Feed Advanced Search

Sat, Oct 20

rjvbb added a comment to D9344: [KDevelop] : [fixed] consistent use of the project name allowing to create multiple projects in a single source tree.

One more thing: could establishing the project file name not simply be done by a method in the ProjectController class rather than by a dedicated class? Because, in how many different functions would you split that logic?

Sat, Oct 20, 3:54 PM · KDevelop
rjvbb added a comment to D16218: [KDevelop/Core]: safe signal-handler implementation (WIP).
Arguably that still stands, but it's outside my area of expertise to comment on it.
Sat, Oct 20, 2:59 PM · KDevelop
rjvbb added a comment to D9344: [KDevelop] : [fixed] consistent use of the project name allowing to create multiple projects in a single source tree.
The current patch I still cannot oversee (though also due to the existing code), so I would have to grab the -1 sign for now if on the jury.
Sat, Oct 20, 2:37 PM · KDevelop
rjvbb set the repository for D16218: [KDevelop/Core]: safe signal-handler implementation (WIP) to R32 KDevelop.
Sat, Oct 20, 9:53 AM · KDevelop
rjvbb updated the diff for D16218: [KDevelop/Core]: safe signal-handler implementation (WIP).

updated as requested.

Sat, Oct 20, 9:53 AM · KDevelop
rjvbb added inline comments to D16218: [KDevelop/Core]: safe signal-handler implementation (WIP).
Sat, Oct 20, 9:51 AM · KDevelop

Fri, Oct 19

rjvbb set the repository for D16218: [KDevelop/Core]: safe signal-handler implementation (WIP) to R32 KDevelop.
Fri, Oct 19, 12:59 PM · KDevelop
rjvbb updated the diff for D16218: [KDevelop/Core]: safe signal-handler implementation (WIP).

Drops the potentially unsafe qDebug output in the signal handler, makes handlingSignal an std::atomic_bool (since we can use locks here anyway) and adds copious comments.

Fri, Oct 19, 12:59 PM · KDevelop
rjvbb added a comment to D16218: [KDevelop/Core]: safe signal-handler implementation (WIP).

Still working on this and waiting on more background info from the Qt Interest ML.

Fri, Oct 19, 8:57 AM · KDevelop

Thu, Oct 18

rjvbb added a comment to D16218: [KDevelop/Core]: safe signal-handler implementation (WIP).
You can't use std::atomic_flag, because it's an `int`.
Thu, Oct 18, 8:52 PM · KDevelop
rjvbb added a comment to D16218: [KDevelop/Core]: safe signal-handler implementation (WIP).

Any idea how we could test the race-condition scenario? I've been trying by re-raising the signal from just before and just inside the if(handlingSignal) loop and until now it has always been behaving as expected (= the if is executed only once).

Thu, Oct 18, 2:06 PM · KDevelop
rjvbb added a comment to D15295: [konsole]: proper fix for a crash-on-exit.

Sorry for the delay; I thought this would be straightforward and then ran into questions...

Thu, Oct 18, 9:05 AM · Konsole
rjvbb added a comment to D16218: [KDevelop/Core]: safe signal-handler implementation (WIP).
This is determined by hardware support. With relevant architectures I meant architectures on which Qt/KDE applications can run, like x86, PPC, ARM. > These all have lock-free `std::atomic<bool>`, as far as I know.
Thu, Oct 18, 8:16 AM · KDevelop
rjvbb added a comment to D16218: [KDevelop/Core]: safe signal-handler implementation (WIP).
I guess you can also use `std::atomic_flag`, which is guaranteed to be lock-free, and should offer enough functionality for our use case.

...

Not in the middle of an assignment, but between the read in `if (!handlingSignal)` and the write `handlingSignal = 1` it can be interrupted. That's not atomic.
Thu, Oct 18, 8:03 AM · KDevelop

Tue, Oct 16

rjvbb added a comment to D16218: [KDevelop/Core]: safe signal-handler implementation (WIP).

At least std::atomic<bool> is lock-free on all relevant architectures. (I'm aware that the standard doesn't guarantee it, probably because of some embedded architectures.

Tue, Oct 16, 10:35 PM · KDevelop
rjvbb set the repository for D9344: [KDevelop] : [fixed] consistent use of the project name allowing to create multiple projects in a single source tree to R32 KDevelop.
Tue, Oct 16, 10:03 PM · KDevelop
rjvbb updated the diff for D9344: [KDevelop] : [fixed] consistent use of the project name allowing to create multiple projects in a single source tree.

Updated as suggested

Tue, Oct 16, 10:02 PM · KDevelop
rjvbb added a comment to D9344: [KDevelop] : [fixed] consistent use of the project name allowing to create multiple projects in a single source tree.

Where in the code would you want a documentation of the intent of this change?
The best place might be a in the handbook or the project import wizard GUI ... but we're in string freeze, no?

Tue, Oct 16, 10:01 PM · KDevelop

Mon, Oct 15

rjvbb added inline comments to D16218: [KDevelop/Core]: safe signal-handler implementation (WIP).
Mon, Oct 15, 11:47 PM · KDevelop
rjvbb set the repository for D16218: [KDevelop/Core]: safe signal-handler implementation (WIP) to R32 KDevelop.
Mon, Oct 15, 2:58 PM · KDevelop
rjvbb updated the diff for D16218: [KDevelop/Core]: safe signal-handler implementation (WIP).
  • Dropped the semaphore-based alternative as it would only be less resource-intensive when manhandling pthreads
  • moved almost everything back out of the CorePrivate class, keeping only the slot required for QSocketNotifier operation.
  • dropped the SIGHUP shortcut, to be resubmitted in the future
Mon, Oct 15, 2:57 PM · KDevelop
rjvbb added a comment to D16218: [KDevelop/Core]: safe signal-handler implementation (WIP).
I would recommend to just not think about the Windows requirement, if you cannot test it anyway.
Mon, Oct 15, 1:35 PM · KDevelop
rjvbb added a comment to D16218: [KDevelop/Core]: safe signal-handler implementation (WIP).
If there is no solution which does not require two different code paths for handling this problem, I'm against merging this, non-conformant old behaviour or not, sorry.
Mon, Oct 15, 10:51 AM · KDevelop
rjvbb added a comment to D16218: [KDevelop/Core]: safe signal-handler implementation (WIP).
Mon, Oct 15, 10:41 AM · KDevelop
rjvbb set the repository for D16218: [KDevelop/Core]: safe signal-handler implementation (WIP) to R32 KDevelop.
Mon, Oct 15, 10:27 AM · KDevelop
rjvbb added a comment to D16218: [KDevelop/Core]: safe signal-handler implementation (WIP).
Mon, Oct 15, 10:20 AM · KDevelop
rjvbb updated the diff for D16218: [KDevelop/Core]: safe signal-handler implementation (WIP).

Adds the missing #endif

Mon, Oct 15, 10:14 AM · KDevelop
rjvbb added a comment to D16218: [KDevelop/Core]: safe signal-handler implementation (WIP).

Re: the testing I did on FreeBSD: that's with a dedicated demonstrator; I cannot currently build KDevelop5 there.

Mon, Oct 15, 9:17 AM · KDevelop
rjvbb requested review of D16218: [KDevelop/Core]: safe signal-handler implementation (WIP).
Mon, Oct 15, 9:15 AM · KDevelop

Tue, Oct 9

rjvbb added a comment to D9344: [KDevelop] : [fixed] consistent use of the project name allowing to create multiple projects in a single source tree.

I'd be pushing less if this hadn't already been committed and then reverted because of an issue that got through the initial review process.

Tue, Oct 9, 11:48 AM · KDevelop
rjvbb added a comment to D9344: [KDevelop] : [fixed] consistent use of the project name allowing to create multiple projects in a single source tree.

In absence of instructions to the contrary I'll interpret Milian's "feel free to respin" as "feel free to recommit", and push a commit during the day. This has been waiting to be re-applied long enough.

Tue, Oct 9, 8:30 AM · KDevelop

Wed, Oct 3

rjvbb committed R626:c1c66262b2df: Don't hardcode the path to bash (authored by rjvbb).
Don't hardcode the path to bash
Wed, Oct 3, 8:56 AM

Sat, Sep 29

rjvbb set the repository for D9344: [KDevelop] : [fixed] consistent use of the project name allowing to create multiple projects in a single source tree to R32 KDevelop.
Sat, Sep 29, 5:25 PM · KDevelop
rjvbb updated the diff for D9344: [KDevelop] : [fixed] consistent use of the project name allowing to create multiple projects in a single source tree.

Another fix for the generic Makefile project manager; I had missed the fact that URLInfo::isDir is undefined when URLInfo::isValid is false. This lead to personalised project files of the type `/path/to/projectFoo/projectFoo.kdev4/customname.kdev4```.

Sat, Sep 29, 5:25 PM · KDevelop
rjvbb set the repository for D15797: [kdev-clazy] : use canonical paths to R32 KDevelop.
Sat, Sep 29, 2:10 PM · KDevelop
rjvbb updated the diff for D15797: [kdev-clazy] : use canonical paths.

Updated as discussed. This variant is less different from stock code than my previous proposal. It complements the current checks with a comparison using canonicalised paths. As a result it should catch all cases that are not caught by either one of the comparisons when performed in isolation.

Sat, Sep 29, 2:09 PM · KDevelop
rjvbb added a comment to D15797: [kdev-clazy] : use canonical paths.

I think there might be a simpler solution to that situation

Sat, Sep 29, 12:22 PM · KDevelop

Fri, Sep 28

rjvbb set the repository for D9344: [KDevelop] : [fixed] consistent use of the project name allowing to create multiple projects in a single source tree to R32 KDevelop.
Fri, Sep 28, 12:24 PM · KDevelop
rjvbb updated the diff for D9344: [KDevelop] : [fixed] consistent use of the project name allowing to create multiple projects in a single source tree.

Updated as discussed: any previous project settings file in .kdev4 will be removed if and before overriding/writing it (instead of simply trashing the entire .kdev4 directory).

Fri, Sep 28, 12:24 PM · KDevelop
rjvbb added a comment to D9344: [KDevelop] : [fixed] consistent use of the project name allowing to create multiple projects in a single source tree.

I'm doing it now and will test it as part of this patch; afterward there are 3 options

Fri, Sep 28, 8:54 AM · KDevelop
rjvbb added a comment to D15694: Make implicit fallthroughs a compiler error, remove unneeded breaks.
Attributes are not keywords — they're a (C++-specific) generic syntax that was introduced with C++11.
Again, the idea is not starting from scratch, but introducing small changes that reduce the number of errors programmers
Fri, Sep 28, 7:51 AM · KDevelop
rjvbb added a comment to D9344: [KDevelop] : [fixed] consistent use of the project name allowing to create multiple projects in a single source tree.

In any situation where we'd already be overwriting the settings file but where there are other projects defined in the same sourcetree. The summary of this DR argues how and why that could be the case.

Fri, Sep 28, 7:28 AM · KDevelop

Thu, Sep 27

rjvbb set the repository for D9344: [KDevelop] : [fixed] consistent use of the project name allowing to create multiple projects in a single source tree to R32 KDevelop.
Thu, Sep 27, 11:40 PM · KDevelop
rjvbb updated the diff for D9344: [KDevelop] : [fixed] consistent use of the project name allowing to create multiple projects in a single source tree.

This fixes a mix-up that slipped through and above all, puts deleting the .kdev4 under user control.
Apparently there are situations where this directory should be deleted because its presence (empty) can confuse the project manager when overwriting an existing project (?!, T6262). /Methinks that's something that must be fixed in the confused place(s), not worked around by removing .kdev4. The whole point of this patch is to allow the creation of multiple projects in a single source tree, after all.

Thu, Sep 27, 11:38 PM · KDevelop
rjvbb added a comment to T6262: Overriding an existing project should wipe .kdev4 directory.

Exactly how can the project manager be confused when you don't remove the .kdev4 directory, knowing that it will be recreated almost immediately after deleting it? (In any case I don't see how it could *not* be recreated given that it will hold the new settings file).

Thu, Sep 27, 10:56 PM · KDevelop
rjvbb added a comment to D15694: Make implicit fallthroughs a compiler error, remove unneeded breaks.
You can use comments <https://developers.redhat.com/blog/2017/03/10/wimplicit-fallthrough-in-gcc-7/>, or `__attribute__((fallthrough))` in C.
Thu, Sep 27, 6:45 PM · KDevelop
rjvbb committed R32:24e2f759694c: Support for Objective-C++ in the custom-definesandincludes plugin (authored by rjvbb).
Support for Objective-C++ in the custom-definesandincludes plugin
Thu, Sep 27, 5:51 PM
rjvbb closed D15764: [Custom-DefinesAndIncludes]: Objective-C++ support.
Thu, Sep 27, 5:51 PM · KDevelop
rjvbb set the repository for D15764: [Custom-DefinesAndIncludes]: Objective-C++ support to R32 KDevelop.
Thu, Sep 27, 5:41 PM · KDevelop
rjvbb updated the diff for D15764: [Custom-DefinesAndIncludes]: Objective-C++ support.

Using Q_UNREACHABLE

Thu, Sep 27, 5:40 PM · KDevelop
rjvbb added a comment to D15625: Sublime: Fix crash when changing areas.

Latest version still doesn't restore the crash for me, so LG.

Thu, Sep 27, 2:35 PM · KDevelop
rjvbb added a comment to D15764: [Custom-DefinesAndIncludes]: Objective-C++ support.

__builtin_unreachable() does have strange effects:

Thu, Sep 27, 2:26 PM · KDevelop
rjvbb requested review of D15797: [kdev-clazy] : use canonical paths.
Thu, Sep 27, 1:50 PM · KDevelop
rjvbb added a comment to D15764: [Custom-DefinesAndIncludes]: Objective-C++ support.

I think this could be Q_UNREACHABLE().

Thu, Sep 27, 9:15 AM · KDevelop

Wed, Sep 26

rjvbb set the repository for D15764: [Custom-DefinesAndIncludes]: Objective-C++ support to R32 KDevelop.
Wed, Sep 26, 5:23 PM · KDevelop
rjvbb updated the diff for D15764: [Custom-DefinesAndIncludes]: Objective-C++ support.

Updated as suggested: handle all known language types in languageStandard()

Wed, Sep 26, 5:23 PM · KDevelop
rjvbb added inline comments to D15764: [Custom-DefinesAndIncludes]: Objective-C++ support.
Wed, Sep 26, 5:22 PM · KDevelop
rjvbb set the repository for D15764: [Custom-DefinesAndIncludes]: Objective-C++ support to R32 KDevelop.
Wed, Sep 26, 3:36 PM · KDevelop
rjvbb updated the diff for D15764: [Custom-DefinesAndIncludes]: Objective-C++ support.

reuse the C(++) parser options for ObjC(++).

Wed, Sep 26, 3:36 PM · KDevelop
rjvbb added a comment to D15764: [Custom-DefinesAndIncludes]: Objective-C++ support.
  • Do we want a -std= flag, does Clang even accept that?
Wed, Sep 26, 3:18 PM · KDevelop
rjvbb set the repository for D15764: [Custom-DefinesAndIncludes]: Objective-C++ support to R32 KDevelop.
Wed, Sep 26, 10:40 AM · KDevelop
rjvbb updated the diff for D15764: [Custom-DefinesAndIncludes]: Objective-C++ support.

Removed left-over x-objchdr reference (sorry about that).

Wed, Sep 26, 10:40 AM · KDevelop
rjvbb requested review of D15764: [Custom-DefinesAndIncludes]: Objective-C++ support.
Wed, Sep 26, 10:37 AM · KDevelop
rjvbb set the repository for D15530: kdev-clang : somewhat more complete ObjC(++) support to R32 KDevelop.
Wed, Sep 26, 10:33 AM · KDevelop
rjvbb updated the diff for D15530: kdev-clang : somewhat more complete ObjC(++) support.

Removed the x-objchdr mimetype (to avoid additional confusion what a .h file could be) and added my current x-objc+src definition to kdevclang.xml .

Wed, Sep 26, 10:33 AM · KDevelop

Tue, Sep 25

rjvbb added a comment to D15530: kdev-clang : somewhat more complete ObjC(++) support.
So let's first please do some effort to have a MIME type id agreed on by others (ideally this would be something done in the Objective-C++ community where you might have your contacts to poke)
Tue, Sep 25, 8:37 PM · KDevelop
rjvbb added a comment to D15625: Sublime: Fix crash when changing areas.
I am slighty uneasy with the explosion of code we add now
Tue, Sep 25, 7:44 PM · KDevelop
rjvbb added a comment to R32:9b581d93bbc5: make AStyleStringIterator::getPeekStart() return valid values.

"this commit is the patch which is reviewed there".

Tue, Sep 25, 1:01 PM
rjvbb committed R32:9b581d93bbc5: make AStyleStringIterator::getPeekStart() return valid values (authored by rjvbb).
make AStyleStringIterator::getPeekStart() return valid values
Tue, Sep 25, 12:38 PM
rjvbb closed D15605: kdev-astyle : upgrade libastyle to v3.1.
Tue, Sep 25, 12:38 PM · KDevelop

Mon, Sep 24

rjvbb accepted D15625: Sublime: Fix crash when changing areas.

Looks like you nailed it this time.

Mon, Sep 24, 7:40 PM · KDevelop
rjvbb added a comment to D15625: Sublime: Fix crash when changing areas.
Then I don't understand the question.
Mon, Sep 24, 6:38 PM · KDevelop
rjvbb added a comment to D15625: Sublime: Fix crash when changing areas.

I don't see how that answers my question?

Mon, Sep 24, 5:10 PM · KDevelop
rjvbb added a comment to D15625: Sublime: Fix crash when changing areas.

If I may: can someone please tell me why it should be impossible that only small items are found, IOW why there would also have to be something to shrink?

Mon, Sep 24, 4:43 PM · KDevelop
rjvbb added a comment to D15625: Sublime: Fix crash when changing areas.

The reasoning was that Items that have maximumWidth size needn't be shrinked, as that's the maximum size that's allowable.

Mon, Sep 24, 4:11 PM · KDevelop
rjvbb added a comment to D15625: Sublime: Fix crash when changing areas.

See also https://bugs.kde.org/show_bug.cgi?id=399025

Mon, Sep 24, 3:59 PM · KDevelop
rjvbb added a comment to D15625: Sublime: Fix crash when changing areas.

Can you guarantee that rect.width (height) will never be equal to the RHS in the equation from my previous reply?

Mon, Sep 24, 2:51 PM · KDevelop
rjvbb added a comment to D15625: Sublime: Fix crash when changing areas.

Another thought: are you sure the comparison should be itemWidth <= maximumWidth and not a simple < instead? That ought to address the situation I run into, though I still don't believe it'd be a guarantee that there will never be other situations where all items are considered to be small items.

Mon, Sep 24, 12:53 PM · KDevelop
rjvbb added a comment to D15625: Sublime: Fix crash when changing areas.

Interestingly, I'm getting the same issue on Linux (with the same QtCurve style though a slightly different font selection).
Only here it's maximumHeight that is concerned, not the width.

Mon, Sep 24, 12:47 PM · KDevelop
rjvbb added a comment to D15625: Sublime: Fix crash when changing areas.
How exactly is maximumWidth calculated to be 0?
Mon, Sep 24, 11:57 AM · KDevelop
rjvbb requested changes to D15625: Sublime: Fix crash when changing areas.

It works and can go in with just one minor change request.

Mon, Sep 24, 11:25 AM · KDevelop
rjvbb added a comment to D15694: Make implicit fallthroughs a compiler error, remove unneeded breaks.
As discussed earlier, switch statements do have a weird syntax and I'm completely with you if you don't like it. They are basically a glorified `goto` cascade. The case labels actually behave like `goto` labels in a lot of ways, which is the basis of oddities like Duff's device
Mon, Sep 24, 8:27 AM · KDevelop
rjvbb added a comment to D15694: Make implicit fallthroughs a compiler error, remove unneeded breaks.
When it comes to no `break;` after a `return;`, that also matches the idea to not have an `else` after an `return` in the branch before.
Mon, Sep 24, 7:48 AM · KDevelop
rjvbb added a comment to D15530: kdev-clang : somewhat more complete ObjC(++) support.
Sure, I am mainly interested here that we use MIME type ids which also accepted elsewhere, and not invent our own here and ignore the rest of the world :)
Once e.g. shared-mime-info has some version accepted, we can then provide fall-back variants in the kdevelop s-m-i files installed.
Mon, Sep 24, 7:40 AM · KDevelop

Sun, Sep 23

rjvbb added a comment to D15694: Make implicit fallthroughs a compiler error, remove unneeded breaks.
Can you explain in more detail how an unreachable `break` after a `return` statement makes the code more readable?
Sun, Sep 23, 7:33 PM · KDevelop
rjvbb added a comment to D15694: Make implicit fallthroughs a compiler error, remove unneeded breaks.

As mentioned on another ticket, I don't like the idea of not putting breaks, no matter how clever the compiler and hard-coded choice of compiler options; I don't think you gain anything from it, and it doesn't improve code readability either for me (esp. when switch cases aren't indented w.r.t the switch context, as in the last hunk in plugins/qmljs/codecompletion/context.cpp.
Making it obligatory to add a token confirming that fallthrough is intended is a good idea, though using a largish term in all-caps like Q_FALLTHROUGH also doesn't improve readibilty. And what about the most common type of fallthrough, are we really going to have to write something like the following?

Sun, Sep 23, 5:31 PM · KDevelop
rjvbb added a comment to D15530: kdev-clang : somewhat more complete ObjC(++) support.

Doesn't KDevelop already add (install) a few mimetypes of its own? I think I mentioned before that I do have a .xml file for SMI, adding the x-objc++src definition and I presume that's why I am not seeing mimetype warnings about ObC (I'm seeing others though.)

Sun, Sep 23, 3:59 PM · KDevelop

Sat, Sep 22

rjvbb added a comment to D15532: [Astyle] Add Objective C to list of languages with formatters.

I have no (big) problems with a fallthrough attribute, but if it's going to be obligatory I'd want the complementary attribute (the break) to be obligatory too...

Sat, Sep 22, 7:05 PM · KDevelop
rjvbb added a comment to D15530: kdev-clang : somewhat more complete ObjC(++) support.

You should probably also add a few lines to the custom-definesandincludes plugin.

Sat, Sep 22, 8:20 AM · KDevelop
rjvbb added a comment to D15532: [Astyle] Add Objective C to list of languages with formatters.
Eventually we have to compile our code anyway, so aren't we all dependent on the compiler?
Sat, Sep 22, 8:14 AM · KDevelop

Sep 21 2018

rjvbb committed R32:ee092ebbadfc: Companion change for the customscript plugin to match #a0992d3166 (authored by rjvbb).
Companion change for the customscript plugin to match #a0992d3166
Sep 21 2018, 7:54 PM
rjvbb set the repository for D7930: Kdevelop CMake plugin : use canonical paths to build.dir to R32 KDevelop.
Sep 21 2018, 3:32 PM · KDevelop
rjvbb updated the diff for D7930: Kdevelop CMake plugin : use canonical paths to build.dir.

Refactored for the 5.3 branch + completed.

Sep 21 2018, 3:30 PM · KDevelop
rjvbb added a comment to D15605: kdev-astyle : upgrade libastyle to v3.1.
"If you have inherited this class to access the formatter, you will need to add a method similar to getPeekStart() in the ASStreamIterator class in astyle_main.h." from http://astyle.sourceforge.net/news.html is the only info I have, which leaves lots of room.
Have you seen any docs for that method?
Sep 21 2018, 12:36 PM · KDevelop
rjvbb set the repository for D15530: kdev-clang : somewhat more complete ObjC(++) support to R32 KDevelop.
Sep 21 2018, 10:33 AM · KDevelop
rjvbb updated the diff for D15530: kdev-clang : somewhat more complete ObjC(++) support.

Updated as suggested. No switch yet but a layout that looks more like one.

Sep 21 2018, 10:33 AM · KDevelop
rjvbb added a comment to D15625: Sublime: Fix crash when changing areas.

Looks good at first glance. The failsafe should work evidently but I'll have to test to be certain if the other fix prevents the situation I ran into. Maybe this afternoon, otherwise tomorrow.

Sep 21 2018, 10:30 AM · KDevelop
rjvbb added a comment to D15530: kdev-clang : somewhat more complete ObjC(++) support.

You should probably also add a few lines to the custom-definesandincludes plugin.

Sep 21 2018, 10:02 AM · KDevelop
rjvbb reopened D15605: kdev-astyle : upgrade libastyle to v3.1.

Would this be OK as a fix?

Sep 21 2018, 9:50 AM · KDevelop
rjvbb added a comment to D15605: kdev-astyle : upgrade libastyle to v3.1.

Is there some API dox what one should implement for getPeekStart(), especially which values are valid?

Sep 21 2018, 8:58 AM · KDevelop