Menu
▾
▴
Re: [Jscheme-user] stack overflow in {}
|
From: Ken A. <kan...@bb...> - 2002-08-19 13:12:27
|
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
>
|
