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 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#57237

On Mon, 24 Jun 2019 17:00:08 -0400, Carlos E.R. <robin_listas@es.invalid> wrote:

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

Yes, indirect indexing of the row offsets from the start will work.
Having the column count at the beginning of each row doesn't help you
find the start of the 50th row. Either row lengths are consistent, or
random access (by for example row number) doesn't work.

Regards, Dave Hodgins

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

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

#57249

David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
> On Mon, 24 Jun 2019 17:00:08 -0400, Carlos E.R. <robin_listas@es.invalid> wrote:
> 
>> 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 :-)
> 
> Yes, indirect indexing of the row offsets from the start will work.
> Having the column count at the beginning of each row doesn't help you
> find the start of the 50th row. Either row lengths are consistent, or
> random access (by for example row number) doesn't work.
> 

The row lengths in the file itself need not be consistent.
You can pad your read buffer to provide random access.

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

#57238

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

what you are talking about I don't call tables, but rather 
"jagged array" (which only share the number of dimensions, 
2, with plain tables)

I understand the issue of selecting A SINGLE CELL by row, 
column coordinates, Nice

but what about selecting A COLUMN in an irregular jagged array ?
The implementation is subjective.
To add or not to add empty items ?
To generate an error if a column does not have a cell in row X ?
To me an editor that uses text in a 2D fashion must either 
work like a bios screen (a rectangular matrix of characters) 
or to work with column of same size (in fields).
A Jagged array makes inconsistent the selection of a column, 
in my opinion

I'm thinking to 1) select a column from table A, copy and 
paste it into table B ... we would not like to have results 
dependent on vertical padding or to just amass all the row 
in a shorter column
High level editors tend to use empty field as valid fields 
(in order to preserve the other index : the row)

with multi dimension (>2) tables), no native support exist : 
one has to declare a declarative synthax with separators' 
nesting, and mouse selection of "sections" of N-1 dimensions 
become impossible, and also possible only with more complex 
text commands.
I would not even call that an editor, but a text scripting 
language (or markup language where nesting is supported by 
synthax). XML too is such a framework, but the text does not 
appear in its ascii representation any longer







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

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

#57240

On Mon, 24 Jun 2019 19:07:41 -0400, Soviet_Mario <SovietMario@cccp.mir> wrote:

> what you are talking about I don't call tables, but rather
> "jagged array" (which only share the number of dimensions,
> 2, with plain tables)

You're definition of a table is fine for usage with a relational database
system such as db2, but is not correct for other table usages.

> I understand the issue of selecting A SINGLE CELL by row,
> column coordinates, Nice
> but what about selecting A COLUMN in an irregular jagged array ?
> The implementation is subjective.

That's a feature of sql, which is designed for usage with tables that
are part of a relational database.

Tables were in use in programs long before rational databases were
in use. In order to be able to be used in a rational database, tables
have a number of restrictions added to them. They must be simple tables.

The simple tables used in relational data base systems are not the only
tables used in programming. Limiting yourself to only using tables that
are suitable for use in db2 or other relational databases precludes you
 from learning how to properly use more complex tables.

How empty/missing items are handled in table processing is a feature
of the programming language being used, in combination with decisions
made by the programmer. In sql, missing entries are assumed to be empty.
It supports the isempty function, and will return not equal for any
comparison.

> A Jagged array makes inconsistent the selection of a column,
> in my opinion

The ability to select an entire column is a feature of sql. Tables
designed for use in programming languages such as cobol, pl/1, etc.,
do not have that feature. In those languages accessing an entire
column requires looping through each and every row in the table.
Deciding what to do with missing entries is up to the programmer.
With most programming languages, the program will terminate with
a subscript out of range error, an addressing error, or will return
invalid results if an empty/missing table entry is attempted to be
accessed.

> with multi dimension (>2) tables), no native support exist :

Correction. No sql access support exists, because sql only supports
simple tables.

As shown in https://www.tutorialgateway.org/multi-dimensional-array-in-c/
they are supported in programming languages with the table support.

And before you complain, an array is just another term for a table. :-)
In text books and most programming documentation, the terms are used
interchangeably, and have been since long before Dr. E. F. Codd
proposed the relational database model.

Complex tables can always be replaced with multiple simple tables,
using the process called normalization. The simple tables have the benefit
of being usable with sql. The complex tables have the benefit of much
simpler programming, as they do not have to implement the equivalent of an
sql join, or add the rest of the complexity of adding a database access
system, when that is not needed for the given application.

Regards, Dave Hodgins

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

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

#57243

On 25/06/2019 10:15, David W. Hodgins wrote:
> On Mon, 24 Jun 2019 19:07:41 -0400, Soviet_Mario 
> <SovietMario@cccp.mir> wrote:
> 
>> what you are talking about I don't call tables, but rather
>> "jagged array" (which only share the number of dimensions,
>> 2, with plain tables)
> 
> You're definition of a table is fine for usage with a 
> relational database
> system such as db2, but is not correct for other table usages.
> 
>> I understand the issue of selecting A SINGLE CELL by row,
>> column coordinates, Nice
>> but what about selecting A COLUMN in an irregular jagged 
>> array ?
>> The implementation is subjective.
> 
> That's a feature of sql, which is designed for usage with 
> tables that
> are part of a relational database.
> 
> Tables were in use in programs long before rational 
> databases were
> in use. In order to be able to be used in a rational 
> database, tables
> have a number of restrictions added to them. They must be 
> simple tables.
> 
> The simple tables used in relational data base systems are 
> not the only
> tables used in programming. Limiting yourself to only using 
> tables that
> are suitable for use in db2 or other relational databases 
> precludes you
> from learning how to properly use more complex tables.
> 
> How empty/missing items are handled in table processing is a 
> feature
> of the programming language being used, in combination with 
> decisions
> made by the programmer. In sql, missing entries are assumed 
> to be empty.
> It supports the isempty function, and will return not equal 
> for any
> comparison.
> 
>> A Jagged array makes inconsistent the selection of a column,
>> in my opinion
> 
> The ability to select an entire column is a feature of sql. 
> Tables
> designed for use in programming languages such as cobol, 
> pl/1, etc.,
> do not have that feature. In those languages accessing an 
> entire
> column requires looping through each and every row in the 
> table.
> Deciding what to do with missing entries is up to the 
> programmer.
> With most programming languages, the program will terminate 
> with
> a subscript out of range error, an addressing error, or will 
> return
> invalid results if an empty/missing table entry is attempted 
> to be
> accessed.
> 
>> with multi dimension (>2) tables), no native support exist :
> 
> Correction. No sql access support exists, because sql only 
> supports
> simple tables.
> 
> As shown in 
> https://www.tutorialgateway.org/multi-dimensional-array-in-c/
> they are supported in programming languages with the table 
> support.
> 
> And before you complain, an array is just another term for a 
> table. :-)
> In text books and most programming documentation, the terms 
> are used
> interchangeably, and have been since long before Dr. E. F. Codd
> proposed the relational database model.
> 
> Complex tables can always be replaced with multiple simple 
> tables,
> using the process called normalization. The simple tables 
> have the benefit
> of being usable with sql. The complex tables have the 
> benefit of much
> simpler programming, as they do not have to implement the 
> equivalent of an
> sql join, or add the rest of the complexity of adding a 
> database access
> system, when that is not needed for the given application.
> 
> Regards, Dave Hodgins
> 


all okay ... but I believed we were talking about ascii 
editors...

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

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

#57206

On 2019-06-24, Melzzzzz <Melzzzzz@zzzzz.com> wrote:
> 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.

For some reason I aways think of a field as being the instersection between a 
row and a colum, kind of like a cell in a spreadsheet. 

>> 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:~$
>>
>
>


-- 
The more I see of Windows, the more I like Linux.

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

#57172

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

Nope.  No difference.  But even if there were, I thought you said
text files can only contain LINES.  So now you're saying they can 
contain FIELDS too?

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

Oh really...
https://streamable.com/2j6hp


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

In conclusion, you don't know what you're talking about.

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

#57174

Le 23/06/2019 à 16:03, owl a écrit :
> 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.
>>
> 
> Nope.  No difference.  But even if there were, I thought you said
> text files can only contain LINES.  So now you're saying they can 
> contain FIELDS too?
> 
>> 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.
>>
> 
> Oh really...
> https://streamable.com/2j6hp
> 
> 
>> In conclusion, the concept of a column does not exist in a text file.
>> A text file contains only LINES.
>>
> 
> In conclusion, you don't know what you're talking about.
> 

Hi Owl ;)

- how the byte stream is "shown" depends on the application. That's for
sure.

- whatever the char to represent the semantic of a field/line separator,
only dedicated apps can deal with that semantic.

- in any cases a byte stream is nothing more than a byte stream, without
any other semantic ; only the apps you use or you write make this
semantic come to life.
for instance, how you use vi or awk with the same byte stream will
influence the presentation of that stream.

note : I like the way you present your tests... 'didn't know streamable ;)

-- 
()
/\

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

#57182

Il 23/06/19 13:03, F. Russell ha scritto:
> 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.

I partially agree : columns are a subset of rows made of fields.
This last could be made of rows with a variable number of 
fields (not only a variable size of each of them, which is 
more normal).
A column oriented text has simply to contain the same number 
of fields per each row (so the structure arises from correct 
number of "hidden" separator per row)

> 
> In a column, the text "flow" is down one column from top to bottom

my caret moves bidirectionally in every editor ...

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

it can, but only if the editor is smart enough to recognize 
them as such

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


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

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

#57211

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

That typesetting meaning is not the only meaning of column.  For example,
in the context of databases it has a completely different meaning.

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

It could be argued that CSV is a binary format, so I'll let that slide.

-- 
  When I tried casting out nines I made a hash of it.

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

#57216

On Mon, 24 Jun 2019 09:18:40 +0000, Jasen Betts wrote:

> 
> That typesetting meaning is not the only meaning of column.  For example,
> in the context of databases it has a completely different meaning.
> 

We are not discussing databases.  We are discussing text files.

In a database a column is an established unit of the file format.
Likewise for a binary word processing file.

But no such unit exists for a text file format.

For the sale of convenience, most text file editors have some
method of selecting "columns" of text, but this selection can
be applied to any rectangular area of the display grid and
not just to what would be recognized as a column.

> 
> It could be argued that CSV is a binary format
>

There is only a single file type and that is binary.
All files are binary.

However, we usually refer to files where the binary
data is human readable (i.e. organized character info) as being
text files.

This would exclude types like XML which are human readable
but whose primary intention is not to be human readable.
The purpose of such "mark up" files is to be parsed by
digital machines.

So a text file must contain binary data that is specifically
intended to be parsed (i.e. read) by humans.

Certain configuration files contain data that is intended
both to be human readable and machine parsable.  CSV files
would also be found here.

Traditionally, text data was considered to be data bytes
with the MSB = 0, i.e. ASCII.  But post-Unicode that is no
longer valid.

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

#57218

On 24/06/2019 12.30, F. Russell wrote:
> On Mon, 24 Jun 2019 09:18:40 +0000, Jasen Betts wrote:


>> It could be argued that CSV is a binary format
>>
> 
> There is only a single file type and that is binary.
> All files are binary.
> 
> However, we usually refer to files where the binary
> data is human readable (i.e. organized character info) as being
> text files.
> 
> This would exclude types like XML which are human readable
> but whose primary intention is not to be human readable.
> The purpose of such "mark up" files is to be parsed by
> digital machines.
> 
> So a text file must contain binary data that is specifically
> intended to be parsed (i.e. read) by humans.
> 
> Certain configuration files contain data that is intended
> both to be human readable and machine parsable.  CSV files
> would also be found here.
> 
> Traditionally, text data was considered to be data bytes
> with the MSB = 0, i.e. ASCII.  But post-Unicode that is no
> longer valid.


I remember a series of programs that would read and save numerical data
in binary format, but could instead save the same data as text, in some
form of csv. The binary format was very fast to load, the text file was
slow because it had to be parsed (I know this for sure, I was the
programmer). But the text file had some advantages: it could be read by
humans, possibly reused for other applications, and possibly can be read
a century in the future with a different CPU. The reason being, the
binary numeric format was in fact a memory dump of each number, so
dependent on the actual representation of a number in the CPU, and
possibly dependent on the math library used. But the text file numeric
"format" is a human readable format with no limits on number of
decimals, exponents, significant digits, etc.



-- 
Cheers,
       Carlos E.R.

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

#57221

On Mon, 24 Jun 2019 13:53:10 +0200, Carlos E. R. wrote:> 

> I remember a series of programs that would read and save numerical data
> in binary format, but could instead save the same data as text, in some
> form of csv. The binary format was very fast to load, the text file was
> slow because it had to be parsed
>

There is a serious problem with storing numeric data as text.  The number
of digits written has to be sufficient to restore the original binary data.
For single precision, this is 9 digits.  For double precision this is, IIRC,
15-16 digits.  Yet some programs will output less than the sufficient number of
digits.

https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html#1251


>
> possibly reused for other applications, and possibly can be read
> a century in the future with a different CPU. The reason being, the
> binary numeric format was in fact a memory dump of each number, so
> dependent on the actual representation of a number in the CPU, and
> possibly dependent on the math library used.
>

That USED to be a serious issue, but the IEEE1985 standard was designed
to make numeric data the same everywhere.  There is no problem any more.


>
> But the text file numeric
> "format" is a human readable format with no limits on number of
> decimals, exponents, significant digits, etc.
>

The "text" format actually is obsolete.  POSIX systems, and that includes
GNU/Linux, no longer distinguish between text and binary.

But ISO C still includes specifications for opening/closing and reading/
writing files in text mode:

https://www.gnu.org/software/libc/manual/html_node/Binary-Streams.html

To me, the "text" format is non-existent, but one must still accord
a special status to LINES of human-readable data that are terminated/separated
by an EOL character.

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

#57224

On 24/06/2019 14.49, F. Russell wrote:
> On Mon, 24 Jun 2019 13:53:10 +0200, Carlos E. R. wrote:> 
> 
>> I remember a series of programs that would read and save numerical data
>> in binary format, but could instead save the same data as text, in some
>> form of csv. The binary format was very fast to load, the text file was
>> slow because it had to be parsed
>>
> 
> There is a serious problem with storing numeric data as text.  The number
> of digits written has to be sufficient to restore the original binary data.
> For single precision, this is 9 digits.  For double precision this is, IIRC,
> 15-16 digits.  Yet some programs will output less than the sufficient number of
> digits.

Well, this program wrote all digits.

> 
> https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html#1251
> 
> 
>>
>> possibly reused for other applications, and possibly can be read
>> a century in the future with a different CPU. The reason being, the
>> binary numeric format was in fact a memory dump of each number, so
>> dependent on the actual representation of a number in the CPU, and
>> possibly dependent on the math library used.
>>
> 
> That USED to be a serious issue, but the IEEE1985 standard was designed
> to make numeric data the same everywhere.  There is no problem any more.

Maybe. I'm not sure.

We had number standards back them. The CPU coprocessors used number
formats defined by the IEEE as well, yet I had problems across different
languages with importing numbers.



>> But the text file numeric
>> "format" is a human readable format with no limits on number of
>> decimals, exponents, significant digits, etc.
>>
> 
> The "text" format actually is obsolete.  POSIX systems, and that includes
> GNU/Linux, no longer distinguish between text and binary.
> 
> But ISO C still includes specifications for opening/closing and reading/
> writing files in text mode:
> 
> https://www.gnu.org/software/libc/manual/html_node/Binary-Streams.html
> 
> To me, the "text" format is non-existent, but one must still accord
> a special status to LINES of human-readable data that are terminated/separated
> by an EOL character.
> 


-- 
Cheers,
       Carlos E.R.

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

#57226

On Mon, 24 Jun 2019 08:49:25 -0400, F. Russell <frussell@random.info> wrote:

> There is a serious problem with storing numeric data as text.  The number
> of digits written has to be sufficient to restore the original binary data.
> For single precision, this is 9 digits.  For double precision this is, IIRC,
> 15-16 digits.  Yet some programs will output less than the sufficient number of
> digits.

You're limiting your views based on your experience with PCs using C or
similar languages. PL/1 on IBM mainframes supported 15 digit decimal
numbers back in the early 80's. Just because some programs will not
print all of the digits doesn't mean they can't be used in other programs
or languages.

Regards, Dave Hodgins

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

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

#57228

On Mon, 24 Jun 2019 09:52:28 -0400, David W. Hodgins wrote:

> 
> You're limiting your views based on your experience with PCs using C or
> similar languages. PL/1 on IBM mainframes supported 15 digit decimal
> numbers back in the early 80's. Just because some programs will not
> print all of the digits doesn't mean they can't be used in other programs
> or languages.
> 

The actual computer or programming language make NO difference.

From a purely mathematical point of view, if a BINARY double floating
point number is to be written as decimal digits then at least SEVENTEEN
(17) digits must be written to ensure that the original BINARY number
is restored.  This is unassailable mathematical FACT.

I stress here the BINARY representation.

The future trend will be to employ DECIMAL, or base 10, floating
point hardware and then this issue will no longer exist.

But at present, with the exception of IBM Power processors, floating
point hardware is BINARY, or base 2, representation.

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

#57229

On Mon, 24 Jun 2019 10:12:54 -0400, F. Russell <frussell@random.info> wrote:

> But at present, with the exception of IBM Power processors, floating
> point hardware is BINARY, or base 2, representation.

I wasn't discussing hardware implementations only and PC hardware isn't
the only hardware out there. The limitations imposed by the floating
point processor in intel and amd hardware do not apply to software
implementations of floating point processing.

For an example dealing with larger than 15 digit decimal numbers, see
https://www.codeproject.com/Articles/2728/C-BigInteger-Class#References

The FPU exists to speed up processing, as floating point arithmetic is
very cpu intensive on decimal only processing hardware, which IBM
mainframes back in the 80's and 90's were. The programming languages
supported floating point, but it was entirely implemented in software.

Regards, Dave Hodgins

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

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

#57148

On 22/06/2019 20.18, F. Russell 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.
> 
> 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.  

Not necesarily. It could be tabs. Some editors used comment lines to
define the tabs arbitrarily:

#---!--------------!---------------!----------------------------!

then the file can be rendered with spaces as appropriate.

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

Not at all. The file displays perfectly, using fixed font as usual on
such files and editors. As they display here in our nntp readers.

-- 
Cheers,
       Carlos E.R.

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

#57128

On 22/06/2019 15.45, F. Russell wrote:
> On Sat, 22 Jun 2019 04:31:34 -0700, Pedro Valdez wrote:
> 
>> I would like to see an editor that does find&replace only in certain columns.
>> I don't know any FOSS editor that does so.
>>
> 
> The concept of a "column" does not apply to a text file.
> 
> Therefore, find & replace tools for "columns" would very
> understandably not be available.
> 

The output of:

lsblk --output
NAME,KNAME,RA,RM,RO,SIZE,TYPE,FSTYPE,LABEL,PARTLABEL,MOUNTPOINT,UUID,PARTUUID,WWN,MODEL,ALIGNMENT
| less -S

(one line)

is formatted in columns.

Same for this command:

rpm -q -a --queryformat "%{INSTALLTIME}\t%{INSTALLTIME:day} \
   %{BUILDTIME:day} %-30{NAME}\t%15{VERSION}-%-7{RELEASE}\t%{arch} \
   %25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}\n" \
  | sort | cut --fields="2-" | tee rpmlist | less -S


There are many commands which output in columns, and I may want to do
things on them.

-- 
Cheers, Carlos.

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

#57130

"Carlos E.R." <robin_listas@es.invalid> wrote in
news:nlq1uf-iki.ln1@Telcontar.valinor: 

> On 22/06/2019 15.45, F. Russell wrote:
>> On Sat, 22 Jun 2019 04:31:34 -0700, Pedro Valdez wrote:
>> 
>>> I would like to see an editor that does find&replace only in
>>> certain columns. I don't know any FOSS editor that does so.
>>>
>> 
>> The concept of a "column" does not apply to a text file.
>> 
>> Therefore, find & replace tools for "columns" would very
>> understandably not be available.
>> 
> 
> The output of:
> 
> lsblk --output
> NAME,KNAME,RA,RM,RO,SIZE,TYPE,FSTYPE,LABEL,PARTLABEL,MOUNTPOINT,UU
I
> D,PARTUUID,WWN,MODEL,ALIGNMENT 
>| less -S
> 
> (one line)
> 
> is formatted in columns.
> 
> Same for this command:
> 
> rpm -q -a --queryformat "%{INSTALLTIME}\t%{INSTALLTIME:day} \
>    %{BUILDTIME:day} %-30{NAME}\t%15{VERSION}-%-7{RELEASE}\t%{arch}
>    \ %25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}\n" \
>  | sort | cut --fields="2-" | tee rpmlist | less -S
> 
> 
> There are many commands which output in columns, and I may want to
> do things on them.
> 

Even 'Marek Novotny's' Linfo.sh has columnar formatting in its 
output (the volume query results), though those results may have 
been formatted columnar by the utility called to produce them.

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

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

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

csiph-web