[Chicken-users] Wish list
Hello, I have talked to a user, and he reminded me of my past experience of using Chicken in production environment around four years ago. While many things improved since then, there're still some I'd like to have. 1. Distribute eggs by HTTP(S) and/or FTP(S). Today I have "chicken-install -r", but it still is a specialized client. I don't quite understand what I can do if I'm in mildly hostile network where automatically configured proxy requires authentication mechanism chicken-install doesn't support. 2. Distribute eggs as source tarballs. In addition to (1) it would be nice if eggs were distributed as tarballs rather than individual files. In addition, such tarballs could be accompanied by cryptographic hash sums (individually per egg or as big list for the whole repository). These tarballs could even be signed, even. 3. Label eggs with their versions. It is unfortunate, that chicken-install still doesn't report egg version in any way. Did I overlook it? It would be nice, if eggs would follow common standard (eggname-x.y.z.tar.gz containing subdirectory eggname-x.y.z). 1-3 in conjunction would help paranoid people who want to track versioning information for various reasons (security, stability in field). (It would also help packagers and thus the community in whole due to better visibility. I hope we do agree that there're people who prefer using controlled installation rather than dumping random files into $PREFIX.) 4. Support installation of eggs into directory other than $(chicken-install -repository). It would be nice to be able to install eggs into private area (for testing purposes, for migration purposes, just as developer convenience, whatever). -- HE CE3OH... ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] wish-list
I added a "wish-list" to the wiki to hold stuff that would be nice to have. This is of course not meant as a replacement for the bug-tracker, but it may be worthwhile to have a place where to put more ambitious ideas. http://wiki.call-cc.org/wish-list cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Wish list
Hi Aleksej, On Sun, 10 Feb 2013 22:36:41 +0400 Aleksej Saushev wrote: > I have talked to a user, and he reminded me of my past experience of > using Chicken in production environment around four years ago. While > many things improved since then, there're still some I'd like to have. > > 1. Distribute eggs by HTTP(S) and/or FTP(S). > > Today I have "chicken-install -r", but it still is a specialized client. > I don't quite understand what I can do if I'm in mildly hostile network > where automatically configured proxy requires authentication mechanism > chicken-install doesn't support. Most (if not all) eggs are available via HTTP(S). For eggs hosted on call-cc.org, you ca use https://code.call-cc.org/svn/chicken-eggs/release/4/ The other hosts (github, bitbucket, gitorious etc) also provide HTTP(S) access (including tarballs). > 2. Distribute eggs as source tarballs. > > In addition to (1) it would be nice if eggs were distributed as tarballs > rather than individual files. In addition, such tarballs could be > accompanied by cryptographic hash sums (individually per egg or as big > list for the whole repository). These tarballs could even be signed, even. Yeah, that can be a handy feature for packagers. Maybe that feature can be implemented via some henrietta-cache hook or something? > 3. Label eggs with their versions. > > It is unfortunate, that chicken-install still doesn't report egg version > in any way. Did I overlook it? It would be nice, if eggs would follow > common standard (eggname-x.y.z.tar.gz containing subdirectory eggname-x.y.z). You can install specific egg versions by specifying them like this: :. Example $ chicken-install sendfile:1.7.23 chicken-status (installed by the chicken-core) lists eggs and versions. > 1-3 in conjunction would help paranoid people who want to track > versioning information for various reasons (security, stability in field). > (It would also help packagers and thus the community in whole due to > better visibility. I hope we do agree that there're people who prefer > using controlled installation rather than dumping random files into $PREFIX.) I see. > 4. Support installation of eggs into directory other than > $(chicken-install -repository). > > It would be nice to be able to install eggs into private area > (for testing purposes, for migration purposes, just as developer > convenience, whatever). As far as I understand what you mean, that's already supported. See http://wiki.call-cc.org/man/4/Extensions#changing-repository-location Best wishes. Mario -- http://parenteses.org/mario ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Wish list
Hello, Mario Domenech Goulart writes: > On Sun, 10 Feb 2013 22:36:41 +0400 Aleksej Saushev wrote: > >> I have talked to a user, and he reminded me of my past experience of >> using Chicken in production environment around four years ago. While >> many things improved since then, there're still some I'd like to have. >> >> 1. Distribute eggs by HTTP(S) and/or FTP(S). >> >> Today I have "chicken-install -r", but it still is a specialized client. >> I don't quite understand what I can do if I'm in mildly hostile network >> where automatically configured proxy requires authentication mechanism >> chicken-install doesn't support. > > Most (if not all) eggs are available via HTTP(S). For eggs hosted on > call-cc.org, you ca use > https://code.call-cc.org/svn/chicken-eggs/release/4/ I have just tried it. It has asked user name and password. It seems not to allow anonymous access. This is not what I wish, I think. > The other hosts (github, bitbucket, gitorious etc) also provide HTTP(S) > access (including tarballs). > > >> 2. Distribute eggs as source tarballs. >> >> In addition to (1) it would be nice if eggs were distributed as tarballs >> rather than individual files. In addition, such tarballs could be >> accompanied by cryptographic hash sums (individually per egg or as big >> list for the whole repository). These tarballs could even be signed, even. > > Yeah, that can be a handy feature for packagers. > > Maybe that feature can be implemented via some henrietta-cache hook or > something? By the way, what I wish is more than tarball automatically generated at each request. I want it stable, so that I could record cryptographic sums and be sure that the archive doesn't change tomorrow without version change. This is different from what github does (I don't know about bitbucket and the rest). >> 3. Label eggs with their versions. >> >> It is unfortunate, that chicken-install still doesn't report egg version >> in any way. Did I overlook it? It would be nice, if eggs would follow >> common standard (eggname-x.y.z.tar.gz containing subdirectory eggname-x.y.z). > > You can install specific egg versions by specifying them like this: > :. Example > >$ chicken-install sendfile:1.7.23 > > chicken-status (installed by the chicken-core) lists eggs and versions. I have missed it then. I think, reworking it in a way that is more usable would be benefitial. Basically, chicken-install, -status, -uninstall implement custom package manager already. Why not consider merging them into single tool that manages repository? >> 1-3 in conjunction would help paranoid people who want to track >> versioning information for various reasons (security, stability in field). >> (It would also help packagers and thus the community in whole due to >> better visibility. I hope we do agree that there're people who prefer >> using controlled installation rather than dumping random files into $PREFIX.) > > I see. > > >> 4. Support installation of eggs into directory other than >> $(chicken-install -repository). >> >> It would be nice to be able to install eggs into private area >> (for testing purposes, for migration purposes, just as developer >> convenience, whatever). > > As far as I understand what you mean, that's already supported. See > http://wiki.call-cc.org/man/4/Extensions#changing-repository-location I see the following problems with the state as of today. 1. Creating directory is unnecessary step. "chicken-install -init" could do it itself. Why require user make unnecessary steps? Note that even developers are users, they still want tools be convenient. 2. Setting environment variable shouldn't be necessary. It is nice if you provide it, but it would be better if it wasn't required. And example should be described in terms like "you can set environment variable in order to set default value overridden by another -p flag." If the environment variable is needed in child processes, then chicken-install can pass it. 3. If anything goes wrong, it should be reported to user. I have tried "chicken-install -init" and "chicken-install -p". I ended with this: ---8<--- mkdir: /tmp/eggs: Not a directory Error: shell command failed with nonzero exit status 256: mkdir -p /tmp/eggs/lib/chicken/6 Error: shell command terminated with nonzero exit code 17920 "/usr/pkg/bin/csi -bnq -setup-mode -e \"(require-library setup-api)\" -e \"(impo... ---8<--- I think that this is caused by "-init" not creating directory. I agree, that I haven't read documentation hard enough, but this could be avoided by adding few lines of code. By the way, when I do create the directory, I end with the following: ---8<--- /usr/pkg/bin/csc -feature compiling-extension -setup-mode-s -O2 -d2 foreigners.scm -j renaming -j foreigners Warning: extension `matchable' is cu
Re: [Chicken-users] Wish list
Hi-- On Sun, Feb 10, 2013 at 12:55 PM, Mario Domenech Goulart < mario.goul...@gmail.com> wrote: > > > On Sun, 10 Feb 2013 22:36:41 +0400 Aleksej Saushev wrote: > > Most (if not all) eggs are available via HTTP(S). For eggs hosted on > call-cc.org, you ca use > https://code.call-cc.org/svn/chicken-eggs/release/4/ > > The other hosts (github, bitbucket, gitorious etc) also provide HTTP(S) > access (including tarballs). Is there a straightforward way for a user to *choose* HTTPS when installing an egg? I thought the -transport option might do that, but according to the manual, that is not the case. > > 3. Label eggs with their versions. > > > > It is unfortunate, that chicken-install still doesn't report egg version > > in any way. Did I overlook it? It would be nice, if eggs would follow > > common standard (eggname-x.y.z.tar.gz containing subdirectory > eggname-x.y.z). > > You can install specific egg versions by specifying them like this: > :. Example > >$ chicken-install sendfile:1.7.23 > That's a useful feature that I was unaware of. I think it would also be useful if the -list option showed version information. > > 4. Support installation of eggs into directory other than > > $(chicken-install -repository). > > > > It would be nice to be able to install eggs into private area > > (for testing purposes, for migration purposes, just as developer > > convenience, whatever). > > As far as I understand what you mean, that's already supported. See > http://wiki.call-cc.org/man/4/Extensions#changing-repository-location But it seems to me that the issue here is not only where the eggs are installed, but where [csi|csc] looks for them at [runtime|compile time]. As I understand it the repository path is *one* location in the filesystem. It might be nice to support multiple paths. -- Matt Gushee ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Wish list
* Aleksej Saushev [130210 22:08]:
> Hello,
>
> Mario Domenech Goulart writes:
>
> > On Sun, 10 Feb 2013 22:36:41 +0400 Aleksej Saushev wrote:
> >
> >> I have talked to a user, and he reminded me of my past experience of
> >> using Chicken in production environment around four years ago. While
> >> many things improved since then, there're still some I'd like to have.
> >>
> >> 1. Distribute eggs by HTTP(S) and/or FTP(S).
> >>
> >> Today I have "chicken-install -r", but it still is a specialized client.
> >> I don't quite understand what I can do if I'm in mildly hostile network
> >> where automatically configured proxy requires authentication mechanism
> >> chicken-install doesn't support.
> >
> > Most (if not all) eggs are available via HTTP(S). For eggs hosted on
> > call-cc.org, you ca use
> > https://code.call-cc.org/svn/chicken-eggs/release/4/
>
> I have just tried it. It has asked user name and password.
> It seems not to allow anonymous access. This is not what I wish, I think.
User: anonymous, password is empty ("").
>
> > The other hosts (github, bitbucket, gitorious etc) also provide HTTP(S)
> > access (including tarballs).
> >
> >
> >> 2. Distribute eggs as source tarballs.
> >>
> >> In addition to (1) it would be nice if eggs were distributed as tarballs
> >> rather than individual files. In addition, such tarballs could be
> >> accompanied by cryptographic hash sums (individually per egg or as big
> >> list for the whole repository). These tarballs could even be signed, even.
> >
> > Yeah, that can be a handy feature for packagers.
> >
> > Maybe that feature can be implemented via some henrietta-cache hook or
> > something?
>
> By the way, what I wish is more than tarball automatically generated at
> each request. I want it stable, so that I could record cryptographic sums
> and be sure that the archive doesn't change tomorrow without version change.
> This is different from what github does (I don't know about bitbucket
> and the rest).
Henrietta cache does check each source specified in the egg-locations
file every hour for new releases, then downloads the source tarballs
for these and chicken-install will rely on these stored tarballs.
These are not created on the fly, so what you are suggesting could
be done this way. Or am I missing something?
Kind regards,
Christian
--
In the world, there is nothing more submissive and weak than
water. Yet for attacking that which is hard and strong, nothing can
surpass it. --- Lao Tzu
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Wish list
On Mon, Feb 11, 2013 at 09:33:01AM +0100, Christian Kellermann wrote: > Henrietta cache does check each source specified in the egg-locations > file every hour for new releases, then downloads the source tarballs > for these and chicken-install will rely on these stored tarballs. This is not accurate. Henrietta downloads the source, which can be aggregated and compressed in various ways (bz2, zip, targz, plain files) so they are currently all normalized and stored in uncompressed, unaggregated form (as plain files in a directory). This is because (see below). > These are not created on the fly, so what you are suggesting could > be done this way. Or am I missing something? The files are individually sent because not changing chicken-install was one of the goals of THE SYSTEM, and the old Henrietta plucked the individual files straight from svn (or a local checkout, I forget). Of course this protocol is easier to maintain by storing the files separately instead of in an archive. This could be changed, but it would break compatibility with every installation of Chicken that exists. If we were to do this we'd have to take care to somehow keep the old system available. Perhaps a new flag to henrietta to send a tarball? But that would be on-the-fly, which we don't want. In any case, henrietta's cache is designed to be just that, a cache. This means that any file can be deleted at any time and it will be re-fetched. That would mean a recreation of a tarball. And when you want to support signing in the first place, that's a problem that lies with the author (or packager). Doing it automatically offers almost no advantage, as a compromised server will happily keep applying automated signatures. Doing this is a huge burden on the community which we currently cannot support. Cheers, Peter -- http://sjamaan.ath.cx ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Wish list
Hi, On Sun, 10 Feb 2013 22:36:41 +0400 Aleksej Saushev wrote: > I have talked to a user, and he reminded me of my past experience of > using Chicken in production environment around four years ago. While > many things improved since then, there're still some I'd like to have. > > 1. Distribute eggs by HTTP(S) and/or FTP(S). > > Today I have "chicken-install -r", but it still is a specialized client. > I don't quite understand what I can do if I'm in mildly hostile network > where automatically configured proxy requires authentication mechanism > chicken-install doesn't support. > > 2. Distribute eggs as source tarballs. > > In addition to (1) it would be nice if eggs were distributed as tarballs > rather than individual files. In addition, such tarballs could be > accompanied by cryptographic hash sums (individually per egg or as big > list for the whole repository). These tarballs could even be signed, even. > > 3. Label eggs with their versions. > > It is unfortunate, that chicken-install still doesn't report egg version > in any way. Did I overlook it? It would be nice, if eggs would follow > common standard (eggname-x.y.z.tar.gz containing subdirectory eggname-x.y.z). > > 1-3 in conjunction would help paranoid people who want to track > versioning information for various reasons (security, stability in field). > (It would also help packagers and thus the community in whole due to > better visibility. I hope we do agree that there're people who prefer > using controlled installation rather than dumping random files into $PREFIX.) Does http://code.call-cc.org/egg-tarballs look ok? If I understand your wishes correctly, it should address 1-3. I've generated it with https://github.com/mario-goulart/egg-tarballs . It took less than 3 minutes to create all the tarballs and less than 1 second on the second run (just checks if tarballs exist and create them if they don't). If it looks good enough, I can set it to run right after henrietta-cache is finished. Best wishes. Mario -- http://parenteses.org/mario ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Wish list
* Mario Domenech Goulart [130211 14:26]: > Hi, > > On Sun, 10 Feb 2013 22:36:41 +0400 Aleksej Saushev wrote: > > > I have talked to a user, and he reminded me of my past experience of > > using Chicken in production environment around four years ago. While > > many things improved since then, there're still some I'd like to have. > > > > 1. Distribute eggs by HTTP(S) and/or FTP(S). > > > > Today I have "chicken-install -r", but it still is a specialized client. > > I don't quite understand what I can do if I'm in mildly hostile network > > where automatically configured proxy requires authentication mechanism > > chicken-install doesn't support. > > > > 2. Distribute eggs as source tarballs. > > > > In addition to (1) it would be nice if eggs were distributed as tarballs > > rather than individual files. In addition, such tarballs could be > > accompanied by cryptographic hash sums (individually per egg or as big > > list for the whole repository). These tarballs could even be signed, even. > > > > 3. Label eggs with their versions. > > > > It is unfortunate, that chicken-install still doesn't report egg version > > in any way. Did I overlook it? It would be nice, if eggs would follow > > common standard (eggname-x.y.z.tar.gz containing subdirectory > > eggname-x.y.z). > > > > 1-3 in conjunction would help paranoid people who want to track > > versioning information for various reasons (security, stability in field). > > (It would also help packagers and thus the community in whole due to > > better visibility. I hope we do agree that there're people who prefer > > using controlled installation rather than dumping random files into > > $PREFIX.) > > Does http://code.call-cc.org/egg-tarballs look ok? If I understand your > wishes correctly, it should address 1-3. > > I've generated it with https://github.com/mario-goulart/egg-tarballs . > It took less than 3 minutes to create all the tarballs and less than 1 > second on the second run (just checks if tarballs exist and create them > if they don't). If it looks good enough, I can set it to run right > after henrietta-cache is finished. Whoa, awesome work Mario :) -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Wish list
Hi, > Does http://code.call-cc.org/egg-tarballs look ok? If I understand your > wishes correctly, it should address 1-3. > > I've generated it with https://github.com/mario-goulart/egg-tarballs . > It took less than 3 minutes to create all the tarballs and less than 1 > second on the second run (just checks if tarballs exist and create them > if they don't). If it looks good enough, I can set it to run right > after henrietta-cache is finished. Nice! This looks good. Thanks Mario. Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Wish list
Hello, Peter Bex writes: > On Mon, Feb 11, 2013 at 09:33:01AM +0100, Christian Kellermann wrote: >> Henrietta cache does check each source specified in the egg-locations >> file every hour for new releases, then downloads the source tarballs >> for these and chicken-install will rely on these stored tarballs. > > This is not accurate. Henrietta downloads the source, which can be > aggregated and compressed in various ways (bz2, zip, targz, plain files) > so they are currently all normalized and stored in uncompressed, > unaggregated form (as plain files in a directory). > This is because (see below). > >> These are not created on the fly, so what you are suggesting could >> be done this way. Or am I missing something? > > The files are individually sent because not changing chicken-install > was one of the goals of THE SYSTEM, and the old Henrietta plucked the > individual files straight from svn (or a local checkout, I forget). > > Of course this protocol is easier to maintain by storing the files > separately instead of in an archive. > > This could be changed, but it would break compatibility with every > installation of Chicken that exists. If we were to do this we'd have > to take care to somehow keep the old system available. Perhaps a new > flag to henrietta to send a tarball? But that would be on-the-fly, > which we don't want. You can do the other way around. If one requests the old mode, unpack the archive on the fly and send individual files got from there. (You can even check signature on the fly, if you want it.) -- HE CE3OH... ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Wish list
On Mon, Feb 11, 2013 at 10:41:26PM +0400, Aleksej Saushev wrote: > > This could be changed, but it would break compatibility with every > > installation of Chicken that exists. If we were to do this we'd have > > to take care to somehow keep the old system available. Perhaps a new > > flag to henrietta to send a tarball? But that would be on-the-fly, > > which we don't want. > > You can do the other way around. If one requests the old mode, > unpack the archive on the fly and send individual files got from there. > (You can even check signature on the fly, if you want it.) True, we could do that, but who's going to sign it? It's still based on a caching mechanism. The fundamental problem is getting people to sign their code and provide static tarballs all the way upstream. Otherwise, if we blow away the cache or add a new mirror to our network, we'll get freshly generated tarballs with different checksums. Cheers, Peter -- http://sjamaan.ath.cx ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Wish list
On Sun, Feb 10, 2013 at 3:36 PM, Aleksej Saushev wrote: > Hello, > > I have talked to a user, and he reminded me of my past experience of > using Chicken in production environment around four years ago. While > many things improved since then, there're still some I'd like to have. > > 1. Distribute eggs by HTTP(S) and/or FTP(S). > > Today I have "chicken-install -r", but it still is a specialized client. > I don't quite understand what I can do if I'm in mildly hostile network > where automatically configured proxy requires authentication mechanism > chicken-install doesn't support. > I have added some support for http proxies to chicken-install a long time ago. It does not support HTTP authentication, but it shouldn't be more than a couple of hours of work to add the required support. It would be trivial to add, except that chicken-install cannot itself rely on eggs to perform the work. I am no longer inside a proxy, so the motivation for doing that evaporated. How many people are using Chicken behind corporate proxies? > > 4. Support installation of eggs into directory other than > $(chicken-install -repository). > > It would be nice to be able to install eggs into private area > (for testing purposes, for migration purposes, just as developer > convenience, whatever). > > This is supported already as others have pointed out, it's just not the default. My opinion is that the default repository should live under the current user's home directory (.chicken ?), so that no super-user permissions are necessary for installing eggs on development machines. Deployment setups could use a system-wide repo, as desired, or even bundle eggs with the deployed application. This would even allow multiple chicken versions to co-exist in the same machine (which is already possible, but requires some environment variable magic). -- Stephen ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Wish list
On Wed, 13 Feb 2013 16:18:31 -0300 Stephen Eilert wrote: > My opinion is that the default repository should live under the > current user's home directory (.chicken ?), so that no super-user > permissions are necessary for installing eggs on development > machines. Deployment setups could use a system-wide repo, as desired, > or even bundle eggs with the deployed application. This would even > allow multiple chicken versions to co-exist in the same machine > (which is already possible, but requires some environment variable > magic). Maybe http://wiki.call-cc.org/eggref/4/chicken-belt#chicken-select ? Best wishes. Mario -- http://parenteses.org/mario ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Wish list
On Wed, Feb 13, 2013 at 4:27 PM, Mario Domenech Goulart < mario.goul...@gmail.com> wrote: > On Wed, 13 Feb 2013 16:18:31 -0300 Stephen Eilert > wrote: > > > My opinion is that the default repository should live under the > > current user's home directory (.chicken ?), so that no super-user > > permissions are necessary for installing eggs on development > > machines. Deployment setups could use a system-wide repo, as desired, > > or even bundle eggs with the deployed application. This would even > > allow multiple chicken versions to co-exist in the same machine > > (which is already possible, but requires some environment variable > > magic). > > Maybe http://wiki.call-cc.org/eggref/4/chicken-belt#chicken-select ? I'll have a look. -- Stephen ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Wish list
Hi, On Mon, 11 Feb 2013 08:09:33 -0500 Mario Domenech Goulart wrote: > On Sun, 10 Feb 2013 22:36:41 +0400 Aleksej Saushev wrote: > >> I have talked to a user, and he reminded me of my past experience of >> using Chicken in production environment around four years ago. While >> many things improved since then, there're still some I'd like to have. >> >> 1. Distribute eggs by HTTP(S) and/or FTP(S). >> >> Today I have "chicken-install -r", but it still is a specialized client. >> I don't quite understand what I can do if I'm in mildly hostile network >> where automatically configured proxy requires authentication mechanism >> chicken-install doesn't support. >> >> 2. Distribute eggs as source tarballs. >> >> In addition to (1) it would be nice if eggs were distributed as tarballs >> rather than individual files. In addition, such tarballs could be >> accompanied by cryptographic hash sums (individually per egg or as big >> list for the whole repository). These tarballs could even be signed, even. >> >> 3. Label eggs with their versions. >> >> It is unfortunate, that chicken-install still doesn't report egg version >> in any way. Did I overlook it? It would be nice, if eggs would follow >> common standard (eggname-x.y.z.tar.gz containing subdirectory eggname-x.y.z). >> >> 1-3 in conjunction would help paranoid people who want to track >> versioning information for various reasons (security, stability in field). >> (It would also help packagers and thus the community in whole due to >> better visibility. I hope we do agree that there're people who prefer >> using controlled installation rather than dumping random files into $PREFIX.) > > Does http://code.call-cc.org/egg-tarballs look ok? If I understand your > wishes correctly, it should address 1-3. > > I've generated it with https://github.com/mario-goulart/egg-tarballs . > It took less than 3 minutes to create all the tarballs and less than 1 > second on the second run (just checks if tarballs exist and create them > if they don't). If it looks good enough, I can set it to run right > after henrietta-cache is finished. Although the original poster hasn't provided feedback on the implementation of the feature he requested, I've set egg-tarballs to generate tarballs for egg sources permanently at http://code.call-cc.org/egg-tarballs/ The tarball tree is updated (i.e., tarballs for new versions are generated) right after henrietta-cache is finished (currently henrietta-cache is run hourly). Please, let me know if you find any issue. Best wishes, Mario -- http://parenteses.org/mario ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] wish-list
On Mon, Oct 25, 2010 at 06:07:06AM -0400, Felix wrote: > > I added a "wish-list" to the wiki to hold stuff that would be nice to > have. This is of course not meant as a replacement for the > bug-tracker, but it may be worthwhile to have a place where to put > more ambitious ideas. > > http://wiki.call-cc.org/wish-list I love it! Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] wish-list
* Peter Bex [101025 12:12]: > On Mon, Oct 25, 2010 at 06:07:06AM -0400, Felix wrote: > > > > I added a "wish-list" to the wiki to hold stuff that would be nice to > > have. This is of course not meant as a replacement for the > > bug-tracker, but it may be worthwhile to have a place where to put > > more ambitious ideas. > > > > http://wiki.call-cc.org/wish-list > > I love it! I want a pony too! Christian ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] wish-list
On Mon, Oct 25, 2010 at 3:37 PM, Felix wrote: > > I added a "wish-list" to the wiki to hold stuff that would be nice to > have. This is of course not meant as a replacement for the > bug-tracker, but it may be worthwhile to have a place where to put > more ambitious ideas. > > http://wiki.call-cc.org/wish-list Good stuff! What is the current state of affairs with respect to this one? * Make it easy to create monoliths with no run-time demands to run on targets without chicken martin ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] wish-list
From: Martin DeMello Subject: Re: [Chicken-users] wish-list Date: Wed, 27 Oct 2010 12:11:59 +0530 > On Mon, Oct 25, 2010 at 3:37 PM, Felix > wrote: >> >> I added a "wish-list" to the wiki to hold stuff that would be nice to >> have. This is of course not meant as a replacement for the >> bug-tracker, but it may be worthwhile to have a place where to put >> more ambitious ideas. >> >> http://wiki.call-cc.org/wish-list > > Good stuff! What is the current state of affairs with respect to this one? > > * Make it easy to create monoliths with no run-time demands to run on > targets without chicken You can always link statically. Most eggs can be statically linked (those that don't can in most cases be converted). Do you have a specific example? cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] wish-list
On Wed, Oct 27, 2010 at 12:42 PM, Felix wrote: > From: Martin DeMello >> >> Good stuff! What is the current state of affairs with respect to this one? >> >> * Make it easy to create monoliths with no run-time demands to run on >> targets without chicken > > You can always link statically. Most eggs can be statically linked > (those that don't can in most cases be converted). Do you have a specific > example? No, I was wondering where exactly the problem lay (i.e. why that was on the wishlist). martin ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] wish-list
From: Martin DeMello Subject: Re: [Chicken-users] wish-list Date: Wed, 27 Oct 2010 14:11:59 +0530 > On Wed, Oct 27, 2010 at 12:42 PM, Felix > wrote: >> From: Martin DeMello >>> >>> Good stuff! What is the current state of affairs with respect to this one? >>> >>> * Make it easy to create monoliths with no run-time demands to run on >>> targets without chicken >> >> You can always link statically. Most eggs can be statically linked >> (those that don't can in most cases be converted). Do you have a specific >> example? > > No, I was wondering where exactly the problem lay (i.e. why that was > on the wishlist). The same could be said for cross-compiling. Chicken already has pretty good support for it, but nobody seems to read the manual. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: static linking (Re: [Chicken-users] wish-list
From: Daishi Kato Subject: static linking (Re: [Chicken-users] wish-list Date: Thu, 28 Oct 2010 01:04:27 +0900 > At Wed, 27 Oct 2010 03:12:08 -0400 (EDT), > Felix wrote: >> >> From: Martin DeMello >> Subject: Re: [Chicken-users] wish-list >> Date: Wed, 27 Oct 2010 12:11:59 +0530 >> >> > On Mon, Oct 25, 2010 at 3:37 PM, Felix >> > wrote: >> >> >> >> I added a "wish-list" to the wiki to hold stuff that would be nice to >> >> have. This is of course not meant as a replacement for the >> >> bug-tracker, but it may be worthwhile to have a place where to put >> >> more ambitious ideas. >> >> >> >> http://wiki.call-cc.org/wish-list >> > >> > Good stuff! What is the current state of affairs with respect to this one? >> > >> > * Make it easy to create monoliths with no run-time demands to run on >> > targets without chicken >> >> You can always link statically. Most eggs can be statically linked >> (those that don't can in most cases be converted). Do you have a specific >> example? >> >> >> cheers, >> felix > > felix, are you sure most eggs can be statically linked? > I assume it means chicken-install produces *.o files, correct? > > I have the following so installed (I think I'm using all of them), > and only 3 have objects: numbers-static.o openssl-static.o sendfile-static.o. > > abnf-charlist.so abnf-consumers.so abnf.so base64.so cgi-handler.so > condition-utils.so datatype.so defstruct.so environments.so hash-let.so > http-client.so iconv.so input-classes.so input-parse.so intarweb.so > internet-message.so iset.so json.so lexgen.so locale-builtin.so > locale-categories.so locale-components.so locale-current.so locale-posix.so > locale-timezone.so locale.so lookup-table-synch.so > lookup-table-unsafe-synch.so lookup-table-unsafe.so lookup-table.so > mailbox.so matchable.so md5.so message-digest-port.so message-digest.so > mime.so miscmacros.so moremacros.so numbers.so numeric-macros.so openssl.so > packrat.so record-variants.so sendfile.so setup-api.so setup-download.so > simple-directory-handler.so smtp.so spiffy-cookies.so spiffy.so srfi-29.so > srfi-4-checks.so srfi-4-errors.so ssax.so ssp-handler.so sxml-transforms.so > sxpath-lolevel.so sxpath.so synch.so txpath.so type-checks.so type-errors.so > typeclass.so unicode-char-sets.so uri-common.so uri-generic.so > utf8-case-map.so utf8-lolevel.so utf8-srfi-13.so utf8-srfi-14.so utf8.so > variable-item.so web-scheme-handler.so > > I wish I could link them statically. > Uh - that's a lot. Some of them can be easily converted, some are compile-time only, but some others are more subtle. Do you need all those in a single application? cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: static linking (Re: [Chicken-users] wish-list
From: Daishi Kato Subject: static linking (Re: [Chicken-users] wish-list Date: Thu, 28 Oct 2010 01:04:27 +0900 Oh, and I forgot to mention that you can also use the `-deploy' option for `csc' and `chicken-install' - that might be a simpler way to create a standalone application. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: static linking (Re: [Chicken-users] wish-list
At Fri, 29 Oct 2010 04:46:34 -0400 (EDT), Felix wrote: > Uh - that's a lot. Some of them can be easily converted, some are compile-time > only, but some others are more subtle. Do you need all those in a single > application? More precisely, here's the list of eggs that I (use in a single app. base64 environments files http-client http-server iconv intarweb json lolevel mailbox md5 mime posix regex rfc822 smtp spiffy spiffy-cookies srfi-1 srfi-13 srfi-14 srfi-18 srfi-4 srfi-69 ssax sxml-transforms sxpath uri-common uri-generic utf8-lolevel utils I installed these eggs and there are a lot of so files in lib. Thanks. Daishi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: static linking (Re: [Chicken-users] wish-list
At Fri, 29 Oct 2010 04:48:14 -0400 (EDT), Felix wrote: > > From: Daishi Kato > Subject: static linking (Re: [Chicken-users] wish-list > Date: Thu, 28 Oct 2010 01:04:27 +0900 > > Oh, and I forgot to mention that you can also use the `-deploy' > option for `csc' and `chicken-install' - that might be a > simpler way to create a standalone application. Oh, this sounds something. Yes, I don't need to eliminate ld dependence. I'm not sure if I understand the usage of -deploy. csc: -deploydeploy self-contained application bundle chicken-install: -deploy build extensions for deployment So, I can just re-install all eggs with -deploy. and compile my app with -deploy, which produces an executable which only depends libc and some standard libs? Best, Daishi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: static linking (Re: [Chicken-users] wish-list
On Fri, Oct 29, 2010 at 10:57:23PM +0900, Daishi Kato wrote: > Oh, this sounds something. Yes, I don't need to eliminate ld dependence. > I'm not sure if I understand the usage of -deploy. > > csc: > -deploydeploy self-contained application bundle Try http://wiki.call-cc.org/manual/Deployment Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: static linking (Re: [Chicken-users] wish-list
At Fri, 29 Oct 2010 16:09:42 +0200, Peter Bex wrote: > > On Fri, Oct 29, 2010 at 10:57:23PM +0900, Daishi Kato wrote: > > Oh, this sounds something. Yes, I don't need to eliminate ld dependence. > > I'm not sure if I understand the usage of -deploy. > > > > csc: > > -deploydeploy self-contained application bundle > > Try http://wiki.call-cc.org/manual/Deployment Thanks. So, this is to place so files with the executables (and link). I'm doing a workaround with CHICKEN_PREFIX. (I looked for CHICKEN_REPOSITORY_PATH, which is no longer available.) I do not need to compile w/ -static, but to link with *.o eggs, isn't it possible? --daishi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: static linking (Re: [Chicken-users] wish-list
On Fri, Oct 29, 2010 at 11:39:38PM +0900, Daishi Kato wrote: > At Fri, 29 Oct 2010 16:09:42 +0200, > Peter Bex wrote: > > > > On Fri, Oct 29, 2010 at 10:57:23PM +0900, Daishi Kato wrote: > > > Oh, this sounds something. Yes, I don't need to eliminate ld dependence. > > > I'm not sure if I understand the usage of -deploy. > > > > > > csc: > > > -deploydeploy self-contained application > > > bundle > > > > Try http://wiki.call-cc.org/manual/Deployment > > Thanks. > So, this is to place so files with the executables (and link). > > I'm doing a workaround with CHICKEN_PREFIX. > (I looked for CHICKEN_REPOSITORY_PATH, which is no longer available.) > > I do not need to compile w/ -static, but to link with *.o eggs, > isn't it possible? > Not every egg supports linking to the .o file. For those eggs that don't, you'll need to add the support yourself. If you do, I'm sure a patch will be accepted making each egg you work with able to statically link. Adding support is easy but not automatic. Usually it will be a few extra lines added to the .setup file for each egg. -Alan -- .i ko djuno fi le do sevzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: static linking (Re: [Chicken-users] wish-list
On Fri, Oct 29, 2010 at 09:02:05AM -0600, Alan Post wrote: > Not every egg supports linking to the .o file. For those eggs that > don't, you'll need to add the support yourself. If you do, I'm sure > a patch will be accepted making each egg you work with able to > statically link. Yes, but it won't be maintained, except maybe by guessing how changes in the dynamic build apply to the static build, because nobody really uses static builds (proven by the lack of eggs that have static options in the first place). > Adding support is easy but not automatic. Usually it will be a few > extra lines added to the .setup file for each egg. It would be nice (TM) if building static files could be automatically done by chicken-install based on the rules for building dynamic libs. I guess that's just impossible in the general case though. Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: static linking (Re: [Chicken-users] wish-list
On Fri, Oct 29, 2010 at 07:09:15PM +0200, Peter Bex wrote: > On Fri, Oct 29, 2010 at 09:02:05AM -0600, Alan Post wrote: > > Not every egg supports linking to the .o file. For those eggs that > > don't, you'll need to add the support yourself. If you do, I'm sure > > a patch will be accepted making each egg you work with able to > > statically link. > > Yes, but it won't be maintained, except maybe by guessing how changes > in the dynamic build apply to the static build, because nobody really > uses static builds (proven by the lack of eggs that have static options > in the first place). > > > Adding support is easy but not automatic. Usually it will be a few > > extra lines added to the .setup file for each egg. > > It would be nice (TM) if building static files could be automatically > done by chicken-install based on the rules for building dynamic libs. > I guess that's just impossible in the general case though. > If we're on that topic, it would be nice if, rather than specifying compile options, we had: (compile-debug-dynamic) (compile-optimize-dynamic) (compile-profile-dynamic) (compile-debug-static) (compile-optimize-static) (compile-profile-static) Presumably then an egg says (compile) and the configuration of the repository chooses which (or how many) types of build to perform without the egg author having to remember to accomodate everyone. -Alan -- .i ko djuno fi le do sevzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: static linking (Re: [Chicken-users] wish-list
On Fri, Oct 29, 2010 at 07:09:15PM +0200, Peter Bex wrote: > On Fri, Oct 29, 2010 at 09:02:05AM -0600, Alan Post wrote: > > Not every egg supports linking to the .o file. For those eggs that > > don't, you'll need to add the support yourself. If you do, I'm sure > > a patch will be accepted making each egg you work with able to > > statically link. > > Yes, but it won't be maintained, except maybe by guessing how changes > in the dynamic build apply to the static build, because nobody really > uses static builds (proven by the lack of eggs that have static options > in the first place). > I need this support too, though not for as many eggs as Daishi needs. I was planning on adding support to those eggs I did need, and I would hope I'd be able to get the patch applied to the repository. -Alan -- .i ko djuno fi le do sevzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: static linking (Re: [Chicken-users] wish-list
On Fri, Oct 29, 2010 at 11:30:48AM -0600, Alan Post wrote: > I need this support too, though not for as many eggs as Daishi > needs. > > I was planning on adding support to those eggs I did need, and I > would hope I'd be able to get the patch applied to the repository. Oh don't get me wrong, it would be (gladly!) accepted I'm sure, but there'd be nobody guarding it against breakages but you. Kind of like Windows support... *hides* Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: static linking (Re: [Chicken-users] wish-list
From: Daishi Kato Subject: Re: static linking (Re: [Chicken-users] wish-list Date: Fri, 29 Oct 2010 22:57:23 +0900 > At Fri, 29 Oct 2010 04:48:14 -0400 (EDT), > Felix wrote: >> >> From: Daishi Kato >> Subject: static linking (Re: [Chicken-users] wish-list >> Date: Thu, 28 Oct 2010 01:04:27 +0900 >> >> Oh, and I forgot to mention that you can also use the `-deploy' >> option for `csc' and `chicken-install' - that might be a >> simpler way to create a standalone application. > > Oh, this sounds something. Yes, I don't need to eliminate ld dependence. > I'm not sure if I understand the usage of -deploy. > > csc: > -deploydeploy self-contained application bundle > > chicken-install: >-deploy build extensions for deployment > > So, I can just re-install all eggs with -deploy. > and compile my app with -deploy, which produces > an executable which only depends libc and some standard libs? You build your application with `csc -deploy ...' and then use `chicken-install -deploy -p ...' to build the extensions and install them into the application-directory. See also: http://wiki.call-cc.org/man/4/Deployment cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: static linking (Re: [Chicken-users] wish-list
From: Daishi Kato Subject: Re: static linking (Re: [Chicken-users] wish-list Date: Fri, 29 Oct 2010 22:51:43 +0900 > At Fri, 29 Oct 2010 04:46:34 -0400 (EDT), > Felix wrote: >> Uh - that's a lot. Some of them can be easily converted, some are >> compile-time >> only, but some others are more subtle. Do you need all those in a single >> application? > > More precisely, here's the list of eggs that I (use in a single app. > base64 environments files http-client http-server iconv intarweb > json lolevel mailbox md5 mime posix regex rfc822 smtp spiffy spiffy-cookies > srfi-1 srfi-13 srfi-14 srfi-18 srfi-4 srfi-69 ssax sxml-transforms sxpath > uri-common uri-generic utf8-lolevel utils Some of those are core libraries that are linked statically with libchicken.a, and the others should be convertible to allow static linking. There might be a problem with indirect extension requirements (see also ticket #420 on bugs.call-cc.org), but that can be solved. Actually chicken recently (since 4.6.0) got a `standard-extension' procedure that avoids the boilerplate in "standard" eggs (those that consist of a single file and provide a single module of the same name) and automatically compiles for static linking (to be used in .setup scripts). I will start adding static linking support to some of these. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: static linking (Re: [Chicken-users] wish-list
At Sun, 31 Oct 2010 23:55:05 +0100 (CET), Felix wrote: > > From: Daishi Kato > Subject: Re: static linking (Re: [Chicken-users] wish-list > Date: Fri, 29 Oct 2010 22:51:43 +0900 > > > At Fri, 29 Oct 2010 04:46:34 -0400 (EDT), > > Felix wrote: > >> Uh - that's a lot. Some of them can be easily converted, some are > >> compile-time > >> only, but some others are more subtle. Do you need all those in a single > >> application? > > > > More precisely, here's the list of eggs that I (use in a single app. > > base64 environments files http-client http-server iconv intarweb > > json lolevel mailbox md5 mime posix regex rfc822 smtp spiffy spiffy-cookies > > srfi-1 srfi-13 srfi-14 srfi-18 srfi-4 srfi-69 ssax sxml-transforms sxpath > > uri-common uri-generic utf8-lolevel utils > > Some of those are core libraries that are linked statically with > libchicken.a, and the others should be convertible to allow static > linking. There might be a problem with indirect extension requirements > (see also ticket #420 on bugs.call-cc.org), but that can be > solved. Actually chicken recently (since 4.6.0) got a > `standard-extension' procedure that avoids the boilerplate in > "standard" eggs (those that consist of a single file and provide a > single module of the same name) and automatically compiles for static > linking (to be used in .setup scripts). > > I will start adding static linking support to some of these. Sounds great. In the meantime, I will try -deploy. Best, Daishi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] [wish list] chicken-install: show available eggs, upgrade all installed eggs?
Hi, It would be good to be able to show available eggs when installing an egg, such that user can grep and find wanted eggs quickly without having to browse at http://wiki.call-cc.org/chicken-projects/egg- index-4.html. Simply a text dump of that html page would help much. The other feature is being able to upgrade all installed eggs after, for instance, upgrading chicken. Then i don't have to reinstall each missing one by one, desperately. Thanks. P.S. The mixture of tabs and space in the source codes really cause a headache for the indention.. -William ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [wish list] chicken-install: show available eggs, upgrade all installed eggs?
Hello! > It would be good to be able to show available eggs when installing an egg, > such > that user can grep and find wanted eggs quickly without having to browse at > http://wiki.call-cc.org/chicken-projects/egg- index-4.html. Simply a text > dump > of that html page would help much. That is possible, but would require a regularly updated "master" document somewhere on our server. > > The other feature is being able to upgrade all installed eggs after, for > instance, upgrading chicken. Then i don't have to reinstall each missing one > by > one, desperately. That has been requested repeatedly in the past, but I'm sceptical. Bulk updates like that make it extremely easy to break everything, unless you have a very rigid control over the stability of the currently available extensions. The egg repository is actually pretty good in that regard, but still, broken eggs and broken dependencies slip in from time to time. We are quick to fix those, but something like a bulk update could easily result in broken installations. For example, I may have several applications that use one or the other installed egg. Those eggs may be out of date, but I'm more interested in having my system running, so when I install new extensions, "chicken-install" will warn me when an egg requires higher versions and I have the choice to think twice about whether I want to do that or not. On the other hand, some people like to be up-to-date at every cost, so for those a bulk update option might be desirable. To come to the point: should be possible, but currently not of high priority. > P.S. The mixture of tabs and space in the source codes really cause a headache > for the indention.. What editor are you using? cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [wish list] chicken-install: show available eggs, upgrade all installed eggs?
On Thu, May 05, 2011 at 06:06:16AM -0400, Felix wrote:
> Hello!
>
> > It would be good to be able to show available eggs when installing an egg,
> > such
> > that user can grep and find wanted eggs quickly without having to browse at
> > http://wiki.call-cc.org/chicken-projects/egg- index-4.html. Simply a text
> > dump
> > of that html page would help much.
>
> That is possible, but would require a regularly updated "master" document
> somewhere
> on our server.
Like "egg-locations" in the new distributed system? ;)
http://bugs.call-cc.org/browser/release/4/egg-locations
> > P.S. The mixture of tabs and space in the source codes really cause a
> > headache
> > for the indention..
>
> What editor are you using?
I agree that TabsAreEvil in Scheme/Lisp code. Even with emacs, it's
highly dependent on your tab width.
Suppose I indented the following piece of code using tabs with a tab
setting of 4:
(define (foo)
(if (whatever)
(print "whatever")
(print "not whatever")))
and you view it with a tab setting of 8, you'd get:
(define (foo)
(if (whatever)
(print "whatever")
(print "not whatever")))
When indenting with tab setting 8 and viewing with tab setting 4, you
get the opposite thing (things not indented far enough).
With Lisp/Scheme code, the only sensible indentation style really is
spaces. With braces-like languages like C it makes sense to use tabs
if used consistently, but even there it's a good source of flamewars.
Because if you consistently indent and have set tabs to 8, it looks like
this on the screen:
int main(void) {
if (whatever) {
printf("blah\n");
}
}
When someone with tabs set to 4 views this code, he or she will see
the following:
int main(void) {
if (whatever) {
printf("blah\n");
}
}
See also http://emacswiki.org/TabsAreEvil
Cheers,
Peter
--
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [wish list] chicken-install: show available eggs, upgrade all installed eggs?
> See also http://emacswiki.org/TabsAreEvil It's the default behaviour of my emacs and it saves time (in the way I use the keyboard). And telling people how to layout the invisible part of their code is a waste of time. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [wish list] chicken-install: show available eggs, upgrade all installed eggs?
On Thu, May 05, 2011 at 06:52:16AM -0400, Felix wrote: > > See also http://emacswiki.org/TabsAreEvil > > It's the default behaviour of my emacs That's *very* easy to fix and I don't understand why emacs has such a silly default for lispy modes: (add-hook 'lisp-mode-hook (lambda () (setq indent-tabs-mode nil))) (add-hook 'scheme-mode-hook (lambda () (setq indent-tabs-mode nil))) > and it saves time (in the way I use the keyboard). I don't really understand how. If you mean you press the tab key to auto-indent, that still works even if indent-tabs-mode is off (at least here it does). You can also press tab to jump to the start of a line even if it's already indented. > And telling people how to layout the invisible part of their code > is a waste of time. I understand that, and that's why I didn't complain about it before (also, my emacs happens to have the same tab width as yours so it's not as jarring to me as it was to the OP) But since others have spoken up and this is easy to fix, I decided to chime in. Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [wish list] chicken-install: show available eggs, upgrade all installed eggs?
On Thu, May 5, 2011 at 7:06 AM, Felix wrote: > Hello! > >> It would be good to be able to show available eggs when installing an egg, >> such >> that user can grep and find wanted eggs quickly without having to browse at >> http://wiki.call-cc.org/chicken-projects/egg- index-4.html. Simply a text >> dump >> of that html page would help much. > > That is possible, but would require a regularly updated "master" document > somewhere > on our server. Henrietta already provides a list of eggs to chicken-install. I suppose that could be used, if we don't care about showing egg descriptions in such a list. > >> >> The other feature is being able to upgrade all installed eggs after, for >> instance, upgrading chicken. Then i don't have to reinstall each missing >> one by >> one, desperately. > > That has been requested repeatedly in the past, but I'm > sceptical. Bulk updates like that make it extremely easy to break > everything, unless you have a very rigid control over the stability of > the currently available extensions. The egg repository is actually > pretty good in that regard, but still, broken eggs and broken > dependencies slip in from time to time. We are quick to fix those, but > something like a bulk update could easily result in broken > installations. > > For example, I may have several applications that use one or the other > installed egg. Those eggs may be out of date, but I'm more interested > in having my system running, so when I install new extensions, > "chicken-install" will warn me when an egg requires higher versions > and I have the choice to think twice about whether I want to do that > or not. But only if you already know which versions you are supposed to be using. For deployed code, I guess you could take the list from a running server, manually. For code sitting in a repository, it doesn't work like that. Even when you do know the versions, it could get tedious. However, you've already provided the solution for that, your 'overrides' :) --Stephen Sent from my Emacs ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [wish list] chicken-install: show available eggs, upgrade all installed eggs?
On May 5, Felix scribed: > > For example, I may have several applications that use one or the other > installed egg. Those eggs may be out of date, but I'm more interested > in having my system running, so when I install new extensions, > "chicken-install" will warn me when an egg requires higher versions > and I have the choice to think twice about whether I want to do that > or not. Maybe I'm not doing it right, but when I install a new version of chicken, I don't have a way to rebuild the eggs, short of using chicken-install to re-retrieve the egg and rebuild. Is there another way to do this? Do people normally keep the egg source laying around for chicken upgrades? I don't see an option on chicken-install to set this up, but I have to admit I haven't looked very hard. tia, dave ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [wish list] chicken-install: show available eggs, upgrade all installed eggs?
On Thu, May 05, 2011 at 11:33:54AM -0300, Stephen Eilert wrote: > On Thu, May 5, 2011 at 7:06 AM, Felix > > That is possible, but would require a regularly updated "master" document > > somewhere > > on our server. > > Henrietta already provides a list of eggs to chicken-install. AFAIK it doesn't do that. chicken-install asks for an egg of a particular name, and henrietta either returns that or gives an error. You need to know the egg name beforehand. But, like I said before, if the new distributed system will be used, this list is already -necessarily- available. Nobody seems particularly interested in the distributed system though, so we might just scrap it. > I suppose that could be used, if we don't care about showing egg > descriptions in such a list. Descriptions aren't in the distributed list either. It could be fetched recursively of course. Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [wish list] chicken-install: show available eggs, upgrade all installed eggs?
Felix call-with-current-continuation.org> writes: > That is possible, but would require a regularly updated "master" document > somewhere on our server. Good.. I tend to use chicken-install in a way similar to apt-get in Debian. > > The other feature is being able to upgrade all installed eggs after, for > > instance, upgrading chicken. Then i don't have to reinstall each missing > > one by one, desperately. > > That has been requested repeatedly in the past, but I'm > sceptical. Bulk updates like that make it extremely easy to break > everything, unless you have a very rigid control over the stability of > the currently available extensions. The egg repository is actually > pretty good in that regard, but still, broken eggs and broken > dependencies slip in from time to time. We are quick to fix those, but > something like a bulk update could easily result in broken > installations. > > For example, I may have several applications that use one or the other > installed egg. Those eggs may be out of date, but I'm more interested > in having my system running, so when I install new extensions, > "chicken-install" will warn me when an egg requires higher versions > and I have the choice to think twice about whether I want to do that > or not. > > On the other hand, some people like to be up-to-date at every cost, so > for those a bulk update option might be desirable. > > To come to the point: should be possible, but currently not of high > priority. I'm not crazy at getting bleeding edge eggs.. However, I do like to upgrade `chicken' itself whenever a newer release comes out. Only realize that i have to find out and reinstall all eggs again. (Because at least all the eggs have to be recompiled using the new chicken?) > What editor are you using? Emacs. You mentioned in the other mail it has no problem with default setup. i think that may be due to my emacs config then, i will check my config. However, eliminating use of tabs would still be much better, where the indention will be the same in all editors. -William ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [wish list] chicken-install: show available eggs, upgrade all installed eggs?
On Thu, 2011-05-05 at 16:51 +0200, Peter Bex wrote: > On Thu, May 05, 2011 at 11:33:54AM -0300, Stephen Eilert wrote: > > On Thu, May 5, 2011 at 7:06 AM, Felix > > > That is possible, but would require a regularly updated "master" document > > > somewhere > > > on our server. > > > > Henrietta already provides a list of eggs to chicken-install. > > AFAIK it doesn't do that. chicken-install asks for an egg of a > particular name, and henrietta either returns that or gives an error. > You need to know the egg name beforehand. > > But, like I said before, if the new distributed system will be used, > this list is already -necessarily- available. Nobody seems particularly > interested in the distributed system though, so we might just scrap it. On the contrary! I'm very interested in the distributed system. It is physically written down on my todo list to find the documentation and give it a go. Please don't drop it yet! > > I suppose that could be used, if we don't care about showing egg > > descriptions in such a list. > > Descriptions aren't in the distributed list either. It could be fetched > recursively of course. > > Cheers, > Peter ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [wish list] chicken-install: show available eggs, upgrade all installed eggs?
On May 5, 2011, at 9:58 AM, William Xu wrote: > Felix call-with-current-continuation.org> writes: >> What editor are you using? > > Emacs. You mentioned in the other mail it has no problem with default setup. > i > think that may be due to my emacs config then, i will check my config. > However, > eliminating use of tabs would still be much better, where the indention will > be > the same in all editors. Hi there, Try putting the following in .dir-locals.el in the root directory of your git checkout: ((nil . ((indent-tabs-mode . t) (tab-width . 8 This will cause your emacs to maintain Felix's indentation conventions when editing any file under that directory, without changing your preferred defaults. Jim ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [wish list] chicken-install: show available eggs, upgrade all installed eggs?
> > I'm not crazy at getting bleeding edge eggs.. However, I do like to upgrade > `chicken' itself whenever a newer release comes out. Only realize that i have > to find out and reinstall all eggs again. (Because at least all the eggs have > to > be recompiled using the new chicken?) Not always, only if some incompatibility has been introduced, particularly in the C runtime system or header-files. I have added an option called "-reinstall" to chicken-install (see experimental branch). This will reinstall all installed eggs, using the same versions. Only minimally tested, though. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [wish list] chicken-install: show available eggs, upgrade all installed eggs?
On Sun, May 08, 2011 at 12:52:36PM +0200, Felix wrote: > > > > I'm not crazy at getting bleeding edge eggs.. However, I do like to upgrade > > `chicken' itself whenever a newer release comes out. Only realize that i > > have > > to find out and reinstall all eggs again. (Because at least all the eggs > > have to > > be recompiled using the new chicken?) > > Not always, only if some incompatibility has been introduced, particularly in > the C runtime system or header-files. > > I have added an option called "-reinstall" to chicken-install (see > experimental > branch). This will reinstall all installed eggs, using the same versions. Only > minimally tested, though. I don't think this will help much. If there's an incompatibility, generally the ABI version is increased too (the 5 in /usr/lib/chicken/5/), so reinstall would reinstall all 0 eggs you have under the new directory :) Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [wish list] chicken-install: show available eggs, upgrade all installed eggs?
From: Peter Bex Subject: Re: [Chicken-users] [wish list] chicken-install: show available eggs, upgrade all installed eggs? Date: Sun, 8 May 2011 13:15:18 +0200 > On Sun, May 08, 2011 at 12:52:36PM +0200, Felix wrote: >> > >> > I'm not crazy at getting bleeding edge eggs.. However, I do like to upgrade >> > `chicken' itself whenever a newer release comes out. Only realize that i >> > have >> > to find out and reinstall all eggs again. (Because at least all the eggs >> > have to >> > be recompiled using the new chicken?) >> >> Not always, only if some incompatibility has been introduced, particularly in >> the C runtime system or header-files. >> >> I have added an option called "-reinstall" to chicken-install (see >> experimental >> branch). This will reinstall all installed eggs, using the same versions. >> Only >> minimally tested, though. > > I don't think this will help much. If there's an incompatibility, > generally the ABI version is increased too (the 5 in /usr/lib/chicken/5/), > so reinstall would reinstall all 0 eggs you have under the new directory :) With incompatibility I mean small ones. Normally the ABI doesn't change. The case you describe here is for big incompatibilities. Hey, it's a start, ok? cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [wish list] chicken-install: show available eggs, upgrade all installed eggs?
On Thu, May 5, 2011 at 7:18 PM, Peter Bex wrote: > > With Lisp/Scheme code, the only sensible indentation style really is > spaces. With braces-like languages like C it makes sense to use tabs > if used consistently, but even there it's a good source of flamewars. You get exactly the same problem in C with nested function applications: foo(some_long_function_call1(...), some_long_function_call2(...), ...); -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [wish list] chicken-install: show available eggs, upgrade all installed eggs?
On Mon, May 09, 2011 at 10:25:27PM +0900, Alex Shinn wrote: > On Thu, May 5, 2011 at 7:18 PM, Peter Bex wrote: > > > > With Lisp/Scheme code, the only sensible indentation style really is > > spaces. With braces-like languages like C it makes sense to use tabs > > if used consistently, but even there it's a good source of flamewars. > > You get exactly the same problem in C with nested function > applications: > > foo(some_long_function_call1(...), > some_long_function_call2(...), > ...); Yeah. You can still use tabs to align things within block though! To get completely consistent results you'd need to indent using tabs up till you're aligned with foo and use spaces to indent the arguments. I think the TabsAreEvil page describes this too. Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
