Re: My first experience as a D Newbie

[Peter R via Digitalmars-d]

Replying to a couple of the comments here

"I don't know if it's a different expectation or a different 
mindset or something else."
I'd like to think I'm fairly knowledgeable, but Yes, I expect 
installing/configuring to be easy and quick, so I can get to the 
actual programming. I expect solid debugging capabilities, full 
IDE support, autocomplete, and 64-bit windows libraries. It is 
just some of the things that I am used to with Visual C++. 
"Better than C++" is my motivation to evaluate D, and to me that 
goes beyond just the language and standard library.
If I, as a new user, don't have a solid first impression, I'd 
have no expectation that the rest of the D ecosystem is polished, 
and I would return to C++


"even when we do have IDE support (e.g. VisualD), it never seems 
to be enough for some folks."
I tried VisualD, but the fact that it didn't use dub underneath 
made me think "that's not the way people are supposed to use D". 
That is why I started the VSCode path- that felt more in the 
spirit of the D ecosystem.


I admit I didn't consider evaluating DLangIDE earlier. I am used 
to Visual Studio, so that was my first choice. If I have to learn 
a second editor I want one that is known to work with many 
languages and lots of plugin support, so I picked VS Code.

My first experience as a D Newbie

[Peter R via Digitalmars-d]

I've recently started evaluating D, and I thought as a D newbie 
(but 20 year game dev veteran) I should share the things I felt 
were missing or unclear, so you can decide if you want to do 
something to cater new users. So my first notes are


1. Reading about D online: There is a decent amount of 
information seems old, and it's hard to tell for newbies that D1 
and D2 are different. Andrei's book seems like it is still the 
best reference for the actual language, but since it is 7 years 
old, as a newbie I expected it to be out of date. Maybe a 2nd 
edition?
2. Set up the dev environment: While the language is solid, and 
the base DMD install and "hello world" are easy to get going, 
getting a full IDE configured is a lot more work. I would really 
like a comprehensive guide to go from there to having a full 
environment set up in for example VS Code. I've spent weeks 
trying to get VS Code configured, and still haven't gotten 
debugging to work. An idiot-proof step by step guide would be 
nice, maybe like this "step 1 install VS Code from this link, DMD 
from this link, Dub from this link, step 2 install these 5 
extensions in VS Code, step 3 make these manual changes to the 
configuration, step 4 download this sample project and open it, 
step 5 here are the 5 important commands you need to build and 
run". If there was a 15-minute guide, it would be much easier to 
get to the parts that matter.
3. Setting up the dev env,take 2: Visual-D seems a lot easier to 
configure, and it had functional samples. However, it was strange 
that it doesn't use dub files directly and instead needs them 
converted to visual studio build projects. I would prefer if it 
the msbuild projects would just directly call Dub, as Dub seems 
like the gold standard. My first attempt at generating a solution 
from a dub project failed, so it feels maybe a bit unfinished. It 
would also be great if Visual-D had a few more detailed templates 
built in, maybe a Derelict SDL window, for example.
4. it took a while to see that the DMD builds come with x86 
windows libraries, but no x64 windows libraries. That seems 
strange in this day and age


I'm still very new on the actual language, but thought it better 
that I share this while it is still fresh.

Re: [WORK] std.file.update function

[R via Digitalmars-d]

On Monday, 19 September 2016 at 02:57:01 UTC, Chris Wright wrote:

You have an operating system that automatically checksums every 
file?


There are a few filesystems that keep checksums of blocks, but I 
don't see one that keeps file checksums.

Re: iPhone vs Android

[R via Digitalmars-d]

On Monday, 12 September 2016 at 22:57:23 UTC, Andrei Alexandrescu 
wrote:
[snip] If it is, that provides more impetus for reference 
counting for D by the following logic: (a) it is likely that in 
the future more code will run on portable, battery-powered 
systems; (b) battery power does not follow a Moore trajectory, 
so at this point in history demand for battery lifetime is 
elastic.



Andrei


I'm keen on reference counting because of embedded and bare-metal 
programming so I'm super keen on D having a short reference long 
garbage standard. I guess we already do this to some extent with 
scope etc.


Battery life can last for years in some of the new embedded 
devices but most languages targeting the M0 etc are really 
archaic, I have seen a rust port somewhere... but if I'm honest I 
only really care for D so I really want LDC -> ARM M0 etc... :D

Re: Promotion rules ... why no float?

[R via Digitalmars-d]

On Tuesday, 6 September 2016 at 15:00:48 UTC, Sai wrote:

Thanks for the replies.

I tend to use a lot of float math (robotics and automation) so 
I almost always want float output in case of division. And once 
in a while I bump into this issue.


I am wondering what are the best ways to work around it.

float c = a / b; // a and b could be integers.

Some solutions:

float c = cast!float(a) / b;
float c = 1f * a / b;


Any less verbose ways to do it?

Another solution I am thinking is to write a user defined 
integer type with an overloaded division to return a float 
instead and use it everywhere in place of integers. I am 
curious how this will work out.


http://code.dlang.org/packages/fixed ?

Re: associative arrays: how to insert key and return pointer in 1 step to avoid searching twice

[R via Digitalmars-d]

On Tuesday, 6 September 2016 at 04:32:52 UTC, Daniel Kozak wrote:

Dne 6.9.2016 v 06:14 mogu via Digitalmars-d napsal(a):

On Tuesday, 6 September 2016 at 01:17:00 UTC, Timothee Cour 
wrote:

is there a way to do this efficiently with associative arrays:

aa[key]=value;
auto ptr=key in aa;

without suffering the cost of the 2nd search (compiler should 
know ptr during aa[key]=value but it's not exposed it seems)


auto pa = &(aa[key] = value);


Yep, but this is a implementation detail, so be careful


:D then make a pull-request to the D test suite...

Bham! Its in the spec if its merged.

Question about version ( ) keyword

[Vincent R via Digitalmars-d]

Hi,

When looking at core definitions like core.sys.posix.pthread I 
can see some "duplicated" code because it seems version doesn't 
support Or as we would do in C/C++ with #ifdefined.

For instance if can read this:

version( CRuntime_Glibc )
{
enum PTHREAD_BARRIER_SERIAL_THREAD = -1;

int pthread_barrier_destroy(pthread_barrier_t*);
int pthread_barrier_init(pthread_barrier_t*, in 
pthread_barrierattr_t*, uint);

int pthread_barrier_wait(pthread_barrier_t*);
int pthread_barrierattr_destroy(pthread_barrierattr_t*);
int pthread_barrierattr_getpshared(in pthread_barrierattr_t*, 
int*);

int pthread_barrierattr_init(pthread_barrierattr_t*);
int pthread_barrierattr_setpshared(pthread_barrierattr_t*, 
int);

}
else version( FreeBSD )
{
enum PTHREAD_BARRIER_SERIAL_THREAD = -1;

int pthread_barrier_destroy(pthread_barrier_t*);
int pthread_barrier_init(pthread_barrier_t*, in 
pthread_barrierattr_t*, uint);

int pthread_barrier_wait(pthread_barrier_t*);
int pthread_barrierattr_destroy(pthread_barrierattr_t*);
int pthread_barrierattr_getpshared(in pthread_barrierattr_t*, 
int*);

int pthread_barrierattr_init(pthread_barrierattr_t*);
int pthread_barrierattr_setpshared(pthread_barrierattr_t*, 
int);

}
else version (OSX)
{
}
else version (Solaris)
{
enum PTHREAD_BARRIER_SERIAL_THREAD = -2;

int pthread_barrier_destroy(pthread_barrier_t*);
int pthread_barrier_init(pthread_barrier_t*, in 
pthread_barrierattr_t*, uint);

int pthread_barrier_wait(pthread_barrier_t*);
int pthread_barrierattr_destroy(pthread_barrierattr_t*);
int pthread_barrierattr_getpshared(in pthread_barrierattr_t*, 
int*);

int pthread_barrierattr_init(pthread_barrierattr_t*);
int pthread_barrierattr_setpshared(pthread_barrierattr_t*, 
int);

}
else version (CRuntime_Bionic)
{
}
else
{
static assert(false, "Unsupported platform");
}

When I see this code I cannot help thinking of something like:

version( CRuntime_Glibc ) || version( FreeBSD ) || version 
(Solaris)

{
if(version(Solaris))
   enum PTHREAD_BARRIER_SERIAL_THREAD = -2;
else
   enum PTHREAD_BARRIER_SERIAL_THREAD = -1;

int pthread_barrier_destroy(pthread_barrier_t*);
int pthread_barrier_init(pthread_barrier_t*, in 
pthread_barrierattr_t*, uint);

int pthread_barrier_wait(pthread_barrier_t*);
int pthread_barrierattr_destroy(pthread_barrierattr_t*);
int pthread_barrierattr_getpshared(in pthread_barrierattr_t*, 
int*);

int pthread_barrierattr_init(pthread_barrierattr_t*);
int pthread_barrierattr_setpshared(pthread_barrierattr_t*, 
int);

}
else version (OSX) ||version (CRuntime_Bionic)
{
}
else
{
static assert(false, "Unsupported platform");
}

I suppose language creators had good reasons to not allow it but 
I am a bit disapointed by the aspect of this language because 
some files are really verbose.
However I understand that this limitation allow a clear 
separation between different platforms...

Re: How can I report what I think a compiler's frontend bug

[Vincent R via Digitalmars-d]

On Monday, 21 March 2016 at 11:00:08 UTC, Vincent R wrote:

On Monday, 21 March 2016 at 09:46:18 UTC, Vincent R wrote:

On Monday, 21 March 2016 at 01:51:09 UTC, Marco Leise wrote:

Am Sun, 20 Mar 2016 22:37:37 +
schrieb Vincent R :

[...]


Thanks and you see I was right to post here since I finally 
found the problem and got an answer :-)


Unfortunately at the end I get a linker error:

1000@MLVD0032 MINGW64 ~/tmp/wxd/src/Samples
$ make
del *.cached
cd Controls
make
dmd -c -version=wx28 -version=__WXMSW__ -version=ANSI -I..\.. 
Controls.d
..\..\wx\common.d(153): Deprecation: function 
wx.common.new_Rectangle is deprecated
..\..\wx\common.d(153): Deprecation: function 
wx.common.new_Rectangle is deprecated


dmd -g -of..\..\bin\Controls.exe Controls.obj ..\..\wxd.lib 
..\..\wxc.lib 
C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxbase28d.lib  C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxbase28d_xml.lib  C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxmsw28d_core.lib  C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxmsw28d_adv.lib  C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxmsw28d_html.lib  C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxmsw28d_xrc.lib  C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxtiffd.lib  C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxjpegd.lib  C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxpngd.lib  C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxzlibd.lib  C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxregexd.lib  C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxexpatd.lib   kernel32.lib user32.lib gdi32.lib comdlg32.lib winspool.lib winmm.l!

ib shell32.lib comctl32.lib ole32.lib oleaut32.lib uuid.lib rpcrt4.lib 
advapi32.lib wsock32.lib odbc32.lib-L/EXETYPE:NT -L/SU:WINDOWS:4.0

OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
C:\DEV\msys64\home\1000\tmp\wxWidgets-2.8.12\lib\dmc_lib\wxexpatd.lib(xmlrole)
 Error 168: >64K Global Types


I tried with a gdc compiler compiled by myself and I was able to 
compile and launch my first sample application using 
wxWidgets-2.8.
Now I have some work to do to fix all the remaining warnings and 
errors but I hope that wxD will be very soon an alternative to 
existing gui framework for D.
In a perfect world I should also work on the D libraries to add 
support for mingwXX winpthreads because for the moment the gdc 
compiler is generated using --enable-threads=win32. As long as it 
cannot use posix thread it cannot be an official package of 
msys2/mingw64.

Re: How can I report what I think a compiler's frontend bug

[Vincent R via Digitalmars-d]

On Monday, 21 March 2016 at 09:46:18 UTC, Vincent R wrote:

On Monday, 21 March 2016 at 01:51:09 UTC, Marco Leise wrote:

Am Sun, 20 Mar 2016 22:37:37 +
schrieb Vincent R :

[...]


Thanks and you see I was right to post here since I finally 
found the problem and got an answer :-)


Unfortunately at the end I get a linker error:

1000@MLVD0032 MINGW64 ~/tmp/wxd/src/Samples
$ make
del *.cached
cd Controls
make
dmd -c -version=wx28 -version=__WXMSW__ -version=ANSI -I..\.. 
Controls.d
..\..\wx\common.d(153): Deprecation: function 
wx.common.new_Rectangle is deprecated
..\..\wx\common.d(153): Deprecation: function 
wx.common.new_Rectangle is deprecated


dmd -g -of..\..\bin\Controls.exe Controls.obj ..\..\wxd.lib 
..\..\wxc.lib 
C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxbase28d.lib  C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxbase28d_xml.lib  C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxmsw28d_core.lib  C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxmsw28d_adv.lib  C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxmsw28d_html.lib  C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxmsw28d_xrc.lib  C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxtiffd.lib  C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxjpegd.lib  C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxpngd.lib  C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxzlibd.lib  C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxregexd.lib  C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxexpatd.lib   kernel32.lib user32.lib gdi32.lib comdlg32.lib winspool.lib winmm.lib!

 shell32.lib comctl32.lib ole32.lib oleaut32.lib uuid.lib rpcrt4.lib 
advapi32.lib wsock32.lib odbc32.lib-L/EXETYPE:NT -L/SU:WINDOWS:4.0
OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
C:\DEV\msys64\home\1000\tmp\wxWidgets-2.8.12\lib\dmc_lib\wxexpatd.lib(xmlrole)
 Error 168: >64K Global Types

Re: How can I report what I think a compiler's frontend bug

[Vincent R via Digitalmars-d]

On Monday, 21 March 2016 at 01:51:09 UTC, Marco Leise wrote:

Am Sun, 20 Mar 2016 22:37:37 +
schrieb Vincent R :

[...]


Thanks and you see I was right to post here since I finally found 
the problem and got an answer :-)

Re: How can I report what I think a compiler's frontend bug

[Vincent R via Digitalmars-d]

On Sunday, 20 March 2016 at 19:06:32 UTC, Johan Engelen wrote:

On Sunday, 20 March 2016 at 17:57:12 UTC, Vincent R wrote:

On Sunday, 20 March 2016 at 16:16:18 UTC, Marco Leise wrote:

Am Sun, 20 Mar 2016 11:28:19 +
schrieb Vincent R :


Hi,

I would like to start a new project (a bonjour/zeroconf 
wrapper

and a gui browser using it).
For the gui part I would like to use my existing skills using
wxWidgets wrapper (wxD).
So I have started to report a problem a few months ago:
https://forum.dlang.org/post/rtarlodeojnmedgsn...@forum.dlang.org

But so far(DMD32 D Compiler v2.070.2) it's still not fixed.
Do you think it will be fixed one day ?

Thanks


Yes, I think it will be fixed one day, since - as you know
by reading the very thread you linked - it is already reported
and the GDC developers chimed in and considered it critical.
There are also 118 open critical/blocker bugs that were
reported before yours. Most of them by people here on the
forums and you would need to explain to us why your bug
deserves higher attention than the others (154 in total).

Dlang is free open-source software and there is only a hand 
full of people who are fixing bugs in the compiler just for 
the sake of improving it. Most people contribute occasionally 
when they are interested in a solution to a particular 
problem.


If you really need this fixed now ... you know the drill. I 
suggest you analyze the problem and start a discussion about 
it. Honestly asking why the compiler emits duplicate symbols 
in a reduced test case might have yielded you some good 
responses from the people who wrote the code.


Ok first maybe it's already reported to GDC but to me it's not 
only a gdc bug since it also happens with dmd. So I don't know 
how bugs are fixed in the differents compilers but I suppose 
they share the same frontend (maybe I am mistaken) and in this 
case I prefer not to wait for gdc developers to fix it but to 
see if for instance some dmd developers have some time to fix 
it.
I just want to use the language and don't have time to dig 
inside its inner workings, so I think D is not for me. This 
project was the opportunity to learn the language by fixing an 
unmaintained library (wxD) but it's not as easy as I thought.


What may speed-up bug fixing a lot is preparing a nice testcase 
that is *as small as possible*.
As you can see in the bug report [1], there is already a 
testcase. It is a good start, but it is not very minimal: 
contains a lot of comments etc. That is a lot of distraction / 
bother (for me at least). One way to help here is to minimize 
it further, and distill it down to the essential thing that 
appears to trigger the bug. You can do that without knowing any 
compiler internals.
It can be very time consuming to make such a testcase, which 
may discourage developers fixing of your bug.


[1] https://issues.dlang.org/show_bug.cgi?id=15324


Ok I think I have found the problem, here is the testcase:

alias TreeItemId wxTreeItemId;
public class TreeItemId : wxObject
{
public this(IntPtr wxobj)
{
super(wxobj);
}

private this(IntPtr wxobj, bool memOwn)
{
super(wxobj);
this.memOwn = memOwn;
}

public this()
{
this(wxTreeItemId_ctor(), true);
}

public this(void* pItem)
{
this(wxTreeItemId_ctor2(pItem), true);
}

override protected void dtor() { wxTreeItemId_dtor(wxobj); }
}

The problem is I think between public this(void* pItem) and 
public this(IntPtr wxobj)

because from what I understand they are the same.
If I comment one of the two constructors it seems to remove the 
warning about duplicated symbols. Now I need to understand what 
the original author wanted to do by declaring these 2 
constructors.

Re: How can I report what I think a compiler's frontend bug

[Vincent R via Digitalmars-d]

On Sunday, 20 March 2016 at 16:16:18 UTC, Marco Leise wrote:

Am Sun, 20 Mar 2016 11:28:19 +
schrieb Vincent R :


Hi,

I would like to start a new project (a bonjour/zeroconf wrapper
and a gui browser using it).
For the gui part I would like to use my existing skills using
wxWidgets wrapper (wxD).
So I have started to report a problem a few months ago:
https://forum.dlang.org/post/rtarlodeojnmedgsn...@forum.dlang.org

But so far(DMD32 D Compiler v2.070.2) it's still not fixed.
Do you think it will be fixed one day ?

Thanks


Yes, I think it will be fixed one day, since - as you know
by reading the very thread you linked - it is already reported
and the GDC developers chimed in and considered it critical.
There are also 118 open critical/blocker bugs that were
reported before yours. Most of them by people here on the
forums and you would need to explain to us why your bug
deserves higher attention than the others (154 in total).

Dlang is free open-source software and there is only a hand 
full of people who are fixing bugs in the compiler just for the 
sake of improving it. Most people contribute occasionally when 
they are interested in a solution to a particular problem.


If you really need this fixed now ... you know the drill. I 
suggest you analyze the problem and start a discussion about 
it. Honestly asking why the compiler emits duplicate symbols in 
a reduced test case might have yielded you some good responses 
from the people who wrote the code.


Ok first maybe it's already reported to GDC but to me it's not 
only a gdc bug since it also happens with dmd. So I don't know 
how bugs are fixed in the differents compilers but I suppose they 
share the same frontend (maybe I am mistaken) and in this case I 
prefer not to wait for gdc developers to fix it but to see if for 
instance some dmd developers have some time to fix it.
I just want to use the language and don't have time to dig inside 
its inner workings, so I think D is not for me. This project was 
the opportunity to learn the language by fixing an unmaintained 
library (wxD) but it's not as easy as I thought.



Cheers

How can I report what I think a compiler's frontend bug

[Vincent R via Digitalmars-d]

Hi,

I would like to start a new project (a bonjour/zeroconf wrapper 
and a gui browser using it).
For the gui part I would like to use my existing skills using 
wxWidgets wrapper (wxD).

So I have started to report a problem a few months ago:
https://forum.dlang.org/post/rtarlodeojnmedgsn...@forum.dlang.org

But so far(DMD32 D Compiler v2.070.2) it's still not fixed.
Do you think it will be fixed one day ?

Thanks

Re: Linker error with dmd when trying to generate wxWidgets wrapper on Windows (msys2/mingw-w64)

[Vincent R via Digitalmars-d]

On Tuesday, 1 December 2015 at 16:46:21 UTC, Vincent R wrote:

On Tuesday, 1 December 2015 at 10:21:11 UTC, Luis wrote:

On Monday, 30 November 2015 at 09:23:33 UTC, Vincent R wrote:

On Friday, 27 November 2015 at 09:56:10 UTC, Kagamin wrote:
The bug report is 
https://issues.dlang.org/show_bug.cgi?id=15324


Just hope it will be fixed soon because I gave up D 7 years 
ago (too many bugs, war between phobos, tango, very young 
language) and now I realize it still very complicated to use 
it (at least on windows).


Yeah, on Linux simply just works. On Windows, there is more 
issues...


Not even sure it works on linux because on the bug report 
above, platform is linux...


Do we know when it will be fixed because I would like to keep on 
progressing on my project and if it takes too much time I will 
use another language (go language is my next candidate) ?

Re: Linker error with dmd when trying to generate wxWidgets wrapper on Windows (msys2/mingw-w64)

[Vincent R via Digitalmars-d]

On Tuesday, 1 December 2015 at 10:21:11 UTC, Luis wrote:

On Monday, 30 November 2015 at 09:23:33 UTC, Vincent R wrote:

On Friday, 27 November 2015 at 09:56:10 UTC, Kagamin wrote:
The bug report is 
https://issues.dlang.org/show_bug.cgi?id=15324


Just hope it will be fixed soon because I gave up D 7 years 
ago (too many bugs, war between phobos, tango, very young 
language) and now I realize it still very complicated to use 
it (at least on windows).


Yeah, on Linux simply just works. On Windows, there is more 
issues...


Not even sure it works on linux because on the bug report above, 
platform is linux...

Re: Linker error with dmd when trying to generate wxWidgets wrapper on Windows (msys2/mingw-w64)

[Vincent R via Digitalmars-d]

On Friday, 27 November 2015 at 09:56:10 UTC, Kagamin wrote:

The bug report is https://issues.dlang.org/show_bug.cgi?id=15324


Just hope it will be fixed soon because I gave up D 7 years ago 
(too many bugs, war between phobos, tango, very young language) 
and now I realize it still very complicated to use it (at least 
on windows).

Linker error with dmd when trying to generate wxWidgets wrapper on Windows (msys2/mingw-w64)

[Vincent R via Digitalmars-d]

Hi,

I have a problem to generate D wrapper for wxWidgets (wxD) on 
msys2/mingw64.

Here is how to reproduce it:

1) Install msys2 from here http://msys2.github.io/

2) Launch msys2 terminal and add dmc/dmd to PATH

$ mkdir tmp && cd tmp
$ export 
PATH="C:\Developer\D\dm\bin":"C:\Developer\D\dmd2\windows\bin":$PATH
$ wget 
https://github.com/wxWidgets/wxWidgets/releases/download/v2.8.12/wxWidgets-2.8.12.tar.gz

$ cd wxWidgets-2.8.12/build/msw
$ make -f makefile.dmc
$ export WXDIR=/home/Vincent/tmp/wxWidgets-2.8.12
$ cd ~/tmp
$ git clone https://github.com/vrichomme/wxd.git
$ cd wxd/src
$ make
...
Warning: Public 
'_D2wx8TreeCtrl10TreeItemId6__ctorMFPvZC2wx8TreeCtrl10TreeItemId' 
already in library, redefinition ignored.


Then when I try to generate some samples I have an error about 
the same symbol:


$ cd Samples/

dmd -c -version=wx28 -version=__WXMSW__ -version=ANSI -I..\.. 
Font.d
Font.d(15): Deprecation: module std.stream is deprecated - It 
will be removed from Phobos in October 2016. If you still need 
it, go to https://github.com/DigitalMars/undeaD
..\..\wx\common.d(151): Deprecation: function 
wx.common.new_Rectangle is deprecated
..\..\wx\common.d(151): Deprecation: function 
wx.common.new_Rectangle is deprecated
Font.d(667): Deprecation: implicitly overriding base class method 
wx.FontMisc.FontEnumerator.Facenames with 
Font.MyFontEnumerator.Facenames deprecated; add 'override' 
attribute


dmd -g -of..\..\bin\Font.exe Font.obj ..\..\wxd.lib ..\..\wxc.lib 
C:/Developer/msys64/home/Vincent/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxbase28d.lib  C:/Developer/msys64/home/Vincent/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxbase28d_xml.lib  C:/Developer/msys64/home/Vincent/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxmsw28d_core.lib  C:/Developer/msys64/home/Vincent/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxmsw28d_adv.lib  C:/Developer/msys64/home/Vincent/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxmsw28d_html.lib  C:/Developer/msys64/home/Vincent/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxmsw28d_xrc.lib  C:/Developer/msys64/home/Vincent/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxtiffd.lib  C:/Developer/msys64/home/Vincent/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxjpegd.lib  C:/Developer/msys64/home/Vincent/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxpngd.lib  C:/Developer/msys64/home/Vincent/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxzlibd.lib  C:/Developer/msys64/home/Vincent/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxregexd.lib  C:/Developer/msys64/home/Vincent/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxexpatd.lib   kernel32.!

lib user32.lib gdi32.lib comdlg32.lib winspool.lib winmm.lib shell32.lib 
comctl32.lib ole32.lib oleaut32.lib uuid.lib rpcrt4.lib advapi32.lib 
wsock32.lib odbc32.lib-L/EXETYPE:NT -L/SU:WINDOWS:4.0
OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
..\..\wxd.lib(TreeCtrl)  Offset B471FH Record Type 00C3
 Error 1: Previous Definition Different : 
_D2wx8TreeCtrl10TreeItemId6__ctorMFPvZC2wx8TreeCtrl10TreeItemId

C:\Developer\msys64\home\Vincent\tmp\wxWidgets-2.8.12\lib\dmc_lib\wxbase28d.lib(dircmn)
 Error 168: >64K Global Types


So I don't know if the bug is inside the wrapper or the 
compiler/linker.

I should add that I have the same issue with gdc.

Need someone to look at it.

Thanks

Re: Generate wxD with dmc/dmd

[Vincent R via Digitalmars-d]

On Saturday, 7 November 2015 at 22:12:55 UTC, Vincent R wrote:

Hi,

I am trying to generate the wxWidgets wrapper wxD on Windows 
through msys/mingw64(or cygwin).
So I have downloaded wxWidgets-2.8.12 and dmd c++/d compiler 
respectively dmc/dmd but I still have an error.

Let's consider we are using cygwin:

[...]


Actually I found my problem you can ignore my previous message.

Generate wxD with dmc/dmd

[Vincent R via Digitalmars-d]

Hi,

I am trying to generate the wxWidgets wrapper wxD on Windows 
through msys/mingw64(or cygwin).
So I have downloaded wxWidgets-2.8.12 and dmd c++/d compiler 
respectively dmc/dmd but I still have an error.

Let's consider we are using cygwin:

$ export 
PATH="C:\Developer\D\dm\bin":"C:\Developer\D\dmd2\windows\bin":$PATH

$ cd ~
$ unzip wxWidgets-2.8.12.zip
$ cd wxWidgets-2.8.12/include/wx
$ cp setup_inc.h setup.h
$ export 
WXDIR="C:\Developer\cygwin64\home\Vincent\projects\dlang\wxWidgets-2.8.12"


$ cd ~
$ git clone https://github.com/afb/wxd.git
$ cd wxD
$ make

cd wxc
make
dmc -D__DMD__ -mn -g -o+none -D -D__WXDEBUG__  
-IC:\Developer\cygwin64\home\Vincent\projects\dlang\wxWidgets-2.8.12\include  -IC:\Developer\cygwin64\home\Vincent\projects\dlang\wxWidgets-2.8.12\lib\dmc_lib\mswd -w- -I. -WA -DNOPCH -HP90 -Ar -Ae   -HP99 -c -owx-release.obj wx-release.cpp
Error 
C:\Developer\cygwin64\home\Vincent\projects\dlang\wxWidgets-2.8.12\include\wx/chkconf.h 1817:  "wxClipboard requires wxDataObject"

--- errorlevel 1

the file to be compiled wx-release.cpp has the following lines:

#include 
#include "wx/defs.h"

#if defined(__APPLE__) && !(wxCHECK_VERSION(2,6,1)) // will be 
2.6.4 eventually

/* don't support the broken 2.5.3, in Mac OS X 10.4 */
#error "unsupported wxWidgets version, please upgrade"
#endif

int main(int argc, char *argv[])
{
if (argc > 1 && argv[1][0] == '-' && argv[1][1] == 'v')
printf("WX_RELEASE_NODOT = ");
printf("%d%d\n", wxMAJOR_VERSION, wxMINOR_VERSION);
return 0;
}


When I look at chkconf.h 1817:

#if wxUSE_CLIPBOARD && !wxUSE_DATAOBJ
#   ifdef wxABORT_ON_CONFIG_ERROR
#   error "wxClipboard requires wxDataObject"
#   else
#   undef wxUSE_DATAOBJ
#   define wxUSE_DATAOBJ 1
#   endif
#endif /* wxUSE_CLIPBOARD */

BUT inside the setup.h I am sure that wxUSE_CLIPBOARD and 
wxUSE_DATAOBJ are true...


When we look at source code we can see that wx/defs.h is included 
and it's this file that includes wx/setup.h but the compiler 
doesn't seem to see it...


But I have also found something weird, if I put some garbage text 
just before include  the compiler is not happy:


$ make
cd wxc
make
dmc -D__DMD__ -mn -g -o+none -D -D__WXDEBUG__  
-IC:\Developer\cygwin64\home\Vincent\projects\dlang\wxWidgets-2.8.12\include  -IC:\Developer\cygwin64\home\Vincent\projects\dlang\wxWidgets-2.8.12\lib\dmc_lib\mswd -w- -I. -WA -DNOPCH -HP90 -Ar -Ae   -HP99 -c -owx-release.obj wx-release.cpp

extern "C" {
 ^
C:\Developer\D\dm\bin\..\include\stdio.h(10) : Error: missing 
decl-specifier-seq for declaration of 'ss'

size_t  __CLIB fread(void *,size_t,size_t,FILE *);


but if I put the same letters just after , compiler 
doesn't give an error about unrecognized tokens !!!


#include 
ss

$ make
cd wxc
make
dmc -D__DMD__ -mn -g -o+none -D -D__WXDEBUG__  
-IC:\Developer\cygwin64\home\Vincent\projects\dlang\wxWidgets-2.8.12\include  -IC:\Developer\cygwin64\home\Vincent\projects\dlang\wxWidgets-2.8.12\lib\dmc_lib\mswd -w- -I. -WA -DNOPCH -HP90 -Ar -Ae   -HP99 -c -owx-release.obj wx-release.cpp
Error 
C:\Developer\cygwin64\home\Vincent\projects\dlang\wxWidgets-2.8.12\include\wx/chkconf.h 1817:  "wxClipboard requires wxDataObject"

--- errorlevel 1

Re: Proper C Pointer Binding

[R]

void main() {

  // init screen and OpenGL setup

  auto font = loadFont(cast (char * ) "Arial.TTF");

  scope (exit) destroyFont(font);

  // draw some text

  // close OpenGL and SDL with some second delay
}


Also I am not sure about the string casting to char * here.
I have been told that literals are 0 terminated, but strings
usually are not. Should I in your opinion create a wrapping
function in D that does convert the string to a proper
char * value? And how would I do that?

Thanks in advance for all the help!
Róbert László Páli

Re: D vs Go in real life, part 2. Also, Erlang.

[Jeff R. Allen]

I am the buddy who's always going on and on about Go.

Here's the blog posting I made explaining why/how I made the MQTT 
server in Go and what I learned:


  http://blog.nella.org/mqtt-code-golf/

I was a bit surprised and interested to see that MQTT with small 
transactions is not easy to optimize because kernel/user context 
switching dominates the work that's done under control of the 
programmer and which can be optimized via data structures and/or 
reducing GC overhead.


Something that both Atila and I verified in this exercise is that 
writing a fast network server that scales is so much easier with 
a very good networking library that takes advantage of 
lightweight threads, and with a runtime that provides GC. This 
frees up the programmer to focus on the protocol logic, and leave 
concurrency and bookkeeping in the capable hands of the machine.


And, as has been mentioned on other Go versus D threads, a lot of 
this is a matter of taste and team dynamics. I've worked on many 
teams in my career where there was not a critical mass of people 
who could reason correctly about C++ memory management, and who 
could use generic programming techniques reliably. And, in line 
with discoveries from psychological research, it's common that 
people who are not competent at something do not recognize that 
fact. Perhaps I'm above average in this regard: I KNOW I'm not 
smart enough to write correct code using templating techniques. :)


  -jeff

Re: Fragile ABI

[R Grocott]

On Monday, 20 August 2012 at 15:26:48 UTC, Kagamin wrote:
What you ask for sounds quite similar to COM composition with 
delegation.


Would anybody mind linking to resources which describe COM 
composition with delegation? It's been suggested twice in this 
thread as an alternative way to develop a non-fragile API, but 
anything related to COM is almost invisible to search engines 
(even moreso than D itself).

Re: Fragile ABI

[R Grocott]

On Saturday, 18 August 2012 at 17:55:22 UTC, Michel Fortin wrote:
As for structs, you could do it the same way, but I don't think 
you'd get enough benefit to compensate the drawback in 
performance and elsewhere. To truly have non-fragile structs 
you'd need to disable almost all compile-time introspection 
too. That would be very disruptive.


So I don't think it makes sense to have non-fragile structs.


Can't D allocate classes on the stack, in some circumstances? 
Would this lead to the same problems that you just described, or 
is the problem caused by how structs and classes are used, rather 
than how they're implemented?



By the way, did you take a look at the benchmarks?



Those are some pretty interesting numbers - seems as though the 
overhead is only about 10% - 20% over that of a regular vtable 
dispatch? I would have guessed that it would almost double the 
overhead, but I suppose that most of the overhead of a function 
call comes from saving registers, managing the stack, etc.


The overhead is so small, in fact, that I'd feel quite 
comfortable using it in a very performance-sensitive situation 
(like, say, a rasterizer library), presuming that your benchmarks 
were accurate. Another strong argument in favour of trying to 
have this system implemented :)

Re: Fragile ABI

[R Grocott]

Hey Michel, posted this question earlier in the thread, but I 
think you might have missed it:


The blog post I linked only talks about rewriting vtables at 
dynamic-link-time. Would it be possible to implement something 
similar for the sizes of structs and scope-classes, and the 
relative address of member variables? dsimcha's post has led me 
to realize that without these additional features, the ABI 
would still be quite fragile.


Long story short: Could your proposal realistically be extended 
to support flexible sizeofs and member-variable offsets? I figure 
that such a system might as well stabilize the entire class ABI, 
rather than just vtables.


I would guess that flexible sizeofs would increase the runtime 
cost only very slightly, but flexible member-variables might be 
more of an issue. The cost could be minimized by looking up 
offsets only when crossing a library boundary (say, when calling 
a template method on an extern (D_FlexibleABI) class, or 
accessing a protected member variable of same), but would that 
actually be possible?

Re: Fragile ABI

[R Grocott]

On Friday, 17 August 2012 at 13:42:27 UTC, Michel Fortin wrote:
It's certainly doable if you put it at the right place. But 
druntime is not the one in charge of dynamic linking: the 
dynamic linker from the OS is, so that's the ideal place to do 
such a thing. If you want to do it in druntime it'll be a huge 
hassle, if doable at all it'll probably break easily. But on 
the OS side you hit a rock because of different approach to 
dynamic linking (Windows does not really have a dynamic linker).


So basically, any system to create a more sensible ABI needs to 
built on top of the C ABI, name mangling, editable vtables, and 
nothing else? Ouch.


If druntime can't detect whether symbols were dynamically or 
statically linked, does that mean that your system would add an 
overhead to *all* virtual function calls, not just those which 
call into a dynamic library? If so, that'd be a pretty strong 
argument against implementing anything like it, unless it's 
something which has to be explicitly switched on (using, say, an 
"extern(D_FlexibleABI)" statement).

Re: Fragile ABI

[R Grocott]

Paulo -

Surely there are ways to work around the OS's native ABI, though, 
even from within compiled code?


Rewriting object vtables (etc.) might be a bit more involved than 
simple name mangling, but I'm almost certain it would be possible 
to implement it as part of druntime. The blog post which I linked 
describes one way to go about it.


Michael -

As far as I can tell, most of the performance cost in your idea 
comes from the additional level of indirection, since you store 
vtable offsets in a global variable which must be read before 
each function call.


This might just be wishful thinking, but would it be possible for 
druntime to write new vtable offsets directly into the program's 
machine code, at dynamic-link time? That would remove all of the 
run-time performance overhead, but, as I say, I'm not sure 
whether it's actually possible.


I think the biggest obstacle is that it would require the .text 
section (or equivalent) of the executable to be writable. I know 
that's possible on Linux, but I'm not sure whether the same is 
true for most other operating systems. I guess it might also be a 
security risk?

Re: Fragile ABI

[R Grocott]

Hm. Come to think of it, I have another question for somebody 
knowledgeable about this stuff:


The blog post I linked only talks about rewriting vtables at 
dynamic-link-time. Would it be possible to implement something 
similar for the sizes of structs and scope-classes, and the 
relative address of member variables? dsimcha's post has led me 
to realize that without these additional features, the ABI would 
still be quite fragile.


I know very little about dynamic linking, but I guess it might be 
too expensive to justify? If nothing else, it would probably 
block a few compile-time optimisations (since offsets and sizes 
would have to be treated as unknown variables rather than integer 
constants).

Re: Fragile ABI

[R Grocott]

And yet that is what DirectX and WinRT are all about.


DirectX, yes: it's a good example of an OO library with a purely 
interface-based API. The only DirectX plugin architecture I can 
bring to mind, though (DirectShow filters), actually uses C++ 
classes (such as CSource) to hide a lot of the underlying 
complexity. I get the impression that wouldn't be necessary if 
interface-based plugins were as simple to create as 
inheritance-based ones.


Likewise, WinRT actually hides a huge amount of complexity inside 
its language bindings. Inheriting from a WinRT object using only 
the underlying COM interfaces involves a lot of hassle, and is a 
prime example of what I'm talking about. See here:


http://www.interact-sw.co.uk/iangblog/2011/09/25/native-winrt-inheritance


Your GUI toolkit just needs to expose interfaces for the 
different
types of events it is required to handle, and you give via API 
calls

objects whose instances implement said interfaces.

To avoid too much code rewrite, some component systems, COM 
included,
support a form of delegation where you can implement just a 
part of the
interface, while delegating the remaining calls to a contained 
object.


That sounds clean in theory - but so does Pimpl, and I know from 
experience that Pimpl tends to make a horrible mess out of any 
codebase. It doesn't help that, as far as I know, COM is 
Windows-only, and D doesn't natively support the 
method-defaulting system you described.


In practice, I think that proper interoperability w/r/t classes 
and inheritance will tend be cleaner than coding strictly against 
an interface. This can be demonstrated by choosing any base-class 
derived-class pair, from any OO codebase, and attempting to 
rewrite that parent-child relationship as a server-client one.

Re: Fragile ABI

[R Grocott]

I'm aware that just exposing class interfaces (via COM or other 
means) is an option, but that tends to cause many problems of its 
own:


- You can no longer call new or delete on the underlying class; 
you're obliged to use factory methods. This leads to issues with 
templates and stack allocation (although this will be less of an 
issue for D compared to C++).


- You can't directly inherit from any of the library's classes. 
This is an issue for any library which wants to allow "custom 
components" (for example, widgets in a GUI toolkit, dialog boxes 
in a browser plugin, or controls in a desktop panel). Coding 
strictly against interfaces is one workaround, but that often 
makes things more complicated than they need to be.


- The library can't provide template methods for classes exposed 
this way, and class methods can no longer be inlined.


- It forces the developer to maintain both a public interface and 
a private implementation; he can no longer code as though he's 
writing classes for his own use.


All of these are relatively minor issues, but taken together, 
they make library development quite difficult. For example, I 
think it would be almost impossible to develop a COM GUI toolkit.

Fragile ABI

[R Grocott]

http://michelf.ca/blog/2009/some-ideas-for-dynamic-vtables-in-d/

The above blog post, written in 2009, proposes a system for 
solving the Fragile ABI Problem in D. Just wondering whether 
anything like this is a planned feature for druntime.


C++'s fragile ABI makes it very difficult to write class 
libraries without some sort of workaround. For example, RapidXML 
and AGG are distributed as source code; GDI+ is a header-only 
wrapper over an underlying C interface; and Qt makes heavy use of 
the Pimpl idiom, which makes its source code much more complex 
than it needs to be. This is also a major problem for any program 
which wants to expose a plugin API.


It would be nice if D could sidestep this issue. It's frustrating 
that C is currently the only real option for developing native 
libraries without worrying about their ABI.

Re: GWAN webserver allowing dynamic pages in D

[Eric R. Schulz (ers35)]

I am able to see that post.


Am I the only one to see this post:

Re: GWAN webserver allowing dynamic pages in D

[Eric R. Schulz (ers35)]

See [1] for details on how to run your own benchmark.

It would be interesting to compare Warp and G-WAN using both of 
their provided benchmark tests.


[1]http://forum.gwan.com/index.php?p=/discussion/525/nginx1.0.6-vs-lighttpd1.4.29-vs-g-wan2.9.30-rpscpuram

On Monday, 25 June 2012 at 15:09:58 UTC, Caligo wrote:
I don't know much about web servers, but is it really the only 
web
server "able to scale on multi-core CPUs"??  I've played around 
with

Yesod/Warp and I was under the impression that it's one of the
fastest.  
http://www.yesodweb.com/blog/2011/03/preliminary-warp-cross-language-benchmarks

Re: GWAN webserver allowing dynamic pages in D

[Eric R. Schulz (ers35)]

True. I will investigate writing a D wrapper for the C API.


Using C plain api it's not a good way to use D power IMHO :)
Encapsulate code with classes/template/etc would be a good idea.

Re: GWAN webserver allowing dynamic pages in D

[Eric R. Schulz (ers35)]

G-WAN exports a C API and D supports calling C functions.

In what way could G-WAN better support D?

Perhaps reading the G-WAN manual would help to explain: 
http://gwan.ch/archives/gwan_linux.pdf



Maybe they should give a better support for D language...

Re: GWAN webserver allowing dynamic pages in D

[Eric R. Schulz (ers35)]

There is an example at "0.0.0.0_8080/#0.0.0.0/csp/hello.d_" in 
the tarball. To use it, install GDC and rename "hello.d_" to 
"hello.d".


You may have difficulties depending on the version of GDC you 
use. I do not recall which version is supported. I will find out 
and make another reply.


On Monday, 25 June 2012 at 10:42:36 UTC, Andrea Fontana wrote:

D.annunce newsgroup fits better :)

However I can't find any example/sdk for D pages...
Neither in tarball I see in download section.

Re: Shared objects?

[R. Grocott]

I'm not too experienced with Github - am I right in thinking that
the SharedRuntime repository has been idle for six months? If so,
does this indicate that Martin has likely abandoned the project?

Like Wouter, I'm looking into developing a project with D that
would eventually require plugins, and I could really do with a
definite answer whether or not this functionality is expected to
be available within, say, twelve months. Is there anybody I could
contact who's likely to know the answer?

One last question - when you say that the runtime can't yet
properly handle dynamic library loading, does this apply equally
to both DMD and GDC? I know that both projects share a fair
amount of common code.

Re: demangle tool

[R]

Hurm. I thought one of the things D had over C++ was that with aliases such 
complex error messages can be avoided. While D still seems to be better off 
than C++ I guess something like this is unavoidable with metaprogramming?

Andrei Alexandrescu Wrote:

> I wrote a simple utility (at the bottom of this message) that may help 
> debugging link-time errors. It reads lines from stdin and writes them 
> with DMD symbols, if any, demangled.
> 
> For example, here's what you see if you add "alias field this;" to Tuple 
> in std.typecons and try to build the "new, new" Phobos:
> 
> obj/posix/debug/unittest/std/file.o: In function 
> `_D3std4file14__T5slurpTiTdZ5slurpFAyaxAaZAS3std8typecons14__T5TupleTiTdZ5Tuple':
> /home/andrei/code/dmd/phobos/std/file.d:1772: undefined reference to 
> `_D3std8typecons14__T5TupleTiTdZ5Tuple6__initZ'
> /home/andrei/code/dmd/phobos/std/file.d:1781: undefined reference to 
> `_D3std5array51__T8AppenderTAS3std8typecons14__T5TupleTiTdZ5TupleZ8Appender3putMFxS3std8typecons14__T5TupleTiTdZ5TupleZv'
> obj/posix/debug/unittest/std/file.o: In function 
> `_D3std5array88__T8appenderTAS3std8typecons14__T5TupleTiTdZ5TupleTS3std8typecons14__T5TupleTiTdZ5TupleZ8appenderFPAS3std8typecons14__T5TupleTiTdZ5TupleZS3std5array51__T8AppenderTAS3std8typecons14__T5TupleTiTdZ5TupleZ8Appender':
> /home/andrei/code/dmd/phobos/std/array.d:578: undefined reference to 
> `_D3std5array51__T8AppenderTAS3std8typecons14__T5TupleTiTdZ5TupleZ8Appender6__ctorMFNcPAS3std8typecons14__T5TupleTiTdZ5TupleZS3std5array51__T8AppenderTAS3std8typecons14__T5TupleTiTdZ5TupleZ8Appender'
> obj/posix/debug/unittest/std/file.o: In function 
> `_D3std8typecons14__T5tupleTiTdZ5tupleFidZS3std8typecons14__T5TupleTiTdZ5Tuple':
> /home/andrei/code/dmd/phobos/std/typecons.d:515: undefined reference to 
> `_D3std8typecons14__T5TupleTiTdZ5Tuple6__initZ'
> collect2: ld returned 1 exit status
> --- errorlevel 1
> 
> However, if you use "make |& ./demangle.d", you see:
> 
> obj/posix/debug/unittest/std/file.o: In function `struct 
> std.typecons.Tuple!(int, double).Tuple[] std.file.slurp!(int, 
> double).slurp(immutable(char)[], const(char[]))':
> /home/andrei/code/dmd/phobos/std/file.d:1772: undefined reference to `Z 
> std.typecons.Tuple!(int, double).Tuple.__init'
> /home/andrei/code/dmd/phobos/std/file.d:1781: undefined reference to 
> `void std.array.Appender!(struct std.typecons.Tuple!(int, 
> double).Tuple[]).Appender.put(const(struct std.typecons.Tuple!(int, 
> double).Tuple))'
> obj/posix/debug/unittest/std/file.o: In function `struct 
> std.array.Appender!(struct std.typecons.Tuple!(int, 
> double).Tuple[]).Appender std.array.appender!(struct 
> std.typecons.Tuple!(int, double).Tuple[], struct 
> std.typecons.Tuple!(int, double).Tuple).appender(struct 
> std.typecons.Tuple!(int, double).Tuple[]*)':
> /home/andrei/code/dmd/phobos/std/array.d:578: undefined reference to 
> `_D3std5array51__T8AppenderTAS3std8typecons14__T5TupleTiTdZ5TupleZ8Appender6__ctorMFNcPAS3std8typecons14__T5TupleTiTdZ5TupleZS3std5array51__T8AppenderTAS3std8typecons14__T5TupleTiTdZ5TupleZ8Appender'
> obj/posix/debug/unittest/std/file.o: In function `struct 
> std.typecons.Tuple!(int, double).Tuple std.typecons.tuple!(int, 
> double).tuple(int, double)':
> /home/andrei/code/dmd/phobos/std/typecons.d:515: undefined reference to 
> `Z std.typecons.Tuple!(int, double).Tuple.__init'
> collect2: ld returned 1 exit status
> --- errorlevel 1
> make: *** [obj/posix/debug/unittest/std/file] Error 1
> 
> The line wraps are all garbled, but you get the idea: all symbols quoted 
> `like this' have been demangled appropriately. Below is the source of 
> the demangle script:
> 
> #!/home/andrei/bin/rdmd
> import std.algorithm, std.demangle, std.getopt, std.stdio;
> 
> void main(string[] args)
> {
>  string lSep = "`", rSep = "'";
>  getopt(args, "lsep", &lSep, "rsep", &rSep);
>  foreach (line; stdin.byLine())
>  {
>  auto sym = find(line, lSep);
>  if (!sym.length)
>  {
>  writeln(line);
>  continue;
>  }
>  sym = sym[1 .. $];
>  auto before = line[0 .. $ - sym.length];
>  sym = sym[0 .. $ - find(sym, rSep).length];
>  auto after = line[before.length + sym.length .. $];
>  writeln(before, demangle(sym.idup), after);
>  }
> }
> 
> 
> Hope this helps someone,
> 
> Andrei

Re: DB/DBMS in D

[Chris R Miller]

Vladimir A. Reznichenko wrote:

Dear Mr./Ms.,


I'd like to ask you about the garbage collector.
It slows down an application, doesn't it?

In case of DBMS, this is critical. I haven't found any articles or tests
about this.

Also it would be great to find out about memory management implemented in
DMD: fragmentation, allocation, reallocation. And if wide-known algorithms are 
used there could it be named?

The C/C++ is classic choice for such projects (DBMS), but the D language
is great one and the best for me ). I want to find out abilities of using
it.


I would argue the opposite: that in a long-running process such as an 
RDBMS you would *want* the garbage collector to ensure that there are no 
memory leaks.  You could have either a super-fast database which leaks 
memory (so your users would have to restart it periodically) OR you 
could use a garbage collector, take the performance penalty (not that 
much - quite frankly, complaining about the garbage collector is like 
complaining that the silverware is gold and not platinum) and have the 
assurance that your memory leakage will be kept to an absolute minimum 
(or not at all, if you remember to properly declare weak references).


Obviously it is possible to use a language like C++ and write code which 
doesn't leak memory... however, that level of effort isn't going to give 
you significant increases in performance compared to D.  D is just plain 
fast.

Re: forward reference hell!

[Chris R Miller]

To stop a forward-reference problem you need to declare the type, but 
not implement it.  Eg:


$ cat vector.d #-
> module vector;
>
> class Vector(E) {
>   E[] data;
> }
>
> $ cat student.d #-
> module student;
>
> import vector;

class Teacher;

> // define Student
> class Student {
>   void ask(Teacher teacher) {
>   }
> }
>
> // define Students
> alias Vector!(Student) Students;
>
> $ cat teacher.d #-
> module teacher;
>
> import student;
>
> class Teacher {
>   Students students;
> }

It is not necessary to smash them all into one file.

Re: The path to unity

[Chris R Miller]

Jarrett Billingsley wrote:

On Fri, Feb 6, 2009 at 11:05 AM, Don  wrote:

With the druntime project, we now have a run time which is shared between
Tango and Phobos. This is a huge step forward, but it's still not much use
without some common user code.

The highest priorities which I see are, in order:
(1) the C standard library
tango.stdc = std.stdc
(2) low-level compiler-related modules
most of tango.core -- for the most part, this is already part of druntime.
(3) tango.math.Math + tango.math.IEEE  = std.math - tgamma().

Can we get agreement on unification of these, at least?


I agree with that.  tango.stdc.posix is also far more complete than
what is in Phobos and would be beneficial to everyone.


If we are able to reach agreement on this, I propose the next step would be
to ensure that the contents of these files be made "identical" on Phobos2
and Tango. ("identical" meaning that when the Tango code is ported to D2, it
will be identical to the Phobos2 version, except for module name
differences).

Doing this will not give us very many immediate benefits. It will break a
very small amount of code, but only in fairly trivial ways. In doing so, it
will remove the subtle inconsistencies between the libraries.
 From there, the next step (quick to implement, but requiring political
agreement) would be to decide on a common namespace. Since this first
step is much less political, I'd like to get agreement to do it now.


Hm.  Name for a common namespace.. How about "common".


I was thinking about keeping it simple.

Either migrate tango to std (and keep module aliases for tango for a 
while to help give people some leniency while they update their code) or 
perhaps move the whole mess to a new namespace: d (duh!)


Just my $0.02 on that subject...

Re: goto

[Chris R Miller]

Bill Baxter wrote:

On Fri, Feb 6, 2009 at 2:30 PM, Andrei Alexandrescu
  wrote:

Walter Bright wrote:

double euclideanDistance(Range)(Range a, Range b, double limit)
{
limit *= limit;
double result = 0;
for (; 1; a.next, b.next)
{
if (a.empty)
{
   enforce(b.empty);
   break;
}
enforce(!b.empty);
auto t = a.head - b.head;
result += t * t;
if (result>= limit) break;
}
return sqrt(result);
}

Gotta give it to The Man!

So after all I couldn't find a good use for goto.


Meh.  I dislike seeing things like for(; 1; ) or while(true) in a loop
(unless it's something like a top level message processing loop or
such).  At least in your goto version I know from a glance at the
for() part  that at most we're going to iterate till the thing is
empty.


Wherever did the foreach(auto foo in bar) feature request go?  Or did 
that conflict with existing syntax?

Re: goto

[Chris R Miller]

Andrei Alexandrescu wrote:

Yah, same here. I seem to finally have found one of the elusive cases
when goto simplifies things.

About Brad's variant - ranges don't define clear, but assigning b =
b.init does the trick. (I personally still find the goto version
marginally clearer. It's also marginally more efficient because it
doesn't do one assignment and one vacuous check. Also the joke with the
programmer who throws the water and then applies the known procedure to
make coffee comes to mind.)


Enlighten those of us unfamiliar with this joke?

Re: D versus Objective C Comparison

[Chris R Miller]

Sean Kelly wrote:

Chris R Miller wrote:


= Short Story =

I needed to search through a String (NSString) specifically to know 
whether a character at a specific index is any one of a given set of 
characters.  Rather than subclass NSString, I decided to make a category:

 > [snip]

Won't all of this be solved by the planned D2 feature of making these 
operations synonymous for all types?


void fn(T val);
T t;
fn(t);
t.fn();

Or are you saying that these added functions can actually access private 
data in the class?


Yes, they can access private data.  I see how this could be both a 
feature and a potential hazard.  Then again, do you not need to be 
careful when subclassing things in Java-style OO languages?  Otherwise 
you can very easily mire yourself in a world of objects that end up 
hindering more than helping.


And just to prove D's potency, the very algorithm I used was stolen from 
something I wrote in D not long ago:


== DuffsDevice.d ==

module duffsdevice;

import tango.io.Stdout;

/// tells if anything in the contents of arr1 are present in arr2
/// uses type implicit opCmp for comparison
bool hasAnyOf(T)(T[] arr1,T[] arr2){
T[] small,large;
if(arr1.length>arr2.length){
large=arr1;small=arr2;
}else{
large=arr2;small=arr1;
}
int lp,rm=large.length%10;
foreach(T t;small){
lp=(large.length-1)/10;
switch(rm){
case 0: do{
if(t==large[lp*10+9]) return true;
case 9: if(t==large[lp*10+8]) return true;
case 8: if(t==large[lp*10+7]) return true;
case 7: if(t==large[lp*10+6]) return true;
case 6: if(t==large[lp*10+5]) return true;
case 5: if(t==large[lp*10+4]) return true;
case 4: if(t==large[lp*10+3]) return true;
case 3: if(t==large[lp*10+2]) return true;
case 2: if(t==large[lp*10+1]) return true;
case 1: if(t==large[lp*10  ]) return true;
}while(0<--lp);
break;
}
}
return false;
}

void main(char[][] argc) {
if(argc.length>2) {
Stdout("argc[0]=={}",argc[1]).newline;
Stdout("argc[1]=={}",argc[2]).newline;
Stdout("hasAnyOf!(char[])(argc[0],argc[1])=={}",
   hasAnyOf!(char)(argc[1],argc[2])).newline;
}
}

== EOF ==

Personally I prefer the D to the Objective-C implementation.

Re: D versus Objective C Comparison

[Chris R Miller]

Jacob Carlborg wrote:

Walter Bright wrote:
Setting aside the technical issues for the moment, isn't that exactly 
what inheritance is supposed to be good for?


A few times I've had the need for this, I've always been able to solve 
the problem but it would have been easier with support for this. But to 
be honest I don't remember these problems right now, so perhaps it's not 
that important.


I think it has less to do with how often its needed and more to do with 
how much more elegant the solution will be.


Just because I want to supply one example of where it's even appropriate 
to use a category-pattern to extend a class' function table without 
extending the class into a new type, I'll just spit out something I just 
wrote in Objective-C.


= Short Story =

I needed to search through a String (NSString) specifically to know 
whether a character at a specific index is any one of a given set of 
characters.  Rather than subclass NSString, I decided to make a category:


== NSString.h ==

#import 

@interface NSString (ACSExtensions)

- (bool)characterAtIndex:(int)idx
 isOneOf:(NSString*)characters;

@end

== NSString.m ==

#import "NSString.h"

@implementation NSString (ACSExtensions)

- (bool)characterAtIndex:(int)idx
 isOneOf:(NSString*)characters {
unichar *arr = malloc([characters length]*sizeof(unichar));
[characters getCharacters:arr];

char ch = [self characterAtIndex:idx];

int lp=([characters length]-1)/10,rm=[characters length]%10;

switch(rm){
case 0: do {
if(ch==arr[lp*10+9]) return YES;
case 9: if(ch==arr[lp*10+8]) return YES;
case 8: if(ch==arr[lp*10+7]) return YES;
case 7: if(ch==arr[lp*10+6]) return YES;
case 6: if(ch==arr[lp*10+5]) return YES;
case 5: if(ch==arr[lp*10+4]) return YES;
case 4: if(ch==arr[lp*10+3]) return YES;
case 3: if(ch==arr[lp*10+2]) return YES;
case 2: if(ch==arr[lp*10+1]) return YES;
case 1: if(ch==arr[lp*10  ]) return YES;
} while(0<--lp);
break;
}
return NO;
}

@end

== end of file ==

As you can see, I added important functionality to the class NSString 
without going through all the trouble to make a new class and type cast 
between NSString and MyDerivedString all over the place.  It's more 
transparent, and it's far better than a global function, or placing this 
kind of code into an unrelated class, or worse yet, a "kitchen-sink" class.


= Special Extended Explanation =

Since some of you may be in a hurry, this part is kind of secondary.

The purpose for adding functionality to NSString is because I'm trying 
my hand at writing my own programming language (interpreted, but a 
language nonetheless).  It's very rudimentary in syntax and capability, 
and it's only designed to script the effects of cards in a card game 
called Arcomage.  I later extended some of its capabilities to make it 
suitable for AI scripting as well.


Mind you I haven't implemented the language yet.  I just wrote a 
specification that I'm now focusing on implementing.  If you want to 
have a laugh or maybe see how badly I've been spoiled by D, you can read 
through the specsheet here:


http://www.fsdev.net/~cmiller/pdf/acs_spec.pdf

And I talk a bit on how I plan to implement such a system over here:

http://www.fsdev.net/~cmiller/a/20090126_acsadv.html

Anyways, the specific and immediate purpose for writing such 
functionality into NSString was so that I could - as I was parsing 
through the source script - quickly and easily check to see if 
characters are certain control characters.  For instance, when searching 
for an integer, the first task is to read to the first numeric 
character.  Two options: read to the first numeric character, or (more 
resistant to malformed code) read through all the whitespace characters 
and then if the next character isn't numeric, you have problems.  What 
whitespace characters are there?


\t
\r
\n
(space)

Unfortunately, they aren't in sequential order in the ASCII table, so 
it's not as simple as determining if char c is numeric:


if ( c > '0' && c < '9' ) // c is numeric

Therefore, it's useful for searching quickly, without getting into the 
potential mess that could be a regular expression search.  Well, I'm 
sure for a lot of people it'd be shorter and more concise, but my 
relative ineptitude with regular expressions would make it far more 
bothersome for me.  Am I here to write a language, or to teach myself 
regular expressions?






Anyways, I'm really happy with the ensuing discussion about this - this 
is the entire reason why I decided to compare the two languages: in 
hopes of bringing up potentially useful features and getting people to 
think about them.

Re: D versus Objective C Comparison

[Chris R Miller]

John Reimer wrote:

I link to stuff so that people can do more reading if they want. :)

And again, I'm not there to really give a history lesson, more to
analyze the situation of "you want to build an app which does foo,
which is better for that purpose?"  (the answer is that it depends:
who do you want to support?  Windows and Linux, or OS X?)


As you wish, but I still think you left out a fairly distinct part of 
Objective C introduction: it's what makes it Objective C.  I say this 
because your mention of it is more appropriate on that side of the 
Objective-C introduction than the D one.   Not all OOP languages are alike.


Well, I've come to the general conclusion that I am the least 
experienced person around here, so I'll defer to your judgement there. 
I've added a small note that acknowledges Objective-C's SmallTalk design 
underpinnings.



Yes, the 32-bit-ness of DWT has distressed me for some time.  When I
had DMD working on Ubuntu a while back I tried to make DWT work... the
code is 64-bit compatible AFACT, but it needs some work with the
libraries it links to - they're not 64-bit compatible.  I wasn't up to
re-writing the library linkage (or the prospect of maybe finding that
the code itself isn't 64-bit compatible!) so I just left it unfixed in
hopes that someone else would fix it someday.


There are a lot of d applications and libraries that will need to become 
64-bit someday.  I'm afraid, though, that those of us contributing to 
dwt can only handle so much for now. 


I'm still amazed that so few people were able to create DWT.


I would argue the opposite.  Objective-C retains the ability to
compile and run *any* code that C can.  C is a general-purpose
language. Therefore Objective-C is a SmallTalk-ish extension of a
general-purpose language.


Yes, I made an assumption in my statement there (concerning the C 
language). If you still consider the C component a competitive 
general-purpose language, then this is indeed true.  I don't think C 
(plus the OO extension) is nearly as competitive in functionality as D 
or C++ as general-purpose languages go.  What we're discussing here 
anyway is really just the Objective extension, since C is available 
everywhere anyway.


There is still a whole lot of stuff being written in C, both 
commercially and Open-Source.  I believe that's because it's such a 
good, general-purpose language and because it's ubiquitous.  Nearly 
every platform has a C compiler.


But I do feel the Objective C extension serves the niche that it's in 
very well; in fact, it becomes the best option for that platform 
specifically because of the rich runtime and API immediately at its 
disposal.  But this could be the case with many languages that manage to 
be neatly and nearly built around an operating system... even D would 
excel a manifold times more if things like garbage collection, language 
specific linking and dynamics, interfaces, etc were integrated into and 
understood by the OS (or a type of abstraction layer that implements the 
functionality).   What better than to have singular consistancy where 
everything is oriented to D in a system such the compilers and systems 
can make easy assumptions.



I emphasize this fact because the dynanism that Objective C achieves is 
primarly a result of its runtime.  Here's a quote from /Objective-C 2.0 
Runtime Programming Guide/ (Introduction, Page 7):



"The Objective-C language defers as much as it can from compile time and 
link time to runtime.  Whenever possible, it does things dynamically.  
This means that the language requires not just a compiler, but also a 
runtime system to execute the compiled code.  The runtime system acts as 
a kind of operating system for the Objective-C language; it's what makes 
the language work."



This is actually kind of interesting because it would seem to make 
Objective-C slightly comparable to the C# language in that it's more 
than just a language (as is Java).  It's a platform (and the beauty of 
the platform is really only extensively demonstrated by the OS runtime 
functionality that supports it ... and Cocoa). 


Well, I suppose it's largely how much you build into the runtime.  C and 
C++ have runtimes, after all, but compared to things like D and C# they 
don't do much at all.  D, C#, and Objective-C perform many more 
functions via their runtimes than do C and C++.



To me, it's the lack of really strong multiplatform support that keeps
Objective-C from being more of a multiplatform general-purpose
language, but it's still a general-purpose language to me.


Yes, this is also true.  But I think Objective C will likely never break 
out of this mold because all the impressive functionality is to remain 
bound to it's runtime + API functionality on a single platform.  On the 
other hand, if Apple ever takes over the computer industry, I suppose 
we'll see Objective C everywhere, and then there will be no argument. :) 


Objective-C's runtime is bundled with it jus

Re: D versus Objective C Comparison

[Chris R Miller]

John Reimer wrote:

Hello Chris,



http://www.fsdev.net/~cmiller/a/20090123_dvobjc.html

Also, I do honor the right of reply.  If there's something I have
written that is now incorrect or inaccurate I will of course change my
page to reflect that.  Heck, all the comparisons in the world are
worthless if they aren't accurate!

Have a great day, and keep up the good work!  I personally can't wait
until D gets to the point that a (total bonehead) like me can install
it on OS X!  Alas, right now it seemeth to require more brain cells
than I have at my disposal.




Here's a couple comments:


(1) I'm surprised that, in your Objective C introduction, you don't 
indicate that the langauge is a direct decendant of Smalltalk.  
Interestingly you mention Smalltalk in the D introduction instead, even 
though the only similarity between the two is that they both implement a 
form of OO programming.  Objective C is practically C with embedded 
Smalltalk. A major purpose for the creation of Objective C was to bring 
the benefits and explicit OO style of SmallTalk to C language developers.


To me it seems that every language borrows from SmallTalk.  So I prefer 
to just ignore it as the father or all modern language design patterns.


I link to stuff so that people can do more reading if they want. :)

And again, I'm not there to really give a history lesson, more to 
analyze the situation of "you want to build an app which does foo, which 
is better for that purpose?"  (the answer is that it depends: who do you 
want to support?  Windows and Linux, or OS X?)


(2)  The DWT port doesn't support 64-bit platforms (so far as I know), 
so I don't understand why this is called a bug.  The two ports of SWT 
that are currently supported are dwt-win and dwt-linux, both 32-bit 
versions and dependent on a 32-compiler (dmd for x86).  dwt-mac is still 
in development by Jacob Carlborg: this version is compiled with gdc for 
Mac and is also 32-bit, so far as I know.


Yes, the 32-bit-ness of DWT has distressed me for some time.  When I had 
DMD working on Ubuntu a while back I tried to make DWT work... the code 
is 64-bit compatible AFACT, but it needs some work with the libraries it 
links to - they're not 64-bit compatible.  I wasn't up to re-writing the 
library linkage (or the prospect of maybe finding that the code itself 
isn't 64-bit compatible!) so I just left it unfixed in hopes that 
someone else would fix it someday.



Finally, I agree most with what you say here:


"I stand by my original statement that they're different languages and 
different tools for different purposes."



My take on it is this:


Some of Objective C's features are very useful (dynamic OO extensions 
and runtime binding); however, I think that Objective-C is really meant 
to be a sort of domain specific solution for which the Cocoa development 
experience is optimized: the language is purposely simple, which makes 
it significantly useful for its intended task.  I know Apple recently 
updated the language to Objective C 2.0 that added a few more 
convenience features, but I don't think they even argue that it's 
directly competitive with C++ (however, I cannot verify this).  In fact, 
for those that might need to use other libraries or use more powerful 
features only available in C++, there's the option of developing in 
Objective C++.



Finally, I don't think Objective-C was intended to be a general-purpose 
programming language in the manner of D or C++, so the comparison will 


I would argue the opposite.  Objective-C retains the ability to compile 
and run *any* code that C can.  C is a general-purpose language. 
Therefore Objective-C is a SmallTalk-ish extension of a general-purpose 
language.


To me, it's the lack of really strong multiplatform support that keeps 
Objective-C from being more of a multiplatform general-purpose language, 
but it's still a general-purpose language to me.

Re: D versus Objective C Comparison

[Chris R Miller]

Anders F Björklund wrote:

Chris R Miller wrote:

Have a great day, and keep up the good work!  I personally can't wait 
until D gets to the point that a (total bonehead) like me can install 
it on OS X!  Alas, right now it seemeth to require more brain cells 
than I have at my disposal.


You can find Mac OS X installer packages on http://gdcmac.sf.net/

If you *require* Leopard / Xcode 3.0 support or Tango / DSSS etc.
look at http://www.dsource.org/projects/tango/wiki/MacOSXInstall


Well, I don't have Tiger lying around for me to use, so Leopard is 
non-negotiable.


I tried those packages several times, but each time it complained that 
the checksum didn't validate.  I tried re-downloading several times, 
using wget and curl as well (sometimes they're more robust), but it 
didn't work.



LDC packages are available for 0.9, but it has some bugs still...


Personally I can't wait to try LDC!  AFAICT LDC and LLVM are some of the 
newest things happening to compilers in a long time.  But I am keeping 
myself busy with Objective-C right now (I think there's a better chance 
that I'll find a paying job with Objective-C) so I can't say that I'll 
be investing time into checking it out as soon as I'd like.


He who has not a working compiler on hand should keep a low profile. 
Which is why I've not been terribly active 'round these parts lately.


But fear not, I am inactive, not gone!  Or that could be reason to 
fear... depends on your viewpoint I suppose.

Re: D versus Objective C Comparison

[Chris R Miller]

Christopher Wright wrote:
It seems that your only significant complaint about Descent is that it 
is not integrated with DSSS. I believe you can set up DSSS as an 
external task in Eclipse:

http://dsource.org/projects/descent/wiki/CompilingPrograms

I believe this will call dsss (or whatever program you specify) on the 
current file, however.


Yes, I looked into that before... I never was able to make it work. 
I've used Eclipse for a long, long, long time, and if I and my heavy 
Java/Eclipse background and experience can't make it work... a 
comparative newbie looking to build something quick and show the world 
isn't going to get that to work, either.


Then again, regression towards the mean would suggest that I could be 
very, very mistaken...

Re: D versus Objective C Comparison

[Chris R Miller]

Michel Fortin wrote:
On 2009-01-31 17:03:10 -0500, Chris R Miller 
 said:



Michel Fortin wrote:
On 2009-01-31 15:39:17 -0500, Chris R Miller 
 said:


Anyways, I decided to write up a comparison of the two languages 
from a less technical, more deployment oriented standpoint.  IOW, 
examining how well they perform for the last mile of development: 
deploying software.


You talk about IDEs in there, and praise Xcode. Do you know about D 
for Xcode?

<http://michelf.com/projects/d-for-xcode/>


I never got that working with Xcode 3.0, so I decided to ignore it.


That's sad. There was a time where it didn't work with Xcode 3, but I've 
fixed that. If you still wish it to work, please test with the latest 
verision and send me be a bug report if you still have problems. I'm 
still fixing bugs when I know it c


I'll put it on the accumulator, though my magic 8-ball says "don't count 
on it."  I've got school again... and this crazy teacher that has me 
print out all this stuff... killing trees left and right this guy is. 
Luckily we just got this fancy new printer with duplex, so that's a big 
relief (plus ADF Duplex scanning - FTW!)


One area I think Objective-C to be very great and that you haven't 
touched is for creating stable APIs. In Objective-C, contrary to D 
and C++, you don't have to recompile every dependency when 
reordering, adding and removing member functions in a class. In 
64-bit Objective-C 2.0, you can even add variables to a class without 
care about recompiling derived classes. Compare that to D, where 
exposing a class as a public API will either force you to not change 
much that class, or force your users to recompile every time you make 
such a change.


Hm, I didn't know that.  I'm not sure it is exactly pertinent to the 
main focus, which is towards quickly building software which can then 
be deployed to a user base relatively quickly and easily.  I just 
glossed over some language features to give a small peek at the 
language's killer features according to me.  D's most cool trick is 
the ability to implement the functionality of many data structures 
through use of its array syntax, and Objective-C is cool 'cause it's C 
with objects, sans all the crazy complexity that you run into with C++.


No indeed. I was just mentionning something I admire very much about 
Objective-C which makes it very good to build stable yet evolving APIs. 
Something which neither C++ nor D has.


Yup, someday someone will take the absolute best parts of all languages 
and make one big super-language.  Until then... D is the closest I've 
seen to the one language to rule them all.

Re: D versus Objective C Comparison

[Chris R Miller]

Michel Fortin wrote:
On 2009-01-31 18:50:52 -0500, Walter Bright  
said:



Michel Fortin wrote:
One area I think Objective-C to be very great and that you haven't 
touched is for creating stable APIs. In Objective-C, contrary to D 
and C++, you don't have to recompile every dependency when 
reordering, adding and removing member functions in a class. In 
64-bit Objective-C 2.0, you can even add variables to a class without 
care about recompiling derived classes. Compare that to D, where 
exposing a class as a public API will either force you to not change 
much that class, or force your users to recompile every time you make 
such a change.


If you use interfaces, you can add member fields without needing to 
recompile clients.


Yeah, indeed. I hadn't thought about that. That's a pretty interesting 
thing about interfaces now that you make me think about it.


But exposing only interfaces makes the API harder to use. In Cocoa, 
classes gain new methods at each new version of the framework (read each 
version of Mac OS X) and it doesn't hinder programs compiled with 
earlier versions of the framework.


If you had a smart enough dynamic linker and the signature of each 
function in the virtual table, you could do that in D too by creating 
virtual tables and updating offsets in the code accordingly while 
linking. (Objective-C doesn't work like that, but it has the same 
effect.) Alternativly, it could be done in some static initialisation 
phase.


An increasingly interesting toy to study (I would think) would be 
Categories - the ability to take an existing class and just randomly 
tack on additional receivers.  Perhaps this is exclusive to 
Objective-C's message-receiver architecture, but it's a curious little 
technology nonetheless.

Re: D versus Objective C Comparison

[Chris R Miller]

Walter Bright wrote:

Chris R Miller wrote:

Walter Bright wrote:

Chris R Miller wrote:
Also, I do honor the right of reply.  If there's something I have 
written that is now incorrect or inaccurate I will of course change 
my page to reflect that.  Heck, all the comparisons in the world are 
worthless if they aren't accurate!


Thanks for doing this, it's a nice comparison. But one error is that 
there is a dmd for Linux, and it's as fully supported and capable as 
the windows one. I use it all the time on Ubuntu.


Hmm, I didn't think that I was implying that it wasn't supported, but 
I have never gotten it to work satisfactorily on Linux with my usual 
entourage of libraries, so I just try and ignore it as me "not doing 
it right" again.


I have clarified that part though, as after re-reading it I see how it 
could be taken the wrong way.


Thanks. But what is the issue you're running into with the Linux dmd?


Primarily that it's difficult (for me) to figure out how to get Tango 
and DSSS working with it.


The compiler is only part of the story - in your defense, I got the 
//compiler// working just fine.  It was my aforementioned entourage of 
libraries that stopped the party.  If I remember correctly the 
showstopper was DWT.  It was Linux 64, and DWT (at least at that point 
in time) wasn't yet 64-bit compatible.  So it didn't work.

Re: D versus Objective C Comparison

[Chris R Miller]

Michel Fortin wrote:
On 2009-01-31 15:39:17 -0500, Chris R Miller 
 said:


Anyways, I decided to write up a comparison of the two languages from 
a less technical, more deployment oriented standpoint.  IOW, examining 
how well they perform for the last mile of development: deploying 
software.


You talk about IDEs in there, and praise Xcode. Do you know about D for 
Xcode?

<http://michelf.com/projects/d-for-xcode/>


I never got that working with Xcode 3.0, so I decided to ignore it.


And since have you taken a look at my D/Objective-C bridge?
<http://michelf.com/projects/d-objc/>


Unfortunately not.  I don't have any compilable D code to bridge to 
Objective-C.


Unfortunately, these two projects aren't getting much attention these 
days, mostly because I can't do much with the current state of the one D 
compiler that runs on my PowerPC iBook.


Hm, that'd certainly be an impediment to continuing work with D.

One area I think Objective-C to be very great and that you haven't 
touched is for creating stable APIs. In Objective-C, contrary to D and 
C++, you don't have to recompile every dependency when reordering, 
adding and removing member functions in a class. In 64-bit Objective-C 
2.0, you can even add variables to a class without care about 
recompiling derived classes. Compare that to D, where exposing a class 
as a public API will either force you to not change much that class, or 
force your users to recompile every time you make such a change.


Hm, I didn't know that.  I'm not sure it is exactly pertinent to the 
main focus, which is towards quickly building software which can then be 
deployed to a user base relatively quickly and easily.  I just glossed 
over some language features to give a small peek at the language's 
killer features according to me.  D's most cool trick is the ability to 
implement the functionality of many data structures through use of its 
array syntax, and Objective-C is cool 'cause it's C with objects, sans 
all the crazy complexity that you run into with C++.


Also, I do honor the right of reply.  If there's something I have 
written that is now incorrect or inaccurate I will of course change my 
page to reflect that.  Heck, all the comparisons in the world are 
worthless if they aren't accurate!


Well there's one error:

"If you ignore Cocoa, then there is the GNUStep [gnustep.org] project, 
which is an Open-Source implementation of the old Carbon standard from 
NeXT Step."


No. Carbon was created to ease port of classic Mac OS applications to 
Mac OS X. It's a revamped version of the Mac OS Toolbox, which got some 
additions as Mac OS X evolved. It has nothing to do with NeXT.

<http://en.wikipedia.org/wiki/Carbon_(API)>


Yikes, I'm just full of hot air today, aren't I?

Fixed.  :-)

Re: D versus Objective C Comparison

[Chris R Miller]

Walter Bright wrote:

Chris R Miller wrote:
Also, I do honor the right of reply.  If there's something I have 
written that is now incorrect or inaccurate I will of course change my 
page to reflect that.  Heck, all the comparisons in the world are 
worthless if they aren't accurate!


Thanks for doing this, it's a nice comparison. But one error is that 
there is a dmd for Linux, and it's as fully supported and capable as the 
windows one. I use it all the time on Ubuntu.


Hmm, I didn't think that I was implying that it wasn't supported, but I 
have never gotten it to work satisfactorily on Linux with my usual 
entourage of libraries, so I just try and ignore it as me "not doing it 
right" again.


I have clarified that part though, as after re-reading it I see how it 
could be taken the wrong way.

D versus Objective C Comparison

[Chris R Miller]

In my hiatus from D, I decided to take the plunge and teach myself 
Objective-C.  This gave me some interesting insights into both 
languages.  It's so fun, whenever I find another programmer, one of the 
first twenty things I say is "have you ever tried Digital Mars D?  It 
will change your whole life, I swear to you!"


Anyways, I decided to write up a comparison of the two languages from a 
less technical, more deployment oriented standpoint.  IOW, examining how 
well they perform for the last mile of development: deploying software.


As is my general stance, I refuse to downright pick a side - they're 
both good languages.  But I thought that those of you who put so much 
(god-damn heroic) effort into D might appreciate a little critique for a 
small bit of perspective.


http://www.fsdev.net/~cmiller/a/20090123_dvobjc.html

Also, I do honor the right of reply.  If there's something I have 
written that is now incorrect or inaccurate I will of course change my 
page to reflect that.  Heck, all the comparisons in the world are 
worthless if they aren't accurate!


Have a great day, and keep up the good work!  I personally can't wait 
until D gets to the point that a (total bonehead) like me can install it 
on OS X!  Alas, right now it seemeth to require more brain cells than I 
have at my disposal.

Re: People speaketh

[Chris R Miller]

Bill Baxter wrote:

On Fri, Jan 30, 2009 at 7:25 AM, Chris R Miller
 wrote:

Pick one and stick with it.  That is all I would suggest.

If someone takes major offense to it, they could alias it to their
preference, right?


Not really, because these names will be used as members of hundreds of
different user-created range structs.
There's no way to make a generic alias for a member of even one struct
let alone hundreds of different ones.


I stand corrected.  Or actually I'm lying in bed with my back against 
the wall using my laptop, but you get the idea.

Re: People speaketh

[Chris R Miller]

Andrei Alexandrescu wrote:
first/last - 13: Jarrett, Bill, dsimcha, Sandeep, Chad, Tiago, Robert, 
Simen, Brian, Bill, Yigal, Gide,  Ary.


head/toe - 9: Bill, dsimcha, Robert, Simen, Max, Don, Michel, Denis, Brian,

front/back - 15: dsimcha, Chad, Steve, Robert, Nick, BCS, Bill, BLS, 
Yigal, Daniel, Max, Don, Gide, Brian, Andrei.


head/last - 7: John, Chad, Sean, Nick, Yigal, Kazuhiro, Max.

There were other choices that were not as popular as the ones above, 
please don't be angry I didn't mention them all.


This vote was rather informal so I allowed myself to do a tally without 
having specified a deadline etc. So I'm not sure how much this all 
counts... should we just settle for front and back?


Pick one and stick with it.  That is all I would suggest.

If someone takes major offense to it, they could alias it to their 
preference, right?  I've been dabbling with Objective-C while waiting 
for the DMD/GDC/LDC thunking to end, so my D is getting slightly rusty.