[Chicken-users] Re: utf8 open tickets
Hi, sorry for the delay. On Sat, Jan 15, 2011 at 12:30 AM, .alyn.post. alyn.p...@lodockikumazvati.org wrote: I have two open tickets against the utf8 egg: https://bugs.call-cc.org/ticket/423 I haven't decided how to handle this yet, but it will probably result in splitting all of the utf8 modules into separate eggs. https://bugs.call-cc.org/ticket/480 Fixed and committed. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] 4.6.3 - regex behavior seems wrong
2010/12/28 Matt Welland estifo...@gmail.com: I'm using the regex egg in 4.6.3 (use regex) Regexs seem to have implict ^ and $ at the start and end. This differs most most regex implementations I'm familiar with. ^\\s+# should match the line # Hello but does not. match matches the entire string, search searches for a match anywhere in the string: #;4 (string-match ^\\s+# # Hello) #f #;5 (string-search ^\\s+# # Hello) ( #) #;6 -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] loopy-loop
On Mon, Dec 20, 2010 at 1:45 AM, Hugo Arregui hugo.arre...@gmail.com wrote: Hi guys, I'm facing an unexpected behaviour using loopy-loop: Is there a reason you're using loopy-loop instead of the newer fast-loop? shows 6,5 as expected, but: (loop lm ((m - in-range-reverse 6 4)) (print m) (lm)) That's a bug, I'll fix it. Also, this: (loop lm ((m - in-range 4)) (print m) (lm)) is given me an error: The error message isn't very helpful, but the problem is you need an endpoint in the range. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] tokyocabinet egg: table API
On Wed, Dec 22, 2010 at 5:46 AM, Sven Hartrumpf hartru...@gmx.net wrote: I use the tokyocabinet egg from time to time. In the uploaded version, there is only support for the hash API (tch), not for the table API (tct). Does anybody have a table API (I need only tc-tdb-open, tc-tdb-close, and tc-tdb-get-columns (= tctdbget3 in C))? I seem to recall someone working on a table API. Either way, patches are welcome. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] loopy-loop
On Wed, Dec 22, 2010 at 10:54 AM, Hugo Arregui hugo.arre...@gmail.com wrote: On Tue, Dec 21, 2010 at 10:44 PM, Alex Shinn alexsh...@gmail.com wrote: On Mon, Dec 20, 2010 at 1:45 AM, Hugo Arregui hugo.arre...@gmail.com wrote: Hi guys, I'm facing an unexpected behaviour using loopy-loop: Is there a reason you're using loopy-loop instead of the newer fast-loop? I didn't know about that. I don't see any docs on eggs index, can you point me to them? fast-loop is a variation that implements the foof-loop syntax: http://mumble.net/~campbell/scheme/foof-loop.txt There are a couple of semantic differences, and some extensions. I'll add documentation when I get a chance. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] jbogenturfa'i compile time down to 12 minutes
On Wed, Dec 1, 2010 at 12:45 PM, Felix fe...@call-with-current-continuation.org wrote: From: Alan Post alanp...@sunflowerriver.org Subject: [Chicken-users] jbogenturfa'i compile time down to 12 minutes Date: Wed, 1 Dec 2010 09:33:07 -0700 I will be more than happy to thoroughly test any changes mode to Chicken's compiler that attempt to optimize large letrec forms with mutually recursive definitions, should any work be done in that area. Working on it - I'll get back to about this. This has been a long-standing complaint of mine! :) I have a macro called let-machine which is basically a letrec that automatically does the transformations needed to compile efficiently under Chicken. I thought I made an egg of it, but apparently not. It must be on my home machine, which I won't have access to for another two weeks. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] utf8 and string-ref performance
On Wed, Nov 24, 2010 at 7:37 AM, Alan Post alanp...@sunflowerriver.org wrote: If possible, I would like to parse utf8 input. I currently have utf8 enabled in my egg. [...] Can anyone point me in the right direction? Parsing is generally one of the things you get for free with utf8. Probably the only thing you need to do is *remove* the reference to the utf8 egg and everything will work. The effect of this is that parsing will work on bytes instead of characters, but the results will be the same. There may still be corner cases. If the API allows searching for individual characters, you need to check if they are non-ASCII and if so convert them into the relevant utf8 string. Indexes on input and output would be in terms of byte position. If you want to make this char position you have to convert once each on input and output. That's O(n), so no effect on asymptotic performance. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] keyword args not assigned in program.
On Sat, Nov 20, 2010 at 5:59 AM, Alan Post alanp...@sunflowerriver.org wrote: It appears that directly evaluating the result of the compiler causes #!key arguments not to be assigned, but if I save that same result and read it back in, things work fine. Seeing the compiler would help, but I'll take a stab and guess you're expanding with macros. That means the expanded forms will be wrapped hygienically and not match plain symbols. Reading and writing to a file effectively strips hygiene. To do this manually at runtime, use `strip-syntax' on the keyword names. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] using mmap files as strings?
Peter Bex peter@xs4all.nl writes: On Fri, Oct 22, 2010 at 06:20:01AM -0400, Felix wrote: I'm specifically interested in running regular expressions across the mmap space. irregex provides a chunk based API, perhaps it is possible to define chunks over the data represented by the mmap pointer. Alex or Peter might be able to tell more about this. The chunked API requires being able to extract strings from the mmapped memory. Chunks also only move forward, so you can't backtrack. If the SRE gets compiled to a backtracking matcher you probably want to include a few commits because otherwise all chunks stick around in memory, I think. I'm not exactly sure how it handles that though. Actually, currently even non-backtracking regexps will hold onto all chunks. The intention of the chunked API is to make it easy to work with non-consecutive strings, not strings that can't fit into memory. Specifically, I wanted to be able to handle any kind of text-buffer (gap-buffer, piece-table, etc.) easily. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Using irregex safely responsibly
Jim Ursetto zbignie...@gmail.com writes: I agree with Peter, the /default procedures seem like a needless abstraction as a totally unambiguous #f is common practice. For example, srfi-13 string-index. No, in retrospect I'm not sure why I didn't suggest that to begin with - I think I've been working too much with type inference lately, which makes such ambiguous return types undesirable. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Using irregex safely responsibly
Jim Ursetto zbignie...@gmail.com writes:
There is some inconsistency in the docs:
irregex-match-num-submatches: Returns the number of numbered
submatches that are defined in the
irregex or match object.
irregex-match-valid-index?: Returns {{#t}} iff the {{index-or-name}}
named submatch or index is defined in the {{match}} object.
But below, *-valid-index? says undefined when *-num-submatches says defined:
Not quite, *-valid-index? says invalid, not undefined.
*-num-submatches just tells you the total number of
submatches that are defined in the regexp, regardless of
what has been matched, and irregex-match-num-submatches on a
match result will always return the same result as
irregex-num-submatches on the corresponding regexp.
The valid-index? predicate does not return a boolean #t value:
#;9 (irregex-match-valid-index? m 3)
0
It returns #t for this in the upstream irregex.
I prefer the old behavior for consistency because if irregex tells me
that 3 submatches exist, I expect to be able to access them without an
exception being thrown.
*-valid-index? just states whether the submatch _may_ exist.
We could add a utility irregex-match-matched-index? to test
if a specific index was successfully matched.
An index which could never be a valid submatch should
arguably always throw an error.
An index which is valid, but failed to match, could either
throw an error or return #f. The -index and -substring
operations are inconsistent in this respect, so we should
fix that.
It may be good to provide both sets, with a /default version
analogous to SRFI-69 hash-table-ref and
hash-table-ref/default:
(irregex-match-substring m invalid-i)= error
(irregex-match-substring m unmatched-i) = error
(irregex-match-substring/default m invalid-i #f)= error
(irregex-match-substring/default m unmatched-i #f) = #f
Thoughts?
--
Alex
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: Removing deprecated wiki-parse egg from the repository [Was: Re: [Chicken-users] More on Packaging eggs]
If anyone is interested I can revert it to the original syntax used on the synthcode.com wiki, otherwise go ahead and delete it. iPhoneから送信 On 2010/10/08, at 16:21, Peter Bex peter@xs4all.nl wrote: On Wed, Sep 29, 2010 at 04:25:09PM -0500, Jim Ursetto wrote: wiki-parse was and initial attempt to tweak what was originally a parser by Alex Shinn for mediawiki syntax, so that it could read svnwiki syntax. If Alex still wants to support it (I wouldn't recommend it, we've hacked this egg beyond all recognition), he could remove this marking. I'd just delete the egg from the repo. It makes Alex look bad and it's not even his fault. Unless anyone objects, I'm going to do this. That means this egg will no longer show up anywhere, and will not be installable anymore. Cheers, Peter -- http://sjamaan.ath.cx -- The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music. -- Donald Knuth ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] dev-snapshot 4.6.3
John Cowan co...@ccil.org writes: On Wed, Oct 6, 2010 at 8:58 AM, Felix fe...@call-with-current-continuation.org wrote: - the `regex' library unit has been removed and is separately available as an extension which should be fully backwards- compatible - `irregex' is now a core library unit and replaces the `regex' API I understand the merits of reducing core dependencies, but have performance comparisons been made? The last I heard, irregex was *much* slower than regex. The switch to irregex was made a long time ago - this new change is just replacing the API with the irregex API. Not only does this remove a needless wrapper layer, but the irregex API provides more fine grained control for performance. Irregex is also asymptotically faster than PCRE, so despite more constant overhead can run arbitrarily faster in certain cases. Also, as Peter says irregex performance was improved a lot recently, and will continue to improve. It's the core regex library for Chicken and Jazz Scheme and a number of other projects, so it gets a lot of attention. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Chicken Gazette - Issue 5
_/_/_/ _/_/_/ _/_/_/_/ _/_/_/ _/ _/ _/_/_/_/_/ _/_/_/ _/ _/_/_/ _/_/_/_/ _/_/ _/_/_/ _/ _/_/ _/_/_/_/ _/_/_/ _/_/ _/_/_/_/ _/_/_/_/_/ _/_/ --[ Issue 5 ]-- G A Z E T T E brought to you by the Chicken Team == 0. Introduction Welcome to issue 5 of the Chicken Gazette! We're tentatively switching the Gazette publication to Monday this week, to give people something to read after coming back from the weekend. == 1. The Hatching Farm - New Eggs The Egg Repository This week Mario Domenech Goulart (http://wiki.call-cc.org/users/mario-domenech-goulart) released a new egg called accents-substitute (http://wiki.call-cc.org/eggref/4/accents-substitute) to replaced accented Latin characters with either HTML entities or their non-accented ASCII equivalents, for when you need to work with ASCII-only text. Ivan Raikov (http://wiki.call-cc.org/users/ivan-raikov) has been busy, and in addition to many egg updates has released a new egg called cis (http://wiki.call-cc.org/egg/cis) (compact integer sets) as a possible alternate to last week's featured egg iset (http://wiki.call-cc.org/egg/iset). It's less efficient in terms of time and space, but has a simpler implementation for when performance doesn't matter. Our fearless leader Felix (http://wiki.call-cc.org/users/felix-winkelmann) also added a new egg system (http://wiki.call-cc.org/eggref/4/system), inspired by the CL defsystem macro. `system` lets you define groups of files and their dependencies which can be loaded or compiled, and even re-loaded or compiled keeping track of modified files. Use it for a `make` alternative in your .setup files, or for rapid development in the repl! == 2. The Core - Bleeding Edge Development It's been another busy week for core development: Overflow-detection for basic arithmetic ops (`+`, `-`, `*` and `/`) has been changed to use bit-twiddling instead of parallel flonum computations, since 64-bit IEEE doubles have not enough precision to hold the full range of fixnums on 64-bit systems A serious compiler bug related to inlining was fixed (found with much help by Sven Hartrumpf (http://wiki.call-cc.org/users/sven-hartrumpf)), and several other bugs reported by Kon Lovett (http://wiki.call-cc.org/users/kon-lovett) were fixed. A new foreign type `pointer-vectors` (vectors of native unboxed pointers) was added, with an API in lolevel. A simpler alternative to `er-macro-transformer`, `ir-macro-transformer` (implicit renaming macros) was added by Peter Bex (http://wiki.call-cc.org/users/peter-bex). See ticket #394 on trac. But the biggest change: irregex is now the official regex API, and has full library unit status, regex unit is removed and available as an egg (should be fully backwards compatible, as long as `(use regex) (import irregex)` idiom is used; dependencies on regex unit not in egg repo, though), upgraded irregex version, many upstream bug-fixes and optimizations, with many thanks to Peter Bex (http://wiki.call-cc.org/users/peter-bex) and Alex Shinn (http://wiki.call-cc.org/users/alex-shinn). And thanks to Felix for help with the summary! == 3. Chicken Talk The exciting news on the mailing list this week was a performance boost (http://lists.nongnu.org/archive/html/chicken-users/2010-09/msg00074.html) mentioned by Mario Domenech Goulart (http://wiki.call-cc.org/users/mario-domenech-goulart) where the awful (http://wiki.call-cc.org/eggref/4/awful) web framework ran a benchmark almost 7x faster. This is likely due to a new GC improvement by Felix. Taylor Venable brought up an issue (http://lists.nongnu.org/archive/html/chicken-users/2010-09/msg00068.html) in the new coops (http://wiki.call-cc.org/eggref/4/coops) object system involving class redefinition and `define-method` on a generic not first provided with `define-generic`. It turns out Chicken will do an implicit `define-generic` for you as a convenience, but it's probably best to define each generic once explicitly. Also be aware that redefining a class will create a completely new class which instances of the old class will not belong to. Richard Hollos reported an error (http://lists.nongnu.org/archive/html/chicken-users/2010-09/msg00066.html) compiling on AMD64 Linux, which turned out to be just a chicken and egg problem. Markus Klotzbuecher provided a patch (http://lists.nongnu.org/archive/html/chicken-users/2010-09/msg00075.html) for the `cairo` egg, showing activity in the graphical library front. Finally Felix just announced (http://lists.nongnu.org/archive/html/chicken-users/2010-09/msg00083.html) coops (http://wiki.call-cc.org/eggref/4/coops) version 1.0! If you've been using `tinyclos`, give `coops` a try. == 4. Omelette Recipes - Tips and Tricks We've got a wide variety of options for parsing in Chicken, from the built
Re: [Chicken-users] Autoloading optional dependencies
Felix fe...@call-with-current-continuation.org writes: From: Alaric Snell-Pym ala...@snell-pym.org.uk If there's macros involved, yes - but then autoloading macros makes no sense as they're loaded at compile time anyway. When you set up an autoload, no compile-time loading happens (no import library, etc) so the macros from the library aren't loaded - but at run time, if you call a procedure imported from the library, then the library is run-time-loaded. Sorry, I can't stop nagging: first, the constructed module#identifier name will not work for identifiers that are imported from a different module and then reexported, second: `global-ref' will be deprecated soon. These are both easy enough to fix by just importing the module without requiring it, and arranging for the first call to do the require. The only problem with this is you'll get warnings about importing undefined identifiers. I don't suppose we could have a declaration or some way to suppress these warnings for individual identifiers and/or modules? -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Autoloading optional dependencies
On Wed, Sep 15, 2010 at 2:01 AM, Felix fe...@call-with-current-continuation.org wrote: From: Alex Shinn alexsh...@gmail.com Subject: Re: [Chicken-users] Autoloading optional dependencies Date: Wed, 15 Sep 2010 00:16:11 +0900 The only problem with this is you'll get warnings about importing undefined identifiers. I don't suppose we could have a declaration or some way to suppress these warnings for individual identifiers and/or modules? Sorry, I don't understand. Well, let's say we have (module auto (json-write) (import scheme) (autoload json json-write)) which basically just exports json-write from the json egg but loaded on demand. So the autoload could expand into: (module auto (json-write) (import scheme) (begin (import (rename json (json-write tmp))) (define (json-write . args) (require 'json) (set! json-write tmp) (apply tmp args thus making use of the module system to resolve names, but performing the require only once when json-write is first called. This works and uses no deprecated features, but when you use the module you'll get the following warnings: Warning: the following toplevel variables are referenced but unbound: json#json-write (in json-write) json#json-write (in json-write) and rightly so, because it's a common error to import an egg without requiring it. But in this case it's intentional. So maybe we could have an alternate form (import-without-warnings (rename (json (json-write tmp ? -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Announcing call-cc.org
Mario Domenech Goulart mario.goul...@gmail.com writes: * http://code.call-cc.org: VCS repositories for CHICKEN and eggs code and release tarballs. If you have an old checkout of any or all of the eggs repo and don't want to download the whole thing again, the magic incantation for SVN to point to the new server seems to be: svn switch --relocate https://galinha.ucpel.tche.br/svn/chicken-eggs \ https://code.call-cc.org/svn/chicken-eggs -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Printing circular lists
Taylor Venable tay...@metasyntax.net writes: If you're open to using a different method to do so, both the fmt and srfi-38 eggs provide such a means via fmt and write-with-shared-structure, respectively. Note Chicken's SRFI-38 implementation also provides `make-repl-support-shared-structure' to automatically print results with `write-with-shared-structure': $ csi -qR srfi-38 #;1 (make-repl-support-shared-structure) #;2 (define a (list 1 2)) #;3 (set-cdr! a a) #;4 a #=0(1 . #0#) #;5 -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: Missing documentation for eggs
felix fe...@call-with-current-continuation.org writes: I tested it once more, and it actually runs to completion, but takes ages to load, so you're completely right. Sorry if this caused any hassle. The expander is definitely too slow. I have to work on that. matchable also uses only syntax-rules, so while it generates fast code, the expansion can be slow. I can speed it up by special casing a few things with ER macros. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] utf8 egg and byte-* procedures
Jeronimo Pellegrini j...@aleph0.info writes: It's fine until that point -- now the string-length procedure is utf8-aware. So that means the egg was loaded and the string manipulating procedures were redefined. But the egg documentation mentions that I can use the byte- prefix to get the old non-utf8 procedures (and explicitly mentions byte-string-length). Now, I suppose they're not visible (or bound) by default, because: In Chicken 3 I provided a separate byte-string module which you needed to import to get access to the renamed byte- versions of the non-utf8 procedures. In Chicken 4 this is no longer needed, since we have modules with fine-grained control of importing. So to get byte-aware versions of the string procedures you can use: (import (prefix byte- (only scheme string-ref string-set! string-length))) and just add to the `only' list any other procedures you need. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] utf8 egg and byte-* procedures
Alex Shinn alexsh...@gmail.com writes: In Chicken 4 this is no longer needed, since we have modules with fine-grained control of importing. So to get byte-aware versions of the string procedures you can use: (import (prefix byte- (only scheme string-ref string-set! string-length))) Sorry, I meant (import (prefix (only scheme string-ref string-set! string-length) byte-)) -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Speeding up bit-vector operation (using iset)
felix winkelmann bunny...@gmail.com writes: On Wed, Mar 17, 2010 at 1:18 PM, Alex Shinn alexsh...@gmail.com wrote: At 2^26 bits each I would say these are *huge* bit-vectors. (do ((i 0 (+ 1 i))) ((= i 10)) (bit-vector-and s1 s2) (bit-vector-ior s1 s2) (bit-vector-and s1 (bit-vector-nand s2))) These operations are generating three new huge bit-vectors on each iteration, so you're spending all your time in GC (and the loop has no effect). I don't think this is completely true. GC-time is quite considerable, but the loops in iset.c are not tight enough for so many iterations (which is mostly caused by slow XXXvector operations that require a full CPS call). Oops, yes, you're right. I wrote iset before I knew how to optimize code for Chicken. I've modified iset so that it will generate tight loops on the bit-vector arithmetic operations, and it runs the original example in just over a second on my machine. You might be able to make this faster by using u32/u64 vectors (storing only fixnum-sized values), but you'd get the biggest gain from rewriting the operations directly in C and vectorizing them. The code is checked into SVN and a new egg should be available shortly. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Speeding up bit-vector operation (using iset)
Lasse Kliemann lasse-list-chicken-2...@mail.plastictree.net writes: It creates two large bit-vectors, initializes them with random entries, and then performs and, ior, and nand operations (corresponding to intersection, union, and difference of the sets defined by the vectors) a number of 10 times. At 2^26 bits each I would say these are *huge* bit-vectors. (do ((i 0 (+ 1 i))) ((= i 10)) (bit-vector-and s1 s2) (bit-vector-ior s1 s2) (bit-vector-and s1 (bit-vector-nand s2))) These operations are generating three new huge bit-vectors on each iteration, so you're spending all your time in GC (and the loop has no effect). If you want to do in-place bit-vector operations you want `bit-vector-and!' and `bit-vector-ior!' (with the trailing exclamation point). -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Set data structure
Lam Luu luuxuan...@gmail.com writes: Well, that's is set in list, which is horribly slow (O(n) IS very slow, for most intends and purposes). I guess my question something like, is there any implementation of set in chicken that is at least O(log n), aka using binary search tree of some sort? For integer sets there's the iset egg, which is highly optimized. For other data types you can just use a hash-table. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Was crunch really discontinued? Is there an alternative?
Jeronimo Pellegrini j...@aleph0.info writes: I have written a program that repeatedly multiply matrices as a very simplistic benchmark (because it is the kind of thing I'd like to do very fast). The result was: bigloo 0.52s gambit 2.70s chicken 8.70s This is for compiled Scheme, with all possible optimizations turned on. Can we see the code and optimization settings you used? -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Is the hato suite working on chicken 4.x?
Timothy Beyer bey...@cs.ucr.edu writes: Has anyone tried running any of the hato suite on = 4.x? If it just requires a few minor changes, I'll try to give it a go, but if major changes are required, I'm going to find a way to have multiple versions of chicken installed concurrently, or maybe not upgrade for a while... The development version of the hato suite has been ported to 4.x. and overall has many changes since the last official release. I'm not sure when I'll have time to make an official 0.4 release, but if I don't get around to it soon I'll at least make the repository available. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: module indentation.
Anthony Carrico acarr...@memebeam.org writes: Jim Ursetto wrote: 2009/5/4 Anthony Carrico acarr...@memebeam.org: I didn't indent the module (this will make it easier to check my work with svn diff). It seems that it is useful not to indent the module body, as definitions aligned at left works better with emacs and scheme-complete. So that is perfectly fine. Except that in emacs it is nice to use indent-sexp to indent the whole module. (defun scheme-module-indent (state indent-point normal-indent) 0) (put 'module 'scheme-indent-function 'scheme-module-indent) -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Which eggs to migrate from Chicken 3 first?
Hi, Phil Bewig pbe...@gmail.com writes: Streams are not lists. Scheme ensures there are substantial disadvantages to using streams rather than lists, due to the underlying promises that require numerous type conversions, so streams should be used only when the sequence of elements is truly infinite (such as mathematical series) or when there is some clear advantage of laziness (such as reducing the number of passes through a large data set). I also find that any data structure in general which is built on I/O works well as a stream. For the current NLP app I'm working on, I need to build a parse graph from a port. Slurping up the whole input at once could require too much memory, and also would prevent the parser acting as a proper (buffered) Unix filter. On the other hand, since the algorithm for determining how much text I need to work with is dynamic, I can't just read chunks at a time (the basic unit I want to work on is a sentence, but I don't know what a sentence is until the parse is finished). So I build the graph as a lazy stream of nodes, and the algorithm transparently expands only as much input as needed. From what I've seen Alejandro also uses streams primarily with I/O - it's a very natural combination. Writing a library that duplicates SRFI-1 for streams seems to me to be folly. Well, if you have streams at all, even if they are only suited to a special class of algorithms, it makes sense to provide a complete library of basic operations. Otherwise people will continuously reinvent the same utilities, and sometimes get them wrong. In fact, it is specifically desirable to provide an exact match of the SRFI-1 API for easy conversions and comparisons. In any module system with import prefixing (including Chicken 4), you can write everything with a stream- prefix and swap the backend from streams to lists with: (import srfi-41) (import (prefix stream-) srfi-1) Going the other direction (writing for SRFI-1 but then switching to streams) is only a little more verbose, requiring renaming of the individual identifiers you use. Some certainly don't belong in a general-purpose library -- if you need symbol-stream to convert the name of a symbol into a stream of characters, you can write it as part of your program. Sure: (define (symbol-stream sym) (string-stream (symbol-string sym))) That's just trivial and probably borderline enough that it isn't needed in the library. string-stream or equivalent functionality should be included, though, because the most efficient implementation of this may vary wildly depending on the Scheme implementation. However, the name may be unintuitive if you're not coming from a streams as I/O perspective. It may be both simpler to specify and easier to understand if you replace most of the foo-stream procedures with: (write-to-character-stream object) (display-to-character-stream object) Many -- such as stream-butlast -- make sense only for lists (which are materialized in their entirety) and not for streams (which may never be materialized). I think it's a little unfair to pick on stream-butlast when SRFI-41 includes stream-length, stream-list, stream-reverse, etc. As you yourself say, not all streams are infinite, and for finite streams these can be useful. Otherwise you'll repeatedly find people who when working entirely with streams (for type signature compatibility, and because all of their utilities are designed for streams, not lists), write things like (list-stream (butlast (stream-list stream))) when they really do need all but the last element of a stream they know to be finite. [I would argue the name and API should be changed to stream-drop-right to match SRFI-1, though.] Now, if you want to argue that the SRFI-1 API is too large, that's another story :) -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] scheme-complete 0.8.6
The latest scheme-complete.el is available at http://synthcode.com/emacs/scheme-complete-0.8.6.el.gz now properly handling module forms and imports even when the module isn't complete, or parens are otherwise unbalanced. It also uses csi -e '(print (repository-path))' instead of chicken-setup -R to find the repository, which should work both in Chicken 3 and Chicken 4. Note that it still expects top-level definitions to be aligned along the left margin - it won't find definitions or imports if you indent the body of the module. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: scheme-complete 0.8.5 for chicken 4
Alex Shinn alexsh...@gmail.com writes: The latest scheme-complete.el is available at http://synthcode.com/emacs/scheme-complete-0.8.5.el.gz This release includes Chicken 4 support, recognizing module forms including only, except, rename, and prefix import specifiers. The module support currently requires that the full module form use balanced parens - I'll fix that shortly. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] stressing the new hygienic macros
Michele Simionato michele.simion...@gmail.com writes: Anyway, this is bad news for me. It means that if I want to define my own syntax transformers I have to implement them from scratch from low level macros :-( No, you can't define your own _transformers_ (the things you pass to define-syntax) with either low or high-level macros. The limitation is not in syntax-rules, it's in define-syntax, let-syntax and letrec-syntax. However, looking at your sweet macros, you can implement def-syntax in either low or high-level macros. Just define a def-syntax macro that expands into a define-syntax macro. The problem is that then this can't be used conveniently with let-syntax and letrec-syntax. So if you want to define your own macro extensions, you need to provide: my-define-syntax my-let-syntax my-letrec-syntax These would then not be composable with any other macro extensions. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] scheme-complete 0.8.5 for chicken 4
The latest scheme-complete.el is available at http://synthcode.com/emacs/scheme-complete-0.8.5.el.gz This release includes Chicken 4 support, recognizing module forms including only, except, rename, and prefix import specifiers. Inside a module form it only expands currently imported identifiers, so if you start with a blank module: (module foo () ^ ) and try to complete it will complain that there are no completions. Making a habit of completing symbols is a good way to make sure you've imported everything you need without waiting for the compiler to tell you. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] stressing the new hygienic macros
Michele Simionato michele.simion...@gmail.com writes: I have subscribed again the list after a few years of absence, because I wanted to try the new and improved hygienic Chicken ;-) As first experiment, I tried to stress a bit syntax-rules. I tried the following at the REPL: (define-syntax very-static-table (syntax-rules () ((_ (name value) ...) (syntax-rules (names name ...) ((_ names) '(name ...)) ((_ name) value) ... (define-syntax color (very-static-table (red 0) (green 1) (blue 2))) Error: unbound variable: red This is left unspecified by R5RS which says nothing about transformer specs other than syntax-rules. Chicken 4 extends define-syntax with the er-macro-transformer spec, (and with raw lambdas which mean the same thing), but these are hard-coded. Al* Petrofsky specifically argued that this be allowed, as well as (let-syntax ((foo some-other-macro)) ...) and implemented it in his alexpander. It's a necessary feature for the user to provide his/her own syntax transformers defined in terms of existing transformers (e.g. super-syntax-rules with extended pattern matching). The other syntactic-closures and riaxpander macros systems in Chicken 3 also support it, as do MIT Scheme, Ikarus and Chibi-Scheme. PLT doesn't. A lot of interpreters do, but more by coincidence than design, and the fact that they represent macros as first-class values (which would make separate compilation, even to bytecode, much harder). -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Which eggs to migrate from Chicken 3 first?
John Cowan co...@ccil.org writes: 52 eggdoc 19 openssl 6 iconv 5 utf8 4 tcp-server 3 format 6 sendfile 2 graph-scc These have already been ported. 17 http Should be deprecated in favor of intarweb? 5 syntactic-closures Deprecated in favor of the new native macro system. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] irregex bug?
Hi, Anthony Carrico acarr...@memebeam.org writes: #;1 (require-library regex) ; loading library regex ... #;2 (import irregex) ; loading /usr/local/lib/chicken/4/irregex.import.so ... #;3 (define rx (sre-irregex '(: bos (submatch (+ (0123456789))) eos))) #;4 (irregex-match rx 0) #(*irregex-match-tag* 0 () 0 1 0 1) #;5 (irregex-match rx a) #f #;6 (irregex-match-data? (irregex-match rx 0)) #f #;7 Thanks for catching this. It had already been fixed upstream, so I've pushed the fix to the chicken trunk. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New to Scheme Macros
John Cowan co...@ccil.org writes: Jim Ursetto scripsit: Explicit renaming macros look neat; the only kinda bummer thing is having to manually pull apart the components of the expression with car/cdr/etc. instead of the destructuring happening in a more automatic way. Of course, I imagine one could write a macro to do this... :) Yes -- hence the matchable extension ;) Matchable is kind of heavyweight compared to destructuring-bind, although it can of course do the same job. (define-syntax bind (syntax-rules () ((_ pat var body ...) (match-let ((pat var)) body ... This is both more concise and more powerful than destructuring-bind. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-setup infinite loop
Hi, underspecified underspecif...@gmail.com writes: Under chicken 3.4.0, I have noticed that I can make chicken-setup enter into an infinite loop by telling it to fetch, but not install the http egg. I posit that the cause is a circular dependency somewhere among http's many dependencies, because eggs like rss with simpler dependencies do not loop. The dependency tree in this case looks like: http (regex-case url openssl) regex-case () url (coerce uri) coerce (miscmacros misc-extn) miscmacros () misc-extn (stack miscmacros) stack () uri (coerce miscmacros synch lookup-table) synch () lookup-table (miscmacros misc-extn) openssl () There's no circular dependency (that would arguably be a bug in the eggs themselves, though chicken-setup should try to handle it gracefully), just some diamond inheritance, but it turns out the bug is triggered for any egg with any dependencies. I've checked in a simple fix which conditions out running install on downloaded dependencies when -fetch is being used. Note this ugly mess has been rewritten in the upcoming Chicken 4 and the setup program renamed to chicken-install. Note also that the http egg also has an improved version in Chicken 4 called intarweb :) -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Build Failure (maybe infinite recursion) on x86_64 Linux
felix winkelmann bunny...@gmail.com writes: It seems that one of the regexen's compiled in the definitions for `absolute-pathname?' or `decompose-pathname' triggers a loop in `nfa-join-transitions!' in the files.scm unit (these are executed at toplevel, outside of the scope of the associated lambdas). Yes, but that would happen at load time, not compile time, so I guess some other macro is using the files unit at compile time, thus loading irregex? Anyway, I tried compiling all four of the patterns occurring in those two procedures with both the irregex.scm in Chicken and with the latest upstream, and couldn't trigger an infinite loop. I'm also puzzled as to how this can be behaving differently between Chicken 3 and 4 when the irregex.scm file is identical. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Questions about pipes
Lam Luu luuxx...@umn.edu writes: Is there any way to spawn another process, then catch both of its stdin and stdout? (use posix) (receive (in out pid) (process gnugo) ...) -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] utf8-srfi-13 and string-join
Timothy Beyer bey...@cs.ucr.edu writes: I just found out today that the utf8 version of srfi-13 doesn't have or export string-join. (though the non-utf8 version does) I'll probably roll my own version for my own use until it is added, but I don't know how to write one that is properly utf8-aware, so I don't think it would be worth submitting. (define utf8-string-join string-join) If the procedure does no indexing on characters then the utf8 version is the same as the normal version. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] optimizing mutually recursive loops
When optimizing my Chicken code for speed, I find one of the most important things is to write the code so that it gets compiled into a single C function with gotos. It's often so important to get this that I end up writing very unnatural Scheme code, including manually combining several loops into one. For a simple example, if you look at the canonical mutual recursion example: (letrec ((myeven? (lambda (x) (if (zero? x) #t (myodd? (- x 1) (myodd? (lambda (x) (if (zero? x) #f (myeven? (- x 1)) (myeven? n)) this will generate two mutually recursive C functions in the backend. Because the overhead of the body of these functions is negligible, the cost of the function overhead is relatively high. One can consider, instead, combining the two procedures into a single, self-recursive procedure. We do this by prepending a label to the argument list, with an integer value assigned to each of the virtual procedures, and dispatch accordingly. The above case becomes something like: (let dispatch ((label 0) (x n)) (if (eq? label 0) (if (zero? x) #t (dispatch 1 (- x 1))) (if (zero? x) #f (dispatch 0 (- x 1) Here the label 0 is for myeven?, and 1 is for myodd?. At first glance, apart from being much harder to read, this would seem to be a pessimisation - we're doing the extra work of a conditional test on each of the loop steps. However, in the C backend this gets compiled to a single procedure with self-tail-calls contracted to gotos. Whenever you find yourself writing ugly code in the name of speed, you should stop and try to abstract away the ugliness. To that end, the let-machine syntax at the end of this article will automate the process for you. Given any letrec expression of literal lambdas, you can simply replace letrec with let-machine. In this case: (let-machine ((myeven? (lambda (x) (if (zero? x) #t (myodd? (- x 1) (myodd? (lambda (x) (if (zero? x) #f (myeven? (- x 1)) (myeven? n)) will generate code similar to the manually unified loop above. Does it help? For this example with n=4, I get 8.703 seconds for the letrec version compared to 1.671 seconds for the let-machine version - a better than 5x improvement! However, this is a toy example where the real work is almost nil and the function overhead everything. There's also an important caveat - the goto contraction can only happen in nested chains of inlined primitives. If you call an arbitrary procedure, it will always generate a full function call. That's a big caveat (and learning exactly when the goto's get generated takes practice). So are there useful examples of loops involving only primitives? A good example of an expensive nested loop is the matrix multiplication algorithm. To multiple matrix A x B, the resulting matrix C can be determined by C(i,j) = A[i,:] x B[:,j] i.e. the dot product of the ith row of A with the jth column of B. In Scheme (with matrices as vectors and passing explicit row/column information): (define (matrix-multiply a a-rows a-cols b b-rows b-cols) (assert (= a-cols b-rows)) (let ((c (make-vector (* a-rows b-cols (let lp1 ((i 0)) (if (= i a-rows) c (let lp2 ((j 0)) (if (= j b-cols) (lp1 (+ i 1)) (let lp3 ((k 0) (sum 0)) (if (= k a-cols) (begin (vector-set! c (+ (* i a-rows) j) sum) (lp2 (+ j 1))) (lp3 (+ k 1) (+ sum (* (vector-ref a (+ (* i a-cols) k)) (vector-ref b (+ (* k b-cols) j) [This would be a little easier to read with do, and a lot easier to read with foof-loop, but I want to make the recursive calls explicit.] The innermost loop lp3 is computing the dot product. It's just performing simple arithmetic operations on each step but the last, so it will be compiled normally with a goto so long as usual integrations are enabled. However, the outer loops are also just composed of primitives, plus calls to the (known) inner loops. What would happen if we could flatten them? It turns out, we _can_ flatten them. By writing them the way we did, with explicit calls back to the outer loop at the end of each loop, we've showed how they are mutually recursive. Thus they allow a straightforward conversion to letrec, and then let-machine: (define (fast-matrix-multiply a a-rows a-cols b b-rows b-cols) (assert (= a-cols b-rows)) (let ((c (make-vector (* a-rows b-cols (let-machine ((lp1 (lambda (i) (if (= i a-rows) c (lp2 0 (lp2 (lambda (j) (if (= j b-cols) (lp1 (+ i 1)) (lp3 0 0 (lp3 (lambda (k sum) (if (= k a-cols) (begin (vector-set! c (+ (* i a-rows) j) sum)
Re: [Chicken-users] freetype egg still being developed?
Matt Gushee m...@gushee.net writes: Like the subject says ... the latest version of freetype in the main egg repo is 0.1. Has Alex, or anyone, done anything beyond that? I am going to need a significant increase in functionality in order to implement font embedding for the PDF egg I am working on. I'm really not the best person to do this kind of thing, because I know just enough C to be dangerous, but if nobody else is doing it, I guess I'll have to. Sigh What other functionality do you need? -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] need regex benchmark
Tobia Conforto [EMAIL PROTECTED] writes: Alex Shinn wrote: Tobia Conforto writes: The file perltestdata in Edi Weitz's cl-ppcre contains a big PCRE stress test (15,000 tests) already formatted for lisp. What Felix is looking for, however, is a benchmark. What's wrong with repeating 1000 times each of those test cases, at least the ones that are not supposed to fail, and record the CPU time used? Because there are regexps which you want to be fast, regexps which you want to just be tractable, and regexps for which there is really no hope. The next release of irregex will include all of these cases, carefully catalogued, measuring compile time, execution time, and memory usage. I just have no idea when I'll get around to this. In the meantime, if you want to take a representative sample you might as well take a sample of something people are actually using. CL-PPCRE doesn't do a DFA construction, so there are regexps that irregex can execute instantly that CL-PPCRE couldn't even execute in a million years. These are obviously _not_ in the CL-PPCRE test suite, so I'm not too confident of it being usable for any kind of benchmarking purposes. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] need regex benchmark
Tobia Conforto [EMAIL PROTECTED] writes: felix winkelmann wrote: Does someone know of a good regex benchmark Yes. The file perltestdata in Edi Weitz's http://weitz.de/files/cl-ppcre.tar.gz contains a big PCRE stress test (15,000 tests) already formatted for lisp. Every line of the file contains a s-expr with the following fields: - numeric id - the test in perl syntax, for cross-language benchmarking - the regular expression under test - case-insensitive? - multi-line? - single-line? - verbose? - target string - error-expected? - expected-match - expected-registers Thanks, I'll take a look at those tests, but they're likely to have a lot of duplicates with the existing test suite. What Felix is looking for, however, is a benchmark. CL-PPCRE used to have benchmarks, but they weren't very good, and don't even seem to be available anymore. The shootout benchmark is a joke. I'll be working on comprehensive benchmarks for the next release of irregex. In the meantime, I think a simple collection of common regular expressions and usage patterns in existing Chicken code would help to reassure people :) -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] string-translate and utf-8
Ah, sorry, I didn't have the latest version of the utf8 egg. I can reproduce the bug now. -- Alex Sunnan * [EMAIL PROTECTED] writes: Well; here's a transcript: CHICKEN (c)2008 The Chicken Team (c)2000-2007 Felix L. Winkelmann Version 3.2.7 - linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables applyhook hostpcre ] compiled 2008-08-21 on debian (Linux) #;1 (string-translate i ö o_) Error: (string-translate) invalid translation destination 0 o_ Call history: syntax(string-translate i ö o_) eval (string-translate i ö o_) -- #;1 (require-extension utf8) ; loading /var/lib/chicken/3/utf8.scm ... ; loading /var/lib/chicken/3/utf8-support.so ... ; loading /var/lib/chicken/3/utf8-lolevel.so ... ; loading /var/lib/chicken/3/byte-string.so ... #;2 (string-translate i ö o_) Error: (vector-ref) out of range #(#\o #\_) 2 Call history: syntax(string-translate i ö o_) eval (string-translate i ö o_) -- ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] string-translate and utf-8
Hi, sorry for the late reply. Sunnan [EMAIL PROTECTED] writes: I'm updating old code that used to work: (require-extension syntax-case utf8 srfi-1 utf8-srfi-13 miscmacros) ;(import utf8) ;(import utf8-srfi-13) ;(commented out since they're not needed anymore?) (use utf8-srfi-13) ;(I've tried with and without this line) (string-translate i ö o_) ;; this should eval to _i_ but i get Error: (vector-ref) out of range, I guess because it reads the multi-byte characters (i.e. #\ö) as multiple entries in the vector. I can't reproduce this. The utf8 extension (not utf8-srfi-13) does provide a STRING-TRANSLATE replacement which handles multi-byte characters (verified on a Chinese example in the test suite). The only thing I can think might be going wrong is the normalization form. If the ö you input into is not the single Unicode character U+00F6 (LATIN SMALL LETTER O WITH DIAERESIS), but is rather U+006F (LATIN SMALL LETTER O) followed by U+0308 (COMBINING DIAERESIS), then you have not only multi-byte characters, but multi-*codepoint* characters. STRING-TRANSLATE, as with all Unicode utilities, works at the codepoint level, not the extended grapheme level. Thus the first vector has 3 elements to the second vectors' 2 elements, and the range error occurs. Modifying STRING-TRANSLATE to work at the extended grapheme level rather than the codepoint level would be a lot of work, and possibly not what people expect. As a workaround, if you have no control over the normalization forms, you can always use STRING-TRANSLATE*. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] current base64 on chicken 3 incorrect?
felix winkelmann [EMAIL PROTECTED] writes: On Fri, Oct 31, 2008 at 2:51 PM, Graham Fawcett [EMAIL PROTECTED] wrote: Hi folks, The current base64 egg for Chicken 3 builds, but gives me incorrect results. The non-working version is by Bailey, ported by Felix. (I found an older version in Scheme by Felix that works correctly.) No, the C version by Bailey was ported by Zbigniew. Thanks for noticing it, Graham, but don't expect a fix any time soon. There's a fast, working version in Hato (hato-base64) if you need: http://synthcode.com/scheme/hato/ -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] faster threading
Jörg F. Wittenberger [EMAIL PROTECTED] writes: My conclusion: I begin a Nuke copyright issues in my way!-implementation of llrbtree.scm. Left leaning red-black trees are definitely worth trying, I'm looking forward to seeing your code! Another alternative is skip lists. Taylor Campbell has an implementation at http://mumble.net/~campbell/scheme/skip-list.scm which according to his benchmarks is much faster than red-black trees (second-hand info, I haven't run the benchmarks myself and the timings may be different for Chicken). The code is released in the Public Domain, so licensing would not be a problem. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in canonical-path?
Hi, Ivan Raikov [EMAIL PROTECTED] writes: I have been meaning to port the Haskell FilePath library to Chicken, because I find its API to be quite elegant and better organized than the existing file name manipulation routines in Chicken. This discussion has prompted me to create the filepath egg, which is an almost verbatim transliteration of the Haskell code, with a few Chicken-specific idioms here and there. I have included a flag parameter, which can be used to enable Posix mode or Windows mode for path name parsing and manipulation. The Windows mode supports weird things like UNC names and is aware of the DOS reserved names (CON, PRN, etc). I would appreciate it if people look at it, as I would like to see some variant of this API supersede the existing Chicken path manipulation stuff. Pathname handling routines is one of the few libraries I spent a lot of time working on for common-scheme, so you may want to look at that (I punted on Windows issues though). PLT also has an extensive pathname handling library, which handles all the Windows weirdness. Your filepath port looks nice. A few comments from what I've skimmed so far: * You're working with lists of characters instead of strings (logical since that maps directly to the Haskell). Working with them allows a convenient functional implementation but can be slow. * Note if you work with substrings rather than character lists, you don't need to (and shouldn't) use utf8-strings, since path names are really just byte-vectors. * The separator inserted for Windows is '\'. Since Windows recognizes '/', would it be better to just use that for all cases? (I don't know, I'm asking the Windows users). * Some people expect path normalization to resolve symlinks. This is a separate operation - both are useful, you should be clear to document that your version doesn't do this. * A concept of the current directoy and resolving relative paths to that is important. * Expanding ~user directories is useful. * Version info is another thing sometimes included in pathname halding (see CL). -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] raw strings
Peter Bex [EMAIL PROTECTED] writes:
On Fri, Oct 10, 2008 at 09:07:59AM +0200, felix winkelmann wrote:
Since escaping backslashes inside string literals can get tedious,
I wondered wether a non-escaping string-syntax might be handy.
Something like:
# ...(doesn't treat backslashes special, with the
exception of \)
Any alternative suggestions?
Don't we already have that, as the heredoc syntax?
Could you give an example in which you need this?
As a wild guess, regular expressions? The syntax of regexps
is really horrible for any language which represents them as
plain strings.
On the other hand something like Gauche's #/.../ or Ruby's
#rx{...} for a regular expression literal would be even more
convenient, and potentially allow for the trailing imsx
modifiers.
--
Alex
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] raw strings
Peter Bex [EMAIL PROTECTED] writes:
On Fri, Oct 10, 2008 at 04:36:02PM +0900, Alex Shinn wrote:
Peter Bex [EMAIL PROTECTED] writes:
Could you give an example in which you need this?
As a wild guess, regular expressions? The syntax of regexps
is really horrible for any language which represents them as
plain strings.
On the other hand something like Gauche's #/.../ or Ruby's
#rx{...} for a regular expression literal would be even more
convenient, and potentially allow for the trailing imsx
modifiers.
We do have the regex-literals egg... Do you propose adding that to
core Chicken?
I wasn't proposing adding anything :)
If Chicken switches to irregex, then we can just use SREs
and be rid of the ugliness of regex syntax forever.
--
Alex
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] raw strings
Tobia Conforto [EMAIL PROTECTED] writes: Alex Shinn wrote: If Chicken switches to irregex, then we can just use SREs and be rid of the ugliness of regex syntax forever. It does look more scalable a syntax, if not less ugly... (word (+ (| alphanum (.-_%))) @ (+ (| alphanum (.-))) . (** 2 4 alpha)) vs. /[EMAIL PROTECTED],4}\b/ Actually, for that particular regexp (or what is intended by it) the development version of irregex has a shorter form: email -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] scheme-complete.el 0.8.3
The new scheme-complete.el supporting Chicken 4.0 is now available: http://synthcode.com/emacs/scheme-complete-0.8.3.el.gz Using/importing now also searches files in the current directory, and fully scans the file for type inferencing information. This is more expensive, so scheme-complete now caches all module exports, making it faster than before. You can optionally enable smart indentation with: (add-hook 'scheme-mode-hook (lambda () (setq lisp-indent-function 'scheme-smart-indent-function))) This is just normal Scheme indentation, but it disables special indentation rules if you locally override a variable. The case that bugs me is that I normally set the indentation for LOOP to behave like LET (as in foof-loop/loopy-loop) but then when you do (let loop (...) ...) that would be wrong. The scheme-smart-indent-function fixes this. As always, comments and bug reports greatly appreciated. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Why is the format egg redundant or unsupported?
felix winkelmann [EMAIL PROTECTED] writes: If this is the case, we can just un-unsupport it. There is format-modular (but is has quite a number of dependencies) and fmt, which is much cooler (but has the odd bug, IIRC). At present there are no known bugs. There were a few bugs in numeric formatting, all of which were fixed within 24 hours. Please let me know if you find any others. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: [gambit-list] Help With Memory
Marc Feeley [EMAIL PROTECTED] writes: I've attached the trace and source code below. The wild difference in performance you get is perhaps due to the old version of Gambit you are using. Can you please try this on your machine with Gambit v4.2.8? Before I do that (because I need to close every application on my machine to have enough memory to compile Gambit), could you try using the same flags I used for Chicken? It's -Ob (or -benchmark-mode), not -b. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] date comparison is very, very, very slow (srfi-19)
Anthony Carrico [EMAIL PROTECTED] writes: I ran into an extreme slowdown with some code that uses dates. I thought this was a complexity issue with sorting, or something like that, but I noticed that it was mainly GC, and traced it to date?. Date comparison is done on julian-days, which are cached in dates, so it is simplest to observe by running date-julian-day over some random dates. Reasons in increasing order of relevance: 1) DATE-JULIAN-DAY is just in general an expensive operation, you want to avoid it in tight loops Hint: a custom comparator that compares dates field-by-field might be faster for sorting. 2) Record accessors in Chicken (and all Scheme implementations to my knowledge) are slow - they're not just memory references, but full procedures, and so every reference to every date field (all 8 of them) generates a generic procedure call with stack checking and all. Hint: if you need to access a lot of fields at once, use MATCH, it's much faster: (match date (($ date nano sec min hour day mon year) ...)) 3) For some reason SRFI-19 uses the numbers egg - did you look at the output of date-julian-day? It's an exact rational in the number of nanoseconds, and the date conversion performs a *lot* of numerical computations. Hint: use EXACT-INEXACT and the FP+, FP/, etc. floating point operators for a huge speedup, e.g. (define (tm:julian-day nanosecond second minute hour day month year tzo) (fp+ (fp- (exact-inexact (tm:encode-julian-day-number day month year)) 0.5) (fp/ (fp+ (exact-inexact (fx+ (fx+ (fx* hour SEC/HR) (fx+ (fx* minute SEC/MIN) second)) (fxneg tzo))) (fp/ (exact-inexact nanosecond) 10.0)) 86400.0))) -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] macro systems and chicken (long)
Alaric == Alaric Snell-Pym [EMAIL PROTECTED] writes: define-record-type (SRFI-9) should be sufficient. The problem is that it is not that easy to construct identifiers in hygienic macros (or it probably is, I don't know, I haven't thought about it very much, yet. There are many loose ends in the moment since so much changes). Alaric It shouldn't be a problem - just (string-symbol Alaric (string-append (symbol-string record-name) - Alaric (symbol-string slot-name))) or whatever as Alaric usual and then don't explicitly rename it, I Alaric reckon. Yes, that works fine, you don't have to give up anything at all moving from unhygienic macros to hygienic macros. They are strictly more powerful. The case of DEFINE-RECORD shouldn't even need any special handling. If you do want to unhygienically build a variable to be bound in a local scope, then you need to tell the body of that scope that the new variable is a free name (see the AIF example). As for DEFINE-MACRO, whether or not you can keep it depends on what you consider the semantics of DEFINE-MACRO to be (and note this is only for backwards compatibility, there's really no reason to keep using it so long as you have the ER- or RSC- transformers). If, as in CL's DEFMACRO, you intend it to operate on and return normal, READ/WRITEable sexprs, then all hygiene information does need to be stripped, and this will cause problems. An alternate view is that the input to and output from DEFINE-MACRO can be an arbitrary sexpr, including possible `identifiers', which may or may not be plain symbols, depending on the use. You can map/fold/destructure the macro body however you want like a normal sexpr, but you have to stick with with identifier API instead of the symbol API: (identifier? obj) (identifier=? env1 id1 env2 id2) (identifier-symbol id) This is what Gauche uses, which is natural because Gauche (I believe) uses Kohlbecker's original coloring algorithm, which colors all the symbols on each expansion. This is simple but slow. The third view is the RSC-/ER- transformer version of DEFINE-MACRO. The syntactic closures algorithm is faster than coloring, but has the downside that any arbitrary sexpr can be wrapped up in a closure. That means any argument to a syntactic closures macro may be a syntax object (or may not be, depending on where and how it was expanded). This is like with SYNTAX-CASE but less consistent - SYNTAX-CASE at least has the advantage of *always* making it hard for you. So, theoretically, a definition like (define-syntax let (er-macro-transformer (lambda (expr rename compare) `((lambda ,(map car (cadr expr)) ,@(cddr expr)) ,@(map cadr (cadr expr)) or equivalently with MATCH destructuring (define-syntax let (er-macro-transformer (lambda (expr rename compare) (match expr ((let ((var val) ...) body ...) `((lambda ,var ,@body) ,@val)) could fail if the (var val) ... list were passed as a syntax object. Though probably this would never happen in practice. So what we probably want is a SYNTAX-MATCH analog to MATCH that can transparently destructure syntax objects... which is really trivial, but then preserving hygiene is another issue :( Anyway, regarding DEFINE-RECORD, I've personally been doing prototyping in Chicken using that and then automatically converting to DEFINE-RECORD-TYPE, simply for portability among other Schemes. You can run the following elisp function inside the DEFINE-RECORD form to perform the expansion. -- Alex (defun expand-define-record () (interactive) (beginning-of-defun) (let* ((sexp (sexp-at-point)) (name (symbol-name (cadr sexp))) (pred (intern (concat name ?))) (make (intern (concat make- name))) (fields (cddr sexp))) (forward-sexp) (insert \n\n(define-record-type ) (insert name) (insert \n ) (insert (with-output-to-string (princ `(,make ,@fields (insert \n ) (insert (symbol-name pred)) (insert \n ) (mapcar #'(lambda (x) (insert (with-output-to-string (princ `(,x ,(intern (concat name - (symbol-name x))) ,(intern (concat name - (symbol-name x) -set!)) (insert \n )) fields) (insert )\n) )) ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] macro systems and chicken (long)
Alaric == Alaric Snell-Pym [EMAIL PROTECTED] writes: Alaric On 17 Apr 2008, at 12:58 pm, Alex Shinn wrote: could fail if the (var val) ... list were passed as a syntax object. Though probably this would never happen in practice. Alaric When *will* it happen in practice? You could force it whenever you want with make-syntactic-closure. I think in this case it's only likely to come about as part of a higher order macro that closes individual parts all the time for safety. Actually, I think if you always use the ER- transformer then you never get anything other than symbols wrapped as syntactic closures, so there would be no problems with destructuring. Alaric Can we not write a define-record as a macro on Alaric top of define-record- type? I've not used Alaric define-record-type much (it seems a bit Alaric overcomplex) so I'm not sure if there's some Alaric fundamental incompatability... Sure, as I said, I was just doing that for portability. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] macro systems and chicken (long)
John == John Cowan [EMAIL PROTECTED] writes: John Alaric Snell-Pym scripsit: Syntax-rules is handy for simple stuff, but I'd hate for it to be the only macro system I had - I like to think of it as a shorthand for a reasonably common case, TBH. John I think quite otherwise: I would never write a John macro in any system other than syntax-rules -- all John other macro systems strike me as standing on a John foundation of quicksand. DEFINE-MACRO is just EVAL. Syntactic closures is just EVAL with the two extra env parameters, one of which the compiler already has (the usage env) and one of which is easy to record. Add in MAKE-SYNTACTIC-CLOSURE, IDENTIFIER? and IDENTIFIER=?, it's maybe a couple hundred lines of code altogether. It's difficult to even imagine a simpler macro system from either an implementation or semantic viewpoint. SYNTAX-RULES is more complicated to implement. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] macro systems and chicken (long)
There seems to be a lot of confusion in the Chicken community, and the Lisp community in general, about the different macro systems, so I thought provide some background information and discussion of the eggs available in Chicken and their uses. --- Background --- There are two completely orthogonal aspects of macro systems - whether they are hygienic or unhygienic, and whether they are low-level or high-level. Low-level means direct manipulation of sexps to produce sexps - you're generating code expressions by hand. High-level means you use some higher abstraction like templating - the underlying processing may or may not make use of sexps at all. Low-level of course offers the most control. High-level has nice benefits such as providing a location in source code for line-number debug info, and easier analysis by other tools like analysers and editors. Neither of these have anything to do with hygiene. Hygiene is a relatively newer concept, so all the old macro systems were either unhygienic + low-level or unhygienic + high-level. defmacro is the former - it's low-level manipulation of sexps. The C preprocessor can be thought of as the weakest, most poorly designed instance of unhygienic high-level macros. It's a templating system without any kind of destructuring, conditionals or polymorphism. Other alternatives like the m4 macro preprocessor and pretty much every assembly preprocessor are more powerful instances of high-level macro systems. Anyway, in the Lisp community we had defmacro, and it was good. You had to be careful to use gensyms, and never to shadow or redefine any core procedures anywhere in your program, but if you stuck to those rules there weren't many problems. Then Scheme came along, and nicely unified the CL namespace mess into a single consistent namespace. The problem was this made conflicts much more likely. It became much more important to be able to automatically avoid problems, without burdening the programmer with mentally keeping track of everything in all lexical scopes. Thus hygiene was born. A good description of why hygiene is necessary can be found at http://community.schemewiki.org/?hygiene-versus-gensym. A very brief time-line: 1986: Kohlbecker - introduced the idea of hygiene, low-level, used an O(n^2) coloring algorithm 1987: Kohlbecker - introduced declare-syntax, high-level, the precursor to syntax-rules 1988: Bawden Rees - Syntactic closures, low-level, faster than Kohlbecker's algorithm 1991: Clinger Rees - Explicit renaming, low-level, based on syntactic-closures but also supports syntax-rules 1992: Dybvig - Syntax-case, primary motivation to remove the distinction between low-level and high-level You can find the papers for these at library.readscheme.org. --- Using The Low-level Systems --- I'm assuming everyone is familiar with syntax-rules, if not there are good tutorials available elsewhere. I'm also going to skip Kohlbecker's original system since it isn't used anywhere. The syntactic closures idea is very simple. Instead of the macro just being passed the expression to transform, it's passed the expression plus environment information. You can think of it like (define-syntax foo (lambda (form usage-environment macro-environment) ...)) which is indeed how it's implemented, but you never use that directly, you use one of the transformer abstractions. The most basic is sc-macro-transformer (sc is for syntactic closures). A good discussion can be found at http://community.schemewiki.org/?syntactic-closures or in the MIT Scheme reference manual http://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/SC-Transformer-Definition.html but basically the idea is you write macros like (define-syntax foo (sc-macro-transformer (lambda (form usage-environment) ...))) You can then manipulate FORM as a normal sexp just like in defmacro. The resulting sexp is then interpreted in the macro's syntactic environment. To make parts of FORM refer to their bindings in the calling environment, you need to wrap them in syntactic-closures with the USAGE-ENVIRONMENT parameter. As an example, (define-syntax swap! (sc-macro-transformer (lambda (form env) (let ((a (make-syntactic-closure env '() (cadr form))) (b (make-syntactic-closure env '() (caddr form `(let ((value ,a)) (set! ,a ,b) (set! ,b value)) FORM is the full form (swap! var1 var2), so we're binding A to var1 and B to var2, in the context of the usage environment. The other identifiers in the returned sexp (LET, VALUE and SET!) all refer to the original macro environment, so even if they had been locally shadowed in the usage environment, this will still work. The second argument to make-syntactic-closure (just '() above) is used when you want to deliberately break hygiene. See the other links for
[Chicken-users] compiled syntax modules
I've just checked in a new version of riaxpander with initial support for compiling syntax extensions. Previously, any file containing macros that you wanted to export you would mark as (syntax) in the .setup file, and just install the file as a .scm without compiling it. Now, when using riaxpander, you have the option of compiling the file with the -Dcompile-syntax option and it works the same way (for all macros, including syntax-rules, explicit-renaming, etc.). There's an example in the wiki documentation. The compiled syntax can only be currently used only with riaxpander (though I'm considering adding support so that it can be loaded from the syntactic-closures egg as well). Because of this, you probably don't want to make published eggs compiled, since it removes the option of using alternate macro systems. It can be useful for private code, though. The effect of this is to speed load-time, and for complex macros speed expansion (compile) time. It won't make any resulting code any faster, it just speeds up the development process. It's also essential if you want to distribute proprietary macro code, and is the first step towards a proper module system. Even if you don't compile any syntax yourself, users of riaxpander will notice a huge difference in that riaxpander now loads *instantly* (because it of course compiles all its own syntax), whereas all the other hygienic macro systems take forever and a day to load. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] bug and potential fix for numbers egg
$ csi -R numbers
...
#;1 (= 0.1 (/ 1 10))
#f
#;2 (= 0.1 (exact-inexact (/ 1 10)))
#f
#;3 (exact-inexact (/ 1 10))
0.1
Note that both equalities hold when not using the numbers
egg. Exact = comparisons on floating point numbers are
rare, but this is just a symptom of a more general issue
which was triggering a 1 in 10,000 bug in the new set of fmt
formatting tests.
The problem is that numbers uses the function mpq_get_d for
converting from a rational to a double, but the description
of that function is:
Function: double mpq_get_d (mpq_t op)
Convert op to a double, truncating if necessary
(ie. rounding towards zero).
So it deliberately loses precision by truncating instead of
rounding. There is no function to do the same with rounding
in GMP.
As a potential workaround, I've attached a patch which first
checks if both the numerator and denominator fit within a
long (there's no direct way to check if they fit in a
double), and if so just uses the straight C operations
(double) numerator / (double) denominator
which is more accurate than what GMP does!
If they don't fit we fall back on mpq_get_d, but in that
case we're going to lose precision whether we want to or not
so it's not a big deal.
The attached patch implements this, and passes the above
test, the numbers egg tests, and the fmt egg tests, but I'd
prefer someone more familiar with GMP look at it before
checking it in.
--
Alex
Index: numbers-c.c
===
--- numbers-c.c (revision 9881)
+++ numbers-c.c (working copy)
@@ -55,10 +55,23 @@
}
+static double
+mpq_get_d_accurately(mpq_t rat)
+{
+ mpz_t *num, *den;
+ num = mpq_numref(rat);
+ den = mpq_denref(rat);
+ if (mpz_fits_slong_p(*num) mpz_fits_slong_p(*den)) {
+return (double) (mpz_get_d(*num) / mpz_get_d(*den));
+ } else {
+return mpq_get_d(rat);
+ }
+}
+
static C_word
rat_to_flo(C_word **p, C_word n, C_word rat)
{
- return C_flonum(p, mpq_get_d(rat_of(rat)));
+ return C_flonum(p, mpq_get_d_accurately(rat_of(rat)));
}
@@ -1189,7 +1202,7 @@
return C_mk_bool(C_flonum_magnitude(x) == C_flonum_magnitude(y));
case C_fix(RAT):
- return C_mk_bool(C_flonum_magnitude(x) == mpq_get_d(rat_of(y)));
+ return C_mk_bool(C_flonum_magnitude(x) ==
mpq_get_d_accurately(rat_of(y)));
default: return C_SCHEME_FALSE;
}
@@ -1210,7 +1223,7 @@
case C_fix(RAT):
switch(ty) {
case C_fix(FLO):
- return C_mk_bool(mpq_get_d(rx) == C_flonum_magnitude(y));
+ return C_mk_bool(mpq_get_d_accurately(rx) == C_flonum_magnitude(y));
case C_fix(RAT):
{ defrat(ry, y);
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] bug and potential fix for numbers egg
John == John Cowan [EMAIL PROTECTED] writes: John Alex Shinn scripsit: As a potential workaround, I've attached a patch which first checks if both the numerator and denominator fit within a long (there's no direct way to check if they fit in a double), and if so just uses the straight C operations (double) numerator / (double) denominator which is more accurate than what GMP does! John I think that's the right general idea, but long John can be 32 bits, and often is; I think you need to John use a system-dependent type that can be guaranteed John to be 64 bits (does Chicken have one?). Well, we're restricted to the GMP API, which gives us mpz_fits_slong_p and mpz_get_d but no mpz_fits_double_p or mpz_fits_long_long_p. So I believe this is the most accurate we can hope for in a straightforward manner. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: arithmetic-shift bug
Alex == Alex Shinn [EMAIL PROTECTED] writes: Alex I believe this is from a relatively recent change, Alex since it's the cause of an error in the fmt egg Alex which previously passed. Sorry, I had been testing on a 64-bit machine before so this may in fact be a long-standing bug. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ditching syntax-case modules for the utf8 egg
Tobia == Tobia Conforto [EMAIL PROTECTED] writes: Tobia Graham Fawcett wrote: Here's another thought. It seems to me that if we were to represent strings as composite values, e.g. a two-slot record whose first slot is an encoding (the symbol 'utf8, or #f for 'byte' encoding), and whose second slot contains the string data, then the various string functions could dispatch on the type, and there would be no need to monkey-patch core string functions to get the desired semantics. Tobia This is more or less how other languages, such as Tobia Python, solved the issue. Two kinds of strings, Tobia byte and unicode, and overloading a few string Tobia operations to have a slightly different meaning Tobia when called on either, computing byte length Tobia vs. character length. I keep trying to say, this is *not* the issue! :) The entire problem revolves around adding Unicode support as an option, without modifying the core. *If* we allow ourselves to modify the core, then there is no problem at all, and we can just copy the utf8 egg code over the existing string procedures, and add in some procedures for byte-level access. That's just changing the procedures used to access strings. Changing the fundamental string representation is a more substantial change by an order of magnitude, involving changes to the core compiler and the FFI among other things. You're just proposing things that would cause even more problems :) -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ditching syntax-case modules for the utf8 egg
John == John Cowan [EMAIL PROTECTED] writes: John felix winkelmann scripsit: A real module system would solve all these problems cleanly. John It wouldn't solve the data-punning problem. As John long as the same object can be seen one way by one John module and another way by another, problems will John continue to be endemic. To fix that, we need two John run-time types, which I hereby dub restricted and John unrestricted strings. Why do we need this? That's not rhetorical, I'd like to hear of any use cases where you think a problem could arise. To me the bigger problem with a module-based solution is the complete separation of all string processing modules into those that are utf8-aware, and those that aren't. A fork which extends to other modules which use string-processing modules, i.e. duplicate copies of most code. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ditching syntax-case modules for the utf8 egg
Graham == Graham Fawcett [EMAIL PROTECTED] writes: Graham On Tue, Mar 18, 2008 at 12:22 PM, John Cowan [EMAIL PROTECTED] wrote: It wouldn't solve the data-punning problem. As long as the same object can be seen one way by one module and another way by another, problems will continue to be endemic. To fix that, we need two run-time types, which I hereby dub restricted and unrestricted strings. Graham Just curious, whence the 'restricted' Graham terminology? I would have thought 'utf8 and Graham raw/byte strings' since that's the practical Graham implication. Gauche uses `complete' and `incomplete' strings. Core string operations work on both where that is meaningful, so you can use STRING-APPEND on mixed complete and incomplete strings, and the result becomes incomplete (it's sort of like inexact contagion in that way). Gauche was the first Scheme implementation with Unicode support, so it bears looking at if you haven't already. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ditching syntax-case modules for the utf8 egg
Felix == felix winkelmann [EMAIL PROTECTED] writes: Felix On Sun, Mar 16, 2008 at 8:04 AM, Alex Shinn [EMAIL PROTECTED] wrote: I actually thought the change you introduced didn't really inline most of the operators but referenced a static table, and that this would occur regardless of whether the procedure was in operator position or not. Felix No, integration only happens in operator Felix position. Well, that's easy enough to change. Felix But won't syntax-case's module system rewrite the Felix variable reference, regardless whether the Felix identifier is in operator position or not? Yes. I see what you're saying though - importing into the top-level doesn't actually mutate the top-level bindings of the same name, so it won't be the same. Except for subsequently LOADed or EVALed code. Yet another compiled code vs. interpreted code difference. Yet another reason never to touch syntax-case modules :( Anyway, I never used utf8 myself before (I always just used utf8-lolevel directly, but that's really not recommended). I will likely not use it in the future either. The semantic differences can be worked around between byte-strings and utf8-strings, but because there is an abundance of code in many libraries that need to refer to string indices it's pretty much impossible to integrate any kind of code that changes the meaning of those indices. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ditching syntax-case modules for the utf8 egg
Graham == Graham Fawcett [EMAIL PROTECTED] writes: Graham On Mon, Mar 17, 2008 at 11:22 AM, Kon Lovett [EMAIL PROTECTED] wrote: Graham The Factor language borrowed from Larceny a Graham clever mechanism for representing Unicode Graham strings efficiently. Perhaps such a system is Graham feasible for Chicken, and might eliminate some Graham of these issues (at the cost of distancing our Graham string type a bit more from C char arrays): Graham http://factor-language.blogspot.com/2008_01_01_archive.html Graham The new representation is quite clever, and Graham comes from Larceny Scheme. The idea is that Graham strings are ASCII strings, but have an extra Graham slot pointing to an 'auxiliary vector'. This only adds news issues, and solves none of the old ones. The representation itself is interesting, though it may in fact be a pessimisation in many cases (utf8 is about the fastest approach for parsing and regex matching, which are the string operations where speed is the biggest issue to begin with). The problems we're having aren't even about string representation though, they're about the semantics of the string operations themselves. Are the string indices byte positions or character positions? Different libraries disagree. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ditching syntax-case modules for the utf8 egg
Kon == Kon Lovett [EMAIL PROTECTED] writes: Kon Summary: I want a byte-string API. I want string Kon integrations. I want global UTF8 strings. The only way this can happen is to push the UTF8 handling into the core of Chicken itself. Integration vs. modules are just different degrees of the fundamental problem that different libraries apply different meanings to string indices, and sooner or later these will conflict. Pushing UTF8 into the core would be easy, and would be much less code than currently in the utf8 egg, since 90% of what that egg does is just wrap existing procedures, translating the meaning of the string indices. However it would be contrary to Chicken's goal of keeping a minimal core with extensions built on top. As it is, if you want Unicode handling, the only way to do it would be with separate modules, and forked versions of every egg that does any string processing. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ditching syntax-case modules for the utf8 egg
Felix == Felix Winkelmann [EMAIL PROTECTED] writes: Felix Alex, what happens if I pass string operators as first Felix class values? These don't get inlined. What Felix happens now? I actually thought the change you introduced didn't really inline most of the operators but referenced a static table, and that this would occur regardless of whether the procedure was in operator position or not. If that's not the case, what happens is the same thing that happened before when you imported utf8 into the top-level - and there have been no bug reports about that yet. That may have more to do with the fact that the utf8 egg may never have gotten much usage, but if that's the case it's silly to worry about compatibility. Anyway, the places where it can break (treating strings like byte-strings) are easy to detect and fix. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ditching syntax-case modules for the utf8 egg
Kon == Kon Lovett [EMAIL PROTECTED] writes: Kon On Mar 15, 2008, at 9:33 AM, Felix Winkelmann wrote: Kon Is this a char-string issue or a byte-string Kon issue? When the source ...string... is a string Kon of ASCII non-nul char then there should be no Kon problem w/ the utf8 egg overriding the string Kon operators. The problem comes when the source ... Kon is actually a byte-string. Kon I am uncomfortable with that particular Chicken Kon idiom. Kon How about moving the utf8 egg's Kon byte-string-srfi-13.scm byte- string.scm into Kon the core? Then when a byte-string use is intended Kon everyone will know. That's a good idea, but they don't need to be moved into the core, we can just split them out into a separate egg. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ditching syntax-case modules for the utf8 egg
Kon == Kon Lovett [EMAIL PROTECTED] writes:
Kon Is this a char-string issue or a byte-string
Kon issue? When the source ...string... is a string
Kon of ASCII non-nul char then there should be no
Kon problem w/ the utf8 egg overriding the string
Kon operators. The problem comes when the source ...
Kon is actually a byte-string.
There are other places things can go wrong, of course. If
you use STRING-{SEARCH,MATCH}-POSITIONS, in code that's not
utf8-aware, and any of the match positions come after wide
characters in the string, then it will break if some other
egg has loaded utf8.
This just makes me sad. The whole concept of referencing
strings by index is broken.
--
Alex
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Hang problem with the http egg.
Hans == Hans Bulfone [EMAIL PROTECTED] writes: Hans that said, i think i really am a quite humble Hans person :) By saying that your humble status has been revoked! :P -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ditching syntax-case modules for the utf8 egg
Robin == Robin Lee Powell [EMAIL PROTECTED] writes: Robin Replying to very old mail. :) Very old, but still relevant, and I was actually about to bring this up again myself. I have the new code ready to check in (complete with Unicode 5.0 updates), but want to reconfirm. Robin On Thu, Jun 28, 2007 at 12:25:54PM +0900, Alex Shinn wrote: I'm considering changing the utf8 egg to no longer use syntax-case modules, so that it would work like the numbers egg. [...] Robin Perhaps I'm missing something, but I *really* Robin don't like the idea of having to manage my own Robin personal versions of spiffy and all of its Robin dependencies just to get utf8 support. That Robin seems really sub-optimal. I'm not entirely sure why you think spiffy would need two versions. First, are you referring to the syntax-case version of utf8 or the new version that would globally redefine string operations? Second, does spiffy itself do any operations on strings where it would matter whether the strings were utf8 or not? I somehow doubt this. I could easily see individual extensions or servlets needing this behavior, but in either the old or the new approach those extensions could just use utf8 themselves, without any need to change spiffy. I think possibly the utf8 string representation may be confusing some people though. Basically, when using the utf8 egg, all Chicken strings are considered to be utf8 encoded. However, code compiled with the default integrations will treat them essentially as byte-vectors, ignoring utf8 semantics. For parsing URI's, or handling pathnames, or most common tasks that spiffy would do, *either* assumption works. Individual servlets could then be compiled without the default integrations, and they would see the utf8 semantics if the utf8 egg were used. Both types of libraries can co-exist, and they would all share the same string representation. This is similar to how the numbers egg works - some code is compiled with (declare fixnum), assuming all numbers are small integers, and some code references the global bindings for arithmetic operations, which can be extended by eggs like numbers. Subtle errors can result, e.g. code may work with the numbers egg but break without (or vice versa) because as numbers get large they become inexact without the numbers egg, but stay exact with it (as bignums), but these can be avoided manually. Similar may happen using utf8 globally, but it's convenient and some people want it - it lets you turn on Unicode support optionally and globally for all of Chicken, while allowing optimizations for some individual eggs. But I want to ask again, do people want this, and is it OK to break compatibility in the current utf8 egg? Or should we possibly wait to see about the new module system? -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] UTF8
Jean-Philippe Theberge [EMAIL PROTECTED] writes: Where is match defined? It's included by default, but you need to (use matchable) when using syntax-case or any of the other hygienic macro systems. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] macrolet
Lui == Lui Fungsin [EMAIL PROTECTED] writes: Lui Hi, Is there a macrolet (CL style old school Lui lexically scoped macro) for chicken? It can be defined in any of syntax-case, syntactic-closures or riaxpander, but you really, really don't want to. Nesting hygienic macros and unhygienic macros just doesn't work. You can still get away with simple, top-level unhygienic macros that don't include any code body, though, like define-record. sc-macro-transformer (available in syntactic-closures and riaxpander), is a lot like CL-style macros, and works with let-syntax. Lui I need to define macro that captures some of the Lui lexical variables and I cannot use let-syntax Lui because Lui - riaxpander currenlty requires case-insensible Lui mode, and that mode breaks a few eggs that I'm Lui using (e.g. ssax) There's no reason for this - it needs to be compiled with csc -i, but then you should be able to load it with case-sensitive Chicken. I've removed that restriction in my local copy and will check it in later. Lui - riaxpander doesn't yet support #!optional , Lui #!key, etc. which i used a lot in my code. I'll add these shortly as well. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] google summer of code
Alaric == Alaric Snell-Pym [EMAIL PROTECTED] writes: Alaric I'm also keen on a proper library/module system, Alaric though. I'd like to be able to use multiple Alaric macro systems in the same source file, for a Alaric start. So something where chicken itself has a Alaric notion of a macro environment, and macro systems Alaric just register closures in an alist or whatever Alaric that (define-syntax ...) dispatches on to Alaric convert whatever the user supplies into a Alaric closure that rewrites syntax objects, then when Alaric the macro is invoked, that closure can be Alaric applied to perform the rewrite. Then the module Alaric system needs to know that there are two Alaric environments - values and syntax - to expose Alaric from modules and import into places, and all Alaric should be well. Surely? Actually, that would be far more work than I'd be interested in. The different macro systems all have their own representations of hygiene information, and getting them all to work together would be a pain. What I would probably end up doing is choosing a single macro system to be required for the module system. Probably riaxpander because Taylor Campbell will actively support it and it already handles syntax-rules, syntactic-closures and explicit renaming. Implementing syntax-case on top of it wouldn't be much work either if people really, honestly felt they wanted that (except identifier-syntax - it would be easy enough for someone else to add but I couldn't bring myself to dirty the macro semantics so badly). Though if people want syntax-case I'd like some rationale before working on it, and clear reasons as to why they don't like the more straightforward alternatives. Again, interoperability with non-module eggs is an important goal, so this wouldn't affect any existing eggs. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] DBI
Tobia == Tobia Conforto [EMAIL PROTECTED] writes: Tobia Alex Shinn wrote: The biggest issue I see with the sql egg right now is it currently hard-codes all values, generating a new SQL expression every time. You want it to be able to represent placeholder values (named or just with a ?) ... It makes more sense to integrate the SQL generation with the backends from the start. Tobia What you propose might get really complex. [...] Tobia The DBI should just provide a standard way to Tobia compile prepared statements, so that an improved Tobia sql egg could use prepared statements across all Tobia DBs that support it. IMHO the key is lessening Tobia the burden on the backend writer, while providing Tobia most features of modern DBs in a consistent Tobia interface. I'd have to disagree, and say that the key, as with any programming library, is lessening the burden on the user. Do the hard work once so it doesn't have to be duplicated. Every other DBI library for every language I've ever seen allows prepared statements. The issue isn't just with the actual query string generated either. We may want the high-level interface to always allow the LIMIT and OFFSET keywords to page results, even if the backend doesn't support it, by emulating it on the client side. Tobia Uhh, still more burden on the backend writer? I Tobia don't like the sound of it. Besides, if you need Tobia limit and offset, you might as well upgrade to Tobia another RDBMS. ROFL! Tell Oracle users to upgrade to another RDBMS :) Oracle has no LIMIT or OFFSET - there's a trick you can use to make a nested SELECT and filter by row-number, but usually it's recommended to just return a cursor and let the client read and discard the initial unneeded rows then only read the remaining LIMIT rows. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] DBI
Tobia == Tobia Conforto [EMAIL PROTECTED] writes: Tobia What's wrong with the sql egg? Can't we just use Tobia that, maybe improve it a bit? Sure, I didn't mean to rule that out. The biggest issue I see with the sql egg right now is it currently hard-codes all values, generating a new SQL expression every time. You want it to be able to represent placeholder values (named or just with a ? as in Perl's DBI) allowing the backends to cache the SQL expression and apply it to different data. However, different backends represent this (and various other extensions we'll eventually want) in different ways. SQL could just generate a standard syntax that all the backends would have to support, but then they'd be reparsing the SQL string we just generated and then putting it back together in their own way. It makes more sense to integrate the SQL generation with the backends from the start. The issue isn't just with the actual query string generated either. We may want the high-level interface to always allow the LIMIT and OFFSET keywords to page results, even if the backend doesn't support it, by emulating it on the client side. This would have to be handled as a combination of query string generation and result set processing. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Continuation Fest 2008
Ivan == Ivan Raikov [EMAIL PROTECTED] writes: IvanAre any Chicken Schemers thinking about attending the Ivan Continuation Fest in Tokyo that was just announced on Ivan comp.lang.scheme? I will probably be in the area that entire Ivan weekend, if anyone wants to have a Chicken meetup. I'll most likely show up, at least for the day if not the whole weekend. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Stupid backquote/unquote question
Hans Nowak [EMAIL PROTECTED] writes: #;1 (define magic 42) #;2 (define s '(foo bar ,magic)) [...] The following doesn't work: #;4 `s s #;5 `,s (foo bar (unquote magic)) ...and I understand *why* they don't work, but I can't figure out how to take s and transform it into (foo bar 42). quasiquote is syntax - it happens at compile-time, so to apply it to dynamic data at runtime you need to call EVAL: (eval (list 'quasiquote s)) ; = (foo bar 42) EVAL may be overkill for something this simple - an alternative would be to write a simple substitution function: (use lolevel) (define (replace-unquotes x) (if (not (pair? x)) x (if (and (pair? (cdr x)) (null? (cddr x)) (eq? 'unquote (car x))) (global-ref (cadr x)) (cons (replace-unquotes (car x)) (replace-unquotes (cdr x)) (replace-unquotes s) ; = (foo bar 42) You'd of course have to extend this if you want to handle nested quasiquotes and unquote-splicing. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Comprehensive documentation rewrite
Ivan == Ivan Raikov [EMAIL PROTECTED] writes: Ivan Well, it is simply not true. Source code with a non-BSD Ivan license that gets imported as an egg does not magically Ivan become BSD-licensed. There are also many eggs that are Ivan actively in use that are not licensed under the BSD. arbiter Relax! :) All he said was most eggs are BSD. Currently Eggs Unlimited lists 202 eggs as BSD, which is more than half, so Elf's statement is true. Which is not to say BSD is better or more encouraged by Chicken in any way. /arbiter To get back to the point, eggs that simply list themselves as (L)GPL should specify the version. The listing on Eggs Unlimited is intended, I think, to refer to the general style of license, so just plain GPL may be fine there, but some may want to argue GPLv3 is sufficiently different to warrant separating. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] ANN: scheme-complete.el 0.8
scheme-complete.el 0.8 is now available at http://synthcode.com/emacs/scheme-complete.el.gz This is a bugfix release, including several parsing fixes for unbalanced parenthesis (thanks to Kazushi NODA), better handling of dotted lambda lists, and proper completion of absolute pathnames. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: ANN: hato 0.3.5
Alex == Alex Shinn [EMAIL PROTECTED] writes: Alex Thanks to the tremendous patience of Felix, who had in Alex pretty much every way the opposite setup as mine, hato 0.3.5 Alex is now available with numerous bugfixes. Sorry, the file permissions in the tarball were broken. I've rewritten the Makefile to no longer use darcs dist so it's working now. Also, the docs have been updated to note that you need the numbers egg, and also optionally openssl and stty (these are autoloaded if they're needed). -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] hato 0.3.1
... is available at http://synthcode.com/scheme/hato/hato-0.3.1.tar.gz There were some really careless bugs in the previous release such that it wouldn't always work right if you didn't have a ~/.hato/filter file (it will now properly deliver to the local mail-spool in this case), and also the alias: sources had been untested. There are also new filters available for date processing: BEFORE, ON, SINCE, SENTBEFORE, SENTON, and SENTSINCE, so for example you can archive old messages into a separate folder with: hato-fetch --delete -f before=`date -d 'now - 1 year'` \ ~/Mail/my-list ~/Mail/archives/my-list ... at least assuming an English locale for the date(1) output - you can also just use -f before=20070131 or whatever. These date filters round to the nearest day for compatibility with IMAP. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] multiple values in chicken
I really, really, loathe multiple values. I've argued the reasons countless times before, and I'm not in the mood to do it again. What I will do is point out is that the most natural (though not only) alternative, just returning a first-class list, already has just as concise syntax if you use MATCH on the result, and for Chicken specifically is much faster. In general, unless the compiler natively takes MV into consideration and goes through the effort to place them on the stack (a complication which can make other optimizations more difficult, and which few compilers do anyway), then LIST is usually at least as fast as VALUES. Specifically, if you have (receive (foo bar) (values baz qux) ...) then you can replace this with (match (list baz qux) ((foo bar) ...)) or you can abbreviate it with a BIND macro like the one in the benchmarks below: (bind (foo bar) (list baz qux) ...) How do the runtimes compare? VALUES -- 35.949 seconds elapsed 0.4 seconds in (major) GC 0 mutations 760 minor GCs 960 major GCs LIST 2.17 seconds elapsed 7.e-03 seconds in (major) GC 0 mutations 3266 minor GCs 8 major GCs That's right, multiple values are more than 10x SLOWER than just using a list in Chicken. This is partly because MV has to perform more checks and partly because Chicken has optimized lists very well (as any good Lisp compiler should). You can even shave off a few more milliseconds in the list case by matching (foo bar . _). -- Alex (define (car+cdr/values pair) (values (car pair) (cdr pair))) (print VALUES --) (gc) (time (do ((i 1 (+ i 1))) ((= i 1000)) (receive (kar kdr) (car+cdr/values '(1 . 2)) (+ kar kdr (define (car+cdr/list pair) (list (car pair) (cdr pair))) (define-macro (bind pat expr . body) `(match ,expr (,pat ,@body))) (print LIST ) (gc) (time (do ((i 1 (+ i 1))) ((= i 1000)) (bind (kar kdr) (car+cdr/list '(1 . 2)) (+ kar kdr ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Hash table mystery
JP == Jean-Philippe Theberge [EMAIL PROTECTED] writes: JP (define BP (make-hash-table 500)) There's your problem. The parameters for MAKE-HASH-TABLE are: (make-hash-table [eq-fn hash-fn init-size]) ... so the first argument, if provided, should be a function to test if two keys are equal (it defaults to EQUAL?). The reason it doesn't signal an error right away is because if the keys hash to different values, then they fall into fresh, empty buckets and there's no other elements to compare against. hype Note that if you use scheme-complete.el and enable eldoc-mode, then the above type signature for MAKE-HASH-TABLE would be shown in the minibuffer as you were typing so you could see the mistake immediately. /hype -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-hosted stalin
On Jan 23, 2008 9:09 AM, John Cowan [EMAIL PROTECTED] wrote: felix winkelmann scripsit: Compilation of Scheme with Stalin takes extremely long. The chicken-compiled Stallin is smaller and doesn't stress gcc so much, but is (naturally) even slower than the original Stalin, which means slow compiling Scheme to C. Well, that's what I expected. But then what is the meaning of saying that there are faster turnaround times for chicken-stalin than for native stalin? I think the relevant point is that there are faster turnaround times for hacking Stalin itself. This is very important, because Stalin is minimal to the point of being unusable, and so a lot of hacking is needed. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] ANN: scheme-complete.el 0.5
scheme-complete provides intelligent tab-completion for Emacs scheme modes, with lexically aware detection of symbols and simple type-inferencing, and optional eldoc support. The new version supports internal defines, infers types more often, and uses smarter parsing, avoiding slurping sexps whenever possible. scheme-complete can be found at http://synthcode.com/emacs/scheme-complete.el.gz with instructions at the top of the file. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: Debian slander?
On Dec 28, 2007 10:15 AM, John Cowan [EMAIL PROTECTED] wrote: Saying that Chicken is R5RS-compliant is simply false advertising. It isn't. There is a whole section in the manual on deviations from the standard. It's good enough compliant. $ csi -case-insensitive -R numbers -R syntactic-closures That addresses the major deviations (although the full numeric tower is'nt even required for a conformant implementation). The other deviations seem to be backwards-compatible extensions or just clarifications of compiler limitations that one wouldn't consider breaking conformancy. The EVAL limitation is the only thing I consider true non-conformance, and that can be handled with the sandbox egg. Oh, and transcript-on and transcript-off, but no one cares about them. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: Debian slander?
On Dec 28, 2007 11:47 AM, John Cowan [EMAIL PROTECTED] wrote: There is letrec as letrec*, This is a perfectly legal extension - the exact R5RS text says that it is an error to refer to one of the other variables. So if you do that demons might fly out of your nose, or it may magically behave like letrec*. The R6RS text is more precise and explicitly requires a distinction, but Chicken is not R6RS. no read/write invariance for numbers, For inexact numbers, which are inexact, and R5RS makes no claims about how inexact , and they needn't be supported at all. no bignum literals in the compiler even with the numeric egg. A fully conformant implementation doesn't need to support bignums at all. There is also the limit on passed arguments, but I don't know if that still applies in the new apply-hack world. Where does R5RS say proceures must support an unlimited number of arguments? That's just a standard compiler limitation - if nothing else you're always limited by available memory. It doesn't have anything to do with standards conformance. I don't mean to nitpick, but there are plenty of other Schemes that call themselves R5RS with similar extensions. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: Debian slander?
On Dec 23, 2007 5:34 PM, John Cowan [EMAIL PROTECTED] wrote: felix winkelmann scripsit: Chicken's interpreter is not strongly performant, but does provide strong debugging facilities. I'd remove that last sentence above. I think it's true: if you want a fast interpreter, you wouldn't use csi, would you? No use implying that Chicken is something it isn't. It's misleading because it's beside the point. When you need speed, you use the compiler. When you don't need speed, any interpreter will do, and the fact that csi is on the slow end of something that is already slow doesn't mean much. The cases where EVAL speed really matter are quite rare so it's confusing to mention them in such a short description. Most newcomers will be used to either entirely compiled or entirely interpreted languages, and if you say that Chicken's EVAL is slow they'll likely assume the language as a whole is slow. I also have issues with the second part of that sentence - I would not consider csi's debugging facilities strong compared to other Scheme implementations (it's about average, and I think we need to raise the bar on Scheme debuggers in general). -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] how to use define-macro to...
On Dec 20, 2007 8:35 PM, minh thu [EMAIL PROTECTED] wrote: 1/ I'd like to repeat this code for a lot of operators (not just + as in the following). (define-syntax shadow (syntax-rules () ((shadow op old-op) (begin (define old-op op) (define (op a b) (if (or (instance-of? a behavior) (instance-of b? behavior)) (create-behavior (list a b) old-op) (old-op a b))) (shadow + old+) (shadow - old-) (shadow * old*) ... etc. That's if you want the old operator visible - you could also use a temp. 2/ But it's boring; I would prefer have a debug macro instead : (define-syntax eval-when-defined (syntax-rules () ((eval-when-defined sym expr) (cond-expand (sym expr) (else (noop)) (define-syntax debug (syntax-rules () ((debug expr) (eval-when-defined debug-behaviors expr define-macro is fundamentally broken. And for these types of macros syntax-rules is actually simpler - you're just dealing with templates. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: Question SRFI-56
On Dec 21, 2007 5:04 AM, Siegfried Gonzi [EMAIL PROTECTED] wrote: I downloade numbers and srfi-56. But I get the following error when using srfi-56 and there is no specific comment in the source code: == siegfried-gonzis-macbook:test sgonzi$ csc srfi-56-test.scm That should be csi -R syntax-case -R numbers srfi-56-test.scm (or -R syntactic-closures instead of -R syntax-case). Bigloo failed the tests because it doesn't support bignums - because of that I believe it had the worse result of any implementation. SRFI-56 did go through a peer review - that's what the SRFI process is. The reason for the withdrawal was explained on the list. As a library of binary parsing utilities it was fine, but I felt it failed to adequately address the distinction between binary and textual files, and I didn't want to encourage people to build on a non-solid foundation. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Re: UTF-8 support
On Dec 13, 2007 11:32 PM, Tobia Conforto [EMAIL PROTECTED] wrote: Can you (or anybody else) give an example of different behaviour with the option turned on and off? I did a couple of tests and can't see any difference, but I admit I have yet to look at the source code. The only two differences are 1) . matches a full utf-8 character with the option on, whereas with the option off it would match one byte of a utf-8 char (thus in Zbigniew's example you get the two bytes \316 and \273 instead of the λ) 2) character classes treat the characters as utf-8 encoded with the option on, and as a sequences of bytes with it off 1 is surprisingly rare - you usually use .* or .+, which turn out to be identical with the option on or off. 2 is only common in non-English linguistic applications. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] chicken lottery!
Ladies, gentlemen and other, we've reached 350 eggs, which means some lucky contributor is going to be the proud owner of their very own Chicken T-shirt! This time we're inviting you all to witness the choosing live. At midnight UTC this Friday the 14th (7pm Thursday night US Eastern Standard time, 4pm Pacific) anyone interested should join #nethack on irc.freenode.net, where a resident bot will be asked to make a random die roll to determine the winner. Based on the current contributors from http://chicken.wiki.br/the-chicken-lottery we've made the following table Roll #eggs Name 1-23 23Ivan Raikov 24-32 9Arto Bendiken 33-40 8Tony Sidaway 41-43 3Will Farr 44-46 3Ben Kurtz 47-49 3Vo minh Thu 50-52 3Shawn Wagner 53-54 2Taylor Campbell 55-56 2Naruto Canada 57-58 2Mario Domenech Goulart 59-60 2Ivan Shmakov 61-62 2Alaric Blagrave Snell-Pym 63 1Peter Bex 64 1Terrence Brannon 65 1Hans Bulfone 66 1Certainty 67 1Thomas Chust 68 1Sven Hartrumpf 69 1Tony and Martin Sidaway 70 1Alex Sandro Queiroz e Silva 71 1Jean-Philippe Theberge 72 1Zbigniew 73*** re-roll twice! *** Duplicates (including 73) are ignored, so at most 2 people can get a shirt. In the event that 69 is rolled, the joint developers Tony and Martin Sidaway will be put into a steel cage match to fight for the death for the right to claim the T-shirt. Or possibly a chicken-wire cage. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ANN: scheme-complete.el 0.3
On Nov 14, 2007 3:51 PM, felix winkelmann [EMAIL PROTECTED] wrote: Thanks! Is there a way to use it even if chicken is not installed in /usr/local? Fixed and uploaded as 0.4. It also supports the CHICKEN_REPOSITORY env var, and for Gauche now supports the GAUCHE_LOAD_PATH. There are still a lot of limitations (and always will be, since it's dealing with potentially incomplete code), but is still quite nice, and at the current version I don't think will break or do anything unexpected to you. And even without any module system support it knows R5RS plus the top-level definitions of the file you're working in plus the current lexical scope. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ANN: scheme-complete.el 0.3
On Nov 13, 2007 3:39 PM, felix winkelmann [EMAIL PROTECTED] wrote: On Nov 13, 2007 7:05 AM, Alex Shinn [EMAIL PROTECTED] wrote: A new release 0.3 of scheme-complete.el is available at http://synthcode.com/emacs/scheme-complete.el Hm... Server down? It's back now. Try http://synthcode.com/emacs/scheme-complete.el.gz for a faster download. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] ANN: scheme-complete.el 0.3
On Nov 14, 2007 3:51 PM, felix winkelmann [EMAIL PROTECTED] wrote: Thanks! Is there a way to use it even if chicken is not installed in /usr/local? You can use it, it just won't know about Chicken's non-standard modules. I introduced a bug at the last minute, I'll make a new release shortly with a fix, and which also searches some common paths for Chicken and Gauche. I'd prefer to automate things for now, though I may add some defcustoms later. -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
