<Guest10-David>
I rendered the two models for which I I had ChatGPT produce the scripts and both look valid. An OpenSCAD plugin might not be necessary to enable useful GPT-4 functionality as both are text (character) based. I'll try more sophisticated structures.
KimK has joined #openscad
Guest10-David has quit [Quit: Ping timeout (120 seconds)]
<J23>
GPT-4 can be told to use other tools to accomplish a task .. so this could improve the outcome as it can use images as input and so create a feedback loop
<kintel>
Meh, for some reason, Windows CI now consistently seems to fail to build manifold-applyops-minkowski.cc. ..without an error, OOM killer strikes again?
Guest10-David has quit [Quit: Ping timeout (120 seconds)]
<InPhase>
kintel: There exists a g++ option of --param gcc-min-heapsize=VAL_IN_KB
<InPhase>
kintel: This is allegedly to set when the garbage collector kicks in.
<InPhase>
kintel: I never once had cause to try it, but maybe worth a shot if you're getting desperate.
<kintel>
InPhase According to docs, the max default setting is 128MB, and GitHub documents runners to be 7 GB RAM
<kintel>
..but we're using Ninja, so who knows how many parallel builds it kicks off, and if we're unlucky they're all CGAL sources
<guso78>
Do i have an old manifold library here ? why doesn't it compile anymore ?
e2k has joined #openscad
<guso78>
teepee, I have seen that there is an const Children *Context::user_module_children() function but it always returns null even though my module has children.
<guso78>
how to make sure that "parent" is false ?
<guso78>
s/false/true/
<teepee>
not sure, maybe it's coming from subclasses?
<guso78>
teepee, i believe the manifold interface code does not match to my manifold version. it there an easy option to re-clone manifold submodule ?
<teepee>
git submodule update --init
<teepee>
that should sync against what is linked in our git
e2k has quit [Quit: leaving]
e2k has joined #openscad
<guso78>
ok thank you
juri_ has quit [Ping timeout: 240 seconds]
juri_ has joined #openscad
J2375 has quit [Quit: Client closed]
J2375 has joined #openscad
<guso78>
https://imgpile.com/i/9NXQKo Functions and modules can fully link to python functions now. There is support for parameters, several datatypes and lists.
<guso78>
Guys like Sanjeev can now start to import their python code with <use> statement instead
<guso78>
There is no trust check is not yet activated when "use" - ing python files
<guso78[m]>
lf94 Same will Happen next week Here: grandfather in law
<lf94>
first time i was in a church in probably 15+ years
Guest82 has joined #openscad
Guest82 has quit [Client Quit]
teepee_ has joined #openscad
teepee has quit [Ping timeout: 240 seconds]
teepee_ is now known as teepee
fling has quit [Ping timeout: 240 seconds]
fling has joined #openscad
JakeSays has quit [Ping timeout: 256 seconds]
JakeSays has joined #openscad
peeps[work] has joined #openscad
guso78 has joined #openscad
KimK_ has joined #openscad
KimK has quit [Ping timeout: 250 seconds]
aiyion has quit [Remote host closed the connection]
aiyion1 has joined #openscad
mmu_man has joined #openscad
guso7870 has joined #openscad
guso7810 has joined #openscad
<guso7810>
is there an easy way to know whether openscad is in command line mode or not ? Decision needs to be taken in SourceFile.cc and it can be called in both modes
<teepee>
nothing official I can think of. why is that needed?
guso7870 has quit [Ping timeout: 245 seconds]
<guso7810>
teepee, in order to find out, if python files are trusted in GUI mode i can simply display a query dialog, whereas in command line mode, i can only depend on a "trust" paramteter
<guso7810>
i simply need to know, if GUI is available
<guso7810>
dont want to add another global variable in case there is infrastructure already
<teepee>
yeah, those are not ideal
<InPhase>
guso7810: How are you handling it after a user clicks "trust all" on the gui?
<InPhase>
Or, "approve all" or whatever it is.
<guso7810>
InPhase, i have a global variable 'python_trusted' which stays true during the session
<InPhase>
That could be set if python is enabled, and not set if it is not, on the command line. Although I suppose that would only handle half the problem anyway. You still need to know whether or not to touch the config files for updates.
<guso7810>
same variable is also set to true in command line mode with 'trust; option
<guso7810>
and i need to know if i can display a query window
<InPhase>
Perhaps check how the logic works for compile warnings. Those either go to the gui console or to the terminal.
<InPhase>
So the problem must be solved there.
<guso7810>
InPhase, thats correct, thats a great idea
<guso7810>
is it nice enough to depend on outputhandler ?
kow__ has joined #openscad
drfff has quit [Ping timeout: 240 seconds]
drkow has quit [Ping timeout: 240 seconds]
<lf94>
nice, are you guys gonna accept guso's awesome work with this new "trust python" feature?
<lf94>
he's asked me to maybe try to integrate nodejs since I'm familiar
<lf94>
that will open openscad to a shit ton of people
<lf94>
(python and js availability)
<lf94>
but the python alone increases accessibility so much
<teepee>
no, the outputhandler stuff is horrible
<teepee>
please don't use that
<InPhase>
Okay, maybe that's not a good model.
<teepee>
problem with it is that it's 1 global handling multiple windows, so it needs a global cross windows gui lock
<InPhase>
lf94: I was a staunch opponent of it because of the security issues, but I think they are addressed with this particular design. It should never be a primary focus to have things be in Python because it is antithetical to the safe-sharing community principle of the scad language, but it adds some huge functionality in providing a gateway for special purpose access to external tooling.
<lf94>
InPhase: yeah, that's what I understood, and that as long as the feature is gated, it's safe
<InPhase>
lf94: I think probably we should not do nodejs, in large part because we might want to let it sit with one added language like this, and see if it's a problem or okay. Also, it's a support burden, and almost all of the potential benefits of adding any language is given by adding Python alone.
<lf94>
I agree, maybe not right away
<InPhase>
lf94: Basically, you get access to some high level numerical functionality, and you get access to file I/O and things like that, in a controlled manner.
<lf94>
Not much of a support burden though I think - guso's shown me some details about their Python fork. Given that the JS pool of talent is massive, it's way less burdensome. Same goes for Python.
<InPhase>
lf94: The goal as I see it is not to add other languages people might be more comfortable with. I have taught OpenSCAD to enough non-programmers that if anyone thinks they can program, but can't figure out OpenSCAD, then there's somthing wrong. :)
J23 has joined #openscad
<InPhase>
Python is another language that pretty much anyone can figure out how to use if they want. So we have two extremely simple languages, one which is safe, and one with approval that gives access to literally anything you can do with a computer.
<InPhase>
Once it's there, I don't really have any horse in the race of what people do with it or why. OpenSCAD is a fun program to play with and push limits, so have at it world. But those reasons are what I consider a design rationale for including it as a locked down extra.
<lf94>
I think you might be a bit biased in this conclusion here
<lf94>
If someone knows JS, they may find it worthless to learn Python
<lf94>
And actually effort
<InPhase>
lf94: Well they can use scad?
<lf94>
They can use JS
<InPhase>
Let me rephrase...
<InPhase>
Well, they can use scad.
<lf94>
I understand
<lf94>
:p
<InPhase>
:)
<InPhase>
But mostly I would be resistant to adding in a bunch of kitchen sinks.
<lf94>
Why would you close the door to something so beautiful to so many?
<lf94>
I see it as equal to supporting french, english, russian, german...
<InPhase>
JS is a web language. But the value-add here is numerical computation and file I/O or report generation.
<lf94>
For you and me, language semantics are easy to travel across. This is not true at large
<InPhase>
These are more typical Python tasks rather than JS tasks, so on a simple threshold of which to pick to have one, Python is the logical choice.
<lf94>
JS is a general purpose language, and has many of the same bindings as Python
<InPhase>
If there were a rationale for some sort of dynamic web interaction as the primary integration goal, then I might have been reluctantly persuaded otherwise.
<InPhase>
But I don't think the language itself needs that, even if tossing OpenSCAD inside browsers is useful.
<lf94>
OpenSCAD doesnt need to be a in a browser to use js
<lf94>
nodejs bindings means continued desktop use
<lf94>
In fact I /fight/ web based shit anything
<lf94>
It leads to bad software in general for reasons
<InPhase>
Node.js was basically just invented so that frontend web developers who only knew JavaScript could also be employed to work on associated web backend components.
<InPhase>
I think of it as more "technically it could also be general purpose".
<lf94>
Technically and practically it is used that way
<lf94>
Lisp was basically invented for AI...
<lf94>
like what kind of argument is this lol
<lf94>
Many things are invented for a purpose and turn out to be useful in other contexts.
<guso7810>
if output handler is deprecated, add a global get_function with a static inner variable ?
<lf94>
You know this, it's a weak argument
<InPhase>
lf94: I'm speaking about the design focus.
<InPhase>
lf94: Like, https://nodejs.org/en/about "As an asynchronous event-driven JavaScript runtime, Node.js is designed to build scalable network applications."
<InPhase>
Not really the task here. :)
teepee has quit [Ping timeout: 240 seconds]
<lf94>
"Node.js® is an open-source, cross-platform JavaScript runtime environment."
<lf94>
Seems perfectly fine. It may be optimized for network applications, but just as LISP was optimized for AI, it excels as a general language also.
<lf94>
A PL for many *is* like a natural language. Learning another, even if similar, is just effort.
<lf94>
For us, we know they're just children of the lambda calculus or turing machine.
<lf94>
So their semantics are easy to pull apart
<lf94>
For *us* - unfortunately not everyone has this knowledge or frame of mind
<InPhase>
Perhaps for some. But packing all the popular languages into the OpenSCAD executable would be a misguided goal I think. So I'm not looking for this to have that purpose.
<InPhase>
We'd end up with a lot of build issues for a diminishing return on capability.
caveman has quit [Ping timeout: 240 seconds]
<InPhase>
If the Python were only bringing that, I'd oppose its integration.
<InPhase>
i.e., we could have jumped through many hoops to try to lock Python down from doing anything. That was raised as an option, but I think then there's no point. We already have a perfectly fine language we support that people seem to learn quickly.
caveman has joined #openscad
<InPhase>
That's why I thought that leave the security issues, but guard the user from accidental problems, is the only logical solution to this problem to introduce value.
<InPhase>
And thus the core goal is just to add "a" mechanism for guarded generality.
<InPhase>
All that said, I wouldn't fight super hard against someone trying to add node.js or other languages if enough other people feel differently. I just think it's probably the wrong project direction and could divert energy for a diminished gain.
<guso7810>
i am very curious, how many opportunities there will arise once people start python. In my experience, people are extraordinary creative with ideas.
<guso7810>
start using python in openscad ...
<InPhase>
Yeah. If we get it in there, and let it simmer for a little bit, maybe all the theoretical narratives of what it's good for will have to change when all the users get a say.
<InPhase>
Then maybe nothing said today is actually right. ;)
<JordanBrown[m]>
Or, rather, I should say three "slots" into which you plug any of a number of components.
<guso7810>
we have several slots for CSG already. latest one is Manifold ;)
guso7810 has quit [Quit: Client closed]
guso78 has quit [Quit: Client closed]
guso78 has joined #openscad
<guso78>
ideally following java approach , you define an "interface" and then implement this interface for different CSG's like CGAL, OPENCSG, MANIFOLD, others
<JordanBrown[m]>
And several IDE variants, effectively. You can use the stock editor/viewer, or you can use a totally different editor and the stock viewer, or you can just use the command line and edit and view using some other tool.
<mfg[m]>
If JavaScript as a more familiar reason is the main reason that node.js has been named, but to big language runtimes are a downside: why not use some simple implementation like quickjs? It's reasonably small, fast enough and the Syntax is more familiar to people
<kintel>
The good thing about JavaScript (not node.js) is that we can sandbox it really well, so the security problem goes away pretty fast
<guso78>
kintel, this is true.hopefully lf94 reads that
<guso78>
kintel we were guessing about good method to find out if openscad is beeing run in command line mode ...
<kintel>
just do it top-down rather than bottom up: Create an object tracking what you want and pass it into the runtime
<kintel>
s/runtime/parser/ if you need the into at parse time
<kintel>
May need to invent a parser settings system of course
<kintel>
Golden rule: Half the work is refactoring :)
<kintel>
if you want a dirty hack, you can probably ask QApplication
guso78 has quit [Ping timeout: 245 seconds]
<kintel>
e.g. if (qGuiApp == nullptr) { <cmd-line> }
<InPhase>
kintel: It seems surprising that OpenSCAD manages to be as complex as it is in two operational modes without this information about command line versus gui having been recorded already.
<kintel>
^ not tested
<kintel>
Ideally, the core would never need to know - it only needs to know where to find resources, what features are enabled etc.
<InPhase>
Here the issue is two behaviors for how to handle python security, one with a warning pop-up, and one with a compile time flag.
<InPhase>
But... I guess that scenario hasn't happened before for the other config options?
<kintel>
We can also create some sort of RuntimeEnvironment class
<InPhase>
Oddly the design philosophy for this was to emulate the spirit of the existing configuration options. The difference here is "pop-up".
<kintel>
..and attach it to each MainWindow
<kintel>
..and instantiate a specific cmd-line RuntimeEnvironment for the cmd-line case
<kintel>
How does popups handle multiple files?
<InPhase>
I suppose we could also dependency inject two different security approvers, one which just checks the flag, and the other of which does the gui interfacing and checks/updates the config file.
<kintel>
open *.scad -> 20 windows -> do I get 20 popups, or are the popup contextualized to each editor pane?
<InPhase>
Give them a base class with a virtual function to check for approval.
<InPhase>
Well I know what should happen, but you better test it on a mac at some point. ;)
<InPhase>
I haven't even tried this yet myself. I've only been dishing out design advice. But it needs some thorough usage testing before we go and accept it.
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
peeps[work] has quit [Ping timeout: 260 seconds]
kintel has joined #openscad
<kintel>
InPhase Btw., clang worked on Windows where gcc failed. ..except float rounding isn't the same apparently. gah
<kintel>
Next time I write a piece of software there will be no Windows build!
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kintel has joined #openscad
kintel has quit [Client Quit]
<peepsalot>
kintel: have you looked at clang-cl ?
aiyion1 has quit [Remote host closed the connection]
teepee has quit [Remote host closed the connection]
GNUmoon2 has quit [Remote host closed the connection]
teepee has joined #openscad
aiyion1 has joined #openscad
GNUmoon2 has joined #openscad
<InPhase>
kintel: Is it picking up libc++ instead of libstdc++ when you do the clang build?
<InPhase>
On Linux libstdc++ is used by default by both unless you specify otherwise, favoring the "native" library. But perhaps that isn't happening for you on Windows given that neither are native.
<InPhase>
I don't think anything other than that should impact rounding. Emphasis on "should".
kintel has joined #openscad
<kintel>
InPhase Links against libc++: clang-cl
<kintel>
uh, wrong paste: -lc++
<kintel>
clang-cl looks ...interesting. I remember doing the opposite back in the 90s; make a visual studio wrapper which pretends to be gcc, to make autotools work on Windows native. Not wishing my way back there...
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]