OpenXTalk Forums

I'm in the middle of compiling the MacOS engine.
In the "LCCE_PrebuiltBinaries", I'm missing the file:

Thirdparty-e5e050573c226f60acfbb9107c2b4aea853b0cbe-mac-Universal-PIC.tar.bz2

There may be more, but that's what it's told me I'm missing so far.

Can anyone help me locate this file as I can't move forward without it.

I can help, are we looking thru GitHub(s) here?

Not so much.
Those prebuilt libraries were part of the Livecode github, and are required for the builds to succeed. They are needed in the build process to actually create the engine.

Someone very (very) kindly supplied me a google drive link, which meant I could put all the prebuilt libraries in the right places - and that's how we now have a recompiled LCC 9.7 engine for linux (without the registration requirement), built from source.

I'd like to do the same for MacOS, so I need these files (and probably more that I've not encountered yet). - I need a magical google drive link - please if anyone is reading this and wants to PM me a secret link.

This is now behind a username and password wall;
https://downloads.livecode.com/prebuilts
... so nobody will be able to make an updated engine if they do not have these files.

I'm also optimistic that this can be used to generate a native Mac Arm version - Arm support arrived in 9.6.8 (see the release notes here https://tekkieuni.livecode.com/LiveCodeNotes-9_6_8.pdf)
Although 'experimental', page 3 lists the option of running the IDE natively on Arm.
As this sourcecode on github (that I safely have a copy of now, so if it's pulled from existence, It's no problem) - it's actually the last version posted "9.7 dp1" to the community. I'm hoping this has the necessary switches to compile an arm version properly. I'm hopeful.

I also want to see if building the new engine fixes the menus 'properly'.

There's also other reasons I want to produce a recompile.
On page 9 of the 9.6.8 release notes, there's a fix to the systemversion bug properly - so my updated 9.7 DP1 engine code should contain this fix (I hope).

Page 10 of that release notes, goes into more details about all the things that have been fixed:
https://tekkieuni.livecode.com/LiveCodeNotes-9_6_8.pdf

I'm also hoping that this 9.7 DP1 source contains fixes for these:

Fixes a bug in the windows media player control
https://github.com/livecode/livecode/pull/7358

Are HTML5 standalones a valid option now?
https://github.com/livecode/livecode/pull/7330

So, I have very good reasons for wanting the gather all these bits together - with all the files I need collated into one location, the engine can be developed further. Without these prebuilt files, it's kind of dead in the water.

(Also worth noting, the version you download from the Livecode git repo isn't 100% correct - it won't compile the engine with GCC under modern linux.) I've fixed the bash and C++ compiler and linker scripts so you can now build this on modern Linux (ubuntu 22+). I have also been able to pull in all the updated libraries and bug-fixes that this also includes.

Under MacOS, the xCode build project that the GYP tool generates, would not succeed as the version on the git repo is tied to earlier versions of xCode (6.2). This stops a modern JDK from being used. I have also fixed this and can now use xCode 11 upwards, the JDK from January 2024 and python 3 libs, (but I need the prebuilt binaries to fully test compilation success).

By building new engines (without the registration requirement), it should also bring the following bug fixes along to the party:

https://downloads.livecode.com/livecode ... -9_6_5.pdf

The Android engine is now built using version 30 of the Android API, a requirement for new apps submitted to the Google Play store.
mobilePickContact will now request permission to read contact data
Improve speed of appending to large strings and encoding large arrays on Windows
Fix long engine exit time when many loaded fonts and objects/paragraphs are still in memory

https://downloads.livecode.com/livecode ... -9_6_6.pdf

It is now possible for Android apps to be built with adaptive icons
It is now possible for Android apps to specify which other apps are accessible via URL schemes
A new function iphoneSafeAreaInsets has been added which returns the safe area insets of the current device
Saving a standalone for iOS 15 or later now works correctly
Opening HyperCard stacks will no longer cause a crash
Support for the system date and the system time has been added on Android
A stack's rect will no longer become out of sync with its actual position after being moved in the IDE on macOS (BRILLIANT!)
Conversions between global and local co-ordinates are now correct on multi-screen macOS systems. (BRILLIANT - REALLY NEEDED IN OXT)
The performance of the script editor while typing has been improved (Excellent - I reported that Windows felt sluggish doing this)
Scripts which run without locking the screen are no longer slower on macOS Big Sur and later
Default buttons and progress bars will no longer cause unnecessary CPU usage on macOS 10.10 (Yosemite) or later
The byteOffset function will no longer cause incorrect results in some cases nor cause a crash.
Scripts containing accented characters will no longer incorrectly report being externally modified.
Using the print link command when printing to PDF on Windows no longer causes a crash.
A significant memory leak in the browser widget on macOS has been resolved (YESSS!!)
Audio-only players no longer consume excessive CPU when in Edit Mode on macOS Big Sur.
WebGL content now displays in the browser widget when running on macOS 12.x (Monterey)
Building iOS apps using Xcode 13.2 with the iOS 15.2 SDK is now supported
There is no longer a delay when opening the IDE menus on macOS (THIS, might just be what I'm looking for! - seems to suggest an nsMenu rewrite for the engine under MacOS. I won't know until I test this under Sonoma to be sure)

https://downloads.livecode.com/livecode ... -9_6_7.pdf

LiveCode (and for our purposes, OXT) will no longer potentially crash if there is an unsupported system date or time format in use on macOS.
The time taken to clone a stack when the message box is open has been reduced.
Gradients now print correctly when targetting the system printer on macOS.
IDE responsiveness will no longer reduce after the message box has been opened and then closed (memory leak bug I think)
Building a standalone for 64-bit Windows no longer includes and loads unnecessary dialog stacks (great!)
The engine will no longer crash when attempting to access the camera or microphone on recent version of macOS.
Windows will no longer redraw incorrectly when another window is running a visual effect.
The entries of directory syntax in LCB will no longer crash when used on Windows. (these next 3 might interest you Paul)
Other processes can now read from a file currently being targetted by the LCB contents of file operation on Windows
Using the LCB property chunk to access a custom property will no longer cause a crash

https://tekkieuni.livecode.com/LiveCodeNotes-9_6_8.pdf

On macOS, the systemVersion will now return the correct value on all operating system versions (mentioned above, but it's cool!)
AppleScript can now be used to control other applications from both the IDE and standalones on macOS.
The minWidth, maxWidth, minHeight and maxHeight properties now work correctly on stacks which have their scaleFactor set.
The return value of do as applescript is now formatted correctly when running through Rosetta on Apple architecture macs.
Using the image variant of export when the source is not an image object will no longer cause a crash (excellent!)
Updating the screen in a tight loop on macOS will no longer cause memory usage to slowly increase.

edit: This next bit is for Paul, for his Fork of the Livecode source:
The file:
https://github.com/livecode/livecode/bl ... codescript

Line 986, where the 'else' statement begins: This will always create the first run file, and returns 'false' even if it's not there - false as in 'does the registration window need to be shown? = false'

Why make the file if it doesn't need it? Because having this firstrun file there will prevent the registration dialog from showing if you open LCC 9.6.x which would normally look for it, so it'll help those builds too (if you have multiple builds on your system at once).

I tried to submit this to your github fork at:
https://github.com/OpenXTalk-org/OpenXT ... escript#L4

But the changes won't 'stick'. So please copy and paste that code in as appropriate.

9.7 existed when LC stopped open source, so that might mean it does NOT have stuff in the 9.6.8 release.

richmond62 wrote: ↑Sun Feb 04, 2024 4:41 pm 9.7 existed when LC stopped open source, so that might mean it does NOT have stuff in the 9.6.8 release.

I don't know. I'm quite hopeful because I've found a rewritten menu code, and plenty of references to arm build targets in there for MacOS. I won't know until I have the missing prebuilts referenced above.

tperry2x wrote: ↑Sun Feb 04, 2024 4:42 pm

richmond62 wrote: ↑Sun Feb 04, 2024 4:41 pm 9.7 existed when LC stopped open source, so that might mean it does NOT have stuff in the 9.6.8 release.

I don't know. I'm quite hopeful because I've found a rewritten menu code, and plenty of references to arm build targets in there for MacOS. I won't know until I have the missing prebuilts referenced above.

So, I'm firmly on the wrong side of that paywall; just how it is.
We are using what's open-source, right? I mean, like this can't come back to bite us in the...

overclockedmind wrote: ↑Sun Feb 04, 2024 6:21 pm So, I'm firmly on the wrong side of that paywall; just how it is.
We are using what's open-source, right? I mean, like this can't come back to bite us in the...

Everything I'm using is/was and should still be in the LC Community GitHub page. The prebuilts were released as part of the LC community github code, and they were in a subfolder, and had their own read me (which is now empty).

I can tell where they should be as the build scripts reference them still.
I've been supplied the Linux ones already, like I say. Just need the MacOS ones and whatever windows engine build will ask me for.

Without the prebuilts, which the Engine build requires, the github code is very incomplete.

It's... odd, but I forked their entire tree the instant I read the news, right along with a bunch of crap I shouldn't have:

https://github.com/overclockedmind

I also renamed the folders, which it warned me not to do. Whoops.

And yet, that file isn't in my repo anyplace. This leads me to the assumption that it got moved after the news broke of it happening.

Open source software should NOT be behind some paywall; I agree with you there. Kind of a RedHat/RHEL sort of move, in my opinion. I am just watching our collective tail, if you will.

tperry2x wrote: ↑Sun Feb 04, 2024 6:52 pm

overclockedmind wrote: ↑Sun Feb 04, 2024 6:21 pm So, I'm firmly on the wrong side of that paywall; just how it is.
We are using what's open-source, right? I mean, like this can't come back to bite us in the...

Everything I'm using is/was and should still be in the LC Community GitHub page. The prebuilts were released as part of the LC community github code, and they were in a subfolder, and had their own read me (which is now empty).

I can tell where they should be as the build scripts reference them still.
I've been supplied the Linux ones already, like I say. Just need the MacOS ones and whatever windows engine build will ask me for.

Without the prebuilts, which the Engine build requires, the github code is very incomplete.

Oh, I would file that under "[redacted comment]"

This, THIS I believe in, is right, and is why really, anyone who produces a pre-built stack and hands it past themselves, or their org/company, needs to also include a link to their actual stack (I don't believe pictures/models/sounds/assets are included, but IANAL) where the code of the stack can be freely downloaded.

That was not an issue until LCC became GPL licensed. Now, it is.

We might file a request for assistance to https://www.eff.org/ and/or similar. They might offer their aid.

An AI once wrote (about two minutes ago) this for me:

EDIT: Referred to a user then immediately referred to elsewhere, negating this part of my post.

Okay, but let's just have it straight.
Are you here to help, or are you here to hinder?

That's not an accusation. Myself and others are wondering.

You did not answer my question above.

tperry2x wrote: ↑Mon Feb 05, 2024 9:22 pm Okay, but let's just have it straight.
Are you here to help, or are you here to hinder?

That's not an accusation. Myself and others are wondering.

"Others"? Why is this community so prone to secret conversations? The best way to address issues that arise in public discussion is to ask the only person who can answer them.

Now that you've broken the bond of secrecy and asked:

I believe there may be benefit to continuing an open source version of LC's xTalk. I believe the sum of my posts here reflect that.

If that aligns with your goals, you may consider that helpful.

But please keep in mind that if I write something you don't personally like, your disposition doesn't change my intention.

This subthread is tantamount to requiring a loyalty oath, likely off-putting to passersby. I'll leave it to the moderator to determine if it reflects the goals of the project.

As a side note, I recognize that you'd asked another question in the other thread. My not answering it there is not a matter of choice; the thread has been locked.

If there's anything I may be able to help with to further the work of this project, I'll do my best to answer it.

AppleScript can now be used to control other applications from both the IDE and standalones on macOS.

Ah, I remember this one (I think I reported it), this bug was simply that the Engine's AppleScript Dictionary (which only has two entries IIRC) was not being including in the standalone app bundle. If you used an AppleEvent <<symbol>> instead of the corresponding AppleScript keywords then the scripts would still run even without that AppleScript dictionary.

The thing about .wasm is about precompiling more / optimizing the Emscripten Engine, getting that engine to be smaller and faster, it already did rely on HTML5 / WebAsembly.

I think everyone that has macOS and Automator needs to open Automator, tell it to record, do a few things, then switch back to Automator, just to understand how powerful AppleScript is. You might want to tweak the code after you get it, but ultimately? It just performed the steps you performed and THEN wrote an AppleScript that makes those things happen.

It'll automate... well, darn near anything. You just read the supplied dictionaries, and you're golden if you feel the need to tweak the script (to not rely on exact screen coordinates, et cetera.) My only problem is that I go into HyperTalk mode (lol) which is close (they are both natural languages) but they aren't both exactly unique.

Anyway, what's the status of the engines? Still just Linux?

overclockedmind wrote: ↑Sat Feb 10, 2024 12:06 am Anyway, what's the status of the engines? Still just Linux?

Beyond updates to IDE scripts an stacks, pretty much yes...
We do now have tPerry2x updated compiled '9.7' engine (Thanks!) for Linuxes.
And we also have a patch for the macOS binary that is an important crash bug-fix, which allows the Engine to run on up to macOS 14 (Sonoma), but no rebuilt binaries nor Apple Silicon build.
I'm not sure if anyone in the community has tried to recompile Windows version of the engine recently (personally Windoze has been my least favorite OS, but it's still the bulk of PC market so...).
------------
OK one more time in the muck...

Guys. before anyone starts calling up EFF or FSF asking for legal advice, has anyone just asked anybody who could from 'over there' to grant us some access to the missing files, and then promised to never bother them about it again?

At the VERY least we need to know what exactly was in that rather generically named archive file, which I'm assuming was simply pre-compiled builds of the open-source libraries in the repo 'third-party' repo: https://github.com/livecode/livecode-thirdparty.
It makes perfect sense to have already compiled dependencies libraries to save on recompiling time (which can take hella long time).

If that is the case, and they needed to modify any of the FOSS code in someway (like to make it work with their xTalk Engine build process), then I believe under the GPL that should've been released. Now many of these libraries have extremely liberal licenses so they might not be obliged to provide anything if they made no source changes. By the same token, if they made no changes to those libraries then we should be able to get those dependent libraries built from source ourselves (and probably automatically using HomeBrew, MacPorts or similar).

IANAL, Richard is probably right in that they are probably not legally obligated to provide those prebuilt files (though I read something somewhere that they might have to for up to 3 years).

Regardless if they do or don't have an obligation, I do think it seems a extremely dickish move to not have the pre-builts available along with the open-source project that needs them in order to be built, with no easy way of knowing exactly what is missing ( it's a rather generic file name). There's no reason that I can think of why they couldn't have been put up on GitHub (release page allows for large binary attachments). Then to top it off they put up a password wall, essentially hobbling the crowd funded open-source version over night. Why should any developer, hobbyist or not, trust such a company after that sort of behavior?

I'm going to keep digging to see if we can figure out how to get past this hurdle on our own.
I don't want to be made to feel like we're begging for some handout.

Overclockedmind's fork of the pre-built repo has '.a' files which are compiled code, and the contents of the Mac sub-directory suggest that they did modified OpenSSL in some way. I don't know what was in that missing archive, so this might not be helpful with that problem.

OpenXTalkPaul wrote: ↑Sat Feb 10, 2024 1:38 am Overclockedmind's fork of the pre-built repo has '.a' files which are compiled code, and the contents of the Mac sub-directory suggest that they did modified OpenSSL in some way.
Screenshot 2024-02-09 at 8.30.00 PM.png
I don't know what was in that missing archive, so this might not be helpful with that problem.

From what tperry2x (boy I hope I did that right) and I have determined, it would appear that they had released those files (the binaries,) but when news broke of the open-sourcing / "fork it now" event (I read about it on theregister.co.uk) they had decided to a) delete the binaries, and/or b) put them behind a paywall. They WERE there, from my understanding, but not before my botched fork, for preservation purposes.

BTW I know that renaming certain things "broke everything" in a manner of speaking; but from what I understand, the binaries were there before some sly fox deleted them, which would have been even before I jumped in response to TheRegister's announcement.

Somebody correct me if I'm wrong... I'm pretty sure I might (maybe) have some of that goofed.