BIT-ROT!

[richmond62]

Erm: Sorry about those slightly Over-the-Top postings: you can blame it on the 'virus' that has sent about 50% of the children I teach to bed with gut problems, sore throats, and temperatures, so I have too much time on my hands.

BUT: one thing is clear: there do need to be more contributions from more 'bottom feeders' like myself: after all as OXT has no fudning it has to get some semi-decent feedback in lieu of market research.

[tperry2x]

Erm: Sorry about those slightly Over-the-Top postings: you can blame it on the 'virus' that has sent about 50% of the children I teach to bed with gut problems, sore throats, and temperatures, so I have too much time on my hands.

Nothing to apologise about. I didn't take offence to any of it, and it's all useful discussion to have. We need to think about these issues.

BUT: one thing is clear: there do need to be more contributions from more 'bottom feeders' like myself: after all as OXT has no fudning it has to get some semi-decent feedback in lieu of market research.

We can have as many examples as we like, and I've been adding to what I have as I go, but ultimately - if people have nothing to run it on... well, it's all for nothing. That's my concern. Keeping something running, that DOES actually run.

As I say, there aren't a great many alternatives - and that's purely because, when you consider the amount of time and effort required, nobody is going to work for free making it.

[tperry2x]

My worry is that all the work we've both done is ultimately going to amount to nothing in the long term

Haven't you read Ecclesiastes or any philosopher actually! We all die in the end, sooner or later and our work and even the memory of us as a person will soon fade.

Yes, although as in ozymandias, I would like something more than just a fragment of a statue in the desert to remain after I'm gone. The goal is for people to continue to use the xTalk language in it's entirety. Not having any viable methods of doing that, other than buying a commercial offering, kind of knocks that on the head somewhat.

The difficulty that anyone making a commercial xTalk is always going to have, is that:

• Free tools exist already, as does free-to-use programming languages (Python, Swift, C/C++, Javascript, Rust etc)

• These tools and languages already have a larger established user base, more examples, more active projects, and more successful completed projects using them.

• These languages can do more at a lower level than a high-level language like xTalk can (I know, this is what builder / xBuilder was for - but that's another discussion). I'm also aware that Python is itself a high-level language, but it can indeed do more than xTalk can

The advantage of xTalk is in it's simplicity and readability. It was conceived to be a language that anyone could script in, without huge technical barriers getting in the way. How then, are you ever going to convince someone to invest in a language that:

• they'll have to re-tool their entire project in

• learn from the ground up, when they may already know (and are comfortable in) javascript, C++, Swift etc

• that has limited IDE support, so it might not run in your chosen OS (or rather, some of it will, bits of it won't).

• that does not offer complete functionality to control the hardware

• Is not going to be mainstream, due to those limitations above.

In my view - it's not going to happen, and making the language a paid-for product makes no sense.

You might then wonder, "How is Python free?" - it kind of is, and kind of isn't. (Which makes me wonder about the implementation of Python 2.7 that's used in the engine, but I digress...)

Python is funded through the "Python Software Foundation" [wiki] - so how does the Python Software Foundation make any money?: Through grants, sponsorships, donations, and membership programs.
So while 90% of people who use python will probably never think about licensing if it's for their own personal use (if they aren't being asked to subscribe or pay at download, they will assume it's a free tool), the foundation can make money by these means. Keeping the language effectively free to use for the most part.

As far as Swift, well.. Apple aren't short of funds.

There is no scoreboard and you can't win because there is no game. So do what you need to do to make yourself, the people around you and your little corner of the world better because that is all that you can count on.

That is why we need to have these discussions, but out in the open. We are a small group of people who ultimately have an interest in this, and if we aren't all working in unison, then there's little point. But if we don't all talk about it, then how are we going to reach an agreement or a plan of direction on anything?

[tperry2x]

Coming back, more on-point, what do we need from an engine?

• We need it to be 75-80% compatible with known xTalk script.

(I'd probably say more than that actually) - if you take script that works in LCC9 and try and run it in LCC7, most of it won't - you'll encounter things that just aren't implemented.

• We need it's interpretation skills

What I mean about that, is the engine is simply an interpreter. When you are in the IDE, typing script in xTalk, the engine is hard at work constantly behind the scenes getting and sending messages back and forwards to the IDE, checking that what you are actually writing is valid script.
The computer's CPU does not know how to interpret xTalk script, so what you are actually doing is (on a greatly simplified level):

Typing in xTalk > the engine interprets this and checks if it's valid > if it's valid and doesn't throw an error, try and make sense of it (interpret the script) > break this down into pre-compiled C++ code (look for prerequisite functions and handlers)> pass this to the main CPU as a valid assembly instruction set (or throws an error back up the message path if it's not valid). The CPU ultimately breaks this down into binary and processes it.

So there's a lot of abstraction / interpretation and various layers of processing going on.

My point to this? - When we are considering an engine making sense of the xTalk scripting, it's actually doing a lot behind the scenes. The task of writing this kind of interpreter is not a small task, and not an easy one either.

It's probably more accurate to think of the engine as an emulator of sorts.

[richmond62]

It's probably more accurate to think of the engine as an emulator of sorts.

Well, unless you are feeding Ones and Noughts directly into the machine there is always some level of emulation going on.

As LCC was Open Source from version 6.something right up to 9.6.3 the source code for ALL the versions should be accessible.

if you take script that works in LCC9 and try and run it in LCC7, most of it won't - you'll encounter things that just aren't implemented.

OK, OK; let's break down your statement into 2 bits:

if you take script that works in LCC9 and try and run it in LCC7

Very true: but might it not be worth sacrificing that and basing a new engine on code froim, say, version 7 of LCC: which might simplify things quite considerably?

Then:

you'll encounter things that just aren't implemented.

Quite: but they could be re-implemented on the basis of a new engine based on an earlier version of LCC.

At the risk of being accused of over-simplifying things:

The 2 things missing from version 7 are SVG capabilities and Widgets/LCB.

Attempts at getting stacks running in HTML are not up to snuff, so missing those would not really matter (that whole area has to be rethought out and re-implemented in a way that:

1. Doesn't involve downloading some clunky engine onto everyone's machine before a browser can display anything.

2. Works.

Of course version 8 sist between versions 7 and 9 (I believe I am going to get an honorary doctorate for that incredibly profound statement): and,
from my experience at least (versions 1.0 to now) post RR 4.5 there was always a case of 5 steps forward, 4 steps backward, and also quite often some fancy footwork off to the side. So "retrenching" to version 7 or 8 may not be quite as daft as it seems.

The symptomatic phrase over the last 8-9 years "over there" has been 'work around'. ANd something that never ceases to surprise me was that the "faithful choir" (back up LC regardless) never seemed to thing that the accumulating pile of work arounds began to look just a teeny-weeny bit NEG.

[tperry2x]

As LCC was Open Source from version 6.something right up to 9.6.3 the source code for ALL the versions should be accessible.

You can get hold of the source, you can't get hold of the prebuilts for each engine version (we only have the ones for 9.6.3). And you know what a story that was.
Neither can we generate the prebuilts for each version, because much of it on which it depends does not exist online (linked libraries have moved on). I mentioned this before somewhere on this forum. Can't find it now though.

Ultimately, if you don't have the prebuilts, you don't have a working compile of the engine.

[tperry2x]

..."retrenching" to version 7 or 8 may not be quite as daft as it seems...

Certainly not version 7 if you want it to work on anything above MacOS 10.14, because LCC7 was 32-bit. (With the exception that LCC 7.1.2 on Linux was 64-bit capable natively at the time - it was the first of all the 3 platforms to go native x64 with LCC).

That means we'd be looking at version 9.6.1 of LCC if we want a 64-bit engine on MacOS. "OXT Lite Retro" is based on a LCC 8.2.0-dp1 engine, because it's 32-bit (and is the reason it only runs up to Mac OS 10.14 not beyond).
You won't find the 8.2.0-dp1 source in the github repo. It's not there. It's like it never existed, so if you want (well, you need) 8.1 as a minimum. (8.1.7 is as close as we can get to it) - but this won't be any good for Catalina or above.
You also have an issue there. LCC 8.1 does not generate valid codesigned MacOS binaries the last time I checked. (Pretty sure I have that right), as far as Sonoma is concerned - 32-bit only, and is another reason I used the last source I had available.

The other thing, as mentioned, we don't have any prebuilts for v8 of the engine either. That's across the board - on Linux, Windows, or MacOS for the engine compile to stand a chance.

Going backwards, I hate to think what version of GTK is used in LCC7 and 8.x ? (actually, I'd assume it's probably still GTK2 and this probably hasn't changed since LCC7 all the way up to LCC9). - so that doesn't move us forward on the linux front either. (we still have the GTK2 depreciation issue, or even moreso if it's GTK1).

Also, the windows version of LCC7 is 32-bit - and that's great all the time Microsoft keep 32-bit compatibility. I'm sure they'd love to ditch that, but there's just too much legacy server cruft that still relies on it. (for those organisations still reliant on Windows servers).

It's not until we get to version 9.6.3 of LCC that it became a 64-bit application on Windows (and 9.6.1 on MacOS respectively). My opinion is that they should at least all be 64-bit native, otherwise we are digging ourselves another potential hole) - this rules out going backwards somewhat. Also, I certainly don't want them to be on different versions of the engine across various platforms. - that would make updates absolutely painful. I'd do the wine wrapper before I'd consider that!

The short version is if you want the engine to run on anything above MacOS 10.14, you'll need v9.6.1 of the engine as a minimum. This is why I'm using the source from the 9.7.0-dp1 (I also wanted all the bugfixes available).

[axwald]

You can get hold of the source, you can't get hold of the prebuilts for each engine version (we only have the ones for 9.6.3). And you know what a story that was.
Neither can we generate the prebuilts for each version, because much of it on which it depends does not exist online (linked libraries have moved on). I mentioned this before somewhere on this forum. Can't find it now though.

Ultimately, if you don't have the prebuilts, you don't have a working compile of the engine.

Hi,
have you read this?
Maybe somebody could talk to SFC & ask for advice? Maybe LC Ltd. would would actually publish the old stuff if nudged by someone semi-official?

No idea if this would help. But it might be worth a try. I'd do it, only I don't haven't the least idea about github, prebuilds, compiling and this stuff ...

[Kdjanz]

The more I hear about the trials and tribulations of trying to recreate a tottering tower on a base of porous and treacherous sand, the more I wish that you were moving ahead with the Zed experiment that you were working on. Clean slate restart seems like it might actually be less work and more long lasting.

The other idea that I am moving towards is that of the web thing. I personally hate web based anything because it is not in my control and the web page may disappear tomorrow taking all my work with it. But I just tried Docker running locally on my Mac and displaying in my browser on localhost:3000 and it seemed to be Ok. It was local to me and the files I was running came directly off my own hard drive, so I felt enough control to be comfortable. Maybe a new engine based on web coding could work and eliminate most of the cross platform issues in one stroke.

I really wonder how much is gained really by sticking with legacy. We want to promote xtalk on any platform and in any shape or guise that will make it accessible to more people.

[tperry2x]

The more I hear about the trials and tribulations of trying to recreate a tottering tower on a base of porous and treacherous sand, the more I wish that you were moving ahead with the [Zig] experiment that you were working on. Clean slate restart seems like it might actually be less work and more long lasting.

In my view, it makes absolutely no sense to continue with trying to shore up the old LC engine now. Even the 9.7.0-dp1 version you find in the github repository is probably next to useless.
Why? Because you can't get most of the linux libs that the compile requires (the only reason mine does is because I had to seriously faff with the package repositories on my local dev box, to the point of almost completely confusing it). The Mac version of the engine is pretty much dead, because it seemingly won't compile on anything. I've now tried all versions of xCode from 7.12 upwards and including 16.2.1 -- no joy. In fact, it's a very joyless experience.
I never thought I'd say it, but the windows version of the engine seems to be the only one where you don't have to jump through serious hoops (although there's a lot of initial setup). But at least it all works.
Not surprising really, and I know I knock Microsoft - however, what they are good at is providing legacy support. Which is definitely what we need with the engine in our case.

I had been focussing my efforts on trying to use zig. (To be clear, I only used zig for the last part of the compilation process - for it's cross-compiling abilities). It can generate arm binaries quite nicely. Of course, these won't be codesigned or plist'd either, or even be a MacOS bundle. So, I feel I'm barking up the wrong tree there.
I'm making a rod for my own back, because that example is based in GTK3 and if I tie it to a certain GTK version, I'm only going to end up with the exact same problems that the engine has with GTK2 - just a bit further down the line.

This is as far as my web implementation got. (not very). It was more just a proof of concept. To see if I could actually do it.
There's the bare bones of something there, and it only uses Javascript (not a java app), CSS and HTML. Nothing exotic and stuff that every browser would support out of the box. It can be run on your computer locally without doing various local docker stuff, and ultimately - it could be run totally offline too.
That is the better way forward as you rightly say.
But this isn't an engine in any way yet. It's not even capable of running a stack. At least it has a point and click GUI of sorts though.

Anyone can expand upon it. Put it into a github repo (if that's your thing), & do what they want with it.
All I ask is they let me know about any efforts to do so.

Screenshot 2025-01-28 at 10-45-47 HyperTalk Parser.png (49.73 KiB) Viewed 560 times

You can get hold of the source, you can't get hold of the prebuilts for each engine version...much of it on which it depends does not exist online... libraries have moved on...if you don't have the prebuilts, you don't have a working compile of the engine.

have you read this?
Maybe somebody could talk to SFC & ask for advice? Maybe LC Ltd. would would actually publish the old stuff if nudged by someone semi-official?

That would be a nice try, and I'm sure they are relying on nobody having the time or inclination to pursue it further. (Unless a legal-eagle is reading this and wants some work), I can't see anyone bothering.
Not that it would help us at all, even if we did have the prebuilts this time around.
Let's say we were trying to get the prebuilts for version 8 of the engine. There's no point because this is 32-bit on MacOS. That means it'll only run up to MacOS 10.14 maximum. You'd need to backtrack all the x64 source from the LCC9.6.1 engine into LCC8.x / LCC7.x engine somehow. As it's such a complete mess (I doubt anyone outside of LC-circles can fully make sense of it) - that's if they can remember how it all is supposed to work now, it's going to be a nightmare to sort out.

My wish list:
Just to be clear, I'd rather just take the 'lexxer, parser, and interpreter" part of the engine - along with all the keywords, definitions and function handling from the engine. I want it to be able to draw on screen using libSkia (an updated one), and to load a stack. The rest of the LCC engine can be discarded. Once we are in a stack, on a canvas, and we have our familiar commands - I'm all good - and can build up from there.

• I'd love to take the LCC7.1.2 source (64-bit linux version), have it decoupled from GTK2 - or updated to GTK4.

• Include GTK4 embedded as an included library.

• Then take the 64-bit engine and make that work on MacOS and Windows.

• Incorporate my mods here..

• Additonally, update all external references to any libraries, to pull in new ones. Even better - have a 'dependencies' folder for each platform, and include all linked libraries recursively there. (yes, I know - large). However that's the only way to guard against bit-rot. Have a copy of everything locally so you aren't reliant upon external third parties. The same with any "prebuilts". The full source for these, and any linked libraries should be included too. (Along with pre-compiled ready-to-go .so and .a files).

• Get rid of gyp completely

• Recreate an xCodeproject manually, one that actually works for MacOS and can be run on OSX 10.9 to MacOS 15+

• Make the xCodeproject version xCode 9.3, so it can be compiled on a wider range of hardware.

• Properly correct the errant menu code on MacOS

• Update the MacOS theming to match the rest of the OS, no matter if you are in OSX 10.9 through to MacOS 15+ (also respecting chosen hilite and accent colours).

• Make a copy of the xCodeproject as an Arm inclusion, so that Mac Arm users open this to generate an arm engine compile - instead of attempting to mix bits of intelx64 libraries in with the arm xcodeproject (stops compilers getting confused).

• Retrofit all the additional terms from LCC9 and LCC8 back into the LCC7 binary.

• Externalise the browser, the "player" - video player, and the Builder syntax. Making these things that can be toggled on and off easily, not embedded as part of the engine.

• Allow the use of something other than mplayer if that's not working.

• Make the "player" object non-blocking

• Give the shell command a non-blocking option, with a variable for returned values

There's probably more if I actually gave it lots of thought...
BUT, that's not going to happen. Nonetheless, that would be my wish-list.

yeah-I-wish.png (416.01 KiB) Viewed 557 times

[Skids]

Hi,
I can't say I'm surprised by the details presented in this thread and its sad but if I have understood correctly then at some point in the not to distant future OpenXtalk will stop working on both Linux and Mac.

Thank you for the information and all the hard work that has gone into looking for a viable way to find a solution.

S

[richmond62]

OpenXtalk will stop working on both Linux and Mac

I think that that is a misrepresentation of the situation.

OpenXTalk (as it now is) will NOT stop working on CURRENT versions of Linux and Mac: OpenXTalk (as it now is) MAY not work on future versions of Linux and Mac.

And before everyone gets too hysterical and starts chewing the carpet, frothing at the mouth, and generally over-dramatising things, I should like to point out that I have recently deployed a licensed version of Runtime Revolution 4.0 on Xubuntu 24.10 ("Ludricous Langour" or some other silly name).

This WHOLE THING is getting way out of control.

"BIT-ROT" as far as it means anything means this:

1. If you want to update the current engines inherited from LiveCode: forget it.

2. If you want to spin off NATIVE Mac ARM standalones: forget it.

3. If you expect OpenXTalk to run on ALL Linux flavours: forget it. [LiveCode never behaved itself on ALL Linux flavours].

OXT Lite "as it is" works very well on MacOS 15 (Sequoia) after a bit of fiddling about.

OXT Lite "as it is" works very well of quite a few Linux distros.

So: unless you have major hangups about points #1, #2, and #3: clam down and use your energy somewhere else.

[FourthWorld]

OXT Lite "as it is" works very well on MacOS 15 (Sequoia) after a bit of fiddling about.

What "fiddling" is required?

[richmond62]

Personally I jus disabled my 'whatever it was called' so I could allow "install from anywhere" and then ran the 'run this first' thing inside the DMG.

I have been running OXT Lite on MacOS 14 and 15 without any further trouble.

[Skids]

clam down and use your energy somewhere else.

great typo - I'm off to clam down!

S

[FourthWorld]

Personally I jus disabled my 'whatever it was called' so I could allow "install from anywhere" and then ran the 'run this first' thing inside the DMG.

I have been running OXT Lite on MacOS 14 and 15 without any further trouble.

That's good news. The menu issue was fixed and we have an ARM compile?

[Skids]

I see OpenXtalk on mac as a short term solution

1. If you want to update the current engines inherited from LiveCode: forget it.

2. If you want to spin off NATIVE Mac ARM standalones: forget it.

3. If you expect OpenXTalk to run on ALL Linux flavours: forget it. [LiveCode never behaved itself on ALL Linux flavours].

S

[richmond62]

we have an ARM compile?

I am not the owner of a post-INTEL Mac: and, unless someone wants to lob me somewhere in the region of $750 I am unlikely to be one any time soon.

Or, as my English Granny from Norfolk used to say, "Go out and eat worms."

[Good things come from Norfolk, so I've heard tell.]

[richmond62]

I see OpenXtalk on mac as a short term solution

Well. coming up to 63: 10 years post heart attack (5 stents and counting): long term solutions mean probably either a walking frame or a coffin.

Certainly retirement is unlikely to see me get "all hot and sweaty" about not being able to deploy my 'latest thang' on MacOS 69.

[Skids]

long term solutions mean probably either a walking frame or a coffin.

that should be walking frame then a coffin ?

Certainly retirement is unlikely to see me get "all hot and sweaty" about not being able to deploy my 'latest thang' on MacOS 69.

Yes but! Apple are requiring that users of Sequioa manually download Rosetta2 meaning that it will probably be disabled in OS Sequioa+1. This will add complications such as running MacOS in a virtual machine and I have little doubt that the security features will be an even greater PIA. So there comes a time to stop banging ones head against a wall.