Re: Giving up
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.
Re: More fun with toStringz and the GC
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. -Steve
Re: Another Windows Bindings by win32metadata
On Sunday, 31 July 2022 at 02:46:47 UTC, godmyoh wrote: Hi everyone! I have been using the rumbu13's Windows Bindings (https://github.com/rumbu13/windows-d), but it does not work well with the latest metadata. So I have created my own bindings. https://github.com/godmyoh/windows-win32-d This is incomplete due to my lack of knowledge. Opinions are welcome!
Re: More fun with toStringz and the GC
On Friday, 5 August 2022 at 23:38:22 UTC, Steven Schveighoffer wrote: On 8/5/22 7:13 PM, jfondren wrote: On Friday, 5 August 2022 at 22:51:07 UTC, Don Allen wrote: My theory: because gc_protect2 is never referenced, I'm guessing that the compiler is optimizing away the storage of the returned pointer, the supporting evidence being what I said in the previous paragraph. Anyone have a better idea? A local variable definitely isn't enough: https://forum.dlang.org/thread/xchnfzvpmxgytqprb...@forum.dlang.org This package came of it: https://code.dlang.org/packages/keepalive Yes, but I will warn you, the compilers are smart buggers. I think someone came up with a case where this still doesn't keep it alive (been a while since I made that). The only true solution is to use `GC.addRoot` on the string and `GC.removeRoot` when you are done. Steve -- Thanks for this. But this time I *did* read the documentation, specifically this: Interfacing Garbage Collected Objects With Foreign Code The garbage collector looks for roots in: the static data segment the stacks and register contents of each thread the TLS (thread-local storage) areas of each thread any roots added by core.memory.GC.addRoot() or core.memory.GC.addRange() If the only pointer to an object is held outside of these areas, then the collector will miss it and free the memory. To avoid this from happening, either maintain a pointer to the object in an area the collector does scan for pointers; add a root where a pointer to the object is stored using core.memory.GC.addRoot() or core.memory.GC.addRange(). reallocate and copy the object using the foreign code's storage allocator or using the C runtime library's malloc/free. 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. Having a better version of C and C++ with a gc and the ability to directly call useful C/C++ libraries is a big D selling point, as far as I am concerned. It was a major motivation for the creation of Go. But getting the interaction between the GC and foreign functions properly documented is essential. Right now, there are bits and pieces of advice in the Language Reference, the Feature Overview, and the toStringz documentation and none of it tells you what you need to know. In fact, it does the opposite, telling you to do something (stick a pointer on the stack) that does not work, which leads to the "nasty bug" spoken of in the toStringz doc. When you waste a lot of a user's time with poor and inaccurate documentation, as this did mine, you are not making friends. I would advise fixing this asap. /Don
Re: More fun with toStringz and the GC
On 8/5/22 7:13 PM, jfondren wrote: On Friday, 5 August 2022 at 22:51:07 UTC, Don Allen wrote: My theory: because gc_protect2 is never referenced, I'm guessing that the compiler is optimizing away the storage of the returned pointer, the supporting evidence being what I said in the previous paragraph. Anyone have a better idea? A local variable definitely isn't enough: https://forum.dlang.org/thread/xchnfzvpmxgytqprb...@forum.dlang.org This package came of it: https://code.dlang.org/packages/keepalive Yes, but I will warn you, the compilers are smart buggers. I think someone came up with a case where this still doesn't keep it alive (been a while since I made that). The only true solution is to use `GC.addRoot` on the string and `GC.removeRoot` when you are done. -Steve
Re: More fun with toStringz and the GC
On Friday, 5 August 2022 at 22:51:07 UTC, Don Allen wrote: My theory: because gc_protect2 is never referenced, I'm guessing that the compiler is optimizing away the storage of the returned pointer, the supporting evidence being what I said in the previous paragraph. Anyone have a better idea? A local variable definitely isn't enough: https://forum.dlang.org/thread/xchnfzvpmxgytqprb...@forum.dlang.org This package came of it: https://code.dlang.org/packages/keepalive
More fun with toStringz and the GC
Remember all the fun we had last year when I failed to heed the
warning in the toStringz documentation about retaining a
reference to a char * passed into C? It took a long time to find
that one, with a lot of help from Steve Schveighoffer and others.
Well, I've got another one. Consider this:
// Get number of children of the parent account
auto gc_protect = bind_text(n_children_stmt, 1,
parent.guid);
parent.children.length = one_row!(int)(n_children_stmt,
_int);
auto gc_protect2 = bind_text(account_child_stmt, 1,
parent.guid);
for (int i = 0; next_row_available_p(account_child_stmt,
_reset); i++) {
parent.children[i] = new Account;
parent.children[i].name =
fromStringz(sqlite3_column_text(account_child_stmt, 0)).idup;
parent.children[i].guid =
fromStringz(sqlite3_column_text(account_child_stmt, 1)).idup;
parent.children[i].flags =
sqlite3_column_int(account_child_stmt, 2);
parent.children[i].value =
get_account_value(parent.children[i]);
}
bind_text takes a D string, turns it into a C string with
toStringz, uses that to call sqlite3_bind_text and returns the C
string, which I store as you can see with the intention of
protecting it from the gc. The code as written above does not
work. At some point, I get an index-out-of-bounds error, because
the loop is seeing too many children. If I turn off the GC, the
code works correctly and the application completes normally.
With the GC on, if I put a debugging writeln inside the loop,
right after the 'for', that prints, among other things, the value
of gc_protect2 (I wanted to convince myself that the GC wasn't
moving what it points to; yes, I know the documentation says the
current GC won't do that), the problem goes away. A Heisenbug!
My theory: because gc_protect2 is never referenced, I'm guessing
that the compiler is optimizing away the storage of the returned
pointer, the supporting evidence being what I said in the
previous paragraph. Anyone have a better idea?
By the way, I get the same error compiling this with dmd or ldc.
/Don Allen
Re: Giving up
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?
Re: Giving up
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.
Re: Giving up
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.
Re: Giving up
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.)
Re: Giving up
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
Re: Giving up
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.
Re: Giving up
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.
Re: Giving up
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;
}
```
Re: Giving up
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
Re: Giving up
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.
Re: Giving up
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`.
Re: Giving up
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
Re: Giving up
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
```
Re: Giving up
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.
Re: Giving up
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
Giving up
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
