- Moose-dev - INF Mailman

Issue 762 in moose-technology: VerveineJ keeps the history of old entities, when invoked from the Moose interface

by moose-technology＠googlecode.com

Status: New Owner: tudor.gi...(a)gmail.com Labels: Type-Defect Priority-Medium New issue 762 by usman.bh...(a)gmail.com: VerveineJ keeps the history of old entities, when invoked from the Moose interface http://code.google.com/p/moose-technology/issues/detail?id=762 First, I invoke VerveineJ from Moose menu to analyse a program A. It analyses the program and imports its entities in a moose model. I invoke VJ once more from moose menu to analyse another program B. When VJ is executed and the entities of program B are imported, I also find in the same model the entities related to the program A. So, VerveineJ keeps the history of old entities, when invoked from Moose interface. I think the problem can be resolved by deleting output.mse once VJ has finished its analysis and the entities are imported in a moose model.

12 years, 7 months

2
9
0 0

positive energy

by Tudor Girba

Hi, I notice a positive flood of good energy. It feels great! Let's keep it up like this. :) Cheers, Doru -- www.tudorgirba.com "Speaking louder won't make the point worthier."

12 years, 7 months

1
0
0 0

Issue 746 in moose-technology: VerveineJ should create parameters for methods with different signatures

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: anquetil...(a)gmail.com Labels: Type-Defect Priority-Medium Component-VerveineJ Milestone-4.6 New issue 746 by tu...(a)tudorgirba.com: VerveineJ should create parameters for methods with different signatures http://code.google.com/p/moose-technology/issues/detail?id=746 In some cases, calls to external libraries get reified as methods with proper signatures, but without parameters. I am trying to reproduce this using the following example (in ad_hoc/MultipleSignatures.java): package ad_hoc; import java.io.PrintWriter; import java.io.StringWriter; public class MultipleSignatures { public void callToRegularPrintStackTrace(Throwable t) { t.printStackTrace() } public void callToPrintStackTraceWithParam(Throwable t) { t.printStackTrace(new PrintWriter(new StringWriter())) } } I encountered a similar code in a case study. However, in this case, I cannot even get the parser to recognize both printStackTrace calls.

12 years, 7 months

1
4
0 0

Issue 869 in moose-technology: Smalltalk code presentation does not populate the text port

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: chisvasi...(a)gmail.com Labels: Type-Defect Priority-Medium Component-Glamour Milestone-4.7 New issue 869 by tu...(a)tudorgirba.com: Smalltalk code presentation does not populate the text port http://code.google.com/p/moose-technology/issues/detail?id=869 Typing in the code editor should populate the text port. The test in GLMSmalltalkCodeMorphicTest>>testExplicitAcceptDoesNotAffectTextPort captures the problem. See: http://ci.moosetechnology.org/job/moose-latest-dev/lastCompletedBuild/testR…

12 years, 7 months

1
4
0 0

Issue 873 in moose-technology: PPAllParsersBrowser does not remember the sample from the inspector

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: kurs....(a)gmail.com Labels: Type-Defect Priority-Medium Milestone-4.7 Component-PetitParser New issue 873 by tu...(a)tudorgirba.com: PPAllParsersBrowser does not remember the sample from the inspector http://code.google.com/p/moose-technology/issues/detail?id=873 In the old PPBrowser, when switching between different parsers, the sample code remains available. This behaviour should be provided by the PPAllParsersBrowser, too. Jan, could you commit your fix for this issue? :)

12 years, 7 months

1
5
0 0

Re: Issue 870 in moose-technology: ROFocusView focuses on the wrong spot

by moose-technology＠googlecode.com

Updates: Status: Started Comment #2 on issue 870 by alexandr...(a)gmail.com: ROFocusView focuses on the wrong spot http://code.google.com/p/moose-technology/issues/detail?id=870 This is not an easy problem to solve apparently. Try the following: -=-=-=-=-= -=-=-=-=-= -=-=-=-=-= -=-=-=-=-= | node | node := view node: #a. view raw on: ROWindowResized do: [ :evt | ROFocusView new on: node view: view raw ]. -=-=-=-=-= -=-=-=-=-= -=-=-=-=-= -=-=-=-=-= This seems to do the thing, but if you resize the window, the view always focuses on the node. If you do not want to focus on the node when you resize, we could do: -=-=-=-=-= -=-=-=-=-= -=-=-=-=-= -=-=-=-=-= | node | node := view node: #a. view raw on: ROWindowResized doOnce: [ :evt | ROFocusView new on: node view: view raw ]. -=-=-=-=-= -=-=-=-=-= -=-=-=-=-= -=-=-=-=-= But this does not work since the romorph is resized 4 times when you open the roassal glamour-based easel.

12 years, 7 months

1
5
0 0

invokedClasses removed?

by Fabrizio Perin

Hi, I have some tests failing cause invokedClasses is not part of FAMIXClass anymore. Is it a bug or it has been removed in purpose? Cheers, Fabrizio

12 years, 7 months

3
3
0 0

Issue 861 in moose-technology: The GTDebugger should ignore halt or test failure when setting the default selection

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: chisvasi...(a)gmail.com Labels: Type-Enhancement Priority-Medium Component-GlamorousToolkit Milestone-4.7 New issue 861 by tu...(a)tudorgirba.com: The GTDebugger should ignore halt or test failure when setting the default selection http://code.google.com/p/moose-technology/issues/detail?id=861 If we add a halt in the code, the intention is to get the debugger in the method where we added the halt, not in the code of the halt implementation. Similarly, when a test is failing, we want the selection to point to the test, not to the error code.

12 years, 7 months

1
2
0 0

Issue 862 in moose-technology: The GTDebugger should not break when there is an error obtaining the value of an attribute

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: chisvasi...(a)gmail.com Labels: Type-Defect Priority-Medium New issue 862 by chisvasi...(a)gmail.com: The GTDebugger should not break when there is an error obtaining the value of an attribute http://code.google.com/p/moose-technology/issues/detail?id=862 To reproduce do the following steps: 1. Add the method: String>>breakDebugger | aVar | self do: [:c | 1=1 ifTrue: [ self halt ] ifFalse: [ aVar := 2 ] ]. 2. Execute: ['aString' breakDebugger] fork 3. In the debugger remove 'self halt' and recompile the method. 4. Select the top context This leads to an error as 'aVar' cannot be obtained from the context.

12 years, 7 months

1
2
0 0

deprecating GLMBrowserTemplate

by Tudor Girba

Hi, Starting with the original version of Glamour, we had the opportunity to define custom browsers through GLMBrowserTemplate. All you had to do was to override buildBrowser and construct your browser. For example: GlamorousBrowser>>buildBrowser browser := GLMFinder new. ... ^ browser I disliked this solution since a while. One reason was that embedding a browser into another one was inelegant because you had to say: a custom: GlamorousBrowser new browser instead of simply: a custom: GlamorousBrowser new So, now, we can achieve this by subclassing the browser from GLMCompositePresentation and overriding compose. And because the GLMCompositePresentation also contains the fluent API, you can script the browser in a fashion that is more consistent with the rest of the scripts. So, the example code would become: GlamorousBrowser>>compose self finder with: [:finder | ... ] The change might seem small, but to me it is significant. If we want to get people to program Moose, it must feel elegant to do so. And to reach this goal I think it is essential to strive to eliminate any unneeded concepts. Even if they are small. Cheers, Doru -- www.tudorgirba.com "One cannot do more than one can do."

12 years, 7 months

1
0
0 0

Issue 831 in moose-technology: Rossal problem with nested node translation to left of 0@0

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 831 by google....(a)ben.coman.com.au: Rossal problem with nested node translation to left of 0@0 http://code.google.com/p/moose-technology/issues/detail?id=831 The way negative translation is handled for nested elements is causing havoc as I was try to put some new tricks into ROCircleLayout. I now perceive this as a bug which I have distilled below. Review to the attached image #1 that was produced by the code listed below. I would expect that the three 'negative' squares would be spaced symmetrically to the three 'positive' squares. In attached image #2 element '-3' was moved to the left. Observe how the origin of element '-3' remains constant at 0@0 while the origin of elements '-2' and '-1' are modified as the left border is pushed further left. In effect, this behaviour appears to be the root cause of the 'non-symmetrical' behavior that is causing me grief. I believe that as element '-3' is dragged into the negative, the origin of '-3' should go negative leaving the origins of '-2' and -'1' unchanged. Let the parent node take care of the overall translation of its nested elements to keep the 'negative' elements in view. The overall visual effect of moving a node into a negative position should be unchanged, except that conceptually the 0@0 point will be drifting into the middle of the parent element rather than remaining fixed at the top left. By way of example, I believe the effect of this on ROCircleLayout>>doExecute would be to remove all references to the 'center' variable. This is with Roassal.283. Attachments: Roassal-problem-with-nested-node-translation#1.png 23.5 KB Roassal-problem-with-nested-node-translation#2.png 29.6 KB

12 years, 7 months

2
22
0 0

[Ann] 4.7 beta

by Tudor Girba

Hi, As a result of the successful Moose Dojo that took place on November 15-16, Moose 4.7 entered the beta state. Some of the outcomes of the Dojo are: - Cleaned a couple of hundred obsolete FAMIX navigation methods (by Robert and Nicolas) - Fixed the major bug when editing code (by Andrei and Stephan) - Fixed several other Glamour bugs (by Erwann) - Worked on improving the PPAllParsersBrowser (by Jan) - Got the GTDebugger to start to work with Bifrost (by Jorge and Andrei) - Got Reloader almost ready to work with Metacello and produce a reloadable version of the complete Moose (by Stephane and me). The 6 remaining issues are listed on the issue tracker: http://code.google.com/p/moose-technology/issues/list?q=milestone%3D4.7 Of these, the most important are: - http://code.google.com/p/moose-technology/issues/detail?id=869 (an unfortunate side effect of getting the code editing fast) - http://code.google.com/p/moose-technology/issues/detail?id=865 (we need to find the way to get the proper loading order of all packages) Anyone want to join efforts on these? Ideally, we should release somewhere at the beginning of December. Afterwards, we move to Pharo 2.0. Cheers, Doru -- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower."

12 years, 7 months

4
3
0 0

Issue 859 in moose-technology: Polymorph UITheme>>exampleBasicControls MNU GTInspector class>>showIcons

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 859 by benjamin...(a)gmail.com: Polymorph UITheme>>exampleBasicControls MNU GTInspector class>>showIcons http://code.google.com/p/moose-technology/issues/detail?id=859 I was looking for Polymorph examples and UITheme class>>exampleBasicControls has a code snippet "self exampleBasicControls" in a comment to run itself. However a debug dialog appears with "MNU: GTInspector class>>showIcons".

12 years, 7 months

1
3
0 0

Re: Issue 860 in moose-technology: Updatng a Glamour list disables the visible selection

by moose-technology＠googlecode.com

Updates: Summary: Updatng a Glamour list disables the visible selection Status: Fixed Labels: Milestone-4.7 Comment #2 on issue 860 by tu...(a)tudorgirba.com: Updatng a Glamour list disables the visible selection http://code.google.com/p/moose-technology/issues/detail?id=860 Fixed by Erwann.

12 years, 7 months

1
0
0 0

[ann] glamorous debugger (alpha)

by Tudor Girba

Hi, Over the last following days, Andrei Chis and me have worked on getting the Glamorous Debugger in a usable state (based on the original effort of Toon Verwaest): This debugger is part of the Glamorous Toolkit project, and it is based on Glamour (see the attached screenshots). You can find some details about it here: http://www.humane-assessment.com/blog/announcing-the-glamorous-debugger-alp… Some interesting characteristics: - It has an integrated inspector that shows all variables in one GTInspector with which you can browse in place all relevant variables - Code-wise, the debugger comes with an explicit model that relies neither on the old Debugger nor on the CodeHolder. The model is rather small and intelligible. In total, the entire code totals some 400 lines of code (at the moment). To put it into perspective, the Debugger class has 1096 lines of code (not counting the extra code used by it). Right now, we consider the code to be in a solid alpha, and we need more eyeballs and clicks to test it :). If you are interested in playing with it, you can either find it in the Moose image, or you can load it in Pharo 1.4 via: Gofer new squeaksource: 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load. (Smalltalk at: #ConfigurationOfGlamoroust) loadDevelopment Cheers, Doru -- www.tudorgirba.com "No matter how many recipes we know, we still value a chef."

12 years, 7 months

1
0
0 0

Issue 769 in moose-technology: Glamour should support drag and drop

by moose-technology＠googlecode.com

Status: New Owner: tudor.gi...(a)gmail.com Labels: Type-Defect Priority-Medium Milestone-4.6 Component-Glamour New issue 769 by tudor.gi...(a)gmail.com: Glamour should support drag and drop http://code.google.com/p/moose-technology/issues/detail?id=769 Something like this: a list allowItemDrag: [:item :list | ... ]; itemDrag: [:item :list | ... ] a list allowDropOnItem: [:draggedObject :targetItem :list | ... ]; dropOnItem: [:draggedObject :targetItem :list | ... ]

12 years, 7 months

5
12
0 0

Re: Issue 870 in moose-technology: ROFocusView focuses on the wrong spot

by moose-technology＠googlecode.com

Issue 870: ROFocusView focuses on the wrong spot http://code.google.com/p/moose-technology/issues/detail?id=870 This issue is now blocking issue moose-technology:816. See http://code.google.com/p/moose-technology/issues/detail?id=816 -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

12 years, 7 months

1
0
0 0

Re: Issue 865 in moose-technology: Reloader should get the list of packages to be loaded from the ConfigurationOfMoose

by moose-technology＠googlecode.com

Issue 865: Reloader should get the list of packages to be loaded from the ConfigurationOfMoose http://code.google.com/p/moose-technology/issues/detail?id=865 This issue is now blocking issue moose-technology:851. See http://code.google.com/p/moose-technology/issues/detail?id=851 -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

12 years, 7 months

1
0
0 0

Issue 809 in moose-technology: Glamour selection should happen through an action

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Enhancement Priority-Medium Component-Glamour Milestone-4.7 New issue 809 by tudor.gi...(a)gmail.com: Glamour selection should happen through an action http://code.google.com/p/moose-technology/issues/detail?id=809 Right now, selecting an item in the user interface will directly populate the #selection port. However, this is less than ideal because it does not allow the developer to intervene in this process. One possibility would be to introduce a selectionAction that is triggered by the ui, and to provide the default behavior is simply setting the #selection port.

12 years, 7 months

1
1
0 0

Issue 708 in moose-technology: Fame should accept comments both for properties and for meta descriptions

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-MooseCore Milestone-4.6 New issue 708 by tudor.gi...(a)gmail.com: Fame should accept comments both for properties and for meta descriptions http://code.google.com/p/moose-technology/issues/detail?id=708 Currently, the MSEComment: is used to define comments of a property. SomeEntity>>someProperty <MSEProperty: ...> <MSEComment: 'comment'> This is used by the MetaBrowser but not by Fame. At the very least, we should add a means to add MSEComment: to the class side for the overall class.

12 years, 7 months

1
5
0 0

Reset meta from the moose panel?

by Alexandre Bergel

Hi! Shouldn't the MooseModel>>resetMeta be accessible from the Utility menu? I think it was on some point, but not anymore apparently. Shall I can introduce it ? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

12 years, 7 months

2
2
0 0

linearFillColor

by roberto.minelli＠usi.ch

Hi, I'm trying out Roassal to draw the entire revision graph of a Git repository. Looking at the examples, the #tutorial>>step5LinearFillColor is broken (i.e., I got big red rectangle with a yellow diagonals). Do anyone of you know a solution? Cheers, Roberto Minelli

12 years, 7 months

5
11
0 0

Famix = static typing

by Nicolas Anquetil

We have been discussing here for long time that the meta-model approach of Moose is not that much adapted to the problems of reverse engineering. Because we need to model detailed informations on the programs being modeled, Famix has many entities that are language specific. Up to now we manage because Moose "core" deals with only two languages: Java and Smalltalk But if we wanted to deal with other languages C#, PHP, Python, Java-script, Cobol, Pascal, Lisp, ... we would have to add entities and/or constructs specific to each language and the tools would become less and less generic. More recently, it occurred to me that this is very similar to the kind of issues one has to deal with in a statically typed language (Java is evil :-) ). So basically Famix introduced static typing in Moose. If this analysis is correct, the questions would be: - was it necessary to go that way? why? - is there another way to do it? more in tune with the smalltalk way of life? nicolas

12 years, 7 months

3
3
0 0

Efficient Roassal Layout

by roberto.minelli＠usi.ch

Hi, I have a collection of objects (revisions of a Git repository) and I'm trying to build a tree of all the revisions (about 14k). I already computed the neighboring relationships, thus for each revision I know parents and children revisions. I wrote a small Roassal script to build a tree and I tried with subsets of revisions (i.e., 50, 100, 200, 300). Everything works fine until I reach 375 revisions or so.. After more than 10 minutes the graph was not yet displayed. So, I profiled the execution and discovered that the bottleneck is the ROHorizontalDominanceTreeLayout I'm using. I know that the Dominance Tree Layout is expensive to compute, and I was wondering if you could suggest a layout to display a tree with more that 300 nodes. Thanks in advance, Roberto

12 years, 7 months

3
2
0 0

No easy way to know which Moose version I am using?

by Mariano Martinez Peck

Hi guys. I have an image with Moose and I don't know how to get which version is it (like 4.7 or so). If there is nothing existing, I think a good place would be in the Moose Panel, when you click the '?' and you get the Help windows... on the left (index) you can add one item more "Current Version" or something like that with the information (version, date of release, details, etc) ? cheers, -- Mariano http://marianopeck.wordpress.com

12 years, 7 months

4
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev