Re: AW: 64 bit desktop apps

2017-06-08 Thread Mark Waddingham via use-livecode

On 2017-06-08 16:19, Paul Dupuis via use-livecode wrote:

On 6/8/2017 3:54 AM, Mark Waddingham via use-livecode wrote:

As a general request, can people let us know if they are relying on
externals on Mac which are currently 32-bit only?


Forgive the dumb question Mark, but how does someone tell whether
externals are 32 bit or 64 bit?


You can do it from the terminal:

otool -hv .bundle/Contents/MacOS/

Will list what executable 'slices' are in the external's executable.


In my first LC 8.1.3 64 bit build, I accidentally included
revVideoGrabber in my inclusions (we don;t use it, it had been checked
by accident). I discovered my OSX standalone would not even launch with
NO error messages or crash report. Only by opening the App bundle to
look around and double-clicking on the actual executable did I get a 
OSX

Terminal listing that showed error with LiveCode trying to start
revVideoGrabber and failing. Removing that from the Inclusion list
allowed creation of a Standalone that launched.


Could you file that as a bug? The S/B should ignore inclusions which are 
not available on the specified architecture and warn if there are 
mismatches.



Then we noticed that the default text font or text flow is different in
8.1.3 from 6.7.11 and test in our splash screen and a licensing dialog
is cut off under 8.1.3 vs 6.7.11. These are the details that add up to 
a

length migration time for large applications.


Yes - this is one thing which did change between 7 and 8 - unavoidably 
so as we moved to using CoreText to render text on Mac, rather than 
ATSUI.



As another example, in testing our LC6.7.11 app under LC8.1.4, I
discovered that the 'standaloneSaved pDestinationFolder' message 
returns:


 'C:/Users/Paul/Desktop/TestProject' under LC6.7.11. Note that the name
of the Standalone folder 'HyperRESEARCH' is not included and there is 
no

ending slash.

but

'C:/Users/Paul/Desktop/TestProject/HyperRESEARCH/" under LC8.1.3, Note
that the name of the Standalone folder 'HyperRESEARCH' is included and
there is a trailing slash


There has been a bit of churn in the SB messages since 6.7 - various 
attempts to fix various bugs. If you file a bug with this particular 
case, Panos will be able to check whether there is still a problem 
there.




On this topic, I applaud LiveCode for having 64 bit support. I curse
Apple for removing 32 bit support. I still have apps under LC6.7.11 and
LC 5.5.5 that now need to migrate to LC8.1.4+ in the next 6 months and 
I
am really annoyed at Apple for doing this. To be fair, we've known 
we've
need to catch up to current LiveCode releases for a good long while, 
but

between business pressures to add new features and fix customer visible
bugs, cleaning up code that needs fixing just due to engine changes
unfortunately always falls to last place. Now, fortunately or
unfortunately due to Apple's heavy handedness, it now moves to first
place for us.


Actually, things are not quite as they might appear from my reading.

Apple will not allow 32-bit slices in *new* apps submitted to the Mac 
App Store from January 2018, and will not accept updates to any app 
containing 32-bit slices from June 2018:


  https://9to5mac.com/2017/06/06/ios-11-32-bit-mac-app-store-64-bit/

Versions of Mac OS *after* High Sierra will no longer support 32-bit 
slices in apps:


   
https://www.imore.com/after-high-sierra-32-bit-games-mac-are-kicked-curb-0


So, right now, if you don't put your app into the MacAppStore - there is 
no need to worry.


If you are looking to submit a new app to MacAppStore then if you don't 
get it in before January 2018, it has to be 64-bit.


If you have an app in the MacAppStore, or will have before January 2018, 
then you have until June 2018 to make sure that it is 64-bit.


Everyone has until September 2018 (projected release date, based on 
history, for the version of mac after High Sierra) to make sure their 
apps can be 64-bit.


In regards to where LiveCode stands:

  - LiveCode started supporting 64-bit Mac from 8.x

  - In 9.0 we will be making 64-bit Mac mode the default for both IDE 
and Standalones


  - If you app works in 9.0, then the only thing blocking you from 
turning off the 32-bit slice is whether you use externals which are Mac 
32-bit only.


  - If you app works in 8.0, then the only thing blocking you from 
turning off the 32-bit slice is whether you use externals which are Mac 
32-bit only, or use QuickTime.


Hopefully this makes things a bit clearer.

We need to do a bit more research before deciding on the date of axing 
32-bit slices in LiveCode - however when we do this will *only* affect 
the 'develop' version at the time (i.e. 8.x will continue to be 
universal, as will all maintenance versions up to the axe date).


Again - please do contact me (off-list is fine, and better perhaps!) if 
any apps you have (and are intending to update / need to run on versions 
of Mac into the future) do rely on 32-bit Mac externals which we 
(LiveCode) 

Re: AW: 64 bit desktop apps

2017-06-08 Thread Paul Dupuis via use-livecode
On 6/8/2017 3:54 AM, Mark Waddingham via use-livecode wrote:
> As a general request, can people let us know if they are relying on
> externals on Mac which are currently 32-bit only?

Forgive the dumb question Mark, but how does someone tell whether
externals are 32 bit or 64 bit?


In my first LC 8.1.3 64 bit build, I accidentally included
revVideoGrabber in my inclusions (we don;t use it, it had been checked
by accident). I discovered my OSX standalone would not even launch with
NO error messages or crash report. Only by opening the App bundle to
look around and double-clicking on the actual executable did I get a OSX
Terminal listing that showed error with LiveCode trying to start
revVideoGrabber and failing. Removing that from the Inclusion list
allowed creation of a Standalone that launched.

Then we noticed that the default text font or text flow is different in
8.1.3 from 6.7.11 and test in our splash screen and a licensing dialog
is cut off under 8.1.3 vs 6.7.11. These are the details that add up to a
length migration time for large applications.

As another example, in testing our LC6.7.11 app under LC8.1.4, I
discovered that the 'standaloneSaved pDestinationFolder' message returns:

 'C:/Users/Paul/Desktop/TestProject' under LC6.7.11. Note that the name
of the Standalone folder 'HyperRESEARCH' is not included and there is no
ending slash.

but

'C:/Users/Paul/Desktop/TestProject/HyperRESEARCH/" under LC8.1.3, Note
that the name of the Standalone folder 'HyperRESEARCH' is included and
there is a trailing slash

A small difference, undoubtedly covered in release notes, but another
cause of code that needed to be changed to accommodate the differences
between 2 versions of the engine.


On this topic, I applaud LiveCode for having 64 bit support. I curse
Apple for removing 32 bit support. I still have apps under LC6.7.11 and
LC 5.5.5 that now need to migrate to LC8.1.4+ in the next 6 months and I
am really annoyed at Apple for doing this. To be fair, we've known we've
need to catch up to current LiveCode releases for a good long while, but
between business pressures to add new features and fix customer visible
bugs, cleaning up code that needs fixing just due to engine changes
unfortunately always falls to last place. Now, fortunately or
unfortunately due to Apple's heavy handedness, it now moves to first
place for us.



___
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: AW: 64 bit desktop apps

2017-06-08 Thread Trevor DeVore via use-livecode
On Thu, Jun 8, 2017 at 2:55 AM Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> As a general request, can people let us know if they are relying on
> externals on Mac which are currently 32-bit only?


I have a couple of externals I use in my apps that are 32-bit. I haven't
set up my new dev computer to work on externals. I was hoping to just
convert the externals to modules once a Cocoa bridge was available and the
C bridge improved some.

-- 
Trevor DeVore

>
___
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: AW: 64 bit desktop apps

2017-06-08 Thread Mark Waddingham via use-livecode

On 2017-06-08 08:48, Tiemo Hollmann TB via use-livecode wrote:
I would love to build 64-bit for Mac, but up to now, the Valentina 
extension

is still 32-bit, I hope they'll get it fixed by time.


I must confess that we always had the intent of dropping the 32-bit 
slice of the engine on Mac from 9 onwards. However, the case of people 
having to rely on 32-bit only externals potentially puts a spanner in 
that - so we might have to hold over to 'the next major version'.


The reason this would be good to do is that:

  1) Beyond the (legacy) 32-bit externals problem there is no advantage 
to the 32-bit slice


  2) It means our Mac builds will halve in time (which is important for 
CI, in particular) as it only has to compile once (and not twice) per 
build


  3) It is one less 'thing to think about' when doing Mac engine work.

  4) It makes LiveCode and the apps it builds more compact.

At the very least, we'll certainly be switching the IDE to 64-bit (by 
default) and make the SB build 64-bit only (by default) in 9+.


I'll see if we can get in contact with Valentina and find out what would 
be needed to do a 64-bit version.


As a general request, can people let us know if they are relying on 
externals on Mac which are currently 32-bit only?


Warmest Regards,

Mark.

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

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