freenode/lisp - IRC Chatlog
Search
5:13:01
beach
theemacsshibe[m]: The #clim channel will answer questions about CLIM and McCLIM. I usually hang out there, but I am traveling at the moment. I'll be back online on Wednesday.
5:20:39
beach
Also, scymtym is working on the reader (called Eclector) which used to be part of SICL, but that is now in a separate repository.
5:22:25
beach
I am trying to extract "modules" from SICL into separate repositories as much as is reasonable.
5:31:18
vtomole
As long as it's not split up too much. I think this stays true to SICL's goal of separating a CL implementation into modules. An implementer will clone the sub-components he/she wants.
5:31:31
beach
stylewarning: Since the basic specification (i.e. the Common Lisp HyperSpec) is stable, I don't think it will be a big problem.
5:33:28
beach
vtomole: It is still non-trivial to use those modules though. For Eclector, either an implementation uses it as a second reader (it has to have a reader in order to read the Eclector source code) or the implementation must cross compile on a different implementation the way SICl does.
5:37:01
beach
Right. But you are right. Take Eclector again. It has functionality that extends the Common Lisp HyperSpec, and that functionality is essential for client code, in particular source tracking. And it is important not to break client code that uses it.
5:39:37
vtomole
beach: To me, Common Lisp implementations are overwhelming. How is the back-end of SICL going? Are you still planning on compiling to x86_64? How much resources (time) does it take to write a "good" optimizing compiler?
5:42:52
beach
vtomole: The back-end is almost done. I have a separate repository containing an assembler for x86-64.
5:44:25
beach
vtomole: Hard to say how long it takes. I am not working on it full time, so it is taking longer.
5:46:15
vtomole
For sure, a lot of implementors compile their languages to LLVM because they don't want to deal with writing optimizers. But you are not worried about performance being equal to SBCL are you?
5:48:29
beach
It doesn't know how to do things like type inference, path replication, escape analysis and other things that are crucial to Common Lisp performance.
12:18:37
Colleen
Unknown command. Possible matches: 8, set, say, mop, get, hello, grant, time, tell, roll,
12:19:25
Colleen
pjb: Unknown command. Possible matches: 8, tell, set, get, time, help, deny, say, mop, test url,
12:22:33
Colleen
runs: Unknown command. Possible matches: 8, weather, set, say, mop, get, notify, grant, block, award,
13:15:06
ebzzry
Is usocket *the* cross platform TCP/IP solution? I want to port a LispWorks library to use it.
13:18:47
White_Flame
it's quite high in use: http://blog.quicklisp.org/2018/03/download-stats-for-february-2018.html
13:43:52
White_Flame
ebzzry: looking at usocket's lispworks backend, it looks like they're all in the comm: package https://github.com/usocket/usocket/blob/master/backend/lispworks.lisp
14:20:39
drmeister
https://github.com/quicklisp/quicklisp-client/blob/master/dists/quicklisp/software/manifest-20120208-git/manifest.lisp#L274
14:26:02
phoe
the variable "symbol" is meant to be a symbol and therefore calling FIND-CLASS with a non-symbol invokes undefined behavior
14:26:34
phoe
I mean, the spec says that it may return an unicorn because the behavior is undefined in such a case
14:35:28
phoe
I see. Then it's manifest's fault for invoking UB in the first place if it calls FIND-CLASS on non-symbols.
14:40:05
phoe
the :IS form seems like a filtering predicate that checks whether a thing falls into a category
15:42:41
oleo
http://dpaste.com/22F1R3C http://dpaste.com/1QRCND6, i did a backtrace for the last one but have still no clue what's wrong
15:45:16
pjb
oleo: typing v on the line 0: in the backtrace should jump to the source line, and you should see where the library value comes from. It's probably the variable that's bad, according to the error message.
16:10:47
oleo
and #.(declaim (optimize (safety 3) (debug 3) (space 0) (speed 0) (compilation-speed 0) (inhibit-warnings 0))) is not good enough ?