Re: [Chicken-users] bug update-uri in uri-common
On Wed, May 28, 2014 at 11:18:14AM +0200, Kristian Lein-Mathisen wrote: > I realize I already put down my vote, but I'd like to promote my case after > some thought. I guess what we're trying to find out is what's more > troublesome and/or surprising: > > 1. having to set the port explicitly (to #f?) when you want to change the > scheme and its port > 2. having to set the port explicitly back to its original value if you want > to change scheme but not its port > > I don't think it's unreasonable to expect the user to realize he/she has to > change the port if he/she changes the port (as in 1.). That requires an > understanding of the relationship between scheme and port by the user. I've now (finally!) changed the implementation not to switch ports when changing schemes (in uri-common trunk). However, taking a look at this behaviour caused me to question another thing: If a port is the default port for the scheme, should it be kept around? Right now, if you do (update-uri uri scheme: 'http port: 80) it will clear the port. This is done so that the uri will be printed as http://foo/bar rather than http://foo:80/bar, which would be redundant. Unfortunately, that also means that (uri-port (update-uri uri port: x)) may return either x or #f. And if you (update-uri (update-uri uri port: 80 scheme: 'http) scheme: 'https) that will result in the port not being 80. I can keep it like this, but I can also keep around the selected port. If that's done, it can still be decided to print the URI as http://foo/bar even if the (uri-port uri) returns 80. So here's a new poll: a) The current behaviour of resetting port to #f if it's the default port for this scheme is ok. b) The port should not be reset, and the uri should be printed with an explicit port, even if it's the default for this scheme. c) The port should not be reset, but the uri should be printed without port if it's the default for this scheme. Once results are in, I'll adjust the behaviour accordingly, and make a new uri-common release. Cheers, Peter -- http://www.more-magic.net ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] [ANN] CHICKEN 4.9.0.1 has been released [was: Re: [Chicken-announce] [ANN] CHICKEN 4.9.0 has been released]
On Mon, Jun 02, 2014 at 05:35:01PM +0200, Peter Bex wrote: > Dear CHICKEN users, > > We are pleased to announce the immediate availability of CHICKEN 4.9.0 > at the following URL: > http://code.call-cc.org/releases/4.9.0/chicken-4.9.0.tar.gz Dear CHICKEN users, It has been pointed out that 4.9.0 self-identifies as 4.8.0 due to C_MINOR_VERSION being defined as 8. This also results in the feature chicken-4.8 being defined, which will break any egg or program attempting to detect the version of CHICKEN it is running under. As a result, we've decided to immediately release CHICKEN 4.9.0.1, as the first stability release. The only change here is the update of the minor version, and an added regression test for this problem. If you're already running 4.9.0, we highly recommend updating to 4.9.0.1 as it will prevent problems with eggs in the future. The tarball is available in the usual location: http://code.call-cc.org/releases/4.9.0.1/chicken-4.9.0.1.tar.gz and so is the NEWS file: http://code.call-cc.org/releases/4.9.0/NEWS-4.9.0.1 Kind regards, The CHICKEN Team ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [Chicken-announce] [ANN] CHICKEN 4.9.0.1 has been released [was: Re: [ANN] CHICKEN 4.9.0 has been released]
On Sat, Jun 07, 2014 at 04:06:51PM +0200, Peter Bex wrote: > The tarball is available in the usual location: > http://code.call-cc.org/releases/4.9.0.1/chicken-4.9.0.1.tar.gz Of course that URL should be http://code.call-cc.org/releases/4.9.0/chicken-4.9.0.1.tar.gz Kind regards, The CHICKEN Team ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] bug update-uri in uri-common
Peter Bex scripsit: > c) The port should not be reset, but the uri should be printed without > port if it's the default for this scheme. +1 for (c). -- John Cowan http://www.ccil.org/~cowanco...@ccil.org Is a chair finely made tragic or comic? Is the portrait of Mona Lisa good if I desire to see it? Is the bust of Sir Philip Crampton lyrical, epical or dramatic? If a man hacking in fury at a block of wood make there an image of a cow, is that image a work of art? If not, why not? --Stephen Dedalus ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
