Yes, you have to specify what char type to use as a template parameter.

On 15 nov 2010, at 20:08, Sean Kelly wrote:

> I think the Tango parser is fast for two reasons. First, it doesn't allocate at all and second, it doesn't decode the string data--that's left up to the user. Even XercesC converts data to a specific encoding before the user sees it (some variant of wchar_t I believe).  I don't know how Tango handles XML streams in different encodings, but perhaps it's a template on char type?
> 
> Sent from my iPhone
> 
> On Nov 14, 2010, at 10:39 PM, Jacob Carlborg <doob at me.com> wrote:
> 
>> I don't know why Phobos is so slow but what I've heard Tango is fast because it never copies the input buffer, what I've heard.
>> 
>> On 14 nov 2010, at 16:10, SHOO wrote:
>> 
>>> LOL! This is terrible!
>>> 
>>> The performance is not so important for me, but this report moves me to tears. What is a bottleneck?
>>> 
>>> --
>>> SHOO
>>> 
>>> (2010/11/14 21:55), Jacob Carlborg wrote:
>>>> A benchmark has shown that the Tango XML module is a lot faster than many of the XML libraries out there, specially than the Phobos module. So I would say that D could do better than other libraries at least when it comes to speed.
>>>> 
>>>> http://dotnot.org/blog/archives/2008/03/10/xml-benchmarks-updated-graphs-with-rapidxml/
>>>> 
>>>> On 14 nov 2010, at 10:44, Russel Winder wrote:
>>>> 
>>>>> On Sun, 2010-11-14 at 15:35 +0900, SHOO wrote:
>>>>>> About a problem of std.xml.
>>>>> 
>>>>> Potentially n00b comment but . . .
>>>>> 
>>>>> The Python community seem to be giving up on having their own library for processing XML and are using bindings to libxml2 and libxslt.  Is it likely that a D source XML library can do better than libxml2 and libxslt or might it be better just to create a D idiomatic binding?
>>>>> 
>>>>> --
>>>>> Russel.
>>>>> =============================================================================
>>>>> Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
>>>>> 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at russel.org.uk
>>>>> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>>>>> _______________________________________________
>>>>> phobos mailing list
>>>>> phobos at puremagic.com
>>>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>>> 
>>> _______________________________________________
>>> phobos mailing list
>>> phobos at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>> 
>> -- 
>> /Jacob Carlborg
>> 
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

-- 
/Jacob Carlborg

std.serialize and std.event. They're not in trunk but maybe someone is working on them, I don't know. But they have been talked about.

On 14 nov 2010, at 15:14, SHOO wrote:

> Because I don't understand which you point out, I cannot answer precisely.
> However, IIRC these items are talked about in the past a half year or are commented by Phobos's codes.
> 
> --
> SHOO
> 
> (2010/11/14 21:57), Jacob Carlborg wrote:
>> Some of these don't exist yet, if I'm not mistaken?
>> 
>> On 14 nov 2010, at 09:05, SHOO wrote:
>> 
>>> I think that it is important that we prioritize our to-do list.
>>> 
>>> Therefore I think that firstly we should make a list. Next, it is necessary for us to clarify the problem that each item has.
>>> 
>>> I show following list the thing which I hit on:
>>> - std.stream, I/O (replace, enhance)
>>> - std.xml (replace?)
>>> - std.json (replace?)
>>> - std.datetime (replace, enhance)
>>> - scope/RAII (replace, enhance)
>>> - std.scoket / asio (replace)
>>> - std.event (enhance)
>>> - std.serialize (enhance)
>>> - documents (enhance)
>>> - std.process (enhance)
>>> - std.path, std.file (enhance)
>>> - pure (apply)
>>> - nothrow (apply)
>>> - @safe/@trusted/@system (apply)
>>> - shared (enhance, bug fix)
>>> - GC (enhance)
>>> - std.container (enhance)
>>> - opDollars (enhance, apply)
>>> - and some voted bugs (bug fix)
>>> (I only enumerate of the list at this stage, and omit the detailed explanation.)
>>> 
>>> Are there items else?
>>> 
>>> --
>>> SHOO
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

-- 
/Jacob Carlborg

That was an old list.  As long as the author listed next to the module isn't the current author, we're good :-)

On Nov 16, 2010, at 3:49 AM, Masahiro Nakagawa wrote:

> In the trunk, I already replaced base64 module.
> 
> 
> Masahiro
> 
> On Tue, 16 Nov 2010 06:42:09 +0900, Sean Kelly <sean at invisibleduck.org> wrote:
> 
>> These are the modules that couldn't be moved to the Boost license for one reason or another.  They should all be removed or replaced:
>> 
>> base64 - Chris Miller
>> loader - Matthew Wilson
>> md5 - RSA Data Security
>> openrj - Matthew Wilson
>> perf - Matthew Wilson
>> socket - Chris Miller
>> socketstream - Chris Miller
>> stream - Pavel Minayev
>> 
>> On Nov 14, 2010, at 12:05 AM, SHOO wrote:
>> 
>>> I think that it is important that we prioritize our to-do list.
>>> 
>>> Therefore I think that firstly we should make a list. Next, it is necessary for us to clarify the problem that each item has.
>>> 
>>> I show following list the thing which I hit on:
>>> - std.stream, I/O (replace, enhance)
>>> - std.xml (replace?)
>>> - std.json (replace?)
>>> - std.datetime (replace, enhance)
>>> - scope/RAII (replace, enhance)
>>> - std.scoket / asio (replace)
>>> - std.event (enhance)
>>> - std.serialize (enhance)
>>> - documents (enhance)
>>> - std.process (enhance)
>>> - std.path, std.file (enhance)
>>> - pure (apply)
>>> - nothrow (apply)
>>> - @safe/@trusted/@system (apply)
>>> - shared (enhance, bug fix)
>>> - GC (enhance)
>>> - std.container (enhance)
>>> - opDollars (enhance, apply)
>>> - and some voted bugs (bug fix)
>>> (I only enumerate of the list at this stage, and omit the detailed explanation.)
>>> 
>>> Are there items else?
>>> 
>>> --
>>> SHOO
>>> 
>>> (2010/11/14 14:52), Jonathan M Davis wrote:
>>>> We have several modules in Phobos which are supposedly going to be deprecated in favor of better implementations (std.stream, std.xml, std.json, etc). As I understand it, this is primarily because the code isn't being maintained, is poorly designed for D2 (possibly because it isn't range-centric or just hasn't been updated with D2-only features), and/or lacks a maintainer/champion. In addition to that, there's various types of functionality which should probably be in Phobos but haven't been done yet.
>>>> 
>>>> The Phobos developers only have so much time on their hands, and some portion of this kind of work is going to need to be done by people who are not currently on the Phobos team. That, and we seem to be adopting the idea that the ideal situation is for each module to have a "champion" of sorts who is behind the module, working to fix bugs on it and make it better.
>>>> 
>>>> So, I was wondering if what we should do is figure out what some of the modules are that we want in Phobos - and in particular the ones currently in Phobos which need to be overhauled - and then post on the main D list looking for people willing to take them on. We don't want to a flood of code that needs to be reviewed for inclusion in Phobos, but if we want to get a lot of this stuff done, we need more people working on it - particularly people who are really looking to focus on it and champion it.
>>>> 
>>>> So, I'm suggesting that we identify the top priority module which aren't likely to be done by Phobos developers any time soon and see if we can get others in the D community to do them. In particular, it's a problem that we have several modules which we intend to replace. The longer that we wait, the more code that will be written using the old modules, and the more code which will break when they get replaced.
>>>> 
>>>> - Jonathan M Davis
>>> _______________________________________________
>>> phobos mailing list
>>> phobos at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>> 
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

I don't know it about this matter so deeply. Perhaps you are understanding it more precisely than me. This will be preaching to the choir...

Nakagawa Masahiro did porting of MessagePack to D.
This module is aimed for serialization and can convert data structure
with character string mutually.
The main purpose of serialization of MessagePack is to hand data beyond
programs and development languages.
And it is std.event to offer mechanism about the communication of the
data which transcended programs/processes.

Alternatively, there is a serialization library called Orange.
The main purpose of serialization of Orange is a save and the
reconstruction of the object which transcended thread and time on the
same program.

Because these are different in a purpose definitely, I think that it is good that both with good interface are included in Phobos.

--
SHOO

(2010/11/16 22:26), Jacob Carlborg wrote:
> std.serialize and std.event. They're not in trunk but maybe someone is working on them, I don't know. But they have been talked about.
>
> On 14 nov 2010, at 15:14, SHOO wrote:
>
>> Because I don't understand which you point out, I cannot answer precisely.
>> However, IIRC these items are talked about in the past a half year or are commented by Phobos's codes.
>>
>> --
>> SHOO
>>
>> (2010/11/14 21:57), Jacob Carlborg wrote:
>>> Some of these don't exist yet, if I'm not mistaken?
>>>
>>> On 14 nov 2010, at 09:05, SHOO wrote:
>>>
>>>> I think that it is important that we prioritize our to-do list.
>>>>
>>>> Therefore I think that firstly we should make a list. Next, it is necessary for us to clarify the problem that each item has.
>>>>
>>>> I show following list the thing which I hit on:
>>>> - std.stream, I/O (replace, enhance)
>>>> - std.xml (replace?)
>>>> - std.json (replace?)
>>>> - std.datetime (replace, enhance)
>>>> - scope/RAII (replace, enhance)
>>>> - std.scoket / asio (replace)
>>>> - std.event (enhance)
>>>> - std.serialize (enhance)
>>>> - documents (enhance)
>>>> - std.process (enhance)
>>>> - std.path, std.file (enhance)
>>>> - pure (apply)
>>>> - nothrow (apply)
>>>> - @safe/@trusted/@system (apply)
>>>> - shared (enhance, bug fix)
>>>> - GC (enhance)
>>>> - std.container (enhance)
>>>> - opDollars (enhance, apply)
>>>> - and some voted bugs (bug fix)
>>>> (I only enumerate of the list at this stage, and omit the detailed explanation.)
>>>>
>>>> Are there items else?
>>>>
>>>> --
>>>> SHOO
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>

std.perf shifts to std.datetime (StopWatch).

It's in trunk, but it is not yet active now. By a migration of std.date/std.gregorian, there may be the change of some name.

Jonathan is working, but it's very very huge now. So, it will be changed more compact and useful design in future.

--
SHOO

(2010/11/16 6:42), Sean Kelly wrote:
> These are the modules that couldn't be moved to the Boost license for one reason or another.  They should all be removed or replaced:
>
> base64 - Chris Miller
> loader - Matthew Wilson
> md5 - RSA Data Security
> openrj - Matthew Wilson
> perf - Matthew Wilson
> socket - Chris Miller
> socketstream - Chris Miller
> stream - Pavel Minayev
>
> On Nov 14, 2010, at 12:05 AM, SHOO wrote:
>
>> I think that it is important that we prioritize our to-do list.
>>
>> Therefore I think that firstly we should make a list. Next, it is necessary for us to clarify the problem that each item has.
>>
>> I show following list the thing which I hit on:
>> - std.stream, I/O (replace, enhance)
>> - std.xml (replace?)
>> - std.json (replace?)
>> - std.datetime (replace, enhance)
>> - scope/RAII (replace, enhance)
>> - std.scoket / asio (replace)
>> - std.event (enhance)
>> - std.serialize (enhance)
>> - documents (enhance)
>> - std.process (enhance)
>> - std.path, std.file (enhance)
>> - pure (apply)
>> - nothrow (apply)
>> - @safe/@trusted/@system (apply)
>> - shared (enhance, bug fix)
>> - GC (enhance)
>> - std.container (enhance)
>> - opDollars (enhance, apply)
>> - and some voted bugs (bug fix)
>> (I only enumerate of the list at this stage, and omit the detailed explanation.)
>>
>> Are there items else?
>>
>> --
>> SHOO
>>
>> (2010/11/14 14:52), Jonathan M Davis wrote:
>>> We have several modules in Phobos which are supposedly going to be deprecated in favor of better implementations (std.stream, std.xml, std.json, etc). As I understand it, this is primarily because the code isn't being maintained, is poorly designed for D2 (possibly because it isn't range-centric or just hasn't been updated with D2-only features), and/or lacks a maintainer/champion. In addition to that, there's various types of functionality which should probably be in Phobos but haven't been done yet.
>>>
>>> The Phobos developers only have so much time on their hands, and some portion of this kind of work is going to need to be done by people who are not currently on the Phobos team. That, and we seem to be adopting the idea that the ideal situation is for each module to have a "champion" of sorts who is behind the module, working to fix bugs on it and make it better.
>>>
>>> So, I was wondering if what we should do is figure out what some of the modules are that we want in Phobos - and in particular the ones currently in Phobos which need to be overhauled - and then post on the main D list looking for people willing to take them on. We don't want to a flood of code that needs to be reviewed for inclusion in Phobos, but if we want to get a lot of this stuff done, we need more people working on it - particularly people who are really looking to focus on it and champion it.
>>>
>>> So, I'm suggesting that we identify the top priority module which aren't likely to be done by Phobos developers any time soon and see if we can get others in the D community to do them. In particular, it's a problem that we have several modules which we intend to replace. The longer that we wait, the more code that will be written using the old modules, and the more code which will break when they get replaced.
>>>
>>> - Jonathan M Davis
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos

socket and socketstream depend on D's I/O design.
Because there are many things depending on I/O else, I think that the
importance of the I/O is high.

--
SHOO

(2010/11/16 6:42), Sean Kelly wrote:
> These are the modules that couldn't be moved to the Boost license for one reason or another.  They should all be removed or replaced:
>
> base64 - Chris Miller
> loader - Matthew Wilson
> md5 - RSA Data Security
> openrj - Matthew Wilson
> perf - Matthew Wilson
> socket - Chris Miller
> socketstream - Chris Miller
> stream - Pavel Minayev
>
> On Nov 14, 2010, at 12:05 AM, SHOO wrote:
>
>> I think that it is important that we prioritize our to-do list.
>>
>> Therefore I think that firstly we should make a list. Next, it is necessary for us to clarify the problem that each item has.
>>
>> I show following list the thing which I hit on:
>> - std.stream, I/O (replace, enhance)
>> - std.xml (replace?)
>> - std.json (replace?)
>> - std.datetime (replace, enhance)
>> - scope/RAII (replace, enhance)
>> - std.scoket / asio (replace)
>> - std.event (enhance)
>> - std.serialize (enhance)
>> - documents (enhance)
>> - std.process (enhance)
>> - std.path, std.file (enhance)
>> - pure (apply)
>> - nothrow (apply)
>> - @safe/@trusted/@system (apply)
>> - shared (enhance, bug fix)
>> - GC (enhance)
>> - std.container (enhance)
>> - opDollars (enhance, apply)
>> - and some voted bugs (bug fix)
>> (I only enumerate of the list at this stage, and omit the detailed explanation.)
>>
>> Are there items else?
>>
>> --
>> SHOO
>>
>> (2010/11/14 14:52), Jonathan M Davis wrote:
>>> We have several modules in Phobos which are supposedly going to be deprecated in favor of better implementations (std.stream, std.xml, std.json, etc). As I understand it, this is primarily because the code isn't being maintained, is poorly designed for D2 (possibly because it isn't range-centric or just hasn't been updated with D2-only features), and/or lacks a maintainer/champion. In addition to that, there's various types of functionality which should probably be in Phobos but haven't been done yet.
>>>
>>> The Phobos developers only have so much time on their hands, and some portion of this kind of work is going to need to be done by people who are not currently on the Phobos team. That, and we seem to be adopting the idea that the ideal situation is for each module to have a "champion" of sorts who is behind the module, working to fix bugs on it and make it better.
>>>
>>> So, I was wondering if what we should do is figure out what some of the modules are that we want in Phobos - and in particular the ones currently in Phobos which need to be overhauled - and then post on the main D list looking for people willing to take them on. We don't want to a flood of code that needs to be reviewed for inclusion in Phobos, but if we want to get a lot of this stuff done, we need more people working on it - particularly people who are really looking to focus on it and champion it.
>>>
>>> So, I'm suggesting that we identify the top priority module which aren't likely to be done by Phobos developers any time soon and see if we can get others in the D community to do them. In particular, it's a problem that we have several modules which we intend to replace. The longer that we wait, the more code that will be written using the old modules, and the more code which will break when they get replaced.
>>>
>>> - Jonathan M Davis
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos

My point was that those modules (std.serialize and std.event) currently don't exist in Phobos. I though it was worth mentioning that on your list they could have been marked as "don't exist yet". I think your descriptions of the libraries/modules are accurate.

About Orange, I offered Orange for inclusion in Phobos, I got some replies at this mailing list which indicated some form of interest but then it kind of died out and nothing happened. Currently I'm refactoring the API and making some types into reference types that were handled as value types before. Maybe I get a better luck the second time.

On 16 nov 2010, at 19:18, SHOO wrote:

> I don't know it about this matter so deeply. Perhaps you are understanding it more precisely than me. This will be preaching to the choir...
> 
> Nakagawa Masahiro did porting of MessagePack to D.
> This module is aimed for serialization and can convert data structure with character string mutually.
> The main purpose of serialization of MessagePack is to hand data beyond programs and development languages.
> And it is std.event to offer mechanism about the communication of the data which transcended programs/processes.
> 
> Alternatively, there is a serialization library called Orange.
> The main purpose of serialization of Orange is a save and the reconstruction of the object which transcended thread and time on the same program.
> 
> Because these are different in a purpose definitely, I think that it is good that both with good interface are included in Phobos.
> 
> --
> SHOO
> 
> (2010/11/16 22:26), Jacob Carlborg wrote:
>> std.serialize and std.event. They're not in trunk but maybe someone is working on them, I don't know. But they have been talked about.
>> 
>> On 14 nov 2010, at 15:14, SHOO wrote:
>> 
>>> Because I don't understand which you point out, I cannot answer precisely.
>>> However, IIRC these items are talked about in the past a half year or are commented by Phobos's codes.
>>> 
>>> --
>>> SHOO
>>> 
>>> (2010/11/14 21:57), Jacob Carlborg wrote:
>>>> Some of these don't exist yet, if I'm not mistaken?
>>>> 
>>>> On 14 nov 2010, at 09:05, SHOO wrote:
>>>> 
>>>>> I think that it is important that we prioritize our to-do list.
>>>>> 
>>>>> Therefore I think that firstly we should make a list. Next, it is necessary for us to clarify the problem that each item has.
>>>>> 
>>>>> I show following list the thing which I hit on:
>>>>> - std.stream, I/O (replace, enhance)
>>>>> - std.xml (replace?)
>>>>> - std.json (replace?)
>>>>> - std.datetime (replace, enhance)
>>>>> - scope/RAII (replace, enhance)
>>>>> - std.scoket / asio (replace)
>>>>> - std.event (enhance)
>>>>> - std.serialize (enhance)
>>>>> - documents (enhance)
>>>>> - std.process (enhance)
>>>>> - std.path, std.file (enhance)
>>>>> - pure (apply)
>>>>> - nothrow (apply)
>>>>> - @safe/@trusted/@system (apply)
>>>>> - shared (enhance, bug fix)
>>>>> - GC (enhance)
>>>>> - std.container (enhance)
>>>>> - opDollars (enhance, apply)
>>>>> - and some voted bugs (bug fix)
>>>>> (I only enumerate of the list at this stage, and omit the detailed explanation.)
>>>>> 
>>>>> Are there items else?
>>>>> 
>>>>> --
>>>>> SHOO
>>> _______________________________________________
>>> phobos mailing list
>>> phobos at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

-- 
/Jacob Carlborg

On Wed, 17 Nov 2010 03:18:17 +0900, SHOO <zan77137 at nifty.com> wrote:

> I don't know it about this matter so deeply. Perhaps you are understanding it more precisely than me. This will be preaching to the choir...
>
> Nakagawa Masahiro did porting of MessagePack to D.
> This module is aimed for serialization and can convert data structure
> with character string mutually.
> The main purpose of serialization of MessagePack is to hand data beyond
> programs and development languages.
> And it is std.event to offer mechanism about the communication of the
> data which transcended programs/processes.

I think the review of std.msgpack is done.
But I will replace MPObject implementation with std.variant before adding
to Phobos.
Unfortunately, this progress is stopped because This[strng] causes
compilation error :(

As an aside, I have very interesting ticket in Cassandra ITS. https://issues.apache.org/jira/browse/CASSANDRA-1735

I think std.event is very important module.
The RPC part of std.msgpack and the interprocess communication of
std.concurrency require std.event.
IIRC, someone suggested libev and libev wrapper in this ML.
But, I don't know the current status of std.event.

As I've said before, new std.socket doesn't provide select function.

> Alternatively, there is a serialization library called Orange.
> The main purpose of serialization of Orange is a save and the
> reconstruction of the object which transcended thread and time on the
> same program.

Yeah. Orange is a good candidate for std.serialization as language specific serialization.

> Because these are different in a purpose definitely, I think that it is good that both with good interface are included in Phobos.

I agree.

> --
> SHOO
>
> (2010/11/16 22:26), Jacob Carlborg wrote:
>> std.serialize and std.event. They're not in trunk but maybe someone is working on them, I don't know. But they have been talked about.
>>
>> On 14 nov 2010, at 15:14, SHOO wrote:
>>
>>> Because I don't understand which you point out, I cannot answer
>>> precisely.
>>> However, IIRC these items are talked about in the past a half year or
>>> are commented by Phobos's codes.
>>>
>>> --
>>> SHOO
>>>
>>> (2010/11/14 21:57), Jacob Carlborg wrote:
>>>> Some of these don't exist yet, if I'm not mistaken?
>>>>
>>>> On 14 nov 2010, at 09:05, SHOO wrote:
>>>>
>>>>> I think that it is important that we prioritize our to-do list.
>>>>>
>>>>> Therefore I think that firstly we should make a list. Next, it is necessary for us to clarify the problem that each item has.
>>>>>
>>>>> I show following list the thing which I hit on:
>>>>> - std.stream, I/O (replace, enhance)
>>>>> - std.xml (replace?)
>>>>> - std.json (replace?)
>>>>> - std.datetime (replace, enhance)
>>>>> - scope/RAII (replace, enhance)
>>>>> - std.scoket / asio (replace)
>>>>> - std.event (enhance)
>>>>> - std.serialize (enhance)
>>>>> - documents (enhance)
>>>>> - std.process (enhance)
>>>>> - std.path, std.file (enhance)
>>>>> - pure (apply)
>>>>> - nothrow (apply)
>>>>> - @safe/@trusted/@system (apply)
>>>>> - shared (enhance, bug fix)
>>>>> - GC (enhance)
>>>>> - std.container (enhance)
>>>>> - opDollars (enhance, apply)
>>>>> - and some voted bugs (bug fix)
>>>>> (I only enumerate of the list at this stage, and omit the detailed
>>>>> explanation.)
>>>>>
>>>>> Are there items else?
>>>>>
>>>>> --
>>>>> SHOO
>>> _______________________________________________
>>> phobos mailing list
>>> phobos at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

On Thu, 18 Nov 2010 04:06:24 -0500, Masahiro Nakagawa <repeatedly at gmail.com> wrote:
> On Wed, 17 Nov 2010 03:18:17 +0900, SHOO <zan77137 at nifty.com> wrote:
>
>> I don't know it about this matter so deeply. Perhaps you are understanding it more precisely than me. This will be preaching to the choir...
>>
>> Nakagawa Masahiro did porting of MessagePack to D.
>> This module is aimed for serialization and can convert data structure
>> with character string mutually.
>> The main purpose of serialization of MessagePack is to hand data beyond
>> programs and development languages.
>> And it is std.event to offer mechanism about the communication of the
>> data which transcended programs/processes.
>
> I think the review of std.msgpack is done.
> But I will replace MPObject implementation with std.variant before
> adding to Phobos.
> Unfortunately, this progress is stopped because This[strng] causes
> compilation error :(

I've been working on an update to std.json, where this is also an issue, and have written a patch. Unfortunately, it's on my home PC, so I'll post it later tonight.

On 11/19/10 9:48 AM, Robert Jacques wrote:
> On Thu, 18 Nov 2010 04:06:24 -0500, Masahiro Nakagawa <repeatedly at gmail.com> wrote:
>> On Wed, 17 Nov 2010 03:18:17 +0900, SHOO <zan77137 at nifty.com> wrote:
>>
>>> I don't know it about this matter so deeply. Perhaps you are understanding it more precisely than me. This will be preaching to the choir...
>>>
>>> Nakagawa Masahiro did porting of MessagePack to D.
>>> This module is aimed for serialization and can convert data structure
>>> with character string mutually.
>>> The main purpose of serialization of MessagePack is to hand data
>>> beyond programs and development languages.
>>> And it is std.event to offer mechanism about the communication of the
>>> data which transcended programs/processes.
>>
>> I think the review of std.msgpack is done.
>> But I will replace MPObject implementation with std.variant before
>> adding to Phobos.
>> Unfortunately, this progress is stopped because This[strng] causes
>> compilation error :(
>
> I've been working on an update to std.json, where this is also an issue, and have written a patch. Unfortunately, it's on my home PC, so I'll post it later tonight.

Does the patch avoid the issues that made Algebraic not work?

Andrei