Yappi does not capture the complete filename, only the basename.

[GoogleCodeExporter]

Would it be possible to capture the complete filename rather
than just the basename? It seems to be stripping out the dirname
in _item2fname.

Yappi is truly awesome, by the way.

Original issue reported on code.google.com by dave.pet...@gmail.com on 16 Mar 2010 at 11:56

[GoogleCodeExporter]

ok, sure. But this needs to wait as I will not be able to work for few months 
unless
somebody else implements this. Thanks for the comment.

Original comment by oktaka...@gmail.com on 26 Mar 2010 at 9:37

[GoogleCodeExporter]

Thank you! I took a stab at it, but just increasing
the maximum size of the filename field was giving me
segfaults. I'll see if I can give it another go.

Original comment by dave.pet...@gmail.com on 27 Mar 2010 at 2:42

[GoogleCodeExporter]

This seems trivial to implement but in fact it is not.the problem is how to 
format
the results in a reasonable manner in 80 column width(default console width). 
This
needs to be thought carefully, maybe we need to make more lines and format the 
header
string according to that and that is not so easy. Another way is to use 
enum_stats()
function which will be called per profile item, maybe item2fname() can be 
changed if
it is called from enum_stats() and we simply do not exclude the basename if
specified. Instead of changing the default formatting, changing enum_stats() and
letting user do his/her own formatting would be better.

Original comment by oktaka...@gmail.com on 27 Mar 2010 at 8:30

[GoogleCodeExporter]

Maybe the default formatting cuts off the path at the front
to preserve the maximum width?

Something like:

../my/super/module.py

And then you can use enum_stats() if that's not good enough?

Original comment by dave.pet...@gmail.com on 27 Mar 2010 at 6:04

[GoogleCodeExporter]

That seems reasonable, have you tried implementing this? Unfortunately, I am
currently unable to work wıth the source code.

Original comment by sum...@gmail.com on 30 Mar 2010 at 10:14

[GoogleCodeExporter]

Not yet, but I will.

Original comment by dave.pet...@gmail.com on 30 Mar 2010 at 3:04

[GoogleCodeExporter]

Ok, here's what I got so far. I also switched some calls to sprintf snprintf.
I think there are some buffer overrun possibilities in the current code. I
haven't tested this on Windows yet, so I'm not sure if my #ifdef works or not.

Original comment by dave.pet...@gmail.com on 4 Apr 2010 at 7:09

Attachments:

• yappi.patch

[GoogleCodeExporter]

I meant to write 'switched some calls from sprintf to snprintf'.

Original comment by dave.pet...@gmail.com on 4 Apr 2010 at 9:05

[GoogleCodeExporter]

The reason that I don't use snprintf is there is some platform differences 
between
formatting the strings when overruning the result string. As far as I can 
remember
Windows and Linux behaves dıfferently if you try to snprintf a size+1 string 
into
size buffer. however I wıll re-test the situation and inform you the exact 
problem.
Other than that thanks for code, I wil try to update ASAP.

Original comment by sum...@gmail.com on 5 Apr 2010 at 7:38

[GoogleCodeExporter]

Oh, you're right. Stupid windows. But this web page suggests an alternative:

http://www.di-mgt.com.au/cprog.html

Maybe we could use that slprintf version on windows?

Original comment by dave.pet...@gmail.com on 5 Apr 2010 at 9:40

[GoogleCodeExporter]

No rush, by the way, I can try porting to the slprintf function I mentioned.

Original comment by dave.pet...@gmail.com on 5 Apr 2010 at 11:00

[GoogleCodeExporter]

How about using PyOS_snprintf? That is documented to be portable in the Python 
C API
documentation.

Original comment by sum...@gmail.com on 21 Apr 2010 at 10:39

[GoogleCodeExporter]

Oh, brilliant. I will port to that, thank you!

Original comment by dave.pet...@gmail.com on 22 Apr 2010 at 1:26

[GoogleCodeExporter]

Ok, seems to work for me, how about you?

Original comment by dave.pet...@gmail.com on 22 Apr 2010 at 3:38

Attachments:

• yappi.patch

[GoogleCodeExporter]

Ok it works for Windows, too. I have changed your patch a little bit, accept a
direction param for formatting. You can check the latest version from SVN 
repository
with other changes. I will upload the new version. Thanks for your help.

Original comment by sum...@gmail.com on 23 Apr 2010 at 8:07

[GoogleCodeExporter]

Thanks, I'll check it out!

Original comment by dave.pet...@gmail.com on 24 Apr 2010 at 1:17

[GoogleCodeExporter]

Works for me! Thanks, Sumer.

Original comment by dave.pet...@gmail.com on 24 Apr 2010 at 9:55

[GoogleCodeExporter]

fixed in version 0.51.

Original comment by sum...@gmail.com on 15 May 2010 at 12:13

• Changed state: Fixed