libera/#sicl - IRC Chatlog

3:00:23 beach nij-: The plan is for the initial executable to contain everything. There is no particular reason to load a small executable.

3:01:10 nij- Hmm

3:02:09 nij- How is that achieved?

3:02:20 nij- For example, at some moment Constrictor has to be loaded.

3:02:40 beach We just load it. We can execute target code at bootstrapping time.

3:02:41 nij- Does SICL (the builder) load Constrictor into the image that will produce the executable?

3:03:09 beach It will when I am done with the bootstrapping procedure, yes.

3:03:32 nij- So first we have the "baby" in the image of SICL (the builder).

3:03:42 nij- All the libs are fed to that "baby".

3:03:58 nij- Eventually the fed baby is serializd into x86 codeA?

3:04:07 nij- baby (now fed)*

3:04:26 beach It is more complicated than that. The main difference between SICL and other Common Lisp implementation is that we can execute target code during bootstrapping.

3:05:15 nij- Does that mean one can interact with that baby (still in the image) before it's serialized to x86 code?

3:05:27 nij- And later it will be serialized into x86 code?

3:06:05 beach Yes, in fact I wrote a REPL function the other day to make it easier.

3:06:51 nij- ... That sounds hard. I don't see how it's possible.

3:06:54 beach So in phase 1 of bootstrapping, we use host generic functions and host classes to build CLOS. Then, we use those to build CLOS again in phase 2, but this time with something I all bridge generic function and bridge classes. Then we use those to build CLOS again in phase 3, this time with something I call ersatz generic functions and ersatz classes.

3:07:09 nij- Basically, you have a running CL in another CL. Later, you serialized that running CL..

3:07:34 beach Those ersatz objects have a structure that is isomorphic to the target objects, so we can generate an executable from them.

3:07:35 nij- How could it be both running, and serializable? A clever tree-shake has to be done.

3:08:22 beach It is all about first-class global environments as implemented by Clostrum.

3:08:51 beach There will be an initial Clostrum environment that contains everything to put in the executable.

3:09:13 beach Things that are not there, like host stuff, just won't be included.

3:09:33 nij- If you can serialize a running CL and only the running CL in the image.

3:09:50 nij- Doesn't that mean a small CL script can also be produced in this way?

3:09:58 nij- Cleanly tree-shaken.

3:10:28 nij- small CL script => tiny executable that only does what that script does, but doesn't contain things that it doesn't use.

3:12:24 beach I don't know. Like I said, I have enough of other things to thing about, so I don't worry about that use case.

3:13:01 nij- Sure.

3:13:12 nij- Still I find it more amazing this time. I'd like to learn more details..

3:13:39 nij- Would it work if the host isn't running as an x86 executable?

3:14:24 beach The SICL bootstrapping procedure needs a host that is a conforming Common Lisp implementation that also has the CLOSER-MOP library.

3:14:30 beach It doesn't require anything else.

3:14:51 beach In particular, it doesn't depend on how the host is implemented.

3:15:55 nij- Sounds like magic..

3:16:33 nij- What happens when you serialize the running lisp into the executable?

3:16:42 nij- That's the most magical part.

3:16:50 beach It is not serializing the running Lisp.

3:17:35 beach The ersatz functions are executable in the host, but they also contain executable code created by the SICL compiler, and that the host is not concerned about.

3:17:43 beach To the host, it is just a vector of bytes.

3:18:28 nij- Oh!

3:19:42 beach The difference with SICL is the first part, i.e., that those ersatz functions are executable in the host.

3:21:11 nij- Yes.

3:21:33 nij- It doesn't have to be running only after being dumped from SICL (the builder).

3:22:22 nij- Are ersatz functions already in a form "close enough" to x86 code?

3:22:30 beach That makes no difference. There will be a function executing in the host that creates a SICL executable. That function won't kill the host automatically.

3:23:17 beach An ersatz function contains (or will contain) a vector of bytes that is x86 code, or some other binary code.

3:23:48 nij- Is there an emulated x86 VM in SICL the builder?

3:24:02 nij- (Or will there be* Lets pretend that when SICL is done.)

3:24:43 beach Nope, the ersatz functions are host executable with the host mechanism. It does not touch the x86 code.

3:25:31 nij- Ok.. so the ersatz thing will be dumped to an x86 executable in the end, ?

3:25:52 nij- The ersatz thing, before being dumped, undergoes a sequence of stages.

3:25:56 beach Yes, and the ersatz "things" are referred to by a first-class global environment.

3:26:31 beach The ersatz objects are generated starting in phase 3 of the bootstrapping procedure.

3:26:34 nij- In the beginning, it is a minimal core. And when it loads, say, Constrictor, some mechanism has to compile constrictor into a format that can be "added on" that minimal core?

3:26:49 beach There is no "minimal core".

3:27:10 beach In the beginning, there is the full host Common Lisp implementation and the CLOSER-MOP library.

3:27:58 beach In the beginning, the SICL compiler runs as a host function, operating on a first-class global environment.

3:29:12 beach The SICL compiler takes a first-class global environment as one of its arguments, and that's where it looks up definitions of functions, classes etc. and that's where it stores the objects it creates.

3:29:15 nij- ACTION listening and anticipating.. feeling close.

3:30:19 beach So in the beginning (phase 1), ENSURE-CLASS and ENSURE-GENERIC-FUNCTION are defined to create host objects and store them in the first Clostrum environment.

3:31:09 beach And the first Clostrum environment contains loads of host functions that we use initially, such as the CONS functions, the SEQUENCE functions, and more.

3:31:37 nij- (Does this happen after loading Constrictors and such?)

3:31:45 beach Before.

3:31:49 nij- cool

3:31:52 nij- ACTION keeps listening

3:32:13 beach Constrictor is not needed until at the end, because we can use host functions that do the same thing.

3:32:30 nij- ACTION nods

3:32:40 beach So you can say that host functions are gradually replaced by target functions.

3:33:26 beach The host-executable code created at bootstrapping time is not necessarily very fast, so it is faster to use host functions when possible during bootstrapping.

3:34:11 nij- ACTION nods

3:34:43 beach The SICL specific aspect here, is that we always have a (nearly) complete Common Lisp system into which we can load arbitrary code.

3:35:09 beach Initially, that system contains lots of host code, but in the end, it contains only SICL code.

3:35:35 nij- Is system a 1st class global env?

3:36:08 beach Sort of, yes. It is the objects referred to by a first-class global environment.

3:36:33 beach So the reason I was so happy about ctype yesterday was that ctype requires a very complete Common Lisp system, and I had to make that happen in order to load ctype.

3:37:09 beach But the same thing can be said about other system we need to load, so the work had to be done anyway at some point.

3:37:43 nij- Do you mean "almost complete" instead of "very complete"?

3:37:51 beach Sure.

3:38:01 nij- Oh.. ok! That's nice!

3:38:38 nij- The SICL compiler compiles CL forms into x86 instructions like objects?

3:39:02 nij- Using the global environment as it's "lookup table"?

3:39:32 beach Using a first-class global environment to look things up, yes.

3:40:43 nij- I know it's not of your interest yet. But imagine if the last executable has to be in other form, would it be very difficult (once the x86 version sicl is done)?

3:40:55 nij- Or we can just toggle an option in Cleavir, and voila?

3:41:21 nij- (other form: say arm64 or LLVM)

3:41:41 beach Oh, no problem. Just select the backend to generate code for.

3:42:16 beach That's what i want the backend library for (that younder might be working on) so that this code doesn't have to be in SICL.

3:42:30 nij- Then the ersatz thing will then be vectors that represents arm64 (say) code?

3:42:37 beach Correct.

3:42:54 nij- It can also be vectors that represents LLVM IR?!?!

3:43:32 beach It would have to be executable I think, since what is generated is an ELF executable file.

3:44:18 nij- "It"?

3:45:05 beach The instructions in the ELF files would have to be native instructions I think, unless there is a mechanism that I am unaware of.

3:45:24 nij- Hmmmmmmm

3:45:40 nij- But there are no files yet..

3:45:59 nij- (I was referring to the ersatz thing.)

3:46:00 beach What do you mean?

3:46:19 beach Right, I am not at that stage in implementing the bootstrapping procedure yet.

3:46:26 beach I am still working on phase 2.

3:46:44 nij- (And I'm asking about phase 3?)

3:47:48 nij- Lemme read the bootstrap paper again. I think I can get much more from that now.. and I can ask slightly better questions.)

3:48:04 beach Before the very end of bootstrapping there are still no files. There is just a graph of objects that is isomorphic to the one that will be put in the executable file. But the vector of bytes in the ersatz functions I think must be native code.

3:48:57 nij- What I'm wondering mainly now..

3:49:10 nij- is that if a ersatz function is a vector that's almost x86 code,

3:49:20 nij- and if your host doesn't have an x86 emulator inside,

3:49:29 nij- and if your host isn't running on an x86 machine,

3:49:33 beach Let me be more precise...

3:49:38 nij- how would that ersatz function be executed?

3:51:03 beach An ersatz function is a host instance of host FUNCALLABLE-STANDARD-CLASS so it is executable in the host. But that instance is otherwise just a HEADER object as required by SICL. The HEADER object contains a RACK object that contains all the SICL-required stuff.

3:51:16 beach The host never looks at the RACK, and just executes the HEADER.

3:52:08 beach The end of the SICL bootstrapping procedure does not look at the executable code in the header, and is only concerned with its structure and the contents of the RACK.

3:56:36 nij- HEADER, RACK - these are things I need to learn from the paper. Thank you :-)

3:56:47 beach Sure.

3:57:20 beach nij-: You might be the first person to take a serious interest in the SICL bootstrapping procedure. :)

3:57:56 beach I mean, some people, like bike, probably understand the underlying principles, but I doubt that even bike has kept up with the details.

3:57:58 nij- I find it very interesting and magical.

3:58:10 nij- I was waiting for the whole day haha

3:58:20 nij- I don't either.. yet.

3:58:40 beach Well, it is different, which is why it had to be invented. But not magical.

3:59:34 nij- The other techniques make sense very quickly.

3:59:43 beach Which ones?

3:59:47 nij- But this approach.. when I heard of its goal it seems impossible.

4:00:13 nij- Like clasp (at least when bike describes) or compilers for some other langs.

4:00:18 nij- Or sbcl.

4:00:26 beach I see.

4:00:51 nij- But yeah.. I'm still not convinced (?) that this is going to work. That's why I want to read the paper.

4:00:55 nij- again)

4:02:06 beach As I often put it, the graph of objects (classes, generic functions, methods) defined by the AMOP could be created "manually", but it would be tedious, error prone, and unmaintainable. The best way to create this graph, is by executing CLOS code, like DEFGENERIC, DEFCLASS, and DEFMETHOD forms, so that's what I had to make possible in order to create CLOS first during bootstrapping.

4:02:10 nij- Oh ok header and rack are in section 4. I remembered reading them.

4:03:09 beach And I had to create CLOS first so that I could load arbitrary Common Lisp code after that, because such code would be much nicer if it can use CLOS.

4:03:58 nij- I intuitively guess that if this takes off development will be much quicker.

4:04:10 nij- very nooby and naive guess tho

4:04:14 beach I hope so, yes.

4:04:22 beach Things will be more maintainable.

4:04:49 beach In particular, we can now extract lost of code that was previously SICL specific into libraries that can be maintained separately.

4:05:09 beach There won't be much left of SICL in the end; just bootstrapping.

4:05:46 beach And even that... We have already extracted the Common Boot library that makes it possible to execute host code during bootstrapping.

4:06:52 beach The desired outcome is to make it much easier to create a new Common Lisp implementation, and SICL will be the first one to benefit.

4:13:25 nij- !!

4:13:32 nij- In the end of 4.2 http://metamodular.com/SICL/bootstrapping.pdf

4:13:54 nij- Say, Constrictors, after loaded into the host, are compiled into two different forms?

4:14:16 nij- One is x86 code, and one is simple subset of CL code?

4:14:38 nij- They are stored in an object. When called from the host, the second one is used.

4:14:52 nij- But after it's dumped to an executable, effectively the first one is used?

4:15:05 nij- So we're assuming that these two result have identical behaviors?

4:15:33 beach Correct.

4:16:29 nij- Hmm.. so that one needs to make sure they have identical behaviors..

4:16:40 nij- If they don't it would be very difficult to debug :-(

4:17:00 nij- And if that's the case, that ruins the point of having the thing being executable in the host, right?

4:17:30 beach Indeed. But in both cases, the source code is translated to an AST, and the host code is a very simple translation of that AST to simple host code.

4:17:49 beach I mean, it is the same AST in both cases.

4:18:45 nij- What is that subset called? And how to compile to that subset?

4:19:03 beach If the translation to host code is buggy, the more likely outcome is that the problem will show up during bootstrapping. This has already happened a few times.

4:19:35 nij- Oh, and also, if (2) doesn't have to be dumped, and all (2)'s point is to make a proxy of (1) before dump, why don't we just use ordinary CL code? Why bother compiling it into CL-subset?

4:20:18 beach It has no name. It is located in the Common Boot library. First and AST is created, then there is a generic function named CPS that translates the AST into CPS code using a trampoline.

4:21:17 beach Because only a small subset is needed from the AST.

4:21:56 nij- But isn't the point of keeping (2) in the host to have it being executed in the host?

4:22:07 nij- (2) doesn't have to be dumped into the final product, right?

4:22:27 nij- Why do we risk compiling it into CL-subset? It can be done, but if there's no point, then that's a pure risk.

4:23:11 beach I am not expressing myself very well. It uses all the Common Lisp features that it needs, so there is no particular effort in making it a subset.

4:23:31 beach It is just that what is generated from the AST *is* a subset.

4:24:14 nij- I see.

4:24:25 nij- Code -> AST -> (1)+(2)

4:24:36 nij- Why dont we make (2) to be the same as Code?

4:24:48 beach Same as what?

4:24:50 nij- Why must we obtain (2) from AST?

4:25:38 beach Well, 1 is x86 code, so then we would have to have an x86 emulator in the host.

4:26:23 nij- Err. Sorry, I meant:

4:26:36 beach From the AST, 2 is obtained by the CPS translator. 1 is obtained by turning the AST into intermediate representation and then to native code.

4:26:49 nij- Code (e.g. Constrictor) -> AST -> (1: almost x86 code, but vector) + (2: CL-subset code)

4:27:10 nij- Why don't replace (2:..) by Code in the first step?

4:27:34 nij- It seems that you need (2:..) to be compiled from AST. Why do you need that?

4:27:34 beach Because then we would need an x86 emulator.

4:27:50 nij- Why? The host can execute Code by itself.

4:28:23 beach No it can't. We don't assume any particular Common Lisp implementation in the host. It may be running in ARM, or it may be an interpreter.

4:28:54 beach And even if it is an x86 Common Lisp implementation, the native code won't be the same in the host and the target.

4:29:14 beach The SICL native code is certainly not compatible with the host ABI.

4:29:19 nij- I'm confused.

4:29:30 nij- Code in the first step (e.g. Constrictor code), is in CL.

4:29:44 beach Yes.

4:30:01 nij- Why can't the host execute that CL code by itself? And instead why do we have to traslate that CL code to AST and to CL-subset?

4:30:37 beach But if it is executed directly by the host, then the host compiler will consult the host global environment, and it will define things in the host global environment, thereby clobbering host functions.

4:31:31 beach So we have to turn that code into something that uses a Clostrum environment.

4:31:55 beach We could do that by using a source translation of the code, but that requires the same analysis as the first pass of a compiler.

4:31:58 nij- !! This is key.

4:32:22 beach So we might as well use the first pass of the SICL compiler, which analyses that code and turns it into an AST.

4:32:24 nij- Lemme think.. (today is dense.)

4:32:53 beach I fully understand.

4:32:55 nij- I see. The host is an *ordinary* CL implementation. It doesn't know how to talk to the 1st class global env.

4:33:02 beach Correct.

4:33:13 nij- I'm fine with dense notions. The only problem is I have bad memory.

4:33:22 beach Welcome to the club.

4:33:27 nij- But if I truly understand a thing that sticks in my memory forever.

4:33:44 beach Again, I fully understand.

4:33:46 nij- (at least.. for >10 years I guess ha)

4:34:44 nij- Why would it be useful to be able to execute the end result in host before dump be useful?

4:34:55 nij- (I feel it is! But I don't see concretely.)

4:35:33 beach It depends on what you mean by "end result".

4:35:46 nij- The x86 executable.

4:35:53 beach That's not useful.

4:36:13 nij- I mean, why do we have to keep "(2)" for it to be executable?

4:36:17 nij- in the host*?

4:36:44 beach As I explained, creating the CLOS object graph is best done by executing CLOS code.

4:36:58 nij- Oh!

4:37:00 beach And I want CLOS early, so that libraries can be written using it.

4:37:05 nij- And we don't want to litter the host implementation.

4:37:07 nij- Oh!

4:37:12 nij- Oh! Ok!

4:37:20 nij- Ok!

4:37:31 beach For example, the SBCL compiler does not use CLOS.

4:37:47 beach Can you imagine how much more maintainable it would be if it could use CLOS?

4:38:08 nij- ACTION imagining..

4:38:36 beach I mean, I can't imagine writing much Common Lisp code without using CLOS.

4:38:40 nij- SICL compiler on the other hand..

4:38:44 nij- is Cleavir,

4:38:46 beach No problem there.

4:38:51 nij- which is loaded in the bootstrapping process

4:39:03 nij- and Cleavir is executed in the form of "(2)"

4:39:15 beach Well, initially, it runs as a host function.

4:39:36 beach As a cross compiler if you like.

4:39:37 nij- But later, the compiler gets morphed into x86 like code?

4:39:46 beach Correct. At the end.

4:39:51 nij- That's insane :-O

4:40:16 nij- So in each phase, the compiler is "updated".

4:40:24 beach The compiler is not a particularly complicated Common Lisp program, in terms of the resources it needs.

4:40:34 nij- In phase 1, the compiler is an ordinary function in the host, and of course it can use the host CLOS.

4:40:40 beach Yes.

4:40:57 nij- In phase 2, the compiler is already in the form (2)?

4:41:02 beach In fact, we don't need the backend of the compiler until the very end.

4:41:20 beach No, the compiler is a cross compiler until the very end.

4:41:35 beach Then it is loaded just like Constrictor, Eclector, etc.

4:41:51 nij- Before the very end, the compiler is a host function?

4:41:53 nij- remains*

4:42:04 nij- If that's the case, then surely it can use CLOS..

4:42:12 beach Yes, or a "cross compiler" like I said.

4:42:21 nij- (I don't know what that term is..)

4:42:40 beach Absolutely. The compiler can be written using the full Common Lisp language.

4:43:21 beach SBCL and other Common Lisp implementations have a problem in that they load CLOS last.

4:43:50 beach This is for historical reasons. These implementations were created before the standard was written so before CLOS was part of the language.

4:44:18 beach So, historically, they had a compiler that used only pre-CLOS features.

4:44:47 beach This means that a large part of the system must be written without the use of CLOS.

4:45:06 beach So then, the maintainability suffers.

4:45:16 nij- I'm confused.

4:45:20 nij- Lets just focus on sbcl.

4:45:25 beach OK.

4:45:34 nij- To my understanding, sbcl first generates a minimal core.

4:45:38 nij- (cold init? forgot the name)

4:45:44 beach Yes.

4:45:52 nij- that minimal core is dumped as a x86 (say) binary file

4:46:01 beach Yes.

4:46:02 nij- and then the host generates baby food for that minimal core to eat

4:46:39 beach Yes, and that "food" is basically a bunch of concatenated FASL files.

4:46:40 nij- (baby food are just vectors that represent memory of the minimal core)

4:47:00 nij- Ok, when you talked about that sbcl's compiler doesn't use CLOS..

4:47:11 nij- do you mean the compiler in the host that generates baby food?

4:47:40 beach The SBCL compiler is written in portable Common Lisp that does not use CLOS, whether it executes in the host or in the target.

4:48:06 nij- Hmm oh.

4:48:21 nij- So one project is to rewrite SBCL compiler in CLOS, right?

4:48:31 nij- Then though the cold init can't be executed in the host,

4:48:42 nij- the dev process would be much better?

4:48:43 beach The SBCL maintainers don't want that. Especially not stassats.

4:48:49 nij- Hmmm why not?

4:48:56 nij- Is that going to make their lives too easy?

4:49:13 beach The excuse is that SBCL CLOS is slow, and he doesn't want the compiler to be slower.

4:49:51 beach But that's not enough to make it execute code in the host. You would also need first-class global environments, and the SBCL compiler is not written that way.

4:50:27 nij- !

4:50:42 beach So you see why I had to start from scratch with SICL....

4:51:00 beach It would not be possible to improve an existing Common Lisp implementation.

4:51:01 nij- In SICL, the (crossed?) compiler (before the end), as a host function, after phase one, always use the 1st class global env?

4:51:31 nij- Even before it's dumped in to an ersatz.. it uses the 1C Global Env already?

4:51:34 beach It uses first-class global environments from the start.

4:51:46 nij- ......................

4:51:56 beach The SICL compiler takes an ENVIRONMENT argument.

4:51:58 nij- ACTION mind blown (yeah, you mentioned this before, but i didn't realize)

4:52:18 nij- And it takes that so it doesn't litter the host.

4:52:21 nij- Dang

4:52:29 beach Exactly!

4:52:36 nij- Would it be slow, as the sbcl people worry?

4:53:30 beach Well, I don't buy the logic: 1. Don't make CLOS faster by using my generic dispatch technique. 2. As a result, don't improve the compiler by using CLOS. 3. Suffer.

4:54:10 nij- Hewsh!

4:54:21 nij- It's a whole lot of stuff but I really need to go to bed (1am here).

4:54:34 beach Sleep well.

4:54:39 nij- I may take some notes tomorrow. But I'm pretty sure I may forget some details..

4:54:42 beach I hope you an sleep. :)

4:54:43 nij- Thanks beach!

4:54:50 beach Pleasure.

7:36:28 beach` ** NICK beach

10:30:31 nij- Questions 20240403-063000:

10:30:31 nij- 1. Why do we care so much of not polluting the host?

10:30:31 nij- 2. How do we effectively ensure that there's no different between ersatz(1) and ersatz(2)?

10:30:31 nij- 3. Why can't ersatz(1) contain LLVM IR (or other IR) in general? After all in order to test them in the host, we only have to execute stuff in ersatz(2).

10:30:33 nij- 4. How will the end product (SICL-produced x86 executable) do garbage management? Do we also have a module that does that?

10:30:36 nij- 5. If we want to add supports (e.g. OS threads, weak pointer, local package.. etc) to the final executable, would it be possible without writing C bindings?

10:30:39 nij- 6. How many phases are there (E0~E5 in the paper?) in total, and what are the goals and (roughly all) steps in each phase?

10:30:42 nij- 7. Which phase are we currently in? Where is the code for E0, E1, E2, ..?

10:32:39 beach 1. The host may cease to work if polluted with target code. Like the host function ENSURE-GENERIC-FUNCTION creates a generic function in the host global environment. But that's not what the target function does.

10:33:26 beach 2. The only answer I can think of is that they are generated by the same code.

10:33:53 beach 3. Sure, it can contain LLVM IR if you like.

10:34:19 beach 4. The plan for the garbage collector is documented in the SICL specification.

10:35:04 beach 5. Anything is possible without C bindings. You can do it either directly i machine code, or in some kind of assembly, like Cluster input.

10:35:41 beach 6. I don't know how many phases there are, and it is kind of arbitrary how many you add beyond 4.

10:36:27 beach 7. Right now for the new bootstrapping procedure? There is no longer an E0, so it starts with E1, and I am currently working in E2.

10:43:51 nij- 5.1. Can we do it in common lisp, and can we observe their effects in the host (before dump)?

10:46:03 beach Sure, it can be done in Common Lisp since we can always create Cluster instructions from Common Lisp. But we won't be able to execute target native code in the host. Again, that would require an x86 emulator, and the host probably would not allow it.

10:47:48 beach nij-: I am off for a lunch break. Further questions will be answered when I get back, or perhaps by some other participants.

10:50:27 nij- Wow.

10:52:49 nij- Say after SICL is done and got extension of OS threads - before dump, we can interact with SICL executable (predumped) in the host, and that's going to have OS threads effectively?!?!

10:53:23 nij- Will that predumped SICL also have a working garbage collector and a working debugger?!

10:58:57 nij- 6.1. Any plans on laying them out first? It may be easier when implementing, and it would allow more people to join the discussion. Higher levels can be cast out, and perhaps we can discover issues or the possible need of large-scale rewrite ahead of time.

12:39:03 beach No, I don't see a way that you can interact with OS aspects of SICL before it is dumped.

12:39:34 beach Same with the garbage collector.

12:39:44 nij- Oh.. :(

12:41:16 beach The debugger might work. In fact, we already have a primitive "debugger". I am not sure how to organize the debugger yet. I would like to see the preferred way to use SICL to be through a CLIM-based IDE.

12:42:04 beach 6.1 I don't know what you mean by "laying them out first".

12:45:44 nij- 6.1- Have a plan on what each phase has to accomplish, written in English.

12:47:30 beach I can't do that until I have actually implemented the phases.

12:47:46 beach I am unable to dream up a design independently of implementing it.

12:51:38 nij- I see. There may be too many details.

12:52:24 beach For my small brain, definitely.

12:54:19 nij- (hmmmmm)

12:56:21 yitzi beach: I know you haven't gotten to khazern, etc. ... but I don't remember if I told you that did some significant work on Cyclosis. It can be loaded extrinsically now which means there will definately be changes when you get to that stage in bootstrapping.

12:56:35 yitzi s/did/I did/

12:57:24 beach Yes, I pulled it and noticed. I'll deal with it when I get to it. Thanks for letting me know. I do use Khazern already.

12:58:25 yitzi Ok. Please let me know if I can help in any way. One of the things I added to Cyclosis was a "transcoding" api that takes care of stream-external-format.

13:05:33 beach Will do! Thanks!