Ideas from over the fence.

[richmond62]

So, LiveCode have released version 10 beta 8, and:

1. Still no sign of the much vaunted GUI: that has, in fact, been shouted about for about 7-8 years, but was 100% promised for version 10.

But, let that pass . . .

2. Most of the addition seem to be re standalones hived off for Android, iOS, and internet.

The Amazon Web Services library now supports configuring custom endpoints via an optional pEndpoint parameter on the AWSSetCredentials command. This allows the library to be used for any S3 compatible service.

3. There is something I do not completely understand re text:

Text encoding and decoding
New syntax has been added to allow encoding strings to, and from, a variety of different text encodings.
The encode using <text-encoding> statement encodes a string to binary data, and the decode using <text-encoding> statement does the converse. In both cases, how characters
map to bytes is determined by the specified text-encoding :
ascii : the 7-bit ASCII character set
native : the native character set of the platform ( MacRoman on macOS and iOS, Windows-1252 on Windows, and ISO8859-1 on Android, Linux and Web).
utf8 : the utf-8 encoding
utf16 : the utf-16 encoding in the byte order of the platform
utf16le , utf16be : the utf-16 encoding in little-endian and big-endian byte order
respectively
utf32 : the utf-32 encoding in the byte order of the platform
utf32le , utf32be : the utf-32 encoding in little-endian and big-endian byte order
respectively
In cases where characters cannot be encoded into the specified text encoding, the character is
encodedas ?. Example:
encode "lorem ipsum" using utf8
decode the result using utf8 into tFooString

3. Number formatting:

The formatted as number and format as number operations now format numbers in a much more generally useful way.
In general, numbers which require up to 21 digits to display will do so without falling back to scientific notation. In particular, large integers will be formatted as integers.

Not really sure whether that is a particular advantage.

4. Some extremely marginal stuff about literals.

5. New nothing constant

Code: Select all

A new constant nothing has been added which exposes the special value the engine places in variables which have yet to be explicitly given a value.

Pardon me for being "as thick as a brick", but,"SHURELY", a variable that has yet to be explicitly given a value is a bit like those unbaptised babies in Mediaeval Catholic Limbo: "Nuffin".

The nothing value behaves like empty when in string context, and like zero when used in number context.

Gosh: my 'four wheel drive" just developed 2 more gears.
-
Oops: that picture is both scurrilous and totally obscene . . . OK, OK: at about 1 hour and 30 minutes. (NOT for the tinies!)
-
I cannot recommend to everyone too much the educational advantages that may be had from listening and watching High Baroque opera:

https://youtu.be/-z0UIpaKmPU





.

[OpenXTalkPaul]

Most of the addition seem to be re standalones hived off for Android, iOS, and internet.

Most of that list makes me think they're moving towards merging together LCS and LCB.
For example they've added the ability to make constants that are associative array literals, something Extension builder has had.

For another example Extension Builder already has that 'nothing' keyword, which is the equivalent to 'undefined' in, and which is not the same as a variable that evaluates to either an empty string (which is actually "") and does NOT evaluate to the number 0 (zero), which is something. I imagined that "is nothing" should work like in LCB but in a xtalk-scripting context, which would be the equivalent to 'if there is not a' (same thing it means Extension Builder), but your quote there has it so it seems to be exactly the same thing as the 'empty' keyword?

I'm pretty sure that the engine has support for all of those character encodings already. What this indicates is that they're now exposing them to the script interpreter for script authors to use. I have previously made Extension FFI binding strings for these internal engine functions, because I needed to while creating the wrapper for HIDAPI library in order to get correct readable names for attached devices from the library. This was needed because the names may have characters like a manufacturer's registered mark '®' that may not be in the same position (glyph number) in different character encodings (MacRoman, Windows-1252, ISO8859-1, etc.). Some devices I own had some Japanese characters in these strings. Anyway. the point is I could change these functions into non-private handlers and put them into a library module to expose them to use with the script engine if people wanted to use them in their scripts.

I beleive Unicode UTF-32 is about fonts with a MASSIVE amount of glyphs, that have glyphs in slots that need 4-bytes worth of numeric range in order to point to such glyphs.

I didn't think that little-endian/big endian bit was still a relevant unless you're running on PowerPC or dealing with a really old API like Apples CoreMIDI.