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

Here's the problem. Any project with a datagrid is going to tear through those ID's in a heartbeat as you are testing. Bob S > On Aug 21, 2017, at 21:58 , Brian Milby via use-livecode > wrote: > > I think there may be a strategy to avoid a large part of the

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

On 2017-08-22 00:23, Monte Goulding via use-livecode wrote: 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

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

> On 22 Aug 2017, at 2:58 pm, Brian Milby via use-livecode > wrote: > > > 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

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

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

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

> 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

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

On 2017-08-21 18:09, Brian Milby via use-livecode wrote: What about something like import into [objectRef] from array [arrayRef] OR update [objectRef] from array [arrayRef] where the array would be in the format of the export and the object would be an existing object. There are a

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

What about something like import into [objectRef] from array [arrayRef] OR update [objectRef] from array [arrayRef] where the array would be in the format of the export and the object would be an existing object. I've been looking at the code and think that it would be straightforward to

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

On 2017-08-21 12:06, Monte Goulding via use-livecode wrote: On 21 Aug 2017, at 7:58 pm, Mark Waddingham via use-livecode wrote: I think its been suggested before that a 'loadStack' message might be quite useful (perhaps it should be 'createStack' - we have

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

> On 21 Aug 2017, at 7:58 pm, Mark Waddingham via use-livecode > wrote: > > I think its been suggested before that a 'loadStack' message might be quite > useful (perhaps it should be 'createStack' - we have 'deleteStack' which is > probably sufficient for the

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

On 2017-08-21 01:31, Monte Goulding via use-livecode wrote: Right now you need to handle preOpenStack in stack A and setup the hierarchy because stack B does not retain the behavior property when saved and does not get any kind of message when used as a behavior. It may actually be a good idea

Re: Developing first on android

> On 21 Aug 2017, at 9:22 am, Brian Milby via use-livecode > wrote: > > > Ok, in that case, would the following work: > > > > On openStack > > Set the behavior of me to stack "parent" > > Set the behavior of stack "child" to me > > End openStack

Re: Developing first on android

Ok, in that case, would the following work: On openStack Set the behavior of me to stack "parent" Set the behavior of stack "child" to me End openStack There may be some need to check that referenced stacks are open, but just did some experimenting to

Re: Developing first on android

> On 21 Aug 2017, at 5:48 am, Brian Milby via use-livecode > wrote: > > What about handlers?Stacks already call preOpenStack and related > handlers.Adding handlers that get called automatically would leave it as > script only but allow for post-load

Re: Developing first on android

What about handlers?Stacks already call preOpenStack and related handlers. Adding handlers that get called automatically would leave it as script only but allow for post-load initialization.I haven't looked to see what is already processed though. > > On

Re: Developing first on android

Hi Folks lcVCS was invented before script only stacks and for the most part script only stacks covers the use case much better. If you have a complicated stackFile then no matter what text representation we make of it you would get lost dealing with merge conflicts and diffs. If you don’t

Re: Developing first on android

I can see that. If using the export as a way to track where you made changes, it would be good to have it in a text format. I've not gotten far enough into the object code to tell when/where it would be safe to edit such an array. This will need to be something considered when writing the

Re: Developing first on android

I'll weigh in here. An array representation of a stack might be useful in ways, such as storing it as a property of another stack, or writing it as a binary file to disk as a backup of sorts after arrayEncoding it. Just so long as no one thinks they can do something like take the key that

Re: Developing first on android

If I'm understanding correctly, a capability to export a stack as an array (with the corresponding import) would get around the issue of the non-public properties though. The array would be the intermediate format that would be used by the engine to construct the stack in memory. LCS could be

Re: Developing first on android

On 8/17/17 8:31 PM, Mike Kerner via use-livecode wrote: I liked what Pomegranate said, which would also be a way to make apps even more levure/git-friendly, and would, I think, solve some of the Android layout issues that she was discussing - every object is created by a script, instead of using

Re: Developing first on android

On 2017-08-18 18:05, Brian Milby via use-livecode wrote: What about a non-binary stack file format? Something XML based and derived from the actual in-memory stack object (would need to be integrated with the IDE/engine to be really useful though - to allow seamless/native import/export). I

Re: Developing first on android

What about a non-binary stack file format? Something XML based and derived from the actual in-memory stack object (would need to be integrated with the IDE/engine to be really useful though - to allow seamless/native import/export). > Mike Kerner wrote: > > > I've been thinking of developing a

Re: Developing first on android

Sorry, I assumed everyone was at Global, yesterday. During the keynote, an interview with Digital Pomegranate was shown. During that interview, there was a lengthy explanation about building LC apps, and things that they do. On Fri, Aug 18, 2017 at 11:04 AM, Bob Sneidar via use-livecode <

Re: Developing first on android

I blame Spell Checker. Bob S > On Aug 18, 2017, at 07:56 , Richard Gaskin via use-livecode > wrote: > > Who is "Pomegranate" and where was this message? In a quick search of recent > posts here I was unable to turn up anything from that user.

Re: Developing first on android

Mike Kerner wrote: > There might be another way to skin this cat. I liked what Pomegranate > said, which would also be a way to make apps even more levure/git- > friendly, and would, I think, solve some of the Android layout issues > that she was discussing - every object is created by a

Re: Developing first on android

I am not too worried about layout. I make extensive setlayout scripts to adjust to all screen sizes. But it seems like Android is the pickiest platform for other reasons as well, so why not start there first? After I get Augmented Earth to work fully on Android, I think I am going to make

Re: Developing first on android

There might be another way to skin this cat. I liked what Pomegranate said, which would also be a way to make apps even more levure/git-friendly, and would, I think, solve some of the Android layout issues that she was discussing - every object is created by a script, instead of using the LC IDE