Missing plugins to make the vmProfiler work on Pharo
Locked
Missing plugins to make the vmProfiler work on Pharo
 
|
Hi Esteban, Hi all, I am working on porting the Squeak VMProfiler to Pharo as a gsoc (I will post a more detailed presentation about that in the mailing list later today). While trying to use the profiler with the Pharo VM, I get the following error : "PrimitiveFailed : primitive #primitiveExecutableModules in VMProfilerLinuxSymbolsManager failed". (see stack trace attached). This plugin (VMProfileLinuxSupportPlugin) does not seem to be included by default in the Pharo VM (it works with a Squeak VM). I haven't tried on a mac, but I guess the plugin (VMProfileMacSupportPlugin) is missing too. For the moment, I am using the latest Squeak VM with my Pharo image but it is not quite convenient. Would it be possible to include the 2 plugins to the Pharo VM ? If I can be of any help, just tell me Thanks! Sophie |
PrimitiveFailed.jpg (91K) |
|
Hi Sophie,
You will have to compile your own VM for the moment. It's fairly easy but you might run into problems when including the extra plugin. To build the VM, follow the instructions on https://github.com/OpenSmalltalk/opensmalltalk-vm and read the README and HOWTO files. Simple build example: cd ~/git/opensmalltalk-vm/build.macos32x86/pharo.cog.spur/ && ./mvm -d will build a debug VM. You'll have to modify one of the "plugins.*" files to include the plugin. HTH, Max
|
Re: Missing plugins to make the vmProfiler work on Pharo
|
|
Hi Max, She has already done that. The point is to add the plugins in the default Pharo VM, so everyone can use the VM profiler. We would like to have the VM profiler loadable through the Pharo catalog, but many people won't be able to use it if the default Pharo VM does not support it... The plugin is lightweight, so I don't see why we can't have it. Best, On Wed, May 10, 2017 at 3:00 PM, Max Leske <[hidden email]> wrote:
|
|
|
OK, I see.
|
Re: Missing plugins to make the vmProfiler work on Pharo
|
|
Hi Sophie, Then let Esteban accept the request or not before the release of Pharo... (if the build are green, there's no reason to not accept it).you could try and modify the plugins.int or plugins.ext files for various pharo distributions and do a pull request on github opensmalltalk-vm. 2017-05-10 15:39 GMT+02:00 Max Leske <[hidden email]>:
|
Re: Missing plugins to make the vmProfiler work on Pharo
|
|
If it is a plug-in, why does it need VM recompilation?
Esteban A. Maringolo 2017-05-10 12:15 GMT-03:00 Nicolas Cellier <[hidden email]>: > Hi Sophie, > you could try and modify the plugins.int or plugins.ext files for various > pharo distributions and do a pull request on github opensmalltalk-vm. > Then let Esteban accept the request or not before the release of Pharo... > (if the build are green, there's no reason to not accept it). > > 2017-05-10 15:39 GMT+02:00 Max Leske <[hidden email]>: >> >> OK, I see. >> >> >> On 10 May 2017, at 15:11, Clément Bera <[hidden email]> wrote: >> >> Hi Max, >> >> She has already done that. The point is to add the plugins in the default >> Pharo VM, so everyone can use the VM profiler. We would like to have the VM >> profiler loadable through the Pharo catalog, but many people won't be able >> to use it if the default Pharo VM does not support it... >> >> The plugin is lightweight, so I don't see why we can't have it. >> >> Best, >> >> On Wed, May 10, 2017 at 3:00 PM, Max Leske <[hidden email]> wrote: >>> >>> Hi Sophie, >>> >>> You will have to compile your own VM for the moment. It's fairly easy but >>> you might run into problems when including the extra plugin. To build the >>> VM, follow the instructions on >>> https://github.com/OpenSmalltalk/opensmalltalk-vm and read the README and >>> HOWTO files. Simple build example: >>> >>> cd ~/git/opensmalltalk-vm/build.macos32x86/pharo.cog.spur/ && ./mvm -d >>> >>> will build a debug VM. You'll have to modify one of the "plugins.*" files >>> to include the plugin. >>> >>> HTH, >>> Max >>> >>> On 10 May 2017, at 14:36, Sophie Kaleba <[hidden email]> wrote: >>> >>> Hi Esteban, Hi all, >>> >>> I am working on porting the Squeak VMProfiler to Pharo as a gsoc (I will >>> post a more detailed presentation about that in the mailing list later >>> today). >>> >>> While trying to use the profiler with the Pharo VM, I get the following >>> error : "PrimitiveFailed : primitive #primitiveExecutableModules in >>> VMProfilerLinuxSymbolsManager failed". (see stack trace attached). >>> >>> This plugin (VMProfileLinuxSupportPlugin) does not seem to be included by >>> default in the Pharo VM (it works with a Squeak VM). I haven't tried on a >>> mac, but I guess the plugin (VMProfileMacSupportPlugin) is missing too. >>> >>> For the moment, I am using the latest Squeak VM with my Pharo image but >>> it is not quite convenient. Would it be possible to include the 2 plugins to >>> the Pharo VM ? >>> >>> If I can be of any help, just tell me >>> Thanks! >>> >>> Sophie >>> >>> >>> >>> >>> >>> >>> <PrimitiveFailed.jpg> >>> >>> >> >> > |
Re: Missing plugins to make the vmProfiler work on Pharo
|
|
On Wed, May 10, 2017 at 5:28 PM, Esteban A. Maringolo <[hidden email]> wrote: If it is a plug-in, why does it need VM recompilation? Internal plugins require VM recompilation. Only external plugins do not.
|
Re: Missing plugins to make the vmProfiler work on Pharo
|
|
In reply to this post by Nicolas Cellier
Thanks for your help! @Nicolas, I'll do it that way 2017-05-10 17:15 GMT+02:00 Nicolas Cellier <[hidden email]>:
|
Re: Missing plugins to make the vmProfiler work on Pharo
|
|
In reply to this post by Clément Béra
2017-05-10 13:38 GMT-03:00 Clément Bera <[hidden email]>:
> On Wed, May 10, 2017 at 5:28 PM, Esteban A. Maringolo <[hidden email]> wrote: >> If it is a plug-in, why does it need VM recompilation? > > Internal plugins require VM recompilation. Only external plugins do not. It was more of a semantic question, I'd expect a plug-in to be that, pluggable, as you say external plugins are. Or what is the "pluggability" of such plugins? Disclaimer: I don't know about the VM internals (*), and this is not a complain of any sort. I just wonder it is called that way. Regards! Esteban A. Maringolo (*) I did compile a Squeak VM a decade ago (added two primitives) but nothing more than that. |
Re: Missing plugins to make the vmProfiler work on Pharo
|
|
On Wed, May 10, 2017 at 8:12 PM, Esteban A. Maringolo <[hidden email]> wrote: 2017-05-10 13:38 GMT-03:00 Clément Bera <[hidden email]>: I would say there is 3 levels of pluggability: 1 non optional internal plugin, pluggable because it can be replaced by another internal plugin implementing the same API at VM compilation time. Used for modularity of specific aspects of the VM. 2 optional internal plugin, pluggable because it can be removed / added / replaced at VM compilation time. Used to improve performance over external plugin or to access VM functions not exposed to external plugins. 3 external plugin, pluggable because it can be removed / added / replaced after the VM is compiled. Used for all other plugins. So they're all pluggable in some way.
|
Re: Missing plugins to make the vmProfiler work on Pharo
|
|
2017-05-11 11:34 GMT+02:00 Clément Bera <[hidden email]>:
External plugins have to use a well defined API for all interactions with VM. Internal plugins not only could have access to unexposed functions, but can also inline some of these functions as recently introduced by Eliot (https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/7fa0184ef8c7c8badb70942c5f17693f8e622426), so the performance might be a criterion of choice. From a packaging POV, making a plugin external is a source of trouble versus embedded internal plugins. The number of possible combinations can rapidly explode (think of testing). It is essentially for letting user choose: - to not embed the plugin * because he knows he ain't gonna need it, and he wants to limit the memory footprint * or because the plugins expose some security issues - to replace a plugin with an alternative version - to produce his own plugins without bothering to recompile the whole VM (or just update the VM without the need to update the plugin because the major revision of API did not change)
|
|
|
In reply to this post by SophieKaleba
On Thu, 11 May 2017 11:34:47 +0200, Cl?ment Bera <[hidden email]> wrote:
> On Wed, May 10, 2017 at 8:12 PM, Esteban A. Maringolo > <[hidden email]> wrote: > > > 2017-05-10 13:38 GMT-03:00 Cl?ment Bera <[hidden email]>: > > > On Wed, May 10, 2017 at 5:28 PM, Esteban A. Maringolo < > > [hidden email]> wrote: > > > > >> If it is a plug-in, why does it need VM recompilation? > > > Internal plugins require VM recompilation. Only external plugins > > > do not. > > It was more of a semantic question, I'd expect a plug-in to be > > that, pluggable, as you say external plugins are. Or what is the > > "pluggability" of such plugins? > > > I would say there is 3 levels of pluggability: 1 non optional > internal plugin, pluggable because it can be replaced by another > internal plugin implementing the same API at VM compilation time. > Used for modularity of specific aspects of the VM. 2 optional > internal plugin, pluggable because it can be removed / added / > replaced at VM compilation time. Used to improve performance over > external plugin or to access VM functions not exposed to external > plugins. 3 external plugin, pluggable because it can be removed / > added / replaced after the VM is compiled. Used for all other > plugins. > So they're all pluggable in some way. > That written, and without attempting to start a semantic discussion, however feeling a contribution may be useful, I would say that the 'levels' one and two described above would better called "modules" instead of plugins. In my way of understanding this non mother tongue "compile time plugins" seem to be more a figure of speech than the offering of 'plugability' which plugins offer, or perhaps, in my humble perception ought to offer. Also, I think it would be less surprising for most people when exposed to the subject (module == compiling, plugin == run time). Just my 0,0199999.... -- Cesar Rabak |
Re: Missing plugins to make the vmProfiler work on Pharo
|
|
Hi Cesar,
> On May 11, 2017, at 12:10 PM, [hidden email] wrote: > >> On Thu, 11 May 2017 11:34:47 +0200, Cl?ment Bera <[hidden email]> wrote: >> >> On Wed, May 10, 2017 at 8:12 PM, Esteban A. Maringolo >> <[hidden email]> wrote: >> >>> 2017-05-10 13:38 GMT-03:00 Cl?ment Bera <[hidden email]>: >>>> On Wed, May 10, 2017 at 5:28 PM, Esteban A. Maringolo < >>> [hidden email]> wrote: >>> >>>>> If it is a plug-in, why does it need VM recompilation? >>>> Internal plugins require VM recompilation. Only external plugins >>>> do not. >>> It was more of a semantic question, I'd expect a plug-in to be >>> that, pluggable, as you say external plugins are. Or what is the >>> "pluggability" of such plugins? >>> >> I would say there is 3 levels of pluggability: 1 non optional >> internal plugin, pluggable because it can be replaced by another >> internal plugin implementing the same API at VM compilation time. >> Used for modularity of specific aspects of the VM. 2 optional >> internal plugin, pluggable because it can be removed / added / >> replaced at VM compilation time. Used to improve performance over >> external plugin or to access VM functions not exposed to external >> plugins. 3 external plugin, pluggable because it can be removed / >> added / replaced after the VM is compiled. Used for all other >> plugins. >> So they're all pluggable in some way. >> > I'm on this vital industry for 45+ years and I already learned that words and names have usages and except when standarized via certains bodies aimed specifically the meaning can vary even within the same realm of the art. > > That written, and without attempting to start a semantic discussion, however feeling a contribution may be useful, I would say that the 'levels' one and two described above would better called "modules" instead of plugins. > > In my way of understanding this non mother tongue "compile time plugins" seem to be more a figure of speech than the offering of 'plugability' which plugins offer, or perhaps, in my humble perception ought to offer. > > Also, I think it would be less surprising for most people when exposed to the subject (module == compiling, plugin == run time). +1. I think the system designers agreed with you because the way to find out what plugins are available is Smalltalk listLoadedModules > Just my 0,0199999.... > > -- > Cesar Rabak _,,,^..^,,,_ (phone) |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |