3,250 karma · joined August 2, 2012
The pictures in the catalog entry were taken in a warehouse. The bike is displayed much more nicely than these show.
https://www.computerhistory.org/collections/catalog/L2003.20...
https://www.reddit.com/r/lojban/comments/12i0d0i/chatgpt_app...
Not surprising, given it would have seen many orders of magnitude less Lojban training data than its English input (basically two books and maybe a few megabytes of web pages).
https://www.mercurynews.com/2023/03/29/san-jose-poa-office-m...
> SJPOA spokesperson Tom Saggau ... was shocked to learn about the allegations swirling around Segovia, who he has known as a beloved figure in the office for over 20 years.
> “She was looked at as the grandma of the POA,” he said. “She’s the one who planned all the funerals when we had officers killed in the line of duty...
"Meanwhile they were heating up, mainly from the radioactive element Aluminum-26. ... this hot stuff’s radioactivity is short-lived: With a half-life of 700,000 years, it was basically all used up, or extinct, within 2 or 3 million years."
So why was there a significant amount of it in the young Sun? Wiki[1] says it "is mainly produced in supernovas ejecting many radioactive nuclides in the interstellar medium." So are they guessing that the Sun condensed from a cloud of material that was _recently_ ejected by a supernova? (Because if it wasn't recently produced, there wouldn't have been any AL-26 left.) Something of a violation of the Mediocrity principle[2].
Of course for early MIPS there were little things like, don't put a jump in the last word of a 4K page... :-(
References:
Dr. Dobb's Journal #32 (Feb 1979) page 41, review of Tiny-C User Manual by Ted Shapin [0]
Dr. Dobb's Journal #35 (May 1979) page 37, "Tiny-C Interpreter on C-Dos" by Ray Duncan[1]
Tiny-C Associates incorporated in Holmdel, NJ, March 1978 [2]
"Tiny C" trademark application filed 1979, cancelled 1987 [3]
There was also a "Small C", see DDJ #45 (May 1980), "A Small C Compiler for the 8080s" by Ron Cain[4]. Cain references buying a copy of "the Tiny-C interpreter from Tiny-C Associates" and finding it too slow, so he bootstraps his own C compiler, writing it in C, compiles it on a UNIX system, then using it to compile itself to get the 8080 machine code.
See also DDJ #69 (July 1982) p. 66, "Small C for the 9900" by Matthew Halfant[5], porting Cain's compiler to another platform.
[0] https://archive.org/details/dr_dobbs_journal_vol_04_201803/p...
[1] https://archive.org/details/dr_dobbs_journal_vol_04_201803/p...
[2] https://www.bizapedia.com/nj/tiny-c-associates.html
[3] https://alter.com/trademarks/tiny-c-73219160
[4]https://archive.org/details/dr_dobbs_journal_vol_05_201803/p...
[5] https://archive.org/details/dr_dobbs_journal_vol_07_201803/p...
Can this be solved by use of, e.g. Audio Hijack? (https://rogueamoeba.com/audiohijack/)
If not (and I'm sure this is not an acceptable idea to a purist like OP) I would consider using a good consumer-grade scanner and post-process with Topaz AI[2], which produces absolutely astonishing results in my experience. Yes, maybe it is inventing the pixels it adds, but they look like the right pixels nonetheless.
* Strings: Codon currently uses ASCII strings unlike Python's unicode strings.
Judas priest, after all the effin' grief we went through to learn how to handle Unicode strings in Python 3, and to finally begin to realize their value, you take this step backward? Forget the i64 limits, the lack of native Unicode strings is a flat deal-breaker. (For example, will Codon warn if it sees an "open(encoding='UTF8')" call? Or a normal open(mode='rt') if the default local encoding is UTF8?)
It doesn't help that the same doc also mentions that
* Dictionaries: Codon's dictionary type is not sorted internally, unlike Python's
Current Python dicts are not "sorted"; rather they "preserve insertion order, meaning that keys will be produced in the same order they were added sequentially over the dictionary."[2]
This is new functionality added only recently (3.7) so its lack would not inconvenience a lot of existing code. OTOH, why did they not plan to reproduce this useful feature from the start?
Possibly they were thinking of the pypi package SortedContainers[3]?
[1] https://docs.exaloop.io/codon/general/differences
[2] https://docs.python.org/3/reference/datamodel.html#index-30
"While Codon does offer a JIT decorator similar to Numba's, Codon is in general an ahead-of-time compiler that compiles end-to-end programs to native code. It also supports compilation of a much broader set of Python constructs and libraries."
In other words, this is vaporware as yet.
Each such source deck would have been assembled to make an object deck. There are assembler commands for formatting the printed assembly listing: TITLE to set a running title on the listing pages, PRINT OFF to avoid listing repetitive macros, PRINT ON, PRINT NOGEN to not print macro-generated statements, EJECT to start a new listing page.
A DSECT line introduces a data section, essentially a record. The pseudo-instruction USING tells the assembler which register contains the base address of a DSECT, so USING MKLOCLS,14 says, assume R14 has the address of the DSECT MKLOCLS. Reference to a name defined within that DSECT will generate an instruction using R14 plus the offset to that name.
A CSECT names a "control section" or named block of instructions. The linker handles CSECTs and DSECTs as units. A CSECT typically begins with USING *,15 or some other register, to inform the assembler that at run-time R15 will have the base address of this code. Local jump addresses will assemble as offsets from that register. A DROP <reg> statement tells the assembler to no longer assume that register is in use.
There are inside jokes: the code with TITLE 'THE AGORONOMIC ROUTINES' is memory management.
APL\360 managed memory on two levels. First, as a time-sharing system, it created a separate "workspace" for each logged-on user. A workspace was a contiguous block of memory (typically 32K as a practical size) that contained all of the user's current code definitions. There was not room in the typical 360 RAM for more than a few user workspaces at one time, so the system swapped whole workspaces in and out as it serviced each user. The code to do this operated the disk drives directly on a head and track level and was highly optimized. You'll see a number of references to "one-track workspace" as a special case; if a workspace fit on one track of the (2311 or 2315) disk, it could be read in or written out in minimum time.
On the user level, the interpreter while executing APL code is constantly creating and trashing values which are stored as memory objects within the current workspace. So there was memory allocation and garbage collection. Garbage collection was a simple sweep across the workspace moving all active objects to one end.
APL would be initiated as a normal job under OS/MFT and would immediately take control of the entire system, kicking the OS out and managing all aspects of the 360 hardware itself, including interrupt handling, storage protection and so on. This was before the day of hardware-supported virtual memory, so it didn't have that to deal with. See NAME=APLSAPLM and forward. I'm pretty sure in that code, TCB stands for Task Control Block, a dispatching object. APL had multiple internal tasks being time-shared, as necessitated by the fact that it had to handle asynchronous interrupts from both terminals and disk drives.
Company description of "Symphony" engine: https://boomsupersonic.com/symphony
Claims 10% lower operating cost, use of 100% sustainable fuel
But that's just me.
As described in the article, books do arrive in, mostly, cardboard boxes, or in paper or plastic shopping bags, and I think I remember a plastic washtub. And of course in a suburb, they arrive as a loose pile in the back of an SUV.
As volunteer manager of a section, I get to evaluate and price a couple hundred books a month. The primary tool for this is Bookfinder[2]. I can't imagine working in this business without it and other sites like Addall[3] and of course, eBay.
[1] https://www.fopal.org/volunteer [2] https://www.bookfinder.com/ [3] https://www.addall.com/used/