HI doru
GLMBrowserTemplate
You must resolve these dependencies before you will be able to load these definitions:
GLMEyeSeeExamplesBrowser
I checked and
GLMEyeSeeExamplesBrowser class >> open
^ self new openOn: ESExamples
package: 'Glamour-Examples' ;
look bogus
it depends on Magritte!, EyeSee and Roassal
I tried
package: 'Glamour-Examples' with: [spec requires: #('Glamour-Magritte-Presentations' 'Glamour-EyeSee-Presentations' 'Glamour-Mondrian-Presentations')] ;
but I navigate in the total guess here.
Can you have a look?
Stef
So I did
package: 'Mondrian-Core';
package: 'Mondrian-ComplexShape' with: [ spec requires: 'Mondrian-Core' ];
package: 'Mondrian-Layouts';
and restarted again….
Mondrian-Pharo-Tests says
This package depends on the following classes:
MondrianTest
You must resolve these dependencies before you will be able to load these definitions:
MOCanvasTest
allEventPollsEmpty
I'm trying to find the problem now but in parallel I'm painting my house door :)
Stef
Hi doru
I like the interface much better than the moose reloader :)
Else
- what about dirty packages that are not in the configuration tree? I would not handle them to force people to get clean
Did you try to rebuild Moose using it?
I will ;)
Stef
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-SmalltalkImporter
New issue 960 by anquetil...(a)gmail.com: Smalltalk importer creates a
non-stub Object.DependentsFields
http://code.google.com/p/moose-technology/issues/detail?id=960
When creating a moose model from smalltalk code not including Object
The class Object is created with isStub=true
Object has an attribute Object.DependentsFields (a class variable) with
isStub=false
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Milestone-4.8 Component-Metanool
Component-Finder
New issue 962 by tu...(a)tudorgirba.com: Metanool should not extend
MooseEntity and MooseGroup
http://code.google.com/p/moose-technology/issues/detail?id=962
Metanool extends these classes with MooseFinder specific methods. These
methods should move to MooseFinder.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
Hi guys
Is Moose really using development version of its subproject?
because
spec project: 'Mondrian' with: [
spec
className: 'ConfigurationOfMondrian';
file: 'ConfigurationOfMondrian';
version: #development ;
repository: 'http://www.smalltalkhub.com/mc/Moose/Mondrian/main'
And
development: spec
<symbolicVersion: #'development'>
spec for: #'common' version: '2.162'.
and there are
<version: '2.9' imports: #('2.5-baseline')>
So when I do
(ConfigurationOfMoose project version: #development) record loadDirective
for moose I get …
(ConfigurationOfMoose project version: #development) record loadDirective
I get No version found for 1.3 of ConfigurationOfShout!!!
Hi doru
I'm trying to reload a configuration for moose and I end up with package loading order problems.
I thought that in reloader we payed attention to preserve the same loading order (I remember that we did it when I was attending the moose
workshop).
Now do you know if the baseline of a project is not interfering with the load order that we store.
Stef