Maintainers of win32 DLLs can opt to provide libraries with
'decorated' function names (Google "stdcall name decoration"). To
pull a function pointer out of one of these DLLs, you have to pass a
decorated name to getProcAddress. This is painful for the authors
of NIM DLL wrappers - they have to pass manually-decorated strings
to "importc", but only on win32.
This commit adds auto-decoration to nimGetProcAddress. This function
will probe the DLL for the undecorated name, and if that fails, it
will automatically add decoration and try again. That way, the author
of the wrapper doesn't have to deal with it.
Set operations used "1<<n" style shifts, which led to undefined
behavior if the signed shift overflowed. Similarly, the right-hand
side of the operator sometimes used a mix of signed and unsigned
integers that were combined with "&". This patch attempts to provide
a consistent implementation that uses unsigned integers everywhere.
and add new functionality
- skewness & kurtosis (3rd and 4th stat moments)
- addition ops for RunningStat
- RunningRegress object
- slope, intercept and correlation regression procs
- addition ops for RunningRegress
Rather than issuing echo "cmd..." then cmd... itself, we enable shell trace
facility via set -x, which is POSIX shell standard command and is compatible
with all UNIX shells.
This effectively cuts build.sh size twice, since we don't need to double stuff
there, also making it human readable.
We are also setting PS4 (trace prefix) to none, instead final echo "SUCCESS",
we issue : SUCCESS command which outputs its contents in trace.
Previously it was not possible to use template arguments in template body as
the symbols were not resolved correctly leading to Error: undeclared
identifier: 'XX', eg.:
template defaultOf[T](t: T): expr = (var d: T; d)
echo defaultOf(1) #<- invalid identifier, but should output 0
The problem comes from the fact that macroOrTmpl[...] is transformed by
semSubscript which is trying to evaluate macroOrTmpl identifier in place. This
is okay for non-generic macros or templates, but wrong for generic ones, that
do not have a chance to receive their generic arguments explicitly specified in
brackets.
Solution:
1. macroOrTmpl[...] where macroOrTmpl is non-generic macro or template, then
macroOrTmpl is evaluated before applying brackets. (as before)
2. macroOrTmpl[...] where macroOrTmpl is generic macro or template, then if:
a. It comes from macroOrTmpl[...](...) call expr (efInCall), then macroOrTmpl
is turned into a symbol (efNoEvaluate) rather than evaluating it in place,
then whole bracket expr is returned to semIndirectOp which transforms it
to proper generic macro or template call with explicit generic arguments.
b. macroOrTmpl[...] does not come from call expr, as above macroOrTmpl is
transformed to symbol, then it is transformed into proper generic macro or
template call with explicit generic arguments and no normal arguments.
