nuScenes Results

Hi there,
This code repo is a graet work. But I have some question about the nuScenes results.
In your current newest version of code, we prepare the data and train a model using the config you provided, and we found that the AP is much lower than that in KITTI. Do you meet the same situation? If so, is this because there are some small bugs of data processing or just because the dataset is much harder?
Thanks

I'm also working on this dataset. Do you get the results on nuScene validation split? Are there bugs coming up for the operations below rather than the provided trainval&test split?(Of course after modifying the nuscenes_data_prep() function)

python create_data.py nuscenes_data_prep --data_path=NUSCENES_TRAIN_DATASET_ROOT --version="v1.0-train" --max_sweeps=10
python create_data.py nuscenes_data_prep --data_path=NUSCENES_TRAIN_DATASET_ROOT --version="v1.0-val" --max_sweeps=10

And from my point of view, low performance is pretty normal for a new challenging dataset. You could refer to the paper https://arxiv.org/pdf/1903.11027.pdf.

The nuscenes dataset is much harder than KITTI. you should focus on nusc dist AP rather than kitti AP to match nuscenes paper result.
@yzheng97 supported version is "v1.0-trainval", "v1.0-mini" and "v1.0-test". "v1.0-val" and "v1.0-train" is invalid.

To understand why nuscenes is hard:

In this picture, all cars will be count as false negatives if your detector can't detect them but it is obviously impossible to detect them.

The nuscenes dataset is much harder than KITTI. you should focus on nusc dist AP rather than kitti AP to match nuscenes paper result.
@yzheng97 supported version is "v1.0-trainval", "v1.0-mini" and "v1.0-test". "v1.0-val" and "v1.0-train" is invalid.

Thanks for your reply.

@traveller59 ,
Do you have results in nuscenes dataset in numbers. I was wondering how much mAP you got till now.

@ghimiredhikura
car Nusc dist<EMAIL_ADDRESS>1.0, 2.0, 4.0
57.95, 65.08, 68.03, 71.30
worse than baseline in nusc paper: 76% dist AP (thresh=2.0)

@traveller59  Did you train the pointpillar to predict all 10 classes or just the car category?
In the paper of nuscenes dataset, they did not mention how to modify the hyper-parameters for nuscenes. How did you modify them? Thanks

@traveller59 Thanks for your reply, it helps a lot

@WERush no, I am working on car-only network.
some important parameters: detection range (especially z range), nms parameters. The major problem of nuscenes AP is too much false negatives. increase det range and modify nms param can decrease false negatives and greatly increase AP performance.

@traveller59  Thanks for your reply.
The baseline result (mAP=76) from nuscenes paper is obtained from a joint-training pointpillar, rather than a car-only one.  It might be a difference. By the way, are those hyper-parameters shown in car.lite.nu.config?

@WERush car.fhd.onestage.config performs worse than pointpillars in nuscenes mini train (~3500 pointcloud, custom split) and complete val (6000 pointcloud), consider try pp first. I will update config file and split method soon.
car.lite performs far worse than car.fhd and pointpillars.
pointpillars car val performance in mini train:
61, 72, 75, 77

@traveller59 Could you please update the result of all.pp.config: 50 epoch, 1/8 dataset ? The result in README.md misses the barrier category. The result in NUSCENES-GUIDE.md is the same with all.pp.lowa.config.

@traveller59  Is all.pp.config released in the latest git version? All I get in nuscenes sub folder are all.pp.mida.config, all.pp.mhead.config, all.pp.lowa.config, all.pp.largea.config,  all.pp.deprecated.config, all.fhd.config. Besides, I'd like to know which config gives the best results on nuscenes.  Thanks !

@ghimiredhikura
car Nusc dist<EMAIL_ADDRESS>1.0, 2.0, 4.0
57.95, 65.08, 68.03, 71.30
worse than baseline in nusc paper: 76% dist AP (thresh=2.0)

Does the results obtain from the model trained with the full dataset?

@WERush  Hello, are you still working on nuScenes? Do you obtain a better results with the latest config file? Thanks

To understand why nuscenes is hard:  In this picture, all cars will be count as false negatives (their bounding boxes is not empty) if your detector can't detect them but it is obviously impossible to detect them.

Hello, I am wondering how did you generate this visualize result?


Multiple repositories

I don't see how the current implementation is working with multiple  --repositories arguments.
According to the documentation of picocli the correct invocation should look like
mvn2nix --repositories https://clojars.org/repo https://repo1.maven.org/maven2 > dependencies.nix

This however causes an error message „Failed to execute goals [[package]].“
Looking deeper into picocli, there seems to be an breaking change since its version 2.0:
Options of type String have now the default-arity 1 and so the arity needs to be explicitly specified.

hey @johannesloetzsch i think the problem is that --repositories needs to be listed more than once.

Here is a concrete example
mvn2nix --repository https://jaspersoft.jfrog.io/jaspersoft/jr-ce-releases --repository  https://repo.maven.apache.org/maven2

Fixed by #23

Thanks for the fast reply and all your work on this usefull tool :)

@johannesloetzsch i appreicate the contribution.
Please be warned; i just merged a change to output JSON instead.
I'm doing still active development on the tool and hope to stabilize it within the week.
If you'd like to avoid that, consider pinning to a commit in the meantime :)

Yes, I realized, but thanks for the hint. Like that you changed it to json and great that it's under development :)
There is just a tiny regression I would suggest to be changed:
mvn2nix takes a bit to run on projects with many dependencies. At the moment the user sees no progress happening and it feels quite unresponsive. Would be nice if you could again add some (optional) logging showing which artifact is processed.

@johannesloetzsch you can toggle -v to show more information which is written to STDERR (so you can > mvn2nix-lock.json).
I thought the UNIX philosophy was write nothing to STDERR in "the happy case".
Happy to iterate on the ergonomics of it though.


fix(input): Fix floating label width

Fix floating label to resize the width to use all available space.
Fixes #688

You should keep in mind that this will cause an overflow on IE and Edge. They don't consider the scale when determining whether to overflow the parent.

@crisbeto: I think in those case we'll see the same behaviour as before this change, which is fine by me (for now).

We had a similar issue on Material 1, even though the label is scaled down to 75%, IE/Edge still consider it as if it was 100%. Then when you set it to 133% it overflows. See https://github.com/angular/material/pull/8116

@hansl are you able to see if this is an issue in IE / Edge?

Re IE/Edge I haven't had a chance to get my Windows Machine up last week. Will check it out tomorrow on a local VM.

I'm installing a VM to test this on IE 11. Will come back when done.

This seems to be working fine on IE11. Syncing up with Robert for more info.
Proof:

@crisbeto: ^ seems to work correctly. If you have something to add before we merge this in :)
Please note our DOM is largely different than Material 1, and much simpler/less reliant on hacks due to Shadow DOM and compartmentalization.

As soon as we clarify the situation with IE11/Edge I'll merge this in. :)

I'll try cloning it to check as well.

Alright, it works as it is now, but it starts overflowing if the any of the parents get overflow: auto. I'm not if it's an issue in this case, but here's what it looks like:

Interesting. By putting overflow: hidden on the md-input itself we mitigate setting it to anything above, which would be okay I guess. The worst case would be if a customer sets overflow: auto to the md-input itself, which we can say "don't do that" since there's no real reason to do it. And it would be fine if he sets it on the element above (and beyond). @crisbeto: What do you think?
@jean-merelis: Can you add overflow: hidden to the :host?

Yeah I'd say that setting a default overflow would be fine, since it's up to the end user to determine whether to override it in that case.

Thanks Kristiyan. Sorry if this was such a mess, but better be right the first time :)
After discussion with @robertmesserle seems like this is the right solution. I'll merge it as soon as Travis finishes.


Rename Accumulo master properties

After a new name is selected (#1638 and #1639) we can start making code changes.  One major change will be renaming the Accumulo master properties.  This is a user facing element so we need to come up with a good strategy for doing, which can be done before the name is selected.  The strategy can be discussed here.

The name agreed to in a vote on the mailing list was 'manager'.

I was thinking of taking this on. In looking at the Properties class, it appears it already supports Deprecated and ReplacedBy annotations on properties. Given that, I was thinking something like the following could work:

Copy all MASTER_ properties and make a MANAGER_ equivalent.
Deprecate all MASTER_ properties and set the ReplacedBy property to the corresponding MANAGER_ property.
Anywhere a MASTER_ property is used, retrieve either the new or old property using AccumuloConfiguration.resolve.

Does that seem like a reasonable strategy?

I was thinking of taking this on. In looking at the Properties class, it appears it already supports Deprecated and ReplacedBy annotations on properties. Given that, I was thinking something like the following could work:

Copy all MASTER_ properties and make a MANAGER_ equivalent.
Deprecate all MASTER_ properties and set the ReplacedBy property to the corresponding MANAGER_ property.
Anywhere a MASTER_ property is used, retrieve either the new or old property using AccumuloConfiguration.resolve.

Does that seem like a reasonable strategy?

@brianloss I think it might be a bit burdensome to use AccumuloConfiguration.resolve in so many places. Also, it might get complicated if we are monitoring any properties for changes (I'm not sure if we are). As an alternative, I was thinking we could:

Produce an error if both master.* and manager.* properties exist in the SiteConfiguration file on startup and fail to start,
Automatically remap any master.* to manager.* when loading the SiteConfiguration file, issuing a warning if any master.* are detected, and
On upgrade, rename any properties in ZooKeeper automatically.

That way, we don't need to maintain any deprecated properties side-by-side in Property.java for this, or do anything special to deal with AccumuloConfiguration.resolve. We can simply rename the enums and property keys in Property.java.

@brianloss I think it might be a bit burdensome to use AccumuloConfiguration.resolve in so many places. Also, it might get complicated if we are monitoring any properties for changes (I'm not sure if we are). As an alternative, I was thinking we could:

Produce an error if both master.* and manager.* properties exist in the SiteConfiguration file on startup and fail to start,
Automatically remap any master.* to manager.* when loading the SiteConfiguration file, issuing a warning if any master.* are detected, and
On upgrade, rename any properties in ZooKeeper automatically.

That way, we don't need to maintain any deprecated properties side-by-side in Property.java for this, or do anything special to deal with AccumuloConfiguration.resolve. We can simply rename the enums and property keys in Property.java.

@ctubbsii I don't know why I assumed Property was in the public API but since it's not, I agree your approach will be cleaner. Thanks!

@ctubbsii I don't know why I assumed Property was in the public API but since it's not, I agree your approach will be cleaner. Thanks!

I like the idea of centralizing handling of the old master props in the code and avoiding AccumuloConfiguration.resolve in lots of places. It would also be nice to avoid having lots of deprecated master props in the Accumulo Property ENUM if possible and centrally handle this special case in the code instead.  The centralized handling needs to ensure we have a concept of what the current master props are and freeze those, not mapping future new manager props to master props that never existed.
@ctubbsii I like your proposal, it seems to imply that users would no longer be able to set master props in zookeeper.  Was that what you were thinking?

I like the idea of centralizing handling of the old master props in the code and avoiding AccumuloConfiguration.resolve in lots of places. It would also be nice to avoid having lots of deprecated master props in the Accumulo Property ENUM if possible and centrally handle this special case in the code instead.  The centralized handling needs to ensure we have a concept of what the current master props are and freeze those, not mapping future new manager props to master props that never existed.
@ctubbsii I like your proposal, it seems to imply that users would no longer be able to set master props in zookeeper.  Was that what you were thinking?

@ctubbsii I like your proposal, it seems to imply that users would no longer be able to set master props in zookeeper.  Was that what you were thinking?

Yes it was. We would still support reading an old config file, but would otherwise prevent any new properties from being set using the old names.

@ctubbsii I like your proposal, it seems to imply that users would no longer be able to set master props in zookeeper.  Was that what you were thinking?

Yes it was. We would still support reading an old config file, but would otherwise prevent any new properties from being set using the old names.

Yes it was. We would still support reading an old config file, but would otherwise prevent any new properties from being set using the old names.

That means these props would not be going through a deprecation cycle? That could have a negative impact on any automation developed around Accumulo.  Its not always user sitting at terminals setting properties.

Yes it was. We would still support reading an old config file, but would otherwise prevent any new properties from being set using the old names.

That means these props would not be going through a deprecation cycle? That could have a negative impact on any automation developed around Accumulo.  Its not always user sitting at terminals setting properties.

That means these props would not be going through a deprecation cycle? That could have a negative impact on any automation developed around Accumulo. Its not always user sitting at terminals setting properties.

With my suggestion, they would still go through a deprecation cycle. While deprecated, we would still respect existing config files, but yes, it would disallow automation of the type you describe, altering these properties in ZooKeeper... at least, without any additional effort.
We could put in the additional effort of allowing such properties by translating any incoming property changes intended for the ZooKeeper store via the API from master.* to manager.* to support the automation you describe. However, I'm not sure this would really be worth it... because automation would already be negatively impacted because the returned properties when querying would not show the old properties. So, if there were automation reading, modifying, and writing, it wouldn't be able to see the master.* properties.
I'm fine with not adding in this additional effort, though, because I think the risk is pretty low. Automation of the type that would change the master.* properties without human intervention seems like it'd be a rare thing, if it exists at all.

That means these props would not be going through a deprecation cycle? That could have a negative impact on any automation developed around Accumulo. Its not always user sitting at terminals setting properties.

With my suggestion, they would still go through a deprecation cycle. While deprecated, we would still respect existing config files, but yes, it would disallow automation of the type you describe, altering these properties in ZooKeeper... at least, without any additional effort.
We could put in the additional effort of allowing such properties by translating any incoming property changes intended for the ZooKeeper store via the API from master.* to manager.* to support the automation you describe. However, I'm not sure this would really be worth it... because automation would already be negatively impacted because the returned properties when querying would not show the old properties. So, if there were automation reading, modifying, and writing, it wouldn't be able to see the master.* properties.
I'm fine with not adding in this additional effort, though, because I think the risk is pretty low. Automation of the type that would change the master.* properties without human intervention seems like it'd be a rare thing, if it exists at all.

With my suggestion, they would still go through a deprecation cycle of a sort.

Having sets of deprecated properties that behave in very different ways would be confusing from a user perspective.  It would need to be reflected in the documentation, so users know what to do.

We could put in the additional effort of allowing such properties by translating any incoming property changes intended for the ZooKeeper store via the API from master.* to manager.* to support the automation you describe.

Could try to put specialized handling in AccumuloConfiguration to map these props on lookup.  Like what resolve does, but not spreading it everywhere in the code.  This may not be additional effort but not sure.
Thinking it would be nice to centralize the handling of this large group of deprecated properties in the code (avoiding specialized per property handling in the code), but make them behave like every other deprecated property in Accumulo from a users perspective.

With my suggestion, they would still go through a deprecation cycle of a sort.

Having sets of deprecated properties that behave in very different ways would be confusing from a user perspective.  It would need to be reflected in the documentation, so users know what to do.

We could put in the additional effort of allowing such properties by translating any incoming property changes intended for the ZooKeeper store via the API from master.* to manager.* to support the automation you describe.

Could try to put specialized handling in AccumuloConfiguration to map these props on lookup.  Like what resolve does, but not spreading it everywhere in the code.  This may not be additional effort but not sure.
Thinking it would be nice to centralize the handling of this large group of deprecated properties in the code (avoiding specialized per property handling in the code), but make them behave like every other deprecated property in Accumulo from a users perspective.

I am thinking we may be too nice here.  I propose:

Fail to startup if any of the master.* properties still exist with an informative message.
Use the version upgrade mechanism to fix any overrides in zookeeper.

I am thinking we may be too nice here.  I propose:

Fail to startup if any of the master.* properties still exist with an informative message.
Use the version upgrade mechanism to fix any overrides in zookeeper.

With my suggestion, they would still go through a deprecation cycle of a sort.

Having sets of deprecated properties that behave in very different ways would be confusing from a user perspective. It would need to be reflected in the documentation, so users know what to do.

I was wondering about this too. Even though the class Property is not in the public API, by having a mechanism to deprecate properties and using that mechanism, including on master.bulk.rename.threadpool.size, it seems we're treating them as though they are part of the public API.

Could try to put specialized handling in AccumuloConfiguration to map these props on lookup. Like what resolve does, but not spreading it everywhere in the code. This may not be additional effort but not sure.

Maybe this idea is worth exploring? It seems like possibly it could be done in the get(Property) method.

With my suggestion, they would still go through a deprecation cycle of a sort.

Having sets of deprecated properties that behave in very different ways would be confusing from a user perspective. It would need to be reflected in the documentation, so users know what to do.

I was wondering about this too. Even though the class Property is not in the public API, by having a mechanism to deprecate properties and using that mechanism, including on master.bulk.rename.threadpool.size, it seems we're treating them as though they are part of the public API.

Could try to put specialized handling in AccumuloConfiguration to map these props on lookup. Like what resolve does, but not spreading it everywhere in the code. This may not be additional effort but not sure.

Maybe this idea is worth exploring? It seems like possibly it could be done in the get(Property) method.

it seems we're treating them as though they are part of the public API.

I think this treatment derives from the fact that they are user facing.  I am uncertain about the best path is in the particular situation, but I do know its good to give user facing changes a bit more consideration.  The conversation is making me think about property deprecation in Accumulo in general.

it seems we're treating them as though they are part of the public API.

I think this treatment derives from the fact that they are user facing.  I am uncertain about the best path is in the particular situation, but I do know its good to give user facing changes a bit more consideration.  The conversation is making me think about property deprecation in Accumulo in general.

Having sets of deprecated properties that behave in very different ways would be confusing from a user perspective. It would need to be reflected in the documentation, so users know what to do.

This is kind of a special case. I think we could document it well enough, and provide meaningful error/warning messages, that consistency with regular property deprecations won't matter much, because it will be clear what to do from the documentation and/or messages.

Having sets of deprecated properties that behave in very different ways would be confusing from a user perspective. It would need to be reflected in the documentation, so users know what to do.

This is kind of a special case. I think we could document it well enough, and provide meaningful error/warning messages, that consistency with regular property deprecations won't matter much, because it will be clear what to do from the documentation and/or messages.

I was looking at Property and AccumuloConfiguration and was wondering what people think about something like the following... In Property the class has a member variable replacedBy that gets filled in if the ReplacedBy annotation is on a specific Property enum (that's done by Property.precomputeAnnotations which is invoked on each property enum value. What if we changed that to something like deprecatedNames so that a given property could have its deprecated names associated with it. I say names, plural, since we already have master.bulk.rename.threadpool.size deprecated and replaced by master.rename.threadpool.size so in my example the deprecatedNames for manager.rename.threadpool.sizewould be both master.rename.threadpool.size and master.bulk.rename.threadpool.size.
With this change, we could restructure AccumuloConfiguration so that get is no longer an abstract method (we'd rename the current abstract method and all of it's implementations to something else, call it internalGet for now) and then it would call the internalGet method with the property name. If that's not found, then it could try any deprecatedNames in turn. This would allow us to maintain the old and new property names and not have to use AccumuloConfiguration.resolve. In fact, any existing deprecated properties could take advantage of this approach too. At startup, we could still go through the site configuration and warn if we find any property names that are in the deprecated.
I'm not familiar enough with the property handling code to recognize if there's some fatal flaw in this idea, so please let me know if I missed something. Barring that, it seems like it could solve the concerns with the previously suggested approaches for this ticket and also provide a cleaner mechanism for any future property deprecations.

I was looking at Property and AccumuloConfiguration and was wondering what people think about something like the following... In Property the class has a member variable replacedBy that gets filled in if the ReplacedBy annotation is on a specific Property enum (that's done by Property.precomputeAnnotations which is invoked on each property enum value. What if we changed that to something like deprecatedNames so that a given property could have its deprecated names associated with it. I say names, plural, since we already have master.bulk.rename.threadpool.size deprecated and replaced by master.rename.threadpool.size so in my example the deprecatedNames for manager.rename.threadpool.sizewould be both master.rename.threadpool.size and master.bulk.rename.threadpool.size.
With this change, we could restructure AccumuloConfiguration so that get is no longer an abstract method (we'd rename the current abstract method and all of it's implementations to something else, call it internalGet for now) and then it would call the internalGet method with the property name. If that's not found, then it could try any deprecatedNames in turn. This would allow us to maintain the old and new property names and not have to use AccumuloConfiguration.resolve. In fact, any existing deprecated properties could take advantage of this approach too. At startup, we could still go through the site configuration and warn if we find any property names that are in the deprecated.
I'm not familiar enough with the property handling code to recognize if there's some fatal flaw in this idea, so please let me know if I missed something. Barring that, it seems like it could solve the concerns with the previously suggested approaches for this ticket and also provide a cleaner mechanism for any future property deprecations.

I'm not familiar enough with the property handling code to recognize if there's some fatal flaw in this idea, so please let me know if I missed something.

The broad strokes you mentioned SGTM, if there is a fatal flaw it will certainly show up during implementation.  It seems like a good general change  that may make the prop deprecation code more maintainable, centralized, and consistent.
Trying to think about how the proposal relates to this issue, I am trying to think of special cases that are unique to this large set of deprecated properties. One thing that comes to mind, is having a gigantic list of individually deprecated master props in the generated props docs.  That would be noisy and not very useful.
Not sure if this documetation still works, it outlines how to render the props docs.

I'm not familiar enough with the property handling code to recognize if there's some fatal flaw in this idea, so please let me know if I missed something.

The broad strokes you mentioned SGTM, if there is a fatal flaw it will certainly show up during implementation.  It seems like a good general change  that may make the prop deprecation code more maintainable, centralized, and consistent.
Trying to think about how the proposal relates to this issue, I am trying to think of special cases that are unique to this large set of deprecated properties. One thing that comes to mind, is having a gigantic list of individually deprecated master props in the generated props docs.  That would be noisy and not very useful.
Not sure if this documetation still works, it outlines how to render the props docs.

@brianloss There are a few concerns I'd have with that proposal:

Extra complexity (it seems a little more complicated and a lot more code changing than the previous proposals),
I think we should encourage phase out of these deprecated stuffs, not continued support indefinitely for code or properties that have been discontinued (this plan sounds like the intent is to support "old names" in perpetuity; in this case, we actually want to discontinue the use of the term "master" in its entirety; this is possibly true for other cases, as well, however, for many other cases), and
Properties are rarely simply renamed... they are most often changed because of a shift in their semantics. Supporting "old names" implies simple renames. That is the case for this change, but this is, as I've said, a special case.

I agree with @keith-turner 's concern about having a gigantic list of individually deprecated properties in the docs. I had been thinking about that as well. In the proposal I suggested, it would be simple to add a section to the generated properties documentation to document that (and how) the master. prefix is deprecated.

@brianloss There are a few concerns I'd have with that proposal:

Extra complexity (it seems a little more complicated and a lot more code changing than the previous proposals),
I think we should encourage phase out of these deprecated stuffs, not continued support indefinitely for code or properties that have been discontinued (this plan sounds like the intent is to support "old names" in perpetuity; in this case, we actually want to discontinue the use of the term "master" in its entirety; this is possibly true for other cases, as well, however, for many other cases), and
Properties are rarely simply renamed... they are most often changed because of a shift in their semantics. Supporting "old names" implies simple renames. That is the case for this change, but this is, as I've said, a special case.

I agree with @keith-turner 's concern about having a gigantic list of individually deprecated properties in the docs. I had been thinking about that as well. In the proposal I suggested, it would be simple to add a section to the generated properties documentation to document that (and how) the master. prefix is deprecated.

@brianloss There are a few concerns I'd have with that proposal:

Extra complexity (it seems a little more complicated and a lot more code changing than the previous proposals),

I'm not sure it's that complicated since the changes would be pretty much limited to Property and AccumuloConfiguration (changes to the AccumuloConfiguration sub-classes would be through IDE refactoring). I had been thinking I might prototype it and see, but the idea was just a thought, and see below...

I think we should encourage phase out of these deprecated stuffs, not continued support indefinitely for code or properties that have been discontinued (this plan sounds like the intent is to support "old names" in perpetuity; in this case, we actually want to discontinue the use of the term "master" in its entirety; this is possibly true for other cases, as well), and

I wasn't intending that we'd support the old names indefinitely, but rather follow semver rules (even though we don't have to for the properties) and have them be fully supported until the next major release when they could be removed.

Properties are rarely simply renamed... they are most often changed because of a shift in their semantics. Supporting "old names" implies simple renames. That is the case for this change, but this is, as I've said, a special case.

I agree with @keith-turner 's concern about having a gigantic list of individually deprecated properties in the docs. I had been thinking about that as well. In the proposal I suggested, it would be simple to add a section to the generated properties documentation to document that (and how) the master. prefix is deprecated.

That's a fair point about simple renames. If we don't think they're likely to happen again any time soon and we don't think our user community will be upset about a partially incompatible change (not being able to use set the old property names in Zookeeper) on a minor version release, then I can just implement what you suggested. I also agree the documentation is important and we wouldn't want the noise of a huge list of deprecated properties in the docs.

@brianloss There are a few concerns I'd have with that proposal:

Extra complexity (it seems a little more complicated and a lot more code changing than the previous proposals),

I'm not sure it's that complicated since the changes would be pretty much limited to Property and AccumuloConfiguration (changes to the AccumuloConfiguration sub-classes would be through IDE refactoring). I had been thinking I might prototype it and see, but the idea was just a thought, and see below...

I think we should encourage phase out of these deprecated stuffs, not continued support indefinitely for code or properties that have been discontinued (this plan sounds like the intent is to support "old names" in perpetuity; in this case, we actually want to discontinue the use of the term "master" in its entirety; this is possibly true for other cases, as well), and

I wasn't intending that we'd support the old names indefinitely, but rather follow semver rules (even though we don't have to for the properties) and have them be fully supported until the next major release when they could be removed.

Properties are rarely simply renamed... they are most often changed because of a shift in their semantics. Supporting "old names" implies simple renames. That is the case for this change, but this is, as I've said, a special case.

I agree with @keith-turner 's concern about having a gigantic list of individually deprecated properties in the docs. I had been thinking about that as well. In the proposal I suggested, it would be simple to add a section to the generated properties documentation to document that (and how) the master. prefix is deprecated.

That's a fair point about simple renames. If we don't think they're likely to happen again any time soon and we don't think our user community will be upset about a partially incompatible change (not being able to use set the old property names in Zookeeper) on a minor version release, then I can just implement what you suggested. I also agree the documentation is important and we wouldn't want the noise of a huge list of deprecated properties in the docs.

Extra complexity

I agree that lots of complexity should not be added to the code to support this one case. The complexity of the Accumulo code base could be considered in conjunction w/ the complexity of the user experience.  Having sets of deprecated properties w/ different runtime behaviors is a complicated user experience.  An ideal solution would reduce the complexity of both, not sure it exists though.

Properties are rarely simply renamed..

There is a good point.  There was not a 1:1 relationship between the deprecated prop and replacements in the recent PR #1861 I did.

I think we should encourage phase out of these deprecated stuffs, not continued support indefinitely for code or properties that have been discontinued

This is really its own issue, but this comment made me think of the following. If we wanted to adopt something more aggressive than semver for removing deprecated props, doing it before 2.1 is released is a good time. Thinking any prop deprecated before an LTS release could be removed in main after the LTS is released (this would be more relaxed that semver possibly).  Not sure about non-LTS releases.  The new policy could be documented and warnings logged for deprecated props could mention when the removal will happen.

Extra complexity

I agree that lots of complexity should not be added to the code to support this one case. The complexity of the Accumulo code base could be considered in conjunction w/ the complexity of the user experience.  Having sets of deprecated properties w/ different runtime behaviors is a complicated user experience.  An ideal solution would reduce the complexity of both, not sure it exists though.

Properties are rarely simply renamed..

There is a good point.  There was not a 1:1 relationship between the deprecated prop and replacements in the recent PR #1861 I did.

I think we should encourage phase out of these deprecated stuffs, not continued support indefinitely for code or properties that have been discontinued

This is really its own issue, but this comment made me think of the following. If we wanted to adopt something more aggressive than semver for removing deprecated props, doing it before 2.1 is released is a good time. Thinking any prop deprecated before an LTS release could be removed in main after the LTS is released (this would be more relaxed that semver possibly).  Not sure about non-LTS releases.  The new policy could be documented and warnings logged for deprecated props could mention when the removal will happen.

I don't think we should adopt anything more aggressive than semver for deprecated props, but I do think this is a special case that may need to be considered apart from what we might do "normally", and that it's okay to flex semver under special circumstances. However, I don't think we need to do that here. Given the conversation indicating a desire to keep support for setting new properties in the API using the old names, I think we can preserve deprecation consistency with very simple changes, that keep complexity low for users and maintainers:

remap SiteConfiguration props on load,
remap ZooConfiguration on upgrade, and
remap props for setProperty() on API call.

(All with appropriate log messages and updated documentation, of course.)
The remapping function could even be located in a single place, to make it easier to drop support for the deprecated props in the next major release.

I don't think we should adopt anything more aggressive than semver for deprecated props, but I do think this is a special case that may need to be considered apart from what we might do "normally", and that it's okay to flex semver under special circumstances. However, I don't think we need to do that here. Given the conversation indicating a desire to keep support for setting new properties in the API using the old names, I think we can preserve deprecation consistency with very simple changes, that keep complexity low for users and maintainers:

remap SiteConfiguration props on load,
remap ZooConfiguration on upgrade, and
remap props for setProperty() on API call.

(All with appropriate log messages and updated documentation, of course.)
The remapping function could even be located in a single place, to make it easier to drop support for the deprecated props in the next major release.


Initial Commit

Issue #: /bcgov/entity#6858
Description of changes:

Added sample articles for other Limited, unlimited companies.

Updated unit tests.

Updated Header block and tooltips for non BCOMP entities.

NOTE:

Still pending a design discussion as what to do for CCC's in the incorporation agreement.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the bcrs-entities-create-ui license (Apache 2.0).

Looks good so far.
Is the "sample articles" blurb the same for all entity types so far?

Very close, Bcomps is a little different :(


CI: use maven OTEL extension in the CI

What does this PR do?
It consumes https://github.com/elastic/opentelemetry-maven-extension in the CI
IMPORTANT: it uses the same service name where the traces from Jenkins are sent to, in this case, apm-ci
Test
The URL to the distributed traces can be found in the comment -> https://github.com/elastic/apm-agent-java/pull/2103#:~:text=commented-,3 days ago,-•
Then click on elastic|observability badge
See the below screenshot that illustrates what we can see now:

:broken_heart: Build Failed

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

Start Time: 2021-09-03T09:16:34.314+0000

Duration: 3 min 27 sec

Commit: 4fb2e116ab9783219cc5592ccf78ac68fac0be79

Trends :test_tube:

Steps errors
Expand to view the steps failures

Sleep

Took 0 min 0 sec . View more details on here
Description: 10

mvn install

Took 0 min 0 sec . View more details on here
Description: ./mvnw clean install -DskipTests=true -Dmaven.javadoc.skip=true -Dmaven.ext.class.path=.mvn/opentelemetry-maven-extension.jar

Log output
Expand to view the last 100 lines of log output

[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:920)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1082)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1040)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:920)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1082)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1040)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:920)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1082)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1040)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:920)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1082)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1040)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:920)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1082)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1040)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:920)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.river.BlockMarshaller.doWriteObject(BlockMarshaller.java:65)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.river.BlockMarshaller.writeObject(BlockMarshaller.java:56)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.MarshallerObjectOutputStream.writeObjectOverride(MarshallerObjectOutputStream.java:50)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.river.RiverObjectOutputStream.writeObjectOverride(RiverObjectOutputStream.java:179)
[2021-09-03T09:19:55.995Z] 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:344)
[2021-09-03T09:19:55.995Z] 	at java.util.HashMap.internalWriteEntries(HashMap.java:1793)
[2021-09-03T09:19:55.995Z] 	at java.util.HashMap.writeObject(HashMap.java:1363)
[2021-09-03T09:19:55.995Z] 	at sun.reflect.GeneratedMethodAccessor414.invoke(Unknown Source)
[2021-09-03T09:19:55.995Z] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[2021-09-03T09:19:55.995Z] 	at java.lang.reflect.Method.invoke(Method.java:498)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.reflect.JDKSpecific$SerMethods.callWriteObject(JDKSpecific.java:156)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.reflect.SerializableClass.callWriteObject(SerializableClass.java:191)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1028)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:920)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1082)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1040)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:920)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:58)
[2021-09-03T09:19:55.995Z] 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:111)
[2021-09-03T09:19:55.995Z] 	at org.jenkinsci.plugins.workflow.support.pickles.serialization.RiverWriter.lambda$writeObject$0(RiverWriter.java:144)
[2021-09-03T09:19:55.995Z] 	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:237)
[2021-09-03T09:19:55.995Z] 	at org.jenkinsci.plugins.workflow.support.pickles.serialization.RiverWriter.writeObject(RiverWriter.java:143)
[2021-09-03T09:19:55.995Z] 	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.saveProgram(CpsThreadGroup.java:557)
[2021-09-03T09:19:55.995Z] 	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.saveProgram(CpsThreadGroup.java:534)
[2021-09-03T09:19:55.995Z] 	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.saveProgramIfPossible(CpsThreadGroup.java:517)
[2021-09-03T09:19:55.995Z] 	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:441)
[2021-09-03T09:19:55.995Z] 	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$400(CpsThreadGroup.java:96)
[2021-09-03T09:19:55.995Z] 	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:312)
[2021-09-03T09:19:55.995Z] 	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:276)
[2021-09-03T09:19:55.995Z] 	at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:67)
[2021-09-03T09:19:55.995Z] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[2021-09-03T09:19:55.995Z] 	at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:139)
[2021-09-03T09:19:55.995Z] 	at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
[2021-09-03T09:19:55.995Z] 	at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:68)
[2021-09-03T09:19:55.995Z] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[2021-09-03T09:19:55.995Z] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[2021-09-03T09:19:55.995Z] 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[2021-09-03T09:19:55.995Z] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[2021-09-03T09:19:55.995Z] 	at java.lang.Thread.run(Thread.java:748)
[2021-09-03T09:19:55.995Z] Retrying
[2021-09-03T09:19:57.474Z] Stage "Tests" skipped due to earlier failure(s)
[2021-09-03T09:19:57.681Z] Stage "Unit Tests" skipped due to earlier failure(s)
[2021-09-03T09:19:57.694Z] Stage "Smoke Tests 01" skipped due to earlier failure(s)
[2021-09-03T09:19:57.706Z] Stage "Smoke Tests 02" skipped due to earlier failure(s)
[2021-09-03T09:19:57.719Z] Stage "Benchmarks" skipped due to earlier failure(s)
[2021-09-03T09:19:57.729Z] Stage "Javadoc" skipped due to earlier failure(s)
[2021-09-03T09:19:57.920Z] Failed in branch Unit Tests
[2021-09-03T09:19:57.930Z] Failed in branch Smoke Tests 01
[2021-09-03T09:19:57.940Z] Failed in branch Smoke Tests 02
[2021-09-03T09:19:57.949Z] Failed in branch Benchmarks
[2021-09-03T09:19:57.960Z] Failed in branch Javadoc
[2021-09-03T09:19:58.256Z] Stage "Integration Tests" skipped due to earlier failure(s)
[2021-09-03T09:19:58.356Z] Stage "JDK Compatibility Tests" skipped due to earlier failure(s)
[2021-09-03T09:19:58.665Z] Stage "Matrix - JAVA_VERSION = 'openjdk12'" skipped due to earlier failure(s)
[2021-09-03T09:19:58.671Z] Stage "Matrix - JAVA_VERSION = 'openjdk13'" skipped due to earlier failure(s)
[2021-09-03T09:19:58.677Z] Stage "Matrix - JAVA_VERSION = 'openjdk14'" skipped due to earlier failure(s)
[2021-09-03T09:19:58.682Z] Stage "Matrix - JAVA_VERSION = 'openjdk15'" skipped due to earlier failure(s)
[2021-09-03T09:19:58.688Z] Stage "Matrix - JAVA_VERSION = 'openjdk16'" skipped due to earlier failure(s)
[2021-09-03T09:19:58.788Z] Stage "Matrix - JAVA_VERSION = 'openjdk12'" skipped due to earlier failure(s)
[2021-09-03T09:19:58.797Z] Stage "Matrix - JAVA_VERSION = 'openjdk13'" skipped due to earlier failure(s)
[2021-09-03T09:19:58.804Z] Stage "Matrix - JAVA_VERSION = 'openjdk14'" skipped due to earlier failure(s)
[2021-09-03T09:19:58.811Z] Stage "Matrix - JAVA_VERSION = 'openjdk15'" skipped due to earlier failure(s)
[2021-09-03T09:19:58.817Z] Stage "Matrix - JAVA_VERSION = 'openjdk16'" skipped due to earlier failure(s)
[2021-09-03T09:19:59.226Z] Failed in branch Matrix - JAVA_VERSION = 'openjdk12'
[2021-09-03T09:19:59.235Z] Failed in branch Matrix - JAVA_VERSION = 'openjdk13'
[2021-09-03T09:19:59.246Z] Failed in branch Matrix - JAVA_VERSION = 'openjdk14'
[2021-09-03T09:19:59.257Z] Failed in branch Matrix - JAVA_VERSION = 'openjdk15'
[2021-09-03T09:19:59.267Z] Failed in branch Matrix - JAVA_VERSION = 'openjdk16'
[2021-09-03T09:19:59.558Z] Stage "Stable" skipped due to earlier failure(s)
[2021-09-03T09:19:59.660Z] Stage "AfterRelease" skipped due to earlier failure(s)
[2021-09-03T09:19:59.704Z] Stage "AfterRelease" skipped due to earlier failure(s)
[2021-09-03T09:20:00.273Z] Running on Jenkins in /var/lib/jenkins/workspace/_java_apm-agent-java-mbp_PR-2103
[2021-09-03T09:20:00.430Z] [INFO] getVaultSecret: Getting secrets
[2021-09-03T09:20:00.477Z] Masking supported pattern matches of $VAULT_ADDR or $VAULT_ROLE_ID or $VAULT_SECRET_ID
[2021-09-03T09:20:01.628Z] + chmod 755 generate-build-data.sh
[2021-09-03T09:20:01.628Z] + ./generate-build-data.sh https://apm-ci.elastic.co/blue/rest/organizations/jenkins/pipelines/apm-agent-java/apm-agent-java-mbp/PR-2103/ https://apm-ci.elastic.co/blue/rest/organizations/jenkins/pipelines/apm-agent-java/apm-agent-java-mbp/PR-2103/runs/1 FAILURE 207039
[2021-09-03T09:20:01.628Z] INFO: curl https://apm-ci.elastic.co/blue/rest/organizations/jenkins/pipelines/apm-agent-java/apm-agent-java-mbp/PR-2103/runs/1/steps/?limit=10000 -o steps-info.json
[2021-09-03T09:20:01.628Z] INFO: curl https://apm-ci.elastic.co/blue/rest/organizations/jenkins/pipelines/apm-agent-java/apm-agent-java-mbp/PR-2103/runs/1/tests/?status=FAILED -o tests-errors.json
[2021-09-03T09:20:01.628Z] Retry 1/3 exited 22, retrying in 1 seconds...
[2021-09-03T09:20:02.971Z] Retry 2/3 exited 22, retrying in 2 seconds...

:grey_exclamation: Flaky test report
No test was executed to be analysed.

jenkins run the tests please

jenkins run the tests please

jenkins run the tests please

jenkins run the tests please

Awesome!
I don't know if it's related to this PR (or the Jenkins job otel integration in general), but is that expected that the transaction name on Kibana is apm-agent-java/apm-agent-java-mbp/PR-{number} without the appropriate PR number ?

I don't know if it's related to this PR (or the Jenkins job otel integration in general), but is that expected that the transaction name on Kibana is apm-agent-java/apm-agent-java-mbp/PR-{number} without the appropriate PR number ?

Yes, that's expected and caused by the Jenkins Otel plugin

we decided to pick a quite generic root span name like my-war/PR-{number} to have a low cardinality span name.
The pattern my-war/PR-{number} is the solution we picked to comply with the OpenTelemetry Specification for span names defined in opentelemetry-specification/specification/trace/api.md

I copied the above from https://github.com/jenkinsci/opentelemetry-plugin/issues/141#issuecomment-877145082 that answered a question I asked about a higher cardinality and the reasons.


Add information about HeaderBackButton

I've ran into a scene where I'd like to override the onPress of back button without changing its looks.
I've searched and found that you can import HeaderBackButton component, but I couldn't find that being mentioned in the document, so I'm adding information for other people who runs into same problem.
READ ME PLEASE!
TL;DR: Make sure to add your changes to versioned docs
Thanks for opening a PR!
The docs cover several versions of react-navigation, and in some cases there are several files (for version 1, version 2 and etc.) that all describe a single page of the docs (eg. "Getting Started").
Please make sure that the edit you're making in docs/file-you-edited.md is also included in the file for the correct version, eg. /versioned_docs/version-3.x/file-you-edited.md for version 3. If such file doesn't exist, please create it. :+1:

@Naturalclar can you update the link of HeaderBackButton, please?

@eriveltonelias thanks! I've updated the link

thanks!


mydumper: 0.16.9-1 -> 0.17.0-1

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for mydumper is: High-performance MySQL backup tool
meta.homepage for mydumper is: https://github.com/mydumper/mydumper
meta.changelog for mydumper is: https://github.com/mydumper/mydumper/releases/tag/v0.17.0-1
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.17.0-1 with grep in /nix/store/dsqzs4b5nqcckf3mkjmqjxxx6kh2pvn1-mydumper-0.17.0-1
found 0.17.0-1 in filename of file in /nix/store/dsqzs4b5nqcckf3mkjmqjxxx6kh2pvn1-mydumper-0.17.0-1

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

mydumper

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/dsqzs4b5nqcckf3mkjmqjxxx6kh2pvn1-mydumper-0.17.0-1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A mydumper https://github.com/r-ryantm/nixpkgs/archive/e6cb5a82e1cd8057d5c38207c1e6e30829a49956.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/e6cb5a82e1cd8057d5c38207c1e6e30829a49956#mydumper

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/dsqzs4b5nqcckf3mkjmqjxxx6kh2pvn1-mydumper-0.17.0-1
ls -la /nix/store/dsqzs4b5nqcckf3mkjmqjxxx6kh2pvn1-mydumper-0.17.0-1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review

x86_64-linux

:white_check_mark: 3 packages built:

mydumper
mydumper.doc
mydumper.man

Maintainer pings
cc @Izorkin @michaelglass for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

@NixOS/nixpkgs-merge-bot built on darwin & linux. looks good

@NixOS/nixpkgs-merge-bot merge


DOC: Add a few previously documented functions [1.1.1]

d2i_X509_bio(), d2i_X509_fp(), i2d_X509_bio(), and i2d_X509_fp()
were documented in OpenSSL 1.0.2.  In a grand unification of the
documentation of (almost) all d2i and i2d functions, these were
dropped, most likely by mistake.
This simply adds them back.
Fixes #17091

This pull request is ready to merge

Merged
6052078d410cb00b58ebd5eb44e8f746a4850321 DOC: Add a few previously documented functions


Mm 47648 check license expandable

Summary

Show the CTA to purchase additional seats when the license is suitable to be self-expand.
Ticket Link

https://mattermost.atlassian.net/browse/MM-47648
Related Pull Requests

Has server changes https://github.com/mattermost/mattermost-server/pull/21770

Screenshots

Release Note

Overage users can expand their license seats.

If I understand, expandability is determined by data already available on the subscription's product, the product's billing_scheme, which is already available in the front end. Do we need to add another fetch to calculate this. I would think that even if it depends on something like age or size of subscription, all that is already available to the front end and we could derive it from that data with a selector instead of adding another redux key. Very possible I'm missing part of the picture on what determines expandability.

@neallred I understand the reason to avoid another request, as it was my first thought, but to do it that way would be:

AFIK, when you load a self hosted license, we are not loading the subscription data on the front side. The endpoint to get the subscription only allows cloud licenses https://github.com/mattermost/mattermost-server/blob/966456567d55141c7a0bd2daa6d63a5b3da937e4/api4/cloud.go#L57. It would require more changes than only a few changes on Server
We allow getting the subscription related a self hosted. The next step is sending the metadata we use to detect this condition. I'm unsure if we want to send it to the webapp.

IMO, the downsides out-weight the benefits of calculating on the front. Creating a new endpoint would allow us to expand it without waiting for the users to update the front.
I can probably improve the UX as I'm rendering the Contact Sales CTA and then swapping it if the response is ok.

Ahh, ok! I forgot this was for self-hosted so subscription isn't available. Makes sense to me now why we would do it this way.

/update-branch

/e2e-test

Successfully triggered E2E testing!
GitLab pipeline | Test dashboard

A pipeline with the same environment variables is already running.
Please cancel it first with /e2e-cancel, or specify different environment variables.

/e2e-cancel

Looks like nothing had to be canceled.

/e2e-test

Successfully triggered E2E testing!
GitLab pipeline | Test dashboard

I've assigned this to myself for doc work. There are some copy changes that I'd like to make but I'll submit them separately.


Crash on load

When launch the loader as administrator, injection being success but game crashing.

What RedHook2 version are you using?
Are you using the Epic Games launcher or the Rockstar Games launcher?
If you're on 1.0.1 could you provide the log located at RedHook2/logs/hook.log?

Hi, I compiled RedHook2 and the sample project from the source. Got that crash. After that, tried with your Released 1.0.1 version, it's same. Loader is works (injected another dll with your loader successful). It's Rockstar Games Launcher version.
And there is not any RedHook2/logs/hook.log

Since there are no longs, std::filesystem::create_directories("RedHook2/logs"); might be throwing an exception. Would you be able to try wrapping a try catch around it and see if that changes anything?

    void CreateLogs()
    {
        try
        {
            std::filesystem::create_directories("RedHook2/logs");

            logs::g_hLog = logging::LogMgr::CreateLog<logging::GenericFileLogger>(
                "hook_log", "RedHook2/logs/hook.log");
        }
        catch (const std::runtime_error& re)
        {
            std::cerr << "Runtime error: " << re.what() << std::endl;
        }
        catch (const std::exception& ex)
        {
            std::cerr << "Error occurred: " << ex.what() << std::endl;
        }
        catch (...)
        {
            std::cerr << "Unknown failure occurred. Possible memory corruption" << std::endl;
        }

    }

Just tried with that code, still can't run and also I forgot to write that is the error I got.

After realize that, I re-compiled from source and changed the target to Release from Debug, the error was gone but still get crash after injection.

abort() has been called

I was able to fix this by manually creating the dirs RedHook2 and RedHook2/logs in the RDR2 game dir.

It's odd that the try catch of @irfn-net didn't work then. Maybe something is going wrong in the logging if the directories don't exist. Creating the directories with ShellExecute might be a good solution.

I tried doing the solution @lmc came up with however I still get the same crash on startup.


[Table] Very laggy when create more than 20 rows on Chrome

I tried create 20 rows in a table on Chrome. It becomes very slow to select any rows. But It is ok on Safari.
I don't know if that's the Chrome's problem.

It turns out affect Chrome on all platforms

My best guess here is that we have a rerendering issue. Implementing the shouldComponentUpdate may help.

I thought I had this problem too but then I realized it only happened when I had the React Dev tools activated. I'm working with a table ~550 rows.

For me, it's laggy only when React Dev tools is enabled.

Table performance is definitely extremely laggy.  Even at 100 rows, it's pretty slow which is kind of unacceptable.  Had to move to facebook's fixed-data-table but ideally these performance are addressed in Material UI.

+1.
When Checkbox is used for table row selection, the performance degrades further more, which makes the table unusable after 50 rows on Chrome. The performance issue of Checkbox has been reported with #2832

Also having this problem. I've removed React Dev Tools completely and the problem persists. I removed  check boxes, and the problem gets a bit better. When I disable selectability (and manually respond to row taps) the problem goes away completely. I've tested this in the latest versions of Chrome, Firefox and Safari, with no difference in the result.

Covered by #2832 and #3289

Found a solution on SA and it works perfectly:
https://stackoverflow.com/a/37025337/1550476