1. 01 Nov, 2017 1 commit
  2. 31 Oct, 2017 1 commit
  3. 30 Oct, 2017 1 commit
  4. 27 Oct, 2017 3 commits
    • Gleb Popov's avatar
      Make kdev{debuggercommon, gdb, lldb} compile under Windows. · 4460a8b3
      Gleb Popov authored
      Summary:
      This patch basically stubs out all stuff that doesn't compile right away.
      Most stuff is located in stty.cpp.
      
      From what I've found, Windows does not have a mention of "tty", so `STTY::OutOutput`/`STTY::ErrOutput` can't possible fire. This, in turn, makes `MIDebugSession::inferiorTtyStdout`/`MIDebugSession::inferiorTtyStderr` not fire.
      In the end, KDevelop doesn't get any output from the debuggee.
      
      If I understand it right, we need a way to fire `MIDebugSession::inferiorTtyStdout` when getting
      output right in MI's console, but I haven't looked at it yet.
      
      Reviewers: #kdevelop
      
      Subscribers: kdevelop-devel
      
      Differential Revision: https://phabricator.kde.org/D8508
      4460a8b3
    • Kevin Funk's avatar
      Merge remote-tracking branch 'origin/5.2' · 86396270
      Kevin Funk authored
      86396270
    • René J.V. Bertin's avatar
      AbstractFileManagerPlugin import benchmark · cf956a12
      René J.V. Bertin authored
      Benchmarks the duration of importing a directory as a project, something
      that can be determined largely by the time it takes to set up a
      KDirWatch instance monitoring the entire tree for changes.
      
      Current results using the gcc 7.2.0 source tree:
      
      On Linux (kernel 4.9.30-ck1 on a 1.6Ghz N3150 with 8Gb RAM and using ZFS
      on a Seagate SSHD):
      
      > perf stat -r 3 abstractfilemanagerpluginimportbenchmark gcc-7.2.0
      KDirWatch backend: Inotify
      Starting import of project gcc-7.2.0
              creating dirwatcher took 1.265 seconds
      importing project 0 took 3.162 seconds
      Done in 4.428 seconds total
      KDirWatch backend: Inotify
      Starting import of project gcc-7.2.0
              creating dirwatcher took 1.232 seconds
      importing project 0 took 3.098 seconds
      Done in 4.331 seconds total
      KDirWatch backend: Inotify
      Starting import of project gcc-7.2.0
              creating dirwatcher took 1.307 seconds
      importing project 0 took 3.14 seconds
      Done in 4.448 seconds total
      
       Performance counter stats for 'abstractfilemanagerpluginimportbenchmark gcc-7.2.0' (3 runs):
      
             5115.785502      task-clock:u (msec)       #    0.976 CPUs utilized            ( +-  0.84% )
                       0      context-switches:u        #    0.000 K/sec
                       0      cpu-migrations:u          #    0.000 K/sec
                  23,868      page-faults:u             #    0.005 M/sec                    ( +-  0.86% )
           4,749,860,940      cycles:u                  #    0.928 GHz                      ( +-  0.14% )
           3,097,364,964      instructions:u            #    0.65  insn per cycle           ( +-  0.01% )
             741,470,473      branches:u                #  144.938 M/sec                    ( +-  0.02% )
              23,852,653      branch-misses:u           #    3.22% of all branches          ( +-  0.23% )
      
             5.241247911 seconds time elapsed                                          ( +-  0.76% )
      > env KDIRWATCH_METHOD=QFSWatch time perf stat -r 3 abstractfilemanagerpluginimportbenchmark gcc-7.2.0
      KDirWatch backend: QFSWatch
      Starting import of project gcc-7.2.0
              creating dirwatcher took 183.192 seconds
      importing project 0 took 3.54 seconds
      Done in 186.734 seconds total
      KDirWatch backend: QFSWatch
      Starting import of project gcc-7.2.0
              creating dirwatcher took 176.655 seconds
      importing project 0 took 4.017 seconds
      Done in 180.672 seconds total
      KDirWatch backend: QFSWatch
      Starting import of project gcc-7.2.0
              creating dirwatcher took 175.662 seconds
      importing project 0 took 3.14 seconds
      Done in 178.803 seconds total
      
       Performance counter stats for 'abstractfilemanagerpluginimportbenchmark gcc-7.2.0' (3 runs):
      
           175971.327864      task-clock:u (msec)       #    0.959 CPUs utilized            ( +-  1.38% )
                       0      context-switches:u        #    0.000 K/sec
                       0      cpu-migrations:u          #    0.000 K/sec
                  34,114      page-faults:u             #    0.194 K/sec                    ( +-  0.48% )
         310,070,244,556      cycles:u                  #    1.762 GHz                      ( +-  0.20% )
          54,088,827,245      instructions:u            #    0.17  insn per cycle           ( +-  0.00% )
           8,733,088,527      branches:u                #   49.628 M/sec                    ( +-  0.00% )
             206,976,905      branch-misses:u           #    2.37% of all branches          ( +-  0.35% )
      
           183.439620257 seconds time elapsed                                          ( +-  1.32% )
      
      On Mac (OS X 10.9.5 on a 2.7Ghz i7, 12Gb RAM, compressed HFS+ on a
      Hitachi SSD):
      
      > repeat 3 time abstractfilemanagerpluginimportbenchmark gcc-7.2.0
      KDirWatch backend: QFSWatch
      Starting import of project gcc-7.2.0
              creating dirwatcher took 86.876 seconds
      importing project 0 took 2.895 seconds
      Done in 89.772 seconds total
      75.877 user_cpu 11.942 kernel_cpu 1:31.34 total_time 96.1%CPU
      KDirWatch backend: QFSWatch
      Starting import of project gcc-7.2.0
              creating dirwatcher took 88.521 seconds
      importing project 0 took 2.679 seconds
      Done in 91.2 seconds total
      77.313 user_cpu 12.010 kernel_cpu 1:32.54 total_time 96.5%CPU
      KDirWatch backend: QFSWatch
      Starting import of project gcc-7.2.0
              creating dirwatcher took 85.653 seconds
      importing project 0 took 2.591 seconds
      Done in 88.244 seconds total
      75.125 user_cpu 11.788 kernel_cpu 1:29.56 total_time 97.0%CPU
      228.320 user_cpu 35.749 kernel_cpu 4:33.46 total_time 96.5%CPU
      
      Differential Revision: https://phabricator.kde.org/D8059
      cf956a12
  5. 26 Oct, 2017 5 commits
  6. 25 Oct, 2017 2 commits
  7. 24 Oct, 2017 8 commits
  8. 23 Oct, 2017 2 commits
  9. 22 Oct, 2017 1 commit
    • Friedrich W. H. Kossebau's avatar
      Restore NavigationToolTips for file items in projects manager · 07bcde0d
      Friedrich W. H. Kossebau authored
      Summary:
      With the introduction of ProjectModelItemDelegate the tooltip events for
      items have been handled by its inherited QItemDelegate::helpEvent(), thus
      somehow no longer bubbling to ProjectTreeView::event().
      As a result no longer the NavigationToolTips were shown for supported file
      items, only the full path as delivered by ProjectModel.
      
      This patch restores that behaviour, by moving the respective code to the
      helpEvent handler of ProjectModelItemDelegate.
      
      Reviewers: #kdevelop, mwolff
      
      Reviewed By: #kdevelop, mwolff
      
      Subscribers: mwolff, kdevelop-devel
      
      Differential Revision: https://phabricator.kde.org/D8410
      07bcde0d
  10. 20 Oct, 2017 5 commits
  11. 19 Oct, 2017 1 commit
  12. 18 Oct, 2017 2 commits
    • Christoph Roick's avatar
      Allow abortion of starting another NativeAppJob · d896e748
      Christoph Roick authored
      Summary:
      - offers to cancel an accidental startup of an already running job
      - kill all running instances instead of one by one
      - fix: do not ask again if "No" was already selected
      
      Test Plan:
      - start second instance of an already running job
      - select
          * Kill All Instances (No) (kills all running instances)
          * Start Another (Yes) (just starts a new instance)
          * Cancel (closes the dialog and drops the new job)
      
      Reviewers: #kdevelop, mwolff
      
      Reviewed By: #kdevelop, mwolff
      
      Subscribers: kfunk, mwolff, kdevelop-devel
      
      Differential Revision: https://phabricator.kde.org/D8199
      d896e748
    • Aaron Puchert's avatar
      Don't try to guess the language from given arguments · 9ec89cdc
      Aaron Puchert authored
      Summary:
      Before this change, the compiler provider looked up the arguments for a
      given language, and passed those to the compiler, where the language was
      guessed from the arguments.
      
      Instead we now pass the language together with the arguments into the
      function, and no more guessing is needed. Besides being cleaner, it may
      not always be possible to guess the language from the given arguments
      anyway.
      
      Reviewers: #kdevelop, mwolff
      
      Reviewed By: #kdevelop, mwolff
      
      Subscribers: mwolff, apol, kdevelop-devel
      
      Differential Revision: https://phabricator.kde.org/D8317
      9ec89cdc
  13. 17 Oct, 2017 3 commits
    • Friedrich W. H. Kossebau's avatar
      Fix registration of the enabled state of plugins · 35f3f710
      Friedrich W. H. Kossebau authored
      Summary:
      The old code was slightly broken:
      At start-up plugin controller updated the config storage only for the
      enabled state of the global-category plugins (and indirectly their
      dependency plugins). Project-category plugins would only get an update
      indirectly once loadProjectPlugins() was run, other plugins only once
      the were requested by their interface.
      Thus in a new session with no project yet loaded the config storage would
      not yet cover the enabled state of the project-category plugins and those
      other.
      
      PluginPreferences code queried the initial enabled state of each plugin
      from the plugin controller, which then has extra code in the isEnabled()
      method to deal with that. Though that information is dropped and replaced
      with the one fetched from the config storage, multiple times even:
      * the plugins are added to the selector using the flag
        KPluginSelector::ReadConfigFile, which results in the data manually set
        to each KPluginInfo instance with kpi.setPluginEnabled(...) being
        overwritten with the config storage data
      * selector->load() was called after plugins were added, which results
        in the same update from the config storage data
      * the PluginPreferences instance like each KDevelop::ConfigPage gets an
        initial call of the reset() method on setup, which again calls
        selector->load()
      Which results in the plugin selector showing wrong enabled state at least
      for new sessions, where no project has been loaded yet and not all plugins
      at least been tried to load once.
      While the first two times of data drop could be fixed, the third would be
      more complicted to do.
      
      So instead of keeping the current on-the-fly enabled state calculation for
      non-global-category plugins, on start-up the config storage is updated for
      any known plugin (and then consecutively updated if failing to load a
      plugin when needed). This gives the plugin selector and any other code
      consistent data and simplifies things.
      
      Next to this, this patch also restores ShellExtension::defaultPlugins()
      power to control which plugins should be loaded by default. Thus any
      tests which (try to) make use of the AutoTestShell::init plugin list
      feature can (and have to) now explicitly define all userselectable plugins
      which should be used (thus also using the correct plugin id :) ).
      
      Test Plan:
      Create a new session, open directly the plugin selection settings and see
      that all build and projectmanager plugins but also the QML plugin are shown
      as enabled, as they should be.
      
      Reviewers: #kdevelop, mwolff
      
      Reviewed By: #kdevelop, mwolff
      
      Subscribers: mwolff, kdevelop-devel
      
      Differential Revision: https://phabricator.kde.org/D8156
      35f3f710
    • Friedrich W. H. Kossebau's avatar
    • Script Kiddy's avatar
      SVN_SILENT made messages (.desktop file) - always resolve ours · 5aca467f
      Script Kiddy authored
      In case of conflict in i18n, keep the version of the branch "ours"
      To resolve a particular conflict, "git checkout --ours path/to/file.desktop"
      5aca467f
  14. 16 Oct, 2017 2 commits
  15. 15 Oct, 2017 3 commits