Allow non-power-of-two enums

Fixes #3.
This supports non power of two enums more or less how they're specified in 06-enums. The return value is an Result<T, EnumError> where EnumError has a single variant UnrecognizedValue. Enums are limited to 32 bits just to make the error type easier.
This PR also splits the Face type on the Specifier trait into a GetterReturn type which specifies the type returned by a getter. For most types it's equivalent to the Face type.
I screwed up some of the commits in a merge, but squashed they're good - I can squash them or tease out the Face/GetterReturn split changes into a separate commit. (hence why I haven't autosquashed yet)
There is no way to set a raw value. I was imagining an API like:
my_struct.set_small_prime_raw(9); // Maybe even unsafe?
let my_struct = my_struct.with_small_prime_raw(9);

but I think that would require _raw methods for every field, not just enum fields. Which is fine it's just more methods/compile time.

Wow, this is really cool! Thanks a lot for this. :rocket:
I quickly glimpsed over the diff and all in all it looks good, however, I am going to need to review it properly later.
It would be especially nice, if you could add some more tests to cover for the new functionality in particular.

Note that with this PR the current codegen for our new constructor for the generated bitfield structs might invoke undefined behaviour since it is no longer guaranteed that the zero bit pattern is actually supported by all bitfields as described here:
https://github.com/Robbepop/modular-bitfield/issues/27#issue-724066122
Before merging this PR we have to find a solution to this issue.

might invoke undefined behaviour

Is it undefined? It's certainly not good behaviour, but as far as I can tell it's fairly well defined (in particular, trying to get an enum field from a ::new()'d struct will return an error, which is weird.)

might invoke undefined behaviour

Is it undefined? It's certainly not good behaviour, but as far as I can tell it's fairly well defined (in particular, trying to get an enum field from a ::new()'d struct will return an error, which is weird.)

Yes you are actually right about this since we handle the erroneous case in our getters. I wonder though if we actually do need this error handling at all if we on the other handside could make sure that those states are never representable in the first place (without serious usage of unsafe).

I wonder though if we actually do need this error handling at all if we on the other handside could make sure that those states are never representable in the first place

In my mind, there's two things a user might want to do: Converting from convenient Rust data structures into packed bitfields, and reading from packed bitfields into convenient Rust data structures. For anyone interacting with hardware (e.g. reading registers), they necessarily are receiving data from "untrusted" sources, or at least sources that we can't control. Something like:
loop {
    let reg = read_reg(0x1234);
    let reg = unsafe { MyReg::from_bytes_unchecked(reg as bytes) };
    match reg.state()? {
        MyRegState::Running => { break; },
        MyRegState::Error => { return Err("State machine encountered error starting!"); },
        MyRegState::Starting => { /* noop */ },
    }
}

from_bytes_unchecked is already unsafe, but if we make it so that get()ing an unrecognized enum variant panics, then I need to separately check whether the incoming value is valid:
     let reg = read_reg(0x1234);
+    if (reg >> 5) & 0x3 == 0x3 {
+        return Err("Received invalid field!");
+    }
     let reg = unsafe { MyReg::from_bytes_unchecked(reg as bytes) };

An alternative might be that the constructor does the check and returns an error, but that introduces two problems - One is that, in the above code, constructing reg might fail for an enum that I don't even care about (here I only read the state() field, and there could be many fields). The other is that I may still care about the raw value, probably so I can report it to the developer ("got unrecognized register status 0x3!").
So I think we definitely want to be able to get into a situation where the bitfield object contains an "invalid" state.
One downside of returning errors from getters is that sloppy users will do things like this:
     match reg.state() {
         Ok(MyRegState::Running) => { break; },
         Ok(MyRegState::Error) => { return Err("State machine encountered error starting!"); },
         Ok(MyRegState::Starting) => { /* noop */ },
+        Err(modular_bitfield::EnumError(UnrecognizedValue(3))) => { /* I'm too lazy to update the struct itself but I need to handle this case */ }
         _ => { /* Now is never hit... until someone updates the struct! */ }
     }

which I think is an argument for getters not returning errors even if #[returns_result] is specified with 2**bits number of variants. My argument against it was just it's inconvenient if they have to refactor lots of code, but maybe it's worth it to force the user to audit their matches. I almost wish we had compile_warning!, then we could do the "this will compile fine so you can run your code, but if you want to submit it to your CI you should really fix this" thing.

I wonder though if we actually do need this error handling at all if we on the other handside could make sure that those states are never representable in the first place

In my mind, there's two things a user might want to do: Converting from convenient Rust data structures into packed bitfields, and reading from packed bitfields into convenient Rust data structures. For anyone interacting with hardware (e.g. reading registers), they necessarily are receiving data from "untrusted" sources, or at least sources that we can't control. Something like:
loop {
    let reg = read_reg(0x1234);
    let reg = unsafe { MyReg::from_bytes_unchecked(reg as bytes) };
    match reg.state()? {
        MyRegState::Running => { break; },
        MyRegState::Error => { return Err("State machine encountered error starting!"); },
        MyRegState::Starting => { /* noop */ },
    }
}

from_bytes_unchecked is already unsafe, but if we make it so that get()ing an unrecognized enum variant panics, then I need to separately check whether the incoming value is valid:
     let reg = read_reg(0x1234);
+    if (reg >> 5) & 0x3 == 0x3 {
+        return Err("Received invalid field!");
+    }
     let reg = unsafe { MyReg::from_bytes_unchecked(reg as bytes) };

An alternative might be that the constructor does the check and returns an error, but that introduces two problems - One is that, in the above code, constructing reg might fail for an enum that I don't even care about (here I only read the state() field, and there could be many fields). The other is that I may still care about the raw value, probably so I can report it to the developer ("got unrecognized register status 0x3!").
So I think we definitely want to be able to get into a situation where the bitfield object contains an "invalid" state.
One downside of returning errors from getters is that sloppy users will do things like this:
     match reg.state() {
         Ok(MyRegState::Running) => { break; },
         Ok(MyRegState::Error) => { return Err("State machine encountered error starting!"); },
         Ok(MyRegState::Starting) => { /* noop */ },
+        Err(modular_bitfield::EnumError(UnrecognizedValue(3))) => { /* I'm too lazy to update the struct itself but I need to handle this case */ }
         _ => { /* Now is never hit... until someone updates the struct! */ }
     }

which I think is an argument for getters not returning errors even if #[returns_result] is specified with 2**bits number of variants. My argument against it was just it's inconvenient if they have to refactor lots of code, but maybe it's worth it to force the user to audit their matches. I almost wish we had compile_warning!, then we could do the "this will compile fine so you can run your code, but if you want to submit it to your CI you should really fix this" thing.

Thanks a lot for your thourough write-up!
That really helped me to understand users of this library a lot better. :)
I am normally coming from a point of view where I think it is good practice to make it impossible to represent invalid state for an object. Therefore I am naturally leaning towards the checking constructor solution you described above since for me types are the purpose of encapsulating valid state.
However, I think you got a decent point there and also generating code for such complicated constructors might actually be pretty involved. Instead we should give up this thought of purity and accept that reality is impure and so should be the state of out bitfields which then implies getters returning Result in those cases. However, I am still thinking that we should avoid returning Result when we can even though this means that we sometimes might enforce some refactorings to the user, however, those are probably mostly wished for; I see it similarly as with the type system. Changing the signature of a public function also often incurs lots of refactoring steps but we are still not willing to give up our type systems and everything they bring to the table.

Well, I can only help you understand one user of this library :P
But sounds good then, thanks! To concretize the behaviour, I'm thinking #[bits = N] and #[can_error] are independent:

If neither is present, it behaves as it did before.
If both are present, getters return Result, and if the number of variants = 2**bits it throws an error (I'll experiment with warnings) [1]
If bits is present but can_error is not, we simply assert that the number of variants is 2**bits
can_error being present without bits is an error.

[1] Thinking about it more, I think the gotcha above with the sloppy users adding fields can happen even if they go from e.g. 6 variants to 7, so I'm not sure that throwing an error in the second case above will actually catch as much as I would initially hope. But it will catch things sometimes, so I could be convinced either way (to your point about the safety of the type system being desirable if sometimes inconvenient).

[1] Thinking about it more, I think the gotcha above with the sloppy users adding fields can happen even if they go from e.g. 6 variants to 7, so I'm not sure that throwing an error in the second case above will actually catch as much as I would initially hope. But it will catch things sometimes, so I could be convinced either way (to your point about the safety of the type system being desirable if sometimes inconvenient).

Design decisions are always the hardest part about programming in my opinion. ^^

If neither is present, it behaves as it did before.

Can we concretize what this means? What happened before is that we errored if the enum did not have a number of variants that is a power of two. Right? But that's what you have written in the last point. However, I think your last point might be a simple mistake. Because if #[bits = N] is present we very well accept non-power-of-two number of variants but will ensure that they won't require more than N bits in order to represent all states: log(#variants) <= N.

* If both are present, getters return `Result`, and if the number of variants = `2**bits` it throws an error (I'll experiment with warnings) [1]

Sounds good but please keep the experiment with warnings out of this PR.  Instead we can do a follow-up experimenting with this crate: https://crates.io/crates/proc-macro-error

* If `bits` is present but `can_error` is not, we simply assert that the number of variants is `2**bits`

We should actually assert what I have written above: That the enum does not require more than N bits to represent all of its information. So using this new #[bits = N] allows us to use non-power-of-two variants.

* `can_error` being present without `bits` is an error.

:+1:
Also I would not call it can_error because that is very technical of what happens under the hood with getters but instead something like #[incomplete] since that is what happens on the user facing side. The enum state is not completely covered.

To the points above we have to make a final decision about what does #[bits = N] on an enum. Does it allow for non-power-of-two number of variants telling which bounds N we'd like instead or does it the opposite and only restrict the user from using exactly as many variants as 2**N?

I think a #[bits = N] without a corresponding #[can_error] tag on a non-power-of-two enum has to be an error. (a #[bits = N] on a power-of-two enum with 2**bits variants is perfectly fine)
Alternatively, it could panic if you get() an invalid variant. In this case, can_error is more descriptive than incomplete, since the user is now explicitly "giving permission" for the enum's getters to return errors.

Okay let's simply go through some explames using your proposed design then:
#[derive(BitfieldSpecifier)]
#[bits = 1]
pub enum Place {
    First,
    Second,
}

This is fine since the enum requires 1 bit as specified in the attribute.
#[derive(BitfieldSpecifier)]
#[bits = 1]
pub enum Place {
    First,
    Second,
    Third,
}

This is an error since we require more bits (2) than specified (1).
#[derive(BitfieldSpecifier)]
#[bits = 2]
pub enum Place {
    First,
    Second,
    Third,
}

This still is an error because we did not specify #[may_error].
#[derive(BitfieldSpecifier)]
#[bits = 1]
#[may_error]
pub enum Place {
    First,
    Second,
    Third,
}

This is fine again since we now specified #[may_error].
#[derive(BitfieldSpecifier)]
#[bits = 2]
#[may_error]
pub enum Place {
    First,
    Second,
    Third,
    Fourth,
}

This is an error since we specified bits and may_error but we actually have a power-of-two size bitfield.

That all looks reasonable to me, the one I'm not sure about is the last one (if the user explicitly said may_error, maybe it's fine that it may never error? Not erroring I think would be the least surprising to the user, since bits and may_error are essentially orthogonal concerns).
I think in the second-to-last one, you have a typo, and it should be #[bits = 2]

That all looks reasonable to me, the one I'm not sure about is the last one (if the user explicitly said may_error, maybe it's fine that it may never error? Not erroring I think would be the least surprising to the user, since bits and may_error are essentially orthogonal concerns).

I cannot follow. Can you elaborate please?

I think in the second-to-last one, you have a typo, and it should be #[bits = 2]

Ah yes, i fixed it. Thanks!

Yeah. So, if we have a may_error attribute, it might surprise the user
that we won't let them keep that attribute (and the API) when number of
variants == 2**bits
It's probably easier to throw an error now, if people complain later it's
easier to open it up than close it down.
On Mon, Oct 19, 2020 at 4:03 PM Hero Bird<EMAIL_ADDRESS>wrote:

That all looks reasonable to me, the one I'm not sure about is the last
one (if the user explicitly said may_error, maybe it's fine that it may
never error? Not erroring I think would be the least surprising to the
user, since bits and may_error are essentially orthogonal concerns).
I cannot follow. Can you elaborate please?
I think in the second-to-last one, you have a typo, and it should be #[bits
= 2]
Ah yes, i fixed it. Thanks!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Robbepop/modular-bitfield/pull/25#issuecomment-712440455,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGWX4FT6O7H4KPVTU73FQTSLSSRPANCNFSM4SVHP5WQ
.

Yeah. So, if we have a may_error attribute, it might surprise the user that we won't let them keep that attribute (and the API) when number of variants == 2bits It's probably easier to throw an error now, if people complain later it's easier to open it up than close it down.
…
On Mon, Oct 19, 2020 at 4:03 PM Hero Bird @.*> wrote: That all looks reasonable to me, the one I'm not sure about is the last one (if the user explicitly said may_error, maybe it's fine that it may never error? Not erroring I think would be the least surprising to the user, since bits and may_error are essentially orthogonal concerns). I cannot follow. Can you elaborate please? I think in the second-to-last one, you have a typo, and it should be #[bits = 2] Ah yes, i fixed it. Thanks! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#25 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGWX4FT6O7H4KPVTU73FQTSLSSRPANCNFSM4SVHP5WQ .

Well okay let's do it like that for now. If the design is suboptimal we can change it later easily since we are not yet version ^1.0.

In https://github.com/Robbepop/modular-bitfield/pull/28 I went with a simpler design for our previously discussed issue with erroneous getters or fail-free getters. In this new design we simply shift the control over to the user of the bitfield and have mirroring getters for expected failure and unexpected failure paths just as we already have for setters.

Alright, I think that makes sense. So basically we wouldn't need the may_error attribute, and we can leave it up to the user whether they call get_checked or get (for panicking behaviour)?
I like that.

Alright, I think that makes sense. So basically we wouldn't need the may_error attribute, and we can leave it up to the user whether they call get_checked or get (for panicking behaviour)?
I like that.

Yep it now works exactly as you have described. :+1:

Alright I rebased (the change is substantially shorter now :P), the one clippy error seems to be pre-existing.

Alright I rebased (the change is substantially shorter now :P), the one clippy error seems to be pre-existing.

Yep you probably have to rebase again because I just fixed the clippy issue. :sweat_smile: Sorry!

Fortunately, no merge conflicts, so it wasn't too hard.

Anytime, thanks for maintaining the crate!


Fix index in take until.

Fixes an issue found in https://github.com/Workiva/go-datastructures/issues/138
@Workiva/dtbackend

+1

+1

Thanks @dustinhiatt-wf


Connect to Ledger Blue

I've installed the Stratis App on my Ledger Blue but can't find how to connect the electrum-stratis wallet to it. Is it done as part of the electrum wallet intialisation? I kept an eye out when doing that but didn't see anything.

I ran into the same issue. Electrum-stratis-2.7.17 does not appear to support the Ledger hardware wallets anymore. Does anyone have an update on when this will be fixed?


1.2.0 doesnt compile

When using PlatformIO (ESP32) with<EMAIL_ADDRESS>the build fails:
In file included from .pio/libdeps/esp/AceTimeClock/src/AceTimeClock.h:29,
                 from src/main.cpp:7:
.pio/libdeps/esp/AceTimeClock/src/ace_time/clock/EspSntpClock.h: In member function 'virtual ace_time::acetime_t ace_time::clock::EspSntpClock::getNow() const':
.pio/libdeps/esp/AceTimeClock/src/ace_time/clock/EspSntpClock.h:52:22: error: 'secondsToCurrentEpochFromUnixEpoch64' is not a member of 'ace_time::LocalDate'
         - LocalDate::secondsToCurrentEpochFromUnixEpoch64();
                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is the listed Dependency Graph for AceTimeClock:
|-- AceTimeClock @ 1.2.0
|   |-- WiFi @ 2.0.0
|   |-- AceTime @ 2.0.0
|   |   |-- AceCommon @ 1.5.2
|   |   |-- AceSorting @ 1.0.0
|   |-- AceCommon @ 1.5.2
|   |-- AceSorting @ 1.0.0

Rolling back to<EMAIL_ADDRESS>also does not work. Looks like the dependencies have no specified version range here so I wouldn't expect ~1.1 to work. Looks like version ranges can be specified but I'm not sure they work in Arduino v1.

Sorry about that. I fixed this on the develop branch yesterday, but I have not yet pushed a new release. Will do that very soon, like today. The LocalDate::secondsToCurrentEpochFromUnixEpoch64() should be Epoch::secondsToCurrentEpochFromUnixEpoch64() instead.

Can confirm, ae638ab works as expected. I'll use it until a new release is there. Thank you!

Fixed with new v1.2.1 release.
I also released EpoxyDuino v1.4.0 and EspMock v0.1, to allow the ESP8266 examples in AceTimeClock to run in GitHub Actions to check for compiler errors. Previously, they were not included because supporting the necessary ESP8266 mocks seemed like a lot of work, which it kinda was but not terribly. But now that the work is done, it feels good to have automated checking for the ESP8266 code paths.

Looks like 1.2.1 is not yet known to PlatformIO: https://registry.platformio.org/libraries/bxparks/AceTimeClock/versions
Also the README dependencies state AceTime v1.8 (Line 151), isnt that 2.0 now?

PlatformIO now also has the version 1.2.1.

Thanks, updated the README.md. Released v1.2.2 with a bug fix in NtpClock.


🌱 add build images action to release-1.5

Workflow file needs to be present in the branch its targeting.

/override test-ubuntu-e2e-integration-release-1-5
/hold
Until verified in IPAM first.

/unhold
/lgtm


Add my profile on GitHub

Hello World!

@motokikasai  thnx for contributing, try this year, and make sure you follow me and star this repo for updates about special swags I will be giving.
Contribute in October for Hacktoberfest 2020


Request: Expand documentation on focus and navigation

I have a very simple grid implementation: https://github.com/dmitriid/lightningjs-repro/blob/master/src/components/Grid.tsx (note, the repo itself is for a separate issue filed against solid-ui)
It just dumps [0...n] elements on a grid like
   0 .... max elements fitting in a row
   max ... max elements fitting in a row
   ...

Once focused... It retains focus on the first element regardless of any keyboard or mouse navigation. In my mental model navigating right would cause selected/activeElement to switch to next element on the right, but that never happens.

👋 - I'll work on adding some more documentation around this topic.
If you look at https://github.com/rdkcentral/solid-ui/blob/main/packages/solid/components/Row/Row.tsx - Row adds a onLeft & onRight keyhandler which is doing the work to update selected and setFocus() on the next element. You'd need to do something similar with your Grid component. Add keyhandlers for each direction and handle setFocus() on each of the elements as the user presses keys. Again you can see how Row does it: https://github.com/rdkcentral/solid-ui/blob/main/packages/solid/utils/handleNavigation.ts#L35
Further, you probably don't need a Grid component. You can easily nest Column, Rows to provide Grid like functionality.

Thanks! I thought it worked "magically" like BBC's LRUD, that's why I couldn't wrap my head around it :)

Added a bit more docs. Closing out

Thank you!


Vendor libnetwork v0.6.1-rc1

Fixes #20026. Programming iptables in container use native API.

Signed-off-by: Madhu Venugopal<EMAIL_ADDRESS>

LGTM, manually tested on Fedora 23 w/ firewalld enabled.

LGTM


Improve claim-backend logging

What was the problem?
This PR resolves #62
How was it solved?
4 middlewares added: 2 Express Middleware and 2 RPC Middleware

expressLogger
expressErrorHandler
rpcLogger
rpcErrorHandler

Both *ErrorHandler are used to suppress error made by client. expressLogger logs data at HTTP level, info such as IP, user-agent, response time are recorded. rpcLogger logs with request and response from RPC API.
Due to the design of express, it requires some over-engineering to get the response at HTTP level, and on the RPC side there is also no HTTP data. That's why 2 middlewares are used.
How was it tested?

Testing backend with every logging level
Testing each RPC endpoints
Testing with valid and invalid data
Logging works as expected

LGTM, one inquiry, tried the logger.ts file in a simple setup, and discovered that the error stack is being returned as response, perhaps not an issue for our use-case as the repository is already public or how the endpoint is consumed?

Error stack will be hidden when NODE_ENV=production and this flag has been used in prod


Documentation

DOCUMENTATION

[ ] Project organization and team work
[ ] Project information (SDK version, ...)
[ ] Pin mapping
[ ] Code comments (doxygen)
[ ] BOM
[ ] Schematics
[ ] Routing
[ ] Export components lib
[ ] Report known issues and bugs (errata)
[ ] keep track of the revisions

@Touftoufe Could you define the review the directory tree from the README.md ?


render-helm-chart function changes

Support multiple values files in RenderHelmChart functionConfig (https://github.com/kubernetes-sigs/kustomize/issues/4219)
Make the repo field optional to support authentication with private repositories (https://github.com/kubernetes-sigs/kustomize/issues/4335)
Support other requested options for helm template, such as api-versions, name-template,  and skip-tests.

EDIT: Removing create-namespace and skip-crds because I'd misunderstood what they do; I don't think they will provide value here as IIUC they involve communication with the cluster.
This is a breaking change, and will require a version bump.

cc @yuwenma


TypeError: undefined is not a function

/home/nlundsten/.atom/packages/quantum-shell/lib/quantum-shell-model.coffee:192
Hide Stack Trace
TypeError: undefined is not a function
at QuantumShellModel.promptString (/home/nlundsten/.atom/packages/quantum-shell/lib/quantum-shell-model.coffee:195:83)
at /home/nlundsten/.atom/packages/quantum-shell/lib/quantum-shell-controller.coffee:191:83

Thank you for the bug report. This should be fixed now, however if you're still having an issue with it after upgrading to 0.6.1, please reopen this and let me know.


Contact::getCustomDetails() is unusable

The method is declared to return array, but tries to return \stdClass and crashes.
Workaround:
$customDetails = (fn () => $this->customDetails)->call($contact);

This is now merged, thank you.


pipeline await and toBuffer

I am trying to pipe an input stream to a sharp pipeline and get a buffer out of it.
To be able to handle the input stream errors, i thought i could do this:
const sharp = require('sharp');
const pipeline = require('util').promisify(require('stream').pipeline);
const got = require('got');

async function getThumbnailBuffer(uri) {
	const pil = sharp().resize({
		fit: "inside",
		height: 64
	}).toFormat('webp', {
		quality: 50
	});
	const pipe = await pipeline(got.stream(uri), pil);
	const buf = await pil.toBuffer();
	return buf; // i know i can return pil.toBuffer(), i do this to show where we wait
};

however that doesn't work - await pipeline doesn't return when no error is thrown.
On the other hand, it correctly (meaning try { await getThumbnailBuffer(url); } works) throws an error (from got.stream) when there is one.
I also tried this but toBuffer is not a stream, so it can't work:
	return await pipeline(got.stream(uri), pil.toBuffer());

Instead i had to do that:
const sharp = require('sharp');
const pipeline = require('util').promisify(require('stream').pipeline);
const got = require('got');

module.exports = async function (uri) {
	const pil = sharp().resize({
		fit: "inside",
		height: 64
	}).toFormat('webp', {
		quality: 50
	});
	let toBuff;
	setTimeout(async () => {
		toBuff = pil.toBuffer();
	});
	await pipeline(got.stream(uri), pil);
	const buf = await toBuff;
	return buf; // i know i can return toBuff, i do this to show where we wait
};

this works and also catches (in a way compatible with async/await) errors.
However it's ugly.
It's hard to tell if it comes from

node
got
sharp
but right now i'm inclined to think the need to call "toBuffer" to trigger the stream is odd.

A sharp instance implements a Duplex stream so won't emit the close event (and therefore resolve the "promisified" logic here) until it knows the destination of the output, as this might be another WritableStream.
Perhaps an alternative approach might be to await the input and output sides concurrently, something like (untested):
const [pipe, buf] = await Promise.all([
  pipeline(got.stream(uri), pil),
  pil.toBuffer()
]);

Yes ! that's so much nicer ! Even better, this works too:
const [buf] = await Promise.all([
  pil.toBuffer(),
  pipeline(got.stream(uri), pil)
]);

maybe it would help so much if it was given as an example somewhere in the documentation.

Glad you got it working. I've tagged this as cookbook for inclusion in future possible document relating to problem-oriented solutions (as opposed to API-level reference).


Named query parameters

Adds the ability to have named parameters via the :name syntax. Can be used together with regular unnamed parameters.

@Qtax Thank you. Amazing contribution. I will review a pr soon


Fix some of the RuboCop RSpec TODO items

As a continuation to @backus' great work in #4904. This fixes some more RSpec related items in .rubocop_todo.yml, and introduces #expect_offense and #expect_no_offenses in some places.

Before submitting the PR make sure the following are checked:

[X] Wrote good commit messages.
[ ] Commit message starts with [Fix #issue-number] (if the related issue exists).
[X] Used the same coding conventions as the rest of the project.
[X] Feature branch is up-to-date with master (if not - rebase it).
[X] Squashed related commits together.
[ ] Added tests.
[ ] Added an entry to the Changelog if the new code introduces user-observable changes. See changelog entry format.
[X] All tests(rake spec) are passing.
[X] The new code doesn't generate RuboCop offenses that are checked by rake internal_investigation.
[X] The PR relates to only one subject with a clear title
and description in grammatically correct, complete sentences.
[ ] Updated cop documentation with rake generate_cops_documentation (required only when you've added a new cop or changed the configuration/documentation of an existing cop).

The CI failure is coming from the intermittent issue that appeared after we started running parallel tests:
NameError:
 uninitialized constant RSpec::Support::Differ

@Drenmi these changes look great. Kudos

@bbatsov: Rebased.


Feature: Override Policy Check for a given run

All Submissions:

[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[x] I have updated the documentation accordingly.
[x] Where applicable I have added tests to cover my changes.
[x] All new and existing tests passed.
[x] My code follows the code style of this project.
[x] I ran lint checks locally prior to submission.
[x] Have you checked to ensure there aren't other open PRs for the same update/change?

What about the current behavior has changed?

This feature allows the user to override a policy-check where applicable
See README with updates under policy-check

Does this introduce a change to go.mod, go.sum or vendor/?

[ ] Yes
[x] No

Does this introduce a breaking change?

[ ] Yes
[x] No

Any relevant logs, error output, etc?
==> Testing <==
cd cmd/ && go test -v
=== RUN   TestPolicySetListCmd
--- PASS: TestPolicySetListCmd (6.13s)
=== RUN   TestPolicyListCmd
--- PASS: TestPolicyListCmd (4.11s)
=== RUN   TestRegistryModulesListCmd
--- PASS: TestRegistryModulesListCmd (17.26s)
=== RUN   TestRootCmd
--- PASS: TestRootCmd (0.00s)
=== RUN   TestRunListCmd
--- PASS: TestRunListCmd (24.02s)
=== RUN   TestTagsListCmd
--- PASS: TestTagsListCmd (0.65s)
=== RUN   TestTeamListCmd
--- PASS: TestTeamListCmd (3.92s)
=== RUN   TestWorkspaceListCmd
--- PASS: TestWorkspaceListCmd (18.98s)
PASS
ok      github.com/AGLEnergyPublic/tfectl/cmd   75.087s

Other information

Superseded


CRLF instead of LF for new line

I am trying to use S3 browser with the credential file but it does not support LF as new line.
The original credentials file using aws configure has CRLF as the new line.
Can this be changed to CRLF?

Fixed in release v2.5
https://github.com/prolane/samltoawsstskeys/commit/21f4738cdd9e4e8b13a77973e1f19a12aec6c0f8


Failed to initialize terrascan. error : could not connect to github.com

terrascan version: 1.14.0
Operating System: Ubuntu

Description
Running 'terrascan init' or 'terrascan scan' command yields following error -
2022-05-09T07:55:24.311+0300	error	cli/init.go:42	failed to initialize terrascan. error : could not connect to github.com
What I Did
Downloaded and installed terrascan in a Dockerfile. Then while running scan or running terrascan init in a pipeline job, getting this error -
2022-05-09T07:55:24.311+0300	error	cli/init.go:42	failed to initialize terrascan. error : could not connect to github.com

Hello @SayaliMane05,
I couldn't reproduce this issue with the latest version. It is possible that GitHub wasn't reachable at the time you performed init.
Could you please try to reproduce again? Let us know if you are still facing this issue.

Hello @patilpankaj212 ,
I tried this multiple times. Still getting the same error.
What could be the reason for this error? Do we need to install anything (any packages etc) along with Terrascan?

No, we don't need to install anything for terrascan to perform the init operation. When the init command is run, it clones the terrascan github repo to $USER_HOME/.terrascan on the users machine. So, when init is run, the machine should be connected to internet and github.com should be reachable.

Okay @patilpankaj212
Thanks for the help. I'll check again why it's failing

I am getting the same error. I am attempting to use the tenable/terrascan docker image from hub.docker.com in my gitlab-ci.yml file and whenever I run any of the terrascan commands, I get this error:

This is what my .gitlab-ci.yml file looks like. I got this method from the documentation.

I am using a GitLab shared runner and its a kubernetes executor. I'm not sure if that's the problem or a bug with the container but I would really like to be able to use this image with my GitLab job.

Hi, I run into this error as well. Same as the issuer @SayaliMane05, I also do "terrascan init" in a Dockerfile and build the image through Gitlab pipeline (gitlab shared runner on kubernetes which is same as @sydneyscoffield).
It's weird that it can successfully execute git clone to the target repo_url directly. However, git clone through terrascan init will failed.

Environment

terrascan version: 1.16.0
Docker build image: docker:stable
Dockerfile base image: alpine 3.12

terrascan config

Does anyone know where it tries to connect to on github.com?
For us github.com will only be opened on certain context-paths but terrascan is not logging the specifics.
Kr

Commenting to say I am also having this issue.
terrascan version: v1.18.3
OS: MacOS Ventura 13.6

I had this problem because our corporate firewall blocks SSH on port 22.  The<EMAIL_ADDRESS>urls use SSH and we're required to use https git urls instead.  Added the following configuration step in our CI job before running terrascan init
git config --global url."git@github.com:".insteadOf https://github.com/


Replace Bash entry point with Python version

This is a translation to Python with minimal semantic changes.
Signed-off-by: Sean Robinson<EMAIL_ADDRESS>

@JacobDomagala
I've pushed rough draft of a entrypoint translation from Bash to Python. Is this a direction you are interested in?

Hey, sorry for late reply, been kinda busy lately.
Are there any advantages of using Python instead of Bash for entrypoint?

Hey, sorry for late reply, been kinda busy lately.

No worries.

Are there any advantages of using Python instead of Bash for entrypoint?

The advantage I see is reducing the complexity of repeatedly crossing the shell boundary.  The current flow is bash > python > bash > python.
Reducing the quantity of execs avoids some stdin/stdout format issues between Bash and Python, e.g. commit 126be5f8. Also, does the current API via the shell correctly handle filenames containing spaces?
A recurring pattern in the existing code is to save stdout to a temporary file to be read later (see commit cd07e30a).  Python's subprocess.run can save command output to a variable for later use in the same script.
I left the subprocess calls to the two existing Python scripts, but the code in get_files_to_check.py and run_static_analysis.py could be moved into entrypoint.py.
Optionally, git commands could be assumed into entrypoint.py with pygit2.

Ok, I like the idea of dealing only with Python environment. :+1:

Also, does the current API via the shell correctly handle filenames containing spaces?

That's a good question. I've never used names with spaces in my projects (that use this workflow).

I have not found the time to work more on this PR and likely won't have time before the end of the year. I'll close this PR but leave the branch in my tree if someone else wants to pick it up.


Cycling from the default "no name" buffer will generate an error.

Launch vim so that the "No Name" default buffer is the only buffer open. Invoke Counterpoint to try to cycle. Counterpoint will generate an ("argument of filter() must be a List or Dictionary").

Fixed by https://github.com/jpetrie/vim-counterpoint/commit/c5175e5b7f75cb07b9e1b5d522c887a531331205.


Tests should work offline

ETA: 2023Q1
tests should really be able to run offline (or autoskip)
Run:
go test -timeout 30s -run ^TestServeSuite$ -testify.m ^(TestRun_GenericServe)$ github.com/filecoin-project/bacalhau/cmd/bacalhau

With networking offline.
See:
13:13:39.944 | DBG system/environment.go:38 > BACALHAU_ENVIRONMENT is not set to a known value:
13:13:39.945 | DBG system/tracer.go:60 > error initializing http tracer: error creating honeycomb exporter: please ensure that "HONEYCOMB_KEY" has been set
13:13:39.945 | DBG system/tracer.go:61 > failed to initialize http tracer, falling back to debug tracer
13:13:39.972 | DBG system/config.go:215 > config file /var/folders/38/kszkvfx157q2qy4fm0gwzxpw0000gn/T/bacalhau-test2060239421/config.yaml does not exist, creating default
13:13:39.972 | DBG system/config.go:239 > user ID key file '/var/folders/38/kszkvfx157q2qy4fm0gwzxpw0000gn/T/bacalhau-test2060239421/user_id.pem' does not exist, creating one
Starting
13:13:40.214 | DBG bacalhau/serve.go:253 > libp2p connecting to: [/ip4/<IP_ADDRESS>/tcp/1235/p2p/QmdZQ7ZbhnvWY1J12XYKGHApJ6aufKyLNSvf8jZBrBaAVL /ip4/<IP_ADDRESS>/tcp/1235/p2p/QmXaXu9N5GNetatsvwnTfQqNtSeKAD6uCmarbh3LMRYAcF /ip4/<IP_ADDRESS>/tcp/1235/p2p/QmYgxZiySj3MRkwLSL4X2MF5F9f2PMhAE3LV49XkfNL1o3]
13:13:40.221 | DBG ipfs/client.go:44 > Created IPFS client for node API address: /ip4/<IP_ADDRESS>/tcp/56954
13:13:40.221 | DBG ipfs/client.go:44 > Created IPFS client for node API address: /ip4/<IP_ADDRESS>/tcp/56954
13:13:40.221 | DBG ipfs_apicopy/storage.go:46 > IPFS API Copy driver created with address: /ip4/<IP_ADDRESS>/tcp/56954
13:13:40.221 | DBG urldownload/storage.go:44 > URL download driver created with output dir: /var/folders/38/kszkvfx157q2qy4fm0gwzxpw0000gn/T/bacalhau-url426508399
13:13:40.221 | DBG filecoin_unsealed/storage.go:34 > Filecoin unsealed driver created with path template:
13:13:40.221 | DBG ipfs/client.go:44 > Created IPFS client for node API address: /ip4/<IP_ADDRESS>/tcp/56954
13:13:40.221 | DBG ipfs_apicopy/storage.go:46 > IPFS API Copy driver created with address: /ip4/<IP_ADDRESS>/tcp/56954
13:13:40.222 | DBG urldownload/storage.go:44 > URL download driver created with output dir: /var/folders/38/kszkvfx157q2qy4fm0gwzxpw0000gn/T/bacalhau-url2401120307
13:13:40.222 | DBG filecoin_unsealed/storage.go:34 > Filecoin unsealed driver created with path template:
13:13:40.222 | DBG ipfs/client.go:44 > Created IPFS client for node API address: /ip4/<IP_ADDRESS>/tcp/56954
13:13:40.222 | DBG ipfs/publisher.go:31 > IPFS publisher initialized for node: /ip4/<IP_ADDRESS>/tcp/56954
13:13:40.348 | DBG docker/executor.go:390 > Cleaning up all bacalhau containers for executor bacalhau-QmXSJKJ4pf7bnXpADYnPASSB9J1RHR8Wnu62LmSG47PWgJ...
13:13:40.348 | DBG libp2p/libp2p.go:187 > Libp2p transport has stopped
13:13:40.349 | ERR docker/executor.go:393 > Docker executor stop error: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/json?all=1&limit=0": context canceled
Error: failed to dial QmdZQ7ZbhnvWY1J12XYKGHApJ6aufKyLNSvf8jZBrBaAVL:
  * [/ip4/<IP_ADDRESS>/tcp/1235] dial tcp4 <IP_ADDRESS>:1235: connect: network is unreachable
Usage:
  bacalhau serve [flags]

Examples:
  TBD

Flags:
      --estuary-api-key string               The API key used when using the estuary API.
      --filecoin-unsealed-path string        The go template that can turn a filecoin CID into a local filepath with the unsealed data.
  -h, --help                                 help for serve
      --host string                          The host to listen on (for both api and swarm connections). (default "<IP_ADDRESS>")
      --ipfs-connect string                  The ipfs host multiaddress to connect to.
      --job-selection-data-locality string   Only accept jobs that reference data we have locally ("local") or anywhere ("anywhere"). (default "local")
      --job-selection-probe-exec string      Use the result of a exec an external program to decide if we should take on the job.
      --job-selection-probe-http string      Use the result of a HTTP POST to decide if we should take on the job.
      --job-selection-reject-stateless       Reject jobs that don't specify any data.
      --limit-job-cpu string                 Job CPU core limit for single job (e.g. 500m, 2, 8).
      --limit-job-gpu string                 Job GPU limit for single job (e.g. 1, 2, or 8).
      --limit-job-memory string              Job Memory limit for single job  (e.g. 500Mb, 2Gb, 8Gb).
      --limit-total-cpu string               Total CPU core limit to run all jobs (e.g. 500m, 2, 8).
      --limit-total-gpu string               Total GPU limit to run all jobs (e.g. 1, 2, or 8).
      --limit-total-memory string            Total Memory limit to run all jobs  (e.g. 500Mb, 2Gb, 8Gb).
      --metrics-port int                     The port to serve prometheus metrics on. (default 2112)
      --peer string                          The libp2p multiaddress to connect to.
      --swarm-port int                       The port to listen on for swarm connections. (default 1235)

Global Flags:
      --api-host string   The host for the client and server to communicate on (via REST). Ignored if BACALHAU_API_HOST environment variable is set. (default "bootstrap.production.bacalhau.org")
      --api-port int      The port for the client and server to communicate on (via REST). Ignored if BACALHAU_API_PORT environment variable is set. (default 1234)

--- FAIL: TestServeSuite (3.44s)
    --- FAIL: TestServeSuite/TestRun_GenericServe (3.44s)
        /Users/daaronch/code/bacalhau/cmd/bacalhau/serve_test.go:131:
            	Error Trace:	/Users/daaronch/code/bacalhau/cmd/bacalhau/serve_test.go:131
            	Error:      	Server did not start in 3000
            	Test:       	TestServeSuite/TestRun_GenericServe
FAIL
exit status 1

It's trying to connect to the default bootstrap nodes, but I'm offline.

I've tested running both unit & integration tests and the only tests that attempt to access the network are:

Tests under pkg/publisher/estuary (see #1271)
The TestLotusNodeSuite tests, as the Lotus image wants to connect to https://api.drand.sh, https://api2.drand.sh, https://api3.drand.sh or https://drand.cloudflare.com before starting up. After looking through the Lotus code, I don't think there's a way to stop this from happening.


Missing dependencies

Is this a bug report?
Yup! When I tried adding 'dynamic-cdn-webpack-plugin' to my project, it causes webpack to crash trying to require in a dependency.
Please find a minimal recreation here: https://github.com/wingsbob/dynamic-cdn-webpack-plugin-issue
Environment
npm ls dynamic-cdn-webpack-plugin
<EMAIL_ADDRESS>project root
`--<EMAIL_ADDRESS>
npm ls webpack
<EMAIL_ADDRESS>project root
`--<EMAIL_ADDRESS>
Steps to Reproduce
require('dynamic-cdn-webpack-plugin')?
Expected Behavior
Webpack runs 🤷♂
Actual Behavior
Webpack crashes with
Error: Cannot find module 'babel-runtime/core-js/object/values'

This happens on requiring 'dynamic-cdn-webpack-plugin'
Reproducible Demo
https://github.com/wingsbob/dynamic-cdn-webpack-plugin-issue
Instructions in the readme.

Hi,
We have fixed this issue on our master branch but haven't released a new version yet.
For the time being you can fix this by installing babel-runtime,
npm i -D babel-runtime

Do you have any timeline on when you'll be releasing a new version? 😄

This issue still exists!
When are you planning a release??


LightSwitch Docs - detail store usage and add OS preference store

@luke-hagar-sp As we discussed on Discord.
We need two things:

We need to make it obvious how you import and use the LightSwitch store
We need to add an addition store which houses the OS "prefers" value, which is set on load, before LightSwitch interaction

Let me know if this can be added, otherwise I'll grab it asap.


#689: enable dnu on osx/linux if dnu in path

Summary
This is a trivial change that enables DNU tools in OSX/Linux environments.
Issue
see #689 for issue.
changes

add dnu to DNUTool's executable names.

Testing

tested Cake project on windows (doesn't build on mono even with change)
tested example project on windows/osx
tested my dnx project on windows/osx
ran both DNURestore and DNUBuild tools.

Can someone take a look at this? it's a pretty trivial change.

@andycmaj I'll take a look at it in a couple of hours.

Looks good to me :smile:
Can you rebase against develop and squash the commits to a single one so I can merge it?
Thanks! :+1:

sure

@andycmaj Not at a computer today but will write some instructions for you asap.

@andycmaj Ok, it looks like you only need to rebase against develop. Here's a quick guide how to do that.
1. Add the upstream remote
> git remote add upstream https://github.com/cake-build/cake.git
2. Rebase fork's develop against upstream/develop
> git checkout develop
> git fetch upstream
> git merge upstream/develop
> git push
3. Rebase feature branch against local develop
> git checkout dnu-tool-fix
> git rebase develop
> git push

Cool... gotcha.
thanks very much, @patriksvensson.
Looks like my commit is the only one in the commit list now. so i think this should be good.

@andycmaj Merged :+1: Thank you for your contribution and for your patience :smile:


Xcode 11.1, failed to get coverage

After updating to Xcode 11.1, I get this error
Failed to get the coverage - Error: Could not find the xccovreport file

I am using the latest version of danger and this plugin
    dependencies: [
        .package(url: "https://github.com/danger/swift.git", from: "2.0.4"),
        .package(url: "https://github.com/f-meloni/danger-swift-coverage", from: "1.0.0")
    ],

Anyone knows how to fix this for Xcode 11.1?

The xccovreport location probably changed, let me have a look

Is a completely different format, it will need a specific patch

released a fix with 1.0.1, let me know if solves it

it works again, thank you.


make market categories case insensitive

I created a market today on test.augur.net, just to get more of a sense for how the UI works.  I intended to add it under the category POLITICS, which already existed... but instead it created a new category and now both of them show up exactly the same on the panel that lists all categories.
Only by clicking on each and comparing the url can you see what happened.. one of them is capitalized while the other is not:
https://test.augur.net/#/markets?category=Politics
https://test.augur.net/#/markets?category=politics
Ideally, I think there should be a dropdown menu of categories, so you can pick from existing ones instead of having to enter it in as a text string.  But either way, it should be case insensitive so this kind of thing can't happen.  (The display is already case insensitive, just need to make the rest consistent with that.)

Thanks for the heads up,
This will be fixed as soon as the PRs are merged. It ended up being both the UI and augur-node use case sensitive category searches.
https://github.com/AugurProject/augur-node/pull/374

Merged. Thank you for the issue report!


Add a logs modal to UI

Hey @mrdmnd, any chance you could share the way you're using Chronos to read the logs of the underlying Mesos?
I saw the add_chronos_logs branch, but it doesn't seem to include the code to fetch the logs, only part of the display. Some guys are discussing about it here as well: http://stackoverflow.com/questions/28669547/how-to-generate-the-url-which-shows-the-live-logs-in-mesos-for-a-job
Thanks!

Hey, @redox - I no longer am a maintainer on Chronos after switching to a new company, but I'd be willing to dig back through some old code and see if I can figure it out. Give me a day or so?

That would be cool, thank you for your help :)


Fix copy/paste issues in views/base.py

Updated correct class names.

Yikes, thanks!

@bennylope Could you please cut a release that includes this?


update: Ensure method _asdict also converts Word object into a native dict

Currently, after segments are generated with the WhiperModel.transcribe() method and word_timestamps=True, upon using method Segment()._asdict, we get output like the following:

In the image above, the upper red box is undesired, because _asdict should convert to native types. Additionally, this causes information, such as the dictionary keys are also lost when we convert the object that is supposedly a dict using json.dumps as exemplified in the lower red box.
The change presented therefore ensures that all Word() objects are first converted to native types, so that the keys for each Word() are retained when the _asdict method is called, or json.dumps(segment._asdict()) is called.

This is a nice change that would benefit the community

closed in favor of #1105


Xps requirements increase too fast

I've played this game for more than 5 hours, and I think I'm good at planning upgrading skills. Even though, I still get stuck. So I think there may be something needed to be adjusted.
I've reached Holy knight in the 3rd generation. However, the requirement for the next job includes Battle tactics level 1k, which is nearly impossible to achieve, and I've been stuck at this for about two generations. ( And I don't think I could get over it without cheating)
The Max Levels of my Concentration and Meditation are 872 and 889, respectively.
I've come up with some strategies, maybe I could end up my life learning Concentration only(upgrade other skills' level to a moderate level for boosts) so that I could have a boost in learning Concentration in later generations. But this is quite frustrating.
Here are some of my suggestions:

reduce the increasing speed of Xp requirements
e.g., from Math.round(this.baseData.maxXp * (this.level + 1) * Math.pow(1.01, this.level)) to some lower rank expressions.
Increase the boost of Max Level.

If we need to surpass the previous Max Level to get a higher boost, it'll be harder and harder to do so. (And the boost's effect is relatively lower and lower)
Change the linear boost into some higher rank expressions.
Change the boost mechanism, provide a very high boost when the current level is less than Max Level. This makes it easier to achieve progress in early generations.

Improve the effect of Bargaining.
I found that Bargaining is quite useless. It's impossible to afford to live in Grand palace with the job Holy Knight with it. Even Lv 500 Bargaining can only reduce the cost to 0.6x.

Here a tip, it should have already been shown to you:

Spoiler warning
Something tells you that the amulet might transform even further after living for 2 whole centuries...
IE: There a way to extend your life and unlock a new path in Amulet.

@asl97 So how do you increase your life? I'm on my fifth generation

Look into the magic a little bit, you may find your answer there.


HBASE-24627 Normalize one table at a time

Introduce an additional method to our Admin interface that allow an
operator to selectivly run the normalizer. The IPC protocol supports
general table name select via compound filter.

FYI @bitoffdev

Goal is for this to eventually go to which versions?

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 28s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+0 :ok:
prototool
0m  0s
prototool was not available.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 26s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 34s
master passed

+1 :green_heart:
checkstyle
2m 49s
master passed

+1 :green_heart:
spotbugs
7m 30s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 19s
the patch passed

-0 :warning:
checkstyle
1m  4s
hbase-server: The patch generated 2 new + 106 unchanged - 1 fixed = 108 total (was 107)

-0 :warning:
rubocop
0m 12s
The patch generated 17 new + 352 unchanged - 0 fixed = 369 total (was 352)

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
11m  8s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1.

+1 :green_heart:
hbaseprotoc
2m 53s
the patch passed

+1 :green_heart:
spotbugs
8m  4s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
1m  2s
The patch does not generate ASF License warnings.

52m 41s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2215

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle cc hbaseprotoc prototool rubocop

uname
Linux 7b6c773c5b8d 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 124af6392c

checkstyle
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/1/artifact/yetus-general-check/output/diff-checkstyle-hbase-server.txt

rubocop
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/1/artifact/yetus-general-check/output/diff-patch-rubocop.txt

Max. process+thread count
94 (vs. ulimit of 12500)

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell U: .

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 35s
the patch passed

+1 :green_heart:
compile
4m  0s
the patch passed

+1 :green_heart:
javac
4m  0s
the patch passed

+1 :green_heart:
shadedjars
7m  2s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 28s
hbase-client in the patch failed.

-0 :warning:
javadoc
0m 45s
hbase-server in the patch failed.

-0 :warning:
javadoc
1m  0s
hbase-thrift in the patch failed.

_ Other Tests _

+1 :green_heart:
unit
1m  5s
hbase-protocol-shaded in the patch passed.

+1 :green_heart:
unit
1m 17s
hbase-client in the patch passed.

-1 :x:
unit
159m 21s
hbase-server in the patch failed.

+1 :green_heart:
unit
4m 38s
hbase-thrift in the patch passed.

-1 :x:
unit
8m 23s
hbase-shell in the patch failed.

223m 55s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2215

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux<PHONE_NUMBER>ab 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 124af6392c

Default Java
2020-01-14

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/1/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-client.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/1/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-server.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/1/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-thrift.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/1/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-client.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/1/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-server.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/1/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-thrift.txt

unit
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/1/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-hbase-server.txt

unit
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/1/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-hbase-shell.txt

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/1/testReport/

Max. process+thread count
4267 (vs. ulimit of 12500)

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/1/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 41s
Docker mode activated.

-0 :warning:
yetus
0m  2s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 23s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m  6s
master passed

+1 :green_heart:
compile
3m  9s
master passed

+1 :green_heart:
shadedjars
6m 15s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
2m  0s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 50s
the patch passed

+1 :green_heart:
compile
3m  7s
the patch passed

+1 :green_heart:
javac
3m  7s
the patch passed

+1 :green_heart:
shadedjars
6m 55s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
2m 19s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
0m 54s
hbase-protocol-shaded in the patch passed.

+1 :green_heart:
unit
1m 22s
hbase-client in the patch passed.

-1 :x:
unit
224m 52s
hbase-server in the patch failed.

+1 :green_heart:
unit
5m 23s
hbase-thrift in the patch passed.

+1 :green_heart:
unit
8m 28s
hbase-shell in the patch passed.

277m 30s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/1/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2215

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 563614e5e295 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 124af6392c

Default Java
1.8.0_232

unit
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/1/artifact/yetus-jdk8-hadoop3-check/output/patch-unit-hbase-server.txt

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/1/testReport/

Max. process+thread count
3590 (vs. ulimit of 12500)

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/1/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

Does the thrift1 API have a normalize command too?

@busbey Nope, it sure doesn't. See the change to ThriftAdmin.java.

Goal is for this to eventually go to which versions?

@busbey this is a backward-compatible feature enhancement, so it's applicable only for patch releases. master and branch-2.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m  5s
the patch passed

+1 :green_heart:
compile
3m 42s
the patch passed

+1 :green_heart:
javac
3m 42s
the patch passed

+1 :green_heart:
shadedjars
5m 57s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 24s
hbase-client in the patch failed.

-0 :warning:
javadoc
0m 41s
hbase-server in the patch failed.

-0 :warning:
javadoc
0m 52s
hbase-thrift in the patch failed.

_ Other Tests _

+1 :green_heart:
unit
0m 59s
hbase-protocol-shaded in the patch passed.

+1 :green_heart:
unit
1m  6s
hbase-client in the patch passed.

-1 :x:
unit
7m 19s
hbase-server in the patch failed.

+1 :green_heart:
unit
4m 36s
hbase-thrift in the patch passed.

+1 :green_heart:
unit
6m 51s
hbase-shell in the patch passed.

56m 31s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/2/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2215

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux df80481cfb76 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / d2afda309d

Default Java
2020-01-14

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/2/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-client.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/2/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-server.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/2/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-thrift.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/2/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-client.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/2/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-server.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/2/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-thrift.txt

unit
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/2/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-hbase-server.txt

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/2/testReport/

Max. process+thread count
2365 (vs. ulimit of 12500)

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/2/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 32s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s
No case conflicting files found.

+0 :ok:
prototool
0m  1s
prototool was not available.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 23s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 42s
master passed

+1 :green_heart:
checkstyle
3m  6s
master passed

+1 :green_heart:
spotbugs
9m 35s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 15s
the patch passed

-0 :warning:
checkstyle
1m 19s
hbase-server: The patch generated 2 new + 106 unchanged - 1 fixed = 108 total (was 107)

-0 :warning:
rubocop
0m 17s
The patch generated 17 new + 352 unchanged - 0 fixed = 369 total (was 352)

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
14m 20s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1.

+1 :green_heart:
hbaseprotoc
3m 14s
the patch passed

+1 :green_heart:
spotbugs
9m 59s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
1m  4s
The patch does not generate ASF License warnings.

63m 23s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/2/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2215

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle cc hbaseprotoc prototool rubocop

uname
Linux af45bf689a02 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / d2afda309d

checkstyle
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/2/artifact/yetus-general-check/output/diff-checkstyle-hbase-server.txt

rubocop
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/2/artifact/yetus-general-check/output/diff-patch-rubocop.txt

Max. process+thread count
95 (vs. ulimit of 12500)

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/2/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f) spotbugs=3.1.12 rubocop=0.80.0

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m  3s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 23s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 40s
master passed

+1 :green_heart:
compile
2m 54s
master passed

+1 :green_heart:
shadedjars
5m 31s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 58s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 24s
the patch passed

+1 :green_heart:
compile
2m 55s
the patch passed

+1 :green_heart:
javac
2m 55s
the patch passed

+1 :green_heart:
shadedjars
5m 33s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
2m  6s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
0m 46s
hbase-protocol-shaded in the patch passed.

+1 :green_heart:
unit
1m  0s
hbase-client in the patch passed.

+1 :green_heart:
unit
147m 23s
hbase-server in the patch passed.

+1 :green_heart:
unit
4m 28s
hbase-thrift in the patch passed.

+1 :green_heart:
unit
7m 31s
hbase-shell in the patch passed.

193m 45s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/2/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2215

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 13fbfbd2b3e4 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / d2afda309d

Default Java
1.8.0_232

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/2/testReport/

Max. process+thread count
4498 (vs. ulimit of 12500)

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/2/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 39s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+0 :ok:
prototool
0m  0s
prototool was not available.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 27s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 11s
master passed

+1 :green_heart:
checkstyle
3m  7s
master passed

+1 :green_heart:
spotbugs
8m 58s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 57s
the patch passed

-0 :warning:
checkstyle
0m 38s
hbase-client: The patch generated 1 new + 282 unchanged - 0 fixed = 283 total (was 282)

-0 :warning:
checkstyle
1m 16s
hbase-server: The patch generated 2 new + 105 unchanged - 2 fixed = 107 total (was 107)

-0 :warning:
rubocop
0m 17s
The patch generated 17 new + 352 unchanged - 0 fixed = 369 total (was 352)

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
13m 18s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1.

+1 :green_heart:
hbaseprotoc
3m 10s
the patch passed

+1 :green_heart:
spotbugs
9m 34s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 55s
The patch does not generate ASF License warnings.

60m 56s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/3/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2215

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle cc hbaseprotoc prototool rubocop

uname
Linux eddedd0884bb 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / a535c7b1af

checkstyle
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/3/artifact/yetus-general-check/output/diff-checkstyle-hbase-client.txt

checkstyle
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/3/artifact/yetus-general-check/output/diff-checkstyle-hbase-server.txt

rubocop
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/3/artifact/yetus-general-check/output/diff-patch-rubocop.txt

Max. process+thread count
94 (vs. ulimit of 12500)

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/3/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f) spotbugs=3.1.12 rubocop=0.80.0

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 32s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 20s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 36s
master passed

+1 :green_heart:
compile
3m  5s
master passed

+1 :green_heart:
shadedjars
5m 32s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 58s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 23s
the patch passed

+1 :green_heart:
compile
2m 55s
the patch passed

+1 :green_heart:
javac
2m 55s
the patch passed

+1 :green_heart:
shadedjars
5m 29s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 59s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
0m 46s
hbase-protocol-shaded in the patch passed.

+1 :green_heart:
unit
1m  0s
hbase-client in the patch passed.

+1 :green_heart:
unit
145m 47s
hbase-server in the patch passed.

+1 :green_heart:
unit
4m 26s
hbase-thrift in the patch passed.

+1 :green_heart:
unit
7m 31s
hbase-shell in the patch passed.

192m 19s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/3/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2215

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 20d14571dcda 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / a535c7b1af

Default Java
1.8.0_232

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/3/testReport/

Max. process+thread count
4635 (vs. ulimit of 12500)

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell U: .

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 46s
the patch passed

+1 :green_heart:
compile
4m  7s
the patch passed

+1 :green_heart:
javac
4m  7s
the patch passed

+1 :green_heart:
shadedjars
7m  1s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 28s
hbase-client in the patch failed.

-0 :warning:
javadoc
0m 45s
hbase-server in the patch failed.

-0 :warning:
javadoc
0m 58s
hbase-thrift in the patch failed.

_ Other Tests _

+1 :green_heart:
unit
1m  5s
hbase-protocol-shaded in the patch passed.

+1 :green_heart:
unit
1m 15s
hbase-client in the patch passed.

+1 :green_heart:
unit
148m 26s
hbase-server in the patch passed.

+1 :green_heart:
unit
4m 58s
hbase-thrift in the patch passed.

+1 :green_heart:
unit
7m 12s
hbase-shell in the patch passed.

204m 26s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/3/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2215

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 9495be7c570f 4.15.0-65-generic #74-Ubuntu SMP Tue Sep 17 17:06:04 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / a535c7b1af

Default Java
2020-01-14

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/3/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-client.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/3/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-server.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/3/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-thrift.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/3/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-client.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/3/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-server.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/3/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-thrift.txt

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/3/testReport/

Max. process+thread count
4291 (vs. ulimit of 12500)

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/3/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
4m 44s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+0 :ok:
prototool
0m  0s
prototool was not available.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 38s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 39s
master passed

+1 :green_heart:
checkstyle
2m 41s
master passed

+1 :green_heart:
spotbugs
7m 46s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 24s
the patch passed

+1 :green_heart:
checkstyle
0m 10s
The patch passed checkstyle in hbase-protocol-shaded

+1 :green_heart:
checkstyle
0m 32s
The patch passed checkstyle in hbase-client

+1 :green_heart:
checkstyle
1m  9s
hbase-server: The patch generated 0 new + 105 unchanged - 2 fixed = 105 total (was 107)

+1 :green_heart:
checkstyle
0m 41s
The patch passed checkstyle in hbase-thrift

+1 :green_heart:
checkstyle
0m 12s
The patch passed checkstyle in hbase-shell

-0 :warning:
rubocop
0m 12s
The patch generated 7 new + 352 unchanged - 0 fixed = 359 total (was 352)

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
12m  5s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1.

+1 :green_heart:
hbaseprotoc
3m 26s
the patch passed

+1 :green_heart:
spotbugs
10m 28s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
1m  6s
The patch does not generate ASF License warnings.

63m 32s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/4/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2215

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle cc hbaseprotoc prototool rubocop

uname
Linux bed34c38dc6b 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / c81ef7368e

rubocop
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/4/artifact/yetus-general-check/output/diff-patch-rubocop.txt

Max. process+thread count
95 (vs. ulimit of 12500)

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/4/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f) spotbugs=3.1.12 rubocop=0.80.0

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
4m 44s
Docker mode activated.

-0 :warning:
yetus
0m  4s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 26s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 41s
master passed

+1 :green_heart:
compile
3m  2s
master passed

+1 :green_heart:
shadedjars
5m 50s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 58s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 27s
the patch passed

+1 :green_heart:
compile
3m  3s
the patch passed

+1 :green_heart:
javac
3m  3s
the patch passed

+1 :green_heart:
shadedjars
5m 33s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 55s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
0m 45s
hbase-protocol-shaded in the patch passed.

+1 :green_heart:
unit
1m  6s
hbase-client in the patch passed.

-1 :x:
unit
139m 33s
hbase-server in the patch failed.

+1 :green_heart:
unit
4m 41s
hbase-thrift in the patch passed.

+1 :green_heart:
unit
7m 25s
hbase-shell in the patch passed.

190m 29s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/4/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2215

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 2cc118e1b8db 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / c81ef7368e

Default Java
1.8.0_232

unit
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/4/artifact/yetus-jdk8-hadoop3-check/output/patch-unit-hbase-server.txt

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/4/testReport/

Max. process+thread count
4471 (vs. ulimit of 12500)

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell U: .

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 32s
the patch passed

+1 :green_heart:
compile
3m 37s
the patch passed

+1 :green_heart:
javac
3m 37s
the patch passed

+1 :green_heart:
shadedjars
6m 27s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 25s
hbase-client in the patch failed.

-0 :warning:
javadoc
0m 40s
hbase-server in the patch failed.

-0 :warning:
javadoc
0m 58s
hbase-thrift in the patch failed.

_ Other Tests _

+1 :green_heart:
unit
1m  2s
hbase-protocol-shaded in the patch passed.

+1 :green_heart:
unit
1m 16s
hbase-client in the patch passed.

-1 :x:
unit
191m 23s
hbase-server in the patch failed.

+1 :green_heart:
unit
5m 26s
hbase-thrift in the patch passed.

+1 :green_heart:
unit
7m  1s
hbase-shell in the patch passed.

244m 29s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/4/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2215

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 86643aa1a219 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / c81ef7368e

Default Java
2020-01-14

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/4/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-client.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/4/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-server.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/4/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-thrift.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/4/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-client.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/4/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-server.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/4/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-thrift.txt

unit
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/4/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-hbase-server.txt

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/4/testReport/

Max. process+thread count
3414 (vs. ulimit of 12500)

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/4/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
3m 49s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+0 :ok:
prototool
0m  0s
prototool was not available.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 33s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 27s
master passed

+1 :green_heart:
checkstyle
2m 43s
master passed

+1 :green_heart:
spotbugs
7m 23s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 15s
the patch passed

+1 :green_heart:
checkstyle
0m 11s
The patch passed checkstyle in hbase-protocol-shaded

+1 :green_heart:
checkstyle
0m 33s
The patch passed checkstyle in hbase-client

+1 :green_heart:
checkstyle
1m  4s
hbase-server: The patch generated 0 new + 105 unchanged - 2 fixed = 105 total (was 107)

+1 :green_heart:
checkstyle
0m 41s
The patch passed checkstyle in hbase-thrift

+1 :green_heart:
checkstyle
0m 11s
The patch passed checkstyle in hbase-shell

-0 :warning:
rubocop
0m 12s
The patch generated 5 new + 352 unchanged - 0 fixed = 357 total (was 352)

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
11m  9s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1.

+1 :green_heart:
hbaseprotoc
2m 53s
the patch passed

+1 :green_heart:
spotbugs
8m  5s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
1m  1s
The patch does not generate ASF License warnings.

55m 32s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/5/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2215

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle cc hbaseprotoc prototool rubocop

uname
Linux 66622b95b49b 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / ea26463a33

rubocop
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/5/artifact/yetus-general-check/output/diff-patch-rubocop.txt

Max. process+thread count
94 (vs. ulimit of 12500)

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell U: .

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 58s
the patch passed

+1 :green_heart:
compile
3m 28s
the patch passed

+1 :green_heart:
javac
3m 28s
the patch passed

+1 :green_heart:
shadedjars
5m 45s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 25s
hbase-client in the patch failed.

-0 :warning:
javadoc
0m 41s
hbase-server in the patch failed.

-0 :warning:
javadoc
0m 49s
hbase-thrift in the patch failed.

_ Other Tests _

+1 :green_heart:
unit
0m 57s
hbase-protocol-shaded in the patch passed.

+1 :green_heart:
unit
1m  9s
hbase-client in the patch passed.

+1 :green_heart:
unit
131m 15s
hbase-server in the patch passed.

+1 :green_heart:
unit
4m 30s
hbase-thrift in the patch passed.

+1 :green_heart:
unit
7m  3s
hbase-shell in the patch passed.

181m 32s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/5/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2215

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 73da96982412 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / ea26463a33

Default Java
2020-01-14

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/5/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-client.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/5/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-server.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/5/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-thrift.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/5/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-client.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/5/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-server.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/5/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-thrift.txt

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/5/testReport/

Max. process+thread count
4025 (vs. ulimit of 12500)

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/5/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
2m 51s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 20s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 56s
master passed

+1 :green_heart:
compile
3m  0s
master passed

+1 :green_heart:
shadedjars
6m  4s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 55s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 49s
the patch passed

+1 :green_heart:
compile
2m 58s
the patch passed

+1 :green_heart:
javac
2m 58s
the patch passed

+1 :green_heart:
shadedjars
6m  1s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 54s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
0m 47s
hbase-protocol-shaded in the patch passed.

+1 :green_heart:
unit
1m  6s
hbase-client in the patch passed.

+1 :green_heart:
unit
199m 44s
hbase-server in the patch passed.

+1 :green_heart:
unit
5m 27s
hbase-thrift in the patch passed.

+1 :green_heart:
unit
8m 15s
hbase-shell in the patch passed.

250m 45s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/5/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2215

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 9ce636cda1fa 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / ea26463a33

Default Java
1.8.0_232

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/5/testReport/

Max. process+thread count
3728 (vs. ulimit of 12500)

modules
C: hbase-protocol-shaded hbase-client hbase-server hbase-thrift hbase-shell U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2215/5/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.


[cherry-pick][branch-2.0] Fix unknown error in global dictionary when predicate both has suppor…

cherry-pick #3422

run starrocks_be_unittest


High-speed writes to keyboard trigger memory fault

The keyboard's WriteCell function always returns false (indicating an invalid address) - so whenever you write to it, it always triggers a memory fault, even if the write was actually successful.
(This is easily worked around by disabling interrupts when accessing a keyboard)

Looking at the code:

Writing anything to location 0 removes the first key in the buffer
Writing a value to any other location removes the first occurrence of that value from the buffer

Would it suffice to allow locations 0 and 1 as valid locations?


Show details during a progress

With the progress module, if you print information about the data in treatment, the progress bar is broken.
Example:
for i in progress.bar(range(100)):
    print(i)
    sleep(random() * 0.2)

It could be useful to add a method to print the current data processed, under the progress bar for example:
for i in progress.bar(range(100)):
    progress.details(i)
    sleep(random() * 0.2)

I don't know, each solution is good, but it could be complicated to implement, couldn't it ?
Maybe the easiest way to implement this, we should only authorize one string without line breaks by iteration, and put the string at the right of the progress bar.
It's enough in the most cases.
Ideally, it could be wonderful to have the three solutions ;-)


refactor(trading): pane stores for grid state

Related issues 🔗
Closes #3396
Closes #3397
Description ℹ
Adds a way for panes to store state and connects panes that display data grids to store the current filters and sort orders. Going forward we can use these stores to manage other pane based settings.
Demo 📺
N/A
Technical 👨🔧

Adds useDataGridEvents hook to connect resize, filter and sort events to a component
Adds zustand stores for each pane. These are initialized in the app only, not in libs so as not to leak local storage into other apps.
Remove useBottomPlaceholder hook. For now buttons might overlay the bottom rows, the incoming pane context menu will resolve this.
Remove useColumnSizes

I'm getting empty rows after applying sort by size in closed orders table and then go to rejected and go back to closed

@bglownia pushed some changes.

Removed subscribeWithSelector
Fixed filters. I had actually broken these. The onGridReady function for the order list that set initial filter state was being overridden by the one from useDataGridEvents. I've updated orders-container to use a hook which handles the special cases for the order list
Added slices to prevent grid store functionality repetition


Do the developers have any plans to parse a2l files?

I use a2lparser to parse a2l files, but the library is written in java and cannot be called well in .netI use a2lparser to parse a2l files, but the library is written in java and cannot be called well in .net

this is the a2lparser:https://github.com/Luncher91/A2LParser

Hi,
no, no such plans at the moment.
Regards
A


Reusable workflow to create cluster

From a sample application focussed GitHub repository that leverages GitHub action workflows as part of it's value prop..... It'd be great to be able to call a reusable workflow homed in this repository to create an AKS cluster and associated resources. This way the sample app focussed repo can concentrate on the steps AFTER the cluster exists.
Parameters needed

Cluster Name
Cluster parameter preset / URI to a publicly accessible parameter file

@khowling you did this in #283 !


Unfollow

PrismaClientKnownRequestError:
Invalid prisma.follower.delete() invocation:
An operation failed because it depends on one or more records that were required but not found. Record to delete does not exist.
at _n.handleRequestError (/usr/src/app/node_modules/@prisma/client/runtime/library.js:123:6854)
at _n.handleAndLogRequestError (/usr/src/app/node_modules/@prisma/client/runtime/library.js:123:6188)
at _n.request (/usr/src/app/node_modules/@prisma/client/runtime/library.js:123:5896)
at async l (/usr/src/app/node_modules/@prisma/client/runtime/library.js:128:10871)
at async UserService.unfollowUser (/usr/src/app/src/services/userService.js:195:24)
at async /usr/src/app/src/routes/api.js:178:7 {
code: 'P2025',
clientVersion: '5.10.2',
meta: { modelName: 'Follower', cause: 'Record to delete does not exist.' }
}
Error: Error removing follower from database:
Invalid prisma.follower.delete() invocation:
An operation failed because it depends on one or more records that were required but not found. Record to delete does not exist.
at UserService.unfollowUser (/usr/src/app/src/services/userService.js:206:13)
at async /usr/src/app/src/routes/api.js:178:7

The bug can be recreated by running the simulator against an empty db.
But the sample data from src/minitwit_scenario.csv contains unfollow actions that are not preceded by follow actions. So is the bug on our end or the simulator data?


Turning capital letters off

Hello,
How can I turn capital letters off? It looks less suspicious when the bot doesn't use them in pokemon names

Hmm, there is no such option as of now. You can create a request at the Feature Requests.


link for the backend no longer works

the weight download link for the backend no longer works. could you send it to me please. (my email<EMAIL_ADDRESS>

http://www.mediafire.com/file/l1b96fk7j18yi7v/backend.h5/file

very good. It works I downloaded it. thank you so much

thank .problem solved


Check open [cv-pls]es for changes

We could scan un-closed cv-pls requests and see if they have been changed, then we can re-review and possibly make the Q better if the OP followed up on something. Also, I think that would help with the "abandoned" close requests. - Nathan Oliver

No longer applicable after rewrite (I think?).