Another xTalk implementation...

[tperry2x]

In the spirit of this topic, regarding "xTalk implementations", here's another xTalk implementation...

One of my own creation.

Don't get your hopes up too much though. It's very much still in it's infancy. Think of this as just an update as to where I am with my zig implementation. I probably underestimated just how large a task it is to create an xTalk engine.

As far as I am with it, I've got the basics of it I think. The following screenshot is using capy for the interface GUI (so should be cross platform with native interface controls eventually).
It's using a spot of C++ which is the minimal code required to interpret a very (VERY) minimal set of xTalk syntax so far.

It's capable of reading an image (hence the splash screen) - only png support so far, getting the screen rect, and a lot of work has gone into building an interpreter.
A lot more is required. (no support for any menus), it doesn't understand anything to do with 'tools' yet - it has no concept at all of 'widgets', network, extensions, libraries, geometry manager, no script editor (yet), no syntax colouring, no message box, no inspectors, no dictionary, no database support, no audio (other than causing a system beep!) .... the list goes on (sigh).

(quite depressing when I think about it, the amount that I have yet to do).
Whether it'll ever see the light of day fully or not is another thing.

Oh, there's also no error catching - so when I try and implement anything that's unsupported - such as choosing the pointer tool (the button on that splash), it just locks up the computer

I suppose handling errors and a message box of some sort needs to come next.

What can it do? At the moment, it's a proof of concept that it works. It can understand rudimentary xTalk - it's capable of writing a prefs file and recording the placement of the preferences window (woop!), it can load in graphics, thanks to capy, and pngLib - but it's using a btn graphic with an icon being pulled in from the png file. It's a regular oxtstack stack format too. So doesn't look like much, but underneath, it's doing quite a lot of xTalk-ish things.

None of it is using any Livecode / OpenXion / (serf) engine - it's all of my own creation (having been inspired by looking at the source code of all 3 for hours on end last week and this week).

Of course, this will be totally free to use and modify as anyone sees fit. At the moment though, it's what I'm doing when I'm not bug-fixing in OXT-Lite.

Not much to show as of yet, but better than the first demo I posted where it just draws a window with a text field, that beeps!

p-in-the-wind.png (326.45 KiB) Viewed 525 times

[richmond62]

Right: let's have a download link so we can get down and dirty.

[tperry2x]

Right: let's have a download link so we can get down and dirty.

I'm a long way off that. Ha, this is only Linux and at the moment, requires lots of dependencies. Plus I just managed to cause a full lockup on another Linux pc (XFCE rather than Mate), so it's not at all ready for human consumption.

Please read the above post: this is not a full (or even partial) IDE at the moment. It does load and save stacks successfully though.

Edit: think the lockup is due to me inadvertently making it rely on needing an Nvidia based GPU. (That's the trouble with borrowing some open source code, and me not reading the notes closely enough).

Just meant as an update in case anyone thought I'd given up on my zig build.

Zig is essentially my last-stage compiler (or cross compiler when it comes to it). Hopefully so I don't have to bother with Microsoft Visual Studio for the windows compile, and I shouldn't need xCode when it comes to producing a Mac version thanks to Zig's cross compiler) although it might not be capable of cross compiling the whole engine. That's a big ask, and there's stuff that needs to go in which is mac specific - which I've not even thought about solving).

[richmond62]

I already have a version of your 'thing' on a Linux laptop at home (Xubuntu), and so far have had no problems.

[tperry2x]

That previous version of tIDE is based on the Livecode engine. This is an entirely different version of my "thing" where I'm starting from scratch.

Reinventing the wheel? Probably.
Needlessly? Possibly, depends on your point of view,.
Lots of work for no apparent reward? Definitely.
Ready for it to be scrutinised: not in the slightest. No thank you very much. (I'm a hobbyist, not a professional coder!)

Feedback can also be demoralising, especially when it's taken me about 3 (and a bit) weeks of pulling my hair out (and the rest before that reading up on C++, zig, capy and WxWidgets) to get this far.

Incompatibilities? Yes, plenty at the moment!

I'm also not quite ready for this to be pulled apart for review yet, (not that there's much to pull part without a GCC and Zig compiler for Linux installed and set up.). About 3MB of it is the various Linux libs (although think there might be more I need to bundle up), then there's the xTalk syntax (Very incomplete as of this stage), capy for the interface elements, with wxWidgets providing the stack rendering and GPU support, then a small amount of C++ initialisation code to tie it all together. A bit of a headache so far thrown in for good measure.

Not much in the way of xTalk script in there as yet (well, about 100ish lines of it), but comparatively small compared to the rest.

My other goal with this: I'm using the old addage of 'keep it simple', ....but also efficient. None of the xTalk script I use will be a mystery (it's all commented as I go). It doesn't go off here, there, everywhere, and back again.

Yes, I'll use functions to reduce code duplication, but it'll hopefully all be logical for anyone to follow.

I guess, being totally candid about everything: when I'm either too old to do this anymore, or long gone - I'd like my contribution to this project to be more than "he took the LCC build and messed about with it... He never got around to making his own engine though", so this is my ongoing (slow) attempt to do something about that. More for my own amusement I suppose.

[micmac]

So if you succeed with this, you could also build an ARM version for Mac?

Mic

[tperry2x]

I suppose so, but that's a bit of a far off goal for me as yet. I'm more familiar with Linux than anything else, and there's plenty of mac-specific things that would need to be added to make this work.

For example, if I were able to get the zig cross-compiler to compile this into a runnable binary for MacOs, I'd want it to run as a standard double-clickable .app instead of something you have to open a terminal and run. I may have to resort to xcode for that bit.

I've no idea how to bridge the gap between intel and arm at the moment. I've read, re-read, re-read and re-read Apple's support documents about migrating an app from intel to arm, but they assume that everyone is using xcode and not a different compiler.

I'll have to see how it develops. (No pun intended). I don't really want to have to recreate what I've done so far in xcode (a lot of work), and it's not quite as straightforward as that because there's different display libraries used to draw something on MacOs than on Linux or Windows. WXWidgets and Capy serve this well, but each platform has their own support libraries that need adding for each platform build.

Plus, with MacOS constantly changing, who's to say that Apple don't change something in their OS and it all breaks? Like the emergency binary engine patch we had to apply to get OXT working in Sonoma.

I think my focus will be on Linux and Windows initially, as they provide far less roadblocks and are less of a moving target.

Plus, I don't have an Arm-based mac to test on, I can't afford Apple's prices for one, and aside from this 'in my spare time' side-project - I frankly have little use for one. A bit of an extravagance if I'm being honest with myself.

One way to speed development of a Mac arm version may be to use a few sneaky tricks to achieve the same result. Essentially creating a Mac arm build by having a 20MB transition layer. There were three projects that initially existed to do this. One was called Hipflask, one called Thimble, and one called Champollion. They are based on the Whiskey app, you double click it, it runs like a Mac program, but it's actually a Windows one.

I can't find any mention of them anywhere now though. It's as if all traces of them have been removed. I can't remember if it was GitHub or GitLab, but there was definitely projects that took over from the idea of wineskin. I wonder if they received a cease-and-desist order by Apple or something? They might well have used Rosetta2 code that Apple hadn't open-sourced.

I wish I'd downloaded them and backed it all up at the time, but I never bothered in 2021-2022 as I didn't have any interest in an Arm mac and didn't have any arm software I wanted to run. (Still true to this day - all my software I want to run is intel-based).

This will really only become a problem when either: Apple scrap Rosetta 2, or the rest of the computer industry stops making and selling computers with Intel chips.

Edit: Found Champollion (I was spelling it incorrectly)
https://github.com/FFRI/ProjectChampollion
I'm sure this still exists simply because it does not provide a working wrapper in itself, only a way to inspect some of the inner workings of Rosetta2, and extract the executable strings. However, those two other previously mentioned programs did a lot more (or were supposed to - I never tried them or got to see them in action).

It was apparently doing what Wineskin did previously, or even kind of what an appimage does.

The whiskey project still exists, and can do this by creating jars (like a wineskin wrapper), but you can also run this as a headless command line - so that can seemingly transparently run your windows x86 intel program under arm MacOS. I'm then thinking you can run winx86-64 OXT Lite on arm macs.

But there are multiple ways I could tackle the Mac issue in due course I think. I'm a long way off that. At this point, I think the only way to run OXT under ARM would be some form of emulation or transition layer, at least until we are capable of recompiling it. Even then, it's going to take someone very skilled in C++ , xCode and with an Arm mac for extensive testing to do it.

Not knowing how to do it myself, I'll ultimately be looking for some kind of legitimate translation layer for running intel apps under Arm MacOs when I've made my engine available under a modern MacOS (if the above issues are all worked out).

I've asked repeatedly if someone else can take up mac development of OXT lite, but that's a different topic.

[OpenXTalkPaul]

Bravo! When it comes to more xTalk interpreters I say the more the merrier!
I will definitely be following your progress on this, a monumental task for sure!

[OpenXTalkPaul]

I might be able to help with some ObjectiveC stuff for a Mac version.
You could just build a wrapper .app with AppleScript that launches the CLI binary, wrappers are what all the .app bundles really are anyway.

Have you looked at Some source for some other HyperCard clones that are out there?
There's some good articles about creating your own programming language, grammars, building lexical parser, and compilers such.

It does seem like reinventing the wheel though, but reinventing the wheel probably helps to understand a lot of important things about wheels.

There are already written HyperCard grammars available, HyperTalk 2.x syntax is the core of xTalk in my opinion.
https://github.com/antlr/grammars-v4/bl ... /README.md

[tperry2x]

Yes, definitely. I've been looking at the source of all the xTalks I could find. HyperCard, Serf, Livecode, OpenXion.

With the exception of Serf and OpenXion, a lot of the way things are done are very similar.
I can't re-share it (as even I understand that doing so is a big no-no), but back in the day I 'obtained' (was sent) a copy of what was then, the metacard source code for the engine. All I can say is that it's strikingly similar to the engine we have in LCC (which shouldn't really come as much of a surprise to anyone).

There's many neat touches in Serf, and although I'm no expert, I am starting to be able to follow how it's put together and make sense of it. So much so, that it would have been excellent to see this become the base for everything for our project.
It would need extending for other platforms, and updating for modern MacOS.

If I could rewind the clock by about 3 weeks, maybe I'd of started with a message to Dan asking if it was feasible to use Serf and build upon it.

I mean, I'm kind of pleased by what I've accomplished with my version so far (minimal as it is - the whole folder is about 12mb uncompressed), but there's no hooks for something like Applescript in there. No support for Windows or Mac as yet and I don't know much about coding for these OS's. It's more than likely to stay a linux offering for the forseeable future. Not that that's entirely a bad thing, as Linux will pretty much run on anything in one form or another. However, even I accept that I can't dictate anyone's choice of OS to them. Plus, the speed of my progress on the 'clean' tIDE build is glacial.

Whereas Serf had the opposite issue, it's Mac only - no Linux build, or Windows.
(I honestly have more enthusiasm for developing for a "real mac" - macOS 'classic' than any of Apple's current offerings). I wish Apple had open-sourced Classic MacOS, but that's another story [here] and [here], with another semi-related article here.
(I had to read a support article about how you turn a modern iPad off the other day). That says all you need to know about how 'old-skool' I am, and also [perhaps] about how unintuitive Apple products and the state of shared UI's across the industry have become.

Coming back on topic (sorry, attention span error again)...

I sometimes think if you could pool all our efforts into some mega-build (Mega talk?) then It'd easily be the ultimate xTalk environment out there.

megatalk-lol.png (1012.79 KiB) Viewed 300 times

[OpenXTalkPaul]

I sometimes think if you could pool all our efforts into some mega-build (Mega talk?) then It'd easily be the ultimate xTalk environment out there.

Yes, but trying to do so may be a bit like herding cats

Have you considered Uli's StackSmith and its xTalk dialect called Hammer? It's written in C++, generates 'Leonie' bytecode for its virtual machine (engine). Hammer is very much truly FOSS, similar to MIT license it's completely free to use for commercial or open-source, just needs to maintain attribution/licensing note according to Uli's GitHub page. The language has some features a bit more advanced than HC 2.x syntax, it includes Dictionaries (for Key/Value pairs, aka associative arrays). Currently its IDE (StackSmith.app) is macOS only (and getting dated) it uses Cocoa for UI kit and has a few bugs, but the xTalk interpreter/VM is cross-platform and it seems to be designed to be extended.

I think it would wonderful to get that ported to run on Linux with Qt or similar and Windows with...(Aero or whatever Windows UI is called now). Unfortunately, it seems development of it has stagnated, but It may be a good base for us to move to and try to move it forward. Unlike LCCE, it was quite easy to build from the source in that repo when last tried to.

Uli and Dan (and a bunch of other people of course) seem to like to like to hang out on the HyperCard Discord channel. I keep meaning to get back on there but I'm always busy doing other things.

[xAction]

Have you guys considered Lazarus?
It'd be super if Pascal didn't feel like programming in 1970 with the edge of punchcards being dragged across my eyeballs.

But it can be extended through packages so maybe it's possible to make a xTalk for it.

It's so alien.