BIT-ROT!

[tperry2x]

It doesn't work like that because it's 1) unfinished and 2) NOT compiled to web assembly format, it's compiled with older ASM.js based version of Emscripten. Re-compiling to .wasm could cut the current 28+MB file-size in half, and speed up execution. Either way the loading-time should be much faster if loading from local storage (specially with m.2 SSDs).

That sounds good. Yes, I'm using m.2 SSDs here, but the weak link in the chain for me is about an 8MB/Sec internet connection. So it's always going to be dog slow. A progress bar while it loads would at least give an indication that it's doing *something*, rather than not responding.

Also, you mention that it's not finished, but who actually owns the Emscripten thing?

IMO, the main advantages of WebASM is NOT code opaqueness (I see that as a DISadvantage), it's the execution speed and the ability to compile existing code from desktop dev, like OXT's C++ engine code, into byte-code that can work on anything that supports running wasm.

It really depends on if you are trying to protect what you have created or not. I think that's what potentially puts a lot of developers off moving to a browser-based solution - everything can be unpicked and copied for any purpose. In a collaborative open-source sense, that's great - but sometimes you really don't want that. Again, horses for courses - the right thing at the right time I suppose.

[OpenXTalkPaul]

...of course there will always be a bit slower performance versus using native machine code compiled code but that 'native' is one of the things makes an executable not-platform agnostic. WebASM, just like native assembly is not machine code so there is still some interpreting down to the machine's language that needs to happen. Also for some things that don't require maximum speed, I don't think it's really needed, not when we can just piggy-back xTalk interpreter on top of existing JS infrastructures (that we don't need to maintain, which is the huge advantage there).

There are other plenty of other languages, such as Python and Lua, where this porting to run in 'browser engine as a platform' as already been achieved.

[tperry2x]

...we can just piggy-back xTalk interpreter on top of existing JS infrastructures (that we don't need to maintain, which is the huge advantage there).

I can't help wondering how much we might be making a rod for our own back here. I mean, I bet LC once thought - if we base it on C++ and we bundle up all our libraries at compile time, then there's nothing that can break... right?
And here we are with underlying OS changes to the way menubars are drawn, and a complete architecture change...

I do wonder if something drastic changed with the javascript engine that stopped everything in it's tracks, then there we are again... but then I could become unnecessarily worried about that. If there's one thing that the title of this thread eludes to, it's that you can't ever stop bit rot entirely - not unless you can shun all modern technology and stop anyone else from upgrading too.

But that's the issue of supporting an OS that keeps changing. That's why I like Linux and *shudder* windows - although Windows Explorer and the OS is packed full of telemetry, but at least it means you have a solid base to start on, rather than something that feels like it's built on shifting sands.
So anything that changed in Javascript - in theory, to remain standards compliant, it would have to change on everything I assume - so at least makes it feel like it's harder to make a sweeping change out of the blue.

[OpenXTalkPaul]

I'm using m.2 SSDs here, but the weak link in the chain for me is about an 8MB/Sec internet connection. So it's always going to be dog slow. A progress bar while it loads would at least give an indication that it's doing *something*, rather than not responding.

Delivering any interpreter engine via the web is always going to be affected by download speeds, the best we can do for that is to try to keep such an xTalk engine as small as possible. Dan's HC Sim is small, under half a megabyte (without all of the extra Hypercard assets). Decker is similarly small.

However the OXT loader page should contain a loader progress indicator that spins and provide some text feedback just above that SVG stack icon while it loads the engine. It works for me on every device I've loaded that page on, which includes an Android TV. https://openxtalk-org.github.io/OpenXTalk-Playground/ (that just took about 8 seconds to fully load here, on old MX Linux laptop with 5400rpm HD)

Also, you mention that it's not finished, but who actually owns the Emscripten thing?

I meant that the port of the OXT engine to Emscripten is not finished, there are some things that don't work at all, don't work correctly, and functions that don't return valid information. But of course Emscripten is still under developement as well.

Who owns Emscripten?
according to Google AI:

AI Overview
Learn more
The Emscripten project is open source and is governed by the emscripten-core organization on GitHub. It's available under the MIT license and the University of Illinois/NCSA Open Source License.
Explanation

The MIT license is a well-known, permissive open source license.

The University of Illinois/NCSA Open Source License allows Emscripten's code to be integrated into LLVM, which uses that license.
Alon Zakai was the original author of Emscripten.

Emphasis from me. It doesn't matter so much to me who initially created it as much as the licensing matters. A very liberal permissive license like MIT means it can be used any way we like.

It really depends on if you are trying to protect what you have created or not.

I would suggest to people who want to keep their source-code closed that they get a subscription to LC's services, that is what they're selling right?

[tperry2x]

I would suggest to people who want to keep their source-code closed that they get a subscription to LC's services, that is what they're selling right?

But what about if you want to keep it away from being affiliated with them in any way?
Even with encrypted content in a browser - as soon as anything gets interpreted by a browser, and gets rendered to a page, it's all viewable in source anyway? So how does anyone protect their intellectual property, even if they wanted it to be accessible for the good of the open-source community - but not for all and sundry [or any company] to see the source?

[OpenXTalkPaul]

Also I just remembered, there was some trick to speeding up the Emscripten engine port to load by loading in a more progressive way, with async transfer of the massive (for .js) engine file. I think Hermann posted some info on that trick somewhere.

But the biggest improvements though would likely come just from recompiling the Emscripten port to .wasm instead of huge .JS file that it currently is (un-minified / beautified or putting return/line-breaks and tab characters back into the JS script, it becomes an over 50 megabyte file!)

[richmond62]

You cannot protect your source code as such, but you can bind it up as much as possible with CopyLeft statements.

[OpenXTalkPaul]

But what about if you want to keep it away from being affiliated with them in any way?
Even with encrypted content in a browser - as soon as anything gets interpreted by a browser, and gets rendered to a page, it's all viewable in source anyway? So how does anyone protect their intellectual property, even if they wanted it to be accessible for the good of the open-source community - but not for all and sundry [or any company] to see the source?

Licensing and lawyers I suppose.
The inherited GPLv3 license currently governs the OXT source, although LC still owns the copyright on the source as it was left to the community. Any additions to that work from us since then are ours, but must remain GPLv3 to comply with the original LC Community license.

[tperry2x]

That pretty much outlines why you'd want to start afresh. If for no reason other than it feels a bit like renting a house, where someone could pull out of the deal at any time.
The fact that we have these MacOS issues has perhaps solidified the issue further, as to why it's important to start afresh. To sign up supposedly protecting my code on a LC server just feels like signing that joint tenancy agreement all over again. Why rent when you can buy, and actually own something outright.
My apologies, as I'm getting off topic (kind of).

The point being that you'd have to sign up to some proprietary service or subscription model to protect your code, so coming back full circle, even if compiled web assembly adds a level of encryption/obscuring then it's welcome from that point. However, I really want to avoid putting it in some kind of wrapper for the sake of code privacy - which as far as I can see is about the only practical advantage.

This pretty much answers my question, and this comment which I'll quote:

If you truly want to encrypt it so that no one else can decrypt it, you could use one of any number of encryptions. For instance, to do it manually, you could use TrueCrypt; or to do it programatically, use the encryption libraries available in most languages.

If what you are really asking, though, is how to obfuscate the code so that no one can reverse-engineer it, the answer is: you can't, not in Javascript or any other language. The best you can do is make it more difficult on the reverse-engineers by making it hard to read

So wrapping it up in layers of legalese and BS seems the way to go.

[OpenXTalkPaul]

The fact that we have these MacOS issues has perhaps solidified the issue further, as to why it's important to start afresh. To sign up supposedly protecting my code on a LC server just feels like signing that joint tenancy agreement all over again. Why rent when you can buy, and actually own something outright.

I signed the agreement. I had to in order for them to accept pull requests so that I could contribute fixes to the documents back when LC Community was still a thing.

IANAL but .... here's a scenario:
Supose some graphics person at LC Ltd. says 'hey I like that method Paul added to the revMenuBar for copying groups of graphic controls to the clipboard as SVG path strings' and then adds that code to their current version of revMenuBar file...OK that's fine but then they would need to publish their source for that file in order to comply with the GPLv3 license that MY OXT addition to that code is licensed under (the inherited GPLv3). Which I suppose we could potentially benifit from seeing any changes they may make to that code from then on. They could just write their own version of the functionality, or say they did, I suppose and not have to publish the source, but I can't worry about that sort of intelectual theft. One of the important things is the GPLv3 license is meant to keep the source open, prevent people from taking GPL code and making a closed source version from it. LC still owns the engine's code so that's different, they have the right to do what they want with their versions of it produced after the discontuning of thier open-source version. But our changes to that same code thereafter are ours and still subject to GPLv3 no matter who wants to use it, even if that someone works for LC. Ltd. (which is why they probably wouldn't want to use it).

In the end all that I really want is to see xTalk scripting be out there in the WILD as much as possible accessible and for a long time, and heck maybe even proliferate *gasp*.

And again I'm not opposed to jumping ship to a different 'runtime', it wouldn't be the first time. (and in fact at this point there are other programming languages I'd be comfortable using as well, but xTalk is the only one I'm passionate about, AppleScript was kinda cool though)

[tperry2x]

In the end all that I really want is to see xTalk scripting be out there in the WILD as much as possible accessible and for a long time, and heck maybe even proliferate *gasp*.

That makes perfect sense, and I can't echo that statement enough. That's exactly how I feel about it.

And again I'm not opposed to jumping ship, it wouldn't be the first time. (and in fact at this point there are other programming languages I'd be comfortable using as well, but xTalk is the only one I'm passionate about, AppleScript was kinda cool though)

Yes, it's just a shame that Applescript (I know, the clue is in the name) - but a shame it is just on MacOS. If only they'd made that available on Windows and Linux too... hang on, you used past tense. Don't tell me they are killing it off?

Don't also tell me they are replacing it with this? [*checks the date of that page to make sure it wasn't published on April the 1st*]

Did Apple not learn anything by watching how unpopular windows 8's 'live tiles' were?


This seems to be the continuing theme: dumb everything down to the point of having a powerpoint-esque interface to everything. It's like AtEase is making a comeback for MacOS!.

ateaseadvanced.png (25.28 KiB) Viewed 1493 times

Except AtEase made no apologies for what it was - it was to provide a simplified interface for those who could not be trusted not to screw up their mac. I suppose it's history repeating. So now, this is bit-rot for Applescript editor too!

[OpenXTalkPaul]

I actually miss that 'button icon view' in the finder / launcher/ 'at ease', which I guess is a bit like 'launch center' or whatever they call it. But 'shortcuts' I think are a bit more like Automator things, and you create them graphical blocks scripting actions / macros.

I'm not aware or any announcement about AppleScript from Apple as far as deprecation, but I don't think they put a lot of resources into that anymore. xTalk is the closest thing to it in a cross-platform language.