I believe I already said here that I don't like very much the "default"
FAMIX metamodel in Moose because it is the union of Smalltalk and Java
specificities.
For 2 languages it works (more or less), but if we want to add C#, C++,
and whatever-else (not talking about non OO languages), it quickly
starts to be a huge mess.
It would be preferable to have a generic metamodel and specific ones for
each languages.
But then, we will run into cases where we want to have some kind of
multiple inheritance.
For example we could want to say that a Java method and a C function are
behaviouralEntities with return type and Java methods and Smalltalk
methods are behavioural entities with a received (when they are called)
and Java method now have two superclasses.
So the question arise why Fame does not have multiple inheritance?
- no specific reason?
- fundamental design decision?
- historical reason?
nicolas
--
Nicolas Anquetil -- RMod research team (Inria)
Hello,
I used stef's reloader to determine the packages loaded in the latest 4.7
build from squeaksource and I compared it to the flatVersion47:
(corresponding to release 4.7, generated in dec 2012) in
configurationOfMoose. There are some packages that are updated in latest
moose 4.7 but there are old versions of these packages in flatVersion47:.
For example, the version number of FAMIX-Core in flatversion47 is 209 but
in the latest 4.7 build, it was 211. I am creating a new script6 that loads
the latest stable version of Moose on 1.4, it is important because there
are some updates from Roassal and Eyesee that we need. So, it would be good
that flatVersion47 points to script6.
Here is a list of packages whose version number changed.
Package: flatVersion47 version number -> latest-dev version number
OSProcess: 73-> 78
Famix-Core: 209-> 211
Famix-File: 38-> 39
Famix-Java: 70-> 71
Famix-Extensions: 244-> 246
PetitAnalyzer: 39-> 40
Glamour-Examples: 252-> 253
Glamour-Morphic-Renderer: 179-> 183
PetitGui: 114-> 116
ConfigurationOfRoassal: 752-> 866
Mondrian-Easel: 42-> 43
ConfigurationOfFuel: 157-> 181
Fuel: 685-> 686
FuelCompatibilityBeforePharo20: 20-> 20
Roassal: 404-> 475
RoassalMorphic: 94-> 111
EyeSee-Tests-Core: 66-> 67
EyeSee-Core: 99-> 100
Moose-Finder: 426-> 427
Moose-MondrianPaintings: 172-> 176
ConfigurationOfMoose: 275-> 278
Usman
Hi,
the metric numberOfLinesOfCode it doesn't work on an imported moose
smalltalk model because it looks for the compiled method version to
calculate the actual lines of code. I think we should seriously rethink the
entire smalltalk importing and handling phase because it is not possible
that only pharo can be imported and analyze: In all the places where a
"isSmalltalk" method is invoked, if that means that you are going to look
for smalltalk code in the image, we should change it with a method called
"isSmalltalkCodeLoaded". This method can be set since the import phase.
What do you think?
Cheers,
Fabrizio
PS: I hope I can make the code I wrote to import Smalltalk available ASAP,
that could be use as a start to create a image code independent
parser/importer :)
Hi,
During April 2-4 we will organize a PharoConf and a MooseDay in Bern, Switzerland. Mark the day and join us. The participation will be free of charge.
The conference will focus on interactivity and exchange, and will feature experience report talks, tutorials, show-us-your-project sessions and open discussions.
We are looking for speakers:
TUTORIAL
These sessions will walk the audience through a piece of technology.
Target duration: 30min - 60min.
Example topics:
- ZeroConf continuous integration builds
- Building vectorial interfaces with Athens
- Building UIs with Spec
- New development tools (Fuel/Tanker, Glamorous Debugger, Nautilus ...)
- Manipulating databases in Pharo (Riak, MongoDB ...)
- Visualizing data (Roassal, EyeSee ...)
TALK
These sessions expose a topic that is not necessarily technical.
Target duration: 30min - 60min.
Example topics:
- Experience of using Pharo to solve business problems
- Experience of using Pharo and Moose to solve various technical problems (not necessarily related to Smalltalk)
- Successes in marketing Pharo-based solutions
- Future directions for Pharo or Moose
SHOW-US-YOUR-PROJECT
These sessions will feature short presentations of the projects (7-10 minutes) followed by open-space demos.
Example topics:
- The Glamorous Debugger
- Nautilus
- Analysis tools like Softwarenaut or Carrack
- Fuel/Tanker
- ...
Please send us your submissions by email at tudor(a)tudorgirba.com.
Cheers,
Doru on behalf of the organizers
--
www.tudorgirba.com
"To lead is not to demand things, it is to make them happen."
Hi everyone. If you remember I'm developing an AST extension for FAMIX and
right now I've started to work on Java part. One of the features I have to
support is generation of method's AST from the source code on demand.
I've found that there is a petit parser implementation for Java and I wander
what is it's status and is it wise to spend time on it. Because having a
parser in smalltalk is really nice compared to passing a method source text
to some external script, reading result from generated file, etc.
uko
--
View this message in context: http://moose-dev.97923.n3.nabble.com/PetitJava-status-tp4026356.html
Sent from the moose-dev mailing list archive at Nabble.com.
Hi,
I have noticed that both FAMIXClass and FAMIXMethod sourceText methods
starts with:
self mooseModel isSmalltalk
I think this is wrong. It should always be:
self sourceLanguage isSmalltalk
This way if a FAMIX element has a language which is default language for
the model you can capture that.
Do you agree?
Cheers,
Fabrizio
Hi,
I would like to create a Moose model of a VisualAge smalltalk
application. I tried to fileout a bunch of applications (which are
groups of packages as far as I understood) and the result file .app
has naturally a different syntax from pharo st files. Now, the
questions are:
- Should I customize the PPSmalltalkParser or should I start a parser
from scratch?
- Did anybody tried to import in moose a smalltalk dilect different
from pharo? If yes how did he do that?
I just want to understand if I can save time or I should build a whole
parser and importer from scratch.
Thanks for any suggestion or information.
Cheers,
Fabriyio (bloodz german kezboard)
Hi,
I fixed a couple of tests in PetitParser (they were using the obsolete includesSubString:) and they are now all green in Pharo 2.0.
However, some of the PetitSmalltalk-Tests are still red:
- There was an issue with a commit from Lukas that went to the old repository and was only partly in the new one (probably due to the confusion around the move to the new repository). I merged the changes.
- Still some tests fail, but I did not have a chance to figure it out as to why this happens.
Cheers,
Doru
--
www.tudorgirba.com
"Value is always contextual."
Some methods in Moose introduce extension methods on BlockContext.
BlockContext has been replaced by BlockClosure. We already have the
required moose extension methods in BlockClosure, so I'll remove extension
methods on BlockContext so that we do not have warnings while loading Moose
on pharo 2.0.
For info, the ist of extension categories added by Moose packages on
BlockContext:
- eyesee-support
- moose-core
- petitparser-core-converting
Hi,
I fixed a couple of issues for Pharo 2.0.
There are still a couple of things left:
- There is error due to Mondrian which freezes the image and it is a bit difficult to debug (see the tests from Glamour-Tests-Mondrian).
- There is an error when using PaginatedMorphTreeMorph which influences the setting of list selection from outside (see GLMListMorphicTest>>testUpdateFromModel)
Cheers,
Doru
--
www.tudorgirba.com
"Every thing should have the right to be different."
We are happy to announce the Moose Suite version 4.7:
http://moosetechnology.org/download
What is new:
• Integration of the Roassal visualization engine
• New PetitParser browser with integrated refactorings
• Improved Glamorous Toolkit for Pharo including the Glamorous Inspector and Debugger
• Several features in Glamour including Watcher support (similar to OS X preview)
• Significant improvements in FAMIX
• Improved external VerveineJ parser for Java
• Based on Pharo 1.4
A list of issues addressed in this release can be found at:
http://code.google.com/p/moose-technology/issues/list?can=1&q=status=Fixed%…
Have fun,
The Moose Team
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-Famix
New issue 916 by anquetil...(a)gmail.com: allChioldScopes include self
http://code.google.com/p/moose-technology/issues/detail?id=916
From a FAMIXScopingEntity, asking allChildScope will include the
receiver ...
this is due to withAllChildScopesDo: which therforew suffers from the same
problem
Expected behaviour: only the direct children of the receiver
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
Status: Accepted
Owner: kurs....(a)gmail.com
CC: tudor.gi...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-PetitParser
New issue 881 by kurs....(a)gmail.com: Missing browser instance variable
http://code.google.com/p/moose-technology/issues/detail?id=881
PPParserBrowser and PPAllParserBrowser are missing browser instance
variable, since the supperclass was changed from BrowserTemplate to
CompsoitePresentation (PetitGui.107).
I presume, this is minor issue, but I have no idea why it was changed from
Template to CompositePresentation.
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 872 by benjamin...(a)gmail.com: Roassal refactor RubberBand>>onDrop:
http://code.google.com/p/moose-technology/issues/detail?id=872
ROExample>>rubberBandOn: currently has the line...
rawView add: (newEdgeRaw + ROLine).
While this is fine in the ROExample script, in my application rawView was
not available at that point, so instead I needed...
newEdgeRaw from view add: (newEdgeRaw + ROLine).
For a while I confused myself by trying to use...
newEdgeRaw view add: (newEdgeRaw + ROLine).
but that was not the same view, since the ROEdge created in the sender had
a random default.
So I now think it is more clear to not create the ROEdge in the sender, but
instead pass the fromElement and toElement and let the user create the
ROEdge themselves. I think this is conceptually clearer.
See the two methods in the attached changeset.
Attachments:
RubberBand-20121125.1.cs 2.4 KB
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 858 by benjamin...(a)gmail.com: Roassal contribution
ROLineEndDiamond
http://code.google.com/p/moose-technology/issues/detail?id=858
I needed a diamond line end symbol to represent aggregation in a UML
diagram, so here it is attached.
Name: Roassal-BenComan.364
Ancestors: Roassal-AlexandreBergel.363, Roassal-BenComan.353
Merge addition of ROLineEndDiamond and ROMondrianExample>>umlAggregateOn:
into mainline (though actually it more catching up ready to merge into
mainline).
Though upon further consideration perhaps 'LineEnd' is not proper, since
someone might want to use it in the middle of a line. Perhaps better
RODiamondLineShape or ROLineShapeDiamond or ROLSDiamond.
btw, since there are many more symbols associated with lines than just
arrows, perhaps consider renaming class ROAbstractArrow something like one
of: ROAbstractLineEnd; ROAbstractLineSymbol; ROAbstractLineShape;
ROLineShape.
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 856 by benjamin...(a)gmail.com: ROAbstractElement>>remove
inconsistent nested behaviour
http://code.google.com/p/moose-technology/issues/detail?id=856
I would expect ROAbstractElement>>remove to work consistently whether it
belongs to the top-level view or nested in another element. However it is
not as demonstrate by the code below having this result...
a ROElement<#x>
------
a ROElement<#x>
a ROElement<#y>
=========================================
v := ROView new.
x := ROElement on: #x.
y := ROElement on: #y.
v add: x.
v add: y. "this line different"
y remove.
v allElementsDo: [ :el | Transcript crShow: el ].
Transcript crShow: '------'.
v := ROView new.
x := ROElement on: #x.
y := ROElement on: #y.
v add: x.
x add: y. "this line different"
y remove.
v allElementsDo: [ :el | Transcript crShow: el ].
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 852 by benjamin...(a)gmail.com: RORubberband with target
highlighting
http://code.google.com/p/moose-technology/issues/detail?id=852
I have added highlighting of target elements to RORubberband - changeset
attached. Note changeset is against Roassal-AlexandreBergel.343.mcz
since .344 breaks something.
Note2, I renamed RORubberbanding to RORubberband. I had originally been
tossing up between the two, and under further consideration I think the
latter is more appropriate. The former will need to be manually removed.
Attachments:
RubberBand2.3.cs 5.9 KB
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 849 by benjamin...(a)gmail.com: Roassal rubber-banding
http://code.google.com/p/moose-technology/issues/detail?id=849
As a new feature for Roassal, I would like to be able to interactively drag
what I term a rubberband (you may have a better one?) from one element to
another to create and edge between them.
I had previously implemented this on original Mondrian but I think only in
my image. I don't think it made it to the Mondrian trunk.
As a starting point of discussion I have attached an extracted changeset
from my image - mostly so that it can be browsed for inspiration in a plain
text editor.
One key part of the Mondrian implementation was using MOCanvas>>drawOn: to
draw the rubberband every cycle as well as being outside of the main
graph. However there is no corresponding #drawOn: on any of the
RO-canvases.
The changeset shows the use by the application of two entry points
#dropRubberBandFrom and #dropRubberBandOn:. Rubber bands can be dragged
from EpcimTerminal elements to EpcimConnectivityNode elements. Method
#addSubViewTo: was my own application-way of splitting up graph creation to
the elements of the graph. I've done this a bit different for updating my
application from Mondrian to Roassal and the reference implementation for
this should preferably use "GLMRossalInteractive"
I have manually re-ordered the changeset so that the order that methods are
used go generally from top to bottom. However the best starting point would
be to scroll down to look at MOCanvas>>drawOn: and MOCanvas>>rubberBand:,
then back up to look at the EpCim* classes,
the the two MOAnnouncer methods.
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 846 by google....(a)ben.coman.com.au: Roassal Easel Find... button
http://code.google.com/p/moose-technology/issues/detail?id=846
With the following steps in Roassal.AlexandreBergel.320
1. World > Tools > Roassal Easel
2. <Example> > ROExample > #basic > lines
3. <Find...> > Node1 > Node2
produces an "Error: not found" from RONullShape.
I am guessing this should be working in this example.
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 843 by google....(a)ben.coman.com.au: ROLightlyHighlightable drains
element colour
http://code.google.com/p/moose-technology/issues/detail?id=843
The following code snippet results in the attached image, showing that
ROLightlyHighlightable drains the original colour from el2 - leaving it
drab and dreary. I think we need to liven up the party for poor old el2,
and give him back his colour.
--------------------
el1 := (ROElement on: 1) height: 50; width:50.
el1 + (ROCircle color: Color lightGreen).
el2 := (ROElement on: 1) height: 50; width:50.
el2 + (ROCircle color: Color lightGreen) @ ROLightlyHighlightable.
rawView := ROView new @ RODraggable.
rawView add: el1.
rawView add: el2.
ROHorizontalLineLayout on: rawView elements.
rawView open.
--------------------
Attachments:
ROLightlyHighlightable-drains-colour-from-element.png 3.6 KB
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 842 by google....(a)ben.coman.com.au: ROTranslatingShape mouse
hotspot mis-alignment
http://code.google.com/p/moose-technology/issues/detail?id=842
Fix attached related to the following mail-posts
Also attached are before and after snapshots from
ROExample>>nestingTranslate.
Ben Coman wrote:
> I was trying to apply ROTranslatingShape to produce a label sitting above
> the
> children nodes. To understand it better how to get what I
> need, I made ROExample>>nestingTranslate to show a permutation of the
> order
> the shapes can be applied. I have attached a screen snapshot and fileout
> for
> this. The case I am particularly interested in is el3.
> The 'el0' case is the reference without any ROTranslatingShape.
> When running the example hover near and over the inner elements to view
> the
> misalignment of the mouse hotspot. I have marked the approximate offset in
> green in the snapshot.
> I notice that the existing call chain goes...
> ROView>>localElementAt:
> ROElement>>elementAt:
> ROElement>>contains:
> ROElemenet>>bounds
> ROShape>>extentFor: (union of extent of each shape)
> It seems to me the hotspot misalignment is related to the translation
> being
> applied at the shape draw level whereas the #contains: checking is done
> at the
> element level. This relies on the union of the shape extents to set the
> element bounds, but I can't see how that extent union could be modified to
> account for the translation - particular in the case of a negative
> translation
> since extents throw away information
> about any negative offset.
> So I thought perhaps that the element #contains: checking needs might be
> better chained through the shaped, so that the translation
> could be applied similar to ROTranslatingShape>>chainedDrawOn:for: and
> that
> this would not cause any/much additional computation since all the shapes
> were
> being cycled through anyway for #extentFor:
> Something like...
> ROView>>localElementAt:
> ROElement>>elementAt:
> ROElement>>contains:
> ROShape>>chainedContains:For: (for each shape)
You can see in all case el1 to el8, the child elements have shifted in
relation
to el0.
However the hotspot remains aligned with the location in el0.
I think part of the problem is that ROChildrenShape is a
ROAbstractEndingShape
and is always at the end of the line - so the translation is applied to the
children elements.
Whereas it might work better if the position of the child elements was not
affected by ROTranslatingShape, such that it becomes the reference for the
position of any other translated shapes.
This would require ROChildrenShape be always the first shape of an element,
rather than always be the last shape.
--------------------
The following code snippet...
el := ROElement on: 1.
(el + ROBorder + ROTranslatingShape + ROLabel ) inspect.
produces shapes chained in order of:
ROLabel-->ROTranslatingShape-->ROBorder-->ROChildrenShape.
which seems reversed from what I would intuitively expect reading the code
left
to right.
I think ideally the shape chain would be:
ROChildrenShape-->ROBorder-->ROTranslatingShape-->ROLabel-->RONullShape
Otherwise as in el1 you can see the position of the label is the same as
el0,
since the label has actually been drawn first prior to the translation, and
instead the translation is applied to the border and child elements, the
latter
of which affects the mouse hotspot.
Attachments:
Roassal-BenComan.310.mcz 242 KB
ROTranslatingShape-permutations-mouse-hotspot-broken.png 33.2 KB
ROTranslatingShape-permutations-mouse-hotspot-fixed.png 29.8 KB
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 841 by hephster(a)gmail.com: Roassal: ROPopup: Text not visible
http://code.google.com/p/moose-technology/issues/detail?id=841
See the example in Roassal Easel: Interaction -> Popup.
The popup is always gray with no text visible.