4 ms·

GNU Guile v2.9.2 – an embeddable REPL for scripting your GUI

40 points by bleair 7y ago

Riverheart 7y ago
Anybody know what the high level overview of embedding guile into an application looks like?
- armitron 7y ago
  My team tried doing it once and we decided against it after running into problems with the number of Guile dependencies. We moved to Lua (0 dependencies) soon after. Guile may have more features but Lua (and Luajit) is really the undisputed king when it comes to embedding and flexibility in terms of merging it into your codebase and molding it to your exact requirements.
  - avar 7y ago
    What was the cumulative size of those dependencies when statically linked? I've never understood why some shy away from "number of dependencies" per-se for C projects, worst case you ship some of them with you, but perhaps the real problem was "prohibitively large object" once it was all compiled together.
    - Crinus 7y ago
      Each dependency increases the cognitive load for maintenance (something goes wrong/is slow/doesn't compile in that platform or requires steps incompatible with the rest of the project/other issue, is it me or the 20839423 libraries i depend on? How does that library that has the issue work? How do i fix it? These are things C programmers tend to care about) as well as reliance on 3rd parties to stay in line with your needs (e.g. you may want to stick with C89 but a library you depend on - or a library a library you depend on depends on - decided to raise minimum requirements to C99 "because everyone has that now" or one of your dependencies stops development for whatever reason - in either case you are left with the choice of dropping the dependency - and anything that depends on it - or taking over maintenance for something you decided to use in the first place to avoid that sort of work).
      - avar 7y ago
        Very little of what you mention would apply to the GP since they're not in the position of maintaining guile, they're a 3rd party user who'd be packaging it and its dependencies up for use in their own application. Guile's list of mandatory dependencies is short, and consists of libraries like libgmp (also used by GCC), libiconv etc., I doubt a packager would have much issue with the stability of those. These are libraries that work on dozens of platforms across a wide range of compiler versions: http://git.savannah.gnu.org/cgit/guile.git/tree/README#n20 http://git.savannah.gnu.org/cgit/guile.git/tree/README#n20 More generally the trade-off with libraries cuts both ways, and I've seen other programmers underestimate the maintenance burden of rolling their own v.s. the investment in just including a well-tested third-party library. E.g. it's very common for C programs to have their own buggy and often insecure version of something like a string library, DNS resolver etc. That's not free for you as a user of those programs either. E.g. the other day I was dealing dealing with an issue in how bitlbee resolves SRV records with its own home-grown code instead of using something like GResolver, which wouldn't have had that issue.
        Crinus 7y ago
        My comment was about the <<I've never understood why some shy away from "number of dependencies" per-se for C projects>> part, not Guile itself although it also applies to what you wrote, specifically this: > they're not in the position of maintaining guile, they're a 3rd party user who'd be packaging it and its dependencies up for use in their own application. ...as it doesn't matter if they are using these other dependencies directly or indirectly, they are still dependencies of their application - if anything these are dependencies they didn't have any say over (they had say over depending on their direct dependency - like Guile - but not on their dependency's own dependencies which were decided by the programmers of that dependency) so they have less knowledge on how those are used and why they are used (knowledge they may need to gain in the case where something goes bad as i wrote above). Basically the more dependencies you have (not necessarily the number of libraries you depend on but also how much of each library you are using), the more people you invite to have a say in how your project will work and as such the more likely to encounter friction and misaligned goals. This is why a lot of C programmers prefer to use small single-purpose libraries (to the point where "single header libraries" have taken off significantly) and avoid huge "multitool" frameworks. > its own home-grown code instead of using something like GResolver, which wouldn't have had that issue. Perhaps, but it may have had other issues you (or even the programmer who wrote that code) didn't know about.
  - paines 7y ago
    I took this dependency list from Arch for guile 2.2: gc, gmp, libffi,libltdl (libtool),libunistring,ncurses,texinfo Maybe the number has increased meanwhile. Lua just has readline as dependency. Not sure about guiles must have, but I guess this list could be narrowwed down by diabling features.
- flukus 7y ago
  Haven't tried it myself but it looks pretty straight forward: https://www.gnu.org/software/guile/docs/guile-tut/tutorial.html https://www.gnu.org/software/guile/docs/guile-tut/tutorial.h... I'm coming round to the suckless philosophy personally though.
  - Riverheart 7y ago
    Thanks for the link! If I may ask, does the Suckless philosophy view language embedding adding unneeded complexity?
    - flukus 7y ago
      Suckless philosophy is basically to change the source code and recompile so there is no need for embedding a language, which seems crazy but makes a fair bit of sense when you think through it. When you embed a language the only audience for that is programmers and most programmers are at least somewhat familiar with C. Relatively simple things you'd find in a config file stay relatively simple, just editing config values in a header file like this, if you wanted to change the colors of your terminal for instance, I'm sure you can work what to change here: (https://git.suckless.org/st/file/config.def.h.html https://git.suckless.org/st/file/config.def.h.html). It's also infinitely extensible, users can do anything and not just what is allowed by the API and it's blazingly fast.

40 points by bleair 7y ago

Riverheart 7y ago

Anybody know what the high level overview of embedding guile into an application looks like?

armitron 7y ago
My team tried doing it once and we decided against it after running into problems with the number of Guile dependencies. We moved to Lua (0 dependencies) soon after. Guile may have more features but Lua (and Luajit) is really the undisputed king when it comes to embedding and flexibility in terms of merging it into your codebase and molding it to your exact requirements.
- avar 7y ago
  What was the cumulative size of those dependencies when statically linked? I've never understood why some shy away from "number of dependencies" per-se for C projects, worst case you ship some of them with you, but perhaps the real problem was "prohibitively large object" once it was all compiled together.
  - Crinus 7y ago
    Each dependency increases the cognitive load for maintenance (something goes wrong/is slow/doesn't compile in that platform or requires steps incompatible with the rest of the project/other issue, is it me or the 20839423 libraries i depend on? How does that library that has the issue work? How do i fix it? These are things C programmers tend to care about) as well as reliance on 3rd parties to stay in line with your needs (e.g. you may want to stick with C89 but a library you depend on - or a library a library you depend on depends on - decided to raise minimum requirements to C99 "because everyone has that now" or one of your dependencies stops development for whatever reason - in either case you are left with the choice of dropping the dependency - and anything that depends on it - or taking over maintenance for something you decided to use in the first place to avoid that sort of work).
    - avar 7y ago
      Very little of what you mention would apply to the GP since they're not in the position of maintaining guile, they're a 3rd party user who'd be packaging it and its dependencies up for use in their own application. Guile's list of mandatory dependencies is short, and consists of libraries like libgmp (also used by GCC), libiconv etc., I doubt a packager would have much issue with the stability of those. These are libraries that work on dozens of platforms across a wide range of compiler versions: http://git.savannah.gnu.org/cgit/guile.git/tree/README#n20 http://git.savannah.gnu.org/cgit/guile.git/tree/README#n20 More generally the trade-off with libraries cuts both ways, and I've seen other programmers underestimate the maintenance burden of rolling their own v.s. the investment in just including a well-tested third-party library. E.g. it's very common for C programs to have their own buggy and often insecure version of something like a string library, DNS resolver etc. That's not free for you as a user of those programs either. E.g. the other day I was dealing dealing with an issue in how bitlbee resolves SRV records with its own home-grown code instead of using something like GResolver, which wouldn't have had that issue.
      - Crinus 7y ago
        My comment was about the <<I've never understood why some shy away from "number of dependencies" per-se for C projects>> part, not Guile itself although it also applies to what you wrote, specifically this: > they're not in the position of maintaining guile, they're a 3rd party user who'd be packaging it and its dependencies up for use in their own application. ...as it doesn't matter if they are using these other dependencies directly or indirectly, they are still dependencies of their application - if anything these are dependencies they didn't have any say over (they had say over depending on their direct dependency - like Guile - but not on their dependency's own dependencies which were decided by the programmers of that dependency) so they have less knowledge on how those are used and why they are used (knowledge they may need to gain in the case where something goes bad as i wrote above). Basically the more dependencies you have (not necessarily the number of libraries you depend on but also how much of each library you are using), the more people you invite to have a say in how your project will work and as such the more likely to encounter friction and misaligned goals. This is why a lot of C programmers prefer to use small single-purpose libraries (to the point where "single header libraries" have taken off significantly) and avoid huge "multitool" frameworks. > its own home-grown code instead of using something like GResolver, which wouldn't have had that issue. Perhaps, but it may have had other issues you (or even the programmer who wrote that code) didn't know about.
- paines 7y ago
  I took this dependency list from Arch for guile 2.2: gc, gmp, libffi,libltdl (libtool),libunistring,ncurses,texinfo Maybe the number has increased meanwhile. Lua just has readline as dependency. Not sure about guiles must have, but I guess this list could be narrowwed down by diabling features.
flukus 7y ago
Haven't tried it myself but it looks pretty straight forward: https://www.gnu.org/software/guile/docs/guile-tut/tutorial.html https://www.gnu.org/software/guile/docs/guile-tut/tutorial.h... I'm coming round to the suckless philosophy personally though.
- Riverheart 7y ago
  Thanks for the link! If I may ask, does the Suckless philosophy view language embedding adding unneeded complexity?
  - flukus 7y ago
    Suckless philosophy is basically to change the source code and recompile so there is no need for embedding a language, which seems crazy but makes a fair bit of sense when you think through it. When you embed a language the only audience for that is programmers and most programmers are at least somewhat familiar with C. Relatively simple things you'd find in a config file stay relatively simple, just editing config values in a header file like this, if you wanted to change the colors of your terminal for instance, I'm sure you can work what to change here: (https://git.suckless.org/st/file/config.def.h.html https://git.suckless.org/st/file/config.def.h.html). It's also infinitely extensible, users can do anything and not just what is allowed by the API and it's blazingly fast.