Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 2 months

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, 2 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev