Unconvenient because typing strings (with escaped double quotes, etc.) at the command prompt looked tedious however, considering that this function provides a very direct string→function conversion, the perspective is different. It was once thought to be an "unconvenient but shorthanded way of defining online functions". Operating on functions, or producing functions:ĭeff: stores function text defined in a string or in a string vector into a function variable, of any of the three sorts. It is thus a last resort way to access the bytecode function data. Save: dumps stack objects in a binary file, probably without any data translation.
Genlib: also loops on all *.sci files in a directory, in order to ceate a library object.
Getd: is based on calling exec in a loop for all files of a given directory. This is the most robust function (less odd bugs reported) These are:Įxec: within its general purpose of loading, parsing and executing scilab code, it can be seen as a function which gets function text from a file, and stores it as plain compiled function ( type 13, no option of profiling). There are few Scilab functions providing some degree of access to the function types, and the possibility to manipulate them. Besides that, profilable functions are compatible with breakpointing (the time spent waiting for user input at the breakpoint is even *not* cumulated in the timing, correctly) the impact of making a function profilable on the performance seems at all negligible. I figure out that one of such words is for storing a cumulative call count, while the second for storing the cumulative time spent. Both breakpointing and profiling operate with such a granularity.įunctions compiled for profiling apparently differ from those "just compiled", in that two extra words are added per function line (this is roughly deducible from the function size reported by who).
#Time scilab code#
In all cases, the function body seems to be organized in elementary chunks corresponding to individual code lines. Historically, once upon a time function variables were stripped of the comment text in the function definition now comments are preserved and stored along. Some of this information can be conjectured from help save_format, as it is likely that, for economy, the binary scilab files are essentially a dump of the stack structures. The basis for the storage seems to be a header, detailing function type, input and output arguments and size, and a function body stored as pseudocode ( type 13). There are two sorts of functions: compiled ( type 13) and compiled with provisions for profiling ( type 13 as well). What follows are a few personal deductions, for reference. Nevertheless, a better understanding of the works of the parser, and its way of storing and perusing code data, would be beneficial for any attempt of designing or improving modern Scilab code tools - like a lexer, a profiler, a debugger, a cross-compiler, a code differentiator, and so on. It is not clear to me whether this reflects an unstated intention of keeping the innermost proprietary details of scilab deliberately cryptic, or is just a result of the development history of Scilab. There is no published description, neither of the parsing of the function text which produces the function pseudocode nor of the storage conventions and implications. Apparently, functions are generated from parsing scilab textual code by a process called " compilation", which seems rather to be a translation in a condensed, tokenized internal representation (called improperly pseudocode). Scilab function variables: representation, manipulation.įunctions in Scilab are stored as variables in the stack.
0 kommentar(er)
