RE: [Inkscape-devel] Google Summer of Code updates needed
I'll fill you guys in now :) There's a business center around here that has Internet access, so I'm using their facilities right now. I'm not sure if I can hook up my laptop and do a CVS commit from here, but I'll give it a try soon.
Apologies if this mail is received as an HTML mess -- I have to use the Outlook web interface, and I'm not quite sure how to tell it to format as plain text...anyway.
The modifications to configure.ac are complete, and compiling with/without the whiteboard code works fine, so that's all ready to go.
On the subject of required libraries: the whiteboard code, as of yesterday, also depends on Boost v1.31.0+ for functor argument binding, smart pointers, and some miscellaneous utility classes. I think it's possible to just include the required Boost files with the Inkscape source distribution (they're all self-contained template classes as far as I can tell), but I'll leave it out for now until given the OK for inclusion.
-- David
________________________________
From: inkscape-devel-admin@lists.sourceforge.net on behalf of Ted Gould Sent: Thu 7/28/2005 7:30 PM To: Bryce Harrington Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Google Summer of Code updates needed
Quick update because David is without Internet access for the next few days. He can fill in more when he gets back.
He's about ready to commit but I asked him to make some changes to configure.ac so that it will detect loudmouth, and not compile the whiteboard stuff if it isn't available. He just needs to test that feature before committing.
--Ted
Bryce Harrington wrote:
Hi all!
One of the key, oft-proven principles of Open Source development is "Release Early, Release Often". This is important because it makes it easier for other people to help you.
I think for our Google Summer of Code students, it will be vital for their learning about Open Source processes to go through at least a couple releases, so they can see how this works in practice.
I know it's a bit different from what we're trained in school to do; in school you have a due date and you (in theory) work on your assignment in secret from other students, and turn it in at the end. Open Source is very different; it's like you take your half-finished assignment to the clubhouse and trade answers with everyone else, and the more you cross-check with each other, the more likely everyone is to get a perfect score. ;-)
Anyway, with the 0.42 release wrapping up, we're at a point where we're ready to integrate work from the Google Summer of Code students.
Michael, David, Greg, and Matthew, can each of you report in on where you are in your work, how we can help you, and what you might be able to add to CVS within the next week or so?
(Also, if you have any questions about getting access to or using CVS, please just ask and we'll get you set up.)
Thanks, Bryce
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Thu, 2005-07-28 at 21:53 -0500, Yip, David W wrote:
On the subject of required libraries: the whiteboard code, as of yesterday, also depends on Boost v1.31.0+ for functor argument binding, smart pointers, and some miscellaneous utility classes. I think it's possible to just include the required Boost files with the Inkscape source distribution (they're all self-contained template classes as far as I can tell), but I'll leave it out for now until given the OK for inclusion.
Hmm, once you commit I'd like to go through the code a little. I'd really, really like to avoid introducing smart pointers into the codebase in the long-term if I can help it.
-mental
On Jul 28, 2005, at 8:12 PM, MenTaLguY wrote:
Hmm, once you commit I'd like to go through the code a little. I'd really, really like to avoid introducing smart pointers into the codebase in the long-term if I can help it.
Hmmm....
Is this the point where I chime in with some exaggerated exclamation?
:-)
Jon A. Cruz wrote:
On Jul 28, 2005, at 8:12 PM, MenTaLguY wrote:
Hmm, once you commit I'd like to go through the code a little. I'd really, really like to avoid introducing smart pointers into the codebase in the long-term if I can help it.
Hmmm....
Is this the point where I chime in with some exaggerated exclamation?
Out of curiosity, any specific reasons for not using smart pointers? (I'm not saying that I think you should, just interested in general reasons not to use them) Or is it just a matter of not wanting to put smart pointers into the mix of explicitly managed memory and garbage collected memory that already exists (if I understood correctly).
On Sun, 2005-07-31 at 11:31 +0200, Jasper van de Gronde wrote:
Out of curiosity, any specific reasons for not using smart pointers? (I'm not saying that I think you should, just interested in general reasons not to use them) Or is it just a matter of not wanting to put smart pointers into the mix of explicitly managed memory and garbage collected memory that already exists (if I understood correctly).
That and the fact that smart pointers invariably introduce a high hidden performance cost, yes.
Applications using smart pointers pervasively invariably die a death of a thousand cuts performance-wise. Even if you can inline the ref()/unref() functions, you're still paying a nasty cache penalty every time you have to touch the refcount member.
It wouldn't be bad if smart pointers were smart enough to elide unneeded ref()/unref() cycles (so it would then be more equivalent to explicit refcounting performance-wise), but there's no way for them to perform that sort of high-level optimization in most cases. So you end up paying the penalty for every trival smart pointer operation...
-mental
On Jul 31, 2005, at 9:58 AM, MenTaLguY wrote:
On Sun, 2005-07-31 at 11:31 +0200, Jasper van de Gronde wrote:
Out of curiosity, any specific reasons for not using smart pointers? (I'm not saying that I think you should, just interested in general reasons not to use them) Or is it just a matter of not wanting to put smart pointers into the mix of explicitly managed memory and garbage collected memory that already exists (if I understood correctly).
That and the fact that smart pointers invariably introduce a high hidden performance cost, yes.
And in general, unless a language was designed with garbage collection to begin with, it's very difficult to retrofit it. Smart pointers try to hide a lot of details from the developers. Sometimes that's good. But then sometimes hiding those details causes more problems that it fixes (especially if you think of developers thinking alloc stuff is now magically taken care of, and thus not taking enough care on the edge cases, etc).
On Thu, Jul 28, 2005 at 09:53:54PM -0500, Yip, David W wrote:
I'll fill you guys in now :) There's a business center around here that has Internet access, so I'm using their facilities right now. I'm not sure if I can hook up my laptop and do a CVS commit from here, but I'll give it a try soon.
Apologies if this mail is received as an HTML mess -- I have to use the Outlook web interface, and I'm not quite sure how to tell it to format as plain text...anyway.
The modifications to configure.ac are complete, and compiling with/without the whiteboard code works fine, so that's all ready to go.
Thanks for the update David, glad to hear things with the laptop are resolving.
Bryce
participants (5)
-
Bryce Harrington -
Jasper van de Gronde -
Jon A. Cruz -
MenTaLguY -
Yip, David W