OpenXTalk Forums

richmond62 wrote: ↑Wed Jul 24, 2024 5:59 pm

It's certainly more than 4 (and a half) - more like a couple of hundred.

It would be extremely nice if they could show their heads above the trench.

TRENCH

OpenXTalkPaul wrote: ↑Fri Jul 26, 2024 12:32 am If I ever get me an M-series Mac I think the first thing I'll do is install Xcode and see if I can compile StackSmith to M-cpu native. I had no problem at all compiling that xTalk engine/IDE from source.

How about instead of going m-series Mac and that expense (and ever-shifting goalposts), you try on a raspberry pi with an arm processor?
I'm wondering if it would allow you to run an arm-centric distro, which we could compile arm versions for single board computers. I did get Windows 11 to run on a raspberry Pi quite well, so I wonder if that would allow for a windows ARM port too.
Of course, that won't solve the MacOS-shaped elephant in the room though.

tperry2x wrote: ↑Mon Jul 29, 2024 9:37 am

OpenXTalkPaul wrote: ↑Fri Jul 26, 2024 12:32 am If I ever get me an M-series Mac I think the first thing I'll do is install Xcode and see if I can compile StackSmith to M-cpu native. I had no problem at all compiling that xTalk engine/IDE from source.

How about instead of going m-series Mac and that expense (and ever-shifting goalposts), you try on a raspberry pi with an arm processor?
I'm wondering if it would allow you to run an arm-centric distro, which we could compile arm versions for single board computers. I did get Windows 11 to run on a raspberry Pi quite well, so I wonder if that would allow for a windows ARM port too.
Of course, that won't solve the MacOS-shaped elephant in the room though.

Yes, exactly. But more specific to porting StackSmith to RPi Linux Arm is that StackSmith's UI uses Objective C / Cocoa APIs. Still I think it may be worth trying to modify those bits to instead use GNUStep equivalents or to use some other UI kit like Qt or GTK. The underlying xTalk dialect (called Hammer) interpreter might not need much modification at all.

Does't this just serve as another distraction from the original goal?

To CONTINUE with LiveCode 'Community'!

I'm not too fussed what the underlying 'engine' is. I'm more interested in can we compile it? Can we change it as we need to? Is it something with a future, or is it something that's a complete mystery and locked away beyond all modification?

Ultimately, if the engine is running on every platform we need it to, and we can all make changes to it, then THAT allows us to continue with an OXT engine. That would be the continuation of the xTalk 'community'.

At the moment, I can only get it to compile on 1 platform and changes are very difficult to say the least.
I can't see there being much continuation with the present engine.

By only one platform I take it you mean Linux.

I have my serious doubts (there being 4 main distinct Linux variants) whether Linux can be described as ONE platform.

Okay, I should then clarify.

Out of all the OS and platforms we would like to see the engine running on:

Windows intel (x32)
Windows intel (x64)
Windows Arm (x64)
MacOS 10.6.8 intel (x32)
MacOS 10.9 intel (x64)
MacOS Arm (aarch-x64)
Linux (GTK2) intel (x64)
Linux (QT) intel (x64)
Linux Arm (x64)
Linux (ChromeOS) x64 (m-series)
Unix (armv7l)

Currently, we have one successful compile target out of the eleven listed above.

But one thing seems obvious to me - with all those different architectures and platforms in mind, the engine should be as minimal as possible - with everything abstracted away from being locked up in an application binary. It should all be referenced as either a library or a stack (externally), so that changing any of this does not have to result in a recompile of the engine.

Personally at this point, I'm getting to the point where I'm increasingly hamstrung by the engine and find myself thinking more about what alternatives can be used. Even if that is seen as a hugely backwards step initially, it may be best to start from bare-bones with something that does actually compile and isn't locked in.

I can say though, that it's an absolute headache to get a C++ parser to understand xTalk and all it's nuances.
For example, if I want to do the equivalent of the xTalk script: I'd have to do this in C++ Now that might not sound too much of a problem, except when you consider I can do the following in xTalk: C++ just does not understand that kind of high level abstraction, so you need a lextable to break it all down into it's component parts. Then tokenise it into various sections so it can be made sense of. A parser to make sense of it all (essentially reassembling it into something that makes sense to C++), something that does error checking and error handling during that parsing if it doesn't make sense, something to then interpret the response back from C++ code into xTalk, then finally something to output it back to either a command line or GUI. Not easy, and multiple layers to work through. It's a pain.

Or to put it another way, writing an engine for xTalk interpretation is more like writing an emulator. After all, you are turning one load of instruction set into another, then delivering the result back into human-readable form. (so perhaps the idea of running the interpreter in as common a language as possible is not a bad idea), but even assembly or machine code has it's differences between processors.

Now this might sound negative, but this is why I consider the only 'active' version of OXT lite to be the linux version - it's the only one I can currently make any changes to the engine in (getting rid of the registration screen at first launch), so currently the only one I see as having a viable future. The others may as well be read-only (as they are effectively 'stuck' at that older version if they won't compile).

If someone gets the Mac (or more likely) the Windows versions to compile without throwing any warnings, then I'll feel a lot happier. Until then, it's why I'm interested in an alternative engine.

richmond62 wrote: ↑Mon Jul 29, 2024 5:02 pm Does't this just serve as another distraction from the original goal?

To CONTINUE with LiveCode 'Community'!

The goal for me has always been Free Open-Source Software xTalk.

IMO it would be even better if it were a liberal MIT license.

It's just that the LC CE base is the most capable, cross-platform open-source engine(s) that's available to us. But it's big ol' beast of a thing, built on top of a Unix engine from the early 1990s (when I was in my early 20s!).

big ol' beast of a thing

Well, that reminds me of MacOS 9.2: carrying around with it an accretion of code from years back.

The odd thing is that Apple, on dumping it, did not start a new, new operating system: they made something to 'float' on top of a type of UNIX.

The really funny thing is how Apple were being very rude about Windows 95 and 98 'floating' on DOS: and then Apple went and did something similar.

I wonder if 'our friends up north' will not use the 'jump' from "one thing to another" to sort out a series of new engines (even if they are promising to keep what they are (inevitably) calling 'classic' chuntering along until 2027.

Obviously,were it possible to modularise and externalise 90% of what is contained in the big ol' beast of a thing (Richard Stallman has written quite a lot on modularisation) and be left with a "leaner, meaner" engine that would be fantastic.

But, I suppose, failing that a different xTalk engine from elsewhere might be better.

The more LEGO-like xTalk can become the easier it will be for end-users to build what they want with fewer constraints than with a big ol' beast of a thing.

LEGO is almost completely unconstrained.

richmond62 wrote: ↑Tue Jul 30, 2024 11:41 am

big ol' beast of a thing

Well, that reminds me of MacOS 9.2: carrying around with it an accretion of code from years back.

The odd thing is that Apple, on dumping it, did not start a new, new operating system: they made something to 'float' on top of a type of UNIX.

The really funny thing is how Apple were being very rude about Windows 95 and 98 'floating' on DOS: and then Apple went and did something similar.

I don't remember Apple being rude about DOS being underneath there knock-off OS, but I do remember Win-fanboys being very smug and proud that they get to type long strings of commands at the command prompt.

And just for accuracy, what Apple did was they ported the Unix base AND NeXT step to PowerPC, rebranded NeXT step to 'Cocoa', changed the graphics to be more 'Mac"-like (at first, in Rhapsody that meant OS 9 look), as a stop-gap added virtualization for the previous OS to run old apps inside of (the 'Classic' environment), and THEN built on top from there. And they didn't do that until after years of failure trying to build a new OS (Copland) with all the buzz-words like 'thread-safe preemptive multitasking'.

Obviously,were it possible to modularise and externalise 90% of what is contained in the big ol' beast of a thing (Richard Stallman has written quite a lot on modularisation) and be left with a "leaner, meaner" engine that would be fantastic.

But, I suppose, failing that a different xTalk engine from elsewhere might be better.

The more LEGO-like xTalk can become the easier it will be for end-users to build what they want with fewer constraints than with a big ol' beast of a thing.

LEGO is almost completely unconstrained.

I'm all for the 'LEGO' metaphor, with a wide-range of shapes and sizes to build with, that is why I like Extension Builder so much since it makes it easier to create new pieces without the need for a whole LEGO factory.

IMO Modularizing / externalizing everything that's not the core language is the way to go, that's been discussed here before at length.

Some syntax currently already uses an 'Externals' like revSpeak, and thanks to the 'branding' there we can implement a 'Speak' command however we like without breaking old-stacks that use the old syntax (unless we remove revSpeak external, which was never fully cross-platform anyway).

Any non-external syntax that uses OS APIs ('play' command) I'd like to remove from 'reserved words' list so it can be over-ridden on the scripting level and implemented however we like, using a external command line tool, extension module, plain-old script, or whatever.

As I've said before I'd like to have libraries that handle the abstraction of underlying implementation(s) for syntax/APIs that are not really part of core xTalk language (by 'core xTalk' I mean our current favorite dialect with Array syntax and all of that). These libraries would determine the best available method to use, preferably ahead of time on loading of the library. This is the way some things, like revLibURL, already work, and this was the design goal in mind when making 'general music' library with its playPMD/PerformMusicData (synonym) command.