On Fri, 19 Nov 2010 14:02:27 -0500, Andrei Alexandrescu <andrei at erdani.com> wrote:

> 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

The patch is to std.variant and includes some additional API improvements/updates (mainly to operator overloading). So yes, it makes Algebraic work as expected.

On Sat, 20 Nov 2010 06:32:28 +0900, Robert Jacques <sandford at jhu.edu> wrote:

> On Fri, 19 Nov 2010 14:02:27 -0500, Andrei Alexandrescu <andrei at erdani.com> wrote:
>
>> 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
>
> The patch is to std.variant and includes some additional API improvements/updates (mainly to operator overloading). So yes, it makes Algebraic work as expected.

It is good news to me :)
I wait your patch!


Masahiro

I agree.
It should be recorded in wiki(or tickets) not to forget it even if a
topic dies down.

--
SHOO

(2010/11/15 17:42), Shin Fujishiro wrote:
> Dmitry Olshansky<dmitry.olsh at gmail.com>  wrote:
>> On 14.11.2010 11:05, SHOO wrote:
>>> I think that it is important that we prioritize our to-do list.
>> Strongly agree. It's even better if it's public list so that all users aware of it.
>
> How about the trac wiki or ticket on dsource?
>
>
> Shin

Note  that there is a public Road Map and list of goals ready for update/editing/expanding already.

http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel

On Sun, Nov 21, 2010 at 8:32 AM, SHOO <zan77137 at nifty.com> wrote:
> I agree.
> It should be recorded in wiki(or tickets) not to forget it even if a topic
> dies down.
>
> --
> SHOO
>
> (2010/11/15 17:42), Shin Fujishiro wrote:
>>
>> Dmitry Olshansky<dmitry.olsh at gmail.com> ?wrote:
>>>
>>> On 14.11.2010 11:05, SHOO wrote:
>>>>
>>>> I think that it is important that we prioritize our to-do list.
>>>
>>> Strongly agree. It's even better if it's public list so that all users aware of it.
>>
>> How about the trac wiki or ticket on dsource?
>>
>>
>> Shin
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>



-- 
Liberty means responsibility. That is why most men dread it. ? - George Bernard Shaw

Responding to an older message (see below).

Historically, community shout-outs have performed poorly. I'm not sure why, but probably it's because people would rather champion something they've already worked on and are having fun with, rather than adopt someone else's orphan.

If you think that would help, feel free to ask away. I have recently pruned a few modules off the documentation already and deprecated or removed others, as I'm sure you saw.


Andrei

On 11/13/10 11:52 PM, 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

I think the main issue with std.xml is its speed. That in turn derives from its design, which is based on delegates. Probably a module that uses a similar design but templated delegates (a la std.algorithm) and uses ranges to avoid memory allocation would be compelling.

Andrei

On 11/14/10 12:35 AM, SHOO wrote:
> About a problem of std.xml.
>
> I do not clearly understand what of this module is a problem. Is the main factor lack of the maintainer? Or the design concept? Performance? Bugs?
>
> Please make problems clear.
>
> Otherwise the action indicator that we should take next is not decided. (I think that this is what I can talk to other modules, too.)
>
> --
> 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

This list is an excellent starter. As you are seeing on the newsgroup I'm discussing streams on and off, and am planning to take that to completion. Anything that you guys find exciting, feel free to discuss here, or simply commit if the changes are noncontroversial.

Andrei

On 11/14/10 2: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