Re: [ANN] Release 9.0.2 RC-1

[panagiotis merakos via use-livecode]

OK, since the "build 32bit slice only" checkbox was not checked
(Brahmanathaswami replied to me privately) then the next thing to check is
that the version of Application Loader you used to upload the .ipa is the
one included in the Xcode version you used to build the app.

See this thread:

http://forums.livecode.com/viewtopic.php?f=49=31656=172373=invalid+architecture#p172373

Best regards,
Panos
--



On Tue, Nov 13, 2018 at 10:36 PM panagiotis merakos 
wrote:

> Hello Brahmanathaswami,
>
> Could it be the case that you have accidentally checked the "build 32bit
> slice only" checkbox in the iOS standalone settings?
>
> Regards,
> Panos
>
> On Tue, Nov 13, 2018, 22:24 Sannyasin Brahmanathaswami via use-livecode <
> use-livecode@lists.runrev.com wrote:
>
>> Hit send button too soon
>> > Bad news. (Does not change my little "guide")
>> >
>> > Build the app, used Jacqulines "Air Launch" get SivaSiva.ipa
>> >
>> > I already had new release, 1.3 on iTuneConnect.
>> >
>> > Booted Application Loader
>> > Run the SivaSiva.ipa
>> >
>> > It passed all analyses; I got a message from Application Loader "Success
>> > [snip other stuff] we will get a review shortly.
>> >
>> > That was saturday
>> On Monday I get a message from Apple that there was "invalid
>> architecture" in app,
>>
>> Plus the using Push Notification Warning and Beta Test entitlement
>> missing those are not blockers for approval. But "invalid architecture" is
>>
>> No further info
>>
>> I have ticket in with Livecode support.
>>
>>
>> Brahmanathaswami
>>
>>
>> ___
>> 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: Reading data from Google Sheets

[Kaveh Bazargan via use-livecode]

Thank you so much to both. And Andre, if you could write a blog post for
every question I have it would help me a lot. ;-)

Actually I think I had looked at the very helpful StackExchange page before
for reading Google Sheets directly in R. I will try it and report back with
any follow ups.

Regards
Kaveh

On Wed, 14 Nov 2018 at 02:12, Andre Alves Garzia 
wrote:

> Kaveh,
>
> There is a much easier way. I've just posted about it since it can be of
> interest for others (there is a demo stack included):
>
>
> http://andregarzia.com/2018/11/reading-google-sheets-data-from-livecode.html
>
> Basically, there are special URLs for retrieving a Google Sheet as a CSV
> or a JSON. Much easier than parsing HTML or visible text.
>
> Cheers
>
> andre
>
> On 11/14/2018 12:46 AM, dunbarxx via use-livecode wrote:
> > Hi.
> >
> > well the (very) short answer is that you can:
> >
> > put url "yourWebpageAddressHere" into temp
> >
> > What you get is the entirety of the html contents of a page. Others will
> > tell both of us how to get the "visible" text, that is, the tab and
> return
> > delimited data, buried in all those tags.
> >
> > Craig Newman
> >
> >
> >
> > --
> > Sent from:
> http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html
> >
> > ___
> > 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
>


-- 
Kaveh Bazargan
Director
River Valley Technologies  • Twitter
 • LinkedIn

___
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: Reading data from Google Sheets

[Andre Alves Garzia via use-livecode]

Kaveh,

There is a much easier way. I've just posted about it since it can be of 
interest for others (there is a demo stack included):


http://andregarzia.com/2018/11/reading-google-sheets-data-from-livecode.html

Basically, there are special URLs for retrieving a Google Sheet as a CSV 
or a JSON. Much easier than parsing HTML or visible text.


Cheers

andre

On 11/14/2018 12:46 AM, dunbarxx via use-livecode wrote:

Hi.

well the (very) short answer is that you can:

put url "yourWebpageAddressHere" into temp

What you get is the entirety of the html contents of a page. Others will
tell both of us how to get the "visible" text, that is, the tab and return
delimited data, buried in all those tags.

Craig Newman



--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
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: What is LC's internal text format?

[Monte Goulding via use-livecode]

> On 14 Nov 2018, at 11:39 am, Monte Goulding via use-livecode 
>  wrote:
> 
>> You generally want to use codepoint in 7+ generally where previously you 
>> used char unless you know you are dealing with a binary string and then you 
>> use byte.
> 
> Sorry! I have written codepoints here when I was thinking codeunits! Use 
> codeunits rather than codepoints as they are a fixed number of bytes (2). 
> Codepoints may be 2 or 4 bytes so there is a cost in figuring out the number 
> of codepoints or the exact byte codepoint x refers to. So for chunk 
> expressions on unicode strings use `codeunit x to y`.

Argh… sorry again… codeunits are a fixed number of bytes but that fixed number 
depends on whether the string is native encoded (1 byte) or UTF-16 (2 bytes)!

And for completeness codeunit/codepoint is not equivalent to char. If you 
really need to count graphemes then you will need to use char.

Cheers

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

Re: Reading data from Google Sheets

[dunbarxx via use-livecode]

Hi.

well the (very) short answer is that you can:

put url "yourWebpageAddressHere" into temp

What you get is the entirety of the html contents of a page. Others will
tell both of us how to get the "visible" text, that is, the tab and return
delimited data, buried in all those tags.

Craig Newman



--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
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: What is LC's internal text format?

[Monte Goulding via use-livecode]

> On 14 Nov 2018, at 10:44 am, Monte Goulding via use-livecode 
>  wrote:
> 
> You generally want to use codepoint in 7+ generally where previously you used 
> char unless you know you are dealing with a binary string and then you use 
> byte.

Sorry! I have written codepoints here when I was thinking codeunits! Use 
codeunits rather than codepoints as they are a fixed number of bytes (2). 
Codepoints may be 2 or 4 bytes so there is a cost in figuring out the number of 
codepoints or the exact byte codepoint x refers to. So for chunk expressions on 
unicode strings use `codeunit x to y`.

Cheers

Monte


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

Re: finding location on mobile device

[Alan via use-livecode]

Note that you may not get a value immediately from your location services 
subsystem so if you find there's nothing there, then try starting up the sensor 
in openCard or openStack, wait some time and then use the button to get the 
current location.

Hope that makes sense (and works for you).

Or are you having problems feeding it in to the map widget?

cheers

Alan

> On 14 Nov 2018, at 7:52 am, Devin Asay via 
>  wrote:
> 
> 
> This has worked for me in the past, but I haven?t tried it in quite some time:
> 
> mobileStartTrackingSensor "location", false
> put mobileCurrentLocation() into tLocArray
> mobileStopTrackingSensor "location"
> put "lat: " & tLocArray["latitude"] & cr & "long: " & tLocArray["longitude"] 
> into fld "report"
> 
> Devin
> 
>> On Nov 13, 2018, at 1:06 PM, Mike for GDC via use-livecode 
>>  wrote:
>> 
>> I am trying to find my current lat/long on my android device.  I have played
>> around with multiple options including "mobileCurrentLocation" and others.
>> I have not been able to find an example of code that does it and works.
>> What I want to do is push a button, have the lat/long displayed so as I can
>> then "feed" it into a map widget for display.  Does anyone have an example
>> of code that does just that?  Thanks.  Mike


___
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: What is LC's internal text format?

[Monte Goulding via use-livecode]

> On 14 Nov 2018, at 6:33 am, Ben Rubinstein via use-livecode 
>  wrote:
> 
> That's really helpful - and in parts eye-opening - thanks Mark.
> 
> I have a few follow-up questions.
> 
> Does textEncode _always_ return a binary string? Or, if invoked with 
> "CP1252", "ISO-8859-1", "MacRoman" or "Native", does it return a string?

Internally we have different types of values. So we have MCStringRef which is 
the thing which either contains a buffer of native chars or a buffer of UTF-16 
chars. There are others. For example, MCNumberRef will either hold a 32 bit 
signed int or a double. These are returned by numeric operations where there’s 
no string representation of a number. So:

put 1.0 into tNumber # tNumber holds an MCStringRef
put 1.0 + 0 int0 tNumber # tNumber holds an MCNumberRef

The return type of textEncode is an MCDataRef. This is a byte buffer, buffer 
size & byte count.

So:
put textEncode(“foo”, “UTF-8”) into tFoo # tFoo holds MCDataRef

Then if we do something like:
set the text of field “foo” to tFoo

tFoo is first converted to MCStringRef. As it’s an MCDataRef we just move the 
buffer over and say it’s a native encoded string. There’s no checking to see if 
it’s a UTF-8 string and decoding with that etc.

Then the string is put into the field.

If you remember that mergJSON issue you reported where mergJSON returns UTF-8 
data and you were putting it into a field and it looked funny this is why.
> 
> > CodepointOffset has signature 'integer codepointOffset(string)', so when you
> > pass a binary string (data) value to it, the data value gets converted to a
> > string by interpreting it as a sequence of bytes in the native encoding.
> 
> OK - so one message I take are that in fact one should never invoke 
> codepointOffset on a binary string. Should it actually throw an error in this 
> case?

No, as mentioned above values can move to and from different types according to 
the operations performed on them and this is largely opaque to the scripter. If 
you do a text operation on a binary string then there’s an implicit conversion 
to a native encoded string. You generally want to use codepoint in 7+ generally 
where previously you used char unless you know you are dealing with a binary 
string and then you use byte.
> 
> By the same token, probably one should only use 'byte', 'byteOffset', 
> 'byteToNum' etc with binary strings - would it be better, to avoid confusion, 
> if char, offset, charToNum should refuse to operate on a binary string?

That would not be backwards compatible.
> 
>> e.g. In the case of &, it can either take two data arguments, or two
>> string arguments. In this case, if both arguments are data, then the result
>> will be data. Otherwise both arguments will be converted to strings, and a
>> string returned.
> The second message I take is that one needs to be very careful, if operating 
> on UTF8 or other binary strings, to avoid 'contaminating' them e.g. by 
> concatenating with a simple quoted string, as this may cause it to be 
> silently converted to a non-binary string. (I presume that 'put "simple 
> string" after/before pBinaryString' will cause a conversion in the same way 
> as "&"? What about 'put "!" into char x of pBinaryString?)

When concatenating if both left and right are binary strings (MCDataRef) then 
there’s no conversion of either to string however we do not currently have a 
way to declare a literal as a binary string (might be nice if we did!) so you 
would need to:

put textEncode("simple string”, “UTF-8”) after pBinaryString

> 
> The engine can tell whether a string is 'native' or UTF16. When the engine is 
> converting a binary string to 'string', does it always interpret the source 
> as the native 8-bit encoding, or does it have some heuristic to decide 
> whether it would be more plausible to interpret the source as UTF16?

No it does not try to interpret. ICU has a charset detector that will give you 
a list of possible charsets along with a confidence. It could be implemented as 
a separate api:

get detectedTextEncodings(, []) -> array 
of charset/confidence pairs

get bestDetectedTextEncoding(, []) -> 
charset

Feel free to feature request that!

Cheers

Monte


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

Re: What is LC's internal text format?

[Geoff Canyon via use-livecode]

I never left, I just went silent.

But since I'm "back", I'm curious to know what the engine-types think of
Bernd's solution for fixing the UTF-32 offsets code. It seems that when
converting both the stringToFind and stringToSearch to UTF-32 and then
searching the binary with byteOffset, you won't find "Reykjavík" in
"Reykjavík er höfuðborg"

But if you first append "せ" to each string, then do the textEncode, then
strip the last 4 bytes, the match will work. That seems like strange voodoo
to me.

On Tue, Nov 13, 2018 at 12:54 PM Ben Rubinstein via use-livecode <
use-livecode@lists.runrev.com> wrote:

> For the avoidance of doubt, all my outrage is faux outrage.
> Public life on both sides of the Atlantic (and around the world) has
> completely exhausted capacity for real outrage.
>
> Come back Geoff!
>
> Ben
>
> On 13/11/2018 17:29, Mark Waddingham via use-livecode wrote:
> > On 2018-11-13 18:21, Geoff Canyon via use-livecode wrote:
> >> Nothing I said in this thread has anything to do with optimizing the
> >> allOffsets routines; I only used examples from that discussion because
> they
> >> illustrate my puzzlement on the exact topic you (in general) raised: how
> >> data types are handled by the engine. I'd generalize the responses, to
> say
> >> that it seems how the engine stores data and how it presents that data
> are
> >> not identical in all cases.
> >
> > The best way to think about it is that the engine stores data pretty
> much in
> > the form it is presented with it; however, what script sees of data is
> in the
> > form it requests. In particular, if data has been through some
> operation, or
> > mutated, then there is a good change it won't be in the same form it was
> before.
> >
> > e.g. put tVar + 1 into tVar
> >
> > Here tVar could start off as a string, but would end up as a number by
> virtue
> > of the fact you've performed an arithmetic operation on it.
> >
> >> The above notwithstanding: sorry I outraged you; I'll exit this thread.
> >
> > Obviously I'm not Ben, but I *think* it was 'faux outrage' (well I hope
> it was
> > - hence my jocular comment about herding cats!) - so I don't think
> there's a
> > reason to exit...
> >
> > Warmest Regards,
> >
> > Mark.
> >
>
> ___
> 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

Reading data from Google Sheets

[Kaveh Bazargan via use-livecode]

Can someone point me to how I can read data from Google Sheets
into LiveCode? For now I just need to read, not write.

Thanks.

-- 
Kaveh Bazargan
Director
River Valley Technologies  • Twitter
 • LinkedIn

___
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: finding location on mobile device

[Ralph DiMola via use-livecode]

Mike

preOpenStack:

if the environment = "mobile" then
   if mobileSensorAvailable("location") then
  mobileStartTrackingSensor "Location", false
   end if
end if


--- this is a hacked up version of what I use. It should be close.
It compiles but not tested. I have to see if this needs some tweaks using
the new Android permission model.

function GetGpsCords
   -- returns
   -- Got fix: An array with ["latitude"] and ["longitude"]
   -- Bad lock: empty
   -- Permission issues: empty
   -- Not yet "retry"
   
   local tGPS
   if not (the environment = "mobile") then
  put 45.338960434184 into tGPS["latitude"]
  put -74.6840746841539 into tGPS["longitude"]
  return tGPS
   else
  put mobileSensorReading("location", true) into tGPS
  if tGPS["latitude"] is not empty and tGPS["longitude"] <> 0 then
 wait .25 seconds -- needed this in the past sometimes on first
location fix
 put mobileSensorReading("location", true) into tGPS
  end if
  
  if tGPS["latitude"] is not empty and tGPS["longitude"] <> 0 then
 return tGPS
  else
 
 local tGPStext
 
 switch the platform
case "iphone" -- see what the iOS permisstion status is
   put "Location Services" into tGPStext
   switch mobileLocationAuthorizationStatus()
  case "authorizedWhenInUse"
  case "authorizedAlways"
 answer tGPStext && "can't determine your location." &
cr & \
   "If your" && tGPStext && "was just enabled,
please try again in a few minutes." \   with "OK"
titled "Proximity Search"

 return empty
 break
  case "denied"
  case "restricted"
 answer "App is not authorized to access"& &"."
& cr & \
   "In Settings, please select" && quote & "While
Using the App"  && "in" && quote&"Location Services" & quote
&& "in this app's settings" \
   with "OK" titled "Proximity Search"
 return empty
 break
  case "notDetermined"
 if mobileSensorAvailable("location") then
   mobileStartTrackingSensor "Location", false
   return "Retry"
 end if
 return empty
 break

  default
 answer tGPStext && "can't determine your location." &
cr & \
   "If your" && tGPStext && "was just enabled,
please try again in a few minutes." \
   with "OK" titled "Proximity Search"
 return empty
   end switch
   break
default
   put "GPS" into tGPStext
   answer tGPStext && "can't determine your location." & cr & \
 "If your" && tGPStext && "was just enabled, please try
again in a few minutes." \
 with "OK" titled "Proximity Search"
   return empty
 end switch
  end if
   end if
end GetGpsCords



Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Mike for GDC via use-livecode
Sent: Tuesday, November 13, 2018 3:06 PM
To: use-livecode@lists.runrev.com
Cc: Mike for GDC
Subject: finding location on mobile device

I am trying to find my current lat/long on my android device.  I have played
around with multiple options including "mobileCurrentLocation" and others.
I have not been able to find an example of code that does it and works.
What I want to do is push a button, have the lat/long displayed so as I can
then "feed" it into a map widget for display.  Does anyone have an example
of code that does just that?  Thanks.  Mike

___
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: How to find offsets in Unicode Text fast

[Geoff Canyon via use-livecode]

I didn't realize this conversation was just between Bernd and me, so here
it is for the list. Bernd found a solution for the Reykjavík issue
(seemingly -- it works, but it's weird) and based on a conversation in
another thread I have a solution for non-case-sensitive matching. So the
UTF-32 version has been updated to account for those issues. It's available
here: https://github.com/gcanyon/alloffsets

On Tue, Nov 13, 2018 at 12:23 PM Geoff Canyon  wrote:

> It's amazing to me that appending the character "せ" for the textEncoding
> fixes the issues with the other characters. I have no idea why that would
> affect anything else at all. Maybe the engine crew can weigh in.
>
> In any case, you seem to have hit on the right bizarre solution, so I
> added that in. I also added a modification to correctly handle case by
> using toUpper instead of (wrongly) depending on caseSensitive, and changed
> from offset to byteOffset, which might speed things up a little. The UTF32
> version is about 3x faster than the item-based solution, but both scale
> well, so I added comments leaving it up to the developer which to use.
>
> The updated version is here: https://github.com/gcanyon/alloffsets
>
> On Tue, Nov 13, 2018 at 9:34 AM Niggemann, Bernd <
> bernd.niggem...@uni-wh.de> wrote:
>
>> Geoff,
>>
>> The thread is very instructive but also a bit disillusioning as far as
>> speed goes. I tried a couple of things Mark Waddingham recommended and they
>> kind of work (I don't know if I did it correctly) but are still slow. Not
>> as slow as simple offset for complex texts but still.
>>
>> Here I pick up on your latest attempt to use UTF-32 which fails on
>> Icelandic Reykjavík (the í is the culprit). There are more Icelandic
>> characters that fail UTF32.
>>
>> On the other hand UTF-32 works surprisingly fast and in many cases
>> accurately.
>>
>> Now I figured that forcing the text to be UTF-32 compliant I would cheat
>> in appending a Japanese character to pFind and pSearch before converting to
>> UTF-32 and removing those afterwards.
>>
>> It turns out that it cures the Icelandic disease...
>> It should also cure similar cases in similar languages.
>> It turns out to be accurate in many things I tested in Brian's test stack.
>>
>> I would love to know the limits of this approach
>>
>> Kind regards
>>
>> Bernd
>>
>> here is the code, additions marked as "new"
>>
>>
>> -
>> *function* allOffsets pFind,pString,pCaseSensitive,pNoOverlaps
>>*-- returns a comma-delimited list of the offsets of pFind in pString*
>>*-- note, this seems to fail on some searches, for example:*
>>*-- searching for "Reykjavík" in "Reykjavík er höfuðborg"*
>>*-- It is uncertain why.*
>>*-- See thread here:
>> http://lists.runrev.com/pipermail/use-livecode/2018-November/251357.html
>> *
>>*local* tNewPos, tPos, tResult, tSkip
>>
>>
>>*put* "せ" after pFind *#<- new force UTF-32*
>>*put* "せ" after pString *#<- new force UTF-32*
>>
>>
>>
>>
>>*put* textEncode(pFind,"UTF-32") into pFind
>>*put* textEncode(pString,"UTF-32") into pString
>>
>>
>>*delete* byte -4 to -1 of pFind *#<- new force UTF-32*
>>*delete* byte -4 to -1 of pString *#<- new force UTF-32*
>>
>>
>>*if* pNoOverlaps *then* *put* length(pFind) - 1 into tSkip
>>
>>
>>*set* the caseSensitive to pCaseSensitive is true
>>*put* 0 into tPos
>>*repeat* forever
>>   *put* offset(pFind, pString, tPos) into tNewPos
>>   *if* tNewPos = 0 *then* *exit* *repeat*
>>   *add* tNewPos to tPos
>>   *if* tPos mod 4 = 1 *then* *put* (tPos div 4 + 1),"" after tResult
>>   *if* pNoOverlaps *then* *add* tSkip to tPos
>>*end* * repeat*
>>*if* tResult is empty *then* *return* 0
>>*else* *return* char 1 to -2 of tResult
>> *end* allOffsets
>> -
>>
>
___
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: finding location on mobile device

[Devin Asay via use-livecode]

This has worked for me in the past, but I haven’t tried it in quite some time:

mobileStartTrackingSensor "location", false
put mobileCurrentLocation() into tLocArray
mobileStopTrackingSensor "location"
put "lat: " & tLocArray["latitude"] & cr & "long: " & tLocArray["longitude”] 
into fld "report"

Devin

> On Nov 13, 2018, at 1:06 PM, Mike for GDC via use-livecode 
>  wrote:
> 
> I am trying to find my current lat/long on my android device.  I have played
> around with multiple options including "mobileCurrentLocation" and others.
> I have not been able to find an example of code that does it and works.
> What I want to do is push a button, have the lat/long displayed so as I can
> then "feed" it into a map widget for display.  Does anyone have an example
> of code that does just that?  Thanks.  Mike
> 
> ___
> 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

Devin Asay
Director
Office of Digital Humanities
Brigham Young University

___
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: What is LC's internal text format?

[Ben Rubinstein via use-livecode]

For the avoidance of doubt, all my outrage is faux outrage.
Public life on both sides of the Atlantic (and around the world) has 
completely exhausted capacity for real outrage.


Come back Geoff!

Ben

On 13/11/2018 17:29, Mark Waddingham via use-livecode wrote:

On 2018-11-13 18:21, Geoff Canyon via use-livecode wrote:

Nothing I said in this thread has anything to do with optimizing the
allOffsets routines; I only used examples from that discussion because they
illustrate my puzzlement on the exact topic you (in general) raised: how
data types are handled by the engine. I'd generalize the responses, to say
that it seems how the engine stores data and how it presents that data are
not identical in all cases.


The best way to think about it is that the engine stores data pretty much in 
the form it is presented with it; however, what script sees of data is in the 
form it requests. In particular, if data has been through some operation, or 
mutated, then there is a good change it won't be in the same form it was before.


e.g. put tVar + 1 into tVar

Here tVar could start off as a string, but would end up as a number by virtue 
of the fact you've performed an arithmetic operation on it.



The above notwithstanding: sorry I outraged you; I'll exit this thread.


Obviously I'm not Ben, but I *think* it was 'faux outrage' (well I hope it was 
- hence my jocular comment about herding cats!) - so I don't think there's a 
reason to exit...


Warmest Regards,

Mark.



___
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: [ANN] Release 9.0.2 RC-1

[panagiotis merakos via use-livecode]

Hello Brahmanathaswami,

Could it be the case that you have accidentally checked the "build 32bit
slice only" checkbox in the iOS standalone settings?

Regards,
Panos

On Tue, Nov 13, 2018, 22:24 Sannyasin Brahmanathaswami via use-livecode <
use-livecode@lists.runrev.com wrote:

> Hit send button too soon
> > Bad news. (Does not change my little "guide")
> >
> > Build the app, used Jacqulines "Air Launch" get SivaSiva.ipa
> >
> > I already had new release, 1.3 on iTuneConnect.
> >
> > Booted Application Loader
> > Run the SivaSiva.ipa
> >
> > It passed all analyses; I got a message from Application Loader "Success
> > [snip other stuff] we will get a review shortly.
> >
> > That was saturday
> On Monday I get a message from Apple that there was "invalid
> architecture" in app,
>
> Plus the using Push Notification Warning and Beta Test entitlement
> missing those are not blockers for approval. But "invalid architecture" is
>
> No further info
>
> I have ticket in with Livecode support.
>
>
> Brahmanathaswami
>
>
> ___
> 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: [ANN] Release 9.0.2 RC-1

[Sannyasin Brahmanathaswami via use-livecode]

Hit send button too soon
> Bad news. (Does not change my little "guide")
>
> Build the app, used Jacqulines "Air Launch" get SivaSiva.ipa
>
> I already had new release, 1.3 on iTuneConnect.
>
> Booted Application Loader
> Run the SivaSiva.ipa
>
> It passed all analyses; I got a message from Application Loader "Success
> [snip other stuff] we will get a review shortly.
>
> That was saturday
On Monday I get a message from Apple that there was "invalid
architecture" in app,

Plus the using Push Notification Warning and Beta Test entitlement
missing those are not blockers for approval. But "invalid architecture" is

No further info

I have ticket in with Livecode support.


Brahmanathaswami


___
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: [ANN] Release 9.0.2 RC-1

[Sannyasin Brahmanathaswami via use-livecode]

Bad news. (Does not change my little "guide")

Build the app, used Jacqulines "Air Launch" get SivaSiva.ipa

I already had new release, 1.3 on iTuneConnect.

Booted Application Loader
Run the SivaSiva.ipa

It passed all analyses; I got a message from Application Loader "Success
[snip other stuff] we will get a review shortly.

That was saturday

On Monday


On 11/10/18 6:15 PM, Pi Digital via use-livecode wrote:
> Perhaps we should get a simplified version of this into every release note 
> from here on in. It will save a whole heap of hunting around for them. 
>
> Sean Cole
> Pi Digital
>
>> On 10 Nov 2018, at 14:59, Sannyasin Brahmanathaswami via use-livecode 
>>  wrote:
>>
>> https://developer.apple.com/download/more/
>>
>> filter the list to iOS (side panel)
>>
>> 1) get  Xcode 10.0
>> 2) also Command_Line_Tools_macOS_10.14_for_Xcode_10.dmg
>>
>> It seems when you install manually like this, Xcode does not prompt to
>> "install additional components" because, if you already downloaded from
>> the store, and got the prompt and installed them, (my guess is that) the
>> system thinks "Oh he got everything."
>>
>> But, upon building a standalone you will have troubles. Because you did
>> not get  tools to the current version of Xcode that you installed
>> manually. So download these for Xcode 10 and install
>>
>> Next, be sure to run from the command line
>>
>> sudo xcode-select --switch /Applications/Xcode.app [or-your-path]


___
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

finding location on mobile device

[Mike for GDC via use-livecode]

I am trying to find my current lat/long on my android device.  I have played
around with multiple options including "mobileCurrentLocation" and others.
I have not been able to find an example of code that does it and works.
What I want to do is push a button, have the lat/long displayed so as I can
then "feed" it into a map widget for display.  Does anyone have an example
of code that does just that?  Thanks.  Mike

___
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: LiveCoders from London, lets meet!

[Bernard Devlin via use-livecode]

I live outside London, but easy enough to get in to meet up.

On Sat, Nov 10, 2018 at 2:14 PM Keith Martin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hi Andre,
>
> I'm based in London – I live in Mitcham/Tooting and I work in Elephant
> & Castle. I'm game!
>
> k
>
>
> On 9 Nov 2018, at 17:04, Andre Alves Garzia via use-livecode wrote:
>
> > Hey Friends,
> >
> > Who here is from London or nearby and would be interested in regular
> > meetups? We could meet once a month or so in a pub or quieter setting.
> > I am thinking of informal meet & drink, chatting.
> >
> > Cheers
> >
> > andre
> >
> >
___
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: What is LC's internal text format?

[Jerry Jensen via use-livecode]

> On Nov 13, 2018, at 2:52 AM, Mark Waddingham via use-livecode 
>  wrote:
> 
> Yes - a byte is not a number, a char is not a number a bit sequence is not a 
> number.

Reminds of a clever sig line from somebody on this list.
I can’t remember who, so author please step up and take credit.
Paraphrasing The Prisoner:

“I am not a number, I am a free NaN”.
___
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: What is LC's internal text format?

[Ben Rubinstein via use-livecode]

That's really helpful - and in parts eye-opening - thanks Mark.

I have a few follow-up questions.

Does textEncode _always_ return a binary string? Or, if invoked with "CP1252", 
"ISO-8859-1", "MacRoman" or "Native", does it return a string?


> CodepointOffset has signature 'integer codepointOffset(string)', so when you
> pass a binary string (data) value to it, the data value gets converted to a
> string by interpreting it as a sequence of bytes in the native encoding.

OK - so one message I take are that in fact one should never invoke 
codepointOffset on a binary string. Should it actually throw an error in this 
case?


By the same token, probably one should only use 'byte', 'byteOffset', 
'byteToNum' etc with binary strings - would it be better, to avoid confusion, 
if char, offset, charToNum should refuse to operate on a binary string?



e.g. In the case of &, it can either take two data arguments, or two
string arguments. In this case, if both arguments are data, then the result
will be data. Otherwise both arguments will be converted to strings, and a
string returned.
The second message I take is that one needs to be very careful, if operating 
on UTF8 or other binary strings, to avoid 'contaminating' them e.g. by 
concatenating with a simple quoted string, as this may cause it to be silently 
converted to a non-binary string. (I presume that 'put "simple string" 
after/before pBinaryString' will cause a conversion in the same way as "&"? 
What about 'put "!" into char x of pBinaryString?)


The engine can tell whether a string is 'native' or UTF16. When the engine is 
converting a binary string to 'string', does it always interpret the source as 
the native 8-bit encoding, or does it have some heuristic to decide whether it 
would be more plausible to interpret the source as UTF16?


Thanks again for all the detail!

Ben

On 13/11/2018 13:31, Mark Waddingham via use-livecode wrote:

On 2018-11-13 12:43, Ben Rubinstein via use-livecode wrote:

I'm grateful for all the information, but _outraged_ that the thread
that I carefully created separate from the offset thread was so
quickly hijacked for the continuing (useful!) detailed discussion on
that topic.


The phrase 'attempting to herd cats' springs to mind ;)


From recent contributions on both threads I'm getting some more
insights, but I'd really like to understand clearly what's going on. I
do think that I should have asked this question more broadly: how does
the engine represent values internally?


The engine uses a number of distinct types 'behind the scenes'. The ones
pertinent to LCS (there are many many more which LCS never sees) are:

   - nothing: a type with a single value nothing/null)
   - boolean: a type with two values true/false
   - number: a type which can either store a 32-bit integer *or* a double
   - string: a type which can either store a sequence of native (single byte) 
codes, or a sequence of unicode (two byte - UTF-16) codes
   - name: a type which stores a string, but uniques the string so that 
caseless and exact equality checking is constant time

   - data: a type which stores a sequence of bytes
   - array: a type which stores (using a hashtable) a mapping from 'names' to 
any other storage value type


The LCS part of the engine then sits on top of these core types, providing
various conversions depending on context.

All LCS syntax is actually typed - meaning that when you pass a value to any
piece of LCS syntax, each argument is converted to the type required.

e.g. charToNativeNum() has signature 'integer charToNativeNum(string)' meaning 
that it

expects a string as input and will return a number as output.

Some syntax is overloaded - meaning that it can act in slightly different (but 
always consistent) ways depending on the type of the arguments.


e.g. & has signatures 'string &(string, string)' and 'data &(data, data)'.

In simple cases where there is no overload, type conversion occurs exactly as 
required:


e.g. In the case of charToNativeNum() - it has no overload, so always expects 
a string
which means that the input argument will always undergo a 'convert to string' 
operation.


The convert to string operation operates as follows:

    - nothing -> ""
    - boolean -> "true" or "false"
    - number -> decimal representation of the number, using numberFormat
    - string -> stays the same
    - name -> uses the string the name contains
    - data -> converts to a string using the native encoding
    - array -> converts to empty (a very old semantic which probably does more 
harm than good!)


In cases where syntax is overloaded, type conversion generally happens in 
syntax-specific sequence in order to preserve consistency:


e.g. In the case of &, it can either take two data arguments, or two string 
arguments. In this case,
if both arguments are data, then the result will be data. Otherwise both 
arguments will be converted

to strings, and a string returned.


From Monte I get that the 

Re: What is LC's internal text format?

[Mark Waddingham via use-livecode]

On 2018-11-13 18:21, Geoff Canyon via use-livecode wrote:

Nothing I said in this thread has anything to do with optimizing the
allOffsets routines; I only used examples from that discussion because 
they
illustrate my puzzlement on the exact topic you (in general) raised: 
how
data types are handled by the engine. I'd generalize the responses, to 
say
that it seems how the engine stores data and how it presents that data 
are

not identical in all cases.


The best way to think about it is that the engine stores data pretty 
much in the form it is presented with it; however, what script sees of 
data is in the form it requests. In particular, if data has been through 
some operation, or mutated, then there is a good change it won't be in 
the same form it was before.


e.g. put tVar + 1 into tVar

Here tVar could start off as a string, but would end up as a number by 
virtue of the fact you've performed an arithmetic operation on it.



The above notwithstanding: sorry I outraged you; I'll exit this thread.


Obviously I'm not Ben, but I *think* it was 'faux outrage' (well I hope 
it was - hence my jocular comment about herding cats!) - so I don't 
think there's a reason to exit...


Warmest Regards,

Mark.

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

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

Re: What is LC's internal text format?

[Geoff Canyon via use-livecode]

On Tue, Nov 13, 2018 at 3:43 AM Ben Rubinstein via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I'm grateful for all the information, but _outraged_ that the thread that
> I
> carefully created separate from the offset thread was so quickly hijacked
> for
> the continuing (useful!) detailed discussion on that topic.
>

Nothing I said in this thread has anything to do with optimizing the
allOffsets routines; I only used examples from that discussion because they
illustrate my puzzlement on the exact topic you (in general) raised: how
data types are handled by the engine. I'd generalize the responses, to say
that it seems how the engine stores data and how it presents that data are
not identical in all cases.

Separately, it's interesting to hear that the engine (can) store(s) numeric
values for strings, as an optimization.

The above notwithstanding: sorry I outraged you; I'll exit this thread.
___
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

Widget Browser, useragent and iOS

[Ludovic THEBAULT via use-livecode]

Hello,

It seems we cannot set the user agent of the widget browser on iOS. Any 
workaround ?

Thanks !
___
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: put the openStacks

[Bob Sneidar via use-livecode]

Oh that's a great idea for a Livecode party! After a few drinks, everyone dons 
nerf boots and begins kicking each other in the nether region. 

Bob S


> On Nov 11, 2018, at 01:12 , Richmond via use-livecode 
>  wrote:
> 
> Um, that kicking might prove mutual; or even, dare I say it, into a 
> free-for-all melee among quite a few people.
> 
> Richmond.


___
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: What is LC's internal text format?

[Bob Sneidar via use-livecode]

There is a quest in World of Warcraft where the objective is actually to herd 
cats. It can be done, but only one cat at a time. :-)

Bob S


> On Nov 13, 2018, at 05:31 , Mark Waddingham via use-livecode 
>  wrote:
> 
> On 2018-11-13 12:43, Ben Rubinstein via use-livecode wrote:
>> I'm grateful for all the information, but _outraged_ that the thread
>> that I carefully created separate from the offset thread was so
>> quickly hijacked for the continuing (useful!) detailed discussion on
>> that topic.
> 
> The phrase 'attempting to herd cats' springs to mind ;)


___
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: What is LC's internal text format?

[Mark Waddingham via use-livecode]

On 2018-11-13 12:43, Ben Rubinstein via use-livecode wrote:

I'm grateful for all the information, but _outraged_ that the thread
that I carefully created separate from the offset thread was so
quickly hijacked for the continuing (useful!) detailed discussion on
that topic.


The phrase 'attempting to herd cats' springs to mind ;)


From recent contributions on both threads I'm getting some more
insights, but I'd really like to understand clearly what's going on. I
do think that I should have asked this question more broadly: how does
the engine represent values internally?


The engine uses a number of distinct types 'behind the scenes'. The ones
pertinent to LCS (there are many many more which LCS never sees) are:

  - nothing: a type with a single value nothing/null)
  - boolean: a type with two values true/false
  - number: a type which can either store a 32-bit integer *or* a double
  - string: a type which can either store a sequence of native (single 
byte) codes, or a sequence of unicode (two byte - UTF-16) codes
  - name: a type which stores a string, but uniques the string so that 
caseless and exact equality checking is constant time

  - data: a type which stores a sequence of bytes
  - array: a type which stores (using a hashtable) a mapping from 
'names' to any other storage value type


The LCS part of the engine then sits on top of these core types, 
providing

various conversions depending on context.

All LCS syntax is actually typed - meaning that when you pass a value to 
any

piece of LCS syntax, each argument is converted to the type required.

e.g. charToNativeNum() has signature 'integer charToNativeNum(string)' 
meaning that it

expects a string as input and will return a number as output.

Some syntax is overloaded - meaning that it can act in slightly 
different (but always consistent) ways depending on the type of the 
arguments.


e.g. & has signatures 'string &(string, string)' and 'data &(data, 
data)'.


In simple cases where there is no overload, type conversion occurs 
exactly as required:


e.g. In the case of charToNativeNum() - it has no overload, so always 
expects a string
which means that the input argument will always undergo a 'convert to 
string' operation.


The convert to string operation operates as follows:

   - nothing -> ""
   - boolean -> "true" or "false"
   - number -> decimal representation of the number, using numberFormat
   - string -> stays the same
   - name -> uses the string the name contains
   - data -> converts to a string using the native encoding
   - array -> converts to empty (a very old semantic which probably does 
more harm than good!)


In cases where syntax is overloaded, type conversion generally happens 
in syntax-specific sequence in order to preserve consistency:


e.g. In the case of &, it can either take two data arguments, or two 
string arguments. In this case,
if both arguments are data, then the result will be data. Otherwise both 
arguments will be converted

to strings, and a string returned.


From Monte I get that the internal encoding for 'string' may be
MacRoman, ISO 8859 (I thought it would be CP1252), or UTF16 -
presumably with some attribute to tell the engine which one in each
case.


Monte wasn't quite correct - on Mac it is MacRoman or UTF-16, on Windows 
it
is CP1252 or UTF-16, on Linux it is IOS8859-1 or UTF-16. There is an 
internal
flag in a string value which says whether its character sequence is 
single-byte (native)

or double-byte (UTF_16).


So then my question is whether a 'binary string' is a pure blob, with
no clues as to interpretation; or whether in fact it does have some
attributes to suggest that it might be interpreted as UTF8, UTF132
etc?


Data (binary string) values are pure blobs - they are sequences of bytes 
- it has
no knowledge of where it came from. Indeed, that would generally be a 
bad idea as you
wouldn't get repeatable semantics (i.e. a value from one codepath which 
is data, might
have a different effect in context from one which is fetched from 
somewhere else).


That being said, the engine does store some flags on values - but purely 
for optimization.
i.e. To save later work. For example, a string value can store its 
(double) numeric value in
it - which saves multiple 'convert to number' operations performed on 
the same (pointer wise) string (due to the copy-on-write nature of 
values, and the fact that all literals are unique names, pointer-wise 
equality of values occurs a great deal).



If there are no such attributes, how does codepointOffset operate when
passed a binary string?


CodepointOffset is has signature 'integer codepointOffset(string)', so 
when you
pass a binary string (data) value to it, the data value gets converted 
to a string

by interpreting it as a sequence of bytes in the native encoding.


If there are such attributes, how do they get set? Evidently if
textEncode is used, the engine knows that the resulting value is the
requested encoding. But what 

Re: What is LC's internal text format?

[Ben Rubinstein via use-livecode]

I'm grateful for all the information, but _outraged_ that the thread that I 
carefully created separate from the offset thread was so quickly hijacked for 
the continuing (useful!) detailed discussion on that topic.


From recent contributions on both threads I'm getting some more insights, but 
I'd really like to understand clearly what's going on. I do think that I 
should have asked this question more broadly: how does the engine represent 
values internally?



I believe from what I've read that the engine can distinguish the following 
kinds of value:

- empty
- array
- number
- string
- binary string

From Monte I get that the internal encoding for 'string' may be MacRoman, ISO 
8859 (I thought it would be CP1252), or UTF16 - presumably with some attribute 
to tell the engine which one in each case.


So then my question is whether a 'binary string' is a pure blob, with no clues 
as to interpretation; or whether in fact it does have some attributes to 
suggest that it might be interpreted as UTF8, UTF132 etc?


If there are no such attributes, how does codepointOffset operate when passed 
a binary string?


If there are such attributes, how do they get set? Evidently if textEncode is 
used, the engine knows that the resulting value is the requested encoding. But 
what happens if the program reads a file as 'binary' - presumable the result 
is a binary string, how does the engine treat it?


Is there any way at LiveCode script level to detect what a value is, in the 
above terms?


And one more question: if a string, or binary string, is saved in a 'binary' 
file, are the bytes stored on disk a faithful rendition of the bytes that 
composed the value in memory, or an interpretation of some kind?


TIA,

Ben

___
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: How to find offsets in Unicode Text fast

[Mark Waddingham via use-livecode]

On 2018-11-13 11:37, Geoff Canyon via use-livecode wrote:
I understand (generally) the complexity of comparison, but that's not 
the

speed issue causing this discussion. Most of the proposed solutions are
using nearly the same operators/functions for comparison, or at least 
the

same comparison is being done. Instead, the problem is a Foolish Line
Painter problem: with single-byte characters, finding all occurrences 
of
one string in another by repeatedly using offset() with charsToSkip 
scales

well; but with multi-byte characters, the penalty for repeatedly
calculating out longer and longer skips is exponential.


The actual reason its not linear when you have Unicode strings (the 
behavior
isn't exponential, btw - cubic, I think) is that to work out the 
character
index in a Unicode string is a O(n) operation - in native strings its 
O(1).


So, I revise what I said before, you actually need to use 
codeunitOffset() with
formSensitive and caseSensitive set to true, with your input strings 
appropriately

processed.

The only wrinkle with that is that you might get 'false-positive' 
matches - i.e.

where a match is not on character boundaries:

e.g. [e, combining-acute] will be found in [e, combining-acute, 
combining-grave]
even though the latter is *not* the former as characters (but is as 
codeunits).


Using textEncode("UTF-32") / binary offset will cause more 
false-positives than that
(as you've mentioned before) as it could find matches which are not on a 
4 byte boundary.


Warmest Regards,

Mark.

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

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

Re: What is LC's internal text format?

[Mark Waddingham via use-livecode]

On 2018-11-13 11:06, Geoff Canyon via use-livecode wrote:
I don't *think* I'm confusing binary string/data with binary numbers -- 
I

was just trying to illustrate that when a Latin Small Letter A (U+0061)
gets encoded, somewhere there is stored (four bytes, one of which is) a
byte 97, i.e. the bit sequence 111, unless computers don't work 
that

way anymore.


Yes - a byte is not a number, a char is not a number a bit sequence is 
not a number.


Chars have never been numbers in LC - when LC sees a char - it sees a 
string and so
when such a thing is used in number context it converts it to the number 
it *looks* like
i.e. "1" -> 1, but "a" -> error in number context (bearing in mind the 
code for "1" is not 1).


i.e. numToChar(charToNum("1")) + 0 -> 1

The same is try for 'byte' in LC7+ (indeed prior to that byte was a 
synonym for char).


What I now see is tripping me up is the implicit cast to a character 
you're
saying that charToNum supports, without the corresponding cast to a 
number

supported in numToChar -- i.e. this fails:

put textEncode("a","UTF-32") into X;put numtochar(byte 1 of X)


Right so that shouldn't work - byte 1 of X here is <97> (a byte), bytes 
get converted to native
chars in string context, so numToChar(byte 1 of X) -> numToChar(<97> as 
char) -> numToChar("a")

and "a" is not a number.

You'd get exactly the same result if you did put numToChar(char 1 of 
"a").


As I said, bytes are not numbers, just as chars are not numbers - bytes 
do implicitly convert to
(native) chars though - so when you use a binary string in number 
context, it gets treated as a

numeric string.

Put another way, just as the code for a char is not used in conversion 
in number context, the

code of a byte is not used either.

Warmest Regards,

Mark.

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

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

Re: How to find offsets in Unicode Text fast

[Geoff Canyon via use-livecode]

A lot of useful points here, thanks.

The caseSensitive vs. binary has been covered in the other discussion --
Monte said that by using offset() "the engine will convert your data to a
string and assume native encoding. This is probably why you are getting
some case insensitivity."


I understand (generally) the complexity of comparison, but that's not the
speed issue causing this discussion. Most of the proposed solutions are
using nearly the same operators/functions for comparison, or at least the
same comparison is being done. Instead, the problem is a Foolish Line
Painter problem: with single-byte characters, finding all occurrences of
one string in another by repeatedly using offset() with charsToSkip scales
well; but with multi-byte characters, the penalty for repeatedly
calculating out longer and longer skips is exponential.

The fastest proposed solutions so far, which both scale much more closely
to linearly with the size of the stringToSearch, are:

1. Set the item delimiter to the charsToFind and then use repeat for each
item on the stringToSearch. This comes with its own headaches, but supports
(lack of) case sensitivity.
2. Converting to UTF-32 binary, and using offset and charsToSkip. This
hasn't yet been corrected to use byteOffset and toUpper to property handle
case insensitivity, but once that is done, this will probably be the
preferred solution between the two -- the logic is simpler, and it's
several times faster.

Thanks,

Geoff

On Tue, Nov 13, 2018 at 12:27 AM Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2018-11-13 01:06, Geoff Canyon via use-livecode wrote:
> > On Mon, Nov 12, 2018 at 11:36 AM Ben Rubinstein via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> >> I'm really confused that case-insensitive should work at all for
> >> UTF-16 or
> >> UTF-32;
>
> The caseSensitive (and formSensitive) properties only apply to strings
> *not* binary strings.
>
> The output of textEncode() is a binary string.
>
> The 'is' operator is overloaded - in strict order:
>
>left-empty 'is' right-ANY -- returns is-empty(right-ANY)
>left-ANY 'is' right-empty -- returns is-empty(left-ANY)
>left-array 'is' left-array -- compare as array
>left-number 'is' right-number -- compare as number
>left-numeric-[binary]-string 'is' right-numeric-[binary]-string --
> compare as number
>left-binary-string 'is' right-binary-string -- compare as binary
> strings
>left-any 'is' right-any -- compare as strings
>
> Also concatenation, put after and put before are overloaded:
>
> binary-string & binary-string -> binary-string
> string & ANY -> string
> ANY & string -> string
>
> put src-data after|before dst-data -> dst-data is binary-string
> put src-ANY after|before dst-ANY -> dst-ANY is string
>
> > This is so puzzling. I tried this code in a button:
> >
> > on mouseUp
> >put "Ѡ" into x
> >put "ѡ" into y
> >--put ("Ѡ" is "ѡ") && (x is y)
> >--exit mouseUp
> >put textencode("Ѡ","UTF-32") into xBig
> >put textencode("ѡ","UTF-32") into xSmall
> >repeat for each byte B in xBig
> >   put B after yBig
> >end repeat
> >repeat for each byte B in xSmall
> >   put B after ySmall
> >end repeat
> >put "Ѡ" into zBig
> >put "ѡ" into zSmall
> >put zBig into wBig
> >put zSamll into wSmall
> >put textencode(zBig,"UTF-32") into zBig
> >put textencode(zSmall,"UTF-32") into zSmall
> >put x into j
> >put y into k
> >set caseSensitive to false
> >put ("Ѡ" is "ѡ") && (xBig is xSmall) && (yBig is ySmall) && (zBig is
> > zSmall) && (wBig is wSmall) && (x is y) && (j is k)
> > end mouseUp
> >
> >
> > That puts: true false false false true true true
> >
> > Things to note:
> >
> > 1. "Ѡ" and "ѡ" are upper and lower case omega in cyrillic, 0460 and
> > 0461. Given the string literals, LC is happy to say they are the
> > same
> > (the first true)
> > 2. Put them in a variable, LC is happy to say they are the same
> > (the second-to-last true).
> > 3. Convert them to UTF-32 and LC no longer recognizes them as the same
> > (the
> > fourth boolean, false)
> > 4. Put the variables into other variables, and LC identifies them as
> > the
> > same (the last true)
>
> ("Ѡ" is "ѡ") is true because they are both strings
> (xBig is xSmall) is false because both sides are binary-strings (and so
> compare byte for byte)
> (yBig is ySmall) is false because both sides are binary-strings
> (zBig is zSmall) is false because you've textEncoded strings which
> produce binary-strings so both are binary strings
> (wBig is wSmall) is true because both sides are strings
> (x is y) is true because both sides are strings
> (j is k) is true because both sides are strings
>
> One could argue that 'is'/'is not' should never have been overloaded to
> do binary string comparison - and that should have perhaps been added as
> a separate operator (especially since binary strings are 

Re: What is LC's internal text format?

[Geoff Canyon via use-livecode]

I don't *think* I'm confusing binary string/data with binary numbers -- I
was just trying to illustrate that when a Latin Small Letter A (U+0061)
gets encoded, somewhere there is stored (four bytes, one of which is) a
byte 97, i.e. the bit sequence 111, unless computers don't work that
way anymore.

What I now see is tripping me up is the implicit cast to a character you're
saying that charToNum supports, without the corresponding cast to a number
supported in numToChar -- i.e. this fails:

put textEncode("a","UTF-32") into X;put numtochar(byte 1 of X)

while this works:

put textEncode("a","UTF-32") into X;put numtochar(bytetonum(byte 1 of X))

Thanks for the insight,

Geoff

On Tue, Nov 13, 2018 at 12:03 AM Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2018-11-13 08:35, Geoff Canyon via use-livecode wrote:
> > So then why does put textEncode("a","UTF-32") into X;put chartonum(byte
> > 1
> > of X) put 97?
>
> Because:
>
>1) textEncode("a", "UTF-32") produces the byte sequence <97,0,0,0>
>2) byte 1 of <97,0,0,0> is <97>
>3) charToNum(<97>) first converts the byte <97> into a native string
> which is "a" (as the 97 is the code for 'a' in the native encoding
> table), then converts that (native) char to a number -> 97
>
> > That implies that "byte" 1 is "a", not 111.
>
> 111 is 97 but printed in base-2.
>
> FWIW, I think you are confusing 'binary string' with 'binary number' -
> these are not the same thing.
>
> A 'binary string' (internally the data type is 'Data') is a sequence of
> bytes (just as a 'string' is a sequence of
> characters/codepoints/codeunits).
>
> A 'binary number' is a number which has been rendered to a string with
> base-2.
>
> Bytes are like characters (and codepoints, and codeunits) in that they
> are 'abstract' things - they aren't numbers, and have no direct
> conversion to them - which is why we have byteToNum, numToByte,
> nativeCharToNum, numToNativeChar, codepointToNum and numToCodepoint.
>
> The charToNum and numToChar functions are actually deprecated /
> considered legacy - as their function (when useUnicode is set to true)
> depends on processing unicode text as binary data - which isn't how
> unicode works post-7 (indeed, there was no way to fold their behavior
> into the new model - hence the deprecation, and replacement with
> nativeCharToNum / numToNativeChar).
>
> You'll notice that there is no modern 'charToNum'/'numToChar' - just
> 'codepointToNum'/'numToCodepoint'. A codepoint is an index into the
> (large - 21-bit) Unicode code table; Unicode characters can be composed
> of multiple codepoints (e.g. [e,combining-acute] and thus don't have a
> 'number' per-se.
>
> Warmest Regards,
>
> Mark.
>
> >
> > I've looked in the dictionary and I don't see anything that comes close
> > to
> > describing this.
> >
> > gc
> >
> > On Mon, Nov 12, 2018 at 10:21 PM Mark Waddingham via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> >> On 2018-11-13 07:15, Geoff Canyon via use-livecode wrote:
> >> > On Mon, Nov 12, 2018 at 3:50 PM Monte Goulding via use-livecode <
> >> > use-livecode@lists.runrev.com> wrote:
> >> > Unless I'm misunderstanding, this hasn't been my observation. Using
> >> > offset
> >> > on a string that has been textEncodet()ed to UTF-32 returns values
> that
> >> > are
> >> > 4 * (the character offset - 1) + 1 -- if it were re-encoded, wouldn't
> >> > it
> >> > return the actual offsets (except when it fails)? Also, 
 encodes to
> >> > 00010001, and routines that convert to UTF-32 and then use offset will
> >> > find
> >> > five instances of that character in the UTF-32 encoding because of
> >> > improper
> >> > boundaries. To see this, run this code:
> >> >
> >> > on mouseUp
> >> >put textencode("
","UTF-32") into X
> >> >put textencode("


","UTF-32") into Y
> >> >put offset(X,Y,1)
> >> > end mouseUp
> >> >
> >> > That will return 2, meaning that it found the encoding for X starting
> >> > at
> >> > character 2 + 1 = 3 of Y. In other words, it found X using the last
> >> > half of
> >> > the first "
" and the first half of the second "
"
> >>
> >> The textEncode function generates binary data which is composed of
> >> bytes. When you use binary data in a text function (which offset is),
> >> the engine uses a compatability conversion which treats the sequence
> >> of
> >> bytes as a sequence of native characters (this preserves what happened
> >> pre-7.0 when strings were only ever native, and as such binary and
> >> string were essentially the same thing).
> >>
> >> So if you textEncode a 1 (native) character string as UTF-32, you will
> >> get a four byte string, which will then turn back into a 4 (native)
> >> character string when passed to offset.
> >>
> >> Warmest Regards,
> >>
> >> Mark.
> >>
> >> --
> >> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> >> LiveCode: Everyone can create apps
> >>
> >> ___
> >> 

Re: How to find offsets in Unicode Text fast

[Mark Waddingham via use-livecode]

On 2018-11-13 01:06, Geoff Canyon via use-livecode wrote:

On Mon, Nov 12, 2018 at 11:36 AM Ben Rubinstein via use-livecode <
use-livecode@lists.runrev.com> wrote:

I'm really confused that case-insensitive should work at all for 
UTF-16 or

UTF-32;


The caseSensitive (and formSensitive) properties only apply to strings 
*not* binary strings.


The output of textEncode() is a binary string.

The 'is' operator is overloaded - in strict order:

  left-empty 'is' right-ANY -- returns is-empty(right-ANY)
  left-ANY 'is' right-empty -- returns is-empty(left-ANY)
  left-array 'is' left-array -- compare as array
  left-number 'is' right-number -- compare as number
  left-numeric-[binary]-string 'is' right-numeric-[binary]-string -- 
compare as number
  left-binary-string 'is' right-binary-string -- compare as binary 
strings

  left-any 'is' right-any -- compare as strings

Also concatenation, put after and put before are overloaded:

   binary-string & binary-string -> binary-string
   string & ANY -> string
   ANY & string -> string

   put src-data after|before dst-data -> dst-data is binary-string
   put src-ANY after|before dst-ANY -> dst-ANY is string


This is so puzzling. I tried this code in a button:

on mouseUp
   put "Ѡ" into x
   put "ѡ" into y
   --put ("Ѡ" is "ѡ") && (x is y)
   --exit mouseUp
   put textencode("Ѡ","UTF-32") into xBig
   put textencode("ѡ","UTF-32") into xSmall
   repeat for each byte B in xBig
  put B after yBig
   end repeat
   repeat for each byte B in xSmall
  put B after ySmall
   end repeat
   put "Ѡ" into zBig
   put "ѡ" into zSmall
   put zBig into wBig
   put zSamll into wSmall
   put textencode(zBig,"UTF-32") into zBig
   put textencode(zSmall,"UTF-32") into zSmall
   put x into j
   put y into k
   set caseSensitive to false
   put ("Ѡ" is "ѡ") && (xBig is xSmall) && (yBig is ySmall) && (zBig is
zSmall) && (wBig is wSmall) && (x is y) && (j is k)
end mouseUp


That puts: true false false false true true true

Things to note:

1. "Ѡ" and "ѡ" are upper and lower case omega in cyrillic, 0460 and
0461. Given the string literals, LC is happy to say they are the 
same

(the first true)
2. Put them in a variable, LC is happy to say they are the same
(the second-to-last true).
3. Convert them to UTF-32 and LC no longer recognizes them as the same 
(the

fourth boolean, false)
4. Put the variables into other variables, and LC identifies them as 
the

same (the last true)


("Ѡ" is "ѡ") is true because they are both strings
(xBig is xSmall) is false because both sides are binary-strings (and so 
compare byte for byte)

(yBig is ySmall) is false because both sides are binary-strings
(zBig is zSmall) is false because you've textEncoded strings which 
produce binary-strings so both are binary strings

(wBig is wSmall) is true because both sides are strings
(x is y) is true because both sides are strings
(j is k) is true because both sides are strings

One could argue that 'is'/'is not' should never have been overloaded to 
do binary string comparison - and that should have perhaps been added as 
a separate operator (especially since binary strings are compared as 
numbers if numeric). With hindsight I'd probably agree as it is a slight 
discontinuity in terms of comparison with pre-7.


Indeed, had we not added that overload then we would not be having this 
discussion - it would have been a similar discussion as used to come up 
a lot with comparing the output of compress() and other functions which 
have always produced binary data - and why comparisons seemed 'not as 
one would expect'.


Warmest Regards,

Mark.

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

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

Re: What is LC's internal text format?

[Mark Waddingham via use-livecode]

On 2018-11-13 08:35, Geoff Canyon via use-livecode wrote:
So then why does put textEncode("a","UTF-32") into X;put chartonum(byte 
1

of X) put 97?


Because:

  1) textEncode("a", "UTF-32") produces the byte sequence <97,0,0,0>
  2) byte 1 of <97,0,0,0> is <97>
  3) charToNum(<97>) first converts the byte <97> into a native string 
which is "a" (as the 97 is the code for 'a' in the native encoding 
table), then converts that (native) char to a number -> 97



That implies that "byte" 1 is "a", not 111.


111 is 97 but printed in base-2.

FWIW, I think you are confusing 'binary string' with 'binary number' - 
these are not the same thing.


A 'binary string' (internally the data type is 'Data') is a sequence of 
bytes (just as a 'string' is a sequence of 
characters/codepoints/codeunits).


A 'binary number' is a number which has been rendered to a string with 
base-2.


Bytes are like characters (and codepoints, and codeunits) in that they 
are 'abstract' things - they aren't numbers, and have no direct 
conversion to them - which is why we have byteToNum, numToByte, 
nativeCharToNum, numToNativeChar, codepointToNum and numToCodepoint.


The charToNum and numToChar functions are actually deprecated / 
considered legacy - as their function (when useUnicode is set to true) 
depends on processing unicode text as binary data - which isn't how 
unicode works post-7 (indeed, there was no way to fold their behavior 
into the new model - hence the deprecation, and replacement with 
nativeCharToNum / numToNativeChar).


You'll notice that there is no modern 'charToNum'/'numToChar' - just 
'codepointToNum'/'numToCodepoint'. A codepoint is an index into the 
(large - 21-bit) Unicode code table; Unicode characters can be composed 
of multiple codepoints (e.g. [e,combining-acute] and thus don't have a 
'number' per-se.


Warmest Regards,

Mark.



I've looked in the dictionary and I don't see anything that comes close 
to

describing this.

gc

On Mon, Nov 12, 2018 at 10:21 PM Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:


On 2018-11-13 07:15, Geoff Canyon via use-livecode wrote:
> On Mon, Nov 12, 2018 at 3:50 PM Monte Goulding via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> Unless I'm misunderstanding, this hasn't been my observation. Using
> offset
> on a string that has been textEncodet()ed to UTF-32 returns values that
> are
> 4 * (the character offset - 1) + 1 -- if it were re-encoded, wouldn't
> it
> return the actual offsets (except when it fails)? Also, 
 encodes to
> 00010001, and routines that convert to UTF-32 and then use offset will
> find
> five instances of that character in the UTF-32 encoding because of
> improper
> boundaries. To see this, run this code:
>
> on mouseUp
>put textencode("
","UTF-32") into X
>put textencode("


","UTF-32") into Y
>put offset(X,Y,1)
> end mouseUp
>
> That will return 2, meaning that it found the encoding for X starting
> at
> character 2 + 1 = 3 of Y. In other words, it found X using the last
> half of
> the first "
" and the first half of the second "
"

The textEncode function generates binary data which is composed of
bytes. When you use binary data in a text function (which offset is),
the engine uses a compatability conversion which treats the sequence 
of

bytes as a sequence of native characters (this preserves what happened
pre-7.0 when strings were only ever native, and as such binary and
string were essentially the same thing).

So if you textEncode a 1 (native) character string as UTF-32, you will
get a four byte string, which will then turn back into a 4 (native)
character string when passed to offset.

Warmest Regards,

Mark.

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

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

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


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