On Thu, Aug 30, 2018 at 07:26:28PM +, nkm1 via Digitalmars-d-announce wrote:
> On Monday, 12 February 2018 at 16:50:16 UTC, Jonathan M Davis wrote:
> > Folks are free to decide to support dxml for inclusion when the time
> > comes and free to vote it as unacceptable. Personally, I think that
>
On Monday, 12 February 2018 at 16:50:16 UTC, Jonathan M Davis
wrote:
Folks are free to decide to support dxml for inclusion when the
time comes and free to vote it as unacceptable. Personally, I
think that dxml's approach is ideal for XML that doesn't use
entity references, and I'd much rather
On Monday, 12 February 2018 at 05:36:51 UTC, Jonathan M Davis
wrote:
dxml 0.2.0 has now been released.
Documentation: http://jmdavisprog.com/docs/dxml/0.2.0/
Github: https://github.com/jmdavis/dxml/tree/v0.2.0
Dub: http://code.dlang.org/packages/dxml
- Jonathan M Davis
This is absolutely aweso
On Thursday, 15 February 2018 at 02:40:03 UTC, Jonathan M Davis
wrote:
LOL. That's actually part of what makes writing range-based
libraries so much harder to get right than simply using ranges
in your program. [snip]
That sounds like an interesting topic for a blog post.
On Thursday, February 15, 2018 01:55:28 rikki cattermole via Digitalmars-d-
announce wrote:
> On 14/02/2018 5:13 PM, Jonathan M Davis wrote:
> > On Wednesday, February 14, 2018 14:09:21 rikki cattermole via
> > Digitalmars-d->
> > announce wrote:
> >> On 14/02/2018 2:02 PM, Adrian Matoga wrote:
> >
On 14/02/2018 5:13 PM, Jonathan M Davis wrote:
On Wednesday, February 14, 2018 14:09:21 rikki cattermole via Digitalmars-d-
announce wrote:
On 14/02/2018 2:02 PM, Adrian Matoga wrote:
On Wednesday, 14 February 2018 at 10:57:26 UTC, rikki cattermole wrote:
See lines:
- Input!IR temp = input;
-
On Wednesday, February 14, 2018 14:09:21 rikki cattermole via Digitalmars-d-
announce wrote:
> On 14/02/2018 2:02 PM, Adrian Matoga wrote:
> > On Wednesday, 14 February 2018 at 10:57:26 UTC, rikki cattermole wrote:
> >> See lines:
> >> - Input!IR temp = input;
> >> - input = temp;
> >>
> >>
On 14/02/2018 2:02 PM, Adrian Matoga wrote:
On Wednesday, 14 February 2018 at 10:57:26 UTC, rikki cattermole wrote:
See lines:
- Input!IR temp = input;
- input = temp;
bool commentLine() {
Input!IR temp = input;
(...)
if (!temp.empty) {
(...)
input = temp
On Wednesday, 14 February 2018 at 10:57:26 UTC, rikki cattermole
wrote:
See lines:
- Input!IR temp = input;
- input = temp;
bool commentLine() {
Input!IR temp = input;
(...)
if (!temp.empty) {
(...)
input = temp;
On 14/02/2018 10:32 AM, Jonathan M Davis wrote:
On Wednesday, February 14, 2018 10:14:44 Kagamin via Digitalmars-d-announce
wrote:
It looks like EntityRange requires forward range, is it ok for a
parser?
It's very difficult in general to write a parser that isn't at least a
forward range, beca
On Wednesday, February 14, 2018 10:14:44 Kagamin via Digitalmars-d-announce
wrote:
> It looks like EntityRange requires forward range, is it ok for a
> parser?
It's very difficult in general to write a parser that isn't at least a
forward range, because without that, you're stuck at only one char
On Tuesday, 13 February 2018 at 22:13:36 UTC, H. S. Teoh wrote:
Ironically, the general advice I found online w.r.t XML
vulnerabilities is "don't allow DTDs", "don't expand entities",
"don't resolve externals", etc.. There also aren't many XML
parsers out there that fully support all the fe
On Wednesday, February 14, 2018 10:03:45 Patrick Schluter via Digitalmars-d-
announce wrote:
> On Tuesday, 13 February 2018 at 22:00:59 UTC, Jonathan M Davis
>
> wrote:
> > On Tuesday, February 13, 2018 21:18:12 Patrick Schluter via
> >
> > Digitalmars-d- announce wrote:
> >> [...]
> >
> > Well, if
On Tuesday, 13 February 2018 at 22:29:27 UTC, H. S. Teoh wrote:
- provide some way of hooking into non-default entities so that
DTD-defined entities can be expanded by the DTD
implementation.
The parser now returns raw text, entity replacement can be done
by DTD processor without any modifi
On Tuesday, 13 February 2018 at 22:00:59 UTC, Jonathan M Davis
wrote:
On Tuesday, February 13, 2018 21:18:12 Patrick Schluter via
Digitalmars-d- announce wrote:
[...]
Well, if dxml just passes the entity references along unparsed
beyond validating that the entity reference itself contains
va
On Tuesday, February 13, 2018 14:29:27 H. S. Teoh via Digitalmars-d-announce
wrote:
> Given the insane complexities of DTD that I'm only slowly beginning to
> grasp from actually reading the spec, I'm quickly adopting the opinion
> that dxml should remain as-is, and any DTD implementation should b
On Tuesday, February 13, 2018 14:13:36 H. S. Teoh via Digitalmars-d-announce
wrote:
> Great, just
> great. Now I know why I've always had this gut feeling that
> *something* is off about the whole XML mania.)
Well, there are plenty of folks who talk like XML is a pile of steaming muck
that shou
On Tue, Feb 13, 2018 at 03:00:59PM -0700, Jonathan M Davis via
Digitalmars-d-announce wrote:
[...]
> The big problem is how the entity references affect the parsing. If
> start tags can be dropped in and affect the parsing (and it's still
> not clear to me from the spec whether that's legal - ther
On Tue, Feb 13, 2018 at 09:18:12PM +, Patrick Schluter via
Digitalmars-d-announce wrote:
> On Tuesday, 13 February 2018 at 20:10:59 UTC, Jonathan M Davis wrote:
[...]
> > If it's 100% sure that entity references can be treated as just text
> > and that you can't end up with stuff like start ta
On Tuesday, February 13, 2018 21:18:12 Patrick Schluter via Digitalmars-d-
announce wrote:
> There's also the issue that entity references open a whole can of
> worms concerning security. It quite possible to have an
> exponential growing entity replacement that can take down any
> parser.
Well, i
On Tuesday, 13 February 2018 at 20:10:59 UTC, Jonathan M Davis
wrote:
On Tuesday, February 13, 2018 15:22:32 Kagamin via
Digitalmars-d-announce wrote:
On Monday, 12 February 2018 at 16:50:16 UTC, Jonathan M Davis
wrote:
> The core problem is that entity references get replaced with
> more XML
On Tuesday, February 13, 2018 15:22:32 Kagamin via Digitalmars-d-announce
wrote:
> On Monday, 12 February 2018 at 16:50:16 UTC, Jonathan M Davis
>
> wrote:
> > The core problem is that entity references get replaced with
> > more XML that needs to be parsed. So, they can't simply be
> > passed on
On Tuesday, 13 February 2018 at 02:53:21 UTC, Nick Sabalausky
(Abscissa) wrote:
On 02/12/2018 11:15 AM, rikki cattermole wrote:
dxml 7.5k LOC
std.xml 3k LOC
dxml would make the situation a lot worse.
4.5k LOC == "a lot worse"?
Uuuuhhh...WAT?
And it's like 2k LOC of code and 5.5k LOC of te
On Monday, 12 February 2018 at 16:50:16 UTC, Jonathan M Davis
wrote:
The core problem is that entity references get replaced with
more XML that needs to be parsed. So, they can't simply be
passed on for post-processing. As I understand it, they have to
be replaced while the parsing is going on.
On Mon, 2018-02-12 at 14:54 +, rikki cattermole via Digitalmars-d-
announce wrote:
> […]
>
> Personally I find J.M.D. arguments quite reasonable for a third-
> party
> library, since yes it does cover 90% of the use cases.
The problem is that std.xml needs removing to make it clear there is
On Monday, 12 February 2018 at 21:51:56 UTC, H. S. Teoh wrote:
[...]
We can even design the DTD support wrapper to start with being
just a thin wrapper around dxml, and lazily switch to full DTD
mode only if a DTD section is encountered. Then user code that
doesn't care to use dxml's raw API w
On 2018-02-12 21:19, Chris wrote:
A few lines of code that could be replaced easily once something better
is available?
Fairly easy because it's so small. I'm actually using the SAX interface
from std.xml and it quite nicely fits my needs.
--
/Jacob Carlborg
On 02/12/2018 10:49 PM, Jonathan M Davis wrote:
Andrei used to complain periodically about how large std.datetime was,
thinking that it was way too much code, and then someone actually went to
the effort of stripping out all of the comments and unit tests and whatnot
to count the actual lines of
On Monday, February 12, 2018 21:53:21 Nick Sabalausky via Digitalmars-d-
announce wrote:
> On 02/12/2018 11:15 AM, rikki cattermole wrote:
> > dxml 7.5k LOC
> > std.xml 3k LOC
> >
> > dxml would make the situation a lot worse.
>
> 4.5k LOC == "a lot worse"?
>
> Uuuuhhh...WAT?
There is sometimes a
On 02/12/2018 11:15 AM, rikki cattermole wrote:
dxml 7.5k LOC
std.xml 3k LOC
dxml would make the situation a lot worse.
4.5k LOC == "a lot worse"?
Uuuuhhh...WAT?
On 02/12/2018 05:02 PM, H. S. Teoh wrote:
On Mon, Feb 12, 2018 at 02:54:48PM +, rikki cattermole via
Digitalmars-d-announce wrote:
[...]
Everything you have mentioned is not in Phobos. Just because something
is 'good enough' does not make it 'good enough' for Phobos. In the
words of Andrei
On 12/02/2018 10:02 PM, H. S. Teoh wrote:
On Mon, Feb 12, 2018 at 02:54:48PM +, rikki cattermole via
Digitalmars-d-announce wrote:
[...]
Everything you have mentioned is not in Phobos. Just because something
is 'good enough' does not make it 'good enough' for Phobos. In the
words of Andrei
On Monday, February 12, 2018 21:26:45 Johannes Loher via Digitalmars-d-
announce wrote:
> On Monday, 12 February 2018 at 05:36:51 UTC, Jonathan M Davis
>
> wrote:
> > dxml 0.2.0 has now been released.
> > [...]
>
> Thank you very much for your efforts, I really appreciate it, as
> I have been looki
On Monday, February 12, 2018 13:51:56 H. S. Teoh via Digitalmars-d-announce
wrote:
> For example, entity
> support pretty much means plain slices are no longer an option, because
> you have to perform substitution of entity definitions, so you'll have
> to either wrap it in some kind of lazy range
On Mon, Feb 12, 2018 at 02:54:48PM +, rikki cattermole via
Digitalmars-d-announce wrote:
[...]
> Everything you have mentioned is not in Phobos. Just because something
> is 'good enough' does not make it 'good enough' for Phobos. In the
> words of Andrei "Good enough is not good enough", we ne
On Mon, Feb 12, 2018 at 09:50:16AM -0700, Jonathan M Davis via
Digitalmars-d-announce wrote:
[...]
> The core problem is that entity references get replaced with more XML
> that needs to be parsed. So, they can't simply be passed on for
> post-processing. As I understand it, they have to be repla
On Monday, 12 February 2018 at 05:36:51 UTC, Jonathan M Davis
wrote:
dxml 0.2.0 has now been released.
[...]
Thank you very much for your efforts, I really appreciate it, as
I have been looking for a decent xml library for quite some time.
Whethr or not this is a candidate for inclusion into
On Monday, 12 February 2018 at 19:47:09 UTC, Jacob Carlborg wrote:
On 2018-02-12 17:49, Chris wrote:
How could it possibly make the situation any worse than it is
now? Atm,
nobody will ever use std.xml, because it is sub-standard and
has no future.
I'm using std.xml in a new project right no
On 2018-02-12 17:49, Chris wrote:
How could it possibly make the situation any worse than it is now? Atm,
nobody will ever use std.xml, because it is sub-standard and has no future.
I'm using std.xml in a new project right now. It's a really small
private project that just need to extracts so
On Monday, February 12, 2018 07:59:24 H. S. Teoh via Digitalmars-d-announce
wrote:
> On Mon, Feb 12, 2018 at 07:04:38AM -0700, Jonathan M Davis via
> Digitalmars-d-announce wrote: [...]
>
> > However, if folks as a whole think that Phobos' xml parser needs to
> > support the DTD section to be acce
On Monday, 12 February 2018 at 16:15:54 UTC, rikki cattermole
wrote:
dxml 7.5k LOC
std.xml 3k LOC
dxml would make the situation a lot worse.
How could it possibly make the situation any worse than it is
now? Atm, nobody will ever use std.xml, because it is
sub-standard and has no future.
On 12/02/2018 3:59 PM, H. S. Teoh wrote:
If std.xml currently does not support DTDs, then I say dxml is
definitely a Phobos candidate. At the very least, it does not make the
current situation worse. Rejecting dxml because it doesn't support DTDs
is basically letting the perfect be the enemy of
On 12/02/2018 3:50 PM, Jonathan M Davis wrote:
In any case, I'm going to finish implementing dxml without any kind of DTD
support and then see how things go as far as the Phobos review process goes.
If dxml gets rejected, because the majority of folks think that we're better
off with std.xml (or
On Mon, Feb 12, 2018 at 07:04:38AM -0700, Jonathan M Davis via
Digitalmars-d-announce wrote:
[...]
> However, if folks as a whole think that Phobos' xml parser needs to
> support the DTD section to be acceptable, then dxml won't replace
> std.xml, because dxml is not going to implement DTD support
On Monday, February 12, 2018 15:45:50 bachmeier via Digitalmars-d-announce
wrote:
> On Monday, 12 February 2018 at 15:43:59 UTC, bachmeier wrote:
> > On Monday, 12 February 2018 at 14:04:38 UTC, Jonathan M Davis
> >
> > wrote:
> >> However, if folks as a whole think that Phobos' xml parser
> >> ne
On Monday, February 12, 2018 15:26:24 rikki cattermole via Digitalmars-d-
announce wrote:
> All J.M.D. has to do to change this, is make the API match the spec (as
> close as possible, without writing another parser) and separate out the
> implementation into a different and very clear module (prob
On Monday, 12 February 2018 at 15:43:59 UTC, bachmeier wrote:
On Monday, 12 February 2018 at 14:04:38 UTC, Jonathan M Davis
wrote:
However, if folks as a whole think that Phobos' xml parser
needs to support the DTD section to be acceptable, then dxml
won't replace std.xml, because dxml is not
On Monday, 12 February 2018 at 14:04:38 UTC, Jonathan M Davis
wrote:
However, if folks as a whole think that Phobos' xml parser
needs to support the DTD section to be acceptable, then dxml
won't replace std.xml, because dxml is not going to implement
DTD support. DTD support fundamentally doe
On 12/02/2018 3:08 PM, Adam D. Ruppe wrote:
On Monday, 12 February 2018 at 14:54:48 UTC, rikki cattermole wrote:
Just because something is 'good enough' does not make it 'good enough'
for Phobos. In the words of Andrei "Good enough is not good enough",
we need to aim higher to show what we actu
On Monday, 12 February 2018 at 14:54:48 UTC, rikki cattermole
wrote:
Just because something is 'good enough' does not make it 'good
enough' for Phobos. In the words of Andrei "Good enough is not
good enough", we need to aim higher to show what we actually
can do.
About 5 years ago (I think, I
On Monday, 12 February 2018 at 14:04:38 UTC, Jonathan M Davis
wrote:
XML parsers are one of those things that everyone seems to want
and no one seems to want to work on.
I wrote one 8 years ago... though mine is more focused on HTML
parsing, and the XML aspect is just a side effect!
On 12/02/2018 2:45 PM, Chris wrote:
On Monday, 12 February 2018 at 14:04:38 UTC, Jonathan M Davis wrote:
On Monday, February 12, 2018 12:38:51 Chris via Digitalmars-d-announce
wrote:
On Monday, 12 February 2018 at 05:36:51 UTC, Jonathan M Davis
However, std.xml does not support the DTD sect
On Monday, 12 February 2018 at 14:04:38 UTC, Jonathan M Davis
wrote:
On Monday, February 12, 2018 12:38:51 Chris via
Digitalmars-d-announce wrote:
On Monday, 12 February 2018 at 05:36:51 UTC, Jonathan M Davis
However, std.xml does not support the DTD section, and glancing
over it, it doesn'
On 12/02/2018 1:51 PM, Chris wrote:
On Monday, 12 February 2018 at 12:49:30 UTC, rikki cattermole wrote:
On 12/02/2018 12:38 PM, Chris wrote:
On Monday, 12 February 2018 at 05:36:51 UTC, Jonathan M Davis wrote:
dxml 0.2.0 has now been released.
I really wasn't planning on releasing anything t
On Monday, February 12, 2018 12:38:51 Chris via Digitalmars-d-announce
wrote:
> On Monday, 12 February 2018 at 05:36:51 UTC, Jonathan M Davis
>
> wrote:
> > dxml 0.2.0 has now been released.
> >
> > I really wasn't planning on releasing anything this quickly
> > after announcing dxml, but when I w
On Monday, 12 February 2018 at 12:49:30 UTC, rikki cattermole
wrote:
On 12/02/2018 12:38 PM, Chris wrote:
On Monday, 12 February 2018 at 05:36:51 UTC, Jonathan M Davis
wrote:
dxml 0.2.0 has now been released.
I really wasn't planning on releasing anything this quickly
after announcing dxml, b
On 12/02/2018 12:38 PM, Chris wrote:
On Monday, 12 February 2018 at 05:36:51 UTC, Jonathan M Davis wrote:
dxml 0.2.0 has now been released.
I really wasn't planning on releasing anything this quickly after
announcing dxml, but when I went to start working on DOM support, it
turned out to be s
On Monday, 12 February 2018 at 05:36:51 UTC, Jonathan M Davis
wrote:
dxml 0.2.0 has now been released.
I really wasn't planning on releasing anything this quickly
after announcing dxml, but when I went to start working on DOM
support, it turned out to be surprisingly quick and easy to
impleme
On Monday, 12 February 2018 at 05:36:51 UTC, Jonathan M Davis
wrote:
dxml 0.2.0 has now been released.
I really wasn't planning on releasing anything this quickly
after announcing dxml, but when I went to start working on DOM
support, it turned out to be surprisingly quick and easy to
impleme
dxml 0.2.0 has now been released.
I really wasn't planning on releasing anything this quickly after announcing
dxml, but when I went to start working on DOM support, it turned out to be
surprisingly quick and easy to implement. So, dxml now has basic DOM
support.
As part of that, it became clear
60 matches
Mail list logo
