<byteit101[m]> augh, it's back:
<byteit101[m]> /jruby/core/target/generated-sources/org/jruby/gen/org$jruby$ext$fiber$ThreadFiber$POPULATOR.java:[35,44] error: cannot find symbol
<byteit101[m]> [ERROR] symbol: class ThreadFiber$INVOKER$i$0$0$initialize
<byteit101[m]> using -pl core -pl shaded
razetime has joined #jruby
razetime has quit [Ping timeout: 265 seconds]
razetime has joined #jruby
razetime has quit [Ping timeout: 252 seconds]
razetime has joined #jruby
<byteit101[m]> success, PTY2.spawn works on jruby and mri (TruffleRuby not tested, but ffi, so I assume so)
<byteit101[m]> now onto the hard work: packaging...
<headius> Hot diggity
<headius> Try running the tests for io-console with your spawn in place
<byteit101[m]> I'm thinking gems for: the binary itself (if not using system), combined binary jar for jruby, ffi bindings, ffi wrapper, and then maybe a high-level api gem, in addition to the change in our pty.rb
<byteit101[m]> I haven't gotten there yet, this is all external to jruby right now :-)
<byteit101[m]> when travel allows, how do I add new builtin gems to jruby
<byteit101[m]> 4 or 5 gems! wow
<headius> It's pretty easy, look in lib/pom.rb
<headius> The pty spawn issues were the only remaining thing preventing us from passing io-console tests using our FFI impl of it
<headius> CRuby passes all tests with the FFI impl
<byteit101[m]> will try that
<byteit101[m]> hmm.. should I make a monorepo or 5 repos?
<headius> What are the 5 parts?
<byteit101[m]> > I'm thinking gems for: the binary itself (if not using system), combined binary jar for jruby, ffi bindings, ffi wrapper, and then maybe a high-level api gem, in addition to the change in our pty.rb
<byteit101[m]> ^
<byteit101[m]> how do I run io-console tests?
<byteit101[m]> oh in their repo, not jruby
<headius> Yes
<byteit101[m]> 5 parts are ^
<headius> Seems a bit much 😀
<headius> This is a more general question though. We have another case that's very similar, the crypt function that we only bind if libcrypt is available
<headius> In jnr-posix, I think enebo did the work on that way back when
<headius> More questions in this case though because libcrypt is usually available
<headius> And I think the way it worked was that if it is available we use it, otherwise we expect the crypt function to be in libc
<headius> So actually maybe that's not so different
<byteit101[m]> How on earth do these heredocs in io-console tests work? run_pty("#{<<~"begin;"}\n#{<<~'end;'}") do |r, w, _|
<headius> haha
<headius> it's a test
<byteit101[m]> sure, but I've never seen what to me looks like some sort of flip-flop heredoc
<headius> I got my lappy out because I was tired of typing on phone and I still have like two hours until my next flight
<headius> I think this "begin" and "end" trick is a way to make it still format like code
<headius> cleverly gross
<byteit101[m]> hmm... but it's still hanging
<headius> hanging?
<headius> I think it just failed outright when I used built-in spawn
<byteit101[m]> au contrair: "hanging" https://github.com/jruby/jruby/issues/6552
<headius> oh ok
<headius> oh right I see
<headius> been a minute since I messed with this library
<headius> still hanging, hmmm
<headius> I believe it was the setsid call but not 100% sure
<byteit101[m]> eval(r.gets) # ew, why not json.parse?
<headius> hah
<headius> these are old tests and this library has not changed much in a long time
<headius> I was pleased I got it to pass on CRuby with the FFI version at all
<headius> I'm too jetlagged to work on my talk so I'll have a look at your PRs
<byteit101[m]> selfishly :-)
<byteit101[m]> but I hope you get a good night sleep before your talk
<byteit101[m]> I saw enebo was doing some merging earlier too
<headius> yeah not speaking until Thursday
<headius> byteit101: does MRI define singleton methods for inspect too?
<headius> on the PTY results
<byteit101[m]> hmm, I didn't check
<byteit101[m]> I just assumed they properly set the file
<byteit101[m]> hence my asking about for_fd the other day
<headius> I don't see anything obvious yet
<byteit101[m]> slave_fptr->pathv = rb_obj_freeze(rb_str_new_cstr(slavename));
<byteit101[m]> yes, they set it correctly
<headius> yup just got there
<headius> and there's no way to set it from Ruby
<headius> well no standard way
<headius> what you have is probably fine for now but creating a singleton class is not cheap
<byteit101[m]> I did it as path was already a singleton class
<byteit101[m]> from freaky's impl
<headius> ahh sure
<headius> yeah so no harm really
<byteit101[m]> yes, hence my asking about sneaky for_fd
<headius> yeah now it makes sense
<headius> now that does seem like a good valid feature for Ruby
<byteit101[m]> I don't think so for pty (unless you are referring to the path search suggestion)
<byteit101[m]> I could move openpty into java
<headius> ah I just mean a way to set the path in for_fd
<byteit101[m]> but I love implementing ruby in ruby (sad rubiniuous noises)
<headius> I'm thinking of things Ruby could add to make this cleaner
<headius> yeah they just fall back on IO.for_fd but if called against File it will be a File object with a nil path
<headius> File.for_fd should take a filename argument
<headius> I wonder if there's any reason not to
<headius> it isn't like they do anything with that path other than for informational purposes
<headius> maybe reopen?
<headius> I see no such feature request
<byteit101[m]> actually, speaking of rubinious, what does/did it do for pty?
<headius> they might have just used the C ext
<headius> hard to know as the code is hard to locate now... all stdlib were removed to gems and then the gems were deleted
<headius> OSS ragequit
<byteit101[m]> rb_ivar_set(wport, rb_intern("@path"), rb_str_new2(SlaveName));
<byteit101[m]> yes
<headius> ooo neat...
<headius> seems like more justification for being able to provide a path
<headius> aha someone saved the repo
<byteit101[m]> I suppose we could File.open(slave_name, :rw)
<byteit101[m]> extra fd's all around
<byteit101[m]> but would work (not for master though
<headius> if they agree it is a good idea and can settle on a form, we could potentially just add it early and cheat a bit
<headius> I
<headius> I
<headius> ugh
<headius> I'll merge what you have since it works and does no harm right now
<headius> oh I realize now we'd want this for IO itself too
<headius> weird that this has never come up
<headius> frickin freezing in here...maybe it's this metal seat
<byteit101[m]> succumb to the inexorably increasing entropy of the universe
<byteit101[m]> I'm more interested in a ruby request for the process stuff, find path, etc
<headius> yeah this just seemed like a no-brainer
<headius> you might be able to explain the need for path searching better
<headius> it also seems like a good feature
<headius> enebo: in the back of my mind we must have considered omitting package modules but I can't remember a reason why we did not do it
<headius> I'm good with merging that in any case and we'll see if a reason presents itself
<byteit101[m]> how do I run just one method via rake?
<headius> just one test method? hmmm
<headius> I know you can run just one file with -n filename, probably using TESTOPT= for rake
<byteit101[m]> File does not exist: /test_cursor_position
<byteit101[m]> with -n on back and in options
<headius> is that a method name or filename
<byteit101[m]> test_cursor_position is a method name
<byteit101[m]> TESTOPTS="--verbose -n test_cursor_position" jruby -S rake test
<byteit101[m]> but -n is assuming filename
<byteit101[m]> I also tried TESTOPTS="--verbose test/io/console/test_io_console.rb -n test_cursor_position" jruby -S rake test
<byteit101[m]> same error
<headius> yeah I do not know the answer
<headius> byteit101: I assume that issue linked above is also fixed by your ObjectSpace tweak
<byteit101[m]> yup
<byteit101[m]> you can wait for IRB change to be 100% sure (I'd honestly like both to make it in)
<headius> ok
<headius> FWIW I found that method looking for other issues relating to each_object and package modules
<headius> could have sworn we had more
<byteit101[m]> ignoring 1 hang, I get 28 tests, 100 assertions, 1 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
<headius> nearly there
<byteit101[m]> What's jruby's underlying ruby_platform?
<byteit101[m]> ie linux, etc
<headius> RUBY_PLATFORM is always "java" but RbConfig::CONFIG["host_os"] should reflect actual OS
<byteit101[m]> excellent
<byteit101[m]> got a1 hang expecting not linux, and java is not linux :-)
<headius> there's been some debate about whether we could switch RUBY_PLATFORM to be actual OS but it is a scary change
<headius> aha yes
<headius> bad test but CRuby folks have resisted switching such things to host_os just for JRuby
<headius> hence the debate
<headius> I believe I can merge fixes
<byteit101[m]> JRUBY_PLATFORM? Then you could do JRUBY_PLATFORM ||RUBY_PLATFORM
<headius> they should probably be checking some RUBY_ENGINE or just use host_os
<headius> we originally used "java" because RubyGems used RUBY_PLATFORM to pick platform-specific gems
<byteit101[m]> no hangs!
<headius> and we wanted ours to be "java"
<headius> but they use something else now
<byteit101[m]> what on earth is test_noctty doing?
<byteit101[m]> (the one failure)
<headius> something about having no controlling tty I suppose
<headius> daemon process
<headius> yeah expects IO.console to be nil if there's no controlling terminal
<headius> we don't implement `daemon` because it needs fork so it must fall back on the "rubyw" logic
<byteit101[m]> Oh! Process.daemon not pty
<headius> yeah
<headius> yeah we just set RUBYW_INSTALL_NAME to "jruby" if not on Windows
<headius> so it just runs normal JRuby and fails because it does have a ctty
<headius> jrubyw/javaw starts as a background process on Windows but there's no equivalent for *nix command line
<headius> I suppose we could make a jrubyw that daemonizes but now I'm getting off track
<byteit101[m]> hmm, ok. I'll ignore that test for now then
<headius> yeah no good way to support that one currently
<headius> but if that's the only one that's great
<byteit101[m]> yup
<byteit101[m]> ok now to work on packaging and cleanup
<byteit101[m]> man, I've forked a lot of repos recently
<byteit101[m]> btw I'm going with monorepo for now
<headius> ok probably best until separate are needed
<byteit101[m]> I'm linking everything to https://github.com/jruby/jruby/issues/6552
<byteit101[m]> btw, if you have any thoughts on what to call the API or repo, I'm still pondering that. Current favorite is LFP::RawProcessBuilder and posix-process-builder
<headius> I'll think about it
<headius> looks like flight's starting to make moves, bl
<headius> bbl
<byteit101[m]> oh fun, take care
<byteit101[m]> https://github.com/byteit101/lfp-process-builder is my work-in-progress packaging. going to take a break and do other things the rest of today, but all the essential code is now there (if unpackaged)
razetime has quit [Ping timeout: 268 seconds]
sagax has quit [Remote host closed the connection]
sagax has joined #jruby
<headius> Cool. Waiting for my last connection now
<headius> enebo: I think we should hack the test/unit excludes system to allow multiple directories and possibly add an includes feature. I would really like to get the WIP tests from MRI suite isolated into a single run so we can better track regressions and things that already work
<headius> Like we did for the specs
<headius> Luckily I implemented the excludes feature so I think I have carte blanche to improve it as I see fit