LiveCode repo name change fixer

Mark Waddingham mark at livecode.com
Thu Sep 10 05:13:25 EDT 2015


> On 09/09/2015 06:25 PM, Monte Goulding wrote:
> 
>> Script only stacks work in 6. Not sure which version they were 
>> introduced but but in 6.7.7 there’s a bucket load of script only 
>> stacks in the IDE for libraries.
> 
> Huh. So they are. At least as far back as 6.7.5 anyway.
> Somehow I missed that fact.

The history of script only stacks goes back to at least 6.7.0, maybe 
even later maintenance releases of 6.6.x.

The motivation was iOS SDK support. At that point there seemed to be 
constant changes being required to the iOS standalone builder to 
continue to support the bleeding edge iOS SDK - it was the most updated 
IDE component at the time.

As, at that point, we had essentially 2/3 IDE branches we had to keep in 
sync, it was becoming a real headache to manage the changes and ensure 
that the revSaveAsIOSStandalone stack was kept in-sync, up to date and 
working in all branches.

I hacked in something to allow a stack to be a text file since that was 
all (for all intents as purposes) what the revSaveAsIOSStandalone stack 
contained - a single stack script. It was a bit rough at first - I was 
trying to solve an immediate problem rather than produce a fully fledged 
feature.

Then someone else in the company noticed it for some other reason, and 
started using it, fed back so I could fix a few issues in it.

I was always slightly concerned about the data-loss potential - the 
reason we never presented it as a 'supported feature' in the first 
instance because I wasn't sure whether the engine should be more 
draconian about their use. i.e. Should the engine stop you from creating 
objects / setting custom props on such a stack?

As it turns out, however, my concerns about that aspect turned out not 
be concerns at all. The utility of script only stacks just as they are 
more than justified their existence and they've been growing in 
usefulness ever since.

I'm still not sure my decision to require a UTF-8 BOM at the start to 
differentiate from a native platform encoding file was a good idea 
though. I probably should have just assumed UTF-8 regardless. (Hindsight 
being 20/20 of course).

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps




More information about the use-livecode mailing list