Re: assertion error "PRI(owl) >= priority" otp.c line 248

> of the list... whoops. Totally not my fault. The mailing list is > obviously inserting bugs in patches as they pass through it. Luckily, the relevant info is in the headers: X-List-Server: Minimalist v2.5(3) (Good Bowl) Do you want me to file the bug report?

Re: assertion error "PRI(owl) >= priority" otp.c line 248

On Thu, Jul 11, 2019 at 08:15:36PM +0200 I heard the voice of Rhialto, and lo! it spake thus: > > I do notice that SetFocus() duplicates a lot of work that the > FocusIn and FocusOut event handlers do. Yeah. Almost-duplicated code makes me a bit grumpy. I spent a minute or two thinking about

Re: assertion error "PRI(owl) >= priority" otp.c line 248

On Thu, Jul 11, 2019 at 11:16:31PM +0200 I heard the voice of Rhialto, and lo! it spake thus: > > but I did find some other scenario that does weird things :-( [...] > so maybe that is a sign of a loop in ctwm indeed. It might be > getting confused while getting the OTP stack in order with

Re: assertion error "PRI(owl) >= priority" otp.c line 248

On Thu 11 Jul 2019 at 20:15:36 +0200, Rhialto wrote: > Indeed, I can't reproduce it anymore now with this scenario. I'm pretty > sure it is the same bug that happened "randomly" before. but I did find some other scenario that does weird things :-( It's not an OTP assertion failure but some sort

Re: assertion error "PRI(owl) >= priority" otp.c line 248

> I mean, I'm actually assuming an _array_ would work better than > either. But if I can't dream up insane anti-solutions that would > _technically_ work, what's the point of weekends anyway? Good point. This said, the current way windows and turned into TwmWindow structs has been "efficient

Re: assertion error "PRI(owl) >= priority" otp.c line 248

>> Hmm... so is it because we changed PRI(owl) without changing the >> OtpWinList accordingly, [...] > > Yes[0]. The PRI() of the transient changed when the main window > gained focus, but it's still down among the normal windows where it > was prior. Looking at OwlEffectivePriority which in

Re: assertion error "PRI(owl) >= priority" otp.c line 248

On Mon, Jul 08, 2019 at 11:08:25AM -0400 I heard the voice of Stefan Monnier, and lo! it spake thus: > > Actually, what we obviously need to do is get rid of TwmWindow > > structs wholesale, just embed SQLite, and store our runtime data > > there; then the indexes will find them for us! > > I

Re: assertion error "PRI(owl) >= priority" otp.c line 248

On Mon, Jul 08, 2019 at 11:04:10AM -0400 I heard the voice of Stefan Monnier, and lo! it spake thus: > > Hmm... so is it because we changed PRI(owl) without changing the > OtpWinList accordingly, [...] Yes[0]. The PRI() of the transient changed when the main window gained focus, but it's

Re: assertion error "PRI(owl) >= priority" otp.c line 248

> Actually, what we obviously need to do is get rid of TwmWindow structs > wholesale, just embed SQLite, and store our runtime data there; then > the indexes will find them for us! I don't follow. Wouldn't a hash-table work just as well? SQLite seems like a rather expensive way to implement a

Re: assertion error "PRI(owl) >= priority" otp.c line 248

>> From what I remember of the time I wrote and debugged OTP, these >> problems were invariably due to things like calling RaiseWindow >> instead of OtpRaiseWindow. > > That would lead to assertion failures where it compares against the X > window stack. These troubles are triggering a bit

Re: assertion error "PRI(owl) >= priority" otp.c line 248

On Sun, Jul 07, 2019 at 10:35:01PM +0200 I heard the voice of Rhialto, and lo! it spake thus: > > An obvious change here would to link all transients for a window to > that window. Well, we have a link that direction, via TwmWindow->transientfor (though that's more expensive than ideal, since

Re: assertion error "PRI(owl) >= priority" otp.c line 248

On Sat 06 Jul 2019 at 23:34:07 -0500, Matthew D. Fuller wrote: > Sigh. The whole way we look for the transients is wonky, because of > the assumptions it makes about where they already are. So we just > have to expand it and search the whole thing. So, new iteration: the An obvious change here

Re: assertion error "PRI(owl) >= priority" otp.c line 248

On Sun, Jul 07, 2019 at 09:05:02AM -0400 I heard the voice of Stefan Monnier, and lo! it spake thus: > > From what I remember of the time I wrote and debugged OTP, these > problems were invariably due to things like calling RaiseWindow > instead of OtpRaiseWindow. That would lead to assertion

Re: assertion error "PRI(owl) >= priority" otp.c line 248

> So, the crash isn't necessarily about where the window is in the X > stacking order, it's about where it is in the OtpWinList chain. >From what I remember of the time I wrote and debugged OTP, these problems were invariably due to things like calling RaiseWindow instead of OtpRaiseWindow.

Re: assertion error "PRI(owl) >= priority" otp.c line 248

> See if you can work out how to reproduce it at will and try it > against the new patch. (... and now that I carefully planned to add the following before I sent the mail, and then completely didn't...) The MonitorLayout config var I just landed may be helpful in this; a hardcoded

Re: assertion error "PRI(owl) >= priority" otp.c line 248

On Mon, Jul 01, 2019 at 07:36:23PM +0200 I heard the voice of Rhialto, and lo! it spake thus: > > Intersting! My theory so far was that *during* the change of focus, > the window depths might be inconsistent. But after > OtpRestackWindow()ing the newly focused window, it should be > finished, and

Re: assertion error "PRI(owl) >= priority" otp.c line 248

On Sun 30 Jun 2019 at 18:36:20 -0500, Matthew D. Fuller wrote: > > The change (or lack thereof) in SetFocus() makes no difference at > > all in either case for me. Which seems a strange; a fairly small > > amount of thinking on the matter _does_ suggest it's a thing that > > should be needed, but

Re: assertion error "PRI(owl) >= priority" otp.c line 248

> The change (or lack thereof) in SetFocus() makes no difference at > all in either case for me. Which seems a strange; a fairly small > amount of thinking on the matter _does_ suggest it's a thing that > should be needed, but somehow... isn't? I'll have to think more on > that. FWIW, I

Re: assertion error "PRI(owl) >= priority" otp.c line 248

On Sat, Jun 29, 2019 at 03:02:30PM +0200 I heard the voice of Rhialto, and lo! it spake thus: > > Looking at my test case (Xine), it has indeed a small window with > playback controls, and it is also a transient of the main window > (fullscreenable). Ah, well, see? If you just stuck with mpv or

Re: assertion error "PRI(owl) >= priority" otp.c line 248

On Wed 26 Jun 2019 at 21:56:07 -0500, Matthew D. Fuller wrote: > So, the solution to _a_ problem (maybe not yours) is that we need to Looking at my test case (Xine), it has indeed a small window with playback controls, and it is also a transient of the main window (fullscreenable).