Page 2 of 6

Re: Extension of systemVersion

Posted: Sat Aug 31, 2019 11:32 pm
by FourthWorld
If the processor doesn't return the processor please file a bug report.

Re: Extension of systemVersion

Posted: Sun Sep 01, 2019 3:09 am
by mwieder
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.

Re: Extension of systemVersion

Posted: Sun Sep 01, 2019 6:44 am
by bogs
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

Re: Extension of systemVersion

Posted: Sun Sep 01, 2019 7:01 am
by richmond62
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

Re: Extension of systemVersion

Posted: Sun Sep 01, 2019 11:37 am
by LCMark
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.

Re: Extension of systemVersion

Posted: Sun Sep 01, 2019 2:11 pm
by AxWald
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!

Re: Extension of systemVersion

Posted: Sun Sep 01, 2019 4:59 pm
by FourthWorld
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.

Re: Extension of systemVersion

Posted: Sun Sep 01, 2019 7:00 pm
by richmond62
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)

Re: Extension of systemVersion

Posted: Sun Sep 01, 2019 7:25 pm
by mwieder
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?

Re: Extension of systemVersion

Posted: Sun Sep 01, 2019 8:27 pm
by bogs
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?

Re: Extension of systemVersion

Posted: Sun Sep 01, 2019 8:58 pm
by mwieder
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

Re: Extension of systemVersion

Posted: Sun Sep 01, 2019 9:05 pm
by bogs
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*.

Re: Extension of systemVersion

Posted: Sun Sep 01, 2019 9:52 pm
by mwieder
Possibly, but I'd be more concerned about the distro and desktop manager. Ubuntu? Debian? KDE? Gnome? Cinnamon? Mate? xfce?

Re: Extension of systemVersion

Posted: Sun Sep 01, 2019 10:21 pm
by bogs
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 :|

Re: Extension of systemVersion

Posted: Sun Sep 01, 2019 10:29 pm
by mwieder
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".