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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022
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 2022