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

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

On Saturday 13 November 2010 22:35:12 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.)

That's part of the problem too. It has been stated several times for various modules that they need to be replaced, but it's not always made clear as to _why_ they should be replaced. If we had a list of modules that we need replacements for, we can give proper reasons for each of them as well. Right now, we don't even have a clear list of modules that we're looking to replace.

Personally, I've never used std.xml, so I don't know what's wrong with it. I know that it's been discussed from time to time, but I don't recall what the reasons were. IIRC, it was a design problem though.

- Jonathan M Davis

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

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20101114/c8419e44/attachment.pgp>

Perhaps it has a problem in license of libxml2 and libxslt.
We may include it in etc, but it does not become the Boost license.
And I don't need such libraries for a *standard*.

--
SHOO

(2010/11/14 18: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?
>
>
>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

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.
>
> 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?
>
Also
- std.bind(deprecate,remove)
it's outdated, it's not working, it's functionality is superseded by
closures/delegates,
and it's still on top in Phobos documentation ;)
> -- 
> 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

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

-- 
/Jacob Carlborg

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
> 
> (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

-- 
/Jacob Carlborg

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