***jao is now known as Guest67107
***Guest67107 is now known as jao
*dsmith builds master for the first time in ages *dsmith gets an undefined reference to undefined reference to GC_get_heap_usage_safe *dsmith installs the right libgc and continues <davexunit>I'm wrapping up some dynamic state changes in a "with-foo" macro. I'm in a situation where I want the return value of what I pass in, but I get the return value from the nullary procedure instead (since it's the last statement). Thoughts on a nice way of returning what I want without using set! ? <davexunit>or do I just need to use set! on some variable I define earlier? should it be expected that a "with-*" procedure return the value of input, rather than the nullary procedure? <davexunit>yeah I guess I could just do something like: (let ((foo ...)) foo) <dsmith>In your macro, (let ((retval passed)) (the-nullary-procedue) retval) <davexunit>I don't know what the expected behavior of a "with" procedure should be, I guess. <dsmith>Well, it's customary to return unspecified when you are not really returning a value. <dsmith>That can usually be got from (if #f #f) <dsmith>IF you with* macro means "return this value after calling this proc", then of course return you value. <davexunit>I think it should return unspecified, after thinking about it. <davexunit>talking about it cleared my head enough to think a bit better. <dsmith>Yeah, that is often the case. Just coalescing the vague thoughts into words often crystallizes things. <davexunit>in my case, I can just move the statement I care about outside of the with-* block. <davexunit>trying to follow wingo's lead and wrap up OpenGL state changes with macros. <mark_weaver>and it's probably better to use *unspecified* than (if #f #f) *dsmith notes that make check had only one failure. In sxml stuff surprisingly <mark_weaver>it's because string ports are limited to the current encoding. <mark_weaver>and one of the earlier tests sets the encoding to something weird. <dsmith>mark_weaver, And so it works fine when you run the test by itself? <davexunit>I didn't have to change my macro at all and I also didn't have to use a set! anywhere in the code that uses the macro. <dsmith>In the new elf .go format. I wonder if the elf "program interpreter" could be (basically) libguile.so. IF so, then I think it could be possible to compile a guile "script" to a binary and then be able to just exec that binary.... <dsmith>You woudn't even need the source. <dsmith>Tis a wingo question, of course. But I'm just thinking out loud.. <cky>mark_weaver: IIRC, *unspecified* is an identifier-syntax that expands to (if #f #f) anyway. <cky>Granted, it's easy enough to replace with an identifier-syntax that expanded to (values) (see comment above *unspecified*'s definition in (ice-9 boot-9)), so perhaps that's why it's recommended over (if #f #f). <dsmith>Well, at this time, the INTERP program header is not included. Only LOAD and DYNAMIC. <mark_weaver>I continue to think it would be a bad idea to change *unspecified* from (if #f #f) to (values). <mark_weaver>IMO, (values) should be called something different. Maybe '*void*'. <cky>Well, of course you break all sorts of things when you change *unspecified* to (values), because it's used in all sorts of places that expect one value. <mark_weaver>right. and its name refers to "unspecified value" which is very often used in the scheme reports. <mark_weaver>and although it's sometimes used in cases where 0 values would make more sense, that's not always the case. ***rixed_ is now known as rixed
***DerGuteM1ritz is now known as DerGuteMoritz
<taylanub>I wonder why ,optimize (let ((x 0)) (if (= x 1) (set! x 2)) x) doesn't result in 0. <taylanub>,optimize (let ((x 0)) (if (= x 1) (display x)) x) does result in 0. <wingo>set! is generally not optimized <wingo>any variable that is ever possibly set! i mean <china-kang>It's too hard to build the lastest version of Guile in windows <dsmith>wingo, Heya. So could it be possible to point the ELF interp in the program header to something like libguile? So then scripts could be compiled to .go files and be directly executed? <dsmith>wingo, Just built master yesterday for the first time in ages... <wingo>dsmith: maybe, though it wouldn't be portable <dsmith>Ah yes. All the world is not ELF <cky>Microsoft and Apple would have you believe all the world is COFF and MachO, respectively. ;-) <Soft>does anybody know if the guile gnome module is supposed to work with the current version of Guile? <sneek>Welcome back shanecelis, you have 1 message. <sneek>shanecelis, mark_weaver says: the issue you found is not related to Guile. The following also fails: int main() { foo: int a; }, but if you add a semicolon after the label then it works. GCC from Debian Wheezy says: "error: a label can only be part of a statement and a declaration is not a statement" <cky>shanecelis: It's the new VM that will be in Guile 2.2. <cky>shanecelis: You'll have to ask wingo about it. I don't know anything about it other than that it kicks ass. <cky>I bet the "R" probably stands for "register", but that's about all I know. <cky>It's a register-based VM, unlike the current 2.0 VM. ***sneek_ is now known as sneek
<taylanub>And Guile's is not the GCC one, but a self-baked one, if I'm not mistaken. <fbs>its actually resistor transistor logic. Scheme is compiled into a circuit and then fed into a simulator ***sneek_ is now known as sneek
***CaptainLex is now known as CaptainLex|AFK
***bitdiddl` is now known as bitdiddle