On 2011-10-05 03:49, Robert Jacques wrote:
On Tue, 04 Oct 2011 12:54:27 -0400, Jacob Carlborg d...@me.com wrote:
On 2011-10-04 17:14, Robert Jacques wrote:
I'm sorry, you're right. In my mind b extended to the end of the a
array, for some reason. However, if you do define b to extend to the
On 2011-10-04 07:21, Robert Jacques wrote:
That putting isSliceOf in the public API, implies its usage by the
archiver.
Ok, then I'll remove it.
Actually it does not need to be part of the public API when I think
about it. I can move it into Serializer. Array would still need to be
public
On Tue, 04 Oct 2011 03:22:35 -0400, Jacob Carlborg d...@me.com wrote:
On 2011-10-04 07:21, Robert Jacques wrote:
[snip]
Actually it does not need to be part of the public API when I think
about it. I can move it into Serializer. Array would still need to be
public since both Serailzer and
On 2011-10-04 17:14, Robert Jacques wrote:
I'm sorry, you're right. In my mind b extended to the end of the a
array, for some reason. However, if you do define b to extend to the end
of the a array, then it can append without allocating:
auto a = [0, 1, 2, 3, 4];
auto b = a[2 .. $];
b ~= 5;
On Tue, 04 Oct 2011 12:54:27 -0400, Jacob Carlborg d...@me.com wrote:
On 2011-10-04 17:14, Robert Jacques wrote:
I'm sorry, you're right. In my mind b extended to the end of the a
array, for some reason. However, if you do define b to extend to the end
of the a array, then it can append
On 2011-10-02 00:52, Robert Jacques wrote:
On Sat, 01 Oct 2011 07:18:59 -0400, Jacob Carlborg d...@me.com wrote:
For the pre-review its okay. But you'll need it for the actual review.
Ok, it will be the same documentation as for Archive and Base. Ddoc
really needs to get better at this, I
On 2011-10-03 05:50, Robert Jacques wrote:
On Sat, 01 Oct 2011 06:50:52 -0400, Jacob Carlborg d...@me.com wrote:
On 2011-10-01 05:00, Robert Jacques wrote:
I agree, which is why I suggested lookup should have some granuality.
i.e. that there is both a global store of serialization methods and
On Mon, 03 Oct 2011 03:06:36 -0400, Jacob Carlborg d...@me.com wrote:
On 2011-10-03 05:50, Robert Jacques wrote:
On Sat, 01 Oct 2011 06:50:52 -0400, Jacob Carlborg d...@me.com wrote:
On 2011-10-01 05:00, Robert Jacques wrote:
I agree, which is why I suggested lookup should have some
On Mon, 03 Oct 2011 02:38:22 -0400, Jacob Carlborg d...@me.com wrote:
On 2011-10-02 00:52, Robert Jacques wrote:
On Sat, 01 Oct 2011 07:18:59 -0400, Jacob Carlborg d...@me.com wrote:
[snip]
Also by the time archiving is called, isSliceOf should always return
false.
Why is that?
If
On 2011-10-03 15:39, Robert Jacques wrote:
On Mon, 03 Oct 2011 03:06:36 -0400, Jacob Carlborg d...@me.com wrote:
On 2011-10-03 05:50, Robert Jacques wrote:
On Sat, 01 Oct 2011 06:50:52 -0400, Jacob Carlborg d...@me.com wrote:
On 2011-10-01 05:00, Robert Jacques wrote:
I agree, which is why
On 2011-10-03 15:57, Robert Jacques wrote:
So, in essence, you are saying that by the time archiving occurs,
isSliceOf will always return false? Then why is it part of the public API?
No, I'm not saying that. Example:
struct Array
{
void* ptr;
size_t length;
size_t
On Mon, 03 Oct 2011 14:10:52 -0400, Jacob Carlborg d...@me.com wrote:
On 2011-10-03 15:57, Robert Jacques wrote:
So, in essence, you are saying that by the time archiving occurs,
isSliceOf will always return false? Then why is it part of the public API?
No, I'm not saying that. Example:
On Sat, 01 Oct 2011 06:50:52 -0400, Jacob Carlborg d...@me.com wrote:
On 2011-10-01 05:00, Robert Jacques wrote:
I agree, which is why I suggested lookup should have some granuality.
i.e. that there is both a global store of serialization methods and a
per instance store of serialization
On 2011-10-01 05:00, Robert Jacques wrote:
I agree, which is why I suggested lookup should have some granuality.
i.e. that there is both a global store of serialization methods and a
per instance store of serialization methods. Lookup would first look in
the local store before defaulting to the
On 2011-10-01 06:29, Robert Jacques wrote:
On Thu, 29 Sep 2011 14:58:30 -0400, Jacob Carlborg d...@me.com wrote:
I would like to have some form of pre-review of my serialization library
Orange for later inclusion in Phobos as std.serialization (or similar).
[snip]
(1)
The first example in
On Sat, 01 Oct 2011 07:18:59 -0400, Jacob Carlborg d...@me.com wrote:
On 2011-10-01 06:29, Robert Jacques wrote:
On Thu, 29 Sep 2011 14:58:30 -0400, Jacob Carlborg d...@me.com wrote:
[snip]
(2)
orange.serialization.archives.XmlArchive need to be documented.
I was hoping the Archive
On 2011-09-29 21:42, Tobias Pankrath wrote:
* For the unit tests I've used my own kind of micro unit test framework
(that is included). Is that something we want to have in general in
Phobos so other modules can take advantage of that?
There should be something in Phobos. This should involve
On Thursday, September 29, 2011 20:58:30 Jacob Carlborg wrote:
* For the unit tests I've used my own kind of micro unit test framework
(that is included). Is that something we want to have in general in
Phobos so other modules can take advantage of that? Or should I just rip
out the framework?
On Thu, 29 Sep 2011 14:58:30 -0400, Jacob Carlborg d...@me.com wrote:
I would like to have some form of pre-review of my serialization library
Orange for later inclusion in Phobos as std.serialization (or similar).
[snip]
This is a quick note on the API design; I'm planning on doing a deeper
On 2011-09-30 08:39, Jonathan M Davis wrote:
On Thursday, September 29, 2011 20:58:30 Jacob Carlborg wrote:
* For the unit tests I've used my own kind of micro unit test framework
(that is included). Is that something we want to have in general in
Phobos so other modules can take advantage of
On 2011-09-30 15:03, Robert Jacques wrote:
On Thu, 29 Sep 2011 14:58:30 -0400, Jacob Carlborg d...@me.com wrote:
I would like to have some form of pre-review of my serialization library
Orange for later inclusion in Phobos as std.serialization (or similar).
[snip]
This is a quick note on the
On Friday, September 30, 2011 16:25:47 Jacob Carlborg wrote:
On 2011-09-30 08:39, Jonathan M Davis wrote:
On Thursday, September 29, 2011 20:58:30 Jacob Carlborg wrote:
* For the unit tests I've used my own kind of micro unit test
framework
(that is included). Is that something we want to
On 2011-09-30 18:09, Jonathan M Davis wrote:
That can be done easily enough with a version block with a version specific to
running longer or shorter tests. No additional framework is necessary. Don
has already brought it up in the Phobos newsgroup, but it's unclear whether
we're going to do
On Fri, 30 Sep 2011 10:41:48 -0400, Jacob Carlborg d...@me.com wrote:
On 2011-09-30 15:03, Robert Jacques wrote:
On Thu, 29 Sep 2011 14:58:30 -0400, Jacob Carlborg d...@me.com wrote:
[snip]
The method should also be static: If I'm registering a custom
serialization method, I don't want to
On Thu, 29 Sep 2011 14:58:30 -0400, Jacob Carlborg d...@me.com wrote:
I would like to have some form of pre-review of my serialization library
Orange for later inclusion in Phobos as std.serialization (or similar).
[snip]
(1)
The first example in class Serializer is:
auto serializer = new
I would like to have some form of pre-review of my serialization library
Orange for later inclusion in Phobos as std.serialization (or similar).
The reason for why I would like to have a pre-review is that Orange, in
its current state, supports both D1/Tango and D2/Phobos. I don't want to
* For the unit tests I've used my own kind of micro unit test framework
(that is included). Is that something we want to have in general in
Phobos so other modules can take advantage of that?
There should be something in Phobos. This should involve two steps.
First define a protocol, so
27 matches
Mail list logo
