Re: How to simplify pkg.m (was Re: [OctDev] Patch for the Image package (changed behavior of ismatrix))

[Juan Pablo Carbajal]

On Wed, Mar 14, 2012 at 5:48 PM, c. <address@hidden> wrote:
>
> OOPS, it seems I forgot to CC the list.
>
> Begin forwarded message:
>
>> From: "c." <address@hidden>
>> Date: 14 March 2012 13:14:13 GMT+01:00
>> To: Søren Hauberg <address@hidden>
>> Cc: Thomas Weber <address@hidden>, Jordi Gutiérrez Hermoso <address@hidden>
>> Subject: How to simplify pkg.m (was Re: [OctDev] Patch for the Image package 
>> (changed behavior of ismatrix))
>>
>>
>> On 14 Mar 2012, at 11:27, Søren Hauberg wrote:
>>
>>>
>>> On Mar 14, 2012, at 11:03 AM, c. wrote:
>>>
>>>>
>>>> On 14 Mar 2012, at 00:45, Thomas Weber wrote:
>>>>
>>>>> On Tue, Mar 13, 2012 at 10:47:23PM +0100, c. wrote:
>>>>>> or test blocks in .cc files could be automatically extracted and saved 
>>>>>> in the tests/
>>>>>> directory upon installation as is currently done for //PKG_ADD / 
>>>>>> //PKG_DEL directives.
>>>>>
>>>>> I'm specifically against this. Have you looked at pkg.m? More than 2400
>>>>> lines of code. Don't add more logic to it.
>>>>>
>>>>>    Thomas
>>>>
>>>> I agree that pkg.m is already overly complicated I am preparing a patch to 
>>>> clean it up a little bit,
>>>> especially I think it would make it much more readable if all subfunctions 
>>>> were separated and put
>>>> into different files in the private directory. I'll move further 
>>>> discussion of this to the octave
>>>> maintainers mailing list.
>>>
>>> From what I remember, the complexity (which I agree is present) is due to 
>>> two things:
>>>
>>> * Actual complexities in determining installation paths that are relevant 
>>> to different use-cases.
>>> * String handling.
>>>
>>> Regarding the latter point, then I ended up having to write a bunch of 
>>> string handling functions as part of 'pkg' as the necessary functions were 
>>> not available in Octave. I think one low hanging fruit in cleaning up 'pkg' 
>>> is to improve the string handling functions in Octave and use these 
>>> directly in 'pkg'. This would also have the added benefit of improving the 
>>> (rather weak) string handing API's in Octave.
>>>
>>> However, 'pkg' would still be overly complicated after such a change, but 
>>> at least the code would be simpler…
>>>
>>> Søren
>>
>> Indeed functions like "split_by", "split" or "rsplit" could probably 
>> eliminated,
>> I'll start looking into it, if someone is willing to help please let me know.
>> c.
>>
>

Hi,
Carnë and my self have a project to work on pkg.m, but is in stand-by.
Please do consider us (at least me) among the potential collaborators.
I would also point that we have a project in GSoC2012 directly
addressing this.
http://octave.org/wiki/index.php?title=GSoC_Project_Ideas#Installation_of_packages

You could add yourself to the list of potential mentors.

Regards,


-- 
M. Sc. Juan Pablo Carbajal
-----
PhD Student
University of Zürich
http://ailab.ifi.uzh.ch/carbajal/