Hi, all,
something that is a major inconvenience: with todays default
configuration of moose, a bunch of glamour basic examples hang Pharo.
I submitted a bugreport: http://code.google.com/p/moose-technology/issues/detail?id=258
that uses one case but there are many more. Select something in a
list and the image hangs.
A bit of a shame, I wanted to play around with Glamour to implement
the control panel for AspectMaps, but now I cannot do anything at
all :-(
--
Johan Fabry
jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile
The comment of this version says:
-=-=-=-=-=-=-=-=-=-=-=-=
This version contains a number of important refactorings and
improvement:
- MOGraphElement.children has been renamed into MOGraphElement.nodes
- allChildrenDo: -> allNodesDo:
- added a method MOGraphElement>>handleException: that handle error.
Normally, an image should not freeze when rendering an erroneous
Mondrian script.
- Bug fixed in MOGraphElement>>elementAt:ifAbsent: This solve the
ISSUE #193. A test has been added:
MOViewRendererTest>>testEdgeContainsPointWithEdges
- recagorization of methods in MOArrowedOrthoVerticalLineShape
- Bug fixed in MOLineShape>>containsPoint:for: This solved the ISSUE
#249. The problem stems from using CurvedLine. I added a test
MOViewRendererTest>>testEdgeContainsPointCurveFitter for this
- Added a safeguard in MOAnnouncer>>popupText:
All 164 Test methods are green!
-=-=-=-=-=-=-=-=-=-=-=-=
Doru, I wanted to do a merge with tg.296, but you redefined
MOSplineShape>>display:on: and I provide a new version of this method
(I refactored some part). Maybe you want to do the merging of this
method. I can do it if you want.
I am now updating the corresponding issues in code.google.com
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi there the infusion team
I would like to know if/how inFusion handles calls in static block in Java. I can not find such invocations in a model. Would it be complicated to add them?
I have the following sample:
class KeyMapping {
static final KeyMapping keyMapping1 =
new KeyMapping(KeyEvent.VK_LEFT,
KeyEvent.VK_RIGHT,
KeyEvent.VK_UP,
KeyEvent.VK_SPACE);
static final KeyMapping keyMapping2 =
new KeyMapping(KeyEvent.VK_X,
KeyEvent.VK_V,
KeyEvent.VK_D,
KeyEvent.VK_ALT);
int left, right, thrust, fire;
KeyMapping(int k_left, int k_right, int k_thrust, int k_fire) {
left = k_left;
right = k_right;
thrust = k_thrust;
fire = k_fire;
}
}
--
Simon
Stef,
I tend to agree, but you want it fairly obvious to the end user that they are wandering onto the bleeding edge when using nano versions:)
For example, by default, Metacello would filter out nano versions...
Dale
----- "stephane ducasse" <stephane.ducasse(a)gmail.com> wrote:
| simon my gut feeling is telling me that four level is too complex.
|
| Stef
|
| On Dec 5, 2009, at 5:07 PM, Simon Denier wrote:
|
| >
| >
| > Thinking again about the dev process specifically in Moose (not
| subprojects such as CAnalyzer, Mondrian...), branches for developer
| should be 'nano' releases actually, that is:
| > - 4 is a major release of Moose
| > - 4.1 is a minor release, but still something consistent
| > - 4.2.x should be for release in the main trunk, i.e. mostly dev and
| beta version before releasing a minor release (would be 4.2)
| > - 4.2.x.y is a branch of one developer (something short-lived,
| typically for a task resolution, once finished should be merged in
| main trunk)
| >
| > We could also follow the linux rule:
| > - 4.1, 4.1.1, 4.1.1.1 are the dev versions for the future 4.2 stable
| releases
| > - 4.2, 4.2.1 etc are minor and micro releases but stable, with bug
| fixes
| > i.e. minor is odd -> dev version, minor is even -> stable version
| > This does not mean we work on two versions in parallel (we dont have
| the manpower), but it just to help distinguish between dev and stable
| versions
| >
| > I'm just pushing ideas out of my head. Now, with this process, we
| have three main requirements for Moose:
| > - making it easy for anybody to retrieve (and identify it) the
| latest stable version
| > - making integration in the main dev trunk the priority (we have
| limited resources, so each developer should take care to merge its
| changes in the main trunk, and start over from the main trunk for a
| new task, NOT always working in the same branches)
| > - managing micro/nano releases from each developer
| >
| > I'm sorry if this feels too complicated and overly complex, it is
| not. I'm just playing with different schemas and see what could work
| best.
| >
| >
| -----------------------------------------------------------------------------------------------------------------------------
| > Now of course Metacello should not care about conventions (minor,
| micro...) of each project. Your proposition seems reasonable and
| flexible enough.
| >
| > But then, how can I ask for a version with a specific blessing?
| >
| >
| >
| > On 4 déc. 2009, at 18:48, Dale Henrichs wrote:
| >
| >>
| >> Thinking off the top of my head, would it be work to supply a
| pattern of some sort as an arg? Something like:
| >>
| >> ConfigurationOfXXX project lastVersion: '*.*'
| >>
| >> Not a real regex (because of the periods would need to be escaped,
| but mainly because reading regex for me is like trying to read
| russian:).
| >>
| >> Maybe best is a special purpose character like '#' in addition to
| the standard(?) smalltalk patterns '*' and '?':
| >>
| >> ConfigurationOfXXX project lastVersion: '#.#' ---> matches all
| major.minor
| >> ConfigurationOfXXX project lastVersion: '1.#' ---> matches all
| 1.minor
| >> ConfigurationOfXXX project lastVersion: '*' ---> is current
| algorithm
| >> ConfigurationOfXXX project lastVersion: '*.0' ---> matches
| versions with trailing .0
| >> ConfigurationOfXXX project lastVersion: '?.#' ---> matches single
| character major.minor
| >
| > I dont see what is the use of this one?
| >
| >
| >
| >> ConfigurationOfXXX project lastVersion: '1.#.3' ---> is invalid
| >>
| >> This one seems to the right approach ... I can add a #match: method
| to MetacelloVersionNumber to implement the pattern matching.
| >>
| >> What do you think?
| >>
| >> Dale
| >>
| >> ----- "Simon Denier" <Simon.Denier(a)inria.fr> wrote:
| >>
| >> | Suppose I have versions like this:
| >> | 1.3.2 #development --> branch by a developer
| >> | 1.3.1 #development --> branch by a developer
| >> | 1.3 #development --> main trunk, last dev
| >> | 1.2 #stable --> main trunk, last stable
| >> |
| >> | When I perform a ConfigurationOfXXX project lastVersion, I would
| like
| >> |
| >> | to retrieve the config for the last dev version common to
| everybody,
| >> |
| >> | and I would like this to be 1.3, not 1.3.2 which is the work of
| one
| >> | guy not yet merged in the main trunk.
| >> |
| >> | Right now, I get 1.3.2
| >> |
| >> | Perhaps we could have something like this:
| >> | 1.3.2 #branch --> branch by a developer
| >> | 1.3.1 #branch --> branch by a developer
| >> | 1.3 #development --> main trunk, last dev
| >> | 1.2 #stable --> main trunk, last stable
| >> |
| >> | and branch would be an 'unstable' tag ignored by the loader when
| >> | asking for latestVersion or lastVersion (and veryLastVersion
| could
| >> | retrieve the latest version, be it a branch, dev, or stable).
| >> |
| >> | I have no special requirements here, I'm just playing with the
| idea
| >> | and process of how to manage micro releases with Metacello.
| >> |
| >> | --
| >> | Simon
| >
| > --
| > Simon
| >
| >
| >
Simon,
I've been thinking about the same problems for GLASS ... I want it to be possible for individual developers to release bugfixes/improvements for sharing, but hadn't thought too far into it ... nano releases sounds like the right way to go...as far as a convention ...
Re: filtering on version and blessing ... I think that the special '#' character in patterns should stay ... blessings don't have a sort order so at the moment they are odd beasts ... for example I can't say 'belssing > #alpha' ... so perhaps we need to define a sort order for blessings ... I lean away from a canonical list of blessings, so folks would need to be able to add blessings/priority to a project ...
Have to come up with the low-level filtering api and then create come higher level helper methods ... I'm open to suggestions at the moment...
Dale
----- "Simon Denier" <Simon.Denier(a)inria.fr> wrote:
| Thinking again about the dev process specifically in Moose (not
| subprojects such as CAnalyzer, Mondrian...), branches for developer
| should be 'nano' releases actually, that is:
| - 4 is a major release of Moose
| - 4.1 is a minor release, but still something consistent
| - 4.2.x should be for release in the main trunk, i.e. mostly dev and
|
| beta version before releasing a minor release (would be 4.2)
| - 4.2.x.y is a branch of one developer (something short-lived,
| typically for a task resolution, once finished should be merged in
| main trunk)
|
| We could also follow the linux rule:
| - 4.1, 4.1.1, 4.1.1.1 are the dev versions for the future 4.2 stable
|
| releases
| - 4.2, 4.2.1 etc are minor and micro releases but stable, with bug
| fixes
| i.e. minor is odd -> dev version, minor is even -> stable version
| This does not mean we work on two versions in parallel (we dont have
|
| the manpower), but it just to help distinguish between dev and stable
|
| versions
|
| I'm just pushing ideas out of my head. Now, with this process, we have
|
| three main requirements for Moose:
| - making it easy for anybody to retrieve (and identify it) the latest
|
| stable version
| - making integration in the main dev trunk the priority (we have
| limited resources, so each developer should take care to merge its
| changes in the main trunk, and start over from the main trunk for a
| new task, NOT always working in the same branches)
| - managing micro/nano releases from each developer
|
| I'm sorry if this feels too complicated and overly complex, it is not.
|
| I'm just playing with different schemas and see what could work best.
|
| -----------------------------------------------------------------------------------------------------------------------------
| Now of course Metacello should not care about conventions (minor,
| micro...) of each project. Your proposition seems reasonable and
| flexible enough.
|
| But then, how can I ask for a version with a specific blessing?
|
|
|
| On 4 déc. 2009, at 18:48, Dale Henrichs wrote:
|
| >
| > Thinking off the top of my head, would it be work to supply a
| > pattern of some sort as an arg? Something like:
| >
| > ConfigurationOfXXX project lastVersion: '*.*'
| >
| > Not a real regex (because of the periods would need to be escaped,
|
| > but mainly because reading regex for me is like trying to read
| > russian:).
| >
| > Maybe best is a special purpose character like '#' in addition to
| > the standard(?) smalltalk patterns '*' and '?':
| >
| > ConfigurationOfXXX project lastVersion: '#.#' ---> matches all
| > major.minor
| > ConfigurationOfXXX project lastVersion: '1.#' ---> matches all
| > 1.minor
| > ConfigurationOfXXX project lastVersion: '*' ---> is current
| > algorithm
| > ConfigurationOfXXX project lastVersion: '*.0' ---> matches
| > versions with trailing .0
| > ConfigurationOfXXX project lastVersion: '?.#' ---> matches single
|
| > character major.minor
|
| I dont see what is the use of this one?
|
|
|
| > ConfigurationOfXXX project lastVersion: '1.#.3' ---> is invalid
| >
| > This one seems to the right approach ... I can add a #match: method
|
| > to MetacelloVersionNumber to implement the pattern matching.
| >
| > What do you think?
| >
| > Dale
| >
| > ----- "Simon Denier" <Simon.Denier(a)inria.fr> wrote:
| >
| > | Suppose I have versions like this:
| > | 1.3.2 #development --> branch by a developer
| > | 1.3.1 #development --> branch by a developer
| > | 1.3 #development --> main trunk, last dev
| > | 1.2 #stable --> main trunk, last stable
| > |
| > | When I perform a ConfigurationOfXXX project lastVersion, I would
|
| > like
| > |
| > | to retrieve the config for the last dev version common to
| everybody,
| > |
| > | and I would like this to be 1.3, not 1.3.2 which is the work of
| one
| > | guy not yet merged in the main trunk.
| > |
| > | Right now, I get 1.3.2
| > |
| > | Perhaps we could have something like this:
| > | 1.3.2 #branch --> branch by a developer
| > | 1.3.1 #branch --> branch by a developer
| > | 1.3 #development --> main trunk, last dev
| > | 1.2 #stable --> main trunk, last stable
| > |
| > | and branch would be an 'unstable' tag ignored by the loader when
| > | asking for latestVersion or lastVersion (and veryLastVersion
| could
| > | retrieve the latest version, be it a branch, dev, or stable).
| > |
| > | I have no special requirements here, I'm just playing with the
| idea
| > | and process of how to manage micro releases with Metacello.
| > |
| > | --
| > | Simon
|
| --
| Simon
Thinking again about the dev process specifically in Moose (not
subprojects such as CAnalyzer, Mondrian...), branches for developer
should be 'nano' releases actually, that is:
- 4 is a major release of Moose
- 4.1 is a minor release, but still something consistent
- 4.2.x should be for release in the main trunk, i.e. mostly dev and
beta version before releasing a minor release (would be 4.2)
- 4.2.x.y is a branch of one developer (something short-lived,
typically for a task resolution, once finished should be merged in
main trunk)
We could also follow the linux rule:
- 4.1, 4.1.1, 4.1.1.1 are the dev versions for the future 4.2 stable
releases
- 4.2, 4.2.1 etc are minor and micro releases but stable, with bug fixes
i.e. minor is odd -> dev version, minor is even -> stable version
This does not mean we work on two versions in parallel (we dont have
the manpower), but it just to help distinguish between dev and stable
versions
I'm just pushing ideas out of my head. Now, with this process, we have
three main requirements for Moose:
- making it easy for anybody to retrieve (and identify it) the latest
stable version
- making integration in the main dev trunk the priority (we have
limited resources, so each developer should take care to merge its
changes in the main trunk, and start over from the main trunk for a
new task, NOT always working in the same branches)
- managing micro/nano releases from each developer
I'm sorry if this feels too complicated and overly complex, it is not.
I'm just playing with different schemas and see what could work best.
-----------------------------------------------------------------------------------------------------------------------------
Now of course Metacello should not care about conventions (minor,
micro...) of each project. Your proposition seems reasonable and
flexible enough.
But then, how can I ask for a version with a specific blessing?
On 4 déc. 2009, at 18:48, Dale Henrichs wrote:
>
> Thinking off the top of my head, would it be work to supply a
> pattern of some sort as an arg? Something like:
>
> ConfigurationOfXXX project lastVersion: '*.*'
>
> Not a real regex (because of the periods would need to be escaped,
> but mainly because reading regex for me is like trying to read
> russian:).
>
> Maybe best is a special purpose character like '#' in addition to
> the standard(?) smalltalk patterns '*' and '?':
>
> ConfigurationOfXXX project lastVersion: '#.#' ---> matches all
> major.minor
> ConfigurationOfXXX project lastVersion: '1.#' ---> matches all
> 1.minor
> ConfigurationOfXXX project lastVersion: '*' ---> is current
> algorithm
> ConfigurationOfXXX project lastVersion: '*.0' ---> matches
> versions with trailing .0
> ConfigurationOfXXX project lastVersion: '?.#' ---> matches single
> character major.minor
I dont see what is the use of this one?
> ConfigurationOfXXX project lastVersion: '1.#.3' ---> is invalid
>
> This one seems to the right approach ... I can add a #match: method
> to MetacelloVersionNumber to implement the pattern matching.
>
> What do you think?
>
> Dale
>
> ----- "Simon Denier" <Simon.Denier(a)inria.fr> wrote:
>
> | Suppose I have versions like this:
> | 1.3.2 #development --> branch by a developer
> | 1.3.1 #development --> branch by a developer
> | 1.3 #development --> main trunk, last dev
> | 1.2 #stable --> main trunk, last stable
> |
> | When I perform a ConfigurationOfXXX project lastVersion, I would
> like
> |
> | to retrieve the config for the last dev version common to everybody,
> |
> | and I would like this to be 1.3, not 1.3.2 which is the work of one
> | guy not yet merged in the main trunk.
> |
> | Right now, I get 1.3.2
> |
> | Perhaps we could have something like this:
> | 1.3.2 #branch --> branch by a developer
> | 1.3.1 #branch --> branch by a developer
> | 1.3 #development --> main trunk, last dev
> | 1.2 #stable --> main trunk, last stable
> |
> | and branch would be an 'unstable' tag ignored by the loader when
> | asking for latestVersion or lastVersion (and veryLastVersion could
> | retrieve the latest version, be it a branch, dev, or stable).
> |
> | I have no special requirements here, I'm just playing with the idea
> | and process of how to manage micro releases with Metacello.
> |
> | --
> | Simon
--
Simon
vedea: new microsoft scripting graphices....
http://blogs.zdnet.com/microsoft/?p=4691
and
http://processing.org/
The future of mondrian may be in Cairo support or Juan works.
So consider to have a look at the cairo package in PharoTaskForces because it will not come to you alone :)
Stef
Thanks Fabrizio,
Please provide the following info:
- inFusion version
- case study (how to get the code)
so that I can reproduce the problem.
Cheers,
Doru
On 4 Dec 2009, at 12:43, Fabrizio Perin wrote:
> Hi Tudor,
> i have problem to export the mse file from inFusion. It doesn't work
> form the command line. Trying in the GUI I get this message:
>
> FAMIX 3.0 MSE Exporter could not be run !
> java.lang.NullPointerException
> at
> com
> .intooitus
> .infusion
> .util.FAMIX30MSEExporter.visitMethod(FAMIX30MSEExporter.java:171)
> at com.intooitus.memoria.core.Method.accept(Method.java:222)
> at
> com
> .intooitus.infusion.util.MSEExporter.exportToStream(MSEExporter.java:
> 70)
> at
> com
> .intooitus
> .infusion
> .plugins.tools.memoria.MSEExporterTool.run(MSEExporterTool.java:40)
> at
> com
> .intooitus
> .infusion
> .gui.ui.EntityMouseAction.actionPerformed(EntityMouseAction.java:198)
> at
> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:
> 2028)
> at javax.swing.AbstractButton
> $Handler.actionPerformed(AbstractButton.java:2351)
> at
> javax
> .swing
> .DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
> at
> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
> at javax.swing.AbstractButton.doClick(AbstractButton.java:389)
> at
> com.birosoft.liquid.LiquidMenuItemUI.doClick(LiquidMenuItemUI.java:
> 492)
> at com.birosoft.liquid.LiquidMenuItemUI
> $MouseInputHandler.mouseReleased(LiquidMenuItemUI.java:1161)
> at java.awt.Component.processMouseEvent(Component.java:6348)
> at javax.swing.JComponent.processMouseEvent(JComponent.java:3267)
> at java.awt.Component.processEvent(Component.java:6113)
> at java.awt.Container.processEvent(Container.java:2085)
> at java.awt.Component.dispatchEventImpl(Component.java:4714)
> at java.awt.Container.dispatchEventImpl(Container.java:2143)
> at java.awt.Component.dispatchEvent(Component.java:4544)
> at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:
> 4618)
> at java.awt.LightweightDispatcher.processMouseEvent(Container.java:
> 4282)
> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4212)
> at java.awt.Container.dispatchEventImpl(Container.java:2129)
> at java.awt.Window.dispatchEventImpl(Window.java:2475)
> at java.awt.Component.dispatchEvent(Component.java:4544)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:635)
> at
> java
> .awt
> .EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:
> 296)
> at
> java
> .awt
> .EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:211)
> at
> java
> .awt
> .EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:
> 201)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:
> 196)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:
> 188)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
>
> Hope that can help you.
>
> Cheers,
>
> Fabrizio
>
--
www.tudorgirba.com
"We are all great at making mistakes."
For example you can run the method
MooseModel class >> mseExportationTest
I remember that some times ago ( some weeks) it was not as long as that. Is
it normal ? Am I doing something wrong ?
