plumbing features through the interfaces
27 views
Skip to first unread message
Sebastian Weber
Apr 1, 2016, 7:12:33 AM4/1/16
to stan development mailing list
Hi!
My apologies if this has already been discussed, but I was wondering how you guys handle features which touch simultaneously the different layers. So for example, let's say I write a neat new function in stan-math. This will affect stan and potentially cmdstan.
- Should I create now an issue in *all* repositories?
- And how can I make the changes in math available to code in stan when I am developing?
Is this somewhere on the wiki?
Thanks!
Sebastian
Krzysztof Sakrejda
Apr 1, 2016, 11:04:22 AM4/1/16
to stan development mailing list
On Friday, April 1, 2016 at 7:12:33 AM UTC-4, Sebastian Weber wrote:
> Hi!
>
> My apologies if this has already been discussed, but I was wondering how you guys handle features which touch simultaneously the different layers. So for example, let's say I write a neat new function in stan-math. This will affect stan and potentially cmdstan.
>
> - Should I create now an issue in *all* repositories?
> Hi!
>
> My apologies if this has already been discussed, but I was wondering how you guys handle features which touch simultaneously the different layers. So for example, let's say I write a neat new function in stan-math. This will affect stan and potentially cmdstan.
>
> - Should I create now an issue in *all* repositories?
I'd start with an issue in the language repo (if this is for something that ends up getting exposed in the interfaces) and get enough buy-in that you think it's going to make it through the process, then open an issue on stan-dev/math (if there's math to implement) once you know how it's going to be implemented). The language seems to be the gatekeeper for the interfaces. It makes sense since the interfaces mostly expose the language rather than providing another layer and once people start using a language feature we're sort of stuck with maintenance/deprecation management.
Krzysztof
Bob Carpenter
Apr 1, 2016, 12:46:20 PM4/1/16
to stan...@googlegroups.com
Daniel --- can you dump this in the wiki somewhere with clarification?
I realized I don't know how to synch breaking updates.
I don't think so. There are two cases. Adding a new function to Stan
is easy. It can go in math, then in Stan, then there's nothing to
change downstream.
Changing a behavior in math that then breaks stan is a different problem.
That usually doesn't happen. But if it does, then we need pull requests
for both math and stan (and sometimes all the other interfaces),
because the math tests test integration with stan and above.
There's a make target in all the repos with sub-repos, as in make math-update
from Stan that brings you to current math w.r.t. branch of stan you are on, or
the current stan w.r.t. branch of cmdstan you are on (no idea how RStan, PyStan,
etc. do this).
- 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+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
I realized I don't know how to synch breaking updates.
I don't think so. There are two cases. Adding a new function to Stan
is easy. It can go in math, then in Stan, then there's nothing to
change downstream.
Changing a behavior in math that then breaks stan is a different problem.
That usually doesn't happen. But if it does, then we need pull requests
for both math and stan (and sometimes all the other interfaces),
because the math tests test integration with stan and above.
There's a make target in all the repos with sub-repos, as in make math-update
from Stan that brings you to current math w.r.t. branch of stan you are on, or
the current stan w.r.t. branch of cmdstan you are on (no idea how RStan, PyStan,
etc. do this).
- 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+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Bob Carpenter
Apr 1, 2016, 12:59:20 PM4/1/16
to stan...@googlegroups.com
See below.
Daniel --- could you also drop the diagram below in the wiki page?
because we don't want to break people's models, so we want to be careful
with naming, etc. The language itself only interfaces through the model
class that gets generated in C++.
It's just that everything has to be consistent.
> It makes sense since the interfaces mostly expose the language rather than providing another layer and once people start using a language feature we're sort of stuck with maintenance/deprecation management.
The bigger picture is this, and you see the stan-dev/stan repo really
spans three logical layers:
stan
----------------------------------
math <- language <- algorithms <- services <- pystan
<- rstan <- rstanarm
<- rethinking
<- cmdstan <- statastan
<- matlabstan
<- stan.jl
What we are trying to do with the services refactor is make a clean
services layer between the core interfaces (pystan, rstan, cmdstan) so that
these don't have to know anything below the services layer. Ideally,
there wouldn't be any calls from pystan, rstan, or cmdstan other than
ones to the stan::services namespace. services, on the other hand, is
almost certainly going to need to know about things below the algorithms
level in language and math.
- Bob
Daniel --- could you also drop the diagram below in the wiki page?
> On Friday, April 1, 2016 at 7:12:33 AM UTC-4, Sebastian Weber wrote:
>> Hi!
>>
>> My apologies if this has already been discussed, but I was wondering how you guys handle features which touch simultaneously the different layers. So for example, let's say I write a neat new function in stan-math. This will affect stan and potentially cmdstan.
>>
>> - Should I create now an issue in *all* repositories?
>
> I'd start with an issue in the language repo (if this is for something that ends up getting exposed in the interfaces) and get enough buy-in that you think it's going to make it through the process, then open an issue on stan-dev/math (if there's math to implement) once you know how it's going to be implemented).
> The language seems to be the gatekeeper for the interfaces.
The language isn't usually the issue, though we are picky about it
>> Hi!
>>
>> My apologies if this has already been discussed, but I was wondering how you guys handle features which touch simultaneously the different layers. So for example, let's say I write a neat new function in stan-math. This will affect stan and potentially cmdstan.
>>
>> - Should I create now an issue in *all* repositories?
>
> I'd start with an issue in the language repo (if this is for something that ends up getting exposed in the interfaces) and get enough buy-in that you think it's going to make it through the process, then open an issue on stan-dev/math (if there's math to implement) once you know how it's going to be implemented).
> The language seems to be the gatekeeper for the interfaces.
because we don't want to break people's models, so we want to be careful
with naming, etc. The language itself only interfaces through the model
class that gets generated in C++.
It's just that everything has to be consistent.
> It makes sense since the interfaces mostly expose the language rather than providing another layer and once people start using a language feature we're sort of stuck with maintenance/deprecation management.
spans three logical layers:
stan
----------------------------------
math <- language <- algorithms <- services <- pystan
<- rstan <- rstanarm
<- rethinking
<- cmdstan <- statastan
<- matlabstan
<- stan.jl
What we are trying to do with the services refactor is make a clean
services layer between the core interfaces (pystan, rstan, cmdstan) so that
these don't have to know anything below the services layer. Ideally,
there wouldn't be any calls from pystan, rstan, or cmdstan other than
ones to the stan::services namespace. services, on the other hand, is
almost certainly going to need to know about things below the algorithms
level in language and math.
- Bob
Daniel Lee
Apr 1, 2016, 1:10:42 PM4/1/16
to stan-dev mailing list
Yes. I'll put it up on a wiki in Stan.
I'll also link to it from the other wikis.Daniel Lee
Apr 4, 2016, 3:37:56 PM4/4/16
to stan-dev mailing list
Feel free to edit.
DanielReply all
Reply to author
Forward
0 new messages