Command-line IDE (like Python IDLE) for xTalk

[tperry2x]

This is the start of a command-line only implementation for xTalk (Linux only: due to engine-compile problems in Win and MacOS).
The idea of this is to provide something that could maybe be used in education, on an inexpensive x64 linux PC in a classroom.
This is more than just a sample stack, this is the engine distilled down into it's minimal form - without all the 'toolset' folders and such. (I could mention this in the 'Education' section. Perhaps it needs moving there... not sure as it's technically an xTalk implementation too).
Just an idea at the moment really. (download link in mega)

screenshot.png (46.94 KiB) Viewed 6120 times

[richmond62]

I honestly don't think anyone will use a command line anything in education (except. possibly, at University level), as everyone wants the visual stuff.

[tperry2x]

I honestly don't think anyone will use a command line anything in education (except. possibly, at University level), as everyone wants the visual stuff.

As I mentioned, (can't find it though now), our secondary school teaches in Python IDLE a lot. Having an xTalk alternative would be great, but this is just an observation.
I know they are using it a lot because I've observed them doing so, and also had been asked to deploy it to 93 computers via Windows group policy.

I wasn't looking to have the use-case of this debated (or have to justify it) or for it to be shot-down instantly: I wasn't trying to advocate this over the 'full-fat' or 'lite' versions of OXT after all. I just thought this section was for mentioning other implementations, so that's why I did.

If we want to see uptake of the xTalk language over something like Scratch or an alternative to Python, then surely it's great to offer something like this as an option?

[richmond62]

My intention was NOT to shoot anything down at all, but to stimulate debate.

What I do know is that here in Bulgaria (which as everyone knows is in the centre of the educational universe) secondary schools are using GUIs to teach programming. Take that as you want as a marginal European country is not really representative in any really meaningful way.

AND surely xTalk's greatest strength is the visual component?

This summer my programming intro course will look at Greenfoot, a GUI front-end for Java, knocked together at the university of London "just because" as my Granny told me, a picture us worth a thousand words.

We will then move 'forwards' to OXT Lite and all the kiddos will sigh with relief.

[richmond62]

There is an on-going debate about the usefulness of block-coding, and the (frankly unnecessary) move to command line coding.

I have encountered many, many children who just cannot. make that conceptual leap.

I believe this us for a few reasons:

1. They become habituated to block-coding.

2. They are expected to 'jump' to Python at 10-11, before they are psychologically mature enough to be capable of abstract thought.

xTalks such as LC/OXT are positioned almost exactly midway between the 2 extremes, so they are an ideal bridge.

[OpenXTalkPaul]

I've considered OpenXION as possibly the best method for command line xTalk, for two main reasons:
1) It implements a text version of Anwser/Ask (including derivatives like 'Answer Folder') allowing for user interactivity, it has a completely minimalist UI, yet the interpreter has some more advanced (than HyperTalk 2.x) language features included, such as support for Arrays.
2) importantly it can run on virtually anything that has a JVM (such as GraalVM, OpenJDK JVM, etc.) as long as the JVM is from the last twenty years or so ( I still have yet to test it out on Mac OS 9 though, lol).

My interest in command-line xTalk interpreter has not much to do with education though.
There's two use-cases I'm interest in:
1) Using xTalk the way one would write a shell script, for task automation. This was probably the instructions given to the completely separate team at Apple that wound up with AppleScript (which reads rather xTalk-like to me, although it's been said that's actually based more on Lisp under the hood). xTalk could fill a role like AppleScript, the same way .sh, python, or like Hammerspoon/Lua (https://www.hammerspoon.org). Many times the only GUI I need is a way to drag-n-drop a folder full of files for processing in some way. And when I finally abandon Apple platforms, I know I'm going to want something to fill the void of not having AppleScript and Automator on whatever FOSS Unix-like Distro I wind up using.

2) Sort of academics research oriented (OK, that is 'Edu'), A 'playground' implementation of sorts that is a line/script-chunks interpreter, that can output text and graphics to some outlet (such as a WebView or to DOM object if running inside a web browser). Basically I'd like 'Swift Playgrounds" but xTalk or Jupyter Notebooks with xTalk support. Much the same way that you can run snippets of code in many other languages (including like Python web ASM implementation) in Jupyter Notebooks (https://jupyter.org)

This certainly is a most important subject IMO, since at the core of our thing here is the engine(s) that turn xTalk script language into executable action on computers/devices,on as many platforms as possible, in as many ways as possible, the more the better,

[tperry2x]

My interest in command-line xTalk interpreter has not much to do with education.
There's two use-cases I'm interest in:
1) Using xTalk the way one would write a shell script, for task automation. This was probably the instructions given to the completely separate team at Apple that wound up with AppleScript (which reads rather xTalk-like to me, although it's been said that's actually based more on Lisp under the hood). xTalk [command line] could fill a role like AppleScript

That is a great use case for people needing to automate their systems. In many cases it might be far easier than having to trawl though cryptic bash or python commands - but that's a long-term use goal (but one I'd love to see be a reality).

2) Sort of academics research oriented (OK, that is 'Edu'), A 'playground' implementation of sorts that is a line/script-chunks interpreter, that can output text and graphics to some outlet (such as a WebView or to DOM object if running inside a web browser). Basically I'd like 'Swift Playgrounds" but xTalk or Jupyter Notebooks with xTalk support. Much the same way that you can run snippets of code in many other languages (including like Python web ASM implementation) in Jupyter Notebooks (https://jupyter.org)

This is another interesting point, and illustrates a very important second use case for a command-line version. Not only for the education sector, but opens it up more for hobbyist use. I think that would boost popularity of the whole xTalk thing though.

This certainly is a most important subject IMO, since at the core of our thing here is the engine(s) that turn xTalk script language into executable action on computers/devices,on as many platforms as possible, in as many ways as possible, the more the better.

That's my thinking as well. Here's the start of a browser-based xTalk interpreter (nothing more complex than javascript and html) which can be run locally (no internet required).

Absolutely, the more the merrier.
My command-line version here is kind of middle-ground. It's not as daunting as someone might find a terminal, but it's not a full GUI with confusing amounts of distractions for a new user either. The idea is it should be a way to try out xTalk script in a minimalist GUI. I've since added light and dark theming, and customisable script syntax colours (you can save your own script colouring themes).
However, I can't implement the method to do this used in LCC (because I'm not using the revIDELibrary, as it doesn't exist) - Neither does a method to capture the result from the message box, and neither was there any type of error handling (errors would just halt the script silently with no feedback).

My newer version does pinpoint which line the error is on if a script error occurs.

scripting.png (63.24 KiB) Viewed 1341 times

However, because this doesn't use the IDE we know - it has a difference in the way script is interpreted.
For example, in the screenshot above - I have a part at the end that will generate an error on purpose. The idea was to test when an error condition is triggered.
If the day of the week ("Sunday") contains more than 7 characters (false) then the script execution tries to:

Code: Select all

put "a" into cd btn tVarB

This causes an error on purpose.
However, this is only reported as an error when it runs. So you can happily run this on "wednesday" - and the condition is true, so you'd never trigger the error all day. But run it on a tuesday and you'd suddenly have a script error (intentional script error).

What I was trying to do is get my interpreter to check the logic of the script, without actually running it. Script execution is faster than in the LCC engine because of this, because it's not proof-reading each condition beforehand. This is what slows the LCC / OXT script editor down as far as I can tell. But even though my engine is faster at interpreting and running script, it may not be 'better' in this regard.
My focus with this experiment is to provide something without the distractions of a full IDE.
This is a desktop version (a C++ implementation) which I currently have working on Linux and Windows.

It's also perfectly capable of creating new stacks, saving those stacks, opening other stacks, and even drawing basic controls. Those saved stacks also open in LCC and OXT too.

I want to add line numbers at a very least, but it's just a side-project (at least I don't have to deal with window-focus errors here).

[OpenXTalkPaul]

Very cool! Looks like an awesome start (I will give it a spin when I get a chance).
As I've said many times now, i think piggy-backing on top of HTML5 by way of JS is out best choice to gain the most limited development burden. There are a few projects that have created JS<>xTalk translation, I'm pretty sure some of them or very liberal licensed, Even if you don't use any bits of those directly, it might help to get some ideas of best ways to approach it. For example Tyler Vano has some old similar project called jsCard that is is MIT licensed:
https://creysoft.com/xtalk/
and OpenXION author as a JS chunk interpreter library routines here:
http://www.kreativekorp.com/lib/jsChunkEx/
Of course I'm a big fan of HC Sim, and there have been some other similar projects around (like VirperCard)
Also there is Hilite.js that already has some xTalk syntax for formatting / colorization of scripts, I believe that was actually employed in the IDEs web dictionary.

I understand the concern that you (expressed in the other thread that you) don't want anyone to be able to claim ownership of xTalk interpreter restricting its use, but being able to learn from, and customize or otherwise build upon the work that other people have shared as open source (and with liberal MIT licensing) is kind of the whole point of Free Open Source Software, isn't it?

My thinking was that I could mix combination of open-source projects to quickly get close to what we're after, perhaps using my customized version of HC Simulator as a starting point and mixing it together with _HyperScript (not just for for visual effects, it enables easier async operations and more, it's a bit like an AJAX replacement in an xTalk form)

[tperry2x]

As there's a lot of conversations occurring about the engine over multiple topics and posts on here at the moment;
As I've said before, as far as I'm concerned, whatever replacement engine we jump to has to have comparative features.
No good in moving to anything that's either half-finished, doesn't have half the feature set, won't compile for MacOS/windows/linux, or is too much of a technical hill to climb just to get it set up and get going with it.

We need something that works as close to a drop-in-replacement as possible.
Unfortunately, there seems to be nothing of that ilk on the horizon. (which is what LC are well aware of) Supercard was probably their nearest competitor, but that was hardly a competitor when you consider that Intel 32-bit support stops working on MacOS Catalina+ (and as it was only available for the Mac, Catalina kind of killed it - or rather Apple did). Will the source code ever become available for Supercard and released as fully open source? Doubtful, but even if it does, it'll still need reworking heavily to support Windows and Linux.
It may be best to start afresh. But that's not an easy task either is it.