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
