RomainManni-Buca has quit [Quit: Bridge terminating on SIGTERM]
JulesIvanicGitte has quit [Quit: Bridge terminating on SIGTERM]
AnilJaiswal[m] has quit [Quit: Bridge terminating on SIGTERM]
UweKuboschGitter has quit [Quit: Bridge terminating on SIGTERM]
BlaneDabneyGitte has quit [Quit: Bridge terminating on SIGTERM]
headius has quit [Quit: Bridge terminating on SIGTERM]
Bi[m] has joined #jruby
ahorek[m] has joined #jruby
enebo[m] has joined #jruby
kai[m] has joined #jruby
lopex[m] has joined #jruby
MatrixTravelerbo has joined #jruby
subbu[m] has joined #jruby
JasonvanZyl[m] has joined #jruby
nilsding has joined #jruby
TimGitter[m] has joined #jruby
MarcinMielyskiGi has joined #jruby
OlleJonssonGitte has joined #jruby
UweKuboschGitter has joined #jruby
JulesIvanicGitte has joined #jruby
ChrisSeatonGitte has joined #jruby
RomainManni-Buca has joined #jruby
BlaneDabneyGitte has joined #jruby
MattPattersonGit has joined #jruby
liamwhiteGitter[ has joined #jruby
JesseChavezGitte has joined #jruby
kares[m] has joined #jruby
basshelal[m] has joined #jruby
byteit101[m] has joined #jruby
KarolBucekGitter has joined #jruby
XavierNoriaGitte has joined #jruby
FlorianDoubletGi has joined #jruby
johnphillips3141 has joined #jruby
nelsnnelson[m] has joined #jruby
klobuczek[m] has joined #jruby
Leonardomejiabus has joined #jruby
mattpatt[m] has joined #jruby
jswenson[m] has joined #jruby
NoraHoward[m] has joined #jruby
rebelwarrior[m] has joined #jruby
deividrodriguez[ has joined #jruby
shibz[m] has joined #jruby
CrisShupp[m] has joined #jruby
AnilJaiswal[m] has joined #jruby
CharlesOliverNut has joined #jruby
headius has joined #jruby
TimGitter[m]1 has joined #jruby
<JasonvanZyl[m]>
If I publish a snapshot build can you verify this week? We don't use any language features above java8, but I've lost track of how the mechanics of the compiler works with respect to building with a newer Java and running on an older.
<JasonvanZyl[m]>
Actually I can do the first test, I'll build it with 11 and flip back to 8 to run it and see if it works. So I'll try that first.
<kares[m]>
(would be nice to have up-to-date version out of the box - but no hard feelings if this gets untagged from 9.3.1.0)
<headius>
I don't have any major objection, but enebo may have already verified the release
<headius>
We need to get that verification into a CI job perhaps
subbu has joined #jruby
<JasonvanZyl[m]>
headius: I have a local build here of polyglot, what is the simplest thing I can run in your build that will tell me if everything is ok? Should I just try `./mvnw verify` ?
<enebo[m]>
I just merged it. I will verify new bits
<headius>
Jason van Zyl: just about anything should verify that it still works
<headius>
the main pom is .rb and everything goes from there
<headius>
Jason van Zyl: I commented on your issue for the record
<headius>
we will move to building with 11 soon but need 11.0.13 at least to fix a javac bug I found that prevents us compiling
<headius>
punted the remaining 9.3.1.0 issues to 9.3.2.0
<headius>
we should continue reevaluating whether they fit 9.3 or 9.4 or whether they should just be untargetd
<headius>
enebo: there are not a ton of large items in this release that warrant their own notes
<enebo[m]>
yeah just mostly things people reported
<headius>
yeah I don't have anything worth adding on top of the issue list
<headius>
I will start prepping the other release items
<enebo[m]>
I plan on pushing site after I eat since it takes some time for Maven
<enebo[m]>
I also think more people see the release on west coast the later we post
<headius>
docker is in process
<headius>
I can throw social posts together whenever the site is up
<enebo[m]>
ok
<headius>
I think I will try to spend the rest of the week figuring out how to get variadic functions working better in jffi
<headius>
I see where all the bits are but the current logic basically assumes varargs all go on heap and that is not right for all platforms
<headius>
the logic builds up a heap va_arg like thing and then dispatches through the same logic as non-variadic calls, but there are libffi functions that should be called for vararg dispatch to set up the call protocol properly
<headius>
jffi itself has no understanding of variadic functions... jnr-ffi does the arg munging on its own
<headius>
this may have been done to avoid having to do a new native jffi lib but it has to change
subbu is now known as subbu|afk
subbu|afk is now known as subbu
<enebo[m]>
headius: going to push site and update github release
<enebo[m]>
After that send release emails
<enebo[m]>
maven is propagated
<headius>
ok
<enebo[m]>
site is live. GH release done. updating VERSION for 9.3.2.0-SNAPSHOT
<headius>
ok
<enebo[m]>
Will send out email now that I see your response
<headius>
download page links to 9.3.0.0 and 404s
<enebo[m]>
what?
<enebo[m]>
ah I see it
<enebo[m]>
fixed
enebo has joined #jruby
<headius>
enebo: the title and header in the release notes page still says 9.3.0.0 also
<puritylake[m]>
Hello to all, joined to talk about the String#freeze issue
<headius>
puritylake: hi there!
<headius>
I'm trying to remember if we have any other cases like this
<headius>
enebo: not sure if you have been following the issue but we need to honor overridden String#freeze and currently always assume it is producing a frozen string
<enebo[m]>
honor mean no longer freeze opto?
<headius>
this is the IR builder logic that does it, with no room for freeze being overridden
<headius>
so if freeze is builtin it acts like a FrozenString operand, but if it is overridden it makes the call
<headius>
this specific case is likely never going to happen but it seems like an opportunity to introduce IR for a cached value that is invalidated by a method change
<enebo[m]>
shoot. I was totally against the idea of using .freeze for this and not a syntax differentiating between immutable/mutable but Matz is not big on that
<enebo[m]>
but it means we cannot prop the value any more like other immediate values
<headius>
well, this was my idea because of matz not wanting to add syntax
<enebo[m]>
yeah but honoring method redefinition is a mistake
<headius>
they still don't have syntax for frozen strings but there's the pragma and some additional utility methods
<headius>
perhaps?
<headius>
it is in the specs in any case
<enebo[m]>
So a = "ff"; p a will not longer become a = "ff" p "ff"
<headius>
no, `a = "ff".freeze; p a` will no longer become `p "ff"`
<headius>
it only affects the .freeze call on a literal string
<enebo[m]>
yeah that was what I was trying to type
<enebo[m]>
Perhaps most people use pragma now
<headius>
I assume almost everyone prefers the pragma now
<enebo[m]>
I suppose if this is becoming a rarity then it doesn't matter if we just make it ordinary. If less rare perhaps it is not propagateable but still "special" with a guard
<enebo[m]>
but are we fixing a real world issue or just a spec?
<headius>
yeah that sums it up
<headius>
Looks good to me, maybe the titles don't need to be links but this is good
<headius>
gah where did that come from
<enebo[m]>
hahah
<headius>
that was about the markdown, if it didn't send before
<enebo[m]>
I know when it was intended to be typed at least
<headius>
as far as I know this is only fixing a spec and an open issue
<enebo[m]>
I think we should consider leaving it as an incompatibility and see if anything real hits it
<enebo[m]>
I certainly don't think without a real use case we should be spending time fixing it atm
<headius>
maybe grep your gems for `".freeze` and `'.freeze`
<enebo[m]>
but you point out the major issue if we allow redefinition of it we have to make this change
<headius>
FrozenString will remain as an operand for cases where we know it's always frozen, like with pragma
<enebo[m]>
oh yeah that's true
<enebo[m]>
for pragma we know. I just meand for "".freeze
<headius>
we would add something like a new instr that's either FrozenStringOrCallFreeze or a more generic CacheIfMethodBuiltin
<headius>
the latter might make this more interesting because there will be other patterns
<enebo[m]>
I like the notion of generic but it is realld CacheIfPureFunction
<headius>
nobody has filed this as a problem with their code
<headius>
it could also be gated behind a property so most people would run with the current behavior
<enebo[m]>
yeah I usually like to be compatible when we can see how to easily enough
<enebo[m]>
in this case it is just extending a callinstr but with that said this feels a little like aliasing eval to me
<enebo[m]>
I can think that someone perhaps wants to instrument how many frozen strings they made using freeze or something like that? Just feels obscure
<enebo[m]>
I would rather figure out another fun issue and just add a line to our list of things we don't support
<headius>
yeah tooling of some sort perhaps
<headius>
hey if you have another item I'm game
<headius>
maybe something 3.0
<headius>
I don't personally care if this ever gets "fixed" so something on the critical path would be cool
<puritylake[m]>
I'd be cool with that
<enebo[m]>
puritylake: do you have a specific interest in IR itself or just getting into JRuby?
<puritylake[m]>
Just getting into JRuby, I just liked the idea of looking into the IR but to be honest I don't mind the task
<puritylake[m]>
As long as I learn something
<puritylake[m]>
Been looking for a open source project to help out with, thought this one might be fun
<enebo[m]>
puritylake: We will find something fun. I am looking through IR issues a little bit
<enebo[m]>
puritylake: if you ever wanted to implement sprintf I made a start on it. This is more of a pure Java task to understand sprintf and make a runtime engine
<puritylake[m]>
That could be fun, is the use case more of a utility?
<puritylake[m]>
Oh, I was unaware sprintf was in Ruby, wow I feel dumb lol
<enebo[m]>
we have an implementation which needs to change but more importantly it is very difficult to add things like %p
<enebo[m]>
It has been a long time since I looked at this branch so I want to see how baked it is
<enebo[m]>
I think what I remember is I support %d through a new parser/execution set of code but then fail back to old impl if not that format
<enebo[m]>
but it is an interesting project because it is making a tiny parser and then making a small interpreter to build up the format string
<enebo[m]>
it also potentially could eventually compile but that is way out of scope
<puritylake[m]>
So, I can I work with java strings convert to jruby strings or should I work in jruby strings?
<puritylake[m]>
s/I//
<enebo[m]>
in this case it is all Ruby Strings which get reduced down to ByteList
<enebo[m]>
both the format string itself and the resulting string
<enebo[m]>
in JRuby a RubyString < RubyObject and has a ByteList field
<enebo[m]>
You can think of ByteList as a byte[] and an encoding
<enebo[m]>
but all the code is Java itself as it is internals
<puritylake[m]>
Ok, cool, I guess I could work on that for the time being
<enebo[m]>
puritylake: alright cool. Give me some time to dust this off and I will make a branch for you on jruby org site
<enebo[m]>
It may take until tomorrow as I have to run an errand but I may get it pushed this evening too
<enebo[m]>
we can talk about what it takes and we will be around to answer questions after you get rolling
<puritylake[m]>
No worries, I assume you are based in the west as it is 9pm here but if you ping me I'll try get back to you if you get it ready today
<enebo[m]>
oh yeah middle of US so it is still 15:22
<puritylake[m]>
Ireland on this end
<enebo[m]>
yeah I will let you know once I get it set up
<puritylake[m]>
👍️
<headius>
enebo perhaps we should close this issue as won't fix and just accept it is a incompatibility