www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - phobos alt.

reply bls <bizprac orange.fr> writes:
I am watching D since about 4 years now.

Still no std.collection. For whatever reasons several approaches to 
bring in an usable collection module has been mission impossible.
Just want to mention Ben Hinkle D1 , Uwe Salomon D1 , and now Steven 
Schveighoffer D2, not to forget Ant D1 (the GTKD initiator)

Just for Phobos noobs
Ben Hinkle - Not on the radar anymore
has written a Java like collection module (including a concurrent 
collections)

Uwe Salomon - Went away
has written a QT like collection module (and more)

Steven Schveighoffer - Surprisingly still there
is the author of dcollections (BOOST LICENSE Range-I-fied)

NONE of these libraries made it into Phobos..

So instead of complaining I would like to suggest that we implement an 
alt.xml
alt.collection
atl.gui,win
guess you get it :)
A+ Bjoern
Oct 29 2011
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sun, 30 Oct 2011 02:20:15 +0300, bls <bizprac orange.fr> wrote:

 Steven Schveighoffer - Surprisingly still there
 is the author of dcollections (BOOST LICENSE Range-I-fied)

std.container? http://d-programming-language.org/phobos/std_container.html -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Oct 29 2011
parent reply bls <bizprac orange.fr> writes:
On 10/29/2011 04:30 PM, Vladimir Panteleev wrote:
 On Sun, 30 Oct 2011 02:20:15 +0300, bls <bizprac orange.fr> wrote:

 Steven Schveighoffer - Surprisingly still there
 is the author of dcollections (BOOST LICENSE Range-I-fied)

std.container? http://d-programming-language.org/phobos/std_container.html

Hi Vladimir, _Please_ compare the half baked std.container stuff {more or less just an Interface) vs Stevens dcollections. http://www.dsource.org/projects/dcollections --- Just a front page copu --- Hash, RBTree, Link, Array, and Deque implementations for appropriate containers. List, Set, Map, and Multiset containers provided. Able to swap out underlying implementation of a container, or customize implementation. Minimized heap activity. All cursors and ranges are struct-based. version 1.0 compatible with Tango and Phobos, version 2.0 compatible with D2 phobos. Safe slicing for D2. Removal while traversing. Removal of elements does not invalidate cursors or ranges when possible. Cursors and ranges can be kept for later use (such as O(1) removal if supported by the container). Interfaces for implementation-independent code. Concatenation and appending for lists. dup functions. Set/Map intersection. Handy filter, transform, and chain iterators. Custom allocators. ---- Allow me a personal mote.. It is a shame that this excellent lib is NOT part of phobos, However IMHO alt,container (dcollections) should satisfy most of us.
Oct 29 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, October 30, 2011 02:58:32 Vladimir Panteleev wrote:
 On Sun, 30 Oct 2011 02:43:44 +0300, bls <bizprac orange.fr> wrote:
 On 10/29/2011 04:30 PM, Vladimir Panteleev wrote:
 On Sun, 30 Oct 2011 02:20:15 +0300, bls <bizprac orange.fr> wrote:
 Steven Schveighoffer - Surprisingly still there
 is the author of dcollections (BOOST LICENSE Range-I-fied)

std.container? http://d-programming-language.org/phobos/std_container.html

Hi Vladimir, _Please_ compare the half baked std.container stuff {more or less just an Interface) vs Stevens dcollections.

std.container seems to have been written by the very same Steven Schveighoffer. (Also, I've never used any collection/container modules, so can't speak about their feature-completeness.)

The basic design of std.container comes from Andrei Alexandrescu, and he wrote Array and SList, but RedBlackTree comes from dcollections with some minor alterations to make it fit in std.container. More containers are forthcoming. The primary holdup at the moment is that Andrei wants the custom allocator scheme that Phobos will use to be sorted out before writing all of those containers, otherwise they'll have to be changed once that happens, and it could break a lot of code. On the whole, std.container has a solid basic design. It just isn't complete yet. It's a big problem and arguably Phobos' greatest deficiency, but it's a problem that will be solved. In the interim, dcollections does exist and can be used. - Jonathan M Davis
Oct 29 2011
prev sibling parent reply bls <bizprac orange.fr> writes:
On 10/29/2011 04:58 PM, Vladimir Panteleev wrote:
 td.container seems to have been written by the very same Steven
 Schveighoffer.

Well, that's not quit right. Steven has done a lot of things on std.container, (especially algorithm wise, RB Tree f.i.), but the senior designer is Andrei. But I thing it's up to Steven to explain the political thingies. Just want to say that > Phobos don't have a boost like container library and dcollections is already offering something beyond. (cursors) AGAIN why not having alt.container ?? A+ Bjoern
Oct 29 2011
next sibling parent reply bls <bizprac orange.fr> writes:
On 10/29/2011 05:26 PM, Jonathan M Davis wrote:
 f you want to have or use a 3rd party library, that's fine. But there's no
 reason to put such a library inside of the standard library. That's just
 confusing to people. std.container is how Phobos is going to do containers. It
 needs to be fleshed out, and it's possible that its API needs some refinement,
 but sticking alternate implementations of things inside of the standard
 library is just confusing and schizophrenic. The standard library will have
 what it will have and implement that how it implements it. It's
 counterproductive to put a bunch of different ways to do the same thing in the
 standard library. If someone wants a different design or implementation, they
 can create or use 3rd party library which does that. There's no need for it to
 be officially sanctioned in the standard library. So, if someone wants to use
 dcollections, then let them use dcollections, but that's no reason to stick it
 in Phobos which already has a different design for how its containers work.

Hi Jonathan, I think I get your point. And sure there are pros and cons Since I am convinced that there are more pros (otherwise I would simply shut up) Let me try to argue for my position. let's start with std.xml I guess you will agree that std.xml is ahem.. not perfect. Now there is something better, on dsource, google, git, Dunno. Isn't better to have such an alt.xml lib handy..without searching ? Let's take collections, Here we have atm nothing comparable in phobos. Let me ask : Having dcollections in phobos ..Will it break some _existing_ code ? Not my last argument.. but heck I am tiered. Simple, but important libraries are hanging around, {somewhere}, a guid lib, a crypt lib, a financial math lib. etc. why not having *alt.* as say.. incubator. A+ Bjoern
Oct 29 2011
parent bls <bizprac orange.fr> writes:
On 10/29/2011 06:04 PM, Jonathan M Davis wrote:
 It has already been suggested in the past that we have an incubator project of
 sorts

Thanks for the feedback, and, ahem... it was me asking for an incubator project.. works fine for other projects,beside. BCS suggested to use dSource Scrabble as Incubator which is imo non-sense, even his own Important!project is pretty unknown. I am convinced that a couple of very good/important D modules disappear from the D radar without being noticed, which means for me (I am afraid) that we'll have to wait another 3 years to get a reasonable standard library. alt. could help but guess further discussion does not make too much sense :) A+ Bjoern
Oct 29 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/29/11 7:17 PM, bls wrote:
 On 10/29/2011 04:58 PM, Vladimir Panteleev wrote:
 td.container seems to have been written by the very same Steven
 Schveighoffer.

Well, that's not quit right. Steven has done a lot of things on std.container, (especially algorithm wise, RB Tree f.i.), but the senior designer is Andrei. But I thing it's up to Steven to explain the political thingies.

There is no politics at play. Steven and I respect each other's design choices and we agree to disagree on a few decisions that could reasonably go either way. He has graciously accepted to alter his RBTree API to integrate it with Phobos.
 Just want to say that > Phobos don't have a boost like container library
 and dcollections is already offering something beyond. (cursors)
 AGAIN why not having alt.container ??

This is an invite to gratuitous balkanization. std.container is open for contributions. If anyone wants to add to it, they would need to pass it through the review process. The design is well-defined enough to make e.g. a DList implementation free of any dilemmas. Thanks, Andrei
Oct 29 2011
parent reply bls <bizprac orange.fr> writes:
On 10/31/2011 05:41 AM, Steven Schveighoffer wrote:
 I encourage anyone to port any portion of dcollections to
 std.container.  If nothing else it will help flesh out the design of
 std.container

Ahem.. No offense, or wth Maybe I miss the point but I guess you will agree with me that Phobos, in order to become a serious library, requires at least! a container library. (guess that's why you've created dcollections:) ) Remarkable enough that a really young language (compared to D) more exact Scala has to offer so MUCH more. Now again ...what _Was_ the point ? Allocation ? Let me quote yourself from dsource ... Features .. Custom allocators. Further.. Could not find it .. But something similar to .. Possibility to exchange the underlaying algorithm.. (Say RBTree, AVL,Skiplist) to implement for instance map!() Sure, I am not using D for bread and butter but would like to,,,. Nevertheless be assured that I will not even touch D. for small commercial projects, until at least xml, (rest/wsdl) and necessarily the collection stuff is available. Again,, no offense,no bashing or whatever, just an opinion. Bjoern
Oct 31 2011
parent bls <bizprac orange.fr> writes:
On 10/31/2011 04:11 PM, Jonathan M Davis wrote:
 That's perfectly reasonable. The fact that std.container is so incomplete is a
 _huge_  problem for Phobos. It needs to be filled out and its API fully ironed
 out. Overall, it looks solid, but it just doesn't have enough actual usage at
 this point to really verify that because of the lack of containers.
 std.container_will_  be completed, so this really shouldn't be a long term
 concern, but in the short term, I agree that it's a definite problem.

Thanks. I've tried to contact Steven via email in order to stress-test my skiplist implementation in dcollections. (I am not obsessed regarding skiplists, but all measurements I have seen so far are showing that in case of massive appending the skiplist algorithm wins).. makes sense for std.database (orm/unitofwork) Nevertheless, what I don't understand is : What has to be ironed out before giving std.collections a go ?, What's the show-stopper? The only thing I can vaguely imagine is streaming .. but dunno.
Oct 31 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sun, 30 Oct 2011 02:43:44 +0300, bls <bizprac orange.fr> wrote:

 On 10/29/2011 04:30 PM, Vladimir Panteleev wrote:
 On Sun, 30 Oct 2011 02:20:15 +0300, bls <bizprac orange.fr> wrote:

 Steven Schveighoffer - Surprisingly still there
 is the author of dcollections (BOOST LICENSE Range-I-fied)

std.container? http://d-programming-language.org/phobos/std_container.html

Hi Vladimir, _Please_ compare the half baked std.container stuff {more or less just an Interface) vs Stevens dcollections.

std.container seems to have been written by the very same Steven Schveighoffer. (Also, I've never used any collection/container modules, so can't speak about their feature-completeness.) -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Oct 29 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, October 29, 2011 17:17:18 bls wrote:
 On 10/29/2011 04:58 PM, Vladimir Panteleev wrote:
 td.container seems to have been written by the very same Steven
 Schveighoffer.

Well, that's not quit right. Steven has done a lot of things on std.container, (especially algorithm wise, RB Tree f.i.), but the senior designer is Andrei. But I thing it's up to Steven to explain the political thingies. Just want to say that > Phobos don't have a boost like container library and dcollections is already offering something beyond. (cursors) AGAIN why not having alt.container ??

If you want to have or use a 3rd party library, that's fine. But there's no reason to put such a library inside of the standard library. That's just confusing to people. std.container is how Phobos is going to do containers. It needs to be fleshed out, and it's possible that its API needs some refinement, but sticking alternate implementations of things inside of the standard library is just confusing and schizophrenic. The standard library will have what it will have and implement that how it implements it. It's counterproductive to put a bunch of different ways to do the same thing in the standard library. If someone wants a different design or implementation, they can create or use 3rd party library which does that. There's no need for it to be officially sanctioned in the standard library. So, if someone wants to use dcollections, then let them use dcollections, but that's no reason to stick it in Phobos which already has a different design for how its containers work. - Jonathan M Davis
Oct 29 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, October 29, 2011 17:49:40 bls wrote:
 On 10/29/2011 05:26 PM, Jonathan M Davis wrote:
 f you want to have or use a 3rd party library, that's fine. But there's
 no reason to put such a library inside of the standard library. That's
 just confusing to people. std.container is how Phobos is going to do
 containers. It needs to be fleshed out, and it's possible that its API
 needs some refinement, but sticking alternate implementations of things
 inside of the standard library is just confusing and schizophrenic. The
 standard library will have what it will have and implement that how it
 implements it. It's
 counterproductive to put a bunch of different ways to do the same thing
 in the standard library. If someone wants a different design or
 implementation, they can create or use 3rd party library which does
 that. There's no need for it to be officially sanctioned in the
 standard library. So, if someone wants to use dcollections, then let
 them use dcollections, but that's no reason to stick it in Phobos which
 already has a different design for how its containers work.

I think I get your point. And sure there are pros and cons Since I am convinced that there are more pros (otherwise I would simply shut up) Let me try to argue for my position. let's start with std.xml I guess you will agree that std.xml is ahem.. not perfect. Now there is something better, on dsource, google, git, Dunno. Isn't better to have such an alt.xml lib handy..without searching ? Let's take collections, Here we have atm nothing comparable in phobos. Let me ask : Having dcollections in phobos ..Will it break some _existing_ code ? Not my last argument.. but heck I am tiered. Simple, but important libraries are hanging around, {somewhere}, a guid lib, a crypt lib, a financial math lib. etc. why not having *alt.* as say.. incubator.

std.xml is going to be replaced. We don't want to leave bad code in Phobos. If something really needs to be replaced, then we're going to replace it, not just create a separate module which does the same thing but differently. We don't need a separate container library in Phobos. We _do_ need a container library, and the one that we have is woefully inadequate, but there are already plans to expand it appropriately. There's no need to add a second container library. It has already been suggested in the past that we have an incubator project of sorts, and there's a lot to be said for that, but we don't need that to be in the standard library. It should be a completely separate project IMHO. The only thing stopping it from happening is that no one has created it. Someone needs to champion such a project, and that hasn't happened - probably because it would be a fair bit of work. - Jonathan M Davis
Oct 29 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, October 29, 2011 18:48:54 bls wrote:
 I am convinced that a couple of very good/important D modules disappear
 from the D radar without being noticed,

Such as? As it stands, to get anything into Phobos, someone needs to champion it and be willing to do all of the work necessary to get it ready and through the review process and into Phobos. If no one cares that much about it, then it's just not going to make it in.
 which means for me (I am afraid)
 that we'll have to wait another 3 years to get a reasonable standard
 library.

That seems a bit extreme. It's definitely taking longer than would be desirable for some stuff, but it's not going to take 3 years for anything if people actually care about it and work on it. We've had a fairly steady set of reviews going of late, some of which have passed and some of which haven't, so new stuff is making it into Phobos on a regular basis. - Jonathan M Davis
Oct 29 2011
prev sibling next sibling parent Jesse Phillips <jessekphillips+d gmail.com> writes:
On Sat, 29 Oct 2011 16:20:15 -0700, bls wrote:

 I am watching D since about 4 years now.
 
 Still no std.collection. For whatever reasons several approaches to
 bring in an usable collection module has been mission impossible. Just
 want to mention Ben Hinkle D1 , Uwe Salomon D1 , and now Steven
 Schveighoffer D2, not to forget Ant D1 (the GTKD initiator)

We don't need an alt. We need a place people can go to find libraries they desire. These libraries need to be maintained. Phobos is already open to contributions for improvements and missing functionality. std.container has a different design goal than dcollections (intended candidate) but modification and submission has already been approved and welcomed by both parties. We want high quality code entering the standard library, and that does mean slower adoption. But it also means a willingness to maintain, stick around, and put up with political strife. When people work on their project they enjoy doing it at leisure, making it public but only announcing upon a usable release. This means code is placed on dsource, github, bitbucket, and developed without intent on it being readily usable. And left in various states, just like all other OSS sites. With the fast pace development of the compiler, libraries can quickly be outdated, things are slowing. If their is a requirement to maintain, it can put people off of submitting. But if there isn't one than someone else just added to their work or the alt lib would quickly become a dsource. The two options I see: someone to go in and updated all of dsource so it compiles on the latest compiler, or update the important libraries they find here: http://www.prowiki.org/wiki4d/wiki.cgi?DevelopmentWithD/Libraries If we can't maintain a list of maintained usable projects, what makes you think we can maintain an alternate library? There is also a CPAN like project in development. Once done, it would require usage by the community to be of any use.
Oct 29 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sat, 29 Oct 2011 22:14:34 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 10/29/11 7:17 PM, bls wrote:
 On 10/29/2011 04:58 PM, Vladimir Panteleev wrote:
 td.container seems to have been written by the very same Steven
 Schveighoffer.



Just the RBTree portion (and Jonathan Davis has fixed a lot of issues with it since then). Andrei insisted my name come first because my contributions occupied the most real estate ;)
 Well, that's not quit right. Steven has done a lot of things on
 std.container, (especially algorithm wise, RB Tree f.i.), but the senior
 designer is Andrei.
 But I thing it's up to Steven to explain the political thingies.

There is no politics at play. Steven and I respect each other's design choices and we agree to disagree on a few decisions that could reasonably go either way. He has graciously accepted to alter his RBTree API to integrate it with Phobos.

I agree with Andrei here. Andrei asked me to incorporate RBTree into std.container, and I did it because it took me quite a while and wrestling with my CLR algorithms book to get it right, and it was an easy thing for me to contribute to phobos which would have been likely painful for another developer to do ;) I don't hold anything against phobos for not wanting my collections library, I'm perfectly happy using it as a third-party lib. I suspect if dcollections were to gain traction by, say, being used in large projects, competition would force std.container to become developed. It's somewhat how std.container came into existence anyways (the announcement of dcollections for D2 forced the issue), and it pushed the current tango container lib along when I tried proposing it to replace Tango's lib. If at some point std.container satisfies my needs for a collection library design-wise, I'll happily switch over to using it and incorporate as much dcollections as I can into std.container. But right now, I find the design woefully inadequate/clunky. Just my opinion. I also quite enjoy having my own side-project to tinker with :) I encourage anyone to port any portion of dcollections to std.container. If nothing else it will help flesh out the design of std.container (or even dcollections). But you will not find me using it until cursors and deletion-while-iterating are added.
 Just want to say that > Phobos don't have a boost like container library
 and dcollections is already offering something beyond. (cursors)
 AGAIN why not having alt.container ??

This is an invite to gratuitous balkanization. std.container is open for contributions. If anyone wants to add to it, they would need to pass it through the review process. The design is well-defined enough to make e.g. a DList implementation free of any dilemmas.

I don't wish to create a secondary "standard" library. Having a third party version is good enough, and people are free to use it or not, it does not need some sort of "official" status. I think a good container library helps when you need it for other parts of the standard library. I have no doubt the design of std.container will be revisited when other parts of phobos try to use it and find it lacking. Necessity is the mother of invention. I do wish dsource would get its act together and start trimming dead wood, dcollections (and other good active projects) are buried in it. I try to bring it up when the issue of collections comes up on the NG, which is about all the press I get ;) I might switch to github, I've found git pretty nifty. And my documentation for dcollections 2.0 is long overdue... -Steve
Oct 31 2011
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, October 31, 2011 15:47 bls wrote:
 On 10/31/2011 05:41 AM, Steven Schveighoffer wrote:
 I encourage anyone to port any portion of dcollections to
 std.container. If nothing else it will help flesh out the design of
 std.container

Ahem.. No offense, or wth Maybe I miss the point but I guess you will agree with me that Phobos, in order to become a serious library, requires at least! a container library. (guess that's why you've created dcollections:) ) Remarkable enough that a really young language (compared to D) more exact Scala has to offer so MUCH more. Now again ...what _Was_ the point ? Allocation ? Let me quote yourself from dsource ... Features .. Custom allocators. Further.. Could not find it .. But something similar to .. Possibility to exchange the underlaying algorithm.. (Say RBTree, AVL,Skiplist) to implement for instance map!() Sure, I am not using D for bread and butter but would like to,,,. Nevertheless be assured that I will not even touch D. for small commercial projects, until at least xml, (rest/wsdl) and necessarily the collection stuff is available. Again,, no offense,no bashing or whatever, just an opinion.

That's perfectly reasonable. The fact that std.container is so incomplete is a _huge_ problem for Phobos. It needs to be filled out and its API fully ironed out. Overall, it looks solid, but it just doesn't have enough actual usage at this point to really verify that because of the lack of containers. std.container _will_ be completed, so this really shouldn't be a long term concern, but in the short term, I agree that it's a definite problem. - Jonathan M Davis
Oct 31 2011
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, October 31, 2011 16:48 bls wrote:
 On 10/31/2011 04:11 PM, Jonathan M Davis wrote:
 That's perfectly reasonable. The fact that std.container is so incomplete
 is a _huge_ problem for Phobos. It needs to be filled out and its API
 fully ironed out. Overall, it looks solid, but it just doesn't have
 enough actual usage at this point to really verify that because of the
 lack of containers. std.container_will_ be completed, so this really
 shouldn't be a long term concern, but in the short term, I agree that
 it's a definite problem.

Thanks. I've tried to contact Steven via email in order to stress-test my skiplist implementation in dcollections. (I am not obsessed regarding skiplists, but all measurements I have seen so far are showing that in case of massive appending the skiplist algorithm wins).. makes sense for std.database (orm/unitofwork) Nevertheless, what I don't understand is : What has to be ironed out before giving std.collections a go ?, What's the show-stopper? The only thing I can vaguely imagine is streaming .. but dunno.

std.collections? Do you mean std.container? Andrei wants the custom allocators sorted out before we implement a bunch of containers that we'd then have to change. As it is, Array and SList are supposed to be turned into final classes rather than reference-counted structs, and not even that has happened yet. So, it seems like std.container has effectively stagnated while waiting for the custom allocator stuff to be worked out. However, supposedly Andrei is going to start messing around with the recently reviewed region allocator stuff with std.container sometime soon in order to iron it out a bit more, but with how busy he is, I don't know where that stands. - Jonathan M Davis
Oct 31 2011
prev sibling next sibling parent Caligo <iteronvexor gmail.com> writes:
--bcaec547cad9119b3004b0a2ac41
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Oct 31, 2011 at 7:46 PM, Jonathan M Davis <jmdavisProg gmx.com>wrote:

 On Monday, October 31, 2011 16:48 bls wrote:
 On 10/31/2011 04:11 PM, Jonathan M Davis wrote:
 That's perfectly reasonable. The fact that std.container is so


 is a _huge_ problem for Phobos. It needs to be filled out and its API
 fully ironed out. Overall, it looks solid, but it just doesn't have
 enough actual usage at this point to really verify that because of the
 lack of containers. std.container_will_ be completed, so this really
 shouldn't be a long term concern, but in the short term, I agree that
 it's a definite problem.

Thanks. I've tried to contact Steven via email in order to stress-test my skiplist implementation in dcollections. (I am not obsessed regarding skiplists, but all measurements I have seen so far are showing that in case of massive appending the skiplist algorithm wins).. makes sense for std.database (orm/unitofwork) Nevertheless, what I don't understand is : What has to be ironed out before giving std.collections a go ?, What's the show-stopper? The only thing I can vaguely imagine is streaming .. but dunno.

std.collections? Do you mean std.container? Andrei wants the custom allocators sorted out before we implement a bunch of containers that we'd then have to change. As it is, Array and SList are supposed to be turned into final classes rather than reference-counted structs, and not even that has happened yet. So, it seems like std.container has effectively stagnated while waiting for the custom allocator stuff to be worked out. However, supposedly Andrei is going to start messing around with the recently reviewed region allocator stuff with std.container sometime soon in order to iron it out a bit more, but with how busy he is, I don't know where that stands. - Jonathan M Davis

How long before custom allocator stuff is complete? 6 months? a year? --bcaec547cad9119b3004b0a2ac41 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Mon, Oct 31, 2011 at 7:46 PM, Jonatha= n M Davis <span dir=3D"ltr">&lt;<a href=3D"mailto:jmdavisProg gmx.com">jmda= visProg gmx.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div><div></div><div class=3D"h5">On Monday, October 31, 2011 16:48 bls wro= te:<br> &gt; On 10/31/2011 04:11 PM, Jonathan M Davis wrote:<br> &gt; &gt; That&#39;s perfectly reasonable. The fact that std.container is s= o incomplete<br> &gt; &gt; is a _huge_ problem for Phobos. It needs to be filled out and its= API<br> &gt; &gt; fully ironed out. Overall, it looks solid, but it just doesn&#39;= t have<br> &gt; &gt; enough actual usage at this point to really verify that because o= f the<br> &gt; &gt; lack of containers. std.container_will_ be completed, so this rea= lly<br> &gt; &gt; shouldn&#39;t be a long term concern, but in the short term, I ag= ree that<br> &gt; &gt; it&#39;s a definite problem.<br> &gt;<br> &gt; Thanks.<br> &gt; I&#39;ve tried to contact Steven via email in order to stress-test my<= br> &gt; skiplist implementation in dcollections.<br> &gt;<br> &gt; (I am not obsessed regarding skiplists, but all measurements I have se= en<br> &gt; so far are showing that in case of massive appending the skiplist<br> &gt; algorithm wins).. makes sense for std.database (orm/unitofwork)<br> &gt;<br> &gt; Nevertheless, what I don&#39;t understand is : What has to be ironed o= ut<br> &gt; before giving std.collections a go ?, What&#39;s the show-stopper? The= only<br> &gt; thing I can vaguely imagine is streaming .. but dunno.<br> <br> </div></div>std.collections? Do you mean std.container? Andrei wants the cu= stom allocators<br> sorted out before we implement a bunch of containers that we&#39;d then hav= e to<br> change. As it is, Array and SList are supposed to be turned into final clas= ses<br> rather than reference-counted structs, and not even that has happened yet. = So,<br> it seems like std.container has effectively stagnated while waiting for the= <br> custom allocator stuff to be worked out. However, supposedly Andrei is goin= g<br> to start messing around with the recently reviewed region allocator stuff w= ith<br> std.container sometime soon in order to iron it out a bit more, but with ho= w<br> busy he is, I don&#39;t know where that stands.<br> <font color=3D"#888888"><br> - Jonathan M Davis<br> </font></blockquote></div><br><div>How long before custom allocator stuff i= s complete? =A06 months? a year?</div> --bcaec547cad9119b3004b0a2ac41--
Oct 31 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, October 31, 2011 20:57:04 Caligo wrote:
 How long before custom allocator stuff is complete?  6 months? a year?

I don't know. I'd expect it to be within the next few months, but there's no way to know when. I could be sooner; it could be later. - Jonathan M Davis
Oct 31 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, October 31, 2011 20:08:52 Jonathan M Davis wrote:
 On Monday, October 31, 2011 20:57:04 Caligo wrote:
 How long before custom allocator stuff is complete?  6 months? a year?

I don't know. I'd expect it to be within the next few months, but there's no way to know when. I could be sooner; it could be later.

One round of review for them was done in this newsgroup already not very long ago, but they didn't pass the review, because they weren't mature enough yet. Andrei and dsimcha need to do more to sort them out still, and I think that the ball is primarily in Andrei's court at this point, because he intends to mess around with them with std.container to see how well dsimcha's current design works. Once all that has been better sorted out, it'll be up for review again, and once it's passed that, it'll be in. But exactly how long that'll be is unknown at this point. - Jonathan M Davis
Oct 31 2011