savingStandalone message

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

savingStandalone message

Ali Lloyd-2
Hi all,

Various tweaks to the standalone builder seem to have broken the way the
savingStandalone message is supposed to work
http://quality.livecode.com/show_bug.cgi?id=18778

I have submitted a pull request that fixes it - the only wrinkle might be
that it reintroduces the following bug:
http://quality.livecode.com/show_bug.cgi?id=18364, namely that the
savingStandalone message gets sent for each build platform.

Now, my personal view is that that is how it should work, provided the
stack state is restored before building for the next platform. It allows a
more fine-grained build step where, if we added suitable parameters to the
message, you could for example ensure substacks with platform/architecture
specific resources were not included in the standalones where they are
irrelevant.

My question to you is the same as I asked Lyn Teyla in the above report:

Would the following behavior be a problem for your use case, and if so why?

store stack state (*)
repeat for each target architecture
   dispatch saving standalone message
   modify stack for per-arch settings
   deploy stack
   restore to state in (*)
   dispatch standalone saved message
end repeat
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: savingStandalone message

Paul Dupuis
I make use of the savingStandalone message in a few projects. Generally,
I would prefer a single message regardless of the number of platforms I
am building for. For ecample, I set a incremental "build' number on
savingStandalone and I would want that build number to be the same for
all platforms built for. If the message was sent for each platform I
suspect I could come up with some what to still do this, but the code
complexity would increase for a relatively simple task.

It would seem to me that if you are looking for platform specific
actions to modify the stack(s) used in each platform build, then ideally
you would want a set of platform specific messages. i.e

savingStandaloneForWindows
savingStandaloneForOSX
savingStandaloneForiOS
savingStandaloneForAndroid
savingStandaloneForHTML5
...

Or something like that. That way if you only meed to make a specific
scripted stack modification for Android, you only need to handle that
specific message.


On 11/15/2016 4:45 AM, Ali Lloyd wrote:

> Hi all,
>
> Various tweaks to the standalone builder seem to have broken the way the
> savingStandalone message is supposed to work
> http://quality.livecode.com/show_bug.cgi?id=18778
>
> I have submitted a pull request that fixes it - the only wrinkle might be
> that it reintroduces the following bug:
> http://quality.livecode.com/show_bug.cgi?id=18364, namely that the
> savingStandalone message gets sent for each build platform.
>
> Now, my personal view is that that is how it should work, provided the
> stack state is restored before building for the next platform. It allows a
> more fine-grained build step where, if we added suitable parameters to the
> message, you could for example ensure substacks with platform/architecture
> specific resources were not included in the standalones where they are
> irrelevant.
>
> My question to you is the same as I asked Lyn Teyla in the above report:
>
> Would the following behavior be a problem for your use case, and if so why?
>
> store stack state (*)
> repeat for each target architecture
>    dispatch saving standalone message
>    modify stack for per-arch settings
>    deploy stack
>    restore to state in (*)
>    dispatch standalone saved message
> end repeat
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: savingStandalone message

Ben Rubinstein
I seem to recall that one A Lloyd made a sensible suggestion for rationalising
this area:
http://quality.livecode.com/show_bug.cgi?id=18371

Paul, I'd think that your needs (which certainly overlap with mine...) could
be met by adopting Ali's suggestion in that report of a single message with
parameter to indicate which platform was being built for, if there was an
additional parameter to indicate that several standalones were being built at
once. Even if it was as crude as:
        savingStandalone  "Windows", 1, 3
        savingStandalone  "iOS", 2, 3
        savingStandalone  "Android", 3, 3

That would allow work to be done for the general case to be coded once, even
if it actually ran three times; platform-specific cases to be handled; and if
you wanted to do something like increment a build number to be the same across
platforms, you could increment only for the "1/3" case.


On 15/11/2016 13:18, Paul Dupuis wrote:

> I make use of the savingStandalone message in a few projects. Generally,
> I would prefer a single message regardless of the number of platforms I
> am building for. For ecample, I set a incremental "build' number on
> savingStandalone and I would want that build number to be the same for
> all platforms built for. If the message was sent for each platform I
> suspect I could come up with some what to still do this, but the code
> complexity would increase for a relatively simple task.
>
> It would seem to me that if you are looking for platform specific
> actions to modify the stack(s) used in each platform build, then ideally
> you would want a set of platform specific messages. i.e
>
> savingStandaloneForWindows
> savingStandaloneForOSX
> savingStandaloneForiOS
> savingStandaloneForAndroid
> savingStandaloneForHTML5
> ...
>
> Or something like that. That way if you only meed to make a specific
> scripted stack modification for Android, you only need to handle that
> specific message.
>
>
> On 11/15/2016 4:45 AM, Ali Lloyd wrote:
>> Hi all,
>>
>> Various tweaks to the standalone builder seem to have broken the way the
>> savingStandalone message is supposed to work
>> http://quality.livecode.com/show_bug.cgi?id=18778
>>
>> I have submitted a pull request that fixes it - the only wrinkle might be
>> that it reintroduces the following bug:
>> http://quality.livecode.com/show_bug.cgi?id=18364, namely that the
>> savingStandalone message gets sent for each build platform.
>>
>> Now, my personal view is that that is how it should work, provided the
>> stack state is restored before building for the next platform. It allows a
>> more fine-grained build step where, if we added suitable parameters to the
>> message, you could for example ensure substacks with platform/architecture
>> specific resources were not included in the standalones where they are
>> irrelevant.
>>
>> My question to you is the same as I asked Lyn Teyla in the above report:
>>
>> Would the following behavior be a problem for your use case, and if so why?
>>
>> store stack state (*)
>> repeat for each target architecture
>>    dispatch saving standalone message
>>    modify stack for per-arch settings
>>    deploy stack
>>    restore to state in (*)
>>    dispatch standalone saved message
>> end repeat
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: savingStandalone message

Ali Lloyd-2
In reply to this post by Paul Dupuis
Thanks for the feedback Paul. How is your build number increment
implemented?

On Tue, Nov 15, 2016 at 1:18 PM Paul Dupuis <[hidden email]> wrote:

> I make use of the savingStandalone message in a few projects. Generally,
> I would prefer a single message regardless of the number of platforms I
> am building for. For ecample, I set a incremental "build' number on
> savingStandalone and I would want that build number to be the same for
> all platforms built for. If the message was sent for each platform I
> suspect I could come up with some what to still do this, but the code
> complexity would increase for a relatively simple task.
>
> It would seem to me that if you are looking for platform specific
> actions to modify the stack(s) used in each platform build, then ideally
> you would want a set of platform specific messages. i.e
>
> savingStandaloneForWindows
> savingStandaloneForOSX
> savingStandaloneForiOS
> savingStandaloneForAndroid
> savingStandaloneForHTML5
> ...
>
> Or something like that. That way if you only meed to make a specific
> scripted stack modification for Android, you only need to handle that
> specific message.
>
>
> On 11/15/2016 4:45 AM, Ali Lloyd wrote:
> > Hi all,
> >
> > Various tweaks to the standalone builder seem to have broken the way the
> > savingStandalone message is supposed to work
> > http://quality.livecode.com/show_bug.cgi?id=18778
> >
> > I have submitted a pull request that fixes it - the only wrinkle might be
> > that it reintroduces the following bug:
> > http://quality.livecode.com/show_bug.cgi?id=18364, namely that the
> > savingStandalone message gets sent for each build platform.
> >
> > Now, my personal view is that that is how it should work, provided the
> > stack state is restored before building for the next platform. It allows
> a
> > more fine-grained build step where, if we added suitable parameters to
> the
> > message, you could for example ensure substacks with
> platform/architecture
> > specific resources were not included in the standalones where they are
> > irrelevant.
> >
> > My question to you is the same as I asked Lyn Teyla in the above report:
> >
> > Would the following behavior be a problem for your use case, and if so
> why?
> >
> > store stack state (*)
> > repeat for each target architecture
> >    dispatch saving standalone message
> >    modify stack for per-arch settings
> >    deploy stack
> >    restore to state in (*)
> >    dispatch standalone saved message
> > end repeat
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: savingStandalone message

Paul Dupuis
Ben,

Your suggested model with the parameters would work just fine for me. I
like it!

Ali

Different projects of mine do different things, but generally, for some
of my projects, I grab a stack custom property that represented a
incremental counter (which is basically incremented by 1 on every
saveStackRequest message) and clear it for the standalone(s) when built.
As noted, I could code around it, or, as I consider this, I realize in
this specific case where I am clearing a property, repeated calls of the
savingStandalone message would not matter. In another I add a date and
time stamp into a property of the standalone - ideally the same date &
time for all the platforms I am building for (which in that case is just
Windows and OSX)

As I noted, any of the above can be coded to work with a
savingStandalone message for each platform, so it is not like the
proposed change would change anything that could not be fixed.


On 11/15/2016 8:49 AM, Ali Lloyd wrote:

> Thanks for the feedback Paul. How is your build number increment
> implemented?
>
> On Tue, Nov 15, 2016 at 1:18 PM Paul Dupuis <[hidden email]> wrote:
>
>> I make use of the savingStandalone message in a few projects. Generally,
>> I would prefer a single message regardless of the number of platforms I
>> am building for. For ecample, I set a incremental "build' number on
>> savingStandalone and I would want that build number to be the same for
>> all platforms built for. If the message was sent for each platform I
>> suspect I could come up with some what to still do this, but the code
>> complexity would increase for a relatively simple task.
>>
>> It would seem to me that if you are looking for platform specific
>> actions to modify the stack(s) used in each platform build, then ideally
>> you would want a set of platform specific messages. i.e
>>
>> savingStandaloneForWindows
>> savingStandaloneForOSX
>> savingStandaloneForiOS
>> savingStandaloneForAndroid
>> savingStandaloneForHTML5
>> ...
>>
>> Or something like that. That way if you only meed to make a specific
>> scripted stack modification for Android, you only need to handle that
>> specific message.
>>
>>
>> On 11/15/2016 4:45 AM, Ali Lloyd wrote:
>>> Hi all,
>>>
>>> Various tweaks to the standalone builder seem to have broken the way the
>>> savingStandalone message is supposed to work
>>> http://quality.livecode.com/show_bug.cgi?id=18778
>>>
>>> I have submitted a pull request that fixes it - the only wrinkle might be
>>> that it reintroduces the following bug:
>>> http://quality.livecode.com/show_bug.cgi?id=18364, namely that the
>>> savingStandalone message gets sent for each build platform.
>>>
>>> Now, my personal view is that that is how it should work, provided the
>>> stack state is restored before building for the next platform. It allows
>> a
>>> more fine-grained build step where, if we added suitable parameters to
>> the
>>> message, you could for example ensure substacks with
>> platform/architecture
>>> specific resources were not included in the standalones where they are
>>> irrelevant.
>>>
>>> My question to you is the same as I asked Lyn Teyla in the above report:
>>>
>>> Would the following behavior be a problem for your use case, and if so
>> why?
>>> store stack state (*)
>>> repeat for each target architecture
>>>    dispatch saving standalone message
>>>    modify stack for per-arch settings
>>>    deploy stack
>>>    restore to state in (*)
>>>    dispatch standalone saved message
>>> end repeat
>>> _______________________________________________
>>> use-livecode mailing list
>>> [hidden email]
>>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: savingStandalone message

Richard Gaskin
In reply to this post by Ben Rubinstein
Ben Rubinstein wrote:

 > Paul, I'd think that your needs (which certainly overlap with
 > mine...) could be met by adopting Ali's suggestion in that report
 > of a single message with parameter to indicate which platform was
 > being built for, if there was an additional parameter to indicate
 > that several standalones were being built at
 > once. Even if it was as crude as:
 > savingStandalone  "Windows", 1, 3
 > savingStandalone  "iOS", 2, 3
 > savingStandalone  "Android", 3, 3
 >
 > That would allow work to be done for the general case to be coded
 > once, even if it actually ran three times; platform-specific cases
 > to be handled; and if you wanted to do something like increment a
 > build number to be the same across platforms, you could increment
 > only for the "1/3" case.

Agreed.  Parameters allow for simpler implementation while still
delivering platform differentiation.

I'm less certain about the count params, and would favor a build number.
  But that would require that all of us use build numbers, and perhaps
some don't, so I'm not opposed either.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: savingStandalone message

Bob Sneidar-2
In reply to this post by Ali Lloyd-2
Okay my standalone building bug is probably related to this one. I can provide any testing and feedback you need on this. For instance, I just quit all versions of Livecode, opened LC 8.1.2 rc1, ONLY opened the splash stack and NOTHING ELSE, tried to compile, and I get this dialog:

A stack with the same name as the one you
are trying to load is a lready open.
Before loading
/Users/bobsneidar/Documents/livecode
Projects/Forms Generator
8/Libraries/sql_yoga.livecode, what do you
want to do with stack:
/Users/bobsneidar/Documents/livecode
Projects/Forms Generator 8/Forms
Generator/Windows/sql_yoga.livecode,
libSQLYoga?

Note the WINDOWS in the second file path. It looks like after it's done compiling for Windows, it is leaving the copied library in memory (why it would have that copy open I do not know), so that when it goes to comile for Mac a second library is open in memory and it wants to save/purge it. As I mentioned this started happening with 8.1.1.

Bob S


> On Nov 15, 2016, at 01:45 , Ali Lloyd <[hidden email]> wrote:
>
> Hi all,
>
> Various tweaks to the standalone builder seem to have broken the way the
> savingStandalone message is supposed to work
> http://quality.livecode.com/show_bug.cgi?id=18778
>
> I have submitted a pull request that fixes it - the only wrinkle might be
> that it reintroduces the following bug:
> http://quality.livecode.com/show_bug.cgi?id=18364, namely that the
> savingStandalone message gets sent for each build platform.
>
> Now, my personal view is that that is how it should work, provided the
> stack state is restored before building for the next platform. It allows a
> more fine-grained build step where, if we added suitable parameters to the
> message, you could for example ensure substacks with platform/architecture
> specific resources were not included in the standalones where they are
> irrelevant.
>
> My question to you is the same as I asked Lyn Teyla in the above report:
>
> Would the following behavior be a problem for your use case, and if so why?
>
> store stack state (*)
> repeat for each target architecture
>   dispatch saving standalone message
>   modify stack for per-arch settings
>   deploy stack
>   restore to state in (*)
>   dispatch standalone saved message
> end repeat
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: savingStandalone message

Bob Sneidar-2
I just compiled for Mac only and the dialog about the open library does not appear. However I am getting this runtime error:

Executing at 9:35:40 AM on Tuesday, November 15, 2016
Type: Handler: error in statement
Object: stack '/Applications/Forms Generator.app/Contents/MacOS/Forms Generator'
Line: go invisible to card 'Main' of stack 'Forms Generator'
Line Num: 12
Hint: openStack

Comments:

Remember this compiles on 8.0.1 some something dramatic has changed. And not in a good way.

Bob S


> On Nov 15, 2016, at 09:30 , Bob Sneidar <[hidden email]> wrote:
>
> Okay my standalone building bug is probably related to this one. I can provide any testing and feedback you need on this. For instance, I just quit all versions of Livecode, opened LC 8.1.2 rc1, ONLY opened the splash stack and NOTHING ELSE, tried to compile, and I get this dialog:
>
> A stack with the same name as the one you
> are trying to load is a lready open.
> Before loading
> /Users/bobsneidar/Documents/livecode
> Projects/Forms Generator
> 8/Libraries/sql_yoga.livecode, what do you
> want to do with stack:
> /Users/bobsneidar/Documents/livecode
> Projects/Forms Generator 8/Forms
> Generator/Windows/sql_yoga.livecode,
> libSQLYoga?
>
> Note the WINDOWS in the second file path. It looks like after it's done compiling for Windows, it is leaving the copied library in memory (why it would have that copy open I do not know), so that when it goes to comile for Mac a second library is open in memory and it wants to save/purge it. As I mentioned this started happening with 8.1.1.
>
> Bob S
>
>
>> On Nov 15, 2016, at 01:45 , Ali Lloyd <[hidden email]> wrote:
>>
>> Hi all,
>>
>> Various tweaks to the standalone builder seem to have broken the way the
>> savingStandalone message is supposed to work
>> http://quality.livecode.com/show_bug.cgi?id=18778
>>
>> I have submitted a pull request that fixes it - the only wrinkle might be
>> that it reintroduces the following bug:
>> http://quality.livecode.com/show_bug.cgi?id=18364, namely that the
>> savingStandalone message gets sent for each build platform.
>>
>> Now, my personal view is that that is how it should work, provided the
>> stack state is restored before building for the next platform. It allows a
>> more fine-grained build step where, if we added suitable parameters to the
>> message, you could for example ensure substacks with platform/architecture
>> specific resources were not included in the standalones where they are
>> irrelevant.
>>
>> My question to you is the same as I asked Lyn Teyla in the above report:
>>
>> Would the following behavior be a problem for your use case, and if so why?
>>
>> store stack state (*)
>> repeat for each target architecture
>>  dispatch saving standalone message
>>  modify stack for per-arch settings
>>  deploy stack
>>  restore to state in (*)
>>  dispatch standalone saved message
>> end repeat
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: savingStandalone message

Ben Rubinstein
In reply to this post by Richard Gaskin
On 15/11/2016 17:14, Richard Gaskin wrote:
> I'm less certain about the count params, and would favor a build number.
> But that would require that all of us use build numbers, and perhaps some
> don't, so I'm not opposed either.

To be clear, which I may not have been, my proposal was that the parameters
should allow the message handler to know
        - what platform this standalone is being built for
        - how many standalones are being built in a single pass, and whether this is
the first, last, or somewhere in between

The latter was really to support Paul's requirement to increment a build
number, which would be the same for all the standalones built in that pass,
but would be incremented on the next pass. There are certainly other ways to
achieve this.

If you're proposing that the LC IDE maintain a build number for every stack,
that might save a bit of effort for some sub-set of the audience which uses
build numbers; but for those who for whatever reason use build numbers or
similar in some scheme incompatible with the one provided, it might make
workarounds more complicated. I certainly wouldn't object to it as an
additional feature!

Ben

On 15/11/2016 17:14, Richard Gaskin wrote:

> Ben Rubinstein wrote:
>
>> Paul, I'd think that your needs (which certainly overlap with
>> mine...) could be met by adopting Ali's suggestion in that report
>> of a single message with parameter to indicate which platform was
>> being built for, if there was an additional parameter to indicate
>> that several standalones were being built at
>> once. Even if it was as crude as:
>>     savingStandalone  "Windows", 1, 3
>>     savingStandalone  "iOS", 2, 3
>>     savingStandalone  "Android", 3, 3
>>
>> That would allow work to be done for the general case to be coded
>> once, even if it actually ran three times; platform-specific cases
>> to be handled; and if you wanted to do something like increment a
>> build number to be the same across platforms, you could increment
>> only for the "1/3" case.
>
> Agreed.  Parameters allow for simpler implementation while still delivering
> platform differentiation.
>
> I'm less certain about the count params, and would favor a build number.  But
> that would require that all of us use build numbers, and perhaps some don't,
> so I'm not opposed either.
>

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: savingStandalone message

Dr. Hawkins
In reply to this post by Richard Gaskin
On Tue, Nov 15, 2016 at 9:14 AM, Richard Gaskin <[hidden email]>
wrote:

> I'm less certain about the count params, and would favor a build number.
> But that would require that all of us use build numbers, and perhaps some
> don't, so I'm not opposed either.


I would like to see flexibility on this.   Personally, my stacks are
named/labeled with YYMMDDv as part of the name, where v start with "a" for
the first version that day.

I build from several stacks, but the standalone picks up the version of my
control stack.

(The naming format comes from my law practices, which causes them to sort
properly/easily.  My paralegal was shocked/awed when her instructor taught
her what I already made her do :)


--
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: savingStandalone message

Richard Gaskin
In reply to this post by Ben Rubinstein
Ben Rubinstein wrote:

 > If you're proposing that the LC IDE maintain a build number for every
 > stack, that might save a bit of effort for some sub-set of the
 > audience which uses build numbers; but for those who for whatever
 > reason use build numbers or similar in some scheme incompatible with
 > the one provided, it might make workarounds more complicated. I
 > certainly wouldn't object to it as an additional feature!

Agreed on both counts:  desirable, but not currently universal enough to
matter to some.

I've adopted build numbers separate from version numbers years ago.
Version numbers are useful for communicating change to humans, and build
numbers provide a simple means of communicating change among automated
processes.

Many years ago Ken Ray wrote a very comprehensive function for comparing
version numbers that accommodates a wide range of common schemes, but
there are always variants, and the schemes he covers require a *lot* of
code.

For automated processes, hard to beat the simplicity of a single integer
value.

But I can appreciate that some may not maintain both a version number
and a build number, and it's not my place to require that they do.

So I'm not opposed to any params sent with a savingStandalone message
that work well for most folks.  The platform distinction is a must, and
I'd love to have the destination path, but beyond that I can take care
of my own needs well enough.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: savingStandalone message

Ali Lloyd-2
I was thinking a parameter array would be better than many additional
params. That way, additional info is cheap.

So currently the proposed params are:
- current build platform
- current build target/architecture (to disambiguate between 32 bit/64
bit/both)
- total number of standalones to build
- which standalone of the total is being built
- build folder

Richard, what's the rationale for having the target folder before the
standalone is built, considering you get the folder as a parameter to
standaloneSaved? It *sort of* strikes me as a recipe for disaster, but
that's just a feeling I'm getting.

On Tue, Nov 15, 2016 at 7:28 PM Richard Gaskin <[hidden email]>
wrote:

> Ben Rubinstein wrote:
>
>  > If you're proposing that the LC IDE maintain a build number for every
>  > stack, that might save a bit of effort for some sub-set of the
>  > audience which uses build numbers; but for those who for whatever
>  > reason use build numbers or similar in some scheme incompatible with
>  > the one provided, it might make workarounds more complicated. I
>  > certainly wouldn't object to it as an additional feature!
>
> Agreed on both counts:  desirable, but not currently universal enough to
> matter to some.
>
> I've adopted build numbers separate from version numbers years ago.
> Version numbers are useful for communicating change to humans, and build
> numbers provide a simple means of communicating change among automated
> processes.
>
> Many years ago Ken Ray wrote a very comprehensive function for comparing
> version numbers that accommodates a wide range of common schemes, but
> there are always variants, and the schemes he covers require a *lot* of
> code.
>
> For automated processes, hard to beat the simplicity of a single integer
> value.
>
> But I can appreciate that some may not maintain both a version number
> and a build number, and it's not my place to require that they do.
>
> So I'm not opposed to any params sent with a savingStandalone message
> that work well for most folks.  The platform distinction is a must, and
> I'd love to have the destination path, but beyond that I can take care
> of my own needs well enough.
>
> --
>   Richard Gaskin
>   Fourth World Systems
>   Software Design and Development for the Desktop, Mobile, and the Web
>   ____________________________________________________________________
>   [hidden email]                http://www.FourthWorld.com
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: savingStandalone message

Richard Gaskin
Ali Lloyd wrote:

 > I was thinking a parameter array would be better than many additional
 > params. That way, additional info is cheap.
 >
 > So currently the proposed params are:
 > - current build platform
 > - current build target/architecture (to disambiguate between 32 bit/64
 > bit/both)
 > - total number of standalones to build
 > - which standalone of the total is being built
 > - build folder

That all sounds very good to me.

 > Richard, what's the rationale for having the target folder before the
 > standalone is built, considering you get the folder as a parameter to
 > standaloneSaved? It *sort of* strikes me as a recipe for disaster, but
 > that's just a feeling I'm getting.

I was actually thinking of the other message, standaloneSaved.
Currently we get an incomplete path, and have to guess what the part
will be for each OS.  Most of the time we can guess correctly, but if
that ever changes we need to guess again.  If we just had the complete
path to the folder containing the freshly-build executable we'd be done
with guessing altogether.

Middle ground: if we kept the partial path as it is now, and added a
platform param to standaloneSaved as proposed for savingStandalone, and
if that param was also the exact name of the target subfolder, I'd be
quite happy.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: savingStandalone message

Ali Lloyd-2
Ah yes, I had unthinkingly just corrected the folder parameter to
standaloneSaved, but I will have to do it in the array data for backwards
compatibility I suppose.

On Tue, Nov 15, 2016 at 8:51 PM Richard Gaskin <[hidden email]>
wrote:

> Ali Lloyd wrote:
>
>  > I was thinking a parameter array would be better than many additional
>  > params. That way, additional info is cheap.
>  >
>  > So currently the proposed params are:
>  > - current build platform
>  > - current build target/architecture (to disambiguate between 32 bit/64
>  > bit/both)
>  > - total number of standalones to build
>  > - which standalone of the total is being built
>  > - build folder
>
> That all sounds very good to me.
>
>  > Richard, what's the rationale for having the target folder before the
>  > standalone is built, considering you get the folder as a parameter to
>  > standaloneSaved? It *sort of* strikes me as a recipe for disaster, but
>  > that's just a feeling I'm getting.
>
> I was actually thinking of the other message, standaloneSaved.
> Currently we get an incomplete path, and have to guess what the part
> will be for each OS.  Most of the time we can guess correctly, but if
> that ever changes we need to guess again.  If we just had the complete
> path to the folder containing the freshly-build executable we'd be done
> with guessing altogether.
>
> Middle ground: if we kept the partial path as it is now, and added a
> platform param to standaloneSaved as proposed for savingStandalone, and
> if that param was also the exact name of the target subfolder, I'd be
> quite happy.
>
> --
>   Richard Gaskin
>   Fourth World Systems
>   Software Design and Development for the Desktop, Mobile, and the Web
>   ____________________________________________________________________
>   [hidden email]                http://www.FourthWorld.com
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: savingStandalone message

Paul Dupuis
In reply to this post by Ali Lloyd-2
On 11/15/2016 3:41 PM, Ali Lloyd wrote:

> I was thinking a parameter array would be better than many additional
> params. That way, additional info is cheap.
>
> So currently the proposed params are:
> - current build platform
> - current build target/architecture (to disambiguate between 32 bit/64
> bit/both)
> - total number of standalones to build
> - which standalone of the total is being built
> - build folder

This would be a great enhancement to have this additional data. Once of
the beautiful things about LiveCode is that many of the messages have
optional parameters (new size with resizeStack, mouseButtonNumber with
mouseDown/mouseUp/etc. and so on. If you don't need them, you just
ignore them, but they are always there when you do need them. It is an
underrated 'feature' of the language that makes it so easy to use.



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: savingStandalone message

Ben Rubinstein
On 15/11/2016 22:48, Paul Dupuis wrote:

> On 11/15/2016 3:41 PM, Ali Lloyd wrote:
>> I was thinking a parameter array would be better than many additional
>> params. That way, additional info is cheap.
>>
>> So currently the proposed params are:
>> - current build platform
>> - current build target/architecture (to disambiguate between 32 bit/64
>> bit/both)
>> - total number of standalones to build
>> - which standalone of the total is being built
>> - build folder
>
> This would be a great enhancement to have this additional data. Once of
> the beautiful things about LiveCode is that many of the messages have
> optional parameters (new size with resizeStack, mouseButtonNumber with
> mouseDown/mouseUp/etc. and so on. If you don't need them, you just
> ignore them, but they are always there when you do need them. It is an
> underrated 'feature' of the language that makes it so easy to use.

+1!

Ben

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Signing an application for distribution outside the Mac App Store

Richard Miller-5
In reply to this post by Richard Gaskin
I am following the livecode instructions for "Signing an application for
distribution outside the Mac App Store".

When I run this in terminal:

       codesign -s "Developer ID Application: My Company"
/Path/To/My/Application.app

.... I get back this error message: "resource fork, Finder information,
or similar detritus not allowed"

I am trying to sign a LC app built in LC 8.0.0 dp16 running under OS
Sierra and XCode 8.1.

Thoughts?

Thanks,
Richard Miller

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: savingStandalone message

Dave Kilroy
In reply to this post by Ali Lloyd-2
Hi all

Ali I would find it really useful if we could set a build number for iOS builds inside the plist file where I’m using the 'external test’ functionality in TestFlight

I normally use my own way of setting and recording build numbers - and I’m happy to carry on doing do. But where there’s a problem is that there is currently no way to indicate to iTunesConnect what an app’s build number is as a separate value to the app’s version number (see http://quality.livecode.com/show_bug.cgi?id=14163 <http://quality.livecode.com/show_bug.cgi?id=14163>) - this means we can’t upload incremented binaries of the same version number to iTunesConnect for rapid deployment via TestFlight, and must instead upload an incremented version and then wait around three days for it to exit ‘Beta review'

So, if you are making changes to the standalone builder and including an option for build number could you bear TestFlight in mind?

Kind regards

Dave



> Thanks for the feedback Paul. How is your build number increment
> implemented?
>
> On Tue, Nov 15, 2016 at 1:18 PM Paul Dupuis <[hidden email] <http://runtime-revolution.278305.n4.nabble.com/user/SendEmail.jtp?type=node&node=4710301&i=0>> wrote:
>
> > I make use of the savingStandalone message in a few projects. Generally,
> > I would prefer a single message regardless of the number of platforms I
> > am building for. For ecample, I set a incremental "build' number on
> > savingStandalone and I would want that build number to be the same for
> > all platforms built for. If the message was sent for each platform I
> > suspect I could come up with some what to still do this, but the code
> > complexity would increase for a relatively simple task.
> >
> > It would seem to me that if you are looking for platform specific
> > actions to modify the stack(s) used in each platform build, then ideally
> > you would want a set of platform specific messages. i.e
> >
> > savingStandaloneForWindows
> > savingStandaloneForOSX
> > savingStandaloneForiOS
> > savingStandaloneForAndroid
> > savingStandaloneForHTML5
> > ...
> >
> > Or something like that. That way if you only meed to make a specific
> > scripted stack modification for Android, you only need to handle that
> > specific message.
> >
> >
> > On 11/15/2016 4:45 AM, Ali Lloyd wrote:
> > > Hi all,
> > >
> > > Various tweaks to the standalone builder seem to have broken the way the
> > > savingStandalone message is supposed to work
> > > http://quality.livecode.com/show_bug.cgi?id=18778 <http://quality.livecode.com/show_bug.cgi?id=18778>
> > >
> > > I have submitted a pull request that fixes it - the only wrinkle might be
> > > that it reintroduces the following bug:
> > > http://quality.livecode.com/show_bug.cgi?id=18364 <http://quality.livecode.com/show_bug.cgi?id=18364>, namely that the
> > > savingStandalone message gets sent for each build platform.
> > >
> > > Now, my personal view is that that is how it should work, provided the
> > > stack state is restored before building for the next platform. It allows
> > a
> > > more fine-grained build step where, if we added suitable parameters to
> > the
> > > message, you could for example ensure substacks with
> > platform/architecture
> > > specific resources were not included in the standalones where they are
> > > irrelevant.
> > >
> > > My question to you is the same as I asked Lyn Teyla in the above report:
> > >
> > > Would the following behavior be a problem for your use case, and if so
> > why?
> > >
> > > store stack state (*)
> > > repeat for each target architecture
> > >    dispatch saving standalone message
> > >    modify stack for per-arch settings
> > >    deploy stack
> > >    restore to state in (*)
> > >    dispatch standalone saved message
> > > end repeat
> > > _______________________________________________
> > > use-livecode mailing list
> > > [hidden email] <http://runtime-revolution.278305.n4.nabble.com/user/SendEmail.jtp?type=node&node=4710301&i=1>
> > > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > > http://lists.runrev.com/mailman/listinfo/use-livecode <http://lists.runrev.com/mailman/listinfo/use-livecode>
> > >
> >
> >
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email] <http://runtime-revolution.278305.n4.nabble.com/user/SendEmail.jtp?type=node&node=4710301&i=2>
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode <http://lists.runrev.com/mailman/listinfo/use-livecode>
> >

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
"The first 90% of the task takes 90% of the time, and the last 10% takes the other 90% of the time."
Peter M. Brigham
Reply | Threaded
Open this post in threaded view
|

Re: savingStandalone message

Bob Sneidar-2
In reply to this post by Bob Sneidar-2
Just discovered that the reason for this is that the compiler somehow changed the path to the mainstack in the Stack Properties Stack Files. What the...??? I reset the path to the main stack and now I can compile.

Bob S


On Nov 15, 2016, at 09:37 , Bob Sneidar <[hidden email]<mailto:[hidden email]>> wrote:

I just compiled for Mac only and the dialog about the open library does not appear. However I am getting this runtime error:

Executing at 9:35:40 AM on Tuesday, November 15, 2016
Type: Handler: error in statement
Object: stack '/Applications/Forms Generator.app/Contents/MacOS/Forms Generator'
Line: go invisible to card 'Main' of stack 'Forms Generator'
Line Num: 12
Hint: openStack

Comments:

Remember this compiles on 8.0.1 some something dramatic has changed. And not in a good way.

Bob S

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

AW: Signing an application for distribution outside the Mac App Store

Tiemo Hollmann TB
In reply to this post by Richard Miller-5
I don't know, if thats the issue for this error message, but as the name of
the certificate you should only use "My Company", not "Developer ID
Application: My Company"
Tiemo

-----Ursprüngliche Nachricht-----
Von: use-livecode [mailto:[hidden email]] Im Auftrag
von Richard Miller
Gesendet: Mittwoch, 16. November 2016 02:49
An: How to use LiveCode <[hidden email]>
Betreff: Signing an application for distribution outside the Mac App Store

I am following the livecode instructions for "Signing an application for
distribution outside the Mac App Store".

When I run this in terminal:

       codesign -s "Developer ID Application: My Company"
/Path/To/My/Application.app

.... I get back this error message: "resource fork, Finder information, or
similar detritus not allowed"

I am trying to sign a LC app built in LC 8.0.0 dp16 running under OS Sierra
and XCode 8.1.

Thoughts?

Thanks,
Richard Miller

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode