LiveCode Forums

@Klaus: It has taken years for Apple to get to a reasonable, understandable and sensible rule in this regard. The relevant clause of the Apple Developer Agreement is: 3.3.2 Except as set forth in the next paragraph, an Application may not download or install executable code. Interpreted code may be ...

@trevordevore: Yes - callbacks passed to win32 API functions should work on 64-bit Windows for this reason (callbacks work in 32-bit too, but they pass a cdecl calling convention function pointer - which isn't compatible with Win32 API callback functions usually).

@SparkOut : 64-bit windows processes cannot load 32-bit DLLs (and vice-versa) - so (as you already figured out) you need to include the 64-bit version of the DLL in the relevant code folder to work with the 64-bit engine. The subsequent error would appear to be a bug in the LCB VM - try a version of...

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 ...

I feel that I should urge any readers of the suggestion of using Cydia Importer to side-load applications as suggested in the post above to do so with the utmost care. Specifically: Do not use it on any iOS device which you use on a day-to-day basis and as a result holds saved login details for any ...

As 'trueword' cuts the mustard for the vast majority of writing systems I wonder what the utility of 'word' is at all, and wonder whether it might not be a good idea to transfer the functionality of 'trueword' to 'word' and then remove 'trueword' altogether. The word chunk (which now also has the s...

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 a...

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 equivale...

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 i...

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 processo...

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 bee...

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 ...

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 wo...

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 proces...

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 designe...