<JordanBrown>
I found that stderr has buffering turned on in some fashion; I didn't get any output until either (a) lots of output or (b) exit. Adding fflush(stdout) made it come out in real time.
<JordanBrown>
I do not get mouseDoubleClickEvent when I right-double-click on the model, but I get it fairly reliably when I right-double-click on the background.
<InPhase>
JordanBrown: I had also switched to cout during the clean build. One of those fixed it. :) (Although I was doing the endl which is supposed to flush, and stderr is supposed to always flush on newlines... but *shrug*)
<JordanBrown>
Yes, as I said something seems to have (somehow) rudely set stderr to be buffered - and block-buffered, at that, not line-buffered like stdout to a terminal should be.
<InPhase>
Weird, and disruptive.
<JordanBrown>
Yes.
<JordanBrown>
but fprintf(stderr, ...); fflush(stderr); does the trick.
<InPhase>
Oh gees.
<JordanBrown>
You can tell that I'm a C guy, not a C++ guy :-)
<InPhase>
I double right clicked in the background, it immediately called mouseDoubleClickEvent, and it immediately caused the issue I couldn't reproduce.
<InPhase>
So I was failing because my aim is too good. *sigh*
<InPhase>
Apparently I missed twice in a very large number of attempts to click on the object. :)
<JordanBrown>
I think that part of the problem with reproducing it is that it isn't visible until a repaint. Depending on the details, triggering it may not immediately cause a repaint.
<InPhase>
Yeah, it's double click on the background, then rotate the object.
<InPhase>
I'll try to reproduce.
<InPhase>
Instant reproduce.
<InPhase>
This is reliable.
<InPhase>
Finally.
<JordanBrown>
I don't immediately see why it wouldn't happen when you double click on the object - I don't see anything in the selection magic that says "I have handled this event, don't handle it any more". But maybe it is very quickly popping the menu, the second click hits the menu, and very quickly pops it
<InPhase>
I did it a few times in a row to prove this is reliable.
<InPhase>
Yeah, I think it's the menu pop-up.
<JordanBrown>
down.
<InPhase>
I think because it puts up that menu at the first click, it never even gets processed as a double click by whatever is upstream.
<JordanBrown>
Don't know where double-click processing is done, so don't have a real theory.
<JordanBrown>
That is, double-click detection.
<InPhase>
Okay! So now we can at least both make it happen consistently. :)
<JordanBrown>
Did you look at my paste?
<InPhase>
Yep, still have it open.
<JordanBrown>
The big question for me at the moment is what causes the mouseReleaseEvents to run with a different GL context.
<InPhase>
Although I don't understand it yet, and I was struggling with getting to where I could even do tests to look at such things.
<JordanBrown>
because something that the double click event is doing is messing up that mechanism.
<JordanBrown>
Well, we know that it's the makeCurrent, but we don't know why double-left-click doesn't cause it too.
<InPhase>
There's a big warning flag to not call makeCurrent on a different thread from the context. But I've checked the context's thread and it matches.
<JordanBrown>
yes, I've slathered QThread::currentThread on my printfs, and they always match.
<JordanBrown>
It seems like it would be a good idea for Qt to assert that the thread calling makeCurrent is the one that "owns" the context. But I suppose that maybe they want to allow you to hand it off between threads, if you're careful.
<JordanBrown>
Or maybe they just don't want to spend the microsecond on the assert.
<InPhase>
I'm not seeing the context change. I assume you're printing the pointer returned by context()?
<InPhase>
But if they differ, that will be informative. They're defined slightly different.
<InPhase>
It would imply that a makeCurrent or a paint was called somehow from something with another context.
LordOfBikes has quit [Ping timeout: 256 seconds]
<JordanBrown>
I think that QOpenGLWidget::context() is the OpenGL context for this widget, as opposed to QOpenGLContext::currentContext(), which is the current OpenGL context.
<JordanBrown>
Presumably something sets them the same occasionally, but something could set them different too.
<InPhase>
So QGLView's context was always the same, and it calls makeCurrent() and it gets set to what its always was.
<InPhase>
BUT, something else has a different one.
<JordanBrown>
But the other mystery is that a double-left-click shows the same behavior... except that it does *not* change the context for the subsequent mouseReleaseEvent calls.
<InPhase>
The problem is one of two things then: Either QGLView is working with the wrong context from initialization/setup, or something ELSE is messing up the context and it just triggers as a problem during this makeCurrent when it gets set back.
<InPhase>
Yes, I'm also seeing double left click reproducing the output, but I do not see it messing up the display.
<JordanBrown>
oh, hmm. I'm only printing mouseReleaseEvent when it's a right click. I should print it all the time.
<InPhase>
I still do not really know what's wrong, but it feels like we're close now.
ghee has quit [Quit: EOF]
<JordanBrown>
Just to catch all of the mouse events, I added a printf to mouseMoveEvent. That was a mistake.
<InPhase>
lol
<JordanBrown>
A right double click doesn't always mess it up.
<InPhase>
JordanBrown: Well, even the currentContext thread checks out as stable during the context change: https://bpa.st/ZDUA
<InPhase>
JordanBrown: So whatever it is, is not a threading issue I think. It's just... another context from somewhere?
<JordanBrown>
yeah, I agree, much as I thought MT, I no longer do.
<JordanBrown>
It's juggling two contexts, one for normal operations and one for selection magic. I think it's sometimes mixing them up and doing selection magic using the normal-op context.
<JordanBrown>
makeCurrent seems to be how you change contexts. Unfortunately, Qt calls makeCurrent *a lot*.
<InPhase>
But contexts are supposed to flow from parents.
<InPhase>
So what do we have unparented?
<InPhase>
I cannot grep for Qt objects created with no parent...
<InPhase>
My grep powers have met their match when it comes to looking for the thing that is not written.
<JordanBrown>
So I added dumping the widget's context, context(). (Which is, I think, QopenGLWidget::context().)
<JordanBrown>
The normal case for a mouse event is that the current GL context is *not* the widget's context.
<JordanBrown>
and so selectObject is called with a context that is not the widget's context.
<JordanBrown>
In the bad case, the *one* following mouseReleaseEvent is called with the widget's context, and so selectObject is called with the widget's context, and does its selection magic in that context.
<JordanBrown>
Subsequent mouseReleaseEvents are back to being called with the "alternate" context, but by then the damage is done.
<JordanBrown>
I wonder if maybe somewhere inside Qt there is a loop that looks like
<JordanBrown>
set GL context
<JordanBrown>
while there are more events
<JordanBrown>
call event handler
<JordanBrown>
so that if there are two or more events queued, and one of them changes the GL context, the later ones see the change, but when you exhaust the queue it gets reset.
<JordanBrown>
It does seem like the right answer is that mouseDoubleClickEvent should restore the original context when it's done. It seems rude for it to change global state like that.
<JordanBrown>
But I am unsatisfied that I don't know how the mouse events come to be called with the alternate context in the first place.
<JordanBrown>
that's a manually cleaned up diff, showing only one of the three(?) points where it needs to restore the context.
<JordanBrown>
It seems like the *right* fix: mouseDoubleClickEvent() changed the context; it should restore it.
<JordanBrown>
Give or take the question of whether that's the right way to save and restore the context.
<InPhase>
Ah, I see.
<InPhase>
Well... That looks truly ridiculous but might work.
<JordanBrown>
Yeah, you would think that you could say "get context" and "set context".
<InPhase>
I'm going to ask for one thing. Add some good comments explaining what we know, what we don't know, and the tepid confidence in the correctness of this, so that the next person coming along with a better understanding feels confident obliterating this.
<JordanBrown>
But the only way to do it seems to be "get context, get surface associated with context, set context as current with surface".
<JordanBrown>
Good plan.
<InPhase>
Yeah, I had been hunting for a way to set the context, to try to see how it could get set, but I didn't see that one.
<JordanBrown>
Is there a way to ask git status to just give you a list of the changed files, without any decorations?
<InPhase>
git status | perl -ne 'print "$1\n" if /modified:\s+(.+)/'
<JordanBrown>
bleah
<InPhase>
:)
<JordanBrown>
git status -s | awk '{print $2;}'
<JordanBrown>
but bleah too.
<InPhase>
Ah, real answer: git diff --name-only
<JordanBrown>
thanks. Now the question is whether I'll be able to remember it.
<JordanBrown>
I use Mercurial every day, but git only every week or so.
<JordanBrown>
Less than, really.
<InPhase>
git_[tab][tab] on my system now suddenly has a git_modified_files
<JordanBrown>
:-)
<JordanBrown>
OK, one problem with that fix is that on its face it requires #include <QOpenGLContext>, and that whines that it is not compatible with GLEW.
<InPhase>
Oh, yeah. I was seeing that too.
<JordanBrown>
I don't mind that kind of whine for diagnostic builds, but I'd rather not add it to production.
<InPhase>
I bet you can fix it by hiding that in another cpp.
<InPhase>
I ignored it before because I was just testing, but I guess it matters for a fix.
<JordanBrown>
Yeah, true: have a helper function "change context and return previous context".
<JordanBrown>
And sneak it in somewhere else, or add a file for it (yuck).
<JordanBrown>
Don't really need oldSurface variable, just
<InPhase>
Probably it needs to go into a separate file, because all the obvious places seem to be either already toxically incompatible, or you'll be dropping a poison pill for the future. :)
<JordanBrown>
yeah
<InPhase>
I would ask again for a comment explaining this...
<InPhase>
Apology comments. Sometimes they're needed.
<JordanBrown>
It seems surprising that QOpenGLContext doesn't have a makeCurrent() that is equivalent to makeCurrent(ctx->surface()).
<JordanBrown>
yes, absolutely.
<JordanBrown>
also known as voodoo comments :-)
<InPhase>
"Beware of dragons, do not merge this file with others."
<JordanBrown>
Oh, yeah, that's another piece of the voodoo that needs to be documented.
<InPhase>
I'm closing out all of these windows. I will accept this as the best fix discernible for now.
<InPhase>
Or, duct tape patch at least.
<JordanBrown>
I'll put together a PR.
<JordanBrown>
Might be a day or two.
<InPhase>
Ping me when it's up and I'll give it a test and merge if it fixes it for me also.
<JordanBrown>
ok
<JordanBrown>
https://bpa.st/ZS5Q is the diff, without comments, before moving to a separate file.
<JordanBrown>
The big question for moving to a separate file is whether there's a straightforward way to get QOpenGLContext as an incomplete type without pulling in the header and causing the warning. It would be unfortunate to have to invent a new structure to wrap around it, or use cast evil.
<JordanBrown>
But right now I need to run an errand.
<InPhase>
You only need the pointer, so a declaration is sufficient.
<InPhase>
In fact it's already forward-declared for you.
<InPhase>
This was required for the classes that return a pointer of it.
<JordanBrown>
Did we ever get an issue filed for this?
teepee_ has joined #openscad
teepee has quit [Ping timeout: 268 seconds]
teepee_ is now known as teepee
<JordanBrown>
Is there a way to get cmake to regenerate its files (so as to add a new file) without blowing away the build directory? If I just run the same cmake command again, it fails complaining about GLEW_LIBRARY.
<peeps[zen]>
JordanBrown: you can try deleting CMakeCache file, and/or CMakefiles directory from within the build dir
<peeps[zen]>
not sure if either of those will save any time over a complete rebuild though
<JordanBrown>
Thanks. I will try that next time. For this time, I'm halfway through the full build.
<JordanBrown>
One might hope that it would, but it would depend on exactly how the dependencies are structure. My usual "make" includes the notion of recording the command used for the particular build action, and will redo it if the command changes - which means that you don't need dependencies in the
<JordanBrown>
then adding a file will tend to rebuild everything.
<JordanBrown>
Makefiles. But if you have dependencies on the Makefiles,
teepee_ has joined #openscad
teepee has quit [Remote host closed the connection]
<InPhase>
JordanBrown: src/RenderStatistics.cc is an example of a more current new file. You can add your own name to a new file, as shown there. The GPL works fine with this.
<InPhase>
Although in reality names at the tops of files are a sort of weird mess of ambiguity given how many people typically edit a file over time. Formally speaking, each edit made to a program documented by git is copyrighted by the person who made the edit, and re-released under the GPL upon submission.
<InPhase>
But it is weirder to put the Clifford/Marius notice at the top of a file that neither of them wrote. The copyright to it does not belong to them unless one formally reassigns it to them.
<InPhase>
Many authors having copyright is considered a strength under the GPL philosophy, because it means you cannot convert away from the GPL unless all the authors who contributed code that you want to convert agree to it.
<InPhase>
If some are unavailable to grant that agreement, those sections have to be rewritten, which is a tricky burden that gives the GPL its effective permanence.
<teepee>
I suppose that comes from some sort of CLA idea as there was a disucssion going MIT
<teepee>
pretty sure that ship has sailed, a simple SPDX identifier on top would probably be best
<InPhase>
Yeah. With 186 contributers by now, it would be a real burden to track down who all did what. :)
<InPhase>
That is, given the reasonable assumption that you would never get everyone to retroactively sign a CLA.
<teepee>
yup, there's a couple of discussions about that, e.g. in scope of gsoc but I don't think for each and every contribution
<teepee>
so I tend to think new library style code (like the svg import) can be slightly separated and go with MIT everything else just remains GPL2+ as it is
<InPhase>
Actually it would be an interesting feature to have a git blameeverybody
<InPhase>
Not just for this question, but for actually figuring out who did what with a line of code.
<InPhase>
Often I need to know more than who the last person was to touch a section of code.
<teepee>
3d code editor :)
<InPhase>
That's going to really strain the text() module.
<teepee>
like flying backward/forward through time and and see people come in moving code around
<InPhase>
:)
<InPhase>
I'd be willing to try it.
<InPhase>
Maybe put that VR technology to some better use than running into walls.
<J1A8462>
probably not easy to track after lines moved and text changed.. you would need some ID for a code command line
<InPhase>
J1A8462: Visual lines connecting it are what you need.
<J1A8462>
i mean you still have to determine what code is it after you insert lines before and after and between
<InPhase>
Yeah, you fly there and look at it.
<InPhase>
Although the real problem is that if you turn around to see changes in the other direction, everything is backwards...
<InPhase>
So maybe we'd need a mirror mode when going in the other direction. :)
<InPhase>
Instead of turning around by rotating, strafe left and right, and invert yourself axially.
<J1A8462>
so like layers and each change adds a layer on top and you can scroll through them
<J1A8462>
so like a sankey diagram but in Z direction
teepee_ has joined #openscad
<J1A8462>
InPhase have you ever used cryptpad or etherpad with the colors for user and the history slider ?
<InPhase>
Such a thing would be a special kind of annoying for any serious work, but it could be very helpful for some simple stuff, discussing small testcases, or teaching people things.
<J1A8462>
but the other (cryptpad) tools are also very nice
<InPhase>
My secret has been to select "Bash" or "Shell" for OpenSCAD syntax highlighting. It gets about as close to correct as anything I can find in the common choices.
<J1A8462>
just was wondering .. seems the preview is removed by that
<Friithian>
time to write an LSP :D
<J1A8462>
hmm dart highlighting look also nice
<InPhase>
J1A8462: Yeah, the preview disappeared when I did that. I guess what you were previewing there was a markdown rendering of your scad code. :)
<InPhase>
J1A8462: I was trying to figure out why the preview disappeared when I clicked that, and wasn't sure if it did for your end as well. But I guess it was the selection of a different language.
<InPhase>
Hmm. That Dart selection looks nice too.
<J1A8462>
wondering why dart knows cylinder and squares
<J1A8462>
probably JS needed to encrypt with the url key
<teepee>
´appropos cadhub, it's probably in dormant state, remains to be seen how that goes
<J1A8462>
hmm if openscad.org would have a WASM page that also accepts links of code - would be cool
ghee has joined #openscad
<teepee>
that would be cool, I think that would work with the current setup (github deployment)
LordOfBikes has quit [Quit: Ex-Chat]
LordOfBikes has joined #openscad
GNUmoon2 has quit [Ping timeout: 268 seconds]
GNUmoon2 has joined #openscad
GNUmoon2 has quit [Read error: Connection reset by peer]
GNUmoon2 has joined #openscad
ghee has quit [Ping timeout: 268 seconds]
ghee has joined #openscad
ccox has quit [Read error: Connection reset by peer]
ccox has joined #openscad
ccox has quit [Read error: Connection reset by peer]
ccox has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 268 seconds]
teepee_ is now known as teepee
ur5us has joined #openscad
<JordanBrown>
I want a time travel editor, so that I can easily go back in time and make changes to a previous revision, at least during development, so that I can have different features and "phases" that are separated into different revisions. Git has rebase -i and Mercurial has histedit, but they're still
<JordanBrown>
kind of awkward and some transitions (like moving a l
<JordanBrown>
ine from one revision to another) can be awkward.
<JordanBrown>
Pushed an update to that copyright notice.
<teepee>
ah, good, via force, so it's nice and clean :)
<JordanBrown>
Yep. Partially tidiness, partially habit from work where there's a "one changeset" rule. (Well, sort of. Multiple fixes in multiple changesets is OK.)
<J1A8462>
text(str(version())); gives me [2022,5] but when using that via command line i got an image with [2022,2] how is that possible?
<InPhase>
JordanBrown: I have a versionbackup command I wrote for which "versionbackup foo.scad" copies foo.scad into "./backup/2022-08-21_19-22-34/foo.scad" and "versionbackup -a" does the same for all files and directories other than backup itself. It's nice for just keeping around date-stamped backups of small scripts without messing with version control systems.
<InPhase>
JordanBrown: If I reach an epoch point, am working on something I don't want to break, or feel like I'm about to make changes I might want to walk back, I fairly habitually run that now.
<InPhase>
JordanBrown: It's not automatic, but it's low mental burden and I find it flexible.
<JordanBrown>
J1A8462: two copies of OpenSCAD installed, and getting different copies when using the two different ways of starting it.
<J1A8462>
JordanBrown damn thats it .. pfff
<JordanBrown>
InPhase: I don't mind using an SCM; I've been using Mercurial daily for >10 years and SCCS and CVS for many years before that. I'm not looking for capturing snapshots; that's easy.
<JordanBrown>
But when I'm working on project X, I may find bugs A, B, and C, and decide that some component needs have its formatting fixed up, and that something needs to be refactored, et cetera. I like to put each one of those changes into its own changeset, so that a reviewer (or subsequent engineer doing
<JordanBrown>
archaeology) can see that changeset 1 fixes bug A,
<JordanBrown>
changeset2 just rearranges whitespace, et cetera, rather than having all of them mushed together in one changeset.
<JordanBrown>
And I may find that I want to refactor stuff "before" work that I've already done, which is where time travel comes into it. I want to go back and refactor it in a changeset before the primary project changeset.
<JordanBrown>
I might have started out saying "I'm just making a few small style changes along the way, so I'll just include them in the primary changeset", and then later say "my few small style changes have turned into a lot of small style changes, so I now want to pull them into a separate changeset".
<JordanBrown>
Git's rebase -i and Mercurial's histed make that not-too-hard to do on a file-by-file basis (though it tends to be two steps to move a file from one changeset to another), but they don't have any automation for moving individual lines.
<JordanBrown>
Anyhow, to be clear this is just random conversation - I don't actually expect help in doing these things. I already know most of the existing tricks. It's just not as easy as I would like.