On 11 December 2012 17:44, Walter Bright <newshound2@digitalmars.com> wrote:
> On 12/11/2012 5:37 AM, Iain Buclaw wrote:
>>
>> I foresee that this release will be the biggest pain in the ass to merge downstream into GDC. I wonder if David on LDC's side shares the same concern...
>
>
> Why?
>

If the last release was anything to go by - I think it was 4 months in development - there were quite a lot of changes that stepped on the toes of the GNU frontend code that required a few unexpected changes. eg; introduction of struct Obj. Plus the shear size of changes makes it a delicate task to make sure that anything pulled in does not remove any GDC-specific changes in D Frontend.

Maybe it's just me, but so far this has been 5 months in development, and the thought of working on a larger set of changes just seems to be an impending daunt over my head. :o)

It shouldn't be though, it should just be as simple as a replacing the old files with the new and done.  But that's something that should consider to work towards in the future.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 12/11/2012 12:08 AM, Denis Shelomovskij wrote:
> 11.12.2012 3:01, Walter Bright пишет:
>> On 12/10/2012 8:28 AM, Denis Shelomovskij wrote:
>>> This was the result of DustMite-ing my sources:
>>> http://d.puremagic.com/issues/show_bug.cgi?id=6296
>>>
>>> Currently the bug state is a bit confusing. It is a regression (but I
>>> didn't
>>> mark it that way, only write in description, sorry) but is resolved as a
>>> duplicate of a non-regression unfixed bug 4269. It was a small war
>>> between
>>> "regression" and "normal" state of 4269 and now it is marked as
>>> "normal".
>>
>>
>> It isn't a regression, and the test cases you reported work in D1 and D2.
>>
>
> How can I suppress DMD "abnormal program termination" pop-up when
> launched with "dmd ... 2>&1"?
>
> DustMite's code:
> https://github.com/CyberShadow/DustMite/wiki/Suppressing-DMD-crashes
> fails in this call: "FindWindowExA(h, null, "Button", "OK");"
>

Edit dmd with OllyDbg

cf

http://forum.dlang.org/thread/k1954u$lsq$1@digitalmars.com#post-k1lkbv:2421n7:241:40digitalmars.com

for the calls you're looking for

On Tuesday, 11 December 2012 at 13:37:16 UTC, Iain Buclaw wrote:
> I foresee that this release will be the biggest pain in the ass to
> merge downstream into GDC. I wonder if David on LDC's side shares the
> same concern...

I have been busy with getting LDC ready for the next release lately, so I didn't have a closer look at the state of things with regard to merging yet. However, it seems like Kai has already put together a patch which merges the frontend as it was a few days ago (see https://github.com/ldc-developers/ldc/wiki/Building-and-hacking-LDC-on-Windows-using-MSVC), so maybe he has any comments on this?

David

On 12/11/2012 2:20 PM, Iain Buclaw wrote:
> Maybe it's just me, but so far this has been 5 months in development,
> and the thought of working on a larger set of changes just seems to be
> an impending daunt over my head. :o)

The bulk of the work was bashing on the back end to get it to generate Win64 code that would work with VS, which should not affect GDC.

On Monday, 10 December 2012 at 23:47:49 UTC, Walter Bright wrote:
> On 12/10/2012 3:35 PM, Jonathan M Davis wrote:
>> On Monday, December 10, 2012 13:50:47 Walter Bright wrote:
>>> Why? (It's being heavily used by some people.)
>>
>> It hasn't even been properly worked out yet, and new features like that
>> shouldn't be being introduced in the main branch. It's not at all ready for
>> general consumption, and if it's in there, people are going to start using it
>> and then complaining when their code breaks when we change it later. It's the
>> sort of thing that should be on a separate branch and not in master. Even
>> worse, if the new stable branch that we've been talking about includes this,
>> then you'll have programmers programming with it for months before they get
>> the updates with the design that we're actually going to end up with, meaning
>> that that much more code will be written for that much longer with an
>> incomplete feature, waiting to be broken when the feature is actually updated
>> in the version of the compiler that they're using.
>
> We've debated this feature at length in various threads. It's under heavy use by some people. It does not break any existing code. I don't see any unresolved issue that should delay its incorporation.

It's still experimental and should be marked as such: it's just not ready for production. I can envision that in a few months, some people using it heavily will report that it's ugly and interacting badly with other features.

You just can't decide that such a feature is ready for production without having a feedback after several months of usage by several users.

On Tuesday, 11 December 2012 at 04:36:36 UTC, Walter Bright wrote:
> On 12/10/2012 8:21 PM, Walter Bright wrote:
>> Yes I understand that, and it is being extensively and heavily used since the
>> day I posted it, and no problems have arisen.
>
>
> I should also add that the design was based on extensive discussions about it here last summer.

Discussions are not enough. Issues and usage patterns only appear after several months of experience by several users. We need several months of experience before actually gaining any insight and feedback on such a feature.

On Wednesday, 12 December 2012 at 05:32:13 UTC, SomeDude wrote:
> On Tuesday, 11 December 2012 at 04:36:36 UTC, Walter Bright wrote:
>> On 12/10/2012 8:21 PM, Walter Bright wrote:
>>> Yes I understand that, and it is being extensively and heavily used since the
>>> day I posted it, and no problems have arisen.
>>
>>
>> I should also add that the design was based on extensive discussions about it here last summer.
>
> Discussions are not enough. Issues and usage patterns only appear after several months of experience by several users. We need several months of experience before actually gaining any insight and feedback on such a feature.

The root problem is that we have one branch for the unstable, testing, and stable code, and there's no possible way to make anyone happy with only that in place.

The chaotic clash between stableness and unstableness will go away once we have a well thought out development and release process put in place, and it should make everyone happy because it can allow for breaking new changes to be introduced into an unstable branch without messing up the next pre-release version, and updates to pre-release won't mess up the current stable branch because it only gets updated with bug fixes.

We're working on the new process here ...
http://forum.dlang.org/thread/ka5rv5$2k60$1@digitalmars.com

Please contribute your thoughts and time if you can, I think it'll be a very good investment for the future of D.

Thanks!

--rt

On Monday, 10 December 2012 at 00:34:33 UTC, Walter Bright wrote:
> It's time to do a release; to that end we should be working on tidying up the regressions.
>
> This will be the last official D1 release.

Just a heads up, GitHub has removed their Uploads feature[1].  Current uploads still work but this next release is going to need to either go back to the Digital Mars server like it was before or find a new home. I prefer the latter for speed reasons. Amazon S3 is fast and works well (it's what GitHub Uploads was backed by) and should be fairly affordable for the sizes we are talking about (I'd guess $3-4 per month).

http://docs.amazonwebservices.com/AmazonS3/latest/gsg/GetStartedWithS3.html



[1] https://github.com/blog/1302-goodbye-uploads

On 2012-12-12 18:29, Brad Anderson wrote:

> Just a heads up, GitHub has removed their Uploads feature[1].

That sucks :( . But thanks for the heads up.

-- 
/Jacob Carlborg

On 12 December 2012 17:29, Brad Anderson <eco@gnuk.net> wrote:
> On Monday, 10 December 2012 at 00:34:33 UTC, Walter Bright wrote:
>>
>> It's time to do a release; to that end we should be working on tidying up the regressions.
>>
>> This will be the last official D1 release.
>
>
> Just a heads up, GitHub has removed their Uploads feature[1].  Current uploads still work but this next release is going to need to either go back to the Digital Mars server like it was before or find a new home. I prefer the latter for speed reasons. Amazon S3 is fast and works well (it's what GitHub Uploads was backed by) and should be fairly affordable for the sizes we are talking about (I'd guess $3-4 per month).
>
> http://docs.amazonwebservices.com/AmazonS3/latest/gsg/GetStartedWithS3.html
>
>
>
> [1] https://github.com/blog/1302-goodbye-uploads

I can offer a server for that, hosted a datacentre in the UK.  If I recall correctly, the net link are behind a 100GB link, testing the net speed, I get 250MB/s upload speed to Europe, only 20MB/s upload to America though.


Regards,
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';