- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Screencast] Using ZnLogEvents and GT Tools to look at HTTP traffic behind Monticello

by Tudor Girba

Nice! :) Doru On Wed, Oct 15, 2014 at 3:55 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Using ZnLogEvents and GT Tools to look at HTTP traffic behind Monticello. > > I love it when a plan comes together. Many small usability changes were > added to GT Tools since they were included in Pharo 4. And a lot of small > custom inspector presentations were added. > > http://youtu.be/rIBbeMdFCys (be sure to select the 720p version) > > This short screencast shows how to use ZnLogEvents and GT Tools in Pharo 4 > to look at the HTTP traffic behing Monticello (more specifically, an > MCSmalltalkhubRepository). This demonstrates how simple custom inspectors > are combined to form a powerful tool - and how easy it is to learn about > what is going on inside Pharo. > > Sven > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 15, 2014

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

by Richard Sargent

Eliot Miranda-2 wrote > On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent < > richard.sargent@ >> wrote: >> One of the best things about Smalltalk is how easily we can say what we >> mean. I think you would be better off creating a method named something >> like >> #hasSameEffectAs: to answer what you are presently using #= to do, and >> change #= to answer the, in my opinion, more sensible "is the same as" >> that >> we conventionally think of #= meaning. >> > > But that's the point. #= has to mean something and having it mean #== > isn't useful, so one has to choose some value-based semantic for > CompiledMethod>>#= and the one that's there is useful. Defining what #= > means for some value type is far easier than defining what it might mean > for something as complex as a CompiledMethod. The definition in > Squeak/Pharo has been useful to me in implementing a closure-based system, > so I'm unapologetic about the current definition. It is a good one but it > doesn't preclude defining others. An interesting response. You ignored the point that e.g. #hasSameEffectAs: provides greater clarity and add an argument against something I didn't say. I also don't think defining equality for a CompiledMethod is particularly difficult. If I were to recompile a method's source code, I would get a new instance of a CompiledMethod that would, in my opinion, be equal to the one already installed in the class (and perhaps cached in the VM's optimizations). So one would be able to say that we would not replace an existing CompiledMethod with an equal one. The current implementation of #= has no such characteristic, since it proclaims a CompiledMethod named #a to be equal to one named #z. The blue book say #= means "Answer whether the receiver and the argument represent the same component." The current implementation does so only for some, in my opinion, counter-intuitive definition of "same component". -- View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p478… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 15, 2014

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

by Eliot Miranda

Hi Richard, On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent < richard.sargent(a)gemtalksystems.com> wrote: > Eliot Miranda-2 wrote > > I responded... > > I have to disagree with your recommendation. You say that you intend #= to > mean "has the same effect as" rather than "is the same as". > > One of the best things about Smalltalk is how easily we can say what we > mean. I think you would be better off creating a method named something > like > #hasSameEffectAs: to answer what you are presently using #= to do, and > change #= to answer the, in my opinion, more sensible "is the same as" that > we conventionally think of #= meaning. > But that's the point. #= has to mean something and having it mean #== isn't useful, so one has to choose some value-based semantic for CompiledMethod>>#= and the one that's there is useful. Defining what #= means for some value type is far easier than defining what it might mean for something as complex as a CompiledMethod. The definition in Squeak/Pharo has been useful to me in implementing a closure-based system, so I'm unapologetic about the current definition. It is a good one but it doesn't preclude defining others. $0.02 worth and worth everything you paid for it. :-) > Richard > > > > > -- > View this message in context: > http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p478… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- best, Eliot

Oct. 15, 2014

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

by Richard Sargent

Eliot Miranda-2 wrote > I responded... I have to disagree with your recommendation. You say that you intend #= to mean "has the same effect as" rather than "is the same as". One of the best things about Smalltalk is how easily we can say what we mean. I think you would be better off creating a method named something like #hasSameEffectAs: to answer what you are presently using #= to do, and change #= to answer the, in my opinion, more sensible "is the same as" that we conventionally think of #= meaning. $0.02 worth and worth everything you paid for it. :-) Richard -- View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p478… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 15, 2014

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

by Eliot Miranda

I responded... On Wed, Oct 15, 2014 at 7:11 AM, Max Leske <maxleske(a)gmail.com> wrote: > We found an issue where CompiledMethods can produce the same hash event > within the same MethodDictionary. Reported here: > > > https://pharo.fogbugz.com/f/cases/14246/CompiledMethod-hash-can-produce-cla… > > Cheers, > Max > -- best, Eliot

Oct. 15, 2014

Re: [Pharo-dev] Context variables?

by Camille Teruel

Hi Jeff, I think you should look at DynamicVariable and ProcessSpecificVariable classes. The first one is a read-only while the second is writable. You have to subclass these class for each variable you want. Ex: DynamicVariable subclass: #MyVar. MyVar value: 4 during: [ MyVar value ] HTH, Camiile On 15 oct. 2014, at 17:09, J.F. Rick <self(a)je77.com> wrote: > I remember there was some discussion on the list about support for variables tied to the context rather than to the instance or class. This seems particularly useful for a web application where you might want to access the request and response from the context. What is the proper name for these kind of variables and where can I read about how to use them? > > Cheers, > > Jeff > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick

Oct. 15, 2014

Context variables?

by J.F. Rick

I remember there was some discussion on the list about support for variables tied to the context rather than to the instance or class. This seems particularly useful for a web application where you might want to access the request and response from the context. What is the proper name for these kind of variables and where can I read about how to use them? Cheers, Jeff -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Oct. 15, 2014

[Pharo4] Properties for classes

by Marcus Denker

Hi, Methods, AST Nodes and all Ring Definitions can store properties. Now in Pharo4 update 307, Yuriy Tymchuk extended this idea to Behaviors. They are not stored when saving code (filing out or MC), as this would be on top (as are the Pragmas on Methods build on top of properties). TODO -> unify API across RB/CompiledMethod/Ring -> add properties to the Variable meta-objects (there is already a proof-of-concept in class LinkWrapper for one special kind of property) -> For sure there are bugs (while writing this I had one idea of one alreadyâ¦ need to check) This will not be used by the system itself for now, therefore we opted to store them not in an ivar but a classVar dictionary, so they do not take any space when not used (like CompiledMethod properties where realised in the beginning, too). Marcus

Oct. 15, 2014

Re: [Pharo-dev] creating custom browsers out of GTInspector extensions

by Hilaire

Le 14/10/2014 23:26, Tudor Girba a Ã©crit : > Now, that more people are playing with the GTInspector, I would like to > raise another point that might otherwise go unnoticed: The inspector > extensions do not only work in the inspector, but can also be combined > in other browsers as well. > It really looks intersting! I can imagine some good use of it to navigate in geometric objects. Thanks Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Oct. 15, 2014

[pharo-project/pharo-core]

by GitHub

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

Oct. 15, 2014