[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.
>
- Fwd: How to simplify pkg.m (was Re: [OctDev] Patch for the Image package (changed behavior of ismatrix)),
c. <=