Moose-dev February 2010

moose-dev@list.inf.unibe.ch

17 participants
31 discussions

by Alexandre Bergel

Hi Jannik, Few weeks ago you apparently spotted a problem due to the last change I made on Mondrian. DSM was really slow. Is this problem still present? cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

15 years, 4 months

Problems using java code importer with inFusion under windows

by Fabrizio Perin

Hi, i was using moose in windows and i had an error trying to use the function "import from Java source with inFusion". Seems that OSProcess doesn't work properly. To reproduce the error just try to import java code using this function in the Moose panel in windows. In Mac i never had problem using that cool function. Anybody can help me to figure out where the problem is? Thanks in advance for the support, Fabrizio PS: Here the stack trace: --- The full stack --- UndefinedObject(Object)>>doesNotUnderstand: #nextPutAll: ExternalWindowsOSProcess>>value ExternalWindowsOSProcess class>>command: WindowsProcess>>command: WindowsProcess>>waitForCommand: OSProcess class>>waitForCommand: MooseImportFromJavaSourceFilesWizard>>validateImportation [] in MooseImportFromJavaSourceFilesWizard>>performTerminateButtonAction [] in ProgressInitiationException>>defaultAction BlockClosure>>ensure: ProgressInitiationException>>defaultAction UndefinedObject>>handleSignal: MethodContext(ContextPart)>>handleSignal: ProgressInitiationException(Exception)>>signal ProgressInitiationException>>display:at:from:to:during: ProgressInitiationException class>>display:at:from:to:during: PSUIManager(MorphicUIManager)>>displayProgress:at:from:to:during: MooseImportFromJavaSourceFilesWizard>>performTerminateButtonAction WizardLastPane>>terminateButtonAction PluggableButtonMorphPlus(PluggableButtonMorph)>>performAction PluggableButtonMorphPlus>>performAction [] in PluggableButtonMorphPlus(PluggableButtonMorph)>>mouseUp: Array(SequenceableCollection)>>do: PluggableButtonMorphPlus(PluggableButtonMorph)>>mouseUp: PluggableButtonMorphPlus>>mouseUp: PluggableButtonMorphPlus(Morph)>>handleMouseUp: MouseButtonEvent>>sentTo: PluggableButtonMorphPlus(Morph)>>handleEvent: PluggableButtonMorphPlus(Morph)>>handleFocusEvent: [] in HandMorph>>sendFocusEvent:to:clear: [] in PasteUpMorph>>becomeActiveDuring: BlockClosure>>on:do: PasteUpMorph>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendMouseEvent: HandMorph>>handleEvent: HandMorph>>processEvents [] in WorldState>>doOneCycleNowFor: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Array(SequenceableCollection)>>do: WorldState>>handsDo: WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: PasteUpMorph>>doOneCycle [] in Project class>>spawnNewProcess [] in BlockClosure>>newProcess

15 years, 4 months

Famix2MSE importer Available in PharoMoose

by Laval Jannik

Hi all, With Cyrille we work on a Famix2MseImporter in Pharo Famix3. It is a hack, in two parts: First, we place a script between the parser and the MooseElement creation. So this script switches elements of Famix2 to Famix3. For example, a FAMIX.InheritanceDefinition in the Famix2Mse become a FamixInheritance in Famix3. The other part of the script appears after the mooseModel creation. In Famix3, there are FamixAccess and FamixReference. But in Famix2, there is only FamixAccess. FamixReference is for a target with type FamixClass. But, when the parser works, it is not easily possible to know the type of an attribute. So, to do it easy, when the MooseModel is created, we check all accesses and test if the target is a FamixClass. If true, the script change the link in a FamixReference. Now, we have three elements with no possible switch: - there is no FAMIXGlobalVariable>>declaredType in Famix2. - in Famix3, FAMIXInvocation>>receivingVariable has disappeared. - in Famix3, FAMIXParameter>>position has disappeared. The meta-informations in Famix2Mse are not taken account. Finally, this script is a hack, the aim is to provide a solution for people who want to come to Pharo-Moose. You can load it with: Gofer new squeaksource: 'Famix2Importer'; package: 'Famix2Importer'; load. A menu item is available in MoosePanel menu. You can try it and mail us if you have some bugs. Cheers, Jannik and Cyrille.

15 years, 4 months

[Mondrian] Issue #319 solved

by Alexandre Bergel

Name: Mondrian-Alexandre_Bergel.366 Author: Alexandre Bergel Time: 18 February 2010, 1:44:56 am UUID: 7a842f26-b887-4342-bb53-6e254dda0152 Ancestors: Mondrian-Alexandre_Bergel.365 Mondrian-Alexandre_Bergel.366 Before this version, form builder could not be embedded in a subview. The reason is that asking what is the size of a form shape triggered a new recomputation of each bounds shape. Therefore, all the subnodes form shape appeared to be at the same location. MOFormsShape>>widthFor: and heightFor: simply lookup in cacheShapeBounds instead of recomputing the whole thing. Naturally, a test has been added to MOFormsBuilderTest . This f**king beast entertained my long evening. But at least, I got rid of it. In addition to this, I did some cleaning. This version addresses the issue #319 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

15 years, 4 months

Problems using java code importer with inFusion under windows

by Fabrizio Perin

15 years, 4 months

[Mondrian] Issue 275 fixed

by Alexandre Bergel

Name: Mondrian-Alexandre_Bergel.365 Author: Alexandre Bergel Time: 17 February 2010, 9:53:58 pm UUID: b6d63f96-53a1-4148-9606-7a2a5020f94d Ancestors: Mondrian-Alexandre_Bergel.364 Mondrian-Alexandre_Bergel.365 fromPositions and toPositions may now be set to #() This is necessary to make the arrow attach fixed in a forceBasedLayout. This new version solve the issue #275 Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

15 years, 4 months

New version of XMLParser

by Alexandre Bergel

Dear List, I incorporated some changes of XMLParser proposed by jaayer(a)zoho.com These changes may break some existing applications. For example, I had to adapt CAnalyzer. ConfigurationOfXMLSupport has now #version102: Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

15 years, 4 months

Moose becomes modular...

by Laval Jannik

I have simulated a remove cycle process. Manually I move some elements in a mooseModel of Moose. To remove all cycles in Moose, my conclusions are: ===== >extend method>> Smalltalk::FAMIXClass.browseSource() in Moose-Finder. >extend method>> Smalltalk::FAMIXMethod.browseSource() in Moose-Finder. >move class>> Smalltalk::MPImportSTCommand in Moose-Wizard. >move class>> Smalltalk::MPImportJavaSourceFilesWithInFusionCommand in Moose-Wizard. >extend method>> Smalltalk::FAMIXNamedEntity.isAbstract() in Famix-Extensions. >extend method>> Smalltalk::FAMIXNamedEntity.isAbstract:(Object) in Famix-Extensions. >extend method>> Smalltalk::FAMIXClass.isAbstract() in Famix-Extensions. >extend method>> Smalltalk::CompiledMethod.mooseName() in Famix-Implementation. >extend method>> Smalltalk::CompiledMethod.mooseNameWithScope:(Object) in Famix-Implementation. >remove reference>> checkClass: refers to MooseModel. >extend method>> Smalltalk::MooseModel.mseExportationTest() in Moose-SmalltalkImporterTests. >move class>> Smalltalk::MooseScripts in Moose-SmalltalkImporter. >remove method>> Smalltalk::FAMIXClass.ascendingPathTo:(Object). >extend method>> Smalltalk::FAMIXPackage.definedMethods() in Famix-Extensions. >extend method>> Smalltalk::FAMIXPackage.extendedClasses() in Famix-Extensions. >extend method>> Smalltalk::FAMIXPackage.extendedClassesGroup() in Famix-Extensions. >extend method>> Smalltalk::FAMIXPackage.extensionClasses() in Famix-Extensions. >extend method>> Smalltalk::FAMIXPackage.extensionClassesGroup() in Famix-Extensions. >extend method>> Smalltalk::FAMIXPackage.extensionMethods() in Famix-Extensions. >extend method>> Smalltalk::FAMIXPackage.localMethods() in Famix-Extensions. >extend method>> Smalltalk::FAMIXPackage.localClasses() in Famix-Extensions. >extend method>> Smalltalk::FAMIXPackage.localClassesGroup() in Famix-Extensions. ===== Is it ok for you ? Cheers Jannik

15 years, 4 months

Some yellow test in CAnalyzer

by Alexandre Bergel

Hi Cyrille, When I run the test of CAnalyzer I have 36 run, 33 passes, 1 expected failures, 2 failures, 0 errors, 0 unexpected passes. (I haven't updated Moose however, my connection is not optimal for this now). Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

15 years, 4 months

mondrian translateBy:

by Tudor Girba

Hi, I refactor the logic of translateTo: and translateBy: in Mondrian. Now translateTo: moves the element to the position by just delegating to translateBy: with the difference from the current position. I also added translateBy:bounded: to distinguish between the use case of limiting the space when draggin and droping, while allowing it to position anywhere during lay out. This was important because I also upgraded a bit the DominanceTreeLayout to position each level at the same y position so that we can finally distinguish layers. I am saying finally because this was always the goal of this layout :). All tests are green, but in case you encounter problems, please let me know. Cheers, Doru -- www.tudorgirba.com "Every now and then stop and ask yourself if the war you're fighting is the right one."

15 years, 4 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev February 2010