Build all at once or…
There seems a dichotomy between explicitly compile each d file (aka module) and then link versus compile all the files (aka modules) at once especially since the objects for each file/module are created in both cases. I am assuming there are also some DMD/GDC/LDC2 differences as well. Currently Dub is compile all source at once and SCons is compile each file individually and then link (though I am currently using SCons in a compile all source at once as an experiment to see what needs to happen to the SCons D build support. Is there some critical feature which means that compile all source at once is a better route? -- 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: Build all at once or…
On Sunday, December 22, 2013 08:21:34 Russel Winder wrote: There seems a dichotomy between explicitly compile each d file (aka module) and then link versus compile all the files (aka modules) at once especially since the objects for each file/module are created in both cases. I am assuming there are also some DMD/GDC/LDC2 differences as well. Currently Dub is compile all source at once and SCons is compile each file individually and then link (though I am currently using SCons in a compile all source at once as an experiment to see what needs to happen to the SCons D build support. Is there some critical feature which means that compile all source at once is a better route? 1. Unless you compile each of the separate files in parallel, it's faster to compile everything at once, because you avoid having to reprocess all of the imported modules. Parallel compiling still has to do all of that work, but the gains from compiling multiple at the same time will likely offset it. 2. As I understand it, there's at least one outstanding bug where the symbols can get screwed up if you build stuff separately. Unfortunately, I don't remember the details or the bug number, but it's generally brought up when anyone tries to promote doing incremental builds. - Jonathan M Davis
Re: ubytes to ulong problem
On 12/21/2013 07:57 PM, Ali Çehreli wrote:
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
Nice, but the block is longer than 8 bytes, so I should use a for (i =
n; i n + 8; i++) rather than a foreach, and index off of i. I
clearly need to redo the documentation a bit (even though it's form me
of a few months from now). It needs to say something like Convert a 8
byte slice from a ubyte array starting at index n into a ulong. n
should always be required to be specified, so I don't want a default
value. (0 was used as a test case, because I'd made a really stupid
mistake and used ^ for exponentiation, and then couldn't see what was
going on, so I was simplifying everything...and I still couldn't see
it. Actually the array starts with a ushort, which specifies the number
of ulongs to follow before a bunch of bytes that are unintelligible data
to the class that's using this function. (OTOH, it seems like something
generally useful, so I'll probably put it in a utils.d file, with some
other generally useful routines.)
OTOH, if I'm going to consider this to be a general utility function,
then I really don't want to make assumptions about where things start,
etc. Perhaps I should throw an exception (other than assertion error)
if the index is bad or the array is to short for the given index. I
need to think about that a bit more. The alternative is to use enforce
rather than assertions...though as long as I'm the only user assertions
suffice. (It's not going to be separately compiled.)
--
Charles Hixson
Re: ubytes to ulong problem
On 12/22/2013 01:04 AM, Charles Hixson wrote: Nice, but the block is longer than 8 bytes, so I should use a for (i = n; i n + 8; i++) rather than a foreach, and index off of i. Makes sense. That reminded me of the Phobos function that does exactly what you want. Have you considered std.bitmanip.read? Ali
Re: Build all at once or…
On Sun, 2013-12-22 at 01:03 -0800, Jonathan M Davis wrote: […] 1. Unless you compile each of the separate files in parallel, it's faster to compile everything at once, because you avoid having to reprocess all of the imported modules. Parallel compiling still has to do all of that work, but the gains from compiling multiple at the same time will likely offset it. I can see this being so where many files are changed between builds, but I am working in a situation where I want to build and run after each change of a file. So with large numbers of files only compiling one and linking seems faster than compiling all. 2. As I understand it, there's at least one outstanding bug where the symbols can get screwed up if you build stuff separately. Unfortunately, I don't remember the details or the bug number, but it's generally brought up when anyone tries to promote doing incremental builds. It would be good to uncover this one in more detail as the current SCons build strategy is always separate compilation. If anyone can add to Jonathan's point here, that would be great. -- 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: ubytes to ulong problem
On Sunday, 22 December 2013 at 03:57:38 UTC, Ali Çehreli wrote:
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.
It's just an unaligned load. If your target cpu architecture
can't do unaligned loads then you're either using something very
small or very old.
Re: Dub and GtkD
On 12/21/2013 11:19 PM, qznc wrote:
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.
This is because the released version of GtkGLext doesn't support Gtk+ 3.x.
You can use the normal/stable variant by adapting
your dependency a little:
dependencies: { gtk-d:gtkd: ~master }
Just depending on the subpackage you need will stop dub from including
the other parts of GtkD in your app. So this should fix your problem.
Not sure, why GtkD does this. There are also no versions, just ~master.
--
Mike Wey
Re: Build all at once or…
On 2013-12-22 11:44, Russel Winder wrote: I can see this being so where many files are changed between builds, but I am working in a situation where I want to build and run after each change of a file. So with large numbers of files only compiling one and linking seems faster than compiling all. There is a big chance this will result in link errors. I don't remember the exact problems but it's something like DMD doesn't emit template symbols to all object files it should. You can search these newsgroups for incremental complication. It was quite easy to find: http://www.digitalmars.com/d/archives/digitalmars/D/Incremental_compilation_with_DMD_96138.html -- /Jacob Carlborg
Re: Build all at once or…
On 2013-12-22 10:03, Jonathan M Davis wrote: 1. Unless you compile each of the separate files in parallel, it's faster to compile everything at once, because you avoid having to reprocess all of the imported modules. Parallel compiling still has to do all of that work, but the gains from compiling multiple at the same time will likely offset it. This probably also depends on how many files that need to be compiled. If there are many files it might be a good idea to compile a couple of files in parallel. It might be interesting to do some experimentation. -- /Jacob Carlborg
Re: Build all at once or…
On Sunday, December 22, 2013 10:44:15 Russel Winder wrote: On Sun, 2013-12-22 at 01:03 -0800, Jonathan M Davis wrote: […] 1. Unless you compile each of the separate files in parallel, it's faster to compile everything at once, because you avoid having to reprocess all of the imported modules. Parallel compiling still has to do all of that work, but the gains from compiling multiple at the same time will likely offset it. I can see this being so where many files are changed between builds, but I am working in a situation where I want to build and run after each change of a file. So with large numbers of files only compiling one and linking seems faster than compiling all. Possibly, but dmd is so fast that the linking portion is often what takes the longest, so I wouldn't even worry about separate compilation until I had a very large project. I wouldn't expect any real gain for smaller projects, and it's definitely the case that the compiler has to do more work when compiling each file separately, so without parallelizing builds, I fully expect that incremental compilation will be slower until a project gets fairly large. But you'd have to experiment to figure out what the exact performance characteristics are. 2. As I understand it, there's at least one outstanding bug where the symbols can get screwed up if you build stuff separately. Unfortunately, I don't remember the details or the bug number, but it's generally brought up when anyone tries to promote doing incremental builds. It would be good to uncover this one in more detail as the current SCons build strategy is always separate compilation. If anyone can add to Jonathan's point here, that would be great. Searching for posts on incremental compilation in the newsgroup will likely turn it up fairly quickly. But when you add that bug on top of the fact that incremental compilation is unlikely to garner much in the way of performance gains except for larger projects, I never bother with incremental compilation at this point and wouldn't bother with it until compilation times were getting large. - Jonathan M Davis
GtkD - how to install
Hello, I'm beginning with programming on desktop. After choosing which language is da best for me, I chose D. And now I want to create GUI applications, so I tried installing GtkD and I failed. Can anybody give me a short manual? I'd like to code on linux (openSUSE 13.1), but if I'll get help on Windows, I'll be happy too. Thank you
Re: GtkD - how to install
On Sunday, 22 December 2013 at 13:29:04 UTC, Amateur wrote: Hello, I'm beginning with programming on desktop. After choosing which language is da best for me, I chose D. And now I want to create GUI applications, so I tried installing GtkD and I failed. Can anybody give me a short manual? I'd like to code on linux (openSUSE 13.1), but if I'll get help on Windows, I'll be happy too. Thank you I would recommend using dub. Either download a release from http://code.dlang.org/download or clone the github repo https://github.com/rejectedsoftware/dub and build with build.sh then you can list gtkd as a dependency for your project and dub will sort it out for you (hopefully). You will need to install the latest gtk+ libs first with yast or zipper or whatever you use for package management.
Generating assembly from dmd
Hi all, Can someone walk me through in a friendly way how to check the assembly produced by dmd? The application in this case is checking some new patches to Phobos. It's something I'm not familiar with doing in general and particularly not with dmd (which doesn't seem to have an assembly-output switch), so I'm hoping someone can advise :-) Thanks best wishes, -- Joe
Re: GtkD - how to install
On Sunday, 22 December 2013 at 13:38:25 UTC, John Colvin wrote: On Sunday, 22 December 2013 at 13:29:04 UTC, Amateur wrote: Hello, I'm beginning with programming on desktop. After choosing which language is da best for me, I chose D. And now I want to create GUI applications, so I tried installing GtkD and I failed. Can anybody give me a short manual? I'd like to code on linux (openSUSE 13.1), but if I'll get help on Windows, I'll be happy too. Thank you I would recommend using dub. Either download a release from http://code.dlang.org/download or clone the github repo https://github.com/rejectedsoftware/dub and build with build.sh then you can list gtkd as a dependency for your project and dub will sort it out for you (hopefully). You will need to install the latest gtk+ libs first with yast or zipper or whatever you use for package management. Yeah, I installed dub and ran commands dub init main and dub fetch --local gtk-d. It worked properly, but how to continue? I tried compile simple app which contains only import gtk.MainWindow; and compiler yells that source for this cannot be found. What have I to do next? I have installed Gtk+ libraries, dmd, dub and I ran too commands dub init main and dub fetch --local gtk-d.
Re: Generating assembly from dmd
On Sunday, 22 December 2013 at 14:17:50 UTC, Joseph Rushton Wakeling wrote: Hi all, Can someone walk me through in a friendly way how to check the assembly produced by dmd? The application in this case is checking some new patches to Phobos. It's something I'm not familiar with doing in general and particularly not with dmd (which doesn't seem to have an assembly-output switch), so I'm hoping someone can advise :-) Thanks best wishes, -- Joe DMD never discretely generates assembly, which is why there is no switch. There is obj2asm by Walter, but it is part of the paid Digital Mars package (AFAIK). objconv[1] should work though, and it is free. Alternatively, if you don't mind GDC-generated assembly, you can do it online quite easily[2]. [1]: http://www.agner.org/optimize/ [2]: http://d.godbolt.org/
Re: Generating assembly from dmd
On Sunday, 22 December 2013 at 14:31:44 UTC, Kelet wrote: DMD never discretely generates assembly To clarify, DMD goes straight from its intermediate representation (IR) of the code to the binary opcodes, which is part of the reason why it compiles faster relative to GDC or LDC. Regards, Kelet
Re: Dub and GtkD
On Sun, 2013-12-22 at 12:58 +0100, Mike Wey wrote:
On 12/21/2013 11:19 PM, qznc wrote:
[…]
For some reason GtkD uses some unreleased version of Gtk with some
OpenGL features.
This is because the released version of GtkGLext doesn't support Gtk+ 3.x.
OK so that is why it isn't in Debian.
Does Fedora 20 or RPM Fusion have the pre-release as a package?
You can use the normal/stable variant by adapting
your dependency a little:
dependencies: { gtk-d:gtkd: ~master }
Just depending on the subpackage you need will stop dub from including
the other parts of GtkD in your app. So this should fix your problem.
OK, that can work for me.
Python now uses the reflection approach to providing a Python binding to
the API: PyGTK has given way to PyGobject. Has the PyGobject approach
been rejected for GtkD staying with the PyGtk approach?
I am currently rewriting a gtkmm application I had in GtkD and once a
few problems of connectSignals is solved I am going to be loving it,
thanks for keeping it going.
--
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: Build all at once or…
On Sun, 2013-12-22 at 13:14 +0100, Jacob Carlborg wrote: […] There is a big chance this will result in link errors. I don't remember the exact problems but it's something like DMD doesn't emit template symbols to all object files it should. You can search these newsgroups for incremental complication. It was quite easy to find: http://www.digitalmars.com/d/archives/digitalmars/D/Incremental_compilation_with_DMD_96138.html I tend to use ldc2 or gdc rather than dmd, I suspect there are a whole different set of issues? -- 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: GtkD - how to install
Am 22.12.2013 15:15, schrieb Amateur: Yeah, I installed dub and ran commands dub init main and dub fetch --local gtk-d. It worked properly, but how to continue? I tried compile simple app which contains only import gtk.MainWindow; and compiler yells that source for this cannot be found. What have I to do next? I have installed Gtk+ libraries, dmd, dub and I ran too commands dub init main and dub fetch --local gtk-d. You have to create a package.json file for you project and add gtk as a dependency. See this page for further details: http://code.dlang.org/package-format When you are done setting up the package.json call dub init and everything should be setup correctly.
Re: GtkD - how to install
On 12/22/2013 11:15 PM, Amateur wrote:
What have I to do next?
I have installed Gtk+ libraries, dmd, dub and I ran too commands dub
init main and dub fetch --local gtk-d.
You need to add gtkd as a dependency to your project's package.json:
{
dependencies: {
gtk-d: ~master
}
}
Also, when using dub to manage your project, you don't need to 'fetch'.
As long as a library is listed as a dependency, dub will fetch it
automatically.
Re: Vibe.d and testing
On Saturday, 21 December 2013 at 15:08:48 UTC, Russel Winder wrote: 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? By forking vibe.d repository. No out-of-the-box way to redefine default TCP handling routines from user code if you mean that.
Re: Generating assembly from dmd
On Sunday, 22 December 2013 at 14:31:44 UTC, Kelet wrote: There is obj2asm by Walter, but it is part of the paid Digital Mars package (AFAIK). Correction: obj2asm actually seems to come with DMD for Linux and Mac, but not Windows, where it seemingly needs to be purchased in the C and C++ Development System or Extended Utility Package[1] [1]: http://www.digitalmars.com/shop.html Regards, Kelet
Re: Build all at once or…
On Sunday, 22 December 2013 at 08:21:47 UTC, Russel Winder wrote: Is there some critical feature which means that compile all source at once is a better route? It is much faster if you have enough memory to afford it (imports are no re-parsed). Also there have been some nasty symbol emitting bugs in separate compilation mode but those should be fixed by now (though I won't swear it)
Re: Generating assembly from dmd
On 22/12/13 15:42, Kelet wrote: Correction: obj2asm actually seems to come with DMD for Linux and Mac, but not Windows, where it seemingly needs to be purchased in the C and C++ Development System or Extended Utility Package[1] Hmm, is there a separate download? I'm running latest git-HEAD self-compiled DMD, so I never download any of the packages.
Re: GtkD - how to install
On Sun, 2013-12-22 at 13:29 +, Amateur wrote: Hello, I'm beginning with programming on desktop. After choosing which language is da best for me, I chose D. And now I want to create GUI applications, so I tried installing GtkD and I failed. Can anybody give me a short manual? I cloned the Git repository for GtkD and then set up a bash script to give the GtkD make system all the right parameters so I could compile it for DMD, GDC and LDC2. However this is not trivial unless you are familiar with Make. However I also just tried using Dub and it works very nicely. I think the general opinion will these days be to use Dub. I'd like to code on linux (openSUSE 13.1), but if I'll get help on Windows, I'll be happy too. I only have Debian and Fedora Linux and OS X, I don't do Windows ;-) -- 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: Build all at once or…
On Sunday, 22 December 2013 at 14:39:23 UTC, Russel Winder wrote: I tend to use ldc2 or gdc rather than dmd, I suspect there are a whole different set of issues? Yes, at least gdc has own tweaks to symbol emitting schemes and some additionals flags to influence it. Incremental compilation (as contrary to simply separate compilation) because of template instance dependency tracking. It has improved a bit with recent change to symbol emitting but this change was incomplete and faulty on its own, still causing linker errors sometimes ;)
Re: Generating assembly from dmd
On Sun, Dec 22, 2013 at 03:17:42PM +0100, Joseph Rushton Wakeling wrote: Hi all, Can someone walk me through in a friendly way how to check the assembly produced by dmd? The application in this case is checking some new patches to Phobos. It's something I'm not familiar with doing in general and particularly not with dmd (which doesn't seem to have an assembly-output switch), so I'm hoping someone can advise :-) [...] This is what I do: dmd -oprogram mod1.d mod2.d ... objdump -D program | ddemangle program.asm vi program.asm # search for symbol, e.g., writeln. Assuming ddemangle has # succesfully demangled the symbol you're looking for (sometimes # it doesn't), you can just search for it as-is. T -- Today's society is one of specialization: as you grow, you learn more and more about less and less. Eventually, you know everything about nothing.
Re: Generating assembly from dmd
On Sun, Dec 22, 2013 at 07:04:54AM -0800, H. S. Teoh wrote: On Sun, Dec 22, 2013 at 03:17:42PM +0100, Joseph Rushton Wakeling wrote: Hi all, Can someone walk me through in a friendly way how to check the assembly produced by dmd? The application in this case is checking some new patches to Phobos. It's something I'm not familiar with doing in general and particularly not with dmd (which doesn't seem to have an assembly-output switch), so I'm hoping someone can advise :-) [...] This is what I do: dmd -oprogram mod1.d mod2.d ... Also, using the -g switch here may help, by including information that lets objdump figure out which identifiers are being referenced by hexadecimal addresses in the program (i.e., 'call std.stdio.writeln+0x123' as opposed to 'call 0x123456'). objdump -D program | ddemangle program.asm vi program.asm # search for symbol, e.g., writeln. Assuming ddemangle has # succesfully demangled the symbol you're looking for (sometimes # it doesn't), you can just search for it as-is. [...] T -- The fact that anyone still uses AOL shows that even the presence of options doesn't stop some people from picking the pessimal one. - Mike Ellis
Re: Generating assembly from dmd
On Sunday, 22 December 2013 at 14:17:50 UTC, Joseph Rushton Wakeling wrote: Hi all, Can someone walk me through in a friendly way how to check the assembly produced by dmd? The application in this case is checking some new patches to Phobos. It's something I'm not familiar with doing in general and particularly not with dmd (which doesn't seem to have an assembly-output switch), so I'm hoping someone can advise :-) Thanks best wishes, -- Joe dmd -c ./file.d objdump ./file.o -D -M intel or drop -M intel if you prefer att
Re: const char* or const(char)* when porting C headers?
On Sunday, 22 December 2013 at 04:06:05 UTC, Alexandr Druzhinin wrote: 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* Thanks, that makes sense. But how would i port this parameter: struct Tcl_Obj * CONST * objv Maybe like this?: const Tcl_Obj[]* objv
Re: const char* or const(char)* when porting C headers?
On Sunday, 22 December 2013 at 15:49:43 UTC, Gary Willoughby wrote: Thanks, that makes sense. But how would i port this parameter: and these: CONST84 char **tablePtr = ? CONST84 char ***argvPtr = ?
Re: Generating assembly from dmd
On 22/12/13 16:15, H. S. Teoh wrote: On Sun, Dec 22, 2013 at 07:04:54AM -0800, H. S. Teoh wrote: This is what I do: dmd -oprogram mod1.d mod2.d ... Also, using the -g switch here may help, by including information that lets objdump figure out which identifiers are being referenced by hexadecimal addresses in the program (i.e., 'call std.stdio.writeln+0x123' as opposed to 'call 0x123456'). objdump -D program | ddemangle program.asm vi program.asm # search for symbol, e.g., writeln. Assuming ddemangle has # succesfully demangled the symbol you're looking for (sometimes # it doesn't), you can just search for it as-is. [...] Thanks muchly :-)
Re: const char* or const(char)* when porting C headers?
Am 22.12.2013 17:02, schrieb Gary Willoughby: On Sunday, 22 December 2013 at 15:49:43 UTC, Gary Willoughby wrote: Thanks, that makes sense. But how would i port this parameter: and these: CONST84 char **tablePtr = ? CONST84 char ***argvPtr = ? In C/C++ the const always applies to whatever is left of it. If there is nothing left of it, it applies to what is right to it. So const char** is equivalent to char const **. That means the only part that is const is the char. In D const applies to whatever is inside the parantheses. So the equivalent in D would be const(char)** and const(char)*** If you have something like the following in C: const char * const the D equivalent would be const(char*) Note that the star is included in the parantheses here, because the pointer is const to, not only the data it points to. the D type: const(char**) would be equivalent to C: char const * const * const. (But you won't ever needs this) Kind Regards Benjamin Thaut
Re: const char* or const(char)* when porting C headers?
On Sunday, 22 December 2013 at 16:45:15 UTC, Benjamin Thaut wrote: Am 22.12.2013 17:02, schrieb Gary Willoughby: On Sunday, 22 December 2013 at 15:49:43 UTC, Gary Willoughby wrote: Thanks, that makes sense. But how would i port this parameter: and these: CONST84 char **tablePtr = ? CONST84 char ***argvPtr = ? In C/C++ the const always applies to whatever is left of it. If there is nothing left of it, it applies to what is right to it. So const char** is equivalent to char const **. That means the only part that is const is the char. In D const applies to whatever is inside the parantheses. So the equivalent in D would be const(char)** and const(char)*** If you have something like the following in C: const char * const the D equivalent would be const(char*) Note that the star is included in the parantheses here, because the pointer is const to, not only the data it points to. the D type: const(char**) would be equivalent to C: char const * const * const. (But you won't ever needs this) Kind Regards Benjamin Thaut Ah right, so: struct Tcl_Obj * CONST * objv would be: const(Tcl_Obj*)* objv or const(Tcl_Obj*)[] objv
Re: ubytes to ulong problem
On 12/22/2013 02:22 AM, Ali Çehreli wrote: On 12/22/2013 01:04 AM, Charles Hixson wrote: Nice, but the block is longer than 8 bytes, so I should use a for (i = n; i n + 8; i++) rather than a foreach, and index off of i. Makes sense. That reminded me of the Phobos function that does exactly what you want. Have you considered std.bitmanip.read? Ali No, thanks. That's precisely what I was looking for. -- Charles Hixson
How can I explicitly qualify things from module?
Hello everybody.
In C++ it is considered good practice to qualify names in
namespaces, as in:
std::vectorint v;
std::cout std::endl;
How can this be done in D, with its std module?
For example I tried the following and it doesn't work.
import std.stdio;
void main()
{
std.writeln(Hello world!);
}
Thank you for your time.
Re: Dub and GtkD
On 12/22/2013 03:36 PM, Russel Winder wrote:
On Sun, 2013-12-22 at 12:58 +0100, Mike Wey wrote:
On 12/21/2013 11:19 PM, qznc wrote:
[…]
For some reason GtkD uses some unreleased version of Gtk with some
OpenGL features.
This is because the released version of GtkGLext doesn't support Gtk+ 3.x.
OK so that is why it isn't in Debian.
Does Fedora 20 or RPM Fusion have the pre-release as a package?
Not as far as i know.
You can use the normal/stable variant by adapting
your dependency a little:
dependencies: { gtk-d:gtkd: ~master }
Just depending on the subpackage you need will stop dub from including
the other parts of GtkD in your app. So this should fix your problem.
OK, that can work for me.
Python now uses the reflection approach to providing a Python binding to
the API: PyGTK has given way to PyGobject. Has the PyGobject approach
been rejected for GtkD staying with the PyGtk approach?
I don't think that would be a good approach with D, you either need a
whole lot of compile time magic, or loose type safety and do everything
at runtime.
I am currently rewriting a gtkmm application I had in GtkD and once a
few problems of connectSignals is solved I am going to be loving it,
thanks for keeping it going.
--
Mike Wey
Re: GtkD - how to install
On 12/22/2013 03:41 PM, Mike Parker wrote:
On 12/22/2013 11:15 PM, Amateur wrote:
What have I to do next?
I have installed Gtk+ libraries, dmd, dub and I ran too commands dub
init main and dub fetch --local gtk-d.
You need to add gtkd as a dependency to your project's package.json:
{
dependencies: {
gtk-d: ~master
}
}
Also, when using dub to manage your project, you don't need to 'fetch'.
As long as a library is listed as a dependency, dub will fetch it
automatically.
I would recommend listing the subpackage as a dependency:
{
dependencies: {
gtk-d:gtkd: ~master
}
}
--
Mike Wey
Re: const char* or const(char)* when porting C headers?
On Sunday, 22 December 2013 at 18:28:43 UTC, Benjamin Thaut wrote: Am 22.12.2013 18:39, schrieb Gary Willoughby: Ah right, so: struct Tcl_Obj * CONST * objv would be: const(Tcl_Obj*)* objv or const(Tcl_Obj*)[] objv Yes Great thanks! I thought i had a pretty good handle on C but porting some headers makes me scratch my head.
Re: How can I explicitly qualify things from module?
On Sunday, 22 December 2013 at 19:23:50 UTC, Cpluspluser wrote:
Hello everybody.
In C++ it is considered good practice to qualify names in
namespaces, as in:
std::vectorint v;
std::cout std::endl;
How can this be done in D, with its std module?
For example I tried the following and it doesn't work.
import std.stdio;
void main()
{
std.writeln(Hello world!);
}
Thank you for your time.
std.stdio.writeln(Hello world!);
Re: How can I explicitly qualify things from module?
On Sunday, December 22, 2013 19:23:49 Cpluspluser wrote:
Hello everybody.
In C++ it is considered good practice to qualify names in
namespaces, as in:
std::vectorint v;
std::cout std::endl;
How can this be done in D, with its std module?
For example I tried the following and it doesn't work.
import std.stdio;
void main()
{
std.writeln(Hello world!);
}
Thank you for your time.
You have to give the full module path:
std.stdio.writeln
- Jonathan M Davis
Re: const char* or const(char)* when porting C headers?
Am 22.12.2013 20:34, schrieb Gary Willoughby:
On Sunday, 22 December 2013 at 18:28:43 UTC, Benjamin Thaut wrote:
Am 22.12.2013 18:39, schrieb Gary Willoughby:
Ah right, so:
struct Tcl_Obj * CONST * objv
would be:
const(Tcl_Obj*)* objv or const(Tcl_Obj*)[] objv
Yes
Great thanks! I thought i had a pretty good handle on C but porting some
headers makes me scratch my head.
Yes, its sometimes really astonishing in what ways C-features can be
abused. I very recently sumbled apon this:
void (*callbackFunc)(GtkWidget* widget, void* userData);
void registerCallback(callbackFunc func);
void userCallback(GtkEntry* entry)
{
...
}
void someFunc()
{
registerCallback((callbackFunc)userCallback);
}
Note that the signature of the funciton does not match at all. The first
parameter is casted automatically to a different data type, which only
works because pointers always have the same size and the second paramter
is omitted completely. This only works because of the C calling
convetion. C can be a strange land ;-)
Kind Regards
Benjamin Thaut
Re: How can I explicitly qualify things from module?
Cpluspluser: In C++ it is considered good practice to qualify names in namespaces, as in: std::vectorint v; std::cout std::endl; How can this be done in D, with its std module? Beside the answers already given you by others (of using std.stdio.writeln after a normal import), in D there are also static imports: static import std.stdio; And qualified imports: import std.stdio: writeln; All this should be more than enough for your needs. Bye, bearophile
Re: Dub and GtkD
On 12/22/13 20:21, Mike Wey wrote: On 12/22/2013 03:36 PM, Russel Winder wrote: Python now uses the reflection approach to providing a Python binding to the API: PyGTK has given way to PyGobject. Has the PyGobject approach been rejected for GtkD staying with the PyGtk approach? I don't think that would be a good approach with D, you either need a whole lot of compile time magic, or loose type safety and do everything at runtime. It's not that bad; no compile time magic and zero runtime overhead is possible: http://repo.or.cz/w/girtod.git/tree/gtk2:/gtk2 While I haven't updated those bindings in ~2 two years, they should still work; may just need some tweaks, to deal with recent d language changes and to support newer lib features. The biggest remaining issue is lack of integrated Cairo bindings. artur
Idiomatic way to share mutable data?
Friends,
I'm writing a little molecular simulator. Without boring you with
the details, here's the gist of it:
struct Atom{
double x, vx;
double interaction(Atom a2){
return (a2.x-this.x)^^2; //more complicated in reality
}
}
main(){
Atom[] atoms = (a bunch of atoms in random positions);
foreach(timestep; 1..1000){ //L0
foreach(atom; atoms){ //L1
foreach(partner; atoms){ //L2
atom.vx += atom.interaction(partner)/mass; //F=ma
}
}
foreach(atom; atoms){ //L3
atom.x += atom.vx * deltaT;
}
}
}
So here's the conundrum: How do I parallelize this efficiently?
The first loop, L0, is not parallelizable at all, and I think the
best speedup will be in parallelizing L1. But I immediately run
into trouble: all the threads need access to all of atoms, and
every atom's position is changed on every pass through L0. So to
do this purely with message passing would involve copying the
entirety of atoms to every thread every L0 pass. Clearly, shared
state is desirable.
But I don't need to be careful about the shared state at all; L1
only reads Atom.x, and only writes Atom.vx. L3 only reads Atom.vx
and only writes Atom.x There's no data dependency at all inside
L1 and L3.
Is there a way to inform the compiler of this without just
aggressively casting things to shared and immutable?
On that note, how do you pass a reference to a thread (via send)
without the compiler yelling at you? Do you cast(immutable
Atom[]) on send and cast(Atom[]) on receive?
Re: Idiomatic way to share mutable data?
On 22/12/13 22:07, Charles McAnany wrote: So here's the conundrum: How do I parallelize this efficiently? Does your simulation rely at all on pseudo-random number generation _inside_ the loop? That is, apart from for generation of the initial array of atoms? If it's purely deterministic, it ought to suffice to use std.parallelism. If not, then things can be more tricky. OTOH you might find it best to declare the array of atoms as shared. I don't have good personal experience here so don't know how to advise you. You might also find it beneficial -- since in each of the inner loops you're reading from one set of values and writing to another -- to split up your array of atoms into two arrays: double[] x and double[] vx -- and to find another way of doing the interaction calculation (e.g. do it as interaction(size_t i, size_t j) where i, j are array indexes). On that note, how do you pass a reference to a thread (via send) without the compiler yelling at you? Do you cast(immutable Atom[]) on send and cast(Atom[]) on receive? This can be one way of handling things -- of course, you have to be careful to treat the data with respect, e.g. to not modify it even though you have cast it away from immutable.
Re: Idiomatic way to share mutable data?
On Sunday, 22 December 2013 at 21:07:11 UTC, Charles McAnany
wrote:
Friends,
I'm writing a little molecular simulator. Without boring you
with the details, here's the gist of it:
struct Atom{
double x, vx;
double interaction(Atom a2){
return (a2.x-this.x)^^2; //more complicated in reality
}
}
main(){
Atom[] atoms = (a bunch of atoms in random positions);
foreach(timestep; 1..1000){ //L0
foreach(atom; atoms){ //L1
foreach(partner; atoms){ //L2
atom.vx += atom.interaction(partner)/mass;
//F=ma
}
}
foreach(atom; atoms){ //L3
atom.x += atom.vx * deltaT;
}
}
}
So here's the conundrum: How do I parallelize this efficiently?
The first loop, L0, is not parallelizable at all, and I think
the best speedup will be in parallelizing L1. But I immediately
run into trouble: all the threads need access to all of atoms,
and every atom's position is changed on every pass through L0.
So to do this purely with message passing would involve copying
the entirety of atoms to every thread every L0 pass. Clearly,
shared state is desirable.
But I don't need to be careful about the shared state at all;
L1 only reads Atom.x, and only writes Atom.vx. L3 only reads
Atom.vx and only writes Atom.x There's no data dependency at
all inside L1 and L3.
Is there a way to inform the compiler of this without just
aggressively casting things to shared and immutable?
On that note, how do you pass a reference to a thread (via
send) without the compiler yelling at you? Do you
cast(immutable Atom[]) on send and cast(Atom[]) on receive?
Partition the atoms up into n sets, have a thread per set. A
thread only writes to it's set. It can read from other sets. No
locks needed and no need to partition the time.
If there are many atoms on a large scale, you can try to group
them into sets based on distance. Then you can greatly optimize
the calculations by ignoring sets that are far away and
contribute little to the force(or use an point mass as an
approximation. This could reduce the calculations from n^2 to
something like n or nlogn.
Re: Idiomatic way to share mutable data?
On 22/12/13 22:42, Joseph Rushton Wakeling wrote: You might also find it beneficial -- since in each of the inner loops you're reading from one set of values and writing to another -- to split up your array of atoms into two arrays: double[] x and double[] vx -- and to find another way of doing the interaction calculation (e.g. do it as interaction(size_t i, size_t j) where i, j are array indexes). I should clarify what I mean there. By splitting up x and vx into two separate arrays, you get the benefit that in the inner loops, you can have a situation where you have one purely read-only array, and one which is write-only. Then, as Frustrated says, you can split up the write-only array into manageable chunks which can be dealt with by separate threads (using separate RNGs if that's necessary: note that the default random generator rndGen is thread-local, so calls to it in different threads should generate sufficiently independent pseudo-random values). But depending on what your total system size is, you might find that your CPU's ability to vectorize loop operations is actually more efficient than any split into different threads (this has certainly happened to me). But if you don't have any random number generation inside the inner loops, again, you'll probably find it better just to use std.parallelism.
Re: Idiomatic way to share mutable data?
On Sunday, 22 December 2013 at 21:07:11 UTC, Charles McAnany
wrote:
How do I parallelize this efficiently?
From what you describe, std.parallelism would probably be
appropriate for this. However, from your problem description,
you're going to have a _lot_ of trouble with false sharing. I
suggest a trick like this:
The atoms list probably needs to be pretty big. I'd assume this
is the case since you're modeling atoms and you're concerned
about using parallelism to speed it up. Split the atoms list into
several lists of approximately equal size. I'd suggest splitting
into about 8 * totalCPUs lists to start with and go from there.
That should be very efficient with slices.
So, something like this (pseudocode):
```
atom[] allAtoms = ...;
atom[][] atomsList;
assert(allAtoms.length (64 * totalCPUs),
Probably not worth parallelizing...);
atomsList.length = 8*totalCPUs;
size_t partitionSize = allAtoms / atomsList.length;
foreach(i, ref list; atomsList) {
list = allAtoms[i*partitionSize .. (i+1)*partitionSize];
}
long leftOvers = allAtoms % atomsList.length;
if(leftOvers) {
atomsList.length++;
atomsList[$-1] =
allAtoms[(atomsList.length - 2)*partitionSize .. $];
}
// Since the leftovers are the only partition that has an odd
// size, it might be appropriate to just save it for last after
// you parallelize everything else.
foreach(a, b; parallelPickPairs(atomsList)) {
foreach(ref atom; a) {
foreach(partner; b) {
atom.vx += atom.interaction(partner)/mass;
}
}
}
```
Obviously the bulk of the work left is implementing
parallelPickPairs which is just pseudocode for use
std.parallelism while picking all possible pairs of items in some
list. In this case, it's just picking pairs of atom arrays in
atomsList. The pair picking process should queue the work up in
such a way to prevent tasks from accessing the same list at the
same time (with 8*totalCPUs lists, there are tons of ways to do
that).
There's some room for improvement, but this kind of idea should
get you started down the right path, I think.
One kind of landmine with foreach loops, though, is forgetting to
use ref and trying to modify the thing. For instance, in your
OP, you're modifying a _copy_ of atom, so it wouldn't work
(although, in your original code that might not be how you did
it). Just a heads up for you.
pure vs std.range.retro
Thanks for all your help understanding the algorithm chaining problem...
Now I have another gotcha.
This code compiles and runs OK if I remove the keyword pure or if I
remove the .retro
As I understand it retro should affect the pureness of the the function.
If I put the keyword in, it fails to instantiate the template...
import std.algorithm;
import std.array;
import std.stdio;
import std.range;
pure auto huh( in uint[] digitArray, in uint value)
{
return find!( (a,b) = (a b))( digitArray.retro, value);
}
unittest {
auto test = [11u, 1u, 1u, 10u];
auto s = huh( test, 10u);
writeln( s);
}
dmd -unittest -main doesnt_work.d ./doesnt_work
/usr/include/dmd/phobos/std/algorithm.d(3508): Error: pure function
'doesnt_work.huh' cannot call impure function
'std.range.retro!(const(uint)[]).retro.Result.popFront'
/usr/include/dmd/phobos/std/algorithm.d(3510): Error: pure function
'doesnt_work.huh' cannot call impure function
'std.range.retro!(const(uint)[]).retro.Result.front'
doesnt_work.d(8): Error: template instance doesnt_work.huh.find!(__lambda3,
Result, const(uint)) error instantiating
--
John Carter
Phone : (64)(3) 358 6639
Tait Electronics
PO Box 1645 Christchurch
New Zealand
--
--
This email, including any attachments, is only for the intended recipient.
It is subject to copyright, is confidential and may be the subject of legal
or other privilege, none of which is waived or lost by reason of this
transmission.
If you are not an intended recipient, you may not use, disseminate,
distribute or reproduce such email, any attachments, or any part thereof.
If you have received a message in error, please notify the sender
immediately and erase all copies of the message and any attachments.
Unfortunately, we cannot warrant that the email has not been altered or
corrupted during transmission nor can we guarantee that any email or any
attachments are free from computer viruses or other conditions which may
damage or interfere with recipient data, hardware or software. The
recipient relies upon its own procedures and assumes all risk of use and of
opening any attachments.
--
Re: GtkD - how to install
El 22/12/13 14:29, Amateur ha escrit: Hello, I'm beginning with programming on desktop. After choosing which language is da best for me, I chose D. And now I want to create GUI applications, so I tried installing GtkD and I failed. Can anybody give me a short manual? I'd like to code on linux (openSUSE 13.1), but if I'll get help on Windows, I'll be happy too. Thank you There is http://d-apt.sourceforge.net/ for Debian Linux. -- Jordi Sayol
Re: pure vs std.range.retro
John Carter: Thanks for all your help understanding the algorithm chaining problem... Now I have another gotcha. This code compiles and runs OK if I remove the keyword pure or if I remove the .retro Some functions can't be pure. Some functions can be pure but in Phobos are not yet pure, often because they call other basic functions that are not yet pure. And probably some functions are not yet pure because of some compiler bug/limits. To know what is your case you have to take a look at the Phobos code. Bye, bearophile
Re: pure vs std.range.retro
On 12/22/2013 02:37 PM, John Carter wrote: This code compiles and runs OK if I remove the keyword pure or if I remove the .retro Third option: It compiles and runs OK if you upgrade your compiler. ;) Works with DMD64 D Compiler v2.065-devel-41ebb59. Ali
Re: pure vs std.range.retro
Yup. That's the answer. Upgraded to 2.064 and good things happened. Diff shows flocks of diffs in std.range Thanks. On Mon, Dec 23, 2013 at 1:21 PM, Ali Çehreli acehr...@yahoo.com wrote: On 12/22/2013 02:37 PM, John Carter wrote: This code compiles and runs OK if I remove the keyword pure or if I remove the .retro Third option: It compiles and runs OK if you upgrade your compiler. ;) Works with DMD64 D Compiler v2.065-devel-41ebb59. Ali -- John Carter Phone : (64)(3) 358 6639 Tait Electronics PO Box 1645 Christchurch New Zealand -- -- This email, including any attachments, is only for the intended recipient. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If you are not an intended recipient, you may not use, disseminate, distribute or reproduce such email, any attachments, or any part thereof. If you have received a message in error, please notify the sender immediately and erase all copies of the message and any attachments. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission nor can we guarantee that any email or any attachments are free from computer viruses or other conditions which may damage or interfere with recipient data, hardware or software. The recipient relies upon its own procedures and assumes all risk of use and of opening any attachments. --
Error: module std.c.stdio import 'FHND_WCHAR' not found
D:\workspace\...dmd -v
DMD32 D Compiler v2.064
Copyright (c) 1999-2013 by Digital Mars written by Walter Bright
...
D:\workspace\...type bug1.d
import std.stdio;
void main()
{
}
D:\workspace\...dmd bug1.d
D:\D\dmd2\windows\bin\..\..\src\phobos\std\stdio.d(35): Error: module
std.c.stdio import 'FHND_WCHAR' not found
D:\D\dmd2\windows\bin\..\..\src\phobos\std\stdio.d(35): Error: module
std.c.stdio import 'FHND_TEXT' not found
I just installed 2.064.2 from the 1-click Windows installer. Everything
seemed to install ok. Any ideas?
Dave
GDC GCC backend
This one's kinda short.. Is it possible to change the variable that gdc finds cc1d? Something like gdc -gcc=/whatever/gcc_backend?
Re: const char* or const(char)* when porting C headers?
22.12.2013 11:06, Alexandr Druzhinin пишет: 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* Yes, the last line should be const char * const == const char* thanks to Benjamin IIRC in D qualificator is applied to the right part of statement if there is no the parantheses and to part inside the parantheses if they exists. Important thing is that in D qualificators are transitive. It makes type system more robust (from POV immutability), but doesn't complete it, sadly.
