Re: std.experimental.xml available on DUB
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
Re: std.experimental.xml available on DUB
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
Re: std.experimental.xml available on DUB
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.
Re: std.experimental.xml available on DUB
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.
Re: std.experimental.xml available on DUB
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
Re: std.experimental.xml available on DUB
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
Re: std.experimental.xml available on DUB
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.
Re: std.experimental.xml available on DUB
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)
Re: std.experimental.xml available on DUB
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
Re: std.experimental.xml available on DUB
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.
Re: std.experimental.xml available on DUB
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.
Re: std.experimental.xml available on DUB
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.
Re: std.experimental.xml available on DUB
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?
Re: std.experimental.xml available on DUB
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.
Re: std.experimental.xml available on DUB
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.
Re: std.experimental.xml available on DUB
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).
Re: std.experimental.xml available on DUB
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.
Re: std.experimental.xml available on DUB
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
std.experimental.xml available on DUB
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
