IRC channel logs

2014-03-17.log

back to list of logs

***adhoc_ is now known as adhoc
<nalaginrut>morning guilers~
<mark_weaver>hi nalaginrut!
<nalaginrut>mark_weaver: heya, long time no see your greeting ;-P
<mark_weaver>yes, I suppose it has been a while
<mark_weaver>I've been trying to work more and chat less
<mark_weaver>(although I've been answering questions on channel quite a bit)
<nalaginrut>yes, I'm trying to do the same like you
<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>if anyone would like to compile the latest snapshot, run "make check", and report any failures, it would be helpful. http://hydra.nixos.org/job/gnu/guile-2-0/tarball/latest
<mark_weaver>(I know I've been talking about 2.0.10 for ages, but this time I really mean it :)
<b4283>mark_weaver: looking good ;; http://bpaste.net/show/1aVMMpinQf5Cl9D57UQf/
<mark_weaver>b4283: thanks! what kind of system was that on? (distro and architecture)
<b4283>OpenSUSE 13.1 AMD64
<mark_weaver>excellent, thanks :)
<b4283>glad to be of help :D
<nalaginrut>I found a nice place to learn licenses https://tldrlegal.com/licenses/browse
<civodul>Hello Guilers!
<artyom-poptsov>Hi civodul
<nalaginrut>heya
***ijp` is now known as ijp
<wingo>moin
<civodul>howdy wingo!
<wingo>heyas :-)
<civodul>wingo: thanks to mark_weaver, it looks like we'll be able to release 2.0.10 by Wed.
<civodul>perhaps even today, who knows ;-)
<wingo>that's super!
<civodul>yeah, overdue :-)
<wingo>yeah, but i can't complain :)
<civodul>heh :-)
<wingo>mark_weaver does his best hacking right before a release, so a prolonged pre-release has worked well for guile ;-))
*wingo evil grin
<wingo>i just fixed stack overflow for good in master, i think
<civodul>ahah :-)
<wingo>there is no limit by default to the stack, though you can impose one with call-with-stack-overflow-handler
<wingo>all documented :)
<civodul>woow, that's neat!
<nalaginrut>sounds cool~
<wingo> http://wingolog.org/archives/2014/03/17/stack-overflow
<saul>wingo, when Guile performs a call/cc, does a copy of the return stack get stored to heap?
<wingo>saul: yep
<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>it's not that rare actually
<wingo>chez scheme does it, though they copy lazily (only when control flow returns past the call/cc)
<wingo>racket copies
<wingo>i think gauche copies but i don't recall
<wingo>so yeah, not uncommon
<saul>So for delimited continuations, is only the continuation chain from after the call/cc copied to heap?
<wingo>saul: yes
<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>np :)
<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
<wingo>there is also (while (f))
<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
<wingo> http://www.gnu.org/software/guile/manual/html_node/Shift-and-Reset.html#Shift-and-Reset
<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 too
<wingo>though i get occasional loop envy from the racketeers
<dsmith-work>Hey hey
<wingo>heya dsmith-work :)
<dsmith-work>NEWS has been updated. Smells like a release is immanent.
<Madsy>saul: These are the two ways I know of at least. Not sure which one is "better" https://gist.github.com/Madsy/9599669
<mark_weaver>Madsy: use (not x) instead of (equal? x #f)
<mark_weaver>dsmith-work: any chance you could test the latest snapshot on an ARM system? http://hydra.nixos.org/job/gnu/guile-2-0/tarball/latest
<mark_weaver>(I've lost contact with mine, or else I'd do it)
<mark_weaver>Madsy: although it's simpler to just do (and x ...)
<mark_weaver>wingo: fantastic work on stack overflows! I'm really excited about guile master :)
<wingo>mark_weaver: thanks :-)
<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 :)
<mark_weaver>but thanks :)
<wingo>it is indeed awesome :)
<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>(because it allows us to write much nicer code)
<wingo>indeed!
<mark_weaver>yeah, that's a good question. hmm.
<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
<mark_weaver>that's an interesting middle ground, yes.
<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>there are differences
<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>sure
<mark_weaver>I think that's a fairly common case.
<wingo>probably, yes
<mark_weaver>e.g. computing some result that is too big
<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
<wingo>anyway :)
<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>we need those anyway, even if we have a reserve.
<mark_weaver>the reserve stuff could optionally be implemented on top of what's currently there, as a nicety.
<wingo>true
<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
<wingo>now that we can be smug, http://bugs.python.org/issue6028#msg87836 is amusing
<mark_weaver>heh :)
<wingo>:)
<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.
<wingo>hehe
<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>(ditto for any memory reserve)
<wingo>ack
<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 :)
<mark_weaver>okay
<civodul>hey mark_weaver
<mark_weaver>hi civodul !
<mark_weaver>just read your test reports. thanks for that :)
<civodul>mark_weaver: you're welcome
<civodul>i think it inspires confidence ;-)
<civodul>so IMO what's left is mainly NEWS
<civodul>and then i'd be happy with the release
<civodul>mark_weaver: and you?
<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.
<mark_weaver>I got things working well with clang, anyway :)
<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)
<civodul>yeah right
<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.
<mark_weaver>and that's just a test anyway.
<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.
<civodul>aah, sorry, not yet
<civodul>ok i'll check later then
<mark_weaver>I could work on it some more, but I could use some input on how things should be organized.
<mark_weaver>but it's mostly there, anyway.
<civodul>okay
<civodul>ttyl
***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.
<mark_weaver>what do you mean by "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.
<mark_weaver>also you could fork and exec and waitpid yourself.
<mark_weaver>(if you don't use threads)
<didi>mark_weaver: I see.
<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>ok
<antoineB>(define (defined-names module) (hash-map->list (lambda (k v) k) (module-obarray module)))
<antoineB>top level mean module level?
<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>ok
<antoineB>are you used to guile emacs?
<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
<wingo>moo
<didi>wingo: Nice post. I'm excited to see the stack limit going away.
<wingo>tx :)
<antoineB>is it possible to use binding defined in elisp language from scheme language?
<civodul>mark_weaver, wingo: mutex_lock(&NEWS.lock)
<wingo>ok :)
*wingo looking over the last month's stable-2.0 changes that he's been ignoring; (system base types) looks nice :)
<civodul>i still need to port it to master
<wingo>master's assembler could use it
<wingo>and disassembler
*wingo pretends he hacks on stable-2.0, pushes a wee fix
<civodul>:-)
*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>thanks!
<civodul>mark_weaver: ping
<civodul>mark_weaver: i think it's time for "make distcheck"
<mark_weaver>hi civodul!
<davexunit>civodul: oh boy! :)
<civodul>hey mark_weaver!
*mark_weaver reads the latest commits
*civodul awaits mark_weaver's (preferably green) light
<mark_weaver>civodul: looks good to me. let's distcheck! wee :)
<civodul>yay!
<civodul>mark_weaver: so how do we proceed?
<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.
<mark_weaver>but I'm willing to help in any way I can.
<civodul>ok
<civodul>well yeah, distcheck will rebuild everything, which takes ~30mn on my laptop
<civodul>mark_weaver: would you like to do the announcements?
<civodul>either way is fine with me
<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>s/be/will be/
<civodul>okay
<civodul>we owe you a lot for this release
<mark_weaver>I should probably get some of those things fixed...
<civodul>yes :-)
<mark_weaver>glad to help. I enjoy working with this community a lot :)
<davexunit>:)
<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 :)
<civodul>heheh, it's been a pleasant journey
<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>definitely time to break out a beer :)
<civodul>:-)
<tupi>yes! :)
<mark_weaver>(or your beverage of choice :)
<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.
<civodul>well, indeed :-)
<civodul>stop looking at NEWS ;-)
<mark_weaver>heh :)
<mark_weaver>C-x k RET