Re: Should D file end with newline?
On Tuesday, 12 February 2019 at 20:03:09 UTC, Jonathan M Davis wrote: So, I'd say that it's safe to say that dmd The whole thing just seems like a weird requirement that really shouldn't be there, Like I said in the first reply, FWIW, it's a POSIX requirement. Turns out most tools don't care (and dmd is apparently one of them). If you want an easy counterexample, try the wc command (it miscounts lines for non-compliant files). I've never seen that break an actual build system, which is why I said you could mostly get away with it. On the other hand, being POSIX-compliant always works. it matters even less if text editors are automatically appending newlines to files if they aren't there whether they show them or not, since if that's the case, you'd have to really work at it to have files not ending with newlines anyway. There are definitely broken text editors out there that won't add the newline (can't think of names). Like Jacob Carlborg said, Github flags the files they generate. hexdump shows a newline followed by a null character followed by a newline after the carriage return. hexdump is printing little-endian 16b by default, so I think that's just two newlines followed by a padding byte from hexdump. Try using the -c or -b flag and you probably won't see any null byte. Curiously, if I create a .cpp or .c file with vim and have it end with a curly brace, vim _does_ append a newline followed by a null character followed by a newline at the end of the file. So, I guess that vim looks at the extension and realizes that C/C++ has such a requirement and takes care of it for you, but it does not think that .d files need them and adds nothing extra for them. It doesn't add anything for a .txt file when I tried it either. Are you sure? vim is supposed to add the newline for all text files because that's POSIX. It does on my (GNU/Linux) machine.
Re: Should D file end with newline?
On Tuesday, February 12, 2019 4:45:43 AM MST Jacob Carlborg via Digitalmars- d-learn wrote: > On 2019-02-10 18:20, Jonathan M Davis wrote: > > I use (g)vim, which I would expect to show anything like trailing > > newlines. It usually shows everything, including rendering control > > characters and the like in a way that you know exactly what's there. > > Opening up > > std/algorithm/mutation.d in vim as an example, it clearly ends in a > > closing brace with no trailing newline. However if I feed it into > > hexdump > > > > ... > > 00158f0 2020 6373 706f 2865 7865 7469 2029 7266 > > 0015900 6565 7328 702e 7274 3b29 7d0a 000a > > 001590d > > > > hexdump shows a newline followed by a null character followed by a > > newline after the carriage return. So, it does indeed look like extra > > junk is there after the data in the file, and surprisingly, vim doesn't > > showing it (or anything indicating that it's there). I don't know why > > any of that would be there, since it seems pointless me, but it is > > there in > > std/algorithm/mutation.d. On the other hand, if I open up > > std/datetime/systime.d with hexdump, it shows > > > > 007f8b0 0a7d 2020 2020 2020 2020 0a7d 2020 2020 > > 007f8c0 0a7d 0a7d > > 007f8c4 > > > > so it actually ends on a closing braces. So, maybe some text editors > > shove extra junk on the end and others don't? I don't know. Either way, > > I find it very odd that vim doesn't show anything after the closing > > brace when it's there. Both of those files show a closing brace as > > their last character when opened in vim. Looking quickly at some of my > > personal projects, I don't see any files which end with anything other > > than a closing brace according to either vim or hexdump. And since all > > of those were created with (g)vim, I'd say that vim does not put those > > extra characters on the end (though it will allow them and otherwise > > ignore them). That also makes it clear that no newline or any other > > special sequence of characters is required at the end of a .d file, > > because all of those files work just fine with their last character > > being a closing brace. > > > > Curiously, if I create a .cpp or .c file with vim and have it end with a > > curly brace, vim _does_ append a newline followed by a null character > > followed by a newline at the end of the file. So, I guess that vim looks > > at the extension and realizes that C/C++ has such a requirement and > > takes care of it for you, but it does not think that .d files need them > > and adds nothing extra for them. It doesn't add anything for a .txt > > file when I tried it either. > > > > In any case, if your text editor happens to insert those extra > > characters at the end of a .d file, then they may end up there, but > > given what hexdump says and what dmd accepts, I can verify that they > > aren't actually required for .d files. > > According to my text editor (TextMate) and GitHub* both > std/algorithm/mutation.d and std/datetime/systime.d ends with a newline. > Also all your source files in your dxml project ends with a newline. > Using "cat" to show the content of a file it's pretty clear if it ends > with a newline or not. If it doesn't, then the prompt will be printed > after the last character in the file. If it does end with a newline, the > prompt will be printed on its own line. (Some terminal emulators, like > iTerm, will add a newline automatically before printing the prompt if > the last output doesn't end with a newline). > > * GitHub will add a symbol at the end of the file indicating it doesn't > end with a newline. I don't know. The various programs don't seem to agree what's actually in the file. If you want another test though, I tried writing a program that wrote out a hello world program with no newlines in it. I never opened the resulting file it in a text editor, so no text editor could screw with it, and it compiled and ran with dmd just fine. cat even doesn't print any newlines in my terminal when cat-ing, screwing up the prompt, since it's not on its own line. So, I'd say that it's safe to say that dmd does not care about newlines at the end of the file, and I honestly have no clue why any programming language would unless C/C++ is doing something like relying on the newline at the end of the file to make sure #including files results in whitespace between them, but AFAIK, you have to put #includes on their own line anyway, and even if that _were_ the problem, the compiler could have just inserted the newlines. The whole thing just seems like a weird requirement that really shouldn't be there, but given that it's C/C++, there was probably something weird with computers back in the 1970's that made it seem like a better idea than it seems like now. Regardless, none of that applies to D, and it matters even less if text editors are automatically appending newlines to files if they aren't there whether they show them or not, since if that's the case, you'd have to really work
Re: Handling big FP numbers
On Saturday, 9 February 2019 at 02:54:18 UTC, Adam D. Ruppe wrote: (The `real` thing in D was a massive mistake. It is slow and adds nothing but confusion.) We've had occasional problems with `real` being 80-bit on FPU giving more precision than asked, and effectively hiding 32-bit float precision problems until run on SSE. Not a big deal, but I would argue giving more precision than asked is a form of Postel's law: a bad idea.
Re: Should D file end with newline?
On 2019-02-10 18:20, Jonathan M Davis wrote: I use (g)vim, which I would expect to show anything like trailing newlines. It usually shows everything, including rendering control characters and the like in a way that you know exactly what's there. Opening up std/algorithm/mutation.d in vim as an example, it clearly ends in a closing brace with no trailing newline. However if I feed it into hexdump ... 00158f0 2020 6373 706f 2865 7865 7469 2029 7266 0015900 6565 7328 702e 7274 3b29 7d0a 000a 001590d hexdump shows a newline followed by a null character followed by a newline after the carriage return. So, it does indeed look like extra junk is there after the data in the file, and surprisingly, vim doesn't showing it (or anything indicating that it's there). I don't know why any of that would be there, since it seems pointless me, but it is there in std/algorithm/mutation.d. On the other hand, if I open up std/datetime/systime.d with hexdump, it shows 007f8b0 0a7d 2020 2020 2020 2020 0a7d 2020 2020 007f8c0 0a7d 0a7d 007f8c4 so it actually ends on a closing braces. So, maybe some text editors shove extra junk on the end and others don't? I don't know. Either way, I find it very odd that vim doesn't show anything after the closing brace when it's there. Both of those files show a closing brace as their last character when opened in vim. Looking quickly at some of my personal projects, I don't see any files which end with anything other than a closing brace according to either vim or hexdump. And since all of those were created with (g)vim, I'd say that vim does not put those extra characters on the end (though it will allow them and otherwise ignore them). That also makes it clear that no newline or any other special sequence of characters is required at the end of a .d file, because all of those files work just fine with their last character being a closing brace. Curiously, if I create a .cpp or .c file with vim and have it end with a curly brace, vim _does_ append a newline followed by a null character followed by a newline at the end of the file. So, I guess that vim looks at the extension and realizes that C/C++ has such a requirement and takes care of it for you, but it does not think that .d files need them and adds nothing extra for them. It doesn't add anything for a .txt file when I tried it either. In any case, if your text editor happens to insert those extra characters at the end of a .d file, then they may end up there, but given what hexdump says and what dmd accepts, I can verify that they aren't actually required for .d files. According to my text editor (TextMate) and GitHub* both std/algorithm/mutation.d and std/datetime/systime.d ends with a newline. Also all your source files in your dxml project ends with a newline. Using "cat" to show the content of a file it's pretty clear if it ends with a newline or not. If it doesn't, then the prompt will be printed after the last character in the file. If it does end with a newline, the prompt will be printed on its own line. (Some terminal emulators, like iTerm, will add a newline automatically before printing the prompt if the last output doesn't end with a newline). * GitHub will add a symbol at the end of the file indicating it doesn't end with a newline. -- /Jacob Carlborg
Re: Handling big FP numbers
On Tuesday, 12 February 2019 at 09:20:27 UTC, Aurélien Plazzotta wrote: Thank you both for your lesson Adam D. Ruppe and H.S. Teoh. Is there a wish or someone showing one's intention to implement into the language the hypothetical built-in 128 bit types via the "cent" and "ucent" reserved keywords? cent and ucent would be integers with values between -170141183460469231731687303715884105728 to 170141183460469231731687303715884105727 and 0 to 340282366920938463463374607431768211455, respectively. Their implementation would not mean that any kind of 128-bit float would also be available. For bigger floating-point numbers there's at least two packages on dub: https://code.dlang.org/packages/stdxdecimal https://code.dlang.org/packages/decimal These are arbitrary-precision, and probably quite a bit slower than any built-in floats. -- Simen
Re: Handling big FP numbers
On Saturday, 9 February 2019 at 03:03:41 UTC, H. S. Teoh wrote: If you want to hold more than 15 digits, you'll either have to use `real`, which depending on your CPU will be 80-bit (x86) or 128-bit (a few newer, less common CPUs), or an arbitrary-precision library that simulates larger precisions in software, like the MPFR module of libgmp. Note, however, that even even 80-bit real realistically only holds up to about 18 digits, which isn't very much more than a double, and still far too small for your number above. You need at least a 128-bit quadruple precision type (which can represent up to about 34 digits) in order to represent your above number accurately. T Thank you both for your lesson Adam D. Ruppe and H.S. Teoh. Is there a wish or someone showing one's intention to implement into the language the hypothetical built-in 128 bit types via the "cent" and "ucent" reserved keywords?
