IRC channel logs
2018-01-19.log
back to list of logs
<manumanumanu>I want to allocate a size_t and then read it back, but I can't reeally find how. <manumanumanu>chez has foreign-ref, which supports accessing any type, but the closest I can come is passing it a bytevector (sizeof size_t) <manumanumanu>I can of course do a ref depending on sizeof size_t, but that seems somewhat like a hack <ecraven>I don't know about guile :-/ but either you want to allocate a size_t and pass a *pointer* to it, or just pass the size_t directly <ecraven>well, size_t is just a typedef for some integer type <ecraven>chez's ffi is one of the nicer ones. I've never used guile's, so I can't comment on that <ecraven>well, guile must have a way of returning integers from foreign functions <manumanumanu>in chez, I can do (foreign-ref pointer type), but in guile I have to do some bytevector magic <manumanumanu>ecraven: I can read raw bytes from a bytevector. So, if the size_t is 8 bytes, i can do bytevector-u64-ref BYTEVECTOR_POINTING_TO_RAW_MEMORY <ecraven>but why is the size_t in a bytevector to begin with? can you show the function signature you wish to write the ffi function for? <manumanumanu>nono, returning integers or size_t's isn't the problem. Reading memory containing size_t is the problem <ecraven>as I said, what exactly do you want to read? a struct that contains a size_t? <manumanumanu>I have allocated (sizeof size_t), and I want to read it back. <ecraven>maybe you can use make-c-struct / parse-c-struct <ecraven>you can use pointer->bytevector, but you need to know the endianness and the size of size_t to parse it manually <manumanumanu>There are the native versions of bytevector-ref that should work <ecraven>you still need to know the exact type and size on the current architecture <manumanumanu>Maybe i'll write a macro that does all this with zero overhead. <ecraven>hehe, old unixen defined size_t to be a *signed* type :P <manumanumanu>not over here. unsigned-int is 4 bytes in guile, whereas this is a 64bit system, so size_t is 8 <ecraven>from my (totally limited) understanding of the guile ffi, that is the way to go <manumanumanu>ecraven: I don't know much C, so it feels good to have someone second my opinion <ecraven>you might want to look into (system foreign), maybe there's relevant code there <manumanumanu>ecraven: nah... It is easier just modelling it after how chez does it. I can even do it as a procedure, since I suspect peval will inline everything it can <manumanumanu>ecraven: but without pointer support, since guile can already dereference pointers and has a special representation for them. <cmaloney>ACTION got Guile working on a PocketBeagle a few weeks back and it tickles me that Ihave scheme in my pocket <cmaloney>(though right now it still needs a computer to power it / interface) <cmaloney>though compiling all of the scheme files about desoldered the processor from the board from how hot it was getting. :) <wingo>yeah the compiler thing is a little irritating :P <amz3>I wonder how people do to hack on guile with that compilation phase, it's very slow cycle of dev <wingo>on guile itself or things on top of guile? <wingo>did things improve with 2.0.3? <amz3>I don't know if things improved with guile 2.2.3 <wingo>in guile itself, it's knowing what needs a full rebuild and what can work with a partial rebuild <wingo>anyway i spend a lot more time editing, compared to compiling <amz3>that said I use guile 2.2.3. <cmaloney>Yeah, the compilation is a one-time pain <cmaloney>I mean, how many folks compile gcc from scratch or just rely on packaged versions? <cmaloney>(probably not the right channel to show how lazy one is with compiling gcc from scratch but w/e. I got nothing to lose) <bavier>I've been having some fun lately poking around with guile's assembler and linker <daviid>fiw, i never find working with guile was slow, it compiles my scheme apps files pretty fast. then, I extensively use geiser we developing, so C-x C-e over the procedure (or procedures) I'm working on, which is instantaneous... the develpoment cycle with static languages, rru over static languages (kawa, clojure) is a ton heavier and really boring actually... working on heavy projects using guile is a charm, for me <dsmith-work>cmaloney: I used to build gcc. Part of using buildroot for embedded. <dsmith-work>Of course you need to tune your makfiles so a simple make clean doesn't wipe it out. <dsmith-work>But out jenkins build machine would start from a clean checkout, and so build gcc. <dsmith-work>But even with all that, it only took about 45 minutes. <dsmith-work>YEah, building guile from git source is slow. Building from a release tarball is better. <dsmith-work>cmaloney: I greatly enjoyed your description of that small machine the other day! <dsmith-work>I've never been on anything *that* small. But I have worked with only 127 bytes of ram. And part of that was stack. <cmaloney>Yeah, I remember the Atari 2600 had a ridiculously small amount of memory <cmaloney>with some older programmer yelling that it was a luxury to have 2K