Bug in function gzip...

[Ben Abbott]

On Jan 7, 2008, at 5:09 PM, David Bateman wrote:

> Ben Abbott wrote:
>> On Jan 7, 2008, at 1:06 AM, Thomas Treichl wrote:
>>
>>> Got it (just before I was getting crazy ;). I changed the line #104
>>> in function
>>> 'myfileparts'
>>>
>>> from
>>> [d, f, ext] = cellfun (@(x) fileparts (x), x, "UniformOutput",
>>> false);
>>>
>>> to
>>> [d, f, ext] = cellfun (@fileparts, x, "UniformOutput", false);
>>>
>>> and I got a gziped file. The same implementation also works for a
>>> cell-array of
>>> strings input argument to 'gzip'. However, I still think that this
>>> is not the
>>> real problem - but if you say yes this is the real problem then I
>>> prepare a patch.
>>>
>>> Some other inline tests that I could run where I maybe can see
>>> somekind of the
>>> same output? I'm currently out of ideas because all other cellfun
>>> lines that I
>>> can find in the codes do work perfectly.
>>>
>>
>> When I make the same change, I get the error below
>>
>> error: can't perform indexing operations for <unknown type> type
>>
>> Ben
>>
> If this is a difference between 3.0.0 and 3.0.0+ then I'd say its a
> difference in the treatment of anonymous versus normal function  
> handles
> in the object classes code. It looks like there is a nasty bug in  
> there
> somewhere as the two versions of the cellfun call above should produce
> the same result.
>
> D.

You deduction appears to be correct.

I had no trouble with the released 3.0.0, but since building with  
today's cvs sources, I get the error as well.

octave:1> file = tilde_expand ('~/.octaverc');
octave:2> gzip(file)
error: invalid number of output arguments for expression X = RHS
error: called from `?unknown?'
error: cellfun: too many output arguments
error: called from `myfileparts' in file `/Users/bpabbott/Documents/ 
Octave/gzip/gzip.m'
error: evaluating if command near line 48, column 7
error: evaluating if command near line 31, column 3
error: called from `gzip' in file `/Users/bpabbott/Documents/Octave/ 
gzip/gzip.m'

Ben