February 2005 - Inkscape Devel

RE: [Inkscape-devel] Inkboard linking/dependencies
by Montgomery, Steven S 05 Feb '05

05 Feb '05

I've went ahead and included the extern lines: however, that's a different issue than what we were having. The undefined reference we have is to functions we wrote in inkboard.cpp. Here they are from the most recent attempt: dialogs/libspdialogs.a(InkboardMsg.o)(.text+0xa7a): In function `sp_inkBMsg_ObjectAddedChild': dialogs/InkboardMsg.cpp:436: undefined reference to `sendChange(char*)' dialogs/libspdialogs.a(InkboardMsg.o)(.text+0xc92): In function `sp_inkBMsg_ObjectRemovedChild': dialogs/InkboardMsg.cpp:519: undefined reference to `sendChange(char*)' dialogs/libspdialogs.a(InkboardMsg.o)(.text+0xe4d): In function `sp_inkBMsg_ObjectChanged': dialogs/InkboardMsg.cpp:624: undefined reference to `sendChange(char*)' dialogs/libspdialogs.a(inkboard-connect.o)(.text+0xa97): In function `sp_inkboardConnect_dialog_inkboardConnect(_GObject*, _GObject*)': dialogs/inkboard-connect.cpp:228: undefined reference to `connect_and_auth(char*, char*, char*)' dialogs/libspdialogs.a(inkboard-connect.o)(.text+0xacf):dialogs/inkboard -connect.cpp:238: undefined reference to `setRecipient(char const*)' dialogs/libspdialogs.a(inkboard-connect.o)(.text+0x138f): In function `sp_inkboardConnect_dialog_inkboardShareUser(_GObject*, _GObject*)': dialogs/inkboard-connect.cpp:393: undefined reference to `send_connect_request_to_user(char const*, char*)' I suspect you didn't get that error when you checked out of the CVS. Line 8 of inkboard.cpp should be #include "dialogs/InkboardMsg.h" instead of #include "dialogs/InkboardMsg.cpp". I hesitate to upload that change since we've been following the convention of only committing changes after we ensure that it at least compiles. For a reason I don't fully understand, including that .cpp somehow informs the linker of where our new functions are defined. Thanks for the help on this. Steven -----Original Message----- From: inkscape-devel-admin(a)lists.sourceforge.net [mailto:inkscape-devel-admin@lists.sourceforge.net] On Behalf Of Bryce Harrington Sent: Friday, February 04, 2005 1:43 AM To: Montgomery, Steven S Cc: inkscape-devel(a)lists.sourceforge.net Subject: RE: [Inkscape-devel] Inkboard linking/dependencies On Thu, 3 Feb 2005, Montgomery, Steven S wrote: > No, we don't have our code linking normally. Since it was such a > brickwall for our progress, we moved the Jabber code into a file we > added under dialogs(where it was being called from). Obviously this > links, but we definitely would like to separate the code back out how it > should be. > > I've seen some recent posts about automake 1.9 causing problems for some > people. Perhaps that is our issue as well? Okay, I think we got this one figured out tonight. Check out our discussion in today's jabber logs here: http://inkscape.gristle.org/2005-02-03.txt Basically, loudmouth is set up to link in C style but since Inkscape is C++, libs are linked in C++ style. You can direct the linker to link the loudmouth functions in C style like this: diff -p -u -r1.4 inkboard.h --- inkboard.h 3 Feb 2005 20:19:33 -0000 1.4 +++ inkboard.h 4 Feb 2005 06:21:55 -0000 @@ -1,7 +1,10 @@ //Inkboard.h +extern "C" { #include <loudmouth/loudmouth.h> +}; + //#include "inkboard-TimedMessageNode.h" #define TEST_RECEPTION 1 Bryce ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

2 1

[0.41] Possible bezier test fix
by Peter Moulder 05 Feb '05

05 Feb '05

As mentioned on jabber, i haven't even *compiled* this patch yet, let alone checked whether it fixes the test failure. I send it now because it's bed time, and it'll take a while on this machine to compile with optimization enabled. (The test doesn't fail without optimization enabled, on my machine.) As usual, the patch is relative to the src/ directory. pjrm.

1 0

0.41 "make check" progress
by Kees Cook 05 Feb '05

05 Feb '05

Peter and I managed to nail down almost all the issues with "make check". This patch includes Peter's earlier ones, and is almost entirely changes to test code, or Makefile goo. There are still two tests failing (and unless they're simple, I would vote to ignore them, since I'm not sure they were run for the 0.40 release... anyone know?) src/xml/repr-action-test src/display/bezier-utils-test I'll try to get 0.41pre1 packaged tomorrow. (This patch does not, however, include mental's update, which I think looks fine to go in.) -- Kees Cook @outflux.net

1 0

[0.41] Fix style-test failure
by Peter Moulder 05 Feb '05

05 Feb '05

The attached patch makes style-test pass. style-test.cpp hadn't been updated for Bulia's addition of basic support for the `overflow' property in style.cpp v1.80. Rationale for inclusion in 0.41: i) Safety: Touches only a regression test, not inkscape/inkview themselves. ii) Needed (though not sufficient) for `make distcheck' / `make check' to work. Suggested cvs comment: Minimal update for supporting overflow property. (Doesn't test overflow, just updates expected result of existing tests.) Again, the patch is relative to the src/ directory. pjrm.

1 0

[0.41] Move gc-related files to libinkpost.a, for `make check'
by Peter Moulder 05 Feb '05

05 Feb '05

libinkpost.a is supposed to contain files needed by subdirs, according to the comment. In particular, a few unit test programs in subdirectories link against libinkpost.a but not libinkpre.a. It seems useful to maintain this distinction: reduced link times, and it facilitates debugging of some link-related bugs (e.g. the recent mips problem) to have different executables link against different subsets of the .a files. The attached patch moves gc-related files from libinkpre.a to libinkpost.a. According to nm, the relevant two .o files (gc.o and gc-anchored.o) don't depend on any other object files, whereas very many files depend on gc-anchored.o, and many of the main-containing files depend on gc.o. pjrm.

1 0

Hard Freeze for 0.41 Release
by Bryce Harrington 05 Feb '05

05 Feb '05

As of now, 11:00pm PST 2/4/05, Inkscape is in "Hard Freeze" mode. During this phase, no commits to CVS are allowed without formal approval from the "Freeze Wardens". For this release, the Freeze Wardens are Bulia Byak and Kees Cook. Both must okay any change to the codebase (including changes that they themselves create). The fundamental idea behind a Hard Freeze is to slow down changes to the codebase, and achieve some quiescence to give room for the changes specifically needed to ensure a quality release. This also allows each of us to doublecheck the final code to make sure all the i's are dotted and t's crossed. If you feel it is critical to get a last minute change in, that's fine. Please submit them as patches (using 'cvs diff -puN') and email them to the Freeze Wardens for review and incorporation (or postponement) at their discretion. The Freeze Wardens will decide when the Hard Freeze is over. They will establish a branch tag and declare it ready for release. It is assumed this may take a few days but less than a week. Once the code is branched and tagged, the Hard Freeze will end, and the Release Phase will begin. The release branch will be used for preparing packages, while the mainline branch will be returned to regular open development. Bryce

1 0

no xmlns crash
by Aaron and Sarah Spike 05 Feb '05

05 Feb '05

I have some files created by hand and some generated by batik that crash on loading. From what I can tell the crash is caused because my files don't have xmlns="http://www.w3.org/2000/svg" in the svg tag. The files cause no trouble with the adobe plugin. Requiring the namespace declaration is great. Inkscape should reject improperly formed files with out crashing right? Aaron Spike

5 5

Re: win32 GTK
by Bob Jamison 05 Feb '05

05 Feb '05

Actually, I was considering something radically different.. If it is possible, it would be good if we could build the entire tree from source ourselves with the cross-compiler (or maybe mingw). Then we could have any configuration we want, and not need to beg & borrow dll's from other people. Does this sound like an idea? Bob Kees Cook wrote: >Hey Bob. I was looking at the GTK packaged for Gimp, Ethereal, and >Gaim, and was thinking about trying to switch to it (after the 0.41 >release). Have you looked at this at all? It looks like it may fix a >number of weird problems we've had. > > >

3 2

Coming Hard Freeze tonight
by Bryce Harrington 04 Feb '05

04 Feb '05

It sounds like we're about ready for going into the final Hard Freeze, so I'd like to propose we do so in 12 hours from now: 11pm PST 2/4. During the Hard Freeze, no changes to CVS should be made without review and approval. Work should be limited to critical bug fixes, packaging, and release-related activity only. I think it was effective to have a pair of reviewer/approvers to keep an eye on the codebase for the hard freeze period in the 0.40 release. Last time, mental and bulia performed this function. For this release, I'd like to ask bulia and kees to perform this function. I know mental has been extremely busy with work, so I suspect he'd like to conserve what Inkscape time he has for finishing up his own work. Kees has been extremely active in bug fixing this release, so I think he'd be an excellent person for this role. (Maybe we can make this a rotating position for future releases.) Bryce

4 8

honoring presserveAspectRatio
by Edward Flick 04 Feb '05

04 Feb '05

Hello everyone, Is the freeze tonight going to mean that there will be no more added features until 1.0? Or just a feature freeze for 4.1? Also, I have just posted a suggestion on the list that the preserveAspectRatio attribute be added/honored. I wouldn't mind doing this myself, although I am new to the project and could use a couple of pointers on where I should make the necessary changes. Would anyone be interested in this? Ed

2 1