The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* Re: [TUHS] block operations in editors, was  My EuroBSDcon talk
@ 2019-09-17 17:31 Doug McIlroy
  2019-09-18  4:47 ` Steve Johnson
  0 siblings, 1 reply; 10+ messages in thread
From: Doug McIlroy @ 2019-09-17 17:31 UTC (permalink / raw)
  To: tuhs, jnc

Noel Chiappa wrote:

>    > From: Doug McIlroy
>
>    > the absence of multidemensional arrays in C.
>
>?? From the 'C Reference Manual' (no date, but circa 'Typesetter C'), pg. 11:
>
>  "If the unadorned declarator D would specify an n-dimensional array .. then
>  the declarator D[in+1] yields an (n+1)-dimensional array"
>
>
>I'm not sure if I've _ever_ used one, but they are there.

Yes, C allows arrays of arrays, and I've used them aplenty.
However an "n-dimensional array" has one favored dimension,
out of which you can slice an array of lower dimension. For
example, you can pass a row of a 2D array to a function of a
1D variable, but you can't pass a column. That asymmetry
underlies my assertion. In Python, by contrast, n-dimensional
arrays can be sliced on any dimension.

Doug

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [TUHS] block operations in editors, was  My EuroBSDcon talk
  2019-09-17 17:31 [TUHS] block operations in editors, was My EuroBSDcon talk Doug McIlroy
@ 2019-09-18  4:47 ` Steve Johnson
  2019-09-18  4:52   ` Jon Steinhart
  0 siblings, 1 reply; 10+ messages in thread
From: Steve Johnson @ 2019-09-18  4:47 UTC (permalink / raw)
  To: Doug McIlroy, tuhs, jnc

[-- Attachment #1: Type: text/plain, Size: 1771 bytes --]

This is one of my pet peeves.  "Random Access" memory is far from
random when you look at the time it takes to do the accesses.  With
modern memories, accessing a column can be 20 to 40x slower than
accessing a row.  This is particularly irritating when doing AI
training, where training reuses 4-d tensors transposed, a very painful
operation.

In FORTRAN days, I once used a vector package in which you described a
vector by giving the first element, the second element, and a count. 
So you could describe rows, columns, a matrix diagonal, and even rows
and columns from back to front.  Fortran passed arguments by address,
which made the whole thing easy and fast.

Steve

----- Original Message -----
From: "Doug McIlroy" <doug@cs.dartmouth.edu>
To:<tuhs@tuhs.org>, <jnc@mercury.lcs.mit.edu>
Cc:
Sent:Tue, 17 Sep 2019 13:31:52 -0400
Subject:Re: [TUHS] block operations in editors, was My EuroBSDcon talk

 Noel Chiappa wrote:

 > > From: Doug McIlroy
 >
 > > the absence of multidemensional arrays in C.
 >
 >?? From the 'C Reference Manual' (no date, but circa 'Typesetter
C'), pg. 11:
 >
 > "If the unadorned declarator D would specify an n-dimensional array
.. then
 > the declarator D[in+1] yields an (n+1)-dimensional array"
 >
 >
 >I'm not sure if I've _ever_ used one, but they are there.

 Yes, C allows arrays of arrays, and I've used them aplenty.
 However an "n-dimensional array" has one favored dimension,
 out of which you can slice an array of lower dimension. For
 example, you can pass a row of a 2D array to a function of a
 1D variable, but you can't pass a column. That asymmetry
 underlies my assertion. In Python, by contrast, n-dimensional
 arrays can be sliced on any dimension.

 Doug



[-- Attachment #2: Type: text/html, Size: 2564 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [TUHS] block operations in editors, was My EuroBSDcon talk
  2019-09-18  4:47 ` Steve Johnson
@ 2019-09-18  4:52   ` Jon Steinhart
  0 siblings, 0 replies; 10+ messages in thread
From: Jon Steinhart @ 2019-09-18  4:52 UTC (permalink / raw)
  To: tuhs

Steve Johnson writes:
> This is one of my pet peeves.  "Random Access" memory is far from random when
> you look at the time it takes to do the accesses.  With modern memories,
> accessing a column can be 20 to 40x slower than accessing a row.  This is
> particularly irritating when doing AI training, where training reuses 4-d
> tensors transposed, a very painful operation.
> 
> In FORTRAN days, I once used a vector package in which you described a vector
> by giving the first element, the second element, and a count.  So you could
> describe rows, columns, a matrix diagonal, and even rows and columns from back
> to front.  Fortran passed arguments by address, which made the whole thing easy
> and fast.
> 
> Steve

Remember the words of that great performance pioneer Jimmy Durante: ras-a-ma-cas.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [TUHS] block operations in editors, was  My EuroBSDcon talk
@ 2019-09-17 15:36 Noel Chiappa
  0 siblings, 0 replies; 10+ messages in thread
From: Noel Chiappa @ 2019-09-17 15:36 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Doug McIlroy

    > the absence of multidemensional arrays in C.

?? From the 'C Reference Manual' (no date, but circa 'Typesetter C'), pg. 11:

  "If the unadorned declarator D would specify an n-dimensional array .. then
  the declarator D[in+1] yields an (n+1)-dimensional array"

I'm not sure if I've _ever_ used one, but they are there.

    Noel

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [TUHS] block operations in editors, was My EuroBSDcon talk
@ 2019-09-17 11:34 Thomas Paulsen
  0 siblings, 0 replies; 10+ messages in thread
From: Thomas Paulsen @ 2019-09-17 11:34 UTC (permalink / raw)
  To: g.branden.robinson; +Cc: tuhs

---------------------------------
>
> Though the vi clone with the best name was, indisputably, elvis.
>
unfortunately unmaintained.
elvis has a smaller memory footprint, and a more pleasant (nroff later html) based help support than vim. There are no plugin, vimscript feature sas well as no python/perl support. I'm interested in a vi with syntax coloring and help support, however I don't need scripting features. Therefore I hope someone will take over maintenance, as I'm too old for tha



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [TUHS] block operations in editors, was  My EuroBSDcon talk
  2019-09-17  0:42 ` G. Branden Robinson
  2019-09-17  2:02   ` George Michaelson
@ 2019-09-17 11:01   ` Thomas Paulsen
  1 sibling, 0 replies; 10+ messages in thread
From: Thomas Paulsen @ 2019-09-17 11:01 UTC (permalink / raw)
  To: G. Branden Robinson; +Cc: tuhs


---------------------------------
>
> Though the vi clone with the best name was, indisputably, elvis.
>
unfortunately unmaintained.
elvis has a smaller memory footprint, and a more pleasant (nroff later html) based help support than vim. There are no plugin, vimscript feature sas well as no python/perl support. I'm interested in a vi with syntax coloring and help support, however I don't need scripting features. Therefore I hope someone will take over maintenance, as I'm too old for that.



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [TUHS] block operations in editors, was My EuroBSDcon talk
  2019-09-17  0:42 ` G. Branden Robinson
@ 2019-09-17  2:02   ` George Michaelson
  2019-09-17 11:01   ` Thomas Paulsen
  1 sibling, 0 replies; 10+ messages in thread
From: George Michaelson @ 2019-09-17  2:02 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

I also went vim, wanting nvi to be there but Keith Bostic lost impetus
or motivation. I am not in love with vim, I still feel like its got a
lot of glitter, but with the keystrokes for homekeys burned into my
brain it was the best choice. I use ed periodically to remind myself
what reductionism in editors means. I used atom and visual basic,
they're ok for what they are.

Vim also gave me syntax colouring. again, I was suprised how quickly I
came to use it, having decried it. I guess like food, in matters of
(editor) taste there is no good disputation.

Sam didn't get into my frontal lobes quickly enough. I think if 8th
and plan9 had been only TWO years earlier out the door, a lot of the
world would look different. I look at kubernetes now, I live in it
actually, and I feel like inferno was leading me there but I got there
via very twisty paths.

Really, what I think UNIX missed the most, was the plumber. GTK and
KDE and the like dance around the problem of cut-paste between
processes in ways which I am led to believe the plumber fixed long
ago.  Another thing which had it been only two years earlier, might
have got us to a more cohered space.

"first, kill all the lawyers" is probably the subtitle of a UNIX book.
Counterfactuals.

-G

On Tue, Sep 17, 2019 at 10:42 AM G. Branden Robinson
<g.branden.robinson@gmail.com> wrote:
>
> At 2019-09-16T20:20:32-0400, Doug McIlroy wrote:
> > Ed imposes a structure, making a (finite) file into an array, aka
> > list, of lines. It's easy to define block moves and copies in a list.
> > But what are the semantics of a block move, wherein one treats the
> > list as a ragged-right 2D array? What gets pushed aside? In what
> > direction?  How does a block move into column that not all destination
> > rows reach? How do you cope when the bottom gets ragged? How about the
> > top? Can one move blocks of tab-separated fields?
> >
> > I think everyone has rued the lack of block operations at one time or
> > another. But implementing them in any degree of generality is a
> > stumbling block. What should the semantics be?
>
> Just in case anyone didn't know, Vim has what it calls "visual block"
> highlighting and operations.  CTRL-V begins one and you use the usual
> movement keys to shape and size it, then an operator like (y)ank or
> (d)elete.
>
> It won't always work as one expects because of the very questions that
> Doug raises above.
>
> Vim also has characterwise blocks (begin with 'v') and linewise blocks
> (begin with 'V').
>
> The last is, more than any other single factor, what pulled me over from
> traditional vi (really nvi in my case).  It was a big win over
> line-counting with ":.,+n" expressions.  In retrospect I should have
> been smarter and just typed ":.,/pattern/", using as /pattern/ some
> short string that did not appear in any of the lines I wanted to operate
> on.
>
> Though the vi clone with the best name was, indisputably, elvis.
>
> Regards,
> Branden

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [TUHS] block operations in editors, was My EuroBSDcon talk
  2019-09-17  0:20 Doug McIlroy
  2019-09-17  0:42 ` G. Branden Robinson
@ 2019-09-17  1:25 ` Bakul Shah
  1 sibling, 0 replies; 10+ messages in thread
From: Bakul Shah @ 2019-09-17  1:25 UTC (permalink / raw)
  To: Doug McIlroy; +Cc: tuhs

On Mon, 16 Sep 2019 20:20:32 -0400 Doug McIlroy <doug@cs.dartmouth.edu> wrote:
Doug McIlroy writes:
> > The "block copy in an editor" thing is something which has intrigued
> > me for years. poor old ed/ex/vi just couldn't do it, and for the life
> > of me, I could not understand why this was "deprecated" by the people
> > writing that family of editors.
>
> One might trace it to the founding tenet that a file is a stream of bytes,
> reinforced by the absence of multidemensional arrays in C. But it goes
> deeper than that.
>
> Ed imposes a structure, making a (finite) file into an array, aka list,
> of lines. It's easy to define block moves and copies in a list. But
> what are the semantics of a block move, wherein one treats the list
> as a ragged-right 2D array? What gets pushed aside? In what direction?
> How does a block move into column that not all destination rows
> reach? How do you cope when the bottom gets ragged? How about the
> top? Can one move blocks of tab-separated fields?
>
> I think everyone has rued the lack of block operations at one time
> or another. But implementing them in any degree of generality is a
> stumbling block. What should the semantics be?

The Rand editor e handled all this reasonably well.

A file was treated as a virtual quarter plane, with 0,0 as
the start of the file (you could move a cursor anywhere
including a non-existant line or column.  Extra blanks or
lines were added only if you actually typed something there).

In the command line (like vi's exmode) for many commands you
can specify an area of operation which can be n lines, n
paragraphs or a rectangle, starting at the cursor position. Or
you can select a rectangular area with the "mark" command. If
you move the cursor straight down, N lines would be chosen.
To pick nx1 rectangle, you move cursor right one place after
marking.

open would open up a blank area,  pushing text left as
necessary.  close would close up an area, pushing text right
if necessary. erase would blank out an area (erase text but
leave text outside alone). run command replaced the contents
with the output of a shell command. feed was like run except
it kept the original and inserted new data at the cursor.

Tabs were not separators but stood for specific columns.  By
default every 8 columns but you could change them to whatever.
picking a rectangle handled them appropriately.  IIRC.  You
stored non standard tab positions in a separate file.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [TUHS] block operations in editors, was  My EuroBSDcon talk
  2019-09-17  0:20 Doug McIlroy
@ 2019-09-17  0:42 ` G. Branden Robinson
  2019-09-17  2:02   ` George Michaelson
  2019-09-17 11:01   ` Thomas Paulsen
  2019-09-17  1:25 ` Bakul Shah
  1 sibling, 2 replies; 10+ messages in thread
From: G. Branden Robinson @ 2019-09-17  0:42 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]

At 2019-09-16T20:20:32-0400, Doug McIlroy wrote:
> Ed imposes a structure, making a (finite) file into an array, aka
> list, of lines. It's easy to define block moves and copies in a list.
> But what are the semantics of a block move, wherein one treats the
> list as a ragged-right 2D array? What gets pushed aside? In what
> direction?  How does a block move into column that not all destination
> rows reach? How do you cope when the bottom gets ragged? How about the
> top? Can one move blocks of tab-separated fields?
> 
> I think everyone has rued the lack of block operations at one time or
> another. But implementing them in any degree of generality is a
> stumbling block. What should the semantics be?

Just in case anyone didn't know, Vim has what it calls "visual block"
highlighting and operations.  CTRL-V begins one and you use the usual
movement keys to shape and size it, then an operator like (y)ank or
(d)elete.

It won't always work as one expects because of the very questions that
Doug raises above.

Vim also has characterwise blocks (begin with 'v') and linewise blocks
(begin with 'V').

The last is, more than any other single factor, what pulled me over from
traditional vi (really nvi in my case).  It was a big win over
line-counting with ":.,+n" expressions.  In retrospect I should have
been smarter and just typed ":.,/pattern/", using as /pattern/ some
short string that did not appear in any of the lines I wanted to operate
on.

Though the vi clone with the best name was, indisputably, elvis.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [TUHS] block operations in editors, was  My EuroBSDcon talk
@ 2019-09-17  0:20 Doug McIlroy
  2019-09-17  0:42 ` G. Branden Robinson
  2019-09-17  1:25 ` Bakul Shah
  0 siblings, 2 replies; 10+ messages in thread
From: Doug McIlroy @ 2019-09-17  0:20 UTC (permalink / raw)
  To: tuhs, ggm

> The "block copy in an editor" thing is something which has intrigued
> me for years. poor old ed/ex/vi just couldn't do it, and for the life
> of me, I could not understand why this was "deprecated" by the people
> writing that family of editors.

One might trace it to the founding tenet that a file is a stream of bytes,
reinforced by the absence of multidemensional arrays in C. But it goes
deeper than that.

Ed imposes a structure, making a (finite) file into an array, aka list,
of lines. It's easy to define block moves and copies in a list. But
what are the semantics of a block move, wherein one treats the list
as a ragged-right 2D array? What gets pushed aside? In what direction?
How does a block move into column that not all destination rows
reach? How do you cope when the bottom gets ragged? How about the
top? Can one move blocks of tab-separated fields?

I think everyone has rued the lack of block operations at one time
or another. But implementing them in any degree of generality is a
stumbling block. What should the semantics be?

> Similarly the 'repeat this sequence of commands' thing which emacs had.

Ed's g command does that, except the sequence can't contain another g.
Sam, barely harder than ed to learn, cures that deficiency and generalizes
in other ways, too--but has no block operations.

Doug

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2019-09-18  4:52 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-17 17:31 [TUHS] block operations in editors, was My EuroBSDcon talk Doug McIlroy
2019-09-18  4:47 ` Steve Johnson
2019-09-18  4:52   ` Jon Steinhart
  -- strict thread matches above, loose matches on Subject: below --
2019-09-17 15:36 Noel Chiappa
2019-09-17 11:34 Thomas Paulsen
2019-09-17  0:20 Doug McIlroy
2019-09-17  0:42 ` G. Branden Robinson
2019-09-17  2:02   ` George Michaelson
2019-09-17 11:01   ` Thomas Paulsen
2019-09-17  1:25 ` Bakul Shah

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).