<headius>
the next logical question for me is "what if you do `convert:` but not `instance_variable:`?" perhaps we bind the field without conversion logic, but do not set up the instance variable?
<headius>
`instance_variable: @foo` also looks good to me for choosing a name
<headius>
er `instance_variable: :@foo` or `instance_variable => :@foo`
<enebo[m]>
Also do we really need the @?
<enebo[m]>
Or can we have hidden ivars?
<headius>
Perhaps not? We are already saying "instance_variable" which implies "@"
<headius>
we can have hidden variables but it is meaningless from Ruby code since you can't access them
<enebo[m]>
In my brain seeing the @foo makes me wonder if I can :@@foo or :$foo
<headius>
`instance_variable_get` requires the @ so there's precedence
<enebo[m]>
ah yeah that's true
<enebo[m]>
but then can we get hidden ones without it?
<headius>
no it errors
<headius>
has to be a valid complete ivar name
<enebo[m]>
ah well I find that weird but that is a precedent so I think following convention makes sense
<headius>
yeah it seems unnecessary in `instance_variable_get` too, but that train has sailed
<enebo[m]>
It just looks like it introduced some question about how else I can specify an ivar
<enebo[m]>
to the point I am wondering it right now :)
<headius>
the @ is part of the name, not just a sigil like in perl
<enebo[m]>
So I remove that suggestion
<headius>
I guess it is both but it is what we put in the table as a key
<enebo[m]>
yeah I think that goes into a philosphical debate but perhaps they tried to decide that by making instance_variable_get require it
<enebo[m]>
Like, man, what is a name anyways? Does anyone really have a name?
<enebo[m]>
Having one keyword only be valid if in the presence of another keyword I think is also fine. We can just raise if you do it wrong. I suspect remembering 2-3 keywords args is simpler than remembering you need to embed a hash of keywords
<headius>
Names are like, just names man
<headius>
yeah if there is a valid case for only `convert` and not `instance_variable`, ok. If there's not, ok.
<headius>
it reads better than nested
<enebo[m]>
yep. agreed
<enebo[m]>
well I am getting closer to Marshal getting finished
<headius>
how much have you rewritten?
<enebo[m]>
There is a whole struct field missing which I think will detect recursion
<enebo[m]>
A lot but not all of it
<headius>
I am going to look over bug reports and then move on to strscan gem since that is needed by at least one net-* (not http)
<enebo[m]>
And what was rewritten was not massively different
<headius>
yeah good
<enebo[m]>
but it lines up more with MRI
<headius>
every time I have had to fix stuff in there I have tried to make it match CRuby marshal a bit closer
<enebo[m]>
I left main old method behind because I cannot tell if it is used by extensions
<headius>
automatic serialization really is just a mess in every language
<enebo[m]>
That is also a philosophical question
<headius>
probably good to leave it and deprecate for one major
<enebo[m]>
It is just interesting to realize the old method will still call into the new stuff
<enebo[m]>
without duplicating everything
<enebo[m]>
but they are close so it probably will work largely
<headius>
I tweeted to this @hiroysato on Twitter... he seems to be having issues (or is just annoyed by) trying to get latest JRuby and Embulk working together but I can't quite follow his tweets (jp translation)
<enebo[m]>
The new code handles I think some ordering issues (not solved yet) and recursion issue (not solved yet) but will just pick up stuff like ruby2_keywords toggles. Some prepend/extend differences, I add TYPE_DATA as a type we never had
<enebo[m]>
Also I can see we call proc more than we are supposed to
<headius>
yikes
<headius>
no wonder he's having issues upgrading JRuby
<enebo[m]>
So the number of things we fail always makes me wonder how much people exchange data between impls
<headius>
# TODO simplify
<headius>
hah markdown
<headius>
yeah we used to get a lot of bugs about marshal because it was used for Rails session and other stuff
marcheiligers[m] has quit [Quit: You have been kicked for being idle]
<headius>
but I dunno how much people use it anymore
<enebo[m]>
hahaha yikes is right
<enebo[m]>
I blame us not having good docs for this
<enebo[m]>
This looks like it is supposed to be ascii8bit right?
<enebo[m]>
I am surprised at a minimum that is not an issue
<headius>
I think it would be yes
<headius>
default encoding for ByteList is ASCII-8BIT
<enebo[m]>
oh I thought US-ASCII. ok then that is probably ok
<headius>
to be fair we don't have much plumbing for working with ByteBuffer which I assume is java_buffer here
<headius>
there's no ByteBuffer.to_s other than the inspect output
<headius>
could be added
<enebo[m]>
but if you are going to rip out a bytelist you may as well also reference on a better method internally
<enebo[m]>
Although in this case perhaps he is making best guess on replace always existing
<enebo[m]>
His gem will stop working in Ruby 3 no doubt
<enebo[m]>
Since all string operations internally will return String and no longer the subclass
<headius>
I did a pass over issues from the last couple weeks and pushed a couple PRs
<headius>
things seem to be moving along ok
<headius>
going to pivot to strscan this afternoon
<headius>
this one is surprisingly green so far but might be deferred until 9.4 since it changes how we calculate thread status (use native status unless it is a "runnable" status, and in that case use our internal status)
<headius>
3F10E on strscan tests and 2F2E on specs
<headius>
many of these seem to be the new allowance for either regexp or string
<headius>
enebo: I was thinking of doing a first pass to do mostly cleanup on this code, like adding ThreadContext and catching up with style changes we've made over time
<headius>
if this is going out into the world as an external library I think it should at least follow the patterns we prefer for extensions
<headius>
this is OLD code
<headius>
that said I'm not sure what pattern we prefer for existing methods that do not pass context
<headius>
this maintains compatibility but going forward you need to pass TC
<headius>
which may be fine for methods bound to Ruby, since I think we are in agreement we would rather those not be considered public API
<headius>
for methods that actually need TC it is clearly best to pass it, but for methods that just need runtime I am unsure
<enebo[m]>
I think we should potentially always just pass it
<enebo[m]>
It maybe is too dogmatic but the second a new Ruby comes out which says "call to_foo" or something like that then we will wish we used it
<headius>
yeah that's true
<enebo[m]>
The other one which is likely is if we want to raise an error but of course we don't care too much for non-static method impls there
<headius>
errors should only need runtime usually
<enebo[m]>
but for static with no args we will have no access to runtime
<headius>
it's mostly for ruby calls that we really want to have it
<enebo[m]>
I guess self
<headius>
or for anything thread-local of course
<enebo[m]>
still...I think it is more future proof
<headius>
like locking, thread state
<headius>
yeah it is
<enebo[m]>
I wish we had a single holistic view of all bound methods where we had all the same guarantees
<headius>
any thoughts on the third signature here unscan(Ruby)? I mainly added that so that the deprecated version would not have to acquire TC, but this is a newish pattern
<enebo[m]>
like TC and Block
<headius>
usually we just make the deprecated old signature acquire TC
<enebo[m]>
yeah
<enebo[m]>
I don't like Runtime over TC personally
<headius>
it won't matter from a user perspective since nobody should be calling these manually so maybe I am trying too hard
<enebo[m]>
Just because both can get each other but one is much cheaper and I like the view of the world that our methods care about the system from the thread they run on
<headius>
true
<enebo[m]>
I don't think we have made this mistake in a long time but there has been a few cases where someone thought they could just save off TC and it was just not really getting how all this fits together. Passing it in all the time means just realizing you can use it because it is always there
<headius>
yeah
<headius>
ok I will just add the TC signature
<headius>
FWIW most of these String/Regexp errors are all the same change, since most methods just backend on scan()
<headius>
I will get all specs and tests green and then finish up the PR for that gem
<headius>
hopefully this will go quickly
<headius>
yeah I assumed it was largely deprecated but I think net-imap or one of the other non-http net libraries uses it
<headius>
and we have never really done much work to optimize this
<headius>
if I see anything obvious I will do it
<headius>
yeah
<headius>
tmp = rb_str_new2("$Id$");
<headius>
this thing is not well-maintained even in CRuby
<headius>
"$Id$"
<headius>
$ rvm ruby-3.1 do ruby -rstrscan -e 'p StringScanner::Id'
<headius>
🙄
<headius>
ours is "$Id: strscan.c 13506 2007-09-24 08:56:24Z nobu $"
<headius>
guess that tells you how old this code is in JRUby
<headius>
yeah really not useful to have this anymore
<headius>
has not been processed by svn or cvs in a long time
nilsding has quit [*.net *.split]
ssaschaa[m] has quit [*.net *.split]
enebo[m] has quit [*.net *.split]
ahorek[m] has quit [*.net *.split]
nilsding has joined #jruby
ahorek[m] has joined #jruby
ssaschaa[m] has joined #jruby
enebo[m] has joined #jruby
daveg_lookout[m] has quit [Ping timeout: 245 seconds]
byteit101[m] has quit [Ping timeout: 245 seconds]
katafrakt[m] has quit [Ping timeout: 245 seconds]
mattpatt[m] has quit [Ping timeout: 245 seconds]
rebelwarrior[m] has quit [Ping timeout: 245 seconds]
MateuszFryc[m] has quit [Ping timeout: 250 seconds]
kroth_lookout[m] has quit [Ping timeout: 250 seconds]
AndyMaleh[m] has quit [Ping timeout: 250 seconds]
puritylake[m] has quit [Ping timeout: 240 seconds]
kovyrin[m] has quit [Ping timeout: 240 seconds]
klobuczek[m] has quit [Ping timeout: 250 seconds]
basshelal[m] has quit [Ping timeout: 240 seconds]
MattWelke[m] has quit [Ping timeout: 240 seconds]
oblutak[m] has quit [Ping timeout: 240 seconds]
bensheldon[m] has quit [Ping timeout: 240 seconds]
headius has quit [Ping timeout: 256 seconds]
Albertico[m] has quit [Ping timeout: 256 seconds]
kares[m] has quit [Ping timeout: 252 seconds]
lopex[m] has quit [Ping timeout: 252 seconds]
rdubya[m] has quit [Ping timeout: 252 seconds]
jtarvydas[m] has quit [Ping timeout: 268 seconds]
nilsding has quit [Ping timeout: 260 seconds]
enebo[m] has quit [Ping timeout: 260 seconds]
ahorek[m] has quit [Ping timeout: 260 seconds]
ssaschaa[m] has quit [Ping timeout: 260 seconds]
bensheldon[m] has joined #jruby
MattWelke[m] has joined #jruby
oblutak[m] has joined #jruby
basshelal[m] has joined #jruby
jtarvydas[m] has joined #jruby
MateuszFryc[m] has joined #jruby
AndyMaleh[m] has joined #jruby
kroth_lookout[m] has joined #jruby
puritylake[m] has joined #jruby
klobuczek[m] has joined #jruby
katafrakt[m] has joined #jruby
byteit101[m] has joined #jruby
rebelwarrior[m] has joined #jruby
rdubya[m] has joined #jruby
kares[m] has joined #jruby
mattpatt[m] has joined #jruby
Albertico[m] has joined #jruby
headius has joined #jruby
kovyrin[m] has joined #jruby
daveg_lookout[m] has joined #jruby
lopex[m] has joined #jruby
nilsding has joined #jruby
ahorek[m] has joined #jruby
enebo[m] has joined #jruby
ssaschaa[m] has joined #jruby
<headius>
3F1E
mattpatt[m] has quit [Remote host closed the connection]
kroth_lookout[m] has quit [Read error: Connection reset by peer]
ahorek[m] has quit [Remote host closed the connection]
Albertico[m] has quit [Read error: Connection reset by peer]
enebo[m] has quit [Read error: Connection reset by peer]
kares[m] has quit [Read error: Connection reset by peer]
AndyMaleh[m] has quit [Read error: Connection reset by peer]
bensheldon[m] has quit [Read error: Connection reset by peer]
headius has quit [Read error: Connection reset by peer]
nilsding has quit [Read error: Connection reset by peer]
rebelwarrior[m] has quit [Remote host closed the connection]
daveg_lookout[m] has quit [Remote host closed the connection]
katafrakt[m] has quit [Remote host closed the connection]
klobuczek[m] has quit [Remote host closed the connection]
lopex[m] has quit [Read error: Connection reset by peer]
MateuszFryc[m] has quit [Read error: Connection reset by peer]
rdubya[m] has quit [Read error: Connection reset by peer]
byteit101[m] has quit [Remote host closed the connection]
puritylake[m] has quit [Read error: Connection reset by peer]
oblutak[m] has quit [Read error: Connection reset by peer]
basshelal[m] has quit [Read error: Connection reset by peer]
kovyrin[m] has quit [Remote host closed the connection]
ssaschaa[m] has quit [Read error: Connection reset by peer]
MattWelke[m] has quit [Read error: Connection reset by peer]
jtarvydas[m] has quit [Read error: Connection reset by peer]
ahorek[m] has joined #jruby
enebo[m] has joined #jruby
lopex[m] has joined #jruby
subbu[m] has joined #jruby
andrea[m] has joined #jruby
byteit101[m] has joined #jruby
katafrakt[m] has joined #jruby
kares[m] has joined #jruby
AndyMaleh[m] has joined #jruby
rebelwarrior[m] has joined #jruby
puritylake[m] has joined #jruby
oblutak[m] has joined #jruby
basshelal[m] has joined #jruby
rdubya[m] has joined #jruby
MateuszFryc[m] has joined #jruby
kovyrin[m] has joined #jruby
ssaschaa[m] has joined #jruby
Albertico[m] has joined #jruby
klobuczek[m] has joined #jruby
bensheldon[m] has joined #jruby
mattpatt[m] has joined #jruby
MattWelke[m] has joined #jruby
headius has joined #jruby
daveg_lookout[m] has joined #jruby
jtarvydas[m] has joined #jruby
nilsding has joined #jruby
kroth_lookout[m] has joined #jruby
andrea[m] has quit [Quit: You have been kicked for being idle]
<headius>
huzzah, 0F0E
<headius>
most of it was adding fixed_anchor support
<enebo[m]>
sweet
<headius>
test:mri:stdlib is not running on master right now