freenode/#lisp - IRC Chatlog
Search
19:42:45
pjb
minion: memo for didi: there are downsides in using :type : then you won't be creating a new type, so it'll be harder to distinguish those structure instances from lists (or vectors). So you would do that, only when this would be the point.
19:47:14
aeth
On the other hand, you can manually deftype, but that's only practical for specialized arrays, not lists.
0:04:57
asarch
I'm trying to run the example from the "A Guided Tour of CLIM, Common Lisp Interface Manager"
0:18:54
pjb
Yes, define it! (cl:defun use (cl:&rest packages) (cl:apply (cl:function cl:use-package) packages))
0:20:31
pjb
Bike: asarch has a problem understanding packages and keywords and qualified symbols. He needs some play and exercises wiht them.
0:21:56
asarch
As far I understand: (defpackage :wasser (:use :clim)) (in-package :wasser) ... ;The rest of the code of the example
0:25:36
pjb
(defpackage "TEST" (:use)) (remove-duplicates (list (read-from-string "defpackage") (read-from-string ":defpackage") (read-from-string "cl:defpackage") (read-from-string "keyword:defpackage") (read-from-string "test::defpackage"))) #| --> (defpackage :defpackage test::defpackage) |#
0:26:40
pjb
(let ((*package* (find-package "TEST"))) (read-from-string "defpackage")) #| --> test::defpackage ; 10 |#
0:28:34
pjb
(let ((*package* (find-package "KEYWORD"))) (read-from-string "(cl:defpackage \"FOO\" (use clim))")) #| --> (defpackage "FOO" (:use :clim)) ; 32 |#
0:28:47
pjb
(let ((*package* (find-package "CL"))) (read-from-string "(cl:defpackage \"FOO\" (use clim))")) #| --> (defpackage "FOO" (common-lisp::use common-lisp::clim)) ; 32 |#
0:28:58
pjb
(let ((*package* (find-package "CL"))) (read-from-string "(cl:defpackage \"FOO\" (:use #:clim))")) #| --> (defpackage "FOO" (:use #:clim)) ; 35 |#
0:33:46
pjb
asarch: didn't you notice the fucking importance of the *package* variable for the meaning of what is read?
0:36:53
asarch
One step at the time: 1. I start a fresh session of SBCL. 2. Load clim: (ql:quickload "clim") 3. Load the pure code of this example: (load "example-02.lisp") and I get:
0:37:45
pjb
asarch: the stereotypical file will contain (defpackage "FOO" (:use "CL" "AND" "STUFF")) (in-package "FOO") …
0:38:42
pjb
if you want to type (use "CL"…) then you need *package* to be bound to the keyword package, so you need: (in-package "KEYWORD") (cl:defpackage "FOO" (use "CL" …)) (cl:in-package "FOO") …
0:39:52
pjb
asarch: again, read clhs in-package and clhs use-package closely, and underline each difference!
0:42:20
asarch
Ok. How would you fix this code? How would you write something like: #include <clim.h> and voila!
0:43:48
pjb
I explained you above the stereotypical file structure. Why cannot you apply it to your file? What's wrong with the sentence "the stereotypical file will contain (defpackage "FOO" (:use "CL" "AND" "STUFF")) (in-package "FOO") …" ?
0:44:38
pjb
What do you need to be told to be able to take a good example and reproduce it in your code?
0:45:52
pjb
Note that if error messages are unclear or ambiguous, in general maintainers will take bug reports about them and clarify/correct them.
1:14:11
pjb
FOr example, I could ask you what the standard says about a thing, but you wouldn't understand why I'm asking you about that thing, because you can't read an error message.
1:16:54
pjb
asarch: for example, we gave you the clhs use-package to read, but you still don't understand that packages such as the :clim package are not used IN the REPL, but used BY other packages.
1:17:31
pjb
(also incidently, you've been told from the start the solution, but you couldn't apply it).
1:22:10
asarch
So, an example would be fine. If I do: (defpackage :asarch (:use :common-lisp)) (in-package :asarch) I understand I am making available all the functions from :common-lisp plus the functions from :asarch, right?
1:27:11
no-defun-allowed
IN-PACKAGE also means all new symbols in the file or REPL will be interned into ASARCH.
2:09:54
pjb
no-defun-allowed: no, using packages doesn't intern symbols. Symbols can be interned only in their home package.
2:12:49
pjb
notice however, that you can intern a symbol with more than one operator (intern, of course, but also import and shadow can intern a symbol).
2:14:32
pjb
Also, contrarily to intern and shadow, and import can intern an existing symbol (if it has no home package).
2:24:28
asarch
So, in the example, (I was re-reading all my notes): Instead of writing (clim:make−pane ...) I could do (use-package :clim), right
2:26:04
asarch
However, if I do that, I get USE-PACKAGE #<PACKAGE "CLIM"> causes name-conflicts in #<PACKAGE "COMMON-LISP-USER"> between the following symbols: COMMON-LISP:INTERACTIVE-STREAM-P, CLIM-LISP-PATCH:INTERACTIVE-STREAM-P
2:26:17
pjb
As long as you do that in a package that doesn't already have symbols with the same name as the symbols exported by the "CLIM" package.
2:38:25
no-defun-allowed
pjb: i believe i said "new symbols ... [are] interned into ASARCH" and "all the symbols from CL [are] used in ASARCH" which is correct
2:56:32
mfiano
It is bad practice to use use-package a lot. The solution is to not use it, and allow your code to be more readable. Alternatively, shadow the exports or imports.
3:01:58
asarch
beach, would you please help me with this code?. I have a mess with the package part: http://paste.scsys.co.uk/581400
3:02:03
beach
asarch: In your package FENSTER, you need to :USE something that contains Common Lisp symbols too. Either :COMMON-LISP or :CLIM-LISP.
3:02:47
beach
asarch: But as mfiano says, I recommend against :USE-ing packages other than :COMMON-LISP (or in this case :CLIM-LISP).
3:03:39
beach
asarch: Also, the system to install from Quicklisp is not called CLIM, it is called MCCLIM.
3:05:43
beach
asarch: You will find a very small (but working) example of using CLIM here: https://github.com/robert-strandh/Compta
3:06:38
beach
But you can study the compta.asd file, the packages.lisp file, and you can look at how symbols are prefixed.
4:23:10
didi
Sooo. I want to use `assert' within `defsetf'. The problem is, the place I use inside `assert' turns into an `undefined variable'. I can do it, if instead of `defsetf', I use `defun (setf ...) ...'. Is there a way to use `assert' within `defsetf'?
4:23:10
minion
didi, memo from pjb: there are downsides in using :type : then you won't be creating a new type, so it'll be harder to distinguish those structure instances from lists (or vectors). So you would do that, only when this would be the point.
4:31:41
Bike
in the expansion function, ONLY-NUMBER will be bound to a symbol. the expansion of setf will bind that symbol to whatever. so it names a place.
4:34:14
didi
Oh well. I should have actually tried, instead of reading the macro expansion. Sorry for the noise.
4:41:05
didi
Ah, right. The trouble program is https://paste.debian.net/hidden/cf0b6b87 . The issue is with the function parameter, not with the new value.
4:42:08
didi
Now SBCL complains. If I try (setf (my-place 0 (list 1 2 3)) 42), "Variable name is not a symbol: 0."
4:44:14
didi
I guess if I want to use `assert', I will have to live with the #'(setf ...) function call.
4:49:51
didi
OK, `(let* ((n ,n)) (assert (numberp n) (n)) (setf (nth n ,list) ,value)) works, but at what cost? Maybe it's better to use (setf my-place) after all.
4:50:46
pjb
didi: I think that the point is that when you use defsetf it doesn't create a (setf foo) function, but setf expands the expression inline.
4:53:18
didi
I also noted that (nth 42 '()) evals to NIL but (elt '() 42) signals a condition. Weird.
4:58:06
aeth
Well I expect the main difference to be that NTH will have an error if not given a list and ELT will work fine if given certain non-lists
5:02:58
pjb
Well, one could expect that elt would still avoid calling length on lists. So it could return nil or signal an error at the same cost.
5:03:18
pjb
But since nth already returned nil, it was more interesting to return an error, just like in the case for vectors.
5:51:00
beach
Yes, but I don't understand your first question. Mainly because I don't understand the grammar of the sentence.
5:51:59
sthalik
beach, there was this basic idea that the standard's immaculate, and it doesn't need anything new ever, at all
5:54:07
beach
sthalik: Also, fast portable sequence functions: http://metamodular.com/sequence-functions.pdf