I have just fixed the bugs I mentionned earlier today. I cannot remember how to trigger the tests from the make command (make check doesn't work on my machine) but the mod files I tried are working (estimation, and simulation, are not crashing).

I am not sure I know how to revert master... And I am even less sure that this would be a good idea (I was told that we should never rewrite history).

The snapshots (donwloadable from the website) up to 13-Sep-2011 02:08 are not affected by my commits.

I agree that it is urgent to put in place the testing version. I don't see the problem with name... Most of the people work with the snapshots. All we have to do is to build the snapshots from the testing (or whatever name) branch which should be updated automatically from the master (unstable).

Meanwhile, I will try not to commit anything on master...

Best, Stéphane.

Michel Juillard michel.juillard@mjui.fr writes:

It is very urgent to put in place the testing version that we talked about. I have referred several people to the unstable version for things that I fixed over the Summer and we can't having it broken over long periods of time (more than one day, I would say)

In fact, intstead of having stable, (new) testing, unstable, I would suggest that we have stable, unstable (that we try to keep in workable state), (new) experimental which is not supposed to be entirely working. The names will be a bit misleading but it will avoid to have to inform people who download unstable to have to download testing instead.

Stephane, could you please revert master to a workable state and create a new experimental branch with the problematic merge instead, if you can't fix master today. We can always change the names of the branches when we come back from Frankfurt.

Best

Michel

On 09/17/2011 11:36 AM, Stéphane Adjemian wrote:

Dear all,

The estimation in dynare/master is broken since (my) commit 322adb92a5ee378ac89610678aeef8e65cebae1e. I am importing new versions of the estimation routines from
one of my private branch which have diverged from master. I try to fix this as soon as possible... But it is very likely that I will break again dynare/master
in the next weeks (not only the estimation).

Best,
Stéphane.

--
Stéphane Adjemian
Université du Maine, Gains et Cepremap
Tel(Gains):    +33(0)2 43 83 31 35
Tel(Cepremap): +33(0)1 40 77 84 19

_______________________________________________
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

Sorry for the message in French. I did not realize that I was writing to the entire list.

Best

Michel

On 09/17/2011 05:40 PM, Michel Juillard wrote:

Salut Stephane,

estimation est casse a cause de ??? Undefined function or method 'nanmean' for input arguments of type 'double'.

Error in ==> initialize_dataset at 78 dataset_.descriptive.mean = nanmean(dataset_.rawdata);

Il y a actuellement 13 tests qui ne passent pas. Ca vient sans doute de changement qui existent sur ta machine mais que tu n'as as commis.

Dans ce cas precis, on pourrait revenir en arriere sans re-ecrire l'histoire (on garde trace de tes changements et du retour en arriere), mais si c'est facile de corriger les problemes restants c'est sans doute mieux de garder tes changements

amicalement

Michel

Je viens de corriger un probleme avec make check. Ca marche maintenant (il faudra

On 09/17/2011 04:03 PM, Stéphane Adjemian wrote:

...

I have just fixed the bugs I mentionned earlier today. I cannot remember how to trigger the tests from the make command (make check doesn't work on my machine) but the mod files I tried are working (estimation, and simulation, are not crashing).

I am not sure I know how to revert master... And I am even less sure that this would be a good idea (I was told that we should never rewrite history).

The snapshots (donwloadable from the website) up to 13-Sep-2011 02:08 are not affected by my commits.

I agree that it is urgent to put in place the testing version. I don't see the problem with name... Most of the people work with the snapshots. All we have to do is to build the snapshots from the testing (or whatever name) branch which should be updated automatically from the master (unstable).

Meanwhile, I will try not to commit anything on master...

Best, Stéphane.

Michel Juillardmichel.juillard@mjui.fr writes:

...

It is very urgent to put in place the testing version that we talked about. I have referred several people to the unstable version for things that I fixed over the Summer and we can't having it broken over long periods of time (more than one day, I would say)

In fact, intstead of having stable, (new) testing, unstable, I would suggest that we have stable, unstable (that we try to keep in workable state), (new) experimental which is not supposed to be entirely working. The names will be a bit misleading but it will avoid to have to inform people who download unstable to have to download testing instead.

Stephane, could you please revert master to a workable state and create a new experimental branch with the problematic merge instead, if you can't fix master today. We can always change the names of the branches when we come back from Frankfurt.

Best

Michel

On 09/17/2011 11:36 AM, Stéphane Adjemian wrote:

 Dear all,

 The estimation in dynare/master is broken since (my) commit 322adb92a5ee378ac89610678aeef8e65cebae1e. I am importing new versions of the estimation routines from
 one of my private branch which have diverged from master. I try to fix this as soon as possible... But it is very likely that I will break again dynare/master
 in the next weeks (not only the estimation).

 Best,
 Stéphane.

 --
 Stéphane Adjemian
 Université du Maine, Gains et Cepremap
 Tel(Gains):    +33(0)2 43 83 31 35
 Tel(Cepremap): +33(0)1 40 77 84 19

 _______________________________________________
 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

---

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

Stéphane Adjemian stepan@dynare.org writes:

I've just found out the problem: nanmean is a routine of the matlab's statistical toolbox! This routine is also distributed in Octave...

I've just pushed a nanmean routine in the utilities/general folder and reverted your last commit (3bf482ae5c3fb0252363d59a6b345b74a6a97e18).

Is there a good reason for not putting 'nanmean' under 'matlab/missing/stats/', like other functions of the MATLAB statistical toolbox that are also in Octave?

@all: I have the impression that matlab never close the generated figures in the test suite... Is this normal ? Shouldn't we close all the figures after each mod file ? On my laptop this seems to be a problem, my matlab freezes after figure number 120...

This is normal but maybe not optimal. We have to see if adding a "close all" after each run does not create problems on text-only terminals.

Best,

Hi Stephane,

I commented out line 78 of ./matlab/utilities/dataset/initialize_dataset.m that triggers an error in the test suite. It is the problem that I mentioned in my previous message. Please, look how to fix it.

9 tests are still failing but they are for less central features.

All the best,

Michel

On 09/17/2011 04:03 PM, Stéphane Adjemian wrote:

I have just fixed the bugs I mentionned earlier today. I cannot remember how to trigger the tests from the make command (make check doesn't work on my machine) but the mod files I tried are working (estimation, and simulation, are not crashing).

I am not sure I know how to revert master... And I am even less sure that this would be a good idea (I was told that we should never rewrite history).

The snapshots (donwloadable from the website) up to 13-Sep-2011 02:08 are not affected by my commits.

I agree that it is urgent to put in place the testing version. I don't see the problem with name... Most of the people work with the snapshots. All we have to do is to build the snapshots from the testing (or whatever name) branch which should be updated automatically from the master (unstable).

Meanwhile, I will try not to commit anything on master...

Best, Stéphane.

Michel Juillardmichel.juillard@mjui.fr writes:

...

It is very urgent to put in place the testing version that we talked about. I have referred several people to the unstable version for things that I fixed over the Summer and we can't having it broken over long periods of time (more than one day, I would say)

In fact, intstead of having stable, (new) testing, unstable, I would suggest that we have stable, unstable (that we try to keep in workable state), (new) experimental which is not supposed to be entirely working. The names will be a bit misleading but it will avoid to have to inform people who download unstable to have to download testing instead.

Stephane, could you please revert master to a workable state and create a new experimental branch with the problematic merge instead, if you can't fix master today. We can always change the names of the branches when we come back from Frankfurt.

Best

Michel

On 09/17/2011 11:36 AM, Stéphane Adjemian wrote:

 Dear all,

 The estimation in dynare/master is broken since (my) commit 322adb92a5ee378ac89610678aeef8e65cebae1e. I am importing new versions of the estimation routines from
 one of my private branch which have diverged from master. I try to fix this as soon as possible... But it is very likely that I will break again dynare/master
 in the next weeks (not only the estimation).

 Best,
 Stéphane.

 --
 Stéphane Adjemian
 Université du Maine, Gains et Cepremap
 Tel(Gains):    +33(0)2 43 83 31 35
 Tel(Cepremap): +33(0)1 40 77 84 19

 _______________________________________________
 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

---

Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev

I agree with Sébastien.

A "testing"-snapshot version would be enough if we distribute the windows binaries *and* the sources... Because the idea is not to commit directly in the "testing" branch but to automatically cherry-pick (in testing) commits from master.

Best, Stéphane.

Sébastien Villemot sebastien.villemot@ens.fr writes:

Michel Juillard michel.juillard@mjui.fr writes:

...

It is very urgent to put in place the testing version that we talked about. I have referred several people to the unstable version for things that I fixed over the Summer and we can't having it broken over long periods of time (more than one day, I would say)

In fact, intstead of having stable, (new) testing, unstable, I would suggest that we have stable, unstable (that we try to keep in workable state), (new) experimental which is not supposed to be entirely working. The names will be a bit misleading but it will avoid to have to inform people who download unstable to have to download testing instead.

Personally I prefer the name "testing", it corresponds more to the reality.

However, I realize that if we want to implement this "testing" version only for users who download the snapshot (and not for those who use git), there is no need to create a new branch. I could just modify my snapshot building script so that a new snapshot is only created if all tests pass in the testsuite. The lastest snapshot available for download would therefore correspond to the last working state of the git. From the point of view of users who download the snapshot, this is "observationally equivalent" to having a testing branch.

Michel Juillard michel.juillard@mjui.fr writes:

I think that having a GIT branch identical to the snapshot would be useful when investigating problems reported in the snapshot, particularly if master becomes less stable than now.

Ok, then we keep the separate branch.

Currently, the unstable version is publicly known and the name is used in the Download section of the web site. I have been telling people to download the "unstable" version for several months. If we change the names, we will need to be very explicit on the web site in order to avoid useless queries.

What we can do is to distribute two snapshots: the "unstable" (corresponding to the master branch) and the "testing" one. Thus we are not contradicting any of our previous statements: we have always said that the "unstable" snapshot can be broken. We can present "testing" as a new snapshot which is between "stable" and "unstable" in the stability/bleeding-edgeness space.

Of course most of the time, today's testing will be equal to yesterday's unstable, but the advantage is that this setup allows for a temporary divergence between the two branches (which could be useful if for example we want "testing" to be temporarily equal to a broken "master" + some dirty workaround that we don't want to incorporate into master).

On 09/19/2011 02:08 PM, Stéphane Adjemian wrote:

I agree with Sébastien.

A "testing"-snapshot version would be enough if we distribute the windows binaries *and* the sources... Because the idea is
not to commit directly in the "testing" branch but to automatically cherry-pick (in testing) commits from master.

Best,
Stéphane.

Sébastien Villemot <sebastien.villemot@ens.fr> writes:

    Michel Juillard <michel.juillard@mjui.fr> writes:

        It is very urgent to put in place the testing version that we talked
        about. I have referred several people to the unstable version for
        things that I fixed over the Summer and we can't having it broken over
        long periods of time (more than one day, I would say)

        In fact, intstead of having stable, (new) testing, unstable, I would
        suggest that we have stable, unstable (that we try to keep in workable
        state), (new) experimental which is not supposed to be entirely
        working. The names will be a bit misleading but it will avoid to have
        to inform people who download unstable to have to download testing
        instead.

    Personally I prefer the name "testing", it corresponds more to the
    reality.

    However, I realize that if we want to implement this "testing" version
    only for users who download the snapshot (and not for those who use
    git), there is no need to create a new branch. I could just modify my
    snapshot building script so that a new snapshot is only created if all
    tests pass in the testsuite. The lastest snapshot available for download
    would therefore correspond to the last working state of the git. From
    the point of view of users who download the snapshot, this is
    "observationally equivalent" to having a testing branch.

_______________________________________________
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