freenode/#lisp - IRC Chatlog
Search
3:41:14
MetaYan
mrblack: A nice Lisp environment based on Emacs and SBCL: https://portacle.github.io
3:54:27
mrblack
MetaYan, oh, I know about Portacle, but I'm an Emacs user already, I think there's no turning back :P
4:01:32
MetaYan
Yes, Portacle is Emacs, SBCL, Quicklisp put together in a nice ease-to install package.
4:09:45
no-defun-allowed
using quicklisp you should install slime then use that slime to load quicklisp so kinda
4:12:26
ober
(ql:quickload :quicklisp-slime-helper) then be sure to source in ~/quicklisp/slime-helper.el in emacs
4:17:24
mrblack
nope... I don't know how to load. I instaled via apt and "whereis" it won't tell me where it is. May I should not use the apt version?
4:23:53
Bike
yeah. you can do (ql:add-to-init-file) and it'll put it in sbcl's init file so you don't have to do it yourself
4:26:31
ober
learn that slime. there are a load of features that are use by many, but not obvious to new folks.
4:37:35
adlai
at which point mrblack discovers that there's a special circle of hell wherein slime addicts are forced to program lisp verbally, and each day a different one has to act as stenographer - using a mechanical typewriter
4:40:02
adlai
ACTION occupies the fixed point in that circle where you have to untangle the key jams
4:49:18
djeis[m]
So they don’t need to learn a new editor at the same time as learning a new programming language.
4:51:02
djeis[m]
Don’t get me wrong- love emacs. Do think it’ll probably stay the best lisp env going forward. But that doesn’t mean everyone should be expected to take the time to learn it. Better if at least a good subset of the CL-specific functionality were in more editors.
4:56:31
MetaYan
SBCL command line can become quite nice with sbcl-readline - just git clone https://github.com/jini-zh/sbcl-readline in quicklisp/local-projects , (ql:register-local-projects) once and then (ql:quickload :sbcl-readline)
5:09:44
adlai
mrblack: eh it shouldn't be sending any messages there during startup. you're probably noticing the inferior lisp buffer where slime talks to sbcl, or maybe the emacs message buffer
5:10:53
mrblack
yeah... I don't know how to solve this. It's of no consequence, really. Just a little OCD on my part.
7:29:04
phoe
Are there any papers on implementing a condition system in Lisp that doesn't have a condition system?
7:33:53
beach
As I recall, the condition system can be implemented entirely in a portable way. But I haven't thought about it for some time.
7:38:18
adlai
phoe: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.100.7504 (warning: the helpful answer would've been "no", but go on, click the link :)
7:41:30
phoe
beach: AFAIK, handlers are just functions, and handler-bind simply conses another handler on top of a dynamic variable. handler-case adds a THROW to achieve non-local exit.
7:41:55
phoe
SIGNAL searches the handler list for matching ones and invokes them; ERROR is signal on top of invoke-debugger.
7:47:46
adlai
ACTION was always under the impression that this behavior could be implemented as a handler of last resort
7:48:31
phoe
(signal (make-condition 'condition)) doesn't usually invoke a debugger; (error (make-condition 'condition)) always does unless the condition is handled
7:51:58
phoe
signaling a condition means "hey, I got this state in the program, you could run some code now if you'd like to"; invoking a debugger on a condition means "oh no, boy, you're *NOT* getting away with this, the program execution is halted"
7:52:50
phoe
which means, signal + invoke-debugger is equivalent to "hey, either you handle this thing, or your program stops in an unpleasant way"
7:54:45
phoe
handlers are just simple callbacks that you are able to specify dynamically; they are pretty useful for non-local exits, though, which is what they are often used for
7:55:58
phoe
see (let ((x 2)) (handler-bind ((condition (lambda (e) (declare (ignore e)) (incf x 2)))) (print x) (signal 'condition) (print x)))
7:56:49
phoe
you can substitute anything you want for the lambda body, and use the condition object for passing arguments to that callback.
9:14:37
adlai
ACTION gives up looking for the halt state precursor state, it appears to be the case that contrary to popular belief, common lisp actually is turing-complete.
9:17:19
aeth
Not only is Common Lisp turing complete, it has like 10 turing complete surprising areas (well, would be surprising in other languages).
9:20:05
aeth
(eval-when (:compile-toplevel) (loop)) ; for when you want to the compiler to infinte loop
9:21:55
russellw
It's an example. You see his point: the reader and compiler can both be instructed to run general code, which is an interesting and unusual feature. Most languages don't have that
9:22:23
aeth
(defun foo (&rest rest) (declare (ignore rest)) (loop)) (deftype foo () `(satisfies foo)) ; for when you want the type system to infinite loop
9:22:39
aeth
Shinmera: yeah, but usually the stated reason why you can't do these sorts of things in $language is to avoid infinite looping
9:23:33
aeth
Technically, I should be doing calls to my Brainfuck implementation instead, since that's a good proof of Turing completeness, but that's actually less fun.
9:24:13
Shinmera
russellw: if you can evaluate arbitrary forms the turing comleteness isn't surprising, it's obvious.
9:24:43
russellw
Shinmera, exactly. So it suffices to pick an example that demonstrates you can evaluate arbitrary forms in those places
9:26:16
aeth
Shinmera: Usually languages that offer compile time evaluation offer a restricted subset of the language or some other, restricted language.
9:26:53
aeth
Because they don't want turing completeness because they don't want things like infinite loops.
9:28:15
aeth
macro expansion, but that's kind of cheating because most languages don't even have that
9:28:48
russellw
C does, and does not allow evaluating arbitrary code in it, so I think that's a fair example
10:18:14
jackdaniel
bueuty of confusion, I've spent last hour writing a comment which strives to spare that confusion future generations
10:19:00
jackdaniel
comment is relatively short. I was just trying to first grok why it behaves the way I observe it
10:20:09
jackdaniel
(basically: x-origin/y-origin are relative to pen position in glyph coordinate system, which is the first-quadrant -- Y grow upwards), that's why we negate left distance and not top one
10:22:04
phoe
https://cdn.kastatic.org/ka-perseus-graphie/5ccb3c65bfc404595f924ce51a0ef166e2a17163.svg
10:23:28
phoe
I did not - yes, I understand what you mean, computer graphics often use fourth quadrant
10:29:56
phoe
Where exactly does the standard specify that (setf (find-class 'condition-type) nil) is the way to remove a condition type from the global environment?
10:31:28
Shinmera
In practice it is because usually conditions are classes, but there's no promise about that
10:32:18
phoe
So, I assume, there is no portable way to remove a condition from the global environment?
10:32:56
Shinmera
CL has real weird edge cases where some definition information is available only for certain kinds of definitions.
10:33:45
Shinmera
Reminds me, I should add a protocoll to Definitions to update or remove definitions.
10:34:06
phoe
Well then, I'll lead the implementation-defined behavior and assume that condition classes exist, no matter what they are.
10:40:24
no-defun-allowed
Is there anything describing why people shouldn't use the Unix "philosophy"?
10:42:20
phoe
beach: I know that SBCL, CCL, ECL, ABCL use condition classes. Only SBCL out of these four doesn't have conditions as standard-objects.
10:44:20
phoe
gendl: do you have access to LispWorks and ACL? Could you give us the results of (describe (make-instance 'condition)) on these two platforms?
10:50:51
beach
I would have expected the existence of a condition-object and condition-class just as there is standard-object and standard-class and also funcallable-standard-object and funcallable-standard-class.
10:54:17
beach
phoe: I don't think the fact that CONDITION is a standard class implies that instances of that class are standard objects.
10:55:15
beach
phoe: I mean, built-in-class is a standard class, and there are certainly instances of built-in-class that are not standard objects.
10:56:46
jackdaniel
phoe: making conditions standard objects (given you have clos already) is easy and you have no push from the standard to givem them a separate hierarchy like condition-class
10:57:35
phoe
jackdaniel: yes, and I actually enjoy the fact that they obey the instance creation protocol - I have my personal use-case for defining INITIALIZE-INSTANCE :AFTER on conditions which only SBCL doesn't obey.
10:58:26
jackdaniel
I'm not saying that such unification is bad thing, only that doing it that way is most likely due to a said laziness
10:59:48
jackdaniel
as of defining initialize-instance :after on condition - it is just not common lisp, so I'd hardly call it a bug
11:28:41
phoe
"...or defining a class by using defclass or define-condition automatically causes the name of the structure or class to be a new type specifier symbol."
11:30:48
|3b|
if i'm generating all the code at compile time (basically compiling a file that looks like "(foo:generate-all-the-code)"), is there any benefit to generating a defpackage form over generating code for building the packages incrementally?
11:31:32
phoe
DEFPACKAGE is much easier to parse by humans in case something goes wrong (and Murphy's law says it most likely will)
11:32:15
|3b|
(foo:generate-all-the-code) is literally the contents of the source file (probably better named and with argument, but still a 1 line macro call)
11:33:05
phoe
but if I ever were to debug code generated by a machine, I'd prefer a DEFPACKAGE where all package information is stored in one place rather than seeing bits of EXPORTs and IMPORTs thrown all over the place
11:33:08
|3b|
but i guess users can macroexpand it (and then watch emacs break on the 100+MB of output)
11:33:48
|3b|
well, probably would still be pretty close together, but probably not hard to build a defpackage form
11:34:17
|3b|
just don't want to put it in git (and also not sure about the legality of doing so once i thought about it)
11:35:44
|3b|
so rather than try to figure out the legality of shipping the jar or code derived from it (and deal with 100MB files in git, or making them smaller), i can just say "download the SDK or this file, and put a path to it here"
11:40:21
|3b|
takes ~30sec to compile from file, but hopefully that won't have to happen often. just loading the .fasl is ~1-2sec
11:41:14
|3b|
nah, seems like reasonable time for 100MB of source, and some of that might be my code being slow
11:42:36
|3b|
and if not, loading 4.5k packages from from a single .fasl file isn't really something i'd expect sbcl to worry about optimizing :)