TUHS

tuhs@tuhs.org

29 participants
6557 discussions

by arnold＠skeeve.com

Hello All In case this is of interest: > Date: Sat, 16 May 2020 12:18:15 +0100 > Subject: qed-archive (Github) > To: arnold(a)skeeve.com > > Hi Arnold > > Apologies for an un-solicited email. > > I have ported Rob's UofT QED from your qed-archive/unix-1992 to Linux > (although I suspect anything with a Unix API will work), and have updated > it to work completely in UTF8/Unicode. This includes correct handling of > unicode codepoints in regexes, subs, etc. > > It's up on Github under phonologus/QED. I thought you might want to add it > to your list of QED-s in your README, as it may be of interest to the other > three connoisseurs out there...! > > I have also included typeset pdf-s of the tutorial and manpage. The > tutorial is fascinating. > > Also, there is no clear statement about copyright, or license, of the > unix-1992 tarball. I have attributed it to Rob, and I have noted that I > scavenged it from your Github repo, but was wondering if there is any > definitive statement on ownership/authorship that I could include in my > repo? > > Best wishes

5 years, 3 months

Re: [TUHS] v7 K&R C [really lexers]

by Nelson H. F. Beebe

Brantley Coile <brantley(a)coraid.com> wrote on Sun, 17 May 2020 01:36:16 +0000: >> It looks like only grap and pic have mkfiles that invoke lex. Both of those are Brian Kernighan's work, and from the FIXES file in his nawk, I can offer this quote: >> ... >> Aug 9, 1997: >> somewhat regretfully, replaced the ancient lex-based lexical >> analyzer with one written in C. it's longer, generates less code, >> and more portable; the old one depended too much on mysterious >> properties of lex that were not preserved in other environments. >> in theory these recognize the same language. >> ... ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

5 years, 3 months

Re: [TUHS] v7 K&R C

by Richard Tobin

> The function prototype for getchar() is: int getchar(void); > > It returns an int, not a char. In all likelihood this is specifically > *because* EOF is defined as -1. It would have probably returned int anyway, because of the automatic promotion of char to int in expressions. It was natural to declare functions returning char as int, if you bothered to declare them at all. As K&R1 said: Since char promotes to int in expressions, there is no need to declare functions that return char. Similarly functions that might return short or float would normally return int or double; there aren't separate atof and atod functions for example. -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

5 years, 3 months

11/40 CPU (Emulation) test programs still available somewhere

by Michael Stiller

Hi Legends, during corona times i “ported” Dave Cheney’s avr11 PDP11/40 emulator to a Teensy 4 MCU board, fixed already some bugs in it and added multiple rk drives and a partially working tm emulation. (space forward/reverse unimplemented) It runs V6 at about 1 Mips and is completely fine usable with multiple rk and tm drives. Playing around with V6 i noticed that Shoppa disk and tried to get ncc running, but after some debugging it looked like it is stuck in some loop which i think is due to possible bugs in the emulator code. So the question is, are there programs V6 runnable or rk bootable available which test the CPU functionality? I already hat a look at some xxdp disk, but the one i found (while they boot) seem to lack basic cpu tests. Best regards, Michael

5 years, 3 months

A la carte menu of OO features or properties

by Don Hopkins

The properties of object oriented programming are better described as an la carte menu like a cafeteria buffet or smörgåsbord, than a point, line, or continuum. http://www.paulgraham.com/reesoo.html <http://www.paulgraham.com/reesoo.html> Paul Graham: Reese Re: OO (Jonathan Rees had a really interesting response to Why Arc isn't Especially Object-Oriented, which he has allowed me to reproduce here.) Here is an a la carte menu of features or properties that are related to these terms; I have heard OO defined to be many different subsets of this list. • Encapsulation - the ability to syntactically hide the implementation of a type. E.g. in C or Pascal you always know whether something is a struct or an array, but in CLU and Java you can hide the difference. • Protection - the inability of the client of a type to detect its implementation. This guarantees that a behavior-preserving change to an implementation will not break its clients, and also makes sure that things like passwords don't leak out. • Ad hoc polymorphism - functions and data structures with parameters that can take on values of many different types. • Parametric polymorphism - functions and data structures that parameterize over arbitrary values (e.g. list of anything). ML and Lisp both have this. Java doesn't quite because of its non-Object types. • Everything is an object - all values are objects. True in Smalltalk (?) but not in Java (because of int and friends). • All you can do is send a message (AYCDISAM) = Actors model - there is no direct manipulation of objects, only communication with (or invocation of) them. The presence of fields in Java violates this. • Specification inheritance = subtyping - there are distinct types known to the language with the property that a value of one type is as good as a value of another for the purposes of type correctness. (E.g. Java interface inheritance.) • Implementation inheritance/reuse - having written one pile of code, a similar pile (e.g. a superset) can be generated in a controlled manner, i.e. the code doesn't have to be copied and edited. A limited and peculiar kind of abstraction. (E.g. Java class inheritance.) • Sum-of-product-of-function pattern - objects are (in effect) restricted to be functions that take as first argument a distinguished method key argument that is drawn from a finite set of simple names. […] (See the web page and the original thread for a discussion of which languages implement which of the above features.) http://www.paulgraham.com/reesoo.html <http://www.paulgraham.com/reesoo.html> https://web.archive.org/web/20160308032317/http://www.eros-os.org/pipermail… <https://web.archive.org/web/20160308032317/http://www.eros-os.org/pipermail…> -Don

5 years, 3 months

Re: [TUHS] v7 K&R C

by Doug McIlroy

> I feel the essence of object-oriented computing > is not operator overloading but the representation of behavior. Rob is right. Overloading is a universal characteristic of OO programming, but not the essence. Doug

5 years, 3 months

Re: [TUHS] v7 K&R C

by Paul McJones

> On May 13, 2020, at 7:00 PM,Dave Horsfall <dave(a)horsfall.org> wrote: > > I never could figure out why Stroustrup implemented that "feature"; let's > see, this operator usually means this, except when you use it in that > situation in which case it means something else. Now, try debugging that. C continues the tradition begun by Fortran and Algol 60 of overloading the arithmetic operators on the various numeric types. C++ allows new types to be defined; when a new type obeys the generally understood properties of a built-in type, it makes sense to use the same operator (or function) for the corresponding operation on the new type (e.g., addition on complex numbers, arbitrary-precision integers and rationals, polynomials, or matrices).

5 years, 3 months

[off topic] anyone want some QIC-250 tapes?

by arnold＠skeeve.com

I recently unearthed two 250 Mb QIC cartridges (like we used to use on Sun workstations). They were last written on in late 1997. I have no idea if they're any good, but they're free to anyone who'll pay postage (from Israel). If no takers, I'll just toss 'em. Thanks, Arnold

5 years, 3 months

Re: [TUHS] Linotron 202 Information

by TangentDelta

Here is a dump of the ROM in a text-based format. I couldn't think of a good way to represent the 4-bit words in a normal binary format with the order being ambiguous. Connecting a logic analyzer up to the ROM and triggering an "autoload" sequence, the processor reads ROM address 0, followed by ROM address 1, and then seems to lock up. I'm curious if the processor is attempting to store the 8-bit word into RAM for some reason? My RAM board is in very poor condition and I will need to devise a way to troubleshoot it. It'd also be helpful to have some of those control lines hooked up to the logic analyzer while it is happening. I'm working on a disassembler that should let me shuffle the order of the 4-bit words around until I get something that looks sane. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, May 13, 2020 3:27 PM, Ken Thompson <ken(a)google.com> wrote: > can you send me the bits of the rom. > i will take a look. > > On Tue, May 12, 2020 at 12:44 PM TangentDelta via TUHS <tuhs(a)minnie.tuhs.org> wrote: > >> Hello. >> >> I have a pair of controller card cages out of Mergenthaler Linotron 202 photo-typesetting machines. Sadly the machines themselves were scrapped, and these card cages are all I was able to save. >> >> The controllers use Computer Automation Naked Mini processors, which are relatively small 16-bit minicomputers designed for embedded control applications. I've been hacking on these for a few months now and have built up a system bus pinout diagram and several schematics. I haven't been able to find any technical information online in regards to the specific model of Naked Mini processor used in the 202, but I have found a trove of documents for other Naked Mini models on Bitsavers. >> >> I pulled the 512x4bit "boot ROM" mentioned in the "Experience with the Mergenthaler Linotron 202 Phototypesetter, or, How We Spent Our Summer Vacation" paper and dumped it, but the resulting binary doesn't produce any sane-looking code when manually disassembled using the documents on Bitsavers and reference, no matter how I arrange the nybbles. The processor also does not appear to respect the control opcodes issued by the Computer Automation LSI series programming console that I obtained. This has led me to the hypothesis that this is not a stock "Naked Mini" or later "Naked Milli" processor, but something specific to Mergenthaler. >> >> My goal is to get the processor to run my own code, and eventually design my own MaxiBus peripherals to use with it. >> >> If anyone knows where I can look for more information in regards to the 202 and the Naked Mini processor, or has any stories of working on these machines, I would greatly appreciate it! >> >> Thanks.

5 years, 3 months

Linotron 202 Information

by TangentDelta

Hello. I have a pair of controller card cages out of Mergenthaler Linotron 202 photo-typesetting machines. Sadly the machines themselves were scrapped, and these card cages are all I was able to save. The controllers use Computer Automation Naked Mini processors, which are relatively small 16-bit minicomputers designed for embedded control applications. I've been hacking on these for a few months now and have built up a system bus pinout diagram and several schematics. I haven't been able to find any technical information online in regards to the specific model of Naked Mini processor used in the 202, but I have found a trove of documents for other Naked Mini models on Bitsavers. I pulled the 512x4bit "boot ROM" mentioned in the "Experience with the Mergenthaler Linotron 202 Phototypesetter, or, How We Spent Our Summer Vacation" paper and dumped it, but the resulting binary doesn't produce any sane-looking code when manually disassembled using the documents on Bitsavers and reference, no matter how I arrange the nybbles. The processor also does not appear to respect the control opcodes issued by the Computer Automation LSI series programming console that I obtained. This has led me to the hypothesis that this is not a stock "Naked Mini" or later "Naked Milli" processor, but something specific to Mergenthaler. My goal is to get the processor to run my own code, and eventually design my own MaxiBus peripherals to use with it. If anyone knows where I can look for more information in regards to the 202 and the Naked Mini processor, or has any stories of working on these machines, I would greatly appreciate it! Thanks.

5 years, 3 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS