December 15, 2011
On 12/14/2011 4:32 PM, Jakob Bornecrantz wrote:
> In short it can be answered with the questions "Can you
> guarantee it work?"

A guarantee would be something like you paid $x for it and I would refund your $x if you weren't completely satisfied (which I often do for Digital Mars C++ and other paid products). But I don't see how I could offer a guarantee on a free product where I have no control over your satisfaction.


> and "Can I justify the amount of work I have
> to put in for the gain?",

That's something only you can answer.


> the thing is I have a had a lot of
> problems with D1 toolchain, I have fixed or worked around these
> issues and I'm wondering if I have to work around those or other
> again. I am currently supporting 3 platforms (Mac, Linux &
> Windows), so that factors in as well (me having fixed some
> issues on Mac for D1).

I can ask:

1. Are these issues all reported in Bugzilla?
2. Are your fixes also supplied to Bugzilla?

With (1), I then will know about the issues, and myself or one of the many contributors can supply a fix. With (2), I can incorporate your fixes into the official toolchain so it will never darken anyone else's doorstep again.


> My current code base is 40Kloc's where about 8Kloc of those
> are library bindings, on top of that it also includes a couple
> of C projects sources (expat, lua and some other misc
> libraries). So I would have to convert all that code to D2 and
> also fix any issues that might arise from that conversion.
> That said I think that it would mostly running the code
> through dmd2 and just fix any cases where it complains. But it
> probably wouldn't be a trivial amount of work.

I don't know how much work that would be. I will say that 40Kloc is not a huge base of code, as these things go. I don't think you'll have to do anything with the C code or other non-D sources.


> I don't use Phobos that much in my code so I wont have to
> change much code with that regards, then again I don't see much
> value of the new Phobos since there isn't much new there for me.
> In fact I sort of have a philosophical disagreement with the
> boost/templet-ification of it and the language in general.

That's fair, but it's also something that could be a separate, wide-ranging discussion.

> Also in the beginning when I was using D1 and it moved much
> more faster I would often find myself having to work around
> or change various parts of the program due to new bugs or
> features. I think D2 is much better in the bug department then
> D1 was so that isn't much of a issue, but its still not really
> stable and its more work for me.

I understand the pain that breaking changes cause, and have pushed hard to stop a few that I felt the minor gains on did not justify the disruption.


> That said there are a couple of features that if they where
> implemented in D2 would encourage me to switch.
>
> One of the biggest problem right now is that I can't build
> my project on Windows and is forced to cross compile it with GDC
> from Linux. This stems from me having a mixed C & D project and
> not getting the various compilers to get along (Both DMD & DMC
> and GDC & GCC, would either not compile or produce broken
> binaries). So making DMD work with the mingw toolchain on
> Windows would be really appreciated (COFF support right?).

I cannot help with this without knowing what the specific problems are.


> Improvements to the GC, I'm currently having to thread lightly
> around various issues with the GC, again its works currently so
> I don't want to work around it again. Adopting a two step
> approach employed by GObject would might help.
> http://developer.gnome.org/gobject/stable/gobject-memory.html
>
>
> All said and done, knowing what I know today I would probably
> not do the project in D1, but I have thrown my dice and I'm
> "stuck" (not used strongly here, I still like a lot of D), but
> I'm not sure I would want to go through all that pain again
> with D2. As Andrie have said D has a tendency to come unglued
> when you start to do advanced thing, and the language dies a
> death of a thousand paper-cuts (and some knife stabs).

You don't have to write advanced code using D2. You can still write "C style" code with it, and even "D1 style" code in it.


> I do appreciate the work you have put into D over the years,
> I just don't want to have meaningless battles with language/-
> compiler bugs. I hope this message is useful for you.

It is, but I really do need more detail as outlined above.
December 15, 2011
On Wednesday, December 14, 2011 18:10:12 Walter Bright wrote:
> On 12/14/2011 4:32 PM, Jakob Bornecrantz wrote:
> > One of the biggest problem right now is that I can't build
> > my project on Windows and is forced to cross compile it with GDC
> > from Linux. This stems from me having a mixed C & D project and
> > not getting the various compilers to get along (Both DMD & DMC
> > and GDC & GCC, would either not compile or produce broken
> > binaries). So making DMD work with the mingw toolchain on
> > Windows would be really appreciated (COFF support right?).
> 
> I cannot help with this without knowing what the specific problems are.

It sounds like the chief problem is the fact that dmd and dmc aren't compatible with the object file format that pretty much every other compiler on Windows uses. It's probably _the_ biggest complaint of the folks trying to use C with D on Windows.

- Jonathan M Davis
December 15, 2011
On Thu, 15 Dec 2011 01:32:35 +0100, Jakob Bornecrantz wrote:

> My current code base is 40Kloc's where about 8Kloc of those are library bindings, on top of that it also includes a couple of C projects sources (expat, lua and some other misc libraries). So I would have to convert all that code to D2 and also fix any issues that might arise from that conversion.

Hello Jakob,

While I can't give any specific answers to your questions I will say that I"ve actually gone to the effort of porting some libraries, I where I wasn't familiar with the codebase (yes I've gotten things wrong), DFL and most recently Juno.

Such efforts were not a great effort. cloc reports about 36k loc for Juno. One thing I did when I made these changes was that I committed similar changes in one commit (some missed though). I considered writing a lessons learned from this, but its extra time. You can check out the commits from Nov 6 to get an idea of what goes into a conversion.

https://github.com/he-the-great/Juno-Windows-Class-Library/commits/master? page=2
December 15, 2011
On Thursday, 15 December 2011 at 02:10:09 UTC, Walter Bright wrote:
> On 12/14/2011 4:32 PM, Jakob Bornecrantz wrote:
>> In short it can be answered with the questions "Can you
>> guarantee it work?"
>
> A guarantee would be something like you paid $x for it and I would refund your $x if you weren't completely satisfied (which I often do for Digital Mars C++ and other paid products). But I don't see how I could offer a guarantee on a free product where I have no control over your satisfaction.
>
>
>> and "Can I justify the amount of work I have
>> to put in for the gain?",
>
> That's something only you can answer.

Not the answer I was expecting for the first question, but it ultimately turned out to be the same, "you or anybody else can't, and neither can I." The point is I have something that works now moving to something new means risks and having to learn new things which ultimately ends up meaning time spent on other things then driving the project forward. I do realize there are some similarities with this argument and your argument for discontinuing D1 support, so I can't argue those reasons.

So the way I see it now, is there are some minor risks involved
and a upfront investment of time to convert the code, for no
real gain. Tho std.concurrency is looking pretty neat.

>> the thing is I have a had a lot of
>> problems with D1 toolchain, I have fixed or worked around these
>> issues and I'm wondering if I have to work around those or other
>> again. I am currently supporting 3 platforms (Mac, Linux &
>> Windows), so that factors in as well (me having fixed some
>> issues on Mac for D1).
>
> I can ask:
>
> 1. Are these issues all reported in Bugzilla?
> 2. Are your fixes also supplied to Bugzilla?
>
> With (1), I then will know about the issues, and myself or one of the many contributors can supply a fix. With (2), I can incorporate your fixes into the official toolchain so it will never darken anyone else's doorstep again.

The issues I have ran into long ago, I'm pretty sure I haven't filed bugs about, sorry about that. The Mac platform issues I have: filed bugs for or reported me too's, generated pull requests, which have been pulled. So they are all resolved.

I think that my biggest fear is running into new bugs that I will have to waste a day or so of productivity on.

>> My current code base is 40Kloc's where about 8Kloc of those
>> are library bindings, on top of that it also includes a couple
>> of C projects sources (expat, lua and some other misc
>> libraries). So I would have to convert all that code to D2 and
>> also fix any issues that might arise from that conversion.
>> That said I think that it would mostly running the code
>> through dmd2 and just fix any cases where it complains. But it
>> probably wouldn't be a trivial amount of work.
>
> I don't know how much work that would be. I will say that 40Kloc is not a huge base of code, as these things go. I don't think you'll have to do anything with the C code or other non-D sources.

My point was it would not be a non-trivial amount of work. You are of course correct that the non-D code would be left alone.

>> I don't use Phobos that much in my code so I wont have to
>> change much code with that regards, then again I don't see much
>> value of the new Phobos since there isn't much new there for me.
>> In fact I sort of have a philosophical disagreement with the
>> boost/templet-ification of it and the language in general.
>
> That's fair, but it's also something that could be a separate, wide-ranging discussion.
>
>> Also in the beginning when I was using D1 and it moved much
>> more faster I would often find myself having to work around
>> or change various parts of the program due to new bugs or
>> features. I think D2 is much better in the bug department then
>> D1 was so that isn't much of a issue, but its still not really
>> stable and its more work for me.
>
> I understand the pain that breaking changes cause, and have pushed hard to stop a few that I felt the minor gains on did not justify the disruption.
>
>
>> That said there are a couple of features that if they where
>> implemented in D2 would encourage me to switch.
>>
>> One of the biggest problem right now is that I can't build
>> my project on Windows and is forced to cross compile it with GDC
>> from Linux. This stems from me having a mixed C & D project and
>> not getting the various compilers to get along (Both DMD & DMC
>> and GDC & GCC, would either not compile or produce broken
>> binaries). So making DMD work with the mingw toolchain on
>> Windows would be really appreciated (COFF support right?).
>
> I cannot help with this without knowing what the specific problems are.

I can try and spend some time on this again. But the last time I tried I got random crashes inside the graphics driver with DMD & DMC while the same code cross compiled worked just fine. That was after a long day fighting various other versions of mingw-gdc trying to get it to work. I have to admit I at that point gave up. I know this is not ideal, sorry about that.

That said it might all work if I move to D2 and it might not, so there is that to factor into things as well.

>> Improvements to the GC, I'm currently having to thread lightly
>> around various issues with the GC, again its works currently so
>> I don't want to work around it again. Adopting a two step
>> approach employed by GObject would might help.
>> http://developer.gnome.org/gobject/stable/gobject-memory.html
>>
>>
>> All said and done, knowing what I know today I would probably
>> not do the project in D1, but I have thrown my dice and I'm
>> "stuck" (not used strongly here, I still like a lot of D), but
>> I'm not sure I would want to go through all that pain again
>> with D2. As Andrie have said D has a tendency to come unglued
>> when you start to do advanced thing, and the language dies a
>> death of a thousand paper-cuts (and some knife stabs).
>
> You don't have to write advanced code using D2. You can still write "C style" code with it, and even "D1 style" code in it.

C style code is mostly what I have been doing anyways. I think the point I was trying to make is that D2 has the same unglued problem as D1. It might be different set of problems, but probably the same. That said C and C++ has its own set of problems and you just learn to work around those. If they differ from D1 to D2 I would have to relearn those.

That said I do have some advanced code in there, mostly relating to resource management, the code itself isn't, but writing it was a uphill battle against the GC. But I'm doing things not allowed, accessing objects from the dtor of a object. Those problems could be solved with the two step approach outlined by the link above.

>> I do appreciate the work you have put into D over the years,
>> I just don't want to have meaningless battles with language/-
>> compiler bugs. I hope this message is useful for you.
>
> It is, but I really do need more detail as outlined above.

I have tried to explain, I think my biggest concern is having to waste time for no gain.


December 15, 2011
On Thursday, 15 December 2011 at 03:19:47 UTC, Jesse Phillips wrote:
> On Thu, 15 Dec 2011 01:32:35 +0100, Jakob Bornecrantz wrote:
>
>> My current code base is 40Kloc's where about 8Kloc of those are library
>> bindings, on top of that it also includes a couple of C projects sources
>> (expat, lua and some other misc libraries). So I would have to convert
>> all that code to D2 and also fix any issues that might arise from that
>> conversion.
>
> Hello Jakob,
>
> While I can't give any specific answers to your questions I will say that I"ve actually gone to the effort of porting some libraries, I where I wasn't familiar with the codebase (yes I've gotten things wrong), DFL and most recently Juno.
>
> Such efforts were not a great effort. cloc reports about 36k loc for Juno. One thing I did when I made these changes was that I committed similar changes in one commit (some missed though). I considered writing a lessons learned from this, but its extra time. You can check out the commits from Nov 6 to get an idea of what goes into a conversion.
>
> https://github.com/he-the-great/Juno-Windows-Class-Library/commits/master?page=2

Thanks, those are encouraging words, I'm having a bit of problems figuring out the commits, but that was just after a quick glance. Doing a quick writeup would be most appreciated, by me or anybody who is going to convert.

Cheers, Jakob.


December 15, 2011
On 12/14/2011 8:55 PM, Jakob Bornecrantz wrote:
> So the way I see it now, is there are some minor risks involved
> and a upfront investment of time to convert the code, for no
> real gain.

The gain would be in taking advantage of the D2 capabilities for the future work on your code.


> The Mac platform issues I have: filed bugs for or reported me
> too's, generated pull requests, which have been pulled. So they are all resolved.

Good.

> I think that my biggest fear is running into new bugs that I will have to waste
> a day or so of productivity on.

This is true of any product - I recently spent some time tracking down a gcc codegen bug on the mac.
December 15, 2011
On Thu, 15 Dec 2011 05:58:01 +0100, Jakob Bornecrantz wrote:

> Thanks, those are encouraging words, I'm having a bit of problems
> figuring out the commits, but that was just after a quick glance.
> Doing a quick writeup would be most appreciated, by me or anybody who is
> going to convert.
> 
> Cheers, Jakob.

Yes, I realize the commits by themselves are hard to understand, and even worse when you don't know how D2 operates.
December 15, 2011
On 2011-12-14 20:34, Nick Sabalausky wrote:
> "Jacob Carlborg"<doob@me.com>  wrote in message
> news:jc9u6j$ebc$1@digitalmars.com...
>> On 2011-12-14 10:56, Walter Bright wrote:
>>> On 12/14/2011 12:45 AM, Jacob Carlborg wrote:
>>>> The few times I've contributed to the compiler I've sent a patch or a
>>>> pull
>>>> request and the end result is that nothing happens. If I'm lucky I get
>>>> a few
>>>> comments, I answer them and then nothing.
>>>
>>> There's currently one open dmd pull request from you. Any others you've
>>> done have been incorporated.
>>
>> Yeah and what happened to that. I got a few comments about the tests
>> failing, but they ended up being a misunderstanding.
>>
>> The same thing happened recently with my attempt of fixing dynamic
>> libraries. It always feel like I'm ending with a question I never get an
>> answer to.
>>
>
> I don't mean this as an attack on Tango or any of the Tango people, but
> FWIW, that's how I usually feel about Tango's support. It seems like most of
> my Tango questions on the msg board go unanswered or maybe just partially
> answered, whereas on Phobos2 I always get quick help from the NG.

There's not much activity in the forums, that have happened to me as well. But when it comes to patches they are usually applied pretty fast.

-- 
/Jacob Carlborg
December 15, 2011
"Jesse Phillips" <jessekphillips+D@gmail.com> wrote in message news:20111214160926.00007dcb@unknown...
> On Wed, 14 Dec 2011 10:46:18 +0100
> Gour <gour@atmarama.net> wrote:
>
>> Can you give me a list of some successful open-source projects written in D1 and/or some proprietary ones?
>
> http://store.steampowered.com/app/18600/?snr=1_200_200_254_13 http://en.wikipedia.org/wiki/ABA_Games

A lot of the ABA Games stuff was actually from before the days of D1, like v0.xxx. For whatever that's worth. (Just random trivia I guess...)


December 15, 2011
"Nick Sabalausky" <a@a.a> wrote in message news:jcc9d8$2bo5$1@digitalmars.com...
> "Jesse Phillips" <jessekphillips+D@gmail.com> wrote in message news:20111214160926.00007dcb@unknown...
>> On Wed, 14 Dec 2011 10:46:18 +0100
>> Gour <gour@atmarama.net> wrote:
>>
>>> Can you give me a list of some successful open-source projects written in D1 and/or some proprietary ones?
>>
>> http://store.steampowered.com/app/18600/?snr=1_200_200_254_13 http://en.wikipedia.org/wiki/ABA_Games
>
> A lot of the ABA Games stuff was actually from before the days of D1, like v0.xxx. For whatever that's worth. (Just random trivia I guess...)

Nevermind. I should read the other replies before posting :)