-
-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows / MinGW test failure - fix spec_helper.rb #157
Conversation
Well nice, down to 1 failure now, although it's the same one you reported in #156: https://ci.appveyor.com/project/tarcieri/nio4r/build/2.1.15/job/7bxd7jw2gjpbh9rj#L438 |
I'll see if I can get to that. I have some patches for Ruby socket tests that I need to look over... May not be tonite (I'm central). Thanks. |
Thanks for taking a look! |
I've got MinGW down to --
Changes to pipe, ssl_socket, & udp_socket, along with three deleted comment lines from selectable_examples. Hoping Travis shows the same. Add another commit to this, another PR, etc. What would you prefer? |
Go ahead and push onto this PR and let's take a look at the Appveyor results |
Note there are explicitly configured directives to skip Appveyor failures here: https://github.com/socketry/nio4r/blob/master/appveyor.yml#L11 A successful PR for this problem should remove the entire |
Not quite there yet. I tested with the following ruby builds:
All had identical results of:
For the two Travis failures, suspect it might be that spec/nio/selectables/udp_socket_spec.rb:33 As to the Appveyor ruby 22 failure, as you probably know, it's not building. As shown above, I installed it with 2.2.8 (built with my tools based on MSYS2/MinGW). FYI, the builds that Appveyor is currently using were created with the original RubyInstaller system. The system was based on MSYS/MinGW tools, but did not use the tools as normally configured. My builds, and the newer (2.4+) RubyInstaller2 builds, are based on MSYS2/MinGW. I have been using the newer set of tools for a long time. So, I'll try to look at the 22 build failure, but I may instead try to contact Appveyor about updating the ruby builds they are using... |
re Appveyor build matrices, a few others Ruby pysch, Ruby openssl I wonder if nio4r would build with 22-x64 (or 23-x64)? FWIW, I believe Appveyor Ruby builds are using gcc 4.7.x. The RubyInstaller2 / MSYS2 /minGW systems are using gcc 6.3.0. |
I don't know the difference offhand, and I'm open regarding advice about Windows toolchains, especially if we can get them properly documented in the README |
Questions:
I don't really want to try and dredge thru why ruby22 isn't building, especially since my builds work with 2.2 thru 2.5. I'm thinking about two items:
|
@@ -22,7 +22,17 @@ | |||
end | |||
|
|||
let :writable_subject do | |||
pending "come up with a writable UDPSocket example" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems to be the main source of the Travis failures...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you see what the error is on the rescue? I couldn't fill up the UDP socket (or generate an error) on Windows.
I'm confused why just two of the travis build jobs failed, and both state 'Expected pending "UDPSocket Error' to fail. No error was raised."
What if the end while condition is removed, and keep some kind of rescue to make sure it can be written to. Maybe that will be better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is on Travis, your example manages to create a writable_subject
, but then the subsequent tests are failing.
I'm not sure why they're failing but it's not entirely unexpected considering this was just pending before. It was likely pending because of sporadic CI failures.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was likely pending because of sporadic CI failures.
I really hate it when that happens. Maybe add a line to output the error type and skip/pending for that (once we see what it is)?
#4 sounds fantastic if that's something you're interested in working on |
Making the gem packages shouldn't take too long; I've just got to figure out how to package what I've already got. I'll jig up a repo so I can test them with the appveyor ruby versions... |
Sorry about that merge. I'll get rid of it tomorrow. Note to self - never use GitHub client for PR work. Fixed appveyor.yml, see Appveyor MSP-Greg/nio4r |
Nice! |
Looking great! Mind squashing these commits? |
See 'Test failures on Windows (MinGW)' socketry#156 Windows / MinGW tests - update spec & examples Windows / MinGW - appveyor.yml
All green. I'll see about creating mingw specific gem packages. Then again, now that 2.2 - 2.4 are building, less of a concern. I'll be back if anything changes re Appveyor. Maybe I can get them to start using a daily ruby trunk build. Have a good weekend, and thanks... |
Looks good! Thanks for contributing! |
See 'Test failures on Windows (MinGW)' #156