[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Shrinking the C core
From: |
Arthur Miller |
Subject: |
Re: Shrinking the C core |
Date: |
Tue, 29 Aug 2023 05:57:54 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Po Lu <luangruo@yahoo.com> writes:
> Arthur Miller <arthur.miller@live.com> writes:
>
>> Unix which? Unix is not a single program; it is a family of operating
>> systems, and I am quite sure nobody runs the same kernel they did back
>> in 1970. I don't know what you are talking about you have
>> "demonestrated". You said yourself *was* and not *is* which suggest
>> that those kernels are rewritten in order to support those C programs
>> that can be interlocked. Again you are constructing yourself things
>> here: I haven't said it is impossible to write mulththreaded C
>> application that can use locking.
>
> Each extant Unix system today contains gobs of code derived from the
> Unix kernel developed at BTL in the 1970s. None of their kernels were
> ever rewritten -- rather, they were subject to iterative refinement that
> eventually allowed them to operate on SMP systems.
>
>> There are many applicaitons that have been redesigned. Emacs has been
>> redesigned since its first incarnations as TECO editor if I have
>> understand the history. For the very last time: I haven't said Emacs
>> *can not be redesigned*, on the contrary, I said Emacs *should be*
>> redesigned. Emacs core so to say. You are fighting against things I
>> haven't said; I don't know why, if it is lack of English skill, or
>> something else, but we are talking constantly beside each other.
>
> Perhaps you define the word "rewrite" differently, but its customary
> meaning implies a reimplementation from square zero. My point is that
> doing so is a gratuitous and unnecessary gesture, and we would be better
> served by more realistic assessments and consequently more reasonable
> proposals.
>
>> Are you saying that a non-multihtreaded program written in C can
>> suddenly become multithreaded without being re-written to support
>> threading? Nevermind, you are totally, on purpose or lack of
>> understanding, missing the point: you have to rewrite stuff to make it
>> multithreaded regardless of the language if you intention is to have
>> Emacs core multithreaded. Supporting multithreading is not same as
>> having entire Emacs internals be multithreaded.
>
> Since when does interlocking call for a rewrite?
>
>> No, it does not because you have missunderstood that I mean something
>> else.
>
> Then clarify what it is, for the plans you present (rewriting Emacs in a
> different language) sure resemble plans for a complete grounds-up
> reimplementation.
>
>> I propose porting core API to Common Lisp because that would save you
>> implementing all those things that you need to make Emacs
>> multithreaded, better GC etc, because it is not a trivial task.
>
> At the cost of portability and control? No, thank you.
> Let me ask a question in turn: how many of the popular and often-cited
> Common Lisp implementations are as old as Emacs? What guarantee is
> there of their continued existence 10 or 20 years into the future?
>
>> Of course you can re-write all that stuff in C too, nobody is denying
>> that it is possible. I am saying there is no need to reduplicate the
>> work, and there are other benefits of having Emacs in Common Lisp.
>
> The work to be duplicated is menial and more-or-less already complete.
> The remaining bulk will need to be tackled irrespective of the language
> used to implement Emacs. The conclusion as to whether we should
> overcome that bulk as-is, of if we should compound it with the challenge
> of rewriting Emacs in a new language, is left as an exercise to the
> reader.
>
>> Look harder.
>
> Any examples?
>
>>>> Well yes, C is portable and fast, nobody denies that. So are some
>>>> CL
>>>> compilers.
>>>
>>> Which Common Lisp compiler is capable of linking with Java code
>>> through
>>> the JNI? (ABCL doesn't work, as the Android JVM can't interpret the
>>> bytecode it generates.)
>>
>> I don't know what you are trying to say; that sound like very
>> uninformed statement based on missunderstanding. Calling Java via
>> native API and generating bytecode that runs Lisp on top of Java as
>> ABCL does are two completely different and separate things. I am quite
>> sure Emacs does not generate Java byte code. But I don't see how is it
>> even relevant, I haven't suggested to run Emacs on JVM. Perhaps it is
>> possible who know, but I have suggested to use sbcl which is a native
>> compiler specialized for compiling Lisp (and runs on Android as well).
>
> It's not possible to load a Common Lisp image into the JVM, because the
> Java linker is only capable of linking compiled C objects that export C
> symbols. Therefore, SBCL cannot run within any GUI Android program,
> given that they must be started from Java.
>
>> "only" ? :-) I can asure you that Lispers have access to both kernel
>> and user space threads. Search on Bordeaux threads.
>
> That's only a wrapper library for the incoherent threading primitives
> furnished by different Common Lisp implementations.
>
>>> garbage collection strategies vary between machine types. I'm sure
>>> we
>>
>> Does it?
>
> Yes it does.
>
>> I am also sure everything is possible, it is software, as a wise old
>> grey head once said. It is just how much effort and resource you are
>> pouring into it. SBCL runs on basically all important platforms on
>> which Emacs runs, minus as mentioned DOS and Windows95; I don't know
>> if there is some other. But it is not the point. The point is: there
>> is another community working on the same problems you have or wish to
>> solve. And they have come far away than you. You could re-use their
>> work, and if you miss somethign add those missing parts so everyone
>> would benefit, or you can live in an isolated island and do everything
>> yourself.
>
> C is hardly an "isolated island". Anyway, we need a portable, fast,
> flexible and ubiquitous language, and Common Lisp doesn't fit the bill:
> if a platform as anodyne as Android poses problems for it, what about
> the next sandboxing contraption for Unix systems? Or any future system
> whose appearance down the line we cannot anticipate now? What if our
> requirements outgrow Common Lisp's capabilities?
>
>> I am telling you that sbcl/ccl has already solved those problems you
>> have to solve in order to have multithreading without having to lift
>> your lock.
>
> We have too. What we have not, they cannot offer either.
>
>>> Instead of denigrating the C language, Emacs's C core, and so many
>>> other
>>> components critical to Emacs that have been subject to unjustified
>>> invective in recent times, why not direct your attention to a more
>>
>> I don't think I understand how I "denigrate the C language" and what
>> "unjustify invective" in this case is, but I don't think it
>> matters. Once you also said I should be forbidden to talk about Emacs.
>
> It does, because such motives drive people to engage in many hours of
> time wasting wild goose chases, all to ascertain which language
> Providence meant for Emacs to be written in.
>
>>> direct your attention to a more
>>> productive task, such as identifying the complex interdependencies
>>> between different pieces of Emacs's global state to establish a
>>> detailed
>>> plan for their interlocking? For this task, the most important tool
>>> is
>>> a control-flow visualizer such as cflow, and an ample supply of
>>> paper.
>>
>> Can we save nature and our selves?
>
> Parse error, sorry.
>
>> Nor are you sole Emacs devs, aren't you? I don't think calling names
>> is appropriate, so I want, but I can come up with at least four people
>> who work on Emacs and who are experienced Lispers. How active they are
>> in development recently I don't know, I don't follow the list every
>> day as I am used to, but I certainly haven't targeted Eli nor you with
>> that one.
>
> Names? Would they be willing to take responsibility for the areas which
> we oversee, in the event a Common Lisp Emacs comes to pass?
Perhaps this recently released paper might be of interest to you:
https://applied-langua.ge/~hayley/swcl-gc.pdf
- Re: Shrinking the C core, (continued)
- Re: Shrinking the C core, Emanuel Berg, 2023/08/31
- Re: Shrinking the C core, Arthur Miller, 2023/08/28
- Re: Shrinking the C core, Po Lu, 2023/08/28
- Re: Shrinking the C core, Arthur Miller, 2023/08/28
- Re: Shrinking the C core, Po Lu, 2023/08/29
- Re: Shrinking the C core, Eli Zaretskii, 2023/08/29
- Re: Shrinking the C core,
Arthur Miller <=
- Re: Shrinking the C core, Richard Stallman, 2023/08/31
- Re: Shrinking the C core, Richard Stallman, 2023/08/30