 Yeah, hi everyone, it's us again and there's some news from the WebAssembly project, or this push to get, have another angle of getting LibreOffice running in the browser. So yeah, we've got some news there with Kalk and some headless operations now working. Welcome to the talk, who's talking, Balazs Varga, and Thorsten, we're both working for Allotropia and, right, so first of all, big thanks to NLNet and by extension, a big thank you to European Union for actually funding this. So if you can't see the text, because it's kind of in that contrast, let me know and we fix that, patch that up on the spot. So yeah, why are we doing this? Very quickly, the LibreOffice Proceed with this LibreOffice technology and also with all the porting that was happening since many, many years, LibreOffice is just the prototypical thing that you want to run natively, like everywhere, and it's been ported to very many platforms and devices and architecture. So it was a natural idea when Wasm was gaining popularity in 2014-15 to try that and we tried it and it didn't quite work and so we waited out a little bit and then we tried it again and I think it's a natural thing to do, like games and other applications running in the browser, that's kind of one of the platforms that matters and it's kind of becoming more and more of an operating system with the, like, you can access very many things already from a browser that previously you had no access to on your system. So that's why we did it. Let me know if you indeed can't read the text. Can you? Interestingly, it has better contrast here, why is it broken in the slideshow, who broke that? So we can maybe just do it here then, if that's better, and write some toolbars, some more toolbars. That's probably as good as it gets. So the thing, kind of, working title, Lova for LibreOffice WebAssembly, it's a native port, it runs client-side, like fully sold, like you don't need a server, you just need to put some binary blob somewhere on a static, on a web server, or you can have it also locally, but you need some decode somewhere and then it pulls it and runs it in the browser. This is said to be funded by an Elnert Horizon 2020 and Alutropia Challenges, quite a few as it turned out. The maturity of the platform, I think, was the biggest problem, the biggest single issue that we faced because it's very much work in progress, very active, which is good, but also very, kind of, fragile, something breaks randomly and you really don't know if, as always with open source, either you fix your bug yourself, or you wait for someone to fix it, or you pay someone to fix it, and the platform itself, like the browser, the M script and etc., it's kind of extremely large surface there, and then the usual problems with LibreOffice are very large, very many party dependencies, notorious to break everything left and right, because of that size, size of the resulting binary. We kind of knew that from the start, so we tried to work around that by kind of cutting everything off, like arm slacks, whatever, you didn't really need to live, we just wanted to write it to run, so that's kind of both the download size, that's a problem, and also the size in the browser, because you essentially have tops for gigabytes, but you probably shouldn't use all of that, so essentially you got realistically one gigabyte in the browser without blowing things up left and right, so yeah, being small, and of course your binary size counts towards the, because it gets loaded obviously, and the browser counts towards that one gigabyte. Multithreading, you also knew that's going to be a challenge, so we tried to disable that, and for that, right, it's kind of a useful target, because when it was developed, it was co-operative multitasking, so writer procedure doesn't really need multithreading, writer is happily sending itself time or events to do something in the background. Yeah, and development and debugging was extremely challenging because of the freshness of the platform, so yeah, we made some progress down, hacked size, if you compress it nicely, some 35 mags, found some way to separate debug info out, which really helps, because it's not GDP and Chrome is actually decently smart only to pull on the amount of what it needs, size of the file system image, so you know, it probably needs a lot of auxiliary files, like fonts and config and dialogue, GUI definitions, and all of that needs to be there when you want to run it, and that's kind of sizable, blocks about 100 mags with everything, so we also tried to cut that down a bit, and then this embedability thing, so that actually, as always, there's very little point just to have it running in the browser, you want to put files in and get files out and possibly control it from or embed it in a larger application to do something useful with it. And it was pretty clear from the get go that we're not going to get this to some very dynamic runtime, quote, generation style, you know, bridge to run in the browser, so kind of opted out of that. Current status, most of that is upstream, there's two more patches in Garrett that are not much yet, but it's mostly a master, you can build it, if you want to figure out how to do that, read static slash read me, and there's a feature branch with a bit more work going on, master, that's essentially the status from February this year, master is hopefully still running as office, and master status is fine now, you get writer, and as of today we get a bit more running down. So timeline very briefly started a while ago, then there was some death march, and it was quite unclear whether we would pull it off, and I'm quite glad that essentially last year's liberal first conference, like a week, so we got together, we got some hacking done, and about a week later things started to fall into place with ECL, demo, kind of doing the first movements and then crashing, not crashing right away, and then everything else is history, so we had a foster talk with the writer coming up. So status right now is kind of working, PDF export is working, also headless C, you still see GUI, but you can switch that off, and ongoing is kind of like really have something headless, like without any main loop running, and yeah, this kind of inventability, so kind of get some demo JavaScript framework, at least one working where you can just stick it in SNI frame and running inside your web app. Core ideas, pretty straightforward, like we did all the other ports, like Android, iOS, just use auto tools and plug in the right parameters, set up the right environment, and then just kind of toil away at it for a year, so until it builds and links and in the end runs, and so I think we were in pretty good shape there, probably, because we've already been porting that through very many platforms. GUI abstraction, yeah, so we were kind of pondering what to do there, and luckily it turns out that there's a Qt plugin, or Qt backend that uses Qt for main loop and a GUI toolkit for rendering, and also Qt turns out to have a wasn't port, so that sounded like a good idea, and it also turned out to be a decently smart idea, so there were some problems, but it wasn't that massive, and so that's Qt 5 right now, the target, there was Qt 6, it just got some, I think, 6.3 or something, and that's kind of second tier for the Qt company, so they only now started to get WebAssembly on the Coreline 6 going, and we haven't tried it yet, but we might, and so for the Linux desktop part, there was a Qt 6 plugin, so we could try that, but we haven't. So yeah, we went full for that, and that was not silly. Core ideas, yeah, just use M-scripten and cross build it. There's a few more compilers, but M-scripten looked like mainstream enough, and with enough activity, and enough people kind of coming back, that sounded like a useful choice, and yeah, so that does for the three things, so we cross build, we use M-scripten, we use Qt, we don't use anything experimental, that was something that we learned over the time of the project, that it's not a good idea to use anything experimental on that platform and focus on writer. Major problems in moving targets, so the M-scripten platform was, so it turned out if we would have started the project nine months later, we would have had much fewer problems. On the other hand, since we kind of learned so much and so we got the groundwork going, so maybe it was very close to the perfect time, I don't know, but it was kind of painful. So it even was that if you installed the exact same M-scripten version on your developer machine, depending on the time of the day and the face of the moon, you would get different setups, because it would randomly pull some Node.js and it was not kind of properly pinned and kind of irritating. So initially we went with the Docker setups where we could at least make sure that every developer would get exactly the same build environment, so ruling out this, oh it crashes, no it doesn't crash for me, how is that possible? And then two days later you figure out that your setup was different. G-build, yeah we needed static linking because in the end what you get is, so there's in theory dynamic linking for WebAssembly, but it's very experimental, so it was a no-no, so we needed static linking and since we were kind of very, very, very active in cutting things off and Android has a static linking as well and also iOS, but it's kind of manual, so you just list like I need those libraries here and we thought that should come from the build system so and then we, Jamux, embarked on a massive project to add static, proper static linking to G-build, which also took quite a while and it's a massive change now to G-build, but we can do that now and the silver lining is we can also do it for example for Linux, so now you can get some S-office, LibS-office and it's just one library that you can link into whatever you need it for. Why me speak to some because we want to show you a demo, major problems, there were plenty, so the most, just to tell you that story because it's so irritating, then I will never forget that, so when we started and we were kind of finally able to statically link all of that into one, into one block, it turned out that the linking stage took north of an hour and something like 80-ish gigabytes of memory just to link, which was one of those cases like nobody had the problem before, it was some, some pessimization in the Python code from M-scripten, nobody had the problem because everybody was smaller and so there was some O-N-square or O-N-cube loop there which was just blowing up for us and nobody had it before, so yeah, so we fixed the problem by venting some EC2 massive builder and building there, but it really slowed us down because imagine you can't debug, so your only way to debug is to put in some equivalent of a printf, so it's not a printf but it ends up on the browser console, so your turnaround is one or two hours, so you put a printf there and then you figure something out and then you put another printf somewhere else and you need to of course build and link again, so two hours later you are, so and that's like you can't really develop like that in any way, in any efficient way, so actually we kind of put the browser aside and then did the debugging and stripping down on Linux because we had the static linking there and it worked decently in comparison, and meanwhile that got fixed, so there was this kind of the platform evolving in a good way. Yeah, the static thing, so let's go over for some real moving pixels here I'd say, so let me get to, so how you do that, so that's the feature branch, so first you need to source the script environment, people who were back in the day working with OpenOffice might remember that, like sourcing some environment in your shell and then you run that thing, so you have a little local server that serves the stuff and opens that in a browser, in this case you really want to use Chrome, like not Chrome, unfortunately the hope is that it's getting better over time like with Firefox catching up, but for now trust me you want to use Chrome. Thank you, Dorstan, so let's see some demo about this, I'm working on that running in WebAssembly a little bit more than one month and also on the hardless conversion, but it's the mouse, it's okay, so as you can see it's example document with some very simple example, for example, auto filter, you can see there are the elements as well, and you can also click on here and the auto filter also works and the charts as well updated, thanks to that there are also shapes in the image, in the example document and what is more important that if I press this anchor, it's not working, I just want the debug mode, but let's try it with fn, f12, yeah that's better, so now you can see there is a debug mode here, just let's wait, the Chrome loaded core folder and you can put here breakpoints and let's see what's happening, I just put breakpoint launch auto filter menu, so let's hope it will stop there, oh yeah that's really great, so there is a breakpoint and you can see here if it's loaded, it's a little bit slow of course, but it's working, you can see the local variables if it's stopped, it's working and there is a call stack as well and you can move on that back and forward and there are also the local variables as well and I mentioned the call stack and you can move forward with this button and that's now it works and also let's see again, you can jump just one if you push this button but in that case maybe it will crash, I hope not. Yeah as you see, it's like 8% okay, so it's kind of still some rough edges on this let's say developer experience part, but let's be honest that's like leaps and bounds better than having to print a debug, something as complex as LibreOffice and it's like yeah, so that's a thing that I'm quite comfortable waiting out so if it's unbearable wait three weeks and Chrome will ship an update and so that's pretty nice in a sense that there's a lot of activity and also a lot of like Chrome gets better and then Firefox gets challenged to get better as well and so. We start again. Just reload? Sorry for that, the problem is here when we try to load the file it's very big and memory cannot handle such a big file because of that the Chrome is crash, that's why it's not always working just yeah, of course and also I can show the PDF export as well, you can click here on the PDF export directly and it's also there are breakpoints but I just keep them and there is a downloaded PDF file which is exported here and you can open in the next tab and there is the exported file and you can do that as well from the console with the Lodoc Brofiskit command just press that one and there is the Uno command for the export directly to PDF and that's also a breakpoint there, just keep that. It might be a bit hard to see but we can maybe put it on the slides so it's essentially interacting on the JavaScript site so that's something that you could do from your website or from the JavaScript code on your website to control the brofisk by sending it commands. Yeah, but it looks like it also works from the command line with the Uno command as well and you can open it in the next tab, it is downloaded to the local file system because in the WebAssembly we use memory file system which is very different than the others but maybe we will talk about it a bit later. Back to the slides. Yeah, let's skip over that. So essentially what would really like the step change and productivity was actually getting Chrome debugging to work and you can also do that on Linux as you see since Chrome there is a flat pack, it's a bit more involved but anyway it works, this is how you do it, details are on the slide so there's three steps you need to do to get the remaining problems, the plenty, so the largest things that in a browser you can't have nested main loops because you can't just like busy loop in a browser because the browser obviously wants to do, like once the page needs to stay responsive so whenever you do this classic LibreOffice thing like open a dialog, that opens another dialog so you have this kind of main loop calling into the main loop recursively, yeah, you're screwed. So what we need to do and there's been collaboration and other people have been putting lots of work into that already to get more dialogs into async mode and normal reschedule calls and that's what we need pretty much for every dialog that we want to run in WebAssembly and there's some example commit how to do that so if you're interested in that it's not an easy hack but it's like an interesting difficulty, easy hack and I would appreciate it clearly. Yeah, I think Balastad's mostly like what you've been fighting with this memory file system. Yes, it's a really tricky one because as I mentioned earlier that use a memory file system in the WebAssembly which is a virtual file system, this is the default file system which is mounted when the runtime is initialized and all files exist strictly in the memory and any data returned to them is lost when the page is reloaded and because of that at the moment we have to read and write the file between the different file systems so just like at the PDF export we have to download the file to the local file system but maybe in the future we change the memory file system to load file system which can access as to reach the local file system and in that case we can load a file right from the local file system for others so that will be a future plan but very tricky. And it makes sense so you reload it again and then you get user settings so there's a way to have some local storage in browser and of course there's the local file system where you would want to load documents from so that's kind of work to do. Qt, as I said, perhaps update to Qt 6 right now we use a patched 5.15.2 that we kind of forked and that's on the GitHub repo down because as I said it was good but not perfect so we actually, the Jamux in that case fixed a number of problems down so that's kind of pinned to that branch right now. Alternatives, using something else possibly like in the end states use something like natively so where we would in particular if we don't need GUI, like if we don't need natively for this GUI but we just have the document and then some JavaScript GUI around that then it would probably make sense to kind of have some minimal VCL plug that renders directly to WebGL or whatever but that's kind of future thing. Yeah, many more things to do kind of running out of time. Maybe it's important to WarC so that's like a, not a browser but it's like a server runtime headless like Node.js but for running WebAssembly which is interesting for something like PDF conversion really because it's very much more portable than having, I mean Linux binaries are nice, I mean everything is running Linux on a server but maybe you can't install software or it's kind of restricted environment so this was clearly interesting for doing headless stuff. Dynamic loading could be interesting because it's a way to cut down even more like the initial number of bits you need to download and yeah, G-Build, G-Build was cut quite super painful, like really, really, really annoying amount of work that we have to put in there. So MISON is a bit of this shiny future thing, I don't know if that's going to really help but at least the dependence, you'll get a lot of, you'll get a lot of stuff for free from MISON because other people already put in the work. Okay, that's brought yet a lot of time, project plan finished and merged the kite stuff and then switched to JavaScript like some demo, UJS or something else where you can embed that and have some demo application that targeted until the end of the year. Yeah, out of time slides will be online so any questions then there will be answers. How big is QT as a proportion? So the question is how large QT is in proportion of this 100 megabyte blob there. I didn't do that recently, Armin might remember it but I think it's something like less than a quarter but it's still sizable. When I remember it was something like 18 to 20 percent. Yeah, so you can save quite a bit, I mean it's not a seed change, it's not that you... So the challenge really with the size is that you're not getting cashed in your browser, that really kills all the fun because then you download it again and again and again when you reload the page so getting below that magic size where your browser starts caching the build and everything lower than that really doesn't matter anymore because so once you can treat your browser and once you're cached it's like instantaneous, it's like two seconds, it's almost faster than native to start your developers because it's kind of, I don't know why, it's static and kind of just in time compile whatever magic happens there but so there's a very... And then it's a very large incentive to do whatever is necessary to get below that size and once you below that then you can just put your feet up. So getting the queue dependency out to me has more like just more control over your fate so you're not depending on queued anymore in terms of like their timeline, their amount, their quality of wasn't supported, et cetera, et cetera. Any, maybe one small question, otherwise we're all here, just hit us up in the whole way or mail us slides, we'll be online, talk is recorded. If there's no further questions, then thanks so much and keep enjoying the conference.