proof errors

[retina]

Originally Posted by preda

BTW, it is normally accepted that the defition of a line in a file is text that ends with a line separator. This can be seen in the output of "wc -l" which counts the lines in a file, which does not count as a line text that's not line-ended.

I wouldn't trust wc to be the sole definer of a line.

But, OMG, you are correct:

~ echo -n "hi" | wc -l
0

Now I hate wc

[aheeffer]

Originally Posted by preda

It's not clear what you mean by "will stop".

If it throws an exception telling you to add a newline, that's fine.

OTOH what you seem to have reported earlier was an exponent that was ran twice. That's not consistent with "will stop", and that's what I can't reproduce.

In other words: do you see a problem with the current behavior? if so, what is the problem you see, exactly?

Here is an example:

2020-06-17 14:55:50 gfx906-0 worktodo.txt : line "PRP=320AC8B64330ED58CBAB02B3947C8D59,1,2,104980517,-1,77,0" does not end with a newline2020-06-17 14:55:50 gfx906-0 Exiting because "lines must end with newline"
2020-06-17 14:55:50 gfx906-0 waiting for background GCDs..
2020-06-17 14:55:50 gfx906-0 Bye

Well 'stop' means the program stops running and tells me 'Bye'. Then I know I simply have to add a CR/LF at the end of the worktodo.txt file. The problem is that I notice 12 to 24 hours later which is a waste of precious Radeon VII compute time. It happened to me several times because it is a natural thing to do with manual assignments: cut - past - save.

[aheeffer]

The above case was a standalone instance of gpuowl. In case the pool option is used, the program does not to exit but seems to look for a 'worktodo.txt' in the local directory. It found an old one (from before using the pool option) and started with an exponent which apparently had expired and its result submitted.

2020-10-21 21:15:09 Rig-RadeonVII-01 worktodo.txt line ignored: ""
2020-10-21 21:15:09 Rig-RadeonVII-01 108980089 FFT: 6M 1K:12:256 (17.32 bpw)
2020-10-21 21:15:09 Rig-RadeonVII-01 Expected maximum carry32: 2E340000
2020-10-21 21:15:10 Rig-RadeonVII-01 OpenCL args "-DEXP=108980089u -DWIDTH=1024u -DSMALL_HEIGHT=256u -DMIDDLE=12u -DPM1=0 -DAMDGPU=1 -DWEIGHT_STEP_MINUS_1=0x9.99a4967011bap-4 -DIWEIGHT_STEP_MINUS_1=-0xc.00089583deaa8p-5  -cl-unsafe-math-optimizations -cl-std=CL2.0 -cl-finite-math-only "
2020-10-21 21:15:10 Rig-RadeonVII-01 ASM compilation failed, retrying compilation using NO_ASM
2020-10-21 21:15:12 Rig-RadeonVII-01 OpenCL compilation in 2.08 s
2020-10-21 21:15:13 Rig-RadeonVII-01 108980089 OK        0 loaded: blockSize 400, 0000000000000003

I hope I made myself clear now.

[Nick]

Originally Posted by retina

Now I hate wc

It's logical because it respects concatenation:
if "wc -l a" gives m and "wc -l b" gives n then "cat a b|wc -l" gives m+n.

[retina]

Originally Posted by Nick

It's logical because it respects concatenation:
if "wc -l a" gives m and "wc -l b" gives n then "cat a b|wc -l" gives m+n.

Nope. wc is still wrong.

"A" has zero lines according to wc, and "B" has zero lines according to wc. But both of those have 1 line each. If I concatenate them then "AB" also has 1 line, it isn't zero lines.

Why should I care about m+n? I only care about the final result, not the parts that make it up.

How many lines are in the following text?

I am one line.

[PhilF]

Originally Posted by retina

How many lines are in the following text?

I am one line.

Depends on if there is a newline at the end.

I like the behavior. As long as you realize the behavior is there, it makes wc more versatile. For example, in this case Preda could use it to determine whether a text file uses newlines or not, then add them if necessary.

[retina]

My conversation with wc:

Me: Hey wc, how many lines were returned from this command?
wc: Zero
Me: So the output was nothing?
wc: No. I said there are zero lines.
Me: How can there be no lines, but still have something there?
wc: Because I said so, that's why.
Me: So if I write out this one line on a piece of paper and ask you to count the lines what will you say?
wc: There are zero lines.
Me: I hate you!

[Xyzzy]

Maybe it is using zero indexing?

[kriesel]

Originally Posted by Xyzzy

Maybe it is using zero indexing?

There's always at least one 0 wiseacre in every crowd.

[retina]

wc can go jump in a lake. grep has it correct:

~ echo -n "hi" | grep -c ""
1

[Batalov]

wc -l doesn't count "lines", it counts line breaks. If there are none, it will return 0.
If you take a short binary file then it will also likely have 0 'lines' (so one can assume that was what wc's author thought a good thing.)

If you wc -l on a "mac-produced" text file you will typically get a 0. (because mac uses \r for a line break.)