Mortal Engines

All flavors welcome.
Forum rules
Be kind.
Post Reply
User avatar
richmond62
Posts: 2621
Joined: Sun Sep 12, 2021 11:03 am
Location: Bulgaria
Contact:

Mortal Engines

Post by richmond62 »

https://downloads.livecode.com/livecode ... 0_dp_4.pdf
-
Screen Shot 2022-06-01 at 1.29.20 PM.png
Screen Shot 2022-06-01 at 1.29.20 PM.png (86.37 KiB) Viewed 1185 times
-
IS there anyway we can leverage this?
https://richmondmathewson.owlstown.net/
User avatar
richmond62
Posts: 2621
Joined: Sun Sep 12, 2021 11:03 am
Location: Bulgaria
Contact:

Re: Mortal Engines

Post by richmond62 »

Screen Shot 2022-06-01 at 2.08.44 PM.png
Screen Shot 2022-06-01 at 2.08.44 PM.png (46.21 KiB) Viewed 1184 times
https://richmondmathewson.owlstown.net/
User avatar
tperry2x
Posts: 1341
Joined: Tue Dec 21, 2021 9:10 pm
Location: Britain (Previously known as Great Britain)
Contact:

Re: Mortal Engines

Post by tperry2x »

That would be great to see in OXT, however I don't think the folks up north would offer up their code voluntarily.
There's always a force decompiler method..., but that would be a bit naughty.
User avatar
tperry2x
Posts: 1341
Joined: Tue Dec 21, 2021 9:10 pm
Location: Britain (Previously known as Great Britain)
Contact:

Re: Mortal Engines

Post by tperry2x »

(in fact, it would probably be in breach of any licensing... blah blah blah).
User avatar
OpenXTalkPaul
Posts: 1485
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Mortal Engines

Post by OpenXTalkPaul »

I do now have an (Intel based) rig that's running macOS Monterey so theoretically I could or someone else could TRY to build the engines for M1 Architecture (which would probably be a more sensible name to use in the SB stack, or AArch64 / ARM64). It seems there was preliminary pushes on github towards that end before LC returned to closed-source.

But as far as leveraging any of LC Ltd's work after Aug. 31st 2021, no we can't use anything 'over there' that isn't open source GPL3 or a more permissive license ( so we could wrap PDFium as an builder extension like they did, but we can not use their non-GPL wrapper, we would have to make our own). You can pretty much forget about the notion of them being any help to an open-source effort. They don't even openly host the pre-built binaries you need to build from source since then (behind PW protected now). The fact that they immediately removed all the prebuilt installers of the community edition (until public outcry got them to re-upload) seemed like a pretty hostile move in regards to the open source version, despite the claim that they 'fully respect their open-source legacy'.

There are other open xTalk environments which should run native (or near native) on M1. There's several that run on JS. and OpenXION which runs on JVM. I'm not sure what Uli's license for StackSmith is (GPL?), but since that's macOS only (although I do think the 'engine' part, the 'Hammer' script interpreter can be built for other platforms) I'd bet that could be more easily compiled to run on M1 than LCC.

I think OXT should stay open to supporting/using other open-source engines.

I quite like OpenXION and would be interested in helping to further that effort (or any other FOSS xTalk really) by adding a cross-platform GUI framework of some kind (JAVA has a bunch available that could be tapped). I made a quick OpenXION library that replace it's built-in text-based Answer (incl.File/Folder)/Ask dialogs with AppleScript's GUI dialogs, and also did some successful tests in trying to do the same using Python GUI stuff (so it could be cross platform). OpenXION has some nice object oriented syntax, but has (by default) a text/console only interface (like the 'server' version of LCC/OXT, or running the engine with the no-UI CLI option). OpenXION also has cross-platform speech and the 'playSentence' form of the Play command out of the gate (although those features may rely on some part of Oracle's JVM as those features don't seem to work with OpenJDK / non-Oracle builds of JVM).
User avatar
OpenXTalkPaul
Posts: 1485
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Mortal Engines

Post by OpenXTalkPaul »

Here's a new feature that's something I've already had to deal with in builder (working on the HIDAPI wrapper), by exposing internals that were already there. The Builder FFI binding string for internals is simple. This bit of info from latest release notes actually helps clarify these string conversion functions for me. What is still unclear to me (I have yet to look into it much) is the how-to of the syntax for making those language definition modules in order to extend the builder language variant.
Text encoding and decoding
New syntax has been added to allow encoding strings to, and from, a variety of different text encodings.
The encode using <text-encoding> statement encodes a string to binary data, and the decode using <text-encoding> statement does the converse. In both cases, how characters
map to bytes is determined by the specified text-encoding :
ascii : the 7-bit ASCII character set
native : the native character set of the platform ( MacRoman on macOS and iOS, Windows-1252 on Windows, and ISO8859-1 on Android, Linux and Web).
utf8 : the utf-8 encoding
utf16 : the utf-16 encoding in the byte order of the platform
utf16le , utf16be : the utf-16 encoding in little-endian and big-endian byte order
respectively
utf32 : the utf-32 encoding in the byte order of the platform
utf32le , utf32be : the utf-32 encoding in little-endian and big-endian byte order
respectively
In cases where characters cannot be encoded into the specified text encoding, the character is
encoded as ?.

Example:
encode "lorem ipsum" using utf8
decode the result using utf8 into tFooString
They seem to be headed towards making LCS language have Builder variant features. Like array literals or the 'nothing' keyword for examples. Perhaps they'll just merge the two languages eventually.
Post Reply

Who is online

Users browsing this forum: No registered users and 4 guests