- User Since
- Apr 16 2015, 7:53 PM (110 w, 3 d)
Wed, May 24
sorry Heinz, but I think the base for this patch is still wrong. Depending on what you did, here are some ideas on what you could try to resolve this situation:
Tue, May 23
Wed, May 17
Mon, May 15
well spotted :)
Sun, May 14
qmake isn't ported yet?
overall looks OK to me, mostly nitpicks. I can't comment on the docker/flatpack magic as this goes beyond my knowledge in that area. Also make sure that the docker/flatpak plugins are only installed on linux.
Does kdev-php and the other plugins that leverage this still work afterwards? If so, +1. That's really the only test that I'd be doing myself :) No idea about what this ASIgnore stuff is supposed to be...
For solarized you showed the screenshots in your original mail. I'm more concerned about backwards compatibility with other schemes. I.e. yes - we do care about the status quo. Can you give an example for a color scheme where this would break stuff? Then I can also apply the patch locally and try it out myself and maybe come up with a concrete idea to fix this all.
Sorry, but I'm against pushing it as-is. Doing the optimization isn't hard, you are more or less prematurely pessimizing it here. And if you want to put this into anything but master, having a proper unit test is a must anyways I'd say.
please fix what kfunk pointed out, but otherwise this lgtm too
Ping? I think other than the mimetype issue, this is OK to get merged. Do you have commit rights?
Sorry for the delay, and thanks for the contribution. You do have commit rights, correct? If so, please push to master.
Tue, May 9
Mon, May 8
Thu, May 4
ugh. I see it's a necessary evil. But I think it's actually going to be faster to either hand roll this replacement or use a QRegularExpression, because your code is now scanning the contents twice. Once should be enough. And a greedy pattern like "\\r\\n??" should be quite fast.
neat, sounds awesome - I'll try to find some time to try this out over the next days. But yes, without sshfs it's going to be tricky to get access to docker contents. I access them usually via, in my case, these paths:
http://doc.qt.io/qt-5/qshareddatapointer.html -> your change looks sane for *explicitly* shared data members, but not for implicit ones which will call detach in non-const operator->() automatically
Wed, May 3
do you have commit rights? if not, someone of us needs to commit this for you. In that case, we'll need to know your email address to properly attribute this patch set to you
first of all, sorry for the long delay Aleix. I haven't yet had time to look at the code, just watched your videos which look pretty neat. some high-level questions:
lgtm, two parts can be cleaned up but otherwise feel free to commit
Tue, May 2
Apr 28 2017
Apr 26 2017
Apr 18 2017
excellent test coverage, much appreciated, some nitpick notes
Apr 17 2017
Apr 13 2017
can we first profile it and see if we can speed it up instead of applying such a (imo) nasty workaround?
Apr 7 2017
Apr 6 2017
Apr 5 2017
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.
Apr 4 2017
also update DYLD_LIBRARY_PATH
Apr 3 2017
lgtm, I can also add the copyright header for you and submit it then later when I get the time
Apr 2 2017
Mar 29 2017
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 :)
Mar 28 2017
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
Mar 27 2017
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.
Mar 26 2017
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?