freenode/lisp - IRC Chatlog
Search
3:23:39
beach
Thank you! Today, I think I'll work on an abstract for a recorded talks that I have planned to give in the context of phoe's new initiative (the name of which I forget).
4:42:14
beach
I didn't see it because 1. I am becoming more dyslexic over time, and 2. The spell checker doesn't recognize "sandboxing" anyway, so it was going to be flagged even with a `d'.
6:39:34
phoe
I didn't really think of anything more fancy since I don't think there needs to be anything more fancy
6:55:31
MichaelRaskin
beach: sounds interesting and useful! and it looks like your work on SICL bootstrapping is now close to making FCGE's available to people who are not going to write implementation internals.
6:58:17
beach
I just realized that a good existing implementation is not very far from using something like first-class global environments.
6:59:01
beach
I mean, it just keep the classes, the (SETF <mumble>) functions, the global value cells, the MAKE-INSTANCE, etc. Somewhere.
6:59:57
beach
So if they would just do the same for functions named by symbols, and global value cells, then they are half way there.
7:01:22
MichaelRaskin
I would be wary about that effect that «getting 90% right there takes 90% of effort… and so does the second 90%»
7:02:06
MichaelRaskin
I would expect a bit of special-case code for properly inlining the standard and defined-to-be-unredefinable functions like + — and like open
7:03:38
MichaelRaskin
It is very likely to make support of FCGE's with _different_ #'cl:open maintenance-intensive
7:03:52
phoe
package name, package predicate, value and function cells, symbol plist and flags that determine constantness, specialness, etc.., are all stored on the symbol
7:03:55
pjb
beach: (defun project-time (effort power) (if (< effort 0.00001) 0.0 (+ (* .9 effort power) (project-time (* 0.9 effort) power)))) (project-time 1.0 1.0) #| --> 8.999914 |#
7:04:44
pjb
https://www.volersystems.com/project-management/228-why-the-last-10-takes-90-of-the-time/
7:07:13
beach
pjb: I just don't see how first-class global environments would have any influence whatsoever on the applicability of that rule, nor on the inlining issues mentioned by MichaelRaskin.
7:07:39
beach
MichaelRaskin: It does, but now you are definitely talking about a subject unrelated to first-class global environments, right?
7:07:52
beach
I mean, I don't see how inlining has anything to do with first-class global environments.
7:08:19
pjb
beach: it's just a general rules. But I would say that it's quite possible that it doesn't apply in your case, given the steady pace your working at.
7:08:45
beach
pjb: I am sure it does apply, but I don't know how it is related to first-class global environments.
7:09:22
MichaelRaskin
For SICL, your inlining code is structured in a way that swapping out a single function should not be a problem
7:10:36
pjb
There are different environments, requiring different sandboxing. The CL environment (functions, variables, etc), the host file system environment, the network environment etc.
7:11:11
pjb
If you have an socket:connect, you may also want to sandbox your network node (use a different DNS, use virtual hosts, etc).
7:11:20
beach
MichaelRaskin: That's a narrow definition of "sandboxing". I consider it essential for a Common Lisp implementation to be safe that appplication code can not alter the code generator of the compiler without some additional manipulation. That's already sandboxing to me.
7:12:13
pjb
MichaelRaskin: with the tools provided by sicl, you can provide your own CL:OPEN to sandbox the file system.
7:12:32
MichaelRaskin
Well, sure, overwriting the compiled code cache does count as «special manipulation»
7:12:52
pjb
This would be required to avoid breaking out of the CL sandbox by generating a patched executable in the file system, and relaunching…
7:13:08
MichaelRaskin
pjb: yes, I have already said a few lines above that SICL is structured in a way that makes this a non-issue
7:14:15
MichaelRaskin
Protecting the code generator by default is what SBCL can do (and I expect that it does) via package locks
7:23:59
beach
phoe: Maybe I should not let you stream my presentation. I mean, first-class global environments are useless anyway, since the same effect can be had with package locks. Plus, it makes it necessary to change how inlining works, and it requires special definitions of CL:OPEN. Worse, it makes the 90/90 rule much worse.
7:25:27
MichaelRaskin
beach: it doesn't make 90/90 rule worse — I just said that 90/90 rule applies to implementing FCGE's in existing implementations without rewriting
7:26:44
MichaelRaskin
FCGE's in SICL, on the other hand, will be nice and useful and usable for defining a true sandbox for untrusted code with reasonable amount of work.
7:27:04
beach
This mode of discourse makes me tired, and I am not looking forward to answering remarks in real time when the presentation is streamed.