Re: fault finding/identification (pre-debugging?), a check to see if something is work in progress and begining widget development

2011-01-07 Thread oliverthered
On Saturday 08 Jan 2011 00:16:40 Thomas Lübking wrote: > > Can you actually confirm that the RAM hunger is distributed evenly among > your running applications ("top") and not everything is just sucked by > only one (X11?) process? > > Usually graphical stuff (including and good god esp. opengl)

Re: fault finding/identification (pre-debugging?), a check to see if something is work in progress and begining widget development

2011-01-07 Thread oliverthered
Ok I just had the issue happen again (well when it happens in a way that can't be recovered by closing down open windows) Basically there are some very odd graphics alignment glitches ctrl + shift + f12 and back again does fix the issue. I'm not getting anything random like memory issues and I

heads up, (an applogy with an explanation in advance of any 'rude' or 'crude'ness)

2011-01-07 Thread oliverthered
I posted a bit of a heads up some time back, but I'll just go over it a bit, since three have been a few developments since then. Basicaly I have Asperger's, which means that I'm shy (well used to be) and sensitive (but thick skined!). But I also have some 'lauguage' difficulties, in that I find

Re: fault finding/identification (pre-debugging?), a check to see if something is work in progress and begining widget development

2011-01-07 Thread Oliver Stieber
Ok Thanks, I'll take a look at that I've got 6GB of system ram, haven't noticed any strange behaviour memory wise, except sometimes I've seen a lot of kernel wait time when I'm doing disk access maxing out one core at 100%. I'm running 64bit where available and haven't seen high memory load on an

Re: fault finding/identification (pre-debugging?), a check to see if something is work in progress and begining widget development

2011-01-07 Thread Thomas Lübking
Am Friday 07 January 2011 schrieb oliverthered: > I'm getting an issue what appears to be GPU memory issues, specifically the > memory seems to be getting eaten up quite quickly even though I've got > loads of system ram and not a huge number of application windows or apps > running. I belive my gr

Re: fault finding/identification (pre-debugging?), a check to see if something is work in progress and begining widget development

2011-01-07 Thread oliverthered
Well the first thing on my list I've managed to solve quite quickly as it turned out in the end. I ran strigidaemon from konsole and it reported Resource temporarily unavailable strigi.daemon: Daemon cannot run: the file /home/oliverthered/.strigi/lock is locked. (this was even though strigi

fault finding/identification (pre-debugging?), a check to see if something is work in progress and begining widget development

2011-01-07 Thread oliverthered
Hi, This is a few in one, but I'll start with my first query and more on. I've had a few issues which may or may not be related, but I'd like to find out about how to track down the problem a bit better, with the hope of either fixing it myself (or working around) or giving a much better bug re

Re: Errarous Release 4.5.5 today

2011-01-07 Thread Andrea Scarpino
On Friday 07 January 2011 19:58:26 Juergen Sauer wrote: > Ther was an Realeas annouced, but elementary problems in kdepim > are still allive and kdepim is totaly broken at the moment. > > The current problems summaries at this: > - instablility of akonadi until unusable broken, > due using default

Errarous Release 4.5.5 today

2011-01-07 Thread Juergen Sauer
Moin, how is it possible to go on further releasing due very important parts of kde are hangin far-far-far behind ? As I read on http://www.pro-linux.de/news/1/16566/kde-aktualisiert-produkte.html Ther was an Realeas annouced, but elementary problems in kdepim are still allive and kdepim is to

Re: How to make the build of kdelibs based on previous results

2011-01-07 Thread Jammy Zhou
Got it. Thanks, Andreas. Regards, Jammy On Fri, Jan 7, 2011 at 6:22 PM, Andreas Pakulat wrote: > On 07.01.11 17:51:29, Jammy Zhou wrote: > > OK, I see. So the %0, %1, ... for the second build is expected, right? > > Yes. If you additionally see "compiling x.cpp" between 0% and 1%, that > would

Re: How to make the build of kdelibs based on previous results

2011-01-07 Thread Andreas Pakulat
On 07.01.11 17:51:29, Jammy Zhou wrote: > OK, I see. So the %0, %1, ... for the second build is expected, right? Yes. If you additionally see "compiling x.cpp" between 0% and 1%, that would be unexpected, unless you've touched the corresponding files or the cmake-cache. Andreas -- This will be

Re: How to make the build of kdelibs based on previous results

2011-01-07 Thread Jammy Zhou
OK, I see. So the %0, %1, ... for the second build is expected, right? Thanks, Jammy On Fri, Jan 7, 2011 at 5:42 PM, Andreas Pakulat wrote: > On 07.01.11 17:34:15, Jammy Zhou wrote: > > Hi, > > > > I am building kdelibs on ARM platform, which may take quite long time. If > I > > terminate the b

Re: How to make the build of kdelibs based on previous results

2011-01-07 Thread Andreas Pakulat
On 07.01.11 17:34:15, Jammy Zhou wrote: > Hi, > > I am building kdelibs on ARM platform, which may take quite long time. If I > terminate the build at 50% for example, and then rebuild kdelibs by run > "make", it seems that the build happens from scratch again, which is quite > annoying. Do you kn

How to make the build of kdelibs based on previous results

2011-01-07 Thread Jammy Zhou
Hi, I am building kdelibs on ARM platform, which may take quite long time. If I terminate the build at 50% for example, and then rebuild kdelibs by run "make", it seems that the build happens from scratch again, which is quite annoying. Do you know how to make the second build based on previous bu