freenode/#sicl - IRC Chatlog
Search
4:28:26
no-defun-allowed
What microphone did you use to record voiceovers for the online presentations?
4:33:48
no-defun-allowed
Oh, because I'm trying to use OBS with a studio microphone, and the gain that I used to produce an acceptable volume doesn't seem have been applied in the recorded video.
4:35:13
no-defun-allowed
Yes, but the noise filter somehow still got applied, and most of my words were cut out, so I have to re-record.
4:36:03
beach
Yes, I see. :( Having to re-record happens to me pretty much every time, for one reason or another.
5:09:19
no-defun-allowed
Alright, I disabled the noise filter and now I just have to adjust the volume when I edit the clips together.
6:21:41
beach
With respect to my series of presentations for the online Lisp meeting, it is interesting to me that several people suggest better alternatives to C. I recently received email from Clive Tovero suggesting PreScheme and Scheme86. So I observe that there is still this widespread idea that a Common Lisp implementation must be written in something other than Common Lisp.
6:28:43
beach
Now, jackdaniel said that he likes the fact that ECL can be built on a system that has nothing other than C. I guess the only way to address that restriction is some kind of BOCL ("Bootstrap Common Lisp) idea, i.e. an implementation that only requires C, but that is designed with the sole purpose of bootstrapping "production" Common Lisp implementations.
6:30:04
beach
And then it is going to boil down to what is considered "source code". In other words, does the C source have to be written by hand, or can it be generated.
7:54:39
jackdaniel
mind, that I've added "given ecl's niche", in other words because its runtime is build on top of C's runtime
7:55:35
jackdaniel
so it is to some degree a pisix common lisp (if we acknowledge that posix is basically c plus os library with c api)
8:00:34
beach
That doesn't stop me from trying to come up with ideas to make ECL and Clasp maintenance burden lighter.
8:11:30
beach
For example, I suggested a long time ago that Clasp implement the possibility of saving and loading the image, because that would cut down on the additional code meant to make startup faster. It appears that this possibility is now about to be implemented.
12:35:06
pjb
beach: perhaps better than a C->CL->CL bootstrap, would be a CL cross compiler. Ie. if we're able to compile with a CL running on a system A a binary CL targetting a system B, then we don't need to bootstrap from different language anymore.
12:36:08
beach
And that is precisely what SICL is doing. But jackdaniel wants ECL to be possible to build on a system that has only C.
12:44:07
no-defun-allowed
Not exactly relevant is the way Squeak Smalltalk was bootstrapped, which I find a bit fascinating: http://ftp.squeak.org/docs/OOPSLA.Squeak.html
12:44:39
jackdaniel
if I understand correctly, you want to create a separate cl implementation for a sole purpose of bootstrapping from c (that is c -> cl -> cl); I think that ecl, as bootstrapped from c, already fills this gap so the task would be more or less opening the unlocked door. as of transpiling CL -> C, ecl's compiler also is capable of doing that, however it targets its own C-ish runtime of course
12:46:31
no-defun-allowed
That was produced by passing the source code for the interpreter in the Blue Book into a Smalltalk-to-C translator, as well as a small amount of C code for interfacing with the operating system. But HIR is much more complex than the subset of Smalltalk used in the interpreter, from memory.
12:46:46
beach
jackdaniel: Me? Yes, but the C code of ECL is more complicated than a BOCL would need, because ECL is designed with performance in mind. A BOCL could be much simpler, and then also simplify the C code of ECL, and even eliminate a lot of it.
12:47:46
beach
pjb: If you look at the channel logs, I asked the question (without expecting an answer) whether C code that is generated was acceptable as counting as "source code".