commit 5e4c6b3ad2a4eb00116406c39be648773d20e69c Author: johnny Date: Wed Dec 21 12:14:43 2005 +0000 - Removed other unused logotypes - Updated votazioni.txt git-svn-id: svn://svn.gna.org/svn/sgpemv2/trunk@121 3ecf2c5c-341e-0410-92b4-d18e462d057c diff --git a/doc/fdl.texi b/doc/fdl.texi new file mode 100644 index 0000000..d044d3c --- /dev/null +++ b/doc/fdl.texi @@ -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: + diff --git a/doc/sgpem2.texi b/doc/sgpem2.texi new file mode 100644 index 0000000..39927dc --- /dev/null +++ b/doc/sgpem2.texi @@ -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 diff --git a/doc/sgpem2dman.texi b/doc/sgpem2dman.texi new file mode 100644 index 0000000..37070bc --- /dev/null +++ b/doc/sgpem2dman.texi @@ -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: + - Part 1 of change description 2. + - 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 diff --git a/doc/sgpem2uman.texi b/doc/sgpem2uman.texi new file mode 100644 index 0000000..24e6f06 --- /dev/null +++ b/doc/sgpem2uman.texi @@ -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 } +@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 +