GNOME Bugzilla – Bug 744350
Code sharing: Builder/LibIDE/coala
Last modified: 2018-01-11 09:46:38 UTC
Hello, I'm a main developer of coala. coala is meant as a static code analysis framework and currently not a GNOME application. https://github.com/coala-analyzer/coala However in order to realize coala we had to implement some features Builder or LibIDE has or will have. If coala is installed it installs its library which contains all the features described below into the python installation directory. This bug is a proposal to try to reduce code duplication between those three/two projects. coala is still in an early but functional state so big changes to our architecture are possible if it makes sense and saves work for the sum of the involved projects. (I'm not interested in me having not much to do but in reducing the double work.) I'd also be happy to move some features out of coala to some external library if the library tries to maintain platform independence and does not yield huge other dependencies. This is possible for a few features IMO, namely: Project files ============= coala has an own parser (and writer) for project files which are similar to the editorconfig format. This file format allows specifying arbitrary settings grouped in arbitrary sections. Files are specified via recursive globs which is a very intuitive thing to do for the user IMO. As mentioned coala also supports writing project files which is cool because you can generate it from a command line invocation and ask users for missing bits. This is fully implemented and completely unit tested available in coala. We did put a lot of thought into this format and those parsers so I think its worth sharing. Language Definitions ==================== Builder seems to have all its definitions for languages in one file, namely: https://git.gnome.org/browse/gnome-builder/tree/src/resources/language/defaults.ini As we have those parsers mentioned under Project Files, coala will probably support some very similar language definition file format in the near future. Furthermore coala will also ship some default language definitions similar to the one in your ini file. In joining our efforts we could be able to provide our users better and more language definitions while creating a simple and intuitive common file format. See https://github.com/coala-analyzer/coala/issues/250 This feature is not yet implemented but shouldn't be hard to do. Settings Autodetection ====================== I do not know if such a thing is planned for Builder but IMO it is way easier if the editor autodetects the codestyle (tab/spaces, number of spaces, ...). To ease the configuration of coala I am currently planning such a feature for coala. See https://github.com/coala-analyzer/coala/issues/251 Fix-Its ======= IIRC Builder will use clang for live code checking. coala currently supports code checking and code replacements in a sequential workflow. (Which we hope to fix soon.) However the main point and idea of coala is to put an abstraction between the user (which could be a human or Builder) and the code checking routines (like clang invokations). What I'm trying to say is that ultimately Builder could instead of invoking some language specific clang API invoke coala and let coala invoke clang and maybe for some other languages some custom routines. In the end Builder will get a result which is converted to one unified result type. We are already providing Annotations and Replacements. Currently we have a few commits in review that will allow setting dependencies so an AST could be reused for checks from different sources. Caching is on our list too. However note that this probably is a performance overhead over directly invoking clang due to all those abstractions. coala's IDE support is currently in planning stage. See: https://github.com/coala-analyzer/coala/wiki/Project-Ideas#ideoutputter Last and least coala could provide static code analysis features which could ease developing builder. Currently this is limited to searching for keywords, checking line length and automatically correcting spacing issues (tabs <-> spaces, trailing whitespace). I will probably do my bachelor thesis about code duplication detection which will be almost language independent, so hopefully easily adjustable. Those are still simple things but you won't believe me how often I and others had to rebase one of my patches for last GSoC for spacing issues which coala can correct automatically. (More relevant for newcomers.) Many greetings, Lasse Schuirmann
Thanks for taking the time to write all of this. I'm afraid we wont be going in a direction that involves depending on Python projects in the core feature set. This stuff needs to be available in the scripting environment and I want that done as an introspectable C library. As for editor settings, we'll go about implementing that using the editorsettings C library, likely (and some gsettings fallbacks for defaults). In general, what is in src/ is prototype code. Mostly so we could get something in peoples hands to test. Things like defaults.ini for languages will largely go away with LibiDE. Fixits/diagnostics are already language agnostic, so any backend/static-analyzer will be able to provide them for the language of choice. We can certainly make it easy to communicate with an external process using coala here. (We will do the same for gnome-code-assistance as well). But all of that will be hidden behind our abstraction in LibIDE. As for editor settings autodetection, i've seen this work correctly exactly zero times. So I'm not going to be betting on this horse. Uncrustify has some detection code, which is probably the closest I've seen. Can you describe what you mean by "Project Files"?
(In reply to Christian Hergert from comment #1) > Thanks for taking the time to write all of this. Thanks for taking the time to read. > ... > As for editor settings, we'll go about implementing that using the > editorsettings C library, likely (and some gsettings fallbacks for defaults). As explained below, we're currently doing this with our project files. > In general, what is in src/ is prototype code. Mostly so we could get > something in peoples hands to test. Things like defaults.ini for languages > will largely go away with LibiDE. What I'm saying is that coala already provides some finished parts that would maybe help speeding up development of LibIDE. > Fixits/diagnostics are already language agnostic, so any > backend/static-analyzer will be able to provide them for the language of > choice. We can certainly make it easy to communicate with an external > process using coala here. (We will do the same for gnome-code-assistance as > well). But all of that will be hidden behind our abstraction in LibIDE. And thats what I mean with duplicate code. (However its usually not as easy as just saying that. I know.) > As for editor settings autodetection, i've seen this work correctly exactly > zero times. So I'm not going to be betting on this horse. Uncrustify has > some detection code, which is probably the closest I've seen. I can see that this autodetection is probably a difficult task for some settings. But I cannot imagine it to be too difficult e.g. to detect some simpler things like indentation. I'm really annoyed that I have to set those trivial things again and again for each IDE and project and this is why this is important to me personally. Thats why we're planning some certainity value so we can carefully balance thresholds and ask the user if we are too unsure. However I didn't try to implement such a detection yet and I'd be happy to know why it shouldn't work out before I try it out the wrong way. > Can you describe what you mean by "Project Files"? With project files I mean at first a file defining which files belong to a project. (I think you've mentioned something like this in your LibIDE planning document) In coala it also defines arbitrary settings which are split to some sections so you can specify e.g. that you want those Makefiles in your project and want it drawn with indentation of 8 spaces, saved with tabs but want all c files with an indentation of 4 spaces and no tabs. This joining of project definition and custom language settings lets users easily set different settings for different projects and statisfies the special use case of e.g. having multiple files of the same type in one project but with different formatting. If you want a really long description about coala and its project files you can read this one: https://github.com/coala-analyzer/coala/blob/wip/sils/tutorial/TUTORIAL.md It took us two prototypes to get the file format refined and I do like it very much now. If code sharing is not possible you might want to look at some ideal values that might provide useful to you if you didn't already do the same.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-builder/issues/13.