libera/#commonlisp - IRC Chatlog
Search
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.
6:40:49
specbot
Resignaling a Condition: http://www.lispworks.com/reference/HyperSpec/Body/09_adaa.htm
7:00:26
pjb
Alfr: thank you. Indeed. The problem is that the code that signals a condition cannot know when the handling of the condition is finished. It's definitely not when we're out of a handler-bind, but even not when we're out of a handler-case. For example, the handler could store the condition (with the situation that led to its signaling embedded in it), and process it later.
7:00:54
pjb
So indeed, conditions can be pre-allocated, but they should be used for a single situation.
7:12:11
pjb
semz: note that when a storage-condition occurs, the condition object is not the only object that needs to be allocated. We may also need to allocate some string (error message), some bignum (memory size, etc), and some other temporary object. Therefore it's probably best managed by reserving some memory zone where to allocate those objects, at the level of the memory manager.
7:33:58
greyrat
I am trying to write a one-off "macro" without using an actual macro. But `eval' seems to evaluate its input in the global scope. How do I do this idiomatically?
7:38:32
greyrat
I didn't use a pastebin because it takes two seconds for the site to load for me, so I really don't like opening webpages when I don't have to. I'll use pastebins in the future.
7:39:01
moon-child
you should be able to configure your text editor to automatically post some region to a paste site
7:43:07
moon-child
the compiler is less constrained if it is not required to be able to dynamically materialise a location for a given variable
7:43:20
beach
greyrat: What moon-child said. If that were possible, the compiler could not apply certain optimizations, such as eliminating dead variables.
7:45:04
moon-child
eliminating dead variables doesn't matter _that_ much--just a bit of extra stack space. But any sort of constant propagation or type analysis would be completely killed
7:48:19
beach
Sort of. If the variable is in a register, it may have to be spilled if it is considered live.
8:05:20
hayley
One trick I've done (which I think is a bit famous for happening frequently in SBCL sources) is to write a form like (macrolet ((frob-it () code-generation-stuff-here)) (frob-it)).
8:06:57
hayley
I recall one person wrote a macro for this pattern, and called it ETOUQ (backwards QUOTE).
8:09:15
greyrat
Okay, I wrote a macro. Is there any way to "map" the macro on a list? Sth like `(mapcar #'to-int '(year month day))' where `to-int' is a macro.
8:11:38
moon-child
(could make it a parameter. (defmacro stuff (&rest vars) ... iterate over vars) (stuff year month day)
8:18:17
greyrat
moon-child: Thanks. This seems awfully redundant and non-composable though. Why can't there be a general way to iterate a macro over symbols?
8:19:34
moon-child
greyrat: we've already established that this is 'one-off'. Why should it need to compose?
8:20:13
moon-child
(in fact, I don't entirely see why it composes much worse than any other solution. But.)
8:20:28
greyrat
moon-child: I would need to repeat the boilerplate for iterating over multiple arguments in ALL my oneoff macros, which is a lot of repetition.
8:21:40
moon-child
you can easily write a macro for writing one-off macros. Beyond that, it seems likely to me there is an alternate organization that would work better, but without looking at the code I cannot supply it
8:23:03
greyrat
moon-child: Can I write a macro that expands `(macro-iter some-macro a b c)' to `(progn (some-macro a) (some-macro b) ...)'? I guess this should be doable, and will resolve my problems.
8:24:37
moon-child
(defmacro ctmap (m &rest args) `(progn ,@(loop for arg in args collect `(m ,arg)))) or some such
8:38:45
greyrat
moon-child: Is it possible to add optional keyword arguments to the macro, while taking all other args into a list? Sth like this:
8:40:11
pve
I decided to see if Eclector could be used to provide a shorthand way of accessing instance slots. Here's what I got:
8:40:16
pve
https://github.com/pve1/eclector-access/blob/master/examples/slots-and-accessors-test.lisp
8:40:47
pve
I remember being a bit annoyed at the verbosity of accessing slots when I started lisping. I don't really feel that way anymore, but it was a nice exercise nonetheless.