Re: [Chicken-users] I've gots an egg: missing.egg
* Alexej Magura amagur...@gmail.com [150813 04:16]: Is hosting on the chicken-eggs svn repo discouraged against for new eggs? If it isn't then I'd like to use the svn repo as a means of managing the egg: I use the git repo as an auxiliary/backup/master/more public repo. You can still use svn if you want. Hosting on distributed VCS has been added to lower the bar for potential contributers. If you like you can get SVN access. See http://wiki.call-cc.org/chicken-svn-for-eggs and especially http://wiki.call-cc.org/eggs%20tutorial for more infos about laying eggs. Cheers, Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] iconv egg patch
On Wed, Aug 12, 2015 at 11:20:04PM -0300, Hugo Arregui wrote: I am afraid that the iconv egg is orphaned at the moment. Would you like to take care of it? Sure!. I cannot access the svn repo mentioned in the egg source, so I guess I should use the result of chicken-install -r as the base, isn't that? You can take the svn egg repo as a base (that's where it's currently hosted). We can give you access to it if you like, or you could import the egg into a git or mercurial repository and we can change the URL. Cheers, Peter signature.asc Description: Digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] I've gots an egg: missing.egg
On Wed, 12 Aug 2015, Alexej Magura wrote: Hey, I've got a new egg that I'm working on: https://github.com/amagura/eggs/tree/master/staging/missing/trunk Excellent! May I offer some tips? 1+ and 1- duplicate add1 and sub1, which are already in the library: http://api.call-cc.org/doc/library/add1 What is !* supposed to do? Using eval like that is most likely not a good idea. Should you be using apply instead? Something like (not (apply fn ...))? Rather than using a settings alist (note that mutation of things imported from modules is not a great idea!), it would be more idiomatic to use parameters: http://api.call-cc.org/doc/chicken/parameters Eg, export a paremter called egg-actions-need-sudo that's initialised to #f, and use the value of that in +install etc. That avoids mutation, and lets you safely override things locally (particularly in the presence of threads). This is a broad mixture of things to put into one egg, especially one claiming such a fine name as missing :-) It might be good to split the install/uninstall/upgrade stuff into an eggs egg, submit do* and setq for inclusion in miscmacros, and decide if you really need to publish the logic stuff, which seem less widely useful to me? Thanks have fun, ABS ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] I've gots an egg: missing.egg
Alaric Snell-Pym scripsit: Excellent! May I offer some tips? +1 to these, and also it's better if do* calls syntax-error rather than error. -- weirdo:When is R7RS coming out? Riastradh: As soon as the top is a beautiful golden brown and if you stick a toothpick in it, the toothpick comes out dry. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] I've gots an egg: missing.egg
Hi, Thanks for your interest in contributing, Alexej. Please, see some comments below. On Thu, 13 Aug 2015 13:26:03 +0100 (BST) Alaric Snell-Pym ala...@snell-pym.org.uk wrote: On Wed, 12 Aug 2015, Alexej Magura wrote: Hey, I've got a new egg that I'm working on: https://github.com/amagura/eggs/tree/master/staging/missing/trunk Excellent! May I offer some tips? 1+ and 1- duplicate add1 and sub1, which are already in the library: http://api.call-cc.org/doc/library/add1 What is !* supposed to do? Using eval like that is most likely not a good idea. Should you be using apply instead? Something like (not (apply fn ...))? Rather than using a settings alist (note that mutation of things imported from modules is not a great idea!), it would be more idiomatic to use parameters: http://api.call-cc.org/doc/chicken/parameters Eg, export a paremter called egg-actions-need-sudo that's initialised to #f, and use the value of that in +install etc. That avoids mutation, and lets you safely override things locally (particularly in the presence of threads). This is a broad mixture of things to put into one egg, especially one claiming such a fine name as missing :-) It might be good to split the install/uninstall/upgrade stuff into an eggs egg, submit do* and setq for inclusion in miscmacros, and decide if you really need to publish the logic stuff, which seem less widely useful to me? Also, with regard to the egg-related things, be careful when calling CHICKEN tools. What would happen when you: * run +install missing? * run +install from /not/in/PATH/csi ? You'd have similar issues with the other REPL commands. With regard to hosting your egg in the CHICKEN svn, I don't see a point, since you already have your code on github. Best wishes. Mario -- http://parenteses.org/mario ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Incorrectly linked binaries with chicken-install -deploy
Does anyone have stand-alone application deployments working via chicken-install? I'm running into an issue where the binaries for my executables are in place, but they are linked to the system libchicken. I'm not sure if this is a bug or I'm using it wrong. I'm seeing this with Chicken 4.10.0, running on Ubuntu 14.04. I compiled 4.10.0 from the tarball on the website and have it installed globally. I have an egg setup file that looks like the following (thanks to Mario Goulart for helping me put this together): (define info '((version 0.1))) (define progs '(prog1 prog2 prog3)) (for-each (lambda (prog) (compile -O3 -d1 ,(make-pathname #f prog scm))) progs) (install-program 'prog progs info) - I run the following command to build: chicken-install -deploy -p my-app-directory All of my dependencies look to be correctly compiled and put into the specified directory, but there is no libchicken in that directory. The 3 programs above also appear to be linked to the global libchicken $ ldd my-app-directory/bin/prog1 linux-vdso.so.1 = (0x7fff591fc000) libchicken.so.7 = /usr/local/lib/libchicken.so.7 (0x7f69474eb000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f6947125000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f6946e1e000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f6946c1a000) /lib64/ld-linux-x86-64.so.2 (0x7f6947acf000) Am I going about this correctly? Running 'csc -deploy prog1.scm' results in a correctly linked libchicken binary, but it doesn't look like chicken-install -deploy uses that. My goal is a tarball that a user can unzip and run directly without installing chicken or any other dependencies. Talking with sjamaan on #chicken, sounds like another option is to not create an egg from the project and script individual calls to 'csc -deploy ...' and chicken-install for the dependencies. For reference. the project I'm having difficulty building can be found on github here https://github.com/senior/pdb-cli. Thanks for the help! Ryan ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] iconv egg patch
You can take the svn egg repo as a base (that's where it's currently hosted). We can give you access to it if you like, or you could import the egg into a git or mercurial repository and we can change the URL. Thanks Peter! I imported the code into a github repository, I will let you guys know when is ready for the URL change. One question though, I found a couple of things I would like to improve: - I think the documentation is a bit misleading when it says (about iconv procedure), The resulting string is returned (or #f if the implementation runs out of memory). But it can actually return #f on error too (check here if you like: https://github.com/hugoArregui/iconv/blob/master/iconv.scm#L85). - The iconv procedure has an `invalid` parameter, which defaults to ?. When an invalid sequence is found, the `invalid` string is appended to the output string for each wrong byte found. Maybe this is desirable sometimes, but there is no way to actually raise an error on this case. So, I will just add an alternative, and if invalid is #f, an error will raise. However, I think raising an error on invalid input is a much saner default, but this breaks backward compatibility I would really like Alex Shinn's opinion on this one, because he has two eggs using iconv. Hope he's reading this. But anyway, my question is: both of this items are related to backwards compatibility, what do you think is the best choice here? should I just change it (if Alex Shinns and perhaps something else who is using it agrees with these changes), should I create another procedure and deprecate this one?, should we call it iconv2 and deprecate iconv?. Thanks. Regards, Hugo signature.asc Description: OpenPGP digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
