***DrPhil- is now known as Ratticus
***Ratticus is now known as JustorGX
<janneke>i would like to see some example code about pattern-matching, currying with goops? <janneke>(define ((a-is? class) object) (is-a? object class)) <janneke>and (match ... (('action (and (? (a-is? <trigger>)) (get! trigger))) ...) ***JustorGX is now known as lemur_with_banan
<mark_weaver>janneke: see the '$' syntax of match, e.g. (match x (($ <trigger> a b c) ...)) where a b c will be matched against slots 0, 1, and 2. <DeeEff>sup guilers. Does anyone know if there's a working swank server for guile-2.0? <DeeEff>hrm, doesn't seem to have what I'm looking for. Thing is I'm a vim user, which is fine with a generic SWANK server, but geiser is far too coupled to emacs, unfortunately. <ijp>I hear slime actually makes proper releases these days <daviid>mark_weaver: did you had a chance to look at the problem i mentioned recently? any idea? any thing i could do to provide more info? <mark_weaver>janneke: see the '$' syntax of match, e.g. (match x (($ <trigger> a b c) ...)) where a b c will be matched against slots 0, 1, and 2. <mark_weaver>daviid: can you remind me what problem you're referring to? <daviid>mark_weaver: i apologies in advance that i may have to leave the keyboard, not sure yet, but that's the case be back later or tomorrow of c0urse... <daviid>noe that the second trace is using 2.0.11.2-0ece4 [not guile 2.0.22 as i wrote by mistake in the log] <mark_weaver>daviid: strange. the error message indicates that '<' was called with #f as its first argument at ice-9/threads.scm:99, but there is no call to '>' near there. are you using the alternative implemention of par-map that I hacked up for you? <daviid>mark_weaver: i'm not sure anymore, i surely did 'git pull' and probably did not reinstall? how could i check <daviid>is the line mentioned in the error reliable? <daviid>note that the bug is systematic, but it occurs in a random way, which means that it occurs on different 'particles' [part og images] for different script occurrences, so i tend to beleive that it's not my code, but ... <mark_weaver>ah, it's probably one of the calls to '>' in 'touch', which is in ice-9/futures.scm <mark_weaver>the first argument to both of those calls is (%nesting-level), where %nesting-level is a parameter <mark_weaver>so I guess that (%nesting-level) is returning #f for you. <daviid>i confess i can't follow you here :) <mark_weaver>so (%nesting-level) accesses a thread-local variable, which _should_ always be an integer. <mark_weaver>it's defined in futures.scm as follows: (define %nesting-level (make-parameter 0)) <daviid>but not related to my code right [this #f stuff] <mark_weaver>which I guess is supposed to ensure that its initial value is 0 in all new threads, but I guess that's not happening properly here. <daviid>i'm facing the code now [futures.scm <daviid>note that i don't have nested par-map in this script, if that's helpíng to know <mark_weaver>the version of par-map I wrote didn't use futures, iirc. <mark_weaver>so it wouldn't run into this problem, but maybe another problem, dunno. <daviid>ah! I thought you pushed it at some point <mark_weaver>but still, I'd like to get to the bottom of this. (make-parameter 0) ends up calling 'new_fluid' with 0 as the 'init'. <daviid>i'm scared that i do not run your par-map <mark_weaver>daviid: no, there are potentially some advantages to using futures for this. <mark_weaver>though my implementation of 'par-map' uses simpler machinery, so that's an advantage I guess. <daviid>i'm confused then, is this par-map free of the original bug tracking y9ou did for me ? <mark_weaver>it's not clear that anything is wrong with the existing 'par-map' in guile git. <daviid>the thing is i do git pull from time to tiem, and forgot to reapply maybe <mark_weaver>I just wrote a simpler one for you to rule out the possibility that something was wrong there. <daviid>ok, so i keep running the distro one then? <mark_weaver>but as I recall, we established that the problem was not in guile but rather in your subprocesses sometimes stalling. <mark_weaver>daviid: for now, I'd recommend sticking to guile stable-2.0 git. <daviid>i think you're confusing with the 'sleeping' problem, which i still don't know and still occurs very regurlarly, the original problem i reported also occured in your computer and civodul as well, so something as been debuged at that time... <daviid>it makes my life easier and also my scripts are good tests for guile anyway :) <mark_weaver>hmm, it may be that the SCM_BOOL_F in 'scm_i_make_initial_dynamic_state' (fluids.c) should be SCM_UNDEFINED instead. <janneke>mark_weaver: wow ... somewhat like records? ... is that documented somewher <mark_weaver>janneke: (Guile Modules > Pattern Matching) in the guile manual mentions the syntax as being for records. however, internally it uses 'is-a?' to check and 'slot-ref' to retrieve the slots. <mark_weaver>so it's more general than is obvious from the manual. <mark_weaver>janneke: there are more complete docs for 'match' in the source code itself, module/ice-9/match.upstream.scm <mark_weaver>janneke: patches for the manual are always welcome :) <mark_weaver>one useful feature of 'match' that's not documented in our manual is the (=> failure) syntax, which allows you to simulate failure from within the body of a clause. <mark_weaver>(i.e. proceed to the next clause, as if this one hadn't matched) <mark_weaver>janneke: the only thing to be careful of is that the slots are matched by slot index, so beware that if the order of the slots changes, or if you insert a slot, the patterns may need to be updated. <mark_weaver>if you are matching a class that inherits other classes, etc, it may be too fragile to match based on slot indices. <mark_weaver>but we use this quite a bit in guile's compiler to match tree-il nodes. <daviid>mark_weaver: i have to go now, let me know... and thanks for your help of course <mark_weaver>daviid: I think that SCM_BOOL_F in 'scm_i_make_initial_dynamic_state' (fluids.c) should be SCM_UNDEFINED instead. that might fix your problem. <janneke>mark_weaver: yes, that's possibly fragile <janneke>so i'm not sure if it's wise to use slots for matching <janneke>possibly it's better not to use them if you only want to bind/access them <mark_weaver>janneke: anyway, you can still use ($ <trigger>) to match that type <mark_weaver>janneke: there are tradeoffs. the advantages of being able to match by position might justify locking down the slot numbers of at least some initial slots, if it's a simple type that doesn't inherit anything else with slots. <mark_weaver>hmm, there are definitely thread-safety problems associated with the garbage collection of fluids. <lemur_with_banan>mark_weaver, do you know what the rationale behind non continuable exceptions exactly is? <mark_weaver>because there's no need to copy the stack before unwinding. <dje42>I'm getting reports of gdb hanging when configured with guile. ***brendyyn is now known as brendyn
<mark_weaver>well, the other thing is that if the exception was generated by C code, we may not have a way to resume from that point. <dje42>I'm guessing libgc is somehow colliding with gdb's SIGCHLD handling. <lemur_with_banan>I was more hoping there was a semantic rather than implemtnation / performance reason to it. <mark_weaver>dje42: the bug report says that the same problem happens with gdb 7.7 <dje42>I know. There may be two bugs here, or it may be a red herring. <dje42>The reports may not necessarily recognize that it's really a separate issue that is a race condition, and only *think* --without-guile fixes things. <mark_weaver>if the same bug happens with 7.7, I guess I don't see how guile could possibly have anything to do with it. <mark_weaver>hmm, comment 6 says that 7.7.1 works and 7.8 locks up, but the original bug report says that 7.7 fails also. <dje42>I need to reconfirm people are actually seeing the problem with 7.7, and it's not a typo. <mark_weaver>and comment 16 says that he sees the problem with a gdb that doesn't even have the --without-guile option <dje42>He thought --without-guile was a gdb option, not a configure option. <mark_weaver>but I see that several others seem to indicate that the bug goes away when built without guile. hmm <dje42>Anyways, I'm just giving y'all a heads up. If anything comes to mind, give me a shout. <mark_weaver>dje42: is libgc linked with gdb if you pass --without-guile to configure? <dje42>Nope. At least I don't expect it to. <mark_weaver>dje42: can you reproduce the problem on your system? <dje42>And I've put a fair bit of time into trying. <dje42>A lot of the reports are from arch-linux users. I may try it in a vm if needed. <dje42>Yep. Both at home and at work.