libera/#commonlisp - IRC Chatlog
Search
19:34:01
etimmons
salt rock lamp: I promised you a link to my work in progress on libgit2. Sorry it took so long: <https://gitlab.common-lisp.net/etimmons/cl-libgit2>
19:34:41
etimmons
salt rock lamp: The lispified wrappers are very much in the experimentation phase, so I can't really recommend using it.
19:35:50
jcowan
The modern view seems to mean that "parallel" does mean" "at the same time", in which case let-bindings are better described as concurrent. This view goes back to at least 1968.
19:38:26
jcowan
Throwing up and catching two balls with two hands is a parallel operation. Juggling three balls with two hands is a concurrent operation.
19:56:27
pjb
Josh_2: if you get storage-condition, and know what to do about them (eg. free some memory), then catch it. Explicitely, and precisely it. But don't catch other non-error conditions that you don't know, and that other parts of the system may rely catching.
19:57:02
pjb
Josh_2: catch storage-condition with handler-bind, it makes no sense catching it with handler-caseā¦
23:50:44
semz
Is it legal to preallocate a single storage-condition for this situation and just reuse it every time?
23:51:13
White_Flame
the system should at least leave space for creating/handling out of memory conditions, I don't think it's a problem for you to do the same
23:52:18
White_Flame
however, it's not just the condition object. Any consing, including during printing, can still be problematic
23:53:38
hayley
Apparently not, the notes are just about what can signal STORAGE-CONDITION (tl/dr everything).
23:57:29
specbot
Resignaling a Condition: http://www.lispworks.com/reference/HyperSpec/Body/09_adaa.htm
23:57:33
saturn2
it should be legal to preallocate a storage-condition and then make a new one after it's been handled and there's room again
0:00:11
saturn2
maybe it doesn't matter since this rule only applies "during the dynamic extent of the signaling process"
0:02:04
saturn2
and running out of memory again while handling a storage-condition just means the world ends anyway
0:02:09
semz
Are conditions themselves guaranteed to survive the signalling process? If they don't, one could reuse the space. Doesn't deal with OOM during the OOM handler but arguably this is a major user fuckup.
0:08:04
Nilby
IIRC some lisp machines had a memory reserve for handling out of memory conditions, and also the firmware could save a restartable image if things got really bad
6:23:09
pjb
semz: good question (reuse of conditions). 1- we can signal the same condition several times. 2- most condition classes in the standard don't have slot writers (therefore in a new situation, there's no standard API to mutate it, but nothing prevents an implementation to have and do it). 3- usually, conditions are not collected, ie. if a condition was mutated, this would have no consequence, because nobody keeps references to old conditions.
6:25:00
pjb
semz: so in the spirit of the standard, it would be best if the condition was pre-allocated, but not reused. It could be allocated when the garbage collector can free enough memory for it. But it would be preferable to allocate a new one each time it's signaled.
6:25:59
pjb
while conditions are not usually collected, this is something that is perfectly conceivable: you could keep reference to old conditions in an object-oriented logging system.