freenode/lisp - IRC Chatlog
Search
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.
1:41:34
Bicyclidine
i don't know if anyone does hardware design that doesn't involve machine assistance at some point
2:46:15
White_Flame
the 2 biggest complexity bottlenecks of Unix are streams-of-bytes and heirarchical filesystems. Plan 9 doubles down on those
2:47:12
White_Flame
zdsjqzrlbo: it is. You ahve to choose a singular parent, for cases where there are legitimately multiples
2:48:27
White_Flame
same problems in OO, bringing in the new thinking of composition over inheritance
2:49:01
White_Flame
any super tight coupling always breeds problems of overcommitment to a linkage and bad scope creep
2:49:36
Zhivago
The only interesting questions are how to uniquely identify things, and how to identify sets of things given constraints.
2:50:59
Zhivago
The important quality of hierarchy for unix is that it ensures every file exists on a single device -- and if you remove that restriction you'll need to solve that in another way.
2:52:00
White_Flame
zdsjqzrlbo: some of my ranting on the subject: https://news.ycombinator.com/item?id=13779293
2:56:03
White_Flame
I especially stand by my response at the bottom of the page, against ad-hoc text files
2:57:19
White_Flame
The only "real" solution is for AI to be the OS of a personal computer, so it "understands" and can work with whatever
2:58:16
White_Flame
heck, even plain JSON config files are way better to work with programmatically, because the machine can make sense of it, as opposed to an ad-hoc pile of magic white space and punctuators
2:58:41
White_Flame
there's only 1 decision to make: Which common standard does it conform to? And then everything else is clear
2:59:06
White_Flame
because at least while the information is ad-hoc, the formatting is standardized
2:59:51
White_Flame
because it's an impedance mismatch barrier and the source of many bugs when pursuing automation and interoperability
3:00:15
White_Flame
again, it's the difference between single-program perspective and ecosystem perspective. individual programs work with their own data, fine
3:00:40
Zhivago
All it saves is writing a parser. Now you've picked a common parser -- rework your argument in this context and see that you've solved no interesting problem.
3:01:16
White_Flame
even above, if you dumped all your photos into a database, then your image viewer can't access it, because computers are based on commonly-accessed files. Once you leave that realm, you lose more interoperability
3:01:58
Zhivago
And using JSON won't help, because it won't understand what "id" means in this context.
3:02:10
White_Flame
and without interoperability, you lose the ability to actually command your machine
3:02:34
White_Flame
Zhivago: yes, but you can usually _simply_ link things together once they're in that state
3:02:49
White_Flame
and it's just a rough example. There is no true solution until the magic AI appears
3:03:18
Zhivago
And this is the fundamental problem, which you've missed, and which makes most of these objections irrelevant.
3:03:43
Zhivago
Your image viewer and the files it understands are in a relationship of shared semantics -- they can interoperate with those semantics.
3:03:52
White_Flame
I'm not talking about reverse engineering unknown data. I'm talking about cases of putting my data somewhere, and now I can only interact with it through one application. Or, I can't easily configure an application because its ocnfiguration data is not exposed, or is difficult to process, or isn't rescanned at runtime, etc
3:04:06
Zhivago
Your file browser and the filesystems it understands are in a relationship of shared semantics -- they can interoperate with those semantics.
3:04:34
Zhivago
How the hell those files are represented just doesn't matter, which is why using JSON doesn't fix anything.
3:04:37
White_Flame
but, it's a coursely-permissioned, single-parent heirarchy, which ends up being weaker when used as a primary organization structure
3:05:37
White_Flame
there's 2: the magic all-encompassing schema of everything, or the magic all-encompassing AI running everything
3:06:31
White_Flame
but really, one of the coufnounding factors is that people don't write applications that are capable of being driven externally
3:07:11
White_Flame
and so we can't use "unix philosophy" to tack together interesting little tools to accomplish new workflows easily
3:08:03
Zhivago
Well, they're all capable of being driven externally -- it's more a question of the convenience and lack of well defined semantics.
3:08:32
White_Flame
obviously, the Lisp machine model does tackle a lot of this, because everything shares an object system, functions are exposed as callable functions, and serialization is not necessary to communicate across domains
3:09:05
White_Flame
obviously, there's still some object heirarchy impedance, and security is difficult
3:10:13
Zhivago
But if you take a CLIM application that wasn't designed to be used as a library, good luck using it as a library.
3:11:03
White_Flame
right, that ontological issue will always remain as long as computers are programmed by rote
3:12:07
Zhivago
When you have AIs, you'll have the problem of determining if you share the same understanding of things.
3:12:59
White_Flame
sure, but in that hypothetical, tools exist to tackle the mismatched ontologies. it's not just a total complete unworkable situation
3:14:36
Zhivago
ebrasca: That might well be a macro invocation, or involve symbol-macros, or have imported symbols from another package, or have a divergent reader, or ...
3:15:03
Zhivago
ebrasca: It might be a parameter of something that doesn't evaluate it, such as quote.
3:15:39
Zhivago
What lisp gives you here is a heirarchical textual structure -- which makes some things more convenient -- but is still essentially just arbitrary text.
3:16:02
White_Flame
unless you're fiddling with reader macros, it tends to be objects, not just character streams
3:17:02
Zhivago
Except that you still need to serialize them, at which point you'll find exciting problems with disagreements on representation, e.g., of floats.
3:17:41
White_Flame
but in any case, my main thrust is that it's good to realize the problems and limitations even of your preferred systems. "I can't believe people diss Unix!" etc, isn't really useful. Everything has problems and limitations, and being aware of them helps shape useful ideas moving forward
3:20:04
Zhivago
Personally, I've come to think that the unix model isn't particularly terrible -- files, filesystems, processes -- but these should ideally be details the user isn't exposed to.
3:20:52
random_numbers
The curiosity to learn more comes from being able to pull at the seams and see what lurks beneath.
3:21:35
Zhivago
But since things are designed for people who don't do that, there are common protocols for communication between things.
3:22:06
Zhivago
It's this consensus that is really needed to address what white flame was complaining about.
3:23:17
White_Flame
when my navigation program broke with an update, there was no way for me to reasonably extract my stored locations
3:23:18
Zhivago
And while the file-system is hierarchical, no-one notices, because there is generally no need to interact with it in that matter.
3:23:36
random_numbers
I can agree with objects. But the difference is hackability. Hacking Lisp is easy. Android is pretty opaque in comparison.
3:24:30
White_Flame
well, I could get started on my other rant on how silicon valley is destroying computing ;)
3:25:10
White_Flame
Zhivago: no, I wouldn't mind converting it from an accesible format. But I don't know where it is, how it's stored, etc.
3:25:48
White_Flame
and I might, as there are dozens of locations of places I travel to on about a yearly basis that a super convenient/important to have on hand
3:26:33
White_Flame
but that's only half the problem. Programmatically injecting that data into another program is harder than just a read-only extraction task
3:27:09
White_Flame
especially if I just have name/latitude/longitude, that's not really enterable from the UI of a gps nav program
3:27:30
White_Flame
but, on a hypothetical Lisp machine, these sorts of things would be at least a bit more exposed
3:27:56
White_Flame
and the ability for a user to bridge information between programs becomes much more practical
3:34:39
eschatologist
I've been thinking about writing some Lisp code to talk to a web service that uses OAuth2. I've found OAuth 1 through 1.0a libraries, but is there any simple OAuth2 solution?