<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 9.2.21.0
<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>
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
<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]>
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]>
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
<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]>
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