Page MenuHome

More replacement of various uses of math.sqrt with math.hypot
Closed, ArchivedPublic


Following on from T40416, 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:

Use Vector.length rather than calculating sqrt of vector dotted with itself: (oops, duplicate upload )
Replace various uses of math.sqrt with more concise math.hypot:

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



Event Timeline

Lawrence D'Oliveiro (ldo) set Type to Patch.
Lawrence D'Oliveiro (ldo) created this task.
Lawrence D'Oliveiro (ldo) raised the priority of this task from to Needs Triage by Developer.
Bastien Montagne (mont29) closed this task as Archived.May 30 2014, 7:32 PM
Bastien Montagne (mont29) claimed this task.

@Lawrence D'Oliveiro (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.

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.

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.

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...

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

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.

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

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.

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. (faerietree) added a comment.EditedMar 5 2015, 3:27 PM

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

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, T40416, was accepted without problem.