Re: D1 D2 alpha's for Win64
On 10/15/2012 3:44 AM, Walter Bright wrote: On 10/14/2012 6:08 PM, Andrej Mitrovic wrote: Ok so we're only supposed to compile with -c when using -m64? I don't suppose DMD could automatically invoke the VC linker? It does automatically invoke the VC linker. You'll need to set the VCINSTALLDIR environment variable. I set it with sc.ini as: - [Environment] LIB=c:\cbx\mars\phobos;c:\cbx\mars\druntime\lib;c:\dm\lib\;c:\curl\lib DDFLAGS=-Ic:\cbx\mars\phobos DFLAGS=-Ic:\cbx\mars\phobos;c:\cbx\mars\druntime\import #LINKCMD=c:\dm\bin\link.exe VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\ WindowsSdkDir=C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\ -- I guess there should be different environments for each architecture specified in sc.ini. Especially the LIB variable will never mix because the windows sdk libraries are called the same on both architectures. A problem with that is the DFLAGS variable: it is read before the command line, so you don't know whether -m32 or -m64 is passed (and it might even specify the switch itself), so you don't know which architecture to use. A solution might be to have additional environment blocks [Environment32] and [Environment64] that are evaluated after the command line processing.
Re: ddox documentation generator
Little styling update: The module tree is now collapsible and the default styling has been improved. Also the anchors in std.algorithm work now (although not optimal, but that's a problem of the docs and not the generator) http://vibed.org/temp/phobos/std/algorithm.html http://vibed.org/api/vibe.http.server/ Apart from the non-working links it starts to look quite statisfactory. (Pressing F5 is necessary again, because the CSS files changed.)
Alex Rønne Petersen joins phobos and druntime
Hello all, Please join me in congratulating Alex Rønne Petersen for joining the phobos and druntime committers on github. Alex has been a very active contributor to D, particularly druntime. We hope his prolific participation to continue and be enhanced by his new role. Good luck! Andrei
Re: Alex Rønne Petersen joins phobos and druntime
On Monday, 15 October 2012 at 18:33:28 UTC, Andrei Alexandrescu wrote: Hello all, Please join me in congratulating Alex Rønne Petersen for joining the phobos and druntime committers on github. Alex has been a very active contributor to D, particularly druntime. We hope his prolific participation to continue and be enhanced by his new role. Good luck! Andrei Congratulations! Seems like he's attending the same school as me :o
Re: Alex Rønne Petersen joins phobos and druntime
On 2012-10-15, 20:33, Andrei Alexandrescu wrote: Hello all, Please join me in congratulating Alex Rønne Petersen for joining the phobos and druntime committers on github. Alex has been a very active contributor to D, particularly druntime. We hope his prolific participation to continue and be enhanced by his new role. Good luck! You mean he hasn't been until now? I swear if someone threatened me to create that list, he'd be on it. Congratulations! -- Simen
Upcoming YOW conference in Australia
I'm giving a workshop on D at the conference. In promoting it, the organizer (Dave Thomas) asked me if I had any quotes about myself or D from customers that he could use. Any help on this would be appreciated. It'll also help promote your company.
Re: ddox documentation generator
Okay the more or less final incarnation now includes full text symbol detection with complete cross linking. I just had to modify some macros in std.ddoc and algorithm.d to avoid that they produce their own links and the result is this: http://vibed.org/temp/phobos/std/algorithm.html http://vibed.org/temp/phobos/std/datetime.html There are still some glitches for various reasons and no links are generated in code blocks right now. But all this linking requires absolutely no manual linking or use of macros anymore (except escaping identifiers that should not be linked with an underscore)
Re: D1 D2 alpha's for Win64
On Sunday, 14 October 2012 at 19:55:20 UTC, Walter Bright wrote: http://ftp.digitalmars.com/dmd1beta.zip http://ftp.digitalmars.com/dmd2beta.zip Be the first kid on your block to build a dmd Win64 app! On Win 2008 R2: 1. Path for VS 11: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\x86_amd64 Simple can be renamed to ..\amd64 2. mspdb110.dll not found: In cmd: C:\dmd2\windows\binpath=%path%;C:\Program Files (x86)\Microsoft Visual Studio 1 1.0\Common7\IDE 3. C:\dmd2\windows\bindmd -m64 t64.d Microsoft (R) Incremental Linker Version 11.00.50727.1 Copyright (C) Microsoft Corporation. All rights reserved. LINK : fatal error LNK1104: cannot open file 'phobos64.lib' --- errorlevel 1104 If phobos.lib renamed to phobos64.lib Microsoft (R) Incremental Linker Version 11.00.50727.1 Copyright (C) Microsoft Corporation. All rights reserved. .\..\lib\phobos64.lib : warning LNK4003: invalid library format; library ignored t64.obj : error LNK2001: unresolved external symbol main ...
Re: D1 D2 alpha's for Win64
But in 32 mode with same sc.ini works fine.
Re: D1 D2 alpha's for Win64
On 10/15/2012 1:27 PM, Michael wrote: LINK : fatal error LNK1104: cannot open file 'phobos64.lib' --- errorlevel 1104 Fixed.
Progress on DGE
I haven't posted a progress update on my game engine project, DGE, for a while. I've managed to find the source of a major bug that was holding back development, and I've been making sporadic improvements ever since. It's still very incomplete and a bit buggy, but at least it draws stuff now. :) One of the more interesting developments is an expansion of the collision detection system. Barring any serious flaws in my code, I think I'm about 3/4 of the way to having a working capsule-capsule sweep test, which, as far as I've seen, has been implemented only one or two times before. Of course, with my knowledge of physics, something's probably wrong, but I haven't noticed any major issues in recent trials (except, obviously, for cases that I haven't implemented). It still needs a good broadphase system, but I haven't figured out what I want to do on that front... Anyway, if anyone wants to take a look at the current state of the code, it's at http://sourceforge.net/p/d-game-engine. I'll probably move it to Github at some point, but I haven't gotten around to it. Also, if anyone has suggestions, enhancement requests, patches, etc., I'd be glad to hear them. I'm still not completely sure how to design the multi-pass rendering facilities, so suggestions in that area would be especially helpful.
Re: D1 D2 alpha's for Win64
On Monday, 15 October 2012 at 20:39:14 UTC, Walter Bright wrote:
On 10/15/2012 1:27 PM, Michael wrote:
LINK : fatal error LNK1104: cannot open file 'phobos64.lib'
--- errorlevel 1104
Fixed.
dmd -m64 t64.d
--
import std.stdio;
void main()
{
writeln(Win 64!);
}
--
.\..\lib\shell32.lib : warning LNK4003: invalid library format;
library ignored
.\..\lib\kernel32.lib : warning LNK4003: invalid library format;
library ignored
.\..\lib\shell32.lib : warning LNK4003: invalid library format;
library ignored
.\..\lib\kernel32.lib : warning LNK4003: invalid library format;
library ignored
LIBCMT.lib(a_map.obj) : error LNK2019: unresolved external symbol
__imp_WideCharToMultiByte referenced in function int __cdecl
__crtLCMapStringA_stat(struct localeinfo_struct *,wchar_t const
*,unsigned long,char const *,int,char *,int,int,int)
(?__crtLCMapStringA_stat@@YAHPEAUlocaleinfo_struct@@PEB_WKPEBDHPEADHHH@Z)
LIBCMT.lib(a_loc.obj) : error LNK2001: unresolved external symbol
__imp_WideCharToMultiByte
phobos64.lib(dmain2_4a7_1a5.obj) : error LNK2001: unresolved
external symbol __imp_WideCharToMultiByte
LIBCMT.lib(a_env.obj) : error LNK2001: unresolved external symbol
__imp_WideCharToMultiByte
LIBCMT.lib(wctomb.obj) : error LNK2001: unresolved external
symbol __imp_WideCharToMultiByte
LIBCMT.lib(write.obj) : error LNK2001: unresolved external symbol
__imp_WideCharToMultiByte
phobos64.lib(dmain2_4a7_1a5.obj) : error LNK2019: unresolved
external symbol IsDebuggerPresent referenced in function main
phobos64.lib(dmain2_4a7_1a5.obj) : error LNK2019: unresolved
external symbol LocalFree referenced in function main
phobos64.lib(dmain2_4a7_1a5.obj) : error LNK2019: unresolved
external symbol GetCommandLineW referenced in function main
phobos64.lib(dmain2_4a7_1a5.obj) : error LNK2019: unresolved
external symbol CommandLineToArgvW referenced in function main
phobos64.lib(thread_1b9_21c.obj) : error LNK2001: unresolved
external symbol __imp_InitializeCriticalSection
phobos64.lib(mutex_335_213.obj) : error LNK2001: unresolved
external symbol __imp_InitializeCriticalSection
phobos64.lib(monitor__519_6fd.obj) : error LNK2019: unresolved
external symbol __imp_InitializeCriticalSection referenced in
function _d_monitor_create
and ... ... ...
Re: D1 D2 alpha's for Win64
On 10/15/2012 2:21 PM, Michael wrote: On Monday, 15 October 2012 at 20:39:14
UTC, Walter Bright wrote:
On 10/15/2012 1:27 PM, Michael wrote:
LINK : fatal error LNK1104: cannot open file 'phobos64.lib'
--- errorlevel 1104
Fixed.
dmd -m64 t64.d
--
import std.stdio;
void main()
{
writeln(Win 64!);
}
--
You should be linking with the VC libraries, not the 32 bit dmc ones. Try
disabling the LIB path in sc.ini.
.\..\lib\shell32.lib : warning LNK4003: invalid library format; library
ignored
.\..\lib\kernel32.lib : warning LNK4003: invalid library format; library
ignored
.\..\lib\shell32.lib : warning LNK4003: invalid library format; library
ignored
.\..\lib\kernel32.lib : warning LNK4003: invalid library format; library
ignored
LIBCMT.lib(a_map.obj) : error LNK2019: unresolved external symbol
__imp_WideCharToMultiByte referenced in function int __cdecl
__crtLCMapStringA_stat(struct localeinfo_struct *,wchar_t const *,unsigned
long,char const *,int,char *,int,int,int)
(?__crtLCMapStringA_stat@@YAHPEAUlocaleinfo_struct@@PEB_WKPEBDHPEADHHH@Z)
LIBCMT.lib(a_loc.obj) : error LNK2001: unresolved external symbol
__imp_WideCharToMultiByte
phobos64.lib(dmain2_4a7_1a5.obj) : error LNK2001: unresolved external symbol
__imp_WideCharToMultiByte
LIBCMT.lib(a_env.obj) : error LNK2001: unresolved external symbol
__imp_WideCharToMultiByte
LIBCMT.lib(wctomb.obj) : error LNK2001: unresolved external symbol
__imp_WideCharToMultiByte
LIBCMT.lib(write.obj) : error LNK2001: unresolved external symbol
__imp_WideCharToMultiByte
phobos64.lib(dmain2_4a7_1a5.obj) : error LNK2019: unresolved external symbol
IsDebuggerPresent referenced in function main
phobos64.lib(dmain2_4a7_1a5.obj) : error LNK2019: unresolved external symbol
LocalFree referenced in function main
phobos64.lib(dmain2_4a7_1a5.obj) : error LNK2019: unresolved external symbol
GetCommandLineW referenced in function main
phobos64.lib(dmain2_4a7_1a5.obj) : error LNK2019: unresolved external symbol
CommandLineToArgvW referenced in function main
phobos64.lib(thread_1b9_21c.obj) : error LNK2001: unresolved external symbol
__imp_InitializeCriticalSection
phobos64.lib(mutex_335_213.obj) : error LNK2001: unresolved external symbol
__imp_InitializeCriticalSection
phobos64.lib(monitor__519_6fd.obj) : error LNK2019: unresolved external symbol
__imp_InitializeCriticalSection referenced in function _d_monitor_create
and ... ... ...
Re: D seems interesting, but...
On Monday, 15 October 2012 at 05:27:14 UTC, H. S. Teoh wrote: On Mon, Oct 15, 2012 at 07:14:42AM +0200, Gerry Weaver wrote: [...] Hi, I checked it out. There is only a dmd.conf. I've included it below. [...] Strange, I have exactly the same copy of dmd.conf, and I didn't see a problem. I copy-n-pasted your code into the same filename, etc.. What version of libc6 do you have? (dpkg -p libc6) Maybe dmd is incompatible with older versions of libc6? T Hi, I was wondering why D doesn't just install everthing in one directory (ie; /opt/dlang) and look at an environment variable (ie; DLANG_ROOT) to source everything. It seems like it would make things a lot simpler. Then the package could be located anywhere and multiple versions could be used safely. Quite a few other languages have used this approach successfully. Anyway, just a thought. Thanks, -G
Re: D seems interesting, but...
On Monday, 15 October 2012 at 05:27:14 UTC, H. S. Teoh wrote: On Mon, Oct 15, 2012 at 07:14:42AM +0200, Gerry Weaver wrote: [...] Hi, I checked it out. There is only a dmd.conf. I've included it below. [...] Strange, I have exactly the same copy of dmd.conf, and I didn't see a problem. I copy-n-pasted your code into the same filename, etc.. What version of libc6 do you have? (dpkg -p libc6) Maybe dmd is incompatible with older versions of libc6? T Hi, I was wondering why D doesn't just install everthing in one directory (ie; /opt/dlang) and look at an environment variable (ie; DLANG_ROOT) to source everything. It seems like it would make things a lot simpler. Then the package could be located anywhere and multiple versions could be used safely. Quite a few other languages have used this approach successfully. Anyway, just a thought. Thanks, -G
Re: D seems interesting, but...
On 10/14/2012 11:09 PM, Gerry Weaver wrote: I was wondering why D doesn't just install everthing in one directory (ie; /opt/dlang) The .zip version works that way. (At least it used to.) Just unzip in any directory: http://dlang.org/download.html and look at an environment variable (ie; DLANG_ROOT) to source everything. You don't even need to do that. The binary detects where it is started from and finds the modules and libraries relative to its path. Ali -- D Programming Language Tutorial: http://ddili.org/ders/d.en/index.html
Re: D seems interesting, but...
On Mon, Oct 15, 2012 at 08:09:54AM +0200, Gerry Weaver wrote:
On Monday, 15 October 2012 at 05:27:14 UTC, H. S. Teoh wrote:
On Mon, Oct 15, 2012 at 07:14:42AM +0200, Gerry Weaver wrote:
[...]
Hi,
I checked it out. There is only a dmd.conf. I've included it below.
[...]
Strange, I have exactly the same copy of dmd.conf, and I didn't see a
problem. I copy-n-pasted your code into the same filename, etc..
What version of libc6 do you have? (dpkg -p libc6) Maybe dmd is
incompatible with older versions of libc6?
[...]
Hmm, apparently you have a *newer* version of libc6 than I do.
Apparently Debian doesn't have 2.15 yet, so I don't have an easy way to
test this further.
Hi,
I was wondering why D doesn't just install everthing in one directory
(ie; /opt/dlang) and look at an environment variable (ie; DLANG_ROOT)
to source everything. It seems like it would make things a lot
simpler. Then the package could be located anywhere and multiple
versions could be used safely. Quite a few other languages have used
this approach successfully. Anyway, just a thought.
[...]
I believe the .deb package is simply following Debian/Ubuntu conventions
by putting things in /usr/bin, /usr/lib, /usr/include, etc.. IIRC, /opt
is intended for manually-installed software (at least, that's what the
docs say).
One improvement that *could* be made, though, is to put things in
/usr/include/d/${version}/*, so that specific versions of dmd can find
the right versions of stuff. This was discussed recently, but I don't
remember if a decision was reached.
In any case, I haven't been able to reproduce the problem you're seeing.
I tried installing the package multiple times, upgrading the system
libraries, etc., and everything still works for me, so I'm not sure what
else to say. Seems like there must be some specific combination of
libraries, system or otherwise, that makes dmd not work. Without being
able to examine your environment, it's really hard to tell.
T
--
Without geometry, life would be pointless. -- VS
Re: Making TypeInfo.next() return a const(TypeInfo) was a bad idea
On 10/14/2012 12:19 PM, Benjamin Thaut wrote:
Because you are now no longer able to do stuff like this:
void log(...)
{
auto t = _arguments[0];
while(some condition)
{
t = t.next();
}
}
To be actually able to use TypeInfo.next you will now need the ConstRef
(hack) from phobos. Afaik there is no such thing in druntime which makes
working with TypeInfo.next within druntime a real pita.
That's the general problem of non-rebindable const references which is a
real pita. There has been a pull request to implement it
(https://github.com/D-Programming-Language/dmd/pull/3) but unfortunately
it never made it into the compiler.
Any suggestions?
You could create a recursive function hoping for
tail-recursion-optimization and inlining:
void log(...)
{
static const(TypeInfo) drillInto(const(TypeInfo) t)
{
if(some condition)
return drillInto(t.next());
return t;
}
auto t = drillInto(_arguments[0]);
}
Re: D seems interesting, but...
On Sun, Oct 14, 2012 at 11:32:30PM -0700, H. S. Teoh wrote:
[...]
In any case, I haven't been able to reproduce the problem you're seeing.
I tried installing the package multiple times, upgrading the system
libraries, etc., and everything still works for me, so I'm not sure what
else to say. Seems like there must be some specific combination of
libraries, system or otherwise, that makes dmd not work. Without being
able to examine your environment, it's really hard to tell.
[...]
Funny, as soon as I said that, I manage to reproduce the same error
messages (though I can't say if it's exactly the problem you're seeing)
by compiling a file that doesn't define main(). In this case, I had a
hello.d with main() renamed to Main():
import std.stdio;
void Main() {
writeln(haha);
}
Running `dmd hello.d` produced a whole bunch of errors almost exactly
the same as what you're seeing. Of course, I'm not sure this is exactly
the problem you have, as your code does have a correctly-spelled main()
(from what I can tell). But this may help find where the problem is.
On that note, here's an enhancement request for dmd: if a program is
missing main() for whatever reason, we really should have a more
user-friendly error message than the reams of encrypted Klingon from the
linker that almost nobody understands.
T
--
Only boring people get bored. -- JM
Re: D seems interesting, but...
On Monday, 15 October 2012 at 06:20:52 UTC, Ali Çehreli wrote: On 10/14/2012 11:09 PM, Gerry Weaver wrote: I was wondering why D doesn't just install everthing in one directory (ie; /opt/dlang) The .zip version works that way. (At least it used to.) Just unzip in any directory: http://dlang.org/download.html and look at an environment variable (ie; DLANG_ROOT) to source everything. You don't even need to do that. The binary detects where it is started from and finds the modules and libraries relative to its path. Ali Hi, I removed the dmd package and downloaded the .zip. I checked for any files that were left behind when the package was removed and they are gone. I then ran dmd from the zip package, but I get the same result. It would seem that dmd does not work on this particular distribution. Thanks, -G Thanks, -G
Re: Making TypeInfo.next() return a const(TypeInfo) was a bad idea
On Monday, October 15, 2012 02:20:23 Alex Rønne Petersen wrote: But this is a problem we *must* solve. It is something I also ran into often while hacking on druntime. If we really need Rebindable in druntime, then we can simply move it to an appropriate place in druntime and alias std.typecons.Rebindable to it. core.time exists specifically because druntime needed some of the datetime stuff (most particularly the duration stuff). Otherwise, everything in it would be in std.datetime (where it was when originally proposed). We can do the same with other constructs if we really need to. We just don't want to be moving them to druntime if we don't actually need to. - Jonathan M Davis
Re: D seems interesting, but...
On 15-10-2012 08:40, H. S. Teoh wrote:
On Sun, Oct 14, 2012 at 11:32:30PM -0700, H. S. Teoh wrote:
[...]
In any case, I haven't been able to reproduce the problem you're seeing.
I tried installing the package multiple times, upgrading the system
libraries, etc., and everything still works for me, so I'm not sure what
else to say. Seems like there must be some specific combination of
libraries, system or otherwise, that makes dmd not work. Without being
able to examine your environment, it's really hard to tell.
[...]
Funny, as soon as I said that, I manage to reproduce the same error
messages (though I can't say if it's exactly the problem you're seeing)
by compiling a file that doesn't define main(). In this case, I had a
hello.d with main() renamed to Main():
import std.stdio;
void Main() {
writeln(haha);
}
Running `dmd hello.d` produced a whole bunch of errors almost exactly
the same as what you're seeing. Of course, I'm not sure this is exactly
the problem you have, as your code does have a correctly-spelled main()
(from what I can tell). But this may help find where the problem is.
Yep, those errors are always a sign that a proper main function is
missing. I have no idea why you would get it otherwise, though.
On that note, here's an enhancement request for dmd: if a program is
missing main() for whatever reason, we really should have a more
user-friendly error message than the reams of encrypted Klingon from the
linker that almost nobody understands.
https://github.com/D-Programming-Language/dmd/pull/1178
T
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
Re: D seems interesting, but...
On Sunday, October 14, 2012 23:40:41 H. S. Teoh wrote: Funny, as soon as I said that, I manage to reproduce the same error messages (though I can't say if it's exactly the problem you're seeing) by compiling a file that doesn't define main(). In this case, I had a hello.d with main() renamed to Main(): Yes. The error message that he's getting is essentially the one that you get when you don't define main, which is weird, because he _is_ defining main. But I don't know if it's exactly the same or not. A detailed comparison of the error messages that he's seeing and those that you get from not defining main on a machine that works would be required to see whether it's exactly the same message or not. I'm surprised that you didn't recognize the errors immediately. I guess that you haven't missed main very often (I'm used to it primarily from forgetting main when throwing together quick test scripts). But I'm totally stumped as to why he'd be getting them, since he does appear to be declaring main correctly. - Jonathan M Davis
Re: Making TypeInfo.next() return a const(TypeInfo) was a bad idea
On Monday, October 15, 2012 08:44:51 Mehrdad wrote: http://stackoverflow.com/questions/12506338 Yes. The problem is that he's trying to do something in druntime, and Rebindable is declared in Phobos. - Jonathan M Davis
Re: D seems interesting, but...
On Monday, 15 October 2012 at 06:47:06 UTC, Jonathan M Davis wrote: On Sunday, October 14, 2012 23:40:41 H. S. Teoh wrote: Funny, as soon as I said that, I manage to reproduce the same error messages (though I can't say if it's exactly the problem you're seeing) by compiling a file that doesn't define main(). In this case, I had a hello.d with main() renamed to Main(): Yes. The error message that he's getting is essentially the one that you get when you don't define main, which is weird, because he _is_ defining main. But I don't know if it's exactly the same or not. A detailed comparison of the error messages that he's seeing and those that you get from not defining main on a machine that works would be required to see whether it's exactly the same message or not. I'm surprised that you didn't recognize the errors immediately. I guess that you haven't missed main very often (I'm used to it primarily from forgetting main when throwing together quick test scripts). But I'm totally stumped as to why he'd be getting them, since he does appear to be declaring main correctly. - Jonathan M Davis Hi, I decided to install the same distribution in a vm. This time instead of installing the .deb package, I went with the zip. Everything seems to be working! I can compile a non-trivial example just fine. I guess I'll definitely be using the zip from now on. Anyway, I also tried the zip version on Mac and Windoze. They both built the same code successfully. This is great! I can finally try out all of those great language features I've been reading about. Thanks to everyone for pushing me down the rabbit hole far enough this time to get some payback ;-) It's on now! Thanks, -G
Re: D seems interesting, but...
On 15 October 2012 04:10, Gerry Weaver ger...@compvia.com wrote:
Hello All,
I have been looking at D off and on for several years. Initially I worked
through a very painful experience to get D compiling on Linux. After that
experience, I concluded that I should wait for it to become more mature.
Since then, I do a very simple test. I install the latest package and try to
build Hello World. I figure that if Hello World builds successfully, I
will continue further. I have just downloaded the latest .deb package and
installed it on Ubuntu 12.04 32bit. Once again it fails this incredibly
simple test. I've read many discussions about how/why, has/hasn't,
will/won't D hit the mainstream in programming languages. I think this
situation may offer at least one data point. I'm struggling to think of any
other language (and I use several) that won't build code out of the box. D
seems to have a lot of potential, but this needs to be fixed. I am not
asking for help on this. I honestly don't care what the solution is. I just
wanted the D developers to know why at least one developer is not using the
language. I sincerely hope that the situation will improve. I'm looking
forward to programming in D.
Thanks for your time,
-G
Here is the code:
import std.stdio;
void main()
{
writeln(Hello, world!);
}
Here is the command:
dmd hello.d
Here is the output:
/usr/lib/i386-linux-gnu/libphobos2.a(dmain2_459_1a5.o): In function
`_D2rt6dmain24mainUiPPaZi7runMainMFZv':
src/rt/dmain2.d:(.text._D2rt6dmain24mainUiPPaZi7runMainMFZv+0x10): undefined
reference to `_Dmain'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_18f_1b8.o): In function
`_D4core6thread6Thread6__ctorMFZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x24):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_19f_6e4.o): In function
`thread_attachThis':
src/core/thread.d:(.text.thread_attachThis+0xb7): undefined reference to
`_tlsstart'
src/core/thread.d:(.text.thread_attachThis+0xbc): undefined reference to
`_tlsend'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17d_1b8.o): In function
`_D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x27):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17e_1b8.o): In function
`_D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x27):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(deh2_43b_525.o): In function
`_D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable':
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x4):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0xc):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x13):
undefined reference to `_deh_end'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x36):
undefined reference to `_deh_end'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17a_713.o): In function
`thread_entryPoint':
src/core/thread.d:(.text.thread_entryPoint+0x64): undefined reference to
`_tlsend'
src/core/thread.d:(.text.thread_entryPoint+0x6a): undefined reference to
`_tlsstart'
collect2: ld returned 1 exit status
--- errorlevel 1
Try and paste the output of the following:
dmd -c hello.d
objdump -d hello.o
Regards
--
Iain Buclaw
*(p e ? p++ : p) = (c 0x0f) + '0';
Re: D seems interesting, but...
On Monday, 15 October 2012 at 07:12:03 UTC, Iain Buclaw wrote:
On 15 October 2012 04:10, Gerry Weaver ger...@compvia.com
wrote:
Hello All,
I have been looking at D off and on for several years.
Initially I worked
through a very painful experience to get D compiling on Linux.
After that
experience, I concluded that I should wait for it to become
more mature.
Since then, I do a very simple test. I install the latest
package and try to
build Hello World. I figure that if Hello World builds
successfully, I
will continue further. I have just downloaded the latest .deb
package and
installed it on Ubuntu 12.04 32bit. Once again it fails this
incredibly
simple test. I've read many discussions about how/why,
has/hasn't,
will/won't D hit the mainstream in programming languages. I
think this
situation may offer at least one data point. I'm struggling to
think of any
other language (and I use several) that won't build code out
of the box. D
seems to have a lot of potential, but this needs to be fixed.
I am not
asking for help on this. I honestly don't care what the
solution is. I just
wanted the D developers to know why at least one developer is
not using the
language. I sincerely hope that the situation will improve.
I'm looking
forward to programming in D.
Thanks for your time,
-G
Here is the code:
import std.stdio;
void main()
{
writeln(Hello, world!);
}
Here is the command:
dmd hello.d
Here is the output:
/usr/lib/i386-linux-gnu/libphobos2.a(dmain2_459_1a5.o): In
function
`_D2rt6dmain24mainUiPPaZi7runMainMFZv':
src/rt/dmain2.d:(.text._D2rt6dmain24mainUiPPaZi7runMainMFZv+0x10):
undefined
reference to `_Dmain'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_18f_1b8.o): In
function
`_D4core6thread6Thread6__ctorMFZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x24):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_19f_6e4.o): In
function
`thread_attachThis':
src/core/thread.d:(.text.thread_attachThis+0xb7): undefined
reference to
`_tlsstart'
src/core/thread.d:(.text.thread_attachThis+0xbc): undefined
reference to
`_tlsend'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17d_1b8.o): In
function
`_D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x27):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17e_1b8.o): In
function
`_D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x27):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(deh2_43b_525.o): In
function
`_D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable':
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x4):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0xc):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x13):
undefined reference to `_deh_end'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x36):
undefined reference to `_deh_end'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17a_713.o): In
function
`thread_entryPoint':
src/core/thread.d:(.text.thread_entryPoint+0x64): undefined
reference to
`_tlsend'
src/core/thread.d:(.text.thread_entryPoint+0x6a): undefined
reference to
`_tlsstart'
collect2: ld returned 1 exit status
--- errorlevel 1
Try and paste the output of the following:
dmd -c hello.d
objdump -d hello.o
Regards
Hi,
Here you go.
hello.o: file format elf32-i386
Disassembly of section .text:
.text:
0: b8 10 00 00 00 mov$0x10,%eax
5: b9 00 00 00 00 mov$0x0,%ecx
a: 8b 11 mov(%ecx),%edx
c: 89 10 mov%edx,(%eax)
e: 89 01 mov%eax,(%ecx)
10: c3 ret
Thanks,
-G
Re: D seems interesting, but...
On Monday, 15 October 2012 at 07:12:03 UTC, Iain Buclaw wrote:
On 15 October 2012 04:10, Gerry Weaver ger...@compvia.com
wrote:
Hello All,
I have been looking at D off and on for several years.
Initially I worked
through a very painful experience to get D compiling on Linux.
After that
experience, I concluded that I should wait for it to become
more mature.
Since then, I do a very simple test. I install the latest
package and try to
build Hello World. I figure that if Hello World builds
successfully, I
will continue further. I have just downloaded the latest .deb
package and
installed it on Ubuntu 12.04 32bit. Once again it fails this
incredibly
simple test. I've read many discussions about how/why,
has/hasn't,
will/won't D hit the mainstream in programming languages. I
think this
situation may offer at least one data point. I'm struggling to
think of any
other language (and I use several) that won't build code out
of the box. D
seems to have a lot of potential, but this needs to be fixed.
I am not
asking for help on this. I honestly don't care what the
solution is. I just
wanted the D developers to know why at least one developer is
not using the
language. I sincerely hope that the situation will improve.
I'm looking
forward to programming in D.
Thanks for your time,
-G
Here is the code:
import std.stdio;
void main()
{
writeln(Hello, world!);
}
Here is the command:
dmd hello.d
Here is the output:
/usr/lib/i386-linux-gnu/libphobos2.a(dmain2_459_1a5.o): In
function
`_D2rt6dmain24mainUiPPaZi7runMainMFZv':
src/rt/dmain2.d:(.text._D2rt6dmain24mainUiPPaZi7runMainMFZv+0x10):
undefined
reference to `_Dmain'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_18f_1b8.o): In
function
`_D4core6thread6Thread6__ctorMFZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x24):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_19f_6e4.o): In
function
`thread_attachThis':
src/core/thread.d:(.text.thread_attachThis+0xb7): undefined
reference to
`_tlsstart'
src/core/thread.d:(.text.thread_attachThis+0xbc): undefined
reference to
`_tlsend'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17d_1b8.o): In
function
`_D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x27):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17e_1b8.o): In
function
`_D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x27):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(deh2_43b_525.o): In
function
`_D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable':
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x4):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0xc):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x13):
undefined reference to `_deh_end'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x36):
undefined reference to `_deh_end'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17a_713.o): In
function
`thread_entryPoint':
src/core/thread.d:(.text.thread_entryPoint+0x64): undefined
reference to
`_tlsend'
src/core/thread.d:(.text.thread_entryPoint+0x6a): undefined
reference to
`_tlsstart'
collect2: ld returned 1 exit status
--- errorlevel 1
Try and paste the output of the following:
dmd -c hello.d
objdump -d hello.o
Regards
Hi,
Here you go.
hello.o: file format elf32-i386
Disassembly of section .text:
.text:
0: b8 10 00 00 00 mov$0x10,%eax
5: b9 00 00 00 00 mov$0x0,%ecx
a: 8b 11 mov(%ecx),%edx
c: 89 10 mov%edx,(%eax)
e: 89 01 mov%eax,(%ecx)
10: c3 ret
Thanks,
-G
Re: D seems interesting, but...
On Mon, 15 Oct 2012 08:36:22 +0200, Gerry Weaver ger...@compvia.com wrote: Hi, I removed the dmd package and downloaded the .zip. I checked for any files that were left behind when the package was removed and they are gone. I then ran dmd from the zip package, but I get the same result. It would seem that dmd does not work on this particular distribution. Maybe you still have an old dmd.conf at $HOME or somewhere else? It could be that it overrides the dmd.conf in the zip/deb file. What do you get when you run $ locate dmd.conf?
Re: Tips for debugging EXC_BAD_ACCESS
On 2012-10-14 22:58, Michel Fortin wrote: By the way, that line is half-fishy: super_struct.super_class = cast(objc.Class) OS.objc_msgSend(id, OS.sel_superclass); It'll work as long as you have only one level of derived classes, and only as long as you don't have a class that overrides the superclass method (which would be weird, I acknowledge). You should be aware of this if you're creating new object classes, especially the first part (the second part is only relevant if you wish to implement some kind of proxy objects). Theoretically, I think it'd be better to use directly functions from the Objective-C runtime[1], which also avoids the dynamic dispatch overhead of objc_msgSend: super_struct.super_class = class_getSuperclass(object_getClass(id)); Thanks for the pointer. As a first step I'm only porting the Java code to D and this is how the Java code looks like. I'm trying to stay as close as possible to the Java code, making it easier to port future versions of SWT. But I also want the code to be correct. -- /Jacob Carlborg
Re: D seems interesting, but...
On 2012-10-15 08:40, H. S. Teoh wrote: On that note, here's an enhancement request for dmd: if a program is missing main() for whatever reason, we really should have a more user-friendly error message than the reams of encrypted Klingon from the linker that almost nobody understands. How should DMD detect if you're building a (dynamic) library? Sure it can see that you're not using -lib or -shared but what about separate complication? -- /Jacob Carlborg
Re: Feature request: enum init shouldn't create a new enumeration
On Sunday, 14 October 2012 at 19:40:17 UTC, Nick Sabalausky wrote:
Yes, but it still has to be taken into account in things like
final switch. You can't just pretend that nothing will ever
have that value, because by making it the init value, you've
*made* it an actual possible value, one that just happens to
indicate uninitialized.
*I* know that named enum variables can have whatever values; it's
rather *you* and DMD who are pretending that enum variables can
have only those values which are specifically enumerated.
You say that final switch should take into account an enum init
value which can be used to represent an invalid value. I say that
final switch shouldn't consider that (invalid) init value any
different from all the other values that are invalid for that
specific enum type, that is: all the values that are not
speficied explicitly by the enumerations. And the way final
switch should take all those invalid values into account, is by
throwing an error when a final switch switches on a value not
specifically defined by the enumerations.
Dmd also seems blinded into thinking that the specified
enumerations are all that an enum variable can ever be, while in
reality, it's very easy to write a bug that makes an enum
variable have an invalid value. E.g:
enum MyEnum { first, second, third }
auto me = MyEnum.min;
while (me MyEnum.max)
{
// do something
++me;
}
switch (me) // this should throw
{
case MyEnum.first: break;
case MyEnum.second: break;
case MyEnum.thrird: break;
}
Re: Feature request: enum init shouldn't create a new enumeration
On Monday, 15 October 2012 at 08:25:18 UTC, Tommi wrote:
in reality, it's very easy to write a bug that makes an enum
variable have an invalid value. E.g:
Writing that bug wasn't as easy as I thought though. Here's the
code with a bug:
enum MyEnum { first, second, third }
auto me = MyEnum.min;
while (me = MyEnum.max)
{
// do something
++me;
}
final switch (me) // this should throw
{
case MyEnum.first: break;
case MyEnum.second: break;
case MyEnum.third: break;
}
Instead, currently this code runs just fine, none of the switch
cases are taken. So, this bug might manifest itself very far from
where it actually should have been throwing: on that final switch
expression. Thus hunting this bug down could be tedious.
Re: D seems interesting, but...
On 2012-10-15 05:10, Gerry Weaver wrote: Hello All, I have been looking at D off and on for several years. Initially I worked through a very painful experience to get D compiling on Linux. After that experience, I concluded that I should wait for it to become more mature. Since then, I do a very simple test. I install the latest package and try to build Hello World. I figure that if Hello World builds successfully, I will continue further. I have just downloaded the latest .deb package and installed it on Ubuntu 12.04 32bit. Once again it fails this incredibly simple test. I've read many discussions about how/why, has/hasn't, will/won't D hit the mainstream in programming languages. I think this situation may offer at least one data point. I'm struggling to think of any other language (and I use several) that won't build code out of the box. D seems to have a lot of potential, but this needs to be fixed. I am not asking for help on this. I honestly don't care what the solution is. I just wanted the D developers to know why at least one developer is not using the language. I sincerely hope that the situation will improve. I'm looking forward to programming in D. Just use DVM, it's also cross-platform: https://bitbucket.org/doob/dvm -- /Jacob Carlborg
Re: D seems interesting, but...
On 15/10/12 06:42, Jonathan M Davis wrote: On Sunday, October 14, 2012 21:39:42 H. S. Teoh wrote: This looks like what happens if you try to use the latest dmd release with an old version of Phobos, perhaps installed along with gdc. Whoever's doing the .deb packaging really should add a versioned Depends: field to debian/control so that it will require installation of the correct version of Phobos, or, at the very least, refuse to install if such is not available. At this point, it's a bad idea to use any version of druntime or Phobos which doesn't match exactly with the version of dmd that you're using. It's not as bad as it used to be, but there are still plenty of cases where a language change (be it a bug fix or added feature or whatever) makes it so that older versions of Phobos won't compile, or the latest Phobos ends up needing the latest dmd. I wouldn't advise anyone to use versions of them that don't all match. - Jonathan M Davis I think we should have a version number in druntime which is checked by the compiler, and bumped every time an incompatible change is made. That way we could reduce the number of messages from frustrated and bewildered users.
Re: D seems interesting, but...
On Monday, 15 October 2012 at 05:27:14 UTC, H. S. Teoh wrote: On Mon, Oct 15, 2012 at 07:14:42AM +0200, Gerry Weaver wrote: [...] Hi, I checked it out. There is only a dmd.conf. I've included it below. [...] Strange, I have exactly the same copy of dmd.conf, and I didn't see a problem. I copy-n-pasted your code into the same filename, etc.. What version of libc6 do you have? (dpkg -p libc6) Maybe dmd is incompatible with older versions of libc6? T I tried to install DMD 2.060 in 32 bit Ubuntu 12.04 (live cd in virtual box). I had to do apt-get install -f after installing the deb to get the dependencies, but after that, it worked. So I don't think this is due to libc6 version.
Re: D seems interesting, but...
On 15/10/12 11:14, Jacob Carlborg wrote: Just use DVM, it's also cross-platform: https://bitbucket.org/doob/dvm I tried that on both Windows and Ubuntu, and couldn't get it to work on either of them. I posted a couple of bug reports eight months ago, and they still haven't been fixed. Not recommended for anyone who is having problems with their installation.
Re: D seems interesting, but...
Jacob Carlborg: How should DMD detect if you're building a (dynamic) library? Sure it can see that you're not using -lib or -shared but what about separate complication? What about the need to use a compiler switch if you are performing a separate compilation? A related enhancement request that I'm asking for since years is: the compiler could define a compile-time constant (like is_main_module or something) as true if the module contains the main, and false otherwise. This allows to have a main() in each module. This is handy to have, it allows to compilerun modules both as normal modules to import, or to compile and run them as stand alone programs, like when you want a module to show a demo of its capabilities, or just run its unittests. Bye, bearophile
Re: Is flags enum needed in Phobos?
Era Scarecrow: But more likely it will be merged with another file, likely std.bitmanip or something... A Phobos pull request is OK even if it's meant to be merged with std.bitmanip. Pull requests are not just for separate modules. On GitHub people will be able to comment on single lines of code, etc. Bye, bearophile
Re: D seems interesting, but...
On Monday, 15 October 2012 at 11:20:26 UTC, bearophile wrote: Jacob Carlborg: How should DMD detect if you're building a (dynamic) library? Sure it can see that you're not using -lib or -shared but what about separate complication? What about the need to use a compiler switch if you are performing a separate compilation? A related enhancement request that I'm asking for since years is: the compiler could define a compile-time constant (like is_main_module or something) as true if the module contains the main, and false otherwise. This allows to have a main() in each module. This is handy to have, it allows to compilerun modules both as normal modules to import, or to compile and run them as stand alone programs, like when you want a module to show a demo of its capabilities, or just run its unittests. Bye, bearophile Yes, this is a nice thing Java, .NET and Python have.
Re: D seems interesting, but...
On Mon, 15 Oct 2012 07:43:54 +0100, Alex Rønne Petersen a...@lycus.org wrote: Yep, those errors are always a sign that a proper main function is missing. I have no idea why you would get it otherwise, though. So.. is it possible to save the source file in such a way that dmd cannot see main? i.e. not ASCII, UTF-8/16/32 or with a weird BOM, or no BOM or.. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
D interface for C library problems
Hello everyone.
I creating interface for gpgme
(http://www.gnupg.org/related_software/gpgme/) and have several
problems:
1. Library have variable with D keyword name:
/* The version string of the installed engine. */
char *version;
How can I create this variable in D interface?
2. Have an error in static function:
gpgme_err_code_t gpgme_err_code_from_syserror (void);
static inline gpgme_error_t
gpgme_error_from_syserror (void)
{
return gpgme_error (gpgme_err_code_from_syserror ());
}
When I write D code like this:
gpgme_err_code_t gpgme_err_code_from_syserror();
gpgme_error_t gpgme_error_from_syserror() {
return gpgme_error(gpgme_err_code_from_syserror());
}
I got error:
In function `gpgme_error_from_syserror':
src/main.d:(.text.gpgme_error_from_syserror+0x5): undefined
reference to `gpgme_err_code_from_syserror'
--- errorlevel 1
collect2: ld returned 1 exit status
Anyone knows how to fix this?
Thanks and sorry for my English.
Re: D seems interesting, but...
On 2012-10-15 11:58, Don Clugston wrote: I tried that on both Windows and Ubuntu, and couldn't get it to work on either of them. I posted a couple of bug reports eight months ago, and they still haven't been fixed. Not recommended for anyone who is having problems with their installation. I know it's not a perfect tool and it contains bugs but most things do work. I don't know which issues have been reported by you, but it seems there's a problem with the -l flag. Running dvm install 2.060 usually works. Could you please point out which issues have been reported by you. I have very limited time to work with D, as I understand most people here has, and I'm currently working on other projects than DVM since basically does what I intended it to do when I started the project. It seems most D installers are broken in one way or another. But the success rate with DVM seems to be quite high anyway. -- /Jacob Carlborg
Re: D interface for C library problems
On 2012-10-15 13:37, Oleg wrote:
2. Have an error in static function:
gpgme_err_code_t gpgme_err_code_from_syserror (void);
static inline gpgme_error_t
gpgme_error_from_syserror (void)
{
return gpgme_error (gpgme_err_code_from_syserror ());
}
When I write D code like this:
gpgme_err_code_t gpgme_err_code_from_syserror();
gpgme_error_t gpgme_error_from_syserror() {
return gpgme_error(gpgme_err_code_from_syserror());
}
I got error:
In function `gpgme_error_from_syserror':
src/main.d:(.text.gpgme_error_from_syserror+0x5): undefined reference to
`gpgme_err_code_from_syserror'
--- errorlevel 1
collect2: ld returned 1 exit status
Anyone knows how to fix this?
Thanks and sorry for my English.
You need to declare all functions you want to use from C as:
extern (C) gpgme_err_code_t gpgme_err_code_from_syserror();
Then you also need to link with the C library.
http://dlang.org/interfaceToC.html
--
/Jacob Carlborg
Re: D interface for C library problems
On Monday, 15 October 2012 at 11:42:41 UTC, Jacob Carlborg wrote:
On 2012-10-15 13:37, Oleg wrote:
You need to declare all functions you want to use from C as:
extern (C) gpgme_err_code_t gpgme_err_code_from_syserror();
Then you also need to link with the C library.
http://dlang.org/interfaceToC.html
I have extern wrapper:
extern (C) {
// code here
}
Re: D interface for C library problems
There is code http://pastebin.com/KyhFdx36
48 hour game jam
We did a 48hr game jam at work this past weekend. We decided to do our entry in D, to further prove that D was a viable and productive solution for real-world game dev. Here's our entry, for those interested. It has only been built/tested in Windows using VS2010, but it should theoretically work on Linux and consoles as well (but the build scripts aren't setup to do it automatically). If there is interest, I will create the build scripts, and test on Linux. https://github.com/RemedyGameJam/stache/wiki
Re: D seems interesting, but...
Regan Heath: So.. is it possible to save the source file in such a way that dmd cannot see main? This is a dirty solution (a hack). I don't like that. Bye, bearophile
Re: D seems interesting, but...
On Mon, 15 Oct 2012 13:08:42 +0100, bearophile bearophileh...@lycos.com wrote: Regan Heath: So.. is it possible to save the source file in such a way that dmd cannot see main? This is a dirty solution (a hack). I don't like that. Err.. I was suggesting this might be the OP's problem (I hadn't read the entire thread to know the actual problem was a bad package). I wondered if perhaps he had accidentally created an invalid D source file. I suspect the compiler complains when it encounters bad source files.. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: core.simd woes
On 15 October 2012 02:50, jerro a...@a.com wrote: Speaking of test – are they available somewhere? Now that LDC at least theoretically supports most of the GCC builtins, I'd like to throw some tests at it to see what happens. David I have a fork of std.simd with LDC support at https://github.com/jerro/** phobos/tree/std.simd https://github.com/jerro/phobos/tree/std.simd and some tests for it at https://github.com/jerro/std.**simd-testshttps://github.com/jerro/std.simd-tests. Awesome. Pull request plz! :) That said, how did you come up with a lot of these implementations? Some don't look particularly efficient, and others don't even look right. xor for instance: return cast(T) (cast(int4) v1 ^ cast(int4) v2); This is wrong for float types. x86 has separate instructions for doing this to floats, which make sure to do the right thing by the flags registers. Most of the LDC blocks assume that it could be any architecture... I don't think this will produce good portable code. It needs to be much more cafully hand-crafted, but it's a nice working start.
Re: D seems interesting, but...
On Monday, 15 October 2012 at 03:10:59 UTC, Gerry Weaver wrote: I install the latest package and try to build Hello World. I've always used the .zip and found it to be the easiest way (and btw, don't follow the terrible installation instructions, just unzip it and use right out of the box). $ wget blah/dmd.version.zip $ unzip dmd.version.zip $ dmd2/src/linux32/bin/dmd hello.d You can of course also add that to your $PATH or use a wrapper script or whatever so you can refer to it easier. That has consistently worked for me for many years. You can install it in /opt or in your own $HOME (my preference, so I don't even have to bother with root).
Re: D seems interesting, but...
On Monday, 15 October 2012 at 11:20:26 UTC, bearophile wrote:
This allows to have a main() in each module.
You could just version it:
version(foo_main)
void main() {}
Re: D seems interesting, but...
Le 15/10/2012 09:08, Gerry Weaver a écrit : On Monday, 15 October 2012 at 06:47:06 UTC, Jonathan M Davis wrote: On Sunday, October 14, 2012 23:40:41 H. S. Teoh wrote: Funny, as soon as I said that, I manage to reproduce the same error messages (though I can't say if it's exactly the problem you're seeing) by compiling a file that doesn't define main(). In this case, I had a hello.d with main() renamed to Main(): Yes. The error message that he's getting is essentially the one that you get when you don't define main, which is weird, because he _is_ defining main. But I don't know if it's exactly the same or not. A detailed comparison of the error messages that he's seeing and those that you get from not defining main on a machine that works would be required to see whether it's exactly the same message or not. I'm surprised that you didn't recognize the errors immediately. I guess that you haven't missed main very often (I'm used to it primarily from forgetting main when throwing together quick test scripts). But I'm totally stumped as to why he'd be getting them, since he does appear to be declaring main correctly. - Jonathan M Davis Hi, I decided to install the same distribution in a vm. This time instead of installing the .deb package, I went with the zip. Everything seems to be working! I can compile a non-trivial example just fine. I guess I'll definitely be using the zip from now on. Anyway, I also tried the zip version on Mac and Windoze. They both built the same code successfully. This is great! I can finally try out all of those great language features I've been reading about. Thanks to everyone for pushing me down the rabbit hole far enough this time to get some payback ;-) It's on now! Thanks, -G I would definitively encourage you to try the .deb on a clean install. I'm pretty sure your old install is confused by old half installed D stuffs.
Re: Import improvement
Le 15/10/2012 14:43, Manu a écrit : So I'm getting sick of this in my files: module stache.states.ingamestate; import fuji.filesystem; import fuji.render; import fuji.matrix; import fuji.material; import fuji.primitive; import fuji.system; import fuji.font; import std.xml; import std.string; import std.conv; import std.random; import std.algorithm; import stache.battlecamera; import stache.i.statemachine; import stache.game; import stache.util.eventtypes; import stache.i.entity; import stache.entity.combatant; import stache.entity.paimei; import stache.thinkers.localplayer; import stache.thinkers.nullthinker; import stache.i.collider; import stache.sound.soundset; import stache.sound.music; This is obviously silly. I know this could be improved with some care, more liberal public imports (dangerous, you risk ending up with EVERYTHING as public import if it sticks as a standard convention), better maintained dependencies... but it's not realistic in a production environment. That sort of maintenance just never happens. I suggest expanding the selective import mechanism to extend to modules, not just functions within a module, eg: module stache.states.ingamestate; import fuji: filesystem, render, matrix, material, primitive, system, font; import std: xml, string, conv, random, algorithm; import stache: game, battlecamera; import stache.i: statemachine, entity, collider; import stache.entity: combatant, paimei; import stache.thinkers: localplayer, nullthinker; import stache.sound: soundset, music; import stache.util.eventtypes; This is much better! Saved ~25 lines of import rubbish, and it also enforces logical grouping; individual import statements tends to lead to related submodules being distanced from eachother, this way, they appear on the same line. Surely this has been considered before. Any reasons it's not supported? It make sense.
Re: Import improvement
On Monday, 15 October 2012 at 12:43:59 UTC, Manu wrote:
Surely this has been considered before. Any reasons it's not
supported?
Yes, it has been considered before. There is an enhancement from
ages ago in bugzilla.
http://d.puremagic.com/issues/show_bug.cgi?id=3603
The syntax you proposed doesn't work, because it conflicts with
selective imports:
===[std.d]===
module std;
void stdio() {}
===[test.d]===
import std : stdio;
Does that import the stdio function from module std, or the
module std.stdio?
You could use something like this:
import std.(stdio, xml, algorithm);
Of course, there's many variations (square brackets, curly
braces, no dot, no commas...) but it's all bikeshedding.
Re: D seems interesting, but...
Adam D. Ruppe:
You could just version it:
version(foo_main)
void main() {}
That's not good enough.
What I as talking about is: when the D compilers know a module is
the main module, it defines a _standard_ version boolean flag,
named like is_main_module as true. And it gives a compiler
error if it can't find a main. Otherwise is_main_module is
false.
It's meant to be used as:
module modulea;
int foo() { return 0; }
static if (is_main_module) {
unittest {}
void main() { // demo code
import std.stdio;
writeln(foo());
}
}
module moduleb;
import modulea;
int bar() { return 1; }
static if (is_main_module) {
unittest {}
void main() { // demo code
import std.stdio;
writeln(foo());
writeln(bar());
}
}
When you compile modulea, defines its is_main_module as true, it
runs its unittests (if you have used -unittest), and its main,
that is a demo for the A module.
If you compile the moduleb (with rdmd or something), it knows
moduleb has to contain the main, it defines is_main_module=true
in moduleb and defines is_main_module=false for modulea. So it
compiles the main of moduleb and ignores the main of modulea. So
it runs the demo code for moduleb only.
Using a non-standard user-defined version as you suggest misses
all this, and it's not good enough. Standardization and
automation is important here.
Bye,
bearophile
Re: D seems interesting, but...
On 15 October 2012 08:23, Gerry Weaver ger...@compvia.com wrote:
On Monday, 15 October 2012 at 07:12:03 UTC, Iain Buclaw wrote:
On 15 October 2012 04:10, Gerry Weaver ger...@compvia.com wrote:
Hello All,
I have been looking at D off and on for several years. Initially I worked
through a very painful experience to get D compiling on Linux. After that
experience, I concluded that I should wait for it to become more mature.
Since then, I do a very simple test. I install the latest package and try
to
build Hello World. I figure that if Hello World builds successfully,
I
will continue further. I have just downloaded the latest .deb package and
installed it on Ubuntu 12.04 32bit. Once again it fails this incredibly
simple test. I've read many discussions about how/why, has/hasn't,
will/won't D hit the mainstream in programming languages. I think this
situation may offer at least one data point. I'm struggling to think of
any
other language (and I use several) that won't build code out of the box.
D
seems to have a lot of potential, but this needs to be fixed. I am not
asking for help on this. I honestly don't care what the solution is. I
just
wanted the D developers to know why at least one developer is not using
the
language. I sincerely hope that the situation will improve. I'm looking
forward to programming in D.
Thanks for your time,
-G
Here is the code:
import std.stdio;
void main()
{
writeln(Hello, world!);
}
Here is the command:
dmd hello.d
Here is the output:
/usr/lib/i386-linux-gnu/libphobos2.a(dmain2_459_1a5.o): In function
`_D2rt6dmain24mainUiPPaZi7runMainMFZv':
src/rt/dmain2.d:(.text._D2rt6dmain24mainUiPPaZi7runMainMFZv+0x10):
undefined
reference to `_Dmain'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_18f_1b8.o): In function
`_D4core6thread6Thread6__ctorMFZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFZC4core6thread6Thread+0x24):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_19f_6e4.o): In function
`thread_attachThis':
src/core/thread.d:(.text.thread_attachThis+0xb7): undefined reference to
`_tlsstart'
src/core/thread.d:(.text.thread_attachThis+0xbc): undefined reference to
`_tlsend'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17d_1b8.o): In function
`_D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFPFZvkZC4core6thread6Thread+0x27):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17e_1b8.o): In function
`_D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread':
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x1d):
undefined reference to `_tlsend'
src/core/thread.d:(.text._D4core6thread6Thread6__ctorMFDFZvkZC4core6thread6Thread+0x27):
undefined reference to `_tlsstart'
/usr/lib/i386-linux-gnu/libphobos2.a(deh2_43b_525.o): In function
`_D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable':
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x4):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0xc):
undefined reference to `_deh_beg'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x13):
undefined reference to `_deh_end'
src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh29FuncTable+0x36):
undefined reference to `_deh_end'
/usr/lib/i386-linux-gnu/libphobos2.a(thread_17a_713.o): In function
`thread_entryPoint':
src/core/thread.d:(.text.thread_entryPoint+0x64): undefined reference to
`_tlsend'
src/core/thread.d:(.text.thread_entryPoint+0x6a): undefined reference to
`_tlsstart'
collect2: ld returned 1 exit status
--- errorlevel 1
Try and paste the output of the following:
dmd -c hello.d
objdump -d hello.o
Regards
Hi,
Here you go.
hello.o: file format elf32-i386
Disassembly of section .text:
.text:
0: b8 10 00 00 00 mov$0x10,%eax
5: b9 00 00 00 00 mov$0x0,%ecx
a: 8b 11 mov(%ecx),%edx
c: 89 10 mov%edx,(%eax)
e: 89 01 mov%eax,(%ecx)
10: c3 ret
Thanks,
-G
That looks to me as if hello.d is an empty file.
Regards
--
Iain Buclaw
*(p e ? p++ : p) = (c 0x0f) + '0';
Re: D seems interesting, but...
On 10/14/2012 10:14 PM, Gerry Weaver wrote: I checked it out. There is only a dmd.conf. I've included it below. Try the following: locate dmd.conf locate dmd locate libphobos2.a locate object.di and see if there are any extras of these floating around.
Re: D seems interesting, but...
On 10/14/2012 11:43 PM, Alex Rønne Petersen wrote: Yep, those errors are always a sign that a proper main function is missing. I have no idea why you would get it otherwise, though. What happens is when the compiler sees main(), it triggers the compiler to emit a bunch of extra declarations into the object file. The missing symbols Gerry is seeing are just those declarations.
Re: core.simd woes
On Monday, 15 October 2012 at 12:19:47 UTC, Manu wrote:
On 15 October 2012 02:50, jerro a...@a.com wrote:
Speaking of test – are they available somewhere? Now that
LDC at least
theoretically supports most of the GCC builtins, I'd like to
throw some
tests at it to see what happens.
David
I have a fork of std.simd with LDC support at
https://github.com/jerro/**
phobos/tree/std.simd
https://github.com/jerro/phobos/tree/std.simd and
some tests for it at
https://github.com/jerro/std.**simd-testshttps://github.com/jerro/std.simd-tests.
Awesome. Pull request plz! :)
I did change an API for a few functions like loadUnaligned,
though. In those cases the signatures needed to be changed
because the functions used T or T* for scalar parameters and
return types and Vector!T for the vector parameters and return
types. This only compiles if T is a static array which I don't
think makes much sense. I changed those to take the vector type
as a template parameter. The vector type can not be inferred from
the scalar type because you can use vector registers of different
sizes simultaneously (with AVX, for example). Because of that the
vector type must be passed explicitly for some functions, so I
made it the first template parameter in those cases, so that Ver
doesn't always need to be specified.
There is one more issue that I need to solve (and that may be a
problem in some cases with GDC too) - the pure, @safe and
@nothrow attributes. Currently gcc builtin declarations in LDC
have none of those attributes (I have to look into which of those
can be added and if it can be done automatically). I've just
commented out the attributes in my std.simd fork for now, but
this isn't a proper solution.
That said, how did you come up with a lot of these
implementations? Some
don't look particularly efficient, and others don't even look
right.
xor for instance:
return cast(T) (cast(int4) v1 ^ cast(int4) v2);
This is wrong for float types. x86 has separate instructions
for doing this
to floats, which make sure to do the right thing by the flags
registers.
Most of the LDC blocks assume that it could be any
architecture... I don't
think this will produce good portable code. It needs to be much
more
cafully hand-crafted, but it's a nice working start.
The problem is that LLVM doesn't provide intrinsics for those
operations. The xor function does compile to a single xorps
instruction when compiling with -O1 or higher, though. I have
looked at the code generated for many (most, I think, but not for
all possible types) of those LDC blocks and most of them compile
to the appropriate single instruction when compiled with -O2 or
-O3. Even the ones for which the D source code looks horribly
inefficient like for example loadUnaligned.
By the way, clang does those in a similar way. For example, here
is what clang emits for a wrapper around _mm_xor_ps when compiled
with -O1 -emit-llvm:
define 4 x float @foo(4 x float %a, 4 x float %b) nounwind
uwtable readnone {
%1 = bitcast 4 x float %a to 4 x i32
%2 = bitcast 4 x float %b to 4 x i32
%3 = xor 4 x i32 %1, %2
%4 = bitcast 4 x i32 %3 to 4 x float
ret 4 x float %4
}
AFAICT, the only way to ensure that a certain instruction will be
used with LDC when there is no LLVM intrinsic for it is to use
inline assembly expressions. I remember having some problems with
those in the past, but it could be that I was doing something
wrong. Maybe we should look into that option too.
Re: Import improvement
On 15 October 2012 16:02, Peter Alexander peter.alexander...@gmail.comwrote:
On Monday, 15 October 2012 at 12:43:59 UTC, Manu wrote:
Surely this has been considered before. Any reasons it's not supported?
Yes, it has been considered before. There is an enhancement from ages ago
in bugzilla.
http://d.puremagic.com/issues/**show_bug.cgi?id=3603http://d.puremagic.com/issues/show_bug.cgi?id=3603
The syntax you proposed doesn't work, because it conflicts with selective
imports:
===[std.d]===
module std;
void stdio() {}
===[test.d]===
import std : stdio;
Does that import the stdio function from module std, or the module
std.stdio?
You could use something like this:
import std.(stdio, xml, algorithm);
Of course, there's many variations (square brackets, curly braces, no dot,
no commas...) but it's all bikeshedding.
Awesome. Well, just throwing it out there... any mechanism by which this is
possible will suit me!
Re: core.simd woes
On 15 October 2012 16:34, jerro a...@a.com wrote:
On Monday, 15 October 2012 at 12:19:47 UTC, Manu wrote:
On 15 October 2012 02:50, jerro a...@a.com wrote:
Speaking of test – are they available somewhere? Now that LDC at least
theoretically supports most of the GCC builtins, I'd like to throw some
tests at it to see what happens.
David
I have a fork of std.simd with LDC support at
https://github.com/jerro/**
phobos/tree/std.simd
https://github.com/jerro/**phobos/tree/std.simdhttps://github.com/jerro/phobos/tree/std.simd
and
some tests for it at
https://github.com/jerro/std.simd-testshttps://github.com/jerro/std.**simd-tests
https://github.**com/jerro/std.simd-testshttps://github.com/jerro/std.simd-tests
.
Awesome. Pull request plz! :)
I did change an API for a few functions like loadUnaligned, though. In
those cases the signatures needed to be changed because the functions used
T or T* for scalar parameters and return types and Vector!T for the vector
parameters and return types. This only compiles if T is a static array
which I don't think makes much sense. I changed those to take the vector
type as a template parameter. The vector type can not be inferred from the
scalar type because you can use vector registers of different sizes
simultaneously (with AVX, for example). Because of that the vector type
must be passed explicitly for some functions, so I made it the first
template parameter in those cases, so that Ver doesn't always need to be
specified.
There is one more issue that I need to solve (and that may be a problem in
some cases with GDC too) - the pure, @safe and @nothrow attributes.
Currently gcc builtin declarations in LDC have none of those attributes (I
have to look into which of those can be added and if it can be done
automatically). I've just commented out the attributes in my std.simd fork
for now, but this isn't a proper solution.
That said, how did you come up with a lot of these implementations? Some
don't look particularly efficient, and others don't even look right.
xor for instance:
return cast(T) (cast(int4) v1 ^ cast(int4) v2);
This is wrong for float types. x86 has separate instructions for doing
this
to floats, which make sure to do the right thing by the flags registers.
Most of the LDC blocks assume that it could be any architecture... I don't
think this will produce good portable code. It needs to be much more
cafully hand-crafted, but it's a nice working start.
The problem is that LLVM doesn't provide intrinsics for those operations.
The xor function does compile to a single xorps instruction when compiling
with -O1 or higher, though. I have looked at the code generated for many
(most, I think, but not for all possible types) of those LDC blocks and
most of them compile to the appropriate single instruction when compiled
with -O2 or -O3. Even the ones for which the D source code looks horribly
inefficient like for example loadUnaligned.
By the way, clang does those in a similar way. For example, here is what
clang emits for a wrapper around _mm_xor_ps when compiled with -O1
-emit-llvm:
define 4 x float @foo(4 x float %a, 4 x float %b) nounwind uwtable
readnone {
%1 = bitcast 4 x float %a to 4 x i32
%2 = bitcast 4 x float %b to 4 x i32
%3 = xor 4 x i32 %1, %2
%4 = bitcast 4 x i32 %3 to 4 x float
ret 4 x float %4
}
AFAICT, the only way to ensure that a certain instruction will be used
with LDC when there is no LLVM intrinsic for it is to use inline assembly
expressions. I remember having some problems with those in the past, but it
could be that I was doing something wrong. Maybe we should look into that
option too.
Inline assembly usually ruins optimising (code reordering around inline asm
blocks is usually considered impossible).
It's interesting that the x86 codegen makes such good sense of those
sequences, but I'm rather more concerned about other platforms. I wonder if
other platforms have a similarly incomplete subset of intrinsics? :/
Re: 48 hour game jam
On 15.10.2012 13:52, Manu wrote: We did a 48hr game jam at work this past weekend. We decided to do our entry in D, to further prove that D was a viable and productive solution for real-world game dev. Here's our entry, for those interested. It has only been built/tested in Windows using VS2010, but it should theoretically work on Linux and consoles as well (but the build scripts aren't setup to do it automatically). If there is interest, I will create the build scripts, and test on Linux. https://github.com/RemedyGameJam/stache/wiki Matt Damon on top of Mt. Fiji and four badass fighters... Sign me in! But how do you control that thing? The only thing that did something was Alt-F4. I haven't built it myself, just downloaded the zip from github and dx11_43.dll from somewhere. Martin
Re: Import improvement
Le 15/10/2012 15:02, Peter Alexander a écrit :
On Monday, 15 October 2012 at 12:43:59 UTC, Manu wrote:
Surely this has been considered before. Any reasons it's not supported?
Yes, it has been considered before. There is an enhancement from ages
ago in bugzilla.
http://d.puremagic.com/issues/show_bug.cgi?id=3603
The syntax you proposed doesn't work, because it conflicts with
selective imports:
===[std.d]===
module std;
void stdio() {}
===[test.d]===
import std : stdio;
Does that import the stdio function from module std, or the module
std.stdio?
You could use something like this:
import std.(stdio, xml, algorithm);
Of course, there's many variations (square brackets, curly braces, no
dot, no commas...) but it's all bikeshedding.
I don't think import should make the difference between packages/modules
and module content.
The example you take is only ambiguous if std is both a package and a
module which isn't allowed anyway now. It is a point on which people are
willing to advance already (Andrei have made a proposal about it).
I'm against introducing more new syntax to import. import is already a
complex beast.
Re: Import improvement
deadalnix: I don't think import should make the difference between packages/modules and module content. This is acceptable only if then it imports the module names only. It means that later you must write stdio.writeln(). I'm against introducing more new syntax to import. import is already a complex beast. The suggested syntax import std.(stdio, xml, algorithm); is probably sub-optimal, and maybe better solutions exist. But in most cases more syntax is way better than foggy/messy semantics. Bye, bearophile
Re: core.simd woes
On Monday, 15 October 2012 at 13:43:28 UTC, Manu wrote:
On 15 October 2012 16:34, jerro a...@a.com wrote:
On Monday, 15 October 2012 at 12:19:47 UTC, Manu wrote:
On 15 October 2012 02:50, jerro a...@a.com wrote:
Speaking of test – are they available somewhere? Now that
LDC at least
theoretically supports most of the GCC builtins, I'd like
to throw some
tests at it to see what happens.
David
I have a fork of std.simd with LDC support at
https://github.com/jerro/**
phobos/tree/std.simd
https://github.com/jerro/**phobos/tree/std.simdhttps://github.com/jerro/phobos/tree/std.simd
and
some tests for it at
https://github.com/jerro/std.simd-testshttps://github.com/jerro/std.**simd-tests
https://github.**com/jerro/std.simd-testshttps://github.com/jerro/std.simd-tests
.
Awesome. Pull request plz! :)
I did change an API for a few functions like loadUnaligned,
though. In
those cases the signatures needed to be changed because the
functions used
T or T* for scalar parameters and return types and Vector!T
for the vector
parameters and return types. This only compiles if T is a
static array
which I don't think makes much sense. I changed those to take
the vector
type as a template parameter. The vector type can not be
inferred from the
scalar type because you can use vector registers of different
sizes
simultaneously (with AVX, for example). Because of that the
vector type
must be passed explicitly for some functions, so I made it the
first
template parameter in those cases, so that Ver doesn't always
need to be
specified.
There is one more issue that I need to solve (and that may be
a problem in
some cases with GDC too) - the pure, @safe and @nothrow
attributes.
Currently gcc builtin declarations in LDC have none of those
attributes (I
have to look into which of those can be added and if it can be
done
automatically). I've just commented out the attributes in my
std.simd fork
for now, but this isn't a proper solution.
That said, how did you come up with a lot of these
implementations? Some
don't look particularly efficient, and others don't even look
right.
xor for instance:
return cast(T) (cast(int4) v1 ^ cast(int4) v2);
This is wrong for float types. x86 has separate instructions
for doing
this
to floats, which make sure to do the right thing by the flags
registers.
Most of the LDC blocks assume that it could be any
architecture... I don't
think this will produce good portable code. It needs to be
much more
cafully hand-crafted, but it's a nice working start.
The problem is that LLVM doesn't provide intrinsics for those
operations.
The xor function does compile to a single xorps instruction
when compiling
with -O1 or higher, though. I have looked at the code
generated for many
(most, I think, but not for all possible types) of those LDC
blocks and
most of them compile to the appropriate single instruction
when compiled
with -O2 or -O3. Even the ones for which the D source code
looks horribly
inefficient like for example loadUnaligned.
By the way, clang does those in a similar way. For example,
here is what
clang emits for a wrapper around _mm_xor_ps when compiled with
-O1
-emit-llvm:
define 4 x float @foo(4 x float %a, 4 x float %b)
nounwind uwtable
readnone {
%1 = bitcast 4 x float %a to 4 x i32
%2 = bitcast 4 x float %b to 4 x i32
%3 = xor 4 x i32 %1, %2
%4 = bitcast 4 x i32 %3 to 4 x float
ret 4 x float %4
}
AFAICT, the only way to ensure that a certain instruction will
be used
with LDC when there is no LLVM intrinsic for it is to use
inline assembly
expressions. I remember having some problems with those in the
past, but it
could be that I was doing something wrong. Maybe we should
look into that
option too.
Inline assembly usually ruins optimising (code reordering
around inline asm
blocks is usually considered impossible).
I don't see a reason why the compiler couldn't reorder code
around GCC style inline assembly blocks. You are supposed to
specify which registers are changed in the block. Doesn't that
give the compiler enough information to reorder code?
It's interesting that the x86 codegen makes such good sense of
those
sequences, but I'm rather more concerned about other platforms.
I wonder if
other platforms have a similarly incomplete subset of
intrinsics? :/
It looks to me like LLVM does provide intrinsics for those
operation that can't be expressed in other ways. So my guess is
that if some intrinsics are absolutely needed for some platform,
they will probably be there. If an intrinsic is needed, I also
don't see a reason why they wouldn't accept a patch that ads it.
Re: Import improvement
On Monday, 15 October 2012 at 13:46:43 UTC, deadalnix wrote: I don't think import should make the difference between packages/modules and module content. The example you take is only ambiguous if std is both a package and a module which isn't allowed anyway now. It is a point on which people are willing to advance already (Andrei have made a proposal about it). My example with module std works as of DMD 2.060, and I can't see anything in the spec that says it is disallowed, or are you saying that it has been agreed that it will be disallowed in the future? I'm against introducing more new syntax to import. import is already a complex beast. I agree, but I also don't like the idea of using the same syntax to mean two different things. import foo : bar, baz; Is this selectively importing symbols or is it importing two modules? This is mildly confusing for the programmer, and complicates parsing.
Re: Import improvement
On 2012-43-15 14:10, Manu turkey...@gmail.com wrote: module stache.states.ingamestate; import fuji: filesystem, render, matrix, material, primitive, system, font; import std: xml, string, conv, random, algorithm; import stache: game, battlecamera; import stache.i: statemachine, entity, collider; import stache.entity: combatant, paimei; import stache.thinkers: localplayer, nullthinker; import stache.sound: soundset, music; import stache.util.eventtypes; Looks nice. Much better than before, certainly. Now, i'm wondering, you /do/ know this is possible, right: import fuji.filesystem, fuji.render, fuji.matrix, fuji.material, fuji.primitive, fuji.system, fuji.font; import std.xml, std.string, std.conv, std.random, std.algorithm; import stache.game, stache.battlecamera; import stache.i.statemachine, stache.i.entity, stache.i.collider; import stache.entity.combatant, stache.entity.paimei; import stache.thinkers.localplayer, stache.thinkers.nullthinker; import stache.sound.soundset, stache.sound.music; import stache.util.eventtypes; Not quite as neat, but still a lot better, methinks. -- Simen
Re: D seems interesting, but...
On Monday, 15 October 2012 at 13:11:29 UTC, bearophile wrote:
Adam D. Ruppe:
You could just version it:
version(foo_main)
void main() {}
That's not good enough.
What I as talking about is: when the D compilers know a module
is
the main module, it defines a _standard_ version boolean flag,
named like is_main_module as true. And it gives a compiler
error if it can't find a main. Otherwise is_main_module is
false.
It's meant to be used as:
module modulea;
int foo() { return 0; }
static if (is_main_module) {
unittest {}
void main() { // demo code
import std.stdio;
writeln(foo());
}
}
module moduleb;
import modulea;
int bar() { return 1; }
static if (is_main_module) {
unittest {}
void main() { // demo code
import std.stdio;
writeln(foo());
writeln(bar());
}
}
When you compile modulea, defines its is_main_module as true, it
runs its unittests (if you have used -unittest), and its main,
that is a demo for the A module.
If you compile the moduleb (with rdmd or something), it knows
moduleb has to contain the main, it defines is_main_module=true
in moduleb and defines is_main_module=false for modulea. So it
compiles the main of moduleb and ignores the main of modulea. So
it runs the demo code for moduleb only.
Using a non-standard user-defined version as you suggest misses
all this, and it's not good enough. Standardization and
automation is important here.
Bye,
bearophile
I'm sorry to say but that *is* a _horrible_ _hack_. It looks
almost as awful as it does in python with the underscores.
Java has the correct DRY solution - each class can define a
static main method but the compiler only uses the one specified
by a compiler switch.
The above basically asks the programmer to endlessly repeat the
same trivial implementation boilerplate that should be written
just once _in_ the compiler.
Re: Import improvement
On Monday, 15 October 2012 at 14:20:48 UTC, Peter Alexander wrote: On Monday, 15 October 2012 at 13:46:43 UTC, deadalnix wrote: I don't think import should make the difference between packages/modules and module content. The example you take is only ambiguous if std is both a package and a module which isn't allowed anyway now. It is a point on which people are willing to advance already (Andrei have made a proposal about it). My example with module std works as of DMD 2.060, and I can't see anything in the spec that says it is disallowed, or are you saying that it has been agreed that it will be disallowed in the future? I'm against introducing more new syntax to import. import is already a complex beast. I agree, but I also don't like the idea of using the same syntax to mean two different things. import foo : bar, baz; Is this selectively importing symbols or is it importing two modules? This is mildly confusing for the programmer, and complicates parsing. And what about import foo : bar, .baz; where .baz is module
Re: core.simd woes
On 15 October 2012 17:07, jerro a...@a.com wrote:
On Monday, 15 October 2012 at 13:43:28 UTC, Manu wrote:
On 15 October 2012 16:34, jerro a...@a.com wrote:
On Monday, 15 October 2012 at 12:19:47 UTC, Manu wrote:
On 15 October 2012 02:50, jerro a...@a.com wrote:
Speaking of test – are they available somewhere? Now that LDC at least
theoretically supports most of the GCC builtins, I'd like to throw
some
tests at it to see what happens.
David
I have a fork of std.simd with LDC support at
https://github.com/jerro/**
phobos/tree/std.simd https://github.com/jerro/
phobos/tree/std.simd https://github.com/jerro/**phobos/tree/std.simd
https://**github.com/jerro/phobos/tree/**std.simdhttps://github.com/jerro/phobos/tree/std.simd
and
some tests for it at
https://github.com/jerro/std.**simd-testshttps://github.com/jerro/std.simd-tests
https://github.**com/jerro/std.**simd-testshttps://github.com/jerro/std.**simd-tests
https://github.**com/jerro/**std.simd-testshttps://github.**
com/jerro/std.simd-tests https://github.com/jerro/std.simd-tests
.
Awesome. Pull request plz! :)
I did change an API for a few functions like loadUnaligned, though. In
those cases the signatures needed to be changed because the functions
used
T or T* for scalar parameters and return types and Vector!T for the
vector
parameters and return types. This only compiles if T is a static array
which I don't think makes much sense. I changed those to take the vector
type as a template parameter. The vector type can not be inferred from
the
scalar type because you can use vector registers of different sizes
simultaneously (with AVX, for example). Because of that the vector type
must be passed explicitly for some functions, so I made it the first
template parameter in those cases, so that Ver doesn't always need to be
specified.
There is one more issue that I need to solve (and that may be a problem
in
some cases with GDC too) - the pure, @safe and @nothrow attributes.
Currently gcc builtin declarations in LDC have none of those attributes
(I
have to look into which of those can be added and if it can be done
automatically). I've just commented out the attributes in my std.simd
fork
for now, but this isn't a proper solution.
That said, how did you come up with a lot of these implementations? Some
don't look particularly efficient, and others don't even look right.
xor for instance:
return cast(T) (cast(int4) v1 ^ cast(int4) v2);
This is wrong for float types. x86 has separate instructions for doing
this
to floats, which make sure to do the right thing by the flags registers.
Most of the LDC blocks assume that it could be any architecture... I
don't
think this will produce good portable code. It needs to be much more
cafully hand-crafted, but it's a nice working start.
The problem is that LLVM doesn't provide intrinsics for those operations.
The xor function does compile to a single xorps instruction when
compiling
with -O1 or higher, though. I have looked at the code generated for many
(most, I think, but not for all possible types) of those LDC blocks and
most of them compile to the appropriate single instruction when compiled
with -O2 or -O3. Even the ones for which the D source code looks horribly
inefficient like for example loadUnaligned.
By the way, clang does those in a similar way. For example, here is what
clang emits for a wrapper around _mm_xor_ps when compiled with -O1
-emit-llvm:
define 4 x float @foo(4 x float %a, 4 x float %b) nounwind uwtable
readnone {
%1 = bitcast 4 x float %a to 4 x i32
%2 = bitcast 4 x float %b to 4 x i32
%3 = xor 4 x i32 %1, %2
%4 = bitcast 4 x i32 %3 to 4 x float
ret 4 x float %4
}
AFAICT, the only way to ensure that a certain instruction will be used
with LDC when there is no LLVM intrinsic for it is to use inline assembly
expressions. I remember having some problems with those in the past, but
it
could be that I was doing something wrong. Maybe we should look into that
option too.
Inline assembly usually ruins optimising (code reordering around inline
asm
blocks is usually considered impossible).
I don't see a reason why the compiler couldn't reorder code around GCC
style inline assembly blocks. You are supposed to specify which registers
are changed in the block. Doesn't that give the compiler enough information
to reorder code?
Not necessarily. If you affect various flags registers or whatever, or
direct memory access might violate it's assumptions about the state of
memory/stack.
I don't think I've come in contact with any compiler's that aren't
super-conservative about this sort of thing.
It's interesting that the x86 codegen makes such good sense of those
sequences, but I'm rather more concerned about other platforms. I wonder
if
other platforms have a similarly incomplete subset of intrinsics? :/
It looks to me like LLVM does provide intrinsics for
Re: 48 hour game jam
On 15 October 2012 16:18, Martin Drasar dra...@ics.muni.cz wrote: On 15.10.2012 13:52, Manu wrote: We did a 48hr game jam at work this past weekend. We decided to do our entry in D, to further prove that D was a viable and productive solution for real-world game dev. Here's our entry, for those interested. It has only been built/tested in Windows using VS2010, but it should theoretically work on Linux and consoles as well (but the build scripts aren't setup to do it automatically). If there is interest, I will create the build scripts, and test on Linux. https://github.com/RemedyGameJam/stache/wiki Matt Damon on top of Mt. Fiji and four badass fighters... Sign me in! But how do you control that thing? The only thing that did something was Alt-F4. I haven't built it myself, just downloaded the zip from github and dx11_43.dll from somewhere. Ah, nicely spotted, I should stick that DLL in the zip now that you mention it. Controls are by gamepads (work in a console dev studio, no shortage of 360 pads! ;)
Re: 48 hour game jam
On 15 October 2012 17:02, bearophile bearophileh...@lycos.com wrote: Manu: We did a 48hr game jam at work this past weekend. We decided to do our entry in D, to further prove that D was a viable and productive solution for real-world game dev. And how did D do? Well actually. It was my team-mates first D code. He was interested, read some stuff, never actually wrote any code. We actually took quite tangible benefits from using D for this one. We actually used the class factory (!), I didn't think I'd ever use that ;) Also used a convenient C# style event system, trivial to implement in D. But mainly it's all the little things, conveniences that add up and make the experience more enjoyable. That said, the code probably isn't particularly idiomatic D code. That's to be expected from new comers I suppose, bringing the conventions of their languages to the table, but it's also a great thing in terms of adoption potential, people can ween themselves in slowly. It's not an all or nothing switch.
Re: D seems interesting, but...
On 10/15/12 7:24 AM, Paulo Pinto wrote:
On Monday, 15 October 2012 at 11:20:26 UTC, bearophile wrote:
Jacob Carlborg:
How should DMD detect if you're building a (dynamic) library? Sure it
can see that you're not using -lib or -shared but what about separate
complication?
What about the need to use a compiler switch if you are performing a
separate compilation?
A related enhancement request that I'm asking for since years is: the
compiler could define a compile-time constant (like is_main_module or
something) as true if the module contains the main, and false
otherwise. This allows to have a main() in each module. This is handy
to have, it allows to compilerun modules both as normal modules to
import, or to compile and run them as stand alone programs, like when
you want a module to show a demo of its capabilities, or just run its
unittests.
Bye,
bearophile
Yes, this is a nice thing Java, .NET and Python have.
Wonder if a simple convention would suffice, e.g. every module that
wanna defines a moduleMain(string[] args) and then you have one module
main.d that has:
void main(string[] args) { import wuddever; moduleMain(args); }
Andrei
Re: Import improvement
On 10/15/12 8:43 AM, Manu wrote: So I'm getting sick of this in my files: [snip litany of imports] This is obviously silly. Agreed. I know this could be improved with some care, more liberal public imports (dangerous, you risk ending up with EVERYTHING as public import if it sticks as a standard convention), better maintained dependencies... but it's not realistic in a production environment. That sort of maintenance just never happens. I suggest expanding the selective import mechanism to extend to modules, not just functions within a module, eg: module stache.states.ingamestate; import fuji: filesystem, render, matrix, material, primitive, system, font; import std: xml, string, conv, random, algorithm; import stache: game, battlecamera; import stache.i: statemachine, entity, collider; import stache.entity: combatant, paimei; import stache.thinkers: localplayer, nullthinker; import stache.sound: soundset, music; import stache.util.eventtypes; This is much better! Saved ~25 lines of import rubbish, and it also enforces logical grouping; individual import statements tends to lead to related submodules being distanced from eachother, this way, they appear on the same line. Surely this has been considered before. Any reasons it's not supported? I don't think imports from a specific package have been considered. In my personal opinion, imports are a necessary evil and it's sort of a bummer that the most accessible place in any source file - the top lines - is occupied by the crappy legal disclaimer (which, after having talked to a lawyer, I always put at the bottom since being at the top is not a requirement), and the litany of imports that the module is using. I'd make all imports local or put them at the bottom of the file if it weren't too much of a shock to others. Three remarks on this particular problem. 1. I expect large packages to introduce a module all.di or _.di to publicly import everything in the package. That could help some use cases. 2. The import declaration accepts a list of modules, and several may be on one line. I think that's a significant positive difference from C, C++, or Go, all of which force one imported module per line. I always advocate imports from the same package in the same import declaration, ordered alphabetically: import fuji.filesystem, fuji.font, fuji.material, fuji.matrix, fuji.primitive, fuji.render, fuji.system; import std.algorithm, std.conv, std.random, std.string, std.xml; ... That makes the existing system much more palatable. 3. I think local imports are currently underutilized. It would be interesting to see what kind of project dynamics they enable. Andrei
Re: Import improvement
On 15 October 2012 17:29, Simen Kjaeraas simen.kja...@gmail.com wrote: On 2012-43-15 14:10, Manu turkey...@gmail.com wrote: module stache.states.ingamestate; import fuji: filesystem, render, matrix, material, primitive, system, font; import std: xml, string, conv, random, algorithm; import stache: game, battlecamera; import stache.i: statemachine, entity, collider; import stache.entity: combatant, paimei; import stache.thinkers: localplayer, nullthinker; import stache.sound: soundset, music; import stache.util.eventtypes; Looks nice. Much better than before, certainly. Now, i'm wondering, you /do/ know this is possible, right: import fuji.filesystem, fuji.render, fuji.matrix, fuji.material, fuji.primitive, fuji.system, fuji.font; import std.xml, std.string, std.conv, std.random, std.algorithm; import stache.game, stache.battlecamera; import stache.i.statemachine, stache.i.entity, stache.i.collider; import stache.entity.combatant, stache.entity.paimei; import stache.thinkers.localplayer, stache.thinkers.nullthinker; import stache.sound.soundset, stache.sound.music; import stache.util.eventtypes; I didn't know that was possible _ Cheers for the protip!
Re: Import improvement
On 10/15/12 11:46 AM, Manu wrote: On 15 October 2012 17:29, Simen Kjaeraas simen.kja...@gmail.com mailto:simen.kja...@gmail.com wrote: import fuji.filesystem, fuji.render, fuji.matrix, fuji.material, fuji.primitive, fuji.system, fuji.font; import std.xml, std.string, std.conv, std.random, std.algorithm; import stache.game, stache.battlecamera; import stache.i.statemachine, stache.i.entity, stache.i.collider; import stache.entity.combatant, stache.entity.paimei; import stache.thinkers.localplayer, stache.thinkers.nullthinker; import stache.sound.soundset, stache.sound.music; import stache.util.eventtypes; I didn't know that was possible _ Cheers for the protip! I think our documentation examples could be changed to use multiple imports systematically. Andrei
Re: D interface for C library problems
On Monday, 15 October 2012 at 11:37:22 UTC, Oleg wrote: I got error: In function `gpgme_error_from_syserror': src/main.d:(.text.gpgme_error_from_syserror+0x5): undefined reference to `gpgme_err_code_from_syserror' --- errorlevel 1 collect2: ld returned 1 exit status Anyone knows how to fix this? Thanks and sorry for my English. I think you missed a library with err codes and functions. You should used -L compiler flag or pragma(lib, nameoflib);
Re: What is the case against a struct post-blit default constructor?
On Thu, 11 Oct 2012 13:23:10 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
Any situation where the init value is essentially invalid (like it would
be
with floating point types) makes it so that you can't have an invariant,
and in
many of those cases, having a default constructor which was always called
would solve the problem. I'm still in favor of _not_ trying to add
default
constructors given all of the issues involved, and I agree that on the
whole,
init is a superior solution (even if it isn't perfect), but there _are_
cases
where you can't have an invariant because of it.
Isn't it possible to customize when an invariant is called using
contracts?
For example:
struct S
{
private bool isValid;
private void _invariant() {assert(isValid);}
void foo()
in { _invariant();} out {_invariant();} body
{
// whatever
}
void opAssign(ref S other)
out {_invariant();} body
{
isValid = other.isValid;
}
}
???
Yeah, It's extra work. But essentially, isn't this what you want? The
thing about disabling invariant checks on some specific function in some
specific case is that someone else has a valid case for requiring it.
The only sucky part about the above is, _invariant is compiled in even in
release mode (though it should inline to a noop).
-Steve
Re: What is the case against a struct post-blit default constructor?
On Monday, 15 October 2012 at 15:56:33 UTC, Steven Schveighoffer
wrote:
Isn't it possible to customize when an invariant is called
using contracts?
For example:
struct S
{
private bool isValid;
private void _invariant() {assert(isValid);}
void foo()
in { _invariant();} out {_invariant();} body
{
// whatever
}
void opAssign(ref S other)
out {_invariant();} body
{
isValid = other.isValid;
}
}
???
Yeah, It's extra work. But essentially, isn't this what you
want? The thing about disabling invariant checks on some
specific function in some specific case is that someone else
has a valid case for requiring it.
The only sucky part about the above is, _invariant is compiled
in even in release mode (though it should inline to a noop).
-Steve
There is now an assert word for version blocks so you can put
your code inside that, and it doesn't get compiled in during
release.
Re: 48 hour game jam
On Monday, 15 October 2012 at 15:01:27 UTC, Manu wrote: But mainly it's all the little things, conveniences that add up and make the experience more enjoyable. I find this as well. D has a lot of neat and interesting features, but really the big advantages over C++ (for me) are: - No header files - Closures - Polymorphic lambdas - Aliases - Simple(r) templates The biggest problem with D at the moment for me is the quality of error messages, especially when using templates with constraints. The best error you'll get is can't call this function with these arguments, and you have to go through and manually expand the templates in your head to see what went wrong. Not fun.
Re: 48 hour game jam
On Monday, 15 October 2012 at 11:52:49 UTC, Manu wrote: We did a 48hr game jam at work this past weekend. We decided to do our entry in D, to further prove that D was a viable and productive solution for real-world game dev. Here's our entry, for those interested. It has only been built/tested in Windows using VS2010, but it should theoretically work on Linux and consoles as well (but the build scripts aren't setup to do it automatically). If there is interest, I will create the build scripts, and test on Linux. https://github.com/RemedyGameJam/stache/wiki Nice! I might not get a chance to download the game in the next few days, but I glanced at the source and everything looks cool. Any screenshots? About that Linux build script, if you manage to make it, let me know :) ps. I'm surprised I don't see a bunch of 'final ...' throughout your code. I thought a big issue of yours in the past was D's auto-virtual functions. Has something been changed in that area that I missed, or have you just not gotten around to doing it (or you don't need it for this project)?
Re: D seems interesting, but...
I am asking for a specific way to solve this problem, Sorry, I am not asking for a specific way to solve this problem, but... Bye, bearophile
Re: D seems interesting, but...
foobar: I'm sorry to say but that *is* a _horrible_ _hack_. It looks almost as awful as it does in python with the underscores. Java has the correct DRY solution - each class can define a static main method but the compiler only uses the one specified by a compiler switch. The above basically asks the programmer to endlessly repeat the same trivial implementation boilerplate that should be written just once _in_ the compiler. What I have suggested is the simplest (requires less stuff to be implemented) way to solve the problem, adding just a single compile time constant. But I agree there are better ways to solve the same problem. I am asking for a specific way to solve this problem, but since some years I'd like some good enough way to solve it. Bye, bearophile
Important packages
Hello All, Thanks again for helping me get going with D! I been looking around a little and noticed that there are packages for CMake, Qt, and there is vibe.d. If I would have realized the existence of these earlier, D would have been much higher on my list of things to check out in depth. Someone should make mention of these on the main D language web page. Some type of a package showcase with code snippets etc. They represent the possibility to build end to end cross-platform solutions with a great build tool to boot. I had no idea things had progressed this far. It makes a BIG difference. I would think this would go a long way to convince the casual browser to dig deeper. I was just thinking how interesting it would have been, if Google had decided to dedicate their considerable resources to D, instead of rolling their own language. Then again, it looks like D is ready for some serious development. When I think about the latest C++ abomination, the timing couldn't be better. I'm going to be dedicating some time to get up to speed. Many thanks to those that put in the hard work to get D to this point. Thanks, -G
Account on ARM/Debian
I've been talking to Iain Buclaw, gdc's leader, and was surprised to learn he has a quite workable ARM port available. To make it production-ready, we should have some continuous test integration, which entails ssh access to an ARM/Debian account. Is there anyone on this list who'd want to donate such an account? Thanks, Andrei
Re: Important packages
On 10/15/12 12:52 PM, Gerry Weaver wrote: Hello All, Thanks again for helping me get going with D! I been looking around a little and noticed that there are packages for CMake, Qt, and there is vibe.d. If I would have realized the existence of these earlier, D would have been much higher on my list of things to check out in depth. Someone should make mention of these on the main D language web page. Some type of a package showcase with code snippets etc. They represent the possibility to build end to end cross-platform solutions with a great build tool to boot. I had no idea things had progressed this far. It makes a BIG difference. I would think this would go a long way to convince the casual browser to dig deeper. I was just thinking how interesting it would have been, if Google had decided to dedicate their considerable resources to D, instead of rolling their own language. Then again, it looks like D is ready for some serious development. When I think about the latest C++ abomination, the timing couldn't be better. I'm going to be dedicating some time to get up to speed. Many thanks to those that put in the hard work to get D to this point. Thanks, -G Thanks for pursuing the installation issue and for your suggestion. I, too, think we should collect a short list of good D projects and feature them on dlang.org. If anyone would like to start designing and integrating such a page, please make the pull request and let's talk! Andrei
Re: 48 hour game jam
On Mon, Oct 15, 2012 at 06:37:06PM +0200, Peter Alexander wrote:
On Monday, 15 October 2012 at 15:01:27 UTC, Manu wrote:
But mainly it's all the little things, conveniences that add up and
make the experience more enjoyable.
I find this as well.
D has a lot of neat and interesting features, but really the big
advantages over C++ (for me) are:
- No header files
- Closures
- Polymorphic lambdas
Yeah closures are a major necessity in any modern language. Recently
I've had to work with some code that was greatly simplified because I
could simply return closures. Writing the same code in C++ or C would
have required horrendously more code and complexity.
I also found std.algorithm and std.range to be incredibly powerful in
expressing common sequential operations in a concise way, often as
one-liners where in C++ you'd have to manually write a for/while loop
with manually-managed indices, increments, loop termination conditions,
etc..
Writing custom structs/classes to conform to the range API also makes it
possible to pass things around to library code that expect ranges,
greatly eliminating lots of boilerplate code that would be needed in C++
to transcribe from one object list to another and back, ad nauseum.
- Aliases
- Simple(r) templates
The biggest advantage of D templates is that the syntax is actually
sane!! When I was coding in C++, my eyes started to glaze over as soon
as templates get nested more than 2 levels deep. Especially when a
compiler error message contained a single template name that spanned 16
lines of output. Not fun.
The biggest problem with D at the moment for me is the quality of
error messages, especially when using templates with constraints. The
best error you'll get is can't call this function with these
arguments, and you have to go through and manually expand the
templates in your head to see what went wrong. Not fun.
[...]
I've asked before for a catch-all template, which is a template that
will be selected only if no other template is matched. This can then be
used in library code to print a nicer error message than the current
situation where the compiler basically talks to you in Klingon.
One alternative I've thought of (and tried before on one occasion) is
that instead of writing:
RetVal MyTemplateFunc(T)(T args...) if (Condition1) {...}
RetVal MyTemplateFunc(T)(T args...) if (Condition2) {...}
RetVal MyTemplateFunc(T)(T args...) if (Condition3) {...}
One could write:
RetVal MyTemplateFunc(T)(T args...)
{
static if (Condition1) { ... }
else static if (Condition2) { ... }
else static if (Condition3) { ... }
else static assert(0, NiceErrorMsgOnWhyConditionsDidNotMatch);
}
To be even more helpful, one could expand the static assert into a
block:
... else
{
pragma(msg, Template conditions failed:);
pragma(msg, Condition1 Clause1 = , Condition1_clause1);
pragma(msg, Condition1 Clause2 = , Condition1_clause2);
pragma(msg, Condition2 = , Condition2);
...
static assert(0);
}
Something like this is probably the compiler's job, but one could
present the info in a more human-understandable way, for example:
RetVal MyTemplateFunc(S,T)(S s, T t)
{
static if (isInputRange!S)
{
static if (isForwardRange!T)
...
else static assert(0, t must be forward range when s
is output range);
}
else static if (isForwardRange!S)
{
static if (isOutputRange!T)
...
else static assert(0, t must be output range when s is
forward range);
}
else ...
}
Of course, effort needs to be invested to write code in this way in the
first place. As a baseline, it's probably still better to have the
compiler print out exactly which conditions failed to match (by
recursively expanding templates for you). The output will be very
verbose, though.
T
--
MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs
Re: Import improvement
On 2012-10-15 14:43, Manu wrote: This is obviously silly. I know this could be improved with some care, more liberal public imports (dangerous, you risk ending up with EVERYTHING as public import if it sticks as a standard convention), better maintained dependencies... but it's not realistic in a production environment. That sort of maintenance just never happens. I suggest expanding the selective import mechanism to extend to modules, not just functions within a module, eg: module stache.states.ingamestate; import fuji: filesystem, render, matrix, material, primitive, system, font; import std: xml, string, conv, random, algorithm; import stache: game, battlecamera; import stache.i: statemachine, entity, collider; import stache.entity: combatant, paimei; import stache.thinkers: localplayer, nullthinker; import stache.sound: soundset, music; import stache.util.eventtypes; This is much better! Saved ~25 lines of import rubbish, and it also enforces logical grouping; individual import statements tends to lead to related submodules being distanced from eachother, this way, they appear on the same line. Surely this has been considered before. Any reasons it's not supported? Shouldn't it be possible to create a mixin that does this? mixin require(std, xml, string); Something like that. But you would still need to import the require function. -- /Jacob Carlborg
Re: 48 hour game jam
On Monday, 15 October 2012 at 16:37:08 UTC, Peter Alexander wrote: ... - Simple(r) templates I keep seeing things like this and probably i am failing to understand it. This is a vast understatement for D templates. Yes, easier to use, i agree. But C++ templates are stone age comparing to D and i don't see this mentioned enough where it matters most. It was there in recent reddit discussions too. I am reading those comments (some posters obviously have some kind of agenda) and seeing no one refuting them. They neither know C++ well enough to do metaprogramming nor D. Because if they did know, they would never bring templates into any discussions which involves C++/D comparison. Comparing to C++. * D templates easier to use. * There are constructs you can't just do templates without. (templates without static if is c without if) * Some things possible (string/float/alias/... arguments) because there is no C++ way of doing these. * Some things possible in practice (there are things you can achieve with C++ templates but they are practically impossible) * You can have all these and able get higher performance. There are probably more of those i just can't remember now.
Re: 48 hour game jam
On Monday, 15 October 2012 at 16:37:08 UTC, Peter Alexander wrote: On Monday, 15 October 2012 at 15:01:27 UTC, Manu wrote: But mainly it's all the little things, conveniences that add up and make the experience more enjoyable. I find this as well. D has a lot of neat and interesting features, but really the big advantages over C++ (for me) are: - No header files - Closures - Polymorphic lambdas - Aliases - Simple(r) templates The biggest problem with D at the moment for me is the quality of error messages, especially when using templates with constraints. The best error you'll get is can't call this function with these arguments, and you have to go through and manually expand the templates in your head to see what went wrong. Not fun. For me: - aliases (Can't believe how Java and C# don't have them) - templates - meta-programming - open source language Sadly at work it is hard to sneak in D, because we mainly do JVM/.NET stuff, with C++ projects considered legacy(!). -- Paulo
Re: D seems interesting, but...
On 10/15/2012 06:22 AM, Iain Buclaw wrote: On 15 October 2012 08:23, Gerry Weaverger...@compvia.com wrote: Disassembly of section .text: .text: 0: b8 10 00 00 00 mov$0x10,%eax 5: b9 00 00 00 00 mov$0x0,%ecx a: 8b 11 mov(%ecx),%edx c: 89 10 mov%edx,(%eax) e: 89 01 mov%eax,(%ecx) 10: c3 ret Thanks, -G That looks to me as if hello.d is an empty file. That is the most plausible reason so far: The OP has an empty file in the current directory but the hello.d that is being edited in Emacs is elsewhere. :) Ali
Re: D seems interesting, but...
On Monday, 15 October 2012 at 15:22:38 UTC, Andrei Alexandrescu
wrote:
snip
Yes, this is a nice thing Java, .NET and Python have.
Wonder if a simple convention would suffice, e.g. every module
that wanna defines a moduleMain(string[] args) and then you
have one module main.d that has:
void main(string[] args) { import wuddever; moduleMain(args); }
Andrei
Great idea! But why add another (redundant) level of indirection?
It should go in the C main in druntime together with a mechanism
to call the correct D main, by e.g. reading the module name from
the command line.
Re: D seems interesting, but...
On Monday, 15 October 2012 at 17:36:10 UTC, Ali Çehreli wrote: On 10/15/2012 06:22 AM, Iain Buclaw wrote: On 15 October 2012 08:23, Gerry Weaverger...@compvia.com wrote: Disassembly of section .text: .text: 0: b8 10 00 00 00 mov$0x10,%eax 5: b9 00 00 00 00 mov$0x0,%ecx a: 8b 11 mov(%ecx),%edx c: 89 10 mov%edx,(%eax) e: 89 01 mov%eax,(%ecx) 10: c3 ret Thanks, -G That looks to me as if hello.d is an empty file. That is the most plausible reason so far: The OP has an empty file in the current directory but the hello.d that is being edited in Emacs is elsewhere. :) Ali Hi, I have been looking into this. I'm afraid it isn't that simple. I just created the file with vi in the same directory I was trying to compile it in. I can cat it etc., so I know the text is there. I have even reproduced the issue on a different partition etc.. I'm starting to think that some other package that is installed on this particular system may be the source of the problem. I can't reproduce the issue on another install of the same OS, version, etc.. I went ahead and installed the .deb package on the new system and it still works. Thanks, -G
Re: D seems interesting, but...
On 10/15/12 1:37 PM, foobar wrote:
On Monday, 15 October 2012 at 15:22:38 UTC, Andrei Alexandrescu wrote:
snip
Yes, this is a nice thing Java, .NET and Python have.
Wonder if a simple convention would suffice, e.g. every module that
wanna defines a moduleMain(string[] args) and then you have one module
main.d that has:
void main(string[] args) { import wuddever; moduleMain(args); }
Andrei
Great idea! But why add another (redundant) level of indirection?
It should go in the C main in druntime together with a mechanism to call
the correct D main, by e.g. reading the module name from the command line.
Well there's a tension here: good language design generally aims at
providing few general features applicable to many use cases. Encoding
particular use cases in the language is warranted by either
disproportionate frequency in use or disproportionate difficulty in
implementing them within the language. I don't think this particular
feature scores very highly in either category.
Andrei
Re: 48 hour game jam
On Mon, Oct 15, 2012 at 07:19:42PM +0200, so wrote:
On Monday, 15 October 2012 at 16:37:08 UTC, Peter Alexander wrote:
...
- Simple(r) templates
I keep seeing things like this and probably i am failing to understand
it. This is a vast understatement for D templates. Yes, easier to
use, i agree. But C++ templates are stone age comparing to D and i
don't see this mentioned enough where it matters most. [...]
[...]
One of the major advances of D templates over C++ is its potent
combination with other D features like aliases/enums, static if,
compile-time introspection, and signature constraints. For example,
consider this:
// This template checks if T satisfies certain properties, like
// having a .NodeType type, parseAtom and parsePrimary methods,
// etc.
template isExprType(T) {
static if (is(T.NodeType)
is(isNodeType!(T.NodeType)
is(T.parseAtom(Lexer.init))
is(T.parsePrimary(Lexer.init)) ...)
{
enum isExprType = true;
}
else
enum isExprType = false;
}
// This template checks that T is a valid node type. That is,
// the previous template uses this one to enforce T.NodeType
// being a type that satisfies certain properties.
template isNodeType(T) {
static if (is(T.precedence : int))
enum isNodeType = true;
else
enum isNodeType = false;
}
// By using the above template as a signature constraint, we're
// free to make use of properties we assumed about T, such as
// parametrizing the return type on .NodeType as defined in T
T.NodeType parseExpr(T)(Lexer lex)
if (isExprType!T)
{
...
// Or calling functions we verified to exist in T
auto node1 = T.parseAtom(lex);
auto node2 = T.parseAtom(lex);
...
// Or using properties of T.NodeType that we verified
// exists, even though the template itself is
// independent of how T.NodeType is even defined by T!
if (node1.precedence node2.precedence)
...
}
This is a ducktyping system where any type that satisfies isExprType
will work with parseExpr. This isn't just C++'s conform to conventions
described in the missing accompanying documentation or get 10 pages of
template errors. This is *compile-time* verification that any type T
you instantiate parseExpr with, conforms to the requirements defined by
isExprType. And furthermore, even T.NodeType itself has been checked to
have certain properties -- such as a .precedence property that is
convertible to int (which means it can be an actual int field, or a
@property function that returns an int, or something that returns an
object convertible to int, etc.).
This allows you to implement an expression parser that is completely
independent of the concrete types of the expression being parsed. AND
this is done without requiring 100 template parameters that specify
every configurable parameter: you just specify them in the type used to
instantiate parseExpr.
Better yet, if you designed the isExprType template correctly, you can
even have a derived class of an expression node that stores a value, and
specifies parsing functions that computes the value on the expression
on-the-fly. So instantiating parseExpr with the base class gives you an
expression tree, and instantiating it with the derived class computes
the value of the expression at parse-time. In the latter case, even the
return type is the correct derived class so you don't even need to
down-cast a base class reference to get at the value. (I actually have
code that does this. You cannot imagine the sense of power when code
like this can be written _cleanly_, without bending over backwards and
running a 100-meter dash with your left leg tied to your neck.)
Now try doing this in C++. It is in all likelihood plain impossible, or
so extremely painful that it's not worth the suffering to implement.
T
--
Lottery: tax on the stupid. -- Slashdotter
Re: D seems interesting, but...
On Mon, Oct 15, 2012 at 07:51:59PM +0200, Gerry Weaver wrote: On Monday, 15 October 2012 at 17:36:10 UTC, Ali Çehreli wrote: [...] That is the most plausible reason so far: The OP has an empty file in the current directory but the hello.d that is being edited in Emacs is elsewhere. :) Ali Hi, I have been looking into this. I'm afraid it isn't that simple. I just created the file with vi in the same directory I was trying to compile it in. I can cat it etc., so I know the text is there. I have even reproduced the issue on a different partition etc.. I'm starting to think that some other package that is installed on this particular system may be the source of the problem. I can't reproduce the issue on another install of the same OS, version, etc.. I went ahead and installed the .deb package on the new system and it still works. [...] Yeah, it seems to be a very system-specific problem. I'd like to get to bottom of it if I could, as it piques my curiosity (plus it would be nice to prevent somebody else from running into the same problem in the future), but then I don't really want to waste your time hunting down an obscure problem if you already have a working dmd by some other means. T -- The computer is only a tool. Unfortunately, so is the user. -- Armaphine, K5
Re: D seems interesting, but...
On Monday, 15 October 2012 at 17:53:15 UTC, Andrei Alexandrescu
wrote:
On 10/15/12 1:37 PM, foobar wrote:
On Monday, 15 October 2012 at 15:22:38 UTC, Andrei
Alexandrescu wrote:
snip
Yes, this is a nice thing Java, .NET and Python have.
Wonder if a simple convention would suffice, e.g. every
module that
wanna defines a moduleMain(string[] args) and then you have
one module
main.d that has:
void main(string[] args) { import wuddever; moduleMain(args);
}
Andrei
Great idea! But why add another (redundant) level of
indirection?
It should go in the C main in druntime together with a
mechanism to call
the correct D main, by e.g. reading the module name from the
command line.
Well there's a tension here: good language design generally
aims at providing few general features applicable to many use
cases. Encoding particular use cases in the language is
warranted by either disproportionate frequency in use or
disproportionate difficulty in implementing them within the
language. I don't think this particular feature scores very
highly in either category.
Andrei
Well, it isn't so much in the language per se as it's (mostly?)
in druntime.
We _already_ have code in druntime that calls the user supplied
main function. All I'm suggesting is a very minor enhancement to
that mechanism which does add useful convenience.
Seems to me the usefulness of this greatly outweighs the
implementation cost.
Re: Import improvement
On Monday, 15 October 2012 at 15:37:06 UTC, Andrei Alexandrescu wrote: I don't think imports from a specific package have been considered. In my personal opinion, imports are a necessary evil and it's sort of a bummer that the most accessible place in any source file - the top lines - is occupied by the crappy legal disclaimer (which, after having talked to a lawyer, I always put at the bottom since being at the top is not a requirement), and the litany of imports that the module is using. I'd make all imports local or put them at the bottom of the file if it weren't too much of a shock to others. Three remarks on this particular problem. 1. I expect large packages to introduce a module all.di or _.di to publicly import everything in the package. That could help some use cases. It is a common practice (usually all.di) but perhaps it could help to establish an official convention. Nothing in the language, just the styleguide. (I know this has already come up and been discussed.) 2. The import declaration accepts a list of modules, and several may be on one line. I think that's a significant positive difference from C, C++, or Go, all of which force one imported module per line. I always advocate imports from the same package in the same import declaration, ordered alphabetically: import fuji.filesystem, fuji.font, fuji.material, fuji.matrix, fuji.primitive, fuji.render, fuji.system; import std.algorithm, std.conv, std.random, std.string, std.xml; ... That makes the existing system much more palatable. I've done this very thing for eons, and yes you are quite right! (Although my formatting is different, but I digress.) That said, I think the OP still has a valid, even quite strong point. Consider, in comparison to your sample: import fuji.( filesystem, font, material, matrix, primitive, render, system ); import std.( algorithm, conv, random, string, xml ); Certainly less visual noise. An even *better* level of improvement comes if we provide an alternate and similar syntax for selective imports, so that they no longer have to be separated. import std.( algorithm, conv, random, xml, stdio:( write, writef, writefln ), string:( munch, splitLines, xformat, xsformat ) ); As for implementation, how difficult is it for the compiler to internally expand something like this into the traditional litany? 3. I think local imports are currently underutilized. It would be interesting to see what kind of project dynamics they enable. I can agree with this. -- Chris Nicholson-Sauls
Re: D seems interesting, but...
On Monday, 15 October 2012 at 18:03:10 UTC, H. S. Teoh wrote: On Mon, Oct 15, 2012 at 07:51:59PM +0200, Gerry Weaver wrote: On Monday, 15 October 2012 at 17:36:10 UTC, Ali Çehreli wrote: [...] That is the most plausible reason so far: The OP has an empty file in the current directory but the hello.d that is being edited in Emacs is elsewhere. :) Ali Hi, I have been looking into this. I'm afraid it isn't that simple. I just created the file with vi in the same directory I was trying to compile it in. I can cat it etc., so I know the text is there. I have even reproduced the issue on a different partition etc.. I'm starting to think that some other package that is installed on this particular system may be the source of the problem. I can't reproduce the issue on another install of the same OS, version, etc.. I went ahead and installed the .deb package on the new system and it still works. [...] Yeah, it seems to be a very system-specific problem. I'd like to get to bottom of it if I could, as it piques my curiosity (plus it would be nice to prevent somebody else from running into the same problem in the future), but then I don't really want to waste your time hunting down an obscure problem if you already have a working dmd by some other means. T Hi, It just occurred to me that I've seen this type of file issue before. If memory serves, it was related to the attempt to load a 64bit lib on a 32bit system. It was an odd problem, because it didn't fail in the way one would expect. The process in that case was reading garbage from memory. I don't get how it could be reading nothing though. Anyway, I'm going to look into this possibility. I found some notes that I made during that time and it does have a similar feel to it. I'll let y'all know what I find. Thanks, -G
