On Saturday, 17 August 2013 at 08:29:37 UTC, glycerine wrote:
On Wednesday, 14 August 2013 at 13:43:50 UTC, Dicebot wrote:
On Wednesday, 14 August 2013 at 13:28:42 UTC, glycerine wrote:
Wishful thinking aside, they are competitors.
They are not. `std.serialization` does not and should not
On Saturday, 17 August 2013 at 08:29:37 UTC, glycerine wrote:
On Wednesday, 14 August 2013 at 13:43:50 UTC, Dicebot wrote:
On Wednesday, 14 August 2013 at 13:28:42 UTC, glycerine wrote:
Wishful thinking aside, they are competitors.
They are not. `std.serialization` does not and should not
On Saturday, 17 August 2013 at 08:29:37 UTC, glycerine wrote:
On Wednesday, 14 August 2013 at 13:43:50 UTC, Dicebot wrote:
On Wednesday, 14 August 2013 at 13:28:42 UTC, glycerine wrote:
Wishful thinking aside, they are competitors.
They are not. `std.serialization` does not and should not
I'd like to start off by saying I don't really know what I want
from a std.serialize module. I've done some work with a C# JSON
serializer and dealt with Protocol Buffers.
This library looks to be providing a means to serialize any D
data structure. It deals with
On 2013-08-14 21:55, ilya-stromberg wrote:
Can you use another serialization format and supports file output for
it? For example, can you use JSON, BSON or binary format?
The idea of the library is that it can support multiple archive types.
Currently only XML is implemented. I have been
On Tuesday, 13 August 2013 at 15:04:38 UTC, Jacob Carlborg wrote:
There's a fully working example here:
https://dl.dropboxusercontent.com/u/18386187/docs/std.serialization/std_serialization_serializer.html
Sorry, I think that example is WRONG!
Your example:
void main ()
{
auto archive =
On Tuesday, 13 August 2013 at 22:54:05 UTC, glycerine wrote:
...
Jacob, can you add a high-level overview which answers this
questions? (in any place you find convenient, until proper place
for package-wide documentation is decided).
On Wednesday, 14 August 2013 at 02:32:20 UTC, Jonathan M Davis
wrote:
In general, the tests should be right after the functions that
they're testing
and not in a separate file. I don't know that it's never
appropriate to put the
tests in a separate file, but none of Phobos does this right
now,
On 2013-08-14 08:29, ilya-stromberg wrote:
Sorry, I think that example is WRONG!
Your example:
void main ()
{
auto archive = new XmlArchive!();
auto serializer = new Serializer;
auto foo = new Foo;
foo.a = 3;
serializer.serialize(foo);
auto foo2 =
On Wednesday, 14 August 2013 at 07:29:48 UTC, Jacob Carlborg
wrote:
Note that current DDocs version supports to generate
documentation from
unittests - it lets as make shure that documentation is
correct. Shall
we add the condition of examples generation from unittests as
required?
How do I
On 2013-08-14 09:19, Dicebot wrote:
Jacob, can you add a high-level overview which answers this questions?
(in any place you find convenient, until proper place for package-wide
documentation is decided).
Yes, I could do that.
--
/Jacob Carlborg
On 2013-08-14 09:32, Dicebot wrote:
http://dlang.org/changelog.html#documentedunittest
Thanks.
--
/Jacob Carlborg
On 2013-08-14 00:54, glycerine wrote:
I'm included to prefer the Thrift bindings over Orange since I need
binary compression and type safety (XML??? yikes), inter-language
operability, and most essentially, data versioning.
Nonetheless, in order to make a realistic comparison and evaulation, I
On 2013-08-14 09:19, Dicebot wrote:
Jacob, can you add a high-level overview which answers this questions?
(in any place you find convenient, until proper place for package-wide
documentation is decided).
Actually, I'm not so sure about that. He wants me to do a comparison to
Thrift.
--
On Wednesday, 14 August 2013 at 07:43:22 UTC, Jacob Carlborg
wrote:
On 2013-08-14 09:19, Dicebot wrote:
Jacob, can you add a high-level overview which answers this
questions?
(in any place you find convenient, until proper place for
package-wide
documentation is decided).
Actually, I'm not
On 2013-08-14 09:46, Dicebot wrote:
I did not mean to answer these questions specifically - just provide a
high-level overview of what std.serialization is. Architecture, use case
domain etc. - to avoid similar confusion from people exploring standard
library documentation. If such
Serious:
- doesn't use ranges
- does this store the entire serialized output in memory?
- I would to serialize to a range (file?) and deserialize from
a range (file?)
Minor
- Indentation messed up in Serializable example
- Typo: NonSerialized example should read NonSerialized!(b)
On 2013-08-14 10:19, Tyler Jameson Little wrote:
Serious:
- doesn't use ranges
- does this store the entire serialized output in memory?
That's up to the archive how it chooses to implement it. But the current
XmlArchive does so, yes. I becomes quite limited because of std.xml.
- I
On Wednesday, 14 August 2013 at 08:48:23 UTC, Jacob Carlborg
wrote:
On 2013-08-14 10:19, Tyler Jameson Little wrote:
- Typo: NonSerialized example should read NonSerialized!(b)
No, it's not a typo. If you read the documentation you'll see
that:
If no fields or this is specified, it
On Wednesday, 14 August 2013 at 08:48:23 UTC, Jacob Carlborg
wrote:
On 2013-08-14 10:19, Tyler Jameson Little wrote:
Serious:
- doesn't use ranges
- does this store the entire serialized output in memory?
That's up to the archive how it chooses to implement it. But
the current XmlArchive
On 2013-08-14 11:15, Tyler Jameson Little wrote:
Well, std.xml needs to be replaced anyway, so it's probably not a good
limitation to have. It may take some work to replace it correctly though...
No, but should std.serialization be on hold until std.xml is replaced?
I'm mostly interested in
On 2013-08-14 11:25, Tyler Jameson Little wrote:
I like this a lot more. Phobos just needs to be compatible with the
current release, so backwards compat is a non-issue here.
I guess this is why we have this thread. I would like to hear comments
from a couple of others as well about this
On Wednesday, 14 August 2013 at 09:17:44 UTC, Tove wrote:
On Wednesday, 14 August 2013 at 08:48:23 UTC, Jacob Carlborg
wrote:
On 2013-08-14 10:19, Tyler Jameson Little wrote:
- Typo: NonSerialized example should read NonSerialized!(b)
No, it's not a typo. If you read the documentation you'll
On 2013-08-14 11:17, Tove wrote:
I understand the need for Orange to be backwards compatible, but for
std.serialization, why isn't the old-style mixin simply removed in favor
of the UDA.
I don't know, it doesn't really hurt to be present. And for anyone using
Orange they only need to change
On Wednesday, 14 August 2013 at 07:40:13 UTC, Jacob Carlborg
wrote:
I have documented the package for what it is, not for what it's
not. It's a package for serialization, not a RCP or network
package
You seem to like me to write a comparison to Thrift in the
documentation. You have to
On Wednesday, 14 August 2013 at 13:28:42 UTC, glycerine wrote:
Wishful thinking aside, they are competitors.
They are not. `std.serialization` does not and should not compete
in Thrift domain. In fact, if something like this can be found in
proposal you should point to it and it will be
On Wednesday, 14 August 2013 at 09:28:20 UTC, Jacob Carlborg
wrote:
On 2013-08-14 11:25, Tyler Jameson Little wrote:
I like this a lot more. Phobos just needs to be compatible
with the
current release, so backwards compat is a non-issue here.
I guess this is why we have this thread. I would
On 2013-08-14 16:15, ilya-stromberg wrote:
I think we should avoid mixins as much as it possible.
UDA @nonSerialized looks much better, so I think we should use it.
Of course, we can leave template NonSerialized(Fields...) for backwards
compatible with Orange and, maybe, deprecate it.
Of
On Wednesday, 14 August 2013 at 14:34:58 UTC, Jacob Carlborg
wrote:
Should it be included and deprecated or should it just be
included?
What is the point of including something into Phobos and
immediately deprecating it? It is first inclusion, so there are
no backwards compatibility
On Wednesday, 14 August 2013 at 14:50:45 UTC, ilya-stromberg
wrote:
I did not use Orange at all.
But the most terrible for library is losing backwards
compatiblity. So, if Orange uses NonSerialized, we have to
include it. We can just add documentation notice that
NonSerialized will be
On Wednesday, 14 August 2013 at 14:34:58 UTC, Jacob Carlborg
wrote:
On 2013-08-14 16:15, ilya-stromberg wrote:
I think we should avoid mixins as much as it possible.
UDA @nonSerialized looks much better, so I think we should use
it.
Of course, we can leave template NonSerialized(Fields...)
On Wednesday, 14 August 2013 at 14:34:58 UTC, Jacob Carlborg
wrote:
On 2013-08-14 16:15, ilya-stromberg wrote:
I think we should avoid mixins as much as it possible.
UDA @nonSerialized looks much better, so I think we should use
it.
Of course, we can leave template NonSerialized(Fields...)
On 2013-08-14 17:08, Kapps wrote:
If you had UDAs available to you from the start, would you have included the
mixins?
No.
If not, why include them now?
You do have a point.
--
/Jacob Carlborg
On 8/14/13 1:48 AM, Jacob Carlborg wrote:
On 2013-08-14 10:19, Tyler Jameson Little wrote:
- I would to serialize to a range (file?) and deserialize from a
range (file?)
The serialized data is returned as an array, so that is compatible with
the range interface, it just won't be lazy.
On 8/14/13 12:10 PM, Jacob Carlborg wrote:
On 2013-08-14 18:25, Andrei Alexandrescu wrote:
This seems like a major limitation. (Disclaimer: I haven't read the
documentation yet.)
The data is built up as a DOM (with the XmlArchive) using std.xml. I
should I get a range out of that?
I'm
On 2013-08-14 18:25, Andrei Alexandrescu wrote:
This seems like a major limitation. (Disclaimer: I haven't read the
documentation yet.)
The data is built up as a DOM (with the XmlArchive) using std.xml. I
should I get a range out of that?
--
/Jacob Carlborg
On 2013-08-14 21:11, Andrei Alexandrescu wrote:
I'm thinking some people may need to stream to/from large files and
would find the requirement of in-core representation limiting.
Yes, I understand that. But currently I'm limited by std.xml.
--
/Jacob Carlborg
On Wed, Aug 14, 2013 at 09:23:50PM +0200, Jacob Carlborg wrote:
On 2013-08-14 21:11, Andrei Alexandrescu wrote:
I'm thinking some people may need to stream to/from large files and
would find the requirement of in-core representation limiting.
Yes, I understand that. But currently I'm
On Wednesday, 14 August 2013 at 19:23:51 UTC, Jacob Carlborg
wrote:
On 2013-08-14 21:11, Andrei Alexandrescu wrote:
I'm thinking some people may need to stream to/from large
files and
would find the requirement of in-core representation limiting.
Yes, I understand that. But currently I'm
On 2013-08-14 21:40, H. S. Teoh wrote:
Would it be possible to present a range *interface*, that currently just
converts to array (or aliases to array if it's already an array), so
that in the future, when std.xml is revamped to use ranges, existing
code will automatically reap the benefits?
On Wednesday, 14 August 2013 at 19:55:52 UTC, ilya-stromberg
wrote:
On Wednesday, 14 August 2013 at 19:23:51 UTC, Jacob Carlborg
wrote:
On 2013-08-14 21:11, Andrei Alexandrescu wrote:
I'm thinking some people may need to stream to/from large
files and
would find the requirement of in-core
On Wednesday, August 14, 2013 16:54:59 Dicebot wrote:
std.serialization is not Orange and should not be considered as
one. Once it is included into Phobos it is a brand new library
and must be treated as such, no matter what origin it has. Users
of Orange expect compatibility from Orange, not
On Monday, 12 August 2013 at 19:55:01 UTC, Jacob Carlborg wrote:
I don't think a pull request should be made before a module has
gone through the review queue and is approved. With Github it's
easy to diff between a fork and upstream:
2 everyone: should I interpret lack of activity as lack of
interest in getting this into Phobos or lack of issues to comment
on? ;)
On 08/12/2013 03:27 PM, Dicebot wrote:
Stepping up to act as a Review Manager for Jacob Carlborg std.serialization
Input
Code: https://github.com/jacob-carlborg/phobos/tree/serialization
Documentation:
https://dl.dropboxusercontent.com/u/18386187/docs/std.serialization/index.html
13-Aug-2013 17:15, Dicebot пишет:
2 everyone: should I interpret lack of activity as lack of interest in
getting this into Phobos or lack of issues to comment on? ;)
Give us some time darn it ;)
--
Dmitry Olshansky
13-Aug-2013 16:48, Dicebot пишет:
On Monday, 12 August 2013 at 19:55:01 UTC, Jacob Carlborg wrote:
I don't think a pull request should be made before a module has gone
through the review queue and is approved. With Github it's easy to
diff between a fork and upstream:
On 2013-08-13 15:33, Tobias Pankrath wrote:
I had no look at the code, but just opened the documentation, asking the
question: What do I need to do to serialize this graph data structure,
I have here?. The documentation does not seem to give a straight answer.
There's a fully working example
On 2013-08-13 16:34, Dmitry Olshansky wrote:
IMHO a good idea to have a non-trivial test suite to be separate so that
it doesn't not clutter other module(s). That said isolated tests for
individual pieces and internal stuff are better kept together with the
code they test.
They are of a high
On Tuesday, 13 August 2013 at 14:35:06 UTC, Dmitry Olshansky
wrote:
IMHO a good idea to have a non-trivial test suite to be
separate so that it doesn't not clutter other module(s). That
said isolated tests for individual pieces and internal stuff
are better kept together with the code they
On Tuesday, 13 August 2013 at 15:04:38 UTC, Jacob Carlborg wrote:
I worked quite hard with the documentation. There are code
examples here as well, I just don't know where to put them in
Phobos:
https://github.com/jacob-carlborg/orange/wiki/_pages
Two random proposals for discussion:
1)
On 2013-08-13 17:09, Dicebot wrote:
What do you think about having top-level folder with functional tests
for a more complex packages?
I think that's a good idea.
--
/Jacob Carlborg
On 2013-08-13 17:12, Dicebot wrote:
2) Create a devoted `examples` module which is not imported in
`package.d` but is available in documentation.
I'm wondering if the package.d module could be used for this, somehow.
--
/Jacob Carlborg
On 2013-08-12 15:27, Dicebot wrote:
Jacob, it is probably worth creating a pull request with latest rebased
version of your proposal to simplify getting a quick overview of
changes. Also please tell if there is anything you want/need to
implement before merging.
I have rebased now.
--
/Jacob
On Tuesday, 13 August 2013 at 15:12:40 UTC, Dicebot wrote:
On Tuesday, 13 August 2013 at 15:04:38 UTC, Jacob Carlborg
wrote:
I worked quite hard with the documentation. There are code
examples here as well, I just don't know where to put them in
Phobos:
On Monday, August 12, 2013 21:55:00 Jacob Carlborg wrote:
* I forgot to add that the unit tests are, a bit controversial, located
in std.serialization.tests
In general, the tests should be right after the functions that they're testing
and not in a separate file. I don't know that it's never
Stepping up to act as a Review Manager for Jacob Carlborg
std.serialization
Input
Code: https://github.com/jacob-carlborg/phobos/tree/serialization
Documentation:
https://dl.dropboxusercontent.com/u/18386187/docs/std.serialization/index.html
Previous review thread:
On 2013-08-12 15:27, Dicebot wrote:
Jacob, it is probably worth creating a pull request with latest rebased
version of your proposal to simplify getting a quick overview of
changes.
I don't think a pull request should be made before a module has gone
through the review queue and is approved.
101 - 158 of 158 matches
Mail list logo
