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