Dear All,
concerning the freeze+release of DYNARE 4.5, I would like to finish/PR:
- shock decompositions + plot_shock_decomposition utilities;
- some (minor) extensions to the parallel [not yet the submodule, which
would be a major change, but an option to tell how many threads to
assign for each slave, since currently we give a singleCompThread which
might be inefficient given the latest desktops featuring a large number
of cpu's]. I would say this requires a new option for the dynare.ini
file for the node. I have to open an issue on github
- there are a couple of small issues in posterior sampling analysis: in
particular it seems impossible/difficult in the current configuration to
run, e.g., posteriorIRF with load_mh_file=1 and mh_replic=0, unless the
oo_ stored in _results if perfectly fit [which is almost never the case
I must say ... ]. Moreover, current parallel configuration for posterior
subdraws and plots does not look appropriate any longer.
- I think it would be useful to have an option for not to fill in
oo_.FilteredVariablesKStepAheadVariances, e.g. by using
options_.filter_covariance [I have a possible PR for this in
store_smoother_results].
- I need to check my local copies for further small adjustments here and
there.
- I would like to fix #838 #1016 [and associated #789] #1170.
What would be the DEADLINE before freezing DYNARe 4.5?
many thanks
best
Marco
--
Marco Ratto,
Finance and Economy Unit
Joint Research Centre
European Commission,
TP 361, 21027 ISPRA(VA), ITALY
Tel: +39 0332 78 3794 Fax: +39 0332 78 5752,
marco.ratto@jrc.ec.europa.eu
http://www.macfinrobods.eu/
On 11/29/2016 11:00 AM, Stéphane Adjemain wrote:
> Hi,
>
> I also vote for the second option. But I would prefer not to take it
> from the master branch... If I create a branch 4.5 this week (I was
> about to do it) would it be fine with the Debian's deadlines.
>
> Before the official release we need to fix (or merge):
>
> - #1201 (the issue with nested parenthesis limit in matlab).
> - Fix the interface for (stochastic) extended path.
> - #1287 (I need to push the fix I made somewhere).
> - PR related to the documentation.
>
> I am working on the windows build. We target Octave 4.2, but we wont't
> have time to fix all the bugs before the release of 4.5.0. This will
> have to wait 4.2.1.
>
> Following issues will wait another release:
>
> - #1175 is related to the changes that revealed the problem in #1201.
> Normally we don't need this anymore... This is not a blocking issue.
> - #419
> - #841
> - #1045
>
> That said, I am also fine with option 3. Maybe we should have 4.5.x (and
> 4.y.x) in experimental. I ;have no idea of the amount of work necessary
> to build a debian package...
>
> Best,
> Stéphane.
>
>
> On 28/11/2016 15:32, Johannes Pfeifer wrote:
>> Hi,
>>
>> I would go for Option 2. We continuously keep delaying the release of a
>> new stable version, although the current unstable version is a lot more
>> "stable" than 4.4.3 and fixes several critical bugs.
>> What is blocking the release of a new stable version?
>>
>> From my perspective, it is
>>
>> 1. Bug #1201 needs to be fixed. That is probably the critical issue here.
>> 2. #1175 should be taken care of.
>> 3. #419 needs to be taken care of (proposed solution exists).
>> 4. #1287 should be dealt with (easy workaround available).
>> 5. The outstanding pull requests should be taken care of, particularly
>> the documentation ones.
>> 6. There are various issues with the build system for Windows we need to
>> solve when we want to release a Windows version (#1179).
>> 7. Octave 4.2 support does still not fully work, but I don't consider
>> this critical (#1307).
>> 8. #841/#1045 would be nice to have, but is not essential.
>>
>> There are various smaller things we could always fix in 4.5.1, including
>> issues at the back end of the above list.
>>
>> Best,
>>
>> Johannes
>>
>> Am 28.11.2016 um 14:34 schrieb Sébastien Villemot:
>>> Dear all,
>>>
>>> The next version of Debian (labelled "Stretch") will be released in
>>> spring 2017. Like all Debian releases, it is expected to be maintained
>>> for 3 years, which means until 2020.
>>>
>>> Given the tight release schedule, we must make very quickly (i.e. in the
>>> coming days) a decision about the status of the Dynare package in that
>>> release.
>>>
>>> There are basically 3 options:
>>>
>>> 1. Ship Dynare 4.4.3 in Debian Stretch.
>>> Pros: this is the latest stable release, and Debian usually ships
>>> stable releases
>>> Cons: it is getting quite old
>>>
>>> 2. Ship a snapshot of Dynare
>>> Pros: fresh codebase
>>> Cons: hard to decide which git commit on which to base the package;
>>> possibly buggy
>>>
>>> 3. Drop the package (from the stable release, not necessarily from
>>> Debian sid/unstable)
>>> Pros: avoids shipping an old or a unstable codebase; makes it clear
>>> that the user must make its own decision
>>> Cons: less user-friendly
>>>
>>> All 3 options are fine with me, but I think you are in a better position
>>> than me to decide. Please let me know what to do.
>>>
>>> Best,
>>>
>> _______________________________________________
>> Dev mailing list
>> Dev@dynare.org
>>
https://www.dynare.org/cgi-bin/mailman/listinfo/dev
>
>
> _______________________________________________
> Dev mailing list
> Dev@dynare.org
>
https://www.dynare.org/cgi-bin/mailman/listinfo/dev
