Re: [Chicken-hackers] CR #1142 and upcoming changes
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 come in point releases after that? These are all good questions, for which no answer can be given yet. I assume a 5 branch will be maintained in parallel, until it works well enough to start suggesting to users to switch. If possible, critical bug fixes should be done for both 4.9 and 5.x for as long as possible. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
Hi, On Tue, 19 Aug 2014 18:13:43 +0200 Peter Bex peter@xs4all.nl 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 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? chicken-setup for CHICKEN 2 and 3 should work, as eggs are available from call/cc.org. Eggs are not updated anymore, though. Best wishes. Mario -- http://parenteses.org/mario ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 core as a CHICKEN build-time option? For embedded systems with limited resources that will give a decent leverage to choose from - either consume more memory but more fast lookups etc (in the case of UCS-4) or consume less memory by the cost of UTF-8 conversions on the fly during string operations. -- Thanks, Yaroslav ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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... Wouldn`t that be possible to specify which internal string encoding is used by the core as a CHICKEN build-time option? For embedded systems with limited resources that will give a decent leverage to choose from - either consume more memory but more fast lookups etc (in the case of UCS-4) or consume less memory by the cost of UTF-8 conversions on the fly during string operations. I think it would be possible, but I dislike the idea because it is hard to maintain two separate compilation options like that. Cheers, Peter -- http://www.more-magic.net ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
From: Peter Bex peter@xs4all.nl 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 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 core as a CHICKEN build-time option? For embedded systems with limited resources that will give a decent leverage to choose from - either consume more memory but more fast lookups etc (in the case of UCS-4) or consume less memory by the cost of UTF-8 conversions on the fly during string operations. I think it would be possible, but I dislike the idea because it is hard to maintain two separate compilation options like that. 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 ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 forward port any of the remaining un-ported stuff. The code is still in SVN so it makes sense to keep the docs as well. The main issue is that this older stuff shows up in searches and confuses new users. Perhaps we should do something about that and more clearly mark the pages themselves as deprecated? Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 time to migrate from 4.7 - 4.9 and I expect that we will be happy with 4.9 for quite some time to come yet. As such, when we come to upgrade we would expect that it would be some work for us. 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. 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 come in point releases after that? Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 decide right now. UCS-2 is obsolete; it would need to be UTF-16 (i.e. support of surrogates). In any case, Alex's point about the FFI is strong. Even on Windows, UTF-8 is coming to be the dominant way to talk to C programs, and it's part of the spirit of Chicken (IIUC) that talking to C is clean and easy. On Posix systems, UTF-8 is massively dominant. Similarly, on the Web, UTF-8 encodes a huge majority of all Web pages. As of early 2012, UTF-8 (including pure ASCII) was at 80% (see http://googleblog.blogspot.com/2012/02/unicode-over-60-percent-of-web.html), and http://w3techs.com/technologies/overview/character_encoding/all shows it still rising. These figures aren't comparable, because Google is using its whole index and the *effective* encoding, whereas W3Techs is using only a large subset (10 million sites, usually only page per site) and the declared encoding (HTTP header, HTML meta, etc.) Still, both reports are loud and clear that UTF-8 is winning. Not having to transcode web pages most of the time is a win too. -- John Cowan http://www.ccil.org/~cowanco...@ccil.org Why are well-meaning Westerners so concerned that the opening of a Colonel Sanders in Beijing means the end of Chinese culture? [...] We have had Chinese restaurants in America for over a century, and it hasn't made us Chinese. On the contrary, we obliged the Chinese to invent chop suey.--Marshall Sahlins ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 the core reorganization may break code, but I'm looking at major releases from a user standpoint. What immediate benefit do those changes bring for users? Maybe R7RS support? Are those changes worth the breakage? Please, note that I'm not against those changes. Not at all, absolutely. I'm totally for them. I just wonder if they justify a major release and and all the burden to maintain another major version. I mentioned Unicode and bignums because, in my opinion, they are quite important for practical applications, and the support CHICKEN provides for them at the moment is not very appealing. Since you mentioned a new major release, why not making them part of it? Of course the obvious, realistic and straight-to-the-point answers are lack of manpower and lack of consensus on those topics, I know. 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. I also hate forcing users into upgrading - I always detested this in other software and would like to spare those that need a working system, for whatever reason. I also don't see a reason _not_ to consider adding the features you talk about, but it shouldn't be the main driving force. If we can provide support for this, fine! But someone has to implement it (of course) So I think: let's just see how well we get along. We should definitely look into what would be required for bignum/unicode support, if someone is willing to evaluate this. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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. I also hate forcing users into upgrading - I always detested this in other software and would like to spare those that need a working system, for whatever reason. 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 also don't see a reason _not_ to consider adding the features you talk about, but it shouldn't be the main driving force. If we can provide support for this, fine! But someone has to implement it (of course) So I think: let's just see how well we get along. We should definitely look into what would be required for bignum/unicode support, if someone is willing to evaluate this. No problem @ bignums. I don't know much about unicode, so that should probably be looked at by someone else. A simple thing we could include would be to reject all strings that have invalid UTF-8 encoding, like Postgres does that. I always really appreciated this feature of Postgres: it ensures that you don't get invalid data in your system, and prevents pollution and getting in character set hell, like happens all the time in MySQL: https://www.bluebox.net/insight/blog-article/getting-out-of-mysql-character-set-hell Adding rejection of non-UTF-8 strings would make the transition to a full Unicode system less painful (and perhaps make it possible to do it in a non-breaking way). I'm not sure how difficult this would be, though: all string mutation procedures should have a check that they won't create invalid strings by setting characters (bytes). Cheers, Peter -- http://www.more-magic.net ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 time being. Once we figure out the remaining issues, this should be usable in a rather seamless way. Is this not the case? What are the goals for a Chicken 5 release? Mostly cleaning up. Shrinking the core system will make maintenance easier, and reduces the need to follow our usual patch-review process. It also allows to use alternatives to cast-in-concrete APIs (like srfi-18) in an easier way. A smaller core system makes it also easier to use it on embedded systems, in particular on systems that don't need loads of external libraries. Restructuring the libraries is required to make things easier for users, especially newcomers. The current library structure is mostly arbitrary. This is not a problem for long-time users, but where what procedure can be found is currently very unintuitive - one just has to know about it, or use tools like chicken-doc all the time. Finally, using more modules in core catches many errors related to wrong naming, or unintended cross-references between library units. Oh, and should we ever want to have a fully transparent import that always does The Right Thing, then a cleaned up and more modularized core will be essential to that. We really need to address the cruft that has accumulated over more than a decade... felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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. Yes, that was implied. No problem @ bignums. I don't know much about unicode, so that should probably be looked at by someone else. A simple thing we could include would be to reject all strings that have invalid UTF-8 encoding, like Postgres does that. I always really appreciated this feature of Postgres: it ensures that you don't get invalid data in your system, and prevents pollution and getting in character set hell, like happens all the time in MySQL: https://www.bluebox.net/insight/blog-article/getting-out-of-mysql-character-set-hell Adding rejection of non-UTF-8 strings would make the transition to a full Unicode system less painful (and perhaps make it possible to do it in a non-breaking way). I'm not sure how difficult this would be, though: all string mutation procedures should have a check that they won't create invalid strings by setting characters (bytes). 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... felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 server-side component for chicken-setup is no longer active. Is it? 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 time being. Once we figure out the remaining issues, this should be usable in a rather seamless way. Works for me. I do think, however, that we should take a good look at the r7rs library names, and probably adopt them wholesale, for the parts that we implement. This would make CHICKEN easier to use for people using multiple Schemes, and for newbies coming from other Schemes. It would also ease our burden at figuring out good names: half of the stuff will suddenly *have* a good name. 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 R7RS-style parameters ;) Finally, using more modules in core catches many errors related to wrong naming, or unintended cross-references between library units. Oh, and should we ever want to have a fully transparent import that always does The Right Thing, then a cleaned up and more modularized core will be essential to that. We really need to address the cruft that has accumulated over more than a decade... proper cleanups are very dangerous. However, if done right, they can make life better. Cheers, Peter -- http://www.more-magic.net ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 large-scale overhaul we're planning on, but I also am a little afraid we'll lose the benefits it brings. I liked the fact that we spread knowledge through the patch review process: I really think we have started to make some progress towards getting more people up to speed about various parts of core. At least, I know more about the GC and the expander, and Evan knows more about the scrutinizer. If we completely change everything without going through the list that means we might get lots of new bugs (which we will anyway, I don't make any illusions about that, but it will be less bad if we have someone review the stuff), and nobody but the person who wrote the code will know how it works. Finally, by reviewing, we'll get useful feedback on alternative approaches to a particular problem (and typical bikesheds, of course. But in this process, we have the freedom to ignore anyone who doesn't submit patches). Cheers, Peter -- http://www.more-magic.net ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 R7RS-style parameters ;) +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. The reason WG1 did that is so as not to have to worry about whether mutation in a parent thread, either before or after a child thread is created or started, affects the parameter value in the child, and per contra whether mutation in the child affects the parent. Different Schemes behave differently in these respects, as SRFI 39 documents. In Chicken, child threads capture the current value in the parent when they are created, and after that the parameters in the threads are independent. Leaving mutation explicitly implementation-dependent avoids having to resolve this issue in portable code. proper cleanups are very dangerous. However, if done right, they can make life better. Emphatic +1. -- John Cowan http://www.ccil.org/~cowanco...@ccil.org And they pack their lyrics till they're so damn dense You could put 'em in your yard and you could use 'em for a fence. --Alan Chapman, Everybody Wants to Be Sondheim ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 identical, we may decide to tweak it to match R7RS. Except for R7RS-style parameters ;) +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. As I understood Felix's comments at the time, R7RS parameterize behaves differently with threads. However, after re-reading the relevant section it appears that CHICKEN's parameterize is indeed perfectly compatible with R7RS. Maybe Felix can explain the nuances I missed again. 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. In Chicken, child threads capture the current value in the parent when they are created, and after that the parameters in the threads are independent. Leaving mutation explicitly implementation-dependent avoids having to resolve this issue in portable code. 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). Cheers, Peter -- http://www.more-magic.net ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
From: Peter Bex peter@xs4all.nl 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 need to follow our usual patch-review process. I fully agree that the patch review process would be untenable for the kind of massive large-scale overhaul we're planning on, but I also am a little afraid we'll lose the benefits it brings. I'm not saying the changes for CHICKEN-5 should not be reviewed - I was talking about stuff that will be removed from the code (the/some srfi units, for example). Everything happening to the core system still needs the review process. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 inside body. It's the last part that I got wrong: I incorrectly assumed it may _not_ influence the values in threads created inside body. That assumption was incorrect, yes. `Parameterize` obviously affects parameter values in the current thread (or it would be useless), and may affect values in child threads created within the body. We don't spell out that it must not do so after the thread is created: exceptions are hard enough without exceptions to exceptions. -- John Cowan http://www.ccil.org/~cowanco...@ccil.org But the next day there came no dawn, and the Grey Company passed on into the darkness of the Storm of Mordor and were lost to mortal sight; but the Dead followed them. --The Passing of the Grey Company ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 by parameterizing a mutable box, if you don't care about threads. -- John Cowan http://www.ccil.org/~cowanco...@ccil.org If I have seen farther than others, it is because I was standing on the shoulders of giants. --Isaac Newton ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 AM, Peter Bex peter@xs4all.nl wrote: 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? Works for me. I do think, however, that we should take a good look at the r7rs library names, and probably adopt them wholesale, for the parts that we implement. This would make CHICKEN easier to use for people using multiple Schemes, and for newbies coming from other Schemes. It would also ease our burden at figuring out good names: half of the stuff will suddenly *have* a good name. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 about that. The release-info files don't have a way to indicate CHICKEN version either. This needs some extra attention, so that repositories can support multiple CHICKEN versions. All this is mainly to safe time - keeping up backward-compatibility hacks (wrapper-eggs, hacks in setup.defaults, etc.) just needs more work and time and we haven't much of that, considering that we are just a handful of part-time maintainers. 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, but it does require updating all the eggs. And of course there's shitloads of eggs that are unmaintained, which will break and never get fixed. So all in all, starting over might be easiest. 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. Cheers, Peter -- http://www.more-magic.net ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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, though I have the utmost confidence in the mission otherwise. Then again, I figure you'll continue to maintain it. -- John Cowan http://www.ccil.org/~cowanco...@ccil.org The exception proves the rule. Dimbulbs think: Your counterexample proves my theory. Latin students think 'Probat' means 'tests': the exception puts the rule to the proof. But legal historians know it means Evidence for an exception is evidence of the existence of a rule in cases not excepted from. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
Hi Felix and all, On Mon, 18 Aug 2014 16:53:22 +0200 (CEST) Felix Winkelmann felix.winkelm...@bevuta.com 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 like to eggify srfi-18, srfi-69, srfi-1/13/14 and perhaps srfi-4 as well and all that (including the /really/ massive changes related to core unit restructuring) will require us constantly running after broken eggs. The compiler-patch by Peter will add some more breakage. I wonder whether it isn't better to postpone releasing these changes, by creating development branches and switch in one step to CHICKEN 5, which would have a number of advantages over doing all that in a piecewise fashion: - There is no need to keep around deprecated APIs, confusing both users and tools (e.g. chicken-doc, which would have to list multiple variants of the same APIs, both in core (deprecated) and in eggs. - Any one change will break stuff; starting from a clean slate (sort of) with a new major release of CHICKEN would allow users a choice of whether to make a transition or keep working with CHICKEN 4. Specifically, anybody having production code will not like being forced to upgrade perfectly running code. It's clear that phasing out CHICKEN 4 does have it's disadvantages (keeping up with security fixes and critical bugs and so on), but since the changes planned are quite pervasive, backporting will be painful in any case, regardless of how we go on. So I would propose to do the following: - Starting with Peter's compiler-modularization, use a new branch in the core-repository (chicken-5). Drop all core support for the eggs in CR #1142, without going through a deprecation phase. - Branch off the egg-repo into a 5 branch. I know that this will not catch problems with eggs outside of the svn repository, but it's a start. Here we can add the eggs related to CR #1142, of course. - Setup a salmonalla instance for these new branches. - 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. All this is mainly to safe time - keeping up backward-compatibility hacks (wrapper-eggs, hacks in setup.defaults, etc.) just needs more work and time and we haven't much of that, considering that we are just a handful of part-time maintainers. Further steps will be creating a core unit for srfi-1/13/14 stuff that's needed there, extracting srfi-18/69/(4), restructuring the core units, and r7rs-compatibility work. This is just a proposal. What do others think? Thanks for your message. This is all very exciting and I'm totally for shrinking the core. Not related with removing units from the core, but since we are talking about CHICKEN 5, shouldn't we consider discussing some polemic topics like the support for Unicode and bignums in core? Those are limitations that recently lead to some ugly hacks (some examples in [1]) and bugs (e.g., [2]). [1] http://lists.gnu.org/archive/html/chicken-users/2014-07/msg00017.html [2] http://bugs.call-cc.org/ticket/1139 Best wishes. Mario -- http://parenteses.org/mario ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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? C I can understand, for performance reasons. I am still maintaining my eggs, and will be happy to do so through this transition--one problem I ran in to prototyping, which frankly surprised me--was hitting code- infrastructure-related scalability limitations in Chicken. I'm happy see the effort above as a result. It would be nice if you could elaborate on the exact things you ran into, so that we may try and fix them. Cheers, Peter -- http://www.more-magic.net ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 recently trying to find a single routine that best expressed what a bootstrap in Chicken does, exactly, and I settled on this as a good balance of expressiveness without requiring too much context: (define (alist-argv l) (define (fn k v) `(,(string-append -- (symbol-string k)) ,v)) (flatten1 (map-alist fn l))) This routine was where I took any of a number of highly experimental data structures and passed them to programs which had well-defined interfaces, converting an experiment to infrastructure, if you will. One end could change to whatever it needed to be, the other end was where I could put solved problem, and this interface let me see how far apart those two components had gotten. I know that's not much too look at for this list--I wanted an example I could give to people who are afraid of Scheme. 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? C I can understand, for performance reasons. When we started, it was not clear how much of the codebase would be in C vs. Python. I was using Chicken to as a high-level language that I could compile to C (that was a hard requirement, we needed our application to run as a shebang line). As we developed the application it became clear that nearly all of it could be written in Python, and the pieces that could not were natural to express in C, so the need for the abstraction provided by Chicken went away. You may be happy (or disgusted!) to know that the engine I wrote in Scheme had been implemented, quite naturally, as a series of promises. Depending on the user input, it calculated any needed dependencies on the fly to produce a correctly ordered result. In Python, to get the same result, this engine became a four-pass compiler. It's certainly easier to see the structure of the thing, but I needed the flexibility provided by Scheme to see the solution, and the feedback I got here on the user interface for genturfa'i (my PEG compiler) was why the hell did you write a multi-pass compiler in Scheme?!) A side benefit I hope to captalize on later is that my logging infrastructure is based on association lists. I did that because I wanted to future-proof my logs for the time when I need to go back to them and profile the system, but it also provided an upgrade path from the Scheme code to Python. I am still maintaining my eggs, and will be happy to do so through this transition--one problem I ran in to prototyping, which frankly surprised me--was hitting code- infrastructure-related scalability limitations in Chicken. I'm happy see the effort above as a result. It would be nice if you could elaborate on the exact things you ran into, so that we may try and fix them. Hands down the largest difficulty I had with Scheme was debugging. You gave me a hint some time ago that adding type declarations to my code would have made my job easier. I haven't had a chance to explore that, I'm sorry to report. But my specific pain: I got to the point where I needed to debug a compiled application, that was my deployment model. In that I could not produce results when I ran the code interpreted. I put together what tools I could for capturing and managing exceptions, so I could get traces and debug output, but I often found myself pouring over a couple thousand lines of trace trying to find the relevant section of code that crashed. The tools I had to write to make this visible in the first place were the first ~hundreds of lines, and if I had an invocation to genturfa'i (le PEG parser), I had to look at that enormous, entirely machine generated, trace. Thematically, Chicken let abstract my problem away to an amazing degree--I would write two pieces of code, realize they were similar, and merge them together. I had a lot of sweet spots like this where I kept seeing a new pattern, parameterizing it, and finding novel uses I hadn't anticipated. Much as Chicken let me do this, my ability to debug problems became substantially constrained. I found that the further I got away from core the harder it was to connect the location of a failure to the part of the code that needed to change. My lack of ability to debug was the significant technical driver that limited what I could do in Scheme. By way of an unfair contrast, I'm able in Python to run a collection of jobs, collect any failures, and jump around to each of the stack traces and do a post-mortem debug. I can safely attach information as any exception heads up the stack but still debug at the original failure point. If I, personally, were going to work on one
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 felix.winkelm...@bevuta.com wrote: This is just a proposal. What do others think? Thanks for your message. This is all very exciting and I'm totally for shrinking the core. Not related with removing units from the core, but since we are talking about CHICKEN 5, shouldn't we consider discussing some polemic topics like the support for Unicode and bignums in core? Those are limitations that recently lead to some ugly hacks (some examples in [1]) and bugs (e.g., [2]). [1] http://lists.gnu.org/archive/html/chicken-users/2014-07/msg00017.html [2] http://bugs.call-cc.org/ticket/1139 Yes please. The current way we're doing this is needlessly complex. I don't think I'll ever have as much fun writing parsers as I did when I could use ASCII character tables, but the one remaining use case I have for solving problems in ASCII is preventing a terminal snow crash when dumping core--the program is already on it's way out and can solve encoding problems mañana. That use case hardly justifies the work it takes to get Chicken to be a first class citizen. I would generally vote we take the most frequenly used eggs and integrate them in to core, but as I fully appreciate the argument against doing so I sure would like to ask instead for utf-8 and numbers. Thank you, -a -- analytics in physical space: http://venueview.co/ my personal website: http://c0redump.org/ ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 components due to the lack of visual source-level debugging. At some point it becomes incredibly cumbersome to wade through stacks of generated C code; and it seems like it would be reasonable to expect to be able to debug Chicken applications without becoming somewhat of an expert in how chicken operates at a low-level. By way of example, there's more often than not no need to understand how V8 works in order to have source-level debugging of Javascript. OTOH, the trace egg is oh-so-close; I've considered integrating support with it into Emacs, so as to have visual source-level debugging. http://wiki.call-cc.org/eggref/4/trace -Dan On Mon, Aug 18, 2014 at 11:13 AM, Alan Post alanp...@sunflowerriver.org wrote: 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 recently trying to find a single routine that best expressed what a bootstrap in Chicken does, exactly, and I settled on this as a good balance of expressiveness without requiring too much context: (define (alist-argv l) (define (fn k v) `(,(string-append -- (symbol-string k)) ,v)) (flatten1 (map-alist fn l))) This routine was where I took any of a number of highly experimental data structures and passed them to programs which had well-defined interfaces, converting an experiment to infrastructure, if you will. One end could change to whatever it needed to be, the other end was where I could put solved problem, and this interface let me see how far apart those two components had gotten. I know that's not much too look at for this list--I wanted an example I could give to people who are afraid of Scheme. 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? C I can understand, for performance reasons. When we started, it was not clear how much of the codebase would be in C vs. Python. I was using Chicken to as a high-level language that I could compile to C (that was a hard requirement, we needed our application to run as a shebang line). As we developed the application it became clear that nearly all of it could be written in Python, and the pieces that could not were natural to express in C, so the need for the abstraction provided by Chicken went away. You may be happy (or disgusted!) to know that the engine I wrote in Scheme had been implemented, quite naturally, as a series of promises. Depending on the user input, it calculated any needed dependencies on the fly to produce a correctly ordered result. In Python, to get the same result, this engine became a four-pass compiler. It's certainly easier to see the structure of the thing, but I needed the flexibility provided by Scheme to see the solution, and the feedback I got here on the user interface for genturfa'i (my PEG compiler) was why the hell did you write a multi-pass compiler in Scheme?!) A side benefit I hope to captalize on later is that my logging infrastructure is based on association lists. I did that because I wanted to future-proof my logs for the time when I need to go back to them and profile the system, but it also provided an upgrade path from the Scheme code to Python. I am still maintaining my eggs, and will be happy to do so through this transition--one problem I ran in to prototyping, which frankly surprised me--was hitting code- infrastructure-related scalability limitations in Chicken. I'm happy see the effort above as a result. It would be nice if you could elaborate on the exact things you ran into, so that we may try and fix them. Hands down the largest difficulty I had with Scheme was debugging. You gave me a hint some time ago that adding type declarations to my code would have made my job easier. I haven't had a chance to explore that, I'm sorry to report. But my specific pain: I got to the point where I needed to debug a compiled application, that was my deployment model. In that I could not produce results when I ran the code interpreted. I put together what tools I could for capturing and managing exceptions, so I could get traces and debug output, but I often found myself pouring over a couple thousand lines of trace trying to find the relevant section of code that crashed. The tools I had to write to make this visible in the first place were the first ~hundreds of lines, and if I had an invocation
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 felix.winkelm...@bevuta.com 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 development branches and switch in one step to CHICKEN 5, which would have a number of advantages over doing all that in a piecewise fashion: Not related with removing units from the core, but since we are talking about CHICKEN 5, shouldn't we consider discussing some polemic topics like the support for Unicode and bignums in core? Those are limitations that recently lead to some ugly hacks (some examples in [1]) and bugs (e.g., [2]). Or we can declare that CHICKEN 5 != 5.0 and go on with the breakage. I'm concerned that trying to fit everything into 5.0 will never finish - there could be lengthy discussions about proposed features and no action. Personally, I think that modularizing the core is of utmost importance now, fixing eggs and adding features could be postponed to some later point releases. -- Regards, Oleg ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
From: Oleg Kolosov bazur...@gmail.com 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 felix.winkelm...@bevuta.com 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 development branches and switch in one step to CHICKEN 5, which would have a number of advantages over doing all that in a piecewise fashion: Not related with removing units from the core, but since we are talking about CHICKEN 5, shouldn't we consider discussing some polemic topics like the support for Unicode and bignums in core? Those are limitations that recently lead to some ugly hacks (some examples in [1]) and bugs (e.g., [2]). Or we can declare that CHICKEN 5 != 5.0 and go on with the breakage. I'm concerned that trying to fit everything into 5.0 will never finish - there could be lengthy discussions about proposed features and no action. Personally, I think that modularizing the core is of utmost importance now, fixing eggs and adding features could be postponed to some later point releases. Very true - I fully agree with that. I think we have enough of core support for R7RS right now and the general direction is to remove stuff (i.e. move to eggs) instead of adding anything. We also should postpone further clean ups to a later point. Adding bignums + utf8 will also be much easier with a smaller and and restructured core system, of course. (this all assumes we don't go mad while ripping everything apart...) felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 changes related to core unit restructuring) will require us constantly running after broken eggs. A couple of simple things come to mind. 1) Deprecate all mechanisms for creating units. Provide a compiler switch used when building Chicken to shut off this warning. 2) Deprecate all mechanisms for loading units except `use` (and presumably `require-extension`, which is equivalent to it). `Use` is safe because it will load either a unit or a module without problem. (Which eggs, if any, are not modules at this point?) 3) Set up the meta language so that if it attempts to require an egg that is present as a unit, it just uses the unit. I wonder whether it isn't better to postpone releasing these changes, by creating development branches and switch in one step to CHICKEN 5, which would have a number of advantages over doing all that in a piecewise fashion: I'm agnostic about this. There will be a lot of eggs that will have to be maintained in two versions, no matter what. I think we should continue to think about ways to ameliorate that. -- John Cowan http://www.ccil.org/~cowanco...@ccil.org In computer science, we stand on each other's feet. --Brian K. Reid ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 Bex peter@xs4all.nl 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 different download URLs in setup.defaults. Perhaps, I'm not sure about that. The release-info files don't have a way to indicate CHICKEN version either. This needs some extra attention, so that repositories can support multiple CHICKEN versions. All this is mainly to safe time - keeping up backward-compatibility hacks (wrapper-eggs, hacks in setup.defaults, etc.) just needs more work and time and we haven't much of that, considering that we are just a handful of part-time maintainers. 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, but it does require updating all the eggs. And of course there's shitloads of eggs that are unmaintained, which will break and never get fixed. So all in all, starting over might be easiest. 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. Cheers, Peter -- http://www.more-magic.net ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
Hi Felix, Oleg and all, On Mon, 18 Aug 2014 22:43:19 +0200 (CEST) Felix Winkelmann felix.winkelm...@bevuta.com wrote: From: Oleg Kolosov bazur...@gmail.com 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: On Mon, 18 Aug 2014 16:53:22 +0200 (CEST) Felix Winkelmann felix.winkelm...@bevuta.com 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 development branches and switch in one step to CHICKEN 5, which would have a number of advantages over doing all that in a piecewise fashion: Not related with removing units from the core, but since we are talking about CHICKEN 5, shouldn't we consider discussing some polemic topics like the support for Unicode and bignums in core? Those are limitations that recently lead to some ugly hacks (some examples in [1]) and bugs (e.g., [2]). Or we can declare that CHICKEN 5 != 5.0 and go on with the breakage. I'm concerned that trying to fit everything into 5.0 will never finish - there could be lengthy discussions about proposed features and no action. Personally, I think that modularizing the core is of utmost importance now, fixing eggs and adding features could be postponed to some later point releases. Very true - I fully agree with that. I think we have enough of core support for R7RS right now and the general direction is to remove stuff (i.e. move to eggs) instead of adding anything. We also should postpone further clean ups to a later point. Adding bignums + utf8 will also be much easier with a smaller and and restructured core system, of course. (this all assumes we don't go mad while ripping everything apart...) Sorry for the sudden jump to those topics. :-) 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 the core reorganization may break code, but I'm looking at major releases from a user standpoint. What immediate benefit do those changes bring for users? Maybe R7RS support? Are those changes worth the breakage? Please, note that I'm not against those changes. Not at all, absolutely. I'm totally for them. I just wonder if they justify a major release and and all the burden to maintain another major version. I mentioned Unicode and bignums because, in my opinion, they are quite important for practical applications, and the support CHICKEN provides for them at the moment is not very appealing. Since you mentioned a new major release, why not making them part of it? Of course the obvious, realistic and straight-to-the-point answers are lack of manpower and lack of consensus on those topics, I know. Best wishes. Mario -- http://parenteses.org/mario ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 changes bring for users? A new major release doesn't necessarily have to bring immediate benefit. 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. If breaking backward compatibility (the purpose of a major release) provides a better platform for future innovation, that's enough justification in general; whether that is true in this case, I don't know. R7RS support [...] Unicode and bignums Those are the obvious candidates for core extensions. -- John Cowan http://www.ccil.org/~cowanco...@ccil.org Here lies the Christian, judge, and poet Peter, Who broke the laws of God and man and metre. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 the main foci of which was cleaning up the string model. I recommend the first three sections, down to the What actually changed in the text model heading. http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html -- John Cowan http://www.ccil.org/~cowanco...@ccil.org Does anybody want any flotsam? / I've gotsam. Does anybody want any jetsam? / I can getsam. --Ogden Nash, No Doctors Today, Thank You ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] CR #1142 and upcoming changes
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 support to core. Is this not the case? What are the goals for a Chicken 5 release? On Tue, Aug 19, 2014 at 9:03 AM, Mario Domenech Goulart mario.goul...@gmail.com wrote: Sorry for the sudden jump to those topics. :-) 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 the core reorganization may break code, but I'm looking at major releases from a user standpoint. What immediate benefit do those changes bring for users? Maybe R7RS support? Are those changes worth the breakage? Please, note that I'm not against those changes. Not at all, absolutely. I'm totally for them. I just wonder if they justify a major release and and all the burden to maintain another major version. I mentioned Unicode and bignums because, in my opinion, they are quite important for practical applications, and the support CHICKEN provides for them at the moment is not very appealing. Since you mentioned a new major release, why not making them part of it? Of course the obvious, realistic and straight-to-the-point answers are lack of manpower and lack of consensus on those topics, I know. ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
