> In hindsight Algol68 may have been the last committee designed
> language that was good.
The committee itself fractured over the design. Dissenters who thought
it was far too complex upped stakes and formed WG2.3, which pointedly
concentrated on program design, not language.
Doug
Hi.
I am trying to figure out how to create a device /dev for lp.
I have mknod but need the (c,b) major/minor numbers for /dev/lp
/etc/mknod name c | b major minor
I do have the required software to run lp. I have read through the
docs I have but no luck.
Thanks
Ken
--
WWL 📚
> From: Warner Losh
> In C I use it all the time to do goto err for common error recovery
> because C doesn't have anything better.
That's because C doesn't have 'conditions'. (Apparently, from the following
posts, most people here are unfamiliar with them. Too bad, they are a great
idea. OK summary here:
http://gunkies.org/wiki/Condition_handler
for those who are unfamiliar with the idea.)
I was at one point writing a compiler using a recursive descent parser, and
decided the code would be a lot simpler/cleaner if I had them. (If, for
example, one discovers discovers an un-expected 'end of file', there can be
an extremely large number of procedure invocations in between where that is
discovered, and where it is desirable to handle it. So every possible
intervening procedure would have to have an 'unexpected EOF' return value,
one would have to write code in every possible intervening procedure to
_handle_ an 'unexpected EOF' return value, etc.)'
(Yes, I could have used setjmp/longjmp; those are effectively a limited
version of condition handlers.)
Since C has a stack, it was relatively easy to implement, without any compiler
support: on() became a macro for 'if _on("condition_name")'; _on() was a
partially-assembler procedure which i) stacked the handler (I forget where I
put it; I may have created a special 'condition stack', to avoid too many
changes to the main C stack), and ii) patched the calling procedure's return
point to jump to some code that unstacked the handler, and iii) returned
'false'. If the condition occurred, a return from _on() was simulated,
returning 'true', etc.
So the code had things like:
on ("unexpected EOF") {
code to deal with it
}
With no compiler support, it added a tiny bit of overhead
(stacking/unstacking conditions), but not too bad.
John Wroclawski and someone implemented a very similar thing
entirely in C; IIRC it was built on top of setjmp/longjmp. I don't
recall how it dealt with un-stacking handlers on exit (which mine
did silently).
Noel
I wonder if Pink Floyd's Summer68 maybe refers to this.
Other than that i am addicted and could not live without it.
The other (terrible) song is from 1984 (east southern US).
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Starting this in TUHS due to UNIX relevance, but with the heavy disclaimer this should quickly diverge to COFF if it drifts into foreign waters.
I've gotten to reading about 5ESS lately, and it seems there are many in use still today. I found myself wondering what the evolution has looked like as far as computing hardware and operating systems involved. DMERT ran on the 3B-20D supporting the 5ESS systems in the early 80s, at the same time that UNIX 4.x was making rounds on the 3B-20S.
A 5ESS manual from 2001[1] mentions UNIX RTR (Real-Time Reliable) of the DMERT lineage. Wikipedia[2] suggests 5ESS is still very much in use and mentions more modern systems like VCDX; its "Sun Microsystems SPARC workstation runs the UNIX-based Solaris (operating system) that executes a 3B20/21D processor MERT OS emulation system." This sounds like the Lucent 3B20 emulator.
Is there still a line of UNIX RTR/DMERT being maintained to this day? Or are users left with other avenues to keep their hardware updated if necessary?
[1] - https://documentation.nokia.com/cgi-bin/dbaccessfilename.cgi/235600510_V1_5…
[2] - https://en.wikipedia.org/wiki/5ESS_Switching_System
- Matt G.
On SCO UNIX 3.2V4 you indeed have local virtual consoles moving from one to
another using the function keys. Worked from F1 to F12, but how often you
could login would depend on your license. Of course all still character
based, and depending on your TERM setting.
--
The more I learn the better I understand I know nothing.
Hi!
I have an updated Unix 2.0v2 package running under the current Vax-780 sim.
It has been tuned up with missing packages and some new ones. Like automatic
startup with date/time setting, running fsck at boot and properly shutting
down
ALL processes at shutdown allowing for a "clean" shutdown thereby avoiding
fsck issues at the next boot.
Also there is a virtual tape so you can do backups..
My question is can THIS version access an IP address? And if so, how.
If there is any interest I could package it up into a tar file for others.
Thanks,
Ken
--
WWL 📚
Hello folks, posing a question here that will help with some timelining.
So System III, according to everything I've read, was commercially issued in 1982. However, PWB 3.0 was issued internally in 1980, two years prior. This isn't that surprising, give USL some time to work it up for commercial-readiness.
Where I'm curious is if there was a similar gap for the public release of PWB, given that was earlier on and pre-support and such. Was there a particular "public release" date for PWB 1.0 or would it have just been whenever folks started getting tapes out of Bell? I know it shows up in a price sheet floating around from say 1983 or 1984 among the likes of V7, 32V, System III, and System V also for sale, but would anything that early have had a formal "ship date" indicating a day they cut the master to copy tapes from or was it more of a contact Bell, someone will cut you a tape of whatever we've got right now?
Also, was PWB held as something that would be "marketable" from the get-go, or was it more of a happy accident that it wound up in the right place in the right time to become the commercial line? One would think USG Generic would be the one they'd shoot for being the "base" to build on, but everything I'm finding in my study of System III lately is pointing to a much more PWB-ish lineage with random borrowings from CB, PY, HO, IH, among others.
- Matt G.
There was such a tool, psroff (same name as, but no shared code with the
Adobe version) that read either C/A/T or ditroff output and produced
postcript. It was in volume 24 of comp.sources.unix. There were also
multiple patches to it.
It dates from 1991.
segaloco, you were looking for this? Contact me privately if you can't
find it.
Arnold
> From: "Ronald Natalie"
> Multilevel breaks are as bad as goto with regard to structure violation.
In a way, you are right. There isn't really much difference between:
for (mumble) {
for (foobar) {
do some stuff
break-2;
}
}
and:
for (mumble) {
for (foobar) {
do some stuff
goto all_loops_done;
}
}
all_loops_done:
The former is basically just 'syntactic sugar' for the latter.
I think the point is that goto's aren't necessarily _always_ bad, in and of
themselves; it's _how_, _where_ and _why_ one uses them. If one uses goto's
in a _structured_ way (oxymoronic as that sounds), to get around things that
are lacking in the language's flow-control, they're probably fine.
Then, of course, one gets into the usual shrubbery of 'but suppose someone
uses them in a way that's _not_ structured?' There's no fixing stupid, is my
response. Nested 'if/then/else' can be used to write comletely
incomprehensible code (I have an amusing story about that) - but that's not
an argument against nested 'if/then/else'.
As I've said before, the best sculpting tools in the world won't make a great
sculptor out of a ham-handed bozo.
Noel