Moose-dev August 2011

moose-dev@list.inf.unibe.ch

26 participants
113 discussions

Issue 681 in moose-technology: SubclassResponsibility: a JPEGReadWriter had the subclass responsibility to implement #nextPutImage:
by moose-technology＠googlecode.com 08 Sep '11

08 Sep '11

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 681 by vonbecm...(a)gmail.com: SubclassResponsibility: a JPEGReadWriter had the subclass responsibility to implement #nextPutImage: http://code.google.com/p/moose-technology/issues/detail?id=681 SubclassResponsibility: a JPEGReadWriter had the subclass responsibility to implement #nextPutImage: Pharo image: Pharo1.3a#13258 Virtual machine used: Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.51] Platform Name: unix Class browser used (if applicable): OBSystemBrowserAdaptor Steps to reproduce: #. select a model. #. select all model namespaces #. press left button, select visualize>>dependencies(cycles) you will see the mondrian renderer #. export to jpeg #. enter a filename #. press Ok Actual Result: SubclassResponsibility: a JPEGReadWriter had the subclass responsibility to implement #nextPutImage: Expected Result: a filename.jpeg with the graph * Type-Defect * Component-Mondrian Renderer Attachments: PharoDebug.log 28.6 KB PharoScreenshot.1.png 69.6 KB

1 3

Re: Issue 106 in moose-technology: Disable the default Smalltalk shortcuts from the Text Morphic widget in Glamour
by moose-technology＠googlecode.com 05 Sep '11

05 Sep '11

Updates: Labels: -Milestone-4.2 Milestone-4.4 Comment #5 on issue 106 by tudor.gi...(a)gmail.com: Disable the default Smalltalk shortcuts from the Text Morphic widget in Glamour http://code.google.com/p/moose-technology/issues/detail?id=106 (No comment was entered for this change.)

1 3

Issue 655 in moose-technology: export a moose model raise an error
by moose-technology＠googlecode.com 05 Sep '11

05 Sep '11

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 655 by cy.delau...(a)gmail.com: export a moose model raise an error http://code.google.com/p/moose-technology/issues/detail?id=655 Try to import a smalltalk model in moose. Right click on the model and 'export to mse' . at the end of the export you will get: MessageNotUnderstood: receiver of "sender" is nil I think it is related this issue : http://code.google.com/p/moose-technology/issues/detail?id=635 At the end of the export there is a notification signaling that the export succeed. The new way announcements are dealing now with exception signals lead to those kind of behavior

1 6

Issue 694 in moose-technology: Should be able to 'do it' in text presentations
by moose-technology＠googlecode.com 05 Sep '11

05 Sep '11

Status: Started Owner: damien.c...(a)gmail.com CC: tudor.gi...(a)gmail.com Labels: Type-Defect Priority-Medium Component-Glamour New issue 694 by damien.c...(a)gmail.com: Should be able to 'do it' in text presentations http://code.google.com/p/moose-technology/issues/detail?id=694 In Glamour, it is not possible to select a piece of text and "do it". Steps to reproduce: 1- GLMBasicExamples open 2- Select one example 3- Select 'Source code' 4- Type 'self' somewhere and print it It should print 'GLMBasicExamples' and not 'nil' as it currently does.

1 5

[ANN] glamorous inspector
by Tudor Girba 31 Aug '11

31 Aug '11

Hi, I am happy to announce the first release of the Glamorous Inspector, a new browser for inspecting objects based on Glamour. More information, including a demo and screenshots, can be found here: http://www.humane-assessment.com/blog/glamorous-inspector-for-smalltalk To download it follow the instructions from: http://www.moosetechnology.org/tools/glamoroustoolkit You can use it by: 1. "GTInspector openOn: someObject", or 2. "GTInspector registerToolsOn: Smalltalk tools" and then use CMD+I (explore) Please let your opinion be heard :) Cheers, Doru p.s. Have fun at ESUG :) -- www.tudorgirba.com "Every successful trip needs a suitable vehicle."

3 6

major repackaging planned
by Tudor Girba 30 Aug '11

30 Aug '11

Hi, For the next major version of Moose, we need to rethink the packaging of Moose. To rethink this, we first need to have a common understanding of the structure of Moose. For this, please read the short description of Moose from here: http://www.themoosebook.org/book/introduction/nutshell In particular, I want to start distinguishing clearly between several types of components: . Importers: -- These have the responsibility of importing data into models -- Examples: SmalltalkImporter, MSE . Analyses -- they do something specific with data -- Examples: metrics, system complexity, dependency browser ... . Meta-Models: -- they define the structure of data -- Examples: FAMIX, Hismo, ... . Engines -- they are meta-tools with which we control the analysis flow -- Examples: Moose-Core, PetitParser, Fame, Mondrian, Glamour, Magritte Then of course, there will be various kinds of flavors. For example: MooseFinder is both an engine (because it is generic and can be contextualized in several ways) and an analysis (because it is built on top of an engine). After we settle on a larger picture, I want to have clearly named configurations for each subpart. Then it will be clearer where people should put the extensions (because currently we all define the extensions in the same package) Cheers, Doru -- www.tudorgirba.com "Be rather willing to give than demanding to get."

5 20

Re: [Pharo-project] Bug or feature? XMLElement>>allElementsDo:
by Tudor Girba 30 Aug '11

30 Aug '11

Indeed, it should be named withAllElementsDo: to be consistent with Smalltalk naming, and then it would exactly what the name says :) Doru On 30 Aug 2011, at 07:51, Max Leske wrote: > … and maybe it should be renamed to #withAllElementsDo: ? > > > On 30.08.2011, at 00:01, Levente Uzonyi wrote: > >> On Mon, 29 Aug 2011, Nicolas Anquetil wrote: >> >>> In XML-Parser-Nodes we have: >>> >>> XMLNodeWithElements >>> XMLDocument >>> XMLElement >>> >>> A document is composed of elements that can hold recursively other elements >>> >>> XMLNodeWithElements implements (in protocol enumerating) >>> allElementsDo: aBlock >>> "Descend depth-first visiting each element with aBlock." >>> >>> self hasElements >>> ifTrue: [self elementsDo: [:each | each allElementsDo: aBlock]] >>> >>> Looks perfectly normal to me >>> But then: >>> >>> XMLElement implements (in protocol searching !) >>> allElementsDo: aBlock >>> "See superclass version." >>> >>> aBlock value: self. >>> >>> super allElementsDo: aBlock. >>> >>> which means that >>> anXMLElement allElementsDo: [...] >>> runs first on itself and then on its elements ?!? >>> Seems counter intuitive to me. >>> >>> Should I remove this? >> >> IMHO you shouldn't, because it is enumerating the whole tree, which is exactly what I'd expect from this method. But the method should be recategorized. >> >> >> Levente >> >>> >>> nicolas >>> >>> >> > > -- www.tudorgirba.com "Live like you mean it."

1 0

Bug or feature? XMLElement>>allElementsDo:
by Nicolas Anquetil 29 Aug '11

29 Aug '11

In XML-Parser-Nodes we have: XMLNodeWithElements XMLDocument XMLElement A document is composed of elements that can hold recursively other elements XMLNodeWithElements implements (in protocol enumerating) allElementsDo: aBlock "Descend depth-first visiting each element with aBlock." self hasElements ifTrue: [self elementsDo: [:each | each allElementsDo: aBlock]] Looks perfectly normal to me But then: XMLElement implements (in protocol searching !) allElementsDo: aBlock "See superclass version." aBlock value: self. super allElementsDo: aBlock. which means that anXMLElement allElementsDo: [...] runs first on itself and then on its elements ?!? Seems counter intuitive to me. Should I remove this? nicolas nicolas

2 1

Fan out.metric computation
by pascal.vollmer＠nexgo.de 28 Aug '11

28 Aug '11

Hi, I try to use Moose to get the fan out-metric computed for a small Smalltalk project. In order to have type inference I checked "Compute type of attributes (using Roel Typer)" when importing my project. Unfortunately I do not understand what "Select a strategy to compute invocation candidates" says. I left this as it is set by default ("Use the standard CandidateListOperation"). The same is true for "Choose an importer". Now, I look at a certain class C which is interesting for me. "InvokedClasses in C" shows several classes to which C does not send a message. What can I do about that? 1) Is there a possibility to "help" Roel Typer manually when automatic type inference is not feasible? 2) What about the approach of Alexandre Bergel shown at ESUG 2011. Can I try it? Kind regards, Pascal Pascal Vollmer Email: pascal.vollmer(a)ieee.org Arcor empfiehlt: Mal über die Karriere nachdenken! Wissenswertes und Nützliches finden Sie hierzu unter http://www.arcor.de/content/finanzen_job/job_karriere/bewerbung_karriere/ra…

2 1

A quick primer on Moose Hapax basics (Moose-Algos-InformationRetrieval)
by Simon Denier 27 Aug '11

27 Aug '11

Hi all Since I'm in the process of discovering/evaluating the Moose tools in Moose-Algos-InformationRetrieval, I thought it would be a good idea to put together a small tutorial about what can be done and how to use it. http://www.moosetechnology.org/tools/moosealgos/vocabulary These tools are built primarily for vocabulary analysis of any document and corpus of documents. There are basic yet allow one to extract interesting information. Of course comments are welcomed. Notice that this does not contain the full Hapax tool suite. The port of Hapax to Pharo is here http://www.squeaksource.com/Hapax.html but development is halted and will not continue unless a specific need arises (first things first, tests need to be written) -- Simon Denier

4 3

← Newer
1
...
5
6
7
8
9
10
11
12
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev August 2011