IRC channel logs


back to list of logs

<wigs>hello now
<sneek>Welcome back wigs, you have 1 message.
<sneek>wigs, fbs says: I fixed gnutls-guile2.0 it by getting libnettle and gnutls-3.1.9 :)
<wigs>sneek, botsnack
<nalaginrut>long time no see you wigs ;-P
<wigs>nalaginrut: yes, I have a new baby
<wigs>so that is lots of work :-)
<nalaginrut>wigs: congrats!
<wigs>it seems the list has been a bit quiet anyway
<wigs>except for the new vm stuff
<nalaginrut>yes, but I haven't tried master now
<lloda>hello Guilers
<lloda>is there anything I can do to make it easier for you to look at my array patches?
<lloda>I'd like to continue, there're more things to fix and finish.
<wingo>lloda: i can try to take a look at them next week
<wingo>unless i can convince mark_weaver to look at them, he would also be a good candidate
<wingo>s/next week/later this week/
<wingo>apologies for the delay there
*wingo working on the rtl compiler
<lloda>sure, np
<stis>morning guilers!
<lloda>I appreciate a lot your work on the compiler!
<taylanub>Might as well join in: +1
<taylanub>Morning BTW.
<wingo>heh, tx
<add^_>Morning :-D
<wingo>i seem to recall someone asking recently about order of evaluation, asking if any practical schemes took advantage of the unspecified order. here's one example:
<wingo>chez does something like that also
<ijp>I knew chez did, but not larceny
<ijp>don't remember who was asking about it though
<stis>cool 6% overall decrease in code size for just one optimisation is quite good.
<stis>I could hack on such an optimization if you would like.
<stis>it sure look like a fun thing to do :-)
<taylanub>I wonder if the optimizations found in Stalin would be applicable to the more "normal" Scheme implementations. Supposedly "Full R4RS Scheme is supported, with a few minor and rarely encountered omissions." I wonder if there are any inherent limitations posed to the language by it, or if it's just drudgery to implement the optimizations ?
<ijp>full program optimisation is applicable to most languages, it's just ass-clenchingly slow
<ijp>I was told the other day that gcc can do it
<taylanub>So this "full-program optimisation" is the main (category of) optimisation Stalin does, and it's a generic concept not tied to Scheme ? That makes me wonder if it could be done on the ELF level or so.
<taylanub>(Well, ELF is just a "container" for actual executable code, isn't it ?)
<ijp>link time optimisation exists
<stis>Hmm, i'm staring at simple.scm in sxml, isn't "'" a character that needs quoting in xml?
<stis>Look carefully, single quote " ' "?
<ijp>if it's inside double quotes, it may be acceptable
<taylanub>Might want to look up the specs. I wouldn't be surprised if HTML writers just quote it per habit due to some historic reasons.
<ijp>in any case, using the entity wouldn't hurt
<taylanub>"To allow attribute values to contain both single and double quotes, the apostrophe or single-quote character (') may be represented as " &apos; ", and the double-quote character (") as " &quot; "." Seems to imply it's otherwise not necessary.
<ijp>taylanub: I should point out that html is not xml
<ijp>it's liable to be more loose
<civodul>Hello Guilers!
<taylanub>Hidy ho!
<taylanub>ijp: Indeed, but XHTML writers are probably the most common XML writers, so I'd guess that their HTML-based habits often confuse XML users...
<ijp>I find that hard to believe
<taylanub>I might be the only one then. :P
<stis>The spec says that string starting with ' needs to quote it else no, so Not a Bug :-)
<ijp>all hail the mighty spec
<wingo>heya civodul
*stis is working trying to parse the spec for xml schema, it's not a beutiful spec!
<civodul>howdy wingo!
<civodul>what's up?
<weinholt>hello there
<weinholt>civodul, been finding some bugs in guile, i hope the reports are useful
<weinholt>(= 1/2 +inf.0) => #t is a nice one, i think
<civodul>weinholt: the reports are certainly useful, even if we don't address them right away
<weinholt>how do you feel about (char-numeric? #\\½) => #f? looks like it should be #t in r6rs
*ijp chuckles
<civodul>usually ijp would address the bug reports after a week of silence :-P
<ijp>alas, I've been caught by the event horizon of a procrastination black hole
<ijp>how I can even communicate from there is perplexing physicists as we speak
<taylanub>Hrm, going through random bug-reports .. I could do that too, when I give this bytestructures stuff a rest. BTW do I need to do copyright assignment stuffs ? I sent a super-small patch a couple weeks back but I think it was forgotten about; frankly I forgot about it myself. :P
<civodul>ijp: :-)
<civodul>taylanub: that would be welcome :-)
<add^_>If I theoretically wanted to submit a patch for guile, how would I go about doing that?
<add^_>Or is there some place on I can read about that?
<add^_>Yeah, found it
<civodul>though maybe it's not crystal clear
<civodul>let us know if you have any questions
<add^_>But "send a patch" isn't really... informative :-P
<civodul>reader under "If you have fixed the bug"
<add^_>That's where it says "Please send a patch and commit log..."
<add^_>I've never made/sent a patch via git.
<add^_>Oh, need to leave for a while again..
<wingo>civodul: re what's up, i have a full cps pass, working on closure conversion that also does our letrec closure hack, afterwards need to adapt noah's register allocator, then compilation to rtl
<wingo>the difference with noah's work is that it covers all of guile scheme
<wingo>instead of a subset
<wingo>also avoids some things he does like boxing all lexicals
<wingo>it's not a simple adaptation of the existing tree-il->glil compiler, but i wanted to give it a go
<wingo>it's very convenient to have every control point have a label
*wingo feels like a noob doing cps for the first time
<wingo>it's nice to have a language in which to reason about things like contification, which we only did in an ad-hoc way (that was the "labels" allocation for letrec)
<wingo>it's when you incorporate a local function into a function's flow graph
<ijp>ah okay, googled it
<wingo>yeah there's surely a better way to put it
<ijp>the worst thing about so much of CS is that the names make more sense after you've learned the concept
<ijp>the analogies too
<wingo>it's very abstract though, how can you have a name without a concept...
<wingo>contification didn't make sense to be before i saw the CPS style that divides functions into "conts" and not-conts -- and the conts get label allocation
<wingo>so contification is making a not-cont into a cont.
<civodul>wingo: nice!
<wingo>funny name ;)
<wingo>but it's really nice also to express things like the letrec closure-patching hack on a language level rather than in gnarly bits of the code generator
<wingo>not contification, just cps there
<civodul>so "fixing letrec" is no longer needed?
<wingo>it's needed to turn general letrec into something that only involves functions
<wingo>and the "fixing letrec reloaded" separates letrec into separate strongly-connected components, which is also useful
<civodul>oh, ok
<wingo>so contification runs after fixing letrec
<wingo>for example not all <fix> tree-il elements get labels allocation
<wingo>though all have passed through fixing letrec.
<mark_weaver>wingo: greetings!
<wingo>heya mark_weaver :-)
<wingo>how goes?
<mark_weaver>wingo: one important note about fixing-letrec-reloaded that may impact your later passes:
*wingo listens
<mark_weaver>wingo: in cases where formerly all mutually-recursive internal procedures would be at the same letrec level, with fixing-letrec-reloaded you often end up with multiple nested levels of binding constructs.
<wingo>that's quite fine
<mark_weaver>wingo: I found that with the current procedures-as-labels optimization later on (in stable-2.0), this would often cause things to no longer use nice labels.
<mark_weaver>in fact that's part of the reason I paused on that work.
<wingo>yes i think with cps we should be able to do the right thing and contify if possible
<wingo>the kennedy paper seems to suggest one can contify exhaustively given local rewrites
<mark_weaver>with the work you're doing, I'm feeling increased pressure to get fixing-letrec-reloaded in, to make sure your later passes optimize its output properly.
<wingo>and if not we can do the dominator-based analysis of fluet et al
<wingo>well, feel whatever pressure you prefer to feel :)
<wingo>hopefully we will be compiling significant programs within a couple weeks, but who knows -- there's so much more to do in the summer than the winter :)
<wingo>and i have the feeling there won't be a problem
<mark_weaver>apart from that, there are two main reasons I haven't yet posted my work: (A) I felt the code needed some more factoring into smaller procedures to look nicer, and more importantly (B) I hadn't yet implemented the explicit error checking (violating the letrec rules), and the new algorithm will actually rearrange the order of inits to make things work in many cases where they shouldn't.
<mark_weaver>but now I'm thinking maybe I should just rebase and post what I've got anyway, so that you can at least take it into account for later passes.
<wingo>i assume it's not introducing more set!s than the existing fixing-letrec pass does?
<mark_weaver>indeed, there are many fewer set!s than the current code.
<mark_weaver>but on the flip side, the labels optimization was foiled in many cases.
<mark_weaver>hopefully that issue will be rectified in master with your new compiler.
<wingo>yes, then, anything algebraic should do better with cps + a contificaiton pass
<wingo>haven't written that yet tho
<wingo>those are the missing parts: closure conversion / letrec flattening (when we can't contify), contification, allocation, and the ->rtl compiler
<mark_weaver>I was also wondering if it would make sense to annotate letrec-bound variables that *do* involve a 'set!' to mark them as "set! only once, and illegal to fetch before the first set!, so effectively immutable in some ways"
<wingo>i'm working on the first bit right now
<mark_weaver>sounds great!
<wingo>mark_weaver: i think that would be apparent from the residual code; no annotation needed i think
<wingo>and if we implement a store-to-load forwarding pass we can probably avoid the fetch in some cases...
<mark_weaver>I'm not so sure. in many cases it may be impossible for the compiler to prove that none of the other inits accessed the variable. although that would be "illegal" according to the letrec def'n, and thus we should be allowed to assume that it won't happen.
<wingo>i want to do a loop peeling pass too at some point
<mark_weaver>(e.g. if any of the other inits call a top-level procedure)
<wingo>the first time through a loop would then be separate and dominate the rest of the loop
<wingo>which should let CSE hoist out things like toplevel references, etc
<mark_weaver>well, this is all very exciting work :)
<wingo>slow going, but fun stuff, yes :)
<mark_weaver>where do you think fixing-letrec should be in the order of passes?
<wingo>mark_weaver: before tree-il->cps, after peval
<wingo>then CSE should eventually happen only on CPS
<mark_weaver>I definitely agree it should be before ->cps. I haven't really thought about its relation to peval. for now I'll take your word for it, but it sounds reasonable :)
<mark_weaver>I guess maybe peval can benefit from seeing letrec-bound variables as immutable, even if 'set!'s are introduced later.
<wingo>yes i think so
<mark_weaver>wingo: any thoughts on changing 'letrec' tree-il nodes to 'letrec-values' ?
<wingo>i haven't thought a lot about it
<wingo>it kinda hurts my brain :)
<mark_weaver>it seems to me that first-class support in fixing-letrec-reloaded for 'letrec*-values' is needed for efficient compilation of internal 'define-values' forms.
<mark_weaver>and 'letrec-values' would be a natural thing to add as well, more powerful in some ways because you can tell the compiler you don't care about the order of evaluation.
<wingo>we could add letrec-values but then simplify in most cases to letrec
<wingo>and use some general evaluation strategy for letrec-values if needed
<wingo>but try to rewrite things like (define-values (a b) (let ((x 10)) (values y z)))
<wingo>into (let ((x 10)) (define a y) (define b z) ...)
<mark_weaver>well, plain 'letrec' is strictly less powerful than 'letrec-values', and similarly for 'letrec*' and 'letrec*-values', so I see no reason to include the single-valued ones in tree-il.
<wingo>with all lexicals having unique names, that sort of thing is easy and with cps we end up flattening lets anyway
<wingo>the reason to include singly valued letrec is not a semantic issue but a representational issue -- it's a form we implement efficiently
<wingo>so if you see a <fix> you know you just have unassigned lambdas on the rhs, without further analysis, and can take advantage of that (even if you can't contify)
<mark_weaver>hmm, well, I guess you save one or two cons cells per binding, yeah.
<mark_weaver>I'm not sure if that's worth the added complexity of two more tree-il node types though. maybe.
<mark_weaver>plain <fix> definitely makes sense, I agree.
<wingo>you could replace <letrec> with <letrec-values>, given the existence of <fix>
<wingo>my cps conversion pass actually relies on fix-letrec already having run -- it expects the input not to have <letrec> at all
<mark_weaver>right, that was my thinking. fixing-letrec-reloaded converts <letrec> to <let> and <fix>, and the multi-valued version would also produce <fix>
<mark_weaver>there might also be value to replacing <let> with <let-values>, since the usual way of converting <let-values> to nested 'call-with-values' fixes the order of evaluation prematurely.
<wingo>ok, that sounds good to me then
<wingo>i would keep <let> how it is, fwiw
<wingo>at least in tree-il
<mark_weaver>but that question can be considered separately, as it doesn't affect the 'define-values' implementation.
<wingo>unless you were just thinking about the residual fixing-letrec code
<mark_weaver>hmm, well, actually I guess 'fixing-letrec-reloaded' augmented for multiple values will want to produce 'let-values' nodes.
<mark_weaver>again, in order to avoid fixing the order of evaluation prematurely.
<wingo>i wouldn't worry too much about that, fwiw -- cps conversoin would happen right after fixing letrec
<wingo>so order of evaluation is practically fixed already
<wingo>also it's not impossible to commute the order later, in many cases...
<wingo>given effects analysis
<mark_weaver>well, effects analysis can only work where calls to top-level procedures are not made.
<mark_weaver>the thing is, if there's ever a time in the future where we might have an optimization that could benefit from playing with the order of inits in a letrec-values, we cannot hope to achieve that without adding a 'let-values' tree-il node type. and we won't be able to do that very often, because of compatibility issues.
<wingo>there is a let-values already of course
<mark_weaver>otoh, I can sympathize with your desire to keep 'let's simple :)
<wingo>perhaps you are thinking of something else though
<mark_weaver>oh, in tree-il you mean?
<mark_weaver>ah there is! :)
<mark_weaver>oops, sorry about that.
<mark_weaver>nevermind :)
<wingo>np, maybe you meant something else
<wingo>that form only binds one producer to one consumer
<wingo>it's like an inlined call-with-values
<mark_weaver>sounds great. in that case, I guess my only request is to change <letrec> to <letrec-values>, and that will address all my concerns.
<wingo>i'm fine with it in principle; a little concerned about complexity, but hopefully that can be a tree-il thing and not a cps thing
<mark_weaver>If you prefer, I guess we could simply add <letrec-values> and still keep <letrec>. That would be fine too. I just figured it's better to keep the number of tree-il node types to a minimum.
<wingo>but we'll see, let me get back to finishing this cps thing
<mark_weaver>right, those nodes will all be gone before the ->cps pass.
<wingo>we can keep working in parallel and catch up in another week
<mark_weaver>sounds good. happy hacking!
<wingo>pareillement :)
<wingo>(sp? my poor french :P)
<mark_weaver>my french is extremely rusty, but it looks right to me for what little that's worth :)
<mark_weaver>damn, now I realized why <let-values> is not sufficient to avoid fixing order of evaluation: as you said, it only includes a single producer and consumer. well, we can talk about it later, maybe over email.
<mark_weaver>there's plenty of time to play with this stuff before 2.2.0 is released.
<add^_>It just feels so awesome when wingo, mark_weaver and civodul and others talk about the inner workings of guile, things that are going to change and future projects.
<mark_weaver>thanks add^_ :) it's a fun community to be a part of, without a doubt :)
<add^_>Indeed :-D
*mark_weaver carefully reads Guile's '=' implementation for bugs, in light of weinholt's recent discovery (ugh)
<add^_>Yeah, that was a strange one..
<mark_weaver>numbers.c line 6538 (stable-2.0) says "dxx is at worst 1 bigger or smaller than xx", which is false. I suspect the code still works, but I need to fix this comment.
<add^_>Hm, I wonder why my guile is still on stable-2.0 and not master, I thought I changed that..
*add^_ goes on to update to master *again*
<mark_weaver>damn, there are a bunch of subtle bugs in our numeric comparisons between fixnums and inexacts.
*mark_weaver goes bug hunting
<mark_weaver>(bugs caused by converting the fixnums to doubles, which loses precision on 64-bit systems)
<mark_weaver>e.g. (< 2305843009213693951 2305843009213694000.0) => #f
<mark_weaver>it's tempting to always convert the inexact to exact first, but I should try to make it faster than that.
<mark_weaver>(= 2305843009213693951 2305843009213694000.0)
<mark_weaver>(sorry, that last one was meant to go to my repl :)
<mark_weaver>here's another: (= 2305843009213693951 2305843009213694000.0+0.0i) => #t
<mark_weaver>I guess one could argue that this kind of thing is acceptable, but it doesn't sit well with me.
<YoungFrog>with emacs lisp: (let ((num 2305843009213694000)) (< (- num 1) num)) => nil
<mark_weaver>Hmm. I get #t on my system. What version of guile are you using?
<mark_weaver>or are you using plain emacs?
<YoungFrog>Sorry, I meant the emacs implementation of emacs lisp
<YoungFrog>(otoh such failures are to be expected: (+ 1 536870911) => -536870912 (from the doc of emacs)
<mark_weaver>yeah, plain emacs does not have bignums, so integers can overflow.
<YoungFrog>this was essentially useless noise
<YoungFrog>sorry about htat
<mark_weaver>no worries :)
<add^_>CL gives True :-/
*add^_ just fills the white-noice with some pink-noice
*youlysses wonders how trivial it-would be to write a white-noise generator.
<add^_>Oops, I missed that xD