Re: Missing plugins to make the vmProfiler work

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Missing plugins to make the vmProfiler work

csrabak
On 12 May 2017 07:40:49 -0700, Eliot Miranda <[hidden email]> wrote:
 
> Hi Cesar,
 
[snipped]
 
Hi Eliot,

> > 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
>
Thank you Eliot!
 
You'll not believe the number of times I typed and backtyped about
listLoadedModules!
 
I keep thinking if I was not being too 'pushy' on my stance. . . :-)
 
If after a serene consideration of the group and finding that would be
right direction for Pharo, we can consider breaking this method in
two:
 
Smalltalk listLoadedModules
 
Smalltalk listLoadedPlugins
 
And in the future have this info exposed in the World menus.
 
Regards,
--
Cesar Rabak
 
Reply | Threaded
Open this post in threaded view
|

Re: Missing plugins to make the vmProfiler work

Nicolas Cellier


2017-05-12 22:32 GMT+02:00 <[hidden email]>:
On 12 May 2017 07:40:49 -0700, Eliot Miranda <[hidden email]> wrote:
 
> Hi Cesar,
 
[snipped]
 
Hi Eliot,

> > 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
>
Thank you Eliot!
 
You'll not believe the number of times I typed and backtyped about
listLoadedModules!
 
I keep thinking if I was not being too 'pushy' on my stance. . . :-)
 
If after a serene consideration of the group and finding that would be
right direction for Pharo, we can consider breaking this method in
two:
 
Smalltalk listLoadedModules
 
Smalltalk listLoadedPlugins
 
And in the future have this info exposed in the World menus.
 
Regards,
--
Cesar Rabak
 

But from the image POV is there any difference between an internal module and an external plugin ?
If none, what would justify such split ?
Additional complexity has to pay back or die.