Hi,
We have improved MooseChef with a generic version MooseQuery.
In the following when we talk about MooseChef, it means the current version available by default in Moose. When we talk about MooseQuery, it means the generic improved version, available on Anne’s smalltalkHub repository.
All the tests of MooseChef except 4 are passing when using our new MooseQuery API.
These four tests concern the same point package scope for extension method.
Considering classA having a method methodA1 calling a method methodBExt1 that extends classB.
classB is defined in pckgB and its extension method by pckgC.
Considering the two following requests:
1. classA queryOutgoingInvocation atClassScope atPackageScope
2. classA queryOutgoingInvocation atPackageScope
To the first query, MooseChef and MooseQuery answer the same: pckgB
To the second query, MooseChef answers pckgC and MooseQuery answers pckgB and pckgC.
So first question: What is the expected behavior? What do we want?
According to us, MooseQuery behavior is more consistent.
***************
Considering now Java code.
class1 contains a method method1 which in its turn contains an inner class innerClass2. innerClass2 contains 2 methods method21 and method22.
the following query:
innerClass2 methodScope
In MooseChef this query has for result method21 and method22.
The following query:
innerClass2 atScope: FAMIXMethod
In MooseQuery this query has for result method1. Indeed, the atScope: method look for the container (also called parent).
So the second question: what is the expected behavior? Do we want like in MooseQuery that atScope: by default always goes up in the containment tree since it is a generic version of atTypeScope, atPackageScope... and do we want another method to goes down in the containment tree?
In MooseChef, methodScope, always goes down to look for the contained methods. typeScope always goes up except for ScopingEntities. These methods have been implemented for each type of entities. It is what we want to avoid with MooseQuery.
******************
It is clear that Synectique will soon migrate to this new version and that our project of SQL analysis will also use it. Please don’t hesitate to use it.
MCHttpRepository
location: 'http://smalltalkhub.com/mc/AnneEtien/MooseQueryDraft/main'
user: ''
password: ‘'
We will do as soon as possible a small doc to explain the usage.
Thank you in advance for your answer to our questions.
Jean-Christophe and Anne
Hi,
yesterday I heard someone from my team talking about a tool for visualizing quickly file size in your system.
I was wondering if there is anything done with Roassal for that? I looked at the current version of Roassal in Moose 6.0 but I didnt find anything.
If there is one could someone help me otherwise should it not be nice to have some?
Thanks for your answer.
Regards,
--------------
Brice Govin
PhD student in RMoD research team at INRIA Lille
Software Engineer at THALES AIR SYSTEMS Rungis
ENSTA-Bretagne ENSI2014
64 chemin des boeufs 91220 PALAISEAU
Hi all!
I want to make a visualization of a graph (nodes and edges), but applying
ForceLayout to it takes forever, because the graph has too many elements.
if I apply TreeLayout, for example, the view renders almost instantly. Is
there some other Layout, similar to ForceLayout, but faster, for so many
elements?
Thanks!
Hi,
Few days ago I built a view using the class RTData.
With the last version of Roassal.. puff... disappeared…
I read the discussion 'New RTData class in Roassal’ and it looks is the one to use. Am I right?
Cheers,
R
Hello,
I was checking on FAMIXSQL and there is this test class that fails
becuase it depends on the PetitSQLIslandParser package. I think this
class is not belong here. Can we move it into a PetitSQLIslandParser
package?
Thanks and cheers,
Fabrizio
Dear all,
I have created a class RTConditionalLayout and it is into the Layout Builder.
Consider the following example:
-=-=-=-=-=-=-=-=-=
v := RTView new.
es := (RTEllipse new
size: 30;
color: [ :value | value odd ifTrue: [ Color red ] ifFalse: [ Color blue ] ])
elementsOn: (1 to: 4).
v addAll: es.
l := RTConditionalLayout new
condition: [ :element | element model odd ];
thenLayout: RTVerticalLineLayout new;
elseLayout: RTHorizontalLineLayout new.
l on: es.
v
-=-=-=-=-=-=-=-=-=
The idea is to have a layout that segregate some elements that match a particular condition.
This is supported in the Layout builder, which allows one to do (using RTMondrian in that case):
-=-=-=-=-=-=-=-=-=
b := RTMondrian new.
b shape rectangle
fillColor: Color white;
borderColor: Color lightGray;
withTextAbove: #name.
b nodes: Collection withAllSubclasses forEach: [ :cls |
b nodes: cls methods.
b edges connectToAll: #dependentMethods.
b layout
ifElement: #isConnected then: RTTreeLayout new;
else: RTGridLayout new.
].
b edges connectFrom: #superclass.
b layout tree.
b
-=-=-=-=-=-=-=-=-=
The issue here is that I have introduced a mechanism to do ‘if’ statements. I am not sure this is the best things…
Comments are welcome :-)
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Dear All,
RTEdgeBuilder has been completely rewritten. You can now specific objects and elements from where edges begins and edges. The API is about 70% the same I believe.
Migration of your code should be fairly easy. Else, ask for help.
In any case, the old builder is named: RTEdgeBuilderDeprecated
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi All
Not sure if this is a bug, but here goes.
Looking through the Glamour examples in Pharo4 I come across the
Updateable Browser example.
This example has a line that, when the collection is greater than 1,
shows a list tab, the title of which is List, col size printString.
This indeed comes up and shows: 'List: 2' but if you continue to add, it
doesn't change. The text will change but not the title.
I came across this when I couldn't get my browser to add tabs, even
though entity gets updated.
Example from Glamour below.
| browser collection|
collection := GLMAnnouncingCollection new.
collection add: 1.
browser := GLMTabulator new.
browser column: #preview.
browser
act: [:b | b entity add: (b entity size + 1). b update ]
icon: GLMUIThemeExtraIcons glamorousAdd
entitled: 'Add an item in the collection'.
browser
act: [:b | b entity removeLast. b update ]
icon: GLMUIThemeExtraIcons glamorousRemove
entitled: 'Remove last item from the collection'.
browser
updateOn: GLMItemAdded from: #yourself;
updateOn: GLMItemRemoved from: #yourself.
browser transmit to: #preview; andShow: [ :a |
a list
title: [:col | 'List: ', col size printString ]; *"This
isn't updating"*
when: [:col | col size > 1 ].
a text title: 'Text';
format: [:col | 'Current collection: ', col printString, '.
Add more items to show the list'] ].
browser openOn: collection
KR
--
Gareth Cox
IT Manager/Developer
Inspired Org (PTY) Ltd
email: gareth(a)inspired.org <mailto:gareth@inspired.org>
Hi Alex,
I think that TRDrag* events should require that you are over the dragged
element with your mouse, because now the behavior is that if the mouse gets
outside the element, drag events are still being fired. But maybe I should
fix this on my side.
To better illustrate my point look at this
https://www.youtube.com/watch?v=4rHdiwGdr4s
When the mouse is completely out of the element the resizing is still
occurring (because the drag event is still being applied), and then compare
it to the behavior of resizing Playground -- there it happens only where it
makes sense.
I haven't found any applicable example directly in Roassal, but you can
look into my
smalltalkhub peteruhnak/roassal-contrib repo (same as we used before for
moving stuff from dynacase)
at DCRTResizable>>example
On another note:
I added methods for moving to RTLayoutTranslator for all sides, so you can
probably move it to Roassal if it looks ok to you.
Thanks,
Peter
