johnfound

BTW: there was a bug in the Windows distribution that caused the program to crash on startup. It has now been fixed. If you're using Windows, please download the package again. I'm sorry, but I don't have Windows, so I had to build the version blindly.

Hi HN!

I'm an assembly programmer, but I've always wanted a CAD tool that combines the workflow of OpenSCAD with the ability to export true, exact geometry to STEP files, rather than polygonal meshes.

I found an abandoned project called bcad, which tried to use OpenCASCADE (OCCT) with OpenSCAD syntax. I decided to revive it. Since I don't know Python or 3D graphics development, I let AI do almost 100% of the coding. I used the terminal version of opencode with the Big Pickle agent, and it worked surprisingly well.

The GUI is built on Dear ImGUI. The app is fully portable (no install, just unpack and run) for both Linux and Windows.

Source code (Fossil): https://asm32.info/fossil/bcad/

What is wrong if your debugging of experimental branch is pushed to the repository? Someone can find this code useful for something else later. And after all, all the experiments are part of the project history, that fossil strive to keep unchanged and as it actually happened.

The same is about the rebase - the difference is that while git keeps the history "as the developers want it to be", fossil keeps it "as it actually happened".

> RE: Portability - Not sure how far you'll be able to get by gcc -S'ing something like nuklear (cross-platform ANSI C89) but it might save you some time.

The big problem with using "gcc -S" is that as a result you have a HLL program, simply written as an assembly language listing.

The humans write assembly code very different than HLL. Even translated to asm notation, this difference will persist. Asm programmer will choose different algorithms, different data structures, different architecture of the program.

Actually this is why in the real world tasks, regardless of the great compiler quality, the assembly programmer will always write faster program than HLL programmer.

Another effect is that in most cases, deeply optimized asm program is still more readable and maintainable than deeply optimized HLL program.

In this regard, some early optimizations in assembly programming are acceptable and even good for the code quality.

According to the wiktionary[1] it is "rhyming slang" from:

    apples and spice = nice

[1] https://en.wiktionary.org/wiki/she%27ll_be_apples

No offenses. :)

At first, FLTK, does not look much better than the old Windows widgets.

In addition, I strongly want Fresh IDE to be portable to MenuetOS, KolibriOS and other assembly written OSes. As a rule, they all are written with FASM and a good IDE that can be ported for days (not for years) can be great tool for the OS developers.

That is why I started the development of special GUI toolkit.

Well, as I said several posts above, I am working on a new, assembly language, portable GUI toolkit that to be used for v3.x series of Fresh IDE.

Unfortunately it will add another 50..100kB to the code, but the portability has price. :(

Code maintainability and readability depends only on the programmers knowledge of the language/framework/libraries used.

For example, I don't know Lisp, so for me it is much harder to read/maintain Lisp project than assembly language project.

Why adding abstraction layers makes programming easier?

Because allow the programmer to not think (and even know) about some things and leaving them to the layer/libraries.

But every layer adds also a level of obscurity. The interaction between multiply layers is even more undefined and random.

It is OK while everything goes as expected. But when there are problems, the obscurity can make the debugging a hell.

In addition, the behavior of the bugs hidden deep in the layers (or in the way the layers interacts in between and with the application) can be really weird.

That is why, IMHO, the programmer should keep the abstraction layers to the minimal count that allows solving programming tasks with minimal effort, counting not only the coding time, but debugging and supporting time as well.

In my practice, I decided that using FASM with Fresh IDE and set of assembly libraries gives me the needed quality of the code.

Well, I am pretty average programmer. Not the worst, not the best.

The code reliability of assembly programs is better because programming algorithms in low level, the programmer controls every aspect of the execution. Notice, that excessive use of code generation macros will cancel this advantage.

Another advantage is that the bugs in assembly programs usually cause immediate crash of the program and this making the fixing easy.

Defer crashes and strange/random/undefined behavior of bugs in assembly programs is rare. IMO, this is because of reduced count of abstraction layers.

Well, no, there is no "book" in the real meaning of this word.

But some documentation is available in the "Documentation" section of the web site and inside the "Help|Help file" (Ctrl+F1) menu in the IDE itself.

There are small example and template projects as well.

Also the FASM forum is a good place to ask: https://board.flatassembler.net

You always can reduce the usage the of macros or make them more assembly-centric. Check the Fresh IDE sources as an example of moderate macro use.

On the other hand, definition of complex data structures is much easier with powerful macro engine.