Moose and Pharo?
Locked
12
12
Re: Moose and Pharo?
 
|
On Tue, Jul 19, 2016 at 7:52 PM, stepharo <[hidden email]> wrote:
> > > Le 19/7/16 à 11:38, Tudor Girba a écrit : >> >> 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) > -- better handling relationships (union....) > - probably revisit the bootstrap of FAME because it is really arcane. > - use of slot for inverse FMmultivalue link > - using traits at the meta meta level > - see how we can integrate better with dynacase toolings (a little off-topic but a minor business opportunity...) If you are updating the metamodel, would you consider making the OMG Model Driven Architecture (MDA) [1] compatibility loading from XMI files a first class citizen. To put this in perspective for just one industry... Historically when electricity markets were provisioned by single government owned entities, each network could be managed with unique and monolithic software systems. In comparison, the trend today to deregulate electricity markets requires a growing number of independent market participants to interact, which in turn requires standardisation of the system model. The U.S. Energy Independence and Security Act of 2007 (EISA) put the National Institute of Standards and Technology (NIST) in charge of coordinating development of protocols and model standards to achieve interoperability of Smart Grid devices and systems. The U.S. Secretary of Commerce and Secretary of Energy met with executives from Smart Grid industries to commit to supporting NIST in this endeavour with a $3.4 billion in government grants and $4.7 billion from private companies. NIST ran public workshops encompassing 1,500 individual Smart Grid stakeholders to produce a document [2] defining sixteen Priority Action Plans of which three encompassed the IEC 61970 Common Information Model (IEC-CIM) (refer Table 2-2 [3]). The market for Smart Grid-related hardware, software, and services was forecast in 2009 to be $43 billion for the U.S. in 2014 and $171 billion globally. There has** to be a market for helping energy utilities to understand and convert their legacy software to the new interoperable Standards, and to track the history of model revisions for which Moose might be an appropriate tool. For example, [7] indicates about $140M in research funding that at least touches IEC 61970. Enterprise Architect is being quite smart about it - getting in bed with standards organisations utilising MDA to produce industry information models [4]. Thus everyone that wants to interoperate with anyone else in these domains needs to use the International Standard, and EA is there ready to help by providing a free viewer. Indeed the IEC-CIM is maintained as a UML model [5] using EA, and the dozen IEC 61970 standards documents are generated from the model. (btw buying the dozen or so IEC 61970 Standards Documents probably costs a few grand [5], but the CIM model is free to download (see attached screen snapshot) for universities after signing up to the CIM User Group [6]) ** Except where I live the opportunities are not so great having one small 3GW grid with 4 main generation operators versus the European 1023GW grid with 41 generation operators interconnected over 35 countries. cheers -ben _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Screenshot-Current Official CIM Model Releases - Google Chrome-1.png (168K)
Re: Moose and Pharo?
|
|
Re: Moose and Pharo?
|
|
In reply to this post by stepharo
Hi,
since I saw many times "Synectique" on the conversation I would like to make the comments about my experience of Moose at Synectique. For the stable and alpha version of Moose I don't think there is a problem to get the moose stable on the Pharo stable and the Moose dev on the Pharo dev. It's true that sometimes we need some features that are not in the stable but in the dev. For this I think that making Moose a sort of meta-project grouping some little project would make easy to load a specific version of what we need. For example we could use Moose stable and load small dude dev after. But making branch as in Moose51 with Monticello is a really bad idea. I will come back on this point later. A bad point about Moose is that it make configurations really really really hard. I spend days to fight with configurations. In Pharo 4 there was bugs with the configurations and the configurations of Moose were really hard to deal with. A part of the problem comes from the branch to backport some features. They messed up *a lot* with the configurations. This should not be redone with Monticello. NEVER! We never end with the right commits, when the configuration load. I can't count anymore the number of "The version XXX was not found. Possible versions: #stable, #development, #bleedingEdge, 1.0, 2.0, XXX, …". Another problem is that there is 2 ConfigurationOfGlamourCore (or Glamour? I don't remember) in two repositories… This cause a lot of bug because they are not the same and they can't co-exist in the same image. I got many errors because the wrong one was in the image and Metacello could not find the right version. The problem is increased when you add the fact that a lot of projects have bad dependencies and load everything, glamour is in a *lot* of configurations. I saw pure model project that loaded GlamourCore, Glamour, Roassal, Merlin during the loading because everything depend on everything. This is the reason why we had a "fork" of Moose. And our configurations depending on Moose51 are full of "spec postLoadDoIt: #hackScript" that remove and reload some packages because we lost too many time on configurations. When we moved on the web we begun to build our tools in an image with Moose and our old tools. This month I cut made the configurations to load our web tools without the old UI. It worked at the first try! Usually I spend days to get a working configuration. This problem can be lessen with better defined dependencies (For example on Moose group Core we get Roassal and Glamour… But if I only want the model? Why am I forced to get the UI?). Not using branches in Monticello anymore (*please*). Having *one* configuration in one repository for each projects. This was improved in Moose 6 with the ConfigurationOfFamix. This is a first step but there is still dependencies problem. For example the famix tests cannot be in the famix configuration because they depend on Moose. For the branches problem, moving to git when the tools will be ready can improve that. Another problem was that the metamodel is not practical to build good tools. We have to hack a lot in Famix to build our tools. But everyone know that and you already talked about hiring someone to work on this. Since Synectique already gave his point of view on this I will not talk more about this point. About moving on the web, our major concerns was: - To not have the configurations problem anymore - To have good looking interfaces - To build interfaces fast - To get profit from all the good and stable JS libraries - To deploy easily (It's fastest to deploy an headless server that blocking everything as halo, debugger, spotter, etc in an image and to install it on every computers) In 1 week we can create a Tool that is good to look and easy to use when we cannot do it in Pharo. Glamour is "smalltalk oriented", this is not what we need for customers that are not smalltalkers. For this point I think that Pharo will have improvements with Bloc/Brick and Spec. But we cannot wait and we cannot contribute because we are 2 full time developers and 2 part time developers. We cannot make the tools, fill the contracts AND make huge contributions to Pharo/Moose. I try to make some small contributions on my free time but at Synectique we don't have the time or the company will not survive. Moving to the web speed up a lot our work and be get a better result. Much more stability, more performent, easy to build, fast to build, easy to map JS library… I don't want to hurt anyone and I know that everyone work hard. I shared my feeling for you to get the vision of someone using Moose in production tools. I hope that this can help you. There is a lot of work everywhere. For example Moose with configurations, Famix and the model, UI frameworks with the look and stability, Pharo with git and deployment. I hope that I will see everything improve little by little. :) I am sure that most problems will be resolved with time, if we choose to not use anymore some things it's just because we don't have this time and we don't have the man power to clean/improve everything. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: Moose and Pharo?
|
|
Re: Moose and Pharo?
|
|
Le 20/07/2016 à 07:12, Tudor Girba a écrit :
> Hi Cyril, > > Thanks a lot for the detailed email. > > Please do not apologize because there is really nothing to apologize for. Moose is an open project that welcomes any amount of effort and nobody should feel bad because the effort did not meet whatever standard. > > It’s better to look at the issue from a more positive perspective and describe the problem as you face it (like you did here). Emails like these are the prerequisite for being able to address your points at all. > > If I understand correctly, an important problem is to be able to reuse parts independently. We can address that one, so let’s work on this and finalize ConfigurationOfFamix. What do you say? > I think this is important to be able to reuse parts independently if you want people building tools in top of Moose and if you want Moose to be used in business. Moose is big and I think most companies that want to work with Moose will start to use all Moose to start, but later they will not need everything. I think it's good to let users takes the part they needs. If you make your own browsers, you don't need Glamour/Roassal/Merlin. If you don't care about duplication then you don't have to be forced to get Dude. Another use case is: Imagine you don't want to slow you tool during the generation of a MSE. You can have an image 1 with Moose that will call an image 2 with the parser. Then the image 2 don't need Moose but only the parser and FAMIX. As I said, at Synectique we don't bring all moose anymore but only the parts we need. And on our Jenkins we can see a lot of "Undeclared" because everything depend on everything. It's hard to clean it but if we do it slowly it will not impact Moose and it will make thing easier for people wanted to work with it. I think that Moose should be a sort of "Meta configuration" and all the part could be load independently. We could have a CI job for each build to check that they do not use undeclared classes/variables anymore. (For example now, if you want only smalldude, you need Moose-Tests-Core and Moose tests core depend on half the packages of Moose, at least). For a platform that promote good modular and good code, this is bad publicity. :) I agree that the first step is to get a good ConfigurationOfFame and ConfigurationOfFamix. For the ConfigurationOfFamix I think the steps are: - Clean cyclic dependencies - Cleans the tests packages of FAMIX that are still in the Moose configuration since they depend on Moose - Remove all the problem we see in Jenkins logs: https://ci.inria.fr/moose/job/Famix/PHARO=60,VERSION=development/21/console - I also think that Famix should not have the importers directly and we should have a ConfigurationOfFamixImporters. > Cheers, > Doru > > -- > www.tudorgirba.com > www.feenk.com > > "Be rather willing to give than demanding to get." > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev > Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: Moose and Pharo?
|
|
Re: Moose and Pharo?
|
|
On 21/07/2016 14:38, Tudor Girba wrote: > Hi Cyril, > > > Everyone agrees that we need to create better configurations, and there were multiple calls for help in the past but until now nobody answered :). > > But, I am happy that you want to invest time in this. > > >> I agree that the first step is to get a good ConfigurationOfFame and >> ConfigurationOfFamix. >> >> For the ConfigurationOfFamix I think the steps are: >> - Clean cyclic dependencies > > Yes. > >> - Cleans the tests packages of FAMIX that are still in the Moose >> configuration since they depend on Moose > > I do not understand this part. We should rename the importer and test packages to not have Moose in the name, but Famix. > the Famix one. This is caused by the fact that Famix tests have dependencies on Moose packages. We cannot launch the tests of Famix without Moose for now. This should be cleaned. Some dependencies need to be cut. Some things that are in Moose's packages need to move on Famix. Maybe some packages might need to be cut into smaller ones. > >> - Remove all the problem we see in Jenkins logs: >> https://ci.inria.fr/moose/job/Famix/PHARO=60,VERSION=development/21/console > > Ok. > >> - I also think that Famix should not have the importers directly and we >> should have a ConfigurationOfFamixImporters. > > Agreed. > > Doru > > -- > www.tudorgirba.com > www.feenk.com > > "Problem solving should be focused on describing > the problem in a way that makes the solution obvious." > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev > Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: Moose and Pharo?
|
|
Re: Moose and Pharo?
|
|
Re: Moose and Pharo?
|
|
Re: Moose and Pharo?
|
|
On 21/07/2016 17:28, Anne Etien wrote: > Hi, > > As Stéphane announced it, we have an engineer position for two years to > modify FAME and FAMIX to make them more easily adaptable… and to adapt > existing tools to this new core. So perhaps, somethings could be done in > parallel, but in the opposite, perhaps, we should not take too much time > to modify the current version since we will rebuild a new one. > > Anne > PS: I am writing the position description to send it to the list and > audition interested people in ESUG. > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev > I think that we should not wait to correct this kind of things because most of the problems are not related to FAMIX but are general problems of any project. If we have people that are willing to help cutting bad dependencies and improving the configurations, that will let more time to the engineer to work on the model itself. I think it would be good at ESUG to make a sort of roadmap of the things to do (for example I would like Moose-Core to be cut into FAMIX-Importers, FAMIX-Presentation, FAMIX-Critics, FAMIX-AbstractModel…). With that roadmap we could begin to clean and when the engineer will be here he will know what to do next. Thanks to RMoD for helping Moose to improve! -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Re: Moose and Pharo?
|
|
| Free forum by Nabble | Edit this page |