Struggling to Compile on Linux (VirtualBox, Ubuntu 22.04.5)

[foxtrot47]

I'm struggling with my 4th attempt (over 2024) to build a Virtual Machine that can compile the Linux version of LCCE/OXT using the build instructions in the Mega Repo, along with different posts on here. I'm targeting a VM so I can move it between different machines more easily. Every attempt has hit a unique dead end, and this one is no different:

Code: Select all

oxt@oxt-dev:~/livecode$ make config-linux
travis_fold:start:config
CONFIGURE
./config.sh --platform linux-x86_64
CC=cc
CXX=c++
AR=ar
LINK=c++
OBJCOPY=objcopy
OBJDUMP=objdump
STRIP=strip
LD=c++
gyp --format make-linux --depth . --generator-output build-linux-x86_64/livecode -DOS=linux -Dbuild_edition=community -Duniform_arch=x86_64 -Dtarget_arch=x86_64 -Djavahome=/usr/lib/jvm/java-11-openjdk-amd64/bin/java
fatal: not a git repository (or any of the parent directories): .git
gyp: Call to 'git -C . rev-parse HEAD' returned exit status 128.
make: *** [Makefile:102: config-linux-x86_64] Error 1

My first thought was to locate the git call and see if I could work around it, like so:

Code: Select all

grep -r "git -C"
prebuilt/scripts/lib_versions.bat:FOR /F "tokens=*" %%x IN ('git -C ../thirdparty/ log -n 1 "--format=%%H"') DO SET Thirdparty_VERSION=%%x
config/version.gypi:					'git_revision': '<!(git -C <(DEPTH)/.. rev-parse HEAD)',
config/version.gypi:					'git_revision': '<!(git -C <(DEPTH) rev-parse HEAD)',

So I backed up the config/version.gypi file and tried removing the conditions that were calling the git command. Unfortunately, that just gave me a new GIT error that seems to be sending me down a rabbit hole.

Code: Select all

make config-linux
travis_fold:start:config
CONFIGURE
./config.sh --platform linux-x86_64
CC=cc
CXX=c++
AR=ar
LINK=c++
OBJCOPY=objcopy
OBJDUMP=objdump
STRIP=strip
LD=c++
gyp --format make-linux --depth . --generator-output build-linux-x86_64/livecode -DOS=linux -Dbuild_edition=community -Duniform_arch=x86_64 -Dtarget_arch=x86_64 -Djavahome=/usr/lib/jvm/java-11-openjdk-amd64/bin/java
gyp: Undefined variable git_revision in engine/engine-common.gyp
make: *** [Makefile:102: config-linux-x86_64] Error 1

I'm not sure why GIT is even necessary for compilation, as I'm not pushing this out to a repo or anything (and I don't use GIT personally.)

I'm not sure what to do next, and I'm hoping someone could point me in the right direction. My intention is to clean up the VM, archive it on my web site (for everyone's benefit), and use it in different personal projects (aka, diversions).

Also, am I doing this the hard way? Or is setting up the build environment still a very difficult task overall?

Again, thank you for any guidance you can offer.

If this helps, here's my install log (a mix of notes and bash commands):

Code: Select all

Installed Ubuntu Desktop 22.04.5 (Minimal Install) onto a new VirtualBox VM.
Updated & Upgraded all installed packages
Restart
Installed VirtualBox Guest Additions
### Installer complaint: unable to compile kernel modules
sudo apt install gcc make perl
Restart
Installed VirtualBox Guest Additions -> Kernel Modules Installed
Shut Down
Enabled Shared Clipboard & Drag'n'Drop for VM
Shared my Downloads folder with VM, copied livecode-git-dump-fixed.zip, LCCE_PrebuiltBinaries-20240127T130653Z-001.zip

Extracted livecode-git-dump-fixed.zip, moved "livecode" folder to Home directory.
Extracted LCCE_PrebuiltBinaries-20240127T130653Z-001.zip to Desktop.

Executed:
	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
		E: Unable to locate package libesd0-dev
		
		sudo nano /etc/apt/sources.list
			### Added to the end of the list
			deb [allow-insecure=yes] http://us.archive.ubuntu.com/ubuntu/ xenial main universe
			deb-src [allow-insecure=yes] http://us.archive.ubuntu.com/ubuntu/ xenial main universe
		sudo apt update
		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

### Success! Commented out the Xenial repos before continuing
sudo apt update

### https://www.openxtalk.org/forum/viewtopic.php?p=9307&hilit=libesd0+dev#p9307
Installing Python 2.7.18 
	cd ~/Downloads
	wget https://www.python.org/ftp/python/2.7.18/Python-2.7.18.tgz
	tar -xf Python-2.7.18.tgz
	cd Python-2.7.18/
	sudo apt install build-essential pkg-config \
      libbz2-dev libffi-dev libgdbm-dev liblzma-dev \
      libncurses5-dev libreadline6-dev libsqlite3-dev \
      libssl-dev tk-dev uuid-dev zlib1g-dev
	./configure --enable-optimizations \
              --enable-shared \
              --enable-loadable-sqlite-extensions \
              --prefix /usr/local \
              LDFLAGS=-Wl,-rpath=/usr/local/lib
	make
		### Failed due to libftp ssl eerors.
	make -i ### Running ignoring tests
		### Failed. Same reason.

## Failed to install Python 2.7.18. Trying the install with pyenv (Python Version Management)

	curl https://pyenv.run | bash
	export PATH="$HOME/.pyenv/bin:$PATH"
	eval "$(pyenv init --path)"
	eval "$(pyenv virtualenv-init -)"
	pyenv install 2.7.18
	pyenv global 2.7.18
	python --version
		Python 2.7.18

## Apparently this file has to be marked as executable
chmod +x config.sh

VirtualBox Snapshot Taken

### Python not reporting installed. Followed install instructions from: https://github.com/pyenv/pyenv?tab=readme-ov-file#1-automatic-installer-recommended

	curl https://pyenv.run | bash
	echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc
	echo '[[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc
	echo 'eval "$(pyenv init - bash)"' >> ~/.bashrc
	
	echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.profile
	echo '[[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.profile
	echo 'eval "$(pyenv init - bash)"' >> ~/.profile
	
	echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bash_profile
	echo '[[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bash_profile
	echo 'eval "$(pyenv init - bash)"' >> ~/.bash_profile
	
	exec "$SHELL"

### Java SDK needed now.
sudo apt update
sudo apt install openjdk-11-jdk
export JAVA_SDK=/usr/lib/jvm/java-11-openjdk-amd64
	## Manually added to ~/.bashrc (because at this point, my brain hurts.)

Restart
### Posting error on Forums, because I'm out of ideas.

[tperry2x]

For some silly reason, the compile script insists on the code coming from a git repo and has a check to ensure the code looks like a git download. Because I don't use GIT syncing (I won't sync my changes back up to git, which I've mentioned in multiple various grumblings regarding my opinion of GIT )

Anyway, I had to download the repo using the git command line tool. It kept erroring out - and on each attempt, it didn't understand where it had got to with the download - so annoyingly, each download attempt of the source for the engine had to be reattempted each time.

It took ages, so the first hurdle (at least for me), was getting it 'out' of GIT. After at least about 20+ attempts of this, I finally managed to grab a complete copy of it. Frustrating.
From there, I could make local changes unimpeded by GIT, and I used a basic text editor for this. (My thinking was as little interference from any programs as possible). There was a lot that needed correcting, as a lot of keywords were depreciated (it seems like the source is hugely out of date for the compiler).

I also changed the source to pull in the prebuilts from a local folder, rather from some obscure remote location on LCs server (which is now inaccessible - essentially making the source shown on github incomplete).

The compile on Linux (and windows) also requires Python 2.7 to be installed. There are various ways you can do this. I had to edit my sources.list on linux to include unsigned/'untrusted' sources (although I could vouch where they came from, so 'trusted' in a logical sense). The compile routine will fail if Python 2.7 isn't installed, and if only v3 (and above at a later date) are installed, it'll fail with an error that Python isn't available (when it is). The configure and compile scripts need redoing with Python 3 in mind.

The only real change I made of note, has been to disable the registration check. It's essentially changing a variable from false to true. That's all. But changing that one variable means an entire recompile. This illustrates the issue we have with the engine, being as it is. With things coded inside the engine like they are, if you want to change the simplest thing, you have a huge wait for compile time - but if you make an error, it can be a slow process to test anything out.

We take for granted just how relatively easy it is to write anything in a stack, and see the results almost instantly. Then being able to debug in realtime. However, going back into C++, it's a reminder how slow a process dev tasks can be with the edit>compile>test>debug (repeat) situation. I would be keen to get as much out of the engine as possible, into at least a library that can be read (allows for easier editing), but the downside of that is a noticeable speed decrease - which is why I think initially my first attempt at a windows recompile was laggy - because it was trying to reference something that wasn't properly included in the engine as it expected it to be.

There's a lot of legacy cruft, and a lot of things that would take a very skilled C++ programmer to sort out. The Mac version even more so, as that also has a lot of other issues to deal with, aside from not really having any developer notes on it.

It's like being handed a big tub of lego, a picture of what you need to build. No instructions, then to add to the fun - someone turns the lights off and expects you to build it in the dark. Oh, and some vital pieces are also located elsewhere which you'll have to go hunt for. That's the best analogy I can come up with (and the most polite version).

I used a real machine (bare-metal) linux install, to compile this on at the time. After that worked, I backed it up to a clone image (using rescuezilla) - I could restore this into something like a virtualbox image, but it would be about 17GB with all the compiler dependencies (as I updated all the libs at the time too, so they were not out of date) - so not something that can be transferred easily I'm afraid.

[tperry2x]

If I was a skilled C++ programmer, rather than a newbie, and if I was completely attempting to sort the engine source code out - I would attempt the following:

• Get rid of the git requirement check

• Separate the engine source into three distinct folders, and remove the GYP requirement. (Rather than having gyp attempt to smash the code together to create individual platform folders at a later stage).

• I would like to externalise as much as possible, so it's not 'locked away' (for want of a better term) in the engine. So that a change does not require a recompile. This would be ideally loaded into ram as a "common-library" at engine runtime, and being pre-loaded into RAM, should offset (improve?) the responsiveness of engine tasks.

• De-junk a lot of the engine. As well as removing a lot of stale code, and functions that are included for "supercard compatibility", and hardcoded subroutines dealing with Audio/Video playback. (Restoring the 'hypermedia' aspect to the IDE).

• Remove the Python 2.x requirement, and update the config and compile scripts to use Python 3.x

• Sort out the numerous memory access violations on MacOS. Currently my Linux and Windows builds of the engine compile without any warnings. Not so on MacOS.

• Change the prebuilts so NOTHING is referenced externally - grab everything you could possibly need into a folder at compile time, calling this folder "required-dependencies" for each platform. That way, if something goes 'offline' at some point on some distant server, it does not stop the engine being compiled.

• Rewrite the documentation fully, to give any new users a chance of actually compiling it. Making all steps clear. This makes the project open-source again. In my view, at the moment, the engine may as well be closed-source - because it's not exactly something that any user can jump-into and tweak. It's obscure at best.

• Make the compile and build processes self-correcting. If a required item isn't found, rather than erroring and stopping, loop back to the download subroutine and grab what's needed. Then resume where it got to.

At which point, I honestly think it would be a simpler task to start writing the engine afresh.

[richmond62]

The idea that the IDE is dependent on Python is hilarious considering the 'rubbishing' of Python that has gone on over the years.

[foxtrot47]

It's like being handed a big tub of lego, a picture of what you need to build. No instructions, then to add to the fun - someone turns the lights off and expects you to build it in the dark. Oh, and some vital pieces are also located elsewhere which you'll have to go hunt for. That's the best analogy I can come up with (and the most polite version).

Thank you, tperry2x, for the analogy. It makes perfect sense, especially as the code-base ages.

The only real change I made of note, has been to disable the registration check. It's essentially changing a variable from false to true. That's all. But changing that one variable means an entire recompile. This illustrates the issue we have with the engine, being as it is. With things coded inside the engine like they are, if you want to change the simplest thing, you have a huge wait for compile time - but if you make an error, it can be a slow process to test anything out.

You've hit on a big reason why this was my 4th attempt: I want to force the enterprise validation functions to always return "true" so I can use the extensions/widgets/libraries I purchased from mothership a few years back. I tried to use LC Builder to create an override of sorts, but the internal nature of the license check means source recompilation is required.

Yes, this goal is a license violation, but I don't care anymore. I'm not making commercial software. Plus, the mothership hasn't exactly kept all of their financially-backed promises over the years, so I don't see a reason why I should play fair either. I just want to use what I "purchased", without feeling like I was "renting" all along.

I used a real machine (bare-metal) linux install, to compile this on at the time. After that worked, I backed it up to a clone image (using rescuezilla) - I could restore this into something like a virtualbox image, but it would be about 17GB with all the compiler dependencies (as I updated all the libs at the time too, so they were not out of date) - so not something that can be transferred easily I'm afraid.

Well, we're miles apart in terms of our understanding of C++ development, so doing this would be completely up to you. I can setup a private FTP account to accommodate, if you want to go down that road.

• De-junk a lot of the engine. As well as removing a lot of stale code, and functions that are included for "supercard compatibility", and hardcoded subroutines dealing with Audio/Video playback. (Restoring the 'hypermedia' aspect to the IDE).

• Sort out the numerous memory access violations on MacOS. Currently my Linux and Windows builds of the engine compile without any warnings. Not so on MacOS.

I know many on the forum want to keep the multi-platform/multi-format compatibility of LCCE going forward in OXT, which is fine (not to mention admirable). However, I don't share that desire. I'd much rather focus on stripping out most, if not all of the multi-platform code, and just make a Linux-focused IDE & Engine. I don't see much point in re-hashing that topic again. (You can search my posts if curious.)

A lofty goal, yes, but I've had good luck with that approach on other projects in my past.

At which point, I honestly think it would be a simpler task to start writing the engine afresh.

You're probably right.

Thank you, again, for taking the time to help myself and others to understand the current state of the engine. If you folks put up a patreon, kick starter, tips, etc., I'd be happy to donate.

In the meantime, my local take-and-bake pizza place is hiring, and I miss my pizza making days

[OpenXTalkPaul]

The reason it's all tied together with git(hub) is because LC team was (and probably still are) using a system to do automated builds. And they had multiple repos (for some reason), keeping the Engine(s) source in one repo, the IDE (the scripts and stacks) in another repo, and third party libraries in yet another with additional files (the 'pre-built' binaries of those 3rd party libraries and some externals from Monte and Trevor) being pulled in from other locations (including an LC server that is now behind a password wall). You may see these links in the repos labeled 'sub-module pointer' (or something like that, which are sort of like Git version of an Mac 'alias' or Windows 'shortcut').

[OpenXTalkPaul]

Yes, this goal is a license violation, but I don't care anymore. I'm not making commercial software. Plus, the mothership hasn't exactly kept all of their financially-backed promises over the years, so I don't see a reason why I should play fair either. I just want to use what I "purchased", without feeling like I was "renting" all along.

Do what you want, but obviously any successful compiling with some sort of commercial license circumventing can't be shared like that (publicly). That said, for extensions you might not need to hack + recompile the engine, extensions are like externals, not part of the engine. The compiled bytecode is 'tacked on' by the engine on the fly. Also there's already a module that has to do with validating extensions licenses, although I'm not really sure how that worked because I never even saw it in use, I mostly only ever used free extensions (mostly the ones I coded myself) or tried out a few that came pre-installed with the Indy edition (which I 'rented' for a year).

If you really needed to use those extensions, an (inconvenient) option is to 'Time Travel' your computer back to when your license was valid

[richmond62]

an (inconvenient) option is to 'Time Travel' your computer back to when your license was valid

My Fifth-best computer running MacOS 9.2 is set in 2001 as it contains quite a few commercial software items I was given licences to by the U.A.E. University in Al Ain, and one of them (Fontographer) I still use on a fairly regular basis. Other applications get used less regularly, but they are useful and it seems daft to lose them: after all I got those licences instead of extra pay, for which I worked.

And, face it: the "rent my software" thing stinks to high-heaven.

I don't know whether any of those applications attempt to phone-home as my G3 iMac can only access the internet via a LAN cable (which languishes in a box amongst all my other 'antiquated crap').

So: go down to your garage, lobby press, junk room, old camper van, cow shed, or wherever you keep your old (-ish) computers and dedicate it to your copy of LC that has a licence expiring in 2020 . . .

Actually the ONLY reason I keep using the G3 iMac (which is only a pain-in-the-bum insofar as it has a fairly mini screen) instead of my G4 Mac Mini is that I have never been able to get that "Classic-Only" thing to work on the Mac Mini; and the emulator for MacOS 9 with MacOS Shuriken is a bit on the clunky side.

[richmond62]

Interestingly enough, one of my multiple personalities downloaded a trial version of LC 10.0.1 rc 3 today and noticed that THESE items in the plugins folder:
-

Screenshot 2025-01-03 at 11.59.08.png (75.47 KiB) Viewed 2655 times

-
Were NOT present in the plugins folder of OXT Lite 1.09.

Copying them into OXT Lite 1.09 they ALL showed up:
-

Screenshot 2025-01-03 at 12.03.11.png (212.76 KiB) Viewed 2655 times

-
While some of them may be copyright:
-

Screenshot 2025-01-03 at 12.10.18.png (140.57 KiB) Viewed 2655 times

-
so not Open Source, I am not sure if there is some legal restriction on our using them.

[tperry2x]

...so not Open Source, I am not sure if there is some legal restriction on our using them.

Excuse my naivety, but I don't know if Frederic Rinaldi is still alive (of course, I hope so - but haven't been able to find out for sure).
I assume it would be up to him if we were allowed to include it. I remember using his XCMDs and XFCNs in Hypercard, and that was a long time ago!

Extra naivety points for me: What about taking something that IS open source, and putting a restriction on it that it can't be used in a commercial offering?

[richmond62]

Extra naivety points for me: What about taking something that IS open source, and putting a restriction on it that it can't be used in a commercial offering?

I jalouse that's the whole point of CopyLeft:

https://en.wikipedia.org/wiki/Copyleft

[tperry2x]

Well, as life is short, I wanted a quick version (without having to go to on a law course at a university), so:

Can you explain CopyLeft in Human readable (non-legal terms)?

ChatGPT:
Certainly! Copyleft is a way of making sure that software (or other creative works) remain free and open for everyone to use, share, and improve. Here's how it works in simple terms:

• Free to Use and Share: Copyleft lets you use, copy, modify, and share a piece of software or content as much as you like, often for free.

• Share Alike: If you modify the original work or create something based on it, you must share your changes under the same open terms. This means you can't take a Copyleft work, improve it, and then make your version private or restrict others from using it.

• Keeps Things Open: It ensures that the freedoms provided by the original creator are passed on to everyone else. This prevents people or companies from turning open work into closed, proprietary versions.

Example:
Imagine a recipe that says, "You can cook this dish, change it however you want, and share it with your friends. But if you share your version, you have to include the recipe and allow others to modify and share it too."

Copyleft is most commonly used in software with licenses like the GNU General Public License (GPL). It’s a way to encourage collaboration while protecting the openness of shared creations.

[tperry2x]

The important bit I pick up on:
It ensures that the freedoms provided by the original creator are passed on to everyone else. This prevents people or companies from turning open work into closed, proprietary versions.

(emphasis mine) - so if OXT was CopyLeft licensed, it would prevent a company from selling any open-source work as part of that commercial offering? - The thing is, OXT is GPL3 Licensed, not CopyLeft - so there's no way to prevent that?

If I'm reading GPL3 correctly *no guarantee (and probably quite the opposite):
GPLv3 includes explicit patent protection clauses, which state that if the program is distributed, any patents the distributor might have that apply to the software must be licensed to the recipients.

So does that make Livecode the "Distributor", and make the OXT project the "Recipients"? - At any rate, sounds like we should have the same rights over the program that Livecode do. Likewise, any "Recipients" downloading OXT should have the same rights over the program that WE do, AND that Livecode originally did?

If that's the case, (and is what I was banging on about when I kept mentioning the prebuilts), any "Recipient" (anyone directly involved in the OXT project, AND any end-user downloading the software and modifying it) should have the same access and same availability to all the files used to generate the Livecode engine that Livecode did?

That would mean all the prebuilts for all and any previous versions.
Try to build version 7 or version 8 of the Livecode engine, and you are met with needing an entire different set of prebuilts than the ones provided to us in version 9 of the engine.
We should therefore have all and any notes related to the compilation of the engine, including any internal notes and requirements needed to compile it on MacOS - just knowing what version of MacOS each engine version is supposed to be compiled on would be a start.

... but not just for us, for ANY user downloading the github GPL3 archive of the engine...

Now, let's assume that LC decide to delete the github repository altogether. This nullifies the license terms, as then there is absolutely no way we can ever provide everything that is required to fulfil the GPL3 requirement (as it stands, we can't provide everything to all users, for all versions of the engine: because we simply don't have it all) - so we currently can't fulfil the GPL3 requirement ourselves. This is my argument that the engine (and what we have inherited) should logically be reclassified as CopyLeft now.

[tperry2x]

So if I use the analogy ChatGPT gave me, what we actually have is:

Imagine a recipe that says, "You can cook this dish, change it however you want, and share it with your friends. But in this case you don't have all the ingredients required to make your version, and you can't provide the recipe to others because you don't have it either."

At that point, you might wonder how your version is ever going to be any good?
That's where we are now.

[richmond62]

I do NOT think LC have actually adhered to the GPL3 licence: something I have stated before.

LC should have given us ALL the ingredients and the recipe: but they seem not to have done that.

Maybe Paul (who seems to have more clout than us) could point this out to LC, and ask them for the missing bits.

As far as I am concerned LC have ALWAYS played fast and loose with their customers and users.

[tperry2x]

I do NOT think LC have actually adhered to the GPL3 licence: something I have stated before.
LC should have given us ALL the ingredients and the recipe: but they seem not to have done that.

Well, until we can remake it (or find someone dedicated enough and equally highly skilled enough) to set about creating a totally revised engine (or rather just a rationalised engine) - We will have to keep plodding along with what we have.
(finding inventive / bizarre ways of dodging the next bug that's raised by systems updating, and the engine staying static).

If we assume the engine, as we know it, is from about 1991 - with the Metacard foundation, this puts it in the same timeframe as the Linux Kernel - which also started development in about 1991. The difference being the Linux kernel is continuously being added to, revised, recompiled and bug fixed.
We can't say the same about our engine from the same time period, as much of it still has the Metacard stuff embedded deep within. I've discovered a lot that could probably be pruned, but if we think the IDE is an interwoven mess, the engine is probably 10 times more than that from what I can tell. If I were to start deleting anything, I'm sure there'd be all sorts of issues.

It seems to me we are rolling along in our car without enough puff to climb the hill that's in front of us. We are fine until the next update to a mainstream system (such as a windows 11 or MacOS update) looms up in the distance and means we don't have a chance of getting over that particular hill. (I think the xUbuntu recent update is absolute proof of this). At which point, the choices are to put the brakes on and declare compatibility stops at this point (which seems like what happened to Supercard - they reached an intel-shaped hill they couldn't overcome with a PowerPC engine). The other choice is to jump into something else with a better engine - something that can get over the update hill and down the other side.

The problem is, there's a distinct lack of a something capable to jump into with a replacement engine that will get us there. All other engines I've seen are just missing parts, and the rest are already consigned to history. The sad truth is, who's going to spend 5+ years of their life, making a capable engine, when there's no financial reward in it for them? No skilled C++ developer works for free - not when they have projects they could be working on that will pay the bills.

The only exception would be a highly-skilled C++ programmer, someone who has an outright passion for the xTalk / Transcript / HyperTalk language, and who wants to see it endure: so much so they are willing to work for free. For 5+ years (or however long it takes to make an equivalent engine without the bugs).

I'm not sure such a person exists.

What are the alternatives? Hope that AI reaches the point of singularity, so I can just ask it to create me an xTalk engine - at which point I'm sure it's quantum compiler could spit one out in under a couple of minutes. But at that point, what do you actually ever need to write a single line of script for ever again anyway? We aren't there yet, but we will be.

[axwald]

Hi,

so if OXT was CopyLeft licensed, it would prevent a company from selling any open-source work as part of that commercial offering? - The thing is, OXT is GPL3 Licensed, not CopyLeft - so there's no way to prevent that?

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.

Preamble
The GNU General Public License is a free, copyleft license for software and other kinds of works.

It's a common misconception to see GPL software like free beer:

When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things.

Bold by me.

If I give you a free beer, you don't have to pay, and you can drink it. But that's all - quite sure someone will have protected (copyrighted) the recipe, the name & the design of the bottle.

If I offer you a GPL beer, there may be a price on it - but if you'd ask for 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!

Have fun!

[richmond62]

Thanks for the clarification.

[richmond62]

If we assume the engine, as we know it, is from about 1991

I do not feel that is either accurate or fair (not that I give a damn about being fair to certain parties), but some time back (possibly at the LC 6/7/8 transition: happened in 2013) there was a considerable amount of 'hullabaloo' about refactoring.

The fact that quite a lot of 'something' went on can be seen in the fact that (as far as I am aware) 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.

https://livecode.com/extending-the-refa ... roperties/

Worth a read!

[richmond62]

https://web.archive.org/web/20110809000 ... ecode.com/

LiveCode Community is an Open Source application, this means that you can look at and edit all of the code used to run it, including the engine code. Of course, you do not have to do this, if you just want to write your app in LiveCode there is no need for you to get involved with the engine at all. You write your app using LiveCode with the English-like scripting language, and our drag and drop interface. Fast, easy, productive and powerful.

Emphasis is mine.

So the question is, how, in 2013 could you look at ALL the code, but now, apparently, you cannot?