Menu
▾
▴
jscheme-user
|
From: Ken A. <kan...@bb...> - 2002-08-13 00:59:08
|
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
|
|
From: Geoffrey S.K. <ge...@kn...> - 2002-08-13 08:32:06
|
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
>
|
|
From: Ken A. <kan...@bb...> - 2002-08-13 16:21:26
|
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
|
|
From: Geoffrey S.K. <ge...@kn...> - 2002-08-18 04:48:13
|
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
|
|
From: Ken A. <kan...@bb...> - 2002-08-18 19:40:14
|
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
>
|
|
From: Geoffrey S.K. <ge...@kn...> - 2002-08-19 03:28:54
|
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
|
|
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
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X