openscad-graph-editor VS HelloWorldDriver

I really wish Livecode hadn't pulled their opensource/Community Edition (and I'd be very glad for someone to do something with that code).

Gambas is something I keep wanting to try and seems promising.

I did one small app w/ Python and TKinter, but it was a dense wall of text/code when I was finished and not something I was interested in revisiting. I keep seeing suggestions that Python w/ QT support is supposed to be quite good.

One unlikely option is Google's Blockly (which I wish had a stand-alone desktop implementation which would make graphical programs), which has a nifty version implementing OpenSCAD:

https://www.blockscad3d.com/editor/

which I've used a fair bit. Moving on from there, there is: https://github.com/derkork/openscad-graph-editor which has the advantage of encompassing the entirety of OpenSCAD. It's also possible to wrap up Python using PythonSCAD.org

If you're willing to consider other node/line connection systems two promising options are:

https://ryven.org/

and

https://nodezator.com/

What sort of coding, on what sort of projects do you want to do?

The Cube was a gift, and the PS work didn't go that far.

I found PS pretty inscrutable, esp. the function-filled variant used in Virtuoso, but did manage to get dimension lines coded up (which promptly ran into precision problems which I eventually gave up on).

OpenSCAD is a lot more approachable, and METAPOST was easy to pick up and make use of:

http://ftp.tug.org/TUGboat/tb40-2/tb125adams-3d.pdf

Still working through this at:

https://willadams.gitbook.io/design-into-3d/3d-project

and mostly using visual tools (which arguably is limiting me) https://www.blockscad3d.com/editor/ and https://github.com/derkork/openscad-graph-editor and of course, had to throw: http://pythonscad.org/ into the mix. Still a bit miffed that Nodebox and Processing or maker.js weren't a good fit.

As a visual person (traditionally trained as a graphic artist), I've wanted this sort of thing for a long while, and I've been trying to use it for 3D.

Surprisingly, there are multiple specialized tools for this:

- https://www.blockscad3d.com --- an adaptation of Google's Blockly to OpenSCAD

- https://github.com/derkork/openscad-graph-editor --- wires and nodes, it has the advantage of exposing _all_ of OpenSCAD's commands (the above has a subset)

- https://github.com/Tanneguydv/Pythonocc-nodes-for-Ryven --- a module for using PythonOCC in Ryven --- when I finally succeeded, I found the language inscrutable, even when provided w/ quite nice examples (definitely a failing on my part, not that of the tool)

- https://github.com/graphscad/graphscad --- it took a long while for the source code for this to be made available, and for a while it had compatibility problems (why was "cube" redefined?) --- probably defunct for political reasons, it had some interesting ideas, in particular the ability to have custom icons for modules

- https://www.nodebox.net --- if memory serves I got hung up by not easily being able to do 3D, and when doing 2D having precision problems (or maybe that was Processing.org)

and I've been using these tools to make various things:

https://willadams.gitbook.io/design-into-3d/3d-project

(and maybe eventually I'll finish something)

The problem I've been running into is there doesn't seem to be an answer to the question:

"What does an algorithm look like?"

I recently had occasion to mention Herman Hesse's _The Glass Bead Game_ (also published as _Magister Ludi_) and I'll bring it up again --- what is a meaningful graphical representation of a program?

The Drakon folks argued that there should be one true path but that's not really communicative and I would note that if this was a simple thing it wouldn't be decades since I last saw a physical Flowcharting Template:

https://americanhistory.si.edu/collections/object-groups/flo...

(and it's pretty rare to even see a well-done electronic drawing of a flowchart since Visio made its splash and vanished into the bowels of Microsoft)

The main problem seems to be one of expressiveness not scaling up well, hence:

https://blueprintsfromhell.tumblr.com/

https://scriptsofanotherdimension.tumblr.com/

Presumably, one doesn't want to define modules/variables unnecessarily --- but the question becomes where is that boundary?

If you define too many, then you're back to the "wall of text" which one was trying to avoid (but wrapped up in nice boxes with some lines or shapes), and if one doesn't use them (well, look at the pretty/awful images in the links above).

Ideally, a well-coded visual program would have a pleasing aesthetic appearance which is expressive and communicates flow and function, and I've tried for that at:

https://willadams.gitbook.io/design-into-3d/programming

(though I wish that there was an easy way to export an SVG version of a program)

I believe that what is needed here is some graphical equivalent to Literate Programming: http://literateprogramming.com

Is there a nice GUI toolkit integration which would allow making a graphical application with this? I have an idea I want to try it which might be a good fit.

_That_ is a question I want an answer for.

Currently I am using OpenSCAD Graph Editor: https://github.com/derkork/openscad-graph-editor to create programs:

https://willadams.gitbook.io/design-into-3d/programming#open...

but the fundamental question which remains unanswered is:

>What does an algorithm look like?

Interesting.

I've long been frustrated by traditional CAD/CAM, so finally worked up:

https://github.com/WillAdams/gcodepreview

which allows me to use:

http://pythonscad.org/

and:

https://github.com/derkork/openscad-graph-editor

to create joinery:

https://forum.makerforums.info/t/openscad-and-python-looking...

which would otherwise be tedious to draw up:

https://community.carbide3d.com/t/creating-drawers/19475/26

Yes, unless you're a visually oriented person like myself who is trying to do the programming visually.

I use:

https://github.com/derkork/openscad-graph-editor

to try to design woodworking projects:

https://forum.makerforums.info/t/openscad-and-python-looking...

and I'd like to think that I'm managing to keep the visual appearance sufficiently expressive that it is easier to work with than a traditional textual code representation --- jury is still out on that, we'll see when I start re-purposing what I'm working on for odd/even sides, and then then doing the horizontal version of the joinery.

The problem here is that a fundamental question has not been answered, and as far as I can tell, has not been addressed by any of these visual environments:

What does an algorithm look like?

Herman Hesse alluded to this in his novel _The Glass Bead Game_, but despite decades of discussion and work, no one has made a convincing pysical representation of that system.

I love the concept, and have made some moderately complex attempts, e.g.,:

https://www.blockscad3d.com/community/projects/1430644

https://github.com/WillAdams/gcodepreview

it always devolves to screen size being out-paced by problem complexity --- one gets something of an inkling of this at:

https://scriptsofanotherdimension.tumblr.com/

Alternately, one can just break a project down into modules, but then the top-level view becomes the wall of text representation (albeit w/ nice lines or captured into pretty boxes) which one is ostensibly trying to escape.

I'd love to see someone succeed in this, and I've been using:

https://github.com/derkork/openscad-graph-editor

quite a bit, and put a bit of money towards:

http://nodezator.com/

I have been very pleased w/ and impressed by:

https://github.com/derkork/openscad-graph-editor

and really want to look deeper into it to see if it could be forked to create a version which creates Python code.

Yes.

OpenSCAD Graph Editor is done with an earlier version and runs on Mac OS, Windows, and Linux:

https://github.com/derkork/openscad-graph-editor

The most impressive 'pushed beyond it's limits' code I've seen is The trick's VB6 kernel mode driver. Yep, really. VB6. Kernel mode. You have to strip out the MSVBVM60.dll dependency, which dramatically limits what language features you can use, but it's possible, albeit for 32bit Windows only, of course.

https://www.vbforums.com/showthread.php?788179-VB6-Kernel-mo...

Inspired by that, I made a similar 'hello world' type kernel mode driver and in addition to the VB6 version, made a twinBASIC version, which can compile to x64 and run on current Windows. twinBASIC has no runtime dependency, so you can use far more of the language features, supports cdecl for calling dbgprint, and it has native support for putting APIs into the IAT so no TLB dependency and overriding the entry point so no special hack for that.

https://github.com/fafalone/HelloWorldDriver

I'm not nearly as brilliant as The trick or wqweto to figure these things out to begin with, but it's so much fun taking the techniques of these legends and running with them. Although I did claim the title of first to create a realtime kernel ETW event tracer, a notoriously unfriendly API that requires multithreading (possible in VB6 thanks to The trick et al, natively supported in tB via API for now, language syntax soon).

I'm a big fan of twinBASIC, more successor than clone.

It's working on full backwards compatibility with VB6 (and very, very close to it, even many complex UserControls work), with a lengthy list of new features (x64-- through compat. with VBA7 x64 syntax, multithreading (via API for now, native syntax soon), generics, overloading, Unicode-everything, defining interfaces/coclasses in language instead of TLBs, easily makes standard DLLs, Implements-Via syntax to extend classes, parameterized class constructors, can specify UDT packing, bitshift operators, inline initialization of vars, forms support modern image formats/transparency/alpha blending, AddressOf works on class members... well, the list goes on for quite some time: https://www.vbforums.com/showthread.php?890181-TwinBasic&p=5...

One thing I'm sure lots of people here will find blasphemous, it lets you make kernel mode drivers, provided you stick to WDM (you could do this as a hack in VB6, but you had to strip the runtime dependency out-- which dramatically limited usefulness, not to mention no WOW64 for kernel mode. tB has no runtime dependency so all you have to do is avoid strings/variants/most but not all arrays, as those call user mode APIs behind the scenes). Proof of concept: https://github.com/fafalone/HelloWorldDriver

Main downsides are that it's also like VB6 in being closed source/commercial (only restriction on the free version is a splash screen on x64 exes though, and won't have access to compiler optimizations or cross-platform compilation when they're implemented; no restriction on commercial use or royalties), but the creator seems amenable to changing that if it's viable, and since we've had 20 years of no community stepping up for something like this, it's just a practical matter that for one person to do it they'd need income as it's a major undertaking, not something you can do as a hobby with full time employment doing something else, at least if it's going to get done in years instead of decades (*cough* Radbasic, which has made near zero progress after being announced around the same time, and is barely a step above Hello World support).

Yes, really.

To prevent them beforehand reliably would be extraordinarily difficult in VBA... you could hook the low level APIs called to perform those operations, but that's no easy task. A file system minifilter driver is the ideal way to go about it, but as that's kernel mode programming you couldn't do it in VBA, you could only do it with great difficulty in VB6 (and only if you had 32bit Windows), and slightly less but still extreme difficulty using the x64 VBA language using twinBASIC, which includes features to make kernel mode drivers (here's a proof-of-concept hello world driver, written with the VBA 64bit language, capable of running on 64bit Windows 10/11). I'm currently working on a proof of concept minifilter driver for just such an application, but since Microsoft's minifilter driver samples don't actually work even when compiled unchanged from their C source, it's quite challenging.