Search
Friday, 9th of August 2019, 11:05:56 UTC
13:14:52
varjag
is there anything like (ccl:current-time-in-nanoseconds) in lispworks?
13:15:00
varjag
any way to access platform's precision timer
13:17:00
dlowe
local-time calls gettimeofday using lispworks' ffi
13:17:46
dlowe
doesn't work for windows, though
16:42:27
nullnullnull
why sbcl --eval is not working like --load? (if i put the whole script into --eval it will not load the "require" packages)
20:15:36
Lord_of_Life_
** NICK Lord_of_Life
22:30:50
manualcrank
hey guys, according to CLHS for SORT, "The sorting operation can be destructive in all cases."
22:32:07
manualcrank
translation: in all cases, maybe. wtf?
22:32:31
manualcrank
when is it destructive and when isn't it?
22:34:01
manualcrank
i spent all day trying to figure out why some code wasn't working
22:34:50
manualcrank
turns out (loop for list across array-of-lists do (sort list #'<)) was dropping list elements
22:36:45
p_l
manualcrank: assume it's destructiv
22:38:50
manualcrank
but if it were destructive then that loop would work, instead i have to do something like
22:38:58
manualcrank
(dotimes (i (length array-of-lists))
22:39:00
manualcrank
(setf (aref array-of-lists i) (sort (aref array-of-lists i) #'<)))
22:47:40
manualcrank
i don't know, maybe i don't understand what destructive implies
22:48:59
manualcrank
seems to imply the argument may be modified in order to return a correct result
22:49:25
manualcrank
but not that the argument will be modified into the correct result
22:51:35
manualcrank
(let ((lst (list 3 2 1)))
22:51:37
manualcrank
(let ((srt (sort lst #'<)))
22:51:45
Bike
manualcrank: "destructive" doesn't mean the argument is changed to be sorted, it means the argument is changed
22:52:04
Bike
manualcrank: you still need to use the value returned by sort.
22:52:12
manualcrank
but (let ((lst (list 9 3 8 2 1)))
22:52:14
manualcrank
(let ((srt (sort lst #'<)))
22:52:33
Bike
lst is "destroyed". you can't use it any more.
22:53:13
Bike
as for "can be destructive in all cases", that means an implementation can decide when it's destructive.
22:53:20
manualcrank
i guess i was used to sort's behavior with arrays of fixnums, which always did the expected thing
22:53:23
Bike
two different implementations can differ on when it's destructive.
22:53:28
Bike
you can't rely on that either.
22:53:42
Bike
use the return value. the argument is destroyed. don't use it any more, even if it looks right on your particular implementation.
22:57:54
manualcrank
sbcl returns a style warning about discarding the return value of NREVERSE
22:58:52
manualcrank
it doesn't do that for SORT though, i really thought SORT worked like in C
23:00:32
Bike
C doesn't have linked lists or non simple arrays
23:00:47
pjb
(map-into array-of-lists (lambda (list) (sort list (function <))) array-of-lists)
23:00:57
no-defun-allowed
well, if you give SORT some conses, it'll adjust the CDRs to taste and it's more than possible whatever cons was first before SORTing could be in the middle
23:02:06
no-defun-allowed
and conses aren't passed by "reference" in a way like arrays are, if you move conses around, there's no telling which is first
23:05:23
manualcrank
yes, in retrospect sort's behavior makes sense
Friday, 9th of August 2019, 23:05:56 UTC