freenode/#lisp - IRC Chatlog
Search
9:12:26
JuanDaugherty
it's easy to be productive if you stay immersed in work, particularly work you do under your own control and for yourself
11:11:16
beach
Here is a very very preliminary suggestion for the layout of different windows in Clordane. Comments are welcome. http://metamodular.com/fig-layout.pdf
11:12:45
beach
The backtrace window is present not only when an error has been signaled, but also when the program has stopped at a breakpoint.
11:15:25
phoe
I'd switch the REPL and the error message windows. Makes more sense when the left side is where all the trouble is, and the right side is there you can do stuff to fix it.
11:16:05
phoe
Or rather, the left side is immutable (the stack is read-only, so is the error message), the right side is mutable (you can edit code and evaluate things in the REPL).
11:16:29
Shinmera
I'd also move the message above the trace, since people usually care about the message first
11:17:47
phoe
It might be a SLIME influence, but I don't think I need a separate window for the error message. It can be printed above the stacktrace in its window, just as in the SLIME debugger.
11:20:00
phoe
I generally think people enjoy allocated but unused space on their screen as much as they enjoy allocated but unused space in their memory.
12:01:03
phoe
or do you want a separate window that shows the variables and parameters in the current stack frame?
12:54:07
flip214
(OPEN #P".../..." :DIRECTION :OUTPUT :ELEMENT-TYPE BASE-CHAR :IF-EXISTS :SUPERSEDE :IF-DOES-NOT-EXIST :CREATE) but
13:00:06
beach
phoe: I am not sure. I was considering showing the value of a variable when it is hovered over by the pointer.
13:01:07
beach
phoe: Alternatively, show the live variables together with source near the source window.
13:06:17
flip214
so some option to open a new (X11!) window with the variable inspected would be nice.
13:06:31
flip214
that's what I did for slimv - open another gvim, and inspect the current thing there
13:06:57
flip214
has the nice advantage that multiple such windows can be easily moved around and visually compared, eg. before/after code change etc.
13:23:29
puchacz
but this one is OK, isn't it? (type (function (or character nil) (or character nil)) predicate)
13:26:01
beach
puchacz: I think you need a level of parentheses around the argument type specifiers.
13:26:19
puchacz
beach: compiler accepted it, but I have no way of knowing if it means anything to it
13:31:42
specbot
Declaration Identifiers: http://www.lispworks.com/reference/HyperSpec/Body/03_cc.htm
14:17:36
flip214
when creating a new file but stopping the process with Ctrl-C, the file gets removed again.
14:41:35
puchacz_
by the way, can I create a package with functions named like unicode/string-downcase, and then import this package shadowing string-downcase from common lisp?
14:42:57
beach
You can shadow any name, but you are not allowed to redefine the Common Lisp function. Shadowing means you have the same SYMBOL-NAME but a different SYMBOL-PACKAGE for the names.
14:43:19
phoe
puchacz_: create FOO:SYMBOL-NAME and then (:shadowing-import-from #:foo #:symbol-name)
14:44:08
puchacz_
is it even possible what I want, i.e. to have name like "string-downcase" to refer to different function?
14:45:23
puchacz_
if I do so, will unqualified symbol STRING-DOWNCASE in source file text refer to my function?
14:45:36
phoe
(defpackage #:my-package (:use #:cl) (:shadowing-import-from #:foo #:string-downcase))
16:07:38
borodust
Xach: is that good enough README (i know it's not exactly very helpful) to get included into main quicklisp? https://github.com/borodust/claw#claw
16:15:20
phoe
Xach cares if your project has the author/description/license fields filled in the ASD file and if it builds on SBCL x64 Linux without errors
16:15:52
jackdaniel
actually offical requirement is that it builds on "at least on two CL implementations"
16:16:19
borodust
i'm looking at http://blog.quicklisp.org/2015/01/getting-library-into-quicklisp.html
16:16:29
phoe
jackdaniel: then it was changed, it was just SBCL before since that's what Xach can test on.
16:30:01
borodust
Xach: also, is that acceptable approach? https://github.com/borodust/chipmunk-blob
16:30:36
borodust
Xach: this is still asdf library, it's just that it doesn't really contain author/description...
16:43:33
puchacz_
hi again, I wanted to have (:shadowing-import-from #:unicode-hack :#char-equal ... etc) as symbol-macro, but it is not expanded in defpackage form
16:45:08
puchacz_
how would it work? regular macro, but in defpackage form prefix it with #. like #.(expand-unicode-hack) ?
17:02:11
scymtym
ebzzry: http://lispm.de/lisp/benchmarks.html but most of the results are not very recent to say the least
17:13:28
phoe
but I'm using SBCL 100% of the time and never had too many issues with compilation times on SBCL.
17:13:55
phoe
all I notice is, when I quickload a new system, or a system after a Quicklisp dist update, then it can take a minute or two-- this.
17:15:49
scymtym
since a few releases ago, SBCL should be substantially faster at compiling ironclad. faster than previous SBCL releases, that is. i don't know about CCL compiling ironclad
17:16:53
scymtym
also, choosing an implementation for development solely based on compilation speed seems ill-advised
17:32:44
jackdaniel
I use all three (ECL included) to ensure that I didn't rely on some implementation-specific behavior
18:31:43
malice
Some of them excel at different things (e.g. SBCL isn't very good at debugging but generates quite fast code)
18:32:06
malice
Some are more popular than other, some might work at platform you need, plus personal preference.
18:32:30
puchacz_
so areas they differ are: debugging, deployment on different platforms, anything else that is important?
18:33:46
beach
puchacz_: Some Common Lisp implementation target specific application types. For example, ECL is good for communicating with C code, and Clasp is good for communicating with C++ code.
18:34:25
beach
puchacz_: Some others are extremely portable, like CLISP because they can function with a bytecode interpreter, so do not need to be retargeted for different architectures.
18:34:26
malice
Speed, interoperability with other languages, bugs, perhaps some OS interfaces, perhaps MOP implementations, implementation-dependant things and probably bunch of other I don't remember right now
18:36:24
malice
The nice thing is that you have many different implementations, so you can just pick the one you like!
18:36:59
puchacz_
so from the benchmarks, I understand SBCL (because everybody uses it and quicklisp is checked against it AFAIK), lispworks (because it has stepper and it can deliver to many platforms) and ABCL (because you can script around java)
18:37:00
_death
you can also find hidden assumptions by trying your programs on different implementations
18:37:02
malice
Note that some implementations might be commercial and require payment, like LispWorks or Franz's compiler.
18:38:59
malice
Not really, I believe there was some effort to bring it up to date, but I'm not sure if that succeeded, though I may be wrong.
18:58:56
jackdaniel
as an example: clisp is the only CL which runs on minix3, ecl is in fact libecl.so and you may attach CL (and introduce live recompilation) to C/C++ application and mezzano is a whole operating system which provides CL as the language to communicate with it
19:10:39
malice
Is it incorrect to say that in CL you call a method? Should you say that you call a generic function instead?
19:13:16
malice
That's true. I also meant a general context; I am aware that e.g. #'call-next-method calls, in fact, a method, and not a gf.
19:14:06
phoe
you may call a method, sure, mop:method-function returns you something that you can funcall