teepee has quit [Remote host closed the connection]
linext_ has quit [Ping timeout: 256 seconds]
teepee has joined #openscad
linext_ has joined #openscad
linext__ has quit [Ping timeout: 248 seconds]
Xeha has quit [Ping timeout: 244 seconds]
ur5us has joined #openscad
J1A846 has joined #openscad
J1A84 has quit [Ping timeout: 252 seconds]
<zingos>
Hi, what should polyhedron be replaced with? It looks like it will be eventually removed
ur5us has quit [Ping timeout: 256 seconds]
<peeps[zen]>
zingos: what gives you that impression?
<peeps[zen]>
i don't see how it will ever be removed... even if so, it would be first need to be deprecated for some years for people to adjust/not riot for breaking all their scripts
<zingos>
it's deprecated and the warning says it will be eventually removed
<peeps[zen]>
you're probably seeing the warning about "triangles" parameter deprecated, in favor of "faces"
<peeps[zen]>
see, that's been deprecated for 8 years and still not completely removed :P
<zingos>
hehe right
qeed has quit [Remote host closed the connection]
qeed has joined #openscad
<J1A846>
JordanBrown this "double right click" is the most unusefull thing ever .. first it f..up the view so you need to restart scad and then you never get the real source of the part like here https://pasteboard.co/xYaoIrAYPKms.png
<J1A846>
so you get somewhere in the middle the line 64 which is at least the 3D producing line - 2D will not be accessible but that is fine. But there should be some kind of marker for the lowest part that is not in the lib.
qeed_ has joined #openscad
qeed has quit [Ping timeout: 268 seconds]
ur5us has joined #openscad
ur5us has quit [Ping timeout: 255 seconds]
<JordanBrown>
J1A846: I don't use it, but it was sort of related to the "where in my program is this shape coming from" question.
<JordanBrown>
Bedtime...
<J1A846>
the idea is ok but as it is working now it is more bug than feature - and it permanently changes the shader so insides become outsides
califax has quit [Remote host closed the connection]
califax has joined #openscad
little_blossom has quit [Ping timeout: 252 seconds]
little_blossom has joined #openscad
Xeha has joined #openscad
Xeha has quit [Read error: Connection reset by peer]
Xeha has joined #openscad
Guest3 has joined #openscad
Guest3 has quit [Client Quit]
ur5us has quit [Ping timeout: 255 seconds]
<InPhase>
J1A846: Hmm. Obviously I don't use that right click menu enough to have even remembered where it was the last two times it has been discussed in here. But whenever I test it on very simple models it works properly.
<InPhase>
J1A846: I have consequently not seen that insides issue you mentioned.
<InPhase>
J1A846: Maybe a minimal testcase with an insides issue would be helpful.
teepee has joined #openscad
<InPhase>
J1A846: The nasty list of calls appears pretty quickly as you scale up the complication of making a spot, but that I think is the only viable approach since there is no one place that counts as having made a non-trivial thing.
Alexer has quit [Ping timeout: 248 seconds]
Alexer has joined #openscad
<J1A846>
It would be nice if you could better see which calls are within the code and what is from the library ( or maybe make them excludable)
<J1A846>
InPhase here your minimal testcase difference(){cube(20);cube(20,true);}
<JordanBrown>
Reproduces easily in a build from July, but not in 2021.01.
<JordanBrown>
Reproduces easily in 2022.03.22.
<J1A846>
what is a "new window" if i have several tabs the problem is in each of them .. (also wondering what prev and next window does)
<J1A846>
interestingly a single right click brings the call list without that problem - only double right click does ( but i am sure i also had cases where a single right click wasn't working)
<JordanBrown>
New windows are what Ctrl+N used to get you, before they were demoted to being second-class citizens. You have to use File / New Window.
<J1A846>
ah yes that is starting a new instance
<JordanBrown>
no
<JordanBrown>
Same process (at least on Windows), just a new window.
<J1A846>
what is interesting the single right click only works in F12 mode (for complex scenes)
<InPhase>
I'm not getting that effect for that testcase.
<InPhase>
It works fine here.
<InPhase>
In both 2022.01 and my 2022.08 build.
<J1A846>
JordanBrown you are right it is the same process .. but as i got another tab in taskbar it look like a when opening a new process
<JordanBrown>
Taskbar mostly just tracks new windows.
<JordanBrown>
But there is a distinction that I have never looked into between top-level windows and secondary windows.
<InPhase>
Sorry, in both 2021.01 and my 2022.08 build
<J1A846>
InPhase i think it is the double right click causing it .. as the single click works without the trouble (only need F12 for some files)
<InPhase>
Double right click is just clicking the first element in the popup list for me.
<JordanBrown>
Undocked console/editor/et cetera don't count, but Thunderbird open-in-new-window windows do, and Thunderbird compose windows do.
<InPhase>
And is behaving identically.
<J1A846>
hmm maybe because undocked window? .. or what could cause this (or was it fixed .. still using 2022.05.04)
<JordanBrown>
I duplicate it in a built that I think I cloned in late July.
<JordanBrown>
s/built/build/
<InPhase>
Maybe we should all re-test with builds from today so we have a common comparison point. :)
<InPhase>
I'll be configuring with: cmake -DEXPERIMENTAL=ON -DCMAKE_BUILD_TYPE=Release ..
<JordanBrown>
That's pretty much what I use, plus -DSNAPSHOT=ON.
<JordanBrown>
I don't know what the voodoo does, I just do it.
<InPhase>
Okay. I built, I ran, I copied and pasted the code (didn't even press enter), pressed F5, and then double right-clicked on the visible (not cut out part) of the larger cube. It flickered a highlight of my one line of code, and continues to look fine in the preview.
<JordanBrown>
It didn't fail on the first double click.
<JordanBrown>
But it did within the first ten or so.
<InPhase>
I double right-clicked 10 times. Still fine.
<InPhase>
Are there extra wiggle it around steps needed or something?
<JordanBrown>
I just clicked a lot on the model in various places.
<InPhase>
lol. Well, we need to know the magic steps. :)
<JordanBrown>
I have not isolated whether it has to be in a particular place.
<JordanBrown>
Are you on Linux or Windows? That might make a different.
<JordanBrown>
s/different/difference/
<InPhase>
Oh. I actually got it to happen, wiggling it around and clicking a bunch randomly.
<JordanBrown>
I am spoiled by Slack at work, where I can go back to my previous messages and fix typos.
<InPhase>
After it goes out of whack, render is also broken.
<InPhase>
It renders, but in a bit of a mess.
<JordanBrown>
yes
<JordanBrown>
Kind of unsurprising. I assume that render uses the same OpenGL logic, just starting with a single polyhedron rather than CSG.
<InPhase>
The right click menu also does not appear anymore.
<InPhase>
So this is some sort of UB error in the display widget I think, if the right click menu is also out.
<JordanBrown>
UB?
<InPhase>
Undefined behavior.
<JordanBrown>
that was my first guess, but I wasn't sure.
<JordanBrown>
I need to bite it and see if I call kill off compile warnings. The last time I tried to, I got rid of some but it failed on other platforms. Is there a way to do the pull-request builds without also running the test suite?
<J1A846>
with F12 the right click may work again .. as said i have designs where it only works with F12 as the target pixel is maybe behind an intersection object
<JordanBrown>
At the moment it is failing almost instantly - F5, double click, left-drag to rotate the view. Several times failed on the first double click; one took two. But I should note that it's competing with a build and so is running a bit sluggishly; probably all of the race conditions are different.
<JordanBrown>
I do *not* have to be clicking on the model; clicking on open space is triggering it too.
ran has joined #openscad
<InPhase>
Is it only with rapid clicking after dragging, or something like that?
<JordanBrown>
The apparent minimal case was a double-right-click followed (after a pause) by a left-drag. I think I have also seen it with double-right-click followed by mouse leaving and reentering the window. Probably anything that causes a redraw.
<JordanBrown>
Duplicated with cube(10);.
<JordanBrown>
(Again, with competition from a build distorting all of the races.)
<JordanBrown>
Double-right click, move mouse to another window (this IRC client), click there, return to OpenSCAD window, redisplays wrong without clicking.
<JordanBrown>
Not always, but sometimes.
<JordanBrown>
Probably depends on how fast the double right click is.
<JordanBrown>
Repeated with a fairly slow double click.
<InPhase>
JordanBrown: Do you have the vertex object renderer turned on in features?
<InPhase>
I'm code tracing, and there's a weird call to renderer->prepare in this right click routine.
<JordanBrown>
no
<JordanBrown>
The only experimental feature that I have turned on is textmetrics.
<InPhase>
Ok. You're sure?
<InPhase>
Because that's the only weird looking thing that does unusual stuff. :)
<JordanBrown>
As sure as I can be looking at an empty checkbox that says "vertex-object-renderers" next to it.
<InPhase>
Ok. :)
<InPhase>
The CSG renderer is a no-op when that's turned off.
<InPhase>
The CGAL renderer does funny things, but I don't think that's used unless one has rendered.
<JordanBrown>
I suspect that the popup menu is failing not because the menu per se is failing, but because the selection magic is failing and so it is as if you right clicked on empty space.
<InPhase>
Yeah, but I checked that and all the checks are implemented for handling the case of no result from the selection magic.
<JordanBrown>
I don't know what "emit" and "signal" mean in this context. Is it possible that the selection logic is running in a separate thread and that two instances of it are racing?
<InPhase>
So if something goes wrong there it's buried and nuanced.
<InPhase>
These emits should all end up in the same gui thread here.
<InPhase>
So it just means "do later once it returns to the event loop".
<JordanBrown>
Right, I think the selection magic is broken, so that it says "click was on nothing", and the higher levels are correctly and cleanly handling that as a no-op.
<JordanBrown>
That is, once we get into this state the selection magic is broken.
<InPhase>
Hmm. Although there is a QThread in the InputDriver...
<InPhase>
Did someone goof and do a direct call from some mouse code?
<InPhase>
It's actually a bit weird and unintuitive to have the inputdriver not in the same thread as the gui code. That's the gui thread's main job, to process the user interface.
<InPhase>
I guess that opens up a sea of possible race condition errors.
<InPhase>
With so many programmers, it's really easy for someone to have not noticed this was done on input driver code.
<InPhase>
(After all, I was assuming it wasn't done until I just grepped for QThreads...)
<JordanBrown>
My going-in position is always that threads are bad :-)
<InPhase>
I love threads. But they require a discipline that, in my perspective, we really haven't designed this codebase for.
<JordanBrown>
Well, I added fprintfs to selectObject, and demonstrated the problem, and it's not being called reentrantly.
<JordanBrown>
But it acts like somebody rudely turned on buffering on stderr.
<InPhase>
I'm more concerned at the moment about MainWindow and/or its friends calling some input routines in a thread unsafe manner while doing all that stuff to get the mouse position.
<InPhase>
But I had to divert to making the kids lunch, which I will now eat, so I didn't look into it.
<InPhase>
I'm not super familiar with how all the subclasses of InputDriver actually integrate.
<InPhase>
I run many of my gui programs with 20+ threads going at once, but I have architectures built around it as an assumption.
<InPhase>
Once you have that in place, you can add more threads and there's no real burden. But slipping one or two surprise threads in is what gets people. :)
<InPhase>
C++ really needs a public: for the same thread, and a public: for other threads. But it doesn't have one, as there's no way to actually designate thread boundaries at compile time.
<InPhase>
It could be done though. :)
<Friithian>
bah, threading is weak, just get a faster single cpu core
<JordanBrown>
Double-right-click, like double-left-click, can trigger mouseDoubleClickEvent. It doesn't seem to distinguish between the two... and it does do some GL operations.
<JordanBrown>
I think I have seen some mouseDoubleClickEvents that are not associated with the failure, but I don't think I have seen a failure that was not associated with a mouseDoubleClickEvent.
<InPhase>
JordanBrown: Have you tried a whole bunch of times to create the error by right clicking and selecting from the action menu?
<InPhase>
With the same sort of wiggling around of the design and different angles?
fling has quit [Ping timeout: 268 seconds]
<JordanBrown>
(Sorry, local interruption)
<JordanBrown>
I have not. But I do have a different data point: I stubbed out mouseDoubleClickEvent(), and am now unable to duplicate the problem.
ur5us has joined #openscad
<InPhase>
Interesting. That was a clever idea.
<InPhase>
That does narrow it down definitively then as at least involving that.
califax has quit [Ping timeout: 268 seconds]
<InPhase>
I looked a little more in between doing other things, and I really cannot find anything about the InputDriver stuff that should be affecting this behavior.
califax has joined #openscad
<InPhase>
So I currently have no working theory for how a threading issue could be contributing to it.
<JordanBrown>
Isolated to the first two lines of mouseDoubleClickEvent(). (Assuming that my previous inability to duplicate it was real.)
<JordanBrown>
Isolated to the first line. Retesting with the entire routine stubbed out.
GNUmoon2 has quit [Ping timeout: 268 seconds]
GNUmoon2 has joined #openscad
<JordanBrown>
Yeah, can't make it fail if I stub out that first line, which isolates it to QOpenGLWidget::makeCurrent.
GNUmoon2 has quit [Ping timeout: 268 seconds]
<InPhase>
The InputDriver code sends stuff through some massive layers of indirection to get where it's going, but as best as I can tell, everything goes as a properly queued event back to the gui thread.
<InPhase>
So that was worth checking, but I think it's not there.
<JordanBrown>
So far I'm not seeing any of the relevant-looking functions reentered.
<InPhase>
I had glanced at makeCurrent initially, but didn't see anything suspicious. I'll look again.
GNUmoon2 has joined #openscad
<InPhase>
Right, that was the built-in.
<JordanBrown>
We import Qt as a binary library, not source, right?
<InPhase>
Yeah.
<InPhase>
Compiling Qt is a bit of a beastly endeavor.
<JordanBrown>
OpenGL has a notion of a "current context". I don't know whether that's global or per-thread. If it's global, then probably what we're looking for is an MT issue where two threads are fighting over which context is current.
<InPhase>
Okay, but how? :)
<JordanBrown>
I pulled over a copy of the base Qt source to look into something else; let's take a look at what makeCurrent does...
<InPhase>
There are no other direct accesses of context() anywhere in the code.
<InPhase>
Everything else about context is the OpenSCAD variable context.
<JordanBrown>
From OpenGL docs:In order for any OpenGL commands to work, a context must be current; all OpenGL commands affect the state of whichever context is current. The current context is a thread-local variable, so a single process can have several threads, each of which has its own current context.
<JordanBrown>
However, a single context cannot be current in multiple t
<JordanBrown>
hreads at the same time.
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #openscad
<InPhase>
The only other use of a direct makeCurrent is in the offscreen renderer, which appears to be a completely separate context.
<JordanBrown>
I dumped QThread::currentThread() from both the double-click event and the selectObject call, and they're the same, so everything seems to be in one thread.
ur5us has quit [Remote host closed the connection]
ur5us has joined #openscad
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
artag has joined #openscad
<JordanBrown>
Stuff is getting run against the wrong OpenGL context.
<JordanBrown>
The mouse release events normally run with a separate GL context, but after the problematic double click, they run with the primary GL Context.
<JordanBrown>
I do't know how the mouse release events run with a private context, but the double click bollixes that up.
<JordanBrown>
A *left* double click does not: it switches to the primary context, but then it's back to the private one for the future mouse events.
<JordanBrown>
But I got up too early and need to take a nap now.
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #openscad
ur5us has quit [Quit: Leaving]
ur5us has joined #openscad
ur5us has quit [Ping timeout: 255 seconds]
<InPhase>
JordanBrown: Is that maybe some sort of double buffering behavior?
<InPhase>
Oh, no, that should stay fixed.
<InPhase>
"Note: The context and the framebuffer object used by the widget changes when reparenting the widget via setParent()."
<InPhase>
Unless they're omitting other conditions under which it changes.
<InPhase>
It sounds like the doubleFrameBufferObject is owned by the context object, so this is embedded into a fixed context I think.
<InPhase>
Thus I agree, it changing sounds wonky.
<InPhase>
JordanBrown: With your test outputs in there, has mouseDoubleClickEvent been getting called reliably for you?
<InPhase>
I have some std::cerr lines in there, and I'm seeing no output...
teepee has quit [Remote host closed the connection]
<InPhase>
Although I'm also not succeeding in triggering the bug.
<InPhase>
Oh! Finally triggered the bug, but still no outputs.
teepee has joined #openscad
<InPhase>
That doesn't make any sense. I have pretty good confidence in my ability to output some text from C++. :) I checked it like 10 times.
<InPhase>
I will try a clean build.
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
fling has joined #openscad
<InPhase>
JordanBrown: Okay, this mouseDoubleClick doesn't run for me at all under right clicks, but now with a clean build it reliably triggers for double left click. How does that cause it to relate to the bug in question/
<InPhase>
JordanBrown: I'd test as you did with exclusion of lines stopping the triggering of it, but I cannot as triggering it is very very unreliable. I've seen it happen only twice so far.
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #openscad
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #openscad
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #openscad
snaked has quit [Ping timeout: 256 seconds]
teepee_ has joined #openscad
teepee has quit [Ping timeout: 268 seconds]
teepee_ is now known as teepee
snaked has joined #openscad
GNUmoon2 has quit [Remote host closed the connection]