Re: Why I'm hesitating to switch to D

[Jacob Carlborg]

On 2011-06-28 21:37, James Fisher wrote:

I'm a casual follower of development on D.  In my opinion, it's the
cleanest, most complete multi-paradigm language currently out there --
from what I can see, I would describe the language as *done*.  However,
I, like many others, am not switching to it.  Why?  Because a perfect
language does not a perfect development environment make: everything
*surrounding* the language is a complete mess.  Here's my
non-comprehensive laundry list in the hope it's useful to someone.


*# Package management*


I working on this. This is the ideas I have: 
https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D


I've started the development. I'm going to write a more detail 
explanation/specification of the tools.



--
/Jacob Carlborg

Re: Why I'm hesitating to switch to D

[Jacob Carlborg]

On 2011-06-28 23:09, Walter Bright wrote:

5. I know I suck at web site design, which is why David Gileadi helped
us out by designing the d-programming-language.org look & feel.


I think it makes it hard when most of the pages are written in DDOC. It 
doesn't help to attract web designers.


--
/Jacob Carlborg

Re: Why I'm hesitating to switch to D

[James Fisher]

On Wed, Jun 29, 2011 at 1:02 AM, Nick Sabalausky  wrote:

> "Jimmy Cao"  wrote in message
> news:mailman.1263.1309305438.14074.digitalmar...@puremagic.com...
> > On Tue, Jun 28, 2011 at 5:49 PM, James Fisher
> > wrote:
> >
> >>
> >> Though the site at http://www.dsource.org/projects/tango gives no
> >> indication of that and still evangelizes migration from Phobos to Tango.
> >>  Are there people that would disagree with your assessment?
> >>
> >
> > The tango homepage will never say something like, "D1/Tango is dead,
> > everyone migrate to Phobos!"  If you look at the history of D, back in
> > 2006
> > or 2007 when the system for requesting improvements and bugfixes was
> > rather
> > messy and Phobos was increasingly incompetent as a standard library, part
> > of
> > the community decided to work on replacing Phobos and make a better
> > library
> > for the community and driven by the community.  So that was how the Tango
> > community started, and that community stayed with D1 when D2 was
> released.
> >
> > Both communities exist today, I guess, but the D2/Phobos community has
> > grown
> > the most, and D1/Tango community has shrunken (it's been years, the fact
> > that there are still some D1/Tango users means that Tango really is a
> fine
> > library).  Phobos has improved ,also, and the transition to github has
> > helped it a lot.  Your best bet is Phobos - its development is very
> > active,
> > and it is poised to clearly become the best standard library.
> >
>
> And even if Tango does get ported to D2 (As I've heard some people are
> working on), it'll most likely be a suppliment to Phobos, rather than the
> "one or the other" issue it was on D1. (That's what druntime is for.)
>

OK.

1.  One of the most pleasingly surprising tech stories I've heard for years
was the merging of Rails and
Merb,
two large separate Ruby web frameworks with the same problem domain.  It was
surprising because in the OSS world there's a nasty habit of all projects
being a fork of something else, almost never a merge of two previous
projects.  I figure all it took was some strong discussion.  BTW, the choice
of stdlib is not obvious to the new user of the language, and the "just let
it die" attitude makes things confusing.  This SO question from
09 (was
the choice considered a non-issue then?) for instance recommends Tango.

2. I suppose, once a package manager is in place, this issue will fade as
Tango can be meted out into smaller packages.

Re: 7z (Was: 64 bit DMD binary on the Mac)

[Jimmy Cao]

The 7-Zip archiver supports it.

On Tue, Jun 28, 2011 at 11:40 PM, Andrew Wiley wrote:

> On Tue, Jun 28, 2011 at 9:17 PM, Jimmy Cao  wrote:
>
>> On Tue, Jun 28, 2011 at 9:05 PM, Andrew Wiley 
>> wrote:
>>
>>> On Tue, Jun 28, 2011 at 3:13 PM, Nick Sabalausky  wrote:
>>>
 "Michel Fortin"  wrote in message
 news:iudhf9$2dr9$1...@digitalmars.com...
 > On 2011-06-28 15:39:42 -0400, Walter Bright <
 newshou...@digitalmars.com>
 > said:
 >
 >> On 6/28/2011 12:13 PM, Jacob Carlborg wrote:
 >>> Since most of the applications and most the libraries (basically all
 >>> that ships
 >>> with Mac OS X) are universal there's usually no problem of
 >>> running/building both
 >>> 32 and 64bit software.
 >>
 >> I'll explain the motivation for 64 bit only DMD binaries:
 >>
 >> 1. It cuts the testing time in half. This is a significant deal for
 me,
 >> as adding another hour to the test cycle slows things down a lot.
 >>
 >> 2. It speeds downloading the dmd package.
 >>
 >> The only reason to have a 32 bit binary is if there are x86 Macs 10.5
 or
 >> later that are incapable of running 64 bit code.
 >
 > Well, you could ship the next DMD version 64-bit only and of you get
 > complains you bring back the 32-bit version as a universal binary.
 >
 > But you'll definitely rule out users of Apple's early Intel computers.
 I
 > think the last Apple model with a 32-bit CPU was the "Mac Mini (Late
 > 2006)", which was replaced mid 2007 with a Core 2 Duo model.
 >
 > As for increasing the download speed, you could try one of these too:
 >
 > * separate per-OS packages
 > * separate source package
 > * separate documentation package
 > * faster server

 * use 7z

 Using 7z instead of zip or tarballs has shrunk the size of my packaged
 Goldie releases down to roughly one-quarter the size of a zip or tar.bz2
 (Yes, ~75% decrease is size). Of course, that's probably an extreme
 case,
 but I just tried making a 7z of DMD 2.053, and it came out to just under
 9MB
 (vs just over 15MB for the official zip release), so fairly close to
 half
 the size. Still pretty damn good.

 And I really see no reason why any programmer shouldn't have a
 7z-capable
 extractor these days. Heck, it's pretty typical on Linux, and it's built
 into WinRar. Zip and tarballs are like MP3's: They're still everywhere,
 but
 only because of inertia, not because of any inherent merit, of which
 there
 really isn't any. 7z is like moving to Vorbis (Except that I think 7z
 support is probably more common than Vorbis support, which is
 unfortunate
 for Vorbis fans like me, but that's even more OT...).



>>> Have you tried xz on Linux? I think WinRar supports it on Windows, but I
>>> haven't checked in a while.
>>>
>>>
>>
>> I just tried using WinRAR to open a tar.xz file, and it didn't work.
>>
>
> Ah, then I suppose I'm a liar and/or delusional. I remember opening one on
> Windows with some archiver, but I've only ever done it a few times, and not
> on a box I have access to at the moment.
>

Re: 7z (Was: 64 bit DMD binary on the Mac)

[Andrew Wiley]

On Tue, Jun 28, 2011 at 9:17 PM, Jimmy Cao  wrote:

> On Tue, Jun 28, 2011 at 9:05 PM, Andrew Wiley wrote:
>
>> On Tue, Jun 28, 2011 at 3:13 PM, Nick Sabalausky  wrote:
>>
>>> "Michel Fortin"  wrote in message
>>> news:iudhf9$2dr9$1...@digitalmars.com...
>>> > On 2011-06-28 15:39:42 -0400, Walter Bright <
>>> newshou...@digitalmars.com>
>>> > said:
>>> >
>>> >> On 6/28/2011 12:13 PM, Jacob Carlborg wrote:
>>> >>> Since most of the applications and most the libraries (basically all
>>> >>> that ships
>>> >>> with Mac OS X) are universal there's usually no problem of
>>> >>> running/building both
>>> >>> 32 and 64bit software.
>>> >>
>>> >> I'll explain the motivation for 64 bit only DMD binaries:
>>> >>
>>> >> 1. It cuts the testing time in half. This is a significant deal for
>>> me,
>>> >> as adding another hour to the test cycle slows things down a lot.
>>> >>
>>> >> 2. It speeds downloading the dmd package.
>>> >>
>>> >> The only reason to have a 32 bit binary is if there are x86 Macs 10.5
>>> or
>>> >> later that are incapable of running 64 bit code.
>>> >
>>> > Well, you could ship the next DMD version 64-bit only and of you get
>>> > complains you bring back the 32-bit version as a universal binary.
>>> >
>>> > But you'll definitely rule out users of Apple's early Intel computers.
>>> I
>>> > think the last Apple model with a 32-bit CPU was the "Mac Mini (Late
>>> > 2006)", which was replaced mid 2007 with a Core 2 Duo model.
>>> >
>>> > As for increasing the download speed, you could try one of these too:
>>> >
>>> > * separate per-OS packages
>>> > * separate source package
>>> > * separate documentation package
>>> > * faster server
>>>
>>> * use 7z
>>>
>>> Using 7z instead of zip or tarballs has shrunk the size of my packaged
>>> Goldie releases down to roughly one-quarter the size of a zip or tar.bz2
>>> (Yes, ~75% decrease is size). Of course, that's probably an extreme case,
>>> but I just tried making a 7z of DMD 2.053, and it came out to just under
>>> 9MB
>>> (vs just over 15MB for the official zip release), so fairly close to half
>>> the size. Still pretty damn good.
>>>
>>> And I really see no reason why any programmer shouldn't have a 7z-capable
>>> extractor these days. Heck, it's pretty typical on Linux, and it's built
>>> into WinRar. Zip and tarballs are like MP3's: They're still everywhere,
>>> but
>>> only because of inertia, not because of any inherent merit, of which
>>> there
>>> really isn't any. 7z is like moving to Vorbis (Except that I think 7z
>>> support is probably more common than Vorbis support, which is unfortunate
>>> for Vorbis fans like me, but that's even more OT...).
>>>
>>>
>>>
>> Have you tried xz on Linux? I think WinRar supports it on Windows, but I
>> haven't checked in a while.
>>
>>
>
> I just tried using WinRAR to open a tar.xz file, and it didn't work.
>

Ah, then I suppose I'm a liar and/or delusional. I remember opening one on
Windows with some archiver, but I've only ever done it a few times, and not
on a box I have access to at the moment.

Re: 7z (Was: 64 bit DMD binary on the Mac)

[Jimmy Cao]

On Tue, Jun 28, 2011 at 9:05 PM, Andrew Wiley wrote:

> On Tue, Jun 28, 2011 at 3:13 PM, Nick Sabalausky  wrote:
>
>> "Michel Fortin"  wrote in message
>> news:iudhf9$2dr9$1...@digitalmars.com...
>> > On 2011-06-28 15:39:42 -0400, Walter Bright > >
>> > said:
>> >
>> >> On 6/28/2011 12:13 PM, Jacob Carlborg wrote:
>> >>> Since most of the applications and most the libraries (basically all
>> >>> that ships
>> >>> with Mac OS X) are universal there's usually no problem of
>> >>> running/building both
>> >>> 32 and 64bit software.
>> >>
>> >> I'll explain the motivation for 64 bit only DMD binaries:
>> >>
>> >> 1. It cuts the testing time in half. This is a significant deal for me,
>> >> as adding another hour to the test cycle slows things down a lot.
>> >>
>> >> 2. It speeds downloading the dmd package.
>> >>
>> >> The only reason to have a 32 bit binary is if there are x86 Macs 10.5
>> or
>> >> later that are incapable of running 64 bit code.
>> >
>> > Well, you could ship the next DMD version 64-bit only and of you get
>> > complains you bring back the 32-bit version as a universal binary.
>> >
>> > But you'll definitely rule out users of Apple's early Intel computers. I
>> > think the last Apple model with a 32-bit CPU was the "Mac Mini (Late
>> > 2006)", which was replaced mid 2007 with a Core 2 Duo model.
>> >
>> > As for increasing the download speed, you could try one of these too:
>> >
>> > * separate per-OS packages
>> > * separate source package
>> > * separate documentation package
>> > * faster server
>>
>> * use 7z
>>
>> Using 7z instead of zip or tarballs has shrunk the size of my packaged
>> Goldie releases down to roughly one-quarter the size of a zip or tar.bz2
>> (Yes, ~75% decrease is size). Of course, that's probably an extreme case,
>> but I just tried making a 7z of DMD 2.053, and it came out to just under
>> 9MB
>> (vs just over 15MB for the official zip release), so fairly close to half
>> the size. Still pretty damn good.
>>
>> And I really see no reason why any programmer shouldn't have a 7z-capable
>> extractor these days. Heck, it's pretty typical on Linux, and it's built
>> into WinRar. Zip and tarballs are like MP3's: They're still everywhere,
>> but
>> only because of inertia, not because of any inherent merit, of which there
>> really isn't any. 7z is like moving to Vorbis (Except that I think 7z
>> support is probably more common than Vorbis support, which is unfortunate
>> for Vorbis fans like me, but that's even more OT...).
>>
>>
>>
> Have you tried xz on Linux? I think WinRar supports it on Windows, but I
> haven't checked in a while.
>
>

I just tried using WinRAR to open a tar.xz file, and it didn't work.

Re: version bug? or am I missing something?

[clone!(all)]

On 6/29/2011 11:28 AM, Jonathan M Davis wrote:

On 2011-06-28 19:22, clone!(all) wrote:

The following outputs "Unicode!". If I reverse the comment for [1] and
[2] however, the output is "ASCII".

file a:

module A;

version = Unicode;  [1]

version(Unicode)
{
alias ChoiceA Choice;
}
else
{
alias ChoiceB Choice;
}

string ChoiceA() { return "Unicode!"; }

string ChoiceB() { return "ASCII"; }


file b:

module B;

import std.stdio: writeln;
import A;

//version = Unicode; [2]

static this()
{
writeln(Choice());
}

void main(){}


==
experience = GetExperience();
assert(experience == "tyro")


When you use use add a new version like that, it only affects the file that
it's in. No other files are affected. If you want it to affect all files, you
have to use the -version flag when compiling.

- Jonathan M Davis


Got it... thank for the swift response.

Re: version bug? or am I missing something?

[Jonathan M Davis]

On 2011-06-28 19:22, clone!(all) wrote:
> The following outputs "Unicode!". If I reverse the comment for [1] and
> [2] however, the output is "ASCII".
> 
> file a:
> 
> module A;
> 
> version = Unicode;  [1]
> 
> version(Unicode)
> {
>   alias ChoiceA Choice;
> }
> else
> {
>   alias ChoiceB Choice;
> }
> 
> string ChoiceA() { return "Unicode!"; }
> 
> string ChoiceB() { return "ASCII"; }
> 
> 
> file b:
> 
> module B;
> 
> import std.stdio: writeln;
> import A;
> 
> //version = Unicode; [2]
> 
> static this()
> {
>   writeln(Choice());
> }
> 
> void main(){}
> 
> 
> ==
> experience = GetExperience();
> assert(experience == "tyro")

When you use use add a new version like that, it only affects the file that 
it's in. No other files are affected. If you want it to affect all files, you 
have to use the -version flag when compiling.

- Jonathan M Davis

version bug? or am I missing something?

[clone!(all)]

The following outputs "Unicode!". If I reverse the comment for [1] and 
[2] however, the output is "ASCII".


file a:

module A;

version = Unicode;  [1]

version(Unicode)
{
alias ChoiceA Choice;
}
else
{
alias ChoiceB Choice;
}

string ChoiceA() { return "Unicode!"; }

string ChoiceB() { return "ASCII"; }


file b:

module B;

import std.stdio: writeln;
import A;

//version = Unicode; [2]

static this()
{
writeln(Choice());
}

void main(){}


==
experience = GetExperience();
assert(experience == "tyro")

Re: 7z (Was: 64 bit DMD binary on the Mac)

[Andrew Wiley]

On Tue, Jun 28, 2011 at 3:13 PM, Nick Sabalausky  wrote:

> "Michel Fortin"  wrote in message
> news:iudhf9$2dr9$1...@digitalmars.com...
> > On 2011-06-28 15:39:42 -0400, Walter Bright 
> > said:
> >
> >> On 6/28/2011 12:13 PM, Jacob Carlborg wrote:
> >>> Since most of the applications and most the libraries (basically all
> >>> that ships
> >>> with Mac OS X) are universal there's usually no problem of
> >>> running/building both
> >>> 32 and 64bit software.
> >>
> >> I'll explain the motivation for 64 bit only DMD binaries:
> >>
> >> 1. It cuts the testing time in half. This is a significant deal for me,
> >> as adding another hour to the test cycle slows things down a lot.
> >>
> >> 2. It speeds downloading the dmd package.
> >>
> >> The only reason to have a 32 bit binary is if there are x86 Macs 10.5 or
> >> later that are incapable of running 64 bit code.
> >
> > Well, you could ship the next DMD version 64-bit only and of you get
> > complains you bring back the 32-bit version as a universal binary.
> >
> > But you'll definitely rule out users of Apple's early Intel computers. I
> > think the last Apple model with a 32-bit CPU was the "Mac Mini (Late
> > 2006)", which was replaced mid 2007 with a Core 2 Duo model.
> >
> > As for increasing the download speed, you could try one of these too:
> >
> > * separate per-OS packages
> > * separate source package
> > * separate documentation package
> > * faster server
>
> * use 7z
>
> Using 7z instead of zip or tarballs has shrunk the size of my packaged
> Goldie releases down to roughly one-quarter the size of a zip or tar.bz2
> (Yes, ~75% decrease is size). Of course, that's probably an extreme case,
> but I just tried making a 7z of DMD 2.053, and it came out to just under
> 9MB
> (vs just over 15MB for the official zip release), so fairly close to half
> the size. Still pretty damn good.
>
> And I really see no reason why any programmer shouldn't have a 7z-capable
> extractor these days. Heck, it's pretty typical on Linux, and it's built
> into WinRar. Zip and tarballs are like MP3's: They're still everywhere, but
> only because of inertia, not because of any inherent merit, of which there
> really isn't any. 7z is like moving to Vorbis (Except that I think 7z
> support is probably more common than Vorbis support, which is unfortunate
> for Vorbis fans like me, but that's even more OT...).
>
>
>
Have you tried xz on Linux? I think WinRar supports it on Windows, but I
haven't checked in a while.

Re: 64 bit DMD binary on the Mac

[Daniel Gibson]

Am 29.06.2011 00:27, schrieb Walter Bright:

On 6/28/2011 3:22 PM, Nick Sabalausky wrote:

OTOH, It seems to be pretty typical, standard, accepted practice in the
Apple world for older machines to get abandoned *very* quickly, so maybe
32-bit is already needless on Mac?


Are there any 32 bit x86 Mac machines? My several-years-old mac mini is
64 bits.




Yes, see:

Am 28.06.2011 23:30, schrieb Michel Fortin:
> But you'll definitely rule out users of Apple's early Intel computers. I
> think the last Apple model with a 32-bit CPU was the "Mac Mini (Late
> 2006)", which was replaced mid 2007 with a Core 2 Duo model.
>

and

Am 28.06.2011 21:13, schrieb Jacob Carlborg:
>
> I just had a look at this:
>
> http://support.apple.com/kb/ht3696
>
> Any Mac running Intel Core Solo or Intel Core Duo is 32bit only.
> Although it's hard to tell how many users that have a Mac with any of
> the above CPU's.
>

Cheers,
- Daniel

Re: Why I'm hesitating to switch to D

[Nick Sabalausky]

"Jimmy Cao"  wrote in message 
news:mailman.1263.1309305438.14074.digitalmar...@puremagic.com...
> On Tue, Jun 28, 2011 at 5:49 PM, James Fisher 
> wrote:
>
>>
>> Though the site at http://www.dsource.org/projects/tango gives no
>> indication of that and still evangelizes migration from Phobos to Tango.
>>  Are there people that would disagree with your assessment?
>>
>
> The tango homepage will never say something like, "D1/Tango is dead,
> everyone migrate to Phobos!"  If you look at the history of D, back in 
> 2006
> or 2007 when the system for requesting improvements and bugfixes was 
> rather
> messy and Phobos was increasingly incompetent as a standard library, part 
> of
> the community decided to work on replacing Phobos and make a better 
> library
> for the community and driven by the community.  So that was how the Tango
> community started, and that community stayed with D1 when D2 was released.
>
> Both communities exist today, I guess, but the D2/Phobos community has 
> grown
> the most, and D1/Tango community has shrunken (it's been years, the fact
> that there are still some D1/Tango users means that Tango really is a fine
> library).  Phobos has improved ,also, and the transition to github has
> helped it a lot.  Your best bet is Phobos - its development is very 
> active,
> and it is poised to clearly become the best standard library.
>

And even if Tango does get ported to D2 (As I've heard some people are 
working on), it'll most likely be a suppliment to Phobos, rather than the 
"one or the other" issue it was on D1. (That's what druntime is for.)

Re: Why I'm hesitating to switch to D

[Jimmy Cao]

On Tue, Jun 28, 2011 at 5:49 PM, James Fisher wrote:

>
> Though the site at http://www.dsource.org/projects/tango gives no
> indication of that and still evangelizes migration from Phobos to Tango.
>  Are there people that would disagree with your assessment?
>

The tango homepage will never say something like, "D1/Tango is dead,
everyone migrate to Phobos!"  If you look at the history of D, back in 2006
or 2007 when the system for requesting improvements and bugfixes was rather
messy and Phobos was increasingly incompetent as a standard library, part of
the community decided to work on replacing Phobos and make a better library
for the community and driven by the community.  So that was how the Tango
community started, and that community stayed with D1 when D2 was released.

Both communities exist today, I guess, but the D2/Phobos community has grown
the most, and D1/Tango community has shrunken (it's been years, the fact
that there are still some D1/Tango users means that Tango really is a fine
library).  Phobos has improved ,also, and the transition to github has
helped it a lot.  Your best bet is Phobos - its development is very active,
and it is poised to clearly become the best standard library.

Re: Some Clang static analyser results

[Trass3r]

Have you run it over dmd's source code?

Re: Why I'm hesitating to switch to D

[Trass3r]

Am 29.06.2011, 00:49 Uhr, schrieb James Fisher :

On Tue, Jun 28, 2011 at 10:09 PM, Walter Bright
2. The "two standard libraries" debacle it pretty much in the past now.  
D2

going forward has one standard library, Phobos.



Fair enough.  Though the site at http://www.dsource.org/projects/tango  
gives
no indication of that and still evangelizes migration from Phobos to  
Tango.

 Are there people that would disagree with your assessment?


Well the problem has indeed been solved in D2 by splitting the runtime  
from the standard library. In fact the Tango runtime was adapted to be  
used as a new common druntime.
But most of the Tango guys just can't seem to get along with D2 and thus  
pursue their own goals now.
So there's only one std lib right now. Someone is trying to port Tango to  
D2 though.

Re: Why I'm hesitating to switch to D

[Walter Bright]

On 6/28/2011 3:35 PM, bearophile wrote:

Regardless its status along its history, it's several years that D aims to be
a good language with a good compiler.


I'd like to agree that D's emphasis has been first and foremost on being an 
excellent language.


It gives the rest something to live up to :-)

Re: delegate cannot handle polymorphism?

[Michel Fortin]

On 2011-06-27 07:49:19 -0400, Nub Public  said:

What's the rational for this behavior though? Resolving the address of 
a virtual function at compile time seems a little counter-intuitive to 
me.


The address for a virtual function isn't necessarily resolved at 
compile time. It is resolved at the point where you use the address-of 
operator, and that'll check the vtable at runtime if necessary.


In D:

B b = new D;
auto dg = &b.foo; // address is resolved at runtime by looking at the 
vtable
dg(); // calls D.foo

In C++:

void (B::*fptr)() = &B::foo;
B b = new D;
b.*fptr(); // vtable lookup here, calls D.foo



I guess this way is slightly more efficient.


It certainly is if you call the delegate more often than you create one.

--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: Why I'm hesitating to switch to D

[James Fisher]

On Tue, Jun 28, 2011 at 10:09 PM, Walter Bright
wrote:

> Thanks for taking the time to do a detailed writeup on your opinions. I
> think it's great feedback.
>

Well, thanks!

1. We all (well, almost all) agree on the need for a package manager. There
> are some recent threads on getting this going.
>

Ah.  Is 
thisthe
main thread you mean?


> 2. The "two standard libraries" debacle it pretty much in the past now. D2
> going forward has one standard library, Phobos.
>

Fair enough.  Though the site at http://www.dsource.org/projects/tango gives
no indication of that and still evangelizes migration from Phobos to Tango.
 Are there people that would disagree with your assessment?

3. For searching, I recommend "D programming" with the quotes. It works
> pretty good in google. I also harangue people who write about D to include
> the phrase "D programming language" at least once on their pages. This helps
> a lot. On twitter we use #d_lang to tie things together.
>

K.

4. The official website for D is now
http://www.d-programming-**language.org
> .


An odd thing about it is that one might mistake it for a companion site to
Andrei's book, having the same name and the front page devoted to it.  Is
this intentional?  Perhaps the plan is to host the book, in a
read-it-free-online-or-buy-the-book scheme, like the amazing Real World
Haskell?
 (That would be an incredibly strong resource.)  Is Andrei's book an
official part of the D project?


> 5. I know I suck at web site design


No offense meant!

6. The dlinks page is ancient, and it's been a long time since I even looked
> at it. I agree it needs a revamp.
>
> 7. The d-programming-language.org site is on github - this means that you
> can create pull requests for it! Please do for anything specific you can
> contribute to.
>

I'd love to.  Is the content of digitalmars.com/d now frozen; is the
intention to replace it with a redirect once content is migrated?

Some Clang static analyser results

[bearophile]

Found following a link chain from Reddit. A list of results of applying the 
Clang (LLVM) static analyser on large/medium C/C++ projects. The output is nice 
HTML with nice annotations and tool tips:

http://lbalbalba.freezoka.net/ccc-analyzer/

Some of the bugs (some of them are not real bugs) found in GCC 4.5.3:
Dereference of null pointer 309
Dead assignment 156
Idempotent operation69
Dead initialization 35
Result of operation is garbage or undefined 14  

One of the comments I have read about similar tools:
>The thing of it is, that you always end up with 100% false positives because 
>people fix the real bugs and mess up your statistics.<

Bye,
bearophile

Re: Why I'm hesitating to switch to D

[bearophile]

James Fisher:

Welcome here.


>Why I'm hesitating to switch to D<

You don't need to "switch" to D. Just using it along with other languages is 
better.


>The language, maybe, but this statement is absolutely not true while there is 
>no associated package manager.<

It's called advertisement :-)


>a massive "batteries included" standard library is no substitute for a 
>world-class package manager.<
>The productivity gain that comes from being able to execute "dinstall 
>", and then having it magically available, is *immense*.<

Right.


>IMO the big-standard-library is a slightly outdated concept in an age where 
>we're always able to pull stuff from the net in an instant.<

There are several more things I'd like in the D standard distribution. External 
libs don't avoid the need of a rich Phobos. As most other design things, it's a 
matter of trade-offs.


>There's an important reason that other languages have squiffy names: 
>searchability.  Googling for "d " is useless, and "d language " 
>is still awful.<

I think it's too much late to fix this for D.


>The point I want to get across here is: the problem with the D programming 
>language *is not that there are problems with the D programming language.* The 
>language and compiler (from what I know) have been world-class for some time.<

Here there is a huge fallacy. I want a well designed language first, with a 
well debugged compiler that produces efficient binaries. This is the necessary 
base to build on, to create Phobos, all nice libraries, and tools like package 
managers and IDEs. A good language without libraries and tools is not so 
useful, but if you don't create a good language&compiler first, or you don't 
express the desire to create it, then I am not interested in it (in the world 
there are languages that are badly designed but are widely used). Regardless 
its status along its history, it's several years that D aims to be a good 
language with a good compiler.

Bye,
bearophile

Re: 64 bit DMD binary on the Mac

[Walter Bright]

On 6/28/2011 3:22 PM, Nick Sabalausky wrote:

OTOH, It seems to be pretty typical, standard, accepted practice in the
Apple world for older machines to get abandoned *very* quickly, so maybe
32-bit is already needless on Mac?


Are there any 32 bit x86 Mac machines? My several-years-old mac mini is 64 bits.

Re: 64 bit DMD binary on the Mac

[Nick Sabalausky]

"Walter Bright"  wrote in message 
news:iudbma$1d9k$2...@digitalmars.com...
> On 6/28/2011 12:11 PM, KennyTM~ wrote:
>> With universal binary there's no need to worry about it anyway.
>
> It's not what I'm asking, I'm asking if there is any reason at all to ship 
> a 32 bit dmd binary?

To not encourage people to accidentally end up writing code that's so 
ctfe/template-heavy that it won't compile with a 32-bit DMD? I don't mean 
that as a snide remark, just a practical consideration.

Plus, in the same way that 64-bit DMD can help shake out 64-bit bugs, 32-bit 
can help shake out memory-usage problems.

OTOH, It seems to be pretty typical, standard, accepted practice in the 
Apple world for older machines to get abandoned *very* quickly, so maybe 
32-bit is already needless on Mac?

7z (Was: 64 bit DMD binary on the Mac)

[Nick Sabalausky]

"Michel Fortin"  wrote in message 
news:iudhf9$2dr9$1...@digitalmars.com...
> On 2011-06-28 15:39:42 -0400, Walter Bright  
> said:
>
>> On 6/28/2011 12:13 PM, Jacob Carlborg wrote:
>>> Since most of the applications and most the libraries (basically all 
>>> that ships
>>> with Mac OS X) are universal there's usually no problem of 
>>> running/building both
>>> 32 and 64bit software.
>>
>> I'll explain the motivation for 64 bit only DMD binaries:
>>
>> 1. It cuts the testing time in half. This is a significant deal for me, 
>> as adding another hour to the test cycle slows things down a lot.
>>
>> 2. It speeds downloading the dmd package.
>>
>> The only reason to have a 32 bit binary is if there are x86 Macs 10.5 or 
>> later that are incapable of running 64 bit code.
>
> Well, you could ship the next DMD version 64-bit only and of you get 
> complains you bring back the 32-bit version as a universal binary.
>
> But you'll definitely rule out users of Apple's early Intel computers. I 
> think the last Apple model with a 32-bit CPU was the "Mac Mini (Late 
> 2006)", which was replaced mid 2007 with a Core 2 Duo model.
>
> As for increasing the download speed, you could try one of these too:
>
> * separate per-OS packages
> * separate source package
> * separate documentation package
> * faster server

* use 7z

Using 7z instead of zip or tarballs has shrunk the size of my packaged 
Goldie releases down to roughly one-quarter the size of a zip or tar.bz2 
(Yes, ~75% decrease is size). Of course, that's probably an extreme case, 
but I just tried making a 7z of DMD 2.053, and it came out to just under 9MB 
(vs just over 15MB for the official zip release), so fairly close to half 
the size. Still pretty damn good.

And I really see no reason why any programmer shouldn't have a 7z-capable 
extractor these days. Heck, it's pretty typical on Linux, and it's built 
into WinRar. Zip and tarballs are like MP3's: They're still everywhere, but 
only because of inertia, not because of any inherent merit, of which there 
really isn't any. 7z is like moving to Vorbis (Except that I think 7z 
support is probably more common than Vorbis support, which is unfortunate 
for Vorbis fans like me, but that's even more OT...).

Re: DDMD

[Andrej Mitrovic]

http://prowiki.org/wiki4d/wiki.cgi?DMDSourceGuide

KennyTM was kind enough to add a whole bunch of front-end info in
recent weeks, thanks Kenny!

Ok well if somebody is already doing the port they should let me now
on this NG, otherwise I'll start doing this the next day.

Re: DDMD

[Nick Sabalausky]

"Andrej Mitrovic"  wrote in message 
news:mailman.1257.1309287037.14074.digitalmar...@puremagic.com...
> On 6/28/11, Nick Sabalausky  wrote:
>> I was thinking of doing that since I didn't see anyone else doing it, but 
>> I
>> have a ton of other things keeping me plenty busy, so that'd be great if 
>> you
>> could.
>
> I don't have a lot of experience with DDMD/DMD since I'm new to its
> codebase. But I do have some experience porting C/C++ code to D. I
> don't think it would be too hard to figure out how to port the new
> changes, since DDMD seems to keep an almost 1to1 representation of C++
> and D code (well apart from a slightly different structure of its
> modules).
>

There's a page on the D Wiki with some helpful information on some of DMD's 
internals, but I never seem to be able to find the link. Anyone have it 
handy? (And of course, I or anyone else could certainly try to help with any 
questions.)

> But it's the scale of changes that is the biggest issue. I've got
> plenty of free time so I can volunteer to give it a go.

Great! :)

Re: Why I'm hesitating to switch to D

[Nick Sabalausky]

"James Fisher"  wrote in message 
news:mailman.1259.1309290936.14074.digitalmar...@puremagic.com...
>
> *# Package management*
>
> This one's *really* important.  The front page of
> digitalmars.org/d/describes it as having "... the programmer
> productivity of modern languages
> like Ruby and Python".  The language, maybe, but this statement is
> absolutely not true while there is no associated package manager.
>

Yea, that's why we're working on it. There's been a few rather big 
discussions on it very recently and a number of people have been working on 
actual code.

> I've followed the "two standard libraries" debacle with some confusion 
> (I'm
> still not clear what's being done about it).

For D2, the std lib is Phobos. Period. For D1, the de-facto standard is 
Tango (which was created because, at the time, Phobos wasn't very good and 
didn't have much manpower). This hasn't been an issue in ages.

> The closest thing to a central repository seems to be
> http://www.dsource.org/.  But this is all wrong.  People don't want to use 
> a
> language-specific site to host their project under SVN.  They want to use
> GitHub/Bitbucket/Google code/etc. Dsource.org should just maintain a list
> of packages for an installer -- say, like http://search.npmjs.org/.

DSource predates the widespread popularity of GitHub/Bitbucket/Google 
code/etc. I think it actually predates Google Code, period. Also, I'd 
caution against blanket stantements about "what people want." I, for one, 
like DSource. There are some things about it I like *better* than the 
others. And I'm happy using DSource for a number of things.

> That D
> projects are hosted on a D-exclusive site tells me that D has a closed
> community.
>

What this tells me is that you enjoy making assumptions and jumping to 
conclusions. ;)

> *# Community fragmentation*
>
> Where is the D community?  I see:
>
> http://www.digitalmars.com/d/ -- seems to be official
> http://www.d-programming-language.org/ -- also seems to be official!
>

You caught us right in the middle of the transition from 
http://www.digitalmars.com/d/ to http://www.d-programming-language.org/ 
That's why it seems confusing.

>
> http://www.dprogramming.com/

I don't see what's so wrong with that. It never claims to be anything 
official. I'm sure other languages have user-created sites, too. Big deal.

> http://www.dsource.org/
> etc.
>

That's for project hosting. Not the same.

> *# It's unsearchable!*
>
> This one is really trivial. There's an important reason that other
> languages have squiffy names: searchability.  Googling for "d " is
> useless, and "d language " is still awful.  Other languages that
> suffer from the same affliction have the convention of appending "lang" as 
> a
> suffix -- "golang", for example -- and this works well.  It seems that
> "dlang" has not caught on.  I see there's a site at http://dlang.org/ 
> (yes,
> yet another one!).  Whois says it's owned by http://oscarbrynolf.com/. 
> The
> (seemingly recent?) move to GitHub and new website would have been a 
> chance
> to get this right.  Prepending "d programming language" to every search I
> make is still absolutely horrible.
>

"d programming" works fine for me. And you're right, it is only a trivial 
matter.

>
> *# No marketing or brand awareness*
>
> OK, I can live with this.  But make no mistake: it *does* seriously cut 
> down
> on the people migrating to it.  Take a look at the "free images" offered 
> at
> http://digitalmars.com/d/dlinks.html -- this is a marketers nightmare! 
> That
> list *literally* makes me shudder.  I'm not saying that D requires another
> generic Web 2.0 HTML5 look with gradients and rounded corners that one 
> sees
> on the latest fashionable projects.  I *am* saying that it needs something
> consistent and clean, and currently it, seemingly willfully, has neither.
>

We've been doing a lot of marketing and promoting. As for the images, that 
seems to be an incredibly petty "issue".

>
> The point I want to get across here is: the problem with the D programming
> language *is not that there are problems with the D programming language.*
> The language and compiler (from what I know) have been world-class for 
> some
> time.  I've seen a few conversations where people using D get quite
> indignant that people are interested in Go, Rust, etc.  D is not getting 
> new
> users because it doesn't look like it *wants* new users: it dresses
> sloppily, it doesn't make itself findable easily, and it doesn't have
> infrastructure for new users to share and benefit from sharing.
>

The main problem with D is that there's too many people with their lists 
about what's wrong with D, and not enough willing to actually jump in and 
help out. I'm sorry if I come across a bit harsh, but we seriously get 
another one of these "What's wrong with D" lists every few weeks (and each 
one seems more out-of-date than the last) and hardly any of the people 
writing them have ever actually made any re

Re: 64 bit DMD binary on the Mac

[Michel Fortin]

On 2011-06-28 15:39:42 -0400, Walter Bright  said:


On 6/28/2011 12:13 PM, Jacob Carlborg wrote:

Since most of the applications and most the libraries (basically all that ships
with Mac OS X) are universal there's usually no problem of 
running/building both

32 and 64bit software.


I'll explain the motivation for 64 bit only DMD binaries:

1. It cuts the testing time in half. This is a significant deal for me, 
as adding another hour to the test cycle slows things down a lot.


2. It speeds downloading the dmd package.

The only reason to have a 32 bit binary is if there are x86 Macs 10.5 
or later that are incapable of running 64 bit code.


Well, you could ship the next DMD version 64-bit only and of you get 
complains you bring back the 32-bit version as a universal binary.


But you'll definitely rule out users of Apple's early Intel computers. 
I think the last Apple model with a 32-bit CPU was the "Mac Mini (Late 
2006)", which was replaced mid 2007 with a Core 2 Duo model.


As for increasing the download speed, you could try one of these too:

* separate per-OS packages
* separate source package
* separate documentation package
* faster server


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: Why I'm hesitating to switch to D

[Walter Bright]

Thanks for taking the time to do a detailed writeup on your opinions. I think 
it's great feedback.


1. We all (well, almost all) agree on the need for a package manager. There are 
some recent threads on getting this going.


2. The "two standard libraries" debacle it pretty much in the past now. D2 going 
forward has one standard library, Phobos.


3. For searching, I recommend "D programming" with the quotes. It works pretty 
good in google. I also harangue people who write about D to include the phrase 
"D programming language" at least once on their pages. This helps a lot. On 
twitter we use #d_lang to tie things together.


4. The official website for D is now http://www.d-programming-language.org.

5. I know I suck at web site design, which is why David Gileadi helped us out by 
designing the d-programming-language.org look & feel.


6. The dlinks page is ancient, and it's been a long time since I even looked at 
it. I agree it needs a revamp.


7. The d-programming-language.org site is on github - this means that you can 
create pull requests for it! Please do for anything specific you can contribute to.

Re: 64 bit DMD binary on the Mac

[Walter Bright]

On 6/28/2011 1:27 PM, KennyTM~ wrote:

Nope :). But I just worry in case there would be bugs introduced in the C++ code
due to the change in pointer size.


Only one way to shake those out!

(And 64 bit DMD on Linux has pretty much accomplished that.)

Re: Why I'm hesitating to switch to D

[David Gileadi]

On 6/28/11 1:37 PM, James Fisher wrote:

I *am* saying
that it needs something consistent and clean, and currently it,
seemingly willfully, has neither.  (BTW, I've done some web design work
before, e.g. http://hsk.org.uk/ -- I'd be willing to help out.)


I've done a little web design too, although it's definitely not my 
strong suit.  I quite like the look of the site you posted; you seem to 
be pretty good at it.


I felt largely the same as you about how the D language presents itself, 
which prompted me to offer to help with the site design.  The design 
that ended up at d-programming-language.org grew out of that.


I'm sure that any help and improvements you'd like to contribute would 
be welcomed.

Re: 64 bit DMD binary on the Mac

[KennyTM~]

On Jun 29, 11 03:52, Walter Bright wrote:

On 6/28/2011 12:11 PM, KennyTM~ wrote:

With universal binary there's no need to worry about it anyway.


It's not what I'm asking, I'm asking if there is any reason at all to
ship a 32 bit dmd binary?


Nope :). But I just worry in case there would be bugs introduced in the 
C++ code due to the change in pointer size.

Re: Why I'm hesitating to switch to D

[Andrej Mitrovic]

All of your problems are solvable by getting more people involved in
contributing to D. And, as far as I can tell, the existing
contributors are working at their 100% capacity even though they might
not have enough free time for themselves.

Things are improving for D, it just needs more time and more contributors.

Re: DDMD

[Trass3r]

According to a quick look at the changeset page (
http://hg.dsource.org/projects/ddmd/ ), the other contributors to DDMD,
besides me and Denis, are Trass3r, Eldar Insafutdinov, and Jacob  
Carlborg.


I've done a few upgrades to newer frontend versions back then but don't  
work on ddmd anymore.

Why I'm hesitating to switch to D

[James Fisher]

I'm a casual follower of development on D.  In my opinion, it's the
cleanest, most complete multi-paradigm language currently out there -- from
what I can see, I would describe the language as *done*.  However, I, like
many others, am not switching to it.  Why?  Because a perfect language does
not a perfect development environment make: everything *surrounding* the
language is a complete mess.  Here's my non-comprehensive laundry list in
the hope it's useful to someone.


*# Package management*

This one's *really* important.  The front page of
digitalmars.org/d/describes it as having "... the programmer
productivity of modern languages
like Ruby and Python".  The language, maybe, but this statement is
absolutely not true while there is no associated package manager.

I've followed the "two standard libraries" debacle with some confusion (I'm
still not clear what's being done about it).  But this isn't actually that
important, and D needs to learn from other languages/platforms (Python pip,
Ruby gems, NodeJS npm, Go goinstall, Haskell cabal, etc.) that a massive
"batteries included" standard library is no substitute for a world-class
package manager.  IMO the big-standard-library is a slightly outdated
concept in an age where we're always able to pull stuff from the net in an
instant.  A big stdlib means a big platform installation, no matter the size
of the task, and yet no stdlib can be so big as to satisfy all needs.

The productivity gain that comes from being able to execute "dinstall
", and then having it magically available, is *immense*.  When
I need to get a job done, I'll often choose an inferior manager-installable
library over a superior one where I have to hunt it out, download the
tar.gz, read the README, make, make install, realise dependencies are
missing, install them too, then fix everything that's broken.  Having a
package manager is also crucial to getting people to bother sharing their
code with others.

The closest thing to a central repository seems to be
http://www.dsource.org/.  But this is all wrong.  People don't want to use a
language-specific site to host their project under SVN.  They want to use
GitHub/Bitbucket/Google code/etc.  Dsource.org should just maintain a list
of packages for an installer -- say, like http://search.npmjs.org/.  That D
projects are hosted on a D-exclusive site tells me that D has a closed
community.

Yet D has a working module and package system, so a working package manager
should be a small task!


*# Community fragmentation*

Where is the D community?  I see:

http://www.digitalmars.com/d/ -- seems to be official
http://www.d-programming-language.org/ -- also seems to be official!

I would guess that d-programming-language.org is meant to deprecate the
digitalmars page, but there's no statement to that effect on either site.

There's a whole host of other sites that seem to have spawned, I guess
because whatever *is* the official center is unsatisfactory:

http://www.dprogramming.com/
http://www.dsource.org/
etc.

Some real effort has to go into rounding up the herd.  (The move to git and
GitHub is an excellent one in this regard.)


*# It's unsearchable!*

This one is really trivial.  There's an important reason that other
languages have squiffy names: searchability.  Googling for "d " is
useless, and "d language " is still awful.  Other languages that
suffer from the same affliction have the convention of appending "lang" as a
suffix -- "golang", for example -- and this works well.  It seems that
"dlang" has not caught on.  I see there's a site at http://dlang.org/ (yes,
yet another one!).  Whois says it's owned by http://oscarbrynolf.com/.  The
(seemingly recent?) move to GitHub and new website would have been a chance
to get this right.  Prepending "d programming language" to every search I
make is still absolutely horrible.


*# No marketing or brand awareness*

OK, I can live with this.  But make no mistake: it *does* seriously cut down
on the people migrating to it.  Take a look at the "free images" offered at
http://digitalmars.com/d/dlinks.html -- this is a marketers nightmare!  That
list *literally* makes me shudder.  I'm not saying that D requires another
generic Web 2.0 HTML5 look with gradients and rounded corners that one sees
on the latest fashionable projects.  I *am* saying that it needs something
consistent and clean, and currently it, seemingly willfully, has neither.
 (BTW, I've done some web design work before, e.g. http://hsk.org.uk/ -- I'd
be willing to help out.)

For comparative illustration:

http://python.org/ -- clean, no showiness.
http://www.ruby-lang.org/en/ -- a bit busy, but consistent.
http://golang.org/ -- very clean, well organized.
http://haskell.org/ 


The point I want to get across here is: the problem with the D programming
language *is not that there are problems with the D programming language.*
 The language and compiler (from what I know) have been world-class for 

Re: 64 bit DMD binary on the Mac

[Walter Bright]

On 6/28/2011 12:46 PM, Robert Clipsham wrote:

Of course the real solution for this one is to offer individual packages.


Even if we did for OSX, why have double the size with "universal binaries"?

Basically, I'm looking for a reason to have 32 bit dmd binaries for OSX.

Re: 64 bit DMD binary on the Mac

[Walter Bright]

On 6/28/2011 12:11 PM, KennyTM~ wrote:

With universal binary there's no need to worry about it anyway.


It's not what I'm asking, I'm asking if there is any reason at all to ship a 32 
bit dmd binary?

Re: 64 bit DMD binary on the Mac

[Robert Clipsham]

On 28/06/2011 20:39, Walter Bright wrote:

1. It cuts the testing time in half. This is a significant deal for me,
as adding another hour to the test cycle slows things down a lot.


Definitely worth investigating then!


2. It speeds downloading the dmd package.


Of course the real solution for this one is to offer individual 
packages. If you're on OS X, why on earth would you want binaries for 
Windows/Linux32/Linux64/FreeBSD and the libraries to go with them? And 
why would you want to download a large zip file when you can download a 
tarball and have it be a fraction of the size (and work just as well out 
of the box as a zip). Or even better a .dmg or .pkg.



The only reason to have a 32 bit binary is if there are x86 Macs 10.5 or
later that are incapable of running 64 bit code.


--
Robert
http://octarineparrot.com/

Re: 64 bit DMD binary on the Mac

[Jonathan M Davis]

On 2011-06-28 12:11, KennyTM~ wrote:
> On Jun 29, 11 02:43, Walter Bright wrote:
> > Although DMD on the Mac can currently only generate 32 bit binaries, the
> > Mac as I understand it can run 64 bit code.
> > 
> > Is there any reason that DMD itself should be a 32 bit app? Are there
> > any 32 bit only Macs out there we should support?
> 
> With universal binary there's no need to worry about it anyway. Just
> pass '-m32 -m64' to gcc. However, I see little reason making DMD itself
> a 64-bit executable.

For at least some of the same reasons that Linux users want a 64-bit dmd 
binary (though obviously not all, since the universal binary solves some of 
the distro-related problems). For instance, to make it less likely to run out 
of memory - particularly when you're using a lot of templates. Once dmd 
actually becomes smarter about handling memory, it won't be as big an issue, 
but at this point, it really isn't all that hard to get dmd to run out of 
memory on a 32-bit system.

- Jonathan M Davis

Re: 64 bit DMD binary on the Mac

[Walter Bright]

On 6/28/2011 12:13 PM, Jacob Carlborg wrote:

Since most of the applications and most the libraries (basically all that ships
with Mac OS X) are universal there's usually no problem of running/building both
32 and 64bit software.


I'll explain the motivation for 64 bit only DMD binaries:

1. It cuts the testing time in half. This is a significant deal for me, as 
adding another hour to the test cycle slows things down a lot.


2. It speeds downloading the dmd package.

The only reason to have a 32 bit binary is if there are x86 Macs 10.5 or later 
that are incapable of running 64 bit code.

Re: 64 bit DMD binary on the Mac

[Jacob Carlborg]

On 2011-06-28 20:53, Robert Clipsham wrote:

On 28/06/2011 19:43, Walter Bright wrote:

Although DMD on the Mac can currently only generate 32 bit binaries, the
Mac as I understand it can run 64 bit code.

Is there any reason that DMD itself should be a 32 bit app? Are there
any 32 bit only Macs out there we should support?


Standard practice is to use universal binaries, that is, having both the
64 bit and 32 bit binary in one eg:

$ file `which which`
/usr/bin/which: Mach-O universal binary with 3 architectures
/usr/bin/which (for architecture x86_64): Mach-O 64-bit executable x86_64
/usr/bin/which (for architecture i386): Mach-O executable i386
/usr/bin/which (for architecture ppc7400): Mach-O executable ppc

Although this will increase binary size, obviously. OS X then chooses
which version to use itself, with preference being the same order as
above (64, 32, ppc).

This said, I see no reason why you can't switch to a 64 bit binary, as
far as I'm aware all the intel hardware apple has shipped supports
running 64 bit applications. You may want to check this though.


Very few applications are 64bit on Mac OS X 10.5. Most of the 
applications are 64bit on Mac OS X 10.6. Although, as far as I 
understand it, quite few Macs actually run the kernel in 64bit (by 
default), if that matters.


Since most of the applications and most the libraries (basically all 
that ships with Mac OS X) are universal there's usually no problem of 
running/building both 32 and 64bit software.


I just had a look at this:

http://support.apple.com/kb/ht3696

Any Mac running Intel Core Solo or Intel Core Duo is 32bit only. 
Although it's hard to tell how many users that have a Mac with any of 
the above CPU's.


--
/Jacob Carlborg

Re: 64 bit DMD binary on the Mac

[KennyTM~]

On Jun 29, 11 02:43, Walter Bright wrote:

Although DMD on the Mac can currently only generate 32 bit binaries, the
Mac as I understand it can run 64 bit code.

Is there any reason that DMD itself should be a 32 bit app? Are there
any 32 bit only Macs out there we should support?


With universal binary there's no need to worry about it anyway. Just 
pass '-m32 -m64' to gcc. However, I see little reason making DMD itself 
a 64-bit executable.

Re: DDMD

[Jacob Carlborg]

On 2011-06-28 20:30, Nick Sabalausky wrote:

Unless Jacob Carlborg's already back on it, I've been temped to finish the
work he started on making it build on Linux (I had assumed that was
complete, but he told me there was still more to be done on that.)


When I stopped working on DDMD it was not working on Posix. There were 
some bugs that I couldn't get around (C++ symbol mangling IIRC), I think 
they all have been fixed now. If I recall there wasn't much left to get 
it to work, unless new bugs or other bugs hidden by the first ones show up.


I have no plans on working on DDMD any time soon.

--
/Jacob Carlborg

Re: 64 bit DMD binary on the Mac

[Robert Clipsham]

On 28/06/2011 19:43, Walter Bright wrote:

Although DMD on the Mac can currently only generate 32 bit binaries, the
Mac as I understand it can run 64 bit code.

Is there any reason that DMD itself should be a 32 bit app? Are there
any 32 bit only Macs out there we should support?


Standard practice is to use universal binaries, that is, having both the 
64 bit and 32 bit binary in one eg:


$ file `which which`
/usr/bin/which: Mach-O universal binary with 3 architectures
/usr/bin/which (for architecture x86_64):   Mach-O 64-bit executable 
x86_64

/usr/bin/which (for architecture i386): Mach-O executable i386
/usr/bin/which (for architecture ppc7400):  Mach-O executable ppc

Although this will increase binary size, obviously. OS X then chooses 
which version to use itself, with preference being the same order as 
above (64, 32, ppc).


This said, I see no reason why you can't switch to a 64 bit binary, as 
far as I'm aware all the intel hardware apple has shipped supports 
running 64 bit applications. You may want to check this though.


--
Robert
http://octarineparrot.com/

Re: DDMD

[Andrej Mitrovic]

On 6/28/11, Nick Sabalausky  wrote:
> I was thinking of doing that since I didn't see anyone else doing it, but I
> have a ton of other things keeping me plenty busy, so that'd be great if you
> could.

I don't have a lot of experience with DDMD/DMD since I'm new to its
codebase. But I do have some experience porting C/C++ code to D. I
don't think it would be too hard to figure out how to port the new
changes, since DDMD seems to keep an almost 1to1 representation of C++
and D code (well apart from a slightly different structure of its
modules).

But it's the scale of changes that is the biggest issue. I've got
plenty of free time so I can volunteer to give it a go.

Re: Article Contest

[Jacob Carlborg]

On 2011-06-28 14:15, Steven Schveighoffer wrote:

I just wanted to again thank Walter and Brad for holding/financing the
article contest. I received my iPad2 last week, and it is awesome! I
hope to write more articles (no contest required) about D to hopefully
entice more people into the D community.

Now I want to be able to write iOS apps in D :)

-Steve


I guess the first would be to get GDC/LDC working on ARM and the runtime 
as well. Then Michel Fortin has his fork of DMD with Objective-C 
interface (or what to call it). Of course, this would need to be ported 
to GDC/LDC as well. After that there's just Cocoa bindings left and then 
we're all set :)


--
/Jacob Carlborg

Re: thread.d "Unable to load thread context"

[Benjamin Thaut]

Am 28.06.2011 18:09, schrieb Sean Kelly:

Have you tried running the latest runtime from git?  I fixed a rather nasty 
threading bug since the last release that could be related.

Sent from my iPhone

On Jun 28, 2011, at 6:47 AM, Benjamin Thaut  wrote:


I'm my current project, which is a relatime 3d space shooter I'm using a lot of 
C libraries (SDL, OpenGL, OpenAL, SDL_Image, Assimp, etc.)
As the gc would take to much time when it runs only once in a while I'm 
performing a full collect after a frame has been rendered.
Now once in a while, sometimes after 30 seconds, sometimes after 20 minutes, the D 
runtime throws the "Unable to load thread context" exception. My debugger tells 
me that the main thread is currenlty performing a full collection when that happens.
A few other threads are waiting for single or multiple objects (on windows that 
is). A OpenGL thread runs the ntdll!ZwQueryInformationThread (I'm using a 
nvidia card so it's the nvidia OpenGL implementation) and one of my threads 
waits for a semaphore with a tryWait.

My application runs 3 thraeds.
-A main thread where the renderer runs in. This thread makes all the OpenGL 
calls.
-A extractor thread that extracts relevant data for the renderer from the game 
thread.
-The game thread that actually performs the game simulation. This thread makes 
calls to the OpenAL api.

Now I'm wondering why this happens. Is this connected to OpenGL?
Is it not a good idea to call the gc collect manually?
Isthe thread that is waiting for the semaphore the problem?

Any help would be appreciated.
--
Kind Regards
Benjamin Thaut


I just build dmd, druntime and phobos fromt the latest git revision (as 
druntime does not build with dmd 2.053). The game does build with it, 
but as soon as it starts a exception gets thrown in the GC which does 
not get cought by any of my catch blocks.

Maybe I did something wrong building dmd, is there a guide somewhere?

--
Kind Regards
Benjamin Thaut

64 bit DMD binary on the Mac

[Walter Bright]

Although DMD on the Mac can currently only generate 32 bit binaries, the Mac as 
I understand it can run 64 bit code.


Is there any reason that DMD itself should be a 32 bit app? Are there any 32 bit 
only Macs out there we should support?

Re: Optimization fuel

[Walter Bright]

On 6/28/2011 1:33 AM, Don wrote:

Historically, only about two bugs per year have been found in DMD's optimizer,


Being in continuous use for 25 yeras has a lot to do with that :-)

Re: DDMD

[Nick Sabalausky]

"Andrej Mitrovic"  wrote in message 
news:mailman.1253.1309231919.14074.digitalmar...@puremagic.com...
>
> But I don't know who is working on what? From posts around here I've
> seen a mention of someone overhauling DDMD to use the GC,

Yea, that's Denis Koroskin ("korDen"). From what I understand, he's the main 
guy behind DDMD. Although what he's doing, from what he described to me, is 
adding *a* GC to DDMD to clean up the leeks the ported frontend leaves 
behind (Ie, not the druntime GC).

> and Nick
> seems to work on his own code injection mechanism.

That's already in (and it's totally optional for anyone who doesn't like 
it). Although it's possible I may have missed a few classes I should have 
added it to...(Actually, I know I missed at least one, I'll have to check 
again to see what it was...something like "DIdent" or "Identifier" maybe?) 
It's a trivial change though. Just the same two little lines added to each 
affected module.

Unless Jacob Carlborg's already back on it, I've been temped to finish the 
work he started on making it build on Linux (I had assumed that was 
complete, but he told me there was still more to be done on that.)

> It seems like there
> will be duplicated work unless we all know who is doing what.
>

Yea, probably a good idea for us to take a poll on that.

> Me, I'd like to start doing diffs and slowly porting the old frontend
> to the newest one (2.053). But maybe someone is already doing that
> work.. hard to tell when there's no organization.

I was thinking of doing that since I didn't see anyone else doing it, but I 
have a ton of other things keeping me plenty busy, so that'd be great if you 
could. I don't know if anyone else is already working on it though (although 
the last pushes besides mine were 7 months ago, so I suspect not).

According to a quick look at the changeset page ( 
http://hg.dsource.org/projects/ddmd/ ), the other contributors to DDMD, 
besides me and Denis, are Trass3r, Eldar Insafutdinov, and Jacob Carlborg. 
To all of them: Are you currently working on anything in DDMD, and if so, 
what?  To all: Is there anyone else working on anything?

Re: thread.d "Unable to load thread context"

[Sean Kelly]

Have you tried running the latest runtime from git?  I fixed a rather nasty 
threading bug since the last release that could be related. 

Sent from my iPhone

On Jun 28, 2011, at 6:47 AM, Benjamin Thaut  wrote:

> I'm my current project, which is a relatime 3d space shooter I'm using a lot 
> of C libraries (SDL, OpenGL, OpenAL, SDL_Image, Assimp, etc.)
> As the gc would take to much time when it runs only once in a while I'm 
> performing a full collect after a frame has been rendered.
> Now once in a while, sometimes after 30 seconds, sometimes after 20 minutes, 
> the D runtime throws the "Unable to load thread context" exception. My 
> debugger tells me that the main thread is currenlty performing a full 
> collection when that happens.
> A few other threads are waiting for single or multiple objects (on windows 
> that is). A OpenGL thread runs the ntdll!ZwQueryInformationThread (I'm using 
> a nvidia card so it's the nvidia OpenGL implementation) and one of my threads 
> waits for a semaphore with a tryWait.
> 
> My application runs 3 thraeds.
> -A main thread where the renderer runs in. This thread makes all the OpenGL 
> calls.
> -A extractor thread that extracts relevant data for the renderer from the 
> game thread.
> -The game thread that actually performs the game simulation. This thread 
> makes calls to the OpenAL api.
> 
> Now I'm wondering why this happens. Is this connected to OpenGL?
> Is it not a good idea to call the gc collect manually?
> Isthe thread that is waiting for the semaphore the problem?
> 
> Any help would be appreciated.
> -- 
> Kind Regards
> Benjamin Thaut

Re: delegate cannot handle polymorphism?

[Nub Public]

On 6/28/2011 7:13 PM, Steven Schveighoffer wrote:

On Mon, 27 Jun 2011 22:23:32 -0400, Nub Public  wrote:



I have to disagree on this.
Member function pointers are useful in many event handling systems.
Imagine a signal and slot system. To register a member function as a
slot, the most direct and intuitive way is to take a member function
pointer. In c++0x and boost, ,  and related
libraries all work with member function pointers.

My premise is simple: a virtual function should always be resolved by
the dynamic identity of the object, regardless of whether it is called
directly or through a function pointer.


This can be had using delegates, but it's not straightforward, you need
to do a little bit of extra work.

For example, if you did this:

class A
{
final void callFoo() { foo(); }
void foo() {writeln("A");}
}

class B : A
{
void foo() {writeln("B");}
}

A delegate to callFoo would do polymorphism, even when you change the
context pointer (to a compatible instance).

Note that it is highly unusual to change anything about a delegate, as
type checking the context pointer is out the window. In fact, it is the
property of delegates which makes them so useful -- because you don't
have to care what the type of the context pointer is, the delegate's
type does not depend on it.


Perhaps the contextptr of D delegate cannot do this because it can
refer to the enclosing context besides an object. But I'd love it for
D to have the functionality of a truly polymorhic member function
pointer. Maybe the restrictions on the keyword "function" can be
relaxed to work with such a pointer?


The easiest thing to do is the suggestion from Michel Fortin -- create a
function/delegate that accepts the base type. This is much safer as
well. I would be highly suspect of code that alters any delegate
components.

-Steve



I see. Thank you.

Re: delegate cannot handle polymorphism?

[Nub Public]

On 6/28/2011 2:54 PM, foobar wrote:

== Quote from Nub Public (nubpub...@gmail.com)'s article

On 6/28/2011 1:29 AM, Timon Gehr wrote:

Nub Public wrote:

On 6/27/2011 7:08 PM, Michel Fortin wrote:

On 2011-06-27 03:30:09 -0400, Nub Public   said:


class BOn 6/27/2011 7:08 PM, Michel Fortin wrote:

On 2011-06-27 03:30:09 -0400, Nub Public   said:


class B
{
void fun() { writeln("B"); }
}

class D : B
{
override void fun() { writeln("D"); }
}

void delegate() dg =&b.fun;
dg.ptr = cast(void*)d;
dg();


Compiler: DMD 2.053
It prints "B" instead of "D".
The equivalent code in C++ prints "D" nicely.


C++ doesn't have delegates, and D doesn't have member function pointers.
Resolving virtual functions is done while you take its address in D,
while in C++ the member function pointer type contains holds the vtable
offset (or several in the case of multiple inheritance) which gets
resolved only when you call the function.

If you want the C++ behaviour, try using a delegate literal as a
trampoline that gets the object as a parameter to then call your function:

void delegate(B b) dg = (B b) { b.fun(); };

dg(d);




Thank you. That was very helpful.

What's the rational for this behavior though? Resolving the address of a
virtual function at compile time seems a little counter-intuitive to me.
I guess this way is slightly more efficient.


A delegate literal consists of a function pointer and a context pointer. There 
is
no polymorphism in that. A member function is a normal function you can take the
address of.

I see.

In general, you shouldn't update one of (ptr,funcptr) without updating the other
unless you have good reasons to do so and know exactly what you are doing.
Not having member pointers is AFAIK a direct consequence of the fact that nobody
uses them in C++ and almost nobody even knows that they exist.
Furthermore, their implementation is too involved, given their limited 
usefulness.

Cheers,
-Timon

I have to disagree on this.
Member function pointers are useful in many event handling systems.
Imagine a signal and slot system. To register a member function as a
slot, the most direct and intuitive way is to take a member function
pointer. In c++0x and boost,,  and related
libraries all work with member function pointers.
My premise is simple: a virtual function should always be resolved by
the dynamic identity of the object, regardless of whether it is called
directly or through a function pointer.
Perhaps the contextptr of D delegate cannot do this because it can refer
to the enclosing context besides an object. But I'd love it for D to
have the functionality of a truly polymorhic member function pointer.
Maybe the restrictions on the keyword "function" can be relaxed to work
with such a pointer?


The above premise is incorrect in that it compares to different concepts. A
delegate is a closure whereas a c++ member function pointer is not. This means 
it
captures the context in which the code was run. In the case of a method call, 
that
context would be the specific instance when the delegate was created hence it
cannot and should not be polymorphic.

Regarding signal/slot designs: see for example C#'s implementation - this is
incorporated into the language as "events" which are simply arrays of delegates.
Implementing this via member function pointers is actually the uncommon case 
since
most other languages use closures.



Thanks for the clarification.

thread.d "Unable to load thread context"

[Benjamin Thaut]

I'm my current project, which is a relatime 3d space shooter I'm using a 
lot of C libraries (SDL, OpenGL, OpenAL, SDL_Image, Assimp, etc.)
As the gc would take to much time when it runs only once in a while I'm 
performing a full collect after a frame has been rendered.
Now once in a while, sometimes after 30 seconds, sometimes after 20 
minutes, the D runtime throws the "Unable to load thread context" 
exception. My debugger tells me that the main thread is currenlty 
performing a full collection when that happens.
A few other threads are waiting for single or multiple objects (on 
windows that is). A OpenGL thread runs the 
ntdll!ZwQueryInformationThread (I'm using a nvidia card so it's the 
nvidia OpenGL implementation) and one of my threads waits for a 
semaphore with a tryWait.


My application runs 3 thraeds.
-A main thread where the renderer runs in. This thread makes all the 
OpenGL calls.
-A extractor thread that extracts relevant data for the renderer from 
the game thread.
-The game thread that actually performs the game simulation. This thread 
makes calls to the OpenAL api.


Now I'm wondering why this happens. Is this connected to OpenGL?
Is it not a good idea to call the gc collect manually?
Isthe thread that is waiting for the semaphore the problem?

Any help would be appreciated.
--
Kind Regards
Benjamin Thaut

Re: Article Contest

[Steven Schveighoffer]

On Tue, 28 Jun 2011 08:21:36 -0400, Robert Clipsham  
 wrote:



On 28/06/2011 13:15, Steven Schveighoffer wrote:

I just wanted to again thank Walter and Brad for holding/financing the
article contest. I received my iPad2 last week, and it is awesome! I
hope to write more articles (no contest required) about D to hopefully
entice more people into the D community.


Well done again, hope you're enjoying my iPad ;p


Well, you might get some satisfaction knowing that it's quickly becoming  
my wife's iPad :)


BTW, anyone who gets an iPad2, get a smart cover, it's extremely cool.   
OK, enough fanboyism...



Now I want to be able to write iOS apps in D :)


I'm about to start working on an iOs app again, really wish I could use  
D for it, Obj-C is horrible D; (Same applys for Android/Blackberry,  
Windows Mobile/Phone are just about bearable).


I very much want to do iOS development, but I don't have a Mac :(  or  
time...


Maybe some day.

-Steve

Re: Programming language benchmark

[Caligo]

Kind of off topic, but a good place to get benchmark results for many
of the programming languages is Sphere Online Judge:
http://www.spoj.pl/problems/classical/

They accept solutions in D, but not many have been submitted.  I found a few:

http://www.spoj.pl/ranks/FCTRL/lang=D
http://www.spoj.pl/ranks/HASHIT/lang=D
http://www.spoj.pl/ranks/ONP/lang=D

Most of the fastest solutions are in C++, but D is pretty close.
Maybe we could start submitting solutions :-)

Re: Article Contest

[Robert Clipsham]

On 28/06/2011 13:15, Steven Schveighoffer wrote:

I just wanted to again thank Walter and Brad for holding/financing the
article contest. I received my iPad2 last week, and it is awesome! I
hope to write more articles (no contest required) about D to hopefully
entice more people into the D community.


Well done again, hope you're enjoying my iPad ;p


Now I want to be able to write iOS apps in D :)


I'm about to start working on an iOs app again, really wish I could use 
D for it, Obj-C is horrible D; (Same applys for Android/Blackberry, 
Windows Mobile/Phone are just about bearable).



-Steve


--
Robert
http://octarineparrot.com/

Article Contest

[Steven Schveighoffer]

I just wanted to again thank Walter and Brad for holding/financing the  
article contest.  I received my iPad2 last week, and it is awesome!  I  
hope to write more articles (no contest required) about D to hopefully  
entice more people into the D community.


Now I want to be able to write iOS apps in D :)

-Steve

Re: About the new website

[Thomas Mader]

http://d.puremagic.com/issues/show_bug.cgi?id=6219

On Mon, Jun 27, 2011 at 6:54 PM, Jonathan M Davis wrote:

> On 2011-06-27 04:31, Thomas Mader wrote:
> > There is a small error on the index page.
>
> If you see any errors on the website, you should report them in bugzilla:
> d.puremagic.com/issues
>
> - Jonathan M Davis
>

Re: delegate cannot handle polymorphism?

[Steven Schveighoffer]

On Mon, 27 Jun 2011 22:23:32 -0400, Nub Public  wrote:



I have to disagree on this.
Member function pointers are useful in many event handling systems.  
Imagine a signal and slot system. To register a member function as a  
slot, the most direct and intuitive way is to take a member function  
pointer. In c++0x and boost, ,  and related  
libraries all work with member function pointers.


My premise is simple: a virtual function should always be resolved by  
the dynamic identity of the object, regardless of whether it is called  
directly or through a function pointer.


This can be had using delegates, but it's not straightforward, you need to  
do a little bit of extra work.


For example, if you did this:

class A
{
   final void callFoo() { foo(); }
   void foo() {writeln("A");}
}

class B : A
{
   void foo() {writeln("B");}
}

A delegate to callFoo would do polymorphism, even when you change the  
context pointer (to a compatible instance).


Note that it is highly unusual to change anything about a delegate, as  
type checking the context pointer is out the window.  In fact, it is the  
property of delegates which makes them so useful -- because you don't have  
to care what the type of the context pointer is, the delegate's type does  
not depend on it.


Perhaps the contextptr of D delegate cannot do this because it can refer  
to the enclosing context besides an object. But I'd love it for D to  
have the functionality of a truly polymorhic member function pointer.  
Maybe the restrictions on the keyword "function" can be relaxed to work  
with such a pointer?


The easiest thing to do is the suggestion from Michel Fortin -- create a  
function/delegate that accepts the base type.  This is much safer as  
well.  I would be highly suspect of code that alters any delegate  
components.


-Steve

Re: ZeroMQ & thrift

[David Nadlinger]

Hi filgood,

there seem to be some D bindings at the official size 
(http://www.zeromq.org/bindings:d, 
https://github.com/itiu/zeromq-connector), but as I haven't really used 
0mq so far, I can't judge in which state they are.


I currently don't have 0mq on my agenda for the GSoC project, but the 
basic functionality should be more or less trivial to implement 
yourself, see the contrib/zeromq directory in the Thrift source tree for 
examples. Be aware, however, that there is, to some extent, an impedance 
mismatch between Thrift and 0mq, as the latter is message-based, while 
Thrift generally assumes its transports to behave like streams. Due to 
this, there are some things which must be taken care of manually, like 
calling one-way RPC methods only on »one-way« (or however they are 
really called) 0mq connections.


Oh, and as for the state of the Thrift project, I regularly publish 
status updates at http://klickverbot.at/ (will post one for the last 
week later today, I was somehow thrown off the plan by getting a brain 
concussion from bumping against a door lintel – yeah, I didn't know that 
was possible either).


David


On 6/28/11 10:50 AM, filgood wrote:

Hi All,

I was wondering if anyone has created bindings for ZeroMQ? If so, could
you point me to these?

It seems possible to get thrift (the GSOC project) to run on top of
ZeroMQ...providing a very interesting packing togetherif there is
time left for the GSOC, it might be worth to explore this?

Thanks, filgood

Re: ZeroMQ & thrift

[filgood]

On 28/06/2011 09:50, filgood wrote:

Hi All,

I was wondering if anyone has created bindings for ZeroMQ? If so, could
you point me to these?

It seems possible to get thrift (the GSOC project) to run on top of
ZeroMQ...providing a very interesting packing togetherif there is
time left for the GSOC, it might be worth to explore this?


I ment if there is time left after thrift is implemented (I have no clue 
how far this GSOC project got so far)




Thanks, filgood

ZeroMQ & thrift

[filgood]

Hi All,

I was wondering if anyone has created bindings for ZeroMQ? If so, could 
you point me to these?


It seems possible to get thrift (the GSOC project) to run on top of 
ZeroMQ...providing a very interesting packing togetherif there is 
time left for the GSOC, it might be worth to explore this?


Thanks, filgood

Re: Optimization fuel

[Don]

bearophile wrote:

My experience about this stuff is zero, but is this idea useful to 
debug/improve DMD too?

http://blog.ezyang.com/2011/06/debugging-compilers-with-optimization-fuel/

Bye,
bearophile


In practice, it does pretty much the same job as CyberShadow's dustmite 
program, which is considerably more general.

https://github.com/CyberShadow/DustMite

Historically, only about two bugs per year have been found in DMD's 
optimizer, compared to >1000 bugs/year in the front end.