https://github.com/arialdomartini/morris-worm/tree/master
Has the decompiled version.
362 karma · joined January 11, 2024
Has the decompiled version.
programs.
] Pointer Fields Now 25 Bits; Flag Bit Gone.
Each typed data word in Lisp machine memory used to have one bit called the "flag bit" which was not considered part of the contents of the word. This is no longer so. There is no longer a flag bit; instead, the pointer field This extra bit extends the range of integers that can be represented without allocation of storage, and also extends the precision of small-floats by one bit.
On the Lambda processor, the maximum size of virtual memory is doubled. This is the primary reason for the change. Unfortunately, the CADR mapping hardware is not able to use the extra bit as an address bit, so the maximum virtual memory size on a CADR is unchanged.
The functions %24-BIT-PLUS, %24-BIT-DIFFERENCE and %24-BIT-TIMES still produce only 24 bits of result. If you wish to have a result the full size of the pointer field, however wide that is, you should use the functions %POINTER-DIFFERENCE and %POINTER-TIMES (the last is new), and %MAKE-POINTER-OFFSET with a first argument of DTP-FIX to do addition.
The functions %FLOAT-DOUBLE, %DIVIDE-DOUBLE, %REMAINDER-DOUBLE and %MULTIPLY-FRACTIONS use the full width of the pointer field.
The values returned by SXHASH have not changed! They are always positive > If Stallman had started with a kernel, there would be very few people who had the legal right to run any utilities or apps on the new kernel
Note however, that you can't use diff on binaries, [...]
fossil diff --command "compare"
As for storing binaries, unversioned files have no history, and are not synced automatically.
GCC does basically the same thing even today,
In this case, one reason why "wagon return" might have made more sense is because there is a wagon that holds the platen of the typewriter.
From https://lists.squeakfoundation.org/pipermail/squeak-dev/1998...
Ralph -
Many times I have browsed past your article "About the Smalltalk
Balloon" and been tempted to add to the little bit of history that you
have there. While your link is entitled "Why a hot-air balloon is the
symbol of Smalltalk," you never really answer the question. The time
has come to tie up that loose end. Return with us now to those
thrilling days of yesteryear, and
The Real Story About the Smalltalk Balloon
Everyone in our group wanted to challenge the ivory tower image in
Byte's special issue on Pascal, because in fact we were all working
intensely to get Smalltalk-80 out the door from Xerox at the time.
The cover of that issue depicted the "land of Smalltalk" as a remote
island, and that triggered a connection for me out of which was born
the fanstasy of liberating Smalltalk from the ivory tower by balloon
ascent.
Here is the connection...
My favorite book from youth was The Mysterious Island, by Jules Verne.
It is the story of an engineer, Cyrus Harding, who gets blown far
afield in a storm during a balloon surveillance mission in the 1860's.
He ends up stranded on an island but, through ingenuity and a bit of
luck, he manages to recreate most of the accomplishments and comforts
of civilization on his own (with a little help from an amiable
orangutan ;-). Cyrus Harding became my childhood standard for
resourcefulness and the conviction that anything can be accomplished
if you are clever and persistent.
The fantasy of a balloon as the vehicle for Smalltalk's release stuck
with me from then on. When the opportunity came to design the cover
for the Byte issue on Smalltalk, I made the suggestion of the balloon
lifting off from the island shown on the Pascal cover, and everyone
picked up on it. Robert Tinney executed the wonderful graphic that we
know so well, and the rest is history.
- Dan
P.S. There is a further coincidence in this particular literary
allusion: It is revealed at the end of The Mysterious Island that the
island is actually the base of operations for a more well-known Verne
character, and that character happens also to be the childhood hero of
a more well-known figure in the history of Smalltalk.Not everything needs a "release" to be alive.
The current state is _very_ fast in simulation to the point where it is uninteresting (there are other things to figure out) to write something as a behavioral model of the '181/'182.
~100 microcode instructions takes about 0.1 seconds to run.
Seeing that not even "Original Gangster" Lisp Machine used Lisp ...
Both the Lambda and CADR are RISCy machines with very little specific to Lisp (the CADR was designed specifically to just run generic VM instructions, one cool hack on the CADR was to run PDP-10 instructions).
By Emacs you definitely mean GNU Emacs -- there are other implementations of Emacs. To most people, what the Lisp Machine was (is?), was a full operating system with editor, compiler, debugger and very easy access to all levels of the system. Lisp .. wasn't the really interesting thing, Smalltalk, Oberon .. share the same idea.
And of course .. https://tumbleweed.nu/lm-3 .
Currently working on an accurate model of the MIT CADR in VHDL, and merging the various System source trees into one that should work for Lambda, and CADR.
Late 80's, very late ... but the concept of "notebooks" predates Mathematica by at least a decade (it was very common to embed structure in source code files with markup).
ADA was designed around a competition between four companies, to make it unbiased the proposals got named by colour.
Honeywell was Green, Intermetrics was Red, SofTech was Blue, and SRI was Yellow. There where no other colors.
The Lisp Machine macroinstructions aren't that complicated, it is a basically stack based machine -- the most complicated thing was handling of the function arguments from Lisp (FEF); which has complicated semantics when it comes to handling optional, keywords, and what not arguments.
Common Lisp was definitely not designed with the intention of better performance, the intention was literally to have a _common_ Lisp language that multiple implementations could use and where porting programs would be much easier. One needs to remember that when Common Lisp was first drafted, there where dozens of Lisp dialects -- all of them different.
The list of CPUs is a very large span, some predating Common Lisp (CLtL1 is from 1984, CLtL2 from 1990, and ANSI Common Lisp from 1996) by close to several years (VAX, from 1977).
But other than that, the idea of a not-Unix system does fall into those two buckets ... make it Unix, or rewrite everything. One can see this in Oberon, Smalltalk-78, Mezzano, etc...
Having showers at work is awesome, it means you can take a proper bike ride to work, and freshen up.
The threading code does seem to be "similar" enough to warrant some investigation, but from the looks no license notice was "removed". Even the threading code in question has never had one, from the initial import from CVS/Subversion.
Making a mountain out of a molehill .... before the molehill is even there?
FWIW -- I think this is the commit being talked about: https://github.com/m87h/libogc/commit/3ba50ecd4134ef37a0f18f...
Looks honestly totally innocent ...
Cross compilation for distributions is a mess, but it is because of a wide proliferation of build systems, not because of the GNU autotools -- which have probably the most sane way of doing cross compilation out there. E.g., distribution have to figure out why ./configure is not supporting --host cause someone decided on writing their own thing ...
> The main idea behind Autoconf is political. Autoconf based programs are deliberately intended to hinder those who are able to build a program on a non-GNU system and then want to make contributions while just staying on that system, not getting a whole GNU environment.
Nothing could be further from the truth, GNU autoconf started as a bunch of shared ./configure scripts so that programs COULD build on non-GNU system. It is also why GNU autoconf and GNU automake go such far lengths in supporting cross compilation to the point where you can build a compiler that targets one system, runs on another, and was build on a third (Canadian cross compile).
Not everything is C, or GNU/Linux. The example also misses much of the basic functionality that makes GNU autotools amazing.
The major benefit of GNU autotools is that it works well, specially for new platforms and cross compilation. If all you care about is your own system, a simple Makefile will do just fine. And with GNU autotools you can also pick to just use GNU autoconf .. or just GNU automake.
Having generated files in the release tarball is a good practise, why should users have to install a bunch of extra tools just to get PDF of the manual or other non-system specific files? It is not just build scripts all over the place, installing TeX Live just to get a PDF manual of something is super annoying.
Writing your own ./configure that works remotely as something users would expect is non-trivial, and complicated -- we did that 30 years ago before GNU autoconf. There is a reason why we stopped doing that ...
I'd go so far to think that GNU autotools is the most sensible build system out there...
And as someone who portedgor Doom working on GNU/Hurd decades ago … I’m going to wager that the GP has never used it. :-)