The basis for an xtalk engine we control

[OpenXTalkPaul]

Speaking of which, added a few more changes:
release notes.pdf

Notably, fixed an error with double-output and added the send in x<duration><measurement> so we can have pendingmessages.

I actually just got some time to look at this, nice!
However, Answer/Ask dialogs aren't working with 097 in latest Safari (18.3), or latest Mac Chrome, they worked with version 096 though.

I also noticed concatenating two strings together results are incorrect.
put "this string" & "that string"
result:
this string" & "that string

Have you seen the "Winkler test", the HyperTalk compatibility test included with OpenXION? It's kind of crazy. HyperTalk was extremely forgiving and/or much more flexible than OXT engine interpreter.

[OpenXTalkPaul]

As a quick test to see if I understand the construction of the interpreter I just added 'the appearance' (or should it be the systemAppearance ? ) which results in either 'dark' or 'light' depending on the browser engines current preferred appearance mode.

Code: Select all

      	// Handle "the appearance"
        if (expr.trim().toLowerCase() === 'the appearance') {
            return this.detectAppearance();
        }
        
        
        // JS function for "the appearance"
            detectAppearance() {
          const darkkMode = window.matchMedia && window.matchMedia('(prefers-color-scheme: dark)').matches;;
          if (darkkMode) { return 'dark'; }
          else { return 'light';}
    }

I added that to v 096 which has a different directory layout, because v.097 seems to be broken.

[tperry2x]

I might have given you my experimental version of v97 - Sorry.
I can confirm that's working as intended in 98 onwards. I aim to test this on different browsers today at some point.

2025-03-12-06-12-55.png (16.27 KiB) Viewed 16065 times

2025-03-12-06-13-19.png (13.88 KiB) Viewed 16065 times

Thank you for the dark mode / light mode detection. I'll add that in, and include it in "testing2.html" as well.

edit:
line 129 of interpreter.js

Code: Select all

detectAppearance() {
    // Check if the browser supports the prefers-color-scheme media query
    if (window.matchMedia && window.matchMedia('(prefers-color-scheme: dark)').matches) {
        return 'dark';
    } else {
        return 'light';
    }
}

Then I added the appearance handler at line 1360

Code: Select all

// Handle "the appearance"
if (expr.trim().toLowerCase() === 'the appearance') {
    return this.detectAppearance();
}

Then I added the test for it in test-suite-2.js at line 192

Code: Select all

// Test appearance function
        await this.runTest("Appearance function test", [
            'put the appearance into tResult',
            'put tResult'
        ], "Testing the appearance function to detect dark/light mode");

Much appreciated:

appearance.png (3.11 KiB) Viewed 16033 times

so, did a bit of testing. I thought (just for a laugh), I'd test this on an old version of MacOS (10.9 Mavericks).

testing_Mac OS Mavericks.png (355.98 KiB) Viewed 15979 times

Ended up running it in Waterfox, which is based on Firefox, but with older OS-compatible APIs. Safari chokes on the CSS styling, before I even get to the script, and then refuses to run anything as it can't understand the javascript classes. Ho-hum, I did think that might be the case.

In fact, I could probably start a related-rant on the state of Safari on earlier versions of MacOS now. Just shows how much the web (and related technologies) has moved on. Can't even get to download waterfox on MacOS 10.11 El-Capitan, before Safari crashes.

Safari-El Capitan 10.11.png (140.52 KiB) Viewed 15961 times

Working fine in Safari on MacOS 12 though:

safari-macos12.png (248.69 KiB) Viewed 15915 times

[tperry2x]

Have you seen the "Winkler test", the HyperTalk compatibility test included with OpenXION? It's kind of crazy. HyperTalk was extremely forgiving and/or much more flexible than OXT engine interpreter.

You mean the one mentioned here?

Code: Select all

put empty into a
put "a b c" into item
put 1 into char
put 2 into word
if true then repeat with word char of item = char char to word of word char of char to word char to char of char char of word
        put a&&"HyperTalk is a bitch to parse
end repeat else beep

As noted on that forum, if an interpreter actually parsed that - then I think I'd throw the interpreter in the bin and start afresh. The script is so inaccurate and just plain wrong (using reserved words etc).
Even LCC/OXT won't parse it:

winkler.png (65.93 KiB) Viewed 15874 times

(and rightly so, in my opinion).

What does stand half-a-chance of working is:

Code: Select all

put "" into a
put a & " b c" into titem
put 0 into tCount
put the number of words of titem into tRpt
repeat tRpt
   add 1 to tCount
   put tCount & " HyperTalk is a bitch to parse, but it helps when the script is half-right!"
end repeat

winkler-test logical.oxtstack

(1.37 KiB) Downloaded 28 times

parsed-correct.png (43.08 KiB) Viewed 15872 times

Now, you could say I'm missing the point here: the script is supposed to be full of inaccuracies (as a way of kind of stress-testing an interpreter), but then it makes no sense to type incorrect script. With the live error checking that the LCC script editor introduced, there's a clearly defined order in which the interpreter works through things - (I can't make sense of the original "Winkler test" script as it doesn't read correctly to me: it breaks the interpreter in my head too!)

Anyway, on with testing.
Working fine in Edge on Windows 11 too:

win11-edge-test.png (95.87 KiB) Viewed 15815 times

Here we are in Chrome (MacOS), doing string combination and answer dialogs. All seems to be working.

Chrome-MacOS-Answer-and-strings.png (225.55 KiB) Viewed 15785 times

[OpenXTalkPaul]

Yeah, I've tried HyperCard Sim, Decker, and others in old versions of macOS with various browsers like iceWeasle, InterWeb, etc. that have tried to back-port some of more modern-web engine features to older OSes and unfortunately I had similar results. A lot of web-tech has changed for the better (IMO) in the pat 15 years or so with HTML5 APIs becoming standard. I don't want to say it wasn't possible to implement an xT interpreter with 2010 web standards, but it certainly would've been more difficult and not as capable.

Some things, like for example WebAudio API, weren't supported or weren't fully supported by a plurality of browsers engines at the time. Apple in particular does seem to take a very long time to fully support newer web APIs as they become standards by default in WebKit, but you can somtimes enable such things like WebGL support from WebKit's developer menu (labeled something like "enable experimental support for"...). There's also WebKit developer preview release builds that can have all the bleeding edge things they're working on. I remember some people in the community used the source to extend the life of Safari on Snow Leopard after Apple dropped official support for 10.6.x WebKit which Safari was built on is open-source https://www.webkit.org. it was derived from KDE's KHTML browser engine (https://en.wikipedia.org/wiki/Konqueror).

[OpenXTalkPaul]

Yeah that's the one. I do beleive that Winkler Test was meant to be confusing and a stress test for the interpreter for compaibility with HyperTalk's interpreter. But I think it also illustrates just how forgiving, perhaps overly forgiving, that the HyperTalk interpreter really was.
I do remember occasionally being completely baffled by simple typo mistake I'd make in a scripts as a result of HyperCard NOT flagging such things as using syntax keywords as variable names. However that lack of reserving keywords is the same mechanism that enables a scripter to create their own implementation of some built-in engine functionality, intercepting and overriding built in implementation. I would have stacks that had custom 'play' commands. So I have a certain fondness for that FEATURE.

Even in LC/OXT I always turned OFF 'strict compilation mode' which makes script interpreter slightly more forgiving.

In my opinion this should work, and it does in OXT, HC Sim

Code: Select all

Answer Hello -- No Quotes

If the parameter is a single word ("Hello"), it doesn't need to be quoted, if a variable named Hello does not exist then interpreter should treat the word as if it were a string literal, any other words following it should be assumed to be additional parameters if any are accepted. Answer Hello World -- would still throw an error for 'World' because it doesn't fit expected type for the second parameter of an 'Answer' command (unless World is the name of a variable in memory)

Answer Hello
or
Put Hello
Don not work with 'WebTalk' currently, you have to use quotes even for a single word.

I do understand the argument for not allowing that level of flexibility though. In fact that Winkler Test illustrates the argument against that very well.

[richmond62]

Henry Winkler?

[tperry2x]

Hmm, these do work - which is confusing, but depends on what version you are using.

hello-singular.png (15.56 KiB) Viewed 15656 times

put-singular.png (11.59 KiB) Viewed 15656 times

[tperry2x]

Henry Winkler?

Haha, Hypercard senior engineer Dan Winkler

[OpenXTalkPaul]

Hmm, these do work - which is confusing, but depends on what version you are using.
hello-singular.png
put-singular.png

I think I was trying an earlier version when I got the idea that they didn't. I'm playing around with v100 tonight.

Here's a very very basic 'speak' command:

Code: Select all

            // Handle Speak command
            if (script.startsWith('speak ')) {
                const expr = script.substring(5);
		const voices = speechSynthesis.getVoices();                
		var msg = new SpeechSynthesisUtterance();
                msg.text = this.evaluateExpression(expr);
		msg.voice = voices[1];
		window.speechSynthesis.speak(msg);
                return '';
            }

I tested on macOS Safari: speak "Hello World"
and it spoke.

It needs several things to make it better. At minimum it should have corresponding 'the speechVoices' which would return a list of the available Text-to-Speech voices, which would be different depending on the platform or browser and there may also be none available. I'd want it to support same syntax as Hypertalk (and revSpeech without the 'rev') which may or may not be fully possible. Some error checking would be good too.

The JS line:
const voices = speechSynthesis.getVoices();
should retrieve a list array of available voices.

I set the msg.voice = voices[1]; so that it would use the first voice it finds
what I think we want is either:
setSpeechVoice voiceName -- as a command, derived from revSpeak's revSetSpeechVoice command
or as a global property:
set the speechVoice to voiceName

[micmac]

What are the chance for graphics tools in that you are working on?

Mic

[tperry2x]

...It needs several things to make it better...

Well, yes - but up until this point, it's only been myself with a text editor (and about 4 months).

.At minimum it should have corresponding 'the speechVoices' which would return a list of the available Text-to-Speech voices, which would be different depending on the platform or browser and there may also be none available. I'd want it to support same syntax as Hypertalk (and revSpeech without the 'rev') which may or may not be fully possible. Some error checking would be good too.

It would be good, but my entire point of doing this in a browser was to provide true cross platform features, with functions that are on a parity across Linux, Windows and MacOS. I'm cautious (actually, I'm against) adding a Mac-Only feature which has no comparable equivalent on Windows or Linux.

Don't get me wrong - I'm not being dismissive of anything you suggest. I too think it should have a good speech function, it's just a shame that speech on Linux and Windows sounds like cr4p compared to MacOS. Ideally, I'd like them all to be high quality and up to the same standard if we are going to implement that. That's all I mean.

What are the chance for graphics tools in that you are working on?

I'm also a way off that. I am rapidly getting to the point where all the functions I want to add are to do with setting properties of objects, and of course for that you need to support objects in the first place. We have a 'card', (the white area) where things can be placed, but in the same way as I mention above, I want this to be platform-agnostic (uniform in approach) across all platforms - which of course would include the likes of Haiku now.

This is also why I've gone to great lengths to keep this a purely javascript and CSS implementation. Not using anything exotic or anything the user may have to install as optional addons. Also, because those addons (and the quality of them) vary drastically between different operating systems. I don't want to use some mac-specific library or windows dll webex extension, or some linux 'library so' file - for exactly that reason.

Yes, this makes it harder, but the end result (I hope) is clean code. That's also my second objective for doing this. Not to stuff it up with comments and things which are half-implemented, broken, or now redundant. As can be seen in our community engine source and also throughout the IDE.

[tperry2x]

Continuing with this, I now have the beginnings of a script editor and implemented button objects.

So, for example I can now run:

Code: Select all

create button "test"
edit script of button "test"

This will make a new button in the card, and it'll invoke the script editor.
You can also do this by right-clicking on a button object:

invoke-script-editor.png (21.43 KiB) Viewed 14707 times

It'll bring up the script editor (in which I'm also trying to support script colourisation/colorization) - which can be edited easily in a css file incidentally.

editing-script.png (25.18 KiB) Viewed 14707 times

Then, when I run the button script:

run-result.png (9.97 KiB) Viewed 14707 times

Seems to be working well.
I'm trying to implement some kind of autocomplete too, but I now have a headache, so this is all for now!

[OpenXTalkPaul]

...It needs several things to make it better...

Well, yes - but up until this point, it's only been myself with a text editor (and about 4 months).

Oh I don't mean to rush you into working on it. I was just sort of thinking out-loud about what other syntax would be needed to support speech. While you may have been the only one working on this interpreter, I have worked on using JS to implement missing things with the OXT Emscripten engine and HyperCard Simulator's SimScript. So I have some functionality already worked out to some degree, I just need to rearrange some lines so it fits with your code.

.At minimum it should have corresponding 'the speechVoices' which would return a list of the available Text-to-Speech voices, which would be different depending on the platform or browser and there may also be none available. I'd want it to support same syntax as Hypertalk (and revSpeech without the 'rev') which may or may not be fully possible. Some error checking would be good too.

It would be good, but my entire point of doing this in a browser was to provide true cross platform features, with functions that are on a parity across Linux, Windows and MacOS. I'm cautious (actually, I'm against) adding a Mac-Only feature which has no comparable equivalent on Windows or Linux.

Don't get me wrong - I'm not being dismissive of anything you suggest. I too think it should have a good speech function, it's just a shame that speech on Linux and Windows sounds like cr4p compared to MacOS. Ideally, I'd like them all to be high quality and up to the same standard if we are going to implement that. That's all I mean.

WebSpeech API ( https://developer.mozilla.org/en-US/doc ... Speech_API ) is not exclusive to macOS. Any modern browser that supports WebSpeech API should ensure there is a voice to use or provide some sort of fall back or report error if there isn't. We can't do much about poor text-to-speech quality on all browsers engines / platforms. Another option I'm a fan of would be to provide an alternative or fall-back method(s) in the implementation. One example could be that if there is an internet connection there are 'cloud' REST TTS APIs that could be used (https://cloud.google.com/text-to-speech/docs/apis https://learn.microsoft.com/en-us/azure ... =streaming .https://luvvoice.com

[OpenXTalkPaul]

Here's another quick add

Code: Select all

	 // "the backdrop" getter
        if (expr.trim().toLowerCase() === 'the backdrop') {
            return document.body.style.background;
        }
  
        // "set the backdrop" setter
        if (property === 'backdrop') {
            document.body.style.background = this.getTextValue(value);
            return;
        }

In a web engine context I've use the web page [body] as the 'backDrop', which corresponds to the result of 'the screen' in OXT Emscripten.

pass standard web CSS color names or RGB Hex works right away.

Code: Select all

set the backDrop to darkgreen
set the backDrop to #070770
put the backdrop

Screenshot 2025-03-13 at 8.33.01 PM.png (73.2 KiB) Viewed 13568 times

Using xTalk-style names or RGB-CSV/Decimal values doesn't work, but that should't be very hard to implement. Using a image as a pattern-fill for 'backDrop' doesn't work either, and I don't think that's worth worrying about that at the moment.

I'm going to try to add 'Answer Color' form of 'Answer' when I get a few spare minutes.

[tperry2x]

Thanks for the backdrop suggestion. That's great - I'll make sure I've got that included too.

Having been experimenting more with my button script, I noticed the mouseup message wasn't being handled properly. Neither did buttons know about other things (mousedown, mouseenter, mouseleave, mousewithin) so I've just added those:

Code: Select all

on mouseDown
  put "Mouse button pressed down"
end mouseDown

Code: Select all

on mouseUp
  put "Mouse button released"
end mouseUp

Code: Select all

on mouseEnter
  put "Mouse entered the button"
end mouseEnter

Code: Select all

on mouseLeave
  put "Mouse left the button"
end mouseLeave

Code: Select all

on mouseWithin
  put "Mouse is within the button"
end mouseWithin

These would now put the corresponding messages in the "message box" as you'd expect.

mouse-events.png (78.96 KiB) Viewed 12924 times

[tperry2x]

I just took your code (thanks again), and added the backdrop property.
I also tweaked it slightly.
Now the interpreter also looks at "col-references.css".
You can now get the backdrop colour and store this in a variable:

Code: Select all

put the backdrop into tOriginalBackdrop

You can also set the backdrop in a variety of ways:

Code: Select all

set the backdrop to darkGreen
set the backdrop to #FF5500
set the backdrop to 200,100,50
set the backdrop to tOriginalBackdrop

backdrop.png (125.92 KiB) Viewed 12753 times

[Kdjanz]

Random interjection...

It's really nice to see both of the gurus working on a single project and pulling in the same direction. I can't help with any of what you are doing, but I really, really, really like the idea of making the browser the only platform and abandoning all this native stuff that was always pulling OXT in three directions at once. It has taken so much energy and wasted so much time to date. Everyone out there has a browser, so if you can make a new engine that works in Chrome, Safari and Firefox, then everyone can have access to OXT without caring what hardware they are running it on.

I know that recreating the engine is a mountainous task, but the upside is that it is all now in your control. You are not beholden to old code from someone or somewhere else, and you can improvise and improve on the fly. You also only have yourself to blame if things aren't working

I hope the new direction is decided upon and things can move ahead as you both find inspiration. OXT Lite gives us everything we had from 9.6.3, so the legacy is still there and still working. But the future is in a new direction and we can walk away from the legacy dung hill that drove that caused so much despair ! !

At least I hope this is what I am seeing and reading and that this is not just another rabbit hole and fun project that isn't going to end up going any where.

Speed on - more power to you!

[OpenXTalkPaul]

I really, really, really like the idea of making the browser the only platform and abandoning all this native stuff that was always pulling OXT in three directions at once. It has taken so much energy and wasted so much time to date. Everyone out there has a browser, so if you can make a new engine that works in Chrome, Safari and Firefox, then everyone can have access to OXT without caring what hardware they are running it on.

I'm not planning on abandoning 'native stuff' at all, I would say that I think it's a good move prioritizing the common capabilities that pretty much every platform has available in the form of modern browser engines. Particularly since about 2015 or so when browsers had standardized on new JS and by then most had support for HTML5 APIs like fileReader, webSpeech, webAudio, etc. Browser Engine's now support many of the things we would've needed an extension or external add on to do using native APIs, like for example 'revSpeech' which is an external that uses 'native' speech APIs (but only supports older Mac & Widows speech APIs).

We can wrap these modern Web APIs in xTalk-style syntax and have a pretty functional 'Engine' available most anywhere there's a web browser and optionally an internet connection.

But there's still 'Native' private APIs from vendors like Apple that I would still want to use (like CoreAudio, CoreMIDI, CoreImage, etc.). That's why I'm interested in webtech-as-desktop-app wrappers like Electron. Running this inside of Electron you would have DIFFERENT APIs available in its browser engine that could then be supported by the xTalk interpreter. For example, in a normal web browser you would probably use standard fileReader API to read in an entire file, which purposefully requires the end user to intitiate the file read access and browser asks for the privilege to do so before it does, but with Electron apps you would use it's fs API which could read parts of the file directly from the 'native' filesystem without the same sort of sandbox restrictions a web browser would normally impose. Running it as an Electron app you could access many of those 'Native' APIs JS wrappers and other community libraries available in the Node.JS ecosystem (there's A LOT!!!).


Speaking of WebSpeech API. I implemented the speechVoices property to (eventually) go along with that speak command:

Code: Select all

        // Handle "the speechvoices"
        if (expr.trim().toLowerCase() === 'the speechvoices') {
	    const voices = speechSynthesis.getVoices();                
	    const voccount = voices.length;
	    let vocList = '';            
        
	    for (var i = 0; i < voccount; i++) {
		vocList += ( voices[i].name + "\r\n" ) ;
		}
            return vocList;
        }

Screenshot 2025-03-14 at 8.46.32 PM.png (56.8 KiB) Viewed 11218 times

[OpenXTalkPaul]

For colorsNames it would be easy to abandon the ones used in OXT, which might be based on 'the colorNames' in SuperCard (not sure). AFAIK the OXT colorNames are NOT based on CSS1 or CSS2, although some color names may be identical to CSS, some of the names do not exist in CSS or have slightly different names.