Hypercard Simulator

[OpenXTalkPaul]

Ahhh.... now I see, this 'Hyper Variety LLC' is Dan Gelder, who produced the righteous, although never released, SERF xTalk/xCard. That makes total sense.

Of the estimated 27 million software developers around the world today, what percentage would identify as HC fans?

Would the percentage who would even know what it is be higher than 5%?

A lot's happened in 36 years.

HyperCard and some that followed weren't really created for software developers were they?
I think this is an idea that's gotten forgotten somewhat — HC was created for 'The Rest of Us", the users, to use. "A solution in search of a problem "— Atkinson. The ability to produce standalone apps didn't even appear in HC until v2.3.5 IIRC. And there was not even any built-in syntax for reading binary files (no 'null' keyword). I'd argue that there are (or were) way more fans of HC/xTalk that never became 'software developers' at all, I didn't (at least I didn't really try to be).

Yes, 36 years is a long time, but since HC was officially shelved by Jobs more than two decades ago, I find it impressive that there are still as many fans as there are, and I'm specially amazed that there seems to be a younger, a bit retro-obsessed crowd that have gotten into it the idea more recently.

I do think the time is now to move xTalk/xCard onto the web (with the help of HTML5) where it should have been as soon as the masses started to have internet in the early-mid 1990s. I'll say it again, while I really like the offline/bare-metal/OS APIs access of a 'native' engine, I do believe that this sort of xTalk/JS transpiring thing would be THE best path for xTalk going forward, for reasons such as the low-cost of maintaining (since 'huge-corp' does the bulk of 'Engine'/Platform developing) and platform agnosticism. With a 'native' wrapper such as Electron, it could have access to the whole Node.js ecosystem (and therefore some of that bare-metal goodness).

[OpenXTalkPaul]

This implementation shows HyperCard's object model and similar edit controls reimplemented as a JavaScript app.

https://hypercardsimulator.com/

So Dan... first thanks so much for building this thing, it's really cool. What's the license on this HyperSim? Can I get the JS source and fork it? I've seen the HC 2.4.1 grammar around in GitHub repos, various things that use such grammars, but I since I wasn't sure how to go about turning that into this sort of transpiling web xTalk scripting 'engine'.

Also, how do you put clickable URL links into these web stacks as there is in the HomeStack, and do you created a movie 'Player' control as there is in the Home stack? Is it that you just replaced the contents of the Fld's XML tag with some HLML5 Canvas player?

How about importing color images (PICT)? I see it already supports addColor syntax, but is stack the importer the only way to import a color image?

And how about adding 'Answer 'File' or Answer 'Color' (using Web APIs)? It would be cool if binary data could be read into a blob/Data URL or JSON Array. Also a textColor chunk property would be great too.

[OpenXTalkPaul]

https://HCSimulator.com/script.js
Begins with these comments:

/* (c) 2022 Hypervariety Custom Software. All rights reserved. Packaged 2023-05-25 18:00:11 */
/*
LICENSE:
This file was developed ©2022 Hypervariety Custom Software, LLC. There is no warranty of any kind expressed or implied. THIS FILE IS OPEN SOURCE. YOU CAN COPY AND RUN THIS FILE YOURSELF AND LEARN PROGRAMMING TECHNIQUES FROM IT. Although the code is not very well-written or pretty, in the interests of public discourse, I am making it available for view.

THANK YOU TO THE RETRO-HACKERS WHO FIGURED OUT THE HC STACK FORMAT.
This script accompanies the stack importer at https://github.com/hyperhello/hypercard-stack-uploader
*/
So you can read and copy this xTalk interpreter 'engine' but it's not a very clear license beyond that.

[OpenXTalkPaul]

Still it's very cool to be able to quickly put the very first stack that I ever saw (created by my sister Nancy sometime around 1987) onto the internet without installing some browser extension or without first manually converting and then loading our 30Mb Emscripten engine into the browser along with the ported stack. The original HC stack for this little animation is about 700kb, this JS 'engine is 750kb, so it loads far faster then the alternative (but of course its only a subset of xTalk avialable in the Emscripten engine).

http://www.openxtalk.org/WebStacks/SchrodingerCat.html

MissicHCIcons.jpg (127.84 KiB) Viewed 917 times

Oops, It seems to be missing the button graphics originally included with HyperCard, I guess those don't get embedded in this html-ish stack format exported from that HC converter.

But since the stack didn'I really need those background buttons, I was able to just delete the tags for those buttons in a text editor, which is nice.

[OpenXTalkPaul]

For comparison, importing into OXT (by way of intermediary LC Community 6.5.2 running on macOS 10.6) for some weird reason resulted in an exponential gain in file size, a whopping 100Mb from a bunch of small, 1-bit bitmaps does not seem right at all, it must be converting the bitmaps to 24bit RGB data or something.
It did import the Lef/right Arrow ICONs, but also completely mangled the background artwork on this particular stack, not sure what that's about:

FileSizeWOAH.jpg (202.2 KiB) Viewed 881 times

Meanwhile the HTML-stack conversion only gained like 50kbytes (+750kb for the Script.js 'engine' if you want the web-stack to actually run), and it looks almost exactly the same as the original HyperCard stack. I'm Lovin' it and I haven't even gotten into the JS mix+matching yet

[richmond62]

Unfortunately your sister's HC stack,

https://www.openxtalk.org/WebStacks/SchrodingerCat.html

while loading (MacOS 12, Brave), does NOT have functional buttons.

[OpenXTalkPaul]

Unfortunately your sister's HC stack,

https://www.openxtalk.org/WebStacks/SchrodingerCat.html

while loading (MacOS 12, Brave), does NOT have functional buttons.

Do you have JavaScript disabled? It works fine on Safari in Big Sur on my end (even the play sentence command)

[richmond62]

Do you have JavaScript disabled?

Unknowingly I did, and, Yes, the thing ran perfectly well in Safari.

BUT, this could be a snag if that is going to be 'the' way to deliver things via web-browser, as end-users will not want to bother with stuff like "enable Java" instructions.

[OpenXTalkPaul]

Do you have JavaScript disabled?

Unknowingly I did, and, Yes, the thing ran perfectly well in Safari.

BUT, this could be a snag if that is going to be 'the' way to deliver things via web-browser, as end-users will not want to bother with stuff like "enable Java" instructions.

I also checked on my phone and it ran fine in Safari Mobile as well. (looking at the JS source it's OnTouch aware)

Despite the names Java and JavaScript are actually unrelated.

Most modern web sites (accept for the increasingly rare HTML-Only pages, like those links pages on the OXT site) absolutely count on JavaScript (standardized as ECMAScript) being available.

A quick Googling: "As of 2023, 98.7% of websites use JavaScript on the client side for webpage behavior"
So I think it's safe to count on JS engines being around well into the future.

[richmond62]

I wonder why the Brave Browser should not have allowed this.
-

Screenshot 2023-12-10 at 17.42.23.png (108.11 KiB) Viewed 869 times

[OpenXTalkPaul]

I wonder why the Brave Browser should not have allowed this.

I can find NO reference to JavaScript in Brave's preferences.

I'm not really familiar with the Brave browser, but maybe it's one of those privacy ad-blocking oriented browsers and you have to approve it for individual site or page to run script first? I'm just guessing.

Is there a developer menu in Brave? Maybe JS is disabled there?

[OpenXTalkPaul]

HCSimErrors.jpg (179.92 KiB) Viewed 867 times

I just tested it on InterWebs, the most up-to-date web-browser available on macOS 10.6 SnowLeopard, and it failed to run and I got these errors in the JavaScript console.

So it needs "web workers" which is probably used for the 'wait' timer sorts of syntax. It looks like this browser also seems to restrict 'mixed content'. Not sure what code-base InterWebs is built from, but I'd guess its probably based off of some significantly older version of FireFox.

In contrast some "Decker stack' ran on this, and the "OXT WebPlayground" (Emscripten engine) at least tries to run on it. Which is still impressive since macOS Snow Leopard is like over 15 years old.

[OpenXTalkPaul]

If you paste the following script into the OXT WebPlayground's 'Console' (at https://openxtalk-org.github.io/OpenXTalk-Playground/ ) and then click the 'Run as xTalk', it's the very beginnings of some xTalk IDE tools in the Emscripten engine ...'OXT Simulator'!

Code: Select all

if there is a stack "Tools" then delete stack "Tools"
create stack "Tools"
set the width of stack "Tools" to 128
set the height of stack "Tools" to 400
set the defaultStack to "Tools"
create button "Close"
set the script of button "Close" to "on mousedown"&cr&"close stack Tools"&cr&"end mousedown"

[OpenXTalkPaul]

Playing around with this sim some more tonight, I used just a smidgeon of JS to add a launchURL command to the sim's script.
Freely mixing and matching xTalk + JS is pretty dern cool I must say, a gazillion times easier than writing an XCMD and it's awesome that it saves my sim script modifications into my account so that they're available any time I log in from anywhere.

I noticed there are some Sim global JS objects in there, like representing the sim, besides the regular web DOM stuff, I'll have to look into that further.

I guess macconv that the importer uses, can only preserve resource fork stuff (like SND resources) is the stack is in a disk image?

I tried to import some sound sample collection stack's (the Monty Python collections) and it did import the stack, but it didn't pull I the 'SND ' resources. Browsing other imported stacks, it clearly can be done, but I'm guessing only if the stack is inside of a HFS .dsk image (as used by classic Mac emulators) with its res-fork intact. I know Apple deprecated the resource fork in macOS like a 100 years ago, but macOS has still, for a long time anyway, seemed to preserve the resource fork data (I guess storing the data in those Apple double ._*filename meta files or otherwise in some extended file attributes somewhere).

It would be super cool if there was an implementation, if there isn't already, of some sort of 'resource-fork' replacement system, where resources like ICONs, SND ,PICT, etc. (and maybe support some new formats like 'SVGP' for a SVG Path String ) that can be stored in a web-friendly format (like blobs / data URL) that could then be listed or referenced by name or resource number and copied from one stack to another stack (like a Resource Mover XCMD would). That could simulate the HyperCard authoring feeling even more better.

[OpenXTalkPaul]

I'm becoming enthralled by the idea of xTalk lang piggybacking on a web browser engine as a method of achieving platform agnosticism and longevity for our favorite language.

This HyperSim here is a great start and I'm still poking that around with a stick... and also I'm starting to work on bringing some similar IDE-type features to the Emscripten engine. Both xTalk-dev-on-js-web methods have some features that IMO are nicer than the other.

Both allow for mixing in some JavaScript code in order to implement features and exchange data between the two worlds.
However HyperSim allows you to in-browser edit the syntax in the Sim's Script, it's xTalk<>JS transpiler 'engine' (which is above 'Home' in its message path), and 'Live-Reload' it.

However my previous comments were incorrect. Any Sim Script edits the user makes are saved to the users browser cache, NOT into your HyperSim account, so these edits are NOT available when you log in from another device. I am keeping a copy of my additions in a field in a stack in my account, so I can copy-paste it into the SimScript as needed on a new device or a different browser.

Also its 'freely mingling' of xTalk + Javascript is somewhat less 'freely' than I had originally thought. It seems to be only in the Sim's Script that you can do that sort of mixing + match mingling of the two languages. I can't get JS to work at the Stack level, which is a shame because if we could then it could be much more like a virtual-XCMD/XFCN, allowing for the code extension to travel with the stack the way eXternals did back in the day inside a stack file's resource fork (which, in case someone reading this doesn't know, was a MacOS classic thing)

Although it lacks any syntax for 'set the HTMLText of field ...' in HyperSim (It's a subset of HC 2.4.1 syntax, maybe we call that 'Level 1-2 xTalk'? ), it does however allow you to just copy arbitrary chunks of web pages and paste it, while retaining images, text styling, hyperlinks, etc. into a card field, which is really awesome (and not at all HC 2.4-like). I guess it's embedding the HTML into its 'part' tag? I'll have to investigate further. Oddly enough, you can even paste an entire other field, including border, styles and all into another field resulting in a field inside of a field, although I would guess the sub-field is just the contents of the original field but no-longer functional as a field as far as setting feild properties on 'sub-field'. Our Emscripten Engine can't do anything quite like this, it's far more self-contained and isolated from the outer web-world, although it does have the capability to expose itself more.

A really cool thing is in HyperSim you can implement new syntax rather quickly and fairly easily with this method. Any function added there can be called like a function OR referenced as a value as you would an xTalk global/engine property.
So for example, I made a SimScript function that use some JS to get the outer-webbrowser's dark mode preference and named it like 'function systemAppearance' then in Stack/Card level xTalk scripts I can use the return value like so:

Code: Select all

if the systemAppearance is "dark" then --- do darkMode stuff

This enables exactly the same syntax I would've used with any of the OXT engine(s).
You can of course still use it as a function normally as well: 'put systemAppearance()', which is just like a lot of other syntax, example: 'the mousLoc' an 'mouseLoc()'. This seems to be a sensible way to wire the interpreter to enable 'OpenLanguage' (one of those funded but unfulfilled 'stretch goals' )

[OpenXTalkPaul]

Pasted in Web Content.jpg (170.65 KiB) Viewed 774 times

I used the above to half-enable 'backDrop' syntax too, which in this case I made that mean the outer-web page, and didn't (yet?) allow for a pattern filled background (hence the 'half-enabled').

The Color logo on my test stack is in a field's content, simply I copied and pasted it directly from the openxtalk.org site front web page.

Those ancient 1-bit icons and artwork don't look so good when rendered at different size and line-density. Scaled down you can see it's making for various Moiré patterns, which is a problem commonly found in the printing industry.

[richmond62]

Why not go off on a tangent that does not seem to interest anyone else?

After all, my Devawriter Pro for digitising ancient Indian languages is like that.

[OpenXTalkPaul]

Why not go off on a tangent that does not seem to interest anyone else?

After all, my Devawriter Pro for digitising ancient Indian languages is like that.

Are you being sarcastic and saying that I'm going off on a tangent with web stuff?
Or are you saying that the world wide web does not seem to interest anyone else besides me?
I don't see working with this xTalk interpreter as going off on a tangent at all, completely to the contrary, this is entirely related to Open-source and xTalk, and I'm convinced it could be made into a monster if we all pulled together as a team

Anyone with some JavaScript skills can work on the development of this xTalk 'engine'...
and I think that inherently makes it far more likely to get community contributions.
It's easy to add to its syntax and modify the existing syntax of the interpreter.
It loads much much faster than our Emscripten xTalk engine.
Its file format is 'stack as a web page', therefore you should be able to manipluate the DOM objects in ways that any web page things can. Add some SVG animation 'parts' (LC calls objects 'controls' and 'widgets') or new CSS based 'visual effects' syntax is entirely possible. I'm imagining mixing in some other xTalk-oriented JS libraries. ///_HyperScript+HTMX ( https://hyperscript.org ) could be really useful here and would keep it all in the family (the xTalk family).

With this setup, you can develop with xTalk from anywhere there's an HTML5 browser engine available.
No Xcode, Visual Studio needed and it's safe from over-zealous IT dept.
This may still be a diamond in the rough, but I thought you guys wanted less bells and whistles with your xTalk anyway?
This is absolutely PERFECT for schools and for students on low-powered Chromebooks or SoC type machines (RPi)
I runs 'Native' on a phone or iPad or Apple Silicon Macs.
It's as platform agnostic as you can get.

If you need any more 'native' access to the operating system you wrap it in a JS App engine like Electron and have all access to all of Node.js 'React-Native ecosystem from xTalk (would still need to make wrappers).

It has a working importer for HyperCard content, and some XCMDs/XFCNs can easily be reimplemented (as I did here for 'launchURL'). By piggy-backing riding on top of HTML5/jS, all the heavy lifting work of development is then being done by MEGA-Corps like Google & Apple, and we gain security and new features 'free'.
Most browsers (Chrome, FireFox, not Safari) now even have built-in support for WebMiDI so I can still easily do some live-coding music stuff while sticking to using xTalk (after writing some wrapper code, which I already added a check for if WebMIDI API is available).
... and again xTalk gains access to all of the gazillion JS libraries that exist, like Charts.js (isn't LC using that) for example.

This kinda solves our problem of lacking a real-pro-lead-software engineer now doesn't it?

and furthermore...

I'm not an lawyer but with a little work this could very probably free all our xTalk scripts from being in anyway bound to that 'LC Community license' in accordance with LC's publicly declared interpretation, because if your scripts don't need that particular xTalk Engine in order for the scripts to work, then your scripts are no longer a 'derivative work' are they? They're something separate, a work in generic 'xTalk lang'.

Mind you, I'm not saying we should abandon the LC Community Engines / IDE code-base at all. I still intend to compile new binaries from source (specially once I get a hold of an Apple Silicon Mac). I am getting more interested in compiling
on Linux, in part because that is also the recommended platform for compiling the Emscipten version of the engine.

What I am saying is that if we can re-implement most, if not all, of our syntax with another xTalk interpreter, one that was built to be far more open and web oriented from its inception, then we should. Then we'll have a second foundation, a backup plan (too bad the name 'Plan 9' was already taken by an OS). An xTalk foundation that runs on web is one that is going to be useable for a very long time, maybe as long as there are web browsers.

[OpenXTalkPaul]

In my opinion, xTalk should have been a web language as soon as NCSA Mosaic browser existed, not just as a CGI (Common Gateway Interface) forms data processor, as is the case with the 'server' version of the engine (you could also do that with HyperCard back in the early days of the web), but for actually programming the webpage interactivity.
Although I don't think it has been until fairly recently, in the last 10 years or so, that I think Web APIs have really gained everything needed to make xTalk+xCard usability on Web a real possible (unless you count proprietary Shockwave/Flash with its original, early Lingo xTalk syntax, before evolved into a more javaScript-looking ActionScript 2+).

[richmond62]

Are you being sarcastic and saying that I'm going off on a tangent with web stuff?

A bit of both.

Mainly because I see OXT Lite 'advancing' by leaps and bounds, and feel that energy should channelled there until we have a 'Number 1'.

HOWEVER, I obviously 'pricked' you slightly more than I intended to; sorry for that.

ALTHOUGH your response covers a lot of interesting ground; thank you for that.

As my focus is xTalk as a teaching tool that is NOT dependent on web-access . . .