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

[Bob Sneidar via use-livecode]

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'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.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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

[Mark Waddingham via use-livecode]

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 merge conflicts


I think we shelved that project before you joined LiveCode :)

The 'dead-end' was more a realisation of the fact that we had been 
trying to solve the wrong problem.


All the dVCSs which exist today are text-based - they are designed and 
built for allowing collaborative contribution to projects which are 
*naturally* text-based. Indeed, git was designed by Linus Torvalds to 
improve efficiency of contribution to the linux kernel - which is a 
purely C project.


When you combine this with an extra constraint which was placed on the 
project - the ability to be able to 'naturally' interact with patches 
through GitHub or similar - you end up with the dead-end.


The goal of trying to create a mergeable text format for stacks which 
should work naturally through GitHub and such was, I think, a mis-step. 
It just isn't possible, in full generality, to do in a way which does 
not involve significant amount of human effort to resolve conflicts at 
the text level (and conflict resolution can be hard - even in C and 
similar languages - for a hierarchical data-structure it can be a lot 
harder!). This means that merges require a tool, and if merges require a 
tool why do we care about the underlying format?


The point here is that, with hindsight, we would have been better off 
ignoring the requirement for things to work 'in GitHub', and instead 
producing a merge-tool which could take two stacks (which had been 
instrumented appropriately) and produce a third after guided interaction 
to resolve the conflicts. Of course, text display of stackfile content 
would be useful in this - to help visualise the conflicts - but it 
wouldn't need to be total, or complete, or satisfy some impossible 
constraints around ensuring merge conflicts (detected with 3-way diff) 
were minimized.


Morale of the story: don't expect an algorithm (diff) which is designed 
for giving you the differences for sequential data to work on 
hierarchical data - because it won't.



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.


From my point of view, array representation of core engine object's 
properties is a useful feature to have. It can be done now (lcVCS shows 
that), however, the code which does it is spread around several places 
which means maintenance is difficult. The thing which generates the 
array format should be a method of the object which produces it.


I'd be wary of adding anything beyond *just* the core properties array 
export to the C++ part of the engine as the overhead in writing the C++ 
to do more than that is not justified - the construction of a full array 
of a stackfile would be better done as a LiveCode Script library. If 
there turn out to be performance issues with that approach which were 
critical *then* we look at how to make the script more performant, 
perhaps by adding engine functionality for the parts causing a problem.



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.


The reason Levure works well is because it plays by the implicit rules 
which you need to follow if you want to use GitHub-like dVCS - your 
project must be a naturally text-based format, where naturally means 
designed to be written in text directly rather than rendered to text 
using some sort of algorithm. Indeed, more specifically, it also needs 
to follow implicit rules which ensure conflicts are minimised - one 
being unique naming of objects!


Certainly YAML would make for quite a readable format - although it is 
unlikely it would be any better or worse, in terms of mergeability, than 
any of the other approaches that have been tried (unless generated in a 
specific canonical way, and the stacks rendered to it follow some very 
very strict rules - which is essentially, 

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

[Monte Goulding via use-livecode]

> 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 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.

The lcVCS approach was to assign everything a UUID and then translate ID 
properties (icon,pattern,behavior etc) to the UUIDs and then translate them 
back to the new UUIDs when the stack is being re-created. It works well enough 
but you do end up seeing UUIDs in diffs. Probably what would be better would be 
to require unique long names (at least for objects that need this translation) 
and translate to those. That way you would see something readable.

> 
> 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.

Hehe… I think I’m perhaps a little jaded because I ended up creating a bit of a 
monster with lcVCS largely because of the UUIDs and the fact that it is a 
directory structure rather than a single file. Yes it would definitely be very 
helpful if we can get it right.

JSON is also not very good for diffs unless you have a not very strict parser 
which allows comma at the end of the last element of an array or object.

So… ideally we would have YAML <-> Array that is at least as fast as mergJSON 
and then a single file format that shmoozes the array before saving to remove 
unnecessary stuff. Working out what is unnecessary is fun too… I ended up with 
a plugin system in lcVCS so you could write a little bit of code for a custom 
control like a DataGrid to decide which custom properties to kill on save.

It’s probably not necessary to start from scratch here. Disregarding the YAML 
bit for a second the other bits only require relatively small changes to lcVCS. 
Well dropping UUIDs would be a bit of work but not too bad. When array export 
is possible then that’s just a matter of swapping out use of the properties 
property for array export/import.

Cheers

Monte


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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

[Brian Milby via use-livecode]

  
  

 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,   (mailto:use-livecode@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@lists.runrev.com Please visit this url 
> to subscribe, unsubscribe and manage your subscription preferences: 
> http://lists.runrev.com/mailman/listinfo/use-livecode  
>
>   
  
  
 
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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

[Monte Goulding via use-livecode]

> 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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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

[Mark Waddingham via use-livecode]

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 options - we have import/export array for widget, which 
naturally extends to any object type; so I'd be inclined to start there.


That being said, in the first instance, it would be best to focus on 
just the core properties - rather than the hierarchical structure which 
perhaps means a variant of 'the properties' might be better (and more 
obvious).


In any case, there's a fair bit of internal work to do before it can be 
exposed at the syntax level, so this doesn't have to be decided now.


I've been looking at the code and think that it would be 
straightforward to
take the save/load code and change it over to creating an array.  Some 
of
the complexity would go away since key existence could be checked 
directly
instead of flags for example (on import mainly).  All of the code 
specific
to versions < 9 would not be needed.  It would start with the MCObject 
and
be needed everywhere else.  The existing import/export code would then 
need

to call appropriate handlers to take care of the object info if the key
existed ([$object] as a suggestion).


There's some work already done along these lines - I'll dig out the 
branch in due course. It was an attempt to abstract the internal 
structure a bit (using the currently-unused 'Record Type' which has long 
been languishing in libfoundation) - but work stopped on it when we 
reached a dead end with the dVCS 'stack dir' idea - based on ideas Monte 
developed in lcVCS.


It might be a bit overkill for what we actually need though - as 
widget's already have a general form - and so its only the engine 
controls in C++ which need to be augmented with the ability; so once 
done, it isn't going to need more controls needing it.


If the full specification of the object is in the export array, then 
the
import could re-create an exact duplicate.  There would need to be a 
check

on the ID and altID to ensure a duplicate isn't being created (with
appropriate/sensible handling of collisions).  The import would be 
fully
backwards compatible since if the object key is not present, then it 
would

just work like it did before.


Yes - we should export the id, and if the id does not exist then honor 
its setting in import. If it does exist, we can either ignore, or throw 
an error; forcing the code to delete the id from the array before 
importing and have the engine assign one.


The suggestions about support for inline arrays would actually make 
this

interesting too.  A single statement could be used to update multiple
values/properties/settings of an object at once.  I'm sure there are 
pretty
big gotchas on that though since it would likely avoid proper messages 
from

being dispatched (or the update could dispatch messages as updates
performed or collect the messages that should be sent and dispatch them
sequentially after all updates were completed to avoid duplicates).  I
haven't gotten that far in research yet, so not sure.


Yes - there is a nice synergy here - particularly if we go for a 
property based mechanism (for existing controls at least) - although I'm 
still not 100% sure what would 'look best' here.


I don't think there are any unpleasant 'gotchas' here with regards 
messages. The engine tends not to send any messages when properties are 
set (there are a couple of exceptions); and it certainly doesn't if it 
is loading / saving - so, particularly for import/export there isn't a 
problem. *Maybe* if we went down the update via a modified properties 
property then we might need to consider it (although, I can only think 
of the menuHistory and friends properties which do send a changed 
message off the top of my head as a result of a property setting by 
script).


One thing though, it is always nice to have equivalences in terms of one 
feature being implemented via another means either for speed or for 
ergonomic reasons. If we were to go down the road and do this partly for 
the 'being able to set object state in a loadStack' type arrangement 
then we probably do want to vet the engine objects to make sure all 
internal properties can be reflected one-to-one in actual public 
properties; and nominate that set as being the 'core' properties (as I 
mentioned before).


The reason to do this is that it would give an equivalence between:

  import object from array ...

and

  create tArray["type"]
  set the prop1 to tArray[prop1]
  set the prop2 to tArray[prop2]
  ...

From memory, one of the issues (which Monte patched the properties 
property to deal with) was that the order you set properties in matters; 
ideally it wouldn't - as long as you only set the core properties. (i.e. 
rect and not the individual parts or pairings there-of).


Having a 

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

[Brian Milby via use-livecode]

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
take the save/load code and change it over to creating an array.  Some of
the complexity would go away since key existence could be checked directly
instead of flags for example (on import mainly).  All of the code specific
to versions < 9 would not be needed.  It would start with the MCObject and
be needed everywhere else.  The existing import/export code would then need
to call appropriate handlers to take care of the object info if the key
existed ([$object] as a suggestion).

If the full specification of the object is in the export array, then the
import could re-create an exact duplicate.  There would need to be a check
on the ID and altID to ensure a duplicate isn't being created (with
appropriate/sensible handling of collisions).  The import would be fully
backwards compatible since if the object key is not present, then it would
just work like it did before.

The suggestions about support for inline arrays would actually make this
interesting too.  A single statement could be used to update multiple
values/properties/settings of an object at once.  I'm sure there are pretty
big gotchas on that though since it would likely avoid proper messages from
being dispatched (or the update could dispatch messages as updates
performed or collect the messages that should be sent and dispatch them
sequentially after all updates were completed to avoid duplicates).  I
haven't gotten that far in research yet, so not sure.

Thanks,
Brian

On Mon, Aug 21, 2017 at 4:58 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Indeed, if we had a better 'properties' property (i.e. as suggested by me
> in terms of import/export array - something allowing you to get/set the
> core persistent state of an object directly) then you could have
> script-only-stacks which *also* contain their state (and, by collorary,
> state of objects on the stack) - via having code which does it.
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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

[Mark Waddingham via use-livecode]

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 sufficient for the antonym) - allowing 
a stack to 'do something' when it is loaded into memory, and then 
unloaded (equivalent to OnCreate / OnDestroy in LCB) as 
loading/unloading is a slightly different part of the life-cycle 
compared to opening and closing.


@LCMark I feel bad snipping discussion of the array literals because…
AWESOME!!!  but I actually only wanted to comment on `createStack`
feelign a bit wrong if we also have `newStack` and the `create stack`
command would send `newStack` not `createStack`.. or maybe it would
send both but you can see why I have an issue with it ;-)


Heh! That post was perhaps a bit 'thick' on content. The literals stuff 
probably should have got its own thread - they are pretty cool, the 
extra symbols needed are irksome but (just like with strings) I think 
resigning ourselves to the fact that different bracket types (in 
particular) are the best way to represent (in text) hierarchical data is 
just something we will have to do.


Back to the point of your post... I see what you mean about 'newStack' / 
'deleteStack' - I had a similar thought whilst writing the email. Too 
many messages and it will just get confusing, too few and its not 
flexible enough. However, it might be we do need a new pair of messages 
here, and clarify precisely what the existing and new ones are for.


Of course, we also have the 'lock messages' issue - something which 
increasingly makes me wonder whether the message path is being 
'overloaded' in use. It works very very well for events which you might 
want to 'bubble'; but I'm becoming increasingly convinced that is not 
quite right for (1) things which are related to a specific object (e.g. 
life-cycle messages); (2) libraries. [ There's a whole corollary here 
with being able to call methods 'inside' widgets here too - the 'do ... 
in widget' problem; it is a similar if not quite the same ].


Anyway, the latter is a somewhat large thought-project in and of itself. 
Certainly there are aspects of LCB which I think work better where the 
message path is very much a separate thing which widgets use (but aren't 
strictly a part of); but on the other hand there are issues still with 
integrating widgets into the message path (mouse messages and such).


So, in the short term, if there is an extra message-path message which 
*would* help make script-only-stacks more flexible, then we should 
perhaps seriously consider it - if we can make it tasteful enough!


Of course, another approach here is to keep script only stacks as they 
are (the header uses 'script' for a reason) - and then have a different 
form for objects which is a text serialization of *core* properties and 
script:


  stack "MyStack"

  set property behavior is ...

  set property title is ...

  on openStack
  end openStack

Or something (I just came up with that off the top of my head - so needs 
'reading between the lines' of the intent). With array properties, 
hierarchical properties could also be set.


As with any text-based representation of stackfiles, custom properties 
cause a significant problem here which is why I suggest that only core 
persistent properties should be allowed. So, even with this kind of form 
you'd still need a way to init them, which takes us back to the adding a 
message which allows such init - and then the need for 'stack ...' type 
script only stacks reduces - it is entirely equivalent to just having 
code in that init message which uses literals to init properties. 
Anything like the above just becomes 'syntactic sugar'.


In terms of language design, we need to be careful to ensure that 
anything you can do with 'syntactic sugar' does have a code-based 
equivalent - the latter coming first. The reason here is that it means 
that there is no engine 'magic', it can all be done in script; and the 
more engine 'magic' which is de-magicised, the more script can do.


Warmest Regards,

Mark.

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

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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

[Monte Goulding via use-livecode]

> 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 'do something' 
> when it is loaded into memory, and then unloaded (equivalent to OnCreate / 
> OnDestroy in LCB) as loading/unloading is a slightly different part of the 
> life-cycle compared to opening and closing.

@LCMark I feel bad snipping discussion of the array literals because… 
AWESOME!!!  but I actually only wanted to comment on `createStack` feelign a 
bit wrong if we also have `newStack` and the `create stack` command would send 
`newStack` not `createStack`.. or maybe it would send both but you can see why 
I have an issue with it ;-)

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

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

[Mark Waddingham via use-livecode]

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 add a loadBehavior and unloadBehavior
message sent to the object using the behavior so it can initialise its
own heirarchy. Still I think saving the behavior property with the
script only stack is a simpler solution.


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 'do 
something' when it is loaded into memory, and then unloaded (equivalent 
to OnCreate / OnDestroy in LCB) as loading/unloading is a slightly 
different part of the life-cycle compared to opening and closing.


I can certainly see that it would be a 'simpler' solution in some ways 
to save the behavior property - however, then it isn't 'just' a script 
anymore - it is actually just a cut down object, so that leads us into 
having general properties / structures encoded in a 'script only stack'.


I was playing about with prototyping something yesterday - array 
literals - it has been suggested before (indeed I thought there was a 
partial attempt by someone before - but I couldn't find it) but I 
thought it would be interesting to try it: 
https://github.com/livecode/livecode/pull/5824


Basically this patch adds JSON-like (which is LCB-like too!) syntax for 
sequence (numerically keyed array) and array (associative array) 
literals:


  put [ 1, 2, [ 3, 4, { "size" : the length of tOtherSeq } ] ] into 
tSeqVar
  put { "foo" : "bar", "baz" : tMyValue , tMyKey : [ 1, 2, 3 ] } into 
tArrVar


The syntax is the same as in LCB - keys and values can be static or 
constant. The implementation has the nice property (well, the sequence 
version does - the array one isn't quite finished yet) that actual 
constant literals (those which have constant key/values which can be 
evaluated at compile time) will share the value. i.e.


  put [ 1, 2, 3 ] into tSeqVar1
  put [ 1, 2, 3 ] into tSeqVar2 -- this will actually share the 
in-memory value with tSeqVar1


This means that you can explicitly write the same constant anywhere, as 
much as you like in script and still only have one instance of it. 
Indeed, the performance of using array literals compared to separate 
'put' statements to construct them is quite encouraging:


   BenchmarkStartTiming "LegacyCreation"
   repeat kRepetitions times
  get empty
  put true into tLegacyLiteral[1]
  put 1 into tLegacyLiteral[2]
  put pi into tLegacyLiteral[3]
  put "Hello" into tLegacyLiteral[4]
  put false into tLegacyLiteral[5]
  put 2 into tLegacyLiteral[6]
  put pi into tLegacyLiteral[7]
  put "World!" into tLegacyLiteral[8]
  put it into tLegacyLiteral[9]
   end repeat
   BenchmarkStopTiming

   BenchmarkStartTiming "ConstantCreation"
   repeat kRepetitions times
  get [ true, 1, pi, "Hello", false, 2, pi, "World!", [ true, 1, pi, 
"Hello", false, 2, pi, "World!" ] ]

   end repeat
   BenchmarkStopTiming

   BenchmarkStartTiming "LegacyDynamicCreation"
   repeat kRepetitions times
  put empty into tLegacyLiteral
  put _Identity(true) into tLegacyLiteral[tOne]
  put _Identity(1) into tLegacyLiteral[tTwo]
  put _Identity(pi) into tLegacyLiteral[tThree]
  put _Identity("Hello") into tLegacyLiteral[tFour]
   end repeat
   BenchmarkStopTiming

   BenchmarkStartTiming "DynamicCreation"
   repeat kRepetitions times
  get [ _Identity(true), _Identity(1), _Identity(pi), 
_Identity("Hello") ]

   end repeat
   BenchmarkStopTiming

Note: In the 'LegacyDynamicCreation' test variables holding actual 
numbers and not numeric literals are used as that is a fairer test with 
how things work at present (a technical detail - literals such as 1 are 
actually stored internally ready for being used as an array key; whereas 
dynamic creation has to create a key from the actual index 1).


On my machine I get the following results:

LegacyConstantCreation 3037 ms
ConstantCreation 53 ms
LegacyDynamicCreation 10330 ms
DynamicCreation 6496 ms

So there's certainly a significant performance advantage.

My only concern is introducing more symbols. There is another option 
here using ( ) can also be made unambiguous:


  ( expr ) - grouped expr

  ( expr , ) - single element sequence

  ( expr : expr ) - single key/value

However, I wonder if this is a bit too subtle - it would be all too easy 
to use ( expr ) for when you actually want a single element list - no 
amount of context can really help here.


This also overlaps with recent discussions about strings. The syntax of 
literals above is the same as JSON (and can be made compatible with 
Python, just by allowing a trailing ',' 

Re: Developing first on android

[Monte Goulding via use-livecode]

> 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 need to check that referenced stacks are open, but just did 
> some experimenting to verify that the calls work in the IDE.I'm guessing 
> you would want to possibly have them only set in one direction though.

That is what we do now although as a behavior can be used but not opened you 
would need to do that in the stack that uses the behavior. So you have stack A. 
The stack that uses the behavior which is a binary stackFile. Stack B the 
script only behavior of stack A. Stack C the script only behavior of stack B.

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 add a loadBehavior and unloadBehavior message sent to the object using the 
behavior so it can initialise its own heirarchy. Still I think saving the 
behavior property with the script only stack is a simpler solution.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Developing first on android

[Brian Milby via use-livecode]

  
  

 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 verify that the calls work in the IDE.I'm guessing 
you would want to possibly have them only set in one direction though.
  

  
Thanks,
  
Brian
  
  

  
>   
> On Aug 20, 2017 at 3:51 PM,   (mailto:use-livecode@lists.runrev.com)>  wrote:
>   
>   
>   
>   >  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 to see what is 
> already processed though. Hmm… I’m not sure what you mean here. Script only 
> stacks are sent the same messages as binary stacks. Do you think they need 
> something else? I have suggested a `loadStack` message here for when a stack 
> is loaded into memory but that’s not specific to script only stacks either. 
> http://quality.livecode.com/show_bug.cgi?id=18223 Cheers Monte 
> ___ use-livecode mailing list 
> use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe 
> and manage your subscription preferences: 
> http://lists.runrev.com/mailman/listinfo/use-livecode  
>
>   
  
  
 
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Developing first on android

[Monte Goulding via use-livecode]

> 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 to 
> see what is already processed though.

Hmm… I’m not sure what you mean here. Script only stacks are sent the same 
messages as binary stacks. Do you think they need something else? I have 
suggested a `loadStack` message here for when a stack is loaded into memory but 
that’s not specific to script only stacks either. 
http://quality.livecode.com/show_bug.cgi?id=18223 


Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Developing first on android

[Brian Milby via use-livecode]

  
  

 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 Aug 19, 2017 at 10:58 PM,   (mailto:use-livecode@lists.runrev.com)>  wrote:
>   
>   
>   
>  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 believe me try 
> looking at an Xcode storyboard merge conflict… it’s no fun. You really are 
> better off just being careful to avoid working on ui stuff on multiple 
> branches. If you have a trivial UI then you can generate it on the fly as we 
> do with some stacks in the IDE. If you have something a little bit too 
> complicated for hand coding generation on the fly then you could use 
> something like the scriptonlyUI library I experimented with one rainy day 
> https://github.com/montegoulding/scriptonlyui . Anything more complicated is 
> just as well off staying a binary file and using script only behaviors for 
> scripts. Having said that there _are_ a couple of stack properties that we 
> could add to script only stacks to make things work better and I don’t think 
> it would be all that tricky to add something YAML like that the engine reads 
> between the `script “”` header and the stack script. The properties that I 
> would add are behavior and stackFiles so your script only stack would look 
> like this: script “StackName” --- behavior: stack “ParentBehavior” 
> stackFiles: - ParentBehavior: some/path.livecodescript --- command MyHandler 
> -- code end MyHandler There could be some other properties that would be 
> helpful but I think these are the critical ones causing issues for behavior 
> hierarchies which are lost when saving so you need to script them. Perhaps 
> even stackFiles isn’t that necessary as the stackFiles could be set on a 
> binary stack elsewhere or the stack could be in a location the engine would 
> find it. We would probably only want to add properties that we feel are 
> causing issues which behavior definitely is. The less you add the less chance 
> of a merge conflict on some change you didn’t intent. Of course once you add 
> _any_ properties it’s suddenly _not_ a script only stack so… BTW if we only 
> wanted to add behavior and only stack behaviors at that it might be nice to 
> just include that in the header: script “StackName” with behavior 
> “ParentBehavior” command MyHandler — code end MyHandler I actually really 
> like this option as it’s in keeping with the original faceless script object 
> concept. Cheers Monte ___ 
> use-livecode mailing list use-livecode@lists.runrev.com Please visit this url 
> to subscribe, unsubscribe and manage your subscription preferences: 
> http://lists.runrev.com/mailman/listinfo/use-livecode  
>
>   
  
  
 
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Developing first on android

[Monte Goulding via use-livecode]

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 believe me try looking at 
an Xcode storyboard merge conflict… it’s no fun. You really are better off just 
being careful to avoid working on ui stuff on multiple branches. If you have a 
trivial UI then you can generate it on the fly as we do with some stacks in the 
IDE. If you have something a little bit too complicated for hand coding 
generation on the fly then you could use something like the scriptonlyUI 
library I experimented with one rainy day 
https://github.com/montegoulding/scriptonlyui 
. Anything more complicated is 
just as well off staying a binary file and using script only behaviors for 
scripts.

Having said that there _are_ a couple of stack properties that we could add to 
script only stacks to make things work better and I don’t think it would be all 
that tricky to add something YAML like that the engine reads between the 
`script “”` header and the stack script.

The properties that I would add are behavior and stackFiles so your script only 
stack would look like this:

script “StackName”
---
behavior: stack “ParentBehavior”
stackFiles:
- ParentBehavior: some/path.livecodescript
---
command MyHandler
  -- code
end MyHandler

There could be some other properties that would be helpful but I think these 
are the critical ones causing issues for behavior hierarchies which are lost 
when saving so you need to script them. Perhaps even stackFiles isn’t that 
necessary as the stackFiles could be set on a binary stack elsewhere or the 
stack could be in a location the engine would find it.

We would probably only want to add properties that we feel are causing issues 
which behavior definitely is. The less you add the less chance of a merge 
conflict on some change you didn’t intent. Of course once you add _any_ 
properties it’s suddenly _not_ a script only stack so…

BTW if we only wanted to add behavior and only stack behaviors at that it might 
be nice to just include that in the header:

script “StackName” with behavior “ParentBehavior”
command MyHandler
  — code
end MyHandler

I actually really like this option as it’s in keeping with the original 
faceless script object concept.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Developing first on android

[Brian Milby via use-livecode]

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 code.

On Fri, Aug 18, 2017 at 5:48 PM, Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> 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
> represents say a button and copy it to another stack array, or a different
> place in the first array, all will be well. All kinds of nasties happen
> with ID's and linked graphics and whatnot just copying a button with a
> linked graphic to another card.
>
> Bob S
>
>
> > On Aug 18, 2017, at 15:12 , Brian Milby via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > 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 used to serialize into a suitable disk format.  It would mean
> that
> > the only way to get a full representation of the object would be to use
> the
> > full import if there were properties like you described above (unless I'm
> > missing something).
> >
> > I've actually been mulling something along these lines over for the past
> > few weeks (but was thinking about a direct XML format).  I briefly looked
> > at the code to save a stack and noticed how it seems pretty straight
> > forward.  I'll take a look at the code for some of the objects this
> weekend
> > and see what I think.  Could be a good opportunity for the community to
> > contribute a useful new feature.
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Developing first on android

[Bob Sneidar via use-livecode]

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 
represents say a button and copy it to another stack array, or a different 
place in the first array, all will be well. All kinds of nasties happen with 
ID's and linked graphics and whatnot just copying a button with a linked 
graphic to another card. 

Bob S


> On Aug 18, 2017, at 15:12 , Brian Milby via use-livecode 
>  wrote:
> 
> 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 used to serialize into a suitable disk format.  It would mean that
> the only way to get a full representation of the object would be to use the
> full import if there were properties like you described above (unless I'm
> missing something).
> 
> I've actually been mulling something along these lines over for the past
> few weeks (but was thinking about a direct XML format).  I briefly looked
> at the code to save a stack and noticed how it seems pretty straight
> forward.  I'll take a look at the code for some of the objects this weekend
> and see what I think.  Could be a good opportunity for the community to
> contribute a useful new feature.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Developing first on android

[Brian Milby via use-livecode]

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 used to serialize into a suitable disk format.  It would mean that
the only way to get a full representation of the object would be to use the
full import if there were properties like you described above (unless I'm
missing something).

I've actually been mulling something along these lines over for the past
few weeks (but was thinking about a direct XML format).  I briefly looked
at the code to save a stack and noticed how it seems pretty straight
forward.  I'll take a look at the code for some of the objects this weekend
and see what I think.  Could be a good opportunity for the community to
contribute a useful new feature.

On Fri, Aug 18, 2017 at 11:56 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> 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 think Monte's lcVCS might well be a good starting point for that -
> there's no real need to have engine support as long as we make sure all the
> things you need to know to deconstruct / reconstruct a stackfile are
> accessible from script (which is where the engine support kicks in).
>
> That being said, there is one piece of engine functionality which would
> make lcVCS and similar tools much simpler - the ability to ask the engine
> for a LiveCode array representing the actual persistent state of any
> LiveCode object. If you have an array which contains a faithful
> representation of the persistent state, then you can write serializers /
> deserializers to whatever text (or other!) format you like in LiveCode
> Script (which is a much much better place for such things to be!).
>
> There is a starting point here for this. In order to allow lcVCS to
> support widgets (which can have arbitrary persistent state), we added a new
> form to the 'export' and 'import' commands:
>
> export  to array 
> import  from array 
>
> We also added 'is strictly' operators which allow you to detect the actual
> dynamic type of a value, rather than what values it could be:
>
>   put "100" is a number -- true
>   put "100" is strictly a number -- false
>
> This allows lcVCS to create a faithful representation (in JSON) of the
> values in LiveCode variables - in particular, in those returned from
> export/import widget.
>
> The reason I mention this is that this ability really is the precursor to
> eliminating the engine's dependence on a bespoke binary stackfile format
> (which is actually a huge problem - for all kinds of reasons) - if we had a
> fully faithful (in the strict mathematical sense!) import/export array
> ability - a stackfile could just become an array which has been encoded
> with any hierarchical data encoding format (of which the arrayEncode format
> is one, JSON is another, BSON is another, YAML is another, ...).
>
> It might be that the part of lcVCS which does the JSON mapping might well
> be completely sufficient - perhaps Monte could chime in here to comment and
> remind me of the issues he had / faced with it.
>
> I can recall one significant issue - the properties we set on objects (or
> widgets - lamentably) are not necessarily reflective of the persistent
> state. What I mean by this is that, in some case, you cannot directly set
> one of the internal persistent state variables of an object directly by a
> property - it can only be done by setting a combination, or by other
> actions (I'd need to look through the engine code to remind myself where
> this occurs).
>
> However *that* is fixable - we make sure that there are suitably human
> understandable properties for all objects which ensure you can easily
> import and export them using just those properties. For widgets, it comes
> to down to imposing a simple rule:
>
> Any piece of state which is saved into the state array (on OnSave) *must*
> be accessible by a public property.
>
> This would actually simplify widget creation - as you wouldn't need an
> OnLoad / OnSave handler at all then. It would just be a case of serializing
> the properties which are marked as 'persistent'. This is one case where I
> modelled the engine's behavior, and shouldn't have done - I should have
> ignored how the engine did things and just gone with 'what made more sense'!
>
> Anyway, I'd suggest we start looking at lcVCS (in terms of its object
> import/export - not the VC related aspects) and see what issues it has;
> then look at starting to fix those issues in the engine; then look to start
> adding array import/export 

Re: Developing first on android

[J. Landman Gay via use-livecode]

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 the LC
IDE to do it.


This method also works well, and I've used it in a couple of projects. 
But being basically lazy, I like to follow the rule to "let the engine 
do it" whenever possible. If you aren't using git or your layouts aren't 
dynamic, it's much easier to let the engine do the resizing and scaling 
for you, and the tricks I mentioned are an easy way to overcome a few 
limitations.


One other comment about my presentation: the problem with issuing the 
"quit" command was just fixed and is now awaiting merge. :) Now all we 
need is suspend/resume messages and the main Android issues will go away.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Developing first on android

[Mark Waddingham via use-livecode]

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 think Monte's lcVCS might well be a good starting point for that - 
there's no real need to have engine support as long as we make sure all 
the things you need to know to deconstruct / reconstruct a stackfile are 
accessible from script (which is where the engine support kicks in).


That being said, there is one piece of engine functionality which would 
make lcVCS and similar tools much simpler - the ability to ask the 
engine for a LiveCode array representing the actual persistent state of 
any LiveCode object. If you have an array which contains a faithful 
representation of the persistent state, then you can write serializers / 
deserializers to whatever text (or other!) format you like in LiveCode 
Script (which is a much much better place for such things to be!).


There is a starting point here for this. In order to allow lcVCS to 
support widgets (which can have arbitrary persistent state), we added a 
new form to the 'export' and 'import' commands:


export  to array 
import  from array 

We also added 'is strictly' operators which allow you to detect the 
actual dynamic type of a value, rather than what values it could be:


  put "100" is a number -- true
  put "100" is strictly a number -- false

This allows lcVCS to create a faithful representation (in JSON) of the 
values in LiveCode variables - in particular, in those returned from 
export/import widget.


The reason I mention this is that this ability really is the precursor 
to eliminating the engine's dependence on a bespoke binary stackfile 
format (which is actually a huge problem - for all kinds of reasons) - 
if we had a fully faithful (in the strict mathematical sense!) 
import/export array ability - a stackfile could just become an array 
which has been encoded with any hierarchical data encoding format (of 
which the arrayEncode format is one, JSON is another, BSON is another, 
YAML is another, ...).


It might be that the part of lcVCS which does the JSON mapping might 
well be completely sufficient - perhaps Monte could chime in here to 
comment and remind me of the issues he had / faced with it.


I can recall one significant issue - the properties we set on objects 
(or widgets - lamentably) are not necessarily reflective of the 
persistent state. What I mean by this is that, in some case, you cannot 
directly set one of the internal persistent state variables of an object 
directly by a property - it can only be done by setting a combination, 
or by other actions (I'd need to look through the engine code to remind 
myself where this occurs).


However *that* is fixable - we make sure that there are suitably human 
understandable properties for all objects which ensure you can easily 
import and export them using just those properties. For widgets, it 
comes to down to imposing a simple rule:


Any piece of state which is saved into the state array (on OnSave) 
*must* be accessible by a public property.


This would actually simplify widget creation - as you wouldn't need an 
OnLoad / OnSave handler at all then. It would just be a case of 
serializing the properties which are marked as 'persistent'. This is one 
case where I modelled the engine's behavior, and shouldn't have done - I 
should have ignored how the engine did things and just gone with 'what 
made more sense'!


Anyway, I'd suggest we start looking at lcVCS (in terms of its object 
import/export - not the VC related aspects) and see what issues it has; 
then look at starting to fix those issues in the engine; then look to 
start adding array import/export methods for all LiveCode objects... 
Assuming this is an interesting project someone (not looking at anyone 
in particular ;)) would like to take up...


Warmest Regards,

Mark.


Mike Kerner wrote:

> I've been thinking of developing a deconstructor to use with Levure.
>  The idea is that you would lay out the objects, but then the
> deconstructor would pull all the properties of each object, put them
> in a YML, JSON, or other similar file, and then they would be built in
> the app by  script, when needed.

That would be handy.  I've considered making one, but the cost/benefit
relative to other commitments here has prevented me from diving in. I
appreciate your interest in this, and know you'll do a fine job with 
it.


While it's understandable that Git can't handle LC's binary files, one 
of

the strongest benefits of "The xTalk Way" is visual design.

This is why so many of us have written libraries to automatically
instantiate mobile-specific controls for us from LC-native objects, 
because
it lets us enjoy the fluid development workflow that characterizes 
xTalks,
rather than defining objects by typing long 

Re: Developing first on android

[Brian Milby via use-livecode]

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 deconstructor to use with Levure.
> >  The idea is that you would lay out the objects, but then the
> > deconstructor would pull all the properties of each object, put them
> > in a YML, JSON, or other similar file, and then they would be built in
> > the app by  script, when needed.
>
> That would be handy.  I've considered making one, but the cost/benefit
> relative to other commitments here has prevented me from diving in. I
> appreciate your interest in this, and know you'll do a fine job with it.
>
> While it's understandable that Git can't handle LC's binary files, one of
> the strongest benefits of "The xTalk Way" is visual design.
>
> This is why so many of us have written libraries to automatically
> instantiate mobile-specific controls for us from LC-native objects, because
> it lets us enjoy the fluid development workflow that characterizes xTalks,
> rather than defining objects by typing long blocks of object definitions in
> scripts, which is a very C way of doing things.
>
> Automating use of Git through binary->script decomposers allows developers
> the full benefit of the best of both xTalk and lower-level workflows.
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Developing first on android

[Mike Kerner via use-livecode]

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-livecode@lists.runrev.com> wrote:

> I blame Spell Checker.
>
> Bob S
>
>
> > On Aug 18, 2017, at 07:56 , Richard Gaskin via use-livecode <
> use-livecode@lists.runrev.com> 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.
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Developing first on android

[Bob Sneidar via use-livecode]

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.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Developing first on android

[Richard Gaskin via use-livecode]

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, instead
> of using the LC IDE to do it.

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.


Was Jonathan's issue specific to layout? I had thought it was a 
reflection of a somewhat general sense that LC's feature set for Android 
is in some ways a subset of features found in LC's iOS engine.  To the 
degree that's true, Jacque's suggestion is a great one, since the range 
of things we can do in Android that aren't available on LC's iOS engine 
does seem smaller than the other way around.


If not limited to layout, how would the storage format of the objects 
affect that?  Whether rebuilt on the fly each time from script or 
instantiated from op codes in the binary stack file, an object is an object.


Even for layout, it seems the benefit of using Git-based workflows is 
for the benefits of using Git, in development, and would not seem to 
alter runtime behavior.  Have I missed some feature unique to 
script-only stacks?



The only downside I can think of to using any single OS for the majority 
of one's multi-platform development is to make sure you periodically run 
in each of the target OSes to ensure things look as they should.


For example on mobile, a menu button row/widget appears at the top of 
the layour in Android (not a bad choice, given that people tend to 
perceive layouts in reading order, left to right and top to bottom), but 
on iOS that main navigation control is placed below the region it 
affects, at the bottom of the card.


There aren't many things like that which differ so starkly, unless you 
get deeply into Android's Material Design.  But if we want to avoid 
having our apps look like something that was obviously designed for some 
other OS and hastily ported we want to learn those differences and 
support them in our layout code.



> I've been thinking of developing a deconstructor to use with Levure.
>  The idea is that you would lay out the objects, but then the
> deconstructor would pull all the properties of each object, put them
> in a YML, JSON, or other similar file, and then they would be built in
> the app by  script, when needed.

That would be handy.  I've considered making one, but the cost/benefit 
relative to other commitments here has prevented me from diving in. I 
appreciate your interest in this, and know you'll do a fine job with it.


While it's understandable that Git can't handle LC's binary files, one 
of the strongest benefits of "The xTalk Way" is visual design.


This is why so many of us have written libraries to automatically 
instantiate mobile-specific controls for us from LC-native objects, 
because it lets us enjoy the fluid development workflow that 
characterizes xTalks, rather than defining objects by typing long blocks 
of object definitions in scripts, which is a very C way of doing things.


Automating use of Git through binary->script decomposers allows 
developers the full benefit of the best of both xTalk and lower-level 
workflows.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Developing first on android

[Jonathan Lynch via use-livecode]

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 future improvements starting on Android 
first.

I got a lot of good tips from her presentation - so thank you Jacqueline:)

Sent from my iPhone

> On Aug 17, 2017, at 9:31 PM, Mike Kerner via use-livecode 
>  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, instead of using the LC
> IDE to do it.  I've been thinking of developing a deconstructor to use with
> Levure.  The idea is that you would lay out the objects, but then the
> deconstructor would pull all the properties of each object, put them in a
> YML, JSON, or other similar file, and then they would be built in the app
> by  script, when needed.  That may give you additional flexibility when
> doing Android or ios because you could build your own geometry manager for
> mobile.
> The other thing that I've been thinking about was doing the layouts in a
> tool like Sketch (which would also mean that I could use some of the
> interface design service companies like uichest and pixelbuddha more
> easily).  That might also make the Android interface simpler to build and
> manipulate, but I haven't played with the idea enough to really
> understand it, yet.
> 
> On Thu, Aug 17, 2017 at 7:24 PM, Jonathan Lynch via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> 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@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
> 
> 
> 
> -- 
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>   and did a little diving.
> And God said, "This is good."
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Developing first on android

[Mike Kerner via use-livecode]

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 to do it.  I've been thinking of developing a deconstructor to use with
Levure.  The idea is that you would lay out the objects, but then the
deconstructor would pull all the properties of each object, put them in a
YML, JSON, or other similar file, and then they would be built in the app
by  script, when needed.  That may give you additional flexibility when
doing Android or ios because you could build your own geometry manager for
mobile.
The other thing that I've been thinking about was doing the layouts in a
tool like Sketch (which would also mean that I could use some of the
interface design service companies like uichest and pixelbuddha more
easily).  That might also make the Android interface simpler to build and
manipulate, but I haven't played with the idea enough to really
understand it, yet.

On Thu, Aug 17, 2017 at 7:24 PM, Jonathan Lynch via use-livecode <
use-livecode@lists.runrev.com> wrote:

> 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@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode