IRC channel logs

2014-01-29.log

back to list of logs

<nalaginrut>morning guilers~
<nalaginrut>I realized that my 'either' proc is actually AMB, (define (either . args) (shift k (for-each k args)))
<nalaginrut>(reset (let ((i (either 1 2 3 4)) (j (either 'a 'b 'c 'd)) (format #t "~a~%" (cons i j)))
<nalaginrut>hmm...should be this:
<nalaginrut>(define (either args) (shift k (for-each k args)))
<nalaginrut>(reset (let ((i (either '(1 2 3 4))) (j (either '(a b c d)))) (format #t "~a~%" (cons i j))))
<nalaginrut>frankly, our par-map is very slow
<mark_weaver>what's your test case?
<nalaginrut>I'm playing with matrix, so I tried a vectors-ref
<nalaginrut>(map (lambda (v) (vector-ref i)) vl) is very fast
<nalaginrut>seems no need to use par-map
<nalaginrut>well, I'm reading your srfi43 patch, then suddenly want to play matrix ;-P
<mark_weaver>well, it's not cheap to create threads and do the necessary thread synchronization. using it when the procedure does something as simple as 'vector-ref' is always going to be a losing proposition.
<mark_weaver>it's simply a misuse of 'par-map'.
<nalaginrut>ah ,alright
<mark_weaver>we could do better than we currently do, that's certainly true. but even if we did the best that we possibly could, it would not be appropriate for something like that.
<nalaginrut>is it any further plan to make it faster? or it's the usage of it
<nalaginrut>ok
<nalaginrut>nothing more, just mention ;-)
<nalaginrut>mark_weaver: IIRC, you once said current parameters implementation is not good for pthread?
<mark_weaver>I don't remember saying that.
<nalaginrut>so it's safe to user it in pthread context?
<nalaginrut>s/user/use
<mark_weaver>yes
<nalaginrut>ok
<mark_weaver>parameters or fluids are both effectively thread-local variables.
<mark_weaver>(which also can be temporarily set within a dynamic extent)
<nalaginrut>nice, I haven't looked into it, but I guess it's based on NPTL stuffs?
<mark_weaver>however, I admit I don't quite understand what you mean by "in pthread context"
<nalaginrut>(I mean under Linux environment)
<nalaginrut>mark_weaver: 'in pthread context" here means, when I used both pthread and parameter in certain code
<mark_weaver>can you explain what you intend to use them for?
<nalaginrut>I'm concerning a scheduler for my server based on delimited-continuation
<mark_weaver>personally, I try hard to avoid parameters and fluids, because they don't mix well with lazy evaluation.
<nalaginrut>but I think it's not cool to take advantage just one core, so I think the simplest way is to open 4 threads(for example I have 4 cores), and each handle an independent queue
<mark_weaver>well, you can also use lexical variables for that.
<mark_weaver>and I'd recommend using lexical variables if you can.
<nalaginrut>my first thought is to use parameters to hold the queue for each thread
<mark_weaver>I recommend avoiding parameters/fluids whenever you can do so without great pain.
<mark_weaver>and in this case, I see no reason to use parameters.
<nalaginrut>yeah, that's the advice I want to hear ;-D
<mark_weaver>my advice is to make a lexical variable within the thread.
<nalaginrut>but how can I make it thread local?
<nalaginrut>if avoid to use parameter
<mark_weaver>well, something like (call-with-new-thread (lambda () (define queue '()) <code-for-thread>))
<mark_weaver>so 'queue' is a lexical within the thread.
<nalaginrut>well, I think you mean to put scheduler in a thread, so there could be a lexical scope queue
<mark_weaver>right
<nalaginrut>my original thought is a global scheduler
<nalaginrut>alright, I'll give it a try
<nalaginrut>thanks ;-P)
<mark_weaver>np!
<nalaginrut>maybe I should do it in a simpler way in the beginning , my original thought is a global scheduler with 4 queues globally, so if one thread become starve, it can take some jobs from others
<nalaginrut>mark_weaver: btw, the bot is done, but I'm waiting for potluck this year ;-P
<mark_weaver>nice!
<wingo>moin
<nalaginrut>hay
<nalaginrut>haya
<jemarch>hi
<taylanub>I thought `syntax-case' was kind of a local maxim, but looks to me like SRFI-72 is a clear improvement over it. Have there been thoughts of supporting it ? I guess it would be a pretty big change ?
<taylanub>local maximum* (?)
<taylanub>(Well, SRFI-72 defines syntax-case as a library form actually.)
<wingo>who cares?
<wingo>perhaps that is a rude thing to say :)
<taylanub>I thought the Guile Scheme code-base uses syntax-case quite often; would you say that most of the uses wouldn't benefit from the SRFI-72 improvements ?
*taylanub reads ML archives ..
<wingo>those archives are missing comments by flatt, dybvig, and clinger
<taylanub>Any place I can find those ?
<wingo>good question, i don't know if they commented
<wingo>but any discussion is incomplete without their comments :)
<taylanub>oh, heh :)
<jmd>I'm trying to use string-match
<jmd>But is seems to always return #f
<taylanub>jmd: What did you do, what did you expect, what did you get ? :)
<taylanub>Wild guess from lack of info: you didn't use enough backslashes. :P
<jmd>Hmm possibly...
<taylanub>Once, I had a backslash. I thought, "I know, I'll use regexps!" Now I had four backslashes.
<jmd>(m (string-match target (string-append "\\\\(.*\\\\)" s "\\\\(.*\\\\)" ))
<jmd>Should match anything s anything shouldn't it?
<jmd>or is it a greedy match?
<taylanub>Regexp * is greedy by default in all regexp styles I know.
<taylanub>Not sure what exact regexps Guile supports.
<taylanub>Manual says POSIX ERE, where you'd use () and not \\(\\), so comes out you had too *many* backslashes after all. :D
<jmd>Oh Thanks.
<taylanub>Also, if you string-append a regexp, then of course the string-holding variables you use (e.g. `s' here) will also be interpreted as part of the regexp.
<taylanub>Apparently (ice-9 regex) has `regexp-quote' so you could use (regexp-quote s) in place of s.
<taylanub>Emacs has this neat `rx' macro, I wonder if Guile has something analogous.
<taylanb>jmd: I'm here now in case you had said something. (My home-server connection is down again. :\\)
<jmd>I didn't say anything. Thanks.
<jmd>Somebody once showed me a cute shebang line so that a file could be called either with guile or with sh
<jmd>Can anyone think of what it might have been?
<dsmith-work>jmd: Maybe what's at the top of the guild script ?
<jmd>The which script?
<dsmith-work>meta/guild
<dsmith-work>Basically #!/bin/sh \\n .. exec guile ... \\n !#
<jmd>But then you can't call it with guile.
<dsmith-work>#! ... !# is a comment
<jmd>Oh.
<jmd>... but not with bash :
<jmd>/bin/sh: \\n .. exec guile ... \\n !#: No such file or directory
<dsmith-work>Bash will run it until the exec, at which point bash is replaced by guile
<dsmith-work>jmd: Don't look at my pseudo code, look at meta/guild
<jmd>I don't have that file
<dsmith-work>Then /usr/local/bin/guild
<dsmith-work>Or more accurately ${prefix}/bin/guild
<jmd>I'll have to install it.
<dsmith-work>It's in your guile source tree in the meta directory
<dsmith-work>It's inetalled when you install guile
<jmd>It must have gone wrong when mine was installed.
<Muhammad_Ahli>Say, it has come to my attention that in guile [syntax-case '(a b (c d)) [] [[first second third] #'third]]] simply works
<taylanub>FYI we generally don't use [] in guile.
<Muhammad_Ahli>It does not report on its input not being a syntax object, and even though it should return #'third, which osensibly should always be a syntax object, it just returns the list (c d)
<mark_weaver>it's acting properly.
<mark_weaver>syntax-case matches its first operand against the pattern [first second third]
<Muhammad_Ahli>mark_weaver, and it should work on bare lists as well?
<mark_weaver>so 'a' gets bound to the pattern variable 'first', 'b', is bound to 'second', and (c d) is bound to 'third'.
<mark_weaver>so when you do #'third, since 'third' is a pattern variable, the thing it's bound to gets substituted.
<Muhammad_Ahli>But in this case #'third evaluates to what is not a syntax object seemingly.
<Muhammad_Ahli>Guile uses psyntax right?
<mark_weaver>yes, it does.
<taylanub>Could it be that a symbol is technically a symbol-constant syntax object without annotation ?
<mark_weaver>although we branched off of the upstream psyntax many years ago.
<Muhammad_Ahli>The r6 specs seems to at least intuitively imply that #'<exp> should always be a syntax object.
<mark_weaver>bare symbols are considered identifiers.
<mark_weaver>although they lack the contextual information normally associated with syntax objects.
<Muhammad_Ahli>scheme@(guile-user)> (identifier? 'a)
<Muhammad_Ahli>$1 = #f
<Muhammad_Ahli>The machine has overthrown its creator, became self aware with a mind of its own I'm afraid.
<mark_weaver>heh, well, yes, the exported 'identifier?' is more strict, although the 'id?' used internally in psyntax accepts bare symbols as identifiers as well.
<Muhammad_Ahli>And thisis standard compliant?
<mark_weaver>anyway, 'syntax-case' really doesn't care what #'third is bound to.
<mark_weaver>it only breaks things apart as much as it needs to.
<mark_weaver>well, R6RS is the only scheme standard that has syntax-case. I don't recall what it says about this.
<Muhammad_Ahli>Well, the r6 standard implies that (syntax <template> always results into a syntax object.
<Muhammad_Ahli>Which it doesn't in that case
*mark_weaver looks
<Muhammad_Ahli>If the syntax-case form is in tail context, the <output expression>s are also in tail position.
<Muhammad_Ahli> it's the line under that line
<Muhammad_Ahli>Oh wait
<Muhammad_Ahli>I misread
<Muhammad_Ahli>I thought the 'syntax' was the return type fo the epxression
<mark_weaver>'syntax' will always return a syntax object if the pattern variables are themselves bound to syntax objects.
<mark_weaver>we cannot invent contextual information from thin air.
<mark_weaver>I don't see where R6RS promises that 'syntax' will return a syntax object, but if it does, then you need to make sure that the first argument to 'syntax-case' is a syntax object.
<mark_weaver>you passed bare symbols to 'syntax-case', which is not generally how it's used.
<Muhammad_Ahli>Yeah, I suppose.
<mark_weaver>that caused pattern variables to be bound to bare symbols (and a list of bare symbols).
<Muhammad_Ahli>I was just a bit puzzled by that syntax case doesn't reject it.
<Muhammad_Ahli>Though I suppose you can use it to destructure lists, might as well just call it 'match' then or something like that.
<mark_weaver>well, for efficiency reasons, it does not traverse the entire structure you give it just to make sure there are no bare symbols.
<mark_weaver>in fact, psyntax only lazily breaks about syntax objects.
<mark_weaver>and that's important when you are dealing with very large operands passed to macros.
<mark_weaver>(for example an entire file wrapped within some macro use)
<Muhammad_Ahli>mark_weaver, well, would you say it is supreme bad practice to use it to destructure lists?
<mark_weaver>yes, i would
<mark_weaver>it's a misuse of 'syntax-case' to work with anything other than syntax objects.
<Muhammad_Ahli>As would I, that is why I was a bit intrigued by that it didn't report an error on not using a syntax object on it.
<mark_weaver>well, it so happens that in psyntax, syntax objects are (sometimes) implemented as normal lists and datums, with symbols replaced by identifiers (currently represented as vectors in Guile, but we'll probably change them to records at some point).
<mark_weaver>I say "sometimes" because they are lazily broken apart. in some cases, it's a syntax-object record/vector that contains an entire compound datum (e.g. nested lists with symbols).
<Muhammad_Ahli>mark_weaver, on another note though, do you know of a portable way to implement a syntax? function
<mark_weaver>not portably, no.
<mark_weaver>it's not guaranteed to be a disjoint type, anyway.
<mark_weaver>actually, a syntax-object can be any datum at all, with one exception: it should not have bare symbols in it.
<mark_weaver>well, any datum that 'read' can return, anyway.
<civodul>Hello Guilers!
<dsmith-work>civodul: Hey hey!