[Pharo-dev] Slides online: "Perfection & Feedback Loops" talk from esug

2016-09-01 Thread Marcus Denker
Hi,

At ESUG last Friday I gave a talk "Perfection & Feedback Loops or: why worse is 
better”, I was asked for the slides.

They are now online:


http://www.slideshare.net/MarcusDenker/perfection-feedback-loops-or-why-worse-is-better-65540840

As the slides do not contain much (just headlines), I created a special 
“Annotated” version with links and some comments
so one can follow better:

http://marcusdenker.de/talks/16ESUG/FeedbackLoopsAnnotated.pdf

PDF and .key file are there, too: http://marcusdenker.de/talks/16ESUG/
(the .key file contains the embedded videos shown).

A video of the presentation should be available soon.


Marcus


Re: [Pharo-dev] About the non-use of Announcer in Bloc

2016-09-01 Thread stepharo

this is really cool :)


Le 1/9/16 à 10:21, Thierry Goubier a écrit :

Hi Stef,

here is the script I use:

| c1 c2 c3 n1 n2 n3 l1 l2 l3 |
c1 := c2 := c3 := 0.
n1 := (Announcer>>#announce:) ast.
n2 := #(subscribe:do: subscribe:send:to: basicSubscribe:) collect: [ 
:e | (Announcer>>e) ast ].
n3 := #(unsubscribe: removeSubscription:) collect: [ :e | 
(Announcer>>e) ast ].

l1 := MetaLink new metaObject: [ c1 := c1 + 1 ]; selector: #value.
l2 := MetaLink new metaObject: [ c2 := c2 + 1 ]; selector: #value.
l3 := MetaLink new metaObject: [ c3 := c3 + 1 ]; selector: #value.
[ n1 link: l1. n2 do: [ :e | e link: l2 ]. n3 do: [ :e | e link: l3 ].
(Duration minutes: 1) wait.
n1 removeLink: l1. n2 do: [ :e | e removeLink: l2 ]. n3 do: [ :e | e 
removeLink: l3 ].
{ 'announce' -> c1. 'subscribe' -> c2.  'unsubscribe' -> c3 } inspect 
] forkAt: Processor userBackgroundPriority


Images intégrées 1

2016-09-01 9:28 GMT+02:00 Thierry Goubier >:


Hi Stef,


2016-09-01 8:13 GMT+02:00 stepharo mailto:steph...@free.fr>>:

Hi thierry

I think that if we would have a tool to show us the activity
I'm quite sure that we would find bugs

or mistaken behavior.


Yes. I did some checks on Morphic and AltBrowser after getting the
numbers, to see if I wasn't
doing something wrong with my code.

could you send the scripts you did?


Later today. I don't have access now to the laptop where I did it.

Thierry


Stef


Le 30/8/16 à 22:36, Thierry Goubier a écrit :

Numbers for the discussion:

No activity, empty desktop:
announcements608/minute
subscribe add/remove9/minute

Activity, AltBrowser:
announcements1109/minute
subscribe add/remove207/minute

Activity, Nautilus:
announcements2488/minute
subscribe add/remove716/minute

Empirically the same processus in both environments: open
two system browser, in one, find the Announcer class,
browse through a few of the methods, select
basicSubscribe: and ask for senders.

Tracing done with Metalinks during one minute.

Not exactly what I would have expected, especially the
ratio subscribe add/remove and announcements.

Thierry

Le 30/08/2016 à 17:36, Henrik Johansen a écrit :


On 30 Aug 2016, at 5:16 , Thierry Goubier
mailto:thierry.goub...@gmail.com>> wrote:


I have the same concern with an Announcer
optimized for certain use
cases, in the fact that the announcer creator is
the one choosing
the 'kind of' optimisation it would target, hoping
that the
listeners will conform to that use case...



There simply is no silver bullet that will give unbeatable
performance in all scenarios; and focusing on
improving one facet of
the default implementation will inevitably lead to
either - the loss
of some important property (general thread-safety if
removing the
mutex protection, ability to unsubscribe in handler if
removing the
copy operation and extending the delivery mutex
protection, etc.) -
greatly degenerated performance for another facet
(like #remove for
OC's).

That said, the current implementation is very geared
towards decent,
balanced subscribe/unsubscribe performance, at the
expense of
delivery speed. I've said it before, and still think,
that offering
at least one other implementation emphasizing delivery
speed over
subscription/unsubscription performance, in the same
way the original
implementation did (and/or changing the default
Announcer to switch
between the two dynamically based on heuristics)
*would* be a
valuable addition to the general library.

Cheers, Henry












[Pharo-dev] about clas deprecation

2016-09-01 Thread stepharo

Hi

Using the idea we got with Peter Uhnak, we know implemented using 
transformation library of gustavo two new transformation:


- deprecate class

just compile a new method raising a warning:

+ a class method deprecated returning true (this could then 
improve to rename the method new if it already exist).


- rename and deprecate:

the idea here is that we want to make sure that we can rename a 
class and that external users get a chance to load and execute their 
code. For that if we have a class A we rename it into ANewName and 
create an empty subclass A that we deprecate.


Let us know what you think.

Stef and Gustavo




Re: [Pharo-dev] [Moose-dev] [ann] pillar support in gtinspector

2016-09-01 Thread Sean P. DeNigris
stepharo wrote
> It does. We want a real editor in Pharo.

+10 :)



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/ann-pillar-support-in-gtinspector-tp4913115p4913691.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.



Re: [Pharo-dev] Binary selector and special characters

2016-09-01 Thread Richard Sargent
Nicolai Hess-3-2 wrote
> 2016-08-31 17:31 GMT+02:00 John Brant <

> brant@

> >:
> 
>> On 08/31/2016 08:46 AM, Nicolai Hess wrote:
>>
>> Anyone knows why RefactoringBrowsers smalltalk scanner (RBScanner)
>>> explicit allowes
>>>   "#($± $· $× $÷)" to be binary selector characters ?
>>>
>>
>> I do -- I added them about 20 years ago :)...
>>
>> Is there any smalltalk dialect that uses these characters ?
>>>
>>
>> VW allows them. When possible, we made the scanner/parser be a superset
>> of
>> the VW & VA syntax.
>>
>>
>> John Brant
>>
>>
> Thank you John, for the info.
> Hm, now, what to do, fix our (pharo) parser to allowe these characters as
> binary selectors or change the scanner to not
> generate binary selector tokens for them...

I would argue that when Zerox PARC created Smalltalk ASCII was all they had
to choose from. 40 years later, we have Unicode and we have people from
around the world using Smalltalk. Most of them are not native English
speakers.

Having a Smalltalk implementation that supports Unicode selectors, unary,
binary, or keyword, would be a good and welcome things.




--
View this message in context: 
http://forum.world.st/Binary-selector-and-special-characters-tp4912981p4913685.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.



Re: [Pharo-dev] [Pharo-users] [ANN] RProjectConnector V2.1

2016-09-01 Thread Alexandre Bergel
I do not see any apparent libraries on OSX. I am inspecting the content of the 
R application Package and it only contains images and some executables.

Alexandre

> On Sep 1, 2016, at 1:55 PM, Blondeau Vincent  
> wrote:
> 
> Sorry, I haven’t a Mac.
>  
> First, you have to install R.
> Then, I think you should only have to copy the R libraries (somewhere in the 
> disk^^) to the Pharo VM folder.
>  
> Tell me if it works ;)
>  
> Vincent
>  
> De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org 
> ] De la part de Alexandre Bergel
> Envoyé : jeudi 1 septembre 2016 17:49
> À : Any question about pharo is welcome
> Cc : scismallt...@googlegroups.com ; 
> Pharo Development List
> Objet : Re: [Pharo-dev] [Pharo-users] [ANN] RProjectConnector V2.1
>  
> I wanted to try, but there is no installation instruction for OS X :-(
> Can you produce some on OS X? It would be great
>  
> Anyway, this is great Vincent! Keep pushing!
>  
> Alexandre
>  
>  
> On Sep 1, 2016, at 12:42 PM, Blondeau Vincent  > wrote:
>  
> Hello everyone, 
>  
> I am glad to announce the release of version 2.1 of the RProjectConnector.
> The binding between Pharo and R (https://www.r-project.org/ 
> ) is now translated to UFFI and so to Pharo 6.0.
>  
> You can call directly your R methods from Pharo. For example, with the famous 
> iris clustering example:
>  
>   iris := 'eval' asREval: {RObject findVar: 'iris'}.
>   'plot'
> asREval:
> {(iris at: 'Petal.Length').
> (iris at: 'Petal.Width').
> (#pch -> 21).
> (#xlab -> 'length').
> (#ylab -> 'Width').
> (#bg  ->((iris at: 'Species') collect: [ 
> :value | {'red'. 'green3'. 'blue'} at: value ])).
> (#main -> 'Edgar Anderson''s Iris Data')}.
>   iris inspect.
>  
> To use it, you should install R and copy the R libraries near the Pharo VM 
> (see the documentation on SmalltalkHub 
> (http://smalltalkhub.com/#!/~VincentBlondeau/RProjectConnector 
> ) for how to 
> proceed).
>  
> Don’t forget to relaunch Pharo after the installation to be able to use the 
> connector.
>  
> Only basic features are implemented yet, but you can participate to its 
> extension!
>  
> Cheers,
> Vincent Blondeau
> 
> !!!*
> "Ce message et les pièces jointes sont confidentiels et réservés à l'usage 
> exclusif de ses destinataires. Il peut également être protégé par le secret 
> professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
> immédiatement l'expéditeur et de le détruire. L'intégrité du message ne 
> pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra 
> être recherchée quant au contenu de ce message. Bien que les meilleurs 
> efforts soient faits pour maintenir cette transmission exempte de tout virus, 
> l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne 
> saurait être recherchée pour tout dommage résultant d'un virus transmis.
> 
> This e-mail and the documents attached are confidential and intended solely 
> for the addressee; it may also be privileged. If you receive this e-mail in 
> error, please notify the sender immediately and destroy it. As its integrity 
> cannot be secured on the Internet, the Worldline liability cannot be 
> triggered for the message content. Although the sender endeavours to maintain 
> a computer virus-free network, the sender does not warrant that this 
> transmission is virus-free and will not be liable for any damages resulting 
> from any virus transmitted.!!!"
>  
> 
> !!!*
> "Ce message et les pièces jointes sont confidentiels et réservés à l'usage 
> exclusif de ses destinataires. Il peut également être protégé par le secret 
> professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
> immédiatement l'expéditeur et de le détruire. L'intégrité du message ne 
> pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra 
> être recherchée quant au contenu de ce message. Bien que les meilleurs 
> efforts soient faits pour maintenir cette transmission exempte de tout virus, 
> l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne 
> saurait être recherchée pour tout dommage résultant d'un virus transmis.
> 
> This e-mail and the documents attached are confidential and intended solely 
> for the addressee; it may also be privileged. If you receive this e-mail in 
> error, please notify the sender immediately and destroy it. As its i

Re: [Pharo-dev] [Pharo-users] [ANN] RProjectConnector V2.1

2016-09-01 Thread Blondeau Vincent
Sorry, I haven’t a Mac.

First, you have to install R.
Then, I think you should only have to copy the R libraries (somewhere in the 
disk^^) to the Pharo VM folder.

Tell me if it works ;)

Vincent

De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de 
Alexandre Bergel
Envoyé : jeudi 1 septembre 2016 17:49
À : Any question about pharo is welcome
Cc : scismallt...@googlegroups.com; Pharo Development List
Objet : Re: [Pharo-dev] [Pharo-users] [ANN] RProjectConnector V2.1

I wanted to try, but there is no installation instruction for OS X :-(
Can you produce some on OS X? It would be great

Anyway, this is great Vincent! Keep pushing!

Alexandre


On Sep 1, 2016, at 12:42 PM, Blondeau Vincent 
mailto:vincent.blond...@worldline.com>> wrote:

Hello everyone,

I am glad to announce the release of version 2.1 of the RProjectConnector.
The binding between Pharo and R (https://www.r-project.org/) is now translated 
to UFFI and so to Pharo 6.0.

You can call directly your R methods from Pharo. For example, with the famous 
iris clustering example:

  iris := 'eval' asREval: {RObject findVar: 'iris'}.
  'plot'
asREval:
{(iris at: 'Petal.Length').
(iris at: 'Petal.Width').
(#pch -> 21).
(#xlab -> 'length').
(#ylab -> 'Width').
(#bg  ->((iris at: 'Species') collect: [ :value 
| {'red'. 'green3'. 'blue'} at: value ])).
(#main -> 'Edgar Anderson''s Iris Data')}.
  iris inspect.

To use it, you should install R and copy the R libraries near the Pharo VM (see 
the documentation on SmalltalkHub 
(http://smalltalkhub.com/#!/~VincentBlondeau/RProjectConnector) for how to 
proceed).


Don’t forget to relaunch Pharo after the installation to be able to use the 
connector.

Only basic features are implemented yet, but you can participate to its 
extension!

Cheers,
Vincent Blondeau

!!!*
"Ce message et les pièces jointes sont confidentiels et réservés à l'usage 
exclusif de ses destinataires. Il peut également être protégé par le secret 
professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant 
être assurée sur Internet, la responsabilité de Worldline ne pourra être 
recherchée quant au contenu de ce message. Bien que les meilleurs efforts 
soient faits pour maintenir cette transmission exempte de tout virus, 
l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne 
saurait être recherchée pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, the Worldline liability cannot be triggered for the 
message content. Although the sender endeavours to maintain a computer 
virus-free network, the sender does not warrant that this transmission is 
virus-free and will not be liable for any damages resulting from any virus 
transmitted.!!!"


!!!*
"Ce message et les pièces jointes sont confidentiels et réservés à l'usage 
exclusif de ses destinataires. Il peut également être protégé par le secret 
professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant 
être assurée sur Internet, la responsabilité de Worldline ne pourra être 
recherchée quant au contenu de ce message. Bien que les meilleurs efforts 
soient faits pour maintenir cette transmission exempte de tout virus, 
l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne 
saurait être recherchée pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, the Worldline liability cannot be triggered for the 
message content. Although the sender endeavours to maintain a computer 
virus-free network, the sender does not warrant that this transmission is 
virus-free and will not be liable for any damages resulting from any virus 
transmitted.!!!"


Re: [Pharo-dev] [Pharo-users] [ANN] RProjectConnector V2.1

2016-09-01 Thread Alexandre Bergel
I wanted to try, but there is no installation instruction for OS X :-(
Can you produce some on OS X? It would be great

Anyway, this is great Vincent! Keep pushing!

Alexandre


> On Sep 1, 2016, at 12:42 PM, Blondeau Vincent 
>  wrote:
> 
> Hello everyone, 
>  
> I am glad to announce the release of version 2.1 of the RProjectConnector.
> The binding between Pharo and R (https://www.r-project.org/ 
> ) is now translated to UFFI and so to Pharo 6.0.
>  
> You can call directly your R methods from Pharo. For example, with the famous 
> iris clustering example:
>  
>   iris := 'eval' asREval: {RObject findVar: 'iris'}.
>   'plot'
> asREval:
> {(iris at: 'Petal.Length').
> (iris at: 'Petal.Width').
> (#pch -> 21).
> (#xlab -> 'length').
> (#ylab -> 'Width').
> (#bg  ->((iris at: 'Species') collect: [ 
> :value | {'red'. 'green3'. 'blue'} at: value ])).
> (#main -> 'Edgar Anderson''s Iris Data')}.
>   iris inspect.
>  
> To use it, you should install R and copy the R libraries near the Pharo VM 
> (see the documentation on SmalltalkHub 
> (http://smalltalkhub.com/#!/~VincentBlondeau/RProjectConnector 
> ) for how to 
> proceed).
>  
> Don’t forget to relaunch Pharo after the installation to be able to use the 
> connector.
>  
> Only basic features are implemented yet, but you can participate to its 
> extension!
>  
> Cheers,
> Vincent Blondeau
> 
> !!!*
> "Ce message et les pièces jointes sont confidentiels et réservés à l'usage 
> exclusif de ses destinataires. Il peut également être protégé par le secret 
> professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
> immédiatement l'expéditeur et de le détruire. L'intégrité du message ne 
> pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra 
> être recherchée quant au contenu de ce message. Bien que les meilleurs 
> efforts soient faits pour maintenir cette transmission exempte de tout virus, 
> l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne 
> saurait être recherchée pour tout dommage résultant d'un virus transmis.
> 
> This e-mail and the documents attached are confidential and intended solely 
> for the addressee; it may also be privileged. If you receive this e-mail in 
> error, please notify the sender immediately and destroy it. As its integrity 
> cannot be secured on the Internet, the Worldline liability cannot be 
> triggered for the message content. Although the sender endeavours to maintain 
> a computer virus-free network, the sender does not warrant that this 
> transmission is virus-free and will not be liable for any damages resulting 
> from any virus transmitted.!!!"



[Pharo-dev] [ANN] RProjectConnector V2.1

2016-09-01 Thread Blondeau Vincent
Hello everyone,

I am glad to announce the release of version 2.1 of the RProjectConnector.
The binding between Pharo and R (https://www.r-project.org/) is now translated 
to UFFI and so to Pharo 6.0.

You can call directly your R methods from Pharo. For example, with the famous 
iris clustering example:

  iris := 'eval' asREval: {RObject findVar: 'iris'}.
  'plot'
asREval:
{(iris at: 'Petal.Length').
(iris at: 'Petal.Width').
(#pch -> 21).
(#xlab -> 'length').
(#ylab -> 'Width').
(#bg  ->((iris at: 'Species') collect: [ :value 
| {'red'. 'green3'. 'blue'} at: value ])).
(#main -> 'Edgar Anderson''s Iris Data')}.
  iris inspect.

To use it, you should install R and copy the R libraries near the Pharo VM (see 
the documentation on SmalltalkHub 
(http://smalltalkhub.com/#!/~VincentBlondeau/RProjectConnector) for how to 
proceed).


Don't forget to relaunch Pharo after the installation to be able to use the 
connector.

Only basic features are implemented yet, but you can participate to its 
extension!

Cheers,
Vincent Blondeau

!!!*
"Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage 
exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret 
professionnel. Si vous recevez ce message par erreur, merci d'en avertir 
imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant 
?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre 
recherch?e quant au contenu de ce message. Bien que les meilleurs efforts 
soient faits pour maintenir cette transmission exempte de tout virus, 
l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne 
saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, the Worldline liability cannot be triggered for the 
message content. Although the sender endeavours to maintain a computer 
virus-free network, the sender does not warrant that this transmission is 
virus-free and will not be liable for any damages resulting from any virus 
transmitted.!!!"


[Pharo-dev] FFIIntegerTypes inheritance hierarchy

2016-09-01 Thread Ben Coman
I'm looking through the keyhole at something new to me, so maybe this
is off base, but looking at the inheritance hierarchy...

FFIIntegerType
FFIUint16
FFIUint16
FFIUInt32
FFIInt32
FFIUint64
FFIInt64
FFIUint8
FFIInt8

I'm curious... why the all the Ints inherit from the UInts?

Each of those classes has the same two methods #basicHandle:at: and
#basicHandle:at:put.   So the Int subclasses fully override the
superclass methods. So there in no inherited behaviour on the instance
side.

On the class side, I see #externalTypeSize is inherited by the Ints,
but evaluating...
FFIIntegerType allSubclasses collect: [ :class |
   class externalType byteSize -> class externalTypeSize ]
produces...
4->4
2->2
4->4
8->8
1->1
2->2
4->4
8->8
1->1

So naively the extra inheritance level seems unnecessary
and perhaps having...
FFIIntegerType class >> externalTypeSize
^ self externalType byteSize

would allow the hierarchy to be flattened.  Maybe not a great benefit,
except to avoid the next person wondering the same thing :P


Also, it is surprising that that FFUInt64 uses #signedLongLongAt:
rather than #unsignedLongLongAt: .  This seems on-purpose rather than
accidental since its inherited by FFIInt64, so it seems there is
something interesting to learn here that would benefit a method
comment.

cheers -ben



[Pharo-dev] Engineer position at Lille (France) about Moose FAMIX

2016-09-01 Thread Anne Etien
Hi,

We have an engineer position at Lille (France) in the RMOD team to modernize 
FAME, FAMIX and software analysis tools.
The position is for two years starting in November or December. Conditions to 
apply are to have a master with 2 to 10 years of experience. 

Industrial applications of Moose have shown some limits: (1) problem to scale, 
(2) modularity and extensibility and (3) user syntax. To overtake these limits, 
it becomes essential to modernize Moose heart. This project has three major 
objectives: (i) reduce the memory print to enable a better scaling, (ii) 
modernize Moose heart to introduce more modularity and extensibility and (iii) 
simplify the use and extension of Moose.

This project aims to develop a new version of Moose (Moose 2.0) more modular, 
less memory consumer and easier to use. Advantages of Platypus 
(PL)(http://dossen.univ-brest.fr/apl/index.php/Platypus 
) a research prototype 
developed in Pharo to analyse software systems as models will be combined to 
those of the current Moose (M) version and the new features of Pharo (P).

Moose 2.0 = flexible metamodel (M) supporting multiple inheritance and union of 
types (PL) + user syntaxto simplify model specifications (PL)
+ lot of analysis and visualization tools (M)
+ tool infrastructure (M)
+ model generator (PL)
+ compatibility with industrial and academic standard (PL) + low memory print 
(P)
+ access to method details (M) on demand (P)

Mission description (in French) and application form are available here 
(https://www.inria.fr/institut/recrutement-metiers/offres/ingenieurs-r-d-confirmes-et-specialistes/%28view%29/details.html?id=PGTFK026203F3VBQB6G68LONZ&nPostingTargetID=17221
 
).
French is not mandatory whereas English is ;o)
If you have questions, don’t hesitate to ask.

Sincerely,

Anne Etien



Re: [Pharo-dev] About the non-use of Announcer in Bloc

2016-09-01 Thread Thierry Goubier
2016-09-01 10:29 GMT+02:00 Denis Kudriashov :

> Hi Thierry.
>
> 2016-09-01 10:21 GMT+02:00 Thierry Goubier :
>
>> (Duration minutes: 1) wait.
>>
>
> Just to mention our nice language: it could be written as:
>
>
>  1 minutes wait
>
>
> Thanks. Didn't find that one when searching through the code. Recovering
the userBackgroundPriority message by code browsing and search wasn't too
obvious either.

 Thierry


Re: [Pharo-dev] About the non-use of Announcer in Bloc

2016-09-01 Thread Sven Van Caekenberghe

> On 01 Sep 2016, at 10:21, Thierry Goubier  wrote:
> 
> Hi Stef,
> 
> here is the script I use:
> 
> | c1 c2 c3 n1 n2 n3 l1 l2 l3 |
> c1 := c2 := c3 := 0.
> n1 := (Announcer>>#announce:) ast.
> n2 := #(subscribe:do: subscribe:send:to: basicSubscribe:) collect: [ :e | 
> (Announcer>>e) ast ].
> n3 := #(unsubscribe: removeSubscription:) collect: [ :e | (Announcer>>e) ast 
> ].
> l1 := MetaLink new metaObject: [ c1 := c1 + 1 ]; selector: #value.
> l2 := MetaLink new metaObject: [ c2 := c2 + 1 ]; selector: #value.
> l3 := MetaLink new metaObject: [ c3 := c3 + 1 ]; selector: #value.
> [ n1 link: l1. n2 do: [ :e | e link: l2 ]. n3 do: [ :e | e link: l3 ].
> (Duration minutes: 1) wait.
> n1 removeLink: l1. n2 do: [ :e | e removeLink: l2 ]. n3 do: [ :e | e 
> removeLink: l3 ].
> { 'announce' -> c1. 'subscribe' -> c2.  'unsubscribe' -> c3 } inspect ] 
> forkAt: Processor userBackgroundPriority

Well, this is really cool code !

> 
> 
> 2016-09-01 9:28 GMT+02:00 Thierry Goubier :
> Hi Stef,
> 
> 
> 2016-09-01 8:13 GMT+02:00 stepharo :
> Hi thierry
> 
> I think that if we would have a tool to show us the activity I'm quite sure 
> that we would find bugs
> 
> or mistaken behavior.
> 
> Yes. I did some checks on Morphic and AltBrowser after getting the numbers, 
> to see if I wasn't
> doing something wrong with my code. 
> 
> could you send the scripts you did?
> 
> Later today. I don't have access now to the laptop where I did it.
> 
> Thierry
>  
> 
> Stef
> 
> 
> Le 30/8/16 à 22:36, Thierry Goubier a écrit :
> 
> Numbers for the discussion:
> 
> No activity, empty desktop:
> announcements608/minute
> subscribe add/remove9/minute
> 
> Activity, AltBrowser:
> announcements1109/minute
> subscribe add/remove207/minute
> 
> Activity, Nautilus:
> announcements2488/minute
> subscribe add/remove716/minute
> 
> Empirically the same processus in both environments: open two system browser, 
> in one, find the Announcer class, browse through a few of the methods, select 
> basicSubscribe: and ask for senders.
> 
> Tracing done with Metalinks during one minute.
> 
> Not exactly what I would have expected, especially the ratio subscribe 
> add/remove and announcements.
> 
> Thierry
> 
> Le 30/08/2016 à 17:36, Henrik Johansen a écrit :
> 
> On 30 Aug 2016, at 5:16 , Thierry Goubier
>  wrote:
> 
> 
> I have the same concern with an Announcer optimized for certain use
> cases, in the fact that the announcer creator is the one choosing
> the 'kind of' optimisation it would target, hoping that the
> listeners will conform to that use case...
> 
> 
> There simply is no silver bullet that will give unbeatable
> performance in all scenarios; and focusing on improving one facet of
> the default implementation will inevitably lead to either - the loss
> of some important property (general thread-safety if removing the
> mutex protection, ability to unsubscribe in handler if removing the
> copy operation and extending the delivery mutex protection, etc.) -
> greatly degenerated performance for another facet (like #remove for
> OC's).
> 
> That said, the current implementation is very geared towards decent,
> balanced subscribe/unsubscribe performance, at the expense of
> delivery speed. I've said it before, and still think, that offering
> at least one other implementation emphasizing delivery speed over
> subscription/unsubscription performance, in the same way the original
> implementation did (and/or changing the default Announcer to switch
> between the two dynamically based on heuristics) *would* be a
> valuable addition to the general library.
> 
> Cheers, Henry
> 
> 
> 
> 
> 
> 
> 
> 




[Pharo-dev] [pharo-project/pharo-core] 29e0f2: 60197

2016-09-01 Thread GitHub
  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 29e0f2580442a1838dc0c84978512f5b73e8c053
  
https://github.com/pharo-project/pharo-core/commit/29e0f2580442a1838dc0c84978512f5b73e8c053
  Author: Jenkins Build Server 
  Date:   2016-09-01 (Thu, 01 Sep 2016)

  Changed paths:
M Collections-Unordered.package/Dictionary.class/class/instance 
creation/newFromPairs_.st
M FreeType.package/FreeTypeFontProvider.class/instance/file 
paths/macOSXFolderDirectories.st
M FreeType.package/FreeTypeFontProvider.class/instance/file 
paths/unixFontDirectories.st
A FreeType.package/FreeTypeFontProvider.class/instance/file 
paths/unixUsualDirectories.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60196.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60197.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60196.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60197.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M 
System-Settings.package/ClassStoredSetting.class/instance/accessing/realValue.st
M 
System-Settings.package/LogicalFontStoredSetting.class/instance/accessing/realValue.st
M 
System-Settings.package/StrikeFontSetStoredSetting.class/instance/accessing/realValue.st
M 
System-Settings.package/StrikeFontStoredSetting.class/instance/accessing/realValue.st
M Tool-CriticBrowser.package/CriticBrowser.class/class/instance 
creation/packagesMenu_.st
M Tool-CriticBrowser.package/CriticBrowser.class/class/menu/icon.st
M 
Tool-CriticBrowser.package/CriticBrowser.class/instance/api/onWindowClosed.st
A 
Tool-CriticBrowser.package/CriticBrowser.class/instance/private/allRules.st
M 
Tool-CriticBrowser.package/CriticBrowser.class/instance/private/applyRules.st
M 
Tool-CriticBrowser.package/CriticBrowser.class/instance/private/reapplyAllRules.st
M 
Tool-CriticBrowser.package/CriticBrowser.class/instance/private/reapplyRule_.st
A Tool-CriticBrowser.package/CriticBrowser.class/instance/system 
annoucements/classAdded_.st
R Tool-CriticBrowser.package/CriticBrowser.class/instance/system 
annoucements/classModified_.st
A Tool-CriticBrowser.package/CriticBrowser.class/instance/system 
annoucements/classRemoved_.st
A Tool-CriticBrowser.package/CriticBrowser.class/instance/system 
annoucements/handleClassAdded_.st
A Tool-CriticBrowser.package/CriticBrowser.class/instance/system 
annoucements/handleClassModified_.st
A Tool-CriticBrowser.package/CriticBrowser.class/instance/system 
annoucements/handleClassRemoved_.st
A Tool-CriticBrowser.package/CriticBrowser.class/instance/system 
annoucements/handleMethodAdded_.st
A Tool-CriticBrowser.package/CriticBrowser.class/instance/system 
annoucements/handleMethodModified_.st
A Tool-CriticBrowser.package/CriticBrowser.class/instance/system 
annoucements/handleMethodRemoved_.st
M Tool-CriticBrowser.package/CriticBrowser.class/instance/system 
annoucements/methodAdded_.st
R Tool-CriticBrowser.package/CriticBrowser.class/instance/system 
annoucements/methodModified_.st
M Tool-CriticBrowser.package/CriticBrowser.class/instance/system 
annoucements/methodRemoved_.st
M Tool-CriticBrowser.package/CriticBrowser.class/instance/system 
annoucements/registerToAnnouncements.st
A Tool-CriticBrowser.package/CriticBrowser.class/instance/system 
annoucements/unregisterFromAnnouncements.st
M 
Tool-CriticBrowser.package/CriticsCache.class/instance/add%2Fremove/itemRemoved_.st
A 
Tool-CriticBrowser.package/CriticsCache.class/instance/add%2Fremove/removeRule_.st
M 
Tool-CriticBrowser.package/SingleCodeCriticResultList.class/instance/initialization/initializeActionToPerformOnTextModel.st

  Log Message:
  ---
  60197
19019 Inexactitude in Dictionary class>> newFromPairs: comment
https://pharo.fogbugz.com/f/cases/19019

18950 CritiqueBrowser: Compiler error when accepting a method with argument
https://pharo.fogbugz.com/f/cases/18950

18992 asClass in font related package
https://pharo.fogbugz.com/f/cases/18992

18988 FreeTypeFontProvider should calculate correctly the directories where to 
look for fonts.
https://pharo.fogbugz.com/f/cases/18988

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




Re: [Pharo-dev] About the non-use of Announcer in Bloc

2016-09-01 Thread Denis Kudriashov
Hi Thierry.

2016-09-01 10:21 GMT+02:00 Thierry Goubier :

> (Duration minutes: 1) wait.
>

Just to mention our nice language: it could be written as:


 1 minutes wait


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

2016-09-01 Thread GitHub
  Branch: refs/tags/60197
  Home:   https://github.com/pharo-project/pharo-core


Re: [Pharo-dev] About the non-use of Announcer in Bloc

2016-09-01 Thread Thierry Goubier
Hi Stef,

here is the script I use:

| c1 c2 c3 n1 n2 n3 l1 l2 l3 |
c1 := c2 := c3 := 0.
n1 := (Announcer>>#announce:) ast.
n2 := #(subscribe:do: subscribe:send:to: basicSubscribe:) collect: [ :e |
(Announcer>>e) ast ].
n3 := #(unsubscribe: removeSubscription:) collect: [ :e | (Announcer>>e)
ast ].
l1 := MetaLink new metaObject: [ c1 := c1 + 1 ]; selector: #value.
l2 := MetaLink new metaObject: [ c2 := c2 + 1 ]; selector: #value.
l3 := MetaLink new metaObject: [ c3 := c3 + 1 ]; selector: #value.
[ n1 link: l1. n2 do: [ :e | e link: l2 ]. n3 do: [ :e | e link: l3 ].
(Duration minutes: 1) wait.
n1 removeLink: l1. n2 do: [ :e | e removeLink: l2 ]. n3 do: [ :e | e
removeLink: l3 ].
{ 'announce' -> c1. 'subscribe' -> c2.  'unsubscribe' -> c3 } inspect ]
forkAt: Processor userBackgroundPriority

[image: Images intégrées 1]

2016-09-01 9:28 GMT+02:00 Thierry Goubier :

> Hi Stef,
>
>
> 2016-09-01 8:13 GMT+02:00 stepharo :
>
>> Hi thierry
>>
>> I think that if we would have a tool to show us the activity I'm quite
>> sure that we would find bugs
>>
>> or mistaken behavior.
>>
>
> Yes. I did some checks on Morphic and AltBrowser after getting the
> numbers, to see if I wasn't
> doing something wrong with my code.
>
> could you send the scripts you did?
>>
>
> Later today. I don't have access now to the laptop where I did it.
>
> Thierry
>
>
>>
>> Stef
>>
>>
>> Le 30/8/16 à 22:36, Thierry Goubier a écrit :
>>
>> Numbers for the discussion:
>>>
>>> No activity, empty desktop:
>>> announcements608/minute
>>> subscribe add/remove9/minute
>>>
>>> Activity, AltBrowser:
>>> announcements1109/minute
>>> subscribe add/remove207/minute
>>>
>>> Activity, Nautilus:
>>> announcements2488/minute
>>> subscribe add/remove716/minute
>>>
>>> Empirically the same processus in both environments: open two system
>>> browser, in one, find the Announcer class, browse through a few of the
>>> methods, select basicSubscribe: and ask for senders.
>>>
>>> Tracing done with Metalinks during one minute.
>>>
>>> Not exactly what I would have expected, especially the ratio subscribe
>>> add/remove and announcements.
>>>
>>> Thierry
>>>
>>> Le 30/08/2016 à 17:36, Henrik Johansen a écrit :
>>>

 On 30 Aug 2016, at 5:16 , Thierry Goubier
>  wrote:
>
>
> I have the same concern with an Announcer optimized for certain use
> cases, in the fact that the announcer creator is the one choosing
> the 'kind of' optimisation it would target, hoping that the
> listeners will conform to that use case...
>


 There simply is no silver bullet that will give unbeatable
 performance in all scenarios; and focusing on improving one facet of
 the default implementation will inevitably lead to either - the loss
 of some important property (general thread-safety if removing the
 mutex protection, ability to unsubscribe in handler if removing the
 copy operation and extending the delivery mutex protection, etc.) -
 greatly degenerated performance for another facet (like #remove for
 OC's).

 That said, the current implementation is very geared towards decent,
 balanced subscribe/unsubscribe performance, at the expense of
 delivery speed. I've said it before, and still think, that offering
 at least one other implementation emphasizing delivery speed over
 subscription/unsubscription performance, in the same way the original
 implementation did (and/or changing the default Announcer to switch
 between the two dynamically based on heuristics) *would* be a
 valuable addition to the general library.

 Cheers, Henry


>>>
>>>
>>>
>>
>>
>


Re: [Pharo-dev] About the non-use of Announcer in Bloc

2016-09-01 Thread Denis Kudriashov
2016-09-01 9:57 GMT+02:00 Denis Kudriashov :

> Really? You lost me on that sentence. SystemAnnouncer current is shared by
>> all the tools no?
>
>
> Yes, you are right. I forgot this big monster :).
> Now I look at senders of #announcer and there are many places with chain
> like "aSomebody announcer when:send:..." or also "aSomebody somebodyElse
> announcer when:send:...". So forgot my words :)
>

But these places are definitely smell.


Re: [Pharo-dev] About the non-use of Announcer in Bloc

2016-09-01 Thread Denis Kudriashov
2016-09-01 8:18 GMT+02:00 stepharo :

>
> But in practice we never share any announcer instance.
>
> Really? You lost me on that sentence. SystemAnnouncer current is shared by
> all the tools no?


Yes, you are right. I forgot this big monster :).
Now I look at senders of #announcer and there are many places with chain
like "aSomebody announcer when:send:..." or also "aSomebody somebodyElse
announcer when:send:...". So forgot my words :)


Re: [Pharo-dev] About the non-use of Announcer in Bloc

2016-09-01 Thread Thierry Goubier
Hi Stef,


2016-09-01 8:13 GMT+02:00 stepharo :

> Hi thierry
>
> I think that if we would have a tool to show us the activity I'm quite
> sure that we would find bugs
>
> or mistaken behavior.
>

Yes. I did some checks on Morphic and AltBrowser after getting the numbers,
to see if I wasn't
doing something wrong with my code.

could you send the scripts you did?
>

Later today. I don't have access now to the laptop where I did it.

Thierry


>
> Stef
>
>
> Le 30/8/16 à 22:36, Thierry Goubier a écrit :
>
> Numbers for the discussion:
>>
>> No activity, empty desktop:
>> announcements608/minute
>> subscribe add/remove9/minute
>>
>> Activity, AltBrowser:
>> announcements1109/minute
>> subscribe add/remove207/minute
>>
>> Activity, Nautilus:
>> announcements2488/minute
>> subscribe add/remove716/minute
>>
>> Empirically the same processus in both environments: open two system
>> browser, in one, find the Announcer class, browse through a few of the
>> methods, select basicSubscribe: and ask for senders.
>>
>> Tracing done with Metalinks during one minute.
>>
>> Not exactly what I would have expected, especially the ratio subscribe
>> add/remove and announcements.
>>
>> Thierry
>>
>> Le 30/08/2016 à 17:36, Henrik Johansen a écrit :
>>
>>>
>>> On 30 Aug 2016, at 5:16 , Thierry Goubier
  wrote:


 I have the same concern with an Announcer optimized for certain use
 cases, in the fact that the announcer creator is the one choosing
 the 'kind of' optimisation it would target, hoping that the
 listeners will conform to that use case...

>>>
>>>
>>> There simply is no silver bullet that will give unbeatable
>>> performance in all scenarios; and focusing on improving one facet of
>>> the default implementation will inevitably lead to either - the loss
>>> of some important property (general thread-safety if removing the
>>> mutex protection, ability to unsubscribe in handler if removing the
>>> copy operation and extending the delivery mutex protection, etc.) -
>>> greatly degenerated performance for another facet (like #remove for
>>> OC's).
>>>
>>> That said, the current implementation is very geared towards decent,
>>> balanced subscribe/unsubscribe performance, at the expense of
>>> delivery speed. I've said it before, and still think, that offering
>>> at least one other implementation emphasizing delivery speed over
>>> subscription/unsubscription performance, in the same way the original
>>> implementation did (and/or changing the default Announcer to switch
>>> between the two dynamically based on heuristics) *would* be a
>>> valuable addition to the general library.
>>>
>>> Cheers, Henry
>>>
>>>
>>
>>
>>
>
>