Yes Houtan, I think it would also make sense for the reporting because it could be used in other projects/places. I have done the move this week for dates and dseries classes (and m-unit-tests since I need to test these classes without Dynare) because I need them to write a gpm-x model generator (also I understood that Michel may need them for other projects). But, unless someone needs to have reporting (without Dynare), it’s not a priority.
Best, Stéphane.
Le 29 nov. 2014 à 15:31, Houtan houtan@dynare.org a écrit :
Tu veux que je fasse le même pour reporting?
Houtan
On 11/29/2014 02:48 PM, Stéphane Adjemian wrote:
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 mailto: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 mailto:git@github.com:DynareTeam/dates.git
and
git@github.com:DynareTeam/dseries.git mailto: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 mailto:Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev https://www.dynare.org/cgi-bin/mailman/listinfo/dev
-- Michel Juillard _______________________________________________ Dev mailing list Dev@dynare.org mailto:Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev https://www.dynare.org/cgi-bin/mailman/listinfo/dev
Dev mailing list Dev@dynare.org mailto:Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev https://www.dynare.org/cgi-bin/mailman/listinfo/dev