octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: octclip and geometry package


From: José Luis García Pallero
Subject: Re: octclip and geometry package
Date: Thu, 20 Jun 2013 14:23:46 +0200

2013/6/20 Juan Pablo Carbajal <address@hidden>
On Thu, Jun 20, 2013 at 1:59 PM, José Luis García Pallero
<address@hidden> wrote:
> 2013/6/20 Carnë Draug <address@hidden>
>>
>> On 20 June 2013 12:47, José Luis García Pallero <address@hidden>
>> wrote:
>> > 2013/6/20 Carnë Draug <address@hidden>
>> >>
>> >> On 20 June 2013 11:52, José Luis García Pallero <address@hidden>
>> >> wrote:
>> >> > 2013/6/20 Juan Pablo Carbajal <address@hidden>
>> >> >>
>> >> >> On Thu, Jun 20, 2013 at 5:01 AM, Carnë Draug <address@hidden>
>> >> >> > Also, we are moving all of Octave forge to individual mercurial
>> >> >> > repos.
>> >> >> > I noticed that you already have one in bitbucket. When you created
>> >> >> > it,
>> >> >> > you didn't convert the old history. If you are interested, I could
>> >> >> > get
>> >> >> > you a mercurial repo with all of the old history until the point
>> >> >> > they
>> >> >> > diverge. I'm guessing it should be possible to graft your new
>> >> >> > history
>> >> >> > on it.
>> >> >
>> >> > Yes, the main development was done using the mercurial bitbucket
>> >> > repo.
>> >> > In
>> >> > this repository is all the history, from its creation in may 2005
>> >>
>> >> The first commit of that repo is May 2011. I noticed the date 2005 on
>> >> the source code and assumed that there was history before that. I just
>> >> noticed that the SVN repository also starts on 2011. I will remove the
>> >> directory main/octclip in the svn repository and upload a clone of
>> >> your mercurial repo. Is that ok?
>> >
>> >
>> > Also I have another bitbucker repo for the package OctPROJ:
>> >
>> > https://bitbucket.org/jgpallero/octproj/src
>> > https://bitbucket.org/jgpallero/octclip/src
>>
>> I will do the same to the octproj repository. Also, I have noticed
>> that you have been committing the pdf that is generated from the tex
>> source. I will filter that file out and update the hgignore file. Is
>> that ok?
>
>
> OK. No problem.
>
>>
>>
>> Carnë
>
>
>
>
> --
> *****************************************
>
> José Luis García Pallero
> address@hidden
> (o<
> / / \
> V_/_
> Use Debian GNU/Linux and enjoy!
> *****************************************

Hi,

Here is the reference mail exchange
http://octave.1599824.n4.nabble.com/Problem-with-octclip-td4634405.html#a4634413

My comments:
1. It is very hard to find functions in Octave-Forge and many packages
obscure names; "octclip" being one of those names, i.e. a user
searching for useful geometrical functions may not look into octclip
cause it doesn't sound like geometry.
2. In general I like "search not order" but in OF we do not have good
search functionalities. Until we get them packages should try to be
organized thematically, or as transparent as possible (yes, "ocs" I am
looking at you :D ).
3. Since we are moving into HG having sub-repos is much easier than it
was in svn, so from the maintainer perspective it should be completely
transparent to maintain only a subfoder/subrepo. It was already super
simple in svn (just checkout the sub-folder!) but seems this wasn't
clear enough.
4. If you are going to revert and separate "octclip" from "geometry"
at least change its name to "polygonclip" or something like that.
Though agian, since "octclip" is just one function, I see no point on
having a separate package.
5. There is no interdependence between "octclip" and "geometry",
however if we are going to start adding "recommended" to the scene,
this might become messy.

In short: I oppose to having octclip as a separate package (there is
no more complexity for the maintainer having them together). However
since I was worry about visibility of octclip, if you want to separate
go ahead, it is really no my problem :D

Cheers

Hello:

Sorry, I didn't remember that mail, but it's right, I have saud that I have no problem to integrate OctCLIP into geometry. Your reasons have convinced me, so I'm not opposed to the integration.
But in order to the package maintaining, I can only assure support for my code, i. e. the code on https://bitbucket.org/jgpallero/octclip
Is there any way to do the changes (if they are needed) on https://bitbucket.org/jgpallero/octclip and clone them on the repo for geometry?
Anyway, I will maintain my bitbucket repo as no Octave Forge official, so my package will maintain the OctCLIP name and the function will maintain the oc_polybool() name. I suppose in geometry it is not a problem to write a *.m wrapper that calls internally the oc_polybool or its C++ countepart

Cheers

--
*****************************************
José Luis García Pallero
address@hidden
(o<
/ / \
V_/_
Use Debian GNU/Linux and enjoy!
*****************************************

reply via email to

[Prev in Thread] Current Thread [Next in Thread]