freenode/lisp - IRC Chatlog
Search
9:26:06
beach
I'll just put "compound-only" in the name of the file in which I planned to put code for those type specifier names.
10:43:38
MrtnDk[m]
<phoe "if we can help you in anything r"> I'm mostly into scheme and e-lisp. I guess E-lisp and common lisp are very similar, in some ways at least, maybe not so much in other ways. I understand that CL is more complex.
10:44:58
MrtnDk[m]
phoe: I'm mostly into scheme and e-lisp. I guess E-lisp and common lisp are very similar, in some ways at least, maybe not so much in other ways. I understand that CL is more complex.
10:45:28
phoe
elisp most likely belongs to #emacs and scheme to #scheme and/or other channels related to the various scheme implementations
10:49:55
jackdaniel
technically speaking Common Lisp is LISP (unlike scheme which was designed from scratch)
10:52:39
no-defun-allowed
Time to go to #scheme and ask what operator changes the colour of the cat.
12:53:25
aeth
Emacs Lisp is essentially a historic Lisp in its design, and CL was designed to replace historic Lisps (rms disagreed, and hence we got the archaic-on-release Emacs Lisp), so that's why they're similar.
12:56:32
beach
Was work on Common Lisp as finished as that when RMS wrote Emacs Lisp? Where did you see this information?
12:57:39
aeth
Ah, CLtL 2 is 1990 and only the first CLtL (1984) was available in 1985. https://en.wikipedia.org/wiki/Common_Lisp_the_Language
12:58:08
aeth
It's in one of those histories of GNU (or Emacs) things online, so it would probably be pretty hard to find.
12:58:45
beach
I think he still is, but I doubt that it was as finished enough when he wrote Emacs Lisp.
12:59:15
aeth
phoe: Sorry, I'm used to search engines being trash these days even when I remember the exact phrases I'm trying to search
12:59:35
White_Flame
afair, CL was too big/complex to implement in emacs, so RMS took a simpler route
13:00:50
aeth
White_Flame: well, phoe's link says that RMS opposed some elements of its design, like keyword arguments
13:01:44
beach
I am not sure about that. I sometimes quote the email exchange I had with him when he first released GNU Emacs. I wrote something like "It would be better to first implement a real Lisp system, and then write Emacs in it" (since I had used Multics Emacs then), and he answered something like "Sounds good. Let me know when you have implemented it.".
13:02:38
beach
I just think he wanted Emacs released as soon as possible, and it would have taken longer to write a Lisp system first."
13:05:15
aeth
But then we have this from last year: https://sourceforge.net/p/sbcl/mailman/message/36659403/
13:06:26
White_Flame
or alternatively, pull python out of sbcl and use emacs lisp underneath instead
13:07:27
aeth
elisp-on-CL would be the way to go for that. There already is at least one of those attempts, but it wouldn't be hard to write a fresh one that meets GNU Emacs's expectations exactly.
13:08:52
aeth
Writing a smaller language on the larger language is the easier route. e.g. Scheme-on-CL is only really a few thousand lines while CL-on-Scheme is a large undertaking.
13:11:30
aeth
jmercouris: The only advantage of having elisp-on-CL in a fully GNU Emacs compliant way would be if people were actually going forward with the GNU Emacs on SBCL project which was in the mailing list a year ago
13:14:08
jmercouris
also, too many problems with assumptions made in existing elisp code, actual reuse would be trivial
13:15:42
phoe
elisp as a language is small, but then there's buffers, windows, all the stuff that is more emacs than elisp
13:17:47
aeth
No, it's not an optimal solution, but it will at least give you a working program. Then you can talk about rewriting.
14:08:39
MrtnDk[m]
That is one of the main issues I have with Emacs. It runs so slow on multicore machines, the same problems with graphical browsers, because they only exploit a faction of the available CPU's.
14:10:04
beach
The main problem with Emacs Lisp is that it is not compiled to native code, or at least it did not use to be. An implementation of Emacs in Common Lisp would make it possible to use one of the Common Lisp implementations that compile to fast native code.
14:17:06
aeth
Not being multithreaded is only going to be more of a problem each year. e.g. AMD's current Zen 2 desktop lineup: https://en.wikipedia.org/wiki/List_of_AMD_Ryzen_microprocessors#Zen_2_based
14:17:47
aeth
4, 6, 8, 12, 16, 24, 32, 64. Laptops are 4, 6, and 8. Intel isn't too different. Intel has a random 10-core for some reason.
14:18:20
aeth
I'm not sure how much of it is elisp and how much of it is deeper built-in assumptions into Emacs, though
14:18:45
aeth
So even moving to SBCL wouldn't necessarily make Emacs work multithreaded, at least the core
14:20:24
beach
There is something going on though. One can use editing commands while a process is filling up a buffer, say with compiler messages.
14:20:46
phoe
beach: one can tune an incremental GC to have pauses that are tens of milliseconds long; suitable for soft real-time applications.
14:21:35
beach
phoe: The point was, if you want to take advantage of a large number of cores, then stopping ever thread is not so great.
14:23:08
aeth
phoe: 10s of ms sounds horrifying to me. That's a dropped frame or two with a 60 Hz monitor, which seems like it would be noticable.
14:24:39
TwoNotes
I keep getting EOF conditions raised by read-from-string. Does it have a problem wiht long strings? (Like 500 bytes)
14:25:28
aeth
beach: What order of magnitude of time does audio work with? I'm not familiar with audio.
14:26:15
bobross
Could someone help me with cl+ssl? I'm unable to read from the stream and I can't understand why. It seems to hang until the connection is closed, then receives the request at that point.
14:26:44
phoe
bobross: is the request-sending part finishing its output before it closes the connection?
14:27:19
bobross
Not on my end. But I also tried with an external application and had the same issue (well, my "client" in Lisp signals an error...)
14:29:23
beach
aeth: The problem is that if you use real-time audio, like for a synthesizer program, the ear is very sensitive to delays, so you can't fill the audio buffer too much. Then you need to react very fast when the buffer is about to get empty.
14:30:33
beach
In fact, the standard Linux kernel can't handle a synthesizer program correctly. It requires special kernels options.
14:30:40
bobross
https://bin.privacytools.io/?1bfac7ec8036a25c#iDiwwxT7hu3R2UZ6vaKsnna/LLtrzBQDj0IaLi8a2gg= this is the code, if someone could have a look. Trying to handle the connection in 'ssl-handler'
14:32:18
phoe
if cl+ssl handles this correctly, then this will flush the buffers and send all data stored there to the server
14:34:44
phoe
bobross: does that come from the client or the server? could you paste the stacktrace somewhere?
14:35:36
bobross
As far as I can tell it comes from trivial-utf-8:read-utf-8-string. Will post stack trace, 1 moment.
14:36:20
bobross
https://bin.privacytools.io/?89260da78d6ba548#LfRQc/oOOxDH61J9k5yoRAsJlg8mctnYK9ErIe0qfsY=
14:37:09
bobross
Yea, I'm using trivial-utf-8 because the application I will use it for needs to use UTF-8 encoded messages. But really, that call could be replaced with a "read-bytes" of some sort. Not sure how to do this in CL.
14:40:00
bobross
Hmm. What's strange is that earlier I managed to read the request after closing the connection of the client (using an external application for the client)
14:48:05
bobross
A side note: when using the 'bombadillo' client I can send a request with 'bombadillo gemini://127.0.0.1:61111/test', which hangs, but once I ctrl-C the request is received successfully
14:50:32
bobross
Honestly I'm not sure. I found the documentation a bit vague. But the clients I mentioned in the previous comment should setup TLS correctly.
14:52:40
bobross
I've looked at that code, and from what I can tell the primary difference is that in the handler 'cl+ssl::*ssl-global-context*' is set directly, and that 'read-line-crlf' (from cl+ssl docs) is used to read from the stream. I couldn't get the 'read-line-crlf' function to run on my end
14:53:43
bobross
There are some short examples for cl+ssl here: https://github.com/cl-plus-ssl/cl-plus-ssl/blob/master/example.lisp
15:47:52
bobross
phoe: After some fiddling the error stops when not using '(usocket:socket-close socket)' on the client, and the request can be read by looping read-byte
15:49:24
bobross
Yep I agree. I would have thought you could read a "TCP message" completely with a single command?
15:50:27
phoe
I think there might be some sort of weirdness happening if you pull the carpet from under cl+ssl while it does its work - that's why I suggested first closing the tls-stream and then closing the socket stream
15:53:25
bobross
Still getting the same error in that case. But from how I interpret the documentation https://common-lisp.net/project/cl-plus-ssl/ the stream should be closed automatically
15:55:45
bobross
TwoNotes: so since it is a byte stream it is not possible to "read the single TCP message" without reading byte by byte and detecting the end of the message?
15:56:49
phoe
ultimately, TCP is a stream protocol, meaning that you get a stream of bytes instead of a stream of messages
15:57:11
phoe
that's different than e.g. UDP, where each packet is its own message, or SCTP, which has a concept of messages.
16:00:41
phoe
when working with raw TCP sockets and nonetheless doing messaging over the stream, usually you read whatever you can and then check if you can "pop" a complete message off the stream
16:01:19
phoe
if you do so, you copy it from the buffer, send into the system, and flush the buffer to remove the already processed bytes
16:01:39
TwoNotes
protocols built on top of TCP define their own 'message' boundaries. Some use prefix byte counts
16:02:10
bobross
So what you mean is that I create in Lisp a "buffer" (e.g. array), read byte by byte, stop at some point, convert the message to e.g. string, then handle it?
16:02:55
TwoNotes
Yes. Just remember that when you start doing that, the end of your 'message' may not have yet arroived over the stream.
16:03:25
TwoNotes
A TCP impolementation that delivers data to you two bytes ata time is perfectly valid.
16:03:58
bobross
Right, but they are guaranteed to be in the correct order due to the protocol right?
16:09:20
bobross
Thank you both very much. Btw I get an error when trying (read-line ...) https://bin.privacytools.io/?043fafaff2b73aab#hGRcZWXG7y/LsZvbrlBxJAr2aRkQWeOS7c8qPxjxON4=
16:12:44
bobross
I will try a similar approach to read-line-crlf in https://github.com/cl-plus-ssl/cl-plus-ssl/blob/master/example.lisp I guess
16:15:32
phoe
https://github.com/cl-plus-ssl/cl-plus-ssl/blob/2b823f11ec69f32ebb94bb96031682009374d4f7/test.lisp#L181
16:20:18
phoe
you could try passing :external-format '(:utf-8 :eol-style :crlf) to the created stream and use characters/strings
16:20:20
bobross
I'm trying to implement a Gemini server following the protocol, which says all headers must be UTF-8
16:20:59
bobross
Oh I see. I will try that later, thank you! Really need to go to walk my dog. I might drop by later.
16:51:59
rogersm
On windows, .dll files should be put in one of the directories listed in the PATH environment variable.
17:25:23
bobross
phoe: Reading/writing through the TLS stream seems to work using ":external-format '(:utf-8 :eol-style :crlf)" as you suggested!
17:58:54
emacsomancer
for SBCL compiled binaries, what is the source of a "Can't find core file relative to ...." error?
18:04:47
max3
"a Symbol identifying the kind of expression. A symbol is an interned string identifier (more discussion below)."
18:18:00
axion
We wanted all of our game algorithms in one repository/system, so there is only a single system now.
18:18:15
pjb
minion: memo for beach: quicksort optimization (branchless Lomuto partitioning): https://blog.reverberate.org/2020/05/29/hoares-rebuttal-bubble-sorts-comeback.html
18:22:53
axion
There was a backwards-incompatible change with all my Quicklisp releases anyway, in that I adopted reverse domain name notation for system/package names, now that PLN is widespread enough, as some of my systems and packages were rather generic and not fair to the ecosystem and Lisp image
19:00:35
emacsomancer
maybe related to the "can't find file relative to core..." errors, does uiop:run-program expect a full path (for a compiled binary)? [e.g. is (uiop:run-program "bash") ok, or should it be (uiop:run-program "/usr/bin/bash") ? ] - I would have assumed it would just check the relevant $PATH
19:15:13
phoe
wait a second though - could you paste the full error along with the stacktrace anywhere?
19:16:38
emacsomancer
phoe: I'm getting reports from someone else, so this is all I have currently: http://dpaste.com/0PNDSZ8
19:17:27
emacsomancer
(I'm still wondering if asdf:progam-op shouldn't be sufficient - e.g. next browser (which is relatively complex with a number of moving pieces) builds everything with asdf:progam-op)
19:19:54
emacsomancer
when I build and run on my own system, they run find, no matter where I run them from
20:13:31
bobross
phoe: Another update... Successfully managed to load a file with an external Gemini client now :D
20:27:14
_death
hmmm.. define-modify-macro in the clhs takes a parameter named "function" which is a symbol.. but I don't see anything saying it should be the name of a function.. since it shows an equivalency I claim it should work with names of other kinds of operators as well, say (define-modify-macro andf (&rest args) and) .. apparently the message introducing d-f-m ( http://cl-su-ai.lisp.se/msg05411.html ) uses that name and it's just been kept
20:27:15
_death
as-is.. I don't yet understand the define-setf-expander ("define-setf-method") example there btw..
20:30:42
bobross
Will do! I am planning to make the source code available when I feel it's in a good state... Will let you know at that point
20:43:40
Bike
_death: the define-setf-method thing seems to be defining a destructurer. like (let (x y) (setf (cons x y) (list 1 2 3)) (values x y)) => 1, (2 3)
20:48:41
_death
that makes sense.. but what functionality does get-destructuring-backquote-setf-method give (as opposed to get-setf-method/expansion) .. maybe it's more like (setf `(,x ,y) ...) ?
20:51:30
pfdietz
Xach: I will deal with that finalize-inheritance problem in sel within the next couple of days. It's problematic.
20:56:55
_death
Bike: I guess it was still not exposed.. it's a good question whether get-destructuring-backquote-setf-method is actually get-setf-expansion