IRC channel logs


back to list of logs

<ZombieChicken>Is guile installed on most Linux systems?
<saul>ZombieChicken, yes.
<ZombieChicken>thank you
<saul>Maybe not on Busybox/linux, but certainly on GNU/Linux.
<ZombieChicken>if busybox is the userland, I wouldn't expect much else to be installed
<saul>ZombieChicken, TInyCore is Busybox-based and it is fairly complete (but does not include Guile).
<ZombieChicken>I didn't say it wouldn't have anything else, but I wouldn't expect it. Tinycore is a 'desktop' distro iirc
<nalaginrut>morning guilers~
<nalaginrut>it's easy to cross-compile Guile into embedded board
<nalaginrut>even if you use Busybox
<ZombieChicken>I was just about to ask if guile played well with uclibc
<nalaginrut>'s been a while since I played it on embedded board, so I can't remember if it's uclibc at that time
<nalaginrut>ZombieChicken: if you tried it, please tell ;-)
<ZombieChicken>I haven't
<dje42>anyone have an opinion on srfi 41 (streams, lazy lists) ? I was looking into it as a way of iterating over some gdb objects without having to create the full list first
<ijp>well, it'll work, but it is in a sense suboptimal, because if you are generating it through somestateful process, then all the list elements have to be fully evaluated in order, and so you are wasting an indirection for each entry
<ZombieChicken>Is there a simple, concise book covering Scheme, like K&R for C?
<ijp>I forget how much K&R covers, but there is the little/seasoned schemer
<ijp>though neither of those cover macros
<ijp>or quite a few other things for that matter, like IO
<ijp>but naturally, portable IO in scheme is rarer than the antartican phoenix
<ZombieChicken>I'm interested in something simple so I could start playing around. I have SICP, but I'd just like something simple so I could actually play with the language a little bit faster
<ZombieChicken>saul: Thanks. Not what I'm looking for exactly, but that is handy.
<wingo>subrs are rtl stubs in master now
<wingo>makes things slower in order to make them faster (?)
<ijp>taylanub: it would be semantically incorrect to use one definition for old code, and one for new code
<taylanub>Hrm, in a way this already happens for syntax and inlinable definitions though, or is that something different ?
<ijp>by the time mutations occur, the syntax has been expanded away
<ijp>if you did have fexprs, then you would need to undo them
<taylanub>When you say semantically incorrect, do you mean intuitively, backwards-compatibly, according to a standard, ... ?
<ijp>all three
<taylanub>Eheh, OK
<ijp>consider the simple factorial function (define (fact x) (if (zero? x) 1 (* x (fact (- x 1)))))
<ijp>what happens if you do (define factorial fact) (define fact list) ?
<ijp>and then call (factorial 10)
<ijp>don't evaluate it, tell me what you think it should do
<bubble>I am trying to make a OOP version (with or without actors) of server-side scripting, woule I still need to take on guile-oops for that or is another OO system imminent ?
<bubble>I am looking at seaside smalltalk for this
<ijp>what do you mean by server-side scripting
<ijp>that sounds like a basically meaningless term
<bubble>What the "cool ideas" page says on
<ijp>the one which says "this page is old ignore it" on the top
<ijp>yes, exactly
<ijp>there are no new OOP systems planned
<bubble>what about the web scripting ? is it guile-www ?
<bubble>the tarball I mean
<ijp>use guile-www if you want, I wouldn't
<ijp>taylanub: anyway, I chose a terrible example, that one =should= error
<bubble>ok, I noted __builtin_expect, maybe make that into a AI. Then translating code for rtl to change archs would not be too bad
<ijp>if fact could never set!, you could optimise the recursive call to jump right to the definition
<bubble>just my 2 cents
<ijp>was never
<ijp>this is not as frivilous an example as it looks, because you can e.g. bind a top level handler for the web server, and then change it dynamically
<ijp>for a similar reason, you need to care about mutability if you want to do eta reduction
<ijp>actually, there is another issue with eta reduction relating to call/cc but that isn't relevant hee
<ArneBab_>ijp: (factorial 10) should then intuitively give '(10).
<ArneBab_>ijp: but it could also give (whatever-fact-pointed-to-before 10)
<ArneBab_>the former would be easier for beginning programmers, but both seem equally intuitive to me (nowadays)
<bubble>wingo : May I ask where guile-figl gets its toplevel window ? Where the code for that is in guile ?
<ijp>well, no, it errors, because the example was broken
<ijp>so you try to multiply by a list
<ijp>if you take the latter behaviour, then you can't have recursive loops that can be changed
<ijp>and I gave the example of server handlers
<ijp>the semantics of scheme are very simple, if you have a function all (foo 1), you look up the current value of foo, and try to apply it the the value 1
<ijp>if you have (lambda () (foo 1)), you need to make sure that it always refers to the current value of foo when that function is called
<ijp>the purpose of optimisation is not to make code fast. it is to make code fast, _while_ preserving all the observable behaviours of that code
<ijp>otherwise we can just compile every program to int main () {return 0;} and call it a day
<ijp>if your code does something different after the optimiser is through with it, it hasn't been optimised, it has been broken
<taylanub>ijp: I kind of didn't think of the possibility of a module set!ing one of its own top-levels that it declares as copy-on-write ...
<taylanub>I'll think more about this later, sadly have to get to work now. :P
<ijp>it doesn't have to while modules are open
<ijp>you peek inside, twiddle about, leave
<ijp>wingo: just out of curiousity, why are you removing glil, objcode &c
<ijp>I don't suppose anyone else is generating it, but still
<ijp>also, are you introducing any backward incompatible changes in treeil?
<ijp>it'd be a shame to have to lose that chunk of the manual, it is one of the nicer parts to read
<wingo>bubble: it's from glut
<wingo>ijp: if a thing has no purpose, it should go -- i am removing the old vm too
<wingo>there are tree-il changes, yes
<ijp>that one could be annoying, since people do actually generate it
<bubble>wingo : so if I understand, you need guild for an API
<bubble>.go == guild object
<ijp>I'm just going to push that self-quoting vector change to the manual
<gzg>bubble: Is it really? Not looking into it at all, I just assumed it was "guile output". :^U
<bubble>gzg :
<ZombieChicken>Silly question; what is the standard file extension for a Scheme file?
<gzg>ZombieChicken: *.scm
<bubble>back in the day also .ss .s
*gzg really needs to stick himself in the manual one of these days. :^U
<ZombieChicken>.scm makes sense, but .ss and .s are good to know
<gzg>bubble: How long ago was "back in the day"?
<bubble>1995 :-)
<ijp>I've never seen .s, but there is still code in the racket repos with .ss
<ZombieChicken>That was quite a while ago
<gzg>Aw, I was still just a babe then. :^)
<ZombieChicken>How long as scheme been around?
<ijp>it was their preferred extension up until the name chaneg
<ijp>ZombieChicken: 40 years
<bubble>1986 IIRC
<bubble>as a "Lisp dialect"
<ZombieChicken>bubble: What do you mean "as a 'Lisp dialect'"?
<bubble>dialect in Dutch is "sublanguage", things with an accent
<gzg>ZombieChicken: Lisp is a family of languages, Scheme is a sub-language, or "dialect".
<gzg>bubble: Why are you always a half-a second ahead of me?! :^)
<bubble>there's clisp for that in
<ZombieChicken>gzg: I know that. I was just wondering if there was something specific bubble meant by that statement
<bubble>dunno :-)
<ZombieChicken>gzg: bubble was about 12 seconds given my timestamps
<ZombieChicken>s/given/faster given/
<gzg>ZombieChicken: Will, I meant the initial response more-so and it's a figure-of-speech. :^P
<ijp>today in stupidity, lookin in the version 1.8 info page
<ZombieChicken>ijp: what is it?
<ijp>out of date
<bubble>indeed, guile 2.2 needs more docs
<ijp>well, that isn't the issue here
<ZombieChicken>There a big change between 2.x and 1.8?
<bubble>I think so, there's lots of new features
<bubble>things such as guile-figl etc are packages devved for a better guile such as perl's h2xs
<bubble>due to guild (old guile-tools) as I said
<bubble>it givesa larger user base
<bubble>which is cool for Scheme
<ZombieChicken>ok. Let me rephrase the question
<bubble>back in the day *lol* you only had bindings
<bubble>libguile 1.6
<ZombieChicken>Is there anything in 2.x that is would affect a newbie trying to learn scheme?
<ZombieChicken>as opposed to 1.8
<ijp>ZombieChicken: the basics are all the same
<gzg>ZombieChicken: I couldn't imagine what.
<ZombieChicken>That is good to know
<bubble>rsr7 + guile dependant features
*gzg is writing an introductory text, to actually teach himself to a much greater degree. :^)
<ijp>wingo: would you mind giving me a yes/no on my peval bug fix sometime this weekend?
<ZombieChicken>bubble: My scheme book is SICP. I imagnine the new standard is newer than the book
<bubble>I read that in 1996
<bubble>meta systems, REPLS
<ZombieChicken>I have my arm resting on it right now
<ijp>guile does not support r7rs, nor is there any immediate plan to
<ZombieChicken>well, in it
<ijp>nor will it matter for ZombieChicken
<gzg>ijp: Well it's not even finalized yet, is it? :^)
<bubble>yes indeed
<ijp>no, and large never will be
<bubble>I wrote snow for s48 a while ago, as a prototype
<ijp>not that it should, but that's a whole other matter
<gzg>ijp: Optimism!
<bubble>s48 == scheme48
<ijp>gzg: I stopped being optimistic when I learned that not a single one of the r7rs wg took exceptions seriously
<ZombieChicken>Would any of you say Scheme is moving towards a more standard enviroment? What I've read has said that Scheme is rather implementation dependant for a number of features
<ijp>ZombieChicken: no
<ijp>and jcowan and I have major, shall we say philosophical, disagreements over what it means for something to be a standard
<ZombieChicken>I thought that that would be a fairly consistent definition
<gzg>ijp: Eh, I'm not well versed in enough in this world to really form a strong view either way; So, I'll take/leave your concerns as real potential problems. :^P
<ijp>ZombieChicken: there are two major definitions, the one everyone outside of computing uses, and the one people in computing use
<ijp>I take the former, he takes the latter
<ZombieChicken>And what is the definition you use?
<ijp>anyway, this is not your concern yet
<bubble>maybe as ZombieChicken is reading, put something of a slib in guile which is r6rs
<ijp>r6rs is dead
<bubble>except for old schemers then ?
<ijp>not even them
<bubble>I don't know what that board is saying
<gzg>For the sake of Guile and it's place within and relevant to the GNU system, I'm not particularly worried if we/they stay "upstream" in-terms of the standard as long as all the cool bits and bytes are implemented in some fashion. :^P
*bubble goes back to his seaside scheme
<gzg>bubble: Well, I mean this is an implementation more-or-less focused for/around the GNU OS and related projects, there's no real pressing need to have a large standard library to-which needs implemented , for other implementations, with a bit of work, could possibly, maybe do close to the same thing. :^P
<bubble>true that's the industry versus the rest
<ZombieChicken>Sorry for all the questions. I'm a curious individual
<bubble>which is ok :-)
<ZombieChicken>How portable is scheme code?
<ZombieChicken>between implementations
<ijp>not very
<bubble>continuations come to mind last std
<ijp>you want to handle erros gracefully? tough luck
<gzg>ZombieChicken: Not very; Certainly not comparable to CL. This is pretty much the 1st step in "correcting this" via the means of R7RS large.
<ijp>gzg: that is not even close to true
<ZombieChicken>I know CL covers a ton of stuff, plus there is asdl and quicklisp for various things. It is also a much more complex language
<ijp>it's basically a rebranded srfi process
<gzg>ijp: Good, if I'm spewing sand out of my mouth correct me; I should have prefaced this statement with "to my very limited knowledge". :^I
<ijp>there is little obligation to support any or all or r7rs large, and they are springling on liberal doses of "implementation dependent" for good measure. don't want to accidentally have code work right on two different schemes.
<ZombieChicken>Ok. how do I run a script with guile? Shebang doesn't seem to work
<bubble>#!/bin/guile \\n!#
<ijp>the !# is important
<bubble>or guile -s proggy.scm
<ijp>though you should get an error if you don't include it
<bubble>ZombieChicken: man guile
<bubble>do read the runtime switches
<ZombieChicken>guile --help seems to be lacking a few options
<bubble>s/runtime/command line
<ZombieChicken>buil #!/usr/bin/guile \\n!# doesn't seem to work
<bubble>\\n == real newline ?
<ijp>do you actually have a guile at /usr/bin/guile ?
<ijp>and which switches are not documented in --help?
<ZombieChicken>ijp: -s
<ZombieChicken>this is guile 1.8.8
<taylanub>That's veeeeeeeery old.
<ijp>1.8.8 is not getting an update
*bubble notes his command line switches have gone
<ijp>more to the point, it does mention -s
<ZombieChicken>hence my questions before about the diff between 1.8 and 2.x
<ijp> [-s] FILE load Scheme source code from FILE, and exit
<bubble>sorry, 1.6 had -s -i
<ZombieChicken>ijp: Yeah. I seem to be blind
<ZombieChicken>Well, that is a thing
<ZombieChicken>Ok, this may sound strange, but is there a sane way to run a .scm file using sh ./
<ZombieChicken>I have it working using ./foo.scm
<ZombieChicken>but I'm just curious of the other can be done sanely
<taylanub>ZombieChicken: "Sanely" I don't know but there's always hacks possible with shell scripts (or any executable) where the initial part of the executable file has some code that finds the executable itself, cuts out this initial part (currently being executed in memory), and the rest of the executable is some "payload" with which it can now do anything it wants.
<taylanub>You can have self-extracting archives like that, and wrappers for different kinds of code, etc.
<ZombieChicken>I could imagine some ugly code using heredocs and/or a self-parsing script
<ijp>I have some shars lying around somewhere, I feel dirty whenever I remember them
<ZombieChicken>neither of which I call sane
<taylanub>I've very recently seen someone use this mentioned hack, was on the Guile mailing list .. let me dig it out.
<bubble>its something as py2exe for python
<taylanub>OK, I can't find it.
<ZombieChicken>no worries
***anderson is now known as Anderson
<ijp>cky: ping. what is the state of the define-macro rewrites?
<mark_weaver>ijp: I'm not so sure that R6RS is dead. It needn't be, if some good implementations continue to support it, and code continues to be written for it.
<mark_weaver>ZombieChicken: why do you want "sh ./foo.scm" to work? That explicitly says to interpret ./foo.scm as a shell script. why would you want to do that?
<davexunit>./foo.scm would work with the proper shebang
<davexunit>is it possible to use generic functions without classes?
<davexunit>generic functions seem really appealing to me for part of guile-2d's API, but I don't think I really need to use classes or other OOP things.
<dsmith>davexunit, You at least need to have types to dispatch to the right function
<davexunit>dsmith: so record types would do?
<davexunit>I'm trying to translate an idea that I have seen in many game libraries for object oriented languages.
<dje42>davexunit: data point: generic functions work with smobs (which aren't real goops classes)
<davexunit>I suppose I could also just my own hash table or something that maps a type to a set of procedures.
<dsmith>davexunit, No, I don't think so. You can dispatch on smobs, like dje42 mentioned.
<ArneBab_>davexunit: from what I saw about generic functions, it would be quite feasible to provide the generic functions as an api: something drawable is something for which the developer defined a draw function.
<ArneBab_>davexunit: but beware: I’m very, very much a beginner here
<ArneBab_>(define-method (draw (x <mythingi>)) … )
<dsmith>davexunit, Does class-of work with those record types?
<davexunit>dsmith: yes.
<davexunit>just tried it out.
<dsmith>Cool. Probably can do it then.
<davexunit>so I guess that means I can make generic functions like that, then.
<dsmith>davexunit, Try it!
<davexunit>my other question is: does this makes sense to do here?
<davexunit>I'm not sure how to do it otherwise. all of the scheme code I've written before this hasn't used any OOP.
<dsmith>davexunit, If it makes it easier to read write and contemplate your code, sure.
<ArneBab_>davexunit: what interface do you want to provide?
<ArneBab_>davexunit: I think starting with the code a game should have would be useful here. Do you write a game while writing guile-2d?
<davexunit>ArneBab_: I just write small example programs.
<davexunit>I have a game in mind that I want to write, though.
<mark_weaver>davexunit: in GOOPS, everything has a class, including primitive types like booleans and symbols.
<mark_weaver>davexunit: you can always ask (class-of <object>)
<davexunit>mark_weaver: thanks
<mark_weaver>so yes, you can use generic functions to dispatch on other things.
<ArneBab_>davexunit: I hope that I’ll be able to use guile-2d, though I have some structures I planned for my games which I’ll have to see whether they can be used with guile-2d
<ArneBab_>davexunit: the current version is in python and the structure partially relies on python-features
<ArneBab_>davexunit: my basic plan looks like this:
<ArneBab_>davexunit: 2 blocks of functionality: Interaction (GUI state, show GUI state, take input) and Logic (model state, take commands, give results)
<davexunit>ArneBab_: I don't see why you couldn't that in guile-2d.
<davexunit>it just might not have all the features yet to make it a pleasant experience for you.
<ArneBab_>davexunit: with the interaction between both happening only from Interaction(UI state) to Logic(take commands) and Logic(give results) to Interaction(GUI state).
<davexunit>ArneBab_: I'm currently trying to write an API for game states, which is why I have all of these generic function questions.
<ArneBab_>davexunit: maybe I can provide some questions for that :)
<davexunit>I would like to make a data type to describe a game state. trouble is, each state has different callback procedures and different data that it operates on.
<ArneBab_>davexunit: where do you need which state? → actors with their own state, the level with actors as state + start and finish conditions.
<ArneBab_>though that is specialized for an RPG
<ArneBab_>(many actors which interact and take their own decisions)
<davexunit>I am writing game states as a high level concept to break up the main portions of a game. examples would be: main menu, battle screen, high score screen, etc.
<ArneBab_>so a game state is something which provides a minimal API for the currently active part of the game (finer than level, but close)?
<davexunit>yeah something like that.
<davexunit>the game loop will know the current state and will call update, draw, key-down, etc. using the callbacks for the current state.
<ArneBab_>there I see two different kinds of states: full states (you switch to level X) and temporary states (you hit pause - goes back to the previous state on escape)
<ArneBab_>davexunit: something like a stack of states which have 2 different options: switch to another state and leave state (goes back to the “higher” state).
<ArneBab_>(that would be the minimal state switching API)
<davexunit>ArneBab_: yeah I'm using a stack as well.
<davexunit>push, pop, and replace (pop and then push)
<ArneBab_>sidenote: I misunderstood “game state” as something like the current score or the lives you have left.
<davexunit>that would be part of *a* game state.
<ArneBab_>davexunit: a slightly complex topic: How to handle preloading of a potential next state.
<ArneBab_>→ maybe add “load” to the API of states
<davexunit>don't know. I don't see the need to preload really.
<ArneBab_>the need is that you will want to avoid unecessary load times on complex levels
<davexunit>that would be for the game programmer to work that out.
<davexunit>preload assets on game load or be smarter about it in a game state. either is possible.
<ArneBab_>the way how you handle pop and push can make that easier or harder
*ArneBab_ made the mistake of making the state something which gets created on push → no preloading possible, except by using cludges like precaching data.
<ArneBab_>people will do whatever is easiest, so the easiest thing to do should be the desirable thing to do on the long run ☺
*ArneBab_ sadly needs to get going
<ArneBab_>davexunit: It’s cool to see you hack on guile-2d!
<ArneBab_>(and I wish I had more time to help - but I try to help when I have some free minutes, even if it’s only by adding ideas which you might have to discard ; I hope they help anyway, if only to sharpen your idea of why you choose the path you take)
<ArneBab_>cu and Happy Hacking!
<davexunit>happy hacking
*stis made a propsal to make vhashes thread safe
<wingo>stis: what do you mean by "using the source as a standard lib" ?
<stis>loading an .so
<stis>yes I'm pretty bad with words as you know.
<wingo>heh, np :)
<wingo>i'm super-skeptical about many "just use C" strategies
<wingo>the compiler will already give a big speed boost and i'm sure there are algorithmic things too that can help
<wingo>the new compiler i mean
<stis>yes, in order to add C stubs we really need to know if vhashes are bottlenecks.
<mark_weaver>stis: how did you come up with that "30x" number? what precisely were you comparing to what?
<stis>vhash-assoc 1 .. 10 0000
<stis>sorry vhash-cons
<stis>vhash-then assq on the number 2000
<mark_weaver>but for the 30x faster version, did you add a VM instruction, or what?
<stis>did that 1000,000 times and looked at the timings
<stis>no the loop is in C
<mark_weaver>oh, well. that's not a fair test.
<stis>but I know that typically there is a 2x speedup for these objects using a VM op instead
*wingo appears to have borked master, working on fixing it
<stis>no, 30x is a target speedup, but a vm-op would probably be 20x. 30x is certainly possible with native compilation uiin guile
<mark_weaver>there's no "typical" here. it depends on what the operation does. if the operation is "vector-ref", then the ratio of how much faster it gets will be a lot bigger than if the operation is very complex.
<mark_weaver>in the scheme loop you wrote, a great deal of the time was probably spent in the loop handling: the counter increment, test, and jump.
<stis>well vhash-assoc seam to take about 200 cycles here. My feeling is for that beast this should be a good estimate
<wingo>heh, master is fine -- i had a locally miscompiled vlist.go here :P
<stis>the scheme loops handles about 10M to 20M oiterations, I did 10M in my C loop
<stis>wingo: :-)
<mark_weaver>it's really hard to make these kinds of estimates, even for those who have a lot more experience than you do.
<wingo>master seems to be about 10% less memory usage currently
<wingo>than 2.0
<mark_weaver>nice! :)
<wingo>on a guile -c '(sleep 1000)'
<stis>well these are the numbers I but it's not a proof, my experience says that i'm not to much off. But it is an aproximation
<wingo>hopefully that will improve when more things are rtl-compiled
<stis>wingo: cool!
<stis>Also I think as you say, using vlist/vhashes wrong, can have algoritmic problems.
<mark_weaver>the other thing is that one must be very careful about concluding too much from super-simple benchmarks like this. in these simple cases, the cache and the branch predictor will be able to perform much better than they normally do in most real programs.
<mark_weaver>a better test is to see how much is improves compile times, given that the compiler uses vlists and vhashes quite a bit.
<mark_weaver>s/is improves/it improves/
<stis>yep, but it's a good test if th working set is small, or if the working set are recent numbers. ANd i suspect that many logic programs has this propert
<wingo>tough to test on master atm though, given that it's in so much flux...
<mark_weaver>if one wanted to use the compiler to find out how much faster vlists are, one could use the profiler to see what percentage of time is spent in the vlist ops, while compiling a file.
<wingo>it used to be around 10% i think
<mark_weaver>or rather, how much time overall.. and then repeat the same compilation with a different vlist implementation.
<stis>yep, my interests is in using vhases for guile-log/kanren
<stis>I know that there the datastructure for the lookup are very critical.
<stis>Especially when we get into nativly compiled code
<mark_weaver>true, but also remember that when we have natively compiled code, then our current vlist/vhash implementation will also be native code.
<stis>Yep, but not today :-) Time will come to move it over to scheme, but not now
<mark_weaver>fwiw, I'm sympathetic to the position that vlists should be reimplemented in C, in fact I've proposed it before. If native compilation wasn't expected in the relatively near future, I'd still believe that quite strongly.
<mark_weaver>but at this point it might be better to wait and see how well we can make the Scheme version perform with native compilation.
<stis>and probably not with the first version of the native compiler can reach the speed of optimized C code.
<stis>gcc is very mature and I worked quite hard at optimizing the code.
<stis>I started with -O3 optimized code at 7x speedup
<wingo>i would be happier if we could determine which parts are considered to be slow
<wingo>if there are primitives that might be worth vm ops
<wingo>but tbh i think doing C stuff on that code is the wrong thing right now -- the potential gains with the new vm and a better compiler are too much
<mark_weaver>wingo: would it be possible to make a faster mechanism for calling out to arbitrary C code?
<wingo>mark_weaver: the rtl stubs are faster i think
<wingo>not hugely faster, but faster nonetheless
<wingo>certainly some little inline caches would be appropriate...
<mark_weaver>well, it might be worth thinking about whether we could have a specialized VM op for reducing the number of instructions in each of those stubs.
<wingo>perhaps elide the switch, and instead trampoline through a function pointer
<mark_weaver>(I haven't looked at the RTL stubs yet)
<mark_weaver>another question is whether we could make a faster mechanism for calling out to specially-crafted C functions that would manipulate the RTL stack directly.
<mark_weaver>basically, these would be kind of like RTL instructions, but outside of the actual VM engine function.
<mark_weaver>I dunno if it's a good idea, but it just popped into my head and I typed it :)
<mark_weaver>I'm motivated by the small 8-bit opcode size.
<dsmith>Would vlist/vhash implemented in C help the bootstrap evaluator?
<cky>ijp: I'll work on it more today. I took today off to get my wisdom teeth extracted, but I'm feeling pretty chipper at the moment (long may that last).
<ijp>cky: well, I'm not exactly in a hurry for it ;)
<ijp>but I was peeking though the bugslist, and there is no "we've replaced macros foo/bar/baz", so I figured 'd ask
<cky>I won't be posting to the bugs list just yet. I'll just be pushing my changes to a private branch.
<cky>(Nice thing about having commit access. ;-))
***linas__ is now known as linas
<dsmith>wingo, irreducible-loops-at-level warning. What does it mean?
<add^_>Hm, I'd completely forgotten that it was Friday..
<civodul>wingo: (system vm coverage) works with RTL programs?
<civodul>i guess that's a sign that it's in good shape ;-)
<civodul>and the FFI