<rtyler>
Sending Logstash logs to /home/pi/logstash-7.1.1/logs which is now configured via log4j2.properties
<rtyler>
doesn't look like it's crashing
* rtyler
shrugs
<rtyler>
what do now
byteit101 has joined #jruby
byteit101 has quit [Client Quit]
byteit101 has joined #jruby
<byteit101>
jnr-enxio clearly has some definitions for Windows, as `Platform.getNativePlatform().getStandardCLibraryName()` returns `msvcrt`, but doesn't appear to bind to anything sucessfully. What is the status of, and goal for, windows support in jnr-enxio?
<headius[m]>
Take some care not to remove any signatures, so any code compiled against them still sees them there
<headius[m]>
kares ^
<kares[m]>
yy that is clear to me only to super-class change I wasn't 100%
notori0us has quit [Quit: WeeChat 2.1]
shellac has quit [Ping timeout: 252 seconds]
_whitelogger has joined #jruby
<headius[m]>
I was just thinking along the lines of that java.nio.Buffer change we've struggled with...don't want to self-inflict 😄
<headius[m]>
ok
<headius[m]>
enebo: interesting find on that ipv4 thing
<headius[m]>
the looping seems fine for something like TCPSocket since it's doing the connect all at once
<headius[m]>
strange...azure pipelines failing to even start maven recently
<rtyler>
headius[m]: did you happen to see my comments on that arm ffi issue from this morning?
<headius[m]>
Ah nope, I'll have a loop
<headius[m]>
look
<headius[m]>
popping a few items off my queue
<rtyler>
heh, sounds good
<rtyler>
in my home lab here I've got a couple FreeBSD machines, and these little raspberry pis floating aruond, so happy to open up shells should you want/need them
<headius[m]>
Yeah waiting to see if logstash folks need some assistance
<headius[m]>
JRuby itself seems ok so something about their repackaging must be causing an issue
<headius[m]>
I should try to set this beaglebone up as a CI endpoint or something
<rtyler>
I've tried to run Jenkins agents on these little pis before, it did not go well :P
<headius[m]>
yeah that was my first thought
<headius[m]>
this doesn't have a ton of memory either
<rtyler>
I really wish I had time to work on my sideproject, it would be suitable for running CI workloads on all sorts of wacky devices like these, oh well
<headius[m]>
maybe I don't like this keyboard that much
<rtyler>
butterflies biting you?
<headius[m]>
tiny fragile butterflies
<headius[m]>
ok, time to finish up this branch
<headius[m]>
rtyler: you commented on the logstash issue?
<rtyler>
I did not
<rtyler>
I just splatted stuff into this channel
<headius[m]>
oh ok
<headius[m]>
byteit101: I'd love to support Windows but I'm out of touch with the proper way to do this sort of API. The usual posix APIs generally work right, but I feel like this probably needs to use win32 WaitForSingleObject or something
<headius[m]>
enxio is a prerequisite to getting JRuby's fully native IO and process stuff working so that's definitely on a critical path
<headius[m]>
rtyler: got it
<headius[m]>
did it crash like the bug reports?
<rtyler>
yes
<rtyler>
took a long ass time to do it
<rtyler>
but it did
<headius[m]>
well that's promising
<headius[m]>
I can think of a few avenues to investigate
<headius[m]>
hmm
<headius[m]>
some simple things possibly to narrow down
<_byteit101>
headius[m]: I also am not in touch with Windows, but while impling a feature in a serial library, had to change the API for windows too. I have a hack of a patch for *partial* Windows read/write support for fd's above 2, but not for polling or nonblocking io. Would you like me to submit a PR for the partial patch using the posix-y apis, or would yo
<_byteit101>
u prefer to have a full win32 impl using win32 api's so that async io would work?
subbu|lunch is now known as subbu
<headius[m]>
_byteit101: something's certainly better than nothing!
<headius[m]>
if it's possible to do async IO without win32 APIs, I'd be find with that...even if it's not the best pattern
<headius[m]>
getting the basic reads and writes and such working would be a good start though
<_byteit101>
Ok, It's implemented as a second LibC interface for windows, that is proxied via a concrete impl of the original libC
<headius[m]>
why fd's above 2 only? Windows TTY weirdness with stdio or something?
<_byteit101>
headius[m]: I'll send a PR this evening then. Don't have access windows at the moment. First time I've used windows in ages :-D
<_byteit101>
didn't test with the current std* overrides
<_byteit101>
should work with 0/1/2 though
<headius[m]>
why is there no good copy-on-write string abstraction in the JDK
<headius[m]>
ever since they stopped doing COW inside String I'm always struggling to find an efficient way to chunk off char[]
<headius[m]>
CharBuffer is out there but it only implements CharSequence and not most of the other String methods
<headius[m]>
and doesn't .equals with String because it only accepts other CharBuffer
<headius[m]>
harumph
<headius[m]>
_byteit101: oh I see
<headius[m]>
ok
<headius[m]>
enebo: there was a minor regression in test:mri:stdlib due to my Socket error changes...I patched that on master but we need to figure out how to get this suite out of allowed failures
<headius[m]>
my best theory at this point is that when running on travis some thread is spinning up in the test run that's not a daemon
<headius[m]>
regardless of what tests run, the suite hangs just before completion
<headius[m]>
I opened an issue about it when I moved it to allowed failures
_byteit101 has left #jruby [#jruby]
<headius[m]>
enebo: around today?
thegeekinside_ has joined #jruby
thegeekinside has quit [Ping timeout: 252 seconds]
<lopex>
java 7 update 5
<lopex>
the update they stopped doing COW
<lopex>
astonishing that is was during a minor update
<lopex>
headius[m]: do we still use that Clicks hashtable ?
<lopex>
er, not, COW just sharing it was
<headius[m]>
lopex: we do, at least for caching signature mappings in overloaded Ruby to Java calls
<headius[m]>
probably a few other places as well
<lopex>
so we can access some package level thingies in jdk still ?
<lopex>
headius[m]: oh, but we dont override jdk hashtables now ?
<lopex>
er, I mean, replace
<headius[m]>
what do you mean?
<headius[m]>
we use some standard JDK hashtables of course
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<lopex>
ah, I thought we replaced them at some point since we're on bootclasspath ?
<lopex>
ah, we're appended
<lopex>
but we can prepend on most envs right ?
<lopex>
or have I messed that up ?
<headius[m]>
oh no, we don't replace anything from JDK
<headius[m]>
never have
<headius[m]>
at build time we have used some stubs to allow building on lower JDKs with higher JDK method signatures, but that doesn't ship in the jar
<headius[m]>
mock Unsafe, etc
<lopex>
but I recall there was some problem on android wrt that hash
<lopex>
so that hash must be doing something that is allowed on jre
<headius[m]>
oh right, there's likely unsafe stuff in there
<lopex>
headius[m]: being an ext is lower than being on boot cp ?
<headius[m]>
those could be replaced with better options if available...we're still running a many-year-old copy of the one collection we're using
<lopex>
or the other way round ?
<lopex>
so, then, maybe unsafe will do for that zero copy still ?
<headius[m]>
ext and boot CP are roughly the same I think
<headius[m]>
but modules mean anything boot CP related is a dead end now
<headius[m]>
exts may still be valid in jpms, not sure
<lopex>
there was some gc locking for unsafe though
<headius[m]>
oh yeah?
<lopex>
I recall there was some cost for unsafe wrt gc etc
<headius[m]>
I don't recall but perhaps so, at least for the direct memory access ones
<headius[m]>
which presumably this collection is using to do CAS
<headius[m]>
CAS being an explicitly bounded transaction might make it more GC friendly perhaps
<lopex>
will field handles have some kind of memory model for array elements ?
<lopex>
or that;s another topic ?
<headius[m]>
they do
<headius[m]>
have you looked at VarHandle at all? It provides an extensive set of operations against both fields and arrays
<headius[m]>
if we could go Java 9+ I have dozens of places we could use those
<lopex>
I looked at those years ago from some conversation from here
<lopex>
also played with some indy and read lots of articles
<lopex>
but never had a chance to use it in a project
<lopex>
so well
<lopex>
well, I like waste time :P
<headius[m]>
hmm looks like I've got the loaded features logic down to minimal allocation now
<headius[m]>
branch is still a bit slower than master though
<lopex>
that loading seem to be pita
<headius[m]>
that's for sure
<headius[m]>
there may be a better data structure I could use here but it's extremely sensitive to allocation
<headius[m]>
I've trimmed rake -T down from 5s to 4s almost exclusively by reducing transient allocations
<headius[m]>
it's slightly under 4s on master, may be noise
<lopex>
is that an mri or rubygem thing ?
<headius[m]>
is what?
<lopex>
loaded features
<headius[m]>
MRI thing
<lopex>
so exts etc too
<headius[m]>
the logic I'm trying to optimize now is a loose port of their loaded features index, which caches all loaded libraries by splitting up their path segments
<headius[m]>
it's a big mapping from of every permutation of trailing feature path to the actual file that was loaded
<lopex>
so loading an .so is too ?
<headius[m]>
yeah it handles .rb vs extensions
<lopex>
shit
<headius[m]>
it caches the path with and without extension, and each level of trailing path
<lopex>
lol
<lopex>
for require or something more ?
<headius[m]>
so for foo/bar/baz.rb it willl cache baz.rb, baz, bar/baz.rb, bar/baz
<headius[m]>
all pointing back to foo/bar/baz.rb
<lopex>
and load
<lopex>
ah, and autoload
<headius[m]>
does that trigger any memory of a better data structure? some sort of tree maybe?
<headius[m]>
autoload also uses this cache
<lopex>
tree with interlinks
<lopex>
:P
<lopex>
like skip up links
<headius[m]>
sounds good, ship it
<lopex>
though it would require invalidation too
<lopex>
yeah, almost done
<headius[m]>
it's pretty likely this is caching more than needed, but I believe it does it this way on the off chance you have someone require foo/bar/baz.rb and in foo/bar/quux.rb there's a require_relative 'baz'
<headius[m]>
so then you look in the index and see that foo/bar/baz.rb was already loaded, and that matches a load path location
<headius[m]>
ideally avoiding file searches for relative files
<lopex>
yeah
<lopex>
but also sounds like it should be a common thing
<lopex>
hold my beer
<headius[m]>
there's more and more require_relative, so we'll need to make sure it's efficient
<headius[m]>
right now on Java 8 it's still generating a Java stack trace, so that's not great
<headius[m]>
Java 9 it uses StackWalker
<headius[m]>
damn, still slower
<headius[m]>
may not be loaded features at this point though
<headius[m]>
guess I'll take a step back and see if I can figure out this sequel failure
<headius[m]>
at least it will be green then
<rtyler>
wooo
<lopex>
why the stacktrace ?
<headius[m]>
because require_relative doesn't typically have access to the caller's FILE
<headius[m]>
er, `__FILE__`
<lopex>
ah
<headius[m]>
it's not hard to improve it...special call site that captures caller's file and uses a fast path if it's actually the built-in require_relative
<headius[m]>
just needs impl
<lopex>
and a lot of casing in IR I guess ?
<enebo[m]>
headius: leaving soon but I just thought of a partial solution maybe...current staticscope.getFile
<enebo[m]>
if it null generate a stacktrace
<enebo[m]>
I believe even if it is in a closure or something exotic it will have file although if it is a block scope we could walk up static scope to local
<headius[m]>
but we don't know if it's the right scope
<lopex>
for require ?
<enebo[m]>
headius: yeah I guess if we call require_relative from non Ruby source it won't be the scope but we are not omitting static scopes are we?
<headius[m]>
hah, my brain didn't connect that the stack trace thing was you
<headius[m]>
ooo selinux
<headius[m]>
that's always fun
<headius[m]>
go ahead and open a new issue for this thing since the stack problem is gone (yay)
<headius[m]>
we've had various minor issues with selinux but this is peculiar
<headius[m]>
after a quick look I have no ideas!
<headius[m]>
that directory is part of normal JRuby dist...we don't write to it and it's just plain old gem specifications
<headius[m]>
if you can't read that it would certainly mess with everything else... the "default" dir is the gems that we include in JRuby as part of the Ruby stdlib, and this may mean it can't find them
<headius[m]>
as for not finding the binary...need more information there I guess, may be related and may not
<headius[m]>
open that issue and we'll chat again tomorrow (and on the issue)