Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

[...]

> It was Phil Carmody [...] who insinuated that "octoctal" is a
> neo-Nazi dogwhistle.

I think it's important to distinguish between saying a particular
word is /heard/ by some (or many) people as a dogwhistle, and
saying that a given speaker who used the word /intended to give/
a dogwhistle.

I don't know what Phil was thinking when he made his comment, but
I think we shouldn't assume he meant one of these alternatives
when he may have meant only the other.

Phil Carmody <pc+usenet@asdf.org> writes:

> David Brown <david.brown@hesbynett.no> writes:
>
>> I think Phil's insinuations are too far-fetched and obscured to be
>> particularly offensive - perhaps he was trying to mock the daftest of
>> conspiracy theorists for some reason. It made as much sense as if
>> he'd suggested "octoctal" was a reference to two fat ladies.
>
> You get it.
>
> And there was no accusation of any individual. I was making a comment
> about an intrinsic property of a sequence of characters, nothing more.

I understand (at least I think I do) the point you're trying to
make, and I think the point is an important one to make.

However, I feel obliged to point out that the property here is
not intrinsic to a sequence of characters, but depends on who the
recipients are. It is a question of fact, but the facts depend
on who the listeners are as well as on what words are used.

Phil Carmody <pc+usenet@asdf.org> writes:

> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Apparently "octoctal" is an extremely obscure term for an encoding that
>> is almost universally called base64. Did you seriously expect your
>> readers to know that, or were you just trying to appear clever at the
>> expense of actually communicating?
>
> It's also a handy dogwhistle. I'm sure the ADL would take great
> offence. Explanation in the headers, but treat it as a puzzle and
> you should be able to work it out pretty quickly, in particular
> if you already know who the ADL are.

Have you read what the ADL has to say about the actual number 88 and
non-white supremacist contexts? You're mistaking tinnitis for the sound
of a dog whistle.

On 1/29/2023 9:57 PM, Joe Pfeiffer wrote:
> Phil Carmody <pc+usenet@asdf.org> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> Apparently "octoctal" is an extremely obscure term for an encoding that
>>> is almost universally called base64. Did you seriously expect your
>>> readers to know that, or were you just trying to appear clever at the
>>> expense of actually communicating?
>>
>> It's also a handy dogwhistle. I'm sure the ADL would take great
>> offence. Explanation in the headers, but treat it as a puzzle and
>> you should be able to work it out pretty quickly, in particular
>> if you already know who the ADL are.
>
> Have you read what the ADL has to say about the actual number 88 and
> non-white supremacist contexts? You're mistaking tinnitis for the sound
> of a dog whistle.

Interestingly, I had not heard of this usage until it came up in this
thread...

But, yeah, numbers like this can come up in lots of other contexts
purely by chance.

Well, and sometimes there is also the possibly fuzzy line between what
is antisemitism, and what is self-deprecating humor, ... In some sense,
context would need to be considered as well to try to determine the
intended effect.

But, there is always also the possibility of people taking offense at
things that were not intended to cause offense. Well, just as there is
the possibility of those with hostile intentions trying to downplay it
as an "innocent joke".

And, for someone whose status is more ambiguous, it can be awkward as
well (both in terms of concern of hostility from those who dislike the
group, and the paranoia that things they say could be taken as offensive
by those who view them as an outsider, so alas...).

On 22/01/2023 19:59, fir wrote:
> when i work with text files i read it into ram then work on it...

Not all text files are small. I've had to work on files many gigabytes
in size, and it can be hard to read the whole file in memory.

It also means that the IO has to happen first (reading the file) then
the processing can being only after the entire file has been read.

If you have a decent operating system - and that's most of them these
days - when you read a few bytes out of a file it will pre-buffer
several kB in advance so the next read is out of the cache.

Processing a large file as you read it can be many times faster than
reading it in, then processing it. Even if it fits in your RAM.

Andy

On Friday, 3 February 2023 at 20:41:39 UTC, Vir Campestris wrote:
> On 22/01/2023 19:59, fir wrote:
> > when i work with text files i read it into ram then work on it...
>
> Not all text files are small. I've had to work on files many gigabytes
> in size, and it can be hard to read the whole file in memory.
>
> It also means that the IO has to happen first (reading the file) then
> the processing can being only after the entire file has been read.
>
> If you have a decent operating system - and that's most of them these
> days - when you read a few bytes out of a file it will pre-buffer
> several kB in advance so the next read is out of the cache.
>
> Processing a large file as you read it can be many times faster than
> reading it in, then processing it. Even if it fits in your RAM.
>
> Andy

I wouldn't exactly call such a file a text file, which implies something that is human readable.

Most text files I read are source files, and an upper limit for normal files (not specially created tests) is 0.1MB. So I could have 40,000 such maximum files load at the same time on my 8GB machine with little problem.

It would be silly then to process such files via a tiny read buffer, so that you'd have to keep checking for end-of-buffer for each character even in the middle of a token.

(If somebody had told me 40 years ago that one day we'd have machines with a quarter of a million times as much RAM, but we'd still have to using buffering for the simplest text file...!)

On Sunday, 5 February 2023 at 03:32:22 UTC+2, bart c wrote:
> On Friday, 3 February 2023 at 20:41:39 UTC, Vir Campestris wrote:
> > On 22/01/2023 19:59, fir wrote:
> > > when i work with text files i read it into ram then work on it...
> >
> > Not all text files are small. I've had to work on files many gigabytes
> > in size, and it can be hard to read the whole file in memory.
> >
> > It also means that the IO has to happen first (reading the file) then
> > the processing can being only after the entire file has been read.
> >
> > If you have a decent operating system - and that's most of them these
> > days - when you read a few bytes out of a file it will pre-buffer
> > several kB in advance so the next read is out of the cache.
> >
> > Processing a large file as you read it can be many times faster than
> > reading it in, then processing it. Even if it fits in your RAM.
> >
> > Andy
> I wouldn't exactly call such a file a text file, which implies something that is human readable.
>
> Most text files I read are source files, and an upper limit for normal files (not specially created tests) is 0.1MB. So I could have 40,000 such maximum files load at the same time on my 8GB machine with little problem.
>
> It would be silly then to process such files via a tiny read buffer, so that you'd have to keep checking for end-of-buffer for each character even in the middle of a token.
>
> (If somebody had told me 40 years ago that one day we'd have machines with a quarter of a million times as much RAM, but we'd still have to using buffering for the simplest text file...!)

Note that vast majority of text files and messages have not been meant
to be normally read by humans for two human generations. Things
like Postscript were invented in end of seventies. The human readability
of most text formats and protocols is there only for to make searching,
comparing and discussing potential defects and sources of misbehavior
possible with less need for special tools. Or for to make making such tools
easier.

piątek, 3 lutego 2023 o 21:41:39 UTC+1 Vir Campestris napisał(a):
> On 22/01/2023 19:59, fir wrote:
> > when i work with text files i read it into ram then work on it...
>
> Not all text files are small. I've had to work on files many gigabytes
> in size, and it can be hard to read the whole file in memory.
>
> It also means that the IO has to happen first (reading the file) then
> the processing can being only after the entire file has been read.
>
> If you have a decent operating system - and that's most of them these
> days - when you read a few bytes out of a file it will pre-buffer
> several kB in advance so the next read is out of the cache.
>
> Processing a large file as you read it can be many times faster than
> reading it in, then processing it. Even if it fits in your RAM.
>

if so on 99% (speaking somewhat metapgorically) you do
something wrong.. i already answered on that (back in post to mmclen if i remember correctly so will not find use in repeating it)

niedziela, 5 lutego 2023 o 02:32:22 UTC+1 bart c napisał(a):
> On Friday, 3 February 2023 at 20:41:39 UTC, Vir Campestris wrote:
> > On 22/01/2023 19:59, fir wrote:
> > > when i work with text files i read it into ram then work on it...
> >
> > Not all text files are small. I've had to work on files many gigabytes
> > in size, and it can be hard to read the whole file in memory.
> >
> > It also means that the IO has to happen first (reading the file) then
> > the processing can being only after the entire file has been read.
> >
> > If you have a decent operating system - and that's most of them these
> > days - when you read a few bytes out of a file it will pre-buffer
> > several kB in advance so the next read is out of the cache.
> >
> > Processing a large file as you read it can be many times faster than
> > reading it in, then processing it. Even if it fits in your RAM.
> >
> > Andy
> I wouldn't exactly call such a file a text file, which implies something that is human readable.
>
> Most text files I read are source files, and an upper limit for normal files (not specially created tests) is 0.1MB. So I could have 40,000 such maximum files load at the same time on my 8GB machine with little problem.
>
> It would be silly then to process such files via a tiny read buffer, so that you'd have to keep checking for end-of-buffer for each character even in the middle of a token.
>
> (If somebody had told me 40 years ago that one day we'd have machines with a quarter of a million times as much RAM, but we'd still have to using buffering for the simplest text file...!)

text files generally are not suitable/prone to be used thsi way that they are optimised/designed to be read partiallt then escape

it would be rether specific format for this - something like reverse log for example (latest messages last) its kinda specialistic usage and in context of this thred it was not stated it is about such very specific and rare cases ofc
(and im recently allerfiuc for people saying stupidity ony to say something, there are planty of much better topics possible)

niedziela, 5 lutego 2023 o 17:33:04 UTC+1 fir napisał(a):
>
> it would be rether specific format for this - something like reverse log for example (latest messages last)

i wanted to writa latset messages first (then when you read the file you may read few first lines and escape) ..in normal log file you eventually also can open log ship to end and read few last lines instead of all but this is still specialised case

in dact inm my own sickle.c library i just got a function that reads wgole file under mallocked ram and returns a pointer..its wery good way to go most cases

i can even post a code for that if someone wants

this is not a code i think has some atest to be good (as i maybe dont like something about it) its rather quickly done to work as a whole in many private uses and be ebentually made better later

int GetFileSize1(FILE* file)
{
int seek_pos = ftell(file);
int error = fseek(file, 0, SEEK_END);

if(error) ERROR_EXIT("seek1 error");

int file_length = ftell(file) ;
error = fseek(file, seek_pos, SEEK_SET);

if(error) ERROR_EXIT("seek2 error");

return file_length;
}

int GetFileSize2(char *filename)
{
struct stat st;

if (stat(filename, &st) == 0)
return (int) st.st_size;

ERROR_EXIT("error obtaining file size for &s", filename);

return -1;
}

chunk LoadChunk(char* file_name)
{ static char* internal_text = NULL;

FILE * file = fopen(file_name, "rb");

if(file == NULL) ERROR_EXIT( " cannot open file %s ", file_name);

int file_length = GetFileSize1(file);

internal_text = (char*)realloc(internal_text, file_length + 10);

if(internal_text == NULL) ERROR_EXIT(" cannot mallock data for file %s ", file_name);

int readed = fread(internal_text, 1, file_length, file);

int error = fclose(file);

if(error) ERROR_EXIT("\n cannot close file %s", file_name);

chunk text = {internal_text, internal_text + file_length - 1};
return text;

}

niedziela, 5 lutego 2023 o 17:41:52 UTC+1 fir napisał(a):
> niedziela, 5 lutego 2023 o 17:33:04 UTC+1 fir napisał(a):
> >
> > it would be rether specific format for this - something like reverse log for example (latest messages last)
> i wanted to writa latset messages first (then when you read the file you may read few first lines and escape) ..in normal log file you eventually also can open log ship to end and read few last lines instead of all but this is still specialised case
>
> in dact inm my own sickle.c library i just got a function that reads wgole file under mallocked ram and returns a pointer..its wery good way to go most cases
>
> i can even post a code for that if someone wants
>
> this is not a code i think has some atest to be good (as i maybe dont like something about it) its rather quickly done to work as a whole in many private uses and be ebentually made better later
>
>
> int GetFileSize1(FILE* file)
> {
> int seek_pos = ftell(file);
> int error = fseek(file, 0, SEEK_END);
>
> if(error) ERROR_EXIT("seek1 error");
>
> int file_length = ftell(file) ;
> error = fseek(file, seek_pos, SEEK_SET);
>
> if(error) ERROR_EXIT("seek2 error");
>
> return file_length;
> }
>
>
>
> int GetFileSize2(char *filename)
> {
> struct stat st;
>
> if (stat(filename, &st) == 0)
> return (int) st.st_size;
>
> ERROR_EXIT("error obtaining file size for &s", filename);
>
> return -1;
> }
>
>
>
> chunk LoadChunk(char* file_name)
> {
> static char* internal_text = NULL;
>
> FILE * file = fopen(file_name, "rb");
>
> if(file == NULL) ERROR_EXIT( " cannot open file %s ", file_name);
>
> int file_length = GetFileSize1(file);
>
> internal_text = (char*)realloc(internal_text, file_length + 10);
>
> if(internal_text == NULL) ERROR_EXIT(" cannot mallock data for file %s ", file_name);
>
> int readed = fread(internal_text, 1, file_length, file);
>
> int error = fclose(file);
>
> if(error) ERROR_EXIT("\n cannot close file %s", file_name);
>
> chunk text = {internal_text, internal_text + file_length - 1};
> return text;
>
> }
if someone sees clearly what is not much good in that code he may say it could make more interesting or constructive discussion.. maybe iu should check if fread not returns error but i dont remember now ..inj also not sure if get file size 1 or 2 is better (chink is of course typedef struct { char* beg,* end; } chunk; ) where end points to last char of file (i hate zero ended chars)

take yet that if need

void SaveChunk(chunk ch, char* filename)
{ if(ChunkIsEmpty(ch)) return;

FILE* file = fopen (filename, "wb");

if(file == NULL) ERROR_EXIT( " cannot open file %s ", filename);

fwrite (ch.beg , 1, ChunkLength(ch), file);

fclose (file);

}

void SaveChunkTextMode(chunk ch, char* filename)
{ if(ChunkIsEmpty(ch)) return;

FILE* file = fopen (filename, "wt");

if(file == NULL) ERROR_EXIT( " cannot open file %s ", filename);

fwrite (ch.beg , 1, ChunkLength(ch), file);

fclose (file);

}

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
> [...]
>
>> It was Phil Carmody [...] who insinuated that "octoctal" is a
>> neo-Nazi dogwhistle.
>
> I think it's important to distinguish between saying a particular
> word is /heard/ by some (or many) people as a dogwhistle, and
> saying that a given speaker who used the word /intended to give/
> a dogwhistle.
>
> I don't know what Phil was thinking when he made his comment, but
> I think we shouldn't assume he meant one of these alternatives
> when he may have meant only the other.

Someone walked into the thread carrying an ornate awl he was very proud of.
All I said was "nice shiv".

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/