March 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Existing <script> <example> pragmas and new GT needs

by kilon alios

Hey guys since we talk about the <example> pragma, I wanted to thank the implementors of this very useful feature. I was testing Bloc and it comes with loads of examples using this pragma and has been extremely convenient. Definitely will be using it with my code too. I was not ware of <script> that sound very useful too. Keep up the awesome job.

March 25, 2015

Re: [Pharo-dev] Slots and MethodWrappers

by stepharo

shining and bright future. Le 24/3/15 17:27, Marcus Denker a Ã©crit : > >> On 24 Mar 2015, at 13:02, phil(a)highoctane.be >> <mailto:phil@highoctane.be> wrote: >> >> I wondered how these two things are related. >> >> Will slots be giving MWs facilities out of the box? >> >> When should I use both? >> > Hello, > > Slots are about state (instance variables), while method wrappers are > about methods > (and hooking into method execution). So they are not directly related, > but there is indeed > a connection :-) > > The MetaLinks (which we will get for real in Pharo5, I sadly did not > finish it for Pharo4) > can be seen as a generalisation of MethodWrappers. They are much more > flexible and > apply not to whole methods, but any âstructuralâ reflective entity. > > This means any node in the AST, but, in addition, slots. This means > you can put a meta-link > on a slot (e.g. one describing a normal instance variable) and call > meta-object before, after > or instead. Which in some way means that you can put a âwrapperâ on an > instance variable. > > The meta-link machinery will indeed completely replace method > wrappers. You can implement > method wrappers using them if you need them, but in most cases using > directly the link will > be exactly what you need. > > I am sure we will use this *a lot* for the tools. E.g. breakpoints > will use links to hook into execution. > Or the inspector will use them to get notified on state change to > update the displayâ¦ an many more. > > Marcus

March 25, 2015

Re: [Pharo-dev] Morphs becoming unresponsive

by stepharo

you are both cool :) Le 24/3/15 12:04, Henrik Johansen a Ã©crit : > >> On 24 Mar 2015, at 11:22 , Alain Plantec via Pharo-dev >> <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> wrote: >> >> >> *Subject: **Re: [Pharo-dev] Morphs becoming unresponsive* >> *From: *Alain Plantec <alain.plantec(a)yahoo.com >> <mailto:alain.plantec@yahoo.com>> >> *Date: *24 Mar 2015 11:21:55 CET >> *To: *Pharo Development List <pharo-dev(a)lists.pharo.org >> <mailto:pharo-dev@lists.pharo.org>> >> >> >> Hello Henrik, >> >> I read >> windowEvent: anEvent >> .... >> WorldState quitSession. >> self removeProperty: #closeWorldDialogOpen ] >> >> but shouldn't it be >> >> windowEvent: anEvent >> .... >> WorldState quitSession. >> self removeProperty: #canOpenCloseDialog ] >> >> Cheers >> Alain > > You are right of course, thanks! > Last minute renames are never a good idea, even when the method is 5 > lines long :/ > I submitted a new slice where the property name is consistent. > > Cheers, > Henry

March 25, 2015

could the size of Playground be reduced a bit

by stepharo

Because it is a bit large now even on a 27 inch screen.

March 25, 2015

Re: [Pharo-dev] Making Seaside work in Pharo 4

by stepharo

strange that it was removed. Le 24/3/15 09:21, Stephan Eggermont a Ã©crit : > In Issue 13739, build 40145 classesInTheSelectedPackage in Nautilus > was removed. What is the correct way to replace it? WABrowser uses a > nautilus browser to show a web-based browser. > (build 609, Seaside #'release3.1' pharo4, from ci) > > WABrowserTest>>testContentsNotifying > | model | > model := WABrowser browserClass new. > model systemCategoryListIndex: (model systemCategoryList indexOf: > 'Seaside-Tests-Pharo-Development'). > model classListIndex: (model classList indexOf: #WABrowserTest). > model messageCategoryListIndex: (model messageCategoryList > indexOf: #'-- all --'). > [ > self assert: > (model contents: 'sampleMethod > ^ 1 + 1' > notifying: self). > self assert: message isNil ] > ensure: [ WABrowserTest removeSelectorSilently: #sampleMethod ] > > Stephan > > >

March 25, 2015

Re: [Pharo-dev] Existing <script> <example> pragmas and new GT needs

by Andreas Wacknitz

Am 25.03.15 um 17:32 schrieb Torsten Bergmann: > Hi Tudor, > > >However, I think there is significantly more value in examples that do return > objects. > > Yet again: no doubt that they may be of value. This is not the point. > If they provide "more value" > than methods that do not return an instance depends on what you want > to achieve with them. > But please accept the fact that they are NOT THE ONLY WAYof giving > "examples" on system usage > to others. There are in fact others as well. > Regarding your script suggestion: > Examples and script have in common is that they can be executed - but > that does not > automagically makes them the same. An example is CONCEPTUALLY not the > same as a > script. > The purpose of creating a script is a different from the purpose of > creating an example. > A script is something I ran, an example is something that is > explicitly provided for others > to learn from it. > >Until now, nobody is really using the <example> except the code that > is packaged in GT > For me one really important thing is: get the names right. 4.0 will be released soon. What is being introduced now will stay for a while. You discussion makes it clear to me that <example> is misleading and thus not an optimal name (for both usages). So it would be better to choose something more intention revealing like <exampleCode> and <exampleInstance>. This also makes room for more example ideas in the future. My 2 cents. Andreas

March 25, 2015

Re: [Pharo-dev] Existing <script> <example> pragmas and new GT needs

by Torsten Bergmann

Alex wrote: >I agree with Doru. Just checked the image and it seems that there is already quite a number of methods with <example> annotation that behave exactly >the same behaviour described by Doru. Yes - there are more for a simple reason: because Doru created them according to HIS OWN definition to solely return instances. And they come in as GT extension methods. Would my opinion/points are more valid if we had more examples tagged <example> tags to mark all example methods? >So maybe we could continue having <example> to show how to create a valid instance of the class that have some >value and can work? One benefit is that we could based on <example> show some usefull preview of the class in inspector. The point is that we could do this preview with <exampleInstance> or <exemplar> as well! We do not lose anything! So with two different tags: - <example> for general examples - and <exemplar> <exampleInstance> for valid instances we would catch TWO FLIES INSTEAD OF JUST ONE: we would not be dependent on exampleXXX selector naming to mark example methods as it is now also in Pharo 4 AND we could do the preview in the new GT tools!!! Also with <exampleInstance> or <exemplar> we would also make it more clear that it returns an instance for a preview! In non-technical terms this would be a WIN-WIN for Tudor and me ;) Â >Assume having a MultistateButtonMorph with <example> pragma. You can inspect MultistateButtonMorph (class) and >will get as preview morph instance of the button. It is not that I do not understand this. I know that by providing instance examples this would also be a step forward on the GT/tools side. I would not like to see only ONE step backward and only ONE forward when we can do TWO MOVES forward. Is this so hard to understand? If Tudor agrees on either <examplar> <sample> or <exampleInstance> he will get a beer. Should I buy you a beer as well to convince you? ;) Thx T.

March 25, 2015

Re: [Pharo-dev] Existing <script> <example> pragmas and new GT needs

by Guillermo Polito

El miÃ©., 25 de mar. de 2015 a la(s) 5:44 p. m., Aliaksei Syrel < alex.syrel(a)gmail.com> escribiÃ³: > On Wed, Mar 25, 2015 at 5:32 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > >> I would like to see more opinions or proposals from others. ;) >> > > I agree with Doru. Just checked the image and it seems that there is > already quite a number of methods with <example> annotation that behave > exactly the same behaviour described by Doru. So maybe we could continue > having <example> to show how to create a valid instance of the class that > have some value and can work? One benefit is that we could based on > <example> show some usefull preview of the class in inspector. > Well, that's right. But it is also right that most of them are extensions added by gt. The only thing that we can conclude is that the <example> pragma was not much used before... :) > > Assume having a MultistateButtonMorph with <example> pragma. You can > inspect MultistateButtonMorph (class) and will get as preview morph > instance of the button. > Here I'm with Torsten. To me there there are examples of objects, and examples of how to use an object, and both are different. - On the first you give a well formed object that shows how it is in the inside. - On the second you show what is its API, not caring about the internals. Both are useful depending on what you're doing, but I think the second one is more useful. Specially when I'm working with already existing objects that I have in my hand because I use to inspect leaf objects, not classes. Guille > > Cheers, > Alex >

March 25, 2015

Monitoring spotter

by Alexandre Bergel

Hi! The GT crew recently introduces in Pharo a way to keep track of what people are searching in the system. This is a highly valuable piece of information that could benefit everybody. For example, I would love to know which Roassal classes are looking the most often. Or which Roassal examples people are repeatedly searching. However, this is hard to know currently. The reason is because of anonymity. No strings are stored in what is being sent over. To me, this is _highly counter-productive_: if you are working with sensitive information (I donât personally), then do not send things over. But enforcing anonymity generate frustration. So, here is my call: If you care about letting us improving the tools everybody use, feel free to reveal your identity. Simply send the result of the following expression: GTSpotterEventRecorderSettings uniqueInstance secretUUID hash For me => 195966943 Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 25, 2015

Re: [Pharo-dev] Existing <script> <example> pragmas and new GT needs

by Torsten Bergmann

"Ben Coman" wrote >The word that I feel best applies to Doru's need is <sample>, to return a fully initialised sample instance that you can play with in the >Inspector.Â When you double-click a method so tagged you can think of it as "give me a sample" of yourself. What would you both think of "exemplar" and "give me an examplar of yourself"? According to Google definition of <exemplar> noun - "a person or thing serving as a typical example or excellent model." Urban dictionary defines <exemplar> as "a typical or standard model or specimen". which would also perfectly fit. @Tudor: please use that and I buy you a beer ;) Thanks T.

March 25, 2015