freenode/#lisp - IRC Chatlog
Search
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.