- Pharo-dev - lists.pharo.org

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

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

by Tudor Girba

Hi Stef, On 26 Apr 2011, at 09:42, StÃ©phane Ducasse wrote: > > On Apr 25, 2011, at 7:37 PM, Tudor Girba wrote: > >> Hi Stef, >> >> On 25 Apr 2011, at 18:50, StÃ©phane Ducasse wrote: >> >>> Indeed but loading default could have destroyed your image. >>> So RPackage should not be managed with default. >> >> I do not understand. The continuous integration server is there to check these issues. > > the proof is that it did not work. > >> The correspondent would be to load now the current baseline. If that breaks, it breaks and people look at it. >> >> Moose is now developed on multiple fronts and serves multiple interests that are not necessarily synchronized. So, we want to depend on latest things because this ensures communication and puts more pressure on synchronizing issues. This is why we want to play with the latest Pharo (hopefully, we will the development to it next week). >> >> Every time we depend on something fixed, we introduce the difficulty of migrating to the next version. > > 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. Although I am sure that when you are developing RPackage, you do want to load the very latest versions of packages :) >>> Now for stable I'm not sure that I set it up well so watch out. >> >> The tests say that for the use of Moose, RPackage works Ok. > > The problem is that the scenario of Moose is just to create Moose model and RPackage is much more than that. > We found conceptual problem with announcement dependencies with benjamin and fix that. > Then for example, Rpackage was not in sync with > - the announcement changes because it was violating encapsulation (law of demeter bad practice) > In addition there are multiple things that now I have to carefully check. Because MC is not nice and we are replicating > this aspects and making rpackage brittle because MC is brittle. I understood that. I was just saying that for Moose it looks like it is working. However, we do not test to see what happens if something is loaded in the image after RPackage was installed, so this is why we are probably missing the issue :(. > 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. If you want to work with a specific version, work with a specific version. Default is nothing but a baseline. You did not remove the other baseline, but you removed 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. Cheers, Doru > > Stef > > >> >> Cheers, >> Doru >> >> >> >>> Stef >>> >>> On Apr 25, 2011, at 12:51 PM, Tudor Girba wrote: >>> >>>> Hi, >>>> >>>> The Moose build broke because the 'default' version was removed from ConfigurationOfRPackage. >>>> >>>> I fixed it now by using #stable, but that is not the issue. >>>> >>>> I understand the need for cleaning, but we should be aware that removing versions from configurations can have far reaching ripple effects. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "From an abstract enough point of view, any two things are similar." >>>> >>> >>> >> >> -- >> www.tudorgirba.com >> >> "Don't give to get. Just give." >> >> >> >> >> >> > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "It's not how it is, it is how we see it."

April 26, 2011

Re: [Pharo-project] Suggestions: move examples from UIThemes class to ExampleBuilderMorph class

by StÃ©phane Ducasse

edmund enter bug entries else your suggestions will be lost. Stef On Apr 25, 2011, at 8:56 PM, DougEdmunds wrote: > A couple of suggestions > > Part 1. > Move the methods in the UIThemes class, protocol 'examples' to > ExampleBuilderMorph class, protocol 'examples'. > > Rationale: Every one of these examples first creates an instance of > ExampleBuilderMorph > as the base class that the example is built on. These examples do not > demonstrate > anything about how to use UITheme. > > I made a file that duplicates the methods from UITheme class -examples- to > ExampleBuilderMorph class -examples-, suitable for filein. Methods such as > ExampleBuilderMorph class >>exampleBasicControls work fine, > indicating they have no dependence on UITheme. > The file's 347 lines, so I'm not posting it here, unless requested. > > Part 2. > Then move ExampleBuilderMorph and ExampleRadioButtonModel from > Polymorph-Widgets > into a new package called Polymorph-Widgets-Examples. > > Rationale: This would be reduce the size of Polymorph-Widgets, and make it > more > obvious that there are some examples of the widgets to look at. > UITheme class is not the place where one expects to find examples of > buttons, > checkboxes, etc. Also this would be consistent with other Morphic packages. > (Morphic-MorphTreeWidget and Morphic-MorphTreeWidget-Examples) > > --- > > > > > > -- > View this message in context: http://forum.world.st/Suggestions-move-examples-from-UIThemes-class-to-Exam… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

April 26, 2011

Re: [Pharo-project] removing versions from configurations

by StÃ©phane Ducasse

On Apr 25, 2011, at 7:37 PM, Tudor Girba wrote: > Hi Stef, > > On 25 Apr 2011, at 18:50, StÃ©phane Ducasse wrote: > >> Indeed but loading default could have destroyed your image. >> So RPackage should not be managed with default. > > I do not understand. The continuous integration server is there to check these issues. the proof is that it did not work. > The correspondent would be to load now the current baseline. If that breaks, it breaks and people look at it. > > Moose is now developed on multiple fronts and serves multiple interests that are not necessarily synchronized. So, we want to depend on latest things because this ensures communication and puts more pressure on synchronizing issues. This is why we want to play with the latest Pharo (hopefully, we will the development to it next week). > > Every time we depend on something fixed, we introduce the difficulty of migrating to the next version. 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. >> Now for stable I'm not sure that I set it up well so watch out. > > The tests say that for the use of Moose, RPackage works Ok. The problem is that the scenario of Moose is just to create Moose model and RPackage is much more than that. We found conceptual problem with announcement dependencies with benjamin and fix that. Then for example, Rpackage was not in sync with - the announcement changes because it was violating encapsulation (law of demeter bad practice) In addition there are multiple things that now I have to carefully check. Because MC is not nice and we are replicating this aspects and making rpackage brittle because MC is brittle. 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). Stef > > Cheers, > Doru > > > >> Stef >> >> On Apr 25, 2011, at 12:51 PM, Tudor Girba wrote: >> >>> Hi, >>> >>> The Moose build broke because the 'default' version was removed from ConfigurationOfRPackage. >>> >>> I fixed it now by using #stable, but that is not the issue. >>> >>> I understand the need for cleaning, but we should be aware that removing versions from configurations can have far reaching ripple effects. >>> >>> Cheers, >>> Doru >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "From an abstract enough point of view, any two things are similar." >>> >> >> > > -- > www.tudorgirba.com > > "Don't give to get. Just give." > > > > > >

April 26, 2011

Re: [Pharo-project] Fix proposed to make alt+t open a transcript in PharoCore 1.3

by Marcus Denker

On Apr 25, 2011, at 3:55 PM, Damien Cassou wrote: > http://code.google.com/p/pharo/issues/detail?id=4093 > We should role back to the old transcript... all of the many problems with transcript will then be fixed. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 26, 2011