Class::member()
Type Class::member_type_
-the C<type> is a Hungarian notation postfix for $C<Type>$.
+the C<type> is a Hungarian notation postfix for $C<Type>$. See below
=head2 COMMENTS
The source is commented in the DOC++ style. Check out doc++ at
http://www.zib.de/Visual/software/doc++/index.html
- /// short description
+ /**
+ short description.
+ Long class documentation.
+ */
class Class {
- /// short description
- /**
- long description
+ /** short description.
+ long description
*/
Data data_member_;
- /****************/
- /// short memo
+
/**
- long doco of member()
+ short memo. long doco of member()
*/
member();
+
+ /// memo only
+ boring_member();
};
- /**
- Class documentation.
- */
Unfortunately most of the code isn't really documented that good.
/// print *this (and substructures) to debugging log
void print() const
- /// add some data to *this;
- add( .. )
/**
+ protected member. Usually invoked by non-virtual A_virtual_func()
+ */
+ virtual do_A_virtual_func()
+
+ /**add some data to *this.
Presence of these methods usually imply that it is not feasible to this
via a constructor
*/
+ add( .. )
/// replace some data of *this
set( .. )
+=head1 HUNGARIAN NOTATION NAMING CONVENTION
+
+Proposed is a naming convention derived from the so-called I<Hungarian
+Notation>.
+
+=head2 Hungarian
+
+The Hungarian Notation was conceived by
+or at least got its name from,
+the hungarian programmer x.
+It is a naming convention with the aim
+to make code more readable (for fellow programmers)
+and more accessible for programmers
+that are new to a project.
+
+The essence of the Hungarian Notation
+is that every identifier has a part
+which identifies its type
+(for functions this is the result type).
+This is particularly useful in object oriented programming,
+where a particular object implies a specific interface
+(a set of member functions, perhaps some redefined operators),
+and for accounting heap allocated memory pointers and links.
+
+=head2 Advantages
+
+Another fun quote from Microsoft Secrets:
+
+
+ The Hungarian naming convention gives developers the ability
+ to read other people's code relatively easily, with a minmum
+ number of comments in the source code. Jon De Vann estimated
+ that only about 1 percent of all lines in the Excel product
+ code consist of comments, but the code is still very
+ understandable due to the use of Hungarian: "if you look at
+ our source code, you also notice very few comments. Hungarian
+ gives us the ability to go in and read code..."
+
+
+Wow! If you use Hungarian you don't have to document your software!
+Just think of the hours I have wasted documenting while this "silver bullet"
+existed. I feel so stupid and ashamed!
+
+=head2 Disadvantages
+
+=over 5
+
+=item *
+more keystrokes (disk space!)
+
+=item *
+it looks silly C<get_slu_p()>
+
+=item *
+it looks like code from micro suckers
+
+=item *
+(which) might scare away some (otherwise good?)
+progammers, or make you a paria in the free
+software community
+
+=item *
+it has ambiguities
+
+=item *
+not very useful if not used consistently
+
+=item *
+usefullness in I<very large>
+(but how many classes is very large?)
+remains an issue.
+
+=back
+
+
+
+=head2 Proposal
+
+=over 5
+
+=item *
+learn about cut and paste / use emacs or vi
+or lean to type using ten fingers
+
+=item *
+Use emacs dabbrev-expand, with dabbrev-case-fold-search set to nil.
+
+=item *
+use no, or pick less silly, abbrvs.
+
+=item *
+use non-ambiguous postfixes C<identifier_name_type_modifier[_modifier]>
+=back
+
+Macros, C<enum>s and C<const>s are all uppercase,
+with the parts of the names separated by underscores.
+
+=head2 Types
+
+=over 5
+
+=item C<b>
+bool
+
+=item C<bi>
+bit
+
+=item C<ch>
+char
+
+=item C<f>
+float
+
+=item C<i>
+signed integer
+
+=item C<str>
+string class
+
+=item C<sz>
+Zero terminated c string
+
+=item C<u>
+unsigned integer
+
+=back
+
+=head2 User defined types
+
+
+ /** Slur blah. blah.
+ (slur)
+ */
+ class Slur {};
+ Slur* slur_p = new Slur;
+
+=head2 Modifiers
+
+The following types modify the meaning of the prefix.
+These are precede the prefixes:
+
+=over 5
+
+=item C<a>
+array
+
+=item C<arr>
+user built array.
+
+=item C<c>
+const
+
+=item C<l>
+temporary pointer to object (link)
+
+=item C<p>
+pointer to newed object
+
+=item C<r>
+reference
+
+=back
+
+=over 5
+
+=item C<loop_i>
+Variable loop: an integer
+
+=item C<u>
+Temporary variable: an unsigned integer
+
+=item C<test_ch>
+Variable Test: a character
+
+=item C<firstName_str>
+Variable first_name: a String class object
+
+=item C<first_name_ch_a>
+Variable first_name: a C<char> array
+
+=item C<loop_i_p>
+Variable Loop: an C<Int*> that you must delete
+
+=item C<loop_i_l>
+Variable Loop: an C<Int*> that you must not delete
+
+=back
+
+
+
customizable notenames, customizable fontset
=item *
-multiple staffs in one score
+Multiple staffs in one score. Each staff can have a different meters.
=item *
multiple stafftypes (melodic, rhythmic) [broken from pl28 on]
=item *
multiple voices within one staff; beams optionally shared
-between voices.
+between voices. (well, more than 2 voices won't look pretty)
=item *
multiple scores within one input file. Each score is output to
a different file.
=item *
-clef changes, meter changes, cadenza-mode, declaring markings
-in the music, repeat bars
+clef changes, meter changes, cadenza-mode, key changes, repeat bars
=back
used interactively. LilyPond writes output to a file. It will not be
extended to play music, or to recognize music.
-We're thinking about adding MIDI output, though
+It will output MIDI, though (at some stage)
=item *
LilyPond is intended to run on Unix platforms, but it should
=back
-
-
=head1 OPTIONS
=over 5
=item B<-d,--debug>,
-debugging. LilyPond will read the file F<.dstreamrc>, which tells for what functions to produce copious debugging output.
+Turn debugging info. LilyPond will read the file F<.dstreamrc>, which
+tells for what functions and classes may produce copious debugging
+output.
=item B<-w,--warranty>,
Show a summary of usage
-=item B<--init, -i>
+=item B<-i,--init=>F<FILE>
-set init file (default: symbol.ini)
+set init file (default: F<symbol.ini>)
=item B<--include, -I>
add to file search path.
=over 5
=item *
- Unix. Any decent Linux distribution is fine. LilyPond is known to run
-on Linux, AIX, Digital Unix and Solaris
+Unix. LilyPond is known to run on Linux, AIX, Digital Unix and
+Solaris (if you have the Cygnus WIN32 port of the GNU utils, it will
+even work in Lose NT/95)
=item *
-GNU C++ v2.7 or better, with libg++. Version 2.7.2 or better recommended.
+GNU C++ v2.7 or better, with libg++ installed. Version 2.7.2
+or better recommended. I doubt if it will compile with AT&T CC.
=item *
GNU make.
flex (2.5.1 or better)
=item *
-Bison or YACC.
+Bison.
=item *
The "Flower" library, which should be available from the same
=over 5
+=item *
+a fast computer (well; full page of music typically takes 1
+minute on my 486/66, using the DEBUG compile)
+
=item *
TeX
This is what the output looks like over here:
- hw:~/musix/spacer$ lilypond input/maartje.ly
- LilyPond 0.0.27/FlowerLib 1.0.23. Compile: Feb 5 1997, 00:28:13 (g++ 2.7.2)
- Parsing ... [./init//symbol.ini[./init/dutch.ini][./init/script.ini][./init/table_sixteen.ini]][./input/maartje.ly]
- Processing music ... Preprocessing ... Calculating ... Postprocessing ...
+ LilyPond 0.0.pre32-3/FlowerLib 1.0.27. Compile: Feb 18 1997, 11:21:57 (g++ 2.7.2)
+ Parsing ... [./init//symbol.ini[./init//dutch.ini][./init//script.ini][./init//table_sixteen.ini]][./input/wohltemperirt.ly]
+ Setting up music ...Processing music ............
+ Preprocessing ...
+ Calculating column positions ... [3][6][9]
+ Postprocessing ...
+ warning: slope_index(): beam steeper than 0.5 (-0.555556)
+ warning: slope_index(): beam steeper than 0.5 (-0.588346)
+ warning: slope_index(): beam steeper than 0.5 (-0.523166)
+ warning: slope_index(): beam steeper than 0.5 (0.571915)
+ warning: slope_index(): beam steeper than 0.5 (-0.555556)
+ warning: slope_index(): beam steeper than 0.5 (-0.588346)
+ warning: slope_index(): beam steeper than 0.5 (-0.523166)
+ warning: slope_index(): beam steeper than 0.5 (0.571915)
output to lelie.out...
hw:~/musix/spacer$ tex test
=head1 REMARKS
LilyPond has no connection with the music package RoseGarden, other
-than the names being similar.
+than the names being similar :-)
=head1 HISTORY
(most) of the checking is done B<after> parsing (some checks even are
done after the break calc!); I'm sorry.
-[outdated]
-
-The parser's job is to construct appropriate objects. It will B<only>
-detect parse errors.
-
- can't find slur to end
-
-Eg. with:
-
- {d g ( } ) g8
-
-The {} part generates two one-note C<Voice>s, the C<g8> another, which
-is translated to start right after the chord. Slurs are contained
-within voices. LilyPond can't find a slur which started in this
-C<g8>'s voice. (what should C<{ d( g ( } )g8 )g8 }> look like? Use
-
- { \music { d } \music { g()g8 } }
-
-
+[yep.. has to be written..]
--- /dev/null
+=head1 NAME
+
+LilyPond -- the Webpage
+
+=head1 DESCRIPTION
+
+Excuse me for this poor page. I don't really have time for doing this..
+
+[and yes, i write webpages in POD :-]
+
+=head1 DOCUMENTATION
+
+=item *
+<a href=README.html
+>
+README
+</a
+>
+
+=item *
+<a href=lilygut.html
+>
+internal structures.
+</a
+>
+
+=item *
+<a href=lilyinput.html
+>
+notes on the input format
+</a
+>
+
+=item *
+<a href=faq.html
+>
+FAQ
+</a
+>
+
+=item *
+<a href=error.html
+>
+errors
+</a
+>
+
+=item *
+<a href=lelie_logo.png
+>
+The lilypond logo (in PNG format)
+</a
+>
+
+
+=item *
+<a href=wohltemperirt.ly
+>
+An example inputfile: from Bach's WTK: c-minor fugue
+</a
+>
+
+=item *
+<a href=wohltemperirt.gif
+>
+A Gif file of the example
+</a
+>
+
+=item *
+<a href=wohltemperirt.ps
+>
+PS output
+</a
+>
+
this stuff comes from e-mail I wrote, some from e-mail others wrote,
some are large comments taken away from the headers
+You should use doc++ to take a peek at the sources.
+
+[have to do more doco; see TODO]
+
=head1 OVERVIEW
LilyPond is a "5-pass" system:
=item *
Staff wide, contains
Local_key_register
+ Bar_register
+ Key_register
+ Meter_register
+ Clef_register
=item *
Voice group, contains
=item 1
-=head1 COMMANDS
-
-
-This table decribes the proper order for the different commands:
-
-
-=head2 interpret
-
- which priority
- ========================
-
- key 200
- clef 190
- meter 180
- bar 170
-
-=head2 typeset
-
- which priority
- ========================
-
- bar 100
- clef 90
- currentclef 80
- key 70
- currentkey 60
- meter 40
-
-
-
=head1 BREAKING
[Source files: F<command.hh>, F<scommands.cc>]
minimum distance to other columns, to prevent symbols from running
into symbols of other columns.)
-=head1 POINTERS
-
-This describes the ownership of certain classes in LilyPond. +
-signifies a "list of". (This is not complete)
-
- Score:
- Paperdef
- Staff+
- Score_commands
- Score_columns+
- PScore
-
- Staff:
- Voice
- Staff_column+
- Command+
-
-
- Voice:
- Voice_element
-
- Voice_element:
- Request+
-
-
- PScore:
- PStaff+
- PCol+
- Idealspacing+
- Item+
- Spanner+
- Spanner+ (broken)
-
=head1 SEE ALSO
=head2 References
universiteit Rotterdam, 1991. (``An automated system for printing
music'' Master's Thesis Management and Computer Science.)
-C. Roemer, The Art of Music Copying. Roerick music co., Sherman Oaks (CA), 1973.
+C. Roemer, The Art of Music Copying. Roerick music co., Sherman Oaks
+(CA), 1973.
Rosecrans, Glen. Music Notation Primer. New York: Passantino, 1979.
=head1 DESCRIPTION
-This page documents the the LilyPond input format, mudela.
+This page globally documents the the LilyPond input format, mudela.
+To get a better impression, please study some examples.
=head2 Overview
+pl 32
+ - multiple meters, see rhythm.ly
+
+
+pl 32-2
+ - skip syntax/Skip_req
+ - command carnage
+ - score_wide_music: commands in staff now override commands in score.
+Internal:
+ - Key_register
+ - Bar_register
+ - Meter_register
+ - meters now kept in baseclass Staff_walker
+ - Score_walker (to ease MIDI output)
+Doc:
+ - Hungarian doco added to CodingStyle
+
+pl 32-1
+ - music processing speedup
+ - website added to doco
+ - clef must *inside* music
+ - fixed spurious "beam too narrow" messages.
+Internal
+ - merge musical / non-musical staff_column
+ - musical/ non-musical requests
+ - Clef_register
+ - split up request.hh, Musical_req vs. Nonmusical_req
+
pl 31
Examples
+
+before 0.1
+
+ * martien.ly, standchen.ly
+
+ * pushgroup, popgroup.
+
+ * basic dynamics
+
+ * triplet notation
+
+ * midi output
+
+ * decent TeX page layout
+
+ * < .. > vs. { .. }
+
This is an assorted collection of stuff that will be done, might be
done, or is an idea that I want to think about
BUGS
- * first clef isn't printed
-
* key undo
- * key print if
+ * key print if clef change.
+
+ * $cis ( | ) cis$
SEVERELY LACKING:
* rest name configurable
+ * '*' vs. '/'
+
SMALLISH PROJECTS
+ * bar numbers
+
* read from mmap directly: study yy_scan_buffer
- * binsearch for notenames
+ * binsearch/hash for notenames
* stafftypes: voice names/ instrument names.
* fix linking: `Warning: size of symbol'
-BIGGISH PROJECT
+ * collision Request_register.
- * merge musical & non-musical column. Scrap Commands in favour
- of Requests, and do multiparallel meters
+ * LilyPond .rpm and .deb
DOC
* a decent webpage
+ * a test suite
+
FUTURE
- * warning: beam(): Beam too narrow: beam gen not per stem
+ * Register_container baseclass
- * put scripts on barcommands
+ * put scripts on bars
* glissando
* Implement all requests
- * merge key{item} & localkey{item}
+ * merge key{item} & localkey{item}?
* QLP for beams?
* eentje/tweetje
+ * piano staff
+
+ * abbreviations a4*8
+
IDEAS
* enter Requests directly
* merge Atom and Symbol?
- * merge Command/Input_command.
-
* merge common code of Item, Atom/Molecule
* Spacing_request for manually adjusting spacing
* PostScript output (esp. Beams, Slurs, etc)
- * caching breakpoints\r
+ * caching breakpoints
+
+ * use exceptions?
\ No newline at end of file
PREFIX=${PREFIX:-.}
echo using PREFIX=$PREFIX
-NEEDFLOWERVER=1.0.26
+NEEDFLOWERVER=1.0.27
flowertar=flower-$NEEDFLOWERVER
here=`pwd`
cd ..
echo '#define LIBDIR "'$PREFIX'/"'> hdr/config.hh
touch Site.make
make -f Initial.make
+
projects / lilypond.git / commitdiff