- User Since
- Apr 16 2015, 7:53 PM (105 w, 4 d)
Tue, Apr 18
excellent test coverage, much appreciated, some nitpick notes
Mon, Apr 17
Thu, Apr 13
can we first profile it and see if we can speed it up instead of applying such a (imo) nasty workaround?
Fri, Apr 7
Thu, Apr 6
Wed, Apr 5
A WIP for this can be found in wip/buildid, it will include the buildid in the heaptrack file. But for interpreting, it isn't enough to just load the debug file only. It has to be used in addition apparently, which isn't possible without patching libbacktrace like is done in vogl.
Tue, Apr 4
also update DYLD_LIBRARY_PATH
Mon, Apr 3
lgtm, I can also add the copyright header for you and submit it then later when I get the time
Sun, Apr 2
Wed, Mar 29
can go project be detected based on some file? If so, could you add something like this to the json file please:
I think you are still abusing the code architecture for compiler support here.
if it shows a graph, lgtm :)
Tue, Mar 28
the screenshot shows "c++11" as Cuda C profile - is that correct?
I'm still against messing with the font styles the way you do it. simply add underlines for the part that is longer than N chars and add a tooltip for that part such that people know what's happening
Mon, Mar 27
still lgtm, do you have commit rights?
still lgtm, do you have commit rights?
I think it's OK to rely on clang only for cuda and not support GCC emulation. This doesn't even really work properly for C++ either, so don't go down that rabbit hole.
@coopht: Your points re recent files are very valid - let's not use it.
Sun, Mar 26
I like the change in general, only wonder whether we need to introduce a new queue for that - can't we reuse the recent file mechanism instead? or do people really want to have an infinite history here?
Mar 23 2017
We are explicitly excluding the standard includes for C and C++, so maybe something like that accidentally happens for cuda, too? Cf. nostdinc.
Yes, please reserve it.
Mar 22 2017
remove the moc, then feel free to push
Mar 20 2017
Mar 19 2017
I'm personally all for improving the status quo, but I think the biggest problem here is that we have no unit test coverage (or do we?). The unit tests would also clearly show the advantage of this new beheavior compared to the old one. So: Could you add unit tests?
@dfaure Is there a way to give actions in the "configure shortcuts" action a different name from what is shown by menus?
lgtm, but please ensure that you squash your commits before pushing this
QtWebKit is actually more alive nowadays than in a long time, so I still think the best way forward would be to wrap it in a thin KF5-material wrapper and use that here
Can you please add more information? I also use "^C" to interrupt tracking and that used to work just fine for me. What is going wrong? Why is your trap line required? Add all of this information to the commit message
sorry for the delay Alexander
some minor nitpicks. imo feel free to commit after fixing those
do you have commit rights? otherwise someone from us can commit this for you
we need to wait for the other change to get in first of course
Mar 16 2017
QTextDocument won't be enough for our purposes. We actually embed e.g. the remote PHP documentation here. And even simple HTML features are not supported by QTextDocument.
Mar 11 2017
OK, but that's still not very user-friendly as
Mar 9 2017
See also: https://phabricator.kde.org/T5381
How did you create that? How would I create a new one? How is this accessible to new users, i.e. not me?
I know Phab is not Gerrit. But Gerrit is an excellent review tool, so what is wrong in making use of the good features in it? It's super ignorant to say "I'm after a Gerrit centric workflow". I'm after a _good_ review workflow. Gerrit just happens to be one.
+100 to what dfaure said, totally in sync to my view of the upstream people
works for me: https://phabricator.kde.org/tag/kdevelop/
Yes, I want to show a bucketed view for the overall project.
See https://phabricator.kde.org/D4665 <-- so probably this is again an issue when people are not using arcanist. We must get a way to add that info for these people, too. But that will only be done once we get the proper git integration, right? Is there any ETA on it? Or will it be "sometime" and we will have to make do with the broken workflow?
Mar 6 2017
Mar 5 2017
now that this API becomes public, it must be improved to make it better understandable to the public
lgtm in principle, but I find it odd that to is lower-cased, but With is uppercased
yep, lgtm - thanks!
lgtm, esp. since a test is added
lgtm in principle, but there are two checks that imo need to be removed to cleanup the code. it's not a good idea to be overly pedantic in code, rather use assertions like we do elsewhere
As-is, this is not a good approach imo. Either have it as generic API in iproblem.h (which would mean you'd also need to serialize the data in problem.cpp), or have it as a special case for the detected problem and only use it there
Feb 26 2017
Feb 23 2017
Feb 22 2017
Feb 21 2017
use override, track view changes
Tons of new files and not a single test? Can you add some?
The existing branch field is not useful. It shows the branch the submitter has been using, which will usually be a work branch. What we need is the *target* branch.