5 ms·

The same bug still exists in JRuby 9000, and was in fact the first thing I ran into when trying it. Considering threading is the main selling point, one of the

by Freaky 11y ago

The same bug still exists in JRuby 9000, and was in fact the first thing I ran into when trying it. Considering threading is the main selling point, one of the commonest patterns of regexp use being completely and dangerously broken with them would have seemed like something of a showstopper.

eropple 11y ago
"Commonest" is a big claim. I'm not a JRuby user, but I sling a whole bunch of Ruby and I've never, not once, used the global regexp stuff--indeed, I didn't know it existed before just now. I can see wanting it fixed, but it's a pretty odd hill to die on.
- tinco 11y ago
  I've been writing Ruby for 7 years now, and I've known about the regex svars for about as long. Never used them once. They're obviously bad style.
Confusion 11y ago
Ah, I didn't get that from your original post. So JRuby 9000 shipped with a known concurrency bug that, from the face of it, seems likely to be a problem in actual use. I agree that seems a bit worrying.
- gsnedders 11y ago
  What VM doesn't ship with bugs likely to be a problem in actual use, though?
- headius 11y ago
  You have to ship some time. Noisy bugs get fixed...and patches are always accepted :-)
  - Confusion 11y ago
    Of course is can be completely reasonable to ship with a known bug, which is why my initial reaction to the OP was: why are you bringing this up here? However, not all bugs are made equal and this one seems relatively likely to actually cause problems for users. Wouldn't someone running some service and handling say 10 requests/second, while using the regex global variables, run into this bug on a daily basis? So I guess I'm just interested in how such a decision is made: what bugs get shipped and which block a release? If this bug would reasonably cause problems in such a situation and if the policy of JRuby is to ship anyway, that seems to be a relevant piece of information to consider for someone using JRuby in production and considering whether to upgrade. Perhaps one should always check the list of open bugs for the version of a compiler/interpreter one intends to start using, but I've never done so, haven't been bitten by a bug yet (AFAIK) and yet this one seems one that could be a problem. The main problem is of course that this may just be 'the curse of knowledge' in play. So I guess I was being a bit dismissive towards OP, then I was sympathetic and now I'm mostly thinking about how I should handle this as someone using JRuby in production. Perhaps I should just ignore it. Perhaps I should investigate the set of concurrency tests and contribute a few. Perhaps I should be conservative and only use 'proven' JRuby versions. Perhaps I should learn to stop worrying and love the bomb :)
    - VeejayRampay 11y ago
      Of perhaps you should simply shy away from global perlisms in a Ruby app, which are really bad practice anyway.
dragonwriter 11y ago
> one of the commonest patterns of regexp use Is it really? Even fairly early in the Ruby 1.8.x era, most recommendations I saw were that the magic regexp globals (and many other magic globals) were a perlism that should generally be avoided.
- jrochkind1 11y ago
  Huh, I use `$1` all the time, and see it all the time. Probably because the alternative with an explicit match object ends up being relatively a lot more code and a lot harder to read, really. If avoiding `$1` has been often recommended for a while... I think it's a recommendation more often ignored than followed.
  - thescrewdriver 11y ago
    I've never seen $1 used in production code.
    - Freaky 11y ago
      Try grepping your lib directory sometime. In fact, let me do it for you, on a relatively clean install: time, benchmark, irb, pry, rubygems, resolv, erb, rake, open-uri, debug, rack, cgi/util, optparse, getoptlong, bundler, activesupport, actionpack, activemodel, erubis, slim, haml, sass, sequel, roda, nokogiri, rugged, faraday, mime-types, thor, test-unit, tzinfo, mail, ffi
      - deleted 11y ago
        [deleted]
      - thescrewdriver 11y ago
        Ouch. That's pretty awful.
- VeejayRampay 11y ago
  I don't think it's that common a pattern. All those perlisms make code unreadable anyway. I much prefer things like match with named captures, which generally make everything more obvious.

by Freaky 11y ago

eropple 11y ago

"Commonest" is a big claim. I'm not a JRuby user, but I sling a whole bunch of Ruby and I've never, not once, used the global regexp stuff--indeed, I didn't know it existed before just now. I can see wanting it fixed, but it's a pretty odd hill to die on.

tinco 11y ago
I've been writing Ruby for 7 years now, and I've known about the regex svars for about as long. Never used them once. They're obviously bad style.

Confusion 11y ago

Ah, I didn't get that from your original post. So JRuby 9000 shipped with a known concurrency bug that, from the face of it, seems likely to be a problem in actual use. I agree that seems a bit worrying.

gsnedders 11y ago
What VM doesn't ship with bugs likely to be a problem in actual use, though?
headius 11y ago
You have to ship some time. Noisy bugs get fixed...and patches are always accepted :-)
- Confusion 11y ago
  Of course is can be completely reasonable to ship with a known bug, which is why my initial reaction to the OP was: why are you bringing this up here? However, not all bugs are made equal and this one seems relatively likely to actually cause problems for users. Wouldn't someone running some service and handling say 10 requests/second, while using the regex global variables, run into this bug on a daily basis? So I guess I'm just interested in how such a decision is made: what bugs get shipped and which block a release? If this bug would reasonably cause problems in such a situation and if the policy of JRuby is to ship anyway, that seems to be a relevant piece of information to consider for someone using JRuby in production and considering whether to upgrade. Perhaps one should always check the list of open bugs for the version of a compiler/interpreter one intends to start using, but I've never done so, haven't been bitten by a bug yet (AFAIK) and yet this one seems one that could be a problem. The main problem is of course that this may just be 'the curse of knowledge' in play. So I guess I was being a bit dismissive towards OP, then I was sympathetic and now I'm mostly thinking about how I should handle this as someone using JRuby in production. Perhaps I should just ignore it. Perhaps I should investigate the set of concurrency tests and contribute a few. Perhaps I should be conservative and only use 'proven' JRuby versions. Perhaps I should learn to stop worrying and love the bomb :)
  - VeejayRampay 11y ago
    Of perhaps you should simply shy away from global perlisms in a Ruby app, which are really bad practice anyway.

dragonwriter 11y ago

> one of the commonest patterns of regexp use Is it really? Even fairly early in the Ruby 1.8.x era, most recommendations I saw were that the magic regexp globals (and many other magic globals) were a perlism that should generally be avoided.

jrochkind1 11y ago
Huh, I use `$1` all the time, and see it all the time. Probably because the alternative with an explicit match object ends up being relatively a lot more code and a lot harder to read, really. If avoiding `$1` has been often recommended for a while... I think it's a recommendation more often ignored than followed.
- thescrewdriver 11y ago
  I've never seen $1 used in production code.
  - Freaky 11y ago
    Try grepping your lib directory sometime. In fact, let me do it for you, on a relatively clean install: time, benchmark, irb, pry, rubygems, resolv, erb, rake, open-uri, debug, rack, cgi/util, optparse, getoptlong, bundler, activesupport, actionpack, activemodel, erubis, slim, haml, sass, sequel, roda, nokogiri, rugged, faraday, mime-types, thor, test-unit, tzinfo, mail, ffi
    - deleted 11y ago
      [deleted]
    - thescrewdriver 11y ago
      Ouch. That's pretty awful.
VeejayRampay 11y ago
I don't think it's that common a pattern. All those perlisms make code unreadable anyway. I much prefer things like match with named captures, which generally make everything more obvious.