論文英語単語帳/表現集
リンク†
表現集†
評価する†
evaluate†
- We evaluate SketchFix on the Defects4J benchmark [20], which consists of 357 real defects from 5 open source Java applications.
- To evaluate our approach, we designed experiments to determine its effectiveness, running time, and the visual appeal of its solutions.
結果を示す†
suggest†
- Our empirical evaluation suggests that our approach can learn useful API usage models which can provide recommendations with higher levels of accuracy than the baseline n-gram model.
present†
- In this section we present 8 findings of our empirical study, grouped by their relevance to research questions raised in Section 1.
比較する†
compare†
- In Section4.2, we compare SketchFix’s repair efficacy and favored defect types with other automated repair techniques.
- We compare Firefox work pattern with another Mozilla project: Firefox OS.
調査する†
investigate†
- In Section 4.3, we investigate if the on-demand candidate generation could effectively reduce the search space of repair candidates.
- To investigate app crashes, we group their exception traces into three different categories according to their exception signalers.
計算する†
compute†
- First we computed the number of comments related to attached files for each day.
conduct a survey†
- To address RQ3, we conducted a user-based survey to evaluate the aesthetics and visual appeal of the repaired page.
分析する†
analyze†
- In the first phase of this study we analyze a total of 64,445 merge scenarios from 422 Java projects from GitHub using Travis CI and Maven.
リサーチクエスチョンに取り組む†
address†
- We address the following research questions in this section:
are†
- The specific research questions we considered were:
seek to answer†
- In our research experiment, we seek to answer following research questions
- Under our research questions that ask how the activity of joiners differs from that of non-joiners over the same time period, we construct a logistic regression with the aforementioned explanatory variables.
リサーチクエスチョンに回答する†
answer†
- In this section, we answer the first research question by comparing SketchFix’s repair efficacy with other repair techniques— Astor [35], Nopol [7], ACS [58] and HDRepair [25].
この意図は†
intent†
- The main intent of the study was to evaluate the effectiveness of the layout distortion metric, L (Section 3.3), in minimizing layout disruptions and producing attractive pages.
であることを示している†
indicate†
- This might indicate that developers tend to be more direct and focus on what’s the most important when working outside the regular work pattern.
inform†
- Despite being a fairly expected phenomenon, it informs us that software obfuscation at this point is still not a general interest to mobile development.
show†
- These results show that our approach was effective in identifying patches that could reduce the amount of distortion in a solution that was able to pass the mobile friendly test.
imply†
- This implies little opportunity to vary placement outside of our convention, similar to our motivating example in Figure 1a.
であった†
found†
- We found that in contrast to the distribution of all apps in App Store regarding their categories, the distribution of obfuscated apps has a vastly different pattern. This pattern varies further when the impact of third-party libraries is considered.
- Based on our analysis, we found two dominant reasons that applied to all of the nine subjects.
- In our data, the maximum number of possible correct locations across all 31 fixing patches for resource/memory leaks is 3, while the average is 1.7.
see†
- We can see that for the fixable build failures, HireBuild fixed them with time comparable to manual fixes.
発生している/があった†
- occur [#i585120f]
- Resource leaks often occur when a function returns prematurely due to an error [6, 59].
- there are [#z6d606fe]
- Moreover, there are 282 merge scenarios containing EditSameMC instances associated with conflicts.
- be observed [#q73e4d6b]
- A measure, readability of the repaired version was observed to be 62% of the time better than the original version.
- yields
- Not every environment yields equally reliable build results.
改善した†
improve†
- On average, MFix improved the mobile friendliness score of a subject by 33% Overall, these results show that our approach was able to consistently improve a subject’s mobile friendliness score.
- On average, the readability rating of the repaired pages showed a 17% improvement over original versions (original = 5.97, repaired = 6.98).
higer†
- In fact, overall, our repaired versions were rated slightly higher than original versions for attractiveness (avg. original = 6.50, avg. repaired = 6.67 and median original = 6.02, median repaired = 7.12).
と説明できる（考えられる）†
- be explained by
- Overall, the steady drop in build failure ratio can (at least partially) be explained by a strong increase in number of builds per release,
- identify with
- Build inflation seems to correspond to differences/similarities in OSes/environments, which can identify clusters of Perl versions/OSes with different failure ratio and value.
傾向がある†
- have a trend
- However, as the regression line in Figure 3 shows, the overall build failure ratio has a strong decreasing trend between 2011 and 2016, especially when taking into account the logarithmic scale used in the figure.
のケースと一致する†
- case
- These correspond to cases where an API is removed from a Perl version before being added again, or where the implementation of a given API changed behavior.
では，†
for†
- For null dereferences, checks may plausibly be placed anywhere between the point at which an object becomes null and its dereference.
- low [#e5309d31]
- The percentage of agreement for joy in the pilot study was the lowest, with 30.25±5% of the comments containing disagreement.
- less [#w6936933]
- However, all other emotions and cases had less disagreement than 19.25±5% (sadness in pilot study).
- The jagged trend of the black line (percentage of builds) is surprising, suggesting that odd releases see substantially less builds than even ones.
- drop
- Overall, the steady drop in build failure ratio can (at least partially) be explained by a strong increase in number of builds per release, i.e., strong increases in the number of builds and the number of releases per CPAN dist.
あがったりさがったり†
- jagged trend
- The jagged trend of the black line (percentage of builds) is surprising, suggesting that odd releases see substantially less builds than even ones.
と異なり†
- apart from
- Unfortunately, apart from these lump numbers, not much more is known about the build failure ratio of projects, for example about how this ratio evolves over time.
と同様に†
結果をみると†
- moving on [#yb12d2d1]
- Moving on with the analysis, we cross information about merge scenarios containing predictors associated with merge, build, and test conflicts.
- based from [#v217f738]
- Based from these observations, we identified the period from 8 am to 7 pm as the day and from 8 pm to 7 am as the night.
- looking at
- First of all, by looking at the data distribution, we filtered out CPAN dists with less than 10 build results and less than 5 versions.
そのうち†
- , with
- A median of 13.5% of OS build vectors fails inconsistently, with a median of 71% of those having only a minority of OSes failing. Windows (30%) and to some extent Linux/Solaris (7%) figure the most amongst the failing OS minority.
説明できない†
- not be explained
While an increasing number of releases is typical for today’s release engineering strategies [25], the increasing number of builds cannot be explained intuitively.
さらに詳細に分析†
さらに理解するために†
- To better understand these cases
- To better understand these cases, we counted the number of trailing zeroes in this vector as a measure of the time (in terms of number of Perl versions) builds have been
broken for a given OS.
なぜか†
- We investigated the results to understand why two subjects did not pass the GMFT. The patched version of the first subject, gsmhosting, contained a content sizing problem.
- This caused a cascading effect with any change introduced in the page, such as increasing font sizes or decreasing width to fit the viewport.
統計的に分析†
- But during result analysis, we performed statistical analysis to find out the sizes of build-fix patches, and the difference in size between the patches our approach can correctly generate and the patches our approach cannot.
目視で確認†
we performed manual analysis to find out why our approach fails. We check whether the reason is related to generation of version numbers, dependency names, etc.
と推測している†
infer†
- We may infer that although developers working on security-sensitive business sectors do view malicious reverse engineering as a nonneglectable threat, the obfuscation applied to their works is mostly for protecting the information encapsulated in the apps rather than the design and implementation of the software.
たとえ〜でも，〜だろう†
Even if†
- Even if we find dependency based on misscompiled classes, that may not match with actual fixing. Example 10 shows such a dependency update where our approach failed to generate the dependency name.
まとめ†
リサーチクエスチョンのまとめ†
- While some emotions obtain higher agreement than others, only love, joy and sadness obtained at least fair agreement. Although comments clearly contain emotions, raters agree the most on the absence of an emotion. Using more than two raters does not significantly change the results in terms of degree of agreement on emotions.
- The 20 projects use seven ASCATs, and in 11 cases each project use one ASCAT only. ASCATs cause up to 6% of broken builds, and up to 97% of warned builds.
結果全体のまとめ†
であった†
- Overall, these results indicate that MFix was very effective in generating repaired pages that (1) users preferred over the original version, (2) considered to be more readable, and (3) that did not suffer in terms of visual aesthetics.
- Our inspection based on Infer’s bug reports revealed that the number of locations ranges from 1 to 30, which poses more variability for placement.
- In summary, by the end of this study first phase, we select a total 45 projects containing at least one build or test conflict.
うまく働いた†
- Therefore, our approach mainly works in the cases where the number of statement changes is small (1 or 2), which is similar to other automatic repair tools.
キャプション†
- Number of changes to ASCAT configurations.
- Distributions of the number of comments for Firefox OS by day of the week.
- Distribution of the number of comments for Firefox depending on the day of the week.
- Distribution of top 15 languages in our dataset
- Distribution of project sizes
- Percentage of base image types across top 25 images
- Percentage of usage of 15 most commonly used base images
- Percentage of checks activated at least once.
時系列の遷移†
- Evolution of the number of comments for Firefox. Vertical gray lines represent major Firefox releases.
ワードクラウド†
- Comparison wordcloud of comments posted during weekends and weekdays. Words on the bottom, in orange, have a higher probability to appear in comments during weekends than words on the top, in green, which have a higher probability to appear in comments during weekdays.
からわかるように†
- As seen in the figure
- As can be seen from the chart, finding the repair for the mobile friendly problems (phase 3) was the most time consuming, taking up almost 60% of the total time.
- From Figure 5, we can see that build script fix generated by our approach takes minimum 2 minutes, maximum 305 minutes and median value of 44 minutes.
から〜にかけて†
- From ~to~,
- From 2010 to 2014, each year two Perl versions were released, so we
investigated the evolution of failure in period of six months.
では，†
- From
- From the figure, we can see that for fixed build failures, the patch list has minimum size of 68 and maximum size of 2,245, while median is 486. For non-fixed build failures, patch list minimum, median and maximum are 8, 223 and 1,266 respectively, which are lower than fixable build failure’s patch list.
- For
- For 54.16% of evaluated build failures, our approach cannot generate build fix.
すべての分布において†
- Figure 4 shows the distribution of the number of builds, OSes, and environments across all dists.
〜する†
結果の例を示す†
- illustrate
- Shown as Figure 6, we illustrate the quality of the repairs generated by SketchFix using an example.
- Figure 2 illustrates the distribution of the median number of builds and the number of versions across all CPAN dists in our full data set (the number of dists within each quadrant is shown as well).
- show
- Fig. 1 shows that comments are not evenly distributed over the days of the week.
棒グラフでx軸ごとに違いを比較†
- Figure 3 shows the results of comparing the before and after median mobile friendliness scores for each subject.
棒グラフに引かれている横線を説明†
- The black horizontal line drawn at 80 indicates the value above which the GMFT considers a page to have passed the test and to be mobile friendly
黒い線は†
- Black lines show the lower and upper thresholds that we determined for the median number of builds and number of versions for each dist.
分布の違い†
- Figure 5 shows the differences between these distributions, leading to the following key observations
プロポーション†
- For both systems we computed the proportion of daily comments made during the night, and the proportion of comments made during a weekend day compared to a weekday.
ログスケール†
- logarithmic scale
- especially when taking into account the logarithmic scale used in the figure.
キャプション†
- Table III provides detailed results regarding severity.
- SketchFix is able to generate repairs for the subjects shown in Table 3.
- The results are presented in Table 2 and Table 3, respectively.
- Table 1 show results for each project. “Bugs” indicates the number of bugs detected by Infer of the given type.
数とパーセンテージ†
- Table 11 shows for each study the number and percentage of comments for which both raters assigned to the same comment agreed on all 6 emotions.
- We present the odds ratios and their and standard errors in Table 3; the numbers with asterisks are those which were significant for a p < .05.
ピックアップ†
- The most notable kind of third-party libraries is for advertising purposes with both metrics being the highest in Table 1.
ソースコード例†
- Figure 6 shows a snippet of the code in question.
を実施†
- All results are statistically significant with the Wilcoxon rank-sum test with the Benjamini-Hochberg correction.
有意差がある†
- For our metrics concerning relationships, we found significant differences for three metrics in both analyses: the number of pull requests, comments on other people’s pull requests, and the days since first interactions. All of these metrics have positive effects in both analyses.
- The number of issue comments was significant in Analysis 2 only.
- we also included in each table the pairwise difference for each metric. That is, we subtracted the quantities of nonjoiners’ metrics from the quantities of joiners. A positive result indicates that the joiner had more activity in that dimension than the nonjoiner
- The highest number of such agreement occurred for group A in round 1, while the same group obtained the lowest agreement in round 2, statistically significantly lower than in three of the other cases (except for the pilot study).
- We observed that relative activity in Firefox OS is significantly lower during weekends than for Firefox.
エフェクトサイズ†
- While we both observe a statistically significant difference between projects for both weekend and night work, the effect size of the weekend work is large (Mann–Whitney U test p-value < 0.001, Cohen’s d = 0.94, Cliff’s δ = 0.77) and neglible for night work (Mann–Whitney U test p-value < 0.01, Cohen’s d = 0.06, Cliff’s δ = 0.06).
記述統計（平均的に．．．）†
- We include the descriptive statistics as well, first, in order to characterize our data more concretely, and second, to point out that joiners are, on the surface, more active in general across every kind of activity within the software communities.
- we report the medians and interquartile ranges (IQRs, or the 25%th and 75%th percentiles) of these differences in the rightmost columns of each table.
- Furthermore, the quantities that characterized joiners tended to be higher, or at least not lower, to their nonjoining peers in every respect.
影響があった†
have impact†
- Patch size has impact on automatic program repair.
関係している†
- Project specific change adaption indicates those changes that are dependent on project structure, file path etc.
その他†
- We preferred medians to means because they were more insensitive to the influence of outliers in our data.
精度が†
- The Bernoulli Naive Bayes models achieved its highest accuracy of 20.52% with N-Grams of ranges 1, 2, and 3. Its micro-average ROC AUC was 0.60, as shown in Table 1. AUC’s for each target class, or target command, ranged from 0.5 to 0.96, with a mean of 0.55 and standard deviation of 0.10.
- The Multinomial Naive Bayes models achieved its highest accuracy of 20.14% with N-Grams of ranges 1, 2, and 3. Its micro-average ROC AUC was 0.59, as shown in Table 1. AUC’s for each target class, or target command, ranged from 0.5 to 0.97, with a mean of 0.61 and standard deviation of 0.14.
- The Logistic Regression model achieved its highest accuracy of 35.87% with N-Grams of ranges 1, 2. Its micro-average ROC AUC was 0.67, as shown in Table 1. AUC’s for each target class, or target command, ranged from 0.50 to 0.95, with a mean of 0.63 and standard deviation +/- 0.12.
回帰係数などが＋orーである†
- For metrics of the individual developer, the number of commits to personal projects and personal followers had a significantly positive impact on joining.
- For team metrics, the number of projects, pull requests, and overall number of contributors had a positive impact on joining, whereas the number of people watching or forking the team had a negative impact on joining and overall number of commits.
その他†
紙面の制約で†
- Due to limited space, we only list categories with significant relevance to the discussions in Finding A.2. It may cause confusion that a small number of apps or libraries do not employ symbol renaming.
Future works†
- These results motivate future work in techniques that can better handle these types of pages.
付録にまとめる†
- For further information on our sample, we provide a complete subject list on our online appendix [1].
![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
