IRC channel logs


back to list of logs

***catonano_ is now known as catonano
<daviid>roptat: I am a bit late :), but wrt to your multithreading guile and single threaded SDL, you might want to take a look at guile-async2, which offers exactly that, but for Gtk (which is single threaded as well ...) and see how it's done/snarf ideas to do that using fibers ...
<daviid>rlb: it occurs to me, just 'now', incidentally, that (gnome gobject generics) does a (define-method (equal? (o1 <gobject>) (o2 <gobject>)) ...), so may because equal? becoes a primti-generic once (oop goops) is used, unlike what needs to be done for guile core procedure (such as connect, in the same (gnome gobject generics) module), and just that (no #:replace, #:re-export ...) just adding the method you need, after importing (oop
<daviid>goops), may 'simply' do what you are expecting ... worth a try
<rlb>So far, it seems like right it works "fine" if I only try to extend equal? for new types, so I've just reworked everything to do that, and I just avoid equal?, i.e. use a new name, for anything that needs "full" goops functionality. Whether or not there's a bug, in 2.2 don't know, but I'm just avoiding the issue for now.
<rlb>"right now"
<daviid>rlb: I think if you 'just' add your equal? methods, after importing (oop goops), you are safe to use equal?
<daviid>to use and rely
<rlb>I'm not sure -- I'll have to double-check, but I think I found that it wont' work if you want to override an existing specialization, mingle your new type with existing types, or add a new arity. I mean it'll work within your module, but you can't export it in a way that others will "see".
<daviid>ok, i didn't know you wanted to redefine existing applicable methods ... neither why that does not work, so you're probably better usig another name indeed ...
<rlb>I think it may have been supposed to work, at least that's what the docs sound like iirc.
<rlb>but maybe the docs need adjustment
<rlb>See my followup here and Mikael's reply for some related bits:
<daviid>did see those emails
<rlb>Ahh, ok, then yeah, the main thing I'd tried to do was something like (define-method (equal? (x <new-type>) (y <pair>)) ...) and couldn't find a way to export it such that other modules could use that specialization.
<daviid>rlb: i bet if you just define-method, modules that import your's will see it/them, don't know
<daviid>rlb: not sure, jut wanted to point to this guile-gnme example, and guile-gnome works with 2.2 and 2.9 - but i didn't specifically try to call its equal? o1 o2 method either, so don't know 'for sure'
***janneke_ is now known as janneke
***ng0_ is now known as ng0
<wingo>good morning, guile
<heisenberg-25>Any graph manipulation libs in scheme that you know?
<wingo>weinholt: i added hungry-eol-escapes and documented lack of unicode escapes in symbols
<wingo>so, r6rs is ready to go i think. i should have a crack at r7rs now
<weinholt>wingo, sweet
<jcowan>Very sweet
<wingo>omg i just found a delicious bug
<wingo>related to mutation of quoted lists passed as arguments to define-module*
<wingo>gross stuff!
<daviid>rlb: fwiw, i can confirm that the way guile-gnome does 'things' wrt adding method(s) to primitive-generics, and those being seen/available by other moduless does work, here is a tny example
<daviid>rlb: completing the above, listing the primitive-generic 'content'
<rlb>Yes, it's fine if you're defining it for a new type, but not if you're defining it for existing types (and maybe combinations of new and existing types iirc).
<rlb>At least if I recall what I found correctly.