December 20, 2012
12.12.2012 5:36, Ellery Newcomer пишет:
> 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

Thanks, it helped. I managed to reduce (in "1 day, 1 hour, 44 minutes, 43 secs, and 125 ms" as DustMite said) and fill
http://d.puremagic.com/issues/show_bug.cgi?id=9189

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
December 20, 2012
On Mon, 10 Dec 2012 09:56:44 +0100, Denis Shelomovskij <verylonglogin.reg@gmail.com> wrote:

> 10.12.2012 4:33, Walter Bright пишет:
>> 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.
>
> Sorry, but I have never understand how can anybody call D stable and why are you doing all this "support".
>
>
> Let me explain:
>
> A long time ago I wrote one (not open source) application in D1+Tango.
> I'm still supporting it. The last D1 compiler I can use is 1.066 as then a fatal regression was introduced and templates became unusable because of ICE. Am I the only one who use templates in D1? If not, what is the purpose for all this needless D1 releases as compiler doesn't work for almost any project with templates?
>

We have our whole infrastructure in D1 and tango and currentl are using dmd 1.075 for
compilation. We don't have any major problems with templates (just a few dmd hickups every now and then).


>
> And let me beat utterly:
>
> Now imagine: a person updated a compiler and get ICE. On *huge* codebase. What will he do? He will use old working one. But I decided to go further, found a DustMite and decided to find the source of the error. Do you know that current D2 compiler ICE-s with compiling DustMite? Imagine, what will feel a person when bug finding tool ICE-s a compiler? He will probably consider "D is a peace of unstable shit" and go away.
>
> And he will be right as it is unforgivable for us to talk about any "stability" of D. "D is for crazy nerd who are ready to find, report and workaround infinite compiler bugs on any complicated code with templates", that's all we can tell.
>
> But I finally managed to compile DustMite without ICE, found the regression and reported. Still unfixed...
>

What you say is partly true, work around and such, but it isn't as bad as you
describe it above. We have big projects and the still work.

    --Marenz

--
Mathias Baumann
Research and Development

sociomantic labs GmbH
Paul-Linke-Ufer 39/40
10999 Berlin

http://www.sociomantic.com

Fon:       +49 (0)30 3087 4615
Fax:       +49 (0)30 3087 4619
Skype:         Mathias Baumann (m4renz)
Irc:           irc://irc.freenode.net User Marenz or Suprano
-----------------------------------------------------------

sociomantic labs GmbH, Location: Berlin
Commercial Register - AG Charlottenburg: HRB 121302 B
VAT No. - USt-ID: DE 266262100
Managing Directors: Thomas Nicolai, Thomas Brandhoff
December 22, 2012
On Friday, 14 December 2012 at 00:42:58 UTC, Walter Bright wrote:
> On 12/13/2012 4:17 PM, David Nadlinger wrote:
>> 1. How much work would it be for the guys at Remedy Games to convert their
>> codebase from [] to @()?
>
> I don't know. All I know is it's a lot of code.

You should ask. It's really crazy to ask the WHOLE community to take the bullet for some company using an experimental unreleased version of the compiler without even knowing if there is a good reason why they can't just fix their code.

And in any case, this is theirs problem, they should be using a special version of the compiler (the one that accepts broken code), not all the rest!

This is just completely crazy...

>> 3. Why is the message you introduced a warning instead of a normal deprecation
>> error?
>
> Because skipping the warning phase has historically been too abrupt for people.

Oh, lord. And then you can't see why deprecation as warnings should have existed in the first place and why it shouldn't be the default...

>> versions, can't they just use a patched version until they have made the switch?
>
> Like any major user of a language, they want confidence in our full support of them. Asking them to use a patched or branch version of the compiler does not inspire confidence.

Yeah, introducing broken unconsulted features to the language and then wanting to keep backwards compatibility for them does inspire a lot of confidence.

Seriously Walter, you're doing it all backwards...

> What I'm doing is hardly unique in business history. When Boeing designed the 707, they showed the prototype to Pan Am,
[...]

And no, your nice stories about Boing doesn't help here, get over it, you're dealing with an opensource project now, not with an internal project of an aeronaval industry.

> Ok, we're not Boeing or Westinghouse. But we have an opportunity to go big time, and I'm not going to let that get away from us.

This is extremely lame unless you present a good case for Remedy Games. Just saying "they have a lot of code" isn't good enough.
December 22, 2012
On 22 December 2012 19:32, Leandro Lucarella < leandro.lucarella@sociomantic.com> wrote:

> On Friday, 14 December 2012 at 00:42:58 UTC, Walter Bright wrote:
>
>> On 12/13/2012 4:17 PM, David Nadlinger wrote:
>>
>>> 1. How much work would it be for the guys at Remedy Games to convert
>>> their
>>> codebase from [] to @()?
>>>
>>
>> I don't know. All I know is it's a lot of code.
>>
>
> You should ask. It's really crazy to ask the WHOLE community to take the bullet for some company using an experimental unreleased version of the compiler without even knowing if there is a good reason why they can't just fix their code.
>
> And in any case, this is theirs problem, they should be using a special version of the compiler (the one that accepts broken code), not all the rest!
>
> This is just completely crazy...
>


This.


-- 
Iain Buclaw

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


December 23, 2012
On Saturday, 22 December 2012 at 23:37:03 UTC, Iain Buclaw wrote:
> On 22 December 2012 19:32, Leandro Lucarella <
> leandro.lucarella@sociomantic.com> wrote:
>
>> On Friday, 14 December 2012 at 00:42:58 UTC, Walter Bright wrote:
>>
>>> On 12/13/2012 4:17 PM, David Nadlinger wrote:
>>>
>>>> 1. How much work would it be for the guys at Remedy Games to convert
>>>> their
>>>> codebase from [] to @()?
>>>>
>>>
>>> I don't know. All I know is it's a lot of code.
>>>
>>
>> You should ask. It's really crazy to ask the WHOLE community to take the
>> bullet for some company using an experimental unreleased version of the
>> compiler without even knowing if there is a good reason why they can't just
>> fix their code.
>>
>> And in any case, this is theirs problem, they should be using a special
>> version of the compiler (the one that accepts broken code), not all the
>> rest!
>>
>> This is just completely crazy...
>>
>
>
> This.

Surely someone like Walter or yourself (I am not suggesting that it's your responsibility) could have written a reliable find and replace for the other attribute syntax, fixed Remedy's codebase and allowed everyone to move on?
December 23, 2012
On 23 December 2012 00:11, ixid <nuaccount@gmail.com> wrote:

> On Saturday, 22 December 2012 at 23:37:03 UTC, Iain Buclaw wrote:
>
>> On 22 December 2012 19:32, Leandro Lucarella < leandro.lucarella@sociomantic.**com <leandro.lucarella@sociomantic.com>> wrote:
>>
>>  On Friday, 14 December 2012 at 00:42:58 UTC, Walter Bright wrote:
>>>
>>>  On 12/13/2012 4:17 PM, David Nadlinger wrote:
>>>>
>>>>  1. How much work would it be for the guys at Remedy Games to convert
>>>>> their
>>>>> codebase from [] to @()?
>>>>>
>>>>>
>>>> I don't know. All I know is it's a lot of code.
>>>>
>>>>
>>> You should ask. It's really crazy to ask the WHOLE community to take the
>>> bullet for some company using an experimental unreleased version of the
>>> compiler without even knowing if there is a good reason why they can't
>>> just
>>> fix their code.
>>>
>>> And in any case, this is theirs problem, they should be using a special version of the compiler (the one that accepts broken code), not all the rest!
>>>
>>> This is just completely crazy...
>>>
>>>
>>
>> This.
>>
>
> Surely someone like Walter or yourself (I am not suggesting that it's your responsibility) could have written a reliable find and replace for the other attribute syntax, fixed Remedy's codebase and allowed everyone to move on?
>


Yes, but using sed to find and replace code is fraught with dangers and should be avoided with a large stick.

-- 
Iain Buclaw

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


December 23, 2012
On 12/23/2012 01:29 AM, Iain Buclaw wrote:
> On 23 December 2012 00:11, ixid <nuaccount@gmail.com
> <mailto:nuaccount@gmail.com>> wrote:
>...
>
>
>     Surely someone like Walter or yourself (I am not suggesting that
>     it's your responsibility) could have written a reliable find and
>     replace for the other attribute syntax, fixed Remedy's codebase and
>     allowed everyone to move on?
>
>
>
> Yes, but using sed to find and replace code is fraught with dangers and
> should be avoided with a large stick.
>
> --
> Iain Buclaw
>
> *(p < e ? p++ : p) = (c & 0x0f) + '0';

I guess he meant a tool based on the compiler front end.
December 23, 2012
On Sat, 2012-12-22 at 20:32 +0100, Leandro Lucarella wrote:
> On Friday, 14 December 2012 at 00:42:58 UTC, Walter Bright wrote:
> > On 12/13/2012 4:17 PM, David Nadlinger wrote:
> >> 1. How much work would it be for the guys at Remedy Games to
> >> convert their
> >> codebase from [] to @()?
> >
> > I don't know. All I know is it's a lot of code.
> 
> You should ask. It's really crazy to ask the WHOLE community to take the bullet for some company using an experimental unreleased version of the compiler without even knowing if there is a good reason why they can't just fix their code.
> 
> And in any case, this is theirs problem, they should be using a special version of the compiler (the one that accepts broken code), not all the rest!
> 
> This is just completely crazy...

Is it really being suggested that the undefined needs of a single organization that neither owns the language and code, nor pays the salaries of the committers, determine the evolution of a FOSS languages?

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


December 24, 2012
On Friday, 14 December 2012 at 03:40:05 UTC, Jonathan M Davis wrote:
> On Thursday, December 13, 2012 22:19:18 Andrei Alexandrescu wrote:
>> On 12/13/12 8:55 PM, kenji hara wrote:
>> > I think we should have -future/-f switch and @future attribute.
>> > It is a rough idea, but seems a required compiler feature.
>> > 
>> > Kenji Hara
>> 
>> That sounds interesting.
>
> I believe that python has something similar.

It does, but in Python they are only for breaking changes (for example when a new keyword is added, first you have to use form __future__import feature). Is kind of the reverse of deprecated. Also __future__ in Python is not really for experimental features, is for final ones, and present only to easy the migration (again, same as deprecated).

If the idea is to enable experimental features, I would name this -experimental rather than -future, which makes much clearer that you're on your own if you use that flag.

>> Regarding attributes, a simple solution is to release it but without
>> official documentation. We place the documentation in a /unstable/
>> directory of the website, distinct from the central mainstream
>> documentation.
>> 
>> People who already started or want to start using attributes understand
>> there are instabilities associated with them. Existing code is
>> unaffected, only certain programs that are technically invalid will
>> actually compile and run.
>> 
>> Works?

Only if you don't set this new experimental features in stone if some company have the crazy idea of start using it ;-)

> Yes. And attributes may not actually need much more work, but adding new,
> essentially untested features into the language and releasing them doesn't
> jive well with the recent push to stabilize and avoid breaking any code,
> because such features will frequently need changes which will break code.
> Hopefully, the adjustments to the release process that are being discussed
> will fix this sort of problem long term, but it comes across like Walter is
> willing to throw new features in but then generally refuses to change things
> which break code, which risks us being stuck with features that aren't quite
> what they could be or should be. The situation with UDAs definitely highlights
> the need to adjust our release process.

Yes, to be honest, I don't think adding experimental features to what is supposed to be a stable compiler is a great idea. I think the best option is to add an experimental branch and add new features there. Having a nightly snapshot build of this experimental branch should be enough to encourage people to play with it making extremely clear that there are no warranties about the stability of that compiler, or on the continuation of new features there.
4 5 6 7 8 9 10 11 12 13 14
Next ›   Last »