Array literals and script only stack initialization (was Re: Developing first on android)

[Brian Milby]

 I think there may be a strategy to avoid a large part of the ID collision issue.    Wouldn't need full on UUIDs, just assign a range to each developer working the UI.    Upon import they could even be collapsed down to the natural order range or left as is.    It would require the temporary setting of the stack ID and being able to revert (thinking the alt ID may be useful here).    Dev A could start at 5001, Dev B at 6001, etc.    Main stack would remain with the 1001 series.    The idea would be that in the preopenstack handler that a check would be made for the dev environment and the developer.    The alt ID would be set for the stack.    When new objects are created, the engine would use the alt ID if set.    There would be a corresponding call to clear the stack alt ID to go back to the normal series (say for the primary developer) and probably also go in the close stack handler.    Custom properties could be used to track where each developer was in their sequence.
  

  
Although the diffs may not be useful for coordinated development, don't you think they would be useful to compare snapshots?    Using github, it would show a bunch of lines where data just changed which wouldn't be all that useful but being able to see the new objects which should be easily identifiable should be useful.
  

  
I know that lcVCS did quite a bit of pruning, but that sort of activity could be built into the LCS code that processed the array before generating the JSON or XML.    There could even be 2 or more levels defined to provide the ability to customize what data was retained.
  

  
I guess my point is that if writing code to pull the native data structure out to an array, why stop at less than everything at that point.    It would be easy to ignore parts of the array that were not needed.    The good thing is that we could ignore the pieces that are no longer relevant (and would get created on the fly when saved as binary).
  

  
If nothing else, it will be a fun learning experience for me.
  

  
Thanks,
  
Brian
  

  
  

  
>   
> On Aug 21, 2017 at 5:23 PM,  <Monte Goulding via use-livecode (mailto:use-livecode at lists.runrev.com)>  wrote:
>   
>   
>   
>   >  On 22 Aug 2017, at 3:17 am, Mark Waddingham via use-livecode wrote:  >   >  work stopped on it when we reached a dead end with the dVCS 'stack dir' idea - based on ideas Monte developed in lcVCS. I can’t recall getting an explanation of what the dead end was but my guess is that it was fact that a merge conflict would be a nightmare to sort out and it is _very_ hard to write a non-lossy stack file format that won’t have a lot of merge conflicts If the goal of any array import/export of LC object is to create a mergeable file format then I wouldn’t bother. There’s just too much mingling of data and session state in LC objects. lcVCS just barely scrapes by if you have rigorous object cleaning scripts so that you don’t get merge conflicts on stuff like object sizes in a resizable stack. Not to mention the object ID merge conflict conundrum which needs a _lot_ of code to work around the fact we don’t have UUIDs. With script only stacks proving there’s significant utility in lossy file formats here I think the best solution would be something along the lines of the script only UI library I made where only a very limited subset of properties is supported, everything _must_ be uniquely named, no custom properties, no non-stack behaviors, only store the name of images used for icons etc. Just the absolute bare minimum to recreate the stack. Use something like YAML so it’s super easy to read and make it a single file so it’s not possible to get lost in an arcane directory structure. Cheers Monte _______________________________________________ use-livecode mailing list use-livecode at lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode  
>
>