Apple Mac assistance sought

[Hated Moron]

Will anybody with an Apple Mac (and an up-to-date version of Safari) please carry out the following test, it will only take a few seconds.

Click on the two links below, they are both to the Newton's Cradle simulation, but compiled using different versions of Emscripten (EMCC). Here, with an 'Apple Silicon' Mac Mini, Link 1 works perfectly but Link 2 results in occasional 'flashing' (perhaps once a second or so) as if an entirely black frame is being rendered.

Link 1
Link 2

Please report back your results, including what model of Mac it is, either here or to me privately if you prefer.

[Hated Moron]

On 27/02/2023 17:55, Storer, Darren wrote (cross-posted from the Discussion Group):

Link 2 demo is still flashing when run with Safari version 16.3 (18614.4.6.1.6) under macOS Ventura 13.2.1 (Intel MBP 2020, with GPU). There was no flashing observed with either demo using Chrome under either version of macOS.

Thank you, I have forwarded your report to the Emscripten developers.

[Hated Moron]

Thank you, I have forwarded your report to the Emscripten developers.

After much discussion at the Emscripten GitHub project, they seem to have concluded that - although the regression was clearly caused by a change to Emscripten - they can't/won't do anything about it. Their argument seems to be that the change in question was essential and cannot be reverted, so I just have to live with the consequences.

For the time being the only workaround available to me is to build BBC BASIC for SDL 2.0 with an old version of Emscripten. Whilst that solves the 'flashing' problem it introduces other problems, most notably that the version of SDL2_ttf bundled with that old version doesn't support the rendering of complex scripts like Arabic and Thai, and the script.bbc library doesn't work.

So, looking to the future, it would seem I have only two choices: drop support for Safari or drop support for rendering complex scripts in a browser. What are people's views on this?

[Hated Moron]

On 06/03/2023 08:06, Storer, Darren wrote (cross-posted from the Discussion Group):

Although Safari has almost 20% of the global browser user base in 2022 (according to at least one survey), the more significant question seems to be, what percentage of Apple users are likely to be impacted when trying to render in-browser code? To answer this, maybe you have some logs that include the user-agent (UA) string from longer-term accesses of the wasm server.

I don't know; if I do I wouldn't know where to find them! I'm afraid web logs are, for me, just a way of periodically filling my hosting account's disk quota! If you can suggest where I might locate that information (e.g. in cPanel) I'll have a look.

Most Apple users that I know have access to Chrome and Firefox, so from a personal viewpoint, I'd rather see Safari dropped in favour of the support for complex script languages. If the in-browser code could detect the UA string, then an appropriate message could be displayed to advise the use of another browser.

Thank you, that is helpful. I wouldn't know how to detect the browser in the Emscripten-generated code, but if that can be done it would be helpful now in providing a more friendly error in Internet Explorer or iOS browsers (and some embedded browsers) than 'Exception thrown, see JavaScript console'! Can you advise (the makefile is here)?

Am I not right in thinking that having 'access' to Chrome or Firefox isn't a complete solution unless also set as the default browser? For example if one is sent a link to an in-browser BBC BASIC utility in an email, won't that open in your default browser, which might still be Safari?

Another possible counter-argument would be that the in-browser edition already has fundamental limitations, most notably that GCOL 1 (OR plotting) and GCOL 2 (AND plotting) are not supported because WebGL doesn't provide them. So you could argue that an additional limitation unique to the in-browser edition (such as not supporting rendering complex scripts) is also acceptable.

I'm not saying I necessarily think that, just being Devil's advocate.

[Hated Moron]

On 10/03/2023 04:02, Storer, Darren wrote (cross-posted from the Discussion Group):

Apache domain access logs path: /usr/local/apache/domlogs/{DOMAIN}

Using the terminal in cPanel, I can successfully change directory to /usr/local/apache/domlogs but I can't see anything there because everything I do gives "Permission denied":

Code: Select all

[bbcbasi@sv4 domlogs]$ pwd
/usr/local/apache/domlogs
[bbcbasi@sv4 domlogs]$ ls
ls: cannot open directory '.': Permission denied

I can't say I'm particularly surprised because the server is understandably quite tied down. I only got access to a terminal after I requested it, by default even that degree of access isn't permitted.