I made a few changes to Brad's excellent char-set-lib and string-lib libraries. These versions can be used with gsi, and you don't have to compile them inside the gambit source tree. `gsc -dynamic' should do the trick. I also fixed a copy of small bugs --- hopefully I didn't introduce too many in their place ;-) I haven't tested these rigorously though. Gambit seems like an awfully nice Scheme, but as distributed it is too spartan for my needs. I'd like to help where I can with porting useful libraries. Regards, Ben
On Apr 6, 2005, at 10:47 PM, ben@fuhok.net wrote:
I also fixed a copy of small bugs --- hopefully I didn't introduce too many in their place ;-) I haven't tested these rigorously though.
It seems to be a bit difficult to extract the bug fixes (as opposed to the other changes) from your code. Could you list them separately? I'd like to fix my versions of the libraries. BTW, the complicated way I defined my error-checking, etc., was to make it more compatible with built-in error checking in the Gambit runtime in the hope that these libraries could someday be integrated in the runtime (either officially or de-facto). Brad
On Thu, Apr 07, 2005 at 11:55:10AM -0500, Bradley Lucier wrote:
On Apr 6, 2005, at 10:47 PM, ben@fuhok.net wrote:
I also fixed a copy of small bugs --- hopefully I didn't introduce too many in their place ;-) I haven't tested these rigorously though.
s/copy/couple/
It seems to be a bit difficult to extract the bug fixes (as opposed to the other changes) from your code.
Yes, and I didn't apply them to the originals as I fixed them. In retrospect, this was not smart.
Could you list them separately? I'd like to fix my versions of the libraries.
I attached some fixes that I fished out of the rather noisy diff. I think I got most of them. The majority aren't really for `bugs', at least not serious ones. They mostly correct wrong function names in your error macros. I noted some discrepancy in argument order between the srfi-14 text and Olin's reference implementation. For those functions that take a string and a `criterion', the srfi (usually) lists the order as `string' `criterion', but the reference implementation often switches them around. The functions string-every and string-any are exceptions: the spec orders their arguments as `criterion' `string'. I flipped several arguments around to match the srfi spec instead of the reference implementation.
BTW, the complicated way I defined my error-checking, etc., was to make it more compatible with built-in error checking in the Gambit runtime in the hope that these libraries could someday be integrated in the runtime (either officially or de-facto).
That thought occurred to me as I was working, but as I had already started, I just plowed on. I'll use mine until yours get integrated into the Gambit distribution. What advantage does the more complicated error checking have over the simpler checking that I put in? Is there more to it than just consistency with the Gambit runtime? Ben
On Apr 7, 2005, at 10:55 PM, ben@fuhok.net wrote:
What advantage does the more complicated error checking have over the simpler checking that I put in? Is there more to it than just consistency with the Gambit runtime?
Thank you for the diffs, I haven't looked at them yet, I've been working on answering this question. Basically, your error-checker (define (##check-arg pred val caller) (if (not (pred val)) (error "Bad argument type" val caller))) can lead to trouble; if val is circular, for example, or a 10000-entry list, or ... then there will just be a whole lot of stuff dumped to the terminal until the user hits ^C. For example: [zakon2-iro-umontreal-ca:~/programs/gambc40b12/ben] bjlucier% gsc Gambit Version 4.0 beta 12
(compile-file "char-set-lib.scm") gcc: unrecognized option `-no-cpp-precomp' #t (load "char-set-lib.scm") "/Users/bjlucier/programs/gambc40b12/ben/char-set-lib.scm" (load "char-set-lib") "/Users/bjlucier/programs/gambc40b12/ben/char-set-lib.o1" (define a (cons #f #f)) a (#f . #f) (set-cdr! a a) (char-set-adjoin char-set:lower-case a) *** ERROR IN char-set-adjoin -- Bad argument type (#f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f <lines and lines of stuff removed>^C *** ERROR IN char-set-adjoin -- Deadlock detected
whereas if you use and extend slightly the built-in error-handling machinery that Marc built, you get
(load "../srfis/srfis") "/Users/bjlucier/programs/gambc40b12/ben/../srfis/srfis.o2" (char-set-adjoin char-set:lower-case a) *** ERROR IN char-set-adjoin -- CHARACTER expected (char-set-adjoin '#<char-set #3 body: #u16(0 0 0 0 0 0 65534 2047 0 0 0 32 0 32768 65535 654... '(#f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f ...) 1>
Of course, all is not perfect:
(char-set-adjoin 1 #\c) *** ERROR IN (console)@21.1 -- (Argument 1) Unknown type expected (char-set-adjoin 1 #\c) 1>
Marc, how do you fix this? Anyway, I've included srfis 13 and 14 modified to work with gambc40b12 in this message. Put these files in a directory srfis in parallel with lib/gsi/gsc/... and compile with
(compile-file "srfis.scm" '(check))
if you want checking or
(compile-file "srfis.scm")
if you don't. (Another reason to do error checking the way I did, you can get rid of the checking easily.) I also added [zakon2-iro-umontreal-ca:~/programs/gambc40b12/ben] bjlucier% rcsdiff *.scm =================================================================== RCS file: RCS/char-set-lib.scm,v retrieving revision 1.1 diff -r1.1 char-set-lib.scm 5a6
(declare (standard-bindings)(extended-bindings)(block))
to your char-set-lib.scm. Brad
Brad, On Fri, Apr 08, 2005 at 11:09:10PM -0500, Bradley Lucier wrote:
On Apr 7, 2005, at 10:55 PM, ben@fuhok.net wrote:
What advantage does the more complicated error checking have over the simpler checking that I put in? Is there more to it than just consistency with the Gambit runtime?
Basically, your error-checker
(define (##check-arg pred val caller) (if (not (pred val)) (error "Bad argument type" val caller)))
can lead to trouble; if val is circular, for example, or a 10000-entry list, or ... then there will just be a whole lot of stuff dumped to the terminal until the user hits ^C. For example:
Ah. I see, thanks.
Marc, how do you fix this?
If you received any more info on this from Marc, please forward it to me. Thanks, Ben
On Apr 7, 2005, at 10:55 PM, ben@fuhok.net wrote:
I attached some fixes that I fished out of the rather noisy diff. I think I got most of them. The majority aren't really for `bugs', at least not serious ones. They mostly correct wrong function names in your error macros.
I noted some discrepancy in argument order between the srfi-14 text and Olin's reference implementation. For those functions that take a string and a `criterion', the srfi (usually) lists the order as `string' `criterion', but the reference implementation often switches them around. The functions string-every and string-any are exceptions: the spec orders their arguments as `criterion' `string'.
I flipped several arguments around to match the srfi spec instead of the reference implementation.
Wow, you caught a lot of problems, thanks. I've included below the diffs between the implementation I sent before and this one; I hope I caught all the things you pointed out. Also, I've included a tar file with all the .scm files again. Put them in a directory srfis at the same level as lib/gsi/gsc in the gambit directory and compile with [zakon2-iro-umontreal-ca:~/programs/gambc40b12/srfis] bjlucier% gsc Gambit Version 4.0 beta 12
(compile-file "srfis" '(check)) #t (load "srfis") "/Users/bjlucier/programs/gambc40b12/srfis/srfis.o6"
By the way, once it's compiled, it can be loaded into the interpreter without any problems. I imagine that srfis will eventually be gambit-runtime quality code, highly optimized but with complete error checks, so I don't see any problem assuming that they will be compiled before being loaded into either the interpreter or the compiler. There are still a number of places where I just call error directly to deal with errors. That strategy is not optimal, for reasons that I laid out in my previous e-mail. Marc, you want to chime in here and tell us how to do it properly? At any rate, perhaps we can use this strategy: Assume that we're compiling all SRFIs in a directory srfis in the Gambit directory as I suggested, and work at incrementally improving this code rather than starting with a new one. Brad
Brad, On Sat, Apr 09, 2005 at 11:23:31PM -0500, Bradley Lucier wrote:
I've included below the diffs between the implementation I sent before and this one; I hope I caught all the things you pointed out.
Add this one: --- srfis.bak/string-lib.scm 2005-04-09 23:01:45.000000000 -0500 +++ srfis/string-lib.scm 2005-04-11 22:29:21.713553376 -0500 @@ -829,7 +829,7 @@ (macro-check-string-start-end s start end (string-count s criterion start end) (##string-count s criterion start end))) -(define (##string-count criterion s start end) +(define (##string-count s criterion start end) (cond ((char? criterion) (do ((i start (+ i 1)) (count 0 (if (char=? criterion (string-ref s i)) Right now, string-count is still broken (unless I've got my diffs mixed up).
Also, I've included a tar file with all the .scm files again. Put them in a directory srfis at the same level as lib/gsi/gsc in the gambit directory and compile with
[zakon2-iro-umontreal-ca:~/programs/gambc40b12/srfis] bjlucier% gsc Gambit Version 4.0 beta 12
(compile-file "srfis" '(check)) #t (load "srfis") "/Users/bjlucier/programs/gambc40b12/srfis/srfis.o6"
That seems to work well. However, as the srfi collection grows, I would think that compiling them into separate loadable libraries would be better, instead of lumping them into one big srfis.o. Perhaps srfi-55 could be implemented.
At any rate, perhaps we can use this strategy: Assume that we're compiling all SRFIs in a directory srfis in the Gambit directory as I suggested, and work at incrementally improving this code rather than starting with a new one.
Sounds good. I think we are missing a few functions. I will likely send you another patch in a few days to correct that. Ben
On Apr 11, 2005, at 10:51 PM, ben@fuhok.net wrote:
At any rate, perhaps we can use this strategy: Assume that we're compiling all SRFIs in a directory srfis in the Gambit directory as I suggested, and work at incrementally improving this code rather than starting with a new one.
Sounds good. I think we are missing a few functions. I will likely send you another patch in a few days to correct that.
OK, for now I've set up a web directory http://www.math.purdue.edu/~lucier/gambit-srfis/ in which I will try to merge your changes. OK? Brad
On Mon, Apr 11, 2005 at 10:51:46PM -0500, ben@fuhok.net wrote:
At any rate, perhaps we can use this strategy: Assume that we're compiling all SRFIs in a directory srfis in the Gambit directory as I suggested, and work at incrementally improving this code rather than starting with a new one.
Sounds good. I think we are missing a few functions. I will likely send you another patch in a few days to correct that.
Ben
A fews days, a month, what's the difference? Very sorry, I got side-tracked by some things that are a lot less fun than hacking scheme. Anyway, attached is a patch against the version of char-set-lib.scm in the web directory you set up. One thing I noticed that kind of sucked was that my laptop, which has 512 megs, can't compile "srfis.scm" in safe mode without running out of memory. It's not clear to me why (declare (safe)) causes Gambit to suck up more memory, but apparently it does. How about deleting the trailing whitespace from those files when you get the chance? Also, are you working on srfi-1 at all? It would seem like the next logical target. Regards, Ben
On May 7, 2005, at 3:50 PM, ben@fuhok.net wrote:
Also, are you working on srfi-1 at all? It would seem like the next logical target.
Well, I didn't really do anything to it. You can probably just compare my implementation with the default one to see what changes I made: http://www.math.purdue.edu/~lucier/gambit-srfis/list-lib.scm The error checking seemed more difficult for SRFI-1 and I haven't worked out yet how to do it the "Gambit" way. Brad
On May 7, 2005, at 3:50 PM, ben@fuhok.net wrote:
Anyway, attached is a patch against the version of char-set-lib.scm in the web directory you set up.
Char-set-invert[!] and predicate->char-set[!] were removed from the srfi during the discussion phase (at my suggestion ;-), but I hadn't yet renamed/re-implementd that new procedures. Fixed, thanks. About cursors: I added a couple of checks to the cursor routines. I noticed that you followed the suggested implementation and had cursors go down from 255 to 0, the same as the implementation for char-set-filter[!]. Yet the documentation talks about "No lazy implementations of char-set-filter because of side effects" etc. Well, if we think side effects are important, should we either ensure that cursors go from 0 up rather than from 255 down? And the same for char-set-filter[!]? Or at least document that these things go down rather than up? Please check my changes.
One thing I noticed that kind of sucked was that my laptop, which has 512 megs, can't compile "srfis.scm" in safe mode without running out of memory. It's not clear to me why (declare (safe)) causes Gambit to suck up more memory, but apparently it does.
The .i file for srfis.scm is 1.9MB when (declare (safe)), that's pretty big. I think our ultimate goal should be to add enough explicit checks that the libraries can be compiled with all unsafe optimizations on. In your gambit.h file define ___OPTIMIZE_SPACE just before the tests for ___OPTIMIZE_SPACE and ___OPTIMIZE_TIME. That should help a lot.
How about deleting the trailing whitespace from those files when you get the chance?
Done. Brad
Brad, I hadn't thought about that. We probably should iterate from 0, although I think anyone who relies on that behavior is asking for trouble, since the spec doesn't say anything about iteration order. Attached are patches to char-set-lib and to string-lib. The latter adds `string-concatenate-reverse' and its shared variant. Ben PS: The permissions are too tight on `list-lib' in the webdav directory. On Mon, May 09, 2005 at 11:47:12PM -0500, Bradley Lucier wrote:
I noticed that you followed the suggested implementation and had cursors go down from 255 to 0, the same as the implementation for char-set-filter[!]. Yet the documentation talks about "No lazy implementations of char-set-filter because of side effects" etc. Well, if we think side effects are important, should we either ensure that cursors go from 0 up rather than from 255 down? And the same for char-set-filter[!]? Or at least document that these things go down rather than up?
On Mon, May 09, 2005 at 11:47:12PM -0500, Bradley Lucier wrote:
I think our ultimate goal should be to add enough explicit checks that the libraries can be compiled with all unsafe optimizations on.
Which includes '(declare (not safe)) right? Earlier today, I realized that either these checks aren't working right, or that I'm confused. I thought that they were working in b12, but I already upgraded to b13, so I will have to reinstall to confirm that. Examples: ------------------------------------------------ Gambit Version 4.0 beta 13
(load "srfis") "/home/ben/srfis/srfis.o1" (char-set-size 'foo)
Process scheme segmentation fault ------------------------------------------------ ------------------------------------------------ Gambit Version 4.0 beta 13
(load "srfis") "/home/ben/srfis/srfis.o1" (string-null? 4)
Process scheme segmentation fault ------------------------------------------------ I thought we were adding checks to avoid segfaults and such. Ben
On May 12, 2005, at 6:45 PM, ben@fuhok.net wrote:
On Mon, May 09, 2005 at 11:47:12PM -0500, Bradley Lucier wrote:
I think our ultimate goal should be to add enough explicit checks that the libraries can be compiled with all unsafe optimizations on.
Which includes '(declare (not safe)) right?
Yes. To activate the (macro-check-* ...) error checking you need to compile with -check, e.g., % gsc -c -check srfis.scm or % gsc
(compile-file "srfis.scm" '(check))
Brad
Bah. You've mentioned that before, but I had forgotten. Sorry. Ignore the last patches I sent. The range-checks were wrong. I attached corrected versions. Thanks, Ben On Thu, May 12, 2005 at 06:13:19PM -0500, Bradley Lucier wrote:
Yes. To activate the (macro-check-* ...) error checking you need to compile with -check, e.g.,
% gsc -c -check srfis.scm
or
% gsc
(compile-file "srfis.scm" '(check))
Brad
On May 12, 2005, at 8:36 PM, ben@fuhok.net wrote:
Ignore the last patches I sent. The range-checks were wrong. I attached corrected versions.
Applied, thanks. I changed the permissions on list-lib.scm to make it readable. I also looked at it for a few minutes thinking I would convert the error checks to "Gambit-style", but I soon got caught up in take, drop, take!, ..., where many, many, more error checks needs to be inserted, so I decided to give up. There are a lot of places in list-lib.scm that need more error checks. Brad
participants (2)
-
ben＠fuhok.net -
Bradley Lucier