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 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
parent reply "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
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 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 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 parent reply 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
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 reply 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 =




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 ne=




ver

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




nd no

 one has done so.
=20
 - Jonathan M Davis


=20
 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
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 reply 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
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