GNOME Bugzilla – Bug 587156
Convert functions to new function format.
Last modified: 2009-08-17 16:46:57 UTC
We had a new function format for years. We really should move there (and de-facto) get rid of the old one.
*** Bug 122090 has been marked as a duplicate of this bug. ***
*** Bug 134089 has been marked as a duplicate of this bug. ***
Let's see which ones have been done already: fn-r fn-stats fn-tsa and partially: fn-info (1) fn-logical (1) fn-lookup (2) fn-math (15) and not at-all: derivatives (why isn't this called fn-derivatives?) fn-complex fn-database fn-date fn-eng fn-erlang fn-financial fn-random fn-string gda numtheory perl-loader python-loader sample_datasource func-builtin
func-builtin is partial. If you start this, just assume the "=FOO(42)" example code already works as discussed. I'm swamped with configuration code right now.
func-builtin and fn-erlang are done (they were small ones)
numtheory is done
fn_math is done. This leaves: fn-info (partially) fn-logical (partially) fn-lookup (partially) derivatives fn-complex fn-database fn-date fn-eng fn-financial fn-random fn-string gda perl-loader python-loader sample_datasource
sample_datasource done
fn-logical done.
fn-complex is done
fn-eng is done. This leaves: fn-info (partially) fn-lookup (partially) derivatives fn-database fn-date fn-financial fn-random fn-string gda perl-loader python-loader I will be doing fn-random next.
fn-random is done
fn-string is done This leaves: fn-info (partially) fn-lookup (partially) derivatives fn-database fn-date fn-financial gda perl-loader python-loader
The perl loader doesn't really contain any translatable function description (other than the template) but uses GNM_FUNC_HELP_OLD to load external descriptions. Changing that is not part of this bug. The same applies to python-loader. So we are really left with fn-info (partially) fn-lookup (partially) derivatives fn-database fn-date fn-financial gda
gda is done
I'll do fn-date.
I'll do fn-info.
fn-date partially done. Some of the strings function examples need to be marked for translation, or alternatively, changed to not use English word in strings. { GNM_FUNC_HELP_EXAMPLES, "=EXACT(\"key\",\"key\")" }, { GNM_FUNC_HELP_EXAMPLES, "=EXACT(\"key\",\"Key\")" }, { GNM_FUNC_HELP_EXAMPLES, "=UPPER(\"cancelled\")" }, { GNM_FUNC_HELP_EXAMPLES, "=REPLACE(\"testing\",2,3,\"*****\")" }, { GNM_FUNC_HELP_EXAMPLES, "=T(\"text\")" }, { GNM_FUNC_HELP_EXAMPLES, "=SUBSTITUTE(\"testing with this test\",\"test\",\"wait\")" }, { GNM_FUNC_HELP_EXAMPLES, "=SUBSTITUTE(\"testing with this test\",\"test\",\"wait\",1)" }, { GNM_FUNC_HELP_EXAMPLES, "=SEARCH(\"c\",\"Cancel\")" }, { GNM_FUNC_HELP_EXAMPLES, "=SEARCH(\"c\",\"Cancel\",2)" }, { GNM_FUNC_HELP_EXAMPLES, "=SEARCH(\"c*c\",\"Cancel\")" }, { GNM_FUNC_HELP_EXAMPLES, "=SEARCH(\"c*c\",\"Cancel\",2)" },
Translation is probably a bad idea (since we would need to add comments to make sure the translators understand that the words are not important but their structure). I'll try to think about some generic terms, for example "Cancún" instead of "Cancel".
fn-info is done. I have also changed the examples in fn-string not to need translation. We are left with: fn-lookup (partially) derivatives fn-database fn-date (partially) fn-financial
We need consistency on whether to end in a period for _NAME and _ARG.
Since they are not sentences I tried to be consistent in _not_ using a period.
I'll try fn-database next.
fn-database is done.
If we do not end in periods, what should we do with stuff like this from fn-r? { GNM_FUNC_HELP_ARG, F_("give_log:if true, log of the result will be returned instead. This is useful if the result would otherwise underflow to 0. Defaults to false.") },
I have thought of GNM_FUNC_HELP_ARG as a _brief_ description: { GNM_FUNC_HELP_ARG, F_("give_log:if true, log of the result will be returned")} and any "usefulness" comment would be stated in the _DESCRIPTION or in a _NOTE Even if we want to end _ARG with a period, I think we should not clutter that description with "usefulness", since we may want to use that argument description as a tooltip in the formula guru.
Uping to BLOCKER. We need this resolved before release. (Where "resolved" means everything converted and made somewhat consistent. The translators would not like us to keep changing things.) I have committed further work on fn-date.
Please make a call on the consistency (for example with respect to periods.)
I have been dropping periods on NAME and ARG. DESCRIPTIONs have periods.
fn-date almost done. I have defined GNM_DATE_BASIS_HELP for use in functions that have calendar basis. It may not be the best description possible, but the hope is that we will have to fix it only in one place.
fn-date done.
fn-r should be ok now.
I have started work on fn-financial.
We are left with: fn-lookup (partially) derivatives (Andreas) fn-financial (Morten)
derivatives are done (I hope I didn't introduce any errors). We are lef with fn-lookup (partially) fn-financial (Morten)
fn-lookup is done, so only fn-financial remains
I'm on it! Really.
I would think of fn-financial as the worst one to do (and the second largest one too!)
32 more to go... I'll be done in a week -- or take up residence in the insane asylum.
Looks like the perl and python interfaces need some kind of attention too. # find . -name '*.[chy]' -print | xargs grep -c HELP_OLD | grep -v ':0' ./plugins/fn-financial/functions.c:25 ./plugins/perl-loader/perl-loader.c:1 ./plugins/python-loader/python-loader.c:1 ./src/func.h:1 ./src/func.c:4 ./src/dialogs/dialog-function-select.c:1
./plugins/perl-loader/perl-loader.c:1 ./plugins/python-loader/python-loader.c:1 in both case the code constructs an old-style descriptions from a description given externally for puthon or perl functions.
fn-financial is done. find . -name '*.[chy]' -print | xargs grep -c HELP_OLD | grep -v ':0' ./plugins/perl-loader/perl-loader.c:1 ./plugins/python-loader/python-loader.c:1 ./src/dialogs/dialog-function-select.c:1 ./src/func.h:1 ./src/func.c:4 We now need to get rid of the above and the old argument list.
And we need to proof read: imcsch: Invalid NAME record bessely: Invalid NAME record erfc: Invalid NAME record oct2dec: Invalid NAME record amorlinc: Invalid NAME record ddb: Invalid NAME record error.type: Invalid NAME record abs: Invalid NAME record coth: Invalid NAME record csch: Invalid NAME record degrees: Invalid NAME record round: Invalid NAME record sech: Invalid NAME record sinh: Invalid NAME record tanh: Invalid NAME record
hex2dec: Help for 2 args, but takes 1-1 duration: Help for 7 args, but takes 5-6 euroconvert: Help for 4 args, but takes 3-3 mduration: Help for 7 args, but takes 5-6 opt_2_asset_correlation: Help for 11 args, but takes 12-12 opt_bs_carrycost: Help for 7 args, but takes 7-8 opt_bs_delta: Help for 7 args, but takes 7-8 opt_bs_rho: Help for 7 args, but takes 7-8 opt_bs_theta: Help for 7 args, but takes 7-8 opt_complex_chooser: Help for 10 args, but takes 9-9 countblank: Help for 0 args, but takes 1-1 asin: Help for 0 args, but takes 1-1 randnegbinom: Help for 4 args, but takes 2-2 left: Help for 1 args, but takes 1-2 leftb: Help for 1 args, but takes 1-2 midb: Help for 2 args, but takes 3-3 right: Help for 1 args, but takes 1-2 rightb: Help for 1 args, but takes 1-2
I am not sure how we can (and if we even want to) get rid of ./plugins/perl-loader/perl-loader.c:1 ./plugins/python-loader/python-loader.c:1 ./src/dialogs/dialog-function-select.c:1 is just: else if (func->help[0].type == GNM_FUNC_HELP_OLD) describe_old_style (description, func); else describe_new_style (description, func, state->sheet); and so is trivial to fix but can't be done until GNM_FUNC_HELP_OLD has really disappeared. ./src/func.h:1 contains just the enumeration definition ./src/func.c:4 contains varies places that just handle this enumeration constant. So all of these changes depend on fixing ./plugins/perl-loader/perl-loader.c:1 ./plugins/python-loader/python-loader.c:1 however we want to do that!?
These are interesting: opt_bs_carrycost: Help for 7 args, but takes 7-8 opt_bs_delta: Help for 7 args, but takes 7-8 opt_bs_rho: Help for 7 args, but takes 7-8 opt_bs_theta: Help for 7 args, but takes 7-8 opt_complex_chooser: Help for 10 args, but takes 9-9 The new docs match the old ones (which apparently did not match the defined number of variables...)
I killed all references to GNM_FUNC_HELP_OLD. Eventually, someone will need to resurrect help for perl/python.
I think I fixed: hex2dec: Help for 2 args, but takes 1-1 opt_2_asset_correlation: Help for 11 args, but takes 12-12 asin: Help for 0 args, but takes 1-1 randnegbinom: Help for 4 args, but takes 2-2 left: Help for 1 args, but takes 1-2 leftb: Help for 1 args, but takes 1-2 midb: Help for 2 args, but takes 3-3 right: Help for 1 args, but takes 1-2 rightb: Help for 1 args, but takes 1-2
hmm, in fn-financial the name records seem to say ...:calculate ... for example { GNM_FUNC_HELP_NAME, F_("TBILLPRICE:calculate price of a treasury bill")}, elsewhere we didn't start with the verb "calculate" but just said what was calculated: { GNM_FUNC_HELP_NAME, F_("TBILLPRICE:price of a treasury bill")},
I think I fixed imcsch: Invalid NAME record bessely: Invalid NAME record erfc: Invalid NAME record oct2dec: Invalid NAME record amorlinc: Invalid NAME record ddb: Invalid NAME record error.type: Invalid NAME record abs: Invalid NAME record coth: Invalid NAME record csch: Invalid NAME record degrees: Invalid NAME record round: Invalid NAME record sech: Invalid NAME record sinh: Invalid NAME record tanh: Invalid NAME record
Only comment #49 remains.
we also need to remove the old argument names.
and of course we first have to change the formula guru to use the new ones!
I was wrong: the function selector uses function_def_get_arg_name.
function_def_get_arg_name has been rewritten to not use the arg_names field but the ARG record.
I have removed all the old argument names and the argument_names field in GnmFuncDescriptor. We still need to remove the corresponding field from GnmFunc.
No longer a blocker.
The unused arg_names field in GnmFunc has been changed into a ptr array in preparation for providing tooltip information when entering functions. In the process I also fixed a crasher when theformula guru was invoked on a cell containing an undefined function. This is now fixed I believe.