jscheme-devel — Developer's list

[Jscheme-devel] CVS-update

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

Update of /cvsroot/jscheme/jscheme/src/elf
In directory sc8-pr-cvs1:/tmp/cvs-serv15489/src/elf

Modified Files:
	describe.scm 
Log Message:
Fix another bug in describe and add a whoCalls capability

[Jscheme-devel] CVS-update

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

Update of /cvsroot/jscheme/jscheme/src/elf
In directory sc8-pr-cvs1:/tmp/cvs-serv5257

Modified Files:
	describe.scm 
Log Message:
Fix bug and have describe of a procedure treat the lexical environment
right.

[Jscheme-devel] CVS-update

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

Update of /cvsroot/jscheme/jscheme/src/elf
In directory sc8-pr-cvs1:/tmp/cvs-serv11304/src/elf

Modified Files:
	jdbc.scm 
Log Message:
My sql query returns byte[] rather than String.
Provide a datum-value method that does the conversion.

[Jscheme-devel] CVS-update

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

Update of /cvsroot/jscheme/jscheme/src/using
In directory sc8-pr-cvs1:/tmp/cvs-serv30310/src/using

Modified Files:
	run.scm 
Log Message:
dclass.scm: Remove definition of filter.
run.scm: fix files*

[Jscheme-devel] CVS-update

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

Update of /cvsroot/jscheme/jscheme/src/dclass
In directory sc8-pr-cvs1:/tmp/cvs-serv30310/src/dclass

Modified Files:
	dclass.scm 
Log Message:
dclass.scm: Remove definition of filter.
run.scm: fix files*

Re: [Jscheme-devel] (no subject)

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

At 11:16 AM 10/22/2003 -0400, Matthew W. Bilotti wrote:
>Dear JScheme developers,
>
>We were wondering what this error means.  It seems to come up after our 
>program has been doing what it is supposed to for awhile, and it is 
>accompanied by no other error message or Java exception.  We were hoping 
>you could shed some light on this:
>
>Fatal error allocating 12 bytesAborted

I have not seen this error before.  It may be related to your stack overflow.

>Also, in a slightly related question, we were wondering if there is any 
>way to tell how deep we are recursing or what the limit is.  It seems as 
>if we blow the stack a lot like this:
>
>> java.lang.StackOverflowError
>>         at jsint.DynamicEnvironment.getValue(DynamicEnvironment.java:95)
>>         at 
>jsint.DynamicVariable.getDynamicValue(DynamicVariable.java:13)
>>         at jsint.Scheme.execute(Scheme.java:484)
>>         at jsint.Scheme.execute(Scheme.java:514)
>>         at jsint.Procedure.makeArgArray(Procedure.java:142)
>>         at jsint.Scheme.execute(Scheme.java:521)
>>         at jsint.Scheme.execute(Scheme.java:497)
>> *       at jsint.Procedure.makeArgArray(Procedure.java:142)
>> *       at jsint.Scheme.execute(Scheme.java:521)
>
>Where the two starred lines repeat over and over again a great many times.
>Rewriting our procedure iteratively had no effect.  I only got it to work 
>by rewriting it in Java.  I am sure there is no hidden infinite recursion 
>somewhere in our code because it works for a short input.  The code also 

You can run this program to see how deep your stack is:

(define (grow n)
    (set! *n* n)
    (cons 1 (grow (+ n 1))))
(grow 1)

I get *n* to have values between 1050 and 1100.

If you write the same program in Java:
package using;

import jsint.Pair;

public class Stack {

  public static Object grow(int n) {
    System.out.println(n);
    return new Pair("1", grow(n+1));
  }
  
  public static void main(String[] args) {
    grow(1);
  }
}
You get 5600.  So your Java version may be working because it makes better use of the stack, or you write it some other way that avoids recursion.

While on windows at least, there is a -Xssn command line argument to java that sets the thread stack size, i've not been able to effect the stack size with it.

My guess is you're doing something that's recursive, try rewriting it to use tail calls.  Send me some code if you need more help.


>allocates a lot of data on the heap.  Is JScheme efficient with its memory 

JScheme is as efficient with memory and GC as Java is.

>and garbage collection?  Do the heap and the stack share memory?  Could 
>this be the problem?  We are running with -Xmx1024m.

The -Xmx only effects the heap size, not the stack size.

>Any insight you have would be greatly appreciated.
>
>Regards,
>
>Matthew Bilotti
>
>-- 
>matthew w. bilotti
>artificial intelligence laboratory
>massachusetts institute of technology
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by OSDN developer relations
>Here's your chance to show off your extensive product knowledge
>We want to know what you know. Tell us and you have a chance to win $100
>http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
>_______________________________________________
>Jscheme-devel mailing list
>Jsc...@li...
>https://lists.sourceforge.net/lists/listinfo/jscheme-devel

Re: [Jscheme-devel] (no subject)

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

On Oct 23, 2003, at 5:28 PM, Ken Anderson wrote:
> Matthew W. Bilotti <mbi...@ai...>:
>> Do the heap and the stack share memory?  Could
>> this be the problem?  We are running with -Xmx1024m.
>
> The -Xmx only effects the heap size, not the stack size.

I was going to suggest -Xms, but that's for initial heap size (-Xmx is 
max heap size).  I don't see anything for tweaking the stack.  On the 
other hand, the JVM shouldn't be putting much on the stack, unless 
somehow there are layers upon layers of Java method calls.  I wonder 
what a tool like OptimizeIt would show?

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

Re: [Jscheme-devel] stack overflow

[Matthew W. B. <mbi...@ai...>]

Dear Timothy and Ken,

Thank you both so much for your prompt reply with suggestions; I'll try 
those as soon as I get a chance.

As of yesterday, I had rewritten the program to rely on as little JScheme 
as possible, converting most of the functionality in Java.  What I'm doing 
now is JS.load on initialization and a JS.call to run one Scheme function.  
I found that this error still occurs.  You are saying that the error 
message is not one of yours, but rather a VM message.  I had never seen it 
before prior to this experiment.  Let us see if we can gather some more 
information on this error and get back to you.

Thanks again!

~ Matthew

On Thu, 23 Oct 2003, Timothy John Hickey wrote:

> 
> On Wednesday, October 22, 2003, at 11:16 AM, Matthew W. Bilotti wrote:
> 
> > Dear JScheme developers,
> >
> > We were wondering what this error means.  It seems to come up after our
> > program has been doing what it is supposed to for awhile, and it is
> > accompanied by no other error message or Java exception.  We were 
> > hoping
> > you could shed some light on this:
> >
> > Fatal error allocating 12 bytesAborted
> Could you tell us what hardware/operating system/jvm you were using
> and anything else about the program that was running?
> >
> > Also, in a slightly related question, we were wondering if there is any
> > way to tell how deep we are recursing or what the limit is.  It seems 
> > as
> > if we blow the stack a lot like this:
> >
> >> java.lang.StackOverflowError
> >>         at 
> >> jsint.DynamicEnvironment.getValue(DynamicEnvironment.java:95)
> >>         at
> > jsint.DynamicVariable.getDynamicValue(DynamicVariable.java:13)
> >>         at jsint.Scheme.execute(Scheme.java:484)
> >>         at jsint.Scheme.execute(Scheme.java:514)
> >>         at jsint.Procedure.makeArgArray(Procedure.java:142)
> >>         at jsint.Scheme.execute(Scheme.java:521)
> >>         at jsint.Scheme.execute(Scheme.java:497)
> >> *       at jsint.Procedure.makeArgArray(Procedure.java:142)
> >> *       at jsint.Scheme.execute(Scheme.java:521)
> >
> > Where the two starred lines repeat over and over again a great many 
> > times.
> > Rewriting our procedure iteratively had no effect.
> Could you send us the offending program or procedure?
> >  I only got it to work
> > by rewriting it in Java.  I am sure there is no hidden infinite 
> > recursion
> > somewhere in our code because it works for a short input.
> It could be there is a non-infinite but still very large recursion. You 
> can
> reset the maximum Java stack depth by a command line argument
>     java -Xss40m jscheme.REPL
> which, I think, allows 40MB stack sizes for each thread...
> 
> See here for more details
> http://java.sun.com/j2se/1.4.2/docs/tooldocs/linux/java.html
> >  The code also
> > allocates a lot of data on the heap.  Is JScheme efficient with its 
> > memory
> > and garbage collection?  Do the heap and the stack share memory?  Could
> > this be the problem?  We are running with -Xmx1024m.
> >
> > Any insight you have would be greatly appreciated.
> Thanks for the feedback!!
> ---Tim---
> >
> > Regards,
> >
> > Matthew Bilotti
> >
> > -- 
> > matthew w. bilotti
> > artificial intelligence laboratory
> > massachusetts institute of technology
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by OSDN developer relations
> > Here's your chance to show off your extensive product knowledge
> > We want to know what you know. Tell us and you have a chance to win 
> > $100
> > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> > _______________________________________________
> > Jscheme-devel mailing list
> > Jsc...@li...
> > https://lists.sourceforge.net/lists/listinfo/jscheme-devel
> 
> 
> 

-- 
matthew w. bilotti
artificial intelligence laboratory
massachusetts institute of technology

Re: [Jscheme-devel] (no subject)

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

I'm sending this again.  I think BBN had mailer trouble for a while.

At 11:16 AM 10/22/2003 -0400, Matthew W. Bilotti wrote:
>Dear JScheme developers,
>
>We were wondering what this error means.  It seems to come up after our 
>program has been doing what it is supposed to for awhile, and it is 
>accompanied by no other error message or Java exception.  We were hoping 
>you could shed some light on this:
>
>Fatal error allocating 12 bytesAborted

I have not seen this error before.  It may be related to your stack overflow.

>Also, in a slightly related question, we were wondering if there is any 
>way to tell how deep we are recursing or what the limit is.  It seems as 
>if we blow the stack a lot like this:
>
>> java.lang.StackOverflowError
>>         at jsint.DynamicEnvironment.getValue(DynamicEnvironment.java:95)
>>         at 
>jsint.DynamicVariable.getDynamicValue(DynamicVariable.java:13)
>>         at jsint.Scheme.execute(Scheme.java:484)
>>         at jsint.Scheme.execute(Scheme.java:514)
>>         at jsint.Procedure.makeArgArray(Procedure.java:142)
>>         at jsint.Scheme.execute(Scheme.java:521)
>>         at jsint.Scheme.execute(Scheme.java:497)
>> *       at jsint.Procedure.makeArgArray(Procedure.java:142)
>> *       at jsint.Scheme.execute(Scheme.java:521)
>
>Where the two starred lines repeat over and over again a great many times.
>Rewriting our procedure iteratively had no effect.  I only got it to work 
>by rewriting it in Java.  I am sure there is no hidden infinite recursion 
>somewhere in our code because it works for a short input.  The code also 

You can run this program to see how deep your stack is:

(define (grow n)
    (set! *n* n)
    (cons 1 (grow (+ n 1))))
(grow 1)

I get *n* to have values between 1050 and 1100.

If you write the same program in Java:
package using;

import jsint.Pair;

public class Stack {

  public static Object grow(int n) {
    System.out.println(n);
    return new Pair("1", grow(n+1));
  }
  
  public static void main(String[] args) {
    grow(1);
  }
}
You get 5600.  So your Java version may be working because it makes better use of the stack, or you write it some other way that avoids recursion.

While on windows at least, there is a -Xssn command line argument to java that sets the thread stack size, i've not been able to effect the stack size with it.

My guess is you're doing something that's recursive, try rewriting it to use tail calls.  Send me some code if you need more help.


>allocates a lot of data on the heap.  Is JScheme efficient with its memory 

JScheme is as efficient with memory and GC as Java is.

>and garbage collection?  Do the heap and the stack share memory?  Could 
>this be the problem?  We are running with -Xmx1024m.

The -Xmx only effects the heap size, not the stack size.

>Any insight you have would be greatly appreciated.
>
>Regards,
>
>Matthew Bilotti
>
>-- 
>matthew w. bilotti
>artificial intelligence laboratory
>massachusetts institute of technology
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by OSDN developer relations
>Here's your chance to show off your extensive product knowledge
>We want to know what you know. Tell us and you have a chance to win $100
>http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
>_______________________________________________
>Jscheme-devel mailing list
>Jsc...@li...
>https://lists.sourceforge.net/lists/listinfo/jscheme-devel

Re: [Jscheme-devel] stack overflow

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

On Wednesday, October 22, 2003, at 11:16 AM, Matthew W. Bilotti wrote:

> Dear JScheme developers,
>
> We were wondering what this error means.  It seems to come up after our
> program has been doing what it is supposed to for awhile, and it is
> accompanied by no other error message or Java exception.  We were 
> hoping
> you could shed some light on this:
>
> Fatal error allocating 12 bytesAborted
Could you tell us what hardware/operating system/jvm you were using
and anything else about the program that was running?
>
> Also, in a slightly related question, we were wondering if there is any
> way to tell how deep we are recursing or what the limit is.  It seems 
> as
> if we blow the stack a lot like this:
>
>> java.lang.StackOverflowError
>>         at 
>> jsint.DynamicEnvironment.getValue(DynamicEnvironment.java:95)
>>         at
> jsint.DynamicVariable.getDynamicValue(DynamicVariable.java:13)
>>         at jsint.Scheme.execute(Scheme.java:484)
>>         at jsint.Scheme.execute(Scheme.java:514)
>>         at jsint.Procedure.makeArgArray(Procedure.java:142)
>>         at jsint.Scheme.execute(Scheme.java:521)
>>         at jsint.Scheme.execute(Scheme.java:497)
>> *       at jsint.Procedure.makeArgArray(Procedure.java:142)
>> *       at jsint.Scheme.execute(Scheme.java:521)
>
> Where the two starred lines repeat over and over again a great many 
> times.
> Rewriting our procedure iteratively had no effect.
Could you send us the offending program or procedure?
>  I only got it to work
> by rewriting it in Java.  I am sure there is no hidden infinite 
> recursion
> somewhere in our code because it works for a short input.
It could be there is a non-infinite but still very large recursion. You 
can
reset the maximum Java stack depth by a command line argument
    java -Xss40m jscheme.REPL
which, I think, allows 40MB stack sizes for each thread...

See here for more details
http://java.sun.com/j2se/1.4.2/docs/tooldocs/linux/java.html
>  The code also
> allocates a lot of data on the heap.  Is JScheme efficient with its 
> memory
> and garbage collection?  Do the heap and the stack share memory?  Could
> this be the problem?  We are running with -Xmx1024m.
>
> Any insight you have would be greatly appreciated.
Thanks for the feedback!!
---Tim---
>
> Regards,
>
> Matthew Bilotti
>
> -- 
> matthew w. bilotti
> artificial intelligence laboratory
> massachusetts institute of technology
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by OSDN developer relations
> Here's your chance to show off your extensive product knowledge
> We want to know what you know. Tell us and you have a chance to win 
> $100
> http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
> _______________________________________________
> Jscheme-devel mailing list
> Jsc...@li...
> https://lists.sourceforge.net/lists/listinfo/jscheme-devel

[Jscheme-devel] (no subject)

[Matthew W. B. <mbi...@ai...>]

Dear JScheme developers,

We were wondering what this error means.  It seems to come up after our 
program has been doing what it is supposed to for awhile, and it is 
accompanied by no other error message or Java exception.  We were hoping 
you could shed some light on this:

Fatal error allocating 12 bytesAborted

Also, in a slightly related question, we were wondering if there is any 
way to tell how deep we are recursing or what the limit is.  It seems as 
if we blow the stack a lot like this:

> java.lang.StackOverflowError
>         at jsint.DynamicEnvironment.getValue(DynamicEnvironment.java:95)
>         at 
jsint.DynamicVariable.getDynamicValue(DynamicVariable.java:13)
>         at jsint.Scheme.execute(Scheme.java:484)
>         at jsint.Scheme.execute(Scheme.java:514)
>         at jsint.Procedure.makeArgArray(Procedure.java:142)
>         at jsint.Scheme.execute(Scheme.java:521)
>         at jsint.Scheme.execute(Scheme.java:497)
> *       at jsint.Procedure.makeArgArray(Procedure.java:142)
> *       at jsint.Scheme.execute(Scheme.java:521)

Where the two starred lines repeat over and over again a great many times.
Rewriting our procedure iteratively had no effect.  I only got it to work 
by rewriting it in Java.  I am sure there is no hidden infinite recursion 
somewhere in our code because it works for a short input.  The code also 
allocates a lot of data on the heap.  Is JScheme efficient with its memory 
and garbage collection?  Do the heap and the stack share memory?  Could 
this be the problem?  We are running with -Xmx1024m.

Any insight you have would be greatly appreciated.

Regards,

Matthew Bilotti

-- 
matthew w. bilotti
artificial intelligence laboratory
massachusetts institute of technology

[Jscheme-devel] CVS-update

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

Update of /cvsroot/jscheme/jscheme/src/elf/eopl2/jscheme
In directory sc8-pr-cvs1:/tmp/cvs-serv4380/src/elf/eopl2/jscheme

Modified Files:
	jscheme-init.scm 
Log Message:
jscheme-init.scm - fix html.
Scheme.java and U.java - some performance improvements.

[Jscheme-devel] CVS-update

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

Update of /cvsroot/jscheme/jscheme/src/jsint
In directory sc8-pr-cvs1:/tmp/cvs-serv4380/src/jsint

Modified Files:
	Scheme.java U.java 
Log Message:
jscheme-init.scm - fix html.
Scheme.java and U.java - some performance improvements.

[Jscheme-devel] CVS-update

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

Update of /cvsroot/jscheme/jscheme/src/elf
In directory sc8-pr-cvs1:/tmp/cvs-serv21700/src/elf

Modified Files:
	html.scm sort.scm 
Log Message:
elf/html.scm fix import.
elf/sort.scm Add Kent Dybvig's merge sort.
src/elf/eopl2/jscheme/psyntax-init.scm remove print.
src/jsint/InputPort.java Use toNum() rathan new Integer().

[Jscheme-devel] CVS-update

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

Update of /cvsroot/jscheme/jscheme/src/using
In directory sc8-pr-cvs1:/tmp/cvs-serv21972

Removed Files:
	Active.class 
Log Message:
Remove Active.class

[Jscheme-devel] CVS-update

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

Update of /cvsroot/jscheme/jscheme/src/elf/eopl2/jscheme
In directory sc8-pr-cvs1:/tmp/cvs-serv21700/src/elf/eopl2/jscheme

Modified Files:
	psyntax-init.scm 
Log Message:
elf/html.scm fix import.
elf/sort.scm Add Kent Dybvig's merge sort.
src/elf/eopl2/jscheme/psyntax-init.scm remove print.
src/jsint/InputPort.java Use toNum() rathan new Integer().

[Jscheme-devel] CVS-update

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

Update of /cvsroot/jscheme/jscheme/src/jsint
In directory sc8-pr-cvs1:/tmp/cvs-serv21700/src/jsint

Modified Files:
	InputPort.java U.java 
Log Message:
elf/html.scm fix import.
elf/sort.scm Add Kent Dybvig's merge sort.
src/elf/eopl2/jscheme/psyntax-init.scm remove print.
src/jsint/InputPort.java Use toNum() rathan new Integer().

Re: [Jscheme-devel] loading from remote URLs

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

Sorry to take 4 months to answer this.  I think loading from a URL is a great idea.  If you're willing to put your code in a jar i think it will work easily.
So if you put the jscheme code in a NioGroupTools.jar something like this should work:

(load "elf/classpath.scm")
(define (addClasspathUrl u) (.addURL# (Import.getClassLoader) (url u)))

(addClasspathUrl
 "http://groupscheme.sourceforge.net/lib/groupscheme/kernel/NioGroupTools.jar")

(load "groupscheme/kernel/NioGroupTools.scm")'

Would this work for you? 
k

At 07:01 PM 6/21/2003 -0400, Timothy John Hickey wrote:

>On Saturday, June 21, 2003, at 06:48 PM, Ken Anderson wrote:
>
>>At 05:57 PM 6/21/2003 -0400, Timothy John Hickey wrote:
>>>Hi Jscheme afficionados,
>>>
>>> I've started using the ability to load from a URL and its very nice.  
>>>One problem is
>>>occurs when we load a file F from a URL and that file contains  
>>>non-URL load statements.
>>>The natural interpretation would be to look for these embedded loads  
>>>on that remote URL
>>>(just as happens with relative links in webpages), but currently  
>>>Jscheme looks for those
>>>files locally. It should be pretty easy to get around this problem  
>>>(keep a stack of URLs
>>>and always use the top of the stack for loads).
>>>
>>>What do you think? Am I missing some unintended consequence?
>>
>>maybe you've found two (or more) features of JScheme that need to be  
>>combined in a better way, certainly in a way that hasn't been tried  
>>before.
>>
>>The normal (load f) tries to open an input port treating f as first a  
>>file, then a resource, and then a URL..
>>
>>This order was chosen because the .scm file would be in a local file  
>>before it gets moved into a jar file for a delivered application.
>>
>>I've never thought about the URL case.  JScheme has a dynamic class  
>>path, and perhaps such a URL should be added to that path.
>>
>>What are you trying to do?
>
>I was thinking that an easy way of demonstrating some of the groupware  
>demos would be to
>just provide the code for the demo in which the first few lines import  
>the necessary groupware
>libraries, e.g.
>>
>>(load  
>>"http://groupscheme.sourceforge.net/lib/groupscheme/kernel/ NioGroupTools.scm")
>>....code that uses this library....
>
>The problem is that the NioGroupTools.scm library loads in four local  
>files and two jar files ...
>>
>>(environment-import "groupscheme/kernel/SendLine.scm")
>>(environment-import "groupscheme/util/PrintDebug.scm")
>>(environment-import "groupscheme/util/Swing.scm" "sw:")
>>(environment-import "groupscheme/util/Queue.scm" "multi-queue:")
>>
>>(environment-import "jlib/Swing.scm")
>>(environment-import "elf/basic.scm")
>>
>>(define nioclass java.nio.channels.Selector.class)
>>....
>The environment-import is implemented as a load into a separate  
>namespace followed
>by a copy into the current namespace (possibly with prefixes added).
>
>If the load procedure noticed that these loads were in remote file and  
>then looked remotely for those
>files, there would be no problem.
>
>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: INetU
>>Attention Web Developers & Consultants: Become An INetU Hosting  
>>Partner.
>>Refer Dedicated Servers. We Manage Them. You Get 10% Monthly  
>>Commission!
>>INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
>>_______________________________________________
>>Jscheme-devel mailing list
>>Jsc...@li...
>>https://lists.sourceforge.net/lists/listinfo/jscheme-devel

Re: [Jscheme-devel] quasi-string syntax for Java

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

I just came across this email.

I think it is interesting to use "{{"  and "}}" as the delimiter.  This is more typing, but doesn't use up "{}" and "[]" as our approach does.

Since it only handles Java expressions inside, you probably need to write a set of Scheme like support functions to do things like separate a list of arguments with commas.

k

At 10:13 AM 8/21/2003 -0400, Timothy John Hickey wrote:
>Here's a link to an interesting preprocessor that allows quasi-string like
>syntax in Java ....
>
>     http://virtualschool.edu/java+/syntax.html
>
>I wonder how far preprocessing could go in making Java more Scheme-like...
>
>---Tim---
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: VM Ware
>With VMware you can run multiple operating systems on a single machine.
>WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
>at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
>_______________________________________________
>Jscheme-devel mailing list
>Jsc...@li...
>https://lists.sourceforge.net/lists/listinfo/jscheme-devel

[Jscheme-devel] quasi-string syntax for Java

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

Here's a link to an interesting preprocessor that allows quasi-string 
like
syntax in Java ....

      http://virtualschool.edu/java+/syntax.html

I wonder how far preprocessing could go in making Java more 
Scheme-like...

---Tim---

[Jscheme-devel] CVS-update

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

Update of /cvsroot/jscheme/jscheme/src/jsint
In directory sc8-pr-cvs1:/tmp/cvs-serv15283

Modified Files:
	DynamicEnvironment.java 
Log Message:
Don't show javadot warnings by default.

[Jscheme-devel] CVS-update

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

Update of /cvsroot/jscheme/jscheme/src/using
In directory sc8-pr-cvs1:/tmp/cvs-serv14785/src/using

Modified Files:
	run.scm 
Log Message:
Remove dependency on comparator which may not be there early in build process.

Re: [Jscheme-devel] CVS-update

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

At 08:19 AM 7/25/2003 -0700, Timothy John Hickey wrote:
>Update of /cvsroot/jscheme/jscheme/src/jsint
>In directory sc8-pr-cvs1:/tmp/cvs-serv871/src/jsint
>
>Modified Files:
>        Compile.scm Symbol.java 
>Log Message:
>added jsint.Symbol.showJavaDotWarnings$ boolean flag, modified to jscheme/SchemeTests.scm to explain warnings, turned off JavaDot warnings during build of the compiler

This handles the most common case of warning, where you want to load code before the classes it references are compiled.

However, when you try to use a class that may not be compiled when you want to run it, you need to do something special, like check for the class or catch an exception.  You also need to turn javadot warnings off.  I've done this in using/run.scm for example.  So the code is annoyingly ugly, in code that should be a good example of Jscheme code.  

I was going to recommend getting rid of the the warning altogether, but i'll just refactor this code.

k 

[Jscheme-devel] Re: First bite! -- anonymous CVS is 1+ days out of sync

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

On Saturday, July 26, 2003, at 20:34, Timothy John Hickey wrote:
> Ahhh. You are using anonymous checkout (pserver) and I am using 
> developer checkout.
> Sourceforge just recently moved anonymous checkout to a separate 
> server which is only backed up
> once a day. So your CVS is 24 hours out of sync!!!!

I'm happy to report that this morning's anonymous CVS checkout and 
build was AOK.

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

[Jscheme-devel] First bite! -- anonymous CVS is 1+ days out of sync

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

On Saturday, July 26, 2003, at 06:50 PM, Geoffrey Knauth wrote:
> Bizarre.  I just tried with fresh CVS checkouts on Mac OS X (10.3) and  
> RedHat 9.0, and I still get the 2 warnings for jsint.compiler.Reflect  
> and jsint.compiler.CompileReflection.
>
> I do see you have a clean build.
>
> Maybe you have something in your CLASSPATH that is causing the  
> warnings not to appear?

Ahhh. You are using anonymous checkout (pserver) and I am using  
developer checkout.
Sourceforge just recently moved anonymous checkout to a separate server  
which is only backed up
once a day. So your CVS is 24 hours out of sync!!!!
The message from sourceforge is quoted below. I saw it, but it didn't  
sink in until a few minutes ago!
Maybe tomorrow will be better.

FROM SOURCEFORGE EMAIL .....
> As you may have noticed, CVS is visibly having growing pains.  Due to
> system load, we have had to move anonymous checkouts to our backup
> server.  This has made the code of our 65,000 projects more
> accessible.  However, since data is synchronized from the primary
> CVS servers to the backup CVS servers at specific times during the day,
> it has also caused up to a 24 hour delay in getting the
> freshest code on the site.
Sorry for the confusion!


>
> Geoffrey
>
> On Saturday, July 26, 2003, at 09:37, Timothy John Hickey wrote:
>
>>
>> On Saturday, July 26, 2003, at 09:28 AM, Geoffrey Knauth wrote:
>>
>>> I'm still getting the 2 warnings.  I'll try again later.
>> Could you try once more.
>> I've just checked out the lastest CVS and compiled it and get no  
>> warnings during the compiler compilation phase.
>> Here is what I get ... there are still some warnings, but these are  
>> in the SchemeTest code, which ought to be OK...
>>
>>> [Timothy-Hickeys-Computer:/tmp/jscheme] tim% src/build/bootstrap
>>> generated Listener11.java
>>> generated Listener11swing.java
>>> generated Listener.java
>>> Javacing 8 files
>>> Compiling the compiler....
>>> Compiling jsint/compiler/Reflect to package jsint.compiler
>>>
>>> Javacing 1 file
>>> Compiling jsint/compiler/CompileReflection to package jsint.compiler
>>>
>>> Javacing 1 file
>>> Compiling jsint/compiler/Compiler to package jsint.compiler
>>>
>>> Javacing 1 file
>>> Compiling jsint/Compile to package jsint
>>>
>>> Javacing 1 file
>>> Javacing 1 file
>>> Note: src/jlib/SchemeCanvas.java uses or overrides a deprecated API.
>>> Note: Recompile with -deprecation for details.
>>> Compiling jlib/JLIB to package jlib
>>>
>>> Javacing 1 file
>>> Compiling jlib/Swing to package jlib
>>>
>>> Javacing 1 file
>>> Compiling jlib/Networking to package jlib
>>>
>>> Javacing 1 file
>>> Note: src/jlib/Networking.java uses or overrides a deprecated API.
>>> Note: Recompile with -deprecation for details.
>>> Compiling jlib/SNLP to package jlib
>>>
>>> Javacing 1 file
>>> Javacing 5 files
>>> Note: src/build/CompilingLoadlet.java uses or overrides a deprecated  
>>> API.
>>> Note: Recompile with -deprecation for details.
>>> Javacing 10 files
>>> Javacing 3 files
>>> Javacing 4 files
>>> Javacing 3 files
>>> Note: Some input files use or override a deprecated API.
>>> Note: Recompile with -deprecation for details.
>>> Javacing 2 files
>>> Javacing 1 file
>>>
>>>
>>> **************** 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
>>>
>>> Javadot WARNING: no such field: class jsint.Symbol.name
>>> Javadot WARNING: no such field: class jsint.Symbol.name
>>> ** 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
>>> Javadot WARNING: Constructor jsint.Symbol has no methods.
>>> Javadot WARNING: Constructor jsint.Symbol has no methods.
>>> Tests: 247 Failures: 0
>>>
>>> All tests have completed with any errors as shown above
>>> Try (run-tests #t) to see both failing and successful tests and  
>>> their results
>>> ********************* jscheme/SchemeTests.scm has completed  
>>> ***********************
>>>
>>>
>>> lib/jscheme.jar built.
>>> lib/applet.jar built.
>>> lib/jschemelite.jar build.
>>> Loading source files for package build...
>>> Loading source files for package dclass...
>>> Loading source files for package elf...
>>> Loading source files for package interact...
>>> Loading source files for package jlib...
>>> Loading source files for package jscheme...
>>> Loading source files for package jschemeweb...
>>> Loading source files for package jsint...
>>> Loading source files for package using...
>>> Constructing Javadoc information...
>>> Standard Doclet version 1.4.1
>>>
>>> Generating doc/api/constant-values.html...
>>> Building tree for all the packages and classes...
>>> Generating doc/api/build/class-use/SchemeLite.html...
>>> Generating doc/api/build/class-use/LoadletClassLoader.html...
>> ....
>>
>>
>>
>>>   Thanks for all your efforts to make this squeaky clean!
>> My pleasure.
>>>
>>> Geoffrey
>>> --
>>> Geoffrey S. Knauth | http://knauth.org/gsk
>>>
>>> On Saturday, July 26, 2003, at 08:28, Timothy John Hickey wrote:
>>>
>>>> Update of /cvsroot/jscheme/jscheme/src/jsint
>>>> In directory sc8-pr-cvs1:/tmp/cvs-serv23990/src/jsint
>>>>
>>>> Modified Files:
>>>> 	DynamicEnvironment.java Symbol.java
>>>> Log Message:
>>>> moved showJavaDotWarnings flag to DynamicEnvironments, where it  
>>>> belongs!
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email sponsored by: Free pre-built ASP.NET sites  
>>>> including
>>>> Data Reports, E-commerce, Portals, and Forums are available now.
>>>> Download today and enter to win an XBOX or Visual Studio .NET.
>>>> http://aspnet.click-url.com/go/psa00100003ave/ 
>>>> direct;at.aspnet_072303_01/01
>>>> _______________________________________________
>>>> Jscheme-devel mailing list
>>>> Jsc...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/jscheme-devel
>>>>
>>>>
>>
>>
>