www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - 2.060 on reddit

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
... with a few stats. Vote up!

http://www.reddit.com/r/programming/comments/xm5y0/d_260_released_d_programming_language/


Andrei
Aug 03 2012
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 03 Aug 2012 11:31:27 -0400
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 ... with a few stats. Vote up!
 
 http://www.reddit.com/r/programming/comments/xm5y0/d_260_released_d_programming_language/
 
 
 Andrei

Wow, that's much more positive towards D than Reddit used to be. Used to be much more mixed.
Aug 03 2012
prev sibling next sibling parent reply Caligo <iteronvexor gmail.com> writes:
When are allocators going to be ready?

On Fri, Aug 3, 2012 at 10:31 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 ... with a few stats. Vote up!

 http://www.reddit.com/r/programming/comments/xm5y0/d_260_released_d_programming_language/


 Andrei

Aug 03 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-08-03 21:44, bearophile wrote:

 Direct experience shows me that once things are in Phobos, it's not easy
 to fix their interface/API. Andrei fears of breaking changes, so even
 small API improvements of Phobos stuff written last year are refused.
 See as example:

One option would be to create a new set of containers, in a new module. These can basically be copies of the original containers with their API's adapted to support custom allocators. It's not pretty but it won't break any code. -- /Jacob Carlborg
Aug 03 2012
prev sibling parent reply Stefan Scholl <stesch no-spoon.de> writes:
bearophile <bearophileHUGS lycos.com> wrote:
 Caligo:
 When are allocators going to be ready?

Direct experience shows me that once things are in Phobos, it's not easy to fix their interface/API. Andrei fears of breaking

Go's solution are experimental packages. You can always use them, but you know that they will change and at some time will be in antother namespace/directory.
Aug 03 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 04-08-2012 04:42, Jonathan M Davis wrote:
 On Saturday, August 04, 2012 02:37:07 Stefan Scholl wrote:
 bearophile <bearophileHUGS lycos.com> wrote:
 Caligo:
 When are allocators going to be ready?

Direct experience shows me that once things are in Phobos, it's not easy to fix their interface/API. Andrei fears of breaking

Go's solution are experimental packages. You can always use them, but you know that they will change and at some time will be in antother namespace/directory.

It's been discussed a time or two that we should have an incubator project for Phobos where potential Phobos modules go to be used and ironed out before actually being reviewed for inclusion in Phobos. But it's never materialized. Someone(s) would have to organize it and manage it, and no one has done so. - Jonathan M Davis

I thought this was the idea of etc.* all along... If nobody's against it, we should definitely get the ball rolling. -- Alex Rønne Petersen alex lycus.org http://lycus.org
Aug 03 2012
parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 04-08-2012 04:57, Jonathan M Davis wrote:
 On Saturday, August 04, 2012 04:44:12 Alex Rønne Petersen wrote:
 It's been discussed a time or two that we should have an incubator project
 for Phobos where potential Phobos modules go to be used and ironed out
 before actually being reviewed for inclusion in Phobos. But it's never
 materialized. Someone(s) would have to organize it and manage it, and no
 one has done so.

 - Jonathan M Davis

I thought this was the idea of etc.* all along...

Someone may have suggested that at some point, but that's not the way that it's used at all.

Well: http://dlang.org/phobos/index.html "etc This is the root of a hierarchy of modules mirroring the std hierarchy. Modules in etc are not standard D modules. They are here because they are experimental, or for some other reason are not quite suitable for std, although they are still useful."
 If nobody's against it, we should definitely get the ball rolling.

I don't think that anyone's really against it, and it's not like it really needs to be official. The Phobos review process can be the same that it's been. There would just be a place for future Phobos stuff to be publicly tinkered with and allowed to evolve through usage rather than just designing everything up front as has often been the case with Phobos modules. The problem is that someone actually needs to step up and make it happen.

Well, what actually needs to be done? When can something be submitted for etc.* rather than std.*? Etc...
 - Jonathan M Davis

-- Alex Rønne Petersen alex lycus.org http://lycus.org
Aug 04 2012
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 04.08.2012 04:42, schrieb Jonathan M Davis:
 On Saturday, August 04, 2012 02:37:07 Stefan Scholl wrote:
 bearophile<bearophileHUGS lycos.com>  wrote:
 Caligo:
 When are allocators going to be ready?

Direct experience shows me that once things are in Phobos, it's not easy to fix their interface/API. Andrei fears of breaking

Go's solution are experimental packages. You can always use them, but you know that they will change and at some time will be in antother namespace/directory.

It's been discussed a time or two that we should have an incubator project for Phobos where potential Phobos modules go to be used and ironed out before actually being reviewed for inclusion in Phobos. But it's never materialized. Someone(s) would have to organize it and manage it, and no one has done so. - Jonathan M Davis

Where should it be hosted, github? -- Paulo
Aug 04 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Caligo:

 When are allocators going to be ready?

Direct experience shows me that once things are in Phobos, it's not easy to fix their interface/API. Andrei fears of breaking changes, so even small API improvements of Phobos stuff written last year are refused. See as example: http://d.puremagic.com/issues/show_bug.cgi?id=8467 So Phobos stuff once created is almost set in stone. This means that in practice the Phobos APIs should be perfect on the first try. So better to not rush things, and do things right. Bye, bearophile
Aug 03 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Friday, 3 August 2012 at 19:44:22 UTC, bearophile wrote:
 Caligo:

 When are allocators going to be ready?

Direct experience shows me that once things are in Phobos, it's not easy to fix their interface/API. Andrei fears of breaking changes, so even small API improvements of Phobos stuff written last year are refused. See as example: http://d.puremagic.com/issues/show_bug.cgi?id=8467 So Phobos stuff once created is almost set in stone. This means that in practice the Phobos APIs should be perfect on the first try. So better to not rush things, and do things right. Bye, bearophile

"When in doubt, leave it out." says Joshua Bloch http://www.youtube.com/watch?v=aAb7hSCtvGw
Aug 03 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, August 04, 2012 02:37:07 Stefan Scholl wrote:
 bearophile <bearophileHUGS lycos.com> wrote:
 Caligo:
 When are allocators going to be ready?

Direct experience shows me that once things are in Phobos, it's not easy to fix their interface/API. Andrei fears of breaking

Go's solution are experimental packages. You can always use them, but you know that they will change and at some time will be in antother namespace/directory.

Aug 03 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, August 04, 2012 02:37:07 Stefan Scholl wrote:
 bearophile <bearophileHUGS lycos.com> wrote:
 Caligo:
 When are allocators going to be ready?

Direct experience shows me that once things are in Phobos, it's not easy to fix their interface/API. Andrei fears of breaking

Go's solution are experimental packages. You can always use them, but you know that they will change and at some time will be in antother namespace/directory.

It's been discussed a time or two that we should have an incubator project for Phobos where potential Phobos modules go to be used and ironed out before actually being reviewed for inclusion in Phobos. But it's never materialized. Someone(s) would have to organize it and manage it, and no one has done so. - Jonathan M Davis
Aug 03 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, August 04, 2012 04:44:12 Alex R=C3=B8nne Petersen wrote:
 It's been discussed a time or two that we should have an incubator =


 for Phobos where potential Phobos modules go to be used and ironed =


 before actually being reviewed for inclusion in Phobos. But it's ne=


 materialized. Someone(s) would have to organize it and manage it, a=


 one has done so.
=20
 - Jonathan M Davis

I thought this was the idea of etc.* all along...

Someone may have suggested that at some point, but that's not the way t= hat=20 it's used at all.
 If nobody's against it, we should definitely get the ball rolling.

I don't think that anyone's really against it, and it's not like it rea= lly=20 needs to be official. The Phobos review process can be the same that it= 's been.=20 There would just be a place for future Phobos stuff to be publicly tink= ered=20 with and allowed to evolve through usage rather than just designing eve= rything=20 up front as has often been the case with Phobos modules. The problem is= that=20 someone actually needs to step up and make it happen. - Jonathan M Davis
Aug 03 2012
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, August 04, 2012 11:25:35 Paulo Pinto wrote:
 Where should it be hosted, github?

Probably. That's where we're putting everything else. - Jonathan M Davis
Aug 04 2012