Comment by lispm | Hacker News Reader

Comment by lispm | Hacker News Reader

Parent Full thread

I have literally started a VLM (Portable Genera 2.0.6) with a Genera 9.0.6 world. In the "herald" the software says that it is running Genera 9.0.6. You can claim "You are purposefully conflating Portable Genera, Open Genera and Genera.", but I'm actually looking at it now and you don't. Please don't tell me this BS, when I'm right now reading the screen in front of me.

> You mention a bunch of things that are also _not_ part of Genera

Of course they are. I have the thing right in front of me, running. I'm typing to it. I'm looking at the system definition of SYSTEM 501. On a live running Genera 9 on a VLM. If I would look at my MacIvory running Genera 8 it also would not look much too different.

Stuff like EH has been long superseded. The Scheduler has been redesigned & rewritten. TV has mostly been superseded by Dynamic Windows. The Garbage Collector has been extended, by new GC variants.

> Open Genera did very little on top of Genera at that, mostly targeting and making it work on the Ivory.

Open Genera does not work on the Ivory processor. It's a Virtual Lisp Machine.

> Genera is a Lisp Machine system based on the work done at MIT, where most of the guts still the same. To the point that how you rebootstrap the system is the same, how the core areas look work, how the scheduler works, how the windowing system works, how flavours works, etc.

The Scheduler works different (the old scheduler polled, the new own is event driven), the window system is now Dynamic Windows, Flavors has been updated to New Flavors & the new CLOS (the Common Lisp Object System), ...

you know you don't need tell everyone how you have palter's vlm to look at rel-8-5's sysdcl which has been leaked and hosted on public sites since forever. for example https://archives.loomcom.com/genera/symbolics/sys.sct/sys/sy... rel9's sysdcl is not substantially different anyway, the list of module components is the same.

ams's hyperbolic perhaps point is that genera is significantly SYSTEM, that symbolics contribution is a kind of obvious extension of the grand vision that was already there in its totality and potential in the MIT's work. I think it's a valid argument, which I don't think can be resolved just by listing names of subsystems.

for example you can't just say "oh they replaced tv and window with dynamic windows", because dw uses both tv and legacy, for lack of better term, window. if you look at the flavor definition of basic dynamic-window it uses tv:stream-mixin tv:graphics-mixin and tv:minimum-window. and tv minimum-window is a venerable SYSTEM flavor. not to mention that other systems (like zwei) still use tv window directly. how thick a layer dynamic-window is on top of tv? answering that question require systems level knowledge and investigation.

other symbolics extensions are of similar nature.

> you know you don't need tell everyone how you have palter's vlm to look at rel-8-5's sysdcl which has been leaked and hosted on public sites since forever

I'm not sure what you are talking about. It's not related to what I wrote.

> how thick a layer dynamic-window is on top of tv? answering that question require systems level knowledge and investigation.

Dynamic Windows introduced a new UI look and feel, different from the old "static windows". DW has new APIs even for reimplementations of old UI features from TV , like the new drawing interface in the graphics package, which replaces the old TV flavor messages, with generic functions. It has also a lot of new features, like the presentation system. Later applications typically will use the new DW interfaces and new features. Both DW and TC are documented in "Programming the User Interface", with DW providing much of the high-level application window features, described in the first chapters.

There is another version of it, in another implementation, which is CLIM, which is then based on CLOS. Even later applications were thought to use the CLIM interfaces, to be able to write portable user interfaces, able to run on various other Lisp systems. Both DW and CLIM are substantially different from TV. Neither DW, nor CLIM are in the MIT software.

Other symbolics extensions are of similar nature.

> Other symbolics extensions are of similar nature.

Sure, and those extensions can run on the MIT Lisp Machine.

But we are taking about the base system. Not extensions. And why one can take those systems and for the most part just run them in another system is cause they are so similar!

Good luck with that. I don't think that's possible.

It is possible, I did it. It isn't hard (mostly boring work with bunch of shims).

The reason is as I said before, Genera is layers on top of an existing system that hasn't changed (much).

E.g, DW is of flavours on top of TV (with lots and lots of extra additions .. additions are easy to handle -- after all the DW code is like 1M of Lisp from 1989 or whatever).

The Dynamic Listener was more complicated to rip out, but mostly work. The hard part, at which I gave up, was adding all the presentations for objects and other such.

Can't talk about the rest, but some spelunking led me to finding that TV was "legacy" component in later Genera options, working properly only on the main console and, due to significant emulation work, on MacIvory through RPC to host Mac.

DW/CLIM treated TV as one possible driver, if not sidestepped it, the problem was that some software (iirc mainly related to some S-Graphics products) had some hardcoded TV dependencies from earlier versions - it's mentioned as part of the porting plans for OpenGenera, because OpenGenera has no working TV subsystem at all, because TV didn't work over X11.

Right, Open Genera uses ONLY an X11 console, and thus requires TCP/IP.

But that was the case on other machines, too. The embedded UX400/1200 machines and the headless NXP1000 use an X11 console, too.

Lots of TV software does not run on these machines, because they don't have a framebuffer.

Reply on news.ycombinator.com