"Benjamin Herr" <ben@0x539.de> wrote in message news:ctt3uc$2l53$1@digitaldaemon.com...
> Anders F Björklund wrote:
> > Thomas Kuehne wrote:
> >> 4) no support for 64bit platforms
> >
> > Clearly a "bug" in the current implementation.
> > Or are you referring to actual API changes ?
>
> I tried changing the un-64bit-ish "ulong _d_newarray(...)" to return an Array struct (same size on 32bit platforms even) but it did not work - I think that the DMD generates code assuming that a scalar ulong is returned and not an aggregate type.

That doesn't work because, sadly, on linux structs are returned in a different way than ulongs are, even if they are the same size.

Walter wrote:
> "Benjamin Herr" <ben@0x539.de> wrote in message
> news:ctt3uc$2l53$1@digitaldaemon.com...
> 
>>Anders F Björklund wrote:
>>
>>>Thomas Kuehne wrote:
>>>
>>>>4) no support for 64bit platforms
>>>
>>>Clearly a "bug" in the current implementation.
>>>Or are you referring to actual API changes ?
>>
>>I tried changing the un-64bit-ish "ulong _d_newarray(...)" to return an
>>Array struct (same size on 32bit platforms even) but it did not work - I
>>think that the DMD generates code assuming that a scalar ulong is
>>returned and not an aggregate type.
> 
> 
> That doesn't work because, sadly, on linux structs are returned in a
> different way than ulongs are, even if they are the same size.

What can I do about it?

"Anders F Björklund" <afb@algonet.se> wrote in message news:ctsmf6$25t5$2@digitaldaemon.com...
> Matthew wrote:
>
>> Maybe I'm a total dunce, but your post seems to contain no information.
>
> It's the local trend (see the D release announcements)...
>
> You're supposed to follow the hyperlink for any info.

Then it's a daft one. Who's got the time to be following any and
all links when given no information about what jewels (or
lumps of coke) might lurk there. More likely that people'll only
be motivated to write one what-the-hell-are-you-on-about post.
This being that. ;)

"Benjamin Herr" <ben@0x539.de> wrote in message news:ctu3da$mvk$1@digitaldaemon.com...
> Walter wrote:
> > "Benjamin Herr" <ben@0x539.de> wrote in message news:ctt3uc$2l53$1@digitaldaemon.com...
> >
> >>Anders F Björklund wrote:
> >>
> >>>Thomas Kuehne wrote:
> >>>
> >>>>4) no support for 64bit platforms
> >>>
> >>>Clearly a "bug" in the current implementation.
> >>>Or are you referring to actual API changes ?
> >>
> >>I tried changing the un-64bit-ish "ulong _d_newarray(...)" to return an Array struct (same size on 32bit platforms even) but it did not work - I think that the DMD generates code assuming that a scalar ulong is returned and not an aggregate type.
> >
> >
> > That doesn't work because, sadly, on linux structs are returned in a different way than ulongs are, even if they are the same size.
>
> What can I do about it?

For 64 bits? I wouldn't bother. All the stuff in internal.* isn't meant to be called by user code, it operates hand-in-glove with the compiler, and the compiler generates the calls to it. Therefore, what to do about it rests on the decisions the person doing a 64 bit compiler needs to make.

Thomas Kuehne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Anders F Björklund wrote:
>>> The aim of D round robin is to unlock D's potential and of course
>>> having fun.
>>> Everybody is encouraged to take part - be it with hunting Big Bugs,
>>> writing core libraries or toying with D source code.
>>
>>     Why we need yet another Phobos is beyond me.
> 
> Already running Phobos replacement projects aren't barred.
> 
> Basically there are several issues with the current Phobos:
<snip>

Not to mention:

5. std.date is somewhat inadequate - see

http://www.digitalmars.com/drn-bin/wwwnews?D/27490
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/2365
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/5405

(Yes, I'm still working on writing something to the spec that eventually came out of the last of these.  I've just had other things on my mind.)

6. Some things are just randomly missing, like a function to copy files.

Stewart.

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

Stewart Gordon wrote:

>>>     Why we need yet another Phobos is beyond me.
>>
>> Already running Phobos replacement projects aren't barred.
>> Basically there are several issues with the current Phobos:
> 
> Not to mention:
> 
> 5. std.date is somewhat inadequate - see
> 
> http://www.digitalmars.com/drn-bin/wwwnews?D/27490
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/2365
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/5405
> 
> (Yes, I'm still working on writing something to the spec that eventually came out of the last of these.  I've just had other things on my mind.)
> 
> 6. Some things are just randomly missing, like a function to copy files.

Still, why does a few bugs in the library warrant a new one ?

Isn't it easier to "just" fix the holes in Phobos instead ?
Such as the missing copyFile function, or missing Exceptions.


I know that some have written OOP "alternatives" already,
which is OK since Phobos isn't object-oriented (by design)

But having multiple versions of basic std functions ? Uggg.
(having multiple basic object wrappers is problem enough)


The missing license issues and the DMD/Phobos separation definitely
needs addressing, as well as the more obvious bugs and shortcomings.

Another interesting question is whether 64-bit support will be in 1.0 ?
Since it's in the language already, I think it should be in the lib too.


I'm just afraid that the alternative runtime libraries are mostly a
reaction to the slow turnabout time to get bugs fixed, and the unclear
licensing issues on existing code and what happens to new contributions.
(lack of a bug database also seems to have "lost" a few bugs / patches)
The apparent lack of Phobos coding standard is also somewhat confusing,
as the style is right now very dependant on the author of the module...

--anders