IRC channel logs


back to list of logs

<jao>dsmith-work, nice! i've become more of a classical music aficionado lately, but jazz pianists still make me very happy :)
<nalaginrut>I will say it again, guile-2.1 is rather faster beyond my expectation, I'll try to show it by something...
<sneek>nalaginrut, you have 1 message.
<sneek>nalaginrut, ArneBab_ says: A cool usecase for Artanis would be something like marmalade for Guile: in marmalade it’s just uploading a single elisp file whose comments are used to extract metadata. No additional walls between writing simple code and sharing it. for bigger libraries marmalade supports *.tgz, but I think it’s the simple files which make a big difference: That makes it possible to start sharing with the smallest possible
<nalaginrut>ArneBab: this?
<nalaginrut>ArneBab: how about yet another package manager plus a site?
<ArneBab>nalaginrut: an Artanis-based webservice for guildhall. It could provide a package-repository.
<ArneBab>nalaginrut: besides: moin ☺
<nalaginrut>ArneBab: yes, I considered such thing for a year
<nalaginrut>but there're several problems we have to think about
<nalaginrut>the first thing is licenses, my proposal is that the site accepts various GPL compatible licenses packages
<nalaginrut>not only GPL, but I don't know how many guys agree me with that
<nalaginrut>my aim is to provide practical things to help guiles contributes their packages
<ArneBab>I would agree
<ArneBab>In the end, it’s a repository of packages to be used by users of Guile, not packages to be integrated.
<nalaginrut>the second issue is a choice, users upload tarballs or upload meta ticket, just like pkg-list.scm
<ArneBab>and as long as the licenses are GPL-compatible (or at least AGPL compatible), developers can always use them all.
<nalaginrut>yeah, I believe licenses friendly is better
<ArneBab>nalaginrut: I think that uploading only tarballs would hinder adoption. Marmalade accepts either elisp files with markup in the initial comments or tarballs. As far as I see, the plain elisp files are the most common choice.
<ArneBab>The site would likely have to package the plain scheme files into tarballs, though, to be compatible with guildhall.
<nalaginrut>IMO, it's fine to upload one scm file compatible with guildhall, but it's better to provide good version control, users may choose history version release
<nalaginrut>it's easy when all the packages are maintained with git
<nalaginrut>hmm...or maybe authors have to find a place to keep all history version, it's no big deal for GNU packages
<nalaginrut>anyway, I have to research similar things. I found npm is a good thing to research, I've tried luarocks recently, it's not so good for me, at least unstable to use.
<ArneBab>I found marmalade to have the best interface of the package repository interfaces I know to date
<ArneBab>there’s the big “add a new package” button, and it does versioning by not allowing re-uploading of packages with the same version number.
***michel_mno_afk is now known as michel_mno
<ArneBab>it could benefit from better error messages and such, but the basic setup is really good.
<nalaginrut>ok, I have to design pkg meta and format first, then APIs, the last is web UI
<nalaginrut>if possible, I would like to [de]compress packages with Scheme code
<nalaginrut>but it's fine if I have to use FFI or pipe
<ArneBab>nalaginrut: do you mean the the pkg metadata for comments?
<ArneBab>nalaginrut: for tarballs there is already a format (
<nalaginrut>yes I know it
<nalaginrut>well, it uses weinholt's zip implementation
<ArneBab>maybe you could reuse the parsing routines from marmalade for accepting pure scheme packages
<nalaginrut>ArneBab: oh, don't make me read elisp code...
<nalaginrut>is it written with elisp?
<ArneBab>I think so, yes
<ArneBab>marmalade uses elnode
<ArneBab>(runs in emacs)
<ArneBab>maybe you could even simply read that with the elisp support in guile
<sneek>wingo, you have 1 message.
<sneek>wingo, dsmith-work says: I'm with you on libltdl
<Chaos`Eternal>hi all
*paron_remote stares into the void of automake
*paron_remote feels the void stare back into him
*ArneBab likes automake - since he realized that make distcheck actually provides unique capabilities and that the GNU coding style provides a portable API to be used by humans (README, NEWS, COPYING, ./configure; make)
<dsmith-work>Thursday Greetings, Guilers
***michel_mno is now known as michel_mno_afk
<paron_remote>so, very weirdly
<paron_remote>"make check" runs different things if in a normal "real" terminal vs emacs M-x shell O_o
<mark_weaver>paron_remote: what is one of the differences?
<paron_remote>mark_weaver: it passes in one and fails in the other :)
<paron_remote>but I can output
<mark_weaver>what's a specific example?
<mark_weaver>which test?
<paron_remote>"make check" in
<mark_weaver>oh, this is not guile, but your own project
<paron_remote>"a guile project I'm trying to learn how to run tests for" but not my own
<paron_remote>but my own
<mark_weaver>maybe your environment variables are set differently in the two cases
<mark_weaver>I would start by looking at this differences
<paron_remote>but they're both from fresh bash processes...
<paron_remote>I guess I don't know how they could be different
<mark_weaver>processes inherit their parent's environment
<mark_weaver>'export' prints the environment variables. you could dump them to a file from each of those shells, and then use 'diff' to find the differences.
<paron_remote>hm, you're right
<paron_remote>$GUILE_LOAD_PATH is the culprit, as probably expected
<paron_remote>thanks mark_weaver
<paron_remote>davexunit: if around, might you mind explaining how the srt2vtt tests know about the tests/ directory?
<davexunit>paron_remote: it's all automake magic:
*davexunit goes afk
<paron_remote>hm, I can't get the magic to happen on my own thing I guess :(
<paron_remote>woo tests run at last.
<dsmith-work>paron_remote: yey
<paron_remote>hi dsmith-work
<dsmith-work>wingo: Speaking of tests. I saw an old email from civodul about the --coverage option to ./check-guile (actually, test-suite/guile-test). Master doesn't like it.
<mark_weaver>wingo: I'm okay with not using libltdl, and I'm also okay with taking in libgc and essentially forking it