Re: Debug messages

[Thomas Lübking]

On Donnerstag, 12. Dezember 2013 22:40:25 CEST, Luis Felipe Dominguez Vega 

Thomas Lübking i just do that, but the file never write to the  path that i > write in kdebugdialog. 


Ok, looking at it - akonadi has like a bazillion entries there and you'd likely 
have to alter all of them and for all 4 levels (iow, my suggestion isn't 
actually sound usable for the specific akonadi case unless you precisely know 
what debug info to catch, sorry)

Cheers,
Thomas


Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Debug messages

[Luis Felipe Dominguez Vega]

Ye wuau, restarting Akonadi from shell was my solution, thanks 
Kevin Krammer and all other people from this Community (well is the most active 
comunnity that i known) Thomas Lübking i just do that, but the file never 
write to the path that i write in kdebugdialog. 

- Mensaje original -

De: "Thomas Lübking"  
Para: kde-devel@kde.org 
Enviados: Jueves, 12 de Diciembre 2013 16:03:24 
Asunto: Re: Debug messages 

Am Donnerstag, 12. Dezember 2013 schrieb Kevin Krammer < kram...@kde.org >: 
> 
> That will get all Akonadi output, including that of resources, in that shell. 
> You can then use kdebugdialog to turn on/off whatever you want. 

or you run "kdebugdialog --fullmode" and log messages to a dedicated file which 
you then also can just tail -f in case. 

Cheers, 
Thomas 

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << 



III Escuela Internacional de Invierno en la UCI del 17 al 28 de febrero del 
2014. Ver www.uci.cu


>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Nepomuk in 4.13 and beyond

[Ignacio Serantes]

On Thu, Dec 12, 2013 at 9:01 PM, Alexander Neundorf wrote:

> On Thursday 12 December 2013, Ignacio Serantes wrote:
> > Welcome Baloo,
> >
> > New suggestions about development direction to avoid some problems
> related
> > to Nepomuk:
> >
> > 1) Baloo must work as a service to share information with other users and
> > minimize resources consumption. With Nepomuk a login is required and in
> > multiuser environment this is a problem.
> > 2) Data must be stored in one repository to improve information sharing
> > with other users in the same or other computers.
>
> Sharing information between users opens the door for security issues.
> If it should be running as a service, I'm quite sure some kind of login or
> authentication will always be required. And you will need access
> permissions
> and manage them. Or am I missing something ?
>

For login I'm meaning KDE user login :). Obviously a security layer must be
implemented and as Activities past requirement was encrypted data, one of
the problems with Nepomuk, I'm assuming security will be implemented so you
could encrypt your data if you like. Maybe I'm wrong :/.


>
> > 3) Remote installation will be a good solution in cases you have several,
> > with mixed OS or old, computers in your home or your office because some
> > users prefer sharing data over speed. With cheap cloud computing have an
> > own server running some services will be more common (owncloud, mpd,
> > quassel, etc...) so considering this for the future would be great.
>
> This changes the security issues from local exploits to remote exploits.
> Are
> you sure we want to go that way, if the plan is to make things simpler ?
>
>
In my case yes, I can't speak for others :). I'm currently using Nepomuk to
store music and media metadata and I would like the share this information
with my family and my several computers and there is no plans to index
documents.



> Alex
>



-- 
Best wishes,
Ignacio

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Debug messages

[Thomas Lübking]

Am Donnerstag, 12. Dezember 2013 schrieb Kevin Krammer :
>
> That will get all Akonadi output, including that of resources, in that
shell.
> You can then use kdebugdialog to turn on/off whatever you want.

or you run "kdebugdialog --fullmode" and log messages to a dedicated file
which you then also can just tail -f in case.

Cheers,
Thomas

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Debug messages

[Kevin Krammer]

On Wednesday, 2013-12-11, 11:12:51, Luis Felipe Dominguez Vega wrote:
> How I can see the "kDebug()" Messages from an Akonadi Resource Plugin???

The best way to get log output from Akonadi processes it to restart Akonadi 
from a shell/terminal.

akonadictl restart

That will get all Akonadi output, including that of resources, in that shell. 
You can then use kdebugdialog to turn on/off whatever you want.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Dissertation project

[Kevin Krammer]

Hi,

On Tuesday, 2013-12-10, 22:03:29, Ovidiu-Florin Bogdan wrote:
> Hello world,
> 
> Me and my fiancée are students for a masters degree in Software Engineering
> and we need to find projects for our dissertations.
> 
> We really want our projects to be something useful and to be a part of KDE.

Very cool!

> We were thinking of a few things and would like your feedback on them on if
> and how can this be achieved.
> 
> 
>- KDE Connect: seamless file browsing on android device (using Dolphin);
>SMS integration with Telepathy, to be able to respond and view the
> message thread; Answer and make phone calls (through Telepathy, maybe);
> Contacts integration with Akonadi for the above two.
>- Akregator: Integration with Akonadi; A plugin to connect and sync with
>feedly: feeds synced across devices, search for new feeds, categories,
>tags, etc.

Akonadi porting is already being worked on, not sure how far it is though. No 
synching as far as I know.

>- Akonadi: better contact integration: see if mail sender is online for
>chat and start chat, send email to the person chatting with (Kmail and
>Telepathy).

That is basically ready, called KPeople. 

In general I am not sure if either of those ideas would qualify for a master 
thesis work, but that will of course depend on what the university expects.

Speaking as a PIM developer we would of course love to have someone work on 
PIM stuff and PIM data and user interfaces in general make good research 
material :)

I would suggest you also ask on the kde-pim mailinglist so you can get 
feedback by more developers from that area.

> I have some experience with KDE development, I've looked over the code of a
> few applications and made a few pull requests, so I know a few things on
> how part of KDE works, but I still need some guidance. Mostly I've only
> done translations and support.

That shouldn't be a problem. Aside from help being available on mailinglists, 
quite some projects have people who are experienced mentors.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Nepomuk in 4.13 and beyond

[Alexander Neundorf]

On Thursday 12 December 2013, Ignacio Serantes wrote:
> Welcome Baloo,
> 
> New suggestions about development direction to avoid some problems related
> to Nepomuk:
> 
> 1) Baloo must work as a service to share information with other users and
> minimize resources consumption. With Nepomuk a login is required and in
> multiuser environment this is a problem.
> 2) Data must be stored in one repository to improve information sharing
> with other users in the same or other computers.

Sharing information between users opens the door for security issues.
If it should be running as a service, I'm quite sure some kind of login or 
authentication will always be required. And you will need access permissions 
and manage them. Or am I missing something ?

> 3) Remote installation will be a good solution in cases you have several,
> with mixed OS or old, computers in your home or your office because some
> users prefer sharing data over speed. With cheap cloud computing have an
> own server running some services will be more common (owncloud, mpd,
> quassel, etc...) so considering this for the future would be great.

This changes the security issues from local exploits to remote exploits. Are 
you sure we want to go that way, if the plan is to make things simpler ?

Alex

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Problems when Compiling Muon

[Aleix Pol]

On Thu, Dec 12, 2013 at 2:51 AM, Volkan Gezer  wrote:

> Hello,
>
> I am trying to compile muon from source, but I am receiving the following
> error:
>
>
> /home/volkan/Belgeler/muon/b/libmuon/backends/ApplicationBackend/../../../../libmuon/backends/ApplicationBackend/Application.h:56:13:
> error: invalid covariant return type for ‘virtual QString
> Application::categories()’
>  QString categories();
>  ^
> In file included from
>
> /home/volkan/Belgeler/muon/b/libmuon/backends/ApplicationBackend/../../../../libmuon/backends/ApplicationBackend/Application.h:34:0,
>  from
>
> /home/volkan/Belgeler/muon/b/libmuon/backends/ApplicationBackend/moc_Application.cpp:10,
>  from
>
> /home/volkan/Belgeler/muon/b/libmuon/backends/ApplicationBackend/muon-appsbackend_automoc.cpp:8:
> /home/volkan/Belgeler/muon/libmuon/resources/AbstractResource.h:115:29:
> error:   overriding ‘virtual QStringList
> AbstractResource::categories()’
>  virtual QStringList categories() = 0;
>  ^
> make[2]: ***
> [libmuon/backends/ApplicationBackend/CMakeFiles/muon-appsbackend.dir/muon-appsbackend_automoc.o]
> Error 1
> make[1]: ***
> [libmuon/backends/ApplicationBackend/CMakeFiles/muon-appsbackend.dir/all]
> Error 2
>
>
> What do you think the problem is? (I have libbodega0 libbodega-dev
> bodega-client, but still the last warning is there)
>
>
> -
> -- The following external packages were located on your system.
> -- This installation will have the extra features provided by these
> packages.
>
> -
>* LibQApt - Qt wrapper around the libapt-pkg library
>* LibAttica - Qt library that implements the Open Collaboration
> Services API
>* PackageKitQt2 - Library that exposes PackageKit resources
>
>
> -
> -- The following OPTIONAL packages could NOT be located on your system.
> -- Consider installing them to enable more features from this software.
>
> -
>* Bodega  
>  Library that exposes Bodega resources
>  Required to build the Bodega backend
>
>
> -
>
> Thank you,
>
> Best regards,
> Volkan GEZER
> volkange...@gmail.com
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> unsubscribe <<
>

Hi Volkan,
I just pushed a fix for this.

Thanks for notifying!
Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Problem with KCompTreeNode on Windows (or: destruction order of static objects?)

[Kevin Funk]

Am Donnerstag, 12. Dezember 2013, 11:27:07 schrieb Frank Reininghaus:
> Hi,
> 
> 2013/12/11 Kevin Funk:
> [...]
> 
> >> > > Just using K_GLOBAL_STATIC for the KZoneAllocator instance doesn't
> >> > > help
> >> > > either. I get the same destruction order + crash with that on
> >> > > Windows.
> >> > > 
> >> > > Dynamic allocation inside KCompTreeNode doesn't work either, because
> >> > > KZoneAllocator needs to be there *before* the first KCompTreeNode is
> >> > > created and needs to there *until* the last one has been destroyed.
> >> > > 
> >> > > Any ideas?
> >> > 
> >> > Well, here is one idea (untested): use a
> >> > QSharedPointer to ensure that the KZoneAllocator is
> >> > not destroyed before the last KCompletion instance using it.
> >> > 
> >> > Replace
> >> > 
> >> > static KZoneAllocator alloc;
> >> > 
> >> > in KCompTreeNode by
> >> > 
> >> > static QSharedPointer alloc;
> >> > 
> >> > and, in kcompletion.cpp,
> >> > 
> >> > KZoneAllocator KCompTreeNode::alloc(8192);
> >> > 
> >> > by
> >> > 
> >> > QSharedPointer KCompTreeNode::alloc;
> >> > 
> >> > In KCompTreeNode's operator new/delete, replace "alloc." by "alloc->".
> >> > 
> >> > Furthermore, add a QSharedPointer member to
> >> > KCompletionPrivate. In KCompletionPrivate's constructor, first check
> >> > if KCompTreeNode::alloc isNull(), initialize it if that is not the
> >> > case, and then copy "alloc" to the new member.
> >> > 
> >> > I think that this might work, and it might also improve application
> >> > start-up time because the KZoneAllocator would only be initialized on
> >> > first use of a KCompletion object.
> > 
> > Hey Frank,
> > 
> > thanks a lot for sharing your thoughts!
> > 
> > I just tried your suggestion, and it indeed fixes the issue on Windows
> > (and
> > doesn't cause havoc on Linux either). See attached patch (v1). I think it
> > pretty much resembles your thoughts.
> 
> great, I'm glad to hear that! I'd recommend to remove the unrelated
> changes in KZoneAllocator though - they just make the patches harder
> to understand.

Unfortunately it's not really unrelated -- When using qDebug() in 
~KZoneAllocator, that sometimes seems to crash in deep inside Qt 
(QTextCodec/QIconvCodec) during __cxa_finalize. Apparently it is too late to 
call qDebug() at this point.

(Reduced) Backtrace:
#0  malloc_consolidate (av=av@entry=0x76061740 ) at 
malloc.c:4088
#1  0x75d210e1 in _int_malloc (av=0x76061740 , 
bytes=32640) at malloc.c:3379
#2  0x75d234d0 in __GI___libc_malloc (bytes=32640) at malloc.c:2859
#3  0x75cc2b19 in __gconv_open (toset=0x44db30 "\002", 
toset@entry=0x7fffd660 "//", fromset=0x7fff , fromset@entry=0x7fffd640 "UTF-16//", han
dle=handle@entry=0x7fffd680, flags=flags@entry=0) at gconv_open.c:283
(and further:)
#4  0x75cc24a1 in iconv_open
#5  0x774703b2 in QIconvCodec::createIconv_t
#6  0x7746fd13 in QIconvCodec::convertFromUnicode
#7  0x77469aa7 in QTextCodec::fromUnicode
#8  0x77346b24 in QString::toLocal8Bit
#9  0x776a10ac in QDebug::~QDebug
#10 0x777da9f6 in KZoneAllocator::~KZoneAllocator
#11 0x77b82e48 in 
QtSharedPointer::ExternalRefCount::deref

> > However, I'm not quite sure this approach is going to be accepted
> > upstream.
> > One issue, for example, is that KCompTreeNode now has a publicly
> > accessible
> > static KZoneAllocator* member and explicitly setting the allocator from
> > within KCompletion seems odd. That completely makes KCompTreeNode(s)
> > depend on KCompletion.
> > 
> > I'm proposing another approach:
> > - Still using QSharedPointer
> > - But: Initialize this shared-pointer directly (as with the static KZA
> > member) - And: Keep a strong-ref in KCompletion on that shared pointer
> > See attached patch (v2)
> > 
> > Any objections? Otherwise I'll post that patch to reviewboard ASAP.
> 
> well, I guess it might be considered a matter of taste. The reason why
> I find v1 slightly better is that the initialization of the custom
> allocator is deferred until it is really needed. Right now, the
> KZoneAllocator constructor will be called on startup for every
> application that links to kdeui.
> 
> BTW, I found the discussion about the introduction of KZoneAllocator
> in KCompletion:
> 
> http://lists.kde.org/?t=10154882781&r=1&w=2
> 
> The author claims that
> 
> "A changed kcompletiontest which just add a big number of strings in
> different ways, and clears the completion object in between showed more
> than a double speedup (from 4950 to 2100 msec)"
> 
> However, it seems that this "changed" test is not provided, and
> moreover, the patch changes a lot more than just the allocator, so
> there is no way to know which part of the saving is due to which
> change. IMHO, two good reasons why this patch should not have been
> committed without further discussions, but I guess that my objection
> is more than 11 years too late ;-)
> 
> (BTW, if I wrote a custom allocato

Re: Nepomuk in 4.13 and beyond

[Ignacio Serantes]

Welcome Baloo,

New suggestions about development direction to avoid some problems related
to Nepomuk:

1) Baloo must work as a service to share information with other users and
minimize resources consumption. With Nepomuk a login is required and in
multiuser environment this is a problem.
2) Data must be stored in one repository to improve information sharing
with other users in the same or other computers.
3) Remote installation will be a good solution in cases you have several,
with mixed OS or old, computers in your home or your office because some
users prefer sharing data over speed. With cheap cloud computing have an
own server running some services will be more common (owncloud, mpd,
quassel, etc...) so considering this for the future would be great.
4) Baloo and Milou must compile and work without Akonadi.



On Thu, Dec 12, 2013 at 11:46 AM, Vishesh Handa  wrote:

>  Hey everyone
>
>
>
> During the KDE 4.11 cycle Nepomuk reached a maturity level that we were
> happy
>
> with, it is reasonably fast, stable, and unless used together with Akonadi
> it
>
> is no longer the "CPU consumer" it was before. We reached this state after
>
> years of analyzing what was wrong and what could be improved to the point
>
> where we no longer think any more improvement is possible only by
> modifying
>
> our code.
>
>
>
> The next place where we could seek improvement was the RDF storage. We
> have
>
> been using Virtuoso for about 4 years and it's been a game changer for us
>
> performing way faster than any other of the alternatives we ever used
> before
>
> and more efficiently, but as many of you know (and others suffer) it is
> not a RDF
>
> storage designed for the desktop and it will never be. Since nothing
> better
>
> than Virtuoso exists for our use-case, we started to implement our own RDF
> storage mechanism (codenamed Vishuoso).
>
>
>
> At some point during that progress we took a step back and re-analyzed the
>
> problems of the workspace and the current implementation. The problems are
> -
>
>
>
> - Resource Description Framework (RDF)
>
> The biggest problem with RDF is that it raises the knowledge needed to
>
> contribute to a point where most developers decide to to skip it. After
> all
>
> these years only a handful of brave developers have worked with it and the
>
> experience hasn't been good.
>
>
>
> Then we need something easier to use so we can see a more broad adoption.
>
>
>
> Additionally, RDF is a very flexible way to store data, it is however not
> the
>
> most efficient way. Data is generally completely normalized even though it
> is
>
> quite often not required. Eg - One doesn't need to store music file
> artists as
>
> a separate contact. This is great, from a theoretical point of view, but
> it is
>
> not very useful in practice.
>
>
>
> - RDF Storage
>
> There is no existing RDF storage designed to work in a Desktop. Virtuoso
> is
>
> great but it quickly uses hundreds of megabytes of ram and it has its own
>
> share of problems. The other alternative is tracker, but they lack certain
>
> features required in Nepomuk.
>
>
>
> - Data duplication
>
> Nepomuk has been used as both a search store and a data store. This
> results in
>
> massive data duplication and synchronization problems. In the case of
> Akonadi,
>
> emails are stored in Akonadi and are then duplicated in virtuoso, and are
> then
>
> duplicated in virtuoso's index. Every time data is changed in Akonadi it
> has
>
> to be updated in Nepomuk and vice-versa. This results in a process being
>
> responsible just for synchronizing the two stores.
>
>
>
> - API Duplication
>
> With the data residing in both Nepomuk and other stores
> (Akonadi/Files/etc),
>
> it isn't always clear which store it should be accessed from. This
> essentially
>
> results in duplication of APIs. Eg - Using KABC vs accessing contacts from
>
> Nepomuk.
>
>
>
> These problems would still exist even if we had the fastest and most
> efficient
>
> RDF storage in the world.
>
>
>
> At this point it was clear to us that the future was not going to be RDF.
> The
>
> next thing we did was to analyze our actual needs based on the last 5
> years of
>
> Nepomuk.
>
>
>
> Our needs are -
>
> * Full text index for searching
>
> * Data store for simple objects such as tags / ratings / activities / etc
>
> * Relations - Forming relations between different objects. Eg - This
> "file" is
>
> related to this "activity" or "person".
>
>  Each of these problems is independently solvable without RDF.
>
>
>
> About 2 months ago we started to draft Baloo [1], a metadata solution that
>
> will cover the bare necessities of each use case we have.
>
>
>
> I'd like to avoid getting into the technical details of the implementation
> in
>
> this thread. Another thread can be started about its different aspects
> once
>
> you've read the basic ideas behind Baloo [2]
>
>
>
> Current Plans
>
> -
>
>
>
> After a month of designing the solution and a month of im

Nepomuk in 4.13 and beyond

[Vishesh Handa]

Hey everyone

During the KDE 4.11 cycle Nepomuk reached a maturity level that we were 
happy 
with, it is reasonably fast, stable, and unless used together with Akonadi it 
is no longer the "CPU consumer" it was before. We reached this state after 
years of analyzing what was wrong and what could be improved to the 
point 
where we no longer think any more improvement is possible only by 
modifying 
our code.

The next place where we could seek improvement was the RDF storage. We 
have 
been using Virtuoso for about 4 years and it's been a game changer for us 
performing way faster than any other of the alternatives we ever used 
before 
and more efficiently, but as many of you know (and others suffer) it is not a 
RDF 
storage designed for the desktop and it will never be. Since nothing better 
than Virtuoso exists for our use-case, we started to implement our own 
RDF storage mechanism (codenamed Vishuoso).

At some point during that progress we took a step back and re-analyzed 
the 
problems of the workspace and the current implementation. The problems 
are -

- Resource Description Framework (RDF)
The biggest problem with RDF is that it raises the knowledge needed to 
contribute to a point where most developers decide to to skip it. After all 
these years only a handful of brave developers have worked with it and the 
experience hasn't been good.

Then we need something easier to use so we can see a more broad 
adoption.

Additionally, RDF is a very flexible way to store data, it is however not the 
most efficient way. Data is generally completely normalized even though it 
is 
quite often not required. Eg - One doesn't need to store music file artists 
as 
a separate contact. This is great, from a theoretical point of view, but it is 
not very useful in practice.

- RDF Storage
There is no existing RDF storage designed to work in a Desktop. Virtuoso 
is 
great but it quickly uses hundreds of megabytes of ram and it has its own 
share of problems. The other alternative is tracker, but they lack certain 
features required in Nepomuk.

- Data duplication
Nepomuk has been used as both a search store and a data store. This 
results in 
massive data duplication and synchronization problems. In the case of 
Akonadi, 
emails are stored in Akonadi and are then duplicated in virtuoso, and are 
then 
duplicated in virtuoso's index. Every time data is changed in Akonadi it has 
to be updated in Nepomuk and vice-versa. This results in a process being 
responsible just for synchronizing the two stores.

- API Duplication
With the data residing in both Nepomuk and other stores 
(Akonadi/Files/etc), 
it isn't always clear which store it should be accessed from. This 
essentially 
results in duplication of APIs. Eg - Using KABC vs accessing contacts from 
Nepomuk.

These problems would still exist even if we had the fastest and most 
efficient 
RDF storage in the world.

At this point it was clear to us that the future was not going to be RDF. The 
next thing we did was to analyze our actual needs based on the last 5 
years of 
Nepomuk.

Our needs are -
* Full text index for searching
* Data store for simple objects such as tags / ratings / activities / etc
* Relations - Forming relations between different objects. Eg - This "file" is 
related to this "activity" or "person".
 
Each of these problems is independently solvable without RDF.

About 2 months ago we started to draft Baloo [1], a metadata solution 
that 
will cover the bare necessities of each use case we have. 

I'd like to avoid getting into the technical details of the implementation in 
this thread. Another thread can be started about its different aspects 
once 
you've read the basic ideas behind Baloo [2]

Current Plans
-

After a month of designing the solution and a month of implementing it, 
Baloo 
is working way better than Nepomuk does. So, I'd like to switch to Baloo by 
default in 4.13, while keeping Nepomuk in maintenance mode for more 
conservative distributions.

This is not a completely new project as large parts of Baloo code are 
derived from Nepomuk and therefore comes with years of testing and real 
world use.
 
Baloo was also discussed in PIM Sprint and the PIM developers are happy 
to 
completely drop Nepomuk support for 4.13 and move to Baloo. Similarly, 
the 
telepathy developers are also working on moving KPeople away from 
Nepomuk.

Migration - There will be an automated migration mechanism for migrating 
tags, 
ratings and comments from Nepomuk to Baloo.

Trying it out?
---

Developers are welcome to try out Baloo and have a look at the current 
source 
code. It's a still a work in progress, but we strongly feel that it is a step 
in the right direction.

I'd recommend using Milou [3] for searching.

-- 
Vishesh Handa

[1] https://projects.kde.org/projects/playground/base/baloo
[2] http://techbase.kde.org/Projects/Baloo
[3] https://projects.kde.org/projects/playground/base/milou

>> Visit http:/

Re: Problem with KCompTreeNode on Windows (or: destruction order of static objects?)

[Frank Reininghaus]

Hi,

2013/12/11 Kevin Funk:
[...]
>> > > Just using K_GLOBAL_STATIC for the KZoneAllocator instance doesn't help
>> > > either. I get the same destruction order + crash with that on Windows.
>> > >
>> > > Dynamic allocation inside KCompTreeNode doesn't work either, because
>> > > KZoneAllocator needs to be there *before* the first KCompTreeNode is
>> > > created and needs to there *until* the last one has been destroyed.
>> > >
>> > > Any ideas?
>> >
>> > Well, here is one idea (untested): use a
>> > QSharedPointer to ensure that the KZoneAllocator is
>> > not destroyed before the last KCompletion instance using it.
>> >
>> > Replace
>> >
>> > static KZoneAllocator alloc;
>> >
>> > in KCompTreeNode by
>> >
>> > static QSharedPointer alloc;
>> >
>> > and, in kcompletion.cpp,
>> >
>> > KZoneAllocator KCompTreeNode::alloc(8192);
>> >
>> > by
>> >
>> > QSharedPointer KCompTreeNode::alloc;
>> >
>> > In KCompTreeNode's operator new/delete, replace "alloc." by "alloc->".
>> >
>> > Furthermore, add a QSharedPointer member to
>> > KCompletionPrivate. In KCompletionPrivate's constructor, first check
>> > if KCompTreeNode::alloc isNull(), initialize it if that is not the
>> > case, and then copy "alloc" to the new member.
>> >
>> > I think that this might work, and it might also improve application
>> > start-up time because the KZoneAllocator would only be initialized on
>> > first use of a KCompletion object.
>
> Hey Frank,
>
> thanks a lot for sharing your thoughts!
>
> I just tried your suggestion, and it indeed fixes the issue on Windows (and
> doesn't cause havoc on Linux either). See attached patch (v1). I think it
> pretty much resembles your thoughts.

great, I'm glad to hear that! I'd recommend to remove the unrelated
changes in KZoneAllocator though - they just make the patches harder
to understand.

> However, I'm not quite sure this approach is going to be accepted upstream.
> One issue, for example, is that KCompTreeNode now has a publicly accessible
> static KZoneAllocator* member and explicitly setting the allocator from within
> KCompletion seems odd. That completely makes KCompTreeNode(s) depend on
> KCompletion.
>
> I'm proposing another approach:
> - Still using QSharedPointer
> - But: Initialize this shared-pointer directly (as with the static KZA member)
> - And: Keep a strong-ref in KCompletion on that shared pointer
> See attached patch (v2)
>
> Any objections? Otherwise I'll post that patch to reviewboard ASAP.

well, I guess it might be considered a matter of taste. The reason why
I find v1 slightly better is that the initialization of the custom
allocator is deferred until it is really needed. Right now, the
KZoneAllocator constructor will be called on startup for every
application that links to kdeui.

BTW, I found the discussion about the introduction of KZoneAllocator
in KCompletion:

http://lists.kde.org/?t=10154882781&r=1&w=2

The author claims that

"A changed kcompletiontest which just add a big number of strings in
different ways, and clears the completion object in between showed more
than a double speedup (from 4950 to 2100 msec)"

However, it seems that this "changed" test is not provided, and
moreover, the patch changes a lot more than just the allocator, so
there is no way to know which part of the saving is due to which
change. IMHO, two good reasons why this patch should not have been
committed without further discussions, but I guess that my objection
is more than 11 years too late ;-)

(BTW, if I wrote a custom allocator for a class which always allocates
objects of the same size, I would try to make use of that in order to
get rid of all the overhead that is needed to keep track of the size
of the allocated blocks, but that's not the topic of this thread.)

Cheers,
Frank

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<