- Moose-dev - INF Mailman

by Cyril Ferlicot

Hello everyone! Some year ago, Moose included a query mechanism called MooseChef. This mechanism worked but was hard to maintain and it was easy to make mistakes in the queries. In 2015 Jean-Christophe Back and Anne Etien created MooseQuery. MooseQuery is a domain-specific language to build navigations and scopes queries for entities in Moose. I helped to improve the performances of MooseQuery in order to use it at Synectique and today I present you a documentation of MooseQuery: https://moosequery.ferlicot.fr/ This documentation cover three axes: - The user documentation: explain how to use MooseQuery to query a model - The developer documentation: explain how to expand a meta-model to make it queriable by MooseQuery and explain how the queries work internally - The API documentation The documentation was already reviewed and enhanced by Anne. If you wish to contribute, you can do a pull request to https://github.com/jecisc/MooseQueryDocumentation. I hope this can help Moose's community. Have a nice day :) -- Cyril Ferlicot https://ferlicot.fr

7 years, 5 months

2
1
0 0

Notification of modifications in MooseQuery

by Cyril Ferlicot

Hello everyone! Some month ago I sent a mail asking to ensure that all FAMIXEntities could answer to all MooseQuery queries. The answer was no because the community does not want some entities to be able to answer to every query. (For example to have associations that can answer to navigation queries). This bothered me because we already have entities that can answer to #children, #parents, #toScope:, #atScope:... even if it does not make any sense. Now I come back with a proposition to clean this half/half state and to get a clean model query side. I discussed these changes with Anne and she agrees with them. In the current state of MooseQuery we have: - TMetaLevelDependency used by FAMIXEntity that allow querying the children, parents, and scopes of an entity - TEntityMetaLevelDependency using TMetaLevelDependency. It adds the navigation queries. - TAssociationLevelDependency using TMetaLevelDependency. It adds some useful methods to associations for the navigation queries. We have two changes to propose. First. It does not make any sense for TAssociationMetaLevelDependency to use TMetaLevelDependency since an association should not be able to answer to #children, #parents, #toScope:... We propose to remove this usage. I did this change in an image and launched MooseQuery/Chef tests, everything is green. Second. TMetaLevelDependency does not make any sense when we have TEntityMetaLevelDependency. All the methods of TMetaLevelDependency are related to entities. We propose to copy all the methods of TMetaLevelDependency to TEntityMetaLevelDependency and remove it. TMetaLevelDependency has two users: FAMIXEntity and TEntityMetaLevelDependency. Since we copy the methods to the second user, there is no problem with it. The biggest change is that now FAMIXEntity will not implement any Meta trait. It does not need to use any since all its subclasses should not understand generic queries. The only change that needs to be done is to move the caches created on FAMIXEntity to the users of TEntityMetaLevelDependencies. I tried to apply this changes in a quick and dirty way to an image and once again all tests seem to pass. In conclusion, what do we win with this changes? All Famix entities will only understand the queries they can answer to. FAMIXAssociation, FAMIXSourceAnchor, FAMIXSourceLanguage will not understand anymore #children, #parents, #toScope:, #atScope:... Have a nice day :) -- Cyril Ferlicot https://ferlicot.fr

7 years, 5 months

2
2
0 0

Scala

by Guido Chari

Hi guys, Is there any importer available to generate Moose models for Scala code? Best regards, Guido.

7 years, 5 months

4
4
0 0

feenk log

by Tudor Girba

Hi, Here is an update of the work on Bloc and GT. As always, please do let us know what you think. Bloc: - Eventing saw a deep overhaul. They are now dispatched using the Announcements engine. The previous mechanism is still in place in order to help people compare the impact. In the process, we also cleaned the propagation of events, and we made them debuggable through inspector extensions: https://twitter.com/feenkcom/status/955086133519618048 https://twitter.com/feenkcom/status/946482609680539649 - Embedding Bloc elements in Morphic is even easier now: https://twitter.com/feenkcom/status/946676667002556416 - We continued the work towards an interactive creation of a graphical scene: https://twitter.com/feenkcom/status/948492946541858816 - Theme experiment GT: - The documentation of Mondrian is available when you download the code and can be viewed using GT Documenter: https://twitter.com/feenkcom/status/939394586115563520 - The Mondrian extensions of BlElement are now extracted in a more general package that enables Bloc elements to be used in graph scenes. Have fun, The feenk team -- www.tudorgirba.com www.feenk.com "Obvious things are difficult to teach."

7 years, 5 months

3
5
0 0

Fwd: [Pharo-dev] Google Summer of Code 2018 with Pharo Consortium

by Serge Stinckwich

---------- Forwarded message ---------- From: Jigyasa Grover <grover.jigyasa1(a)gmail.com> Date: Wed, Jan 10, 2018 at 6:10 AM Subject: [Pharo-dev] Google Summer of Code 2018 with Pharo Consortium To: pharo-dev(a)lists.pharo.org Hello Pharo-ers ! On behalf of the community, I would like to thank each one of you for their significant contribution in the previously concluded *Google Summer of Code 2017* with *Pharo Consortium*. We aspire to take-off on a long flight after this successful stint by applying to participate in the upcoming *Google Summer of Code 2018*. As many of you might know, Google Summer of Code is a global program focused on bringing more student developers into open source software development. Students work with an open source organization on a 3 month programming project during their break from school. Read more about the program here: https://summerofcode.withgoogle.com/ The deadline for organisations to apply is January 23, 2018 which is fast approaching. As an open source evangelist and a Pharo developer, I would like to invite all the experienced members to be a part of the "GSoC 2018 with Pharo Consortium" Team and mentor students. Propose fresh ideas for projects which shall help improve Pharo or volunteer to mentor any of the existing one (Listed here: http://gsoc.pharo.org/). To add your own project idea to the list, visit http://gsoc.pharo.org/#adding-a-proposal Looking forward to an appreciable representation from the Pharo community. Best regards Jigyasa Grover Pharo Consortium Org Admin, Google Summer of Code 2017 [hidden email] -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/

7 years, 5 months

1
0
0 0

[ann] gt connector

by Tudor Girba

Hi, Towards the end of last year we worked on GT Connector, a new kind of interface that allows us to exercise and test the limits (or the lack thereof) of Bloc. It looks like this: You can see it in action here: https://twitter.com/feenkcom/status/936109463462965248 In the current implementation, the Connector allows us to navigate and connect example methods. The focus is not on examples, but on the connections. We used examples because the engine was already around and offered us a nice use case. We want to extend it in the near future to other kinds of objects. There are a couple of things that are worth noting: • The editor works live, and the connection points appear and disappear as you type. • The layout of the editor elements is based on a tree-based graph layout that only works with constrains (no actual visible edges between the editor elements). • The editor works live, so adding new elements to the scene properly rearranges the scene. • But, perhaps, the most exciting part is the fact that the lines connect an element from inside the text editor element with another that lives outside of the editor element. All these validate the architecture of Bloc of having exactly one rendering tree. It was not an obvious goal a couple of years ago, but we are really happy that it works. To put it in perspective, let's compare this with the html world. Text is text is rendered through the DOM tree. If you want graphics you might use something like SVG which comes with its own tree. However, these are two distinct worlds, and you cannot go from one to another, or at least not easily. This is the case in most engines we looked at. Why is this important? One thing we learn in the Smalltalk world is that covering the same space with less concepts opens up a whole dimension of creativity that is simply not possible outside of it. The goal with Bloc is to enable new kinds of user interfaces. As we are late to the game of modern interfaces, even though the field was invented in Smalltalk, our only chance to take the lead again is to rethink the model. Let's look at the Connector again. In most user interfaces we have panes on the outside, and visuals confined within the boundaries of those panes. Interestingly, we can trace this pattern to the very first Smalltalk interfaces. In the Connector interface we have no boundaries with text and visualization being intertwined to form a new kind of workflow. Talking about workflows, we now have two distinct and novel ways to explore examples: one is Connector, and the other one is the expandable code editor. For example, the scene from above looks like this in the example expanding editor: Both of these interfaces are not found in other infrastructures, and yet they were both inexpensive to implement in Bloc. We believe this will have a deep impact for all sorts of interfaces, and especially for the IDE. If you are interested in more details related to the IDE, take a look at the following paper from 2015: http://scg.unibe.ch/archive/papers/Girb15b-PervasiveSoftwareVisualizations.… Please let us know what you think. Cheers, The feenk team -- www.tudorgirba.com www.feenk.com "What is more important: To be happy, or to make happy?"

7 years, 5 months

7
7
0 0

Test failure in Arki

by Cyril Ferlicot

Hi, I saw this test failure in Moose. REPConcernTest>>testDefaults self assert: REPConcern new label = #REPConcern. This comes from Name: Arki-Reporter-Core-TudorGirba.24 Author: TudorGirba Time: 30 December 2017, 11:32:57.176429 pm UUID: 2944c23a-f71d-0d00-88a2-a4180f45ebf9 Ancestors: Arki-Reporter-Core-GuillaumeLarcheveque.23 improve label Since it seems intentional, I will update the test to this: REPConcernTest>>testDefaults self assert: REPConcern new label = 'REP Concern'. self assert: REPConcern new explanation = 'REP Concern'. -- Cyril Ferlicot https://ferlicot.fr

7 years, 5 months

2
1
0 0

bloc next experiments

by Tudor Girba

Hi, Happy New Year! We were asked about the roadmap of Bloc several times. It is a perfectly reasonable request given that Bloc is supposed to offer the UI infrastructure for the future of Pharo. However, I was reluctant to provide one because we do not really have a classic roadmap. When we develop Bloc and GT we think in terms of experiments and examples that we want to play with to get us to our goal. Features are a consequence of that. This approach allowed us on multiple occasions to stumble across functional possibilities that we would have not been able to think about before seeing the experiments. It also works the other way around: as we move ahead, we sometime discover modeling problems and we sometimes chase them all the way down. Having said that, we can specify the next examples and experiments that we consider for the next months. Here they are: • Drag and drop that can be customized on an instance basis. In the process, revisit event management and explore making it use Announcements. Use this for the diagramming engine. • Scrollbar for infinite list and the scalable element. • Apply layout once. For example, this would allow us to apply a layout but still be able to drag elements in custom positions without disturbing the others. The first application is in the context of creating diagrams and visualizations. • Apply layout with animation. For example, in Connector, a new example should be spawned and moved to its position through a smooth animation. This will also allow us to play with the concept of animation and MVVM. • Introduce the concept of elevation. This is important for scenes in which we have overlapping elements that are not part of the composition tree. For example, in Connector, the lines connect inner elements inside the text, but they belong to the root. such as a visualization (but not only). For this to work, we need a better element traversing structure. • Experiment with theming. The theming mechanism should be instance specific with per-widget defaults, and the theme values should ideally be injected in the widgets. The CSS implementation from Glenn is one direction. As developing and maintaining themes can be a nightmare in the long run, the theming mechanism to provide debugging tools. • Experiment with delegating animations through the model. Typical MVVM or MVC focus on the behavior of an interaction. We want to get smooth live interfaces and the animation logic should be influence-able by the model. For example, hovering over a button, enlarges the button with extra details about the action. • Basic widgets: list, input box, button, radio button, checkbox, menu, dropdown menu, toggling button, tabs, toolbar. • Table and tree widgets. • Pager interface (similar to the one in the current inspector) with resizable panes. Have fun, The feenk team -- www.tudorgirba.com www.feenk.com "Presenting is storytelling."

7 years, 5 months

1
0
0 0

Moose server is down and it breaks Moose builds on Jenkins

by Cyril Ferlicot

Hi, I think pretty much everything is in the title. ConnectionTimedOut: Cannot connect to 5.35.243.183:80 -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France

7 years, 5 months

2
1
0 0

More named colors

by Stéphane Ducasse

Hi Since for some experiences in moose we needed more named colors I started to gather together some old extensions and I cleaned the implementation. Now we have emacs colors and XKCD i.e around 1600 named colors. Gofer new smalltalkhubUser: 'StephaneDucasse' project: 'Colors'; package: 'MoreColors'; load. Color initializeNames I would really like to see how we can model the notion of color palettes. Stef -------------------------------------------- Stéphane Ducasse http://stephane.ducasse.free.fr <http://stephane.ducasse.free.fr/> http://www.synectique.eu <http://www.synectique.eu/> / http://www.pharo.org <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

7 years, 6 months

1
0
0 0

Glamour: Updating FastList

by Sean P. DeNigris

I have: ``` a fastTree act: [ :tree :projects | projects add. tree update ] iconName: #add on: $n entitled: 'New Project'; … ``` The tree does not get updated with the new project, but if I close the browser and reopen it is up to date. Ideas? ----- Cheers, Sean -- Sent from: http://forum.world.st/Moose-f1310756.html

7 years, 6 months

2
6
0 0

Delegating views

by Luke Gorrie

Hoi, 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: gtInspectorFooIn: composite <gtInspectorPresentationOrder: 5> 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?

7 years, 6 months

3
5
0 0

Error handling in GTInspector?

by Luke Gorrie

Howdy, I have written a bunch of GTInspector extensions and I would like to get error handling under control. I have errors occuring in a few different contexts such as: - Running gtInspectorFooIn: method - Running display: block for a view - Running column:evaluated: block for a table and at the moment the symptoms are quite different e.g. Debugger dialog or big red morphic error box. How do other people handle errors in their views? I feel like there are two approaches that would be ideal at different times. The "user friendly" way would be to flag errors and keep them out of the way -- e.g. skip views that error, skip table rows/columns/cells that error, etc. The "developer friendly" way would be to hit the debugger as early as possible in order to make a fix. Thoughts / tips / links welcome :) Cheers! -Luke (still having a great time hacking inspector extensions)

7 years, 6 months

1
0
0 0

Glamour: Can't see actions without title

by Sean P. DeNigris

The following won't display the action button unless the commented code is un-commented: browser transmit to: #list; andShow: [:a | a list "title: 'Filter and named action ';" act: [:list | list update] iconName: #add on: $n entitled: 'Update' ]. Known issue? ----- Cheers, Sean -- Sent from: http://forum.world.st/Moose-f1310756.html

7 years, 6 months

2
1
0 0

[ann] gtmondrian

by Tudor Girba

Hi, We are happy to announce GT Mondrian, a graph visualization engine built on top of Bloc. It is similar to the original Mondrian and the Mondrian from Roassal, but it is different in that it is built directly out of Bloc elements. This is interesting because it allows us to combine typical widgets with visualizations. The other interesting thing about it is that it validates the design of Bloc: right now, the implementation has 509 lines of code (excluding graph-specific layouts). The goal is to make visualization a first class citizen and an integral part of the IDE. The key ingredient that made this happen is that Bloc can now treat graph layouts, such as tree or force based, behave under the same rules as typical widget layouts, such as grid or flow. The challenge comes from the fact that a graph layout depends on the notion of edges between elements, and we did not want to have elements know about edges in the core of Bloc. The solution was to split the typical edge implementation in graph visualization libraries into two distinct concepts: • Line is an element that draws the connections. • Edge defines constraints imposed by connections between elements. Thus, edges form constraints, and constraints are what layouts deal with. That is one reason why elements in bloc have the ability of defining layout-specific constraints. Using this, we can nicely define edges between elements as a plugin to Bloc, but still be able to connect arbitrary elements. What's more, it turns out that we need constraints for other layouts as well. For example, an element in a grid layout might specify the span. The API of GT Mondrian is similar to the one from Roassal, but there are a few differences as well. These are described in the Pillar documentation available in the GitHub repo. The best way to experience GT Mondrian and its documentation is to load the GToolkit as described here: https://github.com/feenkcom/gtoolkit If you download the GT code through Iceberg, the documentation can be experienced live by inspecting: './pharo-local/iceberg/feenkcom/gtoolkit-visualizer/doc/mondrian/index.pillar' asFileReference Cheers, The feenk team -- www.tudorgirba.com www.feenk.com "Quality cannot be an afterthought."

7 years, 6 months

5
8
0 0

Finding rows in fastTables?

by Luke Gorrie

Hoi, GTInspector is awesome! I am spending a lot of time scrolling through GTInspector lists and tables trying to spot the row that I am interested in though. Is there a trick to accelerate this somehow? I am used to Emacs where I can use the search function to type a text fragment - e.g. "error" - and have the matching occurrences highlighted. It would be awesome if the glamour lists/tables support some similar lightweight searching mechanism...? Cheers! -Luke P.S. Here is a screenshot of a haystack and I am trying to eyeball needles in... e.g. I want to find a particular address or a field called "error" or ...

7 years, 6 months

2
3
0 0

Famix generator for Scheme/Lisp ?

by Thomas Haug

Hi everbody, Can anybody tell me if there is a Famix generator for Scheme/Lisp? If found the following paper [ http://www.inf.usi.ch/lanza/Downloads/Baro07a.pdf | www.inf.usi.ch/lanza/Downloads/Baro07a.pdf ] But there is not Repo, etc to the get the code. Beside writing the FamixGenerator for .NET I started (again) to code in Scheme for fun and I would like to "analyse" my Scheme code. Many thanks Thomas

7 years, 6 months

1
0
0 0

How to access to a model

by Stéphane Ducasse

Hi guys I loaded a model into moose and MooseModel root first gives me the model but it is bad. Is there a way to access the model? Then I do not understand why the storage by name is empty. I cannot do MooseModel root entityNamed: #mymodel. Stef -------------------------------------------- Stéphane Ducasse http://stephane.ducasse.free.fr http://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

7 years, 6 months

2
3
0 0

[Bug]: Scrolling Live Example in Bloc Pillar Presentation

by Sean P. DeNigris

Steps to reproduce: 1. Inspect the GT Transcript Doc 2. Tab to "Bloc Pillar" 3. At the bottom of the doc, run the #transcriptWithAnimation example 4. Hover over the visual result of the example and scroll vertically Both the presentation and example result scroll simultaneously, making it impossible to scroll very far toward the beginning frames of the animation. p.s. ***Separate issue*** the triangles to expand examples are way too finicky. One has to click on just-the-right place to get them to operate, not anywhere within the triangle ----- Cheers, Sean -- Sent from: http://forum.world.st/Moose-f1310756.html

7 years, 6 months

2
3
0 0

Re: [Pharo-dev] How to get a Moose Model

by Tudor Girba

Hi, Thanks for the question. Please address this to the moose-dev mailing list (in CC): https://www.list.inf.unibe.ch/listinfo/moose-dev I just answered it there. Cheers, Doru > On Dec 5, 2017, at 4:44 PM, Moussa Saker via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > From: Moussa Saker <sak_moussa(a)yahoo.fr> > Subject: How to get a Moose Model > Date: December 5, 2017 at 4:44:31 PM GMT+1 > To: "pharo-dev(a)lists.pharo.org" <pharo-dev(a)lists.pharo.org> > Reply-To: Moussa Saker <sak_moussa(a)yahoo.fr> > > > Hello everyone > > we are working on a Moose project and we need a script to import the Moose Model, right now we use: > > MooseModel root first , > > but it's not really practical, Any suggestions ? > > Moussa Saker > LISCO Laboratory > Badji Mokhtar-Annaba University, > P.O. Box 12, Annaba 23000, Algeriai n > > -- www.tudorgirba.com www.feenk.com "To lead is not to demand things, it is to make them happen."

7 years, 7 months

1
0
0 0

GT-Inspector Meta Tab = Awesome!

by Sean P. DeNigris

The method source looks just like a browser's source pane, except… self is bound to the instance! So, you can for example evaluate instance-side methods by selecting the code and DoingIt. Sooo cool :) ----- Cheers, Sean -- Sent from: http://forum.world.st/Moose-f1310756.html

7 years, 7 months

2
3
0 0

feenk log

by Tudor Girba

Hi, Here is an update of the work on Bloc and GT: Bloc: - Bezier curves (cubic and quadratic). https://twitter.com/feenkcom/status/934765444464021504 https://twitter.com/feenkcom/status/934856909001252865 - Dragging is now possible through a BlDragHandler that can be attached to any element. - Pixel accurate line heads and tails https://twitter.com/feenkcom/status/936704646290305025 - More flexible scalable element. https://twitter.com/feenkcom/status/934003681539907585 - Improved scalability of the rendering. For example, on Mac, we are on par with the speed of Firefox. https://twitter.com/feenkcom/status/931462535861108736 - Sparta is now able to load custom fonts. https://twitter.com/feenkcom/status/930919637214285824 - Text insertion works now much better. Deletion and Selection still require more work. - The rope data structure can now be better inspected. https://twitter.com/feenkcom/status/937298739584172032 - Sparta/Moz2D has a visual loader that also provides more specific details in case of errors. https://twitter.com/feenkcom/status/936501909581688832 - Moz2D is now installed by default on Linux 64b. GT: - The GT Visualizer sub-project now contains two tools: -- GT Mondrian is a graph visualization engine that is both performant and shows how Bloc works well for visualizations. More details in a follow up post. https://twitter.com/feenkcom/status/937682660704563202 -- GT Connector is a new tool for browsing connected examples. More details about it in a follow up post. https://twitter.com/feenkcom/status/936109463462965248 Enjoy, The feenk team -- www.tudorgirba.com www.feenk.com "If you can't say why something is relevant, it probably isn't."

7 years, 7 months

2
1
0 0

start of the begining of a Fortran-to-MSE parser

by Nicolas Anquetil

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 nicolas -- Nicolas Anquetil RMod team -- Inria Lille

7 years, 7 months

1
0
0 0

Re: Cyclomatique Complexity

by abdelghani ALIDRA

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] and not ^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 :) Abdelghani 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 wrote: 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) nicolas On 12/11/2017 18:11, Stéphane Ducasse wrote: Normally cyclo is the number of paths so 1 for the true (the main flow) + on for the true and the or: the alternative flow. Stef | | | CQSE Blog - McCabe's Cyclomatic Complexity and Why We Don't Use It | | |

7 years, 7 months

1
0
0 0

Cyclomatique Complexity

by Alidra Abdelghani

Hi, 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 SomeClass>>aMethod ^true or:false equals 2 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

7 years, 7 months

4
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev