#101: Preprocessor crashes when some dynamic variables appear only in unused
model local variables
--------------------------+-------------------------------------------------
Reporter: sebastien | Owner: sebastien
Type: bug | Status: new
Priority: minor | Milestone:
Component: Preprocessor | Version: 4.1.1
Keywords: |
--------------------------+-------------------------------------------------
See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=2592
The fix is probably to add calls to ExprNode::collectVariables() on model
local variables from DynamicModel::computeDerivIDs()
--
Ticket URL: <https://www.dynare.org/trac/ticket/101>
Dynare <http://www.dynare.org>
The Dynare project
#105: Support normcdf(), asinh(), acosh(), atanh() for USE_DLL+MSVC combination
--------------------------+-------------------------------------------------
Reporter: sebastien | Owner: sebastien
Type: feature | Status: new
Priority: minor | Milestone:
Component: Preprocessor | Version:
Keywords: |
--------------------------+-------------------------------------------------
This would be particularly useful for Windows/64 users, since they don't
have the Cygwin option.
--
Ticket URL: <https://www.dynare.org/trac/ticket/105>
Dynare <http://www.dynare.org>
The Dynare project
#11: Allow for the possibility of using the bytecode representation of the model
for any task
---------------------------+------------------------------------------------
Reporter: sebastien | Owner: ferhat
Type: enhancement | Status: accepted
Priority: major | Milestone: 4.2
Component: Preprocessor | Version:
Resolution: | Keywords:
---------------------------+------------------------------------------------
Comment(by sebastien):
Almost done.
We plan a change in the semantics of stack_solve_algo. Currently, values 0
and 1 actually implement the same algorithm (sim1/simk don’t actually
implement the original relaxation algorithm). We propose to associate to
value 1 the original relaxation algorithm, which will be available in
bytecode at first (slower, but less memory-consuming).
--
Ticket URL: <https://www.dynare.org/trac/ticket/11#comment:3>
Dynare <http://www.dynare.org>
The Dynare project
On Fri, Sep 03, 2010 at 10:06:48AM +0100, George Perendia wrote:
> PS: And what about existing cygwin installation with mingw in
> C:\cygwin\usr\i686-pc-mingw32
> Do we still need to upgrade mingw?
What is this installation ? If it is a custom installation, then just delete
it. There is also a MinGW provided by Cygwin, but it is deficient and uses an
old GCC version (3).
In any case, you need to install the MinGW mentionned on the wiki page.
And don’t forget to clean your PATH if it contains other installations of
MinGW.
Best,
--
Sébastien Villemot
CEPREMAP — http://www.cepremap.ens.fr
Dynare project — http://www.dynare.org
Phone: +33 1 40 77 49 90
PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/)
On Fri, Sep 03, 2010 at 09:59:12AM +0100, George Perendia wrote:
> This looks good and easier for a novice to use.
>
> 1) What about the old user requirements for windows (cygwin) not
> listed any more such as:
> * {{{gcc}}}, {{{gcc-g++}}}
> * {{{gcc-mingw}}}, {{{gcc-mingw-g++}}}
> * {{{gcc4}}}, {{{gcc4-g++}}} and {{{gcc4-gfortran}}}
> * {{{readline}}}
> * {{{libhdf5-devel}}}
>
> Are they not needed any more if one uses Mingw?
No, they are not needed anymore for compiling Dynare with MinGW. But keeping
them is not a problem either.
> 2) What happened to Git users such as our development team? Do we
> continue to use Git to download? I suppose we do but what then about
> the precompiled libraries, will they be updateable via git too?
Nothing has changed regarding Git. We still use it for the development of the
Dynare source code.
Concerning the precompiled binaries, I don’t plan to use a git repository for
them, since they are going to change very rarely. Actually they’re going to
change only if we introduce a new dependency for Dynare (for example when we
added the GSL for the Markov-Switching code), or if we want to upgrade versions
there. I will send an e-mail on the list if I update them.
> 3) GitHowTo (still) suggests using "pull" to download but yuo say
> you prefer us to use Fetch&Rebase. F&R may be easier to control from
> the PM view but it does not merge local and remote changes as pull
> does and so it seems that F&R overwrites any local changes if there
> is a conflict which requires more work and control on our side or we
> may loose our work.
>
> Could we use Pull and then Rebase instead F&R?
Don’t use “pull” and then “rebase”, this will just mess up everything.
The simple rule is the following :
- if you have local commits which are not yet incorporated in the origin/master
branch, then do a “fetch & rebase”
- otherwise, if you have no local commit, a “pull” is fine (and in that case is
equivalent to a “fetch & rebase”).
Houtan is going to improve the wiki page on Git, I hope this will clarify
things for you.
Best,
--
Sébastien Villemot
CEPREMAP — http://www.cepremap.ens.fr
Dynare project — http://www.dynare.org
Phone: +33 1 40 77 49 90
PGP Key: 0xA6C029B9D06B2913D71C105EBE37E801FB6EFF8B (http://pgp.mit.edu/)