1) Increase MAX_PERSONALITES from 16 to 64
Only components that actually use personality are affected.
2) With a prior commit, names= storage was converted to
RTAPI_MP_STRING and the number of names= realtime comps is
no longer limited by halcompile (similar to count= usage)
3) Add doc notes for personality assignment in two special
cases:
a) more instances than specified personalities
(a personality of 0 is assigned for these instances)
b) more personalities then MAX_PERSONALITIES
(personalities are indexed modulo the MAX_PERSONALITIES)
A message is printed for this case now.
Future: Additional memory limiting compile-time settings may
require adjustment when using many components with
personality.
Users using twopass processing request increased number of
named component instances (typically for simple logic elements
like and2,or2,...). This commit removes the maximum
limit of 16 for names= items for realtime components.
Notes:
1) For realtime components (loadrt), the maxium number of
names= items is not limited by halcompile.
2) For userspace components (loadusr), the maximum number
of names= remains fixed at: MAX_USERSPACE_NAMES=16
3) The maxium number of personalities is by default:
MAX_PERSONALITIES=16
4) A command line option can set the maximum number of
personalities: -P|--personalities
5) Behavior for count= directives is unchanged.
6) Current MAX_CMD_LENGTH=1024 in src/hal/halcmd.h may
need increasing if using many very long names= names.
7) For normal usage, all names= items (comma-separated)
must (still) be on a single loadrt line. Using twopass
processing allows multiple loadrt lines for the same
component type.
8) Formerly, a loadrt directive that specified no count= parameter
and an empty names= parameter resulted in an error and no
component was loaded. With this commit, such a directive
loads a single instance (like and2.0)
Updated tests/:
a) module-loading/or2/17-names ---- remove, no longer applicable
b) module-loading/or2/0-names ---- adapt per Note 8 above
c) module-loading/pid/17-names ---- no change (pid.c hardcoded for 16)
d) module-loading/siggen/17-names - no change (siggen.c hardcoded for 16)
e) halcompile/personalities_mod --- new tests for personalites that are
modulo the compiled-in personalities
using the --personalities= option
The --names option alters the default limit (16) of
'names' instances.
Users request increased quantity of 'names' items when
using many components with twopass processing.
Example usage:
$ halcompile --names=20 --install ...
Note: current default 'names' limit is set in halcompile.g as
MAX_NAMES = 16
as an environmental variable.
Users request increased quantity of names= items when
using many components with twopass processing.
Example usage:
$ HALCOMPILE_MAX_NAMES=20 halcompile ...
Note: current default names= limit is set in halcompile.g as
MAX_NAMES_DEFAULT = 16
groff treats '-' (the character you get when you hit the "minus" key on
the keyboard) as "hyphen", not as "minus". Thus it renders incorrectly
in some locales, and line-wraps strangely.
groff treats the two-character sequence "\-" as "minus", and the
four-character sequence "\(hy" as "hyphen".
Details here: https://lists.debian.org/debian-devel/2003/03/msg01481.html
This commit replaces every instance of "-" in our manpages where the
meaning is "minus" with "\-", so it works right.
This fixes many lintian warnings.
If you write to 59 Temple Place you're unlikely to get a response.
Let's realign the address with a more up-to-date one from [1].
[1] https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt
This is purely a cosmetic change, doesn't affect the meaning of the
license. Done to make rpmlint happy.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
comp is part of MH ("compose"), and is also a hal component ("Two input
comparator with hysteresis"), so calling our compiler "comp" causes
trouble, in particular when the shell helpfully suggests you install mh.
