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 ?
Hi,
I would kindly ask you to place an entry in the issue tracker before
you start working on something (even if it's not a bug):
http://code.google.com/p/moose-technology/issues/list
Also, when you add an issue, please make sure to tag it at least with
the Component that is affected by it. If you want to work on it, also
assign it to yourself.
This has the benefit of communicating your intention around and
synchronize with the rest of us. If you want to be up to date with the
changes in the issue tracker, you can subscribe to the RSS feed:
http://code.google.com/feeds/p/moose-technology/issueupdates/basic
Cheers,
Doru
--
www.tudorgirba.com
"Beauty is where we see it."
If there are not dependencies back to Moose, having the filter in Fame
is genau the right place.
--AA
On Dec 3, 2009, at 11:49 , Cyrille Delaunay wrote:
> Ok. But the class 'ParseClientFilter' is not FAMIX-specific and I
> thougth it would maybe be usefull for fame. If it's not, I can move
> it into a moose package :)
>
> 2009/12/3 stephane ducasse <stephane.ducasse(a)gmail.com>
> but cyrille
>
> FAMIX stuff should not polute Fame
> so you should extend (subclass) in moose pckage and hope that FAME
> will take your extension into account.
>
> Stef
> On Dec 3, 2009, at 11:34 AM, Cyrille Delaunay wrote:
>
> > Hi,
> >
> > I just save some changes on the Fame squeaksource repository:
> >
> > - Implement a 'ParseClientFilter' that enable to parse and import
> mse filtering some elements. This is use in Moose to specify the
> FAMIX elements (FAMIX.Class, FAMIX.Method, ...) you want to import
> in a MooseModel from a MSE File (This is already available by
> selecting 'import from MSE' in the MoosePanel).
> >
> > - Two Lint rules in Fame-Util about the Moose issue 143
> > -> checking if a FM3 class respect the fame name convention
> between FM3 and Smalltalk
> > -> checking if the superclass defined in a FM3MetaDescription
> t exist and is well defined.
> >
> >
> >
>
>
>
Hi Cyrille,
The MSE Import Wizard is a good step forward, but it has a problem:
The entity types are hardcoded. This is a big problem because we
should be able to load any entity.
It would be better if that list would be gathered from the types from
MooseModel meta.
ImportingContext should not be hardcoded either, but it should be
computed from the same repository by traversing the properties.
For example, in FAMIXMethod>>parentType says that FAMIXClass is
required for FAMIXMethod. In the same time, FAMIXMethod is not
required for a FAMIXClass because the property FAMIXClass>>methods
isDerived. Basically in this way, we should be able to create the
graph dynamically and thus we can use the mechanisms for any meta-model.
What do you think?
In the meantime I restored the previous implementation as a temporary
solution, because now we have PrimitiveType that should also be
loadable.
Cheers,
Doru
--
www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
Hi,
inFusion 7.2.6 was just released:
http://www.intooitus.com/infusion/download/inFusion.zip
With it, we now have export of PrimitiveType and of declaredType for
Method, Function and all variables. Also the access modifiers are now
correct.
Cheers,
Doru
--
www.tudorgirba.com
"No matter how many recipes we know, we still value a chef."
Unfortunately, there have been too many threads this morning
*About Metacello*
Well Metacello is still in beta, so good news is that we can make it
better. Problem is that it can do a lot of things about which we (I)
dont a clear picture for now, it requires some usage and conventions,
and myself I'm still quite unsure about how Metacello manages nested
configuration (for example right now, when I perform a
ConfigurationOfMoose updateDefault, it does not update the nested
configurations. I am not sure but I think it should)
Suggestions:
1) have better names
loadLast -> loadDevVersion or loadVeryLast
loadLatest -> loadStableVersion or loadLastStable
(those 2 are really annoying)
Also the names in the OB commands could be better and reflect the
current conventions:
Save project -> save configuration
update project -> update configuration
Update Package Methods -> update current version???
Now, when I do a "Current Project Version" on any ConfigurationOf, it
does not work except for the one with Metacello. I dont know, maybe
the configurations do not respect some rules? It's annoying because it
breaks the above tools.
2) refactor the documentation
When I started with Metacello 3 months ago it was easy because there
was one recent post describing the things. Now three months later this
is a problem because things have changed a lot but this post is still
the first hit in google "metacello"
http://gemstonesoup.wordpress.com/2009/08/25/metacello-package-management-f…
Now if you try to follow links there is this post and then this post
http://gemstonesoup.wordpress.com/2009/10/14/a-shiny-new-api-for-metacello/http://gemstonesoup.wordpress.com/2009/11/16/metacello-1-0-beta-14-released/
Finally it appears that
http://code.google.com/p/metacello/w/list
is now the source for documentation.
There is the API reference for declaration, description of
OBCommands,...
Unfortunately it lacks something about how to play with last/latest
versions with the API.
- if I go to the tutorial, it just refers to the embedded tutorial in
the code and I dont want to load the tutorial each time I need some
documentation
So please Dale, can you put a few items about things such as
ConfigurationOfXXX project lastVersion, how to manipulate groups,
things discussed with Lukas?
3) Good tool for managing configuration, saving projects...
There is a small browser in GLMSmalltalkExamples>>metacelloBrowser,
maybe somebody can start to enhance it to display version and perform
commands.
*About the Moose process*
I dont think the Pharo process and the Moose process compare.
The Pharo process is about integrating fixes from packages which are
supposed to do one and only one thing, and do it well and is tested.
The Moose process is about developers making incremental changes to
the code base so that they can work and share it immediately. Which
means it can break other things.
Now I'm pretty sure I dont want a release every time someone commits a
package in Moose, because I'm pretty sure this someone didn't run all
the tests before committing. So making a release for each new commit
makes no sense for me. We dont integrate changes, we just merge when
there are some divergent branches. That's why we are always working
with the dev version and the 'default' is one way to do it.
If we want historical data about Moose, I guess it's still possible to
retrieve all latest packages at a given date. It will not be very
different from what we used at this date.
Now about the *release* process for Moose: sure I would like that
there will be more releases. Now as Doru said, when we do a release,
we should do it for every sub projects and it's bit difficult with the
current tools.
- One way to do automatically it is to use the test server to at least
create a new version from the latest dev version and blessed it as
'tested' if 100% tests passed or 'broken'
But I dont want such versions to pollute the manual versions, which
are supposed to be stronger. So something like create automatically
'testedVersionXXX' with tests or broken as possible blessing.
- Then we can do manual release from time to time (every two weeks,
every months?), which requires more work as we have to do it for the
different subprojects first, and blessed it as beta or stable.
BTW, why is the beta version in Moose marked as 'baseline'? It does
not make sense. It should be beta or stable.
--
Simon
