IRC channel logs
2016-08-13.log
back to list of logs
<stis>Note that to make kanren allow a functional forall, we needs delimeted continuations, somthing lacking in kanrens defined in other languages. <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>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 (https://bundler.io), 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>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 <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 <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>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 <random-nick>guile itself uses the "$PROJECT_ROOT/modules" approach, but guile has docs and C source too <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 <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. <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. <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 implementation...it 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. <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 :) <janneke>dhamidi: interested to work with me on my Emacs GUD patches for Guile? <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 <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>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>maybe it just isn't doing argument processing, but that's just a guess at this point <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 <ijp>I wasn't really expecting a full project <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>I just read a tutorial where the author extended gnuplot, and he did it like this <ijp>I don't think that has been updated in like 6 years <mark_weaver>pmikkelsen: sorry for the confusion. we are in need of a more up-to-date tutorial. <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. <pmikkelsen>It helped me, but yes, a "getting started" guide would be very great! <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>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. <pmikkelsen>mark_weaver: oh, i didn't know that. Does that mean I can get all the SDL goodies without any c? <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 <janneke>is there a shorthand for (bytevector-u32-native-set! bv 0 #x00112233) ==> #vu8(51 34 17 0) <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