Reflection/Get source: Difference between revisions
→{{header|Phix}}
(Add Factor example) |
|||
Line 222:
SETTING::src/core/Dateish.pm
</pre>
=={{header|Phix}}==
There are at least two separate methods for achieving this.
===From Edita===
When using the Edita editor as shipped with Phix, pressing F1 on a call shows a pop-up with the definition and an option to jump to that file/source.
However that only works for routines, not variables/constants/etc. That (older) method is powered by a background scan which periodically saves the required information in edita.edb - and you can investigate the contents of that via Tools/Database Viewer.
Holding down the Ctrl key and hovering the mouse over an identifier changes it to a link; left clicking will jump straight to the definition, and right-clicking will show a pop-up with a basic summary, and an option to jump directly to that file/source.
The latter is achieved (see demo\edita\src\eaisense.ew) by invoking "pw.exe -isense file line col partial_key mode main_file" which plants the requested information from a partial compilation into %TMP%\isense.txt (don't worry, it's near-instant) and sends back a message once it is ready.
Edita handles the messy details of all that for you automatically, but of course you are free to copy and modify those techniques however you like.
I should warn you that Edita is windows-only, however Edix is well under way and if ever finished will offer the same functionality cross-platform.
===Programmatically===
The autoinclude file builtins\pincpathN.e defines the include_paths() builtin, which returns something like:
<pre>
{"C:\\Program Files (x86)\\Phix\\builtins\\",
"C:\\Program Files (x86)\\Phix\\builtins\\VM\\",
"C:\\Program Files (x86)\\Phix\\"}
</pre>
or the directories where your project is located. If you examine that source file (pincpathN.e) you will see a commented-out constant T_fileset and it should not be hard to imagine a matching (but currently missing) sister function named include_files() that retrieves a set of {idx,name} where idx are indexes into the result from above, should that be of interest to you. Note that if it is a pre-compiled executable installed on an end users machine, those sources might not be available, but the internal routines still provide the same names since they are generally quite useful for diagnostic purposes.
A caught exception (see the documentation for throw) contains the line number, file, and path (with the same caveat as above when installed elsewhere).
The file pincpathN.e also shows you how to get your grubby little mitts on the symbol table, and you may also want to look at builtins/VM/prtnidN.e for some ideas on scanning that. Throwing and catching an exception is one way to ensure the symbol table is populated with proper names rather than obscure integer ternary tree indexes. See pglobals.e for detailed notes about the contents of the symbol table. Some caution is advised here; the compiler my plant some otherwise illegal raw values in the symbol table, and play fast and loose with reference counts, etc, and of course messing it up may make life (/subsequent debugging) rather troublesome.
Of course the source files are just files that you can read like any other text files, and for all its detail, the symbol table contains very little in the way of context, which may make mapping of non-unique identifiers rather difficult.
=={{header|Python}}==
| |||