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