IRC channel logs


back to list of logs

<ijp>that isn't one of nils holm's is it?
<ijp>ah, it is
<DeeEff>daviid: is there an html pack of the updated version Sketchy-Scheme?
<ijp>I recall he went in a huff some years back over a german law, and stopped maintaing his stuff
<daviid>DeeEff: i don't know, but as an intro for no programmer, the html version i mentionned here is fine
<DeeEff>as a funny aside, I searched for the book through my university library, and one of the results to come up was "Men and masculinities in South India"
<DeeEff>that's relevant
<ijp>the structure and interpretation of indian societies
<ft>Would something like this be welcome? - I think it's useful to have those available.
<ijp>weird, I'm trying to experiment with cps terms at the repl, and when I write function foo in (guile-user) it fails to give the correct answer on pattern matches, but if I write it in (language cps) (through ,m) it works fine
<ijp>ah, I see the problem, PEBCAK
<ijp>I have a binding for $ which is obviously not free-identifier=? to the one match uses
<nalaginrut>morning guilers~
<davexunit>mornin nalaginrut
***petercom1and is now known as petercommand
<lloda>why do assoc and assoc-ref take their arguments in different orders? this is mad :-/
<nalaginrut>lloda: that's my question too...but it's impossible to change it now...
<saul>Is there a Guile implementation of SRFI-115? (or similar)
<nalaginrut>oops, irregex became srfi-115, great news
<nalaginrut>but I think we don't have it now
<nalaginrut>saul: for now, you have to use irregex, I do so in my project
<civodul>Hello Guilers!
<civodul>irregex is now +/-
<nalaginrut>civodul: is anyone working on srfi-115 for Guile? ;-)
<taylanub>lloda: nalaginrut: assoc-ref is in the -ref family which take their arguments in the order 'collection, key/index', whereas assoc descends from older Lisps and has (I think) always taken arguments of the order 'key, alist'
<taylanub>also looks like assoc-ref isn't in SRFI-1
<nalaginrut>another potential portable issue, although trivial
<civodul>nalaginrut: apart from you? ;-)
<civodul>i would really like it
<dje42>civodul: question: Do you know much about guile 2.2's "finalizer thread" ?
<nalaginrut>oops, the ball back to me huh? ;-P
<civodul>dje42: i know the principle, that it's a thread that runs the finalizers :-)
<nalaginrut>considering Artanis uses irregex heavily, it's reasonable for me to think about it...
<civodul>dje42: what do you want to ask?
<dje42>Heh. My question is whether one is able to disable it, or more generally
<dje42>whether guile will provide a "no internal threads" mode.
<dje42>*I* don't want it, but some in gdb-land do.
<civodul>there's this thread:
<nalaginrut>I think you're requesting a (disable-threads) on the fly
<civodul>dje42: i think eli was concerned about what *users* may do with threads, no about what Guile/libgc do internally
<civodul>(as long as they don't mess up)
<dje42>I think the concern is threads in general.
<civodul>hmm that's not my interpretation
<civodul>and i think that requiring users to configure libgc + guile --without-threads is unreasonable
<dje42>no disagreement there
<dje42>Though one can disable libgc threads with GC_MARKERS [IIUC].
<civodul>i think the way forward is to document the fact that threads in gdb user code are not supported
<civodul>and then make sure that, if there are threads for internal use, they don't mess up with gdb
<civodul>which i think you've achieved already, no?
<taylanub>late correction: yesterday I mentioned the "Ritchie hack"; apparently the correct name is "Thompson hack". I seem to have replicated a mistake someone made on the ML
<dje42>I kinda don't want to be in the position of having said that when power users know what they're doing and will happily use threads anyway.
<nalaginrut>taylanub: LOL
<civodul>dje42: the only way to completely forbid threads would be by requiring (provided? 'threads) => #f at configure time, but we don't want that
<civodul>so AFAICS, the only thing we can do is to say "don't do that"
<civodul>i mean, it's probably similar with Python, isn't it?
<dje42>The python docs are too silent on the matter.
<dje42>All it says is it's hard to make file descriptors close-on-exec in a thread safe manner.
<lloda>(string->number "-0.8 ") -> #f
<lloda>isn't that a bit too strict?!
<taylanub>lloda: wouldn't say so .. you could use `read' for that.
<civodul>if -0.8 were a number, we would know
<civodul>oh, i hadn't noticed the trailing whitespace
<civodul>lloda: per "(r5rs) Lexical structure", this is correct
<dsmith-work>Happy Friday, Guilers!!
<civodul>Happy Friday!
<civodul>howdy, dsmith-work :-)
*dsmith-work is in *way* too early
<dsmith-work>srfi-115 Cool
<JudgeDreadlock>dsmith-work, are you Scottish perchance?
<dsmith-work>JudgeDreadlock: Not that I remember
<JudgeDreadlock>dsmith-work, blasted curses
<JudgeDreadlock>what are you then?
<JudgeDreadlock>dsmith-work, ahhh
<JudgeDreadlock>Do you know of anothert scott except ijp?
<ijp>waxysubs`: I added tail patterns enough for srfi 64, but I see the r6rs also has
<ijp>(<pattern> ... <pattern> <ellipsis> <pattern> ... . <pattern>), and AFAICT that's ambiguous in general
<ijp>and where it isn't, I suspect you need to backtrack
<waxysubs`>ijp: I think it's not actually ambiguous, because if you look carefully at the description of that pattern type in R6RS-lib, it says that the final tail pattern must match the "nth and final cdr", i.e. the final cdr must not itself be a pair.
<waxysubs`>i.e. the nth cdr must not be a pair, is what I mean.
<waxysubs`>so you know exactly how many list items must be matched by the part after <ellipsis>.
<waxysubs`>(note that for the other pattern type involving a tail pattern, with no <ellipsis>, it merely says "the nth cdr", as opposed to "the nth and final cdr")
<ijp>I see, then this is my own mistake
<ijp>this also removes the backtracking objection
<ijp>waxysubs`: good news, all I had to do was 1) get rid of the listp check 2) change length to safe-length, and 3) change the tail-pattern-p predicate
<davexunit>hey guilers, trying to brainstorm how to write a macro.
<davexunit>hard to explain, though.
<davexunit>I want to identify expressions that are a particular type of object.
<davexunit>and then wrap that expression in another form when the matched expression is substituted with something else.
<davexunit>so if I had (+ 1 foo), and foo was the special object, the result would be something like (lambda (foo) (+ 1 foo))
<davexunit>I'm explaining this horribly. need to get things straight in my own head before I talk more.
<civodul>maybe it's something that cannot be done at macro-expansion time
<civodul>because there's insufficient info on whether 'foo' is the special object
<davexunit>yeah, that sounds likely.
<davexunit>I guess I can just introduce a quote/unquote thing instead
<davexunit>but it would still be hard to identify a subexpression as quoted and then expand the parent expression
<davexunit>at least, I'm not sure how to achieve that
<civodul>maybe you need to come up with a reduced case