Moose-dev

moose-dev@list.inf.unibe.ch

6630 discussions

Build failed in Jenkins: moose-5.0 #2134

by admin＠moosetechnology.org

See <https://ci.inria.fr/moose/job/moose-5.0/2134/> ------------------------------------------ Started by upstream project "petitparser" build number 570 originally caused by: [URLTrigger] A change within the response URL invocation (log) Started by upstream project "petitjava" build number 905 originally caused by: Started by upstream project "petitparser" build number 570 originally caused by: [URLTrigger] A change within the response URL invocation (log) Building remotely on moose-slave in workspace <https://ci.inria.fr/moose/job/moose-5.0/ws/> Deleting project workspace... done [moose-5.0] $ /bin/sh -xe /tmp/hudson3899952771019777129.sh + bash + wget --quiet -O - http://get.pharo.org/30+vmLatest Downloading the latest 30 Image: http://files.pharo.org/image/30/latest.zip Pharo.image Downloading the latest pharoVM: http://files.pharo.org/vm/pharo/linux/latest.zip pharo-vm/pharo Downloading PharoV10.sources: http://files.pharo.org/sources//PharoV10.sources.zip Downloading PharoV20.sources: http://files.pharo.org/sources//PharoV20.sources.zip Downloading PharoV30.sources: http://files.pharo.org/sources//PharoV30.sources.zip Creating starter scripts pharo and pharo-ui + ./pharo Pharo.image save moose-5.0 + REPO=http://www.smalltalkhub.com/mc/Moose/Moose/main + ./pharo moose-5.0.image config http://www.smalltalkhub.com/mc/Moose/Moose/main ConfigurationOfMoose --install=development 'Installing ConfigurationOfMoose development' [31mError: Could not access http://smalltalkhub.com/mc/Moose/Moose/main/: ZnHttpUnsuccessful: 400 Bad Request [0mMCSmalltalkhubRepository(Object)>>error: MCSmalltalkhubRepository>>loadAllFileNames in Block: [ :exception | self error: 'Could not access ' , s...etc... BlockClosure>>cull: MethodContext(ContextPart)>>handleSignal: in Block: [ self exceptionHandlerBlock cull: exception ] BlockClosure>>ensure: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: ZnHttpUnsuccessful(Exception)>>signal ZnClient>>handleResponse ZnClient>>executeWithRedirectsRemaining: ZnClient>>executeWithRetriesRemaining: in Block: [ self executeWithRedirectsRemaining: self maxNumb...etc... BlockClosure>>on:do: ZnClient>>executeWithRetriesRemaining: ZnClient>>executeWithTimeout in Block: [ self executeWithRetriesRemaining: self numberOfR...etc... BlockClosure>>on:do: ZnClient>>executeWithTimeout in Block: [ ... ZnClient>>withTimeoutDo: in Block: [ ^ block value ] ZnConnectionTimeout(DynamicVariable)>>value:during: in Block: [ ... BlockClosure>>ensure: ZnConnectionTimeout(DynamicVariable)>>value:during: ZnConnectionTimeout class(DynamicVariable class)>>value:during: ZnClient>>withTimeoutDo: ZnClient>>executeWithTimeout ZnClient>>execute in Block: [ result := self executeWithTimeout ] ZnClient>>withProgressDo: in Block: [ ^ block value ] ZnSignalProgress(DynamicVariable)>>value:during: in Block: [ ... BlockClosure>>ensure: ZnSignalProgress(DynamicVariable)>>value:during: ZnSignalProgress class(DynamicVariable class)>>value:during: ZnClient>>withProgressDo: [0mBuild step 'Execute shell' marked build as failure Archiving artifacts Recording test results

10 years, 5 months

Re: [Esug-list] Award.... new process :)

by Tudor Girba

Hi, Here is our submission for the ESUG Innovation Awards: Title: GT Inspector Submitter: Andrei Chis, Tudor Girba, Alex Syrel Smalltalk Dialect: Pharo Affiliation: University of Bern, tudorgirba.com Country: Switzerland Website: http://gt.moosetechnology.org Trailer: http://vimeo.com/103463364 Keywords: Pharo, IDE, Moose, Visualization Licence: MIT Cheers, The Glamorous Team On Thu, Aug 14, 2014 at 1:24 PM, Stéphane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Hi smalltalkers > > for the awards it seems that the registration server has still a problem. > I suggest that you prepare your video and that you send a title and a > little description of your project > as a reply to this mail. We will manage it differently but we will do this > great competition. > > Stef > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > -- www.tudorgirba.com "Every thing has its own flow"

10 years, 5 months

Charter chapter under construction

by Alexandre Bergel

Dear All, Just to share the work on progress about a chapter on Charter. A charting library on top of Roassal. http://agilevisualization.com https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/0202-Charte… Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

10 years, 5 months

Update of the FamixGenerator

by Thomas Haug

Good evening, I have just pushed a new version of the FamixGenerator tool to my website. So if you want to give it a try: http://www.sharpmetrics.net/index.php/famix-generator I have added a couple of features, like * export of method invocations for FAMIX 3.0 models * export of local variable and parameter access. * several bug fixes * and last but not least: export of generated C#-like code, which can be "attached" inside MOOSE (more is written in the readme file inside the zip file.) The tools does still export Famix 2 and 3.0 models, but currently I am struggling with the Famix 2.1 models for CodeCity. I think this relates to "analysis" and export of generic classes and generic type instances. This feature is not yet complete, so this might be the reason. I will investigate that issue in the next weeks. If you want to view a city inside MOOSE, you can try the following script (if you have the new CodeCity for MOOSE installed): | models builder | models := MooseModel root allModels. builder := CCBuilder new. models notEmpty ifTrue: [ | packages classes classNormalizer packageNormalizer | builder packingLayout. packages := models first allModelNamespaces. classes := packages flatCollect: #classes. packageNormalizer := CCColorNormalizer new low: (Color gray: 0.6); high: (Color gray: 0.95); transformation: #numberOfClasses; population: packages. builder shapeBuilder platform color: packageNormalizer. builder nodes: packages. classNormalizer := CCColorNormalizer new low: (Color gray: 0.25); high: Color blue; transformation: #weightedMethodCount; population: classes. builder shapeBuilder box color: classNormalizer; height: #numberOfMethods; width: #numberOfAttributes; depth: #numberOfAttributes. builder nodes: classes. builder nest: packages node: #yourself in: #parentScope. builder nest: classes node: #yourself in: #namespaceScope ]. builder open As you can see this script uses Famixnamespaces ('allModelNamespaces' and 'namespaceScope'). This is because the FamixGenerator currently does not export FamixPackages. This is also on my agenda... Good night and take care, Thomas

10 years, 5 months

small extension to famix

by Alexandre Bergel

Hi! I am thinking about extending FAMIXClass with the following: withAllSuperclasses ^ self superclassHierarchyGroup isPharoTest ^ self superclassHierarchyGroup anySatisfy: [ :c | c name = 'TestCase’ ] Does this makes sense? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

10 years, 5 months

Re: [Pharo-users] [ANN] Live Robot Programming

by Johan Fabry

Thanks to both :-) Daniel: Contributions from you will be certainly very welcome :-) But watch out, to be able to remote control the EV3 you also need a WiFi key, specifically the Netgear N150 (WNA1100 chipset). Only that one works, and they are getting harder to find these days :-( On Aug 14, 2014, at 11:03 PM, Lemuus <lemuus(a)gmail.com> wrote: > Awesome!!! now I really need to get a Lego Mindstorms EV3 :) > > > On Thu, Aug 14, 2014 at 2:50 PM, Santiago Bragagnolo <santiagobragagnolo(a)gmail.com> wrote: > Great Johan! Congrats for both of you :) > > > 2014-08-14 22:37 GMT+02:00 Johan Fabry <jfabry(a)dcc.uchile.cl>: > > > Aargh, copy-paste error. The Lego robot example is on Instagram of course :-) > > http://instagram.com/p/pEhm0Oj837/ > > > On Aug 14, 2014, at 4:28 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > > > Hi all, > > > > it’s with great joy that I can announce the project that my PhD student Miguel and I have been working on recently: Live Robot Programming, or LRP for short. > > > > LRP is a live programming language designed for the creation of the behavior layer of robots. It is fundamentally a nested state machine language built with robotics applications in mind, but it is not bound to a specific robot middleware, API or OS. Have a look at one minute of LRP programming to get an idea of what it is like: http://youtu.be/4Ma8ZapBUqA > > > > Live programming is fun, and live robot programming even more so, as it brings all the advantages of live programming to programming a robot. You get direct manipulation of a running robot, and that’s just cool beyond words. As an example of LRP on a robot, this guy was programmed in LRP: http://youtu.be/4Ma8ZapBUqA Note that you can use LRP ‘just’ for live programming nested state machines as well. > > > > More information on LRP is available on its website: http://pleiad.cl/LRP where you can also find download instructions. > > > > LRP is implemented in Pharo, and uses Roassal2 for the visualization of its state machines. We currently can steer the Lego Mindstorms EV3 and ROS robots, thanks to a small layer on top of the cool Pharo support that Jannik, Luc, Santiago and Noury are implementing at Douai. I am going to look into support for the Parrot AR.Drone 2.0esug in a few weeks. > > > > Miguel will be at ESUG next week (I cannot make it), and has a talk at the IWST workshop about LRP, in the morning session. I am sure that he will also be happy to give demos of LRP if you ask him to (but sadly without a robot). > > > > All feedback is welcome, and … have fun! > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > > > Johan Fabry - http://pleiad.cl/~jfabry > > PLEIAD lab - Computer Science Department (DCC) - University of Chile > > > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > > > > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

10 years, 5 months

[ANN] Live Robot Programming

by Johan Fabry

Hi all, it’s with great joy that I can announce the project that my PhD student Miguel and I have been working on recently: Live Robot Programming, or LRP for short. LRP is a live programming language designed for the creation of the behavior layer of robots. It is fundamentally a nested state machine language built with robotics applications in mind, but it is not bound to a specific robot middleware, API or OS. Have a look at one minute of LRP programming to get an idea of what it is like: http://youtu.be/4Ma8ZapBUqA Live programming is fun, and live robot programming even more so, as it brings all the advantages of live programming to programming a robot. You get direct manipulation of a running robot, and that’s just cool beyond words. As an example of LRP on a robot, this guy was programmed in LRP: http://youtu.be/4Ma8ZapBUqA Note that you can use LRP ‘just’ for live programming nested state machines as well. More information on LRP is available on its website: http://pleiad.cl/LRP where you can also find download instructions. LRP is implemented in Pharo, and uses Roassal2 for the visualization of its state machines. We currently can steer the Lego Mindstorms EV3 and ROS robots, thanks to a small layer on top of the cool Pharo support that Jannik, Luc, Santiago and Noury are implementing at Douai. I am going to look into support for the Parrot AR.Drone 2.0esug in a few weeks. Miguel will be at ESUG next week (I cannot make it), and has a talk at the IWST workshop about LRP, in the morning session. I am sure that he will also be happy to give demos of LRP if you ask him to (but sadly without a robot). All feedback is welcome, and … have fun! ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

10 years, 5 months

Issue 1015 in moose-technology: GraphET should support lineWidth and legend

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 1015 by usman.bh...(a)gmail.com: GraphET should support lineWidth and legend http://code.google.com/p/moose-technology/issues/detail?id=1015 Graphet should provide support for line width for line diagrams and a legend. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

10 years, 5 months

New circle layouts in Roassal

by Alexandre Bergel

Hi! Daniel has worked on additional circle layouts, which are now included in Roassal. We now have RTEquidistantCircleLayout and RTWeightedCircleLayout in addition to RTCircleLayout and RTCenteredCircleLayout Consider this small script: =-=-==-=-==-=-==-=-= | view aux | view := RTView new. aux := RTEllipse new. aux color: Color red. 1 to: 20 do: [ :i | aux sizeElement: i*4+5. view add: (aux elementOn: i) ]. RTCircleLayout new initialRadius: 150; on: view elements. view open =-=-==-=-==-=-==-=-= It produces the output: There are two recurrent problems with this rendering: - circles are not centered - circles overlaps and this overlap can be avoided since there is spaces between the small circles. The layout does not consider the size of the elements RTEquidistantCircleLayout and RTWeightedCircleLayout address these problems. In the script above, replacing RTCircleLayout by RTWeightedCircleLayout produces the following: The space is allocated to each element according to its size. A variation of this situation may be seen with the following: =-=-==-=-==-=-==-=-= | view aux | view := RTView new. aux := RTEllipse new. aux color: Color red. 1 to: 10 do: [ :i | aux sizeElement: i*10+5. view add: (aux elementOn: i) ]. RTWeightedCircleLayout new initialRadius: 150; on: view elements. view open =-=-==-=-==-=-==-=-= The script produces It may happens however that you want always the same space between the elements. You should therefore use RTEquidistantCircleLayout as in: =-=-==-=-==-=-==-=-= | view aux | view := RTView new. aux := RTEllipse new. aux color: Color red. 1 to: 10 do: [ :i | aux sizeElement: i*10+5. view add: (aux elementOn: i) ]. RTEquidistantCircleLayout new initialRadius: 150; on: view elements. view open =-=-==-=-==-=-==-=-= It produces the following: The work of Daniel may be found in Roassal2. Thanks Daniel! Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

10 years, 5 months

eyesee presentation vs graphET presentation

by Fabrizio Perin

Hi, I built sometimes ago a tab in the moose panel to show an eyesee pieChart: *viewAccessesTypesPieChartIn: composite <moosePresentationOrder: 275> composite eyesee title: 'Database accessor types'; titleIcon: MooseJEEIcons pieChart; diagram: [ :view :each | each mooseInterestingEntity viewAccessesTypesPieChartOn: view ]; when: [ :input | input mooseInterestingEntity isKindOf: FAMIXDBAccessGroup ]* Now, if I load eyesee and the eyesee glamour presentation everything is fine, however, I would like to port this view on graphET. So, I tried: *viewAccessesTypesPieChartIn: composite <moosePresentationOrder: 275> composite graphET title: 'Database accessor types'; titleIcon: MooseJEEIcons pieChart; diagram: [ :view :each | each mooseInterestingEntity viewAccessesTypesPieChartOn: view ]; when: [ :input | input mooseInterestingEntity isKindOf: FAMIXDBAccessGroup ]* now the local variable *each *contains the presentation instead of the model, is that a wanted feature? If so, how can i access the model elements to invoke the view I need? Should I move the logic that implements the view? Thanks in advance, Fabrizio

10 years, 5 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