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.