Moose on pharo 2.0 -> moving it STHub
by Usman Bhatti
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.
10 years, 9 months
I started to migrate Merlin
by Stéphane Ducasse
Hi guys
I started to migrate Merlin.
Now I published all the packages to the Moose/Merlin project.
Stef
10 years, 9 months
Fame is migrated
by Stéphane Ducasse
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
10 years, 9 months
Glamour tree presentation - red square of death
by Ben Coman
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
10 years, 9 months
Moose on pharo 2.0
by Usman Bhatti
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
10 years, 9 months
marea
by Tudor Girba
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."
10 years, 9 months
VerveineJ: analyse Eclipse
by Damien Cassou
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
10 years, 9 months
