Re: tabular is not handling "" escapes

[Phil Bewig]

I have a CSV parser at my blog that might interest you:
https://programmingpraxis.files.wordpress.com/2013/01/textfiledatabases.pdf.
It properly handles bot Unix and DOS-style line endings, and embedded
quotes.

On Fri, Mar 6, 2020 at 2:00 PM Ivan Raikov  wrote:

> Hi Matt,
>
> Thanks, I think the default line terminator is the newline character,
> which would not work on files with DOS-style line endings. Could you
> call the reader with option eol: "\r\n" to see if this fixes the
> problem?
>
> -Ivan
>
> On Fri, Mar 6, 2020 at 11:24 AM Matt Welland 
> wrote:
> >
> > Thanks Ivan, I much appreciate the support.
> >
> > I tested 1.2 and it does solve the escaped quotes problem. I do now see
> another problem. Multi-line cells cause the parser some grief. The attached
> test.csv generated from Excel imports fine to gnumeric but fails with an
> "unable to parse record" with tabular.
> >
> > On Fri, Mar 6, 2020 at 8:16 AM Ivan Raikov 
> wrote:
> >>
> >> Hi Matt,
> >>
> >> Thank you for using tabular and for reporting this issue. This was
> >> indeed a bug in the code that handles escaped quotes. I have fixed it
> >> and have made a new release (1.2). Let me know if you run into any
> >> other issues. Best regards,
> >>
> >> -Ivan
> >>
> >> On Thu, Mar 5, 2020 at 2:14 PM Matt Welland 
> wrote:
> >> >
> >> > It is common in csv to escape double quotes with double quotes. This
> does not work in tabular and I was unable to figure out any other
> mechanism. Replacing the first " with \ did not work and neither did using
> single quotes around the string. Is there a built in mechanism? The csv
> files in question come from Microsoft Excel but I tested with a csv from
> Gnumeric and see the same problem.
> >> >
> >> > cat testing.csv
> >> > Junk,"Joe  ""Super"" Duper Guy",zsssy
> >> > "More Junk",1,2
> >> >
> >> > ../portit pp testing.csv
> >> >
> >> > Error: (list->string) bad argument type - not a character: (#\")
> >> >
> >> > Call history:
> >> >
> >> > utf8-srfi-14.scm:101: iset#iset-contains?
> >> > utf8-srfi-14.scm:101: iset#iset-contains?
> >> > utf8-srfi-14.scm:101: iset#iset-contains?
> >> > utf8-srfi-14.scm:101: iset#iset-contains?
> >> > utf8-srfi-14.scm:101: iset#iset-contains?
> >> > utf8-srfi-14.scm:101: iset#iset-contains?
> >> > utf8-srfi-14.scm:101: iset#iset-contains?
> >> > utf8-srfi-14.scm:101: iset#iset-contains?
> >> > utf8-srfi-14.scm:101: iset#iset-contains?
> >> > utf8-srfi-14.scm:101: iset#iset-contains?
> >> > utf8-srfi-14.scm:101: iset#iset-contains?
> >> > utf8-srfi-14.scm:101: iset#iset-contains?
> >> > utf8-srfi-14.scm:101: iset#iset-contains?
> >> > utf8-srfi-14.scm:101: iset#iset-contains?
> >> > utf8-srfi-14.scm:101: iset#iset-contains?
> >> > utf8-srfi-14.scm:101: iset#iset-contains?   <--
> >> >
> >> > Thanks.
> >> > --
> >> > Complexity is your enemy. Any fool can make something complicated.
> >> > It is hard to keep things simple. - Richard Branson.
> >
> >
> >
> > --
> > --
> > Complexity is your enemy. Any fool can make something complicated.
> > It is hard to keep things simple. - Richard Branson.
>
>

Re: [Chicken-users] Defining defmacro using define-syntax

[Phil Bewig]

>From the Standard Prelude 
at my blog :

(define-syntax (define-macro x)
  (syntax-case x ()
((_ (name . args) . body)
  (syntax (define-macro name (lambda args . body
((_ name transformer)
  (syntax
   (define-syntax (name y)
 (syntax-case y ()
   ((_ . args)
 (datum->syntax-object
   (syntax _)
   (apply transformer
 (syntax-object->datum (syntax args)))

On Mon, May 13, 2019 at 1:24 PM Martin Ward  wrote:

>
> The FermaT program transformation system is implemented in WSL
> and translated to Scheme for compiling or interpreting.
>
> It was originally developed using SCM scheme which uses defmacro
> to define macros, eg:
>
> (defmacro floop (name . body)
>`(call-with-current-continuation
>   (lambda (,name)
> (do () (#f #t)
>,@body
>
> (defmacro pop (v1 v2)
>`(begin
>   (set! ,v1 (car ,v2))
>   (set! ,v2 (cdr ,v2
>
> (defmacro push (v e)
>`(set! ,v (cons ,e ,v)))
>
> I am trying to port it to other Scheme versions. For bigloo
> I can use define-macro to define defmacro as a macro:
>
> (define-macro (defmacro name . forms)
>\`(define-macro (,name . ,(car forms)) ,\@(cdr forms)))
>
> Chicken scheme does not appear to have defmacro or define-macro
> but does have define-syntax.
>
> Is there a way to define defmacro using define-syntax?
>
> --
> Martin
>
> Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk
> G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4
>
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Chicken/Tk

[Phil Bewig]

I was once the maintainer of pstk. But I can tell you that I haven't
touched it in years, and it fell off of SourceForge in one of their
restructurings, so I have no intention of looking at it again.

Several years ago someone, I don't recall who, forked pstk for Chicken. I
was not involved in the fork, and I don't know what changes were made. I'm
pretty sure the Chicken version of pstk hasn't been maintained for a long
time, either.

I am not a regular user of Chicken and am not interested in being the
maintainer of Chicken pstk.

On Wed, Feb 13, 2019 at 1:51 PM lundi  wrote:

> Thank you Vasilij for the quick and detailed reply. That's pretty much
> all I needed to know.
>
> I was definately planning on using ttk widgets so pstk it is.
>
> As I only started coding in Scheme a few months ago I don't feel up to
> the task of maintaining the pstk egg at this point either. The code
> doesn't look too complicated though so I'll probably volunteer to do it
> once I have a bit more experience.
>
> Best wishes,
> -Heinz
>
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] help on find a lisp paper by John McCarthy

[Phil Bewig]

http://delivery.acm.org/10.1145/81/808386/p215-mccarthy.pdf?ip=198.209.225.227=808386=ACTIVE%20SERVICE=F82E6B88364EF649%2EEA777AEEAA51B01B%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35=999374817=78744412&__acm__=1509128711_9f195cf9fe92408377c1edaff75b3e69

On Fri, Oct 27, 2017 at 1:16 PM, Erik Falor  wrote:

> On Fri, Oct 27, 2017 at 05:35:32PM +0800, Jinx wrote:
> >
> > the Paper is about 2-3 pages long, at least can be  downloaded on
> > the internet for free in pdf,
> >
> > the content is on how to constuct lisp from several axioms, more in
> > a math paper fashion.
> >
> > the paper is a late time working paper McCarthy, not the
> > "Recursive Functions of ... Machine, Part I" , there might be some
> > co-author.
> >
> > I have downloaded the paper one year ago, and cant find it now,
> > and after a long search on the web, still get nothing, thats the
> > most elegent paper in constructing the lisp in the axiomatic way,
> > I am sure I will keep it carefully this time if u could help me
> > on finding it
>
> Is what you are looking for similar to Paul Graham's 2002 paper "The
> Roots of Lisp" [1], but authored by McCarthy himself?
>
> [1] http://3e8.org/pub/pdf-t1/the-roots-of-lisp.pdf
>
> --
> Erik Falor
> Registered Linux User #445632http://unnovative.net
>
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
>
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Chicken on Termux

[Phil Bewig]

That works. Thank you to Alexander and the others who responded, both here
and on the Gambit list.

On May 13, 2017 4:00 AM, "Alexander Shendi (web.de)" <
alexander.she...@web.de> wrote:

> Hi Phil,
>
> you have to set LD_LIBRARY_PATH explicitly :
>
> export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$HOME/chicken-4.12.0/lib
>
> Then you should be able to invoke "csi" directly. You don't need my patch,
> if you don't mind a linker warning message each time you run "csi".
>
> Best Regards,
>
> Alexander
>
> Am 13. Mai 2017 03:15:30 MESZ schrieb Phil Bewig <pbe...@gmail.com>:
>>
>> I began as John suggested with the following command line:
>>
>> TMPDIR=$HOME/tmp make C_COMPILER=clang PREFIX=$HOME/chicken-4.12.0
>> PLATFORM=linux install
>>
>> This ran fine (about ten minutes) until it encountered an error on the
>> line:
>>
>> clang -L. chicken.o batch-driver.o compiler.o optimizer.o lfa2.o
>> compiler-syntax.o scrutinizer.o support.o c-platform.o c-backend.o -o
>> chicken -lchicken -W1,-R"." -lm -ldl
>>
>> The error message is:
>>
>> ./libchicken.so: undefined reference to '__android_log_vprint'
>> clan-4.0: error: linker command failed with exit code 1 (use -v to see
>> invocation)
>> make: *** [rules.make:247: chicken] Error 1
>>
>> So I erased everything, untarred again, and did as Alexander suggested:
>>
>> TMPDIR=$HOME/tmp make C_COMPILER=clang PREFIX=$HOME/chicken-4.12.0
>> PLATFORM=android install
>>
>> The compile completed successfully, but when I run ./csi I get an error:
>>
>> CANNOT LINK EXECUTABLE: could not load library "libchicken.so" needed by
>> "./csi"; caused by library "libchicken.so" not found
>>
>> Of course, libchicken.so is in the same directory as csi. I suppose that
>> is the linker error Alexander talked about. I have questions:
>>
>> 1) How do I work around the link error and run csi?
>>
>> 2) Alexander: How do I apply your patch? (I'm not adept with C.) Is your
>> patch forward-compatible so it will work on future versions of chicken?
>>
>> 3) Is there a way to compile chicken so the library is included
>> statically and doesn't require a dynamically-loaded library? (I would
>> prefer that to a patch.)
>>
>> Thanks again,
>>
>> Phil
>>
>> On Fri, May 12, 2017 at 6:16 PM, Alexander Shendi (web.de) <
>> alexander.she...@web.de> wrote:
>>
>>> Dear Phil,
>>>
>>> It's me again.
>>>
>>> Some remarks:
>>> I did successfully compile CHICKEN 4.12.0 on Termux/Android. Please use
>>> that exact release as it contains several fixes for the Android platform.
>>>
>>> 1) I used PLATFORM=android as Termux uses Android's libc (Bionic) rather
>>> than GNU libc.
>>> 2) The complete make invocation I used was:
>>>
>>> TMPDIR=$HOME/tmp make C_COMPILER=clang PREFIX=$HOME/chickens/4.12.0
>>> PLATFORM=android install
>>>
>>> 3) the Android dynamic linker is rather dumb and doesn't support the
>>> --rpath feature used by the Makefile.
>>> It spits out a warning to that effect every time you run csi/csc or an
>>> executable made with csc.
>>> This also screws up the CHICKEN test suite. I have a patch that works
>>> around that
>>> (see https://paste.call-cc.org/paste?id=a738f447edf76ecbaa7b47eec
>>> ed51fa138972add#a0)
>>> But if you can live with the warning message and don't need to run the
>>> test suite you don't need to apply the patch.
>>>
>>> 3) I did (see above).
>>>
>>> 4.1) CHICKEN 's library directory (e.g. $HOME/chickens/4.12.0/lib) must
>>> be in your $LD_LIBRARY_PATH.
>>> 4.2) If you want to install eggs (CHICKEN's version of packages) you
>>> must say:
>>> TMPDIR=$HOME/tmp chicken-install 
>>>
>>>
>>> 5.) Good luck!
>>>
>>> 6.) Do not hesitate to ask for further info.
>>>
>>> Best Regards,
>>>
>>> Alexander
>>>
>>>
>>> Am 12. Mai 2017 23:00:10 MESZ schrieb Phil Bewig <pbe...@gmail.com>:
>>>>
>>>> I recently purchased a Lenovo TAB2 A10 tablet computer and installed
>>>> Termux, a unix-like environment, from the Play Store. I want to compile
>>>> Chicken for my computer so I can have a Scheme REPL with me wherever I go.
>>>> I have several questions:
>>>>
>>>> 1) What is the correct PLATFORM for the make command? Is it android?
>>>> Termux isn't really android, it is its own version of unix, similar to
>>>> Debian.
>>>>
>>>> 2) Are any of the optional features required or recommended for Termux?
>>>>
>>>> 3) Have any other Chicken users successfully compiled Chicken on Termux?
>>>>
>>>> 4) Is there anything else I need to know to compile Chicken on Termux?
>>>>
>>>> Thanks for your help.
>>>>
>>>> Phil
>>>>
>>>
>>> --
>>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
>>> gesendet.
>>>
>>
>>
> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> gesendet.
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Chicken on Termux

[Phil Bewig]

I began as John suggested with the following command line:

TMPDIR=$HOME/tmp make C_COMPILER=clang PREFIX=$HOME/chicken-4.12.0
PLATFORM=linux install

This ran fine (about ten minutes) until it encountered an error on the line:

clang -L. chicken.o batch-driver.o compiler.o optimizer.o lfa2.o
compiler-syntax.o scrutinizer.o support.o c-platform.o c-backend.o -o
chicken -lchicken -W1,-R"." -lm -ldl

The error message is:

./libchicken.so: undefined reference to '__android_log_vprint'
clan-4.0: error: linker command failed with exit code 1 (use -v to see
invocation)
make: *** [rules.make:247: chicken] Error 1

So I erased everything, untarred again, and did as Alexander suggested:

TMPDIR=$HOME/tmp make C_COMPILER=clang PREFIX=$HOME/chicken-4.12.0
PLATFORM=android install

The compile completed successfully, but when I run ./csi I get an error:

CANNOT LINK EXECUTABLE: could not load library "libchicken.so" needed by
"./csi"; caused by library "libchicken.so" not found

Of course, libchicken.so is in the same directory as csi. I suppose that is
the linker error Alexander talked about. I have questions:

1) How do I work around the link error and run csi?

2) Alexander: How do I apply your patch? (I'm not adept with C.) Is your
patch forward-compatible so it will work on future versions of chicken?

3) Is there a way to compile chicken so the library is included statically
and doesn't require a dynamically-loaded library? (I would prefer that to a
patch.)

Thanks again,

Phil

On Fri, May 12, 2017 at 6:16 PM, Alexander Shendi (web.de) <
alexander.she...@web.de> wrote:

> Dear Phil,
>
> It's me again.
>
> Some remarks:
> I did successfully compile CHICKEN 4.12.0 on Termux/Android. Please use
> that exact release as it contains several fixes for the Android platform.
>
> 1) I used PLATFORM=android as Termux uses Android's libc (Bionic) rather
> than GNU libc.
> 2) The complete make invocation I used was:
>
> TMPDIR=$HOME/tmp make C_COMPILER=clang PREFIX=$HOME/chickens/4.12.0
> PLATFORM=android install
>
> 3) the Android dynamic linker is rather dumb and doesn't support the
> --rpath feature used by the Makefile.
> It spits out a warning to that effect every time you run csi/csc or an
> executable made with csc.
> This also screws up the CHICKEN test suite. I have a patch that works
> around that
> (see https://paste.call-cc.org/paste?id=a738f447edf76ecbaa7b47eeced51f
> a138972add#a0)
> But if you can live with the warning message and don't need to run the
> test suite you don't need to apply the patch.
>
> 3) I did (see above).
>
> 4.1) CHICKEN 's library directory (e.g. $HOME/chickens/4.12.0/lib) must be
> in your $LD_LIBRARY_PATH.
> 4.2) If you want to install eggs (CHICKEN's version of packages) you must
> say:
> TMPDIR=$HOME/tmp chicken-install 
>
>
> 5.) Good luck!
>
> 6.) Do not hesitate to ask for further info.
>
> Best Regards,
>
> Alexander
>
>
> Am 12. Mai 2017 23:00:10 MESZ schrieb Phil Bewig <pbe...@gmail.com>:
>>
>> I recently purchased a Lenovo TAB2 A10 tablet computer and installed
>> Termux, a unix-like environment, from the Play Store. I want to compile
>> Chicken for my computer so I can have a Scheme REPL with me wherever I go.
>> I have several questions:
>>
>> 1) What is the correct PLATFORM for the make command? Is it android?
>> Termux isn't really android, it is its own version of unix, similar to
>> Debian.
>>
>> 2) Are any of the optional features required or recommended for Termux?
>>
>> 3) Have any other Chicken users successfully compiled Chicken on Termux?
>>
>> 4) Is there anything else I need to know to compile Chicken on Termux?
>>
>> Thanks for your help.
>>
>> Phil
>>
>
> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> gesendet.
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] Chicken on Termux

[Phil Bewig]

I recently purchased a Lenovo TAB2 A10 tablet computer and installed
Termux, a unix-like environment, from the Play Store. I want to compile
Chicken for my computer so I can have a Scheme REPL with me wherever I go.
I have several questions:

1) What is the correct PLATFORM for the make command? Is it android? Termux
isn't really android, it is its own version of unix, similar to Debian.

2) Are any of the optional features required or recommended for Termux?

3) Have any other Chicken users successfully compiled Chicken on Termux?

4) Is there anything else I need to know to compile Chicken on Termux?

Thanks for your help.

Phil
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Review my Caesar Cipher?

[Phil Bewig]

I would use an auxiliary function char-plus to add or subtract an offset to
a character:

(define (caesar str n)
  (define (char-plus c)
(let ((alpha ABCDEFGHIJKLMNOPQRSTUVWXYZ))
  (if (not (char-alphabetic? c)) c
(let ((i (- (char-integer (char-upcase c)) 65)))
  (string-ref alpha (modulo (+ i n) 26))
  (list-string (map char-plus (string-list str

Then here are your two examples; decryption is just encryption by the
negative:

 (caesar To craunch the marmoset. 1)
UP DSBVODI UIF NBSNPTFU.
 (caesar UP DSBVODI UIF NBSNPTFU. -1)
TO CRAUNCH THE MARMOSET.


On Mon, Mar 10, 2014 at 9:51 AM, Daniel Carrera dcarr...@gmail.com wrote:

 Hello,

 I found a Scheme implementation of the Caesar cipher on Rosetta Code. It
 said This was written by a novice, please review... So I reviewed it, and
 basically rewrote it.

 I think my version is much better (clearer) but since I too am a novice, I
 feel bad removing the novice warning. Could someone who has used Scheme
 longer than two weeks have a quick look at my work and tell me if I can
 remove the warning (or make corrections if my code is not idiomatic or
 something)?

 My version(s):

 http://rosettacode.org/wiki/Caesar_cipher#Scheme

 Previous version:

 http://rosettacode.org/mw/index.php?title=Caesar_cipheroldid=177675#scheme

 Cheers,
 Daniel.
 --
 When an engineer says that something can't be done, it's a code phrase
 that means it's not fun to do.

 ___
 Chicken-users mailing list
 Chicken-users@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/chicken-users


___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Review my Caesar Cipher?

[Phil Bewig]

I used only the procedures provided by RnRS, instead of loading SRFI-13,
but you could use string-map if you want to. For those who prefer to roll
their own, here is a simple version of string-map! that mutates the string
in place:

(define (string-map! f str)
  (do ((i 0 (+ i 1))) ((= i (string-length str)) str)
(string-set! str i (f (string-ref str i)

Or you could convert to a list, perform the mapping, and convert back, as I
did in my original version of the function. With string-map!, the caesar
function changes to this:

(define (caesar str n)
  (define (char-plus c)
(let ((alpha ABCDEFGHIJKLMNOPQRSTUVWXYZ))
  (if (not (char-alphabetic? c)) c
(let ((i (- (char-integer (char-upcase c)) 65)))
  (string-ref alpha (modulo (+ i n) 26))
  (string-map! char-plus str))

For purposes of Rosetta Code, it's probably better to avoid SRFI-13 and
stay with RnRS, as in my first version of the function.


On Mon, Mar 10, 2014 at 10:31 AM, Peter Bex peter@xs4all.nl wrote:

 On Mon, Mar 10, 2014 at 10:26:56AM -0500, Phil Bewig wrote:
  I would use an auxiliary function char-plus to add or subtract an offset
 to
  a character:
 
  (define (caesar str n)
(define (char-plus c)
  (let ((alpha ABCDEFGHIJKLMNOPQRSTUVWXYZ))
(if (not (char-alphabetic? c)) c
  (let ((i (- (char-integer (char-upcase c)) 65)))
(string-ref alpha (modulo (+ i n) 26))
(list-string (map char-plus (string-list str

 If you're using srfi-13, you might as well change the final line to use
 string-map:  (string-map char-plus str)

 Cheers,
 Peter
 --
 http://www.more-magic.net

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Fwd: [Chicken-users] Value returned from modulo

[Phil Bewig]

You can add Chez Scheme to the list of those that gets the correct answer
23163662.

Perhaps (+ (* a x) b) is calculated exactly but the modulo operator uses
inexact arithmetic internally; you mentioned that the returned value was
inexact.  When I do (modulo (+ (* (exact-inexact a) (exact-inexact x))
(exact-inexact b)) (expt 2.0 32) I get 23163648.0.

On Sat, Aug 28, 2010 at 6:19 AM, Jeronimo Pellegrini j...@aleph0.infowrote:

 Hello,

 I was writing a simple PRNG for didatic purposes and found
 that in Chicken, modulo may or may not return an exact
 integer -- whic is OK, I can just do inexact-exact.
 But it seems also that the value varies among systems:

 #;1 (define a 1103515245)
 #;2 (define b 12345)
 #;3 (define m (expt 2 32))
 #;4 (define x 631629065)
 #;5 (modulo (+ (* a x) b) m)
 23163648.0
 #;6 (+ (* a x) b)
 697012302412608270

 Octave also gives me 23163648:
 octave:2 mod((1103515245*631629065 + 12345),(2^32))
 ans =  23163648

 From Gambit, and SBCL I get 23163662.

 Gambit v4.6.0
  (define a 1103515245)
  (define b 12345)
  (define m (expt 2 32))
  (define x 631629065)
  (modulo (+ (* a x) b) m)
 23163662
  (+ (* a x) b)
 697012302412608270

 (Same for Chibi, Gauche and Bigloo)


 SBCL:

 * (setq a 1103515245)
 * (setq b 12345)
 * (setq m (expt 2 32))
 * (setq x 631629065)
 * (mod  (+ (* a x) b) m)

 23163662
 * (+ (* a x) b)

 697012302412608270

 Maxima also answers 23163662 and 697012302412608270.

 What puzzles me is that the large value (before taking the modulo)
 is 697012302412608270 in all systems, but Chiken and Octave will
 still return 23163648 from modulo, so it's not that the larger value
 was not represented exactly. Why then is 23163648 returned?

 I'm not using the numbers egg (I'd like students to do as much as
 possible from scratch, using standard Scheme)

 I'm using Chicken from git, master branch, compiled oon a 64-bit
 machine, so I suppose I can represent all these numbers without
 problems:

 CHICKEN
 (c)2008-2010 The Chicken Team
 (c)2000-2007 Felix L. Winkelmann
 Version 4.6.0rc1
 linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables ]
 compiled 2010-08-09 on newton (Linux)

 J.


 ___
 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] Scheme code to be read

[Phil Bewig]

You might be interested in Programming Praxis http://programmingpraxis.com,
which features Scheme code twice a week.

On Wed, Aug 18, 2010 at 11:19 AM, Stephen Eilert spedr...@gmail.com wrote:

 On Wed, Aug 18, 2010 at 12:02 PM, Christiano F. Haesbaert
 haesba...@haesbaert.org wrote:
  Hi there,
 
  I'm in the point that I can code most stuff in scheme, but I do it
  poorly mainly cause I'm not familiar with the basic SRFIs, the
  language itself and good scheme practices, read: I do not know the
  scheme coding *culture*.
 
  Far too many times I ended up coding something which already existed,
  or doing something really stupid (that worked).
 
  Can you guys point me to some good scheme code ?
  I believe this is the only way to learn.
 
  Thanks.

 From time to time I download egg sources and study them. It has proven
 very instructive.


 --Stephen

 Sent from my Emacs

 ___
 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

[Chicken-users] Re: SRFI 41

[Phil Bewig]

On Wed, May 6, 2009 at 11:26 PM, Kon Lovett klov...@pacbell.net wrote:

 Hello Involved,
 I really hate to respond to this thread but since I ported from the SRFI 41
 reference implementation maybe I should.


I'm curious.  What did you have to do to port SRFI-41?  It should have
worked directly as written just about everywhere.


 On May 6, 2009, at 5:46 PM, Phil Bewig wrote:

 On Wed, May 6, 2009 at 4:56 PM, Alex Shinn alexsh...@gmail.com wrote:

 Hi,

 Phil Bewig pbe...@gmail.com writes:

 snip



  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.


 I disagree.  Streams and lists are not substitutable.  Haskell conflates
 the two because everything in Haskell is lazy, so there is no difference.
 But that isn't true in Scheme.


 There is a reason for 'delay'  'force'. Scheme is eager but
 multi-paradigm and API designers shouldn't go out of the way to hide the
 fact. At least for the basics :-)


Exactly.  Haskell is pure and lazy all the way.  Scheme is broader.



  snip


 When would it make sense to convert the name of a symbol to a stream of
 characters?


 If your interface only accepts streams.


But Scheme doesn't only accept streams.  It also accepts lists.

My other point is that 'symbol' is an atomic concept.  A symbol doesn't
consist of the stream of characters in its name-string.  There might be a
specialized need for a symbol-stream function, perhaps in a debugger or
some other introspective program where streams exist but lists don't, but
that's far beyond a general-purpose library.

That's why using SRFI-1 as a checklist for streams-ext makes no sense.




 snip



 [I would argue the name and API should be changed to
 stream-drop-right to match SRFI-1, though.]


 Sounds like a synonym in a SRFI 41 based streams-ext.


 Stream-length and stream-reverse are certainly candidates to be dropped
 from a stream library.  I'm not entirely sure how I feel about them.


 You feel badly ;-) They imply streams are finite. I prefer the general idea
 by the user that streams are infinite, at least until they run out of steam
 ... err, stream.


I included stream-length and stream-reverse because they are used regularly
in Haskell programs, and Scheme programmers who are porting Haskell code,
say as an academic exercise, might find them useful.

I continue to maintain, as I did in SRFI-41, that if you need to materialize
an entire stream, you do better to find a way to re-cast your program to use
lists.




 You and Alejandro seem to be suggesting that you would use streams in
 preference to lists in a variety of programs.  Take as given that streams
 will be much slower than lists, at least in current Scheme implementations.
 I can't imagine using streams for much more than toy programs or academic
 exercises.  I would always find a better way.



 Now, if you want to argue that the SRFI-1 API is too large,
 that's another story :)


 It is.  I never use SRFI-1.  My personal standard library has take, drop,
 take-while, drop-while, range, iterate, filter, zip, a simple list
 comprehension macro, and pattern matching.


 Maybe the R6RS authors were on to something ;-)


The guiding principle in any library must be to keep it small and simple.  I
quoted Saint-Exupéry in SRFI-41, but could have quoted Einstein Everything
should be as simple as possible, but no simpler.  Occam's Razor also
applies.

SRFI-1 and streams-ext violate that principle to their own detriment.





 --
 Alex


 I continue to maintain that it makes no sense to use SRFI-1 as a checklist
 for implementing a streams extension library.  I hate to keep repeating
 myself, but streams are not lists.  The two data types are used in two
 entirely different sets of circumstances, with different usage patterns.


 I agree. We are walking into sequence territory here.

 I kinda think everything that can be treated as a sequence should have an,
 optional, sequence oriented interface. But built on a type specialized
 interface. (Yes, I would prefer 'list-map', etc. in the base API.)


That idea is more Lispy than Schemely.




 All that said, if you want to write a streams-ext library that mimics
 SRFI-1, feel free.  Just be sure it is based

Re: [Chicken-users] Re: SRFI 41

[Phil Bewig]

As simple as possible, but no simpler.

A large library has many costs.  The obvious cost is the code size, but
that's the least thing to worry about.  Implementers must write, and test,
and debug, and document, and maintain all that code.  Users must endure long
training and voluminous documentation, and inevitably find that the closest
function in the library isn't quite what they need, and write their own
anyway -- worse, they don't notice that the library does provide exactly
what they need, but under a different name, and they write it again,
anyway.  And how many times have you seen a library that was useful in
version 2 but unusable in version 5 because the need to maintain backward
compatibility prevented some feature from working the right way?  If you
don't provide a function now, you won't regret having the function later.

It's ultimately a matter of philosophy.  Scheme has since its inception
favored minimalism.  Other languages make other choices.

I'm not necessarily saying that streams-ext should be tiny, though I do
think smaller is better than larger.  I am saying that SRFI-1 is not an
appropriate checklist by which to design streams-ext, because it will force
you to provide many functions that only make sense for programming with
streams-as-lists but not for programming with streams-as-streams.  And I
think SRFI-41 is, overall, a pretty good library, neither too small nor too
large, but mostly just right.

And if you need butlast, you should probably be using lists, not streams.

On Thu, May 7, 2009 at 9:10 AM, John Cowan co...@ccil.org wrote:

 Phil Bewig scripsit:

  The guiding principle in any library must be to keep it small and simple.
  I
  quoted Saint-Exupéry in SRFI-41, but could have quoted Einstein
 Everything
  should be as simple as possible, but no simpler.  Occam's Razor also
  applies.

 The analogy is false, at least as far as Einstein and Occam are concerned.
 They were talking about keeping the number of explanatory principles
 small.  But tools are not principles.

 The smallest and simplest library for lists in Scheme consists of car,
 cdr, cons, pair?, and '().  Would you really be happy in a world where
 that's all you get, and the rest is just part of your program?  When I
 ask a builder to construct a house for me, I do not expect him to begin
 by cutting down trees, digging clay for bricks, and mining iron ore
 for nails and screws.  Nor do I expect him to reinvent drywall from
 first principles.

  SRFI-1 and streams-ext violate that principle to their own detriment.

 The point of a library, like that of a tool chest, is to provide tools
 considered generally useful.  If your tool chest is half-empty, you
 wind up pounding nails with a screwdriver, or in the extreme case,
 instantiating Greenspun's Tenth Law.  Too-simple libraries make
 too-complex programs.

 --
 John Cowan  http://www.ccil.org/~cowanhttp://www.ccil.org/%7Ecowan
 co...@ccil.org
 To say that Bilbo's breath was taken away is no description at all.  There
 are
 no words left to express his staggerment, since Men changed the language
 that
 they learned of elves in the days when all the world was wonderful. --The
 Hobbit

___
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?

[Phil Bewig]

I did not consider the stream-ext library in the design of SRFI-41.  In
general, as explained in the SRFI, I designed SRFI-41 according to the
advice of Antoine de Saint-Exupéry: *Il semble que la perfection soit
atteinte non quand il n’y a plus rien à ajouter, mais quand il n’y a plus
rien à retrancher*.  (“Perfection is achieved, not when there is nothing
more to add, but when there is nothing left to take away.”)  And I think I
got a couple of things wrong -- if I was to rewrite SRFI-41 today, I would
take away even more.

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).  Writing a library that duplicates SRFI-1
for streams seems to me to be folly.

I looked briefly at your list of suggested extensions.  A few may be useful
for a modest extension library, if you have in mind a particular set of uses
--  some of the examples in the SRFI, such as stream-partition, fall into
this category.  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.  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 find it
amusing that you consider stream-vector and vector-stream, since the pure
FP people have such trouble with mutable arrays.  And even the design is
poor -- stream-butlast-n should almost certainly be merged into
stream-butlast with an optional argument, but stream-reverse shouldn't also
optionally append a list (or is it a stream?).

You say that it is so obvious that all these functions should be included
that you won't waste your time justifying it, but to me it is anything but
obvious -- in fact, it is obvious to me that some of the functions you
mentioned should never exist in the context of streams implemented for
Scheme, much less be included in a standard library.  On the other hand, in
the context of streams implemented for Haskell, it may make sense to include
some of the list-oriented functions, since Haskell has no finite-list type
and uses streams in its place.  Remember: streams are not lists.

You are of course free to use SRFI-41 as the basis for an extended library
of stream functions.  I ask only that you do not call it streams, or
streams-primitive, or streams-derived, so as not to cause confusion with the
SRFI.  I also recommend that you switch over as soon as possible from the
deprecated SRFI-40 to SRFI-41.

By the way, you should have mentioned as you critiqued SRFI-41 that you are
the author of stream-ext.

Phil

On Tue, May 5, 2009 at 9:16 PM, Alejandro Forero Cuervo 
a...@freaks-unidos.net wrote:

  SRFI-40 is deprecated due to a memory leak.  Please port SRFI-41 instead,
  and adapt any code that uses SRFI-40 to the new interface.

 Did you, during the design of srfi-41, consider the existance of the
 stream-ext library, which implements a lot of stream functions on top
 of srfi-40?

 http://chicken.wiki.br/eggref/3/stream-ext

 It's first version was released a long time before srfi-41 and only
 small changes have been made since then.  The naming conventions and
 the semantics match those of srfi-1 as close as possible, to make
 things as consistent as possible.

 I've used the stream-ext library in many applications that represent
 strings as streams of characters throughout.  The largest of these is
 probably Svnwiki.

 I'm worried about the incompatibilities I see between stream-ext and
 srfi-41.  My concerns are the following:

 1. srfi-41 provides a very small subset of the functionality that I
 think that any program that uses streams significantly will need.  As
 such, I think it fails significantly at providing syntax derived from
 those primitives that permits convenient expression of stream
 operations.  Most of the functions I list below can be implemented in
 a portable manner, as stream-ext does.  To be fair, srfi-41 does seem
 to provide some functions that stream-ext does not.

 2. More importantly (the previous concern can be solved with an
 additional library), a small portion of the interface exported by
 srfi-41 differs from that in the stream-ext library.  I provide some
 cases below and explain why I believe the semantics from stream-ext
 are slightly preferable, mostly because of consistency with the srfi-1
 list-based counterparts.  I quite like the interface of srfi-1 and I
 find that, by providing inconsistent counterparts, srfi-41 is making
 it slightly harder to use streams than stream-ext.

 I may be the person who has written the most Scheme code using srfi-40
 

Re: [Chicken-users] Which eggs to migrate from Chicken 3 first?

[Phil Bewig]

On Wed, May 6, 2009 at 4:56 PM, Alex Shinn alexsh...@gmail.com wrote:

 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.


You are correct that streams and parsing go well together.  One of the
examples I wrote for SRFI-41 was a parsing library based on the calculator
Wadler wrote for his 'list of successes' paper, but I dropped it because it
was too long, and illustrated the list of successes technique with the
eight-queens problem.

Parsing also works well without streams, as decades of lex/yacc users can
attest.


  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.


I disagree.  Streams and lists are not substitutable.  Haskell conflates the
two because everything in Haskell is lazy, so there is no difference.  But
that isn't true in Scheme.


  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)


When would it make sense to convert the name of a symbol to a stream of
characters?


  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.]


Stream-length and stream-reverse are certainly candidates to be dropped from
a stream library.  I'm not entirely sure how I feel about them.

You and Alejandro seem to be suggesting that you would use streams in
preference to lists in a variety of programs.  Take as given that streams
will be much slower than lists, at least in current Scheme implementations.
I can't imagine using streams for much more than toy programs or academic

Re: [Chicken-users] Which eggs to migrate from Chicken 3 first?

[Phil Bewig]

SRFI-40 is deprecated due to a memory leak.  Please port SRFI-41 instead,
and adapt any code that uses SRFI-40 to the new interface.

On Wed, Apr 22, 2009 at 11:11 AM, John Cowan co...@ccil.org wrote:

 The following is a list, derived from the dependency graphs, for Chicken
 3 eggs on which more than one other Chicken 3 egg depends.  Eggs high
 up on this list should probably be migrated soon.

 I have excluded all eggs shown in the current Chicken 4 egg list, as
 well as syntax-case.

312 misc-extn
121 lookup-table
 89 srfi-40
 77 locale
 74 srfi-29
 71 format-modular
 63 coerce
 53 srfi-37
 52 eggdoc
 42 stream-ext
 39 srfi-42
 36 uri
 24 url
 23 args
 20 rlimit
 19 openssl
 17 message-digest
 17 http
 16 stream-parser
 10 tinyclos
  7 array-lib
  6 sendfile
  6 iconv
  6 html-stream
  5 utf8
  5 syntactic-closures
  5 srfi-4-comprehensions
  5 blas
  4 tcp-server
  4 stream-sections
  4 ssax
  4 srfi-95
  4 s11n
  4 job-worker
  3 sxml-tools
  3 srfi-66
  3 rfc822
  3 md5
  3 format
  3 dyn-vector
  3 crc
  3 codewalk
  3 args-doc
  2 z3
  2 tool
  2 stream-wiki
  2 sha1
  2 runcmd
  2 pipeline
  2 mime
  2 graph-scc

 --
 John Cowan  http://www.ccil.org/~cowanhttp://www.ccil.org/%7Ecowan
 co...@ccil.org
 To say that Bilbo's breath was taken away is no description at all.  There
 are
 no words left to express his staggerment, since Men changed the language
 that
 they learned of elves in the days when all the world was wonderful. --The
 Hobbit


 ___
 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] PS-tk documentation missing?

[Phil Bewig]

I am the maintainer of PS/Tk.

The official version is on SourceForge, and includes the code necessary to
run in Chicken; in fact, Chicken was the first Scheme implementation for
which PS/Tk was originally developed.

I believe Chicken provides a customized version, but am not familiar with
the details of how it is loaded or what changes it makes from the official
version.

On Fri, Mar 6, 2009 at 12:37 AM, Matthew Welland m...@kiatoa.com wrote:

 I noticed the tk egg minutes after sending my previous email. The tk egg
 seems to have nice documentation and it works on my Nokia n800. However the
 PS-tk egg does not:

 snip
 Nokia-N800-50-2:~# csi

 CHICKEN
 (c)2008 The Chicken Team
 (c)2000-2007 Felix L. Winkelmann
 Version 3.3.1 - linux-unix-gnu-arm  [ dload ptables applyhook ]
 SVN rev. 11106  compiled 2008-07-13 on debian (Linux)

 #;1 (use PS-tk)
 ; loading /var/lib/chicken/3/PS-tk.so ...
 Error: (apply) parameter limit exceeded

Call history:

syntax(use PS-tk)
syntax(##core#require-extension (quote PS-tk))
syntax(begin (begin (##sys#require (quote PS-tk)))
 (##core#undefined))
syntax(begin (##sys#require (quote PS-tk)))
syntax(##sys#require (quote PS-tk))
syntax(quote PS-tk)
syntax(##core#undefined)
eval  (##sys#require (quote PS-tk))   --
 =end===

 What differentiates the two projects? It would be nice to know which one is
 most likely to be supported in the future or to converge on just one tk
 interface for Chicken.

 Thanks,

 Matt
 -=-

 On Thursday 05 March 2009 10:30:13 pm Matthew Welland wrote:
  FYI: The link on the PS-tk egg wiki page seems dead. I did see some docs
  for PS-tk on sourceforge: http://sourceforge.net/projects/pstk
 
  If desired I can cut 'n paste the sourceforge doc into the wiki but no
  promises on keeping all the formatting (although I'll try) 
 
 
  ___
  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

___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users