Hi!
Yesterday evening we had a 3 hours moose session with industrial. We had fun :-)
http://dl.dropbox.com/u/31543901/MooseInClassroom.jpg
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
It seems there is no way to identify classes (java) that are Exceptions.
Even the one that are used.
There are ThrownException / DeclaredException / CaughtException , all
pointing to the exceptionClass, but there is no opposite property in the
exception class that one could use to test whether a given class is used
as an exception.
So the only way is to test whether Exception is an ancestor of a given
class ?
nicolas
With the following script, in Mondrian when you hover over edges a popup
appears showing the name of the edge. Is the same possible with Roassal?
view shape rectangle size: 20.
nodes := view nodes: (1 to: 20).
view edges: (2 to: 20) from: 1 to: #yourself.
view circleLayout.
cheers, Ben
Is there anything (at all) to gain in my continuing to use
ROMondrianViewBuilder versus "native" Roassal?
Is ROMondrianViewBuilder "just" for backward compatability to ease the
transition and draw people into the new system?
Or... is there stuff that ROMondrianViewBuilder does better than
"native" Roassal - in terms of conciseness, ease of use, flexibility,
access to layouts, features, etc...
I am trying to determine whether putting effort into the perhaps easier
step of going from Mondrian to ROMondrianViewBuilder may be wasted
leaving me missing out on any new power of Roassal, or require more
effort later to rework for native Roassal.
You may have gone over this before, but how do the purpose and
architecture of the two differ?
cheers -ben
Just recording a bit of my learning the internals of Roassal, since it
helps me flesh out my understanding.
[ROShape>>removeShape:] does not have a test to reference for my
understanding of this, but it appears to not work as expected. For
example in workspace...
b := ROBox new.
c := ROCircle new.
b addLast: c.
b removeShape: ROCircle.
b inspect
results in a linked list of: aROBoxShape --> aROCircleShape -->
aROChildrenShape.
Actually the semantics of [removeShape:] seem problematic. What should
be the result of...
b := ROBox new.
b removeShape: ROBox.
b inspect.
I would guess that 'b' should hold aROChildrenShape, except you can't
change the value of 'b' from inside the [removeShape:] method. (In my
limited knowledge of 'slots', I wonder if this is something they might
help with.) I am relying on the guess that you could have
aROChildrenShape as the only shape on an element, for subviews without a
border, but could you clarify this.
Naively I thought to just try... removeShape: aShapeClass
^ (self isKindOf: aShapeClass)
ifTrue: [ next become: next next ]
ifFalse: [ next removeShape: aShapeClass ]
but the danger of #become hit me and locked my image.
btw, something else just while I am feeling evil, what should happen
with the following...
b := ROBox new.
b removeShape: ROChildrenShape.
b inspect.
cheers -ben
Hi everybody,
is there a Pharo port of Code City?
I am wondering because the use of VisualWorks Smalltalk and the
license restrictions that come with it make it impossible to use Code
City in a commercial setting (if I understand it right).
Cheers,
Torben
Just recording a bit of my learning the internals of Roassal, since it
helps me flesh out my understanding.
At first glance looking at [ROShape>>addLast:] this seemed to
recursively call itself with no exit-condition, but then I noticed its
ivar 'next' is initialized to ROChildrenShape this provides the exit
condition inherited from RONullShape. Adding a shape replaces this
ROChildrenShape in 'next', but the new shape itself has a
ROChildrenShape in its 'next' .
I haven't got as far looking at ROChildrenShape yet, but briefly thought
it might be a container holding other shapes, but then actually I think
it is the ROElements ivar 'elements' that is the container of subview
nodes - and that ROChildrenShape just stores how to draw the subview nodes.
I guess it is the lack of the [drawOn:For:] method that distinguishes
between abstract and concrete ROShape classes. By the way, what is the
design decision of leaving [ROShape>>drawOn:For] blank rather than using
[self subclassResponsibility] ?
So, just to confirm my understanding, perhaps the following or similar
would be useful as a comment on ROShape>>addLast:
"Instance variable 'next' must be a RONullShape to provide the exit
condition of this recursive call. This is ensured by instance
initialization"
cheers -ben
I was browsing Roassal looking for how mouse-overs are handled, and
bumped into the method ROBeginingAnimation>>isOver, and I was
momentarily confused by what "over" would mean in this context. Without
knowing the whole architecture, I am thinking that perhaps a better
method name would be 'isComplete'. In a highly GUI oriented system,
"over" has too many meanings without diving into the code.
If that is reasonable, but I distraction from other work, I could
implement and submit the change. The method is referenced from five
methods and three tests.
cheers -ben
Hello all,
Just wanted to know if the Windows VM file (Squeak.exe) in one-click Moose
package is the latest version of the VM (in image-folder/Contents/Windows)?
Can I know the source of the vm because I remember downloading one
(Cog.exe) that worked better?
tx,
Usman
Hi everybody,
as I'm new to this list I just wanted to say hello.
I'm quite new to Moose and completely new to Smalltalk - so please
forgive any newbie questions :-)
I came to Moose via CodeCity, and I believe it's a powerful platform,
thus I'm eager to learn more about it. I'm especially interested in
using Moose / CodeCity in a commercial setting, e.g. in the context of
architecture assessments and code reviews that we are doing for
customers. Actually I recently used Moose in such a context, but could
not get quite to the results I wanted to. Not because of Moose, but
rather because I'm not familiar with the Smalltalk environment and
especially Mondrian painting yet...
Today I found this mailing list from which I believe it's a good
source for information and knowledge exchange.
So, "Hello!" :-)
Cheers,
Torben
Today we created a tool with stephane:
I'm a kind of loader that know how to save and load list of packages.
First when you have a configuration of packages that you want to version
use:
(Pay attention version and save first your packages, we are talking here
about saving a list of packages not the packages themselves)
publishNewVersion
it will create a new method scriptXXX on the
MooseConfigurationRepository
You can then version this class in the package containing the Reloader
class.
In another image once you load this new version you can reload the
configuration you save using the method
reload: aNumber
and it will load all the packages you previously specified.
Under the cover, we need a way to know which packages to save and where to
load them.
Here is how this information is specified right now, it can be modified
using accessors.
defaultSavedPackagesPatternNames
^ #(#('Moose-Tests-Algos-InformationRetrieval*' '
http://www.squeaksource.com/MooseAlgos') #('Moose-Settings*' '
http://www.squeaksource.com/Moose') #('ConfigurationOfNewECompletion*' '
http://ss3.gemstone.com/ss/NEC') #('Fame-Example*' '
http://www.squeaksource.com/Fame')
#('Moose-Tests-Algos-FormalConceptAnalysis*' '
http://www.squeaksource.com/MooseAlgos') #('CollectionExtensions*' '
http://www.squeaksource.com/CollectionExtensions') #('Grease-Core*' '
http://www.squeaksource.com/Seaside30') #('PetitSmalltalk*' '
http://source.lukas-renggli.ch/petit') #('Mondrian-Visitor*' '
http://www.squeaksource ......)
Currently, it kills squeaksource but we will retry with a wait between
each package and it should works.
This tool is available at:
http://www.smalltalkhub.com/mc/StephaneDucasse/MooseReloader/main
--
*Guillaume Larcheveque*
Hi everybody,
last question for today :-)
Is there a converter which converts from MSE 3.0 to 2.1 format?
I'm obviously trying to visualize some Java code with Code City. The
MSE was created using verveinej. I know that the inFamix paid version
can produce MSE 2.1 output, but if somehow possible I would prefer an
open source / non-paid solution.
Maybe, is there an older version of verveinej available which would
produce MSE 2.1? Or was verveinej producing MSE 3.0 from the
beginning?
Thanks a lot and best regards,
Torben
Status: New
Owner: ----
CC: alexandr...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-Mondrian Milestone-4.7
New issue 798 by tudor.gi...(a)gmail.com: Mondrian should store edges in the
most specific parent of the from/to nodes
http://code.google.com/p/moose-technology/issues/detail?id=798
The edges should be stored in the most specific parent of the from and to
nodes, and not in the parent of the node in which they are defined.
This is because the layout takes this information into account. For
example, the below layout does not show a tree inside node 1.
view := MOViewRenderer new.
view node: 1 forIt: [
view shape label.
view nodes: (10 to: 11).
view treeLayout.
].
view edgesFromAssociations: {10 -> 11}.
view open.
In experimenting to understand ROMondrianExample>>attachPointOn:
I broke into the execution as follows: "forEach: [:cls | self haltOnce."
now if I highlight and inspect 'view shape line' I get a ROLine.
but if I highlight and inspect 'view shape rectangle' I get a
ROMondrianViewBuilder rather than the expected something like ROBox.
This seems wrong that these are not consistent.
cheers, -ben
I think the following would be the start of a good example of how
Roassal works...
| view rawView el1 el2 edge line |
rawView := ROView new.
el1 := ROElement new.
el1 extent: 50@50.
el1 + ROBox red + ROCircle yellow + ROLabel @ RODraggable.
rawView add: el1.
rawView open
...except that it would be nice if the ROLabel could be centred.
In addition, being able to place the ROLabel in various "offset"
locations, I think that would satisfy a lot of my composition
requirements - for example building a transformer compound symbol with
two overlapping circles and two labels for "equipment tag" and "power
size". To that effect it would be great if ROLabel or similar could
have a callback mechanism to get different attributes from the model.
Alternatively I guess I could make a new subclass of ROShape that draws
such that directly.
cheers -ben
Referring to the attached graph, what is the best way to approach the
following in Roassal.
Currently with Mondrian I produce a produce a custom shape using the
forms builder in #mondrianShape, which is a method of my ModelRoot
class. Referring to the attached graph, as an example this shows the
class name "Substation" above the instance "SS1" and has a space for
contained items to be displayed within it.
>>mondrianShape
| builder |
builder := MOFormsBuilder new.
builder column; center; fill; pref; grow.
builder
row; center; pref; fill; grow;
row; center; pref; fill; grow;
row; center; pref; fill; grow.
builder x: 1 y: 1 add: ( MORectangleShape new text:
#strippedClassName; textAlignment: #left; borderColor: Color white ) .
builder x: 1 y: 2 add: ( MORectangleShape new text: #localName;
textAlignment: #left ) .
builder x: 1 y: 3 add: ( MORectangleShape new ) .
builder x: 1 y: 3 add: ( MOChildrenShape new ) .
^builder shape
In conjunction with the use of MOChildrenShape above, class ModelRoot
also has method #addSubViewTo: which descends through contained classes
- for example instance "primary" inside "T1" inside "SS2" inside "Figure
8..."
>>addSubViewTo: aMOViewRenderer
aMOViewRenderer
node: self
using: self mondrianShape
forIt:
[
self children do:
[ :child |
child addSubViewTo: aMOViewRenderer.
]
]
My initial issues in migrating this to Roassal are:
1. Roassal appears to not provide any methods that have "using:" in them.
2. Roassal appears to not support MOFormsBuilder
It may be that I am accessing to much internal methods. The code above
was the result of evolutionary hacking as I was learning Mondrian. I
would be happy to re-architect if someone can advise best practice for
Roassal.
cheers -ben
Just to give you an idea of where I would like to end up... referring to
the attached [1] & [2]. I am looking to be able to generate a first
layout from data by applying a layout, but then mostly move nodes around
and draw links manually - then save and load these layouts. I imagine
that similar might be useful for software analysis wanting to
intuitively arrange a few nodes to annotate together for printing
purposes - saving different zoomed in "views" of the system under analysis.
One thing I am contemplating is whether one of my "busbar" shapes could
be defined to have several regularly spaced attachpoints, with the
attachpoints themselves optionally visible - either full time or when
hovering over a shape.
Also I'd like to be able to group shapes that a layout can act on as a
whole. A little different from the MOFormsBuilder, it would just be
offsets relative to each other, to the point where interactively you
could multi-select nodes and "Group" them to be acted on by a layout as
a whole.
I've also marked a couple of other ideas on these attached files.
[1] Roassal Use Case - Motor Control Centre Single Line Diagram (small).pdf
[2] Roassal Use Case - Industrial Plant Power Distribution Single Line
Diagram (small).pdf
cheers, -ben