Re: How do I choose the correct primative?
On Friday, 3 January 2014 at 05:25:49 UTC, Casper Færgemand wrote: On Wednesday, 1 January 2014 at 04:17:30 UTC, Jake Thomas wrote: snip Are you looking for something like int_fast32_t and the likes from Boost? If you don't care terribly much for when your numbers overflow, then as others suggested, size_t and pttwhatever work fine. I had never heard of int_fast32_t before, but after Googling and finding out what it is, yes, I am looking for just exactly that.
Re: How do I choose the correct primative?
Keep in mind that RAM access is slow compared to how fast CPUs run. It can be beneficial to have "slower" data types if they allow more data to fit into the CPU cache. Abosolutely fantastic point, Marco! Except if everything still fits in cache as "fast" types, it'd be worth having faster types. How do you folks decide if a number should be an int, long, or even short? I guess the exact type of variables should remain up in the air until the whole thing is implemented and tested using different types? Wow, this is an active forum, I must say. Much thanks! Jake
Re: How do I choose the correct primative?
We have size_t defined as uint on 32bit and ulong on 64bit.
ptrdiff_t for int/long.
I don't know how dmd handles it, although you do have the
ability to align variables.
You may want to consider gdc or ldc more than dmd as they have
better optimization.
Sorry for the delayed response - distractions.
Thanks for the tips! I didn't know about aligning or ptrdiff_t.
I looked into and experimented with "align". At least with dmd,
it seems to only work in structs.
Looking at http://dlang.org/attribute.html, one might conclude
that this is a bug in dmd - the attributes web page doesn't say
anywhere that align should be limited to work only within
structs. No syntactical error is thrown by the compiler if align
is used outside a struct, but the symantics aren't there to back
it up.
Watch this:
[code]
import std.stdio;
int main()
{
align(8) int testInt1;
align(8) int testInt2;
align(8) int testInt3;
int* testInt1Locale = &testInt1;
int* testInt2Locale = &testInt2;
int* testInt3Locale = &testInt3;
long testLong1;
long testLong2;
long testLong3;
long* testLong1Locale = &testLong1;
long* testLong2Locale = &testLong2;
long* testLong3Locale = &testLong3;
struct AlignTest
{
align (8):
int intOne;
int intTwo;
int intThree;
}
AlignTest alignTest;
int* alignTestIntOneLocale = &alignTest.intOne;
int* alignTestIntTwoLocale = &alignTest.intTwo;
int* alignTestIntThreeLocale = &alignTest.intThree;
writeln(cast(long)testInt2Locale - cast(long)testInt1Locale);
writeln(cast(long)testInt3Locale - cast(long)testInt2Locale);
writeln(cast(long)testLong2Locale - cast(long)testLong1Locale);
writeln(cast(long)testLong3Locale - cast(long)testLong2Locale);
writeln(cast(long)alignTestIntTwoLocale -
cast(long)alignTestIntOneLocale);
writeln(cast(long)alignTestIntThreeLocale -
cast(long)alignTestIntTwoLocale);
return 0;
}
[/code]
The above code, compiled with dmd for and on 64-bit linux prints
the following:
[quote]
4 //Ints 1 & 2 are 4 bytes apart, dispite specifying them to be 8
bytes apart.
4 //Ints 2 & 3 are 4 bytes apart, dispite specifying them to be 8
bytes apart.
8 //Longs 1 & 2 are 8 bytes apart.
8 //Longs 2 & 3 are 8 bytes apart.
8 //Struct's ints 1 & 2 are 8 bytes apart - specified by align
attribute.
8 //Struct's ints 2 & 3 are 8 bytes apart - specified by align
attribute.
[/quote]
So, short-term, it seems like one would want to use my
"native/unative" technique. But long-term, hopefully not only
does this get fixed, but the default behavior for the compiler be
to pad things out to the native word size without having to
specify alignment.
Note: I tried "auto" - they come out as ints on my 64-bit
architecture, still separated by 4 bytes.
Even with size_t and ptrdiff_t, I would still want to make my own
aliases "native" and "unative" because size_t is intended for
array indexes (from what I saw when I briefly read about them)
and "native" and "unative" sound more generic and readable - to
me at least - and follows the "u" naming convention.
Stay efficeint,
Jake
Re: GetWindowText & GetWindowTextLength
Perfect. Thank you!
Re: GetWindowText & GetWindowTextLength
On Saturday, 4 January 2014 at 02:44:55 UTC, Bauss wrote: I cannot seem to access those two functions from the Windows API. The core.sys.windows module is woefully incomplete. Two options, either grab the better bindings here: http://www.dsource.org/projects/bindings/browser/trunk/win32 Or define the functions yourself, paste this into your module: extern(Windows) int GetWindowTextLengthW( HWND hWnd ); extern(Windows) int GetWindowTextW( HWND hWnd, wchar* lpString, int nMaxCount ); then call them normally. Or use the A versions instead of W if you want to work with ascii char* instead of unicode.
GetWindowText & GetWindowTextLength
I cannot seem to access those two functions from the Windows API. They doesn't seem to be in the core.sys.windows.windows module either. So I'm kinda lost as for what to do.
Re: Simplest way to create an array from an associative array which its contains keys and values?
H. S. Teoh: I did an implementation of aa.byPair once, that iterates over keys and values simultaneously, but it was ultimately rejected: A byPair will be needed in Phobos, in one way or another. Bye, bearophile
Re: Simplest way to create an array from an associative array which its contains keys and values?
On Sat, Jan 04, 2014 at 12:39:32AM +, bearophile wrote: > Ali Çehreli: > > >I still like that solution. :) Even if it's not spelled out to be > >correct in the spec, I can't imagine a hash table implementation > >where byKey and byValue don't iterate in lock step. > > But in the long term ignoring what's present or missing in the specs > is a bad idea. > > > >I wrote the following Expander range as an exercise. > > See also: > https://d.puremagic.com/issues/show_bug.cgi?id=5489 > https://d.puremagic.com/issues/show_bug.cgi?id=7957 [...] I did an implementation of aa.byPair once, that iterates over keys and values simultaneously, but it was ultimately rejected: https://github.com/D-Programming-Language/druntime/pull/574 T -- What's a "hot crossed bun"? An angry rabbit.
Re: Runtime.unloadLibrary does not return
On Friday, 3 January 2014 at 21:58:07 UTC, cal wrote: On Friday, 3 January 2014 at 19:37:04 UTC, Colden Cullen wrote: I'm using 2.064.2, and I'm having a very similar issue. For me, the program doesn't crash until after my main has finished executing. Does anyone have any idea what might be going on? For me the problem was related to this: https://d.puremagic.com/issues/show_bug.cgi?id=1550 using the workaround in there, loading and unloading DLL's on windows works OK for me now. Wow, that worked wonderfully. Thanks for pointing me in the right direction!
Re: Simplest way to create an array from an associative array which its contains keys and values?
On 01/03/2014 04:39 PM, bearophile wrote: Ali Çehreli: I still like that solution. :) Even if it's not spelled out to be correct in the spec, I can't imagine a hash table implementation where byKey and byValue don't iterate in lock step. But in the long term ignoring what's present or missing in the specs is a bad idea. I don't mean to ignore. I would like to see the spec changed. This feels similar to first C++ standard never explicitly requiring that the elements of a string be contiguous in memory but every implementation doing so. I wrote the following Expander range as an exercise. See also: https://d.puremagic.com/issues/show_bug.cgi?id=5489 https://d.puremagic.com/issues/show_bug.cgi?id=7957 Bye, bearophile They make sense to me. Ali
Re: Simplest way to create an array from an associative array which its contains keys and values?
Ali Çehreli: I still like that solution. :) Even if it's not spelled out to be correct in the spec, I can't imagine a hash table implementation where byKey and byValue don't iterate in lock step. But in the long term ignoring what's present or missing in the specs is a bad idea. I wrote the following Expander range as an exercise. See also: https://d.puremagic.com/issues/show_bug.cgi?id=5489 https://d.puremagic.com/issues/show_bug.cgi?id=7957 Bye, bearophile
Re: Simplest way to create an array from an associative array which its contains keys and values?
On 01/03/2014 09:47 AM, bearophile wrote:
> Unfortunately the D associative arrays specs don't specify this to be
> correct:
>
> zip(aa.byKey, aa.byValue)
I still like that solution. :) Even if it's not spelled out to be
correct in the spec, I can't imagine a hash table implementation where
byKey and byValue don't iterate in lock step.
I wrote the following Expander range as an exercise. I think it could be
useful in Phobos. (I am aware that there are proposals to revamp tuples
in Phobos; the following is for 2.064.)
Some issues:
1) Yes, expand may not be the best name as it would be confusing with
Tuple.expand, which is a different thing.
2) As with some other InputRanges, the need to call the prime() member
function up front in the constructor feels weird. It makes the range
one-step eager. However, doing it in the front() conditionaly via 'if
(is_primed)' would bring a cost to every call to front().
3) The member rangeFront is needed because Tuple does not have opIndex
for dynamic indexes. I can do range.front[0] but I cannot do
range.front[currentIndex]. So, my solution was to take advantage of
Tuple.expand by wrapping it in a slice, which I have taken out due to
performance concern, without ever measuring anything. :p
import std.range;
void main()
{
auto aa = ["one":"1", "two":"2"];
assert(zip(aa.byKey, aa.byValue)
.expand
.equal([ "one", "1", "two", "2" ]));
}
/* Expands individual members of elements of a tuple-range as elements
* of this range. */
struct Expander(R)
if (__traits(compiles, [ ElementType!R ]))
{
alias ElementT = typeof([ ElementType!R.expand ].front);
R range;
ElementT[ElementType!R.length] rangeFront;
size_t currentIndex;
this(R range)
{
this.range = range;
prime();
}
private void prime()
{
if (!empty) {
currentIndex = 0;
/* The following static foreach "I think" avoids a dynamic
array
* allocation when compared to the following line:
*
* rangeFront = [ range.front.expand ];
*/
foreach (i, element; range.front) {
rangeFront[i] = element;
}
}
}
bool empty() @property
{
return range.empty;
}
ElementT front() @property
{
return rangeFront[currentIndex];
}
void popFront()
{
++currentIndex;
if (currentIndex == ElementType!R.length) {
range.popFront();
prime();
}
}
}
Expander!R expand(R)(R range)
if (__traits(compiles, [ ElementType!R ]))
{
return Expander!R(range);
}
unittest
{
import std.typecons;
auto a = [ tuple(1, 2.2), tuple(3, 4.4) ];
auto expanded = a.expand;
static assert(is (typeof(expanded.front) == double));
assert(expanded.equal([ 1, 2.2, 3, 4.4 ]));
// Incompatible tuple members should fail to compile
auto mismatched = [ tuple(int.init, string.init) ];
static assert(!__traits(compiles, mismatched.expand));
}
Ali
Re: Runtime.unloadLibrary does not return
On Friday, 3 January 2014 at 19:37:04 UTC, Colden Cullen wrote: I'm using 2.064.2, and I'm having a very similar issue. For me, the program doesn't crash until after my main has finished executing. Does anyone have any idea what might be going on? For me the problem was related to this: https://d.puremagic.com/issues/show_bug.cgi?id=1550 using the workaround in there, loading and unloading DLL's on windows works OK for me now.
Re: Linux DLL
Thank you Jeroen, Dicebot's post was EXTREMELY helpful, and was more or less what I was looking for! :D
Re: Linux DLL
On Friday, 3 January 2014 at 20:48:29 UTC, Jeroen Bollen wrote: On Friday, 3 January 2014 at 20:37:06 UTC, Mineko wrote: On Friday, 3 January 2014 at 20:34:17 UTC, Jeroen Bollen wrote: On Friday, 3 January 2014 at 20:31:09 UTC, Mineko wrote: So, I was doing some stuff with shared libraries and need some confirmation on what's going on with http://dlang.org/dll-linux.html Is that page recent, or really old? It's using printf and stuff so uhh.. Seems old. Could anyone here perhaps give me a more recent explanation of how to do the bottom example, if it's not already? (http://dlang.org/dll-linux.html#dso10) Using the standard phobos library, of course, for instance, I would have issues with fprintf and the stuff going on with stderror and error/dlerror. It says on top "Preliminary and subject to change.", although that might have just been put in. Oh, thank you, can't believe I missed that.. Other than that, are there any better ways of doing the aforementioned? I've asked a question related to DLL loading myself recently, but all I got from it was "making DLLs in D is terribly complicated and when you hear anything related to it just run". Here's the thread: http://forum.dlang.org/thread/sedvxeoxoslnzbeiy...@forum.dlang.org Or SO on Linux. :D
Re: Linux DLL
On Friday, 3 January 2014 at 20:37:06 UTC, Mineko wrote: On Friday, 3 January 2014 at 20:34:17 UTC, Jeroen Bollen wrote: On Friday, 3 January 2014 at 20:31:09 UTC, Mineko wrote: So, I was doing some stuff with shared libraries and need some confirmation on what's going on with http://dlang.org/dll-linux.html Is that page recent, or really old? It's using printf and stuff so uhh.. Seems old. Could anyone here perhaps give me a more recent explanation of how to do the bottom example, if it's not already? (http://dlang.org/dll-linux.html#dso10) Using the standard phobos library, of course, for instance, I would have issues with fprintf and the stuff going on with stderror and error/dlerror. It says on top "Preliminary and subject to change.", although that might have just been put in. Oh, thank you, can't believe I missed that.. Other than that, are there any better ways of doing the aforementioned? I've asked a question related to DLL loading myself recently, but all I got from it was "making DLLs in D is terribly complicated and when you hear anything related to it just run". Here's the thread: http://forum.dlang.org/thread/sedvxeoxoslnzbeiy...@forum.dlang.org
Re: Linux DLL
On Friday, 3 January 2014 at 20:34:17 UTC, Jeroen Bollen wrote: On Friday, 3 January 2014 at 20:31:09 UTC, Mineko wrote: So, I was doing some stuff with shared libraries and need some confirmation on what's going on with http://dlang.org/dll-linux.html Is that page recent, or really old? It's using printf and stuff so uhh.. Seems old. Could anyone here perhaps give me a more recent explanation of how to do the bottom example, if it's not already? (http://dlang.org/dll-linux.html#dso10) Using the standard phobos library, of course, for instance, I would have issues with fprintf and the stuff going on with stderror and error/dlerror. It says on top "Preliminary and subject to change.", although that might have just been put in. Oh, thank you, can't believe I missed that.. Other than that, are there any better ways of doing the aforementioned?
Re: Linux DLL
On Friday, 3 January 2014 at 20:31:09 UTC, Mineko wrote: So, I was doing some stuff with shared libraries and need some confirmation on what's going on with http://dlang.org/dll-linux.html Is that page recent, or really old? It's using printf and stuff so uhh.. Seems old. Could anyone here perhaps give me a more recent explanation of how to do the bottom example, if it's not already? (http://dlang.org/dll-linux.html#dso10) Using the standard phobos library, of course, for instance, I would have issues with fprintf and the stuff going on with stderror and error/dlerror. It says on top "Preliminary and subject to change.", although that might have just been put in.
Linux DLL
So, I was doing some stuff with shared libraries and need some confirmation on what's going on with http://dlang.org/dll-linux.html Is that page recent, or really old? It's using printf and stuff so uhh.. Seems old. Could anyone here perhaps give me a more recent explanation of how to do the bottom example, if it's not already? (http://dlang.org/dll-linux.html#dso10) Using the standard phobos library, of course, for instance, I would have issues with fprintf and the stuff going on with stderror and error/dlerror.
Re: Is continuously seeding a random number generator performance intensive?
On Friday, 3 January 2014 at 18:23:23 UTC, monarch_dodra wrote: On Friday, 3 January 2014 at 17:41:48 UTC, Jeroen Bollen wrote: On Friday, 3 January 2014 at 13:42:19 UTC, monarch_dodra wrote: On Friday, 3 January 2014 at 13:30:09 UTC, Jeroen Bollen wrote: I already considered this, but the problem is, I need to smoothen the noise, and to do that I need all surrounding 'checkpoints' too. This means that it'll have to load in 5 at a time. I don't see that as a problem. Just because you can load sub-regions at once, doesn't mean you are limited to only loading one at a time. That still means that out of 5 million pixels loaded, only 1 million 4 thousand will be used. I guess I can recycle them though. You could also do a "subdivision" approach: First, a table that contains seeds for 1Kx1K blocks... However each seed is designed to seed 1 new seeds, to generate 10x10 blocks (for example). This way, you can first load your big 1Kx1K block, and then 400 10x10 blocks. Seems reasonable to me. I don't know exactly how big your data is, so your mileage may vary. Depending on your algorithm, you may have to adapt the numbers, or even amount of subdivisions. What generator would be most fitting for this? The Documentation says the "MersenneTwisterEngine" is an 'overall' good one. I decided to go with blocks of 32*32, which all require to be filled with an unsigned byte.
Re: Correct use of map
Dfr:
Here is few code eaxamples, i don't know why it is doesn't work
as expected.
Here i want to transform string into list of tuples split by
character:
auto nameparts = splitter("go.home", '.').map!(v =>
tuple(v,0)).array;
This gives me not very useful message about assert and stuff:
core.exception.AssertError@std.algorithm(1942): Assertion
failure
It works for me:
void main() {
import std.stdio, std.algorithm, std.typecons, std.range;
auto nameParts = "go.home"
.splitter('.')
.map!(v => tuple(v, 0))
.array;
nameParts.writeln;
}
Output:
[Tuple!(string, int)("go", 0), Tuple!(string, int)("home", 0)]
I am using dmd 2.065alpha on Windows.
Bye,
bearophile
Re: External modules
On 2014-01-03 16:05, Adam D. Ruppe wrote: It could potentially be automated with reflection though... Yes, sure. -- /Jacob Carlborg
Re: Segmentation fault on sort
Dfr:
struct Color {
string fg;
string bg;
string attrs;
int slid;
}
auto tt = [Tuple!(uint, Color)(28, Color("0", "255", "", 0)),
Tuple!(uint, Color)(28, Color("0", "255", "", 0))];
tt.sort;
This just dies on "tt.sort", any idea what is wrong ?
Your code has two problems: you are using the buggy built-in sort
instead of the Phobos one, and you have not defined an opCmp and
opEquals in Color.
If you don't want to define those two methods you can use a tuple
again:
import std.stdio, std.algorithm, std.typecons;
struct Color0 {
string fg, bg, attrs;
int slid;
}
alias Color = Tuple!(string,"fg", string,"bg", string,"attrs",
int,"slid");
void main() {
alias T = Tuple!(uint, Color);
auto tt = [T(28, Color("0", "255", "", 0)),
T(28, Color("0", "255", "", 0))];
tt.writeln;
tt.sort(); // Phobos sort.
tt.writeln;
}
Bye,
bearophile
Correct use of map
Here is few code eaxamples, i don't know why it is doesn't work
as expected.
Here i want to transform string into list of tuples split by
character:
auto nameparts = splitter("go.home", '.').map!(v =>
tuple(v,0)).array;
This gives me not very useful message about assert and stuff:
core.exception.AssertError@std.algorithm(1942): Assertion failure
Segmentation fault on sort
struct Color {
string fg;
string bg;
string attrs;
int slid;
}
auto tt = [Tuple!(uint, Color)(28, Color("0", "255", "", 0)),
Tuple!(uint, Color)(28, Color("0", "255", "", 0))];
tt.sort;
This just dies on "tt.sort", any idea what is wrong ?
Re: Runtime.unloadLibrary does not return
On Saturday, 3 November 2012 at 19:36:14 UTC, cal wrote: Following the D win32 dll example (http://dlang.org/dll.html), I created a d dll with a simple exported function, which i then dynamically load and call (just like the example). This works fine, however Runtime.unloadLibrary does not return. I do however get the "DLL_PROCESS_DETACH" message, so it gets at least that far. In fact, if I have code after the Runtime.unloadLibrary call, the program crashes (without code following the call, it just hangs). Has anyone else seen this problem? I get this with both dmd 2.060 and 2.061. I'm using 2.064.2, and I'm having a very similar issue. For me, the program doesn't crash until after my main has finished executing. Does anyone have any idea what might be going on?
Re: Private functions and allMembers
On Friday, 3 January 2014 at 18:30:56 UTC, Carl wrote:
Here is some test code:
// --- start --- //
// main.d //
import std.stdio;
import extra;
void main()
{
void function() func;
foreach(mem; __traits(allMembers, __traits(parent, test)))
{
foreach(att; __traits(getAttributes, mixin(mem)))
{
if(att == "good") func = &mixin(mem);
}
}
if(func) func();
else writeln("func not assigned");
}
// extra.d //
import std.stdio;
@("good")
public void test()
{
writeln("test()");
}
@("bad")
private void badtest()
{
}
// --- end --- //
main.d(13): Error: module main function extra.badtest is private
main.d(15): Error: module main function extra.badtest is private
I understand the need to prevent access to private members, but
how does one work around this?
Adding an if statment with __traits(compiles, mixin(mem)) still
gives errors. However, pragma(msg... shows it does return false
for the private function.
void main()
{
void function() func;
foreach(mem; __traits(allMembers, extra))
{
static if(__traits(compiles, mixin(mem)))
foreach(att; __traits(getAttributes, mixin(mem)))
{
if(att == "good") func = &mixin(mem);
}
}
if(func) func();
else writeln("func not assigned");
}
This works for me. DMD 2.064.2
Private functions and allMembers
Here is some test code:
// --- start --- //
// main.d //
import std.stdio;
import extra;
void main()
{
void function() func;
foreach(mem; __traits(allMembers, __traits(parent, test)))
{
foreach(att; __traits(getAttributes, mixin(mem)))
{
if(att == "good") func = &mixin(mem);
}
}
if(func) func();
else writeln("func not assigned");
}
// extra.d //
import std.stdio;
@("good")
public void test()
{
writeln("test()");
}
@("bad")
private void badtest()
{
}
// --- end --- //
main.d(13): Error: module main function extra.badtest is private
main.d(15): Error: module main function extra.badtest is private
I understand the need to prevent access to private members, but
how does one work around this?
Adding an if statment with __traits(compiles, mixin(mem)) still
gives errors. However, pragma(msg... shows it does return false
for the private function.
Re: Is continuously seeding a random number generator performance intensive?
On Friday, 3 January 2014 at 17:41:48 UTC, Jeroen Bollen wrote: On Friday, 3 January 2014 at 13:42:19 UTC, monarch_dodra wrote: On Friday, 3 January 2014 at 13:30:09 UTC, Jeroen Bollen wrote: I already considered this, but the problem is, I need to smoothen the noise, and to do that I need all surrounding 'checkpoints' too. This means that it'll have to load in 5 at a time. I don't see that as a problem. Just because you can load sub-regions at once, doesn't mean you are limited to only loading one at a time. That still means that out of 5 million pixels loaded, only 1 million 4 thousand will be used. I guess I can recycle them though. You could also do a "subdivision" approach: First, a table that contains seeds for 1Kx1K blocks... However each seed is designed to seed 1 new seeds, to generate 10x10 blocks (for example). This way, you can first load your big 1Kx1K block, and then 400 10x10 blocks. Seems reasonable to me. I don't know exactly how big your data is, so your mileage may vary. Depending on your algorithm, you may have to adapt the numbers, or even amount of subdivisions.
Re: A little DUB question
On Friday, 3 January 2014 at 09:28:32 UTC, Sönke Ludwig wrote: Hm, which version do you use? This one: http://code.dlang.org/files/dub-0.9.21-beta.1-setup.exe (I'm on Windows)
Re: Dub shared library issue
""libs": [ "phobos2" ]" worked perfectly, thank you so much. :)
Re: Simplest way to create an array from an associative array which its contains keys and values?
On Fri, 03 Jan 2014 17:49:28 +, Andrej Mitrovic wrote:
> On Friday, 3 January 2014 at 17:38:16 UTC, Gary Willoughby wrote:
>> I know it can be done via a loop, but is there a more idiomatic way to
>> achieve this?
>
>
> import std.algorithm;
> import std.range;
> import std.stdio;
>
> void main()
> {
> auto aa = ["one":"1", "two":"2"];
> auto range = aa.byKey.map!(a => chain(a.only, aa[a].only));
> string[] array = range.join;
> writeln(array);
> }
>
>
> However I'm not sure whether "only" is present in 2.064, maybe it was
> added recently in the git-head version.
`only` is available in 2.063, maybe even earlier.
Re: Simplest way to create an array from an associative array which its contains keys and values?
On Friday, 3 January 2014 at 17:47:43 UTC, bearophile wrote: string[] r = aa.byKey.map!(k => [k, aa[k]]).join; However the [k, aa[k]] expression will allocate an array for each key you iterate over regardless if you use join or joiner. I posted a solution with "only", hope that works. :)
Re: Simplest way to create an array from an associative array which its contains keys and values?
Gary Willoughby:
Simplest way to create an array from an associative array which
its contains keys and values?
For example if i have an associative array like this:
["one":"1", "two":"2"]
What's the easiest way to create a dynamic array that looks
like this:
["one", "1", "two", "2"]
I know it can be done via a loop, but is there a more idiomatic
way to achieve this?
Unfortunately the D associative arrays specs don't specify this
to be correct:
zip(aa.byKey, aa.byValue)
So a solution without foreach loops is:
void main() {
import std.stdio, std.algorithm, std.array;
auto aa = ["one":"1", "two":"2"];
string[] r = aa.byKey.map!(k => [k, aa[k]]).join;
r.writeln;
}
You can also use joiner if you need just a lazy range.
Bye,
bearophile
Re: Simplest way to create an array from an associative array which its contains keys and values?
On Friday, 3 January 2014 at 17:38:16 UTC, Gary Willoughby wrote:
I know it can be done via a loop, but is there a more idiomatic
way to achieve this?
import std.algorithm;
import std.range;
import std.stdio;
void main()
{
auto aa = ["one":"1", "two":"2"];
auto range = aa.byKey.map!(a => chain(a.only, aa[a].only));
string[] array = range.join;
writeln(array);
}
However I'm not sure whether "only" is present in 2.064, maybe it
was added recently in the git-head version.
Re: Dub shared library issue
On Friday, 3 January 2014 at 15:10:54 UTC, Mineko wrote:
On Friday, 3 January 2014 at 15:03:27 UTC, Mathias LANG wrote:
On Friday, 3 January 2014 at 15:01:16 UTC, Mineko wrote:
So, I can get a shared library compiled normally (Assuming
it's already compiled first with -shared -fPIC etc) with: dmd
-of'Breaker Engine.so' 'Breaker Engine.o' -shared
-defaultlib=libphobos2.so -L-rpath=$PWD
However, for some reason dub is having issues whenever I try
to compile it as a shared library with dynamicLibrary.
Any suggestions? I'd like to get this fixed because otherwise
there's gonna be portability problems..
Could you provide some error message / output, and your
package.json ?
Sure, I thought I was missing some info..
Linking...
dmd
-of.dub/build/library-debug-x86_64-dmd-DA39A3EE5E6B4B0D3255BFEF95601890AFD80709/libbreaker.so
.dub/build/library-debug-x86_64-dmd-DA39A3EE5E6B4B0D3255BFEF95601890AFD80709/breaker.o
-L-ldl -shared -g
/usr/bin/ld: /usr/lib/libphobos2.a(object__a_58c.o): relocation
R_X86_64_32 against `_D10TypeInfo_m6__initZ' can not be used
when making a shared object; recompile with -fPIC
/usr/lib/libphobos2.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
{
"name": "breaker-engine",
"description": "A multi-dimensional engine with a stupid
amount of modularity",
"homepage": "https://github.com/ICGCC/Breaker-Engine";,
"license": "Zlib",
"author": "Jakob Austin Wimberly (Mineko)",
"targetName": "breaker",
"targetPath": "lib",
"targetType": "dynamicLibrary",
"dependencies":
{
"gl3n": "~master",
"derelict-gl3": "~master",
"derelict-glfw3": "~master",
"derelict-fi": "~master"
}
}
Add this to your package.json:
"libs": [ "phobos2" ]
I also added:
"lflags": [ "-rpath=/home//bin/dmd-2.064.2/linux/lib64/" ],
for myself, as my dmd is in ~/bin/, but you shouldn't need it if
you installed the package.
Re: Is continuously seeding a random number generator performance intensive?
On Friday, 3 January 2014 at 13:42:19 UTC, monarch_dodra wrote: On Friday, 3 January 2014 at 13:30:09 UTC, Jeroen Bollen wrote: I already considered this, but the problem is, I need to smoothen the noise, and to do that I need all surrounding 'checkpoints' too. This means that it'll have to load in 5 at a time. I don't see that as a problem. Just because you can load sub-regions at once, doesn't mean you are limited to only loading one at a time. That still means that out of 5 million pixels loaded, only 1 million 4 thousand will be used. I guess I can recycle them though.
Simplest way to create an array from an associative array which its contains keys and values?
Simplest way to create an array from an associative array which its contains keys and values? For example if i have an associative array like this: ["one":"1", "two":"2"] What's the easiest way to create a dynamic array that looks like this: ["one", "1", "two", "2"] I know it can be done via a loop, but is there a more idiomatic way to achieve this?
Re: Dub shared library issue
On Friday, 3 January 2014 at 15:03:27 UTC, Mathias LANG wrote:
On Friday, 3 January 2014 at 15:01:16 UTC, Mineko wrote:
So, I can get a shared library compiled normally (Assuming
it's already compiled first with -shared -fPIC etc) with: dmd
-of'Breaker Engine.so' 'Breaker Engine.o' -shared
-defaultlib=libphobos2.so -L-rpath=$PWD
However, for some reason dub is having issues whenever I try
to compile it as a shared library with dynamicLibrary.
Any suggestions? I'd like to get this fixed because otherwise
there's gonna be portability problems..
Could you provide some error message / output, and your
package.json ?
Sure, I thought I was missing some info..
Linking...
dmd
-of.dub/build/library-debug-x86_64-dmd-DA39A3EE5E6B4B0D3255BFEF95601890AFD80709/libbreaker.so
.dub/build/library-debug-x86_64-dmd-DA39A3EE5E6B4B0D3255BFEF95601890AFD80709/breaker.o
-L-ldl -shared -g
/usr/bin/ld: /usr/lib/libphobos2.a(object__a_58c.o): relocation
R_X86_64_32 against `_D10TypeInfo_m6__initZ' can not be used when
making a shared object; recompile with -fPIC
/usr/lib/libphobos2.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
{
"name": "breaker-engine",
"description": "A multi-dimensional engine with a stupid
amount of modularity",
"homepage": "https://github.com/ICGCC/Breaker-Engine";,
"license": "Zlib",
"author": "Jakob Austin Wimberly (Mineko)",
"targetName": "breaker",
"targetPath": "lib",
"targetType": "dynamicLibrary",
"dependencies":
{
"gl3n": "~master",
"derelict-gl3": "~master",
"derelict-glfw3": "~master",
"derelict-fi": "~master"
}
}
Dub shared library issue
So, I can get a shared library compiled normally (Assuming it's already compiled first with -shared -fPIC etc) with: dmd -of'Breaker Engine.so' 'Breaker Engine.o' -shared -defaultlib=libphobos2.so -L-rpath=$PWD However, for some reason dub is having issues whenever I try to compile it as a shared library with dynamicLibrary. Any suggestions? I'd like to get this fixed because otherwise there's gonna be portability problems..
Re: External modules
On Friday, 3 January 2014 at 13:03:50 UTC, Jacob Carlborg wrote: You can't import the whole module. You would need to use "dlsym" on each symbol you're interested in. It could potentially be automated with reflection though...
Re: Dub shared library issue
On Friday, 3 January 2014 at 15:01:16 UTC, Mineko wrote: So, I can get a shared library compiled normally (Assuming it's already compiled first with -shared -fPIC etc) with: dmd -of'Breaker Engine.so' 'Breaker Engine.o' -shared -defaultlib=libphobos2.so -L-rpath=$PWD However, for some reason dub is having issues whenever I try to compile it as a shared library with dynamicLibrary. Any suggestions? I'd like to get this fixed because otherwise there's gonna be portability problems.. Could you provide some error message / output, and your package.json ?
Re: Is continuously seeding a random number generator performance intensive?
On Friday, 3 January 2014 at 13:30:09 UTC, Jeroen Bollen wrote: I already considered this, but the problem is, I need to smoothen the noise, and to do that I need all surrounding 'checkpoints' too. This means that it'll have to load in 5 at a time. I don't see that as a problem. Just because you can load sub-regions at once, doesn't mean you are limited to only loading one at a time.
Re: Is continuously seeding a random number generator performance intensive?
On Friday, 3 January 2014 at 01:01:21 UTC, Frustrated wrote:
On Thursday, 2 January 2014 at 20:38:10 UTC, Jeroen Bollen
wrote:
[...]
e.g.,
seed(k);
for(i = 1..10)
print(rnd(i));
and
for(i = 1..10)
{
seed(time);
print(rnd(i));
}
will both produce random sequences of numbers(and random
sequences of numbers are "identically random".
[...]
The second example is error-prone. If "time" var doesn't change
between cycle, it's not random at all.
Re: Is continuously seeding a random number generator performance intensive?
On Friday, 3 January 2014 at 10:06:27 UTC, monarch_dodra wrote: On Friday, 3 January 2014 at 01:43:09 UTC, Chris Cain wrote: So, it sounds like the OP is using the x and y coords for a seed to generate a single number and he was curious to whether it costs too much to reseed like this for every point. FWIW, I'm under the impression that this is a fairly common strategy, but usually when I've seen this used more than one number is generated at a time. I *thought* he wanted to do something like that, but was surprised by the fact he wanted to reseed *per* element... You can still do this, in this case. For example, divide x by 10 and generate 10 elements (column wise) in the noise map each time and it reduces the number of reseeds by a factor of 10. Some effort might be wasted, but as long as you need a decent chunk of the noise map at any one point in time, this should work out pretty well in practice. My biggest concern with this approach is that you must take care that your usage of seeding with x and y coordinates does not cause repeated elements to occur. For instance, using `Random rng = Random(x + y);` will _not_ work properly (unless you want strange mirroring down the diagonal in your noise map). There's numerous landmines to avoid when doing something like this. Some approaches may not be perfect, but depending on what you're doing they may be sufficient, however. The approach I'd take here is to eagerly generate a "uint[X / 1000][Y / 1000]" grid, that holds randomly generated numbers, to be used as seeds for individual 1000*1000 blocks of the noise map. I don't know how good that is though in terms of correlation...? Or, even better, to create a single generator of type "Gen", and store a "Gen[X / 1000][Y / 1000]": EG: the generator, with a "checkpoint" every 1_000_000 elements. This should reduce correlation down to 0. AFAIK, all generators above the "linear congruential generator" have a period above 10^12, so this approach should be fine. The only issue with such an approach might be the size of the PRNG's themselves: XOrShift, for example, is only a few bytes big, so that's fine. But MT is about 700B, which is a hefty amount to chug along. I already considered this, but the problem is, I need to smoothen the noise, and to do that I need all surrounding 'checkpoints' too. This means that it'll have to load in 5 at a time.
Re: External modules
On Friday, 3 January 2014 at 13:03:50 UTC, Jacob Carlborg wrote:
On 2014-01-03 14:00, Mineko wrote:
This is another short one, is it possible to export/extern (C)
an entire
module, is it safe?
Also, how do you import said module, this one I don't quite
get.
So, something like this:
dll.d:
extern (C) module test;
int foo() {...}
-
main.d
int main(string[] args)
{
...
(dl loading code for dll.so)
module dll = dlsym(lh, "test");
...
}
So, aside from the crappy abstraction, something like that?
You can't import the whole module. You would need to use
"dlsym" on each symbol you're interested in.
Thank you.
Re: External modules
On 2014-01-03 14:00, Mineko wrote:
This is another short one, is it possible to export/extern (C) an entire
module, is it safe?
Also, how do you import said module, this one I don't quite get.
So, something like this:
dll.d:
extern (C) module test;
int foo() {...}
-
main.d
int main(string[] args)
{
...
(dl loading code for dll.so)
module dll = dlsym(lh, "test");
...
}
So, aside from the crappy abstraction, something like that?
You can't import the whole module. You would need to use "dlsym" on each
symbol you're interested in.
--
/Jacob Carlborg
External modules
This is another short one, is it possible to export/extern (C) an
entire module, is it safe?
Also, how do you import said module, this one I don't quite get.
So, something like this:
dll.d:
extern (C) module test;
int foo() {...}
-
main.d
int main(string[] args)
{
...
(dl loading code for dll.so)
module dll = dlsym(lh, "test");
...
}
So, aside from the crappy abstraction, something like that?
Re: Is continuously seeding a random number generator performance intensive?
On Friday, 3 January 2014 at 01:43:09 UTC, Chris Cain wrote: So, it sounds like the OP is using the x and y coords for a seed to generate a single number and he was curious to whether it costs too much to reseed like this for every point. FWIW, I'm under the impression that this is a fairly common strategy, but usually when I've seen this used more than one number is generated at a time. I *thought* he wanted to do something like that, but was surprised by the fact he wanted to reseed *per* element... You can still do this, in this case. For example, divide x by 10 and generate 10 elements (column wise) in the noise map each time and it reduces the number of reseeds by a factor of 10. Some effort might be wasted, but as long as you need a decent chunk of the noise map at any one point in time, this should work out pretty well in practice. My biggest concern with this approach is that you must take care that your usage of seeding with x and y coordinates does not cause repeated elements to occur. For instance, using `Random rng = Random(x + y);` will _not_ work properly (unless you want strange mirroring down the diagonal in your noise map). There's numerous landmines to avoid when doing something like this. Some approaches may not be perfect, but depending on what you're doing they may be sufficient, however. The approach I'd take here is to eagerly generate a "uint[X / 1000][Y / 1000]" grid, that holds randomly generated numbers, to be used as seeds for individual 1000*1000 blocks of the noise map. I don't know how good that is though in terms of correlation...? Or, even better, to create a single generator of type "Gen", and store a "Gen[X / 1000][Y / 1000]": EG: the generator, with a "checkpoint" every 1_000_000 elements. This should reduce correlation down to 0. AFAIK, all generators above the "linear congruential generator" have a period above 10^12, so this approach should be fine. The only issue with such an approach might be the size of the PRNG's themselves: XOrShift, for example, is only a few bytes big, so that's fine. But MT is about 700B, which is a hefty amount to chug along.
Re: A little DUB question
Am 31.12.2013 11:35, schrieb thedeemon:
I've missed all the DUB discussions here and couldn't find the answer to
my question in the docs, so here it is, very simple:
I've got an app with one dependency stated in package.json as
"dependencies": {
"pegged": "~master"
}
When I build my app with
dub build --build=release
the app itself gets compiled in release mode, but the library it depends
on (in this case Pegged) gets compiled in Debug, so the binary ends up
2-3 times larger than if I build everything myself without DUB.
What is the right way to build everything in release using DUB here?
Hm, which version do you use? The latest releases don't yet support
building dependencies separately, so I guess it must be a GIT master
version. However, for the latest HEAD, I can't reproduce the issue, so
I'd recommend to pull the latest changes in that case. But there will
also be a new beta release shortly.
