Re: Review Request 117902: Use PUBLIC and PRIVATE in target_link_libraries for the installed libs

[Vishesh Handa]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117902/#review57313
---

Ship it!


Sorry, I didn't notice.

- Vishesh Handa


On April 30, 2014, 2:03 p.m., Alexander Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117902/
> ---
> 
> (Updated April 30, 2014, 2:03 p.m.)
> 
> 
> Review request for Baloo.
> 
> 
> Repository: baloo
> 
> 
> Description
> ---
> 
> Use PUBLIC and PRIVATE in target_link_libraries for the installed libs
> 
> 
> Diffs
> -
> 
>   src/core/CMakeLists.txt f9f663b1c1ba4c84057e76da09903c7a7c53da45 
>   src/file/CMakeLists.txt 79a22551f0a8fa7475b69930c381057b42ca10fb 
>   src/file/autotest/CMakeLists.txt a476a8d273bf9674221868f1cf287cd100191c76 
>   src/file/extractor/CMakeLists.txt d8abe98c23b95440e0320b158f44cdca6428e7a6 
>   src/file/lib/CMakeLists.txt a432ebb17ba6b66065ade31240217020b2df2ba4 
>   src/file/lib/autotests/CMakeLists.txt 
> 9676c2e01c980ddb36c18a44ac1d8d08f862d1ea 
>   src/file/tests/CMakeLists.txt f8386ae735e3bbc24f51402e59d5fc701afddd8d 
>   src/pim/lib/CMakeLists.txt b57340872800ead1fcd224235b2f7b6f3f8ad172 
>   src/xapian/CMakeLists.txt 38a4b2ed08db52cc8e2bc1e09ad3290bb6122515 
> 
> Diff: https://git.reviewboard.kde.org/r/117902/diff/
> 
> 
> Testing
> ---
> 
> No longer need to find the private dependencies when building dolphin 
> (frameworks)
> 
> 
> Thanks,
> 
> Alexander Richardson
> 
>


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

Review Request 117996: Add an append(QByteArray) method to the ExtractionResult

[Vishesh Handa]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117996/
---

Review request for Baloo and Milian Wolff.


Repository: kfilemetadata


Description
---

Add an append(QByteArray) method to the ExtractionResult

This way plugins can choose to return the data in utf8 or as a QString,
and the clients can either just let the standard QString::fromUtf8
function do its magic, or implement some special handling if they wish.

This speeds up the PlainTextExtractor quite a bit (60msec vs 8.3msec)

Unfortunately, this meant discarding the extraction of WordCount from
the Plain Text extractor. Though considering the speed difference, I
think it is worth it.


Diffs
-

  autotests/indexerextractortests.cpp 6b7c605 
  autotests/simpleresult.h f3793b5 
  src/extractionresult.h 76dfe59 
  src/extractionresult.cpp 9bc7946 
  src/extractors/plaintextextractor.cpp 5a38857 

Diff: https://git.reviewboard.kde.org/r/117996/diff/


Testing
---


Thanks,

Vishesh Handa


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

Re: Review Request 117996: Add an append(QByteArray) method to the ExtractionResult

[Milian Wolff]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117996/#review57314
---


What is the speed difference compared to the old QString API, but without the 
word-count there? Afaik, the word-count is the major bottleneck and removing it 
alone should greatly speed up the test.

Having a QByteArray in the API would be fine if you document that the data 
_must_ be UTF8. But a meaningful performance test here must include the later 
conversion to std::string for xapian, imo. I.e. what you want to test is file 
-> qbytearray -> std::string vs. file -> qstring -> std::string.

- Milian Wolff


On May 5, 2014, 2:01 p.m., Vishesh Handa wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117996/
> ---
> 
> (Updated May 5, 2014, 2:01 p.m.)
> 
> 
> Review request for Baloo and Milian Wolff.
> 
> 
> Repository: kfilemetadata
> 
> 
> Description
> ---
> 
> Add an append(QByteArray) method to the ExtractionResult
> 
> This way plugins can choose to return the data in utf8 or as a QString,
> and the clients can either just let the standard QString::fromUtf8
> function do its magic, or implement some special handling if they wish.
> 
> This speeds up the PlainTextExtractor quite a bit (60msec vs 8.3msec)
> 
> Unfortunately, this meant discarding the extraction of WordCount from
> the Plain Text extractor. Though considering the speed difference, I
> think it is worth it.
> 
> 
> Diffs
> -
> 
>   autotests/indexerextractortests.cpp 6b7c605 
>   autotests/simpleresult.h f3793b5 
>   src/extractionresult.h 76dfe59 
>   src/extractionresult.cpp 9bc7946 
>   src/extractors/plaintextextractor.cpp 5a38857 
> 
> Diff: https://git.reviewboard.kde.org/r/117996/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Vishesh Handa
> 
>


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

Re: Review Request 117996: Add an append(QByteArray) method to the ExtractionResult

[Milian Wolff]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117996/#review57315
---



src/extractionresult.cpp


this is pure virtual in the header, no? 



src/extractors/plaintextextractor.cpp


both includes are not required anymore


- Milian Wolff


On May 5, 2014, 2:01 p.m., Vishesh Handa wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117996/
> ---
> 
> (Updated May 5, 2014, 2:01 p.m.)
> 
> 
> Review request for Baloo and Milian Wolff.
> 
> 
> Repository: kfilemetadata
> 
> 
> Description
> ---
> 
> Add an append(QByteArray) method to the ExtractionResult
> 
> This way plugins can choose to return the data in utf8 or as a QString,
> and the clients can either just let the standard QString::fromUtf8
> function do its magic, or implement some special handling if they wish.
> 
> This speeds up the PlainTextExtractor quite a bit (60msec vs 8.3msec)
> 
> Unfortunately, this meant discarding the extraction of WordCount from
> the Plain Text extractor. Though considering the speed difference, I
> think it is worth it.
> 
> 
> Diffs
> -
> 
>   autotests/indexerextractortests.cpp 6b7c605 
>   autotests/simpleresult.h f3793b5 
>   src/extractionresult.h 76dfe59 
>   src/extractionresult.cpp 9bc7946 
>   src/extractors/plaintextextractor.cpp 5a38857 
> 
> Diff: https://git.reviewboard.kde.org/r/117996/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Vishesh Handa
> 
>


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

Re: Review Request 117996: Add an append(QByteArray) method to the ExtractionResult

[Vishesh Handa]

> On May 5, 2014, 2:08 p.m., Milian Wolff wrote:
> > src/extractionresult.cpp, line 59
> > 
> >
> > this is pure virtual in the header, no?

Yeah. I had originally kept it as virtual instead of pure virtual, but clang 
complained that the overloaded virtual append(QString) was being hidden. I 
couldn't figure it out, so I made it a pure virtual.


- Vishesh


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117996/#review57315
---


On May 5, 2014, 2:01 p.m., Vishesh Handa wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117996/
> ---
> 
> (Updated May 5, 2014, 2:01 p.m.)
> 
> 
> Review request for Baloo and Milian Wolff.
> 
> 
> Repository: kfilemetadata
> 
> 
> Description
> ---
> 
> Add an append(QByteArray) method to the ExtractionResult
> 
> This way plugins can choose to return the data in utf8 or as a QString,
> and the clients can either just let the standard QString::fromUtf8
> function do its magic, or implement some special handling if they wish.
> 
> This speeds up the PlainTextExtractor quite a bit (60msec vs 8.3msec)
> 
> Unfortunately, this meant discarding the extraction of WordCount from
> the Plain Text extractor. Though considering the speed difference, I
> think it is worth it.
> 
> 
> Diffs
> -
> 
>   autotests/indexerextractortests.cpp 6b7c605 
>   autotests/simpleresult.h f3793b5 
>   src/extractionresult.h 76dfe59 
>   src/extractionresult.cpp 9bc7946 
>   src/extractors/plaintextextractor.cpp 5a38857 
> 
> Diff: https://git.reviewboard.kde.org/r/117996/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Vishesh Handa
> 
>


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

Re: Review Request 117996: Add an append(QByteArray) method to the ExtractionResult

[Vishesh Handa]

> On May 5, 2014, 2:05 p.m., Milian Wolff wrote:
> > What is the speed difference compared to the old QString API, but without 
> > the word-count there? Afaik, the word-count is the major bottleneck and 
> > removing it alone should greatly speed up the test.
> > 
> > Having a QByteArray in the API would be fine if you document that the data 
> > _must_ be UTF8. But a meaningful performance test here must include the 
> > later conversion to std::string for xapian, imo. I.e. what you want to test 
> > is file -> qbytearray -> std::string vs. file -> qstring -> std::string.

Original: 60 msecs
Without Word Count: 30 msecs
Without Word Count + ByteArray: 8 msecs


- Vishesh


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117996/#review57314
---


On May 5, 2014, 2:01 p.m., Vishesh Handa wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117996/
> ---
> 
> (Updated May 5, 2014, 2:01 p.m.)
> 
> 
> Review request for Baloo and Milian Wolff.
> 
> 
> Repository: kfilemetadata
> 
> 
> Description
> ---
> 
> Add an append(QByteArray) method to the ExtractionResult
> 
> This way plugins can choose to return the data in utf8 or as a QString,
> and the clients can either just let the standard QString::fromUtf8
> function do its magic, or implement some special handling if they wish.
> 
> This speeds up the PlainTextExtractor quite a bit (60msec vs 8.3msec)
> 
> Unfortunately, this meant discarding the extraction of WordCount from
> the Plain Text extractor. Though considering the speed difference, I
> think it is worth it.
> 
> 
> Diffs
> -
> 
>   autotests/indexerextractortests.cpp 6b7c605 
>   autotests/simpleresult.h f3793b5 
>   src/extractionresult.h 76dfe59 
>   src/extractionresult.cpp 9bc7946 
>   src/extractors/plaintextextractor.cpp 5a38857 
> 
> Diff: https://git.reviewboard.kde.org/r/117996/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Vishesh Handa
> 
>


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

Re: Review Request 117996: Add an append(QByteArray) method to the ExtractionResult

[Milian Wolff]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117996/#review57322
---



src/extractionresult.cpp


OK but then I don't get why you can compile this. You provide a definition 
of the pure-virtual declaration here, no? That's not going to compile, is it?

Generally, I'd say don't make it pure-virtual as you can provide a 
meaningful default-implementation here... Only for performance reasons would 
one want to reimplement it after all.


- Milian Wolff


On May 5, 2014, 2:01 p.m., Vishesh Handa wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117996/
> ---
> 
> (Updated May 5, 2014, 2:01 p.m.)
> 
> 
> Review request for Baloo and Milian Wolff.
> 
> 
> Repository: kfilemetadata
> 
> 
> Description
> ---
> 
> Add an append(QByteArray) method to the ExtractionResult
> 
> This way plugins can choose to return the data in utf8 or as a QString,
> and the clients can either just let the standard QString::fromUtf8
> function do its magic, or implement some special handling if they wish.
> 
> This speeds up the PlainTextExtractor quite a bit (60msec vs 8.3msec)
> 
> Unfortunately, this meant discarding the extraction of WordCount from
> the Plain Text extractor. Though considering the speed difference, I
> think it is worth it.
> 
> 
> Diffs
> -
> 
>   autotests/indexerextractortests.cpp 6b7c605 
>   autotests/simpleresult.h f3793b5 
>   src/extractionresult.h 76dfe59 
>   src/extractionresult.cpp 9bc7946 
>   src/extractors/plaintextextractor.cpp 5a38857 
> 
> Diff: https://git.reviewboard.kde.org/r/117996/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Vishesh Handa
> 
>


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

Re: Review Request 117996: Add an append(QByteArray) method to the ExtractionResult

[Milian Wolff]

> On May 5, 2014, 2:05 p.m., Milian Wolff wrote:
> > What is the speed difference compared to the old QString API, but without 
> > the word-count there? Afaik, the word-count is the major bottleneck and 
> > removing it alone should greatly speed up the test.
> > 
> > Having a QByteArray in the API would be fine if you document that the data 
> > _must_ be UTF8. But a meaningful performance test here must include the 
> > later conversion to std::string for xapian, imo. I.e. what you want to test 
> > is file -> qbytearray -> std::string vs. file -> qstring -> std::string.
> 
> Vishesh Handa wrote:
> Original: 60 msecs
> Without Word Count: 30 msecs
> Without Word Count + ByteArray: 8 msecs

cool, looks promising. And how slow would be your patch right now, just with 
result->append(QString::fromUtf8(arr)); Or is that then the 30msecs? Just 
wondering what the impact of using STL instead of QIODevice/QFile is here.


- Milian


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117996/#review57314
---


On May 5, 2014, 2:01 p.m., Vishesh Handa wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117996/
> ---
> 
> (Updated May 5, 2014, 2:01 p.m.)
> 
> 
> Review request for Baloo and Milian Wolff.
> 
> 
> Repository: kfilemetadata
> 
> 
> Description
> ---
> 
> Add an append(QByteArray) method to the ExtractionResult
> 
> This way plugins can choose to return the data in utf8 or as a QString,
> and the clients can either just let the standard QString::fromUtf8
> function do its magic, or implement some special handling if they wish.
> 
> This speeds up the PlainTextExtractor quite a bit (60msec vs 8.3msec)
> 
> Unfortunately, this meant discarding the extraction of WordCount from
> the Plain Text extractor. Though considering the speed difference, I
> think it is worth it.
> 
> 
> Diffs
> -
> 
>   autotests/indexerextractortests.cpp 6b7c605 
>   autotests/simpleresult.h f3793b5 
>   src/extractionresult.h 76dfe59 
>   src/extractionresult.cpp 9bc7946 
>   src/extractors/plaintextextractor.cpp 5a38857 
> 
> Diff: https://git.reviewboard.kde.org/r/117996/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Vishesh Handa
> 
>


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

Re: Review Request 117996: Add an append(QByteArray) method to the ExtractionResult

[Vishesh Handa]

> On May 5, 2014, 2:05 p.m., Milian Wolff wrote:
> > What is the speed difference compared to the old QString API, but without 
> > the word-count there? Afaik, the word-count is the major bottleneck and 
> > removing it alone should greatly speed up the test.
> > 
> > Having a QByteArray in the API would be fine if you document that the data 
> > _must_ be UTF8. But a meaningful performance test here must include the 
> > later conversion to std::string for xapian, imo. I.e. what you want to test 
> > is file -> qbytearray -> std::string vs. file -> qstring -> std::string.
> 
> Vishesh Handa wrote:
> Original: 60 msecs
> Without Word Count: 30 msecs
> Without Word Count + ByteArray: 8 msecs
> 
> Milian Wolff wrote:
> cool, looks promising. And how slow would be your patch right now, just 
> with result->append(QString::fromUtf8(arr)); Or is that then the 30msecs? 
> Just wondering what the impact of using STL instead of QIODevice/QFile is 
> here.

With QString::fromUtf8 - About 9msecs. So, it's all QFile.

I've tried testing out actually indexing a file before and after this patch 
(and a small patch in Baloo, to directly convert it into a QString). I can 
barely make out any difference. Just about 100-200 msecs on a file which takes 
11 seconds.

It might just make sense to discard the whole append(QByteArray) and just ship 
the QFile parts.


- Vishesh


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117996/#review57314
---


On May 5, 2014, 2:01 p.m., Vishesh Handa wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117996/
> ---
> 
> (Updated May 5, 2014, 2:01 p.m.)
> 
> 
> Review request for Baloo and Milian Wolff.
> 
> 
> Repository: kfilemetadata
> 
> 
> Description
> ---
> 
> Add an append(QByteArray) method to the ExtractionResult
> 
> This way plugins can choose to return the data in utf8 or as a QString,
> and the clients can either just let the standard QString::fromUtf8
> function do its magic, or implement some special handling if they wish.
> 
> This speeds up the PlainTextExtractor quite a bit (60msec vs 8.3msec)
> 
> Unfortunately, this meant discarding the extraction of WordCount from
> the Plain Text extractor. Though considering the speed difference, I
> think it is worth it.
> 
> 
> Diffs
> -
> 
>   autotests/indexerextractortests.cpp 6b7c605 
>   autotests/simpleresult.h f3793b5 
>   src/extractionresult.h 76dfe59 
>   src/extractionresult.cpp 9bc7946 
>   src/extractors/plaintextextractor.cpp 5a38857 
> 
> Diff: https://git.reviewboard.kde.org/r/117996/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Vishesh Handa
> 
>


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

Re: Review Request 117996: Add an append(QByteArray) method to the ExtractionResult

[Milian Wolff]

> On May 5, 2014, 2:05 p.m., Milian Wolff wrote:
> > What is the speed difference compared to the old QString API, but without 
> > the word-count there? Afaik, the word-count is the major bottleneck and 
> > removing it alone should greatly speed up the test.
> > 
> > Having a QByteArray in the API would be fine if you document that the data 
> > _must_ be UTF8. But a meaningful performance test here must include the 
> > later conversion to std::string for xapian, imo. I.e. what you want to test 
> > is file -> qbytearray -> std::string vs. file -> qstring -> std::string.
> 
> Vishesh Handa wrote:
> Original: 60 msecs
> Without Word Count: 30 msecs
> Without Word Count + ByteArray: 8 msecs
> 
> Milian Wolff wrote:
> cool, looks promising. And how slow would be your patch right now, just 
> with result->append(QString::fromUtf8(arr)); Or is that then the 30msecs? 
> Just wondering what the impact of using STL instead of QIODevice/QFile is 
> here.
> 
> Vishesh Handa wrote:
> With QString::fromUtf8 - About 9msecs. So, it's all QFile.
> 
> I've tried testing out actually indexing a file before and after this 
> patch (and a small patch in Baloo, to directly convert it into a QString). I 
> can barely make out any difference. Just about 100-200 msecs on a file which 
> takes 11 seconds.
> 
> It might just make sense to discard the whole append(QByteArray) and just 
> ship the QFile parts.

yes that sounds like a good approach.


- Milian


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117996/#review57314
---


On May 5, 2014, 2:01 p.m., Vishesh Handa wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117996/
> ---
> 
> (Updated May 5, 2014, 2:01 p.m.)
> 
> 
> Review request for Baloo and Milian Wolff.
> 
> 
> Repository: kfilemetadata
> 
> 
> Description
> ---
> 
> Add an append(QByteArray) method to the ExtractionResult
> 
> This way plugins can choose to return the data in utf8 or as a QString,
> and the clients can either just let the standard QString::fromUtf8
> function do its magic, or implement some special handling if they wish.
> 
> This speeds up the PlainTextExtractor quite a bit (60msec vs 8.3msec)
> 
> Unfortunately, this meant discarding the extraction of WordCount from
> the Plain Text extractor. Though considering the speed difference, I
> think it is worth it.
> 
> 
> Diffs
> -
> 
>   autotests/indexerextractortests.cpp 6b7c605 
>   autotests/simpleresult.h f3793b5 
>   src/extractionresult.h 76dfe59 
>   src/extractionresult.cpp 9bc7946 
>   src/extractors/plaintextextractor.cpp 5a38857 
> 
> Diff: https://git.reviewboard.kde.org/r/117996/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Vishesh Handa
> 
>


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

Re: Review Request 117996: Add an append(QByteArray) method to the ExtractionResult

[Vishesh Handa]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117996/
---

(Updated May 5, 2014, 4:14 p.m.)


Review request for Baloo and Milian Wolff.


Changes
---

PlainTextExtractor: Use fstream instead of QFile

Also discard the word count. This optimizes the plain text extractor
benchmark from 60 msecs to about 9 msecs.


Repository: kfilemetadata


Description
---

Add an append(QByteArray) method to the ExtractionResult

This way plugins can choose to return the data in utf8 or as a QString,
and the clients can either just let the standard QString::fromUtf8
function do its magic, or implement some special handling if they wish.

This speeds up the PlainTextExtractor quite a bit (60msec vs 8.3msec)

Unfortunately, this meant discarding the extraction of WordCount from
the Plain Text extractor. Though considering the speed difference, I
think it is worth it.


Diffs (updated)
-

  autotests/indexerextractortests.cpp 6b7c605 
  src/extractors/plaintextextractor.cpp 5a38857 

Diff: https://git.reviewboard.kde.org/r/117996/diff/


Testing
---


Thanks,

Vishesh Handa


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

Re: Review Request 117996: Add an append(QByteArray) method to the ExtractionResult

[Milian Wolff]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117996/#review57329
---

Ship it!


from my pov, +1

I hope noone will miss the word-count...

- Milian Wolff


On May 5, 2014, 4:14 p.m., Vishesh Handa wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117996/
> ---
> 
> (Updated May 5, 2014, 4:14 p.m.)
> 
> 
> Review request for Baloo and Milian Wolff.
> 
> 
> Repository: kfilemetadata
> 
> 
> Description
> ---
> 
> Add an append(QByteArray) method to the ExtractionResult
> 
> This way plugins can choose to return the data in utf8 or as a QString,
> and the clients can either just let the standard QString::fromUtf8
> function do its magic, or implement some special handling if they wish.
> 
> This speeds up the PlainTextExtractor quite a bit (60msec vs 8.3msec)
> 
> Unfortunately, this meant discarding the extraction of WordCount from
> the Plain Text extractor. Though considering the speed difference, I
> think it is worth it.
> 
> 
> Diffs
> -
> 
>   autotests/indexerextractortests.cpp 6b7c605 
>   src/extractors/plaintextextractor.cpp 5a38857 
> 
> Diff: https://git.reviewboard.kde.org/r/117996/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Vishesh Handa
> 
>


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

Re: Review Request 117996: Add an append(QByteArray) method to the ExtractionResult

[Vishesh Handa]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117996/
---

(Updated May 5, 2014, 4:35 p.m.)


Status
--

This change has been marked as submitted.


Review request for Baloo and Milian Wolff.


Repository: kfilemetadata


Description
---

Add an append(QByteArray) method to the ExtractionResult

This way plugins can choose to return the data in utf8 or as a QString,
and the clients can either just let the standard QString::fromUtf8
function do its magic, or implement some special handling if they wish.

This speeds up the PlainTextExtractor quite a bit (60msec vs 8.3msec)

Unfortunately, this meant discarding the extraction of WordCount from
the Plain Text extractor. Though considering the speed difference, I
think it is worth it.


Diffs
-

  autotests/indexerextractortests.cpp 6b7c605 
  src/extractors/plaintextextractor.cpp 5a38857 

Diff: https://git.reviewboard.kde.org/r/117996/diff/


Testing
---


Thanks,

Vishesh Handa


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

Re: Review Request 117996: Add an append(QByteArray) method to the ExtractionResult

[Commit Hook]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117996/#review57330
---


This review has been submitted with commit 
ce183ae409aa9104cabafaa8bcede4233fa25c5f by Vishesh Handa to branch KDE/4.13.

- Commit Hook


On May 5, 2014, 4:14 p.m., Vishesh Handa wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117996/
> ---
> 
> (Updated May 5, 2014, 4:14 p.m.)
> 
> 
> Review request for Baloo and Milian Wolff.
> 
> 
> Repository: kfilemetadata
> 
> 
> Description
> ---
> 
> Add an append(QByteArray) method to the ExtractionResult
> 
> This way plugins can choose to return the data in utf8 or as a QString,
> and the clients can either just let the standard QString::fromUtf8
> function do its magic, or implement some special handling if they wish.
> 
> This speeds up the PlainTextExtractor quite a bit (60msec vs 8.3msec)
> 
> Unfortunately, this meant discarding the extraction of WordCount from
> the Plain Text extractor. Though considering the speed difference, I
> think it is worth it.
> 
> 
> Diffs
> -
> 
>   autotests/indexerextractortests.cpp 6b7c605 
>   src/extractors/plaintextextractor.cpp 5a38857 
> 
> Diff: https://git.reviewboard.kde.org/r/117996/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Vishesh Handa
> 
>


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

Re: Thank you for Baloo!

[Vishesh Handa]

On Sunday, May 04, 2014 11:59:49 PM Martin Steigerwald wrote:
> Hi Vishesh and all the other devs working on it!
> 
> I don´t know how it indexed more than 70 mails in a local maildir in
> less than half an hour, but it seems it did.
> 
> I did no measurements, but I wouldn´t be surprised if Baloo outpeformed
> Nepomuk by a factor of at least 10 or 20 here.
> 

Much much more than a factor of 20! :D

How was the CPU and memory usage?

> Nice work!
> 

Thanks :)

-- 
Vishesh Handa

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

Re: Launch Bug Report Wizard failing on Apple OS X (was "ksycoca4")

[Thomas Lübking]

On Samstag, 3. Mai 2014 23:38:22 CEST, mk-li...@email.de wrote:

On 23 Mar 2014, at 19:18 , Thomas Lübking wrote:


Another idea would be that OSX doesn't like the "!" prefix (no 
idea why componentchooser writes it - here. Works fine w/o as 
well)



Hmm, I think that’s indeed the problem!


Many thanks for the update - let's see whether Jose can confirm this 
observation.

The only odd thing is that some kio_client apps clutter up the 
dock, which I’ve also seen for kglobalaccel in konversation [1]. 

Actually this does match [2] where many [kioclient] processes hang around - do 
you get them as well? ("ps ax" should also work under OSX)

Cheers,
Thomas


[1] https://bugs.kde.org/show_bug.cgi?id=334174
[2] https://sourceforge.net/p/be-shell/tickets/21/



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

Re: Launch Bug Report Wizard failing on Apple OS X (was "ksycoca4")

[mk-lists]

On 05 May 2014, at 21:00 , Thomas Lübking  wrote:
> Many thanks for the update - let's see whether Jose can confirm this 
> observation.
You’re welcome. We’ll see.

>> The only odd thing is that some kio_client apps clutter up the dock, which 
>> I’ve also seen for kglobalaccel in konversation [1]. 
> Actually this does match [2] where many [kioclient] processes hang 
> around - do you get them as well? ("ps ax" should also work under OSX)
Yup.


signature.asc
Description: Message signed with OpenPGP using GPGMail

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

Re: Launch Bug Report Wizard failing on Apple OS X (was "ksycoca4")

[Thomas Lübking]

On Montag, 5. Mai 2014 21:05:46 CEST, mk-li...@email.de wrote:

On 05 May 2014, at 21:00 , Thomas Lübking  wrote:
Many thanks for the update - let's see whether Jose can 
confirm this observation.

You’re welcome. We’ll see.

The only odd thing is that some kio_client apps clutter up 
the dock, which I’ve also seen for kglobalaccel in 
konversation [1]. 
Actually this does match [2] where many [kioclient] 
processes hang around - do you get them as well? ("ps ax" 
should also work under OSX)

Yup.


I found
https://bugs.kde.org/show_bug.cgi?id=294554
which *might* be https://bugs.kde.org/show_bug.cgi?id=290936 which was 
apparently caused in an attempt to fix 
https://bugs.kde.org/show_bug.cgi?id=182591 but is supposed to be fixed by
https://projects.kde.org/projects/kde/applications/kde-baseapps/repository/revisions/c37d81c2076cfa70c1952c49e5dd31f2034521f6/diff/konqueror/client/kfmclient.cpp

-> can you lookup your local KDE code for the section in kfmclient.cpp?

Cheers,
Thomas


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

Re: Launch Bug Report Wizard failing on Apple OS X (was "ksycoca4")

[mk-lists]

On 05 May 2014, at 21:25 , Thomas Lübking  wrote:
> -> can you lookup your local KDE code for the section in kfmclient.cpp?

Since I am using current KDE 4.12.4 here this change is - of course - present.

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

Re: Thank you for Baloo!

[Martin Steigerwald]

Am Montag, 5. Mai 2014, 18:51:52 schrieb Vishesh Handa:
> On Sunday, May 04, 2014 11:59:49 PM Martin Steigerwald wrote:
> > Hi Vishesh and all the other devs working on it!
> > 
> > I don´t know how it indexed more than 70 mails in a local maildir in
> > less than half an hour, but it seems it did.
> > 
> > I did no measurements, but I wouldn´t be surprised if Baloo outpeformed
> > Nepomuk by a factor of at least 10 or 20 here.
> 
> Much much more than a factor of 20! :D

Might very well be.

I now also indexed my company IMAP account as far as Akonadi can access it. 
Its Exchange IMAP and a bit flaky.

> How was the CPU and memory usage?

I didn´t look at memory usage, but CPU usage: Well there was some, but I think 
it didn´t exceed one logical core of a dual core hyperthreading SandyBridge 
mobile processor with 2,5 GHz.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

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

Re: Review Request 117902: Use PUBLIC and PRIVATE in target_link_libraries for the installed libs

[Alexander Richardson]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117902/
---

(Updated May 5, 2014, 9:07 p.m.)


Status
--

This change has been marked as submitted.


Review request for Baloo.


Repository: baloo


Description
---

Use PUBLIC and PRIVATE in target_link_libraries for the installed libs


Diffs
-

  src/core/CMakeLists.txt f9f663b1c1ba4c84057e76da09903c7a7c53da45 
  src/file/CMakeLists.txt 79a22551f0a8fa7475b69930c381057b42ca10fb 
  src/file/autotest/CMakeLists.txt a476a8d273bf9674221868f1cf287cd100191c76 
  src/file/extractor/CMakeLists.txt d8abe98c23b95440e0320b158f44cdca6428e7a6 
  src/file/lib/CMakeLists.txt a432ebb17ba6b66065ade31240217020b2df2ba4 
  src/file/lib/autotests/CMakeLists.txt 
9676c2e01c980ddb36c18a44ac1d8d08f862d1ea 
  src/file/tests/CMakeLists.txt f8386ae735e3bbc24f51402e59d5fc701afddd8d 
  src/pim/lib/CMakeLists.txt b57340872800ead1fcd224235b2f7b6f3f8ad172 
  src/xapian/CMakeLists.txt 38a4b2ed08db52cc8e2bc1e09ad3290bb6122515 

Diff: https://git.reviewboard.kde.org/r/117902/diff/


Testing
---

No longer need to find the private dependencies when building dolphin 
(frameworks)


Thanks,

Alexander Richardson


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

Re: Review Request 117902: Use PUBLIC and PRIVATE in target_link_libraries for the installed libs

[Commit Hook]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117902/#review57354
---


This review has been submitted with commit 
507fbd3e20b88d591a96a5ceb4094a8083a349cc by Alex Richardson to branch 
frameworks.

- Commit Hook


On April 30, 2014, 2:03 p.m., Alexander Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117902/
> ---
> 
> (Updated April 30, 2014, 2:03 p.m.)
> 
> 
> Review request for Baloo.
> 
> 
> Repository: baloo
> 
> 
> Description
> ---
> 
> Use PUBLIC and PRIVATE in target_link_libraries for the installed libs
> 
> 
> Diffs
> -
> 
>   src/core/CMakeLists.txt f9f663b1c1ba4c84057e76da09903c7a7c53da45 
>   src/file/CMakeLists.txt 79a22551f0a8fa7475b69930c381057b42ca10fb 
>   src/file/autotest/CMakeLists.txt a476a8d273bf9674221868f1cf287cd100191c76 
>   src/file/extractor/CMakeLists.txt d8abe98c23b95440e0320b158f44cdca6428e7a6 
>   src/file/lib/CMakeLists.txt a432ebb17ba6b66065ade31240217020b2df2ba4 
>   src/file/lib/autotests/CMakeLists.txt 
> 9676c2e01c980ddb36c18a44ac1d8d08f862d1ea 
>   src/file/tests/CMakeLists.txt f8386ae735e3bbc24f51402e59d5fc701afddd8d 
>   src/pim/lib/CMakeLists.txt b57340872800ead1fcd224235b2f7b6f3f8ad172 
>   src/xapian/CMakeLists.txt 38a4b2ed08db52cc8e2bc1e09ad3290bb6122515 
> 
> Diff: https://git.reviewboard.kde.org/r/117902/diff/
> 
> 
> Testing
> ---
> 
> No longer need to find the private dependencies when building dolphin 
> (frameworks)
> 
> 
> Thanks,
> 
> Alexander Richardson
> 
>


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