- Moose-dev - INF Mailman

Issue 919 in moose-technology: Moose Panel does not open in on Moose-latest-dev-4.8 image

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 919 by hayatouo...(a)gmail.com: Moose Panel does not open in on Moose-latest-dev-4.8 image http://code.google.com/p/moose-technology/issues/detail?id=919 When I try World--->Moose--->Moose Panel. I get this message : MessageNotUnderstood: MoosePanel>>#openOn: Attachments: screenshot.png 36.9 KB -- 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

12 years, 3 months

1
3
0 0

jenkins is triggered by a commit in moose

by Tudor Girba

Hi, I configured Jenkins to trigger at every commit in the Moose repository. However, it will not trigger when committing to something like Glamour. What we should do now is to create jobs for each of the sub-projects and have those listen to their respective repositories. Afterwards, we make the moose-latest-dev build to be triggered by these sub-jobs. Like that we ensure two things: - every sub-project can be loaded independently - every commit will be checked as soon as possible Of course, ideally, we should also have the builds ran faster, but that is another story :) Cheers, Doru -- www.tudorgirba.com "Quality cannot be an afterthought."

12 years, 3 months

1
0
0 0

glamour question

by Fabrizio Perin

Hi, I was writing a report in Arki. The result of the report is a dictionary. An entry of the dictionary has as key a FAMIXMethod and as value an ordered collection with inside one or more ordered collections. What I want to do is to have a browser with two rows, in the top row I want a MooseFinder opening on the keys of the dictionary, on the bottom row I want to see the content of the dictionary at the selected key. The problem is that I'm not able to make the MooseFinder opening on the keys of the element. Here a script that reproduce this scenario: | dic myBrowser | dic := Dictionary new. dic at: FAMIXMethod new put: (OrderedCollection with: (OrderedCollection with: 1 with: 2 with: 3)). dic at: FAMIXMethod new put: (OrderedCollection with: (OrderedCollection with: 4 with: 5 with: 6)). dic at: FAMIXMethod new put: (OrderedCollection with: (OrderedCollection with: 7 with: 8 with: 9)). myBrowser := GLMTabulator new. myBrowser row: #methods; row: #info. myBrowser transmit to: #methods; andShow: [:a | a custom: (MooseFinder new first startOn: dic keys asMooseGroup) ]. myBrowser transmit to: #info; from: #methods; andShow: [:a | a list title: 'Columns to map'; display: [:method | (self result at: method) ]]. myBrowser openOn: dic. Any suggestion will be more than welcome. Thanks. Cheers, Fabrizio

12 years, 3 months

2
2
0 0

Falling test question

by Andre Hora

Hi, Test MooseSmalltalkImporterRoelTyperTest>>testASTCore is falling because at some point it is using class TypeCollector, which is no longer in the system. So what should we do: - Remove this importer? - Bring back TypeCollector? ======== SmalltalkImporter>>createAttribute: name for: aClass ... ifTrue: [ possibleTypes := (TypeCollector typeInstvar: name asSymbol ofClassWithLookup: aClass ) types. possibleTypes size = 1 ifTrue: [attribute declaredType: (self ensureClass: possibleTypes first theNonMetaClass) ]. ]. ^ attribute ========= -- Andre Hora

12 years, 3 months

5
6
0 0

working moose build

by Tudor Girba

Hi, The Moose build including running tests now works based on the NBCog VM and the latest Pharo 2.0 (built on Ubuntu): https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/lastCompletedBuild/testR… There are 27 test failures. I also tried on OS X using NBCog VM and the there is no crash. This scenario was also confirmed by Stephan although he reported more failures. For reference, we are using the following script on Jenkins: wget --quiet -qO - http://pharo.gforge.inria.fr/ci/script/ciPharo20NBCogVM.sh | bash wget http://pharo.gforge.inria.fr/ci/image/PharoV20.sources ./vm.sh Pharo.image save $JOB_NAME REPO=http://smalltalkhub.com/mc/Moose/Moose/main ./vm.sh $JOB_NAME.image config $REPO ConfigurationOfMoose --install=development ./vm.sh $JOB_NAME.image moosetest --junit-xml-output zip -r $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes PharoV20.sources Cheers, Doru -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar."

12 years, 3 months

2
2
0 0

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

by Tudor Girba

It would be good to have a parallel job, but the problem is that you will get a message saying that the VM is too old for the Pharo 2.0 image. Cheers, Doru On Tue, Mar 12, 2013 at 9:05 AM, Usman Bhatti <usman.bhatti(a)gmail.com>wrote: > Doru, > > In the meantime, can we revert to CogVM because currently we cannot see > the status of fixes and we cannot go any further with Moose 4.8 or may be > create parallel jobs on Cog and Pharo vms ? > > > > On Mon, Mar 11, 2013 at 9:53 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> Where should I report Pharo VM crashes with Pharo 2.0? >> >> In particular, I wanted to report the problem related to running Moose >> tests from the command line: >> >> --- >> You can reproduce it on Mac, quite consistently: just run the attached >> script (you need to have wget installed), or do it manually: >> >> 1. download and unzip the latest Moose 4.8: >> >> https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/lastSuccessfulBuild/arti… >> 2. download and unzip the latest Pharo VM: >> http://pharo.gforge.inria.fr/ci/vm/pharo/mac/pharo-mac-latest.zip >> 3. execute: >> ./Pharo.app/Contents/MacOS/Pharo ./Moose-latest-dev-4.8.image moosetest >> >> The VM crashes, but there is no trace of the error. >> --- >> >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "It's not what we do that matters most, it's how we do it." >> >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- www.tudorgirba.com "Every thing has its own flow"

12 years, 3 months

3
4
0 0

Re: mini-moose sprint tomorrow

by Usman Bhatti

Can you please send me the fix so that I can give it a try with Glamour and Moose browsers tests? On Fri, Mar 8, 2013 at 2:55 PM, Goubier Thierry <thierry.goubier(a)cea.fr>wrote: > Ok, I have a correction for that. How do I upload it ? > > Technical: if pager is nil in a PaginatedMorphTreeMorph, do a ^ super > update: to recover the original MorphTreeMorph behavior (i.e. a one line > change). > > Hum, I'm unable to try all Galmour tests. I ended with a nice segfault:(. > At least I got GLMUpdateMorphicTest green. > > Thierry > > Le 08/03/2013 14:10, Usman Bhatti a écrit : > >> Hello Thierry, >> >> We are moving Moose to Pharo 2.0 and trying to make build green. There >> was a Glamour-related bug fix in MorphTreeMroph to correct this issue: >> http://code.google.com/p/**moose-technology/issues/**detail?id=905<http://code.google.com/p/moose-technology/issues/detail?id=905> >> >> The fix is integrated in Pharo2.0 and now when loading and running tests >> of Glamour and Moose-related browsers, there are a few failing tests and >> the trail leads to the update method in MorphTreeMorph because the pager >> is nil. Can you please have a look? >> >> You can get the latest dev image of Moose on pharo2.0 here: >> https://ci.inria.fr/moose/job/**Moose-latest-dev-4.8<https://ci.inria.fr/moose/job/Moose-latest-dev-4.8> >> and the problem can be reproduced when running glamour-related tests >> (e.g. GLMUpdateMorphicTest >>testInvalidateSelection). >> >> tx, >> >> Usman >> >> >> >> >> >> On Thu, Mar 7, 2013 at 10:36 PM, Tudor Girba <tudor(a)tudorgirba.com >> <mailto:tudor@tudorgirba.com>> wrote: >> >> Hi, >> >> Great. >> >> In the meantime, I fixed Mondrian and EyeSee to not throw errors. >> The problem was that in Pharo 2.0 Morphs send announcements, and >> these got confused with the specific announcements for Mondrian and >> EyeSee. >> >> Now Glamour has 7 errors but they are all due to the same problem of >> not being able to set the value of a port from outside when >> rendering a list. The issue comes from some internal modifications >> of MorphTreeMorph. It would be cool if someone could take a look at >> this. >> >> There are also a couple of Mondrian tests failing, but they are due >> to Easel accessing a missing class MorphicTextEditor which was >> already deprecated in 1.4. Nevertheless, the Easel is no longer >> really needed because we have one in Glamour. >> >> Cheers, >> Doru >> >> >> On Mar 7, 2013, at 4:26 PM, Usman Bhatti <usman.bhatti(a)gmail.com >> <mailto:usman.bhatti@gmail.com**>> wrote: >> >> > For info. >> > >> > ---------- Forwarded message ---------- >> > From: Usman Bhatti <usman.bhatti(a)gmail.com >> <mailto:usman.bhatti@gmail.com**>> >> > Date: Thu, Mar 7, 2013 at 4:15 PM >> > Subject: mini-moose sprint tomorrow >> > To: RMoD private list <lsehub-staff(a)lists.gforge.**inria.fr<lsehub-staff(a)lists.gforge.inria.fr> >> <mailto:lsehub-staff@lists.**gforge.inria.fr<lsehub-staff(a)lists.gforge.inria.fr> >> >> >> > >> > >> > Now that Moose has moved to SThub and we loading it on Pharo 2.0, >> there are some failing tests in Moose: >> https://ci.inria.fr/moose/job/**Moose-latest-dev-4.8/** >> lastCompletedBuild/testReport/<https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/lastCompletedBuild/testR…> >> > >> > Tomorrow, we will try to make green FAMIX/Moose related tests. >> > >> > The place will be decided at "runtime" according to the number of >> participants. >> > >> > usman >> > >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com> >> >> >> "Every thing has its own flow." >> >> >> >> >> >> > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des Systèmes Temps Réel Embarqués > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

12 years, 3 months

3
7
0 0

Re: [Pharo-project] WhatsUp from: 2013-03-11 until: 2013-03-24

by Tudor Girba

Actually, I would love to get this mechanism also for Moose. Would it be possible? Cheers, Doru On Mar 12, 2013, at 10:15 PM, Stéphane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Mar 12, 2013, at 9:04 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> First of all, I think this is a very cool initiative. > > > thanks > I really hope that it will improve our sharing and community building :) > > Stef > > >> >>> ### Here's what I've been up to since the last WhatsUp: >> >> - Working on getting Moose to work on Pharo 2.0 >> - Extended (and documented) the CommandLineHandler to run multiple tests based on context specific requirements >> - Attracted sponsors for PharoConf + MooseDay to make the event free to attend >> - Annoyed people with requests for giving talks and tutorial at PharoConf + MooseDay >> - Brainstormed and reviewed with Andrei around a very cool (really :)) and modular debugger model >> >>> ### What's next, until 2013-03-24 (*): >>> >>> - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION >>> >>> (*) we'll be expecting results by then ;) >> >> - Find a solution for running Moose on a Pharo 2.0-compatible VM >> - Organize the PharoConf + MooseDay >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "Things happen when they happen, >> not when you talk about them happening." >> >> > > -- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower."

12 years, 3 months

2
3
0 0

Re: WhatsUp from: 2013-03-11 until: 2013-03-24

by Stephan Eggermont

### Here's what I've been up to since the last WhatsUp: - Added a storymap view to StoryBoard. Stories can now be added to a goal of a stakeholder. (+Diego Lont) - Accepted proposal to show debugger-driven TDD at Devnology meetup April 3 in Eindhoven (+Willem van den Ende) - Created proposal for a distributed issue tracker GSoC with Diego - Did a spike for a distributed issue tracker with Diego - Convinced Diego to go to Pharo & Moose Days and show TutorialBrowser & Data Conversion with MOOSE - Did a spike with a gherkin glamour browser, tried moving it to latest pharo/MOOSE/vm :) ### What's next, until 2013-03-24 (*): - publish distributed issue tracker spike - prepare presentations with Diego - parse gherkin files, visualize as roassal nested polymetric views Stephan

12 years, 3 months

3
2
0 0

Importing multiple versions

by Alexandre Bergel

Hi! Alejandro is interesting in visualizing commits of methods along a time line (in the same spirit than Kumpel and Chronia). So far, we have experimented using the data contained in the .changes file. It works well, but this it is not really comfortable and nor reliable. Can Moose be used for this purpose on Smalltalk code? A few years ago I have worked on a Monticello importer. But has someone revived this effort? What would be a reliable solution to import multiple versions of a bunch of Monticello packages? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

12 years, 3 months

1
0
0 0

Re: Latest pharo issue with Eliot's latest Cog

by Stephan Eggermont

Esteban wrote: >Pharo 2.0 does not work with Eliot builds (and it will not work in some scenarios). >In this case, the main reason is that we rebuild (and use) FilePlugin and it is not >incorporated in Eliot branch of the vm... so the FileDialogWindow will take years to open if opens at all. >You need to use one of our VM builds (anyone from last 6 months to now should work) Ah, I didn't know the differences were already so that we need a Pharo-specific vm. nbcog-mac-latest.zip from 27-11-2012 doesn't crash. 15883 run, 15493 passes, 2 skipped, 88 expected failures, 207 failures, 95 errors, 0 unexpected passes Would it be possible to have the vm warning more informative? Something like "expected FilePlugIn, ..."? Stephan

12 years, 3 months

2
1
0 0

did we migrate Collection Extensions?

by Stéphane Ducasse

http://www.squeaksource.com/@SLrcvkKbyWk_uj91/ZNU-ZAa5 If this is the case it would be good to say it in the description of the squeaksource project Else I can migrate it. Stef

12 years, 3 months

5
6
0 0

Re: where to report vm crashes? (while running Moose tests)

by Stephan Eggermont

Phil wrote: >Eliot as a new VM as of yesterday > >http://www.mirandabanda.org/files/Cog/VM/VM.r2701/README.2701 > >That kind of fixes things. > >But I guess the Pharo team still has to integrate these fixes. This is with 2701. The Moose image is based on Pharo 20589 Stephan

12 years, 3 months

1
0
0 0

Re: where to report vm crashes? (while running Moose tests)

by Stephan Eggermont

Esteban wrote: > Eliot builds will always have the old vm warning, even if they are not old :)... > you need one of the pharo builds (CogVM, NBCogVM or PharoVM) Well, Doru reported they crashed. Eliot's one doesn't: > 15875 run, 15472 passes, 2 skipped, 88 expected failures, 216 failures, 99 errors, 0 unexpected passes On the other hand, not being able to add a monticello directory repository is also not helpful. No filedialog is shown (receiver of bitAt: is nil, looks like a problem with filesystem permissions) Stephan

12 years, 3 months

1
0
0 0

Re: where to report vm crashes? (while running Moose tests)

by Stephan Eggermont

>It would be good to have a parallel job, but the problem is that you will >get a message saying that the VM is too old for the Pharo 2.0 image. I started the latest MOOSE image on Eliots latest VM on mac. It still has the 'old vm' warning. Adding a monticello repository (directory) doesn't work. Tests are still running Stephan

12 years, 3 months

1
0
0 0

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

by Usman Bhatti

Doru, In the meantime, can we revert to CogVM because currently we cannot see the status of fixes and we cannot go any further with Moose 4.8 or may be create parallel jobs on Cog and Pharo vms ? On Mon, Mar 11, 2013 at 9:53 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Where should I report Pharo VM crashes with Pharo 2.0? > > In particular, I wanted to report the problem related to running Moose > tests from the command line: > > --- > You can reproduce it on Mac, quite consistently: just run the attached > script (you need to have wget installed), or do it manually: > > 1. download and unzip the latest Moose 4.8: > > https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/lastSuccessfulBuild/arti… > 2. download and unzip the latest Pharo VM: > http://pharo.gforge.inria.fr/ci/vm/pharo/mac/pharo-mac-latest.zip > 3. execute: > ./Pharo.app/Contents/MacOS/Pharo ./Moose-latest-dev-4.8.image moosetest > > The VM crashes, but there is no trace of the error. > --- > > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "It's not what we do that matters most, it's how we do it." > >

12 years, 3 months

1
0
0 0

glamour tests crashing image with PharoVM

by Usman Bhatti

https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/48/console The behaviour is not identical on CogVM.

12 years, 4 months

3
4
0 0

cleaning dirty packages

by Tudor Girba

Hi, There are a number of dirty packages in the Moose image. Most of these are due to us loading packages with extensions that are now present in Pharo 2.0. I removed: - BDDExtensions as a prerequisite to Glamour because it is already present in the image - I removed an Morph extension from Glamour - I removed a couple of methods from Mondrian that were extending Behavior and CompiledMethod There are still a couple left: - Moose-TestResources is dirty for some reason I do not understand, but I suspect it has to do with the latest CategoryImporter tests. Yuriy, could you take a look? - Object>>asMorph comes from Magritte and should be renamed to asMagritteMorph - some extensions from Grease were adopted by Pharo Cheers, Doru -- www.tudorgirba.com "Beauty is where we see it."

12 years, 4 months

2
1
0 0

customizing the CommandLineHandler to run Moose tests

by Tudor Girba

Hi, Now that the continuous integration build is using the cool ZeroConf infrastructure, we needed a clean way to run all tests from Moose based on the information gathered from the ConfigurationOfMoose. More precisely we want to run all the tests from all packages that are in the 'Tests' group from all configurations referred from ConfigurationOfMoose (including itself) :). It's sounds more complicated than it actually is: packages | packages | packages := Set new. (self mooseDevelopmentVersion packagesForSpecNamed: 'Tests') do: [ :spec | packages add: spec name ]. self mooseDevelopmentVersion projects do: [ :each | (each version packagesForSpecNamed: 'Tests') do: [ :spec | packages add: spec name ] ]. ^ packages We used to have this logic in an .st file that was ran through the builder from Lukas. But, now, I simply created the MooseTestRunnerCommandLineHandler as a subclass of TestRunnerCommandLineHandler, and provided the new packages. I gave it the commandName of 'moosetest' and now I can simply call from the command line: Pharo ./Moose-latest-dev-4.8.image moosetest In Moose, we have a little package named: Moose-Development-Tools that is loaded by the configuration. I added the new class to it, and I can easily integrate the whole test running in the ci job after loading the configuration. I'd say it's pretty neat. Cheers, Doru p.s. The VM still crashes when running the tests though (at least on Mac) -- www.tudorgirba.com "Beauty is where we see it."

12 years, 4 months

2
4
0 0

cleaning configurations

by Tudor Girba

Hi, I spent a couple of hours cleaning configurations. It is better, but it is highly brittle. We need tools to reason about configurations. This should be a good Moose project. Until now: - I went through the configurations of Moose, Mondrian, Glamour, EyeSee, Fame and pointed repositories to STHub - I cleaned the #baseline to point to #development version instead of hardcoded versions for Moose projects. - I made #development versions point to the latest baseline. Like this we can always load #development and get the very latest of the Moose code. - removed Shout from Glamour and Mondrian - removed RB and RPackage from GToolkit Still, it appears that the ConfigurationOfMondrian has some problems. Cheers, Doru -- www.tudorgirba.com "Not knowing how to do something is not an argument for how it cannot be done."

12 years, 4 months

2
3
0 0

moved DSM to STHub

by Anne Etien

Hi, Yesterday during the minisprint in Lille, we (Nicolas Anquetil) and me moved DSM to STHub. We also changed the ConfigurationOfMoose and ConfigurationOfDSM. Anne

12 years, 4 months

1
0
0 0

moved HealthReportProducer to STHub

by Tudor Girba

Hi, I moved HealthReportProducer to STHub. I also changed the ConfigurationOfMoose and ConfigurationOfHealthReportProducer (which is used by Mondrian) to load XMLParser from STHub instead of XMLSupport. Slowly, we are getting there, but the GTMetaceller is invaluable :). Cheers, Doru -- www.tudorgirba.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

12 years, 4 months

1
0
0 0

[FIX] testCategoryImporter

by Yuriy Tymchuk

https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/lastCompletedBuild/testR… Test was failing because it was running on dsm testResources. I've created testResources for CategoryImporter based on the dsm ones and changed test to use dedicated resources. Cheers Uko -- View this message in context: http://moose-dev.97923.n3.nabble.com/FIX-testCategoryImporter-tp4026396.html Sent from the moose-dev mailing list archive at Nabble.com.

12 years, 4 months

2
1
0 0

ROCircle - rename to ROElipse? (related to issue 857)

by Chris Cunningham

As stated in this bug: "(Sorry) to be explicit, "Circles" should be constrained to remain a circle when either dimension is changed." That's probably right. However, I like the current behavior - I would like an ellipse that fit around my text. Could we rename the current ROCircle to be ROEllipse (and add related code to handle this), and create a new ROCircle that maintained itself as a Circle for those who want that behavior? I'd be happy to take on doing this (or at least some of it) in the next few days; I just need to understand how to submit the changes (and if you want them). -Chris

12 years, 4 months

3
2
0 0

Re: mini-moose sprint tomorrow

by Tudor Girba

Hi, Great. In the meantime, I fixed Mondrian and EyeSee to not throw errors. The problem was that in Pharo 2.0 Morphs send announcements, and these got confused with the specific announcements for Mondrian and EyeSee. Now Glamour has 7 errors but they are all due to the same problem of not being able to set the value of a port from outside when rendering a list. The issue comes from some internal modifications of MorphTreeMorph. It would be cool if someone could take a look at this. There are also a couple of Mondrian tests failing, but they are due to Easel accessing a missing class MorphicTextEditor which was already deprecated in 1.4. Nevertheless, the Easel is no longer really needed because we have one in Glamour. Cheers, Doru On Mar 7, 2013, at 4:26 PM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > For info. > > ---------- Forwarded message ---------- > From: Usman Bhatti <usman.bhatti(a)gmail.com> > Date: Thu, Mar 7, 2013 at 4:15 PM > Subject: mini-moose sprint tomorrow > To: RMoD private list <lsehub-staff(a)lists.gforge.inria.fr> > > > Now that Moose has moved to SThub and we loading it on Pharo 2.0, there are some failing tests in Moose: https://ci.inria.fr/moose/job/Moose-latest-dev-4.8/lastCompletedBuild/testR… > > Tomorrow, we will try to make green FAMIX/Moose related tests. > > The place will be decided at "runtime" according to the number of participants. > > usman > -- www.tudorgirba.com "Every thing has its own flow."

12 years, 4 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev