TUHS

tuhs@tuhs.org

19 participants
6471 discussions

by Diomidis Spinellis

In case you missed the news, it seems that Oracle is effectively shutting down the development of Solaris. You can read an eloquent obituary written by Bryan Cantrill at http://dtrace.org/blogs/bmc/2017/09/04/the-sudden-death-and-eternal-life-of…. Diomidis

7 years, 7 months

Re: [TUHS] Line Terminators in Text Files

by Doug McIlroy

> When did LF replace CR/LF in UNIX? Never. Unix always took LF as newline--an interpretation blessed by the ASCII standard. The convention was inherited from Multics. Interpolation of CRs was the business of drivers, not file formats. As far as I know, the only CR/LF terminal that original Unix dealt with was the model 33 console. That was identified by the fact that the login name was received in all caps. IIRC the TTY 37 conformed to Multics practice on the advice of Joe Ossanna. Because of the model 33, login names were case-insesitive. Come to think of it, I don't know whether they still are in general, though they must be for email to be delivered by login name. Doug

7 years, 7 months

Re: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal isNot My Favorite Programming Language - Unearthed!]

by Richard Tobin

> As I recall, the original definition of ASCII suggested that the > LF character was either "line feed" or "new line", and that if it > *was* new-line, it would be stand-alone. I have put a copy of the original ASCII standard (scanned images) at http://www.cogsci.ed.ac.uk/~richard/ascii.tar I don't remember where I got it from. -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

7 years, 7 months

Re: [TUHS] Future Languages

by Richard Tobin

> So we have some source (that you can have as well, Apache license) > that handles not strings but vectors of strings (or structs or whatever). > > I need to write up how it works, it's sort of clever. It stores both > the size of the vector (always a power of 2) in part of the bits of the > first entry and the actual length in the other part. Because we can > express powers of two in very little space we can support both values > in a 32 bit unsigned with a max length of used space of around 134M. I have something similar. It allocates space for two ints (number allocated and used) at ((int *)array)[-1] and [-2]. Typical use is LTVectorAndInit(char *, names); while(...) LTVectorPush(names, s); for(i=0; i<LTVectorCount(names); i++) ... names[i] ...; LTVectorFree(names); -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

7 years, 7 months

Re: [TUHS] It is time to modernise "groff"

by Doug McIlroy

> > p) Remove the '-a' option (the ASCII approximation output). > > I didn't even know this existed. Looking at what it spits out, I find > myself wondering what good it is. Is this for Unix troff compatibility? > For people who didn't even have glass TTYs and needed to imagine what > the typeset output would look like? Here's a classic use: Since groff is not WYSIWYG, the experimental cycle is long: edit - save - groff - view. In many cases that cycle can be short-circuited by typing straight into groff -a. doug

7 years, 7 months

Re: [TUHS] Introduction to {t,r,g}roff & co...

by Norman Wilson

Call me old-fashioned, but I still think the papers in Volume 2 of the Seventh Edition manual are a good straightforward start. There's a tutorial on troff, and papers introducing eqn, tbl, and refer. Norman Wilson Toronto ON

7 years, 7 months

Introduction to {t,r,g}roff & co...

by Grant Taylor

Hi, Can anyone point to an introduction to {t,r,g}roff / pic / tbl / etcetera? I've respected them for years and with all the latest discussions about them I'd like to try and learn something. Any pointers would be appreciated. -- Grant. . . . unix || die

7 years, 7 months

Re: [TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

by Norman Wilson

Steve Johnson: I think of Alan Demer's comment: "There are two kinds of programming languages, those that make it easy to write good programs, and those that make it hard to write bad ones." ==== I'm (still) with Larry Flon on this one: There does not now, nor will there ever, exist a programming language in which it is the least bit hard to write bad programs. -- SIGPLAN Notices, October 1975, p. 16. There are certainly language that make it easier to avoid trivial mistakes, like buffer overruns and pointer botches, but the sort of nonsense Kernigan and Plaugher demonstrated and discussed about the same time in The Elements of Programming Style shows up in any language. I'm afraid I see that nearly any time I look in source code. To be fair, these days I rarely have the time to look at someone else's source code unless it's buggy, but it is nevertheless appalling what one finds in critical system software like boot environments and authentication code. There is no royal language to good programs. Programming well takes discipline and skill and experience. Languages like Pascal that prevent certain classes of sloppiness like overrunning arrays and string buffers may be better for teaching beginners, but only because that makes it easier to focus on the real issues, such as how to structure a program well and how to write clearly. I have yet to see evidence that that actually happens. Norman Wilson Toronto ON

7 years, 7 months

Re: [TUHS] Line Terminators in Text Files [Was: Re: Why Pascal is Not My Favorite Programming Language - Unearthed!]

by jnc＠mercury.lcs.mit.edu

> From: Chris Torek > termcap has entries for the number of NUL characters to insert after > carriage return. Actually, the stock terminal driver in V6 Unix (here: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/dmr/tty.c if anyone wants to see the actual code; it's in ttyoutput()) had some pretty complex code to do just the right amount of delay (in clock ticks) for a large number of different motion contral characters (TAB, etc, in addition to LF and CR), and then uses the system timer to delay that amount of real time after sending such a character (see the very bottom of ttstart()). E.g. for a NL, it used the fact that it 'knew' which column the print head was in to calculate the exact return time. Clever, but alas, it did this by sticking 'characters' in the buffered output stream with the high bit set, and the delay required in the low 0177 bits, which the output start routine interpreted; as the code drolly notes, "thus (unfortunately) restricting the transmission path to 7 bits". Which was a real PITA recently when I tried to download a binary file to an LSI-11 from a V6 running in Ersatz-11! I had to tweak the TTY driver to allow 8-bit output... Noel

7 years, 7 months

Why Pascal is Not My Favorite Programming Language - Unearthed!

by arnold＠skeeve.com

Seek and ye shall find. Ask and ye shall receive. Brian Kernighan was kind enough to find for me everyone's favorite Computing Sceince Technical Report, CSTR 100, "Why Pascal is Not My Favorite Programming Language". Attached is the file and his macros. This will not immediately format using groff etc.; I hope to create a version that will, sometime in the next few weeks. In the meantime, Warren, please add to the archives when you are able. Enjoy! Arnold

7 years, 7 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