The basis for an xtalk engine we control

[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 (18.5 KiB) Viewed 5699 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);
}

[OpenXTalkPaul]

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,

[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.

[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.

[tperry2x]

And, of course that is also an over-simplification.

platforms.png (43.39 KiB) Viewed 5601 times

[tperry2x]

Now handles 'get' and 'put' correctly. Also added the date function as it's been raining all day.

screenshot.png (32.16 KiB) Viewed 5582 times

[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.

[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.

[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.

[richmond62]

fonts still not right . . .

in what way? can you explain, please?

[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.

[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.

[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.

[tperry2x]

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.

Edit: As far as the engine on MacOS is concerned:
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 (276.42 KiB) Viewed 1690 times

[tperry2x]

Strictly a bit off-topic for this post, but I may decide to move this to a Javascript and HTML implementation instead of a C++ binary.
At the moment I have both, but won't develop both. At the moment I'm favouring the javascript and HTML approach as it's faster to make changes and see them in realtime without the need to recompile.
Plus - no internet required. This isn't using something that requires Python, NODEJS or any extra plugins.
(note how I'm loading this from my desktop).

Just checking that variables can indeed be 'stateless':

now-web-js.png (18.66 KiB) Viewed 546 times

Why try to do this and reinvent the wheel? Because I don't want anyone claiming ownership of it one day.

[tperry2x]

Syntax colouring eludes me at the moment in a browser. Applying this live to the input and output field is extra complexity I've not yet considered. This is the start of a browser based interpretation - but I also have this: where the C++ desktop version for a command-line interpreter (with a minimal GUI) is a lot further forward.

I'm just coming up with ideas. Perhaps one day, both will become methods of someone starting their own IDE if they want. I'm trying to provide two alternative directions - a browser interpreter and a desktop C++ interpreter.

I'm leaning more and more towards starting the ENTIRE IDE from scratch (I don't mean the 'scratch' language - don't panic Richmond ), - there's just too many things I'm inheriting, and I think I'm at the point where although recreating everything is an absolutely huge task - starting afresh with an entirely new IDE may be a way forward. At least I don't inherit windowing errors, and I don't have decades of piled-on IDE fixes (some of which really aren't needed).

But, this is a 5+ year project for me I think, to even get near to something resembling an IDE that could be deemed as useable as metacard. However, we wouldn't owe anyone for this work. It would be solely ours with no ties to LC.