Re: JSON

2023-08-14 Thread Richmond Mathewson via use-livecode
This has recently been explored across on the forums where I managed to
expose my full level of ignorance on the subject.

Best, Richmond.

On Tue, 15 Aug 2023, 07:59 Tore Nilsen via use-livecode, <
use-livecode@lists.runrev.com> wrote:

> JsonImport will make an array of your JSON data, whereas JsonExport will
> turn your array into JSON data. Not much fiddling there.
>
> Best regards
> Tore Nilsen
>
> > 15. aug. 2023 kl. 02:07 skrev Dar Scott via use-livecode <
> use-livecode@lists.runrev.com>:
> >
> >
> > I’m about write some scripts that fiddle with JSON. I have some old
> stacks of mine about someplace. But, I got to thinking there might be
> something faster about someplace. Ideas?
> >
> > Dar
> > ___
> > 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: JSON

2023-08-14 Thread Tore Nilsen via use-livecode
JsonImport will make an array of your JSON data, whereas JsonExport will turn 
your array into JSON data. Not much fiddling there.

Best regards
Tore Nilsen

> 15. aug. 2023 kl. 02:07 skrev Dar Scott via use-livecode 
> :
> 
> 
> I’m about write some scripts that fiddle with JSON. I have some old stacks of 
> mine about someplace. But, I got to thinking there might be something faster 
> about someplace. Ideas?
> 
> Dar
> ___
> 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


iOS media player

2023-08-14 Thread Andrew at MidWest Coast Media via use-livecode
I have a project that needs updating but mobile media controls have completely 
changed since I last worked on this app. Seems now that the mobile player for 
iOS is a completely transparent rectangle until the user taps on it when 3 
controls appear (rewind 10, play/pause, fast forward 10).

Is there any way to make this overlay appear automatically? Once it appears it 
persists even after updating the media file. It feels like I’m going to have to 
create a skin (WinAMP flashbacks) for the media player that used to have 
standard timeline & playback UI from the OS.

The logical command (in my head at least) was 
mobileControlSet "audioPlayer", "showController", TRUE
but that acts more like a visibility command rather than calling up the 
controls. 

Here is a video showing the player object with a blueBackground and the 
controls appearing only after tapping on the mobile player: 
https://www.dropbox.com/scl/fi/q84nccwrqcct8jsmgwvs0/iOS_player.mp4?rlkey=mhqcuz96z9a88ztldweacdsco=0
 

 

Curious how others have handled this change.

—Andrew Bell
___
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


JSON

2023-08-14 Thread Dar Scott via use-livecode

I’m about write some scripts that fiddle with JSON. I have some old stacks of 
mine about someplace. But, I got to thinking there might be something faster 
about someplace. Ideas?

Dar
___
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 filenames in LC Server

2023-08-14 Thread matthias rebbe via use-livecode
see below...


> Am 14.08.2023 um 13:30 schrieb Mark Waddingham via use-livecode 
> :
> 
> On 2023-08-14 12:12, matthias rebbe via use-livecode wrote:
>> Hi Mark,
>> when i read Neville's post i thought also about normalize, although i really 
>> do not have a clue about the whole unicode stuff, but i remembered that the 
>> standalone builder make use of the normalize function. ;)
>> So i used this script on LC Server to write the seconds to a file containing 
>> an a-umlaut in its name.
>> put  normalizeText("testä.txt", "NFC") into tFile
>> put the seconds into URL ("binfile:")
>> put the result
>> put ""
>> put the files
>> put ""
>> put tFile
>> But that does not work. "The result" returns 'can't open file'.
> 
> Hmmm - I must confess that I misread Neville's post - he did explicitly 
> mention 'creating' files... The normalization would only arise if the file 
> already existed, but the requested (incoming) filename was normalized 
> differently (thus resulting in the file not being found).
> 
> So assuming that the defaultFolder is accessible in your above script (as a 
> read-only folder would also cause the same error) then there does appear to 
> be something up here...
> 

The default folder is accessible. The same script works when the ä is removed  
from the line
put  normalizeText("testä.txt", "NFC") into tFile



> Warmest Regards,
> 
> Mark.
> 
> -- 
> Mark Waddingham ~ m...@livecode.com  ~ 
> http://www.livecode.com/
> LiveCode: Build Amazing Things
> 
> ___
> 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: Linux filenames in LC Server

2023-08-14 Thread Mark Waddingham via use-livecode

On 2023-08-14 12:30, Mark Waddingham via use-livecode wrote:
So assuming that the defaultFolder is accessible in your above script 
(as a read-only folder would also cause the same error) then there does 
appear to be something up here...


Okay so I'm pretty sure the linux server engine is doing the right 
thing.


As mentioned previously, Linux filesystems don't actually care what the 
encoding of a filename is - to linux its just a sequence of bytes


The interpretation is given by the 'locale' settings which are in effect 
for any given program.


So, when you run lc-server from a terminal session directly, its almost 
certainly the case that the LC_ALL and LANG environment variables are 
set to en_US.UTF-8 (or some other language code DOT UTF-8 - it is the 
UTF-8 which is the important bit).


On Linux, a C API nl_langinfo() is used to fetch the encoding to use 
when talking to the system APIs (e.g. filesystem APIs) - this (I 
believe) derives its information from LANG/LC_ALL.


If the latter *are not set* then it will likely default to the 'C' 
locale which has no interpretation of any non-ascii chars, and thus 
attempts to encode/decode utf-8 encoded filenames will fail.


My theory is that these variables are not set in the configuration for 
running CGIs in Apache (or whatever web server is being used in this 
instance).


Digging around it looks like Apache (at least) has a `SetEnv` directive 
which would allow these environment variables to be set, e.g.


  SetEnv LC_ALL en_US.UTF-8
  SetEnv LANG en_US.UTF-8

Although I'm not 100% sure where such things go, perhaps someone more 
conversant with apache config could chime in to suggest.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Build Amazing Things

___
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 filenames in LC Server

2023-08-14 Thread Mark Waddingham via use-livecode

On 2023-08-14 12:12, matthias rebbe via use-livecode wrote:

Hi Mark,

when i read Neville's post i thought also about normalize, although i 
really do not have a clue about the whole unicode stuff, but i 
remembered that the standalone builder make use of the normalize 
function. ;)


So i used this script on LC Server to write the seconds to a file 
containing an a-umlaut in its name.


put  normalizeText("testä.txt", "NFC") into tFile
put the seconds into URL ("binfile:")
put the result
put ""
put the files
put ""
put tFile

But that does not work. "The result" returns 'can't open file'.


Hmmm - I must confess that I misread Neville's post - he did explicitly 
mention 'creating' files... The normalization would only arise if the 
file already existed, but the requested (incoming) filename was 
normalized differently (thus resulting in the file not being found).


So assuming that the defaultFolder is accessible in your above script 
(as a read-only folder would also cause the same error) then there does 
appear to be something up here...


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Build Amazing Things

___
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 filenames in LC Server

2023-08-14 Thread matthias rebbe via use-livecode
Hi Mark,

when i read Neville's post i thought also about normalize, although i really do 
not have a clue about the whole unicode stuff, but i remembered that the 
standalone builder make use of the normalize function. ;)

So i used this script on LC Server to write the seconds to a file containing an 
a-umlaut in its name.

put  normalizeText("testä.txt", "NFC") into tFile
put the seconds into URL ("binfile:")
put the result
put ""
put the files
put ""
put tFile

But that does not work. "The result" returns 'can't open file'. 
As i already wrote i have no clue about unicode so i tried also NFD and also 
the other 2 options, but also w/o success.

Is there something else that  one hast to keep in mind to have success with 
this?


Regards,
Matthias



> Am 14.08.2023 um 12:22 schrieb Mark Waddingham via use-livecode 
> :
> 
> On 2023-08-14 02:45, Neville Smythe via use-livecode wrote:
>> OK, so the macOS *is* using utf-8 for its file names - the [e-acute] in the 
>> filename Carré.txt is rendered with two bytes [C3A9] not the single byte 
>> MacRoman encoding. I got tricked by copying the terminal listing into 
>> another program rather than hex dumping within the terminal, and somewhere 
>> in the process the native encoding was preferred.
>> So one must *not* textEncode a filename to utf-8 before writing a file to 
>> disk, LC deals with the encoding, although you *should” textEncode its 
>> contents.
>> Which leaves the problem of why I can’t get LC Server on Linux to write 
>> non-ascii filenames
> 
> So I suspect the problem here is normalization, rather than the inability of 
> Linux to write non-ascii filenames.
> 
> Characters such as e-acute / e-grave have *two* representations in unicode - 
> the decomposed and composed form.
> 
> The composed form is a direct mapping from the native encodings and is a 
> single codepoint, the decomposed form will be two codepoints - (e, 
> combining-acute/grave)
> 
> Depending on where the string comes from it might either be composed or 
> decomposed - macOS filenames are stored decomposed in the FS, but the 
> higher-level parts of the OS make either form work (in a similar fashion to 
> how macOS filesystems are case-insensitive by default).
> 
> Linux filesystems, however, are both case-sensitive and form-sensitive - a 
> filename must match byte to byte with what it was created with (indeed, linux 
> filesystems care nothing for encodings, they see filenames as a sequence of 
> bytes which are interpreted relative to the user's current locale - the 
> default locale on linux these days is utf-8).
> 
> If your app is managing the files completely on Linux (i.e. it is creating / 
> deleting them and the filenames are not user-editable) then (if this is the 
> caseu) the problem should be fixable by choosing a normalization form when 
> you create / lookup the file - i.e. pass all filenames on the server through 
> `normalizeText(, )` - here you want form to be either "NFC" 
> (composed) or "NFD" (decomposed).
> 
> Warmest Regards,
> 
> Mark.
> 
> P.S. For all the gory details about Unicode normalization forms see - 
> https://unicode.org/reports/tr15/
> 
> -- 
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Build Amazing Things
> 
> ___
> 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: Linux filenames in LC Server

2023-08-14 Thread Mark Waddingham via use-livecode

On 2023-08-14 02:45, Neville Smythe via use-livecode wrote:
OK, so the macOS *is* using utf-8 for its file names - the [e-acute] in 
the filename Carré.txt is rendered with two bytes [C3A9] not the single 
byte MacRoman encoding. I got tricked by copying the terminal listing 
into another program rather than hex dumping within the terminal, and 
somewhere in the process the native encoding was preferred.


So one must *not* textEncode a filename to utf-8 before writing a file 
to disk, LC deals with the encoding, although you *should” textEncode 
its contents.


Which leaves the problem of why I can’t get LC Server on Linux to write 
non-ascii filenames


So I suspect the problem here is normalization, rather than the 
inability of Linux to write non-ascii filenames.


Characters such as e-acute / e-grave have *two* representations in 
unicode - the decomposed and composed form.


The composed form is a direct mapping from the native encodings and is a 
single codepoint, the decomposed form will be two codepoints - (e, 
combining-acute/grave)


Depending on where the string comes from it might either be composed or 
decomposed - macOS filenames are stored decomposed in the FS, but the 
higher-level parts of the OS make either form work (in a similar fashion 
to how macOS filesystems are case-insensitive by default).


Linux filesystems, however, are both case-sensitive and form-sensitive - 
a filename must match byte to byte with what it was created with 
(indeed, linux filesystems care nothing for encodings, they see 
filenames as a sequence of bytes which are interpreted relative to the 
user's current locale - the default locale on linux these days is 
utf-8).


If your app is managing the files completely on Linux (i.e. it is 
creating / deleting them and the filenames are not user-editable) then 
(if this is the caseu) the problem should be fixable by choosing a 
normalization form when you create / lookup the file - i.e. pass all 
filenames on the server through `normalizeText(, )` - here 
you want form to be either "NFC" (composed) or "NFD" (decomposed).


Warmest Regards,

Mark.

P.S. For all the gory details about Unicode normalization forms see - 
https://unicode.org/reports/tr15/


--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Build Amazing Things

___
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: LC 9.6.9 App uses too much memory!

2023-08-14 Thread Mark Waddingham via use-livecode

On 2023-08-13 14:29, harrison--- via use-livecode wrote:

Hi LiveCoders,

Clearly this is a bug in LC 9.6.9, but I don’t know what is causing the 
problem.
I noticed that others in the past have run into a similar problem.  Was 
this

ever reported as a bug?


Could you file a bug report with recipe and attach (or send to 
supp...@livecode.com if its sensitive) the stack and recipe for 
reproducing the problem so we can take a look.


Thanks in advance,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Build Amazing Things

___
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