Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

saving moose model with voyage-mongo
by Usman Bhatti 05 May '14

05 May '14

Hello, I started to have a look to understand if Voyage can be used to save a moose model into a Mongo db. This script saves the model, which can be retrieved, modified and saved. |importer model1 | importer := MoosePharoImporterTask new. importer importingContext: (MooseImportingContext new importClass; importMethod; importAccess; importInvocation; importInheritance; mergeClassAndMetaclass; yourself). importer candidateClass: CandidateListOperator. importer importerClass: SmalltalkImporter. importer model: MooseModel new; addFromPackagesNamed: #(#'XML-Writer-Tests'); run. model1 := importer model. model1 name: 'a persistent model'. model1 privateState flush. model1 save MooseModel selectAll. To see the MooseModel instance that you just saved. Or you can see other objects: FAMIXClass selectAll If you want to try it: 1/ Install Mongo 2/ Gofer it url: 'http://smalltalkhub.com/mc/estebanlm/Voyage/main'; package: 'ConfigurationOfVoyageMongo'; load. (ConfigurationOfVoyageMongo project version: '1.2-baseline') load: 'Mongo'. 3/ Gofer it url: 'http://smalltalkhub.com/mc/usman/MooseVoyage/main'; package: 'MooseVoyageMongo'; load. (The package contains a few necessary extension methods to tell voyage to persist moose model and famix entities). 4/ repository := VOMongoRepository host: VOMongoRepository defaultHost database: 'moosedb'. repository enableSingleton. ======================== There are some issues though: - It takes a lot of time even to store even ordinary models. - I don't know yet how to serialize MooseGroups. I'll try to resolve them in my free time. Improvements will come from the new algorithm by Esteban to automatically break circular references in complex Graphs and he'll soon integrate and release it with Voyage 2 :). I hope this improves performance issues. For further info on Voyage, you can follow this book chapter: https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSucces… Please feel free to try/improve. regards, Usmanf

1 0

Jenkins build became unstable: moose-5.0 #1329
by admin＠moosetechnology.org 05 May '14

05 May '14

See <https://ci.inria.fr/moose/job/moose-5.0/1329/>

1 1

Graph builder
by Alexandre Bergel 05 May '14

05 May '14

Hi! Just to share a screenshot of what we are working on: Result of the script: =-=-==-=-==-=-==-=-==-=-= | b | b := RTGraphBuilder new. b nodes color: Color gray. b edges connectTo: #dependentClasses; color: (Color gray alpha: 0.1); if: [ :f :t | '*Example*' match: f name ] color: (Color green alpha: 0.2). b layout partition: [ :c | c inheritsFrom: RTTest ]; partition: [ :c | c inheritsFrom: RTLayout ]; partition: [ :c | c inheritsFrom: RTShape ]; partition: [ :c | c inheritsFrom: RTInteraction ]; partition: [ :c | c inheritsFrom: RTBuilder ]; partition: [ :c | '*Example*' match: c name ]; partition: true; force. b layout circle radius: 250. b global normalizeSize: [ :c | c dependentClasses size ] min: 5 max: 30 using: #sqrt. b addAll: (RTObject withAllSubclasses). b open =-=-==-=-==-=-==-=-==-=-= Comments are welcome! Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

1 0

Analyzing many large projects
by Alexandre Bergel 05 May '14

05 May '14

Hi! I am currently analyzing 80 Pharo applications for which I need to compute for each class of these 80 applications, the lcom2 and lcom3 metrics. Computing these metrics needs to have the attributes, methods, and access in the moose model. Which is rather heavy. I have tried to augment the memory setting given to the VM, but this does not work much. For now, I am trying to run moose as follows: /Users/alexandrebergel/Dropbox/PharoVM/Pharo.app/Contents/MacOS/Pharo -memory 5000m /Users/alexandrebergel/Downloads/moose-5-10/moose-5.0.image Is there an alternative to this? What I could do, is for each project, create a full model, call #lcom2 and #lcom3 on each class to compute the metric, and then trim out the model by removing what I do not need (everything except FAMIXClass). Is there an easy way to do such a transformation on a moose model? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 3

CFP: IEEE Software - 1st Special Issue on Release Engineering
by Bram Adams 05 May '14

05 May '14

[Apologies for duplicate reception of this CFP] IEEE SOFTWARE - 1ST SPECIAL ISSUE ON RELEASE ENGINEERING Submission Deadline: 1 August 2014 Publication: March/April 2015 More Information: http://releng.polymtl.ca/RELENG2014/html/SI.html Software used to be released in shrink-wrapped form, but the advent of agile methodologies and the web has overhauled the landscape. For example, a project like Mozilla Firefox releases every 6 weeks, generating updates for dozens of existing versions on 5 desktop, 2 mobile and 3 mobile desktop platforms, each of which for more than 80 locales. In other words, deployment of modern applications requires coordinating the release of applications on multiple mobile platforms, web platforms with centralized backend services, and native desktop clients. Furthermore, concepts like continuous delivery of software are no longer curiosities, but essential to retain a competitive edge. Release engineering deals with all activities in between regular development and actual usage of a software product by the end user, i.e., integration, build, test execution, packaging and delivery of software. Although research on this topic goes back for decades, the increasing heterogeneity and variability of software products along with the recent trend to reduce the release cycle to days or even hours starts to question some of the common beliefs and practices of the field. The IEEE Software Special Issue on Release Engineering solicits experience reports and papers on tools, methods, practices and techniques to streamline release engineering. We especially welcome submissions targeting recent challenges like continuous delivery and heterogeneous platform support, but the Special Issue is open to any of the following topics: * best practices for code movement (branching/integration) * continuous integration and testing * build and configuration of software * build system maintenance * testing and reporting infrastructures * package and dependency management * legal signoff and bill-of-materials * delivery and deployment of software * code signing and certificate management * continuous delivery, deployment, installation and software update * cloud provisioning and management * cloud service release management * interaction with app stores * mobile app release management * principles and automated techniques for release planning * release engineering for product line systems * devops and interaction with developers, end users, etc. * devops practices and tools * large-scale build and test farms * multi-platform build and test * feedback on continuous delivery and deployment The goals for this Special Issue are three-fold: * making researchers aware of the challenges and research opportunities, and practitioners aware of research in release engineering * sharing experiences with practical approaches, tools, methods and techniques for release engineering * building connections between different communities involved in release engineering. In an effort to engage with practitioners, one of the co-organizers of the Special Issue is a release engineer at Mozilla and one half of the reviewers will consist of release engineers, so we guarantee that each paper or abstract submission receives at least one review from a practitioner. Full submissions for the Special Issue must not exceed 5,400 words including figures and tables, which count for 200 words each. Submissions in excess of these limits may be rejected without refereeing. The articles we deem within the theme and scope will be peer-reviewed and are subject to editing for magazine style, clarity, organization, and space. We reserve the right to edit the title of all submissions. Be sure to include the name of the theme or Special Issue you are submitting for. We also solicit short “practice” papers from practitioners that contain experience reports. These papers do not need to make a research contribution, but should instead present the experiences of a practitioner or practitioners by describing things such as current release processes used, challenges faced, solutions attempted, and/or results obtained. Practice papers should not exceed 3,500 words. Articles should have a practical orientation and be written in a style accessible to practitioners. Overly complex, purely research-oriented or theoretical treatments are not appropriate. Articles should be novel. IEEE Software does not republish material published previously in other venues, including other periodicals and formal conference/workshop proceedings, whether previous publication was in print or in electronic form. For more information about the focus, please contact the Guest Editors: * Bram Adams (http://mcis.polymtl.ca/bram.html), Polytechnique Montréal, Canada * Stephany Bellomo (http://www.sei.cmu.edu/about/people/profile.cfm?id=bellomo_15351), SEI, USA * Christian Bird (http://research.microsoft.com/en-us/people/cbird/), Microsoft Research, USA * Foutse Khomh (http://www.khomh.net/), Polytechnique Montréal, Canada * Kim Moir (http://relengofthenerds.blogspot.com/), Mozilla, Canada For general author guidelines: http://www.computer.org/software/author.htm For submission details: software(a)computer.org

1 0

Telescope - Vizualisation using Roassal2
by Leo Perard 05 May '14

05 May '14

Hi everybody, I'm working on vizualisation with Roassal2 and I would like to have some feedbacks on my work. You can vizualise some elements in their containers and test a property on the elements. You have the legend build with the property and a menu (not a lot of features in the menu but it will come). Edges are not available yet, but I'm working on it. The repository : MCHttpRepository location: 'http://smalltalkhub.com/mc/LeoPerard/Telescope/main' user: '' password: '' To load the project : ConfigurationOfTelescope load To play with it you can follow this example : | telescope | telescope := TLTelescope new onContainers: Collection withAllSubclasses elements: #authors properties: #yourself. telescope numberOfColors: 9. "optional" telescope open or | telescope | telescope := TLTelescope new onElements: Collection withAllSubclasses containers: #package properties: [ :class | class numberOfLinesOfCode > 30 ]. telescope numberOfColors: 9. "optional" telescope open If you have any ideas, or find somes bugs do not hesitate to report to me. Thanks. -- Leo Perard

6 25

RTCompositeShape - Bugs found
by Leo Perard 05 May '14

05 May '14

Hi, here somes bugs I have found on the RTCompositeShape - RTNest does not work with the RTCompositeShape > | view shape element els | > view := RTView new. > shape := (RTVerticalCompositeShape new > shape1: RTBox new; > shape2: RTLabel new; > yourself). > > element := shape elementOn: 'Container'. > els := (RTEllipse new size: 10; color: (Color blue alpha: 0.5)) > elementsOn: (1 to: 16). > view add: element; addAll: els. > element @ RTDraggable. > RTNest new layout: RTGridLayout; on: element nest: els. > view open - on some layouts there is a "lag" when you re-apply a layout > | view shape elements | > view := RTView new. > shape := (RTHorizontalCompositeShape new > shape1: (RTBox new width: 40; height: 30); > shape2: (RTEllipse new size: 15; color: Color red); > yourself). > > elements := shape elementsOn: (1 to: 30). > view addAll: elements. > RTEdge > buildEdgesFromObjects: (1 to: 30) > from: [ :v | v // 2 ] > to: #yourself > inView: view. > > RTHorizontalTreeLayout on: elements. > view canvas addMenu: 'Layout' callback: [ RTHorizontalTreeLayout new > translator: RTSmoothLayoutTranslator new; on: elements ]. > view open This example does not have any sense but in my project the graph is generate dynamicly so I have to apply a layout anytime there is a new element ans this "lag" is strange - RTHorizontalAttachPoint does not work > | view shape elements | > view := RTView new. > shape := (RTHorizontalCompositeShape new > shape1: (RTBox new width: 40; height: 30); > shape2: (RTEllipse new size: 15; color: Color red); > yourself). > > elements := shape elementsOn: (1 to: 30). > view addAll: elements. > RTEdge > buildEdgesFromObjects: (1 to: 30) > from: [ :v | v // 2 ] > to: #yourself > using: (RTLine new attachPoint: RTHorizontalAttachPoint new; color: Color > blue) > inView: view. > > RTHorizontalTreeLayout on: elements. > view canvas addMenu: 'Layout' callback: [ RTHorizontalTreeLayout new > translator: RTSmoothLayoutTranslator new; on: elements ]. > view open For now I have found this bugs. If I find more, I will report them here ;-) -- Cheers, Leo Perard University of Lille 1

2 4

Jenkins build became unstable: moose-5.0 #1322
by admin＠moosetechnology.org 05 May '14

05 May '14

See <https://ci.inria.fr/moose/job/moose-5.0/1322/>

1 1

Jenkins build became unstable: moose-5.0 #1319
by admin＠moosetechnology.org 04 May '14

04 May '14

See <https://ci.inria.fr/moose/job/moose-5.0/1319/>

1 1

Where did 'debug-it' go?
by Johan Fabry 04 May '14

04 May '14

Hi all, I forgot the shortcut key for debug-it (I’m getting old apparently), and I wanted to debug-it an expression in the debugger, but I cannot because the context menu does not have it. The same holds for the playground. Please add it back. It’s cool that the menu is more minimal than what standard Pharo does, but it should really have debug-it. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev