codehero

I looked at your site again and see you made changes. Stop working so fast, it's actually hurting your presentation pretty badly. I see "We make PCBs fast". I suppose it may mean something to the layman, but to me it just means you do what 4PCB does, except not in 24 hrs like they do. But never mind about determining turn time. When I click that I only see a single time listed (5 days). But if I look at the top of the screen I see another turn time of 7 days.

Just stop working on this site for 3-4 days and get your mission statement together. Maybe put some pictures of actual test fixtures if you test boards or any of your rework equipment. Every PCB/PCBA shop out there puts rework videos on its 'gram. It's just really hard to understand your business with this edgy/terse hustler kind of talk. Or your careers page where I get the sense that move fast and break things is the backend philosophy. Not a good look for someone who wants PCBs fast.

I so want this to work but holy cow I can't even understand where you guys are coming from.

Love the energy, but I can hardly believe the title "Proven Metals" because your website does not stand up to basic scrutiny:

1) First issue: I do not know what your manufacturing constraints are for PCBs...the number of layers is not documented. I don't even know if you support FlexPCBs.

2) I suppose I could figure out if you could make my boards in seven days if I played your upload game...but I should have to do that. Even the following site, with its clunky UI, makes it more clear what they can or can't do: https://quickturnpcb.co.kr/

3) You say you ship "tested" boards, but what does that mean? Firmware testing? Emissions testing? If you ultimately choose the MPNs, does that mean you own the failures if the board doesn't come up?

4) It's not clear if you accept consigned parts. It's not even clear if you are properly storing the parts you are kitting with respect MSL, ESD, etc.

5) In the end, what makes you any different from a typical broker like Millenium Circuits Limited? (Not that I am endorsing them, as I have had terrible experience from them as well)

6) If you are owning testing and promising quick turnarounds, I would assume you are actually shipping test fixtures to the CM before they ship so they can rework if necessary. But again unclear from your description

I run in LAN/Developer Mode on the X1C and P1S and I sync filaments just fine. I don't monitor my prints with my phone but if I wanted to I wouldn't complain about the lack of Bambu support on the DEVELOPER MODE! I think the clear call to action here is to DEVELOP your own software.

Depends on the quality of the solder joint. Poor quality solder joints do not survive mechanical shock. If you are fighting a GND pin that sinks a lot of heat, using leadfree solder and you aren't that skilled...don't trim that lead flush with the PCB. Otherwise, if you are sure that the solder has wicked into the hole, trim away.

So if someone is telling you not to trim the lead...I'll let you draw your own conclusion.

Pipes and named FIFOs are easy and great. I say this after implementing various IPC methods (unix domain sockets with fd passing, POSIX message queues, 0MQ, XML RPC, local TCP sockets, just to name a few). Use a simple line oriented protocol. If you are passing complex data through your IPC, you know it's time for files. Shared memory is another way to do IPC but hopefully you have robust method of detecting the liveliness of your local processes and you want to give up the Unix file paradigm.

Can anyone explain to me the advantages of Pikchr over dotfiles?

Any reason why the first example (subtracted sphere) is rotating off axis or possibly has bad geometry?

Safe string manipulation never exceeds the bounds of the buffer. So negative values are dangerous, as all as any additions that would exceed the maximum size.

Negative lengths are not compatible with unsigned representation.

A system implementing invalid string values must choose a text encoding such as UTF-8 that supports the concept of an invalid character. Null termination is too flexible. As such is simple length prepending.

You're explanation is not inconsistent with my proposal, but you don't seem to grasp VALIDITY.

If you have studied Computer Science, you should know that the null string is quite a valid string.

Let's take strstr, which finds a matching substring needle in a haystack string.

-returns a NULL string if the needle is not in the haystack. -returns pointer to first matching substring.

Extend strstr with VALIDITY

Understood behaviour if both are valid.

Say the haystack is INVALID...as the return value is NULL or a strict substring of haystack, should return INVALID. A poison haystack should poison dependent strings.

Say the haystack is valid but the needle is INVALID...should return NULL. A valid string never contains an INVALID string as a subsequence.

Is it more sensible to cat 2 strings, but cut off the second one, then pass off the result as valid?

I would say let an INVALID string be length 0. Then accept that catting a valid and invalid string would result in a shorter length.

Which one do you think is safer?

I don't understand the fallibility. Clearly misuse of string functions is epidemic. A propagating INVALID string result makes it very clear there is a logic error and not an exploit.

I understand how one could shoot down implementations, but none has made a convincing argument about shooting down the idea.

Please support your argument against correctness by providing an example where an INVALID string as input to a suitable modified generic string function would result in a valid string.

NULL is the lack of any string. If one view a string as a result of an operation, then an INVALID string is the consequence of bad input to an operation.

Propagating NAN is an elegant method in floating point and makes sense for well defined string encodings like UTF-8.

memcpy and company are strictly for raw unencoded buffers.

Efficiency looks past current deficiency.

We have the empty string: "\0"

We have the null string: NULL

There is no concept of an INVALID string, as float has NAN.

This would be the result of trying to copy a string to a buffer that is too small.

Or sprintf() into a small buffer.

Or a raw string parsed as UTF-8 and is invalid.

Correctness over efficiency.

I tried really hard to find a main() function browsing the demo source code, but I could not. I also find it interesting that code boilerplating is called out as a problem, but I run into code like this:

  #include "Protocol.h"

  #include "comms/comms.h"

  namespace cc = comms_champion;

  namespace demo
  {

  namespace cc_plugin
  {

  Protocol::~Protocol() noexcept = default;

  const QString& Protocol::nameImpl() const
  {
      static const QString& Str("Demo");
      return Str;
  }

  }  // namespace cc_plugin

  }  // namespace demo

Choose the size representation that bests fits your use case:

  // Put this in header to help user calculate allocation needs but hide size from user
  size_t LIBNAME_alloc_size(param1, param2, ...);

  // Put this in the header to hide the size from user code but allow inlined size calculations
  extern const size_t LIBNAME_ALLOC_X;

  // Put this in the header to make size known to user (for static const allocation)
  #define LIBNAME_ALLOC_Y ((size_t)42)

If your strings are > 65535 bytes in length, consider buffering the string data or using another data structure.

Pet pig owner here. Pigs are problem solvers. Pigs are optimizers.

The following videos of my pig demonstrate this.

Video 2: Pig is first learning the task.

Video 3: Pig has slightly optimized the task.

Video 1: Pig has mastered the task.

https://www.dropbox.com/sh/37f48azh2bt4xk4/Wy3iHDMp1e?previe...

Why use this library when similar libraries implemented in C have been in production for decades?

Ever used OpenSCAD? Try doing CSG operations with CGAL on complex STL surfaces. Then take those same surfaces with vtk, use their boolean operations. Faster but with significantly more errors.

Sell me: I am a crusty old C++ programmer who started numerical and geometric programming on an SGI machine at the turn of the century. I have seen many academic and commercial 3D libraries come, go or perform poorly (vcollide, RAPID, CGAL and many proprietary ones).

It looks interesting but what makes this library any better than what's come before? Why should I learn Rust to use it or really for any computational geometry problem?

Yeah your intuition is correct here. On an MSP430 (which is were I use it) the producer is in interrupt context but as a savvy redditor pointed out, I will need to enable/disable interrupts in the consumer function as well.

I'm running it on a system with 512 bytes of RAM and multiple queues...saving 1 byte helps. I do not need extra space for synchronization; I can enable/disable interrupts without extra RAM required.

I see a war here: the endeavor to reprocess spent waste as fully as possible and the industries that would create expensive burial chambers for them instead.

Making a kernel by community is difficult and has no precedent to directly follow. The model-view-culture community should really take the failings of Linux as an opportunity to make a new kernel that does follow fairness and diversity principles.

No story about early Makerbot is complete without mentioning their commitment to open source (which this puff piece deftly avoids). The open source story has been conveniently dropped.

Here's an excerpt from an Bre Pettis interview in 2011:

Does funding change the commitment to open source hardware? The funding doesn’t change our commitment to being open source. Why would we change a winning strategy? Being open is the future of manufacturing, and we’re just at the beginning of the age of sharing. In the future, people will remember businesses that refused to share with their customers and wonder how they could be so backwards.

http://makezine.com/2011/10/06/makes-exclusive-interview-wit...

Would a donation also stop small companies and 1 man operations from violating the GPL?

Linus' law may scale, but even assuming these eyeballs produce bug fixes, applying those fixes to the source tree does not scale as well.

I have taken time to put my eyeballs on bugs in spidev's ioctl() and TI's spi driver but my bug fixes are not in the tree.

Signing off, adhering to the source standard and attaining enough respect from the established devs to get your fix accepted are the limiting factors.

I already invested significant amounts of time finding these bugs and fixing these issues; I don't have any more to spend to make Mark Brown or other kernel devs happy.

I don't even care about getting the credit for my fixes, but it seems the kernel devs don't want to take my code to next step and get it integrated.