<mdedetrich>
I think the person who originally made the wrapper didn't realise that System.getProperty( "user.dir" ) isn't really going to work for packaged ruby libraries, what should the path lookup actually be
<mdedetrich>
the above understandably fails with org.jruby.embed.ParseFailedException: java.io.FileNotFoundException: /Users/matthewdedetrich/monetise/order/premailer_contact.rb
bf4 has quit [Ping timeout: 252 seconds]
mcclurmc has joined #jruby
iamjarvo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<JRubyGithub>
[jruby] raeoks opened pull request #3091: [#2867] modified Date#>> to take calendar reforms under consideration (master...2867_date_next_year_difference) http://git.io/vtrSj
JRubyGithub has left #jruby [#jruby]
<enebo>
bga57: I believe this is the issue you are talking about. It should be working in 1.7.20.1 for sure and I think we can examine what is needed to make it work on 9000 (which might just be adding this API back)
<bga57>
well, the next command causes it to run until the end of the program, and trying to set a breakpoint causes this error:
<bga57>
INTERNAL ERROR!!! undefined method `entries' for #<String:0x5815d65d>
<bga57>
I tried it on freebsd and ubuntu, both 1.7.20.1 and 9000.
<enebo>
bga57: ok add a new issue…this one is probably not the same error
<enebo>
bga57: I mean it is possible it is but it looks different
samphipp_ has quit [Remote host closed the connection]
samphippen has joined #jruby
<enebo>
bga57: 1.7.x is definitely a regression and 9000 it is up for debate since we do not guarantee backwards compat (although we still need it to work)
<bga57>
Ok. I might not get to it until tonight.
<bga57>
Are you going to the ruby user group meeting tonight?
<enebo>
bga57: thanks
<enebo>
bga57: oh crud :)
<enebo>
bga57: I don’t think so
<enebo>
bga57: but now that you reminded me…maybe? :)
mister_solo has quit [Ping timeout: 252 seconds]
<bga57>
You don't have too. Although I think that one of these months, you or headius might want to talk about 9000 or truffle.
<enebo>
bga57: yeah although next month I think we will both by in Germany
<enebo>
interesting…evalScope in DynamicScope is dead and it is sourced from Binding
<enebo>
did I do this? :) it is nice to not have this stored in two places but why is the dead field left behind
mike___1234 has joined #jruby
Cyrus has joined #jruby
<bga57>
It's just that they're usually looking for speakers, and I know you guys have occasionally shown up there. It's at the Day Block Brewery on Washington Ave these days.
<Cyrus>
I'm sure this has been asked before but I'm not finding it with some Googling -- is Java 7 or 8 preferred for JRuby 9.0.0.0? I remember reading some issues with 8 and indy that caused a regression in performance, but that was sometime last year.
<enebo>
bga57: yeah Valerie and I were going when it was cold out but stopped once it got nice out
<JRubyGithub>
[jruby] storrence opened issue #3092: require_relative through symlinks behaves differently in jruby 9.0.0.0.rc1 than in MRI ruby 2.2.2 http://git.io/vtoHA
JRubyGithub has left #jruby [#jruby]
blaines_ has joined #jruby
blaines has quit [Read error: Connection reset by peer]
deobalds has quit [Quit: Computer has gone to sleep.]
bbrowning_away is now known as bbrowning
tenderlove has joined #jruby
skroon_ has joined #jruby
<skroon_>
i'm trying to use warbler to make my rails app, but when starting the .war with: java -jar app.war I get the message: no main manifest attribute, in app.war
skroon_ is now known as skroon
mister_solo has quit [Ping timeout: 264 seconds]
blaines_ has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<dfr>
Hey folks, any idea whether joni does something funky with raw jvm C++ code access?
<dfr>
'cause I seem to get my server thread to hang on org.joni.ByteCodeMachine.opMemoryStartPush(ByteCodeMachine.java:1180) =/
<dfr>
[Joni 2.0.0, JRuby 1.7.8 if that at all matters)
<dfr>
uh oh. Seems like there's indeed some threading going on in regexp library >.<
* dfr
is really confused =/
dfr is now known as dfr|work
blaines has joined #jruby
<kares>
skroon: you might need to specify (in config/warble.rb) that you want the executable feature
<dfr|work>
lopex, around by any chance? :)
<skroon>
kares: yeah in config/warble.rb i've set that "executable" feature indeed, thanks
<lopex>
dfr|work: there's only checks for interruption
<skroon>
kares: also, when I extract the .war, I do see the boot file
<dfr|work>
lopex, yea, the threading code looks innocuous, so it's very much possible it's my regexp logic, so I'm trying to try to reconstruct what kind of regexp it is so I can grep my code
<dfr|work>
the other confusing part for me is why calling pushMemStart even blocks =/
<kares>
skroon: not sure what boot file you mean?
<dfr|work>
like there doesn't seem to be any synchronization code =/
<lopex>
dfr|work: no idea why would that be
<lopex>
dfr|work: maybe a bug in lock coarsening ?
<lopex>
dfr|work: apart from that is this a regexp that's problematic, or a general issue ?
<dfr|work>
lopex, The only reason I'm blaming regexp is because of the stack trace. I don't know what that actual regexp is even (just got the issue in the wild from server)
<skroon>
kares: config/boot.rb
<dfr|work>
lopex, the general issue is that I have http server threads eating up CPU :) Like for 3+ days straight :)
<skroon>
kares: for some reason, the exectable that start the rails server inside the .war failes to see it
<lopex>
dfr|work: there's might be some long running regexps, we even have an issue for that
<dfr|work>
lopex, what Regexp operation does the MEMORY_START_PUSH correspond to?
<lopex>
dfr|work: backrefs afaik
<dfr|work>
lopex, so something like foo =~ "(.*)\1" or something? :D
<kares>
skroon: hmm that might be a JRuby issue than ... have you tried deploying, .war works fine?
<kares>
also there's java -Dwarbler.debug=true -jar ...
<kares>
maybe something useful comes up (for a bug report)
<lopex>
dfr|work: that one, yes
<dfr|work>
lopex, okay, thanks! Maybe it's just looping forever or something, 'cause I do see a while loop there =/
<lopex>
dfr|work: this still might be a joni bug though
<lopex>
this particular one compiles to [mem-start-push:1]@0(2) [anychar*-sb]@2(1) [mem-end:1]@3(2) [backref1]@5(1)[end]@6(1) [finish]@7(1)
<dfr|work>
lopex, the issue was introduced in my server 2 releases ago, so even if it's a joni bug, it's driven by some our logic change
<dfr|work>
so I'll blame my code first for now and will try to get to root cause :)
<lopex>
dfr|work: I've been making some updates wrt onigmo (last one was 10 Apr)
subbu is now known as subbu|lunch
<dfr|work>
lopex, well, since I'm runnign 2.0.0 I'm trailing the newest version anyway
<lopex>
but that's mostly new stuff, shouldnt affect old regexps
<dfr|work>
anyhow, I'll try to see what the reason is and if it seems like joni is misbehaving, I'll let you know :)
<dfr|work>
but I'm still betting it's my code fault than joni :)
<lopex>
dfr|work: there are known cases where joni can loop for a while (that might be a bug) but it's hard to compare against mri due to warmups
<lopex>
and mri/onigmo has other recent changes
<lopex>
they added some optimizations too
<dfr|work>
lopex, well, it probably shouldn't loop for 3 days :)
<batasrki>
I've installed JRuby from source, version 1.7.20
<batasrki>
the specific issue on jruby-openssl issues list implies that this shouldn't be a problem, but there it is
<batasrki>
any help?
cristianrasch has quit [Quit: Leaving]
<kares>
batasrki: jruby 1.7.20 comes with 0.9.7 yet you managed to get 0.9.4 involved
<kares>
if you really want the old one try installing krypt
<kares>
would instead recommend a bundle update jruby-openssl
<batasrki>
kares: ok. Interesting that 0.9.7 didn't get installed as it would be within the rule '~> 0.9.3', which is what I have in the gemfile
<batasrki>
thanks, I'll try that
<kares>
batasrki: its a default gem already present ... but maybe RG+bundler somehow did not pick it up
<batasrki>
kares: so if I remove it from the Gemfile, it should pick up the default version, right?
cristianrasch has joined #jruby
<kares>
batasrki: hopefully ... you installed from source thus it depends but generally should work yes
<batasrki>
kares: thanks much!
<batasrki>
I will attempt both approaches and one of them should work
<batasrki>
btw, is 9.0.0.0.rc1 production-stable?
<kares>
batasrki: if you do not run into any issues than it is :)
<batasrki>
haha
<batasrki>
ok
yfeldblum has joined #jruby
subbu|lunch is now known as subbu
<mkristian>
kares, so I can grab jruby-openssl as is and look how it is doing with jruby-1_7 and with 9k testsuite ?
<kares>
mkristian: if you do have time to push a snapshot than yes ... I do not plan more updates currently
<mkristian>
kares, will make time for tomorrow ;)
<rtyler>
kares: are you coming to jrubyconf again this year?
<Antiarc>
random language design question: Why does Kernel#load(file, true) return true rather than the anonymous module that the file was loaded into?
<Antiarc>
It seems like if it returned the module, you could almost get Javascript-style scoping of includes, if you're into that kind of thing
<Antiarc>
So you could actually load up a specific version of a class which might conflict with another version of that class, except scoped to an anonymous module so it's self-contained
<kares>
rtyler: probably not ... although I would like to
batasrki has quit [Quit: Leaving...]
<rtyler>
ohnoes
<rtyler>
kares: still in the czech republic?
bf4 has joined #jruby
<kares>
rtyler: yep still relatively near by Berlin :)
<kares>
how many lookouts are coming this year than?
<rtyler>
if you start walking now, you'll be there with plenty of time!
<rtyler>
4
<rtyler>
1 from France, 1 from UK, mkristian and myself
<rtyler>
\o/
<kares>
najs!
<kares>
soon you guys might take over and rename to lookout-conf!
<rtyler>
Lookout Conf, Featuring JRubyCon EU, a Lookout, Inc presentation.
<kares>
Lookout-Conf-9000!
<kares>
mkristian: thanks
mike___1234 has quit [Ping timeout: 256 seconds]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] mkristian pushed 1 new commit to master: http://git.io/vt62i
<JRubyGithub>
jruby/master ae7b2bf Christian Meier: Merge branch 'jruby-1_7'...
JRubyGithub has left #jruby [#jruby]
yfeldblum has quit [Remote host closed the connection]
mje113 has quit [Quit: Connection closed for inactivity]
blaines has quit [Read error: Connection reset by peer]
blaines has joined #jruby
<eam>
I found a race condition in older jruby, in cleanupPOpen() - looping over IO.popen4('echo', 'hi') { |_, _, out, _| out.read } several thousand times will reliably encounter it
<eam>
the race appears to be between checking isOpen() and close()
<eam>
I don't encounter it on jruby 9k, though the race still appears to exist in that method (assuming I'm correct about where the race is)
<eam>
well, part of my question is: if it doesn't repro on head does anyone care?
<eam>
er, on master
<nirvdrum>
1.7.x is still supported. 9k did have a completely rewritten process subsystem, so it may be the case that the bug isn't readily fixable on 1.7.x.
<nirvdrum>
But in that case, having a record of the issue and recorded resolution is still valuable.
bf4 has quit [Read error: Connection reset by peer]
<eam>
ok. I have a fix for 1.7 (simply catch exceptions on close). I'll file an issue tonight
<nirvdrum>
Thanks.
bf4 has joined #jruby
cristianrasch has joined #jruby
cristianrasch has quit [Client Quit]
ddarkpassenger has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
mister_solo has joined #jruby
enebo has joined #jruby
skroon has quit [Read error: Connection reset by peer]
blaines has quit [Ping timeout: 250 seconds]
bf4 has quit [Ping timeout: 272 seconds]
blaines has joined #jruby
enebo has quit [Quit: enebo]
enebo has joined #jruby
blaines has quit [Ping timeout: 276 seconds]
enebo has quit [Client Quit]
blaines has joined #jruby
<rtyler>
nirvdrum: due you know where the source code for jruby.org is?
<rtyler>
I was just thinking about this, so tired of people complaining to me about the state of jruby documentation :P
<nirvdrum>
There's a wiki that no one seems to ever want to update :-/
<nirvdrum>
I'd check with enebo when he's around. He does most of the web site updates.
<rtyler>
we have a similar wiki-challenge internally :P
<rtyler>
the solution generally has been to put the documentation files into the source repo and generate the docs out of them (e.g. asciidoctor)
<nirvdrum>
Way back when, when I was running my first company we wrote a Confluence plugin to run all code samples through CI. This fixed the other problem people have with wikis . . . that the content is stale.