<davexunit>(slot-ref foo 'some-unbound-slot) calls slot-unbound with only foo as an arg, the name of the slot that was unbound is not included. ***sneek_ is now known as sneek
<daviid>davexunit: there are three methods, one of which specializes on the class, the istance and the slot-name <daviid>davexunit: but you're sayig that one isn't called i guess, didn't try :) <daviid>davexunit: in goops.scm, (slot-unbound class obj slot-name) is called within the core of the inner no-slot def, not within the core of the inner have-slot def, which seems like a bug to me <davexunit>daviid: yeah it seems like a bug, but it could be as-designed? <daviid>davexunit: if you compare the def of solt-re and slot-set! in goops.scm, you can see that the no-slot inner def of slot-set! is correct, the one of slot-ref isn't, i think - then, the def of has-slot in slot-ref doesn't look right either <davexunit>I don't feel like going down this rabbit hole but it does seem like something that could be improved. <daviid>the other strange thing is that in this no-slot inner def in slot-ref, slot-missing is called as if it returns a value - and i can't find that it does :) in any of its methods <davexunit>unrelated, but one of these days I'd like to try implementing CLOS's :before, :after, :around methods in goops. <daviid>I just think you found a bug, and that slot-ref should be patched <abralek>I am curious, is there any projects which use 8sync? <leoprikler>At least not according to Guix: No dependents other than itself: guile-8sync@0.4.2 <wingo>when do we get to remove libtool from our build system? :) <wingo>is it actually a pain point for anyone? <dsmith-work>wingo: I had some difficulties with it at one point. Nicely solved by just removing the .la file(s). <dsmith-work>The .la file was pointing to the wrong places, IIRC. <wingo>yeah afaiu all distros remove the .la files <wingo>so we should just stop generating garbage :P <wingo>ideally gnu would have replaced autotools at this point <civodul>wingo: it cannot just be "removed" tho, it has to be replaced <civodul>saying this as a packager who's had occasions to wish Libtool had been used :-) <civodul>to be fair, some of it can be plain removed, such as .la files <zzappie>I am also curious. People seeem to devide to haters and lovers of autotool. And lovers are usually people who build package <zzappie>Were there any atempts to reinvent it? :) <morganw>I think the actual problem with autotools is that there looks to be an issue in finding people to work on them. One suggestion that has come up is for it to require GNU Make (since this is pretty much available everywhere) but I don't think anyone can agree on something to replace m4. <daviid>davexunit: did you see my msg? i think i fixed slot-ref ... but wanted you to check ... <civodul>zzappie: there's no shortage of free build systems these days, but most are broken in their own different ways <civodul>Meson seems to be doing better than the average <civodul>that's going beyond the Libtool discussion though <sneek>davexunit, you have 1 message! <zzappie>morganw: maybe define m4 language for guile and have option to write autoconf macros in scheme? :) <davexunit>I'll try to find some time to fix it. need to get into a state where I build guile from source and try it out. <daviid>wingo, following a attempt to fix slot-ref, i also posted a msg here earlier today for you ... if you have a few min ... let me know what you think, tx <morganw>zzappie: given there is already a GNU Make+Guile, plus all the build tooling for Guix that someone can point at, you would think it would be a logical candidate... <daviid>davexunit: you may as well recompile just that proc on the fly ... and try it ... but as/when you wish/can of course, no problem <leoprikler>fwiw I had an easier time using make plus handwritten m4 at a workplace, that felt too fancy for autotools rather than make+guile on pretty much any machine I had so far