dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2013-02-21T15:05:27Zhttps://git.dynare.org/Dynare/dynare/-/issues/118Build system for SWZ DLL fails under Cygwin2013-02-21T15:05:27ZSébastien VillemotBuild system for SWZ DLL fails under CygwinThe problem comes from the GSL: the package shipped with Cygwin does not link with MATLAB DLLs, which are compiled with MinGW even under Cygwin.
The solution is probably to use a GSL compiled for MinGW:
http://gnuwin32.sourceforge.net/p...The problem comes from the GSL: the package shipped with Cygwin does not link with MATLAB DLLs, which are compiled with MinGW even under Cygwin.
The solution is probably to use a GSL compiled for MinGW:
http://gnuwin32.sourceforge.net/packages/gsl.htm
4.2https://git.dynare.org/Dynare/dynare/-/issues/145when cross-compiling, the host prefix is not added to "ar"2013-02-21T15:03:32ZSébastien Villemotwhen cross-compiling, the host prefix is not added to "ar"When building a static library (as in preprocessor/macro), the build system will always use "ar" (instead of "i686-w64-mingw32-ar" for example).
In most cases this is not a problem.
The problem can happen if one has only the cross-comp...When building a static library (as in preprocessor/macro), the build system will always use "ar" (instead of "i686-w64-mingw32-ar" for example).
In most cases this is not a problem.
The problem can happen if one has only the cross-compiling binutils, but not the native binutils, as for example in a Cygwin install where only the packages listed on the wiki page are installed.
4.2https://git.dynare.org/Dynare/dynare/-/issues/154Change build process to make libslicot optional on Mac OS X2013-02-21T15:03:06ZSébastien VillemotChange build process to make libslicot optional on Mac OS XXCode doesn't provide a Fortran compiler so Mac users will either have to find one precompiled or compile it on their own. Hence, libslicot should be optional in the build process.
XCode doesn't provide a Fortran compiler so Mac users will either have to find one precompiled or compile it on their own. Hence, libslicot should be optional in the build process.
4.2https://git.dynare.org/Dynare/dynare/-/issues/180Adapt the testsuite for MATLAB2013-02-21T15:00:42ZSébastien VillemotAdapt the testsuite for MATLABIn particular this will help verifying that all functionalities work with old MATLAB versions.
In particular this will help verifying that all functionalities work with old MATLAB versions.
https://git.dynare.org/Dynare/dynare/-/issues/210block_bytecode test files: the tests should not report an error if Matlab's o...2013-02-21T15:00:01ZSébastien Villemotblock_bytecode test files: the tests should not report an error if Matlab's optimization toolbox is not availableOne can test for exist('fsolve') in run_test_matlab.m (fsolve is available under Octave)
One can test for exist('fsolve') in run_test_matlab.m (fsolve is available under Octave)
https://git.dynare.org/Dynare/dynare/-/issues/235passing MEXEXT to compile MEX files2013-02-21T14:59:20ZSébastien Villemotpassing MEXEXT to compile MEX filesIn Matlab, the extension name of the MEX file varies accross plateform. When we use USE_DLL and call the model file DLL in another DLL (it is the case for estimation, for example) we need to know this extension.
Currently, the Matlab cal...In Matlab, the extension name of the MEX file varies accross plateform. When we use USE_DLL and call the model file DLL in another DLL (it is the case for estimation, for example) we need to know this extension.
Currently, the Matlab calling program use mexext() to get a string and passes this string to the, say, estimation DLL. This is very roundabout, because mexext() makes a system call to evaluate a batch file to learn the name of the MEX extension of a given system.
I would prefer to know the extension name at the time of compilation of the DLL and hard code it in the DLL.
Currently, the build system already puts the extension name in environment variable MEXEXT. I suggest the following modification to the Makefile:
from
MATLAB_DEFS = -D_GNU_SOURCE -DNDEBUG -DMATLAB_VERSION=0x0713
to
MATLAB_DEFS = -DMEXEXT=$MEXEXT -D_GNU_SOURCE -DNDEBUG -DMATLAB_VERSION=0x0713
Then, we can just use macrovariable MEXEXT in the C++ code when necessary.
The same can be used for OCTAVE but I expect the name of the extension to be always the same.
4.3https://git.dynare.org/Dynare/dynare/-/issues/230Parallelize the testsuite2013-02-21T14:59:20ZSébastien VillemotParallelize the testsuiteCurrently the testsuite only uses one processor.
We should paralellize it, probably using the -j option of make.
Some tests have to be run in sequential order (the 2nd test depends on the result of the 1st): those should probably lie i...Currently the testsuite only uses one processor.
We should paralellize it, probably using the -j option of make.
Some tests have to be run in sequential order (the 2nd test depends on the result of the 1st): those should probably lie in a separate list of tests which will not be (fully) parallelized.
Need to think about a way to aggregate the tests results into one report.
https://git.dynare.org/Dynare/dynare/-/issues/264add checksum to download section of web site2013-02-21T14:55:30ZSébastien Villemotadd checksum to download section of web sitehttps://git.dynare.org/Dynare/dynare/-/issues/289make -j doesn't work in clean work directory2013-02-21T14:54:09ZSébastien Villemotmake -j doesn't work in clean work directoryfor make -j to work for dynare++, it is necessary to check that the code files and headers are ctangle BEFORE being used in compilation
for make -j to work for dynare++, it is necessary to check that the code files and headers are ctangle BEFORE being used in compilation
https://git.dynare.org/Dynare/dynare/-/issues/279add --with-slicot and --with-matio options to configure2013-02-21T14:54:08ZSébastien Villemotadd --with-slicot and --with-matio options to configureAdd m4/ax_slicot.m4 and m4/ax_matio.m4 to conform with --with-gsl.
Add m4/ax_slicot.m4 and m4/ax_matio.m4 to conform with --with-gsl.
https://git.dynare.org/Dynare/dynare/-/issues/277mex problem with Matlab 7.1 under Windows XP2013-02-21T14:54:08ZSébastien Villemotmex problem with Matlab 7.1 under Windows XPI have received the following error message
??? Invalid MEX-file 'C:\JIJI\Dynare\4.3.0\matlab..\mex\matlab\win32-7.1-7.4\mjdgges.mexw32': La procédure spécifiée est introuvable.
Windows XP
Matlab 7.1
the same problem exists with Dynare...I have received the following error message
??? Invalid MEX-file 'C:\JIJI\Dynare\4.3.0\matlab..\mex\matlab\win32-7.1-7.4\mjdgges.mexw32': La procédure spécifiée est introuvable.
Windows XP
Matlab 7.1
the same problem exists with Dynare unstable. Dynare version 4.2.4 used to work