GSoc 2016: Final Reviews required

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

GSoc 2016: Final Reviews required

AMR_KELEG

Dear all,

First of all, I would like to thank all of you for giving me this great opportunity to contribute to the GNU Octave project.
I enjoyed my summer this year working on this project with all the ups and downs - motives and frustrations.

Special thanks goes to my Mentor Professor John Swenson.
Working with you was such a
privilege.


I have to send my work to Google this week as part of my final evaluation so i would like to share my clone of the Geometry package with you.

https://bitbucket.org/amr_keleg/octave-geometry/src/76898074c0f2bbf77cc38c6ff27609800c1baf2d?at=default
Kindly contact me if you have reviews/required edits.

Regards,
Amr Mohamed

Reply | Threaded
Open this post in threaded view
|

Re: GSoc 2016: Final Reviews required

PhilipNienhuis
AMR_KELEG wrote
Dear all,


First of all, I would like to thank all of you for giving me this great opportunity to contribute to the GNU Octave project.
I enjoyed my summer this year working on this project with all the ups and downs - motives and frustrations.

Special thanks goes to my Mentor Professor John Swenson.
Working with you was such a privilege.


I have to send my work to Google this week as part of my final evaluation so i would like to share my clone of the Geometry package with you.

https://bitbucket.org/amr_keleg/octave-geometry/src/76898074c0f2bbf77cc38c6ff27609800c1baf2d?at=default
Kindly contact me if you have reviews/required edits.
Amr,

Some test results.

I installed the header files belonging to boost-1_61-0.7z in /usr/include. 134 MB on disk, quite a bit IMO. (entire boost download would expand to 555 MB,still more excessive).

Next I've cloned your repo and made a geometry-3.0.0 package from it (incl. bootstrap)and built geometry-3.0.0 on both Linux and Windows.
In both OS-es, pkg install mentions that "dissolve" isn't found and that boost needs an upgrade to >= 1.6 (while I have 1.61.0).  Do I need to install additional boost stuff alongside just the header files?

Then I tried the examples on the Mathworks site. (http://nl.mathworks.com/help/map/ref/polybool.html).
A little worrying is that when trying the second example set, Octave crashes hard on the poly2fv call in the sixth block (subplot 2, 3, 6), both on Linux and Windows.
Can you manage to fix that, please?

best wishes,

philip


Reply | Threaded
Open this post in threaded view
|

Re: GSoc 2016: Final Reviews required

AMR_KELEG
PhilipNienhuis wrote
AMR_KELEG wrote
Dear all,


First of all, I would like to thank all of you for giving me this great opportunity to contribute to the GNU Octave project.
I enjoyed my summer this year working on this project with all the ups and downs - motives and frustrations.

Special thanks goes to my Mentor Professor John Swenson.
Working with you was such a privilege.


I have to send my work to Google this week as part of my final evaluation so i would like to share my clone of the Geometry package with you.

https://bitbucket.org/amr_keleg/octave-geometry/src/76898074c0f2bbf77cc38c6ff27609800c1baf2d?at=default
Kindly contact me if you have reviews/required edits.
Amr,

Some test results.

I installed the header files belonging to boost-1_61-0.7z in /usr/include. 134 MB on disk, quite a bit IMO. (entire boost download would expand to 555 MB,still more excessive).

Next I've cloned your repo and made a geometry-3.0.0 package from it (incl. bootstrap)and built geometry-3.0.0 on both Linux and Windows.
In both OS-es, pkg install mentions that "dissolve" isn't found and that boost needs an upgrade to >= 1.6 (while I have 1.61.0).  Do I need to install additional boost stuff alongside just the header files?

Then I tried the examples on the Mathworks site. (http://nl.mathworks.com/help/map/ref/polybool.html).
A little worrying is that when trying the second example set, Octave crashes hard on the poly2fv call in the sixth block (subplot 2, 3, 6), both on Linux and Windows.
Can you manage to fix that, please?

best wishes,

philip
Dear Philip,

I don't think you need to install additional boost stuff alongside the header files.
This means that the dissolve header file that is extracted from the Boost Geometry 1.60 extensions isn't working with Boost Geometry 1.61 .
IMO,I can add the new version of dissolve header file that is part of the Boost Geometry 1.61 extensions to the package and add some checks to choose between the two header files.
So,what do you think?

I tried the Matworks second test and it's working smoothly.
So,I attached a screenshot of the test/output figures.
Screenshot_from_2016-08-20_05-32-50.png

I will write a blog post summarizing the new functions and i will also share my tests for further development/bug fixes.

Best Regards,
Amr
Reply | Threaded
Open this post in threaded view
|

Re: GSoc 2016: Final Reviews required

PhilipNienhuis
AMR_KELEG wrote
PhilipNienhuis wrote
AMR_KELEG wrote
Dear all,


First of all, I would like to thank all of you for giving me this great opportunity to contribute to the GNU Octave project.
I enjoyed my summer this year working on this project with all the ups and downs - motives and frustrations.

Special thanks goes to my Mentor Professor John Swenson.
Working with you was such a privilege.


I have to send my work to Google this week as part of my final evaluation so i would like to share my clone of the Geometry package with you.

https://bitbucket.org/amr_keleg/octave-geometry/src/76898074c0f2bbf77cc38c6ff27609800c1baf2d?at=default
Kindly contact me if you have reviews/required edits.
Amr,

Some test results.

I installed the header files belonging to boost-1_61-0.7z in /usr/include. 134 MB on disk, quite a bit IMO. (entire boost download would expand to 555 MB,still more excessive).

Next I've cloned your repo and made a geometry-3.0.0 package from it (incl. bootstrap)and built geometry-3.0.0 on both Linux and Windows.
In both OS-es, pkg install mentions that "dissolve" isn't found and that boost needs an upgrade to >= 1.6 (while I have 1.61.0).  Do I need to install additional boost stuff alongside just the header files?

Then I tried the examples on the Mathworks site. (http://nl.mathworks.com/help/map/ref/polybool.html).
A little worrying is that when trying the second example set, Octave crashes hard on the poly2fv call in the sixth block (subplot 2, 3, 6), both on Linux and Windows.
Can you manage to fix that, please?
Dear Philip,

I don't think you need to install additional boost stuff alongside the header files.
This means that the dissolve header file that is extracted from the Boost Geometry 1.60 extensions isn't working with Boost Geometry 1.61 .
IMO,I can add the new version of dissolve header file that is part of the Boost Geometry 1.61 extensions to the package and add some checks to choose between the two header files.
So,what do you think?
That might be a good idea. But see below as regards boost versions.

I tried the Matworks second test and it's working smoothly.
So,I attached a screenshot of the test/output figures.
Screenshot_from_2016-08-20_05-32-50.png
To be sure I uninstalled boost-1.61.0 and downgraded to / installed boost-1.60.0
Sure enough, the Matlab example went without a hitch then.

It not very reassuring that the polygon operations do not work with current boost but only with the previous version..... :-)
I'd prefer that the polygon operations work with newest boost versions.

BTW
I find that installing geometry-3.0.0 (beta) from your github account takes a very long time to finish (some minutes) *after* the last compile and copy step. Would you by any chance know what is happening then? Just copying the binary modules into place shouldn't need that much time IMO.
But maybe it is just the polybool compile step that takes so long; installing packages is multi-threaded these days so it could be that the copy step is just hanging until polybool compilation is finalized.

Anyway, as I announced earlier this week I've made a start with comparing the various function versions (ispolycw etc.) to see which ones would be the best and how those could be incorporated in the geometry/mapping packages.

Philip
Reply | Threaded
Open this post in threaded view
|

Re: GSoc 2016: Final Reviews required

Carnë Draug
On 20 August 2016 at 12:00, PhilipNienhuis <[hidden email]> wrote:
> [...]
> I find that installing geometry-3.0.0 (beta) from your github account takes
> a very long time to finish (some minutes) *after* the last compile and copy
> step. Would you by any chance know what is happening then? Just copying the
> binary modules into place shouldn't need that much time IMO.
> [...]

Did you compare with the previous version of the geometry package?
The documentation cache seems to take most of the time because of the
high number functions.  Also, it is not parallelized and a lot slower
on recent versions of Texinfo.

Carnë

Reply | Threaded
Open this post in threaded view
|

Re: GSoc 2016: Final Reviews required

PhilipNienhuis
Carnë Draug wrote:

> On 20 August 2016 at 12:00, PhilipNienhuis <[hidden email]> wrote:
>> [...]
>> I find that installing geometry-3.0.0 (beta) from your github account takes
>> a very long time to finish (some minutes) *after* the last compile and copy
>> step. Would you by any chance know what is happening then? Just copying the
>> binary modules into place shouldn't need that much time IMO.
>> [...]
>
> Did you compare with the previous version of the geometry package?
> The documentation cache seems to take most of the time because of the
> high number functions.  Also, it is not parallelized and a lot slower
> on recent versions of Texinfo.

I profiled a geometry pkg install (both 2.1.1 and 3.0.0) and profshow
suggests that calls to system() take ~97 % of all the processing time.

profexplore however shows that it is "generate_lookfor_cache" and
descending some levels down, doc_cache_create, gen_doc_cache_in_dir and
finally cellfun() and then "anonymous@" that are responsible for most of
that processing time.
How that is to be reconciled with the total time needed for system() (as
profshow indicated) is beyond me .....

Philip

Reply | Threaded
Open this post in threaded view
|

Re: GSoc 2016: Final Reviews required

John Swensen-3
In reply to this post by PhilipNienhuis

> On Aug 20, 2016, at 4:00 AM, PhilipNienhuis <[hidden email]> wrote:
>
> AMR_KELEG wrote
>>
>> PhilipNienhuis wrote
>>>
>>> AMR_KELEG wrote
>>>> Dear all,
>>>>
>>>>
>>>> First of all, I would like to thank all of you for giving me this great
>>>> opportunity to contribute to the GNU Octave project.
>>>> I enjoyed my summer this year working on this project with all the ups
>>>> and downs - motives and frustrations.
>>>>
>>>> Special thanks goes to my Mentor Professor John Swenson.
>>>> Working with you was such a privilege.
>>>>
>>>>
>>>> I have to send my work to Google this week as part of my final
>>>> evaluation so i would like to share my clone of the Geometry package
>>>> with you.
>>>>
>>>> https://bitbucket.org/amr_keleg/octave-geometry/src/76898074c0f2bbf77cc38c6ff27609800c1baf2d?at=default
>>>> Kindly contact me if you have reviews/required edits.
>>> Amr,
>>>
>>> Some test results.
>>>
>>> I installed the header files belonging to boost-1_61-0.7z in
>>> /usr/include. 134 MB on disk, quite a bit IMO. (entire boost download
>>> would expand to 555 MB,still more excessive).
>>>
>>> Next I've cloned your repo and made a geometry-3.0.0 package from it
>>> (incl. bootstrap)and built geometry-3.0.0 on both Linux and Windows.
>>> In both OS-es, pkg install mentions that "dissolve" isn't found and that
>>> boost needs an upgrade to >= 1.6 (while I have 1.61.0).  Do I need to
>>> install additional boost stuff alongside just the header files?
>>>
>>> Then I tried the examples on the Mathworks site.
>>> (http://nl.mathworks.com/help/map/ref/polybool.html).
>>> A little worrying is that when trying the second example set, Octave
>>> crashes hard on the poly2fv call in the sixth block (subplot 2, 3, 6),
>>> both on Linux and Windows.
>>> Can you manage to fix that, please?
>> Dear Philip,
>>
>> I don't think you need to install additional boost stuff alongside the
>> header files.
>> This means that the dissolve header file that is extracted from the Boost
>> Geometry 1.60 extensions isn't working with Boost Geometry 1.61 .
>> IMO,I can add the new version of dissolve header file that is part of the
>> Boost Geometry 1.61 extensions to the package and add some checks to
>> choose between the two header files.
>> So,what do you think?
>
> That might be a good idea. But see below as regards boost versions.
>
>
>> I tried the Matworks second test and it's working smoothly.
>> So,I attached a screenshot of the test/output figures.
>> Screenshot_from_2016-08-20_05-32-50.png
>> <http://octave.1599824.n4.nabble.com/file/n4679337/Screenshot_from_2016-08-20_05-32-50.png>  
>
> To be sure I uninstalled boost-1.61.0 and downgraded to / installed
> boost-1.60.0
> Sure enough, the Matlab example went without a hitch then.
>
> It not very reassuring that the polygon operations do not work with current
> boost but only with the previous version..... :-)
> I'd prefer that the polygon operations work with newest boost versions.
>
> BTW
> I find that installing geometry-3.0.0 (beta) from your github account takes
> a very long time to finish (some minutes) *after* the last compile and copy
> step. Would you by any chance know what is happening then? Just copying the
> binary modules into place shouldn't need that much time IMO.
> But maybe it is just the polybool compile step that takes so long;
> installing packages is multi-threaded these days so it could be that the
> copy step is just hanging until polybool compilation is finalized.
>
> Anyway, as I announced earlier this week I've made a start with comparing
> the various function versions (ispolycw etc.) to see which ones would be the
> best and how those could be incorporated in the geometry/mapping packages.
>
> Philip
>
>
>
>
> --
> View this message in context: http://octave.1599824.n4.nabble.com/GSoc-2016-Final-Reviews-required-tp4679299p4679342.html
> Sent from the Octave - Maintainers mailing list archive at Nabble.com.
>

I think we still need to make another tweak to the makefile.in. The only feature of the polygons that is version dependent is the self-intersection correction (they call it the “dissolve” algorithm). Everything else should work as-is. The dissolve function is currently in the development repositories, but not in the releases. I was under the impression that the 1.60 dissolve worked for both 1.60 and 1.61, but I guess that isn’t the case.

There should be two scenarios, though both should work with different levels of functionality:

1) all functions should work without self-intersection correction for Boost.Geometry > 1.57
2) all functions should work with self-intersection correction for Boost.Geometry > 1.60

I will take a quick look and help Amr figure out why it isn’t doing the conditional compile of the self-intersection correction.

John





Reply | Threaded
Open this post in threaded view
|

Re: GSoc 2016: Final Reviews required

PhilipNienhuis
John Swensen-3 wrote
> On Aug 20, 2016, at 4:00 AM, PhilipNienhuis <[hidden email]> wrote:
>
> AMR_KELEG wrote
>>
>> PhilipNienhuis wrote
>>>
>>> AMR_KELEG wrote
>>>> Dear all,
>>>>
>>>>
>>>> First of all, I would like to thank all of you for giving me this great
>>>> opportunity to contribute to the GNU Octave project.
>>>> I enjoyed my summer this year working on this project with all the ups
>>>> and downs - motives and frustrations.
>>>>
>>>> Special thanks goes to my Mentor Professor John Swenson.
>>>> Working with you was such a privilege.
>>>>
>>>>
>>>> I have to send my work to Google this week as part of my final
>>>> evaluation so i would like to share my clone of the Geometry package
>>>> with you.
>>>>
>>>> https://bitbucket.org/amr_keleg/octave-geometry/src/76898074c0f2bbf77cc38c6ff27609800c1baf2d?at=default
>>>> Kindly contact me if you have reviews/required edits.
>>> Amr,
>>>
>>> Some test results.
>>>
>>> I installed the header files belonging to boost-1_61-0.7z in
>>> /usr/include. 134 MB on disk, quite a bit IMO. (entire boost download
>>> would expand to 555 MB,still more excessive).
>>>
>>> Next I've cloned your repo and made a geometry-3.0.0 package from it
>>> (incl. bootstrap)and built geometry-3.0.0 on both Linux and Windows.
>>> In both OS-es, pkg install mentions that "dissolve" isn't found and that
>>> boost needs an upgrade to >= 1.6 (while I have 1.61.0).  Do I need to
>>> install additional boost stuff alongside just the header files?
>>>
>>> Then I tried the examples on the Mathworks site.
>>> (http://nl.mathworks.com/help/map/ref/polybool.html).
>>> A little worrying is that when trying the second example set, Octave
>>> crashes hard on the poly2fv call in the sixth block (subplot 2, 3, 6),
>>> both on Linux and Windows.
>>> Can you manage to fix that, please?
>> Dear Philip,
>>
>> I don't think you need to install additional boost stuff alongside the
>> header files.
>> This means that the dissolve header file that is extracted from the Boost
>> Geometry 1.60 extensions isn't working with Boost Geometry 1.61 .
>> IMO,I can add the new version of dissolve header file that is part of the
>> Boost Geometry 1.61 extensions to the package and add some checks to
>> choose between the two header files.
>> So,what do you think?
>
> That might be a good idea. But see below as regards boost versions.
>
>
>> I tried the Matworks second test and it's working smoothly.
>> So,I attached a screenshot of the test/output figures.
>> Screenshot_from_2016-08-20_05-32-50.png
>> <http://octave.1599824.n4.nabble.com/file/n4679337/Screenshot_from_2016-08-20_05-32-50.png> 
>
> To be sure I uninstalled boost-1.61.0 and downgraded to / installed
> boost-1.60.0
> Sure enough, the Matlab example went without a hitch then.
>
> It not very reassuring that the polygon operations do not work with current
> boost but only with the previous version..... :-)
> I'd prefer that the polygon operations work with newest boost versions.
>
> BTW
> I find that installing geometry-3.0.0 (beta) from your github account takes
> a very long time to finish (some minutes) *after* the last compile and copy
> step. Would you by any chance know what is happening then? Just copying the
> binary modules into place shouldn't need that much time IMO.
> But maybe it is just the polybool compile step that takes so long;
> installing packages is multi-threaded these days so it could be that the
> copy step is just hanging until polybool compilation is finalized.
>
> Anyway, as I announced earlier this week I've made a start with comparing
> the various function versions (ispolycw etc.) to see which ones would be the
> best and how those could be incorporated in the geometry/mapping packages.
>
> Philip
>
>
>
>
> --
> View this message in context: http://octave.1599824.n4.nabble.com/GSoc-2016-Final-Reviews-required-tp4679299p4679342.html
> Sent from the Octave - Maintainers mailing list archive at Nabble.com.
>

I think we still need to make another tweak to the makefile.in. The only feature of the polygons that is version dependent is the self-intersection correction (they call it the “dissolve” algorithm). Everything else should work as-is. The dissolve function is currently in the development repositories, but not in the releases. I was under the impression that the 1.60 dissolve worked for both 1.60 and 1.61, but I guess that isn’t the case.

There should be two scenarios, though both should work with different levels of functionality:

1) all functions should work without self-intersection correction for Boost.Geometry > 1.57
2) all functions should work with self-intersection correction for Boost.Geometry > 1.60

I will take a quick look and help Amr figure out why it isn’t doing the conditional compile of the self-intersection correction.
The crash with poly2fv in case of boost 1.61 (see my earlier reply) also needs some attention.
If that is due to erroneous input in turn due to polybool yielding erroneous output due to whatever, it indicates that poly2fv needs more robust error checking and/or more robust error catching. Crashes just should not happen.
Admittedly I could have compared polybool's output for both boost versions I tried (1.61 and 1.60) but that didn't occur to me at the time :-(
If that crash is more directly related to boost version 1.61 (i.e., if poly2fv depends on the boost library as well) that would be a more serious issue.

On another note, does polybool also feature clipping lines rather than polygons? That is a thing that Clipperlib can do and that I also often use.

Anyway, on the positive side, polybool and poly2fv seem to operate very fast :-)   Drawing polygons with holes is a lot less complicated now. Nice!

Philip
Reply | Threaded
Open this post in threaded view
|

Re: GSoc 2016: Final Reviews required

PhilipNienhuis
PhilipNienhuis wrote
John Swensen-3 wrote
<snip>

I think we still need to make another tweak to the makefile.in. The only feature of the polygons that is version dependent is the self-intersection correction (they call it the “dissolve” algorithm). Everything else should work as-is. The dissolve function is currently in the development repositories, but not in the releases. I was under the impression that the 1.60 dissolve worked for both 1.60 and 1.61, but I guess that isn’t the case.

There should be two scenarios, though both should work with different levels of functionality:

1) all functions should work without self-intersection correction for Boost.Geometry > 1.57
2) all functions should work with self-intersection correction for Boost.Geometry > 1.60

I will take a quick look and help Amr figure out why it isn’t doing the conditional compile of the self-intersection correction.
The crash with poly2fv in case of boost 1.61 (see my earlier reply) also needs some attention.
If that is due to erroneous input in turn due to polybool yielding erroneous output due to whatever, it indicates that poly2fv needs more robust error checking and/or more robust error catching. Crashes just should not happen.
Admittedly I could have compared polybool's output for both boost versions I tried (1.61 and 1.60) but that didn't occur to me at the time :-(
If that crash is more directly related to boost version 1.61 (i.e., if poly2fv depends on the boost library as well) that would be a more serious issue.
I compared the polybool output from the last item of the second example on Mathworks polybool web page (http://nl.mathworks.com/help/map/ref/polybool.html) for both polybool built with boost-1.60 and with boost-1.61. See attached .mat file.

Indeed the output cell arrays are quite different.

Feeding the Fx, Fy arrays from polybool/boost 1.60 to poly2fv in a geometry package built with boost 1.61 gives a nice plot and no crash.
So that confirms my thinking:

- Ideally, polybool should (IMO) be able to be built and operate properly with boost <= 1.60 and boost >= 1.61
As boost.geometry currently is at 1.61, my suggestion would be to require boost 1.61 as minimum version, but that would require additional work on polybool()

- poly2fv should merely have more robust error checking & error catching (exception handling). E.g.,

>> poly2fv ('a', struct ("b", 3))
error: invalid conversion from string to real N-D array
>> poly2fv (9, struct ("b", 3))
error: octave_base_value::array_value(): wrong type argument 'scalar struct'


JuanPi, how would  you like development to proceed further?
Amr has finished his work but polishing the code for error checks etc. is still required. Such (input) error checks do not look very difficult and can be copied from other code in octave.
The error catching (= avoiding crashes) is probably more challenging.

Philip

polbl_ML_2nd-ex.mat

Reply | Threaded
Open this post in threaded view
|

Re: GSoc 2016: Final Reviews required

Juan Pablo Carbajal-2
On Sun, Aug 21, 2016 at 11:35 AM, PhilipNienhuis <[hidden email]> wrote:
> JuanPi, how would  you like development to proceed further?
> Amr has finished his work but polishing the code for error checks etc. is
> still required. Such (input) error checks do not look very difficult and can
> be copied from other code in octave.
> The error catching (= avoiding crashes) is probably more challenging.

Hi,

I will keep apologizing for my lack of reaction.
I think the best is to merge with geometry asap (there is also APi
issues to solve) and continue fixing from there on.

I could make a bitbucket repo to ease the merging, or somebody with
push rights to SF could do it, if the time is pressing and you can't
wait for a window in my schedule.

Cheers

Reply | Threaded
Open this post in threaded view
|

Re: GSoc 2016: Final Reviews required

Philip Nienhuis
Juan Pablo Carbajal-2 wrote
On Sun, Aug 21, 2016 at 11:35 AM, PhilipNienhuis <[hidden email]> wrote:
> JuanPi, how would  you like development to proceed further?
> Amr has finished his work but polishing the code for error checks etc. is
> still required. Such (input) error checks do not look very difficult and can
> be copied from other code in octave.
> The error catching (= avoiding crashes) is probably more challenging.

Hi,

I will keep apologizing for my lack of reaction.
I think the best is to merge with geometry asap (there is also APi
issues to solve) and continue fixing from there on.

I could make a bitbucket repo to ease the merging, or somebody with
push rights to SF could do it, if the time is pressing and you can't
wait for a window in my schedule.
Amr already "merged", his repo contains a complete geometry-3.0.0 AFAICS

Is there really so much hurry? Any insights on when you will have time for some review?

I can do some basic stuff like pushing to the OF repo. But my time is limited as well, so it will be by little parts at a time in the next weeks.
There's also the divide between mapping and geometry and some duplicate functionality; I can sort that out for you as well then.

Philip
 
Reply | Threaded
Open this post in threaded view
|

Re: GSoc 2016: Final Reviews required

John Swensen-3

> On Aug 22, 2016, at 11:48 AM, Philip Nienhuis <[hidden email]> wrote:
>
> Juan Pablo Carbajal-2 wrote
>> On Sun, Aug 21, 2016 at 11:35 AM, PhilipNienhuis &lt;
>
>> pr.nienhuis@
>
>> &gt; wrote:
>>> JuanPi, how would  you like development to proceed further?
>>> Amr has finished his work but polishing the code for error checks etc. is
>>> still required. Such (input) error checks do not look very difficult and
>>> can
>>> be copied from other code in octave.
>>> The error catching (= avoiding crashes) is probably more challenging.
>>
>> Hi,
>>
>> I will keep apologizing for my lack of reaction.
>> I think the best is to merge with geometry asap (there is also APi
>> issues to solve) and continue fixing from there on.
>>
>> I could make a bitbucket repo to ease the merging, or somebody with
>> push rights to SF could do it, if the time is pressing and you can't
>> wait for a window in my schedule.
>
> Amr already "merged", his repo contains a complete geometry-3.0.0 AFAICS
>
> Is there really so much hurry? Any insights on when you will have time for
> some review?
>
> I can do some basic stuff like pushing to the OF repo. But my time is
> limited as well, so it will be by little parts at a time in the next weeks.
> There's also the divide between mapping and geometry and some duplicate
> functionality; I can sort that out for you as well then.
>
> Philip
>
>
>
>
> --
> View this message in context: http://octave.1599824.n4.nabble.com/GSoc-2016-Final-Reviews-required-tp4679299p4679410.html
> Sent from the Octave - Maintainers mailing list archive at Nabble.com.
>

I have been asking Amr for at least two more items before I pass off on the GSoC:

1) include all the benchmarking tests that he converted from the ClipperLib website into the repository and his other basic tests. We can potentially run these as part of a ‘make test’ target.
2) Make a really nice final blog post that shows visually all the functionality that was added. This involves a couple of set of demonstration images showing the two input polygons used and the results of UNION, INTERSECT, DIFFERENCE, XOR. Since a lot of people aren’t going to wade through C++ code to see what was accomplished (or even read the Readme.md in the repository), a really well-documented final blog post will let Octave users see what has been added.

John S.


Reply | Threaded
Open this post in threaded view
|

Re: GSoc 2016: Final Reviews required

Juan Pablo Carbajal-2
On Mon, Aug 22, 2016 at 11:42 PM, John Swensen <[hidden email]> wrote:

>
>> On Aug 22, 2016, at 11:48 AM, Philip Nienhuis <[hidden email]> wrote:
>>
>> Juan Pablo Carbajal-2 wrote
>>> On Sun, Aug 21, 2016 at 11:35 AM, PhilipNienhuis &lt;
>>
>>> pr.nienhuis@
>>
>>> &gt; wrote:
>>>> JuanPi, how would  you like development to proceed further?
>>>> Amr has finished his work but polishing the code for error checks etc. is
>>>> still required. Such (input) error checks do not look very difficult and
>>>> can
>>>> be copied from other code in octave.
>>>> The error catching (= avoiding crashes) is probably more challenging.
>>>
>>> Hi,
>>>
>>> I will keep apologizing for my lack of reaction.
>>> I think the best is to merge with geometry asap (there is also APi
>>> issues to solve) and continue fixing from there on.
>>>
>>> I could make a bitbucket repo to ease the merging, or somebody with
>>> push rights to SF could do it, if the time is pressing and you can't
>>> wait for a window in my schedule.
>>
>> Amr already "merged", his repo contains a complete geometry-3.0.0 AFAICS
>>
>> Is there really so much hurry? Any insights on when you will have time for
>> some review?
>>
>> I can do some basic stuff like pushing to the OF repo. But my time is
>> limited as well, so it will be by little parts at a time in the next weeks.
>> There's also the divide between mapping and geometry and some duplicate
>> functionality; I can sort that out for you as well then.
>>
>> Philip
>>
>>
>>
>>
>> --
>> View this message in context: http://octave.1599824.n4.nabble.com/GSoc-2016-Final-Reviews-required-tp4679299p4679410.html
>> Sent from the Octave - Maintainers mailing list archive at Nabble.com.
>>
>
> I have been asking Amr for at least two more items before I pass off on the GSoC:
>
> 1) include all the benchmarking tests that he converted from the ClipperLib website into the repository and his other basic tests. We can potentially run these as part of a ‘make test’ target.
> 2) Make a really nice final blog post that shows visually all the functionality that was added. This involves a couple of set of demonstration images showing the two input polygons used and the results of UNION, INTERSECT, DIFFERENCE, XOR. Since a lot of people aren’t going to wade through C++ code to see what was accomplished (or even read the Readme.md in the repository), a really well-documented final blog post will let Octave users see what has been added.
>
That can also be added to http://wiki.octave.org/Geometry_package
> John S.
>
>