Re: rapidxml for D has been ported.
On Tuesday, 8 October 2019 at 17:15:30 UTC, bauss wrote: On Tuesday, 8 October 2019 at 09:52:40 UTC, Andrea Fontana wrote: On Tuesday, 8 October 2019 at 08:56:26 UTC, zoujiaqing wrote: [...] So finally we have a working xml parser! https://github.com/DiamondMVC/Diamond/tree/master/xml Since 9 months ago. It will be nice to have a thorough tutorial on how to use it.
Re: rapidxml for D has been ported.
On Tuesday, 8 October 2019 at 09:52:40 UTC, Andrea Fontana wrote: On Tuesday, 8 October 2019 at 08:56:26 UTC, zoujiaqing wrote: [...] So finally we have a working xml parser! https://github.com/DiamondMVC/Diamond/tree/master/xml Since 9 months ago.
Re: rapidxml for D has been ported.
On Tuesday, 8 October 2019 at 09:52:40 UTC, Andrea Fontana wrote: On Tuesday, 8 October 2019 at 08:56:26 UTC, zoujiaqing wrote: [...] So finally we have a working xml parser! Huh? What's wrong with dxml[1]? (Of course it's always good to have alternatives, working or no). 1: http://code.dlang.org/packages/dxml
Re: rapidxml for D has been ported.
On Tuesday, 8 October 2019 at 08:56:26 UTC, zoujiaqing wrote: [...] So finally we have a working xml parser!
rapidxml for D has been ported.
RapidXml is an attempt to create the fastest XML parser possible,
while retaining useability, portability and reasonable W3C
compatibility. It is an in-situ parser written in modern C++,
with parsing speed approaching that of strlen function executed
on the same data. RapidXml has been around since 2006, and is
being used by lots of people.
Ported rapidxml repo:
https://github.com/huntlabs/rapidxml
Example:
```D
import rapidxml;
import stdio;
void main()
{
auto doc = new xml_document;
string doc_text = "";
doc.parse!(0)(doc_text);
auto node = doc.first_node();
writeln(node.m_name);
doc.validate();
}
```
Re: Blog Post: Beating std::visit Without Really Trying
On Sunday, 6 October 2019 at 19:58:04 UTC, Walter Bright wrote: On 10/6/2019 2:59 AM, Paolo Invernizzi wrote: Well, so there's hope that _very little_ improvements will be merged, in a way or another? I mean, there's some sort of policy for things like that: https://github.com/dlang/phobos/pull/6730 Frankly speaking, the actual situation it's a little discouraging... We want a much higher bar for merging things than historically. A smaller, higher quality library is preferable to a kitchen sink library. There is someone actively adding auto-merge labels to pull requests even when the pull request author specifically says the PR is not ready. So the bar has actually been lowered in recent times.. I'm not going to name names because it would be inappropriate, but people are beginning to notice.
Re: intel-intrinsics v1.2.0: Added GDC support, SSE3
On Tue, 8 Oct 2019 at 02:30, Guillaume Piolat via Digitalmars-d-announce wrote: > > `intel-intrinsics` is a DUB package for people interested in x86 > performance that want a portable set of intrinsics which works > with all D compilers. > > Available through DUB: > http://code.dlang.org/packages/intel-intrinsics > > > *** Changelog of v1.2.0 *** > > - SSE3 intrinsics were implemented. > - Added GDC x86/x86_64 support > > > See this table here to know in which case the intrinsics resort > to a slow, emulated version: > https://github.com/AuburnSounds/intel-intrinsics#supported-instructions-set Thanks. -- Iain
