Win32 nightly builds don't work since Aug 16

[Alvin Penner]

this is just an attempt to bump the priority of https://bugs.launchpad.net/inkscape/+bug/259237 and http://sourceforge.net/mailarchive/forum.php?thread_name=op.uf6b2ds4a8nfnl%40hago1&forum_name=inkscape-user

as far as I can tell, the windows nightly builds have not worked since Aug 16. Using the Aug 21 download, the most recent timestamp that I can see on any files is
08/16/2008  02:49 PM        14,671,360 inkscape.exe

part of my reason for posting this is because there is a possibility that I may have caused this, since I did a commit on that day, svn 19670, for the first time, and I'm afraid I may have done it wrong.

[bulia byak]

Yesterday I compiled latest SVN on WinXP and it does not crash on
start for me, although the downloaded modevia builds did crash
(although on another machine)...

--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Alvin Penner]

as far as I can tell, a patch was done on Aug 17 to solve bug 258761 https://bugs.launchpad.net/inkscape/+bug/258761 .
This was a crash in rev 19671, fixed in rev 19673.

I don't think this fix is present in the nightly win32 builds, at least not according to the dates on the files, but can't figure out why not.
Will try out the latest build tonight.

[bulia byak]

On Fri, Aug 22, 2008 at 1:56 PM, Alvin Penner <penner@...> wrote:
>
> as far as I can tell, a patch was done on Aug 17 to solve bug 258761
> https://bugs.launchpad.net/inkscape/+bug/258761 .
> This was a crash in rev 19671, fixed in rev 19673.

Aha, so it didn't crash for me because I compiled 19743.

I urge the 2geom developers to please look into this and fix this "properly".

Also I'd like to remind them that we still have unsolved
"non-continuous path"  asserts. For example the crash when loading our
own current about.svg:

glibmm-ERROR **:
unhandled exception (type std::exception) in signal handler:
what: lib2geom exception: Non-contiguous path (2geom/path.cpp:88)

This has been broken for too long, it discourages people who try to
use SVN builds for testing. Myself, I somehow put up with the
unstability most of the time, but from time to time I also have to go
back to an old build to finish some work. Please fix this ASAP!

--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[J.B.C.Engelen]

Okay okay... :P
I'll look into it asap when i get back, actually forgot about it...
 
It'll have to wait until I get back from vacation though.. (1 sept)
 
Cheers,
Johan
 
 

________________________________

From: bulia byak [mailto:buliabyak@...]
Sent: Fri 22/08/2008 19:10
To: Alvin Penner; Engelen, J.B.C. (Johan); MenTaLguY
Cc: inkscape-devel@...
Subject: Re: [Inkscape-devel] Win32 nightly builds don't work since Aug 16



On Fri, Aug 22, 2008 at 1:56 PM, Alvin Penner <penner@...> wrote:
>
> as far as I can tell, a patch was done on Aug 17 to solve bug 258761
> https://bugs.launchpad.net/inkscape/+bug/258761 <https://bugs.launchpad.net/inkscape/+bug/258761>  .
> This was a crash in rev 19671, fixed in rev 19673.

Aha, so it didn't crash for me because I compiled 19743.

I urge the 2geom developers to please look into this and fix this "properly".

Also I'd like to remind them that we still have unsolved
"non-continuous path"  asserts. For example the crash when loading our
own current about.svg:

glibmm-ERROR **:
unhandled exception (type std::exception) in signal handler:
what: lib2geom exception: Non-contiguous path (2geom/path.cpp:88)

This has been broken for too long, it discourages people who try to
use SVN builds for testing. Myself, I somehow put up with the
unstability most of the time, but from time to time I also have to go
back to an old build to finish some work. Please fix this ASAP!

--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org <http://www.inkscape.org/>



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Alvin Penner]

yes!!
- the file Inkscape19743-0808220239.7z starts up normally with no problems, life is good again
- thanks for the update!

[J.B.C.Engelen]

> -----Original Message-----
> From: bulia byak [mailto:buliabyak@...]
> Sent: vrijdag 22 augustus 2008 19:11
> To: Alvin Penner; Engelen, J.B.C. (Johan); MenTaLguY
> Cc: inkscape-devel@...
> Subject: Re: [Inkscape-devel] Win32 nightly builds don't work
> since Aug 16
>
> On Fri, Aug 22, 2008 at 1:56 PM, Alvin Penner
> <penner@...> wrote:
> >
> > as far as I can tell, a patch was done on Aug 17 to solve bug 258761
> > https://bugs.launchpad.net/inkscape/+bug/258761 .
> > This was a crash in rev 19671, fixed in rev 19673.
>
> Aha, so it didn't crash for me because I compiled 19743.
>
> I urge the 2geom developers to please look into this and fix
> this "properly".

It was fixed properly. I broke things with a somewhat strange change,
then went on vacation, sorry for that.

>
> Also I'd like to remind them that we still have unsolved
> "non-continuous path"  asserts. For example the crash when
> loading our own current about.svg:
>
> glibmm-ERROR **:
> unhandled exception (type std::exception) in signal handler:
> what: lib2geom exception: Non-contiguous path (2geom/path.cpp:88)
>
> This has been broken for too long, it discourages people who
> try to use SVN builds for testing. Myself, I somehow put up
> with the unstability most of the time, but from time to time
> I also have to go back to an old build to finish some work.
> Please fix this ASAP!

The about screen does not crash for me, can you point me to another SVG
where it happens?

-Johan

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Alvin Penner]

J.B.C.Engelen wrote:

can you point me to another SVG where it happens?

- running Win32 Inkscape19763-0808291650.7z
- the attached file crashes with the message :
about.svg

terminate called after throwing an instance of 'Geom::ContinuityError'
  what():  lib2geom exception: Non-contiguous path (src/2geom/path.cpp:88)

[J.B.C.Engelen]

> -----Original Message-----
> From: inkscape-devel-bounces@...
> [mailto:inkscape-devel-bounces@...] On
> Behalf Of Alvin Penner
> Sent: zaterdag 30 augustus 2008 22:57
> To: inkscape-devel@...
> Subject: Re: [Inkscape-devel] Win32 nightly builds don't work
> since Aug 16
>
> - running Win32 Inkscape19763-0808291650.7z
> - the attached file crashes with the message :
> http://www.nabble.com/file/p19237076/about.svg about.svg
>
> terminate called after throwing an instance of 'Geom::ContinuityError'
>   what():  lib2geom exception: Non-contiguous path
> (src/2geom/path.cpp:88)

Investigation showed the following inequality throws the exception:

(136.653830 , -638.496893)  ==  (136.653830 , -638.496893)

which in hex looks like:

(406114EC2CAB84D2 , C083F3F9A32A10A6)  ==
(406114EC2CAB84D2 , C083F3F9A32A10A7)

This stems from a difference in curvetype I think... (the last two
curves in the loop before the exception being
"N4Geom11BezierCurveILj1EEE" and "N4Geom11SBasisCurveE").
Apparently the endpoints and transformed slightly different for
sbasiscurves.


As a temporary fix I did the following.
2geom is not able to maintain SVGElliptical arcs after a transform; they
are converted to SBasisCurves. To fix the crash in the method
"LoadPathVector" (converting 2geom paths to livarot paths), I now
convert the 2geom path to a 2geom path with only bezier curves when a
transform should be applied. Note that this is a temporary work around!!

-Johan


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Alvin Penner]

J.B.C.Engelen wrote:

I now convert the 2geom path to a 2geom path with only bezier curves when a
transform should be applied.

    thanks, I'll check it out on Tuesday night, don't have access to highspeed at the moment.
Alvin

[Alvin Penner]

J.B.C.Engelen wrote:

Investigation showed the following inequality throws the exception:

(136.653830 , -638.496893)  ==  (136.653830 , -638.496893)

which in hex looks like:

(406114EC2CAB84D2 , C083F3F9A32A10A6)  ==
(406114EC2CAB84D2 , C083F3F9A32A10A7)

 
would it not be desirable to (instead) put some tolerance for round-off error into the 2geom routine, since the difference between these two points is clearly negligible ?

[bulia byak]

On Sun, Aug 31, 2008 at 2:24 PM, Alvin Penner <penner@...> wrote:

>> Investigation showed the following inequality throws the exception:
>>
>> (136.653830 , -638.496893)  ==  (136.653830 , -638.496893)
>>
>> which in hex looks like:
>>
>> (406114EC2CAB84D2 , C083F3F9A32A10A6)  ==
>> (406114EC2CAB84D2 , C083F3F9A32A10A7)
>>
>
> would it not be desirable to (instead) put some tolerance for round-off
> error into the 2geom routine, since the difference between these two points
> is clearly negligible ?

I second that. It's never a good idea to test two floating point
numbers for equality. You should always have an epsilon to account for
rounding errors.

--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Bob Jamison-2]

bulia byak wrote:

> On Sun, Aug 31, 2008 at 2:24 PM, Alvin Penner<penner@...>  wrote:
>    
>>> Investigation showed the following inequality throws the exception:
>>>
>>> (136.653830 , -638.496893)  ==  (136.653830 , -638.496893)
>>>
>>> which in hex looks like:
>>>
>>> (406114EC2CAB84D2 , C083F3F9A32A10A6)  ==
>>> (406114EC2CAB84D2 , C083F3F9A32A10A7)
>>>
>>>        
>> would it not be desirable to (instead) put some tolerance for round-off
>> error into the 2geom routine, since the difference between these two points
>> is clearly negligible ?
>>      
>
> I second that. It's never a good idea to test two floating point
> numbers for equality. You should always have an epsilon to account for
> rounding errors.
>
>    

Yes, even though == works in a lot of cases, people should never
trust it.

I noticed in point.h, == is overloaded like this:

inline bool operator==(Point const &a, Point const &b) {
     return (a[X] == b[X]) && (a[Y] == b[Y]);
}

This should be "abs(a-b) < epsilon", however, maybe nathan
has a faster way.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[J.B.C.Engelen]

> -----Original Message-----
> From: inkscape-devel-bounces@...
> [mailto:inkscape-devel-bounces@...] On
> Behalf Of Bob Jamison
> Sent: maandag 1 september 2008 6:40
> To: bulia byak; inkscape
> Subject: Re: [Inkscape-devel] Win32 nightly builds don't work
> since Aug 16
>
> bulia byak wrote:
> > On Sun, Aug 31, 2008 at 2:24 PM, Alvin
> Penner<penner@...>  wrote:
> >    
> >>> Investigation showed the following inequality throws the
> exception:
> >>>
> >>> (136.653830 , -638.496893)  ==  (136.653830 , -638.496893)
> >>>
> >>> which in hex looks like:
> >>>
> >>> (406114EC2CAB84D2 , C083F3F9A32A10A6)  ==
> >>> (406114EC2CAB84D2 , C083F3F9A32A10A7)
> >>>
> >>>        
> >> would it not be desirable to (instead) put some tolerance for
> >> round-off error into the 2geom routine, since the
> difference between
> >> these two points is clearly negligible ?
> >>      
> >
> > I second that. It's never a good idea to test two floating point
> > numbers for equality. You should always have an epsilon to
> account for
> > rounding errors.

I disagree. In the case of paths, the current curve's final point is
exactly the same data as the next curve's initial point. 2geom has this
built-in redundancy in path data because it simplifies things a lot. But
it is important to maintain this data duplication. Therefore, these
points should be exactly (binary) equivalent.

>
> I noticed in point.h, == is overloaded like this:
>
> inline bool operator==(Point const &a, Point const &b) {
>      return (a[X] == b[X]) && (a[Y] == b[Y]); }
>
> This should be "abs(a-b) < epsilon", however, maybe nathan
> has a faster way.

For this purpose we have "bool are_near(Typename a, Typename b)". So
when one checks point1 == point2, one knows whether they are exactly the
same.

We are working on a proper fix.

Johan


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[calembour]

Hi Johan,
obviously I agree with you :-)
I think it dependends from the new Symmetric Power Basis - Bernstein Basis
conversion routines I implemented the last week. I hope to have fixed
the problem: now the routines leave the initial and final control points
unchanged so that exact comparison can be performed.
Could you syncronize the inkscape code ?

Cheers,
Marco



On Mon, 01 Sep 2008 14:05:14 +0200, <J.B.C.Engelen@...> wrote:

>> -----Original Message-----
>> From: inkscape-devel-bounces@...
>> [mailto:inkscape-devel-bounces@...] On
>> Behalf Of Bob Jamison
>> Sent: maandag 1 september 2008 6:40
>> To: bulia byak; inkscape
>> Subject: Re: [Inkscape-devel] Win32 nightly builds don't work
>> since Aug 16
>>
>> bulia byak wrote:
>> > On Sun, Aug 31, 2008 at 2:24 PM, Alvin
>> Penner<penner@...>  wrote:
>> >
>> >>> Investigation showed the following inequality throws the
>> exception:
>> >>>
>> >>> (136.653830 , -638.496893)  ==  (136.653830 , -638.496893)
>> >>>
>> >>> which in hex looks like:
>> >>>
>> >>> (406114EC2CAB84D2 , C083F3F9A32A10A6)  ==
>> >>> (406114EC2CAB84D2 , C083F3F9A32A10A7)
>> >>>
>> >>>
>> >> would it not be desirable to (instead) put some tolerance for
>> >> round-off error into the 2geom routine, since the
>> difference between
>> >> these two points is clearly negligible ?
>> >>
>> >
>> > I second that. It's never a good idea to test two floating point
>> > numbers for equality. You should always have an epsilon to
>> account for
>> > rounding errors.
>
> I disagree. In the case of paths, the current curve's final point is
> exactly the same data as the next curve's initial point. 2geom has this
> built-in redundancy in path data because it simplifies things a lot. But
> it is important to maintain this data duplication. Therefore, these
> points should be exactly (binary) equivalent.
>
>>
>> I noticed in point.h, == is overloaded like this:
>>
>> inline bool operator==(Point const &a, Point const &b) {
>>      return (a[X] == b[X]) && (a[Y] == b[Y]); }
>>
>> This should be "abs(a-b) < epsilon", however, maybe nathan
>> has a faster way.
>
> For this purpose we have "bool are_near(Typename a, Typename b)". So
> when one checks point1 == point2, one knows whether they are exactly the
> same.
>
> We are working on a proper fix.
>
> Johan
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great  
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the  
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Lib2geom-devel mailing list
> Lib2geom-devel@...
> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Jon A. Cruz]

On Sep 1, 2008, at 5:05 AM, J.B.C.Engelen@... wrote:

I disagree. In the case of paths, the current curve's final point is

exactly the same data as the next curve's initial point. 2geom has this

built-in redundancy in path data because it simplifies things a lot. But

it is important to maintain this data duplication. Therefore, these

points should be exactly (binary) equivalent.

Yes,

but the main problem with floating point values is that depending on the rounding involved on calculations to get to some value, things may be equivalent but not an exact match for all bits.

Also keep in mind that precision might vary from platform to platform.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[J.B.C.Engelen]

> -----Original Message-----
> From: lib2geom-devel-bounces@...
> [mailto:lib2geom-devel-bounces@...] On
> Behalf Of Jon A. Cruz
> Sent: maandag 1 september 2008 20:43
> To: Engelen, J.B.C. (Johan)
> Cc: rwjj@...; inkscape-devel@...;
> lib2geom-devel@...; buliabyak@...
> Subject: Re: [Lib2geom-devel] [Inkscape-devel] Win32 nightly
> builds don'twork since Aug 16
>
>
> On Sep 1, 2008, at 5:05 AM, J.B.C.Engelen@... wrote:
>
>
> I disagree. In the case of paths, the current curve's
> final point is
>
> exactly the same data as the next curve's initial
> point. 2geom has this
>
> built-in redundancy in path data because it simplifies
> things a lot. But
>
> it is important to maintain this data duplication.
> Therefore, these
>
> points should be exactly (binary) equivalent.
>
>
> Yes,
> but the main problem with floating point values is that
> depending on the rounding involved on calculations to get to
> some value, things may be equivalent but not an exact match
> for all bits.
>
> Also keep in mind that precision might vary from platform to platform.

The idea is to get all calculations exactly equal for the initial and
final points.
So this should not be a problem. If the calculations are not exactly
equal, then at the end of the calculation something should be added such
that it mimics the "standard" calculation for initial and final points.


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...
https://lists.sourceforge.net/lists/listinfo/inkscape-devel