id summary reporter owner description type status priority milestone component resolution keywords cc workpackage 569 revise embedded C handling in sasmodels pkienzle "Remove the Iq=""""""... function body ..."""""" option from sasmodels. This makes for cleaner code since we don't have to test whether Iq exists, and if so, whether it is a string or a callable. Those who can program in C are surprised by the missing function declaration. Those who don't know C are going to be surprised that the tutorials for writing C functions include the function definition, but they don't have to. Instead use c_include=[""list"", ""of"", ""sources""] and optional c_source=""""""extra source after the included sources"""""". Because c_source contains top-level C code rather than just the function body, this means we can define helper functions in single file model files, which we otherwise cannot do in the current system. A custom model {{{ def form_volume(...): ... def Iq(q, ...): ... def Iqxy(qx, qy, ...): ... }}} becomes {{{ c_source = """""" static double form_volume(...) { ...; } static double Iq(double q, ...) { ...; } static double Iqxy(double qx, double qy, ...) { ...; } """""" }}} This is a reasonably natural transformation for someone who knows both C and python. If the C source is later moved into model.c (so that you can edit it with C syntax highlighting), this becomes {{{ c_include=[""model.c""] }}} The main advantage of the existing scheme, which is that the parameters in the function definition are automatically generated for the C code in the correct order from the parameter table, is not a big advantage in sasview since the New Model dialog creates the python definitions with the correct parameters already, and that can be easily edited." defect closed minor SasView 4.2.0 SasView fixed SasView Bug Fixing