[TUHS] RIP J.F.Ossanna

[TUHS] RIP J.F.Ossanna

[Dave Horsfall]

We lost J.F. Ossanna on this day in 1977; he had a hand in developing 
Unix, and was responsible for "roff" and its descendants.  Remember him, 
the next time you see "jfo" in Unix documentation.

--
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] RIP J.F.Ossanna

[Ron Natalie]

1977 marks my entry into the world of UNIX.   I've always stated there was
only one person who truly understood nroff and he was dead.
I mourn the fact that of all the UNIX greats I've met, I missed out on
Ossanna.

[TUHS] RIP J.F.Ossanna

[Larry McVoy]

Indeed.  As a big roff fan, not having had the chance to meet him is a
bummer, might have been fun.

On Tue, Nov 28, 2017 at 09:05:19AM +1100, Dave Horsfall wrote:
> We lost J.F. Ossanna on this day in 1977; he had a hand in developing Unix,
> and was responsible for "roff" and its descendants.  Remember him, the next
> time you see "jfo" in Unix documentation.
> 
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] RIP J.F.Ossanna

[Larry McVoy]

I think one could argue that James Clark has a pretty good handle on
roff (having written the GNU version of nroff/troff/tbl/eqn/pic etc).

On Mon, Nov 27, 2017 at 07:06:51PM -0500, Ron Natalie wrote:
> 1977 marks my entry into the world of UNIX.   I've always stated there was
> only one person who truly understood nroff and he was dead.
> I mourn the fact that of all the UNIX greats I've met, I missed out on
> Ossanna.
> 

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] RIP J.F.Ossanna

[Larry McVoy]

On Wed, Nov 29, 2017 at 08:00:55PM +0100, Steffen Nurpmeso wrote:
> Larry McVoy <lm at mcvoy.com> wrote:
>  |On Mon, Nov 27, 2017 at 07:06:51PM -0500, Ron Natalie wrote:
>  |> 1977 marks my entry into the world of UNIX.   I've always stated there was
>  |> only one person who truly understood nroff and he was dead.
>  |> I mourn the fact that of all the UNIX greats I've met, I missed out on
>  |> Ossanna.
> 
>  |I think one could argue that James Clark has a pretty good handle on
>  |roff (having written the GNU version of nroff/troff/tbl/eqn/pic etc).
> 
> And Werner Lemberg, who carried the torch for the last almost two
> decades.  He brought in some really great improvements, like
> arguments for strings, which allows to write pretty much TeX like
> a.k.a. inline if you want to (as in "this is \*[I talic] text").

Yep.  James exited stage left and Werner stepped in.  I mean no disrespect
to anyone, I was just saying that James has a really good handle on roff,
he redid it all.  I admire him for doing so (even though I curse the fact
that he did it in C++).

[TUHS] RIP J.F.Ossanna

[Steffen Nurpmeso]

Larry McVoy <lm at mcvoy.com> wrote:
 |On Wed, Nov 29, 2017 at 08:00:55PM +0100, Steffen Nurpmeso wrote:
 |> Larry McVoy <lm at mcvoy.com> wrote:
 |>|On Mon, Nov 27, 2017 at 07:06:51PM -0500, Ron Natalie wrote:
 |>|> 1977 marks my entry into the world of UNIX.   I've always stated \
 |>|> there was
 |>|> only one person who truly understood nroff and he was dead.
 |>|> I mourn the fact that of all the UNIX greats I've met, I missed out on
 |>|> Ossanna.
 |> 
 |>|I think one could argue that James Clark has a pretty good handle on
 |>|roff (having written the GNU version of nroff/troff/tbl/eqn/pic etc).
 |> 
 |> And Werner Lemberg, who carried the torch for the last almost two
 |> decades.  He brought in some really great improvements, like
 |> arguments for strings, which allows to write pretty much TeX like
 |> a.k.a. inline if you want to (as in "this is \*[I talic] text").
 |
 |Yep.  James exited stage left and Werner stepped in.  I mean no disrespect
 |to anyone, I was just saying that James has a really good handle on roff,
 |he redid it all.  I admire him for doing so (even though I curse the fact
 |that he did it in C++).

The original source was no free code back then, so he did it for
the free and open software world.  Thankfully.  And i do not know,
i mean C++ was in 1989-1992, when he did most of the work as far
as i can tell from a shallow look, a class, later template
extension layer for plain C, not that overly huge stands-by-itself
monster that i call it now.

I am absolutely in favour and a of classes and objects, the
encapsulation they provide, the method-on-object rather than
object-on-function that you have with C.  (Multiple) Inheritance
including automatic upcasts (to the given parent).  Virtual
function pointer tables, automatically managed.  And "simple"
templates.  For example, myself, in the process of creating my own
fork, can write (globbering the global namespace)

   color &assign_rgb(rf_ui32 r, rf_ui32 g, rf_ui32 b){
      m_scheme = scheme_rgb;
      return set_red(r).set_green(g).set_blue(b);
   }  
   color &set_red(rf_ui32 c){
      rf_ASSERT(scheme() == scheme_rgb);
      m_comps[0] = rf_min(c, max_val);
      return *this;
   }
   ...

instead of

  rf_color *rf_color_assign_rgb(rf_color *self, rf_ui32 r, ....){
    self->c_scheme = rf_COLOR_SCHEME_RGB;
    self->c_comps[0] = rf_MIN(r, rf_COLOR_MAX_VAL);
    ...
    return self;
  }

and programming all that out over and over again.  (Or using
macros with side-effects.  Or relying on inline functions.)
And that is a simple object with a short name.
References are unfortunate in my opinion, but you will not see any
light if you try doing C++ without them because they are
omnipresent for core functionality like standard copy constructors
etc.  Like many other things, including the complete departure
from an underlaying C standard.  C++03/C99 or so i would have
appreciated.  But as long as -fno-rtti -fno-exceptions is possible
i can somehow live with it.  (Let aside the fact that i have to
live with it no matter what bloat the C++ standard introduces
next.)  And then C is not what it was no more, too, and
unfortunately the usage-makes-fun guideline from what Plan9
documents and extends onto ISO C89 was not what the ISO C people
looked at when they did.  Well.

Maybe if he would have known what C++ ends up as he would have
used C instead?  That would be an interesting question.  Myself
i currently appreciate coming back to a C++ codebase, however,
because thinking in objects is my personal way of dealing with
programming, that is how i really got used to it, anyway.

--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)

[TUHS] RIP J.F.Ossanna

[Noel Hunt]

If you want to see a nice use of a restricted subset of C++,
that is, code written in the early days before the accretion
of hideous excrescences, I highly recommend Tom Cargill's
'pads'. You will find it in the 10th Edition distributions.
It is a typical blit-style program, with a 'terminal' and
'host' portion, the 'host' portion being written in the said
restricted, earlier form of C++.

The 'terminal' part is in C (this is the graphics front-end)
but written for the blit. There was an OpenLook port by Dave
Kowolski, and I have a version that runs under Plan9 (via
Russ Cox's plan9port)---there is a straight-forward mapping
of blit graphics operations to the Plan9 model.

Noel Hunt

On Fri, Dec 1, 2017 at 2:44 AM, Steffen Nurpmeso <steffen at sdaoden.eu> wrote:

> Larry McVoy <lm at mcvoy.com> wrote:
>  |On Wed, Nov 29, 2017 at 08:00:55PM +0100, Steffen Nurpmeso wrote:
>  |> Larry McVoy <lm at mcvoy.com> wrote:
>  |>|On Mon, Nov 27, 2017 at 07:06:51PM -0500, Ron Natalie wrote:
>  |>|> 1977 marks my entry into the world of UNIX.   I've always stated \
>  |>|> there was
>  |>|> only one person who truly understood nroff and he was dead.
>  |>|> I mourn the fact that of all the UNIX greats I've met, I missed out
> on
>  |>|> Ossanna.
>  |>
>  |>|I think one could argue that James Clark has a pretty good handle on
>  |>|roff (having written the GNU version of nroff/troff/tbl/eqn/pic etc).
>  |>
>  |> And Werner Lemberg, who carried the torch for the last almost two
>  |> decades.  He brought in some really great improvements, like
>  |> arguments for strings, which allows to write pretty much TeX like
>  |> a.k.a. inline if you want to (as in "this is \*[I talic] text").
>  |
>  |Yep.  James exited stage left and Werner stepped in.  I mean no
> disrespect
>  |to anyone, I was just saying that James has a really good handle on roff,
>  |he redid it all.  I admire him for doing so (even though I curse the fact
>  |that he did it in C++).
>
> The original source was no free code back then, so he did it for
> the free and open software world.  Thankfully.  And i do not know,
> i mean C++ was in 1989-1992, when he did most of the work as far
> as i can tell from a shallow look, a class, later template
> extension layer for plain C, not that overly huge stands-by-itself
> monster that i call it now.
>
> I am absolutely in favour and a of classes and objects, the
> encapsulation they provide, the method-on-object rather than
> object-on-function that you have with C.  (Multiple) Inheritance
> including automatic upcasts (to the given parent).  Virtual
> function pointer tables, automatically managed.  And "simple"
> templates.  For example, myself, in the process of creating my own
> fork, can write (globbering the global namespace)
>
>    color &assign_rgb(rf_ui32 r, rf_ui32 g, rf_ui32 b){
>       m_scheme = scheme_rgb;
>       return set_red(r).set_green(g).set_blue(b);
>    }
>    color &set_red(rf_ui32 c){
>       rf_ASSERT(scheme() == scheme_rgb);
>       m_comps[0] = rf_min(c, max_val);
>       return *this;
>    }
>    ...
>
> instead of
>
>   rf_color *rf_color_assign_rgb(rf_color *self, rf_ui32 r, ....){
>     self->c_scheme = rf_COLOR_SCHEME_RGB;
>     self->c_comps[0] = rf_MIN(r, rf_COLOR_MAX_VAL);
>     ...
>     return self;
>   }
>
> and programming all that out over and over again.  (Or using
> macros with side-effects.  Or relying on inline functions.)
> And that is a simple object with a short name.
> References are unfortunate in my opinion, but you will not see any
> light if you try doing C++ without them because they are
> omnipresent for core functionality like standard copy constructors
> etc.  Like many other things, including the complete departure
> from an underlaying C standard.  C++03/C99 or so i would have
> appreciated.  But as long as -fno-rtti -fno-exceptions is possible
> i can somehow live with it.  (Let aside the fact that i have to
> live with it no matter what bloat the C++ standard introduces
> next.)  And then C is not what it was no more, too, and
> unfortunately the usage-makes-fun guideline from what Plan9
> documents and extends onto ISO C89 was not what the ISO C people
> looked at when they did.  Well.
>
> Maybe if he would have known what C++ ends up as he would have
> used C instead?  That would be an interesting question.  Myself
> i currently appreciate coming back to a C++ codebase, however,
> because thinking in objects is my personal way of dealing with
> programming, that is how i really got used to it, anyway.
>
> --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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171201/2bdd154e/attachment-0001.html>

[TUHS] RIP J.F.Ossanna

[Steffen Nurpmeso]

Noel Hunt <noel.hunt at gmail.com> wrote:
 |If you want to see a nice use of a restricted subset of C++,
 |that is, code written in the early days before the accretion
 |of hideous excrescences, I highly recommend Tom Cargill's
 |'pads'. You will find it in the 10th Edition distributions.

I downloaded it from [1]

  [1] http://www.softwarepreservation.org/projects/c_plus_plus/application/application/pi_pads_libj.tgz

 |It is a typical blit-style program, with a 'terminal' and
 |'host' portion, the 'host' portion being written in the said
 |restricted, earlier form of C++.

Yes, that package looks good.  Two nice things in 5 minutes:

        if( !this ) return 0;

I would like to read "references are needless" into that.

  // C++ bug (Action)

Yes!  That is exactly my gut feeling, too!

Interestingly it seems that it has been possible to apply access
policies on file level, even for preprocessor things etc.:

  >pri
  #define PADS_VERSION 0x851021           /* YYMMDD */
  #define CARTE    0x80
  #define NUMERIC  1
  >

That i never had seen before.
Quite a lot of C++ in this package..

 |The 'terminal' part is in C (this is the graphics front-end)
 |but written for the blit. There was an OpenLook port by Dave
 |Kowolski, and I have a version that runs under Plan9 (via
 |Russ Cox's plan9port)---there is a straight-forward mapping
 |of blit graphics operations to the Plan9 model.
 |
 |Noel Hunt

In V10 there are the sources of cfront, and also troff, pic etc.
I would wish i had more time to look through that.  Most code
from these laboratories and universities is just casual, this is
what i like so much.  I mean, really.  Most of the elder code goes
like about

                LayerReshaped();
                MOUSEServe();
                KBDServe();
                RCVServe();

and is done with it  When i started, as well as today, notational
things for namespace and (get, set) functions were in use for at
least libraries, and then i found C++ preferable over C due to
"using NAME" directives etc., whereas in C you go for
g_mount_tracker_find_by_mount_spec() and woe if the argument is "a
subclass".  And pi is really a debugger!?  I detest debuggers!
But he instrumented most of it with trace() and VOK by hand in
order to debug that thing.  That is fantastic.  I dislike so much
that today shipout code of even the smallest utility is compiled
with stack canaries enabled, the assembly looks infested, all that
should be kept in debug code, in my opinion.

--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)

[TUHS] RIP J.F.Ossanna

[Norman Wilson]

Larry McVoy:

  I've always morned that he died so early.  I would have liked to talk 
  to him, I love troff to this day.

====

Me too (s/morn/mourn/, of course).  I might even have had the
chance to work with him.

The original UNIX crowd were all really neat characters, albeit
sometimes a trifle overly characterful.  All nice guys to work
with, too, at least those who were still around when I was at
1127.

Norman Wilson
Toronto ON

[TUHS] RIP J.F.Ossanna

[Larry McVoy]

I've always morned that he died so early.  I would have liked to talk 
to him, I love troff to this day.

On Mon, Nov 28, 2016 at 09:15:00AM +1100, Dave Horsfall wrote:
> We lost J.F.Ossanna in 1977; he had a hand in developing Unix, and was 
> responsible for "roff" and its descendants.  Remember him, the next time 
> you see "jfo" in documentation.
> 
> -- 
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] RIP J.F.Ossanna

[Ron Natalie]

Yes, he had died by the time I knew what UNIX was.   My jest was always that
there was only one person who truly understood troff and he was dead.

-----Original Message-----
From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Dave Horsfall
Sent: Sunday, November 27, 2016 5:15 PM
To: The Eunuchs Hysterical Society
Subject: [TUHS] RIP J.F.Ossanna

We lost J.F.Ossanna in 1977; he had a hand in developing Unix, and was
responsible for "roff" and its descendants.  Remember him, the next time you
see "jfo" in documentation.

--
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
suffer."

[TUHS] RIP J.F.Ossanna

[Dave Horsfall]

We lost J.F.Ossanna in 1977; he had a hand in developing Unix, and was 
responsible for "roff" and its descendants.  Remember him, the next time 
you see "jfo" in documentation.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."