jscheme-devel — Developer's list

[Jscheme-devel] doc/doc/refman.html

[Geoffrey K. <ge...@kn...>]

After getting the latest CVS snapshot, if I open URL:

	file:///Users/gknauth/test/JScheme/jscheme/doc/jscheme.html

and click "online reference manual," I get URL not found:

	file:///Users/gknauth/test/JScheme/jscheme/doc/doc/refman.html

but this works:

	file:///Users/gknauth/test/JScheme/jscheme/doc/refman.html

These links on the jscheme.html page are similarly broken (extra "doc/" 
in path):
	online reference manual
	online user manual
	What's new page
	download
	license

This is for locally installed documentation.  It seems to be OK on the 
web site.

The link to the talk is broken (URL not found):
	http://frege.cs-i.brandeis.edu:8090/user/scheme/doc/talk.sxml

Geoffrey
--
Geoffrey S. Knauth | http://knauth.org/gsk

[Jscheme-devel] (eq? 128 128) => #f

[Geoffrey K. <ge...@kn...>]

I ran into this while calculating azimuths.

 > (eq? 180 180)
#f
 > (= 180 180)
#t
 > (eq? 0 0)
#t
 > (eq? 1 1)
#t
 > (eq? 2 2)
#t
 > (eq? 3 3)
#t
 > (eq? 180 180)
#f

After poking around, I found this:

 > (eq? 127 127)
#t
 > (eq? 128 128)
#f
 > (eq? -127 -127)
#t
 > (eq? -128 -128)
#f

For now I'll use = instead of eq?.  I was just wondering if this was 
documented.

Geoffrey
--
Geoffrey S. Knauth | http://knauth.org/gsk

[Jscheme-devel] Re: [Jscheme-user] Hash-Quasi-Strings and Fixed Modulo Primitive

[Timothy J. H. <tim...@ma...>]

On Jun 16, 2004, at 4:50 PM, Ken Anderson wrote:

> This is good!  Is it easier to do #{ #} rather than the more 
> "synmetric"
> #{ ... }#?
The idea was to use # to prefix new tokens.
We could however have used
#{ and }# for strong quasi-strings and used
[# and #] for escapes from strong quasi-strings.

With this other alternative the example would be as follows:

> > (define  (prog version)
>  #{
>       public class Test {
>          int [] a = new int[] { 1,2,3,4,5};
>          String version = "[#version#]";
>
>         public static void main(String[] args) {;}
>      }
>  }#
> )
> (lambda prog (version)...)

I guess my feeling was that it might get confusing for people to 
remember
whether we were using #{... }#  or {#....#}
and if we escaped with #[...]# or [#...#]
So having a simple HASH-SYMBOL syntax for each delimiter makes it 
somewhat easier
to remember...

---Tim---




> I'd prefer the second form if it isn't too hard, but i guess your way 
> might be slightly faster if there are lots of } in the string.
>
> k
> At 04:30 PM 6/16/2004 -0400, you wrote:
>> I've fixed the modulo bug in the latest CVS.
>>
>> Also, I've added hash-quasi-strings which I'll describe in more 
>> detail later tonight.
>> The idea is that you use #{ and #} to indicate a hash-quasi-string 
>> and then you
>> can escape into scheme using #[ and #]
>>
>> This will allow us to easily quote general strings.
>>
>> The advantage here is that the hash-quasi-string can contain curly 
>> braces and square braces
>> and double quotes, without needing to "quote" them, thus you can use 
>> it go generate C or CSS
>>
>>
>> e.g. this can be used as follows to generate a string representing a 
>> Java class with
>> a user-supplied version string...
>>
>>>> (define  (prog version)
>>> #{
>>>      public class Test {
>>>         int [] a = new int[] { 1,2,3,4,5};
>>>         String version = "#[version#]";
>>>
>>>        public static void main(String[] args) {;}
>>>     }
>>> #}
>>> )
>>> (lambda prog (version)...)
>>
>>>> (prog "abc 6/16/04")
>>> "\n      public class Test {\n         int [] a = new int[] { 
>>> 1,2,3,4,5};\n         String version = \"abc 6/16/04\";\n     \n
>>> public static void main(String[] args) {;}\n     }\n "
>>
>>>> (begin (display (prog "abc 6/16/04")) (newline) (newline) 'yes)
>>>
>>>      public class Test {
>>>         int [] a = new int[] { 1,2,3,4,5};
>>>         String version = "abc 6/16/04";
>>>
>>>        public static void main(String[] args) {;}
>>>     }
>>>
>>>
>>> yes
>>
>> ---Tim---
>>
>> P.S. if this breaks any code please tell me.
>> It shouldn't have any effect unless you use #{ #} #[ #] somewhere
>> in your code....
>>
>>
>> On Jun 16, 2004, at 4:15 PM, Borislav Iordanov wrote:
>>
>>> Hmm, I'm not sure. It seems % is the same as "remainder"...
>>>
>>> Thanks,
>>> Borislav
>>>
>>> | -----Original Message-----
>>> | From: jsc...@li...
>>> | [mailto:jsc...@li...] On Behalf
>>> | Of Ken Anderson
>>> | Sent: Wednesday, June 16, 2004 3:54 PM
>>> | To: Borislav Iordanov
>>> | Cc: jsc...@li...
>>> | Subject: Re: [Jscheme-user] Modulo function
>>> |
>>> |
>>> | Yes, its broken.  For now use
>>> | > (% 0 5)
>>> | 0
>>> | > (% 7 5)
>>> | 2
>>> | >
>>> | At 03:33 PM 6/16/2004 -0400, Borislav Iordanov wrote:
>>> | >Hi,
>>> | >
>>> | >I noticed in Jscheme that:
>>> | >
>>> | >(modulo 0 5) => 5
>>> | >
>>> | >Is this normal behavior?
>>> | >
>>> | >Thanks,
>>> | >Borislav
>>> | >
>>> | >
>>> | >
>>> | >-------------------------------------------------------
>>> | >This SF.Net email is sponsored by The 2004 JavaOne(SM)
>>> | Conference Learn
>>> | >from the experts at JavaOne(SM), Sun's Worldwide Java Developer
>>> | >Conference, June 28 - July 1 at the Moscone Center in San
>>> | Francisco, CA
>>> | >REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code
>>> | >NWMGYKND _______________________________________________
>>> | >Jscheme-user mailing list
>>> | >Jsc...@li...
>>> | >https://lists.sourceforge.net/lists/listinfo/jscheme-user
>>> |
>>> |
>>> |
>>> | -------------------------------------------------------
>>> | This SF.Net email is sponsored by The 2004 JavaOne(SM)
>>> | Conference Learn from the experts at JavaOne(SM), Sun's
>>> | Worldwide Java Developer Conference, June 28 - July 1 at the
>>> | Moscone Center in San Francisco, CA REGISTER AND SAVE!
>>> | http://java.sun.com/javaone/sf Priority | Code NWMGYKND
>>> | _______________________________________________
>>> | Jscheme-user mailing list
>>> | Jsc...@li...
>>> | https://lists.sourceforge.net/lists/listinfo/jscheme-user
>>> |
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
>>> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
>>> Conference, June 28 - July 1 at the Moscone Center in San Francisco, 
>>> CA
>>> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code 
>>> NWMGYKND
>>> _______________________________________________
>>> Jscheme-user mailing list
>>> Jsc...@li...
>>> https://lists.sourceforge.net/lists/listinfo/jscheme-user
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
>> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
>> Conference, June 28 - July 1 at the Moscone Center in San Francisco, 
>> CA
>> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code 
>> NWMGYKND
>> _______________________________________________
>> Jscheme-user mailing list
>> Jsc...@li...
>> https://lists.sourceforge.net/lists/listinfo/jscheme-user
>

Re: [Jscheme-devel] string->number

[Ken A. <kan...@bb...>]

I'm glad we have people like Alexander helping us design JScheme.
I've changed the code so that (string->number "010") -> 10.
If you need to read java literals use string->expr.

k

At 11:24 AM 6/7/2004 -0400, Geoffrey Knauth wrote:
>On Jun 7, 2004, at 10:44, Timothy John Hickey wrote:
>>This little issue actually goes to the heart of JScheme since what is u=
nique about Jscheme is the tight
>>integration with Java and that integration is made possibly by our deci=
sion to adopt the Java primitive types
>>as the Scheme base types. The Java literal syntax is then essential to =
making JScheme integrate smoothly with
>>Java.
>
>This is a worthy goal.  I certainly remember how impressed I was when th=
e first Java language and VM specs came out, so painstakingly developed. =
 But then even Java has warts, for example:
>
>"How Java=92s Floating-Point Hurts Everyone Everywhere"
>http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf
>
>Principle of Least Surprise ... What is more of an unpleasant surprise?
>1.  (string->number "08") =3D> 8
>2.  (string->number "08") =3D> #f
>3.  (string->number "010") =3D> 10
>4.  (string->number "010") =3D> 8
>
>My feeling is that anyone who wants octal interpretation won't mind sayi=
ng so:
>(string->number "010" 8) =3D> 8
>
>Good morning, Alexander.  How old will you be next year?
>   010
>I see you entered a leading zero.  You're too clever.  I wasn't expectin=
g that.  Like many 7 year-olds, I bet sometimes you wish you were 10.
>
>Geoffrey
>--
>Geoffrey S. Knauth | http://knauth.org/gsk
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: GNOME Foundation
>Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
>GNOME Users and Developers European Conference, 28-30th June in Norway
>http://2004/guadec.org
>_______________________________________________
>Jscheme-devel mailing list
>Jsc...@li...
>https://lists.sourceforge.net/lists/listinfo/jscheme-devel

Re: [Jscheme-devel] string->number

[Ken A. <kan...@bb...>]

OK, lets outsource the documentation.
Lets define string->number to be like the scheme documenatation, and have
string->literal for converting a string to a Java literal.

for the convenience of Java programmers, maybe we should define 
true, false, and null too.


k
At 10:44 AM 6/7/2004 -0400, Timothy John Hickey wrote:

>On Jun 7, 2004, at 10:24 AM, Ken Anderson wrote:
>
>>So the remaining issue is what should (string->number "08") return.  
>>It currently returns #f. i was hoping it would return 8.
>
>I can modify it so that string->number does not support the Java octal syntax by default.
>
>This little issue actually goes to the heart of JScheme since what is unique about Jscheme is the tight
>integration with Java and that integration is made possibly by our decision to adopt the Java primitive types
>as the Scheme base types. The Java literal syntax is then essential to making JScheme integrate smoothly with
>Java.
>
>Perhaps the idea should be that string->number has Scheme R4RS as its heritage and should therefore
>rely on the R4RS syntax primarily (hence disallowing octal notation entirely???)
>
>We could then follow Jonathan's suggestion and have a string->JavaNumber  procedure which would parse
>strings in the same way as the default Scheme reader parses numbers.
>
>This thread also raises the issue of documentation.
>
>One of my goals is to minimize documentation by outsourcing it, i.e. we can say that the JScheme literal syntax
>(at least in useJavaSyntax mode) is precisely the Java Literal syntax mode, except for some slight differences
>(#t  #f   #'...'     #(.....))
>This frees the Java programmer from having to learn a new syntax for literals and eases the transition between
>the two languages.
>
>---Tim----
>
>>
>>At 07:27 PM 6/6/2004 -0400, Timothy John Hickey wrote:
>>>I've modified string->number so that in the base 10 case it allows leading zeroes...
>>>The following Unit tests all pass in the current version of JScheme...
>>>
>>> "06/06/2004" ;; literal syntax, TJH
>>>
>>> ;; Default literal syntax is for Java literals,
>>>
>>> ;; but string->number will treat leading zeroes as decimal if base 10 is specified
>>>
>>> (equal? (.getClass '081) jsint.Symbol.class)
>>>
>>> (equal? (.getClass '0123Dig) jsint.Symbol.class)
>>>
>>> (equal? (.getClass '0123) java.lang.Integer.class)
>>>
>>> (equal? (string->number "081" 10) 81)
>>>
>>> (equal? (string->number "010") 10)
>>>
>>> (equal? (string->number "010" 8) 8)
>>>
>>> (equal? (tryCatch (string->number "081" 8) (lambda(e) 'error)) 'error)
>>>
>>> (equal? (string->number "08") #f)
>>>
>>> (equal? (string->number "08" 10) 8)
>>>
>>> (equal? (string->number "10") 8)
>>>
>>> (equal? (string->number "10" 10) 10)
>>>
>>>The implementation of string->number in the base 10 case is
>>>
>>>> public static Object schemeStringToNumber(String tok, int rdx) {
>>>>   try { return U.toNum(Long.parseLong(tok, rdx)); }
>>>>    catch (NumberFormatException e) {
>>>>        try {
>>>>            if (rdx!=10)
>>>>                return U.FALSE;
>>>>            else return new Double(tok); }
>>>>        catch (NumberFormatException e2)
>>>>            { return U.FALSE; }
>>>>    }
>>>> }
>>>
>>>---Tim---
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.Net email is sponsored by the new InstallShield X.
>>> From Windows to Linux, servers to mobile, InstallShield X is the one
>>>installation-authoring solution that does it all. Learn more and
>>>evaluate today! http://www.installshield.com/Dev2Dev/0504
>>>_______________________________________________
>>>Jscheme-devel mailing list
>>>Jsc...@li...
>>>https://lists.sourceforge.net/lists/listinfo/jscheme-devel
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by the new InstallShield X.
>>>From Windows to Linux, servers to mobile, InstallShield X is the one
>>installation-authoring solution that does it all. Learn more and
>>evaluate today! http://www.installshield.com/Dev2Dev/0504
>>_______________________________________________
>>Jscheme-devel mailing list
>>Jsc...@li...
>>https://lists.sourceforge.net/lists/listinfo/jscheme-devel

Re: [Jscheme-devel] string->number

[Geoffrey K. <ge...@kn...>]

On Jun 7, 2004, at 10:44, Timothy John Hickey wrote:
> This little issue actually goes to the heart of JScheme since what is=20=

> unique about Jscheme is the tight
> integration with Java and that integration is made possibly by our=20
> decision to adopt the Java primitive types
> as the Scheme base types. The Java literal syntax is then essential to=20=

> making JScheme integrate smoothly with
> Java.

This is a worthy goal.  I certainly remember how impressed I was when=20
the first Java language and VM specs came out, so painstakingly=20
developed.  But then even Java has warts, for example:

"How Java=92s Floating-Point Hurts Everyone Everywhere"
http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf

Principle of Least Surprise ... What is more of an unpleasant surprise?
1.  (string->number "08") =3D> 8
2.  (string->number "08") =3D> #f
3.  (string->number "010") =3D> 10
4.  (string->number "010") =3D> 8

My feeling is that anyone who wants octal interpretation won't mind=20
saying so:
(string->number "010" 8) =3D> 8

Good morning, Alexander.  How old will you be next year?
    010
I see you entered a leading zero.  You're too clever.  I wasn't=20
expecting that.  Like many 7 year-olds, I bet sometimes you wish you=20
were 10.

Geoffrey
--
Geoffrey S. Knauth | http://knauth.org/gsk

Re: [Jscheme-devel] string->number

[Geoffrey K. <ge...@kn...>]

On Jun 7, 2004, at 10:24, Ken Anderson wrote:
> So the remaining issue is what should (string->number "08") return.  
> It currently returns #f. i was hoping it would return 8.

(string->number "08") => 8 would be consistent with C

I just tried scanf of 08, 09, 010 in C, and got 8, 9, 10.

However, C is not always consistent with itself; 08 cannot be used as a 
constant:
foo.c:9:19: invalid digit "8" in octal constant

Since Tim's unit tests already include:
(equal? (string->number "010") 10)

I think (string->number string-value) in the absence of radix should 
assume a radix of 10.

Geoffrey
--
Geoffrey S. Knauth | http://knauth.org/gsk

Re: [Jscheme-devel] string->number

[Timothy J. H. <ti...@cs...>]

On Jun 7, 2004, at 10:24 AM, Ken Anderson wrote:

> So the remaining issue is what should (string->number "08") return.  
> It currently returns #f. i was hoping it would return 8.

I can modify it so that string->number does not support the Java octal 
syntax by default.

This little issue actually goes to the heart of JScheme since what is 
unique about Jscheme is the tight
integration with Java and that integration is made possibly by our 
decision to adopt the Java primitive types
as the Scheme base types. The Java literal syntax is then essential to 
making JScheme integrate smoothly with
Java.

Perhaps the idea should be that string->number has Scheme R4RS as its 
heritage and should therefore
rely on the R4RS syntax primarily (hence disallowing octal notation 
entirely???)

We could then follow Jonathan's suggestion and have a 
string->JavaNumber  procedure which would parse
strings in the same way as the default Scheme reader parses numbers.

This thread also raises the issue of documentation.

One of my goals is to minimize documentation by outsourcing it, i.e. we 
can say that the JScheme literal syntax
(at least in useJavaSyntax mode) is precisely the Java Literal syntax 
mode, except for some slight differences
(#t  #f   #'...'     #(.....))
This frees the Java programmer from having to learn a new syntax for 
literals and eases the transition between
the two languages.

---Tim----

>
> At 07:27 PM 6/6/2004 -0400, Timothy John Hickey wrote:
>> I've modified string->number so that in the base 10 case it allows 
>> leading zeroes...
>> The following Unit tests all pass in the current version of JScheme...
>>
>>  "06/06/2004" ;; literal syntax, TJH
>>
>>  ;; Default literal syntax is for Java literals,
>>
>>  ;; but string->number will treat leading zeroes as decimal if base 
>> 10 is specified
>>
>>  (equal? (.getClass '081) jsint.Symbol.class)
>>
>>  (equal? (.getClass '0123Dig) jsint.Symbol.class)
>>
>>  (equal? (.getClass '0123) java.lang.Integer.class)
>>
>>  (equal? (string->number "081" 10) 81)
>>
>>  (equal? (string->number "010") 10)
>>
>>  (equal? (string->number "010" 8) 8)
>>
>>  (equal? (tryCatch (string->number "081" 8) (lambda(e) 'error)) 
>> 'error)
>>
>>  (equal? (string->number "08") #f)
>>
>>  (equal? (string->number "08" 10) 8)
>>
>>  (equal? (string->number "10") 8)
>>
>>  (equal? (string->number "10" 10) 10)
>>
>> The implementation of string->number in the base 10 case is
>>
>>>  public static Object schemeStringToNumber(String tok, int rdx) {
>>>    try { return U.toNum(Long.parseLong(tok, rdx)); }
>>>     catch (NumberFormatException e) {
>>>         try {
>>>             if (rdx!=10)
>>>                 return U.FALSE;
>>>             else return new Double(tok); }
>>>         catch (NumberFormatException e2)
>>>             { return U.FALSE; }
>>>     }
>>>  }
>>
>> ---Tim---
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by the new InstallShield X.
>> From Windows to Linux, servers to mobile, InstallShield X is the one
>> installation-authoring solution that does it all. Learn more and
>> evaluate today! http://www.installshield.com/Dev2Dev/0504
>> _______________________________________________
>> Jscheme-devel mailing list
>> Jsc...@li...
>> https://lists.sourceforge.net/lists/listinfo/jscheme-devel
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
>> From Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Jscheme-devel mailing list
> Jsc...@li...
> https://lists.sourceforge.net/lists/listinfo/jscheme-devel

Re: [Jscheme-devel] string->number

[Ken A. <kan...@bb...>]

So the remaining issue is what should (string->number "08") return.  It currently returns #f. i was hoping it would return 8. 

At 07:27 PM 6/6/2004 -0400, Timothy John Hickey wrote:
>I've modified string->number so that in the base 10 case it allows leading zeroes...
>The following Unit tests all pass in the current version of JScheme...
>
>  "06/06/2004" ;; literal syntax, TJH
>
>  ;; Default literal syntax is for Java literals,
>
>  ;; but string->number will treat leading zeroes as decimal if base 10 is specified
>
>  (equal? (.getClass '081) jsint.Symbol.class)
>
>  (equal? (.getClass '0123Dig) jsint.Symbol.class)
>
>  (equal? (.getClass '0123) java.lang.Integer.class)
>
>  (equal? (string->number "081" 10) 81)
>
>  (equal? (string->number "010") 10)
>
>  (equal? (string->number "010" 8) 8)
>
>  (equal? (tryCatch (string->number "081" 8) (lambda(e) 'error)) 'error)
>
>  (equal? (string->number "08") #f)
>
>  (equal? (string->number "08" 10) 8)
>
>  (equal? (string->number "10") 8)
>
>  (equal? (string->number "10" 10) 10)
>
>The implementation of string->number in the base 10 case is
>
>>  public static Object schemeStringToNumber(String tok, int rdx) {
>>    try { return U.toNum(Long.parseLong(tok, rdx)); }
>>     catch (NumberFormatException e) {
>>         try {
>>             if (rdx!=10)
>>                 return U.FALSE;
>>             else return new Double(tok); }
>>         catch (NumberFormatException e2)
>>             { return U.FALSE; }
>>     }
>>  }
>
>---Tim---
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by the new InstallShield X.
> From Windows to Linux, servers to mobile, InstallShield X is the one
>installation-authoring solution that does it all. Learn more and
>evaluate today! http://www.installshield.com/Dev2Dev/0504
>_______________________________________________
>Jscheme-devel mailing list
>Jsc...@li...
>https://lists.sourceforge.net/lists/listinfo/jscheme-devel

[Jscheme-devel] string->number

[Timothy J. H. <tim...@ma...>]

I've modified string->number so that in the base 10 case it allows 
leading zeroes...
The following Unit tests all pass in the current version of JScheme...

   "06/06/2004" ;; literal syntax, TJH

   ;; Default literal syntax is for Java literals,

   ;; but string->number will treat leading zeroes as decimal if base 10 
is specified

   (equal? (.getClass '081) jsint.Symbol.class)

   (equal? (.getClass '0123Dig) jsint.Symbol.class)

   (equal? (.getClass '0123) java.lang.Integer.class)

   (equal? (string->number "081" 10) 81)

   (equal? (string->number "010") 10)

   (equal? (string->number "010" 8) 8)

   (equal? (tryCatch (string->number "081" 8) (lambda(e) 'error)) 'error)

   (equal? (string->number "08") #f)

   (equal? (string->number "08" 10) 8)

   (equal? (string->number "10") 8)

   (equal? (string->number "10" 10) 10)

The implementation of string->number in the base 10 case is

>   public static Object schemeStringToNumber(String tok, int rdx) {
>     try { return U.toNum(Long.parseLong(tok, rdx)); }
>      catch (NumberFormatException e) {
>          try {
>              if (rdx!=10)
>                  return U.FALSE;
>              else return new Double(tok); }
>          catch (NumberFormatException e2)
>              { return U.FALSE; }
>      }
>   }
>

---Tim---

Re: [Jscheme-devel] jscheme/prims.scm update

[Timothy J. H. <ti...@cs...>]

On May 27, 2004, at 11:10 AM, Ken Anderson wrote:

> Yes, using generics which are built on reflection is about 3 times 
> slower.
> However, it is a good way to bootstrap a simple Scheme.  Maybe we 
> could take your primitives and generate Primitives.java from it.
Thats an interesting idea. One approach is to jsint.Compile it to 
create Primitives.java which can then be .load'ed in an environment....
>
> Can you check in the Gabriel benchmarks so we can use them as a 
> performance test?
I've checked them in .. you can run the benchmarks using the (runall) 
command in using/gabriel/runbenchmark.sch

as follows
>
>> tim% java -jar lib/jscheme.jar  using/gabriel/runbenchmark.sch 
>> '(runall)'
>>
>> CPSTAK::(2689 msec)
>> CTAK::(29928 msec)
>> Dderiv::(2689 msec)
>> Deriv::(1840 msec)
>> Destructive::(5306 msec)
>> Div-iter::(1847 msec)
>> Div-rec::(1900 msec)
>> FFT::(11777 msec)
>> Fprint::(137 msec)
>> Fread::(335 msec)
>> Puzzle::
>> Success in 13 trials.(207 msec)
>> TAK::(1087 msec)
>> TAKL::(9117 msec)
>> TAKR::(1193 msec)
>>
>

We should write something which computes a total time so we can get a 
single number measure of how performance changes
when a change is made.....


>
> BTW, Henry Baker showed that some of the benchmarks can be rewritten 
> so they become so fast they no longer become useful benchmarks.
> http://home.pipeline.com/~hbaker1/home.html
Maybe its time to start building a Scheme benchmark set!
We could start with the Great Programming Language Shootout...

---Tim---

>
> At 09:37 AM 5/27/2004 -0400, Timothy John Hickey wrote:
>> Report on direct implementation of primitives in javadot...
>>
>> The jscheme/prims.scm approach still has a way to go before it is 
>> competitive with
>> our current approach. I ran the gabriel benchmarks on standard JScheme
>> (on a 1 GHZ PowerPC G4 Mac OSX 10.3.4)
>> and then ran it again after loading in jscheme/prims.scm
>>
>> It appears that the pure javadot implementation is about 3-5 times 
>> slower
>> (and there are still a few bugs! which cause FFT, Fprint and Fread 
>> not to work,
>> I'll isolate them and put them in jscheme/SchemeTests.scm...)
>>
>>
>>                          CPSTAK CTAK      Dderiv  Deriv  Destructive 
>> Div-iter   Div-rec
>> Mac G4/std        1839      26520      2682     1833     5407
>> 1834       1887
>> Mac G4/prims    8162   134623    21427   22026  39038       5885
>> 5701
>>
>>                                FFT    Fprint    Fread   Puzzle  TAK
>> TAKL    TAKR
>> Mac G4/std          10712  116         480     241     1072      8584
>> 1162
>> Mac G4/prims      FAIL    FAIL        FAIL    650     6946    27842
>> 7381
>>
>> Using the javadot notation seems to double the time for standard 
>> primitives (note (car x) is defined by x.first() in primitives.scm)
>>> (define L '(a b c d e f g))
>>> (time (car L) 100000)    ---> (a (422 msec) (357280 bytes))
>>> (time (.first$ L) 100000)---> (a (869 msec) (357280 bytes))
>>
>> also adding a lambda layer makes the time triple that of the regular 
>> primitive
>>> (define (mycar L) (.first$ L))   ---> (lambda mycar (L)...)
>>> (time (mycar L) 100000) ---> (a (1207 msec) (163008 bytes))
>>
>> This provides an automatic slowdown of about 3.
>> Compilation could remove most of this slowdown if done well.
>>
>> ---Tim---
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: Oracle 10g
>> Get certified on the hottest thing ever to hit the market... Oracle 
>> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
>> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>> _______________________________________________
>> Jscheme-devel mailing list
>> Jsc...@li...
>> https://lists.sourceforge.net/lists/listinfo/jscheme-devel
>

Re: [Jscheme-devel] CVS-update

[Ken A. <kan...@bb...>]

Also symbols like 0123Dig seem no longer to be allowed.

At 07:19 AM 5/27/2004 -0400, Timothy John Hickey wrote:
>Sorry,
>  I forgot to check in the fix.  I modified the code so that it throws a format error
>if it reads a number with a leading zero and digits 8 or greater....
>I've checked in the fix to CVS and the compiler error should disappear!
>---Tim---
>
>On May 26, 2004, at 6:18 PM, Geoffrey Knauth wrote:
>
>>I got those too today, but I ignored them, because in the past ignorable errors were part of the build, and they were so labeled.  
>>Today I ended up with a JAR that was usable.  Were today's errors ignorable?
>>
>>Geoffrey
>>--
>>Geoffrey S. Knauth | http://knauth.org/gsk
>>
>>On May 26, 2004, at 18:05, Ken Anderson wrote:
>>
>>>Tim, i m getting these errors when i compile:
>>>
>>>Compiling the compiler....
>>>** WARNING: Error during load (lineno 511): jsint.BacktraceException[
>>>
>>>("0" )
>>>
>>>  ====================================
>>>java.lang.NumberFormatException: floating point starting with 0 is either an octal or 0.ddd
>>>]
>>>
>>>("0" )
>>>
>>>  ====================================
>>>java.lang.NumberFormatException: floating point starting with 0 is either an octal or 0.ddd
>>>** WARNING: Extra ) ignored -- line number 511
>>>** WARNING: Extra ) ignored -- line number 511
>>>** WARNING: Error during load (lineno 512): jsint.BacktraceException[
>>>
>>>("0" )
>>>
>>>  ====================================
>>>java.lang.NumberFormatException: floating point starting with 0 is either an octal or 0.ddd
>>>]
>>>
>>>("0" )
>>>
>>>  ====================================
>>>java.lang.NumberFormatException: floating point starting with 0 is either an octal or 0.ddd
>>>** WARNING: Extra ) ignored -- line number 512
>>>** WARNING: Extra ) ignored -- line number 512
>>>** WARNING: Error during load (lineno 517): jsint.BacktraceException[
>>>
>>>("0" )
>>>
>>>  ====================================
>>>java.lang.NumberFormatException: floating point starting with 0 is either an octal or 0.ddd
>>>]
>>>
>>>("0" )
>>>
>>>  ====================================
>>>java.lang.NumberFormatException: floating point starting with 0 is either an octal or 0.ddd
>>>** WARNING: Extra ) ignored -- line number 517
>>>** WARNING: Extra ) ignored -- line number 517
>>>** WARNING: Extra ) ignored -- line number 637
>>>
>>>
>>>**************** Running jscheme/ScemeTests.scm ******************
>>>several warnings should appear below as certain error conditions are tested
>>>this is to be expected and does not signal a problem with the tests
>>>
>>>Tests: 0 Failures: 0
>>>
>>>All tests have completed with any errors as shown above
>>>Try (run-tests #t) to see both failing and successful tests and their results
>>>********************* jscheme/SchemeTests.scm has completed ***********************
>>>
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.Net email is sponsored by: Oracle 10g
>>>Get certified on the hottest thing ever to hit the market... Oracle 10g.
>>>Take an Oracle 10g class now, and we'll give you the exam FREE.
>>>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>>>_______________________________________________
>>>Jscheme-devel mailing list
>>>Jsc...@li...
>>>https://lists.sourceforge.net/lists/listinfo/jscheme-devel
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: Oracle 10g
>>Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
>>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>>_______________________________________________
>>Jscheme-devel mailing list
>>Jsc...@li...
>>https://lists.sourceforge.net/lists/listinfo/jscheme-devel

Re: [Jscheme-devel] jscheme/prims.scm update

[Ken A. <kan...@bb...>]

Yes, using generics which are built on reflection is about 3 times slower.
However, it is a good way to bootstrap a simple Scheme.  Maybe we could take your primitives and generate Primitives.java from it.

Can you check in the Gabriel benchmarks so we can use them as a performance test?

BTW, Henry Baker showed that some of the benchmarks can be rewritten so they become so fast they no longer become useful benchmarks.
http://home.pipeline.com/~hbaker1/home.html

At 09:37 AM 5/27/2004 -0400, Timothy John Hickey wrote:
>Report on direct implementation of primitives in javadot...
>
>The jscheme/prims.scm approach still has a way to go before it is competitive with
>our current approach. I ran the gabriel benchmarks on standard JScheme
>(on a 1 GHZ PowerPC G4 Mac OSX 10.3.4)
>and then ran it again after loading in jscheme/prims.scm
>
>It appears that the pure javadot implementation is about 3-5 times slower
>(and there are still a few bugs! which cause FFT, Fprint and Fread not to work,
>I'll isolate them and put them in jscheme/SchemeTests.scm...)
>
>
>                          CPSTAK CTAK      Dderiv  Deriv  Destructive Div-iter   Div-rec
>Mac G4/std        1839      26520      2682     1833     5407       
>1834       1887
>Mac G4/prims    8162   134623    21427   22026  39038       5885       
>5701
>
>                                FFT    Fprint    Fread   Puzzle  TAK    
> TAKL    TAKR
>Mac G4/std          10712  116         480     241     1072      8584   
>1162
>Mac G4/prims      FAIL    FAIL        FAIL    650     6946    27842   
>7381
>
>Using the javadot notation seems to double the time for standard primitives (note (car x) is defined by x.first() in primitives.scm)
>> (define L '(a b c d e f g))
>> (time (car L) 100000)    ---> (a (422 msec) (357280 bytes))
>> (time (.first$ L) 100000)---> (a (869 msec) (357280 bytes))
>
>also adding a lambda layer makes the time triple that of the regular primitive
>> (define (mycar L) (.first$ L))   ---> (lambda mycar (L)...)
>> (time (mycar L) 100000) ---> (a (1207 msec) (163008 bytes))
>
>This provides an automatic slowdown of about 3.
>Compilation could remove most of this slowdown if done well.
>
>---Tim---
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>_______________________________________________
>Jscheme-devel mailing list
>Jsc...@li...
>https://lists.sourceforge.net/lists/listinfo/jscheme-devel

[Jscheme-devel] jscheme/prims.scm update

[Timothy J. H. <tim...@ma...>]

Report on direct implementation of primitives in javadot...

The jscheme/prims.scm approach still has a way to go before it is 
competitive with
our current approach. I ran the gabriel benchmarks on standard JScheme
(on a 1 GHZ PowerPC G4 Mac OSX 10.3.4)
and then ran it again after loading in jscheme/prims.scm

It appears that the pure javadot implementation is about 3-5 times 
slower
(and there are still a few bugs! which cause FFT, Fprint and Fread not 
to work,
I'll isolate them and put them in jscheme/SchemeTests.scm...)


                           CPSTAK CTAK      Dderiv  Deriv  Destructive 
Div-iter   Div-rec
Mac G4/std        1839      26520      2682     1833     5407       
1834       1887
Mac G4/prims    8162   134623    21427   22026  39038       5885       
5701

                                 FFT    Fprint    Fread   Puzzle  TAK    
  TAKL    TAKR
Mac G4/std          10712  116         480     241     1072      8584   
1162
Mac G4/prims      FAIL    FAIL        FAIL    650     6946    27842   
7381

Using the javadot notation seems to double the time for standard 
primitives (note (car x) is defined by x.first() in primitives.scm)
 > (define L '(a b c d e f g))
 > (time (car L) 100000)    ---> (a (422 msec) (357280 bytes))
 > (time (.first$ L) 100000)---> (a (869 msec) (357280 bytes))

also adding a lambda layer makes the time triple that of the regular 
primitive
 > (define (mycar L) (.first$ L))   ---> (lambda mycar (L)...)
 > (time (mycar L) 100000) ---> (a (1207 msec) (163008 bytes))

This provides an automatic slowdown of about 3.
Compilation could remove most of this slowdown if done well.

---Tim---

Re: [Jscheme-devel] CVS-update

[Timothy J. H. <tim...@ma...>]

Sorry,
   I forgot to check in the fix.  I modified the code so that it throws 
a format error
if it reads a number with a leading zero and digits 8 or greater....
I've checked in the fix to CVS and the compiler error should disappear!
---Tim---

On May 26, 2004, at 6:18 PM, Geoffrey Knauth wrote:

> I got those too today, but I ignored them, because in the past 
> ignorable errors were part of the build, and they were so labeled.  
> Today I ended up with a JAR that was usable.  Were today's errors 
> ignorable?
>
> Geoffrey
> --
> Geoffrey S. Knauth | http://knauth.org/gsk
>
> On May 26, 2004, at 18:05, Ken Anderson wrote:
>
>> Tim, i m getting these errors when i compile:
>>
>> Compiling the compiler....
>> ** WARNING: Error during load (lineno 511): jsint.BacktraceException[
>>
>> ("0" )
>>
>>   ====================================
>> java.lang.NumberFormatException: floating point starting with 0 is 
>> either an octal or 0.ddd
>> ]
>>
>> ("0" )
>>
>>   ====================================
>> java.lang.NumberFormatException: floating point starting with 0 is 
>> either an octal or 0.ddd
>> ** WARNING: Extra ) ignored -- line number 511
>> ** WARNING: Extra ) ignored -- line number 511
>> ** WARNING: Error during load (lineno 512): jsint.BacktraceException[
>>
>> ("0" )
>>
>>   ====================================
>> java.lang.NumberFormatException: floating point starting with 0 is 
>> either an octal or 0.ddd
>> ]
>>
>> ("0" )
>>
>>   ====================================
>> java.lang.NumberFormatException: floating point starting with 0 is 
>> either an octal or 0.ddd
>> ** WARNING: Extra ) ignored -- line number 512
>> ** WARNING: Extra ) ignored -- line number 512
>> ** WARNING: Error during load (lineno 517): jsint.BacktraceException[
>>
>> ("0" )
>>
>>   ====================================
>> java.lang.NumberFormatException: floating point starting with 0 is 
>> either an octal or 0.ddd
>> ]
>>
>> ("0" )
>>
>>   ====================================
>> java.lang.NumberFormatException: floating point starting with 0 is 
>> either an octal or 0.ddd
>> ** WARNING: Extra ) ignored -- line number 517
>> ** WARNING: Extra ) ignored -- line number 517
>> ** WARNING: Extra ) ignored -- line number 637
>>
>>
>> **************** Running jscheme/ScemeTests.scm ******************
>> several warnings should appear below as certain error conditions are 
>> tested
>> this is to be expected and does not signal a problem with the tests
>>
>> Tests: 0 Failures: 0
>>
>> All tests have completed with any errors as shown above
>> Try (run-tests #t) to see both failing and successful tests and their 
>> results
>> ********************* jscheme/SchemeTests.scm has completed 
>> ***********************
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: Oracle 10g
>> Get certified on the hottest thing ever to hit the market... Oracle 
>> 10g.
>> Take an Oracle 10g class now, and we'll give you the exam FREE.
>> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>> _______________________________________________
>> Jscheme-devel mailing list
>> Jsc...@li...
>> https://lists.sourceforge.net/lists/listinfo/jscheme-devel
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 
> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Jscheme-devel mailing list
> Jsc...@li...
> https://lists.sourceforge.net/lists/listinfo/jscheme-devel

[Jscheme-devel] New Approach to primitives

[Timothy J. H. <tim...@ma...>]

I'm thinking about changing our approach to primitives.

I've written all of the primitives directly in javadot and the built-in 
JScheme
special forms (set!, macro, if , or, lambda, quote, begin.
See jscheme/prims.scm

You can try it out like this...

> tim% java -cp lib/jscheme.jar jscheme.REPL
>
>
> JScheme 7.0 5/25/04 http://jscheme.sourceforge.net
>
>
;;;First blow away the old environment ... and get left with just 
javadot and 7 special forms...
> > (.INTERACTION_ENVIRONMENT$ (Scheme.currentEvaluator) 
> (jsint.DynamicEnvironment.))
> jsint.DynamicEnvironment@c21ece
;; now load up the new prims
> > (Scheme.load "jscheme/prims.scm")
> #t
;; and run the Scheme Tests successfully
> > (load "jscheme/SchemeTests.scm")
>
>
> **************** Running jscheme/ScemeTests.scm ******************
> several warnings should appear below as certain error conditions are 
> tested
> this is to be expected and does not signal a problem with the tests
>
> ** WARNING: No such  instance  method "equalsFirst" in class jsint.Pair
> ** WARNING: No such  instance  method "equalsFirst" in class jsint.Pair
> ** WARNING: No such  static  method "hashCode0" in class jsint.Pair
> ** WARNING: No such  static  method "hashCode0" in class jsint.Pair
> Tests: 266 Failures: 0
>
> All tests have completed with any errors as shown above
> Try (run-tests #t) to see both failing and successful tests and their 
> results
> ********************* jscheme/SchemeTests.scm has completed 
> ***********************
>
> #t
> > (exit)
> [Timothy-Hickeys-Computer:~/Research/Software/jscheme] tim%

The performance seems fairly close to the current performance.

I've downloaded the gabriel benchmarks for scheme and will compare the
two versions. I'd like to replace the primitives.scm, Primitive.scm, 
and primproc.scm
in jsint, with jscheme/prims.scm. The idea would be to load 
jscheme/prims.scm
directly into an evaluator with the NULL_ENVIRONMENT.

The advantage of doing everything in Scheme is that we get to program 
in Scheme
instead of Java, and I don't think there will be much of a performance 
penalty.

---Tim---

[Jscheme-devel] build error

[Timothy H. <tim...@ma...>]

I checked in a fix to the build error, it should build
without problems now...

I had modified the InputPort.java to throw an error when
it encountered a malformed octal number (e.g. 018), but
it was also objecting to 0l 0d 0f etc. which appear in
SchemeTests.scm.  The last CVS check in fixed that.

The next thing to do is to modify the "Scheme mode" reader
so that it accepts 00018 as just 18 which is what Jonathan Rees
was asking for. This will allow the user to switch the reader
mode to read java-style literals or RNRS-literals.

---Tim---

Re: [Jscheme-devel] CVS-update

[Geoffrey K. <ge...@kn...>]

I got those too today, but I ignored them, because in the past 
ignorable errors were part of the build, and they were so labeled.  
Today I ended up with a JAR that was usable.  Were today's errors 
ignorable?

Geoffrey
--
Geoffrey S. Knauth | http://knauth.org/gsk

On May 26, 2004, at 18:05, Ken Anderson wrote:

> Tim, i m getting these errors when i compile:
>
> Compiling the compiler....
> ** WARNING: Error during load (lineno 511): jsint.BacktraceException[
>
> ("0" )
>
>   ====================================
> java.lang.NumberFormatException: floating point starting with 0 is 
> either an octal or 0.ddd
> ]
>
> ("0" )
>
>   ====================================
> java.lang.NumberFormatException: floating point starting with 0 is 
> either an octal or 0.ddd
> ** WARNING: Extra ) ignored -- line number 511
> ** WARNING: Extra ) ignored -- line number 511
> ** WARNING: Error during load (lineno 512): jsint.BacktraceException[
>
> ("0" )
>
>   ====================================
> java.lang.NumberFormatException: floating point starting with 0 is 
> either an octal or 0.ddd
> ]
>
> ("0" )
>
>   ====================================
> java.lang.NumberFormatException: floating point starting with 0 is 
> either an octal or 0.ddd
> ** WARNING: Extra ) ignored -- line number 512
> ** WARNING: Extra ) ignored -- line number 512
> ** WARNING: Error during load (lineno 517): jsint.BacktraceException[
>
> ("0" )
>
>   ====================================
> java.lang.NumberFormatException: floating point starting with 0 is 
> either an octal or 0.ddd
> ]
>
> ("0" )
>
>   ====================================
> java.lang.NumberFormatException: floating point starting with 0 is 
> either an octal or 0.ddd
> ** WARNING: Extra ) ignored -- line number 517
> ** WARNING: Extra ) ignored -- line number 517
> ** WARNING: Extra ) ignored -- line number 637
>
>
> **************** Running jscheme/ScemeTests.scm ******************
> several warnings should appear below as certain error conditions are 
> tested
> this is to be expected and does not signal a problem with the tests
>
> Tests: 0 Failures: 0
>
> All tests have completed with any errors as shown above
> Try (run-tests #t) to see both failing and successful tests and their 
> results
> ********************* jscheme/SchemeTests.scm has completed 
> ***********************
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 
> 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Jscheme-devel mailing list
> Jsc...@li...
> https://lists.sourceforge.net/lists/listinfo/jscheme-devel
>

Re: [Jscheme-devel] CVS-update

[Ken A. <kan...@bb...>]

Tim, i m getting these errors when i compile:

Compiling the compiler....
** WARNING: Error during load (lineno 511): jsint.BacktraceException[
  
("0" )

  ====================================
java.lang.NumberFormatException: floating point starting with 0 is either an octal or 0.ddd
]

("0" )

  ====================================
java.lang.NumberFormatException: floating point starting with 0 is either an octal or 0.ddd
** WARNING: Extra ) ignored -- line number 511
** WARNING: Extra ) ignored -- line number 511
** WARNING: Error during load (lineno 512): jsint.BacktraceException[
  
("0" )

  ====================================
java.lang.NumberFormatException: floating point starting with 0 is either an octal or 0.ddd
]

("0" )

  ====================================
java.lang.NumberFormatException: floating point starting with 0 is either an octal or 0.ddd
** WARNING: Extra ) ignored -- line number 512
** WARNING: Extra ) ignored -- line number 512
** WARNING: Error during load (lineno 517): jsint.BacktraceException[
  
("0" )

  ====================================
java.lang.NumberFormatException: floating point starting with 0 is either an octal or 0.ddd
]

("0" )

  ====================================
java.lang.NumberFormatException: floating point starting with 0 is either an octal or 0.ddd
** WARNING: Extra ) ignored -- line number 517
** WARNING: Extra ) ignored -- line number 517
** WARNING: Extra ) ignored -- line number 637


**************** Running jscheme/ScemeTests.scm ******************
several warnings should appear below as certain error conditions are tested
this is to be expected and does not signal a problem with the tests

Tests: 0 Failures: 0

All tests have completed with any errors as shown above
Try (run-tests #t) to see both failing and successful tests and their results
********************* jscheme/SchemeTests.scm has completed ***********************

[Jscheme-devel] CVS going to jscheme-cvs@lists.sourceforge.net

[Timothy J. H. <tim...@ma...>]

I've changed the CVS server so that all CVS notification will go to the 
jsc...@li...
mailing list. That will clear up this list for discussions about 
technical implementation issues...

If you want CVS notification you need to join the jscheme-cvs list ...

---Tim---

[Jscheme-devel] CVS-update

[Timothy J. H. <tim...@us...>]

Update of /cvsroot/jscheme/CVSROOT
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv11716

Modified Files:
	loginfo 
Log Message:
more testing of CVS notification

[Jscheme-devel] CVS-update

[Timothy J. H. <tim...@us...>]

Update of /cvsroot/jscheme/CVSROOT
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv11544

Modified Files:
	loginfo 
Log Message:
more testing of CVS notification

[Jscheme-devel] CVS-update

[Timothy J. H. <tim...@us...>]

Update of /cvsroot/jscheme/CVSROOT
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6765

Modified Files:
	loginfo 
Added Files:
	syncmail 
Log Message:
modifying loginfo so CVS notification goes to jscheme-cvs not jscheme-devel

[Jscheme-devel] CVS-update

[Timothy J. H. <tim...@us...>]

Update of /cvsroot/jscheme/jscheme/src/jscheme
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4887/src/jscheme

Modified Files:
	BootstrapCore.scm BootstrapR4RSa.scm 
Log Message:
implemented all R4RS primitives in javadot

[Jscheme-devel] CVS-update

[Timothy J. H. <tim...@us...>]

Update of /cvsroot/jscheme/jscheme/src/elf
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4887/src/elf

Modified Files:
	mbe.scm 
Log Message:
implemented all R4RS primitives in javadot