Re: [Chicken-hackers] [MEGA-PATCH] Modularise the compiler!
From: Peter Bex peter@xs4all.nl Subject: Re: [Chicken-hackers] [MEGA-PATCH] Modularise the compiler! Date: Sun, 17 Aug 2014 23:28:49 +0200 On Sun, Aug 17, 2014 at 11:25:00PM +0200, Felix Winkelmann wrote: If y'all prefer, I could push my branch to call-cc, if that makes it easier to work on this. I realise that sending 19 patches back and forth over the mailing list will be very painful :) Oh, gosh... yes, please create a branch for this. Done! It's called compiler-modules. Thanks, I'd like to study this a little before we take any moves, ok? felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [MEGA-PATCH] Modularise the compiler!
On Mon, Aug 18, 2014 at 02:30:09PM +0200, Felix Winkelmann wrote: From: Peter Bex peter@xs4all.nl Subject: Re: [Chicken-hackers] [MEGA-PATCH] Modularise the compiler! Date: Sun, 17 Aug 2014 23:28:49 +0200 On Sun, Aug 17, 2014 at 11:25:00PM +0200, Felix Winkelmann wrote: If y'all prefer, I could push my branch to call-cc, if that makes it easier to work on this. I realise that sending 19 patches back and forth over the mailing list will be very painful :) Oh, gosh... yes, please create a branch for this. Done! It's called compiler-modules. Thanks, I'd like to study this a little before we take any moves, ok? Feel free to do so. I'm not too happy about a few things (notably the breakage of existing eggs), so I'm not eager to push this early. I submitted it mostly for discussion. 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: remove queues, mmap, evict and binary search from core libraries
Hello! CR #1142 has been accepted. A follow-up mail will propose the further steps to be taken. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
[Chicken-hackers] [PATCH] Fix rename-file behavior on Windows when destination exists
Hi, (rename-file x y) fails on Windows if y already exists. I think it would be better to have the same behavior as Unix (i.e. overwrite). The attached patch does that. Regards, Michele From 57098c32ce1b02834b972924c85690653b2d4fb3 Mon Sep 17 00:00:00 2001 From: Michele La Monaca mikele.chic...@lamonaca.net Date: Mon, 18 Aug 2014 16:19:44 +0200 Subject: [PATCH] Fix rename-file behavior on Windows when destination exists --- chicken.h | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/chicken.h b/chicken.h index fc40303..0624e22 100644 --- a/chicken.h +++ b/chicken.h @@ -1309,7 +1309,12 @@ extern double trunc(double); #define C_string_compare(to, from, n) C_fix(C_memcmp(C_c_string(to), C_c_string(from), C_unfix(n))) #define C_string_compare_case_insensitive(from, to, n) \ C_fix(C_memcasecmp(C_c_string(from), C_c_string(to), C_unfix(n))) -#define C_rename_file(old, new) C_fix(rename(C_c_string(old), C_c_string(new))) +#if defined(_WIN32) || defined(_WIN64) +# include windows.h +# define C_rename_file(old, new)C_fix(0 == MoveFileEx(C_c_string(old), C_c_string(new), MOVEFILE_REPLACE_EXISTING) ? -1 : 0) +#else +# define C_rename_file(old, new)C_fix(rename(C_c_string(old), C_c_string(new))) +#endif #define C_delete_file(fname)C_fix(remove(C_c_string(fname))) #define C_poke_double(b, i, n) (((double *)C_data_pointer(b))[ C_unfix(i) ] = C_c_double(n), C_SCHEME_UNDEFINED) #define C_poke_c_string(b, i, from, s) (C_strlcpy((char *)C_block_item(b, C_unfix(i)), C_data_pointer(from), s), C_SCHEME_UNDEFINED) -- 1.8.4.3 ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Fix rename-file behavior on Windows when destination exists
Michele La Monaca scripsit: (rename-file x y) fails on Windows if y already exists. I think it would be better to have the same behavior as Unix (i.e. overwrite). The attached patch does that. +1 -- John Cowan http://www.ccil.org/~cowanco...@ccil.org The internet is a web of tiny tyrannies giving an illusion of anarchy. --David Rush ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
[Chicken-hackers] CR #1142 and upcoming changes
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 (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? 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 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] [PATCH] Fix rename-file behavior on Windows when destination exists
Mario Domenech Goulart scripsit: Shouldn't we check !defined(__CYGWIN__) here? It can't hurt, but since 2012 Cygwin no longer defines _WIN32. -- John Cowan http://www.ccil.org/~cowanco...@ccil.org The whole of Gaul is quartered into three halves. --Julius Caesar ___ 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
