haze has quit [*.net *.split]
quadz has quit [*.net *.split]
eonwe has quit [*.net *.split]
sgeorge has joined #jruby
vext01 has quit [*.net *.split]
Sigyn has quit [*.net *.split]
Sigyn has joined #jruby
sgeorge has quit [Remote host closed the connection]
sgeorge has joined #jruby
sgeorge has quit [Ping timeout: 272 seconds]
sgeorge has joined #jruby
sgeorge has quit [Ping timeout: 244 seconds]
<kares> headius: the jruby-head CI failure with the RG suite went away for now ...
<kares> AR-JDBC 5x releases cut yesterday
<kares> so now hopefully some perf testing with RGs ... although I do not have data ;(
shellac has joined #jruby
jmalves has joined #jruby
sgeorge has joined #jruby
jmalves has quit [Remote host closed the connection]
jmalves has joined #jruby
sgeorge has quit [Ping timeout: 250 seconds]
jmalves has quit [Ping timeout: 252 seconds]
jmalves_ has joined #jruby
ChrisBr has quit [Ping timeout: 250 seconds]
ChrisBr has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
sgeorge has joined #jruby
sgeorge has quit [Ping timeout: 246 seconds]
drbobbeaty has quit [Ping timeout: 252 seconds]
shellac has joined #jruby
ChrisBr has quit [Ping timeout: 272 seconds]
ChrisBr has joined #jruby
sgeorge has joined #jruby
jmalves_ has quit [Remote host closed the connection]
<lopex> http://www.timqian.com/star-history/#jruby/jruby the trend doesnt seem to be decreasing
jmalves has joined #jruby
<lopex> unless it's all bots now
enebo has joined #jruby
<enebo> lopex: TO THE MOON
<lopex> and beyond
<lopex> how much of that are bots ?
jmalves has quit [Ping timeout: 244 seconds]
<enebo> lopex: well I would not say many...we have other projects with hardly any stars
<enebo> lopex: I guess once we got past a threshold of stars maybe that is when the bot hoard starts also starring? I don't really get stars in general
<lopex> so it might be threshold then
xardion has quit [Remote host closed the connection]
<enebo> lopex: or we may just have people starring our project...
<lopex> enebo: I also have problems quickly telling fork history on gh
<enebo> lopex: think about this if it were just bots they seem to join by small amounts over the entire length of this history
<enebo> lopex: seems more likely it is largely just users
<lopex> I'm not saying most of them are
<lopex> but what's the ratio
<lopex> enebo: jeez at last something that works https://github.com/billziss-gh/winfsp
<enebo> lopex: yeah good question....audit them and tell me once you looked at each one :P
<lopex> reliably
<lopex> enebo: but guss how they did the opts so it can be nc path compatible
<lopex> like host!port\..\..
<lopex> *unc
<lopex> enebo: yeah, starting now
<lopex> one by one
xardion has joined #jruby
<enebo> lopex: you know this sed pattern?
<enebo> lspci -v | sed -nr "/Wireless/, /^$/p"
<lopex> enebo: that fuse thing might be good for ci, since it seems to support fam and the like
<enebo> I feel like I should know it but if I ever knew it then it left my brain decades ago
<lopex> enebo: I always look at man when using sed
<enebo> lopex: but it is very nice at being able to get text between two regexps
<enebo> lopex: I now wonder why this is not common in Ruby
<enebo> lopex: OR IS IT?
<enebo> I don't know what -r is for and I see no mention of it in sed man page either
<enebo> oh extended regexp
<enebo> for alternations and stuff perhaps
<lopex> enebo: https://cheat.sh/sed
<lopex> er, that's not what I meant
<lopex> where is it
<lopex> it was a really cool playground
<enebo> lopex: are you on linux?
<lopex> enebo: depends
<enebo> lopex: you know what that command does?
<lopex> the whole thing ?
<enebo> that sed commands just prints out the section of the output from Wireless to the empty line of the next device
<enebo> so it allows me to target a single entry of that output instead of having it all
<lopex> ok
<lopex> enebo: well, I used to split on look ahead/behind in ruby but it's clearly more restricted
<enebo> lopex: can you give a snippet?
<enebo> you just mean capture groups on multiline regexp?
<lopex> enebo: jeeze somewhere in old gists
<enebo> I guess though this is non-greedy too
<enebo> since if you have two or three wireless...^$ they all print
<enebo> lopex: but I guess you can do that as well with one regexp
<lopex> enebo: do you have minimal example ?
<lopex> ab\n\nc ?
<lopex> like that ?
<enebo> I could supply my lspci output and say do the same thing
<enebo> I think we can specify non-greedy first_linere\n.*\nlast_linere and the center would be what we display
<lopex> so look aheads and behinds
<lopex> behind is more restricted though
<enebo> lopex: another way is to do what sed does and actually use two regexps
<lopex> enebo: can you gist it ?
<enebo> what?
<lopex> the lspci output
<enebo> ok
Puffball has joined #jruby
shellac has quit [Ping timeout: 240 seconds]
<lopex> enebo: yeah, hmm something like not yet satisfactory /(?<!\n)Wireless.*\n(?=\n)/m
<lopex> look behind limitations
telegardian has joined #jruby
sgeorge has quit [Ping timeout: 240 seconds]
<enebo> lopex: lspci -v | ruby -ne 'puts $_ if /Wireless/../^$/'
<enebo> Someone on twitter replied. I sweared I did this at first but I think I got a range error so maybe I mistyped it?
<enebo> I used " for -e so $/ was expanded by bash
sgeorge has joined #jruby
<lopex> enebo: yeah, two regexps though
<enebo> haha
<lopex> enebo: but I admint I havent used that
<lopex> admit
<enebo> lopex: true but this is likely not too perf sensitive
<lopex> yeah
<enebo> lopex: and your single regexp will end up being more archaic syntax-wise even if it does work the same
<lopex> yea
<lopex> enebo: and the problem is it wont
<lopex> enebo: the other thing is that you can go surprisingly far with reluctant modifiers
<lopex> the possessive one I found only useful with anchors
jmalves has joined #jruby
jmalves has quit [Remote host closed the connection]
jmalves has joined #jruby
<lopex> enebo: on the other note Cliff explains spectre https://www.youtube.com/watch?v=5ZOuCuGrw48&t=35m35s
sgeorge has quit [Read error: Connection reset by peer]
sgeorge_ has joined #jruby
<headius> I'm going to release jcodings with module stuff now
<headius> and then joni and bytelist in a while
<lopex> cool
<headius> enebo: a small snag in bytelist
<headius> the bytelist class lives in org.jruby.util
<headius> but we also have org.jruby.util in JRuby
<headius> I don't think that's going to work with modules
<enebo> HAHAH
<enebo> the gift which keeps on giving
<headius> looking into it now
<headius> "Java 9 does not allow split packages in different modules for the reason of the reliable configuration."
<lopex> headius: so there's no reexposure or renaming in modules ?
<headius> at least according to this first article this is a no-no
<lopex> ok, that explains it
<headius> apparently you can't even split packages that aren't exported
<lopex> headius: and everything is transitive ?
<enebo> renaming bytelist is not a huge deal for us but it is a huge deal for native extensions
<headius> well shading is going to be a whole different ball of mess
<lopex> lolz
<enebo> unless we make a org.jruby.util.ByteList which is a shim or something
<headius> enebo: yeah one could extend the other
<headius> well, JRuby one extend the ByteList one
<enebo> yeah
<lopex> headius: hmm, so maybe it's time to split tables from jcodings ?
<lopex> or even transcoding
<headius> lopex: into separate modules?
<headius> maybe
<lopex> yeah
<enebo> lopex: why?
<lopex> enebo: heavy
<lopex> enebo: we're the only users of transcoding tables
<enebo> lopex: because we may decide to use jcoding but not use data or transcoding?
<lopex> and api for that matter
<enebo> lopex: oh other users may want a smaller jar
<headius> also might be helpful for jaotc
<lopex> enebo: yes, the heavies ones are the less used
<headius> but I don't know
<enebo> well I don't actually care
<enebo> I don't think data changes enough for us to be bothered by an extra release
sgeorge_ has quit [Remote host closed the connection]
<lopex> also, joni doesnt even use transcoding and casing apis
<enebo> but I don't care if other projects have a larger jar either
<lopex> not my problem either
<lopex> just mentioned in case anyone cares
<enebo> has anyone ever asked?
<lopex> I dont recall
<lopex> but it's considerable size
<lopex> maybe not so much nowadays though
<lopex> enebo: I'm more concerned whether I shall have a beer now
<enebo> lopex: seems legit
<lopex> enebo: will definitely look at sunday search this week, since I'll have a dew days off
<lopex> er, next one
<lopex> and few
<lopex> dew day
<lopex> it is a thing ?
sgeorge has joined #jruby
<headius> enebo: so a question
<headius> actually nevermind...this bytelist package thing is a bummer
<headius> I was going to ask if we should switch to using the new package within JRuby but just ship a shim for backward compat
<headius> but the signature of any public API that receives or returns ByteList would change
<enebo> yeah it seems like just adding a class to jruby itself with org.jrbuy.util is only feasible option although some IDEs note which artifact a class comes from so it may confuse a few IDEs
<enebo> OTOH bytelist itself will have a new package so it likely will just reload and work
<enebo> It does screw with us a bit if we decide we want to change the API too
<enebo> I guess we can use the new package name and get changes but the jruby.util one somewhat needs to stay the same
mdrob has joined #jruby
<mdrob> I am working with somebody who will be upgrading from JRuby 1.7 to 9.1, are there any guides about things to watch out for?
<mdrob> Or is it expected to be fully compatible?
<headius> ahh hell
<headius> a bunch of ByteList methods return ByteList
<headius> so now they all return org.jruby.bytelist.ByteList
<headius> this is a mess
<headius> enebo: I don't know how to fix this
<lopex> lolz
<headius> only thing I can think of is eliminating org.jruby.util in JRuby or eliminating ByteList as an external library
<lopex> and what about jffi and the like ?
<headius> a third option is overriding every method that returns ByteList in our shim but we'd have to double-construct or make the real ByteList call some factory method
<headius> I don't think any of our other projects depend on bytelist
<lopex> headius: hah! and you wanted once joni depend on it :P
<lopex> screw it, and include in jruby
<lopex> headius: and it will help realigning the api too
<enebo> lopex: ah yeah pepe is illegal in EU right?
<lopex> enebo: I'm not following that
<lopex> enebo: but there's last chance in early 2019 to block iyt
<lopex> enebo: something like EP will listen to mass complains of citizens or something like that
<enebo> that graphic is a play on pepe the frog which was designated a hate symbol by ADL
<enebo> It is still constantly used for memes by gamers
<lopex> yeah, that is obvious
<headius> enebo: bytelist
<lopex> enebo: merge it
<enebo> headius: yeah I think we kill it as a project and people can depend on it for older stuff but it is just part of jruby from some point forward
<enebo> and that point could be now I guess
<headius> I'm trying to determine anything else that depends on the project
<enebo> headius: of ours?
<headius> anywhere
<lopex> or in maven repos ?
<lopex> headius: you dont count maven github deps I guess ?
<enebo> headius: well we can keep it as an artifact and even make it a module but just not use it ourselves
<headius> yeah obviously existing releases won't go away
<enebo> If no one is actually using it so much the better because then we don't need to fix bugs
<headius> yeah that's what I'd like to know
<lopex> headius: is there a chance for more fine grained exposure of org.joni.constants ?
<lopex> these ast nodes are exactly what I wanted to hide
<headius> yes
<headius> jcodings is released already but is there anything we want to hide in there?
<lopex> so all the deps are indirectly through jruby
<headius> I just exposed all packages
<headius> yeah looks like it
<lopex> headius: yes, I'd have to look
<lopex> headius: I can do it once you merge to master then
<headius> lopex: already done and released in 1.0.34
<lopex> headius: I dont see it on gh ?
<lopex> oh, jcodings
<headius> jcodings
<lopex> ok
<headius> joni I'll get done and pushed for you
<lopex> you should do a writeup on modules pitas
<headius> yeah I will
<lopex> and how it relates to tooling
jmalves has quit [Remote host closed the connection]
jmalves has joined #jruby
jmalves has quit [Ping timeout: 240 seconds]
<headius> lopex: pushed
<lopex> ok
<headius> oh I guess I only exposed the main package, constants, and exceptions
<headius> so maybe that's how you want it
<lopex> yeah I see it
<lopex> but want to exclude most of the constants
<lopex> what the state of the ides for that ?
<lopex> headius: since when I work on it I always have once colliding with once in nashorn
<headius> hmmm
<lopex> they will ditch nashorn in 11 I guess
<lopex> anyways
<headius> yeah
<lopex> once/ones
<lopex> jeez
<headius> I'm not sure there's a way to do that
<lopex> so everything changes now, mvn repo search even right ?
<lopex> well, gets additional complexity
<headius> I don't know
<lopex> since till now everythin was essentially public
<lopex> it even asks a question whethere a tool existed that rewrites bytecodes to keep private things in separate packages
<lopex> seems like a preset for proguard
<lopex> that was sarcasm ofc
<headius> I don't think you can even export individual classes
<headius> it works at a package level
<lopex> oh, so that's why there is "exports to" so you can refactor internally ?
<lopex> I guess my assumptions were bad
<headius> exports to is for exporting something to a specific set of modules
<headius> so like joni could export ast only to JRuby or something like that
<headius> used within JDK for hiding internal packages but allowing them to be called from other JDK modules
<lopex> so down the deps
<lopex> er, well, de deps are ineffective there
<headius> enebo: I'm going to go ahead with bytelist move on master
<lopex> headius: jeeze so reflection is whole other story
<headius> yes
<headius> but I'm just making these all open modules
<headius> bytelist move is on master
<lopex> this is something I always expected to happen
<headius> yeah it was fun while it lastest
<headius> lasted
<lopex> yeah, I remember from one of your talks that might be the most used singlefile project
<headius> apparently not by anyone but us
<lopex> yep
<lopex> well, except zillion of npm packages which have single functions
<lopex> and break whole dep trees used by big projects
<headius> hah yeah
<headius> left justify
<lopex> it's a meme already
sgeorge has quit [Remote host closed the connection]
mdrob has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
sgeorge has joined #jruby
sgeorge has quit [Read error: No route to host]
sgeorge has joined #jruby