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
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
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
- 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
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.
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.
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
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
