freenode/#lisp - IRC Chatlog
Search
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.