[HECnet] RSTS/E started emitting "?EVTLOG (BLDNIC) -- %Integer error" messages

[Johnny Billquist]

On 2021-11-12 22:36, Thomas DeBellis wrote:
> gnuemacs?  There's a processor limitation or hardship?  That's never 
> occurred to me as I'm running on Tops-20 right now, which is plenty 
> different from anything else.  The M1 is still fairly new, so maybe 
> people haven't gotten around to gnuemacs just yet.  Some will insist on 
> vi...

It's more properly a question of how does a executable file look like 
for this specific platform. So it's directly about OS behavior, but this 
also leads to processor specifics.

Think about thinks like dynamically loaded libraries, the startup code, 
having the stack sane, registers setup, and all kind of stuff that ld 
would normally do for you. GnuEmacs have to do all of that itself.

And there is plenty of compiled code in GnuEmacs, as compared to lisp 
code. The whole lisp system itself, for example. But also some core 
functionality, which looks like Lisp functions are in fact written in C 
for speed.

But from this perspective, it's all very straight forward from a porting 
point of view. The problem do come when you want to basically dump all 
memory as a runnable file. (And you do not want to include shared 
libraries in that file, but instead actually set it up to load those 
libraries again when running, and all that other stuff mentioned above.)

   Johnny

> 
> I have done a microscopic amount of programming in gnu LISP to customize 
> it; in other words to make gnemacs work more like Tops-20/TENEX/ITS TECO 
> based EMACS so that it doesn't drive me crazy.  This code functions on 
> the other platforms I use (Mac OSX, Windows, Ubuntu) with no 
> modifications.  Obviously some kinds of key bindings are tricky as well 
> as fonts.
> 
> If you want to call it this, gnemacs does have some compiled code, that 
> is C based built-in functions.  I have had occasion to look at some of 
> the C source in order to make sure that I understood actually what was 
> going to be done.  I don't recall seeing any kind of a processor 
> restriction per se, although there could have been conditionals to 
> better leverage certain processors.
> 
> I guess you could differentiate it like the difference between MIDAS 
> based TECO and EMACS based TECO macros.
>> ------------------------------------------------------------------------
>> On 11/12/21 4:07 PM, Paul Koning wrote:
>>
>> I think Johnny was talking about current Emacs.  That might explain why it's hard to port -- for example, there is a Mac version (AquaMacs) but no Arm64 (Apple M1 chip) version because of the trickery associated with the dump machinery.
>>
>> 	paul
>>> ------------------------------------------------------------------------
>>> On Nov 12, 2021, at 3:49 PM, Thomas DeBellis<tommytimesharing at gmail.com>  wrote:
>>>
>>> I'm not 100% sure, but I don't believe that ITS/Tops-20/TENEX Emacs quite does this.  It is built on top of TECO, which you will recall as a language that is so terse that it looks like line noise.  I don't think it's a very big stretch to compare it a byte code interpreter.
>>>
>>> I do not recall that the EMACS libraries that are loaded are not quite compiled.  They have all the comments and unnecessary white space stripped out, which would, of course speed execution.
>>>
>>> gnuEmacs does a similar thing for the LISP code; it's still interpreted as I recall.
>>>
>>>> ------------------------------------------------------------------------
>>>> On 11/12/21 10:59 AM, Johnny Billquist wrote:
>>>>
>>>> RMS kept the idea alive in Emacs, where even today you fire up the core system, load all kind of libraries, and then you do a memory dump, which is the runnable Emacs image.
>>>>
>>>>    JOhnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol