Updates:
Labels: -Platform-Squeak Platform-Pharo
Comment #1 on issue 321 by tudor.gi...(a)gmail.com: Problems using java code
importer with inFusion in windows
http://code.google.com/p/moose-technology/issues/detail?id=321
The command should be taken away from the menu until OSProcess works
properly.
Updates:
Labels: -Milestone-4.2 Milestone-4.3
Comment #6 on issue 114 by tudor.gi...(a)gmail.com: Resizable panes in Finder
http://code.google.com/p/moose-technology/issues/detail?id=114
The basic structure is in place. There are still a couple of things to do:
- include the changes to GeneralScrollPane
- solve the small scrolling animation problem
Status: New
Owner: tudor.gi...(a)gmail.com
CC: usman.bh...(a)gmail.com
Labels: Type-Defect Priority-High Platform-Pharo
New issue 736 by usman.bh...(a)gmail.com:
OrderedCollection(Object)>>doesNotUnderstand: #unsafeAdd:
http://code.google.com/p/moose-technology/issues/detail?id=736
Describe the problem: what do you get?
Message-not-understood: OrderedCollection(Object)>>doesNotUnderstand:
#unsafeAdd:
what do you expect?
a moose model
How to reproduce the problem: step by step if necessary
- download moose 4.6-dev
- import citezen (www.squeaksource.com/citezen)
- import citezen packages in moose
Additional information: platform, context which may impact the problem
- Mac OS x 10.6.6
Please fill in the labels with the following information:
* Type-Defect
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 740 by usman.bh...(a)gmail.com: classNamedOrNil test is bogus
http://code.google.com/p/moose-technology/issues/detail?id=740
There correct test should be
When we give a metaclass name we should get the metaclass of the class and
not nil
testClassNamedOrNil
"(self selector: #testClassNamedOrNil) debug"
self assert: (MooseUtilities classNamedOrNil: Model name) = Model.
self assert: (MooseUtilities classNamedOrNil: FAMIXNameResolver name) =
FAMIXNameResolver.
self assert: (MooseUtilities classNamedOrNil: (FAMIXNameResolver name ,
FAMIXNameResolver metaclassTag) asSymbol) = FAMIXNameResolver class
I discovered MooseMonticelloImporter…. :)
and some methods cannot compile :)
I would merge MooseMonticelloPopulator and MooseMonticelloVisitor (because this is about only 3 stupid accessors).
scope is undeclared. :(
sad it means that there are not tests :(
importFileNamed: name
| version definitions visitor progressBar step |
self setMooseModel.
[ version := self repository versionFromFileNamed: name. ]
on: Error
do: [:ex | self inform: 'Package ', name, ' not accessible from the file system?'. ^ self targetModel].
definitions := version snapshot definitions.
MooseCustomTask runWithProgress: [:bar |
visitor := MooseMonticelloClassPopulator new importer: self.
definitions do: [ :def | def accept: visitor.
bar increment].
] description: 'Importing classes' length: (definitions size).
self setSuperclassesAndCreateStubs.
"create a scope, this is necessary for the method visitor which is VW aware"
scope := Dictionary new.
self targetModel allClasses do: [:famixClass |
famixClass attributes do: [:famixAttribute |
(self scopeOfClass: famixClass) at: famixAttribute name bind: famixAttribute]].
MooseCustomTask runWithProgress: [:bar |
"import methods"
definitions do: [ :def |
(def isKindOf: MCMethodDefinition)
ifTrue: [
visitor := MooseMonticelloMethodPopulator new importer: self.
def accept: visitor.
self targetModel addAll: visitor entities]].
bar increment.
] description: 'Importing methods' length: (definitions size).
^ self targetModel
Here is a proposal
MooseTask
MooseAbstractImporter (which right now is not used and only contain
error handling and importingContext)
this class could hold the plugin mechanism that
would be run as a tearDown from now.
MooseImportingTask - Renamed SmalltalkImportingTask (add
importerClass logic)
MooseCompositeImporterTask
MooseSqueakClassPackageImporterTask
-> MoosePharoClassPackageExtractTask
MooseSqueakClasssCategoriesImporterTask -
>MoosePharoClassCategoriesExtractTask
MooseImportClassesTask ->
MooseExtractClassesTask
FileStructureImporter(/Extractor)
MooseOperator
Since we will not be able to inherit from the same superclass MSEReader and
MooseAbstractImporter.
We could define one trait to represent the plugin management and apply to
the MSEReader and MooseAbstractImporter.
So let us know what you think.
Stef and Usman
to have a default select: [:each | 'pac*' match
and to avoid to have ' in drop box and this is not in the latest version of
moose.
How do we know merge process work in moose?
Stef
Hi
this is still totally unclear to me how I can change Moose and get my changes not breaking parts of moose that I do not know
or are not loaded?
I want to work on the importer/extractor proposal I sent around last week.
So I can implement the changes but what is the process?
Stef
Hi,
Given a FAMIXClass, generated from a Java project parsed with Verveine-J,
is it possible to know the classes that it imports? I am referring to this
kind of information:
import org.argouml.application.events.ArgoDiagramAppearanceEvent;
import org.argouml.application.events.ArgoEventPump;
It should be easy to write a parser that gets these "imports" from the
completeText of the FAMIXFileAnchor, but I don't want to write it if I can
have this information more easily.
Thanks again.
Cheers,
Alberto
--
View this message in context: http://moose-dev.97923.n3.nabble.com/Classes-and-Namespaces-imported-by-a-J…
Sent from the moose-dev mailing list archive at Nabble.com.
what about?
"MooseMonticelloImporter is a dedicated Smalltalk importer that extends the default Smalltalk importer to deal with classes and methods that are not loaded in memory but contained in Monticello packages."
I imagine…
so I will publish that and we fix it if this is wrong.
Stef
Doru
This package is bogus because it is incomplete. The importing superclasses taks are missing. They should not be in another package.
It is a pain to find our way. Because these classes are not in the Moose-GenericImporter too.
but somewhere in between. MooseImportingTask should not be in generic importer too. because it is only for Smalltalk.
So I started to commit some changes.
Stef
ManifestMfBundle has not been documented yet. The class comment should describe the purpose of the class, its collaborations and its variables.
Instance Variables:
name <ProtoObject | PseudoContext>
requiredBundles <Collection>
ManifestMfImporter has not been documented yet. The class comment should describe the purpose of the class, its collaborations and its variables.
Instance Variables:
bundles <(Collection of: Object)>
Why people do not put comments in classes?
Am I that stupid that I do not understand anything?
It is really annoying to have to guess all the time. I crawl crawl and crawl.
Stef
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 744 by usman.bh...(a)gmail.com: SmalltalkImporter should be renamed
SmalltalkExtractor
http://code.google.com/p/moose-technology/issues/detail?id=744
to convey the fact that it goes from source code to model