octave-maintainers
[Top][All Lists]
Advanced

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

Fwd: How to simplify pkg.m (was Re: [OctDev] Patch for the Image package


From: c.
Subject: Fwd: How to simplify pkg.m (was Re: [OctDev] Patch for the Image package (changed behavior of ismatrix))
Date: Wed, 14 Mar 2012 17:48:10 +0100

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



reply via email to

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