freenode/#sicl - IRC Chatlog
Search
3:38:59
beach
scymtym: Thanks. I will re-install my working version of SBCL and use it to compile the latest version.
3:59:36
beach
Problem fixed. Sourceforge is still unavailable, but I happened to have the sources for 2.0.1 around, so I used 1.5.3 to build 2.0.1 and I can now run the boot procedure again.
4:05:45
beach
alandipert: I don't see anything wrong with your scheme. But then, tree shaking is not something that I have given much thought. SICL needs the compiler to create things like effective methods and discriminating functions, and the compiler would probably suck in most of the rest of the system as well, so I don't think a tree shaker would be of much use for SICL.
6:53:35
Harag
so I am thinking about what the sandbox should allow and what not, things like should you be able to add a quicklisp library or should I just limit it to simple scripts.
6:57:00
beach
Not really. There seems to be different opinions about the goal of sandboxing. Mine is to keep the system "safe" by making it impossible to (say) alter the code generator of the compiler. Others want to go much further and allow the system to be used over the web without crashing.
7:01:35
no-defun-allowed
Yeah, crashing is relatively good compared to being able to execute untrusted code.
7:11:24
Harag
well having to parse all the code to make it safe has practical limits I think, some where along the line you might as well just use cl implementations straight and not use the sandbox
7:13:47
beach
Well, I think the solution I suggested to you is "safe". It is possible to keep the system internally consistent by allowing only a subset of the system.
7:13:50
Harag
for web stuff you can start the sandox in a docker, so if it crashes it will just be replaced by another
7:14:54
beach
Again, objectives vary. Some want the system to be used in collaboration with others over the web.
7:18:53
Harag
just out of curiosity would it be practical/sipmle/possible to mark safe and un safe code in the compiler say of sicl so that you could just toggle a switch to say what is allowed and what not
7:20:57
beach
I doubt it. The compiler is invoked to create discriminating functions and effective method functions. Then it may need to execute arbitrary code.
10:51:17
pjb
Indeed, there are systems that are designed without a "shut-down" or "quit" function, but crash only, with a quick restart, without loss or damage. Cf. the work on EROS https://en.wikipedia.org/wiki/EROS_(microkernel)
12:57:15
froggey
beach: I've been investigating a bit more, and change-class on a funcallable-standard-object isn't defined at all. not by the standard and not by the MOP
12:57:26
froggey
it's probably best to not depend on it, even though it seems reasonable and works on some implementations, so I'll send PR to fix it if that's ok?
13:02:26
Bike
change-class really oughta be fine, though, as long as both the original and new are funcallable standard classes
13:05:09
beach
Yeah, I don't see how an implementation that doesn't allow this would be structured. But then, SBCL had a problem with it in the past.
13:09:53
froggey
mezzano probably does the same, but that's because it's not a case I've actually thought about. should be fairly easy to implement though
13:12:03
Bike
i suppose if you define (defmethod change-class ((o standard-object) ...) ...) the method could be used for funcallable standard objects since they're a subclass, but do something wrong
13:44:14
froggey
beach: opened PR #167. I've tested SICL boot on SBCL 2.0.2 and an older version which as the bug, no problems on either
13:45:50
froggey
alright. I'll get started on DEFSTRUCT next week, unless there's anything else you want me to target
14:02:04
froggey
notes I wrote during this: https://gist.github.com/froggey/6bd5dd147fa251cea96448d66f943ca0
14:07:27
froggey
I had to add cleavir2-mir to the asd dependencies to get it to load fresh, but aside from that there weren't any problems
14:35:10
alandipert
beach thanks for the feedback re: tree shaking, i'm definitely worried about code size in the presence of CLOS
14:37:17
alandipert
most broadly, that generic function dispatch involves an algorithm without a javascript equivalent, so i'll definitely need to ship extra runtime to support it
14:39:39
alandipert
maybe by the time i've added 35mb of things to JACL everyone's internet will be way faster
14:39:46
froggey
it is? modern websites don't seem to have any problem slinging giant lumps of javascript around
14:40:00
beach
Now you are assuming that 1. JACL is as big as SBCL, and 2. It all has to be downloaded at once.
14:41:12
alandipert
but the better jacl compares to regular JS in this regard, the easier it will be for me to make a business case to use it. so the quality is valuable by itself, although probably not valuable enough to pursue right now
14:41:53
alandipert
yeah, i thought maybe lazy loading also. or split the runtime into separate deliverables that can be cached
14:43:19
alandipert
the other thing contributing to my worry is the discussion i had with the JSCL creator, he sees CLOS as the single greatest reason he doesn't think JSCL will ever be practical
14:58:01
beach
OK, let's see what is left to do for SICL. The printer is being worked on by lonjil. We haven't heard from aun for some time about the bignums, but that's not terribly urgent. froggey is going to do DEFSTRUCT. jackdaniel is working on Clostrum. We have the streams code from Mezzano.
14:58:11
beach
It looks to me like we mostly need to load all the code that is now executed by the host, i.e., Eclector, Cleavir2, the compiler backend. The LOOP macro expander. FORMAT. The garbage collector. And there are a few things in the code generator that remain.
14:58:13
beach
Now, once we load all this with the code generator turned on, things are going to get seriously slow. So having heisig's HIR evaluator would be very good. I am still willing to make an initial version with Boehm GC just to avoid debugging the GC at the same time as the rest. That way, I can put off generating all those tables by the compiler.
15:00:09
beach
But if we can get the speed up on host execution, we can run some ANSI tests before creating an executable.
15:00:46
beach
Oh, and there are still some impure objects in environment E5. That must be taken care of as well.
15:06:27
beach
So maybe my work in the near future will be to find and fix all the little things that need fixing in order for the generation of a native executable to be possible.
15:08:39
beach
I suppose I could attempt to load all those things that are now executed by the host, but one by one, just to make sure I repair all the problems before we really need to have them loaded.