30 Jun
2014
30 Jun
'14
12:03 p.m.
Orthogonally to the process open dev / release, we have the notion of
two different uses of Configurations.
I call them the Projects vs the Dependencies style.
Let us look at these two uses. I will take an example that is not in
Moose but we can see the exact
same problems in Moose.
There is a parallel with XMLSupport (a group loading XMLparser, writer,
SIXX, Pastell....
and XMLParser, XMLWriter
XMLSupport is a "Project" configuration: it is a convenient way to
group and load (in particular it expresses
dependencies to clients of XML) so the relation is not I load Sixx
because I dependent on it.
More I load it because I want to optionally offer it.
XMLParser is a "Dependencies" configuration: to parse XML we need
OrderedPreservingDictionary, Bitmap...
if we do not load them we cannot get XMLParser working.
Why this difference is important: When you want to build a tool using
the XMLParser you do not want to get SIXX. pastell
when you do not need it.
Based on this analysis we see that
PetitParser project, MooseIDE project are Projects
while
PetitParser (the package), MooseCore (the package) are dependencies
configuration.
Now the problem is that we do not have a simple way to express the
dependencies at the level of a package.
Because when coding the XMLParser package you would write that it
depends on SIXX.
Christophe is working on a prototype to get package dependencies
expressed at the package level
and he will present that at ESUG but this is not ready to use.
Now we could (but this is a lot of work) add a
configuration"Dependencies" to any package. These dependencies would be
really simple. We already have that for Traverser, Merlin, RoelTyper and
many others.
This way we could have
- Project configurations
- Dependencies configurations
Now I would like to see is do we do it? Would be good to have different
names to identify these configurations clearly.
Or at least have a description that clearly say it.
Stef
30 Jun
30 Jun
7:12 p.m.
Doru
I have the impression that there is not one single MooseEngines
configuration and that we will end up in the same
fat configuration. Because may be we want petitParser may be Smacc may
be both or none and just XML.
So
I have one hypothesis: if "dependencies" configuration are handled at
the package level it should be easier to build
as many as we want as "Project" configuration
Now the experience I would like to do is the following:
- create one dependencies configuration for each package (this
configuration should be as small as possible)
- repo
- dependencies to projects
- dependencies to package
- then we define a couple of "useful" project cofniguration One being
moose IDE.
- group such configurations into a MooseMetacelloConfiguration repositories
Stef
1 Jul
1 Jul
9:33 a.m.
Hi Stef,
I did not have enough time to follow in details the conversation. I will
try again in a couple of days, so in the meantime, please take my reply as
a draft :).
I like the distinction between "Project" and "Dependencies". Also, any
Project configuration should be seen as a convenience. In these terms, the
ConfigurationOfMoose has to become a Project configuration.
Every engine we have, except for Moose Core, has its own configuration, and
most of them are pretty much a Project configuration. So, from this point
of view, anyone can easily build his own Project using them.
When I mentioned the MooseEngines configuration, I referred to a Project
configuration to be included in the ConfigurationOfMoose that we support as
a whole. At this moment, this should include the following:
- Roassal2 & co
- MooseAlgos
- PetitParser
- Fame + Metanool
- Glamour
- MooseCore (this does not exist yet)
- XMLReader
The term engine comes from this diagram:
http://www.themoosebook.org/book/introduction/nutshell
Then, we should have a ConfigurationOfFAMIX that includes FAMIX entities +
extensions, importers. I see it as a Dependencies configuration.
Then, we should have ConfigurationOfMooseFinder which includes some basic
tools like the MooseFinder and the MetaBrowser. This is a Dependency
configuration. On top of that we should also have a
ConfigurationOfFAMIXFinder that depends on ConfigurationOfFAMIX and
ConfigurationOfMooseFinder and that includes all the visualizations and the
ui extensions. This will be a bit hairy to do but I think it would be worth
it.
If we move in this direction, the ConfigurationOfMoose will finally become
empty of explicit Monticello packages.
Cheers,
Doru
On Mon, Jun 30, 2014 at 7:12 PM, stepharo <stepharo(a)free.fr> wrote:
Doru
I have the impression that there is not one single MooseEngines
configuration and that we will end up in the same
fat configuration. Because may be we want petitParser may be Smacc may be
both or none and just XML.
So
I have one hypothesis: if "dependencies" configuration are handled at the
package level it should be easier to build
as many as we want as "Project" configuration
Now the experience I would like to do is the following:
- create one dependencies configuration for each package (this
configuration should be as small as possible)
- repo
- dependencies to projects
- dependencies to package
- then we define a couple of "useful" project cofniguration One being
moose IDE.
- group such configurations into a MooseMetacelloConfiguration repositories
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
9:45 a.m.
Hi,
I thought a bit about the terms "Project" and "Dependencies". Given
that it
is likely that these terms will be used in other contexts outside of our
refactoring project, perhaps we could spend a bit of time to tune them.
I think both Project and Dependencies are highly overloaded terms and
because of that it will be easy to create confusion. For example, imagine
this sentence:
"we are working on a project to refactor the dependencies from a project
configuration to make it contain only depencency configurations".
So, I would like to propose another set:
"Project" -> "Assembly"
"Dependencies" -> "Structure/Structural"
With the new terms, this would become:
"we are working on a project to refactor the dependencies from an assembly
configuration to make it contain only structural configurations".
What do you think?
Doru
On Tue, Jul 1, 2014 at 9:33 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Hi Stef,
I did not have enough time to follow in details the conversation. I will
try again in a couple of days, so in the meantime, please take my reply as
a draft :).
I like the distinction between "Project" and "Dependencies". Also,
any
Project configuration should be seen as a convenience. In these terms, the
ConfigurationOfMoose has to become a Project configuration.
Every engine we have, except for Moose Core, has its own configuration,
and most of them are pretty much a Project configuration. So, from this
point of view, anyone can easily build his own Project using them.
When I mentioned the MooseEngines configuration, I referred to a Project
configuration to be included in the ConfigurationOfMoose that we support as
a whole. At this moment, this should include the following:
- Roassal2 & co
- MooseAlgos
- PetitParser
- Fame + Metanool
- Glamour
- MooseCore (this does not exist yet)
- XMLReader
The term engine comes from this diagram:
http://www.themoosebook.org/book/introduction/nutshell
Then, we should have a ConfigurationOfFAMIX that includes FAMIX entities +
extensions, importers. I see it as a Dependencies configuration.
Then, we should have ConfigurationOfMooseFinder which includes some basic
tools like the MooseFinder and the MetaBrowser. This is a Dependency
configuration. On top of that we should also have a
ConfigurationOfFAMIXFinder that depends on ConfigurationOfFAMIX and
ConfigurationOfMooseFinder and that includes all the visualizations and the
ui extensions. This will be a bit hairy to do but I think it would be worth
it.
If we move in this direction, the ConfigurationOfMoose will finally become
empty of explicit Monticello packages.
Cheers,
Doru
On Mon, Jun 30, 2014 at 7:12 PM, stepharo <stepharo(a)free.fr> wrote:
--
www.tudorgirba.com
"Every thing has its own flow"
Doru
I have the impression that there is not one single MooseEngines
configuration and that we will end up in the same
fat configuration. Because may be we want petitParser may be Smacc may be
both or none and just XML.
So
I have one hypothesis: if "dependencies" configuration are handled at
the package level it should be easier to build
as many as we want as "Project" configuration
Now the experience I would like to do is the following:
- create one dependencies configuration for each package (this
configuration should be as small as possible)
- repo
- dependencies to projects
- dependencies to package
- then we define a couple of "useful" project cofniguration One being
moose IDE.
- group such configurations into a MooseMetacelloConfiguration
repositories
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
12:17 p.m.
On 1/7/14 09:45, Tudor Girba wrote:
Hi,
I thought a bit about the terms "Project" and "Dependencies". Given
that it is likely that these terms will be used in other contexts
outside of our refactoring project, perhaps we could spend a bit of
time to tune them.
I think both Project and Dependencies are highly overloaded terms and
because of that it will be easy to create confusion. For example,
imagine this sentence:
"we are working on a project to refactor the dependencies from a
project configuration to make it contain only depencency configurations".
So, I would like to propose another set:
"Project" -> "Assembly"
"Dependencies" -> "Structure/Structural"
With the new terms, this would become:
"we are working on a project to refactor the dependencies from an
assembly configuration to make it contain only structural configurations".
What do you think?
I like dependency because it express the need to work :) but I'm ok for
assembly.
Doru
On Tue, Jul 1, 2014 at 9:33 AM, Tudor Girba <tudor(a)tudorgirba.com
<mailto:tudor@tudorgirba.com>> wrote:
Hi Stef,
I did not have enough time to follow in details the conversation.
I will try again in a couple of days, so in the meantime, please
take my reply as a draft :).
I like the distinction between "Project" and "Dependencies".
Also,
any Project configuration should be seen as a convenience. In
these terms, the ConfigurationOfMoose has to become a Project
configuration.
Every engine we have, except for Moose Core, has its own
configuration, and most of them are pretty much a Project
configuration. So, from this point of view, anyone can easily
build his own Project using them.
When I mentioned the MooseEngines configuration, I referred to a
Project configuration to be included in the ConfigurationOfMoose
that we support as a whole. At this moment, this should include
the following:
- Roassal2 & co
- MooseAlgos
- PetitParser
- Fame + Metanool
- Glamour
- MooseCore (this does not exist yet)
- XMLReader
The term engine comes from this diagram:
http://www.themoosebook.org/book/introduction/nutshell
Then, we should have a ConfigurationOfFAMIX that includes FAMIX
entities + extensions, importers. I see it as a Dependencies
configuration.
Then, we should have ConfigurationOfMooseFinder which includes
some basic tools like the MooseFinder and the MetaBrowser. This is
a Dependency configuration. On top of that we should also have a
ConfigurationOfFAMIXFinder that depends on ConfigurationOfFAMIX
and ConfigurationOfMooseFinder and that includes all the
visualizations and the ui extensions. This will be a bit hairy to
do but I think it would be worth it.
If we move in this direction, the ConfigurationOfMoose will
finally become empty of explicit Monticello packages.
Cheers,
Doru
On Mon, Jun 30, 2014 at 7:12 PM, stepharo <stepharo(a)free.fr
<mailto:stepharo@free.fr>> wrote:
Doru
I have the impression that there is not one single
MooseEngines configuration and that we will end up in the same
fat configuration. Because may be we want petitParser may be
Smacc may be both or none and just XML.
So
I have one hypothesis: if "dependencies" configuration are
handled at the package level it should be easier to build
as many as we want as "Project" configuration
Now the experience I would like to do is the following:
- create one dependencies configuration for each package (this
configuration should be as small as possible)
- repo
- dependencies to projects
- dependencies to package
- then we define a couple of "useful" project cofniguration
One being moose IDE.
- group such configurations into a MooseMetacelloConfiguration
repositories
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
--
www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
1:22 p.m.
Doru
what about Unit and Assembly
Stef
On 1/7/14 12:17, stepharo wrote:
On 1/7/14 09:45, Tudor Girba wrote:
Hi,
I thought a bit about the terms "Project" and "Dependencies". Given
that it is likely that these terms will be used in other contexts
outside of our refactoring project, perhaps we could spend a bit of
time to tune them.
I think both Project and Dependencies are highly overloaded terms and
because of that it will be easy to create confusion. For example,
imagine this sentence:
"we are working on a project to refactor the dependencies from a
project configuration to make it contain only depencency configurations".
So, I would like to propose another set:
"Project" -> "Assembly"
"Dependencies" -> "Structure/Structural"
With the new terms, this would become:
"we are working on a project to refactor the dependencies from an
assembly configuration to make it contain only structural
configurations".
What do you think?
I like dependency because it express the need to work :) but I'm ok
for assembly.
Doru
On Tue, Jul 1, 2014 at 9:33 AM, Tudor Girba <tudor(a)tudorgirba.com
<mailto:tudor@tudorgirba.com>> wrote:
Hi Stef,
I did not have enough time to follow in details the conversation.
I will try again in a couple of days, so in the meantime, please
take my reply as a draft :).
I like the distinction between "Project" and "Dependencies".
Also, any Project configuration should be seen as a
convenience. In these terms, the ConfigurationOfMoose has to
become a Project configuration.
Every engine we have, except for Moose Core, has its own
configuration, and most of them are pretty much a Project
configuration. So, from this point of view, anyone can easily
build his own Project using them.
When I mentioned the MooseEngines configuration, I referred to a
Project configuration to be included in the ConfigurationOfMoose
that we support as a whole. At this moment, this should include
the following:
- Roassal2 & co
- MooseAlgos
- PetitParser
- Fame + Metanool
- Glamour
- MooseCore (this does not exist yet)
- XMLReader
The term engine comes from this diagram:
http://www.themoosebook.org/book/introduction/nutshell
Then, we should have a ConfigurationOfFAMIX that includes FAMIX
entities + extensions, importers. I see it as a Dependencies
configuration.
Then, we should have ConfigurationOfMooseFinder which includes
some basic tools like the MooseFinder and the MetaBrowser. This
is a Dependency configuration. On top of that we should also have
a ConfigurationOfFAMIXFinder that depends on ConfigurationOfFAMIX
and ConfigurationOfMooseFinder and that includes all the
visualizations and the ui extensions. This will be a bit hairy to
do but I think it would be worth it.
If we move in this direction, the ConfigurationOfMoose will
finally become empty of explicit Monticello packages.
Cheers,
Doru
On Mon, Jun 30, 2014 at 7:12 PM, stepharo <stepharo(a)free.fr
<mailto:stepharo@free.fr>> wrote:
Doru
I have the impression that there is not one single
MooseEngines configuration and that we will end up in the same
fat configuration. Because may be we want petitParser may be
Smacc may be both or none and just XML.
So
I have one hypothesis: if "dependencies" configuration are
handled at the package level it should be easier to build
as many as we want as "Project" configuration
Now the experience I would like to do is the following:
- create one dependencies configuration for each package
(this configuration should be as small as possible)
- repo
- dependencies to projects
- dependencies to package
- then we define a couple of "useful" project cofniguration
One being moose IDE.
- group such configurations into a
MooseMetacelloConfiguration repositories
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
--
www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
1:39 p.m.
I like that!
Doru
On Tue, Jul 1, 2014 at 1:22 PM, stepharo <stepharo(a)free.fr> wrote:
Doru
what about Unit and Assembly
Stef
On 1/7/14 12:17, stepharo wrote:
On 1/7/14 09:45, Tudor Girba wrote:
Hi,
I thought a bit about the terms "Project" and "Dependencies". Given
that
it is likely that these terms will be used in other contexts outside of our
refactoring project, perhaps we could spend a bit of time to tune them.
I think both Project and Dependencies are highly overloaded terms and
because of that it will be easy to create confusion. For example, imagine
this sentence:
"we are working on a project to refactor the dependencies from a project
configuration to make it contain only depencency configurations".
So, I would like to propose another set:
"Project" -> "Assembly"
"Dependencies" -> "Structure/Structural"
With the new terms, this would become:
"we are working on a project to refactor the dependencies from an
assembly configuration to make it contain only structural configurations".
What do you think?
I like dependency because it express the need to work :) but I'm ok for
assembly.
Doru
On Tue, Jul 1, 2014 at 9:33 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
--
www.tudorgirba.com
"Every thing has its own flow"
Hi Stef,
I did not have enough time to follow in details the conversation. I
will try again in a couple of days, so in the meantime, please take my
reply as a draft :).
I like the distinction between "Project" and "Dependencies". Also,
any
Project configuration should be seen as a convenience. In these terms, the
ConfigurationOfMoose has to become a Project configuration.
Every engine we have, except for Moose Core, has its own configuration,
and most of them are pretty much a Project configuration. So, from this
point of view, anyone can easily build his own Project using them.
When I mentioned the MooseEngines configuration, I referred to a
Project configuration to be included in the ConfigurationOfMoose that we
support as a whole. At this moment, this should include the following:
- Roassal2 & co
- MooseAlgos
- PetitParser
- Fame + Metanool
- Glamour
- MooseCore (this does not exist yet)
- XMLReader
The term engine comes from this diagram:
http://www.themoosebook.org/book/introduction/nutshell
Then, we should have a ConfigurationOfFAMIX that includes FAMIX
entities + extensions, importers. I see it as a Dependencies configuration.
Then, we should have ConfigurationOfMooseFinder which includes some
basic tools like the MooseFinder and the MetaBrowser. This is a Dependency
configuration. On top of that we should also have a
ConfigurationOfFAMIXFinder that depends on ConfigurationOfFAMIX and
ConfigurationOfMooseFinder and that includes all the visualizations and the
ui extensions. This will be a bit hairy to do but I think it would be worth
it.
If we move in this direction, the ConfigurationOfMoose will finally
become empty of explicit Monticello packages.
Cheers,
Doru
On Mon, Jun 30, 2014 at 7:12 PM, stepharo <stepharo(a)free.fr> wrote:
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing
listMoose-dev@iam.unibe.chhttps://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing
listMoose-dev@iam.unibe.chhttps://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Doru
I have the impression that there is not one single MooseEngines
configuration and that we will end up in the same
fat configuration. Because may be we want petitParser may be Smacc may
be both or none and just XML.
So
I have one hypothesis: if "dependencies" configuration are handled at
the package level it should be easier to build
as many as we want as "Project" configuration
Now the experience I would like to do is the following:
- create one dependencies configuration for each package (this
configuration should be as small as possible)
- repo
- dependencies to projects
- dependencies to package
- then we define a couple of "useful" project cofniguration One being
moose IDE.
- group such configurations into a MooseMetacelloConfiguration
repositories
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
12:14 p.m.
Ok we are in sync.
I should find a way to automatically create the configuration I want and
populate the MooseMetacelloConfigurationRepositories.
Stef
On 1/7/14 09:33, Tudor Girba wrote:
Hi Stef,
I did not have enough time to follow in details the conversation. I
will try again in a couple of days, so in the meantime, please take my
reply as a draft :).
I like the distinction between "Project" and "Dependencies". Also,
any
Project configuration should be seen as a convenience. In these terms,
the ConfigurationOfMoose has to become a Project configuration.
Every engine we have, except for Moose Core, has its own
configuration, and most of them are pretty much a Project
configuration. So, from this point of view, anyone can easily build
his own Project using them.
When I mentioned the MooseEngines configuration, I referred to a
Project configuration to be included in the ConfigurationOfMoose that
we support as a whole. At this moment, this should include the following:
- Roassal2 & co
- MooseAlgos
- PetitParser
- Fame + Metanool
- Glamour
- MooseCore (this does not exist yet)
- XMLReader
The term engine comes from this diagram:
http://www.themoosebook.org/book/introduction/nutshell
Then, we should have a ConfigurationOfFAMIX that includes FAMIX
entities + extensions, importers. I see it as a Dependencies
configuration.
Then, we should have ConfigurationOfMooseFinder which includes some
basic tools like the MooseFinder and the MetaBrowser. This is a
Dependency configuration. On top of that we should also have a
ConfigurationOfFAMIXFinder that depends on ConfigurationOfFAMIX and
ConfigurationOfMooseFinder and that includes all the visualizations
and the ui extensions. This will be a bit hairy to do but I think it
would be worth it.
If we move in this direction, the ConfigurationOfMoose will finally
become empty of explicit Monticello packages.
Cheers,
Doru
On Mon, Jun 30, 2014 at 7:12 PM, stepharo <stepharo(a)free.fr
<mailto:stepharo@free.fr>> wrote:
Doru
I have the impression that there is not one single MooseEngines
configuration and that we will end up in the same
fat configuration. Because may be we want petitParser may be Smacc
may be both or none and just XML.
So
I have one hypothesis: if "dependencies" configuration are
handled at the package level it should be easier to build
as many as we want as "Project" configuration
Now the experience I would like to do is the following:
- create one dependencies configuration for each package (this
configuration should be as small as possible)
- repo
- dependencies to projects
- dependencies to package
- then we define a couple of "useful" project cofniguration One
being moose IDE.
- group such configurations into a MooseMetacelloConfiguration
repositories
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
2 Jul
2 Jul
11:06 a.m.
Stefan
I know about groups :) pretty well in fact. I did not put my name on the
metacello chapter. I wrote it.
Now the point is that groups influenced people to provide Assembly
configuration with many possible
uses and in reality this is difficult to propose solutions that work for
everybody.
So the idea behind distinguishing between Units and Assembly is that
- all Unit should express THEIR and only THEIR dependencies and
not potential usage loading unrelated tools (Ex Moose Algos in Moose)
- based on well described Units, we can build after Assembly
configuration covering common practices but also specific one.
This is like that in linux you have packages (units) and virtual package
(assembly).
I think that doru and me are on the exact same wave length. I will sit
with christophe this afternoon to see how we can
script the generation of Units based on some of our current ASSEMBLY.
Stef
11:25 a.m.
I agree.
Just a piece of brainstorming for the tooling part: probably the Unit and
the Assembly have different requirements for the kinds of actions a user
want to perform on them.
So, we might need to consider introducing a stronger distinction between
them.
Doru
On Wed, Jul 2, 2014 at 11:06 AM, stepharo <stepharo(a)free.fr> wrote:
Stefan
I know about groups :) pretty well in fact. I did not put my name on the
metacello chapter. I wrote it.
Now the point is that groups influenced people to provide Assembly
configuration with many possible
uses and in reality this is difficult to propose solutions that work for
everybody.
So the idea behind distinguishing between Units and Assembly is that
- all Unit should express THEIR and only THEIR dependencies and not
potential usage loading unrelated tools (Ex Moose Algos in Moose)
- based on well described Units, we can build after Assembly
configuration covering common practices but also specific one.
This is like that in linux you have packages (units) and virtual package
(assembly).
I think that doru and me are on the exact same wave length. I will sit
with christophe this afternoon to see how we can
script the generation of Units based on some of our current ASSEMBLY.
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
4014
days inactive
4016
days old
10 comments
3 participants
participants (3)
-
Ben Coman -
stepharo -
Tudor Girba