December 15, 2011 Re: D1 to be discontinued on December 31, 2012 | ||||
---|---|---|---|---|
| ||||
Posted in reply to torhu | 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
|
December 15, 2011 Re: D1 to be discontinued on December 31, 2012 | ||||
---|---|---|---|---|
| ||||
Posted in reply to torhu | 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
|
December 15, 2011 Re: D1 to be discontinued on December 31, 2012 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jesse Phillips | > 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?
|
December 15, 2011 Re: D1 to be discontinued on December 31, 2012 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mirko Pilger | 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).
|
December 15, 2011 Re: D1 to be discontinued on December 31, 2012 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don | 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 |
December 15, 2011 Re: D1 to be discontinued on December 31, 2012 | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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 |
December 15, 2011 Re: D1 to be discontinued on December 31, 2012 | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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.
|
December 15, 2011 Re: D1 to be discontinued on December 31, 2012 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stephan Attachments: | 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 |
December 15, 2011 Re: D1 to be discontinued on December 31, 2012 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | 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 |
December 15, 2011 Re: D1 to be discontinued on December 31, 2012 | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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. > |
Copyright © 1999-2021 by the D Language Foundation