Hi
for certain metrics we need to compute the total amount of lines of code for the complete project.
FAMIXClass >> calculateARLCOMUnderstand
"Class LCOM LOC
C1 12 1000
C2 2 50
For C1 1000/1050 * 12
For C2 50/1050 * 2
"
self halt.
^ self TR_LoC / self mooseModel TR_totalNumberOfLinesOfCode * self TR_LCOM
Now I have a question because totalNumberOfLinesOfCode does exist on Model but on TypeGroup
I wrote it like that on FAMIXTypeGroup
TR_totalNumberOfLinesOfCode
<MSEProperty: #TR_totalNumberOfLinesOfCode type: #Number>
<derived>
<MSEComment: 'Total number of lines of code from Understand'>
^ self
lookUpPropertyNamed: #TR_totalNumberOfLinesOfCode
computedAs: [ (self sumNumbers: [ :each | each TR_LoC ]) asFloat ]
How can I access for example totalNumberOfLinesOfCode at the model level?
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
Hi,
Currently the implementation of #children in MooseEntity is really
fragile. In the current implementation, we select all the selectors
matching "all*s" and we merge the results of these methods.
This is fragile because we could have #allContainerFiles that would not
return children. Also it is possible that there is no method matching
this pattern for some children.
In the meanwhile, Anne, Jean-Christophe and Vincent worked in the usage
of the mse properties in order to build more generic algos. There is
currently a #childrenEntities and a #parentEntities methods to get the
children/parents based on the meta-model of the language. I think this
is now stable.
I will deprecate #childrenEntities and #parentEntities and rename them
#children and #parents now.
So, no need to implement some #children methods anymore :)
--
Cyril Ferlicot
https://ferlicot.frhttp://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
Hi,
I saw that in FAMIXInvocation we have an instance variable named
"receiverSourceCode". I think this is a bad idea to get variables like
this one because source code should be saved via source anchors. Also,
it is not used in Moose image.
I would like to replace the accessors by:
receiverSourceCode
^ self receiver sourceText
receiverSourceCode: aString
self deprecated: 'The source code of the receiver should not be saved
as a property. Instead access it via the receiver entity.'
Any objection? If I get none I'll do it soon to reduce memory consumption.
--
Cyril Ferlicot
https://ferlicot.frhttp://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
Hi,
I have some custom programming languages (Lowtalk for low-level
programming, and Dastrel for GPU shaders) whose grammar are defined by
using PetitParser.
How can I add syntax highlighting support for them by using the GTInspector?
Best regards,
Ronie
Hi,
what is the best approach to use GTExamples as tests?
Should I create a new TestCase subclass that will look up all examples in
my project and run them?
Is there some existing infrastructure that I should just execute?
Thanks,
Peter
Hi team,
I have just unzipped moose_suite_6_0 on my windows 7 system. Built a model
with about 3200 classes following content at
http://www.themoosebook.org/book/ .
When i run the following from the playground tab - [|]
self select: [ :each | each isAnnotatedWith: 'Deprecated' ]
I get the following a popup with title 'MessageNotUnderstood:
FAMIXInvocation>>isAnnotatedWith:'
the first entry has
FAMIXInvocation(Object) doesNotUnderstand: #isAnnotatedWith:
the Variable tab has
self "a FAMIXInvocation
#noname#Restrictions.eq(""userName"",userName).ignoreCase() (Invocation)"
self
thisContext "FAMIXInvocation(Object)>>doesNotUnderstand: #isAnnotatedWith:"
self
Can someone help with this? Earlier this used to work(even model building
had tons of error/warnings). Now the model builds with much lesser error
but cant do anything with it !
Regards,
Bharat
Hi,
I found this method:
allFileAnchors
^self allWithSubTypesOf: FAMIXFileAnchor
The problem is that FAMIXIndexedFileAnchor are also a kind of file anchor.
Should I replace it by
allFileAnchors
^self allWithSubTypesOf: FAMIXAbstractFileAnchor
?
--
Cyril Ferlicot
https://ferlicot.frhttp://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
Why a FamixClassGroup does not know this message?
In fact it knows totalNumberOfLinesOfCode
But numberOfLinesOfCode is defined on model.
So is there a way to convert a group into a model?
Don’t do that. I migrate the numberOfLinesOfCode to AbstractMooseGroup and deleted totalNumberOfLinesOfCode which is now in duplication of numberOfLinesOfCode.
Vincent
Hi vincent
I cannot reply easily I have to understand why I do not receive the moose mails in my mail client.
Now
- This is important to have numberOfLinesOfCode in a model because I need that too.
Because from a class how can I reach all the class of a model?
- you should not “migrate” behavior like that without discussion.
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
Hi
in 2 hours we coded a first and ugly importer for Understand Metrics :).
Soon in the best shops :)
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
Hi guys
I’m coding an importer for moose to import metrics computed from other tools.
Now I created would like to see the imported metrics on FAMIX class.
So I added
FAMIXClass >> TR_LCOM
<MSEProperty: #TR_LCOM type: #Number>
<MSEComment: 'lack of cohesion in methods from XX tools'>
<derived>
^ self propertyNamed: #TR_LCOM
and in my importer
createFamixClassFor: aCollection
"aCollection in the form Name values* following the tag pattern"
| aClass |
aClass := FAMIXClass new.
aClass name: (aCollection first replaceAll: Character space with: $_).
self tags allButFirst
withIndexDo: [ :t :i | aClass propertyNamed: 'TR_' , t put: (aCollection at: i + 1) asNumber ].
self targetModel add: aClass.
^ aClass
testExtendedFAMIX
| importer fmClass |
importer := ThreImporter on: self streamExample.
importer import.
fmClass := importer createFamixClassFor: importer importedArray second.
self assert: fmClass name = 'Messages'.
self assert: (fmClass propertyNamed: 'TR_LoC') equals: 67.
self assert: fmClass TR_LCOM equals: 67.
self halt.
Two questions:
- why I do not see the metrics in the imported famix class? Is there a cache for the metadescription.
- How do I add a Model to the UI? so that we can browse from the Moose Panel?
Tx
BTW I have to see because I do not get the email in my mailbox.
--------------------------------------------
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
in
my Moose image
in
RubTextScrollPane>>scrollSelectionIntoView:
the ( self bounds ) is always set to the default Morph value of
( ( 0@0 )corner:( 40@50 ) )
so
only single page Methods are correctly
selection scrolled into view
in the GTGenericStackDebugger
so
i am guessing that this has been remedied in a Moose
update
is
this in fact what has happened ?
or
can you help me to fix this ?
i tried a couple days to fix it myself but i didn't get anywhere
Thanks
Hi
I'm rusty but I wanted to share something
I did
MooseModel allInstances second allModelClasses numberOfLinesOfCode
and I got an error because a group does not know number of lines of code.
Why a FamixClassGroup does not know this message?
In fact it knows totalNumberOfLinesOfCode
But numberOfLinesOfCode is defined on model.
So is there a way to convert a group into a model?
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
Hi,
We are happy to announce that the moldable editor helped us create a richer transcript: GT Transcript.
The transcript is traditionally a stream of plain text. As we now have an elaborate editor, we can take advantage of it to help us display richer representations.
The API is backward compatible with the existing transcript. To enable the new features, we introduced a builder. For example:
transcript nextPutAll: ‘something’
becomes
transcript next putAll: ‘something’
and after #next we can add multiple attributes that we want to affect the following insertion of a text.
Below you can find an example detailing most of the API. The most notable additions is the support for expandable adornments. For example, #showException: provides an in-place expansion of the stack of the exception context.
To get an idea of how this tool can be useful, take a look at the following video showing the visual logging of a Bloc animation:
https://youtu.be/9VATYNaLwJY
The code can be found in the new incarnation of GToolkit:
Iceberg enableMetacelloIntegration: true.
Metacello new
baseline: 'GToolkit';
repository: 'github://feenkcom/gtoolkit/src';
load.
Cheers,
The feenk team
--
www.tudorgirba.comwww.feenk.com
“Software has no shape. Actually, it has no one shape. It has many."
Hi,
When we announced the GT Documenter as an application for the moldable editor, one of the remarks was that GT Examples implementation relies too much on pragma magic.
We are now happy to announce that this is no longer the case because Andrei did a great job and rebuilt examples without the need for static pragmas for specifying dependencies.
So, now we can example dependencies simply through normal calls:
emptyView
<gtExample>
^ GtMondrian new
twoNodes
<gtExamples>
view := self emptyView
view nodes with: {1 . 2}
... and the engine can figure out the static dependencies. This means that examples can be used both as plain unary methods, and as replacement for tests. We think this should address the worry of examples being too heavy (the current implementation is ~350 lines).
With a bit of extra effort, we also adapted GT Documenter to expand the example dependencies as seen below. This means that examples can now be used directly as units of documentation as well.
We think this is significant.
Cheers,
The feenk team
--
www.tudorgirba.comwww.feenk.com
"We are all great at making mistakes."
Hi,
We are really pleased to announce another major advancement in the development of the moldable editor, and most of it was enabled because of one new feature: expandable elements. We think this will impact significantly our day to day interactions.
To exemplify what we mean, we will make use of two more alpha projects that we did not announce yet: GT Documenter (a set of documentation tools based on Pillar and GT Examples) and GT Mondrian (the graph visualization engine), both of which are being implemented in Bloc.
Please take a look at the following pictures showing the documentation Pillar file that ships together with GT Mondrian. What stands out are the two embedded pictures. These are actually not pictures, but visualizations rendered live during the viewing of the document out of a referenced GT Example.
Now, GT Examples are likely also new for most people. We introduced them a couple of years ago based on the original idea of Markus Gaelli. These are a kind of tests that return an object and that can be built out of other examples. The nice thing is that they are always executable and testable. So, of course, if you see the resulting object, you can also see the code that created it, and if you see the code, you can even execute it live, right in place (notice the preview of the second snippet).
Perhaps the most controversial part of GT Examples is that they offer a mechanism to define static dependencies via pragmas. Please, let’s leave this debate to another occasion, but please also notice that tools can use that static information to unfold the code of the referenced method (notice the nested code editors).
A side note: if you look closer at the list with three items at the top of the Tutorial section, you will notice numbering next to #. That is actually syntax highlighting and so is the mechanism that embeds the expandable elements. It’s really cool.
Taking step back, when we introduced the editor a few weeks ago, we called it moldable because we said we can make it take different shapes easily. GT Documenter with everything you see in the above screenshots has currently ~500 lines of code, and all this while still having an editor that is highly scalable.
We think that Bloc and Brick will change dramatically face of Pharo and now we can start to get a glimpse of what is possible. For example, the use case presented above is more than a technical tool, and we think this will change both the way we write documentation and the way we consume it.
All these will be presented at ESUG both during presentations and at the Innovation Awards competition. In the meantime, those that want to play with it can execute the following in both Pharo 6.1 and Pharo 7.0:
Iceberg enableMetacelloIntegration: true.
Metacello new
baseline: 'GToolkit';
repository: 'github://feenkcom/gtoolkit/src';
load.
And then inspect:
'./pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' asFileReference
Cheers,
The feenk team
--
www.tudorgirba.comwww.feenk.com
"Innovation comes in the least expected form.
That is, if it is expected, it already happened."
That is ok :) Those are not used modules and can be ignored.
I am glad it worked! I will see, maybe it is possible to get rid of at
least one gtk dependency.
Cheers,
Alex
On Aug 18, 2017 6:19 PM, "stephan" <stephan(a)stack.nl> wrote:
On 18-08-17 17:12, Aliaksei Syrel wrote:
> echo "Installing GTK-2.0...";
> sudo apt-get install libgtk2.0-0:i386;
> echo "Installing GTK-3.0...";
> sudo apt-get install libgtk-3-0:i386;
>
Great, that works. Those two were missing.
Stephan
It still complains:
Installing library to File @ /home/stephan/Desktop/pharo6.1
/bin/lib/pharo/5.0-201707201942/libMoz2D.so
Launching Moz2D services...
Gtk-Message: Failed to load module "overlay-scrollbar"
Gtk-Message: Failed to load module "gail"
Gtk-Message: Failed to load module "atk-bridge"
Gtk-Message: Failed to load module "unity-gtk-module"
(pharo:8447): Gtk-WARNING **: Unable to locate theme engine in module_path:
"murrine",
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
Hello
Who can help to get a Pharo 6.0/6.1 catalog entry for PetitParser and YAML?
Who is maintaining PetitParser?
I successfully did a manual installation
Repository:
MCSmalltalkhubRepository
owner: 'Moose'
project: 'PetitParser'
user: ''
password: ''
I loaded
Name: ConfigurationOfPetitParser-TudorGirba.80
Author: TudorGirba
Time: 13 September 2016, 9:59:15.01645 pm
Then
ConfigurationOfPetitParser load
All 232 tests are green for PetitTests-Core and PetitTests-Tests
For YAML parsing I loaded
PetitYAML-PhilippeBack.11
Author: PhilippeBack
Time: 29 May 2017, 12:53:55.994195 pm
from the same repository.
All 76 tests are green.
How do these two packages get a Pharo 6.0/6.1 ** catalog entry?
Regards
Hannes
** The entry should be marked as '6.0'. The image has an 'about
information of Pharo 6.0-60510 and on the desktop it shows 6.0. But
the same image has been announced as version 6.1.
Hello Stephan,
> Yep. I tried with a clean 6.1 install.
> The Moz2D library is downloaded, but does not seem to be installed
> correctly
Below is the list of dependencies for *64bit Ubuntu* and *32bit Pharo*: (on
64bit pharo it should theoretically work out of the box, except 64bit
related issues)
> sudo dpkg --add-architecture i386;
> sudo apt-get update;
> export PKG_CONFIG_PATH=/usr/lib/i386-linux-gnu/pkgconfig/;
>
> echo "Installing c++ libraries";
> sudo apt install libstdc++6:i386;
>
> echo "Installing GTK-2.0...";
> sudo apt-get install libgtk2.0-0:i386;
> echo "Installing GTK-3.0...";
> sudo apt-get install libgtk-3-0:i386;
>
> echo "Installing libGL...";
> sudo apt-get install libglu1-mesa:i386;
We have travis Build which is green:
https://github.com/syrel/Sparta/blob/master/.travis.ymlhttps://travis-ci.org/syrel/Sparta
On Windows users should install Visual C++ Redistributable for Visual
Studio 2015: (reduces binary size by >10mb)
https://www.microsoft.com/en-US/download/details.aspx?id=48145
On OSX works out of the box
Cheers,
Alex
On 18 August 2017 at 17:01, stephan <stephan(a)stack.nl> wrote:
> On 12-08-17 10:47, Tudor Girba wrote:
>
>> Is this still an issue?
>>
>
> Yep. I tried with a clean 6.1 install.
> The Moz2D library is downloaded, but does not seem to be installed
> correctly
>
> > Could you also try on another OS (just to make sure)?
>
> next step
>
> Stephan
>
>
Hi,
After another intense week, we are happy to announce that the Brick editor now supports some advanced syntax highlighting.
To put it in perspective, let us take a look at one screenshot showing an inspector presentation containing a Brick editor opened on a Pillar file that includes some text, a code snippet and a reference to a picture:
This shows both that we style the text based on the Pillar grammar, but also that we can style Smalltalk code (in fact, we have two nested stylers here).
But, the more interesting thing is that below the picture reference, we get to see the actual picture (which happens to be another inspector screenshot). In fact, this picture is actually just another text attribute (we call it an adornment) that can be dynamically added to any text elements. This opens up a whole lot of expression power and it is all easily compose-able. This is another reason why we say that this editor is moldable and you should expect new applications making use of this moldability and combining it with the liveliness of Pharo.
The latest Brick code is loadable through:
Metacello new
baseline: 'Brick';
repository: 'github://pharo-graphics/Brick/src';
load: #development.
If you want to play with Pillar, load the following extra code and just inspect a Pillar file:
Metacello new
smalltalkhubUser: 'Pier' project: 'Pillar';
configuration: 'Pillar';
version: #development;
load.
((IceRepository registry detect: [ :each | each name = 'Brick' ])
packageNamed: 'Brick-Editor-Pillar') loadLatest.
One other thing to mention is performance. What Alex (Syrel) managed to do is quite remarkable. To see the impact in practice, try editing the largest method in Pharo (UnicodeDefinitions class >> #data) in both the built-in editor and in the Brick editor by inspecting:
BrTextEditor onMethod: UnicodeDefinitions class >> #data
There are still issues left to deal with and we will focus on them in the following weeks. But, we can safely say that the most important challenges are now behind us and that the design of the editor code is stable and robust.
Please do let us know what you think.
Cheers,
The feenk team
--
www.tudorgirba.comwww.feenk.com
"If you interrupt the barber while he is cutting your hair,
you will end up with a messy haircut."
Is this still an issue?
Could you also try on another OS (just to make sure)?
Cheers,
Doru
> On Aug 10, 2017, at 2:12 PM, stephan <stephan(a)stack.nl> wrote:
>
> On 10-08-17 13:09, stephan wrote:
>> On 05-08-17 00:19, Tudor Girba wrote:
>> >Iceberg enableMetacelloIntegration: true.
>> That doesn't work. It hangs the image, keeping one CPU
>> busy.
>
> With 60510 that is non-interruptable, b.t.w.
>
> Stephan
>
>
>
>
--
www.tudorgirba.comwww.feenk.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
