Re: Strange behaviour of rdmd vs. dmd concerning main function
$> dmd Special/special.d Common/common.o Special/special.d(4): Error: module common is in file 'common.d' which cannot be read import path[0] = /usr/include/dmd/phobos import path[1] = /usr/include/dmd/druntime/import This is not a linker error. It's a compiler error. You need common.d for the import, so the compiler can know which symbols are available. For any modules you import, you need either the original source file (.d) or a D interface (header) file (.di) which contains the type & function declarations and any template implementations you need. That worked. With "dmd -c -Hd=Common Common/common.d" I created a common.di file then I removed the common.d and could compile with "dmd -ICommon Special/special.d Common/common.o". With this, common.d does not need to be recompiled a lot of times if there are several special.d-files. Thank you!
Re: Initialization of dynamic multidimensional array
On Tuesday, 7 February 2017 at 19:06:22 UTC, berni wrote: auto arr = uninitializedArray!(int[][])(ROWS,COLS); arr.each!"a[]=-1"; This looks like what I was looking for. At least I think I understand what's going on here. The other two suggestions are beyond my scope yet, but I'll come back, when I improved on my D skills. Thanks for your replies. Now I tried this with a named instead of a magic constant e.g. immutable VALUE=-1; arr.each!"a[]=VALUE"; And it doesn't work anymore. I've no clue, why... Can you help me?
Re: Initialization of dynamic multidimensional array
Dne 10.2.2017 v 10:03 berni via Digitalmars-d-learn napsal(a): On Tuesday, 7 February 2017 at 19:06:22 UTC, berni wrote: auto arr = uninitializedArray!(int[][])(ROWS,COLS); arr.each!"a[]=-1"; This looks like what I was looking for. At least I think I understand what's going on here. The other two suggestions are beyond my scope yet, but I'll come back, when I improved on my D skills. Thanks for your replies. Now I tried this with a named instead of a magic constant e.g. immutable VALUE=-1; arr.each!"a[]=VALUE"; And it doesn't work anymore. I've no clue, why... Can you help me? Because it does not see VALUE, you need to use delegate insted of string something like this: arr.each!(a=>a[]=VALUE);
Re: Initialization of dynamic multidimensional array
On Friday, 10 February 2017 at 09:03:16 UTC, berni wrote: Now I tried this with a named instead of a magic constant e.g. immutable VALUE=-1; arr.each!"a[]=VALUE"; And it doesn't work anymore. I've no clue, why... Can you help me? each is a template. As per the template documentation [1], your instantiation of each knows nothing about VALUE, because VALUE declared in the scope in which the template is instantiated. Template instantiations only have the scope in which they are implemented, not where they are instantiated, so here each cannot see VALUE. On an side note (unrelated to your error), when declaring constants that are intended to be symbolic (i.e. you never need to take their address), it's more idiomatic to use manifest constants (via enum) rather than immutable. enum value = -1; [1] https://dlang.org/spec/template.html#instantiation_scope
Re: Initialization of dynamic multidimensional array
On Friday, 10 February 2017 at 09:25:04 UTC, Daniel Kozak wrote: Now I tried this with a named instead of a magic constant e.g. immutable VALUE=-1; arr.each!"a[]=VALUE"; And it doesn't work anymore. I've no clue, why... Can you help me? Because it does not see VALUE, you need to use delegate insted of string something like this: arr.each!(a=>a[]=VALUE); Unfortunately this leeds to the same error... (Or something very simmilar.)
Re: Initialization of dynamic multidimensional array
On Friday, 10 February 2017 at 09:34:39 UTC, berni wrote: On Friday, 10 February 2017 at 09:25:04 UTC, Daniel Kozak wrote: Now I tried this with a named instead of a magic constant e.g. immutable VALUE=-1; arr.each!"a[]=VALUE"; And it doesn't work anymore. I've no clue, why... Can you help me? Because it does not see VALUE, you need to use delegate insted of string something like this: arr.each!(a=>a[]=VALUE); Unfortunately this leeds to the same error... (Or something very simmilar.) Opps, sorry. Taking back everything. It was a typo, that caused the error.
std.datetime
unittest
{
import std.datetime : SysTime, UTC;
{
auto st = SysTime();
st.timezone(UTC());
long date =
st.fromISOExtString("2017-02-10T00:00:00Z").stdTime,
time_of_day =
st.fromISOExtString("-01-01T23:59:50Z").stdTime,
timestamp =
st.fromISOExtString("-01-01T23:59:55Z").stdTime;
import std.stdio;
st.stdTime(date);
writeln(st);
st.stdTime(timestamp);
writeln(st);
st.stdTime(date+timestamp);
writeln(st);
}
}
prints
```
2017-Feb-10 00:00:00Z
-Jan-01 23:59:55Z
2016-Feb-10 23:59:55Z
```
I expect
```
2017-Feb-10 00:00:00Z
-Jan-01 23:59:55Z
2017-Feb-10 23:59:55Z
```
Why does it decrement years? What do I do wrong?
Why do static arrays affect executable size?
// enum int maxarray = 0;
enum int maxarray = 2_000_000;
double[maxarray] a, b, c, d;
void main() {}
Compiled using "dub build --arch=x86_64 --build=release" on
Windows (DMD32 D Compiler v2.073.0), the exe size is 302_592
bytes v.s. 64_302_592 bytes, depending on the array length.
Is that normal?
Re: Why do static arrays affect executable size?
On Friday, 10 February 2017 at 11:21:48 UTC, Bastiaan Veelo wrote:
// enum int maxarray = 0;
enum int maxarray = 2_000_000;
double[maxarray] a, b, c, d;
void main() {}
Compiled using "dub build --arch=x86_64 --build=release" on
Windows (DMD32 D Compiler v2.073.0), the exe size is 302_592
bytes v.s. 64_302_592 bytes, depending on the array length.
Is that normal?
Yes.
Re: Can this implementation of Damm algorithm be optimized?
On Thursday, 9 February 2017 at 23:49:19 UTC, Era Scarecrow wrote: Other optimizations could be to make it multiple levels, taking the basic 100 elements and expanding them 2-3 levels deep in a lookup and having it do it in more or less a single operation. (100 bytes for 1 level, 10,000 for 2 levels, 1,000,000 for 3 levels, 100,000,000 for 4 levels, etc), but the steps of converting it to the array lookup won't give you that much gain, although fewer memory lookups but none of them will be cached, so any advantage from that is probably lost. Although if you bump up the size to 16x10 instead of 10x10, you could use a shift instead of *10 which will make that slightly faster (there will be unused empty padded spots) In theory if you avoid the memory lookup at all, you could gain some amount of speed, depending on how it searches a manual table, although using a switch-case and a mixin to do all the details it feels like it wouldn't give you any gain... Thank you for the detailed reply. I wasn't able to follow you regarding the multilevel stuff though :(
Re: std.datetime
10.02.2017 14:15, drug пишет:
unittest
{
import std.datetime : SysTime, UTC;
{
auto st = SysTime();
st.timezone(UTC());
long date = st.fromISOExtString("2017-02-10T00:00:00Z").stdTime,
time_of_day =
st.fromISOExtString("-01-01T23:59:50Z").stdTime,
timestamp =
st.fromISOExtString("-01-01T23:59:55Z").stdTime;
import std.stdio;
st.stdTime(date);
writeln(st);
st.stdTime(timestamp);
writeln(st);
st.stdTime(date+timestamp);
writeln(st);
}
}
prints
```
2017-Feb-10 00:00:00Z
-Jan-01 23:59:55Z
2016-Feb-10 23:59:55Z
```
I expect
```
2017-Feb-10 00:00:00Z
-Jan-01 23:59:55Z
2017-Feb-10 23:59:55Z
```
Why does it decrement years? What do I do wrong?
I found error - years should start from 1, not 0.
But if months or days start from 0 std.datetime throws exception and
don't for years - it isn't clear that zero year is negative one (in that
mean that stdTime for '' years will be negative.
Why is for() less efficient than foreach?
Benchmarking for() against foreach():
/
enum size_t maxarray = 500_000;
double[maxarray] a, b, c, d;
void main()
{
import std.stdio;
import std.datetime;
import std.random;
for (int n = 0; n < maxarray; n++)
{
a[n] = uniform01;
b[n] = uniform01;
c[n] = uniform01 + 0.1;
}
void overhead() {}
void foreach_loop()
{
foreach(n, elem; d[])
elem = a[n] * b[n] / c[n];
}
void for_loop()
{
for (int n = 0; n < maxarray; n++)
d[n] = a[n] * b[n] / c[n];
}
auto r = benchmark!(overhead,
foreach_loop,
for_loop)(10_000);
import std.conv : to;
foreach (i, d; r)
writeln("Function ", i, " took: ", d.to!Duration);
}
/
Depending on the machine this is run on, for() performs a factor
3-8 slower than foreach(). Can someone explain this to me? Or,
taking for() as the norm, how can foreach() be so blazingly fast?
Thanks!
Re: Why is for() less efficient than foreach?
On Friday, 10 February 2017 at 12:39:50 UTC, Bastiaan Veelo wrote:
void foreach_loop()
{
foreach(n, elem; d[])
elem = a[n] * b[n] / c[n];
}
It's fast because the result of the operation (elem) is discarded
on each iteration, so it is probably optimized away.
Try:
```
void foreach_loop()
{
foreach(n, ref elem; d[])
elem = a[n] * b[n] / c[n];
}
```
You can also do:
```
d = a[] * b[] / c[];
```
with no loop statement at all.
Re: Why is for() less efficient than foreach?
On Friday, 10 February 2017 at 12:39:50 UTC, Bastiaan Veelo wrote:
Benchmarking for() against foreach():
/
enum size_t maxarray = 500_000;
double[maxarray] a, b, c, d;
void main()
{
import std.stdio;
import std.datetime;
import std.random;
for (int n = 0; n < maxarray; n++)
{
a[n] = uniform01;
b[n] = uniform01;
c[n] = uniform01 + 0.1;
}
void overhead() {}
void foreach_loop()
{
foreach(n, elem; d[])
elem = a[n] * b[n] / c[n];
}
void for_loop()
{
for (int n = 0; n < maxarray; n++)
d[n] = a[n] * b[n] / c[n];
}
auto r = benchmark!(overhead,
foreach_loop,
for_loop)(10_000);
import std.conv : to;
foreach (i, d; r)
writeln("Function ", i, " took: ", d.to!Duration);
}
/
Depending on the machine this is run on, for() performs a
factor 3-8 slower than foreach(). Can someone explain this to
me? Or, taking for() as the norm, how can foreach() be so
blazingly fast?
Thanks!
The foreach loop behaves differently.
It does not modify d.
If you want it to modify the array you have to use a ref elem.
If you do you will see that foreach is a little slower.
Re: Why is for() less efficient than foreach?
On Friday, 10 February 2017 at 12:39:50 UTC, Bastiaan Veelo wrote: Depending on the machine this is run on, for() performs a factor 3-8 slower than foreach(). Can someone explain this to me? Or, taking for() as the norm, how can foreach() be so blazingly fast? Thanks! On my machine (AMD FX-8350) actually almost no difference DMD 2.073 dmd -run loops.d -release Function 0 took: 16 ╬╝s and 5 hnsecs Function 1 took: 57 secs, 424 ms, and 555 ╬╝s Function 2 took: 53 secs, 494 ms, 709 ╬╝s, and 8 hnsecs LDC 1.1.0-beta6 ldc2 -run loops.d -release -o3 Using Visual C++: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC Function 0 took: 25 ╬╝s and 5 hnsecs Function 1 took: 53 secs, 253 ╬╝s, and 8 hnsecs Function 2 took: 56 secs, 76 ms, 656 ╬╝s, and 4 hnsecs
Re: Why is for() less efficient than foreach?
On Friday, 10 February 2017 at 13:13:24 UTC, evilrat wrote: On my machine (AMD FX-8350) actually almost no difference oops, it skips flags with -run -_- sorry dmd loops.d -release Function 0 took: 16 ╬╝s and 5 hnsecs Function 1 took: 55 secs, 262 ms, 844 ╬╝s, and 6 hnsecs Function 2 took: 56 secs, 564 ms, 231 ╬╝s, and 6 hnsecs ldc2 loops.d -release Function 0 took: 25 ╬╝s and 5 hnsecs Function 1 took: 46 secs, 757 ms, 889 ╬╝s, and 7 hnsecs Function 2 took: 23 secs, 895 ms, 410 ╬╝s, and 3 hnsecs dmd loops.d -m64 -release Function 0 took: 24 ╬╝s and 7 hnsecs Function 1 took: 27 secs, 752 ms, 952 ╬╝s, and 5 hnsecs Function 2 took: 36 secs, 550 ms, 295 ╬╝s, and 4 hnsecs ldc2 loops.d -m64 -release Function 0 took: 25 ╬╝s Function 1 took: 47 secs, 456 ms, 65 ╬╝s, and 4 hnsecs Function 2 took: 26 secs, 583 ms, 880 ╬╝s, and 1 hnsec setting LDC with any optimization flags completely removes empty call and for loop.
Re: Why is for() less efficient than foreach?
On Friday, 10 February 2017 at 12:57:38 UTC, biozic wrote:
On Friday, 10 February 2017 at 12:39:50 UTC, Bastiaan Veelo
wrote:
void foreach_loop()
{
foreach(n, elem; d[])
elem = a[n] * b[n] / c[n];
}
It's fast because the result of the operation (elem) is
discarded on each iteration, so it is probably optimized away.
Try:
```
void foreach_loop()
{
foreach(n, ref elem; d[])
elem = a[n] * b[n] / c[n];
}
```
Hah, of course.
You can also do:
```
d = a[] * b[] / c[];
```
with no loop statement at all.
Nice.
Thanks.
Re: Why is for() less efficient than foreach?
On Friday, 10 February 2017 at 12:58:19 UTC, Stefan Koch wrote: If you want it to modify the array you have to use a ref elem. If you do you will see that foreach is a little slower. Thanks, I should have spotted that. Bastiaan.
Re: std.datetime
On Friday, February 10, 2017 14:35:28 drug via Digitalmars-d-learn wrote: > I found error - years should start from 1, not 0. > But if months or days start from 0 std.datetime throws exception and > don't for years - it isn't clear that zero year is negative one (in that > mean that stdTime for '' years will be negative. As the documentation states in multiple places, std.datetime follows ISO 8601, which uses the Proleptic Gregorian Calendar, and that specifies that the year 0 is equivalent to what you would normall consider to be 1 B.C. And that's part of the spec for the ISO extended format that fromISOExtString uses. Now, while it is mentioned in multiple places that std.datetime follows ISO 8601 and that it follows the Proleptic Gregorian Calender (even providing a link to wikipedia), it does look like it fails to specifically mention that on the primary ddoc comment of SysTime. So, that should be improved. However, the documentation for SysTime.year does state that positive years are A.D., whereas non-positive are B.C. So, the information is there, even without having to look up the Proleptic Gregorian Calender or ISO 8601. What would have made it clearer for you? - Jonathan M Davis
Re: Why do static arrays affect executable size?
On Friday, February 10, 2017 11:21:48 Bastiaan Veelo via Digitalmars-d-learn
wrote:
> // enum int maxarray = 0;
> enum int maxarray = 2_000_000;
>
> double[maxarray] a, b, c, d;
>
> void main() {}
>
>
> Compiled using "dub build --arch=x86_64 --build=release" on
> Windows (DMD32 D Compiler v2.073.0), the exe size is 302_592
> bytes v.s. 64_302_592 bytes, depending on the array length.
>
> Is that normal?
Module-level and static variables all get put in the executable. So,
declaring a static array like that is going to take up space. A dynamic
array would do the same thing if you gave it a value of that size. The same
thing happens with global and static variables in C/C++.
Similarly, even with a local variable that's a static or dynamic array, if
you use a literal to initialize it, that literal has to be put in the
executable, increasing its size. But the nature of module-level or global
variables is such that even if they're not explicitly assigned a value, they
take up space.
- Jonathan M Davis
Re: std.datetime
10.02.2017 18:02, Jonathan M Davis via Digitalmars-d-learn пишет: On Friday, February 10, 2017 14:35:28 drug via Digitalmars-d-learn wrote: I found error - years should start from 1, not 0. But if months or days start from 0 std.datetime throws exception and don't for years - it isn't clear that zero year is negative one (in that mean that stdTime for '' years will be negative. As the documentation states in multiple places, std.datetime follows ISO 8601, which uses the Proleptic Gregorian Calendar, and that specifies that the year 0 is equivalent to what you would normall consider to be 1 B.C. And that's part of the spec for the ISO extended format that fromISOExtString uses. Now, while it is mentioned in multiple places that std.datetime follows ISO 8601 and that it follows the Proleptic Gregorian Calender (even providing a link to wikipedia), it does look like it fails to specifically mention that on the primary ddoc comment of SysTime. So, that should be improved. However, the documentation for SysTime.year does state that positive years are A.D., whereas non-positive are B.C. So, the information is there, even without having to look up the Proleptic Gregorian Calender or ISO 8601. What would have made it clearer for you? - Jonathan M Davis Is zero positive or negative? May be add statement that zero year is 1 B.C.? Thank you for your good job!
Re: std.datetime
On Friday, February 10, 2017 19:06:53 drug via Digitalmars-d-learn wrote: > 10.02.2017 18:02, Jonathan M Davis via Digitalmars-d-learn пишет: > > On Friday, February 10, 2017 14:35:28 drug via Digitalmars-d-learn wrote: > >> I found error - years should start from 1, not 0. > >> But if months or days start from 0 std.datetime throws exception and > >> don't for years - it isn't clear that zero year is negative one (in > >> that > >> mean that stdTime for '' years will be negative. > > > > As the documentation states in multiple places, std.datetime follows ISO > > 8601, which uses the Proleptic Gregorian Calendar, and that specifies > > that the year 0 is equivalent to what you would normall consider to be > > 1 B.C. And that's part of the spec for the ISO extended format that > > fromISOExtString uses. > > > > Now, while it is mentioned in multiple places that std.datetime follows > > ISO 8601 and that it follows the Proleptic Gregorian Calender (even > > providing a link to wikipedia), it does look like it fails to > > specifically mention that on the primary ddoc comment of SysTime. So, > > that should be improved. However, the documentation for SysTime.year > > does state that positive years are A.D., whereas non-positive are B.C. > > So, the information is there, even without having to look up the > > Proleptic Gregorian Calender or ISO 8601. > > > > What would have made it clearer for you? > > > > - Jonathan M Davis > > Is zero positive or negative? May be add statement that zero year is 1 > B.C.? Thank you for your good job! Neither. It's zero. That's why the documentation says that B.C. is non-positive - non-positive encompasses all of the negative numbers plus zero. And on yearBC, it does say that 0 is treated as 1 B.C. year doesn't mention that, but it's right above yearBC in the docs. It should probably link to yearBC though to make that clearer. B.C. does get kind of wonky though, since mathematically, it pretty much _has_ to be the case that 1 B.C. is 0 unless you just skip 0 (since otherwise all of the A.D. years get shifted by one, and then the years that most everyone uses would be shifted by one - e.g. 2017 would become 2016, which obviously doesn't work). And skipping 0 - as is done when normally talking about A.D. and B.C. - is just plain messy mathematically, just like trying to deal with the switch between the Julian and Gregorian calendars is a mess (even without getting into the issues related to different regions switching calendars at different times) - which is why ISO 8601 uses the Proleptic Gregorian Calendar, making it Gregorian the whole way. It's very mathematically neat, but it then runs afoul of how folks normally think of dates in the B.C. range. So, ultimately, it seems to be the best of a variety of bad answers to the problem. I suppose that we could have gone C#'s route, since they use the Proleptic Gregorian Calender but didn't implement B.C. But then that gets pretty weird when you have 0 hnsecs be the default value, since once you have time zones west of UTC, you suddenly end up with them being in B.C., and if you don't have B.C... I ported std.datetime to C++ once where I was working, and I tried to strip out stuff like B.C. thinking that it would make the code simpler, and it actually made it worse. So, yeah, it's just messy all around. Fortunately, most code doesn't actually care about dates that far back, and for the code that does, there's yearBC for anyone who wants a date that looks more familiar. - Jonathan M Davis
Re: std.datetime
10.02.2017 19:31, Jonathan M Davis via Digitalmars-d-learn пишет: On Friday, February 10, 2017 19:06:53 drug via Digitalmars-d-learn wrote: 10.02.2017 18:02, Jonathan M Davis via Digitalmars-d-learn пишет: On Friday, February 10, 2017 14:35:28 drug via Digitalmars-d-learn wrote: I found error - years should start from 1, not 0. But if months or days start from 0 std.datetime throws exception and don't for years - it isn't clear that zero year is negative one (in that mean that stdTime for '' years will be negative. As the documentation states in multiple places, std.datetime follows ISO 8601, which uses the Proleptic Gregorian Calendar, and that specifies that the year 0 is equivalent to what you would normall consider to be 1 B.C. And that's part of the spec for the ISO extended format that fromISOExtString uses. Now, while it is mentioned in multiple places that std.datetime follows ISO 8601 and that it follows the Proleptic Gregorian Calender (even providing a link to wikipedia), it does look like it fails to specifically mention that on the primary ddoc comment of SysTime. So, that should be improved. However, the documentation for SysTime.year does state that positive years are A.D., whereas non-positive are B.C. So, the information is there, even without having to look up the Proleptic Gregorian Calender or ISO 8601. What would have made it clearer for you? - Jonathan M Davis Is zero positive or negative? May be add statement that zero year is 1 B.C.? Thank you for your good job! Neither. It's zero. That's why the documentation says that B.C. is non-positive - non-positive encompasses all of the negative numbers plus yes, it's my fault zero. And on yearBC, it does say that 0 is treated as 1 B.C. year doesn't mention that, but it's right above yearBC in the docs. It should probably link to yearBC though to make that clearer. B.C. does get kind of wonky though, since mathematically, it pretty much _has_ to be the case that 1 B.C. is 0 unless you just skip 0 (since otherwise all of the A.D. years get shifted by one, and then the years that most everyone uses would be shifted by one - e.g. 2017 would become 2016, which obviously doesn't work). And skipping 0 - as is done when normally talking about A.D. and B.C. - is just plain messy mathematically, just like trying to deal with the switch between the Julian and Gregorian calendars is a mess (even without getting into the issues related to different regions switching calendars at different times) - which is why ISO 8601 uses the Proleptic Gregorian Calendar, making it Gregorian the whole way. It's very mathematically neat, but it then runs afoul of how folks normally think of dates in the B.C. range. So, ultimately, it seems to be the best of a variety of bad answers to the problem. I suppose that we could have gone C#'s route, since they use the Proleptic Gregorian Calender but didn't implement B.C. But then that gets pretty weird when you have 0 hnsecs be the default value, since once you have time zones west of UTC, you suddenly end up with them being in B.C., and if you don't have B.C... I ported std.datetime to C++ once where I was working, and I tried to strip out stuff like B.C. thinking that it would make the code simpler, and it actually made it worse. So, yeah, it's just messy all around. Fortunately, most code doesn't actually care about dates that far back, and for the code that does, there's yearBC for anyone who wants a date that looks more familiar. - Jonathan M Davis Thank you for your answer!
Re: Why is for() less efficient than foreach?
On Friday, 10 February 2017 at 13:33:55 UTC, Bastiaan Veelo wrote: Thanks, I should have spotted that. Bastiaan. No, you don't even have to spot things like that. If you assert() the result that is. (Not a rant, half of us wouldn't probably have bothered).
Mallocator and 'shared'
https://github.com/dlang/phobos/blob/cd7846eb96ea7d2fa65ccb04b4ca5d5b0d1d4a63/std/experimental/allocator/mallocator.d#L63-L65
Looking at Mallocator, the use of 'shared' doesn't seem correct
to me.
The logic stated in the comment above is that 'malloc' is thread
safe, and therefore all methods of Mallocator can be qualified
with 'shared'.
I thought that qualifying a method as 'shared' meant that it
_can_ touch shared memory, and is therefore _not_ thread safe.
The following program produces this error:
"Error: shared method Mallocator.allocate is not callable using a
non-shared object"
import std.experimental.allocator.mallocator;
int main(string[] argv) {
Mallocator m;
m.allocate(64);
return 0;
}
And the above error is because it would be un(thread)safe to call
those methods from a non-shared context, due to the fact that
they may access shared memory.
Am I wrong here?
Re: Why do static arrays affect executable size?
On Friday, 10 February 2017 at 15:12:28 UTC, Jonathan M Davis wrote: Module-level and static variables all get put in the executable. So, declaring a static array like that is going to take up space. A dynamic array would do the same thing if you gave it a value of that size. The same thing happens with global and static variables in C/C++. An important difference with C/C++ in this case is that D floats are initialised to NaN, not 0.0. In binary (assuming IEEE floating point), 0.0 has an all-zero representation, but NaNs don't. Therefore, in C/C++ (on most platforms), default-initialised floats can be allocated in the BSS segment, which doesn't take up executable space, but in D, default-initialised floats have to be put into the compiled binary. If you explicitly initialise the array to all 0.0, you should see it disappear from the binary.
DerelictFmodStudio not found...
I followed the instructions for derelict.fmod. // Load the Fmod library. DerelictFmod.load(); // compiles fine. // Load the Fmod studio library. DerelictFmodStudio.load(); but the Studio load ..\common\derelict_libraries.d(122,5): Error: undefined identifier 'DerelictFmodStudio' In the detailed example, I see the code only loads DerelictFmod. Is the documentation out of date? Or am I missing something. Thanks.
Gc collects trigger access violation exception
Hi, everyone.
I have a thread running in Dll. But it always halts because of
access violation exception when GC begins collecting.
This is the thread stack frame in vs2013.
testSendSms.exe!_D4core6thread6Thread9isRunningMFNbNdZb() + 0x1
bytes D
testSendSms.exe!_D2gc4impl12conservative2gc3Gcx10smallAllocMFNbhKkkZPv() +
0x2a6 bytes D
testSendSms.exe!_D2gc4impl12conservative2gc14ConservativeGC6qallocMFNbkkxC8TypeInfoZS4core6memory8BlkInfo_()
+ 0x6d bytesD
then found these in core.thread.d
private bool suspend( Thread t ) nothrow
{
.
version( Windows )
{
if( t.m_addr != GetCurrentThreadId() && SuspendThread(
t.m_hndl ) == 0x )
{
if( !t.isRunning )
{
Thread.remove( t );
return false;
}
onThreadError( "Unable to suspend thread" );
}
...
}
}
I think the problem is when GC detects if the threading is
runnig, using core.thread.isRunning, the thread pointer is null.
When dll is loaded, it calls Runtime.initialize(),
gc_setProxy(gc) as the wiki says, so I have no idea why this
happened, and how to fix it. Could someone give me a hint ?
Thanks!
Re: Mallocator and 'shared'
On Friday, 10 February 2017 at 23:57:18 UTC, bitwise wrote:
https://github.com/dlang/phobos/blob/cd7846eb96ea7d2fa65ccb04b4ca5d5b0d1d4a63/std/experimental/allocator/mallocator.d#L63-L65
Looking at Mallocator, the use of 'shared' doesn't seem correct
to me.
The logic stated in the comment above is that 'malloc' is
thread safe, and therefore all methods of Mallocator can be
qualified with 'shared'.
I thought that qualifying a method as 'shared' meant that it
_can_ touch shared memory, and is therefore _not_ thread safe.
The following program produces this error:
"Error: shared method Mallocator.allocate is not callable using
a non-shared object"
import std.experimental.allocator.mallocator;
int main(string[] argv) {
Mallocator m;
m.allocate(64);
return 0;
}
And the above error is because it would be un(thread)safe to
call those methods from a non-shared context, due to the fact
that they may access shared memory.
Am I wrong here?
A shared method means that it can only be called on a shared
instance of the struct/class, which will have shared fields. A
shared method should be logically thread-safe, but that cannot be
guaranteed by the compiler. A non-shared method can touch shared
memory, and thus should be thread-safe if it does, but can only
be called on a non-shared instance with possibly non-shared
fields.
shared/non-shared methods don't mix because you generally need to
use different, less-efficient instructions and algorithms to be
thread-safe and scalable in a shared method. In the case of
Mallocator, there are no fields so as far as I can tell the
attribute doesn't do much except for documentation and for
storing references to it in other shared structs/objects.
Re: DerelictFmodStudio not found...
On Saturday, 11 February 2017 at 03:10:35 UTC, WhatMeWorry wrote: I followed the instructions for derelict.fmod. // Load the Fmod library. DerelictFmod.load(); // compiles fine. // Load the Fmod studio library. DerelictFmodStudio.load(); but the Studio load ..\common\derelict_libraries.d(122,5): Error: undefined identifier 'DerelictFmodStudio' In the detailed example, I see the code only loads DerelictFmod. Is the documentation out of date? Or am I missing something. Thanks. Does anybody know the exact version of fmod.dll that is needed by DerelictFmod? I don't think I can gleam this from the DUB entry. I've downloaded from FMOD's website their Windows api 1.09, 1.08, etc. and keep getting the following runtime abort: fmod.dll - %1 is not a valid Win32 application.
Re: Mallocator and 'shared'
On Friday, 10 February 2017 at 23:57:18 UTC, bitwise wrote: https://github.com/dlang/phobos/blob/cd7846eb96ea7d2fa65ccb04b4ca5d5b0d1d4a63/std/experimental/allocator/mallocator.d#L63-L65 Looking at Mallocator, the use of 'shared' doesn't seem correct to me. [...] IIRC you're supposed to use `Mallocator.instance` as it is a singleton.
Re: DerelictFmodStudio not found...
On 11/02/2017 5:38 PM, WhatMeWorry wrote: On Saturday, 11 February 2017 at 03:10:35 UTC, WhatMeWorry wrote: I followed the instructions for derelict.fmod. // Load the Fmod library. DerelictFmod.load(); // compiles fine. // Load the Fmod studio library. DerelictFmodStudio.load(); but the Studio load ..\common\derelict_libraries.d(122,5): Error: undefined identifier 'DerelictFmodStudio' In the detailed example, I see the code only loads DerelictFmod. Is the documentation out of date? Or am I missing something. Thanks. Does anybody know the exact version of fmod.dll that is needed by DerelictFmod? I don't think I can gleam this from the DUB entry. I've downloaded from FMOD's website their Windows api 1.09, 1.08, etc. and keep getting the following runtime abort: fmod.dll - %1 is not a valid Win32 application. Have you got the right dll for your executable? E.g. 32bit dll for 32bit exe?
