I had a quick look through the failures athttps://github.com/ruby/net-imap/actions/runs/14711726747/job/41285563407?pr=470

Failure: test_recursive_inspect(Net::IMAP::TestData)/home/runner/work/net-imap/net-imap/test/net/imap/test_data_lite.rb:180:in `test_recursive_inspect'     177:         # anonymous class     178:         list = klass[value: 1, tail: [2, 3, 4]]     179:         seen = "#<data #{klass.inspect}:...>"  => 180:         assert_equal(     181:           "#<data value=1, head=nil," \     182:           " tail=#<data value=2, head=#{seen}," \     183:           " tail=#<data value=3, head=#{seen}," \<internal:core> core/throw_catch.rb:36:in `catch'<internal:core> core/throw_catch.rb:36:in `catch'<"#<data value=1, head=nil, tail=#<data value=2, head=#<data #<Class:0x411e8>:...>, tail=#<data value=3, head=#<data #<Class:0x411e8>:...>, tail=#<data value=4, head=#<data #<Class:0x411e8>:...>, tail=nil>>>>"> expected but was<"#<data value=1, head=, tail=#<data value=2, head=#<data #<Class:0x411e8>:...>, tail=#<data value=3, head=#<data #<Class:0x411e8>:...>, tail=#<data value=4, head=#<data #<Class:0x411e8>:...>, tail=>>>>">

That looks like an issue of Data#inspect or #to_s in truffleruby not calling inspect on the values.
Buthttps://github.com/oracle/truffleruby/blob/ac88a0fe68bf957f75af7d316594b89731fdec4e/src/main/ruby/truffleruby/core/data.rb#L141-L152 seems to clearly callinspect on each value, so it's a mystery (unless something redefinesnil.inspect? I would hope not, but would be worth checking).
EDIT: it might be related to#470 (comment)
Indeed, and the actual difference is"%p" % nil is "" on TruffleRuby but "nil" on CRuby =>truffleruby/truffleruby#3846

For the other failures I don't see anything obvious, I think they'll need investigation with some debugging, I suggest to do that later and so omit these 9 failures for now.

Both JRuby and TruffleRuby still fail in various ways when inheriting from Data or Struct.

One thought I had given this gem is 3.1+ would be to use Struct (which exists since forever) instead of Data (+ freeze it, BTW thanks forthis issue, should be an easy quick fix).
Then you wouldn't need DataLite at all and wouldn't need to test that Data|DataLite work the same/good enough for the usage here.

But you're saying there are other issues with Struct too?

One thought I had given this gem is 3.1+ would be to use Struct (which exists since forever) instead of Data

That's fair. Idid consider going that route. But I also wanted the more constrained API of Data vs Struct.

I originally started down the path of building a facade over Struct. And then a switched from that to just a PORO. But the API I wanted turned out to be the Data-API. So in the end, I just used Data. And I'd already done much of the work for several features using Data... but I was waiting for v0.6.0 (which will require ruby > 3.2) before merging them.

FetchData is a good example of where theStruct API comes into direct conflict with the natural (Principle of Least Surprise) API for aFETCH response object:#[] should delegate toattr#[], and#size should delegate toattr["RFC822.SIZE"]. My long-term goal for many (not all) of the existing structs is to add deprecation warnings toStruct-specific methods for a couple of versions (i.e: a couple of years), then swap out their implementations forData or POROs.

So I was originally going to hold off on mergingany new data structures until v0.6.0, just to avoid these issues. But work priorities bumped up the schedule for#333 and#329, which were both features I'd already mostly completed on my own time, based onData. So I had to decide between 1) using a fork for ~18 months, 2) converting the objects toStruct, 3) converting the objects to a Struct-facade (probably just a subset of theData API, 4) converting to a PORO API subset, or 5) using aData polyfill which would only be used for one (now-EOL) version of ruby. 🤷🏻 (In the end we used a fork in production for almost three months before I merged and released everything.)

(+ freeze it, BTW thanks forthis issue, should be an easy quick fix).

great! 👍🏻

Then you wouldn't need DataLite at all and wouldn't need to test that Data|DataLite work the same/good enough for the usage here.

My intention has always been (see#352 (comment)) for v0.6.0 to deleteDataLite and setNet::IMAP::Data = ::Data. It only exists for 1) backwards compatibility with a single (now-EOL) version of ruby, and 2) YAML encoding. And the next release ofpsych will add YAML encoding:ruby/psych#692. 🎉

While working on this ticket, I briefly considered keeping it in v0.6.0, just for TruffleRuby and JRuby... but... I'm not gonna do that. 😉 I expect the JRuby and TruffleRuby bugfixes to come faster than my 0.6.0 release plans. 🙂

But you're saying there are other issues with Struct too?

Yep. If you don't get to it first, I'll open TruffleRuby issue for it later today. But the failingnet-imap tests are here:7fd8e2c.

And, to me, they seem very similar to the Data issues. My intuition may be completely wrong, but I would not be surprised if the fixes forData also fixStruct, or vice versa.

And, to me, they seem very similar to the Data issues. My intuition may be completely wrong, but I would not be surprised if the fixes forData also fixStruct, or vice versa.

On further investigation, I suspect the Struct issue is not inheritance related, but a difference in how Struct handles mixed positional and keyword arguments.

I createdtruffleruby/truffleruby#3855.

@eregon here's the issue I saw withIO#gets(CRLF, limit):

#!/usr/bin/env rubyputs ?=*72puts"Ruby Engine:#{RUBY_ENGINE}#{RUBY_ENGINE_VERSION}"require'bundler/inline'gemfiledogem"stringio",">= 3.1.7"endrequire"stringio"puts"Using StringIO#{StringIO::VERSION}"io=StringIO.new("123456789\r\n123456789\r\n")ppstringio:io.gets("\r\n",10)r,w=IO.pipew.write"123456789\r\n123456789\r\n"w.closeppio_pipe:r.gets("\r\n",10)__END__$ ruby test.rb && RBENV_VERSION=truffleruby-24.2.1 ruby test.rb========================================================================Ruby Engine:   ruby 3.4.2Using StringIO 3.1.7{stringio: "123456789\r"}{io_pipe: "123456789\r"}========================================================================Ruby Engine:   truffleruby 24.2.1Using StringIO 3.0.1{:stringio=>"123456789\r\n"}{:io_pipe=>"123456789\r"}

I didn't make a TruffleRuby ticket for this. I'm guessing this is already a known issue, given that it silently failed to use a newer version ofStringIO (even after I manually gem installed it). And it looks like it only affects the test which uses StringIO and probably doesn't affect real IO.

Thank you for reporting those and your work on adding TruffleRuby & JRuby in CI!

Using Struct was just a quick idea, thank you for the detailed reply, I didn't expect that much details but it's good context.
Yeah, if any of these objects is exposed publicly then it's a lot trickier to switch between both.

Re the StringIO issue, you are right, currently StringIO on TruffleRuby always usesour internal pure-Ruby implementation of it. But we should fix it to match the gem, so I created an issue from your comment:truffleruby/truffleruby#3856

All of the currently failing JRuby tests were passing for me locally. Oh well. Maybe it's some sort of race condition when callingSocket#close to shutdown the FakeServer.

But,IO#close shouldn't raise an exception due to "stream closed in another thread", should it? I thought that exception was only raised on threads that are blocked on the closed FD. If I'm reading the CRuby code correctly (that's avery big "if"),rb_io_close_m 1) first checks to see if it's already been closed, and 2) doesn't drop the GVL until after it's been closed (e.g:fptr_finalize_flush is called withKEEPGVL).

All the TruffleRuby issues are fixed now, excepttruffleruby/truffleruby#3858 where for AGE it's not currently planned to be fixed.
The CI on this PR is also already passing on TruffleRuby.
Could we maybe merge this (maybe after some cleanup as there is no need to detect working Data anymore) and not test on JRuby yet in CI since it's failing?

All the TruffleRuby issues are fixed now, exceptoracle/truffleruby#3858 where for AGE it's not currently planned to be fixed. The CI on this PR is also already passing on TruffleRuby.

Excellent! Great work. 🙂

Could we maybe merge this (maybe after some cleanup as there is no need to detect working Data anymore) and not test on JRuby yet in CI since it's failing?

Yes! I'll clean this up and merge it (or a subset of it) before the 0.5.9 release (sometime this week).

@eregon I did discover one more issue:truffleruby/truffleruby/issues/3892. I'd had tests for it already, but forgot about them when I was making test cases for the others.

Replaced by#528 and#529.

I still want to dropNet::IMAP::DataLite for 0.6.0, but maybe we'll keep a remnant of it around for TruffleRuby/JRuby compatibility.