Jump to page: 1 24  
Page
Thread overview
August 05

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

August 05

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

August 05

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.

August 05

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
August 05

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

August 05

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.

August 05

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.

August 05

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

August 05

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.

void main()
{
    double x = 85886696878585969769557975866955695.E0;
}
August 05

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.

« First   ‹ Prev
1 2 3 4