The basis for an xtalk engine we control

[tperry2x]

I've been doing some more work on this, and as I show in these screenshots, I now have a headache. But it's coming along nicely.

answer dialog.png (22.92 KiB) Viewed 25492 times

ask-dialog.png (32.87 KiB) Viewed 25492 times

Does not need a degree in advanced computing to start using it. You would just open the index in a browser.

this.png (60.64 KiB) Viewed 25490 times

[tperry2x]

Probably the most boring 5 minutes, 35 seconds of your life... but at about 4:52 in the video, that might interest Paul
Demo video of the HTML interpreter test.

I will add though, that I don't owe anyone anything for any of this work I've done on my browser interpreter. Running it fully in offline mode. It doesn't use anyone's existing library, and no parts of some github project either.

Keeping with my methodology that software should not be sneaky: should not gather data about a user or their computer without asking, and should not 'phone home': this also strictly sticks to those principles.

I'm allowed to assign any type of license to it I see fit: it's all my own work. I'm still adding all elements of the hypertalk language to the interpreter. Tested on MacOS, Windows and Linux - both locally and via an online instance. All good so far, (if anyone is even slightly interested).

I've been adding some more syntax to my browser engine.

interpreter-testing.pdf

(73.31 KiB) Downloaded 84 times

Release notes so far:

release notes.pdf

(249.18 KiB) Downloaded 97 times

Only seems to be me bothered about it, so I'll just continue with it for my own amusement.

[OpenXTalkPaul]

I've been doing some more work on this, and as I show in these screenshots, I now have a headache. But it's coming along nicely.
answer dialog.png
ask-dialog.png

Does not need a degree in advanced computing to start using it. You would just open the index in a browser.
this.png

Nice! I'll be checking this out as soon as I get a minute.

[dandandandan]

Is the source posted on GitHub? Maybe I can give you a hand.

[richmond62]

No: That's NOT Bob Geldoff: it's probably someone who did some SERFing in the past.

Personally one of my heroes (probably why he avoids me like the plague), and definitely, 100%, a person you want to accept offers like that from.

[tperry2x]

I now at least know that my javascript hypertalk (xtalk) interpreter isn't a lost cause. It has legs, as they say.
So I've been expanding it further:

ask-password-test.png (40.17 KiB) Viewed 25134 times

ask-list.png (12.31 KiB) Viewed 25134 times

The xTalk script to generate that user password dialog is as simple as:

Code: Select all

ask password "Complete registration:" with "username,email,password,confirm password"
put it

The other one as a list, easier still:
added the "ask list" option:

Code: Select all

put "item 1" & return & "item 2" & return & "item 3" into treturndelimitedList
ask list "Please pick an item:" with treturndelimitedList
put it

Oh, and don't worry - you won't have to register to use this. My aim is it will be free, as I previously stated. I'll work out the legalese BS at some point license wise, but it's early days.

(16 views in the space of 7 minutes... that's good for a bot or an 'entity' isn't it)

Anyway, adding a few more bits to what it can do:

release notes.pdf

(60.11 KiB) Downloaded 79 times

[OpenXTalkPaul]

Ask List ... awesome! I've been missing that a few times lately, XFCNs that did that sort of List Dialog Box that is (I think Frederic Rinaldi had one called listSelect, or probably fullListSelect). Oracle Media Objects (aka 'Plus') had something like that built-in to its engine with syntax like 'pick <list>'.

I was looking at some info on interpreters tonight, probably you have seem some of the same infos, but FYI good info / eBook here: https://craftinginterpreters.com/contents.html
Also looking at this here Smalltalk to JS transpiler written in typescript that skips the AST (Abstract Syntax Tree) bits of the process: https://github.com/Small-JS/SmallJS
Smalltalk lang has very few reserved words so it's not all that much to look through.

[tperry2x]

Have added a few more things (version .93 onwards).

release notes.pdf

(287.22 KiB) Downloaded 54 times

Testing page 1.pdf

(160.6 KiB) Downloaded 59 times

Testing page 2.pdf

(21.33 KiB) Downloaded 54 times

Version 93
added the beginnings of GUI objects.
I'm starting with a simple button.
You can now use:

Code: Select all

create button "test" -- creates a button named "test" in the middle of the card area
delete button "test" -- deletes a button named "test" if it exists

Version 94
added the howmany function, as in:

Code: Select all

put "a" into tSearch
put "A string containing a few a characters." into tString
put howmany(tSearch,tString)

output:

Code: Select all

5

(because it's case sensitive)

Version 95
The testing page now reports the result of each test properly underneath each test.

Version 96
added handler support (on and end):

Code: Select all

on handler1
   put "handler1 called"
   handler2
end handler1

on handler2
   put "handler2 called"
end handler2

handler1

outputs:

Code: Select all

handler1 called
handler2 called

however, there’s an exception to this:

Code: Select all

repeat -- we don't need an 'on repeat' here.
   put "do something"
   exit repeat
end repeat

repeat statements don’t need an "on repeat" to begin, so we ignore the need for an on repeat.

[tperry2x]

I was looking at some info on interpreters tonight, probably you have seem some of the same infos, but FYI good info / eBook here: https://craftinginterpreters.com/contents.html
Also looking at this here Smalltalk to JS transpiler written in typescript that skips the AST (Abstract Syntax Tree) bits of the process: https://github.com/Small-JS/SmallJS
Smalltalk lang has very few reserved words so it's not all that much to look through.

That is helpful, and has a few handy snippets I can take for inspiration, thank you.
I also like your idea of using the Ring language to implement an xTalk interpreter - the more the merrier in my opinion.

My only concern is the 'spinning plates' analogy - where we have all these possibles up in the air, but nothing is dished up as working examples. Yes, I know it's good to have alternative ideas - and I'm not shooting anything down; However, if we had working demos / or working output showing xTalk scripting being interpreted by the Ring language, that would allow people to start developing things on that front too. I like having different directions to try, but a few things coming to fruition would be brilliant.

Equally, I know time is precious (and scarce), so this isn't a dig.

[OpenXTalkPaul]

I was looking at some info on interpreters tonight, probably you have seem some of the same infos, but FYI good info / eBook here: https://craftinginterpreters.com/contents.html
Also looking at this here Smalltalk to JS transpiler written in typescript that skips the AST (Abstract Syntax Tree) bits of the process: https://github.com/Small-JS/SmallJS
Smalltalk lang has very few reserved words so it's not all that much to look through.

That is helpful, and has a few handy snippets I can take for inspiration, thank you.
I also like your idea of using the Ring language to implement an xTalk interpreter - the more the merrier in my opinion.

My only concern is the 'spinning plates' analogy - where we have all these possibles up in the air, but nothing is dished up as working examples. Yes, I know it's good to have alternative ideas - and I'm not shooting anything down; However, if we had working demos / or working output showing xTalk scripting being interpreted by the Ring language, that would allow people to start developing things on that front too. I like having different directions to try, but a few things coming to fruition would be brilliant.

Equally, I know time is precious (and scarce), so this isn't a dig.

I agree. Particularly with that last line, not that there is much I can do about that. I was getting very frustrated by the problems I was hitting while trying to work on Linux (the browser widget problems) in the limited amount of 'play time' I've had lately, with all roads leading to the need to fix problems in the engine on the C++ source level (it would've helped if all of those dependencies had not been statically linked/embedded) with recompiling having its own problems, and I think that all had me feeling a bit burnt-out on dev stuff in general. I do feel like we're at a crossroads point. I think we both recognize the benefits and challenges of trying to shift to a different engine too, and specially building a new interpreter from the ground up. Honestly I'm not sure which road is best to take forward, but I do know I don't enjoy reinventing the wheel.

I did do some experiments with Ring but I only mapped a handful of xTalk syntax keywords to Ring keywords, it would be a lot more work to map out 1649 or so keywords (https://github.com/PaulMcClernan/lc-hun ... lk/OXT.dic). I like that Ring is its own VM/Runtime the way Java has JVM, but then there is already Java and several xTalk interpreters that already use Java for runtime engine, and java has been around a lot longer and has much more support and there is OpenJDK, GraalVM etc. so it's also FOSS. (Ring is MIT liscence).

[tperry2x]

I've added the Logarithm function and tests:

log.png (65.9 KiB) Viewed 17672 times

As you probably know, maths isn't my strong point - but I think I've got this calculating it correctly.

[micmac]

Tom, what is the timespan for one command.

is it hours, day or week?

Mic

[tperry2x]

Hi Mic,
Do you mean for me adding a command? It depends on the complexity of what each command is supposed to do.
For example, it was easy to add the put and get commands - that was about 30 seconds.
The things that have me scratching my head are all the maths functions, but that's probably just me.

The GUI stuff might take me a while to get my head around, but that's in progress with the ask and answer dialogs. I already added those - that took less than 10 minutes.

[micmac]

Thanks Tom

From what you tell it sounds doable to make an engine yourself.

It might be the best way forward.

(I have no knowledge of this)

Mic

[tperry2x]

From what you tell it sounds doable to make an engine yourself.

I hope so, that's the plan - I'll try my best.
I might reach the limits of what I can do with plain Javascript... I might not.... (I'd like to keep it as vanilla/plain javascript as possible). No extras required, no special plugins.
Where it might become fairly 'exotic' is when I add the shell (command line) functions - but I'm kind of saving that until last.

I have found with this, that it's important to add things in the right order. I'm building it up bit-by-bit, just so that if I make an error - I can go back easily. It's being developed in a text editor and a browser. No costs: just my time.

I originally put about a 5 year timescale on this, but it's actually coming together quicker than I hoped (at this point).
I'll probably revise that and say 1 to 2 years until it's something that has a nice GUI and can start to be regarded as a serious alternative. (I hope I've not just jinxed myself by writing that!)

[micmac]

I have missed that this was Jawascript, I thought this was your C++ version.

Mic

[OpenXTalkPaul]

I'd like to keep it as vanilla/plain javascript as possible

I think HTML & JS having been intitially influenced by HyperCard, and evolving to have application oriented APIs with HTML5, there's a lot of xTalk/xCard that can be implemented with 'vannilla' JS in web browser engines.

One problem with 'piggy backing' xTalk and xCard UI controls on top of JS/HTML is that various browser engines sometimes implement things in different ways, so sometimes you need to have like three different methods to do the same thing depending on what is supported on the browser it's running in.

If you're including the browser engine with it, ie putting it into a desktop wrapper app like Electron, then you already know which browser engine it will be using, so perhaps best to check that first.

[tperry2x]

...various browser engines sometimes implement things in different ways, so sometimes you need to have like three different methods to do the same thing depending on what is supported on the browser it's running in.

That's a good point. At the moment, I'm flittering between a Linux machine when I do this, and the MacBook Pro - the thing is, both are running Firefox - so of course I'm seeing the same results on both platforms. I suppose it probably wouldn't be permitted to include the full version of firefox in a wrapper (or would it, since Linux Distros do that already?) - but if not, we could include something based on Firefox's Gecko engine which renders and interprets things the same. As Firefox gives consistent results over MacOS, Linux and in theory Windows - that's what my testing is primarily being done in.

[OpenXTalkPaul]

...various browser engines sometimes implement things in different ways, so sometimes you need to have like three different methods to do the same thing depending on what is supported on the browser it's running in.

That's a good point. At the moment, I'm flittering between a Linux machine when I do this, and the MacBook Pro - the thing is, both are running Firefox - so of course I'm seeing the same results on both platforms. I suppose it probably wouldn't be permitted to include the full version of firefox in a wrapper (or would it, since Linux Distros do that already?) - but if not, we could include something based on Firefox's Gecko engine which renders and interprets things the same. As Firefox gives consistent results over MacOS, Linux and in theory Windows - that's what my testing is primarily being done in.

For Mozilla's engine there is a library I just now found out about called GeckoView.
Google AI summary:

This library, based on the Gecko engine that powers Firefox, is designed to be embedded as a web engine component in any kind of application, including desktop apps. It's particularly suited for building mobile browsers but can be used for other applications as well.

I've read that this library was meant for use in Android mobile apps, but I'm not sure if there are builds for making web-apps as desktop apps as well (no matter what the AI summary says).

This wrapper project seems to have been created using that library:
https://news.ycombinator.com/item?id=14883551

Electron, NW.js, React-Native are probably the most well-known options for web-to-desktop apps.

This looks like a summary of the history of these sort of wrapper apps here:
https://gist.github.com/cvan/88fdc79b96 ... 2db0d6c5b4

I remember using one mentioned in above link called Fluid (which used Apple's WebKit) to make a standalone Netflix app for just for my own convenience.
https://en.wikipedia.org/wiki/Fluid_(web_browser)

[tperry2x]

These all sound like possible good candidates - although I'll try and get around to testing on Safari, Edge, Opera, Chrome, Brave... and any other browsers I can think of.

When time allows.

Speaking of which, added a few more changes:

release notes.pdf

(68.31 KiB) Downloaded 8 times

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

test-1.png (13.74 KiB) Viewed 8307 times

test-2.png (26.43 KiB) Viewed 8307 times