J C Calvarese wrote:
<snip>
> If you don't like Core32, you might prefer Y Tomino's efforts:
> http://hp.vector.co.jp/authors/VA028375/d/windows.h.html

None of them cut it.  But I have Tomino's version and I'm kind of working on cleaning it up.

<snip>
> I suspect that part of the reason for this is that the newness of D attracts people that like to try new things. (Note that I said "try".) As D has been maturing there have been some growing pains. It can be annoying when you write code for DMD 0.65 and have to patch it for DMD 0.69 (and then it needs patching again for DMD 0.74). If you're like and don't produce code that fast, it's easy to fall off the upgrade treadmill. It's discouraging to spend more time

Yes, there is still this issue.  But once 1.0 comes out it'll've stabilised a bit.

> With D's current relative maturity, that's less of a problem, but some people from the early days may still be burned out. Personally, I haven't been writing much code recently.
> 
> And, besides, wxD isn't vaporware and DWT just produced a "Hello, World", so the sky's the limit. :)

At least SDWF hasn't died down development-wise since it started.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on on the 'group where everyone may benefit.

> - I perceive a lack of interest among the D developer community.  I
see lots
> of started projects, but few completed ones, and little progress in
the
> meantime.  I can only assume *something* turned off these people who
gave D
> a shot, and this increases my perceived risk around D.

Good point.  Although not at all due to lack of interest.

I've the instigator/developer for one dSource project, a completely separate SourceForge D project, and another completely separate project to which I'm trying to recruit people to help work on "real soon now"

... all more or less on the backburner waiting D maturity

... and I consider myself a D zealot who eagerly looks forward to better debugger support and gui lib(s) .. which are getting better all the time.

... and could probably benefit from some focus <g>

I've been aware of D for some time ... the way it seems to work out is that several times a year, I pick up where I left off 3-4 months previously, get frustrated, and put a "to-do" reminder in my calendar to check back in 3-4 months.

Getting about due, I suppose. Probably overdue. I'm noticing some very positive info about gui libs

Anders F Björklund wrote:
> Brad Anderson wrote:
> 
>> I understand that the ebuild works.  However, it's not in Portage.
> 
> 
> That's up to "politics", and the Gentoo maintainers...
> 
> I just showed how to actually install the software. :-)
> 
> --anders

I appreciate that, and was in fact aware of this already. Thanks to whoever set up that ebuild.

However, it really needs to be in Portage. I like to know that all the software on my system is updated when I type "emerge sync && emerge world -vuDa". I know, I'm being lazy, but I'm hesitant to adopt any software not easily available through Portage.

If there are still some political issues stopping DMD from being put into Portage I would like to see them resolved. Is there anything I can do to help?

--Daniel Siegmann

> No, I don't believe it's currently 1.0 in that I
> wouldn't seriously
> recommend to my boss that we start using it.

At first reading, this seems reasonable ...

but when I try to think of ANY version 1.0 development tool that I could have "seriously recommended to my boss", I can't come up with any. Nada.

Version numbering seems more conservative in the Linux world, but the "rule of thumb" was to NEVER have an important project be dependent on version 1.0 software. That had the potential to be a "career shortening move".

So perhaps that's not a valid criteria?

To me, version 1.0 declares, "Early Adapters: Proceed With Caution"

FWIW: I vote to release as 1.0 RC-1 (release candidate)

Daniel Siegmann wrote:
> If there are still some political issues stopping DMD from being put
> into Portage I would like to see them resolved. Is there anything I can
> do to help?

Aren't the packages in Portage mostly Production level?

Meaning, you don't usually risk breaking something with "unnecessarily updating"?

Currently that is not the case with D, IMHO.

What's the politics on that issue?

Georg Wrede wrote:
> Aren't the packages in Portage mostly Production level?
> 
> Meaning, you don't usually risk breaking something with "unnecessarily updating"?
> 
> Currently that is not the case with D, IMHO.
> 
> What's the politics on that issue?

Portage can contain more than just stable software because ebuilds (even newer versions of the same program) can be masked. Masked ebuilds will not be considered available for the user unless the user specifically unmasks them (requires one entry in one file).

There are two ways to mask a program: place it under the unstable keyword (i.e. ~x86, instead of x86), or hard mask it. Some people may run their system using all ~arch software, but it's not recommended.

Different versions of a program can have different masks. Often packages will end up in ~arch first for testing, and then be moved to arch once any bugs are worked out.

DMD is fairly stable - at least, it's not about to destroy anyone's system (I hope), and it's not like there's a more stable version. So stick it in ~x86 to start with, but I do think it should be in x86.

For comparison, I believe Phoenix was originally stuck in ~x86, but was available even as far back as 0.6 (possibly earlier). However, it ended up in x86 before 1.0.

I'm a big fan of Portage - it's the #1 reason why I use Gentoo. :) Hence I prefer that all the software on my system is managed by it.

Daniel Siegmann wrote:

> If there are still some political issues stopping DMD from being put
> into Portage I would like to see them resolved. Is there anything I can
> do to help?

There were a couple of earlier issues stopping DMD:

1) The DMD zipfiles were not being versioned
   (they are now, example being dmd.119.zip)

2) The license was not known to the Portage system
   (added to the gentoo bug, as LICENSE="DMD")

3) The license does not permit any re-distribution
   (the ebuild is now flagged RESTRICT="nomirror")

4) Man pages were not included in the DMD archive
   (they are now, after some lobbying)

5) The Makefile (linux.mak) lacks a "make install"
   (currently using a ugly workaround)

None of these should stop it from entering ~x86 now ?

--anders

PS. http://bugs.gentoo.org/show_bug.cgi?id=46806