joast has quit [Ping timeout: 245 seconds]
kiwi_35 has joined #jruby
kiwi_35 has left #jruby [#jruby]
lopex has quit [Quit: Connection closed for inactivity]
lucasb has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #jruby
_whitelogger has joined #jruby
sagax has quit [Remote host closed the connection]
<byteit101> headius[m]: After hours of updating windows, I managed to confirm master (w/ no local changes) on win10. Test pasted in https://github.com/jruby/jruby/issues/5829
<byteit101> If you want, I can clean that test up, but I'm too tired right now, and can do it tomorrow
shellac has joined #jruby
shellac has quit [Quit: Computer has gone to sleep.]
armd has joined #jruby
armd has quit [Ping timeout: 260 seconds]
shellac has joined #jruby
lopex has joined #jruby
whitingjr has joined #jruby
kiwi_78 has joined #jruby
kiwi_78 has quit [Remote host closed the connection]
whitingjr has quit [Quit: Leaving.]
drbobbeaty has joined #jruby
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
rusk has joined #jruby
whitingjr has joined #jruby
drbobbeaty has joined #jruby
whitingjr has quit [Ping timeout: 244 seconds]
whitingjr has joined #jruby
whitingjr has quit [Ping timeout: 246 seconds]
<kares[m]> if GH's actions provides Win machines ... we finally might be able to get some CI testing
<kares[m]> there might be failures for the existing suites but at least few should get a spin ...
sagax has joined #jruby
lucasb has joined #jruby
shellac has quit [Ping timeout: 250 seconds]
whitingjr has joined #jruby
joast has joined #jruby
whitingjr has quit [Ping timeout: 268 seconds]
whitingjr has joined #jruby
xardion has quit [Remote host closed the connection]
xardion has joined #jruby
whitingjr has quit [Quit: Leaving.]
rusk has quit [Remote host closed the connection]
<headius[m]> I think we can do windows stuff on azure pipelines...and we have an appveyor account but neither enebo nor I can remember where it is
<headius[m]> byteit101: that's excellent, thank you
enebo has quit [Ping timeout: 245 seconds]
<enebo[m]> It may be worth setting actions to see how well it works
<enebo[m]> I am curious at least since travis has slowly been submerging
<enebo[m]> I lay money it is just azure with a different UI
<headius[m]> Yeah we need to start diversifying
<headius[m]> tossed mac and windows in there quick, no idea if -Ptest passes on Windows though
whitingjr has joined #jruby
<headius[m]> looks like there's a couple failures so far
<headius[m]> testGetHomeDirectory(org.jruby.embed.ScriptingContainerTest) Time elapsed: 1.439 sec <<< FAILURE!
<headius[m]> org.junit.ComparisonFailure: expected:<D:[\a\1\s\core/..]> but was:<D:[/a/1/s]>
<enebo[m]> kares: did you notice uniq being used in something. I am gung ho on making stuff like this faster but I am wondering if you are figuring this out from reading code or running code
<headius[m]> bad test most likely
<headius[m]> mac looks good
<headius[m]> only three failures on Windows
<enebo[m]> Two of those is testing for newline
<enebo[m]> or I should say is not expecting I guess \r\n
<headius[m]> looks like it yeah
<headius[m]> may all be bad tests
<headius[m]> hack day on Windows might get us a good suite to run
<enebo[m]> JRuby 1.7.x did run spec:fast fully but I don't think -Ptest was in it
<headius[m]> -Ptest is pretty baseline
<enebo[m]> native support for IO definitely killed some of that but there are a lot more specs now too
<enebo[m]> I just know I had green runs on appveyor and spent time to get spec running green
<enebo[m]> we probably have existings tags from what with win or windows in the tag
<headius[m]> yeah there's some in there
<headius[m]> a first past just tagging off everything that hangs or fails would be great
<enebo[m]> messing on windows box now :) will be having quiet time
<headius[m]> have fun
travis-ci has joined #jruby
<travis-ci> jruby/jruby (test_windows:35a2072 by Charles Oliver Nutter): The build passed. https://travis-ci.org/jruby/jruby/builds/571462219 [198 min 35 sec]
travis-ci has left #jruby [#jruby]
<headius[m]> I'm going to get back to some light refactorign of Java method binding
travis-ci has joined #jruby
<travis-ci> jruby/jruby (test_windows:35a2072 by Charles Oliver Nutter): The build passed. https://travis-ci.org/jruby/jruby/builds/571462219 [214 min 56 sec]
travis-ci has left #jruby [#jruby]
<kares[m]> enebo: was doing some enumerator stuff - mostly compat (PR soonish).
<kares[m]> than noticed unique is slower -> but also Array#unique so I looked into both
<headius[m]> ugh
<headius[m]> removing all lambdas from my experiment now
<headius[m]> under char[] and byte[] the next blasted thing was Unsafe.defineAnonymousClass from lambda forms
<headius[m]> sampled profile
<headius[m]> they have to fix that
<headius[m]> "they"
<headius[m]> hey one thing I noticed in a sampled startup profile was jnr-ffi setting up bytecoded stubs
<headius[m]> someone want to give me some independent numbers for startup with -Djnr.ffi.asm.enabled=false ?
<headius[m]> I've been testing JI startup with --disable-gems
<headius[m]> latest changes seem to be helping finally
<headius[m]> working my way back from those ClassValues that cache reflection stuff
<headius[m]> kares: do you have any good cases that load a ton of Java classes?
<headius[m]> I suppose a simple one would be to just loaded up anything Swing related
<headius[m]> lots of crap in there
<headius[m]> go J9!
<headius[m]> pretty solid even loading RG
<kares[m]> hmm lots of classes ... not sure maybe try adding some scala.jar and using a class from there
<headius[m]> heh that's certainly a big chunk too
<kares[m]> JI is lazy these days ... so you need to actually somehow force classes to go through JRuby
<kares[m]> otherwise you're just testing Java class loading :)
<headius[m]> $ time jruby --disable-gems --dev -e 'java_import javax.swing.JFrame'
<headius[m]> real0m2.907s
<headius[m]> 😬
<headius[m]> seems like a good test
<kares[m]> heh I guess so - since it should load a few 10s of classes from the method signatures
<headius[m]> yeah
<kares[m]> oh wait, swing also loads AWT ... so yeah maybe even few 100s
<headius[m]> how deep do we dig?
<headius[m]> I don't think we set up binding for classes in signatures until you actually have one of them in hand
<headius[m]> but it would cover all supertypes
<headius[m]> superclasses and interfaces
<headius[m]> and any inner classes in any of those
<kares[m]> oh right, might be so
<headius[m]> heh getDeclaredMethods shows up in this profile
<headius[m]> but I'm caching that as best I can already
<headius[m]> ah, much of this profile is loading the AST peer library
<headius[m]> native library load
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
whitingjr has quit [Quit: Leaving.]
<headius[m]> here's another idea for --dev: -verify:none
<headius[m]> on Java 8 we already load JRuby into boot classloader, but we can't do that on 9 so we pay verification there
<headius[m]> this would also drop verification for generated code on 8
<headius[m]> (which should only be for RubyObject## specialized classes typically)
<headius[m]> yeah that has a big impact on Java 9+ startup
<headius[m]> I'll add to PR
<headius[m]> nice
<headius[m]> 🕺
<lopex> kares[m]: good number on uniq
<lopex> *numbers
<lopex> and 9.2.8 indeed failed for me on window on budler
<lopex> *bundler
<headius[m]> wha
<headius[m]> what failed
<lopex> let me repro
<headius[m]> enebo verifies on Windows every release
<lopex> can't find gem bundler (>= 0.a) with executable bundle
<headius[m]> did you install bundler?
<lopex> Successfully installed bundler-2.0.2
<lopex> let me delete gemfile lock
<headius[m]> hmm
<headius[m]> bundler 2 does have some quirks but I thought it was working ok
<lopex> ok after deleting lock
<lopex> Unable to load application: LoadError: load error: jbundler -- java.lang.IllegalArgumentException: Bad artifact coordinates ---, expected format is <groupId>:<artifactId>[:<extension>[:<classifier>]]:<version>
<lopex> so jbundler fails now
<lopex> and did not before
<headius[m]> jbundler
<headius[m]> I don't have a jbundler
<headius[m]> oh is that the mkristian thing
<headius[m]> maybe that needs updates to be compatible with bundler 2
<headius[m]> that's not a JRuby load error
<enebo[m]> I ran rails with bundler for release
<lopex> my Jarfile: jar 'com.github.jsqlparser:jsqlparser', '1.4'
<lopex> and that's all
<headius[m]> lopex: I'd call it a bug in jbundler
<headius[m]> try with bundler <2
<lopex> headius[m]: api changes since 2.7 ?
<lopex> ok
<enebo[m]> 2.7?
<lopex> jruby
<lopex> x.2.7
<enebo[m]> ah
<headius[m]> nothing that should affect jbundler
<headius[m]> it just uses maven stuff to fetch deps
<lopex> how do I downgrade bundler in gemfile ?
<headius[m]> but it plugs into bundler somehow
<headius[m]> in gemfile, I don't know
<headius[m]> I'm not sure you can
<lopex> I can do it vie gems yeah
<headius[m]> but gem install bundler -v '<2'
<lopex> so, latest 1.x ?
<lopex> ok
<headius[m]> of course it should work with bundler 2+ but this is to confirm it's an incompatibility at that level
<headius[m]> enebo: how's it going
<enebo[m]> ruby spec I gave up on but I think it may partially be my env
<headius[m]> did it run?
<enebo[m]> test:mri runs but for 3 things
<headius[m]> like at all
<headius[m]> nice!
<enebo[m]> 3 things which is thousands of tests
<headius[m]> did you look at -Ptest?
<enebo[m]> seemingly wait and waitpid for nearly all problems
<headius[m]> subprocess stuff
<headius[m]> subprocess tests
<enebo[m]> another is with exec'ing jruby and the quoting is an issue
<headius[m]> hah
<enebo[m]> Both of these were known to some degree
<enebo[m]> wait was for sure
<headius[m]> yeah I feel PTSD every time I look at that jruby-launcher 32/64-bit issue
<enebo[m]> quoting has been a perennial
<enebo[m]> spec is failing exec'ing java from ant in rake
<headius[m]> not surprising
<lopex> headius[m]: yeah it works now
<headius[m]> lopex: ok need to file an issue on jbundler
<enebo[m]> so something to figure out but it could very easily be env issue. I tried a few things and them bleh
<lopex> also there is a problem with mri puma 4.1.0 too
<headius[m]> ok nevermind
<lopex> stdout gets lost
<headius[m]> there's an issue already
<lopex> on mri
<headius[m]> fix it :-D
<headius[m]> huh that's interesting
<enebo[m]> lopex: please refer to new bugs vs regressions
<headius[m]> enebo: -Ptest?
<enebo[m]> headius: I did not run it but those 3 should be easy
<enebo[m]> headius: I can correct them in the morning I guess and then we will have something green at least
<headius[m]> yeah that's all I wanted
<headius[m]> then we can add suites to azure as we get them green on Windows
<enebo[m]> I don't really want to exclude on the mri tests for wait/waitpid (besides having to add 3+k excludes :)
<headius[m]> smaller stuff like JI might pass now
<enebo[m]> yeah that's true and I was just looking at the big stuff
<enebo[m]> MRI looks really good overall once the wait stuff is in
<headius[m]> as we move stuff into azure we could remove from travis too
<enebo[m]> MRI obviously tests against it
<headius[m]> yeah cool
<headius[m]> unfortunately wait/waitpid is the little end of that work
<headius[m]> popen is the big end
<lopex> might be related to https://github.com/puma/puma/pull/1837
<lopex> but I only use sintatra anyways
<headius[m]> I can't even get a pid at this point on Windows
<headius[m]> no posix_spawn on Windows
<headius[m]> hmm
<headius[m]> they have spawn though
<enebo[m]> don't take waitpid and the specific problem here
<enebo[m]> most fail on waitall but the whole family I think is the same code and supported
<headius[m]> waitall can be supported
<headius[m]> since we don't have to give it a pid
<headius[m]> waitpid could maybe be supported if we can dig out something like a pid
<headius[m]> but it's going to be another handle shuffle
<enebo[m]> jps is actually the pid right?
<headius[m]> yeah
<enebo[m]> I guess for arbitrary processes maybe there is nothing
<headius[m]> I assume it's like file descriptors and lazily allocated if you need it
<headius[m]> otherwise you deal with HANDLE
<enebo[m]> I looked at this like 2-3 years ago but I admit it is a bit fuzzy :)
<enebo[m]> It will not be fun that I do remember
<lopex> doh, the whole thing is like running WINE in wsl
<lopex> which works indeed
<headius[m]> spawn is insufficient also because it doesn't do any of the mid-fork stuff posix_spawn does
<headius[m]> mess around with file descriptors and such in the parent and risk racing other spawns
<lopex> headius[m]: so is jbundler maintained still ?
<headius[m]> 🤷‍♂️
<headius[m]> it's yours now
<headius[m]> welcome to the jbundler team
<enebo[m]> lopex: you have any reason to think it isn't?
<lopex> no
<lopex> I just depend on it for a small irrelevant fraction of an app
<lopex> but I'll fixit it needed
<headius[m]> it's probably not a big thing
<lopex> just to validate sql's from user
<headius[m]> famouse last words
<lopex> hah
<lopex> but gentlemen I will tell you, jira is a dirty business now
<lopex> gazzillion plugins
<lopex> with 400% redundancy
<lopex> it's a mess
<lopex> and the gust havent changes since a decade
<lopex> *guts
<enebo[m]> dinner
<lopex> enebo[m]: I'll take is a me being boring
<headius[m]> do you have JIRA on your CV?
<lopex> I should, since 2008
<headius[m]> yeah
<lopex> headius[m]: custom plugins, years of administration
<headius[m]> so in a decade you can get recruiters contacting you
<lopex> but it was only a fraction of my job
<lopex> I did it for 4 years or so
<lopex> and now it;s coming back :P
<lopex> there's now lots of new plugins that do everything
<lopex> but the core is stale
<lopex> and they will never change it
<lopex> too risky
<lopex> so for out new project we chose to have our own app
<lopex> that deals with multiple jiras via ruby jira-api
<lopex> headius[m]: you cant even name a script and then save it if you want to reuse it in a transition
<lopex> or whatever
<lopex> it can be a file, but it needs to be visible from jira
<lopex> but
<headius[m]> so your app integrates JIRA
<headius[m]> do you still use JIRA directly too?
<lopex> you can test groovy scripts in jira
<lopex> yeah, two now, ours, and one of the clients
<lopex> headius[m]: and those plugins came to be quite an advanced ones
<lopex> like
<lopex> you have a groovy editor in jira admin interface
<lopex> and you can even check for static analysis
<lopex> so it seems groovy has some support for that
<headius[m]> yeah if you specify the script (or class?) is all static
<lopex> headius[m]: well, you can even click reflected objects returned via script
<lopex> headius[m]: no it's just a script in textsarea
<lopex> I gather the analysis is limited
<lopex> but it works for quite a few cases
<lopex> and scriptrunner is only one of those plugins
<lopex> so the market is HUGE
<lopex> lots of money there
<headius[m]> ah yeah they might be able to do a bit more than Ruby because their class structures are also static
<lopex> when I scroll addong on out jira instance
<headius[m]> so if it can detect what object you're accessing it knows the fields at least can't change
<lopex> there's lots of plugins like 3000$ and more
<headius[m]> crazy
<lopex> yeah
<lopex> and absolutely no reason for that
<lopex> like
<lopex> jira excel export
<lopex> let me google that
<lopex> ah, so from a jira instance it can gather how many users there are etc
<lopex> so for that plugin it shows that 3k number
<lopex> and is probablt a POI wrapper :P
<lopex> *probably
<headius[m]> I'm in the wrong business
<lopex> ppl know how to do business :P
<lopex> yeah
<lopex> exactly
<headius[m]> why am I mucking about with compilers when I could make bank wrapping some OSS library for business users
<lopex> and there's gazzilion of those plugins
<lopex> which all do good I think
<headius[m]> I guess this can just be a fallback career
<headius[m]> I'll retire from JRuby to write plugins for business software that just wrap other people's libraries
<lopex> headius[m]: BUT you cant easly do onchange hide form element in jira :P
<lopex> madness
<lopex> headius[m]: we have so many plugins so we have to search for "script" in like postfunction transitiokn in jira
<lopex> but hey, jira is like 1% of my time, so I dont get offfended
<lopex> er, let me clarify the one before
<lopex> jira has three major built-in things
<lopex> conditions (wheather the step will show up)
<lopex> validation (sure thing)
<lopex> post functions (being called after transition)
<lopex> which can fail too
<lopex> and for everyone you can define "functionality"
<lopex> that functionality grows as install more plugins
<lopex> and it;s all global
<lopex> so
<headius[m]> yeah sounds like an O(N^M) situation
<lopex> when you decide you need some "transition" postfunction
<headius[m]> huh, NtCreateProcess on Windows can be given a starting address space, behaving like fork
<lopex> you get a menu you can only use search on
<headius[m]> nonstandard API though
<lopex> headius[m]: have you seen that oracle comment on hackernews ?
<headius[m]> no
<lopex> same thing as jira
<lopex> it's all madness
<headius[m]> sounds like a nightmare but I'm not surprised
<headius[m]> closed source is many times worse quality than open source in my experiences
<lopex> yeah
lucasb has quit [Quit: Connection closed for inactivity]
<lopex> but business doesnt care
<lopex> and actually I dont blame them
<headius[m]> ugh
<headius[m]> MRI makes changes in parent process before CreateProcess just like it does for fork/exec
<headius[m]> or rather just like it does for any place that doesn't have fork
<lopex> does windows fork varies exceptionally from posix one nowadays ?
<lopex> wrt threads there is parity afaik ?
<lopex> headius[m]: just distribute jruby via wsl2 :P
<headius[m]> I think we can do some of this via STARTUPINFO struct but ugh structs
<headius[m]> there's no official fork on Windows
<headius[m]> the typical dance for process launching is fork, make changes to cwd, file descriptors, process flags, and then exec
<lopex> ah
<lopex> so dirty dancing
<headius[m]> posix_spawn combines that all into one call but doesn't have a complete set of operations (e.g. it doesn't support cwd change)
<headius[m]> spawn* doesn't support any of them
<headius[m]> CreateProcess looks somewhere around posix_spawn capabilities
<headius[m]> which I guess is as good as we can expect
<lopex> madness
<headius[m]> I wish someone had written a posix_spawn wrapper around CreateProcess
<lopex> well, wsl2 should be opensource
<lopex> so do what they do ?
<lopex> ah, sorry they ran linux kernel
<lopex> *run
<lopex> but wsl1 might be clue ?
<headius[m]> yeah they cheat
<headius[m]> I'd love to be able to say JRuby on Windows needs WSL
<headius[m]> but we do have some people deploying JRuby stuff on Windows, and nobody would do that on top of WSL
<headius[m]> emulating
<headius[m]> how
<headius[m]> ahah
<headius[m]> it does use NtCreateProcess
<headius[m]> that's interesting
<headius[m]> I assume NtCreateProcess would mess up the JVM just as much as fork, but it's interesting
<lopex> you mean the "Improved fork support" ?
<headius[m]> if we could do it all inside a safepoint we could fork
<lopex> "We have improved the fork implementation to meet some new requirements as part of the WSL work"
<headius[m]> yeah interesting
<headius[m]> JVM does use fork+exec on platforms that support it
<headius[m]> but all in native code
<headius[m]> pretty minimal set of file descriptor options
<headius[m]> but thank goodness we can set the X and Y coordinate of a aubprocess
<headius[m]> sub
<headius[m]> weird set of options there too
<lopex> still smellls an owl
<lopex> well, I heard there;s feature parity on threads with posix
<lopex> headius[m]: how more wrong could the world go
<lopex> headius[m]: are those structures available from jffi easily ?
<lopex> I mean
<lopex> if you can generate something from their docs
<headius[m]> well thankfully windows is consistent sizes for DWORD etc
<headius[m]> so we can map them in safely
<lopex> also pico loses it's meaning in wsl2 ?
<lopex> I'm confused
<lopex> but nt process maps on pthread generally right ?
<lopex> er
<lopex> unix process
<lopex> ah
<lopex> so there's thread parity on posix and "nt" threads
<lopex> but not on process ?
<lopex> ok I realized I know knothing about this
<headius[m]> Yeah it is quite different