adius

I've tried to get into Solidworks, Fusion, and FreeCAD several times, but every time I come back to programmatic CAD. It just better matches how I think about 3D design I guess. Also, I love that there can't be any hidden state or constraints -everything is fully defined by your code and fully visible.

Just give it a try, I guess, and see if it works for your use cases!

I was actually able to get a first version released just now: https://luacad.ad-si.com/playground It's still rather bare bones and won't work well for large models, but otherwise it should be fully functional!

I'm pretty sure it's Turing complete by now. If it was conceptualized as a limited language and only became a full fledged programming language over time, it would certainly explain all its weird warts. (Here is some more details: https://github.com/ad-si/LuaCAD#why-lua) I guess 3D modeling is just too complex for a simple, but limited DSL.

Lua is easier to use, faster, and more feature-rich. It's one of those rare occasions when a new solution is actually better in every single way.

Agreed! I’m already working on it, but it’s not quite ready yet. ETA is 1-2 weeks.

Thanks! It natively supports all BOSL2 functions which include a chamfer argument (https://github.com/revarbat/BOSL/wiki#common-arguments). So that makes it quite straightforward to add chamfers to everything!

Yes, it executes in a full fledged Lua environment. So you can do all the things you expect do be able to do with Lua!

I’d pick Lua over Python any day, but maybe that’s just me. ;-)

Good idea! Just committed the necessary changes in https://github.com/ad-si/Woxi/commit/f337a722871ad1b08f8e783.... Did I do it correctly?

No, none of them are implemented yet. I'll bump the priority to implement this!

Interesting - I would never use it as I find entering math with plain ASCII much faster and more intuitive, but if there is interest in this, I'll increase its priority!

Any help is highly appreciated! A great way to get started would be to open issues for the problems you found at https://github.com/ad-si/Woxi/issues.

Thanks! I’m interested as well … I’ll check it out and report back!

Performance is pretty good for most stuff by now. However, there are functions which not optimized yet or implemented in a very basic way and if you use them in non-trivial ways the performance might be quite slow. We're happy about any reports of such issues at https://github.com/ad-si/Woxi/issues!

Yes, Rubi mostly works by now! Performance is still a concern, but we're working on improving it. I'll add some information on how to best use Rubi to the documentation soon. I already have a draft, but didn't find the time to finish it, yet.

We currently support almost everything up to version 6.0. Here is a detailed comparison with all Mathematica versions: https://woxi.ad-si.com/docs/comparison/mathematica/

However, MathLink is one of the few exceptions as it is deprecated by now.

I think the Wolfram Language got 80–90% of it right, and that's why I want to reimplement and use it in the first place. It bothers me that I have to use inferior solutions, such as those implemented in Python and Julia, just because the better solution is prohibitively expensive.

Of course, there are a few things I think we can do better than the Wolfram Language, but given all the available legacy code, there's really no point in making it slightly different and losing the ability to use that code. However, we might build an alternative syntax and frontend in the future that surfaces the capabilities of the Wolfram Language with a better UX.

Since then, we've made more than 7,000 commits and massively expanded Woxi's feature set. So it's well worth another try for anyone who tried it back then!

Cuis Smalltalk has full high-DPI support as its GUI is based on vector graphics: https://cuis.st/

The "Initial Motivation" section in the article explains why existing mobile apps aren't good enough.

Fixed this on main. The macOS build linked against Homebrew's libwebp by absolute path but never bundled it, so it only ran on machines that happened to have it installed. The build now copies all non-system dylibs into the app and rewrites the install names, and fails if any absolute reference survives.

Thanks for the report. I'm looking into it!

After 9 years of on-and-off development, I'm happy to announce the 1.0 release of Perspec, a desktop app for correcting the perspective of photos of documents, receipts, and whiteboards.

The headline feature of 1.0 is automatic corner detection: Instead of the usual edge-detection + Hough transform pipeline, it segments the document via watershed segmentation and finds corners, which handles wrinkled receipts and curved book pages much better. And if the detection is off, you can just drag the selection polygon to fix it.

My theory is that writing as much as possible in Rust will improve performance and produce higher-quality code due to Rust's static typing. So far, it's been working well, but the final verdict is still out.

Author here: I absolutely do not understand this mindset. It has almost 20K unit tests by now and hundreds of full end-to-end tests of complicated scripts to ensure it works and matches the output of Wolframscript. Why does it matter that I was using Claude to help me implement it?

Mathics (https://mathics.org/) has been working on a Mathematica clone for years and hasn't had any problems so far. There have been many legal cases establishing that APIs are't copyrightable, and since Woxi shares zero code with Mathematica, it should be fine.

No support for intermediate steps yet, but if there is interest in it, I'd be happy to prioritize it.

Thanks! I'm hoping to use libraries for this, but unfortunately there aren't many available in Rust yet for those kinds of problems.

Integrating Symbolica would be awesome, but our licenses are incompatible at the moment. If you're willing to relicense parts for Woxi, I'd be happy to work on this together!

For short scripts, it’s often faster because there’s less initialization overhead. In general, though, it largely depends on whether the functions you’re using already have optimized implementations in Woxi. That’s what I’m currently working on, so I’d appreciate any feedback on what doesn’t work for you yet!

As an alternative, I’m working on reimplementing Wolfram Language/ Mathematica in Rust: https://woxi.ad-si.com/ A lot of Wolfram Language code just works already!

As an alternative, I’m working on reimplementing Wolfram Language/ Mathematica in Rust: https://woxi.ad-si.com/

A lot of Wolfram Language code just works already!

LLMs are now smart enough to simply download the code of any project they want to inspect. So this argument doesn't really hold up anymore …

Thanks! I'm using [Anki Panky](https://github.com/kamalsacranie/anki-panky) for generating the flashcards and then [Anki](https://apps.ankiweb.net/) itself for learning them.