<headius[m]>
Hopefully Kristian can help sort out why this artifact is not honoring the updated version. I may be time we move those plugins under JRuby organization and help take over maintenance (which hopefully won't be too much work)
ur5us has quit [Ping timeout: 265 seconds]
annette[m] has quit [*.net *.split]
alfred[m]1 has quit [*.net *.split]
daveg[m] has quit [*.net *.split]
kares[m] has quit [*.net *.split]
alexej[m] has quit [*.net *.split]
ur5us has joined #jruby
alexej[m] has joined #jruby
daveg[m] has joined #jruby
kares[m] has joined #jruby
alfred[m]1 has joined #jruby
ur5us has quit [Ping timeout: 264 seconds]
<headius[m]>
guess I should have done this long ago... rubyspecs and MRI tests are also green on 11
<headius[m]>
how anticlimactic
<headius[m]>
kares, enebo: this is ready, I'll merge "tomorrow" and cherry-pick the one small JI fix to 9.2
<enebo[m]>
Looks like read() is slow in fuse but presumably loading a jar from it will copy it in only a few reads into actual memory
<lopex>
headius[m]: that rabbit hole
<headius[m]>
still not using standard functions though
<lopex>
gets only deeper
<lopex>
hah, dont use autoconf for that
<headius[m]>
no fdlopen on Darwin it seems
<lopex>
but at some point those will stop working anyways
<lopex>
actually this would require security analysis for such functionality
<lopex>
headius[m]: keep digging
<headius[m]>
maybe the best solution is the dumbest one: provide a mechanism for people to install our dll somewhere specific
<headius[m]>
it does seem weird to me that there's no standard way to dlopen from memory though
<lopex>
or separate packages ?
<lopex>
in distros
<headius[m]>
yeah if it's a package this probably isn't an issue already
<headius[m]>
but you're not using bar jar files in that case most likely
<headius[m]>
bare jar
<lopex>
well, sh | curl wont do it
<lopex>
pick your poison
<headius[m]>
I was going to wonder about platforms with no filesystem but I suppose even there they have at least a ram fs
<headius[m]>
we should all just switch to hurd
<lopex>
hurd is still a thing ?
<headius[m]>
latest release december 2016
<enebo[m]>
I hurd it is making a comeback
<lopex>
afaik is was a debian initiative to make is less monolithic
<headius[m]>
so it's more current than Rubinius
<headius[m]>
BURN
<headius[m]>
actually I am pretty sure rbx has newer releases also
<lopex>
headius[m]: bleh today we had to use IBM_JAVA_OPTIONS
<lopex>
does that remimnd you of something ?
<headius[m]>
you're using J9?
<lopex>
yeah
<lopex>
on system I
<headius[m]>
oh hah well I suppose so
<headius[m]>
yeah I know of it
<lopex>
the jvm terminated with OOM
<headius[m]>
we use OPENJ9_JAVA_OPTIONS in jruby.bash
<lopex>
but then began to spit tons of heap dumps
<headius[m]>
that is the new name under OpenJ9
<lopex>
something unsusuall
<headius[m]>
yeah that sounds strange
<headius[m]>
definitely doesn't happen just using OPENJ9_JAVA_OPTIONS as we do it
<lopex>
should OOM spit any dumps ?
<headius[m]>
only if that flag is on
<headius[m]>
HeapDumpOnOOM or whatever
<lopex>
hmm, well, the it depends on that system defaults
<lopex>
yeah, I recall
<headius[m]>
yeah try -XX:+PrintFlagsFinal and see
<headius[m]>
maybe they support that one
<headius[m]>
oh but J9 doesn't honor -XX flags at all
<headius[m]>
they must have something equivalent?
<lopex>
it's on prod so the chaces are vague
<lopex>
*chances
<lopex>
headius[m]: the problem is that we run lots of I systems
<lopex>
headius[m]: and there are plethora of version installed
<headius[m]>
and I suppose openj9 doesn't have supported packages there
<lopex>
hmm, it's system I so it depends what PTFs it has
<lopex>
good lord the industry didnt go with app server and db at once on those machines
<lopex>
headius[m]: mostly is batch'es running on then
<lopex>
but any web thing is on separate linux machines
<lopex>
though I know you can run linux on system I
<lopex>
but price wise it;s not that affordable
<lopex>
better to dedicate the hardware to db
<lopex>
headius[m]: btw, we're about to test nation wide tests for ssl on db2 soon
<lopex>
at least jt400 is a thing one can rely on
<headius[m]>
yeah that sounds like an interesting world to work in 😀
<lopex>
bleh
<lopex>
headius[m]: those systems are so inconsitent, since they're all pre unix
<lopex>
files, objects, spools
<lopex>
bleh
<lopex>
ah, and all those queues
<headius[m]>
I assume these are legacy systems?
<headius[m]>
well perhaps that's silly, is anyone doing new deployments of System I?
<lopex>
lots of them
<lopex>
the less relevant the most regacy
<headius[m]>
using power systems?
<lopex>
I dont know what that is
nirvdrum has quit [Ping timeout: 246 seconds]
<headius[m]>
I'm just reading wikipedia on system i
<headius[m]>
In April 2008, it was replaced by a modern standards-based (PCI, FiberChannel, RAID, etc) rack-friendly server line, IBM Power Systems.
<lopex>
headius[m]: I'm not an admin I just happen to use them
<headius[m]>
if it's new deployments I assume it's one of those
<lopex>
yeah, I hear about those on our dailys
<headius[m]>
neat
<lopex>
headius[m]: the problem is that we have lots of versions our there
<lopex>
and it's becoming hard to support out software
<lopex>
er, OUR
<lopex>
bleh
<headius[m]>
so this depends on some software that only runs on system i and can't be replaced?
<lopex>
well, it must be bought
<lopex>
every part of it
<headius[m]>
so it's just a system built to run on a system with these specifications and you'd have to fill in those blanks yourself
<headius[m]>
a piece of software build...
<headius[m]>
yeah joy of legacy
nirvdrum has joined #jruby
<lopex>
headius[m]: even though system I is perceived as a db system you have to buy sql query capabilities separately
<lopex>
and nobody has any problem with that
<headius[m]>
It sounds so 80s
<lopex>
here we are
<lopex>
and having system I reliability most are ok with it
<headius[m]>
Yeah, they definitely are designed for a different sort of app
<headius[m]>
When I did a mainframe to Java ee conversion in the early 2000s the old mainframe greybeards kept talking about how many memory and io channels the systems had
<lopex>
yeah I remember mainframe javas
<headius[m]>
Basically like custom hardware for pipelining and transforming data
<lopex>
=6;omvs !
<lopex>
I wonder what java it was back then
<headius[m]>
I think that was an mvs system, yeah
<headius[m]>
I learned how to read COBOL
<lopex>
headius[m]: I used native libs on mqseries on mainframe
<headius[m]>
The sad thing was how all those greybeards were essentially losing their jobs because they never moved beyond COBOL
<headius[m]>
My job was to make all of them obsolete 👍
<lopex>
and COBOL
<lopex>
that 4gl was called AGE
<headius[m]>
This was the system that powered food stamps for the United States department of agriculture
<lopex>
headius[m]: since you're IBM can you dig anythin about AGE ?
<headius[m]>
I can't even get free cloud instances
<lopex>
bumer
<lopex>
:P
<headius[m]>
From my perspective it feels more like red hat bought IBM
<lopex>
from what I know ADELIA and AGE were products what aimed at 4gl solution to mainframe and as400 (back then)
<lopex>
and on mainframe before then was CICS
<lopex>
Customer Information Control System
<lopex>
CICS was the kinf on mainframes for al that time
<lopex>
*king
<lopex>
CICS and DB2
<lopex>
and what is was is transaction manager with direct communicatiomn with clietn programs
<lopex>
via COMMAREA
<headius[m]>
Oh you know what, I think it was cics, that sounds familiar
<headius[m]>
By the time I got to the project they'd already decomposed the app into a series of gigantic requirements documents
<headius[m]>
I only had to learn enough COBOL to fill in a few missing pieces
<lopex>
hey COMMAREA was everything back then
<lopex>
it was a layer above COBOL
<headius[m]>
The project was fubar before I took over as architect
<lopex>
in some sense
<lopex>
because it was all binary anyways
<lopex>
ah
<lopex>
headius[m]: I remember at our company, very special emploees wer alowed to access cics cli