***sneek_ is now known as sneek
<RhodiumToad>(define slot (ensure-generic 'slot (and (defined? 'slot) slot))) *RhodiumToad now has a working example of using libarchive via ffi <RhodiumToad>deriving a subclass from a class made with make-foreign-object-type seems to stop the finalizer working? <lilyp>RhodiumToad: Probably because finalizers are per subclass and you don't provide one. ***chris is now known as Guest5500
***Guest5500 is now known as chrislck
<Zelphir>I have looked more at the tar stuff. It seems to me, that there are 3 implementations: The one used in Gash, which is written in GNU Guile inside ustar.scm, GNU tar and libarchive. What would be the pros and cons of using one or the other? (Initially I read "ustar" as "u-star" ~ U* and was wondering what that might be. Shows how little I know, ha! But then I found out, that it is apparently the implementation that most tools use?) <Zelphir>Where "using one or the other" in case of C libraries means writing FFI code. <RhodiumToad>I have a working though still incomplete example of using libarchive <RhodiumToad>that lists the contents of any archive and calculates the sha256 of each file in it <Zelphir>Why do you choose libarchive over GNU tar or the ustar implementation in Gash? <RhodiumToad>how would you use GNU tar for this? by invoking it as an external program? <RhodiumToad>as for the other, libarchive is much cleaner and more flexible <Zelphir>^^ me neither, all new territory for me. <Zelphir>When I do `man tar` I get shown that I have GNU tar. <Zelphir>So I guess when I run any tar command, I am using GNU tar. <lampilelo>there's nothing in /usr/include from gnu tar on my system <RhodiumToad>the freebsd port for gnu tar only lists executables, not libraries <Zelphir>Does it mean, that GNU tar does not put its functions into a separatable library, and that is, why it cannot be a target for FFI? <RhodiumToad>as a bonus, it reads dozens of formats with autodetection, so you don't need to care whether the input is .tar, .tgz, .tzst, .zip, .iso or whatever else <lampilelo>what version of guile do they have in their repos? <RhodiumToad>I have a port for 3.0.x but I didn't get any feedback on how to resolve the conflict over guile.m4, so it's just languishing <RhodiumToad>I compile 3.0.x within the ports/packages system by having my own local port for it <RhodiumToad>(there are a couple of patches needed for freebsd, for where the build is assuming gnu date and gnu sed) <lampilelo>i wonder sometimes about switching to bsd, but i think i like rolling package releases too much <RhodiumToad>(the logic in gen-scmconfig.c doesn't understand that off_t might be defined as a 64-bit type on a 32-bit platform, without ugly "largefile" definitions) <RhodiumToad>(BSD since, I believe, 4.4 has not had any of the "largefile" crap, off_t is a 64-bit type everywhere - the joys of not having to worry about breaking ancient binary compatibility) <Zelphir>How complete is that implementation you linked to (https://dpaste.org/egv3)? How does it compare to the Gash ustar implementation? Could one use one of the two and except to be able to do most things, that people usually do with tar? (For me that would be: (1) creating a tar and adding an arbitrary number of files to it, (2) zipping it (perhaps not part of the implementation and done by another tool), (3) extracting the files (preferably selectively) <lampilelo>Zelphir: seems like there's no option in their autoconf file to compile gnu tar as a library <Zelphir>I would not have known where to look for the answer to that. <RhodiumToad>Zelphir: it's incomplete in that it doesn't include yet many of the functions to get file information (file size, uid, gid, numeric mode, ACLs, etc.) <RhodiumToad>Zelphir: it'll let you read the pathnames and data, though <RhodiumToad>Zelphir: and obviously it's only implementing the read support <RhodiumToad>Zelphir: I have not looked at the gash ustar implementation <lampilelo>RhodiumToad: so just a straightforward change of types? shouldn't it be added to the upstream? <Zelphir>What library would you recommend as particularly easy to write FFI code for and then use from GNU Guile? Perhaps I should start with a super primitive C program, which I write myself and which simply has some operations like + - * / ? <Zelphir>Also I have a more general question: Is there only FFI for C libraries? I mean, some other languages compile to C, but what about FFI for languages, which are not C or compile to C? Would that require completely different tools to be implemented? <Zelphir>Lets say for example I want to use a Python or Rust library from inside GNU Guile. <RhodiumToad>rust iirc is callable from c? so the ffi might work with that (I have no idea, I don't use rust) <RhodiumToad>in theory you could use the ffi to load a python interpreter into the process and use it to run python code <Zelphir>Ah, and we have Python-on-Guile, which might fit this bill? <lampilelo>can python-on-guile load complex python libraries? <Zelphir>Let me check my e-mails and so on for that info. <RhodiumToad>bleh. annoying. guile has internal code to parse out a struct stat, but it doesn't expose it. <Zelphir>Could not find the answer to the question in my e-mails. <RhodiumToad>so if you get a struct stat from an ffi call, you have to parse it yourself, which means having to get the field list from system headers, which means having to have an install step <Zelphir>What is a struct stat? Statistics about a struct?