Re: new std.variant (was Re: The Right Approach to Exceptions)
On Thu, Feb 23, 2012 at 04:00:04AM +0100, Juan Manuel Cabo wrote: [...] > I'm sorry. I went over the top. I apollogize. I apologize too, for some of the inflammatory things I said in the heat of the moment in some of my replies to this thread. > ..I won't post for a while. > This thread is almost poping a vein in my neck.. Heh, several times I had to stop myself from hitting Send, take a deep breath, clear my head, and go back to edit out my inflammatory remarks before posting it. > Passion can do that! > I love D. Love all your good work guys!!! [...] Me too. D is the closest to what I've always wanted in an ideal programming language. It's not perfect, and its implementation still has a ways to go, but it already far surpasses all other languages that I've looked at in terms of what I consider important in an ideal language. I'm loving it so much I just can't convince myself to go back to C++ anymore in my personal projects, except for maintenance. (At work I just grit my teeth and comfort myself that they're paying me for it, so I'll tolerate C/C++. :P) T -- Без труда не выловишь и рыбку из пруда.
Re: new std.variant (was Re: The Right Approach to Exceptions)
On Thursday, 23 February 2012 at 02:12:20 UTC, Juan Manuel Cabo wrote: If we are going to get ideallistic [..] I'm sorry. I went over the top. I apollogize. ..I won't post for a while. This thread is almost poping a vein in my neck.. Passion can do that! I love D. Love all your good work guys!!! --jm
Re: new std.variant (was Re: The Right Approach to Exceptions)
On Wednesday, February 22, 2012 20:07:37 Robert Jacques wrote: > StringBuilder in .Net is implemented using lists and doesn't expose > iteration nor indexing; why are we worrying about the indexing and > container performance of D's appender?l Because we're losing something that we currently have and which is potentially useful. Now, improving the performance of appending may outweigh that, but if we don't need to lose it, then we shouldn't. >From the sounds of it though, we don't have much choice if we want to really improve Appender's appending performance. - Jonathan M Davis
Re: new std.variant (was Re: The Right Approach to Exceptions)
On Thursday, 23 February 2012 at 01:57:49 UTC, Jonathan M Davis wrote: The D equivalent would really be Array, not Appender. Array!T in D is ref counted and more geared towards T being a struct. And I had big trouble sorting it with sort!()() in D2.056, so I made my own sort just to be able to use Array!(T). I know that that situation will not remain forever (and I didn't check if it was already fixed in D2.058). I'm not sure that it's a great idea to use Appender as a container - particularly when there are types specifically intended to be used as containers. Appender is geared specifically towards array building (like StringBuilder in Java, except generalized for all arrays). If it's a container that you're looking for, then I really think that you should use a container. - Jonathan M Davis If Appender supports the range interface, then it is a container. Someone will use it that way, because in the real world people take the things for what they are, not for what they are named. Appender can work with T classes well. Contains items. It would be GC managed (as opposed to Array!T). So it is a container. If it is not O(1) to access, it should be said big in the ddoc though. It is a recurrent trend in your posts, that you post just because you have some ideallistic concern or opinion. If we are going to get ideallistic, this is an extract of a poem by Jorge Luis Borges (argentinian writer) that illustrates my point: If (as the Greek states in the Cratilo) the name is the archetype of the thing, in the letters of rose it is the rose and all the Nile is in the word Nile Si como escribió el griego en el Crátilo, el nombre es arquetipo de la cosa, en el nombre de rosa está la rosa y todo el Nilo en la palabra Nilo. --Jorge Luis Borges --jm
Re: new std.variant (was Re: The Right Approach to Exceptions)
On Wed, 22 Feb 2012 19:57:37 -0600, Jonathan M Davis wrote: On Thursday, February 23, 2012 02:36:31 Juan Manuel Cabo wrote: Yeah, but I don't care about the underlying array. I care about multiple places referencing the same Appender. If I from any place that references it, it appends to the same appender. The Appender "array" has identity. Ranges do not: int[] bla = [1,2,3]; int[] ble = bla; ble ~= 4; assert(bla.length == 3); This is very easy to solve with appender. This is what happens in Java: ArrayList bla = new ArrayList(); bla.add(1); ArrayList ble = bla; ble.add(2); //prints 2 System.out.println(Integer.toString(bla.size())); //prints 2 System.out.println(Integer.toString(ble.size())); (yikes, aint that verbose!) The ArrayList has identity. It is a class, so that it many variables reference the _same_ object. (this can be accomplished with structs too though, but not with ranges). The D equivalent would really be Array, not Appender. I'm not sure that it's a great idea to use Appender as a container - particularly when there are types specifically intended to be used as containers. Appender is geared specifically towards array building (like StringBuilder in Java, except generalized for all arrays). If it's a container that you're looking for, then I really think that you should use a container. - Jonathan M Davis StringBuilder in .Net is implemented using lists and doesn't expose iteration nor indexing; why are we worrying about the indexing and container performance of D's appender?
Re: new std.variant (was Re: The Right Approach to Exceptions)
On Thursday, 23 February 2012 at 01:36:32 UTC, Juan Manuel Cabo wrote: On Thursday, 23 February 2012 at 00:51:38 UTC, Jonathan M Davis wrote: [...] If appender ends up with multiple arrays in it, then random access is no longer O(1) and is therefore unacceptable. As such, most sort algorithms wouldn't work with it. If all I want is binary search on a big appender, then it is O(k * n * log(n)), and that k right there doesn't bother me. Also, binary search is absolutely not cpu cache friendly to begin with. Also, your bit about using appender to pass an array around wouldn't work either, because it wouldn't simply be wrapper around an array anymore. - Jonathan M Davis Yeah, but I don't care about the underlying array. I care about multiple places referencing the same Appender. If I from any place that references it, it appends to the same appender. The Appender "array" has identity. Ranges do not: int[] bla = [1,2,3]; int[] ble = bla; ble ~= 4; assert(bla.length == 3); This is very easy to solve with appender. This is what happens in Java: ArrayList bla = new ArrayList(); bla.add(1); ArrayList ble = bla; ble.add(2); //prints 2 System.out.println(Integer.toString(bla.size())); //prints 2 System.out.println(Integer.toString(ble.size())); (yikes, aint that verbose!) The ArrayList has identity. It is a class, so that it many variables reference the _same_ object. (this can be accomplished with structs too though, but not with ranges). I meant ref counted structs. P.S. Please don't top post. Replies should go _after_ the preceding message. Sorry, got it. --jm
Re: new std.variant (was Re: The Right Approach to Exceptions)
On Thursday, February 23, 2012 02:36:31 Juan Manuel Cabo wrote: > Yeah, but I don't care about the underlying array. I care > about multiple places referencing the same Appender. If I > from any place that references it, it appends to the same > appender. The Appender "array" has identity. Ranges do not: > > int[] bla = [1,2,3]; > int[] ble = bla; > ble ~= 4; > assert(bla.length == 3); > > This is very easy to solve with appender. > This is what happens in Java: > ArrayList bla = new ArrayList(); > bla.add(1); > ArrayList ble = bla; > ble.add(2); > //prints 2 > System.out.println(Integer.toString(bla.size())); > //prints 2 > System.out.println(Integer.toString(ble.size())); > > (yikes, aint that verbose!) > The ArrayList has identity. It is a class, so that it > many variables reference the _same_ object. > (this can be accomplished with structs too though, but > not with ranges). The D equivalent would really be Array, not Appender. I'm not sure that it's a great idea to use Appender as a container - particularly when there are types specifically intended to be used as containers. Appender is geared specifically towards array building (like StringBuilder in Java, except generalized for all arrays). If it's a container that you're looking for, then I really think that you should use a container. - Jonathan M Davis
Re: new std.variant (was Re: The Right Approach to Exceptions)
On Thursday, 23 February 2012 at 00:51:38 UTC, Jonathan M Davis wrote: P.S. Please don't top post. Replies should go _after_ the preceding message. P.S: You are right though, that it wouldn't be O(1) anymore and it should be said big in the documentation that it is amortized. --jm
Re: new std.variant (was Re: The Right Approach to Exceptions)
On Thursday, 23 February 2012 at 01:36:32 UTC, Juan Manuel Cabo wrote: If all I want is binary search on a big appender, then it is O(k * n * log(n)), and that k right there doesn't bother me. (Where binary search is of course O(log(n)) and accessing individual elements with the proposed Appender is O(N / (4080/T.sizeof)), so k == 4080/T.sizeof) --jm
Re: new std.variant (was Re: The Right Approach to Exceptions)
On Thursday, 23 February 2012 at 00:51:38 UTC, Jonathan M Davis wrote: [...] If appender ends up with multiple arrays in it, then random access is no longer O(1) and is therefore unacceptable. As such, most sort algorithms wouldn't work with it. If all I want is binary search on a big appender, then it is O(k * n * log(n)), and that k right there doesn't bother me. Also, binary search is absolutely not cpu cache friendly to begin with. Also, your bit about using appender to pass an array around wouldn't work either, because it wouldn't simply be wrapper around an array anymore. - Jonathan M Davis Yeah, but I don't care about the underlying array. I care about multiple places referencing the same Appender. If I from any place that references it, it appends to the same appender. The Appender "array" has identity. Ranges do not: int[] bla = [1,2,3]; int[] ble = bla; ble ~= 4; assert(bla.length == 3); This is very easy to solve with appender. This is what happens in Java: ArrayList bla = new ArrayList(); bla.add(1); ArrayList ble = bla; ble.add(2); //prints 2 System.out.println(Integer.toString(bla.size())); //prints 2 System.out.println(Integer.toString(ble.size())); (yikes, aint that verbose!) The ArrayList has identity. It is a class, so that it many variables reference the _same_ object. (this can be accomplished with structs too though, but not with ranges). P.S. Please don't top post. Replies should go _after_ the preceding message. Sorry, got it. --jm
Re: new std.variant (was Re: The Right Approach to Exceptions)
On Wed, 22 Feb 2012 18:51:27 -0600, Jonathan M Davis wrote: On Thursday, February 23, 2012 01:38:05 Juan Manuel Cabo wrote: (And not talking about some cheesy insertion sort!!) If you build an array once and for all, and all you want is to do binary search on it later, it doesn't make sense to allocate that big contiguous .data. I'd rather leave it as an appender. --jm On Wednesday, 22 February 2012 at 23:22:35 UTC, Juan Manuel Cabo wrote: >> No, because the array doesn't actually exist until appender >> makes copy. > > Will one be able to use the sort!()() algorithm directly on > your appender, > that is, without accessing/creating the underlying array? If appender ends up with multiple arrays in it, then random access is no longer O(1) and is therefore unacceptable. As such, most sort algorithms wouldn't work with it. Also, your bit about using appender to pass an array around wouldn't work either, because it wouldn't simply be wrapper around an array anymore. - Jonathan M Davis P.S. Please don't top post. Replies should go _after_ the preceding message. Well, a VList (which is a list of arrays) is has O(1) amortized indexing. Actual performance of my implementation would be O(N / (4080/T.sizeof)), which isn't so bad. And anything under a page of ram would be O(1).
Re: new std.variant (was Re: The Right Approach to Exceptions)
On Wed, Feb 22, 2012 at 07:51:27PM -0500, Jonathan M Davis wrote: [...] > P.S. Please don't top post. Replies should go _after_ the preceding message. Answer: Because it breaks the normal flow of conversation. Question: Why is it bad to top-post? T -- Why waste time learning, when ignorance is instantaneous? -- Hobbes, from Calvin & Hobbes
Re: new std.variant (was Re: The Right Approach to Exceptions)
On Thursday, February 23, 2012 01:38:05 Juan Manuel Cabo wrote: > (And not talking about some cheesy insertion sort!!) > > If you build an array once and for all, and all you want > is to do binary search on it later, it doesn't make sense to > allocate that big contiguous .data. I'd rather leave it > as an appender. > > --jm > > > On Wednesday, 22 February 2012 at 23:22:35 UTC, Juan Manuel Cabo > > wrote: > >> No, because the array doesn't actually exist until appender > >> makes copy. > > > > Will one be able to use the sort!()() algorithm directly on > > your appender, > > that is, without accessing/creating the underlying array? If appender ends up with multiple arrays in it, then random access is no longer O(1) and is therefore unacceptable. As such, most sort algorithms wouldn't work with it. Also, your bit about using appender to pass an array around wouldn't work either, because it wouldn't simply be wrapper around an array anymore. - Jonathan M Davis P.S. Please don't top post. Replies should go _after_ the preceding message.
Re: new std.variant (was Re: The Right Approach to Exceptions)
(And not talking about some cheesy insertion sort!!) If you build an array once and for all, and all you want is to do binary search on it later, it doesn't make sense to allocate that big contiguous .data. I'd rather leave it as an appender. --jm On Wednesday, 22 February 2012 at 23:22:35 UTC, Juan Manuel Cabo wrote: No, because the array doesn't actually exist until appender makes copy. Will one be able to use the sort!()() algorithm directly on your appender, that is, without accessing/creating the underlying array? --jm
Re: new std.variant (was Re: The Right Approach to Exceptions)
On Wednesday, 22 February 2012 at 20:59:15 UTC, Jonathan M Davis
wrote:
speed [...] is really its whole point of existance. I don't
know why else you'd ever use appender.
[...]
- Jonathan M Davis
A use case is to give identity to a built-in array.
Consider this:
class MyClass {
private MyData[] theData;
public @property MyData[] data() {
return theData;
}
...
}
MyClass m = new MyClass();
m.data ~= new MyData();
//Nothing got appended:
assert(m.data.length == 0);
For the 95% of the use cases, that is the desired
behaviour. You don't want anyone appending to
your private array. If you wanted to, you would
have defined MyClass.append(myData).
But there are a few cases where you want to
give identity to the array, and let anyone who
has a "handle" to it, to be able to append it.
(another case is while porting code from languages
that don't represent arrays as ranges, and return
them as getters).
--jm
Re: new std.variant (was Re: The Right Approach to Exceptions)
No, because the array doesn't actually exist until appender makes copy. Will one be able to use the sort!()() algorithm directly on your appender, that is, without accessing/creating the underlying array? --jm
Re: new std.variant (was Re: The Right Approach to Exceptions)
On Wed, 22 Feb 2012 14:17:09 -0600, Jonathan M Davis wrote: On Wednesday, February 22, 2012 14:12:07 Jonathan M Davis wrote: On Wednesday, February 22, 2012 12:16:43 Robert Jacques wrote: > There's a big difference between sealed and not accessible. .data's API > requires exposing an array, and there's no way to do this without leaking > memory like a sieve in one way or another. However, if all you need is to > iterate the contents, that's easy to do. I'm currently adding backwards > iteration. Even indexing is fairly efficient (not yet implemented), > particularly relative indexing (i.e. n from back or front). > > I haven't seen too many use cases yet where accessing the underlying array > is important, nor has it come up on bugzilla. I've found one case in > Phobos where appender was used as a stack. What's your example? What > features does it have to support and how efficient does it have to be? It's can be useful to just get at the underlying array and pass it to functions which are going to use it but not alter it (or at least not append to it). Iterating over it doesn't give you an array. And since appender's entire purpose is simply to make appending to an array more efficient, making it impossible to treat it as one until you're done appending is overly restrictive IMHO. Yes, if you leak references to the underlying data, you're asking for trouble, but that doesn't mean that it can't be used without leaking memory. Unfortunately, I don't have any code snippets with me at the moment, so I can't give any concrete examples of usage, but any situation where you want to be able to operate on the array while building it needs the ability to get at the underlying array. Yes, in most cases, you're probably simply appending to the array, but at least once in a while, you need to operate on an array while building it. Also, wouldn't it be less efficient if you _had_ to copy the array once you were done with the appender? That would seem to go against what appender is trying to do. - Jonathan M Davis No, because the array doesn't actually exist until appender makes copy. Internally, appender is using a list of arrays to store the data (similar to a VList and string builders from other languages). So it's little o(2N) for both memory and speed; the current appender is much worse than that. In terms of actual performance, on a clean machine I'm substantially faster for N < 4k (thanks to a free list), about the same for things of a few k in size, and then as things get bigger the current appender tanks.
Re: new std.variant (was Re: The Right Approach to Exceptions)
On Wednesday, February 22, 2012 14:24:49 Robert Jacques wrote: > I view appender's purpose as array building, which is slightly different > from simply speeding up array appending. Simply put, an array is a > terrible data structure for building arrays. But, I can appreciate the > need for mutation and if a particular array building algorithm can't be > performed on appender, then appender has failed. Would exposing a > bidirectional array be sufficient for your usages? A random access range? Well, as long as you don't have access to the actual array, you're going to lose something. There are functions that you just won't be able to use because they take an array. However, a range with essentially the same properties as a range (bidirectional, random access, etc.) would cover a large number of the functions that you might want to call. And if you need to hide the array for speed for efficiency for some reason - especially if it results in a large increase in speed - then that could at least partially outweigh the cost of losing the array (especially if Appender has an API to at least use it as a range). But I'd definitely be against hiding it simply for safety, since speed is really its whole point of existance. I don't know why else you'd ever use appender. So, I don't really like the idea of losing access to the underlying array, but if you can provide at least make it so that you could use it with range-based functions, and the changes provides a sigificant speed improvement, then the need for speed arguably outweighs the loss of being able to use the internal array directly. - Jonathan M Davis
Re: new std.variant (was Re: The Right Approach to Exceptions)
On Wed, 22 Feb 2012 13:12:07 -0600, Jonathan M Davis wrote: On Wednesday, February 22, 2012 12:16:43 Robert Jacques wrote: There's a big difference between sealed and not accessible. .data's API requires exposing an array, and there's no way to do this without leaking memory like a sieve in one way or another. However, if all you need is to iterate the contents, that's easy to do. I'm currently adding backwards iteration. Even indexing is fairly efficient (not yet implemented), particularly relative indexing (i.e. n from back or front). I haven't seen too many use cases yet where accessing the underlying array is important, nor has it come up on bugzilla. I've found one case in Phobos where appender was used as a stack. What's your example? What features does it have to support and how efficient does it have to be? It's can be useful to just get at the underlying array and pass it to functions which are going to use it but not alter it (or at least not append to it). Iterating over it doesn't give you an array. And since appender's entire purpose is simply to make appending to an array more efficient, making it impossible to treat it as one until you're done appending is overly restrictive IMHO. Yes, if you leak references to the underlying data, you're asking for trouble, but that doesn't mean that it can't be used without leaking memory. Unfortunately, I don't have any code snippets with me at the moment, so I can't give any concrete examples of usage, but any situation where you want to be able to operate on the array while building it needs the ability to get at the underlying array. Yes, in most cases, you're probably simply appending to the array, but at least once in a while, you need to operate on an array while building it. - Jonathan M Davis I view appender's purpose as array building, which is slightly different from simply speeding up array appending. Simply put, an array is a terrible data structure for building arrays. But, I can appreciate the need for mutation and if a particular array building algorithm can't be performed on appender, then appender has failed. Would exposing a bidirectional array be sufficient for your usages? A random access range?
Re: new std.variant (was Re: The Right Approach to Exceptions)
On Wednesday, February 22, 2012 14:12:07 Jonathan M Davis wrote: > On Wednesday, February 22, 2012 12:16:43 Robert Jacques wrote: > > There's a big difference between sealed and not accessible. .data's API > > requires exposing an array, and there's no way to do this without leaking > > memory like a sieve in one way or another. However, if all you need is to > > iterate the contents, that's easy to do. I'm currently adding backwards > > iteration. Even indexing is fairly efficient (not yet implemented), > > particularly relative indexing (i.e. n from back or front). > > > > I haven't seen too many use cases yet where accessing the underlying array > > is important, nor has it come up on bugzilla. I've found one case in > > Phobos where appender was used as a stack. What's your example? What > > features does it have to support and how efficient does it have to be? > > It's can be useful to just get at the underlying array and pass it to > functions which are going to use it but not alter it (or at least not append > to it). Iterating over it doesn't give you an array. And since appender's > entire purpose is simply to make appending to an array more efficient, > making it impossible to treat it as one until you're done appending is > overly restrictive IMHO. Yes, if you leak references to the underlying > data, you're asking for trouble, but that doesn't mean that it can't be > used without leaking memory. > > Unfortunately, I don't have any code snippets with me at the moment, so I > can't give any concrete examples of usage, but any situation where you want > to be able to operate on the array while building it needs the ability to > get at the underlying array. Yes, in most cases, you're probably simply > appending to the array, but at least once in a while, you need to operate > on an array while building it. Also, wouldn't it be less efficient if you _had_ to copy the array once you were done with the appender? That would seem to go against what appender is trying to do. - Jonathan M Davis
Re: new std.variant (was Re: The Right Approach to Exceptions)
On Wednesday, February 22, 2012 12:16:43 Robert Jacques wrote: > There's a big difference between sealed and not accessible. .data's API > requires exposing an array, and there's no way to do this without leaking > memory like a sieve in one way or another. However, if all you need is to > iterate the contents, that's easy to do. I'm currently adding backwards > iteration. Even indexing is fairly efficient (not yet implemented), > particularly relative indexing (i.e. n from back or front). > > I haven't seen too many use cases yet where accessing the underlying array > is important, nor has it come up on bugzilla. I've found one case in > Phobos where appender was used as a stack. What's your example? What > features does it have to support and how efficient does it have to be? It's can be useful to just get at the underlying array and pass it to functions which are going to use it but not alter it (or at least not append to it). Iterating over it doesn't give you an array. And since appender's entire purpose is simply to make appending to an array more efficient, making it impossible to treat it as one until you're done appending is overly restrictive IMHO. Yes, if you leak references to the underlying data, you're asking for trouble, but that doesn't mean that it can't be used without leaking memory. Unfortunately, I don't have any code snippets with me at the moment, so I can't give any concrete examples of usage, but any situation where you want to be able to operate on the array while building it needs the ability to get at the underlying array. Yes, in most cases, you're probably simply appending to the array, but at least once in a while, you need to operate on an array while building it. - Jonathan M Davis
Re: new std.variant (was Re: The Right Approach to Exceptions)
On Wed, 22 Feb 2012 11:33:57 -0600, Jonathan M Davis wrote: On Wednesday, February 22, 2012 08:19:38 Robert Jacques wrote: To Variant? Yes, definitely. To Appender? I don't think so. There is an slight change in API behavior necessitated by performance considerations, but I don't think it warrants a review by the community at large. Specifically, appender's internal data structure is now sealed, which means that .data must always make a copy. My preference would be to deprecate .data in favor of a .dup/.idup pair. It'll break a bunch of code (which I don't like), but it will make sure no one is calling .data twice in a row, resulting in a silent performance problem. I've definitely written code that needed to get at data while appending. I would consider it to be a huge downside to not be able to efficiently get at the current state of the array within the appender. Why on earth would you seal it? - Jonathan M Davis There's a big difference between sealed and not accessible. .data's API requires exposing an array, and there's no way to do this without leaking memory like a sieve in one way or another. However, if all you need is to iterate the contents, that's easy to do. I'm currently adding backwards iteration. Even indexing is fairly efficient (not yet implemented), particularly relative indexing (i.e. n from back or front). I haven't seen too many use cases yet where accessing the underlying array is important, nor has it come up on bugzilla. I've found one case in Phobos where appender was used as a stack. What's your example? What features does it have to support and how efficient does it have to be?
Re: new std.variant (was Re: The Right Approach to Exceptions)
On Wednesday, February 22, 2012 08:19:38 Robert Jacques wrote: > To Variant? Yes, definitely. To Appender? I don't think so. There is an > slight change in API behavior necessitated by performance considerations, > but I don't think it warrants a review by the community at large. > Specifically, appender's internal data structure is now sealed, which means > that .data must always make a copy. My preference would be to deprecate > .data in favor of a .dup/.idup pair. It'll break a bunch of code (which I > don't like), but it will make sure no one is calling .data twice in a row, > resulting in a silent performance problem. I've definitely written code that needed to get at data while appending. I would consider it to be a huge downside to not be able to efficiently get at the current state of the array within the appender. Why on earth would you seal it? - Jonathan M Davis
Re: new std.variant (was Re: The Right Approach to Exceptions)
On Tue, 21 Feb 2012 21:51:34 -0600, Andrei Alexandrescu wrote: On 2/21/12 6:11 PM, Robert Jacques wrote: On Tue, 21 Feb 2012 09:12:57 -0600, Adam D. Ruppe wrote: On Tuesday, 21 February 2012 at 02:33:15 UTC, Robert Jacques wrote: Nope. See (https://jshare.johnshopkins.edu/rjacque2/public_html/ ) Any luck in getting the required patches into phobos? I'd love to see this full thing in there for the next release. It rox. I'm in the process of cleaning up the required patches and submitting them. The first one's already in (https://github.com/sandford/phobos/commit/8b845d2a50bc20993afed7306f3d84921e4ac54b). I've almost got appender ready. Are the changes substantial enough to put them through the review process? Andrei To Variant? Yes, definitely. To Appender? I don't think so. There is an slight change in API behavior necessitated by performance considerations, but I don't think it warrants a review by the community at large. Specifically, appender's internal data structure is now sealed, which means that .data must always make a copy. My preference would be to deprecate .data in favor of a .dup/.idup pair. It'll break a bunch of code (which I don't like), but it will make sure no one is calling .data twice in a row, resulting in a silent performance problem.
Re: new std.variant (was Re: The Right Approach to Exceptions)
On 2/21/12 6:11 PM, Robert Jacques wrote: On Tue, 21 Feb 2012 09:12:57 -0600, Adam D. Ruppe wrote: On Tuesday, 21 February 2012 at 02:33:15 UTC, Robert Jacques wrote: Nope. See (https://jshare.johnshopkins.edu/rjacque2/public_html/ ) Any luck in getting the required patches into phobos? I'd love to see this full thing in there for the next release. It rox. I'm in the process of cleaning up the required patches and submitting them. The first one's already in (https://github.com/sandford/phobos/commit/8b845d2a50bc20993afed7306f3d84921e4ac54b). I've almost got appender ready. Are the changes substantial enough to put them through the review process? Andrei
Re: new std.variant (was Re: The Right Approach to Exceptions)
On Tue, 21 Feb 2012 09:12:57 -0600, Adam D. Ruppe wrote: On Tuesday, 21 February 2012 at 02:33:15 UTC, Robert Jacques wrote: Nope. See (https://jshare.johnshopkins.edu/rjacque2/public_html/ ) Any luck in getting the required patches into phobos? I'd love to see this full thing in there for the next release. It rox. I'm in the process of cleaning up the required patches and submitting them. The first one's already in (https://github.com/sandford/phobos/commit/8b845d2a50bc20993afed7306f3d84921e4ac54b). I've almost got appender ready.
new std.variant (was Re: The Right Approach to Exceptions)
On Tuesday, 21 February 2012 at 02:33:15 UTC, Robert Jacques wrote: Nope. See (https://jshare.johnshopkins.edu/rjacque2/public_html/ ) Any luck in getting the required patches into phobos? I'd love to see this full thing in there for the next release. It rox.
