Moose-dev November 2011

moose-dev@list.inf.unibe.ch

25 participants
191 discussions

by Stéphane Ducasse

Hi doru Did you get a chance to discuss with dale about the "problem" in metacello that forces us not to be able to load previous version of Moose? Do we have to run endlessly forward without any chance to control that? Is it just that we should use the metacello tool box api? Stef

13 years, 1 month

Re: Issue 741 in moose-technology: MooseGroupRuntimeStorage>>at:ifAbsent: should have a better code and comment

by moose-technology＠googlecode.com

Updates: Summary: MooseGroupRuntimeStorage>>at:ifAbsent: should have a better code and comment Labels: Component-MooseCore Milestone-4.6 Comment #1 on issue 741 by tudor.gi...(a)gmail.com: MooseGroupRuntimeStorage>>at:ifAbsent: should have a better code and comment http://code.google.com/p/moose-technology/issues/detail?id=741 I integrated this.

13 years, 1 month

Issue 741 in moose-technology: better code and comment

by moose-technology＠googlecode.com

Status: Fixed Owner: ---- Labels: Type-Defect Priority-Medium New issue 741 by stephane...(a)gmail.com: better code and comment http://code.google.com/p/moose-technology/issues/detail?id=741 MooseGroupRuntimeStorage>>at: uniqueName ifAbsent: exceptionBlock | entity na | na := uniqueName asSymbol. "look first by name and if not found" entity := byName at: na ifAbsent: [nil]. entity notNil ifTrue: [^entity]. "iterates over all the elements" entity := self detect: [:each | na == each mooseName asSymbol] ifNone: exceptionBlock. entity notNil ifTrue: [byName at: na put: entity]. ^entity

13 years, 1 month

MooseGroupRuntimeStorage

by Usman Bhatti

We have Collection variableSubclass: #MooseGroupStorage instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Moose-Core' MooseGroupStorage variableSubclass: #MooseGroupRuntimeStorage instanceVariableNames: 'byName elements byType' classVariableNames: '' poolDictionaries: '' category: 'Moose-Core' at: uniqueName ifAbsent: exceptionBlock | entity na | na := uniqueName asSymbol. "look first by name and if not found" entity := byName at: na ifAbsent: [nil]. entity notNil ifTrue: [^entity]. "iterates over all the elements" entity := self detect: [:each | na == each mooseName asSymbol] ifNone: exceptionBlock. entity notNil ifTrue: [byName at: na put: entity]. ^entity Now I could not find where the byName dictionary is set. Does anybody know? Stef

13 years, 1 month

Headless PetitParser

by Alberto Bacchelli

Hi all, I have a small parser written in PetitParser ;) I would like to call it from a non smalltalk application (e.g., Java, javascript) or, more generally, from a Unix command line. Something like: ./myParser -i fileToParse.txt -o outputFile.txt Is there any possibility to do that? Can a headless Pharo be a solution? If so, how can I start and use a headless Pharo? Is there any useful documentation/email about it? Thank you a lot for any help. Cheers, Alberto

13 years, 1 month

OverviewPyramid smalltalk thresholds?

by Ciprian Teodorov

Hi all, I'm new to using moose for analyzing a rather large smalltalk project developed during the last 16-17 years. I hope that using Moose framework will give positive insights on the hot-spots of the system in order to improve its structure, and make it more maintainable. The project name is Madeo (http://stiff.univ-brest.fr/BINIOU/MADEO) a FPGA design-automation toolkit developed mainly by one of my PhD supervisors (Loic Lagadec <http://stiff.univ-brest.fr/~llagadec>). To start the evaluation I believe that the overview pyramid is a very good starting point in order to get a generic idea about the system. However, I was not able to find any smalltalk threshold values in the moose image. So my question is if there is somebody having some idea about the smalltalk threshold values for the OverviewPyramid. If yes, could you provide me these figures, and eventually point me to a scientific paper presenting these results. If not, I'm willing to try to get these figures myself... however I don't really know which smalltalk projects I could use to get good results. Thank you very much for your attention. Best wishes, -- PhDc Ciprian TEODOROV Lab-STICC/AS CNRS UMR 3192 University of Brest phone: (+33)(0) 6 08 54 73 48 mail: ciprian.teodorov(a)univ-brest.fr www.teodorov.ro

13 years, 1 month

Problem in EyeSee with the Matrixes

by Alexandre Bergel

Hi! I played with the matrix in EyeSee in a Pharo image. I found some problems: - #new:withAll: and #new: seems to raise an emergency debugger, whatever the value we provide - Many references are made that do not belong to EyeSee. For example #zero that refers to MalMatrixCoercion I also found other problems (e.g., hash). I added some tests for those. I produced version 0.9.2 Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

13 years, 1 month

connecting a smalltalk class and a FamixClass

by Usman Bhatti

hello all, I am trying to create a distribution map for a moose model representing Citezen. Now, for each class, I am trying to color it according to its authors information. The following script should work for me: |model packages| model := (MooseModel root allModels) first. packages := model allPackages. (DistributionMap onContainers: packages elements: (model allModelClasses) properties: [:cl | cl authors > 10] ) render open. However, the method "authors" that I am invoking on cl (a FamixClass) is not defined by FamixClass but it is described by ClassDescription. Is there anyway to connect a FamixClass to its corresponding Smalltalk class? I am thinking of getting the name of the FamixClass and somehow ask pharo to give me its corresponding Smalltalk class? Any ideas if that should work? thanx in advance, Usman

13 years, 1 month

Issue 733 in moose-technology: VerveineJ does not export modifiers

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: anquetil...(a)gmail.com Labels: Type-Defect Priority-Medium Component-VerveineJ New issue 733 by tu...(a)tudorgirba.com: VerveineJ does not export modifiers http://code.google.com/p/moose-technology/issues/detail?id=733 public abstract class A { ... } should appear as ( (FAMIX.Class (name 'A') (modifiers 'public' 'abstract') ) Similar things should happen to methods and attributes.

13 years, 1 month

to extend, or not to extend?

by Tudor Girba

Hi, Class extensions is at the core of the design of Moose. For example, for a class we have as extensions: - numberOfMethods - isJUnit4TestCase - viewBlueprint and viewBlueprintOn: Now, the question is, when to extend an existing class and when not, given that it might lead to a very large amount of methods. To answer this, let's start from the reason for having the extensions in the first place. We want extensions to unify the scripting and the user interface world. For example: - if we are in a MooseFinder, we can see numberOfMethods in the properties pane, because it is meta-described, and we can use it easily in scripting (each numberOfMethods > 10). - The isJUnit4TestCase is not meta-described, but it's meant to be used as a query facility. - viewBlueprint appears in the menu and it is also meant to be used from the inspector. - viewBlueprintOn: this is particularly useful when it is used inside other Mondrian or Glamour scripts So, all in all, you extend when you have: - a meta-described property - a query method (the best kind are unary ones) - a menu entry - a compose-able script Now, when not to extend? Basically, when you do not fall in the above categories :). Here are some examples: - FAMIXClass>>viewMethods: aCollection inBlueprintLayerNamed: aString on: view I can safely provide this as an example, because created it. This is a method that basically only makes sense in the context of the class blueprint. So, it should be bundled together in a separate helper class. - FAMIXPackage>>configurationOfECell This is basically just a helper method that only makes sense in the context of DSM, so it should better be placed there. Cheers, Doru -- www.tudorgirba.com "Next time you see your life passing by, say 'hi' and get to know her."

13 years, 1 month

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev November 2011