jscheme-user — list for general users

Re: [Jscheme-user] Multiple independent interpreters

[Toby A. <tob...@pe...>]

On Thu, Mar 11, 2004 at 05:10:20PM -0500, Ken Anderson wrote:
> OK, since you've got 3 or 4 votes for your proposal, and none against,
> give it a shot.
> 
> Why don't you email Tim and i as you do it, for guidence.
> 
> What i'd do is copy jsint.Scheme into either jsint.REPL or
> jsint.Evaluator.  make most of the static fields non static ... Then
> get jscheme.REPL to use it rather than jsint.Scheme in main().  Maybe
> we'll just get rid of Scheme eventually.  In fact, remove it and let
> the compiler tell you where you need to change the code.

My first cut (which seems to work for my purposes) is basically exactly
that.  There are a ton of calls to static Scheme methods all through
everything, so I think I'll leave those alone as much as possible and
just redirect them to the appropriate Evaluator instance.  References to
static fields in Scheme need to be changed anyway though.

In order to determine the appropriate Evaluator instance, I've set up a
thread-local stack of them, the interface to which is four methods in
JS:

Evalutor enter()
Evalutor enterNew()
void enter(Evaluator)
void exit()

The expected usage is that any Java code that wants to make calls to
JScheme needs to wrap them in:

 JS.enter();
 try {
     ...
 } finally {
     JS.exit();
 }

The parameterless enter() method will use an existing Evaluator if there
is one for the current thread, or will create a new one.  The enterNew()
method will always create a fresh, new Evaluator instance.

New threads get a copy of their parent's Evaluator stack (but the actual
Evaluator instances are shared).

> Scheme.ARGS only makes sense for the first Evaluator.  So it should
> just become a global variable on the Scheme side.

I don't think ARGS is referred to outside of jsint.Scheme, so it doesn't
really make much difference either way.  I'd probably prefer it to be an
instance field in Evaluator so that you can run multiple scripts that
use the args and don't know about each other.

> What arguments should the constructor take?  Probably a
> DynamicEnvironment at least optionally, but probably also the input,
> output, and error.  Try to avoid setter methods, we want to think
> functionally when we can.

Do you intend the DynamicEnvironment argument to intialise
INTERACTION_ENVIRONMENT?

A fair amount of existing code assigns to the input and output fields.
Do you mean to replace that with code that instead creates a new
Evaluator?

> The jscheme.JS class that interfaces from Java to Scheme will need to
> be changed.  For now, have that class create a static final instance
> to use to keep the code simple.

I think I've covered this with the methods I propose adding to JS above.

> This may be a good tern of events because it may guide us into some
> good refactorings.  For example, i've thought that the REPL (Read Eval
> Print Loop) could be split up.  The E would be an object that too
> s-expressions and returned their value.  It could be attached in the
> usual REPL way or it could be controled by a GUI that passed commands
> to it as the user clicked on things and updated the screen accordinly.  

Sounds like a good idea.  My changes will get you everything rolled into
the E and you can split out the R and the P later if it looks like a
good idea.

> Also, i once made eval and load replaceable procedures, so for example
> you could get R5RS macros.  But that disappeared when Tim put in
> DynamicEnvironments.

Sounds cool :-)  I don't know what it means though :-(

Toby.

Re: [Jscheme-user] Re: Multiple independent interpreters

[Toby A. <tob...@pe...>]

On Fri, Mar 12, 2004 at 02:11:17PM -0500, Jonathan A Rees wrote:
> 
> Each interpreter instance potentially also needs its own class loader
> (for use by scheme code, not by jscheme itself).  Don't forget to
> provide a way to set it in a newly created instance.

Yes, I was just looking at the class loader stuff in jsint.Import, and
that will need attention for any serious J2EE use, and probably any
serious use embedded in a larger application.

The current behaviour is to set the current thread's context class
loader to the class loader that loaded jsint.Import when jsint.Import is
initialised, then always use the class loader that loaded jsint.Import.

I propose that better behaviour is to never change the context class
loader and to use either a user-specified class loader or, if none has
been specified, the current thread's context class loader.

> I'm really glad that multiple interpreter instances is being
> discussed.  The demand for this is an inevitable consequence of the
> project's success.  Soon you may find two applications that both use
> jscheme, that need to interoperate in the same Java VM, and neither
> even *knows* that the other is using jscheme, and this is as it should
> be.

I absolutely agree.

Toby.

[Jscheme-user] Re: Multiple independent interpreters

[Jonathan A R. <ja...@mu...>]

Each interpreter instance potentially also needs its own class loader
(for use by scheme code, not by jscheme itself).  Don't forget to
provide a way to set it in a newly created instance.

I'm really glad that multiple interpreter instances is being
discussed.  The demand for this is an inevitable consequence of the
project's success.  Soon you may find two applications that both use
jscheme, that need to interoperate in the same Java VM, and neither
even *knows* that the other is using jscheme, and this is as it should
be.

Jonathan

Re: [Jscheme-user] Multiple independent interpreters

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

OK, since you've got 3 or 4 votes for your proposal, and none against, give it a shot.
Why don't you email Tim and i as you do it, for guidence.

What i'd do is copy jsint.Scheme into either jsint.REPL or jsint.Evaluator.
make most of the static fields non static ... Then get jscheme.REPL to use it rather than jsint.Scheme in main().  Maybe we'll just get rid of Scheme eventually.  In fact, remove it and let the compiler tell you where you need to change the code.

Scheme.ARGS only makes sense for the first Evaluator.  So it should just become a global variable on the Scheme side.

What arguments should the constructor take?  Probably a DynamicEnvironment at least optionally, but probably also the input, output, and error.  Try to avoid setter methods, we want to think functionally when we can.

The jscheme.JS class that interfaces from Java to Scheme will need to be changed.  For now, have that class create a static final instance to use to keep the code simple.

This may be a good tern of events because it may guide us into some good refactorings.  For example, i've thought that the REPL (Read Eval Print Loop) could be split up.  The E would be an object that too s-expressions and returned their value.  It could be attached in the usual REPL way or it could be controled by a GUI that passed commands to it as the user clicked on things and updated the screen accordinly.  

Also, i once made eval and load replaceable procedures, so for example you could get R5RS macros.  But that disappeared when Tim put in DynamicEnvironments.

k

Re: [Jscheme-user] Re: cool use of jscheme

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

This is a nice example.  I think Tim uses jetty because it is easier to use than Tomcat.  I created the src/using directory to show how JScheme could be used to do things "normal Java" users want to do, in hopes of making them "abnormal Java users empowered by JScheme".
So, maybe we could turn thiis into a using/jetty.scm example, if you'd like.


At 03:55 PM 3/10/2004 -0500, Geoffrey Knauth wrote:
>This is not only cool but useful, since I recently started using JSPWiki.  I'm glad I read to the last line.
>
>Geoffrey
>--
>Geoffrey S. Knauth | http://knauth.org/gsk
>
>On Mar 3, 2004, at 13:46, Ken Anderson wrote:
>
>>Very nice!
>>
>>At 09:43 AM 3/3/2004 -0800, david wrote:
>>
>>>(still cannot post directly to the list)
>>
>>Did you get a sourceforge account?  Did sourceforge let you on the list?  I've had some trouble with this on other groups.
>>
>>>I have been using this trick trick to run a webapp server
>>>without a proper install of tomcat or jetty. All you
>>>need are the jars in the classpath and some scheme
>>>like this.. which I put in a jar as init.scm.
>>>It does not unpack the war file by default so all
>>>the jars can be read only.
>>>
>>>(load "elf/classpath.scm")
>>>(map (lambda (u) (addClasspathUrl u)) '(
>>>    "/usr/share/davud/jars/javax.servlet.jar"
>>>    "/usr/share/davud/jars/org.mortbay.jetty.jar"
>>>    "/usr/share/davud/jars/org.mortbay.jmx.jar"
>>>    "/usr/share/davud/jars/jscheme.jar"
>>>    "/usr/share/davud/jars/ant.jar"
>>>    "/usr/share/davud/jars/jasper-compiler.jar"
>>>    "/usr/share/davud/jars/jasper-runtime.jar"
>>>    "/usr/share/davud/jars/jcert.jar"
>>>    "/usr/share/davud/jars/jmxri.jar"
>>>    "/usr/share/davud/jars/jmxtools.jar"
>>>    "/usr/share/davud/jars/jnet.jar"
>>>    "/usr/share/davud/jars/jsse.jar"
>>>    "/usr/share/davud/jars/xercesImpl.jar"
>>>    "/usr/share/davud/jars/xml-apis.jar"))
>>>
>>>
>>>(import "java.io.*")
>>>(import "java.net.*")
>>>(import "org.mortbay.util.*")
>>>(import "org.mortbay.http.*")
>>>(import "org.mortbay.jetty.servlet.*")
>>>(import "org.mortbay.http.handler.*")
>>>(import "org.mortbay.servlet.*")
>>>(define server (org.mortbay.jetty.Server.))
>>>(define listener (SocketListener.))
>>>(.setPort listener 8088);
>>>(.addListener server listener)
>>>
>>>
>>>(define r2 (HashUserRealm. "Slide DAV Server"))
>>>
>>>(.put r2  (String. "root") (String. "root"))
>>>(.addUserToRole r2 "root" "guest")
>>>(.addUserToRole r2 "root" "user")
>>>(.addUserToRole r2 "root" "root")
>>>
>>>
>>>(.put r2  (String. "david") (String. "david"))
>>>(.addUserToRole r2 "david" "guest")
>>>(.addUserToRole r2 "david" "user")
>>>(.addUserToRole r2 "david" "root")
>>>
>>>(.put r2  (String. "ed") (String. "david"))
>>>(.addUserToRole r2 "ed" "guest")
>>>(.addUserToRole r2 "ed" "user")
>>>(.addUserToRole r2 "ed" "root")
>>>(.addRealm server r2)
>>>(.addWebApplication server "/dav" "/tmp/slide.war")
>>>(.addWebApplication server "/" "/usr/share/davud/jars/JSPWiki.war")
>>>(.start server)
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>Jscheme-user mailing list
>Jsc...@li...
>https://lists.sourceforge.net/lists/listinfo/jscheme-user

[Jscheme-user] jscheme website

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

I've taken over maintaining the http://jscheme.sourceforge.net website from Tim who's busy making his course work better.  It hadn't been updated in 3 days over a year.  I'm trying to set things up so that the site will be rebuilt every night.

sourceforge hint: Turns out, you need to know what time zone your crontab is in.

Re: [Jscheme-user] Re: cool use of jscheme

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

This is not only cool but useful, since I recently started using 
JSPWiki.  I'm glad I read to the last line.

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

On Mar 3, 2004, at 13:46, Ken Anderson wrote:

> Very nice!
>
> At 09:43 AM 3/3/2004 -0800, david wrote:
>
>> (still cannot post directly to the list)
>
> Did you get a sourceforge account?  Did sourceforge let you on the 
> list?  I've had some trouble with this on other groups.
>
>> I have been using this trick trick to run a webapp server
>> without a proper install of tomcat or jetty. All you
>> need are the jars in the classpath and some scheme
>> like this.. which I put in a jar as init.scm.
>> It does not unpack the war file by default so all
>> the jars can be read only.
>>
>> (load "elf/classpath.scm")
>> (map (lambda (u) (addClasspathUrl u)) '(
>>     "/usr/share/davud/jars/javax.servlet.jar"
>>     "/usr/share/davud/jars/org.mortbay.jetty.jar"
>>     "/usr/share/davud/jars/org.mortbay.jmx.jar"
>>     "/usr/share/davud/jars/jscheme.jar"
>>     "/usr/share/davud/jars/ant.jar"
>>     "/usr/share/davud/jars/jasper-compiler.jar"
>>     "/usr/share/davud/jars/jasper-runtime.jar"
>>     "/usr/share/davud/jars/jcert.jar"
>>     "/usr/share/davud/jars/jmxri.jar"
>>     "/usr/share/davud/jars/jmxtools.jar"
>>     "/usr/share/davud/jars/jnet.jar"
>>     "/usr/share/davud/jars/jsse.jar"
>>     "/usr/share/davud/jars/xercesImpl.jar"
>>     "/usr/share/davud/jars/xml-apis.jar"))
>>
>>
>> (import "java.io.*")
>> (import "java.net.*")
>> (import "org.mortbay.util.*")
>> (import "org.mortbay.http.*")
>> (import "org.mortbay.jetty.servlet.*")
>> (import "org.mortbay.http.handler.*")
>> (import "org.mortbay.servlet.*")
>> (define server (org.mortbay.jetty.Server.))
>> (define listener (SocketListener.))
>> (.setPort listener 8088);
>> (.addListener server listener)
>>
>>
>> (define r2 (HashUserRealm. "Slide DAV Server"))
>>
>> (.put r2  (String. "root") (String. "root"))
>> (.addUserToRole r2 "root" "guest")
>> (.addUserToRole r2 "root" "user")
>> (.addUserToRole r2 "root" "root")
>>
>>
>> (.put r2  (String. "david") (String. "david"))
>> (.addUserToRole r2 "david" "guest")
>> (.addUserToRole r2 "david" "user")
>> (.addUserToRole r2 "david" "root")
>>
>> (.put r2  (String. "ed") (String. "david"))
>> (.addUserToRole r2 "ed" "guest")
>> (.addUserToRole r2 "ed" "user")
>> (.addUserToRole r2 "ed" "root")
>> (.addRealm server r2)
>> (.addWebApplication server "/dav" "/tmp/slide.war")
>> (.addWebApplication server "/" "/usr/share/davud/jars/JSPWiki.war")
>> (.start server)

Re: [Jscheme-user] Multiple independent interpreters

[Michael R H. <bu...@zc...>]

On Tue, 2004-03-09 at 22:14, Timothy John Hickey wrote:
> Hi Toby,
> It would be nice to be able to create new JScheme instances that
> could run independently of each other. I would support an effort
> to do this, provided it doesn't make the implementation too complex
> and unwieldly (which is unlikely).

This could also be potentially very useful for the Eclipse plugin, too.

mike
-- 
Michael R Head <bu...@zc...>
ZClipse -- OpenSource Eclipse plugins

Re: [Jscheme-user] Multiple independent interpreters

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

Hi Toby,
   Thanks for the serialization/deserialization extension.
Its a nice feature to have and I look forward to seeing what
we can do with it!

As for running multiple independent Scheme's, I think it is
a good idea as long as it doesn't make the code too complex
(after refactoring...)

On Tuesday, March 9, 2004, at 08:46 PM, Toby Allsopp wrote:
> On Tue, Mar 09, 2004 at 06:58:35PM -0500, Ken Anderson wrote:
>> I think we need to do this carefully.  I'd like to hear what Tim has
>> to say.
>
> I completely understand.  I'm proposing a fairly major change.
It would be nice to be able to create new JScheme instances that
could run independently of each other. I would support an effort
to do this, provided it doesn't make the implementation too complex
and unwieldly (which is unlikely).
>
>> Peter Norvig's original intent was to make jsint.Scheme static "to
>> keep it simple", basically.  However, it does cause problems with
>> things like Scheme.out$ So for example if you have multiple
>> using.Active.interactor() windows up only the last one has control of
>> input and output.
It might make modules easier to implement as well as we could
create a new Scheme instance to load the module into and then
copy its exported bindings into the current Scheme instance, so
it could actually simplify the code somewhat.
>>
>> In fact, i think its fair to say that Peter's design choices were
>> influenced by Java's capabilities at that time, for example , "keep
>> the number of classes small" to minimize applet load times ... With
>> hotspot, we might now make other choices.
>
> I haven't considered applet loading performance as I'm not interested
> in using JScheme in an applet.  I don't think anything I've done will
> cause problems in that department.
>
>> We could also run JScheme in JDK 1.02 environments, which i think we
>> have finally gone beyond.
>
> In my initial implementation (which I'm testing right now), I've used
> some JDK 1.2 classes (and possibly some 1.3 ones), but that can 
> probably
> be worked around if earlier JDK compatibility is required.
>
>> A third alternative to your proposals might be to make certain things
>> thread local, though i haven't thought about this.
>
> I don't think there's any choice but to make some things thread local 
> if
> you want to avoid passing the execution context (perhaps that's a 
> better
> name than interpreter) into every method.
If we make all "execution context variables" thread local, then 
starting a new thread
will be less lightweight. One nice use of threads is to write a simple 
server that starts
a new thread for each incoming socket and then reads from the socket 
and writes to
a common queue (with synchronization as appropriate), I wouldn't want 
this pattern
to be broken. Its true that the nio package makes this use of threads 
unnecessary, but
for small servers it is a nice use of threads....

So, I guess I'd be careful with ThreadLocal variables. Perhaps the 
default behavior
would be to have ThreadLocal variables be initialized to be equal to 
the parent
thread's values, but that resetting a Scheme instance would rebind the 
ThreadLocal
variables to initial values???

>
>> Tim came up with the jscheme package in an attempt, i think to clean
>> the original code a little, by using Interfaces for example, and he
>> has an example of a mini JScheme where most of the primitives are
>> written in Scheme.  So, we need to consider carefully where your
>> proposed class goes.
>
> I must say that I get confused trying to tell the difference between 
> the
> jsint and jscheme packages.  It kind of looks like jscheme is the
> interface and jsint is the implementation.
Thats essentially right. I wanted jscheme to be the public face of 
JScheme so that
we could change the jsint package radically and not break any programs 
that relied
only on the jscheme package.... With that philosophy, I would suggest 
leaving the
jscheme package mostly unchanged (except for some new functionality 
procedures in
jscheme.REPL) and making most of the patches to jsint.Scheme

>
>> Please don't use the name Interpreter.  JScheme is not interpreted.
>> JScheme code is read, then compiled and then executed.  The compiler
>> is both simple and effective (see how those two words almost cancel
>> each other out).  Many people avoid Lisp languages because they fear
>> they are interpreted.  Also JScheme code can be compiled to Java with
>> Tim's compiler.  Evaluator might be a better class name.
>
> Hmm, I'll try to stay out of naming arguments, I always end up with a
> bad name.  I suppose I was misled by the comment at the top of
> Scheme.java :-)
We do need a better name as Interpreter has a bad connotation maybe
just callling it a Scheme instance would do (and we'll need to create a
Scheme constructor ....)

>
>> In fact, maybe this is a time for refactoring.  I've been thinking
>> that jsint.Scheme should be broken up.
>
> I think some refactoring would help to sort out what this new class
> should be called.  I don't feel close enough to the philosophy behind
> JScheme to do any really useful refactoring, so I'm going to prepare a
> patch that does the minimum I can to get it working and hope that it's
> of use.
Sounds good. We could refactor after you patch. I have some
fairly big JScheme programs that make use of modules, threads, and
other features that will provide a good test of whether the patch breaks
any older functionality.... We also have the unit tests, but they are 
not
yet comprehensive....

---Tim---

>
> Toby.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Jscheme-user mailing list
> Jsc...@li...
> https://lists.sourceforge.net/lists/listinfo/jscheme-user

Re: [Jscheme-user] Multiple independent interpreters

[Toby A. <tob...@pe...>]

On Tue, Mar 09, 2004 at 06:58:35PM -0500, Ken Anderson wrote:
> I think we need to do this carefully.  I'd like to hear what Tim has
> to say.

I completely understand.  I'm proposing a fairly major change.

> Peter Norvig's original intent was to make jsint.Scheme static "to
> keep it simple", basically.  However, it does cause problems with
> things like Scheme.out$ So for example if you have multiple
> using.Active.interactor() windows up only the last one has control of
> input and output.
> 
> In fact, i think its fair to say that Peter's design choices were
> influenced by Java's capabilities at that time, for example , "keep
> the number of classes small" to minimize applet load times ... With
> hotspot, we might now make other choices.

I haven't considered applet loading performance as I'm not interested
in using JScheme in an applet.  I don't think anything I've done will
cause problems in that department.

> We could also run JScheme in JDK 1.02 environments, which i think we
> have finally gone beyond.

In my initial implementation (which I'm testing right now), I've used
some JDK 1.2 classes (and possibly some 1.3 ones), but that can probably
be worked around if earlier JDK compatibility is required.

> A third alternative to your proposals might be to make certain things
> thread local, though i haven't thought about this.

I don't think there's any choice but to make some things thread local if
you want to avoid passing the execution context (perhaps that's a better
name than interpreter) into every method.

> Tim came up with the jscheme package in an attempt, i think to clean
> the original code a little, by using Interfaces for example, and he
> has an example of a mini JScheme where most of the primitives are
> written in Scheme.  So, we need to consider carefully where your
> proposed class goes.

I must say that I get confused trying to tell the difference between the
jsint and jscheme packages.  It kind of looks like jscheme is the
interface and jsint is the implementation.

> Please don't use the name Interpreter.  JScheme is not interpreted.
> JScheme code is read, then compiled and then executed.  The compiler
> is both simple and effective (see how those two words almost cancel
> each other out).  Many people avoid Lisp languages because they fear
> they are interpreted.  Also JScheme code can be compiled to Java with
> Tim's compiler.  Evaluator might be a better class name.

Hmm, I'll try to stay out of naming arguments, I always end up with a
bad name.  I suppose I was misled by the comment at the top of
Scheme.java :-)

> In fact, maybe this is a time for refactoring.  I've been thinking
> that jsint.Scheme should be broken up.

I think some refactoring would help to sort out what this new class
should be called.  I don't feel close enough to the philosophy behind
JScheme to do any really useful refactoring, so I'm going to prepare a
patch that does the minimum I can to get it working and hope that it's
of use.

Toby.

Re: [Jscheme-user] Multiple independent interpreters

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

I think we need to do this carefully.  I'd like to hear what Tim has to say.

Peter Norvig's original intent was to make jsint.Scheme static "to keep it simple", basically.  However, it does cause problems with things like Scheme.out$ So for example if you have multiple using.Active.interactor() windows up only the last one has control of input and output.

In fact, i think its fair to say that Peter's design choices were influenced by Java's capabilities at that time, for example , "keep the number of classes small" to minimize applet load times ... With hotspot, we might now make other choices.

We could also run JScheme in JDK 1.02 environments, which i think we have finally gone beyond.

A third alternative to your proposals might be to make certain things thread local, though i haven't thought about this.

Tim came up with the jscheme package in an attempt, i think to clean the original code a little, by using Interfaces for example, and he has an example of a mini JScheme where most of the primitives are written in Scheme.  So, we need to consider carefully where your proposed class goes.

Please don't use the name Interpreter.  JScheme is not interpreted.  JScheme code is read, then compiled and then executed.  The compiler is both simple and effective (see how those two words almost cancel each other out).  Many people avoid Lisp languages because they fear they are interpreted.  Also JScheme code can be compiled to Java with Tim's compiler.  Evaluator might be a better class name.

In fact, maybe this is a time for refactoring.  I've been thinking that jsint.Scheme should be broken up.

At 09:34 AM 3/10/2004 +1300, Toby Allsopp wrote:
>I'm wanting to use JScheme as a way to script a J2EE application.  I
>want to be able to run a scheme program that can send a closure to the
>J2EE application and have it executed by an EJB.  The serialization
>support I submitted is one part of this.
>
>The next big hurdle is that I don't want the results of executing a
>closure in the EJB to taint future executions, and I want to support
>multiple threads executing independently.
>
>Because everything is static, the only way that I can see to have
>independent interpreters is to play games with class loaders, i.e. to
>create a new class loader to load the JScheme classes for each
>interpreter instance.  This approach is unsatisfactory to me because I
>intend to run in a J2EE environment and messing with class loaders is
>explicitly forbidden by the specification.  The performance impact of
>creating a class loader and loading the classes also troubles me.
>
>I propose to make all per-interpreter state (e.g. the dynamic
>environments, input/output ports) non-static and introduce a per-thread
>"current interpreter".  I see two alternative implementation strategies:
>
>1) Introduce a new class, jsint.Interpreter, that is essentially a
>de-static-ed version of jsint.Scheme.  Then, replace the contents of
>each static method in jsint.Scheme with delegation to the corresponding
>method of the current jsint.Interpreter instance.
>
>2) De-static-ify jsint.Scheme and change every static call to
>Scheme.<something> to Scheme.currentInterpreter().<something>.
>
>My questions are:
>
>Does anyone see a better or easier way to achieve what I want?
>
>Which of the two proposed options would be preferred?
>
>Toby.
>
>P.S. Yes, I am volunteering to make these changes.
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>Jscheme-user mailing list
>Jsc...@li...
>https://lists.sourceforge.net/lists/listinfo/jscheme-user

[Jscheme-user] Re: JScheme, Oracle, XML

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

If you want to combine database querying and XML generation you could use a little language, like this xmlDbQuery macro examples.  The first one uses quasistring notation to generate the sql query and the XML:
(xmlDbQuery
  dbConnection
  {select first_name, last_name from people where last_name like '[lname]'}
  {<person>
    <first-name>[first_name]</first-name>
    <last-name>[last_name]</last-name>
   </person>})

The second uses the <> macro in elf/html-gen.scm (see the lastest CVS version):

(xmlDbQuery
  dbConnection
  {select first_name, last_name from people where last_name like 'KNAUTH'}
  (<> person
    (<> first-name first_name)
    (<> last-name  last_name)))

This is close to SXML.  

See also dclass SaxExp.scm for a sax parser that turns XML into s-expressions like McCarthy intended.

k
At 03:23 PM 3/9/2004 -0500, Geoffrey Knauth wrote:
>Have been using JScheme to read Oracle data and organize it hierarchically, since trees are so easy with Lisp/Scheme.  Now trying to convert it to XML (so others can import the data).  There's DrScheme code (a library, SXML?) that does that.  Looking to see if I can do it easily staying in JScheme.
>
>Geoffrey
>--
>Geoffrey S. Knauth | http://knauth.org/gsk
>
>On Mar 9, 2004, at 15:06, Ken Anderson wrote:
>
>>Update of /cvsroot/jscheme/jscheme/src/elf
>>In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv20702/src/elf
>>
>>Modified Files:
>>        future.scm interrupt.scm
>>Log Message:
>>Future.scm - print error when it occurs.
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: IBM Linux Tutorials
>>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>>GenToo technologies. Learn everything from fundamentals to system
>>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>>_______________________________________________
>>Jscheme-devel mailing list
>>Jsc...@li...
>>https://lists.sourceforge.net/lists/listinfo/jscheme-devel

[Jscheme-user] Multiple independent interpreters

[Toby A. <tob...@pe...>]

I'm wanting to use JScheme as a way to script a J2EE application.  I
want to be able to run a scheme program that can send a closure to the
J2EE application and have it executed by an EJB.  The serialization
support I submitted is one part of this.

The next big hurdle is that I don't want the results of executing a
closure in the EJB to taint future executions, and I want to support
multiple threads executing independently.

Because everything is static, the only way that I can see to have
independent interpreters is to play games with class loaders, i.e. to
create a new class loader to load the JScheme classes for each
interpreter instance.  This approach is unsatisfactory to me because I
intend to run in a J2EE environment and messing with class loaders is
explicitly forbidden by the specification.  The performance impact of
creating a class loader and loading the classes also troubles me.

I propose to make all per-interpreter state (e.g. the dynamic
environments, input/output ports) non-static and introduce a per-thread
"current interpreter".  I see two alternative implementation strategies:

1) Introduce a new class, jsint.Interpreter, that is essentially a
de-static-ed version of jsint.Scheme.  Then, replace the contents of
each static method in jsint.Scheme with delegation to the corresponding
method of the current jsint.Interpreter instance.

2) De-static-ify jsint.Scheme and change every static call to
Scheme.<something> to Scheme.currentInterpreter().<something>.

My questions are:

Does anyone see a better or easier way to achieve what I want?

Which of the two proposed options would be preferred?

Toby.

P.S. Yes, I am volunteering to make these changes.

Re: [Jscheme-user] jlib

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

I'll let Tim answer this one.

k

At 08:14 PM 3/8/2004 -0800, david wrote:
>I need to use JTables so I made these modifications to 
>JLIB.scm.. Seems to work okay. JTable manages it's
>data with a TableModel so all the data manipulation 
>is handeled there.  I used the name matrix  for the 
>table widget since table is arleady used..
>
>Maybe we can get somthing like this is the  standard
>jar file?
>
>
>
>
>(define matrix (lambda R
>  (define M (javax.swing.JTable. (first R)))
>  (processConArgs M R)
>  M))
>
>and adding 
>
>((javax.swing.JTable javax.swing.JTable javax.swing.table.TableModel)
>             (.add a c))
>
>to processConArgs
>
>
>
>;;;;;;;;;;;
>(define t (maketagger))
>(define tm (javax.swing.table.DefaultTableModel. 20 2))
>
>(define w 
>  (window "Test"
>          (t "mat1"  (matrix tm))
>          (button "exit" red 
>            (action(lambda(e)(exit))))))
>(.pack w) 
>(.show w)
>(.getDataVector tm)
>(.setValueAt tm "helo" 0 0 )
>;;;;;;;;;;

[Jscheme-user] Classpath.scm - replaceClassLoaders

[Borislav I. <bor...@ko...>]

Hi,

If a load "elf/classpath.scm" and run replaceClassLoaders, I get:

>jscheme


JScheme 6.2 1/22/2004 http://jscheme.sourceforge.net


> (load "elf/classpath.scm")
#t
> (replaceClassLoaders)

(iterate (.elements (.clone Symbol.symbolTable$ ))(lambda
replaceClassLoaders~2
(s)...) )
  copyClassLoader = (lambda replaceClassLoaders~1 (loader)...)

  ====================================

(.isAssignableFrom c (.getClass x ))
  x = {jsint.Primitive poke-static[3]}
  c = #!undefined

  ====================================
SchemeException: ERROR:
NO INSTANCE METHOD OF TYPE

  (.isAssignableFrom jsint.Symbol ...)
>

This is with latest CVS code and a rebuild of Jscheme. Not important for
me, but just to let you know.

Best,
Boris

Re: [Jscheme-user] Serializing closures

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

I've checked in Toby's code with some minor modifications.
also elf/serialize.scm has some example code.

I'll probably make a couple of small changes next week.

Re: [Jscheme-user] Resetting the interpret

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

Well, i think you could look at what symbols are avaiable when JScheme starts
and when you want to reset, just removed the symbols that aren't in this list.
Symbol.symbolTable$ is the symbol table.

Also look at elf/classpath.scm  the procedure replaceClassLoaders resets all the internal caches.

k
At 12:00 AM 3/5/2004 -0500, Borislav Iordanov wrote:
>Hi,
>
>This is a question for the Jscheme developers. I would like to be able
>to reset the interpreter to a clean state without having the restart the
>JVM. I'm not sure how this should be done, but because the interpreter
>interface consists of static methods, it seems that I would need to
>"manually" empty environments and the like (imports, classpaths...). My
>goal is for the interpreter to behave as if started in a fresh JVM. I
>could read the code and figure it out, but some guidance would save me
>time and I'd appreciate it. 
>
>BTW, this is in the context of a NetBeans plugin for JScheme I started
>writing a few days ago. I know there is an Eclipse plugin, but I use
>NetBeans so I want a NetBeans one ;). I'll make it available for other
>NetBeans/Jscheme users (please let me know if there is some interest -
>it's good motivation) once it's more useful. So far, it just does syntax
>coloring, runs the interpreter within NetBeans and has a "Load in
>Jscheme" context menu item in the editor. Resetting the interpreter is
>useful when opening a different project in the IDE.
>
>Thanks a lot in advance.
>Boris

[Jscheme-user] Resetting the interpret

[Borislav I. <bor...@ko...>]

Hi,

This is a question for the Jscheme developers. I would like to be able
to reset the interpreter to a clean state without having the restart the
JVM. I'm not sure how this should be done, but because the interpreter
interface consists of static methods, it seems that I would need to
"manually" empty environments and the like (imports, classpaths...). My
goal is for the interpreter to behave as if started in a fresh JVM. I
could read the code and figure it out, but some guidance would save me
time and I'd appreciate it. 

BTW, this is in the context of a NetBeans plugin for JScheme I started
writing a few days ago. I know there is an Eclipse plugin, but I use
NetBeans so I want a NetBeans one ;). I'll make it available for other
NetBeans/Jscheme users (please let me know if there is some interest -
it's good motivation) once it's more useful. So far, it just does syntax
coloring, runs the interpreter within NetBeans and has a "Load in
Jscheme" context menu item in the editor. Resetting the interpreter is
useful when opening a different project in the IDE.

Thanks a lot in advance.
Boris

Re: [Jscheme-user] Serializing closures

[Toby A. <tob...@pe...>]

On Wed, Mar 03, 2004 at 02:49:59PM -0500, Timothy John Hickey wrote:
> I'd like to see the patch, but it wasn't attached to my email...  I am
> interested in getting serialization to work.... and specifying
> precisely what its semantics is....

Yeah, sorry about that, I've sent it in a separate reply.  The semantics
are tricky to specify.  What I've implemented is the behaviour I happen
to want, but it has the slightly strange side effect of introducing new
top level bindings to satisfy free references on deserialization.  I see
two alternatives:

1) assume that the bindings exist and generate an error if they don't,
   just as if the closure was defined normally,

2) just use the snapshotted values and avoid polluting the top level.

I think what I've implemented is more useful in general, and it
certainly is for me.

Toby.

> > What happens is that any free references in the closure have their
> > values snapshotted on serialization and these snapshot values are
> > used to reestablish the top level bindings if none exist on
> > deserialization.  If the appropriate binding do exists then the free
> > references are hooked up as I would expect (but you may not).
> > 
> > Anyway, I thought this was pretty cool.  Is there any interest in
> > including this patch in the official sources?
> > 
> > Toby.

Re: [Jscheme-user] Serializing closures

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

This looks like a very nice job!  You even fixed serialization of Pairs and Symbols!  I've really wanted to fix serialization for a long time.  Thanks for doing it!

Tim, maybe this would let us have separate heaps, like SISC does.

At 02:49 PM 3/3/2004 -0500, Timothy John Hickey wrote:
>I'd like to see the patch, but it wasn't attached to my email...
>I am interested in getting serialization to work.... and specifying
>precisely what its semantics is....
>
>---Tim---
>
>On Wednesday, March 3, 2004, at 02:34 PM, Toby Allsopp wrote:
>
>>Attached is a patch that allows one to serialize a closure (or most
>>other objects) and read it back in a different process.
>>
>>Given the following definitions:
>>
>>        (import "java.io.*")
>>
>>        (define (serialize filename x)
>>            (let* ((fos (FileOutputStream. filename))
>>                   (oos (ObjectOutputStream. fos)))
>>              (.writeObject oos x)
>>              (.close oos)))
>>
>>        (define (deserialize filename)
>>            (let* ((fis (FileInputStream. filename))
>>                   (ois (ObjectInputStream. fis))
>>                   (x (.readObject ois)))
>>              (.close ois)
>>              x))
>>
>>one can do the following:
>>
>>        JScheme 6.2 1/22/2004 http://jscheme.sourceforge.net
>>
>>
>>>(define qux 42)
>>        42
>>>(define (baz) qux)
>>        (lambda baz ()...)
>>>(define (foo) baz)
>>        (lambda foo ()...)
>>>(foo)
>>        (lambda baz ()...)
>>>((foo))
>>        42
>>>(serialize "foo.ser" foo)
>>        #null
>>        Process scheme finished
>>
>>
>>        JScheme 6.2 1/22/2004 http://jscheme.sourceforge.net
>>
>>
>>>(define bar (deserialize "foo.ser"))
>>        (lambda foo ()...)
>>>(bar)
>>        (lambda baz ()...)
>>>((bar))
>>        42
>>>baz
>>        (lambda baz ()...)
>>>qux
>>        42
>>>(set! qux 20)
>>        20
>>>((bar))
>>        20
>>        Process scheme finished
>>
>>
>>        JScheme 6.2 1/22/2004 http://jscheme.sourceforge.net
>>
>>
>>>(define qux 10)
>>        10
>>>(define bar (deserialize "foo.ser"))
>>        (lambda foo ()...)
>>>((bar))
>>        10
>>
>>What happens is that any free references in the closure have their
>>values snapshotted on serialization and these snapshot values are used
>>to reestablish the top level bindings if none exist on deserialization.
>>If the appropriate binding do exists then the free references are hooked
>>up as I would expect (but you may not).
>>
>>Anyway, I thought this was pretty cool.  Is there any interest in
>>including this patch in the official sources?
>>
>>Toby.
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: IBM Linux Tutorials
>>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>>GenToo technologies. Learn everything from fundamentals to system
>>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>>_______________________________________________
>>Jscheme-user mailing list
>>Jsc...@li...
>>https://lists.sourceforge.net/lists/listinfo/jscheme-user
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>Jscheme-user mailing list
>Jsc...@li...
>https://lists.sourceforge.net/lists/listinfo/jscheme-user

Re: [Jscheme-user] Serializing closures

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

I'd like to see the patch, but it wasn't attached to my email...
I am interested in getting serialization to work.... and specifying
precisely what its semantics is....

---Tim---

On Wednesday, March 3, 2004, at 02:34 PM, Toby Allsopp wrote:

> Attached is a patch that allows one to serialize a closure (or most
> other objects) and read it back in a different process.
>
> Given the following definitions:
>
>         (import "java.io.*")
>
>         (define (serialize filename x)
>             (let* ((fos (FileOutputStream. filename))
>                    (oos (ObjectOutputStream. fos)))
>               (.writeObject oos x)
>               (.close oos)))
>
>         (define (deserialize filename)
>             (let* ((fis (FileInputStream. filename))
>                    (ois (ObjectInputStream. fis))
>                    (x (.readObject ois)))
>               (.close ois)
>               x))
>
> one can do the following:
>
>         JScheme 6.2 1/22/2004 http://jscheme.sourceforge.net
>
>
>> (define qux 42)
>         42
>> (define (baz) qux)
>         (lambda baz ()...)
>> (define (foo) baz)
>         (lambda foo ()...)
>> (foo)
>         (lambda baz ()...)
>> ((foo))
>         42
>> (serialize "foo.ser" foo)
>         #null
>>
>         Process scheme finished
>
>
>         JScheme 6.2 1/22/2004 http://jscheme.sourceforge.net
>
>
>> (define bar (deserialize "foo.ser"))
>         (lambda foo ()...)
>> (bar)
>         (lambda baz ()...)
>> ((bar))
>         42
>> baz
>         (lambda baz ()...)
>> qux
>         42
>> (set! qux 20)
>         20
>> ((bar))
>         20
>>
>         Process scheme finished
>
>
>         JScheme 6.2 1/22/2004 http://jscheme.sourceforge.net
>
>
>> (define qux 10)
>         10
>> (define bar (deserialize "foo.ser"))
>         (lambda foo ()...)
>> ((bar))
>         10
>
> What happens is that any free references in the closure have their
> values snapshotted on serialization and these snapshot values are used
> to reestablish the top level bindings if none exist on deserialization.
> If the appropriate binding do exists then the free references are 
> hooked
> up as I would expect (but you may not).
>
> Anyway, I thought this was pretty cool.  Is there any interest in
> including this patch in the official sources?
>
> Toby.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Jscheme-user mailing list
> Jsc...@li...
> https://lists.sourceforge.net/lists/listinfo/jscheme-user

Re: [Jscheme-user] Serializing closures

[Toby A. <tob...@pe...>]

And here is the patch.  (I *always* forget to attach the bloody things).

Toby.

[Jscheme-user] Serializing closures

[Toby A. <tob...@pe...>]

Attached is a patch that allows one to serialize a closure (or most
other objects) and read it back in a different process.

Given the following definitions:

        (import "java.io.*")

        (define (serialize filename x)
            (let* ((fos (FileOutputStream. filename))
                   (oos (ObjectOutputStream. fos)))
              (.writeObject oos x)
              (.close oos)))

        (define (deserialize filename)
            (let* ((fis (FileInputStream. filename))
                   (ois (ObjectInputStream. fis))
                   (x (.readObject ois)))
              (.close ois)
              x))

one can do the following:

        JScheme 6.2 1/22/2004 http://jscheme.sourceforge.net


        > (define qux 42)
        42
        > (define (baz) qux)
        (lambda baz ()...)
        > (define (foo) baz)
        (lambda foo ()...)
        > (foo)
        (lambda baz ()...)
        > ((foo))
        42
        > (serialize "foo.ser" foo)
        #null
        > 
        Process scheme finished


        JScheme 6.2 1/22/2004 http://jscheme.sourceforge.net


        > (define bar (deserialize "foo.ser"))
        (lambda foo ()...)
        > (bar)
        (lambda baz ()...)
        > ((bar))
        42
        > baz
        (lambda baz ()...)
        > qux
        42
        > (set! qux 20)
        20
        > ((bar))
        20
        > 
        Process scheme finished


        JScheme 6.2 1/22/2004 http://jscheme.sourceforge.net


        > (define qux 10)
        10
        > (define bar (deserialize "foo.ser"))
        (lambda foo ()...)
        > ((bar))
        10

What happens is that any free references in the closure have their
values snapshotted on serialization and these snapshot values are used
to reestablish the top level bindings if none exist on deserialization.
If the appropriate binding do exists then the free references are hooked
up as I would expect (but you may not).

Anyway, I thought this was pretty cool.  Is there any interest in
including this patch in the official sources?

Toby.

[Jscheme-user] Re: cool use of jscheme

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

Very nice!


At 09:43 AM 3/3/2004 -0800, david wrote:

>(still cannot post directly to the list)

Did you get a sourceforge account?  Did sourceforge let you on the list?  I've had some trouble with this on other groups.

>I have been using this trick trick to run a webapp server 
>without a proper install of tomcat or jetty. All you 
>need are the jars in the classpath and some scheme
>like this.. which I put in a jar as init.scm.
>It does not unpack the war file by default so all
>the jars can be read only.
>
>
>
>
>(load "elf/classpath.scm")
>(map (lambda (u) (addClasspathUrl u)) '(
>     "/usr/share/davud/jars/javax.servlet.jar"
>     "/usr/share/davud/jars/org.mortbay.jetty.jar"
>     "/usr/share/davud/jars/org.mortbay.jmx.jar"
>     "/usr/share/davud/jars/jscheme.jar"
>     "/usr/share/davud/jars/ant.jar"
>     "/usr/share/davud/jars/jasper-compiler.jar"
>     "/usr/share/davud/jars/jasper-runtime.jar"
>     "/usr/share/davud/jars/jcert.jar"
>     "/usr/share/davud/jars/jmxri.jar"
>     "/usr/share/davud/jars/jmxtools.jar"
>     "/usr/share/davud/jars/jnet.jar"
>     "/usr/share/davud/jars/jsse.jar"
>     "/usr/share/davud/jars/xercesImpl.jar"
>     "/usr/share/davud/jars/xml-apis.jar"))
>     
>
>(import "java.io.*")
>(import "java.net.*")
>(import "org.mortbay.util.*")
>(import "org.mortbay.http.*")
>(import "org.mortbay.jetty.servlet.*")
>(import "org.mortbay.http.handler.*")
>(import "org.mortbay.servlet.*")     
>(define server (org.mortbay.jetty.Server.))
>(define listener (SocketListener.))
>(.setPort listener 8088); 
>(.addListener server listener)
>
>
>(define r2 (HashUserRealm. "Slide DAV Server"))
>
>(.put r2  (String. "root") (String. "root"))
>(.addUserToRole r2 "root" "guest")
>(.addUserToRole r2 "root" "user")
>(.addUserToRole r2 "root" "root")
>
>
>(.put r2  (String. "david") (String. "david"))
>(.addUserToRole r2 "david" "guest")
>(.addUserToRole r2 "david" "user")
>(.addUserToRole r2 "david" "root")
>
>(.put r2  (String. "ed") (String. "david"))
>(.addUserToRole r2 "ed" "guest")
>(.addUserToRole r2 "ed" "user")
>(.addUserToRole r2 "ed" "root")
>(.addRealm server r2)
>(.addWebApplication server "/dav" "/tmp/slide.war")
>(.addWebApplication server "/" "/usr/share/davud/jars/JSPWiki.war")
>(.start server)

Re: [Jscheme-user] Handling Java Array Parameters

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

You can also make an array with (array class arg ...) or
(make-array class size)  and access array elements with the Scheme primitives vector-ref and vector-set!  They work on any array type.

If you're interested in dynamic classpath hacking, see elf/classpath.scm.
It provides (url) which will create a URL from a File, String or URL.
It also provides addClasspathUrl which will extend the classpath, of the classloader that loaded JScheme, by a url.

I use this to make my JScheme environment automatically know about nearby jars.  So, for example, if you start JScheme with something like:

java -jar lib/jscheme.jar

Then the following code will find the lib/ directory, and home directory of the application, and add all the jar's in lib/ to the classpath:

(load "elf/classpath.scm")
(load "using/run.scm")

;;; lib directory.
(define libDir (.getCanonicalFile
                (.getParentFile (File. ($ "java.class.path")))))

;;; Application home directory.
(define appDir (.getParentFile libDir))

''' Extend classpath.
(for-each addClasspathUrl (files** libDir isJarFile))
At 10:58 PM 3/1/2004 -0500, Timothy John Hickey wrote:

>On Monday, March 1, 2004, at 09:59 PM, Enrique Ricoy Belloc wrote:
>
>>I've started using Jscheme, I want to implement the
>>following code, but
>>don't know quite how to handle the URL[] definition:
>>
>>
>>URL[] urls = new URL[] {
>>new File("C:\\Program Files\\Microsoft SQL Server 2000
>>Driver for
>>JDBC\\lib\\msbase.jar").toURL(),
>>new File("C:\\Program Files\\Microsoft SQL Server 2000
>>Driver for
>>JDBC\\lib\\mssqlserver.jar").toURL(),
>>new File("C:\\Program Files\\Microsoft SQL Server 2000
>>Driver for
>>JDBC\\lib\\msutil.jar").toURL()
>>};
>
>I tend to use the (list->array TYPE LIST) procedure
>which converts a list into an array of the specified type.
>So, to convert a list L of filenames into an array of URLs
>you could use the following procedure:
>
>> (define (filenames->urlarray L)
>  (list->array java.net.URL.class
>    (map .toURL
>       (map java.io.File. L))))
>......
>
>which could be applied as follows:
>
>> (define z (filenames->urlarray (list "lib/jscheme.jar" "lib/applet.jar")))
>.....
>> z
>#(file:/Users/tim/Research/Software/jscheme/lib/jscheme.jar file:/Users/tim/Research/Software/jscheme/lib/applet.jar)
>
>Hope this helps,
>---Tim---
>
>P.S. You can access array elements with (Array.get z n) and (Array.set z n v), e.g.
>
>> (Array.get z 0)
>...
>> (Array.set z 1 (Array.get z 0))
>...
>
>
>
>>URLClassLoader loader = new URLClassLoader(urls);
>>Driver d = (Driver) Class.forName(driverStr, true,
>>loader).newInstance();
>
>This would rewrite to
>(define loader (URLClassLoader. urls))
>(define d (.newInstance (Class.forName driverStr #t loader)))
>
>>
>>--end--
>>
>>__________________________________
>>Do you Yahoo!?
>>Get better spam protection with Yahoo! Mail.
>>http://antispam.yahoo.com/tools
>>
>>
>>-------------------------------------------------------
>>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>>Build and deploy apps & Web services for Linux with
>>a free DVD software kit from IBM. Click Now!
>>http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>>_______________________________________________
>>Jscheme-user mailing list
>>Jsc...@li...
>>https://lists.sourceforge.net/lists/listinfo/jscheme-user
>
>
>
>-------------------------------------------------------
>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>Build and deploy apps & Web services for Linux with
>a free DVD software kit from IBM. Click Now!
>http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>_______________________________________________
>Jscheme-user mailing list
>Jsc...@li...
>https://lists.sourceforge.net/lists/listinfo/jscheme-user