<goglosh>does guile have support for low level system calls? <goglosh>not as in (system "pwd") but as in int 0x80 ***karswell` is now known as karswell
<mark_weaver>goglosh: you can use the dynamic FFI to call 'syscall' <mark_weaver>in the 'guix' source code, see guix/build/syscalls.scm for examples <mark_weaver>at least one of them calls 'syscall', because in that case there's no libc wrapper for it <paroneayea>ACTION sends a perhaps overly-passionate reply to guile-devel! <paroneayea>amz3: also, I hope you don't take my passionate endorsement as a detraction of your own comments <paroneayea>consider it commentary for, not commentary against :) <mark_weaver>paroneayea: fwiw, I really appreciate your post, and your passion :) <zacts>^ SICP is being adapted for lisp flavored erlang <zacts>I wonder how LFE compares with scheme <davexunit>people keep making these Lisps on other people's VMs that somehow seem to gain big followings whilst Scheme, which has been around for decades, gets shorted. <paroneayea>davexunit: true to some extent, though I think it's sometimes a useful entry point <paroneayea>davexunit: hacking on Hy was a useful milestone on the road to me becoming a Guile hacker. <zacts>I still think I would prefer scheme for most things <paroneayea>but I would certainly love to see more proper scheme adoption, yes :) <paroneayea>John Carmack using Racket seems to be gaining some attention. <zacts>indeed, I would personally prefer more scheme adoption over Yet Another Lispy on X-VM implementation language <zacts>racket has done some interesting things with typed racket <zacts>is there an equivalent for guile to typed racket? <zacts>(and if not, I wonder how difficult it would be to make a typed guile) <paroneayea>guile is the place for me, but sometimes I get jealous of racket's stuff :) <zacts>I also like some of the eggs in chicken scheme <paroneayea>zacts: wingo expressed that he thought it was possible at least <paroneayea>I think he said it could be done as a library maybe rather than as a different language, though I may remember wrong <daviid>we have to x fingers that wingo succeed in finalizing our AOT compiler, that will be a big win imo <zacts>oh did ijp ever do that GSoC idea for a guile->javascript compiler? <paroneayea>zacts: there is partial code pushed up... but I don't know what happened mid-project <paroneayea>I don't know which one is more up to date / recommended <paroneayea>he did get it to the point where it could run some code <paroneayea>I hope he didn't get stressed out to the point where he doesn't want to talk about it or something <zacts>that happened to the rubycasts guy <zacts>he had to take a break from it <zacts>I hope the best for ijp, and his projects though <daviid>paroneayea: wrt guile-squee, which I'm working on a bit now. A tiny detail, but while I'm at it... I prefer to remove the .txt extension for COPYING, README and friends, do you have any objection against removing the ext? <daviid>paroneayea: please confirm it is LGPG 3+ as well <ArneBab_>davexunit: other systems already provide all the libraries people want to use, and they already work on their platforms. <daviid>davexunit: what is your prefered email address to put in AUTHOR? [I see you have serveral addresses] <daviid>wonderful, thanks. I have the manual mock up already ready [the most annoying thing so i started from there, and just completed it <calher>Scheme implementations need to go away implement things using bare Scheme. If it's hard, too bad. It's turing complete, it's possible. So, do it. <calher>It's better than having a jillion incompatible Schemes. <paroneayea>calher: that's an option of people implementing libraries, and some do. I don't agree it should be mandatory. <paroneayea>calher: you are welcome to think so, but of course, this is #guile, not #scheme, and people are welcome to embrace guile-dom here. <daviid>paroneayea: on noteabug, you say Because "squeal" is a silly way to pronounce squeal, but the last you wanted to wite SQL right? <daviid>so it comes to this: "Guile-Squee! Why "squee"? Because "squeal" is a silly way to pronounce <daviid>SQL, and "squee" is an always-happy squeal! (Thanks for the great name, <zacts>SQL I pronunciate as 's', 'q', 'l' <taylanub>hmm, libffi seems to support direct struct arguments to functions and not just pointers. I wonder why Guile doesn't just provide a Scheme version of the exact libffi API and builds higher level FFI APIs based on that, in Scheme... <mark_weaver>civodul: any idea what's happening with build 689440 on hydra? it's been running for almost 24 hours, and the build log is completely empty. I've seen this many times, and in each case just killed the relevant process on hydra to free up the build slot, but this time I left it so you could take a look. <sam3>im trying to compile a program im writing with libguile <sam3>using: gcc -o nbody main.c -g -Wall -lSDL2 -lSDL2_gfx `pkg-config --cflags guile-2.0` <sam3>but i get undefined reference errors to 'scm_with_guile' and 'scm_shell' <sam3>which I assume is because I'm compiling it wrong <sam3>hi, I've seen that but I'd like to learn to interface the langauges and learn some more C, which is why I was doing it this way. Thanks though <mark_weaver>sam3: because you are linking in that command (not just compiling), you need to add --libs to the 'pkg-config' command line <mark_weaver>--cflags gives you the flags needed for compiling to a .o file <mark_weaver>--libs gives you the flags needed to link .o files to a program <mark_weaver>since you're doing both in one step, you need both --cflags and --libs <sam3>thanks, I've added that. It still doesn't compile because it can't find a function I have in another file (which I should be able to fix myself) <mark_weaver>sam3: you could just add that other source file after "main.c" <mark_weaver>although normally, with programs that have more than one source file, it's better to compile each one to a .o file and then link in a separate step <daviid>taylanub: wtr "... libffi seems to support direct struct arguments to functions ..." mayb a email to the ML would be usefu? [I was curious and monitoring for an answer as well] <mark_weaver>taylanub: we support direct struct arguments to functions as well, although it's not documented. structure types are represented as a list of the field types. <mark_weaver>but the point is, anywhere that you can pass a single foreign type (e.g. '* or int), you can pass a list of types, and that's interpreted as the type of a struct with those field types. <mark_weaver>so, for example, when calling 'pointer->procedure', you may pass a list as the 'return_type' to indicate that the return value is a struct, and you may pass a nested list as the 'arg_types', if one or more of the arguments are structures. <daviid>unless reasons while not documented, it would be really nice if we'd have a very good, short but concise and complete example in our manual, I think <taylanub>mark_weaver: what kind of argument will be expected, or value returned, for such types? again a list perhaps, of the field values? <mark_weaver>in such cases, a pointer to the struct is expected/returned <mark_weaver>(although from the C point of view, it's the actual struct, not a pointer) <taylanub>should I not be able to use a struct with 4 uint8 fields in place of an int and thus get a pointer to that int, or does Guile's FFI/libffi really do something with the precise type information? (I'm trying to cheat to avoid full transformation between my "bytestructure descriptor" objects and FFI types) <taylanub>getting segfaults at the moment, when I use e.g. (list uint32) in place of int for a return type and (list (list uint64) (list uint64)) in place of (list '* '*) for the arguments <taylanub>seems to work for the return value, but not for the argument types... <please_help>taylanub: you can use (list uint64 uint64) instead of (list '* '*) but you'll have to do (pointer-address ...) or (address->pointer ...) (I think that's what they're called) depending on what you're storing. <please_help>also uint64 is not guaranteed to be the right type based on arch. I don't think guile has a intptr_t, though. <taylanub>please_help: (list uint64 uint64) works, but not (list (list uint64) (list uint64)) which is what I need <please_help>I've never seen such a form ever used, why do you need that and what do you expect it to do? <taylanub>I'm trying to make it accept a pointer to the value that should be passed to the function <taylanub>long story short I'm trying to cheat to avoid full transformation between my "bytestructure descriptor" objects and FFI types <taylanub>I'd like it to just accept pointers to the arguments the function will be called on. I can communicate it the sizes of the arguments by using (make-list n ffi:uint8) where n is the size, but it shouldn't really assume that it's a struct with n uint8 fields... <taylanub>I assumed it wouldn't touch the contents anyway, but I guess it does in some way <taylanub>an object backed by a bytevector, but having type information bundled to it so values can be read out from it sanely <taylanub>ah, just noticed I don't wrap time in a pointer, though that's not the source of the problem at hand <please_help>so what you need to do is: if an arg type is a bytestructure-pointer (such as via (bs:pointer whatever)), then apply to the corresponding value in the function call (bytevector->pointer (bytestructure-bytevector the-actual-input)). <please_help>(yes, time being a bs instead of a pointer seems to be the issue) <please_help>can you use gettimeofday with the ffi directly without a segfault? <taylanub>when I use (list (list uint64) (list uint64)) in place of (list '* '*), it segfaults. I need to use the former (rather, lists with n many uint8s) because otherwise I would need to implement a full conversion between my bytestructure descriptors and these listy types (which isn't plausible anyway because the descriptors are a lot richer in semantics) <taylanub>please_help: yes, when I use (list '* '*) as is actually intended. when I cheat and use (list uint64) in place of a '*, it segfaults. it works with the ruturn value by the way (I get a pointer to the int); only segfaults when I use this cheat for an argument type <please_help>I still don't see what you mean by that, sorry. From what I can tell you want (list '* '*) for gettimeofday and (gettimeofday (bytevector->pointer (bytestructure-bytevector time)) %null-pointer) for gettimeofday "kinda" <taylanub>(I get a pointer to a one-field struct that holds an int, to be precise, but in C's typical memory layout there's no difference between that because structs don't contain any "wrapping") <please_help>that's not accurate, there may be alignment differences under a whole slew of scenarios, but anyway. <taylanub>can a struct { int x; } ever have different alignment from int x; ? <please_help>for (list uint64 uint64), do you use (pointer-address [the-pointer]) or just [the-pointer]? <taylanub>I don't use (list uint64 uint64), I use (list (list uint64) (list uint64)) <please_help>(also 0 instead of (ffi:make-pointer 0) or %null-pointer) <taylanub>you might want to read the backlog from before your first line, in case you didn't <mark_weaver>taylanub: I haven't read the entire backlog, but I'm not sure why you'd think that (list (list uint64) (list uint64)) would be interchangeable with (list '* '*) <mark_weaver>the former is for an argument list like foo(struct bar a, struct bar b) where struct bar { uint64_t x; } <please_help>structs and struct* are not at all interchangeable in C <taylanub>please_help: I want to give it a pointer to a bytevector where values of the real pointer reside <please_help>the latter is for foo(struct bar* a, struct bar* b) where struct bar {uint64_t x;} which is the case of gettimeofday <mark_weaver>if the C code wants a _pointer_ to a structs, then the foreign type needs to be '*, not (list ...) <taylanub>no, I just want to "cheat" libffi so I can pass a pointer for *anything* <mark_weaver>taylanub: can you just show me the C prototype for the function you want to call? <please_help>you want to pass a (void*)X such that the C code sees it as a *(real_type*)X? <mark_weaver>taylanub: if you want to pass a pointer, then the foreign type must be '* <mark_weaver>and guile provides many ways to make pointer objects <taylanub>sorry, it seems I'm still failing to explain what I'm actually trying to do <please_help>it would be a lot easier with the C code and corresponding guile code <taylanub>in this example the signature is just int gettimeofday(timeval*, timezone*). the thing is, I want to avoid creating true FFI types, in this case (list '* '*), and instead just make the FFI take a pointer to *any* type of value that should be passed to the function. <taylanub>so in this case I'd like to pass it a pointer object whose address points to the actual pointers that should be passed to the function <mark_weaver>taylanub: in that case, the 'arg_types' list passed to 'pointer->procedure' really needs to be (list '* '*) <please_help>taylanub: I still have no idea what you want, but do you want (gettimeofday time 0) to resolve to (gettimeofday (ffi-pointer-of time) (ffi-pointer-of 0))? <taylanub>so that I don't need to do a full conversion between my bytestructure descriptor types (which are more expressive than FFI types), and FFI types <please_help>it's all void*, the C code knows what type to expect; you know what type you need to send... <mark_weaver>libffi needs to know the types of the arguments, because that affects how they are passed to the function. <taylanub>I hoped it wouldn't need to know any more than the size <mark_weaver>however, it doesn't need to know what type of object pointers point to. just the fact that it's a pointer is enough. <mark_weaver>for example, most modern ABIs pass integers and floating point values in different kinds of registers <please_help>I don't think it needs more than the size, but the size is encoded in the types for convenience, right? <mark_weaver>uint64_t and double are the same size, but they are typically passed in different registers <please_help>for instance you can pass along a uint64 and the C code sees this as the address to the pointer to the object it cares about <mark_weaver>but modern popular ABIs typically use registers for the first few arguments, and they choose registers that will be convenient to use immediately by the caller/callee functions with minimal conversions <mark_weaver>modern architectures typically store integers in different registers than floating point numbers, for example <mark_weaver>so, floating-point arguments are typically passed in floating-point registers, and integer arguments are passed in integer registers <taylanub>if there's a couple groups of types that are interchangeable, then maybe I could still cheat to some degree to avoid a full conversion from bytestructure descriptors to FFI types... <please_help>it avoids at least 2 moves assuming the floats are actually going to be used? <mark_weaver>the 68k architecture also had different registers for "addresses" vs "data", so maybe it passed pointers in different registers than integers, dunno. <taylanub>hm, could I interchange e.g. (list uint16) with (list uint8 uint8), for one argument? <mark_weaver>sorry, but portability demands that we know the true types of the arguments and return value. <please_help>I had a struct I needed to pass to some C code which expected arguments to be aligned to the nearest multiple of 64 (at least on my arch), so I know that alignment might also change like that. <mark_weaver>the only information you can omit is this: all pointers can be treated the same <please_help>speaking of FFI, any idea how lazy-ffi works in chicken? It's pretty cool how it requires (almost) no hints to communicate to C and works from the repl just fine. <mark_weaver>although it's important for the alignment of the pointers to be sufficient <mark_weaver>please_help: I'm not familiar with it, but since Chicken requires a C compiler anyway, it could presumably use the C compiler to get all the information. <mark_weaver>Chicken generates C code, so it can do things like generate C function calls, and the C compiler does the rest. <please_help>but that works at the repl, which as far as I can tell doesn't use llvm/doesn't generate C code on the fly? (or maybe I'm wrong about that?) <please_help>it says: This facility uses libffi and dynamic loading (via dlopen(3)) to load shared libraries and construct foreign calls at runtime and in interpreted code. <mark_weaver>I don't know what additional tricks they do to avoid requiring fewer hints <mark_weaver>what information do we require that chicken's lazy-ffi does not require? <please_help>I'm asking on #chicken to make sure, I hope they don't actually rely on code generation directly for it. <mark_weaver>I can think of a couple of ways to get the type information without being told: parse the header files (which might not be present), or read the debugging information (which might not be present). <mark_weaver>I don't see how it can possibly be done without one of those two things.