<rebelwarrior[m]> rails v 6.1 doesn't install (railties?)
subbu has quit [Quit: Leaving]
<headius> Yeah we should take a bit and fix anything preventing current rails versions from working
<headius> Open issues for anything you see
oblutak[m] has joined #jruby
<puritylake[m]> enebo: I don’t think that document can help me, if I wanted the binary I could just get the long value with Double.doubleToLongBits
<puritylake[m]> I won't give up on it yet, I can be a bit slow to the uptake on maths and similar topics
<puritylake[m]> I'm gonna do a quick look through of dtoa.c to see if I can understand some of what it is doing
<rebelwarrior[m]> ```
<rebelwarrior[m]> FYI error when using rbenv to install ^^ (I dropped the zip file and that worked instead)
<rebelwarrior[m]> Don't know if it's relevant but wanted to share before I closed the terminal window.
<enebo[m]> rebelwarrior: any chance you can open an issue on rbenv project?
<enebo[m]> Looks like they use tr command for something and it is unhappy
<rebelwarrior[m]> yes I can enebo I'll open an issue there.
<enebo[m]> rebelwarrior: Also which env did Rails 6.1 not work for you?
<enebo[m]> This was on fedora and I test with totally clean env
<enebo[m]> oh you said homebrew
<enebo[m]> rebelwarrior: are you on M1?
<rebelwarrior[m]> Yes I'm on M1
<rebelwarrior[m]> issue open feel free to add or edit if necessary.
<enebo[m]> rebelwarrior: yeah I suspect that is enough for someone to try assuming they have an M1 mac to try it on
<enebo[m]> I wouldn't really expect M1 to be a big deal for unpacking something but who knows
<enebo[m]> When headius is around I suspect he will be able to repro your Rails 6.1 install issue since he can run on M1
<enebo[m]> We will open an issue based on that or get back to you
<enebo[m]> although if you care to you could make an issue for that too :)
<rebelwarrior[m]> where should I open the issue?
<enebo[m]> for the railties install open it on jruby project
<enebo[m]> This almost certainly will be an M1 issue since I can install it on Fedora (and I am not really sure what would not work with railties itself)
<enebo[m]> Oh unless it is doing some binstub thing and not working? Like chmod or ln
<enebo[m]> but done from Ruby which would hit doing native calls
<enebo[m]> Totally a guess though
<enebo[m]> rebelwarrior: That is strange when I installed this I did not get mimemagic as a transitive dep
<enebo[m]> If I had to guess I would it picked mini_mime instead
<enebo[m]> rebelwarrior: can you try of rails? I wonder if there was a problem early in 6.1 where it was doing the wrong thing for JRuby
<rebelwarrior[m]> rails issue was not an issue. resolved.
<rebelwarrior[m]> `gem install rails -v` solved the issue they'd migrated to marcel due to licensing issues -v 6.1 tries to install the old one.
<enebo[m]> rebelwarrior: ah great. So back down to one issue
subbu has joined #jruby
subbu has quit [Ping timeout: 240 seconds]
<enebo[m]> | Syntax | Description |
<enebo[m]> | ----------- | ----------- |
<enebo[m]> | Header | Title |
<enebo[m]> | Paragraph | Text |
<enebo[m]> bummer
<headius> ha
subbu has joined #jruby
<headius> that fixes the tainted string issue on 9.3
<enebo[m]> lol yeah I saw that
<headius> backports changes to string deduplication from 9.3 plus the relevant part of the fix above
<headius> the 9.3 PR passed CI already so it seems good
<headius> I did not check for specs or tags
<enebo[m]> seems fine to me...it is just sad we are fixing things which Ruby has removed
<headius> yeah I am a little annoyed at having to do one last taint fix
<headius> merging this to master will basically just ignore the entire patch
<enebo[m]> the combo PR for 9.2 looks fairly benign to me as well
<enebo[m]> isBare is clearly just being more constrained on what is deduped
<headius> yeah mostly refactoring that only happened in 9.3
<enebo[m]> so I highly doubt 2.5 users are depending on them to be the same instance
<enebo[m]> so I don't see much risk
<headius> I reapplied the same commits so there'd be some accounting of the changes
<enebo[m]> make sense
<enebo[m]> I fixed an issue with your subclasses update
<enebo[m]> you missed 'klass.' in part of it
<headius> hah oh yeah I forgot to test it
<headius> oops
<enebo[m]> np...it was correct other than that so sayeth ruby/spec
<enebo[m]> I am readding gettable so ^var will work as we expect right now
<headius> Ruby's turning into perl 6
<enebo[m]> I honestly don't even remember this syntax
<enebo[m]> adding this method back bums me out. I worked so hard to remove it
<headius> one failure for 9.2 fix: String#-@ does not deduplicate already frozen strings FAILED
<enebo[m]> whoo hooo
<headius> came in with one of the 9.3/2.6 cherry-picks
<headius> 2.5 also does not deduplicate hash keys so I filtered those parts out, but I guess I missed this side
<headius> ahh yeah.. this commit added isBare and changed the behavior of -@
<headius> 42eace21e4547d8ec49ba46b27731021f90746a8
<headius> eb11c5de9d9f9e220c6166b440c484639384e291 on 9.3
<headius> I found an additional related bug: the JIT does not deduplicate frozen strings when first creating them
<headius> FrozenString operand deduplicates based on the raw bytelist so if some code interns a string and other code is loaded with that same frozen string it will be the same deduplicated object
<headius> not sure if this just diverged naturally or if something was changed on purpose
<headius> JIT will cache the frozen string but each unique frozen string will still be created new for that file
<enebo[m]> headius: oh I should bring this up...I broke JVMVistor with my call to markAsRuby2KetwordArg in emitScope
<headius> good job
<enebo[m]> the aload(1) could be a different call but I think it is staticScope but the m.loadArgs is clearly not right
<enebo[m]> I don't see why though...I thought it was just loading args.
<headius> hmm maybe I'm wrong, JIT and operand both seem to call the same function to produce the frozen string
<headius> enebo: I can look at it if you have a repro
<headius> I assume it is failing some tests
<enebo[m]> run spec:compiler
<headius> aha
<headius> indy mode always creates a new frozen string
<headius> normal mode does not but normal mode did not exist until AOT work to remove all indy
<headius> and for this we always use indy still
<headius> enebo: ok
<headius> after I fix this
<headius> oh haha the answer is weirder than that
<headius> enebo: so I'm not sure about this one...
<headius> the reason it only affects interp is because interp StringLiteral is evaluated by retriving the FrozenString it contains and duping it
<headius> that's how yarv does it also
<headius> so when it dups the FrozenString it picks up any flags like tainting
<headius> when the dedup cache is afflicted with a tainted string, that means all non-frozen literals of that string will duplicate that tainting
<headius> JIT mode ignores the contained FrozenString and just caches the ByteList on first access for creating a new string every time
<headius> so no tainting infection from a bad dedup cache
<enebo[m]> hmm
<headius> I'm not sure either way is wrong
<enebo[m]> so one would argue it should not cache a tainted string
<enebo[m]> and tainting does not exist in 3.0
<headius> FrozenString being inside StringLiteral is basically just a way to reuse the FrozenString logic to produce new mutable strings
<headius> yeah maybe I should just leave it
<headius> in both cases you get a new string
<headius> interpreter does it by duping from cache, JIT does it by creating a new object with cached bytelist
<headius> duping is probably slightly slower because of useless flags propagation
<enebo[m]> should JIT be returning new Strings in 3+?
<enebo[m]> It should be using table right?
<headius> both branches taint fixes are merged fyi
<headius> well mutable strings always produce a new object
<headius> so no .freeze or -"string" literal or frozen-literal-string pragma
<headius> the only difference is how the mutable string object gets created, either by duping a cached frozen version of it or by just creating a new object
<enebo[m]> oh I see I was reading that backwards
<headius> that kinda sums it up
<headius> the JIT certainly could switch to producing new mutable strings by duping from the cache but I would expect it to be a bit more overhead for no real gain
<headius> it would also move the construction of the new mutable string object further away from the code, and that will impact inlining
<headius> meh not changing it
drbobbeaty has quit [Ping timeout: 256 seconds]
drbobbeaty has joined #jruby
drbobbeaty has quit [Remote host closed the connection]
drbobbeaty has joined #jruby
sagax has quit [Ping timeout: 240 seconds]