freenode/#sicl - IRC Chatlog
Search
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.