IRC channel logs

2023-08-21.log

back to list of logs

<daviid>cow_2001: imo, this is a excellent example to look at - https://git.dthompson.us/starling.git/tree/
<daviid>cow_2001: it actually is an 'Object-oriented game engine for Guile', and his author is a goops wizard
<daviid>sneek: goops?
<daviid>cow_2001: might read this nice tutorial as well https://www.wedesoft.de/software/2014/03/02/oop-with-goops/
<daviid>sneek: goops-tutorial?
<sneek>I could be wrong, but goops-tutorial is https://www.wedesoft.de/software/2014/03/02/oop-with-goops/
<daviid>ah, i thought so :)
<cow_2001>RhodiumToad: I don't know.
<cow_2001>daviid: Thank you.
<daviid>cow_2001: welcome
<cow_2001>"However one thing I don’t like about Scheme is that there are different function names for each type of arguments. E.g. adding numbers is done with +, adding lists is done with append, and adding strings is done with string-append." Strange. That's one of my favourite bits.
<daviid>RhodiumToad: unlike i said above, the problem might not be with the (apply init-template (list g-inst 'skip-prepare-gi-arguments)) call -
<daviid>but i still struggle to find what causes the segfault
<daviid>RhodiumToad: the difficulty here is that %instance-init-func is called upon template 'subclass' (by GLib/GObject, Gtk in fact but ... not g-golf), so when we launch the demo, it calls %instance-init-func <adw-demo-window>, which triggers a call to %instance-init-func <adw-demo-page-welcome> and %instance-init-func <adw-demo-page-leaflet>
<RhodiumToad>yes, and?
<daviid>RhodiumToad: well speaking loudly, i still fail to identify the cause of the segfault - but here is a version (not gona push it) that helps to track these calls - https://paste.centos.org/view/4b70b828 - if you paste this and run the make danse, you should get those traces as well
<RhodiumToad>I've not yet managed to reproduce the failure on the preferences option
<RhodiumToad>either I get a core dump on startup, or it works
<daviid>in the gdn bt, i can see a pattern, it either is like the one we were looking at yesterday, or the one i pasted here today - https://paste.centos.org/view/918a2327 - this one shows the libguile code that is being run just before the segfault
<daviid>RhodiumToad: did you pull the lates today?
<RhodiumToad>not yet, waiting on rebuilding libs with debugging enabled
<daviid>oh ok - actually the paste here above will do, it has the changes and the print calls - https://paste.centos.org/view/4b70b828
<daviid>RhodiumToad: what i do here, to try to get it to segfault on the preferences window select, is i make a 'false' change in the scm files, ./adw1-demo/window.scm, the ./adw1-demo/preferences.scm - i add and delete a space, to force recompilation, it doesn't always work, but ... sometimes it does ...
<daviid>RhodiumToad: i would be interested to know you can make some out of this bt https://paste.centos.org/view/918a2327 -
<RhodiumToad>"proc" there is clearly a garbage pointer
<RhodiumToad>and it came from here: user_data=0x80, which is also nonsense
<RhodiumToad>so that looks to me like the closure was either improperly created, or it has been stomped on since creation
<daviid>ok
<daviid>RhodiumToad: one thing i note is it either work - then it present the preferences window, and you may close and call it again 100's of times, it will never segfault - or it segfault at the first attempt
<RhodiumToad>I still have never had it segfault on the preferences window
<daviid>could you patch the %instance-init-func using the code above and try again ... also making those 'fake' changes in the scheme code ...
<daviid>RhodiumToad: you might as well provoque a fake change in the adw1-demo/ui/preferences.scm, then in that directory run make, then launch the app again ...
<RhodiumToad>I've tried a whole bunch of things
<RhodiumToad>only place it crashes is on startup, after the first or sometimes second %instance-init-func call
<daviid>RhodiumToad: too bad, here it is a nightmare to try to run aninstance that works :) [ i wanted to trace the (%g-inst-construct-g-type) calls for a case that worked ..]
<RhodiumToad> https://dpaste.org/kX8vi <-- fairly typical crash
<daviid>RhodiumToad: that crash 'pattern' shows it crashes calling the 'next template initialization' which if it worked would display ;; %instance-init-func <adw-demo-page-welcome> ...
<daviid>this means that in this pattern, the pointer to the instance-iit-func for the <adw-demo-page-welcome> is/was corrupted, i think
<daviid>RhodiumToad: and this makes me think maybe you could help me to try to run the demo, but forcing a lower lever optimazation guile default compilation flag
<daviid>i never (had to) change the default guile's compilatyion flags :)
<daviid>i can try no-autocompile, in the adw1-demo.scm script, would that also affect any modules it will use, i assume yes - then clear my cache ofc ... let's see
<RhodiumToad>I don't think optimization at the guile level will make any difference at all
<daviid>RhodiumToad: though using --no-auto-compile i can't get it to segfault anymore
<RhodiumToad>initially, or on the preferences option?
<daviid>on noe
<daviid>i can't get it to segfault anymore
<daviid>nor initially, nor the preferences window
<RhodiumToad>which compiled files did you remove?
<daviid>all
<daviid>all of the demo
<RhodiumToad>if anything, it makes the crashes worse for me
<daviid>i cleared my .cache/guile entirely - the only compiled file it uses are those g-golf core files ..
<RhodiumToad>now it sometimes crashes even before the first %instance-init-func
<daviid>that's really strange - maybe a guile version diffrerence then
<daviid>here i manually install guile, and regularly update, currently, running GNU Guile 3.0.9.90-9d927-dirty
<daviid>be right back ...
<RhodiumToad>woot. finally. I can get useful debug info now
<RhodiumToad>#1 0x0000000800375618 in scm_call_n (proc=proc@entry=0x100, argv=argv@entry=0x7fffffffc2c0, nargs=<optimized out>) at vm.c:1614
<RhodiumToad>0x100 is not likely to be a valid proc
<daviid>RhodiumToad: but what does this tells us? i tracked the instance-init pointer(s), result of the %instance-init-func call prior to g-type-register-static-simple are (always) valid
<daviid>RhodiumToad: also, fwiw, i keep a reference to both the class-init-func and instance-init-func pointers, here - https://git.savannah.gnu.org/cgit/g-golf.git/tree/g-golf/hl-api/gobject.scm?h=devel#n268 - more specifically lines 276-281, so for an adw1-demo (or any g-golf app) running session, these are not gc'ed, and iiuc, nor is unreachable the code it poits to (?)
<RhodiumToad>give me a while to look into what's going on here.
<daviid>RhodiumToad: yes, thanks for your help - let me add one more thing (need to try once more, then i'll write here)
<daviid>RhodiumToad: fwiw, here - https://paste.centos.org/view/c85b6e60
<RhodiumToad>ok. some closure is definitely being freed prematurely.
<RhodiumToad>but only sometimes
<RhodiumToad>see https://dpaste.org/X55Xp
<RhodiumToad>that's freeing an ffi closure at 0x800bdb350
<RhodiumToad>but that closure ends up called from g_type_create_instance later
<RhodiumToad>hence, crash
<daviid>ok, so as i just said, just keeping a ref to the procedure->pointer isn't suffcient
<RhodiumToad>it's definitely supposed to be sufficient
<daviid>i mean i said i thought it was sfficient but it isn't
<daviid>ah ok
<RhodiumToad>though the details are somewhat complex. the result of procedure->pointer is registered in a weak table with the closure as a value
<RhodiumToad>so as long as the pointer is referenced from elsewhere, the weak table entry is not removed, and the closure remains in existence
<daviid>right - what i could try, to make some progress and confirm your analysis, is to make the class-init and instance-init lambda top-level define procedures
<RhodiumToad>so the pointers are stored in slots of the class?
<rlb>Interesting - after reworking the tests to run everything in parallel, the popen-child.scm issue resurfaces: 6069e9733163cf802e806bfa55cb4fcc54fc6ac7
<rlb>i.e. it hangs at 100% cpu
<daviid>RhodiumToad: yes here - https://git.savannah.gnu.org/cgit/g-golf.git/tree/g-golf/hl-api/gobject.scm?h=devel#n268 - more specifically lines 276-281
<daviid>RhodiumToad: and the slots are defined here https://git.savannah.gnu.org/cgit/g-golf.git/tree/g-golf/hl-api/gtype.scm?h=devel#n91 lines 100-101
<daviid>unless a bug in my code, like a cache validation problem - in the %instance-init-func code - https://git.savannah.gnu.org/cgit/g-golf.git/tree/g-golf/hl-api/gobject.scm?h=devel#n430 - the goops proxy class for the g-class pointer is cached and retreived, line 436 -
<daviid>it is cached at <gtype-class> initialization time - https://git.savannah.gnu.org/cgit/g-golf.git/tree/g-golf/hl-api/gtype.scm?h=devel#n115 - line 144-145
<RhodiumToad>anyway, I'll keep looking at this as time permits
<RhodiumToad>since i have something i can consistently reproduce now, I should be able to track down at least one bug
<daviid>RhodiumToad: ok, thanks - i'll try to outsource the code of the %instance-init-func and see - will ping you if it seems to solve the problem
<daviid>i am doing this right now, when done, 'll try, then push and ask you - as time permit ofc - to pull and try ... many thanks again
<daviid>RhodiumToad: i pushed a fix, when time allows, see if it fixes the problem on your side as well, here so far so good
<daviid>let me know ... thanks
<daviid>RhodiumToad: i also just pushed a fix to the gtk-4/peg-solitaire.scm example, so you should no longer need to patch it yourself in freebsd
<rlb>Hmm, surprised srfi-13 string-any seems to specify a boolean for string-any, rather than the matching char (say for a charset predicate). Seems like the former'd be more useful.
<rlb>I have it returning the char in the current branch, but suppose I should change it.
<wingo>civodul: hey. for -Wunused-toplevel and srfi-9 -- should we try to fix this?
<civodul>wingo: -Wunused-module you mean?
<wingo>no, i mean for the define-inlinable accessors
<civodul>ah, yes
<civodul>i've always wanted to fix that
<wingo>the "value" variant often ends up unused and causing a warning
<wingo>so, an idea. embed metadata in the generated lamdba
<civodul>more generally warnings about "unused" macro-introduced bindings
<wingo>(lambda () #((maybe-unused)) body ...)
<civodul>ah sure, that'd be awesome
<wingo>wanted to know what you thought about the idea, and if you liked it, if there was a better way to do it
<wingo>#((disable-analysis unused-toplevel foo-bar)) or something...
<civodul>there's currently no way to associate metadata like this, right?
<wingo>yes of course there is :)
<wingo>already is there
<civodul>oh?!
<wingo>:)
<civodul>how does that work? :-)
<wingo>gets embedded in the binary
<wingo>psyntax.scm:1972
<wingo>a generalization of the docstring facility
<civodul>wat
<wingo>:)
<civodul>unbelievable
<civodul>how did i miss that?
<wingo>well. clearly i didn't document it well ;)
<civodul>heh
<civodul>so yes, a generic "ignore-warning pragma" of sorts would be perfect
<civodul>and no, i can't think of another way to address those unused-toplevel false positives
<wingo>ok let's call it ignore-warnings then
<civodul>sounds good
<wingo>and pass some number of analysis names as args
<civodul>+1
<civodul>-Wunused-variable has false positives too for macro-introduced bindings (like 'match')
<civodul>initially i thought we could add metadata to the binding itself
<civodul>anyway, one thing at a time i guess
<wingo>is that for lexicals too?
<civodul>yes
<wingo>haha that's your problem then ;)
<civodul>like 'match' introduces a binding called 'failure', and it always shows up
<wingo>ACTION not bothered by unused lexicals ;)
<civodul>heh :-)
<wingo>ok, i will see about the srfi-9 thing. conveniently it defines its own define-inlinable
<civodul>old code...
<viaken>Does Guile/Scheme provide something like with-open-port? I see call-with-port, but it doesn't close in case of errors.
<lilyp>viaken I think it should close on errors after garbage collection
<rlb>viaken: I don't know of one offhand, and so you'd have to dynamic-wind or similar, though I'd like one since I almost never want to leave the ports to gc, and it's convenient.
<rlb>I'd be happy to port with-final if we wanted it :) https://gitlab.com/clj-murphy/murphy (a generalization of with-open -- already did port it, more or less, for lokke).
<wingo>mew
<haugh>vlaken, I think with-intput-from-port and with-output-to-port have dynamic-wing builtin
<haugh>but of course these use current-{input,output}-port
<haugh>s/wing/wind/
<haugh>and now I see you're trying to open an ephemeral, not use an existing