IRC channel logs


back to list of logs

***ijp` is now known as ijp
<nalaginrut>morning guilers~
<nalaginrut>times bug seems fixed, I think Guile2 is OK for Hurd
*nalaginrut testing the final stuff
<nalaginrut> unfortunately, it can't pass the test
<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>in times.test, "versus times and sleep"
<nalaginrut>I think the different of two returned clocks after 1 second should be the TIME_UNITS_PER_SECOND, in principle
<nalaginrut>. but I'm not sure if it's elibc or Guile bug
<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>use 'define-syntax'
<mark_weaver>or 'define-syntax-rule' for simple cases
<mark_weaver>e.g. (define-syntax-rule (my-define . args) (define . args))
<lkjoiulkj>can args still be variadic?
<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
<lkjoiulkj>wingo: oh, yeah?
<lkjoiulkj>my repl provides no tc to speak of.
<wingo>i suggest using geiser and paredit in emacs
<lkjoiulkj>vim person.
<wingo>perhaps you didn't enable readline
<wingo>search the manual for readline
<lkjoiulkj>how do i enable 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.
<taylanub>err, anything but Emacs
<wingo>dybvig uses vim :)
<lkjoiulkj>oh, wow. readline is AWESOME!
<davexunit>it's interesting that dybvig uses vim.
<lkjoiulkj>can anyone recommend a decent tutorial for general system scripting?
<wingo>that's a hard question!
<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.
<lkjoiulkj>any recommendations would be appreciated.
<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> for scsh
<wingo>pronounced "skeesh"
<wingo>or skish
<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
<taylanub>Gotta practice some speed-reading.
<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...
<wingo> for example
<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`>never mind: found it:
<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'.
<mark_weaver>what's the right way to fix this?
<wingo>pop-prompt should be a primitive that compile-rtl recognizes
<wingo>it shouldn't be reified
<mark_weaver>ah, okay. well, there's currently no VM instruction for 'pop-prompt', is there? should there be?
*wingo checks
<wingo>mark_weaver: i think it's equivalent to `unwind'
<wingo>so we should make it be `unwind' instead
<mark_weaver>ah, okay, thanks!
<wingo>np :)
<fdsugkjh>to what extent is this applicable to guile?
<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
<mark_weaver>what's that?
<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?
<wingo>fdsugkjh: not fully, no
<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>in compile-cps
<wingo>i haven't tested that code at all
<mark_weaver>would you be willing to take a quick look at the cps? it's simplified by an experimental 'unparse-cps' I'm working on (comments welcome):
<mark_weaver>I think that's old. let me paste a fresh one.
<mark_weaver>wingo: okay, this one is fresh:
<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>what is this pastebin?
<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>can you ,trace emit-label ?
*wingo wonders if that works :)
<mark_weaver>will try.
<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
<wingo>er, letk i mean
<wingo>the unparse-cps output
<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.
<wingo>ah, sorry about that
<wingo>there are tracepoints too
<wingo>,tracepoint emit-label
<mark_weaver>ah, got it.
<mark_weaver>well, the second argument to 'emit-label' is 'cur', which is huge, and prevents me from seeing any of the other arguments.
<wingo>haha, oh well :)
<mark_weaver>the return value seems to contain an alist that might have labels as keys though.
<wingo>it was a noble try
<mark_weaver>anyway, I don't see that label anywhere in the returned alists.
<mark_weaver>so I guess it's not being emitted.
<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>I'll look into 'fold-local-conts'.
<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.
<nalaginrut>well, I think upload function is "perfect" now~
<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.
<mark_weaver>no nvm.
<nalaginrut>if perfect means "perfect temporally" ;-)
<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 not sure :)
<mark_weaver>okay, thanks for looking.
*nalaginrut zzzZZZ...
<mark_weaver>goodnight nalaginrut!
<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>maybe, yes
<mark_weaver>that way, everything is strict in the core engine.
<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.
<mark_weaver>I dunno.
<wingo>yeah, me neither
<davexunit>reading this for the first time
<davexunit>frowns upon the "MIT approach" to software development
<davexunit>and lisp design
<ijp>I think you've misunderstood it
<ijp>basically the essay says "shipping wins"
<davexunit>I gathered that
<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
<dsmith-work>Hey hey