lib2geom-devel — development discussion

Re: [Lib2geom-devel] [Inkscape-devel] lib2geom status

[Bryce H. <br...@br...>]

On Wed, Nov 21, 2007 at 11:43:57AM -0800, Ted Gould wrote:
> On Wed, 2007-11-21 at 20:32 +0100, J.B...@ew... wrote:
> > I don't think we want a release now, so we can quickly address issues
> > that surface. I think it is best to keep 2geom inside Inkscape code
> > for 0.46, and have a good and nice 2geom release for 0.47. This way we
> > can profit from bleeding edge 2geom which atm is nicer than a release
> > will be imho.
> > I am fine by copying 2geom code to Inkscape for now :-)
> 
> We can for development, but I'd prefer not to for release.  Unless the
> lib2geom folks are unwilling to release it, I'd prefer to go that route.
> 
> The biggest advantage this gives us is that they can fix bugs
> independent of Inkscape.  So, if the intersection routine turns out to
> be numerically unstable in a certain situation a spin of lib2geom can be
> done without having to do a release of Inkscape.  And Inkscape users
> still get the benefit.

I definitely agree with Ted.  There are several libraries copied into
the tree that probably ought to be broken out where possible.  Other
projects like Xorg, OpenOffice, etc. demonstrate the many downsides to
monolithic applications, and the benefits to both users and developers
of proper modularization.

I also definitely agree that if there's bugs in lib2geom, rolling a new
release of it would be much, much preferable to having to roll a new
Inkscape.

Bryce

Re: [Lib2geom-devel] [Inkscape-devel] lib2geom status

[Ted G. <te...@go...>]

On Wed, 2007-11-21 at 20:32 +0100, J.B...@ew... wrote:
> I don't think we want a release now, so we can quickly address issues
> that surface. I think it is best to keep 2geom inside Inkscape code
> for 0.46, and have a good and nice 2geom release for 0.47. This way we
> can profit from bleeding edge 2geom which atm is nicer than a release
> will be imho.
> I am fine by copying 2geom code to Inkscape for now :-)

We can for development, but I'd prefer not to for release.  Unless the
lib2geom folks are unwilling to release it, I'd prefer to go that route.

The biggest advantage this gives us is that they can fix bugs
independent of Inkscape.  So, if the intersection routine turns out to
be numerically unstable in a certain situation a spin of lib2geom can be
done without having to do a release of Inkscape.  And Inkscape users
still get the benefit.

		--Ted

Re: [Lib2geom-devel] [Inkscape-devel] lib2geom status

[<J.B...@ew...>]

Perhaps superfluous but still: *we can use 2geom inside Inkscape already =
without problem!!!*


Ted Gould wrote:
>=20
> On Tue, 2007-11-20 at 20:23 -0500, MenTaLguY wrote:
> > On Tue, 2007-11-20 at 15:50 -0800, Ted Gould wrote:
> > > Now that we're including a large part of lib2geom for LPE anyway;=20
> > > what else can we use it for?  I'm unsure of the status of=20
> the whole library.
> > > One feature that I hear alot about when talking to people is the=20
> > > inset/outset function in Inkscape being "less than perfect."  I=20
> > > think this was on the TODO for lib2geom, is it done?
> >=20
> > The pieces are there, although I think it'll take setting=20
> up Inkscape=20
> > to use it to find any remaining gaps in functionality.
>=20
> So I guess what we need is a lib2geom release so that we can=20
> get it packaged and linked to correctly?  Then we can start=20
> to see where that breaks?

I don't think we want a release now, so we can quickly address issues =
that surface. I think it is best to keep 2geom inside Inkscape code for =
0.46, and have a good and nice 2geom release for 0.47. This way we can =
profit from bleeding edge 2geom which atm is nicer than a release will =
be imho.
I am fine by copying 2geom code to Inkscape for now :-)

(note that early on in LPE development i did have 2geom linked in as =
separate lib, 'release like'. It is not too much of a change)

On our wiki, we have started a help page where people can ask questions =
and put answers. Hopefully this will grow to a somewhat complete 2geom =
guide.
http://wiki.inkscape.org/wiki/index.php/WorkingWith2GeomFAQ

Ciao,
Johan

Re: [Lib2geom-devel] [Inkscape-devel] lib2geom status

[Ted G. <te...@go...>]

On Wed, 2007-11-21 at 01:06 +0100, J.B...@ew... wrote:
> Ted Gould wrote:
> > Now that we're including a large part of lib2geom for LPE=20
> > anyway; what else can we use it for? =20
>=20
> It is being used for snapping (right Diederik? :-). Also I think it was
> planned to use it for the 3D box tool.

Anyone know how hard it'd be to tie in the inset/outset functions to use
it?  Is it better than what we have (I hope so :) )?

		--Ted

Re: [Lib2geom-devel] [Inkscape-devel] lib2geom status

[Ted G. <te...@go...>]

On Tue, 2007-11-20 at 20:23 -0500, MenTaLguY wrote:
> On Tue, 2007-11-20 at 15:50 -0800, Ted Gould wrote:
> > Now that we're including a large part of lib2geom for LPE anyway; what
> > else can we use it for?  I'm unsure of the status of the whole library.
> > One feature that I hear alot about when talking to people is the
> > inset/outset function in Inkscape being "less than perfect."  I think
> > this was on the TODO for lib2geom, is it done?
>=20
> The pieces are there, although I think it'll take setting up Inkscape to
> use it to find any remaining gaps in functionality.

So I guess what we need is a lib2geom release so that we can get it
packaged and linked to correctly?  Then we can start to see where that
breaks?

		--Ted

Re: [Lib2geom-devel] [Inkscape-devel] lib2geom status

[<J.B...@ew...>]

Ted Gould wrote:
>
> Now that we're including a large part of lib2geom for LPE=20
> anyway; what else can we use it for? =20

It is being used for snapping (right Diederik? :-). Also I think it was
planned to use it for the 3D box tool.

> I'm unsure of the status of the whole library.

CC'ing to lib2geom lib...@li...

- Johan

[Lib2geom-devel] 2Geom assertions => exceptions

[<J.B...@ew...>]

Hi all,

I've made a nice system to replace the 2geom assertions I think (this is
what makes LPE crash in at least one case). Please have a look of what I
coded into the 2geom dir of Inkscape now [1].=20

My next step is to change asserts into assert_invariants, such that an
exception is thrown instead of a terminate(). I'd also like to splice
the exception stuff from utils.h into a separate file.

Planning on moving this to lib2geom svn head very soon; just give a
shout when it's not any good!
=20
Cheers,
Johan

[1]:
http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/2
geom/utils.h?revision=3D16507&view=3Dmarkup

[Lib2geom-devel] [ 1833272 ] Compose hits assertion

[<J.B...@ew...>]

 Please have a look at the bugreport I filed :

http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1833272&grou=
p_i
d=3D167845&atid=3D844560

The assertion-checks are good, what I don't like as much is that
Inkscape will crash when such an assertion is hit :-( I'd rather have an
exception that I can catch and react upon! (sorry for mentioning this
again, please reconsider!) Now Inkscape's pattern-along-path is
crash-buggy, which it should not be. Inkscape already catches 2geom
exceptions, and then just terminates LPE calculation. Then the user can
fix the error, without having lost an hour of work. :-)

Cheers,
Johan


> -----Original Message-----
> From: lib...@li...=20
> [mailto:lib...@li...] On=20
> Behalf Of mgsloan
> Sent: donderdag 26 juli 2007 23:33
> To: Pajarico
> Cc: Lib...@li...
> Subject: Re: [Lib2geom-devel] Warnings compiling lib2geom SVN
>=20
> Alright, I've fixed it again.  The reason for these errors is=20
> that min/max only work when the types of both sides are the=20
> same.  I guess your compiler is just a bit more of a stickler=20
> - ours appear to coerce.  Anyway, it's definitely good to get=20
> these fixed.  Could you fix them yourself and send a patch? =20
> Just look at the type signature given in the error (the=20
> warnings don't matter), and add a conversion operator in the=20
> code as required.  For example, the most recent one was=20
> max(unsigned int, long unsigned int), so I added (unsigned)=20
> to the beginning of the second operand.
>=20
> Thanks,
> Michael Sloan
>=20
> On 7/26/07, Pajarico <paj...@gm...> wrote:
> > Ok, now I'm getting this:
> >
> > lxuser@localhost ~/compilation/lib2geom $ make [  3%] Generating=20
> > svg_path_parser.cpp with ragel Scanning dependencies of=20
> target 2geom [ =20
> > 7%] Building CXX object src/CMakeFiles/2geom.dir/svg-path.o
> > /home/lxuser/compilation/lib2geom/src/svg-path.h:39:=20
> warning: 'class=20
> > Geom::SVGPathSink' has virtual functions but non-virtual destructor
> > /home/lxuser/compilation/lib2geom/src/svg-path.h: In=20
> instantiation of=20
> >=20
> 'Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Pa
> > th,
> > std::allocator<Geom::Path> > > >':
> > /home/lxuser/compilation/lib2geom/src/svg-path.h:106:  =20
> instantiated from here
> > /home/lxuser/compilation/lib2geom/src/svg-path.h:54:=20
> warning: 'class=20
> >=20
> Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Pat
> > h, std::allocator<Geom::Path> > > >' has virtual functions but=20
> > non-virtual destructor
> > /home/lxuser/compilation/lib2geom/src/svg-path.h:106:=20
> warning: 'class=20
> > Geom::PathBuilder' has virtual functions but non-virtual=20
> destructor [=20
> > 11%] Building CXX object src/CMakeFiles/2geom.dir/svg-path-parser.o
> > /home/lxuser/compilation/lib2geom/src/svg-path.h:39:=20
> warning: 'class=20
> > Geom::SVGPathSink' has virtual functions but non-virtual destructor
> > /home/lxuser/compilation/lib2geom/src/svg-path.h: In=20
> instantiation of=20
> >=20
> 'Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Pa
> > th,
> > std::allocator<Geom::Path> > > >':
> > /home/lxuser/compilation/lib2geom/src/svg-path.h:106:  =20
> instantiated from here
> > /home/lxuser/compilation/lib2geom/src/svg-path.h:54:=20
> warning: 'class=20
> >=20
> Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Pat
> > h, std::allocator<Geom::Path> > > >' has virtual functions but=20
> > non-virtual destructor
> > /home/lxuser/compilation/lib2geom/src/svg-path.h:106:=20
> warning: 'class=20
> > Geom::PathBuilder' has virtual functions but non-virtual=20
> destructor [=20
> > 14%] Building CXX object src/CMakeFiles/2geom.dir/path.o [ 18%]=20
> > Building CXX object src/CMakeFiles/2geom.dir/poly.o
> > /home/lxuser/compilation/lib2geom/src/poly.h: In member=20
> function 'Poly=20
> > Poly::shifted(unsigned int) const':
> > /home/lxuser/compilation/lib2geom/src/poly.h:98: error: no matching=20
> > function for call to 'max(unsigned int, long unsigned int)'
> > make[2]: *** [src/CMakeFiles/2geom.dir/poly.o] Error 1
> > make[1]: *** [src/CMakeFiles/2geom.dir/all] Error 2
> > make: *** [all] Error 2
> >
> > 2007/7/26, mgsloan <mg...@gm...>:
> > > I think the problem is that they don't have the same=20
> type.  Probably=20
> > > our compilers figure out it needs to be cast to unsigned.  I've=20
> > > attempted to fix it in svn, and reverted some of my old changes.
> > >
> > > Hope it works,
> > > Michael Sloan
> > >
> > > On 7/24/07, Pajarico <paj...@gm...> wrote:
> > > > First, thanks for your attention. Unfortunately I get the same=20
> > > > error (the only difference is that 'min' has been replaced by=20
> > > > 'Min'). I did a 'make clean' beforehand.
> > > >
> > > > About compiler/libs incompatibility, care to elaborate?=20
> Which libs=20
> > > > could be guilty?
> > > >
> > > >
> > > > > The issue is the error on min.  The warnings are fine.
> > > > >
> > > > > This is likely due to some sort of compiler/libs=20
> > > > > incompatibility, though your list looks fine.  This=20
> is probably=20
> > > > > why we used to have custom min/max.  Anyway, I've re-added=20
> > > > > custom Min/Max to svn.  Might as well, as it might=20
> help with compatibility in the future.
> > > > >
> > > > > Hope that fixes it,
> > > > > Michael Sloan
> > > > >
> > > > > On 7/22/07, Pajarico <paj...@gm...> wrote:
> > > > > > Hi, I get this error while compiling SVN, 0.1 also=20
> does this:
> > > > > >
> > > > > > lxuser@localhost ~/compilation/lib2geom $ make [  3%]=20
> > > > > > Generating svg_path_parser.cpp with ragel Scanning=20
> > > > > > dependencies of target 2geom [  7%] Building CXX object=20
> > > > > > src/CMakeFiles/2geom.dir/svg-path.o
> > > > > > /home/lxuser/compilation/lib2geom/src/sbasis.h: In function=20
> > > > > > 'Geom::SBasis Geom::truncate(const Geom::SBasis&,=20
> unsigned int)':
> > > > > > /home/lxuser/compilation/lib2geom/src/sbasis.h:215:=20
> error: no=20
> > > > > > matching function for call to 'min(unsigned int&, size_t)'
> > > > > > /home/lxuser/compilation/lib2geom/src/svg-path.h:=20
> At global scope:
> > > > > >=20
> /home/lxuser/compilation/lib2geom/src/svg-path.h:39: warning:=20
> > > > > > 'class Geom::SVGPathSink' has virtual functions but=20
> > > > > > non-virtual destructor
> > > > > > /home/lxuser/compilation/lib2geom/src/svg-path.h: In=20
> > > > > > instantiation of=20
> > > > > >=20
> 'Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<
> > > > > > Geom::Path, std::allocator<Geom::Path> > > >':
> > > > > >=20
> /home/lxuser/compilation/lib2geom/src/svg-path.h:106:  =20
> instantiated from here
> > > > > >=20
> /home/lxuser/compilation/lib2geom/src/svg-path.h:54: warning:=20
> > > > > > 'class=20
> > > > > >=20
> Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<G
> > > > > > eom::Path, std::allocator<Geom::Path> > > >' has virtual=20
> > > > > > functions but non-virtual destructor
> > > > > >=20
> /home/lxuser/compilation/lib2geom/src/svg-path.h:106: warning:=20
> > > > > > 'class Geom::PathBuilder' has virtual functions but=20
> > > > > > non-virtual destructor
> > > > > > make[2]: *** [src/CMakeFiles/2geom.dir/svg-path.o] Error 1
> > > > > > make[1]: *** [src/CMakeFiles/2geom.dir/all] Error 2
> > > > > > make: *** [all] Error 2
> > > > > >
> > > > > >
> > > > > > This is with:
> > > > > > - amd64
> > > > > > - Gentoo Linux 2.6.20-r7
> > > > > > - gcc-4.1.2
> > > > > > - ragel-5.20
> > > > > > - cmake-2.4
> > > > > >
> > > > > > Cheers.
> > > > > >
> > > > > >=20
> --------------------------------------------------------------
> > > > > > ----------- This SF.net email is sponsored by: Splunk Inc.
> > > > > > Still grepping through log files to find problems?  Stop.
> > > > > > Now Search log events and configuration files using=20
> AJAX and a browser.
> > > > > > Download your FREE copy of Splunk now >> =20
> > > > > > http://get.splunk.com/=20
> > > > > > _______________________________________________
> > > > > > Lib2geom-devel mailing list
> > > > > > Lib...@li...
> > > > > > https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
> > > > > >
> > > > >
> > > >
> > >
> >
>=20
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and=20
> a browser.
> Download your FREE copy of Splunk now >> =20
> http://get.splunk.com/ _______________________________________________
> Lib2geom-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
>=20

Re: [Lib2geom-devel] Definition of "near" by windef.h

[MenTaLguY <me...@ry...>]

On Fri, 9 Nov 2007 23:33:13 +0100, J.B...@ew... wrote:
> are_near
> is_near 

are_near would be fine (I prefer predicates to have "to be" in the name
anyway)

-mental

Re: [Lib2geom-devel] Definition of "near" by windef.h

[njh <nj...@nj...>]

On Fri, 9 Nov 2007, MenTaLguY wrote:

> Well, the problem is windef.h polluting the symbol namespace; it isn't
> really an Inkscape or a 2geom issue.  But given things as they are,
> I think the correct solution is to pick a different name for 2geom's
> near function.
>
> Any suggestions?

scanty?

njh

Re: [Lib2geom-devel] Definition of "near" by windef.h

[<J.B...@ew...>]

are_near
is_near=20
?=20

> -----Original Message-----
> From: MenTaLguY [mailto:me...@ry...]=20
> Sent: vrijdag 9 november 2007 23:28
> To: Engelen, J.B.C. (Johan)
> Cc: lib...@li...
> Subject: Re: [Lib2geom-devel] Definition of "near" by windef.h
>=20
> Well, the problem is windef.h polluting the symbol namespace;=20
> it isn't really an Inkscape or a 2geom issue.  But given=20
> things as they are, I think the correct solution is to pick a=20
> different name for 2geom's near function.
>=20
> Any suggestions?
>=20
> -mental
>=20
>=20
>=20

Re: [Lib2geom-devel] Definition of "near" by windef.h

[MenTaLguY <me...@ry...>]

Well, the problem is windef.h polluting the symbol namespace; it isn't
really an Inkscape or a 2geom issue.  But given things as they are,
I think the correct solution is to pick a different name for 2geom's
near function.

Any suggestions?

-mental

[Lib2geom-devel] Definition of "near" by windef.h

[<J.B...@ew...>]

Hi all,

For some files, Inkscape includes "windef.h" which defines 'near':

#define near

This causes compile problems with the inline 'near' functions in coord.h
and point.h. This is the solution I have made in inkscape SVN in coord.h
and point.h:

#ifdef near
#define lib2geom_near_save near
#undef near
#endif

//IMPL: NearConcept
inline bool near(Coord a, Coord b, double eps=3DEPSILON) { return
fabs(a-b) <=3D eps; }

#ifdef lib2geom_near_save
#define near lib2geom_near_save
#undef lib2geom_near_save
#endif

What would be the best way to do this? In Inkscape code? Or in 2geom
code? (note that 2geom code is now incompatible with windef.h)

Thanks,
Johan

Re: [Lib2geom-devel] Intersection

[Diederik v. L. <ma...@di...>]

njh wrote:
> and the reason I implemented the quadtree-like database.

Never heard of a quadtree-like database before, but Wikipedia again 
proved to be very helpful ;-)

> There are really only three approaches to curve-curve intersection:
> * subdivision with accceleration (which is what we do)
> * transform to sylvester matrix or resultant form and do poly root 
> finding/eigenvalue decomposition.
> * convergent iterative approximation such as NR or GNR
>
> The first two are robust (will find the same number of roots and 
> roughly the right positions) at a cost of more computation.  The last 
> can be faster but gives no guarantees about the number found.  I have 
> implemented all three but found that the performance advantages of the 
> last two are outweighed by their poor worst case and inexact nature 
> respectively.

I'm impressed!

> Well for grids you would use roots instead.

Thanks for the hint. I've now got a feeling how to handle snapping of 
intersections. Let's see how far I can get with this...

Diederik

Re: [Lib2geom-devel] Intersection

[njh <nj...@nj...>]

On Tue, 2 Oct 2007, Diederik van Lierop wrote:

> Hi All,
>
> Does lib2geom currently provide a way to efficiently calculate the
> intersection of two Bezier paths? I've browsed through the code, but
> only found path_intersection so far. I haven't tested it, but it looks
> quite slow as it first divides one of the paths in 2^12 pieces and
> subsequently tries to do a linear_intersection for each of those pieces
> to the other path.

I had a look at implementing a direct version of the bezout approach for 
sbasis last night, didn't get it working but I did add instrumentation to 
pair-intersect toy to print the number of steps required to compute the 
intersection.  For order 10 beziers and a particularly complex example 
with 8 crossings it took 240 steps - still well under the 16 million your 
suggested polyline conversion would entail.

If anyone has any ideas about efficient ways to estimate flatness of 
arbitrary order beziers, do tell.  My best guess is to compute the max 
norm of the distance from each bezier handle to i/(n-1) along the endpoint 
line segment.  Expensive...

njh

Re: [Lib2geom-devel] Intersection

[njh <nj...@nj...>]

On Tue, 2 Oct 2007, Diederik van Lierop wrote:

> Hi All,
>
> Does lib2geom currently provide a way to efficiently calculate the
> intersection of two Bezier paths? I've browsed through the code, but
> only found path_intersection so far. I haven't tested it, but it looks
> quite slow as it first divides one of the paths in 2^12 pieces and
> subsequently tries to do a linear_intersection for each of those pieces
> to the other path. That would probably be far too slow for my snapping
> purposes, or am I missing something?

You might play with the boolops, self-intersect, pair-intersect to get a 
feel for their performance.

No, it only considers potential pairs, so for a single intersection it 
might do at most 12 comparisons.  In practice it can do far less 
comparisons than this.  You should also use existing structural 
information to avoid unnecessary comparisons (we can talk about this). 
This was one of the early applications for 2geom and the reason I 
implemented the quadtree-like database.

There are really only three approaches to curve-curve intersection:
* subdivision with accceleration (which is what we do)
* transform to sylvester matrix or resultant form and do poly root 
finding/eigenvalue decomposition.
* convergent iterative approximation such as NR or GNR

The first two are robust (will find the same number of roots and roughly 
the right positions) at a cost of more computation.  The last can be 
faster but gives no guarantees about the number found.  I have implemented 
all three but found that the performance advantages of the last two are 
outweighed by their poor worst case and inexact nature respectively.

If we do end up using gsl as a dependancy I will include eigenvalue 
decomposition based approaches for both roots and curve-curve 
intersection.

New implementations are of course welcome!

> BTW, I'm asking this because I'd like to snap to intersections of guides
> with grids, but also snap objects with other objects, with guides, or
> with grids.

Well for grids you would use roots instead.  Pop into 
lib...@co... and talk to mgsloan or me.

njh

[Lib2geom-devel] Intersection

[Diederik v. L. <ma...@di...>]

Hi All,

Does lib2geom currently provide a way to efficiently calculate the 
intersection of two Bezier paths? I've browsed through the code, but 
only found path_intersection so far. I haven't tested it, but it looks 
quite slow as it first divides one of the paths in 2^12 pieces and 
subsequently tries to do a linear_intersection for each of those pieces 
to the other path. That would probably be far too slow for my snapping 
purposes, or am I missing something?

BTW, I'm asking this because I'd like to snap to intersections of guides 
with grids, but also snap objects with other objects, with guides, or 
with grids.

Regards,

Diederik

[Lib2geom-devel] Camping With lib2geom Source Code

[Sunburned S. <sun...@gm...>]

I'm going camping this weekend and I'm going to take the source code
for the quadtree spatial index in lib2geom. I'm also going to take my
900 page C++ book so that I can try to understand the lib2geom source
code. :]

I wanted to let you guys know I'm still interested in learning about
lib2geom and in contributing at some point. I'll probably have a bunch
of questions next week when I get back.

Scott Huey

Re: [Lib2geom-devel] Warnings compiling lib2geom SVN

[Pajarico <paj...@gm...>]

Thanks for the fixes. Now I can compile it fine (althought I don't
know if it works because I'm testing with inkscape_liveeffects branch,
which doesn't compile right now). However I get these warnings; I
don't know if they are of any help:

[  3%] Generating svg_path_parser.cpp with ragel
Scanning dependencies of target 2geom
[  7%] Building CXX object src/CMakeFiles/2geom.dir/svg-path.o
/home/lxuser/compilation/lib2geom/src/svg-path.h:39: warning: 'class
Geom::SVGPathSink' has virtual functions but non-virtual destructor
/home/lxuser/compilation/lib2geom/src/svg-path.h: In instantiation of
'Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Path,
std::allocator<Geom::Path> > > >':
/home/lxuser/compilation/lib2geom/src/svg-path.h:106:   instantiated from here
/home/lxuser/compilation/lib2geom/src/svg-path.h:54: warning: 'class
Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Path,
std::allocator<Geom::Path> > > >' has virtual functions but
non-virtual destructor
/home/lxuser/compilation/lib2geom/src/svg-path.h:106: warning: 'class
Geom::PathBuilder' has virtual functions but non-virtual destructor
[ 10%] Building CXX object src/CMakeFiles/2geom.dir/svg-path-parser.o
/home/lxuser/compilation/lib2geom/src/svg-path.h:39: warning: 'class
Geom::SVGPathSink' has virtual functions but non-virtual destructor
/home/lxuser/compilation/lib2geom/src/svg-path.h: In instantiation of
'Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Path,
std::allocator<Geom::Path> > > >':
/home/lxuser/compilation/lib2geom/src/svg-path.h:106:   instantiated from here
/home/lxuser/compilation/lib2geom/src/svg-path.h:54: warning: 'class
Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Path,
std::allocator<Geom::Path> > > >' has virtual functions but
non-virtual destructor
/home/lxuser/compilation/lib2geom/src/svg-path.h:106: warning: 'class
Geom::PathBuilder' has virtual functions but non-virtual destructor
[ 14%] Building CXX object src/CMakeFiles/2geom.dir/path.o
[ 17%] Building CXX object src/CMakeFiles/2geom.dir/path-intersection.o
[ 21%] Building CXX object src/CMakeFiles/2geom.dir/poly.o
[ 25%] Building CXX object src/CMakeFiles/2geom.dir/poly-dk-solve.o
[ 28%] Building CXX object src/CMakeFiles/2geom.dir/poly-laguerre-solve.o
/home/lxuser/compilation/lib2geom/src/poly-laguerre-solve.cpp: In
function 'cdouble laguerre_internal_complex(const Poly&, double,
double, bool&)':
/home/lxuser/compilation/lib2geom/src/poly-laguerre-solve.cpp:15:
warning: unused variable 'shuffle'
/home/lxuser/compilation/lib2geom/src/poly-laguerre-solve.cpp: In
function 'std::vector<double, std::allocator<double> >
laguerre_real_interval(const Poly&, double, double, double)':
/home/lxuser/compilation/lib2geom/src/poly-laguerre-solve.cpp:136:
warning: control reaches end of non-void function
[ 32%] Building CXX object src/CMakeFiles/2geom.dir/quadtree.o
[ 35%] Building CXX object src/CMakeFiles/2geom.dir/matrix.o
[ 39%] Building CXX object src/CMakeFiles/2geom.dir/transforms.o
[ 42%] Building CXX object src/CMakeFiles/2geom.dir/point.o
[ 46%] Building CXX object src/CMakeFiles/2geom.dir/d2-sbasis.o
[ 50%] Building CXX object src/CMakeFiles/2geom.dir/piecewise.o
[ 53%] Building CXX object src/CMakeFiles/2geom.dir/sbasis.o
[ 57%] Building CXX object src/CMakeFiles/2geom.dir/sbasis-2d.o
[ 60%] Building CXX object src/CMakeFiles/2geom.dir/sbasis-geometric.o
[ 64%] Building CXX object src/CMakeFiles/2geom.dir/sbasis-math.o
[ 67%] Building CXX object src/CMakeFiles/2geom.dir/sbasis-poly.o
[ 71%] Building CXX object src/CMakeFiles/2geom.dir/sbasis-roots.o
[ 75%] Building CXX object src/CMakeFiles/2geom.dir/sbasis-to-bezier.o
[ 78%] Building CXX object src/CMakeFiles/2geom.dir/basic-intersection.o
[ 82%] Building CXX object src/CMakeFiles/2geom.dir/geom.o
[ 85%] Building CXX object src/CMakeFiles/2geom.dir/bezier-utils.o
[ 89%] Building CXX object src/CMakeFiles/2geom.dir/conjugate_gradient.o
/home/lxuser/compilation/lib2geom/src/conjugate_gradient.cpp:58:
warning: 'double Linfty(const std::valarray<double>&)' defined but not
used
[ 92%] Building CXX object src/CMakeFiles/2geom.dir/convex-cover.o
/home/lxuser/compilation/lib2geom/src/convex-cover.cpp: In member
function 'void Geom::ConvexHull::graham_scan()':
/home/lxuser/compilation/lib2geom/src/convex-cover.cpp:117: warning:
comparison between signed and unsigned integer expressions
/home/lxuser/compilation/lib2geom/src/convex-cover.cpp: In function
'std::pair<std::map<int, int, std::less<int>,
std::allocator<std::pair<const int, int> > >, std::map<int, int,
std::less<int>, std::allocator<std::pair<const int, int> > > >
Geom::bridges(Geom::ConvexHull, Geom::ConvexHull)':
/home/lxuser/compilation/lib2geom/src/convex-cover.cpp:295: warning:
comparison between signed and unsigned integer expressions
/home/lxuser/compilation/lib2geom/src/convex-cover.cpp:296: warning:
comparison between signed and unsigned integer expressions
/home/lxuser/compilation/lib2geom/src/convex-cover.cpp: In function
'Geom::ConvexHull Geom::sweepline_intersection(const
Geom::ConvexHull&, const Geom::ConvexHull&)':
/home/lxuser/compilation/lib2geom/src/convex-cover.cpp:342: warning:
comparison between signed and unsigned integer expressions
/home/lxuser/compilation/lib2geom/src/convex-cover.cpp:346: warning:
comparison between signed and unsigned integer expressions
/home/lxuser/compilation/lib2geom/src/convex-cover.cpp:351: warning:
unused variable 'sweep_y'
/home/lxuser/compilation/lib2geom/src/convex-cover.cpp: In function
'Geom::ConvexHull Geom::intersection(Geom::ConvexHull,
Geom::ConvexHull)':
/home/lxuser/compilation/lib2geom/src/convex-cover.cpp:362: warning:
unused variable 'ai'
/home/lxuser/compilation/lib2geom/src/convex-cover.cpp:362: warning:
unused variable 'bi'
/home/lxuser/compilation/lib2geom/src/convex-cover.cpp:363: warning:
unused variable 'aj'
/home/lxuser/compilation/lib2geom/src/convex-cover.cpp:364: warning:
unused variable 'bj'
/home/lxuser/compilation/lib2geom/src/convex-cover.cpp: In function
'Geom::ConvexHull Geom::merge(Geom::ConvexHull, Geom::ConvexHull)':
/home/lxuser/compilation/lib2geom/src/convex-cover.cpp:391: warning:
comparison between signed and unsigned integer expressions
/home/lxuser/compilation/lib2geom/src/convex-cover.cpp:399: warning:
comparison between signed and unsigned integer expressions
/home/lxuser/compilation/lib2geom/src/convex-cover.cpp: In function
'Geom::ConvexHull Geom::sweepline_intersection(const
Geom::ConvexHull&, const Geom::ConvexHull&)':
/home/lxuser/compilation/lib2geom/src/convex-cover.cpp:353: warning:
control reaches end of non-void function
/home/lxuser/compilation/lib2geom/src/convex-cover.cpp: In member
function 'bool Geom::ConvexHull::no_colinear_points() const':
/home/lxuser/compilation/lib2geom/src/convex-cover.cpp:268: warning:
control reaches end of non-void function
[ 96%] Building CXX object src/CMakeFiles/2geom.dir/solve-bezier-one-d.o
[100%] Building CXX object src/CMakeFiles/2geom.dir/solve-bezier-parametric.o
Linking CXX static library lib2geom.a
[100%] Built target 2geom


2007/7/26, mgsloan <mg...@gm...>:
> Alright, I've fixed it again.  The reason for these errors is that
> min/max only work when the types of both sides are the same.  I guess
> your compiler is just a bit more of a stickler - ours appear to
> coerce.  Anyway, it's definitely good to get these fixed.  Could you
> fix them yourself and send a patch?  Just look at the type signature
> given in the error (the warnings don't matter), and add a conversion
> operator in the code as required.  For example, the most recent one
> was max(unsigned int, long unsigned int), so I added (unsigned) to the
> beginning of the second operand.
>
> Thanks,
> Michael Sloan
>
> On 7/26/07, Pajarico <paj...@gm...> wrote:
> > Ok, now I'm getting this:
> >
> > lxuser@localhost ~/compilation/lib2geom $ make
> > [  3%] Generating svg_path_parser.cpp with ragel
> > Scanning dependencies of target 2geom
> > [  7%] Building CXX object src/CMakeFiles/2geom.dir/svg-path.o
> > /home/lxuser/compilation/lib2geom/src/svg-path.h:39: warning: 'class
> > Geom::SVGPathSink' has virtual functions but non-virtual destructor
> > /home/lxuser/compilation/lib2geom/src/svg-path.h: In instantiation of
> > 'Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Path,
> > std::allocator<Geom::Path> > > >':
> > /home/lxuser/compilation/lib2geom/src/svg-path.h:106:   instantiated from here
> > /home/lxuser/compilation/lib2geom/src/svg-path.h:54: warning: 'class
> > Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Path,
> > std::allocator<Geom::Path> > > >' has virtual functions but
> > non-virtual destructor
> > /home/lxuser/compilation/lib2geom/src/svg-path.h:106: warning: 'class
> > Geom::PathBuilder' has virtual functions but non-virtual destructor
> > [ 11%] Building CXX object src/CMakeFiles/2geom.dir/svg-path-parser.o
> > /home/lxuser/compilation/lib2geom/src/svg-path.h:39: warning: 'class
> > Geom::SVGPathSink' has virtual functions but non-virtual destructor
> > /home/lxuser/compilation/lib2geom/src/svg-path.h: In instantiation of
> > 'Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Path,
> > std::allocator<Geom::Path> > > >':
> > /home/lxuser/compilation/lib2geom/src/svg-path.h:106:   instantiated from here
> > /home/lxuser/compilation/lib2geom/src/svg-path.h:54: warning: 'class
> > Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Path,
> > std::allocator<Geom::Path> > > >' has virtual functions but
> > non-virtual destructor
> > /home/lxuser/compilation/lib2geom/src/svg-path.h:106: warning: 'class
> > Geom::PathBuilder' has virtual functions but non-virtual destructor
> > [ 14%] Building CXX object src/CMakeFiles/2geom.dir/path.o
> > [ 18%] Building CXX object src/CMakeFiles/2geom.dir/poly.o
> > /home/lxuser/compilation/lib2geom/src/poly.h: In member function 'Poly
> > Poly::shifted(unsigned int) const':
> > /home/lxuser/compilation/lib2geom/src/poly.h:98: error: no matching
> > function for call to 'max(unsigned int, long unsigned int)'
> > make[2]: *** [src/CMakeFiles/2geom.dir/poly.o] Error 1
> > make[1]: *** [src/CMakeFiles/2geom.dir/all] Error 2
> > make: *** [all] Error 2
> >
> > 2007/7/26, mgsloan <mg...@gm...>:
> > > I think the problem is that they don't have the same type.  Probably
> > > our compilers figure out it needs to be cast to unsigned.  I've
> > > attempted to fix it in svn, and reverted some of my old changes.
> > >
> > > Hope it works,
> > > Michael Sloan
> > >
> > > On 7/24/07, Pajarico <paj...@gm...> wrote:
> > > > First, thanks for your attention. Unfortunately I get the same error
> > > > (the only difference is that 'min' has been replaced by 'Min'). I did
> > > > a 'make clean' beforehand.
> > > >
> > > > About compiler/libs incompatibility, care to elaborate? Which libs
> > > > could be guilty?
> > > >
> > > >
> > > > > The issue is the error on min.  The warnings are fine.
> > > > >
> > > > > This is likely due to some sort of compiler/libs incompatibility,
> > > > > though your list looks fine.  This is probably why we used to have
> > > > > custom min/max.  Anyway, I've re-added custom Min/Max to svn.  Might
> > > > > as well, as it might help with compatibility in the future.
> > > > >
> > > > > Hope that fixes it,
> > > > > Michael Sloan
> > > > >
> > > > > On 7/22/07, Pajarico <paj...@gm...> wrote:
> > > > > > Hi, I get this error while compiling SVN, 0.1 also does this:
> > > > > >
> > > > > > lxuser@localhost ~/compilation/lib2geom $ make
> > > > > > [  3%] Generating svg_path_parser.cpp with ragel
> > > > > > Scanning dependencies of target 2geom
> > > > > > [  7%] Building CXX object src/CMakeFiles/2geom.dir/svg-path.o
> > > > > > /home/lxuser/compilation/lib2geom/src/sbasis.h: In function
> > > > > > 'Geom::SBasis Geom::truncate(const Geom::SBasis&, unsigned int)':
> > > > > > /home/lxuser/compilation/lib2geom/src/sbasis.h:215: error: no matching
> > > > > > function for call to 'min(unsigned int&, size_t)'
> > > > > > /home/lxuser/compilation/lib2geom/src/svg-path.h: At global scope:
> > > > > > /home/lxuser/compilation/lib2geom/src/svg-path.h:39: warning: 'class
> > > > > > Geom::SVGPathSink' has virtual functions but non-virtual destructor
> > > > > > /home/lxuser/compilation/lib2geom/src/svg-path.h: In instantiation of
> > > > > > 'Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Path,
> > > > > > std::allocator<Geom::Path> > > >':
> > > > > > /home/lxuser/compilation/lib2geom/src/svg-path.h:106:   instantiated from here
> > > > > > /home/lxuser/compilation/lib2geom/src/svg-path.h:54: warning: 'class
> > > > > > Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Path,
> > > > > > std::allocator<Geom::Path> > > >' has virtual functions but
> > > > > > non-virtual destructor
> > > > > > /home/lxuser/compilation/lib2geom/src/svg-path.h:106: warning: 'class
> > > > > > Geom::PathBuilder' has virtual functions but non-virtual destructor
> > > > > > make[2]: *** [src/CMakeFiles/2geom.dir/svg-path.o] Error 1
> > > > > > make[1]: *** [src/CMakeFiles/2geom.dir/all] Error 2
> > > > > > make: *** [all] Error 2
> > > > > >
> > > > > >
> > > > > > This is with:
> > > > > > - amd64
> > > > > > - Gentoo Linux 2.6.20-r7
> > > > > > - gcc-4.1.2
> > > > > > - ragel-5.20
> > > > > > - cmake-2.4
> > > > > >
> > > > > > Cheers.
> > > > > >
> > > > > > -------------------------------------------------------------------------
> > > > > > This SF.net email is sponsored by: Splunk Inc.
> > > > > > Still grepping through log files to find problems?  Stop.
> > > > > > Now Search log events and configuration files using AJAX and a browser.
> > > > > > Download your FREE copy of Splunk now >>  http://get.splunk.com/
> > > > > > _______________________________________________
> > > > > > Lib2geom-devel mailing list
> > > > > > Lib...@li...
> > > > > > https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [Lib2geom-devel] Warnings compiling lib2geom SVN

[mgsloan <mg...@gm...>]

Alright, I've fixed it again.  The reason for these errors is that
min/max only work when the types of both sides are the same.  I guess
your compiler is just a bit more of a stickler - ours appear to
coerce.  Anyway, it's definitely good to get these fixed.  Could you
fix them yourself and send a patch?  Just look at the type signature
given in the error (the warnings don't matter), and add a conversion
operator in the code as required.  For example, the most recent one
was max(unsigned int, long unsigned int), so I added (unsigned) to the
beginning of the second operand.

Thanks,
Michael Sloan

On 7/26/07, Pajarico <paj...@gm...> wrote:
> Ok, now I'm getting this:
>
> lxuser@localhost ~/compilation/lib2geom $ make
> [  3%] Generating svg_path_parser.cpp with ragel
> Scanning dependencies of target 2geom
> [  7%] Building CXX object src/CMakeFiles/2geom.dir/svg-path.o
> /home/lxuser/compilation/lib2geom/src/svg-path.h:39: warning: 'class
> Geom::SVGPathSink' has virtual functions but non-virtual destructor
> /home/lxuser/compilation/lib2geom/src/svg-path.h: In instantiation of
> 'Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Path,
> std::allocator<Geom::Path> > > >':
> /home/lxuser/compilation/lib2geom/src/svg-path.h:106:   instantiated from here
> /home/lxuser/compilation/lib2geom/src/svg-path.h:54: warning: 'class
> Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Path,
> std::allocator<Geom::Path> > > >' has virtual functions but
> non-virtual destructor
> /home/lxuser/compilation/lib2geom/src/svg-path.h:106: warning: 'class
> Geom::PathBuilder' has virtual functions but non-virtual destructor
> [ 11%] Building CXX object src/CMakeFiles/2geom.dir/svg-path-parser.o
> /home/lxuser/compilation/lib2geom/src/svg-path.h:39: warning: 'class
> Geom::SVGPathSink' has virtual functions but non-virtual destructor
> /home/lxuser/compilation/lib2geom/src/svg-path.h: In instantiation of
> 'Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Path,
> std::allocator<Geom::Path> > > >':
> /home/lxuser/compilation/lib2geom/src/svg-path.h:106:   instantiated from here
> /home/lxuser/compilation/lib2geom/src/svg-path.h:54: warning: 'class
> Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Path,
> std::allocator<Geom::Path> > > >' has virtual functions but
> non-virtual destructor
> /home/lxuser/compilation/lib2geom/src/svg-path.h:106: warning: 'class
> Geom::PathBuilder' has virtual functions but non-virtual destructor
> [ 14%] Building CXX object src/CMakeFiles/2geom.dir/path.o
> [ 18%] Building CXX object src/CMakeFiles/2geom.dir/poly.o
> /home/lxuser/compilation/lib2geom/src/poly.h: In member function 'Poly
> Poly::shifted(unsigned int) const':
> /home/lxuser/compilation/lib2geom/src/poly.h:98: error: no matching
> function for call to 'max(unsigned int, long unsigned int)'
> make[2]: *** [src/CMakeFiles/2geom.dir/poly.o] Error 1
> make[1]: *** [src/CMakeFiles/2geom.dir/all] Error 2
> make: *** [all] Error 2
>
> 2007/7/26, mgsloan <mg...@gm...>:
> > I think the problem is that they don't have the same type.  Probably
> > our compilers figure out it needs to be cast to unsigned.  I've
> > attempted to fix it in svn, and reverted some of my old changes.
> >
> > Hope it works,
> > Michael Sloan
> >
> > On 7/24/07, Pajarico <paj...@gm...> wrote:
> > > First, thanks for your attention. Unfortunately I get the same error
> > > (the only difference is that 'min' has been replaced by 'Min'). I did
> > > a 'make clean' beforehand.
> > >
> > > About compiler/libs incompatibility, care to elaborate? Which libs
> > > could be guilty?
> > >
> > >
> > > > The issue is the error on min.  The warnings are fine.
> > > >
> > > > This is likely due to some sort of compiler/libs incompatibility,
> > > > though your list looks fine.  This is probably why we used to have
> > > > custom min/max.  Anyway, I've re-added custom Min/Max to svn.  Might
> > > > as well, as it might help with compatibility in the future.
> > > >
> > > > Hope that fixes it,
> > > > Michael Sloan
> > > >
> > > > On 7/22/07, Pajarico <paj...@gm...> wrote:
> > > > > Hi, I get this error while compiling SVN, 0.1 also does this:
> > > > >
> > > > > lxuser@localhost ~/compilation/lib2geom $ make
> > > > > [  3%] Generating svg_path_parser.cpp with ragel
> > > > > Scanning dependencies of target 2geom
> > > > > [  7%] Building CXX object src/CMakeFiles/2geom.dir/svg-path.o
> > > > > /home/lxuser/compilation/lib2geom/src/sbasis.h: In function
> > > > > 'Geom::SBasis Geom::truncate(const Geom::SBasis&, unsigned int)':
> > > > > /home/lxuser/compilation/lib2geom/src/sbasis.h:215: error: no matching
> > > > > function for call to 'min(unsigned int&, size_t)'
> > > > > /home/lxuser/compilation/lib2geom/src/svg-path.h: At global scope:
> > > > > /home/lxuser/compilation/lib2geom/src/svg-path.h:39: warning: 'class
> > > > > Geom::SVGPathSink' has virtual functions but non-virtual destructor
> > > > > /home/lxuser/compilation/lib2geom/src/svg-path.h: In instantiation of
> > > > > 'Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Path,
> > > > > std::allocator<Geom::Path> > > >':
> > > > > /home/lxuser/compilation/lib2geom/src/svg-path.h:106:   instantiated from here
> > > > > /home/lxuser/compilation/lib2geom/src/svg-path.h:54: warning: 'class
> > > > > Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Path,
> > > > > std::allocator<Geom::Path> > > >' has virtual functions but
> > > > > non-virtual destructor
> > > > > /home/lxuser/compilation/lib2geom/src/svg-path.h:106: warning: 'class
> > > > > Geom::PathBuilder' has virtual functions but non-virtual destructor
> > > > > make[2]: *** [src/CMakeFiles/2geom.dir/svg-path.o] Error 1
> > > > > make[1]: *** [src/CMakeFiles/2geom.dir/all] Error 2
> > > > > make: *** [all] Error 2
> > > > >
> > > > >
> > > > > This is with:
> > > > > - amd64
> > > > > - Gentoo Linux 2.6.20-r7
> > > > > - gcc-4.1.2
> > > > > - ragel-5.20
> > > > > - cmake-2.4
> > > > >
> > > > > Cheers.
> > > > >
> > > > > -------------------------------------------------------------------------
> > > > > This SF.net email is sponsored by: Splunk Inc.
> > > > > Still grepping through log files to find problems?  Stop.
> > > > > Now Search log events and configuration files using AJAX and a browser.
> > > > > Download your FREE copy of Splunk now >>  http://get.splunk.com/
> > > > > _______________________________________________
> > > > > Lib2geom-devel mailing list
> > > > > Lib...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
> > > > >
> > > >
> > >
> >
>

Re: [Lib2geom-devel] Warnings compiling lib2geom SVN

[Pajarico <paj...@gm...>]

Ok, now I'm getting this:

lxuser@localhost ~/compilation/lib2geom $ make
[  3%] Generating svg_path_parser.cpp with ragel
Scanning dependencies of target 2geom
[  7%] Building CXX object src/CMakeFiles/2geom.dir/svg-path.o
/home/lxuser/compilation/lib2geom/src/svg-path.h:39: warning: 'class
Geom::SVGPathSink' has virtual functions but non-virtual destructor
/home/lxuser/compilation/lib2geom/src/svg-path.h: In instantiation of
'Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Path,
std::allocator<Geom::Path> > > >':
/home/lxuser/compilation/lib2geom/src/svg-path.h:106:   instantiated from here
/home/lxuser/compilation/lib2geom/src/svg-path.h:54: warning: 'class
Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Path,
std::allocator<Geom::Path> > > >' has virtual functions but
non-virtual destructor
/home/lxuser/compilation/lib2geom/src/svg-path.h:106: warning: 'class
Geom::PathBuilder' has virtual functions but non-virtual destructor
[ 11%] Building CXX object src/CMakeFiles/2geom.dir/svg-path-parser.o
/home/lxuser/compilation/lib2geom/src/svg-path.h:39: warning: 'class
Geom::SVGPathSink' has virtual functions but non-virtual destructor
/home/lxuser/compilation/lib2geom/src/svg-path.h: In instantiation of
'Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Path,
std::allocator<Geom::Path> > > >':
/home/lxuser/compilation/lib2geom/src/svg-path.h:106:   instantiated from here
/home/lxuser/compilation/lib2geom/src/svg-path.h:54: warning: 'class
Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Path,
std::allocator<Geom::Path> > > >' has virtual functions but
non-virtual destructor
/home/lxuser/compilation/lib2geom/src/svg-path.h:106: warning: 'class
Geom::PathBuilder' has virtual functions but non-virtual destructor
[ 14%] Building CXX object src/CMakeFiles/2geom.dir/path.o
[ 18%] Building CXX object src/CMakeFiles/2geom.dir/poly.o
/home/lxuser/compilation/lib2geom/src/poly.h: In member function 'Poly
Poly::shifted(unsigned int) const':
/home/lxuser/compilation/lib2geom/src/poly.h:98: error: no matching
function for call to 'max(unsigned int, long unsigned int)'
make[2]: *** [src/CMakeFiles/2geom.dir/poly.o] Error 1
make[1]: *** [src/CMakeFiles/2geom.dir/all] Error 2
make: *** [all] Error 2

2007/7/26, mgsloan <mg...@gm...>:
> I think the problem is that they don't have the same type.  Probably
> our compilers figure out it needs to be cast to unsigned.  I've
> attempted to fix it in svn, and reverted some of my old changes.
>
> Hope it works,
> Michael Sloan
>
> On 7/24/07, Pajarico <paj...@gm...> wrote:
> > First, thanks for your attention. Unfortunately I get the same error
> > (the only difference is that 'min' has been replaced by 'Min'). I did
> > a 'make clean' beforehand.
> >
> > About compiler/libs incompatibility, care to elaborate? Which libs
> > could be guilty?
> >
> >
> > > The issue is the error on min.  The warnings are fine.
> > >
> > > This is likely due to some sort of compiler/libs incompatibility,
> > > though your list looks fine.  This is probably why we used to have
> > > custom min/max.  Anyway, I've re-added custom Min/Max to svn.  Might
> > > as well, as it might help with compatibility in the future.
> > >
> > > Hope that fixes it,
> > > Michael Sloan
> > >
> > > On 7/22/07, Pajarico <paj...@gm...> wrote:
> > > > Hi, I get this error while compiling SVN, 0.1 also does this:
> > > >
> > > > lxuser@localhost ~/compilation/lib2geom $ make
> > > > [  3%] Generating svg_path_parser.cpp with ragel
> > > > Scanning dependencies of target 2geom
> > > > [  7%] Building CXX object src/CMakeFiles/2geom.dir/svg-path.o
> > > > /home/lxuser/compilation/lib2geom/src/sbasis.h: In function
> > > > 'Geom::SBasis Geom::truncate(const Geom::SBasis&, unsigned int)':
> > > > /home/lxuser/compilation/lib2geom/src/sbasis.h:215: error: no matching
> > > > function for call to 'min(unsigned int&, size_t)'
> > > > /home/lxuser/compilation/lib2geom/src/svg-path.h: At global scope:
> > > > /home/lxuser/compilation/lib2geom/src/svg-path.h:39: warning: 'class
> > > > Geom::SVGPathSink' has virtual functions but non-virtual destructor
> > > > /home/lxuser/compilation/lib2geom/src/svg-path.h: In instantiation of
> > > > 'Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Path,
> > > > std::allocator<Geom::Path> > > >':
> > > > /home/lxuser/compilation/lib2geom/src/svg-path.h:106:   instantiated from here
> > > > /home/lxuser/compilation/lib2geom/src/svg-path.h:54: warning: 'class
> > > > Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Path,
> > > > std::allocator<Geom::Path> > > >' has virtual functions but
> > > > non-virtual destructor
> > > > /home/lxuser/compilation/lib2geom/src/svg-path.h:106: warning: 'class
> > > > Geom::PathBuilder' has virtual functions but non-virtual destructor
> > > > make[2]: *** [src/CMakeFiles/2geom.dir/svg-path.o] Error 1
> > > > make[1]: *** [src/CMakeFiles/2geom.dir/all] Error 2
> > > > make: *** [all] Error 2
> > > >
> > > >
> > > > This is with:
> > > > - amd64
> > > > - Gentoo Linux 2.6.20-r7
> > > > - gcc-4.1.2
> > > > - ragel-5.20
> > > > - cmake-2.4
> > > >
> > > > Cheers.
> > > >
> > > > -------------------------------------------------------------------------
> > > > This SF.net email is sponsored by: Splunk Inc.
> > > > Still grepping through log files to find problems?  Stop.
> > > > Now Search log events and configuration files using AJAX and a browser.
> > > > Download your FREE copy of Splunk now >>  http://get.splunk.com/
> > > > _______________________________________________
> > > > Lib2geom-devel mailing list
> > > > Lib...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
> > > >
> > >
> >
>

[Lib2geom-devel] "method not implemented"

[<J.B...@ew...>]

Hi all,

Josh found a bug in skel-strokes LPE: when using a circle as pattern =
parameter, Inkscape crashes. I think this is because of the elliptic arc =
thing in inkscape's circles.
(d=3D M 211,162 A 67,58 0 1 1 77,162 A 67,58 0 1 1 211,162 z)

The crash message is:
terminate called after throwing an instance of 'NotImplemented'
what(): method not implemented
It happens when a skeletal stroke effect is applied to a path and when a =
circle shape is copied and then pasted onto the pattern parameter using =
the LPE dialog.

GDB crashes on application of Skel strokes with a "terminate called =
after throwing an instance of 'std::out_of_range'
  what():  vector::_M_range_check" ... this does not happen outside gdb, =
so... i don't know whether this is a bug in inkscape or not (probably it =
is). So i cannot track down where the 'circle crash' comes from.

Maybe you can shine some light on this?

- Johan

Re: [Lib2geom-devel] Warnings compiling lib2geom SVN

[mgsloan <mg...@gm...>]

I think the problem is that they don't have the same type.  Probably
our compilers figure out it needs to be cast to unsigned.  I've
attempted to fix it in svn, and reverted some of my old changes.

Hope it works,
Michael Sloan

On 7/24/07, Pajarico <paj...@gm...> wrote:
> First, thanks for your attention. Unfortunately I get the same error
> (the only difference is that 'min' has been replaced by 'Min'). I did
> a 'make clean' beforehand.
>
> About compiler/libs incompatibility, care to elaborate? Which libs
> could be guilty?
>
>
> > The issue is the error on min.  The warnings are fine.
> >
> > This is likely due to some sort of compiler/libs incompatibility,
> > though your list looks fine.  This is probably why we used to have
> > custom min/max.  Anyway, I've re-added custom Min/Max to svn.  Might
> > as well, as it might help with compatibility in the future.
> >
> > Hope that fixes it,
> > Michael Sloan
> >
> > On 7/22/07, Pajarico <paj...@gm...> wrote:
> > > Hi, I get this error while compiling SVN, 0.1 also does this:
> > >
> > > lxuser@localhost ~/compilation/lib2geom $ make
> > > [  3%] Generating svg_path_parser.cpp with ragel
> > > Scanning dependencies of target 2geom
> > > [  7%] Building CXX object src/CMakeFiles/2geom.dir/svg-path.o
> > > /home/lxuser/compilation/lib2geom/src/sbasis.h: In function
> > > 'Geom::SBasis Geom::truncate(const Geom::SBasis&, unsigned int)':
> > > /home/lxuser/compilation/lib2geom/src/sbasis.h:215: error: no matching
> > > function for call to 'min(unsigned int&, size_t)'
> > > /home/lxuser/compilation/lib2geom/src/svg-path.h: At global scope:
> > > /home/lxuser/compilation/lib2geom/src/svg-path.h:39: warning: 'class
> > > Geom::SVGPathSink' has virtual functions but non-virtual destructor
> > > /home/lxuser/compilation/lib2geom/src/svg-path.h: In instantiation of
> > > 'Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Path,
> > > std::allocator<Geom::Path> > > >':
> > > /home/lxuser/compilation/lib2geom/src/svg-path.h:106:   instantiated from here
> > > /home/lxuser/compilation/lib2geom/src/svg-path.h:54: warning: 'class
> > > Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Path,
> > > std::allocator<Geom::Path> > > >' has virtual functions but
> > > non-virtual destructor
> > > /home/lxuser/compilation/lib2geom/src/svg-path.h:106: warning: 'class
> > > Geom::PathBuilder' has virtual functions but non-virtual destructor
> > > make[2]: *** [src/CMakeFiles/2geom.dir/svg-path.o] Error 1
> > > make[1]: *** [src/CMakeFiles/2geom.dir/all] Error 2
> > > make: *** [all] Error 2
> > >
> > >
> > > This is with:
> > > - amd64
> > > - Gentoo Linux 2.6.20-r7
> > > - gcc-4.1.2
> > > - ragel-5.20
> > > - cmake-2.4
> > >
> > > Cheers.
> > >
> > > -------------------------------------------------------------------------
> > > This SF.net email is sponsored by: Splunk Inc.
> > > Still grepping through log files to find problems?  Stop.
> > > Now Search log events and configuration files using AJAX and a browser.
> > > Download your FREE copy of Splunk now >>  http://get.splunk.com/
> > > _______________________________________________
> > > Lib2geom-devel mailing list
> > > Lib...@li...
> > > https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
> > >
> >
>

Re: [Lib2geom-devel] Warnings compiling lib2geom SVN

[MenTaLguY <me...@ry...>]

On Tue, 2007-07-24 at 23:22 +0200, Pajarico wrote:
> I vaguely know what STL is, but I don't know if STL files are
> installed by gcc or I should install one of the other STL
> implementations, like http://stlport.sourceforge.net/?

STL is standard to the C++ language and comes with g++ (if it is
correctly installed).

-mental

Re: [Lib2geom-devel] Warnings compiling lib2geom SVN

[Pajarico <paj...@gm...>]

I vaguely know what STL is, but I don't know if STL files are
installed by gcc or I should install one of the other STL
implementations, like http://stlport.sourceforge.net/?

I checked out your commit but the error remains there.

2007/7/24, mgsloan <mg...@gm...>:
> Well, it should be in STL.  If the problem still exists, perhaps the
> issue is assuming certain things happen with the #includes.  I've
> added #include "utils.h" to sbasis.h - hopefully that will help.  If
> any more pop up, try adding this to the file.
>
> - Michael Sloan
>
> On 7/24/07, Pajarico <paj...@gm...> wrote:
> > First, thanks for your attention. Unfortunately I get the same error
> > (the only difference is that 'min' has been replaced by 'Min'). I did
> > a 'make clean' beforehand.
> >
> > About compiler/libs incompatibility, care to elaborate? Which libs
> > could be guilty?
> >
> >
> > > The issue is the error on min.  The warnings are fine.
> > >
> > > This is likely due to some sort of compiler/libs incompatibility,
> > > though your list looks fine.  This is probably why we used to have
> > > custom min/max.  Anyway, I've re-added custom Min/Max to svn.  Might
> > > as well, as it might help with compatibility in the future.
> > >
> > > Hope that fixes it,
> > > Michael Sloan
> > >
> > > On 7/22/07, Pajarico <paj...@gm...> wrote:
> > > > Hi, I get this error while compiling SVN, 0.1 also does this:
> > > >
> > > > lxuser@localhost ~/compilation/lib2geom $ make
> > > > [  3%] Generating svg_path_parser.cpp with ragel
> > > > Scanning dependencies of target 2geom
> > > > [  7%] Building CXX object src/CMakeFiles/2geom.dir/svg-path.o
> > > > /home/lxuser/compilation/lib2geom/src/sbasis.h: In function
> > > > 'Geom::SBasis Geom::truncate(const Geom::SBasis&, unsigned int)':
> > > > /home/lxuser/compilation/lib2geom/src/sbasis.h:215: error: no matching
> > > > function for call to 'min(unsigned int&, size_t)'
> > > > /home/lxuser/compilation/lib2geom/src/svg-path.h: At global scope:
> > > > /home/lxuser/compilation/lib2geom/src/svg-path.h:39: warning: 'class
> > > > Geom::SVGPathSink' has virtual functions but non-virtual destructor
> > > > /home/lxuser/compilation/lib2geom/src/svg-path.h: In instantiation of
> > > > 'Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Path,
> > > > std::allocator<Geom::Path> > > >':
> > > > /home/lxuser/compilation/lib2geom/src/svg-path.h:106:   instantiated from here
> > > > /home/lxuser/compilation/lib2geom/src/svg-path.h:54: warning: 'class
> > > > Geom::SVGPathGenerator<std::back_insert_iterator<std::vector<Geom::Path,
> > > > std::allocator<Geom::Path> > > >' has virtual functions but
> > > > non-virtual destructor
> > > > /home/lxuser/compilation/lib2geom/src/svg-path.h:106: warning: 'class
> > > > Geom::PathBuilder' has virtual functions but non-virtual destructor
> > > > make[2]: *** [src/CMakeFiles/2geom.dir/svg-path.o] Error 1
> > > > make[1]: *** [src/CMakeFiles/2geom.dir/all] Error 2
> > > > make: *** [all] Error 2
> > > >
> > > >
> > > > This is with:
> > > > - amd64
> > > > - Gentoo Linux 2.6.20-r7
> > > > - gcc-4.1.2
> > > > - ragel-5.20
> > > > - cmake-2.4
> > > >
> > > > Cheers.
> > > >
> > > > -------------------------------------------------------------------------
> > > > This SF.net email is sponsored by: Splunk Inc.
> > > > Still grepping through log files to find problems?  Stop.
> > > > Now Search log events and configuration files using AJAX and a browser.
> > > > Download your FREE copy of Splunk now >>  http://get.splunk.com/
> > > > _______________________________________________
> > > > Lib2geom-devel mailing list
> > > > Lib...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
> > > >
> > >
> >
>