On 14.12.2011 21:32, torhu wrote:
> On 14.12.2011 14:05, Gour wrote:
>> On Wed, 14 Dec 2011 11:15:58 +0100
>> Jacob Carlborg<doob@me.com> wrote:
>>
>>> I don't know if all of them are successful but important: Tango, DWT,
>>> Minid, Orange,
>>
>> Not to say those are not important, but there are, afaict, falling in
>> the category of D1's ecosystem, not end-user apps.
>>
>> Otoh Tango is ported to D2, Minid has moved to Croc, while DWT& Orange
>> have D2 ports.
>
> DWT for D2 is not in a usable state yet. I'd assume the same goes for
> Tango.

Why is it not ? I am using it regularly. Ok it is broken now since the new release... but b4

On 14.12.2011 23:19, torhu wrote:
> On 14.12.2011 22:26, Andrej Mitrovic wrote:
>> On 12/14/11, torhu<no@spam.invalid> wrote:
>>> DWT for D2 is not in a usable state yet.
>>
>> It has a few build issues but most samples work. I've never used it
>> for any projects yet though.
>
> It doesn't work for much besides the samples.

thats plain wrong

> http://store.steampowered.com/app/18600/?snr=1_200_200_254_13

does anybody know if and when how this game makes use of the steamworks framework, which is a c++ library provided by valve for using the steam game services. the only solution would be to write a plain c wrapper around it, right?

On Thursday, 15 December 2011 at 10:37:00 UTC, Mirko Pilger wrote:
>> http://store.steampowered.com/app/18600/?snr=1_200_200_254_13
>
> does anybody know if and when how this game makes use of the steamworks framework, which is a c++ library provided by valve for using the steam game services. the only solution would be to write a plain c wrapper around it, right?

Have a look at Open Steamworks. It's a C API which returns interfaces, similar to DirectX APIs. These are easily usable from both C (structs with function pointers) and C++ (classes with pure-virtual functions).

Regarding some things said by Walter in this Reddit thread: http://www.reddit.com/r/programming/comments/nbndg/fedora_17_will_include_support_for_the_d/

>I should add that the XMM register support is for 64 bit targets, and also the register allocator will enregister float and double variables in XMM registers.<

Will DMD use 8 XMM registers in 32 bit code too?


>Putting the compiler in D would make it difficult to integrate the D front end into the C/C++ back ends of gcc and llvm.<

Writing the reference front-end in D has some advantages:
- Other people have lot of C/C++ code; if they want to use D they will probably want to interface C/C++ with D code. So writing the compiler front-end in D is a way to eat some of the D dog food, and see/test how much good such interfacing is, and eventually it's a push to improve it.
- It's a way to eat some D dog food in general, because a compiler front-end is a medium-sized project that requires some performance. If some parts of the D2 language are badly designed or they lead to low performance (like fixed sized array assignment) this is a good way to spot such problems and a way to push to fix them.
- I have now understood that if you want a safe & reliable language you need a reliable compiler too. Because a very safe and very well designed language produces buggy and unsafe programs if the compiler is buggy. Writing the front-end in D allows to avoid several compiler bugs from the beginning.
- Writing the front-end in D is probably going to speed up a bit the development of the D compiler, with more expressiveness, less code, more readable code, less bug-prone code, etc.

Bye,
bearophile

On 12/15/2011 03:33 PM, bearophile wrote:
> Regarding some things said by Walter in this Reddit thread:
> http://www.reddit.com/r/programming/comments/nbndg/fedora_17_will_include_support_for_the_d/
>
>> I should add that the XMM register support is for 64 bit targets, and also the register allocator will enregister float and double variables in XMM registers.<
>
> Will DMD use 8 XMM registers in 32 bit code too?
>
>
>> Putting the compiler in D would make it difficult to integrate the D front end into the C/C++ back ends of gcc and llvm.<
>
> Writing the reference front-end in D has some advantages:
> - Other people have lot of C/C++ code; if they want to use D they will probably want to interface C/C++ with D code. So writing the compiler front-end in D is a way to eat some of the D dog food, and see/test how much good such interfacing is, and eventually it's a push to improve it.

I agree.

> - It's a way to eat some D dog food in general, because a compiler front-end is a medium-sized project that requires some performance. If some parts of the D2 language are badly designed or they lead to low performance (like fixed sized array assignment) this is a good way to spot such problems and a way to push to fix them.

The only performance problem is the GC, and that could just be turned off (as DMD handles it ;)). Fixed array assignment certainly won't cause any trouble.

> - I have now understood that if you want a safe&  reliable language you need a reliable compiler too. Because a very safe and very well designed language produces buggy and unsafe programs if the compiler is buggy. Writing the front-end in D allows to avoid several compiler bugs from the beginning.
> - Writing the front-end in D is probably going to speed up a bit the development of the D compiler, with more expressiveness, less code, more readable code, less bug-prone code, etc.

Exactly. But that front-end needs to be written from scratch.

>
> Bye,
> bearophile

On 12/15/2011 03:33 PM, bearophile wrote:
> Regarding some things said by Walter in this Reddit thread:
> http://www.reddit.com/r/programming/comments/nbndg/fedora_17_will_include_support_for_the_d/
>
>> I should add that the XMM register support is for 64 bit targets, and also the register allocator will enregister float and double variables in XMM registers.<
>
> Will DMD use 8 XMM registers in 32 bit code too?
>

An issue is that 32 bit x86 architectures do not necessarily provide any SSE support. GCC will not use XMM registers by default either.

On Thu, 15 Dec 2011 10:37:58 +0100
Stephan <spam@extrawurst.org> wrote:

> Why is it not ? I am using it regularly. Ok it is broken now since the new release... but b4

How are you, in general, satisfied with DWT2?

How it compares with qt/wx/gtk+ ?


Sincerely,
Gour


-- 
As the embodied soul continuously passes, in this body, from boyhood to youth to old age, the soul similarly passes into another body at death. A sober person is not bewildered by such a change.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

Timon Gehr:

> Fixed array assignment certainly won't cause any trouble.<

I don't know about the D front end, but those arrays have caused performance problems in my D2 code. Later I have taken more care, assigning items one after the other, writing:

int[3] a = void;
a[0] = ...
a[1] = ...
a[2] = ...

Instead of:
int[3] a = [..., ..., ...];


> An issue is that 32 bit x86 architectures do not necessarily provide any SSE support.

Most PCs have SSE2 support. Lot of PCs today have SSE3 too.


> GCC will not use XMM registers by default either.

LLVM-GCC (and probably Clang too) use SSE registers on default on 32 bit Windows. And with modern GCC-MinGW I usually compile code with those registers too on 32 bit Windows, using the right compiler switches.

Bye,
bearophile

On 12/15/2011 04:37 PM, bearophile wrote:
> Timon Gehr:
>
>> Fixed array assignment certainly won't cause any trouble.<
>
> I don't know about the D front end, but those arrays have caused performance problems in my D2 code. Later I have taken more care, assigning items one after the other, writing:
>
> int[3] a = void;
> a[0] = ...
> a[1] = ...
> a[2] = ...
>
> Instead of:
> int[3] a = [..., ..., ...];
>

I usually use:

    static _a = [1, 2, 3];
    int[3] a = _a;

This certainly should be fixed, what I wanted to say is, there are not many fixed size arrays in a compiler front-end.

>
>> An issue is that 32 bit x86 architectures do not necessarily provide any SSE support.
>
> Most PCs have SSE2 support. Lot of PCs today have SSE3 too.
>
>
>> GCC will not use XMM registers by default either.
>
> LLVM-GCC (and probably Clang too) use SSE registers on default on 32 bit Windows. And with modern GCC-MinGW I usually compile code with those registers too on 32 bit Windows, using the right compiler switches.
>