lispm

> 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.

There are a lot more cities with good public transport...

and now it's a new portable VLM (DEC Alpha, x86-64, ARM64) with Genera 9.

ZWEI is no longer in the base system. EH does not exist, a Window system does not exist. Dynamic Windows is in the base system.

> The target processor is not that important from the users point of view

It's important for the operating system and the processor was used for very different machine hardware: standalone workstations, headless systems, embedded in a Mac, embedded in a SUN, embedded in a network switch, ...

> Lambda and CADR shared the exact same source code, and microcode.

But not the 3600, which was a 36 bit architecture and not the Ivory, which was a 40 bit microprocessor. A lot of the core routines were different on a 3600 and an Ivory machine. The VLM was even different, running on a 64bit microprocessor, implementing the emulator in C and assembler. There is low-level functionality which has two or three different implementations.

The Ivory machines could be very different from a LAMBDA and a CADR, for example as an embedded CPU in a very different host machine (Mac & SUN). That had a lot of consequences for the operating system.

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), ...

That was gone at a time when Lisp Machines were commercialized (81/82). Emacs there was called Zmacs and was written in Lisp. Maclisp was replaced by Lisp Machine Lisp / ZetaLisp / Common Lisp. UNIX was then a thing.

Open Genera in the early 90s then ran on OSF/1 UNIX (https://en.wikipedia.org/wiki/OSF/1 , renamed to Digital UNIX) on DEC Alpha. OSF meant Open Software Foundation ( https://en.wikipedia.org/wiki/Open_Software_Foundation ), a group propagating "open standards" for UNIX.

The core Symbolics SYSTEM system I see here is version 501.51. It consists of a bunch of other systems like SI, Embedding, L-Bin, Tables, Scheduler, Netboot, Common Lisp, SCT, Garbage Collector, Flavor, Error System, Language Tools, Network, Lisp Compiler, Bitblt, Fonts, FS, Bin, Time, TV, Presentation Substrate, CP, Dynamic Windows, Debugger, I Linker, Fep-FS, ...

I don't see much of that in System 99 from MIT.

Stuff like X11 and NFS is also not random stuff. Open Genera uses it for its console and its files.

> seeing that it doesn't really support CL very well anyway

Well enough that it is able to run a lot of its software written in Common Lisp. It's able to run stuff like PCL, ASDF, ITERATE, ...

System 99 is from 1984 (?), Symbolics started in 81/82. Open Genera appeared 1992/93. You are ignoring a full decade of development.

Earlier:

> Genera did a few cool things but in the grand scheme of things it is essentially not much (the Dynamic Listener probably being the most interesting thing, the rest of the system was essentially the same).

I would guess that less than 20% of the core SYSTEM is essentially the same (but often quite a bit enhanced). For the rest of the software, I would think it's even less. Which is not surprising, since System 99 did not support the 3600 systems, the G-Machines, the I-machines (XL400, XL1200, XL1201, UX400, UX1200, NXP1000, MacIvory 1/2/3, ...), Open Genera, ..., because all that was developed later by Symbolics.

I'm looking at a Symbolics file system. Where do I find Dynamic Windows in System 99? Common Lisp? CLOS? The Document Examiner? X11? NFS?

> rest of the system was essentially the same

not true

The safety net also provides people with cheaper tickets. At least in my city, the ticket costs much less for people who depend on the social safety net.

You don't need to be lucky to live in places with good connections. There are many such places.

That car traffic has generally less problems than the train system is a myth. Check the ADAC traffic event overview on a random workday.

I don't even need to swipe a ticket. All my local public transport has zero ticket checks, just random&rare controls.

In a long distance train I check in on my booked seat via the app. That's it. No additional ticket check.

> With Deutsche Bahn it is either their app or a PDF to print.

They also have an extensive web-based ticket shop.

You don't need to print PDF tickets. One can also show a PDF ticket on an electronic device, without printing it. I used the DB ticket PDFs for several years, without printing it. Nowadays a load the long-distance train tickets onto the phone and have it in the DB app, I have also a PDF version via mail.

> For local and inner city transport you usually don't need a ticket a all, just swipe your card or phone at the beginning and end of your trip.

I have that here also in my city. The reality: most people have a subscription, that's the by far dominant model. Simpler and less tracking needed.

> It is paper tickets everywhere or a gazillion of different apps, because every city and network has their own.

Larger cities like Berlin, Hamburg, Munich, Cologne, Frankfurt, Stuttgart, Düsseldorf, ... are central for large traffic regions. For example the traffic region here in Hamburg serves roughly 3.7 million people.

> That is very much not my understanding of public transport being digital.

We now have a Germany-wide affordable subscription-based ticket for local&regional public transport. That's my understanding of public transport gone digital, nation-wide. The basics were operational after only a few months of planning.

Where I live, students pay for it, 29.40 €. It's a part of the semester fees, IIRC.

> Are you dismissing the lived experience of the person you are talking to? Why?

The DB App has this option, now. That's all. If this information does not help you, there are other readers here, too.

> All of that notwithstanding, why not decrease the friction from needing to use an app (phone needs to be supported, charged and have an internet connection) and instead use contactless payment terminals?

You can buy with credit cards (and a few other options) using the usual payment terminals. Again, you usually have to pay outside of the train. The terminals are at the train station.

> Really sad, as it isn't affordable for poor people anymore.

Depends. In my city "poor" people pay less. Just 19 € per month. Pupils don't pay at all. Students pay 29.40 €.

A German study from 2021 says road traffic created 70 billion euros costs per year. Of that 45 billion had to be paid from general taxes.

> The DB app? Definitely was not an option for the people who did that.

Yeah, it's in the app.

> Paying before just isn't always practical, but I understand that such limitations are often a non-issue for locals.

That's how it works. Typical here for local trains: there are no barriers in train and bus stations. One can just enter the train and bus without any ticket check. But you have to make sure that you have a ticket. The local trains have no installation to buy a ticket anymore. Typically one would buy them online or have a subscription ticket. How does the system make sure that people pay and don't game the system? There are random checks.

If you want a ticket, buy it before entering a train. Train stations have either ticket systems or a ticket office. But most people by now do it online either per website or app.

For long-distance trains I would always book in advance (it's often also cheaper) and book a seat, too.

The ticket is available by other apps, too.

> the US is a MUCH larger country

with much of the population in a few denser areas, where public transport would make a lot of sense.

maybe 3 hours in the car and 1h with public transport.

if you are in the rushhour and a traffic jam (not an unusual problem), then the train will be faster. Plus one can work in the train or relax.

My regional train here 20km going into the city center is impossible to beat by car.

77.77% of the people live in cities. 55% live in cities with >20k people. Generally Germany is a decentralized country with a lot of regions with local center cities. There are 15 cities with >500k people. France has only four.

Pay before. That's how the transport systems generally work in Germany. In many trains you need to have a ticket BEFORE entering the train and also BEFORE entering the platform in the train station.

> Further, the process for getting refunds when you miss a connection requires one to fill in forms on paper and scan them in and then send in via email.

I can do that in the DB app.

> If you're a tourist, it's not meant for you. Sorry.

Tourist&foreigners can use the Deutschlandticket, too.

But: it's a monthly subscription automatically renewing every month, so one has to cancel it early enough when planning to leave the country. You'll also typically need a smartphone for the ticket.

> Everything seems to be stuck in paper based processes, only occasionally and very listlessly digitized.

That's nonsense. Most public transport is digital by now.

> The DB Navigator is so terrible

It's not terrible. I managed to book all my train travels just fine with it, also using a business bahncard which gives me a 50% discount on all trains.

> Except this only helped the folks living close to big train station hubs

Every city has public transport.

There is a large density of public transport throughout the country: trains, local trains, underground trains, busses, ferries, ...

The ticket is valid there, too.

> Didn’t this start as unlimited anywhere for 9 euros no strings attached?

That was a time limited earlier ticket. "The tickets were valid for June, July, or August 2022. The offer aimed at reducing energy use amid the 2021–2022 global energy crisis." https://en.wikipedia.org/wiki/9-Euro-Ticket

It influenced the idea to come up with a permanent ticket: the "Deutschlandticket". It started 1. Mai 2023. https://en.wikipedia.org/wiki/Deutschlandticket

The Deutschlandticket costs max 49 Euros (next year it will cost 58€ per month) and is valid for one month for mostly all local&regional public transport systems (plus a few selected non-regional trains) in the whole of Germany. The subscription will renew automatically.

Companies often support employees by paying some of the costs. Then it typically costs 34.30 € per month. From next year on, employees pay 40,60 € per month max.

Here in my home city already 94% of the 213000 pupils use the Deutschlandticket for 0 € per month. Every pupil has free access to all of the country's local&regional public transport system... I find that kind of mind-blowing.

I have the ticket in my iPhone's wallet and thus also in the Apple Watch wallet. Additionally I need an ID card. Which at some point in time will also come to the smartphone. https://www.iamexpat.de/expat-info/german-expat-news/new-mob...

> So I think the compiler may not be able to compile calls to arbitrary functions?

A Lisp compiler will by default compile a call to ANY function as a "jump subroutine" (or as a non-returning jump in the case of a tail call) machine code call. The function then has to be present at runtime (in the runtime) and the code will call it at runtime. Lisp code by default also calls a global function through its symbol's cell -> late binding.

"supported by the compiler" here probably means that the compiler can generate inline code for these functions in various cases. Thus if the call is to the function 1+ and it knows that the argument is an integer number (and, possibly, the result also has to be an integer number), then it will not use a subroutine call via the global function, but will inline the call to an integer addition machine instruction. Obviously this then defeats late binding.

If a Lisp (for a tiny machine) only has fixnum integers as its single numeric data type, then the thing is simple -> every 1+ will get an integer argument and thus one can inline it. Inlining makes for tiny computers (which uLisp was developed for) only sense if the inlined function code isn't too long and doesn't use to much of the precious memory for the machine code. Inlining OTOH like will have a positive effect in reducing execution time and a negative effect by increasing compilation time.

In languages like Common Lisp or Scheme, which have several numeric types (fixnums, bignums, floats, ratios, complex, ...) this gets more complicated. Common Lisp compilers typically use optional type declarations and type inference to determine what inlined code to generate.

Or even better have the assertion offer a way to repair the problem:

    CL-USER 1 > (defun calculate-something (big small)
                  (assert (>= big small)
                      (big small)           ; these can be reset
                    "Big ~a must be bigger than small ~a" big small)
                  (sqrt (- big small)))
    calculate-something

The error handling will now offer me to repair it, if necessary:

    CL-USER 2 > (calculate-something 4 7)

    Error: Big 4 must be bigger than small 7
      1 (continue) Retry assertion with new values for BIG, SMALL.
      2 (abort) Return to debug level 0.
      3 Restart top-level loop.

    Type :b for backtrace or :c <option number> to proceed.
    Type :bug-form "<subject>" for a bug report template or :? for other options.

    CL-USER 3 : 1 > :c 1 
    The old value of BIG is 4.
    Do you want to supply a new value?  yes

    Enter a form to be evaluated:
    17

    The old value of SMALL is 7.
    Do you want to supply a new value?  yes

    Enter a form to be evaluated:
    5

    3.4641016

The last number is the return value

> However, it also appears that lispm's characterization of Xah as never having written a line of Lisp hasn't been correct for many years.

Read again what I wrote above: "He had never written a line of Lisp (or anything more challenging) and never contributed anything, during his Usenet times." The "during his Usenet times" applies to both parts. People often asked on something like comp.lang.lisp for programming help, I can't remember that he actually wrote solutions or debugged problems (unlike, for example, Erik Naggum, who was providing his expertise). All I ever saw was him derailing discussions about the language.

Later then he was configuring GNU Emacs keybindings. He was then, later, scripting GNU Emacs.

Sure he doesn't like to be reminded of his destructive role as one of the most active trolls in Usenet programming related newsgroups. The Usenet archives document this though and he has actually said that he was trolling back then.

It's a bit sad that you waste your time with this topic... That's the hole I was talking about. Get out of it.

I haven't looked at Linux kernel sources, but I read about this "linked list" usage in the kernel. Embedded link pointers is also a good point.

Do you happen to have a good example for it?