Skip to content
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

Merged
merged 1 commit into from
Jul 4, 2017

Conversation

MSP-Greg
Copy link
Contributor

See 'Test failures on Windows (MinGW)' #156

@tarcieri
Copy link
Contributor

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

@MSP-Greg
Copy link
Contributor Author

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.

@tarcieri
Copy link
Contributor

Thanks for taking a look!

@MSP-Greg
Copy link
Contributor Author

@tarcieri

I've got MinGW down to --

Finished in 36.39 seconds (files took 0.6396 seconds to load)
101 examples, 0 failures, 2 pending

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?

@tarcieri
Copy link
Contributor

Go ahead and push onto this PR and let's take a look at the Appveyor results

@tarcieri
Copy link
Contributor

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 matrix block and ensure there are no Appveyor failures.

@MSP-Greg
Copy link
Contributor Author

@tarcieri

Not quite there yet. I tested with the following ruby builds:

ruby 2.2.8p471 (2017-03-29) [x64-mingw32]                 stable branch
ruby 2.3.5p310 (2017-05-01) [x64-mingw32]                 stable branch

ruby 2.4.1p111 (2017-03-22 revision 58053) [x64-mingw32]  rubyinstaller-2.4.1-2-x64

ruby 2.5.0dev (2017-06-28 trunk 59198) [x64-mingw32]      Trunk

All had identical results of:

Pending: (Failures listed here are expected and do not affect your suite's status)

  1) UDPSocket behaves like an NIO selectable does not select unwritable objects
     # come up with a UDPSocket that's blocked on writing
     Failure/Error: raise TypeError, "can't convert #{io.class} into IO" unless io.is_a? IO

     TypeError:
       can't convert NilClass into IO
     Shared Example Group: "an NIO selectable" called from ./spec/nio/selectables/udp_socket_spec.rb:42
     # ./lib/nio/monitor.rb:18:in `initialize'
     # ./lib/nio/selector.rb:55:in `new'
     # ./lib/nio/selector.rb:55:in `block in register'
     # ./lib/nio/selector.rb:49:in `synchronize'
     # ./lib/nio/selector.rb:49:in `register'
     # ./spec/support/selectable_examples.rb:26:in `block (2 levels) in <top (required)>'

  2) IO.pipe behaves like an NIO selectable does not select unwritable objects
     # windows - can't test due to 'select' not showing correct status
     # ./spec/support/selectable_examples.rb:25

101 examples, 0 failures, 2 pending

For the two Travis failures, suspect it might be that spec/nio/selectables/udp_socket_spec.rb:33
should just be break, but I can't test. If you'd like, I could merge that and see how it tests.

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...

@MSP-Greg
Copy link
Contributor Author

@tarcieri

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.

@tarcieri
Copy link
Contributor

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

@MSP-Greg
Copy link
Contributor Author

MSP-Greg commented Jun 30, 2017

Questions:

  1. Thoughts on the travis failures?

  2. Does anyone in the non-Windows world still use 32 bit builds / OS's?

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:

  1. Move Appveyor along with updating their ruby builds.

  2. Package x64-mingw32 & x86-mingw32 builds of nio4r.

@@ -22,7 +22,17 @@
end

let :writable_subject do
pending "come up with a writable UDPSocket example"
Copy link
Contributor

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...

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor Author

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)?

@tarcieri
Copy link
Contributor

#4 sounds fantastic if that's something you're interested in working on

@MSP-Greg
Copy link
Contributor Author

#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...

@MSP-Greg
Copy link
Contributor Author

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

@tarcieri
Copy link
Contributor

Nice!

@tarcieri
Copy link
Contributor

Looking great! Mind squashing these commits?

See 'Test failures on Windows (MinGW)' socketry#156

Windows / MinGW tests - update spec & examples

Windows / MinGW - appveyor.yml
@MSP-Greg
Copy link
Contributor Author

MSP-Greg commented Jul 1, 2017

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...

@tarcieri tarcieri merged commit 530fd62 into socketry:master Jul 4, 2017
@tarcieri
Copy link
Contributor

tarcieri commented Jul 4, 2017

Looks good! Thanks for contributing!

@MSP-Greg MSP-Greg deleted the mingw_tests_1 branch July 4, 2017 18:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants