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
- RPackage is already present in Pharo 2.0, so no need to load it in the
- 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
PetitParser (will be moved next week too)
For people interested in moving code, here are the scripts for fetch and
"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.
"commit all FAME packages into the smalltalkhub FAME project"
repo := MCSmalltalkhubRepository
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 :-)
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
- 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
I will check to see if I can fix them.
But to me it looks like a bad practice to have red tests.
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
Naively I tried wrapping each of the blocks passed with exception
handling as follows....
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...
| container |
container := super render: aPresentation.
aPresentation shouldAllExpand ifTrue: [container submorphs first
aPresentation shouldRootsExpand ifTrue: [container submorphs first
] on: Exception do: [ self inform: 'render error' ].
Transcript crShow: 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.
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?
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?
"It's not what we do that matters most, it's how we do it."
is it possible to analyse Eclipse source code with VerveineJ? I always
got various OutOfMemoryException
"Success is the ability to go from one failure to another without