[Digikam-devel] Include file firstrunUI.h missing, other beginner questions

[Peter Heckert]

Hi,

A question:

I deleted my whole source tree and I sucked a completely fresh working
copy for digikam 0.9.0, using these instructions:

svn co -N svn://anonsvn.kde.org/home/kde/trunk/extragear/graphics
cd graphics
svn up digikam
svn up digikamimageplugins
svn co svn://anonsvn.kde.org/home/kde/branches/KDE/3.5/kde-common/admin

When I build the digikam project in kdevelop, I get this error:

digikamfirstrun.cpp:64:24: error: firstrunUI.h: No such file or directory

The file is really missing and "svn up digikam" doesnt recover it.
It should do this, shouldnt it?
So I believe, the file is missing in svn's database?

I did the same thing yesterday with success, but today no luck.

Another question:

Need I special compiler settings, when I want to debug?
I use the project configuration "default" in kdevelop and this
has the configure argument "--enable-debug=full". Is this enough to do
source code level debugging (singlestep and so on)?

I tried yesterday, but had no sucess, maybe I hosed somthing up, I am a
very newbee ;-)

Another question:

Is it okay, when I post these very basic beginner questions here?

I just want to get started up and I want to write and debug some plugin
code (the noisereduction plugin) , so I hoped I can do this without
knowing everything about the whole project and the build system, is this
reasonable?

peter
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-2]

Le Mardi 04 Avril 2006 09:13 PM, Peter Heckert a écrit :

> Hi,
>
> A question:
>
> I deleted my whole source tree and I sucked a completely fresh working
> copy for digikam 0.9.0, using these instructions:
>
> svn co -N svn://anonsvn.kde.org/home/kde/trunk/extragear/graphics
> cd graphics
> svn up digikam
> svn up digikamimageplugins
> svn co svn://anonsvn.kde.org/home/kde/branches/KDE/3.5/kde-common/admin
>
> When I build the digikam project in kdevelop, I get this error:
>
> digikamfirstrun.cpp:64:24: error: firstrunUI.h: No such file or directory
>
> The file is really missing and "svn up digikam" doesnt recover it.
> It should do this, shouldnt it?
> So I believe, the file is missing in svn's database?
>
> I did the same thing yesterday with success, but today no luck.
>

No. firstrunUI.h is a temp source file generated by Qt moc pre-compiler. On
any linux box (like Mandriva for example !!!), i have the same error.

I have tried to solve this problem accordinly with Mandriva team... but
without success. This problem is very wierd...

To solve it, just going into digikam/digikam folder, i start "make
firstrunUI.moc". all temp source code generated by moc program will be done.
You can compile all digikam after that. Later, nothing will be done on
firstrunUI...

moc compiler is used to build GUI from xml file genrated by QtDesigner
program. I hate it. I prefert build GUI from scratch because it's very easy
to make gui/layout/widget using Qt API.

When i will more free time, i will rewrite this firstrunUI part from scratch
(:=)))...


> Another question:
>
> Need I special compiler settings, when I want to debug?
> I use the project configuration "default" in kdevelop and this
> has the configure argument "--enable-debug=full". Is this enough to do
> source code level debugging (singlestep and so on)?

yes, it's enough. I'm working like this everytime.

>
> I tried yesterday, but had no sucess, maybe I hosed somthing up, I am a
> very newbee ;-)
>
> Another question:
>
> Is it okay, when I post these very basic beginner questions here?
>

sure (:=)))

> I just want to get started up and I want to write and debug some plugin
> code (the noisereduction plugin) , so I hoped I can do this without
> knowing everything about the whole project and the build system, is this
> reasonable?

Don't forget that to debug a source code, gdb is not enough. You need to use
valgrind program to check memory allocation/using/leak. default settings is
available in HACKING file from svn. Read the valgrind doc before. This tool
is really incredible (:=))).

Friendly

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Peter Heckert]

Hi Gilles,

Caulier Gilles wrote:

> Le Mardi 04 Avril 2006 09:13 PM, Peter Heckert a écrit :
> I have tried to solve this problem accordinly with Mandriva team... but
> without success. This problem is very wierd...
>
> To solve it, just going into digikam/digikam folder, i start "make
> firstrunUI.moc". all temp source code generated by moc program will be done.
> You can compile all digikam after that. Later, nothing will be done on
> firstrunUI...
>
> moc compiler is used to build GUI from xml file genrated by QtDesigner
> program. I hate it. I prefert build GUI from scratch because it's very easy
> to make gui/layout/widget using Qt API.
>
> When i will more free time, i will rewrite this firstrunUI part from scratch
> (:=)))...
>

Thanks. This explains it.

I compiled from commandline, this succeeeded.
After doing so compiling in kdevelop was successful also.

Unfortunately these experiments needed 3 hours ;-)

The userinterface in digikam is incredibly good, so I could concentrate
on the number crunching code for the plugin, that is what I want to do.

>
>> Another question:
>>
>> Need I special compiler settings, when I want to debug?
>> I use the project configuration "default" in kdevelop and this
>> has the configure argument "--enable-debug=full". Is this enough to do
>> source code level debugging (singlestep and so on)?
>
> yes, it's enough. I'm working like this everytime.
>

Unfortunately this doesnt work for me.

I set a breakpoint in the plugin code.
Then I start the program (F9).

The program stops at breakpoint.
Then I see a green triangle at the breakpoint location.

and when I press F11 (singlestep) the program steps on.
(I am doing this while writing)
Ok... I stepped until the next breakpoint.

Now this beakpoint is grayed out and the digikam app is dead (no response)

The debug menu gives me the options to suspend the app or to halt it.
But so far I can see, it doesnt run.
Suspending does nothing, no change. Halt will abort digikam, it dies.

I can see the local variables for my procedure, but so far I can see,
the execution point is elsewhere and the programm is not running, maybe
it hangs on another breakpoint, but how can I find it?

I got all my software from debian's testing and unstable repositories.

Possibly my kdevelop is buggy, possibly I should try to write a hello
world program first and try to debug it.. Unfortunately
kdevelop-GUI-debugging is not so very well documented, I must try how it
works.

> Don't forget that to debug a source code, gdb is not enough. You need to use
> valgrind program to check memory allocation/using/leak. default settings is
> available in HACKING file from svn. Read the valgrind doc before. This tool
> is really incredible (:=))).
>
Yes I know. But in advance I must write some code to produce some memory
leaks. It's an easy task for me, I am rather good with this *g*

thanks so far,

peter


_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-2]

Le Mercredi 05 Avril 2006 12:06 AM, Peter Heckert a écrit :

> Hi Gilles,
>
> Caulier Gilles wrote:
> > Le Mardi 04 Avril 2006 09:13 PM, Peter Heckert a écrit :
> > I have tried to solve this problem accordinly with Mandriva team... but
> > without success. This problem is very wierd...
> >
> > To solve it, just going into digikam/digikam folder, i start "make
> > firstrunUI.moc". all temp source code generated by moc program will be
> > done. You can compile all digikam after that. Later, nothing will be done
> > on firstrunUI...
> >
> > moc compiler is used to build GUI from xml file genrated by QtDesigner
> > program. I hate it. I prefert build GUI from scratch because it's very
> > easy to make gui/layout/widget using Qt API.
> >
> > When i will more free time, i will rewrite this firstrunUI part from
> > scratch (:=)))...
>
> Thanks. This explains it.
>
> I compiled from commandline, this succeeeded.
> After doing so compiling in kdevelop was successful also.
>
> Unfortunately these experiments needed 3 hours ;-)
>
> The userinterface in digikam is incredibly good, so I could concentrate
> on the number crunching code for the plugin, that is what I want to do.

cool (:=)))

>
> >> Another question:
> >>
> >> Need I special compiler settings, when I want to debug?
> >> I use the project configuration "default" in kdevelop and this
> >> has the configure argument "--enable-debug=full". Is this enough to do
> >> source code level debugging (singlestep and so on)?
> >
> > yes, it's enough. I'm working like this everytime.
>
> Unfortunately this doesnt work for me.
>
> I set a breakpoint in the plugin code.
> Then I start the program (F9).
>
> The program stops at breakpoint.
> Then I see a green triangle at the breakpoint location.
>
> and when I press F11 (singlestep) the program steps on.
> (I am doing this while writing)
> Ok... I stepped until the next breakpoint.
>
> Now this beakpoint is grayed out and the digikam app is dead (no response)
>
> The debug menu gives me the options to suspend the app or to halt it.
> But so far I can see, it doesnt run.
> Suspending does nothing, no change. Halt will abort digikam, it dies.
>
> I can see the local variables for my procedure, but so far I can see,
> the execution point is elsewhere and the programm is not running, maybe
> it hangs on another breakpoint, but how can I find it?
>
> I got all my software from debian's testing and unstable repositories.
>
> Possibly my kdevelop is buggy, possibly I should try to write a hello
> world program first and try to debug it.. Unfortunately
> kdevelop-GUI-debugging is not so very well documented, I must try how it
> works.

Sounds like you haven't installed the fresh recompiled plugin before to start
debuging.

The plugins isn't in digikam core. When you start gdb instance via kdevelop,
the binary plugin target used come from your core system, not in local.

You need to install it before. No need to re-install digikam at all. Just open
kdevelop console, go to plugin source code folder and use "su; make install".

>
> > Don't forget that to debug a source code, gdb is not enough. You need to
> > use valgrind program to check memory allocation/using/leak. default
> > settings is available in HACKING file from svn. Read the valgrind doc
> > before. This tool is really incredible (:=))).
>
> Yes I know. But in advance I must write some code to produce some memory
> leaks. It's an easy task for me, I am rather good with this *g*
>
> thanks so far,

De nada

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Peter Heckert]

Caulier Gilles wrote:

> Le Mercredi 05 Avril 2006 12:06 AM, Peter Heckert a écrit :
> Sounds like you haven't installed the fresh recompiled plugin before to start
> debuging.
>
> The plugins isn't in digikam core. When you start gdb instance via kdevelop,
> the binary plugin target used come from your core system, not in local.
>
> You need to install it before. No need to re-install digikam at all. Just open
> kdevelop console, go to plugin source code folder and use "su; make install".
>

Thank you very much.
I did this and first had the same behavior.
However after about 10 minutes the program was alive again and it
stopped again at the breakpoint.

So it was not crashed, but seemingly it was running incredibly slowly.
Is it possible, that debugging slows down the proggie?
Are there debugging hooks e.g. for memory allocation that can slow down
the program in this way?

Can I avoid this?

Thanks in advance for your help.
Ok, this had been 5 hours for today I cannot do this forever, the
program was sleeping, now I must go to sleep :-/

peter


_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

> Thank you very much.
> I did this and first had the same behavior.
> However after about 10 minutes the program was alive again and it
> stopped again at the breakpoint.
>
> So it was not crashed, but seemingly it was running incredibly slowly.
> Is it possible, that debugging slows down the proggie?
> Are there debugging hooks e.g. for memory allocation that can slow down
> the program in this way?

Running under gdb is a bit slower, but not like that. Starting takes
considerably longer because gdb reads information from shared libs, but
running as such is not so much affected (not to be compared to running under
valgrind).

>
> Can I avoid this?
>
> Thanks in advance for your help.
> Ok, this had been 5 hours for today I cannot do this forever, the
> program was sleeping, now I must go to sleep :-/

To rule out any kdevelop problems, start gdb from the command line.
gdb digikam
If you want to set a breakpoint in an image plugin, start the program
r(un)
and press Ctrl-C in gdb when is has started, then set your breakpoint
br(eak) 'DigikamWhateverNamespace::SomeClass::myMethod(...)'
Note the single quotes. There is tab autocompletion, usable at least for the
method parameters.
Then continue the program, and start your plugin
cont(inue)
I do not know if enable-debug=full sets -O0, if it is -O2 single stepping is
not so much reliable (sometimes strange line numbers and so on).
I usually do 90% of my debugging with debug statements because I consider
running gdb as a bit cumbersome (perhaps because of me not using Kdevelop).

Marcel

>
> peter
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Peter Heckert]

Hello Marcel & Gilles,

Marcel Wiesweg wrote:
>> Thank you very much.
>> I did this and first had the same behavior.
>> However after about 10 minutes the program was alive again and it
>> stopped again at the breakpoint.
>>
> I do not know if enable-debug=full sets -O0, if it is -O2 single stepping is
> not so much reliable (sometimes strange line numbers and so on).
> I usually do 90% of my debugging with debug statements because I consider
> running gdb as a bit cumbersome (perhaps because of me not using Kdevelop).

I know about these problems, however my expierience comes from Symantec
C++ and is older than 15 years ;-)
In this case it should still be possible to step into assembly code, and
so this wouldnt confuse me.

Anyway, I want to use kdevelop, because visual debugging is very useful
for me especially when unknown objects and inheritance hierarchies come
into play. It is much easier to follow program flow and to examine
unknown code.

Mainly I want to examine (and possibly modify) variables in my own
plugin while the program runs.

The above mentioned delay happens only on the first invocation, when I
restart kdevelop then it doesnt happen again.

When I rebuild the whole project then it happens again, there is a delay
of more than 10 minutes and the system monitor shows 100% cpu load
during the delay period.

I have found out that the execution pointer is after the very first
"new" invocation when the delay is over.

The code:


Breakpoint here--->    int w = (int)((m_radius + m_lookahead + m_damping
+ m_phase) * 4.0 + 40.0);

     // NOTE: commented from original implementation
     // if (radius < m_lookahead) w = m_lookahead * 4.0 + 40.0;

     float csmooth = m_csmooth;

     // Raw Filter preview

     if (csmooth >= 0.99) csmooth = 1.0;

     // Allocate and init buffers

Delay happens, when this line is invoked:
     uchar *src    = new uchar[ QMAX (width, height) * bytes ];
(This should allocate about some kilobytes of data only)
Execution pointer is here (**), when delay is over.
Afterwards everything is ok and program and debugger is working fine.

**->uchar *dest   = new uchar[ QMAX (width, height) * bytes ];
     float *data   = new float[ QMAX (width, height) + 2*w ];
     float *data2  = new float[ QMAX (width, height) + 2*w ];

So I believe, that some profiler or other (valgrind?) initialization
causes the delay.

Is there an easy way to disable this?

When I developed the gimp plugin, I had a compile-test turnaround time
of 15 seconds only ;-) (I did not need to restart gimp when the plugin
was recompiled)

I belive, this would not be possible here, but I appreciate the new
possibilities that kdevelop and gdb will give to me.

peter


_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-2]

Le Mercredi 5 Avril 2006 23:03, Peter Heckert a écrit :

> Hello Marcel & Gilles,
>
> Marcel Wiesweg wrote:
> >> Thank you very much.
> >> I did this and first had the same behavior.
> >> However after about 10 minutes the program was alive again and it
> >> stopped again at the breakpoint.
> >
> > I do not know if enable-debug=full sets -O0, if it is -O2 single stepping
> > is not so much reliable (sometimes strange line numbers and so on). I
> > usually do 90% of my debugging with debug statements because I consider
> > running gdb as a bit cumbersome (perhaps because of me not using
> > Kdevelop).
>
> I know about these problems, however my expierience comes from Symantec
> C++ and is older than 15 years ;-)
> In this case it should still be possible to step into assembly code, and
> so this wouldnt confuse me.
>
> Anyway, I want to use kdevelop, because visual debugging is very useful
> for me especially when unknown objects and inheritance hierarchies come
> into play. It is much easier to follow program flow and to examine
> unknown code.
>
> Mainly I want to examine (and possibly modify) variables in my own
> plugin while the program runs.
>
> The above mentioned delay happens only on the first invocation, when I
> restart kdevelop then it doesnt happen again.
>
> When I rebuild the whole project then it happens again, there is a delay
> of more than 10 minutes and the system monitor shows 100% cpu load
> during the delay period.
>
> I have found out that the execution pointer is after the very first
> "new" invocation when the delay is over.
>
> The code:
>
>
> Breakpoint here--->    int w = (int)((m_radius + m_lookahead + m_damping
> + m_phase) * 4.0 + 40.0);
>
>      // NOTE: commented from original implementation
>      // if (radius < m_lookahead) w = m_lookahead * 4.0 + 40.0;
>
>      float csmooth = m_csmooth;
>
>      // Raw Filter preview
>
>      if (csmooth >= 0.99) csmooth = 1.0;
>
>      // Allocate and init buffers
>
> Delay happens, when this line is invoked:
>      uchar *src    = new uchar[ QMAX (width, height) * bytes ];
> (This should allocate about some kilobytes of data only)
> Execution pointer is here (**), when delay is over.
> Afterwards everything is ok and program and debugger is working fine.
>
> **->uchar *dest   = new uchar[ QMAX (width, height) * bytes ];
>      float *data   = new float[ QMAX (width, height) + 2*w ];
>      float *data2  = new float[ QMAX (width, height) + 2*w ];
>
> So I believe, that some profiler or other (valgrind?) initialization
> causes the delay.
>
> Is there an easy way to disable this?
>
> When I developed the gimp plugin, I had a compile-test turnaround time
> of 15 seconds only ;-) (I did not need to restart gimp when the plugin
> was recompiled)
>
> I belive, this would not be possible here, but I appreciate the new
> possibilities that kdevelop and gdb will give to me.
>
> peter
>

I cannot reproduce this problem here.

When kdevelop is frozen, have you any messages from embedded gdb console. And
if you start kdevelop from a console, have you any error messages ?

Witch kdevelop version you use. Here i'm under Mandriva 2006 using Kdevelop
3.2.2

Other infos :

[dany@localhost test]$ gdb --version
GNU gdb 6.3-5mdk (Mandriva Linux release 2006.0)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-mandriva-linux-gnu".
[dany@localhost test]$
[dany@localhost test]$ gcc --version
gcc (GCC) 4.0.1 (4.0.1-5mdk for Mandriva Linux release 2006.0)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[dany@localhost test]$

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Peter Heckert]

Gilles Caulier wrote:
> I cannot reproduce this problem here.
>
> When kdevelop is frozen, have you any messages from embedded gdb console. And
> if you start kdevelop from a console, have you any error messages ?
>
> Witch kdevelop version you use. Here i'm under Mandriva 2006 using Kdevelop
> 3.2.2
>
I get these messages in console:

i = 4, currDir = , currFile = noisereduction
i = 5, currDir = , currFile =
ERROR: syntax error
ASSERT: "dataType == typeName" in
/tmp/buildd/kdevelop3-3.3.1/./languages/cpp/debugger/gdbparser.cpp (117)
ASSERT: "dataType == typeName" in
/tmp/buildd/kdevelop3-3.3.1/./languages/cpp/debugger/gdbparser.cpp (117)

Versions:
==================================
peter@KanotixBox:~/graphics/digikamimageplugins$ kdevelop3 --version
Qt: 3.3.6
KDE: 3.5.2
KDevelop: 3.3.1

I invoke KDevelop this way per menu:
kdevelop3 --profile KDECppIDE %u

My system is kanotix (debian for dummies :), I did a dist-upgrade

peter@KanotixBox:~/graphics/digikamimageplugins$ gcc --version
gcc (GCC) 4.0.3 (Debian 4.0.3-1)

peter@KanotixBox:~/graphics/digikamimageplugins$ gdb --version

GNU gdb 6.4-debian
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu".

--
peter


_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-2]

Le Jeudi 6 Avril 2006 00:02, Peter Heckert a écrit :

> Gilles Caulier wrote:
> > I cannot reproduce this problem here.
> >
> > When kdevelop is frozen, have you any messages from embedded gdb console.
> > And if you start kdevelop from a console, have you any error messages ?
> >
> > Witch kdevelop version you use. Here i'm under Mandriva 2006 using
> > Kdevelop 3.2.2
>
> I get these messages in console:
>
> i = 4, currDir = , currFile = noisereduction
> i = 5, currDir = , currFile =
> ERROR: syntax error
> ASSERT: "dataType == typeName" in
> /tmp/buildd/kdevelop3-3.3.1/./languages/cpp/debugger/gdbparser.cpp (117)
> ASSERT: "dataType == typeName" in
> /tmp/buildd/kdevelop3-3.3.1/./languages/cpp/debugger/gdbparser.cpp (117)

Strange. I recommend you to update to Kdevelop 3.2.2 version.

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Peter Heckert]

Gilles Caulier wrote:
> Le Jeudi 6 Avril 2006 00:02, Peter Heckert a écrit :
>> Gilles Caulier wrote:
>>> I cannot reproduce this problem here.
>>>
>>> When kdevelop is frozen, have you any messages from embedded gdb console.
>>> And if you start kdevelop from a console, have you any error messages ?

It is not kdevelop that freezes, it is the digikam app that freezes.
When this happens, then it is gdb that consumes 100% cpu time.

It happens only, when I singlestep over the very first invokation of "new".

> Strange. I recommend you to update to Kdevelop 3.2.2 version.
>
I believe, it is a misbehaviour of gdb.
It doesnt happen, when I set the first breakpoint behind the first "new"
invocation.

So I wrote a dummy "new" invokation

   uchar *test = new uchar[0];

at the very beginning of my routine and this avoids the problem. (So I
have my first memory leak *g*.

(possibly I could see the reason for the problem when debugging assembly
code, but I dont know how to do this in gdb)

Anyway, I can avoid the problem and I am up and running now.

peter


_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel