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