lib2geom-devel — development discussion

Re: [Lib2geom-devel] Warnings compiling lib2geom SVN

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

Re: [Lib2geom-devel] Warnings compiling lib2geom SVN

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

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

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] [Inkscape-devel] Committing LivePathEffects to trunk

[Aaron S. <aa...@ek...>]

Bryce Harrington wrote:
> On Mon, Jul 23, 2007 at 12:31:39PM -0500, Aaron Spike wrote:
>> Bryce Harrington wrote:
>>> That said, I think if you wish to merge this branch into main, it would
>>> be wisest to make your code only relies on a released version of
>>> lib2geom (which may mean working to get a release of lib2geom.)
>> Such a requirement is going to force lib2geom to release new versions
>> weekly or even more rapidly.
> 
> You trimmed it out, but I said this could be achieved with svn extern.

Yes, I trimmed it on purpose. Starting with svn extern seems like a
premature optimisation to me. Aditionally I've never used svn extern
before and I wouldn't feel comfortable trying it for the first time on a
project like Inkscape. So my vote goes for two separate svn checkouts.

> I never said making it depend on released versions was a requirement,
> just that it would be a wiser approach.  

I agree it is wisest.

> But please note that linking
> svn's ALSO places a burden on lib2geom in that it would instead require
> that lib2geom svn remain always buildable.  In theory that should not
> ever be an issue, but imagine if a build issue does enter into lib2geom;
> since only lib2geom developers with commit access to that project's svn
> would be able to fix it, it could result in a situation where inkscape
> development would effectively grind to a halt waiting for a fix.
> 
> Of course, this will likely never happen because lib2geom developers
> would never commit build errors into svn.  It is fortunate that a few
> inkscape developers have commit access into lib2geom; hopefully they
> will take the responsibility of quickly fixing issues if they are
> identified, and this issue will never become a problem.

I could be wrong but I think all of the lib2geom developers have commit
access to both projects. I have personally witnessed times when both
lib2geom developers and inkscape developers have made unbuildable
commits. It is going to happen. But I think grinding halts will be much
rarer occasions (only when one of us makes an unbuildable commit and
then goes on vacation).

I hope we can get more inkscape developers involved in lib2geom.
Actually more developers period.

> I imagine there could also be other potential glitches.  Both projects
> use different svn providers, so now instead of just relying on inkscape
> svn being functional, we now require two svn servers to be up and
> functioning at the same time.  And so on.  In theory, everything will
> work perfectly, but in practice...

Both projects use sourceforge svn; we'll be down at the same time.

> This is why I feel that when possible, it is wiser to rely on stable
> releases.  This doesn't mean forcing upstream to release frequently; it
> means being organized in when features are rolled out that require
> features only available in the upstream SVN.  It's the same philosophy
> we would apply with relying on cairo, gtkmm, or other upstream library
> changes.  If everyone feels that it is not possible to apply this
> philosophy in this case, well then this would be an allowable
> exception.

Development will grind to a halt while we wait for the next lib2geom
release to fix a bug in the new feature we want to commit. I think this
stance is necessary with large established projects like gtkmm and
cairo. They have their own culture and established release systems. But
at the same time I do feel that we are hindered slightly sometimes as we
wait for fixes and features to come back downstream to us (waiting not
because those projects are sluggish, but because we lack a strong
inkscape advocate as an involved party). Lib2geom shares much Inkscape
culture and I imagine they will be rather flexible to work with us in
syncing release etc.

> To be honest it doesn't really matter to me; I've been too busy with the
> new job to work on Inkscape anyway.  If those who are actively
> developing on this are willing to experiment with linking svn's with an
> external project, then if the above concerns are legitimate, I'm sure
> they'll make themselves clear and people can deal with them then.  Patch
> first, discuss later as we always say.  ;-)

Is it possible to compromise? Can we strive to depend on a released
lib2geom as much as possible but allow minimal well publicised periods
of dependance on svn? or is that too much complication?

Aaron

Re: [Lib2geom-devel] [Inkscape-devel] Committing LivePathEffects to trunk

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

On Mon, Jul 23, 2007 at 12:31:39PM -0500, Aaron Spike wrote:
> Bryce Harrington wrote:
> > That said, I think if you wish to merge this branch into main, it would
> > be wisest to make your code only relies on a released version of
> > lib2geom (which may mean working to get a release of lib2geom.)
> 
> Such a requirement is going to force lib2geom to release new versions
> weekly or even more rapidly.

You trimmed it out, but I said this could be achieved with svn extern.

I never said making it depend on released versions was a requirement,
just that it would be a wiser approach.  But please note that linking
svn's ALSO places a burden on lib2geom in that it would instead require
that lib2geom svn remain always buildable.  In theory that should not
ever be an issue, but imagine if a build issue does enter into lib2geom;
since only lib2geom developers with commit access to that project's svn
would be able to fix it, it could result in a situation where inkscape
development would effectively grind to a halt waiting for a fix.

Of course, this will likely never happen because lib2geom developers
would never commit build errors into svn.  It is fortunate that a few
inkscape developers have commit access into lib2geom; hopefully they
will take the responsibility of quickly fixing issues if they are
identified, and this issue will never become a problem.

I imagine there could also be other potential glitches.  Both projects
use different svn providers, so now instead of just relying on inkscape
svn being functional, we now require two svn servers to be up and
functioning at the same time.  And so on.  In theory, everything will
work perfectly, but in practice...

This is why I feel that when possible, it is wiser to rely on stable
releases.  This doesn't mean forcing upstream to release frequently; it
means being organized in when features are rolled out that require
features only available in the upstream SVN.  It's the same philosophy
we would apply with relying on cairo, gtkmm, or other upstream library
changes.  If everyone feels that it is not possible to apply this
philosophy in this case, well then this would be an allowable
exception.

To be honest it doesn't really matter to me; I've been too busy with the
new job to work on Inkscape anyway.  If those who are actively
developing on this are willing to experiment with linking svn's with an
external project, then if the above concerns are legitimate, I'm sure
they'll make themselves clear and people can deal with them then.  Patch
first, discuss later as we always say.  ;-)

Bryce

Re: [Lib2geom-devel] [Inkscape-devel] Committing LivePathEffects to trunk

[Aaron S. <aa...@ek...>]

Bryce Harrington wrote:
> That said, I think if you wish to merge this branch into main, it would
> be wisest to make your code only relies on a released version of
> lib2geom (which may mean working to get a release of lib2geom.)

Such a requirement is going to force lib2geom to release new versions
weekly or even more rapidly. :-) I think requiring a stable version of
lib2geom for a release version of Inkscape is a great idea but at the
current moment requiring a stable version of lib2geom for a development
version of Inkscape is impractical at this point in its development. I'm
pretty sure we could get a new stable release of lib2geom today if we
needed it. But I imagine that stable release will soon be too old for
Inkscape's needs. My vote is for merging and requiring a lib2geom from
svn trunk and publishing and updating the minimum necessary revision in
the wiki. The projects need to push each other right now. Perhaps in a
month we will be ready to require a stable version of lib2geom.

Aaron Spike

[Lib2geom-devel] Warnings compiling lib2geom SVN

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

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.

Re: [Lib2geom-devel] C++ questions when looking at header file forQuadtree Class.

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

Sunburned Surveyor wrote:
> [1] What are we doing in the "std::vector<int> data;"=20
> statement?

Perhaps you should start by reading about templates in C++:
http://www.cplusplus.com/doc/tutorial/templates.html=20
A std::vector is a general class to store an ordered list of items of =
the type between < >.
(http://www.sgi.com/tech/stl/)

You'll read about iterators there or somewhere else aswell :)

Cheers,
Johan

[Lib2geom-devel] C++ questions when looking at header file for Quadtree Class.

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

I haven't had time for lib2geom like I wanted the last couple of
weeks, but I finally had time to sit down and look at the header file
for the Quadtree Class. I had a couple of C++ questions that came up
while I was doing this, and I was hoping you guys would be able to
help. The questions are on C++ syntax.

Let me ask about a couple of statements in the portion of the header
file where the Quad class is defined:

[1] What are we doing in the "std::vector<int> data;" statement? I
think we are declaring a data type from the standard namespace named
"data" that has a data type of "vector", but I'm a little confused
about the "<int>". What is that doing in their? Also, is std:vector a
struct or a class, and how would I find this out on my own?

[2] It looks like we define a function, perhaps a constructor, named
Quad() in this portion of the header file. I'm confused because it
looks like this function has statements in its body, and I thought
header files only contained function prototypes. Was I mistaken about
this? Are constructors an exception to this rule?

[3] The statement "typedef std::vector<int>::iterator iterator;" has
me totally lost. :]
I know the keyword "typedef" can be used to create an alias of sorts.
I think this statement is creating and alias for the std:vector data
type. Are we saying that we want to be able to refer to an instance of
"std:vector" as "iterator"? What is that "<int>" doing in there again?
Is that something like Java Generics?

Thanks for your patience with my efforts to learn C++ and the lib2geom
code base. I'm sorry its been so long since you guys have heard from
me. I hope all is going well.

Scott Huey

Re: [Lib2geom-devel] 2geom + inkscape!

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

>
> Although I was not able to build 2geom on my Windows, Aaron Spike gave me
> a distribution build that I was able to link in with Inkscape: it is now
> possible to use 2geom from Inkscape code! (please know that I did not test
> things on Linux..., I also just tested briefly so I am not confident that
> 'all' works. It did seem a bit 'too easy' to link the two together.)


It's probably a dependency issue, though I'm not confident in offering help
in the issue.  I never figured out how to do anything C on windows...  Of
course, I was trying to use free and OSS.  I believe that JFBarraud has a
hack to compile with the boost dependencies.

I found some functions that read path data from a file (I think in SVG
> format?), but not from a string. This makes interfacing with Inkscape
> troublesome. Therefore, could you please add a function that converts an
> Inkscape-datatype to 2geom? I.e. from Glib::ustring with an SVG path
> string to Geom::Path ?


Hmm, good point, we should probably have it take something more accessible.
I'm afraid that in many aspects of C, I am pretty noobish, and string
handling is one of them.  I could have sworn we used some general input
interface that could take strings or files, or maybe strings can be
converted to FILE (even if no file is written).  Anyway, it takes svgd,
which is indeed just the path data.

Re: [Lib2geom-devel] 2geom + inkscape!

[Aaron S. <aa...@ek...>]

J.B...@ew... wrote:
> Although I was not able to build 2geom on my Windows, Aaron Spike
> gave me a distribution build that I was able to link in with
> Inkscape: it is now possible to use 2geom from Inkscape code! (please
> know that I did not test things on Linux..., I also just tested
> briefly so I am not confident that 'all' works. It did seem a bit
> 'too easy' to link the two together.)

Linking together should be pretty easy, I think. I can help you get the
linking working on Linux.

> I found some functions that read path data from a file (I think in
> SVG format?), but not from a string. This makes interfacing with
> Inkscape troublesome. Therefore, could you please add a function that
> converts an Inkscape-datatype to 2geom? I.e. from Glib::ustring with
> an SVG path string to Geom::Path 

This would create a dep in 2geom on glib, not sure we want to do that. I
think we will need a 2geom equivalent of splivator.cpp where functions
that connect 2geom to inkscape live. There are at least two starts at
providing this functionality. Mike wrote the read svgd from a file that
you mentioned and Mental started work on a somewhat more robust
framework for solving this problem. I'm not sure what the status of
either of those efforts is. Mental, can you comment?

> (btw, as I do most of my devel on windows without gaim, i can't join
> the 2geom jabber channel. maybe you can use inkscape's ^- bot as a
> bridge between an irc channel?)

Why don't you have gaim on windows?


Aaron Spike

[Lib2geom-devel] 2geom + inkscape!

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

Hello all,

I just subscribed to this list. Some of you might already know me; I am =
a developer for Inkscape and currently working on what we call =
live-path-effects (for GSoC'07). A lot of effects will rely heavily on =
math, and 2geom will be very very handy =3D)

Although I was not able to build 2geom on my Windows, Aaron Spike gave =
me a distribution build that I was able to link in with Inkscape: it is =
now possible to use 2geom from Inkscape code! (please know that I did =
not test things on Linux..., I also just tested briefly so I am not =
confident that 'all' works. It did seem a bit 'too easy' to link the two =
together.)

I found some functions that read path data from a file (I think in SVG =
format?), but not from a string. This makes interfacing with Inkscape =
troublesome. Therefore, could you please add a function that converts an =
Inkscape-datatype to 2geom? I.e. from Glib::ustring with an SVG path =
string to Geom::Path ?

Thanks a lot!
Johan


(btw, as I do most of my devel on windows without gaim, i can't join the =
2geom jabber channel. maybe you can use inkscape's ^- bot as a bridge =
between an irc channel?)

[Lib2geom-devel] Fwd: Requirements for lib2geom spatial index...

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

njh told me this didn't make it to the list.

Sorry about that.

Scott Huey

---------- Forwarded message ----------
From: Sunburned Surveyor <sun...@gm...>
Date: Apr 21, 2007 7:19 PM
Subject: Re: [Lib2geom-devel] Requirements for lib2geom spatial index...
To: njh <nj...@nj...>


Perhaps the quadtree class doesn't need any work and I can help with
something else? Is there another simple feature of the library that I can
get started with?

Or perhaps I should just work on some API documentation for the existing
quadtree class?

I did put together a simple API documentation in HTML that could be used to
document any type of object-oriented language. I could put together a sample
of the documentation using this html format and also in PDF.

What do you guys think?

Scott Huey

P.S. - I still need to figure out how to compile the manual. Maybe I need to
do that next Friday before I do anything else. Then I won't irritate anybody
with needless questions.


 On 4/21/07, njh <nj...@nj...> wrote:
>
> On Fri, 20 Apr 2007, Sunburned Surveyor wrote:
>
> > lib2geom spatial index. I want to have these in mind when I start to
> look at
> > the existing quadtree class.
> >
> > Requirement #1: The spatial index should not be limited to a fixed size.
>
> The existing quadtree does this.
>
> > Requirement #2: The spatial index should offer the ability for efficient
>
> > updates.
>
> It does this.
>
> > Requirement #3: The spatial index should present a simple API for its
> basic
> > functionality. In other words it shoud have a method that accepts a
> > rectangle or envelope and returns a list of the geometries that are
> > contained or intersected by that argument.
>
> And this.
>
> > What do you guys think? Am I missing anything?
>
> From the manual:
>
> \chapter{2D databases}
>
> 2Geom provides an implementation of a 2D database using quad trees and
> using a list.  Quad trees aren't the best data-structure for queries,
> but they usually out perform the linear list.  We provide a
> standard interface for object databases with performance guarantees
> and provide a set of useful operations Operations:
>
> \begin{description}
> \item[Insert:] given a bounding box and a 'reference', insert into the db
> \item[Delete:] given a bounding box and a 'reference', delete from the db
> \item[Search:] given a box, find all objects that may interact with this
> box
> \item[Cast:] given a path (including rays) return a list of objects that
> interact with the path, roughly sorted by path order
> \item[Shape query:] given a closed path, find all objects whose bounding
> boxes intersect path.  (this and cast are nearly the same)
> \item[Nearest:] given a point (or maybe box) find the nearest objects,
> perhaps as a generator to get all objects in order.  To do this, we walk
> around the quad tree neighbourhood, pushing all the elements into a
> priority queue, while the queue is empty, move out a bit.  Nearest could
> be manhattan, max norm or euc?
> \item[Binary:] take two dbs, generate all pairs that have intersecting
> boxes.
> \item[Sweep:] traverse the tree in say y order, maintaining a y-range of
> relevant objects. (to implement sweepline algorithms)
> \item[Walk:] traverse the tree in an arbitrary order.
> \end{description}
>
> njh
>

Re: [Lib2geom-devel] Requirements for lib2geom spatial index...

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

Sorry, that sounds a bit cranky - I am not normally like this (actually, 
maybe I am).  I blame my stupid cold that kept me up all night.

njh

On Sun, 22 Apr 2007, njh wrote:

> On Fri, 20 Apr 2007, Sunburned Surveyor wrote:
>
>> lib2geom spatial index. I want to have these in mind when I start to look at
>> the existing quadtree class.
>>
>> Requirement #1: The spatial index should not be limited to a fixed size.
>
> The existing quadtree does this.
>
>> Requirement #2: The spatial index should offer the ability for efficient
>> updates.
>
> It does this.
>
>> Requirement #3: The spatial index should present a simple API for its basic
>> functionality. In other words it shoud have a method that accepts a
>> rectangle or envelope and returns a list of the geometries that are
>> contained or intersected by that argument.
>
> And this.
>
>> What do you guys think? Am I missing anything?
>
>> From the manual:
>
> \chapter{2D databases}
>
> 2Geom provides an implementation of a 2D database using quad trees and
> using a list.  Quad trees aren't the best data-structure for queries,
> but they usually out perform the linear list.  We provide a
> standard interface for object databases with performance guarantees
> and provide a set of useful operations Operations:
>
> \begin{description}
> \item[Insert:] given a bounding box and a 'reference', insert into the db
> \item[Delete:] given a bounding box and a 'reference', delete from the db
> \item[Search:] given a box, find all objects that may interact with this
> box
> \item[Cast:] given a path (including rays) return a list of objects that
> interact with the path, roughly sorted by path order
> \item[Shape query:] given a closed path, find all objects whose bounding
> boxes intersect path.  (this and cast are nearly the same)
> \item[Nearest:] given a point (or maybe box) find the nearest objects,
> perhaps as a generator to get all objects in order.  To do this, we walk
> around the quad tree neighbourhood, pushing all the elements into a
> priority queue, while the queue is empty, move out a bit.  Nearest could
> be manhattan, max norm or euc?
> \item[Binary:] take two dbs, generate all pairs that have intersecting
> boxes.
> \item[Sweep:] traverse the tree in say y order, maintaining a y-range of
> relevant objects. (to implement sweepline algorithms)
> \item[Walk:] traverse the tree in an arbitrary order.
> \end{description}
>
> njh
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Lib2geom-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
>

Re: [Lib2geom-devel] Requirements for lib2geom spatial index...

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

On Fri, 20 Apr 2007, Sunburned Surveyor wrote:

> lib2geom spatial index. I want to have these in mind when I start to look at
> the existing quadtree class.
>
> Requirement #1: The spatial index should not be limited to a fixed size.

The existing quadtree does this.

> Requirement #2: The spatial index should offer the ability for efficient
> updates.

It does this.

> Requirement #3: The spatial index should present a simple API for its basic
> functionality. In other words it shoud have a method that accepts a
> rectangle or envelope and returns a list of the geometries that are
> contained or intersected by that argument.

And this.

> What do you guys think? Am I missing anything?

>From the manual:

\chapter{2D databases}

2Geom provides an implementation of a 2D database using quad trees and
using a list.  Quad trees aren't the best data-structure for queries,
but they usually out perform the linear list.  We provide a
standard interface for object databases with performance guarantees
and provide a set of useful operations Operations:

\begin{description}
\item[Insert:] given a bounding box and a 'reference', insert into the db
\item[Delete:] given a bounding box and a 'reference', delete from the db
\item[Search:] given a box, find all objects that may interact with this 
box
\item[Cast:] given a path (including rays) return a list of objects that 
interact with the path, roughly sorted by path order
\item[Shape query:] given a closed path, find all objects whose bounding 
boxes intersect path.  (this and cast are nearly the same)
\item[Nearest:] given a point (or maybe box) find the nearest objects, 
perhaps as a generator to get all objects in order.  To do this, we walk 
around the quad tree neighbourhood, pushing all the elements into a 
priority queue, while the queue is empty, move out a bit.  Nearest could 
be manhattan, max norm or euc?
\item[Binary:] take two dbs, generate all pairs that have intersecting 
boxes.
\item[Sweep:] traverse the tree in say y order, maintaining a y-range of 
relevant objects. (to implement sweepline algorithms)
\item[Walk:] traverse the tree in an arbitrary order.
\end{description}

njh

Re: [Lib2geom-devel] Requirements for lib2geom spatial index...

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

Doh, forgot to write anything for #3:

Requirement #3: The spatial index should present a simple API for its basic
> functionality. In other words it shoud have a method that accepts a
> rectangle or envelope and returns a list of the geometries that are
> contained or intersected by that argument.
>

 Defintely a good idea.  Another query function might be nearest geometry
(to a point).   I suppose this one might require that the geometry
implements functions to perform this.  It might be valuable to have 3
listing functions - one for containment, one for partial intersection, and
one for containment or intersection.  For now just the
containment+intersection one may be enough, but for a renderer it may be
valuable to treat the geometries which require culling/triming specially.

-Michael Sloan

Re: [Lib2geom-devel] Requirements for lib2geom spatial index...

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

> Hey guys. I always try to sketch out a basic design for my code before a
> start writing classes. It usually helps to think about the problem I'm
> trying to solve and what basic requirements my code will need to meet. I
> wanted to share what I thought would be some good requirements for a
> lib2geom spatial index. I want to have these in mind when I start to look at
> the existing quadtree class.
>

Sounds good -  we tend to jump into coding, and then design it right, but
your strategy is likely better.

Requirement #1: The spatial index should not be limited to a fixed size. At
> a minimum, it should be able to expand in size. If possible, it should be
> able to contract in size. (I'm not speaking of computer memory consumed when
> I say "size" in this context. I mean the limits of the space or area being
> indexed.)
>

Good!

Requirement #2: The spatial index should offer the ability for efficient
> updates. In other words, you shouldn't have to determine where every
> geometry belongs in the index when a geometry is (a) added to the index (b)
> removed from the index, or (c) a geometry in the index is modified.
>

Hmm, I'm not sure if A is feasible.  B and C could be implemented with a
hash table.  I suppose C could also be implemented with pointers and
mutability, though mutability in general could easily throw off a spatial
index.  Really C is just a combination of B and A.

Requirement #3: The spatial index should present a simple API for its basic
> functionality. In other words it shoud have a method that accepts a
> rectangle or envelope and returns a list of the geometries that are
> contained or intersected by that argument.
>



What do you guys think? Am I missing anything?
>

Sounds like you have a pretty good plan/design going, I'd implement what
you've thought up - what's needed later can be added.

P.S. - Do you guys have a class template I can use for lib2geom? If not,
> could I make one?
>

We don't - C++ isn't necessarily one class per file.  Functions don't even
need to be in classes.

Still, might be a good idea - it could include the license (with spots to
insert creator and date), an include guard, the namespace decl, a class
decl, and the editor footer.

Re: [Lib2geom-devel] API Documentation for lib2geom?

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

Where we have code docs, either it's plain comments before the functions or
in doxygen format.

We are still figuring out the best way to do api docs.  I dislike in-code
comments because they tend to lead to very sparse documentation, often times
with repition of information you already know.  The valuable sort of docs
give you valuable information about the usage and quirks of functions and
classes.  Another problem is the seperation of prose and api docs.  I think
we'd prefer there to be just one manual, readable as a manual and jumpable
like api docs.  Another desirable feature is the ability to jump to the
pretty-printed code definition of a function.  We would also like to
integrate math and illustration.

I haven't found a system that does all this, but then again, I haven't
looked very hard.

-Michael Sloan

On 4/20/07, Sunburned Surveyor <sun...@gm...> wrote:
>
> I'm afraid I must ask another question born of my ignorance as a Java
> developer. Does the lib2geom or inkscape development teams have a standard
> format that they use for API documention? Java has Javadoc, other projects
> use DOxygen, Python has EPydoc...
>
> What do you use for C++?
>
> I always try to write good Javadoc comments for my Java code, and want to
> start building good code documentation habbits as a C++ developer. :]
>
> Thanks for the input.
>

[Lib2geom-devel] Requirements for lib2geom spatial index...

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

Hey guys. I always try to sketch out a basic design for my code before a
start writing classes. It usually helps to think about the problem I'm
trying to solve and what basic requirements my code will need to meet. I
wanted to share what I thought would be some good requirements for a
lib2geom spatial index. I want to have these in mind when I start to look at
the existing quadtree class.

Requirement #1: The spatial index should not be limited to a fixed size. At
a minimum, it should be able to expand in size. If possible, it should be
able to contract in size. (I'm not speaking of computer memory consumed when
I say "size" in this context. I mean the limits of the space or area being
indexed.)

Requirement #2: The spatial index should offer the ability for efficient
updates. In other words, you shouldn't have to determine where every
geometry belongs in the index when a geometry is (a) added to the index (b)
removed from the index, or (c) a geometry in the index is modified.

Requirement #3: The spatial index should present a simple API for its basic
functionality. In other words it shoud have a method that accepts a
rectangle or envelope and returns a list of the geometries that are
contained or intersected by that argument.

What do you guys think? Am I missing anything?

Scott Huey

P.S. - Do you guys have a class template I can use for lib2geom? If not,
could I make one?

[Lib2geom-devel] API Documentation for lib2geom?

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

I'm afraid I must ask another question born of my ignorance as a Java
developer. Does the lib2geom or inkscape development teams have a standard
format that they use for API documention? Java has Javadoc, other projects
use DOxygen, Python has EPydoc...

What do you use for C++?

I always try to write good Javadoc comments for my Java code, and want to
start building good code documentation habbits as a C++ developer. :]

Thanks for the input.

Re: [Lib2geom-devel] Question about the lib2geom coordinate system.

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

I think it's much more pure to not include a matrix with all objects.  This
has actually given me an idea - a Transformed<> template! may be useful in
inkscape, anyway.  The main reason for this is that it removes matrices and
related code from seperate concepts, like paths , curves, etc.  Another
reason is possible future optimizations - immutable objects might memoize
conversions, for example.

On 4/17/07, MenTaLguY <me...@ry...> wrote:
>
> On Tue, 17 Apr 2007 08:35:12 -0700, "Sunburned Surveyor" <
> sun...@gm...> wrote:
> > For a spatial index to work won't I need to have geometries on a common
> > coordinate system?
>
> Yes.  Each spatial index would need to have its own "global" coordinate
> system, and either all geometric objects in the index would be assumed to be
> in that coordinate system, or each object's entry in the index would need to
> be accompanied by a transformation from the object's coordinate system to
> the index's.
>
> I'm not sure which is better really.
>
> -mental
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Lib2geom-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
>

[Lib2geom-devel] Stream Fusion

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

Somewhat related to that other paper:

 http://www.cse.unsw.edu.au/~dons/papers/CLS07.html

-mental

Re: [Lib2geom-devel] Question about the lib2geom coordinate system.

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

On Tue, 17 Apr 2007 08:35:12 -0700, "Sunburned Surveyor" <sun...@gm...> wrote:
> For a spatial index to work won't I need to have geometries on a common
> coordinate system?

Yes.  Each spatial index would need to have its own "global" coordinate system, and either all geometric objects in the index would be assumed to be in that coordinate system, or each object's entry in the index would need to be accompanied by a transformation from the object's coordinate system to the index's.

I'm not sure which is better really.

-mental

Re: [Lib2geom-devel] Question about the lib2geom coordinate system.

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

I understand now that every geometry in lib2geom maintains its own
"coordinate system". I am curious how this will work with the spatial index.
For a spatial index to work won't I need to have geometries on a common
coordinate system?

Perhaps this is a foolish question.

Scott


On 4/16/07, mgsloan <mg...@gm...> wrote:
>
> On 4/16/07, MenTaLguY <me...@ry...> wrote:
> >
> > On Mon, 16 Apr 2007 14:04:46 -0700, "Sunburned Surveyor" <
> > sun...@gm...> wrote:
> > > I know that SVG uses a coordinate system in which the "X" or
> > "northing"
> > > coordinate value increases as you move "down" the screen or page. Is
> > this
> > > the coordinate system that lib2geom uses, or does the library employ a
> > > more typical coordinate system in which the "X" or "northing"
> > coordinate value
> > > decreases as you move "down" the screen or page.
> > >
> > > If lib2geom does not use the SVG coordinate system, does it provide
> > code
> > > to do the translation?
> >
> > The short answer is that (ideally) nothing in lib2geom really
> > cares.  The ultimate interpretation of the coordinate system is up to the
> > client.
> >
>
> Yeah, I've gotten in trouble for making methods like cw (clockwise) and
> ccw (counter-clockwise) before, as these would imply a particular coordinate
> system (or at least, the desired behavior varies depending on your view of
> the coord sys).
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Lib2geom-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
>
>

Re: [Lib2geom-devel] Getting Started

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

On 4/16/07, Sunburned Surveyor <sun...@gm...> wrote:
>
> Guys,
>
> I was able to donwload the daily snapshot of the SVN for lib2Geom. I
> printed out the code for the Rect class and the Quadtree class so that I can
> review them later. I was hoping you guys might be able to help me with a few
> questions I came up when I cracked my C++ book and started to think about my
> first lib2geom programming task.
>

One thing to keep in mind, which I neglected to mention, is that the code is
liable to change quite a bit.  While the interface and basic concept of Rect
will likely remain, it will probably be reimplemented in terms of Interval
within the next few weeks.

Oh, and the manual is a good resource, all though it lacks most of our newer
developments/rearchitecurizing, and tends to focus on trivial things (my
bad, really - I established a solid foundation yet haven't followed through
with real content).  Nonetheless, there's good information in there, and a
read through would be beneficial.

-mgsloan