> Begin forwarded message:
>
> From: Sven Van Caekenberghe <sven(a)stfx.eu>
> Subject: [Pharo-users] [ ANN ] Pharo Days 2016
> Date: December 9, 2015 at 9:52:09 AM EST
> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org>, Pharo Development List <pharo-dev(a)lists.pharo.org>, Pharo Business <pharo-business(a)lists.pharo.org>
> Reply-To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org>
>
> Dear fellow Pharoers,
>
> Mark your calendars: on Thursday March 31 & Friday April 1 we are organising the Pharo Days 2016. This year we moved the location to Namur, Belgium, just a bit south of Brussels, at the very beautiful location of the ‘Cercle de Wallonie’ overlooking the river Meuse.
>
> We’ll update the following page moving forward.
>
> https://medium.com/concerning-pharo/pharo-days-2016-c52fe4d7caf
>
> You can ask questions on any of the Pharo mailing lists or you can email the Pharo Board.
>
> Let's make this another success, together ! We hope to see as many of you as possible.
>
>
--
www.tudorgirba.com
"We are all great at making mistakes."
Hi moosers,
When loading Moose 7, PetitJson is not included.
Is it voluntary ?
Cheers,
--
~~Jannik Laval~~
Enseignant-chercheur
Responsable Pédagogique Licence Coordonnateur de Projet
IUT Lumière, Université Lumière Lyon 2
laboratoire DISP
+33 4 78 77 43 06
http://www.jannik-laval.euhttp://www.phratch.comhttp://www.approchealpes.info
Hello
I want to execute statement
RTHTML5Exporter new export: aRoassalView
How?? to download exporter or?? exporter for???? Glamorou browser.
I read moose book and want use it for logistic application.
Feliks
Hi,
We are currently cleaning the traits in FamixNG.
Once again, the idea is to remove FamixCompatibility metamodel and to keep only FamixStEntities or FamixJavaEntities (and so on). Obviously, it has incidence on tests.
Do you use FamixTypeGroup, FamixClassGroup… and more generally groups in Famix?
Thank in advance for your answer.
Anne
Hello everyone!
I'm glad to announce the release of Moose v7.0.0.
I'll explain the main changes since Moose 6.1 and what are the future
plans for Moose 8 in this mail.
* What changed?
In this version of Moose a lot of things changed from the meta model
management point of view. In Moose 6.1 we only had one big metamodel
build with inheritance to analyze all languages. This had a lot of
limits and a lot of work has been done to improve Moose on those weak
points.
In Moose 7, you can now have multiple meta-models independant from
each others. This mean that we will now have one meta model by parser.
We can also create simple meta-models for test purpose. Also those MM
are build by composing stateful traits instead of using inheritance.
On top of that we now also have the possibility to use generators to
manage meta-models. Instead of writing every classes by hand, we can
describe a meta-model in a generator and use it to generate the MM.
Then we can use it to regenerate it also.
Pavel, who did most of the work, wrote some documentation you can find
here: https://pavel-krivanek.github.io/famix/
There is still a lot of work to do to make it better but this will
come with Moose 8. The reason we release now is that in Moose 7 we
started to have split MM for Java, Pharo, and other languages, but we
still have a compatibility meta-model. The work needed to improve
Moose further will require to break the compatibility MM. Thus we are
releasing a stable version now with a compatibility MM and we will
work on a Moose 8 version where the compatibility MM will be removed.
* Workflow for bugfixes
Another change with Moose 6.1 is that now Moose is managed via Github.
This will allow use to do patches or minor releases in case the
community find bugs or need some new simple features in Moose 7 as
long as it only contains backward compatible changes.
* Plan for the next release
We already stated to work on Moose 8. We plan to work on multiple aspects:
- Improve the usability of the generator, especialy while regenerating MMs
- Update the Traits contained in Moose to build our MM. Currently,
they are a reproduction of what was in Moose 6.1 in order to get the
compatibility model. The goal is to remove all the hacks and get
cleaner traits.
- Start to build new tools to use the full power of this new version of Moose
- Fix bugs that will be discovered after such a big change
* How to get Moose 7
You can get Moose 7 in two ways. First is to install it in a Pharo 7 image:
```
Metacello new
baseline: 'Moose';
repository: 'github://moosetechnology/Moose:v7.x.x/src';
load.
```
The second is to get it via the Pharo Launcher. It now has a Moose 7
entry to get this version and a Moose 8 entry to get the development
version.
We will also need to update Moose technology website.
* Credits
Thank to Pavel Krivanek who did most of the work.
Thank also to:
- Benoit Verhaeghe
- Julien Delplanque
- George Ganea
- Christopher Fuhrman
- Stephane Ducasse
- Anne Etien
- Nicolas Anquetil
- Cyril Ferlicot
And any other I might have forgot who participated in the development
of Moose 7 :)
--
Cyril Ferlicot
https://ferlicot.fr
Hi,
Last month we did some changes to the MM generator of the development
version of Moose and it might impact people using it.
I'll explain the changes and what to do in this mail.
Context:
In the development version of Moose, we have two ways of building a
metamodel. The first is to do as in Moose 6.1 and write it by hand.
The second and recommended way is to describe it in a MetaModel
generator and to generate it.
This generator is also able to regenerate a metamodel. In order to do
that, it needs to know the Traits and Slots it generated. This was
done by generating two methods on each entity: #generatedSlotNames and
#generatedTraitNames.
Changes:
With Julien Delplanque, we updated Moose to remove the need of those
two methods. For Traits, we are now able to just ask an entity for its
Traits that are part of the metamodel. Thus, we do not need the
#generatedTraitNames method. For Slots, we have two kinds. One that
describe a relation between entities and another that store
properties. The relations already had a slot specific to Famix. We
introduced another one call FMProperty to be used to store the
properties. With that change, all slots generated by the generator are
specific to Famix, thus we can lust ask a class for its famix slots
and we do not need to generate a static method with the slot names in
entities.
Actions to take after this change:
We added some compatibility code to keep things working during a
transition period. Two actions are needed if you want a clean MM after
those changes:
- The first one is to remove the #generatedTraitNames methods from the
class side of generated entities.
- The second one is to regenerate your metamodel and this will
automatically replace InstanceVariableSlot by FMProperty and remove
#generatedSlotNames methods.
Change in generator behavior:
This change as a side effect you need to know. Before, regeneration of
MM was updating only the Traits and Slots it generated. Now it will
regenerate all Traits that are part of the metamodel (with a
#MSEClass:super pragma) and all Famix slots. Thus, if you are managing
a MM via a generator, you need to update the generator description to
add a Trait or Slot from Famix instead of adding it by hand. Else, it
will be removed during the next generation.
--
Cyril Ferlicot
https://ferlicot.fr
Hi everyone,
As already explained, we are currently cleaning the traits in FamixNG. Pavel did a great job by providing a back office to create new meta model with a tiny DSL and by building the old meta model using the new infrastructure. Now, we want to:
- clean elementary traits (for example when there is a FMMany slot, sometime there is an addXXX method and sometime not)
- compose traits (FamixTClass is not a composition of traits, it has to be done when we build the meta model), to provide semantically rich traits.
- be sure that tests are passing. They were tests in FamixNG, only to ensure compatibility with the old meta model.
Consequently, I developed a generator to create tests associated to elementary traits. Normally you don’t need to use this generator if you use only build traits by composing existing ones.
Anyway, if needed, you can get the generator from FamixNG-TestGenerators package in TestGenerator3 branch:
fttg := FamixTestAndTraitGenerator new.
fttg runFor: FamixTClass
I developed a second generator to generate tests from the trait composition. We will use it after cleaning FamixNG. Obviously, later the generator has no vocation to remain in the image, tests will be generated once and you can add tests by hand.
fcg := FamixComposingTestTraitsGenerator new.
fcg addingTraitsToTestTraitFor: FamixTClass
For using this later, we need that a correction in Pharo concerning composition of traits with slots is back tracked in Pharo 7. Or you can use the attached file.
We already get 135 tests for FamixNG and we will continue.
If you have any question don’t hesitate.
Anne
