Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

by Tudor Girba

Hi, This is the default way to load the latest version: Gofer new squeaksource: 'Glamour'; package: 'ConfigurationOfGlamourSeaside'; load. (Smalltalk at: #ConfigurationOfGlamourSeaside) loadDefault. Cheers, Doru On 27 Apr 2011, at 10:17, Tobias Pape wrote: > > Am 2011-04-27 um 09:33 schrieb Tudor Girba: > >>> […] >>> Is it usable in Squeak4.2? >> >> I never tried but you are welcome to. If you do, please let us know what happened :) >> >> Cheers, >> Doru >> > > Can you give me some starting points? > > So Long, > -Tobias > -- www.tudorgirba.com "It's not how it is, it is how we see it."

14 years

DropListPartTest>>testSelectedIndex

by Tudor Girba

Hi Cyrille, The DropListPartTest>>testSelectedIndex test is failing due to the initialization in DropListPart>>selectionIndex. The test assumes that the selection index is 1, but I saw that you recently changed it in the initialization to be 0. So, I do not know if the error is in the test or in the initialization :). Could you please take a look? Cheers, Doru -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding."

14 years

Issue 599 in moose-technology: Color highlight for methods not necessary

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 599 by alexandr...(a)gmail.com: Color highlight for methods not necessary http://code.google.com/p/moose-technology/issues/detail?id=599 Just move the mouse above a methods and you will see the problem. Thanks Laurent & Patrick

14 years

DocumentationBlueprint

by Alexandre Bergel

The visualization is titled Documentation blueprint. Big box = class; edge = inheritance link; small box = method; small box height = number of lines of code; small box width = number of collaborating classes; red border = non commented; green border = test http://bergel.eu/DocumentationBlueprint-Mondrian.png This visualization is obtained from Mondrian. Yeah, Mondrian is pretty poorly documented. I will work on it. Feedback wanted Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years

removing versions from configurations

by Tudor Girba

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."

14 years

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

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years

Issue 598 in moose-technology: FAMIXType>>>> aSymbol

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 598 by alexandr...(a)gmail.com: FAMIXType>>>> aSymbol http://code.google.com/p/moose-technology/issues/detail?id=598 Good idea. Please add FAMIXType>>>> :) Cheers, Doru On 25 Apr 2011, at 02:16, Alexandre Bergel wrote: Hi! What about adding a method named #>> in FAMIXType to access methods? Or something like #methodNamed: Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Some battles are better lost than fought." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

14 years

potentialReferencingClasses, invokedClasses, clientClasses

by Alexandre Bergel

Hi! There is the method: FAMIXPackage>>potentialReferencingClasses "returns a set of all the classes that potentially refer to the receiver: they potentially refer to some classes that are defined or extended into the receiver" I do not understand what this means. How a class can be "potentially referenced"? How does it differ from #invokedClasses ? There is no class comments for #invokedClasses. I feel this is necessary. I can add some if someone tells me that this method does. By the way FAMIXMethod>>invokedClasses and FAMIXClass>>invokedClasses have a pragma <navigation: 'Invoked classes'> But not FAMIXNamespace and FAMIXPackage? Same things for FAMIXPackage>>clientClasses and FAMIXNamespace>>clientClasses. Shall we add a <navigation: 'Client classes'> as in FAMIXClass>>clientClasses Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years

Accessing methods

by Alexandre Bergel

Hi! What about adding a method named #>> in FAMIXType to access methods? Or something like #methodNamed: Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years

Issue 589 in moose-technology: Glamour: MessageNotUnderstood: receiver of "senders" is nil

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 589 by damien.c...(a)gmail.com: Glamour: MessageNotUnderstood: receiver of "senders" is nil http://code.google.com/p/moose-technology/issues/detail?id=589 While trying to improve the glamoroust smalltalk code browser, I always got the attached backtrace. The strange thing is that no glamour browser is opened at the time when the debugger arrises. It arrises when I save a method from the standard code browser. Attachments: PharoDebug.log 40.8 KB

14 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev