HN user
https://whitequark.org
Original author of smoltcp here! I couldn't have imagined how much of a cornerstone of the Rust ecosystem it would become. Very excited to see it get used like this, and yeah, #![no_std] use cases were the original and primary motivation to build the stack in the first place.
Yup, you can use something like:
$ curl http://yourdomain.org -X PUT --data https://tangled.org/@yourname.tangled.sh/site
from a CI pipeline, or just upload an archive from the same (if you use "Method B" for authorization).
It uses completely different software (that I wrote together with a small team of volunteers: https://codeberg.org/git-pages/git-pages) which scales very well horizontally and works more like GitHub Pages than Codeberg Pages technically, but in concept you are basically correct.
122 MB of it is Wasm machine code of a MinSizeRel LTO build of LLVM; it is compressed to 23 MB by Zstandard when your HTTP client supports that. That is about as small as you can get an LLVM/Clang/LLD bundle to be, and I put a lot of effort into making it smaller.
248 MB of it is an OpenBSD sysroot; it is compressed to 45 MB by Zstandard when your HTTP client supports that. I have not used OpenBSD and have no particular insight into what's inside.
If your browser has Zstandard support, it downloads only 100MB. But yes, this is a proof-of-concept that needs some fixes.
A few things:
he was a large contributing factor to the previous SolveSpace lead maintainer quitting
If you look at https://github.com/solvespace/solvespace/issues/714, it refers to "a few people [who] behave in a way that is unconstructive and directly leads to maintainer burnout [...] have not encountered this level of entitlement and persistence when working on any other OSS, of which I maintain plenty, and I do not wish to encounter it ever again.". That's this guy. At the time I chose not to name him publicly nor to ban him from the organization; the latter was clearly a mistake.
(The unfortunate incident with Aleksey was the proverbial straw. I regret that it happened, since Aleksey has done a lot of good work for the project; if memory serves, at the time I was looking for other ways to fund his work.)
who near converted SolveSpace to doble-licensed open-source, far away from its inital GPLv3.[3]
This happened after I spent several months paying Aleksey Egorov (Evil-Spirit), who did some of the best and most important work on SolveSpace, a competitive salary out of my own pocket, and it has been done in coordination with Jonathan Westhues. (You'll see his name on the CLA.) SolveSpace had a commercial licensing option before the initial open-source release, which provided a (small, but useful) revenue stream, and that seemed like a good option to continue using.
Knowing this, you can also see why Aleksey's unfortunate statement about gender felt so painful. All I wanted was to keep developing a great FOSS CAD!
process_vm_read and its equivalents allow you to read data whose layout you already know. unfork allows you to read data whose layout you don't know or that is partially generated by calling the accessors that the application already has for that data instead of reverse-engineering them and doing the transformation yourself.
Also I got pinged by like a dozen different HN bots, because each time any of them tweets a link, Twitter thinks it's a quote-tweet and sends a notification. Annoying.
At the time when I started working on smoltcp, there were a few Rust libraries for working with TCP/IP on the wire level, and they heavily used metaprogramming. Unfortunately, the task of implementing a generic binary protocol serializer/deserializer that can handle TCP/IP is not small, and as far as I could tell, it overtook implementing anything beyond that.
So I made the decision to do the simplest possible thing: write the packet serializers/deserializers entirely by hand. It took very little time and adding any new features was easy and predictable. I believe it was the right decision as it allowed me to focus on the hard parts of a TCP/IP stack.
It doesn't use any C library functions by itself. (In fact in all of its applications at M-Labs, there is no C code running on the same chip.)
The only uses of libc are in the TUN/TAP driver, which is necessary if you want to bind it to a virtual OS interface.
I designed smoltcp (and wrote most of the code currently in it). The original TCP/IP RFC (RFC 793) contains several ambiguous requirements, and as a result they do not specify a well-defined system. There are also some outright incorrect statements. There are a few follow up RFCs (e.g. RFC 1122) that clarify these issues, and there are more RFCs (e.g. RFC 7414) that describe the TCP features that you should avoid using.
By using this collection of TCP/IP RFCs that grew over the years, it is indeed possible to implement a stack from first principles and have it interoperate with other existing stacks without much trouble. (At least so long as you don't put the same bugs in your test suite as you do in your stack... which you will.)
However, being able to transmit some bytes reliably, and having a high-performance stack that works well in real world conditions are different. You might be able to do the former from RFCs, but the latter absolutely requires a nontrivial amount of tribal knowledge that you have to collect crumb by crumb, and often quite painfully, too.
Smoltcp is somewhere halfway between. It's pretty reliable, but I am sure there is much to be improved in its operation in adverse conditions, with obscure peers, and so on.
The "smol" in "smoltcp" is mostly talking about the internal architecture and exposed API. For example, it will never support true zero-copy sockets, because the API burden due to restricting itself to safe Rust is too high.
I don't think any TCP/IP implementation is going to be "haiku-like", the protocol stack is way too messy.
But it's not like you can build a solid TCP stack these days either simply by reading the original late 70s RFCs.
I literally did this. It's called smoltcp (https://github.com/m-labs/smoltcp) and we use it in production as an lwIP replacement with great results.
MSVC compiler doesn't do SROA, as far as I know.
In the future, consider verifying your extraordinary claims. Of course it does, and it took me about two minutes to demonstrate that: https://godbolt.org/g/9kT1NP
Zoxc has repeatedly refused reasonable requests to alter the patch to fit the standards of upstream. Because of this (and because I am rather tired of not having stack probes, with my embedded system not having functional guard pages), I'll make a hostile fork of their patch soon and get it through the pipeline. Stay tuned.
SolveSpace is indeed similar to FreeCAD's Part Design module. One major difference is that SolveSpace uses the same solver for constraints in 2D and 3D, as well as for sketches and assemblies, whereas in FreeCAD the Assembly module is separate.
There are vague plans for integrating Lua in a way that lets people implement new constraints without touching the C++ code, but the current architecture makes it very hard. We're refactoring it but it will take a while until such scripting is viable.
I care a lot about reliability! In fact, FreeCAD's incessant crashing (and the fact that it corrupted the savefile when doing that) was the single biggest reason I put so much time into improving SolveSpace, although working assembly support is a close second.
Even in case that SolveSpace does crash, it has an autosave facility (with a five minute interval by default), and so you should never lose more than five minutes of work.
You should also use the 2.x branch and not the released version 2.1, as the branch has some important bugfixes. I will release 2.2 within a few of days though.
I've been planning to integrate libarea (of HeeksCNC fame), which can generate HSM toolpaths.
In the current solver, the constraints are linearized. It's not especially complex (just 500 LOC, not counting the symbolic algebra system that feeds it) or clever, but it does the job: https://github.com/solvespace/solvespace/blob/master/src/sys...
We've been planning to evaluate Eigen for a while, but I will also look at Cassowary, thanks!
That being said, depending on the sketch, often the vast majority of the time SolveSpace is calculating after dragging something is spent not in solver, but rather regenerating geometry, and that's harder to optimize.
The bug report is not wrong. Rather, whether the current behavior is correct depends on the platform.
For example, Darwin's libc offers this contract for memcpy and clang is perfectly within its rights to generate such code (note that the IR it generates is still violating LLVM's contract on the memcpy intrinsic); glibc offers no such contract for memcpy, and so clang's code is nonconformant.
How it works: http://www.google.com/patents/US8125620
I'm very interested in this technology (and somewhat skeptical about it). The website is very opaque on how it actually works, and "signature correlation" doesn't appear to be a well-known term (http://scholar.google.ru/scholar?q=signature+correlation+lid...). It also appears to not be based on time-of-flight measurement.
It's also not clear for me how are they going to make a production run within 2 months (funding ends with Feb, shipping in May), much less so for a project which includes an ASIC.
Reference counting comes with a huge toll on interoperability. Forget one Py_INCREF(Py_None) in a tight loop, and you're up to a segfault in a place very, very far away.