Hi all,
Yesterday I had a chat with mgsloan about lib2geom integration for GSoC'08. We spoke about working together on it. He knows 2geom very well, I know Inkscape well and have worked with 2geom a lot for LPE. Because complete conversion to 2geom is a big task, where 2geom issues can become apparant, I think it is nice to have a 2geom developer working on it aswell (although I did commit some small things to 2geom, I do not count myself as a real 2geom developer). This way, we can both work and discuss things where we are uncertain. I hope to have a somewhat longer discussion with mgsloan within the next couple of days.
How do people feel about this?
Apart from having a 2-man team on lib2geom integration: I know I have been very brief in my gsoc proposal as blueprint. I am thinking about 1. writing test code (cxxtest) 2. integrating lib2geom in steps, for example per tool or per feature 3. switching to 2geom path representation in inkscape core is advanced task and should be tried later in the project 4. I'd rather *not* work in a branch, because then people that code new things will use 2geom instead of me/us having to recode new things to 2geom. (conflicts etc abound) 5. Release lib2geom after integration is complete. Not before integration is complete because of things that might be missing or bugged in 2geom.
Thanks for your opinion, Johan
On Fri, Mar 21, 2008 at 4:18 PM, <J.B.C.Engelen@...1578...> wrote:
Yesterday I had a chat with mgsloan about lib2geom integration for GSoC'08.
A general question: has anyone compared performance of 2geom with that of livarot for those tasks where we use livarot - boolops, offsets, etc?
Also, I'd like to nominate the tweak tool as a candidate for the conversion :) It uses livarot black magic and there are many problems with that (precision, autoclosing of open paths) that I have no idea how to fix with livarot.
On Fri, Mar 21, 2008 at 08:18:30PM +0100, J.B.C.Engelen@...1578... wrote:
Hi all,
Yesterday I had a chat with mgsloan about lib2geom integration for GSoC'08. We spoke about working together on it. He knows 2geom very well, I know Inkscape well and have worked with 2geom a lot for LPE. Because complete conversion to 2geom is a big task, where 2geom issues can become apparant, I think it is nice to have a 2geom developer working on it aswell (although I did commit some small things to 2geom, I do not count myself as a real 2geom developer). This way, we can both work and discuss things where we are uncertain. I hope to have a somewhat longer discussion with mgsloan within the next couple of days.
How do people feel about this?
Apart from having a 2-man team on lib2geom integration: I know I have been very brief in my gsoc proposal as blueprint. I am thinking about
- writing test code (cxxtest)
- integrating lib2geom in steps, for example per tool or per feature
- switching to 2geom path representation in inkscape core is advanced task and should be tried later in the project
- I'd rather *not* work in a branch, because then people that code new things will use 2geom instead of me/us having to recode new things to 2geom. (conflicts etc abound)
- Release lib2geom after integration is complete. Not before integration is complete because of things that might be missing or bugged in 2geom.
This all sounds good, and appropriate for fitting in with our refactoring goals. I hope there are also plans on doing some pre-releases of 2geom, so that if there are any issues that come up during linking/packaging/autoconf work, they can be addressed ahead of time.
Bryce
-----Original Message----- From: lib2geom-devel-bounces@lists.sourceforge.net [mailto:lib2geom-devel-bounces@lists.sourceforge.net] On Behalf Of bulia byak Sent: vrijdag 21 maart 2008 20:40 To: Engelen, J.B.C. (Johan) Cc: inkscape-devel@lists.sourceforge.net; lib2geom-devel@lists.sourceforge.net Subject: Re: [Lib2geom-devel] [Inkscape-devel] GSoC tag-team for lib2geomintegration
On Fri, Mar 21, 2008 at 4:18 PM, <J.B.C.Engelen@...1578...> wrote:
Yesterday I had a chat with mgsloan about lib2geom
integration for GSoC'08.
A general question: has anyone compared performance of 2geom with that of livarot for those tasks where we use livarot - boolops, offsets, etc?
I haven't heard of it. It's a good question :S
Also, I'd like to nominate the tweak tool as a candidate for the conversion :) It uses livarot black magic and there are many problems with that (precision, autoclosing of open paths) that I have no idea how to fix with livarot.
I think anything is nominated! I'll make a special note to get the tweak tool early in the process ;)
-johan
I'm developing lib2geom and sometimes I need to update the /2geom source code under inkscape, too.
Until now, Johan Engelen has always kindly synchronized the source code, but if I could have an inkscape svn write-enabled account this would speed up things. My sourceforge user name is: mcecchetti
Kind Regards, Marco Cecchetti
On Mon, Apr 28, 2008 at 04:42:34PM +0200, Marco wrote:
I'm developing lib2geom and sometimes I need to update the /2geom source code under inkscape, too.
Until now, Johan Engelen has always kindly synchronized the source code, but if I could have an inkscape svn write-enabled account this would speed up things. My sourceforge user name is: mcecchetti
Kind Regards, Marco Cecchetti
Welcome aboard Marco, and I look forward to seeing the 2geom integration move forward, and I very much look forward to seeing 2geom officially released.
Bryce
One of the requested features for Subversion is the ability to have something like "symlinks" in a tree, so that one SVN project could reference another. That way, a client project would get updates automatically, and also be able to contribute back with simple commits (if the user has commit privs, of course). I don't know the status of this. It would be especially useful for something like this.
bob
Bryce Harrington wrote:
On Mon, Apr 28, 2008 at 04:42:34PM +0200, Marco wrote:
I'm developing lib2geom and sometimes I need to update the /2geom source code under inkscape, too.
Until now, Johan Engelen has always kindly synchronized the source code, but if I could have an inkscape svn write-enabled account this would speed up things. My sourceforge user name is: mcecchetti
Bob Jamison wrote:
One of the requested features for Subversion is the ability to have something like "symlinks" in a tree, so that one SVN project could reference another. That way, a client project would get updates automatically, and also be able to contribute back with simple commits (if the user has commit privs, of course). I don't know the status of this. It would be especially useful for something like this.
I think that is call externals in svn.
http://svnbook.red-bean.com/en/1.0/ch07s03.html
Aaron
On Tue, 29 Apr 2008 02:46:41 +0200, Bryce Harrington <bryce@...1798...> wrote:
On Mon, Apr 28, 2008 at 04:42:34PM +0200, Marco wrote:
I'm developing lib2geom and sometimes I need to update the /2geom source code under inkscape, too.
Until now, Johan Engelen has always kindly synchronized the source code, but if I could have an inkscape svn write-enabled account this would speed up things. My sourceforge user name is: mcecchetti
Kind Regards, Marco Cecchetti
Welcome aboard Marco, and I look forward to seeing the 2geom integration move forward, and I very much look forward to seeing 2geom officially released.
Bryce
Thanks! I look forward for such goals, too. :-) I and Nathan will work hard this summer to make 2geom even more powerful and reliable.
Kind Regards, Marco
On Mon, 28 Apr 2008 19:51:55 -0500, Bob Jamison <rwjj@...127...> wrote:
One of the requested features for Subversion is the ability to have something like "symlinks" in a tree, so that one SVN project could reference another. That way, a client project would get updates automatically, and also be able to contribute back with simple commits (if the user has commit privs, of course). I don't know the status of this. It would be especially useful for something like this.
Please no. SVN externals are made of pain and fail. It should be obvious why, if you think about it -- the external and local versions are not locked in sync, so you can't get a "known good" configuration when doing e.g. regression testing.
Every project I've been in that has used svn externals has eventually abandoned them for that reason.
-mental
MenTaLguY wrote:
Please no. SVN externals are made of pain and fail. It should be obvious why, if you think about it -- the external and local versions are not locked in sync, so you can't get a "known good" configuration when doing e.g. regression testing.
I don't understand the issue in full. I'm not advocating it, just trying to understand the issues. What would happen if the extern definition pointed to a branch on the remote side rather than trunk?
Aaron Spike
participants (7)
-
unknown＠example.com -
Aaron Spike -
Bob Jamison -
Bryce Harrington -
bulia byak -
Marco -
MenTaLguY