Extension of systemVersion

Something you want to see in a LiveCode product? Want a new forum set up for a specific topic? Talk about it here.

Moderators: Klaus, FourthWorld, heatherlaine, kevinmiller, robinmiller

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3173
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: Extension of systemVersion

Post by mwieder » Mon Sep 02, 2019 4:58 pm

The main question to ask here - why does it make sense for there to be engine syntax for it?
Yeah, that's the point I was making^H^H^Htrying to make earlier.
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 ;)
Um. On my machine 'uname' with no arguments returns
Linux
while both 'the machine' and 'the processor' in LC9.5 return
x86_64

Shouldn't GetMachine() in dsklnx.cpp return u.sysname instead of u.machine if the desired result of 'the machine' is to match the result of 'uname'? The 'processor' is already hard-coded in system-info.cpp and correctly returns the processor type the engine was built with.

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1095
Joined: Thu Apr 11, 2013 11:27 am

Re: Extension of systemVersion

Post by LCMark » Mon Sep 02, 2019 5:24 pm

Shouldn't GetMachine() in dsklnx.cpp return u.sysname instead of u.machine if the desired result of 'the machine' is to match the result of 'uname'? The 'processor' is already hard-coded in system-info.cpp and correctly returns the processor type the engine was built with.
No - the intent is that it returns the (machine) result of the uname() library call. After all it seems reasonable that given the property is 'the machine' that it should use the 'machine' member? (which is equivalent to uname -m).

Of course the real issue here is that since Linux supports all kinds of hardware, and is divorced from the hardware (being independent) that what these things are defined to be will vary considerably.

Bearing in mind that MetaCard was born on a variety of UNIX workstations - where the UNIX variant was tied to the hardware; it would have been a similar situation to macOS - i.e. the UNIX vendor would make sure their hardware/machine identifier had some meaning.

As I said above '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' :wink:

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3173
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: Extension of systemVersion

Post by mwieder » Mon Sep 02, 2019 5:41 pm

OK - no worries then. You threw me off with the
'the machine' is defined to return then result of 'uname' on Linux
thing.

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1095
Joined: Thu Apr 11, 2013 11:27 am

Re: Extension of systemVersion

Post by LCMark » Mon Sep 02, 2019 5:44 pm

Heh - partly my fault - I didn't make it was the system call/libc call rather than the command line.

Really the question here is - what would make a better 'machine identifier' on Linux? Something pithy, easy to splice and dice which actually provides useful information? Bearing in mind the equivalent on macOS returns thinks like MacBookPro15,1...

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3173
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: Extension of systemVersion

Post by mwieder » Mon Sep 02, 2019 6:10 pm

Probably depends on what you want to use the information for. I'd maybe propose that the 'detailed machine' would report the results of the commandline 'lscpu', but that's probably too much information. :roll: Possibly just the 'Mode name' entry from that list. Possibly part of the contents of /proc/version?

But I have to say this is all blue-skying on my part because I don't recall ever having to tried to use the results of 'the machine' before.

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 5683
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Extension of systemVersion

Post by jacque » Mon Sep 02, 2019 10:04 pm

I don't recall ever having to tried to use the results of 'the machine' before.
It's the only command I could find that tells me I'm running an Android app on a Chromebook, something I'm going to need soon.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

bogs
Posts: 4791
Joined: Sat Feb 25, 2017 10:45 pm

Re: Extension of systemVersion

Post by bogs » Mon Sep 02, 2019 10:18 pm

mwieder wrote:
Mon Sep 02, 2019 6:10 pm
I'd maybe propose that the 'detailed machine' would report the results of the commandline 'lscpu', but that's probably too much information.
What is the 'detailed machine' ? Or are you thinking of adding such and say, making it really detailed?
Image

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3173
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: Extension of systemVersion

Post by mwieder » Mon Sep 02, 2019 11:50 pm

That's why I was saying I was proposing it - so as not to change what the machine currently does.

Jacque- what do you get for 'the machine' on a chromebook?

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 5683
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Extension of systemVersion

Post by jacque » Tue Sep 03, 2019 12:44 am

If I remember right, the model followed by the word "Chromebook", like "Lenovo xxx - Chromebook". I only have one test machine though.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3173
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: Extension of systemVersion

Post by mwieder » Tue Sep 03, 2019 3:04 am

Hmm... do you have to worry about whether the chromebook is an arm or intel cpu?

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 5683
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Extension of systemVersion

Post by jacque » Tue Sep 03, 2019 3:35 am

I don't know, I've only had it a little while and I'm a newbie. An early version of my app (LC 9.0.5) ran pretty well on it, it was compiled as ARM7 32-bit. When things started to go south with acceleratedRendering on my Android phone I tested again on the Chromebook (LC 9.5 , still ARM7 32-bit) and it crashed soon after startup. I need to try it again with acceleratedRendering turned off. Or maybe go back to 9.0.5.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1095
Joined: Thu Apr 11, 2013 11:27 am

Re: Extension of systemVersion

Post by LCMark » Tue Sep 03, 2019 6:13 am

It's the only command I could find that tells me I'm running an Android app on a Chromebook, something I'm going to need soon.
Changes to the machine on Linux wouldn't affect the LiveCode Android engine - the Android engine uses the Build.MODEL which it gets from the Java Environment. Chromebooks are like Macs (as Android is) - the OS is tied to the hardware so one would hope that manufacturer provides a reasonable string for it :)

In regards to processor then Chromebooks come in both ARM and Intel flavours so its probably worth compiling using 9.5 with all Android architectures.

I'm still not quite clear what a better value for 'the machine' would be on Linux (or Windows for that matter) - both are OSes which can be installed on pretty much any 'PC' hardware. For it to have a similar meaning to iOS/Android/macOS (which is what you want in a cross-platform environment) it should be simple string describing the actual hardware the engine is running on... Not so much to do with hardware details but manufacturer/model etc.

Jacque's use-case is a good example - it allows her to distinguish between an Android phone/tablet and the Android (emulation) environment on Chromebooks. In that regard it puts it in a similar category (which is its intent) to the processor and the platform - it allows you to make decisions at runtime based on the environment in which your app is running.

It did occur to me last night that there is at least one Linux environment I can think of where it would be useful if 'the machine' did more than just return 'uname -m' (which looks like it is, unhelpfully, just the processor arch of the binary) - RaspberryPi (when we finally get a supported build). The latter is quite a specific piece of PC-like hardware and so being able to tell if you were running on one might well be quite useful. There might be others like that too... However one issue there is you are probably looking at a huge set of cascaded switch statements to determine what 'hardware' is actually underneath, even if identifiable.

Mark Wieder's suggestion of 'the detailed ...' is quite neat - although I really don't think lscpu is the right thing to be looking at - a machine is much more than a cpu. However, it probably would be a way to get more detailed processor information - although morally that should probably apply to the notion of 'the hostProcessor' rather than 'the processor' for reasons already stated.

At the end of the day, without explicit use-cases which people can demonstrate to be actually useful and guide what improvements could be made here then you are probably better off getting this info using shell("lscpu")... Which isn't exactly onerous is it?

P.S. I still offer the notion of hostProcessor to solve the OP's original problem - its 'just' a case of working out how to determine it in an atomic way on all the platforms we support.

bogs
Posts: 4791
Joined: Sat Feb 25, 2017 10:45 pm

Re: Extension of systemVersion

Post by bogs » Tue Sep 03, 2019 12:20 pm

mwieder wrote:
Mon Sep 02, 2019 11:50 pm
That's why I was saying I was proposing it - so as not to change what the machine currently does.
Thanks, I like it AND it tends to fit the style of the language better. I hope your proposal goes through :D

While I was putzing around the outsides of this question, I remember LCMark (I think) saying Gestalt() was used in the Mac part of the equation. Bad news (or maybe old news to this group), I think it is going to be gone soon, or might be inaccurate right now. I found this (and a few others) indicating as much, but not from an official source.
https://opensource.plausible.coop/bugs/browse/PLCR-550 wrote: Problem: Gestalt has been deprecated since 10.8, because it will return the wrong version number on 10.10.
On Yosemite, Gestalt returns 10.9 instead of 10.10.
Reproducibility: Always
...and some possible solutions I found here.

Since I don't at the moment have any method in place for testing on any version of OSX, I'll leave that to others to figure out.
LCMark wrote:
Tue Sep 03, 2019 6:13 am
At the end of the day, without explicit use-cases which people can demonstrate to be actually useful and guide what improvements could be made here then you are probably better off getting this info using shell("lscpu")... Which isn't exactly onerous is it?
If you know how and ahead of time that you will be needing it, no. You mentioned earlier than anyone needing that information should know enough about it to be able to get it. I think Jacque's example is a good test case too, not the way you mentioned, but how to get the information reliably from a platform when you might not know enough about that platform.

Chrome is 'nix-like, but I've never looked into how nixie it really is. (The homework keeps pilling up, don't it? :D )

Sure I know enough about a lot of 'nices/'nixes to get it myself there, but I might not be able to get it everywhere else (although I'm reasonably certain I could, not everyone else is, if you see what I mean).
Image

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3173
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: Extension of systemVersion

Post by mwieder » Tue Sep 03, 2019 5:57 pm

LCMark-

I get that chromebooks don't run linux. Just curious about what happens there. I've got (very) limited experience with chromebooks to date.

I get "arm7l" as a result of running "uname -m" on a Raspberry Pi 2 or 3. I believe the original Pi was an arm6, but the OS determines its environment and adjusts accordingly.

I don't really think the whole contents of lscpu is what we want for the machine on linux either. I think the question is "what problem are we trying to solve?" on linux. Is the 'machine' supposed to determine what distro we're running on? The type of cpu? The kernel? The desktop manager? I know why the machine value is useful on mobile devices - why would you need to test it on linux? And in that case, what value would we want to return?

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1095
Joined: Thu Apr 11, 2013 11:27 am

Re: Extension of systemVersion

Post by LCMark » Tue Sep 03, 2019 6:32 pm

I get that chromebooks don't run linux. Just curious about what happens there. I've got (very) limited experience with chromebooks to date.
Chromebooks run Android apps in the Android environment - so what you get running an LC app built for Android on a Chromebook is the same as what you get when you run an LC app built for Android on a Android phone.

The key thing Jacque has noticed is that she can tell which is the case by inspecting 'the machine' - because on Android, that property returns a piece of system metadata provided by one of system Android classes.
I don't really think the whole contents of lscpu is what we want for the machine on linux either. I think the question is "what problem are we trying to solve?" on linux. Is the 'machine' supposed to determine what distro we're running on? The type of cpu? The kernel? The desktop manager? I know why the machine value is useful on mobile devices - why would you need to test it on linux? And in that case, what value would we want to return?
That is precisely the set of questions which we have yet to answer :)

The original motivation for 'the machine' comes from a situation where the OS was tied to the hardware so the OS vendor was the hardware vendor and as such could give decent names to the different machines they sold. This is the same as macOS is today, and Android and iOS. Linux and Windows are different because the machines they run on are not produced by any given vendor or licensee of the OS...

Post Reply

Return to “Feature Proposals”