IRC channel logs
2016-05-30.log
back to list of logs
<cmhobbs>is there a static site/blog generator written in guile? i seem to recall one existing <lloda>daviid: just use array-length, works for any type <amz3>is there any procedure that allows to walk files in a fs hiearchy? <taylan>I don't need the whole OOP stuff, but I have a perfect use-case for subtyping record types <taylan>I'll have to put a 'user-data' field into my parent record type and let the subtypes fill that field with further data; it's the closest I can come to subtyping I think <taylan>hmm, another choice might be make-object-property <davexunit>wow, wingo will be giving a talk about Guile at Strange Loop! that's fantastic. <davexunit>they release really nice videos of the sessions. <civodul>hacking gdb hacks from Geiser is awesome <civodul>running a REPL server from gdb and all that <civodul>one of these things that make you want to debugging C++ code <lloda>I've never been able to debug C++ properly with gdb. I always hit one demangling bug or another :-/ <civodul>i even posted on this damn web site ;-) <taylan>I wonder how e.g. struct { uint8_t x[3]; } would be expressed with the FFI module, for passing to pointer->procedure (as return type or an argument type) <mark_weaver>taylan: should be the same as struct { uint8_t x0; uint8_t x1; uint8_t x2; } for purposes of layout <mark_weaver>oh, well, actually, better use a struct for this because, iirc, structs are often dealt with differently for purposes of C function arguments/returns. <taylan>I'm finally working on my bytestructure-descriptor -> ffi type conversion <taylan>(have lots of free time in the coming months. am unemployed for now.) <mark_weaver>taylan: also remember that integer and floating-point arguments are often (usually?) handled differently, e.g. passed in different machine registers, for purposes of C function arguments/returns. <mark_weaver>as for the more general question of how to convert any struct type, possibly including a mixture of nested structs/arrays of various types, to a suitable FFI type: better consult the relevant C standards on struct layout rules. <mark_weaver>I vaguely recall that in many cases, it is sufficient to treat the array as individual elements within the struct, but I'm not 100% sure that this rule works in all cases. <mark_weaver>and maybe it's cleaner to uniformly convert each array into its own struct, rather than unpacking its elements into the parent struct. <taylan>as I'm doing it now, e.g. struct { uint16_t x; uint8_t y[3]; struct { uint32_t z; } } will become (list uint16 (make-list 3 uint8) (list uint32)). does that look principally OK for pointer->procedure? I can smooth out details later (e.g. does libffi handle alignment/padding, or do I have to do it? if it pads automatically, is there still a way to express packed structs? etc.) <mark_weaver>your method looks reasonable to me, but it's been a while since I read that part of the C standard carefully <taylan>ah thanks, I was looking at 6.7.2 (Type specifiers) instead <taylan>mark_weaver: how can I translate knowledge of the C standard to knowledge of what lists to use in Guile's FFI though? e.g. what is (list uint8 uint16) in terms of the C standard, so to say? I'm guessing I also need to know a bit about libffi details? <mark_weaver>libffi doesn't support arrays, so you need to convert arrays into something else that's equivalent for purposes of layout <mark_weaver>use C99 to determine what is equivalent to arrays for purposes of layout <mark_weaver>my vague recollection is that arrays can be converted to structs without affecting layout. you could double-check that.. <taylan>I see. so I read the C standard to find out a suitable struct equivalent (in terms of layout) of an arbitrary type, and then encode that struct in the Scheme notation (nested lists) <taylan>that way I get a suitable Scheme representation of the original type <mark_weaver>one exception though: arrays that are *not* nested within a struct should be represented as pointers to bytevectors instead, for a few reasons. <mark_weaver>the most important reason is that structs and arrays are handled differently when passed as C function arguments/returns. <mark_weaver>usually, structs are copied onto the stack, whereas for arrays a pointer is passed. <mark_weaver>another reason is efficiency, in the case of large arrays <mark_weaver>it's a common case that should be handled more efficiently, if possible. <mark_weaver>I worry about what will happen when you try to convert a large array into a struct. <taylan>ouch, looks like my assumptions about struct member alignment/padding, where bitfields are allocated, and the meaning of the sign bit in a bit field, are all not specified by the C standard :( <taylan>I wonder if the behavior really diverges among the common platforms of our day though. if the assumptions hold for x86, ARM, and MIPS, it should be acceptable <taylan>for starters, I'd guess that all common platforms nowadays use the two-complements semantics for the sign bit, i.e. the bit adds the value -2^(n-1) for an n-bit signed integer <ft>At work, we use DSPs that use 16 bit bytes. <ft>The DSP does use two's complement as well, though. And I don't know an active architecture that doesn't. <mark_weaver>taylan: I think it's okay to assume twos complement. it's doubtful that guile is portable to non-twos-complement platforms anyway <mark_weaver>taylan: but I wonder, why do you need to know the representation? <ft>Structure alignment and bitfields are probably hard to get done portably. <taylan>mark_weaver: for bitfield access, I interpret the meaning of the sign bit in Scheme, using unsigned bitfields under the hood <mark_weaver>if someone complains some day, we can fix it, but I think twos complement is pretty well locked in by now <taylan>next question would be alignment. I wonder if there's any common platform nowadays where the basic C types (integers and floating-point numbers) aren't "self-aligned"? (i.e. the alignment of such a type equals its size) <mark_weaver>I would try to write the code such that any assumptions you make like this can be fixed later relatively easily <mark_weaver>maybe include a procedure that reports the alignment of a given type <mark_weaver>for now, it could simply return the size, but always use it so that it could be made more complex later if needed. <mark_weaver>at some point, we could perhaps make this alignment information available from guile in a portable way <mark_weaver>you could do something similar for the representation of negative bit fields <taylan>currently the descriptor objects have an alignment field that just holds an integer. I could make that a procedure returning an integer instead. although, all the numeric descriptors are initialized once when the library is loaded, so the correct alignment information could also be queried from the platform at that point already. <mark_weaver>if a descriptor object represents a C type, then I don't see an advantage to including a procedure that returns an integer instead of just including the integer. <taylan>right, it's not like we change architectures at runtime :) the alignment values of the numeric types can certainly be determined at module loading time, so that should be fine I guess.