www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - std.experimental.xml available on DUB

reply Lodovico Giaretta <lodovico giaretart.net> writes:
Hi,

I'm proud to announce that std.experimental.xml v0.1.0 is 
available on DUB [1]!

This is the project I'm working on for GSoC 2016. It aims to 
become a substitution for Phobos std.xml. Now you can easily try 
it and provide some feedback. I will soon create a WIP PR on the 
Phobos repository.

I suggest you to depend on ~master instead of v0.1.0, as bugfixes 
and enhancements are added on a daily basis (v0.1.0 is already 
one commit behind!)

Current limitations:
1) The documentation [2] is very limited;
2) Some advanced DOM methods are not completely implemented;
3) Some advanced features (e.g. DTD validation, namespace checks) 
are not yet available.

If you find any issue / have any suggestion, please file an issue 
on Github [3].

Thank you.

[1] https://code.dlang.org/packages/std-experimental-xml
[2] https://lodo1995.github.io/experimental.xml/
[3] https://github.com/lodo1995/experimental.xml
Jul 30 2016
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/30/16 5:26 AM, Lodovico Giaretta wrote:

 Hi,

 I'm proud to announce that std.experimental.xml v0.1.0 is available on
 DUB [1]!

 This is the project I'm working on for GSoC 2016. It aims to become a
 substitution for Phobos std.xml. Now you can easily try it and provide
 some feedback. I will soon create a WIP PR on the Phobos repository.

 I suggest you to depend on ~master instead of v0.1.0, as bugfixes and
 enhancements are added on a daily basis (v0.1.0 is already one commit
 behind!)

 Current limitations:
 1) The documentation [2] is very limited;
 2) Some advanced DOM methods are not completely implemented;
 3) Some advanced features (e.g. DTD validation, namespace checks) are
 not yet available.

 If you find any issue / have any suggestion, please file an issue on
 Github [3].

 Thank you.

 [1] https://code.dlang.org/packages/std-experimental-xml
 [2] https://lodo1995.github.io/experimental.xml/
 [3] https://github.com/lodo1995/experimental.xml


Good to see this advancing!

I'm looking at the cursor API and like what I see.

A couple things:
1) I see struct Cursor is not tagged for documentation, yet all it's 
members are. Your docs are missing out on a lot of stuff here! This 
might be true elsewhere too, make sure you tag types for documentation 
or the members won't show up in the docs.
2) The function "exit", I don't like. This is bikeshedding, but I just 
don't like the possibility that to conflate with C exit. I don't have a 
good replacement name for enter/exit, so this comment is pretty minor.

-Steve
Jul 31 2016
next sibling parent Lodovico Giaretta <lodovico giaretart.net> writes:
On Sunday, 31 July 2016 at 12:04:18 UTC, Steven Schveighoffer 
wrote:

 On 7/30/16 5:26 AM, Lodovico Giaretta wrote:

 [...]


 Good to see this advancing!

 I'm looking at the cursor API and like what I see.


Good to know. The cursor API is the central concept of the 
library, even if it will probably not be directly used by many.


 A couple things:
 1) I see struct Cursor is not tagged for documentation, yet all 
 it's members are. Your docs are missing out on a lot of stuff 
 here! This might be true elsewhere too, make sure you tag types 
 for documentation or the members won't show up in the docs.


You are right. Many things are only partially documented. I'm 
working to improve the situation. For now, you can find the 
documentation of Cursor in std.experimental.xml.isCursor, as this 
is in fact where it belongs. I will definitely mark struct Cursor 
for documentation, and add the relevant link to template isCursor.


 2) The function "exit", I don't like. This is bikeshedding, but 
 I just don't like the possibility that to conflate with C exit. 
 I don't have a good replacement name for enter/exit, so this 
 comment is pretty minor.


I don't agree with you on this. But I'm not too attached to that 
name either, so if anyone can suggest a better name pair for 
enter/exit, I have no problem in changing it. In general, I'm 
open to every kind of change that would ease usage and 
understanding.

Thank you for your feedback.
Jul 31 2016
prev sibling parent Chris <wendlec tcd.ie> writes:
On Sunday, 31 July 2016 at 12:04:18 UTC, Steven Schveighoffer 
wrote:


 2) The function "exit", I don't like. This is bikeshedding, but 
 I just don't like the possibility that to conflate with C exit. 
 I don't have a good replacement name for enter/exit, so this 
 comment is pretty minor.

 -Steve


How about `leave` (enter/leave)
Aug 02 2016
prev sibling next sibling parent reply LaTeigne <LaTeigne blabla.fr> writes:
On Saturday, 30 July 2016 at 09:26:27 UTC, Lodovico Giaretta 
wrote:

 Hi,

 I'm proud to announce that std.experimental.xml v0.1.0 is 
 available on DUB [1]!

 This is the project I'm working on for GSoC 2016. It aims to 
 become a substitution for Phobos std.xml. Now you can easily 
 try it and provide some feedback. I will soon create a WIP PR 
 on the Phobos repository.

 I suggest you to depend on ~master instead of v0.1.0, as 
 bugfixes and enhancements are added on a daily basis (v0.1.0 is 
 already one commit behind!)

 Current limitations:
 1) The documentation [2] is very limited;
 2) Some advanced DOM methods are not completely implemented;
 3) Some advanced features (e.g. DTD validation, namespace 
 checks) are not yet available.

 If you find any issue / have any suggestion, please file an 
 issue on Github [3].

 Thank you.

 [1] https://code.dlang.org/packages/std-experimental-xml
 [2] https://lodo1995.github.io/experimental.xml/
 [3] https://github.com/lodo1995/experimental.xml


I have two comments.

What is the plan for the string interner and the allocator-based 
appender ?

They are neither part of the package, nor proposed in phobos, it 
seems that you'll encounter a problme in the package structure 
itself. This is also problemtaic now if I want to test it I have 
to add 3 import paths to sc.conf.

I suggest you either to propose them for phobos or to add them in 
a subpackage "internal" **inside xml** (or in a big internal.d 
module) like it's done for several phobos packages (algos, 
ndslices).

_____

I see a naming problem in you "fast" strings: fastIndexOf, 
fastEqual etc.

This is not good: does it mean that phobos's equivalent are slow 
? Does it mean that you'll also propose slow equivalents (This is 
absurd, but it shows the problem).
Jul 31 2016
parent reply Lodovico Giaretta <lodovico giaretart.net> writes:
On Sunday, 31 July 2016 at 15:28:14 UTC, LaTeigne wrote:

 On Saturday, 30 July 2016 at 09:26:27 UTC, Lodovico Giaretta 
 wrote:

 Hi,

 I'm proud to announce that std.experimental.xml v0.1.0 is 
 available on DUB [1]!

 This is the project I'm working on for GSoC 2016. It aims to 
 become a substitution for Phobos std.xml. Now you can easily 
 try it and provide some feedback. I will soon create a WIP PR 
 on the Phobos repository.

 I suggest you to depend on ~master instead of v0.1.0, as 
 bugfixes and enhancements are added on a daily basis (v0.1.0 
 is already one commit behind!)

 Current limitations:
 1) The documentation [2] is very limited;
 2) Some advanced DOM methods are not completely implemented;
 3) Some advanced features (e.g. DTD validation, namespace 
 checks) are not yet available.

 If you find any issue / have any suggestion, please file an 
 issue on Github [3].

 Thank you.

 [1] https://code.dlang.org/packages/std-experimental-xml
 [2] https://lodo1995.github.io/experimental.xml/
 [3] https://github.com/lodo1995/experimental.xml


 I have two comments.

 What is the plan for the string interner and the 
 allocator-based appender ?

 They are neither part of the package, nor proposed in phobos, 
 it seems that you'll encounter a problme in the package 
 structure itself. This is also problemtaic now if I want to 
 test it I have to add 3 import paths to sc.conf.

 I suggest you either to propose them for phobos or to add them 
 in a subpackage "internal" **inside xml** (or in a big 
 internal.d module) like it's done for several phobos packages 
 (algos, ndslices).

 _____

 I see a naming problem in you "fast" strings: fastIndexOf, 
 fastEqual etc.

 This is not good: does it mean that phobos's equivalent are 
 slow ? Does it mean that you'll also propose slow equivalents 
 (This is absurd, but it shows the problem).


Thank you for your comments.

Talking about your points:
1) the interner shall really go away before inclusion in Phobos; 
it is unneeded; its code is already partially duplicated in 
CopyingCursor (std.experimental.xml.cursor); but it would be good 
to have something like this in Phobos, somewhere in the future.
2) The appender is needed, as the Phobos one does not work with 
custom allocators; I don't have the time to polish it for Phobos 
adoption, so putting it in an internal xml submodule may be a 
great idea.
3) The fastXXX functions are intended for internal usage; they 
will have package protection in the final library (I really 
forgot about this thing; thanks).

I will tag v0.1.1 late this night, with some fixes based on the 
feedback from you and Steven.

Thank you again.
Jul 31 2016
parent LaTeigne <LaTeigne blabla.fr> writes:
On Sunday, 31 July 2016 at 15:36:47 UTC, Lodovico Giaretta wrote:

 On Sunday, 31 July 2016 at 15:28:14 UTC, LaTeigne wrote:

 On Saturday, 30 July 2016 at 09:26:27 UTC, Lodovico Giaretta


 Thank you for your comments.

 Talking about your points:
 1) the interner shall really go away before inclusion in 
 Phobos; it is unneeded; its code is already partially 
 duplicated in CopyingCursor (std.experimental.xml.cursor); but 
 it would be good to have something like this in Phobos, 
 somewhere in the future.
 2) The appender is needed, as the Phobos one does not work with 
 custom allocators; I don't have the time to polish it for 
 Phobos adoption, so putting it in an internal xml submodule may 
 be a great idea.


Yes that's the most reasonable solution, unless someone has the 
time to polish it for you and enough karma to get it pulled in 
the allocator package (very unlikely as adding new stuffs in 
phobos is usually not a piece of cake. Anyway it would really 
have its place there since there's already all the array 
routines: make expand shrink etc.)


 3) The fastXXX functions are intended for internal usage; they 
 will have package protection in the final library (I really 
 forgot about this thing; thanks).

 I will tag v0.1.1 late this night


Ok, I'm gonna check this tomorrow.
Jul 31 2016
prev sibling next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Saturday, 30 July 2016 at 09:26:27 UTC, Lodovico Giaretta 
wrote:

 Hi,

 I'm proud to announce that std.experimental.xml v0.1.0 is 
 available on DUB [1]!


 If you find any issue / have any suggestion, please file an 
 issue on Github [3].

 Thank you.


Why is it 15 files when kxml is only one?
Jul 31 2016
parent reply Lodovico Giaretta <lodovico giaretart.net> writes:
On Sunday, 31 July 2016 at 18:38:32 UTC, Guillaume Piolat wrote:

 On Saturday, 30 July 2016 at 09:26:27 UTC, Lodovico Giaretta 
 wrote:

 Hi,

 I'm proud to announce that std.experimental.xml v0.1.0 is 
 available on DUB [1]!


 If you find any issue / have any suggestion, please file an 
 issue on Github [3].

 Thank you.


 Why is it 15 files when kxml is only one?


kxml is way more than a file. You may say that its parser is just 
a file. In std.experimental.xml, the parser is at most three 
files (it depends on what you mean by parser), not fifteen.

kxml is also way limited with respect to std.experimental.xml. It 
does not support many features, like custom allocators (because 
they don't exist in Java). It does not have to strive to be  nogc 
(because it does not exist in Java). It does not support high 
customization, with custom lexers, pluggable validations, full 
DOM Level 3 support, with the ability for the user to provide a 
custom DOM implementation and have the DOMBuilder use it instead 
of the default provided DOM implementation. It does not support 
SAX with DbI on the handler type. It does not support outputting 
XML using a custom formatter, again with DbI.

Also keep in mind that std.experimental.xml contains LOTS of 
lines of unittests and some code is there just because Phobos 
does not provide some essential tools for the job.

It is true that I could merge some of these files, as they are 
almost all quite short, but I prefer them this way, cause they 
are easier to handle.
Jul 31 2016
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Sunday, 31 July 2016 at 18:56:33 UTC, Lodovico Giaretta wrote:

 kxml is also way limited with respect to std.experimental.xml. 
 It does not support many features, like custom allocators 
 (because they don't exist in Java). It does not have to strive 
 to be  nogc (because it does not exist in Java). It does not 
 support high customization, with custom lexers, pluggable 
 validations, full DOM Level 3 support, with the ability for the 
 user to provide a custom DOM implementation and have the 
 DOMBuilder use it instead of the default provided DOM 
 implementation. It does not support SAX with DbI on the handler 
 type. It does not support outputting XML using a custom 
 formatter, again with DbI.


Okay, just wanted to know what we are buying with (supposedly) 
more code.
For reference I was speaking of the D kxml package, which is a 
DOM parser than can range-iterate on nodes using XPath.
Aug 01 2016
parent Lodovico Giaretta <lodovico giaretart.net> writes:
On Monday, 1 August 2016 at 07:38:29 UTC, Guillaume Piolat wrote:

 On Sunday, 31 July 2016 at 18:56:33 UTC, Lodovico Giaretta 
 wrote:

 kxml is also way limited with respect to std.experimental.xml. 
 It does not support many features, like custom allocators 
 (because they don't exist in Java). It does not have to strive 
 to be  nogc (because it does not exist in Java). It does not 
 support high customization, with custom lexers, pluggable 
 validations, full DOM Level 3 support, with the ability for 
 the user to provide a custom DOM implementation and have the 
 DOMBuilder use it instead of the default provided DOM 
 implementation. It does not support SAX with DbI on the 
 handler type. It does not support outputting XML using a 
 custom formatter, again with DbI.


 Okay, just wanted to know what we are buying with (supposedly) 
 more code.
 For reference I was speaking of the D kxml package, which is a 
 DOM parser than can range-iterate on nodes using XPath.


Ouch. Looks like I misunderstood you then. I apologize.

I don't know anything about that D package, but I can safely 
assume that this library will provide more functionalities and 
(most of all) more customization points. It's designed as a 
collection of components, each of with can be customized or even 
substituted with a user defined one. This is what such a big 
quantity of code will buy.

There are various principles one can use when building a library. 
In this case I didn't choose minimality. I prefered extensibility 
and customizability.
Aug 01 2016
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2016-07-30 11:26, Lodovico Giaretta wrote:


 I'm proud to announce that std.experimental.xml v0.1.0 is available on
 DUB [1]!

 This is the project I'm working on for GSoC 2016. It aims to become a
 substitution for Phobos std.xml. Now you can easily try it and provide
 some feedback. I will soon create a WIP PR on the Phobos repository.


* Does it work at CTFE?
* I see that it doesn't follow the D naming conventions

-- 
/Jacob Carlborg
Aug 02 2016
parent reply Lodovico Giaretta <lodovico giaretart.net> writes:
On Tuesday, 2 August 2016 at 15:32:50 UTC, Jacob Carlborg wrote:

 * Does it work at CTFE?


I don't think so.


 * I see that it doesn't follow the D naming conventions


You are talking about upper/lower cases in the names, right? I 
will correct them in the Phobos PR.
Aug 03 2016
parent Jacob Carlborg <doob me.com> writes:
On 2016-08-03 09:20, Lodovico Giaretta wrote:

 On Tuesday, 2 August 2016 at 15:32:50 UTC, Jacob Carlborg wrote:

 * Does it work at CTFE?


 I don't think so.


It would be cool if it did. I think it would at least be worth taking a 
couple of minutes and investigate if it does work or not. If doesn't 
work, what it would take to make it work.

Most parts in D work at CTFE but there are some particular things that 
are not compatible like allocating with malloc instead of the GC. I see 
that allocators are used, not sure how well those work at CTFE. At least 
in theory the GC allocator should work.


 You are talking about upper/lower cases in the names, right? I will
 correct them in the Phobos PR.


Yes, and some methods use Java style getters and setters, instead of D 
style properties. Example:

// Java style
int getFoo();
void setFoo(int foo);

// D style
int foo();
int foo(int foo);

In D, the above can be called like:

Bar bar;
auto i = bar.foo;
bar.foo = 3;

-- 
/Jacob Carlborg
Aug 03 2016
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2016-07-30 11:26, Lodovico Giaretta wrote:

 Hi,

 I'm proud to announce that std.experimental.xml v0.1.0 is available on
 DUB [1]!


Another question. I see that there are a couple of different lexers 
available. Can those be exposed with the same interface/type instead of 
using different types? Perhaps based on the input type.

-- 
/Jacob Carlborg
Aug 03 2016
next sibling parent reply Robert burner Schadek <rburners gmail.com> writes:
On Wednesday, 3 August 2016 at 09:04:30 UTC, Jacob Carlborg wrote:

 Another question. I see that there are a couple of different 
 lexers available. Can those be exposed with the same 
 interface/type instead of using different types? Perhaps based 
 on the input type.


Well, currently you have to make that choice as developer, and 
there is always the BufferedLexer which should be good choice is 
most cases. Polymorphic design was not a goal of the project, so 
I think it is going to be hard to add that without sacrificing to 
much.
Aug 03 2016
parent Jacob Carlborg <doob me.com> writes:
On 2016-08-03 22:57, Robert burner Schadek wrote:


 Well, currently you have to make that choice as developer, and there is
 always the BufferedLexer which should be good choice is most cases.
 Polymorphic design was not a goal of the project, so I think it is going
 to be hard to add that without sacrificing to much.


I'm not talking about a polymorphic design. I'm talking about how most 
functions work with ranges. They adapt depending on what type the input 
range is. Example, there's one lexer for forward ranges and one for 
input ranges. Why is that necessary? It's not necessary for functions in 
std.algorithm to use different names for a function for different input 
types.

-- 
/Jacob Carlborg
Aug 04 2016
prev sibling parent reply Lodovico Giaretta <lodovico giaretart.net> writes:
On Wednesday, 3 August 2016 at 09:04:30 UTC, Jacob Carlborg wrote:

 On 2016-07-30 11:26, Lodovico Giaretta wrote:

 Hi,

 I'm proud to announce that std.experimental.xml v0.1.0 is 
 available on
 DUB [1]!


 Another question. I see that there are a couple of different 
 lexers available. Can those be exposed with the same 
 interface/type instead of using different types? Perhaps based 
 on the input type.


I don't know if it is what you want, but you can do this:

auto lexer = chooseLexer!input;

The function chooseLexer creates the most suitable lexer type 
based on the input type.

You can test if a type is a lexer using the trait isLexer defined 
in std.experimental.interfaces.
Aug 04 2016
parent Jacob Carlborg <doob me.com> writes:
On 2016-08-04 09:15, Lodovico Giaretta wrote:


 I don't know if it is what you want, but you can do this:

 auto lexer = chooseLexer!input;

 The function chooseLexer creates the most suitable lexer type based on
 the input type.

 You can test if a type is a lexer using the trait isLexer defined in
 std.experimental.interfaces.


Please see my reply to Robert [1].

[1] http://forum.dlang.org/post/nnv6gt$sbe$1 digitalmars.com

-- 
/Jacob Carlborg
Aug 04 2016