libera/#commonlisp - IRC Chatlog
Search
14:03:12
hayley
The idea is basically the "partial read barrier" used in Smalltalk <https://dl.acm.org/doi/10.1145/2754169.2754186>, with the exceptions that the authors of that paper do not implement change-class, nor does their implementation need to be safe when using multiple threads.
14:06:07
hayley
What they call the "read barrier" is what we called the "indirection". The read barrier is "partial" in the sense that they try to avoid following the indirection, when it is not necessary to follow the indirection.
14:12:30
beach
Here is what I have understood so far: In the beginning there are no indirections because no class has been modified. At some point, it is then inevitable that a class will change. Since there are no indirections, all references must be updated. Yet, it is enough to scan the stack to find those references.
14:13:29
beach
But don't bother trying to explain it to me. The only way I can make sense of it is if it is written down in a coherent text that can be read in its entirety and commented upon.
14:14:46
gin
what is the syntax of melpa version numbers? I can see there is package-YYYYMMDD.NNN. What is the NNN? I thought it must be HHMM for hours minutes but why only 3 digits. what time formatting produces three digits for hours minutes?
14:15:00
hayley
I would recommend reading that paper then, until I get the time to write down how the technique would be adapted for a Common Lisp implementation.
14:23:09
hayley
I'm almost done with university for the semester, so hopefully I should be able to write my idea down soon. And hopefully I'll be able to finish off my parallel GC soon.
14:39:08
prokhor
hayley: do i understand it right: you plan to implement a compiler for a parallel language?
14:43:28
beach
prokhor: I know hayley has been working on a parallel garbage collector for SBCL, so that's probably what was referred to.
15:35:09
splittist
Would anyone like to share some OpenType font file reading code? I would like to play with CFF2 charstrings.
17:08:22
alcor
A few days ago, I read an internet that said CL conditions can be used to implement progress notification without unwinding the stack. Where can I find more info about this use case?
17:12:29
edwlan[m]
You'd just use (define-condition progress ...) to define the condition and then (signal 'progress ...) to signal progress
17:24:13
scymtym
my take from many years ago: https://github.com/scymtym/more-conditions#tracking-and-reporting-progress-of-operations
17:57:47
bitblit1
What are your opinions on recursive functions; when do you use them? all the time, completely avoid, other. If you do you them then what is your mindset meaning how do you solve a problem using recursive functions?
17:58:35
bitblit1
In your case is it harder to solve a problem using recursion rather than iterative solutions? Or same or other?
18:05:51
beach
bitblit1: As edwlan[m] says, you use recursion when your data is naturally inductive, except that you don't use recursion on linear structures like lists.
18:17:14
edwlan[m]
Like, if you're working with a list, you have a base case, (), and then a step case (x . rest)
18:17:54
edwlan[m]
So, it's often easier to work recursively because you can define how to handle the base case and how to handle the step case and then reduce handling rest to a recursive call
18:54:19
pjb
alcor: more details in the clcs book. (there's a #clcs channel too). https://www.amazon.com/Common-Lisp-Condition-System-Mechanisms/dp/148426133X
21:19:18
zest
if there is a way not to use a gray stream like function, similar to file-position thatd be perfect...
21:19:51
zest
use case is i am writing a protocol and want to read as little as possible since the protocol is io heavy
21:20:28
zest
i looked to fast-io and trivial-gray-streams to no avail... surely there is a function like file-position for gray-streams...