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, robinmiller, kevinmiller

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7022
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Extension of systemVersion

Post by FourthWorld » Sat Aug 31, 2019 11:32 pm

If the processor doesn't return the processor please file a bug report.
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

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

Re: Extension of systemVersion

Post by mwieder » Sun Sep 01, 2019 3:09 am

Ah, Richmond... deploying to other processors/operating systems isn't a matter of checking a system property via script - the engine itself has to be compiled to run on the processor (Intel/ARM/etc) and hook into the operating system in various sneaky ways. That's why we don't currently have a Raspberry Pi deployment at present - it's waiting for someone with the proper ken to step up and fiddle with the build files and the engine innards. We can currently deploy Android engines to ARM7 devices, but that's still not enough to get us to Piville.

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

Re: Extension of systemVersion

Post by bogs » Sun Sep 01, 2019 6:44 am

FourthWorld wrote:
Sat Aug 31, 2019 11:32 pm
If the processor doesn't return the processor please file a bug report.
Certainly, My assumption was that it was returning what the installed OS was reporting, not anything from the actual hardware level, and so this was not a bug, but I'll be happy to file it.

*Edit - apparently a bug was already filed for this, and according to Panos, the processor should actually report the app's architecture? <hee hee> that is confusing, or maybe better said "counter intuitive" to say the least.
"the processor" returns correct results, it should return the arch of the running app. Maybe the docs need to make this clearer.
I sure didn't see that one coming heh.

In any case, I appended what I am seeing, even though processor isn't actually a bug.

*Edit 2 - I dug around back to Mc 2.2 to see if any changes in the dictionary occurred, this is what I found.

This in the Metacard 2.2 reference, which states:

"The following terms are accepted as valid function and property names, but are not implemented and return fixed values:"
This is where 'processor' is listed.
processorFromMetacard22.png
Huh...
Machine, though, is a slightly different bird, even in the earliest Mc IDE I can run, it states that it is indeed supposed to return the CPU type, however even back then it reports it incorrectly, or at least, reports what the installed OS says it is running on.

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

For instance....
montegoulding on Jun 30, 2017 Contributor wrote: Actually this is the same for all platforms. the processor will return the processor the engine was built for not the processor of the machine if there is some emulation going on. So in the case of all three desktop OSs that may or may not be the actual processor arch if it returns 32 bit...
Long read, but fascinating stuff :D
Last edited by bogs on Sun Sep 01, 2019 7:53 am, edited 3 times in total.
Image

richmond62
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 3809
Joined: Fri Feb 19, 2010 10:17 am
Location: Bulgaria

Re: Extension of systemVersion

Post by richmond62 » Sun Sep 01, 2019 7:01 am

deploying to other processors/operating systems isn't a matter of checking a system property via script
Really? Gosh, I didn't know that . . .
waiting for someone with the proper ken to step up and fiddle with the build files and the engine innards
Um: fiddle with the . . . innards.

I've got a friend who performs autopsies on road crash victims . . . 8)

Err . . . joking apart . . .

For the sake of argument . . . I am the author of a "thing" called Devawriter Pro, which
is one hell of a sh*t-kicker when it comes to Indic language writing systems . . . and I offer
a variety of Demos for a variety of OSes and machines (thanks to LiveCode).

Now I can spare myself a lot of time and aggro if I have a small standalone for, say, Windows,
which a potential customer can run on his/her system and it can tell me what sort of Windows
they are using and whether their computer is a 32-bit or a 64-bit machine.

This is particularly useful as most "crusty professors" of Sanskrit don't know very much
about the innards of computers and their operating systems.
-
DWP3bShK.jpg
-
https://www.dropbox.com/sh/z9r67i66f094 ... B5gia?dl=0

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

Re: Extension of systemVersion

Post by LCMark » Sun Sep 01, 2019 11:37 am

Devin asked a similar thing on the use-list last week - suggesting doing exactly
the same thing - my general response was don't make your life more complicated
than it needs to be:
> No, I’m just toying with the idea of having a 32-bit launcher that
> would examine the host OS, then launch the proper executable based on
> whether it is 32 or 64 bit. Sort of like a poor man’s universal app
> like we used to create for MacOS. It’s possible I’m use way
> overthinking this.

I think you might be overthinking this...

The Windows world is different from mac because the former don't have the
idea of multi-architecture binaries.

Obviously on mac this isn't something you have to worry about - especially
since versions of macOS going back many years have supported 64-bit as have
the machines it runs on.

On Windows it is usual for the user to choose whether they want 32-bit or
64-bit versions of the apps they download and install. This is usually guided
by the webpages which offer downloads as you can usually assume that if the user
is on a 64-bit windows machine, then the browser they are running will be 64-bit
which means that you can tell from the UserAgent string what architecture their
machine has and so you can guide the user to the right choice.

In an end-user setting, you could always have a dialog which pops up when running
the 32-bit version on a 64-bit machine (by using Dar's suggestion) on first run
to suggest the user might want to download the 64-bit version - however, you then
have to ask yourself whether your app actually benefits from being 64-bit enough
to justify this extra complexity.

In an organizational setting then one would hope that the IT department would
know what to do when presented with the choice of both a 32-bit and a 64-bit
build of a Windows app... In reality this may or may not be the case ;)

So my suggestion (in general - obviously specific circumstances always apply) is
don't worry about it. Offer two downloads explicitly named and marked - one as
32-bit one as 64-bit and then, if you can, guide the user to the right choice
online by offering the appropriate build (which Chrome does, for example, adding
further weight to being able to rely on the bitness of the browser accessing your
download site).
Really the key thing in most cases is 'does your app actually benefit from being 64-bit
enough to justify any extra complexity[of shipping more than one binary]'. Unless
you actually notice a performance advantage or, indeed, are needing to manipulate
> 3Gb of data at a time (in memory) then its probably the case that 32-bit only will
do fine for some considerable time into the future.

AxWald
Posts: 369
Joined: Thu Mar 06, 2014 2:57 pm

Re: Extension of systemVersion

Post by AxWald » Sun Sep 01, 2019 2:11 pm

Hi,
richmond62 wrote:
Sun Sep 01, 2019 7:01 am
Now I can spare myself a lot of time and aggro if I have a small standalone for, say, Windows, which a potential customer can run on his/her system and it can tell me what sort of Windows
they are using and whether their computer is a 32-bit or a 64-bit machine.

This is particularly useful as most "crusty professors" of Sanskrit don't know very much about the innards of computers and their operating systems.
I think you'll get the best information switching for "the platform", and then using a suitable cmd line tool.

I have in use:
  1. Windows:

    Code: Select all

       put shell("systeminfo")
  2. Android:

    Code: Select all

       put "BOARD,BOOTLOADER,BRAND,CPU_ABI,CPU_ABI2,DEVICE,DISPLAY," & \
             "FINGERPRINT,HARDWARE,HOST,ID,MANUFACTURER,MODEL,PRODUCT," & \
             "RADIO,SERIAL,TAGS,TIME,TYPE,USER" into myData
       repeat for each item L in myData
          put "mobileBuildInfo(" & (quote & L & quote) & ")" into myTemp
          put L & ": " & value(myTemp) & CR after myVar
       end repeat	
       put myVar
For Linux, "uname", "lshw" and "lscpu" should do the job.

Have fun!
Livecode programming until the cat hits the fan ...

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7022
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Extension of systemVersion

Post by FourthWorld » Sun Sep 01, 2019 4:59 pm

If your app is running, it's compatible with the host OS. Just let your users enjoy that, and they'll never need to become CPU-savvy. If it won't run on their machine no additional functions well help, since they'll never be able to be called.
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

richmond62
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 3809
Joined: Fri Feb 19, 2010 10:17 am
Location: Bulgaria

Re: Extension of systemVersion

Post by richmond62 » Sun Sep 01, 2019 7:00 pm

If your app is running
Well, Yes . . .

But, let's suppose I release a DEMO version of my thing in various flavours,
and the Windows 32-bit version runs on Windows 64-bit, but "Dr Sanskrit",
were s/he to order a fully-licensed and fully-enabled version from me might
still be better served if s/he is sent a licensed version for Windows 64-bit. 8)

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

Re: Extension of systemVersion

Post by mwieder » Sun Sep 01, 2019 7:25 pm

Still not clear on this...

I can see why you'd want a 32-bit demo version running on 64-bit Windows.
But then "Dr Sanskrit" would select either the 32-bit or 64-bit version to order from you, no?
Are you suggesting that the demo version tell the user which version to order?
Or maybe the order form is in the demo version? And it would select for the user?

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

Re: Extension of systemVersion

Post by bogs » Sun Sep 01, 2019 8:27 pm

I think the most likely reason you'd want 'the processor' to tell you the actual processor, or 'the machine' to give you an in-depth description of the hardware your running on, would be system requirement testing. The rest of the functions cover the rest of the requirements in that scenario pretty well.

But lets take a look at it from a backwards view if you will.

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.

Now, I don't know how resource intensive Richmond's Deva Writer is, but instead of that, let us say you were making a bench marking utility. I think the very least you'd have to know is the processor (and as much about it as you could find out, make/cores/mhz/86-64/etc... directly from the hardware and not from the OS), the amount of ram, what kind of hard drives, chipset, graphics card, monitor, etc etc etc. just for the reporting part of the tool. At least, I haven't seen very many good tools of that kind that can't tell you what kind of system your running.

Another example, your writing a game. You know below certain specs, this game will run like doo-doo. In the demo and release version of your game, you could include the test by having Lc tell you the hardware the game will be running on. You then can tell the end user "Hey blockhead, your system is going to run this game like DOO-DOO you cheap skate! Put another gig of ram in you miser!! And how about a video card newer than the '80s !??!" :P

Either of the two functions discussed here would be ideal for that kind of information, but despite the descriptions of them, neither actually does anything close to this. For that matter, you could drop 'the processor' altogether if you felt like it, and just bulk up 'the machine' so the programmer could pick and choose what he/she wants to, but since it is existing, why not make it do what it says it should be doing?
Image

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

Re: Extension of systemVersion

Post by mwieder » Sun Sep 01, 2019 8:58 pm

I see two things going on in this thread:

1. I need a way to determine which build to distribute to a given customer.
2. I want in-depth information about my client's machine for debugging, etc.

#1 is pretty easy to do from a scripting level, so I don't see the need to bother the engine files with it.
#2 is also doable from a script, although it takes a bit more environment-sensitive scripting to take care of, and then I don't think you can generate any useful cross-platform results.

I don't know if anyone is using the systemVersion currently... it doesn't seem very useful. On my system I get just the kernel:
Linux 4.15.0-58-generic

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

Re: Extension of systemVersion

Post by bogs » Sun Sep 01, 2019 9:05 pm

mwieder wrote:
Sun Sep 01, 2019 8:58 pm
it doesn't seem very useful. On my system I get just the kernel:
Linux 4.15.0-58-generic
...which is more than 'the platform' gives you by a yard :D

Code: Select all

 put "The systemVersion is" && the systemVersion & cr \
 & "The platform is " & the platform 
The systemVersion is Linux 4.19.0-5-amd64
The platform is Linux
Of those two, the platform gives you less than what I'd be looking for in a series of if/then or case statements determining what to do on a given system. On linux, the kernel version could mean a *lot*.
Image

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

Re: Extension of systemVersion

Post by mwieder » Sun Sep 01, 2019 9:52 pm

Possibly, but I'd be more concerned about the distro and desktop manager. Ubuntu? Debian? KDE? Gnome? Cinnamon? Mate? xfce?

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

Re: Extension of systemVersion

Post by bogs » Sun Sep 01, 2019 10:21 pm

Well, I'm sure you already know how to 'cat' that stuff, and it might matter if Lc was designed to run on every distro, but since that isn't the case, you really only have to know if it is running on Ubuntu, Mint, or straight Debian maybe.

Unless the desktop is Gnome, I'm not sure I'd be counting on a lot for the decorations being correct. I can't tell if the menu issue was fixed or not. I'll have to load an ubuntu machine at some point to find out, since I never checked beyond the thread that came up in.

*Edit - My bad, there is also Redhat gnome and I *think* SUSE gnome :|
Image

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

Re: Extension of systemVersion

Post by mwieder » Sun Sep 01, 2019 10:29 pm

My point, though, was that returning the kernel version by itself doesn't really help with any of that.
Except possibly the data point of "the client hasn't updated the kernel".

Post Reply

Return to “Feature Requests”