How to extract an entire element from an HTML file?

[Keith Clarke via use-livecode]

Folks,
Can anyone please guide me towards an LiveCode feature(s) that might provide the equivalent to the javascript jQuery library’s "jQuery(‘.class’).html();" mechanism that allows one to select an entire element’s content (including nested elements) from the page DOM?

I have experimented with using jQuery in a browser widget for this purpose but it introduces dependencies & integration complexities - and I’d prefer to work without necessitating a desktop UI to contain for the browser widget, so the code could potentially run on LC Server.

I can see how I might build a 'roll-your-own' approach, using LiveCode’s powerful text & chunk features. This would seem to need the HTML file to be pre-processed, to iterate through the tags of the text file to both find & mark both each nesting level within elements and also ‘pair-up’ the (anonymous) closing tags.

Is there a smarter way - any HTML parsing utilities/libraries/lessons/stacks I should study?
Thanks
Keith

[Paul Dupuis via use-livecode]

You could do this with revXML (see teh dictionary), but it is not a
single call.


On 11/25/2018 7:12 AM, Keith Clarke via use-livecode wrote:
> Folks,
> Can anyone please guide me towards an LiveCode feature(s) that might provide the equivalent to the javascript jQuery library’s "jQuery(‘.class’).html();" mechanism that allows one to select an entire element’s content (including nested elements) from the page DOM?
>
> I have experimented with using jQuery in a browser widget for this purpose but it introduces dependencies & integration complexities - and I’d prefer to work without necessitating a desktop UI to contain for the browser widget, so the code could potentially run on LC Server.
>
> I can see how I might build a 'roll-your-own' approach, using LiveCode’s powerful text & chunk features. This would seem to need the HTML file to be pre-processed, to iterate through the tags of the text file to both find & mark both each nesting level within elements and also ‘pair-up’ the (anonymous) closing tags.
>
> Is there a smarter way - any HTML parsing utilities/libraries/lessons/stacks I should study?
> Thanks
> Keith
> _______________________________________________
> use-livecode mailing list
> use-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

[Keith Clarke via use-livecode]

Thanks for the steer, Paul - I’ve not worked with XML in LiveCode so hadn’t made the connection between the HTML markup structure & XML.

A quick scan through suggests that this library could prove really useful - I’ll dig further and look for related resources, thanks.
Best,
Keith

> On 25 Nov 2018, at 13:55, Paul Dupuis via use-livecode <use-***@lists.runrev.com> wrote:
>
> You could do this with revXML (see teh dictionary), but it is not a
> single call.
>
>
> On 11/25/2018 7:12 AM, Keith Clarke via use-livecode wrote:
>> Folks,
>> Can anyone please guide me towards an LiveCode feature(s) that might provide the equivalent to the javascript jQuery library’s "jQuery(‘.class’).html();" mechanism that allows one to select an entire element’s content (including nested elements) from the page DOM?
>>
>> I have experimented with using jQuery in a browser widget for this purpose but it introduces dependencies & integration complexities - and I’d prefer to work without necessitating a desktop UI to contain for the browser widget, so the code could potentially run on LC Server.
>>
>> I can see how I might build a 'roll-your-own' approach, using LiveCode’s powerful text & chunk features. This would seem to need the HTML file to be pre-processed, to iterate through the tags of the text file to both find & mark both each nesting level within elements and also ‘pair-up’ the (anonymous) closing tags.
>>
>> Is there a smarter way - any HTML parsing utilities/libraries/lessons/stacks I should study?
>> Thanks
>> Keith
>> _______________________________________________
>> use-livecode mailing list
>> use-***@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-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

[Trevor DeVore via use-livecode]

On Mon, Nov 26, 2018 at 3:30 AM Keith Clarke via use-livecode <
use-***@lists.runrev.com> wrote:

> Thanks for the steer, Paul - I’ve not worked with XML in LiveCode so
> hadn’t made the connection between the HTML markup structure & XML.


Keith,

I’ve used revXML for parsing HTML in somewhat controlled conditions. While
revXML can work for HTML, your results will vary based on how well
structured the HTML is. If there are tags that are not closed or are out of
balance then revXML won’t give you the results you expect. If you are
generating the HTML then it shouldn’t be a problem. If it is third party
HTML then you may have to massage the HTML input to get it to work.

It would be great if there were a library wrapper around one of the
dedicated HTML parsers listed on this page:

https://en.m.wikipedia.org/wiki/Comparison_of_HTML_parsers

--
Trevor DeVore
ScreenSteps

[Keith Clarke via use-livecode]

Thanks for the warning and the link to the parsers, Trevor.

I get the point regarding unclean HTML - as I won’t be in control of the source. Following a cursory glance through the dictionary, I’m also a tad concerned about the variability in HTML tag content (e.g.

<div class=“red box”>content & elements</div>
vs.
<div class=“box red”>content & elements</div>

...and hence, how much wrangling might be needed to identify all the nodes in the tree with a specific class, where jQuery’s "$j(‘.red’).html();” saves a lot of the heavy lifting involved.

I’ll have a look at those parsers, too - though I doubt my coding chops are up to creating a library wrapper - indeed, I’ll have to Google what one is! :-)
Best,
Keith

> On 26 Nov 2018, at 13:42, Trevor DeVore via use-livecode <use-***@lists.runrev.com> wrote:
>
> On Mon, Nov 26, 2018 at 3:30 AM Keith Clarke via use-livecode <
> use-***@lists.runrev.com> wrote:
>
>> Thanks for the steer, Paul - I’ve not worked with XML in LiveCode so
>> hadn’t made the connection between the HTML markup structure & XML.
>
>
> Keith,
>
> I’ve used revXML for parsing HTML in somewhat controlled conditions. While
> revXML can work for HTML, your results will vary based on how well
> structured the HTML is. If there are tags that are not closed or are out of
> balance then revXML won’t give you the results you expect. If you are
> generating the HTML then it shouldn’t be a problem. If it is third party
> HTML then you may have to massage the HTML input to get it to work.
>
> It would be great if there were a library wrapper around one of the
> dedicated HTML parsers listed on this page:
>
> https://en.m.wikipedia.org/wiki/Comparison_of_HTML_parsers
>
> --
> Trevor DeVore
> ScreenSteps
> _______________________________________________
> use-livecode mailing list
> use-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

[Tom Glod via use-livecode]

I've been thinking about a simple html parser as well to extract email
addresses or urls from a page.....

Tools that might help

1. regular expressions
2. item delimiter and chunks. (set itemdelimiter to tag you are trying to
extract)
3.replace command

Good luck.


On Mon, Nov 26, 2018 at 10:18 AM Keith Clarke via use-livecode <
use-***@lists.runrev.com> wrote:

> Thanks for the warning and the link to the parsers, Trevor.
>
> I get the point regarding unclean HTML - as I won’t be in control of the
> source. Following a cursory glance through the dictionary, I’m also a tad
> concerned about the variability in HTML tag content (e.g.
>
> <div class=“red box”>content & elements</div>
> vs.
> <div class=“box red”>content & elements</div>
>
> ...and hence, how much wrangling might be needed to identify all the nodes
> in the tree with a specific class, where jQuery’s "$j(‘.red’).html();”
> saves a lot of the heavy lifting involved.
>
> I’ll have a look at those parsers, too - though I doubt my coding chops
> are up to creating a library wrapper - indeed, I’ll have to Google what one
> is! :-)
> Best,
> Keith
>
> > On 26 Nov 2018, at 13:42, Trevor DeVore via use-livecode <
> use-***@lists.runrev.com> wrote:
> >
> > On Mon, Nov 26, 2018 at 3:30 AM Keith Clarke via use-livecode <
> > use-***@lists.runrev.com> wrote:
> >
> >> Thanks for the steer, Paul - I’ve not worked with XML in LiveCode so
> >> hadn’t made the connection between the HTML markup structure & XML.
> >
> >
> > Keith,
> >
> > I’ve used revXML for parsing HTML in somewhat controlled conditions.
> While
> > revXML can work for HTML, your results will vary based on how well
> > structured the HTML is. If there are tags that are not closed or are out
> of
> > balance then revXML won’t give you the results you expect. If you are
> > generating the HTML then it shouldn’t be a problem. If it is third party
> > HTML then you may have to massage the HTML input to get it to work.
> >
> > It would be great if there were a library wrapper around one of the
> > dedicated HTML parsers listed on this page:
> >
> > https://en.m.wikipedia.org/wiki/Comparison_of_HTML_parsers
> >
> > --
> > Trevor DeVore
> > ScreenSteps
> > _______________________________________________
> > use-livecode mailing list
> > use-***@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-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

[J. Landman Gay via use-livecode]

On 11/26/18 1:46 PM, Tom Glod via use-livecode wrote:
> I've been thinking about a simple html parser as well to extract email
> addresses or urls from a page.....
>
> Tools that might help
>
> 1. regular expressions
> ...

I've posted this link before but it is worth reading more than once. :)
<https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454>

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

[Rick Harrison via use-livecode]

I had a couple of issues with the delivery of my
to the apple app store.

I followed Kee’s livecode lesson exactly, so what
do I need to do to fix this?

Here are the issues:
i386 (in com.(..myappname..).app/Contents/MacOS/revsecurity.dylib)
App sandbox not enabled - The following executables must include the "com.apple.security.app-sandbox" entitlement with a Boolean value of true in the entitlements property list. Refer to the App Sandbox <https://developer.apple.com/devcenter/mac/app-sandbox/> page for more information on sandboxing your app.
Your help is appreciated in advance!
Thanks,
Rick

[kee nethery via use-livecode]

Try this URL

https://developer.apple.com/documentation/security/com_apple_security_app-sandbox?language=objc

It’s not very useful. But it does say that entitlement needs a boolean.

Try adding to the entitlements.plist the following:

<key>com.apple.security.app-sandbox</key>
<true/>

Wonder what your app is doing that my app was not. If we knew, we could add this to the list of entitlements and explain when it needs to be used.

Kee

> On Nov 26, 2018, at 1:51 PM, Rick Harrison via use-livecode <use-***@lists.runrev.com> wrote:
>
> I had a couple of issues with the delivery of my
> to the apple app store.
>
> I followed Kee’s livecode lesson exactly, so what
> do I need to do to fix this?
>
> Here are the issues:
> i386 (in com.(..myappname..).app/Contents/MacOS/revsecurity.dylib)
> App sandbox not enabled - The following executables must include the "com.apple.security.app-sandbox" entitlement with a Boolean value of true in the entitlements property list. Refer to the App Sandbox <https://developer.apple.com/devcenter/mac/app-sandbox/> page for more information on sandboxing your app.
> Your help is appreciated in advance!
> Thanks,
> Rick
> _______________________________________________
> use-livecode mailing list
> use-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

[Kee Nethery via use-livecode]

What is revsecurity.dylib used for? That probably tells us what you are using that my app was not.

Kee

> On Nov 26, 2018, at 2:57 PM, kee nethery via use-livecode <use-***@lists.runrev.com> wrote:
>
> Try this URL
>
> https://developer.apple.com/documentation/security/com_apple_security_app-sandbox?language=objc
>
> It’s not very useful. But it does say that entitlement needs a boolean.
>
> Try adding to the entitlements.plist the following:
>
> <key>com.apple.security.app-sandbox</key>
> <true/>
>
> Wonder what your app is doing that my app was not. If we knew, we could add this to the list of entitlements and explain when it needs to be used.
>
> Kee
>
>> On Nov 26, 2018, at 1:51 PM, Rick Harrison via use-livecode <use-***@lists.runrev.com> wrote:
>>
>> I had a couple of issues with the delivery of my
>> to the apple app store.
>>
>> I followed Kee’s livecode lesson exactly, so what
>> do I need to do to fix this?
>>
>> Here are the issues:
>> i386 (in com.(..myappname..).app/Contents/MacOS/revsecurity.dylib)
>> App sandbox not enabled - The following executables must include the "com.apple.security.app-sandbox" entitlement with a Boolean value of true in the entitlements property list. Refer to the App Sandbox <https://developer.apple.com/devcenter/mac/app-sandbox/> page for more information on sandboxing your app.
>> Your help is appreciated in advance!
>> Thanks,
>> Rick
>> _______________________________________________
>> use-livecode mailing list
>> use-***@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-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

[Kee Nethery via use-livecode]

Oooops.

My list of entitlements already included

<key>com.apple.security.app-sandbox</key>
<true/>

Ignore my previous emails. No clue why revsecurity.dylib is triggering an entitlements issue. Perhaps it is standalone code that needs it’s own entitlements plist?

Kee

> On Nov 26, 2018, at 2:59 PM, Kee Nethery via use-livecode <use-***@lists.runrev.com> wrote:
>
> What is revsecurity.dylib used for? That probably tells us what you are using that my app was not.
>
> Kee
>
>> On Nov 26, 2018, at 2:57 PM, kee nethery via use-livecode <use-***@lists.runrev.com> wrote:
>>
>> Try this URL
>>
>> https://developer.apple.com/documentation/security/com_apple_security_app-sandbox?language=objc
>>
>> It’s not very useful. But it does say that entitlement needs a boolean.
>>
>> Try adding to the entitlements.plist the following:
>>
>> <key>com.apple.security.app-sandbox</key>
>> <true/>
>>
>> Wonder what your app is doing that my app was not. If we knew, we could add this to the list of entitlements and explain when it needs to be used.
>>
>> Kee
>>
>>> On Nov 26, 2018, at 1:51 PM, Rick Harrison via use-livecode <use-***@lists.runrev.com> wrote:
>>>
>>> I had a couple of issues with the delivery of my
>>> to the apple app store.
>>>
>>> I followed Kee’s livecode lesson exactly, so what
>>> do I need to do to fix this?
>>>
>>> Here are the issues:
>>> i386 (in com.(..myappname..).app/Contents/MacOS/revsecurity.dylib)
>>> App sandbox not enabled - The following executables must include the "com.apple.security.app-sandbox" entitlement with a Boolean value of true in the entitlements property list. Refer to the App Sandbox <https://developer.apple.com/devcenter/mac/app-sandbox/> page for more information on sandboxing your app.
>>> Your help is appreciated in advance!
>>> Thanks,
>>> Rick
>>> _______________________________________________
>>> use-livecode mailing list
>>> use-***@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-***@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-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

[Rick Harrison via use-livecode]

Hi Kee,

I don’t know why revsecuity.dylib is causing the problem if it is.

Is there a way to see if revsecuity.dylib is 32 bit instead of 64 bit?

Rick

> On Nov 26, 2018, at 6:09 PM, Kee Nethery via use-livecode <use-***@lists.runrev.com> wrote:
>
> Oooops.
>
> My list of entitlements already included
>
> <key>com.apple.security.app-sandbox</key>
> <true/>
>
> Ignore my previous emails. No clue why revsecurity.dylib is triggering an entitlements issue. Perhaps it is standalone code that needs it’s own entitlements plist?
>
> Kee

[Rick Harrison via use-livecode]

Hi Kee,

I was wondering if perhaps revsecurity.dylib is being used
for the password protection of the stack. That could be it.
If that is the problem though how are people supposed to
protect their code?

Rick

> On Nov 26, 2018, at 5:59 PM, Kee Nethery via use-livecode <use-***@lists.runrev.com> wrote:
>
> What is revsecurity.dylib used for? That probably tells us what you are using that my app was not.
>
> Kee
>

[kee nethery via use-livecode]

Sounds like a bug report is in order?

Also, I wonder if you pull it out of the app and then do Get Info on it, whether it will tell you is is 32 or 64 bit?

Kee

> On Nov 26, 2018, at 4:46 PM, Rick Harrison via use-livecode <use-***@lists.runrev.com> wrote:
>
> Hi Kee,
>
> I was wondering if perhaps revsecurity.dylib is being used
> for the password protection of the stack. That could be it.
> If that is the problem though how are people supposed to
> protect their code?
>
> Rick
>
>> On Nov 26, 2018, at 5:59 PM, Kee Nethery via use-livecode <use-***@lists.runrev.com> wrote:
>>
>> What is revsecurity.dylib used for? That probably tells us what you are using that my app was not.
>>
>> Kee
>>
>
>
> _______________________________________________
> use-livecode mailing list
> use-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

[Rick Harrison via use-livecode]

Hi Kee,

I did a get info on revsecurity.dylib inside the contents of the standalone
and unfortunately it doesn’t tell me if it is 32 or 64 bit. :-(

Rick

> On Nov 26, 2018, at 11:36 PM, kee nethery via use-livecode <use-***@lists.runrev.com> wrote:
>
> Sounds like a bug report is in order?
>
> Also, I wonder if you pull it out of the app and then do Get Info on it, whether it will tell you is is 32 or 64 bit?
>
> Kee
>
>> On Nov 26, 2018, at 4:46 PM, Rick Harrison via use-livecode <use-***@lists.runrev.com> wrote:
>>
>> Hi Kee,
>>
>> I was wondering if perhaps revsecurity.dylib is being used
>> for the password protection of the stack. That could be it.
>> If that is the problem though how are people supposed to
>> protect their code?
>>
>> Rick
>>
>>> On Nov 26, 2018, at 5:59 PM, Kee Nethery via use-livecode <use-***@lists.runrev.com> wrote:
>>>
>>> What is revsecurity.dylib used for? That probably tells us what you are using that my app was not.
>>>
>>> Kee
>>>
>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> use-***@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-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

[kee nethery via use-livecode]

Sounds like bug report. Sorry I’m no expert on revsecurity.dylib. Once you figure it out, happy to add it to the instructions.
Kee


> On Nov 26, 2018, at 8:42 PM, Rick Harrison via use-livecode <use-***@lists.runrev.com> wrote:
>
> Hi Kee,
>
> I did a get info on revsecurity.dylib inside the contents of the standalone
> and unfortunately it doesn’t tell me if it is 32 or 64 bit. :-(
>
> Rick
>
>> On Nov 26, 2018, at 11:36 PM, kee nethery via use-livecode <use-***@lists.runrev.com> wrote:
>>
>> Sounds like a bug report is in order?
>>
>> Also, I wonder if you pull it out of the app and then do Get Info on it, whether it will tell you is is 32 or 64 bit?
>>
>> Kee
>>
>>> On Nov 26, 2018, at 4:46 PM, Rick Harrison via use-livecode <use-***@lists.runrev.com> wrote:
>>>
>>> Hi Kee,
>>>
>>> I was wondering if perhaps revsecurity.dylib is being used
>>> for the password protection of the stack. That could be it.
>>> If that is the problem though how are people supposed to
>>> protect their code?
>>>
>>> Rick
>>>
>>>> On Nov 26, 2018, at 5:59 PM, Kee Nethery via use-livecode <use-***@lists.runrev.com> wrote:
>>>>
>>>> What is revsecurity.dylib used for? That probably tells us what you are using that my app was not.
>>>>
>>>> Kee
>>>>
>>>
>>>
>>> _______________________________________________
>>> use-livecode mailing list
>>> use-***@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-***@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-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

[Rick Harrison via use-livecode]

Hi Kee,

I tried a couple of quick experiments.

I turned off the password encrypt protection
and the destroy-stack option to see if that
would remove the revsecurity.dylib.
Unfortunately I had no luck in removing it.

I will try some other things in the morning.

Thanks for getting back to me about it!

Rick

> On Nov 26, 2018, at 11:49 PM, kee nethery via use-livecode <use-***@lists.runrev.com> wrote:
>
> Sounds like bug report. Sorry I’m no expert on revsecurity.dylib. Once you figure it out, happy to add it to the instructions.
> Kee
>

[Rick Harrison via use-livecode]

Here is the problem:

lipo -info /Users/…(PathToMyAppContents)…/Contents/MacOS/revsecurity.dylib are: i386 x86_64

Notice that at the end it says i386

That is what apple is complaining about.

This is clearly a serious LiveCode revsecurity.dylib problem, and without it fixed
no one can submit a Macintosh App to the Apple App Store.

> i386 (in com.(..myappname..).app/Contents/MacOS/revsecurity.dylib)
> App sandbox not enabled - The following executables must include the "com.apple.security.app-sandbox" entitlement with a Boolean value of true in the entitlements property list. Refer to the App Sandbox <https://developer.apple.com/devcenter/mac/app-sandbox/ <https://developer.apple.com/devcenter/mac/app-sandbox/>> page for more information on sandboxing your app.

Rick

[Brian Milby via use-livecode]

What version of LC?

Thanks,
Brian
On Nov 27, 2018, 11:28 AM -0600, Rick Harrison via use-livecode <use-***@lists.runrev.com>, wrote:
> Here is the problem:
>
> lipo -info /Users/…(PathToMyAppContents)…/Contents/MacOS/revsecurity.dylib are: i386 x86_64
>
> Notice that at the end it says i386
>
> That is what apple is complaining about.
>
> This is clearly a serious LiveCode revsecurity.dylib problem, and without it fixed
> no one can submit a Macintosh App to the Apple App Store.
>
> > i386 (in com.(..myappname..).app/Contents/MacOS/revsecurity.dylib)
> > App sandbox not enabled - The following executables must include the "com.apple.security.app-sandbox" entitlement with a Boolean value of true in the entitlements property list. Refer to the App Sandbox <https://developer.apple.com/devcenter/mac/app-sandbox/ <https://developer.apple.com/devcenter/mac/app-sandbox/>> page for more information on sandboxing your app.
>
> Rick
> _______________________________________________
> use-livecode mailing list
> use-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

[Rick Harrison via use-livecode]

LC version 9.0.1

Rick

> On Nov 27, 2018, at 12:38 PM, Brian Milby via use-livecode <use-***@lists.runrev.com> wrote:
>
> What version of LC?

[JB via use-livecode]

I have never submitted an app on the apple store but
I googled i386 and here is what I get.

x86_64 is for 64 bit processors. i386 is for 32 bit processors.

So the question I wonder is does this have something to do with
Mojave OS? From what I have read they will be eliminating the
32 bit programs very soon and i386 is 32 bit.

Is there an option that allows you to select only 64 bit because
it sounds like that is what you need.

JB



> On Nov 27, 2018, at 9:27 AM, Rick Harrison via use-livecode <use-***@lists.runrev.com> wrote:
>
> Here is the problem:
>
> lipo -info /Users/…(PathToMyAppContents)…/Contents/MacOS/revsecurity.dylib are: i386 x86_64
>
> Notice that at the end it says i386
>
> That is what apple is complaining about.
>
> This is clearly a serious LiveCode revsecurity.dylib problem, and without it fixed
> no one can submit a Macintosh App to the Apple App Store.
>
>> i386 (in com.(..myappname..).app/Contents/MacOS/revsecurity.dylib)
>> App sandbox not enabled - The following executables must include the "com.apple.security.app-sandbox" entitlement with a Boolean value of true in the entitlements property list. Refer to the App Sandbox <https://developer.apple.com/devcenter/mac/app-sandbox/ <https://developer.apple.com/devcenter/mac/app-sandbox/>> page for more information on sandboxing your app.
>
> Rick
> _______________________________________________
> use-livecode mailing list
> use-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

[Rick Harrison via use-livecode]

Hi JB,

I had the build for Mac OS X 64-bit box checked in the
Standalone Application Settings for my stack.

I am running High Sierra and so far LiveCode does
not yet that I know of support Mojave. I do however
think that yes this is Apple forcing things forward as
per usual.

I believe the team at LiveCode probably just needs
to recompile revsecurity.dylib to be a 64 bit library
and everything should work correctly.

Rick

> On Nov 27, 2018, at 4:56 PM, JB via use-livecode <use-***@lists.runrev.com> wrote:
>
> I have never submitted an app on the apple store but
> I googled i386 and here is what I get.
>
> x86_64 is for 64 bit processors. i386 is for 32 bit processors.
>
> So the question I wonder is does this have something to do with
> Mojave OS? From what I have read they will be eliminating the
> 32 bit programs very soon and i386 is 32 bit.
>
> Is there an option that allows you to select only 64 bit because
> it sounds like that is what you need.
>
> JB

[JB via use-livecode]

That sounds like the solution.

JB


> On Nov 27, 2018, at 4:44 PM, Rick Harrison via use-livecode <use-***@lists.runrev.com> wrote:
>
> Hi JB,
>
> I had the build for Mac OS X 64-bit box checked in the
> Standalone Application Settings for my stack.
>
> I am running High Sierra and so far LiveCode does
> not yet that I know of support Mojave. I do however
> think that yes this is Apple forcing things forward as
> per usual.
>
> I believe the team at LiveCode probably just needs
> to recompile revsecurity.dylib to be a 64 bit library
> and everything should work correctly.
>
> Rick
>
>> On Nov 27, 2018, at 4:56 PM, JB via use-livecode <use-***@lists.runrev.com> wrote:
>>
>> I have never submitted an app on the apple store but
>> I googled i386 and here is what I get.
>>
>> x86_64 is for 64 bit processors. i386 is for 32 bit processors.
>>
>> So the question I wonder is does this have something to do with
>> Mojave OS? From what I have read they will be eliminating the
>> 32 bit programs very soon and i386 is 32 bit.
>>
>> Is there an option that allows you to select only 64 bit because
>> it sounds like that is what you need.
>>
>> JB
>
> _______________________________________________
> use-livecode mailing list
> use-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>

[Brian Milby via use-livecode]

LC already has code to run lipo when building the app. It currently just
operates on externals. The code is in __revSBCopyFile which is a part of
revsblibrary.livecodescript. From my initial look, I'm guessing that it
also needs to work on revsecurity.dylib as well.

Have you tried manually running lipo on the file? Doing so would also
require that it be resigned though.

On Tue, Nov 27, 2018 at 6:49 PM JB via use-livecode <
use-***@lists.runrev.com> wrote:

> That sounds like the solution.
>
> JB
>
>
> > On Nov 27, 2018, at 4:44 PM, Rick Harrison via use-livecode <
> use-***@lists.runrev.com> wrote:
> >
> > Hi JB,
> >
> > I had the build for Mac OS X 64-bit box checked in the
> > Standalone Application Settings for my stack.
> >
> > I am running High Sierra and so far LiveCode does
> > not yet that I know of support Mojave. I do however
> > think that yes this is Apple forcing things forward as
> > per usual.
> >
> > I believe the team at LiveCode probably just needs
> > to recompile revsecurity.dylib to be a 64 bit library
> > and everything should work correctly.
> >
> > Rick
> >
> >> On Nov 27, 2018, at 4:56 PM, JB via use-livecode <
> use-***@lists.runrev.com> wrote:
> >>
> >> I have never submitted an app on the apple store but
> >> I googled i386 and here is what I get.
> >>
> >> x86_64 is for 64 bit processors. i386 is for 32 bit processors.
> >>
> >> So the question I wonder is does this have something to do with
> >> Mojave OS? From what I have read they will be eliminating the
> >> 32 bit programs very soon and i386 is 32 bit.
> >>
> >> Is there an option that allows you to select only 64 bit because
> >> it sounds like that is what you need.
> >>
> >> JB
> >
> > _______________________________________________
> > use-livecode mailing list
> > use-***@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-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>

[Rick Harrison via use-livecode]

Hi Brian,

I have not tried manually running lipo on the file.

I figure I will have to resign the app anyway so
not a huge deal if it works.

I’m not a big unix user so if you have some
additional suggested lipo code for me to look
at I’d appreciate it.

All I found on the web was the following
really old example:

For example if you wanted to thin the “Stickies” application to only contain intel (i386) code:

cd /Applications
lipo Stickies.app/Contents/MacOS/Stickies -thin i386 -output Stickies.app/Contents/MacOS/Stickies.i386
cd Stickies.app/Contents/MacOS/
rm Stickies
mv Stickies.i386 Stickies

I assume I want something like this but I want to thin it for x86_64
or something similar?

Thanks for the suggestion, I will
also take a look at
> __revSBCopyFile which is a part of
> revsblibrary.livecodescript.

Rick


> On Nov 27, 2018, at 9:08 PM, Brian Milby via use-livecode <use-***@lists.runrev.com> wrote:
>
> LC already has code to run lipo when building the app. It currently just
> operates on externals. The code is in __revSBCopyFile which is a part of
> revsblibrary.livecodescript. From my initial look, I'm guessing that it
> also needs to work on revsecurity.dylib as well.
>
> Have you tried manually running lipo on the file? Doing so would also
> require that it be resigned though.
>
> On Tue, Nov 27, 2018 at 6:49 PM JB via use-livecode <
> use-***@lists.runrev.com> wrote:
>

[Rick Harrison via use-livecode]

Hi Brian,

I am assuming you are referring to the following:

-- Remove unneeded slices from the MacOS externals

if the platform is "macos" and pSettings is not empty then

local tRemove

if pSettings["MacOSX x86-64"] is true and pSettings["MacOSX x86-32"] is not true then

put "i386" into tRemove

else if pSettings["MacOSX x86-32"] is true and pSettings["MacOSX x86-64"] is not true then

put "x86_64" into tRemove

end if


if tRemove is not empty then

set the itemDel to slash

if pSettings["externals"] contains item -1 of pTargetFile then

replace " " with "\ " in pTargetFile

local tShell

put "lipo " & pTargetFile & " -remove " & tRemove & " -output " & pTargetFile into tShell

get shell(tShell)

end if

end if

end if

Rick


> On Nov 27, 2018, at 9:08 PM, Brian Milby via use-livecode <use-***@lists.runrev.com> wrote:
>
> revSBCopyFile

[Brian Milby via use-livecode]

Yes, that is the section of code that I was referring to. So you should be
able to:
lipo revsecurity.dylib -remove i386 -output revsecurity.dylib

After changing to the directory containing the file in the terminal.


>
>

[panagiotis merakos via use-livecode]

Hello all,

Yes, it seems we have to make sure that the code applied to externals for
removing unneeded arch is also applied to revsecurity. Here are detailed
instructions on how to do this manually from the terminal (the instructions
are for tsNet - just change the path to the one of revsecurity):

See comment 6 in
https://quality.livecode.com/show_bug.cgi?id=20946

Kind regards,
Panos
--

On Wed, Nov 28, 2018 at 7:07 AM Brian Milby via use-livecode <
use-***@lists.runrev.com> wrote:

> Yes, that is the section of code that I was referring to. So you should be
> able to:
> lipo revsecurity.dylib -remove i386 -output revsecurity.dylib
>
> After changing to the directory containing the file in the terminal.
>
>
> >
> >
> _______________________________________________
> use-livecode mailing list
> use-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>

[panagiotis merakos via use-livecode]

Just filed this report:

https://quality.livecode.com/show_bug.cgi?id=21720

Best,
Panos

On Wed, Nov 28, 2018 at 10:20 AM panagiotis merakos <***@gmail.com>
wrote:

> Hello all,
>
> Yes, it seems we have to make sure that the code applied to externals for
> removing unneeded arch is also applied to revsecurity. Here are detailed
> instructions on how to do this manually from the terminal (the instructions
> are for tsNet - just change the path to the one of revsecurity):
>
> See comment 6 in
> https://quality.livecode.com/show_bug.cgi?id=20946
>
> Kind regards,
> Panos
> --
>
> On Wed, Nov 28, 2018 at 7:07 AM Brian Milby via use-livecode <
> use-***@lists.runrev.com> wrote:
>
>> Yes, that is the section of code that I was referring to. So you should
>> be
>> able to:
>> lipo revsecurity.dylib -remove i386 -output revsecurity.dylib
>>
>> After changing to the directory containing the file in the terminal.
>>
>>
>> >
>> >
>> _______________________________________________
>> use-livecode mailing list
>> use-***@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>

[Matthias Rebbe via use-livecode]

Another and more comfortable way would be to use App Wrapper 3, in case you own it.

App Wrapper has a feature called Architecture Cleanup to make Intel 64-Bit or Intel 32-Bit only.

http://www.ohanaware.com/appwrapper/

Regards,

Matthias


Matthias Rebbe

free tools for Livecoders:
https://instamaker.dermattes.de
https://winsignhelper.dermattes.de

> Am 28.11.2018 um 09:20 schrieb panagiotis merakos via use-livecode <use-***@lists.runrev.com>:
>
> Hello all,
>
> Yes, it seems we have to make sure that the code applied to externals for
> removing unneeded arch is also applied to revsecurity. Here are detailed
> instructions on how to do this manually from the terminal (the instructions
> are for tsNet - just change the path to the one of revsecurity):
>
> See comment 6 in
> https://quality.livecode.com/show_bug.cgi?id=20946
>
> Kind regards,
> Panos
> --
>
> On Wed, Nov 28, 2018 at 7:07 AM Brian Milby via use-livecode <
> use-***@lists.runrev.com> wrote:
>
>> Yes, that is the section of code that I was referring to. So you should be
>> able to:
>> lipo revsecurity.dylib -remove i386 -output revsecurity.dylib
>>
>> After changing to the directory containing the file in the terminal.
>>
>>
>>>
>>>
>> _______________________________________________
>> use-livecode mailing list
>> use-***@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-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

[Rick Harrison via use-livecode]

Hi Guys,

I managed to strip out the old 32 bit stuff leaving
just the 64 bit code thanks to your instructions.

I re-codesigned the app and made sure that
the entitlements.plist had:

<key>com.apple.security.app-sandbox</key>
<true/>
<key>com.apple.security.files.user-selected.read-write</key>
<true/>
<key>com.apple.security.network.client</key>
<true/>

I tested the package to make sure it executed fine,
and tested my resulting app which worked fine too.

I used the Application Loader and started uploading
the package to Apple.

It then spit the following error message back at me.

ERROR ITMS-90296: “App sandbox not enabled. The following executables must include the “com.apple.security.app-sandbox” entitlement with a Boolean value of true in the entitlements property list [(“<myapp>.pkg/Payload/<myapp>/Contents/MacOS/<myapp>”)] Refer to App Sandbox page at https://developer.apple.com/devcenter/mac/app-sandbox/ for more information on sandboxing your app.”

The Application Loader offered option buttons - “Send to Apple…”, “Activity…” “Back”… “Send”.

So what should I do now besides feeling very frustrated?

Rick

[Brian Milby via use-livecode]

When you did the codesign, did you use the "--entitlements" option? (I saw
this in a semi-related post on rejections)

On Wed, Nov 28, 2018 at 12:26 PM Rick Harrison via use-livecode <
use-***@lists.runrev.com> wrote:

> Hi Guys,
>
> I managed to strip out the old 32 bit stuff leaving
> just the 64 bit code thanks to your instructions.
>
> I re-codesigned the app and made sure that
> the entitlements.plist had:
>
> <key>com.apple.security.app-sandbox</key>
> <true/>
> <key>com.apple.security.files.user-selected.read-write</key>
> <true/>
> <key>com.apple.security.network.client</key>
> <true/>
>
> I tested the package to make sure it executed fine,
> and tested my resulting app which worked fine too.
>
> I used the Application Loader and started uploading
> the package to Apple.
>
> It then spit the following error message back at me.
>
> ERROR ITMS-90296: “App sandbox not enabled. The following executables must
> include the “com.apple.security.app-sandbox” entitlement with a Boolean
> value of true in the entitlements property list
> [(“<myapp>.pkg/Payload/<myapp>/Contents/MacOS/<myapp>”)] Refer to App
> Sandbox page at https://developer.apple.com/devcenter/mac/app-sandbox/
> for more information on sandboxing your app.”
>
> The Application Loader offered option buttons - “Send to Apple…”,
> “Activity…” “Back”… “Send”.
>
> So what should I do now besides feeling very frustrated?
>
> Rick
>
>
>
> _______________________________________________
> use-livecode mailing list
> use-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

[Rick Harrison via use-livecode]

Brian,

Do you mean:

sudo codesign --verbose --deep --force --sign "3rd Party Mac Developer Application: MYCOMPANY NAME (KDSK9SJUNK)” --entitlements <Path to my.plist> <Path to my app>

If so, yes I did that.

Rick

> On Nov 28, 2018, at 3:13 PM, Brian Milby via use-livecode <use-***@lists.runrev.com> wrote:
>
> When you did the codesign, did you use the "--entitlements" option? (I saw
> this in a semi-related post on rejections)

[kee nethery via use-livecode]

> On Nov 28, 2018, at 1:51 PM, Rick Harrison via use-livecode <use-***@lists.runrev.com> wrote:
>
> Brian,
>
> Do you mean:
>
> sudo codesign --verbose --deep --force --sign "3rd Party Mac Developer Application: MYCOMPANY NAME (KDSK9SJUNK)” --entitlements <Path to my.plist> <Path to my app>

assuming you meant --entitlements <Path to my_entitlements.plist>

Kee

>
> If so, yes I did that.
>
> Rick
>
>> On Nov 28, 2018, at 3:13 PM, Brian Milby via use-livecode <use-***@lists.runrev.com> wrote:
>>
>> When you did the codesign, did you use the "--entitlements" option? (I saw
>> this in a semi-related post on rejections)

[Brian Milby via use-livecode]

Yes, that is what I meant.

Thanks,
Brian
On Dec 3, 2018, 12:59 PM -0600, kee nethery via use-livecode <use-***@lists.runrev.com>, wrote:
>
>
> > On Nov 28, 2018, at 1:51 PM, Rick Harrison via use-livecode <use-***@lists.runrev.com> wrote:
> >
> > Brian,
> >
> > Do you mean:
> >
> > sudo codesign --verbose --deep --force --sign "3rd Party Mac Developer Application: MYCOMPANY NAME (KDSK9SJUNK)” --entitlements <Path to my.plist> <Path to my app>
>
> assuming you meant --entitlements <Path to my_entitlements.plist>
>
> Kee
>
> >
> > If so, yes I did that.
> >
> > Rick
> >
> > > On Nov 28, 2018, at 3:13 PM, Brian Milby via use-livecode <use-***@lists.runrev.com> wrote:
> > >
> > > When you did the codesign, did you use the "--entitlements" option? (I saw
> > > this in a semi-related post on rejections)
>
> _______________________________________________
> use-livecode mailing list
> use-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

[JB via use-livecode]

That is really nice to know!

thanks,
JB


> On Nov 28, 2018, at 1:39 AM, Matthias Rebbe via use-livecode <use-***@lists.runrev.com> wrote:
>
> Another and more comfortable way would be to use App Wrapper 3, in case you own it.
>
> App Wrapper has a feature called Architecture Cleanup to make Intel 64-Bit or Intel 32-Bit only.
>
> http://www.ohanaware.com/appwrapper/
>
> Regards,
>
> Matthias
>
>
> Matthias Rebbe
>
> free tools for Livecoders:
> https://instamaker.dermattes.de
> https://winsignhelper.dermattes.de
>
>> Am 28.11.2018 um 09:20 schrieb panagiotis merakos via use-livecode <use-***@lists.runrev.com>:
>>
>> Hello all,
>>
>> Yes, it seems we have to make sure that the code applied to externals for
>> removing unneeded arch is also applied to revsecurity. Here are detailed
>> instructions on how to do this manually from the terminal (the instructions
>> are for tsNet - just change the path to the one of revsecurity):
>>
>> See comment 6 in
>> https://quality.livecode.com/show_bug.cgi?id=20946
>>
>> Kind regards,
>> Panos
>> --
>>
>> On Wed, Nov 28, 2018 at 7:07 AM Brian Milby via use-livecode <
>> use-***@lists.runrev.com> wrote:
>>
>>> Yes, that is the section of code that I was referring to. So you should be
>>> able to:
>>> lipo revsecurity.dylib -remove i386 -output revsecurity.dylib
>>>
>>> After changing to the directory containing the file in the terminal.
>>>
>>>
>>>>
>>>>
>>> _______________________________________________
>>> use-livecode mailing list
>>> use-***@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-***@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-***@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>

[Rick Harrison via use-livecode]

Hi Kee,

It already has this so that can’t be it.

Rick

> On Nov 26, 2018, at 5:57 PM, kee nethery via use-livecode <use-***@lists.runrev.com> wrote:
>
> <key>com.apple.security.app-sandbox</key>
> <true/>