jscheme-devel Mailing List for The Jscheme Web Programming Project

This is a test method to see if it will be sent to the moderators,  
who can feel free to kill it!!

> strict-import sounds like a reasonable feature.  The only thing I
> don't like about it is users having to change their imports into
> strict-imports.  Users might get paranoid that "import" is no longer
> good enough, so then they'd be typing the longer version all the
> time.  I wonder if it would be possible to do something like (strict-
> imports boolean) so that people wouldn't have to change their code,
> only the current loading behavior.


I actually prefer the strict-imports form you're suggesting.  It would have
to modify the interpreter instance or set a global correct?  Adding the
strict import at the top of a module/file would be nice since it would
effectively be a declaration.  Would it just have file/module scope or in
the entire interpreter?  I'm not sure what the best way would be to
implement this in the current code base.

Further comments below.
>
> > We're using JScheme in one of our production applications (for a
> > DSL) and we're looking to have it be as strict as possible so that
> > we end up deferring as few errors/issues to runtime as possible.
> > Detecting failed class imports (when the class is not actually on
> > the classpath) would help towards this goal.
>
> I like that argument.  I could have used it in previous battles
> discussions with management in years past.


There are probably a lot of features that could be added to help in this
respect (especially if they were optional, as suggested above).  I actually
would have pushed to use JScheme more if it weren't for the issue of lack of
confidence in the runtime code.  Unit testing helps but only goes so far.

I wonder if anyone is still using JVMs prior to 1.2?  I guess they
> could still use "old" JScheme.



> There may be a performance difference since ArrayList and HashMap
> > are not synchronized themselves - and it looks like the code in
> > JScheme is doing a lot of the synchronization itself anyway.
>
> We can run tests!


Since you brought that up, what is the opinion on testing during the build?
I see that tests are run, but they do not cause the build to fail as far as
I can tell.  Also, what would the opinion be on using JUnit as a testing
framework?  Or even one of the common Java build tools like Maven?

We use Maven and the dependency declarations are very valuable - also, it
would have been nice if JScheme were part of the ibiblio maven repository it
could be used from maven projects (and thus automatically downloaded).



Kyle

On Sep 24, 2007, at 5:37 PM, Geoff Knauth wrote:

> I can't think of a more appropriate list!
>
> strict-import sounds like a reasonable feature.  The only thing I  
> don't like about it is users having to change their imports into  
> strict-imports.  Users might get paranoid that "import" is no  
> longer good enough, so then they'd be typing the longer version all  
> the time.  I wonder if it would be possible to do something like  
> (strict-imports boolean) so that people wouldn't have to change  
> their code, only the current loading behavior.
We could probably just change the implementation of import so that it  
signals an error if the class is not found.
This might temporarily break some old code, but only if it were  
important classes that didn't exist, in which
case the imports could be taken out or enclosed in a trycatch  
expression.

---Tim---

>
> Further comments below.
>
> On Sep 24, 2007, at 16:54, Kyle R. Burton wrote:
>
>> Is jscheme-devel the appropriate list?  I received a message  
>> indicating that the message is awaiting moderator approval.   
>> Should I just be using jscheme-users?
>>
>> Thanks,
>>
>> Kyle
>>
>> ---------- Forwarded message ----------
>> From: Kyle R. Burton <kyl...@gm...>
>> Date: Sep 24, 2007 4:49 PM
>> Subject: feature request: strict-import
>> To: jsc...@li...
>>
>> The current import function is lazy, which nice from an  
>> interactive point of view.  From knowing that the code will  
>> execute point of view, it is less desirable.  I'd like to propose  
>> an additional function: strict-import that would error if the  
>> class being imported is not actually found at the time the strict- 
>> import is processed.
>>
>> I can think of a few ways that strict-import could behave:
>>
>>   (strict-import class-name)
>>
>> In addition to calling Import.addImport, this would also validate  
>> that the class can actually be loaded, otherwise it would throw an  
>> exception (class not found exception).
>>
>>   (strict-import "class.or.package.name.*")
>>
>> If the arg prefix (dropping the wildcard) is a package name, then  
>> this works exactly as the existing import (no detectable errors).   
>> if the arg prefix is a class name, then all the static methods in  
>> the class are imported as symbols in the current environment:
>>
>>   (strict-import "java.lang.Math.*")
>>
>> Would create a function 'random in the current environment.
>>
>>   (strict-import "java.lang.Math.random")
>>
>> In this case the form is requesting the importing of a single  
>> static method from the Math class, it would create a function  
>> 'random in the current environment.
>>
>>
>> I can work at creating an example implementation some night this  
>> week (I don't expect it to be difficult) if it is warranted.
>>
>> We're using JScheme in one of our production applications (for a  
>> DSL) and we're looking to have it be as strict as possible so that  
>> we end up deferring as few errors/issues to runtime as possible.   
>> Detecting failed class imports (when the class is not actually on  
>> the classpath) would help towards this goal.
>
> I like that argument.  I could have used it in previous battles  
> discussions with management in years past.
>
>> Also, I've noticed that the implementation uses Vector and  
>> Hashtable quite a bit.  I realize that they were what was  
>> available when JScheme was created and the newer (and generally  
>> considered better) ArrayList and HashMap were not available until  
>> java 1.2.  Is there any reason at this point not to switch the  
>> code to use the newer collections framework?
>
> I wonder if anyone is still using JVMs prior to 1.2?  I guess they  
> could still use "old" JScheme.
>
>> There may be a performance difference since ArrayList and HashMap  
>> are not synchronized themselves - and it looks like the code in  
>> JScheme is doing a lot of the synchronization itself anyway.
>
> We can run tests!

On Sep 24, 2007, at 4:49 PM, Kyle R. Burton wrote:

> The current import function is lazy, which nice from an interactive  
> point of view.  From knowing that the code will execute point of  
> view, it is less desirable.  I'd like to propose an additional  
> function: strict-import that would error if the class being  
> imported is not actually found at the time the strict-import is  
> processed.
That sounds reasonable and not too hard to implement.
>
>
> I can think of a few ways that strict-import could behave:
>
>   (strict-import class-name)
>
> In addition to calling Import.addImport, this would also validate  
> that the class can actually be loaded, otherwise it would throw an  
> exception (class not found exception).
>
>   (strict-import "class.or.package.name.*")
>
> If the arg prefix (dropping the wildcard) is a package name, then  
> this works exactly as the existing import (no detectable errors).   
> if the arg prefix is a class name, then all the static methods in  
> the class are imported as symbols in the current environment:
>
>   (strict-import "java.lang.Math.*")
This is something we would need to discuss.
The nice thing about the javadot notation is that you can tell by  
looking at a procedure name if it is a Java element
and if one follows the convention of not using "." in any user- 
defined scheme names, then it separates those name
spaces syntactically.

If we break that naming convention one could import a Java class that  
contains a static method "car" which could
reek havoc with any scheme code ...

Another approach would be to specify which static methods should be  
imported without the "." notation, e.g.
      (string-import "java.lang.Math" '(random ulp IEEEremainder))

>
>
> Would create a function 'random in the current environment.
>
>   (strict-import "java.lang.Math.random")
>
> In this case the form is requesting the importing of a single  
> static method from the Math class, it would create a function  
> 'random in the current environment.
>
>
> I can work at creating an example implementation some night this  
> week (I don't expect it to be difficult) if it is warranted.
>
> We're using JScheme in one of our production applications (for a  
> DSL) and we're looking to have it be as strict as possible so that  
> we end up deferring as few errors/issues to runtime as possible.   
> Detecting failed class imports (when the class is not actually on  
> the classpath) would help towards this goal.
Adding some error checking sounds like a good idea to me..
>
>
>
> Also, I've noticed that the implementation uses Vector and  
> Hashtable quite a bit.  I realize that they were what was available  
> when JScheme was created and the newer (and generally considered  
> better) ArrayList and HashMap were not available until java 1.2.   
> Is there any reason at this point not to switch the code to use the  
> newer collections framework?  There may be a performance difference  
> since ArrayList and HashMap are not synchronized themselves - and  
> it looks like the code in JScheme is doing a lot of the  
> synchronization itself anyway.
This is a very interesting idea.
A more ambitious project would be to rewrite the JScheme codebase  
using the newer collections and generics.
If there is enough interest we could start work on this and take the  
opportunity to clean up the code and javadoc
comments throughout....

Best,
---Tim---

The current import function is lazy, which nice from an interactive point of
view.  From knowing that the code will execute point of view, it is less
desirable.  I'd like to propose an additional function: strict-import that
would error if the class being imported is not actually found at the time
the strict-import is processed.

I can think of a few ways that strict-import could behave:

  (strict-import class-name)

In addition to calling Import.addImport, this would also validate that the
class can actually be loaded, otherwise it would throw an exception (class
not found exception).

  (strict-import "class.or.package.name.*")

If the arg prefix (dropping the wildcard) is a package name, then this works
exactly as the existing import (no detectable errors).  if the arg prefix is
a class name, then all the static methods in the class are imported as
symbols in the current environment:

  (strict-import "java.lang.Math.*")

Would create a function 'random in the current environment.

  (strict-import "java.lang.Math.random")

In this case the form is requesting the importing of a single static method
from the Math class, it would create a function 'random in the current
environment.


I can work at creating an example implementation some night this week (I
don't expect it to be difficult) if it is warranted.

We're using JScheme in one of our production applications (for a DSL) and
we're looking to have it be as strict as possible so that we end up
deferring as few errors/issues to runtime as possible.  Detecting failed
class imports (when the class is not actually on the classpath) would help
towards this goal.


Also, I've noticed that the implementation uses Vector and Hashtable quite a
bit.  I realize that they were what was available when JScheme was created
and the newer (and generally considered better) ArrayList and HashMap were
not available until java 1.2.  Is there any reason at this point not to
switch the code to use the newer collections framework?  There may be a
performance difference since ArrayList and HashMap are not synchronized
themselves - and it looks like the code in JScheme is doing a lot of the
synchronization itself anyway.


Thanks,

Kyle

Hi JScheme developers,

I've added Geoffrey Knauth as a JScheme developer. Geoff is a long  
time JScheme user
who has contributed many bug fixes over the years and has a good  
understanding of the
code base.

Best wishes,
---Tim---

Hi Guys,

I've attempted to port a few languages onto J2me, then I found Peter
Norvig's Jscheme for Java...

It's compiled size fit our budget and it offered basic Continuations,
and not so basic lambda's, recursive functions, vectors, etc and most
of R4RS. It's kinda stunning how much he fit into so little code.

Well, I haven't hit any big stumbling blocks with the port; of course,
I've had to slash out JavaMethod and any java.lang.reflect calls.
For those who don't know, MIDP 2.0 and CLDC 1.1 is pretty limited
compared to SE. It's missing almost everything in the reflection
department and there's no class loader.

An interpreter like this was very attractive because we can save so
much "building stuff" byte code using downloadable scripts and
documents (sound familar?).

Performance left alot to be desired though, but Peter offers some
helpful hints here, http://www.norvig.com/jscheme-design.html
Peter conjectures that most of the time is spent in linear lookups in
the global environment.

I switched subclasses GlobalEnvironment from Environment and use a
hashtable for setting primitives, defining them and looking them up.
It was a pleasant surprise to see a 100% increase in speed. That is,
it took half the time to do almost everything - from intensive
quicksort tests to simple random vector generation. Sweet!

I'd love to find more simple things that'll improve performance like
that because it's always great to have that things faster. The quicker
I can interpret, the more opportunity there is to include scripts in
tight render loops for controlling positions of sprites/characters on
screen, etc.

Does anyone have any other ideas for performance boosting tweaks?

I suppose anything involving lexicon lookup would help greatly, but I
was thinking more abstract tactics like lambda-pre-analysis or
intermediate interpretation or something fancy.

Anything at the end of the day that'll save cycles will be greatly appreciated.

In regards to the other environment lookups, there is more thinking I
need to do about why Scheme rampantly uses nested Pair's for lists of
things. As elegant as cons'ing things together is, it doesn't perform
terribly well on a mobile virtual machine. It'd be nice if there were
a native Hashtable type in scheme that I could map over to the Java
hashtable. I can further jack performance by using Hashtable's for all
environments, but I'm not particularly sure how to do that for all
Procedure derived types.

Does anyone know of a Hashtable implementation exists in a common
Scheme Library of sorts?

More importantly, I'd like to give what-ever I've written back to the
community. Since I'm working on such an old source tree, adding
patches into the sourceforce truck is probably a bad idea.

Do you think I should start my own project, and just publish the
source in my blog?
Or, should I start commiting to JScheme on sourceforge?
I'm taking a different route for this R4RS implementation. My goals
are to focus on speed and to sacrifice language features/compliance
for runtime speed and platform (j2me +ext_packages) wrapping.

It seems this flavour of Scheme I'm roasting differs quite a bit from
R4RS or R5RS; maybe it's not Scheme at all, and just an incomplete
subset - J2ScheME? J2MEScheme?

Thanks to everyone for a great Scheme port that's small, powerful and nifty.

Hope to hear back,
Vijay Santhanam

Hello there

I would greatly appreciate a small amount of your time to assist with
my doctoral research at The University of Newcastle. The research
concerns open source licensing and we're seeking developers working on
Java projects. The research is supervised, ethics-approved, anonymous
and results will be freely available. Participation will also provide a
custom licensing report for your project. To learn more, please visit:

   http://licensing-research.newcastle.edu.au

Thanks for reading this email, and I hope you'll consider participating.

Best regards
Ben Alex

(My apologies for being off-topic; this list will not be emailed again)

Is there a built-in for finding a list's tail?

I've implemented 2 versions, one in jscheme:

(define-method (tail (lst
Pair))

  (let loop ((lst
lst))


(cond

     ((null?
lst)


#f)

     ((null? (cdr
lst))


lst)


(else

      (loop (cdr lst))))))


and one in java:


/**

   * Finds a list's tail by traversing the
list.

   * @param lst the list to find the tail
of

   * @error ClassCastException if lst is not a proper
list.

*/

  public static Pair tail (Pair lst)
{

    Object tmp =
rest(lst);

    while (isPair(tmp))
{

      lst =
(Pair)tmp;

      tmp =
rest(tmp);


}

    return
lst;

  }


The java version is quite a bit faster:

(define
*1k-list*

  (let loop ((max 1000) (res
(list)))

    (cond ((= 0
max)


res)


(else

           (loop (- max 1) (cons max
res))))))



(time

 (dotimes (ii
1000)

   (my-tail
*1k-list*)))


$7 = (() (479 msec) (147624 bytes))


(time

 (dotimes (ii
1000)

   (U.tail *1k-list*)))

$8 = (() (42 msec) (189360 bytes))


Is it ok if I add that method as a static to the utils and add unit tests?

Thanks,

Kyle

Hey,

just looked at the feature request.

   list(Object... a)

means (afaik)

   list(Object[] a)

proposed solution:

   public static SchemePair list(Object[] a) {
    return list(a, 0);
   }

   public static SchemePair list(Object[] a, int index) {
    if (a.length == 0 || index >= a.length)
     return Pair.EMPTY;

    return new Pair(a[index], list(a, index+1));
   }

I've not tested it, but it might work...
Should I create a patch or something?

Basti

On Jan 9, 2006, at 11:10 PM, Kyle R. Burton wrote:

> I'm confused about the version to be released.=A0 I've updated from =
CVS=20
> and the jar file built by bin/make.sh reports that it is JScheme 7.1,=20=

> but one that I've built at work (which I assumed was also from CVS)=20
> reports that it is 7.2.
I'll do a fresh build from CVS and see what happens on my machines....
I'll send you a transcript (not to the jscheme-devel list) ...

>
> I also see a CVS tag named js7-2, but it appears in the CVS log after=20=

> the js7-1 tag.
hmmmm...
We haven't established any protocol about when to set tags or how to=20
name them.....
Perhaps its time!!

>
> Also, is there a test suite?=A0 Or rather is there one besides=20
> src/jscheme/SchemeTests.scm that should be used to validate the build=20=

> before release?
There is only the src/jscheme/SchemeTests.scm test that gets done=20
automatically during the build.

However, whenever we do a new build, I always test it on my big=20
applications (in particular, on the grewpedit application at=20
http://groupscheme.sourceforge.net/grewpedit )
and its a good idea
>
> SchemeTests.scm reports 5 failures out of 311 tests (see below for the=20=

> output).
Which platform are you running on?

>
> Are the missing method warnings expected?=A0
Yes...
> They look like they may be - is there some way to suppress them during=20=

> the particular tests where the exception (warning) is expected?=A0
I'll look into it...

>
> Are the failures related to separate interpreters not really being=20
> separate?
I'm not sure....

>
> Thanks,
>
> Kyle
>
>
> SchemeTests.scm output (with debug set to #f)
>
> **************** Running jscheme/ScemeTests.scm ******************
> several warnings should appear below as certain error conditions are=20=

> tested
> this is to be expected and does not signal a problem with the tests
>
> (=3D (.eval js1 'x) 1)=A0 failed!
> (=3D (.eval js1 'x) 1)=A0 failed!
> (=3D (.eval js2 'x) 2)=A0 failed!
> (=3D (.eval js1 'x) 11)=A0 failed!
> (=3D (+ (.eval js1 '(+ (let ((js3 (JScheme.))) (.load js3 "(define x=20=

> 3)") (.eval js3 'x)) x)) x) 24)=A0 failed!
> ** WARNING: No such=A0 instance=A0 method "equalsFirst" in class =
jsint.Pair
> ** WARNING: No such=A0 instance=A0 method "equalsFirst" in class =
jsint.Pair
> ** WARNING: No such=A0 static=A0 method "hashCode0" in class =
jsint.Pair
> ** WARNING: No such=A0 static=A0 method "hashCode0" in class =
jsint.Pair
> Tests: 311 Failures: 5
>
> All tests have completed with any errors as shown above
> Try (run-tests #t) to see both failing and successful tests and their=20=

> results
> ********************* jscheme/SchemeTests.scm has completed=20
> ***********************
>
> $3 =3D "********************* jscheme/SchemeTests.scm has completed=20
> ***********************\n\n"
>
> >
>

I'm confused about the version to be released.  I've updated from CVS and
the jar file built by bin/make.sh reports that it is JScheme 7.1, but one
that I've built at work (which I assumed was also from CVS) reports that it
is 7.2.

I also see a CVS tag named js7-2, but it appears in the CVS log after the
js7-1 tag.

Also, is there a test suite?  Or rather is there one besides
src/jscheme/SchemeTests.scm that should be used to validate the build befor=
e
release?

SchemeTests.scm reports 5 failures out of 311 tests (see below for the
output).

Are the missing method warnings expected?  They look like they may be - is
there some way to suppress them during the particular tests where the
exception (warning) is expected?

Are the failures related to separate interpreters not really being separate=
?

Thanks,

Kyle


SchemeTests.scm output (with debug set to #f)

**************** 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

(=3D (.eval js1 'x) 1)  failed!
(=3D (.eval js1 'x) 1)  failed!
(=3D (.eval js2 'x) 2)  failed!
(=3D (.eval js1 'x) 11)  failed!
(=3D (+ (.eval js1 '(+ (let ((js3 (JScheme.))) (.load js3 "(define x 3)")
(.eval js3 'x)) x)) x) 24)  failed!
** 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: 311 Failures: 5

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
***********************

$3 =3D "********************* jscheme/SchemeTests.scm has completed
***********************\n\n"

>

This patch introduces a new variable dclass-verbose which is initially
set to #t to preserve existing behavior.  When set to #f the printing
of diagnostic information to the default output port is disabled.

I'm not sure what the procedure is for submitting patches.  It is both
in-line in the email as well as attached.

This is my first patch for JScheme, I'm basically a novice in both
scheme and JScheme so any and all criticism is welcome and
appreciated.


Best regards,

Kyle R. Burton


--=20
---------------------------------------------------------------------------=
---
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
kyl...@gm...                          =20
http://www.neverlight.com/~mortis
---------------------------------------------------------------------------=
---

--
diff -uNr jscheme-7.1/src/dclass/dclass.html jscheme-krb/src/dclass/dclass.=
html
--- jscheme-7.1/src/dclass/dclass.html        2002-04-06
14:01:01.000000000 -0500
+++ jscheme-krb/src/dclass/dclass.html     2005-07-18 00:22:16.000000000 -0=
400
@@ -179,6 +179,19 @@
     (public int hashCode () 0))</pre>
=20
 <hr>
+<h2>Controlling the Output of Diagnostic Information</h2>
+<p>By default <tt>(define-class)</tt> emits diagnostic informaiton
+about the classes it is generating (including a full dump of the Java
+source for the class).  To disable this output, set the global
+dclass-verbose to false (<tt>#f</tt>).
+
+<pre>
+  (load "src/dclass.scm")
+  (set! dclass-verbose #f)
+</pre>
+
+
+<hr>
 <h2>Issues</h2>
=20
 <p>  Fields must be declared public for Scheme to access them in an
diff -uNr jscheme-7.1/src/dclass/dclass.scm jscheme-krb/src/dclass/dclass.s=
cm
--- jscheme-7.1/src/dclass/dclass.scm     2004-02-04 16:36:37.000000000 -05=
00
+++ jscheme-krb/src/dclass/dclass.scm     2005-07-18 00:09:51.000000000 -04=
00
@@ -18,6 +18,12 @@
 ;;; Root directory of where compiled *.class files should go.
  (define dclass-class-base dclass-src-base)
=20
+(define dclass-verbose #t)
+(define (dclass-display . things)
+  "Use display to print messages to the console if dclass-verbose is true.=
"
+  (if dclass-verbose
+      (apply display things)))
+
  ;;; Classpath to use by javac
  (define dclass-classpath
   (apply string-append
@@ -92,7 +98,7 @@
     (java.io.File. src-base (.toString java-file)))
   (define (open-src-file name)
     (let ((f (make-src-file dclass-src-base (class->file (.toString name))=
)))
-      (display (string-append "Writing Java code for " name  " to " f "\n"=
))
+      (dclass-display {Writing Java code for [name] to [f]\n})
       (.mkdirs (File. (.getParent f)))
       (java.io.PrintWriter. (java.io.BufferedWriter.
                            (java.io.FileWriter. f)))))
@@ -106,8 +112,8 @@
        (port (open-src-file name)))
      (emit result port)
      (.close port)
-       (emit result (current-output-port))
-      (display (string-append "Compiling Java code for " name "\n"))
+        (if dclass-verbose (emit result (current-output-port)))
+    (dclass-display {Compiling Java code for [name]\n})
    (out (run (cmd javac -classpath ,dclass-classpath
                   -d ,dclass-class-base
                      -sourcepath ,dclass-src-base

Dear JScheme developers....

jscheme-devel will now become a moderated list so as to eliminate all 
spam.
I'll quickly OK non-spam messages so there shouldn't me much of a delay.

Best,
---Tim---

On Feb 20, 2005, at 10:32 AM, Richard wrote:

>
> To Whom It May Concern,
>
> If this message is making you in-convenient, please skip it and accept 
> our sincere apology!!
>
---snip---  this was spam. I won't let any more spam onto our list...

To Whom It May Concern,

If this message is making you in-convenient, please skip it and accept our sincere apology!!


We have learned from the Internet that you are interested in tents.  We have been in the tent manufacturing business for many years and are currently in the process of expanding and our customer base.  We are quite excited about contacting you and the potential for establishing friendly business relations with you as well as sharing the mutual benefits.

We specialize in high quality, high performance tents offered to our cutomers at competitive prices.  We are able to supply a wide variety of tents manufactured to the specifications and requirements of the customer.  We would be interested in receiving more information from you so we could submit a suitable offer to you.

Feel free to view our website:  www.jxtrade.cn

If you do not wish to receive any more information,  please let us know  and we will take you off our  mailing  list.
We are awaiting your favorable response.

Sincerely,

Richard Zheng
Marketing Director
Xia Men Jiao Xia Trade Co., TLD
No.89, CangHong Rd, HaiCang Xia Men China(361006)
Tel/Fax: 0086-592-5527336
Mobil: 0086-13806069172
mail: sa...@jx...

PS.
   If you are looking for other  China-made products, please feel free 
to let us know, we will work for you according to your needs.
2-20

Dear JScheme  community,

I'm sorry to bring you the very sad news that Ken Anderson,
one of the co-developers of JScheme, died last night at the Spam 
conference
in Cambridge.  He was in great spirits, talking about JScheme, when
he collapsed mid-sentence.

Ken was one of the three main developers of JScheme.
JScheme had two parent languages -- Peter Norvig's SILK
and Tim Hickey's Jscheme applet.  Ken came onto the project
in the beginning (1997) and built the Scheme-Java interface that became
the javadot notation. He was responsible for the beautifully designed
cache techniques that make javadot so efficient. He also
was a tireless developer, chasing down bugs, dreaming up and
seriously analyzing proposed new optimizations. He was a
talented software engineer who loved building an elegant
and simultaneously practical language. He was also a really
nice guy. Kind, generous, thoughtful.  The world is a poorer
place for his passing.

Ken touched many lives and brought many communities together.
I worked with him on JScheme for 2-3 years (publishing two papers)
before I met him in person (or even knew what he looked like!)
We've met regularly since to plot the future of JScheme and to
share our war stories of JScheme in the world.  He has played
a major role in the Lightweight Language conferences and was
also an active player in the anti-Spam effort. I will miss him,
as I'm sure many other will as well.

JScheme will remain an active project and is very much part
of what Ken has given to the world. I am honored to have been
his friend and codeveloper.

Sincerely,
---Tim Hickey---

Tim,
I've added some performance improvements to field and method invocation.  So, for example, .first is only 1.5 time slower than car.
I thought you had a benchark that compared generics to primitives, do you?

k

On Oct 28, 2004, at 6:20 PM, Ken Anderson wrote:

> After talking to Joe Marshal, and getting JScheme working in 1.5.0, i 
> thought i'd write a cartoon document describing how JScheme works.  I 
> also hoped it would lead to identify opportunites for optimization.
Good idea.
Maybe we can publish it on the website....

>
> One thing i found was that Scheme.execute() which calls 
> Scheme.currentEvaluator().execute() was happening a lot.  So i added 
> an Evaluator argument to most of those sites.
Good idea...

>
> This lead to a 20% improvement in the Gabriel benchmarks.
Nice!
>  Not a bad thing to do during OOPSLA (though i didn't go).
The natural question is to see how many places still need to get the 
currentEvaluator from the
thread local variable. It would be nice if we could avoid using 
threadlocal variables as they
add an extra layer of complexity. It would be better if we could 
explain JScheme semantics '
viz a viz threads without having to assume that the reader has a prior 
understanding of the fine points of
thread local variables.....

---Tim---
>
>
>
> -------------------------------------------------------
> This Newsletter Sponsored by: Macrovision
> For reliable Linux application installations, use the industry's 
> leading
> setup authoring tool, InstallShield X. Learn more and evaluate
> today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/
> _______________________________________________
> Jscheme-user mailing list
> Jsc...@li...
> https://lists.sourceforge.net/lists/listinfo/jscheme-user

Thanks for trying to fix this.

The problem was the code did not check the permission on the method or the class.  StringBuilder is a package protected abstract class.  I think package protecting it is wrong, but maybe that had some deep language design reason for this.

Here's the fixed version (i just checked it in, so it will be in cvs tomorrow).
  public static Vector methodVectorMerge(Class c, String name, Vector result,boolean canAccessPrivateData) {
    Class s = c.getSuperclass();

    if (s != null) result = methodVectorMerge(s, name, result,canAccessPrivateData);
    Class[] is = c.getInterfaces();
    for (int i = 0; i < is.length; i = i + 1) 
      result = methodVectorMerge(is[i], name, result,canAccessPrivateData);

    Method[] ms = getMethods(c,canAccessPrivateData);  
    for(int i = 0; i < ms.length; i++) {
      Method m = ms[i];
      if ((!Modifier.isStatic(m.getModifiers())) &&
          // KRA 25OCT04: Fixes problem with .append in JDK 1.5.0
          (canAccessPrivateData ||
           (Modifier.isPublic(m.getModifiers()) &&
            Modifier.isPublic(m.getDeclaringClass().getModifiers())) &&
           m.getName().equals(name)))
        maybeAdd(result, m);
      }
    return result;
  }


At 01:31 AM 10/23/2004 +0300, Tatu Tarvainen wrote:

>I posted earlier about reflection problems under Java 5.
>
>The invoker prefers superclass methods over subclass methods, which is
>fine with interfaces, but causes problems in the StringBuffer scenario.
>I don't know if my solution is the right one in all situations but it
>solved my specific problems.
>
>I made the following change to jsint/Invoke.java:
>
>Change:
>   /** Only add an instance method if no superclass provides one. **/
>   private static void maybeAdd(Vector result, Method m1) {
>     for(int i = 0; i < result.size(); i++) {
>       Method m2 = ((Method) result.elementAt(i));
>       if(parameterTypesMatch(getParameterTypes(m1),
>        getParameterTypes(m2)))
>         return;
>     }
>     result.addElement(m1);
>   }
>
>To the following:
>   /** Only add an instance method if no superclass provides one. **/
>   private static void maybeAdd(Vector result, Method m1) {
>      for(int i = 0; i < result.size(); i++) {
>         Method m2 = ((Method) result.elementAt(i));
>         if(parameterTypesMatch(getParameterTypes(m1),
>            getParameterTypes(m2))) {
>            /* TTA: prefer methods provided by the subclass over
>superclass methods,
>             * but not over interface methods.
>             */
>             if(!m2.getDeclaringClass().isInterface()) 
>                result.set(i, m1);
>             return;
>         }
>      }
>      result.addElement(m1);
>   }
>
>--
>Tatu Tarvainen
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>Use IT products in your business? Tell us what you think of them. Give us
>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
>http://productguide.itmanagersjournal.com/guidepromo.tmpl
>_______________________________________________
>Jscheme-devel mailing list
>Jsc...@li...
>https://lists.sourceforge.net/lists/listinfo/jscheme-devel

I posted earlier about reflection problems under Java 5.

The invoker prefers superclass methods over subclass methods, which is
fine with interfaces, but causes problems in the StringBuffer scenario.
I don't know if my solution is the right one in all situations but it
solved my specific problems.

I made the following change to jsint/Invoke.java:

Change:
   /** Only add an instance method if no superclass provides one. **/
   private static void maybeAdd(Vector result, Method m1) {
     for(int i = 0; i < result.size(); i++) {
       Method m2 = ((Method) result.elementAt(i));
       if(parameterTypesMatch(getParameterTypes(m1),
	getParameterTypes(m2)))
         return;
     }
     result.addElement(m1);
   }

To the following:
   /** Only add an instance method if no superclass provides one. **/
   private static void maybeAdd(Vector result, Method m1) {
      for(int i = 0; i < result.size(); i++) {
         Method m2 = ((Method) result.elementAt(i));
         if(parameterTypesMatch(getParameterTypes(m1),
            getParameterTypes(m2))) {
            /* TTA: prefer methods provided by the subclass over
superclass methods,
             * but not over interface methods.
             */
             if(!m2.getDeclaringClass().isInterface()) 
                result.set(i, m1);
             return;
         }
      }
      result.addElement(m1);
   }

--
Tatu Tarvainen

We saw this in a 1.5 beta too.  At the time, i thought it was a bug, it still may be.  I think the problem is with how we fill the method table.
It may take me a few days to fix it.

k
At 12:59 PM 10/22/2004 +0300, Tatu Tarvainen wrote:

>Some Java-calls don't seem to work under JDK 1.5.0.
>Using quasi-strings fails, because the StringBuffer append method fails.
>
>This happens with the latest jscheme jar and the CVS version.
>I think the reflective access to the append method fails because in Java
>5 the java.lang.StringBuffer class inherits from a new
>java.lang.AbstractStringBuilder class which is not public and also
>provides the append method.
>
>I'll look into a patch over the weekend.
>
>Here is a capture of the failure:
>---------- clip -----------
>tadex@tatu-dt ~/import $ java -showversion -jar jscheme.jar
>java version "1.5.0"
>Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
>Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode, sharing)
>
>JScheme 7.1 (10/20/04 8:50 AM) http://jscheme.sourceforge.net
>> (define sb (StringBuffer.))
>
>> (.append sb "text")
>
>In openResource(elf/basic.scm):
>java.lang.OutOfMemoryError: Java heap space
>** WARNING: (load) can't open "elf/basic.scm"
>while backtrace loading describe: SchemeException: ERROR: undefined
>variable "backtraceBody"
>In openResource(elf/basic.scm):
>java.lang.OutOfMemoryError: Java heap space
>** WARNING: (load) can't open "elf/basic.scm"
>SchemeException: ERROR: undefined variable "backtraceValueString"
>Error in BacktraceException.printStackTrace:
>java.lang.OutOfMemoryError: Java heap space
>** WARNING: Error during load (lineno 23): jsint.BacktraceException[
>
>
>]
>---------- clip -----------
>The errors just go on and on, until the process is killed.
>
>-- 
>Tatu Tarvainen
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>Use IT products in your business? Tell us what you think of them. Give us
>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
>http://productguide.itmanagersjournal.com/guidepromo.tmpl
>_______________________________________________
>Jscheme-devel mailing list
>Jsc...@li...
>https://lists.sourceforge.net/lists/listinfo/jscheme-devel

Some Java-calls don't seem to work under JDK 1.5.0.
Using quasi-strings fails, because the StringBuffer append method fails.

This happens with the latest jscheme jar and the CVS version.
I think the reflective access to the append method fails because in Java
5 the java.lang.StringBuffer class inherits from a new
java.lang.AbstractStringBuilder class which is not public and also
provides the append method.

I'll look into a patch over the weekend.

Here is a capture of the failure:
---------- clip -----------
tadex@tatu-dt ~/import $ java -showversion -jar jscheme.jar
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode, sharing)

JScheme 7.1 (10/20/04 8:50 AM) http://jscheme.sourceforge.net
> (define sb (StringBuffer.))

> (.append sb "text")

In openResource(elf/basic.scm):
java.lang.OutOfMemoryError: Java heap space
** WARNING: (load) can't open "elf/basic.scm"
while backtrace loading describe: SchemeException: ERROR: undefined
variable "backtraceBody"
In openResource(elf/basic.scm):
java.lang.OutOfMemoryError: Java heap space
** WARNING: (load) can't open "elf/basic.scm"
SchemeException: ERROR: undefined variable "backtraceValueString"
Error in BacktraceException.printStackTrace:
java.lang.OutOfMemoryError: Java heap space
** WARNING: Error during load (lineno 23): jsint.BacktraceException[


]
---------- clip -----------
The errors just go on and on, until the process is killed.

-- 
Tatu Tarvainen

I wonder why.  i tried it with jscheme in several different directories and didn't have a problem.  Do you remember what the error was?

I assume you were in a cmd shell, but invoking bin/make.bat also works in cygwin.

At 10:13 AM 9/28/2004 -0400, Geoffrey Knauth wrote:
>To get bin/make.bat to work on Windows (our tech lead's machine), I had to change all the / chars to \ chars.  Subsequently, he was very impressed with JScheme's capabilities.
>
>Geoffrey
>--
>Geoffrey S. Knauth | http://knauth.org/gsk
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
>Project Admins to receive an Apple iPod Mini FREE for your judgement on
>who ports your project to Linux PPC the best. Sponsored by IBM.
>Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
>_______________________________________________
>Jscheme-devel mailing list
>Jsc...@li...
>https://lists.sourceforge.net/lists/listinfo/jscheme-devel

On Sep 28, 2004, at 5:18 PM, Geoffrey Knauth wrote:

> On Sep 28, 2004, at 4:34 PM, Ken Anderson wrote:
>> Could we get a servlet that only reads the file once?  Or maybe even 
>> never - it calls a function that its already loaded?
>
> I think it should be an option.  load-always or load-once, so to speak.
I agree. We can work on it.

One method I have been using for static webpages that are build using 
jscheme servlets
is to just use a website copier (e.g. wget -kmp --update-links 
http://localhost:8080/mywebapp )
and then have a script that copies the website and moves these static 
pages to an apache
server.

In the www.4collegewomen.org site there are both static and dynamic 
pages so I have two variables
[dcontext] and [scontext] and use the wget to copy only the static 
pages while leaving links to the
dynamic pages alone. The apache-served static pages then have links to 
the Jetty-served dynamic
pages and we get good performance on static pages and OK performance on 
dynamic pages
(which are used as often for that website).

I often work with the "founder" of the website (a public health 
professional in Washington) by
phone and as we both view the website, I make changes to the dynamic 
site, run the script to
copy it to apache, and she sees the changes almost immediately. its 
pretty cool and really easy
from this side....



>
> At the customer site where I've been using JScheme servlets to demo 
> screen designs and change them on the spot, it's been very nice that 
> little tweaks to my html.scm and defs.scm "libraries" get reflected 
> immediately in the browser, and fellow developers were impressed that 
> I never had to stop/restart the Jetty server.
>
> I can see the value of load-once too, so long as there is a way to 
> dump ("forget") something in memory dynamically so a new version can 
> be loaded.
Yes, I do this on my sites using a "reload.servlet" at the top level 
that I can call to reload the dynamic
environment that the servlets run in.  That environment is initially 
set up when the Scheme servlet is loaded
by calling some initialization code in WEB-INF/scheme/scheme.sss which 
loads in the file in
WEB-INF/scheme/servletlib/init.scm and possibly elsewhere in WEB-INF.

---Tim---

>
> Geoffrey
> --
> Geoffrey S. Knauth | http://knauth.org/gsk
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on 
> ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give 
> us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out 
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Jscheme-devel mailing list
> Jsc...@li...
> https://lists.sourceforge.net/lists/listinfo/jscheme-devel

It would be nice be able to say something about the overhead of JScheme servlets vs Java servlets.  What results did you get from httpref?

Here's a good evaluation of different servlet containers
http://www.webperformanceinc.com/library/ServletReport/

It mentions, at the end, that Jetty does not seem to use all of the CPU in its normal configuration.