Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

[Jdt2Famix] Parsing of innerclasses creates unamed methods

by Blondeau Vincent

Hi, By generating some models with the Jdt2Famix java parser, I rose an issue with the anonymous classes. It appears that some methods and classes generated have no name (i.e. getName() = ""). For instance, this code: public static void method(String name) { Comparator<String> comparator = new Comparator<String>() { @Override public int compare(String string1, String string2) { return string1.toString().compareTo(string2.toString()); } }; } should model a stub constructor: Comparator. But, there is no such method and only an empty method belonging to the container class is created. Consequently, it is harder to find them in the model ... I opened an issue https://github.com/girba/jdt2famix/issues/34 and added some tests that you can found in the PR: https://github.com/girba/jdt2famix/pull/33 Can someone take a look at this problem? Thanks in advance, Cheers, Vincent !!!************************************************************************************* "Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!"

8 years, 2 months

BUG - MooseModel resetMeta

by Anne Etien

Hi, I am developing a tool based on Fame pragma. Considering the following methods: FAMIXSQLExpression >>referencedRequests <MSEProperty: #referencedRequests type: #FAMIXRequest opposite: #usedInExpression> <multivalued> <MSEComment: 'List of requests referenced by the expression.'> ^ referencedRequests FAMIXRequest >>usedInExpression <MSEProperty: #usedInExpression type: #FAMIXSQLExpression opposite: #referencedRequests> <MSEComment: 'Expression in which the request is used.'> ^ usedInExpression (FAMIXSQLExpression mooseDescription at: 'referencedRequests') hasOpposite should return true. However, I don’t have always the same behavior after each resetMeta. (1 to: 100) do: [ : e | MooseModel resetMeta. (FAMIXSQLExpression mooseDescription at: 'referencedRequests') hasOpposite ifFalse: [ 1halt ] ]. always halts, at some unpredictable iteration (usually less than 10) Does someone has any idea what is the problem and how to solve it? By the way, MooseSQL is available here https://ci.inria.fr/moose/job/MooseSQL/ <https://ci.inria.fr/moose/job/MooseSQL/> Thanks in advance for your help. Anne

8 years, 2 months

edges attach point issues with tree layout

by Tudor Girba

Hi, I have a tree layout scene and I am trying to add on top other edges that do not affect the layout and that should have a centered attach point. However, the edges are still being drawn from bottom to top, like the rest of the edges from the tree layout. I think this is a bug. What do you think? Here is the example: view := RTMondrian new. view shape label. view nodes: (1 to: 10). edges := view edges connectFrom: [ :x | x//2 ]. view layout tree userDefinedEdges: edges. view shape arrowedLine color: Color red; centeredAttachPoint. view edges source: {3->2 . 9->7} connectFrom: #key to: #value. view http://ws.stfx.eu/QX0KW6F3QYC0 Cheers, Doru -- www.tudorgirba.com www.feenk.com "Quality cannot be an afterthought."

8 years, 3 months

Did someone know how to install the libs on a slave of the Moose CI?

by Blondeau Vincent

Because it seems that the x32 libs are not installed : https://ci.inria.fr/moose/job/moose-6.1/461/console And that the Ubuntu node is down: https://ci.inria.fr/moose/computer/ BTW, can we upgrade the Jenkins to the next version? Thanks in advance, Cheers, Vincent !!!************************************************************************************* "Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!"

8 years, 3 months

happy and bold new year

by Tudor Girba

Happy New Year, everyone! Over the last year, I went through a rather extensive tour and I directly exposed Moose, GT and Pharo to some 2000+ technical people through various sessions and trainings at conferences and companies. The tour will continue this year. Most of the sessions are not directly about Moose, GT or Pharo, but about broader topics that are served through what we do around here. These topics can relate to solving problems without reading code, to steering agile architecture, or more recently, to even broader topics like software environmentalism. If you are wondering what software environmentalism is, please take a look at this talk: https://youtu.be/N3l3eB62oSw?list=PLqvTNJtc942Cs9Qo4ikCGrUNtAw93Q0JA I now have the confirmation that there is a whole space which is unaddressed by mainstream technologies. Often people find themselves frustrated having to build their systems on top of opaque technologies with not much hope of understanding what is going on under the hood both because they do not have access to what is behind and because they are provided lack the tools to investigate. You see, developers are suppose to have the coolest job on the planet, and many of them are unhappy. This has to change, and we can do that. In a conversation I had with a highly respected researcher, after explaining how our tools allow us to work, he noted reluctantly “so, you are claiming that you are practicing a fundamentally different software engineering?”. This question took me a little by surprise because the only answer I found myself being able to provide was “yes”. I sent him this talk: https://youtu.be/XWOOJa3kEa0?list=PLqvTNJtc942Cs9Qo4ikCGrUNtAw93Q0JA It is strange to be in the position to tell the world that we are constructing something fundamentally better, but I really do believe that we are. I wish you a happy and bold new year! Cheers, Doru -- www.tudorgirba.com www.feenk.com "Every thing should have the right to be different."

8 years, 3 months

Design Challenge: metrics missing value...

by stepharong

Hi dear great OO designers Here is a little challenges for your brainy souls :) In Moose when we compute metrics it may happen than a tool (often external to pharo) does not compute a metrics and when we request it in moose we check and often we return a not so good -1. I'm trying to brainstorm on a solution - first may be the simplest way is to not invoke a metrics when it is not computed. But it means that we should know it and that we should have a registration mechanism. After all this is probably the best solution. - Second we were thinking to use exception but when we have multiple entities missing one metrics.... I have serious doubts. - Second I was thinking about having the following behavior testCollect | uarray collected | uarray := UniformOrderedCollection new. uarray add: 10. uarray add: 20. uarray add: (MissingValue discarding). collected := uarray collect: [ :each | each ]. self assert: collected size equals: 2. testDo | res uarray | uarray := UniformOrderedCollection new. uarray add: 10. uarray add: 20. uarray add: (MissingValue discarding). uarray add: 40. res := 0. uarray do: [ :each | res := res + each ]. self assert: res equals: 70. testCollectDefaulting | uarray collected | uarray := UniformOrderedCollection new. uarray add: 10. uarray add: 20. uarray add: (MissingValue default: 33). collected := uarray collect: [ :each | each ]. self assert: collected size equals: 3. self assert: collected third equals: 33 I basically started to implement do: aBlock "Refer to the comment in Collection|do:." 1 to: self size do: [:index | (self at: index) toDo: aBlock on: self] collect: aBlock "Evaluate aBlock with each of the receiver's elements as the argument. Collect the resulting values into a collection like the receiver. Answer the new collection." | newCollection | newCollection := self species new. self do: [ :each | each toCollect: aBlock on: newCollection ]. ^ newCollection and DiscardingValue >> toCollect: aBlock on: aCollection "discard computation" ^ self Object >> toCollect: aBlock on: aCollection ^ aCollection add: (aBlock value: self) So I imagine that you see the design and I wanted to get your point of view. -- Using Opera a kind of bad mail client but far better than thunderbird

8 years, 3 months

Re: [Pharo-dev] happy and bold new year

by Tudor Girba

Hi, In my opinion, Pharo provides the strongest infrastructure for understanding a system from all technologies I have seen. So, if you say that Pharo is a bit "under featured in, then I think we are not referring to the same thing :). May I ask how you are using the inspector? For example: - do you extend the inspector? - do you construct visualizations about your system in the inspector? - do you write queries about code in the inspector? Cheers, Doru > On Jan 9, 2017, at 3:42 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > > I know this path of understanding code while it is running (inspector or > debugger), but it is still a tedious path, and I feel Pharo is a bit > under featured on that specific department, therefore my question on Moose. > > Hilaire > > > > Le 09/01/2017 à 15:09, Tudor Girba a écrit : >> That is why my advice is to not try too long to understand Pharo code statically because this is not where the power of Pharo is. You are in a much better position to understand a system when it’s running. So, the tools that I use the most are the inspector when I need to understand structural relationships or contracts between objects, and the debugger when I need to understand some algorithmic steps. Even when I look for code structure patterns, I mostly use the inspector because it allows me to query. Then you augment these tools with custom views and you get quite far. > > -- > Dr. Geo > http://drgeo.eu > > -- www.tudorgirba.com www.feenk.com "We can create beautiful models in a vacuum. But, to get them effective we have to deal with the inconvenience of reality."

8 years, 3 months

Re: [Pharo-dev] happy and bold new year

by Tudor Girba

Hi Hilaire, GT is essentially a project that takes the relevant parts of Moose and make them applicable to plain Pharo. Pharo ships with only the core tools, but the complete configuration of GT also brings with it Roassal and a couple of other goodies. There are still more interesting things in Moose, but you can get quite far with only GT. About your particular question, it’s true that Pharo does not have static types, but that does not make it harder to understand. Only different. The first thing to realize is that Pharo is not about code, but about objects. That is why my advice is to not try too long to understand Pharo code statically because this is not where the power of Pharo is. You are in a much better position to understand a system when it’s running. So, the tools that I use the most are the inspector when I need to understand structural relationships or contracts between objects, and the debugger when I need to understand some algorithmic steps. Even when I look for code structure patterns, I mostly use the inspector because it allows me to query. Then you augment these tools with custom views and you get quite far. I know this sounds abstract, but I am practicing this since several years and I still find it amazing. I tried to provide a hint of how it works in the ESUG 2016 talk. Cheers, Doru > On Jan 9, 2017, at 2:02 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > > Hello Doru, > > I am curious. > Yesterday I had a look to MessageBrowser, and realize I understand > nothing of it. I saw there is a mix of SpecXXX, models, Navigation > browser, Announcement, etc, then I knew I will have to spend a lot of > time browsing (multiple window again) to understand a bit how these > objects are related, and may be be able to change it in the way I want. > Does the Moose & al tools could help me understand code I don't know about? > > Given the fact Pharo/Smalltalk are not typed makes it harder for code > analysis, don't you? > > Happy new year to you too. > > Hiaire > > Le 09/01/2017 à 10:30, Tudor Girba a écrit : >> Happy New Year, everyone! >> >> Over the last year, I went through a rather extensive tour and I directly exposed Moose, GT and Pharo to some 2000+ technical people through various sessions and trainings at conferences and companies. The tour will continue this year. >> >> Most of the sessions are not directly about Moose, GT or Pharo, but about broader topics that are served through what we do around here. These topics can relate to solving problems without reading code, to steering agile architecture, or more recently, to even broader topics like software environmentalism. If you are wondering what software environmentalism is, please take a look at this talk: >> https://youtu.be/N3l3eB62oSw?list=PLqvTNJtc942Cs9Qo4ikCGrUNtAw93Q0JA >> >> I now have the confirmation that there is a whole space which is unaddressed by mainstream technologies. Often people find themselves frustrated having to build their systems on top of opaque technologies with not much hope of understanding what is going on under the hood both because they do not have access to what is behind and because they are provided lack the tools to investigate. You see, developers are suppose to have the coolest job on the planet, and many of them are unhappy. This has to change, and we can do that. >> >> In a conversation I had with a highly respected researcher, after explaining how our tools allow us to work, he noted reluctantly “so, you are claiming that you are practicing a fundamentally different software engineering?”. This question took me a little by surprise because the only answer I found myself being able to provide was “yes”. I sent him this talk: >> https://youtu.be/XWOOJa3kEa0?list=PLqvTNJtc942Cs9Qo4ikCGrUNtAw93Q0JA >> >> It is strange to be in the position to tell the world that we are constructing something fundamentally better, but I really do believe that we are. >> >> I wish you a happy and bold new year! >> >> Cheers, >> Doru >> > > -- > Dr. Geo > http://drgeo.eu -- www.tudorgirba.com www.feenk.com "If you can't say why something is relevant, it probably isn't."

8 years, 3 months

doing a pass on FAMIX-File

by Usman Bhatti

Hi, I am using FAMIXFile and FAMIXFolder for a project. There are a few things that I've improved. FAMIXAbstractFile defines a variable for belongsTo, I renamed this variable to parentFolder because AFAIK belongsTo is always derived information. I've implemented parentFolder as a FMMutlivalueLink. The opposite is childrenFileSystemEntities so that we've autoupdating back links. This change has made make existing files and folders inst vars and their accessors redundant. The selectors folder and files on a FAMIXFolder still exist but they are computed from childrenFileSystemEntities. IMO, the resulting solution is much more clean and more expressive. Let me know if there's a conceptual regression or some cases not covered. Usman

8 years, 3 months

Happy new year!

by Alexandre Bergel

Here is our traditional Roassal-flavored best wishes. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= points := Compiler evaluate: ' {(-225@ -206). (-225@ -196). (-228@ -185). (-228@ -174). (-230@ -164). (-218@ -182). (-209@ -182). (-197@ -182). (-190@ -207). (-192@ -194). (-190@ -187). (-192@ -170). (-190@ -161). (-180@ -161). (-176@ -171). (-167@ -185). (-162@ -197). (-151@ -208). (-143@ -202). (-140@ -193). (-124@ -164). (-136@ -183). (-133@ -175). (-159@ -181). (-150@ -181). (-142@ -181). (-97@ -165). (-101@ -181). (-101@ -193). (-103@ -206). (-104@ -210). (-88@ -211). (-77@ -210). (-80@ -199). (-89@ -193). (-61@ -171). (-63@ -182). (-64@ -213). (-67@ -200). (-64@ -191). (-54@ -207). (-38@ -210). (-54@ -190). (-40@ -188). (-35@ -195). (-35@ -200). (-42@ -207). (0@ -199). (0@ -194). (-6@ -179). (-4@ -185). (-10@ -171). (-11@ -163). (-17@ -201). (-13@ -194). (-9@ -190). (57@ -196). (58@ -190). (58@ -181). (58@ -176). (57@ -168). (62@ -193). (69@ -180). (68@ -183). (74@ -175). (80@ -163). (77@ -170). (80@ -172). (81@ -184). (81@ -197). (81@ -201). (95@ -198). (97@ -183). (97@ -162). (98@ -169). (97@ -172). (107@ -162). (116@ -162). (122@ -162). (103@ -178). (109@ -179). (101@ -198). (117@ -198). (111@ -198). (134@ -196). (151@ -179). (141@ -187). (154@ -170). (167@ -170). (176@ -200). (175@ -194). (160@ -195). (183@ -174). (171@ -181). (162@ -189). (187@ -181). (189@ -185). (197@ -198). (-147@ -105). (-156@ -98). (-156@ -89). (-163@ -82). (-165@ -94). (-180@ -111). (-174@ -103). (-167@ -74). (-134@ -102). (-137@ -89). (-135@ -79). (-136@ -73). (-126@ -67). (-119@ -68). (-122@ -86). (-128@ -84). (-128@ -102). (-119@ -102). (-99@ -72). (-86@ -102). (-92@ -96). (-96@ -88). (-77@ -99). (-62@ -75). (-73@ -88). (-63@ -75). (-54@ -67). (-91@ -81). (-86@ -79). (-77@ -79). (-29@ -61). (-33@ -109). (-33@ -96). (-32@ -88). (-32@ -82). (-32@ -75). (-31@ -71). (-22@ -101). (-14@ -101). (-9@ -89). (-15@ -86). (-25@ -86). (-19@ -80). (0@ -72). (-5@ -80). (-3@ -67). (-126@21). (-123@4). (-117@ -3). (-107@ -10). (-91@ -8). (-93@7). (-85@16). (-85@34). (-89@44). (-91@57). (-108@67). (-119@79). (-132@86). (-119@87). (-102@88). (-90@88). (-74@87). (-8@9). (-18@19). (-20@30). (-23@43). (-18@53). (-14@61). (-4@73). (6@78). (35@69). (38@55). (24@81). (15@82). (45@44). (37@35). (33@23). (24@14). (11@9). (2@7). (54@79). (66@69). (82@21). (74@56). (74@41). (78@39). (88@19). (88@28). (89@38). (90@79). (88@55). (89@49). (127@31). (131@21). (134@14). (152@10). (168@10). (177@13). (189@13). (192@14). (182@44). (188@35). (187@25). (171@56). (164@69). (152@82). (152@89). (141@93)}'. delta := 30. v := RTView new. b := [ :pos | e := (RTEllipse new color: (RTPalette c3 atRandom alpha: 0.8); size: 5 atRandom + 3) element. d := ((delta atRandom - (delta / 2)) @ (delta atRandom - (delta / 2))). e translateTo: pos + d. v add: e. v addAnimation: (RTAccelerationMove to: pos during: 10 on: e) ]. [points do: [ :p | b value: p. (Delay forSeconds: 0.1) wait ]] fork. v open -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Here is the result of a nice animation: Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

8 years, 3 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev