IRC channel logs
2013-07-13.log
back to list of logs
<taylanub>Alternatively, if the index is `*', it only dereferences. (bytestructure-ref bs '*) would evaluate to another bytestructure, one encapsulating only the struct. *taylanub goes to add pointers to the documentation, then push. <taylanub>Hrm, I might want to make the code allocate bytestructures and fill pointers automatically when null pointers are encountered. I also need to complete the test-suite for pointers .. I'll do all this tomorrow, too tired. <taylanub>Weird, I would've expected the following to segfault or so: (let ((addr (pointer-address (bytevector->pointer (make-bytevector 3))))) (gc) (pointer->bytevector (make-pointer addr) 3)) ;What is it that protects the bytevector from GC ? <taylanub>Oh wait, advantage of conservative GC! :D <taylanub>Actually, since a Guile number's stack-representation is a different C value than the numeric value it holds, I'm not sure now if it's related to the conservative GC. Well, maybe the address is a bignum; I don't know how things look on the heap. But what's most weird is that, even when I set addr to (- (pointer-address...) 1000), then (gc), then do (make-pointer (+ addr 1000)), it still works. <taylanub>I can't explain this. I also did (clear-value-history!) a couple times in the REPL, although it shouldn't be relevant; maybe there's some other REPL stuff that for some weird reason protects the object. <taylanub>ERROR: In procedure read_bytevector: Error while printing exception. <taylanub>Happens when you #vu() instead of #vu8() apparently. <cluck>taylanub: there, there, don't cry, you're not really alone :D <taylanub>I should use the mailing-list more often, but then there's often minor passing thoughts which aren't worth an e-mail but still worth a chat. <taylanub>I wish the default value for optional arguments would be the unspecified value and not #f; is *much* less likely to be a problem (#f is often a valid value the user wants to pass *explicitly*), and the code reads better: (if (unspecified? foo) ... ...) <cluck>taylanub: otoh (if foo ...) is shorter ;) <taylanub>Sure, but IMO the problem of not being able to pass #f in that case trumps that advantage. <cluck>passing false values around?! what are we now politicians?! <taylanub>It's funny that the name "unspecified" is accidentally so fitting in this situation. <dsmith>taylanub, In C, there is a value that is passed for option args. Like when you call (display) without a port. I don't remember what it is right now, but it's NOT #f. <taylanub>I think it's SCM_UNSPECIFIED but is not the same as #<unspecified> or something. :P I reckon some funny issues wrt. the several "undefined," "unbound," and "unspecified" values and their different C and Scheme names. <cluck>taylanub: yeah, we just need to rename the helper functions to attachés and we'll have quorum <dsmith>I don't know if it's possible to see that from Scheme though <taylanub>Yeah, it isn't, although you can query a "variable" object to see if it's unbound, which works on the C level by filling that value into it. <dsmith>scheme@(guile-user)> (define foo) <dsmith>scheme@(guile-user)> (display foo) <dsmith>#<unspecified>scheme@(guile-user)> <taylanub>Yeah, `define' must be doing that itself. To observe the effect of the Scheme-invisible UNDEFINED value, you can (module-add! (current-module) 'foo (make-undefined-variable)): http://sprunge.us/EFXE <kejoki`>Someday I will have the "aha" moment with call/cc. I'm looking forward to it. <sigh /> <cluck>am i the only one vying for the dethronement of call/cc? we can do better <taylanub>cluck: Guile already implements it in terms of delimited ones. :) <taylanub>But it's probably easier to explain than delimited ones, so for pedagogical purposes it can be used as a stepping-stone. <cluck>but, but, portable code! (cue the competition sucks motto)