IRC channel logs


back to list of logs

<stis>I think I got a proper kanren forall coded. See
<stis>Note that to make kanren allow a functional forall, we needs delimeted continuations, somthing lacking in kanrens defined in other languages.
<amz3`>héllo :)
<djcb>good morning
<dhamidi>I've been toying around a bit with guile lately
<dhamidi>and was wondering about the package management story in guile
<dhamidi>there is guildhall, but it seems to have few packages
<dhamidi>right now I'm looking into guix
<dhamidi>how do you guys manage your guile code? Is there something like a "standard project structure"?
<galex-713>dhamidi: no, but most people around there (and GNU project more generally) tends to use emacs + autotools
<dhamidi>using emacs myself, however autotools solves a different problem (building code) -- I was basically looking for something like Ruby's bundler (, but for guile instead
<mark_weaver>dhamidi: I would recommend GNU Guix as a model citizen for guile projects :)
<random-nick>a popular approach for project structure is to have a modules folder in which you have either files or folders representing the modules
<galex-713>dhamidi: guildhall is to be abandoned in favour of guix, also guix has the ability of importing packages from guildhall and even other package managers such as bundler, pip, etc.
<random-nick>for example for the module (ice-9 match) it would be modules/ice-9/match.scm
<mark_weaver>I'm not sure that we've made a decision about whether to completely abandon guildhall, but it's certainly true that we consider Guix a much preferred solution.
<mark_weaver>and as a result, we've not worked on guildhall lately
<mark_weaver>the proliferation of language-specific package managers is a big problem, though.
<mark_weaver>so it's quote possible that we'll drop guildhall, in order to not contribute to that problem. but I don't think that decision has been made yet.
<dhamidi>all right, then I'll familiarize myself with guix
<galex-713>ihmo we should just share all the packages of all the languages of all the distros, sources or bytecode or compiled or not, in P2P, indexed by a secure DHT
<galex-713>And then we identify packages by a hash of a predicate (in any language) determining through various pubkey who is allowed to change the project and how (including how and who is allowed to change the predicate)
<random-nick>there are some security issues with sharing packages over something like the bittorrent protocol
<galex-713>I mean, except it’s hard to anonymize, I don’t see the problem
<mark_weaver>guix plans to make greater use of gnunet in the future, e.g. for distribution of binary substitutes.
<galex-713>oh, maybe the fact several really approaching versions of the same package would have different seed so it would fragment and lower a lot the efficience of the whole process but let’s hack it
<galex-713>mark_weaver: I know it, I also know it has temporarly delayed because of “issues” (dunno what kind of issues)
<galex-713>random-nick: so what security issue?
<galex-713>I mean except surveillance it could work perfectly
<galex-713>The only problem being versionning is not integrated into bittorrent
<random-nick>for example if you want to download a version of a new package and that version fixes a remote execution vulnerability, people would have the IP of a machine that probably has that vulnerability
<galex-713>ah I see
<galex-713>Then surveillance/anonymization yeah
<random-nick>since the bittorrent protocol requires you to have IPs of peers so you can seed
<galex-713>Then why not using that over something like I2P?
<galex-713>random-nick: we can hack bittorrent so it uses i2p or cjdns
<random-nick>well bittorent protocol still leaks your IP but I don't know if a fixed protocol over something like i2p or tor is secure
<mark_weaver>this is a hard problem, and I trust the gnunet folks to get it right more than I'd trust some hack job :)
<galex-713>mark_weaver: afaik bittorrent works over i2p and doesn’t leak your IP (especially when you don’t have one x)
<galex-713>random-nick: yet tor isn’t intended to make P2P work, tor is opposed to that and don’t want bittorrent on their network, that’s why it doesn’t work well on their network
<galex-713>mark_weaver: is guix some kind of research or experiment or it is intended to serious usage?
<mark_weaver>it's considered beta at this stage, but serious usage. it's already under very heavy use. all my laptops have been running it for years.
<mark_weaver>there's a lot of interest in guix. it's had over 5600 commits by almost 100 contributors in the last year, and those numbers keep going up.
<mark_weaver>the development mailing list has so much traffic it's too much to read
<mark_weaver> for some stats
<galex-713>mark_weaver: because afaik gnunet is not “serious usage” right now, it’s kinda an experiment or a research project, intended to do stuff, some wrong some right, then perish and lead to better stuff
<dhamidi>so, I've had a look at a few guile packages from guix and found two approaches to structuring projects: $PROJECT_ROOT/modules (used by guile-ssh, guile-reader) as mentioned by random-nick and the other was to have $PROJECT_ROOT/$MODULE_NAME, e.g. $PROJECT_ROOTS/redis for guile-redis (used by guile-redis, guile-commonmark). That makes two options: would it make sense to settle on one? Are there tools for setting up
<dhamidi> a new project with (a/the) "standard" project layout?
<galex-713>the first one seems less redundant to me
<galex-713>Because the project name, thus the project root will be often the same or at least have some part in common with the module name
<dhamidi>well, the first one ends up as $PROJECT_ROOT/modules/$MODULE_NAME
<galex-713>So you would have guile-redis/redis or guile-commonmark/commonmark
<galex-713>ah :/
<galex-713>dunno then
<random-nick>guile itself uses the "$PROJECT_ROOT/modules" approach, but guile has docs and C source too
<random-nick>so it makes sense to not have scheme code in src/
<dhamidi>random-nick: that's a good point
<mark_weaver>galex-713: bittorrent would not work well for Guix, because there are literally thousands of binary substitutes, most of them small.
<mark_weaver>bittorrent doesn't work efficiently for small files, there's too much per-torrent-download overhead.
<dhamidi>another question: are autotools really necessary for a pure guile project?
<amz31>dhamidi: depends of the project, but I don't use autotools
<janneke>dhamidi: i'm working on a silly package that tries to be gnu-build-system compatible without using autotools:
<amz31>dhamidi: the anwser is yes
<mark_weaver>I'd recommend it, mainly because it's the easiest way to provide the standard interface for the GNU build system (i.e. ./configure && make && make install, with the standard set of options for ./configure), and makes life a lot easier for distributions than having to figure out yet-another-half-baked build system.
<galex-713>mark_weaver: ah interesting
<janneke>but i'm not sure that's a sensible way to do it
<mark_weaver>janneke: oh, interesting! well, as long as it conforms to the GNU build system interface, another well-done implementation of that would be welcome.
<mark_weaver>especially for pure guile programs.
<dhamidi>janneke: looking at your project right now to figure out what's going on :)
<janneke>mark_weaver: i'm struggling with autotools; i *really* like the automatic conforming to gnu standards -- that's a must; but the would be nice if we could depend on GNU make+guile after building those ... something like that
<mark_weaver>the important thing, from my perspective as someone who works on a distro (GNU Guix), is to conform to the gnu build system.
<dhamidi>conforming to the existing standard is indeed important
<mark_weaver>sure, I'd love to have something simpler and cleaner than autotools, for cases where all that complexity is not needed.
<dhamidi>the problem I have with autotools is that it's hard to find beginner-friendly documentation for it
<dhamidi>if using/learning autotools was easier and some of the setup when starting a new library/module was automated, the barrier to writing a new guile package would be lower and thus help the guile ecosystem grow
<dhamidi>and having a thriving ecosystem would help with using Guile in places where Ruby/Go/NodeJS are used right now
<dhamidi>basically I've played around with guile after reading the chapter on streams in Structure and Interpretation of Computer Programs and started really liking the development environment and language
<dhamidi>the experience of developing with guile + geiser in Emacs is the best I've seen so far for the "writing code" part of development
<mark_weaver>dhamidi: you might also look at guile-opengl, written by Andy Wingo. that's a pure guile project, with no C at all, and I'm guessing that wingo did a good job with the build system.
<dhamidi>thanks, I'll check that out
<mark_weaver>whereas Guix is more complex from the fact that it's daemon is written in C++ (inherited from Nix)
<mark_weaver>(Guix plans to rewrite the daemon in Guile at some point, and thus become a pure-guile project, but we're not there yet)
<dhamidi>in all other areas of development, Go's tooling comes out first (distribution, deployment, documentation)
<dhamidi>so I want to be able to use Guile "in production" when developing software as team in a commercial environment (i.e. involving money and deadlines)
<dhamidi>and that means filling the tooling gaps :)
<mark_weaver>sounds great :)
<janneke>dhamidi: interested to work with me on my Emacs GUD patches for Guile?
<mark_weaver>ACTION --> zzz
<dhamidi>janneke: principally yes, however right now my first priority is to create something that makes starting a new guile library one command
<random-nick>why is it required to have a mutex in order to use condition variables?
<mark_weaver>random-nick: because otherwise there would be a race condition
<mark_weaver>there's no way to make it work otherwise
<mark_weaver>anyway, I need to sleep now. happy hacking!
<dhamidi>good night, mark!
<amz31>is it safe to work on guile master?
<galex-713>wingo: is the guile-opengl doc going to be completed one day or is it abandoned to some future contributor that’d know what to put in it?
<pmikkelsen>Hello guile users
<pmikkelsen>I am having a problem that i dont understand
<pmikkelsen>I wrote a program in c that starts a guile shell, with some functions defined
<pmikkelsen>and in the shell, those functions works fine, but not when running -s file.scm
<ijp>example pls
<pmikkelsen>do you want the code?
<ijp>maybe it just isn't doing argument processing, but that's just a guess at this point
<stis> A functional finadall in minikanren, enjoy!!
<pmikkelsen>I will put it on gitlab in a few minutes, but the stange thing is, that i can run "functions" with no arguments, but the ones that have arguments are undefined when i use -s file.scm
<pmikkelsen>okay, so the code is at
<ijp>I wasn't really expecting a full project
<pmikkelsen>it's not so big tho
<ijp>shouldn't scm_shell be called from inside guile mode?
<pmikkelsen>As i understand it, scm_with_guile enables guile mode in the current shell
<mark_weaver>pmikkelsen: quoting the entry for 'scm_with_guile' in the manual: "When ‘scm_with_guile’ returns, the thread is no longer in guile mode [...]"
<ijp>no, only for the duration of the call
<ijp>this is a common pattern for functions with "with" in the name
<pmikkelsen>oh, i must have misunderstood some things then
<pmikkelsen>I just read a tutorial where the author extended gnuplot, and he did it like this
<mark_weaver>pmikkelsen: what's the URL?
<pmikkelsen>I am talking about section 3.1
<mark_weaver>gah, you're right :-(
<ijp>I don't think that has been updated in like 6 years
<mark_weaver>well, it needs an update now, clearly
<pmikkelsen>ooh, thats explains it ;)
<mark_weaver>and this is obviously not on some random web site
<pmikkelsen>No, that is why i got even more confused :p
<mark_weaver>pmikkelsen: sorry for the confusion. we are in need of a more up-to-date tutorial.
<pmikkelsen>mark_weaver: No problem :)
<mark_weaver>fwiw, when starting a new project, I would strongly consider making 'guile' the main program, and instead implementing any C bits you need in small shared libraries loaded by guile.
<mark_weaver>see section 6.20.3 (C Extensions) in the guile manual for an example of how to do that.
<mark_weaver>maybe it's not appropriate in your case, but it's something to consider anyway :)
<pmikkelsen>mark_weaver: oh, okay thanks! Will look into that :)
<pmikkelsen>I am quite new to guile and scheme, so i dont really know the best way to do stuff yet :)
<mark_weaver>we are in need of better tutorials and "getting started" material, but on the plus side this IRC channel tries to be helpful.
<mark_weaver>thanks to our (relatively) new dynamic FFI, it is often possible to avoid writing any C code altogether, which greatly simplifies distribution. for example, the guile-opengl project adds opengl support to guile without any C code at all.
<mark_weaver>much of the older tutorial-style documentation for guile has not been updated to take into account the new goodies added since 2.0 was released.
<mark_weaver>things have improved a great deal.
<pmikkelsen>It helped me, but yes, a "getting started" guide would be very great!
<pmikkelsen>oh, i see
<ijp>Incidentally, I've been messing around with my own game stuff recently, but it's rpg in python, rather than platformer in guile
<mark_weaver>out of curiosity, what is giraffe aiming to do? maybe I can help suggest the best way forward.
<pmikkelsen>ijp: cool!
<ijp>code coming 2056
<mark_weaver>ah, a game platform, nice@
<pmikkelsen>mark_weaver: the plan was to provide a program that loads a scheme file and some game data, and the scheme file is acting as a configuration file (sort of)
<mark_weaver>pmikkelsen: davexunit has worked on that too. he just recently posted bindings for SDL2 for guile.
<mark_weaver>and he has a project called "sly" with similar goals.
<mark_weaver>sneek: sly?
<sneek>From what I understand, sly is
<pmikkelsen>mark_weaver: oh, i didn't know that. Does that mean I can get all the SDL goodies without any c?
<mark_weaver>pmikkelsen: most likely, yes.
<mark_weaver>although you might need some C code to accelerate some of the math, dunno.
<pmikkelsen>mark_weaver: Yes maybe, but i guess that will be relatively easy to do with the extensions, right?
<mark_weaver>but if needed, that can be done with a small shared library, as described in section 6.20.3 (C Extensions)
<mark_weaver>yeah, I would definitely recommend making the main program, and most of the code in guile.
<pmikkelsen>mark_weaver: okay, I think i will make a new project then, this one was only a few days old anyways
<mark_weaver>davexunit, who hangs out here on channel, will be a good person to ask about his experiences
<amz31>pmikkelsen: there is #sly too
<pmikkelsen>amz31: okay :)
<pmikkelsen>I gotta go, bye
<mark_weaver>pmikkelsen: okay, thanks for stopping by!
<pmikkelsen>PS, very great IRC channel!
<mark_weaver>sneek: guile-sdl2 is
<sneek>I'll keep that in mind.
<amz31>sneek: culturia?
<amz31>sneek: sicp?
<sneek>sicp is Structure and Interpretation of Computer Programs,
<amz31>sneek: wiredtiger?
<OrangeShark>Morning everyone
<amz31>morning OrangeShark
<janneke>is there a shorthand for (bytevector-u32-native-set! bv 0 #x00112233) ==> #vu8(51 34 17 0)
<ijp>janneke: not really
<ijp>I keep a hex-string->bytevector around somewhere
<janneke>ijp: ok, thanks; then i'll make some int->bv32 ->bv16, or something
<amz31>nice, i used to do something with (format #f "~X" foo)
<random-nick>what's the difference between string= and string=? ? number of arguments?
<stis>string= s1 s2 [start1 [end1 [start2 [end2]]]]
<stis>string=? [s1 [s2 . rest]]
<stis>looks like the = version can compare substrings and the =? can compare multiple strings
<stis>(string=? "a" "a" "a") -> #t
<stis> (string= "a" "ab" 0 1 0 1) -> #t
<amz31>Is Julian Graham here?