digitalmars.D - phobos alt.
- bls (20/20) Oct 29 2011 I am watching D since about 4 years now.
- Vladimir Panteleev (6/8) Oct 29 2011 std.container?
- bls (29/34) Oct 29 2011 Hi Vladimir,
- Vladimir Panteleev (8/21) Oct 29 2011 std.container seems to have been written by the very same Steven
- Jonathan M Davis (13/32) Oct 29 2011 The basic design of std.container comes from Andrei Alexandrescu, and he...
- bls (10/12) Oct 29 2011 Well, that's not quit right. Steven has done a lot of things on
- Jonathan M Davis (15/27) Oct 29 2011 If you want to have or use a 3rd party library, that's fine. But there's...
- bls (16/29) Oct 29 2011 Hi Jonathan,
- Jonathan M Davis (15/47) Oct 29 2011 std.xml is going to be replaced. We don't want to leave bad code in Phob...
- bls (13/15) Oct 29 2011 Thanks for the feedback, and, ahem... it was me asking for an incubator...
- Jonathan M Davis (12/17) Oct 29 2011 Such as?
- Andrei Alexandrescu (11/21) Oct 29 2011 There is no politics at play. Steven and I respect each other's design
- Steven Schveighoffer (39/59) Oct 31 2011 Just the RBTree portion (and Jonathan Davis has fixed a lot of issues wi...
- bls (19/22) Oct 31 2011 Ahem.. No offense, or wth
- Jonathan M Davis (8/37) Oct 31 2011 That's perfectly reasonable. The fact that std.container is so incomplet...
- bls (10/16) Oct 31 2011 Thanks.
- Jonathan M Davis (11/31) Oct 31 2011 std.collections? Do you mean std.container? Andrei wants the custom allo...
- Caligo (2/40) Oct 31 2011 How long before custom allocator stuff is complete? 6 months? a year?
- Jesse Phillips (28/34) Oct 29 2011 We don't need an alt. We need a place people can go to find libraries
- Jonathan M Davis (4/5) Oct 31 2011 I don't know. I'd expect it to be within the next few months, but there'...
- Jonathan M Davis (10/15) Oct 31 2011 One round of review for them was done in this newsgroup already not very...
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
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
On 10/29/2011 04:30 PM, Vladimir Panteleev wrote:On Sun, 30 Oct 2011 02:20:15 +0300, bls <bizprac orange.fr> wrote: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.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
Oct 29 2011
On Sun, 30 Oct 2011 02:43:44 +0300, bls <bizprac orange.fr> wrote:On 10/29/2011 04:30 PM, Vladimir Panteleev wrote: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.netOn Sun, 30 Oct 2011 02:20:15 +0300, bls <bizprac orange.fr> wrote:Hi Vladimir, _Please_ compare the half baked std.container stuff {more or less just an Interface) vs Stevens dcollections.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
Oct 29 2011
Jonathan M Davis <jmdavisProg gmx.com> 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: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 DavisOn 10/29/2011 04:30 PM, Vladimir Panteleev wrote: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.)On Sun, 30 Oct 2011 02:20:15 +0300, bls <bizprac orange.fr> wrote:Hi Vladimir, _Please_ compare the half baked std.container stuff {more or less just an Interface) vs Stevens dcollections.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
Oct 29 2011
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
On Saturday, October 29, 2011 17:17:18 bls wrote:On 10/29/2011 04:58 PM, Vladimir Panteleev wrote: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 Davistd.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 ??
Oct 29 2011
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
On Saturday, October 29, 2011 17:49:40 bls wrote:On 10/29/2011 05:26 PM, Jonathan M Davis wrote: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 Davisf 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.
Oct 29 2011
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 sortsThanks 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
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
On 10/29/11 7:17 PM, bls wrote:On 10/29/2011 04:58 PM, Vladimir Panteleev wrote: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.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 ??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
On Sat, 29 Oct 2011 22:14:34 -0400, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:On 10/29/11 7:17 PM, bls wrote: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 ;)On 10/29/2011 04:58 PM, Vladimir Panteleev wrote:td.container seems to have been written by the very same Steven Schveighoffer.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.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 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... -SteveJust 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.
Oct 31 2011
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.containerAhem.. 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
On Monday, October 31, 2011 15:47 bls wrote:On 10/31/2011 05:41 AM, Steven Schveighoffer 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. - Jonathan M DavisI encourage anyone to port any portion of dcollections to std.container. If nothing else it will help flesh out the design of std.containerAhem.. 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.
Oct 31 2011
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
On Monday, October 31, 2011 16:48 bls wrote:On 10/31/2011 04:11 PM, Jonathan M Davis wrote: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 DavisThat'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
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:How long before custom allocator stuff is complete? 6 months? a year?On 10/31/2011 04:11 PM, Jonathan M Davis wrote:incompleteThat's perfectly reasonable. The fact that std.container is sostd.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 Davisis 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
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
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
On Monday, October 31, 2011 20:08:52 Jonathan M Davis wrote:On Monday, October 31, 2011 20:57:04 Caligo wrote: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 DavisHow 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.
Oct 31 2011