The Dictionary . . . Again

[richmond62]

The current OXT Lite dictionary leaves out substantial bits of information:
-

SShot 2025-04-08 at 15.41.57.png (56.65 KiB) Viewed 5772 times

-

SShot 2025-04-08 at 15.42.24.png (71.18 KiB) Viewed 5772 times

[richmond62]

NBG!
-

Screenshot 2025-04-09 at 16.48.03.jpg (281.2 KiB) Viewed 5713 times

[OpenXTalkPaul]

NBG!
-
Screenshot 2025-04-09 at 16.48.03.jpg

I don't know what NBG is? I've use 'NFG' at the shop.

That's pretty much why I didn't want to take on the task of completely redoing a Dictionary-as-stack from scratch, too many ways it could go wrong or foe info to go missing in action, but as a quick reference it is stil better than trying to use the broken-on-Linux Browser Widget dictionary version. I think a better option might have been to generate an entrees to display from the array which can be retrieved from that revDocs library (which is used to generate the JSON /HTML version to begin with). I believe that's how the IDE does it for the Dictionary display that can be viewed 'inline' at the bottom of script-editor windows.

put the machine -- on macOS returns Model Identifier. like MacBookPro13,1
... that's yet another bit of syntax that I don't think I've ever used or knew existed before!

[richmond62]

That's probably because 'bloody' is not used much as a swear work on your side of the pond.

[OpenXTalkPaul]

I think the closest thing we might get to 'the machine' in a web context is the userAgent string, you can figure out the type of machine/platform in a broad sense, like "desktop" or "mobile" plus vendor. in a desktop app context it's easy to get that sort of info with a shell() function.

I just checked the Emscripten port of the Engine 'the machine' returns empty.

But I yeah a syntax dictionary viewer should display a parameters section, specially with specific possible enum values it's important for being able to use the syntax.

Since Tom used a plain text format it should be easy to fix it yourself and then share it with us.

[richmond62]

Why do I have a feeling that the discussion about 'the machine' has mysteriously migrated here from another thread?

viewtopic.php?p=14597&hilit=machine#p14597

Could one of the list 'Dads' (Ugh: we all know where that childish sort of terminology originated) sort this out, please?

[richmond62]

In spite of "Mr Prickles" and his reaction, the FACT is that the current Dictionary does not display all the information it should.

And part of that reaction might be because of someone getting slightly frazzled digging in pastures new and having no time to do some weeding inbye the biggin.

I am aware the current Dictionary is 'there' because the inherited one 'fekked up big' on Linux.

That does not really excuse the very real problem.

While the text files for the current Dictionary are text files, as far as I recall they do contain some sort of markup language.

I intend to address this over the next few days, and see if I cannot produce at least a static stack that displays all the information inwith the text files in a fairly similar way to the legacy dictionary but usable on Linux.

[tperry2x]

In spite of "Mr Prickles" and his reaction, the FACT is that the current Dictionary does not display all the information it should.

Rather than complain about it Richmond, why don't you have a look at the script of the dictionary stack and have a go at sorting it out? This is a common theme. I don't know why you don't go weeding through the script to work out WHY it's not working. Four eyes are better than two.

And part of that reaction might be because of someone getting slightly frazzled digging in pastures new and having no time to do some weeding inbye the biggin.

I don't know what you mean by "inbye the biggin", but yes - pouring my time into what is essentially always going to remain a broken engine makes no sense.

I am aware the current Dictionary is 'there' because the inherited one 'fekked up big' on Linux.
That does not really excuse the very real problem.
While the text files for the current Dictionary are text files, as far as I recall they do contain some sort of markup language.

You aren't wrong there. It's better to have something rather than nothing.

I intend to address this over the next few days, and see if I cannot produce at least a static stack that displays all the information inwith the text files in a fairly similar way to the legacy dictionary but usable on Linux.

Good. Glad to hear it!
That's what I'm on about. Hope this doesn't come across as too "Prickly!" but saying NBG (No bloody Good) is all very well, but let's see you do better!?
I don't mean that in a terse or objectionable way - see it as a scripting challenge if nothing else. The info is all there in the text files, for want of a better phrase - it's how they are being 'parsed'.

In all seriousness, I'd like someone to take over the development of what I see as our "very legacy engine", and I wish them all the luck in the world with it. I don't feel I can innovate or take it any further though.

You could equally argue though, that as the information in the dictionary is (at best) probably only 50% correct - I'm not going to overly worry about it anyway when the source material is so deeply flawed. I normally find I just need enough to jog my memory on something, then the rest is pretty much self explanatory in most cases: usually resulting in something not being implemented on all platforms in the engine, or implemented differently. (running up against our legacy engine problems yet again).

[tperry2x]

On a lighter note, this made me laugh at least:

say-what-lol.png (92.88 KiB) Viewed 5362 times

[richmond62]

Rather than complain about it Richmond, why don't you have a look at the script of the dictionary stack and have a go at sorting it out?

[tperry2x]

Rather than complain about it Richmond, why don't you have a look at the script of the dictionary stack and have a go at sorting it out?

Uh, yeah - indeed.
If you want a starting point - open the dictionary stack so it's visible and loaded, and run this in the message box:

Code: Select all

edit the script of btn "load random" of cd 1 of stack "OpenXTalk Lite Dictionary"

[richmond62]

Oops:
-

SShot 2025-04-10 at 12.18.01.png (104.82 KiB) Viewed 5326 times

-

SShot 2025-04-10 at 12.42.22.jpg (200.18 KiB) Viewed 5320 times

-
AT least part of the problem might be that a lot of the HTML tags have been removed in the TEXT files.

HOWEVER I have NO idea whatsoever where to find the HTML files from which these text files have been derived.

[richmond62]

Let's suppose that these are what I need:
-

SShot 2025-04-10 at 12.49.39.png (73.06 KiB) Viewed 5318 times

-
Presumably (?) there is a way to export each term to an HTML file (otherwise I wonder how those TEXT files were derived).

[richmond62]

SShot 2025-04-10 at 13.02.06.png (14.79 KiB) Viewed 5315 times

-
Um . . .

Erm . . .

Were those HTML files rather than text files would all that formatting code be necessary?

[tperry2x]

Presumably (?) there is a way to export each term to an HTML file (otherwise I wonder how those TEXT files were derived).

They were exported as text by a script, opening each dictionary item one-by-one on a loop, copying the raw text, and pasting into a corresponding .txt file. (using xdotool on linux).

If you want the HTML tags, you'd need to open the dictionary in LCC 9.6.3 in a browser, then view the source (for each entry) I suppose.

[tperry2x]

Were those HTML files rather than text files would all that formatting code be necessary?

Yes, because HTML display within the IDE is very lacking. (which is why I think they default to trying to use a browser approach). - no table support for htmltext for example.

[richmond62]

the dictionary in LCC 9.6.3 in a browser

Not very helpful: https://livecode.com/apidocs/docs/api.html

as seems no obvious way to export each individual entry as a 'simple' HTML file.

[richmond62]

Yes, because HTML display within the IDE is very lacking.

That's an odd statement as my Devawriter Pro gubbins can import HTML text and keeps at least some of the formatting intact.

However, right now I have to go and sing for my supper:
-

SShot 2025-04-10 at 13.09.11.png (40.98 KiB) Viewed 5309 times

[tperry2x]

Yes, because HTML display within the IDE is very lacking.

That's an odd statement as my Devawriter Pro gubbins can import HTML text and keeps at least some of the formatting intact.

Not really. As you wanted the parameters to load as a table, there's no built in table support in the htmltext implementation of the IDE, so you either have to use a datagrid or roll-your-own.

Anyway, here's how you get access to those HTML files. (Ignore the time on these screenshots as it's a VM).

I'm using LCC 9.6.3 here and opening the dictionary.

a.9_10_04_2025_11_19_08.png (258.64 KiB) Viewed 5307 times

With the dictionary loaded, not closed, I then navigate to here in the finder:

b.9_10_04_2025_11_19_28.png (322.2 KiB) Viewed 5307 times

it's this api.html file you want. Open that in a browser of your choice.

You now at least have it displaying in a normal browser, not the browser widget of the IDE.

c.9_10_04_2025_11_19_52.png (138.84 KiB) Viewed 5307 times

View page source:

d.9_09_12_2025_11_22_19.png (182.88 KiB) Viewed 5307 times

There's all your HTML tags and markup.

e.9_10_04_2025_11_22_19.png (245.9 KiB) Viewed 5307 times

[richmond62]

Thanks.

Something tells me I'm going to have a fairly dirty weekend . . .