request - get argments like in xdebug

[wojons]

I wanted to know if there was anyway to get arguments like in xdebug. I think they allow for knowing the type of data and the size of that data, and then also to be able to dump all the aguments

[bweston92]

LINE
FILE
DIR

print_debug_traceback()
debug_traceback()

Should be able to help a bit

---

Thanks, Bradley.
Sent from my iPhone

On 10 Feb 2013, at 20:11, Alexis Okuwa notifications@github.com wrote:

I wanted to know if there was anyway to get arguments like in xdebug. I think they allow for knowing the type of data and the size of that data, and then also to be able to dump all the aguments

—
Reply to this email directly or view it on GitHub..

[aterrien]

We are working on it. I suggest you read #7.

[wojons]

Okay thank you very much I think this is a lot smaller then xdebug thats why i am using it in a project, if there is anything i can help you with I would love to give back to what you have already done, I am not very good at C its been a while but anything else i can help with I would be glade to.

[aterrien]

The project is young, don't hesitate to give your feedback.

[ichiriac]

You can use the @ProfileCaption annotation to output directly on the stack view the function arguments debug, take a look at the README.md samples.

It outputs the strings contents, and for other types only a simple outputs version (array, classname, etc...)

[wojons]

The objective of the project that i am working on is that the user would
not need to edit there code to get it to work with this, it is more or less
plug and play

On Mon, Feb 11, 2013 at 2:02 AM, Ioan CHIRIAC notifications@github.comwrote:

You can use the @ProfileCaption annotation to output directly on the stack
view the function arguments debug, take a look at the README.md samples.

It outputs the strings contents, and for other types only a simple outputs
version (array, classname, etc...)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-13373918..

Enjoy,
Alexis Okuwa
WojonsTech
424.835.1223

[wojons]

Currently i am using @bweston92 suggestion, but wanted to know if there was any update with this feature request currently i merge the forp_dump with debug_backtrace, maybe forp_dump can have that intergrated for starters.

[wojons]

@aterrien wanted to know if we could get this feature included soon?

[wojons]

@aterrien ping?

[aterrien]

Was working on an other project last weeks :(

This feature is the next one in our forp backlog.

I don't know if you have tested forp_inspect() ? It allows you to explain a var in forp stack. Debug is sent to the Inspector tab of forp-ui. It's a little bit intrusive in PHP code.

I've recently commited forp_json, I advise you to use it if you directly send forp_dump to javascript client like forp-ui. It avoid to create a buffer before sending the output and, therefore, it decrease the memory footprint of forp.

FYI, since few days, I'm working on new features for forp-ui.

[wojons]

Wow, cool stuff I have seen but not player with forp_json or forp_inspect.
Is forp_json better then json_encode if Im going to write the results to a
file. I will also play with forp_inspect been using an old version of the
ui because was to lazy to build the new one to look like the old one.

If there is anything I can help you with
Please let me know. And is there any eta on how long you think this feature
will take.
On Jul 20, 2013 7:27 AM, "aterrien" notifications@github.com wrote:

Was working on an other project last weeks :(

This feature is the next one in our forp backlog.

I don't know if you have tested forp_inspect() ? It allows you to explain
a var in forp stack. Debug is sent to the Inspector tab of forp-ui. It's a
little bit intrusive in PHP code.

I've recently commited forp_json, I advise you to use it if you directly
send forp_dump to javascript client like forp-ui. It avoid to create a
buffer before sending the output and, therefore, it decrease the memory
footprint of forp.

FYI, since few days, I'm working on new features for forp-ui.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-21294289
.

[wojons]

@aterrien any update yet on this feature?

[wojons]

@aterrien ping

Just wanted to know if there were any updates on this

[aterrien]

hi wojons .. no, sorry :(

[wojons]

@aterrien okay thats cool, if you want please feel free to email me. my email address is in listed on my account.

[wojons]

@aterrien ping?

[ichiriac]

hi, i've recently used forp_inspect. It enables you to output in the forp GUI the vars and navigate into. For the output it's only works on forp_dump() the forp_json() serialisation is not yet implemented.

That's a sample code that I use :

/**
 * Handling forp profiler bootstrap
 */
if (
    function_exists('forp_start') && IS_DEV
) {
    forp_start();
    forp_inspect('$_SERVER', $_SERVER);
    forp_inspect('$_REQUEST', $_REQUEST);
    register_shutdown_function(
        /**
         * @ProfileAlias("Shutdown Function")
         */
        function() {
            if (defined('PROFILE_DISABLED')) return;
            if (!defined('PROFILE_ENABLED')) return;
            if ( PHP_SAPI !== 'cli' ) {
                echo '<script src="http://aterrien.github.io/forp-ui/javascripts/forp.min.js?v2"></script>';
                echo '<script>var $f = new forp.Controller(); $f.setStack(';
                echo json_encode(forp_dump());
                echo ').run();</script>';
            } else {
                forp_print();
            }
        }
    );
}

TIP : You also need to use the latest version for forp.min.js

[wojons]

@ichiriac this is pretty cool and useful but i was hoping for forp_inspect to run within forp_start(); and when ever a method is called it would inspect them. Just so profiling can be done with less code. other wise i am going to have to write a way for it to also work with xdebug since it has that setting built in.

[ichiriac]

@wojons It could be triggered by an annotation like @ProfileInpect - but anyway it could not be possible to automatically grab any parameter of any call because the amount of data to be output could be big - could you tell us the xdebug parameter / setting / function that you could use it could help us to better understand how they do :)

[wojons]

@ichiriac

http://xdebug.org/docs/stack_trace

using this flag in the ini file or ini_set(), xdebug.collect_params

depending on the input will collect the entire value or just the the type of value it was

[ichiriac]

@wojons ok, I understand better now, If we just grab the type and size it could work (the size is not so big as the unserialized structure of data).

I'm not sure but I think the variables collected in xDebug are not written in the profiler output file used with KCacheGrind, they just shown on errors/notices so even if they took place in memory, the output is limited even if they output the full data dump, it's concerns only a leaf of the execution stack.

Actually I think it's a dilemma :) ... if we collect only the type and the size it's not enough in some/most cases (strings, arrays) but if we include the serialization data in each call it will overkill the memory, json output, javascript GUI loading ...

Any idea is welcome

[wojons]

@ichiriac I am thinking that if we get tarted with what type of input it is and we hook in there that would be a good first step. the next steps i would allow in the settings that if you want the summerized or serializated format of the data. if you take the raw data maybe we allow the user to set limits on how long each one could be sometimes the first few characters are enough and then the max amount of them that are able to occure. I am also very intrested in knowing how xdebug handles this.

[wojons]

@ichiriac ping?

[ichiriac]

Sorry @wojons i was a little busy.

So, to recap, you want to profile arguments on each call - but just showing basic informations (type, size, preview of data).

We think that it can be done and technically could be not so big. On the other hand, if you want to output more specific data, you can even use forp_inspect or @ProfileCaption

But we actually don't do the same stuff as xdebug because xdebug is oriented for debugging (step/by/step debugger) and forp is only a profiler.

Main difference is that forp can actually serve for profilling execution (speed, memory usage ... and some cool stuff) but it's not for debugging as xdebug does ...

On the other hand, forp is intended to be used on production servers without slowing down the process, and as you know xdebug should not be enabled on a production server - that's why we are carefull to not allocate too much cpu or ram when we process data.

[wojons]

@ichiriac you are correct I have never written a php c extension before so I would not know where to start on collecting this data. Once I understand how you get the values I should be able to add some extra logic on when I want the full text of an arg or when I simply want its type and size.

How long do you think it will take to get this added?

[wojons]

@aterrien & @ichiriac pls any word on this feature

[aterrien]

Sorry wojons, we have worked a lot last weeks on most important features (refactoring of forp-ui, forp.io, forp-chrome).
Also, we decided that forp is a profiler and must do that perfectly before doing more debug things.

[wojons]

anyway you guys could help get me started on how to do this in another branch and then i will figure it out from there? also whats the goal of forp.io

[ichiriac]

@wojons You're welcome to fork the project, to get your own work copy follow the steps :

1. first fork this project from github (that will make a copy on your account)
2. clone it from your account on your desktop
3. make changes and test it, and when they are ok, commit them on your account
4. make a pull-request of your changes, and we will merge them on this repository

If you need help for building or testing your code you can open an issue here, I'll try to help you