TUHS

tuhs@tuhs.org

21 participants
6516 discussions

Re: [TUHS] Anyone know what a LANTERN is

by Doug McIlroy

I have no actual information about the lantern character, but a tapered "storm lantern" would be far down my list of guesses. The tapered chmney would much more likely be called a "lamp", for it's a standard shape for the oil (kerosene) lamps that everyone had before electricity. My top guess would be a carriage lantern with a Japanese garden ornament as a distant second. The carriage lantern would be an unfilled circle superimposed on a vertical rectangle, filled or unfilled. The rectangle might be simplified to two (interrupted) vertical sides. An alternate form of lantern would be a side view of a carriage (or picture-projection) lantern, schematized as a box, with a flaring projection to the right--an icon for shining light on a subject, also interpretable as a movie camera. A Japanese lantern would be tripartite: cap, body, and feet. Do any of these possibilities ring a bell? Doug

7 years, 10 months

Re: [TUHS] Anyone know what a LANTERN is

by Norman Wilson

Doug McIlroy: Do any of these possibilities ring a bell? ==== More to the point, do any shed light on the matter? Norman Wilson Toronto ON

7 years, 10 months

Anyone know what a LANTERN is?

by Paul Ruizendaal

> Message: 1 > Date: Thu, 27 Jul 2017 11:58:38 -0400 > From: Random832 <random832(a)fastmail.com> > To: tuhs(a)minnie.tuhs.org > Subject: [TUHS] Anyone know what a LANTERN is? > Message-ID: > <1501171118.69633.1054588920.11864815(a)webmail.messagingengine.com> > Content-Type: text/plain; charset="utf-8" > > There is a character in the terminfo/curses alternate character set, > ACS_LANTERN, which is mapped to "i" in the VT100 alternate grapical > character set. This character is, in fact, on a real VT100/VT220 (and > therefore in most modern terminal emulators that support the full ACS), > "VT" (in 'control character picture' format, along with HT FF CR LF NL). > The ASCII mapping uses "#", and some CP437/etc mappings map it to the > double box drawing intersection character. > > Was there ever a real 'lantern' character? The manpage mentions "some > characters from the AT&T 4410v1 added". What did it look like? There's two references in the termcap manpages: http://invisible-island.net/ncurses/man/terminfo.5.html and http://invisible-island.net/ncurses/man/curs_add_wch.3x.html The second link mentions that the AT&T 4410 terminal added this glyph in the location of the VT100 VT glyph. Apparently what it looked like is lost, unless someone finds a detailed 4410 manual (or has a working one in the attic).

7 years, 10 months

Anyone know what a LANTERN is?

by Random832

There is a character in the terminfo/curses alternate character set, ACS_LANTERN, which is mapped to "i" in the VT100 alternate grapical character set. This character is, in fact, on a real VT100/VT220 (and therefore in most modern terminal emulators that support the full ACS), "VT" (in 'control character picture' format, along with HT FF CR LF NL). The ASCII mapping uses "#", and some CP437/etc mappings map it to the double box drawing intersection character. Was there ever a real 'lantern' character? The manpage mentions "some characters from the AT&T 4410v1 added". What did it look like?

7 years, 10 months

Re: [TUHS] Photo of some Unix greats

by Peter Adams

That is such a great shot! Since we are on the topic of photos… I’ve been shooting portraits of some of these same people as part of a larger photo project called Faces of Open Source. If anyone is interested in taking a look, here they are: http://facesofopensource.com -P- — Peter Adams Photography | web: http://www.peteradamsphoto.com | Instagram/twitter: @peteradamsphoto @facesopensource > On Jul 19, 2017, at 7:00 PM, tuhs-request(a)minnie.tuhs.org wrote: > > Send TUHS mailing list submissions to > tuhs(a)minnie.tuhs.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs > or, via email, send a message with subject or body 'help' to > tuhs-request(a)minnie.tuhs.org > > You can reach the person managing the list at > tuhs-owner(a)minnie.tuhs.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of TUHS digest..." > Today's Topics: > > 1. Photo of some Unix greats (Dave Horsfall) > 2. Re: Photo of some Unix greats (Larry McVoy) > 3. Re: Photo of some Unix greats (Dan Cross) > > From: Dave Horsfall <dave(a)horsfall.org> > Subject: [TUHS] Photo of some Unix greats > Date: July 19, 2017 at 3:48:48 PM PDT > To: The Eunuchs Hysterical Society <tuhs(a)tuhs.org> > > > https://en.wikipedia.org/wiki/Steven_M._Bellovin#/media/File:Usenix84_1.jpg > > Dennis Ritchie, Steve Bellovin, Eric Allman, Andrew Hume (I know him), Don Seeley, Mike Karels, Clem Cole... > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." > > > > > From: Larry McVoy <lm(a)mcvoy.com> > Subject: Re: [TUHS] Photo of some Unix greats > Date: July 19, 2017 at 4:35:05 PM PDT > To: Dave Horsfall <dave(a)horsfall.org> > Cc: The Eunuchs Hysterical Society <tuhs(a)tuhs.org> > > > It's a cool picture, thanks. Brings back lots of memories and makes me > hate being younger than that crowd, would have loved to have been there. > I was just far enough along at that point to have a job sys admining some > of Clem's work products, 3 Masscomps. Think I was a junior in college. > > Great picture, good people. > > On Thu, Jul 20, 2017 at 08:48:48AM +1000, Dave Horsfall wrote: >> https://en.wikipedia.org/wiki/Steven_M._Bellovin#/media/File:Usenix84_1.jpg >> >> Dennis Ritchie, Steve Bellovin, Eric Allman, Andrew Hume (I know him), Don >> Seeley, Mike Karels, Clem Cole... >> >> -- >> Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." > > -- > --- > Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm > > > > > From: Dan Cross <crossd(a)gmail.com> > Subject: Re: [TUHS] Photo of some Unix greats > Date: July 19, 2017 at 6:22:47 PM PDT > To: Dave Horsfall <dave(a)horsfall.org> > Cc: The Eunuchs Hysterical Society <tuhs(a)tuhs.org> > > > I like how Andrew Hume is defying the weather. Like a boss. > > On Wed, Jul 19, 2017 at 6:48 PM, Dave Horsfall <dave(a)horsfall.org <mailto:dave@horsfall.org>> wrote: > https://en.wikipedia.org/wiki/Steven_M._Bellovin#/media/File:Usenix84_1.jpg <https://en.wikipedia.org/wiki/Steven_M._Bellovin#/media/File:Usenix84_1.jpg> > > Dennis Ritchie, Steve Bellovin, Eric Allman, Andrew Hume (I know him), Don Seeley, Mike Karels, Clem Cole... > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." > > > > _______________________________________________ > TUHS mailing list > TUHS(a)minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs

7 years, 10 months

Re: [TUHS] Filename wildcarding (was: origin of the name 'glob')

by Johnny Billquist

On 2017-07-09 23:44, ron minnich <rminnich(a)gmail.com> wrote: > On Sun, Jul 9, 2017 at 2:29 PM Dave Horsfall <dave(a)horsfall.org> wrote: >> >> I vaguely remember something like "PIP *.TXT *.OLD" to rename files (the >> "*" was interpreted by the command itself, not the interpreter). Well, that would not rename files, but copy them and at the same time changing their names. But you could also do renaming in a similar way, but usually it would require a switch to PIP telling it that you wanted the files renamed, and not copied. Also, the syntax of PIP, and the order of arguments is a bit different. At least the versions I can remember right now, it would be: PIP *.OLD=*.TXT to copy, and PIP *.OLD/RE=*.TXT to rename. And yes, it is the program who process the wildcard expansions, and not the command interpreter. Which is why commands like the ones above worked. This is one of those classical examples you get to when comparing Unix with DEC OSes about wildcarding, and the effects the different ways they are done have on the result. (In Unix, you can't do such a mass copy and rename in the same way.) > All the DEC-10 and 11 operating systems I used had that wildcard, as well > as IIRC even the PDP-8, maybe someone can confirm the -8. Yes. It's the same on the OSes I've used on PDP-8s as well. I would say that the globbing in Unix have much less to do with regular expressions and much more to do with trying to mimic what DEC was doing in their OSes. > It would have been nice had RE's been the standard way to glob files, but, > that said, when I mention .*\.c to people instead of *.c they don't much > like it. In a way, it would have made more sense to just use standard RE's for globbing, but that didn't happen. And like I said, I suspect it was because DEC OSes did it this way, and Unix just mimicked it. Same I guess with the convention of '.' to separate filename from type. Even though it's less pervasive in Unix than in DEC systems. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

7 years, 11 months

Re: [TUHS] origin of the name 'glob'

by Doug McIlroy

Glob was an an accident. When Ken and Dennis wanted to put wildcards (an anachronistic word--it wasn't used in the Unix lab at the time) into the shell, there wasn't room, so they came up with the clever hack of calling another process to do the work. I have always understood that glob meant global because commands like rm * would be applied to every file in a directory. A relationship to ed's g command was clear, but not primary in my mind. One curious fact is that from day one the word hase been pronounced glob, not globe. (By contrast, creat has been variously pronounced cree-at and create.) It is also interesting to speculate on whether there would be a glob library routine in Linux had glob only been an identifier in sh.c rather than an entry in /bin. I believe the simple * was borrowed from somewhere else. If the g command had been the driving model, glob would probably have had ? and ?*, not ? and *. (It couldn't use ed's . because . was ubiquitous in file names.) My etymology is somewhat different from Steve's. But I never asked the originator(s). Steve, did you? Doug

7 years, 11 months

Regular Expressions (was Re: origin of the name 'glob')

by Paul Winalski

On 7/9/17, ron minnich <rminnich(a)gmail.com> wrote: >> > All the DEC-10 and 11 operating systems I used had that wildcard, as well > as IIRC even the PDP-8, maybe someone can confirm the -8. > > It would have been nice had RE's been the standard way to glob files, but, > that said, when I mention .*\.c to people instead of *.c they don't much > like it. So when were REs first designed and implemented? I would imagine that they came about as a way to extend the old '*' and '?' wildcard syntax, but that is only a guess. -Paul W.

7 years, 11 months

Re: [TUHS] Regular Expressions (was Re: origin of the name 'glob')

by jnc＠mercury.lcs.mit.edu

> From: Paul Winalski > So when were REs first designed and implemented? I would imagine that > they came about as a way to extend the old '*' and '?' wildcard syntax, > but that is only a guess. I would suspect in the context of editors, not command file-naming. Don't have time to research it, though. Try checking CTSS, early Multics, etc. Noel

7 years, 11 months

Re: [TUHS] origin of the name 'glob'

by Norman Wilson

Doug McIlroy: One curious fact is that from day one the word hase been pronounced glob, not globe. (By contrast, creat has been variously pronounced cree-at and create.) ===== On the other hand, the UNIX Room pronunciation of `cron' rhymed with bone, not with spawn. Norman Wilson Toronto ON

7 years, 11 months

Re: [TUHS] origin of the name 'glob'

by jnc＠mercury.lcs.mit.edu

> From: Ron Minnich > Why was it called glob? I always wondered. Something about global expressions. I recall reading about this somewhere; I tried looking in the man page: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/man/man7/glob.7 but it didn't go into any detail. I don't know where I could have seen it, alas... Noel

7 years, 11 months

origin of the name 'glob'

by ron minnich

Why was it called glob? I always wondered.

7 years, 11 months

DR11-W - anyone need one?

by Arthur Krewat

Probably no one here wants it, but I have a DR11-W UNIBUS board: http://bitsavers.trailing-edge.com/pdf/dec/unibus/DR11W_UsersMan.pdf It's basically a 16-bit DMA interface that can actually do 500Kw per second (woo hoo! 1MB/sec!) to another DR11-W Anyone need it? Want it? Figured I'd try here first, in case we had some historic UNIX people that were still running a UNIBUS PDP-11 (or VAX). No takers in a few weeks, I'll try the museums next. thanks art k.

7 years, 11 months

Re: [TUHS] DR11-W - anyone need one?

by jnc＠mercury.lcs.mit.edu

> From: Toby Thain > Are we to infer that neither Noel and Clem are "good homes"? Well, I said something like 'I don't have an immediate need for it, but I'd be happy to take it', so I guess the question is 'does someone have an actual, immediate use for it' (which I don't)? Noel

7 years, 11 months

Adventure shell / Doug Gwyn

by David

Does anyone here remember the Adventure Shell? Doug wrote it back in 83, and I just stumbled across a copy in an RCS directory. Invoked as ‘ash’ it was pretty clever. I’ve lost the instructions and help files, however I’ve got the main script. Back when people did weird things because it was fun. David

7 years, 11 months

Re: [TUHS] What did cc -2 do?

by Richard Tobin

> Browsing the source for "cc" in v6 and v7, if invoked with -2 would > replace crt0.o with crt2.o. If the -2 were followed by another character > (probably intended to be -20), it would use crt20.o and use -l2 instead > of -lc. > > These options seem to be undocumented, and I can't find any source code > of these libraries or indication as to what the purpose was. The "scc" man page for System V may be enlightening, as it mentions similarly-named files: NAME scc - C compiler for stand-alone programs SYNOPSIS scc [ +[ lib ] ] [ option ] ... [ file ] ... DESCRIPTION Scc prepares the named files for stand-alone execution. [...] FILES /lib/crt2.o execution start-off /usr/lib/lib2.a stand-alone library /usr/lib/lib2A.a +A configuration library /usr/lib/lib2B.a +B configuration library -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

7 years, 11 months

Re: [TUHS] 211bsd: kernel panic after a 'here document' in tcsh

by Walter F.J. Mueller

Hi, two remarks on the issues around FPSIM and tcsh: I of course wondered by a line like mov $4..,r0 is accepted by 'as', I naively expected that this should cause an error. I didn't locate the 211bsd 'as' manual, so checked 7th Edition manuals, which can be found under https://wolfram.schneider.org/bsd/7thEdManVol2/ The assembler manual, see https://wolfram.schneider.org/bsd/7thEdManVol2/assembler/assembler.pdf states 6.1 Expression operators The operators are: (blank) when there is no operand between operands, the effect is exactly the same as if a ‘+’ had appeared. So the lexer sees two tokens $4. --> number . --> symbol for location counter and, because the default operator is '+', interprets this as mov $4. + . , r0 which ends up being a number in the 160000 to 177777 range. So 'as' is not to blame, works as designed. Noel Chippa wrote: > I'm fairly amazed that apparently nobody has run across one of these 4 before! > (Or, at least, not bothered to report it.) > I wonder how long that bug has been in the code? The answer is: this bug was in 211bsd all the time. Steven Schultz told me that that they simply didn't have a way to test FPSIM because all machines had FPP, and the only way of testing would have been to physically remove the FP11 from a 11/70. With best regards, Walter

7 years, 11 months

What did cc -2 do?

by Random832

Browsing the source for "cc" in v6 and v7, if invoked with -2 would replace crt0.o with crt2.o. If the -2 were followed by another character (probably intended to be -20), it would use crt20.o and use -l2 instead of -lc. These options seem to be undocumented, and I can't find any source code of these libraries or indication as to what the purpose was.

7 years, 11 months

Obscure Blit menu data structure

by Noel Hunt

I was hoping someone on the list who remembers 'mhit.c' from the Blit library code could shed some light on some members of the 'NMitem' structure. I believe that 'mhit' (sometimes 'hmenunit') was written by Andrew Hume. The structure in question is this: typedef struct NMitem { char *text; char *help; struct NMenu *next; void (*dfn)(), (*bfn)(), (*hfn)(); long data; /* user only */ } NMitem; The three functions are called at different times when a menu is being traversed, but 'dfn' and 'bfn' are only called before a submenu is entered, and after a submenu is exited, respectively. 'hfn' is called whenever an item has been selected. I have never seen 'dfn' and 'bfn' used in any Bell Labs code so I was wondering what the rationale for their existence was. Noel Hunt

7 years, 11 months

International conference: "Unix in Europe : between innovation, diffusion and heritage"

by Paloque-berges Camille

Dear THUS list, I am a recent lurker on this list, also a history and communication scholar looking at pieces of Unix history for my research. I hope it is okay if I share with you the news of a historical conference on Unix that we are organizing in France next Fall with fellow humanities scholars and computer scientists and engineers involved in the history and heritage of computing and computers. You are of course welcomed, even encouraged, to submit a proposal. It will be a pleasure to meet you at this conference in any case. Best, Camille Paloque-Berges *** Please find enclosed the CFP for the *international conference**"Unix in Europe: between innovation, diffusion and heritage"* that will take place in Cnam (Paris, France), October, 19th, 2017. A one-page abstract (maximum 500 words) with a short biography is expected for June 30th 2017. The Cfp is also available at : <http://technique-societe.cnam.fr/international-symposium-unix-in-europe-bet…>. Best regards, The organization comitee : Isabelle Astic, Raphaël Fournier-S'niehotta, Pierre-Eric Mounier-Kuhn, Camille Paloque-Berges, Loïc Petitgirard ------------------------------------------------------------ *Call for contributions* *International symposium * *Unix in Europe: between innovation, diffusion and heritage* */Conservatoire National des Arts et Métiers, Paris, France – October 19 2017/* ** Communications and discussions will be held in French or English. * * *Rationale* * * **The Unix system was born in the 1970s at the crossroads between two interacting worlds: industry (the Bell Labs at AT&T) and academia (the University of Berkeley computer science network). Its fast adoption throughout computer research and engineering networks across the world signaled the future success of the new system, fostering software experiments within its open, multi-user and multi-tasking system running on mini-computers – and later compatible with a larger part of computer hardware. In the European context, how was this American innovation propagated, adopted and adapted? Why was Unix of so much interest in this context, then and now? A solid culture of Unix users might also explain this success, as well as subsequent processes of appropriation and inheritance, due to the long and complex history of Unix versioning. The memory of Unix users is vivid indeed, fed by early accounts within the computer world (Salus, 1994) as well as preservation initiatives (Toomey, 2010). Moreover, the Unix system is a crucial reference in the history of computing, in particular in the field of free and open source software (Kelty, 2008), computer networks (Paloque-Berges, 2017), as well as in programming language philosophy (Mélès, 2013). In order to explore the variety of these interrogations, this symposium encourages contributions from historians as well as philosophers, social science researchers, and heritage professionals interested in the history of computer open systems and software with a focus on Unix or who have a wider perspective. It will also welcome protagonists and witnesses of Unix culture and carriers of its memory. We wish to discuss and shed light on several aspects of the development of Unix in Europe (including in comparison or relation with the rest of the world) along three main lines: historical and sociological, philosophical and epistemological, and heritage- and preservation-oriented. *1/ Historical and sociological perspectives* * * Historically, the Unix system is linked to the promotion and development in research on open systems and computer networks. How does this fit in the context of industrial, scientific and technological policies defined at the national and European level? The history of Unix thus reaches at least three levels of interrogations: 1/ the forms, places and practices of innovation around Unix in R&D labs and computing centers in companies, schools and universities; 2/ planning, promoting and negotiating open systems (norms and standards) from the perspective of science and/or politics; 3/ international geopolitical relations, whether economical or geopolitical and even geostrategic (for example between Unix users, with users of other computer equipment or other hardware and software companies, the role of embargos in the shipping of mini-computers, of code, and military uses of Unix). In parallel, how has the world of computer research welcomed, encouraged, negotiated and propagated uses and innovations related to Unix systems? This begs the question of how Unix-related research and development was legitimized - or played a part in the legitimization of computer science experimentalism in the scientific field and beyond. We would also like to highlight practices of resistance, the failure to acknowledge, ignorance of or even the limits of the Unix system, its software tools and hardware environment (beginning with the famous PDP and Vax machines from Digital Equipment where the first Unix versions were implemented). With a focus on occupational computer uses, we call for analysis which aims to explore and clarify: - the role of developers, users, and user associations – from the point of view of pioneers as well as helpers, maintainers and other witnesses of the implementation of Unix; - the context, process, and people who determined its propagation, appropriation, and development over time; - the meaning of concepts of Unix philosophy and ethics such as “openness” and “autonomy”, from a social, political or economic point of view. *2. Philosophical and epistemological perspectives* We will foster research and reflection at the crossroad of the theoretical foundations of computer systems and engineering pragmatism, between the philosophy of computer systems and Unixian practices. Protagonists in the conception and diffusion of Unix often claim to have a ‘Unix philosophy’ . But beyond statement of principle, what was the real influence of this idea on the technical choices underlying the system’s developments? What are the ethical, moral, and philosophical motivations – alongside the social, political or economic dimensions discussed earlier – underpinning the adoption of Unix or pretending to extend it (for instance in relation to the notions of sharing, modularity or freedom)? How is the idea of ‘openness’ attached to Unix practices and heritage (free software, open source) conceived? What are the theoretical developments to be drawn from it (for instance with the idea of open software)? The logical and mathematical foundations of Unix should be readdressed. Do the fundamental concepts of Unix have an ontological or metaphysical significance beyond the sole research aim of technical efficiency? What role do aesthetics play in the formulation of general principles and technical choices? How can we analyze programming languages such as C and its successors, scripts, software, and generally speaking, the proliferating source codes of Unix? How do we consider the system, the software environment, as well as the hardware in which Unix is implemented and executed? Such philosophical questions also cover the modalities of the transmission of Unix, extending to the investigation of the respective roles of theory and practice in the teaching of the system, the teaching of knowledge and tools underlying the system or supporting the system. *3. Unix heritage and ‘heritagization’* ** France is now the home to multiple initiatives taking place to build and preserve a material and immaterial heritage of computer science and technology – such as ‘Software Heritage’ at INRIA, a global software archive in progress. The Museum of Arts et Métiers gave impetus to the MINF initiative (‘Pour un Musée de l’informatique et du numérique’) and coordinates the ‘Patstec Mission’ dealing with contemporary scientific and technological heritage preservation, including computer science. At an international scale and with a grassroots perspective carried by the community of Unix users, the TUHS (The Unix Heritage Society) demonstrates the current interest in the specific heritage linked to Unix. We encourage reflections on this heritage and its specific features: - What is the place of Unix in the construction of computer science heritage? Is it possible to map Unix systems and their heritage, from the standpoint of machines, languages and software? What has already been collected? What corpus, data bases, and/or platforms with a patrimonial mission are concerned with Unix and to what purpose? - How are the questions of training, constitution and diffusion of a Unix culture incorporated in the effort to collect heritage? How do we evaluate and put forward the importance of immaterial heritage attached to Unix, considering the effects of community and memory in its history and for the writing of its history? - What are the practices and modalities advocated by the unixian heritage itself? What has been its influence on the field of computer engineering and research as well as diverse fields such as: popularization of science and technology, ‘hacker’ movements and many ‘maker’ practices today (Lallement, 2016)? *Schedules* Please send a one-page abstract (maximum 500 words) with a short biography by June 30, 2017 to: camille.paloque-berges(a)cnam.fr <mailto:camille.paloque-berges@lecnam.net>and loic.petitgirard(a)cnam.fr <mailto:loic.petitgirard@cnam.fr>. Accepted contributions and speakers will be notified by July 15, 2017. *Organizing committee* Isabelle Astic (Musée des arts et métiers) Raphaël Fournier-S’niehotta (Cédric, Cnam) Pierre-Eric Mounier-Kuhn (CRM, Paris 1) Camille Paloque-Berges (HT2S, Cnam) Loïc Petitgirard (HT2S, Cnam) *Scientific committee * François Anceau (UMPC-LIP6)** Pierre Cubaud (Cédric, Cnam) Liesbeth de Mol (STL, Lille 3) Claudine Fontanon (CAK, EHESS) Gérald Kembellec (DICEN, Cnam) Baptiste Mélès (Archives Henri Poincaré, CNRS) Pierre Paradinas (Cédric, Cnam, SIF) Giuseppe Primiero (Middlesex University) Lionel Tabourier (LIP6, Paris 6)** *Institutional partners and support: * - Project « Hist.Pat.info.Cnam », HT2S, Cnam – Research program supported by the Excellence laboratory History and Anthropology of Knoweldge, Technics and Beliefs (HASTEC), and in partnership with the laboratories CEDRIC (Cnam), DICEN (Cnam), and the Center Alexandre Koyré (EHESS). - « Histoire de l’informatique » (« History of computing » seminar) seminar - (Musée des arts et métiers, CRM, Paris 1, UMPC-LIP6) - « Source code » seminar - (CNRS, Cnam, Université Paris 6). With support from the DHST/DLMPST for the History and Philosophy of Computing (HAPOC) *Bibliography * Kelty, Christopher M. 2008. /Two Bits: The Cultural Significance of Free Software/. Durham: Duke University Press Books. Lallement, Michel. 2016. /L’âge du faire, /Seuil. Mélès, Baptiste. 2003. « Unix selon l’ordre des raisons : la philosophie de la pratique informatique ». /Philosophia Scientiæ/17 (3): 181‑98. Salus, Peter H. 1994. /A quarter century of UNIX/. Addison-Wesley. Reading. Toomey, Warren. 2010. « First Edition Unix: Its Creation and Restoration ». /IEEE Annals of the History of Computing/ 32 (3): 74‑82. * * **

7 years, 11 months

Re: [TUHS] 211bsd: kernel panic after a 'here document' in tcsh

by jnc＠mercury.lcs.mit.edu

> From: "Walter F.J. Mueller" > the kernel panic after tcsh here documents is understood. Very nice detective work! > The kernel panic is due to a coding error in mch_fpsim.s. ... After > fixing the "$SIGILL." ... and three similar cases I'm fairly amazed that apparently nobody has run across one of these 4 before! (Or, at least, not bothered to report it.) I wonder how long that bug has been in the code? Noel

7 years, 12 months

Re: [TUHS] 211bsd: kernel panic after a 'here document' in tcsh

by Johnny Billquist

On 2017-06-11 04:00, "Walter F.J. Mueller" <w.f.j.mueller(a)retro11.de> wrote: > Hi, > > the kernel panic after tcsh here documents is understood. > And fixed, at least on my system. Nice work. Looking forward to patch #250. And to respond to Noels remark about this being around for a long time without reports - since this is in FPSIM, and I believe the notes for 2.11BSD even says that this is an untested piece of code, which are not even know if it works or not, it's not something that have been used for ages. I'm in a way surprised it even worked at all. I think I've seen somewhere that it was last tested around 2.9BSD, and have not been officially tested since. > The essential hint was Johnny's observation that on his system he gets > an "Illegal instruction - core dumped" and no kernel panic. Well, had I had FPP simulated, I would maybe not have gotten a kernel panic anyway. It would all depend on where the address ended up. With my current build, the kernel would have been able to read the address, since it pointed into the boot diagnostics rom. So it's a dicey error at best. But the tcsh error was very good that you also figured out. And I guess it means we now have a known working FPSIM. :-) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

7 years, 12 months

Array index history

by Doug McIlroy

> Who started this? Why was the change made? Arrays in Fortran and Algol were indexed from 1 by default, but Algol (IIRC) generalized that to allow first:last declarations. NPL used first,last for the SUBSTR operation. But first,last begets off-by-one errors. The successor slice begins at last+1. The formula for the position of 1-indexed a[i,j] is a mess. First,length is much cleaner: the successor begins at first+length. I convinced the committee of that, so when NPL became PL/I, first,length was the convention. Zero- indexing is also a clean first,length notation. BCPL, where a[i] was synonymous with rv(a+i), had it. Dennis, who knew a good thing when he saw it, took it over. Dijkstra, too, often inveighed against 1-indexing, and opined that zero was the true computer-science way. 1-indexing certainly came into programming languages from the math tradition for matrix notation. Of course in math series are often indexed from zero, so one may pick and choose. Off hand I can only think of one CS context where 1 comes in handy: heapsort. Doug

7 years, 12 months

Re: [TUHS] 211bsd: kernel panic after a 'here document' in tcsh

by Walter F.J. Mueller

Hi, the kernel panic after tcsh here documents is understood. And fixed, at least on my system. The essential hint was Johnny's observation that on his system he gets an "Illegal instruction - core dumped" and no kernel panic. I'm using a self-build PDP 11/70 on an FPGA, see https://github.com/wfjm/w11/ https://wfjm.github.io/home/w11/ which doesn't have a floating point unit. Therefore the kernel is build with floating point emulation, thus with FPSIM YES # floating point simulator In a kernel with FPSIM activated the trap handler trap(), see http://www.retro11.de/ouxr/211bsd/usr/src/sys/pdp/trap.c.html calls for each user mode illegal instruction trap fpsim(). In case it was a floating point instruction fpsim() emulates it, returns 0, and trap() simply returns. If not, fpsim() returns the abort signal type, and trap() calls psignal() with this signal type, which in general will terminate the offending process. The kernel panic is due to a coding error in mch_fpsim.s. Look in http://www.retro11.de/ouxr/211bsd/usr/src/sys/pdp/mch_fpsim.s.html the code after label badins: badins: / Illegal Instruction mov $SIGILL.,r0 br 2b The constant SIGILL is defined in assym.h as #define SIGILL 4. Thus after substitution the mov instruction is mov $4..,r0 with *two dots* !!! The 'as' assembler generates from this mov #160750,r0 So r0 will contain a invalid signal number, which is returned by fpsim() to trap(). This signal number is passed to psignal(), which starts with mask = sigmask(sig); prop = sigprop[sig]; The access to sigprop[sig] results into an address in IO space, causes an UNIBUS timeout, and in consequence the kernel panic. After fixing the "$SIGILL." to "$SIGILL" (removing the extraneous '.') and three similar cases the kernel doesn't panic anymore, tcsh crashed with an illegal instruction trap. Remains the question why tcsh runs onto an illegal instruction. Getting now a tcsh core dump adb gives the answer adb tcsh tcsh.core $c 0172774: _rscan(0176024,0174434) from ~heredoc+0246 0176040: _heredoc(067676) from ~execute+0234 0176126: _execute(067040,01512,0,0) from ~execute+03410 0176222: _execute(066754,01512,0,0) from ~process+01224 0176274: _process(01) from ~main+06030 0177414: _main() from start+0104 heredoc(), which is located in OV1, calls rscan(), which is in OV6 with rscan(Dv, Dtestq); where Dtestq is a function pointer to Dtestq(), which is as heredoc() in OV1. rscan(), which has the signature rscan(t, f) register Char **t; void (*f) (); uses 'f' in the statement (*f) (*p++); The problem is that - heredoc() and Dtestq() are in OV1 - that's why in the end ~Dtestq is used a function pointer, like for all overlay internal function invocations - rscan() is in OV6, when it's called, overlay is switched OV1 -> OV6 - this invalidates the function pointer, which points to some random code location, which happens to hold '000045', causing a trap. It is clear that in this context _Dtestq, the forwarder in the base, must be used and not ~Dtestq, the entry point in the overlay. The generated code for 'rscan(Dv, Dtestq)' is ~heredoc+0230: mov $0174434,(sp) # arg Dtestq: uses ~Dtestq ~heredoc+0234: mov r5,-(sp) ~heredoc+0236: add $0177764,(sp) # arg Dv ~heredoc+0242: jsr pc,*$_rscan Since rscan() is very small and only used by heredoc() I simply moved the code of rscan() from sh.glob.c (OV6) to sh.dol.c where also heredoc() and Dtestq() is defined. After that tcsh works fine with here documents ./tcsh cat >x.x <<EOF 1 $TERM $PWD EOF cat x.x 1 vt100-long /usr/src/bin/tcsh Bottom line - fpsim was broken all the time - tcsh was broken all the time I'm convert this into proper patches and send them to Steven, but this will take some time because I've to tidy up my system to be again in the position to provide proper and clean patch sets. With best regards, Walter P.S.: debugging the kernel issue was quite easy because the w11a CPU has three essential 'build into the cpu' debug tools: - a 'cpu monitor', which records 144 bits of processor state for the last 256 instructions or vector fetches, see https://github.com/wfjm/w11/blob/master/rtl/w11a/pdp11_dmcmon.vhd - a 'breakpoint unit' which allows to set instruction of data breakpoints - an 'ibus monitor' which records the last 512 ibus transactions After setting a breakpoint on the trap 004/010 handler an inspection of the instruction trace gave the essential information. Below a very condensed and annotated excerpt nc ....pc cprptnzvc ..dsrc ..ddst ..dres vmaddr vmdata # # the "(*f) (*p++)" in tcsh, running onto an illegal instruction # 15 145210 uu00-.... 000105 173052 000105 w d 173052 000105 mov r0,(sp) 25 145212 uu00-.... 173050 174434 174434 w d 173050 145216 jsr pc,@n(r5) 19 174434 uu00-.... 000010 173064 000010 r i 174434 000045 ?000045? 1 174434 uu00-.... 000012 173064 000012 r d 000010 000045 !VFETCH 010 RIT # # the "mov $SIGILL.,r0" in fpsim(), load 160750 instead of 000004 # 17 160744 ku00-n..c 160750 000045 160750 r i 160746 160750 mov #n,r0 14 160750 ku00-n..c 160752 160750 160732 r i 160750 000770 br .-14 # # the "sigprop[sig]" access in psignal(), which accesses 174036 # which leads to a external bus (or UNIBUS) time out and IIT trap # 23 161314 ku00-.z.. 000000 147500 000000 w d 147500 000000 mov r1,n(r5) 9 161320 ku00-.z.. 174036 000000 000000 Ebto 174036 013066 movb n(r3),r0 3 161320 ku00-.z.. 000006 000000 000006 r d 000004 013066 !VFETCH 004 IIT

7 years, 12 months

Re: [TUHS] Array index history

by David

Arnold gets it right on the Pascal indexing. In UCSD Pascal you could specify any array bounds you would like and the compiler would 0 base them for you by always doing a subtraction, or addition if your min was negative, of your min array index. So a little run time cost for non-zero based arrays. I’m not sure how other Pascal compilers did this. I find it interesting that there are now a slew of testing programs (Valgrind, Address Sanitizer, Purify, etc) that will add the ‘missing’ array bounds checking for C. David > On Jun 7, 2017, at 10:01 AM, tuhs-request(a)minnie.tuhs.org wrote: > > Date: Wed, 07 Jun 2017 07:20:43 -0600 > From: arnold(a)skeeve.com > To: tuhs(a)tuhs.org, ag4ve.us(a)gmail.com > Subject: Re: [TUHS] Array index history > Message-ID: <201706071320.v57DKhmJ026303(a)freefriends.org> > Content-Type: text/plain; charset=us-ascii > > Pascal (IIRC) allowed you to specify upper and lower bounds, something > like > > foo : array[5..10] of integer; > > with runtime bounds checking on array accesses. (I could be wrong --- > it's been a LLLLOOONNNGGG time.) > > HTH, > > Arnold

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