freenode/#lisp - IRC Chatlog
Search
3:55:02
verisimilitude
Then again, I'm also careful to change idioms and whatnot to ``writing'' rather than ``speaking'' or ``talking'' when using a medium like this.
3:57:30
verisimilitude
How would one pronounce ``ugt'', anyway; I'd figure ``ugh'' with a hard ``t'' sound at the end.
4:44:02
verisimilitude
The cl-ecma-48.lisp file is updated, but I've not updated the cl-ecma-48.tgz file, yet.
4:46:16
verisimilitude
I was careful to double check my searching and replacing, but do tell me if it doesn't work, which means I made a mistake somewhere with that.
4:47:01
verisimilitude
Then again, you were probably loading that to load ACUTE-TERMINAL-CONTROL, I suppose.
6:08:23
asarch
One stupid question: how would you create a function at runtime? Can you give me please an example
6:24:12
verisimilitude
Actually, that's an old version of the code; I suppose I forgot to upload the latest version.
6:43:14
minion
verisimilitude: SICL: SICL is a (perhaps futile) attempt to re-implement Common Lisp from scratch, hopefully using improved programming and bootstrapping techniques. See https://github.com/robert-strandh/SICL
6:43:20
minion
verisimilitude: Cleavir: A project to create an implementation-independent compilation framework for Common Lisp. Currently Cleavir is part of SICL, but that might change in the future
6:50:05
beach
The code generator of the compiler will obviously contain a few lines of assembler, of course.
6:51:16
beach
LdBeth: I don't think I have a published paper on the basic organization of SICL or Cleavir. I am waiting until I have a more complete system.
6:55:00
verisimilitude
I also have ambitions to eventually create a Common Lisp system, but I'm currently working on a machine code development environment, so that's a ways away.
6:56:12
verisimilitude
The machine code development environment is in-progress, which prevents me from using it to work on a Common Lisp implementation is what is meant.
6:57:17
beach
verisimilitude: I am trying to figure out how developing a Common Lisp system would depend on a machine code environment.
6:57:35
beach
verisimilitude: It is far from done, but it would probably use something like that, yes.
6:57:56
verisimilitude
So, I intend to write most of the COMMON-LISP package in Common Lisp, implementing primitives and whatnot in machine code.
6:58:11
verisimilitude
Will this implementation provide its own mechanism to exit; if so, I'll add it to SHUT-IT-DOWN already.
6:58:34
loke
Is there a way to print a symbol using the conventions of readtable-case :INVERT, without actually changing the readtable?
6:58:35
beach
verisimilitude: Let's discuss that in a few years when I have made some more progress.
6:59:05
verisimilitude
Writing a language entirely in itself can be interesting, but I find it much easier to simply write the base in something else.
7:00:33
verisimilitude
I find it much easier to think about having precise control over the compiled result if it's not written in itself.
7:01:59
verisimilitude
This is my website; I don't currently have any material on this planned Common Lisp implementation, however.
7:03:33
beach
verisimilitude: If you have any questions about SICL, I'll be happy to answer them. But right now, I am off to run some errands.
7:03:45
loke
verisimilitude: I do, but I find it a bit ugly. But perhaps I have the wrong sense of æthetics.
7:04:26
verisimilitude
A brief summary of a sentence or so, if possible, would be appreciated, when you get the time, beach.
7:14:39
phoe
verisimilitude: SICL is a highly modular CL implementation written in CL and bootstrapped from CL.
7:15:31
verisimilitude
I use Emacs with Ghostscript to read PDFs, but my GuixSD X11 Emacs is currently defective; I'm using no-x Emacs, currently.
7:23:12
verisimilitude
I would just run X11 and Emacs, but there are a few other things I sometimes need to do that prevent that right now.
7:33:20
LdBeth
Even you’re still young physically, you mind gets older(and mature) when you start using CL
10:04:51
Shinmera
I have yet to see an explanation as to why anyone would ever push NIL onto features to begin with.
10:08:53
phoe
Shinmera: (pushnew nil *features*) is a magical way to break a lot of Lisp code in unexplainable ways
10:08:57
jackdaniel
just as C is easier to read because you don't have to count the parenthesis ;) I'd say it is a matter of getting used to it, but #+NIL being semantically wrong is a fact from the specification standpoint and the programmer's desired effect
10:10:43
phoe
and if I wanted to use code that's only incorrect in some circumstances rather than code that's correct period, I'd be using Javascript
10:12:54
Shinmera
phoe: Whether people write correct code or not has nothing to do with the language.
10:22:41
Shinmera
Personally I just comment things out. With expand-region bound to C-q, that's just as quick as C-q M-;
12:49:13
Xach
Hmm, I wonder if there's an existing easy way to "refactor" the frequent use of a complex accessor into a local variable in emacs.
13:03:24
Xach
I don't think I need a macro at all. I want to bind a value instead of computing it over and over.
13:04:16
Xach
schweers: in the near future archive integrity will be checked by signature and digest. but the composition of the archive is still a weak point.
13:05:06
Xach
there will be confidence that code comes from the expected place, but it might be bad code.
13:06:04
Xach
Anyway, I can do what I want fairly easily enough manually, with a combination of paredit, some typing, and query-replace.
13:09:35
_death
Xach: I don't use redshank, but I'd likely do something like that with multiple-cursors
14:03:08
epony
English is not my native language, now it tries to be. I always forget one word and have trouble remembering it, there is something wrong with it. Endorse is heard from marketing leaflets waving salesmen with a previous career. Thank you for reminding it to me, verisimilitude.
14:33:43
shrdlu68
beach: Your LispOS paper is thought-provoking. Something has to play the role of a kernel, right?
14:38:03
phoe
as in, the paper AFAIR does not concern itself with scheduling/init/devices, so it can be done in any suitable manner
14:39:05
beach
shrdlu68: Yes, there will be a collection of functions and such for dealing with that.
14:40:50
beach
dlowe: There is very likely going to have to be a few lines of assembly-like code here and there. Sure.
14:43:44
Shinmera
There is an environment, of course, but not a separate entity that acts as the kernel.
14:44:05
beach
I am thinking of taking inspiration from I/O Kit from Apple for device drivers, except using CLOS instead of C++ (of course).
14:44:09
phoe
shrdlu68: as far as I understand beach's reasoning here, there's *something* that does that. What exactly it is and what terminology is used to describe it is an implementation detail.
14:45:33
beach
shrdlu68: Think a Common Lisp system where some of the code is dedicated to managing devices, scheduling threads, etc.
14:47:34
beach
In Multics, since every program was contained in a segment, the "kernel" was just a collection of segments. You could replace any such segment without rebooting, and every program would instantly see the difference. A device driver could be replaced for instance, or the code for some system call.
14:47:43
shrdlu68
So the Linux kernel is a collection of OS functions and objects, plus some other thing{,s}.
14:50:20
beach
Though in the Lisp OS I am thinking of, since most applications would not be able to manipulate raw addresses, there is no particular need to make them execute in a non-privileged state.
14:50:51
beach
Applications written in C using the traditional technique would still have to execute unprivileged.
14:53:35
beach
verisimi`: SICL is different in that it uses more modern programming techniques than most existing implementations, simply because most implementations were written before CLOS existed. And the idea is to make the code simpler, so therefore easier to maintain, than existing systems. This property, I hope, will encourage improvements and optimizations that would be difficult in existing implementations.
14:53:44
TMA
beach: it is not entirely accurate. you can change any system call code at runtime, it is a matter of swapping in a different function pointer to the syscall dispatch table. It is just not pleasant and there are problems with C not having a usable notion of CHANGE-CLASS, so you are basically stuck with the data structures you already have
14:54:28
shrdlu68
beach: But how do you tell a program is capable of manipulating raw addresses or not?
14:54:58
beach
shrdlu68: Such a program would have to become a particular subclass of FUNCALLABLE-STANDARD-OBJECT.
14:55:40
beach
shrdlu68: And when such an object is called, it would remap the address space. Something that most functions would not need to do.
14:58:11
shrdlu68
The clearest difference between the kernel and the not-kernel to me at this point is that a not-kernel does not a need a reboot.
14:58:47
beach
shrdlu68: In Common Lisp you can't take some arbitrary instructions and create a callable function out of them. You have to go through COMPILE, or equivalent. In Lisp OS, to turn some C code into such a program, you would need some other similar compiler function and it would create the kind of object that remaps the address space.
15:00:09
beach
When I hear or use "kernel", I think "monolithic piece of code created by a 1960s linker and that must be replaced entirely in order to update even a single instruction".
15:01:37
shrdlu68
beach: Say I have an arbitrary binary that I want to run on your OS, what's the sequence of events from executing it to seeing a "Hello, world!" printed on the screen?
15:03:26
TMA
I use "kernel" for elevated privileges code (namely when the privilege elevation is hardware assisted)
15:05:21
beach
And it's a perfectly valid use of the word. Just not very useful for the Lisp OS I am thinking of.
15:06:18
TMA
sure, it has to go through something like COMPILE to grant the privileges of executing the unsafe parts
15:06:28
beach
It would have to be compiled with a special compiler to create a special subclass of funcallable-standard-object.
15:13:38
TMA
it becomes problematic when untrusted code can request compilation via the special compiler -- or at least that is my gut feeling
15:15:31
TMA
the whole purpose of the special compiler is that it allows marking some potentially unsafe code (code that uses raw addresses) as executable
15:16:30
beach
No, the purpose is to create a Common Lisp function that, when executed, changes the address mapping so that it can't do anything other than what a standard Unix program can do.
15:16:38
shrdlu68
The way I understand it, the system simply does not understand unsafe code. It does not know how to run unsafe code.
15:17:36
beach
And it would have to manipulate Common Lisp objects though "file descriptors", i.e. small integers.
15:18:33
TMA
oh, I have messed up the one that allows to patch the lisp-os's parts involving inline assembly/raw address with the C-programs enabling one
15:18:38
beach
I don't quite understand why the focus here is on something that I consider totally exceptional, that I would rather not see at all, but that MIGHT be required in SOME VERY unique cases.
15:19:26
beach
Patching the Lisp OS would be the same as patching a Common Lisp program, i.e. a function would be replaced, or a class would be redefined, etc.
15:19:55
beach
shrdlu68: I think I am entitled to my perspective since I am the author of the specification.
15:22:11
beach
It wouldn't be a matter of something that somehow is impossible to do the "standard" way.
15:22:30
beach
Just that someone would be lazy enough to want to incorporate C code rather than writing the equivalent Common Lisp code.
15:23:44
shrdlu68
I think I get it now. It really is a Lisp OS. Not just an OS written in Lisp, but for running Lisp.
15:25:07
beach
First sentence of the intro in fact: A Lisp Operating System (LispOS for short) is not just another operating system that happens to be written in Lisp...
15:27:39
shrdlu68
It's like writing a javascript OS, and some fella comes along with his Lisp code...
15:29:00
beach
shrdlu68: That situation is no different from running Lisp on the "C operating system" called Unix.
15:30:30
beach
shrdlu68: It is a research project. I am fortunate not to have to care about things like that. It is a project where I attempt to show how much better things could be than what they are. If people don't want better things, there is not much I can do, and it won't say anything about the validity of the project.
15:32:47
beach
Exactly, and that's the reason for most of the security problems we are faced with today.
15:33:43
beach
... which apparently don't work anyway, and only create problems for application writers.
15:36:59
TMA
the security problems are that there is so much code in existence you cannot be expected to audit it before running it compounded with that the people do not behave nicely to each others
15:37:02
loke
jmercouris: If your code can never arbitrarily access data by pointer, then it's not needed.
15:37:32
epony
"If you find that you're spending almost all your time on theory, start turning some attention to practical things; it will improve your theories. If you find that you're spending almost all your time on practice, start turning some attention to theoretical things; it will improve your practice."
15:38:00
jmercouris
Yeah, I just skimmed a little bit above, if this conversation goes deeper and I missed a lot, sorry
15:38:10
loke
jmercouris: Whose code would that be? In Beach's OS, only the low level kernel code will have that capability (and even then, a very tiny bit of code since the OS itself is written in Lisp).
15:38:10
beach
jmercouris: The entire argument is that it is absurd because it fixes a problem that should have been fixed differently.
15:38:38
jmercouris
if fixing it correctly means making a new OS, I think that is a cost very few are willing to bear
15:38:45
epony
I agree with beach, the problem should have been prevented instead of sorted that way.
15:39:22
jmercouris
loke: Not only low level code would have that ability, there are ways, especially if you have physical access to the hardware
15:39:34
beach
jmercouris: You apparently also missed my saying that this is a research project, so there is no real "cost" involved.
15:40:19
jmercouris
I understand the time/place of your project, and I'm fully in agreement with you
15:40:22
beach
jmercouris: And you missed that most code in the OS I am thinking of would not have physical access to the hardware.
15:40:28
loke
jmercouris: sure. you could shut the machine down and reboot Linux or something. I'm putting words in beach's mounth here, but I'm pretty sure the project does not intend to prevent that.
15:42:23
beach
jmercouris: And you missed that most code in the OS I am thinking of would not have physical access to the hardware.
15:43:41
epony
jmercouris the machine is a machine code interpreter, how you give the machine the operands is irrelevant given the machine runs and not halts
15:43:51
loke
beach: Are you going to use some microkernel or something as foundational base, or will you be writing the lowest level code yourself?
15:44:31
jmercouris
I imagine it will have to be a microkernel, it makes a lot of sense anyway with the message passing
15:45:13
jmercouris
epony: I understand your sentence, I don't understand your meaning within the context of this discussion
15:45:44
shrdlu68
beach: Isn't there a LispOS similar to what you're proposing already in existence?
15:47:00
jmercouris
I think Lisp OS were not as beach describes, just OS' with function calls and paired with hardware optimized for common lisp operations
15:47:59
jcowan
One thing conspicuously missing from the protection scheme is any way to protect the user from themself.
15:48:04
loke
I wondering if Redox is trying to approach security in some similar way... (there are huge differences of cours,e but the fundamental idea that software should not be allowed to do the wrong thing seems similar)
15:48:25
jcowan
When everything is mutable and persistent, how are you to stop a brain fart from permanently ruining your system?
15:49:09
jmercouris
I was joking firstly, but sure, you could write conditions for everything you are afraid of
15:49:12
beach
jcowan: That's a very good question. In the worst case, the global environment would have to be ditched.
15:50:28
beach
So here we go again. I suggest something that is way better than anything we have, but it is not accepted because I can't solve problems that no other operating system can solve today.
15:51:03
jcowan
Well, one of the things it loses is the ability to throw away a local world and start again, because there is only a global world.
15:52:17
jcowan
You make global Lisp environments explicit, but that's not the same as a whole world, which is more like a VM today.
15:52:40
epony
I would not consider arguments from other environments is a decision to not accept something better, but difficulty understanding the foundation.