Re: const char* or const(char)* when porting C headers?
22.12.2013 07:47, Gary Willoughby пишет: When porting C headers which include function declarations with using char* types. Is it best to use const char* or const(char)* as the type in the D declaration? C vs D const char* == const(char)* const char const* == const char*
Re: Removing multiple elements from array
On 12/21/2013 05:39 PM, aldanor wrote: > On Saturday, 21 December 2013 at 21:49:01 UTC, MrSmith wrote: >> just use foreach_reverse > > Wow, I never knew it is a keyword, thank you! I feel guilty for omitting in knowingly but we've been hearing that it would be deprecated. I don't think it will ever happen. :-/ Besides, I think retro(), its alternative, is not suitable for recursive algorithms because retro() works only with ranges. I had once tried to do recursive iteration with ranges (probably on a tree) but it had turned out that iteration with opApplyReverse was more natural for recursion. (I may be wrong on my conclusion but that is what I remember now.) Ali
Re: ubytes to ulong problem
On 12/21/2013 05:44 PM, Charles Hixson wrote:
On 12/21/2013 03:52 PM, Ali Çehreli wrote:
On 12/21/2013 03:13 PM, John Colvin wrote:
> Ideally the compiler will optimise your version to be fast, but you may
> find you get better performance by doing the bit manipulations
eplicitly:
Assuming that the program needs to support only big endian and little
endian systems (i.e. excluding systems where no D compiler exists :)),
the following is less wordy and should be equally fast:
import std.bitmanip;
import std.system;
ulong ubytesToUlong(ubyte[] block, size_t n = 0)
in
{
assert (n >= 0);
assert (n + 8 <= block.length);
}
body
{
ulong value = *cast(ulong*)(block.ptr + n);
if (std.system.endian == Endian.littleEndian) {
return *cast(ulong*)(value.nativeToBigEndian.ptr);
} else {
return value;
}
}
Ali
Will that work even when the alignment is to odd bytes? Because that's
the case I was really worried about. The ubyte array is a packed
mixture of types, some of which are isolated bytes.
No, it is not guaranteed to work unless the alignment is right.
How about this, then: :)
import std.array;
ulong ubytesToUlong(ubyte[] block, size_t n = 0)
in
{
assert (n >= 0);
assert (n + 8 <= block.length);
}
body
{
ulong value = block.front;
block.popFront();
foreach (ub; block) {
value <<= 8;
value |= ub;
}
return value;
}
Ali
Re: ubytes to ulong problem
On 12/21/2013 03:52 PM, Ali Çehreli wrote:
On 12/21/2013 03:13 PM, John Colvin wrote:
> Ideally the compiler will optimise your version to be fast, but you may
> find you get better performance by doing the bit manipulations
eplicitly:
Assuming that the program needs to support only big endian and little
endian systems (i.e. excluding systems where no D compiler exists :)),
the following is less wordy and should be equally fast:
import std.bitmanip;
import std.system;
ulong ubytesToUlong(ubyte[] block, size_t n = 0)
in
{
assert (n >= 0);
assert (n + 8 <= block.length);
}
body
{
ulong value = *cast(ulong*)(block.ptr + n);
if (std.system.endian == Endian.littleEndian) {
return *cast(ulong*)(value.nativeToBigEndian.ptr);
} else {
return value;
}
}
Ali
Will that work even when the alignment is to odd bytes? Because that's
the case I was really worried about. The ubyte array is a packed
mixture of types, some of which are isolated bytes.
--
Charles Hixson
Re: Removing multiple elements from array
On Saturday, 21 December 2013 at 21:49:01 UTC, MrSmith wrote: On Saturday, 21 December 2013 at 00:47:04 UTC, aldanor wrote: Is there an efficient method to remove elements with multiple (compile-time-unknown) indices from an array? I currently do something like if (!index.empty) foreach (i; index.sort.reverse) a = a.remove(i); ... which looks a bit awkward. just use foreach_reverse Wow, I never knew it is a keyword, thank you!
Re: const char* or const(char)* when porting C headers?
On Sun, Dec 22, 2013 at 12:47:45AM +, Gary Willoughby wrote: > When porting C headers which include function declarations with > using char* types. Is it best to use const char* or const(char)* > as the type in the D declaration? Doesn't really matter: both work exactly the same way. I kinda prefer "const char*" just because that looks the same as in C.
const char* or const(char)* when porting C headers?
When porting C headers which include function declarations with using char* types. Is it best to use const char* or const(char)* as the type in the D declaration?
Re: ubytes to ulong problem
On Saturday, 21 December 2013 at 23:52:05 UTC, Ali Çehreli wrote:
On 12/21/2013 03:13 PM, John Colvin wrote:
> Ideally the compiler will optimise your version to be fast,
but you may
> find you get better performance by doing the bit
manipulations eplicitly:
Assuming that the program needs to support only big endian and
little endian systems (i.e. excluding systems where no D
compiler exists :)), the following is less wordy and should be
equally fast:
import std.bitmanip;
import std.system;
ulong ubytesToUlong(ubyte[] block, size_t n = 0)
in
{
assert (n >= 0);
assert (n + 8 <= block.length);
}
body
{
ulong value = *cast(ulong*)(block.ptr + n);
if (std.system.endian == Endian.littleEndian) {
return *cast(ulong*)(value.nativeToBigEndian.ptr);
} else {
return value;
}
}
Ali
Nevermind equally fast, that will be much faster. -10 brain
points for me tonight...
Re: ubytes to ulong problem
On 12/21/2013 03:13 PM, John Colvin wrote:
> Ideally the compiler will optimise your version to be fast, but you may
> find you get better performance by doing the bit manipulations eplicitly:
Assuming that the program needs to support only big endian and little
endian systems (i.e. excluding systems where no D compiler exists :)),
the following is less wordy and should be equally fast:
import std.bitmanip;
import std.system;
ulong ubytesToUlong(ubyte[] block, size_t n = 0)
in
{
assert (n >= 0);
assert (n + 8 <= block.length);
}
body
{
ulong value = *cast(ulong*)(block.ptr + n);
if (std.system.endian == Endian.littleEndian) {
return *cast(ulong*)(value.nativeToBigEndian.ptr);
} else {
return value;
}
}
Ali
Re: ubytes to ulong problem
On 12/21/2013 02:31 PM, ponce wrote:
On Saturday, 21 December 2013 at 22:29:59 UTC, ponce wrote:
On Saturday, 21 December 2013 at 22:22:09 UTC, Charles Hixson wrote:
I was planning to ask if there were a better way to do this, but
instead I need to ask what's my mistake?
For some reason, if called with an uninitialized ubyte array, and an
index of 0, it returns a value of 8, even though all the values in
the array are 0.
The error has to be somewhere in the "ret = " statement, but I sure
don't see it.
/**Convert 8 consecutive bytes sliced from a ubyte[] into a ulong
* @paramblockThe array from which to slice.
* @paramnThe starting index within the block*/
ulongubytesToUlong(ubyte[] block, int n)
{ulongret;
assert (n >= 0);
assert (n + 8 <= block.length);
writefln ("n = %s", n);
writefln ("block[0] = %s", cast(ulong)block[0]);
writefln ("block[1] = %s", cast(ulong)block[1]);
writefln ("block[2] = %s", cast(ulong)block[2]);
writefln ("block[3] = %s", cast(ulong)block[3]);
writefln ("block[4] = %s", cast(ulong)block[4]);
writefln ("block[5] = %s", cast(ulong)block[5]);
writefln ("block[6] = %s", cast(ulong)block[6]);
writefln ("block[7] = %s", cast(ulong)block[7]);
ret=cast(ulong)block[n] * 2^21
+cast(ulong)block[n+1] * 2^18
+cast(ulong)block[n+2] * 2^15
+cast(ulong)block[n+3] * 2^12
+cast(ulong)block[n+4] * 2^9
+cast(ulong)block[n+5] * 2^6
+cast(ulong)block[n+6] * 2^3
+cast(ulong)block[n+7] * 2^0;
writefln ("ret = %s", ret);
returnret;
}
Use the exponentiation operator which is spelled: ^^
Thanks. I was *sure* it was something stupid on my part. It's 'good'
to know that I was right about *that*.
--
Charles Hixson
Re: sending an Exception and print it
I just wanted to add that the "can't format immutable Exception" also prevents me from doing this: auto exception = receiveOnly!(immutable Exception)(); because receiveOnly creates a tuple which implements a toString that uses indirectly uses formatObject. So I'm forced to use the slightly more clunky recieve() as seen on DPaste.
sending an Exception and print it
I'm sending an exception from a worker thread to the owner thread to be logged/printed. Using DMD64 D Compiler v2.064 http://dpaste.dzfl.pl/7c8b68bd Using std.concurrency prevents me from passing a naked Exception. So the owner receives either a shared or immutable Exception. I can't format a shared Exception: /usr/include/dmd/phobos/std/format.d(2602): Error: static assert "unable to format shared objects" I can't format an immutable Exception: /usr/include/dmd/phobos/std/format.d(2610): Error: template instance formatObject!(Appender!string, immutable(Exception), char) does not match template declaration formatObject(Writer, T, Char)(ref Writer w, ref T val, ref FormatSpec!Char f) if (hasToString!(T, Char)) What gives? I expected the immutable Exception to be formattable. My current workaround is to cast to const Exception. Is there something else I should be doing here?
Re: Compiling D inside of a D program
On Saturday, 21 December 2013 at 23:00:20 UTC, Mineko wrote: On Saturday, 21 December 2013 at 22:51:53 UTC, John Colvin wrote: On Saturday, 21 December 2013 at 22:18:58 UTC, Mineko wrote: On Saturday, 21 December 2013 at 22:07:42 UTC, John Colvin wrote: To the best of my knowledge it's totally ok to have your program download the latest zip from dlang.org on the client machine and use that. Sounds good to me, I more or less know what to do now, I'll be using DMD because of it's fast code compilation which is going to be KEY especially to multiplayer games, I would have LIKED to use GDC, but like I said, fast compilation times. (Or perhaps someone has an idea there..?) How fast do you actually need it to be? Fast enough to where the engine is not spending 5 minutes compiling a heavily scripted (multiplayer usually) game, perhaps gdc -0fast would do it? -Ofast means fast code, not fast compilation. For a scripting layer, dmd is probably the best choice. If the scripts get really big you might still run in to some problems. If they remain small (or at least the bit that neds recompiling is small) then gdc/ldc would still be viable.
Re: ubytes to ulong problem
On Saturday, 21 December 2013 at 22:22:09 UTC, Charles Hixson
wrote:
I was planning to ask if there were a better way to do this,
but instead I need to ask what's my mistake?
For some reason, if called with an uninitialized ubyte array,
and an index of 0, it returns a value of 8, even though all the
values in the array are 0.
The error has to be somewhere in the "ret = " statement, but I
sure don't see it.
/**Convert 8 consecutive bytes sliced from a ubyte[] into a
ulong
* @paramblockThe array from which to slice.
* @paramnThe starting index within the block*/
ulongubytesToUlong(ubyte[] block, int n)
{ulongret;
assert (n >= 0);
assert (n + 8 <= block.length);
writefln ("n = %s", n);
writefln ("block[0] = %s", cast(ulong)block[0]);
writefln ("block[1] = %s", cast(ulong)block[1]);
writefln ("block[2] = %s", cast(ulong)block[2]);
writefln ("block[3] = %s", cast(ulong)block[3]);
writefln ("block[4] = %s", cast(ulong)block[4]);
writefln ("block[5] = %s", cast(ulong)block[5]);
writefln ("block[6] = %s", cast(ulong)block[6]);
writefln ("block[7] = %s", cast(ulong)block[7]);
ret=cast(ulong)block[n] * 2^21
+cast(ulong)block[n+1] * 2^18
+cast(ulong)block[n+2] * 2^15
+cast(ulong)block[n+3] * 2^12
+cast(ulong)block[n+4] * 2^9
+cast(ulong)block[n+5] * 2^6
+cast(ulong)block[n+6] * 2^3
+cast(ulong)block[n+7] * 2^0;
writefln ("ret = %s", ret);
returnret;
}
As pointed out before, you're using '^' which is xor, instead of
^^. Ideally the compiler will optimise your version to be fast,
but you may find you get better performance by doing the bit
manipulations eplicitly:
/**Convert 8 consecutive bytes sliced from a ubyte[]
* to a ulong using bigendian byte ordering.
* @paramblockThe array from which to slice.
* @paramnThe starting index within the block, default 0*/
ulong ubytesToUlong(ubyte[] block, size_t n = 0)
in
{
assert (n >= 0);
assert (n + 8 <= block.length);
}
body
{
return ((cast(ulong)block[n ]) << 56)
| ((cast(ulong)block[n+1]) << 48)
| ((cast(ulong)block[n+2]) << 40)
| ((cast(ulong)block[n+3]) << 32)
| ((cast(ulong)block[n+4]) << 24)
| ((cast(ulong)block[n+5]) << 16)
| ((cast(ulong)block[n+6]) << 8)
| (cast(ulong)block[n+7]);
}
unittest
{
ubyte[8] a = [0,0,0,0,0,0,0,0];
assert(a[].ubytesToUlong() == 0);
a[7] = 3;
a[6] = 1;
assert(a[].ubytesToUlong() == 259);
}
Re: Compiling D inside of a D program
On Saturday, 21 December 2013 at 22:51:53 UTC, John Colvin wrote: On Saturday, 21 December 2013 at 22:18:58 UTC, Mineko wrote: On Saturday, 21 December 2013 at 22:07:42 UTC, John Colvin wrote: To the best of my knowledge it's totally ok to have your program download the latest zip from dlang.org on the client machine and use that. Sounds good to me, I more or less know what to do now, I'll be using DMD because of it's fast code compilation which is going to be KEY especially to multiplayer games, I would have LIKED to use GDC, but like I said, fast compilation times. (Or perhaps someone has an idea there..?) How fast do you actually need it to be? Fast enough to where the engine is not spending 5 minutes compiling a heavily scripted (multiplayer usually) game, perhaps gdc -0fast would do it?
Re: Compiling D inside of a D program
On Saturday, 21 December 2013 at 22:18:58 UTC, Mineko wrote: On Saturday, 21 December 2013 at 22:07:42 UTC, John Colvin wrote: To the best of my knowledge it's totally ok to have your program download the latest zip from dlang.org on the client machine and use that. Sounds good to me, I more or less know what to do now, I'll be using DMD because of it's fast code compilation which is going to be KEY especially to multiplayer games, I would have LIKED to use GDC, but like I said, fast compilation times. (Or perhaps someone has an idea there..?) How fast do you actually need it to be?
Re: ubytes to ulong problem
On Saturday, 21 December 2013 at 22:29:59 UTC, ponce wrote:
On Saturday, 21 December 2013 at 22:22:09 UTC, Charles Hixson
wrote:
I was planning to ask if there were a better way to do this,
but instead I need to ask what's my mistake?
For some reason, if called with an uninitialized ubyte array,
and an index of 0, it returns a value of 8, even though all
the values in the array are 0.
The error has to be somewhere in the "ret = " statement, but I
sure don't see it.
/**Convert 8 consecutive bytes sliced from a ubyte[] into
a ulong
* @paramblockThe array from which to slice.
* @paramnThe starting index within the block*/
ulongubytesToUlong(ubyte[] block, int n)
{ulongret;
assert (n >= 0);
assert (n + 8 <= block.length);
writefln ("n = %s", n);
writefln ("block[0] = %s", cast(ulong)block[0]);
writefln ("block[1] = %s", cast(ulong)block[1]);
writefln ("block[2] = %s", cast(ulong)block[2]);
writefln ("block[3] = %s", cast(ulong)block[3]);
writefln ("block[4] = %s", cast(ulong)block[4]);
writefln ("block[5] = %s", cast(ulong)block[5]);
writefln ("block[6] = %s", cast(ulong)block[6]);
writefln ("block[7] = %s", cast(ulong)block[7]);
ret=cast(ulong)block[n] * 2^21
+cast(ulong)block[n+1] * 2^18
+cast(ulong)block[n+2] * 2^15
+cast(ulong)block[n+3] * 2^12
+cast(ulong)block[n+4] * 2^9
+cast(ulong)block[n+5] * 2^6
+cast(ulong)block[n+6] * 2^3
+cast(ulong)block[n+7] * 2^0;
writefln ("ret = %s", ret);
returnret;
}
Use the exponentiation operator which is spelled: ^^
Re: ubytes to ulong problem
On Saturday, 21 December 2013 at 22:22:09 UTC, Charles Hixson
wrote:
I was planning to ask if there were a better way to do this,
but instead I need to ask what's my mistake?
For some reason, if called with an uninitialized ubyte array,
and an index of 0, it returns a value of 8, even though all the
values in the array are 0.
The error has to be somewhere in the "ret = " statement, but I
sure don't see it.
/**Convert 8 consecutive bytes sliced from a ubyte[] into a
ulong
* @paramblockThe array from which to slice.
* @paramnThe starting index within the block*/
ulongubytesToUlong(ubyte[] block, int n)
{ulongret;
assert (n >= 0);
assert (n + 8 <= block.length);
writefln ("n = %s", n);
writefln ("block[0] = %s", cast(ulong)block[0]);
writefln ("block[1] = %s", cast(ulong)block[1]);
writefln ("block[2] = %s", cast(ulong)block[2]);
writefln ("block[3] = %s", cast(ulong)block[3]);
writefln ("block[4] = %s", cast(ulong)block[4]);
writefln ("block[5] = %s", cast(ulong)block[5]);
writefln ("block[6] = %s", cast(ulong)block[6]);
writefln ("block[7] = %s", cast(ulong)block[7]);
ret=cast(ulong)block[n] * 2^21
+cast(ulong)block[n+1] * 2^18
+cast(ulong)block[n+2] * 2^15
+cast(ulong)block[n+3] * 2^12
+cast(ulong)block[n+4] * 2^9
+cast(ulong)block[n+5] * 2^6
+cast(ulong)block[n+6] * 2^3
+cast(ulong)block[n+7] * 2^0;
writefln ("ret = %s", ret);
returnret;
}
ubytes to ulong problem
I was planning to ask if there were a better way to do this, but instead
I need to ask what's my mistake?
For some reason, if called with an uninitialized ubyte array, and an
index of 0, it returns a value of 8, even though all the values in the
array are 0.
The error has to be somewhere in the "ret = " statement, but I sure
don't see it.
/**Convert 8 consecutive bytes sliced from a ubyte[] into a ulong
* @paramblockThe array from which to slice.
* @paramnThe starting index within the block*/
ulongubytesToUlong(ubyte[] block, int n)
{ulongret;
assert (n >= 0);
assert (n + 8 <= block.length);
writefln ("n = %s", n);
writefln ("block[0] = %s", cast(ulong)block[0]);
writefln ("block[1] = %s", cast(ulong)block[1]);
writefln ("block[2] = %s", cast(ulong)block[2]);
writefln ("block[3] = %s", cast(ulong)block[3]);
writefln ("block[4] = %s", cast(ulong)block[4]);
writefln ("block[5] = %s", cast(ulong)block[5]);
writefln ("block[6] = %s", cast(ulong)block[6]);
writefln ("block[7] = %s", cast(ulong)block[7]);
ret=cast(ulong)block[n] * 2^21
+cast(ulong)block[n+1] * 2^18
+cast(ulong)block[n+2] * 2^15
+cast(ulong)block[n+3] * 2^12
+cast(ulong)block[n+4] * 2^9
+cast(ulong)block[n+5] * 2^6
+cast(ulong)block[n+6] * 2^3
+cast(ulong)block[n+7] * 2^0;
writefln ("ret = %s", ret);
returnret;
}
--
Charles Hixson
Re: Dub and GtkD
On Saturday, 21 December 2013 at 14:52:08 UTC, Russel Winder
wrote:
I just created a new vibe.d project using dub, all fine. Well
once I had
solved the libevent problem. Then, as the project is to be a
GUI client,
I added a gtk-d dependency. I tried building the empty project
and the
binary comes out at 42MB. Not only that there are two copies of
it one
in . and one in ./.dub/build. I was gobsmacked, this isn't Go,
there
should be dynamic linking by default. Is this something I have
missed?
There ought to be a clean target for dub as well as a build and
run
target for dub, or have I missed something?
Re GtkD, when I run the "Hello World" vibe.d web server with
GtkD doing
nothing, I get:
|> dub
Checking dependencies in
'/home/users/russel/Repositories/Git/Masters/ArcamClient_D'
Target is up to date. Skipping build.
Running ./arcamclient
Listening for HTTP requests on ::1:8080
Listening for HTTP requests on 127.0.0.1:8080
Please open http://127.0.0.1:8080/ in your browser.
object.Exception@../../../../.dub/packages/gtk-d-master/src/gtkc/Loader.d(127):
Library load failed: libgtkglext-3.0.so.0
Error: Program exited with code 1
In an earlier thread here, Mike Wey's response was "download
libgtkglext
and build it yourself". I am not sure this is the right
approach. Debian
packages GNOME 3 quite well but they do not have this
libgtkglext-3.0.so.0 and yet things work. I think mayhap GtkD
should
have this as an optional dependency rather than a mandatory
one. Or am I
missing something?
For some reason GtkD uses some unreleased version of Gtk with
some OpenGL features. You can use the "normal/stable" variant by
adapting your dependency a little:
"dependencies": { "gtk-d:gtkd": "~master" }
Not sure, why GtkD does this. There are also no versions, just
"~master".
Re: Compiling D inside of a D program
On Saturday, 21 December 2013 at 22:07:42 UTC, John Colvin wrote: To the best of my knowledge it's totally ok to have your program download the latest zip from dlang.org on the client machine and use that. Sounds good to me, I more or less know what to do now, I'll be using DMD because of it's fast code compilation which is going to be KEY especially to multiplayer games, I would have LIKED to use GDC, but like I said, fast compilation times. (Or perhaps someone has an idea there..?)
Re: Dub and GtkD
On 2013-12-21 15:51, Russel Winder wrote: I just created a new vibe.d project using dub, all fine. Well once I had solved the libevent problem. Then, as the project is to be a GUI client, I added a gtk-d dependency. I tried building the empty project and the binary comes out at 42MB. Not only that there are two copies of it one in . and one in ./.dub/build. I was gobsmacked, this isn't Go, there should be dynamic linking by default. Is this something I have missed? There ought to be a clean target for dub as well as a build and run target for dub, or have I missed something? I don't know if this is the issue in this case but Dub build everything at once. The correct solution in this case would be to build GtkD separate from the application. This is planed in a future release of Dub, hopefully the next release. Have a look at this thread: http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/652/ -- /Jacob Carlborg
Re: Compiling D inside of a D program
On Saturday, 21 December 2013 at 21:58:16 UTC, Mineko wrote: On Saturday, 21 December 2013 at 10:00:10 UTC, Kelet wrote: On Saturday, 21 December 2013 at 08:55:04 UTC, Mineko wrote: This is a fairly basic question but I can't find any good answers, so I'm asking.. Anyways, I want to be able to invoke the D compiler, whichever that might be from inside of a D program, so I can say, compile a D script on-the-fly in some game, it's just an idea though. To be even more to the point, how can I invoke the D compiler inside of a D program, also, do I need to bundle said D compiler with my program or does D have some compilation feature inside of an already compiled program (Which I doubt)? Hi, I was also interested in this topic. My research suggests that there is no easy or safe way to do this at the moment, as thedeemon suggests. Although I think it's worth offering a possible alternative: using a scripting language binding like LuaD[1], DerelictLua[2], or pyd[3]. From here, you can expose some functions/variables between them, and solve a lot of the same problems. That being said, I think it would be useful to have something like JavaCompiler[4]. It's not an optimal solution, but combined with a minimal compiler package it could help a lot. As far as I know, you need to ask permission to distribute DMD with your application, so it may be safer to include GDC or LDC if you want to go this route. Or ask Walter, of course. [1]: https://github.com/JakobOvrum/LuaD [2]: https://github.com/DerelictOrg/DerelictLua [3]: https://bitbucket.org/ariovistus/pyd [4]: http://docs.oracle.com/javase/7/docs/api/javax/tools/JavaCompiler.html Regards, Kelet Would it be legal to have my program automatically download some dmd binary, that way I could always keep it up to date? Given Walter here doesn't absolutely forbid my program does that. To the best of my knowledge it's totally ok to have your program download the latest zip from dlang.org on the client machine and use that.
Re: Compiling D inside of a D program
On Saturday, 21 December 2013 at 10:00:10 UTC, Kelet wrote: On Saturday, 21 December 2013 at 08:55:04 UTC, Mineko wrote: This is a fairly basic question but I can't find any good answers, so I'm asking.. Anyways, I want to be able to invoke the D compiler, whichever that might be from inside of a D program, so I can say, compile a D script on-the-fly in some game, it's just an idea though. To be even more to the point, how can I invoke the D compiler inside of a D program, also, do I need to bundle said D compiler with my program or does D have some compilation feature inside of an already compiled program (Which I doubt)? Hi, I was also interested in this topic. My research suggests that there is no easy or safe way to do this at the moment, as thedeemon suggests. Although I think it's worth offering a possible alternative: using a scripting language binding like LuaD[1], DerelictLua[2], or pyd[3]. From here, you can expose some functions/variables between them, and solve a lot of the same problems. That being said, I think it would be useful to have something like JavaCompiler[4]. It's not an optimal solution, but combined with a minimal compiler package it could help a lot. As far as I know, you need to ask permission to distribute DMD with your application, so it may be safer to include GDC or LDC if you want to go this route. Or ask Walter, of course. [1]: https://github.com/JakobOvrum/LuaD [2]: https://github.com/DerelictOrg/DerelictLua [3]: https://bitbucket.org/ariovistus/pyd [4]: http://docs.oracle.com/javase/7/docs/api/javax/tools/JavaCompiler.html Regards, Kelet Would it be legal to have my program automatically download some dmd binary, that way I could always keep it up to date? Given Walter here doesn't absolutely forbid my program does that.
Re: Removing multiple elements from array
On Saturday, 21 December 2013 at 00:47:04 UTC, aldanor wrote: Is there an efficient method to remove elements with multiple (compile-time-unknown) indices from an array? I currently do something like if (!index.empty) foreach (i; index.sort.reverse) a = a.remove(i); ... which looks a bit awkward. just use foreach_reverse
Re: Why is compilation failing with this selective import?
On 12/21/2013 09:56 PM, Nick Hamann wrote:
I'm not sure if this is a bug or if I'm doing something wrong.
Compilation succeeds and the program runs successfully with this code:
import std.stdio;
import std.conv : to;
void main() {
auto x = std.conv.to!double("7.3");
writeln(x - 2.2);
}
...
The first import seems to introduce the identifier 'std' (+ more). The
second import seems to introduce 'conv' into the scope of 'std'.
However, when I change the first line to "import std.stdio : writeln;",
I instead get:
: dmd main.d
main.d(5): Error: undefined identifier std
...
Now it does not introduce the identifier 'std'.
I'm running DMD 2.064 on 64-bit Arch Linux.
This part of the language is not specified too well. It cannot hurt to
report this though. The current behaviour is non-modular, as which
modules are available depends on which modules you imported transitively.
Why is compilation failing with this selective import?
I'm not sure if this is a bug or if I'm doing something wrong.
Compilation succeeds and the program runs successfully with this
code:
import std.stdio;
import std.conv : to;
void main() {
auto x = std.conv.to!double("7.3");
writeln(x - 2.2);
}
However, when I change the first line to "import std.stdio :
writeln;", I instead get:
: dmd main.d
main.d(5): Error: undefined identifier std
I'm running DMD 2.064 on 64-bit Arch Linux.
Re: Thrift maintained..?
On Friday, 15 November 2013 at 21:11:36 UTC, simendsjo wrote: I thrid compiling thrift 0.9.1 from github with d support, but there's a bug in the makefile it seems. $(addprefix.log: $(addprefix @p='$(addprefix'; \ b='$(addprefix'; \ $(am__check_pre) $(LOG_DRIVER) --test-name "$$f" \ --log-file $$b.log --trs-file $$b.trs \ $(am__common_driver_flags) $(AM_LOG_DRIVER_FLAGS) $(LOG_DRIVER_FLAGS) -- $(LOG_COMPILE) \ "$$tst" $(AM_TESTS_FD_REDIRECT) The error is reported at the first line with the message: Makefile:1206: *** unterminated variable reference. Stop. Can anyone spot the error? (And preferably send a pull request so I don't take the credit :) ) Rebuild autoconf and automake files? Try ./bootstrap.sh && ./configure && make.
Re: Thrift maintained..?
On 11/15/2013 01:11 PM, simendsjo wrote: I thrid compiling thrift 0.9.1 from github with d support, but there's a bug in the makefile it seems. $(addprefix.log: $(addprefix @p='$(addprefix'; \ b='$(addprefix'; \ $(am__check_pre) $(LOG_DRIVER) --test-name "$$f" \ --log-file $$b.log --trs-file $$b.trs \ $(am__common_driver_flags) $(AM_LOG_DRIVER_FLAGS) $(LOG_DRIVER_FLAGS) -- $(LOG_COMPILE) \ "$$tst" $(AM_TESTS_FD_REDIRECT) The error is reported at the first line with the message: Makefile:1206: *** unterminated variable reference. Stop. Can anyone spot the error? (And preferably send a pull request so I don't take the credit :) ) addprefix is a make function: http://www.gnu.org/software/make/manual/html_node/File-Name-Functions.html $(addprefix prefix,names...) None of the addprefix calls in that excerpt look correct. :-/ Ali
Re: Thrift maintained..?
On Friday, 15 November 2013 at 21:11:36 UTC, simendsjo wrote: I thrid compiling thrift 0.9.1 from github with d support, but there's a bug in the makefile it seems. $(addprefix.log: $(addprefix @p='$(addprefix'; \ b='$(addprefix'; \ $(am__check_pre) $(LOG_DRIVER) --test-name "$$f" \ --log-file $$b.log --trs-file $$b.trs \ $(am__common_driver_flags) $(AM_LOG_DRIVER_FLAGS) $(LOG_DRIVER_FLAGS) -- $(LOG_COMPILE) \ "$$tst" $(AM_TESTS_FD_REDIRECT) The error is reported at the first line with the message: Makefile:1206: *** unterminated variable reference. Stop. Can anyone spot the error? (And preferably send a pull request so I don't take the credit :) ) I ran into this same problem but haven't had time to look into what is required to fix it. We need someone more familiar with make to figure it out. I imagine the problem is related to the unbalanced parens.
Vibe.d and testing
Is there a way of mocking the TCPConnect call so as to create a connection to a mock instead of the real device so as to be able to integration test and system test a vibe.d-based client? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Dub and GtkD
I just created a new vibe.d project using dub, all fine. Well once I had solved the libevent problem. Then, as the project is to be a GUI client, I added a gtk-d dependency. I tried building the empty project and the binary comes out at 42MB. Not only that there are two copies of it one in . and one in ./.dub/build. I was gobsmacked, this isn't Go, there should be dynamic linking by default. Is this something I have missed? There ought to be a clean target for dub as well as a build and run target for dub, or have I missed something? Re GtkD, when I run the "Hello World" vibe.d web server with GtkD doing nothing, I get: |> dub Checking dependencies in '/home/users/russel/Repositories/Git/Masters/ArcamClient_D' Target is up to date. Skipping build. Running ./arcamclient Listening for HTTP requests on ::1:8080 Listening for HTTP requests on 127.0.0.1:8080 Please open http://127.0.0.1:8080/ in your browser. object.Exception@../../../../.dub/packages/gtk-d-master/src/gtkc/Loader.d(127): Library load failed: libgtkglext-3.0.so.0 Error: Program exited with code 1 In an earlier thread here, Mike Wey's response was "download libgtkglext and build it yourself". I am not sure this is the right approach. Debian packages GNOME 3 quite well but they do not have this libgtkglext-3.0.so.0 and yet things work. I think mayhap GtkD should have this as an optional dependency rather than a mandatory one. Or am I missing something? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: "a[++i] = i" vs "a[i] = ++i"
aldanor: So should this considered a bug then and be filed? I think so. I have a related EnhancementRequest open, but I have to close it down or modify it... Bye, bearophile
Re: Removing multiple elements from array
On Saturday, 21 December 2013 at 02:52:00 UTC, bearophile wrote:
Do not forget to add the () after the sort, otherwise you call
the deprecated, buggy and slow built-in sort.
reverse is another deprecated built-in, so use "retro".
The first "if" is not much useful, trying to sort an empty
array will not wast much time.
foreach (i; index.sort().retro)
a = a.remove(i);
In alternative you can also invert the sorting cmp (untested):
foreach (i; index.sort!q{a > b})
a = a.remove(i);
Thanks, that looks like the cleanest solution so far! So (I
guess) it will not cause index.length reallocations by just
moving the elements in-place and then returning a slice?
P.S. I wonder where would one learn about the deprecated sort and
reverse if not from this forum? I followed the official docs and
there's nothing about these properties being deprecated... yet
another spot where a compiler warning would be appropriate?
Re: Removing multiple elements from array
On Saturday, 21 December 2013 at 03:22:22 UTC, H. S. Teoh wrote: Unfortunately, while std.algorithm.remove does provide a way to do this if the number of indices to remove are known beforehand, it doesn't seem to be able to remove a dynamic list of indices. Probably an enhancement request should be filed: http://d.puremagic.com/issues If the number of indices to remove are fixed, though, you can do this: import std.algorithm : remove; int[] arr = [ ... ]; int i1, i2, i3; // indices to remove arr = arr.remove(i1, i2, i3); Yes, this is exactly why I opened this thread initially, I noticed this functionality in .remove() and was native enough to assume there's a shortcut for batch removal with indices unknown in advance :)
Re: "a[++i] = i" vs "a[i] = ++i"
On Saturday, 21 December 2013 at 02:56:57 UTC, Dicebot wrote: No. There is no such thing as "suitable compiler warning". So should this considered a bug then and be filed? (if that will do any good, lol)
Re: Circular Buffer
On Friday, 20 December 2013 at 15:45:04 UTC, Frustrated wrote: I'm in need of a circular buffer/array. I am using std.container.array to avoid the GC. I suppose I could copy and modify the code but is there any easier way? It looks like it is defined as templates so could I somehow hijack the code and modify only what is needed rather than duplicate a lot of stuff? (or maybe someone could just add it to the library... circular arrays are useful ya know ;) Writing your own should be quite simple. I see others have already added some implementations, so I'll add mine too. Modifying it to use a static array shouldn't be too difficult, but you're probably better off using some of the others code as this is dynamic and haven't been used in production. https://gist.github.com/simendsjo/3b8a9c60bd92e16691d7
Re: Compiling D inside of a D program
On Saturday, 21 December 2013 at 08:55:04 UTC, Mineko wrote: This is a fairly basic question but I can't find any good answers, so I'm asking.. Anyways, I want to be able to invoke the D compiler, whichever that might be from inside of a D program, so I can say, compile a D script on-the-fly in some game, it's just an idea though. To be even more to the point, how can I invoke the D compiler inside of a D program, also, do I need to bundle said D compiler with my program or does D have some compilation feature inside of an already compiled program (Which I doubt)? Hi, I was also interested in this topic. My research suggests that there is no easy or safe way to do this at the moment, as thedeemon suggests. Although I think it's worth offering a possible alternative: using a scripting language binding like LuaD[1], DerelictLua[2], or pyd[3]. From here, you can expose some functions/variables between them, and solve a lot of the same problems. That being said, I think it would be useful to have something like JavaCompiler[4]. It's not an optimal solution, but combined with a minimal compiler package it could help a lot. As far as I know, you need to ask permission to distribute DMD with your application, so it may be safer to include GDC or LDC if you want to go this route. Or ask Walter, of course. [1]: https://github.com/JakobOvrum/LuaD [2]: https://github.com/DerelictOrg/DerelictLua [3]: https://bitbucket.org/ariovistus/pyd [4]: http://docs.oracle.com/javase/7/docs/api/javax/tools/JavaCompiler.html Regards, Kelet
Re: Compiling D inside of a D program
I still hope they make DMD available as shared/static library just like tinyc compiler! On Saturday, 21 December 2013 at 08:55:04 UTC, Mineko wrote: This is a fairly basic question but I can't find any good answers, so I'm asking.. Anyways, I want to be able to invoke the D compiler, whichever that might be from inside of a D program, so I can say, compile a D script on-the-fly in some game, it's just an idea though. To be even more to the point, how can I invoke the D compiler inside of a D program, also, do I need to bundle said D compiler with my program or does D have some compilation feature inside of an already compiled program (Which I doubt)?
Re: Compiling D inside of a D program
On Saturday, 21 December 2013 at 08:55:04 UTC, Mineko wrote: To be even more to the point, how can I invoke the D compiler inside of a D program, also, do I need to bundle said D compiler with my program or does D have some compilation feature inside of an already compiled program (Which I doubt)? D runtime doesn't include any compilation abilities, it's not a Lisp. You'll need to invoke the compiler as a separate process. Look at this example: http://dlang.org/phobos/std_process.html#.execute
Compiling D inside of a D program
This is a fairly basic question but I can't find any good answers, so I'm asking.. Anyways, I want to be able to invoke the D compiler, whichever that might be from inside of a D program, so I can say, compile a D script on-the-fly in some game, it's just an idea though. To be even more to the point, how can I invoke the D compiler inside of a D program, also, do I need to bundle said D compiler with my program or does D have some compilation feature inside of an already compiled program (Which I doubt)?
Re: Circular Buffer
On Friday, 20 December 2013 at 15:45:04 UTC, Frustrated wrote: I'm in need of a circular buffer/array. I am using std.container.array to avoid the GC. I suppose I could copy and modify the code but is there any easier way? It looks like it is defined as templates so could I somehow hijack the code and modify only what is needed rather than duplicate a lot of stuff? (or maybe someone could just add it to the library... circular arrays are useful ya know ;) http://p0nce.github.io/gfm/gfm.core.queue.html#RingBuffer < and use malloc instead of .length
