What I'm adding, and what I'm planning next...

[richmond62]

Just got back:
-

SShot 2024-08-29 at 17.47.27.png (360.06 KiB) Viewed 6043 times

-
That must be a record or something.

Let's do a compare & contrast thing:
-

SShot 2024-08-29 at 17.49.56.png (29.32 KiB) Viewed 6041 times

-
3 minutes 15 seconds

[richmond62]

If you can possibly roll the timer stack into 107, or even better, make it available as a free-standing stack: I can run compile tests with LC 963, OXT Lite 107, and OXT Heavy on both MacOS 12 and MacOS 15.

[tperry2x]

If you can possibly roll the timer stack into 107, or even better, make it available as a free-standing stack: I can run compile tests with LC 963, OXT Lite 107, and OXT Heavy on both MacOS 12 and MacOS 15.

I have just done exactly that for v1.07

I've also attached it, so you can drop this into LCC 9.6.3, or OXT Heavy, or whatever you wish.
[location of your LC or OXT app]/["Tools" folder if on a mac]/Toolset/libraries/revsaveasstandalone.livecodescript

[richmond62]

Just super. Thank you very much.

[tperry2x]

I'll continue this on the Devawriter Pro topic here, in a moment... I have a load of screenshots and results of testing to upload...

[mwieder]

Not to distract you from benchmarks, Tom, but here's an easy one for you.
This fixes linux printing (bugzilla #21131).
LC is trying to shell out to lp to do the printing, and that requires elevated privileges.
This patch uses the cups library instead.

[OpenXTalkPaul]

Not to distract you from benchmarks, Tom, but here's an easy one for you.
This fixes linux printing (bugzilla #21131).
LC is trying to shell out to lp to do the printing, and that requires elevated privileges.
This patch uses the cups library instead.

Nice, thanks Mark!

[tperry2x]

Not to distract you from benchmarks, Tom, but here's an easy one for you.

Don't worry, I think I'm almost done with that. (edit: I am done with it now)

This fixes linux printing (bugzilla #21131).
LC is trying to shell out to lp to do the printing, and that requires elevated privileges.
This patch uses the cups library instead.

Thanks Mark. This is very very much appreciated. Great work, and I hope it can be rolled into the source for the engine.
Actually, that's a good point. This isn't meant as a 'snarky' remark (or anything like that), it's a genuine question:
Is the engine of LCC the one we are using from here, here, or here currently? - is it possible to pull all these together (for want of a better phrase?)

Either way, I've also added it to my list of possible C++ engine fixes, just in case anyone asks me ever.
I don't think it's going to be easy for me to implement any C++ changes to the engine any time soon, and I think I'd rather wait to see a release of the engine from a github repo - that way I know I'm getting any cumulative fixes.

But once again, genuinely, a massive thank you for working on this. All updates to the engine are very welcome, and are very much needed. (don't solely take my word on that, but the voting poll at the top of this topic would suggest people feel the same).

I'm probably going to take a back seat from OXT Lite development for a while, due to other circumstances, so someone else can pick up the lead from here.

[OpenXTalkPaul]

Not to distract you from benchmarks, Tom, but here's an easy one for you.

I don't think it's going to be easy for me to implement any C++ changes to the engine any time soon, and I think I'd rather wait to see a release of the engine from a github repo - that way I know I'm getting any cumulative fixes.

I second this!
Mark if you don't want to or have time to package a release, then could put the binary up for your Linux build of the engine, along with it's Standalone Builder stack and .wasm Engine build, that would be awesome! I'm very interested in seeing how the webAssembly version engine is compared to the v9.6.x gigantic JS version. I'm also working on Linux a bit more again lately and trying to get OXT DPE (aka Heavy) up to date on Linux.
Thanks.

[mwieder]

Changes to the engine itself aren't enough to get more standalone options: there's a whole folder of support files for deployment and standalone actions. At the moment I take the "if it ain't broken, fix it until it is" adage seriously and I've messed up non-native standalone building, so give this a bit of time. Plus, as I said, the engine alone isn't going to do this. I'm currently running my latest engine build in a slightly modified LC 9.6.12 envelope and it's stable within reason. Busy for the next while, so nothing imminent upcoming.

[richmond62]

I'm currently running my latest engine build in a slightly modified LC 9.6.12 envelope and it's stable within reason.

I am not sure how much use that is going to be over here in the Open Source world.

[mwieder]

Eh?
It helps verify that I haven't broken the engine enough to affect usability.

[OpenXTalkPaul]

Changes to the engine itself aren't enough to get more standalone options: there's a whole folder of support files for deployment and standalone actions. At the moment I take the "if it ain't broken, fix it until it is" adage seriously and I've messed up non-native standalone building, so give this a bit of time. Plus, as I said, the engine alone isn't going to do this. I'm currently running my latest engine build in a slightly modified LC 9.6.12 envelope and it's stable within reason. Busy for the next while, so nothing imminent upcoming.

OK, no rush. I may try to compile it myself on Linux if I can find the time.

I completely understand that the Standalone Builder library scripts AND the Standalone Settings (UI stack) AND the standalone engines runtime all need to be altered to modify a standalone deploy options (we've already done this when adding 32bit-Mac option back into Mac deploy options).
I'm pretty sure that all that I really need to get that web-assembly going is the compiled Emscripten .wasm which would probably be next to the js folder in:
PathToIDE/Tools/runtime/Emscripten/
Other than the wasm engine itself, the other files for web assembly I would think would be very similar to the contents of the JS folder, a standalone-template folder and an html file to load the engine and a .mem file.

Screen Shot 2024-09-05 at 9.33.38 AM.png

"slightly modified LC 9.6.12 envelope"?
I'm sure you know we can't use anything from LC from after Sept.1st 2021, since it's not GPL thereafter.

[mwieder]

Yeah, no worries.
I'm just placing my engine into the LC directory structure to make sure I didn't break anything on a huge scale.