Page 1 of 1

Funny Observation from across the road. #1

Posted: Mon Oct 21, 2024 7:02 pm
by richmond62
https://file.livecode.com/livecode/10_0 ... 1_rc_1.pdf
-
Screenshot 2024-10-21 at 21.54.47.png
Screenshot 2024-10-21 at 21.54.47.png (151.22 KiB) Viewed 1059 times
-
It seems that one can use an outdated Intel Mac machine to build standalones for an up-to-date ARM Mac.

Obviously they take Linux incredibly seriously:
-
Screenshot 2024-10-21 at 22.01.24.png
Screenshot 2024-10-21 at 22.01.24.png (32.72 KiB) Viewed 1058 times
-
Ubuntu 16.04 (for those of us who cannot count) is 8 years out of date.

Re: Funny Observation from across the road. #1

Posted: Mon Oct 21, 2024 7:36 pm
by OpenXTalkPaul
richmond62 wrote: Mon Oct 21, 2024 7:02 pm https://file.livecode.com/livecode/10_0 ... 1_rc_1.pdf
-
Screenshot 2024-10-21 at 21.54.47.png
-
It seems that one can use an outdated Intel Mac machine to build standalones for an up-to-date ARM Mac.

Obviously they take Linux incredibly seriously:
-
Screenshot 2024-10-21 at 22.01.24.png
-
Ubuntu 16.04 (for those of us who cannot count) is 8 years out of date.
Sure, if we had an Apple Silicon 'slice' to build stand-alone apps with then we could, the process for building a 'standalone app' is not the same as compiling a binary from source, which may also be possible I'm not sure (consult X-code docs).

What they're talking about with 'slice' is an architecture 'slice' from a FAT binary which has multiple architectures binaries merged into one binary. The 'standalone' version of the Engine is an already compiled binary in a pre-made app bundle which our stacks get merged with to produce a new binary app bundle. The macOS part of standalone builder scripts use Apple's dev tool called 'lipo' to trim the 'fat' binary removing architectures that may not be desirable in some way. For example if you have a macOS .app that has a Intel x86 32bit slice, that's not allowed on macOS 10.15+ (the reason SuperCard is crippled) and so you should get a message about that when you try to launch it ( something like "contact the developer for an update"). But that doesn't mean we can't build the 32bit standalone on macOS 10.15+, it just means we can't actually test the output .app on macOS 10.15+ because it's 32bit and and so it won't run. I'm pretty sure if this is still the way it works on LC 10 with Intel 64bit/AppleSilicon 'FAT' binaries. I have no clue how LC "Create" or Cloud works, that may be different.

Re: Funny Observation from across the road. #1

Posted: Tue Oct 22, 2024 4:09 pm
by tperry2x
richmond62 wrote: Mon Oct 21, 2024 7:02 pm Ubuntu 16.04 (for those of us who cannot count) is 8 years out of date.
I've mentioned it before, but here we go again. These are minimum requirements, not maximum supported requirements.

For example, Windows 7 is mentioned on System requirements for LC10 - and that came out in 2009!
winrecs.png
winrecs.png (13.32 KiB) Viewed 752 times

Re: Funny Observation from across the road. #1

Posted: Tue Oct 22, 2024 6:39 pm
by richmond62
Indeed: but thick wazzucks like me get it wrong because 'those people' treat MacOS and Windows dfferently.

So: OXT could at least learn (as they most definitely will not) and give a range of versions as for MacOS and Windows.

Re: Funny Observation from across the road. #1

Posted: Tue Oct 22, 2024 7:50 pm
by tperry2x
richmond62 wrote: Tue Oct 22, 2024 6:39 pm Indeed:... because 'those people' treat MacOS and Windows dfferently.
Well, kind of. Because of the changes in MacOS, dropping 32 bit support, etc - big sur seems to be a minimum now. So no 10.9 > 10.15 support, effectively dropping support for a huge amount of macs there.

Re: Funny Observation from across the road. #1

Posted: Tue Oct 22, 2024 7:50 pm
by OpenXTalkPaul
richmond62 wrote: Tue Oct 22, 2024 6:39 pm Indeed: but thick wazzucks like me get it wrong because 'those people' treat MacOS and Windows dfferently.

So: OXT could at least learn (as they most definitely will not) and give a range of versions as for MacOS and Windows.
So far the range for 9.x on macOS is 10.9+ to current (I wonder why not 'mountain lion'... I skipped over 10.7 & 10.8 back when), assuming the menu-patched binary is used that should include the latest as far as I know (can't test it yet).

Hey Tom did you ever try compiling Mark's repo with his patches on Linux?
I'm interested in the 9.7x web standalone deploy 'wasm' option (which should build on Linux).
I'm hoping that would be smaller and faster than the current 'asm.js' Emscripten html5 engine.

Re: Funny Observation from across the road. #1

Posted: Tue Oct 22, 2024 7:59 pm
by tperry2x
OpenXTalkPaul wrote: Tue Oct 22, 2024 7:50 pm So far the range for 9.x on macOS is 10.9+ to current (I wonder why not 'mountain lion'... I skipped over 10.7 & 10.8 back when),
I'm assuming the need for running 64-bit aware code. Even though 32-bit stuff does run in MacOS all the way up to 10.14, MacOS 10.8 did not understand 64-bit properly. So perhaps that's why the need for 64-bit compatibility and MacOS 10.9, as some libraries are 64-bit only.
OpenXTalkPaul wrote: Tue Oct 22, 2024 7:50 pm assuming the menu-patched binary is used that should include the latest as far as I know (can't test it yet).
I do use that in the IDE with no obvious side effects, it's only in the standalone where I spotted occasional image corruption. It should mean that OXT Lite (and patched OXT) should continue to run until Apple ditch rosetta - aside from the occasional memory segmentation faults that seem to be evident on MacOS 11+ with our 9.6.x engine.
OpenXTalkPaul wrote: Tue Oct 22, 2024 7:50 pm Hey Tom did you ever try compiling Mark's repo with his patches on Linux?
I'm interested in the 9.7x web standalone deploy 'wasm' option (which should build on Linux).
I'm hoping that would be smaller and faster than the current 'asm.js' Emscripten html5 engine.
I did try using Mark's version of the engine, however I couldn't get Mark's repo to compile. It came up with many errors, and did not get past the gyp stage to create the build scripts. I can't find the post now, and the PM Mark sent me with a link - where he kindy sent me a 2.4GB zip of his entire git engine - that seemingly has been deleted now, but I'll see if I can find it and link it back here.

edit: been looking through previous posts, (not much in the way of pleasant reading there), but amongst it all the link to Mark's repo is here.

Try pasting the above link from Mark's github into here to download the folder. (I can't find a better way) without using git command line (which I don't want to install on the computer I'm typing this on currently).

(or this one possibly, which has the download link pre-filled for you)
Or, if that doesn't work - there's this one too... (WHY doesn't github just SIMPLY give you a link to download a folder?)

Anyway, I'm done with github. Have fun.

Re: Funny Observation from across the road. #1

Posted: Thu Oct 24, 2024 1:11 am
by OpenXTalkPaul
tperry2x wrote: Tue Oct 22, 2024 7:59 pm edit: been looking through previous posts, (not much in the way of pleasant reading there), but amongst it all the link to Mark's repo is here.

Try pasting the above link from Mark's github into here to download the folder. (I can't find a better way) without using git command line (which I don't want to install on the computer I'm typing this on currently).

(or this one possibly, which has the download link pre-filled for you)
Or, if that doesn't work - there's this one too... (WHY doesn't github just SIMPLY give you a link to download a folder?)

Anyway, I'm done with github. Have fun.
You can download GitHub repos from their web UI, just not individual folders from a repo. I have a feeling that limitation was designed to prevent people from using it as if it were a free file hosting cloud service (although I'm sure there's people who still do that). For development projects of a normal size (which OXT is not your typical sized project), you would likely want the whole project anyway, but there has indeed been times where I just wanted a particular sub-folder from a Repo. Thanks for the links to those web GitHub downloader web tools.

I see Mark updated that Repo just 4 days ago. I might give compiling the Linux and Emscripten engines a whirl if I can find the time. Hopefully that doesn't require 10s of gigs of Development Tools installed to build like the Mac/Win platforms engines do.

Re: Funny Observation from across the road. #1

Posted: Thu Oct 24, 2024 3:26 am
by tperry2x
OpenXTalkPaul wrote: Thu Oct 24, 2024 1:11 am Hopefully that doesn't require 10s of gigs of Development Tools installed to build like the Mac/Win platforms engines do.
You just need gcc, make and the c++ compiler... and a few other things :lol: (not 50GB of stuff though). I think it's more like about 5GB if I recall correctly.
There's also the other dependencies listed on the lcc linux build info page (copied and pasted here).

build-essential
automake
libtool
gawk
git
curl
flex
bison
libx11-dev
libxext-dev
libxrender-dev
libxft-dev
libxinerama-dev
libxv-dev
libxcursor-dev
libfreetype6-dev
libpopt-dev
libesd0-dev
liblcms-dev
pkg-config
libgtk2.0-dev
zip

An easy way is to do:

Code: Select all

sudo apt-get install build-essential automake libtool gawk git curl flex &&
sudo apt-get install bison libx11-dev libxext-dev libxrender-dev libxft-dev &&
sudo apt-get install libxinerama-dev libxv-dev libxcursor-dev libfreetype6-dev && 
sudo apt-get install libpopt-dev libesd0-dev liblcms2-dev pkg-config libgtk2.0-dev zip
You might have to do a merry dance installing some of these by messing around with your sources lists in your software repositories, as some dependencies are getting hard to find now (depending on the distro you use). For compiling it, I found it worked best using full-fat ubuntu and building up the system with the depencencies from there.

I used a dedicated real machine that I assembled for this, rather than one that mattered. A sacrificial piece of hardware, as compiling will take a while.

That's how I got the LCC9.7.0-DP1 source to compile successfully, using that combination.
If I recall, I had to install some dependencies manually, as they might no longer be in mainstream software repos. can't remember exactly which ones were problematic now off the top of my head.

I'd really like to move away from git, but to be blunt, the whole engine source project needs sorting out from the ground up. Not a simple, easy or quick task at all as I'm sure you are aware.

You'll also find a lot of depreciated variables and structures that gyp generates are now considered invalid, so I had to correct these. My adjusted source is in my mega link off the download page. ("Revised Source" folder) - be aware, it's 4.2GB though Mega DO give you the ability to download a folder of course!

'Helpfully' when at the config stage, the gyp build tool will create the makefiles but with the depreciated variables and syntax because it's now out of date. You can manually correct the output in the build directory as it'll step through telling you what's wrong.
As I say, if you want to grab my amended version, that might save you some work there. I made no other changes. Any adjustments such as removing the registration requirement are listed separately, with screenshots of what I changed, so people can 'follow along', and pick and choose as they see fit, without having to unpick changes from the main source.
Example:
what I changed.png
what I changed.png (85.8 KiB) Viewed 641 times
Also included in that folder, are Mark Wieder's changes to printing on Linux, using CUPS. I've not tested this yet, so my engine that's been in use uses whatever LC originally put in. You may want to include the CUPS mods when you build your version.
I've also got a proposed fix in that folder for the systemversion function, but not being able to compile on MacOS, this is also untested as it really only affects the Mac version of the build, not Windows or Linux in any way.

My linux compile is simply LCC9.7.0-dp1 (the engine code from approx 3 years ago as I write this), as close to 'vanilla' / unmodified state as possible, but with the registration file auto-created as above in the screenshot. No other changes as yet, so it's a good place to start... possibly. Up to you.

If you can identify what Mark has changed with his emscripten / web deploy options, then you could in theory add these to your DPE Engine github? Seems to be multiple version of this kicking about now, not that it really matters I guess.

In the file "[home]/livecode/prebuilt/fetch-libraries.sh", change line 27 to point to your prebuilts folder.
(this is so it grabs the prebuilts locally, rather than from LC's server online - which of course won't work now :roll: ). You'll need to adjust this path to where you placed your prebuilts folder. Speaking of which, you'll find the prebuilts here too.

My aim here was to try and gather together everything anyone might need, rather than having to go hunt for it all across the net and relying on things such as the waybackmachine for old code repositories. (and, if anything gets pulled from a github repo that we don't own of course). I just saved all those read-me's from github too, just in case things... 'disappear' as they tend to do.

Plus, being GPLv3, we have a requirement to keep the source available - however old it now might be, and however much of a headache it might actually cause to compile it.

Also listed on that requirements / "You will need" page should be "An abundance of patience, and a strong drink of your choice". Personally I found drinks containing caffeine worked better than ones containing alcohol. Your mileage may vary :mrgreen:

Thinking about this, it might be an idea to put this in a linux VM of some description - so that when the Linux dependencies no longer exist one day, you can simply spin up the VM to make a recompiled engine. A simpler way to do that of course would be to base it on an old version of Ubuntu, not Ubuntu 22 as I used when I made my recompile. That would probably save you having to mess around with your sources list file in linux too, thinking about it.

Unfortunately that's not going to be an option for MacOS and Windows (due to the OS not being free), so we can't redistribute it. Netherless, It would be good to get a MacOS VM of the build working - with all the versions of xCode pre-installed, but that's going to be a huge VM image. Probably easily over 100GB. Likewise for Windows too.

Off-topic, why was I up at 5:30am posting this? Back ache.
Also, phpBB doesn't understand UK "daylight savings time", so it's an hour incorrect. - that's a common theme. Microsoft can't get their heads around that one either :lol:

Re: Funny Observation from across the road. #1

Posted: Thu Oct 24, 2024 11:53 pm
by OpenXTalkPaul
Good idea having a dedicated compiling machine, I'm sort of in the process of reviving an older (but beefy) rig, that's running macOS 10.14.6 now but I'm aiming to have it triple booting three (or more) platforms on separate drives, with its main purpose being to compile code (I did install some of music recording stuff, it's my garage computer), oh and it also will occasionally act as my media server.

So for Linux I had planned on my go-to Ubuntu Studio (because I want to get more into Linux Music/Audio stuff)

I think Emscripten engine could be compiled to web assembly in addition to the older 'asm.js', like the wasm patches Mark pulled-into his build, but independent of compiling the rest of the engines.

Here's the Emscripten build instructions, they're fairly old now though.
https://github.com/livecode/livecode/bl ... cripten.md
Here's a page on how to compile C++ to Web Assembly with the Emsscripten SDK.
https://emscripten.org/docs/compiling/WebAssembly.html