Moose-dev February 2013

moose-dev@list.inf.unibe.ch

21 participants
145 discussions

Start a nNew thread

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

Migrated HashTable from ss to SmalltalkHub
by Stéphane Ducasse 10 Feb '13

10 Feb '13

- migrated all the history - defined configurationOf - All tests are green under 1.4 and 2.0 Stef

1 0

Moose on pharo 2.0
by Usman Bhatti 07 Feb '13

07 Feb '13

Hello, Tomorrow, there is a pharo sprint in Lille. We, people working on Moose in Lille, thought of doing a Moose sprint/dojo and the purpose is to port Moose on Pharo 2.0. Is there someone who has tried to make Moose work on Pharo 2.0? If so, do we have a list of bugs for Moose 4.8 that we can kill tomorrow? Usman

1 0

marea
by Tudor Girba 06 Feb '13

06 Feb '13

Hi Mariano, I just stumbled across the paper, and it looks really nice. I definitely would like to have it used in Moose. I actually started to prototype a cache based on Fuel, but obviously Marea is way better. In the paper, you mention that the use in Moose is to be able to handle multiple models. That is a use case, but I think it's not a critical one. A more interesting use case is the one in which we want to store an AST alongside FAMIX. There are two challenges here: - The size of AST data is really prohibitive for being loaded in memory all the time - For the AST to be most valuable, we need to be able to link parts of the model to the corresponding AST nodes. See the picture in the attachment for an example: an invocation between methodA and methodB would have a corresponding message send node in the AST of methodA. If I understand Marea right, we could consider as roots all the AST root nodes, and essentially have them all swapped until we get to use one for some detailed analysis such as whether the invocation happens inside a loop or not. Is that correct? Cheers, Doru -- www.tudorgirba.com "It's not what we do that matters most, it's how we do it."

1 0

VerveineJ: analyse Eclipse
by Damien Cassou 05 Feb '13

05 Feb '13

Hi, is it possible to analyse Eclipse source code with VerveineJ? I always got various OutOfMemoryException Thank you -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev February 2013