skade has quit [Quit: Computer has gone to sleep.]
mkristian has quit [Ping timeout: 260 seconds]
mkristian has joined #jruby
yfeldblum has quit [Remote host closed the connection]
pawnbox_ has joined #jruby
pawnbox has quit [Ping timeout: 245 seconds]
pawnbox_ has quit [Read error: Connection reset by peer]
pawnbox__ has joined #jruby
drbobbeaty has joined #jruby
pawnbox__ has quit [Remote host closed the connection]
brikkoroller has joined #jruby
<brikkoroller>
Hello world!
<brikkoroller>
I'm trying to provision a server with Chef and install jruby with rbenv, but I get this error: "ERROR: Java 7 required. Please install a 1.7-compatible JRE."
<brikkoroller>
can anybody help me with this issue? It'd be very much appreciated
nirvdrum has joined #jruby
skade has joined #jruby
pawnbox has joined #jruby
pawnbox has quit [Ping timeout: 240 seconds]
mkristian has quit [Quit: This computer has gone to sleep]
cremes has quit [Remote host closed the connection]
cremes has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
skade has joined #jruby
<headius>
haylon: I believe that's possible
<headius>
good morning all
<chrisseaton>
headius: hello!
<headius>
chrisseaton: hiya! congrats on lang specs
<chrisseaton>
thanks - I think if you looked at your remaining specs you could complete them all as we have most of the same for the last few and it just needed a few tricks here and there
<headius>
yeah we chip a few away once in a while...usually we prioritize reported issues first, and there's never any lack of those
<headius>
if a reported issue is tied to a spec, we'll fix that whole chunk
<chrisseaton>
I don't know if we can take specs from Rubinius any more so we may need to write our own for 2.3
<headius>
well there's already more 2.3 specs in ruby/spec than in rbx
<headius>
ruby-2.3 branch passes all of them I believe
<headius>
I don't think I tagged anything
<chrisseaton>
I will add some missing specs like refinements at some point, now I won't have to risk abuse to get them accepted
<GitHub0>
jruby/master d54e4cd Konstantin Shabanov: Fix SizedQueue#num_waiting regression...
<GitHub0>
jruby/master 304129d Charles Oliver Nutter: Merge branch 'num_waiting_regression' of https://github.com/etehtsea/jruby into etehtsea-num_waiting_regression
<GitHub0>
jruby/master c0b4ba1 Charles Oliver Nutter: Merge branch 'etehtsea-num_waiting_regression'
<enebo>
My other wish is we could just have one single code path which is return jnr-posix.mkfifo which will just return unimplemented
<enebo>
I guess we do that in some cases
<headius>
well we could if jnr-ffi had some metadata for functions it can't bind
<headius>
rather than just exploding
<enebo>
but if we want a deps system embedded in code it then seems those places should not have platform chaecks in code
<enebo>
headius: yeah possibly..windows is the weird one because we have all these other methods and we call posix and not libc
<headius>
right, we do our own cygwin-like emulation in many cases
<headius>
cygwin-like or ruby-like
<enebo>
headius: we probably need a decent anno system on jnr-posix :)
<enebo>
WindowsPosix { @Unimplemented int mkfifo() {} }
<enebo>
err WindowsPOSIX
<enebo>
hmmm this is complciated :)
<enebo>
we have this ahead of time knowledge in this library
<enebo>
we implement is as late bound knowledge
<enebo>
on using side (JRuby) we do platform check to make sure we don’t call something which will fail (because we don’t know since it is late bound)
<enebo>
on top of that MRI sometimes has pretty different behavior on windows vs unix for the same method so we definitely will need some platform checks on jruby consuming side
<headius>
I wonder how project panama handles this
<headius>
if it has anything
<enebo>
ok lunch time for me bbiab…I will think about this more
<headius>
ugh, wish I had more time to look at those things
elia has joined #jruby
<enebo>
seems like half of this is static on jnr-posix side
<enebo>
adn we are missing that though
ITXpander has joined #jruby
<headius>
yeah
<headius>
enebo: does jnr-posix pass on darwin for you?
<headius>
I'm getting a failure in fcntl test trying to set CLOEXEC
<headius>
FWIW, MRI does just mark mkfifo not implemented on Windows right now
shellac has joined #jruby
<headius>
I don't see why it should fail
<headius>
gah
<headius>
now this is failing on all platforms, what gives
<nirvdrum>
Indeed. I finally got something together.
<nirvdrum>
Unfortunately, at 140 commits, specs didn't pass for maybe the first 120. String is a fairly critical class as it turns out.
<enebo>
ROES
<nirvdrum>
Not bad. About a couple weeks of effort.
<enebo>
nirvdrum: you are getting something to run so that is neat
<nirvdrum>
There are certainly some bad cases. But on the whole, I'm seeing faster critical operations.
<enebo>
oh faster?
<nirvdrum>
Some of them are certainly doable with ByteList. Ropes just made it easier.
<enebo>
nirvdrum: and I thought you were simplifying and not working on fast
<nirvdrum>
I mostly was.
<enebo>
nirvdrum: ah cool. take notes
<nirvdrum>
But when code range & string length are cached, some operations became easier to do using those values.
<enebo>
nirvdrum: yeah and we can cache length in existing impl without ropes too
<nirvdrum>
Right.
<nirvdrum>
Ropes being immutable just meant it was easier for me to keep track of it.
<enebo>
nirvdrum: also as we talked about I think if we keep track of mbc width we can optimize smaller uniform strings in a UCS2 sort of way
<nirvdrum>
ByteList has trouble with caching character length because it's shared for sub strings.
<headius>
I'm curious how much false sharing it will add or remove
<headius>
COW string is prone to false sharing problems (by which I mean holding a giant buffer for a tiny slice)
<enebo>
not as much as it is for Array
<headius>
of ByteList contained all the COW logic it would be a lot simpler to work with
<nirvdrum>
headius: Indeed. I reported an issue like that against JRuby a couple years ago :-/
<enebo>
at least that is my opinion :)
<headius>
as it is it's mostly a dumb struct
<headius>
enebo: true, but it's still there
<headius>
that's the main reason OpenJDK stopped doing it
kith has joined #jruby
<nirvdrum>
I haven't done much with the byte[] itself. Right now, it does a copy everywhere. So my offsets are always 0.
<nirvdrum>
And the end is always the byte length.
<nirvdrum>
It made the conversion simpler. But it may be a bit too aggressive.
<headius>
nirvdrum: yeah, so there's the question about how much duplication it introduces versus byte[] sharing
<headius>
it will be interesting to tune
<enebo>
nirvdrum: the byte[] is shared but length is length between begin and begin + realLength
<headius>
there will be almost no false sharing there but potentially a lot more duplication
<enebo>
nirvdrum: so I think it can be cached ni bytelist no?
<headius>
enebo: I think he means there's no semantics for sharing within ByteList itself
<headius>
we do all of that in RubyString
<enebo>
headius: potentially more heuristics to merge as well
<nirvdrum>
headius: Indeed. Although I applied some identity construction methods that in practice have worked out fairly well. E.g., mspec takes a directory name, appends a filename, chops the filename off, appends the next filename, and so on.
<headius>
nirvdrum: that may be something truffle can see through, at least a bit farther
<nirvdrum>
I wasn't explicitly looking to handle that case, but I accidentally did and was pleasantly surprised.
<nirvdrum>
A substring of a concatenated rope will try to work with one of its two children.
<enebo>
nirvdrum: yeah substr would need to recalc in some cases unless it is known to be constant width
<nirvdrum>
So in that case, there was a high level of reuse for the directory name rope.
<headius>
I do still want to make ByteList fully COW-clean so we don't have that logic splattered all over RubyString
<headius>
my attempts to do it have been extremely painful
<enebo>
heh
<enebo>
yeah something is intimidating on cleaning up that API
<nirvdrum>
I'd like to have all string literals interned. Right now each string literal will share the same rope. But I'd like two district string literal nodes with the same logical value using the same rope as well.
<headius>
we could flip that switch in the parser in any JRuby mode really
<nirvdrum>
I should note I started this as immutable ByteList and it could be made back into that. But ByteList had a lot of baggage I didn't want to cope with at the moment.
<headius>
it's just a matter of accepting a lot more retained strings in order to manage that identity
<nirvdrum>
E.g., ByteList being a CharSequence.
<headius>
yeah, ByteList as a CharSequence is legacy that never really worked right
<headius>
or should I say, never did what it should have, because it predated Encoding
<nirvdrum>
headius: Right. But I think both backends are already caching that ByteList.
<nirvdrum>
So you're looking at some additional overhead for a table, for sure. But I think in practice it'll end up paying for itself.
<headius>
nirvdrum: across calls to the same StrNode, yes, but not for the same str content in different nodes
<headius>
this is why MRI's AST actually does freeze and deduplicate the strings in the AST
<headius>
so our StrNode equivalent is just a dup
<headius>
but they only have one copy of "foo" in the entirety of the app's ASTs
<nirvdrum>
Right. That's what I'm saying. There's overhead for the table, but we currently cache distinct ByteLists representing the same byte[] at each StrNode.
bb010g has joined #jruby
<headius>
I want to make the MRI change
<headius>
I have an open bug for it
<nirvdrum>
I think eliminating that duplication would let the table pay for itself fairly quickly.
<headius>
and a couple other cases
<headius>
indeed
<headius>
and we already have the table at least for fstrings in JRuby proper
<nirvdrum>
And if you start caching character length and what not, you'd save a lot of calculations elsewhere.
mkristian has quit [Quit: This computer has gone to sleep]
<headius>
indeed
<enebo>
how about id lookup in that table?
<nirvdrum>
Length is a big one, since it's used for bounds checking on indexing.
yfeldblum has joined #jruby
<enebo>
I guess though 4 bytes vs an object reference of 4 bytes
<nirvdrum>
enebo: Eh?
<enebo>
nirvdrum: at one point I had thought about using id’s instead of object references to save memory but I doubt we can use 2 bytes for that vs 4 bytes which a object reference to an object would be
<nirvdrum>
Ahh.
<enebo>
nirvdrum: and with compressed refs in Java it might be counterproductive anyways
<enebo>
nirvdrum: I am solving a problem which Java ended up partially solving anyways
skade has joined #jruby
tcrawley is now known as tcrawley-away
n00bdev has quit [Remote host closed the connection]
<headius>
we'll see what happens when this is fixed
<nirvdrum>
Cool. I guess nothing was set up. It appears there's a global setting to notify a lot of people on failure.
<nirvdrum>
No IRC option that I see.
<enebo>
headius: I am going to manually apply your 1.7 block fix to master and then rip out appropriate IR logic
<enebo>
headius: is there some specific tests to untag
<GitHub85>
[jruby] enebo closed issue #2335: File.exist? and many others do not try system dir on wnidows if path starts with bare / https://github.com/jruby/jruby/issues/2335
<headius>
look at that commit or the one after, I untagged
<lopex>
" Cooper’s computer actually found the prime on 17 September 2015, but a bug meant the software failed to send an email alert reporting the discovery, meaning it went unnoticed until some routine maintenance a few months later"
<lopex>
" The official discovery date is the day a human took note of the result"
<enebo>
headius: ok
<headius>
lopex: I may have asked this before and forgotten...what is the VANILLA mode in jcodings?
<lopex>
nirvdrum: that's a lot of work wrt ropes
<headius>
code in VANILLA doesn't appear to match anything in MRI
<nirvdrum>
lopex: I'd love your feedback.
<headius>
and it has always been false it seems
<headius>
or at least it's false everywhere right now
<lopex>
headius: oniguruma before it diverged in mri and then onigmo
<lopex>
might be an unsigned int code point issue so it should be widened
<headius>
hmm
<lopex>
nirvdrum: wrt previous discussion, you meant full literal merging and keeping global table so the nodes can point at those ?
<nirvdrum>
lopex: Yeah. The table can either store a byte[] (both ByteList & Rope friendly) or just one or the other. CoW will take care of the rest.
<lopex>
nirvdrum: how far can truffle see literal propagation ?
<nirvdrum>
lopex: Well, the literal nodes come from the parser. Truffle wouldn't need to know that two different literals are the same string. It would just see that they share the same rope.
skade has quit [Ping timeout: 240 seconds]
<lopex>
headius: what about those "non-strict" encodings ? these are only used in 1.8 mode now in 1.7
<headius>
those could go then too
<lopex>
headius: and possibly by KCode as a remnant
<headius>
well, maybe not until 1.7 is EOL
<lopex>
headius: KCode is totally deprecated now ?
<lopex>
headius: also, if the non strict ones go, some encoding classes can be now resplit
<headius>
it has been deprecated but some of the flags might still do m17n setup
skade has joined #jruby
<nirvdrum>
headius: Where's the fstring cache you mentioned earlier?
<headius>
Ruby.freezeAndDedupString
<lopex>
nirvdrum: you want to merge cr and singleByteOptimizable at some point ?
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<lopex>
(in rope node)
<headius>
hmphf
<headius>
I can't find anything different in our GB18030 transcoder so far
<nirvdrum>
lopex: I really can't because of binary strings.
<nirvdrum>
lopex: More accurately, ASCII-8BIT.
<lopex>
nirvdrum: I recall now
<nirvdrum>
I did essentially get rid of CR_UNKNOWN.
<nirvdrum>
I still need to remove the scanForCodeRange calls. They just short-circuit out currently.
<nirvdrum>
headius: Thanks.
<lopex>
nirvdrum: if you want to serialize entire rope you'd be still going through that negotiate encoding thingy right ?
<nirvdrum>
I'm not sure I follow.
<lopex>
or I dont get it all yet
<nirvdrum>
headius: So this still sees a RubyString with an allocated ByteList, but discards that in favor of the cached one?
<headius>
yes, intended to be used first time to get the global version of that string
<headius>
obviously not useful to keep feeding new strings to
<headius>
see how it is used in FrozenString operand for example
<nirvdrum>
lopex: Encoding compatibility still needs to be checked for a lot of operations. I haven't work on optimizing that much yet. Ruby's semantics around that are also infuriating.
<headius>
this is roughly how MRI's works, but their AST is not separable from runtime state so they get these fstrings eagerly
<lopex>
nirvdrum: oh, I just thought for a minute some of that might be delayed
<nirvdrum>
lopex: I'd like to do that. Or at the very least, I'd like to make it cheaper. I think we can use a lookup table. I mentioned this before.
<nirvdrum>
The cross-product of encodings would be fairly small.
<headius>
lopex: MRI's GB18030 encoding sources have a million times more stuff than we do...what is all this?
<nirvdrum>
So if we could lookup by each encoding index, it'd be a 2D array reference.
<headius>
jeez, 21k lines long
<lopex>
headius: the trans ?
<nirvdrum>
headius: Eliminating allocations would be nice. But for the time being, I'm quite content to simply get them all using the same references.
<headius>
lopex: yeah
<headius>
the so and sio functions appear to match theirs
<headius>
I'm checking the encoding tables now
<lopex>
headius: oh you mean transcoding instructions, maybe not all of them get parsed by the scripts ?
<lopex>
ranges or trascoding instrs ?
<headius>
well what is all this:
<headius>
gb18030_byte_array[56182] = {
<headius>
#define from_GB18030_81_30_81_offsets 0
<headius>
48, 57,
<headius>
1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
<headius>
this stuff goes on for thousands of lines
<lopex>
headius: Transcoder_Gb18030_WordArray.bin is 115k in size
<headius>
ahhh ok that's where that noise goes
<headius>
has been a while since I worked on the trancoder
<lopex>
headius: for ranges you'll notice similar noise, they use gperf for looking up char type names
<lopex>
no idea why
<headius>
ok
<lopex>
then perfect hashing is just a code bloat for me
mdedetrich has joined #jruby
<headius>
hmm, well all the usual suspects look ok for this
<headius>
I guess I need to check encoding methods now too
<enebo>
code deletion looks really good with this parser change
<enebo>
but I am not going to commit this right before I take off for the evening :)
<lopex>
headius: leftAdjustCharHead
<lopex>
this is the encoding when you dont know the length in bytes until you read three first for example :)
<lopex>
three potential heads
<headius>
yeah
<headius>
that could certainly produce all unrecognized chars
<enebo>
1) Error:
<enebo>
TestFlip#test_hidden_key:
<enebo>
grr
<nirvdrum>
Heh.
<headius>
yeah this looks like it could use a re-port
<headius>
I must not have bothered when working on 9k because it's HUGE
<lopex>
headius: in funSoFromGB18030 you use >>
<lopex>
maybe try a >>> ?
<headius>
I suppose I should use >>>
<headius>
I'll give it a shot
<headius>
long should have plenty of room for unsigned int though
<lopex>
there's other arithmethics though
<lopex>
I'd opt for long there
<headius>
u is a long
<headius>
what do you mean?
<lopex>
os wait, I thought s0 and the like were also codes
<headius>
those are just unsigned bytes
<headius>
out of the incoming byte array
<headius>
s0 = unsigned byte s[0]
<headius>
THANKS JAVA
<lopex>
headius: but dont you need to mask with 0xffffffff when constructing a codepoint ?
<headius>
ahh that's possible
<headius>
LHS is int there
<lopex>
you need to sign widen that int
<headius>
possibly also in sio
<nirvdrum>
Signed bytes. It's what everyone expects.
<lopex>
nirvdrum: I still have 0xff in my dreams
<nirvdrum>
I lost about a half a day debugging some code until I realized I forgot 0xff somewhere.