Re: [Pharo-dev] [ANN] Pompeii Volcanic Graphics, a mesh based 2D graphics API

[Tudor Girba]

Hi Ronie,

This is fascinating work!

We will definitely look at this to see what it would take to have it as a Bloc 
backend.

And thanks a lot for tackling the SDL2/OSWindow issue. We will test that as 
well.

Cheers,
Doru


> On May 13, 2017, at 1:55 AM, Ronie Salgado  wrote:
> 
> Hi Alex,
> 
> This is great!
> Do you know whether Pompeii can be used by Bloc?
> I do not know. If the Bloc people pointed me to the places that have to be 
> modified, and if there are willing to have yet another backend, then I am 
> willing to try adding the backend for Bloc.
> 
> Best regards,
> Ronie
> 
> 2017-05-12 20:01 GMT-03:00 Alexandre Bergel :
> Hi Ronie,
> 
> This is great!
> Do you know whether Pompeii can be used by Bloc?
> 
> Alexandre
> 
> 
> > On May 12, 2017, at 6:26 PM, Ronie Salgado  wrote:
> >
> > Hello,
> >
> > I am releasing a first version of a new 2D graphics API that I am making 
> > for Pharo, using OpenGL.
> >
> > 
> > 
> >
> > http://smalltalkhub.com/#!/~ronsaldo/PompeiiGraphics
> > https://youtu.be/emE6_1RpAo8
> >
> > This 2D graphics API is not vectorial based becase it does not use SVG 
> > style paths. This API is triangle mesh based, so it is more friendlier with 
> > the GPU than Athens or Sparta.
> >
> > With this API I did a basic gui toolkit, with only two widgets: buttons and 
> > label. I did this Widget toolkit to not mess with Bloc, and because I need 
> > something relatively stable for the Woden 2 level editor. For now, I am 
> > leaving this widget toolkit mostly as a demo. Hopefully it is possible to 
> > make Bloc backend using this API.
> >
> > During the process of making this API, I had to fix several bugs with 
> > OSWindow, and bugs in the interaction between OSWindow and OpenGL. The 
> > biggest problem was a race condition between the creation of an OSWindow 
> > using SDL2, and the events (such as Expose) that are sent to the just 
> > created Window.
> >
> > As for Mac OS X, OSWindow is out of service until a pull request ( 
> > https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/138 ) gets 
> > integrated into the VM.
> >
> > Best regards,
> > Ronie
> 
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"One cannot do more than one can do."

Re: [Pharo-dev] Official cover for the Pharo booklet collection

[Damien Pollet]

Thanks :)

On 12 May 2017 at 23:18, Oleks  wrote:

> It looks wonderful!
>
>
>
> --
> View this message in context: http://forum.world.st/
> Official-cover-for-the-Pharo-booklet-collection-tp4946926p4946945.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>


-- 
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

Re: [Pharo-dev] [ANN] Pompeii Volcanic Graphics, a mesh based 2D graphics API

[Ronie Salgado]

Hi Alex,

This is great!
> Do you know whether Pompeii can be used by Bloc?
>
I do not know. If the Bloc people pointed me to the places that have to be
modified, and if there are willing to have yet another backend, then I am
willing to try adding the backend for Bloc.

Best regards,
Ronie

2017-05-12 20:01 GMT-03:00 Alexandre Bergel :

> Hi Ronie,
>
> This is great!
> Do you know whether Pompeii can be used by Bloc?
>
> Alexandre
>
>
> > On May 12, 2017, at 6:26 PM, Ronie Salgado  wrote:
> >
> > Hello,
> >
> > I am releasing a first version of a new 2D graphics API that I am making
> for Pharo, using OpenGL.
> >
> > 
> > 
> >
> > http://smalltalkhub.com/#!/~ronsaldo/PompeiiGraphics
> > https://youtu.be/emE6_1RpAo8
> >
> > This 2D graphics API is not vectorial based becase it does not use SVG
> style paths. This API is triangle mesh based, so it is more friendlier with
> the GPU than Athens or Sparta.
> >
> > With this API I did a basic gui toolkit, with only two widgets: buttons
> and label. I did this Widget toolkit to not mess with Bloc, and because I
> need something relatively stable for the Woden 2 level editor. For now, I
> am leaving this widget toolkit mostly as a demo. Hopefully it is possible
> to make Bloc backend using this API.
> >
> > During the process of making this API, I had to fix several bugs with
> OSWindow, and bugs in the interaction between OSWindow and OpenGL. The
> biggest problem was a race condition between the creation of an OSWindow
> using SDL2, and the events (such as Expose) that are sent to the just
> created Window.
> >
> > As for Mac OS X, OSWindow is out of service until a pull request (
> https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/138 ) gets
> integrated into the VM.
> >
> > Best regards,
> > Ronie
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

Re: [Pharo-dev] [ANN] Pompeii Volcanic Graphics, a mesh based 2D graphics API

[Alexandre Bergel]

Hi Ronie,

This is great!
Do you know whether Pompeii can be used by Bloc?

Alexandre


> On May 12, 2017, at 6:26 PM, Ronie Salgado  wrote:
> 
> Hello,
> 
> I am releasing a first version of a new 2D graphics API that I am making for 
> Pharo, using OpenGL.
> 
> 
> 
> 
> http://smalltalkhub.com/#!/~ronsaldo/PompeiiGraphics
> https://youtu.be/emE6_1RpAo8
> 
> This 2D graphics API is not vectorial based becase it does not use SVG style 
> paths. This API is triangle mesh based, so it is more friendlier with the GPU 
> than Athens or Sparta.
> 
> With this API I did a basic gui toolkit, with only two widgets: buttons and 
> label. I did this Widget toolkit to not mess with Bloc, and because I need 
> something relatively stable for the Woden 2 level editor. For now, I am 
> leaving this widget toolkit mostly as a demo. Hopefully it is possible to 
> make Bloc backend using this API.
> 
> During the process of making this API, I had to fix several bugs with 
> OSWindow, and bugs in the interaction between OSWindow and OpenGL. The 
> biggest problem was a race condition between the creation of an OSWindow 
> using SDL2, and the events (such as Expose) that are sent to the just created 
> Window.
> 
> As for Mac OS X, OSWindow is out of service until a pull request ( 
> https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/138 ) gets integrated 
> into the VM. 
> 
> Best regards,
> Ronie

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Re: [Pharo-dev] Official cover for the Pharo booklet collection

[Oleks]

It looks wonderful!



--
View this message in context: 
http://forum.world.st/Official-cover-for-the-Pharo-booklet-collection-tp4946926p4946945.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] [ANN] Pompeii Volcanic Graphics, a mesh based 2D graphics API

[Ronie Salgado]

Hello,

I am releasing a first version of a new 2D graphics API that I am making
for Pharo, using OpenGL.

[image: Imágenes integradas 1]
[image: Imágenes integradas 2]

http://smalltalkhub.com/#!/~ronsaldo/PompeiiGraphics
https://youtu.be/emE6_1RpAo8

This 2D graphics API is not vectorial based becase it does not use SVG
style paths. This API is triangle mesh based, so it is more friendlier with
the GPU than Athens or Sparta.

With this API I did a basic gui toolkit, with only two widgets: buttons and
label. I did this Widget toolkit to not mess with Bloc, and because I need
something relatively stable for the Woden 2 level editor. For now, I am
leaving this widget toolkit mostly as a demo. Hopefully it is possible to
make Bloc backend using this API.

During the process of making this API, I had to fix several bugs with
OSWindow, and bugs in the interaction between OSWindow and OpenGL. The
biggest problem was a race condition between the creation of an OSWindow
using SDL2, and the events (such as Expose) that are sent to the just
created Window.

As for Mac OS X, OSWindow is out of service until a pull request (
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/138 ) gets
integrated into the VM.

Best regards,
Ronie

[Pharo-dev] Git breaks Monticello's version numbers

[Oleksandr Zaytsev]

Hello

Two days ago I was trying to send the slice with my fix to PolyMath using
Monticello. But the version number got set to 1494471195. Today I realized
that all the packages to which I commit are numbered like that.

Cyril Ferlicot explained to me that this happens when I mix git and
Monticello commits. He suggested that I use a separate image for committing
to GitHub, or file out/file in if there is a lot of changes to commit.

Can this be considered a bug? Should I report it?

I think it would be causing problems for many people.

Oleks

Re: [Pharo-dev] Missing plugins to make the vmProfiler work

[csrabak]

On 12 May 2017 07:40:49 -0700, Eliot Miranda  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

 

Re: [Pharo-dev] Official cover for the Pharo booklet collection

[serge . stinckwich]

Nice !!!

Envoyé de mon iPhone

> Le 12 mai 2017 à 20:43, Stephane Ducasse  a écrit :
> 
> Tx damien
> 
> Stef
> 
> 

Re: [Pharo-dev] immediateByteSubclass: ?

[Stephane Ducasse]

Tx we will remove it.

In pharo 70 we will have
- a classParser with a class definition to handle all the terrible logic of
importing
- a fluid class definition
- and it will help removing duplicated and old logic with a huge number of
optional parameters
...
Stef

On Fri, May 12, 2017 at 8:25 PM, Benoit St-Jean via Pharo-dev <
pharo-dev@lists.pharo.org> wrote:

>
>
> -- Forwarded message --
> From: Benoit St-Jean 
> To: Pharo Development List 
> Cc:
> Bcc:
> Date: Fri, 12 May 2017 18:25:53 + (UTC)
> Subject: Re: [Pharo-dev] immediateByteSubclass: ?
> If that's of any help, I was able to track it back to Squeak 5.0 and it
> had no sender in that version too!  The author's initials are eem.
>
> -
> Benoît St-Jean
> Yahoo! Messenger: bstjean
> Twitter: @BenLeChialeux
> Pinterest: benoitstjean
> Instagram: Chef_Benito
> IRC: lamneth
> Blogue: endormitoire.wordpress.com
> "A standpoint is an intellectual horizon of radius zero".  (A. Einstein)
>
>
> --
> *From:* Clément Bera 
> *To:* Pharo Development List 
> *Sent:* Friday, May 12, 2017 1:40 PM
> *Subject:* Re: [Pharo-dev] immediateByteSubclass: ?
>
> This one looks strange and seems indeed to be dead code.
>
> Maybe it was an attempt to make a specific class definition keyword for
> CompiledMethod / CompiledCode / CompiledBlock. Right now there is a
> specific case in the code somewhere to use the specific compiledCode layout
> for those 3 classes instead of the byte layout which is normally used for
> the keyword variableByteSubclass: that those 3 classes use.
>
> I am not sure immediateByteSubclass: makes sense though. I would rather
> have compiledCodeSubclass, variablePointerAndByteSubclass or something like
> that.
>
> On Fri, May 12, 2017 at 5:39 PM, Stephane Ducasse  > wrote:
>
> Hi
>
> with guille we are working on a class parser and our game is to make sure
> that we can parse all the crazy class definitions among which
>
> variableWordSubclass:
> ephemeronSubclass:
> weakSubclass:
> variableByteSubclass:
> variableSubclass:
> immediateSubclass:
> subclass: aSubclassSymbol  layout:
>
> And we found this method definition and it has no senders and we wonder if
> it is just plain deadcode?
>
> immediateByteSubclass: className instanceVariableNames: instvarNames
> classVariableNames: classVarNames package: package
> "Added to allow for a simplified subclass creation experience. "
>
> ^ self
> immediateSubclass: className
> instanceVariableNames: instvarNames
> classVariableNames: classVarNames
> package: package
>
> S & G
>
>
>
>
>
>

[Pharo-dev] Official cover for the Pharo booklet collection

[Stephane Ducasse]

Tx damien

Stef

[image: Inline image 1]

Re: [Pharo-dev] immediateByteSubclass: ?

[Benoit St-Jean via Pharo-dev]

--- Begin Message ---
If that's of any help, I was able to track it back to Squeak 5.0 and it had no 
sender in that version too!  The author's initials are eem.
 - 
Benoît St-Jean 
Yahoo! Messenger: bstjean 
Twitter: @BenLeChialeux 
Pinterest: benoitstjean 
Instagram: Chef_Benito
IRC: lamneth 
Blogue: endormitoire.wordpress.com 
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)

  From: Clément Bera 
 To: Pharo Development List  
 Sent: Friday, May 12, 2017 1:40 PM
 Subject: Re: [Pharo-dev] immediateByteSubclass: ?
   
This one looks strange and seems indeed to be dead code. 
Maybe it was an attempt to make a specific class definition keyword for 
CompiledMethod / CompiledCode / CompiledBlock. Right now there is a specific 
case in the code somewhere to use the specific compiledCode layout for those 3 
classes instead of the byte layout which is normally used for the keyword 
variableByteSubclass: that those 3 classes use.
I am not sure immediateByteSubclass: makes sense though. I would rather have 
compiledCodeSubclass, variablePointerAndByteSubclass or something like that.
On Fri, May 12, 2017 at 5:39 PM, Stephane Ducasse  
wrote:

Hi 
with guille we are working on a class parser and our game is to make sure that 
we can parse all the crazy class definitions among which 
variableWordSubclass:ephemeronSubclass:weakSubclass:variableByteSubclass:variableSubclass:immediateSubclass:
 subclass: aSubclassSymbol  layout:
And we found this method definition and it has no senders and we wonder if it 
is just plain deadcode?
immediateByteSubclass: className instanceVariableNames: instvarNames 
classVariableNames: classVarNames package: package "Added to allow for a 
simplified subclass creation experience. "
 ^ self immediateSubclass: className instanceVariableNames: instvarNames 
classVariableNames: classVarNames package: package
S & G



   --- End Message ---

Re: [Pharo-dev] immediateByteSubclass: ?

[Clément Bera]

This one looks strange and seems indeed to be dead code.

Maybe it was an attempt to make a specific class definition keyword for
CompiledMethod / CompiledCode / CompiledBlock. Right now there is a
specific case in the code somewhere to use the specific compiledCode layout
for those 3 classes instead of the byte layout which is normally used for
the keyword variableByteSubclass: that those 3 classes use.

I am not sure immediateByteSubclass: makes sense though. I would rather
have compiledCodeSubclass, variablePointerAndByteSubclass or something like
that.

On Fri, May 12, 2017 at 5:39 PM, Stephane Ducasse 
wrote:

> Hi
>
> with guille we are working on a class parser and our game is to make sure
> that we can parse all the crazy class definitions among which
>
> variableWordSubclass:
> ephemeronSubclass:
> weakSubclass:
> variableByteSubclass:
> variableSubclass:
> immediateSubclass:
> subclass: aSubclassSymbol  layout:
>
> And we found this method definition and it has no senders and we wonder if
> it is just plain deadcode?
>
> immediateByteSubclass: className instanceVariableNames: instvarNames
> classVariableNames: classVarNames package: package
> "Added to allow for a simplified subclass creation experience. "
>
> ^ self
> immediateSubclass: className
> instanceVariableNames: instvarNames
> classVariableNames: classVarNames
> package: package
>
> S & G
>

[Pharo-dev] immediateByteSubclass: ?

[Stephane Ducasse]

Hi

with guille we are working on a class parser and our game is to make sure
that we can parse all the crazy class definitions among which

variableWordSubclass:
ephemeronSubclass:
weakSubclass:
variableByteSubclass:
variableSubclass:
immediateSubclass:
subclass: aSubclassSymbol  layout:

And we found this method definition and it has no senders and we wonder if
it is just plain deadcode?

immediateByteSubclass: className instanceVariableNames: instvarNames
classVariableNames: classVarNames package: package
"Added to allow for a simplified subclass creation experience. "

^ self
immediateSubclass: className
instanceVariableNames: instvarNames
classVariableNames: classVarNames
package: package

S & G

Re: [Pharo-dev] [ann] bloc & cairo+morphic

[Tudor Girba]

Hi,

It seems that my initial message generated a misunderstanding.

My original blog post was meant to communicate two things:
1. That the known Bloc project has received a new feature that the community 
raised as a problem (i.e., host & backend).
2. Address the other concern that the community raised: how to sustain the Bloc 
development in terms of engineering effort. This is why we announced the 
financial support for the work of Alex that is valid from this point on.

The post was certainly not intended to overlook the people that contributed to 
the overall project. I apologize if it looked like this.

To clarify the historical perspective, we now added an explicit history page on 
the official project page:
https://github.com/pharo-graphics/Bloc/blob/master/HISTORY.md

I also changed the blog post to more clearly communicate the intent:
http://www.humane-assessment.com/blog/bloc-flexible-backends-hosts/

I hope this addresses the concerns. I am really excited that Alain joined and 
that we can get even more traction around Bloc.

Cheers,
Doru



> On May 12, 2017, at 7:56 AM, Stephane Ducasse  wrote:
> 
> BTW for an historical perspective
> 
> RMoD me and igor were also involved far less than the effort of alain but as 
> he mentioned it we collaborated on it. I spent time on documenting several 
> versions and I stopped disgusted to see the total lack of attention for 
> comments. 
> Then Rmod paid nearly a year of effort on Athens, SDL20 support, a year on 
> TxText. I find really strange that we are not even mentioned in any support.
> 
> Stef
> 
> 
> On Thu, May 11, 2017 at 8:12 PM, Stephane Ducasse  
> wrote:
> Doru can you change the humane assessment blog post?
> 
> 
> On Thu, May 11, 2017 at 8:07 PM, Tudor Girba  wrote:
> Hi,
> 
> Indeed, this is wonderful news that you will rejoin your baby project :).
> 
> Cheers,
> Doru
> 
> 
> > On May 11, 2017, at 6:40 PM, Alexandre Bergel  
> > wrote:
> >
> > Hi Alain!
> >
> > Thanks for the mail (even if the historial part has always been pretty 
> > clear to me).
> > We miss you! Be back soon!
> >
> > Cheers,
> > Alexandre
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >> On May 11, 2017, at 12:36 PM, Alain Plantec via Pharo-dev 
> >>  wrote:
> >>
> >>
> >> From: Alain Plantec 
> >> Subject: Re: [Pharo-users] [ann] bloc & cairo+morphic
> >> Date: May 11, 2017 at 12:36:36 PM GMT-3
> >> To: Pharo Development List 
> >> Cc: Alain Plantec , Moose-related development 
> >> , Any question about pharo is welcome 
> >> 
> >>
> >>
> >> Hello Doru, all,
> >>
> >> I’m really happy to see Bloc progresses.
> >> Even I’m not active since more than one year, Bloc is still an important 
> >> project for me.
> >>
> >> but let me complete this short historical presentation a little bit.
> >>
> >> Bloc is a project that I initiated in 2013 in collaboration with RMOD 
> >> following experiments made around the ROME project.
> >> The idea was to completely revisit the 2D framework of Pharo to address 
> >> Morphic limits.
> >> Following an invitation of the Software Composition Group (thanks to Oscar 
> >> Nierstrasz and to Doru here),
> >> I presented the first version of Bloc at Bern (March, 2015), then Doru and 
> >> Aliaksel joined the project.
> >> One year ago, during his PhD at Brest, Glenn Cavarle produced a new 
> >> version of the Bloc infrastructure that is now the
> >> one used together with the layouting system that was implemented by 
> >> Aliaksel.
> >>
> >> Please, do not use the humane assessment web site but the github project 
> >> one instead.
> >>
> >> I will restart working on Bloc/Brick soon in the context of a project that 
> >> we recently signed with the Thales company.
> >>
> >> Thanks,
> >> Cheers
> >>
> >> Alain
> >>
> >>
> >>> On 8 mai 2017, at 23:00, Tudor Girba  wrote:
> >>>
> >>> Hi,
> >>>
> >>> We are happy to announce that based on the work of Glenn, Alex extended 
> >>> Bloc (Sparta) to work directly in the Morphic world using Cairo as a 
> >>> backend.
> >>>
> >>> Cairo is less powerful than Moz2D (see the screenshot below for an 
> >>> example), but the implementation addresses a concern that the community 
> >>> raised regarding a perceived increased liability due to the dependency to 
> >>> Moz2D. Essentially this means that Bloc can be treated as another 
> >>> graphical library that can coexist with Morphic without requiring any 
> >>> external VM plugin.
> >>>
> >>> 
> >>>
> >>> I would also like to point out that adding a new backend and host was 
> >>> possible because of the many iterations (including throwing away whole 
> 

Re: [Pharo-dev] Missing plugins to make the vmProfiler work on Pharo

[Eliot Miranda]

Hi Cesar,

> On May 11, 2017, at 12:10 PM, csra...@bol.com.br wrote:
> 
>> On Thu, 11 May 2017 11:34:47 +0200, Cl?ment Bera  
>> wrote:
>> 
>> On   Wed,  May   10,  2017   at  8:12   PM,  Esteban   A.  Maringolo
>>  wrote:
>> 
>>> 2017-05-10 13:38 GMT-03:00  Cl?ment Bera :
 On  Wed, May  10,  2017  at 5:28  PM,  Esteban  A. Maringolo  <
>>> emaring...@gmail.com> 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,019
> 
> --
> Cesar Rabak

_,,,^..^,,,_ (phone)

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

  Branch: refs/tags/60486
  Home:   https://github.com/pharo-project/pharo-core

[Pharo-dev] [pharo-project/pharo-core] 4778e8: 60486

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 4778e8f6a49f99d25ca2860d8e36d4f08d545211
  
https://github.com/pharo-project/pharo-core/commit/4778e8f6a49f99d25ca2860d8e36d4f08d545211
  Author: Jenkins Build Server 
  Date:   2017-05-12 (Fri, 12 May 2017)

  Changed paths:
M 
BaselineOfIDE.package/BaselineOfIDE.class/instance/actions/additionalInitialization.st
M BaselineOfIDE.package/BaselineOfIDE.class/instance/baseline/baseline_.st
M BaselineOfIDE.package/BaselineOfIDE.class/instance/baseline/groups_.st
M 
BaselineOfMorphic.package/BaselineOfMorphic.class/instance/actions/postload_package_.st
M 
Glamour-Morphic-Brick.package/GLMHorizontalLinearLayout.class/instance/width/widthParentDependency_.st
M 
Glamour-Morphic-Brick.package/GLMLinearLayout.class/instance/testing/hasWidthRestrictions_.st
M 
Glamour-Morphic-Brick.package/GLMTabSelectorBrick.class/instance/actions/updateTabs.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60485.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60486.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60485.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60486.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  60486
20050 Theme must be reset at the end of BaselineOfIDE loading
https://pharo.fogbugz.com/f/cases/20050

20051 Tab labels in Glamour should not shrink if there is available space
https://pharo.fogbugz.com/f/cases/20051

20049 TravisIntegrationHelp is not loaded into the bootstrapped image
https://pharo.fogbugz.com/f/cases/20049

http://files.pharo.org/image/60/60486.zip

Re: [Pharo-dev] Does OSSubprocess works on ARM vm?

[Mariano Martinez Peck]

 I don't know. Can you at least try for the first time in a 32 bits ARM
?

On Fri, May 12, 2017 at 5:00 AM, Denis Kudriashov 
wrote:

> Hi.
>
> I decided to ask before I will try it.
>
> Best regards,
> Denis
>



-- 
Mariano
http://marianopeck.wordpress.com

[Pharo-dev] Does OSSubprocess works on ARM vm?

[Denis Kudriashov]

Hi.

I decided to ask before I will try it.

Best regards,
Denis

Re: [Pharo-dev] Extending the debugger inspector with a new presentation

[Denis Kudriashov]

Hi.

One possibility is to follow BytecodeDebugger approach. Try to look how it
is implemented

2017-05-12 9:53 GMT+02:00 :

> Hello,
>
> I would like to extend the debugger with some context-dependent
> information.
> I am playing with metalinks and I would like to show, in the debugger,
> some information if my metalinks are in the selected method.
> This means that:
> - I need to add a new presentation in the debugger next to the "variable"
> and "evaluator" ones.
> - I need to filter that presentation to show it depending on which method
> is selected.
>
> I tried to extend ProtoObject with a method like:
>
> gtDebuggerExpressionMachinViewIn: composite
> 
>
> composite text
> title: 'My machin';
> display: [ :browser :debugger | debugger asString]
>
> However, this did not add a presentation in the debugger. It only show up
> when selecting an object in the debugger inspector (see screenshot).
>
> How can I extend the debugger as I want?
>
> Thanks
> Thomas and Guille
>

[Pharo-dev] Extending the debugger inspector with a new presentation

[tdupriez]

Hello,

I would like to extend the debugger with some context-dependent information.
I am playing with metalinks and I would like to show, in the debugger,  
some information if my metalinks are in the selected method.

This means that:
- I need to add a new presentation in the debugger next to the  
"variable" and "evaluator" ones.
- I need to filter that presentation to show it depending on which  
method is selected.


I tried to extend ProtoObject with a method like:

gtDebuggerExpressionMachinViewIn: composite


composite text
title: 'My machin';
display: [ :browser :debugger | debugger asString]

However, this did not add a presentation in the debugger. It only show  
up when selecting an object in the debugger inspector (see screenshot).


How can I extend the debugger as I want?

Thanks
Thomas and Guille