kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Andy-pants has joined #openscad
J232456 has quit [Quit: Client closed]
J232456 has joined #openscad
J23245696 has joined #openscad
J232456 has quit [Quit: Client closed]
Andy-pants has quit [Ping timeout: 265 seconds]
Andy-pants has joined #openscad
Andy-pants has quit [Remote host closed the connection]
Andy-pants has joined #openscad
Andy-pants has quit [Ping timeout: 250 seconds]
Andy-pants has joined #openscad
<Andy-pants>
Any chance that someone can point me in the right direction working through an issue? When trying to animate using the CLI I get errors saying "MS GDI - RegisterClass failed" and "Can't create OpenGL OffscreenView. Code: -1." Here's a paste with the .scad file and full console output including command executed - https://pastebin.com/wFZi5HmX
<Andy-pants>
I'm on Windows 11, Running Openscad 2021.01 in Powershell.
<Andy-pants>
It write's one png succesfully and appears to die on the 2nd, leaving a 0 KB file.
<kintel>
We try to register the Wnd Class every frame. Probably not a good idea
<kintel>
I know nothing about win32, but this looks fishy :(
<InPhase>
kintel: Off the top of my head, how about: static ATOM class_atom = RegisterClassW(&wc); ?
<Andy-pants>
kintel: That is what I suspect. It gets registered, but doesn't unregister it. So, either 1) Check if already registered before attempting another registration or 2) unregister after each usage
<InPhase>
And I suppose one can always do the old: static bool first_run = true; /* stuff */ first_run = false;
<kintel>
static sounds like a good enough hack for now.
<kintel>
Andy-Pants Are you able to build OpenSCAD yourself?
<Andy-pants>
I haven't, but, should be able to do so.
<InPhase>
Maybe static bool registered_class = false; so that it makes sense as a variable state if the error returns prematurely.
<Andy-pants>
Though, setting up C/C++ dev environments tends to make me grumpy XD
<kintel>
The other question is of course: Why do we create a new context per frame?
<InPhase>
Or a singleton?
<InPhase>
I don't know the underlying logic of this API. It just sounds from the "ERROR_CLASS_ALREADY_EXISTS" error like this API is expecting some sort of global state.
LordOfBikes has joined #openscad
<kintel>
yeah, I think it's just an initial registration of the widget type, needing to run once at program startup
<InPhase>
Ah.
<InPhase>
Singleton would do it then!
<kintel>
Andy-Pants: In the meantime, could you open a ticket, for tracking? I might try to reboot into Windows tomorrow to validate, now that I got VS Code + ssh working on Windows ;)
<kintel>
( but booting into Windows makes me grumpy, so no promises ;) )
<Andy-pants>
haha
<InPhase>
kintel: I eventually found a fix for booting into Windows making me grumpy.
<Andy-pants>
Don't do it? XD
<InPhase>
kintel: ... I stopped installing it.
<kintel>
I had to bite the bullet this time, as I want to clean up offscreen context management, and I don't trust Wine
<InPhase>
Right. I confess, I do keep a dusty unused virtual machine of Windows around for emergencies. But I try not to use that either.
<kintel>
It's my first Windows install since I had Windows XP in a VM 10 years ago or so ;)
<InPhase>
For something like opengl dev though, you're probably going to want to be native.
<Andy-pants>
So, one thing I'm a bit fuzzy on is that the conditional is checking whether the last error isn't `ERROR_CLASS_ALREADY_EXISTS` before displaying that message. However, I'm getting an error 1410, which is literally a `ERROR_CLASS_ALREADY_EXISTS` error.
<InPhase>
kintel: And my VM is Windows 7. Much more modern!
<Andy-pants>
I shouldn't be seeing that error message, right?
<kintel>
I totally overlooked what that check does as well :)
<InPhase>
Oh, lol. Yeah.
<kintel>
Lesson learned: Test the nightly first ;)
<kintel>
Anyway, I still feel a static initialization is nicer, but I can cross that bridge later
<InPhase>
So it's still doing a silly thing. But it's doing it correctly now, probably.
<kintel>
An even better fix would be to reuse the context from the previous frame
<Andy-pants>
I generally try to avoid nightlies. But in this case, it looks like I'm stuck.
<kintel>
OpenSCAD nightlies are generally of high quality
<InPhase>
Especially now.
<Andy-pants>
Why such a large gap in time between the last stable release and now, though? The last stable was 2 years ago. There's been no shortage of development, and there have been bugfixes against the stable branch which seemed to have gotten rolled into the next major release instead of a patch release for the stable.
<InPhase>
We're coming up on some really potent stuff for release, so the nightlies are doing spectacular.
<Andy-pants>
I've see what
<Andy-pants>
's coming down the pipe, and I'm super excited for it. :)
<InPhase>
Andy-Pants: Yeah, we're a little overdue, and maybe missed a good timepoint for it months back. But at this point now we should wait just a notch longer and see what of this high value active work is stable when.
<InPhase>
We had a working theory that more regular releases would lure devs in. And then the devs appeared (perhaps in part coincidence, as 3D printers are rapidly growing in availability). And now stuff is just flooding in like crazy.
<InPhase>
But we should probably keep on that regular releases theory.
<Andy-pants>
Regular releases are good. But, only if they occur. :D
<Andy-pants>
Is the desire to have releases occur at a regular tempo? (e.g. every 3,6,12 months?)
<Andy-pants>
Hrmm. I installed the nightly and am just getting the usage text when using my previously valid command without a clear indicator what's wrong with it. Heck, even this relatively simple command is causing usgae screen display "C:\Program` Files\openSCAD\openscad.com -o test.png --preview=test.sca"
<Andy-pants>
typo in the file extension should be .scad
<JordanBrown[m]>
There's a certain argument that we are currently on a 24-hour release cadence :-)
<Andy-pants>
Absolutely, nightlies are releases! But, they're not stable releases, though. :)
<JordanBrown[m]>
stable-ish :-)
<Andy-pants>
Undoubtedly. But, still not stable. :D
<Andy-pants>
I'm hope it's obvious that I'm being flippant.
<Andy-pants>
Wait, that's not the word I wanted to use. Pedantic is the word I wanted to use. I apologize.
<Andy-pants>
I don't mean stable in a "free-of-bugs" way. But, from a "line-in-the-sand" "things aren't changing for now" perspective
<JordanBrown[m]>
It's all about the cadence. They don't change for a whole 24 hours :-)
<Andy-pants>
haha
J2324569667 has joined #openscad
<InPhase>
Andy-Pants: We do a pretty good job of putting unstable stuff under "Experimental" features, and disabling them. That keeps the bug count in nightly releases pretty low unless you choose optional bugs.
<InPhase>
A few things cannot be done this way, but they're usually not disruptive items.
<InPhase>
Every once in a while something differs.
J23245696 has quit [Ping timeout: 260 seconds]
<JordanBrown[m]>
I was thinking much the same thing, but we do have something of a question of when we de-experimental-ize something.
<JordanBrown[m]>
I'm not immediately aware of anything that's been de-experimental-ized.
<InPhase>
I think in fact there might be a stability bug in the current nightlies, which causes it to just go to 100% cpu once in a while for long stretches. But I can't pin down what's causing it.
<Andy-pants>
InPhase: Fearture flagging is great way to keep the breaking changes tamped down
<InPhase>
But these are reasonably rare.
<Andy-pants>
Feature*
<InPhase>
JordanBrown[m]: Well fast-csg might be a reasonable choice to remove from experimental for the next release.
<InPhase>
JordanBrown[m]: Manifold might not make it. But we'll see.
<InPhase>
I think fast-csg has been hammered pretty hard by now, and as long as you only click the first two options, it seems to handle everything.
<InPhase>
We could leave the option for a little while, but just default it to on.
<JordanBrown[m]>
Selfishly, I think that the textmetrics stuff could largely be de-experimental-ized. The only part of it that I have an uncertainty about is the string presentation of the objects.
<kintel>
Andy-Pants We do run all tests for the nightlies, even on Windows. The stuff you just experienced should perhaps be a test case if it doesn't behave as expected
<InPhase>
JordanBrown[m]: I didn't even realize that was still experimental.
<JordanBrown[m]>
Yep.
<InPhase>
Maybe we want to actually at least have a solid game plan on the object stuff first, to make sure there are no conflicts there.
<InPhase>
I guess it sort of wedged itself into that a little bit on the side.
<InPhase>
Which, is my bad. I always remember to work on reviewing the object stuff when I reach the point of 50% asleep...
<JordanBrown[m]>
Except for the string presentation aspect, I'm completely comfortable with the way that objects are presented so far - obj.name, obj["name"], and for(name=obj). I'm happy with declaring that part of the design "done".
<Andy-pants>
kintel: that's the way I prefer to handle bugs; Write a test case which duplicates the issue, then resolve. If skill allows, it also allows the bug author to review the PR to ensure that the test case properly captures their failure scenrio.
<kintel>
Andy-Pants Yep, and the good news is that our test suite is based on executing the actual OpenSCAD binary, so you could report a bug with a literal cmd-line and the expected and actual output, and it should be relatively straight-forward to write a test case based on that.
<JordanBrown[m]>
InPhase the import function for JSON is in a similar state. I'm not deeply familiar with it, but I expect that I'd be completely happy with considering it "done".
<Andy-pants>
InPhase: The nightly definitely fixes that animation issue! Unfortunately, the nightly is not happy with the command that `openscad_docsgen` uses to render examples. Something seems to have changed in how the `--preview` CLI option is parsed. 2021.01 seems to be happy to accept that option without an argument, whereas the current nightly needs an argument for that option.
<Andy-pants>
So, I'm trying to figure out if that's in intended change, a regression, or a bugfix against 2021.01.
<InPhase>
I don't know. The help is badly written for that argument.
<InPhase>
I can't even deduce what it expects for the listed argument.
<Andy-pants>
I believe `opencsg` and `throwntogether` are valid values
<InPhase>
Well the help should certainly say that if so.
<InPhase>
"[=throwntogether] -for ThrownTogether preview png" This reads like a jumble to me, and the "=" doesn't make sense with the syntax to the left of it.
<Andy-pants>
Agreed
<InPhase>
Looks from the code like the options are "throwntogether" or literally any other string you can type.
<InPhase>
"--preview fishsticks" worked very well for me.
<InPhase>
This is probably also silly.
<Andy-pants>
InPhase: where are you looking at that in the code?
<InPhase>
Line 1040, openscad.cc
<Andy-pants>
Ahh, there it is, thank you :)
<InPhase>
Most likely the UX experience of this was not carefully thought out. Looks like maybe it just sort of evolved.
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
foul_owl has joined #openscad
Andy-pants has joined #openscad
Andy-pants has quit [Ping timeout: 252 seconds]
guso78 has joined #openscad
<guso78>
MainWindow.cc initializes an instance of OpenCSGRenderer.cc and ThrowntogetherRenderer.cc which both derive from Renderer.cc, which initializes OpenGL shaders.
<guso78>
So it appears opengl shaders are initialized twice. I am wondering if OpenCSGRenderer and ThrownToghetherRenderer use SAME or EQUAL shaders...
<guso78>
after changeing tbb to intel-tbb TBB is found with the .pc file
<guso78>
i am wondering if TBB actually comes with different package names
<Scopeuk>
there was something in the work as it was setup initially that started with intel-tbb and changed over. I suspect it has different names in different package managers just for fun
<guso78>
for mxe its definitely called intel-tbb
<guso78>
so intel-tbb is old name and tbb new name ?
<guso78>
i also had to remove libdouble-convert.a from the TARGET LINK list because it caused a linker error with many duplicate functions. its included in QT libs already
Av8r has quit [Remote host closed the connection]
<teepee>
no idea what's going on then, while it's not using the build-dep script, the config should be essentially identical in the docker images and those are fine
<teepee>
I also upgraded to latest MXE so it should not be caused by an old version or something like that
<guso78>
teepee, is it possible to compare mxe versions ?
<guso78>
how to check and how to upgrade ?
<teepee>
not really, only git-hash, they don't seem to do releases anymore
banachtarski has quit [Remote host closed the connection]
banachtarski has joined #openscad
guso78 has quit [Ping timeout: 260 seconds]
guso78 has joined #openscad
guso78 has quit [Ping timeout: 260 seconds]
Andy-pants has joined #openscad
pah has quit [Ping timeout: 260 seconds]
banachtarski has quit [Quit: Leaving]
Andy-pants has quit [Ping timeout: 276 seconds]
L29Ah has quit [Read error: Connection reset by peer]
kintel has joined #openscad
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kintel has joined #openscad
<kintel>
guso78: Yeah, it's likely that duplicate shaders could be managed better between the renderers. I think there's a lot of GL-related resources which could benefit from better management..
<kintel>
I'm currently looking into some of the GL stuff, but in a very bottom-up fashion right now, so I don't know if I'll realistically get to the rendering logic anytime soon..
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<teepee>
disable fast-csg , enable manifold and it works
gunnbr_ has joined #openscad
gunnbr has quit [Ping timeout: 265 seconds]
snaked has joined #openscad
<InPhase>
"Your url appears to be ridiculous as it will split across lines" really needs to be an IRC client feature.
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<teepee>
hah, yes :)
<linext>
the slightly bigger example doesn't render
castaway has quit [Ping timeout: 265 seconds]
marcus has quit [Remote host closed the connection]
marcus has joined #openscad
Andy-pants has joined #openscad
Andy-pants has quit [Ping timeout: 264 seconds]
<linext>
so the wasm is not a drop in replacement
<teepee>
hmm, so ochafik has some extra patches maybe?
<linext>
i need to un-minify the JS and see what's failing
<linext>
it could just be that my openscad.js is very different from yours
<teepee>
oh, that's possible, it shoud be the one from dschroer
<teepee>
it might be setup differently for modules and extensions, but I have not looked into any details
<linext>
function createWasm() is failing
<linext>
wasmMemory = Module["asm"]["Ma"];
<linext>
openscad.wasm.js:305 Uncaught (in promise) RuntimeError: Aborted(LinkError: WebAssembly.instantiate(): Import #92 module="a" function="Ma" error: function import requires a callable). Build with -sASSERTIONS for more info.
<teepee>
hmm, no idea what that means
<teepee>
where did you get the earlier versions from? from ochafik github?
<linext>
DShroer
<linext>
i think i built it myself with some options to reduce the binary size and increase the optimizations slightly