mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > Software

Reply
 
Thread Tools
Old 2023-01-28, 23:59   #980
storm5510
Random Account
 
storm5510's Avatar
 
Aug 2009
Not U. + S.A.

2×7×181 Posts
Default

Quote:
Originally Posted by rogue View Post
...The difference between \n and \r doesn't make any sense. The code is GPU agnostic. But if it works for you, then who am I to complain.
I remember \n from trade school. New line. \r must be more recent. As long as it does its job and you have no suspicions about it working properly, then no problem here.
storm5510 is offline   Reply With Quote
Old 2023-01-29, 22:32   #981
Mark Rose
 
Mark Rose's Avatar
 
"/X\(‘-‘)/X\"
Jan 2013

2×1,553 Posts
Default

Quote:
Originally Posted by storm5510 View Post
I remember \n from trade school. New line. \r must be more recent. As long as it does its job and you have no suspicions about it working properly, then no problem here.
Unix traditionally used the line feed character (ASCII 10 or 0A) for a new line, commonly represented as \n.

Old Mac, before Mac OS X (which is Unix under the hood), used the carriage return character (13 or 0D), \r.

CP/M used both, \r\n. In many ways MS DOS was modelled after CP/M, including the use of both characters for a new line. That has continued on to modern Windows.

Most programming languages discard white space. Most editors are smart enough to work with the existing encoding of a text file.

https://blog.codinghorror.com/the-great-newline-schism/
Mark Rose is online now   Reply With Quote
Old 2023-02-01, 05:51   #982
LaurV
Romulan Interpreter
 
LaurV's Avatar
 
"name field"
Jun 2011
Thailand

3×23×149 Posts
Default

Real programmers (TM) use \r or CR (carriage return) or ascii code 13 (hex 0x0D) for bringing the cursor at the beginning of the line, without advancing to the new line. This is very useful when you have "counting counters" or other running numbers or info on screen and you want that info to stay on the same line without changing the rest of the screen.
Same way, \n or LF (line feed) or ascii code 10 (hex 0x0A) is used to advance the line without bringing the cursor to the beginning of the line. Like moving the cursor down one row. You have also codes to move the cursor up, or left, right. On former tty (text) monitors (like VT100, etc) you would have to move the cursor here or there to write drop down menus, rewrite the screen under those, when the menu is closed, etc. There is also a FF character (form feed, page skip, you can see all these in an ascii table) which is dated from before terminals, when all the interface was on printer, and the printer would have to go to the next page. In "modern times" they got different uses but a "clever" terminal (like TeraTerm, etc., but also partially for less clever terminals like windows' HT or the command prompt) may have specific settings how these characters (and their combinations are treated). Some "less clever" systems/programs will make no difference and treat all of them like being both CR+LF, i.e. the cursor comes to the beginning of the next like - this is stupid and makes your screen behave like an old typewriter where you had a crowbar to push to return the carriage and advance a line in the same time, Norman style... There you can not (easily) make a running counter on screen, and generally your "grades of liberty" when you design the "text interface" of your program are much restricted.

Last fiddled with by LaurV on 2023-02-01 at 05:52
LaurV is offline   Reply With Quote
Old 2023-02-01, 13:18   #983
Andrew Usher
 
Dec 2022

E416 Posts
Default

It would be nice to have the characters always work in that 'logical' way, but that can't be assumed anymore. In that case a newline would consist of both characters (in either order) and there DOS/Windows have it right, and CR+LF was not invented by CP/M but goes back to the ASCII standard, which in turn was based on actual typewriter/teletype use.

Unix is gratuitously incompatible here, and for the sake of saving one byte per line, which seems absurd today (it also makes the tricks you suggest impossible, as does the standard C library, based on Unix conventions).
Andrew Usher is offline   Reply With Quote
Old 2023-02-02, 00:11   #984
storm5510
Random Account
 
storm5510's Avatar
 
Aug 2009
Not U. + S.A.

2×7×181 Posts
Default

Quote:
Originally Posted by Andrew Usher View Post
It would be nice to have the characters always work in that 'logical' way, but that can't be assumed anymore. In that case a newline would consist of both characters (in either order) and there DOS/Windows have it right, and CR+LF was not invented by CP/M but goes back to the ASCII standard, which in turn was based on actual typewriter/teletype use.

Unix is gratuitously incompatible here, and for the sake of saving one byte per line, which seems absurd today (it also makes the tricks you suggest impossible, as does the standard C library, based on Unix conventions).
I would think that, regardless of the programming language, the actual binary values of each would not change. From my days of tinkering with hex editors, I recognized them as 0A 0D.
storm5510 is offline   Reply With Quote
Old 2023-02-02, 13:49   #985
Andrew Usher
 
Dec 2022

22·3·19 Posts
Default

Actually, 0D 0A in DOS/Windows format (the other order won't generally work), but in a Unix-format text file, it really is just 0A. In any case, the C standard output converts all newlines written to it explicitly or implicitly into both functions, regardless of the system implementation, and the same is true of files opened in text mode (which are treated the same - another Unixism).

There is a way of doing the 'running counter' trick in DOS (don't know if it works the same in modern Windows) using non-standard functions, and it can be done in Unix also, but differently - there is no portable way of moving the cursor using ASCII characters, though there was supposed to be.
Andrew Usher is offline   Reply With Quote
Old 2023-02-03, 04:49   #986
storm5510
Random Account
 
storm5510's Avatar
 
Aug 2009
Not U. + S.A.

47468 Posts
Default

Quote:
Originally Posted by LaurV View Post
Real programmers (TM) use \r or CR (carriage return) or ascii code 13 (hex 0x0D) for bringing the cursor at the beginning of the line, without advancing to the new line...
How does this change in-process from overwriting an existing line to creating a new line below? rogue says he doesn't understand how it can do this in the case of srsieve2cl. My "guess" is that it has something to do with the GPU or its driver package. It does this on one of my GPU's, but not both.
storm5510 is offline   Reply With Quote
Old 2023-02-03, 09:46   #987
LaurV
Romulan Interpreter
 
LaurV's Avatar
 
"name field"
Jun 2011
Thailand

1028110 Posts
Default

Quote:
Originally Posted by Andrew Usher View Post
(it also makes the tricks you suggest impossible, as does the standard C library, based on Unix conventions).
no, not impossible, there are "escape sequences" for those, I remember the old 0x1B, 0x5B, etc sequences I had to send to my VT52 and VT100 to move the cursor here and there, delete lines, etc. I remember they existed, I mean, and I used them in my Uni projects a lot, but I don't remember what they were. One can easily google those.

And to reply to storm too, I don't use srsieve2cl, but I am sure it can be done, as well as I am sure that the Linux terminal is a lot more clever than the Windoze stuff I use. Those terminals were modeled after the VT52, in fact.

Last fiddled with by LaurV on 2023-02-03 at 09:49
LaurV is offline   Reply With Quote
Old 2023-02-03, 13:09   #988
Andrew Usher
 
Dec 2022

22·3·19 Posts
Default

Quote:
Originally Posted by LaurV View Post
no, not impossible, there are "escape sequences" for those, I remember the old 0x1B, 0x5B, etc sequences I had to send to my VT52 and VT100 to move the cursor here and there, delete lines ...
Yes, but that is not standard, which is my point. Although all terminal devices presumably can do this somehow, Unix chose not to support it - and if standard output were redirected to a file (as is always possible), those escape sequences might make it unreadable.
Andrew Usher is offline   Reply With Quote
Reply

Thread Tools


All times are UTC. The time now is 18:43.


Sun Feb 5 18:43:24 UTC 2023 up 171 days, 16:11, 1 user, load averages: 1.04, 0.90, 0.83

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2023, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.

≠ ± ∓ ÷ × · − √ ‰ ⊗ ⊕ ⊖ ⊘ ⊙ ≤ ≥ ≦ ≧ ≨ ≩ ≺ ≻ ≼ ≽ ⊏ ⊐ ⊑ ⊒ ² ³ °
∠ ∟ ° ≅ ~ ‖ ⟂ ⫛
≡ ≜ ≈ ∝ ∞ ≪ ≫ ⌊⌋ ⌈⌉ ∘ ∏ ∐ ∑ ∧ ∨ ∩ ∪ ⨀ ⊕ ⊗ 𝖕 𝖖 𝖗 ⊲ ⊳
∅ ∖ ∁ ↦ ↣ ∩ ∪ ⊆ ⊂ ⊄ ⊊ ⊇ ⊃ ⊅ ⊋ ⊖ ∈ ∉ ∋ ∌ ℕ ℤ ℚ ℝ ℂ ℵ ℶ ℷ ℸ 𝓟
¬ ∨ ∧ ⊕ → ← ⇒ ⇐ ⇔ ∀ ∃ ∄ ∴ ∵ ⊤ ⊥ ⊢ ⊨ ⫤ ⊣ … ⋯ ⋮ ⋰ ⋱
∫ ∬ ∭ ∮ ∯ ∰ ∇ ∆ δ ∂ ℱ ℒ ℓ
𝛢𝛼 𝛣𝛽 𝛤𝛾 𝛥𝛿 𝛦𝜀𝜖 𝛧𝜁 𝛨𝜂 𝛩𝜃𝜗 𝛪𝜄 𝛫𝜅 𝛬𝜆 𝛭𝜇 𝛮𝜈 𝛯𝜉 𝛰𝜊 𝛱𝜋 𝛲𝜌 𝛴𝜎𝜍 𝛵𝜏 𝛶𝜐 𝛷𝜙𝜑 𝛸𝜒 𝛹𝜓 𝛺𝜔