***adhoc_ is now known as adhoc
<nalaginrut>mark_weaver: heya, long time no see your greeting ;-P <mark_weaver>(although I've been answering questions on channel quite a bit) <mark_weaver>hi tupi! I've ordered a gluglug x60, so that I'll be a position to help with the gnome bindings at some point. <mark_weaver>btw, it appears that 2.0.10 will be released fairly imminently: within a couple of days. <mark_weaver>(I know I've been talking about 2.0.10 for ages, but this time I really mean it :) <mark_weaver>b4283: thanks! what kind of system was that on? (distro and architecture) ***ijp` is now known as ijp
<civodul>wingo: thanks to mark_weaver, it looks like we'll be able to release 2.0.10 by Wed. <wingo>yeah, but i can't complain :) <wingo>mark_weaver does his best hacking right before a release, so a prolonged pre-release has worked well for guile ;-)) <wingo>i just fixed stack overflow for good in master, i think <wingo>there is no limit by default to the stack, though you can impose one with call-with-stack-overflow-handler <saul>wingo, when Guile performs a call/cc, does a copy of the return stack get stored to heap? <wingo>guile implements call/cc via stack copying <saul>Isn't that a rare approach for Schemes? (not complaining, just trying to understand some things) <wingo>chez scheme does it, though they copy lazily (only when control flow returns past the call/cc) <wingo>i think gauche copies but i don't recall <saul>So for delimited continuations, is only the continuation chain from after the call/cc copied to heap? <wingo>delimited continuations are interesting because they can be present multiple times on the control stack <wingo>calling a delimited continuation *composes* with the current continuation <wingo>(unlike call/cc, which throws away the current continuation) <wingo>so reinstating a delimited continuation is in general a copy <saul>wingo, thank you for the explanation. I had missed entirely that aspect of delimited continuations (I was thinking it was just a memory-saving technique). <wingo>the general axes are composable vs non-composable, and delimited vs non-delimited <wingo>standard scheme call/cc is non-composable non-delimited <wingo>some schemes provide a delimited call/cc (a call/cc that only captures up to a certain point) <wingo>and all composable continuations are delimited <Madsy>If I want to iterate over the result of a function (f) until it returns false, what's the most idiomatic approach in Guile? <Madsy>(do ((i (f) (f) )) .. works I suppose, but I'm not sure how pretty that is <wingo>dunno :) i never use do; i never remember how it goes <wingo>(let lp () (and (f) (lp))) is what i would do :P <saul>Madsy, do you otherwise need the result of (f)? <saul>wingo, what does the % indicate in: (% (baz) (lambda (k) k)) <Madsy>saul: Yeah I do, that's why do seemed like the best fit so far. <wingo>saul: it's pronounced "prompt" -- a pun on the tcsh prompt <Madsy>saul: My overall goal is to iterate over the result of a guardian, and clean up the objects it returns <wingo>(let lp () (and=> (g) (lambda (o) (clean-up o) (lp)))) <saul>Madsy, I tend to use named let for all my iteration. It's more code, but generally easier to follow. <wingo>though i get occasional loop envy from the racketeers <dsmith-work>NEWS has been updated. Smells like a release is immanent. <mark_weaver>wingo: fantastic work on stack overflows! I'm really excited about guile master :) <wingo>and thank you for all the awesome 2.0 hacking! <mark_weaver>I probably wouldn't use the word "awesome" to describe it, but stuff that needs to be done anyway :) <wingo>but yes, you were totally right that the limit needed to go away <wingo>i think i shouldn't have to touch it again <mark_weaver>I'm really happy with the new stack handling in master. In many ways, it's my favorite feature of master. <wingo>the one open question would be whether to install a handler at the REPL -- i punted on the issue for now <wingo>s/handler/limit and handler/ <mark_weaver>the thing is, the REPL isn't just for writing code and debugging. it's also for doing real work. on the other hand, one thing you can be sure of at a REPL is that a human is there and can retry something if there's not enough stack space. <mark_weaver>(well, maybe not "sure", but a reasonable assumption) <wingo>handlers can allow the computation to proceed with more stack space <wingo>they can print out a warning and continue, etc <wingo>but then i thought "why bother" -- we don't currently warn about the heap growing, and anyway you can ctrl-c at any time <wingo>we could have a handler check for loops in the call graph <mark_weaver>right, I still come back to my belief that stack and heap should be treated the same. <wingo>it makes sense to throw an exception on stack overflow, and allow the program to handle it <wingo>it does not make sense to do so for exceeding a memory limit <mark_weaver>I saw that observation in your blog post, but I don't see why you think that. <mark_weaver>why does it not make sense to throw an exception of memory exceeded? <wingo>(the reason being that the propagation of the exception will free stack, whereas allocating the exception will take memory, and not necessarily free significant amounts of memory) <mark_weaver>oh, I don't know, if the memory is held by intermediate stack frames, then it _will_ free memory. <wingo>well there are two cases, really -- one where you really reach the limit, the maximum limit, and you have to do an unwind-only exception <wingo>and one where you reach a user-imposed limit <wingo>in the latter case you can do whatever <wingo>in the former you need to abort the process somehow <wingo>maybe i am confusing things, though <mark_weaver>that's one case where I think there's room for improvement. I think there would ideally be a stack reserve, so that the stack overflow exception needn't be unwind-only. <wingo>what would you do when you run out of stack reserve? <wingo>(that's what we currently have in 2.0 and it's not reliable) <mark_weaver>now, when the overflow happens, you have to release the reserve, and then the user-specified overflow handler might bungle things up and hit the hard overflow limit, in which case you still need to do the unwind-only exception. <mark_weaver>but in the common case, you could handle the exception in the normal way. <mark_weaver>I dunno, maybe it's not worth the added complications. <wingo>user handlers only run on user-imposed limits <wingo>unwind-only exceptions only run when you fail to grow the stack <wingo>or reach the C recursion limit <mark_weaver>I think the way you have it now in master is more than sufficient. really excellent, actually. <wingo>you're probably right that it could be better, but i wanted to err on the side of caution wrt unwind-only exns <wingo>but perhaps there is a nice fix there <mark_weaver>the reserve stuff could optionally be implemented on top of what's currently there, as a nicety. <wingo>you could grow the stack when you are within X% of the limit or something <wingo>and throw unwind-only exceptions only when X is 0 <mark_weaver>speaking of python, there's an article on LWN (subscribers-only until Thursday) about how Python considers Date objects to be false if they correspond to some Midnight in UTC. So terrible... <mark_weaver>this behavior is causing code to intermittently fail at various times (depending your time zone). <mark_weaver>how anyone ever thought that was a good idea is beyond me. <mark_weaver>wingo: fwiw, I would make the reserve be a fixed amount of space, rather than proportional to the current stack size. <mark_weaver>wingo: btw, in the NEWS, I wasn't sure how to justify the deprecation of scm_c_program_source. The rationale you gave in the commit log was that it has no internal users, but it's not marked as an internal function. <wingo>i searched on gitorious and github <wingo>and didn't find external ones either <wingo>and the interface it needs is different in master <wingo>so that's why it's deprecated in stable-2.0 <wingo>the portable interface is scm_procedure_source <wingo>(scm_c_program_source being introduced in 2.0) <mark_weaver>ah, now that's a good justification. but I'm curious, why can't the scm_c_program_source API be implemented in master? what's missing? <wingo>the "ip" parameter has a different type in general, and the complexity model is different in master <wingo>anyway it should have been an internal api :) <civodul>and then i'd be happy with the release <mark_weaver>I wish we had a build report on OSX, but I'm not going to worry about it. they can patch things up if needed. I agree that things are looking good for a release. <civodul>yeah, which is quite an achievement already :-) <civodul>i don't have easy access to OSX here <civodul>but Hydra says it's OK anyway, right? <mark_weaver>hydra.nixos.org successfully built 950a on darwin, but I don't know how close that is to what people will be using on homebrew. <mark_weaver>hydra is a bit behind; it hasn't built much beyond 950a. <mark_weaver>(for the last few days it seems to have been overloaded) <mark_weaver>anyway, 950a is probably close enough for a good test. f1a1326 is the only thing since then that i could imagine breaking anything. <civodul>yeah, i think we're on the safe side <civodul>i'll see if we can cheat with the hydra queue <civodul>in the meantime, if you want to start with NEWS, i can continue when i get back to keyboard later <mark_weaver>I wouldn't worry about it. the bigger question in my mind is how diverse hydra's tests really are. <mark_weaver>civodul: did you not get my email? I pushed a first draft of the NEWS. <mark_weaver>I could work on it some more, but I could use some input on how things should be organized. ***cky944 is now known as cky
<mark_weaver>hmm, I wonder why civodul was able to connect to freenode via tor, but I cannot. <didi>What's the recommended machinery to run async subprocesses? I'm seeing `open-pipe*' but I can't seem to find a way to control the subprocess. <didi>mark_weaver: Kill it or know if it's done. <mark_weaver>sorry, have to go afk, but 'close-pipe' calls 'waitpid' and returns the status code, which can be interrogated with status:exit-val etc. <didi>`close-pipe' doesn't seem to be appropriate for what I need. <didi>Hum. Maybe I can cook something with threads and `open-pipe*'. <didi>The use case is this: I want to launch N async subprocess and exit when one of them terminates, returning the last outputted line of this subprocess. <antoineB>hello is it possible to know all the binding at top level? <ijp>pretty sure we covered this the other day <antoineB>(define (defined-names module) (hash-map->list (lambda (k v) k) (module-obarray module))) <ijp>and if you want imports, you'll also need to search the module-uses list <ijp>antoineB: every binding is in some module, so yes <antoineB>guile emacs provide an elisp function "eval-scheme" <antoineB>but from the evaluated code i can't have access to any elisp function <antoineB>so i was wondering in wich world those elisp function lives? <ijp>guilemacs, last I checked, didn't use guile's elisp implementation <ijp>it just replaced bits of C <didi>wingo: Nice post. I'm excited to see the stack limit going away. <antoineB>is it possible to use binding defined in elisp language from scheme language? <civodul>mark_weaver, wingo: mutex_lock(&NEWS.lock) *wingo looking over the last month's stable-2.0 changes that he's been ignoring; (system base types) looks nice :) <wingo>master's assembler could use it *wingo pretends he hacks on stable-2.0, pushes a wee fix *civodul adds a NEWS entry <civodul>wingo: i left you 3 XXX to fix & remove :-) <civodul>well, actually just one needs fixing <civodul>the other two can be removed, i think <civodul>mark_weaver: congrats on the great work on that file! *wingo fixed the scm_c_program_source XXX <civodul>mark_weaver: i think it's time for "make distcheck" *mark_weaver reads the latest commits *civodul awaits mark_weaver's (preferably green) light <civodul>i distcheck then upload somewhere for you to double-check? <mark_weaver>well, I'm not sure that double-check is even needed. I might try compiling on a fast machine, but you could do that just as easily. <civodul>well yeah, distcheck will rebuild everything, which takes ~30mn on my laptop <civodul>mark_weaver: would you like to do the announcements? <mark_weaver>thanks for asking, but go ahead and do them this time, if you don't mind. <mark_weaver>given that you're doing the distcheck, and the tarball be signed by your key (mine is not yet on the gnu keyring, nor does it have perms to upload) <mark_weaver>glad to help. I enjoy working with this community a lot :) <mark_weaver>the recent work on guile that you and wingo have done in recent years is awesome, and is what got me interested in guile in the first place, so thanks for that :) <tupi>yes the work that has been done is just amazing, the 3 of you and many other contributers ineeed. the community, the quality, the respect for others, beginners till best hackers is such that i can say, in my opinion, one of the best of the communities i did or had to be in touch with! awsome <davexunit>I'm with tupi. the guile community is great. <mark_weaver>civodul: would this be an inopportune time to point out a typo I made in NEWS? line 144 "as specified SRFI-46 and R7RS" --> "as specified in SRFI-46 and R7RS" <mark_weaver>but not important if you're already deep in make distcheck.