freenode/lisp - IRC Chatlog
Search
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?
4:03:35
ebrasca
eschatologist: I try to run ansi-test on mezzano because froggey say I can find with it how to help.
4:05:06
eschatologist
froggey suggested that you obtain ansi-test and then use it to find bugs to fix.
4:24:11
ebrasca
eschatologist: Now it load thanks to "(load "/home/ebrasca/quicklisp/local-projects/MBuild/Mezzano/ansi-test/compile-and-load.lsp")"
6:02:43
pjb
This is really the wrong question to ask. You're asking about people when you have a technical problem. You're asking about a specific library (a specific solution), when you want to solve a specific problem.
6:04:00
pjb
Furthermore, if the question is whether cl-readline provides it, then you could answer yourself trivially (just scan the f... list of functions provided by cl-readline).
6:13:22
rk[ghost]
if the answer to my first question is 'no it doesn't have the function' then my question of 'what is it?' is irrelevant
6:14:19
rk[ghost]
i tried to read through the docs of functions and none of them /seemed/ like they do it.
6:15:06
rk[ghost]
when i asked a specific question before: i was pointing to a list of 10 or so libraries
6:17:21
rk[ghost]
so i suppose this question would then be, does gnu readline have the cability to clear a screen or is this handled on another layer?