Looking for Code Inefficiences
by Natalie Sanders
Hi All!
I'm new to the community and I'm looking to improve any code
inefficiencies, especially inefficient data structures. Do you have any
suggestions on where to start? Thanks!
Best,
Natalie
--
Natalie Sanders
University of Notre Dame
Class of 2016
Computer Science Major
8 years, 6 months
Good Introductory Bugs
by Kathryn Weiss
Hello,
I am a relatively new programmer. I am looking to gain some coding
experience and I am interested in developing Inkscape. In particular, I am
looking at trying to fix bugs or improve performance related to data
structures. I was wondering if anyone had advice as to specific areas that
need this sort of work. Thank you for your help!
Sincerely,
KW
8 years, 6 months
Testing related
by Josh Andler
Hey all,
There has been quite a bit of discussion over the past couple months
related to testing. Thanks to an inquiry from someone interested in
helping us improve Inkscape, it was a reminder that we have a mailing
list which used to be dedicated to the topic.
https://lists.sourceforge.net/lists/listinfo/inkscape-tester
In looking back in the archive, there were regular posts from
automated builds of Inkscape which would provide compilation warnings
and errors encountered during the build.
It seems like it would be great to get the results from Coverity,
automated builds, and the test framework (whatever we end up with)
posted there. Any thoughts on us doing this?
Cheers,
Josh
8 years, 6 months
Feature Freeze for 0.91
by Bryce Harrington
3. Frost. √ Experimental Branch is forked
√ Mainline Branch focuses on stabilization
√ Only production-ready code committed to Mainline
√ Post inkscape-0.91-pre0.tar.gz
√ Finalize any major changes to platform packaging
√ Release Notes should be >90% filled in.
√ Inkscape must pass >90% of 'make distcheck'
√ Start an About Screen contest
√ General Bug Hunt: 1500 points
√ Post additional inkscape-0.91-pre*.tar.gz releases
√ Packagers test creating pkgs of the -pre* releases
4. Feature Freeze √ Stable Branch is forked from Mainline
Regular development resumes on Mainline.
Avoid major refactorings on Mainline.
Only bug fixes committed to Stable Branch.
Bug fixes are cherrypicked from Mainline.
Inkscape must pass 'make distcheck'
String Freeze No further string changes allowed on Stable Branch.
Finalize tutorials to be shipped with release
Finalize other docs included in the release
Finalize about screen
Finalize Release Notes except Known Issues
Translators work on translations.
Recruit Release Wardens for Hard Freeze
Inkscape has completed the Frost phase and is moving into Freeze.
Translators, please fire up your engines! You have (at least) until
Nov 18th to commit translation updates to the stable branch.
------------------------------------------------------------------------
A stable branch lp:inkscape/0.91.x has been split off of trunk. Only
strict bug fixes and translations may be committed to this branch; for
anything else please seek release manager approval (Josh or Bryce).
# Stable branch
bzr clone lp:inkscape/0.91.x inkscape-0.91-stable
You will need to check this out only if you intend to check in fixes to
the stable branch.
IMPORTANT: Do not make changes to translatable strings in the stable
branch. If it is critical that a string change be made, please get
approval from the release managers first!
------------------------------------------------------------------------
The lp:inkscape branch (trunk) is now open for regular development
towards the 0.92.x series.
# Development branch
bzr clone lp:inkscape
You don't need to do anything with your current branch if you just want
to keep committing to the development branch.
Congrats to everyone that helped us get this far,
Bryce
8 years, 6 months
Merge of experimental branch
by Liam White
With Bryce's permission, I have merged the experimental branch into trunk.
Trunk is now open for development. Please do not make further commits
to experimental.
If you do not use a separate directory for build and source:
> $ bzr pull lp:inkscape
…
> Conflict: can't delete src/dialogs because it is not empty. Not deleting.
> 1 conflicts encountered.
> Now on revision 13641.
> $ rm -rf src/dialogs
> $ bzr revert
This should fix your local copy.
8 years, 6 months
Static analysis results
by Jon A. Cruz
Hi,
I've been working with Johan and Bryce on the clang and Coverity
analysis. Bryce should be getting the coverity runs more automated soon,
but we'll take a little before things get published. We'll need to
ensure we are sensitive to security, disclosure, etc.
However I do have a few preliminary results. First goes to leveraging
the clang results effectively. We'll need to pull together some wiki
info on which clang issues to prioritize, and what approaches might be
used for remediation of some of the reported problems. Initially we have
one question on "Dead assignment" and the other dead store. The first
case Johan and I looked at was one that did warrant skipping
initialization... however clang reports 167 of those while Coverity
lists only 8 issues that might overlap them. So this set of clang
warnings appears to be a bit subjective on the clang dev's part, or
perhaps just more advisory. So we should probably look at addressing
those last.
In the Coverity results I spotted two different big-picture issues
hiding in the details. One warrants just low-level code cleanup while
the other should be looked over by as many people keeping 'architecture'
in mind.
The simple issue is with the GTK-style casting macros such as
SP_IS_USE(x) and SP_USE(x). They started out following the GTK team's
approach to adding objects to C. A while back these were refactored to
be C++ oriented so existing code would not have to be changed as we
migrated to true classes. However, the usage is backwards
(check-then-cast vs. cast-then-check) and conceptually there are some
big mismatches that lead to most usages being vulnerable to null pointer
dereferencing. Conceptually these are also backwards as they use
run-time checks instead of compile-time checks.
>From an implementation viewpoint, these macros have two major problems.
First is that they cast away any const attributes and thus make the code
less safe. Secondly (and far more critical) they are using C-Style casts
that also make them take any random block of data and treat it as a
proper C++ object. One of my test cases was to feed the macros a simple
array of 5 arbitrary bytes. I expected it to accept but result in NULL,
however it instead gave me a seemingly valid SPUse pointer. Not good.
The good news is that in the vast majority of cases, no macros or casts
are needed at all in C++ (for upcasting, etc.) and thus their use can
just be removed. I'm working through an initial cleanup pass that should
correct all but those where the improper loss of 'const' comes into
play. This cleanup is good since these macros are responsible for
600-800 of the outstanding 1,135 Coverity defects.
The second issue is a higher-level problem of design and naming. There
are a few methods who's names appear to be leading to buggy use. The
main example is SPShape::getCurve(). The problem is that to convey
proper meaning this probably should be called something more like
SPShape::generateNewCurve(). Many developers were treating it similar to
std::string::c_str() and accessing it to query attributes of the
resulting curve without explicitly grabbing and then freeing the curve.
That is, the name implied access to an existing object instead of
creation and ownership transfer of a new object.
To fix this we might simply change the naming approach (e.g. avoid
'getFoo()' for anything that allocates) and the using code... or we
could change getCurve() and friends to operate on an internal object
that is persistent... or perhaps something else.
--
Jon A. Cruz
jon@...18...
8 years, 6 months
need a short name
by Jabier Arraiza
Hi to all, i want a short name to a type of fillet chamfer. Currently is
called "double chamfer" but i want add a int parameter to subdivide the
chamfer in more steps than one. see the attachment.
I want a two word name at max, because is in a GUI button.
Im thinking in:
multi chamfer
chamfer steped...
Finaly, about this, i have another question, could I remove this button
"double chamfer" and manage it in the chamfer subdivision? The only
disventage i find, is you can't have a "real chamfer" -0 subdivision-
and a stepper chamfer in the same path.
Removing or not the "double chamfer" button, there is only one
subdivision to all chamfers in the path, also a extra "no subdivision"
-0- in case of retain the button.
Think i explain well, but tell me if dont undertand my "english".
Cheers, Jabier.
8 years, 6 months
cannot link rev 13646, Windows XP
by alvinpenner
attempting to compile rev 13646, devlibs rev 52, I get the following link
error:
--- link / rc
--- link / link
============ cmd ============
mingw32-g++ -o build/inkscape.exe -mwindows -mthreads
build\obj\2geom\affine.o b
uild\obj\2geom\basic-intersection.o build\obj\2geom\bezier-clipping.o
build\obj\
2geom\bezier-curve.o build\obj\2geom\bezier-utils.o
build\obj\2geom\circle-circl
e.o build\obj\2geom\circle.o build\obj\2geom\conic_section_clipper_impl.o
build\
obj\2geom\conicsec.o build\obj\2geom\conjugate_gradient.o
build\obj\2geom\convex
-cover.o build\obj\2geom\crossing.o build\obj\2geom\curve.o
build\obj\2geom\d2-s
basis.o build\obj\2geom\ellipse.o build\obj\2geom\elliptical-arc.o
build\obj\2ge
...
snip
...
9 -Lc:\devlibs/lib -lwpd-stream-0.9 -Lc:\devlibs/lib -lwpg-0.2
-Lc:\devlibs/lib
-llcms2 -liconv -Lc:\devlibs/lib -lMagick++ -Lc:\devlibs/lib -lMagickCore
-Lc:\d
evlibs/lib -lfontconfig -Lc:\devlibs/lib -lfreetype -Lc:\devlibs/lib -llcms2
-Lc
:\devlibs/lib -lgsl -lgslcblas -lm -lpng -ljpeg -ltiff -lexif -lpopt -lz
-lgc -l
ws2_32 -lintl -lgdi32 -lcomdlg32 -lm -lgomp -lpthreadGC2 -laspell -lmscms
=============================
Make error line 447: LINK problem: mingw32-g++: error: CreateProcess: No
such file or directory
Cheers,
Alvin
--
View this message in context: http://inkscape.13.x6.nabble.com/cannot-link-rev-13646-Windows-XP-tp49719...
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
8 years, 6 months
