IRC channel logs

2021-04-07.log

back to list of logs

<davexunit>slot-unbound is not very useful in goops :(
<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.
<dsmith>sneek: botsnack
<sneek>:)
<dsmith>goodbot
***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?
<davexunit>if it is, I just don't like the design. :)
<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
<daviid>*slot-ref
<daviid>*have-slot (not has-slot)
<davexunit>yeah, I noticed that
<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>add that to the list of goops oddities
<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
<daviid>davexunit: that would be nice
<daviid>sneek: later tell davexunit here is a fix, could you try it - https://paste.debian.net/1192569/
<sneek>Will do.
<daviid>wingo: could you look at this (oop goops) slot-ref fix - https://paste.debian.net/1192569/ - if ok, i'll file bug-report with a proper patch
<dsmith-work>{appropriate time} Greetings, Guilers
<pkill9>hi
<dsmith-work>Am I back?
<dsmith-work>Yes!
<lampilelo>or is he?
<dsmith-work>Maybe?
<lampilelo>so are you back or not?
<dsmith-work>Hope to be. connectivity issues
<abralek>Hi guile
<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 trolls
<dsmith-work>wingo: As soon as possible?
<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>But then I was cross-compiling.
<dsmith-work>The .la file was pointing to the wrong places, IIRC.
<wingo>yeah afaiu all distros remove the .la files
<wingo>fedora, debian, even guix
<wingo>so we should just stop generating garbage :P
<wingo>ideally gnu would have replaced autotools at this point
*wingo grumble
<Noisytoot>What's wrong with autotools?
<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
<civodul>(and support for AIX 5 and Tru64)
<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>:-)
<civodul>Meson seems to be doing better than the average
<civodul>that's going beyond the Libtool discussion though
<davexunit>daviid: no I missed it, sorry.
<sneek>davexunit, you have 1 message!
<sneek>davexunit, daviid says: here is a fix, could you try it - https://paste.debian.net/1192569/
<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.
<davexunit>rather, to try the fix.
<daviid>davexunit: sure
<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