freenode/#lisp - IRC Chatlog
Search
7:19:42
jdz
I might be misremembering exact figures, but according to Microsoft around 80–90% of security problems (remote code execution) are due to memory management problems (buffer overflows and use-after-free).
7:21:15
jdz
Here's one from a quick interwebs search, that quotes 70%: https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/
7:31:26
jdz
And instead of improving the tools (i.e., programming languages/runtimes), they push the burden of securing software to kernel/hardware.
7:39:22
Shinmera
I mean, if y'all are gonna hoot and holler about unsafe, let's talk about people using safety 0 in Lisp.
7:40:32
no-defun-allowed
I should stop but a lot of the standard library uses unsafe, probably moreso than Lisp
7:40:49
shka__
Shinmera: safety 0 in a hot function can make sense, the problem is that sometimes it is used accross the whole project
7:41:30
no-defun-allowed
We were bitten by safety 0 in jsown quite a bit. Got unhandled memory faults and all cause we wrote (:obj (stuff)) instead of (:obj . stuff)
7:41:32
jdz
And sometimes people think their hot loop is correct and use safety 0 and then it turns out it's not.
7:45:00
no-defun-allowed
loke: I also have to stop with this too, but it sounds very anti-Climacsictic.
7:45:06
loke
Duuqnd: It's a typical “let's rewrite it in rust” project. Just a bit more stupid than the others.
7:45:35
loke
Anyone who actually _understand_ Emacs understands that the goal must be to get _rid_ of the low-level code. Not replace it.
7:46:02
no-defun-allowed
My favourite is the one that rewrites GNU Hurd basically, but it's actually vaguely usable (not to the extent of Mezzano, no quake), but it's still trash cause Unix.
7:46:56
no-defun-allowed
Then when it was time to learn redox reactions in chemistry class I had flashbacks. Never got the hang of chemistry either.
7:47:02
jdz
loke: Better as in they've been talking on Emacs mailing list about moving to Common Lisp (for performance reasons).
7:47:16
loke
Duuqnd: That's the thing, they don't “work” on the Emacs code. They don't even understand it. They just mechanically replace function with the Rust workalikes. Whcih also explains why most of these fucntions have ‘unsafe’ in them.
7:47:48
loke
jdz: Yes, that has at least been mentioned. Although the likelyhood of that happening is also absolutely tiny.
7:48:17
loke
But... at least it's nonzero when looking at a 20-year horizon. The likelyhood of Remacs becoming something better than real Emacs is zero.
7:48:20
no-defun-allowed
I also heard about troubles with unexec (similar to sb-ext:save-lisp-and-die but it also has to deal with the C side) too.
7:48:41
loke
no-defun-allowed: unexec was removed in the recent version of Emacs. They use the portable dumper now.
7:49:40
loke
The portable dumper basically portably serialises the object graph and writes it to a file. When emacs starts it can use that heap dump to pre-populate the heap.
7:50:16
loke
Another benfit is that you can dump the heap at any time, creating a snapshot of an emacs session that you can load later (there is a flag to Emacs that tells it which dump file to load)
7:51:46
loke
Duuqnd: I don't think the goal sound be to replace GNU Emacs in the general case. The goal should be to be useful to at least a nonzero number of users.
7:52:35
Duuqnd
Yeah, that makes sense. It's just that there's a lot of Emacs packages that my workflow kind of depends on.
7:53:20
Duuqnd
What would be nice would be an Emacs clone written in Common Lisp with some sort of semi-automatic porting tool for Emacs Lisp -> CL.
7:54:14
loke
Duuqnd: It's feasible (or, even better: It would be easy to implement an Emacs lisp runtime for CL). However, the problem isn't Elisp per se. The issue is the behaviour of Emacs that Elisp depends on. Replicating that would bea nightmare. In fact, it would be futile.
7:54:31
no-defun-allowed
It should be possible, I think? Elisp is rougly a subset of Common Lisp with editor stuff on top.
7:54:57
Duuqnd
loke: Maybe some of the more commonly used quirks and features could be emulated/translated by the porting tool.
7:55:19
loke
no-defun-allowed: But you'd need a full implementation of a lot of behjaviours... For example, you need to replicate the behaviour of the Emacs-style string properties and overlays.
7:56:07
loke
So you'd need to bodge on something that implements the Emacs style overlay behaviour on top.
7:56:54
Duuqnd
What about manually porting/replacing most things, but having rough automatic porting for more obscure things.
7:57:10
phoe
if you want to avoid the "let's replicate legacy emacs behaviour" nightmare, then you *have* to rewrite a lot of elisp code to something that doesn't depend on that behaviour. that's an either-or.
7:57:37
phoe
and a rewrite of the emacs C layer in Rust/CL/TeX/whatever won't fix this particular issue.
7:58:28
Duuqnd
phoe: Yeah, many things need to be remade from scratch, but automatic porting could exist for when you don't want to port/rewrite old code yourself.
7:58:58
phoe
Duuqnd: do you mean a compatibility layer that accepts legacy emacs behaviour and outputs new saner behaviour?
8:00:09
phoe
And 95% of the code still goes through that library. And now you have bugs that happen inside the emacs-as-a-library, and on the interface between it and the editor below, and also compatibility issues that will nonetheless arise.
8:01:09
shka__
i think that at this point we would be better of to simply go with emacs style editor without emacs compatibility
8:02:16
Duuqnd
shka__: Well, there's a lot of packages that would be quite a pain to rewrite. I don't think a lot of people are very excited about re-implementing Magit, for example.
8:02:27
shka__
true, but personally i just need slime, magit, git-timemachine, evil, parenedit, smartparens, avy and helm
8:04:43
phoe
and if these three things existed in abundance, then we wouldn't even be discussing this current issue right now
8:06:30
Duuqnd
shka__: CLIM is great, but it looks really ugly. That's probably easy to fix, but I haven't seen a single good looking CLIM program
8:06:36
shka__
loke: i won't talk you out of this, i personally still want to write something in clim, i just don't have that much time
8:07:29
Shinmera
phoe: https://github.com/shirakumo/alloy https://www.youtube.com/watch?v=DbLBze3beOo
8:08:42
Duuqnd
loke: I don't know much about CLIM, but from what I've seen, it's pretty difficult to make it look nice.
8:12:18
Shinmera
Well, technically I do have better things to do, like focusing on university studies
8:13:16
no-defun-allowed
Making cool things in Lisp and getting a degree to get a good job, probably.
8:13:41
no-defun-allowed
But good language variety to one of the universities I looked at was "Java and C♯" ):
8:17:07
no-defun-allowed
And I have a compose key I have no other use for, other than writing ☭ slightly faster.
8:18:46
no-defun-allowed
In fact, this web client is so shitty that even macOS configured to use Emacs keybinds don't work.
8:20:52
Duuqnd
no-defun-allowed: Why use a web client? There should be plenty of IRC clients on macOS.
8:22:25
Nistur
I miss university. So much time to do what you want. It felt hectic and busy at the time but, looking back...
8:22:38
no-defun-allowed
Duuqnd: Because I use IRC via matrix.org, which has its own problems I'm not in the mood to cover, and that has basically 0 good clients other than the web one.
9:45:57
scymtym
phoe: did you say CLIM dark mode? https://techfak.de/~jmoringe/mcclim-dark-theme.png
9:51:43
scymtym
the mechanism will probably be a part of McCLIM (it is not in the CLIM standard). applications will be customizable individually
9:52:41
Duuqnd
That sounds really cool. It'd be great if you can change the settings in one place and have all CLIM programs follow that.
9:52:45
scymtym
but i think we should finish double buffering ( https://techfak.de/~jmoringe/mcclim-double-buffering.ogv ) and fsm-based gadgets/animations ( https://techfak.de/~jmoringe/mcclim-gadgets-fsm-2.ogv ) first
9:58:21
scymtym
changing themes would be like this https://techfak.de/~jmoringe/mcclim-gadgets-fsm-3.ogv
10:04:59
scymtym
when the time comes: https://common-lisp.net/project/mcclim/static/manual/mcclim.html
10:10:13
scymtym
we have lots of work ahead of us to make those prototypes into something actually usable
10:17:28
scymtym
maybe some find in-browser CLIM exciting? https://techfak.de/~jmoringe/mcclim-broadway-7.ogv
10:44:00
phoe
scymtym: you have a choice now, either you post that last video to /r/common_lisp or I post it there
10:53:48
scymtym
phoe: go ahead if you like, but make sure to note that it is a prototype. for context: the communication with the browser uses a modified version of GTK's broadway protocol ( https://developer.gnome.org/gtk3/stable/gtk-broadway.html )
10:59:07
phoe
https://old.reddit.com/r/Common_Lisp/comments/dfwbiz/a_prototype_of_mcclim_in_browser_using_the_gtk/
11:23:36
prxq
Hi, does anyone here have an archived copy of the RDNZL library? It seems to have vanished from the net. I followed the links at cliki etc, all download links that I've found are dead.
11:33:02
prxq
phoe: thanks. My customer has a ton of legacy code based on RDNZL, that could be an upgrade path. Need to get the old stuff running first, though.
12:12:34
ralt
the doc has this warning though: "Note that the CVS repository at common-lisp.net is usually not in sync with the current release version!"
12:14:37
ralt
Edi Weitz was fairly responsive as of a couple of years ago though, so I'm surprised you couldn't reach out to him
12:26:20
samlamamma
I've got a couple of Sexprs I'd like to print out as a Graphviz graph (w/o explicit cons cells, so straight up the AST). Anyone done a similar thing with a library that they can point me to?
13:40:19
ralt
it mentions latest rdnzl-cpp version is 0.7.1 and the latest svn commit says "import 0.7.1", so I assume it's the same
16:01:14
pjb
varjag: binary streams were considered to be always non-interactive, so it didn't make sense.
16:02:18
pjb
varjag: of course, nowadays, there are implementation-specific extensions such as socket-stream, that are both binary and interactive, so implementations may provide implementation specific to do the equivalent of read-char-no-hang.
16:02:42
pjb
varjag: or, if the implementation is consistent and considers socket-streams to be interactive, you can write (when (listen s) (read-byte s))
16:03:40
pjb
check the behavior of listen in your implementation on tcp streams, and if good, (when (listen s) (read-byte s))
18:56:31
fiveop
I wanted to try vulkan in CL unter linux. cl-vulkan seems unfinished and vktk is only set up for windows and mac so far. Is there anything else?
19:03:35
pjb
fiveop: CL doesn't run under linux, but above linux. So you might want to try vulkan in CL uber linux.