Where store my general use scripts library?

[FourthWorld]

Today I tried to make that stack a script-only stack, because that's what it should be, basically.

"Should be"? Why?

Do you have a multi-developer team whose workflow includes dependencies on version control tools designed for other languages?

That's why script-only stacks were invented.

[Fjord]

multi-developer team (…) That's why script-only stacks were invented.

That's an opinion. Or did you see that mentioned in a document from the LC team?

Not many people around here know for sure (doc…) the answer to my question: can I use script-only stacks as plugins?. I asked in case someone here was able to point to some document, blog, whatever, from the LC team.

BTW, I see no link between script-only stacks and multi-developpers teams…
One might think of other virtues of script-only stacks; from the top of my mind: smaller space, ability to use any text editor… which have nothing to do with multi-developer teams.

[Fjord]

"Should be"? Why?

OK, I take back that a plugin "should" be a script-only stack.

[FourthWorld]

multi-developer team (…) That's why script-only stacks were invented.

That's an opinion. Or did you see that mentioned in a document from the LC team?

I was a contractor with LiveCode before v1.0. I was the LC Community Liaison during the open source years (2013-2021). I've read pretty much every post to the LiveCode mailing list since it was started just after the turn of the century, including many discussions of version control.

Yes, what I write are opinions. But they're reasonably informed opinions.

Not many people around here know for sure (doc…) the answer to my question: can I use script-only stacks as plugins?. I asked in case someone here was able to point to some document, blog, whatever, from the LC team.

I know from direct firsthand experience that the engine can open stack files, and once opened they behave just like any other stack file.

It sounds like the IDE script that loads files from the Plugins folder needs to be enhanced to include a search for files with that extension.

To confirm try renaming the file to use the "*.livecode" extension. If that works we've narrowed it down, and you might consider filling a bug report on that:
https://quality.livecode.com/

Given how few have used script-only stacks as plugins it's understandable that they haven't seen this earlier. But it should be simple enough to fix.

BTW, I see no link between script-only stacks and multi-developpers teams…

I've never seen the corn fields of Wisconsin, because I've never lived there. But when friends who do live there tell me about them, I have no reason to doubt what they're telling me.

One might think of other virtues of script-only stacks; from the top of my mind: smaller space, ability to use any text editor… which have nothing to do with multi-developer teams.

The additional space is negligible (less than 1k IIRC; you can test it by just creating a new stack with nothing in it and saving it). If you need any persistent GUI elements or custom properties, those would require scripts to instantiate, which are generally much larger than their finished binary object form.

Which script editor do you use? Some have plugins available which will let you use them with scripts stored in binary stack objects as well.

As for teams needing version control...

TL/DR:
https://github.com/livecode/livecode-ide

More detailed explanation offered because some find it useful to know the history of key developments in the engine:

Version control is a classic problem of computing, as old as team development. There are too many ways to screw up large code bases with many developers, and too much difficulty merging portions of a project with other portions of a project.

For many years there were a great many options for version control. There still are, but one has emerged as the clear leader: git, an open source package developed by the Linux kernel team to help them manage incoming changes from hundreds of core developers and thousands of contributors around the world.

For git to become truly popular required a good interface, which eventually emerged in the form of GitHub. Most public code is stored and worked on there, though GitLab has sprung up in recent years as an alternative which more fully embraces open source ethos and is quite popular as well.

The LiveCode engine is more than half a million lines of code, mostly C++. There's no practical way to manage it without a robust version control system, and git fits the bill quite nicely.

But with LiveCode's IDE being comprised of stack files, their binary format afforded no option for taking advantage of git's text-focused tooling. So the race for a textual format was on!

Beginning in the first decade of this century and continuing into the second decade until what we now call script-only stacks were invented, many options were discussed within the team, and between the team and the community via the LiveCode mailing list (in the earliest days that was the main channel; these forums didn't arrive until years later).

There was a lot of talk about using XML as a wrapper, but that seemed cumbersome. And managing GUI elements such as the IDE requires poses a whole host of challenges attempting to represent them with complete fidelity in textual form, esp given the complexities of workflows where multiple devs may be working on the same stacks simultaneously.

By the time releasing an open source edition was being considered, version control among the IDE devs had already become cumbersome; opening up that process to the world would become prohibitively cumbersome.

So I believe it was dev lead Mark Waddingham who finally sliced the Gordian knot: instead of attempting a textual format for objects, they'd make script-only stacks. Where GUI objects are needed a preOpenStack handler can be used to create those objects on the fly.

You can see this in action in nearly all of the LC IDE stack scripts. The Toolbar is a good place to explore. The engine is so efficient that it can create the LC IDE UI on the fly at startup almost as fast as it used to unpack the binary objects back when they were stored in binary stack files.

There are probably other benefits to script-only stacks, but that's the origin story.

The open source edition was officially ended on Aug 31 of last year (the old GitHub repository linked to above has temporarily remained as a community service, and will likely be removed soon).

Script-only stacks made merging contributions MUCH easier than could have been done without it, and AFAIK the team continues using git as their version control system, these days on a private server.

--

I'll close with a juicy trivia tidbit as a reward for those who read this long post all the way to the end:

At the heart of git are two key functions, diff and merge.

Diff takes two blocks of text and outputs a concise listing of the differences between them.

Merge takes the master script and the diff list and produces the changed script.

The benefit of using merge rather than just using the newer file is that you can edit the diff file to merge only the changes you want to accept, leaving other things as they were.

Both of these have quietly found their way into the LC engine, in the form of gitDiff and gitMerge functions in the LiveCode Script language.

If one had enough time on their hands they could use those to make a wide range of useful and convenient GUI version control tools.

[richmond62]

Wow! A big, but highly nutritative mouthful.

I certainly learnt a lot.

Thank you for such an formative, err posting, err article.

It explains so well why it is very difficult indeed to edit some of the stacks inside the IDE: because they are script only.

[bn]

....
I'll close with a juicy trivia tidbit as a reward for those who read this long post all the way to the end:

At the heart of git are two key functions, diff and merge.
Diff takes two blocks of text and outputs a concise listing of the differences between them.
Merge takes the master script and the diff list and produces the changed script.
The benefit of using merge rather than just using the newer file is that you can edit the diff file to merge only the changes you want to accept, leaving other things as they were.
Both of these have quietly found their way into the LC engine, in the form of gitDiff and gitMerge functions in the LiveCode Script language.
If one had enough time on their hands they could use those to make a wide range of useful and convenient GUI version control tools.

I agree with Richard that "diffing" can be quite useful.
For those who want to look up the functions in the dictionary:

Code: Select all

DiffCompare
DiffCompareFiles
DiffPatch

the library is:
com.livecode.library.diff

Kind regards
Bernd

[LostinLC]

The open source edition was officially ended on Aug 31 of last year (the old GitHub repository linked to above has temporarily remained as a community service, and will likely be removed soon).

Why remove it? There would be no practical consequences. There are 71 forks of that repository currently. Who should gain what from removing the original?

[richmond62]

Why remove it?

Presumably for the same reason as the download page suddenly lost all the Open Source versions: because they
detract from the commercial version.

The GIT hub link above is to version 6.

This one is to a "9.7.0 DP-1":

https://github.com/livecode/livecode

[FourthWorld]

The open source edition was officially ended on Aug 31 of last year (the old GitHub repository linked to above has temporarily remained as a community service, and will likely be removed soon).

Why remove it? There would be no practical consequences. There are 71 forks of that repository currently. Who should gain what from removing the original?

GitHub for one. That's a lot of space for a project that is no longer active.

Removing the repo removes any expectations that it is supported.

As you noted, many forks exist. There is at least one active one, OpenXtalk. Some orgs will pull their repo as soon as it's no longer supported. LC has left theirs in place nearly a year so those interesting in actively maintaining a fork can do so.

[LostinLC]

GitHub used space would hardly shrink one iota. Read the docs:
"When you delete a public repository, one of the existing public forks is chosen to be the new parent repository. All other repositories are forked off of this new parent and subsequent pull requests go to this new parent."

Also note that total size of files in "livecode-ide" is 67 MB
(or 46 MB if compressed),
"livecode" the engine is even smaller.
Wild guess, you may have an audio or image file on your watch that is bigger.

Would a platform care that accepts repos up to 100 GB in size and hosts (I don't know) billions of files needing many TB of space?

On clear communication of support:

If LC Ltd cared what people know about their support for the published version they would have spared a minute on Sept 1 2021 and added a support-end note to the livecode repository readme .md file and maybe also at livecode-ide (which has none, maybe using the about .txt file).

Funny enough, last person committing something to the readme file was the well-known BerndN who three years ago bravely upgraded the copyright year from 2015 and 2016 (it had not been consistent in the same file) to 2019.

Might be it was assumed someone should announce the end of this support as a community contribution as well. Alas, it cannot be done, as the repository is read-only now.

[FourthWorld]

End of support was announced a year ago when it happened.

If you really want a workout for your C++ skills you can fork from any of the live forks.

[LostinLC]

Oh, did I mention my C++-skills? Darn.

[FourthWorld]

Oh, did I mention my C++-skills? Darn.

That's what most of the engine is written in.

[richmond62]

Read it and, erm, cough:

https://www.theregister.com/2022/08/04/ ... on_policy/

[stam]

Read it and, erm, cough:

https://www.theregister.com/2022/08/04/ ... on_policy/

And yet:

https://www.theregister.com/2022/08/05/ ... on_policy/

Not to mention it seems likely LC still use GitHub as you can keep projects private (and probably use the paid version anyway)…