Is there one in existence?

-Kaitlyn

On Wednesday, 5 February 2020 at 01:43:24 UTC, Kaitlyn Emmons wrote:
> Is there one in existence?

Most ordinary xml D parser can run at compile time.

I've tested my dom.d with it and it parses successfully, though several actual manipulations cause the compiler to crash [!].

import arsd.dom;

string translate(string xml) {
        auto document = new Document(xml, true, true);
        foreach(p; document.querySelectorAll("p"))
                p.removeAllChildren(); // this worked at least
                //p.innerText = "compile time"; // crashed!
                //p.addClass("paragraph"); // crashed!
        return document.toString();
}

// with the `enum` keyword, it runs the function at compile-time
enum e = translate("<xml><p>cool</p></xml>");

void main() {
        pragma(msg, e); // and this prints the result as it compiles
}

On Wednesday, 5 February 2020 at 01:51:07 UTC, Adam D. Ruppe wrote:
> On Wednesday, 5 February 2020 at 01:43:24 UTC, Kaitlyn Emmons wrote:
>> Is there one in existence?
>
> Most ordinary xml D parser can run at compile time.
>
> I've tested my dom.d with it and it parses successfully, though several actual manipulations cause the compiler to crash [!].
>
> import arsd.dom;
>
> string translate(string xml) {
>         auto document = new Document(xml, true, true);
>         foreach(p; document.querySelectorAll("p"))
>                 p.removeAllChildren(); // this worked at least
>                 //p.innerText = "compile time"; // crashed!
>                 //p.addClass("paragraph"); // crashed!
>         return document.toString();
> }
>
> // with the `enum` keyword, it runs the function at compile-time
> enum e = translate("<xml><p>cool</p></xml>");
>
> void main() {
>         pragma(msg, e); // and this prints the result as it compiles
> }

It crash from manipulation but does it ever crash just parse and read? I dont need manipulation, just parse and read. Going to try parse and auto generate a VK binding from VKapi.xml that krhonos releases :) But it is big and complex xml so need stable parser.

On Wednesday, 5 February 2020 at 02:06:58 UTC, Kaitlyn Emmons wrote:
> It crash from manipulation but does it ever crash just parse and read?

Not for me but I almost always just do it at runtime; the compile time isn't as well tested. (I've only done little things with it at CT)

But the same principle should apply to the other D xml parsers so maybe one of them will be better.

> to try parse and auto generate a VK binding from VKapi.xml that krhonos releases :) But it is big and complex xml so need stable parser.

You might be better off doing it at run time anyway - write a program to load the xml and generate it as a separate step in your build process.

With a CT binding, every single build is going to have to reparse all the xml and regenerate the binding and the compile time function executor in the compiler is kinda slow.

On Tuesday, February 4, 2020 6:43:24 PM MST Kaitlyn Emmons via Digitalmars-d wrote:
> Is there one in existence?

I believe that dxml works at compile-time, since IIRC, after I gave my talk on it, someone created a PR to make the few changes necessary to make it work at compile-time:

http://code.dlang.org/packages/dxml

I haven't ever used it at compile-time myself though.

- Jonathan M Davis

On Wednesday, 5 February 2020 at 02:20:00 UTC, Adam D. Ruppe wrote:
> On Wednesday, 5 February 2020 at 02:06:58 UTC, Kaitlyn Emmons wrote:
>> It crash from manipulation but does it ever crash just parse and read?
>
> Not for me but I almost always just do it at runtime; the compile time isn't as well tested. (I've only done little things with it at CT)
>
> But the same principle should apply to the other D xml parsers so maybe one of them will be better.
>
>> to try parse and auto generate a VK binding from VKapi.xml that krhonos releases :) But it is big and complex xml so need stable parser.
>
> You might be better off doing it at run time anyway - write a program to load the xml and generate it as a separate step in your build process.
>
> With a CT binding, every single build is going to have to reparse all the xml and regenerate the binding and the compile time function executor in the compiler is kinda slow.

simple build process > fast build process .. not gana fuck with two step build system who got time for that... not me lol... also if it is separate module and does not import other modules, shouldn't rdmd recognize it doesnt need recompilation if the xml and module dont change?

On Wednesday, 5 February 2020 at 04:37:34 UTC, Kaitlyn Emmons wrote:
> simple build process > fast build process

hah yeah i know how you feel. Though I want BOTH!

The good news is almost all your code would actually be the same thanks to CTFE calling ordinary functions. So if you change your mind, you can change like `mixin(generate())` to `file.write(generate())` and otherwise basically keep it the same.

So an easy decision to change your mind on if needs be in the future.

> modules, shouldn't rdmd recognize it doesnt need recompilation if the xml and module dont change?

rdmd only caches the end result, not intermediaries. But other builds can do it... just at the cost of some of that simplicity.