***ijp` is now known as ijp
<nalaginrut>times bug seems fixed, I think Guile2 is OK for Hurd *nalaginrut testing the final stuff <nalaginrut>for Hurd internal-time-units-per-second will be 1000 <nalaginrut>but the elapsed time is far larger than (* 2 internal-time-units-per-second) <nalaginrut>I think the different of two returned clocks after 1 second should be the TIME_UNITS_PER_SECOND, in principle <nalaginrut>is it proper to set CLOCKS_PER_SEC to 1000 for everyone else, and..."Milliseconds"? <lkjoiulkj>can i alias (define) to something else, like (=)? <mark_weaver>yes, but aliasing it to = is probably a bad idea since that's the numerical equality predicate. <mark_weaver>e.g. (define-syntax-rule (my-define . args) (define . args)) <lkjoiulkj>define just seems lame to type all the time and there isn't any tab complettion. <wingo>there are lots of solutions for tab completion <wingo>the repl does it with one system, geiser uses another, etc <wingo>i suggest using geiser and paredit in emacs <wingo>perhaps you didn't enable readline <wingo>search the manual for readline <wingo>i don't recall the exact incantation <wingo>it's something you do once, drop in your .guile, and forget about it :) <taylanub>lkjoiulkj: Editing Lisp in anything but Vim will be a sub-optimal experience. <lkjoiulkj>can anyone recommend a decent tutorial for general system scripting? <wingo>maybe scsh has a good tutorial <wingo>it's not quite the same, but it is clearly focused on that problem area <lkjoiulkj>well i'm brand new, so i don't really know what to make of any literature i encounter. <wingo>scsh was an old project (almost 20 years ago) but still fresh in some ways, that aimed to replace bash with scheme <wingo>many of guile's interfaces were inspired by it <wingo>so for a schemey perspective on system scripting, its manual is a good read <wingo>for a practical perspective on system scripting, you need to read a good POSIX manual like the Stevens books -- those typically use C for their examples but Guile does have low-level posix interfaces <wingo>so they transfer over fairly well <wingo>depending on who you talk to :) <wingo>also the manual's intro is a classic *taylanub pronounces it ess see ess eich <wingo>taylanub: that is incorrect :) <taylanub>I wonder why I pronounce it in my mind at all if I'm never speaking it out. :P <wingo>hoo boy, it's almost a good thing guile doesn't have a secure random number generator <wingo>with all the bugs that are coming out these days in android's... <Arne`>Is there a netcdf library for guile? <Arne`>I could not find one - but then it’s pretty hard to google for scheme… <Arne`>(which shows again that the name scheme has been chosen in the pre-google time…) <Arne`>(googling “guile scheme” helped. I never thought that would work) <mark_weaver>wingo: should 'emit-seq' have a case for $call nodes? the reason I ask is that when compiling prompts, 'compile-cps' currently creates a $primcall 'pop-prompt' that returns directly to a kseq. when primitives are reified, this is turned into a normal procedure call, and then 'compile-rtl' tries to match a $call in 'emit-seq'. <wingo>pop-prompt should be a primitive that compile-rtl recognizes <mark_weaver>ah, okay. well, there's currently no VM instruction for 'pop-prompt', is there? should there be? <wingo>mark_weaver: i think it's equivalent to `unwind' <wingo>so we should make it be `unwind' instead <mark_weaver>wingo: do you think 'visit-cont' in contification.scm needs a case to handle $ktrunc ? <mark_weaver>I'm getting an "unbound near relocation" error during link, and the problematic label seems to be for the handler continuation. <wingo>mark_weaver: i don't think so because the last case is a default clause <wingo>so i was thinking of something that we are doing wrong in contification <wingo>we don't ensure that the function is contified at a point in the program in which the constant continuation is in scope <wingo>so if we are contifying f, with a continuation of k <wingo>we currently contify f where it is bound <wingo>but there is no guarantee that k is bound there <mark_weaver>*nod* I still haven't taken the time to understand the contifier. <wingo>so we need to compute the k* at which to contify f, such that k is bound there <wingo>do read the kennedy paper :) <fdsugkjh>wingo: will that tutorial be fully applicable to guile? <fdsugkjh>is guile nt just an implementatin of the scheme standard? <mark_weaver>wingo: I've added that to my TODO. in the meantime, do you have any guess as to why the label for the prompt handler (and presumably the code that follows) would not have been generated? (that's my guess, perhaps misguided, about why I'm seeing "unbound near relocation"). In CPS, the handler is a $ktrunc bound by a $letk. <wingo>mark_weaver: could be a bad cps conversion <wingo>i haven't tested that code at all <mark_weaver>and I get: "ERROR: unbound near relocation (x8-s24 khargs126 3 1)" <mark_weaver>so that khargs126 corresponds to the $ktrunc of the handler. *add^_ is trying to rewrite "Boing" C-code in Scheme <wingo>is it the cps going before or after transformation/optimization? <mark_weaver>after reification of primitives. so just before rtl gen. <mark_weaver>I can show you the cps in another stage if you like. *wingo wonders if that works :) <mark_weaver>hmm, what's the right syntax for that again? ",trace emit-label" can't be right; it immediately tries to evaluate 'emit-label' while tracing. <wingo>yes, emit-label has to be in scope <wingo>you might have to (use-modules (system vm assembler) <wingo>mark_weaver: btw mark_weaver the k in the continuations in letcont is redundant <mark_weaver>Either I'm confused, or ",trace" doesn't do what you think it does. it does *not* seem to record that all future calls to 'emit-label' wlil be traced. instead, it runs a trace immediately while evaluating the expr. <mark_weaver>well, the second argument to 'emit-label' is 'cur', which is huge, and prevents me from seeing any of the other arguments. <mark_weaver>the return value seems to contain an alist that might have labels as keys though. <mark_weaver>anyway, I don't see that label anywhere in the returned alists. <mark_weaver>is there some machinery for eliminating dead continuations at that late stage? <mark_weaver>is it enough for the continuation to simply be in a $letk, or does it have to be traversed from the place where it's used? <wingo>perhaps it isn't being collected by fold-local-conts <wingo>no, being in a $letk should be enough <mark_weaver>wingo: should 'cont-folder' in 'fold-local-conts' have a case for $trunc? <wingo>mark_weaver: don't think so... <mark_weaver>if not that, then should 'collect-exps' in compile-rtl.scm? <mark_weaver>I guess I need to spend more time studying this code and that paper. <wingo>mark_weaver: it probably is the case that emit-label is never called if there are no expressions in a continuation <mark_weaver>hmm, or maybe 'emit-trunc' needs a case for $prompt. <wingo>mark_weaver: i suppose collect-exps could add a case for ktrunc in the second match statement <wingo>that's probably the thing to do... though... is it? <wingo>it could be prompt's responsibility to do the trunc <wingo> i guess that's how calls are done currently <wingo>mark_weaver: another thing is, what happens when you do (call-with-prompt tag (lambda () (values 1 2)) (lambda (k a) a)) <wingo>probably it should error about too many values returned to continuation <wingo>i guess that could be expressed somehow by the ktrunc but it's not nice <wingo>making ktrunc mean "require these many values, possibly consing a rest list" and also "require at least this many values, possibly consing a rest list" <wingo>we have bugs in 2.0 because of this kind of imprecision <mark_weaver>I was thinking that maybe, instead of having truncation of extra values being a core part of our semantics, instead single-valued continuations (e.g. when evaluating arguments) should be continuations of the form (lambda (x . _) ...) <mark_weaver>where the _ gets dumped, and we make sure the optimizer prevents the rest list from being constructed. <wingo>though receive-values might have to be strict, or have a flag indicating that there may be more values <mark_weaver>*nod*. simple $kargs with a rest list that's never used could compile into 'receive-values' with that flag set. <davexunit>frowns upon the "MIT approach" to software development <ijp>I think you've misunderstood it <ijp>basically the essay says "shipping wins" <davexunit>but the author calls into question lisp design. the MIT approach states that it's more important for the interface to be simple than the implementation. <davexunit>whereas the new jersey approach favors implementation simplicity. ***ijp` is now known as ijp