19 Jul
2016
19 Jul
'16
10:22 p.m.
On Tue, Jul 19, 2016 at 2:26 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Hi,
DynaCase is a generic editor : https://dynacase.github.io/
This would be nice if MOOSE and DynaCase are more integrate in the future.
--
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/
On Jul 19, 2016, at 5:52 AM, stepharo
<stepharo(a)free.fr> wrote:
Le 19/7/16 à 11:38, Tudor Girba a écrit :
Great.
Hi,
I think we are talking about two different things.
The GT interface is not for people that want to click, but for people that want to
program. Not the same audience, and I would certainly not use it for products dedicated to
people that do not want to program. We need a better infrastructure for end-user products,
and what we have now is not enough. I think that is not a Moose problem, but a Pharo one,
and it can only change with Bloc/Brick.
Also, we are talking about the development version of Moose, not the stable one. The
development version is not meant to be stable (even if it turns out to be stable enough).
For the Moose 5.1/Pharo 4 version, we had a couple of patches that happen after the
release, and they got integrated in the respective configurations. I think that shows that
we can do that if we really need to.
About a Famix fork: could it be that you are referring to extensions to Famix that are
specific to the languages that you are parsing, and not for the common parts? If not, I
would love to hear where the issues are and how we can correct them, because I did not see
public issues that were not integrated in quite some time.
In any case, I am happy that you are interested in investing in the modeling parts (Fame
and Famix). For example, it would be great to have traits deeply used. I would be happy to
work with people in any direction. Just make it public and let’s solve real problems.
Ok noted. I was sure you would say that so we will see.
This was discussed some years ago on this mailing-list. Check emails of nicolas and
anne.
We will send a call for job with a description of tasks we want. In a nutshell and from memory
- easier way to describe metamodels (probably based on platypus)
I think it is an interesting goal. I just want to keep as a goal the simplest mapping to
the Pharo code, too. Certainly, a separate DSL would be an interesting direction, but
another route here would be to have a better tool integration that allows us to map
meta-annotations to the code.
-- better handling relationships (union….)
Interesting. Do you have more details?
- probably revisit the bootstrap of FAME
because it is really arcane.
- use of slot for inverse FMmultivalue link
Yes.
- using traits at the meta meta level
Yes. And in Famix.
- see how we can integrate better with
dynacase toolings
Interesting. Could you detail that use case?