IRC channel logs
2014-01-26.log
back to list of logs
<mark_weaver>I seem to have gotten myself distracted by getting two SRFIs implemented for Guile. I'm working on both SRFI-43 and SRFI-64. <davexunit>mark_weaver: I was happy to see SRFI-111 on the ML. <Sleep_Walker>ERROR: Wrong type to apply: #<<response> version: (1 . 1) co.... <nalaginrut>unfortunately, I have to work on Sunday today... <nalaginrut>well, positively, I have received a bunch of reports for my stupid bugs in Artanis again. I feel happy~ <mark_weaver>Sleep_Walker: the first argument to 'call-with-values' should be a thunk (i.e. a procedure that takes no arguments) <mark_weaver>although in this case, I see that you only want the first value, so you don't need to use 'call-with-values' at all. <nalaginrut>I haven't prepared the real logo of Artanis, since designers I known are very busy these days... *nalaginrut nalaginrut has no painting talent... <mark_weaver>nalaginrut: I finished my implementation of SRFI-43 for Guile. <mark_weaver>I just need docs and tests now, but it passes Shiro Kawai's test suite for SRFI-43 anyway. *nalaginrut can't remember each srfi number for its functions <nalaginrut>well, please tell me when you decide to merge to stable-2.0 ;-P <olkol>gnucash 2.6.0 and guile 2.0, reverting to guile 1.8.8 and previous gnucash works again <olkol>i do not understand, without changing the environment it runs fine with 1.8.8 <Fishlord_Murloc>I often use the idiom to define a function which has to take one or more arguments of (define (f x . xs) {define xs (cons x xs)) <body> ), this in guile binds xs in the body to an improper list whose final cdr is <unspecied> is this a bug? <wingo>it is not really a bug -- your code is equivalent to (define (f x . xs) (letrec ((xs (cons x xs))) <body>)) <wingo>so you can see that the xs in the cons refers to the new binding you declared <wingo>ideally that should signal an error (accessing a letrec binding before it is bound) but that is not currently the case <wingo>so your code has a bug, and guile's lack of reporting is somewhat of a bug also <Fishlord_Murloc>wingo, hmm, it works in other implementations, I was of the impression that with value bindings it would be identical to a let and shadow but with function bindings be recursive. <Fishlord_Murloc>wingo, is there a way to let a shadow exist over the remaining scope? <wingo>there is no difference between values and functions in this case <wingo>it's a letrec; and the initializers are in the scope of the new bindings <wingo>and otherwise i don't know what you are trying to do :) if you want the old xs on the right-hand-side there is no way out of using `let' <wingo>sorry, don't have time to look right now <wingo>i suggest you review the section of the r5rs about internal definitions <wingo>civodul: precise stack marking in master :) <civodul>like it doesn't mark past the current SP? <wingo>like stack slots that are dead once a call has begun are not marked <wingo>so the hottest frame is marked conservatively, as before <wingo>but other frames have gc maps recorded in the elf file for all return points <wingo>those maps are consulted at gc time to avoid marking dead data