dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2019-06-19T15:37:42Zhttps://git.dynare.org/Dynare/dynare/-/issues/1500Remove `tests/practicing` from repository2019-06-19T15:37:42ZHoutan BastaniRemove `tests/practicing` from repositoryFollowing https://github.com/DynareTeam/dynare/issues/637#issuecomment-234199900, we should remove `tests/practicing` from the repository.
We can:
1) simply delete it
1) compress the files and serve them on www.dynare.org somewhere
...Following https://github.com/DynareTeam/dynare/issues/637#issuecomment-234199900, we should remove `tests/practicing` from the repository.
We can:
1) simply delete it
1) compress the files and serve them on www.dynare.org somewhere
What do people prefer?4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1483if Dynare++ will not be built, do not build mex files that depend on it2019-08-14T12:33:08ZHoutan Bastaniif Dynare++ will not be built, do not build mex files that depend on it`mex/build/matlab/configure.ac` does not account for the case when makefiles are not created for dynare++ by the main configure script. Hence, `libdynare++` and `gensylv` will still be built, causing an error. See #1482.
Easy solution...`mex/build/matlab/configure.ac` does not account for the case when makefiles are not created for dynare++ by the main configure script. Hence, `libdynare++` and `gensylv` will still be built, causing an error. See #1482.
Easy solution: test for BLAS, LAPACK, and MatIO. don't build `libdynare++`, `gensylv`, `k_order_perturbation`, or `dynare_simul_` if one of these libraries is not found (same test that we implement for building Dynare++ in the main config file.
Another solution would be to pass the value of `BUILD_DYNAREPLUSPLUS` to `AC_CONFIG_SUBDIRS([mex/build/matlab])` in `configure.ac`4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1810macOS: solve installation problems2021-09-01T13:44:39ZJohannes PfeifermacOS: solve installation problemsSee https://forum.dynare.org/t/installation-failure-with-dynare-4-6-4/18563/18
and
https://github.com/Homebrew/discussions/discussions/1990#discussioncomment-1190489See https://forum.dynare.org/t/installation-failure-with-dynare-4-6-4/18563/18
and
https://github.com/Homebrew/discussions/discussions/1990#discussioncomment-11904895.xhttps://git.dynare.org/Dynare/dynare/-/issues/1807Manual: fix broken references2021-09-20T16:34:02ZJohannes PfeiferManual: fix broken referencesThe manual contains a bunch of broken internal references that seems to occur when referencing something that does not have a natural anchor. For example
```
.. _quote-note:
.. note::
Note on Quotes
```
and
```
...The manual contains a bunch of broken internal references that seems to occur when referencing something that does not have a natural anchor. For example
```
.. _quote-note:
.. note::
Note on Quotes
```
and
```
.. _VarianceDecomposition:
``VarianceDecomposition``
Decomposition of variance (unconditional variance, i.e. at
horizon infinity). [#f5]_
``VarianceDecompositionME``
Same as `VarianceDecomposition`_, but contains
```
do not work5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1803Investigate reasons for incomplete source package distributed via Webpage2021-09-02T16:29:04ZJohannes PfeiferInvestigate reasons for incomplete source package distributed via WebpageSee https://forum.dynare.org/t/dynare-make-check-failed-tests/18600/5
This problem seems to affect only 4.6.4, i.e. may be superseded with the release of 4.7See https://forum.dynare.org/t/dynare-make-check-failed-tests/18600/5
This problem seems to affect only 4.6.4, i.e. may be superseded with the release of 4.75.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1779Fix detection of Command Line Tools in macOS installer2021-06-28T19:04:06ZSébastien VillemotFix detection of Command Line Tools in macOS installerIn some circumstances (to be determined), the Dynare installer thinks that CLT are installed, while they are not. The typical error message in this case (in `install.log`) is that `git` is not in the path.
Some instances of this:
- http...In some circumstances (to be determined), the Dynare installer thinks that CLT are installed, while they are not. The typical error message in this case (in `install.log`) is that `git` is not in the path.
Some instances of this:
- https://forum.dynare.org/t/i-can-t-download-dynare-4-6-3-in-macos/17296/
- https://forum.dynare.org/t/error-while-installing-dynare-4-6-3-mac-os-big-sur/17131/
- https://forum.dynare.org/t/problem-installing-4-6-0-on-macos-catalina/15247/20 (second poster)
- https://forum.dynare.org/t/installation-problems-of-4-6-0-on-macos/15345/20 (second poster)5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1759Decide whether to drop Windows 7 support2021-11-16T16:29:57ZSébastien VillemotDecide whether to drop Windows 7 supportCurrently, we officially support three versions of Windows: 7, 8.1 and 10.
Mainstream support for Windows 7 expired on 2015, and extended support expired on January 2020.
Until January 2023, Microsoft still provides so-called “Extended...Currently, we officially support three versions of Windows: 7, 8.1 and 10.
Mainstream support for Windows 7 expired on 2015, and extended support expired on January 2020.
Until January 2023, Microsoft still provides so-called “Extended Security Updates”, but this requires a paid subscription (which is probably quite expensive, and thus only accessible to large institutions).
The decision to drop official Dynare support for Windows 7 therefore mostly depends on whether our institutional users have already moved away from Windows 7, or are still postponing the inevitable upgrade.
Note that dropping support for Windows 7 does not mean that Dynare would stop working on that platform (at least until we introduce some breaking change). It simply means that there would be no testing and no guarantee of functionality on that platform.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1728Improvements to make install rule2021-01-19T09:49:57ZSébastien VillemotImprovements to make install ruleCurrently the preprocessor is installed at two places: `${prefix}/lib/dynare/matlab/preprocessorNN/` and `${prefix}/bin`. The former should probably be made a symlink to the latter.
By the way, we could rename the preprocessor binary to...Currently the preprocessor is installed at two places: `${prefix}/lib/dynare/matlab/preprocessorNN/` and `${prefix}/bin`. The former should probably be made a symlink to the latter.
By the way, we could rename the preprocessor binary to a better name.
Moreover, docs should be installed under `${prefix}/share/doc/dynare/`.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1670Mac Package: see if we can use Homebrew `binutils` package to provide `as` an...2020-10-20T13:02:00ZHoutan BastaniMac Package: see if we can use Homebrew `binutils` package to provide `as` and `ld` and thus not install CLTThe idea is that if we can use Homebrew to provide `as` and `ld` then we can avoid installing Command Line Tools. I am not hopeful because `install_name_tool`, which is used to rename library paths when installing to a non-default direct...The idea is that if we can use Homebrew to provide `as` and `ld` then we can avoid installing Command Line Tools. I am not hopeful because `install_name_tool`, which is used to rename library paths when installing to a non-default directory is installed via Command Line Tools. The thing to check is whether this is used only when installing to non-default directories or whether it is always used. If it is always used, then CLT must not be required (though, it is located in `/Library/Developer/CommandLineTools/usr/bin/install_name_tool`)5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1790MacOS installer auto uninstalls old Dynare version2023-10-12T18:37:03ZWilli Mutschlerwilli@mutschler.euMacOS installer auto uninstalls old Dynare versionThe 4.6.* installer auto-uninstalls any 4.5.* versions on MacOS, I can replicate the issue a user had on the [forum](https://forum.dynare.org/t/how-to-coexist-two-version-of-dynare/18151/8)
Can we make this optional with a checkbox?The 4.6.* installer auto-uninstalls any 4.5.* versions on MacOS, I can replicate the issue a user had on the [forum](https://forum.dynare.org/t/how-to-coexist-two-version-of-dynare/18151/8)
Can we make this optional with a checkbox?6.xhttps://git.dynare.org/Dynare/dynare/-/issues/1774Manually verify analytic derivatives before major relases2024-01-17T13:47:43ZJohannes PfeiferManually verify analytic derivatives before major relasesUsing `optim = ('DerivativeCheck', 'on','FiniteDifferenceType','central')`
allows checking the correctness of analytic Jacobians for `analytic_derivatives/fs2000_analytic_derivation.mod` and `method_of_moments\RBC\RBC_MoM_GMM_gradient_op...Using `optim = ('DerivativeCheck', 'on','FiniteDifferenceType','central')`
allows checking the correctness of analytic Jacobians for `analytic_derivatives/fs2000_analytic_derivation.mod` and `method_of_moments\RBC\RBC_MoM_GMM_gradient_optim.mod`. These tests would fail as Matlab does not allow setting the tolerance lower than the default 1e-6, while we are at 1e-5. But we should nevertheless manually check whether we are within a reasonable tolerance.7.xhttps://git.dynare.org/Dynare/dynare/-/issues/1183Fix compatibility with matlab 2016a in installer and mex-folder2019-06-19T15:37:51ZStéphane Adjemianstepan@adjemian.euFix compatibility with matlab 2016a in installer and mex-folderI had to revert commit 6072aa0b462484da990ffa00ee39fb141fa9513f (which is PR #1144 by @JohannesPfeifer) because the snapshot build failed this evening. The generated mex files are not saved in the expected directory. They are saved in `m...I had to revert commit 6072aa0b462484da990ffa00ee39fb141fa9513f (which is PR #1144 by @JohannesPfeifer) because the snapshot build failed this evening. The generated mex files are not saved in the expected directory. They are saved in `mex/matlab/win64-7.8-8.6` instead of `mex/matlab/win64-7.8-9.0`. I did not find where the name of this directory is controlled. @houtanb can you fix this?
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1179Fix cross-compilation of Dynare++ for Windows2019-06-19T15:37:51ZJohannes PfeiferFix cross-compilation of Dynare++ for WindowsWith the unstable version under Windows 10 I get an error that `libquadmath-0.dll` is missing, while Dynare 4.4.3 still works.
With the unstable version under Windows 10 I get an error that `libquadmath-0.dll` is missing, while Dynare 4.4.3 still works.
4.5Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1121Fix compilation flags in the build system2019-06-19T15:37:52ZStéphane Adjemianstepan@adjemian.euFix compilation flags in the build systemCompilation flags (`CFLAGS` and `CXXFLAGS`) specified with the `configure` script are not passed correctly when building the mex files (the preprocessor and dynare++ honour the flags). So the mex files are always compiled with debug symb...Compilation flags (`CFLAGS` and `CXXFLAGS`) specified with the `configure` script are not passed correctly when building the mex files (the preprocessor and dynare++ honour the flags). So the mex files are always compiled with debug symbols and it is not possible to use more aggressive optimizations (ie `-O3`).
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/862support 32bit and 64bit preprocessors2019-06-19T15:38:00ZHoutan Bastanisupport 32bit and 64bit preprocessors- if a 64 bit preprocessor is created, rename it to `dynare_m64` (32 bit remains `dynare_m`)
- depending on whether the host OS is 32 or 64 bit, call the appropriate preprocessor from the matlab code
- if a 64 bit preprocessor is created, rename it to `dynare_m64` (32 bit remains `dynare_m`)
- depending on whether the host OS is 32 or 64 bit, call the appropriate preprocessor from the matlab code
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/640Provide support for Cygwin 64-bit2019-06-19T15:38:10ZSébastien VillemotProvide support for Cygwin 64-bitRecent versions of Cygwin include a 64-bit version, installed under `c:\cygwin64` by default.
We should support this configuration, at least in two places:
- when compiling MEX files with `use_dll`; see http://www.dynare.org/DynareWiki/...Recent versions of Cygwin include a 64-bit version, installed under `c:\cygwin64` by default.
We should support this configuration, at least in two places:
- when compiling MEX files with `use_dll`; see http://www.dynare.org/DynareWiki/ConfigureMatlabWindowsForMexCompilation
- in `README.md`, for people compiling from source
4.5https://git.dynare.org/Dynare/dynare/-/issues/461dynare++ doesn't compile with bison >= 2.72019-06-19T15:38:16ZMichelJuillarddynare++ doesn't compile with bison >= 2.7The functions xx_parse() are now declared int in csv_tab.hh formula_tab.hh and matrix_tab.hh, generated by bison, but declared void in csv_parser.cpp, formula_parser.cpp, matrix_parser.cpp
The functions xx_parse() are now declared int in csv_tab.hh formula_tab.hh and matrix_tab.hh, generated by bison, but declared void in csv_parser.cpp, formula_parser.cpp, matrix_parser.cpp
4.4https://git.dynare.org/Dynare/dynare/-/issues/375Support optional features of MatIO on Windows and Mac2016-06-10T12:43:17ZSébastien VillemotSupport optional features of MatIO on Windows and MacThe Windows binary currently comes with a matio compiled without zlib and HDF5, which means that it cannot read/write compressed MAT files nor 7.3 MAT-files.
The Mac binary is in the same situation.
Fixing this would first require comp...The Windows binary currently comes with a matio compiled without zlib and HDF5, which means that it cannot read/write compressed MAT files nor 7.3 MAT-files.
The Mac binary is in the same situation.
Fixing this would first require compiling static versions of zlib and HDF5 for the 2 platforms.
Then `-lhdf5 -lz` would have to be added to `LIBADD_MATIO` or, better, we could use `pkg-config` in ax_matio.m4 to detect the proper link flags (but the latter may be difficult in a cross-compiler environment).
4.5https://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/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.2