freenode/#lisp - IRC Chatlog
Search
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)
7:59:53
lieven
Thinking Forth by Brodie is a great book even if you have no intention to ever use Forth
8:05:38
jdz
I quite liked it. The comments about size made me chuckle, reminded me of https://prog21.dadgum.com/116.html.
8:07:19
jackdaniel
while I admire forth very much (and rather like C), I'm afraid we stray from the channel topic forther and forther ;)
8:07:38
schweers
yeah, I know. I was having a hard time understanding the more interesting features of forth and was hoping for more (and different?) explanations.
8:07:52
jdz
I have not done any Forth programming, and cannot be considered a real programmer since I have not even implemented a Forth interpreter.
8:09:04
lieven
jackdaniel: up to a point. in a way lisp and forth are two languages that very much support building up your language to address the problem domain. they're both programmable programming languages where you have (most of) the tools of the language implementor at hand for your own work
8:09:54
jackdaniel
Imo if we refuse to talk scheme or clojure here, forth may be considered not common-lispy enough too :-)
8:10:40
schweers
we could discuss whether forth is closer to common lisp than scheme. Or we could simply not ;)
8:25:30
aeth
If you write a Forth implementation in CL (or any language) you have to call it Firth of Forth. https://en.wikipedia.org/wiki/Firth_of_Forth
8:31:33
lieven
Henry Baker did some work on that. for example http://home.pipeline.com/~hbaker1/ForthStack.html
8:38:46
no-defun-allowed
it just says [it hasn't been submitted](https://github.com/eshamster/cl-naive-bayes)
9:20:06
schweers
is it just my impression, or is compiling Lisp code really pretty fast, even with SBCL?
9:21:12
dim
well it depends, I think the fact that we often compile a small chunk at a time interactively makes it for a very low-latency feedback loop and it then seems very fast
9:21:39
dim
that said compiling pgloader sources to a binary image takes minutes, as you can see at https://travis-ci.org/dimitri/pgloader
9:21:55
schweers
I find it quite fast even when I empty the cache (~/.cache/common-lisp) and load my whole system it is reasonably fast.
9:23:35
schweers
hm, so it seems my impression is only partly correct. Nevertheless, it’s not extremely slow as one might naively expect
9:23:50
aeth
The problem with CL compilation is that it is not parallel and afaik that is a problem that would have to be solved by ASDF.
9:24:47
dim
schweers: I think most people attributes slowness to being “interpreted” languages and don't understand that a language isn't compiled or interpreted, the implementation is, and may be both (as in javascript), and also that the level of flexibility and dynamism we have in CL, people think it must cost a lot in perfs
9:25:42
aeth
dim: It *does* costs a lot, it's just that on 2018 hardware those costs are usually laughable.
9:25:59
loke
no-defun-allowed: CCL's code generation isn't as good as SBCL's but I've never really been in a situation where that matters.
9:27:16
dim
CCL/SBCL: pgloader shows the difference quite clearly, CCL is far better at Garbage Collection and memory maintenance while SBCL produces code that can be twice as fast
9:27:21
schweers
the programs maybe, but it seems that the runtime is still often too large for “embedded” devices. Which is why I don’t like said devices
9:27:21
aeth
shka_: Only because programs are using a lot more RAM than they used to. I am running several daemons that have almost bloated to the starting RAM usage of SBCL (including systemd and Xorg, which probably surprises no one)
9:27:53
aeth
But most SBCL programs don't compare to the web browser and browser-based 'native' programs
9:30:18
schweers
ah, speaking of garbage collection; does anyone know for sure what SBCL uses on AMD64? The manual is not exactly clear on the distinction between 32 and 64 bit x86.
9:31:47
aeth
The state of the art for garbage collectors are made for Java and/or the JVM, in general.
9:32:21
schweers
wow. Now I’m even more impressed with GC. TIME in SBCL reports how much time was spent in GC and out of GC. I was always impressed by how little time the collector needed. Now that you’re telling me this could be even better, I’m even more impressed and convinced that GC is good for performance.
9:33:26
aeth
schweers: The lowest hanging fruits in SBCL performance improvements are probably the GC and CLOS, at least based on stuff people say in #lisp
12:48:34
LdBeth
is there *fast* approch to implement binary op so add #xFFFF and #x0123 is #x0122 and subtruact #x0123 form #x0121is #xFFFE
12:55:31
shka_
somehow sbcl seems to be able to infer that this operation is allowed to overflow and produces slightly different code
13:24:20
Shinmera
but the good news is you don't need to, just spawn a swank server and connect to it with slime (tunnelling the port through ssh for instance)
13:24:46
Shinmera
systemd will automatically log any stderr/stdout output to journald for all its services, so you don't need to do anything for that
13:25:12
dingusman
ok, yeah, if I didn't run screen I guess the second question is no longer relevant
13:26:44
dingusman
Does it matter what's in start.lisp in this example? seems to me this will still start sbcl in interactive mode
13:28:09
dingusman
I tried something like this already. But (IIUC) systemd points process' stdin at /dev/null
13:32:37
dingusman
And I'd still be able to connect the swank server since it's running in a separate thread?
13:58:02
dim
dingusman: you can also have a look at https://github.com/dimitri/pgcharts/blob/master/src/pgcharts.lisp if you want, for an alternative implementation, still with the idea of (loop :while *server-is-running* :do (sleep 1))
14:05:31
dingusman
dim: thank you, that's helpful. I've been looking for some real-life hunchentoot server code. There's a lot for me to learn in there
14:11:02
dim
dingusman: the part I like a lot is the serving of static files from memory, and building a binary image that includes those static resources, so that you only have one file to deploy
14:16:01
dingusman
That is neat. I'm doing something pretty similar. Generate a ql dependency bundle, html/js with who/parenscript, then load it all in and dump it to a core image to deploy
14:17:07
dim
hehe... do you compress the core? it might make the startup time a little longer, but gives a much smaller image
14:26:53
dingusman
dim: managed to kill my emacs in the process, but compression makes a big difference
14:29:26
Shinmera
there's a noticeable difference if you want to do scripts and stuff but for a heavy-weight thing like a server or a gui it's perfectly fine.