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.
HN user
codehero
https://analog10.com https://www.tindie.com/stores/analog10/ http://github.com/codehero
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 demoChoose 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.
USB is still problematic on Linux. In particular the musb is completely unstable when "babble" is detected. You have to use the right kind of USB hub (or modify the cable) to keep power from backfeeding into the BBB. It seems your experience is different from mine.
There are two troubling lines in his code (from https://github.com/espruino/EspruinoOrion/blob/gh-pages/seri...)
var header = sampleRate; // 1 sec to charge/discharge the cap
var bufferSize = samplesPerByte*data.length/*samples*/ + header*2;
This implies 2 seconds of overhead per message sent from smartphone to microcontroller, 1 for the light to turn and 1 second of clearing time before the next transmission. This explains why the lights toggle so slowly.To top it off, he uses 2 stop bits. The signalling rate may be 9600 baud but do not expect to be transmitting 9600 DATA bits a second! I think such claims need to be backed up with a demonstration full loopback capability without either side dropping a byte, with no pauses between serial bits.