Struggling to Compile on Linux (VirtualBox, Ubuntu 22.04.5)

[tperry2x]

this was when a lot of the constituent stacks of the IDE stopped being 'real' stacks and became stacks generated on the fly from text-only .livecodescript files.

Yes, that was added on additionally - but the original stack format remains and has not changed, and the functions in the engine that deal with reading these stacks show signs of Metacard references.

[tperry2x]

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.

[tperry2x]

The GPL v3 IS a copyleft license:

The GNU General Public Licenses (GNU GPL, or simply GPL) are a series of widely used free software licenses, or copyleft licenses, that guarantee end users the freedoms to run, study, share, and/or modify the software. The GPL was the first copyleft license available for general use.

So that's confusing. If that's the case, and IF GPL3 is in fact copyleft (why not call it CopyLeft instead of GPL3 then?), then this prevents the LC engine being sold commercially and any commercial enterprise from taking bits of it and using it in a commercial product.

If I offer you a GPL beer, there may be a price on it - but if you'd ask for [it] you'll be provided with a detailed recipe, and you may brew it yourself, change the ingredients, publish it and so on - just be sure to keep the GPL intact, and to grant those permissions to all that receive it!
Beware that the name & the design of the bottle of my GPL beer may not necessarily be under GPL. They still may be copyrighted!

Emphasis mine. So we have asked for all the bits that make up the recipe of the engine, but these are not forthcoming.
We cannot provide those permissions to all that receive it, because we don't have all the ingredients ourselves. Neither do we necessarily even know what parts of the recipe we are missing - because we've not had those permissions passed to us originally. Nor have we ever been provided with a full recipe (please see my note about producing prebuilts for other versions of the engine above).

However, it doesn't just stop there of course. Various libraries and components used throughout the engine have dependencies on other tools that no longer exist online.

Have fun!

May your desk never become wonky.

[richmond62]

wobble.jpg (7.54 KiB) Viewed 1674 times

-

a refined, minimal subset of just what's needed

That presupposes that you have a list of all the things that are present in the legacy engines that are NOT needed.

[tperry2x]

That presupposes that you have a list of all the things that are present in the legacy engines that are NOT needed.

Yes, and if I make an assumption that something isn't used - and remove it:

• Will I annoy someone who wanted that left in?

• Will I break something else by removing it, which I won't find out about until much later?

[richmond62]

Will I annoy someone who wanted that left in?
Will I break something else by removing it, which I won't find out about until much later?

Well, as you are developing what you are developing with no remuneration, and no comeback for users as the thing is open source, I certainly would NOT worry about the first 'fuss'.

Looking at recent events round these parts (I do not know how many times OXT Lite has been downloaded), there are very few people who are using OXT Lite AND reporting blips with it: probably no more than I can count on 2 hands at most.

Perhaps ?

A way to do things is to get a "1.10" with the current engines 'out there', and then STOP development on that.

Then start on your own engine; glueing bits of the IDE onto it as you go.

I, for one, am perfectly happy to develop what I am currently developing with 109/110.

I will download any "OXT X" (as in OXT Xperimental) that you dish up and give it a run, and generally make your life "orrible" with anything I find either wrong or lacking.

[tperry2x]

Well, as you are developing what you are developing with no remuneration, and no comeback for users as the thing is open source...

Well, yes - open source, to a fashion. As far as comeback from users - there's always been plenty of that. However, because people aren't paying anything for it of course - I think people should take that into consideration more. On the other side of the coin, just because you aren't paying for it, doesn't mean you should have to settle for anything that remains broken. I've already fixed lots when you compare OXT Lite to LCC 9.6.3. Things that people forget about like the geometry saving, but to do anything meaningful - I'm increasingly at the point where modifications to the engine are becoming inevitable.

...there are very few people who are using OXT Lite AND reporting blips with it...

That is also true. However, if I was inundated with bug reports - that wouldn't be workable either, as I'm just one person trying to maintain this. If we had 55 users (the currently registered count on here) all making their own requests and suggestions, I think I'd hand OXT Lite back to someone else to carry on with. Not out of spite or any ill feeling. Just that I would not have the time to keep up with requests.

get a "1.10" with the current engines 'out there', and then STOP development on that.

A 1.10 is on the cards (pun intended?), shortly. I'm currently debating whether to release it 'as is' - before I do any alternative windowing stuff, or whether to include that in 1.10. (I'm currently leaning towards leaving the windowing out of v1.10 and saving for a future version).

Then start on your own engine; glueing bits of the IDE onto it as you go.

I kind of have something in place regarding this already, a non-community version, in which I modified the stack format (because I want it specifically to work with that modded engine). It's not designed to be backwards compatible (and I didn't want it to be backwards compatible - because I may add extra features to the engine in future), even though it can of course open MC, LC legacy, and OXT stacks.

I, for one, am perfectly happy to develop what I am currently developing with 109/110.

Okay, all the more reason for me not making any huge sweeping changes in v1.10.

I will download any "OXT X" (as in OXT Xperimental) that you dish up and give it a run, and generally make your life "orrible" with anything I find either wrong or lacking.

That's the thing - I think if I go off on my entirely own direction with a modified engine, as well as the IDE, it'd probably only be to my own whims anyway - so a non-collaborative build (not one I adhered to any feedback on). That's what OXT Lite is for after all, as that's the one linked to discussions here on this forum.

Speaking of which...

[richmond62]

Speaking of which...

'Squeaking' of which . . .

Personally (this might be a synonym for 'selfishly' in this context) as the Boxes in my school are running Xubuntu 24.04 LTS (which, by-ther-way, means support re the system itself, not any software you may be trying to run on it) if I can attract any 'victims' for programming classes with OXT Lite, the "Xubuntu horrors" are only confined to the Message Box, which I do NOT need to introduce the 9 - 17 crowd to anyway: so, HOLD the "funky-monkey" new window furniture for a, possible, 1.11 or 11.69.

Get a 1.10 'out' and then turn your attentions elsewhere . . .

[axwald]

Hi,

So that's confusing. If that's the case, and IF GPL3 is in fact copyleft (why not call it CopyLeft instead of GPL3 then?), then this prevents the LC engine being sold commercially and any commercial enterprise from taking bits of it and using it in a commercial product.

Nope. See 2nd GNU quote. CopyLeft doesn't mean you can't sell it, it just means you cannot 'copyright' it (thus the name) - especially in the sense of selling derivative work as closed source. LiveCode Ltd. may be on a dangerous path here - but, on the other hand, who'll bother to drag an already dying horse before a court? No plaintiff, no judge, as they say.
Actually, maybe that 'Create' is a rewrite to remedy exactly this problem?

So we have asked for all the bits that make up the recipe of the engine, but these are not forthcoming.

I'm not the only one thinking that LiveCode Ltd. never met its obligations coming with collecting a lot of crowdsourced money & advertising with the OpenSource label, AFAIK. IMHO they are actually the 'leechers', not the open source aficionados that brought user numbers, visibility & a quality of support in the forum like never before.
That they failed to capitalize from this huge wave of attention may be because they have proven to be a classic 'Mac software company', that most often went belly up due to ignoring user input, asking for ridiculous prices, and to miss the fact that not only 'not-Mac' users come in thousands for each one Mac user, but that these are accustomed to a far higher software quality, and are not already caught in a 'golden cage'. See '4th Dimension', 'RagTime', 'Canvas' etc. - all outstanding products that failed as soon as they left the narrow limits of the 'golden cage'.

We cannot provide those permissions to all that receive it, because we don't have all the ingredients ourselves. Neither do we necessarily even know what parts of the recipe we are missing - because we've not had those permissions passed to us originally. Nor have we ever been provided with a full recipe (please see my note about producing prebuilts for other versions of the engine above).

My (amateur) advice would be to copy all you have to [somewhere], and to use this then as your 'source repository'. Maybe drop a file mentioning where all this came from, why the original location is close to useless now, and that this is why you're not providing the original sources.
Your obligation is, IMHO, to provide your sources. Not the original ones - a link there (or what remains of it ...) should suffice.

However, it doesn't just stop there of course. Various libraries and components used throughout the engine have dependencies on other tools that no longer exist online.

Seems they absolutely loved to drag in dependency above dependency (starting with ~ V7). And for sure, always assumed we're all hobby coders, would always use the latest version (where the dependencies would be updated), would happily work around all the new bugs because, well, we're all hobby coders & it doesn't matter if our 'app' doesn't work for a few days ...
This is where the serious exodus of the professional coders started. I have to admit, I was too lazy, didn't give up hope quickly enough - this has cost me serious money.

May your desk never become wonky.

Oh, forgot:
May your grass always be brown! :)

[tperry2x]

CopyLeft doesn't mean you can't sell it, it just means you cannot 'copyright' it (thus the name) - especially in the sense of selling derivative work as closed source. LiveCode Ltd. may be on a dangerous path here - but, on the other hand, who'll bother to drag an already dying horse before a court?

I agree, if there's nobody left to complain who cares, with the required legal clout, then there's not going to be any comeback on anything. Doesn't leave much scope for most people to change it and compile it unfortunately.