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