I have a python 3.3 job failing on travis python 3.3 worker. Here is the link to the failing job:
https://travis-ci.org/rags/pynt/jobs/5482408
I believe this could be a problem with the worker for following reasons:
The build passes on my box (really!) with python 3.3
The travis build on 3.2 is passing
The error seems to be in the python 3.3 built-in library code. /usr/lib/python3.3/argparse.py:2028
Here are the relevant python 3.3 sources
https://github.com/certik/python-3.3/blob/master/Lib/argparse.py
https://github.com/certik/python-3.3/blob/master/Lib/gettext.py
There is a possibility that my code is doing something funny, but I cant seem to debug it.
Any pointers, suggestion will help
Thank you
Update:
This is a bug in travis. It has been accepted as one and a corresponding ticket has been raised. Hopefully, it will get fixed soon.
Related
I am trying to install psychopy on linux mint from the default repositories (i.e. ubuntu jammy).
Installation fails with this error:
OverflowError: line number table is too long
Has anyone else encountered this error?
This only occurs when using Python 3.10 I believe and it's fixed in the current development branch of PsychoPy's github repository. You can see the required changes in the following pull request, but also note that the recommended version of Python to install PsychoPy is 3.8 not 3.10. I think there are going to be other points of pain using Python 3.10
https://github.com/psychopy/psychopy/pull/5185
Repost from Antonio D.:
I just installed FLOW following all the instructions given in the following link. After executing the sugiyama example, SUMO shows an error saying this: "Error: tcpip::Storage::readIsSafe: want to read 8 bytes from Storage, but only 4 remaining". I know that after the release of SUMO 1.0.0 TraCI libraries and SUMO are no more compatible but I am not able to downgrade the last version of SUMO in my machine (MacBook). Which is the version I should downgrade tool and how can I do it?
I would really appreciate if anyone could help me to fix this.
Repost from Flow team:
This is probably happening because your conda environment cannot find the associate binaries. I would recommend installing the binaries into your conda environment; that should fix this. You can do so from your terminal by running the following commands:
cd /path/to/flow
source activate flow
scripts/setup_sumo_osx.sh
Hope this helps.
I was wondering why my NUnit tests were suddenly terminating successfully after 30 seconds whereas they usually take at least 20 minutes. Then I looked into the build log and found that after upgrading the mono version on our build agent to v 5.4.1, the test runner crashed with exit code 134.
After doing some research, I found out the following:
- The test runner works when using mono 4.8.1 (which we have installed, too), but the test code won't compile with it
- Ì also tried launching th erunner manually like so: /Library/Frameworks/Mono.framework/Versions/5.4.1/bin/mono -v /Applications/TeamCity/buildAgent/plugins/dotnetPlugin/bin/JetBrains.BuildServer.NUnitLauncher.exe which gave me the following error: [1] 3461 abort /Library/Frameworks/Mono.framework/Versions/5.4.1/bin/mono -v with the 3461changing every time I retry.
- According to this thread, exit code 134 means that the program crashed.
Due to the error output, I am not sure, whether it's the TeamCity test runner that crashes, mono that crashes or TeamCity that makes mono crash.
Any help appreciated :)
I finally figured it out myself. Apparently, Mono 5.4.1 lacks important NUnit2 components that were shipped with Mono 5.2 and older. To make tests work again, I had to add the NUnit.Console NuGet-package (not NUnit.ConsoleRunner as it lacks required extensions) and update the TeamCity build step to use the nunit3-console as described here.
For others that may come across this, I fixed this by changing the NUnit build steps from NUNit 2.6.3 to the NUnit 3.10. I didn't change any of my code / packages, just the TC configuration.
I recently upgraded the various pieces of our selenium suite, and when I updated the GeckoDriver to the latest version (0.16.1) I started encountering the following error during set up:
KeyError: 'sessionId'
I know this issue has been brought up here before, but I've checked the other threads and made sure I've followed the correct process. It seems the universal suggestion is to make sure everything is updated correctly.
I'm using robot framework with a modified version of their Selenium2Library to write and run the tests.
robot version is 3.0.2
selenium version is 3.4.3
FF version is 53.0.3
I have also tried altering my proxy settings following the guidance in the thread here(I am on a mac OS X El Capitan):
Why doesn't Selenium's response have a sessionId?
All of this is to no avail. The only thing I can do to get my tests back to a semi-functional state on firefox is to downgrade the geckodriver. I'd like to avoid that if possible, since this newest version has some bug fixes helpful to me.
Any guidance on what I should try next?
Upgrade version of selenium2Library. Current version is 1.8.0
Selenium2Library
Run Command
pip install robotframework-selenium2library --upgrade in cmd
Problem will be solved.
I've resolved this using the nuclear option -- I did a full uninstall of the three main dependencies in the original question and reinstalled through pip.
Latest versions seem to be in good shape. For some reason this resolved the underlying keyError. It does not appear that upgrading the Selenium2Library had any effect.
I use pyinstaller in generate pythion program with matplotlib a exe file
The exe is generated well but when use the exe, there is a error said no module named 'tz'
what does it mean?
I have test the pythinstaller with program with numby and pyqt4 without matplotlib, it worksenter image description here well! )
I have find the solution on pyinstaller git hub provided by Cecil Curry.
It is：
This is a known issue. python-dateutil 2.5.0 is currently broken with respect to PyInstaller, unfortunately.
Until python-dateutil issues a new stable release correcting this, consider temporarily downgrading to python-dateutil 2.4.2. Apologies for the mild inconvenience – and thanks for taking the time to report this, nonetheless.
I have tested and it works