IRC channel logs

2013-06-14.log

back to list of logs

<davexunit>how do you use a docstring with a procedure defined like: (define foo (let ((bar "bar")) (lambda () ... )))
<sneek>Welcome back davexunit, you have 1 message.
<sneek>davexunit, mark_weaver says: see 'reap-pipes' in ice-9/popen.scm, and the immediately following call to 'add-hook!' for an example of how to use guardians.
<ijp>put it in the lambda?
<ijp>that should work,no?
<ijp>yeah, it does
<davexunit>ijp: cool, thanks
<mark_weaver>sneek: botsnack
<sneek>Welcome back mark_weaver, you have 1 message.
<sneek>mark_weaver, tupi says: thanks, was busy talking to a collegue, but till now i did not received your email. we can talk about it later or tomorrow of course, thanks again: it is extremely important to me that we find a solution to this problem...
<sneek>:)
<mark_weaver>sneek: later tell tupi if the patch I sent doesn't fix it, let me know and I'll dig deeper.
<ijp>hey mark_weaver
<sneek>Will do.
<mark_weaver>hi ijp!
<ijp>what's been happening in my absence? anything interesting?
<mark_weaver>quite a bit, actually. wingo has been merging the RTL stuff into master. exciting times :)
<mark_weaver>we still lack a compiler to generate the RTL from Scheme, but I suspect we'll have that in the next month or two. I might even do it myself if it takes too long :)
<mark_weaver>how have you been? hacking anything fun these days?
<ijp>nah, nothing exciting happening
<ijp>I've been trying to figure out what to do for lispinsummerprojects
<mark_weaver>ah, I should take a look at that site.
<mark_weaver>ah, sounds like a great initiative :)
<mark_weaver>is this its first year?
<ijp>I think so
***fangism is now known as fangism-nomnom
<mark_weaver>so no earlier years to look to for insight as to what kind of thing the judges will appreciate.
<mark_weaver>I notice that "documentation" is in their set of ideas. One possibility would be to come up with a set of tutorials for R6RS Scheme. I think that's something you could probably do very well. I have a lot of respect for your coding style.
<mark_weaver>or maybe your Guile-VM-in-Javascript idea?
<ijp>I've considered going for the static fp compiler route, just as an excuse to go though "compilinig with continuations"
<ijp>the guile-vm-in-js is a tricky one
<ijp>they said implementations were alright in js, as long as it was significantly in scheme
<ijp>but, I'm not certain it'd be a lot of scheme
<ijp>well, by the time you fill in the runtime, it might be
<mark_weaver>ah, so a compiler might be better. then you could write the compiler in scheme :)
<mark_weaver>Replacing large chunks of our C code with Scheme would definitely be a good thing, IMO.
<ijp>I've written a "static functional language" interpeter before, including algebraic data types, type inference, blah, but there is still a lot of novelty there with typeclasses,etc
<ijp>one big choice is whether to integrate with guile, or go for portable
<mark_weaver>You could make as much of it portable as practice, with the non-portable bits targetting Guile for now.
<mark_weaver>s/practice/practical/
<mark_weaver>it would be really nice to have a static fp front-end for Guile.
<mark_weaver>ideally something that could be built-upon to eventually build a haskell front end.
***CaptainLex|AFK is now known as CaptainLex
<nalaginrut>sneek: later tell civodul IMP is a tiny imperative language, which is used in some CS course, http://fsl.cs.uiuc.edu/images/0/0d/CS522-Spring-2011-PL-book-imp.pdf
<sneek>Got it.
<nalaginrut>sneek: later tell civodul it's simple enough but not too simple, so I think it's suitable to be a tutorial of Guile front-end taking all the 'regular' mechanism like make-token&LALR
<sneek>Got it.
<youlysses>Guile is 2.x now in the Arch/Parabola's repos. \\o/
*youlysses just switched back to Parabola.
<mark_weaver>that's great news! :)
<youlysses>mark_weaver: Yup and evidently guix has a package in the aur, which was super easy to get going! :^D
<nalaginrut>mark_weaver: I've fixed the redundant white-space eating in IMP, there's some trick in ecmascript, I don't know if it's the regular way to go
<nalaginrut>the last semi-colon before EOF must return '*eoi* rather than 'semi-colon, or the user have to press C-d in REPL to end the input
<nalaginrut>the lexer of ecmascript handled that, what a trip
<nalaginrut>s/trip/trap
<mark_weaver>interesting
<mark_weaver>congrats on getting IMP working, btw!
<nalaginrut>lol
***CaptainLex is now known as CaptainLex|ZZZ
***Shozan is now known as SHODAN
<davexunit>good morning guilers.
<add^_>Good afternoon davexunit
<davexunit>mark_weaver: thanks for pointing me towards reap-ports.
<davexunit>for those of you that write unit tests: there's a srfi that provides a testing framework. is that what you use?
<fbs>o/
<davexunit>emacs has some pretty nice unit testing libraries, but I don't know of equivalent libraries for guile.
<mark_weaver>davexunit: Although I haven't used it myself, I've seen civodul recommend that people use SRFI-64. Guile uses it's own home grown testing framework for it's internal test suite, but it's only in the build directory (not installed).
<davexunit>mark_weaver: yeah I remember you telling about the internal test suite before.
<davexunit>I'll try srfi-64.
<davexunit>trying to be better about testing my code.
<mark_weaver>yes, a comprehensive regression test suite is well worth the effort.
<davexunit>I agree. I spend a lot of time writing tests at work.
<mark_weaver>davexunit: if you use SRFI-64, note that it's reference implementation was written during the time of Guile 1.6, when Guile did not have SRFI-34 or SRFI-34. You'll see those two imports commented out of the Guile section. I guess you should uncomment them.
<mark_weaver>We should probably add SRFI-64 to Guile.
<mark_weaver>s/it's/its/
<davexunit>mark_weaver: okay. thanks for the heads up.
<mark_weaver>wingo: thanks for the fascinating article on Igalia.
<wleslie>indeed
<mark_weaver>I'd never before heard of such a large and successful consensus-based organization. 40 people reaching consensus on a regular basis sounds almost impossible, unless the people are very carefully chosen (which I'm sure they were :)
<mark_weaver>I've always liked the idea of consensus, but never seen it work on such a large scale.
<wleslie>a set of people getting things together is often difficult even when that set has one element; I think they must be very carefully chosen too
<wleslie>people with a common goal and significant reflection
<wleslie>is consensus actually required?
<mark_weaver>and crucially: people who will refrain from blocking consensus, and set aside their own (sometimes strong) preferences, so that the entire group doesn't become paralyzed.
<wleslie>good flatmates.
***CaptainLex|ZZZ is now known as CaptainLex
***ijp` is now known as ijp
***fangism-nomnom is now known as fangism
<tupi>can someone remember me if it is safe [or not] - guile 2.0.7 or higher - when a function returns multiple values, not to use receive [or call-with-values], when the first returned value is the only one i need ?
<sneek>Welcome back tupi, you have 1 message.
<sneek>tupi, mark_weaver says: if the patch I sent doesn't fix it, let me know and I'll dig deeper.
<cky>tupi: Guile 2.0 allows you to use a single-value continuation with multiple values, yes.
<cky>So you can say (+ (values 1 2 3) 4) and get 5.
<tupi>for example yes
<ijp>FWIW, I consider this a misfeature
<cky>ijp: CL's designers certainly liked it.
<ijp>and at best, an assymetry
<ijp>asymmetry*
<tupi>but your example is a bit different from the use i was thinking of :) in this case it really sounds weird i agree
<cky>tupi: What was your intended use?
<tupi>i already wrote a function, let's call it a
<cky>CL's behaviour makes some functions, in particular the rounding functions, easier to use.
<cky>The rounding functions in CL return two values, the rounded value and the remainder.
<tupi>now i'd ike it to return 2 other values, but i don't want to change existing code
<cky>If you don't need to use the remainder, then just use the return in a single-value context.
<tupi>that does nort answer my quizz :)
<ijp>the behaviour is expected going forward
<ijp>It should be documented, at least in NEWS
<ijp>let's see....
<tupi>ijp: i don't understand 'the behaviour is expected going forward'
<ijp>this was a 2.0 change
<tupi>if it is not garanteed, i need to revisit existing code, which is fine too, but i'd like to avoid it right now if possible
<ijp>I'm telling you it is guaranteed
<tupi>perfect, thanks
<ijp>in compiled code anyway
<tupi>perfect
<ijp>I hate this behvaiour in lua too
<mark_weaver>tupi: it's guaranteed behavior in 2.0, whether compiled or not.
<tupi>mark_weaver: tx. and tx for the patch, i should try it later today
<tupi>will let you know how it goes of course
<mark_weaver>tx!
<mark_weaver>ijp: I also have mixed feelings about the multiple-value truncation, but the current behavior needn't be inconsistent. One way to think about it is that the default continuations that are created when evaluating arguments are not of the form (lambda (x) ...) but rather (lambda (x . _) ...)
<mark_weaver>I'm not sure that our current implementation is entirely consistent with that formulation, but that's one way to do it.
<ijp>my feelings aren't mixed, I've mostly just went off multi-valued continuations altogether
<mark_weaver>if we had immutable pairs, then we could just use lists without allocating heap.
<mark_weaver>(assuming a clever compiler)
<mark_weaver>but as things currently are, multiple values are the only way to return more than one value without allocating.
<mark_weaver>(which is sometimes very important)