<sickpig>
I've installed jruby 1.7.19 through rvm on digitalocean virtual machine
<sickpig>
and I'm expiriencing something very strange
<sickpig>
every time I perfom a bundle update it will take forever and from looking at my netweok traffic / stracing java process
<bbrowning>
bga57: no problems with the proxy that I'm aware of
<sickpig>
I see that the proccess is trying to connect to an IP address locate in China
<sickpig>
this is the ip address 115.231.222.45
erikhatcher has joined #jruby
mcclurmc has joined #jruby
lance|afk has quit [Quit: Bye bye]
lanceball has joined #jruby
lanceball has quit [Remote host closed the connection]
kyugyi has joined #jruby
<kyugyi>
.
<kyugyi>
did usa covertly supply isis with weapons like they did with al-qaeda to justify creating wars?
<kyugyi>
did usa excute the creative mess in the middle east like they said they will, does the creative mess include explosions with uncertain responsibles to create wars?
<kyugyi>
plz, send my qs to help limiting usa&israel aggression against others.
<kyugyi>
.did usa covertly supply isis with weapons like they did with al-qaeda to justify creating wars?
<kyugyi>
did usa excute the creative mess in the middle east like they said they will, does the creative mess include explosions with uncertain responsibles to create wars?
<kyugyi>
plz, send my qs to help limiting usa&israel aggression against others.
skade has quit [Remote host closed the connection]
lanceball has joined #jruby
kyugyi has quit [Excess Flood]
e_dub has quit [Quit: e_dub]
kyugyi has joined #jruby
<kyugyi>
.
<kyugyi>
did usa covertly supply isis with weapons like they did with al-qaeda to justify creating wars?
<kyugyi>
did usa excute the creative mess in the middle east like they said they will, does the creative mess include explosions with uncertain responsibles to create wars?
<kyugyi>
plz, send my qs to help limiting usa&israel aggression against others.
<kyugyi>
.did usa covertly supply isis with weapons like they did with al-qaeda to justify creating wars?
<kyugyi>
did usa excute the creative mess in the middle east like they said they will, does the creative mess include explosions with uncertain responsibles to create wars?
<kyugyi>
plz, send my qs to help limiting usa&israel aggression against others.
kyugyi has left #jruby [#jruby]
lanceball has quit [Changing host]
lanceball has joined #jruby
gaustin has joined #jruby
triple_b has joined #jruby
skade has joined #jruby
triple_b_ has joined #jruby
triple_b has quit [Ping timeout: 246 seconds]
enebo has joined #jruby
mje113__ has joined #jruby
bjfish2 has joined #jruby
skade has quit [Remote host closed the connection]
skade has joined #jruby
iamjarvo has joined #jruby
marr has quit [Ping timeout: 256 seconds]
cremes has quit [Read error: Connection reset by peer]
cremes has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] nirvdrum pushed 4 new commits to master: http://git.io/jbKp
<JRubyGithub>
jruby/master 3692562 Kevin Menard: Added modifyAndKeepCodeRange to the CodeRangeable interface.
<JRubyGithub>
jruby/master efb1aed Kevin Menard: Encoding.STR_ENC_GET should work with all ByteListHolders.
<JRubyGithub>
jruby/master bb1c024 Kevin Menard: Moved most of RubyString#trTrans19 to StringSupport.trTransHelper.
<nirvdrum>
headius: Looking at the build failures?
cpuguy83 has joined #jruby
cpuguy83 has quit [Client Quit]
e_dub has joined #jruby
cpuguy83 has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius created test-load-fixes (+2 new commits): http://git.io/jAhC
<JRubyGithub>
jruby/test-load-fixes 0f30577 Charles Oliver Nutter: Rework load sequence wrt feature checking and locking....
<JRubyGithub>
jruby/test-load-fixes 764d6af Charles Oliver Nutter: Rework jar service loading to properly build path....
JRubyGithub has left #jruby [#jruby]
<headius>
enebo: going to let travis run a cycle with my bandaids and we'll see how it goes
<enebo>
headius: cool
<headius>
if you get a chance to look at the logic, let me know...I'm sure it's doing too much work, but it's functional
iamjarvo has joined #jruby
<enebo>
ok. I will try. I have mixed feelings about committing the new lexer even locally until more is passing but I keep feeling like I am setting myself up
<enebo>
hmmm I could always squash later
iamjarvo has quit [Max SendQ exceeded]
<headius>
I have a vision of a LoadService that actually has a structured representation of load path and loaded features, which would also start giving us opportunity to make the load path entries cache some dir indexes
<headius>
this may be too ambitious to do in pre2, though
iamjarvo has joined #jruby
<enebo>
yeah
<chrisseaton>
enebo: I tried to use DetailedSourcePosition instead, but it turned out to be much more work than I thought
<enebo>
so there are a handful of ISourcePosition consumers in truffle and I am contemplating changing this in the new lexer to more match MRI and to get rid of millions of getPosition calls
<chrisseaton>
enebo: what would it look like instead?
<enebo>
chrisseaton: I might just push line and not bother with file
<enebo>
chrisseaton: which means we may not care about having a full class for a single field
<enebo>
chrisseaton: I am still figuring out if just sticking file into RootNode is enough
<enebo>
chrisseaton: I still need all scope types to have the ability to know the file
<enebo>
chrisseaton: but worst case I add file field for those few nodes which are top-level nodes
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 1 new commit to master: http://git.io/jxJH
<JRubyGithub>
jruby/master 5a353b7 Charles Oliver Nutter: Fix boundscheck lost in last String#rindex change.
JRubyGithub has left #jruby [#jruby]
<enebo>
chrisseaton: I could also make ISourcePosition getPosition() on node return self and have a dummy file field
<enebo>
chrisseaton: then linenumber would continue to work and filename perhaps could just get saved off in those few important nodes
<chrisseaton>
enebo: seems like a lot of work to support something legacy
<enebo>
truffle?
<enebo>
:)
<chrisseaton>
Truffle can adapt to whatever you do - I just mean for you
<enebo>
chrisseaton: ok. I just don’t like breaking stuff
<enebo>
chrisseaton: well I sort of like breaking stuff
mitchellhenke has quit [Quit: Computer has gone to sleep.]
<chrisseaton>
Can't you create an iSourcePosition on demand when getPosition() is called?
<headius>
cancelled a few jobs I know will fail without that last rindex fix
<headius>
bbl
<enebo>
chrisseaton: but I could probably add a couple of lines which I think will preserve most of what you want
<enebo>
chrisseaton: I think I will just have Node implements ISourcePosition
<enebo>
chrisseaton: for top-level nodes getFile will not return null and all other nodes will continue returning proper line number
<enebo>
chrisseaton: which I think will not break your stuff and I think will be easier for me potentially if we depend on ISourcePosition outside of parser
<chrisseaton>
you could modify your ast so that nodes know about their parents? or I suppose fields are what you are trying to get rid of
<enebo>
chrisseaton: yeah I did that in jruby-parser as well but it is a whole extra object reference per node
<enebo>
which is secondary benefit possibly of removing sourceposition field
<enebo>
For jruby-parser there is a lot more desired navigation around the tree so it is useful
<enebo>
for our mainline parser it would only really help to have getFilename work
<chrisseaton>
enebo: yeah but the parser doesn't know enough at the right time, and neither does the lexer, or at least I couldn't figure it out
<enebo>
chrisseaton: one reason for not wanting a factory is warmup from the extra indirection. JVM does warmup fine with a factory but before that point it all shows up
<enebo>
chrisseaton: jruby-parser does seem to largely maintain all the info and so we used to keep enough info
<enebo>
chrisseaton: well most of it anyways…some syntax is never made into tokens
<enebo>
chrisseaton: although in jruby-parser there is a map maintained for all non-semantic syntax
<enebo>
chrisseaton: which is a pretty horrible solution
<chrisseaton>
maybe Truffle should just depend on jruby-parser
<enebo>
chrisseaton: so do you want full info all the time or just for a mode?
<enebo>
chrisseaton: I guess it is tough to say what is the right thing to do here. In JRuby proper, we used to maintain the world as far as node info and we paid a measurable price for that
<chrisseaton>
enebo: I think we want it all the time, but I guess we might have to backtrack on that when we start tuning for startup performance and start running tons of code like rails
<enebo>
chrisseaton: startup time is the largest problem JRuby has by far so slowing things down a little bit for this is not very desirable
<enebo>
chrisseaton: Another idea I have been thinkng about is mmap of file source
<chrisseaton>
In SVM we have the lexer and parser compiled to native, so we hope that will make a big difference
<enebo>
chrisseaton: so methods need to know where they start and end but then we can display source of code
<enebo>
chrisseaton: perhaps we could incrementally parse regions on demand to build the info if you end up wanting the info
<enebo>
chrisseaton: but the problem with this is keeping all loaded source in memory is not full time desirable :)
<enebo>
chrisseaton: yeah cool
<enebo>
chrisseaton: we actually talked about making a JNI parser
dinfuehr has joined #jruby
<enebo>
chrisseaton: 2 options there 1) alloc Java AST tree 2) expose access to native tree to Java
<enebo>
chrisseaton: feels criminal to me and I am not sure if it would be faster
tcrawley-away is now known as tcrawley
subbu|lunch is now known as subbu
vyorkin has joined #jruby
bbrowning_away is now known as bbrowning
mitchellhenke has joined #jruby
colinsurprenant has quit [Quit: colinsurprenant]
skade has quit [Quit: Computer has gone to sleep.]