> Begin forwarded message:
>
> From: Marcus Denker <marcus.denker(a)inria.fr>
> Subject: [Pharo-dev] [JOB][Research] 3 Year Starting Research Positions
> Date: February 20, 2018 at 9:39:42 AM GMT+1
> To: Pharo Development List <pharo-dev(a)lists.pharo.org>
> Cc: Any question about pharo is welcome <pharo-users(a)lists.pharo.org>
> Reply-To: Pharo Development List <pharo-dev(a)lists.pharo.org>
>
> Inria opended a call for starting researchers. This is a three year contract.
>
> REQUIREMENTS
>
> - Have a French doctorate or an equivalent international degree
> - From 2 to 8 years of experience in research (after the thesis)
> - No age or nationality conditions.
> - Deadline: April 3rd, 2018
>
> Before writing their research program, the applicants are strongly encouraged to contact the teams
> or project(s)-teams leaders concerned by their applications. More information on the official website:
> https://www.inria.fr/en/institute/recruitment/offers/starting-research-posi…
>
> MISSION
>
> Join one of our two lines of research: Tools for Software Maintenance or New Programming
> Language Constructs for Software Evolution.
>
> THE REGION
>
> Lille is strategically located in Northern Europe with train connections to Paris (1h), London (1h30)
> and Brussels (30 min.) The Nord Pas de Calais region is a dynamic area in both industry and research
> for computer science with companies that are european leaders in their branch. Lille, the capital of
> northern France is an attractive metropolis of over 1 million inhabitants. Cost of living in Lille is lower
> than that of very big cities such as Paris and London.
>
> THE TEAM
>
> RMoD is an Inria research project team. It consists of 5 permant researchers (Inria CR and DR, as
> well as University Assistant Professors) and Engineers, postdocs and students (Master and PhD).
> RMoD is an international team with more than 20 members from six countries.
>
> LINKS:
>
> RMoD: http://rmod.lille.inria.fr
> INRIA Lille: http://www.inria.fr/lille/
> INRIA in General: http://www.inria.fr
> Lille:
> http://en.wikipedia.org/wiki/Lille
> http://wikitravel.org/en/Lille
>
> Please contact the head of the research team: Stephane.Ducasse(a)inria.fr or one
> of the following group members: Nicolas.Anquetil(a)inria.fr, Marcus.Denker(a)inria.fr
>
> Permanent Link: https://rmod.inria.fr/web/blog/2018-02-19
--
www.tudorgirba.com <http://www.tudorgirba.com/>
www.feenk.com <http://www.feenk.com/>
"From an abstract enough point of view, any two things are similar."
Dear Moosers,
I am trying to use Moose 6.1 (by the way, it is beautiful !)
I declared this method that should make visible all RMQLogEntity in the
MoosePanel :
MooseModel>>allRMQLogEntityGroups
   <navigation: 'All RMQ Log groups'>
   ^self allWithType: RMQLogEntity
The item "all rmqlogentity" is available in the MoosePanel, but when I
click on it, it generate an error (available attached).
I probably forget to declare something, but I do not remember which one.
Could you help me ?
Cheers,
Jannik
--
~~Jannik Laval~~
Enseignant-chercheur
http://www.jannik-laval.euhttp://www.phratch.comhttp://www.approchealpes.info
Hello everyone!
Some year ago, Moose included a query mechanism called MooseChef.
This mechanism worked but was hard to maintain and it was easy to make
mistakes in the queries.
In 2015 Jean-Christophe Back and Anne Etien created MooseQuery.
MooseQuery is a domain-specific language to build navigations and
scopes queries for entities in Moose.
I helped to improve the performances of MooseQuery in order to use it
at Synectique and today I present you a documentation of MooseQuery:
https://moosequery.ferlicot.fr/
This documentation cover three axes:
- The user documentation: explain how to use MooseQuery to query a model
- The developer documentation: explain how to expand a meta-model to
make it queriable by MooseQuery and explain how the queries work
internally
- The API documentation
The documentation was already reviewed and enhanced by Anne.
If you wish to contribute, you can do a pull request to
https://github.com/jecisc/MooseQueryDocumentation.
I hope this can help Moose's community.
Have a nice day :)
--
Cyril Ferlicot
https://ferlicot.fr
Hello everyone!
Some month ago I sent a mail asking to ensure that all FAMIXEntities
could answer to all MooseQuery queries. The answer was no because the
community does not want some entities to be able to answer to every
query. (For example to have associations that can answer to navigation
queries).
This bothered me because we already have entities that can answer to
#children, #parents, #toScope:, #atScope:... even if it does not make
any sense.
Now I come back with a proposition to clean this half/half state and
to get a clean model query side.
I discussed these changes with Anne and she agrees with them.
In the current state of MooseQuery we have:
- TMetaLevelDependency used by FAMIXEntity that allow querying the
children, parents, and scopes of an entity
- TEntityMetaLevelDependency using TMetaLevelDependency. It adds the
navigation queries.
- TAssociationLevelDependency using TMetaLevelDependency. It adds some
useful methods to associations for the navigation queries.
We have two changes to propose.
First. It does not make any sense for TAssociationMetaLevelDependency
to use TMetaLevelDependency since an association should not be able to
answer to #children, #parents, #toScope:...
We propose to remove this usage. I did this change in an image and
launched MooseQuery/Chef tests, everything is green.
Second. TMetaLevelDependency does not make any sense when we have
TEntityMetaLevelDependency.
All the methods of TMetaLevelDependency are related to entities.
We propose to copy all the methods of TMetaLevelDependency to
TEntityMetaLevelDependency and remove it.
TMetaLevelDependency has two users: FAMIXEntity and
TEntityMetaLevelDependency. Since we copy the methods to the second
user, there is no problem with it. The biggest change is that now
FAMIXEntity will not implement any Meta trait. It does not need to use
any since all its subclasses should not understand generic queries.
The only change that needs to be done is to move the caches created on
FAMIXEntity to the users of TEntityMetaLevelDependencies.
I tried to apply this changes in a quick and dirty way to an image and
once again all tests seem to pass.
In conclusion, what do we win with this changes? All Famix entities
will only understand the queries they can answer to. FAMIXAssociation,
FAMIXSourceAnchor, FAMIXSourceLanguage will not understand anymore
#children, #parents, #toScope:, #atScope:...
Have a nice day :)
--
Cyril Ferlicot
https://ferlicot.fr
---------- Forwarded message ----------
From: Jigyasa Grover <grover.jigyasa1(a)gmail.com>
Date: Wed, Jan 10, 2018 at 6:10 AM
Subject: [Pharo-dev] Google Summer of Code 2018 with Pharo Consortium
To: pharo-dev(a)lists.pharo.org
Hello Pharo-ers !
On behalf of the community, I would like to thank each one of you for their
significant contribution in the previously concluded *Google Summer of Code
2017* with *Pharo Consortium*. We aspire to take-off on a long flight after
this successful stint by applying to participate in the upcoming *Google
Summer of Code 2018*.
As many of you might know, Google Summer of Code is a global program focused
on bringing more student developers into open source software development.
Students work with an open source organization on a 3 month programming
project during their break from school. Read more about the program here:
https://summerofcode.withgoogle.com/
The deadline for organisations to apply is January 23, 2018 which is fast
approaching. As an open source evangelist and a Pharo developer, I would
like to invite all the experienced members to be a part of the "GSoC 2018
with Pharo Consortium" Team and mentor students. Propose fresh ideas for
projects which shall help improve Pharo or volunteer to mentor any of the
existing one (Listed here: http://gsoc.pharo.org/). To add your own project
idea to the list, visit http://gsoc.pharo.org/#adding-a-proposal
Looking forward to an appreciable representation from the Pharo community.
Best regards
Jigyasa Grover
Pharo Consortium Org Admin, Google Summer of Code 2017 [hidden email]
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
--
Serge Stinckwich
UMI UMMISCO 209 (IRD/UPMC/UY1)
"Programs must be written for people to read, and only incidentally for
machines to execute."http://www.doesnotunderstand.org/