Smalltalk › Pharo › Pharo Smalltalk Developers

VirtualMachine vs. Platform and Bootstrap

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Torsten Bergmann

VirtualMachine vs. Platform and Bootstrap

Hi,

1. We can query for the VIRTUAL MACHINE and ask if it is 32 or 64 bit (internally depending on wordSize):

Smalltalk vm is32Bit

Anything OK on that side.

2. We can also query for the OPERATING SYSTEM we are running on using:

Smalltalk os

and there are subclasses for OSPlatform like Win32Platform, Win64Platform as well as Unix32Platform,
unix64Platform, ...

But when I evaluate "Smalltalk os" in Pharo 7 Build #70552

2a) I receive a Win32Platform instance which means 32 bit although I'm running on a Win 64 system
2b) I receive a Unix32Platform instance which means 32 bit although I'm running on a Ubuntu 64 system

I see this as a clear bug and very confusing

The reason for this behavior is simple: because I run with the 32 bit VM/image on these two 64 bit operating
systems and in Pharo:

for 2a) the#isActivePlatform method ask the VM (???)for the platform name (which is Win32 then)

for 2b) the#isActivePlatform method also considers the word size from the VM (???)

But to me the "os" should give me infos about the underlying operating system and is currently
returning a wrong instance (because it falls back to querying about the running VM, not the real platform)

This would be easy to fix with some UFFI calls (for instance piping from "uname -i" on Unix or "ver" on Windows).
With UFFI I would also be able to give more and better infos in the platform hierarchy about the underlying OS.

But doing this would introduce a dependency from the "Systems-Platforms" package to "UFFI" (and currently my
understanding is that UFFI comes later)

From what I understood from the comment in getPwdViaFFI:with we also would like to focus on a minimal dependency
for bootstrap ... and only depend on FFI and not UFFI.

Any comments how we could deal with that best?

Thx
T.

Henrik Sperre Johansen

Re: VirtualMachine vs. Platform and Bootstrap

It's a question of responsibilities.
Right now, it's used to determine which dll's to use on linux (on linux, see
ffiModuleName), which means the distinction between 32/64 platforms is which
ABI to use when doing UFFI, or more accurately, where to find libraries for
the ABI supported by the vm.
To make things less confusing, it would be better to remove the 32/64
subclasses from platform, (since they are really a separation only relevant
to UFFI) and have the ffiModuleName: extension branch on Smalltalk vm
is32/64 as appropriate for UnixPlatform.

Then one would be free to implement either 32/64 subclasses as you suggest
if there's prim support, or a #getDetailedPlatformInfo dependent on FFI to
fetch more specific details like 32/64 bit, actual windows version, etc..

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Guillermo Polito

Re: VirtualMachine vs. Platform and Bootstrap

In reply to this post by Torsten Bergmann

On Fri, Feb 16, 2018 at 10:18 AM, Torsten Bergmann <[hidden email]> wrote:

Hi,

1. We can query for the VIRTUAL MACHINE and ask if it is 32 or 64 bit (internally depending on wordSize):

Smalltalk vm is32Bit

Anything OK on that side.

2. We can also query for the OPERATING SYSTEM we are running on using:

Smalltalk os

and there are subclasses for OSPlatform like Win32Platform, Win64Platform as well as Unix32Platform,
unix64Platform, ...

But when I evaluate "Smalltalk os" in Pharo 7 Build #70552

2a) I receive a Win32Platform instance which means 32 bit although I'm running on a Win 64 system
2b) I receive a Unix32Platform instance which means 32 bit although I'm running on a Ubuntu 64 system

I see this as a clear bug and very confusing

Yup.

The reason for this behavior is simple: because I run with the 32 bit VM/image on these two 64 bit operating
systems and in Pharo:

for 2a) the#isActivePlatform method ask the VM (???)for the platform name (which is Win32 then)

for 2b) the#isActivePlatform method also considers the word size from the VM (???)

But to me the "os" should give me infos about the underlying operating system and is currently
returning a wrong instance (because it falls back to querying about the running VM, not the real platform)

This would be easy to fix with some UFFI calls (for instance piping from "uname -i" on Unix or "ver" on Windows).
With UFFI I would also be able to give more and better infos in the platform hierarchy about the underlying OS.

But doing this would introduce a dependency from the "Systems-Platforms" package to "UFFI" (and currently my
understanding is that UFFI comes later)

From what I understood from the comment in getPwdViaFFI:with we also would like to focus on a minimal dependency
for bootstrap ... and only depend on FFI and not UFFI.

Well, but that's because the working directory is needed at bootstrap time. Take into account that the packages that belong to the bootstrap are those listed in

BaselineOfPharoBootstrap

System-Platforms is listed there, but maybe it is not so necessary? We should check what are the usages of it.

In any case, what I'd say is that "stuff" that is not really needed at bootstrap time should be loaded afterwards, maybe as a separate package with extension methods?

And in that case you're free to go and use uFFI, that should be no problem.

Just take into account that uFFI is loaded by BaselineOfMorphicCore nowadays.

Any comments how we could deal with that best?

Thx
T.

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr

Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Ben Coman

Re: VirtualMachine vs. Platform and Bootstrap

On 19 February 2018 at 17:35, Guillermo Polito <[hidden email]> wrote:

On Fri, Feb 16, 2018 at 10:18 AM, Torsten Bergmann <[hidden email]> wrote:
Hi,

1. We can query for the VIRTUAL MACHINE and ask if it is 32 or 64 bit (internally depending on wordSize):

Smalltalk vm is32Bit

Anything OK on that side.

2. We can also query for the OPERATING SYSTEM we are running on using:

Smalltalk os

and there are subclasses for OSPlatform like Win32Platform, Win64Platform as well as Unix32Platform,
unix64Platform, ...

But when I evaluate "Smalltalk os" in Pharo 7 Build #70552

2a) I receive a Win32Platform instance which means 32 bit although I'm running on a Win 64 system
2b) I receive a Unix32Platform instance which means 32 bit although I'm running on a Ubuntu 64 system

I see this as a clear bug and very confusing

Yup.

The reason for this behavior is simple: because I run with the 32 bit VM/image on these two 64 bit operating
systems and in Pharo:

for 2a) the#isActivePlatform method ask the VM (???)for the platform name (which is Win32 then)

for 2b) the#isActivePlatform method also considers the word size from the VM (???)

But to me the "os" should give me infos about the underlying operating system and is currently
returning a wrong instance (because it falls back to querying about the running VM, not the real platform)

Good point, but to be pedantic I'd say "not the real OS" rather than "not the real platform".

Would it be correct to distinguish between OS and Platform?

where Platform is your compile target, and OS is where you run the exe ??

Thus the fix would not be just for "Smalltalk os" ==> Win64Platform but to introduce

"Smalltalk platform" ==> Win64Platform for 64 bit VM and ==> Win32Platform for 32 bit VM.

and "Smalltalk os" ==> something else entirely.

or maybe I'm completely off base.

cheers -ben

This would be easy to fix with some UFFI calls (for instance piping from "uname -i" on Unix or "ver" on Windows).
With UFFI I would also be able to give more and better infos in the platform hierarchy about the underlying OS.

But doing this would introduce a dependency from the "Systems-Platforms" package to "UFFI" (and currently my
understanding is that UFFI comes later)

From what I understood from the comment in getPwdViaFFI:with we also would like to focus on a minimal dependency
for bootstrap ... and only depend on FFI and not UFFI.

Well, but that's because the working directory is needed at bootstrap time. Take into account that the packages that belong to the bootstrap are those listed in

BaselineOfPharoBootstrap

System-Platforms is listed there, but maybe it is not so necessary? We should check what are the usages of it.
In any case, what I'd say is that "stuff" that is not really needed at bootstrap time should be loaded afterwards, maybe as a separate package with extension methods?
And in that case you're free to go and use uFFI, that should be no problem.

Just take into account that uFFI is loaded by BaselineOfMorphicCore nowadays.

Any comments how we could deal with that best?

Thx
T.

--

Guille Polito
Research Engineer
Centre de Recherche en Informatique, Signal et Automatique de Lille
CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr

Web: http://guillep.github.io

Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13