Re: Counting an initialised array, and segments
```
import std;
auto arr = [dchar(' '), '\t', 0x0a, 0x10];
void main()
{
writeln("Hello D: ", typeid(arr));
}
```
Re: Warning The package will no longer be detected starting from v1.42.0
On Sunday, 25 June 2023 at 12:21:52 UTC, Mathias LANG wrote: On Sunday, 25 June 2023 at 04:50:42 UTC, Soulsbane wrote: I'm guessing it's caused by this https://github.com/dlang/dub/pull/2610. What's the fix for this exactly? Thanks! A fix would be to do the following: ``` for package in $($HOME/Projects/D/libs/*); do mv -v $package $package/master/$(basename $package) done ``` Provided that all you have in your `libs` folder are folders that represent packages. This would also allow you to use different versions of a library (I'm assuming you only have one, hence the `master`), and work with libraries like Cybershadow's `ae`. However, I'm not sure we should expect our users to do this for a simple `add-path`. Yeah, each folder under libs is a package and it's own git repository. I think I'll just use the add-local approach. Kind of a pain but getting spammed with a page of warnings every compile is getting tiring :). Thanks a lot for the help Rikki and Mathias
Counting an initialised array, and segments
I recently had some problems dchar[] arr = [ ‘ ‘, TAB, CR, LF … ]; and I got errors from the compiler which led to me having to count the elements in the initialiser and declare the array with an explicit size. I don’t want the array to be mutable so I later added immutable to it, but that didn’t help matters. At one point, because the array was quite long, I got the arr[ n_elements ] number wrong, it was too small and the remainder of the array was full of 0xffs (or something), which was good, helped me spot the bug. Is there any way to get the compiler to count the number of elements in the initialiser and set the array to that size ? And it’s immutable. The only reason that I’m giving it a name is that I want the object to be used in several places and I don’t want multiple copies of it in the code/readonly initialised data segment. Another couple of unrelated questions: is there such a thing as a no-execute initialised readonly data segment? I’m seeing immutables going into the code segment, I think, with x86 LDC at least, can’t remember about GDC. Anyway on x86-64 immutables are addressed as [rip + displ] which is very pleasing as it’s vastly more efficient than accessing statics in TLS which seems to be a nightmare in Linux at least. In MS Windows, isn’t TLS dealt with using FS: ( or GS: ?) prefixes? Shame this doesn’t seem to be exploited in Linux, or am I wrong? I’d like to deal with the overhead of retrieving the static base address all the time in the Linux situation (if I have got the right end of the stick) but having an ‘application object’ which contains all the statics in a struct in an alloc cell or something, and passing a pointer to this static base app object everywhere seems a nightmare too as it eats a register and worse eats one of the limited number of precious function argument registers which are in short supply in eg x86-64, where there are less than half a dozen argument registers allowed. I realise that one can deal with that limited number by rolling some passed arguments up into a passed struct, but that’s introducing a level of indirection and other overhead, that or just live with the fact that the extra args are going into the stack, which isn’t the worst thing in the world. I wonder what others do about statics in TLS?
Re: Large statics
On Sunday, 25 June 2023 at 21:08:13 UTC, Ali Çehreli wrote: On 6/25/23 13:41, Cecil Ward wrote: > The docs say that there is a limit on the size of large statics Customers (at least Weka) did request larger statics in the past. Since they use LDC, the limit was removed for LDC. I did not try it. :) Ali Ah, I did not know that, many thanks, I’m using LDC and GDC. A wishlist for the docs on the website would be to have them mention, and link to additional documentation regarding GDC and LDC, not just DMD. The docs should mainly be about the D language not solely about the DMD compiler.
Re: Large statics
On 6/25/23 13:41, Cecil Ward wrote: > The docs say that there is a limit on the size of large statics Customers (at least Weka) did request larger statics in the past. Since they use LDC, the limit was removed for LDC. I did not try it. :) Ali
Large statics
The docs say that there is a limit on the size of large statics of 16 MB. Is it desirable to remove this limit ? I realise that with new code there is the option to alloc the space instead where the static is uninitialised. There are other possibilities, such as an object filled with compile-time generated data maybe. The documentation also points out the crazy but understandable bloat on the exe size. Is it possible to place a large object in BSS by using ubyte arr[ enormous ] = void;
Re: Warning The package will no longer be detected starting from v1.42.0
On Sunday, 25 June 2023 at 04:50:42 UTC, Soulsbane wrote: I'm guessing it's caused by this https://github.com/dlang/dub/pull/2610. What's the fix for this exactly? Thanks! A fix would be to do the following: ``` for package in $($HOME/Projects/D/libs/*); do mv -v $package $package/master/$(basename $package) done ``` Provided that all you have in your `libs` folder are folders that represent packages. This would also allow you to use different versions of a library (I'm assuming you only have one, hence the `master`), and work with libraries like Cybershadow's `ae`. However, I'm not sure we should expect our users to do this for a simple `add-path`.
Re: Warning The package will no longer be detected starting from v1.42.0
Unfortunately yes, this appears to be an unintended side effect of that PR. The search paths in dub are all implemented together, one set of logic. So add-path probably was never doing what was expected of it. You will need to switch to add-local for each package, unless you want to work on dub :)
