<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: how about yet another package manager plus a site? <ArneBab>nalaginrut: an Artanis-based webservice for guildhall. It could provide a package-repository. <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>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. <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 <ArneBab>nalaginrut: do you mean the the pkg metadata for comments? <ArneBab>maybe you could reuse the parsing routines from marmalade for accepting pure scheme packages <ArneBab>maybe you could even simply read that with the elisp support in guile <sneek>wingo, dsmith-work says: I'm with you on libltdl *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) ***michel_mno is now known as michel_mno_afk
<paron_remote>"make check" runs different things if in a normal "real" terminal vs emacs M-x shell O_o <paron_remote>"a guile project I'm trying to learn how to run tests for" but not my own <mark_weaver>maybe your environment variables are set differently in the two cases <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>davexunit: if around, might you mind explaining how the srt2vtt tests know about the tests/ directory? <paron_remote>hm, I can't get the magic to happen on my own thing I guess :( <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