Re: Difference between "html" and "htmlText" in clipboardData?

[Mark Waddingham via use-livecode]

On 2017-02-02 01:46, Richard Gaskin via use-livecode wrote:
The Dictionary entry for clipboardData lists these among the array 
keys:


- htmlText: LiveCode HTML text
- html: styled text in LiveCode HTML format


That dictionary entry could do with a little refinement :)

What is the difference between "LiveCode HTML text" and "LiveCode HTML 
format"?


Nothing - they are the same format in that context (the clipboardData). 
However,
you should use 'htmlText' and 'rtfText' in preference to 'html' and 
'rtf' as they

are the new names.

If there is no difference and they're both LC's htmlText, why two key 
names?


The difference comes about when you use 'the fullClipboardData'.

The fullClipboardData gives you access both to the engine's synthesized 
data

formats and the original data that was placed on the clipboard.

In this context:

  - rtfText: LiveCode's rtfText format
  - htmlText: LiveCode's htmlText format
  - styledText: LiveCode's (array-based) styledText format
  - html: Only present if the data on the clipboard is actually HTML
  - rtf: Only present if the data on the clipboard is actually RTF

This is explained in more detail in the fullClipboardData entry.

I'd generally recommend not using 'the clipboardData' for new apps, and 
using
'the fullClipboardData' instead. It allows you to put multiple distinct 
data
types on the clipboard, and does not use any 'legacy' rules to determine 
what
keys appear ('the clipboardData' only allows a single actual datatype, 
so uses

priority rules to determine which you see).

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: AW: Different result in LC 6 to LC 8 when copying field text into Excel?

[Mark Waddingham via use-livecode]

They are platform-specific - the 'original' win32 ones are here:



It looks like Tiemo has discovered a bug in the docs!

Warmest Regards,

Mark.

Sent from my iPhone

> On 8 Feb 2017, at 16:17, Richard Gaskin via use-livecode 
>  wrote:
> 
> Tiemo Hollmann wrote:
> 
> > I tested a little bit more and this code works for me:
> > on mouseUp
> >lock clipboard
> >set the rawClipBoardData to empty
> >set the rawClipboardData["CF_UNICODETEXT"] to textEncode(fld 1, "UTF-16" 
> > )
> >unlock clipboard
> > end mouseUp
> >
> > and the IDE doesn't crashes anymore.
> > BTW. The rawclipboarddata key is supposed to be ["CF_UNICODETEXT"]
> > and not ["CF_UNICODE"] as the docs say.
> 
> I wonder if the difference in keys is because the keys of the 
> rawClipboardData are platform-specific.
> 
> After reading Mark Waddingham's note here last week on a related subject:
> http://lists.runrev.com/pipermail/use-livecode/2017-February/234491.html
> 
> ...I've come to regard the fullClipboardData as my go-to first choice for 
> manipulating Clipboard contents, resorting to rawClipboardData only when I 
> need some platform-specific special handling I can't address with 
> fullClipboardData.
> 
> -- 
> 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: Windows and OSX 64-bit builds?

[Mark Waddingham via use-livecode]

On 2017-02-10 03:38, Tom Glod via use-livecode wrote:
I will... if u wanna replicate...put an image on a stack..make it 32k x 
32k
.and try and do a export snapshot of the image,  LC goes POOF... 
Trevor
said tha last version of 8 (8.13)  had some memory issues solves, so i 
will

try to test is there too.


Currently, the engine implements 'export snapshot' by allocating a 
raster (32-bits per pixel) of the size of the snapshot you are making, 
rendering into it and then compressing it.


So really the maximum size you could hope to snapshot is 16k x* 16k 
pixels as that requires 2Gb - the engine in general uses signed integer 
indicies, so the maximum memory buffer it can manipulate is 2Gb bytes. A 
32-bit process would probably struggle to do that (due to only having 
around 2-3Gb of user address space to use) - as there is overhead in 
rasterization and then compression; but a 64-bit process should be fine.


There is a bug here as (at least in this specific case) the engine 
should fail gracefully (as we know there is a hard limit in the size of 
an image the engine can process).


As you correctly point out 32k x 32k comes in at 1Gb pixels - which at 
24-bit RGB comes out at 4Gb of data. No 'normal' 32-bit application 
which isn't explicitly designed for manipulating huge images will be 
able to deal with something that size. I would expect applications such 
as Photoshop to be able to deal with them though since I believe their 
native raw storage format for images pages from disk as required (so you 
never have the 'whole thing' in memory at once - just the bit you are 
looking at / editing).


One important thing to remember is that the amount of memory required to 
take a snapshot is (SOMECONSTANT * 4 * the number of pixels) in the rect 
of the snapshot (I've not checked but I would estimate 0 < SOMECONSTANT 
< 2) which means that you can get LiveCode to generate very large 
images, but you have to break the problem down by splitting up the 
snapshot into bands and probably use an external (command-line) tool to 
compress the image into your format of choice (how big an image such a 
tool can process, again, will be dependent on whether it needs to load 
the entire image into memory to compress it or not).


Rough idea:

repeat with i = 0 to pHeight / kBandSize

  import snapshot from rect (0, pWidth, i * kBandSize, kBandSize)

  write the imageData of the last image to file tOutputFile

  delete the last image

   end repeat

After this you will have a very large file with the raw xRGB data in it, 
so you need to find a tool which can take raw 32-bit xRGB data (with 
specified order of the RGB), the width and height and process it into 
jpg or png or whatever format you require (I'm hoping others who know 
more about such things might be able to chime in here - ImageMagick has 
an arsenal of command-line tools, for example).


Warmest Regards,

Mark.

P.S. There is a hard limit of co-ordinate magnitude in LC and thus the 
size of any object - 32767 pixels on any side of anything.


--
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: Why do I still need MacToISO, when working with UTF-8?

[Mark Waddingham via use-livecode]

Hi Tiemo,

On 2017-01-16 11:57, Tiemo Hollmann TB via use-livecode wrote:
Now my German Umlaute don't get corrupted in the MySQL db and 
everything is

fine, but I would like to understand the technical background. Why do I
still need MacToISO() in LC 8 on a Mac and even worse, I didn't needed 
it in

LC 6 in the same program. What am I missing here?


Can you explain (with code examples if possible) what you are calling 
MacToIso() on, and how you are using its output?


It isn't entirely clear exactly what steps you are taking in your 
previous email and it sounds like the problem is at the point of LC's 
communication with PHP, rather than within LC.


Thanks in advance!

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: AW: AW: Why do I still need MacToISO, when working with UTF-8?

[Mark Waddingham via use-livecode]

Hi Tiemo,


thank you for taking your time and clarifying. I wasn't aware that the
internal format on a Mac client is MacRoman. I thought it would be a
"neutral" UTF-8 format.


Internally, the engine uses either MacRoman/ISO-Latin1 *or* UTF-16 
depending on platform and what the string contains.


However, the 'endpoints' (i.e. where the developer can 'see' encoded 
text output - e.g. when writing to a file, or encoding for a URL) had to 
remain as before otherwise all existing applications using anything 
other than ASCII text would have broken when moving from 6.7 -> 7.0.


You can use the 'utf8' keyword to open utf-8 encoded files; however, you 
have to deal with urlEncode manually (which isn't necessarily a bad 
thing, since your server scripts determines what the URL Encoded bytes 
mean after the '?' - NOT LiveCode).


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: Why do I still need MacToISO, when working with UTF-8?

[Mark Waddingham via use-livecode]

Hi Matthias,

On 2017-01-16 18:25, Matthias Rebbe via use-livecode wrote:

It would have been nice if you had also put some sample code for how
to UTF8 encode the string.
That would have made your explanations complete. ;)


Sure - here is how I'd slightly adjust Tiemo's code:

*put fld "name" into myName*
-- ...
*open file myFile for binary write*
*write textEncode(myName, "utf8") to file myFile*
*close file myFile*
-- ...
*open file myFile for binary read*
*read from file myFile until EOF*
*close file myFile*
*put textDecode(it, "utf8") into myName*
-- ...
*put URL ("http://myUser:myPW@myURL; & "mySQL.php?" & 
URLEncode(textEncode(theName, "utf8")))

into rslt*
-- mySQL.php writes to a MySQL db, where theName column is encoded as
"utf8_general_ci"

The missing piece here is PHP configuration on the other side. I'm 
assuming that PHP is doing the following:

   1) URLDecode the part after '?' into bytes
   2) Interpret the bytes as Latin-1 encoded text
   3) Passing the text string to the appropriate MySQL function
   4) The MySQL function is converting the text string to UTF-8

This may or may not be the case. If 'theName' is encoded as UTF8 before 
being URLEncode, all that needs to be checked is that the PHP (on the 
other end) is decoding it into a string as UTF-8 before passing it to 
MySQL.


Warmest egards,

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: Why do I still need MacToISO, when working with UTF-8?

[Mark Waddingham via use-livecode]

Am 16.01.2017 um 18:30 schrieb Mark Waddingham via use-livecode 
<use-livecode@lists.runrev.com 
<mailto:use-livecode@lists.runrev.com>>:



Sure - here is how I'd slightly adjust Tiemo's code:

*put fld "name" into myName*
-- ...
*open file myFile for binary write*
*write textEncode(myName, "utf8") to file myFile*
*close file myFile*
-- ...
*open file myFile for binary read*
*read from file myFile until EOF*
*close file myFile*
*put textDecode(it, "utf8") into myName*


I always thought, that binary reading a text file would result into a
string with the same encoding and  line endings.


When you read a file in binary mode, what you get is binary data *not* 
text - i.e. it is just a sequence of bytes. The engine cannot tell by 
just looking at the bytes what it could be therefore you have to 
explicitly convert it to something - in this case we convert the 
sequence of bytes to text by interpreting the bytes as UTF-8.


One of the biggest changes from 6 to 7 is that binary strings and text 
strings are no longer the same thing.


Prior to 7, the engine didn't really 'know' anything about Unicode - the 
field did to a certain degree, but nothing else - and it assumed that 
binary strings and text strings were the same thing. Indeed, on Mac the 
engine would assume that a binary string could be treated as a MacRoman 
encoded string (as MacRoman is one byte, one char); and on Windows/Linux 
it would assume that a binary string could be treated as a Latin-1 
encoded string (also a one byte, one char encoding).


This equivalence has been retained in 7 from 6 - which is why stacks 
written in 6 work exactly the same as they do in 7. Specifically, there 
is an implicit auto conversion between binary strings and text strings 
using the platform encoding:


put  into tVar
put "foobar" after tVar

In the second line here, the engine will first convert tVar to a text 
string (assuming MacRoman encoding on Mac) then append "foobar".


So when i binary read UTF8 files  i still have to textDecode it to 
UTF8?


Yes - because if you read something as binary, then it is just that - 
binary - it has no structure and is just a sequence of bytes.


A perhaps more obviously example is that you have to explicitly 
decompress data which has been compress'd and explicitly arrayDecode 
data which has been arrayEncode'd. When it is just data, the engine 
doesn't know what it could be so the code processing it has to 
explicitly specify a conversion.


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: AW: Why do I still need MacToISO, when working with UTF-8?

[Mark Waddingham via use-livecode]

Hi Tiemo,

Okay so, I'm assuming that all this code is running on the Mac client...


*put fld "name" into myName*


At this point myName contains a (text) string - thus encoding issues 
don't exist (you should think of text strings in memory as being stored 
in an 'encoding neutral' format).



*open file myFile for binary write*
*write myName to file myFile*
*close file myFile*


This piece of code will open a file on disk in the native encoding of 
the platform - so MacRoman. It will convert this from the internal 
encoding to MacRoman on writing. Thus your text file will be a MacRoman 
encoded text file.



*open file myFile for binary read*
*read from file myFile until EOF*
*close file myFile*
*put it into myName*


This piece of code will read from a file on disk and assume that it is 
in the native encoding of the platform - so, in this case, MacRoman. It 
will convert the content of the file from that to the internal encoding.


Up to this point - because you saved and loaded the file on the same 
platform the content of myName should be as you expect -- unchanged.



*if the platform is "MacOS" then put macToISO(theName) into theName*


When run on Mac this line will execute and do the following:

   1) Convert theName to a binary string - this uses the native platform 
encoding (MacRoman)
   2) Map each byte from the MacRoman code index to the ISO Latin-1 code 
index


This essentially converts theName from a text string to a binary string 
encoded in Latin-1.


*put URL ("http://myUser:myPW@myURL; & "mySQL.php?" & 
URLEncode(theName))

into rslt*


This line constructs the URL - it is making the assumption that PHP (at 
the other end) will interpret the bytes after the '?' as representing 
Latin-1 encoded text.


Without macToISO on a Mac client theName enters corrupted in the mySQL 
db


This is most likely because PHP is defaulting to 8859-1 or Latin-1 as 
the encoding used in URLEncoded fields in a URL. If you don't do 
MacToIso, then you will be passing up MacRoman encoded text (URLencoded) 
to PHP, which can happily be decoded as Latin-1 or 8859-1 (Latin-1 is a 
superset of 8859-1), but with some chars (such as accented letters) in 
different places.


What you need to do here is explicitly UTF8 encode theName before 
passing it to URLEncode, then explicitly decode it as UTF8 on the PHP 
side (or set a property in PHP which changes the default assumption 
about URLs - I apologise for not being more accurate here, my knowledge 
of PHP is a little stale these days!).


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: Changes to use-livecode list.

[Mark Waddingham via use-livecode]

On 2017-01-06 13:55, Heather Laine via use-livecode wrote:

Well. That's the problem you see. DMARC rejects mail on the basis that
it does not come from the same address as the sender ie the posting
person's email is not the list address. Reversing this change will
reinstate that issue. There is no good solution here, which is why I'm
wondering if the list is reaching end of life. Either a proportion of
list users get persistently bounced, creating bounce problems for
other list users in the process, or we live with this style of from
address. And as yet, I do not know if this has really solved the
problem, we'll need to wait a few weeks and see.


This is a pretty useful blog post about the subject, for anyone 
interested. It doesn't sound like any 'perfect' solution is going to 
appear anytime soon...




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: Codesigning issue with revxml.bundle in LC 8

[Mark Waddingham via use-livecode]

Hi Tiemo,

On MacOS Sierra I am just trying to codesign a new version with LC 
8.1.2 of

an old program, which I have codesigned successfully in the past.

I do the codesigning manually via terminal like: codesign -s
"myCertificateName" --deep --force myApp

Today I get the error "resource forke, Finder information, or similar
detritus not allowed In subcomponent: revxml.bundle" What does it want 
me to

do?


I think this is this problem:



Try doing:

  xattr -cr myApp

Before running codesign and see if it works. This command should clear 
out any extended attributes on all files in your app bundle.


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: rawKeyUp/Down give different keys for same char since LC 8

[Mark Waddingham via use-livecode]

Hi Tiemo,

On 2017-03-21 17:40, Tiemo Hollmann TB via use-livecode wrote:
Testing on Win 10, IDE: up to LC 6.7 special chars, as German Umlaute 
gave

the same key in rawKeyUp and rawKeyDown, e.g.

ä = 39, ü = 59, ö = 96, ß = 91

in LC 8 and 9 the rawKeyUp are still the same, but in rawKeyDown I now 
get:


ä = 228, ü = 252, ö = 246, ß = 223

Is there any plausible explanation or reason why this had to be 
changed, or

is this a bug?


This looks like a bug to me - the key codes in rawKeyDown and rawKeyUp 
should match

and be the code of the key, not the translated character.

Out of interest, what are you using the rawKey messages for?

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: differences between text/imagedata of image in LC6/8 (EDIT)

[Mark Waddingham via use-livecode]

On 2017-03-24 11:58, Mark Waddingham via use-livecode wrote:

What works in LC8/9 is

2.   set the text of img 2 to the text of img 1

and

3.   put img 1 into img 2


Both of these do the same thing - (3) is short hand for (1).


I mean (3) is short-hand for (2) here!

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: differences between text/imagedata of image in LC6/8

[Mark Waddingham via use-livecode]

Hi Tiemo,

in an old program I obviously tried to be very technically over correct 
when

copying an image and did:

1.   set the imagedata of img 2 to the imagedata of img 1

This worked up to LC 6.7. In LC8/9 I get a corrupted image (black and
stripes) in the target image.


The imageData of an image is the extracted color values for the pixels 
in the
image. Specifically, it is a sequence of bytes with each pixel 
represented as
xRGB. These are the bytes which are applied to the screen when the image 
is
rendered and does not include any alpha data (which is specified using 
the
alphaData property). To set the imageData you need to set the width and 
height

of the field first.


What works in LC8/9 is

2.   set the text of img 2 to the text of img 1

and

3.   put img 1 into img 2


Both of these do the same thing - (3) is short hand for (1).

The 'text' of an image is the original image data from a format such as 
PNG, GIF etc.

i.e. the content of a PNG file or GIF file.

What is the correct syntax today? Is solution 2 and 3 the same and just 
an
alias (what it seems to me) or are there differences in details I do 
not

see?


In general, (2) or (3) is better than (1) as (1) is considered an 'image 
editing'
operation and as such will cause a recompression of the data in some 
fashion. Also
(2) and (3) will automatically set the size, and alpha channel of the 
image appropriately.


And is there any explanation why the upward compatibility of solution 1 
is

broken?


If there is a difference here then it is a bug - although please do 
check that the width/height of the image is the same, and also transfer 
across alphaData too.


I'd recommend using (2) or (3) - or, indeed, using referenced files 
instead. The engine
will automatically cache referenced images and share the underlying 
decompressed data.

i.e.

   set the filename of image 1 to "foo"
   set the filename of image 2 to "foo"

Will first resolve "foo" as an absolute path, load that image file into 
a cache if not
already present and attach the decompressed image data to the image 
object. Then, when
the second image's filename is set, it will find the image is already in 
the cache and

just use the decompressed image data attached to that file in the cache.
i.e. The two images share the same pixel data in memory.

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: LiveCode's handling of Unicode glyphs being dependent on the underlying OS

[Mark Waddingham via use-livecode]

On 2017-03-27 14:39, Mark Waddingham via use-livecode wrote:

In regards to your specific requirements, I had a thought on that last
night. I think essentially what you want is a way to treat a sequence
of codepoints in a field as a sequence of glyph indicies into the
current font. So rather than treating the 0x1CF7 codepoint as a
character, it would just be treated as a number to index into the
glyph table of the (inherited) font set on its style. This could be
done as a textStyle, although that would give you no control over
positioning, the only thing it could do there is use the advance width
/ baseline in the glyph to position it sequentially.


I realized that you don't actually need this at all - the PUA can be 
used to do precisely this.


As I'm sure you realize, a font has a 'cmap' table which maps codepoints 
to glyphs and this is can be a many->one mapping - i.e. you can have 
more than one codepoint mapping to the same glyph. So what you could do 
is:


  1) Map all the unicode defined codepoints to their appropriate glyphs 
(noting that use of these codepoints will cause the standard rules to be 
applied when typesetting strings).


  2) Map all the glyphs you want access to a block in the PUA (noting 
that these codepoints will have no extra processing)


You can then use PUA codepoints to get 'just the glyphs', or the normal 
codepoints if you want the standard behavior.


In the future you could look into adding OpenType tables (GPOS, GDEF and 
GSUB in particular) to your font - these allow the font to define things 
like complex kerning, ligatures (where two characters combine into one 
glyph), accents (where single character is composed of a base glyph and 
an accent attached to it) and all kinds of other things without the 
software using it having to know anything about the gory details.


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: LiveCode's handling of Unicode glyphs being dependent on the underlying OS

[Mark Waddingham via use-livecode]

On 2017-03-28 10:30, Richmond via use-livecode wrote:

In 1996 I bought a copy of Fontographer, having previously developed
several bitmap fonts
for Macintosh with Fontastic (for Anglo-Saxon and Old Slavic). At that
time (1996) it was possible
to use Fontographer to make fonts with about 4000 characters which one
could access through Mac Keyboard layouts. As far as I know, although
Unicode development started in 1986, there was
no question of Unicode compatibility (and I had not heard of Unicode).

Presumably (?) ALL that Macintosh system 7.5 was doing when it
displayed characters outwith the ASCII set was what I need now?


Not necessarily - I believe system 7.5 was pretty advanced when it came 
to text and fonts. In particular, I'm sure it had an implementation of 
TrueType at least. The only difference then was that a font might have 
multiple CMAP tables for different text encodings as the Unicode 
encoding was still in its infancy. Even bitmap fonts (which might not 
necessarily have been TrueType) would have to declare what encoding it 
assumed was being used so that things could be mapped appropriately.


In actual fact, fonts don't really care about encoding exactly - they 
provide tables which map indexes in an encoding to the glyphs to 
represent them. Everything inside the font runs on glyph indexes and not 
codepoints in any encoding. Indeed (as I mentioned in another email) you 
can use the PUA area for your font as a direct codepoint->glyph map.



I'm glad you find it unusable: I have a G5 iMac (connects to the
Internet using TenFourFox) running
dual-boot 10.4 and 10.5 that is stuffed with lots of PPC software that
I bought when I had more money for that sort of thing than I have now:
I would be lost without the availability of Appleworks and
Bryce.


I'd point out that TenFourFox is a fork of FireFox and is not a Mozilla 
project.


i.e. A third-party has taken the responsibility for maintaining a fork 
of an open-source project to ensure there is a variant of FireFox which 
runs on older systems...


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: LiveCode's handling of Unicode glyphs being dependent on the underlying OS

[Mark Waddingham via use-livecode]

On 2017-03-26 17:48, Richmond Mathewson via use-livecode wrote:

Interestingly enough this FREE program for Macintosh:

https://www.macupdate.com/app/mac/9752/unicodechecker

Very successfully displays glyphs I have built into my Devawriter.ttf
font in comformance
with the Unicode version 10 Beta specification.

This all on my supposedly outmoded system 10.7.5 plastic box.


Just an update here - my 10.11 box does happily display all three 
characters as needed in LiveCode and other apps. When I initially 
installed the devawriter font which was supplied, it must not have 
installed it properly (I think I might have had an old version 
installed). After removing 'Devawriter' completely (using Font Book) and 
then reinstalling (by double clicking the latest version) - I get all 
codepoints appearing as expected.


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: LiveCode's handling of Unicode glyphs being dependent on the underlying OS

[Mark Waddingham via use-livecode]

On 2017-03-29 22:26, Sannyasin Brahmanathaswami via use-livecode wrote:

One anomaly that appears to be generated by LC 9dp5 running on Sierra
10.12.3: Code point U803 maps in the Unicode standard to the Extended
Latin "H with dot underneath" character.


Just to check, I take it you mean 'h' followed by U803 (the latter is 
'combining underdot' so needs a preceding char to make sense).



for some bizarre reason, on my machine/system,  Livecode is mapping
this character to Lucida (I think… possibly Helvetica.)
So this is an issue with the LC engine…


Indeed, that is odd - and does put Richmond's initial issue slightly 
more under the spotlight particularly as I'm now looking at the issue on 
a 10.6 machine (still haven't had time to upgrade it...)


What I observe (in 8.1 - it happened to be the LiveCode version I had 
opened) is this:


Field's textFont set to Devawriter.

Field containing: 'h' U+803

Displays h-with-underdot glyph - not using Devawriter font.

Field containing: 'h' U+803 ' '

Displays h-with-underdot glyph - uses Devawriter font.

Revisiting the original problem with the 1CF5, 1CF6 and 1CF7 codepoints:

1CF5 on its own - square glyph
1CF5 ' ' - square glyph, then space
1CF5 'a' - VEDIC SIGN JIHVAMULIYA, square glyph

Similar story for 1CF6.

The 1CF7 codepoint always displays the 'undefined codepoint' glyph from 
the last resort font.


Using TextEdit then as long as Devawriter is set as the explicit font, 
1CF5 and 1CF6 seem happy enough to display regardless of chars before or 
after. 1CF7 does the same thing as LiveCode.


*However*, trying h,underdot in TextEdit I observe a worse behavior than 
in LiveCode - the h,underdot never displays in Devawriter font 
regardless of subsequent chars!


So:

  1) The behavior of 1CF7 seems to be because it is an 'unassigned' 
codepoint at this time - I'm not quite sure the exact rationale behind 
not just using the specified font's CMAP table to generate a glyph 
regardless but I suspect it might be to do with unassigned codepoints 
being yet to have any properties which would affect how they are 
processed.


  2) The behavior in LiveCode with regard 1CF5 and 1CF6 looks a lot like 
the behavior with [h,underdot] - where a trailing character is needed to 
make the original character appear in the appropriate font.


I'm pretty sure that (1) is an OS issue and not something we could 
necessarily do much about - it seems to be replacing it with the 
undefined codepoint early on in the rendering process (at the OS level, 
not the engine).


However, (2) does look like it could be an engine issue - indeed, it 
feels like an 'off-by-one' error somewhere in the processing of the runs 
of characters which eventually get passed to CoreText.


That being said, there is different behavior in general between TextEdit 
and LiveCode - which reminds me that I *think* Apple had not yet 
replumbed the text support in Cocoa to use CoreText in 10.6 - that 
happened in a later OS. So, in 10.6 TextEdit is most likely using 
entirely separate Text APIs from LiveCode...


Anyway, I'll take a closer look and see if I can find where the problem 
might be.


Warmest Regards,

Mark.

P.S. In terms of 1CF7 - it still looks like you might have to use a PUA 
char for it to have it work on Mac until it becomes widely supported :(


--
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: LiveCode's handling of Unicode glyphs being dependent on the underlying OS

[Mark Waddingham via use-livecode]

On 2017-03-28 13:20, Richmond via use-livecode wrote:
I'd point out that TenFourFox is a fork of FireFox and is not a 
Mozilla project.


Is that a point that anyone who is prepared to go on running a PPC Mac 
should

be worried about?


They probably won't be - until the project ceases to be because a lack 
of support / input / people to use it...


What I was more trying to indicate was that whilst we (LiveCode) will 
not be directly supporting older operating systems, there is no reason 
why a similar community-led project could not exist for LiveCode to 
bring it back to older systems. Admittedly, this is not an easy project 
(if it was then the evaluation of whether we could continue to support 
them ourselves would potentially have turned out differently) but it is, 
at least, possible.



My original point was that I feel the word "unusable" is a way too
strong way of saying "not
up-to-date in the least".


Hehe - perhaps it was a little strong and I perhaps should have made it 
more specific. So "Unusable" if you need to interact with a lot of 
modern web-services and such through a fully compliant browser (i.e. 
general day-to-day use, instead of specific cases).


I'm NOT going to make Amazon purchases with my Debit card on my G3 
iMac!


Or indeed, let any information-which-needs-to-be-encrypted flow over the 
internet connection. To be fair, browsers tend to be somewhat unique in 
that they typically use their own entire network stack - relying only on 
the OS's bare sockets. So, a project like ForTenFour will likely be as 
secure as using a browser on any other more recent operating system. 
However, any app which uses system services will likely be a potential 
problem.


However, agin, this matters not one whit if the machine is not using / 
connecting to the internet or only doing so through applications which 
are known to be safe.



I have a friend who drives a 1980 Lada: it's great because as its
incredibly "primitive" not having
any on board computers anything that goes wrong can generally be
sorted out with a spanner,
a soldering iron and a few vulgar words.


Sounds a bit like computers from the 1980's too! (The spanner usually 
being used to hit the case, rather than actually spanner anything ;))


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: LiveCode's handling of Unicode glyphs being dependent on the underlying OS

[Mark Waddingham via use-livecode]

On 2017-03-27 13:56, Richmond via use-livecode wrote:

"UnicodeChecker is being developed using the Objective-C programming
language with the standard macOS developer tools, i.e. Xcode and the
Cocoa frameworks. The display of Unicode characters uses the default
system facilities of macOS. So there is no special handling of newer
Unicode characters: While Mac OS X 10.7.5 does not support the latest
Unicode versions when it comes to the character properties (such as
„General Category“, „Combining Class“, etc.) it will happily just
display any character that is present in a font, even if the character
was not actually defined in the very specific version of Unicode that
this version of Mac OS X supports."


Well, yes - it is just displaying the glyph completely out of context.


Now what is interesting is that LC 8.1.3 on Mac OS 10.7.5 will NOT
display characters simply as
characters, but tries to be too clever for its own good.


No - it is not being too clever. It is doing precisely what it should 
for the purposes of laying out text (and indeed what the CoreText engine 
on MacOS does - as that is what the engine uses). Pretty much everyone 
writing apps does not want to care about the (very complex) details of 
turning text into positioned glyphs, they just want a text string to be 
rendered how 'you would' expect, with regard to the codified rules which 
have been developed over a large number of years for typesetting 
language into a printed representation. Moreover, generally people want 
that done in a way which is 100% consistent with all other apps on the 
same OS (which is why using system services for such things is so 
important - Windows, for example, has a lot of behaviors built-in for 
dealing with CJK fonts which date back 1-2 decades, if an app doesn't 
support those then it won't operate in the same fashion).



As I am the developer of a program that does "all the knitting"
internally all I really would like is exactly
what this chap describes above. The fact that LiveCode seems to be
doing some of "the knitting" off
its own bat and/or leveraging OS "knitting" is what is causing me 
problems.


Quite - you have a special-case - you don't want to layout text, you 
(probably) just want to render glyphs which you specify.



I have already run the latest builds of my Devawriter on Mac OS 10.12
and Ubuntu 16.04
without these problems.  However I have several clients who run their
Macs on Mac OS 10.6.


Well, it is unlikely that anything will change with regards 10.6 with 
regards LiveCode. 8.1.x will be the last branch which will support 
anything less than 10.9.


To be fair, 10.6 is pretty much now a completely dead operating system 
for anything other than offline use. Critically, it does not and will 
never support some new SSL related transport modes, nor does it get 
Certificate Store updates. Basically, as time goes by the number of 
things a 10.6 machine will happily connect to *safely and securely* 
'over the internet' will diminish to probably zero. (I know this from 
experience - my laptop is still on 10.6 for various reasons and is just 
about unusable now as it can't be used to connect a variety of online 
services anymore - updating it to 10.11 or 10.12 is on my todo list).


In regards to your specific requirements, I had a thought on that last 
night. I think essentially what you want is a way to treat a sequence of 
codepoints in a field as a sequence of glyph indicies into the current 
font. So rather than treating the 0x1CF7 codepoint as a character, it 
would just be treated as a number to index into the glyph table of the 
(inherited) font set on its style. This could be done as a textStyle, 
although that would give you no control over positioning, the only thing 
it could do there is use the advance width / baseline in the glyph to 
position it sequentially.


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: could you please make a quick test for me?

[Mark Waddingham via use-livecode]

On 2017-03-31 10:28, Tiemo Hollmann TB via use-livecode wrote:

Thank you for your help


Mine is forthcoming - btw, I suggest anyone doing this makes sure they 
only send the results to Tiemo privately - unless you want all your Mac 
addresses in a public forum :)


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

[Mark Waddingham via use-livecode]

On 2017-03-31 12:12, Richmond via use-livecode wrote:

So, if I do something like this:

*put the codePointToNum("§")*

I will get the Unicode address of that character as a Decimal number.

How can I get it as a Hex number?


Two options - you can use baseConvert:

  put baseConvert(10, 16, codepointToNum("§")

or you can use format:

  put format("%x", codepointToNum("§"))

The latter is much more flexible e.g.:

  put format("\\u{%06x}", codepointToNum("§"))

Gives the codepoint as the escape sequence for JSON strings (for 
example).


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: OMG WTF detailed files BST?

[Mark Waddingham via use-livecode]

Hi Ben,

This might be of interest:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms724290(v=vs.85).aspx

On 2017-03-31 12:48, Ben Rubinstein via use-livecode wrote:

The standalone, built from LC 6.7.11, is running on a Windows machine
(VM running Windows Server 2008 R2) in London, which has a volume
mounted from a server running an unknown operating system.


What is the filesystem of the volume? The above document suggests that 
FAT stores
filetimes in local time and *not* universal time which sounds like it 
might be the problem...


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: OMG WTF detailed files BST?

[Mark Waddingham via use-livecode]

On 2017-03-31 13:20, Mark Waddingham via use-livecode wrote:

Hi Ben,

This might be of interest:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms724290(v=vs.85).aspx

On 2017-03-31 12:48, Ben Rubinstein via use-livecode wrote:

The standalone, built from LC 6.7.11, is running on a Windows machine
(VM running Windows Server 2008 R2) in London, which has a volume
mounted from a server running an unknown operating system.


What is the filesystem of the volume? The above document suggests that
FAT stores
filetimes in local time and *not* universal time which sounds like it
might be the problem...


I just re-read the pertinent paragraph:

The FAT file system records times on disk in local time. GetFileTime 
retrieves cached UTC times from the FAT file system. When it becomes 
daylight saving time, the time retrieved by GetFileTime is off an hour, 
because the cache is not updated. When you restart the computer, the 
cached time that GetFileTime retrieves is correct. FindFirstFile 
retrieves the local time from the FAT file system and converts it to UTC 
by using the current settings for the time zone and daylight saving 
time. Therefore, if it is daylight saving time, FindFirstFile takes 
daylight saving time into account, even if the file time you are 
converting is in standard time.


Sounds like a restart is needed to ensure that the APIs the engine has 
to use are correct...


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: Linux 32bit?

[Mark Waddingham via use-livecode]

Hi Phil,

On 2017-03-18 20:39, Phil Thane via use-livecode wrote:

OK, I'm back. When I follow the links I end up here:

https://livecode.org/download-after-sign-up/

There is only one button 'Download LiveCode Community'. I assume it 
then
probes my hardware and comes up with the wrong result because the 
download is:


'LiveCodeCommunityInstaller-8_1_3-Linux.x64'


Yes - indeed - that would be a bug. I've filed a report about it here:

   http://quality.livecode.com/show_bug.cgi?id=19454

So, hopefully we will get it corrected soon.

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: OMG WTF detailed files BST?

[Mark Waddingham via use-livecode]

On 2017-03-31 19:23, Local (BenR) wrote:

Hi Mark,

Thanks for your response, very helpful.

Unfortunately I don't know what the filesystem of the volume with the
files is - this is a client's network, and they set up a VM in the DMZ
for me to work on, with this network share mounted - but I've no idea
what the fileserver is.


Hmmm - I suspect something to do with the fileserver is at play here.

LiveCode uses FindFirstFileW and similar Win32 APIs to fetch the 
detailed file
into. Beyond converting the raw 'filetime' value which you get to 
'seconds
since 1970' (UTC) which is just (essentially) done by adding a constant 
offset

it doesn't do anything suspect with such values.

I can't explain why Explorer shows the correct values unless:

  1) It 'knows' about some sort of DST drift problem and has hard-coded 
handling of it


  2) It is using a different API to LiveCode to get the same info

Of course (2) requires there being a different file system API one could 
use, but to
my knowledge all Win32 FS operations are implemented in terms of the 
family we are

using.

Therefore, some more precise details of the setup your app is running on 
is probably
the best thing to try and get now - i.e. the details of the network 
share and how

it is configured in the VM.

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: Gradients with transparency?

[Mark Waddingham via use-livecode]

On 2017-04-03 11:37, Terry Judd via use-livecode wrote:

Is it possible to have a gradient with one of its end-points being
transparent instead of a solid colour?


Yes the color values you specify for gradients can have an alpha 
component. For example:


  0.5,255,0,0 -> at half way through the gradient, the color should be 
solid red


  0.5,255,0,0,127 -> at half way through the gradient, the color should 
be 50% transparent red.


Hope this helps!

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: Is there a technical difference between a RC and stable release?

[Mark Waddingham via use-livecode]

Hi Tiemo,

On 2017-04-05 08:25, Tiemo Hollmann TB via use-livecode wrote:
What I actually don't know, is there any "technical" difference behind 
the
scenes between a RC and a stable release? Is a RC just an approval 
state for
any feedback from us and could go 1:1 into a stable release, if there 
are no
serious new bugs? In other words, if I test my app with a RC and don't 
see
any bugs, which affect my app, would it be the same for me to use a RC 
for
an indy production, as a stable release or is there any technical 
difference

behind the scenes or reason for not to use a RC?


A stable release is 'just' a renaming of the last RC of any sequence of 
releases
for a given version - however, an RC might contain a regression 
(introduced in
the RC) in which case there will be another RC either fixing the 
regression

or reverting the patch which caused the regression.

In maintenance releases we try quite hard to minimize the impact of any
change which is made, so the general risk of regressions during an RC 
cycle

should be quite low.

So, in general, if a build of your app with an RC goes through your 
usual

testing procedures fine; then there should be no harm in using it in a
production release.

Indeed, people using RCs in production is actually very helpful for us 
as

it increases general test coverage, increasing the chance of finding any
regressions (which actually affect production code) in it.

Hope this helps,

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: Private Repo Services

[Mark Waddingham via use-livecode]

On 2017-04-03 13:44, Mike Kerner via use-livecode wrote:
Github is nice, but all your repos have to be public in order to be 
free.
I went looking for private ones (because there are things you just 
can't do

without a remote repo, and I don't want all my code in the open)

So far I've found two:
1) Github - $7/month
2) Google - free, but it's more complicated to get set up, and they 
have
quotas.  I have had no trouble getting an increase, but I'm sure there 
are

limits to their generosity

Does anyone know of others?


Atlassian Bitbucket is free (as far as I can tell!) for small teams - I 
don't know if there are any usage limits, but it certainly seems more 
than sufficient for my personal use.


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: Line numbers for soft-wrapped styled text?

[Mark Waddingham via use-livecode]

On 2017-03-29 12:48, hh via use-livecode wrote:

Alex,
before you waste valuable time:
The formattedRect can NOT be used in LC 7/8/9, because of the
(2^15 div 2)-limit for coordinates is active for that.


I couldn't find a bug report for that so I filed one:

http://quality.livecode.com/show_bug.cgi?id=19515

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: Cheesed off by 32xxx

[Mark Waddingham via use-livecode]

On 2017-04-02 19:07, Richmond Mathewson via use-livecode wrote:

The problem, such as it is, is that the Unicode specifications have
128 * 8703 slots for glyphs (= a big number my mind cannot cope with)
and the display in my "CHAR REF" stack is set up to cope with 128
glyphs a go: hence 8703 buttons.

Of course I could be racist and leave out the Chinese ideograph slots
(= about 70%) . . .


You'd probably be okay with 8703 buttons (were there not a co-ordinate 
magnitude limit), but certainly not with 128*8703 buttons.


To give some context...

Each button takes up at least 128 bytes in memory, so:

  8703 buttons is about 1.4Mb - which isn't too bad

  8703*128 buttons would be about 150Mb - which is substantially more

Admittedly, neither of these will 'break the bank' in terms of memory 
availability, even on machines of a G3 Mac vintage, however just storing 
the representation of such things in memory is not the only issue. The 
engine has to do things like:


  - render all the controls on the card

  - perform hit testing when the user clicks or interacts with the card

  - search for controls when you reference them in script

Rendering requires a linear back to front scan of each control, painting 
each one which is within the visible rect of the window the card sits 
in. This means that if you have 8703*128 buttons it will need to perform 
that many steps to render. Additionally, whenever a small amount 
changes, it needs to do this again - as any one control *could* have 
been moved or intersect with the area which has changed (and thus 
require rendering).


Hit testing is similar, although the process is from front to back, and 
stops as soon as a control says it is the target of the mouse / user 
interaction event.


The third case, is the killer though. Looking up a control by name or by 
later requires (on average) number of controls on card / 2 steps to 
perform. If you use the (short) id, then there is a per-stack cache 
which makes the lookup take 1 step if it has been looked up before but 
the normal number of steps if it has not.


In general, we'd never advise using so many controls on a single card - 
and a data-oriented approach which is what others have suggested is 
generally the best approach in this case. i.e. Update the content of a 
small set of buttons as the user browses through the list.



I wonder if that limit is "cast in stone" or the Livecode people could
expand it?


Currently engine controls are limited to 16-bit quantities for 
co-ordinates - which means a range of -32768 to 32768. The underlying 
rendering library we use (libgraphics), however, uses floats (32-bit 
real numbers which given an integer range up to around 2^24). So, 
updating the engine to use floats or similar in its co-ordinates for 
controls is certainly possible, just not a task we've undertaken yet.


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

[Mark Waddingham via use-livecode]

On 2017-04-05 16:30, Alex Tweedly via use-livecode wrote:

The dictionary says

There is a sample stack for revBrowser at the following location in 
the


LiveCode folder: Resources/Examples/Browser Samper.rev. This stack

demonstrates, with many examples, how to use browser objects in an

application.


Anyone know where it can be found ?


It is inside the app bundle on Mac - Contents/Tools/Resources/... - on 
windows it will be in Program Files in the LiveCode folder. There 
probably is somewhere in the IDE that links to it, but I can't remember 
where off the top of my head...


Any reason for revBrowser over the browser widget? ;)

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

[Mark Waddingham via use-livecode]

On 2017-04-05 17:53, Alex Tweedly via use-livecode wrote:
Well, I looked in the dictionary for "browser" and that's what I found 
:-)


The widgets come under different sections in the left hand drop-down at 
the moment unfortunately...



OK - so now I see there's a choice which should I use ?
Is there a similar sample or lesson covering the browser widget ?


That is a good question - I shall check...

However, one of the reasons for needed a revBrowser sample stack was 
that you have to setup and
teardown your browsers yourself so it is fiddly to use in comparison to 
a normal control.


The browser widget, on the other hand, is as simple as 'drag the widget 
from the tools palette to your card
and set its url property'. The properties are also editable in the 
Property Inspector.


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: Negative Numbers and NumberFormat

[Mark Waddingham via use-livecode]

On 2017-04-03 19:11, Bob Sneidar via use-livecode wrote:

Was anyone aware that the sign takes up one of the digital in number
format? For instance,

set the numberformat to "00";put -1 +0 & ":" & 0 +0 & ":" & 0 +0
returns:
-1:00:00

but
set the numberformat to "00";put -12 +0 & ":" & 0 +0 & ":" & 0 +0
returns:
-12:00:00

Does no one else find that odd??


It looks odd, but is explainable. It has nothing to do with '-' eating 
up

places for 0 in the numberFormat, but to do with the type of things in
that expression:

Contrast:

set the numberformat to "00";put 0+0 & ":" & 0+0 & ":" & 0+0
  => 00:00:00

And:

set the numberformat to "00";put 0 & ":" & 0 & ":" & 0
  => 0:0:0

The reason here is that the token 0 in a script is actually treated as a 
string *until*
you do something to it which turns it into a number. Only numbers are 
subject to

numberFormat.

So, in the first case you are doing:

  put NUMBER & ":" & NUMBER & ":" & NUMBER

In the second case you are doing:

  put STRING & ":" & STRING & ":" & STRING

The & operator requires two strings, so in the first case the NUMBERs 
are being
converted to strings (and thus subject to numberFormat) whereas in the 
second

case they are already STRINGs so no conversion takes place.

I class this as an anomaly.

The correction would be that any token in script which *looks* like a 
number should
act like a number in terms of string conversion rules (including the 
application of

numberFormat), even if it can't be represented exactly as a number.

This rule would mean that as long as you don't attempt to do arithmetic 
on something

which looks like a number, how it looks will be preserved.

The latter bit about 'not being able to do arithmetic' might sound odd 
but it is

a reflection of the finiteness of computers.

For example, the engine currently uses IEEE doubles for all its 
arithmetic. Whilst
such things can represent a very large number of numbers (2^60 different 
values or
near enough), the actual range a double can represent is substantially 
bigger (many
orders of magnitude bigger, in fact - something like -10^300 to 
+10^300). This results
in there being many many string representations which map to the same 
double (for example

0 can be written as 0, 0.0, 0.00, 0.000, ...).

Indeed, doubles only have about 15 digits of decimal precision, meaning 
that if your
actual number has more than 15 non-zero digits before or after a lot of 
0's then
you'll get an approximation to the actual number (well, you'll get a 
number which is
within DBL_EPSILON of the real number, anyway - this kind of stuff gets 
pernickety very

very quickly).

In actual fact, the above rule can be extended further - and perhaps 
expressed more

succinctly as:

  If a string is converted to a number, then the actual conversion 
should not

  occur until it is absolutely needed.

The point here is that formatting a (decimal) string representation of a 
number
via numberFormat does not actually require conversion to an actual 
number - it can
be done using the string representation alone - and doing it that way 
would mean
that numbers would be preserved to look exactly as they did unless you 
actual poke

them with arithmetic.

Of course, you might argue that 'whats the point of numbers if you don't 
do
arithmetic on them' - but it is often the case that our programs 
manipulate
numbers without doing anything to them, we just need to know that 'they 
are

numbers'.

A good example is the json importers/exporters which exist. They do
zero arithmetic - they merely import and export existing data. In that 
case it
is very important that the data is preserved *as is* otherwise you can't 
roundtrip

(i.e. import data, and immediately export without changing anything).

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

[Mark Waddingham via use-livecode]

On 2017-04-05 18:18, Mark Waddingham via use-livecode wrote:

That is a good question - I shall check...


Panos dug this out:

<https://livecode.com/a-mini-web-browser-in-under-15-minutes-sample-stack-included/>

Hope this helps!

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: Negative Numbers and NumberFormat

[Mark Waddingham via use-livecode]

On 2017-04-05 20:28, Bob Sneidar via use-livecode wrote:

And here is an oddity again. In the dictionary, there is no mention of
spaces or any other character besides "0.#" being valid in a
numberformat string, but:

set the numberformat to " 00";put -09+0 & ":" & 00+0 & ":" & 00+0

produces -09:000:000

In fact, you can put ANYTHING in place of a 0, and it will treat it as
though it were a 0!

Wha???


I think the numberFormat is perhaps just appearing to do more than it 
actually does. Basically it allows you to set the field width before and 
after a decimal point. So:


  set the numberFormat to "."

Will result in the engine padding either side of the decimal point up to 
the specified number of chars with 0 if the length of that part is less 
than the specified width.


Whether or not the '-' sign should be included in these width 
calculations I guess is a matter of debate...


Warmest Regards,

Mark.

P.S. Apologies for missing your actual point before, I should have read 
the thread in more detail before posting ;)


--
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: Negative Numbers and NumberFormat

[Mark Waddingham via use-livecode]

I should say the bit of engine code which does parsing and application of the 
numberformat has been left untouched in terms of what it does for as long as I 
can remember... It is one of those places where a subtle change could break 
apps quite easily as it is somewhat hard to see precisely what it should and 
should not do!

Mark

Sent from my iPhone

> On 5 Apr 2017, at 19:56, Mark Waddingham via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> 
>> On 2017-04-05 20:28, Bob Sneidar via use-livecode wrote:
>> And here is an oddity again. In the dictionary, there is no mention of
>> spaces or any other character besides "0.#" being valid in a
>> numberformat string, but:
>> set the numberformat to " 00";put -09+0 & ":" & 00+0 & ":" & 00+0
>> produces -09:000:000
>> In fact, you can put ANYTHING in place of a 0, and it will treat it as
>> though it were a 0!
>> Wha???
> 
> I think the numberFormat is perhaps just appearing to do more than it 
> actually does. Basically it allows you to set the field width before and 
> after a decimal point. So:
> 
>  set the numberFormat to "."
> 
> Will result in the engine padding either side of the decimal point up to the 
> specified number of chars with 0 if the length of that part is less than the 
> specified width.
> 
> Whether or not the '-' sign should be included in these width calculations I 
> guess is a matter of debate...
> 
> Warmest Regards,
> 
> Mark.
> 
> P.S. Apologies for missing your actual point before, I should have read the 
> thread in more detail before posting ;)
> 
> -- 
> 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

Re: Negative Numbers and NumberFormat

[Mark Waddingham via use-livecode]

On 2017-04-05 19:21, Mark Waddingham via use-livecode wrote:
The latter bit about 'not being able to do arithmetic' might sound odd 
but it is

a reflection of the finiteness of computers.


Just correcting myself: 'finiteness of computers' was the wrong thing to 
say
here - if you can represent a number as a decimal string in a computer 
then it

is clearly finite as the amount of memory you have is finite.

Therefore, it is more about 'needing to do arithmetic quickly on 
computers'

(for some definition of 'quickly').

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: numberFormat affecting array keys???

[Mark Waddingham via use-livecode]

On 2017-04-21 01:51, Bob Sneidar via use-livecode wrote:

Put this into a button:

on mouseUp
   set the numberFormat to "00"
   repeat with i=1 to 10
  put i into myArray [i]
  breakpoint
   end repeat
end mouseUp

At the breakpoint examine the array. There will be a 1 in an element
with the name... ready??? "01"

Okay THAT has GOT to be a bug!!! Why the hell is numberformat
modifying the name of the array element?? I haven't done ANY math on
it. Apparently the engine DOES!


As others have already said, this isn't a bug - just a consequence of
the rules previously mentioned. The engine is doing this:

  repeat with i = strToNum(1) to strToNum(10)
put i into myArray[numToStr(i)]
  end repeat

So, the value of the key is put into the array as a number but array
keys are always strings, so it is converted to a string before indexing
the array.

I think this is perhaps more evidence that 'numberFormat' should 
probably
be deprecated - or at least marked as 'present for HyperCard 
compatibility

only and shouldn't be used in new code'.

Indeed, even the latter is somewhat misleading as (due to the IEEE 
double

internal representation used for numbers in LiveCode), numberFormat does
not and cannot work the same.

(The reason it cannot work the same is that the numberFormat expresses
precision in decimal places, but doubles use binary representation - so
a double can only approximate a decimal number to a certain number of
decimal places, it can't faithfully represent it except for a subset
of values).

My general recommendation is:

  1) Don't use numberFormat in new code.

  2) Use format() to format your numbers *when you want to display 
them*.


  3) Use round() to control the precision of your numbers.

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: numberFormat affecting array keys???

[Mark Waddingham via use-livecode]

On 2017-04-21 16:33, Bob Sneidar via use-livecode wrote:

I got that wrong. I could say I expected the value to be 01. Also if
you see  the value of i in the debugger, it indicates that the value
of i is 1 and NOT 01. So it HAS to be the array designation that is
doing it.


Yes - i is a number (as it is the index of the for loop) so the value
of the array element is a number, and so appears as '1' (not affected
by numberFormat).

However, array keys are *always* strings, so when you set the array key
numberFormat comes into play and the key is '01' and not '1'.

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: The selectedObjects - is it a container or not?

[Mark Waddingham via use-livecode]

Hi Graham,

On 2017-04-17 21:07, Graham Samuel via use-livecode wrote:

I have a stack where the user is allowed to select vector objects. For
this example, let’s assume some objects are already selected.

I am using LC 8.1.4 rc1 on a Mac running Sierra, and I  have a bit of
code that says in part:

if the selectedObjects is not empty then
  repeat with i = 1 to the number of lines of the selectedObjects
  …


Just to clear up precisely what is going on here...

There are a number of pieces of syntax in LiveCode which return control
references (e.g. field 1). As LiveCode represents such things as strings
there is an ambiguity when you do:

   of 

e.g. the number of lines of the selectedObject

In this case it could either mean:

  1) the number of lines in the string returned by the selectedObject

  2) the number of lines in the control returned by the selectedObject

The engine tends towards case (2) in most cases (I can't say all cases
without going through all such things and checking) - including this 
one.



OTOH, if I change the second line to

 repeat with i = 1 to the number of lines of (the selectedObjects0

the code works as expected.


The presence of brackets here force evaluation of 'the selectedObjects'
as a string and not as a control.


If I execute in the message box:

   put the number of lines of the selectedObjects

I sometimes get no result and sometimes “source is not a container”,
but if I change the line to:

put the number of lines of (the selectedObjects)

I always get the right answer.


In the first case, whether or not 'the number of lines of the 
selectedObjects'

will do something sensible depends on:

  1) if there is a selectedObject (otherwise you are trying to get the
 number of lines in no object - which makes no sense)

  2) There is a selected object, but it has no idea of a 'text' property
 so doesn't have anything for 'the number of lines of' to process.

Hope this helps!

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: byteLen()?

[Mark Waddingham via use-livecode]

On 2017-03-09 22:24, Richard Gaskin via use-livecode wrote:

I'm not sure I follow that, but it almost sounds like no matter what
the encoding each char is mapped to one byte, so a 5-chart string like
"hello" will take up 5 bytes - is that right?


In the case of the implicit conversion the engine does between text
and binary data - yes it is. The number of bytes in the generated
data will be the same as the number of chars in the original text.

However that only relates to the implicit 'compatibility' conversion
the engine does. In new code, it is better to make sure the conversion
is explicit by using textEncode / textDecode.


I have some large files I want to open and read as binary (for speed
mostly; if there's a reason I should be doing that as text let me
know), then I'll work my way through it looking for substrings,
keeping track of the byte offsets within the data where those can be
found.

Once I have my list of byte offsets, I can save that as a sort of
index file, and use "seek" or "read at" to go directly to that portion
of the larger files whenever I need to access that data.

The data files may use a variety of encodings, mostly UTF-8 but I can
expect Latin-ISO or perhaps even UTF-16.  In short, encoding will may
be known in advance.

But since I'm working with binary data the whole time, the encoding
shouldn't matter, should it?


It depends on whether you need to convert a text string into a byte 
sequence
to search for, and whether you are wanting an exact text match or a 
caseless

text match.

If the file you are searching is just a text file which you want to 
search
as binary then you need to know the encoding of said text file so you 
can
encode the text you are searching for in the same way. For example, if 
you
are search for "foó" and encode it as UTF-16 (which would generate 6 
bytes)
and the (text) file you are searching is UTF-8 encoded then it won't 
work.

The UTF-8 encoding of "foó" is different from the UTF-16 encoding.

If the file you are searching is some binary file containing text then 
things
are decidedly more tricky as to do the search accurately you need to 
know the
exact format of the binary file so you know precisely where the 
(encoded) text
strings within it sit. This is presuming you are not happy with 'false 
positives'.


(A stackfile, for example, contains encoded text and sequences of bytes 
which
were and never will be text - however, it is perfectly possible for the 
latter

to match encoded text, just by chance.)

If you are wanting a caseless match rather than an exact match then you 
pretty
much have to treat the file as text - you can't do caseless matching on 
arbitrary

bytes as it makes no sense (as they are just bytes with no meaning).


Earlier you wrote:

  the number of bytes in textEncode(tText, kEncoding)

...which implies that I would need to know the encoding (kEncoding),
but do I really need textEncode for the use-case described here?


Strictly speaking that depends on the encoding:

For native encoding - number of bytes == number of codeunits

For UTF-16 - number of bytes = 2 * number of codeunits

For UTF-32 - number of bytes = 4 * number of codeunits

However, UTF-8 is a multibyte encoding based on the codepoints in the
text. A single codepoint can be encoded as 1, 2, 3 or 4 bytes.

The point here being, in order to compute the byte length of a piece of
text encoded as UTF-8 you need to look at each character. Since 
textEncode

does that, it is a reasonably clear way of working such things out.

By the way, here I've mentioned three things - codeunit, codepoint and
char:

  - a codeunit is the smallest element in UTF-16 and represents unicode
codepoints 0-65535 (i.e. fits in a 16-bit unsigned int).

  - a codepoint is the natural 'unit' of Unicode - a 21-bit quantity 
which
indexes into the Unicode char tables. (UTF-16 encodes the 21-bit 
quantity
by using 'surrogate' pairs of codeunits - meaning that, in that 
encoding

a codepoint can take 1 or 2 codeunits).

  - a char is a sequence of codepoints which are generally considered to
be a single (human-processable) character.

I'm not sure if the above helps or not - it might be helpful to explain 
the

problem you are trying to solve more deeply. I still can't quite see how
the byte length of a piece of text (encoded in a particular encoding) is 
useful
since surely you need the byte sequence to search for anyway, in which 
case
the number of bytes is the length of that byte sequence that you already 
have...


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: byteLen()?

[Mark Waddingham via use-livecode]

On 2017-03-09 19:06, Richard Gaskin via use-livecode wrote:

Thanks. I don't mind the verbosity, but I could use some clarity:

There's been talk of LC using UTF-16 internally, but when I do this:

on mouseUp
   put "Hello" into s
   put the number of bytes of s
end mouseUp

...I get "5".

When does LC use UTF-16, and when it's not UTF-16 is it still
ISO-8959-1 or UTF-8?


Internally strings are stored as either UTF-16 or in the native encoding 
(MacRoman, Latin-1) depending on the content of the string and such (the 
engine transparently switches internal encoding as necessary). However, 
this is an internal implementation detail - it might do something 
completely different in the future...


Before 7, the idea of 'byte' and 'char' were synonymous - if you used a 
string in the context of something expecting text it interpreted as 
being a string encoded in the native encoding, if you used a string in 
the context of something expecting binary data it interpreted as being 
just plain bytes.


With the advent of 7 it is necessary to treat text and binary separately 
- they aren't the same thing at all for the simple reason that text only 
becomes binary when you choose a specific text encoding and apply it to 
the unicode string.


In order to ensure that code written prior to 7 worked identically in 7 
it was necessary to add an automatic conversion between text and binary 
which preserved the previous behavior which (essentially) viewed text 
and binary strings as being the same thing.


Indeed, in the above code what is actually happening is this:

on mouseUp
  put "Hello" into a
  put the number of bytes of (s)
end mouseUp

One important property which existed before 7 was that:

   the number of bytes in s == the number of chars in s

However, the definition of 'char' changed in 7 to mean a Unicode 
grapheme - something which will often require many bytes to encode in 
any encoding (e.g. [e, combining-acute] is a perfectly valid way to 
express e-acute in Unicode - taking two codepoints, and not one). In 
order to keep the above equivalence (which would break many things if it 
were not kept) the implicit-text-to-data conversion is defined as 
follows:


  repeat for each char tChar in tString
get textEncode(tChar, "native")
if textDecode(it, "native") is tChar then
   put it after tData
else
   put "?" after tData
end if
  end repeat

(Note: The engine does work quite hard to keep things as equivalent as 
possible - it normalizes tString to NFC first so that it doesn't matter 
if the string has passed through a process which has happened to 
decompose it, or if it has come from a source which favours decomposed 
representations - most notably Mac HFS filenames).


This approach means that any multi-codepoint character in Unicode still 
maps to a single byte - and any non-updated code which manipulates 
strings as if they are data will still work (albeit with some data loss 
in regards the original Unicode string - which it wasn't written to 
understand anyway).


In the future, it is entirely possible that we will make it a runtime 
error to implicitly convert between data and string (don't worry, it 
wouldn't be the default behavior) because if you aren't clear about how 
you are doing the conversion (i.e. which conversion you are using) it is 
a potential source of hard to find errors in code.


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: byteLen()?

[Mark Waddingham via use-livecode]

Hi Richard,

No, there is no such function as the byte length is a property of text which 
has been encoded with a specific encoding, not text in general.

the number of bytes in textEncode(tText, kEncoding)

Should give you what you need.

Warmest Regards,

Mark.

Sent from my iPhone

> On 9 Mar 2017, at 02:37, Richard Gaskin via use-livecode 
>  wrote:
> 
> the len() function returns a character count, but with Unicode this may be 
> very different than the byte size.
> 
> Do we have a size() or byteLen() function?
> 
> -- 
> 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: "ouch: the beginning of the end"

[Mark Waddingham via use-livecode]

On 2017-03-08 14:51, Roger Eller via use-livecode wrote:
So... Why not convert the forms to high-res (300+ dpi) PNG or JPEG as 
Mark
suggests as one of the many options, and overlay LiveCode fields to 
create
an app for filling the form?  Once filled in, merge the high-res image 
with
the collected field data into a fresh new PDF generated via the Quartum 
PDF

Library (using 100% LiveCode scripting).

http://users.telenet.be/quartam/pdf4rev/benefits.html



This sounds like a good balance. I should perhaps point out (after my 
previous
slightly 'gloomy' post) that generating PDF files by hand for specific 
cases

is not that hard as they are mostly text files (in their simplest form).

In Dr Hawkins case, it sounds like images + overlaid text is sufficient 
and as
long as the text is ASCII then Quartam PDF's abilities should be more 
than up

to the task.

[ The reason I mention ASCII text here is that one of the hardest parts 
of
generating PDF (and PostScript, to be fair) is actually text rendering. 
As
they are both display/print oriented output formats they require text to 
be
fully processed into positioned glyphs taken from subsets of embedded 
fonts.
If however you stick to ASCII, or the slightly larger standard Adobe 
encodings
with the default PostScript fonts then most of the complexity falls 
away. ]


The hard part about PDF support (at both sides) is generality - which is 
what
you need if you have no control over what PDFs are coming in, or what 
might

need to be printed to PDF.

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: "ouch: the beginning of the end"

[Mark Waddingham via use-livecode]

Hi Dr Hawkins,

I've been away on holiday for just over a week, and this thread has got
quite long, so I thought it easier to answer the original post rather
than some off shoot on it.

On 2017-03-03 00:13, Dr. Hawkins via use-livecode wrote:

I just got off the phone with the court clerk in Reno, and received the
beginning of the end . . .I figured it would come from some state or 
anther

in a year or two, but they are requiring me to use the *exact* pdf as
propagated by the court.


Having read the entire thread, my understanding of your problem is as 
follows

(please correct if I am wrong):



You have PDF forms which are downloadable from a government department. 
They
are intended for filling printing and then filling in - i.e. they do not 
use

editable PDF forms (FPDF?).

The government department for whatever reason requires that the forms 
are used
exactly as is with the user filling in the relevant spaces within them 
and then

submitting.

There is some claim by said department that 'at some point' they will 
get
scanners which will be able to tell whether the original forms were used 
or not

thus you are not allowed to recreate the non-user parts of the form.



Reading between the lines the latter requirements of the department are 
not
unreasonable - I suspect they would like to automate their processes as 
much
as possible and as such would like to be able to have a computer via OCR 
or
whatever suck out the appropriate parts of forms at some point to remove 
a

human from the equation.

Given that there is an obvious 'printing' element involved in this at 
present
pixel-perfection is not exactly what they are looking for (unless they 
are
imagining they live in a world where all printers are capable of 
absolutely
perfect registration - some skew / offset is always going to be present) 
just
that whatever software they might use in the future to automate can 
locate
the user written parts to suck out - therefore it is reasonable for them 
to
require that the non-user sections are relatively laid out and look 
precisely

the same as if you printed the original PDF.

I'll run on these above assumptions for now.



First of all let me just point out that EPS is definitely *not* what you 
want.


EPS is just a PostScript program with appropriate comments describing an
(optional) pre-rendered thumbnail, and other print related metadata so 
it
can be embedded in another document. Rendering EPS properly requires a 
full
PostScript interpreter - many programs which 'support EPS' actually only 
support

rendering the thumbnail and then only printing on a PostScript printer.

Indeed, there is a good reason why no non-GPL full open-source 
PostScript
interpreter exists (as far as I'm aware at least) - they are complex 
pieces

of software which have a high degree of commercial value.

Whilst Linux and Mac users might be used to transparent PostScript 
support this
is only because GhostScript is installed as an innate part of the 
printing tool
chain on those platforms - thus this is an innate part of the 'system' 
and as
such you can write non-GPL applications which use it as you don't need 
to distribute
it with your app. On all other platforms, however, you are looking at 
having to
distribute a PS interpreter with your app - and at that point you are 
hit by the
GPL (in particular, in your case, it would classify as an 'innate' 
requirement

of your application and non-optional and thus virality would kick in).

So, if you want a PostScript interpreter in your app you are going to 
have to
pay $ to license such a thing. (Including such a thing in LiveCode 
would
require license fees or development costs way above what most people 
would want
to pay for a feature they would probably rarely if ever use and as such 
it is
unreasonable to expect LiveCode to support such things cross-platform as 
part of

the standard license fee - event at the Business license level).

One of the main reasons that Adobe created PDF was to avoid needing a 
PostScript
interpreter to accurately create 'archival' type quality representations 
of printable
documents and to provide a much easier way to edit / amend and modify 
such documents.
As PDF is just a data structure the latter can be done with processing a 
generated
PDF. As EPS/PS are actually a program all bets are off for editing - the 
program
does what it is written to, and you can write it in any way you want. If 
you want to

'edit' it, you need to edit the program.

However

PDF is also a large complicated format whose reading, writing and 
rasterisation

has huge commercial value.

Up until Google bought and open-sourced *part* of FoxIT so they could 
include a
full and complete cross-platform PDF renderer in Chrome (in the form of 
PDFium)
there was no non-GPL open-source full and complete PDF renderer 
available in

the open-source world that I know of.

As far as I'm aware all such open-source libraries for PDF rasterisation 
and

Re: Re Quick Test for Tiemo

[Mark Waddingham via use-livecode]

On 2017-03-31 15:36, Francis Nugent Dixon via use-livecode wrote:

Sorry Tiemo,

Got a message that "MyMACs.livecode" is not a stack - can't open it
with LiveCode

I wonder why ?

Using - 10.12 Sierra with LiveCode 5.5.


It is a 7.0 format stackfile... The error message in older LiveCode 
versions was a little lacking in this regard, it is more specific in 
6.7.x onwards (i.e. it tells you why it doesn't think it is a stack!) :)


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

[Mark Waddingham via use-livecode]

Indeed our split isn't perfect - so there's a list of things we can and cannot 
do - depending on which engine version is needed to support the changes - this 
forces a good process (because it forces thought on it).

The submodule link is a version dependence - it's just hard to think of it like 
that because we go engine->ide, rather than ide->engine which would be 'better'.

Of course I use the term A/B testing - but that's just a superset of what we 
are already doing (we're just doing one test at a time at the moment and 
probably will do for quite a while).

However, the underlying process should be the same - and the points of friction 
are actually also points of potential error (in terms of if the boundaries 
weren't there then it would be where we could be more likely to make a mistake) 
- so those points of friction help maintain good process (because it forces us 
to think about the dependencies).

A lot of the IDE first run things are just superficial in the sense they are 
entirely ide code, and engine tweaks are generally fixes which have to follow 
maintenance procedure anyway.

And yes, submodule a cause grumblings internally and from contributors - so 
that just requires tooling to help, and a gradual cleanup of the boundaries of 
our repos so we can eventually restructure slightly to serve us better until 
they aren't a problem anymore. Retaining our quality process is higher priority 
I think, and should come first right now - that's all.

Warmest Regards,

Mark.

Sent from my iPhone

> On 30 Jul 2017, at 23:17, Monte Goulding via use-livecode 
>  wrote:
> 
> 
>>> On 31 Jul 2017, at 6:59 am, Mark Wieder via use-livecode 
>>>  wrote:
>>> 
>>> 
>>> Actually, submodules actually do their job really quite well. They aren't 
>>> ideal, but they do enforce modularity (hence the name ;)). We just need to 
>>> get round to sorting out some tooling (local shell scripts / git hooks) to 
>>> help make sure they aren't quite so easy to forget about syncing properly.
>> 
>> It's possible (and IMO preferable) to have a modular approach to app 
>> building in makefiles and such without forcing git to have to deal with that.
> 
> Submodules are very helpful when they are doing what they are meant to do 
> which is point to a specific version of a dependency.
> 
> Unfortunately with the ide submodule we have two way dependencies and tests 
> that break in one or the other or both if they aren’t updated in sync. Indeed 
> we have some ide libraries in the engine repository. So sometimes to make a 
> seemingly small patch you need to patch both repos. Additionally it’s easy to 
> break an IDE test and not find out about it until everything is merged up 
> because tests are run against the main repo (this is potentially solvable by 
> working out how to run the tests for all the submodules but it will require 
> some special Travis wrangling). 
> 
> There is an overhead to all this that I personally believe doesn’t justify 
> the benefits. Should we have IDE A/B test versions then I think we will need 
> to branch the engine repo for them sometimes anyway so any benefits may be 
> less than they at first appear… indeed the scenario may multiply the 
> overheads… 
> 
> Anyway, probably better to continue this discussion internally as not may 
> people here would be interested in this.
> 
> 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


___
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: Wait, the problem, and why it is important to solve

[Mark Waddingham via use-livecode]

Hi Herman,

This is all very useful information I must confess.

I guess I'm wary of just extrapolating potential performance from piecing 
together results from very different underlying architecture (e.g emterpreter 
vs no emterpreter) over bastions different html5 engine iterations.

Of course your post has made me wonder whether a hybrid approach might work 
(i.e. emterpret enough to get wait working but not so much it damages 
performance - I'm sure there was a technical reason why this wasn't an option - 
but it is probably worth trying again).

Also it might be worth doing two versions one wait capable (slow speed); one 
non-wait capable (faster speed).

At least then users have a choice and it will depend on their app which they 
need to use.
 
Anyway, I'm on holiday for a week now so might be a bit quiet on here (compared 
to recently, anyway). However I will return to this, and everything else when 
I'm back.

Warmest Regards,

Mark.

Sent from my iPhone

On 30 Jul 2017, at 19:25, hh via use-livecode  
wrote:

>> Mark wrote:
>> I'm not sure relating this to RaspPi is useful. The reason is that if I 
>> am wanting to move my Desktop app (Mac, Windows, Linux) app to HTML5 
>> then I'd want the performance in the browser to be within a reasonable 
>> distance of that when on the Desktop...
>> ...The only way to know what the speed of a certain combination of 
>> implementation strategies and execution environments is to actually run 
>> performance tests.
> 
> Well, I compare "scenarios", that is "target-platforms" and  LC versions
> that generate the standalone, running on "medium" hardware (mine, for tests).
> 
> May be some say I'm going to compare apples to oranges. Yes, I do, both are
> fruits and I can eat the one or the other or both. These are my experiences,
> without "wait":
> Say I'm on medium fast machines (2.5GHz), and say I am going to make an
> animation using graphics, with the fastest method (send in time, no wait) and
> everything needed is already available in LC 6.7.11.
> 
> Such scripts will run at about the same speed on desktop Mac/Win/linux (what
> is an excellent result).
> This is the base speed I keep in mind, it is at about the same for standalones
> or still being in the IDE.
> And this is probably one of the most used standalone version that is compared
> to HTML5 standalones, the latter built with "unchanged" source.
> 
> Now I will have here a slow down by a factor of (best cases)...
> ... 10 or 20 when running on Raspi2B+ or Raspi3.
> ... 2-3 when when running in LC 8/9 on the same machine.
> ... 6-32 when running in the newest version of the most used browser on
> Mac/Win/linux in a HTML5 standalone.
> 
> *** For me these are good-to-know thumb-rules, mostly very close to real 
> tests.
> And running a test-stack on Raspi3 in the 6.5.1 IDE is at about the average
> speed I'll get in a HTML5 standalone on a medium fast machine with 
> Mac/Win/linux.
> 
> Once again, compared to LC 8/9 desktop standalones, the slow down factor is...
> ... 3-16 when running in the newest version of the most used browser on
> Mac/Win/linux in a HTML5 standalone (what is an excellent result).
> 
> The lowest slowdown for HTML5 standalone is when using the 'fastest' browser 
> of
> Safari/Firefox/Chrome/Opera which is currently Safari on Mac. For the 
> 'slowest'
> browser (Chrome/Opera) there is AGAIN, compared to Safari, a slow down of 3-4.
> [-> But Opera Developer is already close to Safari!!]
> 
> In sum, if I wish to display a "complicated" clock animation every second 
> (also
> having the different refresh rates of the different main browsers in mind) 
> then
> I know I have to reach less than 30 millisecs per cycle in LC 6.7.11 or 60
> millisecs per cycle in LC 8/9. And I have to "work-around" for the worst case.
> 
> And if you wish to be below the refresh rate of 54 millisecs of Firefox on
> Mac/Win/linux with your HTML5 standalone, then you have to reach 5-6 millisecs
> per cycle in the LC 8/9 IDE on the same machine.
> 
> Such good results are in the dreams only of some other comparable IDE's.
> 
> So no exaggeration is needed. Take it as good as it is. And go on, LC-team, 
> with
> your excellent work to improve it.
> 
> ___
> One possible "test-stack" to reproduce my thumb-rule statements on your own
> machine(s) is the source code of the "LCD"-HTML5 standalone.
> Start there with preset 7 for comparing browsers on the same machine:
> http://hh.on-rev.com/html5/LCD-01e-8.0.2X.html
> (replace "X.html" with ".zip" for the source)
> There is also Raspi stack #79 which is (probably) that source code
> http://forums.livecode.com/viewtopic.php?p=145528#p145528
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

Re: AW: load URL is broken in 8.1.4

[Mark Waddingham via use-livecode]

I don't think there is anyway we can deny that the transition from 6.x to 7.x 
caused a lot of regressions.

This is why we have a strict policy of handling maintenance releases now - i.e. 
we work very hard to ensure each maintenance version is strictly better than 
before.

I know of a number of users who have had similar difficulties moving from 6 
straight to 8 - however, barring the occasional error (e.g. The backdrop fiasco 
and the load URL one you mention directly) 8.1.(x+1) has had less regressions 
relative to 6 - and no regressions relative to 8.1.x.

Also (as far as we can) regressions relative to older versions get very high 
priority in our bug fixing queue.

So things might not yet be perfect but I'd hope that everyone can see that 
we've made great strides (indeed, we've made good progress on fixing issues 
which have been around a lot longer recently - even back to the very early days 
of the MetaCard engine).

No-one likes encountering regressions - however in a system as complex and 
broad as ours they are often unavoidable.

Every one sees a different view of the elephant so to speak - and we try to act 
as quickly as we can when issues are reported (usually seeeing them fixed in 
the next maintenance release).

Warmest Regards,

Mark.

Sent from my iPhone

> On 31 Jul 2017, at 12:27, Tiemo Hollmann TB via use-livecode 
>  wrote:
> 
> I forgot my final question: Have you made similar experiences or is it only
> me and how do you handle this permanent hazard of regression bugs?
> Tiemo
> 
> -Ursprüngliche Nachricht-
> Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag
> von Tiemo Hollmann TB via use-livecode
> Gesendet: Montag, 31. Juli 2017 11:16
> An: LiveCode User Liste senden 
> Cc: Tiemo Hollmann TB 
> Betreff: load URL is broken in 8.1.4
> 
> Hello,
> 
> For my automatic update mechanism I am downloading a zip file from a web
> server, extracting the zip file and starting the downloaded update.
> 
> I am doing this since years, without having changed anything in my code. Now
> in 8.1.4, Windows 10 this load URL downloads a "broken/corrupted" empty zip
> file, which breaks my whole update process. In 8.1.4 rc1 this still has
> worked and in 8.1.5 it seems to work again without any changes in my code or
> the zip file. I didn't tested yet 8.1.6 and 9.
> 
> I had done a minor change in my program, completely far off the download
> handler and just build a new standalone for a new CD production and thought
> I'll take the "stable" release 8.1.4 instead of the last build with 8.1.4
> rc1 for the new production. Because it was only a minor bug fix in my
> program and I only switched from 8.1.4 to 8.1.4 rc1 I didn't tested each and
> every possible feature of my program, before going into the production of a
> new release. Only by a great chance I discovered that my update process is
> broken. If I would have sold this new CD production, I would never have been
> able to update my program again, because the update process would have been
> broken.
> 
> In all the years working with RunRev/LiveCode I never have experienced so
> many, frequently regression bugs as in LC 8. I had at least 10-20 regression
> bugs in LC 8, since switching from 6.7. Almost in each single release
> candidate and each general release there are new regression bugs of old and
> common features so that it is a game of hazard to use a new release. I have
> no idea, what is going on behind the scenes in Edinborough, if it is related
> to the open source development, so that everybody can create regression
> bugs, but this isn't anymore a reliable software development. The complete
> responsibility is passed to us.
> 
> Sorry, but I am really pissed off and my trust in every new release has
> dropped to zero.
> 
> 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
> 
> 
> ___
> 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: template stacks

[Mark Waddingham via use-livecode]

On 2017-07-28 11:30, Richmond Mathewson via use-livecode wrote:
From LiveCode 8.0 upwards when one wants a new stack one is given a 
menu

of choices for iPads, iPhones and so on.

Is there a way to edit that menu PERMANENTLY so one
can accommodate one's own sizes?


That is perhaps something we could add to preferences so you could 
configure... Feel free to file an enhancement request for it in the 
quality center :)


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

[Mark Waddingham via use-livecode]

Well Gitter itself is posed as more a technical/open source software dev thing 
I think.

Peter set it up as a more modern form of irc channels where people contributing 
to the open source project can interact with us and others along those lines.

For that it works really well. There can be a little bit of a delay in terms of 
getting an initial response sometimes - but when there's an active conversation 
going on we all try and be as responsive as we can.

We are likely to ask people to 'go elsewhere' if their questions / chat is not 
about actually contributing to the project - codewise in particular (or helping 
us do the dev work we do - e.g. Trying to diagnose a thorny problem in specific 
platform configurations!)

Mark.

Sent from my iPhone

> On 29 Jul 2017, at 08:01, Mark Wieder via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> 
>> On 07/29/2017 01:44 AM, Mark Waddingham via use-livecode wrote:
>> P.S. None of us tend to sit on gitter.io - we can only process so many 
>> simultaneous inputs - however gitter does send email notifications when 
>> someone posts something on there and usually it doesn't take too long for 
>> one of us to notice (weekends, notwithstanding!).
> 
> While I think the original idea for using gitter (after trying Slack first) 
> was to set up sort of an IM channel, I have stopped expecting it to be that 
> and instead I use it for conversations where I need some deeper or arcane 
> expertise and don't feel like cluttering up the uselist or the web forums 
> that would be of interest to nobody else. And, once I stopped expecting it to 
> be an IM channel, I have to say that whatever the subject, I have always 
> gotten immensely useful information from the team on gitter.
> 
> -- 
> Mark Wieder
> ahsoftw...@gmail.com
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: Web vs Native (was Re: HTML5 limitations?)

[Mark Waddingham via use-livecode]

 of code) into something no browser could load. This is because the engine 
is general - it is the thing which runs the specific code that you all write.

So we just raise the level - we asyncify the livecode script at the point an 
html5 standalone is built. We write a tool - extrinsic to the existing engine 
code - which does the necessary analysis and rewrites the code you write 
automatically and transparently.

At this level the analysis is tractable, the amount of code which is needed on 
is orders of magnitude less and (most importantly) as the tool is extrinsic it 
can be done without touching a single line of the existing source base - so 
there's no way we can break any part of the functionality of the existing 
engine whilst working towards this goal.

So anyway, that is essentially the story of wait in HTML5. With hindsight the 
solution is blindingly obvious - however (as is often the case), the right 
solution often does not appear until you have seen all the wrong ones.

 Warmest Regards,

Mark.

Sent from my iPhone

> On 28 Jul 2017, at 18:18, Jonathan Lynch via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> 
> I thought that JS/HTML5 did not have a wait function? One can loop the 
> engine, which is horrible, or one can set timeouts for functions. What 
> functionality do you access to induce a wait?
> 
> Sent from my iPhone
> 
>> On Jul 28, 2017, at 8:29 PM, Mark Waddingham via use-livecode 
>> <use-livecode@lists.runrev.com> wrote:
>> 
>> Hi Hermann,
>> 
>> First of all please don't take any offence at my email as none was intended.
>> 
>> I was mainly trying to explain that whilst there are many things the HTML5 
>> engine does not do, which means many stacks will not work without 
>> changes/workarounds (indeed, somewhat significant ones) - there are 
>> increasing numbers of those which do work and this is set to continue and 
>> expand as we have more time to spend on the 'surface' features as opposed to 
>> the core.
>> 
>>> On 2017-07-28 22:22, hh via use-livecode wrote:
>>> Probably the "one" (=checking if the mouse is "down") pledged and bought a 
>>> HTML5
>>> license, the "at least other 2" (=never using it) didn't pledge nor
>>> buy a license.
>> 
>> To be honest, this really is probably not true.
>> 
>> The thing is that 'the mouse' has long reported the event-asynchronous mouse 
>> state, which is almost never what you actually want on modern purely 
>> event-driven OSes - so over time its use has diminished as if you use it to 
>> do certain things (not all - admittedly), you will end up noticing 
>> 'interaction faults' which can be fixed by tracking mouseDown / mouseUp 
>> using the event loop. Also, it is generally used alongside 'wait' - which of 
>> course does not currently work.
>> 
>> Obviously you do use it, as do others, so it isn't that it is not important, 
>> just that there are lots of other things that we have been working on in the 
>> HTML5 engine first which *are* used much more widely.
>> 
>> It isn't actually possible to get the async mouse state on HTML5, so it will 
>> not be 100% the same (although to be fair, the approximation we can use 
>> there is probably more correct anyway). It is just a matter of time before 
>> we get it to work, not if.
>> 
>>> I reported to quality center in Dec 2015/Jan 2016, that the state of the 
>>> mouse
>>> and modifier keys aren't recognized and that all menu buttons crash
>>> the standalone.
>> 
>> Similarly, the modifierKeys. Text entry and keyboard states for the LiveCode 
>> engine in HTML5 is another what is a seemingly 'simple' thing from the 
>> outside, but is actually not that simple at all under the hood.
>> 
>> We are still working on solving some issues with text entry - we will solve 
>> the problem in time, but again as with other facets of this endeavour some 
>> things are taking a lot longer than we had originally anticipated.
>> 
>>> Since the start of this *395 thousand dollars* project in July 2014 I made 
>>> at
>>> about 60 "successful tests" to show 'oh the HTML5 engine does this' and
>>> 'oh it does that'. This wasn't easy at all, needed a _lot_ of workarounds 
>>> ...
>> 
>> You've mentioned the amount of money raised several times; however, one 
>> thing which everyone has to appreciate is that every project we have 
>> crowd-funded has had the value raised matched at least by a factor of 2 from 
>> other sources (in some cases significantly more). My point here is not to 
>> undervalue the contr

Re: Web vs Native (was Re: HTML5 limitations?)

[Mark Waddingham via use-livecode]

On 2017-07-29 07:11, J. Landman Gay via use-livecode wrote:

On 7/28/17 7:29 PM, Mark Waddingham via use-livecode wrote:
P.S. At some point I'll write at length about the 'wait' problem in 
HTML5. Whilst I try not to let myself be kept awake at night by 
engineering problems related to work - if ever there was one which 
did, it would be that one!


When you recover from sunstroke I'd be interested to hear about that.


I figured many people would so check the email I just posted - whilst my 
general irascibility and tendency to 'tilt at windmills' (again, sorry 
Hermann, and Bob) might go up slightly when suffering from sunstroke, 
hopefully my technically acuity isn't affected too much!


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: controlNames deprecated??

[Mark Waddingham via use-livecode]

I use Firefox for dev'ing on the html5 engine as it tends to be at the 
forefront of 'what is to come' and also I find it's dev console somehow more 
responsive and 'better' than Chrome's and Safari's when dealing with huge blob 
of JS that the html5 engine is.

For everything else I use Chrome.

In all fairness to the Mozilla crew they are currently rewriting the core of 
FireFox in Rust (the Servo project). In fact Rust has been developed to do that.

When that is done we can fully expect that FireFox will be the most secure 
browser (at least as far as the bounds of the layout engine / JS engine goes) 
when evaluated from the point of view of having any exploitable vulnerabilities 
caused by coding errors (as you can't make such errors in Rust).

So if FireFox itself is going through a bit of a end-user low point it is 
likely in part to that (and the division of resources they must be facing).

Warmest Regards,

Mark

Sent from my iPhone

> On 28 Jul 2017, at 15:13, Mark Wieder via use-livecode 
>  wrote:
> 
>> On 07/28/2017 01:52 PM, Bob Sneidar via use-livecode wrote:
>> Duly submitted from Chrome. Something is wrong with Firefox.
> 
> I recently had a brief flirtation with Firefox for a few weeks, then gave up 
> in disgust and went back to Chrome. Web browsers are such memory hogs these 
> days.
> 
> -- 
> Mark Wieder
> ahsoftw...@gmail.com
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: E.T.

[Mark Waddingham via use-livecode]

On 2017-07-29 09:53, Richmond Mathewson via use-livecode wrote:

I would suppose I need that software to "phone home" and check itself
against a list (text document)
or something so that only 5 copies can function "out there", and if a
6th version phones home it
will do a "Peter Graves" and self-destruct.

Obviously this needs the end-user to have an active internet
connexion, at least when the program is
initially installed . . .


There are tools which exist (I'd provide links to examples, but my 
google-fu is failing me tonight) which when given a compiled application 
(LiveCode standalones will work fine), will wrap it up in something 
which will control the number of simultaneous uses on a local network.


It might be a good solution in your case. Indeed, there are some 
organisations (such as universities) which actually use them themselves 
on the software they purchase in multi-user settings in order to ensure 
they can strictly conform to licensing requirements.


Hopefully someone else can find the right phrase to google to point you 
in the right direction!


Warmest Regards,

Mark.

P.S. Writing a system which you propose is perfectly possible - in 
LiveCode - the IDE does this (for example - although our solution is 
very specific and not general). However, it isn't an inconsiderable 
amount of work - particularly as users tend to get a little 'vexed' if 
the system breaks at any point (even for short periods!).


--
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: Compiling LiveCode on Sierra

[Mark Waddingham via use-livecode]

On 2017-07-29 07:11, Brian Milby via use-livecode wrote:

Is it possible to compile the LiveCode IDE on Mac OS 10.12.6?


Yes - some of us (at LiveCode) use 10.11, some 10.12. We also have a 
10.9 machine which is more of a 'hot-desk'. (One of our test machines is 
10.10 IIRC, so we have all bases covered). [ Panos has also recently 
setup a 10.13 beta machine - not liking some of the crash reports we are 
seeing there - one wonders what Apple are doing with that! ].


I tried to follow the instructions on GitHub.  I have the Xcode 
versions
downloaded.  I had to use sudo to get the setup_xcode_sdks.sh to 
finish.
First pass was missing Java, so went back and installed that.  Was able 
to
configure, but build complains about a missing SDK.  Finally got it to 
a

point where I saw an error message that the earliest SDK that could be
built against is 10.11 so I tried to edit some files and try again.  It 
got

further, but failed somewhere in the Skia library.


We currently support the engine source being compiled against the 10.9 
SDK - but I think it *should* compile against 10.11 SDK and 10.12 SDK (I 
believe Ali made some tweaks to ensure the latter lately).


Recent versions of Xcode have a setting in an internal plist to (by 
default) ignore the 10.9 SDK - this can be solved by:


"edit (with Xcode) the MinimumSDKVersion key value in 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Info.plist"


[ Taken from here : https://forums.developer.apple.com/thread/43381 ]

Of course, you'll need to grab the 10.9 SDK from an older version of 
Xcode. Apple being Apple don't make these easily available (because, of 
course, if you are using the latest Xcode then you can't be using a 
project which has to also compile on older Xcodes for testing purposes 
as, obviously, everyone in the Apple world always has the latest OS 
don't they! Ahem).


Hope this helps - if not it might be worth trying to capture the 
attention of one of us on gitter.io (LiveCode channel) so we can help 
diagnose the issues in 'real-time'.


Warmest Regards,

Mark.

P.S. None of us tend to sit on gitter.io - we can only process so many 
simultaneous inputs - however gitter does send email notifications when 
someone posts something on there and usually it doesn't take too long 
for one of us to notice (weekends, notwithstanding!).


--
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: Wait, the problem, and why it is important to solve

[Mark Waddingham via use-livecode]

Indeed - we can make all the things on the list I made have a callback / 
without waiting form too.

In terms of wait itself - it is the HyperTalk way of doing 'async' - allowing 
you to write such code without the 'headache' of nested callbacks / closures 
and such - this is why it is important to retain and improve. It makes coding 
event driven things easier.

The fact that C# has async, and JS is getting it (because node.js primarily) 
shows that it is an important pattern. One we've had for years, just in a 
restricted (recursive) form.

Warmest Regards,

Mark.

Sent from my iPhone

> On 31 Jul 2017, at 16:39, Mark Wieder via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> 
>> On 07/29/2017 09:23 PM, Mark Waddingham via use-livecode wrote:
>> 
>> P.S. One other possibility I've toyed with is doing LCS->BYTECODE, then 
>> BYTECODE->ASYNCIFIED_JAVASCRIPT. The latter would be particularly easy if 
>> targetting browsers which have already implemented the new async JavaScript 
>> features. Since it looks like the HTML5 engine will only become truly widely 
>> usable when we move to WASM, this might well be a much more maintainable, 
>> and relatively quicker option.
> 
> I also want to point out (thanks for that long well-thought-out post) that 
> many of the use cases you list might be better served with callback functions 
> than with a cobbled-together 'wait' command. Javascript on its own doesn't 
> have a wait or sleep command, and while there are ways to simulate the 
> effect, they are problematic in a real-world environment where network timing 
> issues are out of control of the calling code.
> 
> -- 
> Mark Wieder
> ahsoftw...@gmail.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: template stacks

[Mark Waddingham via use-livecode]

On 2017-07-28 18:01, Richard Gaskin via use-livecode wrote:

But those seem pretty rare to me.  On desktop my windows tend to be
different sizes, and on mobile it's important that they be responsive
to any screen size; in either case the specific dimensions at the
moment of creation seem of little value.


All of this is very true... However, Richard, how long have you been 
designing/programming/building apps for?


A new user coming to a programming environment (of any kind) is usually 
presented with a wealth of choices. Every choice which can at least be 
parameterised / or constrained as the first step makes things 'easier' 
(in some sense).


This is particularly pertinent to mobile - for sure, all apps should be 
able to adapt to all screen sizes. However, in reality when you start 
out you have to choose one size. Hence the options in the New Stack 
menu. It isn't perfect, but at least means a brand new user has some 
chance of choosing a size which will actually fit pixel-for-pixel on the 
device they have next to them to play with.


Now, that menu is not perfect - we know its not - you've pointed that 
out to us often enough ;)


However, we are now actively involved in a process of trying to evaluate 
what 'first-run' things do actually (measurably) make a difference. I'm 
sure that particular menu will be the subject of such 'tests' at some 
point in the process :)


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: HTML5: mixed signals

[Mark Waddingham via use-livecode]

Hermann has the 'the right' of it here.

Basically it is important to remember that just because you *might* be 
able to see source-code it doesn't mean you have the right to copy, use 
or do anything with it. If there is no license attached to it, or if 
there is not a clear declaration of a license under which you are 
receiving it then it is not yours, you cannot touch it, you cannot use 
it. If you do, then you could find yourself being subjected to a 
copyright-related law suit (depending on how litigious the owner of the 
copyright of the source code is). (Generally for very small 'snippets', 
there is no problem, it is only significant and/or complete works under 
which this could be enforced, in general).


If you use the community version, then you are not just obliged, but you 
are ABSOLUTELY REQUIRED (by the GPL) to make the full source of the 
application you are conveying available UNDER THE GPL (our HTML5 
standalone builder makes this easy - as it does it for you :)). This 
isn't optional, it is part of the agreement you make by using the GPL 
licensed community version in the first place. If you do not do this, 
then you are breaking that agreement and in so doing your right to use 
the GPL software from which it originated (LiveCode in this case) is 
(legally speaking) terminated.


If you use the commercial version, then there are generally no 
restrictions on what license you may convey your applications or source 
code under. It is reasonable to assume, with the absence of a license, 
that if you give someone a software application that they are allowed to 
run it. However, that is about as far as you can assume. The receiver 
has no right to use any part of the source-code they may or may not see 
(this is protected under copyright - the author* of the source-code of 
an app is the copyright holder) in any way. So being able to see source 
code does not imply a right of use, modification, distribution or indeed 
anything. Indeed - even the right to run received software is 
necessarily a given (just an implied right, else why would you send 
someone it?) - this is why you should always attach a license to all 
software you distribute it, explaining the allowed bounds of use by the 
receiver.


Of course, the commercial version has password protection built-in, so 
you can hide the source of your commercial apps from prying eyes to give 
you a level of physical protection; and not just legal. (You have the 
legal protection, regardless).


Warmest Regards,

Mark.

* It is really important to note that in the UK, and most other 
countries, if you write code during periods of time you are being paid 
for by your employer, then the copyright is implicitly owned by the 
company *and not* you. Consulting work is a little more grey - which is 
why it is important that you agree the terms of copyright ownership as 
part of the contract discussion. Typically this is structured as 'the 
copyright of code specific to the client project is owned by the client' 
but 'any library code not specific to the client which the consultant 
has built up to enable her/him to do his work is licensed under a 
perpetual license to the client'. Of course, this kind of thing very 
much depends on the client - a client is perfectly within their rights 
to ask that all code in a project is copyright them... However, then it 
is just a question of cost - i.e. if they can afford to pay for that to 
be the case!


--
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: Web vs Native (was Re: HTML5 limitations?)

[Mark Waddingham via use-livecode]

On 2017-07-28 16:47, Sannyasin Brahmanathaswami via use-livecode wrote:

Hence oft-repeated prayer that we get the browser "widget" to become a
true member of the LC message hierarchy, they we can leverage the web
apps eye candy layer (easy to build, responsive, CSS is already done
for us…) with LC powerful framework, so that we don't have to waste
time using JS to get work done, but use it just for "clicking here and
there" while LC does the heavy lifting in the background.


I can assure you your 'prayer' has been heard - however, there is a 
slight chasm between hearing a prayer and being able to act on it 
(especially for mere mortals, like ourselves ;)).


There is a whole (reasonably sized) 'new market' for LiveCode in the 
space of providing the shell into which HTML5/JS webapps can be placed. 
i.e. The creation of a native app which wraps a HTML5/JS web-app which 
then has direct access to all the platform features LiveCode gives you 
access to (a bit like PhoneGap or Cordova or ... - the fact there are so 
many of these things suggests that it is a very useful thing that people 
actually want to do). Now, this works quite well right now - although I 
do appreciate that the asynchronous nature of return values from the 
host (LiveCode) does make some things more difficult to do (*although*, 
it should be pointed out that async something I think *all* other host 
environments that provide this kind of wrapping have to put up with!).


However, as you have may have noticed (from various comments - sometimes 
positive, sometimes not, mostly not - about CEF) there is a fair bit of 
technical challenge involved in having a browser widget and keeping it 
working on all platforms. Now, this is not to say we do not like 
technical challenges - we clearly do. However, in general, the greater 
the technical challenge, the greater the resources required to solve it.


Such an endeavour *has* to be self supporting - i.e. it needs to 
generate enough revenue in order to justify its existence. The browser 
widget as it stands is already taxing us on that front (it is really 
important, so whilst I sometimes get concerned about the 'money-pit' it 
sometimes seems to be, one has to remind oneself that some things are a 
long-term investment).


Of course, the above is entirely related to technical issues - there is 
also the problem of selling LiveCode and this feature into such a 
space...


That old adage of 'build it and they will come' is quite possibly one of 
the biggest load of bovine-backend-excretion that has ever been uttered. 
Build it and, well, most people will walk by it, some might look at it 
and go 'oh that's nice' and walk on, very few will actually take the 
time to visit it without some sort of cajoling. Unfortunately, this kind 
of activity (I'm of course talking about marketing) tends to be a great 
deal more expensive than development (I could make the rather cynical 
observation that there is a reason why marketing consultant's offices 
tend to be a great deal 'nicer' than those of computing consultants - 
but I should probably keep that to myself ;)) and it is only through 
marketing such things that you can make them generate enough revenue to 
pay for their seat at the table.


So TL;DR version. Yes - Kevin and I would both like to do more with the 
browser widget as it is actually a really really cool thing (so we hear 
your prayers - every one). However, right now, we simply don't feel we 
have the bandwidth (to use a Kevinism) to do it properly in a way where 
the endeavour can be fully self-supporting. Also, we are already seated 
at a rather large dinner at the moment (Infinite LiveCode, LiveCode 
Connect, LiveCodeForFM, Version 9, Maintenance of 8, ...) so perhaps 
need to finish *at least* one of those courses before we embark on the 
next (no-one likes indigestion, after all).


Warmest Regards,

Mark.

P.S. By the way, I'm mainly saying all of this to make it clear that we 
have been listening, we are just not able to act on it at the moment. 
Please *do* keep poking us about it - as it keeps the idea in our minds, 
and each time it comes up it causes a re-evaluation. It also helps to 
remind people that they CAN use LiveCode for this kind of stuff and so 
should - which is a precursor to being able to convince people who are 
not 'LiveCoders' that LiveCode might be something they should check 
out... If only to give them an easier way to ship a 'native' HTML5/JS 
app.


P.P.S. We are also fully away that this 'HTML5/JS' wrapper idea is also 
very much a gorilla activity - they might come for the wrapper, but stay 
because of LiveCode. However, one still needs to capture and tame the 
gorilla first ;)


P.P.P.S. Yes - I know it should have been 'guerilla', it is just that 
using 'gorilla' seemed more fun.


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

___
use-livecode mailing 

Re: Web vs Native (was Re: HTML5 limitations?)

[Mark Waddingham via use-livecode]

On 2017-07-28 18:28, William Prothero via use-livecode wrote:

on myRequest
   —send a POST or GET request, whatever, with a callback handler 
specified.

   —display a mask that inhibits new mouse clicks and sets a busy icon.
end myRequest
on myCallbackHander myReturnData
  —do whatever you want with myReturnData
end myCallbackHander

But then again, I’m not a master of javascript, so there may be other 
issues.


I think it is mainly the thought process which goes with having to do 
things in this 'threaded style' - for simple things it is fine, but it 
can get unwieldy pretty quickly for long running sequences of stuff. 
From an abstract perspective, at the very least, it *should* be possible 
to make this more natural (e.g. C# has an 'async' concept - which is 
basically a bit like out wait but more focused) so that is one angle 
here.


Although I am one of the people calling for more browser widget 
development...


I have my doubts about the ability to make it synchronous with LC.


It is definitely possible - the fact it is not is related to a technical 
detail in the way the engine interoperates with CEF (and the other 
browsers). However, being possible says nothing about the difficulty of 
getting it to work or ensuring it continues to work!


The HTML5 engine IS synchronous so that gives at least a suggestion that 
is should be possible (although, admittedly, the HTML5 engine IS 
JavaScript so there's no 'world-boundary' to be concerned about in that 
instance).


At the end of the day, it might not be that making it synchronous *is* 
the solution, but instead tweaking engine syntax and semantics to make 
it easier to deal with this asynchronicity.


e.g.

on mouseUp
  async do "..." as javascript into tVar
  -- implicit wait until tVar has been set
  put tVar into field 1
end mouseUp

Note, this is just pseudo-code for the idea. The hardest part about 
doing the callback thing is that it splits up the critical sequence of 
actions you are trying to code into lots of bits separated by cruft (the 
handler definitions). This reduces readability, and maintainability 
which is something we really don't want. i.e. The problem you are trying 
to solve is obfuscated by the technical baggage needed to solve it.


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: HTML5: mixed signals

[Mark Waddingham via use-livecode]

Oops - I forgot to say 'I am not a laywer but'... At the start of this.

I should say that most of this stuff is pretty standard, in general as 
long as you always use attach a license to your commercial works, and 
always follow the requirements of the GPL then you don't have to worry 
about these things too much.


However, if something comes up where it *doesn't* seem entirely 
clear-cut, particularly if the works involved are significant, or the 
money involved is significant (for some definition of significant) it is 
well worth consulting an actual physical lawyer to make sure you aren't 
accidentally stepping on a mine you did not see!


Warmest Regards

Mark.

On 2017-07-28 16:32, Mark Waddingham via use-livecode wrote:

Hermann has the 'the right' of it here.

Basically it is important to remember that just because you *might* be
able to see source-code it doesn't mean you have the right to copy,
use or do anything with it. If there is no license attached to it, or
if there is not a clear declaration of a license under which you are
receiving it then it is not yours, you cannot touch it, you cannot use
it. If you do, then you could find yourself being subjected to a
copyright-related law suit (depending on how litigious the owner of
the copyright of the source code is). (Generally for very small
'snippets', there is no problem, it is only significant and/or
complete works under which this could be enforced, in general).

If you use the community version, then you are not just obliged, but
you are ABSOLUTELY REQUIRED (by the GPL) to make the full source of
the application you are conveying available UNDER THE GPL (our HTML5
standalone builder makes this easy - as it does it for you :)). This
isn't optional, it is part of the agreement you make by using the GPL
licensed community version in the first place. If you do not do this,
then you are breaking that agreement and in so doing your right to use
the GPL software from which it originated (LiveCode in this case) is
(legally speaking) terminated.

If you use the commercial version, then there are generally no
restrictions on what license you may convey your applications or
source code under. It is reasonable to assume, with the absence of a
license, that if you give someone a software application that they are
allowed to run it. However, that is about as far as you can assume.
The receiver has no right to use any part of the source-code they may
or may not see (this is protected under copyright - the author* of the
source-code of an app is the copyright holder) in any way. So being
able to see source code does not imply a right of use, modification,
distribution or indeed anything. Indeed - even the right to run
received software is necessarily a given (just an implied right, else
why would you send someone it?) - this is why you should always attach
a license to all software you distribute it, explaining the allowed
bounds of use by the receiver.

Of course, the commercial version has password protection built-in, so
you can hide the source of your commercial apps from prying eyes to
give you a level of physical protection; and not just legal. (You have
the legal protection, regardless).

Warmest Regards,

Mark.

* It is really important to note that in the UK, and most other
countries, if you write code during periods of time you are being paid
for by your employer, then the copyright is implicitly owned by the
company *and not* you. Consulting work is a little more grey - which
is why it is important that you agree the terms of copyright ownership
as part of the contract discussion. Typically this is structured as
'the copyright of code specific to the client project is owned by the
client' but 'any library code not specific to the client which the
consultant has built up to enable her/him to do his work is licensed
under a perpetual license to the client'. Of course, this kind of
thing very much depends on the client - a client is perfectly within
their rights to ask that all code in a project is copyright them...
However, then it is just a question of cost - i.e. if they can afford
to pay for that to be the case!


--
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: Web vs Native (was Re: HTML5 limitations?)

[Mark Waddingham via use-livecode]

On 2017-07-26 23:06, hh via use-livecode wrote:

There are, sadly, still very basic things missing, which make the
HTML5 standalone
builder, TMHO, not yet ready for "beta"-state.


Well - yes - the 'beta' state as I mentioned was a slip (mainly in that 
we don't do 'beta' in our dev process as I explained).


However, there is one VERY important point I do need to make. It is easy 
to get hang up on saying 'oh the HTML5 engine doesn't do this, and oh it 
doesn't do that' - and this might well be true. *However* the only 
important metric in this regard is - does it allow a suitable percentage 
of LiveCode stacks which exist *right now* to run in the browser 
unchanged.


The problem here is that this is quite subjective - it largely depends 
on HOW you code and use LiveCode (remember my analogy of LiveCode and 
the elephant and the blind men). One thing you have pointed out is that 
'the mouse' function does not work. It does not, this is true - however, 
for every person who ever uses 'the mouse' function I can be absolutely 
sure there are probably AT LEAST 2 who do not. This is true of all 
LiveCode features to a greater or lesser degree.


Jacque (for example), clearly has an app that she would really like to 
work in the HTML5 engine. I'd really like this too. Now, I know Jacque 
quite well, I also know her coding style quite well and the way she uses 
LiveCode to solve problems. The app she is talking about should be the 
bread-and-butter of the HTML5 engine however I'm sure it does use a 
number of features which are not the easiest to get working on that 
platform (because I know a bit of Jacque's thought process). Overall, 
without looking at the code in more detail I can't really say how far we 
are from being able to allow it to run well on that platform without 
significant changes. (It might be it is almost there, it might be a very 
long way - but just FOR THAT SPECIFIC app).


In contrast, I've spent a fair bit of time with David Simpson here at 
FileMaker DevCon. Whilst chatting about HTML5 engine, David happened to 
mention that his largest product works perfectly in the current HTML5 
engine - WITH NO CODE CHANGES. This product has (if memory serves me 
correctly) in excess of 100,000 lines of code.


So PLEASE remember, we all have a different view of the elephant. Just 
because something might not yet have reached the point of intersection 
with our OWN view, it does not mean that it has not completely covered 
the view of others. Utility is in the eye of the beholder, and whilst 
our goal is to have the ability to take any LiveCode stack and have it 
run in the browser with no code changes let us not think that just 
because that is not true, it is not actually REALLY useful for many 
cases RIGHT NOW.


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

[Mark Waddingham via use-livecode]

On 2017-07-29 21:00, Mark Wieder via use-livecode wrote:

Yeah. That's what I was trying to say.


I know - I just thought I'd take the opportunity to be a little more 
blunt about it since you gave me the hook to do so - i.e. gitter is not 
a route to get direct tech support from our engineers :)


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: Compiling LiveCode on Sierra

[Mark Waddingham via use-livecode]

On 2017-07-29 23:00, Monte Goulding via use-livecode wrote:

Ah, yes, it doesn’t do anything if the sdk is already linked in.
There’s a few things I’d like to change about that script. One is it
should link in any SDKs that are in the cache or found in the other
xcode app bundles rather than just the specific list. At the moment
it’s really annoying that for develop-8.1 you need 10.8 but for
develop you need 10.9 but the script doesn’t do both on either branch
so you end up having to modify the script before you run it. Every
time I run it I think I really should fix this but what I’m actually
meant to be doing that day always makes me forget about it until the
next time ;-)


Completely unrelated to the SDK thing, but it is worth mentioning (as 
Brian obviously also noticed issues with develop-8.1)...


If you are building from source keep an entirely separate clone for 
develop-8.1 and develop - don't switch within them to branches of the 
opposite base as you'll end up getting funky errors whilst building 
quite a lot.


We changed the way prebuilts work on develop compared to develop-8.1 - 
and the two methods don't get along very well (at all, really!)


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: Compiling LiveCode on Sierra

[Mark Waddingham via use-livecode]

On 2017-07-29 23:10, Monte Goulding via use-livecode wrote:

Hmm… I don’t do that and I seem to get along ok. Indeed in the newer
versions of Xcode I can witch branches then regenerate the config and
Xcode is fine with that.


Interesting - maybe something subtle has changed in recent months which 
means the problem no longer exists - mine is a rather 'brute force' 
approach.


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: Sluggish on Mobile Device

[Mark Waddingham via use-livecode]

On 2017-07-30 02:35, J. Landman Gay via use-livecode wrote:

Isn't this the "datagrid scrolling" issue we just funded? The layout
has groups inside a container group.


No - not quite.

From what Dan said - he has a *fixed* layout - i.e. a group with 200 
subgroups. Todd has used this approach very effectively (I'm sure he'll 
be more than happy to talk about it... Assuming I understood what he 
did, based on a phone call he, Kevin and I had recently).


The DataGrid is a dynamic beast - so the currently acceleratedRendering 
mode is not sufficient.


The DataGrid2 FE was two-fold:

  1) Add the ability to have objects nested arbitrarily deep within 
'container' groups which have their own scrolling, static or dynamic 
layerMode (all non-top-level objects are static at the moment, 
regardless of what you tell them).


  2) Add features to the DataGrid to allow the left/right swiping 
behavior and main UI features you see in iOS scrollers (which, whilst 
not quite the same as Android - have dominated the mobile UI world for 
many types of list-based UI).


So if you have a completely static scrolling group (i.e. one you can 
layout 'ahead of time' or build 'ahead of time') which can fit within a 
groups 32k co-ord width/height limit - then acceleratedRendering will do 
you just fine as it is.


However, if you have a dynamic scrolling group - one which is composed 
of potentially 'infinite' numbers of objects (well, not infinite, but 
backed by a datasource which can serve arbitrary numbers of line items) 
then you need DG2.


The former works for fixed sets of data (I've seen things like Tourist 
information apps and such which use this approach - the data is fixed at 
the point of build and/or data download). However, it doesn't work for 
things like a mail app or contacts DB - where the number of things you 
want to scroll is essentially unbounded.


Of course the fundamental addition to DataGrid will allow far more. 
General compound LiveCode Script controls (which the DG is) can leverage 
it too. For example, you could build a sprite canvas (in LiveCode 
Script). Pretty much anything where you want to group (and clip) a 
collection of dynamic layers (e.g. sprites) and whizz them around at 
virtually no re-rendering cost (which is essentially what happens in 
UIDataView, you can indepdently, smoothly move each line item left and 
right). There's a whole list of things we could do in the future - 
although the next logical step is a bit of a jump implementation-wise as 
the small-tiled nature of accelRender mode is great for scrolling, but 
less great for allowing arbitrary 'free' transformations. However, lets 
get DG2 done first, and see how people get on with that. This time I 
won't make the same mistake I made when we shipped acceleratedRendering 
mode - I'll make sure we document it very clearly to ensure that 
everybody can learn how to use it effectively.


Hope this clears things up!

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: Sluggish on Mobile Device

[Mark Waddingham via use-livecode]

On 2017-07-30 05:43, J. Landman Gay via use-livecode wrote:

There may be a minor difference when acceleratedRendering is on, but
not enough to really help much. I'll see if I can extract a group.
It's one from Swami's project, built dynamically, and all the images
are referenced, so it isn't as easy as just copying a card.

Would referenced images rather than imported images make a difference?


They shouldn't do - no.

It sounds like *something* in the group structure is causing 
accelRendering not to be effective (although I'm not sure what from the 
description). Are there any scripts running?


In the first instance, just the group structure would do - if we have 
trouble reproducing the problem we can come back to you for a more 
faithful reproduction.


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: Web vs Native (was Re: HTML5 limitations?)

[Mark Waddingham via use-livecode]

On 2017-07-29 13:10, Jonathan Lynch via use-livecode wrote:

So... if we use the wait command, and deploy to HTML5, the engine
converts it to JavaScript with extra functions because the engine
added in asynchronous timeouts? And you preserve all the variable
values of the source LC script across these multiple functions?


Yes - that is essentially the 'asyncify' transformation as pertains to 
'leaf' functions (those which call no other wait calling functions).



This was the easy solution?


Easy is always a comparative assertion (there's a reason I always say: 
'easy', for some definition of 'easy').



Either I am misunderstanding, or the concept of what is difficult in
Scotland is shedloads harder than what we puny Americans think.


Heh - I must confess first thing this morning (6am, after 4 hours sleep 
- I perhaps shouldn't have stayed up until 2am writing that lengthy 
email on this topic to here last night) I honestly couldn't 'parse' that 
sentence. I know get it completely - I must make a mental note to 
perhaps not read and reply to mailing lists until I've been awake for at 
least an hour, and had a suitable amount of coffee :)


Anyway, this thread has now spiralled into a behemoth - so I'm going to 
start a new one on this topic to stop it getting lost in a sea of 
not-quite-related things.


[ Also it gives me something to do whilst flying over the USA - 
currently somewhere between Kansas City and Springfield looking at our 
trajectory (this brings up all kinds of images in my mind - Simpsons and 
Wizard-of-Oz crossover anyone?) ]


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

[Mark Waddingham via use-livecode]

On 2017-07-30 00:53, Monte Goulding via use-livecode wrote:
On 30 Jul 2017, at 8:49 am, Mark Waddingham via use-livecode 
<use-livecode@lists.runrev.com> wrote:


However, the IDE submodule is set to stay (despite various discussions 
about merging it internally - I've always said no, and I'm glad I 
have) - indeed, the fact it is a separate submodule helps to put in 
place a mechanism which ensures we won't have another 8.1.6-rc-2 type 
'balls-up' whilst doing user-testing :)


:-( expect continued internal grumblings on that...


I'd rather suffer internal grumblings from our team due to having to 
have an IDE submodule, than much larger shouts from our users when we 
make an error like we did in 8.1.6-rc-2. I have a thick skin, I can 
happily ignore such grumblings; less so very long, and very valid 
threads on the use-list :)


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: Out of the office

[Mark Waddingham via use-livecode]

On 2017-07-29 09:11, james--- via use-livecode wrote:

Well imagine my surprise to see three (and now four) user list digests
waiting for me this morning.


Hopefully that wasn't entirely down to me - although I did send 30+ 
emails to the use-list yesterday...



Going through them and enjoying Mark Waddingham's answer to questions
as well as to himself I find myself torn between wanting Kevin to send
him out of the office more often (and thus allow him to grace the
lists like today) or get him back there ASAP to continue with the work
(infinite LC, HTML etc.)


Well it has been a most productive trip - I have spoken (and given 
demos) to probably around 100 people; posted far more messages on the 
use-list than usual; just about kept track of what's been going on back 
home (Slack and its bot integrations are great for making you feel in 
touch!); *and* think I've almost solved two problems which have been 
irking me for a very long time... The 'wait' problem and the 'partial 
script compilation' problem (when I say solve here, I mean concretely in 
the context of our source-base - which is always an entirely different 
kettle of fish from solving such things abstractly).


Moreover, thus far I seem to have completely escaped jet-lag - although 
I'm probably setting myself up for a fall in saying that... I'm 
currently flying what is generally considered to be the worst way - 
east...


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: CEF Browser - what is wrong with my script

[Mark Waddingham via use-livecode]

On 2017-07-30 00:44, Matthias Rebbe via use-livecode wrote:

stack "Untitled 1": execution error at line n/a (External handler
execution error: creation failed) near "creation failed"
Am i missing something?


It might be a bug - there's been a fair amount of churn in CEF stuff in 
recent versions so we might have missed something with regards 
revBrowserCEF.


Is there any reason you are using revBrowser rather than the browser 
widget?


If there is then please let us know asap (file a bug) so we can fix it.

The fact is that revBrowser is on the verge of being deprecated and then 
quickly axed (for a number of reasons).


[ For existing projects, this isn't really a problem - its an external 
so current built versions will work for some time to come - and we'll 
make sure the S/B still plays nicely with it as it requires some special 
fu to get to work - it would be better if we weren't having to support 
two variants of the same rather complicated thing, and people didn't 
start using it 'by mistake' because they hadn't discovered the widget ].


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: CEF Browser - what is wrong with my script

[Mark Waddingham via use-livecode]

On 2017-07-30 01:06, Matthias Rebbe via use-livecode wrote:

Mark,

I cannot use the widget because of bug #20200.


I was hoping you were going to say 'because I hadn't thought to' 
(although, I must confess that was a fanciful notion, having observed 
your attention to detail over the years).



If we can expect a fix for 20200 then there would be no need for a
bug report for the browser external.


Please do report a bug about the browser external, we haven't officially 
deprecated it yet, so still need to support it.



Or is it more realistic that if i report it as a bug that  the browser
external is fixed earlier than bug 20200?


I suspect we will actually fix 20200 first (if only because it is 
probably a couple of hours work, rather than a day) or at the same time 
- the less 'new' projects which use revBrowser the better; but on the 
other hand we have to keep supporting use of revBrowser until it is 
replaceable.


A classic chicken-and-egg scenario.

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: Sluggish on Mobile Device

[Mark Waddingham via use-livecode]

H - do you notice a difference between accelrender on and off on android? 
If you can copy the group onto a bare stack as is and file it with a bug report 
we can take a look. That case should work well so there might be something 
specific going on in that case.

Warmest Regards,

Mark.

Sent from my iPhone

> On 29 Jul 2017, at 23:17, J. Landman Gay via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> 
>> On 7/29/17 8:07 PM, Mark Waddingham via use-livecode wrote:
>> So if you have a completely static scrolling group (i.e. one you can layout 
>> 'ahead of time' or build 'ahead of time') which can fit within a groups 32k 
>> co-ord width/height limit - then acceleratedRendering will do you just fine 
>> as it is.
> 
> I guess I misunderstood then. I have a fixed number of static groups inside a 
> scrolling container group and even with acceleratedRendering turned on, 
> scrolling is not smooth -- though it seems to be mostly an Android issue. The 
> only way I can get it to work is to have a single scrolling group with loose 
> controls inside it (no sub-groups.) I was thinking the Datagrid FE would fix 
> that.
> 
> -- 
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Wait, the problem, and why it is important to solve

[Mark Waddingham via use-livecode]

So LiveCode has long has this feature called 'wait' - it is one of those 
seemingly innocuous things which, from the surface seems simple (it 
allows you to wait for something - it's great when syntax is aptly 
named!) however it is perhaps one of the deepest language features we 
have.


I think there is some confusion (or puzzlement) as to why I am a little 
hung up on it because, on the whole, the 'wait' command is not actually 
seen in script that much. Certainly it is part of some people's coding 
style (the one thing I love about LiveCode is that it promotes a very 
pluralistic style to solving programming problems), but on the whole 
many of us rarely if ever use it. Well, we *think* we don't use it.


The thing is that 'wait' is such an important feature to LiveCode that 
many pieces of syntax use it without you knowing! The pure mathematician 
in my likes classifying and counting things (hey its what we do!), so 
here is a reasonably complete list of the places the engine uses it 
(this list is alphabetic by source-file in the engine order):


   - it is used to provide the flash of the menu when a menu accelerator 
key is pressed


   - it is used to wait for uses of shell() to send back any data so it 
can be accumulated for return


   - it is used to wait for a return value from sending an AppleEvent on 
Mac (send and request)


   - *it is used to implement 'wait for/until/while ...' (kinda obvious, 
but hey, I was trying to be semi-complete ;))*


   - it is used to implement 'read ... with timeout' forms

   - it is used to wait for process death when you do 'kill'

   - *it is used to wait between beeps when you do 'beep '*

   - *it is used to moderate the speed of 'drag from x to y'*

   - *it is used to moderate the speed of 'type STRING '*

   - *it is used to moderate the time between mouseDown and mouseUp when 
doing 'click at'*


   - *it is used to wait whilst a non without-waiting form of 'move' is 
invoked*


   - it is used in the mobile browser control to wait for JavaScript 
evaluation to finish


   - it is used to wait for mobile calendar UI modal panes to return

   - it is used to wait for mobile photo taking panes to return

   - it is used to wait for mobile contact UI modal panes to return

   - it is used to wait for mobile datetime/option picker modal panes to 
return


   - it is used to wait for mobile compose mail UI modal panes to return

   - it is used to wait for mobile media picker UI modal panes to return

   - it is used to wait for mobile fullscreen videos to finish

   - it is used to wait for mobile text message UI modal panes to return

   - it is used to wait inbetween vibrations when you use 'iphoneVibrate 
'


   - *it is used to wait between frames for visual effects / 
transitions*


   - it is used in all forms of blocking socket commands (open, read, 
write etc.)


   - it is used to wait for blocking DNS resolution to finish*

   - *it is used to wait for 'modal ' to finish (by closing the 
stack)*


   - *it is used (in libURL) to wait for evaluation of 'url ' to 
finish*


   - *it is used (in libURL) to wait for 'post to url ' to finish*

   - *it is used to wait for 'popup widget' to finish*

   - it is used by various other things in externals, and widgets and 
libraries to implement things which need to wait for something or some 
time in order to have something to return


Phew! The ones surrounded by '*' are ones which would make some sense to 
have working in HTML5. Almost all of these can be rendered in a form 
without 'wait', they just end up being *slightly* less useful or easy to 
use (e.g. get url -> load url, always use 'move without waiting', etc.).


So, first thing to point out, even without 'wait', if we manage to 
implement all the existing things which make sense in the HTML5 engine, 
'greenfield' (new projects) will work fine (as you avoid the things 
which don't work in HTML5), and a reasonable number of existing projects 
(particularly ones which are already written to use 'load url' rather 
than 'get url') will also work. However, there will still be a 
substantial number of existing projects which will not, without 
significant code changes.


One of the things we pride ourselves on is that (on the whole) an app 
written on one platform will work, largely unchanged on all the others 
(particularly if platform-specific features are avoided). However, we 
can't really keep that mantra, if something such as 'wait' is abandoned 
because it is deemed 'too hard to implement'. It means for any project 
targetting HTML5, you have to write in a different style, and avoid a 
reasonable number of features that many use day-to-day.


Now, if these features were 'just' things like 'drag' or 'click' or pick 
any specific (non-general language feature) that we have things wouldn't 
be too bad. However, 'wait' is a different kettle of fish altogether.


Wait is essentially LiveCode's implementation of 'async' - this is 
something that 

Doing user testing in a risk free way (Re: gitter)

[Mark Waddingham via use-livecode]

On 2017-07-30 01:04, Monte Goulding via use-livecode wrote:

I’m actually not sure I see the connection between the ide submodule
and the 8.1.6-rc-2.


Heh - the connection is indirect, however it is definitely there!

**The goal:

We want to do A/B testing on LiveCode's 'first run' experience. This 
experience has to go from finding the site, all the way through to 
downloading, installing, activating and actually using the product to 
ensure the data that we get is of the highest, and most useful quality. 
The experience any new user (who is being used as a guinea pig) has to 
be indistinguishable from all other new user's except for the specific 
test flow they have been allocated to.


**The problem:

Iteration on develop branch is too slow and we can't guarantee with a 
high degree of confidence that any one DP would be in any way suitable 
for a brand new user to use. (We still reserve the right to make 
absolutely blooping mistakes in develop DPs - obviously we try not to, 
but we need to be able to test out invasive changes somewhere, and that 
is where we currently can!).


We have a well-defined and tightly controlled process for our 
maintenance branch. It is really important that this is kept as it is, 
and it is definitely *not* the place to do any sort of testing of any 
features whatsoever.


For A/B testing to work, tests need to be able to be rolled out quickly, 
iterated quickly, and pulled quickly if they are unsuccessful, or 
indeed, ill-posed.


**The primary observation:

A/B testing is centered around the outermost, user-visible parts of any 
release. Specifically, the IDE and supporting materials. Any engine work 
that might be required will either be new (internal) additions to 
support user-visible work or bug fixes (almost always the latter).


**The proposed solution:

All A/B tests are built *upon* but not *into* the maintenance builds.

If a specific test *requires* a bug fix, it will be placed in first RC 
of the next maintenance build. If this means a specific test has to be 
deferred a short while it can be deployed then that is what must happen. 
(We have plenty of tests we could run, after all - it is not like we are 
going to run out anytime soon).


If a specific test *requires* an internal engine addition to achieve, 
then suitable analysis will be done to make sure it can and does have 
zero impact on the potential stability of a maintenance build. 
Basically, these things are constrained to internal features which are 
entirely 'bolted' on to the existing engine and have no interoperation 
with the existing code and ideally such things would be a widget/library 
or a similar extrinsic addition.


A test will be created by making a fork of the target maintenance 
release branch in the IDE repository. All work for the specific test 
happens on this branch. All active test branches are kept up to date, by 
merging progress of the underlying maintenance branch/release branch 
(e.g. develop-8.1 or release-8.1.7) into them.


Tests are not built into the maintenance releases - the entire IDE 
bundle for that test will be uploaded as a separate archive.


When a new user who is being put through a test generates a license, the 
license will be marked with the name of the test.


When the user activates and launches the IDE for the first time, the 
appropriate test (IDE) archive will be downloaded and *that* version of 
the IDE will be launched, rather than the one built into the release.


If a test is successful, it will be merged into the next *suitable* 
version.


For small entirely first-run related things this might well be a 
maintenance release (e.g. new first run tutorials, new materials, new 
default preferences for first-run users).


For larger things (such as autocomplete or handler lists) we will use a 
bump in *middle* version number of semver, and use a DP release to make 
sure we got it absolutely right.


Importantly the latter has no impact on what new users see. We can merge 
all successful tests into all future tests so we our test profiles build 
on what we have done before. i.e. New users will see the combined set of 
successful tests; whilst existing users will be able to help us finesse 
them and ensure that they are as good as they can be before appearing in 
a minor version update; rather than a maintenance update.


If a test is unsuccessful, the test just gets deleted, the code for it 
is never merged (but of course, we'll keep the code - it might be 
something we might want to test again in the future).


**Why it works:

The issue which occurred with 8.1.6-rc-2 was due to the fact we were 
iterating on the actual releases which existing users rely on. This 
approach means that existing users will not see, nor even have the code 
in their system for any of the tests which we run. We can keep the 
strict process for maintenance releases we have always had, whilst still 
using them to iterate rapidly in the first-run A/B testing side.


**What 

Re: gitter

[Mark Waddingham via use-livecode]

On 2017-07-29 22:51, Monte Goulding via use-livecode wrote:

As we get more contributors gitter will become more active and you
will be able to answer many of the questions for each other. There’s
little point expecting a great deal of chatter if there’s only half a
dozen people outside the company that have built livecode from source.
FWIW I have it on my phone and open on my desktop so I get
notifications and respond if I know the answer. Usually it’s “Have you
updated submodules?” ;-)


Its not just on Gitter that sentence gets uttered a lot - it also occurs 
frequently on our internal Slack dev channels!


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

[Mark Waddingham via use-livecode]

On 2017-07-30 00:10, Mark Wieder via use-livecode wrote:

Have I mentioned lately how much I hate submodules?


Have I mentioned lately how much I hate submodules? ;)

Actually, submodules actually do their job really quite well. They 
aren't ideal, but they do enforce modularity (hence the name ;)). We 
just need to get round to sorting out some tooling (local shell scripts 
/ git hooks) to help make sure they aren't quite so easy to forget about 
syncing properly.


That being said we are very gradually working towards eliminating the 
third-party submodule.


However, the IDE submodule is set to stay (despite various discussions 
about merging it internally - I've always said no, and I'm glad I have) 
- indeed, the fact it is a separate submodule helps to put in place a 
mechanism which ensures we won't have another 8.1.6-rc-2 type 'balls-up' 
whilst doing user-testing :)


[ Something which is also on my list to post on - you're vehemence on 
the subject which I must confess I cannot in anyway disagree with made 
me come up with a solution to the problem - necessity being the mother 
of invention and all! ]


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: CEF Browser - what is wrong with my script

[Mark Waddingham via use-livecode]

The solution here is to use revBrowserOpen.

I missed the fact this is on macOS. We removed CEF on Mac in 8, as it was not 
possible to use CEF on Mac as a slave (for technical reasons).

The system web view on Mac is still WebKit based so they are very similar.

Sorry for the confusion!

Mark.

Sent from my iPhone

> On 29 Jul 2017, at 19:06, Matthias Rebbe via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> 
> Mark,
> 
> I cannot use the widget because of bug #20200.
> 
> If we can expect a fix for 20200 then there would be no need for a  bug 
> report for the browser external.
> 
> Or is it more realistic that if i report it as a bug that  the browser 
> external is fixed earlier than bug 20200?
> 
> 
> Matthias Rebbe
> +49 5741 31
> ‌matthiasrebbe.eu <http://matthiasrebbe.eu/>‌
> 
>> Am 30.07.2017 um 00:57 schrieb Mark Waddingham via use-livecode 
>> <use-livecode@lists.runrev.com <mailto:use-livecode@lists.runrev.com>>:
>> 
>> On 2017-07-30 00:44, Matthias Rebbe via use-livecode wrote:
>>> stack "Untitled 1": execution error at line n/a (External handler
>>> execution error: creation failed) near "creation failed"
>>> Am i missing something?
>> 
>> It might be a bug - there's been a fair amount of churn in CEF stuff in 
>> recent versions so we might have missed something with regards revBrowserCEF.
>> 
>> Is there any reason you are using revBrowser rather than the browser widget?
>> 
>> If there is then please let us know asap (file a bug) so we can fix it.
>> 
>> The fact is that revBrowser is on the verge of being deprecated and then 
>> quickly axed (for a number of reasons).
>> 
>> [ For existing projects, this isn't really a problem - its an external so 
>> current built versions will work for some time to come - and we'll make sure 
>> the S/B still plays nicely with it as it requires some special fu to get to 
>> work - it would be better if we weren't having to support two variants of 
>> the same rather complicated thing, and people didn't start using it 'by 
>> mistake' because they hadn't discovered the widget ].
>> 
>> Warmest Regards,
>> 
>> Mark.
>> 
>> -- 
>> Mark Waddingham ~ m...@livecode.com <mailto:m...@livecode.com> ~ 
>> http://www.livecode.com/ <http://www.livecode.com/>
>> LiveCode: Everyone can create apps
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com <mailto:use-livecode@lists.runrev.com>
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: CEF Browser - what is wrong with my script

[Mark Waddingham via use-livecode]

Yes please do - also maybe mention we should make revBrowserOpenCEF throw a 
more appropriate error in macOS.

General advice on Mac use open, on win/Linux use openCef. This will give you 
reasonably consistent environments on all three desktop platforms.

Mark.

Sent from my iPhone

> On 30 Jul 2017, at 05:10, Matthias Rebbe via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> 
> The dictionary in 8 and 9 shows CEF as available for Win and Mac. So i will 
> at least file a report about that.
> 
> 
> 
> 
> Matthias Rebbe
> +49 5741 31
> ‌matthiasrebbe.eu <http://matthiasrebbe.eu/>‌
> 
>> Am 30.07.2017 um 10:20 schrieb Mark Waddingham via use-livecode 
>> <use-livecode@lists.runrev.com <mailto:use-livecode@lists.runrev.com>>:
>> 
>> The solution here is to use revBrowserOpen.
>> 
>> I missed the fact this is on macOS. We removed CEF on Mac in 8, as it was 
>> not possible to use CEF on Mac as a slave (for technical reasons).
>> 
>> The system web view on Mac is still WebKit based so they are very similar.
>> 
>> Sorry for the confusion!
>> 
>> Mark.
>> 
>> Sent from my iPhone
>> 
>>> On 29 Jul 2017, at 19:06, Matthias Rebbe via use-livecode 
>>> <use-livecode@lists.runrev.com <mailto:use-livecode@lists.runrev.com>> 
>>> wrote:
>>> 
>>> Mark,
>>> 
>>> I cannot use the widget because of bug #20200.
>>> 
>>> If we can expect a fix for 20200 then there would be no need for a  bug 
>>> report for the browser external.
>>> 
>>> Or is it more realistic that if i report it as a bug that  the browser 
>>> external is fixed earlier than bug 20200?
>>> 
>>> 
>>> Matthias Rebbe
>>> +49 5741 31
>>> ‌matthiasrebbe.eu <http://matthiasrebbe.eu/> <http://matthiasrebbe.eu/ 
>>> <http://matthiasrebbe.eu/>>‌
>>> 
>>>> Am 30.07.2017 um 00:57 schrieb Mark Waddingham via use-livecode 
>>>> <use-livecode@lists.runrev.com 
>>>> <mailto:use-livecode@lists.runrev.com><mailto:use-livecode@lists.runrev.com
>>>>  <mailto:use-livecode@lists.runrev.com>>>:
>>>> 
>>>> On 2017-07-30 00:44, Matthias Rebbe via use-livecode wrote:
>>>>> stack "Untitled 1": execution error at line n/a (External handler
>>>>> execution error: creation failed) near "creation failed"
>>>>> Am i missing something?
>>>> 
>>>> It might be a bug - there's been a fair amount of churn in CEF stuff in 
>>>> recent versions so we might have missed something with regards 
>>>> revBrowserCEF.
>>>> 
>>>> Is there any reason you are using revBrowser rather than the browser 
>>>> widget?
>>>> 
>>>> If there is then please let us know asap (file a bug) so we can fix it.
>>>> 
>>>> The fact is that revBrowser is on the verge of being deprecated and then 
>>>> quickly axed (for a number of reasons).
>>>> 
>>>> [ For existing projects, this isn't really a problem - its an external so 
>>>> current built versions will work for some time to come - and we'll make 
>>>> sure the S/B still plays nicely with it as it requires some special fu to 
>>>> get to work - it would be better if we weren't having to support two 
>>>> variants of the same rather complicated thing, and people didn't start 
>>>> using it 'by mistake' because they hadn't discovered the widget ].
>>>> 
>>>> Warmest Regards,
>>>> 
>>>> Mark.
>>>> 
>>>> -- 
>>>> Mark Waddingham ~ m...@livecode.com <mailto:m...@livecode.com> 
>>>> <mailto:m...@livecode.com <mailto:m...@livecode.com>> ~ 
>>>> http://www.livecode.com/ 
>>>> <http://www.livecode.com/><http://www.livecode.com/ 
>>>> <http://www.livecode.com/>>
>>>> LiveCode: Everyone can create apps
>>>> 
>>>> ___
>>>> use-livecode mailing list
>>>> use-livecode@lists.runrev.com <mailto:use-livecode@lists.runrev.com> 
>>>> <mailto:use-livecode@lists.runrev.com 
>>>> <mailto: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: Wait, the problem, and why it is important to solve

[Mark Waddingham via use-livecode]

On 2017-07-30 11:13, hh via use-livecode wrote:

Wow. You say (using stars) it would make sense to implement wait
in HTML5 for some features that do _not_ (yet) work in HTML5.
Will be a great enhancement side-effect. I look forward to that.


I don't think that was the implication. The implication was that those 
things marked '*' all make sense in HTML5 - i.e. they actually *could* 
be implemented (the other things are mainly mobile related things which 
make no sense). The further point I made was that *all* of them are 
useful (if not identical) if wait does not work.


i.e. We get a more effective HTML5 engine by implementing them even if 
we don't have wait.


Ergo, the HTML5 engine gets even better when we do have wait - in terms 
of ability to use code without modification.



Peter-B already implemented wait in 2015, see bug #16076.
This caused an _additional_ slow down by a factor of 16 that was
*overall*, i.e. also in handlers not containing any form of wait.


Indeed - hence the paragraph in one of my previous emails where I 
stated:


"The alternative - emterpreter - works perfectly but (as anyone who used 
the early wait-supporting versions will know) is wy too slow 
to be viable. Not an ideal situation, to say the least."


Emterpreter (due to the way things are structured in the C++ engine) is 
an all or nothing thing. It makes little difference whether things call 
wait or not.


Also to actually determine this 'calls wait' / 'doesn't call wait' 
attribute requires a level of abstract analysis of script which would 
essentially mean we were performing asyncification anyway. So that is 
what we might as well do, and not pay the cost of emterpretation at all.



We had since then, not counting browser improvements, a speed up
in the HTML5 engine by a factor of up to 8. So "wait" would cause
in sum (better: in product) a slowdown by a factor of at least 2.


Well, compared to now perhaps.

I'd be wary of using such 'approximation' math on things like this. Just 
because we have numbers for certain combinations, it does not mean you 
can just recombine them with other assumptions (we don't know that the 
actual performance metrics can be added or multiplied either 
associatively or distributively).


The only way to know what the speed of a certain combination of 
implementation strategies and execution environments is to actually run 
performance tests.



This is at about the same factor as with RaspberryPiB. RaspberryPi3
has a slow down factor of at about 10.


I'm not sure relating this to RaspPi is useful. The reason is that if I 
am wanting to move my Desktop app (Mac, Windows, Linux) app to HTML5 
then I'd want the performance in the browser to be within a reasonable 
distance of that when on the Desktop.


Comparing different platforms (which are slower due to hardware 
implementation - slower memory buses, in particular) isn't all that 
helpful in determining the veracity of the HTML5 engine's performance.



So the move of the HTML5 engine to WebAssembly may be a necessary
condition?


WASM will likely make a significant difference to size and startup time. 
Performance, is probably more going to be in the 10-15% range. However, 
that is not a number to be relied upon. The only way to find out is to 
test and benchmark.


All I'm really saying, speculating based on the numbers we have, or 
against other (completely different) platforms isn't going to give us 
much, if any insight. The only thing we can do is try, measure and 
iterate. Then try, measure and iterate again.


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

[Mark Waddingham via use-livecode]

Indeed - and (if I remember correctly) - one purpose of devils advocate is to 
ensure the other side justifies its case 'sufficiently' (for some definition of 
sufficiently - usually a great deal harder when pedanticism kicks in!).

I'm off to have another G!

Warmest Regards,

Mark.

Sent from my iPhone

> On 2 Aug 2017, at 23:29, Richmond Mathewson via use-livecode 
>  wrote:
> 
> There are one or two people around here who probably don't know what a 
> *devil's advocate* is . . .
> 
> Off to polish my horns.
> 
> 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


___
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: Hackintosh

[Mark Waddingham via use-livecode]

Sorry - release the source-code of things you write in LiveCode you distribute 
to others.

Warmest Regards,

Mark.

Sent from my iPhone

> On 3 Aug 2017, at 00:21, Mark Waddingham via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> 
> Just to pay reference to the comment about LiveCode - I missed it the first 
> time around...
> 
> We (LiveCode Ltd.) did not 'give away' LiveCode. We released it under a 
> software license that has strings.
> 
> The GPL requires (subject to interpretation by lawyers - and a court of law) 
> you to also release your source code of the things you write in LiveCode.
> 
> There's no such thing as a free lunch - there's always some sort of payment 
> somewhere - even if that payment is 'for the good of all' rather than in any 
> form of 'currently understood currency'.
> 
> Warmest Regards,
> 
> Mark.
> 
> Sent from my iPhone
> 
>> On 2 Aug 2017, at 23:24, Richmond Mathewson via use-livecode 
>> <use-livecode@lists.runrev.com> wrote:
>> 
>> 
>> 
>>> On 8/3/17 12:03 am, Richard Gaskin via use-livecode wrote:
>>> Richmond Mathewson wrote:
>>> 
>>>> No, I don't think we have to respect Apple's policy at all.
>>> 
>>> A similar view might ask whether the DevaWriter license terms need to be 
>>> respected, or LiveCode Ltd.'s, or Stephen King's, or the protections 
>>> afforded any creator of an original work.
>>> 
>> 
>> 
>> LOL.
>> 
>> I have just changed my Devawriter licensing system so that each 
>> instantiation of it that I sell is tied to the MAC address of
>> an individual computer. Therefore there is nothing to respect, a chain is a 
>> chain, and if someone manages to spoof Mac Addresses
>> on a large scale to use my program the fact that they would go to that 
>> trouble proves it's a program worth having!
>> 
>> I have made my "licensing" system as hard as I can: I'm sure it can be 
>> broken: whether it is worth going to that bother remains to be seen;
>> after all you can have a site licence for 10 machines at $200.
>> 
>> If I really wanted to make "my fortune" programming computers I wouldn't be 
>> tinkering around in our spare bedroom at 55 anyway . . .
>> 
>> The reason I have changed it is because I know of someone who purchased my 
>> Devawriter 3 years ago and now has copies all over the place:
>> my bad, I should have taken a bit more trouble: at least some people are 
>> finally getting their heads around "Sanskrit As it Should Be":
>> 
>> http://andregarzia.on-rev.com/richmond/home.html
>> 
>> Apple's policy is "just" Apple trying something on. A EULA is NOT a legally 
>> binding agreement: if you choose to abide by it you
>> can feel "awfully" moral, much in the same sort of way I haven't fathered 27 
>> children with 27 mothers simultaneously (which, oddly
>> enough, is not illegal) makes me fell that I'm slightly more moral in some 
>> respects.
>> 
>> I bought a 10 year-old Intel iMac about 8 months ago. I had the system 
>> install disks from a Mac laptop of my wife's that went bang about 3 years 
>> ago.
>> Now I was probably breaking some sort of agreement by using those disks to 
>> get my iMac going - possibly not "meant" to install on another Mac other
>> than the one they were bought with. Morally, as the one the disks came with 
>> a dead computer I could see nothing wrong with using them to get
>> another, similar computer running; especially as I could find no way to 
>> purchase Mac OS Lion disks from Apple.
>> 
>> LiveCode give away the Open Source version of their product. . .
>> 
>> Stephen King . . . well, if you really have to read his books you can borrow 
>> them from the library . . . I read 3 of them in about 1984.
>> 
>> Love, 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
> 
> 
> ___
> 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: Hackintosh

[Mark Waddingham via use-livecode]

Whilst that may be true - a significant part of LiveCode's business comes from 
the US... As does our support for Apple devices.

Of course, Apple probably don't care (why would they? Hackintoshes are not 
Macs). However, Apple did think it reasonable to outlaw anything other than 
Obj-C and JS (through the WebView) apps on iOS for a while. So let's not 
presume we can 'read' intent of such 'powerful' entities.

As I said there are other forums for discussing hackintosh creation - it is 
definitely off topic for this forum; so beyond a few links of elsewhere to look 
(which our helpful users have already supplied) I think this discussion has 
probably done all it needs to, hasn't it?

At the end of the day, unless you believe in anarchy (which you might, I have 
no issue with that - particularly if you can explain to me how that works in 
practice ;)), some observance of rules is required - and there is a difference 
between discussing the rules (e.g. the meta level) which can be most 
enlightening; and the discussing of how to break them (which often gets quite 
boring in any specific case after a while - especially as plenty of other 
people have discussed them at length and in detail elsewhere) ;)

Caution is sometimes the greatest approach anyone can take, if you actually 
want to effect change.

Warmest Regards,

Mark.

Sent from my iPhone

> On 2 Aug 2017, at 22:07, Richmond Mathewson via use-livecode 
>  wrote:
> 
> Apple's EULA may not actually be legal or legally enforcable in a large 
> number of territories
> where this Use-List is read.
> 
> Just seen Tim Cook "sucking the kneecaps" of China's one-party state's 
> leaders and blethering anent "adhering to the law" re VPNs.
> Nothing makes me despise anyone more than trying to justify adherence to laws 
> of a totalitarian state.
> 
> Sometimes the law is an ass; as has been demonstrated by sensible lawyers 
> time out of mind.
> 
> This kind of reaction makes me want to scream "Richard Stallman" in a very 
> trenchant tones.
> 
> I also don't see how discussing how one might go about something has to be 
> seen as a demonstration of an intention
> to carry out those actions . . .
> 
> . . . but then I don't live in a paranoid police state (Bulgaria had a patch 
> of that and gave it up, just as some, previously open, states
> started on an opposite journey).
> 
> Of course in "parts west" they don't even need the full apparatus of a 
> police-state any more as they have, through political
> correctness  effectively erected what Mao Zedong ( a well-known advocate of 
> democracy) termed "a dictatorship of the
> proletariat" where the people police themselves.
> 
> Anyway we don't need to worry about that when we have our own folk attempting 
> to impose censorship nearer to home.
> 
> I have come up against this attitude in several places recently, the idea 
> that a place is "safe and friendly" only when we are not allowed to
> express certain opinions.
> 
> That is the beginning of the end of proper, robust discussion and healthy 
> creativity.
> 
> Richmond.
> 
>> On 8/2/17 6:56 pm, Richard Gaskin via use-livecode wrote:
>> We have a great community, having earned a reputation for providing a safe, 
>> friendly environment for learning LiveCode.
>> 
>> With that in mind, please remember that Apple's EULA for macOS requires that 
>> it be run only on "Apple-branded computers".
>> 
>> Discussions of using VMs on Mac hosts is great, useful for testing our apps 
>> on multiple OS versions.
>> 
>> But we probably don't want to have discussions of violating Apple's 
>> copyright as part of this community's permanent public archive.
>> 
>> There are other venues where such discussion can take place.  Here in this 
>> official LiveCode support venue, it may be better to follow the guidelines 
>> used for the Forums, in which we avoid discussions which may be construed as 
>> encouraging illegal activity.
>> 
>> Forum Guidelines
>> 
>> 
>> -- 
>> Richard Gaskin
>> LiveCode Community Liaison
>> rich...@livecode.org
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: Hackintosh

[Mark Waddingham via use-livecode]

Just to pay reference to the comment about LiveCode - I missed it the first 
time around...

We (LiveCode Ltd.) did not 'give away' LiveCode. We released it under a 
software license that has strings.

The GPL requires (subject to interpretation by lawyers - and a court of law) 
you to also release your source code of the things you write in LiveCode.

There's no such thing as a free lunch - there's always some sort of payment 
somewhere - even if that payment is 'for the good of all' rather than in any 
form of 'currently understood currency'.

Warmest Regards,

Mark.

Sent from my iPhone

> On 2 Aug 2017, at 23:24, Richmond Mathewson via use-livecode 
>  wrote:
> 
> 
> 
>> On 8/3/17 12:03 am, Richard Gaskin via use-livecode wrote:
>> Richmond Mathewson wrote:
>> 
>> > No, I don't think we have to respect Apple's policy at all.
>> 
>> A similar view might ask whether the DevaWriter license terms need to be 
>> respected, or LiveCode Ltd.'s, or Stephen King's, or the protections 
>> afforded any creator of an original work.
>> 
> 
> 
> LOL.
> 
> I have just changed my Devawriter licensing system so that each instantiation 
> of it that I sell is tied to the MAC address of
> an individual computer. Therefore there is nothing to respect, a chain is a 
> chain, and if someone manages to spoof Mac Addresses
> on a large scale to use my program the fact that they would go to that 
> trouble proves it's a program worth having!
> 
> I have made my "licensing" system as hard as I can: I'm sure it can be 
> broken: whether it is worth going to that bother remains to be seen;
> after all you can have a site licence for 10 machines at $200.
> 
> If I really wanted to make "my fortune" programming computers I wouldn't be 
> tinkering around in our spare bedroom at 55 anyway . . .
> 
> The reason I have changed it is because I know of someone who purchased my 
> Devawriter 3 years ago and now has copies all over the place:
> my bad, I should have taken a bit more trouble: at least some people are 
> finally getting their heads around "Sanskrit As it Should Be":
> 
> http://andregarzia.on-rev.com/richmond/home.html
> 
> Apple's policy is "just" Apple trying something on. A EULA is NOT a legally 
> binding agreement: if you choose to abide by it you
> can feel "awfully" moral, much in the same sort of way I haven't fathered 27 
> children with 27 mothers simultaneously (which, oddly
> enough, is not illegal) makes me fell that I'm slightly more moral in some 
> respects.
> 
> I bought a 10 year-old Intel iMac about 8 months ago. I had the system 
> install disks from a Mac laptop of my wife's that went bang about 3 years ago.
> Now I was probably breaking some sort of agreement by using those disks to 
> get my iMac going - possibly not "meant" to install on another Mac other
> than the one they were bought with. Morally, as the one the disks came with a 
> dead computer I could see nothing wrong with using them to get
> another, similar computer running; especially as I could find no way to 
> purchase Mac OS Lion disks from Apple.
> 
> LiveCode give away the Open Source version of their product. . .
> 
> Stephen King . . . well, if you really have to read his books you can borrow 
> them from the library . . . I read 3 of them in about 1984.
> 
> Love, 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


___
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: Points of Graphic Oval

[Mark Waddingham via use-livecode]

File an enhancement - it's not something we have gotten round to doing yet but 
a 'flattened path' api was always on the cards to do but we hadn't gotten 
around to it yet.

Warmest Regards,

Mark.

P.S. 'Flattening' is the term used to describe the process of turning paths 
into sequences of line segments.

Sent from my iPhone

> On 2 Aug 2017, at 23:24, hh via use-livecode  
> wrote:
> 
> I have already done what you describe in a HTML5 standalone for displaying
> progress along a Bezier curve, using LC Script only.
> http://hh.on-rev.com/html5/hhProgressHTML5_2-8.0.2X.html
> 
> And it is done for all LC's SVG icons using the jquery-drawsvg plugin in
> a browser widget (incl. optional affine transformations of the SVG icons).
> http://livecodeshare.runrev.com/stack/833/AutoDraw_SVGicon
> 
> What I meant is to have such a tricky translation of model elements
> (arc, curve etc.) of an SVG path into an appropriate points-only path
> in LCB? Perhaps one could use parts of LC-Ian's SVG work for that?
> 
>> Mark wrote:
>> Heh - sometimes it takes a relative tome of justification to arrive at a
>> simple explanation!
>> 
>> However the beauty of Bézier curves is that arcs are just a small subset
>> of what they can represent 'well enough'.
>> 
>> For moving along an arbitrary (Bézier - you can represent a straight line
>> segment as one trivially) path, what you actually need is first the length
>> of the path (annoyingly not a representable function - iirc) and a parametric
>> form of a Bézier curve (which is how they are best expressed).
>> 
>> Then to step along the path at fixed distance at each step you use
>> f(n * fixeddist / length) (here f is the parametric form of the Bézier
>> - returning a 2d point). You'd need some adjustment (+/- 1 pix) to account
>> for rounding error - but I think the idea is sound.
> 
> ___
> 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: Made with . . .

[Mark Waddingham via use-livecode]

I'm not sure the learning of C and its relatively difficulty was the point here.

Find me a book on C which teaches you how to create a window, show a button and 
have that button pop up a modal dialog which says 'hello world' on Android, 
HTML5, iOS, Linux, Mac and Windows then *that* would be interesting (if only to 
show how ridiculous using C to write user facing applications is!)

Oh, and also, they have to be 'bare OS metal' - ie from scratch - only core 
libraries on all platforms allowed (so no wxWidgets, QT or whatever!) and also 
they need to teach enough to be able to get you to understand enough to do a 
great deal more than that trivial case.

Only when you consider it from that point of view does the true power - 
relative to C - of LiveCode (and very high level languages) become apparent.

Ah - and you'll also need to write the (shell) scripts to build your app and 
run it!

Having books which 'teach you' a language is one thing - having books which 
could teach you to do what LiveCode does for you would actually be a library. 
LiveCode does a lot of stuff for you so you can actually focus on what you are 
wanting to achieve.

After all there's a huge gap between being able to write English; and being 
able to write a novel in English which someone would want to buy.

Warmest Regards,

Mark.

P.S. I didn't write the above to dispute your point - merely to use it to hint 
at a deeper truth... Which Richmond's pupil realised and hence bought 
chocolates as a result :)

Sent from my iPhone

> On 3 Aug 2017, at 00:43, Alejandro Tejada via use-livecode 
>  wrote:
> 
> Hi Richmond,
> 
> Some years ago, Alex Tweedly recommended this book
> to learn C. I bought this for US$ 30 on Amazon:
> https://www.amazon.com/Illustrating-C-Ansi-Iso-Version/dp/0521468213
> 
> More recently, another developer recommended this 2015 book:
> https://www.amazon.com/Programming-Absolute-Beginners-Guide-3rd/dp/0789751984/
> 
> Al
> ___
> 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 get the value of a custom property if the name of the cProperty is in a variable?

[Mark Waddingham via use-livecode]

You can put the name of the property into a local var and use that (unless I 
misunderstood the problem).

Ali's suggestion is however the very pragmatic one - there are always going to 
be cases where var names might conflict with other things 'in context' and 
require disambiguation. (Although even that doesn't work in some cases - 
consider 'tExt' - when you have case insensitivity and no need to explicitly 
declare variables).

Of course, if you'd like to file a bug report / enhancement about being able to 
do 'the "mycustompropname" of ... - then that is probably the 'future' much 
better solution :)

Warmest Regards,

Mark.

Sent from my iPhone

> On 2 Aug 2017, at 21:56, Dr. Hawkins via use-livecode 
>  wrote:
> 
> On Wed, Aug 2, 2017 at 10:25 AM, Klaus major-k via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> 
>> answer the tMyVar of this cd
>> 
> 
> This is an area that is awkward in live code.
> 
> The use of unquoted literals for this is inconsistent with most of live
> code (but quoting would be inconsistent with the built in properties, so .
> . .)
> 
> I have "loops" like
> 
> repeat for each word someProp in "theOnlyPropInTheList"
> 
> set the someProp of someControl to myVal
> 
> end repeat
> 
> 
> If you have a variable whose name is the same as the property, there does
> does not seem to be a good solution.
> -- 
> Dr. Richard E. Hawkins, Esq.
> (702) 508-8462
> ___
> 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: Made with . . .

[Mark Waddingham via use-livecode]

Well they do say 'out of the mouths of babes'.

At the very least it helps us to reinforce the fact that 'we' have a purpose :)

Warmest Regards,

Mark.

Sent from my iPhone

> On 2 Aug 2017, at 23:33, Richmond Mathewson via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> 
> That's a very good explanation,
> 
> Thank you very much indeed.
> 
> I had a "small problem" with a teenager in my programming classes who asked:
> 
> "If Livecode is written using C++ why don't we just bypass Livecode 
> completely?"
> 
> Which prove that his English is up to a high standard :)
> 
> I found a book in a junk shop that was an introduction to C++ and sent him 
> home with it and asked
> him to start teaching himself C++ and to duplicate the simplest exercise 
> stacks we were doing in the classes.
> 
> On the Monday he turned up with a big box of chocolates for me and an apology.
> 
> I will be forever grateful to the Livecode team that they have saved me from 
> having to learn C++.
> 
> Richmond.
> 
>> On 8/2/17 9:07 pm, Mark Waddingham via use-livecode wrote:
>> Increasingly less - and in contrast the amount that could be done in LC 
>> instead of C++ continues to increase (far more slowly than I'd like - but 
>> hey, if wishes were horses...)
>> 
>> Indeed, a lot of the 'heavy lifting' seen in the engine comes down to either 
>> the core abstractions which the LiveCode script language requires (i.e. the 
>> VM), direct access to C exposed APIs, or for speed.
>> 
>> For example a lot of 'compound' operations such as the set operation 
>> commands can be implemented in LCS - indeed it is a very readable way to 
>> define their behaviour - but become far more effective for large arrays if 
>> done in C++ (i.e. for optimisation purposes). Although that is largely 
>> because we don't have a native code compiler for LCS.
>> 
>> LCB has started to provide more of what is needed to 'get away from C++' - 
>> admittedly its performance is not great as yet, but for its current purposes 
>> it is more than sufficient. In particular, UI elements generally require 
>> little 'hardcore' performance - just rendering and property marshalling; 
>> similarly, wrapping system and third-party APIs to the level where they are 
>> 'more natural' in LCS mainly just requires appropriate type mapping and 
>> indexing of objects (enter LCB).
>> 
>> LiveCode Script is a complete programming language in its own right; it 
>> lacks direct access to third-party APIs certainly, however it is perhaps 
>> surprising how much outside of user interaction related tasks require that. 
>> Even in 7+, it's speed is perfectly reasonable for 'reasonably sized' 
>> computational tasks (for certain types of thing it is actually much more 
>> memory efficient due to copy on write being used for values - which increase 
>> the memory size of tasks, if not speed).
>> 
>> As a mode of expression of algorithms, it perhaps start to approach Knuth's 
>> idea of 'literate programming' *without* using a blended typesetting + code 
>> approach (which is how TeX and MetaFont are written, for example).
>> 
>> So, if for that reason alone there's rarely harm in writing something in LCS 
>> first, and *then* taking to rewrite critical parts in a lower level language 
>> if required for speed reasons.
>> 
>> Warmest Regards,
>> 
>> Mark.
>> 
>> Sent from my iPhone
>> 
>>> On 2 Aug 2017, at 13:50, Klaus major-k via use-livecode 
>>> <use-livecode@lists.runrev.com> wrote:
>>> 
>>> Hi Richmond,
>>> 
>>>> Am 02.08.2017 um 13:43 schrieb Richmond Mathewson via use-livecode 
>>>> <use-livecode@lists.runrev.com>:
>>>> 
>>>> " remember that LC is made with LC, so everything in the IDE is a stack 
>>>> resp. scripted and can be modified!"
>>>> recently claimed by someone elsewhere [Hi, Klaus :) ]
>>> hi mate! :-)
>>> 
>>>> BUT: it that really true?
>>>> Why do I have a funny feeling that a lot of the "heavy lifting" is done 
>>>> with C++ ?
>>> Yes, that is true, except for the engine and its functionality which is 
>>> made with C++ or whatever.
>>> 
>>>> Richmond.
>>> Best
>>> 
>>> Klaus
>>> 
>>> --
>>> Klaus Major
>>> http://www.major-k.de
>>> kl...@major-k.de
>>> 
>>> 
>>> ___
>>> use-livecode mailing list
&

Re: Hackintosh

[Mark Waddingham via use-livecode]

Indeed - freedom of speech and all.

However, I have to side with Richard here - this forum is about LiveCode and 
not anything else. Sure we have 'OT' discussions now and again but generally 
they either 'peter out' or are suggested that this is not the appropriate forum 
(the latter in this case).

Whilst I appreciate Apple's policy maybe irksome to many, it works for them so 
we do have to respect that.

Warmest Regards,

Mark.

Sent from my iPhone

> On 2 Aug 2017, at 18:32, Richard Gaskin via use-livecode 
>  wrote:
> 
> Bob Sneidar wrote:
> 
> >> On Aug 2, 2017, at 08:56 , Richard Gaskin wrote:
> >>
> >> But we probably don't want to have discussions of violating Apple's
> >> copyright as part of this community's permanent public archive.
> >
> > Not to start a riot or anything, but I wasn't aware discussions could
> > violate a copyright.
> 
> I wrote "...discussions OF..."
> 
> See also: bikeshedding
> 
> -- 
> 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: Points of Graphic Oval

[Mark Waddingham via use-livecode]

A general arc (which an oval is an example of) is represented in LiveCode like 
elsewhere as a maximum of four cubic Bézier curves.

These Bézier curves are then flattened to polynomials relative to a notion of 
'flatness' - which means that the you iterate (using the de Casteljeu method) 
until you reach a point that the maximum perpendicular distance that the curve 
lies from the line segment (imagine drawing lines at 90deg up from the line to 
hit the arc - you are looking for the longest or equal, which always exists). 

Basically if you set flatness to be 0.5 pixels then the human eye cannot 
distinguish the difference (when taking into account the visual quantisation 
that occurs - resolution of the screen and antialiasing more than makes up for 
it).

So, at the level of the graphic object it is a true arc, at the level of 
instructing the graphics library it is a Bézier approximation but at the level 
of working out what pixels to render it is a polygon.

Whether that means the engine works in true ovals or not, I'll leave to 
whatever existential proclivities you hold ;)

Warmest Regards,

Mark.

Sent from my iPhone

> On 2 Aug 2017, at 05:51, Sannyasin Brahmanathaswami via use-livecode 
>  wrote:
> 
> Sequently found "effectivePoints" and used that and it works fine on Mobile.
> 
> But this thread became something more, it became about generating a polygon 
> object that "looks like" an oval. 
> 
> But is an oval such an object at all?
> 
> Mark Wieder via use-livecode"  behalf of use-livecode@lists.runrev.com> wrote:
> 
>How many points would you guess are in an oval?
> 
> BR Ahhh, programmatically perhaps it has no "points" as such… being a single 
> continuous line shaped only by its changing arc-radius values.?
> i.e.  a mystic conundrum: "infinite number of points and not points at all"
> 
> SCOTT  Rossi wrote:
> 
> You can use the effectivePoints to get the points of any graphic shape, but 
> depending on the size, your oval may produce too many points.
> 
> In any event, your source oval doesn't need to be perfect. If you reference a 
> "decent" number of points along the shape of the oval, your image will have 
> the appearance of moving along an elliptical path.
> 
> 
> BR: But using "The effectivePoints" seems to work as if there were no points 
> (as such), but only a contiguous line… 
> 
> Which takes us back to Marks first question…"how many points in an oval"   
> which I will re cast as: 
> 
> At the depths of the LC engine imaging algorithms… is a circle or oval made 
> up of points at all?
> 
> br
> 
> 
> 
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
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: Made with . . .

[Mark Waddingham via use-livecode]

Hah! I missed the IDE bit - 99.99% of the IDE is written in LCS (some widgets 
in LCB).

Pretty much the only bits which aren't are done script introspection features 
(e.g. revAvailableHandlers), the core standalone building part (which fettles 
with executables on each platform) and the mechanism it uses for detecting 
changes in properties.

The latter couldn't be done in LCS as it stands - the rest probably could but 
would be too slow for large scripts and message paths (revAvailableHandlers); 
or where having direct access to the system headers and such in their natural 
state made the code 'easier' to write (although not necessarily on the 
readability / maintenance) side of things.

Warmest Regards,

Mark.

Sent from my iPhone

> On 2 Aug 2017, at 13:43, Richmond Mathewson via use-livecode 
>  wrote:
> 
> " remember that LC is made with LC, so everything in the IDE is a stack resp. 
> scripted and can be modified!"
> 
> recently claimed by someone elsewhere [Hi, Klaus :) ]
> 
> BUT: it that really true?
> 
> Why do I have a funny feeling that a lot of the "heavy lifting" is done with 
> C++ ?
> 
> 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


___
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: Points of Graphic Oval

[Mark Waddingham via use-livecode]

Bézier curves are a polynomial - usually quadratic (2nd degree) or cubic (3rd 
degree) but the model extends to arbitrary order.

With four cubic Bézier curves (so 8 quadratic) you can make an exceptionally 
good approximation to an oval - but it is not exact.

Indeed (anyone who might have a better memory of this than I, please correct 
me) from memory, to accurately represent an oval (or arc - any general planar 
quardratic shape written naturally as a quadratic polynomial in TWO not ONE 
variable - eg x^2 + y^2 = 0) you would require an infinite single variate 
polynomial (and I think this would only work for a quadrant too). This can be 
seen from the fact that to compute cos/sin/tan (which are the mathematical 
primitives in some sense acting here) require a 'taylor' expansion which is an 
infinite polynomial sequence (with order tending to infinity) which converges 
to the required value.

Enough abstract math over - here the only 'issue' with the effectivePoints for 
the purpose described is that it does not take into account radius to adjust 
the number of generated points - hence the 'too many points at certain sizes' 
problem.

Now this is not an error or bug - I remember Mark (not me!) submitting that PR 
and reviewing it - what he did was entirely reasonable given that there were no 
apparent use-cases at the time, and without use-case then you can only make 
things generally useful, and not specifically useful. (After all 360 is a key 
number as it is the number of DEGREES in a full circle - so is something which 
is understandable to most).

Indeed, what is actually needed here is to approximate the required arc based 
on a notion of 'flatness' and 'pixel positioning'. Meaning that you want the 
line segments to have minimal maximal (that is not a typo a for once!) 
perpendicular distance from the true curve, and still be large enough to sit at 
pixel positions so as not to cause jitter (a slightly subjective idea).

I strongly suspect Malte's animationEngine does this 'correctly' for this case 
as it was designed with this kind of use case in mind.

Anyway I know this thread has gone on a bit and perhaps the above is not really 
useful anymore but I thought it (1) might be interesting and (2) might perhaps 
encourage the more mathematically minded among us (and yes, I have one or two 
specific people in mind!) to maybe find a spare moment to 'do the math' and 
write up how it should work.

And yes, there are those on the team who probably could - but I think all of us 
have long sinced 'hung up' our mathematician's cowels and are now focused on 
more concrete day to day endeavours... However, that focus does perhaps mean we 
could happily implement whatever correct (relative to this use case - which is 
probably the singularly most important one!) solutions appear.

Warmest Regards,

Mark.

Sent from my iPhone

> On 31 Jul 2017, at 22:23, Bob Sneidar via use-livecode 
>  wrote:
> 
> Both are part of the joke. I shouldn't explain it because that is like 
> disecting a frog. The frog dies and nobody cares. :-)
> 
> But geometrically in any line there are an infinite number of points, because 
> a point is an infinitely small coordinate. That's if by point you mean 
> literally points in the geometrical sense. But if you mean how many pixels on 
> a given display to create a visually smooth curve, well that is another 
> matter. And if by points you meant anchors in a vector based drawing program, 
> why typically 4 points, although 3 will do, I just don't know how perfect the 
> circle can be and I thing an oval would require 4. 
> 
> See? The frog died and nobody cares! 
> 
> Bob S
> 
> 
>>> On Jul 31, 2017, at 08:34 , hh via use-livecode 
>>>  wrote:
>>> 
>>> Bob S. wrote:
>>> By strict geometry, an infinite amount. Using Bezier, 4. :-)
>> 
>> Just because I am curious which part of your statement is the joke:
>> 
>> How do you define "strict geometry"?
>> And what is an "infinite amount"?
> 
> 
> ___
> 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: Hackintosh

[Mark Waddingham via use-livecode]

Heh - I'm apologise for being slightly glib - and definitely off-topic there.

Although, I'd point out (because I'm a very pedantic person at times) - that 
there are always rules we can't change such as the rules of nature (e.g. 
Physics - although the rules evolve as we 'understand more' - or Mathematics 
(at least within zermelo-fraenkel set theory which is the predominant 
interpretation).

And this is 'me' speaking not CTO of LiveCode - which might be an important 
point I should make (perhaps I need an IANAL type acronym for that ;)).

In all good faith,

Mark.

Sent from my iPhone

> On 2 Aug 2017, at 22:52, Erik Beugelaar - Solidit via use-livecode 
> <use-livecode@lists.runrev.com> wrote:
> 
> Dear Mark,
> 
> " At the end of the day, unless you believe in anarchy (which you might, I
> have no issue with that - particularly if you can explain to me how that
> works in practice ;)), some observance of rules is required - and there is a
> difference between discussing the rules (e.g. the meta level) which can be
> most enlightening; and the discussing of how to break them (which often gets
> quite boring in any specific case after a while - especially as plenty of
> other people have discussed them at length and in detail elsewhere) ;)"
> 
> Mark, It works in practice, please read:
> 
> https://www.youtube.com/watch?v=MPojltjv4M0
> https://www.youtube.com/watch?v=MPojltjv4M0
> 
> Off topic but to me of interest.
> 
> All the best,
> Erik
> 
> 
> 
> 
> -Original Message-
> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
> Of Mark Waddingham via use-livecode
> Sent: Wednesday, August 2, 2017 10:34 PM
> To: How to use LiveCode <use-livecode@lists.runrev.com>
> Cc: Mark Waddingham <m...@livecode.com>
> Subject: Re: Hackintosh
> 
> Whilst that may be true - a significant part of LiveCode's business comes
> from the US... As does our support for Apple devices.
> 
> Of course, Apple probably don't care (why would they? Hackintoshes are not
> Macs). However, Apple did think it reasonable to outlaw anything other than
> Obj-C and JS (through the WebView) apps on iOS for a while. So let's not
> presume we can 'read' intent of such 'powerful' entities.
> 
> As I said there are other forums for discussing hackintosh creation - it is
> definitely off topic for this forum; so beyond a few links of elsewhere to
> look (which our helpful users have already supplied) I think this discussion
> has probably done all it needs to, hasn't it?
> 
> At the end of the day, unless you believe in anarchy (which you might, I
> have no issue with that - particularly if you can explain to me how that
> works in practice ;)), some observance of rules is required - and there is a
> difference between discussing the rules (e.g. the meta level) which can be
> most enlightening; and the discussing of how to break them (which often gets
> quite boring in any specific case after a while - especially as plenty of
> other people have discussed them at length and in detail elsewhere) ;)
> 
> Caution is sometimes the greatest approach anyone can take, if you actually
> want to effect change.
> 
> Warmest Regards,
> 
> Mark.
> 
> Sent from my iPhone
> 
>> On 2 Aug 2017, at 22:07, Richmond Mathewson via use-livecode
> <use-livecode@lists.runrev.com> wrote:
>> 
>> Apple's EULA may not actually be legal or legally enforcable in a 
>> large number of territories where this Use-List is read.
>> 
>> Just seen Tim Cook "sucking the kneecaps" of China's one-party state's
> leaders and blethering anent "adhering to the law" re VPNs.
>> Nothing makes me despise anyone more than trying to justify adherence to
> laws of a totalitarian state.
>> 
>> Sometimes the law is an ass; as has been demonstrated by sensible lawyers
> time out of mind.
>> 
>> This kind of reaction makes me want to scream "Richard Stallman" in a very
> trenchant tones.
>> 
>> I also don't see how discussing how one might go about something has 
>> to be seen as a demonstration of an intention to carry out those actions .
> . .
>> 
>> . . . but then I don't live in a paranoid police state (Bulgaria had a 
>> patch of that and gave it up, just as some, previously open, states
> started on an opposite journey).
>> 
>> Of course in "parts west" they don't even need the full apparatus of a 
>> police-state any more as they have, through political correctness  
>> effectively erected what Mao Zedong ( a well-known advocate of democracy)
> termed "a dictatorship of the proletariat" where the people police
> themselves.
>> 
>

Re: Hackintosh

[Mark Waddingham via use-livecode]

Richard just said what I was thinking but much much better!

Warmest Regards,

Mark.

Sent from my iPhone

> On 2 Aug 2017, at 23:03, Richard Gaskin via use-livecode 
>  wrote:
> 
> Richmond Mathewson wrote:
> 
> > No, I don't think we have to respect Apple's policy at all.
> 
> A similar view might ask whether the DevaWriter license terms need to be 
> respected, or LiveCode Ltd.'s, or Stephen King's, or the protections afforded 
> any creator of an original work.
> 
> Many of us here earn our living through intellectual property.  So 
> personally, I feel it reflects well on our community to respect other 
> people's IP as we ask them to respect ours.
> 
> Whether any given action may be a violation of law is a matter for attorneys. 
>  Encouraging mutual respect seems simply a matter of good taste.
> 
> FWIW I have no personal opinion about hackintoshes one way or another, and I 
> think Apple might do its platform a favor by considering licensing the OS on 
> other hardware (though unlike before, this time do it earnestly so it might 
> actually stand a a chance of working).
> 
> But Apple has made their intentions clear, and it is their right to apply any 
> terms they feel are in the interest of their shareholders. Those who want a 
> different license can choose software governed by a license they like.
> 
> 
> > But I do tend to agree that any discussion of anything that might rub
> > Apple up the wrong way if it is to take place on this use-list should
> > only be in relation to LiveCode.
> 
> That's pretty much all the Forum Guidelines ask for, and all that Mark 
> Waddingham has asked for here.
> 
> It's not even about Apple really, but about creating an environment that 
> clearly respects the efforts of developers and the rights afforded them under 
> the Berne agreement.
> 
> -- 
> Richard Gaskin
> LiveCode Community Liaison
> rich...@livecode.org
> 
> 
> ___
> 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: merge() only evaluating first expression?

[Mark Waddingham via use-livecode]

If you evaluate the second expression in that merge in the context (i.e. Same 
handler) of the call to merge does it throw an error?

If a compile or runtime error occurs in any [[ ... ]] bracketed part of the 
merge string, then it gets rendered literally and not the value of it (as it 
can't be evaluated).

Warmest Regards,

Mark.

Sent from my iPhone

> On 2 Aug 2017, at 21:02, Dr. Hawkins via use-livecode 
>  wrote:
> 
> Before I file the bug report, I want to check that this is an error (or am
> I missing something
> 
> I have the custom property  blElQry with value
> 
> SELECT kywd FROM [[dhtbl_dat]] WHERE kywd LIKE '[[the leadFdWc of srcRw]]%'
> ESCAPE '\' ORDER BY kywd
> 
> However, the single quote appears to be blocking evaluation of the second
> bracketed term; the first is correctly taken from a variable, but the
> second retains that literal text.
> 
> I don't  believe that LiveCode should be treating a single-quoted range as
> a literal in merge(), should it?
> 
> For that matter, nothing in the dictionary suggests that a double-quoted
> string would be exempt from valuation.
> -- 
> Dr. Richard E. Hawkins, Esq.
> (702) 508-8462
> ___
> 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: Points of Graphic Oval

[Mark Waddingham via use-livecode]

Heh - sometimes it takes a relative tome of justification to arrive at a simple 
explanation!

However the beauty of Bézier curves is that arcs are just a small subset of 
what they can represent 'well enough'.

For moving along an arbitrary (Bézier - you can represent a straight line 
segment as one trivially) path, what you actually need is first the length of 
the path (annoyingly not a representable function - iirc) and a parametric form 
of a Bézier curve (which is how they are best expressed).

Then to step along the path at fixed distance at each step you use f(n * 
fixeddist / length) (here f is the parametric form of the Bézier - returning a 
2d point). You'd need some adjustment (+/- 1 pix) to account for rounding error 
- but I think the idea is sound.

Warmest Regards,

Mark.

Sent from my iPhone

On 2 Aug 2017, at 22:18, hh via use-livecode  
wrote:

>> Mark wrote:
>> So, at the level of the graphic object it is a true arc, at the level of 
>> instructing
>> the graphics library it is a Bézier approximation but at the level of 
>> working out what
>> pixels to render it is a polygon.
> 
> Thanks for arriving from your previous post at this very clear statement.
> You will have to do a lot of such approximations by simple polygons when you 
> implement
> to move along an SVG path for your SVG widget... ;-)
> 
> p.s. The 360 points of Mark are really good enough for very large circles in 
> order to
> move along such points in 2 seconds. These are 3 points per tick!
> ___
> 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: Mark in a kilt...

[Mark Waddingham via use-livecode]

Heh - I'll say one thing for kilts... in the blistering heat of Arizona (I 
think it peaked at 42 Celsius) - it was a lot more comfortable outside than 
shorts or trousers! (The black long sleeved shirt less so - but life's not 
perfect!)

Warmest Regards,

Mark.

Sent from my iPhone

> On 2 Aug 2017, at 21:29, Richmond Mathewson via use-livecode 
>  wrote:
> 
> Would that be Emperor Trump's wall between the United States of America and 
> the United States of Mexico (and Texas),
> or Emperor Hadrian's one between Newcastle and the Solway Firth, Emperor 
> Antoninus' one between Glasgow and the Firth of Forth,
> or the one between command-line languages and object-based ones?
> 
> Were I Emperor kilts would be compulsory all over.
> 
> Richmond.
> 
>> On 8/2/17 4:09 pm, Mike Kerner via use-livecode wrote:
>> were they from north of the wall?
>> 
>> On Tue, Aug 1, 2017 at 10:38 AM, Bob Sneidar via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> 
>>> I used to play marching drums in a Scottish bagpipe band. We were good
>>> too. Won 1st place in the DC 4th of July parade once. We had excellent
>>> instructors.
>>> 
>>> Bob S
>>> 
>>> 
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>> 
>> 
>> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: MouseDown sent to button in group, but MouseUp sent to card

[Mark Waddingham via use-livecode]

Erdős is considered one of the most prolific mathematicians of the 20th century.

His most famous quote is 'a mathematician is a machine for turning coffee into 
theorems'.

He drank a lot of coffee.

He also took a lot of amphetamines.

Warmest Regards,

Mark.

Sent from my iPhone

> On 3 Aug 2017, at 23:23, Bob Sneidar via use-livecode 
>  wrote:
> 
> Now we know how new math came to be. 
> 
> 
>>> On Aug 3, 2017, at 13:53 , Monte Goulding via use-livecode 
>>>  wrote:
>>> 
>>> 
 On 4 Aug 2017, at 6:38 am, hh via use-livecode 
  wrote:
 
 Monte wrote:
 ... G drinking holiday ;-)
>>> 
>>> Practising Geometry & Trigonometry and drinking??
>> 
>> Yeah I know… crazy mathematicians! What can you do.
>> 
>> 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


___
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: Mobile LC Apps Downloading Stacks After installation

[Mark Waddingham via use-livecode]

On 2017-08-11 18:00, Mike Kerner via use-livecode wrote:
That's not what I'm saying.  What I'm saying is while telling everyone 
to
control themselves is good, removing these capabilities from LC is bad, 
so

if the time comes where it is necessary to do something to stop someone
from behaving badly, please make sure we have a switch in place that 
allows

the rest of us to continue as-is.


Hence my comment about 'when being run from an App Store installed 
environment'. It is easy to check if an App is running when installed 
from an AppStore...


Indeed, you have to build such things using a 'distribution profile' 
specific to the store - so any action would be at standalone-build time, 
rather than anywhere else.


To be fair, I don't think it is likely to happen... However, unlikely 
does not mean impossible!


Warmest Regards,

Mark.

P.S. I'd also rather not have to expend the resources doing it - there 
are far better things we could be doing than figuring out ways to turn 
dynamic features into static ones, or reworking stuff so the dynamic 
features could be turned off. I much prefer the 'with great power comes 
great responsibility' approach - i.e. trust!


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