- Removed other unused logotypes
- Updated votazioni.txt git-svn-id: svn://svn.gna.org/svn/sgpemv2/trunk@121 3ecf2c5c-341e-0410-92b4-d18e462d057c
This commit is contained in:
commit
5e4c6b3ad2
|
@ -0,0 +1,452 @@
|
|||
|
||||
@appendix License
|
||||
|
||||
@cindex FDL, GNU Free Documentation License
|
||||
@center @strong{GNU Free Documentation License}
|
||||
@center Version 1.2, November 2002
|
||||
|
||||
@display
|
||||
Copyright @copyright{} 2000,2001,2002 Free Software Foundation, Inc.
|
||||
51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
|
||||
|
||||
Everyone is permitted to copy and distribute verbatim copies
|
||||
of this license document, but changing it is not allowed.
|
||||
@end display
|
||||
|
||||
@enumerate 0
|
||||
@item
|
||||
PREAMBLE
|
||||
|
||||
The purpose of this License is to make a manual, textbook, or other
|
||||
functional and useful document @dfn{free} in the sense of freedom: to
|
||||
assure everyone the effective freedom to copy and redistribute it,
|
||||
with or without modifying it, either commercially or noncommercially.
|
||||
Secondarily, this License preserves for the author and publisher a way
|
||||
to get credit for their work, while not being considered responsible
|
||||
for modifications made by others.
|
||||
|
||||
This License is a kind of ``copyleft'', which means that derivative
|
||||
works of the document must themselves be free in the same sense. It
|
||||
complements the GNU General Public License, which is a copyleft
|
||||
license designed for free software.
|
||||
|
||||
We have designed this License in order to use it for manuals for free
|
||||
software, because free software needs free documentation: a free
|
||||
program should come with manuals providing the same freedoms that the
|
||||
software does. But this License is not limited to software manuals;
|
||||
it can be used for any textual work, regardless of subject matter or
|
||||
whether it is published as a printed book. We recommend this License
|
||||
principally for works whose purpose is instruction or reference.
|
||||
|
||||
@item
|
||||
APPLICABILITY AND DEFINITIONS
|
||||
|
||||
This License applies to any manual or other work, in any medium, that
|
||||
contains a notice placed by the copyright holder saying it can be
|
||||
distributed under the terms of this License. Such a notice grants a
|
||||
world-wide, royalty-free license, unlimited in duration, to use that
|
||||
work under the conditions stated herein. The ``Document'', below,
|
||||
refers to any such manual or work. Any member of the public is a
|
||||
licensee, and is addressed as ``you''. You accept the license if you
|
||||
copy, modify or distribute the work in a way requiring permission
|
||||
under copyright law.
|
||||
|
||||
A ``Modified Version'' of the Document means any work containing the
|
||||
Document or a portion of it, either copied verbatim, or with
|
||||
modifications and/or translated into another language.
|
||||
|
||||
A ``Secondary Section'' is a named appendix or a front-matter section
|
||||
of the Document that deals exclusively with the relationship of the
|
||||
publishers or authors of the Document to the Document's overall
|
||||
subject (or to related matters) and contains nothing that could fall
|
||||
directly within that overall subject. (Thus, if the Document is in
|
||||
part a textbook of mathematics, a Secondary Section may not explain
|
||||
any mathematics.) The relationship could be a matter of historical
|
||||
connection with the subject or with related matters, or of legal,
|
||||
commercial, philosophical, ethical or political position regarding
|
||||
them.
|
||||
|
||||
The ``Invariant Sections'' are certain Secondary Sections whose titles
|
||||
are designated, as being those of Invariant Sections, in the notice
|
||||
that says that the Document is released under this License. If a
|
||||
section does not fit the above definition of Secondary then it is not
|
||||
allowed to be designated as Invariant. The Document may contain zero
|
||||
Invariant Sections. If the Document does not identify any Invariant
|
||||
Sections then there are none.
|
||||
|
||||
The ``Cover Texts'' are certain short passages of text that are listed,
|
||||
as Front-Cover Texts or Back-Cover Texts, in the notice that says that
|
||||
the Document is released under this License. A Front-Cover Text may
|
||||
be at most 5 words, and a Back-Cover Text may be at most 25 words.
|
||||
|
||||
A ``Transparent'' copy of the Document means a machine-readable copy,
|
||||
represented in a format whose specification is available to the
|
||||
general public, that is suitable for revising the document
|
||||
straightforwardly with generic text editors or (for images composed of
|
||||
pixels) generic paint programs or (for drawings) some widely available
|
||||
drawing editor, and that is suitable for input to text formatters or
|
||||
for automatic translation to a variety of formats suitable for input
|
||||
to text formatters. A copy made in an otherwise Transparent file
|
||||
format whose markup, or absence of markup, has been arranged to thwart
|
||||
or discourage subsequent modification by readers is not Transparent.
|
||||
An image format is not Transparent if used for any substantial amount
|
||||
of text. A copy that is not ``Transparent'' is called ``Opaque''.
|
||||
|
||||
Examples of suitable formats for Transparent copies include plain
|
||||
@sc{ascii} without markup, Texinfo input format, La@TeX{} input
|
||||
format, @acronym{SGML} or @acronym{XML} using a publicly available
|
||||
@acronym{DTD}, and standard-conforming simple @acronym{HTML},
|
||||
PostScript or @acronym{PDF} designed for human modification. Examples
|
||||
of transparent image formats include @acronym{PNG}, @acronym{XCF} and
|
||||
@acronym{JPG}. Opaque formats include proprietary formats that can be
|
||||
read and edited only by proprietary word processors, @acronym{SGML} or
|
||||
@acronym{XML} for which the @acronym{DTD} and/or processing tools are
|
||||
not generally available, and the machine-generated @acronym{HTML},
|
||||
PostScript or @acronym{PDF} produced by some word processors for
|
||||
output purposes only.
|
||||
|
||||
The ``Title Page'' means, for a printed book, the title page itself,
|
||||
plus such following pages as are needed to hold, legibly, the material
|
||||
this License requires to appear in the title page. For works in
|
||||
formats which do not have any title page as such, ``Title Page'' means
|
||||
the text near the most prominent appearance of the work's title,
|
||||
preceding the beginning of the body of the text.
|
||||
|
||||
A section ``Entitled XYZ'' means a named subunit of the Document whose
|
||||
title either is precisely XYZ or contains XYZ in parentheses following
|
||||
text that translates XYZ in another language. (Here XYZ stands for a
|
||||
specific section name mentioned below, such as ``Acknowledgements'',
|
||||
``Dedications'', ``Endorsements'', or ``History''.) To ``Preserve the Title''
|
||||
of such a section when you modify the Document means that it remains a
|
||||
section ``Entitled XYZ'' according to this definition.
|
||||
|
||||
The Document may include Warranty Disclaimers next to the notice which
|
||||
states that this License applies to the Document. These Warranty
|
||||
Disclaimers are considered to be included by reference in this
|
||||
License, but only as regards disclaiming warranties: any other
|
||||
implication that these Warranty Disclaimers may have is void and has
|
||||
no effect on the meaning of this License.
|
||||
|
||||
@item
|
||||
VERBATIM COPYING
|
||||
|
||||
You may copy and distribute the Document in any medium, either
|
||||
commercially or noncommercially, provided that this License, the
|
||||
copyright notices, and the license notice saying this License applies
|
||||
to the Document are reproduced in all copies, and that you add no other
|
||||
conditions whatsoever to those of this License. You may not use
|
||||
technical measures to obstruct or control the reading or further
|
||||
copying of the copies you make or distribute. However, you may accept
|
||||
compensation in exchange for copies. If you distribute a large enough
|
||||
number of copies you must also follow the conditions in section 3.
|
||||
|
||||
You may also lend copies, under the same conditions stated above, and
|
||||
you may publicly display copies.
|
||||
|
||||
@item
|
||||
COPYING IN QUANTITY
|
||||
|
||||
If you publish printed copies (or copies in media that commonly have
|
||||
printed covers) of the Document, numbering more than 100, and the
|
||||
Document's license notice requires Cover Texts, you must enclose the
|
||||
copies in covers that carry, clearly and legibly, all these Cover
|
||||
Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on
|
||||
the back cover. Both covers must also clearly and legibly identify
|
||||
you as the publisher of these copies. The front cover must present
|
||||
the full title with all words of the title equally prominent and
|
||||
visible. You may add other material on the covers in addition.
|
||||
Copying with changes limited to the covers, as long as they preserve
|
||||
the title of the Document and satisfy these conditions, can be treated
|
||||
as verbatim copying in other respects.
|
||||
|
||||
If the required texts for either cover are too voluminous to fit
|
||||
legibly, you should put the first ones listed (as many as fit
|
||||
reasonably) on the actual cover, and continue the rest onto adjacent
|
||||
pages.
|
||||
|
||||
If you publish or distribute Opaque copies of the Document numbering
|
||||
more than 100, you must either include a machine-readable Transparent
|
||||
copy along with each Opaque copy, or state in or with each Opaque copy
|
||||
a computer-network location from which the general network-using
|
||||
public has access to download using public-standard network protocols
|
||||
a complete Transparent copy of the Document, free of added material.
|
||||
If you use the latter option, you must take reasonably prudent steps,
|
||||
when you begin distribution of Opaque copies in quantity, to ensure
|
||||
that this Transparent copy will remain thus accessible at the stated
|
||||
location until at least one year after the last time you distribute an
|
||||
Opaque copy (directly or through your agents or retailers) of that
|
||||
edition to the public.
|
||||
|
||||
It is requested, but not required, that you contact the authors of the
|
||||
Document well before redistributing any large number of copies, to give
|
||||
them a chance to provide you with an updated version of the Document.
|
||||
|
||||
@item
|
||||
MODIFICATIONS
|
||||
|
||||
You may copy and distribute a Modified Version of the Document under
|
||||
the conditions of sections 2 and 3 above, provided that you release
|
||||
the Modified Version under precisely this License, with the Modified
|
||||
Version filling the role of the Document, thus licensing distribution
|
||||
and modification of the Modified Version to whoever possesses a copy
|
||||
of it. In addition, you must do these things in the Modified Version:
|
||||
|
||||
@enumerate A
|
||||
@item
|
||||
Use in the Title Page (and on the covers, if any) a title distinct
|
||||
from that of the Document, and from those of previous versions
|
||||
(which should, if there were any, be listed in the History section
|
||||
of the Document). You may use the same title as a previous version
|
||||
if the original publisher of that version gives permission.
|
||||
|
||||
@item
|
||||
List on the Title Page, as authors, one or more persons or entities
|
||||
responsible for authorship of the modifications in the Modified
|
||||
Version, together with at least five of the principal authors of the
|
||||
Document (all of its principal authors, if it has fewer than five),
|
||||
unless they release you from this requirement.
|
||||
|
||||
@item
|
||||
State on the Title page the name of the publisher of the
|
||||
Modified Version, as the publisher.
|
||||
|
||||
@item
|
||||
Preserve all the copyright notices of the Document.
|
||||
|
||||
@item
|
||||
Add an appropriate copyright notice for your modifications
|
||||
adjacent to the other copyright notices.
|
||||
|
||||
@item
|
||||
Include, immediately after the copyright notices, a license notice
|
||||
giving the public permission to use the Modified Version under the
|
||||
terms of this License, in the form shown in the Addendum below.
|
||||
|
||||
@item
|
||||
Preserve in that license notice the full lists of Invariant Sections
|
||||
and required Cover Texts given in the Document's license notice.
|
||||
|
||||
@item
|
||||
Include an unaltered copy of this License.
|
||||
|
||||
@item
|
||||
Preserve the section Entitled ``History'', Preserve its Title, and add
|
||||
to it an item stating at least the title, year, new authors, and
|
||||
publisher of the Modified Version as given on the Title Page. If
|
||||
there is no section Entitled ``History'' in the Document, create one
|
||||
stating the title, year, authors, and publisher of the Document as
|
||||
given on its Title Page, then add an item describing the Modified
|
||||
Version as stated in the previous sentence.
|
||||
|
||||
@item
|
||||
Preserve the network location, if any, given in the Document for
|
||||
public access to a Transparent copy of the Document, and likewise
|
||||
the network locations given in the Document for previous versions
|
||||
it was based on. These may be placed in the ``History'' section.
|
||||
You may omit a network location for a work that was published at
|
||||
least four years before the Document itself, or if the original
|
||||
publisher of the version it refers to gives permission.
|
||||
|
||||
@item
|
||||
For any section Entitled ``Acknowledgements'' or ``Dedications'', Preserve
|
||||
the Title of the section, and preserve in the section all the
|
||||
substance and tone of each of the contributor acknowledgements and/or
|
||||
dedications given therein.
|
||||
|
||||
@item
|
||||
Preserve all the Invariant Sections of the Document,
|
||||
unaltered in their text and in their titles. Section numbers
|
||||
or the equivalent are not considered part of the section titles.
|
||||
|
||||
@item
|
||||
Delete any section Entitled ``Endorsements''. Such a section
|
||||
may not be included in the Modified Version.
|
||||
|
||||
@item
|
||||
Do not retitle any existing section to be Entitled ``Endorsements'' or
|
||||
to conflict in title with any Invariant Section.
|
||||
|
||||
@item
|
||||
Preserve any Warranty Disclaimers.
|
||||
@end enumerate
|
||||
|
||||
If the Modified Version includes new front-matter sections or
|
||||
appendices that qualify as Secondary Sections and contain no material
|
||||
copied from the Document, you may at your option designate some or all
|
||||
of these sections as invariant. To do this, add their titles to the
|
||||
list of Invariant Sections in the Modified Version's license notice.
|
||||
These titles must be distinct from any other section titles.
|
||||
|
||||
You may add a section Entitled ``Endorsements'', provided it contains
|
||||
nothing but endorsements of your Modified Version by various
|
||||
parties---for example, statements of peer review or that the text has
|
||||
been approved by an organization as the authoritative definition of a
|
||||
standard.
|
||||
|
||||
You may add a passage of up to five words as a Front-Cover Text, and a
|
||||
passage of up to 25 words as a Back-Cover Text, to the end of the list
|
||||
of Cover Texts in the Modified Version. Only one passage of
|
||||
Front-Cover Text and one of Back-Cover Text may be added by (or
|
||||
through arrangements made by) any one entity. If the Document already
|
||||
includes a cover text for the same cover, previously added by you or
|
||||
by arrangement made by the same entity you are acting on behalf of,
|
||||
you may not add another; but you may replace the old one, on explicit
|
||||
permission from the previous publisher that added the old one.
|
||||
|
||||
The author(s) and publisher(s) of the Document do not by this License
|
||||
give permission to use their names for publicity for or to assert or
|
||||
imply endorsement of any Modified Version.
|
||||
|
||||
@item
|
||||
COMBINING DOCUMENTS
|
||||
|
||||
You may combine the Document with other documents released under this
|
||||
License, under the terms defined in section 4 above for modified
|
||||
versions, provided that you include in the combination all of the
|
||||
Invariant Sections of all of the original documents, unmodified, and
|
||||
list them all as Invariant Sections of your combined work in its
|
||||
license notice, and that you preserve all their Warranty Disclaimers.
|
||||
|
||||
The combined work need only contain one copy of this License, and
|
||||
multiple identical Invariant Sections may be replaced with a single
|
||||
copy. If there are multiple Invariant Sections with the same name but
|
||||
different contents, make the title of each such section unique by
|
||||
adding at the end of it, in parentheses, the name of the original
|
||||
author or publisher of that section if known, or else a unique number.
|
||||
Make the same adjustment to the section titles in the list of
|
||||
Invariant Sections in the license notice of the combined work.
|
||||
|
||||
In the combination, you must combine any sections Entitled ``History''
|
||||
in the various original documents, forming one section Entitled
|
||||
``History''; likewise combine any sections Entitled ``Acknowledgements'',
|
||||
and any sections Entitled ``Dedications''. You must delete all
|
||||
sections Entitled ``Endorsements.''
|
||||
|
||||
@item
|
||||
COLLECTIONS OF DOCUMENTS
|
||||
|
||||
You may make a collection consisting of the Document and other documents
|
||||
released under this License, and replace the individual copies of this
|
||||
License in the various documents with a single copy that is included in
|
||||
the collection, provided that you follow the rules of this License for
|
||||
verbatim copying of each of the documents in all other respects.
|
||||
|
||||
You may extract a single document from such a collection, and distribute
|
||||
it individually under this License, provided you insert a copy of this
|
||||
License into the extracted document, and follow this License in all
|
||||
other respects regarding verbatim copying of that document.
|
||||
|
||||
@item
|
||||
AGGREGATION WITH INDEPENDENT WORKS
|
||||
|
||||
A compilation of the Document or its derivatives with other separate
|
||||
and independent documents or works, in or on a volume of a storage or
|
||||
distribution medium, is called an ``aggregate'' if the copyright
|
||||
resulting from the compilation is not used to limit the legal rights
|
||||
of the compilation's users beyond what the individual works permit.
|
||||
When the Document is included in an aggregate, this License does not
|
||||
apply to the other works in the aggregate which are not themselves
|
||||
derivative works of the Document.
|
||||
|
||||
If the Cover Text requirement of section 3 is applicable to these
|
||||
copies of the Document, then if the Document is less than one half of
|
||||
the entire aggregate, the Document's Cover Texts may be placed on
|
||||
covers that bracket the Document within the aggregate, or the
|
||||
electronic equivalent of covers if the Document is in electronic form.
|
||||
Otherwise they must appear on printed covers that bracket the whole
|
||||
aggregate.
|
||||
|
||||
@item
|
||||
TRANSLATION
|
||||
|
||||
Translation is considered a kind of modification, so you may
|
||||
distribute translations of the Document under the terms of section 4.
|
||||
Replacing Invariant Sections with translations requires special
|
||||
permission from their copyright holders, but you may include
|
||||
translations of some or all Invariant Sections in addition to the
|
||||
original versions of these Invariant Sections. You may include a
|
||||
translation of this License, and all the license notices in the
|
||||
Document, and any Warranty Disclaimers, provided that you also include
|
||||
the original English version of this License and the original versions
|
||||
of those notices and disclaimers. In case of a disagreement between
|
||||
the translation and the original version of this License or a notice
|
||||
or disclaimer, the original version will prevail.
|
||||
|
||||
If a section in the Document is Entitled ``Acknowledgements'',
|
||||
``Dedications'', or ``History'', the requirement (section 4) to Preserve
|
||||
its Title (section 1) will typically require changing the actual
|
||||
title.
|
||||
|
||||
@item
|
||||
TERMINATION
|
||||
|
||||
You may not copy, modify, sublicense, or distribute the Document except
|
||||
as expressly provided for under this License. Any other attempt to
|
||||
copy, modify, sublicense or distribute the Document is void, and will
|
||||
automatically terminate your rights under this License. However,
|
||||
parties who have received copies, or rights, from you under this
|
||||
License will not have their licenses terminated so long as such
|
||||
parties remain in full compliance.
|
||||
|
||||
@item
|
||||
FUTURE REVISIONS OF THIS LICENSE
|
||||
|
||||
The Free Software Foundation may publish new, revised versions
|
||||
of the GNU Free Documentation License from time to time. Such new
|
||||
versions will be similar in spirit to the present version, but may
|
||||
differ in detail to address new problems or concerns. See
|
||||
@uref{http://www.gnu.org/copyleft/}.
|
||||
|
||||
Each version of the License is given a distinguishing version number.
|
||||
If the Document specifies that a particular numbered version of this
|
||||
License ``or any later version'' applies to it, you have the option of
|
||||
following the terms and conditions either of that specified version or
|
||||
of any later version that has been published (not as a draft) by the
|
||||
Free Software Foundation. If the Document does not specify a version
|
||||
number of this License, you may choose any version ever published (not
|
||||
as a draft) by the Free Software Foundation.
|
||||
@end enumerate
|
||||
|
||||
@page
|
||||
@appendixsubsec @emph{Addendum}: How to use this License for your documents
|
||||
|
||||
To use this License in a document you have written, include a copy of
|
||||
the License in the document and put the following copyright and
|
||||
license notices just after the title page:
|
||||
|
||||
@smallexample
|
||||
@group
|
||||
Copyright (C) @var{year} @var{your name}.
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.2
|
||||
or any later version published by the Free Software Foundation;
|
||||
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.
|
||||
@end group
|
||||
@end smallexample
|
||||
|
||||
If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,
|
||||
replace the ``with...Texts.'' line with this:
|
||||
|
||||
@smallexample
|
||||
@group
|
||||
with the Invariant Sections being @var{list their titles}, with
|
||||
the Front-Cover Texts being @var{list}, and with the Back-Cover Texts
|
||||
being @var{list}.
|
||||
@end group
|
||||
@end smallexample
|
||||
|
||||
If you have Invariant Sections without Cover Texts, or some other
|
||||
combination of the three, merge those two alternatives to suit the
|
||||
situation.
|
||||
|
||||
If your document contains nontrivial examples of program code, we
|
||||
recommend releasing these examples in parallel under your choice of
|
||||
free software license, such as the GNU General Public License,
|
||||
to permit their use in free software.
|
||||
|
||||
@c Local Variables:
|
||||
@c ispell-local-pdict: "ispell-dict"
|
||||
@c End:
|
||||
|
|
@ -0,0 +1,37 @@
|
|||
\input texinfo @c -*-texinfo-*-
|
||||
|
||||
@c %**start of header
|
||||
@setfilename sgpem2.info
|
||||
@settitle SGPEM v2 Manuals
|
||||
@include version.texi
|
||||
@c %**end of header
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@copying
|
||||
This is SGPEM v2 Manual (version @value{VERSION},
|
||||
@value{UPDATED}).
|
||||
|
||||
Copyright @copyright{} 2005 University of Padova, dep. of Pure
|
||||
and Applied Mathematics
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.2
|
||||
or any later version published by the Free Software Foundation;
|
||||
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled "GNU
|
||||
Free Documentation License".
|
||||
@end copying
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@dircategory SGPEM v2
|
||||
@direntry
|
||||
* SGPEM v2 User Manual : (sgpem2uman) Learn how to operate SGPEM v2
|
||||
* SGPEM v2 Developer Manual : (sgpem2dman) Learn how to contribute to
|
||||
SGPEM development
|
||||
@end direntry
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@bye
|
|
@ -0,0 +1,788 @@
|
|||
\input texinfo @c -*-texinfo-*-
|
||||
|
||||
@c %**start of header
|
||||
@setfilename sgpem2dman.info
|
||||
@settitle SGPEMv2 Developer Manual
|
||||
@include version.texi
|
||||
@c %**end of header
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@copying
|
||||
This is SGPEMv2 Manual (version @value{VERSION},
|
||||
@value{UPDATED}).
|
||||
|
||||
Copyright @copyright{} 2005 University of Padova, dept. of Pure
|
||||
and Applied Mathematics
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.2
|
||||
or any later version published by the Free Software Foundation;
|
||||
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.
|
||||
@end copying
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@titlepage
|
||||
@title SGPEMv2 Developer Manual
|
||||
@subtitle for version @value{VERSION}, @value{UPDATED}
|
||||
@author Giovanni Giacobbi (@email{ggiacobb@@studenti.math.unipd.it})
|
||||
@author Filippo Paparella (@email{ironpipp@@gmail.com})
|
||||
@author Paolo Santi (@email{psanti@@studenti.math.unipd.it})
|
||||
@author Matteo Settenvini (@email{matteo@@member.fsf.org})
|
||||
@author Marco Trevisan (@email{evenjn@@gmail.com})
|
||||
@author Djina Verbanac (@email{betalgez@@yahoo.com})
|
||||
@author Luca Vezzaro (@email{lvezzaro@@studenti.math.unipd.it})
|
||||
@page
|
||||
@vskip 0pt plus 1filll
|
||||
@insertcopying
|
||||
@end titlepage
|
||||
|
||||
@c Output the table of contents at the beginning.
|
||||
@contents
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@c SGPEM v2 Developer Manual
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@ifnottex
|
||||
@node Top, History, (none), (dir)
|
||||
@top SGPEMv2 Developer Manual
|
||||
|
||||
@insertcopying
|
||||
@end ifnottex
|
||||
|
||||
@menu
|
||||
|
||||
* History:: The history of changes to this document.
|
||||
|
||||
* Directory overview:: How SGPEM sources are organized
|
||||
|
||||
* Coding style:: Here there are the rules you should abid
|
||||
to when working on SGPEM
|
||||
|
||||
* Committing changes:: Some notes on how we keep our
|
||||
versions organized, how to use
|
||||
our repository, and how we would
|
||||
like you to commit patches
|
||||
|
||||
* License:: The full text of the license under which this
|
||||
manual is given to you
|
||||
|
||||
* Concept index:: Complete index
|
||||
|
||||
@end menu
|
||||
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@node History, Directory overview, Top, Top
|
||||
@unnumbered History
|
||||
|
||||
@table @strong
|
||||
|
||||
@item 2005, December 11th @r{--- Matteo Settenvini}
|
||||
Added sources' directory description and repository usage
|
||||
guidelines. Included full FDL license text.
|
||||
|
||||
@item 2005, November 8th @r{--- Matteo Settenvini}
|
||||
First draft of this document
|
||||
|
||||
@end table
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@node Directory overview, Coding style, History, Top
|
||||
@chapter Directory overview
|
||||
@cindex directory layout
|
||||
|
||||
If you need to work on SGPEM sources, you'll probably
|
||||
be interested in understanding how this package directory
|
||||
structure is organized.
|
||||
|
||||
What follows is the tree you'll find after uncompressing
|
||||
the SGPEM tar archive.
|
||||
|
||||
@table @samp
|
||||
|
||||
@item config/
|
||||
Files used by Autotools while configuring
|
||||
and compiling SGPEM.
|
||||
|
||||
@item data/
|
||||
Various data SGPEM will use at runtime, like icons,
|
||||
images, XML DTDs, User Interface (@file{*.ui})
|
||||
definition files, and so on.
|
||||
|
||||
@item doc/
|
||||
Inside this directory you'll find the User and Developer
|
||||
Manuals, like the one you're reading, ready to be compiled.
|
||||
|
||||
@item desktop/
|
||||
The desktop menu entries for FreeDesktop compliant
|
||||
Desktop Environments.
|
||||
|
||||
@item distro/
|
||||
Files used to prepare a package for a specific platform,
|
||||
maybe containing the installer data.
|
||||
|
||||
@item glade/
|
||||
Glade2 source files that can we used to generate various
|
||||
windows for the GUI.
|
||||
|
||||
@item m4/
|
||||
M4 macros used by Autoconf.
|
||||
|
||||
@item po/
|
||||
Here are stored the Gettext PO catalogs. If you are a
|
||||
translator, you should first look here in order to
|
||||
localize SGPEM into your language.
|
||||
|
||||
@item src/
|
||||
The source files of SGPEM.
|
||||
|
||||
@end table
|
||||
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@node Coding style, Committing changes, Directory overview, Top
|
||||
@chapter Coding style
|
||||
@cindex coding style
|
||||
|
||||
In this chapter we explore some self-imposed coding standards
|
||||
we tried to follow when coding SGPEM.
|
||||
If you plan to extend it in any way, you should abid to the
|
||||
guidelines explained thereafter.
|
||||
|
||||
@menu
|
||||
|
||||
* Editors :: Some things you should know about indentation
|
||||
and editors
|
||||
|
||||
* Coding in C++::
|
||||
|
||||
@end menu
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@node Editors, Coding in C++, Coding style, Coding style
|
||||
@section Editors
|
||||
@cindex editors
|
||||
@cindex emacs
|
||||
@cindex mixed mode
|
||||
|
||||
@c this needs rework, of course
|
||||
|
||||
IDEs are a bad choice, since usually they leave your directory
|
||||
dirty, and full of temporary or project files. Please avoid their
|
||||
use if not strictly necessary.
|
||||
|
||||
A good choice for an editor is @acronym{GNU}
|
||||
Emacs, but every other editor supporting mixed mode for
|
||||
indentation and that has Unicode support will do.
|
||||
|
||||
Your files should be in ``UNIX mode''; that is, only a char is used
|
||||
for a newline. On DOS-based systems, usually two chars are employed:
|
||||
the newline char and the carriage return one.
|
||||
Failure to check your text files are correctly saved wastes space
|
||||
and others' patience, so please take care.
|
||||
|
||||
Indentation mixed mode is useful to ensure that your file will be
|
||||
correctly indented wheter another developer on another machine
|
||||
opens it with Emacs, Vim, Notepad, with a 8-spaces indent, with a
|
||||
3-spaces one, and so on.
|
||||
A lot of UNIX editors nowadays use mixed mode.
|
||||
|
||||
@acronym{GNU} Emacs has another nice property: it can automatically indent
|
||||
code in a whole region for you, with @kbd{M-x indent-region}.
|
||||
Moreover, if you can get accustomed to it, you can activate the
|
||||
automatic indentation while in a programming mode, by
|
||||
typing @kbd{C-c C-a}.
|
||||
Experienced programmers find it saves quite a lot of time, but
|
||||
we guess it's just a matter of taste.
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@node Coding in C++, (none), Editors, Coding style
|
||||
@section Coding in C++
|
||||
@cindex c++
|
||||
@cindex coding, style
|
||||
|
||||
SGPEM is mostly written in C++, an Object Oriented language
|
||||
ideated by Bjarne Stroustrup and standardized in 1998 by ISO.
|
||||
Here are explained some guidelines you should keep well in mind
|
||||
if you want to contribute to this project.
|
||||
|
||||
@menu
|
||||
|
||||
* C++ Coding Style::
|
||||
|
||||
* C++ Coding Conventions::
|
||||
|
||||
@end menu
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@node C++ Coding Style, C++ Coding Conventions, Coding in C++, Coding in C++
|
||||
@subsection C++ Coding Style
|
||||
@cindex coding style
|
||||
|
||||
These are some notes on coding style, and things
|
||||
you should keep in mind whenever extending SGPEM
|
||||
source code.
|
||||
Patches to the source that don't uniform to these
|
||||
guidelines are likely to be rejected and need rework.
|
||||
Coding styles are highly subjective and are often the
|
||||
cause of harsh holy wars. Here we try also to give
|
||||
a rationale of these choices, supporting our statements.
|
||||
|
||||
@enumerate
|
||||
@item
|
||||
Left curly braces go on a newline, respect to
|
||||
the statement that comes before them. Right curly
|
||||
braces are to be put into a newline too.
|
||||
It may make you feel uneasy at first, but this
|
||||
behaviour is preferable because it clearly let you
|
||||
identify code blocks.
|
||||
Moreover, it is observed that putting left curly
|
||||
braces on the same line of a statement isn't a rule
|
||||
you always follow: a lot of exceptions are raised by
|
||||
particular situations, like: ``should my brace go on the
|
||||
same line after a class initialization list? and after
|
||||
a @code{for} loop declaration? what happens after
|
||||
namespaces declaration?''
|
||||
So it's best to stick to a well known practice and
|
||||
put it always on a newline.
|
||||
A lot of complex software projects follow this rule
|
||||
because it also increases manutenibility: keep in mind
|
||||
that you aren't writing code for yourself, but for others
|
||||
to read.
|
||||
|
||||
@item
|
||||
The return type for every function goes on a
|
||||
line, while the function name and its parameters
|
||||
go on the following, without any leading space.
|
||||
This makes easier to @command{grep}
|
||||
the source. For example, if you're searching for a
|
||||
declaration of @code{int foo::bar()} inside a large
|
||||
directory, grepping for: @samp{'/^foo::bar/g'} will
|
||||
immediately pop out the correct result, whereas,
|
||||
if you didn't follow this rule, you would have
|
||||
searched for @samp{'/foo::bar/g'}, thus finding
|
||||
@strong{all} recurrences of the function in the code,
|
||||
even function calls.
|
||||
|
||||
@item
|
||||
Use the following example to understand how we want
|
||||
you to space expressions:
|
||||
@example
|
||||
@code{ type var = exp1 OP (exp2 OP fun1(exp3)); }
|
||||
@end example
|
||||
And for parameters, the following spacing is preferable:
|
||||
@example
|
||||
@code{ function(par1, par2 = value, ...)}
|
||||
@end example
|
||||
|
||||
@item
|
||||
Please define pointers like @code{type* var}
|
||||
instead of @code{type *var}.
|
||||
|
||||
@item
|
||||
Labels go indented on the same level of the
|
||||
containing code block. For example:
|
||||
@example
|
||||
@verbatim
|
||||
switch(x) {
|
||||
case 1:
|
||||
// foo
|
||||
case 2:
|
||||
// bar
|
||||
default:
|
||||
// baz
|
||||
}
|
||||
@end verbatim
|
||||
@end example
|
||||
Remember that also @code{public}, @code{protected} and
|
||||
@code{private} are labels.
|
||||
|
||||
@item
|
||||
Put incomplete class declarations before their interface,
|
||||
documenting it. For example:
|
||||
@example
|
||||
@verbatim
|
||||
//! I'm a useless class
|
||||
/** This class is completely useless. */
|
||||
class C;
|
||||
// [...]
|
||||
|
||||
class C {
|
||||
public:
|
||||
// [...]
|
||||
};
|
||||
@end verbatim
|
||||
@end example
|
||||
|
||||
@item
|
||||
All header files of the libs and the engine
|
||||
follow a common model. Try to adhere to it
|
||||
by looking at existing headers. Document them
|
||||
fully, even if it is tedious, using a
|
||||
Doxygen-like syntax. The payback will be
|
||||
high, I assure you.
|
||||
|
||||
@item
|
||||
Class names are
|
||||
composed of capitalized words.
|
||||
Member functions are composed of
|
||||
capitalized words @strong{except} for the very
|
||||
first letter.
|
||||
Member data are lowercase words (sometimes
|
||||
separated by an underscore).
|
||||
Enums members are lowercase and they have
|
||||
a prefix that tells something about their
|
||||
function, e.g., in an enum named @emph{signal},
|
||||
``@code{signal_*;}''.
|
||||
Macro names are written all in capital.
|
||||
|
||||
@item
|
||||
Private member object and function names always
|
||||
begin with an underscore. Public and protected
|
||||
ones don't.
|
||||
|
||||
@item
|
||||
Some (broken?) versions of autotools had problems with extensions
|
||||
other than @samp{.cc} for C++ implementation files (e.g.
|
||||
automake didn't produce correct implicit rules for them).
|
||||
Consequently, in order to avoid problems, we require you
|
||||
to use the following extensions:
|
||||
@itemize
|
||||
|
||||
@item
|
||||
@samp{.cc} : C++ implementation files
|
||||
|
||||
@item
|
||||
@samp{.hh} : C++ header files
|
||||
|
||||
@item
|
||||
@samp{.tcc} : Template implementation files
|
||||
|
||||
@end itemize
|
||||
|
||||
You can also add to the end of your @file{~/.emacs} the line:
|
||||
@example
|
||||
@code{(add-to-list 'auto-mode-alist (cons "\\.tcc\\'" 'c++-mode))}
|
||||
@end example
|
||||
to automatically associate the @samp{.tcc} extension to
|
||||
the @samp{c++-mode}.
|
||||
|
||||
@end enumerate
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@node C++ Coding Conventions, (none), C++ Coding Style, Coding in C++
|
||||
@subsection C++ Coding Conventions
|
||||
@cindex coding conventions
|
||||
|
||||
|
||||
Some common rules you should keep in mind when writing
|
||||
new code:
|
||||
|
||||
@enumerate
|
||||
|
||||
@item
|
||||
Never use @code{std::cout/cerr} if you can do
|
||||
without them.
|
||||
Use @code{printf()} and @code{fprintf()} from
|
||||
@code{cstdio} instead,so that marking strings
|
||||
for @command{gettext} translation will be easier.
|
||||
|
||||
@item
|
||||
Don't use ``@code{using}'' directives into the
|
||||
global space, even in a @samp{.cc}, and neither in other
|
||||
namespaces. If you don't keep this in mind,
|
||||
you're buying to everybody a (big) problem.
|
||||
``@code{using}'' makes sense
|
||||
at the beginning of a function to improve
|
||||
code readability, and you should be specific:
|
||||
@enumerate
|
||||
@item
|
||||
``@code{using namespace std;}'' is bad
|
||||
@item
|
||||
``@code{using std::string;}'' is good
|
||||
@end enumerate
|
||||
|
||||
@item
|
||||
When treating long template names, remember that
|
||||
@code{typedef} (along with @code{typename} as
|
||||
needed) are your best friends, expecially at
|
||||
the beginning of class declarations or function
|
||||
definitions.
|
||||
|
||||
@item
|
||||
``@emph{Syscalls}'' are evil for portability.
|
||||
Thread calls can sometimes escape this rule (since
|
||||
they're quite different from system to system,
|
||||
and @acronym{GNU}/Linux
|
||||
ones are really good), but
|
||||
remember that every UNIX/Win32/Solaris/etc.
|
||||
native call you use means extra-work somewhere
|
||||
in the near future.
|
||||
If a portable toolkit we're using provides the
|
||||
same functionality, it should be preferred to a
|
||||
system call.
|
||||
|
||||
@item
|
||||
Only exportable classes and functions inside
|
||||
a library should be marked with correct
|
||||
visibility attribute (usually a macro we defined
|
||||
as @code{DLL_EXPORT}). All the others are marked with
|
||||
@option{--visibility=hidden} from the compiler, and aren't
|
||||
available outside the @acronym{DSO, Dynamic Shared Object}
|
||||
they live in, so that they don't clutter
|
||||
the @acronym{DSO} namespace.
|
||||
|
||||
@item
|
||||
When you do something, remember to update the
|
||||
@emph{ChangeLog}. This is essential.
|
||||
More on this on @xref{Committing changes}.
|
||||
|
||||
@item
|
||||
Remember macros for inclusion at the beginning of header
|
||||
files, as well in template implementation files.
|
||||
In the latter case, you may want to include the template
|
||||
implementation files in the corresponding header files.
|
||||
An example of a correct inclusion directive is:
|
||||
@example
|
||||
@verbatim
|
||||
#ifndef HELLO_WORLD_HH
|
||||
#define HELLO_WORLD_HH 1
|
||||
|
||||
// interface definitions
|
||||
|
||||
#endif
|
||||
@end verbatim
|
||||
@end example
|
||||
|
||||
@item
|
||||
Please follow this order when declaring a class interface:
|
||||
@enumerate
|
||||
|
||||
@item
|
||||
Incomplete declarations of nested classes and
|
||||
friend functions / classes declarations.
|
||||
|
||||
@item
|
||||
Typedefs
|
||||
|
||||
@item
|
||||
Enums
|
||||
|
||||
@item
|
||||
Non-static member functions
|
||||
|
||||
@item
|
||||
Static member functions
|
||||
|
||||
@item
|
||||
Static constant data members
|
||||
|
||||
@item
|
||||
Variable data members
|
||||
|
||||
@end enumerate
|
||||
Static non-const data members shouldn't exist.
|
||||
Nested classes go declared @strong{outside} their
|
||||
containing class. For example:
|
||||
@example
|
||||
@verbatim
|
||||
class C;
|
||||
|
||||
class C {
|
||||
class D;
|
||||
// ...
|
||||
};
|
||||
|
||||
class C::D {
|
||||
// ...
|
||||
};
|
||||
@end verbatim
|
||||
@end example
|
||||
The order for visibility should be: @code{public}, then
|
||||
@code{protected}, then @code{private}.
|
||||
|
||||
@end enumerate
|
||||
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@node Committing changes, License, Coding style, Top
|
||||
@chapter Committing changes
|
||||
@cindex repository
|
||||
@cindex subversion
|
||||
|
||||
SGPEM sources are held in a repository managed by
|
||||
Subversion. This is not an introduction on how to
|
||||
use this tool. For that, you should refer to its own
|
||||
manual, located at @url{http://svnbook.red-bean.com/}.
|
||||
Rather, it sets some ``best practices'' you ought
|
||||
to follow committing changes to the repository.
|
||||
|
||||
@menu
|
||||
|
||||
* Introduction and goals::
|
||||
|
||||
* Repository layout::
|
||||
|
||||
* Basic svn usage::
|
||||
|
||||
* Gold rules on committing::
|
||||
|
||||
* How to write good log messages::
|
||||
|
||||
* Conflicts resolution::
|
||||
|
||||
@end menu
|
||||
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@node Introduction and goals, Repository layout, Committing changes, Committing changes
|
||||
@section Introduction and goals
|
||||
@cindex repository
|
||||
@cindex subversion
|
||||
|
||||
The Subversion repository, commonly referred to just as ``repository'',
|
||||
is the place where all the material produced within this project will
|
||||
live.
|
||||
|
||||
There is a strong need to maintain an history of development data,
|
||||
even on plain documentation, whether it is a proprietary file format
|
||||
describing an UML chart, or some lovely C source code.
|
||||
|
||||
Mantaining versioned files for everything makes developers more free to cut,
|
||||
modify, hack, and revamp them, with the safety that older versions
|
||||
can always be fetched again.
|
||||
|
||||
This document describes some guidelines for maintaining the
|
||||
repository as clean as possible, by defining some restrictive
|
||||
rules that developers must respect in order to avoid abusing
|
||||
of the customizability this tool offers.
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@node Repository layout, Basic svn usage, Introduction and goals, Committing changes
|
||||
@section Repository layout
|
||||
@cindex repository
|
||||
@cindex directory layout
|
||||
|
||||
The layout you'll find inside the repository will be:
|
||||
|
||||
@table @samp
|
||||
|
||||
@item swe/docs
|
||||
(@emph{subdirectories}: @samp{internals}, @samp{externals},
|
||||
@samp{manuals}, @samp{misc})
|
||||
|
||||
Contains all drafts intended for the developers. This
|
||||
directory doesn't support tagging and branching because drafts
|
||||
has ``eternal'' life. If needs arise, they'll rather need to be
|
||||
renamed appending their version to their filename (-01, -02, etc.).
|
||||
|
||||
@item swe/trunk
|
||||
(@emph{subdirectories}: @samp{doc}, @samp{src}, @dots{})
|
||||
|
||||
This is the main development area where source files are held.
|
||||
Usually, official releases spin off the trunk.
|
||||
For a list of the directories layed out therein, please
|
||||
refer to @ref{Directory overview}.
|
||||
|
||||
@item swe/tags
|
||||
|
||||
It contains copies of the @samp{trunk/} directory. Note that
|
||||
tagging the trunk directory reflects in a double space only
|
||||
for your local working copy, while it is a @math{O(1)}
|
||||
operation for the server. Changes and commits are NOT
|
||||
allowed here. Please note that tagging must be agreeded
|
||||
with project administrator.
|
||||
|
||||
The format of a tag is:
|
||||
@example
|
||||
<@emph{version_number}>
|
||||
@end example
|
||||
|
||||
Example:
|
||||
@example
|
||||
1.0
|
||||
@end example
|
||||
|
||||
@item swe/branches
|
||||
|
||||
This is the same as tags, except that commits are allowed inside the
|
||||
branch. Please refer to common development models to decide what
|
||||
should or should not be done inside a branch. Note that
|
||||
branching isn't something everybody should do: it should be agreed
|
||||
together with the project administrator.
|
||||
|
||||
The format of a branch is:
|
||||
@example
|
||||
<@emph{version_number}>-r<@emph{revision_number}>--<@emph{branch_name}>
|
||||
@end example
|
||||
|
||||
Example:
|
||||
@example
|
||||
1.2-r164--guirestyle
|
||||
@end example
|
||||
|
||||
@end table
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@node Basic svn usage, Gold rules on committing, Repository layout, Committing changes
|
||||
@section Basic svn usage
|
||||
@cindex repository
|
||||
@cindex svn
|
||||
@cindex locking files
|
||||
|
||||
In your daily use of the repository you will mostly need to know a
|
||||
very small subgroup of svn commands. Other ones are usually for fine
|
||||
tuning operations (like setting file binary flags, keyword expansion, managing
|
||||
the repository tree, etc.), which are tasks carried out by the repository
|
||||
administrator.
|
||||
|
||||
Here there's a quick reference about such commands:
|
||||
|
||||
@table @samp
|
||||
|
||||
@item svn checkout @emph{http://svn.thgnet.it/swe/drafts}
|
||||
Downloads a copy of the current @samp{drafts/} directory contents.
|
||||
Checking out the root repository dir (/swe/) may
|
||||
result, in near future, to a @strong{big} download, as
|
||||
branch and tags will be stored inside the root directory.
|
||||
|
||||
@item svn update @r{(}@emph{short form}@r{:} svn up@r{)}
|
||||
Recursively updates the current directory to the
|
||||
latest revision. Use option @option{-r N} to update to a
|
||||
specific revision.
|
||||
|
||||
@item svn status
|
||||
Shows the status of @strong{your} working copy against
|
||||
the repository.
|
||||
|
||||
@item svn diff
|
||||
Shows differences in unified diff format between your working
|
||||
copy and the base version of the current revision selected
|
||||
(usually it means the latest). If you want to compare two different
|
||||
revisions you can add a @option{-r N:M} parameter.
|
||||
|
||||
@item svn lock @emph{filename}
|
||||
Locks a file so that everybody except the lock owner can't commit
|
||||
over it. This is particularly useful for binary files:
|
||||
you should always try to acquire a lock before starting editing.
|
||||
|
||||
@end table
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@node Gold rules on committing, How to write good log messages, Basic svn usage, Committing changes
|
||||
@section Gold rules on committing
|
||||
@cindex committing
|
||||
|
||||
A versioning system, by definition, records everything that goes through it.
|
||||
So it may be a good idea not to commit garbage or make changes that will
|
||||
probably be rejected by the team. The repository mustn't be used as a
|
||||
temporary file storage system (so just don't use it to transfer files from
|
||||
work to home or vice-versa!).
|
||||
|
||||
When you commit something, it should be an acceptable piece of work.
|
||||
Of course, it can happen that later inspection demonstrates
|
||||
it's better to revert some changesets, but that's the purpose of
|
||||
having a centralized versioning system.
|
||||
|
||||
Avoid big commits altogether. A detailed description of your intentions
|
||||
should hit the mailing list @emph{before} even starting to write such a
|
||||
patch. Then, committing your work must happen via
|
||||
@strong{small incremental patches}.
|
||||
|
||||
Also please avoid making structural tree changes (creating,
|
||||
moving, removing, renaming directories) without asking first
|
||||
the repository administrator.
|
||||
|
||||
Everything can be reverted by @command{svn}, but that's not an
|
||||
excuse for sloppiness.
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@node How to write good log messages, Conflicts resolution, Gold rules on committing, Committing changes
|
||||
@section How to write good log messages
|
||||
@cindex log messages
|
||||
|
||||
Be as descriptive as possible, concisely. If your changeset was discussed on
|
||||
the mailing list or at a meeting, make a clear reference to it.
|
||||
|
||||
Please be consistent with the message format. Use a clean english language,
|
||||
employing only abbreviations contained in the glossary document.
|
||||
|
||||
Always prepend a dash (@minus{}) for each changeset description,
|
||||
followed by a space. This will make clear, in case of line wrapping,
|
||||
what is part of the list and what is simply a new line.
|
||||
|
||||
Every sentence must end with a full stop. If a particular description
|
||||
is composed by several sub-descriptions, use a colon (@samp{:}), and
|
||||
use a tab space to indent the inner list.
|
||||
|
||||
You can use only one level of nesting for lists. If you need more,
|
||||
you are probably making an oversized commit.
|
||||
|
||||
An example of the log format is the following:
|
||||
|
||||
@example
|
||||
- Change description 1.
|
||||
- Change description 2:
|
||||
<tab> - Part 1 of change description 2.
|
||||
<tab> - Part 2 of change description 2.
|
||||
- Change description 3. This particular change has a very long message
|
||||
describing this atomic commit.
|
||||
@end example
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@node Conflicts resolution, (none), How to write good log messages, Committing changes
|
||||
@section Conflicts resolution
|
||||
@cindex conflicts
|
||||
@cindex merging
|
||||
|
||||
As in any other concurrent development system, conflicts may happen.
|
||||
this will be demanded to the official @cite{Subversion Book (ch. 3 sect. 5.4)}
|
||||
for an explanation on how to handle them.
|
||||
We will just quote something to keep well in mind, however:
|
||||
|
||||
@quotation
|
||||
In the end, it all comes down to one critical factor: user communication.
|
||||
When users communicate poorly, both syntactic and semantic conflicts
|
||||
increase. No system can force users to communicate perfectly, and no system
|
||||
can detect semantic conflicts. So there's no point in being lulled into a
|
||||
false promise that a locking system will somehow prevent conflicts; in
|
||||
practice, locking seems to inhibit productivity more than anything else.
|
||||
@end quotation
|
||||
@cite{Version Control with Subversion, a.k.a. ``The Subversion Book''}
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@c include license text
|
||||
@node License, Concept index, Committing changes, Top
|
||||
@include fdl.texi
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@node Concept index, (none), License, Top
|
||||
@unnumbered Concept Index
|
||||
|
||||
@printindex cp
|
||||
|
||||
|
||||
@bye
|
|
@ -0,0 +1,237 @@
|
|||
\input texinfo @c -*-texinfo-*-
|
||||
|
||||
@c %**start of header
|
||||
@setfilename sgpem2uman.info
|
||||
@settitle SGPEMv2 User Manual
|
||||
@include version.texi
|
||||
@c %**end of header
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@copying
|
||||
This is SGPEMv2 Manual (version @value{VERSION},
|
||||
@value{UPDATED}).
|
||||
|
||||
Copyright @copyright{} 2005 University of Padova, dept. of Pure
|
||||
and Applied Mathematics
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.2
|
||||
or any later version published by the Free Software Foundation;
|
||||
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.
|
||||
@end copying
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@titlepage
|
||||
@title SGPEMv2 User Manual
|
||||
@subtitle for version @value{VERSION}, @value{UPDATED}
|
||||
@author Giovanni Giacobbi (@email{ggiacobb@@studenti.math.unipd.it})
|
||||
@author Filippo Paparella (@email{ironpipp@@gmail.com})
|
||||
@author Paolo Santi (@email{psanti@@studenti.math.unipd.it})
|
||||
@author Matteo Settenvini (@email{matteo@@member.fsf.org})
|
||||
@author Marco Trevisan (@email{evenjn@@gmail.com})
|
||||
@author Djina Verbanac (@email{betalgez@@yahoo.com})
|
||||
@author Luca Vezzaro (@email{lvezzaro@@studenti.math.unipd.it})
|
||||
@page
|
||||
@vskip 0pt plus 1filll
|
||||
@insertcopying
|
||||
@end titlepage
|
||||
|
||||
@c Output the table of contents at the beginning.
|
||||
@contents
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@c SGPEMv2 User Manual
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@ifnottex
|
||||
@node Top, History, (none), (dir)
|
||||
@top SGPEM v2 User Manual
|
||||
|
||||
@insertcopying
|
||||
@end ifnottex
|
||||
|
||||
@menu
|
||||
|
||||
* History:: The history of changes to this document.
|
||||
|
||||
* What is SGPEM:: Description and objectives of SGPEM v2.
|
||||
|
||||
* Installation:: Here we explain how to install SGPEM v2,
|
||||
as well as providing some advice for
|
||||
believed-to-be useful compilation options.
|
||||
|
||||
* License:: A full copy of the GNU Free Documentation License
|
||||
this manual is licensed into.
|
||||
|
||||
* Concept index:: Complete index.
|
||||
@end menu
|
||||
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@node History, What is SGPEM, Top, Top
|
||||
@unnumbered History
|
||||
|
||||
@table @strong
|
||||
|
||||
@item 2005, December 11th @r{--- Matteo Settenvini}
|
||||
Added full license text.
|
||||
|
||||
@item 2005, November 8th @r{--- Matteo Settenvini}
|
||||
First draft of this document.
|
||||
|
||||
@end table
|
||||
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@node What is SGPEM, Installation, History, Top
|
||||
@chapter What is SGPEM
|
||||
|
||||
@menu
|
||||
* Description and aims::
|
||||
* Features::
|
||||
@end menu
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@node Description and aims, Features, What is SGPEM, What is SGPEM
|
||||
@section Description and aims
|
||||
@cindex SGPEM
|
||||
@cindex description
|
||||
|
||||
SGPEM is an Italian acronym, standing for ``@emph{Simulatore della Gestione dei Processi in un Elaboratore Multiprogrammato}'' (in English,
|
||||
``@emph{Multitasking Computer Process Management Simulator}'').
|
||||
It was initially developed for use inside the Course in Computer Science
|
||||
of the Padova University, Italy.
|
||||
|
||||
SGPEMv2 is a didactic software aiming...
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@node Features, (none), Description and aims, What is SGPEM
|
||||
@section Features
|
||||
@cindex features
|
||||
|
||||
Main features are:
|
||||
|
||||
@itemize
|
||||
@item
|
||||
Graphical display of simulated processes...
|
||||
|
||||
@end itemize
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@node Installation, License, What is SGPEM, Top
|
||||
@chapter Installation
|
||||
@cindex installation
|
||||
|
||||
@menu
|
||||
* Prerequisites:: Programs and libraries needed to
|
||||
compile and run SGPEM
|
||||
|
||||
* Building:: Help for compiling SGPEM on
|
||||
your platform.
|
||||
|
||||
@end menu
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@node Prerequisites, Building, Installation, Installation
|
||||
@section Prerequisites
|
||||
@cindex requirements
|
||||
|
||||
Some software is needed in order to build and install SGPEM on your
|
||||
personal computer.
|
||||
This is the list; if you find it misses something / it lists
|
||||
the wrong version of a program, please let us know!
|
||||
|
||||
@itemize
|
||||
@item
|
||||
@emph{GCC with C++ support}, as well as the other standard
|
||||
GNU tools: make, sed, ld... GCC version >=3.4 is highly
|
||||
recommended. Please don't report compiling-related
|
||||
problems with any previous version.
|
||||
|
||||
@item
|
||||
@emph{libXML2 >= 2.6.15} : we need this to parse saved files.
|
||||
@dots{}
|
||||
@c cairo? gtkmm? and so on...
|
||||
|
||||
@end itemize
|
||||
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@node Building, (none), Prerequisites, Installation
|
||||
@section Building
|
||||
@cindex compiling
|
||||
|
||||
@noindent To ensure a clean build, follow these steps:
|
||||
|
||||
@example
|
||||
@code{cd <this directory>}
|
||||
@code{mkdir =build}
|
||||
@code{cd =build}
|
||||
@code{CXXFLAGS="what you want" ../configure --prefix=/usr/local}
|
||||
@end example
|
||||
@sp 2
|
||||
|
||||
@noindent This will check you have all the needed software installed.
|
||||
|
||||
@noindent Choosing good @env{CXXFLAGS} to optimize your build.
|
||||
For example, on my machine, I would use:
|
||||
@example
|
||||
@code{CXXFLAGS="-O3 -pipe -march=pentium4" ../configure --prefix=/usr/local}
|
||||
@end example
|
||||
@sp 2
|
||||
|
||||
@noindent Being a developer, though, if I had to debug SGPEM, I would type:
|
||||
@example
|
||||
@code{CXXFLAGS="-O0 -g -ggdb -pg" ../configure \}
|
||||
@code{ --prefix=`pwd`/_inst --disable-shared}
|
||||
@end example
|
||||
@sp 2
|
||||
|
||||
@noindent Once succesfully configured Stradivari, just type:
|
||||
@example
|
||||
@command{make}
|
||||
@end example
|
||||
@sp 2
|
||||
|
||||
@noindent And upon a succesful build, you can install it just by:
|
||||
@example
|
||||
@code{su -c "make install"}
|
||||
@end example
|
||||
@sp 2
|
||||
|
||||
@noindent Root password will be required (of course, if you're
|
||||
installing it with a prefix places inside your home directory,
|
||||
you won't need administrative rights, and just ``@samp{make install}''
|
||||
will sufficit).
|
||||
|
||||
See the ``@file{INSTALL}'' file in this folder for an overview of other
|
||||
(less common) autoconf options.
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@c include license text
|
||||
@node License, Concept index, Installation, Top
|
||||
@include fdl.texi
|
||||
|
||||
@c % --------------------------------------------------
|
||||
|
||||
@node Concept index, (none), License, Top
|
||||
@unnumbered Index
|
||||
|
||||
@printindex cp
|
||||
|
||||
@bye
|
||||
|
Loading…
Reference in New Issue