> Begin forwarded message:
> From: Sven Van Caekenberghe <sven(a)stfx.eu>
> Subject: [Pharo-users] [ ANN ] Pharo Days 2016
> Date: December 9, 2015 at 9:52:09 AM EST
> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org>, Pharo Development List <pharo-dev(a)lists.pharo.org>, Pharo Business <pharo-business(a)lists.pharo.org>
> Reply-To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org>
> Dear fellow Pharoers,
> Mark your calendars: on Thursday March 31 & Friday April 1 we are organising the Pharo Days 2016. This year we moved the location to Namur, Belgium, just a bit south of Brussels, at the very beautiful location of the ‘Cercle de Wallonie’ overlooking the river Meuse.
> We’ll update the following page moving forward.
> You can ask questions on any of the Pharo mailing lists or you can email the Pharo Board.
> Let's make this another success, together ! We hope to see as many of you as possible.
"We are all great at making mistakes."
Synectique is openning the source code for a C/C++ parser based on
The parser was developed as an Eclipse (Mars release) plugin and is
under MIT licence.
Nicolas Anquetil -- MCF (HDR)
Is there a way to set a default selection to a list presentation? so that
when I open the browser, the morphic list has already a value selected.
I tried that:
tmpBrowser := GLMTabulator new.
tmpBrowser row: #list.
tmpBrowser transmit to: #list; andShow: [:a |
display: [:input | input];
tmpBrowser openOn: #( b c d v a d f r).
but the list still open with nothing selected
What is the best way for an object to delegate one or more GTInspector
views to other objects?
I have been using a pattern like this:
otherObject gtInspectorFooIn: composite
but I am wondering whether there is a better way, and also whether this
method is valid (I've occasionally seen odd behavior, like Inspector panes
disappearing after I "Refresh", and I wonder if I could be somehow
confusing the model or if this is not relevant.)
also: Supposing this pattern is valid, is there an easy way to override the
title of the view(s) added by otherObject?
Since we got a question on this recently, I hereby annouce that for a
local project, I started a Fortran to MSE parser.
- because this is an "easy" path, it is based on PTP, an Eclipse plugin
for Fortran (similar to parsing java with JDT and C/C++ with CDT)
- it is in a very preliminary state (proof of concept). Don't expect
off-the-shelf installation and use
- tied to a specific version of Eclipse, ask details if interested
- currently only identifies sub-programs (and functions) and their
invocations + global variables and their accesses
code available at: https://github.com/NicolasAnquetil/VerveineF.git
RMod team -- Inria Lille
Re: Cyclomatique Complexity
Thank you all of you for your answers,
It looks like this is a controversial question :
CQSE Blog - McCabe's Cyclomatic Complexity and Why We Don't Use It
Anyway, I find this way of calculating CC quit confusing. For me a boolean does not define a branch; branches are sets of instructions that are executed or not.
Also, Booleans are sometimes considered as any other type and sometimes not.
For instance, in the expression x or: y, why the first boolean (x) creates two branches but not the second. i.e. why
^x or: y <=> x ifTrue:[^true] ifFalse[^y]
^x or: y <=> x ifTrue:[^true] ifFalse[y ifTrue:[^true] ifFalse:[^false]]
Besides, in the following code
self doSomethingIf: (condition1 or: condition2) => 1 branches, doSomethingIf: is always invoked. but CC = 2
That’s why I would rather ignore boolean operators when calculating CC. But this is a personal opinion :)
On 17 Nov 2017, at 12:00, moose-dev-request(a)list.inf.unibe.ch wrote:
It seems to make sense to me if you think of code optimization (I assume
Pharo does this). Indeed
^true :or false
must always execute both paths, but
^false :or true
only needs to execute one path to have a result of true for the OR. There's
a similar case for :and with false values.
On Tue, Nov 14, 2017 at 4:17 AM, Nicolas Anquetil <nicolas.anquetil(a)inria.fr
Yes typically, it is easier to count cyclomatic as +1 for each "testing
statement" (if, loops)
May be the rational is that #or: is basically the same thing as #ifFalse:
and #and: is similar to #ifTrue: ?
In FAST for pharo, there is an algorithm that computes cyclomatic also, it
uses the same ideas (#or: and #and: add 1 to cyclomatic)
On 12/11/2017 18:11, Stéphane Ducasse wrote:
Normally cyclo is
the number of paths
1 for the true (the main flow)
+ on for the true and the or: the alternative flow.
CQSE Blog - McCabe's Cyclomatic Complexity and Why We Don't Use It
I have just noticed that when calculating the cyclomatic complexity of a method, Moose adds 1 for each boolean operator in the code.
For instance, the cyclomatique complexity of
This is funny because I found such a thing anywhere else.
In addition, In the method RBVisitorForFAMIXMetrics>>computeCyclomaticNumber: there is a comment that says :
"The score is basically the number of decision points in a routine + 1. Decision points are taken to be conditionals and loops.”
but then in the code, there is another strange comment :"-- HERE STARTS THE OLD ERRORFUL IMPL --"
and some lines further :
cyclo := self cyclomaticNumber + 1 + booleanOperators.
So my question is : Why booleanOperators is used to calculate cyclomatique complexity. Wouldn’t it be simpler to do cyclo := self cyclomaticNumber + 1?
Thanks in advance
Would it be possible to have a quick install of Moose64 for Linux, Mac and Windos available somewhere easily accessible?
I was teaching moose yesterday and today again with other students. It took half an hour to get an image of Moose 64 that works, downloading Moose64 on the CI website, Pharo VM on another web sites and the sources. It is not a good image that we give to the students with this complexity just to download Moose.
I really think that it is relevant for the students to work on Moose, but please help us by providing an archive with everything in it.
I agree that because it is open source project, I could help in this, but I am sure, that you will prefer not, because I am really bad at this.
Thanks a lot for your help.
Currently Moose-Query works with Traits.
There is :
- TDependencyQueries containing all the query system and the common
queries such as #queryIncomingAccesses
- TOODependencyQueries using TDependencyQueries and adding the method
specific to OO entities (mostly inheritance queries)
The users of TDependencyQueries are:
The users of TOODependencyQueries are:
I think it would make sense to move TDependencyQueries to FAMIXEntity.
FAMIXEntity has all the API needed to the queries and it would help
with the consistancy. For example I think that all famix entities
should be able to answer to "queryAllIncomingAssociations". It would
felp making more generic tools.
What do you think? Does that bother someone?
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
I find how to easily do one Distribution map from elements.
However, as you can see, it is not very beautiful.
- Is there an easy way to get legend on distribution map? Here each color corresponds to an author, but if I don’t say it to you you can’t invent it.
- the labels are too long, there are the result of element printString and not of element mooseName. How can I change that?
- I would also like to be able to inspect each element when clicking on it. But once again, since DistributionMap doesn’t inherit from any Roassal element, I don’t know how to do it.
Can anyone help me?
Thanks in advance.