Running 'things' on non-mainstream operating systems and/or hardware.

[richmond62]

(most distros come with it now anyway don't they?)

Dunno: recently (well, inwith the last 2 years) I have installed VLC post-distro install on 7 different, relatively mainstream distros.

AND neither WindoZe or MaKintosh have VLC automagically installed.

Admittedly I have even used VLC on Haiku OS in a moment of madness.

[overclockedmind]

(most distros come with it now anyway don't they?)

Haiku OS

Hey man, I have that same madness.

[OpenXTalkPaul]

Thanks Richmond for the links to the Unix MC builds, it would be great if we had some registration info to use.
There's some Mac serials on the Macinthosh Garden, if someone uploads the v2.5 stuff on there then maybe someone else will kindly [k]rack it for us like was done for Rev v1.1 for macOS 9< and 2.2 (only runs OSX in Classic mode only it seems).

Software hoarding? HA! Not only do I still have multiple builds (official and otherwise) of 10.4 (and going back to Rhapsody beta OS), but I even have a copy of the retail CDROM-650MB-split Burnable Apple 10.4 installer. Of course a lot of that sort of thing is readily available on Archive.org these days.

FYI: OS X Tiger 10.4's Classic Mode will not work on Intel MacOS that could run 10.4.10/11, nor any virtualization based on an Intel Mac. You can use PowerPC emulators like SheepShaver or QEMU (which has a nice UI front-end available called UTM ) instead in order to do that trick (also there's 'native' emulation builds for Apple Silicon Macs).

Interestingly I recently played with someone-else's cross-platform 'native' builds of a (newly made) HyperCard stack standalone. They were actually builds of the MiniVMac Emulator setup to launch HC standalone app on macOS 7 startup inside the Emulator. This could be taken a step further by replacing the macOS Finder app with the HyperCard Stack Standalone App, just change the create/type codes of your app to match the Finder's type/creator, rename your app tp "Finder" and dropout into the Emulation's Sys.6 or 7 System Folder (should back up your original Finder of course), then the OS launches directly into your App, no Finder! This was sometimes useful to do in pre-"Multi-Finder" days (yes I'm old) when my Mac 512KE still had only 2.5 megabytes of Ram and you might be booting from a 400mb or 800mb floppy disk.

[OpenXTalkPaul]

Look what I found lurking in the revStandloneSettings UI

old engines.jpg (74.01 KiB) Viewed 2085 times

Of course this does no good if there aren't engines in the Appropriate locations, And such engines would likely require to down-save your stack format to 7 (arm6) or even stack format v2.5 (for Solaris).

[richmond62]

That Linux ARM setting is in which version of LC?

Certainly NOT in 963.

One can see similar things in, say, 9.6.11 for MacOS ARM, but that is going to do OXT no good at all.

[OpenXTalkPaul]

That Linux ARM setting is in which version of LC?

Certainly NOT in 963.

One can see similar things in, say, 9.6.11 for MacOS ARM, but that is going to do OXT no good at all.

LC Community for Linux / ARM6 packages were built by community members late in v6 cycle and up to v7.0.14, the Community member 'Shao Sean' posted that he succussfull built LC CE v8.x for Linux ARM but they never posted the build for downloading anywhere.

But I do believe we could, possibly easily, add the LC CE v7 Linux Arm6 binary back into the Standalone options, similar to how we've added macOS 32bit builds back in. Using an LC CE v7 Engine means no widgets allowed

I guess technically the Android Engines are Linux Engines too, since Android runs on top of the Linux Kernel.

I'd like to add back-in Android build options capabie of using old ADK for Android 2.x and 4.x. Ironically the stacks (AND Extensions) that I built Android .apks builds from with these older dev kits from back back when, run very well side-loaded on my Sony Android v10 TV, in contrast I've had some newer builds (Android 6+) that don't run, or don't run well or fail to function fully. My Battery Monitor Extension became broken long ago on newer built package builds, probably needs API update in the code.

The Android build process is actually something we can update without even recompiling an engine, since the scripts direct command-line apps from Android ADK that do the actual building of Android App packages.

[OpenXTalkPaul]

Can we in any way get it to depend on, perhaps, the VLC libraries?

[redacted] re; sorting out video for LC Linux for at least 20 years (started asking them questions in 2003!) . . .

My personal feeling is that being dependent on anything external to the acutal IDE is going to cause problems sooner or later (after all an end-user who get a shopping list telling him/her/it a vast number of 'other stuff' they have to install on their rig just to watch a 30 second movie of someone changing their trousers is NOT going to be a happy camper).

Also . . .

If the "totally cross-platform" mantra is to keep humming (and it never was totally true), a programmer should, as the [redacted] "program once, spread everywhere" (a bit like peanut butter, really - sticks between you teeth); so whatever is going to play video on Windows has to play it on Linux has to play it on Mac, and has to play it on any other platforms any OXT developer is aiming at.

I disagree, embedding into the Engine and maintaining an entire self-contained system for playing and editing media files would likely break constantly and need maintaining and recompiling engines just to fixes minor issues. Try compiling the three FFMPEG CLI binaries from source with all the supported dependencies, codecs and such compiled in...together they're about 150mb.

This is why I talk about libraries meant for abstracting away the underlying implementation from the xTalk script. For example you would write your xTalk scripts to call the (unreleased) 'OXT Unified Speech' library and that library picks the best available speech synthesis engine to pass along the appropriate parameters. Your scripts just wants TTS to happen, it doesn't matter if the library is using whatever revSpeak External is using, if it's using whatever HTML5/JS engine is using (if your xTalk is running on Web), eSpeak on Linux, or some obscure 'Speak-N-Spell' Emulator thing. The same could be done for media recording and editing functionality, you would call cropVideo tPathToVideoFile, tleft, ttop, tright, tbottom add the library might be using FFMPEG on Linux, or AVMedia on macOS14, or QuickTime via AppleScript or JSX.

This is already the way that that some things have worked. Like revLibURL works on 'Commercial LiveCode using a third party made custom library called TSNet to implement its functionality, do the actual connecting and downloading, but they used another (slow) method on the Open-Source Community edition.
Like I said before, high-level abstraction (such as Answer/Ask File(s)/Folder(s)/Record/Color) has always been part of xTalk.

IMO we should get 'the Engine' down to being as simplified as possible (K.I.S.S.), make any functionality beyond the core language interpreter be separate modules that can be updated individually.

In several instructional standalones I have authored for my school and so on, I have used animations so that I am 100% sure they will work 'Whereever': of course this is alright ONLY if it involves simple stuff such as a cartoon of some kid picking potatoes, but NOT for a movie-qua-movie.

Oh sure there's lots of very simple ways to do animations with xTalks. At some point I took the classic 'QuackMan" HyperCard stack, and updated it from using B&W ICON resources on Mac System 6, to using full color PNGs (that may look a little too close to Namco's Pac-Man) in OXT and it works pretty smoothly. I should upload it somewhere it's a pretty good example of using xTalk to write a simple 2D game (that even runs well on a 0.8MHz Moto 68000 CPU), and its also proof/example you can port ancient HyperCard stacks to run on modern(-sih) OXT Engine.

[tperry2x]

Interestingly I recently played with someone-else's cross-platform 'native' builds of a (newly made) HyperCard stack standalone. They were actually builds of the MiniVMac Emulator setup to launch HC standalone app on macOS 7 startup inside the Emulator.

I was kind of thinking along the same lines, in view of a lack of arm-native support for MacOS.

Rather than have to run a full Virtual Machine, booting into Windows / Linux, just to run OpenXTalk.
The same way wineskin works, in producing a self-contained wrapper:


I wondered about having a Whiskey wrapper, which has native arm support, and will still allow the OpenXTalk builds to run. We could then continue to run OpenXTalk RCx & Lite [windows builds] inside this wrapper. It could be set up in such a way that it looks exactly like a mac app.

I know Apple haven't yet, and this is an old article:
https://www.macrumors.com/2021/03/02/ro ... 3-strings/

In the third beta of macOS 11.3 seeded to developers for testing today, MacRumors contributor Steve Moser uncovered new strings in the beta's code indicating that "Rosetta will be removed upon installing this update." Another new string reads "Rosetta is no longer available in this region. Applications requiring Rosetta will no longer run."

I know that this is an old article I'm referencing, but this does not detract from the fact that If these string statements exist in the developer kits, then it's feasible to say it's going to happen. Everything is in place already for this to be discontinued. All it would take is an update that tells the system to flick the kill switch on Rosetta 2. If anything, it means we need to have more options in place around this. It might be a few months, but it could also be years away. It's the not knowing that I don't like.
https://forums.developer.apple.com/forums/thread/692238

However, I'm getting away from my original point. It's just to be prepared for this eventuality if it occurs any time soon.

Kdjanz has been doing some testing for me on an arm mac, and confirms that OXT Lite 0.98 [windows] runs fine via Whiskey on Arm.
So, this is known to work. Thanks again Kdjanz, much appreciated.

If we then had a wrapper in place, which functioned as transparently as wineskin can, then this would be a route into providing continued platform support for Arm-based macs.

[richmond62]

For a few months of madness I was running LC 963 for Windows on MacOS 14 Sonoma under WINE 8: this is alright up to a point, but if one were to run a Windows executable via WINE on Mac ARM machines that would still NOT allow us to build Mac OS ARM executables.

[tperry2x]

...that would still NOT allow us to build Mac OS ARM executables.

Very true. My other suggestion was going to be less popular with die-hard mac fans: to ditch macOs when apple stop supporting x86-64 intel code, and run an arm version of debian instead. (as that will still offer an ability to run intel x64 programs)

Debian has multiarch support which means that you can install and run programs built for one architecture on other architectures.

https://cdimage.debian.org/debian-cd/cu ... -DVD-1.iso

[richmond62]

die-hard mac fans

Well: let us pause a moment and ask ourselves who is likely to use OXT (none at the present rate):

1. Teachers preparing 'guff' (interactive somethings) for schools . . . 98% of schools run Windows.

2. Teachers using OXT to teach programming to sprogs . . . 98% of schools run Windows.

3. Other people running up Q-n-D in-house stuff to do Q-n-D things . . . Most people use Windows or Linux: and if people are so wealthy they can afford new ARM Macintoshes they can pay for LiveCode, use other commercial software, or boil their heads.

4. Niche nutcases working on the programming equivalent of the great American novel that will take them several years until they have something semi-decent.

This is where I hope a few people who are reading this stuff can chime in with some other realistic use-cases.

As I fit into ALL these categories:

1. In-house stuff for my language/programming school.

2. Teaching sprogs programming.

3. Just ran up a text analysis program for my son for something he is doing for his PhD which involves trawling through 1,000s of documents: the commercial thing would cost him £500: OK, nicer interface, more capabilities (which he doesn't need), blah, blah, blah: why waste 500 quid when Dad can knock you together a Q-n-D thing that does what you need all for the price of running downstairs to make coffee and carry a plate of biscuits upstairs?

4. Niche nutcase: Yup: Devawriter Pro (for typing in Sanskrit FFS) ongoing after 14 years: Pismo (for typing in Glagolitic Old Church Slavonic FFS): Grendel (for typing in Anglo-Saxon, Lower Franconian, other distinctly dead Germanic languages FFS). At least it keeps some psychopathic creatures locked in their University departments analysing and digitising ancient languages when they might be out button-holing random people in the street and asking them, "Why don't you speak Gothic?" with threats and violence.

I would say, "Screw Macintosh ARM processors: or, at the least, bung them right down the bottom of the laundry list."

BUT, wait a moment, I am a "die-hard mac fan" . . .

Well, YES and No:

Between 2009 and 2018 I had only access to a 32-bit Intel iMac running 10.6 (Snow Leopard), so dod all the things I listed above on Xubuntu.

I have NO problems at all with Xubuntu.

I like the Macintosh interface: but as this is fakeable on XFCE this is not a factor.

Emotionally attached to Macintosh computers.

BUT, quite honestly I cannot see myself getting my knickers in a twist if there is no Mac ARM version of OXT.

If you can get a version 1/RC 1 out of the door with the inherited LC engine that has to be the first step (which you are fast approaching), which will be a wonderful thing.

If 'someone' works out a way (engine or other) way to get things up-and-running on Mac ARM machines: well, jolly nice: but not mission critical.

[richmond62]

Debian has multiarch support

Probably getting the messageBox to accept the cursor on Linux systems is more valuable at the moment that anything about Mac ARM versions.
-

[tperry2x]

Probably getting the messageBox to accept the cursor on Linux systems is more valuable at the moment that anything about Mac ARM versions.

(very mortal engine) - perhaps even geriatric.

That is partly down to the choice of Linux distro, and a combination of engine incompatibilities with particular window managers. (They can all be a bit flaky to be honest, but depends on what combination of other windows you also have open, inspector, stack you are working on etc). I've mentioned this before, but a lot of the issue is due to all the needless calls back-and-forth the inspector makes in the message path. As I said, it's a mess, and to unpick it is beyond the scope of my improvements I can make.
Also not helped by the fact that the engine on linux does not understand the systemwindow property (as they say in the documentation) - whereas on Macs and Windows, that has been included in the engine.

So, on linux we have this merry dance of palettes to overcome what should be fixed in the engine. (yeah, sounding like a broken record).

As such, I'm more bothered about the engine as it's a long-term consideration. Fixing the engine will also fix all these other associated issues.

In the meantime, you could always just:

Code: Select all

set the toplevel of stack "message box" to false;set the systemwindow of stack "message box" to true

That'll make it float above "everything", or at least it does on ubuntu:

haha-float.png (70.54 KiB) Viewed 1879 times

Note on the screenshot, on the bottom panel, Firefox is my frontmost window - and after running this, the message box is always focussable - so much that it's in the way.
Not what you want, and a funny effect, but it's clickable at all times.

You could always have something like:

Code: Select all

on suspendstack
Set the systemwindow of stack "message box" to false
pass suspendstack
end suspendstack

(This only has merit on the Linux distros where systemwindow has any effect)
I find Ubuntu-based ones, with XFCE to be the worst so far. I've tested lots so far. I would deem all of them workable except Ubuntu / Xubuntu ones.

That line above will make the message box behave differently between Linux distros. Some don't do anything.
I get the feeling that when LC say that the system window is not supported on Linux, they probably mean 'not consistent'

When you quit the IDE and reopen it, it'll be back to normal (unless of course you'd saved the message box stack), but sometimes just toggling the message box a few times is enough to get it working too!

As a last resort, you could also use:

Code: Select all

set the blindtyping to true

if you are having messagebox focus issues. Then you won't need to click it to be able to type into it.

[tperry2x]

If 'someone' works out a way to get things up-and-running on Mac ARM machines: well, jolly nice: but not mission critical.

That seems to be the general consensus, between those I've PM'd and comments on here.
Nobody seems overly worried about it, so that's fine.
But I keep banging on about the engine needing attention because a lot of the problems can't be fixed in the IDE when the engine seems to be trying to fight it. Two conflicting functions, running at the same time, both trying to set the same variable to something different never ends well.

Of course, people aren't bothered about arm support - until suddenly one day they are.
Anyway, that's the last I'll say about arm support, & I mean that because that's been well and truly explored.

I think it's good that Paul is looking at versions that run in a browser (even if local). I think it's good that there are multiple approaches and different directions to go with this. That's if we are serious about keeping the language alive outside of anything closed source / commercial.

[OpenXTalkPaul]

It would be great if there were a MacOS version or Linux equivalent to WINE (which is a MS Windows compatibility layer), but WINE only does MS Windows stuff.

There are of course ARM translations from Intel to ARM instruction set (such as Rosetta2 and QEMU), even with some reports that certain code actually runs faster in Rossetta2 ARM translation, but unfortunately currently it is only through the Rosetta2 method that we still can 'native'ly access macOS APIs from our macOS Engine and its Externals and Extensions.

That's not good for me (am I #4 in Richmond's list?) because I want scripting access to the OS's media and MIDI APIs. Its similar to the reason that xTalk inside a Web-Browser is not optimal. Although being able to use Node ecosystem and tons of APIS via JS libraries might make a web-JS based xTalk, in the long run, better alternative to running in an OS-in-VM or some sort of Wrapper.

Apple was fairly clear that this was always going to be a stop-gap emulation, a transition phase to new Architecture, just like the switch from Motorola to PowerPC, and later PowerPC to Intel CPUs were. I expect that macOS 15 will cut support for Intel Machines and that there will be an influx of macOS-to-Linux (or-Windows...NO!) switcher/converts when it does happen.

I've always been looking for alternatives xTalk/xCards, and uncertainty in the commercial companies sphere has always been part of the reason.

I'd bet that Uli's Stacksmith Engine would not be difficult to compile to ARM binary (it re-compiled it from source for Intel quite easily). But that's written largely targeting macOS UI 'widgets'. The underlying 'Hammer' script engine should be portable though and I just installed GTK GNOME dev kits on macOS so If Hammer/Stacksmith could be modified to use GNOME's APIs (which to some degree are cross-platform) instead of Apple's Cocoa then we could probably have it running on Linuxes too.

[OpenXTalkPaul]

BTW @tPerry2x
I tried OpenXION 'native' on Sonoma (where I know I never installed a Java runtime) and got the same results as you, JVM runtime environmental variables are not set and so it fails to even try to start. I either didn't generate the binary with the correct switches to make it work (there's lots of options to explore), or the dynamic nature of OpenXION is not compatible with the pre-compiled environment that create ( https://www.graalvm.org/native-image/li ... rameworks/ ). I must have unknowingly had a JRE installed on the machine I originally tested it on. Alternatively OpenXION could be bundled to include a Java runtime (JRE). https://www.advancedinstaller.com/user- ... e-jre.html https://www.youtube.com/watch?v=51iMSVUOQNM

[overclockedmind]

Xubuntu, while close to my faves, has options like window focus stealing prevention and other things that make it "out of spec," if you use them.

You can even get rid of font smoothing/hinting.

I love the thing, but I know better than to set it up to do some extremely heavy lifting over the network, such as upping a 50GB file to my file server just by using drag-and-drop. It gets done in a Terminal window... XFCE's file manager Thunar will drop the whole process and it's just... gone. Where did it leave off? Who knows, it's gone.

But Linux distros are like opinions; everyone's got their favorite.

The reason this comes up is: when I got this MacBook Air, it had Monterey on it. And luckily it worked out for doing testing. Now this, friends is a 1.6 GHz Dual Core i5 with 8 GB of RAM, so over the life of the machine, when it's not needed for testing anymore, it'll be leaving Monterey Station.

It was merely one of those "happy accidents" that worked out well for the situation at hand. And so, as long as it's needed for testing OXT, Monterey it is. This isn't a whine: when I returned to the project, I could contribute! Awesome. And I enjoy contributing in whatever minor way that I can.

But Apple's interests, and mine? They just kinda don't line up. I'm contributing for a Mac future when I'll be in Linux at the end of the day. And that's fine by me.