Hi Rodrigo,
Am 27/06/2016 um 21:54 schrieb Rodrigo Queiroz:
Thanks again for updates. I tried a new build: Master branch (after your
recent updates), and keeping Trusty box. Vagrant and integration scripts
worked with no error :)
-
I've found a problem, and maybe I should report in the issues section.
When performing a feature analysis and a feature expression is too long
for the column in the database, the program crashes and everything is lost.
016-06-26 15:04:31 [*codeface.dbmanager*] MainProcess*CRITICAL*:
MySQL error 1406 during "INSERT INTO commit_dependency (commitId,
file, entityId, entityType, size, impl) VALUES (%s,%s,%s,%s,%s,%s)":
Data too long for column 'entityId' at row 534
I solved this by increasing the size of the column in the database
(commit_dependency.entityId, originally a 256 varchar). Some expressions
can be really large.
I have a question: when adding new releases to a previously performed
analysis, is it possible to skip the commit analysis from already
analysed versions? I noticed that removing the releases from the config
makes Codeface reset the database. It would be useful when a crash
occurs and we want to continue from one specific release.
Best,
Rodrigo
On Fri, Jun 24, 2016 at 7:22 PM, Wolfgang Mauerer
<wolfgang.mauerer@xxxxxxxxxxxxxxxxx
<mailto:wolfgang.mauerer@xxxxxxxxxxxxxxxxx>> wrote:
Hi Rodrigo.
Am 24/06/2016 um 19:46 schrieb Rodrigo Queiroz:
> Thank you very much for the updates. CPPstats problem is solved.
>
> More details of the build:
>
> I tested a new build from the for-upstream (using both trusty and
> xenial), but the the vagrant provision fails at some point of the
> integration scripts.
> I tried to run the the scripts manually (the same order as the
> vagrantfile) and got this error after install_codeface_python.sh
>
> Exception:
> Traceback (most recent call last):
> File "/usr/lib/python2.7/dist-packages/pip/basecommand.py", line
209,
> in main
> status = self.run(options, args)
> File "/usr/lib/python2.7/dist-packages/pip/commands/install.py",
line
> 317, in run
> requirement_set.prepare_files(finder)
> File "/usr/lib/python2.7/dist-packages/pip/req/req_set.py", line
360,
> in prepare_files
> ignore_dependencies=self.ignore_dependencies))
> File "/usr/lib/python2.7/dist-packages/pip/req/req_set.py", line
448,
> in _prepare_file
> req_to_install, finder)
> File "/usr/lib/python2.7/dist-packages/pip/req/req_set.py", line
387,
> in _check_skip_installed
> req_to_install.check_if_exists()
> File "/usr/lib/python2.7/dist-packages/pip/req/req_install.py", line
> 1011, in check_if_exists
> self.req.project_name
> AttributeError: 'Requirement' object has no attribute 'project_name'
that's curious, I have not seen this error yet.
>
> But even with this error, python seems to be working without problems.
> The integrations tests pass and I also tested a project with the feature
> analysis (xenial box).
>
> Maybe this error was stopping the provision, or maybe some instability
> in my network was causing the problem. I will do another test once I get
> a wired connection.
>
> For now, is working :)
that's good to hear!
When you're doing another try anyway to get a clean install, please
make sure to use the current state of for-upstream. I've updated
cppstats to 0.9.0 because this solves some more problems with python
dependencies. The travis build on github now succeeds for this branch
(and so do my local builds); assuming no network turbulences,
you should also get a clean build out of this branch. If not,
we need to look closer into the bug you mentioned above...
Best regards, Wolfgang
--
*Rodrigo Queiroz, M.Sc.*
/Ph.D. Candidate
/
/Generative Software Development Lab/
/University of Waterloo/
/200 University Ave. West, /
/Waterloo, ON, N2L 3G1, //CANADA/
/Tel.: +1 519 885 1211 x35035
/
/Mob:+1 226 606 2133
/
/rodrigoqueiroz.skype/
