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] [PATCH 2/2] Invert poll(2) flag default
HI Peter, Peter Bex peter@xs4all.nl writes: This seems like a good idea. However, could you also swap the two code blocks? A double negation (#ifndef NO_...) can be confusing, and by making it read #ifdef NO_POSIX_POLL (I'd probably drop the HAVE_ prefix, as that's more idiomatic AFAICT), it becomes a little clearer. you are right--my intention was to make the patch as non-invasive as possible so its purpose is obvious. Now that the purpose should be clear, find attached an updated version which swaps the code blocks to avoid the double negation. I also dropped the HAVE_ prefix as per your suggestion, I didn't see the other flags names like that. Thanks for the hint! Moritz From 27097791ee5de99d52d513858b10d4e43ce0e33b Mon Sep 17 00:00:00 2001 From: Moritz Heidkamp moritz.heidk...@bevuta.com Date: Mon, 4 Aug 2014 15:23:13 +0200 Subject: [PATCH] Invert poll(2) flag default To be on the safe side we now assume that poll(2) is available by default and define the NO_POSIX_POLL flag in case it isn't available on a platform. --- Makefile.aix | 1 - Makefile.android | 1 - Makefile.bsd | 1 - Makefile.cross-linux-mingw | 1 + Makefile.cygwin| 1 - Makefile.haiku | 1 - Makefile.hurd | 1 - Makefile.ios | 1 - Makefile.linux | 1 - Makefile.macosx| 1 - Makefile.mingw | 1 + Makefile.mingw-msys| 1 + Makefile.solaris | 1 - runtime.c | 14 ++-- scheduler.scm | 54 +++--- 15 files changed, 37 insertions(+), 44 deletions(-) diff --git a/Makefile.aix b/Makefile.aix index 68b33b7..72e9715 100644 --- a/Makefile.aix +++ b/Makefile.aix @@ -74,7 +74,6 @@ chicken-config.h: chicken-defaults.h echo #define HAVE_LONG_LONG 1 $@ echo #define HAVE_MEMMOVE 1 $@ echo #define HAVE_MEMORY_H 1 $@ - echo #define HAVE_POSIX_POLL 1 $@ echo #define HAVE_SIGACTION 1 $@ echo #define HAVE_SIGSETJMP 1 $@ echo #define HAVE_STDINT_H 1 $@ diff --git a/Makefile.android b/Makefile.android index ac72ee8..819587f 100644 --- a/Makefile.android +++ b/Makefile.android @@ -69,7 +69,6 @@ chicken-config.h: chicken-defaults.h echo #define HAVE_LONG_LONG 1 $@ echo #define HAVE_MEMMOVE 1 $@ echo #define HAVE_MEMORY_H 1 $@ - echo #define HAVE_POSIX_POLL 1 $@ echo #define HAVE_SIGACTION 1 $@ echo #define HAVE_SIGSETJMP 1 $@ echo #define HAVE_STDINT_H 1 $@ diff --git a/Makefile.bsd b/Makefile.bsd index af28814..c69ea35 100644 --- a/Makefile.bsd +++ b/Makefile.bsd @@ -72,7 +72,6 @@ chicken-config.h: chicken-defaults.h echo #define HAVE_LONG_LONG 1 $@ echo #define HAVE_MEMMOVE 1 $@ echo #define HAVE_MEMORY_H 1 $@ - echo #define HAVE_POSIX_POLL 1 $@ echo #define HAVE_SIGACTION 1 $@ echo #define HAVE_SIGSETJMP 1 $@ echo #define HAVE_SIGPROCMASK 1 $@ diff --git a/Makefile.cross-linux-mingw b/Makefile.cross-linux-mingw index 32a6f2f..6e4c34a 100644 --- a/Makefile.cross-linux-mingw +++ b/Makefile.cross-linux-mingw @@ -95,6 +95,7 @@ chicken-config.h: chicken-defaults.h echo #define HAVE_LONG_LONG 1 $@ echo #define HAVE_MEMMOVE 1 $@ echo #define HAVE_MEMORY_H 1 $@ + echo #define NO_POSIX_POLL 1 $@ echo #define HAVE_STDINT_H 1 $@ echo #define HAVE_STDLIB_H 1 $@ echo #define HAVE_STRERROR 1 $@ diff --git a/Makefile.cygwin b/Makefile.cygwin index 376f6b8..f499c90 100644 --- a/Makefile.cygwin +++ b/Makefile.cygwin @@ -89,7 +89,6 @@ chicken-config.h: chicken-defaults.h echo #define HAVE_LONG_LONG 1 $@ echo #define HAVE_MEMMOVE 1 $@ echo #define HAVE_MEMORY_H 1 $@ - echo #define HAVE_POSIX_POLL 1 $@ echo #define HAVE_SIGACTION 1 $@ echo #define HAVE_STDINT_H 1 $@ echo #define HAVE_STDLIB_H 1 $@ diff --git a/Makefile.haiku b/Makefile.haiku index a1f5841..7eeec26 100644 --- a/Makefile.haiku +++ b/Makefile.haiku @@ -66,7 +66,6 @@ chicken-config.h: chicken-defaults.h echo #define HAVE_LONG_LONG 1 $@ echo #define HAVE_MEMMOVE 1 $@ echo #define HAVE_MEMORY_H 1 $@ - echo #define HAVE_POSIX_POLL 1 $@ echo #define HAVE_SIGACTION 1 $@ echo #define HAVE_SIGSETJMP 1 $@ echo #define HAVE_SIGPROCMASK 1 $@ diff --git a/Makefile.hurd b/Makefile.hurd index 6a97db6..d2f9a1f 100644 --- a/Makefile.hurd +++ b/Makefile.hurd @@ -67,7 +67,6 @@ chicken-config.h: chicken-defaults.h echo #define HAVE_LONG_LONG 1 $@ echo #define HAVE_MEMMOVE 1 $@ echo #define HAVE_MEMORY_H 1 $@ - echo #define HAVE_POSIX_POLL 1 $@ echo #define HAVE_SIGACTION 1 $@ echo #define HAVE_SIGSETJMP 1 $@ echo #define HAVE_SIGPROCMASK 1 $@ diff --git a/Makefile.ios b/Makefile.ios index 6f82e00..6c99c47 100644 --- a/Makefile.ios +++ b/Makefile.ios @@ -73,7 +73,6 @@ chicken-config.h: chicken-defaults.h echo #define HAVE_LONG_LONG 1 $@ echo #define HAVE_MEMMOVE 1 $@ echo #define HAVE_MEMORY_H 1 $@ - echo #define HAVE_POSIX_POLL 1 $@ echo #define HAVE_SIGACTION 1 $@ echo #define HAVE_SIGSETJMP
