<tarcieri>
headius: the protobufs stuff makes me sad
<tarcieri>
headius: the annoying thing is a native protobufs binding to the Java library would be great! if they cared
<tarcieri>
but it seems like they don't care
<Antiarc>
I can see their viewpoint - from the outside, jruby is a marginal implementation
<tarcieri>
and if they don't care, it will be a second class citizen
<Antiarc>
But yes, ultimately, it is sad
<tarcieri>
if you guys put the work into making it awesome that'd be great
<tarcieri>
Antiarc: their viewpoint was more roflscaling MRI
<tarcieri>
they could, you know, implement more FFI-friendly/performant APIs in protobufs itself
calavera has joined #jruby
<tarcieri>
they were talking about calling back from native code into Ruby to use individual method calls to set members of a struct-alike
<tarcieri>
and I was like WTF don't do that, there's your problem
subbu has quit [Ping timeout: 258 seconds]
<tarcieri>
yajl-ffi is 6x slower than the MRI C extension running an unspecified benchmark on an unspecified Ruby interpreter on unspecified hardware when it's doing total crazysauce like using the Ruby method protocol to construct a struct
<tarcieri>
no fucking shit sherlock, that sounds like a bad time
<tarcieri>
they control both sides of this binding as a single, atomically commitable monorepo
<tarcieri>
compared to what I've tried to do, this is fucking cake
<tarcieri>
when I've done FFI bindings, I've had to file issues with the upstream library to get them to add FFI-able APIs and limp along as they get added
<tarcieri>
that's the main argument against FFI, but if you control both the library and the language binding in the same repo then it should be way simpler and cleaner than getting a bunch of MRIcrap in your way
<tarcieri>
and you wind up with a library that's easy for any language with an FFI to bind to
subbu has joined #jruby
anaeem1_ has joined #jruby
anaeem1_ has quit [Read error: Connection reset by peer]
anaeem1 has joined #jruby
subbu has quit [Ping timeout: 245 seconds]
subbu has joined #jruby
subbu has quit [Ping timeout: 250 seconds]
yfeldblum has quit [Ping timeout: 258 seconds]
subbu has joined #jruby
subbu has quit [Ping timeout: 256 seconds]
subbu has joined #jruby
<Antiarc>
I totally agree with you, FWIW
purplefox has quit [Ping timeout: 250 seconds]
phrinx has joined #jruby
brettporter has joined #jruby
purplefox has joined #jruby
Felystirra has joined #jruby
yfeldblum has joined #jruby
Hobogrammer has joined #jruby
phrinx_ has joined #jruby
phrinx has quit [Ping timeout: 265 seconds]
Felystirra has quit []
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
phrinx_ has quit [Remote host closed the connection]
phrinx has joined #jruby
Hobogrammer has quit [*.net *.split]
anaeem1 has quit [*.net *.split]
dbussink has quit [*.net *.split]
brettporter has quit [*.net *.split]
jimbaker has quit [*.net *.split]
balo has quit [*.net *.split]
djbender has quit [*.net *.split]
electrical has quit [*.net *.split]
amdprophet has quit [*.net *.split]
e_dub has quit [*.net *.split]
tcrawley-away has quit [*.net *.split]
purplefox has quit [*.net *.split]
tsunamie has quit [*.net *.split]
errstr has quit [*.net *.split]
mpapis has quit [*.net *.split]
kwando has quit [*.net *.split]
phrinx has quit [*.net *.split]
subbu has quit [*.net *.split]
dfas has quit [*.net *.split]
kotk has quit [*.net *.split]
jeremyevans_ has quit [*.net *.split]
brycek has quit [*.net *.split]
ahadding1 has quit [*.net *.split]
justinmcp_ has quit [*.net *.split]
yfeldblum has quit [*.net *.split]
dcolebatch has quit [*.net *.split]
zph has quit [*.net *.split]
mccraig has quit [*.net *.split]
gazarsgo has quit [*.net *.split]
n1ftyn8 has quit [*.net *.split]
bruceadams has quit [*.net *.split]
Scorchin has quit [*.net *.split]
Freaky has quit [*.net *.split]
teamon_ has quit [*.net *.split]
ylluminate has quit [*.net *.split]
jamooo has quit [*.net *.split]
_ko10 has quit [*.net *.split]
yosafbridge has quit [*.net *.split]
tarcieri has quit [*.net *.split]
Sinjo has quit [*.net *.split]
portertech has joined #jruby
dabradley has joined #jruby
fidothe_ has joined #jruby
jarib has joined #jruby
teamon_ has joined #jruby
noop has joined #jruby
JohnBat26 has joined #jruby
brettporter has joined #jruby
brettporter has joined #jruby
rsim has joined #jruby
josh-k has joined #jruby
rsim1 has joined #jruby
rsim has quit [Read error: Connection reset by peer]
robbyoconnor has joined #jruby
jumex has joined #jruby
mister_s_ has joined #jruby
noop has quit [Quit: Leaving]
jumex has quit [Quit: jumex]
noop has joined #jruby
rsim1 has quit [Read error: Connection reset by peer]
mister_s_ has quit [Ping timeout: 250 seconds]
pchalupa has joined #jruby
rsim has joined #jruby
brettpor_ has joined #jruby
brettporter has quit [Ping timeout: 245 seconds]
dumdedum has joined #jruby
brettpor_ has quit [Remote host closed the connection]
elia has joined #jruby
josh-k has quit [Remote host closed the connection]
marr has joined #jruby
mister_s_ has joined #jruby
brettporter has joined #jruby
fridim_ has joined #jruby
vtunka has joined #jruby
josh-k has joined #jruby
drbobbeaty has joined #jruby
Usuario_ has joined #jruby
Usuario_ is now known as frobs
brettpor_ has joined #jruby
brettporter has quit [Ping timeout: 245 seconds]
Usuario_ has joined #jruby
frobs has quit [Ping timeout: 252 seconds]
Usuario_ is now known as frobs
josh-k has quit [Remote host closed the connection]
josh-k has joined #jruby
josh-k has quit [Remote host closed the connection]
<mkristian>
i.e. where and how do I use those eventHooks from ruby
<headius>
mkristian: hmmm
<headius>
well, it would be set_trace_func from Ruby
<headius>
or the newer TracePoint stuff
<mkristian>
let me see then
<enebo>
rtyler: it raining there?
<mkristian>
hmm this merge looks indeed painful
<headius>
mkristian: I'm confused how that fixed the bug
jumex has joined #jruby
<headius>
oh duh
<mkristian>
the new list was empty but the last entry which was the new eventHook
<headius>
it wasn't copying
<mkristian>
yes
<rtyler>
enebo: it is raining, I'm in a big fuckoff skyscraper though, so none of it affects me now
<headius>
ick...I wonder if that was me
<mkristian>
well, it was an easy fix ;)
<rtyler>
there's people who are working from home because their commute would be a little longer
<enebo>
rtyler: hah
<rtyler>
it's so silly
<jumex>
Hi all. I was wondering if anyone here has had experience running warbler (and bundler) using only maven without a system jruby installation?
<enebo>
rtyler: looks like some SF folks have sand bags outside their businesses. I guess living a bottom of hill might mean some highly localized flooding
<electrical>
headius: hiya
<headius>
electrical: hello
<rtyler>
jumex: lots of it here
<rtyler>
well, you need to run warbler with jruby-complete
<rtyler>
but that's not hard to do
<electrical>
headius: do you know if a recent build has been created for jruby 9? the last one we used broke :-)
<jumex>
rtyler: I figured I needed jruby-complete. Good to know that is the right path. I think where I am getting stuck is that I am not sure how to bundle all my gems up so that warbler exists and can use them.
<headius>
electrical: I think ruby-build should be using the right tarball now...what do you use?
<headius>
I'll double-check that snapshots are still being made properly
<rtyler>
jumex: have you tried using bundler installing into a specified path?
<electrical>
we were using this one: jruby 9.0.0.0.dev-SNAPSHOT (2.2.0p0) 2014-11-18 0cfdfe5 Java HotSpot(TM) 64-Bit Server VM 25.25-b02 on 1.8.0_25-b17 +jit [linux-amd64]
<electrical>
haven't updated rbenv yet
<headius>
ok, filename has changed since then
<electrical>
wanted to make sure first if a more recent build was made :-)
<headius>
indeed there is...let me update our silly index.html for it
<electrical>
hehe okay :-)
<headius>
ruby-build should do the right thing...I believe they merged my last PR
<electrical>
will update rbenv on our jenkins node and re-test
<jumex>
rtyler: That is one path I was following, but I was having a hard time getting maven to recognize the GEM_HOME/GEM_PATH I set up.
<rtyler>
maven doesn't install the gems or anything like that with warbler jumex
<jumex>
So, I am thinking the steps are: 1) get jruby-complete, 2) use it to gem install bundler to a path, which I check in with my project, 3) use antrun with jruby-complete to run bundle install from maven, 4) use antrun with jruby-complete to run warble.
<headius>
that's a maven failure of some kind
<jumex>
rtyler: yeah, that is what I am discovering.
<headius>
failed to build altogether
<rtyler>
if you want a MUCH COOLER way of building jars and wars, boy do I have the plugin for you!
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
yfeldblum has joined #jruby
Aethenelle has joined #jruby
yfeldblum has quit [Ping timeout: 265 seconds]
<bbrowning>
enebo: headius: so I'm trying to get TB4's smaller integration test suite passing on JRuby 9.0.0.0 snapshots - as I find issues, just create a github issue for each?
<bbrowning>
ie the constant "File::FNM_EXTGLOB" doesn't appear to exist in JRuby even though it's part of Ruby 2's File constants
Hobogrammer has joined #jruby
<bbrowning>
I guess I can assume if the constant doesn't exist none of the behavior triggered by it doesn't as well?
<bbrowning>
double negative, but you understand I think :)
<enebo>
bbrowning: open each as an issue
<Aethenelle>
bbrowning: that's likely only the case for features that are implemented in Java with java equivalents. If it's implemented in C (jnr-posix), you can use the value of the constant and itll work
<bbrowning>
that issue prevents Rails 4.1 apps from working at all
<Aethenelle>
... unless JRuby checks the range (against something like FNM_MAX dunno if that actually exists) and the one you're using falls outside the range...
<enebo>
bbrowning: ;P
<Aethenelle>
not likely with ioctl
skade has joined #jruby
r0bby_ has quit [Ping timeout: 250 seconds]
benlovell has quit [Ping timeout: 244 seconds]
colinsurprenant_ has joined #jruby
colinsurprenant has quit [Ping timeout: 264 seconds]
colinsurprenant_ is now known as colinsurprenant
kgerman_ has joined #jruby
calavera has joined #jruby
kgerman has quit [Remote host closed the connection]
<nirvdrum>
enebo: RubyEncoding has two factory methods that never seem to be used. Are you keeping them around for compatibility with something?
<jc00ke>
Also, no idea if I got encoding right (probably didn't in the least)
<headius>
jc00ke: oh thanks! I was traveling this week
<enebo>
nirvdrum: don’t know offhand. It is possible it was a 1.8/1.9 thing
yfeldblum has joined #jruby
<nirvdrum>
I can delete them while I'm in there. But don't want to break things.
<jc00ke>
headius: no worries! Looking forward to feedback on the PR
<enebo>
nirvdrum: The only possibility of them being used would be if bytecode generation called them which is extremely unlikely
<enebo>
nirvdrum: remove them
<enebo>
nirvdrum: actually another would be java native ext but that seems unlikely to me
<chrisseaton>
there's quite a lot of dead code in master now - I don't delete it as I go as I don't want to mix truffle/non-truffle commits
<nirvdrum>
headius: You also have a mess of deprecated methods in RubyEncoding from almost 4 years back. 9k might be the time to remove them.
<headius>
definitely
<chrisseaton>
perhaps we should have an annotation for public APIs, so that we know what not to delete as it looks like dead code
<headius>
and now is the time to do it, so we can catch exts that need it
<enebo>
yeah it has been the goal all along
<headius>
chrisseaton: that's what enebo wants to do
<enebo>
chrisseaton: I proposed @Extension…Did I ever make it though? :)
<nirvdrum>
chrisseaton: Is mixing commits that problematic? We use the [Truffle] prefix for Truffle stuff.
<nirvdrum>
Heh. "// TODO: make threadsafe" -- from 2008.
<bbrowning>
DONE
yfeldblum has quit [Ping timeout: 252 seconds]
<chrisseaton>
nirvdrum: surely best not to hide potential changes to the normal JRuby external API in a Truffle commit?
<nirvdrum>
chrisseaton: Well, you could make it a separate commit. I thought you meant you didn't want git log to have Truffle and then non-Truffle commits.
<chrisseaton>
yeah I could stage stuff more carefully
<enebo>
yeah you guys can do as many general JRuby commits as you want…just don’t mix into truffle-specific commits
<enebo>
which I think you both know
<nirvdrum>
"git add -p" is your friend here.
<headius>
-p is the best git flag
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] nirvdrum pushed 2 new commits to master: http://git.io/w-fDUQ
<JRubyGithub>
jruby/master 8bd0df2 Kevin Menard: Removed unused RubyEncoding factories.
<JRubyGithub>
jruby/master c34b8db Kevin Menard: Removed a bunch of unused, deprecated RubyEncoding methods.
JRubyGithub has left #jruby [#jruby]
<enebo>
sneaky p
<nirvdrum>
*slipper p
<nirvdrum>
*slippery
<nirvdrum>
2 weeks until Christmas. How's 9k pre1 looking anyway?
<enebo>
nirvdrum: It could be looking better
<nirvdrum>
IR stuff? Or stdlib?
<enebo>
nirvdrum: Some IR some features but we are getting pretty close. It is just tight.
kgerman has quit [Ping timeout: 245 seconds]
pataprogramming has joined #jruby
x1337807x has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<pataprogramming>
I'm currently fighting with become_java!, and would appreciate some advice...the resulting classes seem to ignore the java_package directive.
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<pataprogramming>
I need to generate classes with specific package paths for use with a plugin filter system.
<pataprogramming>
The system currently supports Groovy, and I'm hoping to add the ability to create filters in JRuby.
<headius>
pataprogramming: hello :-)
<pataprogramming>
headius: Greetings.
<headius>
hmmm
<headius>
become_java! doesn't use java_package, I believe...only jrubyc at command line will use it
<pataprogramming>
Unfortunately, the filters get dropped into a directory of the live system, and are compiled on the fly...so precompilation isn't really a good path.
<pataprogramming>
Anyway to invoke jrubyc's functionality programmatically without going through the shell?
<headius>
sure, it's just a Ruby script...but I don't know if we have documented how to do it
<headius>
may I ask why you need to generate real Java classes for this?
<headius>
I'm going to guess that whatever plugin system this is requires a class it can Class.forName
<pataprogramming>
Could be...so far, I've been trying to imitate the approach that the authors used for the Groovy plugin support.
skade has quit [Read error: Connection reset by peer]
<headius>
seriously, do Groovy developers actually write any Groovy? Every time I find a project that claims it's written in Groovy, it's 95% Java
triple_b has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<headius>
all these plugins have more code in Java than in Groovy
<headius>
anyway...
<pataprogramming>
Basically, by implementing getClassFromFilterFile() on that FileSystemPollingFilterStore(), it should be pretty straightforward...but it is expecting a class.
<pataprogramming>
Groovy seems to be more-or-less Java that can be written while drunk.
skade has quit [Client Quit]
r0bby_ has joined #jruby
<pataprogramming>
I haven't chased down how the package prefix is used in the code yet, but it does expect one or more prefixes to be specified.
<headius>
pataprogramming: hah, I like that description of Groovy
elia has joined #jruby
<headius>
pataprogramming: hmm yes, I hate plugin systems that use Class instances
<headius>
and then I'm sure it goes on to try to instantiate it
<headius>
using a default constructor
<pataprogramming>
At the moment, I'm trying to figure out what I can coax JRuby into spitting out...I'm sure the two can be made to meet in the middle somehow, but I'm hoping it's not too hacky.
<headius>
this is such a stench that's all over all plugin systems
<headius>
pataprogramming: if you evaluate that script, become_java! returns the class it created
<pataprogramming>
Well, not any hackier than any system is that relies on reflection.
<headius>
indeed
<headius>
I forget if the class is instantiable with a default constructor...checking that now
<pataprogramming>
This is my first time doing much mucking around with JRuby...am I going to get any nasty jrubyc-related surprises if I have that class implement an interface?
<pataprogramming>
Or extend an abstract class?
<headius>
pataprogramming: it appears to work
<headius>
so what you'd want to do is basically just evaluate the script and you'll get a Class out of it
<pataprogramming>
So package prefix may not matter.
<headius>
yeah probably not
<headius>
but I assume there's an interface to impl or something?
<pataprogramming>
headius: Yes, so as long as become_java! includes that in the generated code, all should be good.
<headius>
if you specify it in the code it will
<pataprogramming>
Then that's next on the list to try. Thanks very much for the assistance.
<headius>
java_implements
<headius>
yup, let me know how it goes
<headius>
we need better doco on how to integrate with systems like this
<imperator>
enebo, found a workaround - explicitly opent the file in binmode
<enebo>
imperator: yeah that will for sure give a consistent view
<enebo>
imperator: Their read(30) seems like buggy behavior to me though
<imperator>
it doesn't match the docs
<imperator>
or rather, what the docs -imply-
<imperator>
i'm sorta confused my own self
elia has quit [Quit: Computer has gone to sleep.]
r0bby_ has quit [Remote host closed the connection]
triple_b has joined #jruby
<nirvdrum>
Why is JCodings so obtuse?
<pataprogramming>
headius: When I was digging around online, it looked like this was a pain point for people who were trying to interop with systems that rely heavily on dependency injection.
<Aethenelle>
dunno... ditched it before i had to deal with it much... my questions for jcodings is "why only ints?"
yfeldblum has joined #jruby
robbyoconnor has joined #jruby
robbyoconnor has quit [Changing host]
robbyoconnor has joined #jruby
<nirvdrum>
Oh, I didn't realize that was a JRuby project. Oops.
justinsmestad has joined #jruby
<headius>
nirvdrum: the API is not friendly
<headius>
but we've never spent time to improve it
<headius>
it's mostly the C API
<nirvdrum>
headius: What's "p" mean? I assume it's some sort of pointer.
<headius>
yeah, just a position reference
<headius>
char**
<headius>
an "out" holder
byteit101 has joined #jruby
robbyoconnor has quit [Client Quit]
<nirvdrum>
headius: Any objections to me introducing a new interface both RubyEncoding implementations can use so I can make better use of some of the stuff in EncodingService? I'd really hate to reimplement all this byte twiddling.
<headius>
go for it
justinsmestad has quit [Client Quit]
<headius>
anything we can do to unify the truffle and non-truffle side of things
jstad has joined #jruby
yfeldblum has quit [Ping timeout: 245 seconds]
<nirvdrum>
Cool.
<enebo>
nirvdrum: much of jcodings and joni follow C impl close because it is really complicated and it is easier to track evolution of C project
<byteit101>
currently using mkristian's jbundler and mvn tools on a jruby project, I get "jbundler support needs jruby to create a local config: jruby -S jbundle install"
<enebo>
nirvdrum: which that said any nice wrapper around it would be fucking great
<nirvdrum>
enebo: Makes sense. I was just hoping for some javadocs.
<enebo>
nirvdrum: HAHAHA
<byteit101>
I've not used maven much, and am unsure what the error means/ how to fix it
<nirvdrum>
I think I'd rather just figure out a way to use it.
<byteit101>
that line is thrown in the rakefile when I do `wt = Warbler::Task.new`
<enebo>
heh
<nirvdrum>
And that was all written in 2008 by a guy I don't think I've ever seen around here.
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<enebo>
nirvdrum: it is lopex
<nirvdrum>
Oh, really? I thought his name was something else.
<lopex>
did I do something wrong
<nirvdrum>
lopex: Just JCodings :-P
<enebo>
nirvdrum: but any questions about stuff and lopex is your guy for regexps and m17n
<lopex>
hey, I wrote more jruby code than joni and jcodings
<enebo>
lopex: tehcnically you ported those two as well
<nirvdrum>
lopex: I'm looking to implement encoding in Truffle. Getting the name from an encoding is a bit complex.
<headius>
lopex: it is just challenging to use the C-like APIs and we've never added nicer ones
<headius>
you didn't do anything wrong :-)
<nirvdrum>
But I'm going to see if I can find a way to share a lot of the core stuff in EncodingService.
<lopex>
nirvdrum: well, it's a direct port, and any diff when you'll troy to simplyfy it will come up eventually
mitchellhenke has joined #jruby
<lopex>
nirvdrum: also, that code in mri might have changed
<lopex>
nirvdrum: why not use that ?
<nirvdrum>
lopex: Why not use what? The code in MRI?
<lopex>
headius: the only nicer thing is named backref iterators
<lopex>
:)
<lopex>
headius: or where they tossed lots of function pointers at once
<lopex>
nirvdrum: the code in jruby
<lopex>
nirvdrum: do you use ByteList as well ?
<nirvdrum>
lopex: Well, I'm trying to. But we have a different class hierarchy.
<lopex>
nirvdrum: then we might try to split some code in jruby base ?
<nirvdrum>
lopex: That's what I'm looking at now. There's a lot of stuff that could be shared, since they both use JCodings and ByteList.
<lopex>
nirvdrum: dont complain here, in mri world, they all copy and import foreign code into mri's repo :)
<lopex>
nirvdrum: and more, they copy that into mri's internals
<lopex>
so you dont know it was a part of an external library in the past
<nirvdrum>
I'm not faulting you. Porting C make sense. It's just hard to follow is all.
<lopex>
nirvdrum: I'm being ironic
<nirvdrum>
All these p's and end's.
<lopex>
yeah
diegoviola has quit [Ping timeout: 244 seconds]
<lopex>
I know
<lopex>
nirvdrum: but in such messy c code it's easier to relate the things
<nirvdrum>
Right.
<headius>
definite want to split out shared logic from e.g. StringSupport, RubyString, IO, if it isn't already
<lopex>
nirvdrum: initially we though that after some baking we might do some refactoring
<lopex>
nirvdrum: like, StringSupport might go into jcodings
<nirvdrum>
It's been 6 years :-P
<headius>
6 glorious years of p
<enebo>
we really should do one pass through RubyString and symbol to remove the duality between 1.8 and 1.9 methods
<nirvdrum>
Heh.
<lopex>
nirvdrum: but it was a lot harder to modify two projects at once
<headius>
nirvdrum: I think it has never happened because once wired up we don't really use those methods anymore
<headius>
we go through StringSupport for most things
<headius>
and it does the right thing
<enebo>
since some are not encoding and others are
<lopex>
enebo: is there still a duality ?
<nirvdrum>
Yeah. Don't fix what isn't broken.
<headius>
actually StringSupport and other logic in JRuby probably could be the beginnings of a nicer Java-friendly API for jcodings
<headius>
would love to move more of that stuff out to libs
<lopex>
headius: but StringSupport was done much later on
<headius>
lopex: indeed
<headius>
but probably half its methods are basically just jcodings logic with a nice face
<enebo>
lopex: well the 1.8-specific @JRubyMethods are cleaned up but the lower layers we still have 1.9 encoding-aware methods calling non-encoding specific methods
<headius>
that and code range stuff
<enebo>
I find it unfortunate that CR represents semantic behavior and is not specifically just an optimization flag
<headius>
enebo: did you see four regressions in jruby-openssl?
<enebo>
no
<headius>
updated by mkristian a bit ago
<headius>
I believe the implication is that if we fix those we can put out 0.9.6
<enebo>
headius: cool if true
<headius>
they're not going to be fun though
<enebo>
yay something other tham repo2 now has jnr-constants
<lopex>
nirvdrum: another difficulty when looking at mri's code is that you have absolutely no idea at first glance, what code relies in runtime and what code is independent
<lopex>
*relies on runtime
<lopex>
it might pass void* and then cast it into VALUE
<enebo>
lopex: That is known as adding VALUE
<lopex>
yeah
<lopex>
capitalized
<lopex>
even better
colinsurprenant has quit [Quit: colinsurprenant]
<lopex>
you need to trace the fuction bodies to know that
mkristian has quit [Quit: bye]
<headius>
nirvdrum: just be glad you don't have to reimplement the transcoding subsystem
<headius>
it was a "fun" exercise but I wouldn't wish it on anyone
<lopex>
I guess I thought that from the other end
<lopex>
but I guess I'd still fail at that state machine
<nirvdrum>
Fortunately, most of these methods are private, so I should be able to make this work without too much bloodshed.
<JRubyGithub>
[jruby] nirvdrum pushed 1 new commit to master: http://git.io/r6TfRQ
<JRubyGithub>
jruby/master ca99b12 Kevin Menard: Removed unused constructors.
JRubyGithub has left #jruby [#jruby]
skade has joined #jruby
josh-k has quit [Remote host closed the connection]
e_dub has joined #jruby
fridim_ has quit [Ping timeout: 245 seconds]
colinsurprenant has joined #jruby
mister_s_ has quit [Ping timeout: 244 seconds]
anaeem1_ has quit [Remote host closed the connection]
<lopex>
numbers ?
egp has joined #jruby
<egp>
I'd like to be able to use a ruby gem (https://github.com/staqapp/staq-msbin) in my scala project, was looking at maybe using jruby to do it, and use the scriptenginemanager (https://github.com/jruby/jruby/wiki/JavaIntegration) one thing I'm little confused about this theoretical solution, would be howto reference the gem, and I would do the reference import/call the actual MSBIN::Record.DecodeStream
<egp>
that, and how it would get packaged in my jar/etc rather than having to a do a "gem install" on any production box
<nirvdrum>
lopex: Is there a reason that RubyEncoding#getEncoding lazily loads the encoding?
<nirvdrum>
It looks like creating the RubyEncoding instance with the Encoding instance would be trivial.
<lopex>
nirvdrum: initially, it was to monomorphize encoding callsites
<lopex>
nirvdrum: in a hope that only two of them being loaded
<lopex>
like ascii and utf-8
<lopex>
nirvdrum: and hotspot likes to inline bimorphic ones
<nirvdrum>
I don't follow. It's just an object reference.
pataprogramming has quit [Ping timeout: 240 seconds]
<lopex>
nirvdrum: hotspot is aware of classes being loaded and can optimize for that
<lopex>
if one class is being loaded it can totally devirtualiza the calls
<lopex>
even when called via interface
<lopex>
chrisseaton: can you clarify if I'm wrong here ?
<nirvdrum>
lopex: But this is all done during runtime bootstrap.
<chrisseaton>
lopex: what you are saying makes sense in theory - but I would be very surprised if you can measure a difference
rsim has quit [Quit: Leaving.]
<nirvdrum>
I don't want to bloat startup time, but I suspect this one callsite can't be optimized anyway.
yfeldblu_ has joined #jruby
<lopex>
chrisseaton: I guess, I'd think as you as well now, but that code was written quote a bit ago
<lopex>
chrisseaton: I was much more gullable to that then
<lopex>
nirvdrum: it's not this callsite
<lopex>
nirvdrum: the theory was that any encoding callsite would/could
rsim has joined #jruby
<chrisseaton>
lopex: we're building a research tool for truffle that will show you the source code and will overlay information such as how polymorphic a call site is - so you would be able to tell for sure - but not sure there's any existing tool like that at the moment
<lopex>
chrisseaton: and anyways in most cases it would be deopted
<lopex>
nirvdrum: class loading isnt any issues here I guess
yfeldblum has joined #jruby
<nirvdrum>
lopex: I'm not trying to chastise you anything. I just want to know if there's a landmine I should be watching out for.
<lopex>
chrisseaton: but still, having only one implementor changes things ?
<lopex>
nirvdrum: like, concurrency wise or something ?
<nirvdrum>
lopex: Although the problem with doing it this way is RubyEncoding#getEncoding isn't thread-safe, as you commented.
<lopex>
nirvdrum: because it's all per runtime
<chrisseaton>
lopex: yeah - interfaces will be faster if there is one implementation - and get deoptimized when another implementation is loaded - I can see that happen for real
<lopex>
nirvdrum: then it's more forgiving
<lopex>
nirvdrum: but yeah, that code need to be revisited
<lopex>
*needs
<lopex>
chrisseaton: that's what I was thinking about back then
yfeldblu_ has quit [Ping timeout: 240 seconds]
<lopex>
chrisseaton: but from hotspot related readings and some hotspot code study
<nirvdrum>
lopex: Fair enough. I just wonder if the cost of being lazy would dominate the cost of any potential deopt from class loading.
<lopex>
nirvdrum: ah, there's another thing
<lopex>
nirvdrum: encoding tables
<lopex>
nirvdrum: thoese are loaded via static field dependencies and some of them are HUGE
<lopex>
nirvdrum: like 1MB
<nirvdrum>
So, you're lazy loading classes from the classpath too?
<lopex>
nirvdrum: it hurts ruboto folks to the point of unacceptable
Aethenelle_ has joined #jruby
<lopex>
nirvdrum: no, static fields being fed from files
Aethenelle has quit [Ping timeout: 244 seconds]
Aethenelle_ is now known as Aethenelle
<lopex>
nirvdrum: and that dependency is being than by jvm spec
<lopex>
*s/than/done/
<lopex>
nirvdrum: this eliminates synchronization
<lopex>
nirvdrum: is that clear enough ?
<nirvdrum>
I guess where I'm confused is I already have an encoding iterator walking each of the entries in EncodingDB, so aren't these classes already loaded?
<lopex>
nirvdrum: encoding db entry is just a holder for encoding
imperator3 is now known as imperator
<nirvdrum>
Okay. So they are lazy loaded then?
<lopex>
yes
<lopex>
like I said
<nirvdrum>
Well I thought I asked if you were lazy loading classes and you said "no".
<lopex>
nirvdrum, chrisseaton: so all the locking etc is being done withing jvm class loading dependency spec
<nirvdrum>
No worries.
<lopex>
oh
<lopex>
I must have made a mistake
<nirvdrum>
I'm looking at the JCodings source now. I see that they're being lazy-loaded.
<lopex>
yes
<nirvdrum>
Ruboto, I fear, is a bandaid we're going to have to rip off at some point :-/
<lopex>
nirvdrum: since you where asking why getEncoding loads a class
colinsurprenant has quit [Quit: colinsurprenant]
colinsurprenant has joined #jruby
<nirvdrum>
But I don't have a good solution for that one yet.
<lopex>
for ruboto ?
<lopex>
maybe some maven annotation processing thingy ?
<nirvdrum>
Yes. I don't like the idea of leaving people behind, but we go through quite a few gymnastics to continue supporting it.
<nirvdrum>
I can't see Truffle ever working for it.
<nirvdrum>
With Go now supporting Android, I have a sneaking suspicion that's going to be Google's exit strategy.
<chrisseaton>
I've set up some tools to remove Truffle from the build to help Ruboto
<nirvdrum>
And RubyMotion is a thing now.
<lopex>
nirvdrum: also there is the complication for some encodings wrt transcoding tables
<lopex>
nirvdrum: some of them are really huge and we still ship the whole thing
<lopex>
even NOBODY uses it
<lopex>
it's too rare
<lopex>
the GB* thingy
<nirvdrum>
Okay. Well, that I can buy into.
<lopex>
nirvdrum: mri doesnt pay for it that much since it's just an fread on c binary
<lopex>
nirvdrum: but jruby goes the whole unzip
skade has quit [Quit: Computer has gone to sleep.]
SynrG has quit [Read error: Connection reset by peer]
treehau55 has quit [Ping timeout: 246 seconds]
<lopex>
nirvdrum: but I was all alone on the encoding site of things and the amount of required solutions overwhelmed me
<nirvdrum>
Heh. I'm not criticizing :-)
<lopex>
so lots of things are not being touched for years
<nirvdrum>
I'm just looking at code written in 2008 and am curious.
SynrG has joined #jruby
<nirvdrum>
And unfortunately, a lot of the older stuff is wholly undocumented.
<lopex>
most of jruby was so in those years
<lopex>
nirvdrum: I only fixed some critical bugs and about two years ago did some more important joni optimizations
<lopex>
and that was it
<lopex>
for some time
<lopex>
nirvdrum: joni is quite a bit behind onigmo too now
<nirvdrum>
lopex: Yeah. chrisseaton filed an issue a few days ago. I don't know if you saw.
<nirvdrum>
Maybe that doesn't tie into joni. But it's regexp-related.
<lopex>
yeah
<lopex>
linked in the todo
<lopex>
might be just quoting/unquoting for #sources
<lopex>
*#source
skade has joined #jruby
<lopex>
the whole regex thing is heinous, in mri it's multiply copied and processed, and the string that is being matched against, it's preprocessed and COPIED at least once
<lopex>
it's a joke
<lopex>
in jruby it's quite likely (given encdogin oportunites) regexp source in joni regexp is the SAME as the one at parse time
<lopex>
joni even tries to COW the literal anchors within it's own AST on expand