Closing... I was unsure what to do. The commit that I made contained the wrong reference, so that there is no evidence here that the patch was applied.
BTW that was
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Jan 21 2020
Jan 18 2020
Going back to original Py_Finalize() to maintain compatibility with pithon2 and earlier versions of python3
Jan 16 2020
Jan 13 2020
Is there a reason why the patch was not applied to master? It would seem plausible...
Jan 11 2020
Since I forgot to mention, this is a patch agains bug #416037
Jan 10 2020
Removed comments
Jan 9 2020
Jan 8 2020
patch applied to release/19.12 also
Pushed in git@git.kde.org:kig branch master. I should do the same in Applications/19.12, I guess
Jan 7 2020
On second thought I would vote for Py_INCREF... an object_imp can change dinamically, but I think the worst case would be an "InvalidObject", which still is an object.
We should apply this patch in the git repository; I think I can do it myself.
Dec 31 2019
I uploaded the result of a git diff in
my collegue Franco Pasquarelli proposed the following patch
Jun 1 2018
Now that the goldenpoint got merged in master, we should also push this bug patch (in master). I can take care of that.
perhaps a bug should also be merged into other branches of kig?
May 30 2018
I think we should wait for David Narvaez to decide what to do
May 26 2018
In D13139#268813, @bourquin wrote:This patch is on top of the golden ratio point patch.
As I said, this is not a probem specific of the Golden Ratio. You should have a look at the bug report https://bugs.kde.org/show_bug.cgi?id=394676
This is a consequence of a somewhat obscure information that can (should) be associated to a construction.
I know this very well since I am responsible for it.
May 25 2018
I just filed a bug report for the problem mentioned above: https://bugs.kde.org/show_bug.cgi?id=394676
in that report there is no mention of the new GoldenRatio property; it would raise the number of properties
of a segment from 5 to 6, the method mentioned in the bug report should return "true" for the GoldenRatio
property, since the constructed point is contained in the segment.
About the crash above: the problem resides in AbstractLineImp::isPropertyDefinedOnOrThroughThisImp...
However it involves more than the new Golden Point. Perhaps the right action should be to file a bug
report.
It seems that the implementation of this property is wrong with respect to the hierarchy of objects
I get a crash with a construction involving the new 'golden ratio' point:
- construct a segment s = AB
- construct the golden point G from the segment
- circle of center C (somewhere) through G
- position C such that the circle has two distinct intersections with the segment, one is G
- contruct the intersections between the segment and the circle
May 16 2018
I would not object in accepting this revision
Concerning the external point... I would *not* add a construction for it... I am afraid that such construction would be somewhat confusing.
As you see... most (if not all) of the figures representing the golden section show the larger segment on the left. And when you say
"short to long equals long to whole", this is simply the result of a phrase where the subject is actually the "long", something like
"the long is 'in between' the whole and the rest".
Moreover you could as well say
"whole to long equals long to short" (and I would prefer this latter phrasing as more corresponding to the definition:
I have one remark. Since the result is different depending on how we orient the segment (say) AB we have to decide if the construction
gives the point on the segment nearest to A or the one nearest to B. The proposed solution: