Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.linux > #57099 > unrolled thread

I Have Found My Editor

Back to article view | Back to alt.os.linux

Contents

  I Have Found My Editor "F. Russell" <fr@random.info> - 2019-06-22 01:47 +0000
    Re: I Have Found My Editor Pedro Valdez <pedro1492@lycos.com> - 2019-06-22 04:31 -0700
      Re: I Have Found My Editor "Carlos E.R." <robin_listas@es.invalid> - 2019-06-22 14:04 +0200
      Re: I Have Found My Editor owl <owl@rooftop.invalid> - 2019-06-22 12:43 +0000
        Re: I Have Found My Editor owl <owl@rooftop.invalid> - 2019-06-22 12:50 +0000
      Re: I Have Found My Editor John Hasler <jhasler@newsguy.com> - 2019-06-22 07:21 -0500
        Re: I Have Found My Editor Yrrah <Yrrah-aol@aol.invalid> - 2019-06-22 15:29 +0200
          Re: I Have Found My Editor John Hasler <jhasler@newsguy.com> - 2019-06-22 10:16 -0500
      Re: I Have Found My Editor "F. Russell" <fr@random.info> - 2019-06-22 13:45 +0000
        Re: I Have Found My Editor owl <owl@rooftop.invalid> - 2019-06-22 14:00 +0000
          Re: I Have Found My Editor "F. Russell" <fr@random.info> - 2019-06-22 15:54 +0000
            Re: I Have Found My Editor owl <owl@rooftop.invalid> - 2019-06-22 16:08 +0000
              Re: I Have Found My Editor John Hasler <jhasler@newsguy.com> - 2019-06-22 11:37 -0500
                Re: I Have Found My Editor "Carlos E. R." <robin_listas@es.invalid> - 2019-06-22 23:21 +0200
                Re: I Have Found My Editor DecadentLinuxUserNumeroUno@decadence.org - 2019-06-23 14:44 +0000
                  Re: I Have Found My Editor owl <owl@rooftop.invalid> - 2019-06-23 19:44 +0000
            Re: I Have Found My Editor Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-23 17:47 +0200
          Re: I Have Found My Editor "F. Russell" <fr@random.info> - 2019-06-22 16:07 +0000
            Re: I Have Found My Editor owl <owl@rooftop.invalid> - 2019-06-22 16:33 +0000
              Re: I Have Found My Editor owl <owl@rooftop.invalid> - 2019-06-22 16:46 +0000
                Re: I Have Found My Editor "F. Russell" <fr@random.info> - 2019-06-22 18:18 +0000
                  Re: I Have Found My Editor owl <owl@rooftop.invalid> - 2019-06-22 20:13 +0000
                    Re: I Have Found My Editor "F. Russell" <fr@random.info> - 2019-06-23 11:03 +0000
                      Re: I Have Found My Editor Melzzzzz <Melzzzzz@zzzzz.com> - 2019-06-23 11:15 +0000
                        Re: I Have Found My Editor John Hasler <jhasler@newsguy.com> - 2019-06-23 10:05 -0500
                          Re: I Have Found My Editor DecadentLinuxUserNumeroUno@decadence.org - 2019-06-23 15:33 +0000
                            Re: I Have Found My Editor DecadentLinuxUserNumeroUno@decadence.org - 2019-06-23 15:34 +0000
                          Re: I Have Found My Editor owl <owl@rooftop.invalid> - 2019-06-23 15:53 +0000
                            Re: I Have Found My Editor Melzzzzz <Melzzzzz@zzzzz.com> - 2019-06-24 00:58 +0000
                              Re: I Have Found My Editor "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2019-06-23 21:33 -0400
                                Re: I Have Found My Editor William Unruh <unruh@invalid.ca> - 2019-06-24 07:35 +0000
                                  Re: I Have Found My Editor "Carlos E. R." <robin_listas@es.invalid> - 2019-06-24 11:45 +0200
                                  Re: I Have Found My Editor "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2019-06-24 07:45 -0400
                                  Re: I Have Found My Editor "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2019-06-24 08:34 -0400
                                  Re: I Have Found My Editor Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-24 14:37 +0200
                                    Re: I Have Found My Editor "Carlos E. R." <robin_listas@es.invalid> - 2019-06-24 15:09 +0200
                                    Re: I Have Found My Editor "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2019-06-24 09:46 -0400
                                      Re: I Have Found My Editor "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2019-06-24 12:26 -0400
                                        Re: I Have Found My Editor vallor <vallor@cultnix.org> - 2019-06-24 18:03 +0000
                                        Re: I Have Found My Editor "Carlos E.R." <robin_listas@es.invalid> - 2019-06-24 23:00 +0200
                                          Re: I Have Found My Editor "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2019-06-24 17:25 -0400
                                            Re: I Have Found My Editor owl <owl@rooftop.invalid> - 2019-06-25 16:42 +0000
                                        Re: I Have Found My Editor Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-25 01:07 +0200
                                          Re: I Have Found My Editor "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2019-06-25 04:15 -0400
                                            Re: I Have Found My Editor Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-25 13:23 +0200
                              Re: I Have Found My Editor RonB <ronb02NOSPAM@gmail.com> - 2019-06-24 04:28 +0000
                      Re: I Have Found My Editor owl <owl@rooftop.invalid> - 2019-06-23 14:03 +0000
                        Re: I Have Found My Editor Georges <georges@prout.com> - 2019-06-23 16:43 +0200
                      Re: I Have Found My Editor Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-23 17:54 +0200
                      Re: I Have Found My Editor Jasen Betts <jasen@xnet.co.nz> - 2019-06-24 09:18 +0000
                        Re: I Have Found My Editor "F. Russell" <fr@random.info> - 2019-06-24 10:30 +0000
                          Re: I Have Found My Editor "Carlos E. R." <robin_listas@es.invalid> - 2019-06-24 13:53 +0200
                            Re: I Have Found My Editor "F. Russell" <frussell@random.info> - 2019-06-24 12:49 +0000
                              Re: I Have Found My Editor "Carlos E. R." <robin_listas@es.invalid> - 2019-06-24 15:14 +0200
                              Re: I Have Found My Editor "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2019-06-24 09:52 -0400
                                Re: I Have Found My Editor "F. Russell" <frussell@random.info> - 2019-06-24 14:12 +0000
                                  Re: I Have Found My Editor "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2019-06-24 10:43 -0400
                  Re: I Have Found My Editor "Carlos E. R." <robin_listas@es.invalid> - 2019-06-22 23:27 +0200
        Re: I Have Found My Editor "Carlos E.R." <robin_listas@es.invalid> - 2019-06-22 16:30 +0200
          Re: I Have Found My Editor DecadentLinuxUserNumeroUno@decadence.org - 2019-06-22 14:59 +0000
        Re: I Have Found My Editor DecadentLinuxUserNumeroUno@decadence.org - 2019-06-22 14:54 +0000
      Re: I Have Found My Editor Melzzzzz <Melzzzzz@zzzzz.com> - 2019-06-22 20:51 +0000
    Re: I Have Found My Editor "Carlos E.R." <robin_listas@es.invalid> - 2019-06-22 14:17 +0200
      Re: I Have Found My Editor Yrrah <Yrrah-aol@aol.invalid> - 2019-06-22 14:50 +0200
        Re: I Have Found My Editor "Carlos E.R." <robin_listas@es.invalid> - 2019-06-22 15:55 +0200
          Re: I Have Found My Editor Yrrah <Yrrah-aol@aol.invalid> - 2019-06-22 17:43 +0200
    Re: I Have Found My Editor Melzzzzz <Melzzzzz@zzzzz.com> - 2019-06-22 20:54 +0000
      Re: I Have Found My Editor RonB <ronb02NOSPAM@gmail.com> - 2019-06-23 03:17 +0000
        Re: I Have Found My Editor Melzzzzz <Melzzzzz@zzzzz.com> - 2019-06-23 07:24 +0000
          Re: I Have Found My Editor RonB <ronb02NOSPAM@gmail.com> - 2019-06-23 16:46 +0000
            Re: I Have Found My Editor Melzzzzz <Melzzzzz@zzzzz.com> - 2019-06-24 00:56 +0000
              Re: I Have Found My Editor RonB <ronb02NOSPAM@gmail.com> - 2019-06-24 04:26 +0000
    Re: I Have Found My Editor Maurice <maurice@nomail.afraid.org> - 2019-06-23 10:56 +0000
    Re: I Have Found My Editor azigni <azigni@yahoo.com> - 2019-06-25 21:33 +0000
      Re: I Have Found My Editor "F. Russell" <fr@random.info> - 2019-06-26 01:32 +0000
        Re: I Have Found My Editor Aragorn <thorongil@telenet.be> - 2019-06-26 12:53 +0200
          Re: I Have Found My Editor "F. Russell" <frussell@random.info> - 2019-06-26 11:48 +0000
            Re: I Have Found My Editor Wildman <best_lay@yahoo.com> - 2019-06-26 07:39 -0500
              Re: I Have Found My Editor fr314159@gmail.com - 2019-06-26 05:51 -0700
            Re: I Have Found My Editor Aragorn <thorongil@telenet.be> - 2019-06-26 18:13 +0200
          Re: I Have Found My Editor Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-26 13:54 +0200
            Re: I Have Found My Editor Dan Purgert <dan@djph.net> - 2019-06-26 12:16 +0000
              Re: I Have Found My Editor Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-26 15:42 +0200
            Re: I Have Found My Editor Aragorn <thorongil@telenet.be> - 2019-06-26 18:18 +0200
              Re: I Have Found My Editor Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-26 21:07 +0200
          Re: I Have Found My Editor "F. Russell" <frussell@random.info> - 2019-06-26 12:26 +0000

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#57142

On Sat, 22 Jun 2019 16:46:10 +0000, owl wrote:

> 
> And of course, you could always do this...
> 

You are trying to shoehorn things that don't belong.

If you really wanted to mix columns with ordinary
text lines then you would need to employ some
"invisible" Unicode character as a special column
delimiter.  Although I don't recall specifically
the characters, a different kind of "space" could
work:

http://jkorpela.fi/chars/spaces.html

But again, this would be purely a local application.
If you wanted to distribute the files then you would
need to also distribute extra information that describes
the formatting as well as a BOM (byte order mark).

[toc] | [prev] | [next] | [standalone]

#57144

F. Russell <fr@random.info> wrote:
> On Sat, 22 Jun 2019 16:46:10 +0000, owl wrote:
> 
>> 
>> And of course, you could always do this...
>> 
> 
> You are trying to shoehorn things that don't belong.
> 

Nope.

> If you really wanted to mix columns with ordinary
> text lines then you would need to employ some
> "invisible" Unicode character as a special column
> delimiter.

Why would I need to do that?


>  Although I don't recall specifically
> the characters, a different kind of "space" could
> work:
> 
> http://jkorpela.fi/chars/spaces.html
> 
> But again, this would be purely a local application.
> If you wanted to distribute the files then you would
> need to also distribute extra information that describes
> the formatting as well as a BOM (byte order mark).
> 

You're wrong, as usual.  What matters is the application
that interprets the file.  A CSV file is just like any
other plain text file to a text editor, but feed it to
a database or spreadsheet application, and suddenly it's
columnar data.

anon@lowtide:~$ cat afile
1,dafaf,fdfasfdsafdsa,dafad
2,xx,pp,iii
3,ladfh,iifafd,dfaiee
anon@lowtide:~$ sqlite3 fabtarddb
SQLite version 3.8.7.1 2014-10-29 13:59:56
Enter ".help" for usage hints.
sqlite> create table blah(id int,c1 text,c2 text,c3 text);
sqlite> .mode csv
sqlite> .import afile blah
sqlite> .mode columns
sqlite> .output data
sqlite> select * from blah;
sqlite> .quit
anon@lowtide:~$ cat data
1           dafaf       fdfasfdsafdsa  dafad     
2           xx          pp             iii       
3           ladfh       iifafd         dfaiee    
anon@lowtide:~$

[toc] | [prev] | [next] | [standalone]

#57165

On Sat, 22 Jun 2019 20:13:15 +0000, owl wrote:

> 
> You're wrong, as usual.  What matters is the application
> that interprets the file.  A CSV file is just like any
> other plain text file to a text editor, but feed it to
> a database or spreadsheet application, and suddenly it's
> columnar data.
> 

A CSV file does not contain COLUMNS.  A CSV file contains FIELDS.
The is a BIG difference between a COLUMN and a FIELD.

In a column, the text "flow" is down one column from top to bottom
and then a jump to the top of the next column and so on.  This CANNOT
be made to happen in a text file.  A text file CANNOT have columns.

In conclusion, the concept of a column does not exist in a text file.
A text file contains only LINES.

[toc] | [prev] | [next] | [standalone]

#57167

On 2019-06-23, F. Russell <fr@random.info> wrote:
> On Sat, 22 Jun 2019 20:13:15 +0000, owl wrote:
>
>> 
>> You're wrong, as usual.  What matters is the application
>> that interprets the file.  A CSV file is just like any
>> other plain text file to a text editor, but feed it to
>> a database or spreadsheet application, and suddenly it's
>> columnar data.
>> 
>
> A CSV file does not contain COLUMNS.  A CSV file contains FIELDS.
> The is a BIG difference between a COLUMN and a FIELD.

Field is synonim for column...

>


-- 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi 
bili naoruzani. -- Mladen Gogala

[toc] | [prev] | [next] | [standalone]

#57176

Melzzzzz writes:
> Field is synonim for column...

No it isn't.
-- 
John Hasler 
jhasler@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#57178

John Hasler <jhasler@newsguy.com> wrote in 
news:877e9cpckj.fsf@dhh.gt.org:

> Melzzzzz writes:
>> Field is synonim for column...
> 
> No it isn't.

  Since my spreadsheet app is formatted at the pixel level and so are 
its print jobs, I actually could easily make an array that matches a 
MONO-spaced text array, and format each cell right down to the pixel 
level placement in the print job, much less all aspects of formatting 
each word...  hell, each character in each word, in its own spearate 
'space'.

  'Field' refers to a database term where a text area is provided where 
the user fills in data on a user input form or 'reads' already stored 
data on a user display form.  These are terms typically related to a 
graphical workspace and there would be no "columns" per se, even if the 
developer lined 'fields' up vertically.

[toc] | [prev] | [next] | [standalone]

#57179

DecadentLinuxUserNumeroUno@decadence.org wrote in
news:qeo63h$nov$1@gioia.aioe.org: 

> John Hasler <jhasler@newsguy.com> wrote in 
> news:877e9cpckj.fsf@dhh.gt.org:
> 
>> Melzzzzz writes:
>>> Field is synonim for column...
>> 
>> No it isn't.
> 
>   Since my spreadsheet app is formatted at the pixel level and so
>   are 
> its print jobs, I actually could easily make an array that matches
> a MONO-spaced text array, and format each cell right down to the
> pixel level placement in the print job, much less all aspects of
> formatting each word...  hell, each character in each word, in its
> own spearate 'space'.
> 
>   'Field' refers to a database term where a text area is provided
>   where 
> the user fills in data on a user input form or 'reads' already
> stored data on a user display form.  These are terms typically
> related to a graphical workspace and there would be no "columns"
> per se, even if the developer lined 'fields' up vertically.
> 

  Sorry... I should have put the latter paragraph first.  Not that 
it really matters.

[toc] | [prev] | [next] | [standalone]

#57181

John Hasler <jhasler@newsguy.com> wrote:
> Melzzzzz writes:
>> Field is synonim for column...
> 
> No it isn't.

The difference is not rigid.  Sometimes it's a matter of semantics.
Sometimes it's just a preference of terminology.

anon@lowtide:~$ csvtool --help |grep field|wc -l
0
anon@lowtide:~$ csvtool --help |grep column|wc -l
29
anon@lowtide:~$

anon@lowtide:~$ man awk |grep field |wc -l
55
anon@lowtide:~$ man awk |grep column |wc -l
0
anon@lowtide:~$

[toc] | [prev] | [next] | [standalone]

#57196

On 2019-06-23, owl <owl@rooftop.invalid> wrote:
> John Hasler <jhasler@newsguy.com> wrote:
>> Melzzzzz writes:
>>> Field is synonim for column...
>> 
>> No it isn't.
>
> The difference is not rigid.  Sometimes it's a matter of semantics.
> Sometimes it's just a preference of terminology.

In database terms, field is column. You can call it either
way. Table has rows and columns.

>
> anon@lowtide:~$ csvtool --help |grep field|wc -l
> 0
> anon@lowtide:~$ csvtool --help |grep column|wc -l
> 29
> anon@lowtide:~$
>
> anon@lowtide:~$ man awk |grep field |wc -l
> 55
> anon@lowtide:~$ man awk |grep column |wc -l
> 0
> anon@lowtide:~$
>


-- 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi 
bili naoruzani. -- Mladen Gogala

[toc] | [prev] | [next] | [standalone]

#57197

On Sun, 23 Jun 2019 20:58:54 -0400, Melzzzzz <Melzzzzz@zzzzz.com> wrote:
> In database terms, field is column. You can call it either
> way. Table has rows and columns.

Agreed. Text terminals use rows and columns to define locations where
characters are shown, so the statement that text cannot contain columns
is patently false. Before the usage of database software, tables were
normally stored as text files. The fields (aka columns) could be defined
by the column location (start/length or start/end), or by separator
characters such as spaces, tabs, or various forms of quotes.

For an example of a table stored in a text file on all linux systems,
just look at /etc/passwd. It's a text file, containing a table using
the character : as a field/column separator.

In this case the word column has double meaning. For example, column 3
may refer to the third character of each line, or it refer to all of the
UIDs stored in that file.

A table can also be stored as a simple string. For example ...
$ cat bin/weekday
#!/bin/bash
DayTable="Sun Mon Tue Wed Thu Fri Sat"
let ColStart="4 * $1"
DayAbbr=${DayTable:$ColStart:3}
printf '%s\n' $DayAbbr

The above script uses a table stored as a simple string. It assumes
weekdays with Sun=0, so running ...
$ bin/weekday 1
Mon

That's always been the normal way of creating tables in asm. Any higher
level language that has table support and where the compiler allows asm
output will show they use the same method for in core tables.

This is stuff I learned in my first programming course in grade 10 (1975).

Regards, Dave Hodgins

-- 
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

[toc] | [prev] | [next] | [standalone]

#57207

On 2019-06-24, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
> On Sun, 23 Jun 2019 20:58:54 -0400, Melzzzzz <Melzzzzz@zzzzz.com> wrote:
>> In database terms, field is column. You can call it either
>> way. Table has rows and columns.
>
> Agreed. Text terminals use rows and columns to define locations where

And if a field is white space delimited, then "field" is a pretty
useless concept to use for text. In a database usually :fields" have a
given content-- numbers, text (which could have lots of words) lins,
etc. 
Columns for text usually means individual letters in a line. Again
useless if what you want to handle are words.

> characters are shown, so the statement that text cannot contain columns
> is patently false. Before the usage of database software, tables were

Depends on what you mean by columns. 

> normally stored as text files. The fields (aka columns) could be defined

If by "fields" you mean individual words, then some rows have 20 columes
some 3. Is that useful?

> by the column location (start/length or start/end), or by separator
> characters such as spaces, tabs, or various forms of quotes.
>
> For an example of a table stored in a text file on all linux systems,
> just look at /etc/passwd. It's a text file, containing a table using
> the character : as a field/column separator.

Yes, the password database has colums of fields, separated by colons. It
is certainly a useful concept for that. But this particular newsnet post
the conceept of column is pretty useless.

>
> In this case the word column has double meaning. For example, column 3
> may refer to the third character of each line, or it refer to all of the
> UIDs stored in that file.
>
> A table can also be stored as a simple string. For example ...
> $ cat bin/weekday
> #!/bin/bash
> DayTable="Sun Mon Tue Wed Thu Fri Sat"
> let ColStart="4 * $1"

Where "column" refers to "words" -- ie white space sparated. 

> DayAbbr=${DayTable:$ColStart:3}
> printf '%s\n' $DayAbbr
>
> The above script uses a table stored as a simple string. It assumes
> weekdays with Sun=0, so running ...
> $ bin/weekday 1
> Mon
>
> That's always been the normal way of creating tables in asm. Any higher
> level language that has table support and where the compiler allows asm
> output will show they use the same method for in core tables.
>
> This is stuff I learned in my first programming course in grade 10 (1975).

And perhaps concepts are more sophistacated than what youlearned in
grade school.

>
> Regards, Dave Hodgins
>

[toc] | [prev] | [next] | [standalone]

#57213

On 24/06/2019 09.35, William Unruh wrote:
> On 2019-06-24, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
>> On Sun, 23 Jun 2019 20:58:54 -0400, Melzzzzz <Melzzzzz@zzzzz.com> wrote:
>>> In database terms, field is column. You can call it either
>>> way. Table has rows and columns.
>>
>> Agreed. Text terminals use rows and columns to define locations where
> 
> And if a field is white space delimited, then "field" is a pretty
> useless concept to use for text. In a database usually :fields" have a
> given content-- numbers, text (which could have lots of words) lins,
> etc. 
> Columns for text usually means individual letters in a line. Again
> useless if what you want to handle are words.

You are being absurdly picky and stubborn. Most of us understand that we
can do fields and/or columns in text files, if *we* so wish.

-- 
Cheers,
       Carlos E.R.

[toc] | [prev] | [next] | [standalone]

#57217

On Mon, 24 Jun 2019 03:35:21 -0400, William Unruh <unruh@invalid.ca> wrote:
> And if a field is white space delimited, then "field" is a pretty
> useless concept to use for text. In a database usually :fields" have a
> given content-- numbers, text (which could have lots of words) lins,
> etc.
> Columns for text usually means individual letters in a line. Again
> useless if what you want to handle are words.
> And perhaps concepts are more sophistacated than what youlearned in
> grade school.

Have you ever heard of a book cipher? The book is a table, with individual
words identified by three subscripts. Page number, line number, word number.
That's a clear example of text being stored and used as a table. In this
case, a three dimensional table with a variable number for each value
depending on the book chosen.

While concepts do evolve, learning new concepts generally requires
understanding the old ones. The concepts behind tables have not changed,
just the methods for accessing and storing them.

Regards, Dave Hodgins

-- 
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

[toc] | [prev] | [next] | [standalone]

#57219

On Mon, 24 Jun 2019 03:35:21 -0400, William Unruh <unruh@invalid.ca> wrote:
> And if a field is white space delimited, then "field" is a pretty
> useless concept to use for text. In a database usually :fields" have a
> given content-- numbers, text (which could have lots of words) lins,
> etc.
> Columns for text usually means individual letters in a line. Again
> useless if what you want to handle are words.
> And perhaps concepts are more sophistacated than what youlearned in
> grade school.

Thinking a bit more about this, I think this problem you're having is
an expectation that with tables, each row must have the same number of
columns as every other row. That is not true.

A variable length table can have the number of rows vary depending on
the data loaded, the number of columns in each row vary, and the length
of each column vary.

And regarding databases, I used to teach database administration,
including normalization up to 6th normal form, when to denormalize,
the design and to what level, based on the application, as well as
optimization techniques for storing them in either relational (DB2)
databases, or hierarchical databases (IMS). That was back in the 80's
and 90's on IBM mainframes, but none of that has changed.

Regards, Dave Hodgins

-- 
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

[toc] | [prev] | [next] | [standalone]

#57220

On 24/06/2019 09:35, William Unruh wrote:
> On 2019-06-24, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
>> On Sun, 23 Jun 2019 20:58:54 -0400, Melzzzzz <Melzzzzz@zzzzz.com> wrote:
>>> In database terms, field is column. You can call it either
>>> way. Table has rows and columns.
>>
>> Agreed. Text terminals use rows and columns to define locations where
> 
> And if a field is white space delimited, then "field" is a pretty
> useless concept to use for text. In a database usually :fields" have a
> given content-- numbers, text (which could have lots of words) lins,
> etc.
> Columns for text usually means individual letters in a line. Again
> useless if what you want to handle are words.
> 
>> characters are shown, so the statement that text cannot contain columns
>> is patently false. Before the usage of database software, tables were
> 
> Depends on what you mean by columns.
> 
>> normally stored as text files. The fields (aka columns) could be defined
> 
> If by "fields" you mean individual words, then some rows have 20 columes
> some 3. Is that useful?

in that case the text is not structured as a valid table. A 
smart editor can support table-like structure when there is 
one, but surely cannot create it ex novo if there isn't


for the same reason the most basic (and useless) notion of 
column as a character, makes "sense" only if the file has 
rows all of the same size (maybe padded somewhat), but does 
not make sense in every text

> 
>> by the column location (start/length or start/end), or by separator
>> characters such as spaces, tabs, or various forms of quotes.
>>
>> For an example of a table stored in a text file on all linux systems,
>> just look at /etc/passwd. It's a text file, containing a table using
>> the character : as a field/column separator.
> 
> Yes, the password database has colums of fields, separated by colons. It
> is certainly a useful concept for that. But this particular newsnet post
> the conceept of column is pretty useless.

anyway a column must span all the file, from first to last 
row (at worst with empty fields), and this for each column. 
If it don't then the text is not table-like, and the column 
concept is no longer relevant

Maybe the concept of "logical" column and "physical" column 
could be distinguished. The first is broader, including 
fields of variable size (by separators or delimiters and a 
minimal synthax for correct parsing), the second is 
stricter, positional, and only can refer to fixed size 
tables. In a low level editor to make the first kind look 
like the (graceful) second kind, manual padding with 
"blanks" is required

> 
>>
>> In this case the word column has double meaning. For example, column 3
>> may refer to the third character of each line, or it refer to all of the
>> UIDs stored in that file.
>>
>> A table can also be stored as a simple string. For example ...
>> $ cat bin/weekday
>> #!/bin/bash
>> DayTable="Sun Mon Tue Wed Thu Fri Sat"
>> let ColStart="4 * $1"
> 
> Where "column" refers to "words" -- ie white space sparated.
> 
>> DayAbbr=${DayTable:$ColStart:3}
>> printf '%s\n' $DayAbbr
>>
>> The above script uses a table stored as a simple string. It assumes
>> weekdays with Sun=0, so running ...
>> $ bin/weekday 1
>> Mon
>>
>> That's always been the normal way of creating tables in asm. Any higher
>> level language that has table support and where the compiler allows asm
>> output will show they use the same method for in core tables.
>>
>> This is stuff I learned in my first programming course in grade 10 (1975).
> 
> And perhaps concepts are more sophistacated than what youlearned in
> grade school.

how old is one who attends grade 10 ?
(here we use different denomination for education)


> 
>>
>> Regards, Dave Hodgins
>>


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]

#57223

On 24/06/2019 14.37, Soviet_Mario wrote:
> On 24/06/2019 09:35, William Unruh wrote:


>>> by the column location (start/length or start/end), or by separator
>>> characters such as spaces, tabs, or various forms of quotes.
>>>
>>> For an example of a table stored in a text file on all linux systems,
>>> just look at /etc/passwd. It's a text file, containing a table using
>>> the character : as a field/column separator.
>>
>> Yes, the password database has colums of fields, separated by colons. It
>> is certainly a useful concept for that. But this particular newsnet post
>> the conceept of column is pretty useless.
> 
> anyway a column must span all the file, from first to last row (at worst
> with empty fields), and this for each column. If it don't then the text
> is not table-like, and the column concept is no longer relevant

I had a text editor in MsDOS which I don't remember the name - perhaps Q
- that handled columns on a section of the file, then a different number
of columns or none.

It used a comment that defined tab sizes for the section, IIRC and don't
confuse features of different editors. I understand that VI also uses
some kind of commands in the text that affects how it behaves, so this
is valid text editor feature.

-- 
Cheers,
       Carlos E.R.

[toc] | [prev] | [next] | [standalone]

#57225

On Mon, 24 Jun 2019 08:37:49 -0400, Soviet_Mario <SovietMario@cccp.mir> wrote:

> in that case the text is not structured as a valid table. A
> smart editor can support table-like structure when there is
> one, but surely cannot create it ex novo if there isn't

That is not correct. Two dimensional tables are defined as
having rows and columns. Tables with more dimensions use other
terms for the remaining dimensions. In the case of a book cipher,
the cipher uses three dimensions, page number, line number, and
word number. The line number and word number are also be called
the row and column.

The most complex table I ever dealt with in my working career had
12 dimensions. The program using it was written in PL/1, which can
support up to 15 dimensional tables. While working on that program,
I learned that the maximum length for a variable name in PL/1 is
30 characters, as I worked hard to keep everything readable and
understandable. PL/1 will accept longer name variables, but if used
the compiler will shorten the name by concatenating the first and last
15 characters, and print a warning that it has done so.

> for the same reason the most basic (and useless) notion of
> column as a character, makes "sense" only if the file has
> rows all of the same size (maybe padded somewhat), but does
> not make sense in every text

Ever write a program that works directly with the screen buffer? The
characters in a text terminal are addressed using row and column number.

> anyway a column must span all the file, from first to last
> row (at worst with empty fields), and this for each column.
> If it don't then the text is not table-like, and the column
> concept is no longer relevant

Just because you've never worked with a table where each row has a
variable number of columns, or tables that have more dimensions than just
rows and columns doesn't mean that they don't exist or aren't still tables.

> Maybe the concept of "logical" column and "physical" column
> could be distinguished. The first is broader, including
> fields of variable size (by separators or delimiters and a
> minimal synthax for correct parsing), the second is
> stricter, positional, and only can refer to fixed size
> tables. In a low level editor to make the first kind look
> like the (graceful) second kind, manual padding with
> "blanks" is required

You are adding restrictions to the definition of a table that only exist
in your mind, due to your limited experience.

> how old is one who attends grade 10 ?
> (here we use different denomination for education)

The school year here goes from Sept. to June. As my birthday is in Nov.,
I turned 15 during that school year.

The high school (grades 9 to 13) I attended had a Honeywell 100/5 mini
computer. I took two years of programming in Fortran and one in COBOL,
and taught myself the Honeywell asm and coded directly in machine code
too. Grade 13 included subjects such as function and relations which
included things like matrix (aka table) arithmetic, calculus, and
algebra.

I completed the 5 years of high school in 4 years, then went on to college
where I learned commodore BASIC, PL/1, RPG III and IBM 360 asm before
starting my co-op work experience where I learned, Mark IV, pc asm and
Basic, and other languages on the mainframe that I don't remember off hand
right now. College also included courses in things like data structures,
and linear algebra, as well at business basics such as accounting
marketing, human relations, etc. I also took typing in grade 9, as I
needed it due to my really bad handwriting skills. :-) Came in handy when
I had to learn how to use a card punch, and later a computer keyboard.

Regards, Dave Hodgins

-- 
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

[toc] | [prev] | [next] | [standalone]

#57230

On Mon, 24 Jun 2019 09:46:07 -0400, David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:

> On Mon, 24 Jun 2019 08:37:49 -0400, Soviet_Mario <SovietMario@cccp.mir> wrote:
>> anyway a column must span all the file, from first to last
>> row (at worst with empty fields), and this for each column.
>> If it don't then the text is not table-like, and the column
>> concept is no longer relevant

> Just because you've never worked with a table where each row has a
> variable number of columns, or tables that have more dimensions than just
> rows and columns doesn't mean that they don't exist or aren't still tables.

Just occurred to me. The expectation that the columns must exist is due
to the assumption that every row in the table must be able to be accessed
randomly.

Tables do not have to be able to be accessed randomly to be tables.

Using either a delimiter (as used in ascii text files), or a counter of
the number of characters in that row, at the beginning of each row (as
used in variable length ebcdic files) can be used to allow the table to
be processed sequentially.

If an in core table must be able to be accessed using random access for
the rows, then yes, space must be reserved to keep each row the same
length. If you're willing to give up using random access and only use
sequential access, then they do not have to be the same length.

You may not consider a table that can only be processed sequentially to
be a table, but courses in data structures do consider them to be tables.

An ascii text file is a table of variable length strings (which are single
dimension tables with just the column numbers for subscripts) delimited by
newline characters. While the rows cannot be accessed using random
addressing, the characters/columns within each row (line) can be.

A text file loaded into core, and searched line by line, column by column
for some purpose is still being processed as a table. It just has to be
searched sequentially, from the beginning every time it's searched.

Regards, Dave Hodgins

-- 
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

[toc] | [prev] | [next] | [standalone]

#57232

On Mon, 24 Jun 2019 12:26:15 -0400, David W. Hodgins wrote:

> On Mon, 24 Jun 2019 09:46:07 -0400, David W. Hodgins
> <dwhodgins@nomail.afraid.org> wrote:
> 
>> On Mon, 24 Jun 2019 08:37:49 -0400, Soviet_Mario <SovietMario@cccp.mir>
>> wrote:
>>> anyway a column must span all the file, from first to last row (at
>>> worst with empty fields), and this for each column.
>>> If it don't then the text is not table-like, and the column concept is
>>> no longer relevant
> 
>> Just because you've never worked with a table where each row has a
>> variable number of columns, or tables that have more dimensions than
>> just rows and columns doesn't mean that they don't exist or aren't
>> still tables.
> 
> Just occurred to me. The expectation that the columns must exist is due
> to the assumption that every row in the table must be able to be
> accessed randomly.
> 
> Tables do not have to be able to be accessed randomly to be tables.
> 
> Using either a delimiter (as used in ascii text files), or a counter of
> the number of characters in that row, at the beginning of each row (as
> used in variable length ebcdic files) can be used to allow the table to
> be processed sequentially.
> 
> If an in core table must be able to be accessed using random access for
> the rows, then yes, space must be reserved to keep each row the same
> length. If you're willing to give up using random access and only use
> sequential access, then they do not have to be the same length.
> 
> You may not consider a table that can only be processed sequentially to
> be a table, but courses in data structures do consider them to be
> tables.
> 
> An ascii text file is a table of variable length strings (which are
> single dimension tables with just the column numbers for subscripts)
> delimited by newline characters. While the rows cannot be accessed using
> random addressing, the characters/columns within each row (line) can be.
> 
> A text file loaded into core, and searched line by line, column by
> column for some purpose is still being processed as a table. It just has
> to be searched sequentially, from the beginning every time it's
> searched.
> 
> Regards, Dave Hodgins

Indeed, it is just so.

To use an example I used not too long ago:  classic Unix /etc/passwd is a 
plain text file that contains a table.

-- 
 -v

[toc] | [prev] | [next] | [standalone]

#57234

On 24/06/2019 18.26, David W. Hodgins wrote:
> On Mon, 24 Jun 2019 09:46:07 -0400, David W. Hodgins
> <dwhodgins@nomail.afraid.org> wrote:
> 
>> On Mon, 24 Jun 2019 08:37:49 -0400, Soviet_Mario
>> <SovietMario@cccp.mir> wrote:
>>> anyway a column must span all the file, from first to last
>>> row (at worst with empty fields), and this for each column.
>>> If it don't then the text is not table-like, and the column
>>> concept is no longer relevant
> 
>> Just because you've never worked with a table where each row has a
>> variable number of columns, or tables that have more dimensions than just
>> rows and columns doesn't mean that they don't exist or aren't still
>> tables.
> 
> Just occurred to me. The expectation that the columns must exist is due
> to the assumption that every row in the table must be able to be accessed
> randomly.
> 
> Tables do not have to be able to be accessed randomly to be tables.
> 
> Using either a delimiter (as used in ascii text files), or a counter of
> the number of characters in that row, at the beginning of each row (as
> used in variable length ebcdic files) can be used to allow the table to
> be processed sequentially.
> 
> If an in core table must be able to be accessed using random access for
> the rows, then yes, space must be reserved to keep each row the same
> length. If you're willing to give up using random access and only use
> sequential access, then they do not have to be the same length.

You can have random access by using an auxiliary index table. Indirect,
yes. And the index has to be kept. Or you can have a number of (fixed
size) columns at the beginning of each row indexing the variable length
column. Many tricks :-)



-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | alt.os.linux

csiph-web