reporting system for pharo

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

reporting system for pharo

cdelaunay
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
Reply | Threaded
Open this post in threaded view
|

Re: reporting system for pharo

Tudor Girba
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
Reply | Threaded
Open this post in threaded view
|

Re: reporting system for pharo

cdelaunay
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
Reply | Threaded
Open this post in threaded view
|

Re: reporting system for pharo

Tudor Girba
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
Reply | Threaded
Open this post in threaded view
|

Re: reporting system for pharo

cdelaunay
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
Reply | Threaded
Open this post in threaded view
|

Re: reporting system for pharo

cdelaunay
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
Reply | Threaded
Open this post in threaded view
|

Re: reporting system for pharo

cdelaunay
 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
Reply | Threaded
Open this post in threaded view
|

Re: reporting system for pharo

Tudor Girba
Hi,

Actually not necessarily.

There are at least two distinct classes of concerns:
1. Those for which we can say what is bad and what is ok. These are  
like Lint rules, and have a status that can be either: Success or  
Failure.
2. Those that mainly document the system. When you use the  
Distribution Map as documentation, that concern will fall in this  
category and will have a Neutral status.

Cheers,
Doru


On 25 Aug 2010, at 17:36, Cyrille Delaunay wrote:

>  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

--
www.tudorgirba.com

"Live like you mean it."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev