I've found the following idiom (or parts of it) to be repeatedly useful:
browser transmit
...
andShow: [ :a :b | a finder show: [ :b :object | object
gtInspectorPresentationsIn: b inContext: GTInspector new ] ]
I wonder if it's worth reifying into the DSL. I first thought `a inspector`,
but it seems Object already implements it to open an actual... inspector ;)
-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Moose-f1310756.html
While protoyping a Glamour browser in the editor, it seemed that once I got
an error, I was no longer able to "Go" and have the browser appear in the
top pane. I had to close the editor and open a new one. This was an
unsatisfying workflow. Is there a workaround? If not, could we wrap these
inevitable errors so they don't take down the tool?
-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Moose-f1310756.html
Hi!
I have some improvements I would like to make to Moose query and I
would like your approuval.
First. Currently there is:
- #queryAllOutgoing and #queryAllOutgoingAssociations to query all the
outgoing associations of the receiver
- #queryAllIncoming and #queryAllIncomingAssociations to query all the
incoming associations of the receiver
#queryAll{Direction} is based on the properties while
#queryAll{Direction}Associations seems to be more empirical.
See:
queryAllOutgoingAssociations
^ self queryStaticOutgoingAssociations
addAll: self queryAllOutgoingInvocations;
yourself
I propose two changes:
- Remove the empirical implementation to use only the one based on the
meta-model
- Deprecate #queryAllIncoming and #queryAllOutgoing. I think
#queryAllIncomingAssociations is a better name, but I can change my
mine if you have a different opinion on that.
Second. To query all the in/out associations with the method based on
the meta-models, there is the use of "FAMIXAssociation
withAllSubclassesDo:" to iterate on the associations and do the
queries for all of them.
I have three problems with that:
- This is not efficient. If an entity can have only 2 incoming
associations it will still try the queries for all the associations in
the image
- This has a role in the circular dependency between FAMIX-Core and
Moose-Query packages because we reference FAMIXAssociation
- If one day we create another project from FAME to represent
something that is not a software model, we will maybe not have
FAMIXAssociation but we might still have associations. And Moose-Query
could still be useful on this project.
I propose to add to TEntityMetaLevelDependency two methods:
allOutgoingAssociationTypes
^ (self allChildrenTypes flatCollectAsSet: #outgoingAssociationTypes)
addAll: self outgoingAssociationTypes;
yourself
and
allIncomingAssociationTypes
^ (self allChildrenTypes flatCollectAsSet: #incomingAssociationTypes)
addAll: self incomingAssociationTypes;
yourself
Thus the entities will be ab
--
Cyril Ferlicot
https://ferlicot.frhttp://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
Hi,
apparently CompiledMethod>>#isGTExampleMethod
has been changed from
isGTExampleMethod
^ self pragmas anySatisfy: [ :each | each isGTExamplePragma ]
to
isGTExampleMethod
^ (self pragmas anySatisfy: [ :each | each isGTExamplePragma ])
and: [ self numArgs = 0 ]
(
https://github.com/feenkcom/gtoolkit-examples/blob/master/src/GToolkit-Exam…
, also strange that I don't see the history of the method on github).
In either case this means that if an example has dependencies it is no
longer an example, because it has arguments.
Thanks,
Peter
I was just building a Glamour browser by combining behavior from the many
examples. Somehow, I got into a fight with #display:. Because of the way I
had set up my model, I was expecting display to accept an individual list
item, and it was receiving the list collection instead. Also, I found out
later that what I really wanted was #format, as I just wanted to change the
way the underlying item was shown in the list.
So here's my question: while trying to figure out how #display: worked, I
found where it was implemented but there was no method comment. This seems
to be a core part of the scripting language and I know Moose in general to
be extremely thoughtfully written, so I am assuming that there is some other
way/place where this sort of thing is documented of which I'm not aware.
What am I missing?
-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Moose-f1310756.html
We started to work on a Fortran parser:
https://github.com/NicolasAnquetil/VerveineF.git
Because it's easiest for us, we are using the Eclipse parsing
infrastructure (project Photran)
The parser is in a VERY preliminary version as it only recognizes
function declarations and calls
Famix will also have to be adapted to Fortran ...
It is released under MIT licence
have fun
nicolas
--
Nicolas Anquetil -- MCF (HDR)
Project-Team RMod
Hi
It seems totalNumberOfLinesOfCode disappeared from FamixTypeGroup recently.
Now I wonder if the new implementation is correct because it would be nice to take into account class definition size.
MooseAbstractGroup >> numberOfLinesOfCode
<MSEProperty: #numberOfLinesOfCode type: #Number>
<MSEComment: 'The number of classes in the model'>
^ self
lookUpPropertyNamed: #numberOfLinesOfCode
computedAs: [ self allMethods sum: #numberOfLinesOfCode ]
What do you think?
Stef
--------------------------------------------
Stéphane Ducasse
http://stephane.ducasse.free.frhttp://www.synectique.eu / http://www.pharo.org
03 59 35 87 52
Assistant: Julie Jonas
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley,
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France
