Hi,
This week I started to reorganize part of the codes by replacing some folders by git submodules. The idea is that part of the codes in Dynare may be used for other projects (without putting all Dynare’s routines in the path). For these parts of Dynare it makes more sense to create separate git repositories and to include these as submodules in Dynare. Also this will force to think more about the organization of the routines (which is currently a mess).
In master I already moved the codes related to unit tests (formerly under matlab/utilities/tests) and the dates class (matlab/@dates and matlab/utilities/dates subfolders). I am about to do the same with the dseries class (matlab/@dseries and matlab/utilities/dseries subfolders).
After your next pull from master you will need to do:
~$ git submodule init ~$ git submodule update
Otherwise codes using dseries and/or dates will fail. These submodules points to branches called old-oop-style in:
git@github.com:DynareTeam/dates.git
and
git@github.com:DynareTeam/dseries.git
In these repositories, the master branches will be used to rewrite the codes using the new syntax for classes (which is not compatible with the current version, 3.8, of Octave, but will be compatible with Octave 4.2). Another consequence is that if you need to fix a bug in dates or dseries classes you will need to send PR or push patches to DynareTeam/dates.git and DynareTeam/dseries.git (old-oop-style branch) and to update the submodule(s) in DynareTeam/dynare.git (so that they point to the HEAD of old-oop-style branches).
I have done the same with the particle folder (codes for the non linear filters) but this will stay in a separate branch (called rewrite-nonlinear-filters) for a while because Fred and I are rewriting these codes so that the non linear filters can be used with any reduced form model (not only the solution of the second order approximation) and this will take a couple of months.
Best, Stéphane.
Stéphane Adjemian Université du Maine, Gains
Thanks Stéphane. This is great. You should add a news on the Dynare web site and the forum. In the same spirit, we may want to split the manual and the Dynare Help forum for @dates and @dseries, giving them their full status of separate products.
Best
Michel
Stéphane Adjemian writes:
Hi,
This week I started to reorganize part of the codes by replacing some folders by git submodules. The idea is that part of the codes in Dynare may be used for other projects (without putting all Dynare’s routines in the path). For these parts of Dynare it makes more sense to create separate git repositories and to include these as submodules in Dynare. Also this will force to think more about the organization of the routines (which is currently a mess).
In master I already moved the codes related to unit tests (formerly under matlab/utilities/tests) and the dates class (matlab/@dates and matlab/utilities/dates subfolders). I am about to do the same with the dseries class (matlab/@dseries and matlab/utilities/dseries subfolders).
After your next pull from master you will need to do:
~$ git submodule init ~$ git submodule update
Otherwise codes using dseries and/or dates will fail. These submodules points to branches called old-oop-style in:
git@github.com:DynareTeam/dates.git
and
git@github.com:DynareTeam/dseries.git
In these repositories, the master branches will be used to rewrite the codes using the new syntax for classes (which is not compatible with the current version, 3.8, of Octave, but will be compatible with Octave 4.2). Another consequence is that if you need to fix a bug in dates or dseries classes you will need to send PR or push patches to DynareTeam/dates.git and DynareTeam/dseries.git (old-oop-style branch) and to update the submodule(s) in DynareTeam/dynare.git (so that they point to the HEAD of old-oop-style branches).
I have done the same with the particle folder (codes for the non linear filters) but this will stay in a separate branch (called rewrite-nonlinear-filters) for a while because Fred and I are rewriting these codes so that the non linear filters can be used with any reduced form model (not only the solution of the second order approximation) and this will take a couple of months.
Best, Stéphane.
Stéphane Adjemian Université du Maine, Gains
Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
Yes we can do that… But before I would prefer to add a manual reference for each submodule and (maybe) rewrite the master branch with the new class interface (or at least start).
For the documentation there are still pending issues to be discussed/worked. I started the documentation of the submodule m-unit-tests (which is used in Dynare to perform the unitary tests). The documentation is under the doc subfolder and is written with the Sphinx tool (Python) and rest markup language. The result is nice and the source of the documentation is far easier to read (and write) than the Dynare reference manual (which uses texinfo). I also started to rewrite the Dynare reference manual using the same technology in a separate branch but it’s a lot of work...
The docs for the submodules will be available in subfolders of dynare/matlab (which is not consistent with the current design of Dynare). Obviously, when preparing a release we can build the docs in dynare/doc and remove the sources from the dynare/matlab directory. Also if we rewrite the Dynare reference manual with Sphinx, we can easily include the docs for the submodules.
Best, Stéphane.
Stéphane Adjemian Université du Maine, Gains & Dynare Team
Le 29 nov. 2014 à 09:30, Michel Juillard michel.juillard@mjui.fr a écrit :
Thanks Stéphane. This is great. You should add a news on the Dynare web site and the forum. In the same spirit, we may want to split the manual and the Dynare Help forum for @dates and @dseries, giving them their full status of separate products.
Best
Michel
Stéphane Adjemian writes:
Hi,
This week I started to reorganize part of the codes by replacing some folders by git submodules. The idea is that part of the codes in Dynare may be used for other projects (without putting all Dynare’s routines in the path). For these parts of Dynare it makes more sense to create separate git repositories and to include these as submodules in Dynare. Also this will force to think more about the organization of the routines (which is currently a mess).
In master I already moved the codes related to unit tests (formerly under matlab/utilities/tests) and the dates class (matlab/@dates and matlab/utilities/dates subfolders). I am about to do the same with the dseries class (matlab/@dseries and matlab/utilities/dseries subfolders).
After your next pull from master you will need to do:
~$ git submodule init ~$ git submodule update
Otherwise codes using dseries and/or dates will fail. These submodules points to branches called old-oop-style in:
git@github.com:DynareTeam/dates.git
and
git@github.com:DynareTeam/dseries.git
In these repositories, the master branches will be used to rewrite the codes using the new syntax for classes (which is not compatible with the current version, 3.8, of Octave, but will be compatible with Octave 4.2). Another consequence is that if you need to fix a bug in dates or dseries classes you will need to send PR or push patches to DynareTeam/dates.git and DynareTeam/dseries.git (old-oop-style branch) and to update the submodule(s) in DynareTeam/dynare.git (so that they point to the HEAD of old-oop-style branches).
I have done the same with the particle folder (codes for the non linear filters) but this will stay in a separate branch (called rewrite-nonlinear-filters) for a while because Fred and I are rewriting these codes so that the non linear filters can be used with any reduced form model (not only the solution of the second order approximation) and this will take a couple of months.
Best, Stéphane.
Stéphane Adjemian Université du Maine, Gains
Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
-- Michel Juillard _______________________________________________ Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
I have looked at the HTML version of unitary tests documentation: it is stunning. I agree that we should convert the current dynare.texi to that format. It will only be done if we share the work. Everybody in the team should convert a couple of chapters. We need first some guidelines concerning the style.
In the unitary tests documentation, I see that Contents: is empty. Is there some automatic tools to fill the Contents: block of chapteres and sections?
It is useful to read README.md to find out how to build sphinx. It took me a little time to find the dependencies and see that sphinxcontrib-matlabdomain that is not in Debian and to realize that it doesn't work in python3
Best
Michel
Stéphane Adjemian writes:
Yes we can do that… But before I would prefer to add a manual reference for each submodule and (maybe) rewrite the master branch with the new class interface (or at least start).
For the documentation there are still pending issues to be discussed/worked. I started the documentation of the submodule m-unit-tests (which is used in Dynare to perform the unitary tests). The documentation is under the doc subfolder and is written with the Sphinx tool (Python) and rest markup language. The result is nice and the source of the documentation is far easier to read (and write) than the Dynare reference manual (which uses texinfo). I also started to rewrite the Dynare reference manual using the same technology in a separate branch but it’s a lot of work...
The docs for the submodules will be available in subfolders of dynare/matlab (which is not consistent with the current design of Dynare). Obviously, when preparing a release we can build the docs in dynare/doc and remove the sources from the dynare/matlab directory. Also if we rewrite the Dynare reference manual with Sphinx, we can easily include the docs for the submodules.
Best, Stéphane.
Stéphane Adjemian Université du Maine, Gains & Dynare Team
Le 29 nov. 2014 à 09:30, Michel Juillard michel.juillard@mjui.fr a écrit :
Thanks Stéphane. This is great. You should add a news on the Dynare web site and the forum. In the same spirit, we may want to split the manual and the Dynare Help forum for @dates and @dseries, giving them their full status of separate products.
Best
Michel
Stéphane Adjemian writes:
Hi,
This week I started to reorganize part of the codes by replacing some folders by git submodules. The idea is that part of the codes in Dynare may be used for other projects (without putting all Dynare’s routines in the path). For these parts of Dynare it makes more sense to create separate git repositories and to include these as submodules in Dynare. Also this will force to think more about the organization of the routines (which is currently a mess).
In master I already moved the codes related to unit tests (formerly under matlab/utilities/tests) and the dates class (matlab/@dates and matlab/utilities/dates subfolders). I am about to do the same with the dseries class (matlab/@dseries and matlab/utilities/dseries subfolders).
After your next pull from master you will need to do:
~$ git submodule init ~$ git submodule update
Otherwise codes using dseries and/or dates will fail. These submodules points to branches called old-oop-style in:
git@github.com:DynareTeam/dates.git
and
git@github.com:DynareTeam/dseries.git
In these repositories, the master branches will be used to rewrite the codes using the new syntax for classes (which is not compatible with the current version, 3.8, of Octave, but will be compatible with Octave 4.2). Another consequence is that if you need to fix a bug in dates or dseries classes you will need to send PR or push patches to DynareTeam/dates.git and DynareTeam/dseries.git (old-oop-style branch) and to update the submodule(s) in DynareTeam/dynare.git (so that they point to the HEAD of old-oop-style branches).
I have done the same with the particle folder (codes for the non linear filters) but this will stay in a separate branch (called rewrite-nonlinear-filters) for a while because Fred and I are rewriting these codes so that the non linear filters can be used with any reduced form model (not only the solution of the second order approximation) and this will take a couple of months.
Best, Stéphane.
Stéphane Adjemian Université du Maine, Gains
Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
-- Michel Juillard _______________________________________________ Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
Michel,
I have just pushed the branch where I started a tentative sphinx version of the doc on github (sphinx-doc-experimental). Also to see the result I pushed the generated html files here
dynare.ithaca.fr/dynare-manual http://dynare.ithaca.fr/dynare-manual
If you want to read the generated html files locally (on your computer) you should apache and configure apache2 (otherwise you will be missing some nice features like the search function).
I wrote the introduction and the Installation and configuration chapter. I also wrote the outline for the other chapters and sections. I did not touch this since at least a month… The branch is up to date w.r.t master. We need to agree on the style and maybe write some python code to adjust the style. For instance, in the current manual, I think that there is a clear distinction between dynare commands and matlab/function…
Once we agree on the style (and modify the default style to our needs) it is not that hard to do the translation. For the first chapters, if I remember correctly, I used pandoc to convert the html pages into rst.
Best, Stéphane.
-
Michel Juillard -
Stéphane Adjemian