I think it's no longer in our interest to clog the bug tracker with
failing specs. They're failing and we have tags for them, so we know
about them. Only user bugs should go in the tracker, since they
represent a failure that affected a user.
This is a new policy so don't feel bad if you filed Rub
I should elaborate on this slightly. I think it is valid to have a bug
in the tracker for failing specs under these circumstances:
1. If work has started on the bug and it requires a place for discussion.
2. If there's already a bug filed with *useful* discussion.
3. If there's a patch that requir
On Thu, Nov 17, 2011 at 3:05 AM, Charles Oliver Nutter
wrote:
> I should elaborate on this slightly. I think it is valid to have a bug
> in the tracker for failing specs under these circumstances:
>
> 1. If work has started on the bug and it requires a place for discussion.
> 2. If there's already
TypeError converting java class to interface
Key: JRUBY-6219
URL: https://jira.codehaus.org/browse/JRUBY-6219
Project: JRuby
Issue Type: Bug
Affects Versions: JRuby 1.6.2
Reporter:
Win32Ole possible leak
--
Key: JRUBY-6220
URL: https://jira.codehaus.org/browse/JRUBY-6220
Project: JRuby
Issue Type: Improvement
Components: win32ole, Windows
Environment: jruby 1.6.5 (ruby-1.8.7-p330)
On Thu, Nov 17, 2011 at 8:03 AM, Thomas E Enebo wrote:
> I completely agree bugs like 'Math spec failing' suck since they don't
> really tell you what is broken and they also are also possibly
> open-ended depending on when we update our spec tags.
And we often have tags disappear without realizi
perfect!
-Tom
On Thu, Nov 17, 2011 at 1:00 PM, Charles Oliver Nutter
wrote:
> On Thu, Nov 17, 2011 at 8:03 AM, Thomas E Enebo wrote:
>> I completely agree bugs like 'Math spec failing' suck since they don't
>> really tell you what is broken and they also are also possibly
>> open-ended dependin
json gem encoding/decoding is 2x slower than under MRI
--
Key: JRUBY-6221
URL: https://jira.codehaus.org/browse/JRUBY-6221
Project: JRuby
Issue Type: Bug
Components: Performance
Remove rdoc data from dist in favor of rdoc-data gem
Key: JRUBY-6222
URL: https://jira.codehaus.org/browse/JRUBY-6222
Project: JRuby
Issue Type: Improvement
Affects Versions: JRuby 1.6
JRuby 1.6.5 and Cucumber incompatible on Windows 7(x64): load error:
gherkin/i18n -- org.yaml.snakeyaml.reader.ReaderException
--
Key: JRUBY-6223
In MRI 1.9 the flag for Module#const_get also controls lookup of toplevel
constants but not in JRuby
Key: JRUBY-6224
URL: https://jira.codehaus.org/browse/JRUBY-6
There seems to be some differences between what we ship on master for
1.8.7 stdlib and what we have in the jruby "ruby" fork's branch
jruby-1_8_7:
https://gist.github.com/1374961
I'm not sure which of these changes should remain in place in stdlib
and which should be overwritten by jruby-ruby_1_8
hi all,
I was thinking about what was said on that thread a bit.
one point from Tobias was standard tools. if I look how I work
currently then I use
$ rake db:migrate
$ rails server
$ rspec spec/*_spec.rb
etc
and all these commands do have a nice clean java-classpath. the only
thing which is dif
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
(2011/11/18 8:57), Charles Oliver Nutter wrote:
> There seems to be some differences between what we ship on master
> for 1.8.7 stdlib and what we have in the jruby "ruby" fork's
> branch jruby-1_8_7:
>
> https://gist.github.com/1374961
>
> I'm
14 matches
Mail list logo
