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 12265 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 12263 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.

[tperry2x]

I was just poking around in old versions of LCC, as one might, and discovered that the old standalone builder in LCC 7.0 Linux-x64 supports building on Arm Linux.
So, I wonder if this can be bought up-to-date, and I wonder about incorporating that in OXT Lite.
It would be cool as we can then deploy for Raspberry PI's.

this-is-cool.png (182.01 KiB) Viewed 3511 times

As a side note, my god LCC 7.x is fast compared to LCC 9.x - the script editor absolutely knocks the spots off the one in LCC 9.x

[richmond62]

The first difference between 7.0 and 8.0 is the "Massive Unicode Clunk", which from an entirely selfish point of view made my day re Devawriter Pro and Sheba:Madeka.

This is NOT necessary if you are after something for the Raspberry Pi.

The jump to 8.0 was almost as big as the jump from 10.0 to 'Create' might be if they pull it off. That obviously came at a price.

LCD, Widgets, script-only stacks . . .

[tperry2x]

I mention as I was interested in seeing if I could get a recompiled armhf (also referred to as armv7+) - or 32-bit ARM program. It would be a handy thing to have if it could be made aware of the 9.x language. With raspberry pi devices being cheap (raspberry pi 3 is 32-bit arm), and they can be gotten hold of easily, aren't locked down like a chromebook and can be installed by SD card - it's a handy platform for Arm development - and I'd of thought in education (supposing of course you don't have this dictated-down and mandated to you).

I'll probably try downloading an arm32 / armhf version of debian too at some point, and taking it for a spin on a raspberry pi.

[tperry2x]

The jump to 8.0 was almost as big as the jump from 10.0 to 'Create' might be if they pull it off. That obviously came at a price.

Yes, I've been reading about the 'Create' saga thread over there. It seems to be dividing opinion a bit.

LCD, Widgets, script-only stacks . . .

LCD?
I know Paul loves his Widgets, and I can take or leave script-only stacks. I could probably have lived without unicode support too, but each to their own.

Strangely, just been reading in the LCC7 release notes:

Supported encodings are (currently):
"ASCII"
"ISO-8859-1" (Linux only)
"MacRoman" (OSX only)
"Native" (ISO-8859-1 on Linux, MacRoman on OSX, CP1252 Windows)
"UTF-16"
"UTF-16BE"
"UTF-16LE"
"UTF-32"
"UTF-32BE"
"UTF-32BE"
"UTF-32LE"
"UTF-8"
"CP1252" (Windows only)

I'm just super impressed with the responsiveness of the IDE in LCC7 - it's absolutely rapid. I can barely even blink after pressing return to open it, and it's open.

[richmond62]

Erm, sorry: LCB.

[richmond62]

Unicode support, of a sort, was there in 7.0, just in a more complicated fashion.