Dev

dev@dynare.org

3402 discussions

[Fwd: Dynare version 4.0.0]
by Michel Juillard 17 Sep '08

17 Sep '08

-------- Original Message -------- Subject: Dynare version 4.0.0 Date: Tue, 16 Sep 2008 19:27:19 -0700 From: Wesley_Phoa(a)capgroup.com To: Michel Juillard <michel.juillard(a)ens.fr> Michel: I just took a break from the financial crisis to install it. Congratulations to everyone on the team! Best regards, Wesley Phoa.

1 0

[Fwd: r2081 - dynare_v4/debian]
by Michel Juillard 17 Sep '08

17 Sep '08

How do we handle these bugs in packaging for one particular architecture? Do we replace the package silently ? Do we have different version numbers for different packages? Do we make a bug fixing release for all architectures, even if nothing changes in some? Best Michel -------- Original Message -------- Subject: r2081 - dynare_v4/debian Date: Wed, 17 Sep 2008 18:02:33 +0200 From: sebastien(a)pythie.cepremap.cnrs.fr To: subversion_users(a)cepremap.cnrs.fr Author: sebastien Date: 2008-09-17 18:02:33 +0200 (Wed, 17 Sep 2008) New Revision: 2081 Modified: dynare_v4/debian/dynare.install Log: trunk debian/ubuntu packaging: added missing matlab/distributions/ and matlab/distributions/toolbox/ directories Modified: dynare_v4/debian/dynare.install =================================================================== --- dynare_v4/debian/dynare.install 2008-09-17 16:00:41 UTC (rev 2080) +++ dynare_v4/debian/dynare.install 2008-09-17 16:02:33 UTC (rev 2081) @@ -1,7 +1,9 @@ -matlab/*.m /usr/lib/dynare/matlab -matlab/gensylv/*.m /usr/lib/dynare/matlab/gensylv -matlab/qz/*.m /usr/lib/dynare/matlab/qz -matlab/kronecker/*.m /usr/lib/dynare/matlab/kronecker -mex/octave/*.mex /usr/lib/dynare/mex/octave -mex/octave/rcond.m /usr/lib/dynare/mex/octave -preprocessor/dynare_m /usr/lib/dynare/matlab +matlab/*.m /usr/lib/dynare/matlab +matlab/gensylv/*.m /usr/lib/dynare/matlab/gensylv +matlab/qz/*.m /usr/lib/dynare/matlab/qz +matlab/kronecker/*.m /usr/lib/dynare/matlab/kronecker +matlab/distributions/*.m /usr/lib/dynare/matlab/distributions +matlab/distributions/toolbox/*.m /usr/lib/dynare/matlab/distributions/toolbox +mex/octave/*.mex /usr/lib/dynare/mex/octave +mex/octave/rcond.m /usr/lib/dynare/mex/octave +preprocessor/dynare_m /usr/lib/dynare/matlab

2 4

Virtualization on Hal
by Sébastien Villemot 17 Sep '08

17 Sep '08

Hi all, I am trying to run a virtual machine on Hal, so that I can compile packages for Ubuntu/AMD64 there (and it would probably be possible to also run a Windows/64). The software I use for that (VirtualBox) is very intuitive, but needs a hardware feature, called Intel VT. The feature is present in Hal, but is currently disabled in the BIOS, and therefore we need a manual intervention on Hal for enabling it. Does any of you plan to go to Jourdan in the near future ? Best Sébastien

2 2

Subversion migration
by Sébastien Villemot 16 Sep '08

16 Sep '08

Hi all I have written a wiki page about the project of migrating the SVN server (and other related stuff): http://www.cepremap.cnrs.fr/DynareWiki/SubversionMigration Please write your comments/ideas on the wiki page or on the list. Best Sébastien P.S. for George and Ferhat: you don't seem subscribed to changes on the Wiki. It would probably be a good thing if you did so, since you would then be informed by e-mail of the modifications on the Wiki. For doing that, log in into the Wiki with your personal account, click on "Preferences" and put ".*" (a dot followed by a star, i.e. the catch-all regular expression) in the last field of the preferences page.

1 0

v4.0
by Michel Juillard 15 Sep '08

15 Sep '08

Hi everybody, I'm ready to release v 4.0. It is still far from perfect, but I think that the main functions are working. What do you think? Best Michel

4 3

Broken functions
by Sébastien Villemot 10 Sep '08

10 Sep '08

The following functions are implemented in the preprocessor, but are currently broken: * dsample: the preprocessor sets options_.dsample when encountering this command, but this option is never used in the Matlab code (just initialized in global_initialization); however, there exists a dsample.m which sets options_.smpl. I suppose I should fix this by asking the preprocessor to call dsample.m (or maybe even incorporate the content of dsample.m into the preprocessor). Am I right ? * calib and calib_var: it is clear that the Matlab files (calib.m, calib_obj.m and calib_obj2.m) corresponding to these functions are currently broken (the function prototypes contain global variables, which makes no sense...). What should we do about these? * model_comparison: the Matlab file corresponding to this preprocessor command is actually missing (it has not been ported from v3). Stéphane is going to look at this. Best Sébastien

1 0

/branches/4.0/locked ?
by Stéphane Adjemian 08 Sep '08

08 Sep '08

Hi all, Did someone locked the svn repository (/branches/4.0) ? I cannot commit... Best, Stéphane. Stéphane Adjemian Université du Maine, GAINS & CEPREMAP http://www.cepremap.cnrs.fr/~adjemian

3 3

changes in Dynare v4
by Michel Juillard 06 Sep '08

06 Sep '08

Hi everybody, I just realized that with all the changes that we made to the function names (distributions) and the calling sequences, we broke all code written by Dynare users and using Dynare internals. We need to document these changes quickly on DynareWiki. We need to write a tool (perl, python, ...) that -compares two dynare versions (only /matlab/ and subdirectories) -which *.m f ile were added/deleted -extracts the function ..... line, compares the argument lists and reports differences. Who can start working on it? Best Michel

3 3

freezing version 4.0.0
by Michel Juillard 05 Sep '08

05 Sep '08

Hi everybody, on SVN, I have created branches/4.0 to freeze version 4.0.0 Most changes necessary to release version 4.0.0 have been done. There are a few keywords/options that need to be added to the preprocessor and more tests need to be done. Please keep adding new features to the trunk (don't change anything to your SVN setup). If you want to test version 4.0.0, please check out branches/4.0 in a separate working directory, then commit only bug corrections from this working directory. Best, Michel -------- Original Message -------- Subject: Re: SVN Date: Tue, 08 Jul 2008 17:40:56 +0200 From: Sébastien Villemot <sebastien.villemot(a)ens.fr> To: stephane.adjemian(a)ens.fr CC: Michel Juillard <michel.juillard(a)ens.fr>, George Perendia <artilogica(a)btconnect.com> References: <487370EC.4010500(a)ens.fr> <200807081638.05166.stephane.adjemian(a)ens.fr> <20080708165802.17365ydzqi1sg8sg(a)www.zelya.net> <200807081712.03561.stephane.adjemian(a)ens.fr> Here is the timeline: * we finish Dynare 4.0.0 in the trunk (dynare_v4/) * when we're done, we copy dynare_v4/ to branches/4.0 and tags/4.0.0 * we fix bugs in branches/4.0, creating new releases when we feel the need (creating a release involves copying branches/4.0 to tags/4.0.x where x is the minor release number) * meanwhile, we add new features or restructure the code in the trunk (dynare_v4/). Also note that many bug fixes done on the 4.0 branch will also apply to the trunk * when we think we can make a new major release (for example when we've completed September 30 goals), we release 4.1.0 by copying dynare_v4/ to branches/4.1 and tags/4.1.0 * we continue the parallel development of the trunk, the 4.1 branch, and maybe the 4.0 branch (or we can decide to drop the 4.0 branch at that point) Sébastien "Stéphane Adjemian" <stephane.adjemian(a)ens.fr> a écrit : > So we use branches/4.0 to fix the bugs and use dynare_v4 to develop > dynare. Am > I right ? But what is the purpose of branches/4.1 (before the release of > dynare 4.1.0) ? > > Stéphane. > > > Le Tuesday 08 July 2008 16:58:02, vous avez écrit : >> Under our current tree layout: >> * dynare_v4/ is the trunk >> * branches/ is for branches (for example branches/4.0/ or branches/4.1/) >> * tags/ is for releases (tags/4.0.0, tags/4.0.1, ...) >> >> Sébastien >> >> "Stéphane Adjemian" <stephane.adjemian(a)ens.fr> a écrit : >> > I also agree with Sébastien suggestion (if the trunk is the current >> > dynare_v4 directory under svn). >> > >> > Stéphane. >> > >> > Le Tuesday 08 July 2008 16:29:36 G. Perendia, vous avez écrit : >> >> I support Sebastian's suggestion which, as he pointed out, is in line >> >> with the SW industry standard practices. We may also have the >> >> "traditional" "alpha" and "beta" releases (but that is just a matter of >> >> naming the X.0.0 and X.0.1 releases respectively). >> >> >> >> Best regards >> >> >> >> George >> >> Mob. +44(0)7951415480 >> >> artilogica(a)btconnect.com >> >> >> >> ----- Original Message ----- >> >> From: "Sébastien Villemot" <sebastien.villemot(a)ens.fr> >> >> To: "Michel Juillard" <michel.juillard(a)ens.fr> >> >> Cc: "George Perendia" <artilogica(a)btconnect.com>; "StéphaneAdjemian" >> >> <stephane.adjemian(a)gmail.com> >> >> Sent: Tuesday, July 08, 2008 3:12 PM >> >> Subject: Re: SVN >> >> >> >> >> >> Concerning Dynare release schedule, one option would be the following: >> >> >> >> * finish Dynare 4.0, and release version 4.0.0 >> >> * create a 4.0 branch in the SVN, used only for bugfixes; in other >> >> words, versions 4.0.1, 4.0.2... would only incoporate bug fixes since >> >> 4.0.0, but no new feature nor code restructuring >> >> * add new features or code restructurings in the trunk; the trunk will >> >> later become the 4.1 branch (maybe for the September 30 deadline) >> >> * and so on at each major release/deadline... >> >> >> >> This model of development is used in many softwares. Its main interest >> >> is that it produces very stable software at the end of a development >> >> branch, since no new feature can destabilize the code along a branch. >> >> On the other hand, it involves some overhead related to the >> >> simultaneous management of a branch and a trunk (a bugfix needs often >> >> to be applied to both). >> >> >> >> Do you think it is a sensible development model for Dynare? >> >> >> >> Best >> >> >> >> Sébastien >> >> >> >> "Michel Juillard" <michel.juillard(a)ens.fr> a écrit : >> >> > I have added 'george' as username authorized to commit on the SVN >> >> > archive. The password is as mentioned at the Summer School. >> >> > George will also get the email messages after each commit. >> >> > >> >> > Stephane, I checked that these messages go for you at >> >> > stephane.adjemian(a)ens.fr. Is it what you want? >> >> > >> >> > best >> >> > >> >> > Michel > > >

2 2

options_.replic
by Stéphane Adjemian 04 Sep '08

04 Sep '08

Hi all, We have a problem with options_.replic which is used for three different purposes (number of prior simulations, irfs with a second order approximation and repeated stochastic simulations). In global_initialization.m this variable is defined twice! We have: * options_.replic =1 for prior simulations (?) , and after * options_.replic = 50 for irfs with a second order approximation ... So that the default value is 50. When the user asks for a stochastic simulation with a second order approximation, dynare simulates 50 times the model and displays the results associated to the last simulated time series. Shouldn't we create new fields in options_ ? If so, how should I call them (for the prior sampler and for the repeated stochastic simulations) ? Something will have to be fixed also in the preprocessor. Best, Stéphane. Stéphane Adjemian Université du Maine, GAINS & CEPREMAP.

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Dev