@janstarzy Could you please fix build (http://pullrequest.opencv.org/) and combine the commits into one so that we have a clear history in the repo?

Hope that's ok now, Git and Github are still very new to me. The failed build on Lin is due to the test-system, I think. Is's hard for me to provide a X-server ;-)

The X server issue is now resolved, sorry about that.

You didn't, however, combine any commits, you just added more, three of which are merges. Please rearrange your history into a series of logical changes, based on the latest 2.4. Interactive rebase is your friend.

Also, what's the point of those optional returns?

I merged the commits in my local copy (git log shows just one), but
could'nt figure out yet how to do so in my fork on github. I hoped these
changes would be pushed as well, but obviously I was wrong. As I
mentioned, I'm still very new to git.

The optional returns were in the original code. They all can be removed
or unified but I thought the author had something in mind with them
(code clearity?) and kept them. And added them again where I had removed
them unintentionally. That's all. May be they should be removed, but I'm
not sure.

The X server issue is now resolved, sorry about that.

You didn't, however, combine any commits, you just added more, three
of which are merges. Please rearrange your history into a series of
logical changes, based on the latest 2.4. Interactive rebase is your
friend.

Also, what's the point of those optional returns?

—
Reply to this email directly or view it on GitHub
#1177 (comment).

I merged the commits in my local copy (git log shows just one), but could'nt figure out yet how to do so in my fork on github. I hoped these changes would be pushed as well, but obviously I was wrong.

You need to force-push them to your fork now. The list of commits here will be automatically updated.

The optional returns were in the original code. They all can be removed or unified but I thought the author had something in mind with them (code clearity?) and kept them. And added them again where I had removed them unintentionally. That's all. May be they should be removed, but I'm not sure.

I see. Well, use your judgment.

I hope that's it. I undid a merge from my github-fork to my local copy (proposed by git push w/o force) and push-forced.

As you see, I kept the optional returns.

There's one commit now, but the commit message is wrong, and looking at the diff, I can see chunks of other commits. You can fix the former using git commit --amend, and probably the latter by rebasing on top of current master. If all else fails, you can just delete your branch, recreate it from the current master, replace the files with the most recent version and commit.

If all else fails, you can just delete your branch, recreate it from the current master, replace the files with the most recent version and commit.

That looked much easier and that's what I did.

I see, the merge failed :-(

That means you haven't used the latest master sorry, 2.4 to begin with.

You're right, I'm already working on it.

That means you haven't used the latest master sorry, 2.4 to begin with.

—
Reply to this email directly or view it on GitHub
#1177 (comment).

http://pullrequest.opencv.org/ is unreachable.

@apavlenko Andrey, could you please review?

I suggets removing all throwJavaException* functions except the throwJavaExceptionE and use the last one only.

That would log all exceptions to ERROR, not DEBUG, ok.
So two functions would remain:

/// throw java exception from std::exception
static void throwJavaException(JNIEnv *env, const std::exception &e,
const char *method);

/// throw java exception from unknown exception
static void throwJavaException(JNIEnv *env, const char *method);

There are a lot of unnecessary return statements after the calls to
throwJavaException[DE]. They can be removed/unified, but I kept them
because the original author had done so. What do you think, keep or remove?

I suggets removing all |throwJavaException*| functions except the
|throwJavaExceptionE| and use the last one only.

—
Reply to this email directly or view it on GitHub
#1177 (comment).

Agree with 2 remaining methods.
I think you can remove useless return-s.

👍