freenode/#lisp - IRC Chatlog
Search
21:24:41
drmeister
Im thinking aloud here while I’m on my phone - can I define a method on finish-output for a stream? Python has a sys.displayhook() that I need to mimic so that cl-jupyter can display intermediate output
21:29:29
Shinmera
https://github.com/trivial-gray-streams/trivial-gray-streams/blob/master/package.lisp#L36
21:29:52
Shinmera
subclass the appropriate output-stream class, and add a method to stream-finish-output
21:37:04
Shinmera
You could base it on the redirect-stream for instance https://github.com/Shinmera/redirect-stream
22:27:06
grobe0ba
i am having issues running CCL. On Alpine, with MUSL libc, i'm missing symbols, which is to be expected, so i'm not bothering with that at the moment. however, since that fails, i have been attempting to run it in a docker container with centos, which fails with "Couldn't load lisp heap image from /home/grobe0ba/opt/ccl/lx86cl64.image: Operation not permitted".
22:27:40
grobe0ba
the container is privileged, using host networking, and has multiple add-caps, all apparently of no use.
23:01:35
pillton
stylewarning: Regarding the conversation a while back where you said: "ad hoc polymorphism is nice with types/classes/CLOS/spec-store/whatever, but I meant parametric polymorphism above, where we define a function that's singly generically useful for many types"
23:02:15
pillton
stylewarning: I attempted to do that with https://github.com/markcox80/template-function which is built on top of specialization store.
23:35:31
Fare
stylewarning, pillton, have you seen lisp-interface-library, for parametric polymorphism?
0:33:14
pillton
Actually, what I really mean, I had difficulty mapping lisp-interface-library to the problems I have.
0:34:08
stylewarning
LIL to me was the introduction of a new paradigm to Common Lisp, not a library to fulfill the needs of an existing paradigm
0:35:12
stylewarning
it does enable different sorts of polymorphism, but doesn't map syntactically to any usual way of thinking about polymorphism (imo)
0:35:41
stylewarning
Haskell type classes, for instance, eventually map to an interface-passing style mechanism under the hood, but it's not something you ever see or are exposed to as a user
0:56:20
PuercoPop
Fare: looking into the quake source code I see some code for the alloy-mode, but I'm unsure what was the use case of alloy, to help model the DB?
3:26:41
PuercoPop
At long last my XCB client can send and read the setup request. Now I have to think how to reify the XCB types, probably as CLOS classes. I've seen the Elisp client uses the slots in a class as 'schema' but one can't assume the slot order is they are 'written in code' right? Plus I don't want to keep the padding bytes in slots if I can avoid it.
3:31:42
sabrac
Agree the slot order is not specified, so you cannot rely on the order in the written code
3:33:51
PuercoPop
I've been thinking of maybe writing the schema filter padding fields before defining the corresponding class
6:42:12
beach
I didn't read it for the longest time because I thought it would be something written by random complainers.
6:42:31
beach
But these guys are very knowledgeable and very smart. They know their computing history.
6:42:32
schweers
I’m not sure its brilliant, but it does shed some light on areas of unix which I previously did not critically examine
6:43:04
schweers
I sometimes wish for more commentary on how this should be instead, but nevertheless, it is an interesting read.
6:43:15
beach
It is brilliant because it accurately points out many things that we knew how to do before Unix, and that are now done wrong.
6:44:43
beach
Oh, I agree that the book depressing in many ways. But the way the computing domain has turned out is depressing. That's why I am trying to do something about it.
6:44:53
schweers
I first heard of the book when I was starting out with linux. back then I came from windows, which I still find worse.
6:45:05
beach
Well, I won't be able to change anything, but at least I will know what should have been done instead.
6:50:50
schweers
I worry that even if your Lisp OS is the greatest thing ever, and it done by tomorrow, it won’t pick up much market share. Simply because our industry is already fubar :(
6:51:24
beach
That's what I meant when I said I won't be able to change things, but I will know what should have been done instead.
6:52:17
schweers
I wonder: how difficult would it be to run programs not written in lisp on such an OS?
6:53:25
schweers
please correct me if I’m wrong, but this is how I understand it: by focussing on C so much, unix became kind of language agnostic. I wonder how this would work an OS which focusses on any higher level language.
6:55:07
jackdaniel
there was also vacietis (not sure if I didn't mix some letters) - C compiler written in CL
6:56:11
Shinmera
No, but you don't need to program in Lisp to run a lisp routine either. It's all ASM at the bottom.
6:56:17
schweers
I wonder how to properly translate C to lisp, as C relies so heavily on the fact that memory is flat and has poor access restrictions.
6:56:24
jackdaniel
I'm working on an interesting problem: copying array region into itself (with possible overlap)
6:56:47
lieven
symbolics came with a C compiler. it's often invoked in C standard debates to show that the NULL pointer isn't guaranteed to have all bits 0 and can't be initialized with calls to calloc
6:56:48
schweers
that I get, but how does one exchange data? in a simple format not unlike what is done in C-land?
6:57:59
schweers
This sounds a lot less scary than I initially thought. So thanks for the clarification :)
6:58:12
Shinmera
It's really astounding to me how ingrained this idea has become in people's minds that "C is simple" and that everything else is somehow special.
6:58:59
lieven
schweers: for example, a lot of those poor access restrictions you're talk about in C aren't guaranteed by the standard
6:59:02
jackdaniel
I like C though I have one complaint – control of the function argument stack should be on the calee, not the caller
7:00:06
schweers
Ah yes, another problem: the C I have in my head is C on linux on x86, not the language standard.
7:00:48
schweers
I find it really weird that C does not have access even to very simple parts of the processor, like the carry flag
7:02:24
schweers
nevertheless they were once relevant. And other architectures may become more relevant again in the future.
7:02:30
lieven
C on VM/SP did not have a stack but as mandated by that system's ABI a chain of activation records
7:03:58
beach
schweers: The way I see it is, in order to run a C program on the kind of OS I would like, it would have to behave like a single Common Lisp function, and it would have to communicate with other functions just like in Unix, i.e. with something like file descriptors.
7:50:36
schweers
forth is and was interesting to me because it induces a shift in perspective. Lisp obviously did too.
7:52:34
Bike
i mean things like the create word. when i learned that i was like oh, that's "lower level" than C (not knowing about alloca at the time)