IRC channel logs


back to list of logs

<catonano>amz3: o/
<manumanumanu>so... anyone familiar with the ffi here?
<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>and then accessing it as a 64bit unsigned int
<manumanumanu>which is ok on my 64bit system
<manumanumanu>I can of course do a ref depending on sizeof size_t, but that seems somewhat like a hack
<manumanumanu>Oh well, I'll just implement them myself
<ecraven>are you asking about chez or guile?
<manumanumanu>chez has a really nice interface for that imho.
<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
<manumanumanu>The problem is reading it back
<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
<ecraven>from looking at for 3 seconds, maybe (pointer->procedure 'size_t (dynamic-func ...) (list ...)) works?
<ecraven>why is the size_t in a bytevector?
<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
<manumanumanu>and get a 64bit unsigned integer out
<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
<manumanumanu>I did a foreign allocation (using C alloc)
<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.
<manumanumanu>All I have is a pointer to it
<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
<ecraven> says "See the code for (system foreign) for details."
<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>for that I have sizeof, so that isn't a huge problem
<manumanumanu>Anyway, I seem to have been on the correct path.
<manumanumanu>Maybe i'll write a macro that does all this with zero overhead.
<ecraven>usually size_t will be unsigned int
<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
<manumanumanu>anyway, I am going with the bytevector version
<ecraven>gcc before 2.4, so actually old ;)
<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.
<manumanumanu>does guile do cross-module inlining?
<manumanumanu>nope. not yet :) I'll work around it with a macro.
<dsmith-work>Happy Friday, Guilers!!
<wingo>good evening guilefolk
<cmaloney>Good evening
<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>on guile itself
<amz3>it's ok on top of guile
<wingo>ACTION nod
<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>and with packaging I don't notice it
<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>Along with the clib and everything else.
<cmaloney>Yeah, in that case it makes sense
<dsmith-work>But even with all that, it only took about 45 minutes.
<dsmith-work>To go from a checkout to an installation image.
<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>dsmith-work: Heh
<cmaloney>Yeah, I remember the Atari 2600 had a ridiculously small amount of memory
<cmaloney>on the order of a few hundred bytes
<cmaloney>128 bytes of run-time data
<dsmith-work>Had a windowed eprom
<dsmith-work>2K bytes of code space. Fun!
<cmaloney>with some older programmer yelling that it was a luxury to have 2K