Custom Query (1030 matches)

? (time (print (make-string 10000)))
""
(PRINT (MAKE-STRING 10000)) took 11,157,608 microseconds (11.157608 seconds) to run 
                    with 2 available CPU cores.
During that period, 10,291,164 microseconds (10.291164 seconds) were spent in user mode
                    868,038 microseconds (0.868038 seconds) were spent in system mode
70,577 microseconds (0.070577 seconds) was spent in GC.
 97,616 bytes of memory allocated.
 120 minor page faults, 12,281 major page faults, 0 swaps.
""

Note that the above was run with string highlighting disabled. When it's enabled, things get even slower. (See ticket #540.)

It would also be nice (and would be a resolution of this ticket as far as I'm concerned) to have something like *print-length* that applied to strings. I'm doing some database work that involves very long strings (megabytes) and it would be very nice not to have to manually kill the printing process whenever I accidentally print one of these monsters.

I'm calling this a "minor enhancement" because I can work around it myself by defining a print-object method on strings.

Reported by <p2.edoc@…> in openmcl-devel on 9 Jun 2014, but it bothers me too so I'm reporting it. Printing long sexprs to the listener in the IDE is a denial-of-service attack.

Setting variables like *print-length* or hitting cmd-, are not adequate solutions for this problem: if you forget to set *print-length* in advance, you're hosed. And once the spinning beachball of death appears, cmd-, is useless.

Try executing the following form in the listener in the IDE and the listener in the command line. The experiences will be very different. In the command line, hitting cmd-. or cmd-, always stops the output. But in the IDE, cmd-. never works and cmd-, only works occasionally, assuming you don't have a beachball. Very often, the only recourse in the IDE is to force-quit CCL.

(let ((l (make-list 100 :initial-element 'foo))) (make-list 100000 :initial-element l))

Not sure if this is a bug or changes required on my end due to bridge changes re: framework loading as the error message isn't telling me anything helpful (I've attached the backtrace as Trac seems to want to wrap everything making it very difficult to read)