duncan_bayne

Activity Graph

Page 1 of 1

2019-03-03

[11:32:06] duncan_bayne: has joined #ruby
[11:34:00] duncan_bayne: Hi :) On my system, File.stat('/tmp').writable? returns true when run under MRI 2.5.1, but false when run under JRuby 9.1.7.0. This means that Dir.tmpdir is failing under JRuby, because it thinks /tmp isn't writable.
[11:34:35] duncan_bayne: I suspect I'm running into an obscure bug here, but couldn't find anything obvious.
[11:34:50] duncan_bayne: Has anyone seen this behaviour before?
[12:11:53] duncan_bayne: has left #ruby: ("gives up for the night")

2017-11-17

[03:35:52] duncan_bayne: has joined #ruby
[03:37:11] duncan_bayne: Hey :) We've just upgraded a Rails 4 project from MRI 2.2.2 -> 2.4.2, and we're seeing some odd behaviour in some of our specs. Specifically, assertions that kept failing until Timeout#timeout gave up no longer raise Timeout::Error, and thus no longer time out.
[03:37:37] duncan_bayne: Are there are any known issues w/ Timeout in 2.4.2? Did the usual Googling for issues, etc., but couldn't find anything.
[03:43:22] duncan_bayne: Radar: LOL yes :)
[03:44:32] duncan_bayne: We're busy bisecting Ruby versions in an attempt to narrow it down
[03:45:30] duncan_bayne: Radar: all of us in the office are having a laugh at this :)
[03:48:58] duncan_bayne: Also I still need to bring my rspec electrocution rig to Melbourne Ruby and hook you up to it :)
[03:49:12] duncan_bayne: If you place the little patches right you can provoke involuntary muscle spasms when your tests fail
[03:49:31] duncan_bayne: Ended up having a third child which took up a lot of capacity
[03:51:24] duncan_bayne: Not unless you count 'run a particular spec in our suite that does not seem to be different to any others' as M
[03:51:30] duncan_bayne: Seriously, it's _odd_
[03:52:19] duncan_bayne: Also, it doesn't always fail
[03:52:41] duncan_bayne: When it 'works', the debug trace shows a Timeout::Error being raised (eventually) after successive expectation failures
[03:52:58] duncan_bayne: When it doesn't, you see the expectation failure, but it just keeps trying forever (well, until CI or an operator kills it)
[03:56:22] duncan_bayne: RickHull: yeah we don't use it directly, it's the https://github.com/laserlemon/rspec-wait gem
[03:59:22] duncan_bayne: Radar: Pez isn't a fan of those; he wanted greater flexibility around matchers, IIRC.
[03:59:31] duncan_bayne: Hence rspec-wait ...
[04:01:36] duncan_bayne: sneep: Same company for the time being; Pez' outfit is a client of ours
[04:01:47] duncan_bayne: Best. Behaved. Kids. Ever.
[04:02:26] duncan_bayne: This is more confusing than the bloody Ruby bug ;)
[04:03:21] duncan_bayne: So, yeah, _definitely_ not 2.2.2, and usefully reproducible in 2.4.2
[04:04:33] duncan_bayne: Radar: trying that right now
[04:12:54] duncan_bayne: RickHull: you mean a PR on MRI?
[04:15:36] duncan_bayne: RickHull: I like the way you roll
[04:35:14] duncan_bayne: RickHull: let me know how you go, would be interested to try your fork against our test suite
[04:35:28] duncan_bayne: Meanwhile, have persuaded rbenv to install HEAD, & retesting
[04:35:45] duncan_bayne: ACTION eagerly anticipates PM beer
[04:41:50] duncan_bayne: Radar: confirmed; 2.2.2 definitely works, 2.2.3 definitely doesn't
[04:41:58] duncan_bayne: Still waiting on a result from HEAD
[04:42:46] duncan_bayne: Radar: Looks that way
[04:42:58] duncan_bayne: And it must be subtle, because it works in most cases
[04:43:05] duncan_bayne: "The compiler is broken"
[04:43:17] duncan_bayne: ACTION continues testing, skeptically
[04:49:22] duncan_bayne: pars: Speaking for myself, trying to work out why Timeout#timeout ... isn't ... but only in one of our specs, and only since 2.2.2
[04:58:08] duncan_bayne: RickHull: ta, I'll take a look
[04:58:16] duncan_bayne: pars: neither do I, neither do I :-/
[05:04:22] duncan_bayne: Thanks for the suggestions folks; I'm off home
[05:04:48] duncan_bayne: Will definitely let you know how we get on; milewski reports that the first test run on 2.4 HEAD didn't repro the problem. But it is intermittent ...
[05:04:59] duncan_bayne: has left #ruby: ("beer time")
[05:05:47] duncan_bayne: has joined #ruby
[05:05:55] duncan_bayne: Well that was quick - failed the second time out
[05:06:00] duncan_bayne: Fails on 2.5 preview as well
[05:06:43] duncan_bayne: Radar: Def. boo. Time for MCVE + bisect I think
[05:07:24] duncan_bayne: Well, actually, time for beer, and MVCE + bisect on Monday
[05:07:26] duncan_bayne: has left #ruby: ()
[06:16:17] duncan_bayne: has joined #ruby
[06:16:34] duncan_bayne: RickHull: pez has asked me to let you know that he's commented on https://github.com/rickhull/rspec-wait/commit/985aa88dfe4ade70d290aa5c61e57d3872e6b7fc
[06:16:43] duncan_bayne: ACTION enables SlackToIRCProxyMode
[06:16:59] duncan_bayne: I suggested that if he used Emacs he'd have a built in IRC client
[06:22:06] duncan_bayne: RickHull: Ta :)
[06:23:00] duncan_bayne: has left #ruby: ("ERC (IRC client for Emacs 25.3.1)")

2017-08-07

[07:06:04] duncan_bayne: has joined #ruby
[07:08:11] duncan_bayne: has left #ruby: ("ERC (IRC client for Emacs 25.2.1)")

2015-12-01

[03:51:50] duncan_bayne: has joined #ruby
[04:00:23] duncan_bayne: Quit: Page closed

2015-09-20

[21:59:28] duncan_bayne: has joined #ruby
[22:00:31] duncan_bayne: Hi, quick question - are thread pools the default for JRuby 9.0.1.0? I get 'jruby: warning: unknown property jruby.thread.pooling' when I try to use thread pools with 9.0.1.0 but not with 1.7.22.
[22:00:52] duncan_bayne: I've had a look at the documentation, but it doesn't say anything about support being dropped / defaulted.
[22:02:08] duncan_bayne: When I set it in JRUBY_OPTS, e.g. JRUBY_OPTS="-J-Djruby.thread.pooling=true" ruby myscript.rb
[22:02:19] duncan_bayne: No complaint from 1.7.22, but warnings with 9.0.1.0
[22:03:07] duncan_bayne: Of course it might be I'm passing in an altogether invalid option, and it's just that 1.7.22 is silent about it :)
[22:09:25] duncan_bayne: Ping timeout: 255 seconds
[22:13:43] duncan_bayne: has joined #ruby
[22:19:04] duncan_bayne: Ping timeout: 252 seconds

2015-09-02

[10:49:22] duncan_bayne: has joined #ruby
[10:50:32] duncan_bayne: Hi, can anyone recommend a library for parsing Excel files that doesn't barf on large spreadsheets (~ 30MiB or so)? I've just filed https://github.com/weshatheleopard/rubyXL/issues/199 and https://github.com/woahdae/simple_xlsx_reader because both those libraries burn 6.0GiB+ to open a 30MiB spreadsheet, then my system falls over :(
[10:50:49] duncan_bayne: Sorry, https://github.com/woahdae/simple_xlsx_reader/issues/22
[11:04:05] duncan_bayne: Quit: ERC Version 5.3 (IRC client for Emacs)

2015-04-13

[05:03:56] duncan_bayne: Hi, I'm seeing some unexpected behaviour using in_time_zone() in Australia. It uses 'EST +10:00' instead of AEST, and 'EST +11:00' instead of AEDT. Details here: https://gist.github.com/duncan-bayne/62bd46da5167c6b5bc93
[05:04:22] duncan_bayne: Am I being unreasonable in my expectations here?
[05:11:39] duncan_bayne: @sevenseacat I'm pretty sure it should be EDT (or AEDT) not EST during daylight savings.

2014-09-25

[05:18:55] duncan_bayne: Hi, I'm trying to call a set accessor from C with 'rb_funcall(output, rb_intern("state"), 1, T_TRUE);'. It's failing silently :( Am I doing something obviously wrong here?
[05:19:34] duncan_bayne: That's intended to be equivalent to 'output.state = true' in Ruby
[05:21:30] duncan_bayne: Correct code is: 'rb_funcall(output, rb_intern("state="), 1, Qtrue);'

2014-01-27

[11:04:14] duncan_bayne: Hey is help with Rubywarrior (https://github.com/ryanb/ruby-warrior) on-topic here? Want to check before referring people here in a presentation.
[11:04:39] duncan_bayne: It's a 'how to learn Ruby with rubywarrior' meetup presentation for newbies.

2012-10-02

[00:30:46] duncan_bayne: Hi all, quick question: does anyone know how to configure max_nesting for multi_json in Rails 3? I'm regularly working with JSON nested deeper than the default maximum of 20.

2012-09-26

[04:05:21] duncan_bayne: Hi all. Got a quick question: I've upgraded a Rails 2 app to 3.2.8. Coffeescript files are being re-compiled when changed, but frequently the old version is being served up in the browser.
[04:05:40] duncan_bayne: Symptom is I make a change, save, refresh the page, see the change, refresh, don't see it (old version is served).
[04:05:50] duncan_bayne: Anyone seen this behaviour before?
[04:08:19] duncan_bayne: @micaeked: That does indeed fix it, as does a precompile. But the issue is that by my understanding it shouldn't happen at all. Once recompiled the new asset should be served consistently. Which means either my understanding is flawed or I'm doing something wrong.
[04:11:48] duncan_bayne: @rknLA: it does, but it's happening on both FF and Chrome. And it doesn't happen on a fresh Rails 3.2.8 app which leads me to suspect our app is doing something retarded.
[04:16:50] duncan_bayne: @micaeked: https://gist.github.com/3785991
[04:17:22] duncan_bayne: @micaeked: (comments trimmed)
[04:21:17] duncan_bayne: @micaeked: Thanks, I'll give that a whirl ...
[04:23:08] duncan_bayne: @micaeked: Same behaviour I'm afraid :-(
[04:28:13] duncan_bayne: @micaeked: Yeah, that's what we did too. Our app is large, so we actually scripted it. Basically incrementally worked on this script to build a Rails 3 app from the guts of our Rails 2 app, then 'flicked the switch', merged, and we were in Rails 3. Then a bunch of sundry little issues to fix, of which this is the last.
[04:39:03] duncan_bayne: @micaeked: Ahah. Having had a look through our Rake tasks, I think we may be precompiling automatically in dev :-/
[04:39:27] duncan_bayne: @micaeked: I think that may be some sort of weird legacy from the asset pipeline stuff we were doing in Rails 2.
[04:41:41] duncan_bayne: @micaeked: Well, that my current best theory ... time to go and test it :-)