about loading previous versions
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
12 years
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
12 years
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
12 years
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
12 years
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
12 years
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
12 years
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
12 years
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."
12 years
