libera/#commonlisp - IRC Chatlog
Search
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
14:57:27
phantomics
flip214: I'm counting the number of cores that are currently busy, the number of cores present is simple to find
15:39:54
beach
Is SBCL still emitting style warnings for slots with the same SYMBOL-NAME but different SYMBOL-PACKAGE, or is it just that I haven't updated my SBCL for some time?
15:58:13
mfiano
beach: In response to my issue, this was implemented in 2.1.9: "finalizing classes with slots with duplicate symbol-names will only emit a warning if either slot name is an exported symbol."
16:03:00
mfiano
Yes, but beach and I explicitly annotate slot names to not coincide with exported symbols.
16:29:28
flip214
phantomics: cores busy _globally_, or with your CL image? Counting active _threads_ is easy... but _cores_ needs scheduler support, eg. reading /proc/self/sched or /proc/self/status every second and building differences
16:32:26
phantomics
flip214: the goal is counting threads busy in the CL image. (lparallel:task-categories-running) returns this information but it builds a vector, and my goal would be to count active threads very often, anytime I might want to put a task in the lparallel channel, so I'd rather not use a method with that much overhead
16:56:26
flip214
phantomics: so, if you have 8 cores but 20 threads running, you'd want a value of 20?
16:57:41
flip214
the scheduler already has a few counters: https://github.com/lmj/lparallel/blob/master/src/kernel/classes.lisp#L68
17:02:22
flip214
phantomics: how about this? https://github.com/lmj/lparallel/blob/master/src/kernel/stealing-scheduler.lisp#L101
17:02:24
phantomics
The issue is that I want to split complex tasks across threads but the efficiency of doing so depends on the available workers
17:03:11
flip214
phantomics: well, if you create your own kernel, you _know_ how many workers are available. Of course, the number of available _cores_ is a harder question....
17:05:22
phantomics
Basically, the issue is that I'm running tasks that can be divided into independent parts, thus can be multithreaded. However, some parts of a task may be more complicated than others, and an individual task may contain threadable parts
17:05:48
phantomics
So if one of the sub-tasks is threadable, I would want to subdivide it and then check whether there are idle workers
17:06:43
phantomics
If there are idle workers, they will get parts of the sub-task to do. If not, I will run the parts of the sub-task synchronously, -but- after each one completes, I will check again whether there are idle workers, and if so, I will start assigning them parts of the sub-task
17:10:06
phantomics
Would the maybe-wake-a-worker function be usable to check whether a worker is idle?
17:12:37
White_Flame
you also need to average multiple samples of this. a single snapshot could happen to be running a bunch of 1 nanosecond jobs simultaneously
17:14:45
phantomics
The consequence of that would simply be that one task segment would get run synchronously, but when the subsequent segments are run the system would see idle workers and assign them the following segments
17:17:26
rendar
the lisp parser uses a stack right? e.g. (+ (+ 2 3) (+ 5 6)) it reads first +, and pushes that to a stack, it evals 2+3 and 5+6 and then eval the first + bringing those results from the stack, right?
17:20:32
_death
read and eval are separate.. an interpreter would first read the whole form, and then evaluate it
17:25:15
_death
it depends on the lisp dialect.. in Common Lisp the evaluation order is left to right, and the + is not evaluated at all
17:26:16
jackdaniel
(+ (+ 2 3) (+ 5 6)) is equivalent to (funcall #'+ (funcall #'+ 2 3) (funcall #'+ 5 6)) ; so in some metasense it may be considered evaluated :)
17:27:01
rendar
i mean, you must pass whatever (b) and (c) returns to a, and in doing that, you must get (b) and (c)
17:27:33
jackdaniel
application - take a function and arguments and call the function with said arguments
17:29:43
jackdaniel
2022 websites are a pile of dynamically changed content with cookie popups, in other words - garbage
17:30:30
rendar
jackdaniel, at least, you don't have to do left and right with the head, like you're watching a tennis match
17:33:13
jackdaniel
most notably it embraces techniques from both scheme and common lisp, so in some sense it is better than studying a single language
17:34:07
rendar
i'm writing a little lisp interpreter in python for learning purposes, and to compute (+ (+ 2 3) (+ 5 6)) i need a stack or something where to put the first + operator, computer 2+3 and 5+6 then compute the a+b with those results..
17:37:11
_death
there's also structure and interpretation of computer programs (SICP).. there you can even see it in the logo (the mutual recursion of eval and apply)