freenode/lisp - IRC Chatlog
Search
3:18:55
aeth
Oh, fun fact: define-function is no longer portable because (length (documentation 'define-function 'function)) is 2565 and ARRAY-TOTAL-SIZE-LIMIT "is not less than 1024"
3:31:06
capadoodle
is it better style to explicitly call out the package that an external symbol is from when used within your package? `package:function` rather than just `function`? Right now my package only depends on clim
3:35:43
aeth
capadoodle: There are three styles, each with drawbacks. You can :use a package, you can :import-from specific symbols from a package, or you can explicitly use the symbols like you said.
3:36:30
aeth
capadoodle: The disadvantage of :use is that even though there is no current conflict, a symbol could be added in the future creating a future name conflict. The disadvantage of :import-from is that you have to list every symbol you're going to use and it's easy to forget to remove it from the import if you're no longer using it (no tool currently detects this afaik).
3:36:52
aeth
capadoodle: And the disadvantage of always saying the package name is that the package name can be very long and nicknames are discouraged because nicknames can name conflict, especially very short nicknames.
3:38:48
pfdietz
:use also has the danger that you may accidentally redefine something with that symbol.
3:41:11
aeth
Fortunately, redefinition of functions and macros can give a warning (depending on the implementation) so at least you can detect that.
3:43:04
capadoodle
makes sense, I think I'd be partial to always saying the name, especially for clim which is so short already. the documentation for clim recommends using clim and clim-lisp rather than CL :( why is that? seems potentially shady
3:54:17
beach
I think CLIM-LISP makes the same promise as COMMON-LISP, i.e. no new symbols will be added, and only symbols with the same names as those in COMMON-LISP are present.
3:55:06
beach
Besides, your program would look very strange if you had to write CLIM-LISP:CAR, CLIM-LISP:IF etc.
4:28:06
asarch
How could I know the current version of ASDF (for example, from a running session of clisp)?
4:29:03
asarch
"/home/asarch/quicklisp/dists/quicklisp/software/bordeaux-threads-v0.8.6/bordeaux-threads.asd: You need ASDF >= 3.1 to load this system correctly."
4:30:25
beach
asarch: Normally, you don't have to care. If you install a recent version of your Common Lisp implementation, it comes with an appropriate version of ASDF.
4:32:07
beach
asarch: Do you have any particular reason for using CLISP rather than one of the more widespread implementations?
4:35:10
asarch
Well, all my attempts to have SBCL with threads on OpenBSD 6.4 for AMD64 have miserably fail
4:37:43
beach
But I don't know much more about it. I am suggesting ECL because jackdaniel maintains it and he is often here, so you can ask him questions.
4:50:21
aeth
(Also, the developers from some currently incomplete implementations like Clasp and SICL)
6:01:06
beach
In splitter.lisp, you violate one of the rules of the LUV slides by Norvig and Pitman, in that you use WORKLIST as a Boolean variable, but it is a list. It is better to write UNTIL (NULL WORKLIST) instead of WHILE WORKLIST.
6:02:41
beach
It is more common to put the LOOP keyword first on a line, rather than last on the preceding line.
6:03:10
beach
To make that work, you need the SLIME-INDENTATION contribution, or your loop clauses might not have the right indentation.
6:07:05
beach
Otherwise, it looks idiomatic to me. I haven't looked at the program logic, though. Just checked for idiomatic constructs.
6:07:40
elderK
One thing I'm not happy with, is how I have duplicated the "for y below.... do for x below ... " stuff quite often.
6:07:59
elderK
I initially had a function, on-each-cell, but that would up being more a PITA to use than just, duplicating the iteration.
6:08:19
elderK
I.e. I had to define a function with lambda or flet, and pass it into say, on-each-cell.
6:09:07
no-defun-allowed
(loop for VAR below NUM do THING) can be replaced with (dotimes (VAR NUM) THING) to save words
6:09:08
elderK
One thing I would like to know: What is the convention for functions that alter their input? I'm used to the form "something!" from Scheme, if something mutates one of its arguments.
6:09:59
no-defun-allowed
i wrote a macro for cl-vep which did a similar thing, mapping an expression over one or more three-dimensional arrays
6:10:47
elderK
I'm not particularly happy with the splitter code. Like, it seems like its doing a lot. I'd like to factor it out further, but I couldn't think of any good names for its pieces.
6:11:18
elderK
It wound up being simpler to keep it as one unit, rather than try to b reak it apart :(
6:13:23
elderK
Is it idiomatic to have do on a line of its own? Or do you have thing slike, do (.... stuff ....)
6:15:32
elderK
slimv's not bad :) Not as awesome as SLIME perhaps, but it is pleasant enough to work with :)
6:15:59
elderK
Ah, okay. I was thinking like, maybe using and would be better or something. Like, I figure the with ... and ... is like let. And with ..., with ... is like let*
6:17:00
|3b|
ACTION thinks AND suggests it matters which you used, so WITH is easier to parse mentally
6:17:53
elderK
beach: I know I should probably learn Emacs and just use SLIME proper. Iono. I'm very attached to vim.
6:19:17
elderK
Still, if necessary, I don't mind correcting it. It autoindents pretty well for the most part. It just doesn't seem to have rules for loop.
6:20:46
elderK
:) I'm enjoying using Lisp so far. The C++ version of this program is much, much, much larger. Even at the same "feature point"
6:21:19
elderK
I'm starting to get used to navigating and parsing CLHS, too. Thank you again for referencing me to the description of the grammar CLHS uses.
6:39:44
beach
I have an idea. I should recruit all the vim users that program in Common Lisp to help out with Second Climacs. That way, they can have their favorite key bindings, modes, and whatnot, at the same time that they get a programming environment that is superior to that of SLIME. :)
6:43:18
|3b|
ACTION suspects vim users run fewer large applications (irc, email, etc) in their editor too, so possibly easier to get them to switch once it is usable for lisp code editing
6:50:54
elderK
Iono. I know that Emacs is a lot better for Lisp development but, man, I've been using Vim for so, so long. I imagine I feel about it, as you do about Emacs - it's almost like an extension of you when you work. One day, I /should/ learn Emacs. But for now, I'd like to focus on playing with Lisp itself :)
6:51:07
beach
One more argument: Emacs is written in (Emacs) Lisp, so Common Lisp programmers can probably modify it and add features to it fairly easily. I imagine users of vim who program in Common Lisp would love to have a vim-like editor written entirely in Common Lisp.
6:52:08
elderK
And tbh, a lot of "interactive repl" type stuff in Vim is usually pretty... flakey. Particularly as "asynchronous stuff" was only added reasonably recently.
6:53:29
elderK
I'm thinking my next "experiments" in CL will be to make a basic graphical program with a "little" binding for SDL.
6:54:40
elderK
I suppose I should finish the current "experiment" though. I still have to add support for say, reading worlds from file, etc.
6:56:58
elderK
It's not that I have anything against McCLIM. It looks to be an impressive piece of work. If I were developing something GUIish, I would definitely opt to give it a shot. But, for now, it looks to be far more than I require.
6:57:35
elderK
:) CL might be easily become my language to like, make GUI in. I abhor Java's Swing. And, I never bothered to learn Qt.
6:57:37
jcowan
elderK: The name `null` goes back to the earliest days of Lisp 1.0; it has never been nullp.
6:57:59
beach
elderK: If you work on your own stuff using FFI and SDL bindings, you will get work done perhaps a bit faster, but it won't benefit the community.
6:58:32
beach
elderK: But if you work on or with McCLIM, you might take a bit longer to learn it, but it will have an impact to other people here as well.
6:59:50
jackdaniel
but yes, more hands to help with McCLIM is welcome, you'll be able to brag that you work on technology older than you ;) many interesting parts of code (educational-wise)
6:59:57
elderK
I'd like to help the community. But I need to be comfortable in Lisp before I start on that path.
7:03:00
jackdaniel
there are two ways to have it working: 1) create opengl backend (harder); 2) create a custom opengl gadget (easier)
7:04:02
elderK
That's probably something I should learn about before I begin on any kind of binding :)
7:08:17
jackdaniel
|3b|: I imagine that would require some piping to extract drawable from clx window and pass it to the library doing the opengl to use it
7:09:36
|3b|
ACTION thought there was some problem with the protocol getting out of sync when you mixed CLX with FFI GL, but i guess you could create a subwindow with ffi or something
7:10:42
jackdaniel
well, I certainly didn't take that into account when I've made a suggestion, I'm wasn't aware of clx <-> ffi problems
7:14:49
|3b|
been a long time since i've looked at mcclim, so possibly i'm misremembering things, or someone was doing things wrong to cause problems in the first place :)
7:15:26
|3b|
ACTION wants option 1 anyway though, since i don't have any X at the moment, and want to display on things that aren't normal 'screens' anyway :p
7:17:42
jackdaniel
start lisp image with mcclim preloaded*. how does it fail? did you report an issue?
7:22:00
beach
LdBeth: Oh, sorry, the listener starts additional threads, so the image can't be saved. But dumping an imagine with (say) Clouseau works fine.
7:24:45
beach
LdBeth: I was saying that once you load the listener, SBCL can no longer save the image.
7:26:30
no-defun-allowed
does it start a thread to run the CLIM loop? iirc you can still eval stuff in stdin/slime
7:27:01
beach
I was able to do (asdf:load-system :clouseau), then (save-lisp-and-die...), then run SBCL with the new core, and finally (clouseau:listener '(a b c))
7:27:31
beach
no-defun-allowed: I was not running any CLIM application, just compiling the listener.
7:29:00
beach
Inline: I think I just reported an experment where "just loading all the libs" resulted in failure to save the image.
7:31:43
beach
LdBeth: I take that back. It is indeed possible to save the image with the CLIM Listener pre-loaded.
7:36:10
LdBeth
Is it possiable to do something so save image after running a mcclim application won't has problem
7:37:39
Inline
i just define all the stuff to run and invoke a top-level :eval (cl-user:run) from one of my scripts
7:37:58
beach
LdBeth: SBCL is unable to save an image if several threads are running. So what Inline does is to avoid starting additional threads before saving the image.
7:45:27
LdBeth
I don't mind to use a script since loading compiled code is still fast, though someone had shown some concerns about distributing a McCLIM application
7:48:26
Inline
once it has compiled stuff over to .cache/common-lisp the next start is even faster....
7:51:03
Inline
sbcl --core blah --load quicklisp/setup.lisp --userinit createnewlim4.lisp --eval (cl-user::clm)"
7:54:13
beach
LdBeth: So can we agree that there is no McCLIM-related problem when it comes to saving and distributing images?
8:02:11
beach
I'm confused. I thought LdBeth indicated a problem, so I spent this time trying to confirm it, but found that there isn't one. Then LdBeth says "for me it works perfectly fine", and I don't know why I spent all this energy.
8:04:11
Inline
i suppose one should abstain from asking further in such a state and abstain from providing answers too
8:06:34
|3b|
beach: sounded to me like the problem was in usage rather than mcclim and your effort helped resolve it
8:07:26
|3b|
though possibly with a "it would be nice if mcclim could shut things down enough to dump a core" on the side
8:08:04
|3b|
ACTION has no idea if that is possible or not though, or if starting threads breaks cores even if they all shut down nicely
9:50:55
pjb
gorgi: I don't know, but I could find out. Try to find out yourself, it should not be that hard.
9:53:14
pjb
Following some links you get to https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lisp.html
9:54:18
pjb
The last google search that led to that was: org mode how to specify block code language
10:54:09
gorgi
pjb: I already tried that. I didn't say so because long questions including details like that tend to be ignored. All that does is create a new variable. I've tried modifying ob-lisp.el.gz, but it won't let me.
10:59:33
pjb
gorgi: if it creates a new variable, it means you don't have the right version of org-babel.e
10:59:51
pjb
If you have a more recent version, then you will have to find the new mechanism. If you have an older version, then upgrade.
11:05:13
no-defun-allowed
It's pretty simple, I want to write some stuff to it via a stream and see what it responds with and what it does.
11:06:01
no-defun-allowed
How could I feed it using a kind of "null modem"ish stream? I want to read and write from one end and on the other (but in reverse).
11:06:50
no-defun-allowed
So far the best solution I've thought of is using string streams and a twoway-stream since I can use any number of streams, as the protocol is relatively stateless. Is there a better way to make such a "null" stream?
11:09:48
no-defun-allowed
https://en.wikipedia.org/wiki/Null_modem might be relevant for anyone who's never seen one before. Wait, that's me. ):
11:11:18
|3b|
(looking at the docs for it, probably not unless you need binary or bivalent streams instead of string streams)
11:11:48
no-defun-allowed
Yeah, I just need to work with text, in a way that somewhat replicates a TCP socket without spinning one up preferably.
11:12:23
no-defun-allowed
After making the event loop into an event handler, I can single-step events so I'll just make one, handle one and repeat.
11:59:35
jebes
god to think i'm employed as a dev and highschool was 4 years ago :/ I don't think that's supposed to happen
12:54:21
elderK
Guys, when should you create and use your own conditions? Starting out, I'm not really sure how to signal problems in the Lisp way
12:54:56
elderK
There seem to be many ways to signal errors. So, like, getting a feel for when to use what, would be useful.
12:55:29
pjb
elderK: first you should note that the condition hierarchy in a program is often as numerous if not more than the program class hierarchy.
12:56:26
beach
elderK: In SICL, the idea is that I always signal a particular condition. That way, client code can handle each one separately.
12:56:58
pjb
But then, you may notice that a lot of implementation define an implementation specific set of simple-error and simple-whatever condition, that in addition tot he standard parameters, take a format-control and format-argument string to display a nice simple error message.
12:57:19
beach
elderK: Sometimes I am lazy and I signal a simple-error or something like that, but it's a temporary solution when I am in a rush.
12:58:10
pjb
The question is when you want to catch and handle those errors. This is when you want the most precise condition class, with the most useful slots.
12:58:38
pjb
You cannot count on a format argument list to extract the parameters of the error to process in a handler. This is too brittle.
13:00:36
pjb
And finally, if you create a condition class, it becomes part of the API. client code may expect to receive this condition from time to time. If it never occurs, useless code may be written, transitions not taken and program not working.
13:00:54
|3b|
ACTION thought format-control and format-arguments were part of standard simple-condition
13:01:11
elderK
I guess I'll look around on Github, try and see how often people do like, condition stuff. To try and get a feel for how I should write my stuff.
13:02:24
pjb
elderK: you'd start by using (error "message ~S" argument). Then when you try to handle errors, you will notice what specific errors you want to deal with, and define conditions for them.
13:03:52
pfdietz
I also suggest you do not count on the errors provided by the implementation. For example, (car x) is supposed to throw a type-error if X is not a list, in safe code. But in code with safety < 3 anything could happen.
13:04:36
pfdietz
Using assertions to signal errors rather than as signs something has gone horribly wrong with your program is also bad.
13:04:36
pjb
Yes, CL is way too underspecified about conditions signaled. They're a late addition to the standard…
13:05:17
pjb
pfdietz: this is discutable. assert signals a continuable error when you give places to modify in restarts…
13:05:26
|3b|
ACTION would count on errors from (car x) for safety > 0, and not use any implementation where it doesn't :p
13:06:24
pfdietz
The restatability of asserts is another reason not to use them as error signals, if you don't actually want that restartability. Lots of code gets generated. Internally, SBCL uses AVER which skips the restarts.
13:08:54
pfdietz
I put in a wishlist ticket for SBCL to mark all error signalling code as "cold" and try to move it out of line with other code, so it doesn't clog the instruction cache.
13:09:50
elderK
Well, I'll make sure to use check-type at the "top level" of my stuff. Assertions and things too as per usual. But, those are for me, not for the users.
13:12:55
elderK
I've just been using check-type like an ordinary kind of function, before I do "the stuff" :)
13:13:14
pfdietz
A declare is an assurance to the compiler about what the values of variable will be. The compiler could use it to optimize away the check.
13:14:16
|3b|
(if your implementation isn't smart enough to figure that out for itself, sbcl usually is)
13:14:56
pfdietz
And if A is never assigned to, you don't need the declare. Type propagation from check-type should do what you want.
13:36:12
elderK
I find check-type useful, as it prevents you know, stupid mistakes. And also adds documentation in a sense. Assertions for more "stupid mistake" checking :)
13:42:12
void_pointer
elderK: I think most people do it when the API has converged a bit and they need more performance.
13:43:25
elderK
It seems like, unless you really really need the performance, adding them is like, polish )
13:44:07
elderK
I was also wondering how expensive destructuring-bind is for simple.. destructuring, like, extracting stuff from a cons pair and stuff.
13:44:27
void_pointer
forcing the numbers to say be a fixnum means that you can't handle big integers where the definition of big is implementation dependent
13:45:11
void_pointer
declarations do indeed make it harder to refactor since you have to track them all down, especially for things passed between many pieces of code
13:45:25
elderK
Makes sense, tag requirements etc, impl-dep. And like, they probably would be on 64bit, but not on 32bit.
13:45:44
elderK
beach: Ah, good. So, unless I'm doing something really heavy, I shouldn't feel too bad about using it?
13:46:31
void_pointer
elderK: on most systems, the size of a fixnum is a signed integer with a number of bits equal to the pointer size minus a few bits. So on 64 bit systems, it is often something like 60 bits. On 32 bit systems, it is often something like 28, 29, or 30 bits