Menu
Search

Forums

Forum Index

August 05, 2022
Gravatar of RumbuPosted by Rumbu
in reply to Steven Schveighoffer		Reply
Rumbu
Gravatar of Rumbu
Posted in reply to Steven Schveighoffer


Reply

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.

August 05, 2022
Gravatar of Steven SchveighofferPosted by Steven Schveighoffer
in reply to Rumbu		Reply
Steven Schveighoffer
Gravatar of Steven Schveighoffer
Posted in reply to Rumbu


Reply

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

August 05, 2022
Gravatar of bachmeierPosted by bachmeier
in reply to Steven Schveighoffer		Reply
bachmeier
Gravatar of bachmeier
Posted in reply to Steven Schveighoffer


Reply

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.)

August 05, 2022
Gravatar of bachmeierPosted by bachmeier
in reply to bachmeier		Reply
bachmeier
Gravatar of bachmeier
Posted in reply to bachmeier


Reply

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.

August 05, 2022
Gravatar of max haughtonPosted by max haughton
in reply to Rumbu		Reply
max haughton
Gravatar of max haughton
Posted in reply to Rumbu


Reply

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.

August 05, 2022
Gravatar of mwPosted by mw
in reply to bachmeier		Reply
mw
Gravatar of mw
Posted in reply to bachmeier


Reply

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?

August 06, 2022
Gravatar of bachmeierPosted by bachmeier
in reply to mw		Reply
bachmeier
Gravatar of bachmeier
Posted in reply to mw


Reply
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.
August 06, 2022
Gravatar of Vladimir PanteleevPosted by Vladimir Panteleev
in reply to Rumbu		Reply
Vladimir Panteleev
Gravatar of Vladimir Panteleev
Posted in reply to Rumbu


Reply

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 overflow, I don't see any int

The last version where this compiled successfully was D 2.057, released on December 13, 2011.

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

August 06, 2022
Gravatar of Walter BrightPosted by Walter Bright
in reply to Max Samukha		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Max Samukha


Reply
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.
August 06, 2022
Gravatar of TimPosted by Tim
in reply to Walter Bright		Reply
Tim
Gravatar of Tim
Posted in reply to Walter Bright


Reply

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:

// #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;
}
« First   ‹ Prev
1 2 3 4
Next ›   Last »