IRC channel logs


back to list of logs

***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>now i have
<janneke>(define ((a-is? class) object) (is-a? object class))
<janneke>and (match ... (('action (and (? (a-is? <trigger>)) (get! trigger))) ...)
<janneke>which feels very clumsy
***JustorGX is now known as lemur_with_banan
<mark_weaver>bah, neither janneke nor sneek is here.
<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?
<mark_weaver>DeeEff: not that I know of, but I'd recommend taking a look at Geiser <>
<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>heya guilers
<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: yes, just a sec
<daviid>here: at the end of the log
<daviid>i send a paste og a fulltrace here:
<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 [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>here is the threads.scm extract ...
<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>(i.e. based on a fluid)
<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.
<daviid>i should
<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 totally independent of that.
<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>ok i'll stick then
<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)
<janneke>mark_weaver: how nice, all this!
<mark_weaver>janneke: you're welcome!
<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: okay, ttyl!
<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>but that depends on the details of your situation
<mark_weaver>hi zacts
<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>they are more efficient to invoke
<mark_weaver>because there's no need to copy the stack before unwinding.
<lemur_with_banan>Ah yeah, that makes sense I guess
<lemur_with_banan>THat's really the entire thing though?
<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.
<mark_weaver>wingo is a better person to ask about this, though.
<dje42>I'm guessing libgc is somehow colliding with gdb's SIGCHLD handling.
<lemur_with_banan>mark_weaver, wingo doesn't seem to be around a lot though.
<lemur_with_banan>But I mean in the r6 sense
<lemur_with_banan>which defines a distinction between continuable and non continuable
<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
<mark_weaver>lemur_with_banan: I don't know off hand
<dje42>I know. There may be two bugs here, or it may be a red herring.
<mark_weaver>did gdb 7.7 have guile support?
<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.
<dje42>See comment 17.
<mark_weaver>but I see that several others seem to indicate that the bug goes away when built without guile. hmm
<mark_weaver>oh, I see
<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>Alas no.
<dje42>And I've put a fair bit of time into trying.
<mark_weaver>is your system multi-core ?
<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.