On Monday, 22 August 2022 at 11:48:47 UTC, solidstate1991 wrote:
> First I'd want some community input

You might want to look into my dom.d too, it isn't suitable for all xml but it does a decent job on much of it.

On Mon, Aug 22, 2022 at 11:48:47AM +0000, solidstate1991 via Digitalmars-d wrote:
> Since the XML parsing library was removed from Phobos, I'm thinking about either getting dlang-community/experimental.xml into a usable state, or write a completely new parser.
> 
> First I'd want some community input, and would like to hear from the users of lodo1995's library. Depending on some circumstances, I'll be losing my job next month, so I'll have some extra time on my hands (no money will be a tough thing), and even without that I'll try to pull it off somehow.

Why not use Jonathan's dxml?


T

-- 
"You know, maybe we don't *need* enemies." "Yeah, best friends are about all I can take." -- Calvin & Hobbes

On Monday, 22 August 2022 at 14:51:34 UTC, H. S. Teoh wrote:
>
> Why not use Jonathan's dxml?
>
>
> T

I might have a lot of free time in the near future, so I could write something for Phobos.

On Monday, 22 August 2022 at 14:51:34 UTC, H. S. Teoh wrote:

> Why not use Jonathan's dxml?

I build a project off of dxml and found it to be quite nice, but I forgot to read the fine print (aka the template specialization).  After a week of development when everything was working well, I tried to use it for parsing stdin and that's when the compiler let me know than an InputRange wasn't sufficient.  Totally my fault, no knock against the author.

So depending on the use case, dxml works quite well.  For my own purposes I'll need to find/create a ForwardRange adapter for stdin or refactor my code to use another library.

On Mon, Aug 22, 2022 at 10:51:44PM +0000, Chris Piker via Digitalmars-d wrote:
> On Monday, 22 August 2022 at 14:51:34 UTC, H. S. Teoh wrote:
> 
> > Why not use Jonathan's dxml?
> 
> I build a project off of dxml and found it to be quite nice, but I forgot to read the fine print (aka the template specialization). After a week of development when everything was working well, I tried to use it for parsing stdin and that's when the compiler let me know than an InputRange wasn't sufficient.  Totally my fault, no knock against the author.
> 
> So depending on the use case, dxml works quite well.  For my own purposes I'll need to find/create a ForwardRange adapter for stdin or refactor my code to use another library.

Do you need to parse xml on-the-fly, or would it work to just slurp the entire stdin into a buffer and then parse that?

In the former case, you could probably just accumulate incoming stdin lines into a buffer and parse that (though you'll probably need a wrapper, otherwise dxml may terminate prematurely at the end of the current line).

In the latter case it should be a simple matter of using std.algorithm.copy to read stdin into a buffer, which can then be parsed with dxml.


T

-- 
There's light at the end of the tunnel. It's the oncoming train.

On 8/22/22 15:51, Chris Piker wrote:

> So depending on the use case, dxml works quite well.  For my own
> purposes I'll need to find/create a ForwardRange adapter for stdin

The 'cached' range adaptor I mentioned on these forums a couple of times and in my DConf 2022 lightning talk converts any InputRange to a ForwardRange. (It does this by evaluating the elements once; so it would be valuable with generators as well; and in fact, a generator use case was why I wrote it.)

(Aside: It actually makes a RandomAccessRange because it supports opIndex as well but it does not honor O(1): It will grab 'n' elements if you say myRange[n] and if those elements are not in the cache yet.)

Currently it has an assumed performance issue because it uses a regular D slice, and the way it uses the slice incurs an allocation cost per element. There are different ways of dealing with that issue but I haven't finished that yet.

Ali