www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Giving up

reply Rumbu <rumbu rumbu.ro> writes:
Hi,

Sincerely I am tired to maintain my library with every change 
made by D compiler. Mostly regressions. Bug reports are ignored 
or challenged, I don't have time to argue.

Therefore, if someone finds interesting my decimal lib [0], 
please continue or maintain it from here, I stopped completely to 
adjust it. It is still working, but unit tests are not running 
anymore because of regressions in compiler.

The last issues are generated by unpublished changes in the 
parser:

Examples:

```
float z = 85886696878585969769557975866955695.E0; //integer 
overflow, I don't see any int
real x = 0x1p-16383; //number `0x1p-16383` is not representable. 
It is, trust me.

```

Please don't ask me what is the last version when everything 
worked like a charm. I don't know and now I don't care.

[0] https://github.com/rumbu13/decimal
Aug 05
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 8/5/22 11:36 AM, Rumbu wrote:
 float z = 85886696878585969769557975866955695.E0; //integer overflow, I 
 don't see any int
That's an integer, which is trying to call a UFCS function named `E0`. Did you mean to include the `.`? -Steve
Aug 05
next sibling parent reply React <react react.js> writes:
On Friday, 5 August 2022 at 15:44:10 UTC, Steven Schveighoffer 
wrote:
 On 8/5/22 11:36 AM, Rumbu wrote:
 float z = 85886696878585969769557975866955695.E0; //integer 
 overflow, I don't see any int
That's an integer, which is trying to call a UFCS function named `E0`. Did you mean to include the `.`? -Steve
Yes, continue to argue, exactly what I am saying. It worked before because numbers were eagerly consumed in the parser. Someone made a change without dovumenting it. That value is not even written by me, it is from an official test file from Intel which should be parsed by any C compiler. Since there are millions of tests there, I don't intend to hand pick the values from the file to make D compiler happy.
Aug 05
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 8/5/22 11:57 AM, React wrote:
 On Friday, 5 August 2022 at 15:44:10 UTC, Steven Schveighoffer wrote:
 On 8/5/22 11:36 AM, Rumbu wrote:
 float z = 85886696878585969769557975866955695.E0; //integer overflow, 
 I don't see any int
That's an integer, which is trying to call a UFCS function named `E0`. Did you mean to include the `.`?
Yes, continue to argue, exactly what I am saying. It worked before because numbers were eagerly consumed in the parser. Someone made a change without dovumenting it.
Just saying, I see an integer. That's an integer according to the language (as far back as I can test, which is 2.060 released 2012). If that was somehow parsing as a float before, that was a bug in the parser. Since your first release is 0.9, released Jan 2018, I find it hard to believe this ever worked for you.
 That value is not even written by me, it 
 is from an official test file from Intel which should be parsed by any C 
 compiler.
D is not a C compiler. Well it has an experimental one, but that shouldn't be relied on for testing. -Steve
Aug 05
parent reply Rumbu <rumbu rumbu.ro> writes:
On Friday, 5 August 2022 at 16:08:50 UTC, Steven Schveighoffer 
wrote:

 Just saying, I see an integer. That's an integer according to 
 the language (as far back as I can test, which is 2.060 
 released 2012). If that was somehow parsing as a float before, 
 that was a bug in the parser. Since your first release is 0.9, 
 released Jan 2018, I find it hard to believe this ever worked 
 for you.
Yes, I am lying, my hidden agenda is to put D in a bad spot. Congrats, you got me.
Aug 05
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 8/5/22 12:30 PM, Rumbu wrote:
 On Friday, 5 August 2022 at 16:08:50 UTC, Steven Schveighoffer wrote:
 
 Just saying, I see an integer. That's an integer according to the 
 language (as far back as I can test, which is 2.060 released 2012). If 
 that was somehow parsing as a float before, that was a bug in the 
 parser. Since your first release is 0.9, released Jan 2018, I find it 
 hard to believe this ever worked for you.
Yes, I am lying, my hidden agenda is to put D in a bad spot. Congrats, you got me.
I don't have any agenda or want to bust yours. D is not in a bad spot since code that is not D code is not (and has never been) expected to compile. I don't think that code ever built. Possibly you didn't test it properly originally. But if you are done with it, I guess it doesn't matter. -Steve
Aug 05
parent reply Rumbu <rumbu rumbu.ro> writes:
On Friday, 5 August 2022 at 16:37:56 UTC, Steven Schveighoffer 
wrote:
 I don't think that code ever built. Possibly you didn't test it 
 properly originally. But if you are done with it, I guess it 
 doesn't matter.

 -Steve
Thank you for this. Deleted since everything is fake there and never worked.
Aug 05
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 8/5/22 12:48 PM, Rumbu wrote:
 On Friday, 5 August 2022 at 16:37:56 UTC, Steven Schveighoffer wrote:
 I don't think that code ever built. Possibly you didn't test it 
 properly originally. But if you are done with it, I guess it doesn't 
 matter.
Thank you for this. Deleted since everything is fake there and never worked.
I meant the intel.d file, not the whole thing! Hopefully you change your mind, as removing projects can affect anyone who is depending on it. At least let someone take it over! -Steve
Aug 05
parent reply bachmeier <no spam.net> writes:
On Friday, 5 August 2022 at 16:51:44 UTC, Steven Schveighoffer 
wrote:
 On 8/5/22 12:48 PM, Rumbu wrote:
 On Friday, 5 August 2022 at 16:37:56 UTC, Steven Schveighoffer 
 wrote:
 I don't think that code ever built. Possibly you didn't test 
 it properly originally. But if you are done with it, I guess 
 it doesn't matter.
Thank you for this. Deleted since everything is fake there and never worked.
I meant the intel.d file, not the whole thing! Hopefully you change your mind, as removing projects can affect anyone who is depending on it. At least let someone take it over! -Steve
The D source files should be saved as part of the documentation. I checked and this is the case for the five modules. (Never used it, so no idea what to do with them, but they're there if someone else wants them.)
Aug 05
parent reply bachmeier <no spam.net> writes:
On Friday, 5 August 2022 at 17:46:59 UTC, bachmeier wrote:
 The D source files should be saved as part of the 
 documentation. I checked and this is the case for the five 
 modules. (Never used it, so no idea what to do with them, but 
 they're there if someone else wants them.)
Here's the code if anyone is relying on it: https://github.com/bachmeil/decimal/tree/main Same license as the original.
Aug 05
parent reply mw <mingwu gmail.com> writes:
On Friday, 5 August 2022 at 17:56:47 UTC, bachmeier wrote:
 Here's the code if anyone is relying on it: 
 https://github.com/bachmeil/decimal/tree/main
I really think DUB should save a copy of all the files of all the registered packages: https://code.dlang.org/packages/decimal to prevent such disaster in the future. bachmeier, you want create a new DUB entry?
Aug 05
parent reply bachmeier <no spam.net> writes:
On Friday, 5 August 2022 at 18:29:46 UTC, mw wrote:
 On Friday, 5 August 2022 at 17:56:47 UTC, bachmeier wrote:
 Here's the code if anyone is relying on it: 
 https://github.com/bachmeil/decimal/tree/main
I really think DUB should save a copy of all the files of all the registered packages: https://code.dlang.org/packages/decimal to prevent such disaster in the future. bachmeier, you want create a new DUB entry?
I'm not familiar with that process. Anyone else that has the necessary knowledge should feel free to do so.
Aug 05
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 8/5/22 10:40 PM, bachmeier wrote:
 On Friday, 5 August 2022 at 18:29:46 UTC, mw wrote:
 On Friday, 5 August 2022 at 17:56:47 UTC, bachmeier wrote:
 Here's the code if anyone is relying on it: 
 https://github.com/bachmeil/decimal/tree/main
I really think DUB should save a copy of all the files of all the registered packages: https://code.dlang.org/packages/decimal to prevent such disaster in the future. bachmeier, you want create a new DUB entry?
I'm not familiar with that process. Anyone else that has the necessary knowledge should feel free to do so.
Note, we have a complete copy of the git repository. I would prefer a full copy if someone is going to register. Please ask on discord if you need this, WebFreak has the full copy. It needs someone to publish and maintain. -Steve
Aug 06
parent reply mw <mingwu gmail.com> writes:
On Sunday, 7 August 2022 at 00:54:35 UTC, Steven Schveighoffer 
wrote:
 Note, we have a complete copy of the git repository.
So you mean all the dub registered packages are cached somewhere? Can we publish the cache address?
Aug 06
next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 8/6/22 8:59 PM, mw wrote:
 On Sunday, 7 August 2022 at 00:54:35 UTC, Steven Schveighoffer wrote:
 Note, we have a complete copy of the git repository.
So you mean all the dub registered packages are cached somewhere? Can we publish the cache address?
I don't know how it's done. It's probably their local copy. -Steve
Aug 06
prev sibling parent WebFreak001 <d.forum webfreak.org> writes:
On Sunday, 7 August 2022 at 00:59:14 UTC, mw wrote:
 On Sunday, 7 August 2022 at 00:54:35 UTC, Steven Schveighoffer 
 wrote:
 Note, we have a complete copy of the git repository.
So you mean all the dub registered packages are cached somewhere? Can we publish the cache address?
here is a snapshot, but I don't have the constantly updating cache exposed anywhere: https://wfr.moe/clones-2022-06-14_16-16-36_you_might_need_to_git_checkout_master_or_main_in_each_project.tar.zstd The dependency cloning and updating is part of https://github.com/Pure-D/symbol-search which is a complete DScanner index of all DUB packages (all symbols indexed with version, file and line number + symbol type and other things) which is run on my server every 6 hours.
Aug 08
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Friday, 5 August 2022 at 16:30:28 UTC, Rumbu wrote:
 On Friday, 5 August 2022 at 16:08:50 UTC, Steven Schveighoffer 
 wrote:

 Just saying, I see an integer. That's an integer according to 
 the language (as far back as I can test, which is 2.060 
 released 2012). If that was somehow parsing as a float before, 
 that was a bug in the parser. Since your first release is 0.9, 
 released Jan 2018, I find it hard to believe this ever worked 
 for you.
Yes, I am lying, my hidden agenda is to put D in a bad spot. Congrats, you got me.
If you pull up run.dlang.org and run the code below with "All D compilers" (which goes back to 2.060) you can see what the error messages would have been. As I said above, if you remove the `.` or the `E` then it should have run fine (the server might time out with all compilers, but you can run it with the current version just fine). It is entirely possible that you have a typo in your code that is causing the issue and what you looked at previously didn't have the typo. No hidden agenda needed. ```d void main() { double x = 85886696878585969769557975866955695.E0; } ```
Aug 05
prev sibling next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Friday, 5 August 2022 at 15:44:10 UTC, Steven Schveighoffer 
wrote:
 On 8/5/22 11:36 AM, Rumbu wrote:
 float z = 85886696878585969769557975866955695.E0; //integer 
 overflow, I don't see any int
That's an integer, which is trying to call a UFCS function named `E0`. Did you mean to include the `.`? -Steve
Either drop the `.` or drop the `E`.
Aug 05
prev sibling parent reply Max Samukha <maxsamukha gmail.com> writes:
On Friday, 5 August 2022 at 15:44:10 UTC, Steven Schveighoffer 
wrote:
 On 8/5/22 11:36 AM, Rumbu wrote:
 float z = 85886696878585969769557975866955695.E0; //integer 
 overflow, I don't see any int
That's an integer, which is trying to call a UFCS function named `E0`. Did you mean to include the `.`? -Steve
Both "123." and "123.E123" is valid C. For some reason, D only copied the former.
Aug 05
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/5/2022 9:43 AM, Max Samukha wrote:
 Both "123." and "123.E123" is valid C. For some reason, D only copied the
former.
It's to support UFCS (Universal Function Call Syntax). The idea with C compatible aspects of D is to not *silently* break code when there's a different meaning for it. And so, these generate an error message in D (although the error message could be much better). So, does it work with ImportC? test2.c: float z = 85886696878585969769557975866955695.E0; long double x = 0x1p-16383; dmd -c test2.c test2.c(3): Error: number `0x1p-16383` is not representable So the first one does compile as expected with ImportC. Let's try gcc and clang: gcc -c test2.c test2.c:3:1: warning: floating constant truncated to zero [-Woverflow] long double x = 0x1p-16383; ^ clang -c test.c test2.c:3:17: warning: magnitude of floating-point constant too small for type 'double'; minimum is 4.9406564584124654E-324 [-Wliteral-range] long double x = 0x1p-16383; aaaand, the truth comes out. It is not representable, it is truncated to 0. Technically, ImportC should accept it. But if it does, doesn't it mislead users into thinking it is non-zero? We've got the right choice here, but it's definitely a judgement call.
Aug 06
next sibling parent reply Tim <tim.dlang t-online.de> writes:
On Saturday, 6 August 2022 at 08:29:19 UTC, Walter Bright wrote:
 On 8/5/2022 9:43 AM, Max Samukha wrote:
 Both "123." and "123.E123" is valid C. For some reason, D only 
 copied the former.
It's to support UFCS (Universal Function Call Syntax). The idea with C compatible aspects of D is to not *silently* break code when there's a different meaning for it. And so, these generate an error message in D (although the error message could be much better).
It could silently break code if the right function is defined. The following example is valid in C and D (except import/include), but prints a different value: ```D // #include <stdio.h> import core.stdc.stdio; int E2(int i) { return i; } int main() { float f = 123.E2; printf("%f\n", f); return 0; } ```
Aug 06
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/6/2022 2:02 AM, Tim wrote:
 It could silently break code if the right function is defined. The following 
 example is valid in C and D (except import/include), but prints a different
value:
 
 ```D
 // #include <stdio.h>
 import core.stdc.stdio;
 
 int E2(int i)
 {
      return i;
 }
 
 int main()
 {
      float f = 123.E2;
      printf("%f\n", f);
      return 0;
 }
Congrats, you got me there!
Aug 06
prev sibling next sibling parent reply Max Samukha <maxsamukha gmail.com> writes:
On Saturday, 6 August 2022 at 08:29:19 UTC, Walter Bright wrote:
 On 8/5/2022 9:43 AM, Max Samukha wrote:
 Both "123." and "123.E123" is valid C. For some reason, D only 
 copied the former.
It's to support UFCS (Universal Function Call Syntax).
UFCS could still be supported with the exception of functions named like exponents. (I am not advocating for it.)
 aaaand, the truth comes out. It is not representable, it is 
 truncated to 0. Technically, ImportC should accept it. But if 
 it does, doesn't it mislead users into thinking it is non-zero?

 We've got the right choice here, but it's definitely a 
 judgement call.
No objections to this.
Aug 06
next sibling parent Siemargl <inqnone gmail.com> writes:
On Saturday, 6 August 2022 at 11:08:05 UTC, Max Samukha wrote:
 On Saturday, 6 August 2022 at 08:29:19 UTC, Walter Bright wrote:
 On 8/5/2022 9:43 AM, Max Samukha wrote:
 Both "123." and "123.E123" is valid C. For some reason, D 
 only copied the former.
It's to support UFCS (Universal Function Call Syntax).
UFCS could still be supported with the exception of functions named like exponents. (I am not advocating for it.)
 aaaand, the truth comes out. It is not representable, it is 
 truncated to 0. Technically, ImportC should accept it. But if 
 it does, doesn't it mislead users into thinking it is non-zero?

 We've got the right choice here, but it's definitely a 
 judgement call.
No objections to this.
May be we need some warnings about ambiguity, but incompability with C in base things, as literals is not an option. Same code compiled different with ImportC but not D, ough.
Aug 06
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/6/2022 4:08 AM, Max Samukha wrote:
 UFCS could still be supported with the exception of functions named like 
 exponents. (I am not advocating for it.)
We could, and enter the inevitable bug report from the baffled user who can't figure out why UFCS stopped working for his algorithm-generated function names. At some point, we just have to accept there's going to be a compromise.
Aug 06
prev sibling parent reply Rumbu <rumbu rumbu.ro> writes:
On Saturday, 6 August 2022 at 08:29:19 UTC, Walter Bright wrote:
 On 8/5/2022 9:43 AM, Max Samukha wrote:
 Both "123." and "123.E123" is valid C. For some reason, D only 
 copied the former.
It's to support UFCS (Universal Function Call Syntax). The idea with C compatible aspects of D is to not *silently* break code when there's a different meaning for it. And so, these generate an error message in D (although the error message could be much better). So, does it work with ImportC? test2.c: float z = 85886696878585969769557975866955695.E0; long double x = 0x1p-16383; dmd -c test2.c test2.c(3): Error: number `0x1p-16383` is not representable
It is. Since real exponent is biased by 16383 (15 bits), it is equivalent of all exponent bits set to 0. Probably it looks unimportant, but here it was about a floating point library. Subnormal values are part of the floating point standard.
 So the first one does compile as expected with ImportC. Let's 
 try gcc and clang:

 gcc -c test2.c
   test2.c:3:1: warning: floating constant truncated to zero 
 [-Woverflow]
    long double x = 0x1p-16383;
    ^

 clang -c test.c
   test2.c:3:17: warning: magnitude of floating-point constant 
 too small for type 'double'; minimum is 4.9406564584124654E-324 
 [-Wliteral-range]
   long double x = 0x1p-16383;
Both gcc and clang are using 64 bits for long double by default. You need specific compiler flags to enable 80-bit (-mlong-double-80). Also the value needs a L suffix in clang to not be interpreted a classic double. Yes, it is truncated to 0, but is representable.
Aug 06
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 8/6/22 19:27, Rumbu wrote:
 On Saturday, 6 August 2022 at 08:29:19 UTC, Walter Bright wrote:
 On 8/5/2022 9:43 AM, Max Samukha wrote:
 Both "123." and "123.E123" is valid C. For some reason, D only copied 
 the former.
It's to support UFCS (Universal Function Call Syntax). The idea with C compatible aspects of D is to not *silently* break code when there's a different meaning for it. And so, these generate an error message in D (although the error message could be much better). So, does it work with ImportC? test2.c:   float z = 85886696878585969769557975866955695.E0;   long double x = 0x1p-16383; dmd -c test2.c   test2.c(3): Error: number `0x1p-16383` is not representable
It is. Since real exponent is biased by 16383 (15 bits), it is equivalent of all exponent bits set to 0. Probably it looks unimportant, but here it was about a floating point library. Subnormal values are part of the floating point standard.
Seems you should just use a long double/real literal? real x = 0x1p-16383L; // (works)
Aug 06
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/6/2022 1:29 PM, Timon Gehr wrote:
 Seems you should just use a long double/real literal?
 
 real x = 0x1p-16383L; // (works)
Looks like that settles it. (Why didn't I notice that? Sheesh!)
Aug 06
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 07/08/2022 10:45 AM, Walter Bright wrote:
 On 8/6/2022 1:29 PM, Timon Gehr wrote:
 Seems you should just use a long double/real literal?

 real x = 0x1p-16383L; // (works)
Looks like that settles it. (Why didn't I notice that? Sheesh!)
Needs a better error message. https://issues.dlang.org/show_bug.cgi?id=23284
Aug 06
prev sibling parent kdevel <kdevel vogtner.de> writes:
Good catch!

On Saturday, 6 August 2022 at 17:27:30 UTC, Rumbu wrote:
 [...]
   long double x = 0x1p-16383;

 dmd -c test2.c
   test2.c(3): Error: number `0x1p-16383` is not representable
It is.
But not in the double type and `0x1p-16383` is a double not a long double.
 [...]
 Also the value needs a L suffix in clang to not be interpreted 
 a classic double.
GCC is no exception and needs the `L` suffix, too. [1] [1] https://en.cppreference.com/w/cpp/language/floating_literal
Aug 06
prev sibling next sibling parent kdevel <kdevel vogtner.de> writes:
Hi Rumbu,

I appreciate your work.

On Friday, 5 August 2022 at 15:36:06 UTC, Rumbu wrote:
 [...]
 The last issues are generated by unpublished changes in the 
 parser:

 Examples:

 ```
 float z = 85886696878585969769557975866955695.E0; //integer
The latest compiler here on my local machine is 2.073.2 of 2017 (?): ``` $ dmd --version DMD64 D Compiler v2.073.2 Copyright (c) 1999-2016 by Digital Mars written by Walter Bright $ cat e0.d unittest { float z = 85886696878585969769557975866955695.E0; //integer overflow, I don't see any int real x = 0x1p-16383; //number `0x1p-16383` is not representable. It is, trust me. } $ dmd e0 e0.d(2): Error: integer overflow e0.d(3): Error: number '0x1p-16383' is not representable ```
Aug 05
prev sibling next sibling parent max haughton <maxhaton gmail.com> writes:
On Friday, 5 August 2022 at 15:36:06 UTC, Rumbu wrote:
 Hi,

 Sincerely I am tired to maintain my library with every change 
 made by D compiler. Mostly regressions. Bug reports are ignored 
 or challenged, I don't have time to argue.

 [...]
This is not the correct syntax for real literals. We can improve the error message but this is not new behaviour.
Aug 05
prev sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Friday, 5 August 2022 at 15:36:06 UTC, Rumbu wrote:
 The last issues are generated by unpublished changes in the 
 parser:

 Examples:

 ```d
 float z = 85886696878585969769557975866955695.E0; //integer 
 overflow, I don't see any int
 ```
The last version where this compiled successfully was D 2.057, released on December 13, 2011.
 ```d
 real x = 0x1p-16383; //number `0x1p-16383` is not 
 representable. It is, trust me.
 ```
The last version where this compiled successfully was D 0.116, released on March 7, 2005. Perhaps you may have had a bug in your test suite which caused these lines to not be compiled.
Aug 05
parent kdevel <kdevel vogtner.de> writes:
On Saturday, 6 August 2022 at 06:03:59 UTC, Vladimir Panteleev 
wrote:
 On Friday, 5 August 2022 at 15:36:06 UTC, Rumbu wrote:
 [...]
 The last version where this compiled successfully was D 0.116, 
 released on March 7, 2005.

 Perhaps you may have had a bug in your test suite which caused 
 these lines to not be compiled.
The file named intel.d was introduced with ``` commit b5b1458585b65b9072f907de4c3f09b1b4790e26 (tag: v0.9.1) Author: razvan.stefanescu <rumbu rumbu.ro> Date: Wed Jan 31 23:09:19 2018 +0200 a lot of changes ``` it seems that nobody, including me, ever executed `dub test`. Archiving and CI would be nice for packages registered with code.dlang.org.
Aug 06