sgeorge has quit [Remote host closed the connection]
jmalves has joined #jruby
jmalves has quit [Ping timeout: 252 seconds]
sgeorge has joined #jruby
mistergibson has quit [Remote host closed the connection]
sgeorge has quit [Remote host closed the connection]
sgeorge has joined #jruby
sgeorge has quit [Remote host closed the connection]
<kares> enebo: lopex :)))
<kares> headius: yeah haven;t poked around if its an existing issue - well at least it wasn;t on JRuby's tracker
<kares> seems like they don't rush to fix it so users have to remove gem 'bootsnap' under JRuby ;(
_whitelogger has joined #jruby
jmalves_ has joined #jruby
jmalves_ has quit [Remote host closed the connection]
jmalves has joined #jruby
drbobbeaty has joined #jruby
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Puffball_ has joined #jruby
shellac has joined #jruby
Liothen has quit [Quit: The Dogmatic Law of Shadowsong]
Liothen has joined #jruby
Puffball_ has quit [Remote host closed the connection]
Puffball has joined #jruby
rdubya has quit [Ping timeout: 264 seconds]
rdubya has joined #jruby
sgeorge has joined #jruby
<headius> kares: I think if we come up with a patch for them they'd release it
Eiam has joined #jruby
xardion has quit [Remote host closed the connection]
xardion has joined #jruby
shellac has quit [Ping timeout: 276 seconds]
sgeorge has quit [Remote host closed the connection]
<lopex> headius: I asked for org.jruby namespace on sonatype
<lopex> no sure if that's what I was supposed to do
<lopex> headius: but for now I need jcodings and joni release
<headius> lopex: you filed issue?
<lopex> yeah
<headius> I think I need to approve you, link me
<headius> or at least give me +1
<headius> my +1
<lopex> well, the type is "New Project "
<lopex> confusing
<headius> ah yeah there's another way but this will probably work ok
<headius> linkity link
<lopex> headius: where am I supposed to provide keys ?
<headius> keys? like password for your account on sonatype?
<headius> that goes in ~/.m2/settings.xml
<lopex> enebo mentioned about pgp key
<headius> oh for signing the releases
<headius> it should just use gpg command
<headius> I have a different set up because I use a yubikey...enebo can probably describe his setup better
<headius> it still just uses gpg for me too though
<lopex> ok, I'll poke him
<headius> lopex: they're quick, you're in
<lopex> wowsers
<lopex> thank you
<headius> yeah now it's just fiddling with config and auth
sgeorge has joined #jruby
<enebo> lopex: I just gave a public key
<enebo> well actually in ~/.m2/settings.xml I have two entries with id and a password
<enebo> but we definitely need to sign releases as well
<headius> I'm looking at this and the related code (RESTORE_EXCEPTION_VAR) and I don't think the code actually does anything anymore
<headius> if you look at what the JIT calls, IRRuntimeHelpers.restoreExceptionVar, it accepts IRubyObject for the exception and the only logic there runs if that exception is instanceof IRReturnJump or IRBreakJump
<headius> those types don't implement IRubyObject, and nothing extends them
<headius> so the method does nothing
<headius> there's similar logic in the interpreter
<enebo> headius: so can we just nuke that code and be ok?
<headius> test:jruby passed
<headius> I'm running specs
<headius> it's looking pretty good
Eiam has quit [Quit: Textual IRC Client: www.textualapp.com]
<headius> enebo: I pushed branch remove_restore_exception if you want to look at the commit
<enebo> headius: yeah looks good I think
<headius> I'll let CI chew on it for a bit and then merge if it's ok
<enebo> I mean my only confusion is we must set $! properly natively now
<enebo> I believe this was only added because there were pockets where it got lost
<enebo> so if those cases are gone then this is great
<headius> yeah
<headius> it seems like that's the case
<headius> I know we had this sort of logic sprinkled all over so this may have just been obsoleted without realizing it
<headius> I have a possible resolution
<headius> I could just replace the stops with some interrupts and chalk it up to non-native IO on Windows
<headius> getting that done will fix this, and Thread#stop either errors or does nothing in recent JDKs
<enebo> "This would obviously eliminate the output, but it might mean some threads that never wake up from a blocking IO call get stuck and accumulate."
<enebo> but what you are saying is newer jdks are not even supporting a broken stop
<enebo> so if something does acculmulate it will be happening in a newer jdk anyways
<headius> hmm maybe not this particular stop call
<headius> at this point I'd like to get some report in the wild of accumulating threads and figure out a better way to do it
<enebo> headius: I am ok with strategic "maybe" break
<headius> or realize that Windows use is widespread enough that we should finish native IO on Windows
<headius> maybe break
<enebo> headius: since we don't actually know having defensive code which seems to cause a known issue but may not solve an unknown one makes it maybe worth it
<headius> I'm not sure which way you're advocating
<enebo> heh
<enebo> I say we remove stops and see if anything gets reported
<headius> ok
<enebo> we don't know right?
<headius> we don't
<headius> this is a very old hack
<enebo> I think this is a strategic decision to see since we have no visibility into it atm
<headius> newer JDK may be more reliably about waking on interrupt
<lopex> enebo: do you release with javadoc ?
<lopex> I get module-info.java:6: error: module not found: org.jruby.jcodings
<lopex> on release:prepare
<lopex> and it's javadoc plugin
<lopex> headius: is anything being picked up based on jdk version ?
<enebo> lopex: I have not seen that error but I think now that we are 9+ on releases javadocs error instead of warns
<lopex> shall I turn it off ?
<enebo> lopex: or I have noticed now that javadocs must properly parse to not explode javadocs
<enebo> lopex: I would fix the javadoc errors or we will all have to disable them forever
<lopex> enebo: yes, di some tweaking in jcodings for that
<lopex> enebo: but it's a modules issue
<enebo> lopex: but I also think sonatype maybe won't close without javadoc jar
<lopex> Exit code: 1 - /opt/joni/src/module-info.java:6: error: module not found: org.jruby.jcodings
<enebo> lopex: wait so javadocs is scanning that file and exploding...hahaha
<enebo> lopex: this must be a solved problem or no one has javadocs with modules
<lopex> hmm, it modules, not javadoc
<lopex> enebo: what goes after prepare ?
<enebo> release:perform
<enebo> lopex: but did prepare finish?
<lopex> no
<enebo> lopex: then definitely don't perform :)
<headius> I'm not sure why it shows the exception change...github is weird sometimes with multiple branches
<lopex> I gather
<headius> fixed that
<enebo> headius: yeah weird but seems reasonable for the non-exception stuff
<headius> ok
<headius> I'll make sure CI doesn't go wacky
subbu is now known as subbu|lunch
<lopex> ok, now I cant perform
<lopex> Return code is: 401, ReasonPhrase: Unauthorized.
<headius> enebo: I'm releasing jnr-constants 0.9.10
<headius> this includes the fixes for generation and updated bits for linux, windows, macos, freebsd, and solaris
<enebo> headius: nice I was going to ask
<headius> we'll have to get help regenerating the rest but they should be ok as it
<headius> they just won't be as up to date and might be missing some added constants
<enebo> ah that was what I was going to ask...so whatever we fix is better than before
<enebo> with exception of fake which may change something on un-regenerated platforms?
<lopex> enebo: halp ?
<enebo> pulp?
<headius> well, mostly there's no reordering of enums with my changes
<headius> so existing enums should be fine
<headius> enum values
<lopex> enebo: I have setup <id>ossrh</id> with credentials
<lopex> in settings.xml
<lopex> is that enough ?
<enebo> headius: I guess if no fake values are different then it cannot hurt un-regenerated platforms since they will see the new thing
<headius> yeah should be ok
<enebo> I doubt we have ruby looking for constants via const_defined? or something and even if we did that would not affect the Java side of things
<headius> we want to spin something before RC anyway, so hopefully if the unusual platforms have issues, people will see it soon
<enebo> <id>sonatype-nexus-staging</id> and <id>sonatype-nexus-snapshots</id>
<enebo> lopex: I have those two entries
<lopex> in servers ?
<enebo> headius: you have that cvar pr and I looked at the failtures
<enebo> lopex: yeah
<headius> enebo: yeah what do you think
<enebo> headius: the two failures is somehow your fix allows '@@' to be set or at least not throw an error
<headius> link me that PR
<lopex> enebo: it works!
<enebo> lopex: congrats
<headius> woot
<lopex> enebo: their example has ossrh
<headius> note we are using an older version with a parent pom that's deprecated
<lopex> so same credentials for both ?
<headius> I wanted to fix that but doing that and java 9 at the same time was too much hassle
<enebo> headius: I am trying to discern which method must be raising arg error on @@
<enebo> lopex: yeah
<enebo> assert_raise(NameError) { c.class_variable_set(:'@@', 1) }
<enebo> this is seemingly not raising NameError
<lopex> headius: so you say you did not have 'requires org.jruby.jcodings' when preparing joni ?
<enebo> headius: tbh I don't see how this code could cause that though
<lopex> headius: on default profile
<enebo> you call storeClassVariable in old and new
<lopex> enebo: I even went through not enough entropy for gpg2
<lopex> enebo: so many things
<enebo> lopex: yeah sounds like my fun this weekend getting my raspi moved over to a new network so I could install pi-hole which did not work
<enebo> lopex: I think I had to change like 20 things by the end
<lopex> enebo: my rpi began to show undervoltage lately after some updates
<lopex> enebo: even itself reboot segfaulted
<lopex> er, reboot itself
<enebo> Mine has been on with wrong network settings for like a year
<enebo> happily not communicating with the world
<lopex> enebo: and mine sometimes comes with 3 cpus online
<lopex> randomly
<enebo> lopex: time for a new one?
<lopex> yeah, it's 2B+
<enebo> I think mine is just first one
<headius> lopex: I hadn't finished the jdk 9 stuff for joni yet
<lopex> enebo: mine works mostly for vpn and ssh remote forwards and the like
<headius> er wait
<lopex> headius: somethings smelly
<headius> joni
<lopex> you did skip something ?
<headius> what do you mean, joni does say requires org.jruby.jcodings
<headius> on master
<lopex> on prepare
<lopex> I dont know what the earlieer phases are
<lopex> headius: it complains about jcodings and asm
<lopex> so the only modules it depends on
<headius> what JDK are you using?
<lopex> 10
<headius> and mvn clean package fails?
<lopex> headius: so it must be picking up something by default ?
<headius> hmm
<lopex> headius: I would bother you if that would fail
<headius> show me output
<lopex> I wouldnt
<lopex> on sec
<lopex> anything obvious ?
subbu|lunch is now known as subbu
<lopex> headius: it fails too when disabling javadoc errors
<headius> maven-javadoc-plugin:2.7
<headius> that's not from master...need to update to something recent
<headius> it's 3.0.1 on master
<lopex> oh why
<lopex> it's a clean copy
<headius> hmm
<lopex> removing m2 repo
<lopex> er, cache
<lopex> or some other dependeee ?
<headius> hmm
<headius> yeah I'm confused too
<headius> it's 3.0.1 in pom.xml for you right?
<lopex> I'll look at dep tree in a moment
<lopex> yeah, clean copy
<lopex> shall I pin some sonatype plugins or something ?
<headius> I think it's something goofy with jdk version number
<headius> it's not activating the jdk9 profile for you
<headius> or for me on 10.0.1
<headius> so it's using sonatype ossrh defaults for javadoc
<headius> lopex: fixed
<lopex> ooh
<lopex> I see
<lopex> headius: but you did build it with 10 too right ?
<headius> yes it should work with 9+ now
<lopex> headius: but you seem to have built it with 9 only
<headius> ah I think I was messing with this trying to get stuff to activate and lost the range along the wy
<headius> back when I was trying to do multi-release jar
<lopex> the gpg.passphrase in settings.xml also doesnt seem to work for me
<headius> shouldn't affect the release artifacts
<lopex> I found the export GPG_TTY=$(tty)
<headius> ah yeah
<headius> I think I set up gpg-agent as well but the yubikey basically does that now
<headius> I made the same version range fix to jcodings
<lopex> but I admit the whole setup with server naming is confusing
<lopex> headius: you also auth on sonatype via ssh or gpg keys ?
<lopex> er
<lopex> nvm
<lopex> headius: joni released
<lopex> doh
<headius> yay
<headius> no?
<lopex> yes, "doh" was to show my annoyance
<lopex> so now it's somwhere in their stagin structure
<headius> enebo: we punted a lot of 9.2 stuff to 9.2.1 that probably should be 9.3 or something
<headius> lopex: hah
<headius> yeah takes too long to propagate
<enebo> headius: we definitely need to kill this 90 issue backlog against point releases back to what is realistic
<enebo> just making 9.3 and putting 90 issues there will just cause this again
<headius> I know
<enebo> we do I think have some 9000 milestone right?
<headius> I've been closing about 1/3 of what I've looked at because they're old or have no repro or activity
<headius> yeah I wasn't sure if that's where we want stuff or what
<enebo> naw I think we want untargetted but we probably need to get a better system for identifying stuff we can target
<headius> enebo: there's some breakage from jnr-constants update
<headius> I'm looking at it
<headius> seems to be errno issues
<ChrisBr> headius: enebo: if you have time, could you have a look https://github.com/Shopify/bootsnap/pull/200
<ChrisBr> I think there is only sth minior missing ...
<ChrisBr> the previous issue like CGI not loading are all resolved
<enebo> ChrisBr: did you try Rails 5.1.6 (I think was reported version where it broke at first) and make a new app with bootsnap?
<enebo> ChrisBr: I think in 5.2.x they disable bootsnap on jruby by default
<ChrisBr> rails 5.2.1 but I enabled bootsnap manually
<enebo> ChrisBr: ah ok
<enebo> ChrisBr: It is a good stake in the ground. I wonder if they will want to consider how to generify this technique since MRI also must have some wackiness like our internal libs in it
Eiam has joined #jruby
<ChrisBr> but unlike the jruby internal libs, it seems it is not necessary to require them explicit
<enebo> ChrisBr: but they must have some code somewhere to say what they are?
<enebo> or data
<ChrisBr> they just assume everything what is not a path I gues
<ChrisBr> guess
<ChrisBr> but not 100% sure ...
<enebo> oh yeah that is an interesting semantic
<enebo> I wonder if that will always be true
<ChrisBr> it seems like it is good enough so far ...
<enebo> for that matter how are cexts handled if someone does not put the .so in toplevel
<enebo> his comment is interesting since jruby should not need to do that MRI builtin check either
<enebo> I guess though generifying all this would be pretty big change
<ChrisBr> hmm, difference is that it seems mri does return false when loading one of these internal libraries
<enebo> ah yeah
<ChrisBr> in jruby we need to require them explicit
<ChrisBr> right
<ChrisBr> ?
<ChrisBr> here is another interesting comment
<enebo> I find it odd that require of anything is not true first time and false thereafter but it is what it is I guess
<headius> ChrisBr: awesome
<enebo> JRUBY_INTERNAL_LIBRARIES&.key? and just make it nil if not jruby
<enebo> just thinking about smallest delta of your PR
<ChrisBr> ah rafael already commented ...
<headius> enebo: I may have a theory about the jnr-constants failures
<headius> might not have been as binary-compat as I'd hoped and jnr-posix etc are breaking
<headius> enebo: can you try that branch?
<headius> update-jnr-constants=for-1509
<headius> I messed up the name
<headius> but that's the branch...the same tests failiing on travis are passing here so it seems like maybe the linux constants got mucked up?
<enebo> headius: is that pushed to jruby?
<headius> might be on my repo
<headius> yeah sorry it's on my repo
<headius> git@github.com:headius/jruby.git
<enebo> got it
<headius> bbiab
<headius> let me know what you see running e.g. test:jruby
<headius> or spec/ruby/core/io/read_spec.rb should have like 6 failures
<headius> they're all errno related
<enebo> </Stale\ NFS\ file\ handle/> expected to be =~
<enebo> <"Stale file handle">.
<enebo> 2 errors in test:jruby
<enebo> the other was not raising an errorno like EBADF
Puffball has quit [Remote host closed the connection]
Puffball has joined #jruby
sgeorge has quit [Remote host closed the connection]
sgeorge has joined #jruby
sgeorge has quit [Ping timeout: 252 seconds]