dataesr/scientific-paragraphs-categorization huggingface dataset:
D. Performance (RQ #4) To investigate if STYLER can be used in practice, we measure the execution time spent when running STYLER on the real error dataset. Table  IV  shows the minimum, median, average, and maximum spent time on projects, split over the different steps from the STYLER workflow. For training data generation, STYLER took at least 16 minutes and up to six and a half hours. To tokenize the training data, it took up to 13 minutes, and for training the models, it took mostly about one hour. Therefore, the training of STYLER (data generation + tokenization + model training) took around two hours and a half on average. This can be considered just fine, since the  STYLER employs a machine-learning-based approach for repairing formatting convention violations. An alternative approach would be a rule-based one.
For instance, there would be one transformation to be applied in the code per Checkstyle rule. As said, this approach requires the engineering of a transformation for every single linter rule, which is timeconsuming. While this is costly, this might be even impractical for highly configurable linters such as Checkstyle: the rulebased repair system would need to have different transformations for the same linter rule due to the configurable properties. On the contrary, a machine learning approach does not require costly human engineering. It is able to infer transformations for a diverse set of linter rules. Our experiments have validated this property in the context of formatting errors raised by Checkstyle.
B. Threats to Validity STYLER generates training data for repairing errors based on the Checkstyle configuration file contained in a given project. This means that STYLER assumes that all formatting rules contained in the Checkstyle configuration file are valid. In practice, however, developers might ignore the violations of certain rules. Our experiment does not take this scenario into account, thus we do not claim that 100% of the fixes produced by STYLER are necessarily relevant for developers. The real error dataset contains Checkstyle errors mined from GitHub repositories. It is to be noted that it does not cover all existing Checkstyle formatting rules. It is worth to mention that we are still collecting real errors, and those can potentially cover new rules. Moreover, the dataset might not be representative of the real distribution of the 19 rules in the real world.
[38] investigated the usage of static analysis tools from the perspective of the development context in which these tools are used. For that, they surveyed 42 developers and interviewed 11 industrial experts that integrate static analysis tools in their workflow. They found out that static analysis tools are used in three main development contexts, which are local environment, code review, and continuous integration. Moreover, they also found out that developers differently consider warning types depending on the context, e. g. , when performing code reviews they mainly look at style conventions and code redundancies. [22]  focused on one specific static analysis tool:  [33]. Through an online survey with 18 developers from different organizations, they found out that most respondents agree that the issues reported by static analysis tools are relevant for improving the design and implementation of software.
There are some tools to fix errors raised by specific linters. For instance, ESLint  [13]  is a linter for JavaScript, but it also includes automated solutions to repair errors raised by it. For Python, there exists the autopep8 tool [5], which formats Python code to conform to the PEP 8 Style Guide for Python Code  [27]. For Java, there exists the CHECKSTYLE-IDEA  [9]  plugin for IntelliJ, which we used to be compared to STYLER. CHECKSTYLE-IDEA is able to highlight the error and also to suggest fixes in some cases. However, it is very limited in repairing errors from several different rules as we have shown in RQ #2. Code formatters. A way to enforce formatting conventions lies in code formatters. In Section V-C, we described NATURALIZE  [3]  and CODEBUFF  [26] : NATURALIZE recommends fixes for coding conventions related to naming and formatting in Java programs, and CODEBUFF infers formatting rules to any language given a grammar.
Similar to the idea behind CODEBUFF,  [30]  had previously experimented with different learning algorithms and feature set variations to learn the style of a given corpus so that it could be applied to arbitrary code. Beyond those academic systems, there are code formatters such as google-java-format  [15] , which reformats source code according to the Google Java Style Guide  [16] , and as such fixes violations of the Google Style. However, these formatters are usually not configurable or require manual tweaking, which is a tedious process for developers. This is a problem because not all developers are ready to follow a unique convention style. STYLER, on the other hand, is generic and automatically captures the conventions used in a project to fix formatting violations.
Algorithm 1 Batch injection of Checkstyle errors in Java files. Input: ruleset -Checkstyle configuration of the project under consideration Input: f iles -corpus of error-free Java files taken from the project Input: numberOf Errors -number of errored files to be generated Input: protocol in [Styler random , Styler 3grams ] Output: dataset with Checkstyle errors 1: const BAT CH_SIZE ← 500 2: var dataset ← {} 3: while dataset. length < numberOf Errors do.
Algorithm 1 Batch injection of Checkstyle errors in Java files. Input: ruleset -Checkstyle configuration of the project under consideration Input: f iles -corpus of error-free Java files taken from the project Input: numberOf Errors -number of errored files to be generated Input: protocol in [Styler random , Styler 3grams ] Output: dataset with Checkstyle errors 1: const BAT CH_SIZE ← 500 2: var dataset ← {} 3: while dataset. length < numberOf Errors do 4: var modif iedF iles ← {} 5: for i ← 0; i < BAT CH_SIZE; i + + do 6:.
The tremendous advancement of cardiac imaging methods, the substantial progress in predictive modelling, along with the amount of new investigative multimodalities, challenge the current technologies in the cardiology field. Innovative, robust and multimodal tools need to be created in order to fuse imaging data (e. g. , MR, CT) with mapped electrical activity and to integrate those into 3D biophysical models. In the past years, several cross-platform toolkits have been developed to provide image analysis tools to help build such software. The aim of this study is to introduce a novel multimodality software platform dedicated to cardiovascular diagnosis and therapy guidance: MUSIC. This platform was created to improve the image-guided cardiovascular interventional procedures and is a robust platform for AI/Deep Learning, image analysis and modelling in a newly created consortium with international hospitals.
Introduction With the substantial progress in medical imaging and the boosting of multimodalities, it becomes increasingly challenging to obtain a comprehensive and integrated 3D view of a given heart. Unequivocally, most of these are consequences of larger size of acquired data (often in multiple centres), complex fusion of the imaging modalities, and variability in cardiac function. MUSIC (Multimodality Platform for Specific Imaging in Cardiology) is a software platform developed by the Multimodal Data Science team (https://www. ihu-liryc. fr/en/ technology-for-health-cluster/p/mds/, accessed on 1 June 2022) at Liryc IHU (https://www. ihu-liryc. fr accessed on 1 June 2022) and the Epione (https://team. inria. fr/epione/, accessed on 1 June 2022) and Carmen (https://team. inria. fr/carmen/, accessed on 1 June 2022) Inria (http://www.
inria. fr, accessed on 1 June 2022) teams that aims to offer a large spectrum of functionalities and processing pipelines dedicated to cardiology applications for both diagnosis and therapy guidance. The MUSIC project is led by a multidisciplinary team including researchers, developers, clinicians and medical imaging operators. MUSIC is composed of a desktop application, a web portal, and an academic consortium. The desktop application is called MUSICardio and is built on the open-source software medInria (http://med. inria. fr, accessed on 1 June 2022), which comprises a large set of versatile tools for medical image segmentation, visualisation, filtering, histogram analysis, data reformatting, registration and mesh processing, all of which are being provided to the community with a user-friendly common framework for more efficiency.
Treatment improvement: MUSIC offers image-based algorithms for diagnosis and prognosis as well as pipelines dedicated to the guidance of either atrial or ventricular interventions through imaging. For instance, this application has been used to guide scar-related ventricular tachycardia (VT) ablation in over 500 consecutive procedures in Bordeaux University Hospital. A booster for research: MUSICardio is an application allowing the analysis, in one environment, of multi-parametric data sets from different Liryc IHU teams (structural, mechanics, hemodynamics, electrical, etc. ) and to interface with simulation platforms such as SOFA (https://www. sofa-framework. org/, accessed on 1 June 2022), CEPS (https://carmen. gitlabpages. inria. fr/ceps/, accessed on 1 June 2022), and CARP (https://carp.
medunigraz. at/, accessed on 1 June 2022), in order to develop patient-specific modelling and simulation strategies. Our researchers can therefore use directly in MU-SICardio our medical image analysis and processing algorithms to obtain quantitative information to improve the diagnosis of heart disease. A VT MUSIC consortium has been created including more than 30 international hospitals with expertise in ventricular tachycardia from Europe, USA and Australia. Participating centres anonymise and upload their data to our MUSIC web portal, then our expert operators process the data in the MUSICardio software to obtain customised models of the heart. These new data are then sent back to the hospitals, which can immediately include them during operations to visualise catheters in real time in patient-specific heart modelling.
Some imaging platforms similar on some points to MUSIC allow us to situate ourselves: OsiriX (https://www. osirix-viewer. com, accessed on 1 June 2022) and Horos (https://horosproject. org, accessed on 1 June 2022) (OsiriX fork) are imaging applications allowing the reading of DICOM from sources or PACS systems, data visualisation in 2D/3D/4D, and have imaging tools and algorithms. They can be compared to our MUSICardio application within the MUSIC platform. There are differences: MUSICardio is dedicated to cardiology with dedicated tools, imports and exports several data types in addition to DICOM, and has a pipeline system of Python scripts allowing to chain tools and algorithms very easily for the users. OsiriX has two versions: one not free and FDA/CE certified, and the other free and non-certified.
Horos is free and suggests a donation. Both applications are compatible only with macOS. MUSICardio is compatible with macOS, linux (Ubuntu) and Windows. Another similar application is 3DSlicer (https://www. slicer. org, accessed on 1 June 2022). It is a free and open-source medical imaging software. The common points with MUSICardio: 3DSlicer is compatible with macOS, linux and Windows; it allows the display of different types of medical data such as DICOM or meshes, offers algorithmic imaging treatments, AI-assisted segmentations and scripting in Python. For its part, MUSICardio also has algorithms and tools dedicated to cardiology. These tools are similar to our MUSICardio application, however they do not cover all the functionalities of our MUSIC platform dedicated to cardiology: the MUSICardio application, the web portal, as well as the dedicated consortium, in particular the expertise of our medical operators and clinicians within the consortium.
Consortium The VT MUSIC consortium brings together international centres with expertise in ventricular tachycardia and our institute. The data acquired in the hospitals are sent to us through a web portal and processed rapidly by our expert operators in our MUSICardio application. Thus, personalised models of the patient heart can be sent to the centres to be included in cardiac operations. Figure  1  shows the process of the consortium for the particular case of radiotherapy. VT centres interested in joining the consortium are invited to contact our team. Access to the consortium is free.
Web Portal A web portal has been developed in Java through the Play framework (https://www. playframework. com, accessed on 1 June 2022). Users of the VT MUSIC consortium can anonymise their images through an anonymisation tool that we developed. Then, the web server allows users to upload these anonymised data and add relevant information for our operators and clinicians. The data are downloaded by our operators who process them in our MUSICardio application. Finally, the generated cardiac models are uploaded to the web portal and can be retrieved by hospital users for use during cardiac operations. In addition to the web portal, a mesh viewer developed by our team is provided so that clinicians from the VT MUSIC consortium hospitals can study the heart meshes before surgery.
Usage There are three current ways of using MUSICardio. The application can be directly used by our researchers for instance to use algorithmic tools developed by our team. Researchers, post-doctoral fellows, PhD students or other members of our laboratory can also write Python scripts, with the help of our team, to create pipelines to process and analyse their data in the application. Python is an understandable language for nondevelopers, and it can be learnt quickly and easily. Pipelines allow complex suites of algorithms and tools to be processed in simple graphical steps in MUSICardio, making it easier for users, especially if they have to perform the tasks many times. Finally, our expert operators (who are trained medical imagery staff, and formed to use our VT pipeline script in MUSICardio) can process our pipeline in MUSICardio, using as input the data sent by partner hospitals in the VT MUSIC consortium, and they can send back the output heart models to these hospitals.
Pipelines Processing workflows can be executed through a pipeline system included in the MUSICardio application. This allows us to script complex process sequences in order to simplify the work of the operators, make the results more robust and obtain the output data fast. The pipeline scripts were developed in Python, allowing researchers and operators to create and adapt their own customised pipelines. For instance, within the VT MUSIC consortium, clinicians and expert operators at Liryc IHU use the pipeline system to segment CT and MR images, and to generate a 3D structural model comprising a detailed anatomy of the whole heart, myocardial scar maps from CT-derived wall thickness or late-enhancement MRI analysis, structures at risk during SBRT (stereotactic body radiotherapy) procedures, or other structures such as coronaries, left phrenic nerve, atrioventricular node, ICD (implantable cardioverter defibrillator) lead tip, GI (gastrointestinal) tract, etc.
Data Format The data management system in the MUSIC project includes local databases per user managing the data imported or generated by the MUSICardio application, access from the application to several data sources including PACS systems, and our online web portal that allows hospitals in the VT MUSIC consortium to send their data to our institute and to receive output data from us. Within the application, users can import and export data in various formats, including VTK, ITK, DICOM, Nnrd, GIS, Nifti, Gipl, OBJ, STL, Medit, etc. MUSICardio can export data to electrophysiology mapping systems such as BioSense Webster, Johnson & Johnson (New Brunswick, NJ, USA) "CARTO", Boston Scientific (Natick, MA, USA) "RHYTHMIA", and Saint-Jude Medical (Saint Paul, MN, USA) "EnSite NavX". Within the VT MUSIC consortium, these compatible data are sent to VT centres around the world where clinicians can visualise their catheters in real time inside a virtual patient-specific heart created in the application through their navigation systems.
Artificial Intelligence Deep Learning-based algorithms developed by our team have been recently included in Python script pipelines and further used in the MUSICardio application. These AI algorithms included in the scripts can improve the accuracy of cardiac segmentation and speed up the analysis and computations, resulting in a less invasive patient diagnostic, a more precise treatment, as well as a better therapy outcome. The Python support in MUSICardio pipeline allows us to access an unlimited number of calculation libraries, including the AI libraries such as: TensorFlow, PyTorch, and scikitlearn. The pipeline script also has several extended front-end controls of the MUSICardio interface, which are able to facilitate the visualisation of processing steps undertaken during the AI project.
The automatic image segmentation is performed using a pre-trained Dual-UNet segmentation network, while the VA classifier network consists of a conditional variational autoencoder and a fully connected classifier model. The two DL networks and all matrix calculations can be integrated directly in the pipeline Python script. The complete image processing pipeline is presented in Figure  11. The pipeline ends with the VA classification from the 2D wall thickness map using a conditional variational autoencoder and a fully connected classifier model. A so-called "attention map" is also generated from the gradient back propagation of the classification score. The thickness map, attention map and classification score can be displayed at the end of the pipeline, as shown in Figure  12. The pipeline that was implemented and designed to be used case by case was not adapted for the processing of multiple inputs/outputs required for the development stage of the AI models.
Therefore, both AI models were built, trained and validated outside of MUSICardio using the Python environment and packages, including TensorFlow (Deep Learning algorithms) and SimpleITK, Numpy and VTK (image processing). The segmentation network was built using two consecutive 3D UNet models. The first model was used to coarsely segment the heart regions, which was used to crop the region of interest to be used as input in the second segmentation model for refine segmentation. The model achieved a Dice score of 0. 90 for left ventricle wall segmentation on the validation dataset. Similarly, the post-infarct VA prediction was trained using a retrospective dataset of 600 patients (27. 5% VA). The validation on the test dataset showed the prediction accuracy of 79. 2%, sensitivity of 73. 2% and specificity of 81.
5%. The architectures of the AI networks used in the example pipeline are shown in Figure  11. Once a model such as this has been built, it can be implemented in MUSICardio pipelines for direct use: the compatibility of the application to run and install Python packages allows the direct integration of internal and external image processing tools, as well as the pre-trained AI models, into a single MUSICardio pipeline. Thus, MUSICardio proves to be a powerful tool to quickly prototype a fully functioning AI-based project.
Discussion The MUSIC project brings together various partners in the cardiology world: hospitals, research institutes, and therefore clinicians, researchers, developers, modelling engineers, database specialists, etc. This mixture of professions and objectives requires communication, adaptation and imagination in order to develop computer tools as well as interfaces that correspond to the greatest number of people. In particular, the tools must be easy to use and adapted to the needs of the medical world, which prefers stable and intuitive tools. They must also be modular enough to be used by the researchers who are less interested in stability than in rapid prototyping of the tools and algorithms, and who may want to change the parameters and the tools employed more frequently. The plurality of our users also requires cross-platform applications, including developing and testing on macOS, Windows and Linux.
Thus, a continuous integration process had to be created and improved in order to obtain stable and efficient software tools. Our quality approach is necessary because of the plurality of our users but also because we can promote our code through spin-off companies. The inHEART (https://www. inheart. fr, accessed on 1 June 2022) spin-off was created jointly by Liryc IHU and Inria, and it is based on a version of our software. It is thus required to have a controlled development processes in order to help with the regulatory process needed for any software as a medical device. An important issue in the development of clinical and research applications is the long-term funding of personnel and equipment not only for software development and continuous improvement but also for database management, beta testing, management, etc.
This is not always present in classical academic funding. For now, the web portal is accessible only by the members of the VT MUSIC consortium. Our imaging application MUSICardio is accessible by members of our laboratory: researchers and engineers for research purposes, and expert operators and clinicians for the VT MUSIC consortium. The core of MUSICardio (medInria) is open-source and can be tested by the public; however, a lot of the functionalities that we developed are private for now. Our tools must also manage more and more data, some of which are very heavy. This impacts the technologies we can use but also the minimal hardware that users must have to run our software: processors, graphics card, hard disk, etc. The balance is complicated to find between the power needed to visualise and apply treatments on very large data and the power of the computers that users can have, especially in hospitals or research centres.
Perspectives The MUSIC project continues to be developed and improved. We are currently working on a future version of the MUSICardio 4 software in close collaboration with the Inria team that handles medInria. This new version will include new algorithms, tools, and will be based on medInria 4 on which we work also. New features will include an improvement of the global GUI of the software, the data management system as well as the management of plugins. We have started an exploratory work of real-time simulation of catheters during a cardiac intervention in MUSICardio. This could allow us to display in real time a catheter in the application and to superimpose it with patient images or meshes to study their relative positions. We also want to develop augmented reality tools to display and manipulate meshes in MUSICardio.
This will allow us to study mesh in more detail as well as communicate about our tools in scientific events, and it is a first step to study the use of augmented reality in diagnostic or operative cardiology. It would also be interesting to certify our binaries by Microsoft and Apple software platforms to simplify their installation. This would allow an official installation in hospitals where computer security is omnipresent: clinicians often do not have the computer rights to install unofficial software, so it can take a long time or a complicated route to install new software on these computers. In addition, an online mesh viewer developed in Three. js (https://threejs. org, accessed on 1 June 2022) has been developed. It is currently deployed on the network of our laboratory for beta-testing, and it aims to replace the mesh viewer (desktop application) provided by our team to hospitals inside the VT MUSIC consortium.