libera/#commonlisp - IRC Chatlog
Search
3:39:03
beach
I don't know the answer, but I wonder why that is important. I mean, you typically don't start your Common Lisp image very often.
3:40:40
smlckz
something like this: https://slime.common-lisp.dev/doc/html/Loading-Swank-faster.html
4:18:11
phantomics
Checking in again with a question about the finer points of threading. In lparallel is there a fast way to get a count of the number of active workers in the kernel? I'm working on finding a way to divide large, unpredictable workloads without causing delays due to shortages of available threads
4:22:15
phantomics
(lparallel:task-categories-running) will get the info, but running it millions of times will definitely cost
4:22:42
hayley
Though it'd be "intrusive" to your code, you could have your tasks atomically bump a counter?
4:22:54
phantomics
I've thought of keeping an integer count of active threads and incrementing/decrementing it when appropriate, but I'll have to handle many conditions
4:23:38
phantomics
Intrusive isn't much of a problem, since I'm concentrating all parallelism in the system in a single function to focus on optimizing
5:57:31
flip214
phantomics: is that more a question of "how many cores did I get assigned on startup", or "how busy is my system right now"?
6:01:00
flip214
the latter will be unpredictable to some degree... the first question is "just" a syscall, but could vary too
6:51:45
Josh_2
I have a macro that is defining two conditions, the latter has the former as a superclass, but CL is complaining that the former is not yet defined
6:55:10
flip214
or it might be easier to just (EVAL ...) the superclass directly during macro runtime
7:02:20
Josh_2
turns out it was because I had a define-condition form somewhere it shouldn't have been
7:52:13
flip214
Using SBCL 2.2.6+git something I observe that my code, when it dynamically creates a package, binds *PACKAGE* to it, and then (LOADs ...) some files into it (which use macros in other packages etc.),
7:52:55
flip214
gets the symbols LOOP-END-NIL, LOOP-STEP-NIL, and LOOP-TOP-NIL interned in that new package.
7:53:28
flip214
I'm fairly sure that my code doesn't do that; is that something that got fixed in SBCL lately?
9:38:29
_death
it generates such symbols via a function called symbol-append, which for some reason uses INTERN instead of MAKE-SYMBOL
9:58:07
beach
flip214: If the function is inlined, you will not see anything when you trace it. I don't know that that's the case, but it could very well be that.
9:59:47
flip214
beach: well, swank's tracer shows that ADD-SYMBOL is being called ... but using SBCL's (TRACE :encapsulation nil :break sb-impl:add-symbol) [that should use a breakpoint] doesn't work
10:03:45
beach
flip214: If it is not declared notinline, it could be inlined. But I guess that's not the case.
10:05:41
flip214
_death: but ITERATE is used in functions that are "statically defined" and might only get called via macros... does iterate INTERN in the generated loop prolog or epilogue??
10:22:37
flip214
yeah, thanks... one macro calls an inlined function that uses ITERATE, I guess that's the point where it happens.
10:24:23
_death
my guess is that make-symbol should be used instead, but I've not tried to assess the repercussions
10:32:42
Josh_2
aeth: Thanks for the info but no, the problem was I had a define-condition form with a superclass that was not yet defined somewhere it was not meant to be (duplicates)
10:35:46
flip214
yeah, perhaps that should be a GENSYM instead... reading the docs to find out what the iterate api is
10:36:36
flip214
https://iterate.common-lisp.dev/doc/Named-Blocks.html#Named-Blocks wants to use the block name directly, so no gensym
10:38:10
flip214
as a workaround I now switch *PACKAGE* to CL-USER before compiling resp. macro expansion
10:38:29
_death
the block name comes from the user (or nil by default).. here we are talking about the symbols generated by iterate
10:40:29
flip214
yeah - but I argue when passing in a symbol the generated symbols should be in the same package, not in *package*.
10:45:21
_death
my suggestion is that these symbols should not belong to any package.. I could be wrong if there's some expectation of persistence beyond a macroexpansion, but a priori I consider it unlikely
10:46:43
flip214
well, yeah, these could be GENSYMs too. but then you'd need a MACROLET for RETURN-FROM to divert the user-defined symbol to the gensym.
10:48:46
flip214
https://iterate.common-lisp.dev/doc/Named-Blocks.html#Named-Blocks says The generated code behaves exactly like a named block; in particular, (return-from name) can be used to exit it
10:51:22
flip214
oh, you want _only_ these symbols moved, now I understand. Yeah, these might be simple gensyms, I guess.
14:24:40
jeosol
yeah, it's going well - it's partly self use but has a lot of utility for others, other researchers if i can deploy it efficiently and portably