hi,
i am trying to access the source that a program/object/function is coming from.
the information must be there somewhere, since eg a backtrace produces it, but i can't figure out how to get to it.
it would be sort of like the reverse of master()->program_path_to_name().
any suggestions?
greetings, martin.
Backtraces produce filenames from the line-number table. This may contain more than one filename, if #include is used.
It's not your source? Otherwise you can use the precompile identifier __FILE__,
constant my_source=__FILE__;
my_program->my_source;
no, it's not my source.
what i am actually trying to do is, to extract the documentation for any given item, to be able to display it at runtime.
i figured out how to pick the docs from a file, and now i need to find the file.
potentially i could do a search on the master()->programs mapping,
or alternatively modify the compile process to store the documentation alongside the compiled object. maybe even add a _doc() function to each class. no idea how to do that though...
greetings, martin.
You should be able to use the same routines as the describe_backtrace routine. However, I'm not sure how that one works, but it should have the proper magic deep inside.
Might have to code some C though. :p
hmm, i don't think so. describe_backtrace appears to be a formatting function that takes an error as argument.
it would have to be within backtrace() itself.
it probably makes more sense to just capture the docs at compile time. that way it will also work with classes that are built from a string at runtime.
greetings, martin (who just has a visit from a mantis in his kitchen).
This will not work in all cases though, as it is possible to document a function in another file than the implementation (or more likely where it is actually made public for the user). As an example, look at the top of Array.pmod.
well, it will of course not work for code written in c, but that can be solved later and is no reason to not try to make it work for the rest.
i don't see any documentation in Array.pmod for functions that are not defined there. i see constants that point to builtins which would be documented where the code is and not where they are exposed to the user.
greetings, martin.
ah, useful, somewhat, as
Program.defined(object_program(Stdio));
(9) Result: "/local/users/mbaehr/tomoyo/src/pike/Pike-7.7/lib/master.pike:1648"
is the definition if the joinnode class.
it's not a deal breaker though as i went down the route of parsing the docs each time a program is compiled, which has the advantage of working with compile_string() too.
right now i am stuck somewhere else. the detection of modules is currently a rather crude guess based on the token stream and i'd like to have something more reliable.
there appears to be a difference between what _typeof() finds, but other than using sprintf() and scanning the string i don't know how to make use of that:
_typeof(Tools);
Result: object(is master()->joinnode)
_typeof(Tools.Hilfe);
Result: object(is object_program(Tools.Hilfe))
_typeof(.somemodule);
Result: object(is object_program(/local/users/mbaehr/tomoyo/src/pike/tmp/somemodule))
_typeof(.someclass(1));
Result: object(is /local/users/mbaehr/tomoyo/src/pike/tmp/someclass)
greetings, martin.
is the definition if the joinnode class.
For me it's a dirnode and not a joinnode, but yes, such things complicates matters. For dirnodes you can index out dirname, e.g. Stdio->dirname. For joinnodes you'd have to index out joined_modules and then investigate those further. (This is a reason to only have `[] and not `-> overloaded in those two classes.)
If you write code that tries to extract paths and lines from dirnodes and joinnodes I suggest you put it inside those classes, because they might be entirely rewritten at some point in the future.
right now i am stuck somewhere else. the detection of modules is currently a rather crude guess based on the token stream and i'd like to have something more reliable.
You mean .pmod vs .pike files? Looking in the objects mapping in the master should be a fairly reliable to tell whether something is a module. Strings cast to objects end up there too, but that's an uncommon thing to do (I think that should be an error instead - such quirky and unintuitive casts are just confusing).
there appears to be a difference between what _typeof() finds,
Isn't it better to use the describe_* functions in the master, or take a look at how they do it? It's probably the same functions _typeof itself is using.
On Sun, Jun 10, 2007 at 01:55:03PM +0000, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
You mean .pmod vs .pike files? Looking in the objects mapping in the master should be a fairly reliable to tell whether something is a module.
ah, right.
Strings cast to objects end up there too, but that's an uncommon thing to do (I think that should be an error instead - such quirky and unintuitive casts are just confusing).
i am guilty of having done that. but you do have a point. although, it IS useful to create singleton objects:
((program)"someclass.pike")() == ((program)"someclass.pike")();
Result: 0
((object)"someclass.pike") == ((object)"someclass.pike");
Result: 1
there appears to be a difference between what _typeof() finds,
Isn't it better to use the describe_* functions in the master, or take a look at how they do it? It's probably the same functions _typeof itself is using.
the describe_functions are not generic, means, i'd have to do multiple tests, and it still does not make it any easier to get the type.
greetings, martin.
i am guilty of having done that. but you do have a point. although, it IS useful to create singleton objects:
The function as such is not my gripe. It's the way it's hooked into the cast operation. There's no natural mapping between strings and objects, as it is between e.g. the integer 1 and the string "1". If anything, it'd be slightly more natural to interpret the string as pike code and compile it.
the describe_functions are not generic, means, i'd have to do multiple tests, and it still does not make it any easier to get the type.
If you want the type then that's exactly what _typeof gives you. No sprintf'ing and no scanning needed. I don't understand what you want.
master()->objects[object_program(Stdio)]; should have done the trick. i am puzzled why that does not work.
Ah, yes, dirnodes and joinnodes don't end up there, only "proper" module objects. The fc mapping is better:
master()->fc_reverse_lookup (Mapping);
(1) Result: "/home/mast/Pike/stable/lib/modules/Mapping"
master()->fc_reverse_lookup (Stdio);
(2) Result: "/home/mast/Pike/stable/lib/modules/Stdio"
On Sun, Jun 10, 2007 at 03:10:01PM +0000, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
the describe_functions are not generic, means, i'd have to do multiple tests, and it still does not make it any easier to get the type.
If you want the type then that's exactly what _typeof gives you. No sprintf'ing and no scanning needed. I don't understand what you want.
what i want is to be able to decide whether a given object is a module or not.
having the type as given by _typeof() or by master()->describe_module() does not solve the problem because each module has a different type, and i'd have to try to look at the output for hints that help me decide if that type is a module or not.
eg: by doing stunts like: search(sprintf("%O", _typeof(Stdio)), "node")
master()->objects[object_program(Stdio)]; should have done the trick. i am puzzled why that does not work.
Ah, yes, dirnodes and joinnodes don't end up there, only "proper" module objects. The fc mapping is better:
but the DO end up there:
master()->objects;
(1) Result: ([ /* 30 elements */ master: master(), object_program(_static_modules): _static_modules, object_program(_Charset): _Charset, object_program(Locale.Charset): Locale.Charset, object_program(Pike): Pike, object_program(System): System, object_program(Stdio): Stdio, object_program(Locale): Locale, object_program(___Math): ___Math, object_program(Math): Math, object_program(Array): Array, object_program(String): String, object_program(Gmp): Gmp, object_program(_ADT): _ADT, object_program(ADT): ADT, object_program(Parser.XML.Tree): Parser.XML.Tree, object_program(Parser.XML): Parser.XML, object_program(__builtin): __builtin, object_program(Parser._parser): Parser._parser, object_program(Parser): Parser, object_program(Tools.AutoDoc.PikeObjects): Tools.AutoDoc.PikeObjects, object_program(Tools.AutoDoc.PikeExtractor): Tools.AutoDoc.PikeExtractor, object_program(Tools.AutoDoc): Tools.AutoDoc, object_program(Thread): Thread.Thread(0), object_program(Stdio.Terminfo): Stdio.Terminfo, object_program(Tools.Hilfe): Tools.Hilfe, object_program(Getopt): Getopt, object_program(Parser.Pike): Parser.Pike, object_program(Tools.AutoDoc.DocParser): Tools.AutoDoc.DocParser, object_program(Error): Error ])
master()->fc_reverse_lookup (Mapping);
(1) Result: "/home/mast/Pike/stable/lib/modules/Mapping"
master()->fc_reverse_lookup (Stdio);
(2) Result: "/home/mast/Pike/stable/lib/modules/Stdio"
what version of pike is that?
i get:
master()->fc_reverse_lookup(Stdio);
(2) Result: 0
fails both in the 7.7 pikefarm build as well as in a regular installed 7.6
greetings, martin.
but the DO end up there:
What you see there are the programs for the compiled module.pmod files, I think.
I think the problem is that you get joinnodes like this:
Stdio;
Result: master()->joinnode(({ /* 1 element */ master()->dirnode("/home/mast/Pike/frozen/lib/modules/Stdio.pmod") }))
The fc mapping always contain dirnodes, so you'd get a hit in it by picking out the dirnodes first, e.g:
master()->fc_reverse_lookup (Stdio->joined_modules[0]);
Result: "/home/mast/Pike/frozen/lib/modules/Stdio.pmod"
And you get a hit in objects if you pick out the "module" of the dirnode:
master()->objects[object_program (Stdio->joined_modules[0]->module)];
Result: Stdio
But the last part only works for directory modules with module.pmod in them.
I don't know exactly why you get more joinnodes than me. It seems kind of unnecessary to have a joinnode with only one dirnode in it, as I got above.
Note that all these details are largely considered internal in the master. As I've said earlier, it might happen that dirnodes and joinnodes get rewritten completely (I'd like to see a solution where at least the dirnodes actually get compiled from the code in the directory, so that typing and inheriting would work better).
So if you write code that dig around in these things, you better put it in the master (having variants of Program.defined and Function.defined that correctly handles all these pecularities would be nice).
ahh,
now it makes sense, thank you!
greetings, martin.
On Sun, Jun 10, 2007 at 01:55:03PM +0000, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
You mean .pmod vs .pike files? Looking in the objects mapping in the master should be a fairly reliable to tell whether something is a module.
it looks easy, but i can't get it to work:
master()->objects[Stdio];
(25) Result: 0
master()->objects[object_program(Stdio)];
(26) Result: 0
master()->objects[_typeof(Stdio)];
(29) Result: 0
master()->objects[typeof(Stdio)];
(30) Result: 0
master()->objects[master()->describe_module(Stdio)];
(31) Result: 0
master()->objects[object_program(Stdio)]; should have done the trick. i am puzzled why that does not work.
greetings, martin.
pike-devel@lists.lysator.liu.se
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum -
Martin Baehr -
Martin Bähr
-
Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Mirar ＠ Pike developers forum