[codeface] Re: Bugfixes and copyright header cleanups

  • From: Wolfgang Mauerer <wolfgang.mauerer@xxxxxxxxxxxxxxxxx>
  • To: <codeface@xxxxxxxxxxxxx>, <rqueiroz@xxxxxxxxxxxxxxxx>, Mitchell Joblin <joblin.m@xxxxxxxxx>
  • Date: Thu, 23 Jun 2016 00:19:23 +0200

Hi Rodrigo,

(Mitchell, Claus: Some stuff for you at the end of this email)

Am 21/06/2016 um 21:20 schrieb Rodrigo Queiroz:

Hi Wolfgang,

Thanks for the updates. I started using codeface just now for a new
project and 
never had a fully working/tested build before to make a better analysis
of the updates.

thanks for your detailed investigation! FYI, branch for-upstream should
in its current state work with Xenial (Ubuntu 16.04) on Virtualbox, so
you should be able to use Codeface out of the box.

Master Branch:
My first build was from the Master branch, using vagrant and virtualbox
(using R 3.2.5)
The package plyr causes this error at the cluster phase:
--

    2016-06-15 23:55:39 [codeface.util] MainProcessINFO:   -> Revision
    range v3.8..v3.9: Detecting clusters...
    Error in unloadNamespace(package) :
      namespace 'plyr' is imported by 'ggplot2', 'scales', 'reshape' so
    cannot be unloaded
    Error in library(plyr) : Package 'plyr' version 1.8.3 cannot be unloaded
    Calls: suppressPackageStartupMessages -> withCallingHandlers -> library
    Execution halted

that seems to be a problem in upstream ggplot and plyr. I can reproduce
this issue; it comes down to the fact that the order in which ggplot and
plyr are loaded has become important recently, which seems a bug to me.
I did not investigate the issue further, but decided to take the
opportunity to rebase the whole distribution to a more recent Ubuntu
version.

Unfortunately, things used to work fine in branch master until
recently, but unless Ubuntu Precise support is required for some reason,
the current plan is to abandon this old base version, and focus on
more recent distribution versions.

 --

For-Upstream Branch:
My second test was after your recent updates. It didn't work with
virtualbox and the Xenial box. 
The "vagrant up" fails before even creating the shared directory.

I could also reproduce this issue, it seems to be caused by the base
box provided by Hashicorp. In for-upstream, I've changed the base
provider to a different Ubuntu 16.04 image (based on the server distro),
and things work fine now at least here. Could you give branch
for-upstream a try with your setup sometime?
--

    default: /tmp/vagrant-shell: line 1: cd: /vagrant: No such file or
    directory
    ==> default: /tmp/vagrant-shell: line 3:
    integration-scripts/install_repositories.sh: No such file or directory
    ==> default: /tmp/vagrant-shell: line 4:
    integration-scripts/install_common.sh: No such file or directory
    ==> default: /tmp/vagrant-shell: line 5:
    integration-scripts/install_codeface_R.sh: No such file or directory
    ==> default: /tmp/vagrant-shell: line 6:
    integration-scripts/install_codeface_node.sh: No such file or directory
    ==> default: /tmp/vagrant-shell: line 7:
    integration-scripts/install_codeface_python.sh: No such file or
    directory
    ==> default: /tmp/vagrant-shell: line 9:
    integration-scripts/install_cppstats.sh: No such file or directory
    ==> default: /tmp/vagrant-shell: line 11:
    integration-scripts/setup_database.sh:

--

However, I changed to Ubuntu Trusty and it worked fine for me.

that's interesting -- I also tried Trusty, but did encounter several
issues whose causes I have not tracked down yet. Since it would be
valuable to have support for Trusty (travis-ci provides a base
distribution for this, but not xenial, so our CI is currently broken
for for-upstream), would you mind sharing your Vagrantfile or changes?
I'd be happy to merge your results.

With this working build (for-upstream branch, but with trusty box), only
the feature tests from the integration fail.

--

    ======================================================================
    ERROR: testEndToEnd
    (integration.test_features.TestEndToEndOnlyTaggingExample3Feature)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/vagrant/codeface/test/integration/test_features.py", line
    46, in testEndToEnd
        self.checkEdges()
      File "/vagrant/codeface/test/integration/test_exampleprojects.py",
    line 147, in checkEdges
        cluster_id = dbm.get_cluster_id(project_id, release_range)
      File "/vagrant/codeface/dbmanager.py", line 156, in get_cluster_id
        raise Exception("Cluster from project {} not found!".format(pid))
    Exception: Cluster from project 113 not found!

    ======================================================================
    ERROR: testEndToEnd
    (integration.test_features.TestEndToEndOnlyTaggingExample3Feature_File)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/vagrant/codeface/test/integration/test_features.py", line
    46, in testEndToEnd
        self.checkEdges()
      File "/vagrant/codeface/test/integration/test_exampleprojects.py",
    line 147, in checkEdges
        cluster_id = dbm.get_cluster_id(project_id, release_range)
      File "/vagrant/codeface/dbmanager.py", line 156, in get_cluster_id
        raise Exception("Cluster from project {} not found!".format(pid))
    Exception: Cluster from project 115 not found!

    ----------------------------------------------------------------------

I can confirm that this issue also occurs for all my current boxes. It
seems the test is broken ATM.


--


I also tried with a project and could confirm the analysis with
"tagging: file" works.
With "tagging: feature", the dependencies at feature level are not found
and the clusters phase fail:

    2016-06-20 15:57:18 [codeface.util] MainProcess INFO:   -> Revision
    range 1_22_0..1_23_0: Detecting clusters...
    /usr/bin/env: Rscript: No such file or directory
    2016-06-20 15:57:18 [codeface.util] MainProcess ERROR: Command
    '/vagrant/codeface/R/cluster/persons.r --loglevel info -c
    /vagrant/codeface.conf -p /tmp/busyboxuFG__Y
    /vagrant/results/busybox/feature/1_22_0-1_23_0 13' failed with exit
    code 127.
    (stdout: None
    stderr: None)
    Traceback (most recent call last):
      File "/usr/local/bin/codeface", line 9, in <module>
        load_entry_point('codeface', 'console_scripts', 'codeface')()
      File "/vagrant/codeface/cli.py", line 202, in main
        return run(sys.argv)
      File "/vagrant/codeface/cli.py", line 198, in run
        return args.func(args)
      File "/vagrant/codeface/cli.py", line 117, in cmd_run
        args.profile_r, args.jobs <http://args.jobs>, args.tagging,
    args.reuse_db)
      File "/vagrant/codeface/project.py", line 136, in project_analyse
        endmsg=prefix + "Detecting clusters done."
      File "/vagrant/codeface/util.py", line 110, in add
        func(*args, **kwargs)
      File "/vagrant/codeface/util.py", line 279, in execute_command
        raise Exception(msg)
    Exception: Command '/vagrant/codeface/R/cluster/persons.r --loglevel
    info -c /vagrant/codeface.conf -p /tmp/busyboxuFG__Y
    /vagrant/results/busybox/feature/1_22_0-1_23_0 13' failed with exit
    code 127.
    (stdout: None
    stderr: None)

 

Do I need any additional configuration or dependencies to work with the
feature analysis?

If you have cppstats installed (as the vagrant provisioner does),
nothing extra is required. I will investigate this bug during the next
couple of days.

@Mitchell, Claus: Do you have any idea what could be causing this? The
failure is systematic. Since the two of you have most experience with
feature  analysis, could you please also have a look at the issue?

Thanks, Wolfgang

Other related posts:

  1. Home
  2. codeface
  3. Archive
  4. 06-2016