Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

by Tudor Girba

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

13 years, 8 months

major repackaging planned

by Tudor Girba

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

13 years, 8 months

Re: [Pharo-project] Bug or feature? XMLElement>>allElementsDo:

by Tudor Girba

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

13 years, 8 months

Bug or feature? XMLElement>>allElementsDo:

by Nicolas Anquetil

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

13 years, 8 months

Fan out.metric computation

by pascal.vollmer＠nexgo.de

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…

13 years, 8 months

A quick primer on Moose Hapax basics (Moose-Algos-InformationRetrieval)

by Simon Denier

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

13 years, 8 months

Re: Sparse Matrix in Moose/Pharo

by Alberto Bacchelli

I am trying the one in Hapax (e.g., SparseRowMatrix) but it doesn't look so sparse to me… Maybe I am doing something wrong. In any case, at least the data structure for the Yale format shouldn't be too hard to write. I'll keep you posted about it. On Aug 25, 2011, at 11:29 AM, Tudor Girba wrote: > I am not aware of it, but it would be a great addition. We had one in VW, but I think you know that one already. > > Doru > > > On 25 Aug 2011, at 11:20, Alberto Bacchelli wrote: > >> Hi all, >> >> Is there any library for _seriously_ handling/storing sparse matrices >> in Pharo/Moose? >> >> >> I was thinking about something like >> http://en.wikipedia.org/wiki/Sparse_matrix#Yale_format >> >> Thanks. >> >> Alberto >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Every thing should have the right to be different." > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

13 years, 8 months

Problems with checkout of Py2mse

by Nelli Kaiser

Hi everyone, I am a newbie here and for one of my projects I need Py2mse. I found the intruction how to checkout this parser ( http://www.moosetechnology.org/tools/retired/py2mse) but I did not make it. Can anyone please tell me exactly how I can download it - I mean: which lines should I enter in my subversion client? Your assistance would be greatly appreciated!! Thanks, Nelli

13 years, 8 months

Issue 697 in moose-technology: FAMIX should provide TypeAlias for modeling typedef in C

by moose-technology＠googlecode.com

Status: New Owner: tudor.gi...(a)gmail.com Labels: Type-Defect Priority-Medium Component-Famix Milestone-4.6 New issue 697 by tudor.gi...(a)gmail.com: FAMIX should provide TypeAlias for modeling typedef in C http://code.google.com/p/moose-technology/issues/detail?id=697 I C we can provide another name for an existing type: typedef struct var newtype; Essentially, this acts like a type alias. This should be captured by FAMIX-C.

13 years, 8 months

Sparse Matrix in Moose/Pharo

by Alberto Bacchelli

Hi all, Is there any library for _seriously_ handling/storing sparse matrices in Pharo/Moose? I was thinking about something like http://en.wikipedia.org/wiki/Sparse_matrix#Yale_format Thanks. Alberto

13 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev