Focus is on fixing compiler issues, especially the bugs introduced with 0.120.

http://www.digitalmars.com/d/changelog.html

In article <d3pc4b$19cp$1@digitaldaemon.com>, Walter says...
>
>Focus is on fixing compiler issues, especially the bugs introduced with 0.120.

Phobos already has a file "ti_delegate.d" with a class named "TypeInfo_D" in it, while .121 defines a new class "TypeInfo_Delegate" in "object.d."  Is one of these classes misnamed, or is one defunct?


Sean

In article <d3pc4b$19cp$1@digitaldaemon.com>, Walter says...
>
>Focus is on fixing compiler issues, especially the bugs introduced with 0.120.

Oops, and a related question.  Phobos already had a file called "ti_ptr.d" with a class named "TypeInfo_P" in it.  This seems to conflict with the new TypeInfo_Pointer.  Which one is defunct?


Sean

In article <d3pc4b$19cp$1@digitaldaemon.com>, Walter says...
>
>Focus is on fixing compiler issues, especially the bugs introduced with 0.120.

Same with "ti_C.d" class name "TypeInfo_C" for "TypeInfo_Class."

I'm going to back off on moving to .121 for now.  I'm not sure what to update.


Sean

"Sean Kelly" <sean@f4.ca> wrote in message news:d3pk26$1fai$1@digitaldaemon.com...
> In article <d3pc4b$19cp$1@digitaldaemon.com>, Walter says...
> >
> >Focus is on fixing compiler issues, especially the bugs introduced with 0.120.
>
> Same with "ti_C.d" class name "TypeInfo_C" for "TypeInfo_Class."

Replying to all your posts, yes, they are both needed.

In article <d3pn80$1hu9$1@digitaldaemon.com>, Walter says...
>
>"Sean Kelly" <sean@f4.ca> wrote in message news:d3pk26$1fai$1@digitaldaemon.com...
>> In article <d3pc4b$19cp$1@digitaldaemon.com>, Walter says...
>> >
>> >Focus is on fixing compiler issues, especially the bugs introduced with 0.120.
>>
>> Same with "ti_C.d" class name "TypeInfo_C" for "TypeInfo_Class."
>
>Replying to all your posts, yes, they are both needed.

Thanks.  Are they both for the same type?  The implementation for these pairs of classes seems almost identical in each case.


Sean

"Sean Kelly" <sean@f4.ca> wrote in message news:d3poe7$1im2$1@digitaldaemon.com...
> In article <d3pn80$1hu9$1@digitaldaemon.com>, Walter says...
> >
> >"Sean Kelly" <sean@f4.ca> wrote in message news:d3pk26$1fai$1@digitaldaemon.com...
> >> In article <d3pc4b$19cp$1@digitaldaemon.com>, Walter says...
> >> >
> >> >Focus is on fixing compiler issues, especially the bugs introduced
with
> >> >0.120.
> >>
> >> Same with "ti_C.d" class name "TypeInfo_C" for "TypeInfo_Class."
> >
> >Replying to all your posts, yes, they are both needed.
>
> Thanks.  Are they both for the same type?  The implementation for these
pairs of
> classes seems almost identical in each case.

One is generic, the other isn't. I'll probably try to merge the two.

"Walter" <newshound@digitalmars.com> wrote in message news:d3pc4b$19cp$1@digitaldaemon.com...
> Focus is on fixing compiler issues, especially the bugs introduced with 0.120.
>
> http://www.digitalmars.com/d/changelog.html

ah, you sneaky devil. You started messing with the Exception inheritence tree! Do you have plans for the rest? :-)

"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d3psac$1kr7$1@digitaldaemon.com...
> ah, you sneaky devil. You started messing with the Exception inheritence tree! Do you have plans for the rest? :-)

Well, SysError really was embarassingly bad. I have no other plans on it at the moment.

"Walter" <newshound@digitalmars.com> wrote in message news:d3q02q$1nad$1@digitaldaemon.com...
>
> "Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d3psac$1kr7$1@digitaldaemon.com...
>> ah, you sneaky devil. You started messing with the Exception inheritence tree! Do you have plans for the rest? :-)
>
> Well, SysError really was embarassingly bad. I have no other plans on it
> at
> the moment.

ok. I have a silly question about SysError, though. The code in dmd-120 had hard-coded strings that mapped the same input error codes to the same strings on all platforms. Like you say that won't work since the error codes aren't the same on different platforms. But why can't SysError on linux call strerror? The error codes fed to the function are platform-dependent and the resulting string is platform-dependent but the purpose of the function (map a platform-dependent error code to a platform-dependent string) is platform-independent. So off the top of my head I'd think a linux version using strerror would be ok.