importC | Using D with Raylib directly | No bindings | [video]
Testing out importC with Raylib. Here is the [link](https://www.youtube.com/watch?v=1BrvRkZdGOA).
Re: Giving up
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
Re: Giving up
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?
Re: Giving up
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
Re: Giving up
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
Re: Giving up
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!)
Re: Giving up
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
Re: Giving up
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)
Re: Giving up
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.
Re: More fun with toStringz and the GC
On Saturday, 6 August 2022 at 13:40:12 UTC, Don Allen wrote: On Saturday, 6 August 2022 at 02:14:24 UTC, Steven Schveighoffer wrote: On 8/5/22 8:51 PM, Don Allen wrote: And this, from Section 32.2 of the Language Reference Manual: If pointers to D garbage collector allocated memory are passed to C functions, it's critical to ensure that the memory will not be collected by the garbage collector before the C function is done with it. This is accomplished by: Making a copy of the data using core.stdc.stdlib.malloc() and passing the copy instead. -->Leaving a pointer to it on the stack (as a parameter or automatic variable), as the garbage collector will scan the stack.<-- Leaving a pointer to it in the static data segment, as the garbage collector will scan the static data segment. Registering the pointer with the garbage collector with the std.gc.addRoot() or std.gc.addRange() calls. I did what the documentation says and it does not work. I know, I felt exactly the same way in my post on it: https://forum.dlang.org/post/sial38$7v0$1...@digitalmars.com I even issued a PR to remove the problematic recommendation: https://github.com/dlang/dlang.org/pull/3102 But there was pushback to the point where it wasn't worth it. So I closed it. As I said in my previous post, the documentation issue really needs to be addressed. I do realize now that I *assumed* that what I did was going to result in a stack reference to the c-string I was trying to keep alive. At the risk of over-doing this, one more thing I want to say in the interest of clarity: the incorrect documentation led me right into this error: "This is accomplished by . Leaving a pointer to it on the stack (as a parameter or automatic variable), as the garbage collector will scan the stack." I've fixed my code using addRoot/removeRoot and so far it seems to work.
Re: More fun with toStringz and the GC
On Saturday, 6 August 2022 at 02:14:24 UTC, Steven Schveighoffer wrote: On 8/5/22 8:51 PM, Don Allen wrote: And this, from Section 32.2 of the Language Reference Manual: If pointers to D garbage collector allocated memory are passed to C functions, it's critical to ensure that the memory will not be collected by the garbage collector before the C function is done with it. This is accomplished by: Making a copy of the data using core.stdc.stdlib.malloc() and passing the copy instead. -->Leaving a pointer to it on the stack (as a parameter or automatic variable), as the garbage collector will scan the stack.<-- Leaving a pointer to it in the static data segment, as the garbage collector will scan the static data segment. Registering the pointer with the garbage collector with the std.gc.addRoot() or std.gc.addRange() calls. I did what the documentation says and it does not work. I know, I felt exactly the same way in my post on it: https://forum.dlang.org/post/sial38$7v0$1...@digitalmars.com I even issued a PR to remove the problematic recommendation: https://github.com/dlang/dlang.org/pull/3102 But there was pushback to the point where it wasn't worth it. So I closed it. As I said in my previous post, the documentation issue really needs to be addressed. I do realize now that I *assumed* that what I did was going to result in a stack reference to the c-string I was trying to keep alive. Bad assumption, obviously. But I think the point is that there is a simple, reliable mechanism -- addRoot, removeRoot -- that works and the documentation should say that and only that. Walter said this in his 9/25/21 post: "Use GC.addRoot() to keep a reference alive. That's what it's for. ". That's all that's needed. All the rest leads people like me who don't think like a compiler to make the mistake I made.
Re: More fun with toStringz and the GC
On Fri, Aug 05, 2022 at 10:14:24PM -0400, Steven Schveighoffer via Digitalmars-d-announce wrote: > On 8/5/22 8:51 PM, Don Allen wrote: > > > And this, from Section 32.2 of the Language Reference Manual: > > > > If pointers to D garbage collector allocated memory are passed to C > > functions, it's critical to ensure that the memory will not be > > collected by the garbage collector before the C function is done > > with it. This is accomplished by: > > > > Making a copy of the data using core.stdc.stdlib.malloc() and > > passing the copy instead. > > -->Leaving a pointer to it on the stack (as a parameter or > > automatic variable), as the garbage collector will scan the stack.<-- > > Leaving a pointer to it in the static data segment, as the garbage > > collector will scan the static data segment. > > Registering the pointer with the garbage collector with the > > std.gc.addRoot() or std.gc.addRange() calls. > > > > I did what the documentation says and it does not work. > > I know, I felt exactly the same way in my post on it: > > https://forum.dlang.org/post/sial38$7v0$1...@digitalmars.com > > I even issued a PR to remove the problematic recommendation: > > https://github.com/dlang/dlang.org/pull/3102 > > But there was pushback to the point where it wasn't worth it. So I > closed it. [...] IMO this PR should be revived. The one thing worse than no documentation is misleading documentation. This state of things should not be allowed to continue. T -- Study gravitation, it's a field with a lot of potential.
Re: Giving up
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.
Re: Giving up
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.) nd, 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.
Re: Giving up
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.) nd, 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.
Re: Giving up
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
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!
Re: Giving up
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 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.
Re: Giving up
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
import core.stdc.stdio;
int E2(int i)
{
return i;
}
int main()
{
float f = 123.E2;
printf("%f\n", f);
return 0;
}
```
Re: Giving up
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; nd, 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.
Re: Giving up
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.
