- Moose-dev - INF Mailman

Bug fix for InputEventSensor (incomplete initialization)

by Alexandre Bergel

Ready to be reviewed: http://code.google.com/p/pharo/issues/detail?id=5501 Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

13 years, 3 months

1
0
0 0

Other reengineering platform for dynamic languages?

by Alexandre Bergel

Hi! Moose is able to process code written in Smalltak, a dynamically typed languages. Is there other platform that would work with python, ruby or groovy? I did some googling, but nothing apparent emerged. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

13 years, 3 months

1
0
0 0

Re: Jenkins build is still unstable: moose-latest-dev #886

by Moose

I updated Pharo to the latest version. It looks like multiple tests fail because something changed in the computation of allRecursiveTypes. Cheers, Doru On 15 Mar 2012, at 22:48, Alexandre Bergel wrote: > How comes there are so many failed tests ? > > Alexandre > > > On 15 Mar 2012, at 16:46, admin(a)moosetechnology.org wrote: > >> See <http://hudson.moosetechnology.org/job/moose-latest-dev/886/> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

13 years, 3 months

4
6
0 0

Re: [Pharo-project] Does anyone have tried/succeeded to use PetitParser for parsing dates?

by Tudor Girba

Hi, I used it for various forms of dates. What is the question? Cheers, Doru On 14 Mar 2012, at 16:24, Friedrich Dominicus wrote: > I wonder if anyone has used PetitParser to parse dates in diverse > formats. > e.g > 01/01/2012 > 07/31/2012 > > And with failures on things like > 2012-07-32 or > 2012-13-01 or > 2012-02-30 or > 2011-02-29 > > Regards > Friedrich > > > > > > -- > Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim > Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus > -- www.tudorgirba.com "One cannot do more than one can do."

13 years, 3 months

1
0
0 0

Re: Jenkins build is unstable: moose-latest-dev #881

by Tudor Girba

Thanks a lot. I just needed to set the author before compiling and it worked! Now we have 3 tests that fail. I I guess this is a pharo issue. Could you report it? Cheers, Doru Sent from my iPhone On Mar 14, 2012, at 17:21, Alexandre Bergel <abergel(a)dcc.uchile.cl> wrote: > Apparently, this will also fix the Fame failing tests :-) > Today is a good day :-) > > Alexandre > > > On 14 Mar 2012, at 10:07, Alexandre Bergel wrote: > >> I lunched a headless image and checked what happened. Apparently instances of InputEventSensor are not properly initialized in a headless mode. This seems to solve the Glamour failing tests. >> >> Can you try something? In the script you use to lunch the tests, can you add before running the tests? >> -=-=-=-=-=-=-=-=-=-=-=-= >> InputEventSensor compile: 'initialize >> super initialize. >> eventQueue := WaitfreeQueue new. >> mouseButtons := 0. >> mousePosition := 0 @ 0. >> modifiers := 0 '. >> InputEventSensor allInstances do: #initialize. >> -=-=-=-=-=-=-=-=-=-=-=-= >> >> I suspect this will help. No idea whether this will solve the Fame problem or not. >> >> Cheers, >> Alexandre >> >> >> >> On 14 Mar 2012, at 07:55, Tudor Girba wrote: >> >>> Hi, >>> >>> This is the only test that is like this. The other failures I cannot >>> reproduce locally. >>> >>> It would be great if you could take a look and see if you can reproduce them. >>> >>> Cheers, >>> Doru >>> >>> On Wed, Mar 14, 2012 at 1:42 PM, Alexandre Bergel >>> <alexandre.bergel(a)me.com> wrote: >>>> We have those 12 failing test since a long time already. >>>> I checked some of the tests, and apparently they are due to the underlying Morph. For example: >>>> | browser | >>>> browser := GLMExpander new. >>>> browser show: [ :a | a text ]. >>>> window := browser openOn: #(#a #b #c). >>>> >>>> testCreation expect to have "window submorphs last class == MorphTreeMorph", however it gets GeneralScrollPane. Shouldn't the test be simply updated? >>>> >>>> Is there anything I could do to help? >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> On 14 Mar 2012, at 06:15, admin(a)moosetechnology.org wrote: >>>> >>>>> See <http://hudson.moosetechnology.org/job/moose-latest-dev/881/> >>>>> >>>>> >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

13 years, 3 months

4
5
0 0

DistributionMap windows size

by Guillaume Larcheveque

We wanted to open a DistributionMap with a given windows size. Any idea how to do it? We looked with stef in the MOViewRenderer class but nothing jumps to our eyes. Thanks. -- *Guillaume Larcheveque*

13 years, 3 months

3
6
0 0

Moose Model of Java Project with nested namespacing

by Dennis Schenk

Hi, I used inFamix to create an .mse File of Jython <http://www.jython.org/>. All works well except the namespacing seems to be a bit off in the model, e.g. there is a namespace called jython and another one called jython::util but the first is not defined as parentPackage of the latter. I think they should be thought - at least for Java systems. Mircea Lungu told me there was a class floating around somewhere which fixes this for moose models. Could anyone point me to it? I'd like to use it for testing. Also, is inFamix maybe capable of doing that but I haven't found it? Or are there other tools which do the importing with namespaces linked in this way? Cheers, Dennis

13 years, 3 months

3
2
0 0

Space is low

by Alberto Bacchelli

Hi all, I am trying to import an MSE file [1] generated by Verveine-J into the latest moose-latest-dev image [2]. My image is basically the same you find in the Jenkins build and I am running it on MacOS 10.7.3. When the parsing of the file is almost completed I get this dialog: "Space is low Warning! Pharo is almost out of memory! Low space detection is now disabled. [...]" By simply closing all the windows and restarting the image, I have no luck: The message still appears. The message also suggests to "restart the Pharo VM with a larger memory allocation." Unfortunately I have no idea on how to do this in general, and on a Mac in particular. I looked at previous threads in the mailing list, but I was not able to find any solution. Can anyone help me with this problem, please? Thank you in advance. Cheers, Alberto [1] http://www.inf.usi.ch/phd/bacchelli/svn_2011_06_30.mse.zip [2] http://ci.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/arti… -- View this message in context: http://moose-dev.97923.n3.nabble.com/Space-is-low-tp3823370p3823370.html Sent from the moose-dev mailing list archive at Nabble.com.

13 years, 3 months

3
4
0 0

[Fwd: Re: Re: Glamour/Magritte example Re: Re: Glamour-Examples comparison 4.5 v 4.6 - Class GLMBasicExamples]

by Ben Coman

I've had some trouble with email. I'm not sure if this one made it out or if I just didn't get it back from the list. I would have missed any responses. Ben Coman wrote: 8<----cut------- > So in the end I added 'self update' to the start of > GLMMagrittePresentation>>reactOnAnswerFor: as follows... > reactOnAnswerFor: aValue > self update. > ^ answerBlock glamourValue: > (aValue asGlamorousMultiValue, > self asGlamorousMultiValue, > self entity asGlamorousMultiValue) > > and now the <cancel> button works as expected. However I still don't > know what reactOnAnswerFor is meant to do, or if there > is a more appropriate way of achieving this. Please let me know. > > I also haven't had any success getting the #list pane to refresh when > a change is saved on the #detail pane. Any assistance will be greatly > appreciated. > > cheers, -ben > Phew! That was a lot to take in. Upon further investigation I retract modifying GLMMagrittePresentation. The solution to both the <save> and <cancel> buttons can be encompassed entirely within the user code with one additional line 'onAnswer:' magritteParentPrototype := a magritte. magritteParentPrototype "these are the essential parts" title: 'Details'; description: [:person | person magritteDescription] ; onAnswer: [ :ignore | browser update ] . I have uploaded this as Glamour-Examples-BenComan.230 Note that I think this only worked for me last time when I had MagritteMagic loaded onto Moose 4.6. cheers, Ben

13 years, 3 months

2
3
0 0

Moose Windows VM problem

by Usman Bhatti

Hello, I have a one-click moose image downloaded around first week of Feb 2012. The problem with the image is that it's windows vm that does not launch the image file. In fact, when I execute the vm, it creates a process (visible in windows task manager) but nothing happens. We tried to debug it with Igor but we couldn't (as there is no entry point). The image in the bundle can be launched with latest windows vm (from pharo server) [meaning that the problem comes from the vm which we cannot debug]. I downloaded another moose image today and executed its windows vm, and its working fine. It would be good to have a jenkins process to run moose on windows vm. Do we have such a setup? If not, I can create one in the coming weeks. thanx, usman

13 years, 3 months

1
0
0 0

VerveineJ/Java and activations from non java code

by Holger Hans Peter Freyther

Hi again, I am still exploring moose and my immediate usage is to identify dead code (classes, methods, variables). There are two issues I am facing with false-positive. 1.) In java a lot is configured/instantiated via the usage of XML. E.g. the Log4J configuration happens via xml, another example would be the menu structure of an Eclipse plugin. What would be the easiest way to represent these usages in a .mse file? Is there a tool to merge two .mse files or combine them? 2.) The attribute/field detection of verveineJ does not see all variable usages, e.g. it appears that it can not resolve a "this.foo" properly (e.g. in a constructor, or in an anonymous class). I will try to have a minimal testcase to show this issue (as my time permits). holger

13 years, 4 months

3
2
0 0

Good evening

by rafat al_s3ode

firstly, i would to thank all that supporting mosse for ussecondly, i want any one help me with details, now i have a java project built with eclipse, i want to parser all project through Famix using VerveinJ to get all information about the code number of attribute and methods classes etc. with my best regards With My Best Regards Ra'fat Ahmad Ali AL-Msie'Deen Phone # : 0033761712744E-mail : rafatals3ode(a)yahoo.com Take Care

13 years, 4 months

1
0
0 0

XML Data Parsing

by Júlio Martins

> > Correcting what I told... > > Hi, >>> >>> You can probably save time and memory by directly passing the file >>> stream to the XMLParser: >>> stream := (FileStream readOnlyFileNamed: aFilenameString) readStream. >>> root := (XMLDOMParser parse: stream) root. >>> >> >> I follow your suggestion Tudor, but it didn't reduce the total time >> expended on reading of data or the reduction was minimal. >> >> >>> A question: if you do you have a problem with the reading part (I mean >>> to compute the root), or is it spent in the follow up loops? >>> >> >> I not understood well your question. >> > I was able to compute almost everything that I needed, *but for some >> reason, some data are lost when I iterate on root* >> > > In truth it can be correct, I messed up to interpret the data. > >> >> > >> >> >>> Cheers, >>> Doru >>> >>> >>> >>> 2012/3/9 Júlio Martins <[hidden email]<http://user/SendEmail.jtp?type=node&node=4459560&i=0> >>> >: >>> >>> > HI! >>> > >>> > I have a optimization problem to solve and I would want some hint of >>> you. >>> > >>> > I am using the xml framework to work with data from xml file, and the >>> > reading of the data is consuming much time. >>> > In my code I do something as: >>> > >>> > | stream root | >>> > >>> > stream := (FileStream readOnlyFileNamed: aPath) contentsOfEntireFile >>> > asString.. >>> > root := (XMLDOMParser parse: stream) root. >>> > >>> > root allElementsNamed: 'something' do:[ :eachB| >>> > eachB attributeNodes attributeValueAt: 'list' >>> > ... >>> > eachB allElementsNamed: 'another something' do:{ :eachD| >>> > . eachD attributeNodes attributeValueAt: 'element' >>> > .. >>> > ] >>> > ] >>> > >>> > I know such iteration like that take much time to be executed when the >>> file >>> > read is big. There is a another manner to read the data from xml file >>> that >>> > consume less time as possible? Or have someone an idea to improve this >>> code? >>> > >>> > Julio >>> > >>> > ________________________________ >>> > View this message in context: XML Data Parsing >>> > Sent from the Moose mailing list archive at Nabble.com. >>> > >>> > _______________________________________________ >>> > Moose-dev mailing list >>> > [hidden email] <http://user/SendEmail.jtp?type=node&node=4459560&i=1> >>> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> > >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] <http://user/SendEmail.jtp?type=node&node=4459560&i=2> >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> >> ------------------------------ >> View this message in context: XML Data Parsing<http://forum.world.st/XML-Data-Parsing-tp4459560p4459560.html> >> Sent from the Moose mailing list archive<http://forum.world.st/Moose-f1310756.html>at Nabble.com. >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> > -- View this message in context: http://forum.world.st/XML-Data-Parsing-tp4459626p4459626.html Sent from the Moose mailing list archive at Nabble.com.

13 years, 4 months

1
0
0 0

Re: XML Data Parsing

by Júlio Martins

Correcting what I told... Hi, >> >> You can probably save time and memory by directly passing the file >> stream to the XMLParser: >> stream := (FileStream readOnlyFileNamed: aFilenameString) readStream. >> root := (XMLDOMParser parse: stream) root. >> > > I follow your suggestion Tudor, but it didn't reduce the total time > expended on reading of data or the reduction was minimal. > > >> A question: if you do you have a problem with the reading part (I mean >> to compute the root), or is it spent in the follow up loops? >> > > I not understood well your question. I got to compute almost everything > that I needed, *but for some reason, some data are lost when I iterate on > root* > In truth it can be correct, I messed up to interpret the data. > > > > >> Cheers, >> Doru >> >> >> >> 2012/3/9 Júlio Martins <[hidden email]<http://user/SendEmail.jtp?type=node&node=4459560&i=0> >> >: >> >> > HI! >> > >> > I have a optimization problem to solve and I would want some hint of >> you. >> > >> > I am using the xml framework to work with data from xml file, and the >> > reading of the data is consuming much time. >> > In my code I do something as: >> > >> > | stream root | >> > >> > stream := (FileStream readOnlyFileNamed: aPath) contentsOfEntireFile >> > asString.. >> > root := (XMLDOMParser parse: stream) root. >> > >> > root allElementsNamed: 'something' do:[ :eachB| >> > eachB attributeNodes attributeValueAt: 'list' >> > ... >> > eachB allElementsNamed: 'another something' do:{ :eachD| >> > . eachD attributeNodes attributeValueAt: 'element' >> > .. >> > ] >> > ] >> > >> > I know such iteration like that take much time to be executed when the >> file >> > read is big. There is a another manner to read the data from xml file >> that >> > consume less time as possible? Or have someone an idea to improve this >> code? >> > >> > Julio >> > >> > ________________________________ >> > View this message in context: XML Data Parsing >> > Sent from the Moose mailing list archive at Nabble.com. >> > >> > _______________________________________________ >> > Moose-dev mailing list >> > [hidden email] <http://user/SendEmail.jtp?type=node&node=4459560&i=1> >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] <http://user/SendEmail.jtp?type=node&node=4459560&i=2> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > ------------------------------ > View this message in context: XML Data Parsing<http://forum.world.st/XML-Data-Parsing-tp4459560p4459560.html> > Sent from the Moose mailing list archive<http://forum.world.st/Moose-f1310756.html>at Nabble.com. > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- View this message in context: http://forum.world.st/Re-Moose-dev-XML-Data-Parsing-tp4459619p4459619.html Sent from the Moose mailing list archive at Nabble.com.

13 years, 4 months

1
0
0 0

XML Data Parsing

by Júlio Martins

> > Hi, > > You can probably save time and memory by directly passing the file > stream to the XMLParser: > stream := (FileStream readOnlyFileNamed: aFilenameString) readStream. > root := (XMLDOMParser parse: stream) root. > I follow your suggestion Tudor, but it didn't reduce the total time expended on reading of data or the reduction was minimal. > A question: if you do you have a problem with the reading part (I mean > to compute the root), or is it spent in the follow up loops? > I not understood well your question. I got to compute almost everything that I needed, but for some reason, some data are lost when I iterate on root. Is about it your question? > Cheers, > Doru > > > > 2012/3/9 Júlio Martins <jleandro.martins(a)gmail.com>: > > HI! > > > > I have a optimization problem to solve and I would want some hint of you. > > > > I am using the xml framework to work with data from xml file, and the > > reading of the data is consuming much time. > > In my code I do something as: > > > > | stream root | > > > > stream := (FileStream readOnlyFileNamed: aPath) contentsOfEntireFile > > asString.. > > root := (XMLDOMParser parse: stream) root. > > > > root allElementsNamed: 'something' do:[ :eachB| > > eachB attributeNodes attributeValueAt: 'list' > > ... > > eachB allElementsNamed: 'another something' do:{ :eachD| > > . eachD attributeNodes attributeValueAt: 'element' > > .. > > ] > > ] > > > > I know such iteration like that take much time to be executed when the > file > > read is big. There is a another manner to read the data from xml file > that > > consume less time as possible? Or have someone an idea to improve this > code? > > > > Julio > > > > ________________________________ > > View this message in context: XML Data Parsing > > Sent from the Moose mailing list archive at Nabble.com. > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- View this message in context: http://forum.world.st/XML-Data-Parsing-tp4459560p4459560.html Sent from the Moose mailing list archive at Nabble.com.

13 years, 4 months

1
0
0 0

XML Data Parsing

by Júlio Martins

HI! I have a optimization problem to solve and I would want some hint of you. I am using the xml framework to work with data from xml file, and the reading of the data is consuming much time. In my code I do something as: | stream root | stream := (FileStream readOnlyFileNamed: aPath) contentsOfEntireFile asString.. root := (XMLDOMParser parse: stream) root. root allElementsNamed: 'something' do:[ :eachB| eachB attributeNodes attributeValueAt: 'list' ... eachB allElementsNamed: 'another something' do:{ :eachD| . eachD attributeNodes attributeValueAt: 'element' .. ] ] I know such iteration like that take much time to be executed when the file read is big. There is a another manner to read the data from xml file that consume less time as possible? Or have someone an idea to improve this code? Julio -- View this message in context: http://forum.world.st/XML-Data-Parsing-tp4459406p4459406.html Sent from the Moose mailing list archive at Nabble.com.

13 years, 4 months

3
2
0 0

Metadata queries in Google datastore

by Andre Hora

Similar to our meta meta model...no? :) http://code.google.com/appengine/docs/java/datastore/metadataqueries.html

13 years, 4 months

2
1
0 0

Glamour-Examples comparison 4.5 v 4.6 - Class GLMBasicExamples

by Ben Coman

btw, I am on Windows 7. The GLMExamplesBrowser menu item [View browser tree] is interesting... NEW IN 4.6 Do the following demonstrate new functionality in 4.6 or just a new example of existing 4.5 functionality ? #formatAsWords - what does this have to do with composites protocol? #listDragAndDrop new to 4.6 - very nice :) A useful addition would be allowing drop onto background of [Target] (which might be item + 0) Dropping onto a number in [Source] causes an error An additional comment to describe operation of the example would be useful eg.. "Drag a number from Source into Target dropping on either an item or the background" #smalltalkCode #spawnBrowserActions - it would be useful to also see how a single selected item could be opened in a new window - not just the whole list) #spawnBrowserSelectionActions (note, the method of in-comment example is incorrect) [*1] operational change... 4.5 has a default window menu ==> 4.6 does not - why the difference ?[3] [*2] finder list ==> finder show: [ :a | a list browser text ==> browser show: [ :a | a text finder table ==> finder show: [ :a | a table Browser menu #simpleFinderWithMenu Filter #multipleFinderWithFilter Finder #simpleFinder Populate port action #populatePortAction Search #multipleFinderWithFilterAndSearch Toolbar #browserWithToolbar Tabs with different labels #tabsWithDifferentLabels #treeWithInitialSelection - actually this gets a MNU GLMTabulator>>text in 4.6 - needs one more refactoring [*3] #using seems to be being purged from Glamour. Perhaps to remove a lot of methods from GLMBrowser & GLMTPresentationBuilder, leaving these only in GLMCompositePresentation. Examples... showOn: ... using: [ browser mondrian ==> transmit to: .... andShow: [ :a | a mondrian showOn: ... using: [ browser list ==> transmit to: ... andShow: [ :a | a list showOn: ... using: [ browser morph ==> transmit to: ... andShow: [ :a | a morph Action list #simpleActionList Allowing all nil #allowAllNil Allowing nil #allowNil Drop-down #dropDownList [ Drop-down with initial value #dropDownListWithInitialValue Fix size pane #fixSizePanes Morph icons #morphIcons Tags #compoundTaggedTree Updated selection #listsWithUpdatedSelection (no glmBrowser pragma) #singleInitialSelection [*4] #sendTo:from:with: ==> #transmit:port: ; #from: ; #transformed Updated selection #listsWithUpdatedSelection [*6] Transcript ==> Inspector (not really a significant change?) Action list #simpleActionList [*3,6] Menus #staticAndDynamicMenu [*6] DOES NOT WORK IN 4.6 #interdependentPanes - code is flagged as not working. does not work in 4.5 either. FIXED IN 4.6, WAS NON-WORKING IN 4.5 Double click #doubleClick #simpleTable #textPortsExamples #accumulator - Accumulator - looks like an example design change to separate concerns. Double clicking a number in the left pane, in the right pane brings up... 4.5 - number tab with sub-tabs 'List' & 'Text' as well as a connect-menu item 'Inspect' 4.6 - number tab only, no sub-tabs or context menu WORKS FROM EXAMPLE BROWSER BUT NOT FROM METHOD COMMENT #textSelection - execute from method comment works in 4.5 but fails in 4.6 with unknown selector #textSelectionInterval. OPERATES THE SAME - CODE DIFFERENCE AS NOTED Dashboard #dashboard Dashboard specifying extents #dashboardWithSpecificExtents Dashboards in dashboard #dashboardsInDashboard Composite arrangements #differentComposites Complex morphs (StarBrowser simulation) #starBrowser EyeSee interactive bar chart #eyeseeBarDiagram Mondrian painting #mondrianPainting Multiple actions #multipleActions Simple Expander #simpleExpander Smart lists #treeWithAmountFiltering Stacker #stacker Tabs with different actions #tabsWithDifferentActions Three inter-dependent panes #threeInterdependentPanes Tree with children by level #treeWithChildrenByLevel Tree with expansion #treeWithExpansion (no glmBrowser pragma) #taggedTree (no glmBrowser pragma) #multiInitialSelection [*1,3] - but I am only able to multi-select contiguous items with the SHIFT key. I am unable to multi-select non-contiguous items as I would expect using the CTRL key. Instead a context menu for MorphTreeMorph appears. Is this unfortunate behaviour just me? #magritte - This was one a was I was REALLY interested to see regarding the update to Magritte 3. However the code is identical to 4.5. Both 4.5 and 4.6 produce the same error.... [Save] ==> error MAWriteError: Not supposed to write to something. [Cancel] ==> no change. Now without knowing anything about Magritte, I would expect the text box to revert to the original text. What would actually be a fantastic example here would be a small address book of a few entries that browsed a list in one pane and in another the magritte detail could be edited. #tableWithIcons 4.6 also adds alternating icons. 4.5 broken & does not transmit to next pane, but same code to 4.6 does work. selectionAct: [:tree | tree inspect ] ==> selectionAct: [:tree | tree selection inspect ] This has been improved in 4.6 to auto-expand when moving from [first tree] to [second tree] However in both 4.5 & 4.6, upon initial opening and when switching from [first tree] to [second tree] an erroneous additional line spacing occurs as shown in _ treeWithInitialSelection-extra-line-spacing.jpg _ (attached) #treeWithMenu - might need the same change to selectionAct: as for #tableWithIcons #treeWithTags [*1] #treeWithTagsMoreLevels [*1] - it would be good if after deselecting the tags, it remembered which node had previously been expanded. When when I click a tag twice, I expect to get back the same view I had before. #updateableBrowser [*1] Completely different code and operation. What is the difference in operation between the 'Upadted automatically' tab and 'Updated via menu' - #validator [*6] #validatorDynamic [*6] - but I don't actually see any difference to operation of #validator method - what am I missing ? #wizard - it is not clear how to get the selected items

13 years, 4 months

3
11
0 0

talks about moose

by Tudor Girba

Hi, I would be interested in collecting talks related to Moose and announcing them on the website. Have any of you given any recently? Or maybe will give some in the near future? Cheers, Doru -- www.tudorgirba.com "Not knowing how to do something is not an argument for how it cannot be done."

13 years, 4 months

2
1
0 0

Re: [Pharo-project] problem: nautilus forked moose-algos

by Tudor Girba

I updated the base Pharo image, and now Nautilus loads properly in the Moose image: http://ci.moosetechnology.org/job/moose-latest-dev/ Thanks. Cheers, Doru On 4 Mar 2012, at 15:35, Tudor Girba wrote: > Thanks for the pointer. I will update the base image. > > Cheers, > Doru > > > On 4 Mar 2012, at 15:22, Mariano Martinez Peck wrote: > >> >> >> On Sun, Mar 4, 2012 at 2:39 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi, >> >> I saw that you removed the problematic parts, but now CofigurationOfNautilus throws a loading error, because MonticelloAnnouncer is not present when NautilusMCBindings gets loaded. >> >> Are you loading in the LASTEST pharo core 1.4? I think MonticelloAnnouncer was added just recently (in fact, for Nautilus). >> >> Cheers >> >> >> Could you take a look? >> >> Cheers, >> Doru >> >> >> On 3 Mar 2012, at 23:42, Benjamin wrote: >> >>> I will remove that and push it into another repo. >>> >>> It was a plugin started by Jannik, but never finished :) >>> >>> Thanks for report :) >>> >>> Ben >>> >>> On Mar 3, 2012, at 9:41 PM, Tudor Girba wrote: >>> >>>> Hi, >>>> >>>> Nautilus includes NautilusCommon and this in turn includes NautilusCommon-Plugin-JannikAlgo which copies verbatim a part of the classes from the Moose-Algos-Graph package from http://www.squeaksource.com/MooseAlgos. >>>> >>>> These classes are used in a plugin. Because of this, we cannot use Nautilus in Moose. >>>> >>>> So, I would suggest one of these: >>>> - remove the plugin, at least from the default configuration >>>> - load Moose-Algos-Graph properly >>>> - fork with a different name >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Yesterday is a fact. >>>> Tomorrow is a possibility. >>>> Today is a challenge." >>>> >>>> >>>> >>>> >>> >>> >> >> -- >> www.tudorgirba.com >> >> "Obvious things are difficult to teach." >> >> >> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > -- > www.tudorgirba.com > > "There are no old things, there are only old ways of looking at them." > > > -- www.tudorgirba.com Things happen when they happen, not when you talk about them happening.

13 years, 4 months

1
0
0 0

Re: MSE duplicated entities

by roberto.minelli＠usi.ch

The simple project analyzed is this one http://goo.gl/vAhfO Without adding the Android SDK sources the MSE is fine. Then I copied the Android SDK in the source folder of the project (this because I need to extract dependencies between Android apps and Android SDK). In this way the MSE is wrong. If you're interested in reproduce my case you can download the Android SDK (from http://developer.android.com/sdk/index.html) and copy the "android" folder in the "src" folder of the ZoomerWithKeys project. Then try to generate the mse and take a look at the 'mZoomIn' attribute, for example. The classes do not appear twice and they do not appear in different packages, as I said the project has just one single class ;) Thanks for your interest, RM > Hi, > > This is strange. If it is like that, it is a bug. However, I would like to learn more about the structure of your sources. Could it be that these classes appear twice? Or maybe that they appear in different packages? > > Are these source available? > > Cheers, > Doru > > > On 3 Mar 2012, at 15:38, roberto.minelli(a)usi.ch wrote: > >> Dear all, >> >> I have a question regarding inFamix and the MSE format. >> >> I have an Android project composed by a single class. I need to perform an analysis on the Invocations. For this reason I need the source code of the library called. Thus I copied some of the sources of the Android SDK inside the src folder of the project. When I generate the MSE file of the project I end up having a problem: Each FAMIX entity, i.e., FAMIX.Attribute, appears twice in the MSE. I have duplicated classes, attributes, invocations and methods. In this way it's impossible to perform any kind of analysis. >> >> As an example, here is a snippet of the obtained MSE: >> >> (FAMIX.Attribute (id: 430073) >> (name 'mZoomIn') >> (parentType (ref: 368554)) >> (declaredType (ref: 413535)) >> (isPrivate true) >> (isFinal true) >> ) >> >> ... >> >> (FAMIX.Attribute (id: 450685) >> (name 'mZoomIn') >> (parentType (ref: 450670)) >> (declaredType (ref: 413535)) >> (isPrivate true) >> (isFinal true) >> ) >> >> The 'parentType's 368554 and 450670 are the same, but duplicated as well. >> >> Any help is appreciated, thanks in advance. >> >> Regards, >> RM >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >

13 years, 4 months

2
3
0 0

moving to pharo 1.4

by Tudor Girba

Hi, Now that Moose 4.6 is out, we will move to Pharo 1.4. I will start working on it this week. It would be great to get some help. Cheers, Doru -- www.tudorgirba.com "One cannot do more than one can do."

13 years, 4 months

5
16
0 0

loading nautilus

by Tudor Girba

Hi, I am trying to load Nautilus in 1.4, but there seems to be a problem with the configuration. I run: Gofer it url: 'http://ss3.gemstone.com/ss/Nautilus'; package: 'ConfigurationOfNautilus'; load. (Smalltalk at: #ConfigurationOfNautilus) loadRelease. But, the Growl dependency is incorrect: spec project: 'Growl' with:[ spec repository: 'http://www.squeaksource.com/Growl'; package: 'Growl' ]. We could create a ConfigurationOfGrowl, or just load the package directly: spec package: 'Growl' with: [spec repository: 'http://www.squeaksource.com/Growl' ]. Which one do you prefer? Btw, the Moose build is failing because of this :). Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

13 years, 4 months

1
1
0 0

MSE duplicated entities

by roberto.minelli＠usi.ch

Dear all, I have a question regarding inFamix and the MSE format. I have an Android project composed by a single class. I need to perform an analysis on the Invocations. For this reason I need the source code of the library called. Thus I copied some of the sources of the Android SDK inside the src folder of the project. When I generate the MSE file of the project I end up having a problem: Each FAMIX entity, i.e., FAMIX.Attribute, appears twice in the MSE. I have duplicated classes, attributes, invocations and methods. In this way it's impossible to perform any kind of analysis. As an example, here is a snippet of the obtained MSE: (FAMIX.Attribute (id: 430073) (name 'mZoomIn') (parentType (ref: 368554)) (declaredType (ref: 413535)) (isPrivate true) (isFinal true) ) ... (FAMIX.Attribute (id: 450685) (name 'mZoomIn') (parentType (ref: 450670)) (declaredType (ref: 413535)) (isPrivate true) (isFinal true) ) The 'parentType's 368554 and 450670 are the same, but duplicated as well. Any help is appreciated, thanks in advance. Regards, RM

13 years, 4 months

2
1
0 0

Issue 600 in moose-technology: Popup does not work properly

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-Hapao Component-Mondrian New issue 600 by alexandr...(a)gmail.com: Popup does not work properly http://code.google.com/p/moose-technology/issues/detail?id=600 It takes times to appear and does not always appears. I am not sure where the problem comes from. Probably Mondrian. The popup has problems probably because the visualization takes time to render. Classes in Hapao are nested within a very large node. This prevent classes to be catched as a bitmap. Tested on Pharo 1.3. Thanks Laurent & Patrick

13 years, 4 months

1
6
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev