freenode/lisp - IRC Chatlog
Search
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?
6:22:56
rk[ghost]
and i believe i understand your friction with 'asking about a particular solution', but from my perspective it is more about asking about a particular environment which ones happens to be in. if the answer is 'in such environment you cannto do that.. pick a different one... then i can aceept that. but often environments are inherited and one is forced to mold a compromise of a solution.
6:28:33
rk[ghost]
does anyone around do any tui applications in common lisp? what libraries do ya'll use and how do you feel about them?
6:29:27
random_numbers
https://common-lisp.net/project/cl-ncurses/ Haven't used it for Lisp yet but I do use it for basically every other language I use.
6:30:59
jackdaniel
cl-charms is often recommended ncurses interface for cl (https://github.com/HiTECNOLOGYs/cl-charms)
6:33:18
rk[ghost]
so, have ya'll used those libraries yourselves, or just heard them as recommended?
6:34:26
rk[ghost]
i haven't learned all the details of ncurses, but doing some investigations it doesn't seem like the greatest framework
6:34:59
random_numbers
beach: Allow easy access and management of files. Remote server access if a feature I like too (browsing ftp/ssh/webdav/etc).
6:35:42
rk[ghost]
i suppose ranger has the ability to call python functions which one could technically set up a foriegn interface to CL bindings..
6:35:42
random_numbers
beach: I'd be inclined to say it should either directly allow modifying metadata or closely integrate with software that does it in its stead.
6:36:06
random_numbers
There's also Hy-lang, if you don't mind the similarities it has with clojure.
6:37:17
beach
random_numbers: To me a "file" is just a special case. At least for Unix-style files, it is just a vector of bytes.
6:37:44
beach
random_numbers: So there would be no need to have a particular file manager, separate from any other "manager".
6:38:22
random_numbers
beach: Hm. I see. I just tend to see them as units more like one would get in say... a database-filesystem. It just reflects my use more closely.
6:38:43
random_numbers
Despite the whole "everything is a stream to pipe somewhere" thing inherent to unix.
6:39:33
beach
rk[ghost]: The point here is that the document that was the origin of random_numbers's question specifically says that there is no file system.
6:41:16
rk[ghost]
everything as a file is a nice abstraction, but it is curious to ask if it is appropriate for all things computer
6:41:51
beach
rk[ghost]: "Everything is a file" is a lousy abstraction. It has ridiculous restrictions that make it very hard to write collaborating applications.
6:42:13
beach
rk[ghost]: It was a restriction that was necessary because of the computers at the time. It is anything but "nice".
6:42:40
beach
rk[ghost]: The computers being much more powerful these days means that this restriction is no longer necessary.
6:43:00
jackdaniel
beach: btw, did you see zeitgeist framework? (it's not lisp, but it acts on similar premises, that file is a lousy abstraction)
6:43:08
beach
rk[ghost]: Strangely, many generations of software developers still assume it is a necessary restriction for intrinsic reasons.
6:43:27
random_numbers
Honestly, besides the collision issue and a few usabilities questions (difficulty imagining it), I would say the LispOS file model seems more reasonable from a programmatic and user side.
6:43:57
random_numbers
Not knowing where my files are is weird if I don't have a fuzzy way to find them incrementally.
6:44:18
Zhivago
It's closer to 'everything is a device', and 'make all devices visible in the filesystem', which aren't particularly terrible ideas.
6:44:57
beach
random_numbers: Since it is a strict generalization, I don't see the problem. Anyone who wants to continue to live with those restrictions can do so. Just like you can program in a C style in Common Lisp.
6:45:29
jackdaniel
random_numbers: that could be done in the following way: you select one tag you are interested in and "file manager" shows other tags connected with this one
6:45:46
beach
random_numbers: And I have no idea what "collision issues" or "usabilities question" you have in mind.
6:46:05
random_numbers
beach: Files with similar or near-identical tags and how to find them quicky and in a practical manner for use.
6:46:52
beach
random_numbers: If you want to, you can have a "directory" object that has a single tag. It can then contain other objects, such as directories and vectors of bytes.
6:47:05
rk[ghost]
beach: aye the stack has a rotten core.. and people keep piling up on top. backwords compability.. finally should be abandoned for a move forward. quit making stuff specifically for x86 running POSIX ;P
6:47:05
random_numbers
jackdaniel: With usage tracking a bit ala Zeitgeist, I could see that working very nicely.
6:47:21
Zhivago
Yes, the apple solution of having directories that look like files was a reasonable approach.
6:48:55
random_numbers
About the cl-readline, readline has a clear-screen command. Not sure if the CL bindings allow access to it.
6:49:36
Zhivago
rk: Once you view the kernel as a provider of virtual machines ... it gets a lot simpler.
6:49:41
rk[ghost]
random_numbers: aye good to know. if it is jus tthe bindings lacking, i can dive deeper knowing not in vain.. add the binding myself.
6:50:03
random_numbers
rk[ghost]: https://cnswww.cns.cwru.edu/php/chet/readline/readline.html#fn_C It's about 10th in that list.
6:51:28
random_numbers
Given what I think I got out of LispOS, there's no reason the system-level commands couldn't be redundant Actors on a distributed network.
6:52:57
Zhivago
Well, you'd need some kind of multi-process semantics for that to work, unless you're proposing distributed shared memory.
6:52:59
rk[ghost]
random_numbers: grreat. thanks! i will start peeling away the layers of the cl-readline source.
6:53:28
Zhivago
And if you're proposing distributed shared memory, it's probably time to look into why it's not really a workable option.
6:54:22
rk[ghost]
i imagine that there will be distinct chips (open too!) soon enough for any given service..
6:55:04
rk[ghost]
aye, i think process semantics (adopting OTP principles of the actor model) seems like the right path forward.
8:05:02
phoe
rann: bindings are bindings, you can always hack around it if you can read the TERM variable and issue the proper escape command yourself.
8:05:38
phoe
this is hackery, but is only worse than a pull request to cl-readline that implements the missing functionality
8:06:53
phoe
today exclusively on #lisp: unexpected tips and how they can affect your life (more on page 7)
8:30:46
phoe
ebrasca: On hiatus for now - I'm doing other things that my real life requires to be done first.
8:37:51
phoe
ebrasca: I'm not familiar with ansi-test but it should give you some sort of list of what tests failed.
8:41:58
phoe
it looks like the function is copied or something, where it should be the same object at the same memory address.
8:43:54
phoe
ebrasca: ask around for help on #mezzano - this looks complicated and might need changes in either what SETF does or in compiler or some other place.