Extension of systemVersion

[bogs]

Ahhhhhhh! Yes, then, it would be nice to get as much info as possible.

[LCMark]

You have a function called the processor, which the dictionary blatantly states should be telling you what the CPU is. Instead, apparently, it tells you what your application is compiled for. You compiled the application, why would you need to know what you compiled it for? You already have this information before it leaves your machine.

Nope - in 9.5 the processor dictionary entry does (at least!) make it clear that you might get the emulated or host CPU. Of course it could say it in a clearer way, and suggest why this is the case in more detail!

Imagine you have built both a windows 32-bit and 64-bit standalone... Whilst you might know which is which - your code in them might well need to know which is which as some things may well be in different places. i.e. Your script might contain:

Code: Select all

if the processor is "x86" then
  -- look for x86 specific thing
end if

The point here is that due to the way these things work it is the architecture of the code being run which determines this, not that of the host processor.

Similarly, I can guarantee you that if you are running code inside an Android emulator on a machine then the host processor is entirely irrelevant (as is the host platform). That's the point of emulation - you aren't meant to be able to 'get out of the emulated sandbox'. [ WOW64 is actually a 32-bit emulation layer - its just that 64-bit intel CPUs can run a 32-bit instruction environment - its the same case for ARM64 and ARMv7 instructions ].

Even benchmarking - 32-bit x86 code running on a 64-bit processor will have different performance characteristics from the same code compiled to 64-bit x86 code (there are substantially more registers available in the latter, for example) - so, the architecture of the compiled code is probably more important than that of the host.

So, anyway, my general observation over the years when this has come up is that - the current functions we have are doing the right thing from the point of view of what is most commonly used (and actually needed).

Of course there will always be special cases (benchmarking, for example, is a highly specialized case!) but that's why there's all manner of ways to get at information provided through other means. e.g. shell, the registry functions, LCB etc.

[bogs]

Yah, I read that discussion and even posted a link to it in this thread back here

*Edit 3 - Also came across this interesting discussion about the processor function.

The problem I see with it occurs in several ways.
First problem:

you might get the emulated or host CPU.

What ever you *might* get, you are never getting the actual processor, least not on straight up debian linux. This box is running a AMD 64 bit 3 core processor, on a (for this test) 64 bit Debian OS. At the least, since this is not in a virtual machine of any kind, I would expect the result to be
• x86_64: x86 64 bit architecure

Because the Lc IDE being used is 32 bit, though, in reality, what I see is
• x86: x86 32 bit architecure

The processor, 9.5.0...

Code: Select all

bogs@bogsebian:~$ dpkg --print-architecture
amd64
bogs@bogsebian:~$ dpkg --print-foreign-architectures
i386

Second problem:
If your trying to debug something, the way this reports could lead to an awful lot of confusion as shown in example 1, especially if you are thinking your getting the real hardware, but even if your only talking about the applications execution environment, I'd think you would want more information. Maybe something on the order of -
psuedo processor (reported now) , real processor (which really shouldn't be that hard to obtain).

Third problem:

the current functions we have are doing the right thing from the point of view of what is most commonly used (and actually needed).

I'm sure that has been said by everyone going back to the beginning of time,

[Technology] - Pump? Why on earth would you need a pump?? We have buckets, and that should be enough for anybody!!

[Speed] - As you may well know, Mr. President, ‘railroad’ carriages are pulled at the enormous speed of fifteen miles per hour by ‘engines’ which, in addition to endangering life and limb of passengers, roar and snort their way through the countryside, setting fire to crops, scaring the livestock and frightening women and children.

The Almighty certainly never intended that people should travel at such breakneck speed.

[Computers] - 640k should be enough for anyone~! {Although that person now denies it was ever said by him}

but what is your view on "the machine"? If the processor is good enough, why shouldn't the machine report more information than it does, which is no more than the processor, *and* report it accurately (i.e. real hardware)?

In this post, the machine is the same machine I am running now with the same 64 bit processor, but 'the machine' is reporting that it is a 'i686' (32 bit) because it is running on a 32 bit os. On the 64 bit Debian Os, it correctly reports x86_64, but why not report all the hardware much like the way "the files" works? After all, "the machine" certainly sounds like it should be talking about... well, the machine

[LCMark]

So basically, the syntax is all doing precisely what it should - it is returning what it is defined to (on Linux, the machine returns the result of the uname() API call, for example).

The question of 'why doesn't the machine report all hardware much like...' is simple - because:
1) it wasn't designed to
2) if it changes to do so it would break all existing code which relies on what it is currently defined to return

I should point out that I'm not saying that these functions are the be-all-and-end-all - just that they are correct relative to what they are defined to do, are very well-defined and provide a useful purpose in a good range of scenarios (the machine on Linux is perhaps the least useful, admittedly because it is determined by uname which linux distributions can basically get to return whatever they want!).

If you want other information great - there's all kinds of ways to get that - if you can find a way to define, model and present that information in a programatically cross-platform way along with all the details of how to get it in a non-fragile way universally that makes it useful to a reasonable range of requested use-cases then submit an engine PR for it - or perhaps better, write an LiveCode script library for it (which would actually make a lot more sense!).

Having said that, assuming it is actually determinable using system APIs and people could agree what it should return when you are running a mobile emulator on a desktop platform - a 'hostProcessor' function probably wouldn't go amiss

[bogs]

Gotcha, thank you for the reply. <going back out of testing mode>

[LCMark]

Just another way to think about your testing is that it actually means that Linux (and Windows for that matter) do a *really* good job at ensuring that 32-bit processes run exactly as they should when operating in a 64-bit OS...

i.e. you can't easily tell (from the point of view of the 32-bit process) that you are running in a 64-bit OS because if you could it would mean that some aspect of the environment wasn't exactly the same (and thus could trip up a 32-bit application written before the 64-bit ISA existed).

Specifically I'm not sure how true the 'which really shouldn't be that hard to obtain' statement in 'psuedo processor (reported now) , real processor (which really shouldn't be that hard to obtain).' actually is...

On Windows you can obtain it by looking for a given folder - as the FS is shared; and Linux is probably the same (although I think multi-arch distros have approached the problem in different ways so there's is likely to be a bit of variation). However both of those approaches could be considered fragile - what if the permissions are setup in such a way that any FS stuff being used to determine the difference isn't visible to the running process?

[bogs]

I was going to reply sooner, but REALITY hit me right between the eyes!

Where did you go ?!

I really should consider my remarks more before hitting 'submit' Keep in mind I haven't touched the deep roots of a Win box in many ... DECADES now, so the following is strictly from the POV of unix environments, Debian in particular (i.e. should work on any distro based on same).

i.e. you can't easily tell (from the point of view of the 32-bit process) that you are running in a 64-bit OS

In multi-arch setups, you can easily tell the base os with dpkg, and it does not require escalation (unless you are adding architectures). But simply reading the architecture requires no special priviledge, i.e.

Code: Select all

bogs@bogsebian:~$ dpkg --print-architecture # base architecture...
amd64
bogs@bogsebian:~$ dpkg --print-foreign-architectures # additional architectures...
i386

Specifically I'm not sure how true the 'which really shouldn't be that hard to obtain' statement in 'psuedo processor (reported now) , real processor (which really shouldn't be that hard to obtain).' actually is...

{Part in bold is one unit, your already pulling the psuedo processor just fine}
Well, that would be as easy without change in privileges as lscpu -

Code: Select all

bogs@bogsebian:~$ lscpu
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
Address sizes:       48 bits physical, 48 bits virtual
CPU(s):              3
On-line CPU(s) list: 0-2
Thread(s) per core:  1
Core(s) per socket:  3
Socket(s):           1
NUMA node(s):        1
Vendor ID:           AuthenticAMD
CPU family:          16
Model:               5
Model name:          AMD Athlon(tm) II X3 450 Processor
Stepping:            3
CPU MHz:             3200.000
CPU max MHz:         3200.0000
CPU min MHz:         800.0000
BogoMIPS:            6429.06
Virtualization:      AMD-V
L1d cache:           64K
L1i cache:           64K
L2 cache:            512K
NUMA node0 CPU(s):   0-2
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr hw_pstate vmmcall npt lbrv svm_lock nrip_save

For the rest of the hardware easily obtained, lspci is where I turn short of other harder methods -

Code: Select all

bogs@bogsebian:~$ lspci
00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD9x0/RX980 Host Bridge (rev 02)
00:02.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GFX port 0)
00:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 0)
00:09.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 4)
00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] (rev 40)
00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus Controller (rev 42)
00:14.1 IDE interface: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 IDE Controller (rev 40)
00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA) (rev 40)
00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 LPC host controller (rev 40)
00:14.4 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 PCI to PCI Bridge (rev 40)
00:14.5 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI2 Controller
00:16.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:16.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor HyperTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Address Map
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Link Control
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Oland PRO [Radeon R7 240/340]
01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde/Pitcairn HDMI Audio [Radeon HD 7700/7800 Series]
02:00.0 USB controller: VIA Technologies, Inc. VL805 USB 3.0 Host Controller (rev 01)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
04:07.0 Ethernet controller: Accton Technology Corporation SMC2-1211TX (rev 10)
bogs@bogsebian:~$ 

From what I remember of Windows, you could pull similar without admin rights from the same source as the device manager uses (any user level can look at the device manager), but take that with a grain of salt cause it has just been way too long.

However, I know how smart you all are, and I know from the diverse group that works on such things that you already know both of these, so I just assume that there is some reason that these are not acceptable sources.

[LCMark]

Right but the above are presumably running a on a 64-bit debian environment... So that is a 64-bit terminal, calling a 64-bit lscpu

Now you need to consider that you are running a 32-bit process on that 64-bit environment and, moreover, you want a way to determine the host processor which will work universally on any Linux distribution.

Looking at the man page for lscpu it seems it just a simple wrapper around /proc/cpuinfo - so assuming that a 32-bit process doesn't see a 'modified' form of /proc/cpuinfo; then grokking the right part of that would be the non-fragile way to get that information (I'd actually hope there was a more systematic / syscall way of doing so too - but a fair bit these days is now wrapped up in /proc rather than via C-style syscall APIs lamentably)

[bogs]

ight but the above are presumably running a on a 64-bit debian environment... So that is a 64-bit terminal, calling a 64-bit lscpu

I think I wasn't clear enough, this pertains to the real processor, you will get the real processor no matter which program processes are being used (the psuedo hw).

Now you need to consider that you are running a 32-bit process on that 64-bit environment and, moreover, you want a way to determine the host processor which will work universally on any Linux distribution.

As I said, your already doing the psuedo one just fine, why change that? This would be an extension of what is already there.

The extended information (lscpu and pci) are what I would envision the machine function giving you. It is what I pull from through the other methods you mention, I haven't seen it fail on any of the distro's I run, not to sound in-modest, but the number is fairly high . It is what I was talking about when I compared 'machine' against 'files'.

The actual proc files are what I usually target (like when your writing a top program), but for something of this level it isn't really needed. I agree a nice C api would be great, but I don't think your going to get 800+ distros to agree on that one, and besides, proc files / lscpu / dpkg have been around forever and aren't likely to disappear anytime soon.

[LCMark]

However, I know how smart you all are, and I know from the diverse group that works on such things that you already know both of these, so I just assume that there is some reason that these are not acceptable sources.

I missed this paragraph in the above...

The main question to ask here - why does it make sense for there to be engine syntax for it?

System metrics which make sense across all platforms, and can be accessed/fetched with 100% accuracy with no chance of error - sure - they are potential candidates (as long as those things have a reasonably high-degree of utility generally - otherwise it just ends up being code bloat in the engine) [ hostProcessor would probably fall into this category of being a potentially sane thing ].

However, for things like the list of pci devices? Detailed information about CPUs? These things vary widely - is the lscpu output standardized in any way and never going to change in format? What about lspci? Does all that information even make sense across all the platforms/architectures/devices LiveCode supports?

Both lscpu and lspci fail these tests in several ways: to work the commands need to be there, they need to be callable from the engine process, they need to have a fixed never changing output format etc.

At the end of the day if you app needs this stuff in this much detail, then it means you know what you are looking for and can easily figure out how to find it, and then manipulate it using shell() commands and LC's excellent text processing abilities, surely?

[LCMark]

The actual proc files are what I usually target (like when your writing a top program), but for something of this level it isn't really needed. I agree a nice C api would be great, but I don't think your going to get 800+ distros to agree on that one, and besides, proc files / lscpu / dpkg have been around forever and aren't likely to disappear anytime soon.

Case in point - last time I checked 'dpkg' is entirely Debian specific is it not?

[ /proc is of course provided by the kernel - so that is at least as stable as Linus decides to make it - its just not quite as easy to grok as a well-defined, standardized syscall/libc API that's all! ]

[bogs]

The main question to ask here - why does it make sense for there to be engine syntax for it?

I haven't delved through the code for the entire IDE, so there are lots of parts of this puzzle I am not knowledgeable about. Heck, I haven't even finished completely documenting the Mc IDE I work in regularly yet, keep in mind I have been playing some (20 ?) years of catch up in a lot of this stuff

Having said that, and not knowing the complete structure of where (specifically) things get pulled from as it relates to the IDE/functions/messages/etc, a lot of this is guesswork on my part.

If all functions are hard written into the engine(s), then it might be harder to justify for edge cases like the ones I mentioned. However, since the machine is as I understand it at this point supposed to be telling you the real cpu, and it doesn't in certain cases, doesn't that mean it has to be fixed in the engine? If your already in there mucking about, that would seem an ideal time to think about whether this should be added or not. Providence!

I'm not sure what you mean by

...for things like the list of pci devices? Detailed information about CPUs? These things vary widely...

Every OS I've ever used has had this information, generally in great detail. On the other side of that, I haven't used *every* OS either. It is (usually) fairly easy to access if you know the magic incantations and which specific places to look, something that might take years of your life to figure out, or you could just ask your local nerd I suppose, but once you know where and how, it doesn't seem to change a whole lot in format even between OS'es.

I could be wrong there though, I don't study the architecture of even the 3 main desktops obsessively.

is the lscpu output standardized in any way and never going to change in format?

Is it standardized, yes.

Is it never going to change? How could you say? Everything changes at some point, even the programming language of this very topic. If anything, I would probably expect those two files to change in format. Even the proc files have changed in format.

Look at it another way, when Quicktime was king of the hill, did you expect it would go away at some point? If you did, you must be psychic! but it was still part of Lc for a long long time.

I'll go back into testing mode though for a while, take a look at the 3 major (and a goodly number of minor) 'nix'en, and see what comes up. I still think uname (even though I use it a lot myself) is a poor choice for real information since it can spit out anything.

[bogs]

The actual proc files are what I usually target (like when your writing a top program), but for something of this level it isn't really needed. I agree a nice C api would be great, but I don't think your going to get 800+ distros to agree on that one, and besides, proc files / lscpu / dpkg have been around forever and aren't likely to disappear anytime soon.

Case in point - last time I checked 'dpkg' is entirely Debian specific is it not?

[ /proc is of course provided by the kernel - so that is at least as stable as Linus decides to make it - its just not quite as easy to grok as a well-defined, standardized syscall/libc API that's all! ]

Good point, dpkg is only on Debian (and based) distros. However, the proc files are not that bad to figure out and are as far as I know across all systems. I'll check the standardization of the two wrapper calls.

As far as the 'hard to grok' proc files go, there are addtions made but once you have the format it really doesn't change all that much. I found a 'top processes' tutorial written in the Mc era that still works (shocking) and dips through the proc files.

[LCMark]

If all functions are hard written into the engine(s), then it might be harder to justify for edge cases like the ones I mentioned.

Except for a handful of cases (most url related syntax for example) all engine syntax (properties, chunks etc.) and functions which have a 'the' form (e.g. the processor/machine/systemVersion) are all in the engine.

However, since the machine is as I understand it at this point supposed to be telling you the real cpu, and it doesn't in certain cases, doesn't that mean it has to be fixed in the engine? If your already in there mucking about, that would seem an ideal time to think about whether this should be added or not. Providence!

Well here is the point of contention - 'the machine' is defined to return then result of 'uname' on Linux - that is it. Just because it is called 'the machine' it doesn't mean it necessarily returns anything concretely related to a physical machine

Now, the fact it does that is because at some point in the dim and distant past (probably when there was a family of 'real' UNIXes which the engine supported) that obviously made sense.

Is it never going to change? How could you say? Everything changes at some point, even the programming language of this very topic. If anything, I would probably expect those two files to change in format. Even the proc files have changed in format.

Things which are standardized in the truest sense of the word (as related to computing) don't change - they expand, but what I mean here is that if you ran code compiled now on a system which conformed to standard X then would it still run the same way in a few years?

For example, C is standardized sufficiently well that I can be sure that any of my printf formatting strings will continue to do the same thing in 10 years time as they do today (give or take some of the more 'modern' extensions) at least.

Similarly, UNIX C programs written to POSIX interfaces from 20 years ago will compile and run identically today on POSIX compliant UNIXes today (I think macOS is such a beast these days - not sure about Linux strictly speaking).

I was perhaps over-labouring the point - basically it comes down to this...

Adding the hostProcessor (which would solve the OP's original problem ) has to be done in a way which is sensible for all platform/architectures we support. It needs to work without 'hidden' dependencies (which lscpu certainly would be, /proc may be okay) - because it is a very low-level operation which would cause great surprise if it failed on a random system.

'The machine' is a piece of legacy (these days) which I think only really returns something reasonable on macOS/iOS - but that's because Apple control hardware which runs macOS and iOS and so have a well-defined eternal naming system for all the actual physical machines they produce. On other platforms - well, it does what it does, it isn't going to change so if what it does is useful to you then you know it will be the same 10 years from now as it is today and as it was 10 years ago.

Getting more detailed system information certainly might be useful for certain applications - but I suspect if you got 5 people in a room who all wanted such a thing it would take them quite a while to agree on precisely what they wanted and what format they wanted it in (especially when considering it from a multi-platform, rather than single platform standpoint).

Given there are numerous means to get at all this information (on the Desktop platforms at least - iOS/Android are much more restricted) via shell/registry/filesystem - such an endeavour would be best done as a script library written in LCS I feel. Of course in the process of such a thing being produced, specific pieces of information may well be discovered that are specific enough, well enough defined and easily fetchable such that they then deserve the place of being added to engine syntax.

[bogs]

If all functions are hard written into the engine(s), then it might be harder to justify for edge cases like the ones I mentioned.

Except for a handful of cases (most url related syntax for example) all engine syntax (properties, chunks etc.) and functions which have a 'the' form (e.g. the processor/machine/systemVersion) are all in the engine.

Thanks for the insight <tucking away a note>

However, since the machine is as I understand it at this point supposed to be telling you the real cpu, and it doesn't in certain cases, doesn't that mean it has to be fixed in the engine? If your already in there mucking about, that would seem an ideal time to think about whether this should be added or not. Providence!

Well here is the point of contention - 'the machine' is defined to return then result of 'uname' on Linux - that is it. Just because it is called 'the machine' it doesn't mean it necessarily returns anything concretely related to a physical machine

Well, again the dictionary is a tad contradictory in the description, I wasn't going solely by the name of the function.

machine

Type function

Syntax
the machine
machine()

Summary
Returns the type of hardware the application is running on.

<sic>

Description
Use the machine function to detect what type of system your
application is running on.

If you were shooting for the actual hardware, which is how I interpreted it, uname would be the last thing I would use. If, on the other hand, it is just going to return the same thing as processor, what is the point to having it?

If you see what I mean.

Things which are standardized in the truest sense of the word (as related to computing) don't change - they expand, but what I mean here is that if you ran code compiled now on a system which conformed to standard X then would it still run the same way in a few years?

In that context, then I still would dump uname and go to the proc files, at least for machine, even in the current limited form it is now.