freenode/#lisp - IRC Chatlog
Search
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
6:19:20
sthalik
beach, having passed some datum to the pattern-matching macro, have the compiler guarantee that all cases are taken care of
6:26:46
aeth
You can define a member type with a custom macro that also defines a custom ecase. The custom ecase can verify that every member in the member type foo is a clause in the foo-ecase macro and only members of that member type foo. At compile time. Afaik. It doesn't sound particularly hard, either.
6:27:13
aeth
Now, that's just a tiny part of the problem, but I think the basic solution form would hold. Generate a function and a macro in a macro, and call that function in the macro to verify that the macro is valid
6:28:02
sthalik
aeth, compilers like SBCL have inference done on the matched datum. can you access that?
6:28:54
aeth
I don't think you can access SBCL's type inference. At least, I haven't seen a library do that. You'd have to use type declarations if you can't.
6:29:24
sthalik
aeth, can a pattern-matching library like that access, say, CHECK-TYPE or DECLARE TYPE?
6:30:06
aeth
specialization-store, an otherwise wonderful library for type-based generic functions, cannot access anything other than type declarations from DECLARE as well as FTYPE declarations afaik.
6:30:22
aeth
If you haven't seen it, this is the library. https://github.com/markcox80/specialization-store/
6:31:03
sthalik
aeth, but a pattern-matching library won't infer (or access the info from the compiler) whether the pattern is exhaustible, will it?
6:32:32
aeth
I don't think there's any more information available at compile time than the information that's in introspect-environment, but I could be wrong. If there is, it would be incredibly non-portable.
6:33:14
aeth
I'm guessing there isn't more because there are libraries that could benefit from more.
6:36:25
aeth
If someone could port some of SBCL's behavior to CCL, it would no longer become implementation specific!
6:41:07
aeth
sthalik: What do you have in mind? Can you put some invalid code in a pastebin that you wish would work?
6:44:59
sthalik
aeth, rather, what's potentially recognized as valid that ought be guaranteed recognized as invalid
7:00:44
lieven
ACTION must have missed the many times Harrop was right. The arrogant part is spot on.
7:03:04
sthalik
lieven, people engaging in the arguments on Lisp's side made a straw man out of type systems so Harrop had an easy time
7:05:06
sthalik
aeth, Lisp side: type systems peak at C89. pattern matching doesn't improve program flow
7:07:50
jackdaniel
sthalik: unless it is a type based on `satisfies', then function associated with it may compare object with anything
7:08:30
aeth
sthalik: The built in typed conses are... lacking in many ways. However, most implementations now (or hopefully soon) enforce :type in slots on structs, so you can create your own typed cons.
7:09:43
lieven
the lisp side argument was mostly that lisp is a dynamic language and that so far attempts to mesh a static type system with it are clumsy.
7:10:10
aeth
sthalik: https://gitlab.com/zombie-raptor/zombie-raptor/blob/93ddd7250aba57a22817defadf6cc45176109926/util/util.lisp#L402-463
7:10:32
aeth
It's getting increasingly messy, though, so I might use inline specialization-store specializations instead of prefixes.
7:11:17
aeth
The core of it is just a three line defstruct to have a car of type and a cdr of (or null type-cons)
7:11:37
aeth
Yes, it's not as powerful as a Lisp cons and is only for lists. A separate kind of cons could be created for trees that has less guarantees.
7:13:35
aeth
Now, there's lots of things about type systems that are lacking in CL, but typed conses via structs seem to be doable. Probably even immutable ones with :read-only, although probably not useful without the language itself optimizing them
7:14:35
sthalik
technically one can "freeze" a definition but then it's the "sufficiently smart compiler" fallacy
7:17:27
aeth
I do think that if CL has a weakness it's in its limited set of collections available, especially lacking in immutability and non-generic versions (except for specialized arrays).
7:18:26
aeth
e.g. If CL had built-in hash tables that could only hold type foo, then the compiler would know on the GETHASH what the type is (if it knew the type of the hash table), which would remove a lot of declare/the/check-type/etc.
7:21:21
aeth
One problem with :element-type is that you can't e.g. store (integer 0 10), it'll round it to probably (integer 0 15) or something.
7:21:50
aeth
Sure, internally, it should round it, but it would be nice if it actually remembered you wanted to store (integer 0 10) so the type information isn't lost across the function boundary.
7:23:29
aeth
SBCL has sb-ext:*derive-function-types* which when enabled allows the non-standard behavior of assuming that the ftype of a function will never change.
7:24:44
aeth
It's good to have that option, but you still lose information in data structures like hash-tables and lists
7:24:48
sthalik
what's the purpose of statically-knowing the element type being fixnum between 0 and 10?
7:25:42
aeth
If for some reason you add (- most-positive-fixnum 20) or something, it knows it stays as a fixnum and so uses much faster arithmetic
7:28:51
aeth
I personally have a define-function macro, so in my game engine I would write it as (define-function foo ((x (integer 0 10))) (+ (- most-positive-fixnum 10) x))
7:29:45
aeth
Usually SBCL does a good job at deriving the return type and I don't think the other implementations have an ftype so I don't care about supporting return types. At some point I'd support it as an option
7:30:36
aeth
But I think that would require a third generated defun so I have been procrastinating that
7:35:24
sthalik
now that I think of, the argument-environment bits for a walker aren't even necessary
7:37:17
aeth
sthalik: Personally, I preallocate everything that I can and use dynamic-extent on the rest. This is a bit... eccentric and no one else in #lispgames has a game loop style remotely as restrictive as this.
7:38:20
aeth
This is for the engine's game loop only, though. I don't think I'd ever finish anything if I tried to use this style for the whole program.
7:40:32
aeth
Everything called from zombie-raptor/core/window::game-loop doesn't cons in SBCL. It's too hard to profile other implementations for this, and possibly impossible even if I could profile them.
7:41:14
aeth
(Obviously if I loaded assets while the game loop was running I wouldn't be able to keep this restriction to this extreme anymore.)
7:44:07
aeth
The way my engine is structured, it doesn't even load images! I have loaded images before in some of my unpublished tests, but I feed in the texture assets to the make-window function.
7:48:04
sthalik
in multiple C++ projects I've hit a roadblock where there's a decent amount of top-down design that can't go away
7:53:20
sthalik
even at this point there's no remote equivalent of lexical non-local return in fancy static languages
7:54:16
sthalik
aeth, what good are games if they're just iterative improvements? if it's ever done, it must transgress boundaries and do what was thought to be not feasible
7:55:06
sthalik
aeth, Falcon 4.0 included a persistent ground/air war simulation. post-mortem interviews explained "we didn't know any better"
7:57:24
aeth
I think the limiting factor is normally art. When the game devs don't care about art (e.g. Dwarf Fortress) they can do ridiculous things
7:58:03
aeth
On the other hand, when something's AAA photorealistic, everything is so expensive to make *and* you don't want to increase the risk by venturing too far from the formula
8:00:32
aeth
I plan on doing space games, at least for now. Space is mostly empty. No, even more empty than that.
8:01:50
sthalik
there's a modern maintained F4 derivative based on stolen code. current copyright holders allow it as a gentleman's agreement.
9:49:07
aeth
p_l: Well, #lispcafe does a very bad job at enforcing off-topicness and is often about Lisp.
10:46:46
thekolb
Xach: I have this weird situation where a dependency wants asdf3 but my quicklisp has asdf2? I did update-client but that didn’t upgrade asdf?
10:47:20
thekolb
(don’t ask me how I ended up with a dependency that wants asdf3 in the first place, good question though)
10:52:22
Shinmera
Also lots of dependencies require ASDF3 nowadays (for instance: all of my libraries)
11:00:42
jackdaniel
thekolb: asdf is not part of the standard (given how it constantly changes that would mean that our standard is progressing!). You may download lastest asdf relase, compile it and put (load …) in your .cclrc before loading quicklisp
11:19:36
thekolb
MichaelRaskin: the ccl package on NixOS is broken (doesn’t set CCL_DEFAULT_DIRECTORY)
11:22:20
thekolb
MichaelRaskin: CCL_RUNTIME has no effect on ccl whatsoever and seems to be a variable introduced by the Nix expression for referencing the kernel
11:23:00
thekolb
MichaelRaskin: CCL_DEFAULT_DIRECTORY is a variable used by ccl to refer t its installation destination
11:24:55
thekolb
MichaelRaskin: Not really, you should make sure that $(which ccl) sets CCL_DEFAULT_DIRECTORY appropriately and execs the kernel
11:25:57
thekolb
I.e., set CCL_DEFAULT_DIRECTORY in https://github.com/NixOS/nixpkgs/blob/release-18.03/pkgs/development/compilers/ccl/default.nix#L79
11:31:50
MichaelRaskin
env -i $(test-build -test ccl)/bin/ccl -e "(require :asdf)" -e "(print (find :asdf3 *features*))" -e "(quit)"
11:33:15
MichaelRaskin
If I don't pre-require :asdf, it is not found — again, with or without CCL_DEFAULT_DIRECTORY
11:35:52
MichaelRaskin
CCL 1.11.5 in master includes ASDF3 (even without CCL_DEFAULT_DIRECTORY variable set), maybe stable has an older one?
11:39:19
MichaelRaskin
Yes, and I have the change and I want to test one of these things before pushing to master
11:49:02
unanimousarc
Hello, new person here, if I invoke (ql:quickload x) will that package remain installed for future sessions?
11:49:11
thekolb
MichaelRaskin: I did nix-env -f https://github.com/NixOS/nixpkgs/archive/master.tar.gz -i ccl and ccl -n -e "(ignore-errors (require 'asdf))" -e "(quit (or (find :asdf3 *features*) 1))"; echo $?
11:49:50
MichaelRaskin
thekolb: I think CCL defaults to the image location if CCL_DEFAULT_DIRECTORY is unset; given the details of the Nix package that seems to mean the variable is irrelevant
11:49:55
phoe
unanimousarc: quicklisp fetches the dependencies from the network and then invokes ASDF to load the system into memory.
11:50:10
phoe
the former is persistent, the latter needs to be done after each reload of the Lisp image.
11:50:36
phoe
you can theoretically save the resulting Lisp image and then reload that one, but it's not commonly done during development - better to just #'ql:quickload things again.
11:57:06
MichaelRaskin
If you run «which ccl», do you actually get the version in the profile? If you just run CCL, what version is reported?
12:06:06
MichaelRaskin
Well, in a fresh test account I use your installation command (well, with -p, I have a complicated non-default setup) — it gives CCL which loads ASDF3
12:10:13
MichaelRaskin
Well, I could try to pastebin a nix-expression that imports from a fixed revision and checks CCL in build-time — failure-or-success of Nix builds is less environment-dependent than installation
12:13:27
MichaelRaskin
Does this also error: env -i /nix/store/32xnrnrf399nxf616fxihx00qi6xb4mv-ccl-1.11.5/bin/ccl -n -e '(require :asdf)'