Re: Making "read from file" less blocky.

[Jerry Jensen via use-livecode]

Memory returns slowly… 
I take back what I said about eof maybe working for serial ports. I’m pretty 
sure it doesn’t. When I did this before I was taking data from 2 incoming 
asynchronous serial ports, one then the other then repeat. They only had tiny 
buffers, so I had to read small pieces of data from each with minimum delays 
between. When nobody was talking I handled the accumulated data. 

It it is!
.Jerry

> On Aug 3, 2019, at 8:02 PM, Tom Glod via use-livecode 
>  wrote:
> 
> Jerry, that simple tweak worked to improve the performance of the UI a
> great deal.. its a slower method of loading...but not too slow
> to use as background loading. ...Its actually better than what I
> expected.   Awesome.
> I always love to use the forever loop. its just so fun to write. lol
> I gotta get some error handling in there but thats another story.
> Consider this one SOLVED. Thanks again.
> 
> 
> 
> On Sat, Aug 3, 2019 at 10:47 PM Tom Glod  wrote:
> 
>> Dar, Yes...I understand.it is a blocking operation no matter what I
>> can just introduce breaks in the blockiness.  So I'm not expecting a socket
>> like experience for sure.
>> 
>> Those are very good suggestions to try thank you.
>> 
>> Jerry, I will give that a try, it looks promising.even a little
>> improvement would be better and sufficient for this need, and I can use it
>> sparingly.  Thanks alot!  Onward indeed.
>> 
>> On Sat, Aug 3, 2019 at 10:36 PM Jerry Jensen via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> 
>>> Hi Tom,
>>> 
>>> I’ve done this in the past watching it instead of the result. I seem to
>>> remember eof was not useful. Maybe for a serial port it would be?
>>> 
>>> As in:
>>> 
>>> repeat forever
>>>  read from file ThisFile for (1024 * 1000) bytes
>>>  if it is empty then exit repeat
>>> — do your stuff
>>>  wait 0 with messages
>>> end repeat
>>> 
>>> Onward,
>>> .Jerry non-sphere (tetrahedron?)
>>> 
>>> It was a long time ago in, I think, LC 5, so YMMV.
>>> 
>>> 
 On Aug 3, 2019, at 5:56 PM, Tom Glod via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
 
 Hey folks,
 
 I'm having trouble finding a combination of settings that allows my file
 loading  to seem to happen in the background.
 
 repeat while read_result is not "eof"
read from file ThisFile for (1024 * 1000) bytes
put the result into read_result
put it after IntoThisVariable
add length(it) to amount_read
TSTProgress amount_read,ExpectedSize,"%","Loading File ..."
 (Progress Indicator Handler)
wait 10 milliseconds with messages
 end repeat
 
 no matter what I try, its still sluggish, and it seems like messages are
 still accumilating instead of being processed by the engine.
 
 Am I missing something?  Normally waiting with messages sufficiently
>>> frees
 the engine to allow the UI to remain responsive.
 
 Thanks,
 
 Tom
 ___
 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
>> 
>> 
> ___
> 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: Updated Lesson and new Notarization Helper Stack

[Tom Glod via use-livecode]

Hats off to you again sir Matthias. Thank you



On Sat, Aug 3, 2019 at 4:34 PM J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I wasn't aware of the AppWrapper update, but yours not only works
> seamlessly with LC, but it's free. That's a big plus, and you're
> generous to provide it to us.
>
> On 8/3/19 3:14 PM, Matthias Rebbe via use-livecode wrote:
> > Jacque, thank you very much for your kind words.
> >
> > To be fair, App Wrapper 3.9.1, which is able to notarize, was released
> some days ago.
> >
> > Regards,
> > Matthias
> >
> > Matthias Rebbe
> >
> > free tools for Livecoders:
> > InstaMaker 
> > WinSignMaker Mac 
> >
> >> Am 03.08.2019 um 21:58 schrieb J. Landman Gay via use-livecode <
> use-livecode@lists.runrev.com >:
> >>
> >> If you need to notarize a Mac app, this thing is a marvel. I was
> nervous about getting through Apple's new requirements for app distribution
> but Notarization Helper is as simple as it gets. I'd used AppWrapper in the
> past, but the new notarization and stapling process isn't included there
> yet, at least until AppWrapper comes out of beta. Matthias has made an
> all-in-one solution that requires nothing from the user but a couple of
> bits of info and a mouse click, and it works right within the LC IDE.
> >>
> >> This is a keeper. If you are distributing outside the Macc App Store,
> go get it.
> >>
> >> On 8/3/19 2:30 PM, Matthias Rebbe via use-livecode wrote:
> >>> For those who are interested.
> >>> Today i´ve updated the Lesson on How to code sign and Notarize an app
> for distribution outside of the Mac Appstore. I´ve also included an updated
> version of my stack. The new version is now able to to the complete stuff
> from code signing up to notarizing and stapling your app or dmg.
> >>> You just drap your app to the stack, enter some data and the stack
> does all the rest for you.
> >>> The new lesson can be found here <
> http://lessons.livecode.com/m/4071/l/1122100-codesigning-and-notarizing-your-lc-standalone-for-distribution-outside-the-mac-appstore
> <
> http://lessons.livecode.com/m/4071/l/1122100-codesigning-and-notarizing-your-lc-standalone-for-distribution-outside-the-mac-appstore
> >>.
> >>> Hope this is of some use for the one or the other.
> >>> Regards,
> >>> Matthias
> >>> ___
> >>> 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
> >>
> >>
> >> --
> >> Jacqueline Landman Gay | jac...@hyperactivesw.com  jac...@hyperactivesw.com>
> >> HyperActive Software   | http://www.hyperactivesw.com <
> 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
> >
> > ___
> > 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
> >
>
>
> --
> 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
___
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: Making "read from file" less blocky.

[Tom Glod via use-livecode]

Jerry, that simple tweak worked to improve the performance of the UI a
great deal.. its a slower method of loading...but not too slow
to use as background loading. ...Its actually better than what I
expected.   Awesome.
I always love to use the forever loop. its just so fun to write. lol
I gotta get some error handling in there but thats another story.
Consider this one SOLVED. Thanks again.



On Sat, Aug 3, 2019 at 10:47 PM Tom Glod  wrote:

> Dar, Yes...I understand.it is a blocking operation no matter what I
> can just introduce breaks in the blockiness.  So I'm not expecting a socket
> like experience for sure.
>
> Those are very good suggestions to try thank you.
>
> Jerry, I will give that a try, it looks promising.even a little
> improvement would be better and sufficient for this need, and I can use it
> sparingly.  Thanks alot!  Onward indeed.
>
> On Sat, Aug 3, 2019 at 10:36 PM Jerry Jensen via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> Hi Tom,
>>
>> I’ve done this in the past watching it instead of the result. I seem to
>> remember eof was not useful. Maybe for a serial port it would be?
>>
>> As in:
>>
>> repeat forever
>>   read from file ThisFile for (1024 * 1000) bytes
>>   if it is empty then exit repeat
>> — do your stuff
>>   wait 0 with messages
>> end repeat
>>
>> Onward,
>> .Jerry non-sphere (tetrahedron?)
>>
>> It was a long time ago in, I think, LC 5, so YMMV.
>>
>>
>> > On Aug 3, 2019, at 5:56 PM, Tom Glod via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> >
>> > Hey folks,
>> >
>> > I'm having trouble finding a combination of settings that allows my file
>> > loading  to seem to happen in the background.
>> >
>> >  repeat while read_result is not "eof"
>> > read from file ThisFile for (1024 * 1000) bytes
>> > put the result into read_result
>> > put it after IntoThisVariable
>> > add length(it) to amount_read
>> > TSTProgress amount_read,ExpectedSize,"%","Loading File ..."
>> > (Progress Indicator Handler)
>> > wait 10 milliseconds with messages
>> >  end repeat
>> >
>> > no matter what I try, its still sluggish, and it seems like messages are
>> > still accumilating instead of being processed by the engine.
>> >
>> > Am I missing something?  Normally waiting with messages sufficiently
>> frees
>> > the engine to allow the UI to remain responsive.
>> >
>> > Thanks,
>> >
>> > Tom
>> > ___
>> > 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
>
>
___
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: Making "read from file" less blocky.

[Tom Glod via use-livecode]

 Dar, Yes...I understand.it is a blocking operation no matter what I
can just introduce breaks in the blockiness.  So I'm not expecting a socket
like experience for sure.

Those are very good suggestions to try thank you.

Jerry, I will give that a try, it looks promising.even a little
improvement would be better and sufficient for this need, and I can use it
sparingly.  Thanks alot!  Onward indeed.

On Sat, Aug 3, 2019 at 10:36 PM Jerry Jensen via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hi Tom,
>
> I’ve done this in the past watching it instead of the result. I seem to
> remember eof was not useful. Maybe for a serial port it would be?
>
> As in:
>
> repeat forever
>   read from file ThisFile for (1024 * 1000) bytes
>   if it is empty then exit repeat
> — do your stuff
>   wait 0 with messages
> end repeat
>
> Onward,
> .Jerry non-sphere (tetrahedron?)
>
> It was a long time ago in, I think, LC 5, so YMMV.
>
>
> > On Aug 3, 2019, at 5:56 PM, Tom Glod via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Hey folks,
> >
> > I'm having trouble finding a combination of settings that allows my file
> > loading  to seem to happen in the background.
> >
> >  repeat while read_result is not "eof"
> > read from file ThisFile for (1024 * 1000) bytes
> > put the result into read_result
> > put it after IntoThisVariable
> > add length(it) to amount_read
> > TSTProgress amount_read,ExpectedSize,"%","Loading File ..."
> > (Progress Indicator Handler)
> > wait 10 milliseconds with messages
> >  end repeat
> >
> > no matter what I try, its still sluggish, and it seems like messages are
> > still accumilating instead of being processed by the engine.
> >
> > Am I missing something?  Normally waiting with messages sufficiently
> frees
> > the engine to allow the UI to remain responsive.
> >
> > Thanks,
> >
> > Tom
> > ___
> > 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
___
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: Making "read from file" less blocky.

[Jerry Jensen via use-livecode]

Hi Tom,

I’ve done this in the past watching it instead of the result. I seem to 
remember eof was not useful. Maybe for a serial port it would be?

As in:

repeat forever
  read from file ThisFile for (1024 * 1000) bytes
  if it is empty then exit repeat
— do your stuff
  wait 0 with messages
end repeat

Onward,
.Jerry non-sphere (tetrahedron?)

It was a long time ago in, I think, LC 5, so YMMV.


> On Aug 3, 2019, at 5:56 PM, Tom Glod via use-livecode 
>  wrote:
> 
> Hey folks,
> 
> I'm having trouble finding a combination of settings that allows my file
> loading  to seem to happen in the background.
> 
>  repeat while read_result is not "eof"
> read from file ThisFile for (1024 * 1000) bytes
> put the result into read_result
> put it after IntoThisVariable
> add length(it) to amount_read
> TSTProgress amount_read,ExpectedSize,"%","Loading File ..."
> (Progress Indicator Handler)
> wait 10 milliseconds with messages
>  end repeat
> 
> no matter what I try, its still sluggish, and it seems like messages are
> still accumilating instead of being processed by the engine.
> 
> Am I missing something?  Normally waiting with messages sufficiently frees
> the engine to allow the UI to remain responsive.
> 
> Thanks,
> 
> Tom
> ___
> 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: Making "read from file" less blocky.

[Dar Scott Consulting via use-livecode]

Alas, only read from socket allows a message to be sent upon completion. The 
step siblings read from file, read from process and read from driver do not.

Here are a few things you might do:

1. Try making the file loading very fast and don't do it in the background. 
Change the cursor if need be.  Try using URL with file: or binfile:, maybe that 
is fast.

2. Use a "send loop" to read in portions and update a progress bar. You can get 
help here on how to do that.

3. Process the file lazily and bring in parts as needed.

4. Figure out how to make the file read through networking. Somehow. Maybe.


> On Aug 3, 2019, at 6:56 PM, Tom Glod via use-livecode 
>  wrote:
> 
> Hey folks,
> 
> I'm having trouble finding a combination of settings that allows my file
> loading  to seem to happen in the background.
> 
>  repeat while read_result is not "eof"
> read from file ThisFile for (1024 * 1000) bytes
> put the result into read_result
> put it after IntoThisVariable
> add length(it) to amount_read
> TSTProgress amount_read,ExpectedSize,"%","Loading File ..."
> (Progress Indicator Handler)
> wait 10 milliseconds with messages
>  end repeat
> 
> no matter what I try, its still sluggish, and it seems like messages are
> still accumilating instead of being processed by the engine.
> 
> Am I missing something?  Normally waiting with messages sufficiently frees
> the engine to allow the UI to remain responsive.
> 
> Thanks,
> 
> Tom
> ___
> 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

Making "read from file" less blocky.

[Tom Glod via use-livecode]

Hey folks,

I'm having trouble finding a combination of settings that allows my file
loading  to seem to happen in the background.

  repeat while read_result is not "eof"
 read from file ThisFile for (1024 * 1000) bytes
 put the result into read_result
 put it after IntoThisVariable
 add length(it) to amount_read
 TSTProgress amount_read,ExpectedSize,"%","Loading File ..."
(Progress Indicator Handler)
 wait 10 milliseconds with messages
  end repeat

no matter what I try, its still sluggish, and it seems like messages are
still accumilating instead of being processed by the engine.

Am I missing something?  Normally waiting with messages sufficiently frees
the engine to allow the UI to remain responsive.

Thanks,

Tom
___
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: Updated Lesson and new Notarization Helper Stack

[J. Landman Gay via use-livecode]

I wasn't aware of the AppWrapper update, but yours not only works 
seamlessly with LC, but it's free. That's a big plus, and you're 
generous to provide it to us.


On 8/3/19 3:14 PM, Matthias Rebbe via use-livecode wrote:

Jacque, thank you very much for your kind words.

To be fair, App Wrapper 3.9.1, which is able to notarize, was released some 
days ago.

Regards,
Matthias

Matthias Rebbe

free tools for Livecoders:
InstaMaker 
WinSignMaker Mac 


Am 03.08.2019 um 21:58 schrieb J. Landman Gay via use-livecode 
mailto:use-livecode@lists.runrev.com>>:

If you need to notarize a Mac app, this thing is a marvel. I was nervous about 
getting through Apple's new requirements for app distribution but Notarization 
Helper is as simple as it gets. I'd used AppWrapper in the past, but the new 
notarization and stapling process isn't included there yet, at least until 
AppWrapper comes out of beta. Matthias has made an all-in-one solution that 
requires nothing from the user but a couple of bits of info and a mouse click, 
and it works right within the LC IDE.

This is a keeper. If you are distributing outside the Macc App Store, go get it.

On 8/3/19 2:30 PM, Matthias Rebbe via use-livecode wrote:

For those who are interested.
Today i´ve updated the Lesson on How to code sign and Notarize an app for 
distribution outside of the Mac Appstore. I´ve also included an updated version 
of my stack. The new version is now able to to the complete stuff from code 
signing up to notarizing and stapling your app or dmg.
You just drap your app to the stack, enter some data and the stack does all the 
rest for you.
The new lesson can be found here 
>.
Hope this is of some use for the one or the other.
Regards,
Matthias
___
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



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


___
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




--
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: Updated Lesson and new Notarization Helper Stack

[Matthias Rebbe via use-livecode]

Jacque, thank you very much for your kind words.

To be fair, App Wrapper 3.9.1, which is able to notarize, was released some 
days ago. 

Regards,
Matthias

Matthias Rebbe

free tools for Livecoders:
InstaMaker 
WinSignMaker Mac 

> Am 03.08.2019 um 21:58 schrieb J. Landman Gay via use-livecode 
> mailto:use-livecode@lists.runrev.com>>:
> 
> If you need to notarize a Mac app, this thing is a marvel. I was nervous 
> about getting through Apple's new requirements for app distribution but 
> Notarization Helper is as simple as it gets. I'd used AppWrapper in the past, 
> but the new notarization and stapling process isn't included there yet, at 
> least until AppWrapper comes out of beta. Matthias has made an all-in-one 
> solution that requires nothing from the user but a couple of bits of info and 
> a mouse click, and it works right within the LC IDE.
> 
> This is a keeper. If you are distributing outside the Macc App Store, go get 
> it.
> 
> On 8/3/19 2:30 PM, Matthias Rebbe via use-livecode wrote:
>> For those who are interested.
>> Today i´ve updated the Lesson on How to code sign and Notarize an app for 
>> distribution outside of the Mac Appstore. I´ve also included an updated 
>> version of my stack. The new version is now able to to the complete stuff 
>> from code signing up to notarizing and stapling your app or dmg.
>> You just drap your app to the stack, enter some data and the stack does all 
>> the rest for you.
>> The new lesson can be found here 
>> >  
>> >.
>> Hope this is of some use for the one or the other.
>> Regards,
>> Matthias
>> ___
>> 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
> 
> 
> -- 
> 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

___
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: Updated Lesson and new Notarization Helper Stack

[J. Landman Gay via use-livecode]

If you need to notarize a Mac app, this thing is a marvel. I was nervous 
about getting through Apple's new requirements for app distribution but 
Notarization Helper is as simple as it gets. I'd used AppWrapper in the 
past, but the new notarization and stapling process isn't included there 
yet, at least until AppWrapper comes out of beta. Matthias has made an 
all-in-one solution that requires nothing from the user but a couple of 
bits of info and a mouse click, and it works right within the LC IDE.


This is a keeper. If you are distributing outside the Macc App Store, go 
get it.


On 8/3/19 2:30 PM, Matthias Rebbe via use-livecode wrote:

For those who are interested.

Today i´ve updated the Lesson on How to code sign and Notarize an app for 
distribution outside of the Mac Appstore. I´ve also included an updated version 
of my stack. The new version is now able to to the complete stuff from code 
signing up to notarizing and stapling your app or dmg.

You just drap your app to the stack, enter some data and the stack does all the 
rest for you.

The new lesson can be found here 
.

Hope this is of some use for the one or the other.


Regards,

Matthias


___
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




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

Updated Lesson and new Notarization Helper Stack

[Matthias Rebbe via use-livecode]

For those who are interested.

Today i´ve updated the Lesson on How to code sign and Notarize an app for 
distribution outside of the Mac Appstore. I´ve also included an updated version 
of my stack. The new version is now able to to the complete stuff from code 
signing up to notarizing and stapling your app or dmg.

You just drap your app to the stack, enter some data and the stack does all the 
rest for you.

The new lesson can be found here 
.

Hope this is of some use for the one or the other.


Regards,

Matthias


___
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: "template" stack in custom property

[Klaus major-k via use-livecode]

Hi guys,

> Am 03.08.2019 um 17:19 schrieb Paul Dupuis via use-livecode 
> :
> On 8/2/2019 10:33 PM, ambassador--- via use-livecode wrote:
>> What are the advantage of instantiating the new stack from data in a prop 
>> rather than by cloning a substack?
> That was my question too.

well the first approach is much much cooler than the latter one, innit? :-)

Jokes aside, one advantage is that someone else can create that "template" 
stack, my
customer in this case, and since this is a separate stack file it can thus 
contain substacks, 
which can be another big advantage in some situations.

> It is a very different way of storing a stack.

I have never been representative. 8-)

> I imagine that an: open invisible stack (the cSavedStack of stack 
> "someOtherStack")
> would be like a open invisible URL 

Yes.

> in that it has to be loaded into memory, so it it is not the last line of the 
> script, I would expect it should be followed by a "wait  with 
> messages" to allow all the new stack messages to fire.

But as I wrote, if I load a stack from my hd, everything works as advertised!?
Anyway, I have a nice workaround and a happy customer.

Have a nice weekend.


Best

Klaus

--
Klaus Major
https://www.major-k.de
kl...@major-k.de


___
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: Save Standalone Settings Externally

[Mark Wieder via use-livecode]

On 8/3/19 7:53 AM, Brian Milby via use-livecode wrote:

No, that is a required file for the app and needs to be in the repo.


Ah. My bad. I assumed the .app was the standalone itself.

--
 Mark Wieder
 ahsoftw...@gmail.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: "template" stack in custom property

[Paul Dupuis via use-livecode]

On 8/2/2019 10:33 PM, ambassador--- via use-livecode wrote:
What are the advantage of instantiating the new stack from data in a 
prop rather than by cloning a substack?




That was my question too.

It is a very different way of storing a stack.

I imagine that an: open invisible stack (the cSavedStack of stack 
"someOtherStack")

would be like a open invisible URL 
in that it has to be loaded into memory, so it it is not the last line 
of the script, I would expect it should be followed by a "wait 
 with messages" to allow all the new stack messages to fire.


___
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: Save Standalone Settings Externally

[Brian Milby via use-livecode]

No, that is a required file for the app and needs to be in the repo.

Thanks,
Brian
On Aug 3, 2019, 10:40 AM -0400, Mark Wieder via use-livecode 
, wrote:
> On 8/3/19 7:14 AM, Sannyasin Brahmanathaswami via use-livecode wrote:
> > When working collaborately with a framework on Git Hub. There is always an 
> > issue of the stack that will be made the standalone for the app.
> >
> > No changes are made to binary MyMainStack.app other than settings in the 
> > standalone, which you may does simply for testing.
> >
> > Now, if you "pull" the project in Git Hub, you are prompted that the 
> > changes to MyMainStack.app need to be committed…etc. if you do, then you 
> > will get a conflict when you will pull. So the usual practice (for me 
> > anyway) is to
>
> Do you already have MyMainStack.app in your (and your team's) .gitignore
> file?
>
> --
> Mark Wieder
> ahsoftw...@gmail.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
___
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: Save Standalone Settings Externally

[Mark Wieder via use-livecode]

On 8/3/19 7:14 AM, Sannyasin Brahmanathaswami via use-livecode wrote:

When working collaborately with a framework on Git Hub. There is always an 
issue of the stack that will be made the standalone for the app.

No changes are made to binary MyMainStack.app other than settings in the 
standalone, which you may does simply for testing.

Now, if you "pull" the project in Git Hub, you are prompted that the changes to 
MyMainStack.app need to be committed…etc.  if you do, then you will get a conflict when 
you will pull. So the usual practice (for me anyway) is to


Do you already have MyMainStack.app in your (and your team's) .gitignore 
file?


--
 Mark Wieder
 ahsoftw...@gmail.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

Save Standalone Settings Externally

[Sannyasin Brahmanathaswami via use-livecode]

When working collaborately with a framework on Git Hub. There is always an 
issue of the stack that will be made the standalone for the app.

No changes are made to binary MyMainStack.app other than settings in the 
standalone, which you may does simply for testing.

Now, if you "pull" the project in Git Hub, you are prompted that the changes to 
MyMainStack.app need to be committed…etc.  if you do, then you will get a 
conflict when you will pull. So the usual practice (for me anyway) is to

a) be sure the only changes in the binary are to the SA settings, nothing else
b) run git stash
c) then pull

Is there some way to externalize the SA setting so that they don’t change the 
binary?

This way you could


  1.  Load SA setting for testing # call it "MyMainStack_SA-Setting.config"

  # git ignore would have a  "MyMainStack_SA-Setting.config" so it does 
not track

  1.  Now whatever you do  with SA settings for testing, does not check the 
binary stack.
  2.  Pull without conflict.

And, now you know for sure that  when you commit the MyMainStack.app changes 
where you are for sure changed anything else *other* that the standalone 
settings? Because you never save it…

Of course, it you want to save the SA setting in the binary, you *could* save 
them….

BR


___
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