PID of VM ?

Hi,

Is there a way to get the operating system PID of the running Pharo VM from inside the image ?

If not, I think that would be a nice addition.

Sven

Did anyone ever look at my OS projects at http://smalltalkhub.com/#!/~OS
where I try to unify the native platforms (to keep platform independence)
while on the other side allow to use native functionality as much as possible:


Gofer it
        smalltalkhubUser: 'Pharo' project: 'MetaRepoForPharo40';
        configurationOf: 'OSUnix';
        loadVersion: #stable.

=>  UnixProcess currentProcessId



Gofer it
        smalltalkhubUser: 'Pharo' project: 'MetaRepoForPharo40';
        configurationOf: 'OSWindows';
        loadVersion: #stable.
       
=>  WinProcess currentProcessId

Have fun
T.

> On Sep 14, 2015, at 11:04 AM, Sven Van Caekenberghe <[hidden email]> wrote:
>
> Hi,
>
> Is there a way to get the operating system PID of the running Pharo VM from inside the image ?

If I’m not mistaken, it is what OSProcess is for. I think this should be it:

> OSProcess thisOSProcess pid.

The comment of thisOSProcess says:

"Answer a single instance of the class corresponding to the OS process in which this Smalltalk image is executing."

OK, that seems to works in Pharo 5. Thanks.

I don't know the overall status of OSProcess in Pharo though. Is is 100% supported in all current versions, 3.0, 4.0 and 5.0 ? Is it based on a plugin or on native boost ? Should it be included by default ?

OK, that works, thanks.

Pretty straightforward NativeBoost based code, small.

I seem to be missing the platform independence code (but I only care for OS X and Linux for my projects).

How does this relate to OSProcess ? Why did you start it ? What is the goal ?

100%
Plugin
yes it should :)

Esteban

ps: But the plugin has some problems in windows. So, it is supported 100% of the support it provides… so we need to improve that :P

>
>
>

On Mon, Sep 14, 2015 at 02:08:54PM +0200, Sven Van Caekenberghe wrote:
It should be working in all Pharo versions. It is based on a VM plugin.

I am the author of OSProcess, and I try to keep it working in Pharo as well
as Squeak. Thierry Goubier also works on OSProcess for Pharo (and he has write
access to the repository).

No, OSProcess should not be included in the image. It is intended to be
an external package.

Dave

mmm… we want to include it as more and more people requires it and we can profit from having it in the image (same as FFI).
why do you think it should be external?

Esteban

>
> Dave
>
>

On Mon, Sep 14, 2015 at 8:25 PM, Esteban Lorenzano <[hidden email]> wrote:
We should distinguish between having it traditionally-in-Image where
that is the only place it exists and fixes are integrated, and the
current trend (e.g. in-Image Glamorous Tools) where fixes are
integrated "upstream" into an external package

cheer -ben

Yes, that is what I meant.

Dave

Several packages are in that situation: Zinc, STON, FUEL, ... it works quite well.

On Mon, Sep 14, 2015 at 7:00 PM, Sven Van Caekenberghe <[hidden email]> wrote:
In fact, Fuel was integrated in the "traditionally-in-Image" style,
but at some point we could switch to the new trend.

Martín

Sven wrote:
> OK, that works, thanks.
>
> Pretty straightforward NativeBoost based code, small.
>
> I seem to be missing the platform independence code (but I only care for OS X and Linux for my projects).
>
> How does this relate to OSProcess ? Why did you start it ? What is the goal ?


OSProcess is nice - but it requires a plugin, compilation, etc. It also only covers some basic functions
that are sharable for platforms. Using NativeBoost allows for speed and easy changeability in Pharo itself.

I started "OS" because I required more and more things from Windows that OSProcess can never cover. Later
beside "OS-Windows" I added other platforms like "OS-Unix"/"OS-Ubuntu".

The "OS" project tries to provide the same interface for things that are close in each operating
system but still includes things that are available on specific platforms only like Windows.

For instance in Windows there is the Windows registry - you can access it with this project. It would
not make sense to have this for Unix systems. Another example: the OS-Linux-Ubuntu-Environment package
includes a class UbuntuShell that you can use the open the gnome system monitor. You can use it if
you are on this particular platform by evaluating

   UbuntuShell systemMonitor

If on another platform it would not make sense to use it.

Still while allowing to be as much "as native" as possible with the platform it is/should be possible to keep
some kind of "platform independence". This could be done by using same naming and compatibility could be enforced by
Tests (because of the lack of "interfaces" in Smalltalk) and similar naming:

  UnixProcess currentProcessId
  WinProcess currentProcessId

Anything other is explained in
http://www.smalltalkhub.com/#!/~OS/OS-Windows

I hoped other jumped onto the bandwagon to help because at least on Mac I'm currently lost (until I access to
an iOS machine).

Currently I do not invest too much into it - especially because of this bad feeling that was given
that NativeBoost might not be continued and I heard about planes on refocusing back to (slower) FFI later.

So far NativeBoost served all my needs well and it would be a pitty if I would have to redo
all bindings later. :(

Bye
T.

Sven wrote:
> OK, that works, thanks.
>
> Pretty straightforward NativeBoost based code, small.
>
> I seem to be missing the platform independence code (but I only care for OS X and Linux for my projects).
>
> How does this relate to OSProcess ? Why did you start it ? What is the goal ?


OSProcess is nice - but it requires a plugin, compilation, etc. It also only covers some basic functions
that are sharable for platforms. Using NativeBoost allows for speed and easy changeability in Pharo itself.

I started "OS" because I required more and more things from Windows that OSProcess does not cover. Later
beside "OS-Windows" I added other platforms like "OS-Unix"/"OS-Ubuntu".

The "OS" project tries to provide the same interface for things that are close in each operating
system but still includes things that are available on specific platforms only like Windows.

For instance in Windows there is the Windows registry - you can access it with this project. It would
not make sense to have this for Unix systems. Another example: the OS-Linux-Ubuntu-Environment package
includes a class UbuntuShell that you can use the open the gnome system monitor. You can use it if
you are on this particular platform by evaluating

   UbuntuShell systemMonitor

If on another platform it would not make sense to use it.

Still while allowing to be as much "as native" as possible with the platform it is/should be possible to keep
some kind of "platform independence". This could be done by using same naming and compatibility could be enforced by
Tests (because of the lack of "interfaces" in Smalltalk) and similar naming:

  UnixProcess currentProcessId
  WinProcess currentProcessId

Anything other is explained in
http://www.smalltalkhub.com/#!/~OS/OS-Windows

I hoped other jumped onto the bandwagon to help because at least on Mac I'm currently lost (until I access to
an iOS machine).

Currently I do not invest too much into it - especially because of this bad feeling that was given
that NativeBoost might not be continued and I heard about planes on refocusing back to (slower) FFI later.

So far NativeBoost served all my needs well and it would be a pitty if I would have to redo
all bindings later. :(

Bye
T.

nativeboost is not maintained and we need a solution that can be
maintained by multiple people.
Normally with the new FFI esteban is doing you will be able to use the
NativeBoost syntax.
>
> Bye
> T.
>
>