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
>