Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

http://www.squeaksource.com/ShapeST80
by Usman Bhatti 13 Feb '13

13 Feb '13

I am moving EyeSee from squeaksource to SThub. EyeSee has a dependency on ShapeST80 (ss/ShapeST80). Should I move this project to Moose team or is this project used somewhere independent of EyeSee? usman

3 2

SS/Moose -> St/Moose + St/MooseArchive
by Usman Bhatti 12 Feb '13

12 Feb '13

As the subject suggests, moose repo on squeaksource has been completely moved to SThub. Now, we distinguish two types of package in squeaksource/Moose: - the packages from the repo loaded by the current moose configuration are moved to Moose project on SThub. - the packages not loaded by the current moose config are moved to MooseArchive project on SThub (to be sure that we do not lose code). ConfigurationOfMoose cannot be updated and tested unless all peripheral tools (Mondrian/XMLSupport/etc.) are moved to SThub. So, we are first moving and updating leaves before updating and testing the config of trunk. So, now remaining projects (in the coreDefault: baseline of Moose): Mondrian, MooseAlgos, Glamour, PetitParser, XMLSupport. I've already downloaded all packages of Mondrian, tomorrow I'll push them and update the config. The ones that require more effort in terms of organization: Glamour and PetitParser. So, may be during of the next week we can start loading the first basic config of moose (after some cleanup: exclude DSM, Smalldude, Nile, etc.) loadable from STHub and it would be good to make it rapid otherwise, if someone needs to push some changes in moose and (s)he starts doing it on SS, it'll be a mess. usman

1 0

EyeSee update - a fix
by Usman Bhatti 12 Feb '13

12 Feb '13

Currently, an EyeSee chart does not update itself when its pane is updated in Glamour. I think the problem comes from the fact that erroneously the presentation is assigned a new diagram block instead of a new renderer. This code fixes this problem. Can I integrate it in glamour? GLMMorphicEyeSeeRenderer >> actOnPresentationUpdate: ann "ann presentation diagram: ESDiagramRenderer new." ann presentation eyeseeRenderer: ESDiagramRenderer new. canvasScrollPane scroller removeMorph: canvasScrollPane scroller submorphs first. self eyeseeCanvasFor: ann presentation

1 0

EyeSee + STShape80 now on SThub
by Usman Bhatti 12 Feb '13

12 Feb '13

- moved the code of the both to SThub - updated the config - tested in 1.4 (all tests green) - tested in 2.0 1. Apparently, BlockContext is removed in 2.0 so eyeSeeValue: cannot be loaded from EyeSee in 2.0. 2. All tests green except ESExamplesTest>>testSmoke Should I open bug entries for these? Usman

1 0

doing Eyesee then Mondrian
by Usman Bhatti 12 Feb '13

12 Feb '13

1 0

Moving Moose-Core to Moose project in SmalltalkHub
by Usman Bhatti 11 Feb '13

11 Feb '13

We are working today to move all Moose package in Moose repo in SqueakSource to SmalltalkHub, update the config and test these packages on both 1.4 and 2.0.

1 0

Moose on pharo 2.0 -> moving it STHub
by Usman Bhatti 11 Feb '13

11 Feb '13

Hello all, Today, we worked on moving Moose on pharo2.0. We needed to update a few baselines because some packages were already present in Pharo2.0. For example, - RPackage is already present in Pharo 2.0, so no need to load it in the image. - PetitParser loads Glamour, which loads NECompletion and NEC does not have configuration for pharo2.0. We decided to move all the moose code to STHub before porting it to 2.0 so that we can save changes somewhere. Some projects are created in STHub in the Moose team: Fame (Moved all code from FAME on squeaksource to STHub, updated configurationOf to load from STHub + creating a version with latest dev.) Glamour (in the process of downloading packages but its taking long, but glamour will be difficult because it has dependencies with other projects so may be it should be moved incrementally. Doru, I think you can take lead on that since you know the project better) Moose (FAMIX + Moose-Core, downloading packages, will be committing next week) PetitParser (will be moved next week too) For people interested in moving code, here are the scripts for fetch and push. ================================== "fetch all FAME packages from their repository" | go | go := Gofer new squeaksource: 'Fame'. ((go allResolved select: [:aPac |'*Fam*' match: aPac packageName ]) do: [:each | self crLog: each packageName. go package: each packageName. Transcript show: each printString ; cr. go fetch.]). ====================================== "commit all FAME packages into the smalltalkhub FAME project" |go repo| repo := MCSmalltalkhubRepository owner: 'Moose' project: 'Fame' user: 'XXX' password: 'XXX'. go := Gofer new. go repository: repo. (((FileSystem disk workingDirectory / 'package-cache') allFiles select: [:each | '*Fame*.mcz' match: each basename]) groupedBy: [:each | (each base copyUpToLast: $-) ]) keys do: [:name | go package: name; push] Now, moving to Pharo2.0 is important, so it will be good to kill this boring task by working collaboratively :-) Usman P.S: The last step of moving every project is to create a new baseline to point to STHub for the project and preferably create a version with that baseline.

6 8

I started to migrate Merlin
by Stéphane Ducasse 10 Feb '13

10 Feb '13

Hi guys I started to migrate Merlin. Now I published all the packages to the Moose/Merlin project. Stef

3 3

Fame is migrated
by Stéphane Ducasse 10 Feb '13

10 Feb '13

Hi guys - I fixed the 1.4 stable and development specification (do not use common) - I produced a version for 2.0 Now I do not understand why the tests are red in 1.4 and 2.0 199 run, 193 passes, 0 expected failures, 0 failures, 6 errors, 0 unexpected passes Failures: Errors: FMExporterTest>>#testExportAsMSE FMExporterTest>>#testExportAsXML FMMetaRepositoryFilterTest>>#testExportAsMSE FMMetaRepositoryFilterTest>>#testExportAsXML FMLibraryExample>>#testPrintMetamodel FMLibraryExample>>#testPrintModel I will check to see if I can fix them. But to me it looks like a bad practice to have red tests. Stef

3 7

Glamour tree presentation - red square of death
by Ben Coman 10 Feb '13

10 Feb '13

I am having some trouble with a with a tree presentation in Glamour being replaced with red square with a yellow cross. How can I attach troubleshooting this? Naively I tried wrapping each of the blocks passed with exception handling as follows.... ---- a tree updateOn: LEKShownClassesChanged from: self announcer when: [ :ann :entity | [ self setNavigatorIconsFor: LEKCimPackage rootPackage ] on: Exception do: [ self inform: 'upDateOn error' ] . true ] ; children: [ :item | [ item children sort: [ :before :after | before cimName < after cimName ] ] on: Exception do: [ self inform: 'children error' ] ] ; format: [ :item | [ item cimName ] on: Exception do: [ self inform: 'format error' ] ] ; act: [ :presentation :model | self shownClasses inspect ] entitled: 'selected package classes' ; icon: [ :item | [ self navigatorIconFor: item ] on: Exception do: [ self inform: 'icon error' ] ] ; ---- and also similarly wrapping the rendering... ---- GLMMorphicTreeRenderer>>render: aPresentation | container | [ container := super render: aPresentation. aPresentation shouldAllExpand ifTrue: [container submorphs first expandAll ]. aPresentation shouldRootsExpand ifTrue: [container submorphs first expandRoots ]. ] on: Exception do: [ self inform: 'render error' ]. Transcript crShow: container. ^ container ---- but nothing happens. Where does the red square get generated from? So I can try making a debugger come up instead of the red square. cheers, Ben

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev