hotfix GitFlow mess; overhead in stack_alloc

[Bob Carpenter]

1. I'd like to get a release out ASAP that fixes the memory
leaks. So I'm going to fix those before turning to new
projects (finishing Cholesky correlation, new auto-diff).

2. Now that it's been over a month since the start
of hotfix/v2.1.1, can we just merge the whole mess back
into develop when it's stable and work from there?

Given our pickiness in keeping develop in a ready-to-release
state, I don't see that we're ever going to need a hotfix
branch.

3. I thought we'd decided to back out the bytes requested
counter in stack_alloc.hpp? Am I misremembering? It's still
there in the most recent hotfix/v2.1.1 branch.

I'm going to fix the other memory leaks without using the
counter method. I don't know if it's then going to be easy
to back out.

The tests will be brittle, but I'd really rather not keep
chipping away at efficiency for the sake of convenience in
testing. As usual, the testing's really holding me back.
(On that note, I really want to get the C++11 fixes to the parser
in that have been languishing for lack of tests.)

- Bob

[Daniel Lee]

On Thu, Jan 16, 2014 at 3:08 PM, Bob Carpenter <ca...@alias-i.com> wrote:

1.  I'd like to get a release out ASAP that fixes the memory
leaks.  So I'm going to fix those before turning to new
projects (finishing Cholesky correlation, new auto-diff).

Great. Once all the known memory leaks are patched, lets get a release out.

2.  Now that it's been over a month since the start
of hotfix/v2.1.1, can we just merge the whole mess back
into develop when it's stable and work from there?

Every pull request to the hotfix branch should be duplicated. One goes to the hotfix branch, the other to develop. I've already created a second pull request, but haven't merged yet.

 

Given our pickiness in keeping develop in a ready-to-release
state, I don't see that we're ever going to need a hotfix
branch.

I do. I can imagine a scenario where our pickiness doesn't stop a bad feature. If we have just bugfixes on the hotfix branch, the hotfix branch will only be fixing bugs from the last release.

Of course, I could be convinced to just release from develop whenever we're ready, but then every patch release we'll be introducing new features.

 

3.  I thought we'd decided to back out the bytes requested
counter in stack_alloc.hpp?  Am I misremembering?  It's still
there in the most recent hotfix/v2.1.1 branch.

I think you're misremembering, but here's my suggestion:

- fix the other memory leaks with tests for the bytes requested counter

- after all (known) memory leaks have been patched, let's take the counter out

 

I'm going to fix the other memory leaks without using the
counter method.  I don't know if it's then going to be easy
to back out.

I can handle the backing out. Go ahead and patch the code with the tests.

 

The tests will be brittle, but I'd really rather not keep
chipping away at efficiency for the sake of convenience in
testing.  As usual, the testing's really holding me back.
(On that note, I really want to get the C++11 fixes to the parser
in that have been languishing for lack of tests.)

So my suggestion is to use the counter for the testing now. After it's in, we'll pull it out and leave brittle tests in place.

Is that going to be too complicated?

 

- Bob

--
You received this message because you are subscribed to the Google Groups "stan development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Daniel Lee]

Nevermind my last comments. I see the pull request. I'll review that.

[Bob Carpenter]

I fixed the one remaining memory leak (log_softmax) and added
a brittle test. You can verify by unplugging
the leak (i.e., removing the agrad::vari qualification
on operator new) and seeing the test fail.

The new tests with the counter are also not very robust
because they'll fail if the internals of the function change
in the way that they use variables or auxiliary memory.

If you want to use the counter for testing and then back it
out again right away, could you do it?

You're right that we might mess up develop somehow and still want
to get a hotfix out. Bottom line is that I'm OK
with just a hotfix release for 2.1.1 next.

My only ongoing concern is that I don't want to spam our users with
releases. We need to balance that with fixing major problems like
leaks in softmax ASAP.

Luckily, this latest change shouldn't require anything of PyStan or
RStan other than rebuilding.

There are still a couple of issues tagged for 2.1.1, as well as some
doc updates, so I don't think we're quite there yet. But they're all
just bug fixes, not new features.

- Bob

On 1/16/14, 10:04 PM, Daniel Lee wrote:

> stan-dev+unsubscribe@__googlegroups.com <mailto:stan-dev%2Bunsu...@googlegroups.com>.
> For more options, visit https://groups.google.com/__groups/opt_out <https://groups.google.com/groups/opt_out>.

>
>
> --
> You received this message because you are subscribed to the Google Groups "stan development mailing list" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.