Moose-dev December 2011

moose-dev@list.inf.unibe.ch

32 participants
167 discussions

Issue 765 in moose-technology: Meta Browser search list should offer the full name of classes
by moose-technology＠googlecode.com 23 Dec '11

23 Dec '11

Status: New Owner: tudor.gi...(a)gmail.com Labels: Type-Defect Priority-Medium Component-Finder Milestone-4.6 New issue 765 by tudor.gi...(a)gmail.com: Meta Browser search list should offer the full name of classes http://code.google.com/p/moose-technology/issues/detail?id=765 Currently, we use the name when searching for classes in the MetaBrowser, and when we get classes named the same but in different packages it gets confusing. We should use the fullName

1 1

Issue 764 in moose-technology: The Glamorous Inspector should allow editing the values of variables
by moose-technology＠googlecode.com 22 Dec '11

22 Dec '11

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-GlamorousToolkit New issue 764 by tudor.gi...(a)gmail.com: The Glamorous Inspector should allow editing the values of variables http://code.google.com/p/moose-technology/issues/detail?id=764 In the regular inspector, you can just accept a new value in the preview pane and the instance variable gets updated. Glamorous Inspector should offer a similar support. Most likely, we will start with a dialog for entering a new value. That is until we get the ability to edit in place in the table.

1 0

gt inspector
by Tudor Girba 21 Dec '11

21 Dec '11

Hi, Just out of curiosity: Does any of you use the GTInspector? For those that wonder what that is, here is a demo:http://www.humane-assessment.com/blog/glamorous-inspector-for-smalltalk This is available in any recent Moose image mapped as Explorer (CMD+I). You can load it in a Pharo 1.3 image by:Gofer new squeaksource: 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load.(Smalltalk at: #ConfigurationOfGlamoroust) loadDefault.(Smalltalk at: #GTInspector) registerToolsOn: Smalltalk tools. Cheers,Doru -- www.tudorgirba.com "Every thing has its own flow"

2 1

gtinspector
by Tudor Girba 21 Dec '11

21 Dec '11

Hi, Just out of curiosity: Does any of you use the GTInspector? For those that wonder what that is, here is a demo: http://www.humane-assessment.com/blog/glamorous-inspector-for-smalltalk This is available in any recent Moose image mapped as Explorer (CMD+I). You can load it in a Pharo 1.3 image by: Gofer new squeaksource: 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load.(Smalltalk at: #ConfigurationOfGlamoroust) loadDefault.(Smalltalk at: #GTInspector) registerToolsOn: Smalltalk tools. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

2 1

Re: Jenkins build is still unstable: moose-latest-dev #756
by Alexandre Bergel 21 Dec '11

21 Dec '11

Hi! I worked on the failing test. It is now green. In the process, I added comments and unit test for part there were not tested. Here are my changes: Moose-Tests-MonticelloImporter-AlexandreBergel.4 : renamed testBasic into something more meaningful (testImporting) Moose-MonticelloImporter-AlexandreBergel.26 : Replace reference to SmalltalkMethodVisitor by MonticelloMethodVisitor Moose-SmalltalkImporter-AlexandreBergel.124 : Rename SmalltalkMethodVisitor into AbstractSmalltalkMethodVisitor. Added two subclasses to it, SmalltalkMethodVisitor and MonticelloMethodVisitor. I did this since the lookup of name is different. Famix-Implementation-AlexandreBergel.98 : Added a new unit test, FAMIXNameResolverTest Cheers, Alexandre > On 19 Dec 2011, at 22:41, Alexandre Bergel wrote: > >> Tomorrow I work on it. >> >> Alexandre >> >> >> >> Le 19 déc. 2011 à 18:34, admin(a)moosetechnology.org a écrit : >> >>> See <http://hudson.moosetechnology.org/job/moose-latest-dev/756/> >>> >>> > > -- > www.tudorgirba.com > > "Sometimes the best solution is not the best solution." > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 1

Re: Glamour-Merilin-Mondrian
by Júlio Martins 20 Dec '11

20 Dec '11

Correting the code >> >> | filterWizard view | >> browser := GLMTabulator withStatusbar. >> filterWizard := BMBugMapsFilterWizard new. "a child of WizardControl" >> 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. >> > filterWizard > 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 <[hidden email]<http://user/SendEmail.jtp?type=node&node=4214005&i=0> >> > 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 <[hidden email]<http://user/SendEmail.jtp?type=node&node=4214005&i=1> >>> >: >>> > 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! >>> >> -- View this message in context: http://forum.world.st/Re-Moose-dev-Glamour-Merilin-Mondrian-tp4214058p42140… Sent from the Moose mailing list archive at Nabble.com.

2 1

Glamour Presentations
by Júlio Martins 19 Dec '11

19 Dec '11

Might one of you give me a code example that show a way of how show different views of a same type of mondrian presentation, just changing a value? This value must be gotten from a window and the mondrian presentation must be in another window. For example a window with presentation have a menu that call the another window, or something so. . It is possible? Julio. * * -- View this message in context: http://forum.world.st/Glamour-Presentations-tp4215080p4215080.html Sent from the Moose mailing list archive at Nabble.com.

1 0

java (jboss) dynamic instrumentation?
by Tudor Girba 19 Dec '11

19 Dec '11

Hi, Can anyone recommend an dynamic instrumentation tool for Java? I am interested in a solution that would work also on the server side (in particular, inside a JBoss server). I found some links, but I do not know how good they are: http://java-source.net/open-source/profilers Cheers, Doru -- www.tudorgirba.com "Reasonable is what we are accustomed with."

3 2

Re: Moose-dev Digest, Vol 64, Issue 56
by Sergio Castro 19 Dec '11

19 Dec '11

On 19/12/11 13:09, moose-dev-request(a)iam.unibe.ch wrote: > > ---------------------------------------------------------------------- > > > Message: 2 > Date: Mon, 19 Dec 2011 05:07:39 +0100 > From: Tudor Girba<tudor(a)tudorgirba.com> > Subject: [Moose-dev] java (jboss) dynamic instrumentation? > To: Moose-dev Moose Dev<moose-dev(a)iam.unibe.ch> > Message-ID:<56F679FD-8623-4A68-BD18-B7C3B3C3D340(a)tudorgirba.com> > Content-Type: text/plain; charset=us-ascii > > Hi, > > Can anyone recommend an dynamic instrumentation tool for Java? > > I am interested in a solution that would work also on the server side (in particular, inside a JBoss server). > > I found some links, but I do not know how good they are: > http://java-source.net/open-source/profilers > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Reasonable is what we are accustomed with." > > As far as I know, Javassist is what you need. I have used it for byte code instrumentation and is relatively easy to learn and use, if I remember correctly JBoss provides support for it. Take a look to: http://www.jboss.org/javassist Sergio

4 4

designing a log parser
by Tudor Girba 19 Dec '11

19 Dec '11

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."

2 1

← Newer
1
...
7
8
9
10
11
12
13
...
17
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev December 2011