freenode/#lisp - IRC Chatlog
Search
2:03:50
jasom
emaczen: oh, I guess it's not part of the spec, see trivial-garbage for a portable library
2:22:17
jasom
https://github.com/jasom/ql2nix/tree/overlay <-- an overlay that contains ~75% of the systems in quiciklisp for nix; you should be able to use it to make working dev environments for projects on nix
2:32:21
jasom
it's not well tested (if the system loads with no errors, it gets included), *but* all foreign libraries that are loaded with the system should be correctly included
3:22:55
lexicall
Hi, I'm on OSX using sbcl 1.3.21 with slime 2.14 and I caught "Error while compiling ~/quicklisp/dists/quicklisp/software/slime-2.14/contrib/swank-sbcl-exts.lisp"
3:30:11
happy_gnu[m]
Look I have no idea because I am a begginer at programming, but usually GNU/Linux bistros come with everything packaged in a simpler way
3:33:56
pjb
(ok, it's a commercial unix system so it has a lot of problems (uncorrected bugs) like all commercial software, but still…
3:34:42
happy_gnu[m]
I didn't say it won't work on Mac I just said usually is easier to install things from GNu/Linux than mac
3:34:50
pjb
1- check your rc files. Don't load any thing provided by the packaging system if you used one to install sbcl!
3:35:07
pjb
(this is why using ccl is nice: no packaging system provides ccl! You have to install it yourself :-))
3:36:57
lexicall
I'm using homebrew, which installed slime 2.20 but I don't know exactly how to link that one with quicklisp or emacs.
3:37:12
takitus
It's silly to talk about how easy is to install things on 'Linux'. It depends entirely on which distro.
3:37:42
pjb
lexicall: remove the one installed by homebrew! Only use the one installed by quicklisp!
3:38:14
pjb
Notice I said MacPort, not homebrew. I didn't have had the same success with homebrew, to say the least.
3:41:20
lexicall
pjb: noting related to slime appears in my .sbclrc and LOAD-PATH was set to directory of slime 2.20 in .emacs.d/init.el. but emacs is still loading slime 2.14
3:42:24
pjb
In emacs, it's load-path not LOAD-PATH (emacs symbols are case sensitive and the reader doesn't change the case).
3:49:47
jasom
lexicall: macports has always been better for the softwae I use; I agree it's harder to use, but when the command completes successfully I find I'm much more likely to have something that works
3:50:30
pjb
Of course, there's a degree of personal task and experience in it. For example, I dislike that homebrew installs in /usr/local (this is MY administrative domain!), while I like that MacPort installs in /opt/local/.
3:50:58
pjb
There are also the packages and their versions. You may find what you want in one or the other, but there are differences.
4:00:08
lexicall
i think MacPorts always trying to download source codes and compile them natively, which wastes too much time.
8:31:05
phoe_
loke: so many interesting biochemical processes going on in your body at the moment, have you ever wondered or pondered about how your hairs grow?
8:34:31
Shinmera
I'm thinking some more about the planned rewrite of my CI system, but I don't consider that "very interesting". It is definitely something going on though.
8:44:47
beach
So I have this "intelligent macroexpand" feature in Cleavir. It takes the underlying Common Lisp expression of a concrete syntax tree (CST), calls the normal macroexpand function, and then tries to build a CST from the result and the original CST, in order to preserve, as much as possible, information about source location, present in the original CST.
8:45:15
beach
Now, I have pretty much decided that I want to compile LET by transforming the expression into a lambda form.
8:45:54
beach
I could do that by defining LET as a macro, counting on the intelligent macro expand function to preserve the source location as much as possible.
8:46:27
beach
Alternatively, I could transform the CST corresponding to the LET expression "manually" and then call the compiler on the transformed CST.
8:47:00
beach
In the second case, I am sure that I will get the source location right, but in the first case, maybe not.
8:47:39
beach
A third option would be to write a version of the PARSE-MACRO function that works on CSTs rather than on Common Lisp expressions.
8:48:31
beach
With this third option, I can write code as if I am writing a macro, but the resulting "macro function" would work on CSTs instead.
8:51:01
pjb
He writes: (defmacro let (vs &body forms) `(funcall #'(lambda ,(mapcar #'car vs) ,@forms) ,@(mapcar #'cadr vs))) ; but it's known to be overly simple. For example, you want to deal with declarations.
8:51:42
pjb
There may also be some other problems with the variables (eg. (let ((a 1) (a 2)) …) would expand to something that's is accepted, while this let form is bad.
8:52:08
pjb
There's also that call-arguments-limit doesn't apply to the number of bindings in a LET…
8:57:18
beach
Thanks for the link, by the way. I will definitely read the article with great interest.
9:03:25
beach
It would truly cut down on maintenance if I could find general technique in HIR to produce efficient code, even when these special operators are defined as in that article.
9:05:18
pjb
With some luck (ie. control flow and data flow analysis), you could perhaps recover efficiency in some cases; but I would guess that in general you would need to recover the meaning of the construct to compile them efficiently.
9:07:29
pjb
But if your optimizer is able to simplify and optimize eg. the condition handling thru multiple frames (including across multiple functions), I would say it would probably be powerful enough to do that.
12:28:39
mrSpec
Hi guys! I've got a question related to SLIME. When I go to method definition using M-. it opens *slime-xref* new buffer (fine!), when I select definition, slime points me the method, but instead of showing it in the buffer I came from, it uses the oldest buffer (so this is always not the one where I pressed M-. but the one where I'm looking at another file)
12:38:13
edgar-rft
There's e.g. Elisp (buffer-menu) for managing buffers like dired does for files, and I'm sure there are other built-in things...
12:40:07
Shinmera
edgar-rft: I don't want to have to do anything at all. It should just use a sensible buffer to display the result in instead of splitting things to hell.
12:44:39
edgar-rft
Shinmera: and I want a pony. Example: Using the same *buffer* means Emacs would have to delete the old contents of the buffer first and you would need to undo the deletion afterwards, is that what you want?
12:45:25
Shinmera
edgar-rft: This is software, I can just say what I want and it should be possible.
12:46:26
Shinmera
It's not what he meant because emacs terminology is confusing. He meant to reuse the same window.
12:47:14
Shinmera
Rather than the current behaviour, where it often will split the windows again or place the result buffer in some other random window.
12:48:57
Xach
ACTION wonders what to do about macroexpand-dammit, a project that never had an .asd file and whose site has stopped working
12:49:54
edgar-rft
Shinmera: You can configure Emacs to never split windows, or only split windows in any situation you like, or a bazillion other possibilities. That's what Emacs is famous for.
12:51:52
edgar-rft
the general stuff is here: <https://www.gnu.org/software/emacs/manual/html_node/elisp/Windows.html#Windows>
12:54:05
edgar-rft
...and here are the window-splittig options:<https://www.gnu.org/software/emacs/manual/html_node/elisp/Choosing-Window-Options.html#Choosing-Window-Options>
12:57:47
edgar-rft
Example for a list of Emacs buffer names that shall not pop-up: (setq same-window-buffer-names '("*inferior-lisp*"))
12:59:32
edgar-rft
Change number of buffers displayed in the toolbar's buffers list from 10 to 16: (setq buffers-menu-max-size 16)
13:02:14
edgar-rft
I have some function slike "switch to last visited Elisp buffer" and ".. CL buffer" if anyone is interested, but that is far more than oly one line.
13:03:21
mrSpec
because making *slime-xref* not pop-up won't solve the issue, and would create a new one
13:06:26
mrSpec
edgar-rft: ah no sorry. I'm looking for opening file (with function definition) in last visited buffer, not switching to last visited buffer
13:12:50
edgar-rft
mrSpec: an Emacs *buffer* is a piece of RAM holding the text, an Emacs *window* ist the graphic memory object displaying the text. Do you want to re-use the *buffer* (requires deleting the old text) or the *window* (does *not* require deletion of text in any buffer, only re-uses the GUI window for displaying a different buffer). In Emacs, this is an important difference.
13:19:06
mrSpec
I thought that when I split window I still have 1 window, but 2 buffers. Now I see that when I split window, I have 2 windows.
13:19:46
Shinmera
as in, you have frames which contain one or more windows, each of which displays a buffer.
13:25:48
edgar-rft
mrSpec: the Emacs terminology comes from the time when people still worked with text terminals. When GUIs became popular, Emacs already had occupied the term "window" for it's own meaning. That's why Emacs calls GUI desktop windows "frames". Not very clever, but it saved them from re-writing all the internals. It's a well-known and endless source of confusion.
13:26:29
dlowe
if only they had access to a decent text editor that would do search-and-replace on a lot of files.
13:27:20
edgar-rft
I still would like to come up with a workable solution, but I need to know what the exact problem is.
13:28:37
Xach
dlowe: I don't like getting an alert every day about a failure to fetch an update for it.
13:28:56
Xach
dlowe: so that means moving to sharplispers (and adding a system, readme, etc) or just dropping it and breaking a couple projects.
13:31:37
dlowe
If I had a project that depended on something like that, I would just want to get a notification that it was no longer maintained, and that I should switch to something else before it gets dropped.