IRC channel logs


back to list of logs

<dsmith-work>davexunit: Hmm. I assume you started from a completely clean checkout? (git clean -dxf)
<dsmith-work>Is there an ice-9/psyntax-pp.go ?
<dsmith-work>And what does file say it is?
<dsmith-work>$ file module/ice-9/psyntax-pp.go
<dsmith-work>module/ice-9/psyntax-pp.go: ELF 64-bit LSB shared object, no machine, version 1, dynamically linked, not stripped
<dsmith-work>That's what mine looks like
<dsmith-work>You can dig stuff out of it with readelf too
***CuneytArkin is now known as VonCuneytArkin
<VonCuneytArkin>On that note, dsmith-work, like, if you reference a binding in guile that is not yet defined, it raises a runtime exception rather thna compile time error right?
<VonCuneytArkin>I always thought a runtime model like that was prohibitively slow, as it actually has to with each evaluation of a binding look fetch something from some environment, or am I mistaken?
<davexunit>dsmith-work: gah sorry gotta go afk, I'll investigate later. thanks for trying to help.
<dsmith-work>VonCuneytArkin: Not the expert here. But the compiler is pretty good for things that are visible
<dsmith-work>VonCuneytArkin: No inter-module optimization. Or even top-level?
<dsmith-work>mark_weaver: Do you remember?
<dsmith-work>VonCuneytArkin: Check out
<davexunit>dsmith-work: build worked this time. I guess I didn't clean up properly the last time.
<dsmith-work>davexunit: Yeah, it's always a good idea, as master is moving so much, the make dependencies might not get everything just right.
<vinipsmaker>what's the state around guile-emacs integration work? I follow this project every year
<davexunit>vinipsmaker: I haven't heard a peep about it, unfortunately.
<vinipsmaker>davexunit, there isn't much info on the mailing list archives also. i'll ask on the #emacs channel too
<davexunit>I don't think they will know, either.
<davexunit>if anyone would know, it would be wingo, the mentor.
<vinipsmaker>i see the student is the same every year
<vinipsmaker>was wingo also the mentor every year?
<davexunit>not sure
<paroneayea>I think he wasn't a couple years ago
*paroneayea wishin' and hopin' for a guilemacs
<mark_weaver>VonCuneytArkin: top-level variable references are cached, so the lookup doesn't happen on every evaluation.
<mark_weaver>the module dictionary maps identifiers to variable objects, which are objects that contain a mutable slot for the variable's value.
<VonCuneytArkin>mark_weaver, alpha-aequivalent function definitions are not compiled to the same code though right?
<ijp>we don't try to merge them
<VonCuneytArkin>I won't profess to know a lot about writing efficient implementations, but to have variable objects or names existing at runtime seems costly.
<VonCuneytArkin>Gives great debug info though.
<VonCuneytArkin>Maybe I should actually once write a compiler for a simple language to get an idea how it's done, all I've managed are poor interpreters that actually walk the syntax tree.
<mark_weaver>well, it's the cost of being able to evaluate arbitrary code at run-time, being able to add code to the system at run-time, etc.
<mark_weaver>non-toplevel variables are much more efficient.
<mark_weaver>even ELF shared libraries contain the names.
<VonCuneytArkin>Hmm, so they are done differently?
<VonCuneytArkin>Well, I guess that makes sense with the unbound reference thing.
<mark_weaver>since non-toplevel variables can only be accessed within their scopes, we don't need to keep the names around. for one thing, any non-toplevel variable that is never set is immutable, and thus doesn't require a mutable slot, and can be optimized heavily. they can be completely optimized away in some cases.
<mark_weaver>our compiler does issue warnings about references to non-existent toplevel variables.
<mark_weaver>but it cannot be considered an error because the variable might be available at runtime.
<VonCuneytArkin>Yeah, so that does make (lambda (x) x) and (lambda (y) y) compile to the same code in the end?
<mark_weaver>yes, they compile to the same code.
<VonCuneytArkin>How do you make a variable available at runtime that's not there at compile time?
<mark_weaver>modulo debugging info perhaps
<VonCuneytArkin>In racket at least, I liked how it complained about unbound variables at compile time.
<VonCuneytArkin>As in, refused to compile.
<mark_weaver>modules are first-class objects. there are procedures to add bindings to them at runtime, etc.
<mark_weaver>or simply use 'eval'.
<VonCuneytArkin>Hmm, yeah, I guess that would require it
<VonCuneytArkin>I guess racket doesn't have that stuff.
<mark_weaver>R6RS has a much stricter module system. modules are immutable objects.
<ijp>VonCuneytArkin: even supposing we do not have first class modules, we need a way to allow definitions from C code
<VonCuneytArkin>I'm always on the fence about this kind of "powerful" in languages in a way.
<VonCuneytArkin>ijp, which can be altered at run time?
<ijp>they need to be added at runtime
<VonCuneytArkin>I'll confess I mostly use guile as an r6 implementation
<VonCuneytArkin>These kinds of choices in implementation writing are kind of interesting, I wish I knew more about it.
***fangism is now known as fangism-hongry
<nalaginrut>morning guilers~
<ijp>it would be nice to have an ,expand-1
<nalaginrut>expand once?
<ijp>yes, just the outermost macro
<nalaginrut>I checked the current master, seems the register allocator hasn't been added yet.
*nalaginrut is surprised that Guile could use the classical CFA approaches, he thought it's definitely k-CFA even before he read wingo 's blog, because of some info from stackoverflow...
<civodul>Hello Guilers!
<wingo>heya :-))
<sneek>Welcome back wingo, you have 1 message.
<sneek>wingo, ArneBab_ says: I got a unicode error with current master and the function name spielfähig when importing the module.
<civodul>howdy wingo!
<civodul>wingo: are you going to the GHM?
<wingo>civodul: i have slipped on planning but i certainly should!
*wingo looks at tickets
<civodul>would be cool
***fangism-hongry is now known as fangism
***VonCuneytArkin is now known as homo-eroticaXL