ivy31 has joined #jruby
ivy31 has quit [Quit: Client closed]
<kares[m]> have opened the jossl update against jruby-9.2 and tagged it for https://github.com/jruby/jruby/pull/6909
<kares[m]> the pre was out for a few days and users did not report anything problematic, there's also a flag to force the legacy cert verification path ...
<kares[m]> but I will have no hard feelings if this is seen risky and postponed till
<headius> That seems pretty good to me then
<enebo[m]> kares: jruby-openssl is gem installable so people can back off to an older version if the workaround env is not enough?
<kares[m]> yes - should be. there were issue due it being a default gem, I am actually not sure if that is still the case ...
<enebo[m]> kares: The ability to downgrade with gem install is a factor in .20 or .21 but not really the only factor since multiple people are saying they are stuck without it
<enebo[m]> since you have an env to essentially backoff that also makes it more appealing to get in sooner than later
<headius> enebo: I am fixing the versioning issue with asm but I notice a lot of warnings in this build about overlapping classes: https://app.travis-ci.com/github/jruby/jruby/jobs/545051687
<headius> seems like there's some double-shading going on or something
<headius> for example
<headius> jruby-jars-
<headius> I think I see the problem here
<headius> you updated all the versions to SHAPSHOT
<headius> easy fix is easy
<headius> funny none of us noticed this
<enebo[m]> HAHAHAH
<enebo[m]> headius: OMG
<enebo[m]> h is by n but I am so use to the pattern of chars I just must have mentally glossed over it
<headius> yeah I didn't notice it looking at it several times
<headius> finally went up to look at the jruby-jars filename and read it piece by piece to see if it matched
<enebo[m]> SHAP SHOT
<enebo[m]> HAHAH I am still laughing
<enebo[m]> It could have only been a better mispelling if it was SLAPSHOT
<enebo[m]> Although I would have noticed that one
<headius> your SNAPSHOT update turned out to be a shapshot
<enebo[m]> shapshot is not actually a bad name for dev cycle software
<enebo[m]> perhaps we should ask maven to allow it
<headius> yeah I don't know whether SNAPSHOT is enforced or just de facto
<enebo[m]> release plugin can do the auto naming
<headius> that's true
<enebo[m]> so there is at least something to it and sonatype also accepts the convention but that is probably just de facto
<headius> kares: I would just go ahead and optimistically close those issues you tagged re: cert verification
<edipofederle[m]> Guys, I'm facing problems to figure out how I can write equivalent code inside Jruby/Java: https://gist.github.com/edipofederle/6db4c057cd15ec720b0d697f0476a929 some advise? I try to look already into ShellLauncher, RubyIO and PopenExecutor but not sure how to pass that block, for example
<headius> mark for 9.2.20 since we will update jossl there and we can't have multiple milestones on an issue
<headius> edipo.federle: like, trying to write this code in Java? The block is really just convenience for opening the pipe, making some calls against it, and closing it (ensured/finallyed)
<headius> or do you actually need to pass a Ruby block in Java?
<edipofederle[m]> headius: no, block is not required, if same result
<headius> ok if you have launched a process then it just would want a try/finally to close it down with this sort of logic in the body of the catch
<headius> that's really all it does in Ruby
<headius> it is also possible to make a Block from arbitrary Java code and pass that to e.g. RubyIO.popen but if you look in popen there's not much to the block logic
<edipofederle[m]> Let me try so,
<headius> edipo.federle: you should rebase this and eliminate the version changes: https://github.com/jruby/jruby/pull/6907
<headius> also, are we not running the command line specs? I'm confused why we need this tag when we are green
<headius> ugh, we are not!
<headius> edipo.federle: nevermind that... I will add command line specs to the slow run and tag everything that fails
<headius> oh nevermind we do run it in slow
<headius> so I am back to confused about why we need the tag
<edipofederle[m]> ah, please, this PR can be ignore, I will close it now.
<headius> easy peasy
<edipofederle[m]> closed,
<edipofederle[m]> <headius> "ok if you have launched a..." <- here you mean something like: `ShellLauncher.popen(runtime, "LESS", newIOOptions(runtime, 0).getModeFlags());` ?
<headius> edipo.federle: maybe if you tell me what you are doing I can help better... there are several ways to launch a process
<edipofederle[m]> Sure, I am trying to use open here: https://github.com/jruby/jruby/pull/6902#discussion_r735888554
<edipofederle[m]> for send help usage string to PAGER (for example. `less).
<edipofederle[m]> From Plain Ruby, I can follow this approach: https://github.com/jruby/jruby/pull/6902#discussion_r735888554
<edipofederle[m]> ops
<edipofederle[m]> s/From Plain Ruby, I can follow this approach: https://github.com/jruby/jruby/pull/6902#discussion_r735888554/From Plain Ruby, I can follow this approachhttps://gist.github.com/edipofederle/6db4c057cd15ec720b0d697f0476a929/
<edipofederle[m]> So, I am trying to achieve the same
<edipofederle[m]> s/open/popen/
<enebo[m]> ruby help output in Ruby 3 will pipe to whatever PAGER or RUBY_PAGER specifies. So he wants to exec, for example, less and then send our help to its stdin
<enebo[m]> which I think it just a ProcessBuilder with getOutputStream() to get that processes stdin
<enebo[m]> Just to catch headius up because this is before runtime is defined it is easier to just use ProcessBuilder
<edipofederle[m]> I can create a runtime with: Ruby runtime = Ruby.newInstance(config);, right?
<headius> ah tricky
<enebo[m]> Is there an issue with ProcessBuilder? This does not seem like it would be a lot of code
<headius> so this is a new general feature for long output from flags and since it happens before we launch JRuby itself we need a pure Java option
<enebo[m]> My first thought was to leverage popen logic we have but this is just exec + grabbing the stdin of what you are spawning
<edipofederle[m]> enebo[m]: I cannot make it works without have the "bash" thing, as you notice on the PR...
<headius> this will be a little tricky because subprocess launching from Java does not work well at all with things like `less`
<enebo[m]> edipo.federle: I notice you keep using 'LESS' that is not a unix command
<enebo[m]> Is that maybe a builtin in bash?
<headius> less wants to take over the terminal but Java process logic manually "pumps" the in/out/err streams so they look like they are always empty
<edipofederle[m]> enebo[m]: this in temp, I will remove it, and read from ENV
<enebo[m]> ah
<enebo[m]> ah to both of you I guess
<enebo[m]> headius: so ProcessBuilder actually lacks the ability to interact with something needing a terminal?
<enebo[m]> That feels pretty limiting :)
<edipofederle[m]> Another think, quiick, and ugly, but works in Unix and Win, is to make a temp file with content from Help, and just pass it to the PAGER command
<headius> I think you can get some of the way by using ProcessBuilder and setting all streams to be inherited, but we actually want to pipe err to the input of `less`
<enebo[m]> edipo.federle: yeah I guess that would mostly work but gdepending on PAGER it will show the file name in some cases
<enebo[m]> Feels really like MRI devs were bored on this feature
<headius> ProcessBuilder provides no way to pipe one stream to another
<edipofederle[m]> enebo[m]: exactly, the file name is present, at least until you page up/down
<headius> it might be simpler to pump the entire output to a `less` that we exec
<headius> we know we are exiting always right?
<enebo[m]> I am confused about the err part of this
<enebo[m]> we control the messages we want to send as strings don't we?
<enebo[m]> This is only for putputting help
<enebo[m]> Or does it do more?
<edipofederle[m]> just for help
<enebo[m]> Can't we just writeAll on the getOutputStream of the new process
<headius> wow, nobu must have written this code
<enebo[m]> hahah
<enebo[m]> I sort of see the convience of this but it is hardly the unix way
<headius> const char *const progname =
<headius> origarg.argc > 0 && origarg.argv && origarg.argv[0] ? origarg.argv[0] :
<headius> ruby_engine);
<headius> (argc > 0 && argv && argv[0] ? argv[0] :
<headius> I mean really
<enebo[m]> I wonder which system has argv[0] be NULL?
<enebo[m]> I mean besides someone doing it in C after it has started
<enebo[m]> I may be assuming too much about what those two values are from
<edipofederle[m]> enebo[m]: need to check/try.
<enebo[m]> edipo.federle: you mean you need to see how much got written and pump the data and combined with what headius said there is an issue with talking to tty processes
<enebo[m]> Another mechanism would be to just use our POSIX subsystem
<headius> ok so CRuby just launches or fork/exec's the pager and then calls its logic to write help to that process's input (as a tty)
<headius> so they change the target of the write to be the subprocess
<enebo[m]> yeah
<enebo[m]> it appears to just write help to whatever PAGER/RUBY_PAGER may be set to
<enebo[m]> if nothing it just prints out
<headius> yeah
<enebo[m]> I also like that it sets LESS to
<enebo[m]> "-R"
<headius> I think this is doable with processbuilder
<headius> you would want to set it to inherit err and out and then write the help to its stdin
<enebo[m]> which I think is just getOutputStream on that process
<edipofederle[m]> I see, well guys, I will try in that way.
<headius> so redirectOutput and redirectErr should be INHERIT
<edipofederle[m]> yes, right now I;m using: builder.redirectOutput(ProcessBuilder.Redirect.INHERIT);
<enebo[m]> oh you are saying you do not maybe even need that
<enebo[m]> you just print and it will pick it up because it inherits
<headius> default for in is PIPE so that should be fine... get the subprocess stdin and write+flush+close+waitFor
<headius> you still need to actually write it to the input of the subprocess though
<headius> so that may need changes to our help output
<headius> (just passing a stream in though)
<headius> edipo.federle: I think you are on the right track
<headius> once you close the input I believe it should be reflected on `less` and it will do paging and then terminate
<headius> terminal control is a big open question but this should work well enough for now
<edipofederle[m]> great, thx a lot for the help guys
<headius> you wouldn't be able to do this with `vim` for example because it needs a lot of tty control
<headius> but less may be ok
<headius> in any case I would try this and if it doesn't work we can go deeper
<headius> enebo: I have not managed to get far with the M1 issues... untangling the variadic logic in jnr-ffi has been challenging
<headius> I need to take a new approach and move the variadic logic from jnr-ffi into jffi and then start replacing it with the correct FFI calls from there I think
<headius> for review... jnr-ffi manually does varargs set-up using native heap memory but M1 varargs uses a mix of stack and heap and so we lose args
<headius> the right way to do this is to always use the ffi functions for setting up varargs calls, which will do it right on current platform... but I have to push this endpoint logic down from jnr-ffi into the native lib in jffi
<headius> I have considered sending wmeissner an email
<headius> he could fix this in a day
<headius> I'm going to do a round of jnr releases to pick up recent minor fixes and land a few in-progress PRs on the jruby end
<enebo[m]> heh
<enebo[m]> hit up wayne...Maybe he will come back into the game
<headius> won't know if we don't try
<enebo[m]> It has been a long time since his retirement
<headius> sent
<basshelal[m]> That would be awesome if we could get his clarification or help on some things, struct by value support comes to mind
<basshelal[m]> Thanks for the merges headius 😁
<headius> for sure we could use some help
<headius> ok I think I have all relevant things merged and closed in jnr-*
<headius> basshelal: if you see anything I missed let me know... gonna grab some lunch here
<headius> ok releases are happening
<puritylake[m]> enebo: I realise how to fix one of the errors, seems I forgot the case where I could call to_str which one of the specs complains if it doesn't get called
<puritylake[m]> Actual that is both in the call log you sent me
danieljrubyquest has joined #jruby
<headius> enebo: update jnr in 9.3 or 9.2?
<headius> mostly small fixes, additional constants (syslog, sockets), s390x binary
<puritylake[m]> s/Actual/Actually/
<danieljrubyquest> :wave: Hi all! I'm attempting to upgrade from `jruby-` to `jruby-`, but am seeing a new NoMethodError when calling `map` on a Java list:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/604fb3592a378d5eeadfe19ebc2f0ca1e62e8bd1)
<headius> hmmm
<headius> it should be picking up map from Ruby Enumerable, which we mix into Java Collection (or List)
<headius> could you print out `obj.class.ancestors` where obj is the result of `getFields`?
<headius> kares: I see a jruby-openssl gem artifact in sonatype staging
<headius> 0.11
<headius> do we release the gem on maven?
<headius> enebo: I did the PR against 9.3
<headius> oops, I meant 9.2
<enebo[m]> sorry was doing a couple of errands
<headius> No problem
<headius> That PR probably won't be green due to Maven lag but jnr stuff is released
<headius> I couldn't think of a good reason not to do it against 9.2
<enebo[m]> headius:can you restart your ci run on your PR
<enebo[m]> headius: I think the only fear I have in it are the jnr-constant fixes
<enebo[m]> headius: but I am game
<enebo[m]> all the jobs on travis failed
<enebo[m]> puritylake: cool. fix_printf is completely green now too
<headius> The constant fixes were mostly additions so I don't think they're likely to hurt anything
<headius> I will restart the pr ci in a while but Travis tends to get stuck with stale versions sometimes
<enebo[m]> puritylake: if you fixed those two be sure to push them to that branch you made the PR on
<enebo[m]> headius: I just saw some renaming like Inet to INet but those perhaps are just internal to the library
<puritylake[m]> Not quite yet, running the test locally more errors cropped up the spec fast one
<puritylake[m]> They are to do with String#% fails
<headius> That was fixing a bad class name on Windows, it failed to load because it was wrong
<headius> And I think that is all still part of the added socket constants that weren't there before
<enebo[m]> ok
<enebo[m]> puritylake: if you merge your branch with HEAD of fix_sprintf you should see completely green run
<enebo[m]> puritylake: unless it is a bug with %cC you are seeing in format
<enebo[m]> I fixed some problems a couple of days ago with format
<puritylake[m]> Ok one sec
<enebo[m]> I now also realize I need to change the parser a little bit. I tried to get away with all modifier parsing in one method and I should make methods for width and precision as their own parse methods
<enebo[m]> That realization becomes way more obvious as I started fixing esoteric error messages that we never passed. I keep adding more and more if statements with boolean toggles. Not a good pattern once you have multiple ones
<headius> enebo: restarted
<edipofederle[m]> This is the correct way to set a ENV variable: `posix.setenv(keyAsJava, valueAsJava, 1);` ?
<puritylake[m]> enebo: is fix_sprintf a new branch?
<enebo[m]> puritylake: sorry I meant the branch we are working on
<enebo[m]> new_sprintf
<puritylake[m]> Ah cool, seem to be at HEAD already, just rerunning the tests due to a technical hiccup in the command I ran with git
<puritylake[m]> I'll let you know the tests that are failing as soon as they are done
<puritylake[m]> Some of the fails are the ones you mentioned would fail if the environment wasn't set up right but the ones I refer to regard sprintf
<enebo[m]> puritylake: I am apparently eating an early dinner :) I will stop back afterwards but there is not really any time pressure.
<puritylake[m]> No worries, enjoy
<enebo[m]> edipo.federle: ProcessBuilder.environment() will return a map you can change values before executing the process
<edipofederle[m]> ah, so, just change the map directly?
<enebo[m]> posix.setenv will work but only when native support is enabled (which probably is not important here).
<enebo[m]> yeah I believe so
<edipofederle[m]> nice
<edipofederle[m]> thx!
<enebo[m]> np
<enebo[m]> bbiab
<danieljrubyquest> <headius> "could you print out `obj.class...." <- Sure! I'm seeing this:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/2a0dd7fb7de3e822f399eab1c89b4ca88b7955b5)
<puritylake[m]> Ok fails seem to be gone, did a quick push
<enebo[m]> puritylake: yeah watching it run in a tab :)
<puritylake[m]> Awesome, hopefully can get to work on the next specifier if this passes
<enebo[m]> I see some others also failed too. Looks like something with zero padding broke
<puritylake[m]> Oh boy
<enebo[m]> heh
<enebo[m]> well assuming your merge did not undo something in the parser I would think it would mostly be %c sorts of things
<enebo[m]> I do also see in ruby/spec run that one of those mocks are not calling something (which I think was the last thing you said you fixed)
<puritylake[m]> The tests had stopped failing, I'll have another look
<puritylake[m]> Zero padding seems to be a problem with %d
<puritylake[m]> I must have messed up that code somehow
<puritylake[m]> Maybe I messed with the merging conflicts
<enebo[m]> I see you did a force push too?
<puritylake[m]> Did I?
<enebo[m]> well maybe you didn't. The PR says the merge conflicts commit was force push but perhaps I don't get something
<enebo[m]> I never notice comments like that until there is a problem :)
<puritylake[m]> I could have, my memory in the short term can be unreliable
<enebo[m]> you could create a new branch off of HEAD and git cherry-pick the 4 commits you made for this original PR
<enebo[m]> err 3 commits
<enebo[m]> then submit a new PR
<enebo[m]> that would eliminate the merge and HEAD ran green on travis
<puritylake[m]> Haven't heard of cherry-picking in git
<enebo[m]> yeah it is really useful. It just takes a specific commit and commits onto your current branches HEAD (and no doubt you can specify where you want it committed)
<enebo[m]> I alias it to 'git cp' and will use it when I just want to move a commit from mainline development back to an older support branch
<enebo[m]> I am thinking if zero padding for %d is broken something went wrong in the merge so it is simpler to just start a new branch and cp your commits there
<enebo[m]> unless any of your 3 commits hit the parser and changes how zero padding works
<puritylake[m]> I think I know where I went wrong, is it possible to revert the changes I push from the PR? I know off the top of my head what I did to fix MY code
<puritylake[m]> I remember seeing code you wrote in format_d* I think I overwrote it in a merge
<enebo[m]> well there are two ways but I dislike both of them
<enebo[m]> 1 is to git revert which will make a big commit which undoes the commit. I think this is probably weirder output-wise for merge commits
<enebo[m]> 2. is to use git reset --hard HEAD^ which would nuke the last commit and the force push to the PR
<enebo[m]> This is good for really removing stuff but it is about as dangerous as you might think it is so you need to be careful
<puritylake[m]> Option 2 doesn't seem good
<puritylake[m]> Well for this case
<enebo[m]> The advantage of 1 is nothing is destroyed but you add more noise to history. number 2 has no noise but you need to be confident
<puritylake[m]> Ok, I'll learn to cherry pick
<enebo[m]> I locally do #2 and there is a syntax for deleting n commits when I realize I just booched what I was working on
<enebo[m]> Or sometimes I do it to do pre-release testing because I will commit version number as a commit. When I am done I just hard head kill that commit because it is not release time
<enebo[m]> (our build system requires the version to be committed which is why I need to do the commit)
<enebo[m]> I should say I have used git for years and still feel I am not very good at git
<enebo[m]> So someone may come along and lay the smack down on my suggestions but a new brajc and 3 cps will make a much smaller PR
<enebo[m]> you actually have merged twice too and now it will be 0
<puritylake[m]> So on the new branch I checkout upstream's head? Then cherry pick my commits?
<enebo[m]> you git checkout new_sprintf; git pull (to make sure you at HEAD); git branch my_pr_branch; git checkout my_pr_branch; git cherry-pick {commit_hash} ...;
<enebo[m]> then push to your fork and then go over to github and it will say you can open a PR at the top for that last commit
<enebo[m]> Actually it will be in the text of the push too
<puritylake[m]> My brain is like goo right now trying to fix this mess lol
<enebo[m]> yeah this is not so bad. but if you are tired it may be easier tomorrow :)
<enebo[m]> people redo PRs all the time too
<puritylake[m]> I'm tempted to drop my PR, copy and paste only my pieces of code and pushing it again lol
<puritylake[m]> The changes I made are very close to each other
<puritylake[m]> And I haven't done a huge amount
<enebo[m]> well that is also valid since you made changes between commits
<enebo[m]> some projects ask people to squash commits so that if we later want to use git bisect we do not bisect into a commit which breaks stuff
<enebo[m]> we don't ask that but there is a virtue to it
<puritylake[m]> I think I'll do that, gimme a moment