openXION

[OpenXTalkPaul]

Probably, but it would be better if linked to Python 3 since 2 is now pretty much dead now.

Haha, you say that, but the LCC engine when compiling makes heavy use of Python 2.
Not saying you are wrong at all when you say Python 2 is dead though

Yeah I was a little surprised that on Python.org I didn't find an easy Linux installer (.deb or rpm or whatever) for Python 2.7.18, you have to manually compile it from source? No one in that massive community has made an easy install package for it?

[tperry2x]

I disagree, I quite enjoy playing around with GUI-less xTalk. At a minimum it can do anything you could do with a bash script or from OXT using shell(). It also runs on anything from the last 15+ years that has a JVM...

Yes, don't get me wrong. I like a command-line xTalk as much as anyone, however what we really need is something that is fully-formed and has a comparable feature set to the LCC engine, with a GUI, which will compile under Linux, Windows, and MacOS - without the past baggage of 20+ years of defunct and stale code.

Seems like a big ask, and I suspect that's ultimately why LC mainly seem to have ported Metacard to make LCC - because bringing all this into a modern desktop environment is a huge task. Far easier to heap new code on top of the old stuff.

As to all the command line stuff - yes, it has it's place. Who's actually using it though, compared to the number of people creating stacks in an IDE with a graphical user interface? (which is also a niche use case too).

[tperry2x]

Yeah I was a little surprised that on Python.org I didn't find an easy Linux installer (.deb or rpm or whatever) for Python 2.7.18, you have to manually compile it from source? No one in that massive community has made an easy install package for it?

It was in the mainstream package repositories at one point.
I did grab 2.7.18 when I had a chance, and it's dependencies, out of the package manager as deb files.
If I get a chance, I'll see if I can locate them. (It'll be on my backup server on my local network)
However, I don't want to cause you any broken or held packages by attempting to install these old deb files. (I generally do that with dpkg -i, however for a UI which also gets dependencies, I'd recommend GDebi).
You could probably also play around with your sources.list, so that you pull in older versions of Python through your package manager. You can always hold these versions of Python back from upgrading with Synaptic, and then revert your sources.list repositories once they are installed.

but yes, the far better way is not to use old versions of libraries and binaries - and adjust code to keep up with newer versions of Python. In the real world though, as here with software being hard-coded to old Python versions, that's not always an option.

edit: link for Python 2.7

[tperry2x]

I also think there's a lot of potential for StackSmith to be ported to Linux using Gtk or maybe even GNUStep (some of its code might even work unmodified in that case), the Hammer script dialect interpreter is not platform specific, and Uli designed the whole thing with portability in mind. My biggest question about StackSmith are licensing related, if it's an FOSS, GPL, BSD, or MIT license I would be willing to work on that effort. But that's a different topic.

I had looked into this. (Not put anything out there, as I've not asked for Uli's consent), but it seems like a huge task. I couldn't find anything that would compile the objective-c stuff on a modern system. (Apple are discouraging it's use it seems). Rather than being able to convert it over from objective-c to C++ for example - it seems more like a rewrite would be in order (although don't want to put words in Uli's mouth if he's reading this).

[richmond62]

Yeah I was a little surprised that on Python.org I didn't find an easy Linux installer (.deb or rpm or whatever) for Python 2.7.18, you have to manually compile it from source? No one in that massive community has made an easy install package for it?

Yes, Well: you were obviously using a rather narrow search:

https://pkgs.org/download/python2.7

https://packages.debian.org/search?keywords=python2.7

[OpenXTalkPaul]

Yeah I was a little surprised that on Python.org I didn't find an easy Linux installer (.deb or rpm or whatever) for Python 2.7.18, you have to manually compile it from source? No one in that massive community has made an easy install package for it?

Yes, Well: you were obviously using a rather narrow search:

https://pkgs.org/download/python2.7

https://packages.debian.org/search?keywords=python2.7

Well yeah, I was only referring to the official Python.org site, not package repos. I'm sure I could get it installed if I actually wanted to, but it's a deprecated version, which I've read has significant differences to the present 3.x versions, so I wouldn't want to write Python code targeting 2.7 at this point..

[OpenXTalkPaul]

Simple cross-platform GUIs for your command line tools:
https://github.com/matyalatte/tuw

That would probably do nicely for adding GUI to OpenXION, the JSON could even be created on the fly with xion script prior to upening the UI app
Which I think is based on this library: https://libui-ng.github.io/libui-ng/

[Kdjanz]

I really like the idea of taking command of our own destiny by moving off the heaped up pile of (insert your own expletive here) that the engine has become. Create a new engine that retains compatibility yet has completely modern underpinnings. The idea of the same look and feel across so many different platforms is also a ship that has sailed... the only common thing we have today is the web. So bring the essentials of Xtalk into the modern day by creating a new engine with a web based interface that can run locally on the machine without actually using the internet part of the browser where it is not needed. All users will see the same controls and all users will have access to the same resources with the only requirement being a modern web browser. The whole Mac, Windows, and dozen flavors of Linux are all distractions and have so many edge cases that even a large team could not tame that beast.

If you can find a graphics package that mirrors the web interface, then you could even create independent executables for running locally outside the browser. Best of all worlds in my view.

The ultimate goal is to preserve and extend xTalk. Any method that achieves that goal and doesn't get bogged down in history or platforms or all the other things you are fighting with is my definition of ultimate success. A modern xTalk that runs anywhere, for anyone, on any computer would be so much better than trying to recreate an environment that - face the facts - ultimately failed, is doomed to failure again.

my 2 cents (although we don't have pennies in Canada so I have to round it up to a nickel.

[OpenXTalkPaul]

I really like the idea of taking command of our own destiny by moving off the heaped up pile of (insert your own expletive here) that the engine has become. Create a new engine that retains compatibility yet has completely modern underpinnings. The idea of the same look and feel across so many different platforms is also a ship that has sailed... the only common thing we have today is the web. So bring the essentials of Xtalk into the modern day by creating a new engine with a web based interface that can run locally on the machine without actually using the internet part of the browser where it is not needed. All users will see the same controls and all users will have access to the same resources with the only requirement being a modern web browser. The whole Mac, Windows, and dozen flavors of Linux are all distractions and have so many edge cases that even a large team could not tame that beast.

If you can find a graphics package that mirrors the web interface, then you could even create independent executables for running locally outside the browser. Best of all worlds in my view.

The ultimate goal is to preserve and extend xTalk. Any method that achieves that goal and doesn't get bogged down in history or platforms or all the other things you are fighting with is my definition of ultimate success. A modern xTalk that runs anywhere, for anyone, on any computer would be so much better than trying to recreate an environment that - face the facts - ultimately failed, is doomed to failure again.

my 2 cents (although we don't have pennies in Canada so I have to round it up to a nickel.

Hah, I agree with a lot of this comment. The more platform agnostic the better, that's why I like things that run on Java VM like OpenXION does, it was first written almost 20 years ago and yet it still runs OK on the latest JVMs on any platform that has one available (which includes FreeBSD and other OSes).

And that's also the same reason I'm interested in things like WebAssembly builds, and xTalk<>JavaScript translator (or better transpilng). Browser Engines today come with just about anything you might need to create any sort of application. And WASM can make it fast and open up thr use of other WebASM ports (there's even an FFMPEG port to WebASM), and HTML5 has a lot of useful APIs like Web-Speech (TTS) that just works on about any platform. Hell you can even use WebAudio based Synthesizers to Jam but with scripting. The point is an xTalk-xCard like tool that runs great in a browser engine is probably the best bet to keep xTalks going into the future. There are a few 'wrappers' that can turn web apps into Desktop apps, and give them native features like direct file system access, and running shell() commands (which you can't do in a browser). Electron being the one that's been around the longest.

The ultimate thing I think would be to have a sort of xTalk VM (with it's own window manager), an example of this I think is pretty cool is the Lively Kernel:
https://lively-kernel.org/lively4/livel ... start.html
https://lively-next.org/
https://smalltalkzoo.thechm.org/

The US should do away with the Penny too, I'm pretty sure the price of copper makes it cost more to produce one than it's worth, although I've heard they don't use 100% copper now. Most people don't even use them, I throw them in a big jar.