July 2009 - Inkscape Devel - Inkscape Mailman

[OS X] 0.47pre1 from sf.net hangs when launched (was Re: Inkscape doens't start anymore)
by ~suv 20 Jul '09

20 Jul '09

[full quote to the list] On 14/7/09 16:35, Giovanni wrote: > Dear ~suv, > > thanks for the reply. > > On Tue, Jul 14, 2009 at 4:10 PM, ~suv<suv-sf@...58...> wrote: >> Which exact versions do you have installed? > - OS X 10.5.7 > - XQuartz 2.3.3.2 (xorg-server 1.4.2-apple42) > (from xquartz.macosforge.org) > - Inkscape 0.47pre1 r21720, built Jul 6 2009 > (from sf.net) > >> 1) Can you test that there's no conflict resulting from both (macports >> install, packaged build from sf.net) using the same user configuration >> files? >> >> Move/rename the config directories in $HOME: >> ~/.config/inkscape (0.46+devel, 0,47pre) >> ~/.inkscape (0.46) >> ~/.inkscape-etc >> other config files used by the macports install? >> then start the packaged prerelease version again. Any interesting >> console.log msgs? Do not mix running two installed versions without >> again renaming the config dirs until you can rule out that it is part of >> the problem. > > If I understood it good: I removed the three directories you > mentioned. I started the precompiled Inkscape (0.47pre1 from sf.net) > but still with no luck (Console logs end with > > Jul 14 16:25:47 92 [0x0-0x56056].org.inkscape.Inkscape[30111]: > Emergency save activated! > Jul 14 16:25:47 92 [0x0-0x56056].org.inkscape.Inkscape[30111]: > Emergency save completed. Inkscape will close now. > Jul 14 16:25:47 92 [0x0-0x56056].org.inkscape.Inkscape[30111]: If you > can reproduce this crash, please file a bug at www.inkscape.org > Jul 14 16:25:47 92 [0x0-0x56056].org.inkscape.Inkscape[30111]: with a > detailed description of the steps leading to the crash, so we can fix > it. > > ) > >> 2) do you have any suspicious fonts installed? >> Check all font directories (/System/Library/Fonts, /Library/Fonts, >> ~/Library/Fonts, ~/.fonts) for possibly corrupt fonts, move them out of >> the fonts folder, then clean Inkscape's fontcache: >> move/rename >> ~/.fontconfig >> and restart X11 and Inkscape.app. Any changes? > > I removed .fontconfig, restarted everything, but still no luck. > >> 3) what about other X11 applications like 'GIMP on OS X' from >> gimp.lisanet.de? Do they launch without problems? >> > > I compiled myself the Inkscape package now (following the wiki > instructions), and my version work. I.e. the Inkscape.app produced by > > ./osx-build.sh a c b i -s p > > does work normally (it is a .app therefore, it doesn't have anything > to do with macports, except it was compiled using its libraries). The > Gimp also works. > > I really don't know what it could be. To summarized > > 1. I deleted .config/inkscape .inkscape .inkscape-etc .fontconfig but > Inkscape.app from sf.net doesn't start. The errors are as in my first > message. > > 2. Inkscape package done by me: works. > > 3. Inkscape compiled with MacPorts: works. > > 4. Inkscape from sf.net was working one week ago. > > If needed, this is the report from the Crash Reporter > > > Date/Time: 2009-07-14 16:28:12 +0200 > OS Version: 10.5.7 (Build 9J61) > Architecture: i386 > Report Version: 4 > > Command: Inkscape > Path: /Users/gio/Applications/Inkscape.app/Contents/MacOS/Inkscape > Version: 0.47pre1 (0.47pre1) > Parent: launchd [166] > > PID: 30111 > Event: hang > Time: 6.65s > Steps: 38 > > > Process: Inkscape [30111] > Path: /Users/gio/Applications/Inkscape.app/Contents/MacOS/Inkscape > > ADDRESS BINARY > 00001000 /Users/gio/Applications/Inkscape.app/Contents/MacOS/Inkscape > 00021000 > /System/Library/Components/AppleScript.component/Contents/MacOS/AppleScript > 000cc000 /Library/ScriptingAdditions/LCC Scroll Enhancer > Loader.osax/Contents/MacOS/LCC Scroll Enhancer Loader > 000d4000 /Library/Application > Support/Logitech.localized/Logitech Control Center.localized/LCC > Scroll Enhancer.bundle/Contents/MacOS/LCC Scroll Enhancer > 00300000 > /System/Library/PrivateFrameworks/AppleScript.framework/Versions/A/AppleScript > 1544f000 > /System/Library/CoreServices/RawCamera.bundle/Contents/MacOS/RawCamera > > Thread id: 5226128 > User stack: > 38 start + 41 (in Inkscape) [0x1e99] > 38 __start + 216 (in Inkscape) [0x1f72] > 38 _main + 1228 (in Inkscape) [0x2bae] > 38 _RunApplicationEventLoop + 222 (in HIToolbox) [0x951932a2] > 38 _ToolboxEventDispatcher + 86 (in HIToolbox) [0x95196a4c] > 38 _SendEventToEventTarget + 52 (in HIToolbox) [0x95129eac] > 38 > __Z30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec > + 405 (in HIToolbox) [0x9510d55b] > 38 > __Z23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec > + 2134 (in HIToolbox) [0x9510e4d6] > 38 > __Z29ToolboxEventDispatcherHandlerP25OpaqueEventHandlerCallRefP14OpaqueEventRefPv > + 356 (in HIToolbox) [0x9513bd34] > 38 _SendEventToEventTargetWithOptions + 58 (in > HIToolbox) [0x9510d3c0] > 38 > __Z30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec > + 405 (in HIToolbox) [0x9510d55b] > 38 > __Z23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec > + 1181 (in HIToolbox) [0x9510e11d] > 38 _FCCacheFailedHandler + 250 (in > Inkscape) [0x2176] > 38 ___wait4_nocancel + 10 (in > libSystem.B.dylib) [0x93caf18e] > > > Thanks again for your attention and your time. > > Giovanni > I have no answer nor do I know where to continue to search. what I can take from the crash report: FCCacheFailedHandler is the 'Handler for when fontconfig caches need to be generated', defined in <http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/packagin…>, the launcher app based on (an old version of) Platypus. This again points to a font issue - did you have a look at your installed fonts? (font management with/in 'Font Book' has no influence on which fonts inkscape / X11 sees -> Contents/Resources/etc/fonts/font.conf defines the included font directories for inkscape) But JiHO or Michael would know better how to read the crash report. ~suv

3 9

Re: [Inkscape-devel] inkscape - regular win builds
by Bob Jamison 15 Jul '09

15 Jul '09

Hi again, all. I don't know if anyone noticed, but Mingw.org recently released the gcc 4.4.0 suite as a single bundle (you still need mingw-runtime and win32api). There were a couple of issues with how they package the stdc++ libs, but once that is fixed, it will be a great improvement to our builds. The big thing is that mingw will start using Dwarf2 exception handling by default (we jumped the gun a bit in switching to dw2). So we will be able to share our c++ libs with other projects now, such as Fedora-mingw. Also, Mingw has a new project, mingw-get, which is their version of a package and dependency manager. How cool is that? Something we have wanted for a long time. Wish them luck on that project. bob (ishmal) On 7/2/2009 8:10 AM, Donna Benjamin wrote: > Hey guys! > > James Turnbull can help out with regular windows builds of inkscape. > > Bob says he needs an account on Modevia so he can post 'em somewhere > useful... > > Hoping that by emailing all of you, you might be able to get the right > people in touch with each other to help get this sorted! > > :) > > cheers > Donna

2 2

GSoC 2009 - Midterm Evaluations
by Joshua A. Andler 15 Jul '09

15 Jul '09

Hey Mentors, As I am sure you are already aware, the midterm evaluations are available for you to fill out regarding the progress of your students. The surveys became available about 12 hours ago and they are due by the 13th (next Monday). To complete the surveys, please visit: http://socghop.appspot.com/ In the left menu, the links are toward the bottom and in red to help them stand out. If anyone has any questions or concerns, please let me know. Cheers, Josh CCing the devel-list so people know that we're halfway through SoC!

8 9

Updated bug hunt tally: 342/500
by Tavmjong Bah 15 Jul '09

15 Jul '09

The current bug hunt tally is now 342/500. Newly fixed bugs: 9 275519 Rintel ODG export produces corrupt files on x86_64 3 397793 hefee dxf import: encoding problem 6 398240 ScislaC Eraser width broken 12 171150 Cracan Connectors should always touch the shape boundary Note: Bug fixes must be marked in the bug tracker as Fixed Released or Fixed Committed to be counted. Tracked at: http://wiki.inkscape.org/wiki/index.php/Release_Info_for_0.47 Tav

1 0

pre1 not showing in Fedora testing repository
by MilesTogoe 15 Jul '09

15 Jul '09

just a note to say that the Fedora testing respository is still showing the pre0 (6/16) rather than the new pre1 (7/7).

2 1

Inkscape doens't start anymore
by Giovanni 14 Jul '09

14 Jul '09

Hi. I used to use Inkscape 0.46 and 0.47pre1 (the compiled packages found at www.inkscape.org) without any problems on my macbook pro, Os X 10.5, latest XQuartz. Until today. Now when I double click I get the icon in the dock, but nothing more. From the command line I get bash-3.2$ cd Applications/Inkscape.app/Contents/MacOS/ bash-3.2$ ./Inkscape 2009-07-14 12:57:24.549 defaults[23746:10b] The domain/default pair of (kCFPreferencesAnyApplication, AppleAquaColorVariant) does not exist 2009-07-14 12:57:24.563 defaults[23747:10b] The domain/default pair of (kCFPreferencesAnyApplication, AppleHighlightColor) does not exist (process:23726): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. Xlib: extension "RANDR" missing on display "/tmp/launch-I5F7mE/:0". Emergency save activated! Emergency save completed. Inkscape will close now. If you can reproduce this crash, please file a bug at www.inkscape.org with a detailed description of the steps leading to the crash, so we can fix it >From the Resources folder bash-3.2$ cd Applications/Inkscape.app/Contents/Resources/bin bash-3.2$ ./inkscape 2009-07-14 13:01:33.127 defaults[23825:10b] The domain/default pair of (kCFPreferencesAnyApplication, AppleAquaColorVariant) does not exist 2009-07-14 13:01:33.144 defaults[23826:10b] The domain/default pair of (kCFPreferencesAnyApplication, AppleHighlightColor) does not exist (process:23813): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. Xlib: extension "RANDR" missing on display "/tmp/launch-I5F7mE/:0". ** (inkscape-bin:23813): WARNING **: Null pixbuf for 0x2a6b6f0 [Contents/Resources/icons/remove-color.png] (inkscape-bin:23813): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_width: assertion `GDK_IS_PIXBUF (pixbuf)' failed (inkscape-bin:23813): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_height: assertion `GDK_IS_PIXBUF (pixbuf)' failed ** (inkscape-bin:23813): WARNING **: Null pixbuf for 0x2a6bd80 [Contents/Resources/icons/remove-color.png] (inkscape-bin:23813): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_width: assertion `GDK_IS_PIXBUF (pixbuf)' failed (inkscape-bin:23813): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_height: assertion `GDK_IS_PIXBUF (pixbuf)' failed ** (inkscape-bin:23813): WARNING **: Null pixbuf for 0x2a6c090 [Contents/Resources/icons/remove-color.png] (inkscape-bin:23813): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_width: assertion `GDK_IS_PIXBUF (pixbuf)' failed (inkscape-bin:23813): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_height: assertion `GDK_IS_PIXBUF (pixbuf)' failed ** (inkscape-bin:23813): CRITICAL **: Inkscape::XML::Document* sp_repr_read_file(const gchar*, const gchar*): a nkscape::IO::file_test( filename, G_FILE_TEST_EXISTS )' failed ** (inkscape-bin:23813): WARNING **: Unable to read keys file Contents/Resources/keys/default.xml Emergency save activated! Emergency save completed. Inkscape will close now. If you can reproduce this crash, please file a bug at www.inkscape.org with a detailed description of the steps leading to the crash, so we can fix it. and bash-3.2$ ./inkscape-bin dyld: Library not loaded: /opt/local/lib/libgsl.0.dylib Referenced from: /Users/gio/Applications/Inkscape.app/Contents/Resources/bin/./inkscape-bin Reason: image not found Trace/BPT trap But I'm still able to run the macports copy of Inkscape (the one I got with sudo port install inkscape ) any idea of what the problem might be, and how to solve it? Thanks Giovanni Lanzani

2 1

Re: [Inkscape-devel] CLAMP does not handle NaN correctly
by Peter Moulder 14 Jul '09

14 Jul '09

On Mon, Jul 13, 2009 at 08:48:00PM +0200, Diederik van Lierop wrote: > On 07/13/2009 05:26 AM, Peter Moulder wrote: >> I've changed libnr/nr-macros.h to prefer our version of CLAMP over glib's, >> and I've changed both sp-star.cpp and star-context.cpp to call NR_CLAMP >> explicitly, but I haven't been able to test here. >> >> Diederik, can you svn up and test please? > > Thanks for looking into this, this indeed fixed the issue! > > Can we now safely replace all occurrences of CLAMP with NR_CLAMP, with > the v0.47 release being this close? Or should we be safe and wait until > after the release? Some information relevant to the decision: - There are apparently 103 lines containing the word CLAMP in inkscape, including just one definition. ("Word" as in grep -w, so excluding CLAMP_D_TO_U8, NR_CLAMP, etc.) This is a bit much to analyse each one, though of course one could analyse just a few and change just a few. - Both versions are simple macros that evaluate their arguments multiple times. - NR_CLAMP requires that that the bounds be ordered (a <= b), and that neither is NaN. So when deciding whether or not to change a particular call of CLAMP to NR_CLAMP, we might take into consideration whether a,b are constants or not, or how certain we are that a <= b (and that neither is NaN). - glib CLAMP(val, a, b) returns NaN if val is NaN (regardless of the values of a,b); whereas NR_CLAMP returns a for this case[*1]. It seems unlikely that a caller within Inkscape would prefer NaN over a, though it's hard to say. If we don't do it before releasing 0.47, then I'd support doing it after 0.47, even if it were a blind search-and-replace; at least in the common case that a and b are constants and a < b. I see the trade-offs as: - For each individual call, it is likely that changing to NR_CLAMP will either make no functional change (e.g. NaN isn't possible, e.g. it's an int) or will be an improvement. - I would go so far as to say that it's unlikely that any caller will be worse off being changed to NR_CLAMP, and I'd guess that at least one caller will benefit in at least some circumstance (even if rare). - Although I don't follow inkscape bug reports very closely, I would guess that in practice it doesn't often cause serious bugs: because I would guess that any serious bug would have gotten attention and been fixed. (One might regard the current case as evidence either for or against this claim.) - The concern for holding off is of course that we might introduce a bug: maybe there's some code actually ends up behaving better if CLAMP returns NaN than _a, or maybe the slight different macro expansion properties cause a problem, or maybe we make a mistake when changing CLAMP to NR_CLAMP (and we might not notice the mistake if there are 102 callers), or maybe there's some problem I just haven't considered. There's some evidence that any existing bugs from use of CLAMP aren't too serious or common, whereas possibly an introduced bug will be serious (e.g. perhaps making some code not work at all rather than fail only in the rare occasion that NaN is encountered). There isn't much testing time remaining, which reduces the probability that any such serious bug would be found between committing the change and releasing 0.47. One of the changes I made to libnr/nr-macros.h was to make it override any existing definition of CLAMP from glib. Subject to anyone else's comments in the thread, I may revert that aspect of the change, just in case, though I think it should be re-instated after 0.47. pjrm. [*1] I have seen one or two inkscape bug reports whose symptoms indicate that some compiler used under Windows doesn't have correct NaN comparison behaviour. I don't know whether such a bug still exists in current compiler versions or not, or how common such a bug is.

1 0

CLAMP does not handle NaN correctly
by Diederik van Lierop 13 Jul '09

13 Jul '09

Hi all, While fixing a crash I noticed that the CLAMP macro does not handle NaN properly, although it is stated in its comments that it should ("returns v bounded to within [a, b]. If v is NaN then returns a."). Apparently, if NaN goes in, then NaN comes out :-(. I tried fixing this in the macro but I didn't succeed. Could one of the little-less-inexperienced devs have a look at this? This crash can be reproduced using revision 21793 or older: create a grid, draw a star, and snap both its handles to the same grid intersection. So far so good. Now try drawing a new star somewhere else and watch in horror! The "proportion" parameter of the star has become NaN, and remains NaN although it has been clamped in sp_star_context_set(). If I use this line for debugging (inserted on line 210 of star-context.cpp) std::cout << "CLAMP DOESN'T HANDLE NaN! Before clamping: " << val->getDouble(0.5) << " -> after clamping: " << sc->proportion << std::endl; Then this is what I get: CLAMP DOESN'T HANDLE NaN! Before clamping: nan -> after clamping: nan I fixed this for the star but there might be more instances of this bug. It might however save us some future headaches if someone could fix the CLAMP macro. Regards, Diederik

2 3

Re: [Inkscape-devel] rotating guides
by Diederik van Lierop 13 Jul '09

13 Jul '09

1 0

GSoC midterms
by Jon A. Cruz 13 Jul '09

13 Jul '09

Don't worry, I'm on track now for getting your midterm set, and those reviews, advice, etc you need. (Aside from everything else we just had a fun round of the family getting a quick flu... but real life will not defeat me now!)

1 0