octave-maintainers
[Top][All Lists]
Advanced

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

operator< for caseless_str


From: Jordi Gutiérrez Hermoso
Subject: operator< for caseless_str
Date: Sat, 14 May 2011 15:01:13 -0500

2011/5/13 Robert T. Short <address@hidden>:
> Jordi Gutiérrez Hermoso wrote:
>>
>> Should we start thinking about a 3.4.1 release? Perhaps release in a
>> month or so?
>
> I get an error when I try to build the stable branch.  It doesn't occur when
> I build the development branch.
>
> This is on a debian linux system, tip 68a59630798d
>
>
> ./munge-texi ../.. ../../scripts/DOCSTRINGS ../../src/DOCSTRINGS < var.txi >
> var.texi-t
> mv var.texi-t var.texi
> ../../run-octave -f -q -H -p . --eval "geometryimages ('voronoi', 'txt');"
> error: invalid value = <custom>
> error: set: invalid value for radio property "papertype" (value = <custom>)
> error: error setting default property papersize
> error: __go_figure__: failed to create figure handle
> error: called from:
> error:
> /home/rtshort/Mirrored/octave/Sources/octave-full/scripts/plot/figure.m at
> line 66, column 9
> error:
> /home/rtshort/Mirrored/octave/Sources/octave-full/doc/interpreter/geometryimages.m
> at line 128, column 5
> error:
> /home/rtshort/Mirrored/octave/Sources/octave-full/doc/interpreter/geometryimages.m
> at line 22, column 3
> make[3]: *** [voronoi.txt] Error 1
> make[3]: Leaving directory
> `/home/rtshort/Mirrored/octave/Sources/octave-full/doc/interpreter'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory
> `/home/rtshort/Mirrored/octave/Sources/octave-full/doc'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory
> `/home/rtshort/Mirrored/octave/Sources/octave-full'
> make: *** [all] Error 2

Yes, looks like 68a59630798d broke something in stable. I just managed
to successfully compile 2c54fde0f397. The following two lines appear
to be what breaks in 68a59630798d:

     set (0, "defaultfigurepapertype", "<custom>");
     f = figure (1);

After some printf debugging, I managed to conclude that the algorithm
in op< implemented therein is buggy. Look:

     http://codepad.org/aQsNx53a

Clearly "queue" and "cancel" are not both greater than equal to each
other lexicographically. Since this is happening, std::set concludes
tha the two are the same so only inserts the first one of them into
the set, which results in certain property values being taken as
invalid, as the above error shows.

Sadly, whatever state of mind David Bateman was in when he wrote this
is the same one I'm in right now, because I can't see the bug.

- Jordi G. H.


reply via email to

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