Okay, let's continue.
One more person joining, great.
There you go.
The death room is almost full and we have
GCC Cobalt talk that has not even been on the agenda
until this morning.
That's great.
Can we please resume?
All right, so James, thank you very much again for being here.
We discussed this last night that we had a change in the schedule
and unplanned cancellation and James offered to do
impromptu, GCC Cobalt talk regarding
some other parsing use of lipics, ML2.
Maintenance of that and all these funny things
that you need to do in engineering,
in a proper compiler, which is not just a research kind of
fun thing, but James has done GCC Cobalt talks
on every instance of the GCC death room at
the end of the day.
So we have a different system, so here's another one.
Good morning, everybody.
We're afternoon already, I think.
So, talk is about why and how we're going to do
XML in Cobalt, so I'd like to give it the why part.
It is because they said so, that is to say,
I'd be in defines a verb in Cobalt that says
we're going to parse XML.
It's very simple.
Parse, sorry, XML, parse,
buffer name, function.
For every element that the Cobalt that these are,
the XML parser generates, we call the function.
That function knows there are, for what two cold registers
that describe the element and the function does whatever it does.
He is a compiler writer.
I don't have actually much to do, right?
That's not a lot to parse.
Then, I had to figure out a way to make that
actually happen in the system.
And that comes to the what part.
It's interesting that if I wanted to make GCC happy,
I could just write my own XML parser.
No controversy.
It's a library.
Nothing to discuss.
Build it right in.
Done.
But you don't get a beard this collar
without learning some things about how the world works.
And one of the things I decided was that as confident as I am
of parsing, I mean, what could be easier than parsing XML.
A tag, properties, text, a closing tag.
It's as simple as could be.
There's expressions with a lot of ugly syntax.
But then, on the other hand, if I look around the world,
I find that there are two XML libraries out there.
Both on satisfactory.
After decades of operation.
So, there is perhaps some possibility that there are aspects of this parsing
problem that I don't fully understand.
And I say to myself, okay, we're going to have to use library.
And I use the security vulnerability that the GCC gave that you last year.
And I commit to the library, the library, the live jicoval.
I commit a new dependency.
We're going to use the live XML to library.
We're going to use the Sax parser.
Job done.
This is where we encounter the other part of the web part,
which is you do engineering in the large.
You have a lot of people to satisfy.
And it turns out there's not a single opinion about how to do these things.
So, now, okay, I'm not going to write my own parser.
I'm going to use this library.
How am I going to make that library open and useful to the
couple programs that are going to take advantage of this feature.
Another thing that would have made GCC very happy is to just make this option.
If we make it optional, then it doesn't really matter how it comes in
because the person who builds the compiler just makes the decision.
But here's the problem.
It's not really an option.
If you say that the XML library is optional,
then you say that some part of the functionality of the compiler is optional,
which means that the user has either got the whole compiler or some of the
compiler.
He doesn't know that I made that choice.
And so, who are making these choices?
Well, we could make it optional and then the package,
the guy who does the packaging, he could decide,
except he doesn't know what the user is going to want,
because the user doesn't know yet.
And if he didn't know he's wrong, because that's going to change later.
So, each time you provide an option about what's going to be a
concluded or not included, you really just give somebody else a choice
that isn't a choice, which means he has to make a choice to bring that thing in.
So, I don't want to make it optional.
It's not really optional.
I don't want it to be the case that when the user arrives at his XML horse thing,
he gets an error back and says,
the compiler didn't give that to you.
So, not optional.
Then the question is, how do so find?
Now, we've got this terrible library.
I should point out terrible.
So, I said earlier that the only options available to us
were unsatisfactory.
And live XML2, unfortunately, has a not very stellar reputation.
It has seen a lot of changes over the years,
and not been terribly good.
Apparently, it's not an experience I had, but when I'm told
that the ABI has been a little variable.
So, keeping track of the versions of XML2,
I'm going to use over the generations of GCC that are going to be available.
Who's going to take care of that?
How are we going to account for many of the security violations reports
that are maybe maliciously, maybe whatever generated we don't really know
how important they actually are, but there they are.
How do we deal with them?
So, should then live XML become part of GCC?
Do I become the maintainer of this thing?
I, who bets it never saw the code actually,
and just want to use it.
So, my user can have his feature.
Do we rely on the target?
Do we, do we say, just look at the package,
or just have to put it in some place and go find it?
And then, if, do we allow it to be statically leaked for some packages that
want to build a compiler in that way?
These were all the questions, and different people want different things
from the system.
They actually want different GCCs.
So, I put this to the steering committee last month,
and I said, last month?
Yeah, last month.
And I said, hmm, so should we bring this in?
Should live gcote, sorry?
Should live XML, too?
Be like Z-Live.
Put it right in the repository.
Build it like everything else.
Make it a bootstrap library.
And I think the answer is, no.
I think the answer is, that was one way to do it.
And it could be the case that some people who are doing packaging want to build
live gcobal from source and build live XML, too,
from source and link it in statically.
And that should be an option.
But it may be the case that do not necessarily do that.
So, I think what the consensus hope the consensus is.
We just have to make it as flexible as possible when we configure the building of the library
about which version of live XML you're going to bring in.
And then simply run, you know, rely on the runtime linker to pull that in.
So, do I cover the what, the why and how yes.
So, we're doing this because the user wants to be able to parse XML.
We've decided to rely on runtime dynamic linking to make it happen.
But to put in a bunch of configuration options when you build the library that will establish
where that one is coming from, who wants to pull it in how, whether they want to link it
in statically, whether they want to rely on the target to supply it.
So, that is more or less what I want to say.
And I thought, you know, there's this gnarly engineering question might spur questions.
So, I thought I would have let ask you if you had any.
You are in trouble.
I'm in trouble.
I'm always in trouble.
Yes.
So, it was very easy to have a talk with a site and you made it very captivating.
So, thanks for that.
Oh.
But now's the question.
Yes.
You think that you don't want, in a way, to be fair based on the HTML being there or not.
But is XML part of the standard, or it's an extension of the command of the user system.
It depends on what being by yes.
The verb I mentioned at the outside is called XML pars.
And your question is, is that part of the standard?
My question is, what's the standard?
So, yes and no.
The ISO not only has not included this verb as part of the official 2023 standard.
It does not intend to include it as part of the 2022 standard.
So, no.
On the other hand, IBM.
Yes.
So, IBM added this to their compiler.
They also have a JSON parser, by the way.
They also have XML generate.
If anyone here has worked in finance, you've encountered one or two XML files in your day.
And we chose to use the sex parser because not only we're going to see XML files, but they're going to be big.
So, it's not an international standard, but it's a standard of the international business machine company.
And that's actually good enough for us.
So, the question is, can I use options about dialects and so on when the compiler runs to decide whether or not the future is available?
And the answer is yes.
In fact, that option already exists.
The question is whether we want to build logical, depending on whether, so, if you have such an option, when you build your co-valt program, that doesn't change what features are available in the library that that co-valt program may be available.
So, I have no way to build the library and then say this library only supports these versions of the co-valt standard.
Well, you could do lazy loading.
I could do lazy loading.
So, I could use deal open, you mean?
Yes, something like that.
Yes, at the risk of having an error when the program runs.
Yes.
Simon is thinking to the question of whether deal open opens another can of worms and the answer is absolutely true and he's speaking from experience.
Yes.
I have to admit I was a little bit disappointed to not see a parser written in co-valt, which would solve the mission.
So, if we wrote our XML parser in co-valt, we would solve it elegantly.
Absolutely true.
If indeed, I have finished the project.
And then you'll maintain it.
It's acceptable for a partner to take the flag.
Similar to that, you print because it's also standard advice.
You know, it's linked in the repo.
So, it's a special part you've created.
Then instead of having a little bit of repo home, I'll link for the next moment.
There could be a little bit of repo for that scenario.
We're trying to acquire it, you know, that could then be probably even written by us separately.
So, I didn't understand every word you said, but if I can try to repeat what you were suggesting is that the weather or not, I'm sorry, the time is up, so I don't have to answer.
Thank you.