Updated 2geom -- what changed?
Locked
123
123
Updated 2geom -- what changed?
 
|
Hi all,
I just updated our copy of lib2geom to the latest trunk version (bzr 10025). This greatly helps in improving Inkscape and lib2geom together. What changed in lib2geom since the last time we updated? Quite an important name change has happened: Geom::Matrix is now called Geom::Affine (to be found in affine.h instead of matrix.h). Some bugs were fixed (but were backported to Inkscape often too), and there are some other name changes. See the list below. I have not done extensive tests, Inkscape seems to build fine, runs ok, and what I tested (spiro LPE) works fine too. If there are any troubles, let me know. Cheers, Johan _______________________________________________________________________ Relevant changes to lib2geom since last update: Geom::Matrix --> Geom::Affine <2geom/matrix.h> --> <2geom/affine.h> Geom::Interval::extendTo --> expandTo Geom::Line::setBy2Points --> setPoints Geom::Line::origin(Geom::Point) --> setOrigin Geom::Line::versor(Geom::Point) --> setVersor Geom::Matrix::without_translation --> Geom::Affine::withoutTranslation Geom::EllipticalArc::rotation_angle --> rotationAngle Geom::EllipticalArc::large_arc_flag --> largeArc Geom::EllipticalArc::sweep_flag --> sweep _______________________________________________________________________ ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Inkscape-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/inkscape-devel |
Re: [Lib2geom-devel] Updated 2geom -- what changed?
|
Johan,
It appears that the affine files were not added as a part of the commit. In file included from arc-context.cpp:26:0: display/sp-canvas.h:38:26: fatal error: 2geom/affine.h: No such file or directory Cheers, Josh On Wed, Feb 2, 2011 at 1:26 PM, <[hidden email]> wrote: > Hi all, > > I just updated our copy of lib2geom to the latest trunk version (bzr > 10025). This greatly helps in improving Inkscape and lib2geom together. > > What changed in lib2geom since the last time we updated? Quite an > important name change has happened: Geom::Matrix is now called > Geom::Affine (to be found in affine.h instead of matrix.h). Some bugs > were fixed (but were backported to Inkscape often too), and there are > some other name changes. See the list below. > > I have not done extensive tests, Inkscape seems to build fine, runs ok, > and what I tested (spiro LPE) works fine too. If there are any troubles, > let me know. > > Cheers, > Johan > > _______________________________________________________________________ > Relevant changes to lib2geom since last update: > > Geom::Matrix --> Geom::Affine > <2geom/matrix.h> --> <2geom/affine.h> > > Geom::Interval::extendTo --> expandTo > > Geom::Line::setBy2Points --> setPoints > > Geom::Line::origin(Geom::Point) --> setOrigin > Geom::Line::versor(Geom::Point) --> setVersor > > > Geom::Matrix::without_translation --> Geom::Affine::withoutTranslation > > Geom::EllipticalArc::rotation_angle --> rotationAngle > Geom::EllipticalArc::large_arc_flag --> largeArc > Geom::EllipticalArc::sweep_flag --> sweep > _______________________________________________________________________ > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > Lib2geom-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/lib2geom-devel > ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Inkscape-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/inkscape-devel |
Re: [Lib2geom-devel] Updated 2geom -- what changed?
|
|
I added the missing files to inkscape trunk.
Cheers, Josh On Wed, Feb 2, 2011 at 1:50 PM, Josh Andler <[hidden email]> wrote: > Johan, > > It appears that the affine files were not added as a part of the commit. > > In file included from arc-context.cpp:26:0: > display/sp-canvas.h:38:26: fatal error: 2geom/affine.h: No such file > or directory > > Cheers, > Josh > > On Wed, Feb 2, 2011 at 1:26 PM, <[hidden email]> wrote: >> Hi all, >> >> I just updated our copy of lib2geom to the latest trunk version (bzr >> 10025). This greatly helps in improving Inkscape and lib2geom together. >> >> What changed in lib2geom since the last time we updated? Quite an >> important name change has happened: Geom::Matrix is now called >> Geom::Affine (to be found in affine.h instead of matrix.h). Some bugs >> were fixed (but were backported to Inkscape often too), and there are >> some other name changes. See the list below. >> >> I have not done extensive tests, Inkscape seems to build fine, runs ok, >> and what I tested (spiro LPE) works fine too. If there are any troubles, >> let me know. >> >> Cheers, >> Johan >> >> _______________________________________________________________________ >> Relevant changes to lib2geom since last update: >> >> Geom::Matrix --> Geom::Affine >> <2geom/matrix.h> --> <2geom/affine.h> >> >> Geom::Interval::extendTo --> expandTo >> >> Geom::Line::setBy2Points --> setPoints >> >> Geom::Line::origin(Geom::Point) --> setOrigin >> Geom::Line::versor(Geom::Point) --> setVersor >> >> >> Geom::Matrix::without_translation --> Geom::Affine::withoutTranslation >> >> Geom::EllipticalArc::rotation_angle --> rotationAngle >> Geom::EllipticalArc::large_arc_flag --> largeArc >> Geom::EllipticalArc::sweep_flag --> sweep >> _______________________________________________________________________ >> >> >> ------------------------------------------------------------------------------ >> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! >> Finally, a world-class log management solution at an even better price-free! >> Download using promo code Free_Logger_4_Dev2Dev. Offer expires >> February 28th, so secure your free ArcSight Logger TODAY! >> http://p.sf.net/sfu/arcsight-sfd2d >> _______________________________________________ >> Lib2geom-devel mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel >> > ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Inkscape-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/inkscape-devel |
|
On 3/2/11 04:17, Josh Andler wrote:
> On Wed, Feb 2, 2011 at 1:50 PM, Josh Andler wrote: >> On Wed, Feb 2, 2011 at 1:26 PM, <[hidden email]> wrote: >> >>> I just updated our copy of lib2geom to the latest trunk version >>> (bzr 10025). This greatly helps in improving Inkscape and >>> lib2geom together. >> >> It appears that the affine files were not added as a part of the >> commit. >> >> In file included from arc-context.cpp:26:0: >> display/sp-canvas.h:38:26: fatal error: 2geom/affine.h: No such >> file or directory > > I added the missing files to inkscape trunk. 'src/2geom/Makefile_insert'?): trying to build r10030 fails when linking inkscape with a lot of 'Undefined symbols' (log attached). (tested with r10030 on OS X 10.5.8, GCC 4.2.1) ~suv CXXLD inkscape Undefined symbols: "vtable for Geom::QuadraticBezier", referenced from: __ZTVN4Geom15QuadraticBezierE$non_lazy_ptr in libinkscape.a(curve.o) __ZTVN4Geom15QuadraticBezierE$non_lazy_ptr in lib2geom.a(sbasis-to-bezier.o) __ZTVN4Geom15QuadraticBezierE$non_lazy_ptr in libinkscape.a(svg-path.o) __ZTVN4Geom15QuadraticBezierE$non_lazy_ptr in libinkscape.a(path-manipulator.o) "typeinfo for Geom::QuadraticBezier", referenced from: __ZTIN4Geom15QuadraticBezierE$non_lazy_ptr in libinkscape.a(geom.o) __ZTIN4Geom15QuadraticBezierE$non_lazy_ptr in libinkscape.a(sp-polygon.o) __ZTIN4Geom15QuadraticBezierE$non_lazy_ptr in libinkscape.a(sp-path.o) __ZTIN4Geom15QuadraticBezierE$non_lazy_ptr in libinkscape.a(latex-pstricks.o) __ZTIN4Geom15QuadraticBezierE$non_lazy_ptr in libinkscape.a(odf.o) __ZTIN4Geom15QuadraticBezierE$non_lazy_ptr in libinkscape.a(pov-out.o) __ZTIN4Geom15QuadraticBezierE$non_lazy_ptr in libinkscape.a(inkscape-cairo.o) __ZTIN4Geom15QuadraticBezierE$non_lazy_ptr in libvarot.a(PathCutting.o) __ZTIN4Geom15QuadraticBezierE$non_lazy_ptr in libinkscape.a(svg-path.o) __ZTIN4Geom15QuadraticBezierE$non_lazy_ptr in libinkscape.a(nr-arena-shape.o) __ZTIN4Geom15QuadraticBezierE$non_lazy_ptr in libinkscape.a(lpe-spiro.o) "Geom::LineSegment::nearestPoint(Geom::Point const&, double, double) const", referenced from: vtable for Geom::Path::ClosingSegmentin libinkscape.a(geom.o) vtable for Geom::Path::StitchSegmentin libinkscape.a(geom.o) vtable for Geom::Path::StitchSegmentin lib2geom.a(path.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(curve.o) vtable for Geom::Path::ClosingSegmentin lib2geom.a(sbasis-to-bezier.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(object-snapper.o) vtable for Geom::Path::StitchSegmentin libinkscape.a(object-snapper.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(pencil-context.o) vtable for Geom::Path::ClosingSegmentin libvarot.a(PathCutting.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(svg-path.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(sp-conn-end.o) vtable for Geom::Path::ClosingSegmentin lib2geom.a(circle.o) vtable for Geom::Path::StitchSegmentin lib2geom.a(circle.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(path-manipulator.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-rough-hatches.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-bendpath.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-vonkoch.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-envelope.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-interpolate.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-copy_rotate.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-constructgrid.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-gears.o) vtable for Geom::Path::StitchSegmentin libinkscape.a(lpe-gears.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-extrude.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-curvestitch.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-line_segment.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-knot.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-powerstroke.o) vtable for Geom::Path::ClosingSegmentin lib2geom.a(shape.o) vtable for Geom::Path::StitchSegmentin lib2geom.a(shape.o) "Geom::Curve::allNearestPoints(Geom::Point const&, double, double) const", referenced from: vtable for Geom::Path::ClosingSegmentin libinkscape.a(geom.o) vtable for Geom::Path::StitchSegmentin libinkscape.a(geom.o) vtable for Geom::Path::StitchSegmentin lib2geom.a(path.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(curve.o) vtable for Geom::SVGEllipticalArcin lib2geom.a(sbasis-to-bezier.o) vtable for Geom::VLineSegmentin lib2geom.a(sbasis-to-bezier.o) vtable for Geom::AxisLineSegment<(Geom::Dim2)1>in lib2geom.a(sbasis-to-bezier.o) vtable for Geom::HLineSegmentin lib2geom.a(sbasis-to-bezier.o) vtable for Geom::AxisLineSegment<(Geom::Dim2)0>in lib2geom.a(sbasis-to-bezier.o) vtable for Geom::Path::ClosingSegmentin lib2geom.a(sbasis-to-bezier.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(object-snapper.o) vtable for Geom::Path::StitchSegmentin libinkscape.a(object-snapper.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(pencil-context.o) vtable for Geom::EllipticalArcin lib2geom.a(elliptical-arc.o) vtable for Geom::Path::ClosingSegmentin libvarot.a(PathCutting.o) vtable for Geom::SVGEllipticalArcin libvarot.a(PathCutting.o) vtable for Geom::SVGEllipticalArcin libinkscape.a(svg-path.o) vtable for Geom::VLineSegmentin libinkscape.a(svg-path.o) vtable for Geom::AxisLineSegment<(Geom::Dim2)1>in libinkscape.a(svg-path.o) vtable for Geom::HLineSegmentin libinkscape.a(svg-path.o) vtable for Geom::AxisLineSegment<(Geom::Dim2)0>in libinkscape.a(svg-path.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(svg-path.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(sp-conn-end.o) vtable for Geom::Path::ClosingSegmentin lib2geom.a(circle.o) vtable for Geom::Path::StitchSegmentin lib2geom.a(circle.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(path-manipulator.o) vtable for Geom::SVGEllipticalArcin libinkscape.a(path-manipulator.o) vtable for Geom::VLineSegmentin libinkscape.a(path-manipulator.o) vtable for Geom::AxisLineSegment<(Geom::Dim2)1>in libinkscape.a(path-manipulator.o) vtable for Geom::HLineSegmentin libinkscape.a(path-manipulator.o) vtable for Geom::AxisLineSegment<(Geom::Dim2)0>in libinkscape.a(path-manipulator.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-rough-hatches.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-bendpath.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-vonkoch.o) vtable for Geom::SVGEllipticalArcin lib2geom.a(ellipse.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-envelope.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-interpolate.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-copy_rotate.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-constructgrid.o) vtable for Geom::SVGEllipticalArcin libinkscape.a(lpe-offset.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-gears.o) vtable for Geom::Path::StitchSegmentin libinkscape.a(lpe-gears.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-extrude.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-curvestitch.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-line_segment.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-knot.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-powerstroke.o) vtable for Geom::Path::ClosingSegmentin lib2geom.a(shape.o) vtable for Geom::Path::StitchSegmentin lib2geom.a(shape.o) "vtable for Geom::LineSegment", referenced from: __ZTVN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(geom.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in lib2geom.a(path.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(curve.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in lib2geom.a(sbasis-to-bezier.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(object-snapper.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(pencil-context.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(snapped-line.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in libvarot.a(PathCutting.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in lib2geom.a(line.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(svg-path.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(sp-conn-end.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in lib2geom.a(circle.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(path-manipulator.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(lpe-rough-hatches.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(lpe-bendpath.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(lpe-vonkoch.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in lib2geom.a(ellipse.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(lpe-envelope.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(lpe-interpolate.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(lpe-copy_rotate.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(lpe-constructgrid.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(lpe-offset.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(lpe-gears.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(lpe-extrude.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(lpe-curvestitch.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(lpe-line_segment.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(lpe-knot.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(lpe-powerstroke.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in lib2geom.a(shape.o) __ZTVN4Geom11LineSegmentE$non_lazy_ptr in lib2geom.a(geom.o) "Geom::Curve::length(double) const", referenced from: vtable for Geom::SVGEllipticalArcin lib2geom.a(sbasis-to-bezier.o) vtable for Geom::EllipticalArcin lib2geom.a(elliptical-arc.o) vtable for Geom::SVGEllipticalArcin libvarot.a(PathCutting.o) vtable for Geom::SVGEllipticalArcin libinkscape.a(svg-path.o) vtable for Geom::SVGEllipticalArcin libinkscape.a(path-manipulator.o) vtable for Geom::SVGEllipticalArcin lib2geom.a(ellipse.o) vtable for Geom::SVGEllipticalArcin libinkscape.a(lpe-offset.o) "typeinfo for Geom::LineSegment", referenced from: typeinfo for Geom::Path::ClosingSegmentin libinkscape.a(geom.o) typeinfo for Geom::AxisLineSegment<(Geom::Dim2)0>in libinkscape.a(geom.o) typeinfo for Geom::AxisLineSegment<(Geom::Dim2)1>in libinkscape.a(geom.o) typeinfo for Geom::Path::StitchSegmentin libinkscape.a(geom.o) __ZTIN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(geom.o) typeinfo for Geom::AxisLineSegment<(Geom::Dim2)0>in libinkscape.a(sp-polygon.o) typeinfo for Geom::AxisLineSegment<(Geom::Dim2)1>in libinkscape.a(sp-polygon.o) __ZTIN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(sp-polygon.o) typeinfo for Geom::AxisLineSegment<(Geom::Dim2)0>in libinkscape.a(sp-path.o) typeinfo for Geom::AxisLineSegment<(Geom::Dim2)1>in libinkscape.a(sp-path.o) __ZTIN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(sp-path.o) typeinfo for Geom::AxisLineSegment<(Geom::Dim2)0>in libinkscape.a(latex-pstricks.o) typeinfo for Geom::AxisLineSegment<(Geom::Dim2)1>in libinkscape.a(latex-pstricks.o) __ZTIN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(latex-pstricks.o) typeinfo for Geom::AxisLineSegment<(Geom::Dim2)0>in libinkscape.a(odf.o) typeinfo for Geom::AxisLineSegment<(Geom::Dim2)1>in libinkscape.a(odf.o) __ZTIN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(odf.o) typeinfo for Geom::Path::StitchSegmentin lib2geom.a(path.o) typeinfo for Geom::Path::ClosingSegmentin libinkscape.a(curve.o) __ZTIN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(curve.o) typeinfo for Geom::AxisLineSegment<(Geom::Dim2)1>in lib2geom.a(sbasis-to-bezier.o) typeinfo for Geom::AxisLineSegment<(Geom::Dim2)0>in lib2geom.a(sbasis-to-bezier.o) typeinfo for Geom::Path::ClosingSegmentin lib2geom.a(sbasis-to-bezier.o) typeinfo for Geom::AxisLineSegment<(Geom::Dim2)0>in libinkscape.a(pov-out.o) typeinfo for Geom::AxisLineSegment<(Geom::Dim2)1>in libinkscape.a(pov-out.o) __ZTIN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(pov-out.o) typeinfo for Geom::Path::ClosingSegmentin libinkscape.a(object-snapper.o) typeinfo for Geom::Path::StitchSegmentin libinkscape.a(object-snapper.o) typeinfo for Geom::AxisLineSegment<(Geom::Dim2)0>in libinkscape.a(javafx-out.o) typeinfo for Geom::AxisLineSegment<(Geom::Dim2)1>in libinkscape.a(javafx-out.o) __ZTIN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(javafx-out.o) __ZTIN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(sp-shape.o) typeinfo for Geom::Path::ClosingSegmentin libinkscape.a(pencil-context.o) typeinfo for Geom::AxisLineSegment<(Geom::Dim2)0>in libinkscape.a(inkscape-cairo.o) typeinfo for Geom::AxisLineSegment<(Geom::Dim2)1>in libinkscape.a(inkscape-cairo.o) __ZTIN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(inkscape-cairo.o) typeinfo for Geom::AxisLineSegment<(Geom::Dim2)0>in libvarot.a(PathCutting.o) typeinfo for Geom::AxisLineSegment<(Geom::Dim2)1>in libvarot.a(PathCutting.o) typeinfo for Geom::Path::ClosingSegmentin libvarot.a(PathCutting.o) __ZTIN4Geom11LineSegmentE$non_lazy_ptr in libvarot.a(PathCutting.o) typeinfo for Geom::Path::StitchSegmentin libinkscape.a(svg-path.o) typeinfo for Geom::AxisLineSegment<(Geom::Dim2)0>in libinkscape.a(svg-path.o) typeinfo for Geom::AxisLineSegment<(Geom::Dim2)1>in libinkscape.a(svg-path.o) typeinfo for Geom::Path::ClosingSegmentin libinkscape.a(svg-path.o) __ZTIN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(svg-path.o) typeinfo for Geom::Path::ClosingSegmentin libinkscape.a(sp-conn-end.o) typeinfo for Geom::Path::ClosingSegmentin lib2geom.a(circle.o) typeinfo for Geom::Path::StitchSegmentin lib2geom.a(circle.o) typeinfo for Geom::Path::ClosingSegmentin libinkscape.a(path-manipulator.o) typeinfo for Geom::AxisLineSegment<(Geom::Dim2)1>in libinkscape.a(path-manipulator.o) typeinfo for Geom::AxisLineSegment<(Geom::Dim2)0>in libinkscape.a(path-manipulator.o) typeinfo for Geom::Path::ClosingSegmentin libinkscape.a(lpe-rough-hatches.o) typeinfo for Geom::Path::ClosingSegmentin libinkscape.a(lpe-bendpath.o) typeinfo for Geom::AxisLineSegment<(Geom::Dim2)0>in libinkscape.a(nr-arena-shape.o) typeinfo for Geom::AxisLineSegment<(Geom::Dim2)1>in libinkscape.a(nr-arena-shape.o) __ZTIN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(nr-arena-shape.o) typeinfo for Geom::Path::ClosingSegmentin libinkscape.a(lpe-vonkoch.o) typeinfo for Geom::Path::ClosingSegmentin libinkscape.a(lpe-envelope.o) typeinfo for Geom::Path::ClosingSegmentin libinkscape.a(lpe-interpolate.o) typeinfo for Geom::Path::ClosingSegmentin libinkscape.a(lpe-copy_rotate.o) typeinfo for Geom::Path::ClosingSegmentin libinkscape.a(lpe-constructgrid.o) typeinfo for Geom::AxisLineSegment<(Geom::Dim2)0>in libinkscape.a(lpe-spiro.o) typeinfo for Geom::AxisLineSegment<(Geom::Dim2)1>in libinkscape.a(lpe-spiro.o) __ZTIN4Geom11LineSegmentE$non_lazy_ptr in libinkscape.a(lpe-spiro.o) typeinfo for Geom::Path::ClosingSegmentin libinkscape.a(lpe-gears.o) typeinfo for Geom::Path::StitchSegmentin libinkscape.a(lpe-gears.o) typeinfo for Geom::Path::ClosingSegmentin libinkscape.a(lpe-extrude.o) typeinfo for Geom::Path::ClosingSegmentin libinkscape.a(lpe-curvestitch.o) typeinfo for Geom::Path::ClosingSegmentin libinkscape.a(lpe-line_segment.o) typeinfo for Geom::Path::ClosingSegmentin libinkscape.a(lpe-knot.o) typeinfo for Geom::Path::ClosingSegmentin libinkscape.a(lpe-powerstroke.o) typeinfo for Geom::Path::ClosingSegmentin lib2geom.a(shape.o) typeinfo for Geom::Path::StitchSegmentin lib2geom.a(shape.o) "vtable for Geom::Curve", referenced from: __ZTVN4Geom5CurveE$non_lazy_ptr in libinkscape.a(geom.o) __ZTVN4Geom5CurveE$non_lazy_ptr in lib2geom.a(path.o) __ZTVN4Geom5CurveE$non_lazy_ptr in libinkscape.a(curve.o) __ZTVN4Geom5CurveE$non_lazy_ptr in lib2geom.a(sbasis-to-bezier.o) __ZTVN4Geom5CurveE$non_lazy_ptr in libinkscape.a(object-snapper.o) __ZTVN4Geom5CurveE$non_lazy_ptr in libinkscape.a(pencil-context.o) __ZTVN4Geom5CurveE$non_lazy_ptr in lib2geom.a(elliptical-arc.o) __ZTVN4Geom5CurveE$non_lazy_ptr in libinkscape.a(snapped-line.o) __ZTVN4Geom5CurveE$non_lazy_ptr in libvarot.a(PathCutting.o) __ZTVN4Geom5CurveE$non_lazy_ptr in lib2geom.a(line.o) __ZTVN4Geom5CurveE$non_lazy_ptr in libinkscape.a(svg-path.o) __ZTVN4Geom5CurveE$non_lazy_ptr in libinkscape.a(sp-conn-end.o) __ZTVN4Geom5CurveE$non_lazy_ptr in lib2geom.a(circle.o) __ZTVN4Geom5CurveE$non_lazy_ptr in libinkscape.a(path-manipulator.o) __ZTVN4Geom5CurveE$non_lazy_ptr in libinkscape.a(lpe-rough-hatches.o) __ZTVN4Geom5CurveE$non_lazy_ptr in libinkscape.a(lpe-bendpath.o) __ZTVN4Geom5CurveE$non_lazy_ptr in libinkscape.a(lpe-vonkoch.o) __ZTVN4Geom5CurveE$non_lazy_ptr in lib2geom.a(ellipse.o) __ZTVN4Geom5CurveE$non_lazy_ptr in libinkscape.a(lpe-envelope.o) __ZTVN4Geom5CurveE$non_lazy_ptr in libinkscape.a(lpe-interpolate.o) __ZTVN4Geom5CurveE$non_lazy_ptr in libinkscape.a(lpe-copy_rotate.o) __ZTVN4Geom5CurveE$non_lazy_ptr in libinkscape.a(lpe-constructgrid.o) __ZTVN4Geom5CurveE$non_lazy_ptr in libinkscape.a(lpe-offset.o) __ZTVN4Geom5CurveE$non_lazy_ptr in libinkscape.a(lpe-gears.o) __ZTVN4Geom5CurveE$non_lazy_ptr in libinkscape.a(lpe-extrude.o) __ZTVN4Geom5CurveE$non_lazy_ptr in libinkscape.a(lpe-curvestitch.o) __ZTVN4Geom5CurveE$non_lazy_ptr in libinkscape.a(lpe-line_segment.o) __ZTVN4Geom5CurveE$non_lazy_ptr in libinkscape.a(lpe-knot.o) __ZTVN4Geom5CurveE$non_lazy_ptr in libinkscape.a(lpe-powerstroke.o) __ZTVN4Geom5CurveE$non_lazy_ptr in lib2geom.a(shape.o) __ZTVN4Geom5CurveE$non_lazy_ptr in lib2geom.a(geom.o) "Geom::Curve::unitTangentAt(double, unsigned int) const", referenced from: vtable for Geom::Path::ClosingSegmentin libinkscape.a(geom.o) vtable for Geom::Path::StitchSegmentin libinkscape.a(geom.o) vtable for Geom::Path::StitchSegmentin lib2geom.a(path.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(curve.o) vtable for Geom::SVGEllipticalArcin lib2geom.a(sbasis-to-bezier.o) vtable for Geom::SBasisCurvein lib2geom.a(sbasis-to-bezier.o) vtable for Geom::VLineSegmentin lib2geom.a(sbasis-to-bezier.o) vtable for Geom::AxisLineSegment<(Geom::Dim2)1>in lib2geom.a(sbasis-to-bezier.o) vtable for Geom::HLineSegmentin lib2geom.a(sbasis-to-bezier.o) vtable for Geom::AxisLineSegment<(Geom::Dim2)0>in lib2geom.a(sbasis-to-bezier.o) vtable for Geom::Path::ClosingSegmentin lib2geom.a(sbasis-to-bezier.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(object-snapper.o) vtable for Geom::Path::StitchSegmentin libinkscape.a(object-snapper.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(pencil-context.o) vtable for Geom::EllipticalArcin lib2geom.a(elliptical-arc.o) vtable for Geom::SBasisCurvein lib2geom.a(elliptical-arc.o) vtable for Geom::Path::ClosingSegmentin libvarot.a(PathCutting.o) vtable for Geom::SVGEllipticalArcin libvarot.a(PathCutting.o) vtable for Geom::SBasisCurvein libvarot.a(PathCutting.o) vtable for Geom::SVGEllipticalArcin libinkscape.a(svg-path.o) vtable for Geom::SBasisCurvein libinkscape.a(svg-path.o) vtable for Geom::VLineSegmentin libinkscape.a(svg-path.o) vtable for Geom::AxisLineSegment<(Geom::Dim2)1>in libinkscape.a(svg-path.o) vtable for Geom::HLineSegmentin libinkscape.a(svg-path.o) vtable for Geom::AxisLineSegment<(Geom::Dim2)0>in libinkscape.a(svg-path.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(svg-path.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(sp-conn-end.o) vtable for Geom::Path::ClosingSegmentin lib2geom.a(circle.o) vtable for Geom::SBasisCurvein lib2geom.a(circle.o) vtable for Geom::Path::StitchSegmentin lib2geom.a(circle.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(path-manipulator.o) vtable for Geom::SVGEllipticalArcin libinkscape.a(path-manipulator.o) vtable for Geom::SBasisCurvein libinkscape.a(path-manipulator.o) vtable for Geom::VLineSegmentin libinkscape.a(path-manipulator.o) vtable for Geom::AxisLineSegment<(Geom::Dim2)1>in libinkscape.a(path-manipulator.o) vtable for Geom::HLineSegmentin libinkscape.a(path-manipulator.o) vtable for Geom::AxisLineSegment<(Geom::Dim2)0>in libinkscape.a(path-manipulator.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-rough-hatches.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-bendpath.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-vonkoch.o) vtable for Geom::SVGEllipticalArcin lib2geom.a(ellipse.o) vtable for Geom::SBasisCurvein lib2geom.a(ellipse.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-envelope.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-interpolate.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-copy_rotate.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-constructgrid.o) vtable for Geom::SVGEllipticalArcin libinkscape.a(lpe-offset.o) vtable for Geom::SBasisCurvein libinkscape.a(lpe-offset.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-gears.o) vtable for Geom::SBasisCurvein libinkscape.a(lpe-gears.o) vtable for Geom::Path::StitchSegmentin libinkscape.a(lpe-gears.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-extrude.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-curvestitch.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-line_segment.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-knot.o) vtable for Geom::Path::ClosingSegmentin libinkscape.a(lpe-powerstroke.o) vtable for Geom::Path::ClosingSegmentin lib2geom.a(shape.o) vtable for Geom::Path::StitchSegmentin lib2geom.a(shape.o) "vtable for Geom::BezierCurve", referenced from: __ZTVN4Geom11BezierCurveE$non_lazy_ptr in libinkscape.a(geom.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in lib2geom.a(path.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in libinkscape.a(curve.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in lib2geom.a(sbasis-to-bezier.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in libinkscape.a(object-snapper.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in libinkscape.a(pencil-context.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in libinkscape.a(snapped-line.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in libvarot.a(PathCutting.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in lib2geom.a(line.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in libinkscape.a(svg-path.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in libinkscape.a(sp-conn-end.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in lib2geom.a(circle.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in libinkscape.a(path-manipulator.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in libinkscape.a(lpe-rough-hatches.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in libinkscape.a(lpe-bendpath.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in libinkscape.a(lpe-vonkoch.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in lib2geom.a(ellipse.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in libinkscape.a(lpe-envelope.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in libinkscape.a(lpe-interpolate.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in libinkscape.a(lpe-copy_rotate.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in libinkscape.a(lpe-constructgrid.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in libinkscape.a(lpe-offset.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in libinkscape.a(lpe-gears.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in libinkscape.a(lpe-extrude.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in libinkscape.a(lpe-curvestitch.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in libinkscape.a(lpe-line_segment.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in libinkscape.a(lpe-knot.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in libinkscape.a(lpe-powerstroke.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in lib2geom.a(shape.o) __ZTVN4Geom11BezierCurveE$non_lazy_ptr in lib2geom.a(geom.o) "Geom::bezier_length(Geom::Point, Geom::Point, Geom::Point, Geom::Point, double)", referenced from: Inkscape::UI::Node::_linearGrow(int) in libinkscape.a(node.o) Inkscape::UI::Node::_linearGrow(int) in libinkscape.a(node.o) Inkscape::UI::Node::_linearGrow(int) in libinkscape.a(node.o) Inkscape::UI::Node::_linearGrow(int) in libinkscape.a(node.o) Inkscape::UI::Node::_linearGrow(int) in libinkscape.a(node.o) Inkscape::UI::Node::_linearGrow(int) in libinkscape.a(node.o) "typeinfo for Geom::Curve", referenced from: __ZTIN4Geom5CurveE$non_lazy_ptr in libinkscape.a(geom.o) __ZTIN4Geom5CurveE$non_lazy_ptr in libinkscape.a(sp-polygon.o) __ZTIN4Geom5CurveE$non_lazy_ptr in libinkscape.a(sp-path.o) __ZTIN4Geom5CurveE$non_lazy_ptr in libinkscape.a(latex-pstricks.o) __ZTIN4Geom5CurveE$non_lazy_ptr in libinkscape.a(odf.o) __ZTIN4Geom5CurveE$non_lazy_ptr in libinkscape.a(curve.o) typeinfo for Geom::SBasisCurvein lib2geom.a(sbasis-to-bezier.o) __ZTIN4Geom5CurveE$non_lazy_ptr in libinkscape.a(conn-avoid-ref.o) __ZTIN4Geom5CurveE$non_lazy_ptr in libinkscape.a(pov-out.o) __ZTIN4Geom5CurveE$non_lazy_ptr in libinkscape.a(javafx-out.o) __ZTIN4Geom5CurveE$non_lazy_ptr in libinkscape.a(sp-shape.o) __ZTIN4Geom5CurveE$non_lazy_ptr in libinkscape.a(pencil-context.o) typeinfo for Geom::EllipticalArcin lib2geom.a(elliptical-arc.o) typeinfo for Geom::SBasisCurvein lib2geom.a(elliptical-arc.o) __ZTIN4Geom5CurveE$non_lazy_ptr in libinkscape.a(inkscape-cairo.o) typeinfo for Geom::SBasisCurvein libvarot.a(PathCutting.o) __ZTIN4Geom5CurveE$non_lazy_ptr in libvarot.a(PathCutting.o) __ZTIN4Geom5CurveE$non_lazy_ptr in libinkscape.a(eraser-context.o) __ZTIN4Geom5CurveE$non_lazy_ptr in libinkscape.a(pen-context.o) __ZTIN4Geom5CurveE$non_lazy_ptr in libinkscape.a(dyna-draw-context.o) typeinfo for Geom::SBasisCurvein libinkscape.a(svg-path.o) __ZTIN4Geom5CurveE$non_lazy_ptr in libinkscape.a(svg-path.o) typeinfo for Geom::SBasisCurvein lib2geom.a(circle.o) typeinfo for Geom::SBasisCurvein libinkscape.a(path-manipulator.o) __ZTIN4Geom5CurveE$non_lazy_ptr in libinkscape.a(path-manipulator.o) __ZTIN4Geom5CurveE$non_lazy_ptr in libinkscape.a(nr-arena-shape.o) typeinfo for Geom::SBasisCurvein lib2geom.a(ellipse.o) typeinfo for Geom::SBasisCurvein libinkscape.a(lpe-offset.o) __ZTIN4Geom5CurveE$non_lazy_ptr in libinkscape.a(lpe-spiro.o) typeinfo for Geom::SBasisCurvein libinkscape.a(lpe-gears.o) "vtable for Geom::CubicBezier", referenced from: __ZTVN4Geom11CubicBezierE$non_lazy_ptr in libinkscape.a(curve.o) __ZTVN4Geom11CubicBezierE$non_lazy_ptr in lib2geom.a(sbasis-to-bezier.o) __ZTVN4Geom11CubicBezierE$non_lazy_ptr in libinkscape.a(pencil-context.o) __ZTVN4Geom11CubicBezierE$non_lazy_ptr in libvarot.a(PathCutting.o) __ZTVN4Geom11CubicBezierE$non_lazy_ptr in libinkscape.a(svg-path.o) __ZTVN4Geom11CubicBezierE$non_lazy_ptr in libinkscape.a(path-manipulator.o) __ZTVN4Geom11CubicBezierE$non_lazy_ptr in libinkscape.a(lpe-rough-hatches.o) __ZTVN4Geom11CubicBezierE$non_lazy_ptr in libinkscape.a(lpe-powerstroke.o) "typeinfo for Geom::CubicBezier", referenced from: __ZTIN4Geom11CubicBezierE$non_lazy_ptr in libinkscape.a(geom.o) __ZTIN4Geom11CubicBezierE$non_lazy_ptr in libinkscape.a(sp-polygon.o) __ZTIN4Geom11CubicBezierE$non_lazy_ptr in libinkscape.a(sp-path.o) __ZTIN4Geom11CubicBezierE$non_lazy_ptr in libinkscape.a(latex-pstricks.o) __ZTIN4Geom11CubicBezierE$non_lazy_ptr in libinkscape.a(odf.o) __ZTIN4Geom11CubicBezierE$non_lazy_ptr in libinkscape.a(curve.o) __ZTIN4Geom11CubicBezierE$non_lazy_ptr in libinkscape.a(conn-avoid-ref.o) __ZTIN4Geom11CubicBezierE$non_lazy_ptr in libinkscape.a(pov-out.o) __ZTIN4Geom11CubicBezierE$non_lazy_ptr in libinkscape.a(javafx-out.o) __ZTIN4Geom11CubicBezierE$non_lazy_ptr in libinkscape.a(pencil-context.o) __ZTIN4Geom11CubicBezierE$non_lazy_ptr in libinkscape.a(inkscape-cairo.o) __ZTIN4Geom11CubicBezierE$non_lazy_ptr in libvarot.a(PathCutting.o) __ZTIN4Geom11CubicBezierE$non_lazy_ptr in libinkscape.a(eraser-context.o) __ZTIN4Geom11CubicBezierE$non_lazy_ptr in libinkscape.a(pen-context.o) __ZTIN4Geom11CubicBezierE$non_lazy_ptr in libinkscape.a(dyna-draw-context.o) __ZTIN4Geom11CubicBezierE$non_lazy_ptr in libinkscape.a(svg-path.o) __ZTIN4Geom11CubicBezierE$non_lazy_ptr in libinkscape.a(path-manipulator.o) __ZTIN4Geom11CubicBezierE$non_lazy_ptr in libinkscape.a(nr-arena-shape.o) __ZTIN4Geom11CubicBezierE$non_lazy_ptr in libinkscape.a(lpe-spiro.o) ld: symbol(s) not found collect2: ld returned 1 exit status make[3]: *** [inkscape] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Inkscape-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/inkscape-devel |
|
|
[ forwarding to the list ]
On 3/2/11 21:57, Krzysztof Kosiński wrote: > 2011/2/3 ~suv <[hidden email]>: >> >> There seem still some files missing (or need to be added to >> 'src/2geom/Makefile_insert'?): trying to build r10030 fails when linking >> inkscape with a lot of 'Undefined symbols' (log attached). > > Based on the error messages, I think curve.cpp and bezier.cpp were > omitted (these files contain code that was previously in the headers). Can those two files just be copied from <http://bazaar.launchpad.net/~lib2geom-hackers/lib2geom/trunk/files/head:/src/2geom/> or are there other changes needed in inkscape's 2geom files? ~suv ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Inkscape-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/inkscape-devel |
Re: Updated 2geom -- what changed?
|
|
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of ~suv > Sent: 03 February 2011 22:12 > To: Krzysztof Kosiński > Cc: Inkscape Devel List; Engelen, J.B.C. (Johan) > Subject: Re: [Inkscape-devel] Updated 2geom -- what changed? > > [ forwarding to the list ] > > On 3/2/11 21:57, Krzysztof Kosiński wrote: > > 2011/2/3 ~suv <[hidden email]>: > >> > >> There seem still some files missing (or need to be added to > >> 'src/2geom/Makefile_insert'?): trying to build r10030 fails when > linking > >> inkscape with a lot of 'Undefined symbols' (log attached). > > > > Based on the error messages, I think curve.cpp and bezier.cpp were > > omitted (these files contain code that was previously in the headers). > > Can those two files just be copied from > <http://bazaar.launchpad.net/~lib2geom- > hackers/lib2geom/trunk/files/head:/src/2geom/> > or are there other changes needed in inkscape's 2geom files? Sorry for breaking the build. Of course, it was a bzr (un)usability issue. Again I wonder why we ever switched to bzr... I cannot fix the build or add files because now bzr is broken again here. I am willing to pay good money to switch our repo back to SVN. -Johan ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Inkscape-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/inkscape-devel |
Re: Updated 2geom -- what changed?
|
|
>> On 3/2/11 21:57, Krzysztof Kosiński wrote:
>> > 2011/2/3 ~suv <[hidden email]>: >> >> >> >> There seem still some files missing (or need to be added to >> >> 'src/2geom/Makefile_insert'?): trying to build r10030 fails when >> linking >> >> inkscape with a lot of 'Undefined symbols' (log attached). >> > >> > Based on the error messages, I think curve.cpp and bezier.cpp were >> > omitted (these files contain code that was previously in the headers). >> >> Can those two files just be copied from >> <http://bazaar.launchpad.net/~lib2geom- >> hackers/lib2geom/trunk/files/head:/src/2geom/> >> or are there other changes needed in inkscape's 2geom files? > > Sorry for breaking the build. Of course, it was a bzr (un)usability issue. Again I wonder why we ever switched to bzr... I cannot fix the build or add files because now bzr is broken again here. > > I am willing to pay good money to switch our repo back to SVN. Are you having merge conflicts? Cheers, Josh ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Inkscape-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/inkscape-devel |
Re: Updated 2geom -- what changed?
|
In reply to this post by ~suv-2
W dniu 3 lutego 2011 22:11 użytkownik ~suv
<[hidden email]> napisał: > Can those two files just be copied from > <http://bazaar.launchpad.net/~lib2geom-hackers/lib2geom/trunk/files/head:/src/2geom/> > or are there other changes needed in inkscape's 2geom files? > ~suv Build failures should be fixed in 10031. I also fixed a problem with DBus header conflicts that appears if you have sufficiently new giomm. > Sorry for breaking the build. Of course, it was a bzr (un)usability issue. Again I wonder why we ever switched to bzr... I cannot fix the build or add files because now bzr is broken again here. This is not very helpful. What exactly is broken and how does this brokenness manifest? Trying to abandon an unquestionably better tool at the first sight of a problem is not a wise idea. My wild guess is that you somehow copied 2geom's bzr directory into the Inkscape tree. Delete it and things should be back to normal. If they're not, you'll need a fresh checkout. Also here's an useful tip: you can say "bzr add directory" and Bazaar will recursively add all unversioned, non-ignored files it finds in that directory. Regards, Krzysztof ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Inkscape-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/inkscape-devel |
|
|
In reply to this post by J.B.C.Engelen
On 2/2/11 22:26, [hidden email] wrote:
> I have not done extensive tests, Inkscape seems to build fine, runs ok, > and what I tested (spiro LPE) works fine too. If there are any troubles, > let me know. tested with r10031 on OS X 10.5.8, default prefs, compared with r10021: 1) select tool transforming with the mouse (stretch, scale, skew) seems broken 2) node tool node-editing of a path with auto-smooth nodes randomly (?) converts un-affected auto-smooth nodes into cusps. In attached example: - select e.g. an end node and move it: all auto-smooth nodes turn into cusp nodes - now select all nodes (Ctrl+A) and move the selection of nodes (i.e. the whole path): auto-smooth nodes are restored hth, ~suv ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Inkscape-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/inkscape-devel |
2geom-regression-1-r10031.svg (3K)
Re: Updated 2geom -- what changed?
|
|
In reply to this post by Krzysztof Kosiński
> -----Original Message-----
> From: Krzysztof Kosiński [mailto:[hidden email]] > Sent: 04 February 2011 00:24 > To: ~suv > Cc: Inkscape Devel List; Engelen, J.B.C. (Johan) > Subject: Re: [Inkscape-devel] Updated 2geom -- what changed? > > W dniu 3 lutego 2011 22:11 użytkownik ~suv > <[hidden email]> napisał: > > Can those two files just be copied from > > <http://bazaar.launchpad.net/~lib2geom- > hackers/lib2geom/trunk/files/head:/src/2geom/> > > or are there other changes needed in inkscape's 2geom files? > > ~suv > > Build failures should be fixed in 10031. I also fixed a problem with > DBus header conflicts that appears if you have sufficiently new giomm. Thanks for fixing it. > > Sorry for breaking the build. Of course, it was a bzr (un)usability > issue. Again I wonder why we ever switched to bzr... I cannot fix the > build or add files because now bzr is broken again here. > > This is not very helpful. What exactly is broken and how does this > brokenness manifest? Trying to abandon an unquestionably better tool > at the first sight of a problem is not a wise idea. My wild guess is > that you somehow copied 2geom's bzr directory into the Inkscape tree. > Delete it and things should be back to normal. If they're not, you'll > need a fresh checkout. Wild guesses are not very helpful either. What happened is that I just copied files into Inkscape's tree, and (tortoise)bzr does not tell me they are unversioned/not-added upon commit. (Tortoisesvn does tell and provides checkboxes to tick which one should be committed and which should not.) So I forgot to add them. Then yesterday I did a bzr update, got the files that Josh added, then tried to bzr add more and... crashes on trying to add files. I did not try with the commandline, as the software should be better than that. > Also here's an useful tip: you can say "bzr add directory" and Bazaar > will recursively add all unversioned, non-ignored files it finds in > that directory. Thanks for that tip. Although most often I do not want to add all files. Again, thanks for fixing the build, Johan PS. About the unquestionably better tool. I am sure you can find benefits of using Bazaar (note that you are one of the very few that uses branches). But Bazaar is also: - slow - broken (crashing or failing on simple functions) - cumbersome - not providing functionality that I need often, while providing functionality that is rarely used ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Inkscape-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/inkscape-devel |
Re: Updated 2geom -- what changed?
|
|
On Thu, Feb 3, 2011 at 11:55 PM, <[hidden email]> wrote:
> Wild guesses are not very helpful either. Agreed... which is why questions were asked. > What happened is that I just copied files into Inkscape's tree, and (tortoise)bzr does not tell me they are unversioned/not-added upon commit. (Tortoisesvn does tell and provides checkboxes to tick which one should be committed and which should not.) So I forgot to add them. > Then yesterday I did a bzr update, got the files that Josh added, then tried to bzr add more and... crashes on trying to add files. I did not try with the commandline, as the software should be better than that. Yeah, once things diverge, they can become messy if you don't have time/patience to shake things out... I won't disagree. > PS. About the unquestionably better tool. I am sure you can find benefits of using Bazaar (note that you are one of the very few that uses branches). But Bazaar is also: > - slow Agreed. (to slow, not branches) > - broken (crashing or failing on simple functions) I think this is tortoisebzr, command line bzr has not had these issues at all for me. > - cumbersome I find it no less straightforward than svn or git. (more commands than svn, but sensibly) > - not providing functionality that I need often, while providing functionality that is rarely used What are you looking for? As long as I have things like "pull", "push", "add", "commit", "uncommit", "status", "diff", and other basics... I'm pretty good. Cheers, Josh ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Inkscape-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/inkscape-devel |
|
In reply to this post by J.B.C.Engelen
When compiling (Windows XP SP3, bzr 10032), I get this error:
Make error line 300: problem compiling: src/2geom/conicsec.cpp:36:41: error: 2geom/conic_section_clipper.h: No such file or directory src/2geom/conicsec.cpp: In function 'bool Geom::clip(std::vector<Geom::RatQuad, std::allocator<Geom::RatQuad> >&, const Geom::xAx&, const Geom::Rect&)': src/2geom/conicsec.cpp:1545: error: 'clipper' was not declared in this scope src/2geom/conicsec.cpp:1545: error: expected ';' before 'aclipper' src/2geom/conicsec.cpp:1546: error: 'aclipper' was not declared in this scope src/2geom/conicsec.cpp: At global scope: src/2geom/conicsec.cpp:1543: warning: unused parameter 'cs' src/2geom/conicsec.cpp:1543: warning: unused parameter 'R' It seems there's a missing file. Regards. Luca |
|
|
On 4/2/11 10:53, LucaDC wrote:
> When compiling (Windows XP SP3, bzr 10032), I get this error: > > Make error line 300: problem compiling: src/2geom/conicsec.cpp:36:41: error: > 2geom/conic_section_clipper.h: No such file or directory > src/2geom/conicsec.cpp: In function 'bool > Geom::clip(std::vector<Geom::RatQuad, std::allocator<Geom::RatQuad> >&, > const Geom::xAx&, const Geom::Rect&)': > src/2geom/conicsec.cpp:1545: error: 'clipper' was not declared in this scope > src/2geom/conicsec.cpp:1545: error: expected ';' before 'aclipper' > src/2geom/conicsec.cpp:1546: error: 'aclipper' was not declared in this > scope > src/2geom/conicsec.cpp: At global scope: > src/2geom/conicsec.cpp:1543: warning: unused parameter 'cs' > src/2geom/conicsec.cpp:1543: warning: unused parameter 'R' > > It seems there's a missing file. ... or it is a file that's not needed: on osx (last build r10032) the file 'src/2geom/conicsec.cpp' doesn't get compiled (used) - if I add it in my local branch to 'Makefile_insert' I get the same errors and Inkscape fails to build. @Johan or @Krzysztof - could you check it that *.cpp file (added in r10028) is needed or if only its header file needs to be in Inkscape's copy of 2geom? ~suv ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Inkscape-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/inkscape-devel |
|
|
In reply to this post by ~suv-2
On 4/2/11 06:37, ~suv wrote:
> On 2/2/11 22:26, [hidden email] wrote: > >> I have not done extensive tests, Inkscape seems to build fine, runs ok, >> and what I tested (spiro LPE) works fine too. If there are any troubles, >> let me know. > > tested with r10031 on OS X 10.5.8, default prefs, compared with r10021: > > 1) select tool > transforming with the mouse (stretch, scale, skew) seems broken > > 2) node tool > node-editing of a path with auto-smooth nodes randomly (?) converts > un-affected auto-smooth nodes into cusps. > > In attached example: > - select e.g. an end node and move it: all auto-smooth nodes turn > into cusp nodes > - now select all nodes (Ctrl+A) and move the selection of nodes > (i.e. the whole path): auto-smooth nodes are restored r10032 is nearly unusable - any transformations with the select tool (scale, rotate, stretch, skew) use the wrong reference point and the dragged corner gets completely detached from the position of the mouse pointer. The issue was also confirmed by ScislaC (on irc) with r10032 on Ubuntu. other issues: 3) Node tool The previously mentioned issue with auto-smooth nodes in the the node tool affects smooth nodes and cusp nodes in paths created with the pen and pencil tool, see 4 and 5) as well. 4) Pencil (freehand) tool Curves drawn as freehand lines with the pencil tools now have cusp nodes with apparently extracted handles though they are not shown in the node tool (in r10021 and 0.48 they use smooth nodes) 5) Pen (bezier) tool Bezier curves drawn with the pen tool have cusp nodes instead of smooth nodes. No handles are displayed when editing the path in the node tool. When moving a node in the node tool or inserting a new node, all segments are turned into straight lines. Unlike described in 2) the handles can't be restored. ~suv ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Inkscape-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/inkscape-devel |
bzr rant... Was: Updated 2geom -- what changed?
|
|
In reply to this post by Josh Andler
> -----Original Message-----
> From: Josh Andler [mailto:[hidden email]] > Sent: 04 February 2011 09:06 > > On Thu, Feb 3, 2011 at 11:55 PM, <[hidden email]> wrote: > > - not providing functionality that I need often, while providing > functionality that is rarely used > > What are you looking for? As long as I have things like "pull", > "push", "add", "commit", "uncommit", "status", "diff", and other > basics... I'm pretty good. (I have become to hate bzr with quite some passion, so my arguments may be biased.) Most of the joy of version control (SVN) is gone for me, since there is no decent UI bzr client with Explorer integration, like TortoiseSVN. Unfortunately TortoiseBZR is *not* close to TortoiseSVN. >From the top of my head here are some things that annoy me: - that I can no longer see the overlays on file icons that say that the file is changed/unchanged/ignored/unversioned/... (I had to turn off this feature in tortoisebzr, otherwise explorer becomes really slow and unusable; ask any other windows dev) - The commit dialog can be quirky and slow, and does not show earlier commit messages (it can show unversioned files, but does not seem to save the status of the checkbox). - Resolving conflicts is something I do not understand in bzr. (e.g. just now I've been doing all kinds of tricks to get my tree 'correct' again) - No fixed revision numbers?! - I no longer dare to use the bzr update dialog, which also does not provide functionality to keep up-to-date about the source code, like TortoiseSVN does: click button "Show log..." and it only shows the log entries of changes since last update. - when an operation fails halfway, 50% chance of the tree being damaged, and completely new checkout needed, which takes a long time and can again fail halfway... I'm sure there are other devs that can append more to this list. One of the problems of explaining my annoyance with bzr is that if you have not used TortoiseSVN, it is perhaps hard to understand how easy, fun, understandable, and seamless a versioning system can be. For me, a versioning system without a UI is unusable for a big project like Inkscape. (say you want to revert/add/... some files, but not all, but they are spread around the tree a little bit. You'd have to type all those path/filename in the commandline, and of course you are going to forget some files since you have no overview whatsoever. With a UI, simply click some checkboxes) And to repeat, I really am willing to pay money to go back to SVN. Ciao, Johan ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Inkscape-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/inkscape-devel |
Re: bzr rant... Was: Updated 2geom -- what changed?
|
On Fri, 4 Feb 2011 19:02:20 +0100
<[hidden email]> wrote: > (I have become to hate bzr with quite some passion, so my arguments may > be biased.) :-} that's very honest, anyway - I guess it's only a form of bias if it leads you to count things against bzr unfairly. Personally I use bzr mostly from the command line, but I do sometimes use the QBzr http://wiki.bazaar.canonical.com/QBzr pseudo-gui, invoked for example as bzr qcommit These are just some minor factoids in case they're helpful, assuming (?) that a switch from bzr to SVN is unlikely. - the qcommit interface will show you non-versioned files also, have you looked at Bzr-explorer, which comes with the standalone windows bzr install? > - No fixed revision numbers?! - revision IDs are fixed, they're strings like 'tbrown@beaver-20110126225013-bij9m84cj3vycsrf' which are of course less appealing than simple numbers, but simple numbers aren't really possible in a distributed peer-to-peer system. Although having said that I thought Ted applied a setting to the lp repo so that subsuming other people's commits into a merged commit of your own is not possible, so lp rev no.s should be fairly fixed. > - when an operation fails halfway, 50% chance of the tree being damaged, > and completely new checkout needed, which takes a long time and can > again fail halfway... You can use shared repositories to avoid slow checkouts. Create a directory with bzr init-repo and then branch the lp trunk in there. Afterwards you can delete the trunk branch and branch it again and it should take long at all. I don't use the windows gui bzr tools much, but I know one of them, probably bzr-explorer, asked me about wrapping a branch in a shared repo when I went to branch something the other day. bzr supports multiple distinct workflows, I'm sure things could get confusing if you were mixing parts of different workflows. Personally I only use branch/merge/pull/push, I forget the checkout/update/commit semantics, although I suspect those are closer to SVN style. Cheers -Terry ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Inkscape-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/inkscape-devel |
Re: Updated 2geom -- what changed?
|
|
In reply to this post by ~suv-2
W dniu 4 lutego 2011 16:37 użytkownik ~suv
<[hidden email]> napisał: > @Johan or @Krzysztof - could you check it that *.cpp file (added in > r10028) is needed or if only its header file needs to be in Inkscape's > copy of 2geom? > > ~suv I think even the header is not necessary right now. Regards, Krzysztof ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Inkscape-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/inkscape-devel |
Re: bzr rant... Was: Updated 2geom -- what changed?
|
In reply to this post by J.B.C.Engelen
Bzr was a big part of me pretty much giving up trying with the main codebase. Last few times I found some spare time to try I just spent an entire evening getting pissed at how difficult something that should be trivial was being made by a bad tool. Slow, unreliable, and fairly incomprehensible.
Sent from my iPhone On 4 Feb 2011, at 18:02, <[hidden email]> wrote: >> -----Original Message----- >> From: Josh Andler [mailto:[hidden email]] >> Sent: 04 February 2011 09:06 >> >> On Thu, Feb 3, 2011 at 11:55 PM, <[hidden email]> > wrote: >>> - not providing functionality that I need often, while providing >> functionality that is rarely used >> >> What are you looking for? As long as I have things like "pull", >> "push", "add", "commit", "uncommit", "status", "diff", and other >> basics... I'm pretty good. > > (I have become to hate bzr with quite some passion, so my arguments may > be biased.) > Most of the joy of version control (SVN) is gone for me, since there is > no decent UI bzr client with Explorer integration, like TortoiseSVN. > Unfortunately TortoiseBZR is *not* close to TortoiseSVN. >> From the top of my head here are some things that annoy me: > - that I can no longer see the overlays on file icons that say that the > file is changed/unchanged/ignored/unversioned/... (I had to turn off > this feature in tortoisebzr, otherwise explorer becomes really slow and > unusable; ask any other windows dev) > - The commit dialog can be quirky and slow, and does not show earlier > commit messages (it can show unversioned files, but does not seem to > save the status of the checkbox). > - Resolving conflicts is something I do not understand in bzr. (e.g. > just now I've been doing all kinds of tricks to get my tree 'correct' > again) > - No fixed revision numbers?! > - I no longer dare to use the bzr update dialog, which also does not > provide functionality to keep up-to-date about the source code, like > TortoiseSVN does: click button "Show log..." and it only shows the log > entries of changes since last update. > - when an operation fails halfway, 50% chance of the tree being damaged, > and completely new checkout needed, which takes a long time and can > again fail halfway... > I'm sure there are other devs that can append more to this list. > One of the problems of explaining my annoyance with bzr is that if you > have not used TortoiseSVN, it is perhaps hard to understand how easy, > fun, understandable, and seamless a versioning system can be. For me, a > versioning system without a UI is unusable for a big project like > Inkscape. (say you want to revert/add/... some files, but not all, but > they are spread around the tree a little bit. You'd have to type all > those path/filename in the commandline, and of course you are going to > forget some files since you have no overview whatsoever. With a UI, > simply click some checkboxes) > > And to repeat, I really am willing to pay money to go back to SVN. > > Ciao, > Johan > > > ------------------------------------------------------------------------------ > The modern datacenter depends on network connectivity to access resources > and provide services. The best practices for maximizing a physical server's > connectivity to a physical network are well understood - see how these > rules translate into the virtual world? > http://p.sf.net/sfu/oracle-sfdevnlfb > _______________________________________________ > Inkscape-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/inkscape-devel ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Inkscape-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/inkscape-devel |
Re: bzr rant... Was: Updated 2geom -- what changed?
|
|
In reply to this post by J.B.C.Engelen
2011/2/4 <[hidden email]>:
> (I have become to hate bzr with quite some passion, so my arguments may > be biased.) 95% of your complaints are related to TortoiseBZR rather than Bazaar itself. The GUI situation is not perfect in Bazaar. For now I think it's better to learn to use it from the command line - I've never had problems this way. The CLI is much easier to understand than Git, and in some respects even easier than SVN (for example, no possibility of mixed-revision tree, which never made any sense for me). You can also check out QBzr; it's not an Explorer extension like Tortoise projects, but it gives you GUI dialogs for most operations. There is a Windows installer here: http://wiki.bazaar.canonical.com/QBzr > - Resolving conflicts is something I do not understand in bzr. (e.g. > just now I've been doing all kinds of tricks to get my tree 'correct' > again) When you have a conflict in file.cpp, 3 files get created: file.cpp.BASE, file.cpp.OTHER, and file.cpp.THIS. file.cpp contains the usual >>>> marks known from SVN. file.cpp.BASE contains the revision of the file at which the versions of file.cpp here and in the merge source diverged. file.cpp.OTHER contains the merge source's version of the file. file.cpp.THIS contains the version of the file from this working tree (merge target). You can fix the conflict by overwriting file.cpp with one of thr above, or editing file.cpp to fix it manually. Once you are done, you need to say "bzr resolve file.cpp" or, equivalently, delete all 3 files listed above (those ending in .BASE, .OTHER and .THIS). The last step is different than in SVN, so it might have been causing you some problems. You can also fix all conflicts at once and then say "bzr resolve --all", which saves you some typing. I think > - I no longer dare to use the bzr update dialog, which also does not > provide functionality to keep up-to-date about the source code, like > TortoiseSVN does: click button "Show log..." and it only shows the log > entries of changes since last update. Use "bzr log -l N" where N is the number of latest revisions you want to see. On POSIX systems you can just say "bzr log -l 100 | less" to scroll through the changelog of 100 most recent revisions. I don't know whether Windows has a pager similar to GNU less. > - when an operation fails halfway, 50% chance of the tree being damaged, > and completely new checkout needed, which takes a long time and can > again fail halfway... I didn't encounter any operations failing halfway, and I never ended up with a broken tree. A few times I had to interrupt a long running command and ended up with a lock on the remote branch, but it was easily solved with "bzr break-lock" (the CLI suggested this command in an error message). I guess it might be TortoiseBZR's fault too. > For me, a > versioning system without a UI is unusable for a big project like > Inkscape. (say you want to revert/add/... some files, but not all, but > they are spread around the tree a little bit. You'd have to type all > those path/filename in the commandline, and of course you are going to > forget some files since you have no overview whatsoever. With a UI, > simply click some checkboxes) As far as I understand, you can use QBzr to pick files you want to commit / revert / add using a GUI. Since it's not an Explorer extension, it should be much faster than Tortoise. > And to repeat, I really am willing to pay money to go back to SVN. I am willing to pay 2x more than you to stay with Bazaar, because - for example - I would not be able to maintain the Cairo rendering branch using SVN. It would just take too much time due to SVN slowness. By the way, I'm not dismissing your complaints - I just think that resolving them is going to be much more productive in the long run than going back to a centralized VCS. Regards, Krzysztof ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Inkscape-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/inkscape-devel |
Re: bzr rant... Was: Updated 2geom -- what changed?
|
|
In reply to this post by john cliff-2
2011/2/4 John Cliff <[hidden email]>:
> Bzr was a big part of me pretty much giving up trying with the main codebase. Last few times I found some spare time to try I just spent an entire evening getting pissed at how difficult something that should be trivial was being made by a bad tool. Slow, unreliable, and fairly incomprehensible. The only slow thing I encountered in Bazaar was the initial checkout and pushing a new branch to LP, everything else is fairly quick - no different from SVN, which also takes some time to do those operations. Committing to a remote branch is far quicker in Bazaar. As for incomprehensible - replacing "svn" with "bzr" in a corresponding SVN command makes things work 95% of the time. This argument would have some merit if we used Git, which is vastly different and uses a lot of idiosyncratic concepts, but I can't see how it applies to Bazaar. For the user, the only basic thing different between those two is the conflict resolution, which I admit is a little harder in Bazaar. It would be useful to know what exactly was your problem, otherwise I can't suggest any solution. Regards, Krzysztof ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Inkscape-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/inkscape-devel |
«
Return to Inkscape - Dev
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |