lillo: Profiler

[Antoni]

Lillo:
As there seems to be no private messages here I report it to the forum:

The profiler in version 0.14 continues not creating the report if a filename is passed in the command$ list.If the command$ is left empty it works.
The same bug you could not reproduce in v 0.13. Perhaps if I send you my PC via DHL.....

AS I said before, it's not important as I can use the preprocessor to compile an alternate version for profiling.

BTW: The 0.13 profiler created an exe 0f 300K, 4 times biggerthan the normal exe.The 0.14 profiler creates a 3,2Meg exe, you may be using tons of (faster) static vars!!

[v1ctor]

Using -g too? The new debugging support for symbols will add quite a lot of data to allow GDB to show user types, local vars etc.

EDIT: btw, i can't reproduce the profile error in XP, in which OS did that happen?

[lillo]

A new 0.14 pre-release for both Win32 and Linux has been released (files already on SF, V1ctor should update the site soon to reflect this), with a new profiler core. Hope this fixes the issue... Please try with this new pre-release and let me know!

[Antoni]

V!ctor:
So you implemented full debugger support!!!
Version .13 of the profiler did not work without -g. I will try without it...


OK, i'm going to try the new pre-release ...

[Antoni]

Lillo: The new version has the same problem.

[v1ctor]

Not full support yet, include files aren't working (GDB gets nuts because the main function overlapping the other ones, what can't happen in C), dynamic arrays won't show their contents (i can't get GDB to use Fortran arrays), enum's will be converted to integers, but everything else seems to be working..

Btw, you have to type the var names in UPPERCASE to watch them, if they aren't parameters or local vars, that are watched automatically.

Insight for Windows can be download from the Cygwin (the gdb package).

[lillo]

Compiling with profiling support is completely independent of compiling with debugging support... So you can compile with the -profile switch and still not use -g, as well as you could use both, resulting in a profiling exe with debug support ;)

Anyway, I can't reproduce your problem either; here's what I do:
Having this small program:

Code: Select all

f$ = command$
print "hello"
sleep

I compile it with

Code: Select all

fbc command.bas -profile

Then if I run command.exe with:

Code: Select all

command.exe these are fake arguments

I still get profile.txt generated in the directory of the exe...

[Antoni]

No, it's not ANY command line, I'm afraid i did'nt explain it very well.
It's dragging & dropping a file to the exe (that should convert to a command line parameter surrounded by doublequotes in windows)
Of course, my program is prepartre do strip the doublequotes when it receives them.
If the file name is written manually in a command line, profiler works.

Yes -g is not needed, but it was in v0.13 (unless I got puzzled with the d'n'd' problem)

[Sisophon2001]

No, it's not ANY command line, I'm afraid i did'nt explain it very well.
It's dragging & dropping a file to the exe

<snip>

Hi:

What happens is the “profile.txt” file is created in the current directory, which is not necessarily the directory of the exe, so it is easy to get “lost”. In my tests when I drag-and-drop a file on the exe the “profile.txt” ends up in C:\Documents and Settings\XXX where XXX is the current user.

Now that I look, there is a lot of old garbage in this directory.

Have fun

Garvan

[lillo]

I was suspecting something like this... So now I've fixed the problem by forcing profile.txt to be generated in the same directory of the EXE. Fix is in CVS.

[Antoni]

I should have guessed it....Drag and drop leads to strange current paths with nothing to do with the Dragged or the dropped items. I'm adding

Code: Select all

cd /d %~dp0      

in all the bach files I intend to use with drag and drop...
Lillo: excuse me for not delimiting the problem and waste your time.