reporting system for pharo

> Hello,
>  In order to provide a reporting system for pharo, I implemented  
> some tools over arki, build some concerns, work on way to save  
> reports.
> There still work to do, but you can already test it and give me  
> feedback if you want :):
>
> Download the package 'MooseComputedConcerns' at: www.squeaksource.com/MooseDemoReport
> .
> A message will tell you to resolve depencies by first loading  
> 'System-Benchmarks'.
> As the concern about benchmarks is not finished you can choose to  
> 'proceed' (the benchmarkConcern will just not been working).
> Otherwise you can load 'System-Benchmarks' from the same repository  
> (allow 'block argument assignement' in the settings before).
>
> Then you will be able, in the moose panel, to right click on a model  
> and open a arki reporter.
> You can then play a bit with the browser.
>
> pay attencion : load the last version of 'Refactoring-core' to be  
> able to use the LintRules-Concern
> --------------------
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> Ok, it should be ok for the override.
> But I think I still do not understand how should be saved the  
> concerns :)
> When I finish to build a report, I have a collection of REPConcern's  
> objects. Then I do not see how to save directly those objects as  
> Methods. What should I do with those objects?
>
>
> 2010/8/23 Tudor Girba <[hidden email]>
> Hi Cyrille,
>
> I took a look. As I mentioned in a private email, it is a nice  
> start, but I think it would be nicer to get the saving of concerns  
> towards directly compiling as methods in the concern class.
>
> Now, an important issue: you are still overriding  
> REPConcernSpecification>>open. Please delete this override.
>
> Cheers,
> Doru
>
>
>
> On 20 Aug 2010, at 17:23, Cyrille Delaunay wrote:
>
> Hello,
>  In order to provide a reporting system for pharo, I implemented  
> some tools over arki, build some concerns, work on way to save  
> reports.
> There still work to do, but you can already test it and give me  
> feedback if you want :):
>
> Download the package 'MooseComputedConcerns' at: www.squeaksource.com/MooseDemoReport
> .
> A message will tell you to resolve depencies by first loading  
> 'System-Benchmarks'.
> As the concern about benchmarks is not finished you can choose to  
> 'proceed' (the benchmarkConcern will just not been working).
> Otherwise you can load 'System-Benchmarks' from the same repository  
> (allow 'block argument assignement' in the settings before).
>
> Then you will be able, in the moose panel, to right click on a model  
> and open a arki reporter.
> You can then play a bit with the browser.
>
> pay attencion : load the last version of 'Refactoring-core' to be  
> able to use the LintRules-Concern
> --------------------
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Being happy is a matter of choice."
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

>  I also understand why 'generic' concernc (like distributionMap)  
> doesnt really feat with the concept of Concern having a result and a  
> status.
> Only The user that want a specific DistributionMap know which kind  
> of information he want to retrieve from it, and therefore what will  
> be the 'status'. Am I right ?
> In this case it's better to let the user create its own subclass
>
> 2010/8/25 Cyrille Delaunay <[hidden email]>
> By looking at the onMooseReport, I understand wht you mean :)
>
> 2010/8/24 Cyrille Delaunay <[hidden email]>
>
> So each time I want to create a concern with specific parameters, I  
> create a subclass with accessors returning directly the concrete  
> value of those parameters?
>
> For example, If we take the DistributionMap I did. I have several  
> parameters that I can specified when creating such a concern :  
> label, explanation, containers, elements, property.
> If I want a report ('CyrilleReport') containing a  
> DistributionMapConcern, with specific values fore these parameters.  
> I should crate a new subclass of DistributionMapConcern returning  
> directly the specific values, Am I write?
>
> But even with that solution, if I want to save the 'template' of a  
> report, I still have to specify somewhere: 'CyrilleReport' is  
> composed by this Concern' subclass.
>
> I have the impression that there is two kind of informations we want  
> to keep:
> - the 'template' of the report. Once created, we can apply it on any  
> model we want. From a concern point of view, we want to save its  
> parameters not model-specific: for example label, explanation for  
> any kind of Concern (abel, explanation, containers, elements,  
> property in our example).
> This is what it's done in your solution (and also my current  
> solution).
>
> - the 'result' of a report. we want to keep information relative to  
> each concern's computation/result. That means informations relative  
> to a specific MooseModel. For now nothing is provided to do that. I  
> don't know what could be the more appropriated solution ?
>
> 2010/8/23 Tudor Girba <[hidden email]>
> Hi Cyrille,
>
> Right now, you are instantiating a generic class and then you have  
> objects that you serialize in an array. I suggest to create a  
> subclass of the generic class and save the value of the fields  
> (e.g., label, explanation) as methods of that class.
>
> Like that you could have best of both worlds. As I mentioned before,  
> you could solve it with Magritte, or directly having a specialized  
> editor that edits these fields for you.
>
> Cheers,
> Doru
>
>
> On 23 Aug 2010, at 14:19, Cyrille Delaunay wrote:
>
> Ok, it should be ok for the override.
> But I think I still do not understand how should be saved the  
> concerns :)
> When I finish to build a report, I have a collection of REPConcern's  
> objects. Then I do not see how to save directly those objects as  
> Methods. What should I do with those objects?
>
>
> 2010/8/23 Tudor Girba <[hidden email]>
> Hi Cyrille,
>
> I took a look. As I mentioned in a private email, it is a nice  
> start, but I think it would be nicer to get the saving of concerns  
> towards directly compiling as methods in the concern class.
>
> Now, an important issue: you are still overriding  
> REPConcernSpecification>>open. Please delete this override.
>
> Cheers,
> Doru
>
>
>
> On 20 Aug 2010, at 17:23, Cyrille Delaunay wrote:
>
> Hello,
>  In order to provide a reporting system for pharo, I implemented  
> some tools over arki, build some concerns, work on way to save  
> reports.
> There still work to do, but you can already test it and give me  
> feedback if you want :):
>
> Download the package 'MooseComputedConcerns' at: www.squeaksource.com/MooseDemoReport
> .
> A message will tell you to resolve depencies by first loading  
> 'System-Benchmarks'.
> As the concern about benchmarks is not finished you can choose to  
> 'proceed' (the benchmarkConcern will just not been working).
> Otherwise you can load 'System-Benchmarks' from the same repository  
> (allow 'block argument assignement' in the settings before).
>
> Then you will be able, in the moose panel, to right click on a model  
> and open a arki reporter.
> You can then play a bit with the browser.
>
> pay attencion : load the last version of 'Refactoring-core' to be  
> able to use the LintRules-Concern
> --------------------
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Being happy is a matter of choice."
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "It's not what we do that matters most, it's how we do it."
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev