More replacement of various uses of math.sqrt with math.hypot #40437

New Issue

Lawrence D'Oliveiro · 2014-05-30T09:08:18+02:00

2014-05-30 09:08:18 +02:00

Following on from #40416, I had a look through blender-addons-contrib, and found some opportunities for similar and other simplifications. I have grouped my changes into 3 separate patches.

Remove unnecessary imports: addons-contrib-unnecessary-imports.patch
Use Vector.length rather than calculating sqrt of vector dotted with itself: addons-contrib-vector-length.patch (oops, duplicate upload addons-contrib-vector-length.patch)
Replace various uses of math.sqrt with more concise math.hypot: addons-contrib-sqrt-hypot.patch

Some of these addons seem buggy. I trust I have not introduced any new bugs, at any rate. :)

Following on from #40416, I had a look through blender-addons-contrib, and found some opportunities for similar and other simplifications. I have grouped my changes into 3 separate patches. Remove unnecessary imports: [addons-contrib-unnecessary-imports.patch](https://archive.blender.org/developer/F91947/addons-contrib-unnecessary-imports.patch) Use Vector.length rather than calculating sqrt of vector dotted with itself: [addons-contrib-vector-length.patch](https://archive.blender.org/developer/F91948/addons-contrib-vector-length.patch) (oops, duplicate upload [addons-contrib-vector-length.patch](https://archive.blender.org/developer/F91950/addons-contrib-vector-length.patch)) Replace various uses of math.sqrt with more concise math.hypot: [addons-contrib-sqrt-hypot.patch](https://archive.blender.org/developer/F91949/addons-contrib-sqrt-hypot.patch) Some of these addons seem buggy. I trust I have not introduced any *new* bugs, at any rate. :)

Lawrence D'Oliveiro commented

2014-05-30 09:08:18 +02:00

Changed status to: 'Open'

Lawrence D'Oliveiro commented

2014-05-30 09:08:18 +02:00

Added subscriber: @ldo

Bastien Montagne commented

2014-05-30 19:32:29 +02:00

Changed status from 'Open' to: 'Archived'

Bastien Montagne closed this issue

2014-05-30 19:32:29 +02:00

Bastien Montagne self-assigned this 2014-05-30 19:32:29 +02:00

Bastien Montagne commented

2014-05-30 19:32:29 +02:00

@ldo Thanks a lot for this patch, but unfortunately, we do not maintain contrib addons… As you noticed, some are buggy, we should probably cleanup that repo one day, but we only edit those addons e.g. when we make a breaking API change or so… Else, it’s their authors’ responsibility to keep them in good shape.

Lawrence D'Oliveiro commented

2014-05-31 01:32:15 +02:00

It seems to me there is no harm accepting these patches. Remember, you are using Git now, so this should not greatly complicate the task of merging in any future updates from the original contributors.

In fact, they can merge in your fixes as well.

It seems to me there is no harm accepting these patches. Remember, you are using Git now, so this should not greatly complicate the task of merging in any future updates from the original contributors. In fact, they can merge in your fixes as well.

Lawrence D'Oliveiro commented

2014-06-15 07:22:32 +02:00

Where do users come if they want definitive versions of these addons? It seems to me they would most likely come here, to the official Blender Foundation repo, just as I did.

Which is why it is sad to hear that these addons cannot be properly maintained here. This is an official Blender Foundation repository, is it not? Why have a repo if not to facilitate collaborative development? Is this repo to be come a dumping ground for poorly-maintained, gradually decaying code?

Sure, by all means say that the original authors should be primarily responsible for maintenance of this code. But then why put a copy into this repo? Is it not to act as the central source for obtaining the code? But, being a Git repo, should it not also be a central location for maintaining the code?

Let the authors maintain their own copies, by all means. That is the beauty of Git: you can accept updates from them, and they can accept updates from you. Doing work in one place does not preclude doing work in another place. Git is all about decentralized collaboration.

For those authors who have abandoned their code, the users’ only choice becomes to get updates from you. And for those authors who have not completely abandoned their code, but are, shall we say, getting just a bit lazy, perhaps the sight of others taking over more of the contributions should prompt them to wake up and become more active themselves.

Where do users come if they want definitive versions of these addons? It seems to me they would most likely come here, to the official Blender Foundation repo, just as I did. Which is why it is sad to hear that these addons cannot be properly maintained here. This is an official Blender Foundation repository, is it not? Why have a repo if not to facilitate collaborative development? Is this repo to be come a dumping ground for poorly-maintained, gradually decaying code? Sure, by all means say that the original authors should be primarily responsible for maintenance of this code. But then why put a copy into this repo? Is it not to act as the central source for obtaining the code? But, being a Git repo, should it not also be a central location for *maintaining* the code? Let the authors maintain their own copies, by all means. That is the beauty of Git: you can accept updates from them, and they can accept updates from you. Doing work in one place does not preclude doing work in another place. Git is all about decentralized collaboration. For those authors who have abandoned their code, the users’ only choice becomes to get updates from you. And for those authors who have not completely abandoned their code, but are, shall we say, getting just a bit lazy, perhaps the sight of others taking over more of the contributions should prompt them to wake up and become more active themselves.

Bastien Montagne commented

2014-06-15 10:16:02 +02:00

That kind of discussion would be better done on ML (bf-python) imho, that way everyone could participate.

But to summarize the role of the "testing" repo, it’s supposed to be a transitional repo where incomming addons get tested and fine tuned (code style etc.), before going to contrib repo, that’s why testing is only distributed with nightly builds, and not official releases. Granted, we should clen it up, we have way too much dead code in there...

That kind of discussion would be better done on ML (bf-python) imho, that way everyone could participate. But to summarize the role of the "testing" repo, it’s supposed to be a transitional repo where incomming addons get tested and fine tuned (code style etc.), before going to contrib repo, that’s why testing is only distributed with nightly builds, and not official releases. Granted, we should clen it up, we have way too much dead code in there...

Lawrence D'Oliveiro commented

2014-06-15 10:50:03 +02:00

I’m talking about the blender-addons-contrib repo.

Bastien Montagne commented

2014-06-15 10:56:34 +02:00

Rrrrm… sorry, just woke up here :/

Well, the point remain, as I said in first answer, we usually do not edit contrib addons, unless cases like API changes or so… I would again suggest to raise this on ML, that kind of general discussion (do we stick to minimal interventions in contrib, or can we be more involved) is better suited there imho.

Rrrrm… sorry, just woke up here :/ Well, the point remain, as I said in first answer, we usually do not edit contrib addons, unless cases like API changes or so… I would again suggest to raise this on ML, that kind of general discussion (do we stick to minimal interventions in contrib, or can we be more involved) is better suited there imho.

Philipp Oeser commented

2014-10-23 15:17:07 +02:00

Added subscriber: @lichtwerk

J.R.I.B. commented

2015-03-01 23:07:19 +01:00

Added subscriber: @faerietree

J.R.I.B. commented

2015-03-01 23:07:19 +01:00

@ldo:
Couldn't we just fork this repo (recreate it on Github) and then maintain it there?

@ldo: Couldn't we just fork this repo (recreate it on Github) and then maintain it there?

Lawrence D'Oliveiro commented

2015-03-01 23:42:41 +01:00

Very tempting idea. This repo has become a wasteland.

Unfortunately any fork is not likely to become as well-known as an official Blender Foundation repo. Which puts us back at square one, as far as I’m concerned.

Very tempting idea. This repo has become a wasteland. Unfortunately any fork is not likely to become as well-known as an official Blender Foundation repo. Which puts us back at square one, as far as I’m concerned.

J.R.I.B. commented

2015-03-01 23:54:49 +01:00

True ... (The 2nd/3rd least redundant case of just maintaining a fork on our personal Github/any other server sites may make it difficult for people to know which now is the newest/fittest version despite the useful x commits ahead, y commits behind fork information on Github.)

So if it's helping to gather it all in one place, then we might create a community (open source) organization:

BlenderDevelopers,
BlenderCommunity,
blendercom,
or whatever. Then add all the coders we know of that are active and have idling code, macoono, cwolf3d, migius, zeffii, ...

I agree it'd be nice to have it here, but the opinion of blender foundation has to be respected (they are responsible for the repo, have to pay for servers, ... so it's Blender foundation's decision).

Edit: Long-term planning (personal, not blender foundation) includes a rolling release style blender anyway. So why not go ahead and provide a full rolling release blender (HEAD revision, autobuilt, but with roll-back to stable option) bundled with our maintained contrib addons?

Edit2: Another alternative is to use the blender addon linking shell script that supports multiple sources and this way easily allows to override deprecated versions of addons that come with blender ... (e.g. BoltGenerator, render2print, online_mat_lib, ...)

Edit3: Fixing breakage by interesting API changes like FILENAME -> FILE_NAME can also be fixed easily in a central repo, while it takes very long until every coder realizes there is a refactoring that broke Addon 3, 7, 11 and 13 of the 15 addons the poor guy/gal has coded.

True ... (The 2nd/3rd least redundant case of just maintaining a fork on our personal Github/any other server sites may make it difficult for people to know which now is the newest/fittest version despite the useful x commits ahead, y commits behind fork information on Github.) So if it's helping to gather it all in one place, then we might create a community (open source) organization: - BlenderDevelopers, - BlenderCommunity, - blendercom, or whatever. Then add all the coders we know of that are active and have idling code, macoono, cwolf3d, migius, zeffii, ... I agree it'd be nice to have it here, but the opinion of blender foundation has to be respected (they are responsible for the repo, have to pay for servers, ... so it's Blender foundation's decision). **Edit:** Long-term planning (personal, not blender foundation) includes a rolling release style blender anyway. So why not go ahead and provide a full rolling release blender (HEAD revision, autobuilt, but with roll-back to stable option) bundled with our maintained contrib addons? **Edit2:** Another alternative is to use the blender addon linking shell script that supports multiple sources and this way easily allows to override deprecated versions of addons that come with blender ... (e.g. BoltGenerator, render2print, online_mat_lib, ...) **Edit3:** Fixing breakage by interesting API changes like FILENAME -> FILE_NAME can also be fixed easily in a central repo, while it takes very long until every coder realizes there is a refactoring that broke Addon 3, 7, 11 and 13 of the 15 addons the poor guy/gal has coded.

J.R.I.B. commented

2015-03-05 15:27:31 +01:00

Summary: If a repository, then one using submodules for a more decentralized character. Else let's encourage to use the shell gather addons and link script, which solves all problems but the one that one coder who might want to automatically commit the same fix for several foreign (not his own) addons too. In this case the busy coder needs to fork each modified addon's repository. Either case leads to only subtly increased workload for the busy coder as the addon is checked out as full or as submodule repository anyway which makes fork->pull request/patch/diff generation easy.

Turns out that all addons in one single repository are suboptimal anyway.
It seems a repository for every addon is the better choice.
Then one wrapper repository that include the addons as submodules. It allows to include svn or hg (mercurial) repositories too.

This way, the coders aren't required to join the central/Github organization/blender developer anymore. The programmer's credit can be maintained. Otherwise a different person that is part of the organization had to commit the foreign addon code into the merge-repository (like blender-addons-contrib), which as side-effect will lead to a stern issue: Usually the authors of the addon place the extension code in its own repository. Therefore pull requests are not possible and a maintenance mess (or at least unnecessary manual work) follows.

Using Git submodules this can be avoided. Without depending on pull requests, the maintainers of the collection/wrapper repository can pick the newest addon (and even if the maintainers not manage to reference the most recent commit in the submodule, then the user still had a pointer towards where to get the newest version - and could even analyze the fork network on Github for more insight).

=> Git submodules is a sensible solution if a centralized maintenance is discouraged (and it currently is because if centralized maintenance was to happen, then it should happen here on developer.blender.org).

**Summary:** If a repository, then one using submodules for a more decentralized character. Else let's encourage to use the shell gather addons and link script, which solves all problems but the one that one coder who might want to automatically commit the same fix for several foreign (not his own) addons too. In this case the busy coder needs to fork each modified addon's repository. Either case leads to only subtly increased workload for the busy coder as the addon is checked out as full or as submodule repository anyway which makes fork->pull request/patch/diff generation easy. --- Turns out that all addons in one single repository are suboptimal anyway. It seems a repository for every addon is the better choice. Then one wrapper repository that include the addons as submodules. It allows to include svn or hg (mercurial) repositories too. This way, the coders aren't required to join the central/Github organization/blender developer anymore. The programmer's credit can be maintained. Otherwise a different person that is part of the organization had to commit the foreign addon code into the merge-repository (like blender-addons-contrib), which as side-effect will lead to a stern issue: Usually the authors of the addon place the extension code in its own repository. Therefore pull requests are not possible and a maintenance mess (or at least unnecessary manual work) follows. Using Git submodules this can be avoided. Without depending on pull requests, the maintainers of the collection/wrapper repository can pick the newest addon (and even if the maintainers not manage to reference the most recent commit in the submodule, then the user still had a pointer towards where to get the newest version - and could even analyze the fork network on Github for more insight). \=> Git submodules is a sensible solution if a centralized maintenance is discouraged (and it currently is because if centralized maintenance was to happen, then it should happen here on developer.blender.org).

Lawrence D'Oliveiro commented

2015-03-05 19:18:52 +01:00

Multiple addons in one repo are exactly what we have with blender-addons. That seems to work well enough. The problem with blender-addons-contrib is the refusal of the PTB to to accept changes from anyone other than the original authors—a policy which doesn’t apply to blender-addons, for some reason. The corresponding patch to this for blender-addons, #40416, was accepted without problem.

Sign in to join this conversation.