April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Why we have Behavior >> flushCache?

by StÃ©phane Ducasse

what is the cache flushed? I think that your point is valid and it would be good to do it. Stef On Apr 26, 2011, at 12:34 PM, Mariano Martinez Peck wrote: > Hi. As far as I can see, > > Behavior >> flushCache > "Tell the interpreter to remove the contents of its method lookup cache, if it has > one. Essential. See Object documentation whatIsAPrimitive." > > <primitive: 89> > self primitiveFailed > > > And primitive 89 does nothing in particular with the receiver (the class in this case). In both, InterpreterVM and Cog, the WHOLE cache is flushed, there is NOTHING related to the receiver class. Of course, that's at least what it looks for me (please tell me if I am wrong). > So...if this is the case, wouldn't make sense to move it elsewhere? like Smalltalk flushCache or Smalltalk vm flushCache (and it is a good moment to reify the VM). So after we can do: Smalltalk vm version. Smalltlak vm flushCache, Smalltalk vm parameterAt: , etc.... > > If you don't like doing "Smalltalk vm" then we can create a VM class with all class methods, or a singleton and use #current or a singleton and put it in Smalltalk globals...etc > > We will need to fix a couple of senders, thus. > > What do you think? For me is really confusing, and you don't understand it until you see the primitive implementation. > > Cheers > > -- > Mariano > http://marianopeck.wordpress.com >

April 26, 2011

[Pharo-project] Why we have Behavior >> flushCache?

by Mariano Martinez Peck

Hi. As far as I can see, Behavior >> flushCache "Tell the interpreter to remove the contents of its method lookup cache, if it has one. Essential. See Object documentation whatIsAPrimitive." <primitive: 89> self primitiveFailed And primitive 89 does nothing in particular with the receiver (the class in this case). In both, InterpreterVM and Cog, the WHOLE cache is flushed, there is NOTHING related to the receiver class. Of course, that's at least what it looks for me (please tell me if I am wrong). So...if this is the case, wouldn't make sense to move it elsewhere? like Smalltalk flushCache or Smalltalk vm flushCache (and it is a good moment to reify the VM). So after we can do: Smalltalk vm version. Smalltlak vm flushCache, Smalltalk vm parameterAt: , etc.... If you don't like doing "Smalltalk vm" then we can create a VM class with all class methods, or a singleton and use #current or a singleton and put it in Smalltalk globals...etc We will need to fix a couple of senders, thus. What do you think? For me is really confusing, and you don't understand it until you see the primitive implementation. Cheers -- Mariano http://marianopeck.wordpress.com

April 26, 2011

Re: [Pharo-project] [Moose-dev] Re: removing versions from configurations

by Tudor Girba

Hi Stef, On 26 Apr 2011, at 11:35, StÃ©phane Ducasse wrote: >>> >>> yes but this is the price to pay if you want a really robust package system. >>> I cannot work on a system where I cannot rollback and check a given version and I cannot work with a system >>> where I can lose half of my work. >> >> Sure. Just do not work with the baseline then. > > I dnu what you mean. > > > >> Although I am sure that when you are developing RPackage, you do want to load the very latest versions of packages :) >> >>> So sorry but I need to control the version I work with and there is no way I will work on RPackage with default >>> (and yes this is a pain for me too to have to change all the time the configuration but this is the only way). >> >> I do not understand your line of reasoning. You do not have to work with default to provide a default. > > because people load the default and code based on the default and after a certain period of time configurations are not updated > and this is the mess. > So now for RPackage there is no default so that people changing it are FORCED to produce a new configuration with named file. > > >> If you want to work with a specific version, work with a specific version. Default is nothing but a baseline. > Indeed I know that > > >> You did not remove the other baseline, but you removed default. > > Yes I know. I did it on purpose. No way to load latest using default. But you did not circumvent anything. All I have to do is load the baseline10: and then I get the latest versions of packages :). Anyway, the discussion was simply about the ripple effects of removing a version from a configuration. This is similar to removing a package version from a Monticello repository. >> In any case, my message came from the point of view of someone who integrates and it is not related to default. I understand your needs but I wanted to point out the dangers that come with removing a version. > > Yes this was an emergency solution because I succeeded to lose code (which did not happen to me over the last 10 years in smalltalk). > Now I'm back to the point where > - RPackage tests are better > - Clean SystemAnnouncements > - Green > - I have annotated a lot of issues to fix and verify > - So I will be able to make progress, add more tests > Looks like I control RPackage now. I am happy you are in control. Cheers, Doru > Stef -- www.tudorgirba.com "Don't give to get. Just give."

April 26, 2011

Re: [Pharo-project] Better debugging...

by StÃ©phane Ducasse

Yes soon or later we will clean the debugger code and principle too :) I'm interested in any progress on that front. Stef On Apr 25, 2011, at 11:29 PM, Camillo Bruni wrote: > I think a nice way to have a decent debugger is to run the program on top of a changeable interpreter. Since a classical debugger is nothing else but an interpreter with slightly changed semantics. > > The object flow VM does a great job at tracing back stuff.. however it might pose a massive overhead since it collects tons and tons of data. > > In Pinocchio[1] we implemented very nice and simple debuggers by "just" changing the current interpreter to take a user-action into account on each message send. Since this is implemented on top of a metacircular interpreter this was quite simple to achieve. So the whole implementation of the known debugger functionality (step, over...) maybe took an afternoon. Since you have access to the full interpreter protocol it is very easy to intercept different sorts of actions. As described in the linked paper, it was very easy to implement the object-flow behavior in Pinocchio. > > So for me there is only one real way to have a decent debugger. And that means that it is a first-class interpreter whose semantics I can change at will. Thus I can create a specific debugger for my applications. > > But I guess that making the first-class interpreters work right away in Pharo will take a while to do, hence I propose the following additions to the current interpreter to make it partly useable: > > - interception of message sends > - per thread [ok] > - of specific classes [missing] > - of specific instances [missing] > > - interception of instance variable access, read/write > - per thread [missing] > - of specific classes [missing] > - of specific instances [missing] > - of specific instance variables [missing] > > Furthermore I really want to be able to script all of that stuff, eg. provide a simple test block that gets invoked on each message send. Returning true => halt, Returning false => continue execution. > > > [1] http://scg.unibe.ch/archive/papers/Verw10aPinocchio.pdf

April 26, 2011

Re: [Pharo-project] [Moose-dev] Re: removing versions from configurations

by StÃ©phane Ducasse

>> >> yes but this is the price to pay if you want a really robust package system. >> I cannot work on a system where I cannot rollback and check a given version and I cannot work with a system >> where I can lose half of my work. > > Sure. Just do not work with the baseline then. I dnu what you mean. > Although I am sure that when you are developing RPackage, you do want to load the very latest versions of packages :) > >> So sorry but I need to control the version I work with and there is no way I will work on RPackage with default >> (and yes this is a pain for me too to have to change all the time the configuration but this is the only way). > > I do not understand your line of reasoning. You do not have to work with default to provide a default. because people load the default and code based on the default and after a certain period of time configurations are not updated and this is the mess. So now for RPackage there is no default so that people changing it are FORCED to produce a new configuration with named file. > If you want to work with a specific version, work with a specific version. Default is nothing but a baseline. Indeed I know that > You did not remove the other baseline, but you removed default. Yes I know. I did it on purpose. No way to load latest using default. > In any case, my message came from the point of view of someone who integrates and it is not related to default. I understand your needs but I wanted to point out the dangers that come with removing a version. Yes this was an emergency solution because I succeeded to lose code (which did not happen to me over the last 10 years in smalltalk). Now I'm back to the point where - RPackage tests are better - Clean SystemAnnouncements - Green - I have annotated a lot of issues to fix and verify - So I will be able to make progress, add more tests Looks like I control RPackage now. Stef

April 26, 2011

Re: [Pharo-project] new template for class empty comments for OB

by StÃ©phane Ducasse

the problem of automated is that your would like aslo to know the roles of the class during its interaction. But this could be something to start about the collaboration may be you should only show roots when you have root and leaves. stef On Apr 25, 2011, at 10:25 PM, Alexandre Bergel wrote: > Hi! > > I worked on a small prototype to help me write code documentation. > As an example, here is a template that is automatically given for MOShape, an abstract class in Mondrian that does not have any class variables. MOShape has just one instance variable, isCached. > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > 'MOShape is PLEASE FILL > MOShape is an abstract class. The following methods needs to be implemented > #absoluteBoundsFor: #containsPoint:for: #display:on: #heightFor: #widthFor: > > Class collaborations > MOFilledShape MORoundedRectangleShape MOEvent MOLineShape MOAbstractLineLayout MOHorizontalLineLayout MOShape MOVerticalLineLayout MONode MOMouseEvent MOFormsShape MOImageShape MOEasel MOViewRenderer MOShapeAdaptor MOGraphElement MOFormsBuilder MOBoundedShape MOChildrenShape MONodeShape > > Testing classes > MOViewRendererTest MondrianTest MOFormsBuilderTest MONewFormsBuilderTest > > Class public API > #absoluteBoundsFor: #apply:bounds: #boundsFor: #canHandleChildren #collectAllShapes #computeBoundsFor: #computeExtentFor: #containsPoint:for: #disableCache #display:on: #enableCache #heightFor: #isCached #isChildShape #isFormsShape #isLineShape #isNodeShape #isShape #scaleElement:by: > Implementation notes > > Instance Variables: > isCached -- PLEASE FILL > > Comments written by AlexandreBergel on 25 April 2011 > ' > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > I plan to use this template for each class of Mondrian. > The template can be easily automatically processed to detect inconsistency. > > A collaboration class is a class for which I sent to or received a message from. Unit tests are excluded. > A public method is a method that is invoked by an instance of a different class. This is very Java specific, I know. We could scope it to an object instead of a class. > > What is your opinion on this template? > > Cheers, > Alexandre > > > On 25 Apr 2011, at 11:59, Alexandre Bergel wrote: > >> I see your point. We need to iterate on what a good template can be. >> >> In general, I believe a lot can be extracted from unit test execution that can serve as a good basis for documentation: public, private methods, collaboration, ... >> >> Alexandre >> >> >> On 25 Apr 2011, at 03:15, Lukas Renggli wrote: >> >>> Hi Alexandre, >>> >>>> But this is not incompatible. The IVs may still be listed, >>>> the template can be adjusted for that >>> >>> Yes, this is true and the proposed change takes the IVs into account. >>> The only problem is that I have to scroll to the bottom in 90% of the >>> cases as the variables are a couple of pages below the template text. >>> 90% of the time I am looking for information and then something like >>> the variable types is at least useful, a two page template is only >>> "useful" the few times I actually write a comment. >>> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

April 26, 2011

Re: [Pharo-project] Better debugging...

by Jorge Ressia

Hi guys, Stef, BifrÃ¶st was invented for this particular purpose. http://scg.unibe.ch/research/bifrost BifrÃ¶st is a unified approach to reflection. Stef, if you explain a little bit the use case I can quickly provide an adaptation solution. HTH, Jorge On Mon, Apr 25, 2011 at 11:29 PM, Camillo Bruni <camillo.bruni(a)inria.fr> wrote: > I think a nice way to have a decent debugger is to run the program on top of a changeable interpreter. Since a classical debugger is nothing else but an interpreter with slightly changed semantics. > > The object flow VM does a great job at tracing back stuff.. however it might pose a massive overhead since it collects tons and tons of data. > > In Pinocchio[1] we implemented very nice and simple debuggers by "just" changing the current interpreter to take a user-action into account on each message send. Since this is implemented on top of a metacircular interpreter this was quite simple to achieve. So the whole implementation of the known debugger functionality (step, over...) maybe took an afternoon. Since you have access to the full interpreter protocol it is very easy to intercept different sorts of actions. As described in the linked paper, it was very easy to implement the object-flow behavior in Pinocchio. > > So for me there is only one real way to have a decent debugger. And that means that it is a first-class interpreter whose semantics I can change at will. Thus I can create a specific debugger for my applications. > > But I guess that making the first-class interpreters work right away in Pharo will take a while to do, hence I propose the following additions to the current interpreter to make it partly useable: > > - interception of message sends > Â Â Â Â - per thread [ok] > Â Â Â Â - of specific classes [missing] > Â Â Â Â - of specific instances [missing] > > - interception of instance variable access, read/write > Â Â Â Â - per thread [missing] > Â Â Â Â - of specific classes [missing] > Â Â Â Â - of specific instances [missing] > Â Â Â Â - of specific instance variables [missing] > > Furthermore I really want to be able to script all of that stuff, eg. provide a simple test block that gets invoked on each message send. Returning true => halt, Returning false => continue execution. > > > [1] http://scg.unibe.ch/archive/papers/Verw10aPinocchio.pdf > -- Jorge Ressia www.jorgeressia.com

April 26, 2011

[Pharo-project] [ANN] SqueakSource3 Beta.1 "Easter Fire"

by Tobias Pape

Dear Smalltalkers, gladly I would like to announce the first Beta of SqueakSource3 âEaster Fireâ. To try it, take your favorite Monticello-API and install the Metacello configuration. N.B.: The SqueakSource-Configuration has a dependency on Seaside3, however, if you happen to not have Seaside installed previously there will be no adaptor chosen for you. So, it is preferable to install Seaside3 with the settings you like before installing SqueakSource. "===" "GemStone. N.B.: You probably need an almostOutOfMemory-guard." Gofer project load: 'SqueakSource' version: #easterFire group: #( 'Full' ). "--" "Squeak" Installer squeaksource project: 'MetacelloRepository' install: 'ConfigurationOfSqueakSource'. ((Smalltalk globals at: #ConfigurationOfSqueakSource) project version: #easterFire) load. "--" "Pharo" Gofer new squeaksource: MetacelloRepository; package: 'ConfigurationOfSqueakSource'; load. ((Smalltalk at: #ConfigurationOfSqueakSource) project version: #easterFire) load. "===" SqueakSource3 is a port of SqueakSource to Seaside 3 and Magritte 2. It is based on the original SqueakSource by Lukas Renggli, Adrian Lienhard, and Avi Bryant; moreover recent changes to several SqueakSource-forks are incorporated, too. Some features like access to diffs in a browser as done by Bert Freudenberg for source.squeak.org have been integrated into SqueakSource3. SqueakSource3 incorporates a basic issue tracker done by Dale Henrichs. SqueakSource3 is expected to run on GemStone/GLASS as well as on squeakish Smalltalks, ie, Pharo and Squeak. âeaster fireâ has been tested on GemStone 2.4.4.x/GLASS 1.0-beta.8 and Squeak4.2 both with Seaside 3.0.4. Pharo-tests are pending. The agenda for SqueakSource3 in random order is: â¢ Have it running on GemStone, esp. GemStone 3 beta â¢ Provide a cleaner external API (may be REST or XMLRPC) â¢ Provide a more clear modularization and extension api (example: the Issue component by Dale Henrichs) â¢ Name itâ¦suggestions are welcome. â¢ Stability. Philippe Marschal, Dale Henrichs, and Gerhard Obermann have contributed much to SqueakSource3. All feedback is appreciated. So Long, -Tobias

April 26, 2011

Re: [Pharo-project] glamour chapter

by Mariano Martinez Peck

THanks Doru...BTW, do you plan to do a pdf/print of the book in the future? cheers Mariano On Tue, Apr 26, 2011 at 10:19 AM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi, > > For those interested, I updated the Glamour chapter on the Moose Book: > http://www.themoosebook.org/book/internals/glamour > > The examples are meant to work in the latest Moose development image, but > the engine is not tied to this image. Please let me know if there are still > issues you would like to see discussed. > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Relationships are of two kinds: those we choose and those that happen. > They both matter." > > > > > > > -- Mariano http://marianopeck.wordpress.com

April 26, 2011

[Pharo-project] glamour chapter

by Tudor Girba

Hi, For those interested, I updated the Glamour chapter on the Moose Book: http://www.themoosebook.org/book/internals/glamour The examples are meant to work in the latest Moose development image, but the engine is not tied to this image. Please let me know if there are still issues you would like to see discussed. Cheers, Doru -- www.tudorgirba.com "Relationships are of two kinds: those we choose and those that happen. They both matter."

April 26, 2011