IRC channel logs

<dsmith>Just got my new "Programming Rust" today! And who do I see quoted on Page 1? Andy Wingo!

<dsmith>(also one of the authors, Jim Blandy, was an early Guile developer)

*RhodiumToad prefers his software to be corrosion-free

<dsmith>I think it's supposed to be something like ice-9. It covers everything.

<flatwhatson>someone mentioned "typed guile" earlier, is that "theme-D" or something else?

<flatwhatson>it would be amazing to have something like this: https://lisp-journey.gitlab.io/blog/compile-time-type-checking-in-common-lisp/

<drakonis>oh i have yes.

<drakonis>i meant it as a vehicle to enable guile to evolve some interesting new tricks

<apteryx>trying a relocatable guix pack of guile on armhf-linux: error: 'clone' failed: Invalid argument\nguile: run.c:123: rm_rf: Unexpected error: Device or resource busy.\nAborted

<apteryx>hmm. seems it's a proot problem. it works when not using the relocatable bits.

<apteryx>not sure, it works on another system. Perhaps the kernel config (buildroot-based) is too bare-bone.

<tohoyn>sneek: botsnack

<sneek>:)

<tohoyn>flatwatson: see http://tohoyn.fi/theme-d/index.html for Theme-D. It's a "typed Scheme".

<sarna>hey, suppose I wanted to share my program with someone, and I'd like them to be able to run it with as little friction as possible. they shouldn't have to have guile installed, and ideally they wouldn't need to know the software is in guile

<sarna>how would I go about making such a package?

<sarna>I think guile doesn't support static linking or anything like that

<ft>Guile doesn't do native compilation, so the program is required for running code, even if it is byte compiled.

<sarna>can I package it somehow? `guix pack` comes to mind, but I don't know if it's not too heavy-handed

<ft>Classic distributions can solve that, by having your package depend on Guile. And then there are approaches such as guix pack, flatpak and the like.

<tohoyn>Should guile be able to do native compilation? I think it could be useful.

<sarna>I like dynamic languages, but they're such a pain when I need to send my stuff to somebody else :(

<ft>I think wingo has plans in that direction, but it sounds like quite the undertaking. :)

<wingo>plans, yeah, but time is constrained atm :)

<ft>Speak of the devil. :)

<sarna>I'll try with `guix pack` and we'll see how it goes, thanks!

<lampilelo>you can make a simple main.c file that loads scheme code, and compile it, statically linking against libguile, you'd have to install the binary with all the guile modules it uses, preferably precompiled, and set the load paths correctly

<lampilelo>i've never done it but theoretically it should work

<lampilelo>and remember: if you distribute binaries linked against guile you need to include the license and some way to get the source code of your program

<lampilelo>sarna: ^

<lampilelo>i'd probably stick to "guix pack" though

<sarna>lampilelo: oh no I forgot it's GPL! then it's gonna be a pain, hahaha

<sarna>thanks for the tips

<lampilelo>yeah, it's LGPL but statically linking or distributing it with your program will mean you'll need to use a compatible license

<lampilelo>s/but/so/

<sarna>can't do that at work, sadly

<rlb>sarna: if you really needed to, you could also likely install guile to a --prefix, and then distribute that along with your code, and your program (#! script or compiled C) would just set the appropriate PATH, GUILE_LOAD_PATH, and LD_LIBRARY_PATH. But of course it'd be somewhat platform specific unless you statically linked guile (do we support that easily?).

<rlb>i.e. guile itself would be dynamically linked to the built-system's libs, and so would require compatible versions wherever you ran it.

<rlb>Oh, I think that's similar to what lampilelo was suggesting. And might have been clear, but as lampilelo also suggested, the source distribution requirements vary depending on whether static or dynamic linking is used.

<lampilelo>yes, but if you distribute guile along with your software LGPL applies to that too, doesn't matter if you link it dynamically

<leoprikler>does it though?

<lampilelo> https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic

<leoprikler>doesn't the LGPL make a clear difference between changing guile itself (must be LGPL) and building stuff on top (can be anything)

<leoprikler>this doesn't say anything about licensing tho

<rlb>Interesting, I wasn't familiar with (1) there.

<rlb>i.e. that a foo.o might be adequate wrt the license terms.

<leoprikler>I think this refers to the point 4d of the LGPL (v3)

<leoprikler>Hmm, this does state that the Minimal Corresponding Source must be conveyed under LGPL terms though

<leoprikler>which means the things that you need to link things together plus the original library, I guess

<lampilelo>so it means not all of your code needs to be under LGPL, but only the part that's needed to link

<dsmith-work>Hmm. Is it still possible to statically link guile with all dep libs?

<lampilelo>then i was wrong, also this faq states that if you distribute lgpl'ed software with your own, you need to provide the source for lgpl'ed stuff only

<lampilelo>hm

<sarna>so can I link it into one binary and include "built using guile which uses LGPL, grab the source at $WEBSITE" and it'll be okay?

<sarna>the source for guile of course

<sarna>oh, I'd need to include links to all libraries I use that are GPL.. hrm.

<apteryx>does Guile fall-back to no JIT on platforms it isn't supported? Or must it be built with --enable-jit=no on those?

<leoprikler>sarna if you link to GPL libs, you need to distribute your entire program under the GPL anyway

<leoprikler>if it's just LGPL, listing them and making sure you can link against modified versions is enough

<dsmith-work>apteryx: Yeah, at configure time, JIT_AVAILABLE defaults to "no" unless arm/x86.

<apteryx>dsmith-work: thanks!

<apteryx>any real life example using Swig to generate C/C++ Guile bindings?

<dsmith-work>swig? is that still maintained for Guile?

<lampilelo>i don't know if it's still maintained but works with guile 3 no problem

<sarna>thanks leoprikler! I have no experience dealing with that stuff so it helps a lot

<lampilelo>although it created functions for enum values instead of variables

<dsmith-work>Wrapping C stuff directly (SMOBS) is not all that hard.

<dsmith-work>But the current trend is to use Guile's FFI for that stuff.

<lampilelo>for big interfaces it's a pain

<lampilelo>there's also nyacc, it generates ffi in scheme instead of making a c module

<dsmith-work>There have been a few others too.

<dsmith-work>nyacc parses header files? Needed for #define's

<lampilelo>i think so

<lampilelo>i know it broke for me when tried to parse the header file that included math.h, i don't think it's documented yet but there's a certain thing you need to put in your nyacc instructions for it to work with cstd files

<lampilelo>so i guess it recurses

<leoprikler>nyacc is in a weird spot where it does both too much and too little at the same time

<drakonis>rewrite it in guile?

<leoprikler>nyacc is already written in Guile tho?

<leoprikler>Or do you mean the C thingy

<drakonis>the guile thingy

<drakonis>C thingy

<leoprikler>that's not always an option

<leoprikler>think of moderately large stuff like SDL or even bigger stuff like GTK

<leoprikler>(GTK really is an outlier here as there's at least two implementations of GObject Introspection in Guile, but still)

<dsmith-work>There is also g-wrap

<dsmith-work>Mainly for guile-gnome

<leoprikler>okay but g-wrap tried to be a more general c wrapper like nyacc, no?

<dsmith-work>Yeah, I think it tried to be general.

<dsmith-work>Looks like hasn't been touched in a while.

<daviid>not sure who asked what wrt g-wrap, but I'd recommend not to use it anymore, because it was designed at a time wedidin'thave dynamic ffi ... it produces/generates C (libguile) code ... and afaict,is unmaintained

<daviid>one should use nyacc, if the objective is to bind a C library that is not GObject Introspectable, then do some 'manual' tuning where necessary, but nyacc does an amazing job, at least to get you started (I'd say much more then 'get you started' ... but ...)

<daviid>but nor g-wrap neither nyacc will help if the lib is in C++

<leoprikler>True, C++ is a different beast.

<leoprikler>I think Schmutz helps you with that, but it's kinda like manually doing libguile stuff in C.

<leoprikler>but if you C++ thingy has C bindings, you could nyacc those

<daviid>my 'distant' experience wrt C++ lib, like vigra (used by guile-cv) is that someone first write a C wrapper, vigra_c in this particular case, that merely wrap the C++ function in a C function that calls the C++ func, deals with the exception and return a code (sortof)

<daviid>openCV 2.x did that to,then they abandonned (too much work i guess) the C API in 3.x ...

<daviid>fwiw, here https://github.com/BSeppke/vigra_c

<daviid>the author of vigra_c did that to be able to bind vigrafor racket, called it vigracket :), and that was my luck because i wouldn't want to do that wrapper myself, but if/when we conewith some magic, i'd use openCV in guile-cv ...

<leoprikler>yeah, if you don't like writing wrapper C, you'll be left with schmutz

IRC channel logs

2021-07-13.log