Re: Two features I don't understand

[Richard Gaskin]

Monte Goulding wrote:
> On 31 Oct 2014, at 2:55 pm, Richard Gaskin wrote:
>
>> If RunRev needed this themselves, they've done a good
>> job of concealing why. :)  Copying styled text works
>> great with htmlText.
>
> Richard if you remember originally styledText supported
> a few things that htmlText didn't and people complained...

Rightly so, according to the inventor of the LiveCode engine:  Dr. Raney 
once explained to me that the purpose of htmlText is to provide an 
easily-manipulatable way to faithfully reproduce the entire contents and 
styles within a field or chunk.


Anything less is indeed a bug report. :)

I like the idea of using arrays to manipulate field contents, but alas 
we have so much missing from the the styledText representation at the 
moment.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for Desktop, Mobile, and Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Re: Two features I don't understand

[Monte Goulding]

On 31 Oct 2014, at 2:55 pm, Richard Gaskin  wrote:

> If RunRev needed this themselves, they've done a good job of concealing why. 
> :)  Copying styled text works great with htmlText.

Richard if you remember originally styledText supported a few things that 
htmlText didn't and people complained so they upgraded htmlText so I think the 
original plan was to introduce a way to work with the new field features and 
that may have become somewhat redundant after the update to htmlText. I think 
it also mirrors more closely the data structures used in the engine and 
therefore be a bit quicker to get and set.

Cheers

--
M E R Goulding 
Software development services
Bespoke application development for vertical markets

mergExt - There's an external for that!

___
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: Two features I don't understand

[Richard Gaskin]

Alex Tweedly wrote:

On 30/10/2014 18:36, Richard Gaskin wrote:

1. ID caching
Page 10 of the v6.0 Release Notes:


The description there says:

   The engine now caches lookups of control references of the form
   “card id ...” and “control id ...”.  This speeds up any access
   using those forms after the first time, turning an operation that
   would be completed in linear time into one that will be completed
   in constant time.

What does that mean in practical terms?  How can I benchmark the
benefit of this new feature?


H - I said this once before :-) :-)


My apologies for the inconvenience.  I'd either missed it before or 
completely forgot about it, but the latter seems unlikely given how 
remarkable the post was:



Yes, here's an example. The clue (I think) is in the "linear
time...into constant time"

Create a large-ish number of controls - in this stack I cloned a
button 1000 times, calling them
BBB1   BBB2  BBB1000

Then this code accesses a single control many times - and shows that
accessing by id is much faster than accessing by name, but more
importantly here, that in 6.0 access by id to the most recently
accessed control is very fast.

in 5.5.3
name takes 830 ms while id takes only 250 ms

but in 6.0 (i.e. with id caching)
name takes 830 ms while id takes 5 ms

-- Alex.



global K

on mouseUp
   put 1000 into K

   put the millisecs into t1
   put "BBB"&(K-10) into tName
   repeat 1 times
  put the short name of control tName  into t
   end repeat
   put the millisecs-t1 && t &CR after msg

   put the millisecs into t1
   put the id of button tName into tID
   repeat 1 times
  put the short name of control id tID  into t
   end repeat
   put the millisecs-t1 && t &CR after msg

end mouseUp


What I find most remarkable is the way your benchmark makes the value of 
this ID caching seem rather trivial.


I trust this was a one-liner, as I can't imagine them spending much time 
optimizing something so very specialized and which takes so little 
execution time per iteration.


I wonder what prompted this one...perhaps something specific to the 
coding style of the person who wrote the Project Browser?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for Desktop, Mobile, and Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Re: Two features I don't understand

[Richard Gaskin]

Michael Doub wrote:

> I use the styled arrays quite often when creating content, applying
> styles and taking advantage of the metadata.

Thanks.  I still don't understand how I might use it, but I'm glad 
someone's using it.


RunRev don't generally spend time on a feature unless there's either a 
lot of people asking for it or it's something they need themselves.


Since AFAIK no one's ever asked for this it seems an internal need, but 
the examples in the Dictionary are a bit weak, simply using it to copy 
formatted content but nothing more interesting than that.


If RunRev needed this themselves, they've done a good job of concealing 
why. :)  Copying styled text works great with htmlText.



> Rather than including char offsets for runs in the array itself,
> I think it might be more useful to have an easy way to get from
> a char offset to the pgh_number/run_number within the styled array.
> Another thing to look at in 7.0.

Yes, when I first heard about StyledText I had imagined it would have 
elements like that, which would make it much more interesting (or at 
least understandable) for me.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for Desktop, Mobile, and Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Re: Possible bug in LC6.7 - maybe one for Mark Schonewille?

[Richard Gaskin]

Peter Haworth wrote:
> Late to this one but there is indeed a new property named "status"
> which is why your script now fails.  Unfortunately, can't tell what
> it's used for since there's no dictionary entry for it.  About to
> file a bug report for that.

Please do - thanks.

Searching for "status" in the v7 Release Notes it seems that it's now a 
property of the new player widget.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for Desktop, Mobile, and Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

7.0 Bug

[Peter Haworth]

Getting the imagesource of a character that is immediately preceded by a
tab character returns empty even if the character has an imagesource set on
it.  QCC report number 13887.

Pretty obscure but it pretty much cripples lcStackBrowser when trying to
expand a line.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 
___
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

(Arbitrarily) Long-Division Script

[Igor de Oliveira Couto]

Hi all,

I wanted to develop a library to allow me to perform basic maths (add, 
subtract, multiply, divide) with arbitrarily long numbers in LiveCode. My 
requirements are simple: 

- integers and floating-point numbers must be supported as all operands in all 
operations, to an arbitrarily large number of decimal cases

- speed is NOT an issue: performances can safely be relatively slow, as it is 
unlikely that it’ll need to perform hundreds of thousands of operations per 
second

- accuracy IS an issue: needless to say, all operations must provide *accurate* 
and *reliable* results, regardless of how many decimal cases are used

It proved relatively easy to do the addition, multiplication and subtraction 
operations in LiveCode. I followed the ‘pen-and-paper’ algorithm, and it all 
seems to be working really well - I’m happy to provide anybody with a copy of 
the scripts off-list, if you wish (just send me an email directly). I’m stuck, 
however, trying to implement DIVISION. There does not seem to be an “easy” 
pen-and-paper algorithm that would support arbitrarily large numbers with 
unknown number of decimal cases. 

Most long-division algorithm seems to expect that the number being divided can 
be of an arbitrarily length, but they expect that the divisor (the number we 
are dividing BY) is going to be low enough, so that the person making the 
division will “know” instinctively how many times it would “fit” into the 
number being divided. These algorithms are not recommended once we start 
dealing with divisor of 3 digits or more. There does not seem to be an 
algorithm that would allow us to procede “digit-by-digit” with the division, as 
can be done with addition/subtraction/multiplication… Or is there?

Searching Google and Wikipedia has yielded articles about using bitwise 
operations, or complex mathematical theory, both of which are beyond me. Is 
there a Math Wiz in this list, who could give us a layman’s explantion of an 
algorithm that could be used? Any help would be much appreciated!

Kindest regards to all,

--
Igor Couto
Sydney, Australia

___
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: Possible bug in LC6.7 - maybe one for Mark Schonewille?

[Peter Haworth]

Hi Graham,
Late to this one but there is indeed a new property named "status" which is
why your script now fails.  Unfortunately, can't tell what it's used for
since there's no dictionary entry for it.  About to file a bug report for
that.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 

On Sat, Oct 25, 2014 at 6:26 AM, Graham Samuel  wrote:

> In a desktop app (Mac and Windows - currently testing the Mac version) I’m
> using a button (actually a group acting as a button) designed by Mark
> Schonewille which does nice things with shading. This has been working for
> a long time, ever since it was announced by Mark. Now in LC 6.7, I get a
> compile error in a setProp handler in the group (in fact in several groups
> with the same script). Part of a case statement looks like this
>
> …
> lock messages
>  set the status["disabled"] of me to not theBool
>  set the status["hilite"] of me to false
>  unlock messages
> …
>
> The IDE reports
>
> >  compiling at 2:58:22 PM
> > Type  Expression: bad factor
> > ObjectClearAllGroup
> > Line  set the status["disabled"] of me to not theBool
> > Hint  [
>
> There is no hint. As it would seem to be a syntax failure, maybe some new
> reserved word is getting in the way - but this is just a guess.
>
> I have not yet been able to isolate this to confirm and then report it as
> a bug. Mark, if you're around, do you understand what's happening? I quite
> understand if you haven't got time to look at it, but I thought I'd ask
> before trying to go deeper into the issue.
>
> TIA
>
>
>
> ___
> 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: Two features I don't understand

[Alex Tweedly]

On 30/10/2014 18:36, Richard Gaskin wrote:

1. ID caching
Page 10 of the v6.0 Release Notes:


The description there says:

   The engine now caches lookups of control references of the form
   “card id ...” and “control id ...”.  This speeds up any access
   using those forms after the first time, turning an operation that
   would be completed in linear time into one that will be completed
   in constant time.

What does that mean in practical terms?  How can I benchmark the 
benefit of this new feature?



H - I said this once before :-) :-)

If I could remember well enough how to find things on Nabble or Gmane, 
I'd just point to the original thread - but since I can't and am in a 
hurry - here's a message I sent to this list on 12/05/2013.






Yes, here's an example. The clue (I think) is in the "linear 
time...into constant time"


Create a large-ish number of controls - in this stack I cloned a 
button 1000 times, calling them

BBB1   BBB2  BBB1000

Then this code accesses a single control many times - and shows that 
accessing by id is much faster than accessing by name, but more 
importantly here, that in 6.0 access by id to the most recently 
accessed control is very fast.


in 5.5.3
name takes 830 ms while id takes only 250 ms

but in 6.0 (i.e. with id caching)
name takes 830 ms while id takes 5 ms

-- Alex.



global K

on mouseUp
   put 1000 into K

   put the millisecs into t1
   put "BBB"&(K-10) into tName
   repeat 1 times
  put the short name of control tName  into t
   end repeat
   put the millisecs-t1 && t &CR after msg

   put the millisecs into t1
   put the id of button tName into tID
   repeat 1 times
  put the short name of control id tID  into t
   end repeat
   put the millisecs-t1 && t &CR after msg

end mouseUp



On 11/05/2013 03:11, Richard Gaskin wrote:
The Release Notes for v6 include:

  ID caching (6.0 DP 2)
  New global property – allowDatagramBroadcasts (6.0 DP 2)
  A new global property allowDatagramBroadcasts has been added. This
  needs to be set to true before sending to a broadcast address
  (enables the per-socket flag for whether they are allowed).
  The engine now caches lookups of control references of the form
  “card id ...” and “control id ...”.
  This speeds up any access using those forms after the first time,
  turning an operation that would be completed in linear time into
  one that will be completed in constant time.


I'm not clear on the syntax, so I've been unable to benchmark the 
performance boost.


Anyone here have a sample of ID caching in action?

--
 Richard Gaskin
 Fourth World
 LiveCode training and consulting: http://www.fourthworld.com
 Webzine for LiveCode developers: http://www.LiveCodeJournal.com
 Follow me on Twitter: http://twitter.com/FourthWorldSys

___
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: Two features I don't understand

[Michael Doub]

I use the styled arrays quite often when creating content, applying styles and 
taking advantage of the metadata.  I can’t comment on the speed.

I have a tendency to think in terms of arrays so this is pretty comfortable for 
me.   

I did a lot of work using space above and below and was really bummed when 
pageranges did not take them into account.  (a bug report exists for this.)   I 
guess I should look and see if 7.0 addressed that issue.

Rather than including char offsets for runs in the array itself, I think it 
might be more useful to have an easy way to get from a char offset to the 
pgh_number/run_number within the styled array.   Another thing to look at in 
7.0.

-= Mike


On Oct 30, 2014, at 2:36 PM, Richard Gaskin  wrote:

> 1. ID caching
> Page 10 of the v6.0 Release Notes:
> 
> 
> The description there says:
> 
>   The engine now caches lookups of control references of the form
>   “card id ...” and “control id ...”.  This speeds up any access
>   using those forms after the first time, turning an operation that
>   would be completed in linear time into one that will be completed
>   in constant time.
> 
> What does that mean in practical terms?  How can I benchmark the benefit of 
> this new feature?
> 
> 
> 2. StyledText array
> Pages 16-18 of the v5.5.4 Release Notes:
> 
> 
> Anyone here use this?  Is it faster than doing equivalent operations on 
> htmlText?  While the style attributes themselves are well represented in the 
> array, the character offsets of runs don't seem to be present, so I'm unclear 
> as to what this should be used for.
> 
> 
> Any insight into either of these would be appreciated - TIA...
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: livecode versions what do the various suffix mean? DP/RC/GM

[Richard Gaskin]

Robert Mann wrote:

> Self explaining in title! Dummy question.. but.. can't find
> information easily in the live code account space.
>
> dp = ??
>
> rc = ??
>
> gm = ??
>
> thanks.. !

From the top of the Downloads page at 
:



 STABLE - These releases are stable public releases.

 RC - Short for "Release Candidate", these releases are
  feature complete and have been made public to allow
  LiveCode developers to test whether they think the
  release is stable. Users who find bugs can file them
  at http://quality.runrev.com.

 DP - Short for "Developer Preview", these releases are not
  feature complete and likely to contain bugs. They have
  been made public to allow LiveCode developers to
  experiment with the latest features and feedback to
  the team. Users who find bugs can file them at
  http://quality.runrev.com.


"GM" is an older designation for "Stable", harkening back to the days 
when software was shipped on CDs: it stands for "Golden Master", and 
back in the early days master builds were sent to the disk duplicator 
using especially high-quality media which had a golden color.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Two features I don't understand

[Richard Gaskin]

1. ID caching
Page 10 of the v6.0 Release Notes:


The description there says:

   The engine now caches lookups of control references of the form
   “card id ...” and “control id ...”.  This speeds up any access
   using those forms after the first time, turning an operation that
   would be completed in linear time into one that will be completed
   in constant time.

What does that mean in practical terms?  How can I benchmark the benefit 
of this new feature?



2. StyledText array
Pages 16-18 of the v5.5.4 Release Notes:


Anyone here use this?  Is it faster than doing equivalent operations on 
htmlText?  While the style attributes themselves are well represented in 
the array, the character offsets of runs don't seem to be present, so 
I'm unclear as to what this should be used for.



Any insight into either of these would be appreciated - TIA...

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Re: livecode versions what do the various suffix mean? DP/RC/GM

[Thomas von Fintel]

developer preview
release candidate
gold master

http://en.wikipedia.org/wiki/Software_release_life_cycle

Greetings
Thomas


Am 30.10.2014 um 18:56 schrieb Robert Mann:

> Self explaining in title! Dummy question.. but.. can't find information
> easily in the live code account space.
> 
> dp = ??
> 
> rc = ??
> 
> gm = ??
> 
> thanks.. !
> 
> 
> 
> --
> View this message in context: 
> http://runtime-revolution.278305.n4.nabble.com/livecode-versions-what-do-the-various-suffix-mean-DP-RC-GM-tp4685199.html
> Sent from the Revolution - User mailing list archive at Nabble.com.
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

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

Re: livecode versions what do the various suffix mean? DP/RC/GM

[Colin Holgate]

I think DP would be Developer Preview. RC is Release Candidate, GM is Gold 
Master.


> On Oct 30, 2014, at 1:56 PM, Robert Mann  wrote:
> 
> Self explaining in title! Dummy question.. but.. can't find information
> easily in the live code account space.
> 
> dp = ??
> 
> rc = ??
> 
> gm = ??
> 
> thanks.. !
> 
> 
> 
> --
> View this message in context: 
> http://runtime-revolution.278305.n4.nabble.com/livecode-versions-what-do-the-various-suffix-mean-DP-RC-GM-tp4685199.html
> Sent from the Revolution - User mailing list archive at Nabble.com.
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

livecode versions what do the various suffix mean? DP/RC/GM

[Robert Mann]

Self explaining in title! Dummy question.. but.. can't find information
easily in the live code account space.

dp = ??

rc = ??

gm = ??

thanks.. !



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/livecode-versions-what-do-the-various-suffix-mean-DP-RC-GM-tp4685199.html
Sent from the Revolution - User mailing list archive at Nabble.com.

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

Re: Valentina db

[Mark Talluto]

On Oct 30, 2014, at 12:42 AM, la...@significantplanet.org wrote:

> Hello,
> 
> Has anyone used Valentina database with LC?
> 
> If so, what is your experience with it?
> 
> Is it a product that a newbie (me) could reasonably learn how to use with LC?
> 
> Thanks for any info,
> Larry
> 
> P.S. If you have a recommendation for a database that is REALLY easy to use 
> with LC, please let me know.


Hi Larry,

At Canela Software, we have developed a database just for LiveCode.  We use it 
in all of our applications that need databases.  We have designed it to be very 
easy to use.  We call it CassiaDB.  Local storage is free to use as you like, 
forever.

You can give it a try through our LiveCloud website:  livecloud.io
You will find full documentation, code examples, and working programs written 
in LiveCode using CassiaDB for data storage.

If you have any questions, please feel free to contact us directly. We are here 
to help.

 
Best regards,

Mark Talluto
livecloud.io
canelasoftware.com

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

Re: QT replacement on Windows?

[Martin Koob]

>From the roadmap http://livecode.com/community/roadmap/ the cross platform
player object will be made possible by the new widget framework.  My
understanding is that now that LiveCode 7 and 6.7 are released work can now
start on widgets as part of the next version of LiveCode.  

Martin



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/QT-replacement-on-Windows-tp4685192p4685197.html
Sent from the Revolution - User mailing list archive at Nabble.com.

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

Re: Benchmarking 7.0 performance

[Tim Selander]

Thanks, Kay!

Rinaldi's plug in has "saved" me with the saving problem -- it 
also seems a little slow on the saves, but does it in the 
background with no visible impact/slowdown while using the stack 
as it saves. Good enough for our needs.


I hear you on the merits of SQLite. But my main goal for this 
project is to move an in house customer tracking system from 
Hypercard over to LC, giving my office users as close to the same 
experience they have on HC now, AND with as little time spent on 
my part. We're too small to have an IT guy per se... so the IT 
guy is me. I wouldn't bother moving the system, but we're running 
out of OS9 compatible printers for invoices, receipts, mailing 
labels, etc.  Our needs are very simple. Which is good, because 
I'm a video production guy, not a programmer!


I have done quite a bit of experimenting with MySQL and have 
"successfully" implemented a CRUD system that gets Japanese data 
on and off the MySQL server. I like tinkering on this kind of 
thing in my spare time. But I haven't been able to figure out how 
to generate the right SQL query with a script, based on simple 
form or picklist input. On the other hand, I made a simple search 
interface very similar to Filemaker's (fill in what you want on a 
search form that looks like an empty record) and was able to 
script that to get just the right "mark card where..." in one 
evening. And LC is fast enough that no matter how complicated a 
search I throw at it -- 'Get me all customers in Tokyo or 
Yokohama that have bought X and Y, and whose first order was last 
year or this year' -- and present it as a datagrid or a subset of 
cards all within 3 or 4 seconds. Plenty fast enough for my users.


I have some ideas of some things I'd like to try in the future 
with SQL... but not anytime in the immediate future.


Thanks for your coaching on this!

Tim

P.S. REALLY enjoying the seamless unicode in v7!





On 10/30/14, 6:34 PM, Kay C Lan wrote:

Sorry, hit the Send button accidentally before finding the link.

NOT CSV*

* For reasons as to why you wouldn't use a comma to separate your values,
please refer to this excellent article by Richard Gaskin:

http://www.fourthworld.com/embassy/articles/csv-must-die.html

Unfortunately, using 1 Card + Flat File means you have to code all the
search, filter and sort capabilities that you get free if you use SQLite.
Depending on your data and the likely searches that will be carried out,
this may not be a trivial matter and may take just as much time to
implement as learning how to use SQLite with LC.

If you want to hone your LC skill set then 1 Card + Flat file would be the
way to go.

If your looking to expand your horizons, then learning how to implement
SQLite into LC will definitely open more doors for use in more projects
down the road.

HTH
___
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: Encoding videos for Android

[Mark Schonewille]

What kind of custom control would that be, David? I'm currently having 
the same problem.


--
Best regards,

Mark Schonewille

Economy-x-Talk Consulting and Software Engineering
Homepage: http://economy-x-talk.com
Twitter: http://twitter.com/xtalkprogrammer
KvK: 50277553

Installer Maker for LiveCode:
http://qery.us/468

Buy my new book "Programming LiveCode for the Real Beginner" 
http://qery.us/3fi


LiveCode on Facebook:
https://www.facebook.com/groups/runrev/

On 3/29/2013 10:10, David Bovill wrote:

By the way the issue appears to be that "play someVideoFile" does not work
on Android - at least my set up (I only get sound no image). Using a custom
control to play the video works fine with both video formats.

On 1 March 2013 17:03, David Bovill  wrote:


I've tried 2 videos so far for playback on Android (Nexus 7). Both played
but without showing a picture - that is the sound played. The first was an
.m4v file which I did not expect to play, and then I tried converting it to
a .webm file - this only played the sound as well. The webm file played
fine using Chrome or Firefox.

Any thoughts on how to best encode videos? I'll be testing some other
files - but some tips could save time :)



___
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

AW: Unicode: LC 7.0 - PHP - MySQL?

[Tiemo Hollmann TB]

Thanks Peter

> -Ursprüngliche Nachricht-
> Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im
Auftrag
> von Peter W A Wood
> Gesendet: Donnerstag, 30. Oktober 2014 13:11
> An: How to use LiveCode
> Betreff: Re: Unicode: LC 7.0 - PHP - MySQL?
> 
> Hello Tiemo
> 
> > On 30 Oct 2014, at 16:30, Tiemo Hollmann TB  wrote:
> >
> > Hello Peter,
> > thank you for taking your time for your helpful explanations. I still
> > have two issues left.
> > I found in the SQL export of my db that it is UTF-8 encoded. So
> > perhaps the definition of a collation "ascii_general_ci" defines a
"subset"
> of UTF-8?
> 
> True ASCII (the first 128 characters which includes A-Z and a-z but not é,
ü,
> etc) is a genuine subset of UTF-8. From a quick web search, it seems the
_ci
> refers to case insensitive collation so that "A" and "a" are treated the
same.
> 
> > As far as I understand it now, I should pass all LC strings with
> > uniEncode(string,UTF8) to the PHP because of the UTF-8 of MySQL.
> > Probably I will fiddle around with uniEncode/uniDecode at the
> > interface to the PHPs and see with which encode parameter the correct
string
> gets into the MySQL db.
> >
> > On the other side I am importing data from a Valentina-DB. Where I
> > have to set the Encoding to Macintosh / Latin, depending on the
> > platform. Does this platform related conversion gets obsolete with LC
> > 7 UniCode, or is this still valid, because of data coming from
> > outside, though Valentina probably also is Unicode.
> 
> From their website, it seems that Valentina uses the same 'C library' as
> LiveCode (LibICU) and stores text UTF-16 encoded. In theory, you shouldn't
> need to convert text passing between the two but it may be different in
> practice.
> 
> Hope this helps.
> 
> Peter
> 
> 
> ___
> 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: Unicode: LC 7.0 - PHP - MySQL?

[Peter W A Wood]

Hello Tiemo

> On 30 Oct 2014, at 16:30, Tiemo Hollmann TB  wrote:
> 
> Hello Peter,
> thank you for taking your time for your helpful explanations. I still have
> two issues left.
> I found in the SQL export of my db that it is UTF-8 encoded. So perhaps the
> definition of a collation "ascii_general_ci" defines a "subset" of UTF-8?

True ASCII (the first 128 characters which includes A-Z and a-z but not é, ü, 
etc) is a genuine subset of UTF-8. From a quick web search, it seems the _ci 
refers to case insensitive collation so that "A" and "a" are treated the same.

> As far as I understand it now, I should pass all LC strings with
> uniEncode(string,UTF8) to the PHP because of the UTF-8 of MySQL. Probably I
> will fiddle around with uniEncode/uniDecode at the interface to the PHPs and
> see with which encode parameter the correct string gets into the MySQL db. 
> 
> On the other side I am importing data from a Valentina-DB. Where I have to
> set the Encoding to Macintosh / Latin, depending on the platform. Does this
> platform related conversion gets obsolete with LC 7 UniCode, or is this
> still valid, because of data coming from outside, though Valentina probably
> also is Unicode.

>From their website, it seems that Valentina uses the same 'C library' as 
>LiveCode (LibICU) and stores text UTF-16 encoded. In theory, you shouldn't 
>need to convert text passing between the two but it may be different in 
>practice.

Hope this helps.

Peter  


___
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

QT replacement on Windows?

[Tiemo Hollmann TB]

Hello,

now that runrev replaced Quicktime by AVFoundation on Mac, I am curious
about a solution for windows.

One of the extendet targets of the crowdfunding was replacing QT (not only
on Mac). But I don't hear anything anymore about this roadmap issue.

Probably it was easier to replace on Mac, but I think a replacement on
Windows is much more urgent. Quicktime is officially not any more supported
since Windows 7 (or even Vista). Since 5 years I have constant trouble with
customers because of "failed" QT installations. The QT installation itself
doesn't fails, but LC doesn't recognize QT as being installed or produces
rubbish when playing videos or taking screenshots of a video. Because the
issues happen in my program, my customers complain me and my LC program even
though QT is the reason, but that isn't of interest for them. Only the
result counts. Since 5 years I constantly have to tell customers to
reinstall QT, sometimes up to 5 times, until finally the old QT API is found
by LC. At least 11 FAQs on my support site care about Quicktime failures.
This really is a pain.

Has anybody heard anything what has happened to this roadmap issue?

Tiemo

 

 

 

___
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: Valentina db

[larry]

Thanks very much Kay and Tiemo!

- Original Message - 
From: "Kay C Lan" 

To: "How to use LiveCode" 
Sent: Thursday, October 30, 2014 2:33 AM
Subject: Re: Valentina db



On Thu, Oct 30, 2014 at 3:42 PM,  wrote:


Hello,

Has anyone used Valentina database with LC?

Yes, for many years now.




If so, what is your experience with it?

Love it. Especially if you need speed and simplified table 
relationships -

Binary Links are great.



Is it a product that a newbie (me) could reasonably learn how to use with
LC?

Probably not at your stage.


I am a hobbyist. I was moderately competent with HC when I moved to
Revolution which is now LC. Because of LC db capabilities I then played
with MySQL and SQLite with some success, but again I was fluent with LC at
the time. In the search for more speed I went to Valentina. Having some
knowledge of SQL and pretty fluent with LC made the move to Valentina less
bumpy.

Noting your many bumps along the path of LC enlightenment I'm not sure
getting tangled with Valentina right now would be painless. I note 
frequent

posts on the Valentina Users List about people who get stuck installing
Valentina for LC. It's a simple 2 step process, but as most people's
experience with installers is that it does absolutely everything for them,
they regular seem to miss the need for the 2nd step.

I do recommend you download Valentina Studio, it's free - I'll explain
later.

http://www.valentina-db.com/en/all-downloads



P.S. If you have a recommendation for a database that is REALLY easy to
use with LC, please let me know.

Whether you are just interested in trying out LC's database capabilities,

or have a real need to do something with a database, unless you definitely
need something fed from a web server you can't go wrong with SQLite. It's
already installed on your computer (it is for OS X and I'm pretty sure it
is the same for Win and Linux) so there is ZERO installation process to go
through. It's free and will always be free - unlike MySQL which has a
pretty convoluted licensing structure which most people can't understand
and so you'll often see a suggestion to 'contact MySQL, give them your 
case

and see what they say'.

You can download the free Valentina Studio which allows you to build, view
and test SQLite dbs. Makes it really easy with LC (or any other 
programming
environment) to test SQL statements outside of LC to determine is it the 
LC

code that is wrong or the SQL statement. There are also plenty of online
tutorials for SQLite so you can play with Valentina Studio + SQLite first,
make sure you've got the basics of dbs organised and working before taking
the next step and seeing if you can get LC to talk to the db you've 
created.


Unless you have very large data sets it is unlikely that you'll notice any
real speed difference. Yes, you might be able to prove that Valentina is a
couple of ms faster, but to the user it all happens within the blink of an
eye. Even then, if you do have huge data sets, you can do all your 
learning
and testing with SQLite, once you feel you know what you are doing, you 
can

download a trial version of Valentina, export all the data out of SQLite
and import it into a Valentina db, create your own 'realistic' benchmark
test and see the difference for yourself. You'll then know exactly what 
you

are getting for your money.

There are many LC + SQLite users on this List, and a couple of gurus, so 
if

you run into trouble help is not far away.

HTH
___
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: Benchmarking 7.0 performance

[Kay C Lan]

Sorry, hit the Send button accidentally before finding the link.

NOT CSV*

* For reasons as to why you wouldn't use a comma to separate your values,
please refer to this excellent article by Richard Gaskin:

http://www.fourthworld.com/embassy/articles/csv-must-die.html

Unfortunately, using 1 Card + Flat File means you have to code all the
search, filter and sort capabilities that you get free if you use SQLite.
Depending on your data and the likely searches that will be carried out,
this may not be a trivial matter and may take just as much time to
implement as learning how to use SQLite with LC.

If you want to hone your LC skill set then 1 Card + Flat file would be the
way to go.

If your looking to expand your horizons, then learning how to implement
SQLite into LC will definitely open more doors for use in more projects
down the road.

HTH
___
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: Benchmarking 7.0 performance

[Kay C Lan]

So you are saying that there is NO difference between 6.5 and 7.0, both
take 10-12 sec to save your file.

Are you still looking for a way to speed that up?

If so the short answer is you need to move all those records to an SQLite
database. 1 card + 1 SQLite DB and guaranteed any changes you make will be
saved in less than the blink of an eye.

Of course, learning how to work with SQLite, transfer all that data and
modify your stack will take somewhat longer; but thankfully LC is a rapid
development environment so you can feel good about the fact that it'll take
less time than any other language ;-)

If the thought of learning SQLite seems daunting then working with a NOT
CSV* flat file would also yield noticeable speed increases.



On Wed, Oct 29, 2014 at 9:27 PM, Tim Selander 
wrote:

> Hi Kay,
>
> Good question! Wait a moment
>
> OK, I'm back. Under 6.5 it also takes about 12 seconds.
>
> It is a data stack in the old HC sense, not SQL or even CSV. It is about
> 11,000 cards, each containing the customer's address & other info. !0.2MB
> total file size.
>
> I am pleased with how fast it is working for me other than saves. And now
> Rinaldi has come to my rescue again. I have use a LOT of his stuff over all
> these years.
>
> Tim Selander
> Tokyo, Japan
>
>
>
> On 10/29/14, 1:57 PM, Kay C Lan wrote:
>
>> On Tue, Oct 28, 2014 at 8:28 PM, Tim Selander 
>> wrote:
>>
>>  saving changes to the file takes a full 10 seconds or more.
>>>
>>>  How long does it take in LC 6.x ?
>>
>> When you say 'measly 10MB file - customer database. Are you saying the
>> file
>> is a db file like mySQL or SQLite, or is it just a flat file that you use
>> to store tab/comma separated values?
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

AW: Valentina db

[Tiemo Hollmann TB]

Hi Larry,

I am using Valentina locally without server, that’s not too hard. But I
think it depends on your needs of number of users, client/server,
performance, etc. SQLite probably is even easier and it is free. The reason
for me going with Valentina was, that I needed to protect the data of my
local db and as far as I know, I can't do that with SQLite.
Tiemo

> -Ursprüngliche Nachricht-
> Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im
Auftrag
> von la...@significantplanet.org
> Gesendet: Donnerstag, 30. Oktober 2014 08:42
> An: use-livecode@lists.runrev.com
> Betreff: Valentina db
> 
> Hello,
> 
> Has anyone used Valentina database with LC?
> 
> If so, what is your experience with it?
> 
> Is it a product that a newbie (me) could reasonably learn how to use with
LC?
> 
> Thanks for any info,
> Larry
> 
> P.S. If you have a recommendation for a database that is REALLY easy to
use
> with LC, please let me know.
> ___
> 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: Valentina db

[Kay C Lan]

On Thu, Oct 30, 2014 at 3:42 PM,  wrote:

> Hello,
>
> Has anyone used Valentina database with LC?
>
> Yes, for many years now.


> If so, what is your experience with it?
>
> Love it. Especially if you need speed and simplified table relationships -
Binary Links are great.


> Is it a product that a newbie (me) could reasonably learn how to use with
> LC?
>
> Probably not at your stage.

I am a hobbyist. I was moderately competent with HC when I moved to
Revolution which is now LC. Because of LC db capabilities I then played
with MySQL and SQLite with some success, but again I was fluent with LC at
the time. In the search for more speed I went to Valentina. Having some
knowledge of SQL and pretty fluent with LC made the move to Valentina less
bumpy.

Noting your many bumps along the path of LC enlightenment I'm not sure
getting tangled with Valentina right now would be painless. I note frequent
posts on the Valentina Users List about people who get stuck installing
Valentina for LC. It's a simple 2 step process, but as most people's
experience with installers is that it does absolutely everything for them,
they regular seem to miss the need for the 2nd step.

I do recommend you download Valentina Studio, it's free - I'll explain
later.

http://www.valentina-db.com/en/all-downloads


> P.S. If you have a recommendation for a database that is REALLY easy to
> use with LC, please let me know.
>
> Whether you are just interested in trying out LC's database capabilities,
or have a real need to do something with a database, unless you definitely
need something fed from a web server you can't go wrong with SQLite. It's
already installed on your computer (it is for OS X and I'm pretty sure it
is the same for Win and Linux) so there is ZERO installation process to go
through. It's free and will always be free - unlike MySQL which has a
pretty convoluted licensing structure which most people can't understand
and so you'll often see a suggestion to 'contact MySQL, give them your case
and see what they say'.

You can download the free Valentina Studio which allows you to build, view
and test SQLite dbs. Makes it really easy with LC (or any other programming
environment) to test SQL statements outside of LC to determine is it the LC
code that is wrong or the SQL statement. There are also plenty of online
tutorials for SQLite so you can play with Valentina Studio + SQLite first,
make sure you've got the basics of dbs organised and working before taking
the next step and seeing if you can get LC to talk to the db you've created.

Unless you have very large data sets it is unlikely that you'll notice any
real speed difference. Yes, you might be able to prove that Valentina is a
couple of ms faster, but to the user it all happens within the blink of an
eye. Even then, if you do have huge data sets, you can do all your learning
and testing with SQLite, once you feel you know what you are doing, you can
download a trial version of Valentina, export all the data out of SQLite
and import it into a Valentina db, create your own 'realistic' benchmark
test and see the difference for yourself. You'll then know exactly what you
are getting for your money.

There are many LC + SQLite users on this List, and a couple of gurus, so if
you run into trouble help is not far away.

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

AW: Unicode: LC 7.0 - PHP - MySQL?

[Tiemo Hollmann TB]

Hello Peter,
thank you for taking your time for your helpful explanations. I still have
two issues left.
I found in the SQL export of my db that it is UTF-8 encoded. So perhaps the
definition of a collation "ascii_general_ci" defines a "subset" of UTF-8?

As far as I understand it now, I should pass all LC strings with
uniEncode(string,UTF8) to the PHP because of the UTF-8 of MySQL. Probably I
will fiddle around with uniEncode/uniDecode at the interface to the PHPs and
see with which encode parameter the correct string gets into the MySQL db. 

On the other side I am importing data from a Valentina-DB. Where I have to
set the Encoding to Macintosh / Latin, depending on the platform. Does this
platform related conversion gets obsolete with LC 7 UniCode, or is this
still valid, because of data coming from outside, though Valentina probably
also is Unicode.

Thanks for coaching
Tiemo







> -Ursprüngliche Nachricht-
> Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im
Auftrag
> von Peter W A Wood
> Gesendet: Donnerstag, 30. Oktober 2014 08:30
> An: How to use LiveCode
> Betreff: Re: Unicode: LC 7.0 - PHP - MySQL?
> 
> Hello Tiemo
> 
> I'm not sure that I have all the answers you are looking for but I hope
this
> will help a little. It is a simplification though to try and make things
> understandable.
> 
> > On 30 Oct 2014, at 00:11, Tiemo Hollmann TB  wrote:
> >
> > Hello,
> >
> > I have a LC 6 program communicating through PHP with a MySQL db.
> > Because my background about Unicode, PHP and MySQL is limited I wonder
> > what I have to care about, when migrating to LC 7.
> >
> > I have read the release notes of LC 7. My limited thinking was, that
> > UniCode really has a unique code for each sign on the planet. But why
> > is there a
> > UTF-8 / UTF-16.
> 
> Yes, UniCode does have a unique code for (almost) every sign on the
planet.
> The unique codes are known as codepoints. There are so many of them that
the
> numbers allocated to them exceed the maximum size of one "character" (or
even
> two). They do all fit into 4 characters though. UTF-8 is a way of storing
the
> Unicode codepoints in single (8-bit) "characters". It may take one, two or
> three of them to store a Unicode codepoint. UTF-16 is a way of storing
Unicode
> codepoints in double (16-bit) "characters". The vast majority of Unicode
> codepoints fit into a single "double character", some take two.
> 
> 
> > Which one is LC using?
> 
> Internally LiveCode uses UTF-16.
> 
> > Which one is my MySQL db using?
> 
> I suspect that MySQL normally uses UTF-8, I'm sure one of the database
experts
> can correct me if I am wrong. However, what is most important is which
> encoding system was used to create the data in the first place.
> 
> > Idon't find any information about UTF-8/16 in my db description. How
> > is the collation of the db related to UTF-x and to LC?. My tables are
> > collated in ascii_general_ci. In some of my PHPs a "COLLATE
> latin1_swedish_ci" is used.
> > I have no idea why this Swedish collation is in my german PHP and how
> > it can be compatible with my ascii_general_ci DB. (The PHPs are made
> > by third
> > party)
> 
> This suggests that your PHP scripts are expecting the data they received
to be
> have "encoded" in a specific system, either "ascii_general_ci" or
> "latin1_swedish_ci". They are different from Unicode.
> 
> >
> > What do I have to change in my LC program when migrating to 7. Where
> > to start?
> 
> As best as I understand, you will need to use textDecode to convert any
> external text (ie from PHP or MySQL) to LiveCode text. You will need to
use
> textEncode to convert any LiveCode text to send to any external source.
> 
> > Is LCs Unicode really the magic thing, where I don't have to care
> > about any charset related thing and all my thinking is just waste?
> 
> Internally, it really is magic (from my point of view). Sadly the
magicians in
> Edinburgh have yet to come up with a spell that magically converts
somebody
> else's data to LiveCode Text (UTF16). They need a little help from us
users to
> tell them how the external text is encoded. (That has always been the case
> when combining differently encoded text data since LiveCode 1).
> 
> Regards
> 
> Peter
> 
> 
> ___
> 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

Valentina db

[larry]

Hello,

Has anyone used Valentina database with LC?

If so, what is your experience with it?

Is it a product that a newbie (me) could reasonably learn how to use with LC?

Thanks for any info,
Larry

P.S. If you have a recommendation for a database that is REALLY easy to use 
with LC, please let me know.
___
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: Unicode: LC 7.0 - PHP - MySQL?

[Peter W A Wood]

Hello Tiemo

I'm not sure that I have all the answers you are looking for but I hope this 
will help a little. It is a simplification though to try and make things 
understandable.

> On 30 Oct 2014, at 00:11, Tiemo Hollmann TB  wrote:
> 
> Hello,
> 
> I have a LC 6 program communicating through PHP with a MySQL db. Because my
> background about Unicode, PHP and MySQL is limited I wonder what I have to
> care about, when migrating to LC 7.
> 
> I have read the release notes of LC 7. My limited thinking was, that UniCode
> really has a unique code for each sign on the planet. But why is there a
> UTF-8 / UTF-16.

Yes, UniCode does have a unique code for (almost) every sign on the planet. The 
unique codes are known as codepoints. There are so many of them that the 
numbers allocated to them exceed the maximum size of one "character" (or even 
two). They do all fit into 4 characters though. UTF-8 is a way of storing the 
Unicode codepoints in single (8-bit) "characters". It may take one, two or 
three of them to store a Unicode codepoint. UTF-16 is a way of storing Unicode 
codepoints in double (16-bit) "characters". The vast majority of Unicode 
codepoints fit into a single "double character", some take two.


> Which one is LC using?

Internally LiveCode uses UTF-16.

> Which one is my MySQL db using?

I suspect that MySQL normally uses UTF-8, I'm sure one of the database experts 
can correct me if I am wrong. However, what is most important is which encoding 
system was used to create the data in the first place.

> Idon't find any information about UTF-8/16 in my db description. How is the
> collation of the db related to UTF-x and to LC?. My tables are collated in
> ascii_general_ci. In some of my PHPs a "COLLATE latin1_swedish_ci" is used.
> I have no idea why this Swedish collation is in my german PHP and how it can
> be compatible with my ascii_general_ci DB. (The PHPs are made by third
> party)

This suggests that your PHP scripts are expecting the data they received to be 
have "encoded" in a specific system, either "ascii_general_ci" or 
"latin1_swedish_ci". They are different from Unicode.

> 
> What do I have to change in my LC program when migrating to 7. Where to
> start? 

As best as I understand, you will need to use textDecode to convert any 
external text (ie from PHP or MySQL) to LiveCode text. You will need to use 
textEncode to convert any LiveCode text to send to any external source.

> Is LCs Unicode really the magic thing, where I don't have to care about any
> charset related thing and all my thinking is just waste?

Internally, it really is magic (from my point of view). Sadly the magicians in 
Edinburgh have yet to come up with a spell that magically converts somebody 
else's data to LiveCode Text (UTF16). They need a little help from us users to 
tell them how the external text is encoded. (That has always been the case when 
combining differently encoded text data since LiveCode 1).

Regards

Peter


___
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