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 ID collision
> issue.Wouldn'
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
> 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 they could even be collapsed dow
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 tempor
> 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 fac
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 few
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
t
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
'deleteStack' which is probably suf
> 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 antonym) - allowing a stack to 'd
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 to
> 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
>
>
>
> There may be some nee
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 ver
> 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 initialization.I haven't looked
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 Au
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 belie
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
import
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
repr
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 use
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
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
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 d
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 <
use-li
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.
__
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 script,
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 futur
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 t
I really appreciate something Jacqueline said in her presentation. If we start
with Android deployment first, we can be pretty sure it will work on iOS.
How do you guys feel about this?
Sent from my iPhone
___
use-livecode mailing list
use-livecode@lis
27 matches
Mail list logo
