freenode/#sicl - IRC Chatlog
Search
4:55:18
beach
Me? Only the one for ELS. But I am working on one that explains first-class global environments.
6:01:59
beach
ebrasca: Either way, if you have any questions relative to those videos, don't hesitate to ask.
7:06:37
ebrasca
beach: Why compile run and debug version instead of compiling debug version on demand?
7:23:15
beach
The paper is not that great, in that the page limit is not enough to explain everything. But you might at least understand why it can't be done in one phase.
8:24:01
beach
Just a little bit. My main goal has to do with how applications collaborate, so I haven't given much thought to low-level details. In fact, I can very well see running this "operating system" as a Unix process for some time.
8:24:02
beach
But there is a project called IOKit that created object-oriented device drivers, though it was in C++. But I think some inspiration can be found there.
8:34:54
ebrasca
Have you think running this OS over multiple machines at the same time as one device?
8:36:14
beach
No, I don't know how to do that, unless the multiple machines simulate shared memory. Everything in the Lisp world relies on object identity being fixed, and that is hard to accomplish in a distributed system.
8:37:10
no-defun-allowed
I screwed up with my last commit for hash tables, and forgot I had an alist of hash functions and not test functions.
8:42:42
no-defun-allowed
The hash functions are at the end of Code/Hash-tables/sxhash.lisp, and the test functions in Code/Hash-tables/generic-functions.lisp (above hash-table-test)
9:29:23
no-defun-allowed
Though I think https://developer.apple.com/library/archive/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/Introduction/Introduction.html is more interesting to read.
9:30:12
beach
I think I did some reading and it was quite interesting. The main point was to use the tools of object-oriented programming to factor the code compared to what is traditionally possible in C.
9:32:17
no-defun-allowed
That sounds like it would be very effective. I forgot whom but someone told me most of the complexity of drivers was basically in forming a database of how hardware breaks its own specification.
9:34:53
no-defun-allowed
I thought the drivers were classes themselves, so another client object wouldn't be necessary.
9:38:26
MichaelRaskin
no-defun-allowed: I think it is a common understanding. I think I was mentioning this on this channel and on lispcafe when people got too optimistic about possible high-quality drivers for mass-market devices
9:38:50
no-defun-allowed
Then at initialization time, the driver could test for whatever quirks it might need to handle, and change the class of the object, to one which accommodates for that quirk. (That could use something like dynamic-mixins to handle multiple of such quirks for one device.)
9:40:39
MichaelRaskin
no-defun-allowed: I am kind of afraid there are things you do not want to risk probing unless you are OK with them working… (and then there are undiscoverable quirks where you need kernel module parameters, sigh)
9:42:59
beach
Subclassing might work as well. I guess it depends on the number and nature of the differences.
12:15:29
phoe
Whichever day and time you consider the most proper. Frequency, I guess once per two weeks is okay.
12:24:21
phoe
beach: no problem. Could you send me a short abstract on query? I will want one or two short paragraphs like the quoted ones in https://www.reddit.com/r/lisp/comments/gpwfyf/online_lisp_meeting_2/
12:25:25
phoe
beach: nope. The sooner the better, but I want to have it a week before the actual meeting to give everyone's at least a week's notice before the actual meeting happens.
12:59:04
beach
It is not quite complete, but before I continue, I would like remarks on it, remarks about the precision of the text, but especially remarks regarding whether you think it works: http://metamodular.com/SICL/discriminating-automaton.tex
12:59:30
beach
It is not TeX yet, but when it is finished, I'll incorporate it into the specification.
13:01:05
beach
heisig: In case you missed it. I wrote a generic version of TYPEP and it has EQL specializers. I need to figure out how to cache calls to it, and also how to satiate it.
13:02:16
beach
I am both wired and exhausted. I worked too hard on this thing since yesterday. I need to figure out a way to relax.
13:12:23
heisig
beach: Yes, I read about your work on EQL specializers. But I didn't think it through yet.
13:14:19
beach
So if TYPEP contains EQL specializers, we don't currently cache calls, which means we call compute-applicable-methods, etc, in each call. These functions use things like copy-list, nth, etc.
13:16:12
beach
Besides we had to figure out how to cache calls to direct instances of standard-generic-functions with EQL specializers anyway.
13:17:08
heisig
I think you already wrote that bypassing COMPUTE-APPLICABLE-METHODS for standard generic functions is possible.
13:18:23
heisig
The other one could be to follow the generalizers/specializers proposal. But I am not sure that is applicable here.