richmond62 wrote: ↑Sat Jan 04, 2025 1:37 pm
how, in 2013 could you look at ALL the code, but now, apparently, you cannot?
You could look at all the code then (because the prebuilts were not behind a password protected wall like they are now), but you might not have necessarily been able to compile it back then - seeing the code and compiling the code; that's another matter altogether.
Plus, you can see the issue Foxtrot47 has with the python dependency in post 1 of this initial thread. Back then, Python 2.0 (released in 2000) has had a long lifespan (2.7.18 lasted all the way up to 2020) - this means there's a huge amount of projects that can still rely on Python 2 dependencies behind the scenes. Most have been updated to use Python 3 I'd have thought by now.
The point being, in 2013 - Python 2 was available and was current - and was readily available without having to jump through hoops, swapping in unsigned libs with a modified sources file. You didn't have to play silly-so-and-so's because Python 2 was at that time used by everyone. Now, the use of Python 2.x is discouraged (doesn't even appear in the package lists of some distros anymore) and has been replaced by Python 3.x.
It's not simply a case of upping version numbers in the compile scripts for the engine, as a lot of keywords and terminology has changed between python 2.0 and 3.0 - in fact, some of the ways it handles variables and functions have changed to such an extent that anything that used Python 2 has to go through a process of correcting and adjusting compile scripts to factor python 3 in.
That's just Python. The engine pulls in (and uses) many different technologies and libraries at compile stage. There's many things that have moved on that it utilises: Cygwin (windows), Visual Studio Libraries, Microsoft Speech SDK, Perl, SQLdbLibraries, xCode SDKs (Mac), - and more (Cygwin required components adds about 3GB of extra plugins required for the compile to succeed). Visual Studio downloads about 8-10GB of required compile tools needed to compile the engine. Under MacOS, you need multiple SDKs to support each version of MacOS you intend it to run on.
Then there's countless libraries such as libSkia (to do with rendering and processing of drawing graphics in-engine). These in turn have dependencies on other libraries, which may also have sub-dependencies on other things... and so it goes on.
It's a hugely complex beast.
Now, if one of those things changes (and of course they mostly all have - seeing that this source is designed to work with everything else that was around in 2021), invariably it means that a lot of it is broken. No problem you might say, I'll just download all the old versions of everything so it matches in what the compile script was looking for in 2021. Good luck, because a lot of it is just no longer online anymore. This was the battle I had with it when compiling for Linux and Windows - I had to modify and point it towards all updated libraries. Some it found, some were hard-coded to a specific old versions of libraries and plugins that just aren't available now.
As I mentioned on here though, I really think you'd have a better chance rewriting the engine. It would certainly make more sense in places. To start afresh with a refined, minimal subset of just what's needed, and update it with modern APIs - making it available to be run in a platform-agnostic target like a browser or a web-app.
(But then, I've pretty much just described Livecode "Create"). Whereas what I'd like to do is, as above: start afresh with a refined, minimal subset of just what's needed, and update it with modern APIs
BUT without any registration or user lock in. I may only achieve that with the use of an AGI - which brings me onto
what I'm going on about here.
