freenode/lisp - IRC Chatlog
Search
3:53:09
beach
seok: In general, if you don't have a predicate like STRINGP, the way to check it is (TYPEP <object> '<type-descriptor>) so in this case (TYPEP X 'STRING).
4:02:42
ffwacom
the main issue is the package :iterate and :generators both define the #'next symbol
4:03:59
beach
And if the name of the package is too long, use package-local nicknames, now available in every significant implementation.
4:05:10
beach
By using explicit package prefixes, your code is easier to understand, because the person reading it can immediately see what package a symbol comes from.
4:44:42
White_Flame
ffwacom: there's package-local-nicknames, which is an extension that pretty much every lisp implementationhas now
8:07:26
beach
Do we have a collective name for the type specifier names AND, OR, EQL, MEMBER, MOD, NOT, SATISFIES, and VALUES.
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