Re: [Pharo-dev] PID of VM ?
On Sep 14, 2015, at 11:04 AM, Sven Van Caekenberghe <sven@stfx.eu> 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."
On 14 Sep 2015, at 11:12, Skip Lentz <skip.lentz@inria.fr> wrote:
On Sep 14, 2015, at 11:04 AM, Sven Van Caekenberghe <sven@stfx.eu> 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 ?
On 14 Sep 2015, at 14:08, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 14 Sep 2015, at 11:12, Skip Lentz <skip.lentz@inria.fr> wrote:
On Sep 14, 2015, at 11:04 AM, Sven Van Caekenberghe <sven@stfx.eu> 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 ?
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:
On 14 Sep 2015, at 11:12, Skip Lentz <skip.lentz@inria.fr> wrote:
On Sep 14, 2015, at 11:04 AM, Sven Van Caekenberghe <sven@stfx.eu> 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 ?
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
On 14 Sep 2015, at 14:21, David T. Lewis <lewis@mail.msen.com> wrote:
On Mon, Sep 14, 2015 at 02:08:54PM +0200, Sven Van Caekenberghe wrote:
On 14 Sep 2015, at 11:12, Skip Lentz <skip.lentz@inria.fr> wrote:
On Sep 14, 2015, at 11:04 AM, Sven Van Caekenberghe <sven@stfx.eu> 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 ?
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.
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 2:25 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 14 Sep 2015, at 14:21, David T. Lewis <lewis@mail.msen.com> wrote:
On Mon, Sep 14, 2015 at 02:08:54PM +0200, Sven Van Caekenberghe wrote:
On 14 Sep 2015, at 11:12, Skip Lentz <skip.lentz@inria.fr> wrote:
On Sep 14, 2015, at 11:04 AM, Sven Van Caekenberghe <sven@stfx.eu>
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 ?
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.
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?
Would be nice to have it in. It is one of the first things I load in my images. How else can we access environment variables, pids, ... ? Beware: some version have issues of performance (in Pharo3). Phil
Esteban
Dave
On Mon, Sep 14, 2015 at 8:25 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 14 Sep 2015, at 14:21, David T. Lewis <lewis@mail.msen.com> wrote:
On Mon, Sep 14, 2015 at 02:08:54PM +0200, Sven Van Caekenberghe wrote:
On 14 Sep 2015, at 11:12, Skip Lentz <skip.lentz@inria.fr> wrote:
On Sep 14, 2015, at 11:04 AM, Sven Van Caekenberghe <sven@stfx.eu> 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 ?
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.
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?
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
On 14 Sep 2015, at 15:18, Ben Coman <btc@openinworld.com> wrote:
On Mon, Sep 14, 2015 at 8:25 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
On 14 Sep 2015, at 14:21, David T. Lewis <lewis@mail.msen.com> wrote:
On Mon, Sep 14, 2015 at 02:08:54PM +0200, Sven Van Caekenberghe wrote:
On 14 Sep 2015, at 11:12, Skip Lentz <skip.lentz@inria.fr> wrote:
On Sep 14, 2015, at 11:04 AM, Sven Van Caekenberghe <sven@stfx.eu> 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 ?
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.
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?
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
as you maybe noticed, we are slowly moving to an âall is configuredâ scheme. Which means everything included in image is both included AND external :) the first step of that is not accepting framework contributions without their configurations⦠of course that means our tools need to improve because there are badly prepared to the task⦠but we are doing it. In an ideal world, Pharo will be a small kernel + a list of modules included through configurations (it will take time, but we will be there). Esteban
cheer -ben
On Mon, Sep 14, 2015 at 8:25 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 14 Sep 2015, at 14:21, David T. Lewis <lewis@mail.msen.com> wrote:
No, OSProcess should not be included in the image. It is intended to be an external package.
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?
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
Yes, that is what I meant. Dave
On 14 Sep 2015, at 18:46, David T. Lewis <lewis@mail.msen.com> wrote:
On Mon, Sep 14, 2015 at 8:25 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 14 Sep 2015, at 14:21, David T. Lewis <lewis@mail.msen.com> wrote:
No, OSProcess should not be included in the image. It is intended to be an external package.
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?
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
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 <sven@stfx.eu> wrote:
On 14 Sep 2015, at 18:46, David T. Lewis <lewis@mail.msen.com> wrote:
On Mon, Sep 14, 2015 at 8:25 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 14 Sep 2015, at 14:21, David T. Lewis <lewis@mail.msen.com> wrote:
No, OSProcess should not be included in the image. It is intended to be an external package.
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?
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
Yes, that is what I meant.
Dave
Several packages are in that situation: Zinc, STON, FUEL, ... it works quite well.
In fact, Fuel was integrated in the "traditionally-in-Image" style, but at some point we could switch to the new trend. MartÃn
participants (7)
-
Ben Coman -
David T. Lewis -
Esteban Lorenzano -
Martin Dias -
phil＠highoctane.be -
Skip Lentz -
Sven Van Caekenberghe