> Would the intention be to move all primary development effort over to
> the 5 branch? How would 4.9 stability releases work? Most of the
> proposed 5 work is cleanup. Where would feature work be expected to be
> done? What work would be done before the first stable 5 release and what
> work would
Hi,
On Tue, 19 Aug 2014 18:13:43 +0200 Peter Bex wrote:
> On Tue, Aug 19, 2014 at 05:21:06PM +0200, Felix Winkelmann wrote:
>> > I would think that support for Chicken 2 & 3 should be dropped after a
>> > Chicken 5 branch is made.
>>
>> Yes, that sounds reasonable.
>
> I didn't know we still s
Felix Winkelmann scripsit:
> Hm. Wasn't wchar_t on Windows 16 bits? Do they use UTF-16 there?
Yes, they do nowadays. Of course, so do the JVM and the CLR.
> The internal representation is a different issue compared to the
> external encoding. It would be nice if we could separate these two
> th
>> Well, actually we might as well support several: ASCII/Latin-1, UTF-8
>> and UCS-2/UCS-4. Without UTF-8 it would just be a variable
>> element-size option. But I agree that this doesn't make maintenance
>> any easier... Let's think some more about this. We don't have to
>> decide right now.
>
>
Felix Winkelmann scripsit:
> Well, actually we might as well support several: ASCII/Latin-1, UTF-8
> and UCS-2/UCS-4. Without UTF-8 it would just be a variable
> element-size option. But I agree that this doesn't make maintenance
> any easier... Let's think some more about this. We don't have to
>
On Wed, Aug 20, 2014 at 01:27:58PM +0100, Andy Bennett wrote:
> It may even be possible to do some parts of the work, such as splitting
> srfis out of core, in 4.X as these will not require .scm sourcecode
> changes; only metadata changes.
I'm not sure about this. We could do that while 5.0 is be
Hi,
> I'd love to hear from some of the people using CHICKEN in their business
> or for other Serious Projects (Kristian? Ivan? Andy?) how painful this
> would be for them.
After taking some time to familiarise myself with them, these all sound
like big and important changes.
It took us a long t
Hi,
> The Chicken wiki still has an index of Chicken 3 eggs, although I do
> think chicken-setup is no longer operational.
> Perhaps now would be a good time to clean the wiki of vestigial
> references to 2 & 3.
AIUI, this documentation is preserved for posterity and in case anyone
wants to forwa
Am 18.08.2014 17:06, schrieb Peter Bex:
Yeah, we're pretty thinly spread right now.
I think calling this CHICKEN 5 may be a good idea. I don't know for
sure though: adding backwards compatibility may actually be easier
in this situation. Ripping out the SRFIs from core should be pretty
simple
On Wed, Aug 20, 2014 at 5:40 PM, Felix Winkelmann <
felix.winkelm...@bevuta.com> wrote:
> From: Peter Bex
> Subject: Re: [Chicken-hackers] CR #1142 and upcoming changes
> Date: Wed, 20 Aug 2014 10:02:51 +0200
>
> > On Wed, Aug 20, 2014 at 11:59:58AM +0400, Yarosl
From: Peter Bex
Subject: Re: [Chicken-hackers] CR #1142 and upcoming changes
Date: Wed, 20 Aug 2014 10:02:51 +0200
> On Wed, Aug 20, 2014 at 11:59:58AM +0400, Yaroslav Tsarko wrote:
>> On 19.08.2014 19:24, Felix Winkelmann wrote:
>> >
>> >Sounds like a good first ste
On Wed, Aug 20, 2014 at 11:59:58AM +0400, Yaroslav Tsarko wrote:
> On 19.08.2014 19:24, Felix Winkelmann wrote:
> >
> >Sounds like a good first step, even though I personally would prefer
> >UCS-4 strings (constant lookup + modification and so on). But that
> >seems to be unpopular, AFAICT...
>
>
On 19.08.2014 19:24, Felix Winkelmann wrote:
Sounds like a good first step, even though I personally would prefer
UCS-4 strings (constant lookup + modification and so on). But that
seems to be unpopular, AFAICT...
Wouldn`t that be possible to specify which internal string encoding is
used by
The Chicken wiki still has an index of Chicken 3 eggs, although I do think
chicken-setup is no longer operational.
Perhaps now would be a good time to clean the wiki of vestigial references
to 2 & 3.
I also like the idea of adopting the r7rs library names.
-Ivan
On Wed, Aug 20, 2014 at 1:13 A
Felix Winkelmann scripsit:
> It's also the only behaviour that makes sense, IMHO.
Well, I think doing parameters in Chicken style but with only immutable
parameters is also a reasonable choice. Currently, no Scheme I know of
makes that choice. You can always portably emulate multiple parameters
Felix Winkelmann scripsit:
> It is written:
I'm glad to see you are treating R7RS-small as scripture!
> "If an implementation supports multiple threads, then parameterize
> must not change the associated values of any parameters in any thread
> other than the current thread and threads created i
> The way parameters and threads work right now is perfect for CHICKEN,
> and there are various libraries that make use of this (most notably
> Spiffy, which relies on it heavily).
It's also the only behaviour that makes sense, IMHO.
felix
___
Chicken
> +1, but what's wrong with R7RS parameters? They are entirely compatible
> with Chicken parameters AFAICT; the ability to mutate a parameter isn't
> present in R7RS, but R7RS documents that the effect of (p x) where
> p is a parameter is implementation-defined.
It is written:
"If an implementat
From: Peter Bex
Subject: Re: [Chicken-hackers] CR #1142 and upcoming changes
Date: Tue, 19 Aug 2014 18:23:22 +0200
> On Tue, Aug 19, 2014 at 05:21:06PM +0200, Felix Winkelmann wrote:
>> Mostly cleaning up. Shrinking the core system will make maintenance
>> easier, and reduces the
> I didn't know we still supported CHICKEN 2 and 3. In what way is that
> done? AFAIK the server-side component for "chicken-setup" is no longer
> active. Is it?
I wouldn't know myself, to be honest.
felix
___
Chicken-hackers mailing list
Chicken-h
Peter Bex scripsit:
> It's unfortunate that R7RS mentioned threads here at all: it doesn't say
> anything about threads *anywhere* else, in the whole document. It
> should've left this undefined: threads are out of scope for the document.
There was a minority argument that parameters were easily
On Tue, Aug 19, 2014 at 01:19:35PM -0400, John Cowan wrote:
> Peter Bex scripsit:
>
> > Note that this does _not_ imply we should implement things that we
> > don't already have, just move the things we do have under the names
> > defined by R7RS. If we have something that's close to R7RS but not
Peter Bex scripsit:
> Note that this does _not_ imply we should implement things that we
> don't already have, just move the things we do have under the names
> defined by R7RS. If we have something that's close to R7RS but not
> identical, we may decide to tweak it to match R7RS. Except for
> R
On Tue, Aug 19, 2014 at 05:21:06PM +0200, Felix Winkelmann wrote:
> Mostly cleaning up. Shrinking the core system will make maintenance
> easier, and reduces the need to follow our usual patch-review process.
I fully agree that the patch review process would be untenable for
the kind of massive la
On Tue, Aug 19, 2014 at 05:21:06PM +0200, Felix Winkelmann wrote:
> > I would think that support for Chicken 2 & 3 should be dropped after a
> > Chicken 5 branch is made.
>
> Yes, that sounds reasonable.
I didn't know we still supported CHICKEN 2 and 3. In what way is that
done? AFAIK the serv
> To avoid doing this again soon, I think the other change you suggested
> should definitely be included: the reworking of internal libraries by
> splitting them up. Perhaps you already assumed this would be included,
> I don't think I have seen this mentioned yet so I wanted to put it out
> there
> I would think that support for Chicken 2 & 3 should be dropped after a
> Chicken 5 branch is made.
Yes, that sounds reasonable.
> I had also implicitly assumed that the modularisation changes would help
> bring full R7RS support to core.
I think it is R7RS support will be in an egg for the ti
On Tue, Aug 19, 2014 at 10:20:56AM +0200, Felix Winkelmann wrote:
> I understand your concerns, but doing all the planned changes piece by
> piece will be a massive maintenance effort and the compatibility hacks
> required to have something halfway working during the transition will
> be even more.
> In fact, as a user, I was just trying to bring some topics that are
> practical issues and that we could piggyback with the breaking changes
> to make a major release.
>
> I'm not sure reorganizing the core and making it smaller justifies a
> major release. I understand some changes caused by t
I would think that support for Chicken 2 & 3 should be dropped after a
Chicken 5 branch is made.
If anyone desperately needs Chicken 3, would it not be better to migrate
the Chicken 3 stuff to another server?
I had also implicitly assumed that the modularisation changes would help
bring full R7RS
John Cowan scripsit:
> It's only now with Python 3.4 (arguably 3.3) that parity with Python
> 2.7 was achieved. There is still no recommendation to convert working
> 2.7 applications (as opposed to libraries) and there may never be.
Here's a FAQ about the Python 2 to Python 3 transition, one of
Mario Domenech Goulart scripsit:
> I'm not sure reorganizing the core and making it smaller justifies a
> major release. I understand some changes caused by the core
> reorganization may break code, but I'm looking at major releases from a
> user standpoint. What immediate benefit do those chang
Hi Felix, Oleg and all,
On Mon, 18 Aug 2014 22:43:19 +0200 (CEST) Felix Winkelmann
wrote:
> From: Oleg Kolosov
> Subject: Re: [Chicken-hackers] CR #1142 and upcoming changes
> Date: Mon, 18 Aug 2014 23:08:23 +0400
>
>> On 08/18/14 20:41, Mario Domenech Goulart wrote:
>&
I do think it is time for an overhaul, and creating a new major version
branch is the right way to go about it.
Obviously it would take some time to port everything, but it seems that the
changes will be simpler than during the hygienic macros transition.
Ivan
On Aug 19, 2014 12:09 AM, "Peter
Felix Winkelmann scripsit:
> All eggs that use queues, mmap, binary-search and eviction will break.
> This is manageable, as salmonella will point them out to us, but I'd
> also like to eggify srfi-18, srfi-69, srfi-1/13/14 and perhaps srfi-4
> as well and all that (including the /really/ massive
From: Oleg Kolosov
Subject: Re: [Chicken-hackers] CR #1142 and upcoming changes
Date: Mon, 18 Aug 2014 23:08:23 +0400
> On 08/18/14 20:41, Mario Domenech Goulart wrote:
>> Hi Felix and all,
>>
>> On Mon, 18 Aug 2014 16:53:22 +0200 (CEST) Felix Winkelmann
>> wrote:
On 08/18/14 20:41, Mario Domenech Goulart wrote:
> Hi Felix and all,
>
> On Mon, 18 Aug 2014 16:53:22 +0200 (CEST) Felix Winkelmann
> wrote:
>
>> I'm not sure how to go on with the CR-related changes.
>>
>> I wonder whether it isn't better to postpone releasing these changes,
>> by creating de
Sadly, it seems that the last attempt at connecting a decent debugger to
Chicken has long since been abandoned:
http://wiki.call-cc.org/eggref/3/mayo
I, too, regularly end up hitting a wall with any decent sized application
that also relies on native compilation and interfacing with external
compo
On Mon, Aug 18, 2014 at 04:41:54PM +, Mario domenech Goulart wrote:
> Hi Felix and all,
>
> On Mon, 18 Aug 2014 16:53:22 +0200 (CEST) Felix Winkelmann
> wrote:
>
> > This is just a proposal. What do others think?
>
> Thanks for your message. This is all very exciting and I'm totally for
>
On Mon, Aug 18, 2014 at 06:54:48PM +0200, Peter Bex wrote:
> On Mon, Aug 18, 2014 at 10:00:46AM -0601, Alan Post wrote:
> > I used Chicken Scheme to bootstrap my company.
>
> That's really cool!
>
Thank you! It's the most successful Scheme program I've ever
written by a large margin. I was rec
On Mon, Aug 18, 2014 at 10:00:46AM -0601, Alan Post wrote:
> I used Chicken Scheme to bootstrap my company.
That's really cool!
> As of a few months ago, I am no longer running any scheme code, it
> has been ported to either C or Python.
What is/was the main reason you had to rewrite to Python?
Hi Felix and all,
On Mon, 18 Aug 2014 16:53:22 +0200 (CEST) Felix Winkelmann
wrote:
> I'm not sure how to go on with the CR-related changes.
>
> All eggs that use queues, mmap, binary-search and eviction will break.
> This is manageable, as salmonella will point them out to us, but I'd
> also
On Mon, Aug 18, 2014 at 05:06:54PM +0200, Peter Bex wrote:
> On Mon, Aug 18, 2014 at 04:53:22PM +0200, Felix Winkelmann wrote:
> > - I don't know how this is handled with henrietta - do we need a
> > separate CGI script running for this? It seems so, so the
> > core-branch will need to have dif
Peter Bex scripsit:
> I'd love to hear from some of the people using CHICKEN in their business
> or for other Serious Projects (Kristian? Ivan? Andy?) how painful this
> would be for them.
I would be pretty damned inconvenienced if the numbers egg were broken for
any substantial period of time, t
On Mon, Aug 18, 2014 at 04:53:22PM +0200, Felix Winkelmann wrote:
> - I don't know how this is handled with henrietta - do we need a
> separate CGI script running for this? It seems so, so the
> core-branch will need to have different download URLs in
> setup.defaults.
Perhaps, I'm not sure
Hello!
I'm not sure how to go on with the CR-related changes.
All eggs that use queues, mmap, binary-search and eviction will break.
This is manageable, as salmonella will point them out to us, but I'd
also like to eggify srfi-18, srfi-69, srfi-1/13/14 and perhaps srfi-4
as well and all that (i
46 matches
Mail list logo
