freenode/lisp - IRC Chatlog
Search
11:08:25
_death
generally you avoid serializing those.. but see http://www.discontinuity.info/~pkhuong/common-cold/
11:40:26
phoe
generally you serialize those by (if at all) capturing their source code at compile time and storing the source code, then compiling it again during deserialization
16:54:23
dlowe
"we have the most flexible expressive language, but you HAVE to use exactly this software or it falls apart"
16:57:36
rk[ghost]
phoe: i like rlwrap sbcl.. but i was trying to use cl-readline to make a custom readline for a internal repl.. (the rlrwap was catching all my keypresses and i couldn't figure out why the lib wasn't working as described:P)
16:59:38
rk[ghost]
phoe: aye. assuming i make equalized hardware on a distributed system just curious
17:00:34
rk[ghost]
since serialization is a major concern when designing a good concurrent system, was curious how it handled something high-level like a function
17:08:23
phoe
functions are compiled into erlang BEAM bytecode, that's how they are serialized and passed around between nodes
18:02:20
sukaeto
IMO, "just use slime" isn't a bad requirement, in this case. You don't have to use Emacs for anything else, just as your repl.
18:02:48
sukaeto
I mean, assuming the user is looking for a solution to "I type sbcl at the shell and the repl I get is really shitty"
18:03:32
sukaeto
using any random editor and copy pasting to a slime repl is no worse than copy pasting to any other repl
18:09:41
sukaeto
FWIW, this is exactly what I used to do. Way back in the day, I used clisp. Then I switched to sbcl, but I wanted a repl at least as good as the clisp one, so I used Emacs just for slime. Then I discovered slimv. Then I eventually figured out that Emacs was better (for me) at everything except the editor itself, so I switched to Emacs+evil. And now I'm rambling, so I'll stop.
18:19:41
_death
the next step is to discover the banality of evil and submit at the altar of st. ignucius
18:41:23
mrottenkolber
rk[ghost]: phoe: regarding serializing functions, I *think* you don’t do that. You send a symbol to the other node and it tries to execute the function named by that symbol. That’s what Erlangen does, I believe its also how you do it in Erlang (send a module:name tuple). I know of WASP which is specifically designed to push remote code. So I would look at that if I was serious about “true” RCE. http://waspvm
18:43:09
mrottenkolber
Erlang probably has like phoe said some way to push new versions of modules around
18:43:35
mrottenkolber
They put a lot of thought even into situations where you have two versions of the same module around
19:43:35
random_numbers
About that Lisp OS draft paper someone linked me to. It was interesting. I'm not quite convinced of non-hierarchized filesystem/object-store.
19:46:28
jackdaniel
non-hierarchical doesn't mean flat. ("source" "cl" "file.lisp") is the same as ("file.lisp" "source" "cl"), but different than ("source" "cl" "my-project" "file.lisp") 9r ("src" "file.lisp" "cl")
19:47:22
jackdaniel
having two objects designated by tuples ("a" "b" "c") and ("b" "a" "c") is not possible of course (because they are not ordered)
19:48:10
random_numbers
Hm. That works, logically. I'm curious what a file-manager for such a system would look/act like.
19:50:20
jackdaniel
good question. some approximation would be what gnome once tried with zeitgeist extension
19:52:52
random_numbers
I'll say though that a unified meta-data system not reliant on the peculiarities of various formats would be a massive improvement on my current workflow. Even just epub vs pdf, mp3 vs ogg, serves to make it seem useful to me.
19:58:28
random_numbers
For command-line usage I think that file-reference completion in a manner analogous to emacs' "helm" could be a decent method.
22:23:00
random_numbers
mrottenkolber: I'll try getting it from the logs, otherwise it's here https://github.com/robert-strandh/LispOS as (La)?tex source.
22:25:07
random_numbers
mrottenkolber: http://metamodular.com/lispos.pdf Here was the link flavio81 originally gave me.