The basis for a C++ xtalk engine we control

A place to discuss any and all xTalk implementations, not just LC LCC Forks, but HyperCard, SuperCard, MetaCard, Gain Momentum, Oracle MediaTalk, OpenXION, etc.
Forum rules
Please limit any bashing/harping on any commercial interests to a minimum, thanks!
Post Reply
User avatar
tperry2x
Posts: 2523
Joined: Tue Dec 21, 2021 9:10 pm
Location: Somewhere in deepest darkest Norfolk, England
Contact:

The basis for a C++ xtalk engine we control

Post by tperry2x »

The title says it all really.
"The basis for a C++ xtalk engine we control".

The general gist being, you can type "get the time", which is of course xTalk script, and it'll return the current time.
output.png
output.png (18.5 KiB) Viewed 4355 times
So, who wants to add all the function types, definitions, handlers, commands, subroutines, and GUI on top of it?
-- okay, nobody will be rushing all at once to do that, but this merely shows how that kind of thing could be done.

Edit: I'll move the functions such as "getCurrentTime()" out of "main.cpp" into something like "functions.cpp" for easier editing.

Code: Select all

// Function to get the current time as a string
std::string getCurrentTime() {
    std::time_t currentTime = std::time(nullptr);
    char timeStr[9]; // buffer to hold formatted time
    std::strftime(timeStr, sizeof(timeStr), "%H:%M:%S", std::localtime(&currentTime));
    return std::string(timeStr);
}
Attachments
xtalk_program_in_c_plusplus.7z
(32.28 KiB) Downloaded 59 times
User avatar
OpenXTalkPaul
Posts: 2282
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: The basis for a C++ xtalk engine we control

Post by OpenXTalkPaul »

tperry2x wrote: Fri Oct 11, 2024 12:59 pm The title says it all really.
"The basis for a C++ xtalk engine we control".

The general gist being, you can type "get the time", which is of course xTalk script, and it'll return the current time.
output.png

So, who wants to add all the function types, definitions, handlers, commands, subroutines, and GUI on top of it?
-- okay, nobody will be rushing all at once to do that, but this merely shows how that kind of thing could be done.

Edit: I'll move the functions such as "getCurrentTime()" out of "main.cpp" into something like "functions.cpp" for easier editing.
Awesome, I'll definitely check it out when I get a minute. It would be great to have base xTalk language as a framework all set up and in a way the make it easy expand on.
One thing, shouldn't it be 'put the time' since we are putting the value to a console STDOUT? If we 'get the time' that value should go into a global 'it' or 'the result' variable.

There is also StackSmith's xTalk script interpreter component, also written in C++, which interprets the xTalk dialect called 'Hammer script". The interpreter part can be GUI-less on the command line. I believe Uli gave it a liberal license (like MIT). It's designed to allow a community to expanded on it. 'Stacksmith' uses Apple's Cocoa UI elements on macOS, but my thinking was that it could be modified to use GTK, Qt, etc. UI kits.

That's also basically what I wanted to work on doing, but for the HyperCard simulator's 'engine'. Its syntax is super easy to expand on via a user 'SimScript' section (that's editable in Browser), and that javascript built 'Engine' is relatively very small compared to our 28mb 'Emsricipten' compiled JS engine version.

I think if starting a brand new xTalk script interpreter shell from scratch, it might be better use Rust ( or 'Go' lang?) instead of C++ to write it, for the 'memory safe' quality,
User avatar
tperry2x
Posts: 2523
Joined: Tue Dec 21, 2021 9:10 pm
Location: Somewhere in deepest darkest Norfolk, England
Contact:

Re: The basis for a C++ xtalk engine we control

Post by tperry2x »

Yes, you are right - this should be put instead of get of course, but it's in the super early stages. i just wanted to check that it would work as a lexer-parser and execution test.

I get what you mean, using rust would be better and does have lots of benefits such as memory safe interpretation. I just don't know much about rust. I'm still learning c++ slowly after all, but it's coming along.

Ideally, for speed, I read that it should really be in assembly - if I really want to give myself a headache.

I did have a look at stacksmith, and it would be excellent if we could use it as a basis for a new oxt engine. However, because it seems very focussed on mac-only, I don't know how cross platform it would turn out to be. I'd of course be happy to use that, as I'm not even sure if I can accomplish making a full-on interpreter afresh yet!

With the cocoa-bindings of stacksmith - it'd be a lot of work to reimplement that for windows and linux.

That's my thinking of using c++. I'm able to use the gcc compiler on Windows and MacOS, and as long as I ensure I keep my functions cross-platform compatible, then that's really what I'm trying to achieve. Something that runs on all 3 (linux, windows and macos).

My first go at doing this would have been Linux only, and while I got further with that, I really need it to be editable without extensive c++ knowledge, so you can edit the language definitions as text files.
User avatar
richmond62
Posts: 3936
Joined: Sun Sep 12, 2021 11:03 am
Location: Bulgaria
Contact:

Re: The basis for a C++ xtalk engine we control

Post by richmond62 »

What do you mean by 'all 3'?

We can draw a 3 by 3 matrix with

Windows, Linux, and Macintosh along the top

and

ARM, Intel 32, and Intel 64 down the side.

And, of course that is also an over-simplification. 8-)
https://richmondmathewson.owlstown.net/
User avatar
tperry2x
Posts: 2523
Joined: Tue Dec 21, 2021 9:10 pm
Location: Somewhere in deepest darkest Norfolk, England
Contact:

Re: The basis for a C++ xtalk engine we control

Post by tperry2x »

richmond62 wrote: Sat Oct 12, 2024 6:11 am And, of course that is also an over-simplification. 8-)
platforms.png
platforms.png (43.39 KiB) Viewed 4257 times
User avatar
tperry2x
Posts: 2523
Joined: Tue Dec 21, 2021 9:10 pm
Location: Somewhere in deepest darkest Norfolk, England
Contact:

Re: The basis for a C++ xtalk engine we control

Post by tperry2x »

Now handles 'get' and 'put' correctly. Also added the date function as it's been raining all day.
screenshot.png
screenshot.png (32.16 KiB) Viewed 4238 times
User avatar
OpenXTalkPaul
Posts: 2282
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: The basis for a C++ xtalk engine we control

Post by OpenXTalkPaul »

That would be the goal of working to switch an alternative engine over to use one (or more) of several widely used cross-platform UI toolkits. GTK4? Qt5/6? I believe all of them can create controls with standard native system appearance on the major OSes, They're toolkits that were designed from their start to be cross-platform. And they're quite popular, I think they'll be sticking around for quite a long time, so I think it would be worth the effort.

Technically Objective C IS, at least to some degree, cross-platform in the form of GNUStep APIs. I wouldn't say that it's widely used, but it does still get updates in its GitHub repo. GNUStep uses themes for 'native look' appearances GTK,WinUI and Mac-look appearance themes available. However it is much more than a UI toolkit, it includes a whole Object-oriented framework (Objective C), and application construction architecture (AppKit) that would already be familiar to anyone who has ever built an app for NeXT/OpenStep/Apple's Cocoa.

Most off what I know of C++ comes from reading through StackOverflow comments and trying to wrap C++ libraries. Reading up on ANSI-C decades ago has maybe helped a little.

In general though, anything Object oriented, where you create and manipulate things in memory, and the things can have attributes that can be set and queried for their attributes (has Properties with 'setters' and 'getter'), that can answer questions and follow intructions to do stuff (has functions and commands, aka 'methods'), the paradigm or programming pattern, just makes a lot of sense in my mind.
User avatar
OpenXTalkPaul
Posts: 2282
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: The basis for a C++ xtalk engine we control

Post by OpenXTalkPaul »

There's a difference between 'platform' and CPU architecture. In theory if you stick to writing to OS APIs, those would likely be ported to new architectures by the OS provider, Apple, Microsoft, Canonical, etc. and would require nothing more than recompiling tp keep such an app current. Of course we know in reality it's often much less seamless, with various things being declared dead (deprecated) or implementations change so much that they require some edits to source.
User avatar
neville
Posts: 46
Joined: Wed Jul 31, 2024 1:03 am
Location: Canberra, Australia
Contact:

Re: The basis for a C++ xtalk engine we control

Post by neville »

nobody will be rushing all at once to do that,
But possibly an AI, properly trained, could rush in and do it all at once

However isn’t the engine a lot more than just a collection of objects and functions? There’s message handling, event handling, error handling, screen buffering ,caching, object and script hashing strategies, object serialisation, fonts which LC still hasn’t got right, Unicode, ++, for some of which performance tweaking is going to be os dependent rather than one size fits all. The initial conversion of everything to Unicode in LC version 8 caused a big hit in performance, it took a few versions to bring it back up to speed. Behaviors. And arrays….MW’s implementation seems to be utter magic in efficiency - maybe it is a straightforward port of C++ arrays but I suspect not.

It’s a great idea to build everything from scratch but It does seem a pretty big mountain to climb and have to wonder if it is time well spent.
User avatar
richmond62
Posts: 3936
Joined: Sun Sep 12, 2021 11:03 am
Location: Bulgaria
Contact:

Re: The basis for a C++ xtalk engine we control

Post by richmond62 »

fonts still not right . . .

in what way? can you explain, please?
https://richmondmathewson.owlstown.net/
User avatar
neville
Posts: 46
Joined: Wed Jul 31, 2024 1:03 am
Location: Canberra, Australia
Contact:

Re: The basis for a C++ xtalk engine we control

Post by neville »

fonts still not right . . .
This has been gone into in a previous post ... and Paul replied with some ideas for rewriting the font manager

Bugs in the font manager go back many years. LC does not handle styled fonts (such as Foobar Ultra Light Italic) well-- the styles command produces useless information, and on Mac incorrect information; on Windows it is impossible to use the majority of all the thousands of existing fonts because "the Fontnames" only lists the family Foobar of the font, not the full name; the ascent and descent metrics returned by LC for the Mac are not quite accurate so you cannot compute the baseline of field text; start/stop using fonts has a major bug, and does not work at all on Linux. That's the ones I recall offhand.
User avatar
richmond62
Posts: 3936
Joined: Sun Sep 12, 2021 11:03 am
Location: Bulgaria
Contact:

Re: The basis for a C++ xtalk engine we control

Post by richmond62 »

Thsnk you: the odd thing is that most of my work relies on specific fonts, but on a eay that has never 'rubbed up against' all the very many problems you mention.
https://richmondmathewson.owlstown.net/
User avatar
neville
Posts: 46
Joined: Wed Jul 31, 2024 1:03 am
Location: Canberra, Australia
Contact:

Re: The basis for a C++ xtalk engine we control

Post by neville »

fair enough ... most users wouldn't see these problems as long as they stay away from styled fonts, or need to access many fonts in a temporary fashion, or need accurate metrics for fine calibration of layouts.
User avatar
tperry2x
Posts: 2523
Joined: Tue Dec 21, 2021 9:10 pm
Location: Somewhere in deepest darkest Norfolk, England
Contact:

Re: The basis for a C++ xtalk engine we control

Post by tperry2x »

neville wrote: Fri Oct 25, 2024 12:56 pm However isn’t the engine a lot more than just a collection of objects and functions? There’s message handling, event handling, error handling, screen buffering ,caching, object and script hashing strategies, object serialisation, fonts...

It’s a great idea to build everything from scratch but It does seem a pretty big mountain to climb and have to wonder if it is time well spent.
You aren't wrong. It is an absolute mountain to climb. Whether it's a good use of time, well - that's the question.
It keeps me out of trouble, and I don't know if I'd be doing anything productive with the LCC engine at the moment.

But if nothing else, I'm finding it an interesting process.
Here's a first bit of GUI, using the cross-platform GTK-3 library, rather than relying on a terminal command. So fields already look native, because they are native. No faking of the GUI involved.
At the moment, it's a single-line message box.

I'm only contemplating starting from scratch because the IDE / Engine seems to have totally tripped over itself. Rather than trying to fix it, I think that's going to be a bigger task than trying to rewrite it ultimately. Whether there's any call for all this is debatable, given the pace that AI is moving along. Human coders may be a thing of the past soon.
screenshot.png
screenshot.png (276.42 KiB) Viewed 346 times
Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest