Cheers, I'll do that! I've still had nothing but trouble getting cygwin to
build the mips toolchain we were experimenting with. I don't know enough
about GCC and making it work >_<.
Although ideally a binary distribution would probably want to be
mingw/msys based.

On 6 December 2011 14:23, Iain Buclaw <ibuclaw@ubuntu.com> wrote:

> On 6 December 2011 10:27, Manu <turkeyman@gmail.com> wrote:
> >> Manu:
> >>
> >> > but I don't believe I'm alone.. the rest
> >> > of the gamedev community will find D soon enough if the language gets
> it
> >> > right...
> >>
> >> I think games are one of the most important short-term purposes of D, despite I think D was not explicitly designed to write games.
> >
> >
> > I agree, it certainly didn't seem to be a major consideration early on,
> but
> > I don't think any decisions yet made prohibit it from being well suited. If as you say, there is some focus to generate interest from the game community, it would be really nice to have a few binary GDC cross
> compiler
> > distributions available (for windows, linux users never have problems building the toolchain themselves). ARM/PPC, maybe MIPS toolchains hosted somewhere on the website might really help encourage some people get started, and I'd love to spend some time on the standard libraries for
> these
> > platforms.
> >
>
> If you ping me on IRC to get this moving, could put some time into setting up a toolchain for such purposes over the weekend. ie: such as a sript to set-up cross compiling from the current host to target B.
>
>
> --
> Iain Buclaw
>
> *(p < e ? p++ : p) = (c & 0x0f) + '0';
>

On 12/6/11 1:16 AM, Walter Bright wrote:
> On 12/5/2011 8:48 PM, Andrei Alexandrescu wrote:
>> On 12/5/11 10:15 PM, Walter Bright wrote:
>>> On 12/5/2011 8:10 PM, bearophile wrote:
>>>> This is not about integers but yeah, I'd like the better str<-> float
>>>> conversions of Python in D too.
>>>
>>> Do you have any test data that they actually are better in Python (apart
>>> from just being better specified)?
>>
>> I can tell Google's double-conversion routines (http://goo.gl/RU5g4)
>> are faster
>> than sprintf/sscanf, in addition to being better specified. We use
>> them at
>> Facebook.
>
> Darn, licensing problems:
>
> "Redistributions in binary form must reproduce the above copyright
> notice, this list of conditions and the following disclaimer in the
> documentation and/or other materials provided with the distribution."
>
> http://www.opensource.org/licenses/bsd-license.php

This is a general issue. Can it be overcome by distributing the text in the HTML documentation included with the download?

Andrei

On 12/6/11 1:20 AM, Walter Bright wrote:
> On 12/5/2011 10:52 PM, Don wrote:
>> On 06.12.2011 05:15, Walter Bright wrote:
>>> On 12/5/2011 8:10 PM, bearophile wrote:
>>>> This is not about integers but yeah, I'd like the better str<-> float
>>>> conversions of Python in D too.
>>>
>>> Do you have any test data that they actually are better in Python (apart
>>> from just being better specified)?
>>
>> Bug 5229 is an example.
>>
>> I have five papers on this topic. Most recent is the excellent:
>> Florian Loitsch, "Printing FP numbers quickly and accurately with
>> integers" (2010)
>
> Right now, we rely on C's standard library. Often, it's deficient. We
> should roll our own, like we did with the math routines, and make sure
> the D standard reflects the modern thinking on it.
>
> (Python's implementation currently uses David Gay's dtoa.c)

Translating dtoa.c to D and making sure it works during compilation sounds like a great project. People who want to help D in any way, please take notice :o).

Andrei

On 12/6/2011 9:11 AM, Andrei Alexandrescu wrote:
> On 12/6/11 1:16 AM, Walter Bright wrote:
>> On 12/5/2011 8:48 PM, Andrei Alexandrescu wrote:
>>> On 12/5/11 10:15 PM, Walter Bright wrote:
>> Darn, licensing problems:
>>
>> "Redistributions in binary form must reproduce the above copyright
>> notice, this list of conditions and the following disclaimer in the
>> documentation and/or other materials provided with the distribution."
>>
>> http://www.opensource.org/licenses/bsd-license.php
>
> This is a general issue. Can it be overcome by distributing the text in the HTML
> documentation included with the download?

Every customer who builds a program with D will have to have that notice somewhere in it. It's the old Tango problem.

On 12/6/2011 9:14 AM, Andrei Alexandrescu wrote:
> Translating dtoa.c to D and making sure it works during compilation sounds like
> a great project. People who want to help D in any way, please take notice :o).

Sadly, despite dtoa.c's wide use, there doesn't appear to be a test suite for it. I suppose we could email David Gay and ask.

On 12/6/11 6:14 PM, Andrei Alexandrescu wrote:
> On 12/6/11 1:20 AM, Walter Bright wrote:
>> (Python's implementation currently uses David Gay's dtoa.c)
>
> Translating dtoa.c to D and making sure it works during compilation
> sounds like a great project. People who want to help D in any way,
> please take notice :o).

Isn't there the same licensing problem with David Gay's code as well? »provided that this entire notice is included […] in all copies of the supporting documentation for such software.«

David

On Wed, 07 Dec 2011 04:11:40 +1100, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 12/6/11 1:16 AM, Walter Bright wrote:
>> On 12/5/2011 8:48 PM, Andrei Alexandrescu wrote:
>>> On 12/5/11 10:15 PM, Walter Bright wrote:
>>>> On 12/5/2011 8:10 PM, bearophile wrote:
>>>>> This is not about integers but yeah, I'd like the better str<-> float
>>>>> conversions of Python in D too.
>>>>
>>>> Do you have any test data that they actually are better in Python (apart
>>>> from just being better specified)?
>>>
>>> I can tell Google's double-conversion routines (http://goo.gl/RU5g4)
>>> are faster
>>> than sprintf/sscanf, in addition to being better specified. We use
>>> them at
>>> Facebook.
>>
>> Darn, licensing problems:
>>
>> "Redistributions in binary form must reproduce the above copyright
>> notice, this list of conditions and the following disclaimer in the
>> documentation and/or other materials provided with the distribution."
>>
>> http://www.opensource.org/licenses/bsd-license.php
>
> This is a general issue. Can it be overcome by distributing the text in the HTML documentation included with the download?

It's the "binary form" phrase that's a problem. Does it mean "executable form" rather than "text form", or "digital" rather than "hardcopy" form?

-- 
Derek Parnell
Melbourne, Australia

On 12/06/2011 09:49 AM, Walter Bright wrote:
> On 12/6/2011 9:14 AM, Andrei Alexandrescu wrote:
>> Translating dtoa.c to D and making sure it works during compilation
>> sounds like
>> a great project. People who want to help D in any way, please take
>> notice :o).
>
> Sadly, despite dtoa.c's wide use, there doesn't appear to be a test
> suite for it. I suppose we could email David Gay and ask.
>

Fuzz test it?

Feed it and the clone random data (after a archive of selected values) until they give different results or you get sick of waiting.

On 12/05/2011 11:20 PM, Don wrote:
> On 06.12.2011 05:21, bcs wrote:
>> On 12/05/2011 08:37 AM, Don wrote:
>>> On 05.12.2011 14:31, bearophile wrote:
>>>> Found through Reddit, two blog posts about how integers should behave
>>>> in system languages (with hardware support):
>>>>
>>>> http://blog.regehr.org/archives/641
>>>> http://blog.regehr.org/archives/642
>>>>
>>>> Bye,
>>>> bearophile
>>>
>>> Not very convincing, since he proposes a change to existing
>>> architectures, and seems completely unaware of the overflow flag.
>>
>> I think he's looking at it form the language theory standpoint. As such,
>> architectures has nothing to do with it (the architectures to be
>> targeted has yet to be defined at that point)and getting access to the
>> overflow flag would require exposing it natively in the language.
>
> It's not that he hasn't specified an architecture. It's a proposal which
> does not work on _any_ existing architectures!
> It's pure fantasy.

Well you can do it on x86. The fact the it doesn't provied hardware traps is irrelevant. You might need to add a lot of branches but you can get the semantics he is asking for.

That said, there is another interesting (but independent) question of can it be done efficiently? You might have a very good question there, but that isn't the question regehr is considering.

>
> And he talks about NaN, when he means infinity. Floating point overflow
> never results in a NaN.

You have a point there.

> He doesn't seem to know anything about
> saturating integer arithmetic, which exists in hardware (even x86
> machines have supported a couple of operations since 1996).
>
> Useless.

Again, he's not interested in the hardware implementation, he's only interested in the defined semantics of the language, the things you can count on regardless of that instruction set you are using. The fact the x86 has saturating integer operations is moot because C doesn't have a type the end up using them.

On 07.12.2011 05:11, bcs wrote:
> On 12/05/2011 11:20 PM, Don wrote:
>> On 06.12.2011 05:21, bcs wrote:
>>> On 12/05/2011 08:37 AM, Don wrote:
>>>> On 05.12.2011 14:31, bearophile wrote:
>>>>> Found through Reddit, two blog posts about how integers should behave
>>>>> in system languages (with hardware support):
>>>>>
>>>>> http://blog.regehr.org/archives/641
>>>>> http://blog.regehr.org/archives/642
>>>>>
>>>>> Bye,
>>>>> bearophile
>>>>
>>>> Not very convincing, since he proposes a change to existing
>>>> architectures, and seems completely unaware of the overflow flag.
>>>
>>> I think he's looking at it form the language theory standpoint. As such,
>>> architectures has nothing to do with it (the architectures to be
>>> targeted has yet to be defined at that point)and getting access to the
>>> overflow flag would require exposing it natively in the language.
>>
>> It's not that he hasn't specified an architecture. It's a proposal which
>> does not work on _any_ existing architectures!
>> It's pure fantasy.
>
> Well you can do it on x86. The fact the it doesn't provied hardware
> traps is irrelevant. You might need to add a lot of branches but you can
> get the semantics he is asking for.
>
> That said, there is another interesting (but independent) question of
> can it be done efficiently? You might have a very good question there,
> but that isn't the question regehr is considering.
>
>>
>> And he talks about NaN, when he means infinity. Floating point overflow
>> never results in a NaN.
>
> You have a point there.
>
>> He doesn't seem to know anything about
>> saturating integer arithmetic, which exists in hardware (even x86
>> machines have supported a couple of operations since 1996).
>>
>> Useless.
>
> Again, he's not interested in the hardware implementation, he's only
> interested in the defined semantics of the language, the things you can
> count on regardless of that instruction set you are using. The fact the
> x86 has saturating integer operations is moot because C doesn't have a
> type the end up using them.

He's talking about system languages. A system language has to have a close relationship to the architecture.

By contrast, if you don't care about performance, it's easy -- just use BigInts for everything. Problem solved.

Looks like I have to put it more bluntly: I don't think he knows what he's talking about. (On this particular topic).