External Script Editor

[richmond62]

Frankly, Unicode or Not: it might just be possible you are feeling fairly damned anyway.

ANd, even with my silly BINGO and TAROT I keep turning up "inconveniences" that make me want to stump off for a glass of whisky: which, come to think of things, I shall do right now.

[OpenXTalkPaul]

Yes, I guess that would it 'block' the UI execution thread, however other script execution might still continue, I'm not sure that it would be totally blocking. I would think we would want to stop script execution while we're editing scripts anyway, but that could another problem because the dialog and script editor are built and running as scripts.

FTR,
I'm woke AF, in the sense that today's far-to-middle-right-wingers in the US mean that as a pejorative, in that I don't give a damn about what floats your boat in the bedroom as long as it's consensual adults, I'll use any pronouns makes you happy, and I'm completely against fascist assholes pushing the continued use of revisionist history that pretends our government has never committed any heinous acts against any group of people and further wants to pretend that slavery was about 'states rights' or some kind of job-training program (that "Moms for Liberty" b.s. here in the US turns my stomach, crazy Orwellian times we're living in).

[richmond62]

Every single government everywhere has oppressed people in one way or another, and anyone who pretends otherwise is daft.

Every single person has irrational prejudices: and it is our moral duty to try to overcome them, and as soon as anyone says "I'm not prejudiced" I start feeling queasy.

I particularly admire the government of Benin who have opened a centre to explore and document their people's part in the slave trade.

HOWEVER, I have 2 objections to the 'woke/pc' brigade:

1. I do not believe in either collective or inherited guilt: I am not going to be held responsible for the sins of my ancestors.

I have my own sins to take care of.

2. Critical Race Theory won't stand up to scrutiny.

[tperry2x]

Frankly, Unicode or Not: it might just be possible you are feeling fairly damned anyway.

Well, I'm still not fully recovered from my encounter with the Covid fairy, so that's one way of putting it.

ANd, even with my silly BINGO and TAROT I keep turning up "inconveniences" that make me want to stump off for a glass of whisky: which, come to think of things, I shall do right now.

I'm glad that you do, and that Neville has (with the answer dialog too), as although I grumble and roll my eyes - it's good to get them fixed. Ultimately, I'd rather know about them.

This text strangeness (encoding?) is going to cause issues for the IDE though, as it makes me wonder what external editors will do to the IDE script. Case in point, if you select text from a script editor window of the IDE, and paste into an external text editor - sometimes all you get pasted in is unicode character garbled text. I wonder if allowing external text editors access to editing scripts is going to cause more headaches. But we'll see.

[OpenXTalkPaul]

2. Critical Race Theory won't stand up to scrutiny.

That's debatable I suppose, CRT is after all a legal theory, but as I see it the problem here in the US with 'CRT' is that right-wingers have been purposefully redefined what CRT even is,,, teaching middle school age kids about the 'Trail of Tears' or 'Black Walstreet/Tulsa Race Riots', is NOT CRT, it's teaching history accurately. 'CRT' and 'Woke' have been redefined interchangeably to mean anything that makes conservatives uncomfortable or they don't agree with. Peruse the lists of books proposed for banning by these people from K thru 12 schools and it's quite clear what the goal is suppression of facts and ideas. (I've seen 1984 on the lists).

Anyway, that's off topic politics stuff...

[OpenXTalkPaul]

This text strangeness (encoding?) is going to cause issues for the IDE though, as it makes me wonder what external editors will do to the IDE script. Case in point, if you select text from a script editor window of the IDE, and paste into an external text editor - sometimes all you get pasted in is unicode character garbled text. I wonder if allowing external text editors access to editing scripts is going to cause more headaches. But we'll see.

I think that has more to do with pasteboard allowing for data such as styed text to be transferred in different formats ('plain' text, Rich Text, HTMLText) with encoding (UTF-8, UTF-16, etc.) I don't think it would be a problem with most code editors and text saved out in UTF-8. It already works sort-of with 'script-only' stacks,

[axwald]

Hehe,

All apart from the SQLite bit - I'll steer clear of attempting to handle SQLite databases in the LCC engine entirely, at all costs. [...]

I accept this - getting used to databases takes some time, and I know they look terrifying at first.
But there's a reason God & her dog are using SQLite for prefs and what else. I'd die for a OXT where the dreaded preferences stack would be replaced with a nice, tidy SQLite that never gets corrupted ;-)
Or is there another reason I'm not aware of?

I know what you mean about LCC9 engine. I'd have loved to base OXT on the LCC7 engine instead. Unicode be damned. It's so so much faster than 9 will ever be. Why did LC make a 64-bit version of the v7 engine for Linux, and not do a 64-bit version until v8 on the Mac?

Well, I think LCC7 was already "over the rainbow". The IDE had been hit hard (at least for Win), the overall speed had seriously deteriorated, and the bugs had multiplied. Compared to the last LCC6 versions.

The last versions I'd actually have paid money for was 6.7.10/11, and when I learned about this, it wasn't for sale anymore. What was released after was, in my humble opinion, one pre-beta after another, without any half ways stable release versions (LTS, with backported bug fixes) ever. Nothing that I saw fit to use to deliver my mission-critical commercial software with.
And coding in LC, and selling my work, was until recently my sole source of income - for nearly 10 years.

As you may know I had lobbied for keeping a openSource "LC classic" based on the last 6.7. I even had asked LC Ltd. for an estimate of the costs to port the last 6.7 to 64bit, at least for Android/ Linux/ Win - they didn't even reply (I had some financial background at the time & might have been able to collect a serious sum). Similarly, my corresponding proposal here has been smashed.

Still I wonder if not this "unicode over alles" mentality (well, it was kind of a hype back then) wasn't the last nail for the coffin of XTalk languages in commercially applicable software products (that unfortunately are the sole reliable source of income).

I wonder if anybody (besides Richmond for sure) actually pays for a current LC license + actually uses the unicode features. Maybe it had been better LC Ltd. had just finally improved the field object (for instance, full support for tabular data as well as output according to OS settings) and the still broken font support - this might have been enough.
But I don't really understand the unicode thing (it never bit me, even my japanese customers happily accepted western style output as long as it was correct ...), so I may be blatantly wrong. Educate me then, plz!

'CRT' and 'Woke'

Oh oh. Anyways, reminds me of:

Bishop to Duke: "I'll keep 'em stupid, you keep 'em poor!"
Duke to Bishop: "Nice & thanks, but they keep complaining."
Bishop to Duke: "Then we need help, gimmi a moment, plz!"
HiredMinion to both: "What can I do for you?"
Bishop to HiredMinion : "You keep 'em divided, so I can keep 'em stupid, and he can keep 'em poor!"
HiredMinion to both: "Hehe, easy. I assume it'll pay?"
Bishop & Duke: "Grmml, 10% to you."
HiredMinion to both: "20%!"
Bishop & Duke: "Grmml, 15%."
HiredMinion to both: "Done. They'll be at each others throats in no time. But I need an alias, know me as 'SJW' from now on."
Bishop, Duke, SJW: "*grin*"

[tperry2x]

I accept this - getting used to databases takes some time, and I know they look terrifying at first...
Or is there another reason I'm not aware of?

Mainly it's the engine and IDE's tendancy to drop the SQL connection, and not having a good way to check that the connection is actually still active (unless you try reading from it and receive an error). I've shifted the entire dictionary away from SQL due to many connection errors, invalid SQL requests, and how easy it is to corrupt an SQL database by editing it with various tools. It'll mean that the SQL lookup tables lose their structure and can't be referenced reliably.

I work with mySQL databases a lot in web back-ends, and use them with various other software (with our data manager in my job), however they are prone to corruption - and as they are a central store for sensitive information, it also makes them a vulnerable target for snooping and code injection (as SQL queries can be input, then executed without user knowledge). Not good, so there are lots of reasons I don't like using them.

Aside from the fact that the SQL library in the engine is also currently very out of date too, and itself vulnerable to the same exploits that plague Microsoft dotNet 3.5, but I won't go into that as it's documented in various Microsoft KB articles. It's the same reason I don't advocate using the CEF browser at all. It too is vulnerable to code injection from other processes.

[OpenXTalkPaul]

"and not do a 64-bit version until v8 on the Mac?"
LC CE v8 for macOS was a 'fat' or 'universal' binary with both Intel 32 AND 64bit. But it may have been set to 32bit by default. In the Finder get-info window on certain macOS versions there was a check-box to run such an app in "32bit mode". V8 actually ran well for me on Snow Leopard 10.6 in 64bit mode (which was why I delayed moving on to v9 until I had a mac that could run 10.9 Mavericks+), and v8 improved text processing speed from 7, and it supports Widgets and Library extensions (but sadly not foreign function interface). If I were doing retro-OXT for Mac Snow Leopard I'd use v8.

[tperry2x]

Well, there's some interesting snippets in the release notes PDFs that LC produced:

Note that 7.1.4 is 32-bit only (Snow Leopard was an absolute trooper - could run 32bit, 64bit and PowerPC apps)

Screenshot 2024-12-22 at 20.25.52.png (57.49 KiB) Viewed 1020 times

Note that 8.10 was 32-bit only by the look of it. Hence why they don't mention 10.14 as an option (10.14 kills off 32-bit mode). Interesting that in 8.10, LC say it supports MacOS 10.13...

Screenshot 2024-12-22 at 20.26.12.png (49.66 KiB) Viewed 1020 times

Then, in 8.2.0 - they regress and say that only MacOS upto 10.12 is supported.

Screenshot 2024-12-22 at 20.27.03.png (44.93 KiB) Viewed 1020 times

The 9.6.1 engine only supported up to 10.15, but note this is where 10.9 became a requirement. I think this is likely where it gained 64-bit mode, as part of being an intel fat binary.

Screenshot 2024-12-22 at 20.27.23.png (43.2 KiB) Viewed 1020 times

In 9.6.3, you can see that this is probably still a fat binary (intel fat binary) - it runs on 10.9 through to MacOS 11.

Screenshot 2024-12-22 at 20.27.39.png (45.05 KiB) Viewed 1020 times

After MacOS 11, this is where compatibility starts to drop off.
As LCC never released a release notes for the 9.7.0-dp1 engine - then not sure what MacOS is 'officially' supported.
It likely still contains 32-bit code at this point, but MacOS will only execute the engine in 64-bit mode after 10.15+
(you could still run 32-bit apps via the terminal towards the final update stages in MacOS 10.14, but this was being hugely phased out)

v13t2oodsdr01-1455086082.png (13.6 KiB) Viewed 1017 times

[tperry2x]

Anyway, getting back on topic:
The start of an external script editor hook (demo video).

Edit: now detects various text editors you have installed, and offers these as a choice:
(rejigged layout too)

external-editor-choices.png (67.94 KiB) Viewed 728 times

edit 2: then, if the file has been edited externally, when switching back to the stack:

are-we-done.png (36.38 KiB) Viewed 711 times

[tperry2x]

This is why I also wanted it to detect possible text editors on MacOS (like it already does in Linux), and where I discovered that what looks like /Applications is actually /System/Applications now.
This is the mac equivalent of the linux screenshot above, when selecting external script editors.

mac-opts.png (22.42 KiB) Viewed 652 times

[richmond62]

Well, you'd be hard put to get BBEdit into the /System/Applications folder as it NOT something that Apple installs by default (and clogs up your system as you cannot remove it if you want to).

[tperry2x]

Well, you'd be hard put to get BBEdit into the /System/Applications folder as it NOT something that Apple installs by default (and clogs up your system as you cannot remove it if you want to).

No, and this is why it stupidly has to search additional locations now.
My point being where previously you had: /Applications
then, if you'd installed anything specific to the user: ~/Applications

Which would have been far simpler.

Now I have to check:
/Applications
/System/Applications
~/Applications

oh well, just means it's a bit slower to do it's thing on macOS. No change there