September 2015 - Pharo-users

Re: [Pharo-users] Observing changes of regular attributes

by Marcus Denker

Hello, The idea of Reflectivity is to be just that: a way to âhookâ into code without changing the sourceâ¦ this is a similar use case like the one described yesterday: link := MetaLink new metaObject: MyNotifyer; selector: #notifyChangedVaNamed:; arguments: #(name). this is a link that when installed on an AssignmentNode, will call #notifyChangedVaNamed on a class MyNotifyer with the name of the changed variable passed as an argument. (you can pass other things needed, one could even have an Announcement as the metaObject. To install this on all ivar assignments, do: MyClass assignmentNodes do: [ :each | each variable isInstance ifTrue: [each link: link ]]. to get rid of the link: link uninstall. Now when code is recompiled (loaded), you need to re-install the links in those methods, it does not happen automatically. Marcus > On 09 Sep 2015, at 18:18, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > is there a mechanism for observing a change of regular variables? > > Normally I would use ValueHolder (or fire announcements manually), but this assumes I can change the code. > > For example imagine a method of someone else's package > ~~~~~~~~~~~~~~~ > FAMIXNamedEntity>>name: aString > name := aString > ~~~~~~~~~~~~~~~ > > I could simply override the method, but that's very brittle since if I were to update the package it would load the "unmodified" version. > > Can I somehow overload the assignment operator? Can I augment methods? Is this even possible? > > Thanks, > Peter

Sept. 9, 2015

Re: [Pharo-users] Observing changes of regular attributes

by Marcus Denker

> On 09 Sep 2015, at 21:26, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Le 09/09/2015 21:00, Mariano Martinez Peck a Ã©crit : >> If you can live with only intercepting setters (not assigments) , then >> you can run some code AFTER loading the code, to install some method >> wrappers or Marea CompiledMethod proxy that intercept the execution of >> the setter method and do whatever you want. In the worst case you simply >> must re-run such script after reloading the code .... > > You can also use Jejak to trace assignments with the same approach (i.e. to reinstall the probes after loading a new version), but you'll have to adapt one of the Jejak rewriter for that (or filter the generated events to retrieve only the ones relevant to your instance variable). > > By the way, Marcus, how do Metalinks behave in this scenario (i.e. reloading a new version of the code). Are they lost? > Yes, re-applying links needs to be done by the user for now. I should add a framwork and example to make this easier. Marcus

Sept. 9, 2015

Re: [Pharo-users] Observing changes of regular attributes

by Thierry Goubier

Le 09/09/2015 21:00, Mariano Martinez Peck a Ã©crit : > If you can live with only intercepting setters (not assigments) , then > you can run some code AFTER loading the code, to install some method > wrappers or Marea CompiledMethod proxy that intercept the execution of > the setter method and do whatever you want. In the worst case you simply > must re-run such script after reloading the code .... You can also use Jejak to trace assignments with the same approach (i.e. to reinstall the probes after loading a new version), but you'll have to adapt one of the Jejak rewriter for that (or filter the generated events to retrieve only the ones relevant to your instance variable). By the way, Marcus, how do Metalinks behave in this scenario (i.e. reloading a new version of the code). Are they lost? Thierry > > > On Wed, Sep 9, 2015 at 3:27 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Not yet :) > > Le 9/9/15 18:18, Peter UhnÃ¡k a Ã©crit : > > Hi, > > is there a mechanism for observing a change of regular variables? > > Normally I would use ValueHolder (or fire announcements > manually), but this assumes I can change the code. > > For example imagine a method of someone else's package > ~~~~~~~~~~~~~~~ > FAMIXNamedEntity>>name: aString > name := aString > ~~~~~~~~~~~~~~~ > > I could simply override the method, but that's very brittle > since if I were to update the package it would load the > "unmodified" version. > > Can I somehow overload the assignment operator? Can I augment > methods? Is this even possible? > > Thanks, > Peter > > > > > > > -- > Mariano > http://marianopeck.wordpress.com

Sept. 9, 2015

Re: [Pharo-users] [Pharo-dev] [ANN] MessageFlowBrowser

by Torsten Bergmann

Sept. 9, 2015

Re: [Pharo-users] Observing changes of regular attributes

by Mariano Martinez Peck

If you can live with only intercepting setters (not assigments) , then you can run some code AFTER loading the code, to install some method wrappers or Marea CompiledMethod proxy that intercept the execution of the setter method and do whatever you want. In the worst case you simply must re-run such script after reloading the code .... On Wed, Sep 9, 2015 at 3:27 PM, stepharo <stepharo(a)free.fr> wrote: > Not yet :) > > Le 9/9/15 18:18, Peter UhnÃ¡k a Ã©crit : > > Hi, >> >> is there a mechanism for observing a change of regular variables? >> >> Normally I would use ValueHolder (or fire announcements manually), but >> this assumes I can change the code. >> >> For example imagine a method of someone else's package >> ~~~~~~~~~~~~~~~ >> FAMIXNamedEntity>>name: aString >> name := aString >> ~~~~~~~~~~~~~~~ >> >> I could simply override the method, but that's very brittle since if I >> were to update the package it would load the "unmodified" version. >> >> Can I somehow overload the assignment operator? Can I augment methods? Is >> this even possible? >> >> Thanks, >> Peter >> > > > -- Mariano http://marianopeck.wordpress.com

Sept. 9, 2015

Re: [Pharo-users] Observing changes of regular attributes

by stepharo

Not yet :) Le 9/9/15 18:18, Peter UhnÃ¡k a Ã©crit : > Hi, > > is there a mechanism for observing a change of regular variables? > > Normally I would use ValueHolder (or fire announcements manually), but > this assumes I can change the code. > > For example imagine a method of someone else's package > ~~~~~~~~~~~~~~~ > FAMIXNamedEntity>>name: aString > name := aString > ~~~~~~~~~~~~~~~ > > I could simply override the method, but that's very brittle since if I > were to update the package it would load the "unmodified" version. > > Can I somehow overload the assignment operator? Can I augment methods? > Is this even possible? > > Thanks, > Peter

Sept. 9, 2015

Re: [Pharo-users] [ANN] MessageFlowBrowser

by stepharo

Coooool I want to try it! Thanks for it. This was a project I wanted to propose. Le 9/9/15 14:07, Torsten Bergmann a Ã©crit : > A new tool to browse and dive deep into the flow of messages > using a tree representation (messages, senders, implementors, ...) > and further on. I know such a tool from Smalltalk/MT and it is really > helpful to trace a message flow without running in the debugger. > > See the attached screenshot, the best is to try it: > > In a latest Pharo 5.0 image (Pharo5.0 Latest update: #50314) > you can evaluate: > > Gofer new > url: 'http://smalltalkhub.com/mc/TorstenBergmann/MessageFlowBrowser/main'; > package: 'Tool-MessageFlowBrowser'; > load > > to load it. > > Then open whatever method in Nautilus and choose "Message Flow" from the context > menu. The nice thing is that you can dive into senders, implementors, messages sent > deeper and deeper (or up again) and you do not open more and more windows but stay > in a single window !!! > > Alternatively you can start the tool from the playground: > > MessageFlowBrowser openOn: #inspect "open the flow browser on a selector" > > MessageFlowBrowser openOn: (Compiler>>#evaluate) "open the flow browser on a method" > > MessageFlowBrowser openOn: Object "open the flow browser on a class" > > 1 messageFlow. "open the flow browser on the class of an instance" > > > If someone with GT knowledge and time could help to correct the syntax highlighting > in the code pane this would be super cool (see method MessageFlowBrowser #openOn:). > Also selection could be improved to show/highlight the messages sent directly > in the code. Unfortunately I'm not so familar with the current code editors - so > any help is appreciated. > > Repo is open for contribution. > > Thanks > T. >

Sept. 9, 2015

Re: [Pharo-users] [Moose-dev] Re: [ann] brick on top of bloc - preview

by Offray Vladimir Luna CÃ¡rdenas

Hi, Thanks for the prebuild image, works like a charm. For me is a timely reading because I'm now redesigning the interface of my project. I considered for a while jumping directly to bloc, but there is still not enough documentation, so I will go with Spec first. In fact there is a sense of continuous moving in Pharo that is nice, but can be difficult at the same time. So, some feedback: a) All the looking is pretty nice. I specially like the "Window with content" example (the one with the dog). b) I think that we need visual clues to tell apart tabs from buttons, from menus. c) I was unable to find a named menu, only the vertical suspensive points without any name. Named menus are a big advantage of Spec over GT-Tools, so will be nice to have them on this new interface. d) When you click on the examples window it doesn't raise over other windows, you need to move it to get it raised. e) Fonts seems kind of pixelated when compared between current pharo 4 and pharo + bloc. See the comparison here (left pharo 4, right: Pharo + Bloc). f) I have been looking for information on how to renew the icons of my interface and material icons are really nice. Would be useful to have them listed somehow besides the current eclipse ones. I wonder how difficult will be to migrate an interface from Spec to bloc in the future. Should I stick with Spec? Cheers, Offray Thanks and keep the good work. On 27/08/15 15:00, Aliaksei Syrel wrote: > Hi, > > We prepared a working image with Brick preview :) Just open it with > the latest Pharo VM and you will instantly see an example browser > â > Pharo-Brick.zip > <https://drive.google.com/file/d/0B-bMBVDOi3oTdll3dGJValVIenc/view?usp=drive…> > â > > Cheers, > Alex > > On Tue, Aug 25, 2015 at 10:13 PM, Tudor Girba <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>> wrote: > > Hi, > > We are happy to announce the first preview version of Brick, a new > widget set created from scratch on top of Bloc. > > Brick is being developed primarily by Alex Syrel (together with > Alain Plantec, Andrei Chis and myself), and the work is sponsored > by ESUG. Brick is part of the Glamorous Toolkit effort and will > provide the basis for the new versions of the development tools. > > Brick's goal is to provide a beautiful looking widget set, and the > default look is based on material design. The widgets are theme-able. > > Right now, there exists: > - Label > - Simple button > - Toggle button > - Checkbox > - Radio button > - Window with or without an active title bar that can include > various visual actions and info > - Menu > - Beautiful scrollbars that are thin by default and enlarge when > the mouse hovers over it > - Scalable list for huge amounts of items with various heights > (The list also allows one for embedding text widgets with in place > editing) > > The next immediate target is the creation of a new Pager widget > (the widget that is behind the current GTInspector). > > You can see some screenshots on the official site: > http://gt.moosetechnology.org/brick > > To play with it, you can download a ready-made image: > https://ci.inria.fr/moose/job/gtoolkit5/lastSuccessfulBuild/artifact/gtoolk… > > and, in a Bloc space, you can browse the examples: > BrExampleBrowser exampleOpen > > We would be happy to hear your feedback. > > Cheers, > Doru > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow" > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Sept. 9, 2015

Re: [Pharo-users] [Pharo-dev] [ANN] MessageFlowBrowser

by Alexandre Bergel

Also, it would be great to have it accessible from the World/Tools menu. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Sep 9, 2015, at 9:07 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > > A new tool to browse and dive deep into the flow of messages > using a tree representation (messages, senders, implementors, ...) > and further on. I know such a tool from Smalltalk/MT and it is really > helpful to trace a message flow without running in the debugger. > > See the attached screenshot, the best is to try it: > > In a latest Pharo 5.0 image (Pharo5.0 Latest update: #50314) > you can evaluate: > > Gofer new > url: 'http://smalltalkhub.com/mc/TorstenBergmann/MessageFlowBrowser/main'; > package: 'Tool-MessageFlowBrowser'; > load > > to load it. > > Then open whatever method in Nautilus and choose "Message Flow" from the context > menu. The nice thing is that you can dive into senders, implementors, messages sent > deeper and deeper (or up again) and you do not open more and more windows but stay > in a single window !!! > > Alternatively you can start the tool from the playground: > > MessageFlowBrowser openOn: #inspect "open the flow browser on a selector" > > MessageFlowBrowser openOn: (Compiler>>#evaluate) "open the flow browser on a method" > > MessageFlowBrowser openOn: Object "open the flow browser on a class" > > 1 messageFlow. "open the flow browser on the class of an instance" > > > If someone with GT knowledge and time could help to correct the syntax highlighting > in the code pane this would be super cool (see method MessageFlowBrowser #openOn:). > Also selection could be improved to show/highlight the messages sent directly > in the code. Unfortunately I'm not so familar with the current code editors - so > any help is appreciated. > > Repo is open for contribution. > > Thanks > T. > > <messageflow.png>

Sept. 9, 2015

Re: [Pharo-users] [ANN] MessageFlowBrowser

by Alexandre Bergel

Hi Torsten, Can you make it available from the catalog browser ? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Sep 9, 2015, at 9:07 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > > A new tool to browse and dive deep into the flow of messages > using a tree representation (messages, senders, implementors, ...) > and further on. I know such a tool from Smalltalk/MT and it is really > helpful to trace a message flow without running in the debugger. > > See the attached screenshot, the best is to try it: > > In a latest Pharo 5.0 image (Pharo5.0 Latest update: #50314) > you can evaluate: > > Gofer new > url: 'http://smalltalkhub.com/mc/TorstenBergmann/MessageFlowBrowser/main'; > package: 'Tool-MessageFlowBrowser'; > load > > to load it. > > Then open whatever method in Nautilus and choose "Message Flow" from the context > menu. The nice thing is that you can dive into senders, implementors, messages sent > deeper and deeper (or up again) and you do not open more and more windows but stay > in a single window !!! > > Alternatively you can start the tool from the playground: > > MessageFlowBrowser openOn: #inspect "open the flow browser on a selector" > > MessageFlowBrowser openOn: (Compiler>>#evaluate) "open the flow browser on a method" > > MessageFlowBrowser openOn: Object "open the flow browser on a class" > > 1 messageFlow. "open the flow browser on the class of an instance" > > > If someone with GT knowledge and time could help to correct the syntax highlighting > in the code pane this would be super cool (see method MessageFlowBrowser #openOn:). > Also selection could be improved to show/highlight the messages sent directly > in the code. Unfortunately I'm not so familar with the current code editors - so > any help is appreciated. > > Repo is open for contribution. > > Thanks > T. > > <messageflow.png>

Sept. 9, 2015