IRC channel logs
2023-08-20.log
back to list of logs
<rlb>ACTION really doesn't like the fact that guile will run a stale .go file if compilation of a newer .scm fails -- assuming he hasn't been misunderstanding. <rlb>I *never* want that. <daviid>RhodiumToad: i pushed a long serires of patches to the g-golf devel branch, the last one being a (preliminary) port of the adwaita 1.2.2 demo, a wip, currently it has the adw1-demo window, header bar, primary-menu (and their actions are supported, inspector, preferences and about), as well as the Welcome and Leaflet (GtkStack) pages <daviid>RhodiumToad: now, i am tracking two bugs, severe bugs (segfaults) - i was wondering if you could pull those changes, try and possibly help me ... if you have a bit of free time ofc - let me know if your 'in' ... i'll give ytou some more context <daviid>yes, i would release as soon as i fix those bugs <daviid>RhodiumToad: great, tx! first, let1's see if you can reproduce, let me know when you will have grabbed the atest and configure/make/make install the latest g-golf (devel branch) <daviid>when you will have done this, you then cd <the g-golf git clone devel branch dir>/examples/adw-1, then ./adw1-demo.scm <daviid>which may either work, raise an exception, or segfault - but we don't want to deal with this one yet :) - if that happens, just launch ./adw1-demo.scm again, till the adw1-demo wondow is presented ... then <daviid>ok the when you have an adw1-demo window, select the primira-menu->Preferences' - which should either work or segfault, we are tracjinkg the degfault (not exactly random but sometimes it work, sometimes it doesn't ... <RhodiumToad>I've got a bunch of stuff rebuilding right now thanks to the fact that freebsd ports just picked up a new glib version, and a ton of stuff has that as a dependency <daviid>RhodiumToad: could you join #gtk, i am gona ask for some hint there as well ... <daviid>RhodiumToad: to give you some more context, everything in the adw demo uses templates, except the inspector and the about window - the prefecences template is defined in xamples/adw-1/adw1-demo/ui/preferences.scm [used to generated the ui file] and the code in examples/adw-1/adw1-demo/preferences.scm <RhodiumToad>so far, I get a segfault, bus error or illegal instruction before the demo shows any window about 2/3rds of the time, <lilyp>rlb: the issue is trickier than that, it's about the timestamps of the files themselves <RhodiumToad>but if it gets to showing the main window, I haven't yet had it crash when opening the preferences window <lilyp>success rate of 33%, good enough :) <rlb>lilyp: well, unless I'm missing something, I think if decides it needs to compile foo.scm and that fails, I just want it to stop. <lilyp>rlb I think we're talking about quite different things here <lilyp>If compilation fails, it fails, nothing else <RhodiumToad>if compilation fails, it doesn't stop guile from actually executing the file anyway <cbaines>why does Guile call the readlink system call so often? <cbaines>I think this is a known issue, but I can't find anything about it <cbaines>I think it's being called on directories in the guile load path <daviid>RhodiumToad: i pushed a patch, a review of the %instance-init-func - i doesn't fix the 'preferences window' opening 'random' segfault, but now the gdb bt is different - i kept the address pointer calls, but commented, i am convinced, even more after this patch, that it is not the problem, that the problem is in the execution of the %instance-init-func generated closure ... could you pull and see if you can reproduce, thanks <daviid>RhodiumToad: not sure, but i suspect that what triggers the segfaukt is the (apply init-template (list g-inst 'skip-prepare-gi-arguments)) call, line 442 in the newly patched (g-golf hl-api gobject) module <daviid>hum, that is difficult, the 'optimization' of skipping the prepare-gi-arguments is also because at the time init-template is called, the goops proxy instance doesn't exist yet, not necessarily at least, see the lines below, that creates it only if ... <rlb>ACTION ❤️'s better UTF-8 test coverage (bug fixes to the banch coming up) <rlb>janneke: certainly. I think it's getting closer to the point where we could more seriously test it against "real code", though of could try that at any time. And if anyone does, I'd love to hear how it goes. It'll be easier for (C) code that doesn't use any scm_i_* calls. <rlb>I suspect any attempts right now will most likely flush out additional bugs, but later I'd like to see how it affects performance. <cow_2001>Are there any good examples of GOOPS being used? I need to wrap my brain around it.