<headius>
I am going to tag off the remaining items in this jit spec PR... they are known issues with bugs filed, but unlikely to be hit by most people in typical apps (and none have been reported organically)
<headius>
2 * size + 1 I think is typical if you don't want to check for size = 1
<headius>
er size = 0
<headius>
I will look at your branch but it sounds like you sussed out what we should be doing
<enebo[m]>
headius: [nil].to_s.encoding
<enebo[m]>
err
<enebo[m]>
2 + size() + 1
<enebo[m]>
not 2 * size()
<enebo[m]>
As it turns out MRI has some really weird weird logic for this
<enebo[m]>
[nil] -> USASCII
<enebo[m]>
but some cases will be default external
<headius>
2 + size + 1?
<headius>
weird
<enebo[m]>
it was an ensure for ',' and ' ' to be appended
<headius>
oh I see
<enebo[m]>
not sure where the +1 came in but we already check size on append and cat
<enebo[m]>
and those resizes I guess could make it too big?
<headius>
FWIW there is rb_enc_associate_index in EncodingUtils, which is pretty much what you needed... but just using cat seems fine
<enebo[m]>
I guess that could be a reason for it if we are doing a lot of [0] or something
<headius>
+1 maybe for trailing null?
<enebo[m]>
hahah yeah maybe
<headius>
they are not very explicit when they do that so I have to read between the lines
<headius>
duplicating that ternary in three places does seem a little ick
<enebo[m]>
it is going away
<headius>
ok
<enebo[m]>
I failed tests in MRI
<enebo[m]>
I did not plan on that being the end of this either but the ternary does exist within other places
<enebo[m]>
Also in MRI too :)
<headius>
figures
<enebo[m]>
so I dislike this associateIndex but I may end up doing it
<enebo[m]>
The ruby/spec definition sounds very clear on how it behaves but the reason it behaves that way is not as described
<enebo[m]>
things will be US-ASCII and won't be if they change due to a single content with the only exception is that we cannot use an encoding which is not ascii compatible since we are putting '[]' into the resulting string
<enebo[m]>
So testing for default external etc is really testing that a subelement of that was present in a sense
<enebo[m]>
It is still good they have these specs since it catches mistakes in ary_to_s
<headius>
and because inspect strings always need to be ascii
<headius>
right?
<enebo[m]>
well yeah they have to accept an ascii character to display
<enebo[m]>
I guess it goes encoding -> default_external -> fuck it US-ASCII and look horrible
<enebo[m]>
somewhat surprised it is not binary
<headius>
oh rad, they appear to have deprecated Proc.new with no block in 2.7
<enebo[m]>
yeah
<headius>
that will be nice, we can remove that hack in IR
<enebo[m]>
It is already gone
<enebo[m]>
ssshhhh
<headius>
tasty
<headius>
I just tagged off a spec in this jit run that does ProcSubclass.new
<headius>
worked accidentally in interpreter but was never really supported
<headius>
I must be doing something wrong with these tags... I thought adding any tag name would filter it but it doesn't seem to for "jit"
<headius>
ah need to add to exclusion I guess
<headius>
there we go
<headius>
looks like that got it... I will merge this PR shortly and then look at the last couple items I have for 9.3
<enebo[m]>
headius: I was reading this the other day...this is only windows because we do some ffi stuff (as part of fiddle impl) to access windows registry or something like that?
<enebo[m]>
I don't totally recall why we have to do this on windows but I want to make sure it only impacts windows since I doubt we would want to enable ffi on all platforms for startup hit
<enebo[m]>
this is from Win32API?
<enebo[m]>
derp
<enebo[m]>
ignore me...kernel/file.rb
<enebo[m]>
sorry I read this a couple of days ago and forgot...so windows only
<headius>
so the problem here is that we activate FFI very early in boot to set up some Windows and Solaris methods on File (symlink, fcntl)
<headius>
early as in before RubyGems even boots
<headius>
so there's no way to even try to activate the gem
<headius>
I thought it could be made lazy but it defines constants from FFI that should be visible before you call e.g. fcntl
<headius>
the cleanest option would be moving this into Java and using jnr-posix or jnr-ffi
<enebo[m]>
I think this could be more easily be lazy if we just say windows 2002/2003 are no longer supported
<enebo[m]>
that would eliminate the main FFI check which has to be done early
<enebo[m]>
I think then there would be a def symlink which more or less included most of the code in the windows block (via another require) which then redefined symlink
<enebo[m]>
I guess there is another early if for FFI::Config but is that because some windows platform may not be capable of loading FFI?
<headius>
yeah the constants are the part I was unsure how to make lazy
<enebo[m]>
I do half think though that could be in the new file and it would behave in a similar way to how it works now if ffi does not load
<headius>
hmm they could just be harcoded too
<enebo[m]>
those constants are only used by symlink or more?
<headius>
not use FFI::Platform::ADDRESS_SIZE
<headius>
they do not appear to be standard constants, maybe I am worried for nothing
<headius>
standard as in we are just defining them for this logic
<enebo[m]>
ok so everything in the windows section other than class File can be in another file which then does all that jazz to File including loading FFI at that point from first call to symlink?
<headius>
that's what I'm thinking
<headius>
and similar for the Solaris flock below
<enebo[m]>
yeah I think so long as the 2002 thing is dropped it becomes easier
<enebo[m]>
even the 2002 thing could be checked in another way I suppose but I think saying 9.2 is our last win 2002/3 supported version is ok in 2021
<enebo[m]>
if someone really is stuck we can probably help them backport something but I don't feel horrible about dropping old platforms over time
<headius>
yeah that seems reasonable
<enebo[m]>
heh another possible path is to load it and pretend it will work and just catch any error which happens :)
<headius>
yeah I am going to try to lazy this
<enebo[m]>
2002 would then call symlink get an error we catch then return unimplemented
<headius>
gem activation would have been nice but I would need to move this way later in boot
<enebo[m]>
so the funny part of this discussion is two hours from now when we realize bootstrapping on windows calls symlink
<headius>
ugh I wouldn't be surprised
<enebo[m]>
I am kidding there is no way that happens :)
<enebo[m]>
If it does we probably should eliminate that
<enebo[m]>
binstubs would be one place where it could happen but on windows?
<headius>
yeah seems pretty unlikely
<headius>
they aren't really even a user-facing thing on Windows
<enebo[m]>
you could catch on NoMethodError if you want to allow 2002/2003 to still work although the last comment in the issue above seems to imply your previous work did not solve their issue
<enebo[m]>
since the referenced issue removed us from their test run
<headius>
yeah who cares
<enebo[m]>
ok. if they care then we can help in some way.
<enebo[m]>
but that is pretty long in the tooth
<enebo[m]>
at some point you may need to monkey patch your own install if you want to keep working
<headius>
2002/2003 has been EOL by MS for a while anyway
<enebo[m]>
I bet
<enebo[m]>
HAHAHA
<enebo[m]>
2015. And that issue was opened in 2016 :)
<headius>
yeah
<byteit101[m]>
headius: about to go on a one week vacation, but I wasn't sure how to fix 6718 when I debugged it as I wasn't sure how the super logic was working over there