Custom Query (1030 matches)
Results (901 - 903 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #1197 | fixed | load-time-value regression | ||
| Description |
File-compiling (defun ltv ()
Yields (ltv) => #:LOAD-TIME-EVAL and CDR yields ((FUNCALL #<Anonymous Function #x3020066140CF>)) |
|||
| #1198 | fixed | Printing long things to the listener is a DOS attack | ||
| Description |
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)) |
|||
| #1199 | wontfix | Possible wrong memory alloc statistics on multicore | ||
| Description |
I did some quick performance tests using the :lparallel library by replacing dotimes/mapcar by pdotimes/pmapcar in some raytracing programs. The results were correct and the speed-up on a quadcore Ubuntu Odroid U3 were plausible (about 2.5 times), however, the amount of memory allocated reported by the time macro was about 100-300 times LESS than the single thread original version. Perhaps only the memory allocated by the parent thread is counted in the statistics? |
|||
