- Moose-dev - INF Mailman

by Alexandre Bergel

Dear Colleagues and Friends, It is a great pleasure to announce the release of Agile Visualization. Agile Visualization is a book about the Roassal Visualization engine. Paperback, eBook (PDF), and a free HTML format chapters are available from http://AgileVisualization.com The book has 235 pages and covers the essential aspects of Roassal. Copies of the book will be sold at ESUG’16. Screenshots and codes contained in the book were produced on Pharo. However, most of the covered code and topics _equally_run on VisualWorks (from version 7.4 (!)). We would like to thank all the contributors and users of Roassal who have deeply impacted and shaped Agile Visualization. The book is dedicated to the Smalltalk community at large. Big big thanks to our sponsors, Lam Research, Object Profile, and ESUG. And thanks to you for being as you are and making Smalltalk such a great platform. Thanks Alexandre

8 years, 10 months

9
11
0 0

moose 6.1 on top of pharo 6.0

by Tudor Girba

Hi, I moved all development CI jobs to Pharo 6.0: https://ci.inria.fr/moose/view/Moose%206.1/ The job for Moose 6.0 now loads the #stable version: https://ci.inria.fr/moose/view/Moose%206.0/job/moose-6.0/ Cheers, Doru -- www.tudorgirba.com www.feenk.com "Some battles are better lost than fought."

8 years, 10 months

1
0
0 0

Re: Moose-dev Digest, Vol 120, Issue 10

by Meinert Schwartau

Hi Tudor, > > Very interesting. This is the first time I heard of lombok, and I would > have to look into it more closely. What I find strange is that you get to > visit the method (this is where you get the unresolved method declaration > from) even if the method does not exist. I am sure I do not understand > something. Would you like to open an issue for this? > > Actually the lombok issue resolved itself. I found out that lombok provides a delombok functionality (https://projectlombok.org/features/delombok.html ): "Delombok [...] allows you to use lombok with these tools by preprocessing your java code into java code with all of lombok's transformations already applied. [...] Delombok's standard mode of operation is that it copies an entire directory into another directory, recursively, skipping class files, and applying lombok transformations to any java source files it encounters." So I just have analyse my delomboked source files instead of the original source files and everything will be fine. > > The cause of the next problem is that we have multiple smaller > applications (e.g. backoffice and frontend) which are separate applications > but share a common db. Some of these services have classes with the same > class and packagename (e.g. an annotation WebController). This lead to the > following error message: > > unresolved annotation type declaration - WebController - > c:\data\moose\....\WebController.java - line 12 > > I had to start the debugger to find the issue. I found it because > AnnotationTypeDeclaration.parent.problems = "Pb(323) The type > WebController is already defined" > > If the package names are different the problems disappears. Then I only > get the the lombok errors. As a solution I will create unique base package > names for my projecfs (which makes sense anyway). > > Indeed. The only other solution for this problem is to analyze each > sub-project separately. Also, perhaps I can manage to create a better log > statement for this case. Would you like to open an issue on github for this? > > > > Note that you could the following example to you README of jdt2famix to > show how to download the dependencies for gradle projects: > > > > task copyDependencies(type: Copy) { > > from configurations.compile > > from configurations.testCompile > > into 'dependencies’ > > } > > Thanks! > > Could you also tell me how to actually add this to a gradle script and > invoke it? I tried a variation of this (without > configurations.testCompile), but I did not manage to run it. I am likely > missing something basic here, and perhaps if you would walk me through a > concrete example, I could make some progress :). For example, what steps > would you use for downloading the dependencies of > https://github.com/spring-projects/spring-framework ? > > Cheers, > Doru > > Actually I tested it with the spring gradle file and it worked. The spring build file is a little bit more complicated, because it is a multimodule project. Basically an easy way to find the right place is to define it directly after the dependencies of the java projects. I added it as follows to the configure (allprojects) section: configure(allprojects) { project -> group = "org.springframework" version = qualifyVersionIfNecessary(version) // .... task copyDependencies(type: Copy) { from configurations.compile into 'dependencies' } } If you have a simple project (not a multi module one), there won't exist such a configure method. Then you can define it directly (e.g. after the dependencies). I attached my spring gradle build file to this mail. In my company project, which is a multi module project too, I added it to a configure method which is used for all java projects (we have some non java projects too). If I added to a configure method which is called for all projects due to the non java projects I would get an error. So it seems as if you always have to change you build files and as if there doesn't exist a general solution (like there exists one for maven). But I'm not a gradle expert, so there might exist a better solution. Best regards Meinert

8 years, 10 months

1
0
0 0

[ann] moose 6.0

by Tudor Girba

Hello everyone, We are happy to announce version 6.0 of the Moose Suite, the platform for software and data analysis built in Pharo: http://moosetechnology.org/#install Description --- The key highlights are: - It is based on Pharo 5.0 including the latest version of the Glamorous Toolkit. - It includes the SmaCC parsing framework together with parsers and abstract syntax trees for Java, JavaScript and Swift. - Roassal2 comes with several enhancements. - Famix features a new and generic query API engine. - Moose Finder and GTInspector come with more custom presentations and visualizations. - SmaCC comes with a dedicated debugger. - The debuggers for Glamour, PetitParser and Announcements received a new update. - DeepTraverser is an order of magnitude faster. Extra highlights: - Roassal2 is documented in a brand new book: http://agilevisualization.com - jdt2famix is a new open-source importer for Java: https://github.com/girba/jdt2famix Installation --- The Moose Suite 6.0 comes for each platform as a separate bundle: - For Mac: http://moosetechnology.org/res/download/moose_suite_6_0-mac.zip - For Windows: http://moosetechnology.org/res/download/moose_suite_6_0-win.zip - For Linux: http://moosetechnology.org/res/download/moose_suite_6_0-linux.zip The Moose Suite 6.0 can also be loaded in a Pharo 5.0 image either from the Configuration Browser, or by executing the following script: Metacello new smalltalkhubUser: 'Moose' project: 'Moose'; configuration: 'Moose'; version: #stable; load. Enjoy, The Moose team

8 years, 10 months

3
2
0 0

Re: Problems with mondorian

by Meinert Schwartau

Hi Tudor, there are two types of problems in the jdt2famix-import.problems file. My project uses Lombok to generate getter, setters and builders and so on (which is quite commmon for java projects). Because of that, some methods can't be found. Consider the following classes: ---------------------------------------- import lombok.Builder; @Builder public class Address { private String postalCode; } ---------------------------------------- import lombok.AccessLevel; import lombok.NoArgsConstructor; @NoArgsConstructor(access = AccessLevel.PRIVATE) public class AddressBuilder extends Address.AddressBuilder { public static AddressBuilder anAddressBuilder() { return new AddressBuilder(); } public Address.AddressBuilder withDefaultValues() { return this.postalCode("23456"); } } ----------------------------------------- I get the following error: unresolved method declaration - withDefaultValues - c:\data\moose\...\AddressBuilder.java - line 12 This error message and its line number (line number 12 is the method header "Address.AddressBuilder withDefaultValues ...") are misleading because at first I thought that the hole method is missing. But it only means that in this method an unresolved method is used. Furthermore I wonder if it were possible to support lombok? The cause of the next problem is that we have multiple smaller applications (e.g. backoffice and frontend) which are separate applications but share a common db. Some of these services have classes with the same class and packagename (e.g. an annotation WebController). This lead to the following error message: unresolved annotation type declaration - WebController - c:\data\moose\....\WebController.java - line 12 I had to start the debugger to find the issue. I found it because AnnotationTypeDeclaration.parent.problems = "Pb(323) The type WebController is already defined" If the package names are different the problems disappears. Then I only get the the lombok errors. As a solution I will create unique base package names for my projecfs (which makes sense anyway). Note that you could the following example to you README of jdt2famix to show how to download the dependencies for gradle projects: task copyDependencies(type: Copy) { from configurations.compile from configurations.testCompile into 'dependencies' } Best regards Meinert -----Original Message----- From: Tudor Girba [mailto:tudor@tudorgirba.com] Sent: Thursday, August 11, 2016 10:41 PM To: Moose-related development Subject: [Moose-dev] Re: Problems with mondorian Hi, Great. I am happy it works for you. Still, could you tell me if you get any problems reported in jdt2famix-import.problems when you parse your system? Cheers, Doru > On Aug 11, 2016, at 6:12 PM, Meinert Schwartau <m.schwartau(a)gmail.com> wrote: > > Thanks. After downloading the current Moose version and using the > other method you suggested it works for me :-) > > Thank you for providing the Java parser. > > Best regards > Meinert > > > Am 10.08.2016 um 16:36 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > > > > Hi, > > > > I now fixed the providerTypes error (including a test). Please try with the latest Moose 6.0 image. > > > > Cheers, > > Doru > > > > > >> On Aug 10, 2016, at 3:49 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> > >> Hi, > >> > >> Welcome back :) > >> > >>> On Aug 10, 2016, at 9:04 AM, Meinert Schwartau <m.schwartau(a)gmail.com> wrote: > >>> > >>> Hi, > >>> > >>> I want to display the dependencies between my classes. I wonder why the following code does not work, it displays the classes in a circle but not the edges between them. I’m using Moose 6 und Pharo 5 (downloaded yesterday) and evaluated the following code in the moose panel in the evaluator: > >>> > >>> |view| > >>> view := RTMondrian new. > >>> view nodes: ArrayedCollection withAllSubclasses. > >>> view edges: (ArrayedCollection withAllSubclasses) from: [ :cls | cls yourself ] to: [ :cls | cls referencedClasses ]. > >>> view circleLayout. > >>> view > >> > >> In your script, from:to: connects one source node with one target node returned by evaluating the corresponding blocks. However, your to: blocks return a collection, and the engine will try to find a node that has that collection as a model. > >> > >> What you want is to iterate over all items in the collection and connect the source node to each of the target nodes. > >> > >> To this end, you should use toAll: > >> > >> |view| > >> view := RTMondrian new. > >> view nodes: ArrayedCollection withAllSubclasses. > >> view edges source: (ArrayedCollection withAllSubclasses) connectFrom: [ :cls | cls yourself ] toAll: [ :cls | cls referencedClasses ]. > >> view circleLayout. > >> view > >> > >>> > >>> Then I tried to display the dependencies between my own classes (parsed by jdt2famix) but got an exception. After clicking on All classes in the moose panel I entered the following code in the evaluator: > >>> |view allClasses| > >>> view := RTMondrian new. > >>> allClasses := self allClasses. > >>> view nodes: allClasses. > >>> view edges: allClasses from: [ :cls | cls yourself ] to: [ :cls | cls providerTypes]. > >>> view circleLayout. > >>> view > >>> > >>> If I execute the code above, I get an “MessageNotUnderstood: reveiver of “atScope:” is nil” exception. If I remove the “view edges: allClasses from: [ :cls | cls yourself ] to: [ :cls | cls providerTypes].” statement I don’t get an exception, the RTMondorian view opens, but no classes are displayed as dots in the view. > >> > >> Indeed, thanks for reporting. > >> > >> I also noticed a bug in MooseQuery during the computation of messages like providerTypes. The problem appears when the opposite part of a relationship is nil. For example, when you have an invocation and the target cannot be resolved, the invocation will point to nil, and Moose gets unhappy. This is a problem in Moose and we need to solve it. > >> > >> Cheers, > >> Doru > >> > >> > >>> Any suggestions? > >>> > >>> Best regards > >>> Meinert > >>> > >>> > >>> _______________________________________________ > >>> Moose-dev mailing list > >>> Moose-dev(a)list.inf.unibe.ch > >>> https://www.list.inf.unibe.ch/listinfo/moose-dev > >> > >> -- > >> www.tudorgirba.com > >> www.feenk.com > >> > >> "If you can't say why something is relevant, it probably isn't." > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "From an abstract enough point of view, any two things are similar." > > > > > > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.tudorgirba.com www.feenk.com "Not knowing how to do something is not an argument for how it cannot be done."

8 years, 10 months

2
1
0 0

Problems with mondorian

by Meinert Schwartau

Hi, I want to display the dependencies between my classes. I wonder why the following code does not work, it displays the classes in a circle but not the edges between them. I’m using Moose 6 und Pharo 5 (downloaded yesterday) and evaluated the following code in the moose panel in the evaluator: |view| view := RTMondrian new. view nodes: ArrayedCollection withAllSubclasses. view edges: (ArrayedCollection withAllSubclasses) from: [ :cls | cls yourself ] to: [ :cls | cls referencedClasses ]. view circleLayout. view Then I tried to display the dependencies between my own classes (parsed by jdt2famix) but got an exception. After clicking on All classes in the moose panel I entered the following code in the evaluator: |view allClasses| view := RTMondrian new. allClasses := self allClasses. view nodes: allClasses. view edges: allClasses from: [ :cls | cls yourself ] to: [ :cls | cls providerTypes]. view circleLayout. view If I execute the code above, I get an “MessageNotUnderstood: reveiver of “atScope:” is nil” exception. If I remove the “view edges: allClasses from: [ :cls | cls yourself ] to: [ :cls | cls providerTypes].” statement I don’t get an exception, the RTMondorian view opens, but no classes are displayed as dots in the view. Any suggestions? Best regards Meinert

8 years, 10 months

4
7
0 0

Fwd: Re: Problems with mondorian

by Meinert Schwartau

Thanks. After downloading the current Moose version and using the other method you suggested it works for me :-) Thank you for providing the Java parser. Best regards Meinert > Am 10.08.2016 um 16:36 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > > Hi, > > I now fixed the providerTypes error (including a test). Please try with the latest Moose 6.0 image. > > Cheers, > Doru > > >> On Aug 10, 2016, at 3:49 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> Welcome back :) >> >>> On Aug 10, 2016, at 9:04 AM, Meinert Schwartau <m.schwartau(a)gmail.com> wrote: >>> >>> Hi, >>> >>> I want to display the dependencies between my classes. I wonder why the following code does not work, it displays the classes in a circle but not the edges between them. I’m using Moose 6 und Pharo 5 (downloaded yesterday) and evaluated the following code in the moose panel in the evaluator: >>> >>> |view| >>> view := RTMondrian new. >>> view nodes: ArrayedCollection withAllSubclasses. >>> view edges: (ArrayedCollection withAllSubclasses) from: [ :cls | cls yourself ] to: [ :cls | cls referencedClasses ]. >>> view circleLayout. >>> view >> >> In your script, from:to: connects one source node with one target node returned by evaluating the corresponding blocks. However, your to: blocks return a collection, and the engine will try to find a node that has that collection as a model. >> >> What you want is to iterate over all items in the collection and connect the source node to each of the target nodes. >> >> To this end, you should use toAll: >> >> |view| >> view := RTMondrian new. >> view nodes: ArrayedCollection withAllSubclasses. >> view edges source: (ArrayedCollection withAllSubclasses) connectFrom: [ :cls | cls yourself ] toAll: [ :cls | cls referencedClasses ]. >> view circleLayout. >> view >> >>> >>> Then I tried to display the dependencies between my own classes (parsed by jdt2famix) but got an exception. After clicking on All classes in the moose panel I entered the following code in the evaluator: >>> |view allClasses| >>> view := RTMondrian new. >>> allClasses := self allClasses. >>> view nodes: allClasses. >>> view edges: allClasses from: [ :cls | cls yourself ] to: [ :cls | cls providerTypes]. >>> view circleLayout. >>> view >>> >>> If I execute the code above, I get an “MessageNotUnderstood: reveiver of “atScope:” is nil” exception. If I remove the “view edges: allClasses from: [ :cls | cls yourself ] to: [ :cls | cls providerTypes].” statement I don’t get an exception, the RTMondorian view opens, but no classes are displayed as dots in the view. >> >> Indeed, thanks for reporting. >> >> I also noticed a bug in MooseQuery during the computation of messages like providerTypes. The problem appears when the opposite part of a relationship is nil. For example, when you have an invocation and the target cannot be resolved, the invocation will point to nil, and Moose gets unhappy. This is a problem in Moose and we need to solve it. >> >> Cheers, >> Doru >> >> >>> Any suggestions? >>> >>> Best regards >>> Meinert >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)list.inf.unibe.ch >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "If you can't say why something is relevant, >> it probably isn't." > > -- > www.tudorgirba.com > www.feenk.com > > "From an abstract enough point of view, any two things are similar." > > > > >

8 years, 10 months

2
1
0 0

Moose best practices / workflow

by Meinert Schwartau

Hi! Currently I have three questions: I want to declare my own methods like isJunitTest, isBookingClass, isMasterdataClass, isGeneratedClass and so on to filter and visualize my classes. As far as I read it these new methods should be added to existing classes. So in my case because they belong to a class to FamixClass. But these extensions should be stored in a separate package. How do you do it? Is there an example in the web how to do this in pharo? How do you save your visualizations and queries? Using the moose panel is nice for prototyping. But in the end I would like to create a menu entry, or a new entry in the moose panel on which somebody can click and sees the result of the query I created. Any suggestions for storing my code in a git repository. It seems not to be so easy like it should be (see http://stackoverflow.com/questions/25722280/pharo-project-on-git) Best regards Meinert

8 years, 10 months

3
2
0 0

configuration of famix

by Tudor Girba

Hi, I extended the excellent work of Cyril, and now all Famix related code (including tests) is in ConfigurationOfFamix. We now have 10 failures, but these were failing before as well. Now, the ConfigurationOfMoose contains only 10 packages that are related to the UI and visualization (and one for Moose-Help). I would consider creating a separate configuration for those packages, and leave in the ConfigurationOfMoose only the Moose-Help. Please take a look, and let me know if you see something broken (e.g., missing code). For reference, here is how the configuration looks like now: Cheers, Doru -- www.tudorgirba.com www.feenk.com "It's not what we do that matters most, it's how we do it."

8 years, 10 months

2
3
0 0

[ann] jdt2famix 1.0.2

by Tudor Girba

Hi, I created a minor release that adds more robust error handling for three edge-case issues: https://github.com/girba/jdt2famix/releases/tag/1.0.2 Cheers, Doru -- www.tudorgirba.com www.feenk.com "Being happy is a matter of choice."

8 years, 10 months

2
4
0 0

strange errors in jenkins jobs

by Tudor Girba

Hi, Since yesterday, all Moose-related jobs are failing. These are built on top of Pharo 5.0 stable, downloaded like this: wget --quiet -O - http://get.pharo.org/50+vm | bash We did not change anything in the projects that fail, and locally on Mac, I can load any of the code without problems. The jobs are running Linux. So, I am wondering if anything else has changed in Pharo 5.0. In particular, the error is quite strange. It looks like this: [31mError: MessageNotUnderstood: receiver of "finish" is nil [0mUndefinedObject(Object)>>error: [ :err :rcvr | | errCtx errMorph | errCtx := thisContext. [ errCtx := errCtx sender. "Search the sender chain to find the morph causing the problem" [ errCtx notNil and: [ errCtx receiver isMorph not ] ] whileTrue: [ errCtx := errCtx sender ]. "If we're at the root of the context chain then we have a fatal drawing problem" errCtx ifNil: [ ^ self handleFatalDrawingError: err ]. errMorph := errCtx receiver. ... See more at: https://ci.inria.fr/moose/job/fame/1266/console Any idea of what might be wrong? Cheers, Doru -- www.tudorgirba.com www.feenk.com "We cannot reach the flow of things unless we let go."

8 years, 11 months

2
2
0 0

reasonably stable image - release target next week

by Tudor Girba

Hi, The Moose image is back to a reasonable state. Next is to look at the ConfigurationOfFamix and see how to integrate it. Please take a look and let me know if you see any problems. Cheers, Doru -- www.tudorgirba.com www.feenk.com "Every successful trip needs a suitable vehicle."

8 years, 11 months

1
0
0 0

RTLabel does not implement trachelShapeClass

by Johan Fabry

And another one. That's not cool :-/ At some point I get to RTLabel>>trachelShapeForOneLine: which does a self trachelShapeClass but that is not defined there, so it goes to RTShape where it is implemented as self subclassResponsibility. -- Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please see http://emailcharter.org . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

8 years, 11 months

3
6
0 0

[ann] jdt2famix 1.0.1

by Tudor Girba

Hi, I am happy to announce the first release of jdt2famix (1.0.1): https://github.com/girba/jdt2famix/releases/tag/1.0.1 http://www.humane-assessment.com/blog/jdt2famix-1.0.1 It is available as a standalone binary and can be used directly. Cheers, Doru -- www.tudorgirba.com www.feenk.com "It's not how it is, it’s how we see it."

8 years, 11 months

2
1
0 0

RTAbstractLine>>width: MNU

by Johan Fabry

Hi all, I get an MNU on the following code: RTLine new width: 2 This is because widthElement: is not implemented. It’s called here: RTAbstractLine>> width: aBlockOrValue "Set the width of the shape" self widthElement: [ :e | aBlockOrValue rtValue: e model ]. Is there a quick workaround that I can do while I wait for this to be fixed? -- Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please see http://emailcharter.org . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

8 years, 11 months

4
3
0 0

jdt2famix - logging problems

by Tudor Girba

Hi, I added a new feature: explicit logging of problems encountered during import. These problems do not stop the import, but they do lead to loss of information quality in the model. These problems are typically due to missing jars in the classpath. However, if you know which parts are problematic, you get a chance of fixing them. To give you an example, entries might look like this: unresolved type declaration - TestPlatform - /Users/girba/Work/Code/jdt2famix/tmp/guava/guava-tests/test/com/google/common/math/TestPlatform.java - line 21 unresolved method declaration - suite - /Users/girba/Work/Code/jdt2famix/tmp/guava/guava-tests/test/com/google/common/primitives/ByteArrayAsListTest.java - line 51 For example, in the case of guava, importing just the checked out code, gives us 419 problems, most of which were method declaration problems (due to unknown return types). However, after downloading all jars from the maven dependencies, we got only 47 problems (only type declaration problems, but no more method declaration problems). Interestingly, guava is made out of several sub-projects, and these problems appear if we import the overall project. But, if we import only a subproject at a time, the problems do not appear anymore, so likely the issue is related to conflicting jars, or duplicated sources. The point is that having an insight on what problems are encountered can provide a hint of how to act to improve the quality of the resulting model. The logging support is quite rudimentary right now, and I will likely build on this, but it already offers an added value. Cheers, Doru -- www.tudorgirba.com www.feenk.com "Reasonable is what we are accustomed with."

8 years, 11 months

1
0
0 0

jdt2famix beta

by Tudor Girba

Hi, I am happy to announce that jdt2famix reached a beta version. I consider that the coverage of entities that we can import is essentially complete. I am sure there are still edge cases to hunt for (both in terms of error handling and import semantics), and that is what I would like to look at. So, if you can, now is the time to try again to play again with it :). Cheers, Doru -- www.tudorgirba.com www.feenk.com "Don't give to get. Just give."

8 years, 11 months

2
3
0 0

new version of FamixGenerator

by Thomas Haug

Hi everybody I just released a new version (1.0.0) of the FamixGenerator for .NET assemblies: http://www.sharpmetrics.net/index.php/famix-generator I have fixed a couple of issues (especially with handling of generic classes and types). Cheers Thomas

8 years, 11 months

6
12
0 0

Re: [Pharo-dev] Ask HN: Examples of elegant, non-trivial Smalltalk? | Hacker News

by Serge Stinckwich

On Fri, Jul 29, 2016 at 2:23 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Hi Sven, > > I'd put RB + SmaCC among the lot. But I consider that really non-trivial : > the pattern language of RB (and the underlying pattern matching and > unification algorithm) is top notch, and how SmaCC builds on RB to virtually > generate code / optimise code / then compile is nothing short of amazing. > > SmaCC comes with a pattern matching/unification algorithm over ASTs + > auto-generation of AST code + visitor + tree equality + the equivalent of > Flex/Bison(*) + a GUI in 11401 lines of code. SmaCC deserves definitively more advertisements and should be added to MOOSE platform I think. When I see all the buzz around languages workbenches like Rascal: https://www.youtube.com/watch?v=Ffx7VtEOSx4 with MOOSE+RB+SmaCC+Reflectivity+GTools we are close to these tools (or even better). Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

8 years, 11 months

4
3
0 0

still a problem with the debugger...

by Alexandre Bergel

Hi! Currently, I cannot use the moose image. Some classes are missing. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

8 years, 11 months

1
0
0 0

MOOSE job on travis

by Serge Stinckwich

Dear all, I have now a travis job running for Moose here: https://travis-ci.org/moosetechnology/Moose/jobs/147971040 with the same tests than on Jenkins: https://ci.inria.fr/moose/job/moose-6.0/ But strangely, there is some errors on the travis job that do not appear on Jenkins. listBackgroundColor message is send to Pharo3Theme, but there is no message like that in Pharo 5.0 … Any ideas why ? -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

8 years, 11 months

4
6
0 0

A MOOSE open book

by Serge Stinckwich

hi all, books are successful products of the Pharo community. We have now something like 5 books and the new Agile Visualisation book should be out soon. Can we try to push an open book about MOOSE ? There is already some materials available here: http://www.themoosebook.org/ but the contents is quite obsolete now. Can we open it and release the contents on github ? Thank you. -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

8 years, 11 months

4
4
0 0

[ann] jdt2famix standalone - alpha version

by Tudor Girba

Hi, I am happy to announce that I now obtained a reasonable first beta stage of a standalone jdt2famix Java importer. This is implemented in Java, it works from the command line and has a similar structure to VerveineJ (the previous solution relied on JNIPort, but that did not scale well due to 32bits and needs rethinking). It is based on FameJava and JDT, and it is available under EPL2. The model is a new Famix version generated out of the Pharo meta-descriptions. To this end, I extended a bit the tool support around Fame and I will follow up with some details one that. Here is the repository including some basic info: https://github.com/girba/jdt2famix The importer was created through fine-grained tests, there are some 100 of them right now, and the coverage of the importer is more than 93%. However, there are still things to do: - finish the coverage of the imported entities (see below). - improve the error handling. As Java has a ton of edge cases, it would be great if you would use it to parse your systems and report possible errors. We would then manufacture test cases out of those. - check the semantics of the produced data (possibly by comparing with VerveineJ). - find a better way to package the application. - integrate in Moose with one click. Ideally, even downloading the application should be doable directly from Moose. The goal here is to make jdt2famix part of the Moose 6 release. As a deadline, I am targeting August 1 for a beta version, and August 10 for a Moose 6.0 release. Please let me know what you think, and most importantly please give it a try and provide feedback. Here is a detailed list of what works and what is left to do: ✓Namespace ✓Type ✓Type without binding ✓Inheritance without binding ✓Interface ✓Parameterizable Class ✓ParameterizedType ✓Method ✓Constructor ✓Visibility (public, private, protected, package) ✓Parameter ✓Method signature ✓Local variable ✓Attribute ✓Anonymous Class ✓Anonymous Class with Parameterized Type ✓Invocation ✓Super invocation ✓Constructor Invocation ✓Super constructor invocation ✓Class instantiation ✓Class initializer ✓Invocation receiver ✓Field read access in invocation receiver ✓Field read access in invocation parameter ✓Field read access in class instantiation ✓Field read access in assignment ✓Field read access in super invocation parameter ✓Field write access in assignment ✓Local write access in assignment ✓Local read access in invocation receiver ✓Local read access in invocation parameter ✓Local read access in super invocation parameter ✓Local read access in super constructor parameter ✓Read access through return ✓Read accesses in: do, while, if, for, switch, enhanced for, conditional (?:) ✓Read access in synchronized ✓Attribute initializer ✓Read access in attribute initializer ✓Read access to qualified enum value ✓Read access to qualified attribute ✓Parentheses ✓Enum ✓EnumValue ✓Array types [] ✓AnnotationType ✓AnnotationType attributes ✓AnnotationInstance for types ☐AnnotationInstance for attributes ☐AnnotationInstance for methods ☐AnnotationInstance for parameters ☐Generic Type in Method scope ☐Class reference ☐Inner Class ☐Wildcard types <?> ☐ThrownException ☐CaughtException ☐DeclaredException ☐SourceAnchor ☐Array Access ☐Comments ☐Implicit variables ☐Lambda variables Cheers, Doru -- www.tudorgirba.com www.feenk.com "One cannot do more than one can do."

8 years, 11 months

6
16
0 0

Re: [ann] jdt2famix standalone - alpha version

by Meinert Schwartau

> > > > ---------- Weitergeleitete Nachricht ---------- > From: Tudor Girba <tudor(a)tudorgirba.com> > To: Moose-related development <moose-dev(a)list.inf.unibe.ch> > Cc: > Date: Tue, 19 Jul 2016 07:41:05 -0600 > Subject: [Moose-dev] [ann] jdt2famix standalone - alpha version > > > improve the error handling. As Java has a ton of edge cases, it would be > great if you would use it to parse your systems and report possible errors. > We would then manufacture test cases out of those. > I'll definitely give it a try. Because the number of people who'll try this out will be limited, to be sure that there aren't any bugs in this parser I suggest that we let it parse all java github projects. Then we could group the resulting errors (if there exists any ;-)) per error type, write tests for these edge cases and then fix them. If all of the java git hub projects can per parsed without errors then we could be really sure this parser can is at least to parse the edge cases without exceptions. For sure, we don't know if the result makes sense but at least it produces a result. Getting the download url for all java github projects is very easy: https://api.github.com/search/repositories?q=language:Java Further optional parameters for this url for paging: {&page,per_page,sort,order}. Documentation for this request: https://developer.github.com/v3/search/#search-repositories How do you think about it? Best regards Meinert

8 years, 11 months

4
8
0 0

Moose and Pharo?

by Alexandre Bergel

Hi! Does the moose build uses Pharo 6? It does not look like… How to make Moose loads in Pharo 6? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

8 years, 11 months

14
31
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev