Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

by Tudor Girba

Hi, I am currently working on analyzing some log files using PetitParser, and I have some metaphysical questions about the design I use :). The log file contains all sorts of events, including method start, method end and others. Furthermore, the log can collect events coming from multiple clients. See below: 2011-12-12 00:00:00,000 TRACE MethodTraceLogInterceptor: Client 1: START method package.Class#method 2011-12-12 00:00:00,010 TRACE MethodTraceLogInterceptor: Client 1: START method package2.Class2#methodWithoutEnd 2011-12-12 00:00:00,020 DEBUG Something else 2011-12-12 00:00:00,030 TRACE MethodTraceLogInterceptor: Client 2: START method package2.Class2#method 2011-12-12 00:00:00,040 DEBUG Something else 2011-12-12 00:00:02,000 TRACE MethodTraceLogInterceptor: Client 1: END after 2000 ms method package.Class#method 2011-12-12 00:00:02,030 TRACE MethodTraceLogInterceptor: Client 2: END after 2000 ms method I would like to retrieve for each client a tree based on the nesting of method calls. The grammar is quite straightforward. But, the question is how to get the tree from the parser. My current solution is to hold a stack in the parser and push/pop to it when a method starts/ends (actually, I have a stack for each client). Something like this: methodStart super methodStart. ==> [:token | ... (self topForClient: (token at: 2)) addChild: newMethodLogEntry. self push: newMethodLogEntry forClient: (token at: 2) ] methodEnd super methodEnd. ==> [:token | ... self popForClient: (token at: 2) ] This works Ok, and in the end I get my tree in the stack instance variable of the parser. But what makes me uneasy is that the result of the parser is somewhat unclean, because both for methodStart and for methodEnd I will get the same object. However, the good thing about this is that I do not have to create an intermediary representation for the log and directly produce the tree (which can save memory when we talk about large log files). What do you think? Do you have a more elegant solution? Cheers, Doru -- www.tudorgirba.com "One cannot do more than one can do."

13 years, 4 months

Glamour-Merilin-Mondrian

by Júlio Martins

> > This is it > > | filterWizard view | > browser := GLMTabulator withStatusbar. > filterWizard := BMBugMapsFilterWizard new. > browser > row: [ :row | row column: #map span: 2.5; column: #metrics] span: 1.5; > row: [ :row | row column: #code span: 2.5; column: #chart]. > > browser transmit > to: #map; > andShow: [ :b | self distributionMapIn: b]. > > filterWizard := BMBugMapsFilterWizard new > glamourWizard > initialExtent: 400@200; > yourself. > > browser > spawn: [:a| > filterWizard > atEndDo:[:wizardInformation| . > self distributionMapIn: a with: (wizardInformation at: #textEntry). > a update.]. > ] entitled: 'Filter'. > > where self is an instance of GLMBrowserTemplate. > > > On 19 December 2011 10:51, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> If the first parameter is a browser, something is probably wrong (you >> might be using the wrong api). Please send also the browser code. >> >> Cheers, >> Doru >> >> 2011/12/19 Júlio Martins <jleandro.martins(a)gmail.com>: >> > Ok! >> > >> > distributionMapIn: a with: aNumber >> > >> > "in this point the method is executed" >> > >> > ^a mondrian >> > painting: [ :view :model | self halt. >> > view shape rectangle withoutBorder. >> > view nodes: (model allModelNamespaces asSet sortedAs: [ :x :y | x >> > numberOfClasses > y numberOfClasses ]) forEach: [ :each | >> > view shape label. >> > view node: each name. >> > view node: each forIt: [ >> > view interaction menu: #mooseMenu. >> > view shape rectangle size: 12; >> > if: [ :c | c numberOfMethods = 0 ] fillColor: Color green; >> > if: [ :c | c numberOf Methods >= 1 and: [ c numberOfBugs < 3 ] ] >> fillColor: >> > Color orange; >> > if: [ :c | c numberOfMethods >= 3 ] fillColor: Color red. >> > view nodes: ((each classes select: [ :class | class numberOf Methods >= >> > aNumber]) sortedAs: #numberOfMethods). >> > >> > view gridLayout gapSize: 2 ]. >> > view verticalLineLayout ]. >> > view gridLayout ]. >> > >> > the first method parameter is a GLMTabulator, The block started by the >> > method "halt" is not executed, I no wonder why! >> > >> > On 19 December 2011 10:15, Tudor Girba <[hidden email]> wrote: >> >> >> >> Hi, >> >> >> >> I am sorry, but I cannot understand what the issue is. Could you >> >> provide some runnable code? >> >> >> >> Cheers, >> >> Doru >> >> >> >> >> >> 2011/12/19 Júlio Martins <[hidden email]>: >> >> >> >> > Hi people! >> >> > >> >> > I was with problems figure out the question "how to update the >> >> > distribution >> >> > map from a secundary wizard? So searching for the solution i found a >> >> > another >> >> > problem: when a mondrian receive a message to GLMTabulator and send a >> >> > message to method "painting:[:a :b| ... ]" , the execution flow >> doesn't >> >> > enter on block, where is all commands to build my new distribution >> map >> >> > view. >> >> > The code is like this sample: >> >> > >> >> > >> >> > GLMTabulator new mondrian >> >> > painting:[:a :b| >> >> > .... >> >> > "here the flow doesn't enter, why?" >> >> > ] >> >> > >> >> > Before this block, the flow is normal and works, but have no >> commands to >> >> > execute >> >> > i need help of you. >> >> > >> >> > ________________________________ >> >> > View this message in context: Glamour-Merilin-Mondrian >> >> > Sent from the Moose mailing list archive at Nabble.com. >> >> > >> >> > _______________________________________________ >> >> > Moose-dev mailing list >> >> > [hidden email] >> >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> > >> >> >> >> >> >> >> >> -- >> >> www.tudorgirba.com >> >> >> >> "Every thing has its own flow" >> >> >> >> _______________________________________________ >> >> Moose-dev mailing list >> >> [hidden email] >> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > >> > >> > >> > ________________________________ >> > View this message in context: Re: [Moose-dev] Re: >> Glamour-Merilin-Mondrian >> > >> > 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/Glamour-Merilin-Mondrian-tp4214005p4214005.html Sent from the Moose mailing list archive at Nabble.com.

13 years, 4 months

Re: Glamour-Merilin-Mondrian

by Júlio Martins

Ok! *distributionMapIn:* a *with:* aNumber "in this point the method is executed" ^a mondrian painting: [ :view :model |* self halt*. view shape rectangle withoutBorder. view nodes: (model allModelNamespaces asSet sortedAs: [ :x :y | x numberOfClasses > y numberOfClasses ]) forEach: [ :each | view shape label. view node: each name. view node: each forIt: [ view interaction menu: #mooseMenu. view shape rectangle size: 12; if: [ :c | c numberOfMethods = 0 ] fillColor: Color green; if: [ :c | c numberOf Methods >= 1 and: [ c numberOfBugs < 3 ] ] fillColor: Color orange; if: [ :c | c numberOfMethods >= 3 ] fillColor: Color red. view nodes: ((each classes select: [ :class | class numberOf Methods >= aNumber]) sortedAs: #numberOfMethods). view gridLayout gapSize: 2 ]. view verticalLineLayout ]. view gridLayout ]. the first method parameter is a GLMTabulator, The block started by the method "halt" is not executed, I no wonder why! On 19 December 2011 10:15, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I am sorry, but I cannot understand what the issue is. Could you > provide some runnable code? > > Cheers, > Doru > > > 2011/12/19 Júlio Martins <jleandro.martins(a)gmail.com>: > > Hi people! > > > > I was with problems figure out the question "how to update the > distribution > > map from a secundary wizard? So searching for the solution i found a > another > > problem: when a mondrian receive a message to GLMTabulator and send a > > message to method "painting:[:a :b| ... ]" , the execution flow doesn't > > enter on block, where is all commands to build my new distribution map > view. > > The code is like this sample: > > > > > > GLMTabulator new mondrian > > painting:[:a :b| > > .... > > "here the flow doesn't enter, why?" > > ] > > > > Before this block, the flow is normal and works, but have no commands to > > execute > > i need help of you. > > > > ________________________________ > > View this message in context: Glamour-Merilin-Mondrian > > 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/Re-Moose-dev-Re-Glamour-Merilin-Mondrian-tp4213899p42… Sent from the Moose mailing list archive at Nabble.com.

13 years, 4 months

xpath queries

by Tudor Girba

Hi, Is there some solution for supporting XPath queries in Pharo? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

13 years, 4 months

Glamour-Merilin-Mondrian

by Júlio Martins

Hi people! I was with problems figure out the question "how to update the distribution map from a secundary wizard? So searching for the solution i found a another problem: when a mondrian receive a message to GLMTabulator and send a message to method "painting:[:a :b| ... ]" , the execution flow doesn't enter on block, where is all commands to build my new distribution map view. The code is like this sample: GLMTabulator new mondrian painting:[:a :b| .... "here the flow doesn't enter, why?" ] Before this block, the flow is normal and works, but have no commands to execute i need help of you. -- View this message in context: http://forum.world.st/Glamour-Merilin-Mondrian-tp4213842p4213842.html Sent from the Moose mailing list archive at Nabble.com.

13 years, 4 months

Fwd: [vwnc] Introducing SimpleXPath

by Steffen Märcker

Hi, during my work on the XML-Mapping framework SimpleXO, I realized that the XML querying code could be useful standalone, too. I factored out a library named SimpleXPath and made it available in Cincom public repository under the MIT license. It is similar to the XPath location path subset (without predicates) but offers some distinct features: - paths are built as pure Smalltalk expressions - extended wildcard support - simple API Example: (RootStep // 'source' /@ 'id') "XPath: //source/@id" contextNode: anXmlNode; nodesDo: [:node | Transcript show: node stringValue; cr]. The above code prints the 'id' value of all 'source' elements in the XML document from which anXmlNode is taken. I am interested in your opinions. I'd be glad If you give it a try and discuss your thoughts here. Below I've attached the package comment explaining the API, just in case. ;) Regards and happy coding! Steffen Simple XPath is an XML query library based on a subset of the XPath 1.0 language. It provides a handy API to construct paths and a parser for abbreviated XPath location paths without predicates. See also: http://www.w3.org/TR/xpath/. I. NodeSets ----------------- The result of constructing a path or parsing an XPath location path is a NodeSet. If applied to an XML node, a NodeSet provides access to the nodes selected by this set. 1. Call #contextNode: to define the node a NodeSet is applied to. 2. Call #nodes to get a set of all matched nodes, #nodesDo: with a one argument block to iterate over all matched nodes and #selectNodes: with a one argument block to select some of the matched nodes. If you are working with tags that have prefixed names, ensure that you resolve the associated namespace before using a NodeSet. Call >>#resolveNamespaces: with a dictionary that maps all prefixes to their namespace. II. Path construction API: ------------------------------------ To construct a path programmatically, use the Axis classes and the methods from the protocol "path construction". 1. Single path steps: ChildAxis ? 'name'. "select all child nodes tagged with 'name'" ChildAxis ? ('prefix' + 'name'). "select all child nodes tagged with 'prefix:name'" AttributeAxis ? 'id'. "select all attribute nodes tagged with 'id'" SelfAxis ? AnyNodeTest. "select the context node itself" DescendantOrSelfAxis ? CommentTest. "select all descendant comment nodes" 2. Concatenate steps with #/ : (ChildAxis ? 'name') / (ChildAxis ? ('second' + 'name')). (ChildAxis ? AnyNodeTest) / (AttributeAxis ? 'id'). "Often, the axis can be omitted:" 'name' / ('second' + 'name'). "same as" (ChildAxis ? 'name') / (ChildAxis ? ('second' + 'name')). AnyNodeTest / (AttributeAxis ? 'id'). "same as" (ChildAxis ? AnyNodeTest) / (AttributeAxis ? 'id'). "Similar to XPath, #/@, #// and #//@ abbreviate attribute and descendant-or-self steps:" AnyNodeTest /@ 'id'. "same as" (ChildAxis ? AnyNodeTest) / (AttributeAxis ? 'id'). 'name' // CommentTest. "same as" (ChildAxis ? 'name') / (DescendantOrSelfAxis ? AnyNodeTest) / (ChildAxis ? CommentTest). 'name' //@ 'id'. "same as" (ChildAxis ? 'name') / (DescendantOrSelfAxis ? AnyNodeTest) / (AttributeAxis ? 'id'). 3. Query from the document root with a RootStep: RootStep // AnyNodeTest. "all nodes" RootStep //@ 'id'. "id of each node" 4. Create the union of two NodeSets with #| : (RootStep // 'element') | (RootStep // CommentTest). "#\@ abbreviates the union with an attribute step:" CommentTest \@ 'id'. "same as" (ChildAxis ? CommentTest) | (AttributeAxis ? 'id'). 5. The wildcards # and * match single and multiple characters in local tag names: ChildAxis ? 'name_##'. "selects e.g. <name_01 />" AttributeAxis ? '*_id'. "selects e.g. ... svg_id='0x5' ..." "NOTE: XPath allows * only for the whole tag name, e.g. //prefix:* " III. Parser API: -------------------- To parse an abbreviated XPath location path, use SimpleXPathParser. However, predicate expressions are not supported. Call #parseString: with the XPath string to parse that string and obtain a NodeSet and #validateString: to check whether the string is free of syntax errors. If parsing fails, a SyntaxError is raised that gives the error position and a brief description. _______________________________________________ vwnc mailing list vwnc(a)cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

13 years, 4 months

Thanks for the Overview Pyramid

by pascal.vollmer＠nexgo.de

To whoever implemented the Overview Pyramid in moose: thank you indeed! I like the book "Object-Oriented Metrics in Practice" and I am happy to recommend it by giving a demo on real code. Kind regards, Pascal Pascal Vollmer Email: pascal.vollmer(a)ieee.org

13 years, 4 months

almost green tests

by Tudor Girba

Hi, There were several test problems due to the introduction of the new method in LANNode, but I solved them. We now have only one red test: MooseMonticelloImporterTest>>testBasic It seems to be a setup problem, but I cannot figure out why it breaks all of a sudden. Could someone take a look? Cheers, Doru -- www.tudorgirba.com "It's not what we do that matters most, it's how we do it."

13 years, 4 months

3 fame tests disabled

by Tudor Girba

Hi, I disabled the 3 tests from Fame that caused failures on the server, but were running Ok locally. They can be found in the FMMetaRepositoryFilterTest class: - disabledBecauseItFailsOnTheServerInHeadlessModetestExportLIBBookWithPartialMetamodel - disabledBecauseItFailsOnTheServerInHeadlessModetestExportLIBLibraryWithPartialMetamodel - disabledBecauseItFailsOnTheServerInHeadlessModetestExportLIBPersonWithPartialMetamodel Cheers, Doru -- www.tudorgirba.com "We cannot reach the flow of things unless we let go."

13 years, 4 months

Re: Issue 216 in moose-technology: No unnecessary port validation

by moose-technology＠googlecode.com

Updates: Status: Fixed Labels: Milestone-4.6 Comment #2 on issue 216 by tudor.gi...(a)gmail.com: No unnecessary port validation http://code.google.com/p/moose-technology/issues/detail?id=216 This is done now using suspendAllWhile: in the renderer

13 years, 4 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