jscheme-user — list for general users

Re: [Jscheme-user] Ability to Sub-class a Java Object?

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

There are several ways to do this.  see
http://jscheme.sourceforge.net/jscheme/src/dclass/dclass.htmlsrc/dclass/dclass.html 


The closest thing to what Jython does is
(define-class).  This requires you to declare types for all your methods, 
so it isn't as nice as Jython's way.

I'd like to do it Jython's way at some point.

At 11:00 AM 9/9/2002, Kyle R . Burton wrote:
>I haven't been able to find anything in the documentaiton talking about
>how to create an object (or some type of equivaletn construct) in jscheme
>that effectivly inhertis from a Java class.  Is this possible?
>
>I beleive that inheriting from a Java class is supported by one or more
>of the other Java scriping projects.  Jython gives an example:
>
>   http://www.jython.org/docs/subclassing.html
>
>IBM's Skij project doesn't seem to support inheritence, and it does not
>appear to be active, since the maintainer has left IBM and IBM has not
>released the code under any kind of open license.
>
>The behavior I am looking for is to use a Java abstract class or interface,
>and implement the required methods in scheme to be able to do rapid
>prototyping.
>
>
>Thank you for your time.
>
>Kyle R. Burton
>
>--
>
>------------------------------------------------------------------------------
>Wisdom and Compassion are inseparable.
>         -- Christmas Humphreys
>mo...@vo...                            http://www.voicenet.com/~mortis
>------------------------------------------------------------------------------
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by: OSDN - Tired of that same old
>cell phone?  Get a new here for FREE!
>https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>_______________________________________________
>Jscheme-user mailing list
>Jsc...@li...
>https://lists.sourceforge.net/lists/listinfo/jscheme-user

[Jscheme-user] Ability to Sub-class a Java Object?

[Kyle R . B. <mo...@vo...>]

I haven't been able to find anything in the documentaiton talking about
how to create an object (or some type of equivaletn construct) in jscheme
that effectivly inhertis from a Java class.  Is this possible?

I beleive that inheriting from a Java class is supported by one or more 
of the other Java scriping projects.  Jython gives an example:

  http://www.jython.org/docs/subclassing.html

IBM's Skij project doesn't seem to support inheritence, and it does not 
appear to be active, since the maintainer has left IBM and IBM has not 
released the code under any kind of open license.

The behavior I am looking for is to use a Java abstract class or interface, 
and implement the required methods in scheme to be able to do rapid 
prototyping.


Thank you for your time.

Kyle R. Burton

-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------

Re: [Jscheme-user] Compiled Macros

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

No. (F.load) should install the value of all top level symbols, macros or not.

IE the effect of (F.load) and (load "F.scm") should be the same, except 
that the macros and procedures are compiled.

k

At 05:16 PM 9/5/2002, Timothy Hickey wrote:
>On Thursday, September 5, 2002, at 04:55 PM, Graham Spencer wrote:
>>Timothy Hickey wrote:
>>
>> > We could also automatically compile macro1.scm when the (load
>> > "macro1.scm") expression is compiled in macro2.scm or we could just
>> > scan through it and pull out the macro definitions.....
>>
>>I like this sort of approach better than an include statement because it 
>>means that as a user of a library, I don't have to remember which 
>>definitions are functions and which are macros. If macros and functions 
>>are handled differently, then a library provider would have to create two 
>>separate files so that the user could do:
>>
>>         (include "mylib-macros.scm")
>>         (load "mylib.scm")
>>
>>Ideally, the macro definitions would be saved in the java file so that 
>>they would work even if the user was loading a compiled .class file, e.g. 
>>(mylib.load). This would guarantee that (load "mylib.scm") and 
>>(mylib.load) always had the same semantics. It would also allow JScheme 
>>libraries to be distributed as .class/.jar files.
>
>This is an interesting point. It would be nice to be able to distribute 
>libraries as class files
>and to have
>       (load F.scm)
>be equivalent to
>       (F.load).
>but this suggests that the compiled class should provide a way of 
>accessing the defined macros
>so that the compiler can extract the macros from the .class file as easily 
>as from the .scm file, e.g.
>     (F.getMacros)
>could return a hashtable containing the macros defined in the Swing.scm 
>library.
>
>---Tim---
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by: OSDN - Tired of that same old
>cell phone?  Get a new here for FREE!
>https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>_______________________________________________
>Jscheme-user mailing list
>Jsc...@li...
>https://lists.sourceforge.net/lists/listinfo/jscheme-user
>

Re: [Jscheme-user] Compiled Macros

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

On Thursday, September 5, 2002, at 04:55 PM, Graham Spencer wrote:
> Timothy Hickey wrote:
>
> > We could also automatically compile macro1.scm when the (load
> > "macro1.scm") expression is compiled in macro2.scm or we could just
> > scan through it and pull out the macro definitions.....
>
> I like this sort of approach better than an include statement because 
> it means that as a user of a library, I don't have to remember which 
> definitions are functions and which are macros. If macros and functions 
> are handled differently, then a library provider would have to create 
> two separate files so that the user could do:
>
> 	(include "mylib-macros.scm")
> 	(load "mylib.scm")
>
> Ideally, the macro definitions would be saved in the java file so that 
> they would work even if the user was loading a compiled .class file, 
> e.g. (mylib.load). This would guarantee that (load "mylib.scm") and 
> (mylib.load) always had the same semantics. It would also allow JScheme 
> libraries to be distributed as .class/.jar files.

This is an interesting point. It would be nice to be able to distribute 
libraries as class files
and to have
       (load F.scm)
be equivalent to
       (F.load).
but this suggests that the compiled class should provide a way of 
accessing the defined macros
so that the compiler can extract the macros from the .class file as 
easily as from the .scm file, e.g.
     (F.getMacros)
could return a hashtable containing the macros defined in the Swing.scm 
library.

---Tim---

Re: [Jscheme-user] Compiled Macros

[Graham S. <fo...@pa...>]

Timothy Hickey wrote:

 > We could also automatically compile macro1.scm when the (load
 > "macro1.scm") expression is compiled in macro2.scm or we could just
 > scan through it and pull out the macro definitions.....

I like this sort of approach better than an include statement because it 
means that as a user of a library, I don't have to remember which 
definitions are functions and which are macros. If macros and functions 
are handled differently, then a library provider would have to create 
two separate files so that the user could do:

	(include "mylib-macros.scm")
	(load "mylib.scm")

Ideally, the macro definitions would be saved in the java file so that 
they would work even if the user was loading a compiled .class file, 
e.g. (mylib.load). This would guarantee that (load "mylib.scm") and 
(mylib.load) always had the same semantics. It would also allow JScheme 
libraries to be distributed as .class/.jar files.

--g

Re: [Jscheme-user] Compiled Macros

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

Maybe there could be a way to mark certain symbols against accidental 
overwriting.  If you really wanted to reimplement or override some of 
the basic functions, could you unprotect them first.

Geoffrey

On Thursday, September 5, 2002, at 02:20 PM, Timothy Hickey wrote:

>
>
> On Thursday, September 5, 2002, at 09:45 AM, Ken Anderson wrote:
>> I'm not opposed to a module approach, but what happens in Common Lisp 
>> is that macros become part of the compiler's environment.  So when 
>> the compiler compiles something it uses all the macros its seen.
>
> At 07:24 PM 9/4/2002, Graham Spencer wrote:
>                 .....snip....
>> The (load "macro2.scm") works as expected, but in (macro2.load), the 
>> macro defined in macro1.scm is expanded but not evaluated.
>
> This is a bug, it should either evaluate as expected or signal an 
> error, the expansion is just wrong...
>
>>  In general, I cannot get macros defined in one compiled .class file 
>> to work in another file.
>
>> Am I doing something wrong, or is this really a bug?
>
> We need to do something about this, whether it is a bug or not.
> The brute force method is just to copy the macros you need into every 
> file that uses them,
> but this is clearly wrong as it calls out for refactoring.
>
> Using an "include" statement to include the macros  into the file is a 
> simple approach
> but it could be abused if something besides macros is included.
>
> The Common Lisp approach is a good idea. It shouldn't require too much 
> of a change to implement it.
> It does create problems if someone compiles a program that redefines 
> one of the base macros
> (like cond or do) as this will break the compiler......
> With this method we would handle Graham's macro1.scm macro2.scm 
> example by compiling them together..
>   %java jsint.Compile macro1.scm macro2.scm
>
> We could also automatically compile macro1.scm when the (load 
> "macro1.scm") expression is compiled
> in macro2.scm or we could just scan through it and pull out the macro 
> definitions.....
>
> A final approach is to create a special directive for loading in 
> macros, e.g.
>    (load-macros "macro1.scm")
> which the compiler could use to specify the language that should be 
> used during
> the current compilation.
>
> I like the last idea. It is relatively simple to implement. It has a 
> simple semantics,
> and it solves Graham's problem.
>
> On the other hand the "include" option is even simpler and its only 
> drawback is that
> it might be dangerous for people who don't know what they are doing, 
> but *hey* so
> are the macros we use in jscheme.....
>
> Ideas or Comments??
>
> ---Tim---
>
>
>
>
>
>
>>
>> At 08:51 AM 9/5/2002, Timothy Hickey wrote:
>>
>>> On second thought, Graham's example points out the need for modules!
>>> In Dr. Scheme, one can specify a "language" when importing a module.
>>> The language is a collection of macros.
>>>
>>> I'll take a closer look at how the jscheme compiler handles macros
>>> and report back to this list.
>>>
>>> It would be nice to have someway of indicating in the program code
>>> that the program should be compiled using some set of macros.
>>> One easy way would be to add an "include" command that would simply
>>> include the macro code in the source before compiling, e.g.
>>>
>>> ;; macro2a.scm
>>> (include "macro1.scm")
>>> (define-macro (myplus2 a b)
>>>   `(+ ,a ,b))
>>> (.println java.lang.System.out$ (myplus1 1 2))
>>> (.println java.lang.System.out$ (myplus2 1 2))
>>>
>>> This is essentially the way the C handles shared type declarations,
>>> by storing them in .h files which are then included whereever they 
>>> are needed.
>>>
>>> What do you think??
>>> ---Tim---
>>>
>>>
>>>>> At 07:24 PM 9/4/2002, Graham Spencer wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I think I've found a bug in JScheme version 5.0.0. Given the 
>>>>>> following two files:
>>>>>>
>>>>>> ;; macro1.scm
>>>>>> (define-macro (myplus1 a b)
>>>>>>   `(+ ,a ,b))
>>>>>>
>>>>>> ;; macro2.scm
>>>>>> (load "macro1.scm")
>>>>>> (define-macro (myplus2 a b)
>>>>>>   `(+ ,a ,b))
>>>>>> (.println java.lang.System.out$ (myplus1 1 2))
>>>>>> (.println java.lang.System.out$ (myplus2 1 2))
>>>>>>
>>>>>> If I compile both files to .class files and then run jscheme.REPL:
>>>>>>
>>>>>> Jscheme 5.0 04/05/2002 http://jscheme.sourceforge.net
>>>>>> > (load "macro2.scm")
>>>>>> 3
>>>>>> 3
>>>>>> #t
>>>>>> > (macro2.load)
>>>>>> (+ 1 2)
>>>>>> 3
>>>>>> #null
>>>>>>
>>>>>> The (load "macro2.scm") works as expected, but in (macro2.load), 
>>>>>> the macro defined in macro1.scm is expanded but not evaluated. In 
>>>>>> general, I cannot get macros defined in one compiled .class file 
>>>>>> to work in another file. Am I doing something wrong, or is this 
>>>>>> really a bug?
>>>>>>
>>>>>> (My apologies if I should have posted this bug report somewhere 
>>>>>> else.)
>>>>>>
>>>>>> Thanks for your help,
>>>>>>
>>>>>> --g
>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------------
>>>>> This sf.net email is sponsored by: OSDN - Tired of that same old
>>>>> cell phone?  Get a new here for FREE!
>>>>> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>>>>> _______________________________________________
>>>>> Jscheme-user mailing list
>>>>> Jsc...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/jscheme-user
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This sf.net email is sponsored by: OSDN - Tired of that same old
>>>> cell phone?  Get a new here for FREE!
>>>> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>>>> _______________________________________________
>>>> Jscheme-user mailing list
>>>> Jsc...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/jscheme-user
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This sf.net email is sponsored by: OSDN - Tired of that same old
>>> cell phone?  Get a new here for FREE!
>>> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>>> _______________________________________________
>>> Jscheme-user mailing list
>>> Jsc...@li...
>>> https://lists.sourceforge.net/lists/listinfo/jscheme-user
>>>
>>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Jscheme-user mailing list
> Jsc...@li...
> https://lists.sourceforge.net/lists/listinfo/jscheme-user
>
>
--
Geoffrey S. Knauth				http://knauth.org/gsk

Re: [Jscheme-user] Compiled Macros

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

On Thursday, September 5, 2002, at 09:45 AM, Ken Anderson wrote:
> I'm not opposed to a module approach, but what happens in Common Lisp 
> is that macros become part of the compiler's environment.  So when the 
> compiler compiles something it uses all the macros its seen.

At 07:24 PM 9/4/2002, Graham Spencer wrote:
                 .....snip....
> The (load "macro2.scm") works as expected, but in (macro2.load), the 
> macro defined in macro1.scm is expanded but not evaluated.

This is a bug, it should either evaluate as expected or signal an error, 
the expansion is just wrong...

>  In general, I cannot get macros defined in one compiled .class file to 
> work in another file.

> Am I doing something wrong, or is this really a bug?

We need to do something about this, whether it is a bug or not.
The brute force method is just to copy the macros you need into every 
file that uses them,
but this is clearly wrong as it calls out for refactoring.

Using an "include" statement to include the macros  into the file is a 
simple approach
but it could be abused if something besides macros is included.

The Common Lisp approach is a good idea. It shouldn't require too much 
of a change to implement it.
It does create problems if someone compiles a program that redefines one 
of the base macros
(like cond or do) as this will break the compiler......
With this method we would handle Graham's macro1.scm macro2.scm example 
by compiling them together..
   %java jsint.Compile macro1.scm macro2.scm

We could also automatically compile macro1.scm when the (load 
"macro1.scm") expression is compiled
in macro2.scm or we could just scan through it and pull out the macro 
definitions.....

A final approach is to create a special directive for loading in macros, 
e.g.
    (load-macros "macro1.scm")
which the compiler could use to specify the language that should be used 
during
the current compilation.

I like the last idea. It is relatively simple to implement. It has a 
simple semantics,
and it solves Graham's problem.

On the other hand the "include" option is even simpler and its only 
drawback is that
it might be dangerous for people who don't know what they are doing, but 
*hey* so
are the macros we use in jscheme.....

Ideas or Comments??

---Tim---






>
> At 08:51 AM 9/5/2002, Timothy Hickey wrote:
>
>> On second thought, Graham's example points out the need for modules!
>> In Dr. Scheme, one can specify a "language" when importing a module.
>> The language is a collection of macros.
>>
>> I'll take a closer look at how the jscheme compiler handles macros
>> and report back to this list.
>>
>> It would be nice to have someway of indicating in the program code
>> that the program should be compiled using some set of macros.
>> One easy way would be to add an "include" command that would simply
>> include the macro code in the source before compiling, e.g.
>>
>> ;; macro2a.scm
>> (include "macro1.scm")
>> (define-macro (myplus2 a b)
>>   `(+ ,a ,b))
>> (.println java.lang.System.out$ (myplus1 1 2))
>> (.println java.lang.System.out$ (myplus2 1 2))
>>
>> This is essentially the way the C handles shared type declarations,
>> by storing them in .h files which are then included whereever they are 
>> needed.
>>
>> What do you think??
>> ---Tim---
>>
>>
>>>> At 07:24 PM 9/4/2002, Graham Spencer wrote:
>>>>> Hello,
>>>>>
>>>>> I think I've found a bug in JScheme version 5.0.0. Given the 
>>>>> following two files:
>>>>>
>>>>> ;; macro1.scm
>>>>> (define-macro (myplus1 a b)
>>>>>   `(+ ,a ,b))
>>>>>
>>>>> ;; macro2.scm
>>>>> (load "macro1.scm")
>>>>> (define-macro (myplus2 a b)
>>>>>   `(+ ,a ,b))
>>>>> (.println java.lang.System.out$ (myplus1 1 2))
>>>>> (.println java.lang.System.out$ (myplus2 1 2))
>>>>>
>>>>> If I compile both files to .class files and then run jscheme.REPL:
>>>>>
>>>>> Jscheme 5.0 04/05/2002 http://jscheme.sourceforge.net
>>>>> > (load "macro2.scm")
>>>>> 3
>>>>> 3
>>>>> #t
>>>>> > (macro2.load)
>>>>> (+ 1 2)
>>>>> 3
>>>>> #null
>>>>>
>>>>> The (load "macro2.scm") works as expected, but in (macro2.load), 
>>>>> the macro defined in macro1.scm is expanded but not evaluated. In 
>>>>> general, I cannot get macros defined in one compiled .class file to 
>>>>> work in another file. Am I doing something wrong, or is this really 
>>>>> a bug?
>>>>>
>>>>> (My apologies if I should have posted this bug report somewhere 
>>>>> else.)
>>>>>
>>>>> Thanks for your help,
>>>>>
>>>>> --g
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This sf.net email is sponsored by: OSDN - Tired of that same old
>>>> cell phone?  Get a new here for FREE!
>>>> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>>>> _______________________________________________
>>>> Jscheme-user mailing list
>>>> Jsc...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/jscheme-user
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This sf.net email is sponsored by: OSDN - Tired of that same old
>>> cell phone?  Get a new here for FREE!
>>> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>>> _______________________________________________
>>> Jscheme-user mailing list
>>> Jsc...@li...
>>> https://lists.sourceforge.net/lists/listinfo/jscheme-user
>>
>>
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by: OSDN - Tired of that same old
>> cell phone?  Get a new here for FREE!
>> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>> _______________________________________________
>> Jscheme-user mailing list
>> Jsc...@li...
>> https://lists.sourceforge.net/lists/listinfo/jscheme-user
>>
>

Re: [Jscheme-user] Compiled Macros

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

In DrScheme, when you select another "language," it seems to forget any 
acquired language features and revert to a base level of functionality 
before loading on the new functionality.

On Thursday, September 5, 2002, at 09:45 AM, Ken Anderson wrote:

> I'm not opposed to a module approach, but what happens in Common Lisp 
> is that macros become part of the compiler's environment.  So when the 
> compiler compiles something it uses all the macros its seen.
>
> At 08:51 AM 9/5/2002, Timothy Hickey wrote:
>
>> On second thought, Graham's example points out the need for modules!
>> In Dr. Scheme, one can specify a "language" when importing a module.
>> The language is a collection of macros.
>>
>> I'll take a closer look at how the jscheme compiler handles macros
>> and report back to this list.
>>
>> It would be nice to have someway of indicating in the program code
>> that the program should be compiled using some set of macros.
>> One easy way would be to add an "include" command that would simply
>> include the macro code in the source before compiling, e.g.
>>
>> ;; macro2a.scm
>> (include "macro1.scm")
>> (define-macro (myplus2 a b)
>>   `(+ ,a ,b))
>> (.println java.lang.System.out$ (myplus1 1 2))
>> (.println java.lang.System.out$ (myplus2 1 2))
>>
>> This is essentially the way the C handles shared type declarations,
>> by storing them in .h files which are then included whereever they 
>> are needed.
>>
>> What do you think??
>> ---Tim---
>>
>>
>>>> At 07:24 PM 9/4/2002, Graham Spencer wrote:
>>>>> Hello,
>>>>>
>>>>> I think I've found a bug in JScheme version 5.0.0. Given the 
>>>>> following two files:
>>>>>
>>>>> ;; macro1.scm
>>>>> (define-macro (myplus1 a b)
>>>>>   `(+ ,a ,b))
>>>>>
>>>>> ;; macro2.scm
>>>>> (load "macro1.scm")
>>>>> (define-macro (myplus2 a b)
>>>>>   `(+ ,a ,b))
>>>>> (.println java.lang.System.out$ (myplus1 1 2))
>>>>> (.println java.lang.System.out$ (myplus2 1 2))
>>>>>
>>>>> If I compile both files to .class files and then run jscheme.REPL:
>>>>>
>>>>> Jscheme 5.0 04/05/2002 http://jscheme.sourceforge.net
>>>>> > (load "macro2.scm")
>>>>> 3
>>>>> 3
>>>>> #t
>>>>> > (macro2.load)
>>>>> (+ 1 2)
>>>>> 3
>>>>> #null
>>>>>
>>>>> The (load "macro2.scm") works as expected, but in (macro2.load), 
>>>>> the macro defined in macro1.scm is expanded but not evaluated. In 
>>>>> general, I cannot get macros defined in one compiled .class file 
>>>>> to work in another file. Am I doing something wrong, or is this 
>>>>> really a bug?
>>>>>
>>>>> (My apologies if I should have posted this bug report somewhere 
>>>>> else.)
>>>>>
>>>>> Thanks for your help,
>>>>>
>>>>> --g
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This sf.net email is sponsored by: OSDN - Tired of that same old
>>>> cell phone?  Get a new here for FREE!
>>>> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>>>> _______________________________________________
>>>> Jscheme-user mailing list
>>>> Jsc...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/jscheme-user
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This sf.net email is sponsored by: OSDN - Tired of that same old
>>> cell phone?  Get a new here for FREE!
>>> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>>> _______________________________________________
>>> Jscheme-user mailing list
>>> Jsc...@li...
>>> https://lists.sourceforge.net/lists/listinfo/jscheme-user
>>
>>
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by: OSDN - Tired of that same old
>> cell phone?  Get a new here for FREE!
>> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>> _______________________________________________
>> Jscheme-user mailing list
>> Jsc...@li...
>> https://lists.sourceforge.net/lists/listinfo/jscheme-user
>>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Jscheme-user mailing list
> Jsc...@li...
> https://lists.sourceforge.net/lists/listinfo/jscheme-user
>
>
--
Geoffrey S. Knauth				http://knauth.org/gsk

Re: [Jscheme-user] Compiled Macros

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

I'm not opposed to a module approach, but what happens in Common Lisp is 
that macros become part of the compiler's environment.  So when the 
compiler compiles something it uses all the macros its seen.

At 08:51 AM 9/5/2002, Timothy Hickey wrote:

>On second thought, Graham's example points out the need for modules!
>In Dr. Scheme, one can specify a "language" when importing a module.
>The language is a collection of macros.
>
>I'll take a closer look at how the jscheme compiler handles macros
>and report back to this list.
>
>It would be nice to have someway of indicating in the program code
>that the program should be compiled using some set of macros.
>One easy way would be to add an "include" command that would simply
>include the macro code in the source before compiling, e.g.
>
>;; macro2a.scm
>(include "macro1.scm")
>(define-macro (myplus2 a b)
>   `(+ ,a ,b))
>(.println java.lang.System.out$ (myplus1 1 2))
>(.println java.lang.System.out$ (myplus2 1 2))
>
>This is essentially the way the C handles shared type declarations,
>by storing them in .h files which are then included whereever they are needed.
>
>What do you think??
>---Tim---
>
>
>>>At 07:24 PM 9/4/2002, Graham Spencer wrote:
>>>>Hello,
>>>>
>>>>I think I've found a bug in JScheme version 5.0.0. Given the following 
>>>>two files:
>>>>
>>>>;; macro1.scm
>>>>(define-macro (myplus1 a b)
>>>>   `(+ ,a ,b))
>>>>
>>>>;; macro2.scm
>>>>(load "macro1.scm")
>>>>(define-macro (myplus2 a b)
>>>>   `(+ ,a ,b))
>>>>(.println java.lang.System.out$ (myplus1 1 2))
>>>>(.println java.lang.System.out$ (myplus2 1 2))
>>>>
>>>>If I compile both files to .class files and then run jscheme.REPL:
>>>>
>>>>Jscheme 5.0 04/05/2002 http://jscheme.sourceforge.net
>>>> > (load "macro2.scm")
>>>>3
>>>>3
>>>>#t
>>>> > (macro2.load)
>>>>(+ 1 2)
>>>>3
>>>>#null
>>>>
>>>>The (load "macro2.scm") works as expected, but in (macro2.load), the 
>>>>macro defined in macro1.scm is expanded but not evaluated. In general, 
>>>>I cannot get macros defined in one compiled .class file to work in 
>>>>another file. Am I doing something wrong, or is this really a bug?
>>>>
>>>>(My apologies if I should have posted this bug report somewhere else.)
>>>>
>>>>Thanks for your help,
>>>>
>>>>--g
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This sf.net email is sponsored by: OSDN - Tired of that same old
>>>cell phone?  Get a new here for FREE!
>>>https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>>>_______________________________________________
>>>Jscheme-user mailing list
>>>Jsc...@li...
>>>https://lists.sourceforge.net/lists/listinfo/jscheme-user
>>
>>
>>
>>-------------------------------------------------------
>>This sf.net email is sponsored by: OSDN - Tired of that same old
>>cell phone?  Get a new here for FREE!
>>https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>>_______________________________________________
>>Jscheme-user mailing list
>>Jsc...@li...
>>https://lists.sourceforge.net/lists/listinfo/jscheme-user
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by: OSDN - Tired of that same old
>cell phone?  Get a new here for FREE!
>https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>_______________________________________________
>Jscheme-user mailing list
>Jsc...@li...
>https://lists.sourceforge.net/lists/listinfo/jscheme-user
>

[Jscheme-user] Compiled Macros

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

>>
On second thought, Graham's example points out the need for modules!
In Dr. Scheme, one can specify a "language" when importing a module.
The language is a collection of macros.

I'll take a closer look at how the jscheme compiler handles macros
and report back to this list.

It would be nice to have someway of indicating in the program code
that the program should be compiled using some set of macros.
One easy way would be to add an "include" command that would simply
include the macro code in the source before compiling, e.g.

;; macro2a.scm
(include "macro1.scm")
(define-macro (myplus2 a b)
   `(+ ,a ,b))
(.println java.lang.System.out$ (myplus1 1 2))
(.println java.lang.System.out$ (myplus2 1 2))

This is essentially the way the C handles shared type declarations,
by storing them in .h files which are then included whereever they are 
needed.

What do you think??
---Tim---


>> At 07:24 PM 9/4/2002, Graham Spencer wrote:
>>> Hello,
>>>
>>> I think I've found a bug in JScheme version 5.0.0. Given the 
>>> following two files:
>>>
>>> ;; macro1.scm
>>> (define-macro (myplus1 a b)
>>>   `(+ ,a ,b))
>>>
>>> ;; macro2.scm
>>> (load "macro1.scm")
>>> (define-macro (myplus2 a b)
>>>   `(+ ,a ,b))
>>> (.println java.lang.System.out$ (myplus1 1 2))
>>> (.println java.lang.System.out$ (myplus2 1 2))
>>>
>>> If I compile both files to .class files and then run jscheme.REPL:
>>>
>>> Jscheme 5.0 04/05/2002 http://jscheme.sourceforge.net
>>> > (load "macro2.scm")
>>> 3
>>> 3
>>> #t
>>> > (macro2.load)
>>> (+ 1 2)
>>> 3
>>> #null
>>>
>>> The (load "macro2.scm") works as expected, but in (macro2.load), the 
>>> macro defined in macro1.scm is expanded but not evaluated. In 
>>> general, I cannot get macros defined in one compiled .class file to 
>>> work in another file. Am I doing something wrong, or is this really a 
>>> bug?
>>>
>>> (My apologies if I should have posted this bug report somewhere else.)
>>>
>>> Thanks for your help,
>>>
>>> --g
>>>
>>
>>
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by: OSDN - Tired of that same old
>> cell phone?  Get a new here for FREE!
>> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>> _______________________________________________
>> Jscheme-user mailing list
>> Jsc...@li...
>> https://lists.sourceforge.net/lists/listinfo/jscheme-user
>>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Jscheme-user mailing list
> Jsc...@li...
> https://lists.sourceforge.net/lists/listinfo/jscheme-user
>

Re: [Jscheme-user] Re: jscheme question

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

On Wednesday, September 4, 2002, at 09:23 PM, Ken Anderson wrote:
> I think Tim can answer this.

Hmmmm. This is a bug in the sense that the compiled and interpreted 
versions
of the code behave differently. However.... I think it is somewhat 
subtle.
The problem arises because the compiler assumes that the only macros it
must use to compile the program are the ones that appear in the program
itself.

I think what you want is some way of specifying that a program (say 
test.scm)
should be compiled using some specified set of macros (e.g. those in 
macro1.scm).
We could modify the compiler to do this, e.g. add a -macro switch,

    % java jsint.Compile -v -macro mymacro1.scm  test.scm

and this would be equivalent to adding all macros in mymacro1.scm to the 
beginning
of the test.scm file.

Does this seem like a reasonable solution to the problem?

---Tim---


>
> At 07:24 PM 9/4/2002, Graham Spencer wrote:
>> Hello,
>>
>> I think I've found a bug in JScheme version 5.0.0. Given the following 
>> two files:
>>
>> ;; macro1.scm
>> (define-macro (myplus1 a b)
>>   `(+ ,a ,b))
>>
>> ;; macro2.scm
>> (load "macro1.scm")
>> (define-macro (myplus2 a b)
>>   `(+ ,a ,b))
>> (.println java.lang.System.out$ (myplus1 1 2))
>> (.println java.lang.System.out$ (myplus2 1 2))
>>
>> If I compile both files to .class files and then run jscheme.REPL:
>>
>> Jscheme 5.0 04/05/2002 http://jscheme.sourceforge.net
>> > (load "macro2.scm")
>> 3
>> 3
>> #t
>> > (macro2.load)
>> (+ 1 2)
>> 3
>> #null
>>
>> The (load "macro2.scm") works as expected, but in (macro2.load), the 
>> macro defined in macro1.scm is expanded but not evaluated. In general, 
>> I cannot get macros defined in one compiled .class file to work in 
>> another file. Am I doing something wrong, or is this really a bug?
>>
>> (My apologies if I should have posted this bug report somewhere else.)
>>
>> Thanks for your help,
>>
>> --g
>>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Jscheme-user mailing list
> Jsc...@li...
> https://lists.sourceforge.net/lists/listinfo/jscheme-user
>

[Jscheme-user] Re: jscheme question

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

I think Tim can answer this.

At 07:24 PM 9/4/2002, Graham Spencer wrote:
>Hello,
>
>I think I've found a bug in JScheme version 5.0.0. Given the following two 
>files:
>
>;; macro1.scm
>(define-macro (myplus1 a b)
>   `(+ ,a ,b))
>
>;; macro2.scm
>(load "macro1.scm")
>(define-macro (myplus2 a b)
>   `(+ ,a ,b))
>(.println java.lang.System.out$ (myplus1 1 2))
>(.println java.lang.System.out$ (myplus2 1 2))
>
>If I compile both files to .class files and then run jscheme.REPL:
>
>Jscheme 5.0 04/05/2002 http://jscheme.sourceforge.net
> > (load "macro2.scm")
>3
>3
>#t
> > (macro2.load)
>(+ 1 2)
>3
>#null
>
>The (load "macro2.scm") works as expected, but in (macro2.load), the macro 
>defined in macro1.scm is expanded but not evaluated. In general, I cannot 
>get macros defined in one compiled .class file to work in another file. Am 
>I doing something wrong, or is this really a bug?
>
>(My apologies if I should have posted this bug report somewhere else.)
>
>Thanks for your help,
>
>--g
>

Re: [Jscheme-user] How do you build SchemeInvocationHandler?

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

Actually, my first reply was in error.
If in the jscheme directory you do

src/build/bootstrap

(or src\build\bootstrap)

you should get the elf\*.java classes compiled.

This will not work if you are using a Java older than JDK 1.2.
Let me know if you're still having problems.

k

At 04:45 PM 9/3/2002, John Raley wrote:
>Hi,
>
>I don't see how to build SchemeInvocationHandler
>(other than by hand).  Am I missing something in the
>doc, or is that the only way?
>
>Thanks.
>
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Finance - Get real-time stock quotes
>http://finance.yahoo.com
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by: OSDN - Tired of that same old
>cell phone?  Get a new here for FREE!
>https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>_______________________________________________
>Jscheme-user mailing list
>Jsc...@li...
>https://lists.sourceforge.net/lists/listinfo/jscheme-user

Re: [Jscheme-user] How do you build SchemeInvocationHandler?

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

Unfortunately, yes.
I think there used to be a message when you compiled that certain classes 
had to be compiled by hand.  SchemeInvocationHandler was not compiled 
because it is JDK 1.2+ specific, and we still support ancient Java 
environments.

I'll add some code to compile these classes specially.

For now, compile them, form the jscheme directory, with:
javac -classpath src src/elf/SchemeInvocationHandler.java

If you run the bootstrap again it will include the .class file in the jar.
k

At 04:45 PM 9/3/2002, John Raley wrote:
>Hi,
>
>I don't see how to build SchemeInvocationHandler
>(other than by hand).  Am I missing something in the
>doc, or is that the only way?
>
>Thanks.
>
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Finance - Get real-time stock quotes
>http://finance.yahoo.com
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by: OSDN - Tired of that same old
>cell phone?  Get a new here for FREE!
>https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>_______________________________________________
>Jscheme-user mailing list
>Jsc...@li...
>https://lists.sourceforge.net/lists/listinfo/jscheme-user

[Jscheme-user] How do you build SchemeInvocationHandler?

[John R. <jb_...@ya...>]

Hi,

I don't see how to build SchemeInvocationHandler
(other than by hand).  Am I missing something in the
doc, or is that the only way?

Thanks.


__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com

[Jscheme-user] Rick Hightower scripting articles.

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

Here are 5 articles on scripting in Java by Rick Hightower:

http://www.biztool.com/magazines/java/archives/servlet.pdf p 80-88
http://www.biztool.com/magazines/java/archives/jmfsecrets.pdf p 54-70
http://www.biztool.com/magazines/java/archives/bizrules.pdf p 82-88
http://www.sys-con.com/java/article.cfm?id=881
http://www.biztool.com/magazines/java/archives/0506/hightower/

Maybe we can get him to write one about Jscheme.

Re: [Jscheme-user] reading numbers?

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

On Thursday, August 8, 2002, at 06:13 PM, Ken Anderson wrote:

> Why does this
> > 0208030030
> 2.0803003E8
> get read as a Double?
The initial 0 signals an octal number
(so 010 would read as 8 as in Java)
However, the presence of an 8 indicates an error and the
reader tries to read it as a double instead.

We should probably just have the reader
throw an error in this case....
>
> While this:
> > 208030030
> 208030030
> gets read as a Integer.
>
> And this:
> > 20803003000
> 20803003000L
> is read as a long?
Whole numbers are read as longs and if the are in the range of an
integer converted back into integers. This can be overridden using an
L suffix if you want a small number to be a long.

>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Jscheme-user mailing list
> Jsc...@li...
> https://lists.sourceforge.net/lists/listinfo/jscheme-user
>

Re: [Jscheme-user] stack overflow in {}

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

Wow!
In fact, if you do M-x toggle-truncate-lines to toggle back and forth, you 
can save time printing huge lists, and actually see them if you want too.

Thanks!
k
At 11:28 PM 8/18/2002, Geoffrey S.Knauth wrote:
>Ken,
>
>Adding elf/basic.scm to my command line solved my problem.  Now, back to 
>your original question.  I found with Emacs 20.x, the following Emacs Lisp 
>(vs. Scheme) command helped a great deal:
>
>         (setq truncate-lines t)
>
>With Emacs 21.x, the above command also helped, but less so.  With Emacs 
>20.x, the output line for (t2 100000) grows to 80 chars and then $ appears 
>on the right, and the function finishes quickly.  With Emacs 21.x, a 
>right-arrow replaces the $ and the cursor tried to follow the numbers 
>being output so I had to type C-p (previous-line) to position the cursor 
>on the line above the output line so it wouldn't follow all the output.
>
>----------------------------------------------------------------------
>GNU Emacs 20.7.1, powerpc-apple-darwin, 1GB RAM
>
>(t1 100000)
>14.214 sec
>
>(t2 100000)
>163.919 sec
>
>[Emacs] M-: (setq truncate-lines t) RET
>
>(t2 100000)
>5.891 sec
>
>----------------------------------------------------------------------
>GNU Emacs 21.2.1, i386-redhat-linux-gnu, 1GB RAM
>
>(t1 100000)
>8.092 sec
>
>(t2 100000)
>395.059 sec
>
>[Emacs] M-: (setq truncate-lines t) RET
>
>(t2 100000)
>65.534 sec
>
>Geoffrey
>
>On Sunday, August 18, 2002, at 03:37 PM, Ken Anderson wrote:
>
>>Try
>>java -classpath ~/test/JScheme/jscheme/lib/jscheme.jar jschem.REPL 
>>elf/basic.scm
>>
>>This is the standard environment i start with, which provides print, 
>>describe, inspect and other things.  Perhaps we should standardize on a 
>>richer set of things to start with, but we've been concerned about 
>>startup time.
>>
>>At least, i should have provided what i loaded with the code i sent.
>>
>>k
>>At 12:47 AM 8/18/2002, Geoffrey S.Knauth wrote:
>>>I tried this but `print' came up undefined.  I see it is in 
>>>primitives.scm.  What did I forget to load?  I invoked JScheme like this:
>>>
>>>         java -classpath ~/test/JScheme/jscheme/lib/jscheme.jar jscheme.REPL
>>>
>>>Thanks,
>>>Geoffrey
>>>
>>>On Tuesday, August 13, 2002, at 12:20 PM, Ken Anderson wrote:
>>>
>>>>The problem is not with the number of lines, but with displaying a 
>>>>single line.  This code shows the problem:
>>>>
>>>>(define (gen n)
>>>>   (let loop ((n n)
>>>>              (sofar '()))
>>>>     (if (= n 0) sofar
>>>>         (loop (- n 1) (cons n sofar)))))
>>>>
>>>>;;; Xemacs 21.4  Gnu Emacs 20.7.1
>>>>(define (t1 n)                            ; 13 sec        51 sec
>>>>   (time (begin (for-each print (gen n)) #t) 1))
>>>>
>>>>                                         ; 152 sec      120 sec cursor 
>>>> at bottom
>>>>(define (t2 n)                          ;   2 sec       98 sec cursor 
>>>>at top
>>>>     (time (begin (print (gen n)) #t) 1))
>>>>
>>>>{
>>>>Xemacs 21.4
>>>>t1:
>>>>n      #chars  time(sec)
>>>>25000   138894  3.445    time = n/10000 + 0.245
>>>>50000   288894  6.579
>>>>100000  588895  12.978
>>>>
>>>>t2:
>>>>25000   138895  9.294    time = 2e-08n^2 + 0.0001n + 1.8
>>>>50000   288895  37.143
>>>>100000  588896  153.862
>>>>
>>>>Gnu Emacs 20.7.1
>>>>
>>>>25000   138894  11.126   time = 4*n/10000
>>>>50000   288894  18.918
>>>>100000  588895  42.202
>>>>
>>>>25000   138895  11.857   time = 7e-09n^2 0.0005x - 6
>>>>50000   288895  38.482
>>>>100000  588896  118.050
>>>>
>>>>If you run (t1), it prints 100,000 integers to the screen in about 13 
>>>>seconds.
>>>>If you do (t2) it takes 2 minutes to print the list of 100,000 
>>>>integers, 588,896 characters long.
>>>>
>>>>The problem is formatting the output with the cursor at the bottom of 
>>>>the buffer.  If you move the cursor to the top of the buffer before 
>>>>printing is much faster in Xemacs and a little faster in Gnu EMACS.
>>>>
>>>>While the printing is happening, XEMACS is completely unresponsive, 
>>>>while Gnu EMACS is fairly responsive.
>>>>
>>>>So a million character list takes about 8 minutes to display, and an 8 
>>>>million character list takes almost 9 hours.  So i try not to print them.
>>>>At 04:32 AM 8/13/2002, Geoffrey S.Knauth wrote:
>>>>>I'm very surprised to hear that Emacs had a memory problem holding all 
>>>>>this output, since in Emacs terms, 35,000 is still a relatively small 
>>>>>number.  I've used Emacs to examine files that were hundreds of 
>>>>>megabytes in size.  Ten years ago, however, there was an 8MB limit.
>>>>>
>>>>>I wonder if the Emacs behavior you saw, not being able to hold all the 
>>>>>output, was a side effect of the Emacs mode you were in.  You wrote 
>>>>>that you didn't have line breaks.  Perhaps you were in a mode that 
>>>>>looked for line breaks in order to do font/color customization, and 
>>>>>the mode lost its way.
>>>>>
>>>>>Just out of curiosity, try M-x text-mode or fundamental-mode on your 
>>>>>output buffer before generating huge output, just to see if that keeps 
>>>>>Emacs from boiling over.  Also, see if you are using a relatively 
>>>>>recent Emacs (M-x emacs-version).
>>>>>
>>>>>Geoffrey
>>>>>
>>>>>On Monday, August 12, 2002, at 08:58 PM, Ken Anderson wrote:
>>>>>
>>>>>>Rusty an i have been data mining with lists of 35,000 items.
>>>>>>Things work reasonably OK as long as you don't print them as a list 
>>>>>>to EMACS without any line breaks.  I usually kill my Jscheme at that 
>>>>>>point and start over.
>>>>>>
>>>>>>I've truncated error messages to 1000 characters which helps a lot 
>>>>>>with reporting bugs.  Perhaps we should have parameter that effects 
>>>>>>the REPL, to help reduce the cost of accidents.  Common Lisp had 
>>>>>>several, such as print-length and print-level, but one might work for 
>>>>>>us, were small.
>>>>>>
>>>>>>We have one example of using {} to generate a web page, with at least 
>>>>>>a 1300 row x 5 columns x 3 string
>>>>>> > 19,500 Jscheme frames - leads to a stack overflow.  This seems 
>>>>>> pretty tiny, but
>>>>>>the simple experiement:
>>>>>>(define (grow n)
>>>>>>   (if (= n 0) '()
>>>>>>       (cons n (grow (- n 1)))))
>>>>>>(define (size n)
>>>>>>   (print n)
>>>>>>   (grow n)
>>>>>>   (size (+ n n)))
>>>>>>(size 1)
>>>>>>
>>>>>>produces:
>>>>>> > 1
>>>>>>2
>>>>>>4
>>>>>>8
>>>>>>16
>>>>>>32
>>>>>>64
>>>>>>128
>>>>>>256
>>>>>>512
>>>>>>1024
>>>>>>2048
>>>>>>An unrecoverable stack overflow has occurred.
>>>>>>
>>>>>>We were able to rewrite the page in a dumb string-consing accumulator 
>>>>>>style and get the result we wanted.
>>>>>>
>>>>>>Is there an alternative way we can write !{}?
>>>>>>
>>>>>>k
>>>>>>
>>>>>>
>>>>>>
>>>>>>-------------------------------------------------------
>>>>>>This sf.net email is sponsored by: Dice - The leading online job board
>>>>>>for high-tech professionals. Search and apply for tech jobs today!
>>>>>>http://seeker.dice.com/seeker.epl?rel_code=31
>>>>>>_______________________________________________
>>>>>>Jscheme-user mailing list
>>>>>>Jsc...@li...
>>>>>>https://lists.sourceforge.net/lists/listinfo/jscheme-user
>>>--
>>>Geoffrey S. Knauth                              http://knauth.org/gsk
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This sf.net email is sponsored by: OSDN - Tired of that same old
>>>cell phone?  Get a new here for FREE!
>>>https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>>>_______________________________________________
>>>Jscheme-user mailing list
>>>Jsc...@li...
>>>https://lists.sourceforge.net/lists/listinfo/jscheme-user
>>
>--
>Geoffrey S. Knauth                              http://knauth.org/gsk
>

Re: [Jscheme-user] stack overflow in {}

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

Ken,

Adding elf/basic.scm to my command line solved my problem.  Now, back to 
your original question.  I found with Emacs 20.x, the following Emacs 
Lisp (vs. Scheme) command helped a great deal:

	(setq truncate-lines t)

With Emacs 21.x, the above command also helped, but less so.  With Emacs 
20.x, the output line for (t2 100000) grows to 80 chars and then $ 
appears on the right, and the function finishes quickly.  With Emacs 
21.x, a right-arrow replaces the $ and the cursor tried to follow the 
numbers being output so I had to type C-p (previous-line) to position 
the cursor on the line above the output line so it wouldn't follow all 
the output.

----------------------------------------------------------------------
GNU Emacs 20.7.1, powerpc-apple-darwin, 1GB RAM

(t1 100000)
14.214 sec

(t2 100000)
163.919 sec

[Emacs] M-: (setq truncate-lines t) RET

(t2 100000)
5.891 sec

----------------------------------------------------------------------
GNU Emacs 21.2.1, i386-redhat-linux-gnu, 1GB RAM

(t1 100000)
8.092 sec

(t2 100000)
395.059 sec

[Emacs] M-: (setq truncate-lines t) RET

(t2 100000)
65.534 sec

Geoffrey

On Sunday, August 18, 2002, at 03:37 PM, Ken Anderson wrote:

> Try
> java -classpath ~/test/JScheme/jscheme/lib/jscheme.jar jschem.REPL 
> elf/basic.scm
>
> This is the standard environment i start with, which provides print, 
> describe, inspect and other things.  Perhaps we should standardize on a 
> richer set of things to start with, but we've been concerned about 
> startup time.
>
> At least, i should have provided what i loaded with the code i sent.
>
> k
> At 12:47 AM 8/18/2002, Geoffrey S.Knauth wrote:
>> I tried this but `print' came up undefined.  I see it is in 
>> primitives.scm.  What did I forget to load?  I invoked JScheme like 
>> this:
>>
>>         java -classpath ~/test/JScheme/jscheme/lib/jscheme.jar 
>> jscheme.REPL
>>
>> Thanks,
>> Geoffrey
>>
>> On Tuesday, August 13, 2002, at 12:20 PM, Ken Anderson wrote:
>>
>>> The problem is not with the number of lines, but with displaying a 
>>> single line.  This code shows the problem:
>>>
>>> (define (gen n)
>>>   (let loop ((n n)
>>>              (sofar '()))
>>>     (if (= n 0) sofar
>>>         (loop (- n 1) (cons n sofar)))))
>>>
>>> ;;; Xemacs 21.4  Gnu Emacs 20.7.1
>>> (define (t1 n)                            ; 13 sec        51 sec
>>>   (time (begin (for-each print (gen n)) #t) 1))
>>>
>>>                                         ; 152 sec      120 sec cursor 
>>> at bottom
>>> (define (t2 n)                          ;   2 sec       98 sec cursor 
>>> at top
>>>     (time (begin (print (gen n)) #t) 1))
>>>
>>> {
>>> Xemacs 21.4
>>> t1:
>>> n      #chars  time(sec)
>>> 25000   138894  3.445    time = n/10000 + 0.245
>>> 50000   288894  6.579
>>> 100000  588895  12.978
>>>
>>> t2:
>>> 25000   138895  9.294    time = 2e-08n^2 + 0.0001n + 1.8
>>> 50000   288895  37.143
>>> 100000  588896  153.862
>>>
>>> Gnu Emacs 20.7.1
>>>
>>> 25000   138894  11.126   time = 4*n/10000
>>> 50000   288894  18.918
>>> 100000  588895  42.202
>>>
>>> 25000   138895  11.857   time = 7e-09n^2 0.0005x - 6
>>> 50000   288895  38.482
>>> 100000  588896  118.050
>>>
>>> If you run (t1), it prints 100,000 integers to the screen in about 13 
>>> seconds.
>>> If you do (t2) it takes 2 minutes to print the list of 100,000 
>>> integers, 588,896 characters long.
>>>
>>> The problem is formatting the output with the cursor at the bottom of 
>>> the buffer.  If you move the cursor to the top of the buffer before 
>>> printing is much faster in Xemacs and a little faster in Gnu EMACS.
>>>
>>> While the printing is happening, XEMACS is completely unresponsive, 
>>> while Gnu EMACS is fairly responsive.
>>>
>>> So a million character list takes about 8 minutes to display, and an 
>>> 8 million character list takes almost 9 hours.  So i try not to print 
>>> them.
>>> At 04:32 AM 8/13/2002, Geoffrey S.Knauth wrote:
>>>> I'm very surprised to hear that Emacs had a memory problem holding 
>>>> all this output, since in Emacs terms, 35,000 is still a relatively 
>>>> small number.  I've used Emacs to examine files that were hundreds 
>>>> of megabytes in size.  Ten years ago, however, there was an 8MB 
>>>> limit.
>>>>
>>>> I wonder if the Emacs behavior you saw, not being able to hold all 
>>>> the output, was a side effect of the Emacs mode you were in.  You 
>>>> wrote that you didn't have line breaks.  Perhaps you were in a mode 
>>>> that looked for line breaks in order to do font/color customization, 
>>>> and the mode lost its way.
>>>>
>>>> Just out of curiosity, try M-x text-mode or fundamental-mode on your 
>>>> output buffer before generating huge output, just to see if that 
>>>> keeps Emacs from boiling over.  Also, see if you are using a 
>>>> relatively recent Emacs (M-x emacs-version).
>>>>
>>>> Geoffrey
>>>>
>>>> On Monday, August 12, 2002, at 08:58 PM, Ken Anderson wrote:
>>>>
>>>>> Rusty an i have been data mining with lists of 35,000 items.
>>>>> Things work reasonably OK as long as you don't print them as a list 
>>>>> to EMACS without any line breaks.  I usually kill my Jscheme at 
>>>>> that point and start over.
>>>>>
>>>>> I've truncated error messages to 1000 characters which helps a lot 
>>>>> with reporting bugs.  Perhaps we should have parameter that effects 
>>>>> the REPL, to help reduce the cost of accidents.  Common Lisp had 
>>>>> several, such as print-length and print-level, but one might work 
>>>>> for us, were small.
>>>>>
>>>>> We have one example of using {} to generate a web page, with at 
>>>>> least a 1300 row x 5 columns x 3 string
>>>>> > 19,500 Jscheme frames - leads to a stack overflow.  This seems 
>>>>> pretty tiny, but
>>>>> the simple experiement:
>>>>> (define (grow n)
>>>>>   (if (= n 0) '()
>>>>>       (cons n (grow (- n 1)))))
>>>>> (define (size n)
>>>>>   (print n)
>>>>>   (grow n)
>>>>>   (size (+ n n)))
>>>>> (size 1)
>>>>>
>>>>> produces:
>>>>> > 1
>>>>> 2
>>>>> 4
>>>>> 8
>>>>> 16
>>>>> 32
>>>>> 64
>>>>> 128
>>>>> 256
>>>>> 512
>>>>> 1024
>>>>> 2048
>>>>> An unrecoverable stack overflow has occurred.
>>>>>
>>>>> We were able to rewrite the page in a dumb string-consing 
>>>>> accumulator style and get the result we wanted.
>>>>>
>>>>> Is there an alternative way we can write !{}?
>>>>>
>>>>> k
>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------------
>>>>> This sf.net email is sponsored by: Dice - The leading online job 
>>>>> board
>>>>> for high-tech professionals. Search and apply for tech jobs today!
>>>>> http://seeker.dice.com/seeker.epl?rel_code=31
>>>>> _______________________________________________
>>>>> Jscheme-user mailing list
>>>>> Jsc...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/jscheme-user
>>>
>> --
>> Geoffrey S. Knauth                              http://knauth.org/gsk
>>
>>
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by: OSDN - Tired of that same old
>> cell phone?  Get a new here for FREE!
>> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>> _______________________________________________
>> Jscheme-user mailing list
>> Jsc...@li...
>> https://lists.sourceforge.net/lists/listinfo/jscheme-user
>>
>
>
--
Geoffrey S. Knauth				http://knauth.org/gsk

Re: [Jscheme-user] stack overflow in {}

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

Try
java -classpath ~/test/JScheme/jscheme/lib/jscheme.jar jschem.REPL 
elf/basic.scm

This is the standard environment i start with, which provides print, 
describe, inspect and other things.  Perhaps we should standardize on a 
richer set of things to start with, but we've been concerned about startup 
time.

At least, i should have provided what i loaded with the code i sent.

k
At 12:47 AM 8/18/2002, Geoffrey S.Knauth wrote:
>I tried this but `print' came up undefined.  I see it is in 
>primitives.scm.  What did I forget to load?  I invoked JScheme like this:
>
>         java -classpath ~/test/JScheme/jscheme/lib/jscheme.jar jscheme.REPL
>
>Thanks,
>Geoffrey
>
>On Tuesday, August 13, 2002, at 12:20 PM, Ken Anderson wrote:
>
>>The problem is not with the number of lines, but with displaying a single 
>>line.  This code shows the problem:
>>
>>(define (gen n)
>>   (let loop ((n n)
>>              (sofar '()))
>>     (if (= n 0) sofar
>>         (loop (- n 1) (cons n sofar)))))
>>
>>;;; Xemacs 21.4  Gnu Emacs 20.7.1
>>(define (t1 n)                            ; 13 sec        51 sec
>>   (time (begin (for-each print (gen n)) #t) 1))
>>
>>                                         ; 152 sec      120 sec cursor at 
>> bottom
>>(define (t2 n)                          ;   2 sec       98 sec cursor at top
>>     (time (begin (print (gen n)) #t) 1))
>>
>>{
>>Xemacs 21.4
>>t1:
>>n      #chars  time(sec)
>>25000   138894  3.445    time = n/10000 + 0.245
>>50000   288894  6.579
>>100000  588895  12.978
>>
>>t2:
>>25000   138895  9.294    time = 2e-08n^2 + 0.0001n + 1.8
>>50000   288895  37.143
>>100000  588896  153.862
>>
>>Gnu Emacs 20.7.1
>>
>>25000   138894  11.126   time = 4*n/10000
>>50000   288894  18.918
>>100000  588895  42.202
>>
>>25000   138895  11.857   time = 7e-09n^2 0.0005x - 6
>>50000   288895  38.482
>>100000  588896  118.050
>>
>>If you run (t1), it prints 100,000 integers to the screen in about 13 
>>seconds.
>>If you do (t2) it takes 2 minutes to print the list of 100,000 integers, 
>>588,896 characters long.
>>
>>The problem is formatting the output with the cursor at the bottom of the 
>>buffer.  If you move the cursor to the top of the buffer before printing 
>>is much faster in Xemacs and a little faster in Gnu EMACS.
>>
>>While the printing is happening, XEMACS is completely unresponsive, while 
>>Gnu EMACS is fairly responsive.
>>
>>So a million character list takes about 8 minutes to display, and an 8 
>>million character list takes almost 9 hours.  So i try not to print them.
>>At 04:32 AM 8/13/2002, Geoffrey S.Knauth wrote:
>>>I'm very surprised to hear that Emacs had a memory problem holding all 
>>>this output, since in Emacs terms, 35,000 is still a relatively small 
>>>number.  I've used Emacs to examine files that were hundreds of 
>>>megabytes in size.  Ten years ago, however, there was an 8MB limit.
>>>
>>>I wonder if the Emacs behavior you saw, not being able to hold all the 
>>>output, was a side effect of the Emacs mode you were in.  You wrote that 
>>>you didn't have line breaks.  Perhaps you were in a mode that looked for 
>>>line breaks in order to do font/color customization, and the mode lost its way.
>>>
>>>Just out of curiosity, try M-x text-mode or fundamental-mode on your 
>>>output buffer before generating huge output, just to see if that keeps 
>>>Emacs from boiling over.  Also, see if you are using a relatively recent 
>>>Emacs (M-x emacs-version).
>>>
>>>Geoffrey
>>>
>>>On Monday, August 12, 2002, at 08:58 PM, Ken Anderson wrote:
>>>
>>>>Rusty an i have been data mining with lists of 35,000 items.
>>>>Things work reasonably OK as long as you don't print them as a list to 
>>>>EMACS without any line breaks.  I usually kill my Jscheme at that point 
>>>>and start over.
>>>>
>>>>I've truncated error messages to 1000 characters which helps a lot with 
>>>>reporting bugs.  Perhaps we should have parameter that effects the 
>>>>REPL, to help reduce the cost of accidents.  Common Lisp had several, 
>>>>such as print-length and print-level, but one might work for us, were small.
>>>>
>>>>We have one example of using {} to generate a web page, with at least a 
>>>>1300 row x 5 columns x 3 string
>>>> > 19,500 Jscheme frames - leads to a stack overflow.  This seems 
>>>> pretty tiny, but
>>>>the simple experiement:
>>>>(define (grow n)
>>>>   (if (= n 0) '()
>>>>       (cons n (grow (- n 1)))))
>>>>(define (size n)
>>>>   (print n)
>>>>   (grow n)
>>>>   (size (+ n n)))
>>>>(size 1)
>>>>
>>>>produces:
>>>> > 1
>>>>2
>>>>4
>>>>8
>>>>16
>>>>32
>>>>64
>>>>128
>>>>256
>>>>512
>>>>1024
>>>>2048
>>>>An unrecoverable stack overflow has occurred.
>>>>
>>>>We were able to rewrite the page in a dumb string-consing accumulator 
>>>>style and get the result we wanted.
>>>>
>>>>Is there an alternative way we can write !{}?
>>>>
>>>>k
>>>>
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>This sf.net email is sponsored by: Dice - The leading online job board
>>>>for high-tech professionals. Search and apply for tech jobs today!
>>>>http://seeker.dice.com/seeker.epl?rel_code=31
>>>>_______________________________________________
>>>>Jscheme-user mailing list
>>>>Jsc...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/jscheme-user
>>
>--
>Geoffrey S. Knauth                              http://knauth.org/gsk
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by: OSDN - Tired of that same old
>cell phone?  Get a new here for FREE!
>https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>_______________________________________________
>Jscheme-user mailing list
>Jsc...@li...
>https://lists.sourceforge.net/lists/listinfo/jscheme-user
>

Re: [Jscheme-user] stack overflow in {}

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

I tried this but `print' came up undefined.  I see it is in 
primitives.scm.  What did I forget to load?  I invoked JScheme like this:

	java -classpath ~/test/JScheme/jscheme/lib/jscheme.jar jscheme.REPL

Thanks,
Geoffrey

On Tuesday, August 13, 2002, at 12:20 PM, Ken Anderson wrote:

> The problem is not with the number of lines, but with displaying a 
> single line.  This code shows the problem:
>
> (define (gen n)
>   (let loop ((n n)
>              (sofar '()))
>     (if (= n 0) sofar
>         (loop (- n 1) (cons n sofar)))))
>
> ;;; Xemacs 21.4  Gnu Emacs 20.7.1
> (define (t1 n)                            ; 13 sec        51 sec
>   (time (begin (for-each print (gen n)) #t) 1))
>
>                                         ; 152 sec      120 sec cursor 
> at bottom
> (define (t2 n)                          ;   2 sec       98 sec cursor 
> at top
>     (time (begin (print (gen n)) #t) 1))
>
> {
> Xemacs 21.4
> t1:
> n      #chars  time(sec)
> 25000   138894  3.445    time = n/10000 + 0.245
> 50000   288894  6.579
> 100000  588895  12.978
>
> t2:
> 25000   138895  9.294    time = 2e-08n^2 + 0.0001n + 1.8
> 50000   288895  37.143
> 100000  588896  153.862
>
> Gnu Emacs 20.7.1
>
> 25000   138894  11.126   time = 4*n/10000
> 50000   288894  18.918
> 100000  588895  42.202
>
> 25000   138895  11.857   time = 7e-09n^2 0.0005x - 6
> 50000   288895  38.482
> 100000  588896  118.050
>
> If you run (t1), it prints 100,000 integers to the screen in about 13 
> seconds.
> If you do (t2) it takes 2 minutes to print the list of 100,000 
> integers, 588,896 characters long.
>
> The problem is formatting the output with the cursor at the bottom of 
> the buffer.  If you move the cursor to the top of the buffer before 
> printing is much faster in Xemacs and a little faster in Gnu EMACS.
>
> While the printing is happening, XEMACS is completely unresponsive, 
> while Gnu EMACS is fairly responsive.
>
> So a million character list takes about 8 minutes to display, and an 8 
> million character list takes almost 9 hours.  So i try not to print 
> them.
> At 04:32 AM 8/13/2002, Geoffrey S.Knauth wrote:
>> I'm very surprised to hear that Emacs had a memory problem holding all 
>> this output, since in Emacs terms, 35,000 is still a relatively small 
>> number.  I've used Emacs to examine files that were hundreds of 
>> megabytes in size.  Ten years ago, however, there was an 8MB limit.
>>
>> I wonder if the Emacs behavior you saw, not being able to hold all the 
>> output, was a side effect of the Emacs mode you were in.  You wrote 
>> that you didn't have line breaks.  Perhaps you were in a mode that 
>> looked for line breaks in order to do font/color customization, and 
>> the mode lost its way.
>>
>> Just out of curiosity, try M-x text-mode or fundamental-mode on your 
>> output buffer before generating huge output, just to see if that keeps 
>> Emacs from boiling over.  Also, see if you are using a relatively 
>> recent Emacs (M-x emacs-version).
>>
>> Geoffrey
>>
>> On Monday, August 12, 2002, at 08:58 PM, Ken Anderson wrote:
>>
>>> Rusty an i have been data mining with lists of 35,000 items.
>>> Things work reasonably OK as long as you don't print them as a list 
>>> to EMACS without any line breaks.  I usually kill my Jscheme at that 
>>> point and start over.
>>>
>>> I've truncated error messages to 1000 characters which helps a lot 
>>> with reporting bugs.  Perhaps we should have parameter that effects 
>>> the REPL, to help reduce the cost of accidents.  Common Lisp had 
>>> several, such as print-length and print-level, but one might work for 
>>> us, were small.
>>>
>>> We have one example of using {} to generate a web page, with at least 
>>> a 1300 row x 5 columns x 3 string
>>> > 19,500 Jscheme frames - leads to a stack overflow.  This seems 
>>> pretty tiny, but
>>> the simple experiement:
>>> (define (grow n)
>>>   (if (= n 0) '()
>>>       (cons n (grow (- n 1)))))
>>> (define (size n)
>>>   (print n)
>>>   (grow n)
>>>   (size (+ n n)))
>>> (size 1)
>>>
>>> produces:
>>> > 1
>>> 2
>>> 4
>>> 8
>>> 16
>>> 32
>>> 64
>>> 128
>>> 256
>>> 512
>>> 1024
>>> 2048
>>> An unrecoverable stack overflow has occurred.
>>>
>>> We were able to rewrite the page in a dumb string-consing accumulator 
>>> style and get the result we wanted.
>>>
>>> Is there an alternative way we can write !{}?
>>>
>>> k
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This sf.net email is sponsored by: Dice - The leading online job board
>>> for high-tech professionals. Search and apply for tech jobs today!
>>> http://seeker.dice.com/seeker.epl?rel_code=31
>>> _______________________________________________
>>> Jscheme-user mailing list
>>> Jsc...@li...
>>> https://lists.sourceforge.net/lists/listinfo/jscheme-user
>
>
--
Geoffrey S. Knauth				http://knauth.org/gsk

Re: [Jscheme-user] stack overflow in {}

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

The problem is not with the number of lines, but with displaying a single 
line.  This code shows the problem:

(define (gen n)
   (let loop ((n n)
              (sofar '()))
     (if (= n 0) sofar
         (loop (- n 1) (cons n sofar)))))

;;; Xemacs 21.4  Gnu Emacs 20.7.1
(define (t1 n)                            ; 13 sec        51 sec
   (time (begin (for-each print (gen n)) #t) 1))

                                         ; 152 sec      120 sec cursor at 
bottom
(define (t2 n)                          ;   2 sec       98 sec cursor at top
     (time (begin (print (gen n)) #t) 1))

{
Xemacs 21.4
t1:
n      #chars  time(sec)
25000   138894  3.445    time = n/10000 + 0.245
50000   288894  6.579
100000  588895  12.978

t2:
25000   138895  9.294    time = 2e-08n^2 + 0.0001n + 1.8
50000   288895  37.143
100000  588896  153.862

Gnu Emacs 20.7.1

25000   138894  11.126   time = 4*n/10000
50000   288894  18.918
100000  588895  42.202

25000   138895  11.857   time = 7e-09n^2 0.0005x - 6
50000   288895  38.482
100000  588896  118.050

If you run (t1), it prints 100,000 integers to the screen in about 13 seconds.
If you do (t2) it takes 2 minutes to print the list of 100,000 integers, 
588,896 characters long.

The problem is formatting the output with the cursor at the bottom of the 
buffer.  If you move the cursor to the top of the buffer before printing is 
much faster in Xemacs and a little faster in Gnu EMACS.

While the printing is happening, XEMACS is completely unresponsive, while 
Gnu EMACS is fairly responsive.

So a million character list takes about 8 minutes to display, and an 8 
million character list takes almost 9 hours.  So i try not to print them.
At 04:32 AM 8/13/2002, Geoffrey S.Knauth wrote:
>I'm very surprised to hear that Emacs had a memory problem holding all 
>this output, since in Emacs terms, 35,000 is still a relatively small 
>number.  I've used Emacs to examine files that were hundreds of megabytes 
>in size.  Ten years ago, however, there was an 8MB limit.
>
>I wonder if the Emacs behavior you saw, not being able to hold all the 
>output, was a side effect of the Emacs mode you were in.  You wrote that 
>you didn't have line breaks.  Perhaps you were in a mode that looked for 
>line breaks in order to do font/color customization, and the mode lost its way.
>
>Just out of curiosity, try M-x text-mode or fundamental-mode on your 
>output buffer before generating huge output, just to see if that keeps 
>Emacs from boiling over.  Also, see if you are using a relatively recent 
>Emacs (M-x emacs-version).
>
>Geoffrey
>
>On Monday, August 12, 2002, at 08:58 PM, Ken Anderson wrote:
>
>>Rusty an i have been data mining with lists of 35,000 items.
>>Things work reasonably OK as long as you don't print them as a list to 
>>EMACS without any line breaks.  I usually kill my Jscheme at that point 
>>and start over.
>>
>>I've truncated error messages to 1000 characters which helps a lot with 
>>reporting bugs.  Perhaps we should have parameter that effects the REPL, 
>>to help reduce the cost of accidents.  Common Lisp had several, such as 
>>print-length and print-level, but one might work for us, were small.
>>
>>We have one example of using {} to generate a web page, with at least a 
>>1300 row x 5 columns x 3 string
>> > 19,500 Jscheme frames - leads to a stack overflow.  This seems pretty 
>> tiny, but
>>the simple experiement:
>>(define (grow n)
>>   (if (= n 0) '()
>>       (cons n (grow (- n 1)))))
>>(define (size n)
>>   (print n)
>>   (grow n)
>>   (size (+ n n)))
>>(size 1)
>>
>>produces:
>> > 1
>>2
>>4
>>8
>>16
>>32
>>64
>>128
>>256
>>512
>>1024
>>2048
>>An unrecoverable stack overflow has occurred.
>>
>>We were able to rewrite the page in a dumb string-consing accumulator 
>>style and get the result we wanted.
>>
>>Is there an alternative way we can write !{}?
>>
>>k
>>
>>
>>
>>-------------------------------------------------------
>>This sf.net email is sponsored by: Dice - The leading online job board
>>for high-tech professionals. Search and apply for tech jobs today!
>>http://seeker.dice.com/seeker.epl?rel_code=31
>>_______________________________________________
>>Jscheme-user mailing list
>>Jsc...@li...
>>https://lists.sourceforge.net/lists/listinfo/jscheme-user

Re: [Jscheme-user] stack overflow in {}

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

I'm very surprised to hear that Emacs had a memory problem holding all 
this output, since in Emacs terms, 35,000 is still a relatively small 
number.  I've used Emacs to examine files that were hundreds of 
megabytes in size.  Ten years ago, however, there was an 8MB limit.

I wonder if the Emacs behavior you saw, not being able to hold all the 
output, was a side effect of the Emacs mode you were in.  You wrote that 
you didn't have line breaks.  Perhaps you were in a mode that looked for 
line breaks in order to do font/color customization, and the mode lost 
its way.

Just out of curiosity, try M-x text-mode or fundamental-mode on your 
output buffer before generating huge output, just to see if that keeps 
Emacs from boiling over.  Also, see if you are using a relatively recent 
Emacs (M-x emacs-version).

Geoffrey

On Monday, August 12, 2002, at 08:58 PM, Ken Anderson wrote:

> Rusty an i have been data mining with lists of 35,000 items.
> Things work reasonably OK as long as you don't print them as a list to 
> EMACS without any line breaks.  I usually kill my Jscheme at that point 
> and start over.
>
> I've truncated error messages to 1000 characters which helps a lot with 
> reporting bugs.  Perhaps we should have parameter that effects the 
> REPL, to help reduce the cost of accidents.  Common Lisp had several, 
> such as print-length and print-level, but one might work for us, were 
> small.
>
> We have one example of using {} to generate a web page, with at least a 
> 1300 row x 5 columns x 3 string
> > 19,500 Jscheme frames - leads to a stack overflow.  This seems pretty 
> tiny, but
> the simple experiement:
> (define (grow n)
>   (if (= n 0) '()
>       (cons n (grow (- n 1)))))
> (define (size n)
>   (print n)
>   (grow n)
>   (size (+ n n)))
> (size 1)
>
> produces:
> > 1
> 2
> 4
> 8
> 16
> 32
> 64
> 128
> 256
> 512
> 1024
> 2048
> An unrecoverable stack overflow has occurred.
>
> We were able to rewrite the page in a dumb string-consing accumulator 
> style and get the result we wanted.
>
> Is there an alternative way we can write !{}?
>
> k
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Dice - The leading online job board
> for high-tech professionals. Search and apply for tech jobs today!
> http://seeker.dice.com/seeker.epl?rel_code=31
> _______________________________________________
> Jscheme-user mailing list
> Jsc...@li...
> https://lists.sourceforge.net/lists/listinfo/jscheme-user
>

[Jscheme-user] stack overflow in {}

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

Rusty an i have been data mining with lists of 35,000 items.
Things work reasonably OK as long as you don't print them as a list to 
EMACS without any line breaks.  I usually kill my Jscheme at that point and 
start over.

I've truncated error messages to 1000 characters which helps a lot with 
reporting bugs.  Perhaps we should have parameter that effects the REPL, to 
help reduce the cost of accidents.  Common Lisp had several, such as 
print-length and print-level, but one might work for us, were small.

We have one example of using {} to generate a web page, with at least a 
1300 row x 5 columns x 3 string
 > 19,500 Jscheme frames - leads to a stack overflow.  This seems pretty 
tiny, but
the simple experiement:
(define (grow n)
   (if (= n 0) '()
       (cons n (grow (- n 1)))))
(define (size n)
   (print n)
   (grow n)
   (size (+ n n)))
(size 1)

produces:
 > 1
2
4
8
16
32
64
128
256
512
1024
2048
An unrecoverable stack overflow has occurred.

We were able to rewrite the page in a dumb string-consing accumulator style 
and get the result we wanted.

Is there an alternative way we can write !{}?

k

[Jscheme-user] reading numbers?

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

Why does this
 > 0208030030
2.0803003E8
get read as a Double?

While this:
 > 208030030
208030030
gets read as a Integer.

And this:
 > 20803003000
20803003000L
is read as a long?