mimetype for files with a wrong extension?
I'm trying to figure out why kmimetype returns image/jpeg for a png file that
was renamed to have a jpg extension (which apparently happens a lot for real
users).
In the dox for KMimeType::findByUrl it's said that if only the filename is used
to determine the mimetype, accuracy is set to 80 -- but it's not, it's set to
100.
diff --git a/kdecore/services/kmimetype.cpp b/kdecore/services/kmimetype.cpp
index 955bf62..74f371d 100644
--- a/kdecore/services/kmimetype.cpp
+++ b/kdecore/services/kmimetype.cpp
@@ -211,6 +211,7 @@ KMimeType::Ptr KMimeType::findByUrlHelper( const KUrl
_url, mode_t mode,
kWarning() Glob file refers to selectedMime
but this mimetype does not exist!;
mimeList.clear();
} else {
+accuracy = 80;
return mime;
}
}
lines 1-12/12 (END)
When doing this I can at least see that only the filename was used. But I'm
wondering why checking the magic numbers for jpg, png and so on from the
content isn't given a higher accuracy, since if do a findByContent, I get an
accuracy of 50 for my file, but the magic numbers for image files are pretty
much completely reliable.
--
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: Setting up a Quality Team within KDE
On 09.04.12 12:58:02, Alexander Neundorf wrote: On Friday 06 April 2012, Anne-Marie Mahfouf wrote: On 04/06/2012 02:23 PM, Aleix Pol wrote: On Thu, Apr 5, 2012 at 1:42 PM, Anne-Marie Mahfouf annemarie.mahf...@free.fr wrote: Hi, We would like to setup a Quality Testing Team within KDE in order to better test our next KDE SC and make the beta process more efficient. Attached is the first draft of the ideas I brainstormed. Source .odt of this document is available at http://quickgit.kde.org/index.php?p=scratch%2Fannma%2Fquality-testing-do c.git (We can make it a public Google doc if it is more convenient or an etherpad). The document roughly describes 2 areas of action: - reinforcement (labelled Reinforce) of existing structures (mainly targetted to developers and mainly relevant before the beta stage of the release). This could be used as guidelines for new developers. Of course it won't be newbies which will develop Unit Tests or check the code quality. But some guidelines can be useful for libs outside Frameworks. An area of relevant reinforcement that can be currently done is the Review process for new integration. - new infra-structures: this is labelled New in the doc: this is what I would see to happen for the 4.9 release. A new mailing list has been set up in order to discuss all this: please subscribe to it if you would like to be part of this https://mail.kde.org/mailman/listinfo/kde-testing An IRC channel also was created on Freenode: #kde-quality Please join the mailing list and the IRC channel so we can setup a plan to start putting all this in gear! Hi! I think this project is a very interesting idea and definitely something we need. Said that, I'd like to propose some small changes on how this should be done. In the document there are some actions to be taken that sound a bit too technical, for example it specifies reinforcing the unit testing. This is something that we should have been doing already and I don't see someone from the Quality Team going to a development team and improving that. Making unit tests is the developer task (and the document mentions it) and we do have solit Unit Tests in kdelibs and Frameworks and kdepimlibs. However there are other libs within KDE where maybe unit tests are not as present as they should (I did not research that though). Also, about unit tests, it's not only writing them, it's also running them. This is not done in a regular basis and needs to be automated in the future and the fails need to be fixed. No newbie will ever touch to any Unit Tests of course. And any action will be discussed with the gurus in this field (/me does not point to David). We have many tools for developers which are not fully used: latest great tool is Jenkins which I was aware of only recently. My label Reinforce is to take full advantage of those existing tools. (It would be cool if at Akademy there are some talks focusing on using these tools.) There is not only Jenkins, but also CDash, which integrates nicely with our cmake-based build system. I was trying to set up nightly builds for the KDE modules two years ago or so (hosted on http://my.cdash.org, some of our projects are actually using it), gave a talk at Akademy in Tampere and tried really hard, but there was not much response to it. Well, I'd say jenkins has a lot more to offer than cdash. Its also a lot simpler to use, setup and understand for newcomers in my opinion. With jenkins I can have a shell-script job which runs cmake make make test and be done. Setting up a build for submission to cdash takes a lot more effort - at least it did when I tried to do this maybe things got easier meanwhile. Andreas PS: Personally I find the Web-GUI also a bit nicer, but thats really just a personal preference.
Re: Re: Setting up a Quality Team within KDE
On Monday 09 April 2012 13:15:26 Andreas Pakulat wrote: There is not only Jenkins, but also CDash, which integrates nicely with our cmake-based build system. I was trying to set up nightly builds for the KDE modules two years ago or so (hosted on http://my.cdash.org, some of our projects are actually using it), gave a talk at Akademy in Tampere and tried really hard, but there was not much response to it. Well, I'd say jenkins has a lot more to offer than cdash. Its also a lot simpler to use, setup and understand for newcomers in my opinion. With jenkins I can have a shell-script job which runs cmake make make test and be done. Setting up a build for submission to cdash takes a lot more effort - at least it did when I tried to do this maybe things got easier meanwhile. I quite agree. Jenkins offers in my opinion much, much more. I have been using my own custom Jenkins installation for at least half a year now and that allows me to easily build KWin with various compile flags, etc. etc. Also the community around Jenkins is very active and there are lots of plugins available to improve the testing (e.g. cppcheck which got recently added to our build.kde.org instance) Andreas PS: Personally I find the Web-GUI also a bit nicer, but thats really just a personal preference. +1 Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: Setting up a Quality Team within KDE
On Monday, April 09, 2012 02:05:28 PM Martin Gräßlin wrote: On Monday 09 April 2012 13:15:26 Andreas Pakulat wrote: There is not only Jenkins, but also CDash, which integrates nicely with our cmake-based build system. I was trying to set up nightly builds for the KDE modules two years ago or so (hosted on http://my.cdash.org, some of our projects are actually using it), gave a talk at Akademy in Tampere and tried really hard, but there was not much response to it. Well, I'd say jenkins has a lot more to offer than cdash. Its also a lot simpler to use, setup and understand for newcomers in my opinion. With jenkins I can have a shell-script job which runs cmake make make test and be done. Setting up a build for submission to cdash takes a lot more effort - at least it did when I tried to do this maybe things got easier meanwhile. I quite agree. Jenkins offers in my opinion much, much more. I have been using my own custom Jenkins installation for at least half a year now and that allows me to easily build KWin with various compile flags, etc. etc. Also the community around Jenkins is very active and there are lots of plugins available to improve the testing (e.g. cppcheck which got recently added to our build.kde.org instance) As far as i understand things here (which probably is not much), the two complement it other. CDash is in no way a substitute or alternative to jenkins. But another way to congregate and present the unit test results from different builds, machines, configurations side by side. Jenkins as far is i know only presents the results of one build. But i know it can congregate the test results of more than one build. At least it can for java. But i am not sure it can do it for builds running on different jenkins instances. CDash can. So each jenkins build could run the test and give them to cdash. Best of both worlds. Mike -- Michael Jansen http://michael-jansen.biz
Re: Question about unittesting
El Diumenge, 8 d'abril de 2012, a les 21:45:34, Giorgos Tsiapaliwkas va
escriure:
Hello,
Why we don't have in KDE a macro like,
if (application_is_in_debug_mode) {
//do some testing
}
Because then you are not testing your real code anymore.
Albert
Why we need a macro like that?
a. Giorgos added a feature which deletes a folder from dolphin. Without
this macro in order Giorgos to
test it he needs,
-to create a dir
-remove the dir
-check if the remove was successful(this is the actual test)
but if we had this macro Giorgos would need to implement the last step.
c. we gain more time and it gets easier for contributors to add some
testing code.
A side note here, of course in vital libs only experienced developers
should write the unittests,
but in small applications contributors could also do the job.
Regards
P.S.: this macro could be enabled by adding in the cmake options something
like enable_unittest
Re: Setting up a Quality Team within KDE
On 09.04.12 13:28:31, Anne-Marie Mahfouf wrote: On 04/09/2012 01:15 PM, Andreas Pakulat wrote: On 09.04.12 12:58:02, Alexander Neundorf wrote: On Friday 06 April 2012, Anne-Marie Mahfouf wrote: On 04/06/2012 02:23 PM, Aleix Pol wrote: On Thu, Apr 5, 2012 at 1:42 PM, Anne-Marie Mahfouf annemarie.mahf...@free.fr wrote: Hi, We would like to setup a Quality Testing Team within KDE in order to better test our next KDE SC and make the beta process more efficient. Attached is the first draft of the ideas I brainstormed. Source .odt of this document is available at http://quickgit.kde.org/index.php?p=scratch%2Fannma%2Fquality-testing-do c.git (We can make it a public Google doc if it is more convenient or an etherpad). The document roughly describes 2 areas of action: - reinforcement (labelled Reinforce) of existing structures (mainly targetted to developers and mainly relevant before the beta stage of the release). This could be used as guidelines for new developers. Of course it won't be newbies which will develop Unit Tests or check the code quality. But some guidelines can be useful for libs outside Frameworks. An area of relevant reinforcement that can be currently done is the Review process for new integration. - new infra-structures: this is labelled New in the doc: this is what I would see to happen for the 4.9 release. A new mailing list has been set up in order to discuss all this: please subscribe to it if you would like to be part of this https://mail.kde.org/mailman/listinfo/kde-testing An IRC channel also was created on Freenode: #kde-quality Please join the mailing list and the IRC channel so we can setup a plan to start putting all this in gear! Hi! I think this project is a very interesting idea and definitely something we need. Said that, I'd like to propose some small changes on how this should be done. In the document there are some actions to be taken that sound a bit too technical, for example it specifies reinforcing the unit testing. This is something that we should have been doing already and I don't see someone from the Quality Team going to a development team and improving that. Making unit tests is the developer task (and the document mentions it) and we do have solit Unit Tests in kdelibs and Frameworks and kdepimlibs. However there are other libs within KDE where maybe unit tests are not as present as they should (I did not research that though). Also, about unit tests, it's not only writing them, it's also running them. This is not done in a regular basis and needs to be automated in the future and the fails need to be fixed. No newbie will ever touch to any Unit Tests of course. And any action will be discussed with the gurus in this field (/me does not point to David). We have many tools for developers which are not fully used: latest great tool is Jenkins which I was aware of only recently. My label Reinforce is to take full advantage of those existing tools. (It would be cool if at Akademy there are some talks focusing on using these tools.) There is not only Jenkins, but also CDash, which integrates nicely with our cmake-based build system. I was trying to set up nightly builds for the KDE modules two years ago or so (hosted on http://my.cdash.org, some of our projects are actually using it), gave a talk at Akademy in Tampere and tried really hard, but there was not much response to it. Well, I'd say jenkins has a lot more to offer than cdash. Its also a lot simpler to use, setup and understand for newcomers in my opinion. With jenkins I can have a shell-script job which runs cmake make make test and be done. Setting up a build for submission to cdash takes a lot more effort - at least it did when I tried to do this maybe things got easier meanwhile. What's a bit sad is that nobody talks very much about Jenkins There's been several blogposts in the past weeks/months about build.kde.org, but indeed its more of a Developer-Resource in that it builds KDE modules and runs their unit-tests to inform developers asap when something broke. Andreas, your script should be public. Uhm I'd use this as a start: cd build cmake ../ make make test But I don't own any of the jobs at build.kde.org, so you should probably talk to the admins of the jenkins server to find out how the builds are actually run. Andreas
Re: Setting up a Quality Team within KDE
On 09.04.12 14:29:27, Michael Jansen wrote: On Monday, April 09, 2012 02:05:28 PM Martin Gräßlin wrote: On Monday 09 April 2012 13:15:26 Andreas Pakulat wrote: There is not only Jenkins, but also CDash, which integrates nicely with our cmake-based build system. I was trying to set up nightly builds for the KDE modules two years ago or so (hosted on http://my.cdash.org, some of our projects are actually using it), gave a talk at Akademy in Tampere and tried really hard, but there was not much response to it. Well, I'd say jenkins has a lot more to offer than cdash. Its also a lot simpler to use, setup and understand for newcomers in my opinion. With jenkins I can have a shell-script job which runs cmake make make test and be done. Setting up a build for submission to cdash takes a lot more effort - at least it did when I tried to do this maybe things got easier meanwhile. I quite agree. Jenkins offers in my opinion much, much more. I have been using my own custom Jenkins installation for at least half a year now and that allows me to easily build KWin with various compile flags, etc. etc. Also the community around Jenkins is very active and there are lots of plugins available to improve the testing (e.g. cppcheck which got recently added to our build.kde.org instance) As far as i understand things here (which probably is not much), the two complement it other. CDash is in no way a substitute or alternative to jenkins. But another way to congregate and present the unit test results from different builds, machines, configurations side by side. Jenkins as far is i know only presents the results of one build. But i know it can congregate the test results of more than one build. At least it can for java. But i am not sure it can do it for builds running on different jenkins instances. You usually have only 1 jenkins instance and a so-called jenkins-slave on each machine that actually runs builds. The build.kde.org server is its own slave atm, presumably because there's no further hardware available. In jenkins each configuration would be 1 job, each job has a number of past builds and associated test results as well as output from various other plugins (if configured, like static code-checkers). The website can aggregate the information and generate graphs (or rather the various plugins do this) to see things like test-trends etc. It doesn't matter on which of the slaves the build actually runs. If you don't depend on volunteers submitting their own local builds to cdash, then this is similar to cdash, except that cdash only does the aggregation of results. So CDash leaves setting up build infrastructure, automatic VCS-check etc. up to you to do. Relying on volunteers to submit their own local builds has proven to be not working well for us, there are few if any builds regularly submitted. CDash can. So each jenkins build could run the test and give them to cdash. Except, this would have absolutely no benefit compared to just displaying the data in Jenkins itself :) Andreas
Re: Setting up a Quality Team within KDE
On 09.04.12 16:27:17, Laszlo Papp wrote: Well, I'd say jenkins has a lot more to offer than cdash. Its also a lot simpler to use, setup and understand for newcomers in my opinion. With jenkins I can have a shell-script job which runs cmake make make test and be done. Setting up a build for submission to cdash takes a lot more effort - at least it did when I tried to do this maybe things got easier meanwhile. It has been simpler than I thought when I have set the functionality up with a little bit of guidance last summer. I think we could probably even make the setup easier with some automated script or so by solving the boilerplate part of the relevant cmake files. As far as I see the admin setting this up needs to know some parameters if I am not too mistaken. I do not have any opinions about the web interface differences because I do not visit that. I have been getting the warnings, errors and unit test failures via email, if any. Hmm, that may work if your project has usually no warnings, but I find this for warnings to be too much noise. The CI mails should immediately tell me if CI is considered broken (and warnings are often not considered that) or not and if its broken show me the error so I don't need to go to the website to fix it - ideally. I will also try out this Jenkins in the future once I find the time for that, but I have been a happy CDash user for about ten months by now. :-) build.kde.org can give you a pretty good idea of how jenkins looks and can be used to do CI. Andreas
Re: Review Request: KJS: Implement Object.GetOwnPropertyDescriptor Object.DefineProperty
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104515/ --- (Updated April 9, 2012, 8:23 p.m.) Review request for kdelibs. Changes --- Changed Array to use Object instead of Pointer to Objects. This gives a 100ms speed boost compared to the Pointer version. Overall its ~100ms slower than the original kjs 4.8.2, but that is expected as this version really checks for attributes. So every put/delete/enum is really checked, a version without check is always faster. Tested with sunspider 1.0 (latest svn trunk), both version run about 10 times (x10runs = 100). I also tested virtual putDirect vs. non-virtual putDirect (only performancewise), the avg performance loss was 14ms (after 10 x 10 runs = 100 sunspider 1.0 runs). Anyway it does not seems like it is a very critical performance loss. testregress showed a tiny/typo difference with max Array Index, this is fixed in this version. Now no difference when using ./testregression.shell --js --noxvfb ~/khtmltests/regression/ compared to the orginal kde 4.8.2 kjs Description --- KJS: Implement Object.GetOwnPropertyDescriptor Object.DefineProperty This is a pretty big patch, to get Object.defineProperty perfect for ecmascript (for all tests that only use implemented stuff, all test that use Object.create for example will fail, as its not implemented) PropertyDescriptor: Necessary for collectiong data, this introduce new CommonIdentifiers.h, this might requiere to rebuild khtml against new kjs, otherwise it might cause weird crashes (at least for me) object.h: Beside from adding new getPropertyDescriptor getOwnPropertyDescriptor defineOwnProperty, the important changes are making getPropertyAttributes, put/get/remove-Direct virtual. Why do I need that? Because put checks if the prototype already has property XYZ and uses it. Now imagine an array that got a setter-only property via a prototype. DefineProperty would try to use put, which uses the prototype property and it would fail. So all custom-data classes like Array need to implement/use put/get/remove-Direct. object.cpp: currently put on a setter-only property would always throw an exception, this is only correct for strict-mode, as we currently do not check for strict-mode it would make more sense to change it to default not throwing an exception. array.cpp/h: The old Array implementation did not store attributes for array indexes, I rewrote it to also store the attributes. + Bonus: also fix getOwnPropertyNames, as we now store attributes. + use new attributes, reject put/delete/enum if set function.cpp (Arguments) changed the default attributes how parameter are stored, according to ECMA 10.6.11.b Rest is just the defineProperty implementation Diffs (updated) - kjs/CMakeLists.txt 1188064 kjs/CommonIdentifiers.h 8ee40e8 kjs/array_instance.h 3f2b630 kjs/array_instance.cpp fe9b8b4 kjs/function.h 3757fe8 kjs/function.cpp 5f39ae6 kjs/object.h 047c242 kjs/object.cpp c19122f kjs/object_object.cpp 986f03f kjs/operations.h f8a28c8 kjs/operations.cpp d4c0066 Diff: http://git.reviewboard.kde.org/r/104515/diff/ Testing --- ecmascript daily surfing used valgrind on many array testcases to check for possible memleaks Thanks, Bernd Buschinski
Re: Setting up a Quality Team within KDE
Hmm, that may work if your project has usually no warnings, but I find this for warnings to be too much noise. We have also had many warnings back then. :-) The CI mails should immediately tell me if CI is considered broken (and warnings are often not considered that) or not and if its broken show me the error so I don't need to go to the website to fix it - ideally. That can be done as far as I know. It also shows the warnings, but it might be that you need to click on the link you receive in the email, if you have many warnings. It redirects you to the list so that you can go through your codebase to fix those. I have never found the web interface for this goal disadvantageous yet. I will also try out this Jenkins in the future once I find the time for that, but I have been a happy CDash user for about ten months by now. :-) build.kde.org can give you a pretty good idea of how jenkins looks and can be used to do CI. I do not personally find the page aforementioned having that professional layout as the CDash site, but that might be just me. Also, I personally find the CDash site simpler to use. My personal worry is that, I would not like to refactor the setup already existing and working just fine for a while unless there is a compelling reason and the switch is simple. Also, I do not see Playground projects on the build.kde.org site. In addition, if it is just for KDE, it would result me using different services for Qt Playground and KDE projects. That would be a bit unhandy. I could use CDash for both. That having said, CDash was designed with CMake in mind. We already depend on CMake and CTest. Those three projects are maintained by the same company, if I am not mistaken, called Kitware (and probably also by community volunteers). Therefore, we can be sure about the integrity and so forth. On the contrary I can somewhat understand the need for a community driven site even if it is quite unlike Kitware just goes away. They have not been doing that with cmake either for many years. They respect KDE, and Alex has always been very helpful with those topics. :-) The current setup is comfortable and good enough to me, but I am open, thus I will check out Jenkins. Best Regards, Laszlo Papp
Re: Setting up a Quality Team within KDE
On 09.04.12 23:29:17, Laszlo Papp wrote: I will also try out this Jenkins in the future once I find the time for that, but I have been a happy CDash user for about ten months by now. :-) build.kde.org can give you a pretty good idea of how jenkins looks and can be used to do CI. I do not personally find the page aforementioned having that professional layout as the CDash site, but that might be just me. Also, I personally find the CDash site simpler to use. I noted my personal impression only as a PS since I'm well aware that there's much personal preference here. One thing I do like about jenkins: I see the status of the projects immediately when opening the page. With some better filtering/views set up this can be quite handy. My personal worry is that, I would not like to refactor the setup already existing and working just fine for a while unless there is a compelling reason and the switch is simple. I'm not sure what exactly the setup is on build.kde.org, looking at the console output some envvars are set and then as I said in another reply all it takes is cd build cmake ../ make make install No further setup needed (unless the unit-tests have some specific requirements). If thats encoded into the ctest script you could also just run ctest. Also, I do not see Playground projects on the build.kde.org site. The service is comparatively new, but as can be seen already has a lot more builds on it then ever where done for CDash. Also IIRC there was a blog-post inviting people to submit requests for the addition of their projects. I also don't see any KDE playground apps on my.cdash.org :) In addition, if it is just for KDE, it would result me using different services for Qt Playground and KDE projects. That would be a bit unhandy. I could use CDash for both. If one is involved with different projects outside of Qt/KDE then its quite normal to have to deal with various types of web-services. So personally I don't think thats a good enough reason to ignore the benefits that jenkins does provide. In addition as was said elsewhere in the thread, the jenkins job could submit their data to cdash too if the projects are set up for that. That having said, CDash was designed with CMake in mind. We already depend on CMake and CTest. We actually do not depend on CTest, that is an optional tool, one can run the tests without ctest (in fact I've never used CTest on my machines). Those three projects are maintained by the same company, if I am not mistaken, called Kitware (and probably also by community volunteers). Therefore, we can be sure about the integrity and so forth. On the contrary I can somewhat understand the need for a community driven site even if it is quite unlike Kitware just goes away. They have not been doing that with cmake either for many years. They respect KDE, and Alex has always been very helpful with those topics. :-) I'm not questioning the usefulness of CDash or wether the free-hosting goes ever away. I don't actually care who hosts the CI-server for KDE projects, all I care about is that its easy to get a project set up to be build continously (and the unit-tests executed) and wether it provides more than just build errors/warnings and test-results. Since some of these things are handy - especially when working on libraries. Andreas
Review Request: Make nepomuk runner remove undesired matches
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104526/ --- Review request for KDE Runtime. Description --- Nepomuk runner returns matches like global namespace, local namespace and PaginatedTextDocument which pollutes the query's returned matches. This patch adds a NegationTerm to the nepomuk query to filter them. If somebody has a better way to prevent those matches from appearing please let me know. This addresses bug 284553. http://bugs.kde.org/show_bug.cgi?id=284553 Diffs - plasma/generic/runners/nepomuksearch/queryclientwrapper.h 48c1eaa plasma/generic/runners/nepomuksearch/queryclientwrapper.cpp 0b828b0 Diff: http://git.reviewboard.kde.org/r/104526/diff/ Testing --- Works in my Plasma Active installation. Thanks, Lamarque Vieira Souza
Re: Review Request: Copy files instead of moving if parent dir is not writable
On March 30, 2012, 8:18 p.m., Thomas Lübking wrote: Any more questions about this patch? Can I push it? - Lamarque Vieira --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104417/#review12037 --- On March 30, 2012, 6:57 p.m., Lamarque Vieira Souza wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104417/ --- (Updated March 30, 2012, 6:57 p.m.) Review request for KDE Runtime and Plasma. Description --- When adding an application resource to a private activity kactivitymanager tries to move the resource's .desktop file to the activity's private folder. The new .desktop file is created successfully but the source file is not deleted if the user does not have write permission on the file's directory. This patch detects such situation and uses copy instead of move to prevent permission denied messages for every resource being added. This addresses bug 296808. http://bugs.kde.org/show_bug.cgi?id=296808 Diffs - service/jobs/nepomuk/Move.h 8a8afd1 service/jobs/nepomuk/Move.cpp 2248768 Diff: http://git.reviewboard.kde.org/r/104417/diff/ Testing --- Works for resources of type app, it does not work for image yet because Move::canMove receives the nepomuk's uri instead of the file url when the resource type is image. Thanks, Lamarque Vieira Souza
Re: Review Request: Add cmake config for kdeclarative library.
On March 5, 2012, 8:51 p.m., Alexander Neundorf wrote:
experimental/libkdeclarative/KDeclarativeConfig.cmake.in, line 14
http://git.reviewboard.kde.org/r/104140/diff/1/?file=51648#file51648line14
I didn't check, but how is INCLUDE_INSTALL_DIR set ?
Is it done by via find_package(KDE4) ?
In this case, INCLUDE_INSTALL_DIR is a relative path under Windows, so
the config file wouldn't work properly under Windows.
Lamarque Vieira Souza wrote:
I do not know, INCLUDE_INSTALL_DIR was already used in
libkdeclarative/CMakeLists.txt before I created this patch. I am just using
it.
Any more questions about this patch? Can I push it?
- Lamarque Vieira
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104140/#review11151
---
On March 5, 2012, 9:55 p.m., Lamarque Vieira Souza wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104140/
---
(Updated March 5, 2012, 9:55 p.m.)
Review request for kdelibs.
Description
---
Currently kdeclarative library does not install the KDeclarativeConfig.cmake
and KDeclarativeConfigVersion.cmake to ${LIB_INSTALL_DIR}/cmake/KDeclarative
and so other KDE programs cannot find the library using cmake's find_package
macro.
kde-workspace, kde-runtime and plasma-mobile currently hardcode the
kdeclarative library name in their CMakeLists.txt, which is not ideal. Once
this patch is submitted we need to fix their CMakeLists.txt to use
find_package(KDeclarative REQUIRED).
Diffs
-
experimental/libkdeclarative/CMakeLists.txt 0db647c
experimental/libkdeclarative/KDeclarativeConfig.cmake.in PRE-CREATION
experimental/libkdeclarative/KDeclarativeConfigVersion.cmake.in
PRE-CREATION
Diff: http://git.reviewboard.kde.org/r/104140/diff/
Testing
---
I can now compile kde-workspace/ksmserver without using the custom made
FindKDeclarative.cmake.
Thanks,
Lamarque Vieira Souza
Re: Review Request: KJS: Implement Object.prototypeOf, Object.keys, Object.getOwnPropertyNames
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104511/#review12281 --- kjs/function.cpp http://git.reviewboard.kde.org/r/104511/#comment9642 How should this react when the length property is altered? kjs/function.cpp http://git.reviewboard.kde.org/r/104511/#comment9643 Why convert to ident when isMapped will convert back to number again? Just add aversion that takes a number; similarly [] works on numbers already. (And perhaps fix up some of the sloppiness with signs there) kjs/object.h http://git.reviewboard.kde.org/r/104511/#comment9644 It's OK to make API changes here; just make sure you fix every call site. Frankly, past experience shows that overloaded virtual groups like this are a mistake and hard to get right (there have been bugs caused with the getters, for example). kjs/object.cpp http://git.reviewboard.kde.org/r/104511/#comment9645 This might actually show up on some benchmarks. I bet you can speed this up by making an appropriate choice of value for PropertyMap::IncludeDontEnumProperties -- basically making it a mask on attr, but that may be a bit brittle maintenance wise kjs/object_object.cpp http://git.reviewboard.kde.org/r/104511/#comment9647 For these comments, could you include the spec version? Reason: we have a whole bunch of the around already... From something older than the 3rd edition. (Dunno if from 2nd or 1st..) kjs/object_object.cpp http://git.reviewboard.kde.org/r/104511/#comment9648 Faster: save return value of getObject() and check that for null. (Note that it matters here..) kjs/object_object.cpp http://git.reviewboard.kde.org/r/104511/#comment9649 So this one shows the DontEnum ones? Joy. kjs/object_object.cpp http://git.reviewboard.kde.org/r/104511/#comment9650 I think you could merge this implementation with the above; the only difference is what gets passed to getOwnPropertyNames as last argument, isn't it? This is way too much to duplicate.. - Maks Orlovich On April 8, 2012, 9:14 p.m., Bernd Buschinski wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104511/ --- (Updated April 8, 2012, 9:14 p.m.) Review request for kdelibs. Description --- KJS: Implement Object.prototypeOf, Object.keys, Object.getOwnPropertyNames NOTE: Array was left out on purpose, as currentl imeplementation does not save attributes (next patch will fix this) keysGetOwnPropertyNames requieres to change the JSObject::getOwnPropertyNames implementation, for future use a enum is better than than a bool, maybe there will be more ways to include/exclude properties. All changes for khtml/ecma/ are to silense the -Woverloaded-virtual warnings Diffs - khtml/ecma/kjs_css.h aba44b8 khtml/ecma/kjs_css.cpp e3e7417 khtml/ecma/kjs_dom.h d0433c3 khtml/ecma/kjs_dom.cpp 5fff7e3 khtml/ecma/kjs_html.h 0f3f544c khtml/ecma/kjs_html.cpp e3da95c khtml/ecma/kjs_scriptable.h af5343c khtml/ecma/kjs_scriptable.cpp 5d4ea68 kjs/JSVariableObject.h a8f01eb kjs/JSVariableObject.cpp b00ef76 kjs/array_instance.h 3f2b630 kjs/function.h 3757fe8 kjs/function.cpp 5f39ae6 kjs/object.h 047c242 kjs/object.cpp c19122f kjs/object_object.cpp 986f03f kjs/property_map.h 6b127ff kjs/property_map.cpp b2ff08e kjs/string_object.h e890d52 kjs/string_object.cpp 170e2f7 Diff: http://git.reviewboard.kde.org/r/104511/diff/ Testing --- ecma script daily surfing Thanks, Bernd Buschinski
Re: Review Request: KJS: Implement Object.GetOwnPropertyDescriptor Object.DefineProperty
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104515/#review12282 --- I think I need a bit of higher-level info from here; plus I guess refining the other one (which has far simpler stuff to fix) and submitting it would remove some of the duplication.. kjs/CMakeLists.txt http://git.reviewboard.kde.org/r/104515/#comment9651 where is this file? kjs/array_instance.cpp http://git.reviewboard.kde.org/r/104515/#comment9653 Could the array stuff perhaps be split out? kjs/array_instance.cpp http://git.reviewboard.kde.org/r/104515/#comment9652 This is useless; it does what the default one would do (and why not copy constructor then?) kjs/object.h http://git.reviewboard.kde.org/r/104515/#comment9654 This is why I don't like the making of these virtual: getDirectLocation goes with these, so if these are virtual so should it be, but getDirectLocation is used by the Window object, so it's absolutely and utterly performance-critical. What I don't understand is: is there actually generic/polymorphic code that needs to call both the default and array's version? kjs/object.cpp http://git.reviewboard.kde.org/r/104515/#comment9655 I don't understand all that you're doing here --- you invoke getOwnPropertySlot (which is virtual and may be overridden in subclasses, then getPropertyAttributes and then getDirect. And then get. What's the interface to the subclass here? Just how many look ups is it doing, etc.? kjs/object.cpp http://git.reviewboard.kde.org/r/104515/#comment9656 There is an explicit isUndefined check, but what about the ways in which toObject can fail? kjs/operations.cpp http://git.reviewboard.kde.org/r/104515/#comment9657 Please point out how this isn't the same as strictEquals (due to the spec having two almost identical, but slightly different in handling of FP ops). - Maks Orlovich On April 9, 2012, 8:23 p.m., Bernd Buschinski wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104515/ --- (Updated April 9, 2012, 8:23 p.m.) Review request for kdelibs. Description --- KJS: Implement Object.GetOwnPropertyDescriptor Object.DefineProperty This is a pretty big patch, to get Object.defineProperty perfect for ecmascript (for all tests that only use implemented stuff, all test that use Object.create for example will fail, as its not implemented) PropertyDescriptor: Necessary for collectiong data, this introduce new CommonIdentifiers.h, this might requiere to rebuild khtml against new kjs, otherwise it might cause weird crashes (at least for me) object.h: Beside from adding new getPropertyDescriptor getOwnPropertyDescriptor defineOwnProperty, the important changes are making getPropertyAttributes, put/get/remove-Direct virtual. Why do I need that? Because put checks if the prototype already has property XYZ and uses it. Now imagine an array that got a setter-only property via a prototype. DefineProperty would try to use put, which uses the prototype property and it would fail. So all custom-data classes like Array need to implement/use put/get/remove-Direct. object.cpp: currently put on a setter-only property would always throw an exception, this is only correct for strict-mode, as we currently do not check for strict-mode it would make more sense to change it to default not throwing an exception. array.cpp/h: The old Array implementation did not store attributes for array indexes, I rewrote it to also store the attributes. + Bonus: also fix getOwnPropertyNames, as we now store attributes. + use new attributes, reject put/delete/enum if set function.cpp (Arguments) changed the default attributes how parameter are stored, according to ECMA 10.6.11.b Rest is just the defineProperty implementation Diffs - kjs/CMakeLists.txt 1188064 kjs/CommonIdentifiers.h 8ee40e8 kjs/array_instance.h 3f2b630 kjs/array_instance.cpp fe9b8b4 kjs/function.h 3757fe8 kjs/function.cpp 5f39ae6 kjs/object.h 047c242 kjs/object.cpp c19122f kjs/object_object.cpp 986f03f kjs/operations.h f8a28c8 kjs/operations.cpp d4c0066 Diff: http://git.reviewboard.kde.org/r/104515/diff/ Testing --- ecmascript daily surfing used valgrind on many array testcases to check for possible memleaks Thanks, Bernd Buschinski
Re: Setting up a Quality Team within KDE
Also IIRC there was a blog-post inviting people to submit requests for the addition of their projects. I believe, I missed that. I also don't see any KDE playground apps on my.cdash.org :) http://my.cdash.org/index.php?project=Gluon http://my.cdash.org/index.php?project=QtOpenAL (You do not find it in playground since it was deleted 1-2 days ago after migrating to Qt Playground, but it has been hosted there). Unfortunately, I had some server issues recently though that I did not have time to deal with. At any rate, playground projects should be able to have quality services on wish as well IMO. If one is involved with different projects outside of Qt/KDE then its quite normal to have to deal with various types of web-services. So personally I don't think thats a good enough reason to ignore the benefits that jenkins does provide. That is not so simple. Once you get used to the feeling and you settle down you can use the same service for multiple projects, it is a bit difficult to persuade yourself it is worth changing in order to have more services to get familiar with. Like I said, as for me, it needs to have a compelling reason with smooth transition and simple usage in the future as well. As for my case, I would not just personally like to get involved in two different services, if I am fine with one. In addition as was said elsewhere in the thread, the jenkins job could submit their data to cdash too if the projects are set up for that. :-) Meanwhile, I trust you it is possible to do that, I prefer to avoid the multilayering, if possible. That having said, CDash was designed with CMake in mind. We already depend on CMake and CTest. We actually do not depend on CTest, that is an optional tool, one can run the tests without ctest (in fact I've never used CTest on my machines). I stand corrected, you are right about that. You can use make test without getting involved with CTest. [...] all I care about is that its easy to get a project set up to be build continously (and the unit-tests executed) and wether it provides more than just build errors/warnings and test-results. Since some of these things are handy - especially when working on libraries. Could you please precisely enumerate the technical pros and cons so that we can all understand ? Thank you in advance! Best Regards, Laszlo Papp
Re: Setting up a Quality Team within KDE
I also don't see any KDE playground apps on my.cdash.org :) http://my.cdash.org/index.php?project=Gluon http://my.cdash.org/index.php?project=QtOpenAL (You do not find it in playground since it was deleted 1-2 days ago after migrating to Qt Playground, but it has been hosted there). Ah yes, and also my playground dictionary I worked on: http://my.cdash.org/index.php?project=Mula Best Regards, Laszlo Papp
Review Request: fix kio_sftp login after pressing cancel in the retry dialog
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104529/ --- Review request for KDE Runtime and Andreas Schneider. Description --- The following patch address a scenario the following sftp login related patches: https://git.reviewboard.kde.org/r/101332/ https://git.reviewboard.kde.org/r/102428/ missed. Namely, what happens if the user presses cancel not in the original password dialog, but rather in the subsequent retry dialog. This could happen if the user made a typo when entering login and password originally. With this patch all the scenarios work as advertised and kio_sftp behaves almost exactly the same as kio_ftp. Diffs - kioslave/sftp/kio_sftp.cpp cfd9bcf Diff: http://git.reviewboard.kde.org/r/104529/diff/ Testing --- Repeat the testing outlined in https://git.reviewboard.kde.org/r/101332/, but with the following change: In step #1, instead of pressing cancel in the password dialog, enter incorrect login/password. Wait for the the retry dialog to pop up, and then press cancel. Thanks, Dawit Alemayehu
