- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Online Pharo Documentation

by Camillo Bruni

I am currentlz hacking together a fulltext search index using solr.. once that is running I consider the project to be more or less complete ;). and yeah, then I should get it up and running somewhere :) camillo On 2011-04-26, at 13:00, Bernat Romagosa wrote: > Just tried the demo image, very nice job! > > Maybe we could set up a running instance somewhere and link it from the Pharo website? > > Bernat. > 2011/4/22 laurent laffont <laurent.laffont(a)gmail.com> > That's really nice Camillo. Thank you. I hope to see it online soon ;) > > Laurent. > > On Fri, Apr 22, 2011 at 9:52 PM, Camillo Bruni <camillo.bruni(a)inria.fr> wrote: > Hi everyone, > > During the last month I worked a bit on my pharo web documentation tool. > It's a derivate of ruby's http://yardoc.org/ running on top of seaside. > > A test image is available here: > http://dl.dropbox.com/u/18184943/WebDoc.zip > Open the image then access the documentation in your browser > http://localhost:8080/doc > > There are still some glitches due to the javascript fancyness around. > > Features: > - browse and filter packages > - browse and filter classes of packages > - Class overview with markdown enabled comments > - fully annotated source code with popups for known types and selectors > > Missing: > - fully functional and slightly more intelligent search for methods, classes and packages > - hierarchical display of packages > - bookmarkable links don't work yet. > > Please feel free to add your own wishes, I hope to slowly improve this webdoc to make it really usable. > > v(^_^)v > camillo > >

April 26, 2011

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

by Toon Verwaest

I'm working on porting this idea already to the Glamour debugger. The idea is basically to use meta-circular interpreters as a way to specify what semantics you want, but for speed reasons you might want to flatten out the interpretation by combining both. This however should all be done behind the scenes, independent of the definition of the debugger. More elaborate debuggers such as the alias debugger can be implemented but there's no good way yet to separate the data spaces involved. That's where me and Erwann are looking at how to maybe use a GC that can run multiple different versions code at the same time while synchronizing the shared data between the versions of the code. For example in the case of the alias debugger, that needs aliases everwhere; but all the global data (classes, methods, ...) is not aliased. To make this work you actually want to have a "copy" of the global data that is aliased, but kept in sync with the original data. Here it starts making a lot of sense to have thread-local heaps + a versioned but synced global heap. Of course that's all still wishful thinking... step by step :) cheers, Toon On 04/25/2011 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] Why we have Behavior >> flushCache?

by Mariano Martinez Peck

On Tue, Apr 26, 2011 at 2:35 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > Not using the receiver is indeed misleading. I thought it simply flushes > the cache for a particular class > You are not alone :) That's why I am proposing the change. Of course, a nice comment could be enough (even if I muuuuch prefer to have it in elsewhere), but I think it may be a good moment to reify the VM and delegate a couple of things to it. > > Alexandre > > > On 26 Apr 2011, at 06:34, 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 > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- Mariano http://marianopeck.wordpress.com

April 26, 2011

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

by Mariano Martinez Peck

On Tue, Apr 26, 2011 at 12:51 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > what is the cache flushed? > what or when? What ? it flushed all the method lookup cache when? ok, for our refactoring the only thing that matters are the senders in the image. If you read the comment of the method it says "the method cache is flushed on every programming change and garbage collect" However, that seems not to be true. If I do a garbageCollect, Behavior>>flushCache is not sent (not even the primitive), And "every programming change" I don't know what it is. The senders I see in the image are: - Behavior >> superclass: aClass (it does a Object flushCache) - Time class >> benchmarkMillisecondClock (it does a Object flushCache.) - Time class >> benchmarkPrimitiveResponseDelay (it does a Object flushCache.) So, in fact, as much as I can see, all the senders of Behavior>>flushCache are sent to Object and not to a class in particular. Hence, it is one more probe that such method is independent of the receiver. 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 > > > > > -- Mariano http://marianopeck.wordpress.com

April 26, 2011

Re: [Pharo-project] Online Pharo Documentation

by Bernat Romagosa

Just tried the demo image, very nice job! Maybe we could set up a running instance somewhere and link it from the Pharo website? Bernat. 2011/4/22 laurent laffont <laurent.laffont(a)gmail.com> > That's really nice Camillo. Thank you. I hope to see it online soon ;) > > Laurent. > > On Fri, Apr 22, 2011 at 9:52 PM, Camillo Bruni <camillo.bruni(a)inria.fr>wrote: > >> Hi everyone, >> >> During the last month I worked a bit on my pharo web documentation tool. >> It's a derivate of ruby's http://yardoc.org/ running on top of seaside. >> >> A test image is available here: >> http://dl.dropbox.com/u/18184943/WebDoc.zip >> Open the image then access the documentation in your browser >> http://localhost:8080/doc >> >> There are still some glitches due to the javascript fancyness around. >> >> Features: >> - browse and filter packages >> - browse and filter classes of packages >> - Class overview with markdown enabled comments >> - fully annotated source code with popups for known types and >> selectors >> >> Missing: >> - fully functional and slightly more intelligent search for >> methods, classes and packages >> - hierarchical display of packages >> - bookmarkable links don't work yet. >> >> Please feel free to add your own wishes, I hope to slowly improve this >> webdoc to make it really usable. >> >> v(^_^)v >> camillo >> > >

April 26, 2011

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

by StÃ©phane Ducasse

>> >> >>> 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 :). yes but this is a different thing that load or loadDefault. It requires extra energy. >>> >> Looks like I control RPackage now. > > I am happy you are in control. Me too. I will work a lot on it from thursday. first address some of the flag: I did second understand what cyrille did for the integration with MC write more tests and see where we get. may be implement what we discussed. Stef

April 26, 2011

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