issue #19: handle multiple nodes #38

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
2 participants
@rflynn

rflynn commented Apr 13, 2013

...days wasted on this one.

@uwiger

This comment has been minimized.

Show comment
Hide comment
@uwiger

uwiger Apr 13, 2013

Owner

Ehm, can you be more specific? What exactly was the problem?

Owner

uwiger commented Apr 13, 2013

Ehm, can you be more specific? What exactly was the problem?

@rflynn

This comment has been minimized.

Show comment
Hide comment
@rflynn

rflynn Apr 14, 2013

The same as issue #19 -- looks like i need to say "issue #19" in the commit message to make the pull request show up there...

rflynn commented Apr 14, 2013

The same as issue #19 -- looks like i need to say "issue #19" in the commit message to make the pull request show up there...

@uwiger

This comment has been minimized.

Show comment
Hide comment
@uwiger

uwiger Apr 14, 2013

Owner

No matter which gen_leader I insert in the deps, it will be the wrong one
for some people.

One question: How do you use gproc? Do you fetch/build it from a top-level
rebar.config?

By setting an OS env variable, REBAR_DEPS, gproc can be made to set
deps_dir to some local directory, and use whatever gen_leader you have
there.

I'd be happy to consider other ways of telling gproc which gen_leader to
use, at build-time.

2013/4/14 Ryan Flynn notifications@github.com

The same as issue #19 #19 --
looks like i need to say "issue #19#19"
in the commit message to make the pull request show up there...


Reply to this email directly or view it on GitHubhttps://github.com/uwiger/gproc/pull/38#issuecomment-16353811
.

Owner

uwiger commented Apr 14, 2013

No matter which gen_leader I insert in the deps, it will be the wrong one
for some people.

One question: How do you use gproc? Do you fetch/build it from a top-level
rebar.config?

By setting an OS env variable, REBAR_DEPS, gproc can be made to set
deps_dir to some local directory, and use whatever gen_leader you have
there.

I'd be happy to consider other ways of telling gproc which gen_leader to
use, at build-time.

2013/4/14 Ryan Flynn notifications@github.com

The same as issue #19 #19 --
looks like i need to say "issue #19#19"
in the commit message to make the pull request show up there...


Reply to this email directly or view it on GitHubhttps://github.com/uwiger/gproc/pull/38#issuecomment-16353811
.

@rflynn

This comment has been minimized.

Show comment
Hide comment
@rflynn

rflynn Apr 16, 2013

Yes, we use rebar.config and managed to override gen_leader even without the change, I was just trying to save other people the hassle of running into the same problem. I'm confused about why the out-of-the-box config wouldn't work properly for "global" across >1 node, since Erlang's "global"does and that's what you compare to in your gproc whitepaper, though it's possible I'm missing something.

rflynn commented Apr 16, 2013

Yes, we use rebar.config and managed to override gen_leader even without the change, I was just trying to save other people the hassle of running into the same problem. I'm confused about why the out-of-the-box config wouldn't work properly for "global" across >1 node, since Erlang's "global"does and that's what you compare to in your gproc whitepaper, though it's possible I'm missing something.

@uwiger

This comment has been minimized.

Show comment
Hide comment
@uwiger

uwiger May 24, 2013

Owner

Leaving this open for a while. I've detected no consensus yet regarding which gen_leader is the best, and I'm hoping that some rebar changes will eventually appear that make it easier for users to exercise control of dependencies.

Owner

uwiger commented May 24, 2013

Leaving this open for a while. I've detected no consensus yet regarding which gen_leader is the best, and I'm hoping that some rebar changes will eventually appear that make it easier for users to exercise control of dependencies.

@uwiger

This comment has been minimized.

Show comment
Hide comment
@uwiger

uwiger May 29, 2014

Owner

I'm closing this. There is still no concensus on gen_leader versions, and I don't expect there will be any. Personally, I'm leaning towards locks_leader instead (see the uw-locks_leader branch)

Owner

uwiger commented May 29, 2014

I'm closing this. There is still no concensus on gen_leader versions, and I don't expect there will be any. Personally, I'm leaning towards locks_leader instead (see the uw-locks_leader branch)

@uwiger uwiger closed this May 29, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment