Dropwizard as simple Elastic Search proxy

Feature Request
Desired behaviour
Hook up Dropwizard to allow Elastic Search queries. This is followed up updating the AngularJS-Elastic search prototype.

This is now available as both a AngularJS prototype in the webservice ( http://localhost:8080/static/elastic_demo_ui/demo.html ) and a Angular one in ui2 ( http://localhost:4200/admin-search )


Broken page edition UI for RTL languages

Issue Summary
In page editing UI when language is a RTL one things get funny (broken)
See this
Steps to Reproduce
Active a RTL language of your choice

I have confirmed that this issue can be reproduced as described on a fresh Wagtail project

Technical details

Wagtail version: 4.1.1

Hey @engAmirEng @zerolab ,
I would like to give a try to this issue.

It seems Tailwind CSS not supporting RTL. For this specific issue I made a workaround:

Create a CSS admin hook inside wagtail_hooks.py

from django.conf import settings
from django.templatetags.static import static
from django.utils.html import format_html
from django.utils.translation import get_language_bidi
from wagtail import hooks

@hooks.register("insert_global_admin_css")
def global_admin_css():
    if get_language_bidi():
        return format_html(
            '<link rel="stylesheet" href="{}">',
            static("extended/wagtail/rtl.css"),
        )
    return ""

Inside the specified static path (extended/wagtail/rtl.css):

.form-side {
    --tw-translate-x: -100%;
}

.form-side--open {
    --tw-translate-x: 0%;
}

There are most probably many more issues (especially with Tailwind CSS) which could resolved by try-and-errors and then added to this file or, a better solution (and more time consuming) would be to add decent support for RTL inside Wagtail's Tailwind CSS codes.

It seems Tailwind CSS not supporting RTL. For this specific issue I made a workaround:

Create a CSS admin hook inside wagtail_hooks.py

from django.conf import settings
from django.templatetags.static import static
from django.utils.html import format_html
from django.utils.translation import get_language_bidi
from wagtail import hooks

@hooks.register("insert_global_admin_css")
def global_admin_css():
    if get_language_bidi():
        return format_html(
            '<link rel="stylesheet" href="{}">',
            static("extended/wagtail/rtl.css"),
        )
    return ""

Inside the specified static path (extended/wagtail/rtl.css):

.form-side {
    --tw-translate-x: -100%;
}

.form-side--open {
    --tw-translate-x: 0%;
}

There are most probably many more issues (especially with Tailwind CSS) which could resolved by try-and-errors and then added to this file or, a better solution (and more time consuming) would be to add decent support for RTL inside Wagtail's Tailwind CSS codes.

Hey,
It makes the the opening and closing the preview panel fixed, thanks for that,
can you make something similar for other two main problems? I mean
1-broken panel preview for tablet and desktop (the mobile preview seems fine)
2-and the blinking of the minimap

👋 thanks for reporting this! We don’t currently formally support right-to-left languages, so as much as I’d like to see this fixed, to me this is an enhancement rather than a bug in the intended behavior.
There are a lot of known issues with how the admin interface displays with RTL languages (see #7793 for more context). If anyone wants to help getting this particular issue sorted, I’d really recommend making a pull request directly to Wagtail rather than making your own rtl.css overrides (though that’s definitely a good workaround in the short term).
If anyone thinks this really ought to be treated as a bug, then you need to spend some time making the case for why Wagtail should now officially support RTL languages, backed with a summary of known issues so we don’t claim support for something that’s completely broken.

Back to this specific issue – I believe none of our usage of CSS translations (translateX) is reversed in RTL languages. So my preference would be to fix this for all areas of the UI at once – introduce a CSS variable equal to 1 or -1 depending on the language direction, and use that variable in all our translations to change their direction.

Looks awsome, thanks 👍


Fix bugs in tts.py

If you input text that is entirely silent, such as ".......", the audio array will be empty, and therefore np.concatenate will fail. This adds a check for that.
The example code was using an old function name that has since been renamed.
It was also transposing the audio when the function already did that.
At least for me, the sd.sleep call was far too short to actually hear any audio. Using sd.wait sleeps for exactly the right time, without having to calculate it manually.

Very cool project, looking forward to this being completed with a full on hardware rig. :thumbsup:
Some things I'll probably look into after this:

Figuring out if there's a way to register the TTS with espeak directly, so that other programs too can use GlaDOS's voice.
Using the referenced distil-whisper as ggml-medium-32-2 linked in the installation instructions seems to take far too long to be real-time on my laptop for some reason.
Hooking up an LLM to llm.py via a server using the OpenAI API, so that the LLM can keep running when the TTS is restarted.

Let me know if you're interested in pull requests upstream for any of those.

Sure, always happy for pull requests.
On your three points

Can you clarify what you want to do exactly?

I use a GPU, and ASR + TTS is basically real time. Try downsizing the distil small, or moving using acceleration hardware.

OpenAI interfaces should be easy to add. My goal is a fully local GlaDOS, who understands she is running on a gaming PC.

I'll test and merge your Bugfixes soon, 👍

One extra thing to note, if you use the tts.py module:
Using this code:
sd.sleep(int(1000 * audio.shape[1] / RATE))
is probably what you want. It's non-blocking, so you can use the LLM to generate more text while the generated voice audio is playing.
Using:
sd.wait()
is blocking, so you can't get anything else done.   In the name == "main" demo, the audio doesn't play because the program ends before the audio finishes, whilst your bugfix sd.wait() keeps it running.

1. Can you clarify what you want to do exactly?

Basically, figuring out a way so running espeak "hello world" outputs in GlaDOS's voice. Ideally in a way so that programmatic access from other programs without using the shell works seamlessly, e.g. Firefox has a feature where it can use the system TTS in article reader mode. Not sure if this is possible, as I have no experience with espeak or TTS infrastructure on Linux in general, but it would be cool to have GlaDOS integrated with existing TTS APIs.

2. I use a GPU, and ASR + TTS is basically real time. Try downsizing the [distil small](distil-whisper/distil-small.en), or moving using acceleration hardware.

Looks like I had a minor misunderstanding when writing the initial post, I had assumed that ggml-medium-32-2 was not distil-whisper as it seems distil-whisper uses inconsistent naming (the small variant is named ggml-distil-small).
Anyway, I've now tried both. With ggml-medium-32-2 on the CPU, having whisper.cpp transcribe the jfk.wav sample provided in its repo (./main -m models/ggml-medium-32-2.en.bin  -f samples/jfk.wav) takes some 12 seconds, with distil-small 4 seconds. The demo.ipynb echo example also takes around 4 seconds for GlaDOS to repeat "hello there" back to me. (This was initially much worse, when I wrote the initial post it was at 35 seconds, but I've now been able to disable some of my laptop's power saving settings). 4 seconds is still a noticeable delay unfortunately, but much better than the 35 secs of my initial test, and tolerable. I'm still confused how in the video example in the whisper.cpp readme it runs in about a second on an iPhone 13 mini, without using distil.

3. OpenAI interfaces should be easy to add. My goal is a fully local GlaDOS, who understands she is running on a gaming PC.

Fully agree, the API is just to have it connect to an already locally running LLM.


Extends life of monsteres

This PR changes how long a monster can live without feeding.
The factor hunger_hp_modifier is changed from 1 to 5. This implies that the monster still gets hungry after 10 hours, but then still has HP for another 50 hours.
The ricardian contracts still needs to be updated to reflect this change. All users with living monsters need to agree that the monsters can now live longer (and the users RAM is blocked in this contract for longer)

Thanks @friedger, that's exactly what we need although it comes from a config table now (our global config singleton). So actually we should just add a method to change this field of the table like changecrtol, changebatma, changebatidt. I'm going to close it for now and follow up on #74 which is in our new project.


Ha tool regions

copy of @aspiers 's PR to upstream repo: madkiss#21

I prefer hyphens in branch names, but whatever ;-)  BTW we didn't need a PR for this - you could have pushed the new branch directly.


updates for v4.0 and minor tweaks

Put a versions.json in here for v4 and couldn't help but fix up a bunch of things:

put the name in the downloads list, Node.js or io.js
put a correct download URL
change a whole lot of "node.js" to "Node.js", sorry, I've got a beef with this one, does anyone object? @mikeal, @fhemberger?
change NPM to npm in the header of the downloads table

LGTM :+1:

Added some text to a release post, please review @mikeal and others, @nodejs/tsc perhaps? See the big locale/en/blog/release/v4.0.0.md  file in this PR.

Will review shortly. 10-15 minutes or so
On Sep 8, 2015 2:12 PM, "Rod Vagg"<EMAIL_ADDRESS>wrote:

Added some text to a release post, please review @mikeal
https://github.com/mikeal and others, @nodejs/tsc
https://github.com/orgs/nodejs/teams/tsc perhaps? See the big
locale/en/blog/release/v4.0.0.md file in this PR.
—
Reply to this email directly or view it on GitHub
https://github.com/nodejs/new.nodejs.org/pull/110#issuecomment-138555669
.

you have time, I'm rerunning tests and making builds and whatnot since the late addition of the handle zapping change

Added a new section on build/platforms/arm:

Over the past year thanks to donations from companies such as Rackspace, DigitalOcean, Scaleway, miniNodes, Voxer, ARM Holdings, and individuals from the community, we've built an amazing test cluster that includes an impressive line-up of Linux variants, OS X, Windows, FreeBSD and SmartOS. New to Node.js, we also have first-class support for ARM processors. Our test suite must be continually passing on ARMv6, ARMv7 and the new 64-bit ARMv8 processors. So Node.js is officially ready for use by hobbyists and ARM server users alike.

Text looks good as well.

Looks good on initial read through. Nothing major sticks out.

+1 to what @jasnell said.

Comments inline. Other than that, +1


metaData to store for natural_breaks to create data categories

This is good work.
However, we decided to refactor the code because the code can be simpler if we query the json files directly.
Also, there are multiple app features that rely on the refactored way of querying the json files.


Fix dropdown icon padding

The dropdown icon have too much bottom padding. This PR fixes this.
From:

To:

Signed-off-by: Andrew Thornton<EMAIL_ADDRESS>

Codecov Report

Merging #6651 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #6651      +/-   ##
==========================================
- Coverage   40.55%   40.54%   -0.01%
==========================================
  Files         406      406
  Lines       54501    54501
==========================================
- Hits        22101    22100       -1
- Misses      29362    29365       +3
+ Partials     3038     3036       -2

Impacted Files
Coverage Δ

models/unit.go
0% <0%> (-14.29%)
:arrow_down:

models/repo_list.go
66.84% <0%> (-1.06%)
:arrow_down:

modules/log/log.go
71.42% <0%> (+2.52%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1bce189...d733ec9. Read the comment docs.

Please send back port to v1.8

@lunny done.


Call for Stage 3 Reviews

Hi All,
I'm seeking Stage 3 advancement at the March meeting (< 3 weeks away), and in order to do that, I need a spec review.

Reviewers:

[x] @bakkot
[ ] @DanielRosenwasser

Spec Editors

[x] @bakkot
[ ] @ljharb
[ ] @michaelficarra
[ ] @syg

Please add any comments here.

var a = 1; (a) += 4; a; is valid; can someone confirm if var a = 1; (a) &&= 4; a; is also valid? If so, it seems like perhaps we don't want to add more parenthesized LHS's to the language?

You explained in https://github.com/tc39/proposal-logical-assignment/issues/15#issuecomment-596054653 that LogicalAssignmentPunctuator is just for viewability within the proposal, but could we call this out in a Section 1 note, so it's understood that we don't mean to merge it that way?

can someone confirm if var a = 1; (a) &&= 4; a; is also valid?

It is, and this is covered by the AssignmentTargetType static error in https://tc39.es/proposal-logical-assignment/#sec-assignment-operators-static-semantics-early-errors. The AssignmentTargetType of the (a) in (a) &&= 4 is simple, due to:

https://tc39.es/ecma262/#sec-grouping-operator-static-semantics-assignmenttargettype
https://tc39.es/ecma262/#sec-identifiers-static-semantics-assignmenttargettype

If so, it seems like perhaps we don't want to add more parenthesized LHS's to the language?

It'd actually take considerably more work to change this behavior, we'd have to plumb  an entirely new AssignmentTargetType through the spec.

could we call this out in a Section 1 note, so it's understood that we don't mean to merge it that way?

Sure.

It'd actually take considerably more work to change this behavior, we'd have to plumb an entirely new AssignmentTargetType through the spec.

Without offering an opinion on whether this change should be made, I don't think this is true: you could just have an Early Error to the effect of
AssignmentExpression : LeftHandSideExpression LogicalAssignmentOperator AssignmentExpression

It is a Syntax Error if LeftHandSideExpression is PrimaryExpression : CoverParenthesizedExpressionAndArrowParameterList.

(Similar wording is used in the Early Errors for delete.)
Of course, it might be better to have a new AssignmentTargetType instead of this.

On reflection, I think it'd be best to allow these parenthesized LHSes (i.e., keep the current spec). Banning weird syntax whenever there is any new syntax involved, even though that syntax is very similar to existing syntax, causes trouble for implementations and does not obviously benefit anyone.
For example, we recently removed the restriction that you could not have try {} catch (e) { for (var e of foo); } (note the duplicate e), which strikes me as a pretty similar situation.

In that case, that's because that's a reasonable thing to want to do :-) when would you actually want to put parens around the LHS?

That was not why we relaxed that restriction. It was explicitly because the restriction caused difficulty for implementations and did not obviously benefit anyone. The same is true here.
Also, that is definitely not a reasonable thing to want to do, at least not with the semantics it has. (The var e declares a variable in the outer function scope, but the loop assigns to the e created by the catch binding.)

Review approval pending https://github.com/tc39/proposal-logical-assignment/pull/20

LGTM

I agree that we should allow parenthesized LHSes.
LGTM editorially. Only suggestion is when preparing the PR for merge, please make sure the strict mode note isn't duplicated for every single production.

LGTM. I think we could've described the error behaviour inline in the algorithm steps instead of in a big note that references step numbers (gross), but I see that it's just consistent with what's already there, so it's fine for now.

One more point I almost forgot: in the same way as https://github.com/tc39/proposal-nullish-coalescing/pull/50, it would be good to rename LogicalAssignmentOperator to ShortCircuitAssignmentOperator.
(I know the name of the proposal is a foregone thing but we can still editorialize the spec text. :joy:)

My understanding is that "LogicalAssignmentOperator" won't actually be in the spec PR; it was just a device to show the diff in this repo?

@ljharb That's LogicalAssignmentPunctuator, but the similarity is in fact why I forgot to mention this earlier. 😅

whoops, good call then :-)

Update: I've opened https://github.com/tc39/proposal-logical-assignment/issues/23 to discuss adding a NamedEvaluation to anonymous functions that are the RHS.


Argoexec init contariner meet OOMKilled issue

Pre-requisites

[X] I have double-checked my configuration
[X] I can confirm the issues exists when I tested with :latest
[ ] I'd like to contribute the fix myself (see contributing guide)

What happened/what you expected to happen?
The argoexec init container OOMKilled.
I think that 64Mi memory is enough for init container.
We are looking for the right limit to set and that we check the differences between environments but we cannot correlate.
Need argo workflow team to check why argoexec init container use more memory than 64Mi. it's abnormal.
And which cause the init container use more memory?
Init Containers:
init:
Container ID:  containerd://3eb8993d0faaec1cd0862bde4e92e33558ca6e329e2e0c960d101a69ad4cc22b
Image:         quay.io/argoproj/argoexec:latest
Image ID:      quay.io/argoproj/argoexec@sha256:5cd920d5e57cdc0881f13a9b39238cea462eee59ea35a39f1142b7994a27a5fd
Port:
Host Port:
Command:
argoexec
init
--loglevel
debug
--log-format
text
State:          Terminated
Reason:       OOMKilled
Exit Code:    137
Started:      Mon, 12 Jun 2023 16:19:37 +0800
Finished:     Mon, 12 Jun 2023 16:19:38 +0800
Ready:          False
Restart Count:  0
Limits:
cpu:     500m
memory:  64Mi
Requests:
cpu:     100m
memory:  64Mi
Version
V3.4.8 or lastest
Paste a small workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflows that uses private images.
argo workflow configmap set as this:
 kubectl get cm workflow-controller-configmap -o yaml -n argo
apiVersion: v1
data:
  executor: |
    imagePullPolicy: IfNotPresent
    resources:
      requests:
        cpu: 0.1
        memory: 64Mi
      limits:
        cpu: 0.5
        memory: 64Mi
    args:
    - --loglevel
    - debug
    - --gloglevel
    - "6"

Logs from the workflow controller
time="2023-06-16T06:01:51.629Z" level=info msg="node changed" namespace=XXXXX
new.message="OOMKilled (exit code 137)" new.phase=Failed new.progress=0/1 nodeID=XXXXXX old.message= old.phase=Pending old.progress=0/1 workflow=XXXXXX
time="2023-06-16T06:01:51.631Z" level=info msg="node XXXXXX message: OOMKilled (exit code 137)" namespace=XXX workflow=XXX.." ... level=deb type: 'Warning' reason: 'WorkflowNodeFailed' Failed node XXXXXXX: OOMKilled (exit code 137)"

Logs from in your workflow's wait container
k logs podname -n xxx -c init
time="2023-06-09T08:32:45.385Z" level=info msg="Starting Workflow Executor" version=untagged
time="2023-06-09T08:32:45.454Z" level=info msg="Using executor retry strategy" Duration=1s Factor=1.6 Jitter=0.5 Steps=5
time="2023-06-09T08:32:45.454Z" level=info msg="Executor initialized" deadline="0001-01-01 00:00:00 +0000 UTC" includeScriptOutput=false 。。。,Platform:linux/amd64,}"

and no other log to print.(because print this pod is OOMKilled)

need modificate.

have u got large input artifact? I used to have OOM on it but setting my init container to 160MB fixed it

I'm not setting the large input artifact.

To clarify a bit further (I am a coworker of @taoc2021 ), if we do a deploy, on most of our clusters, it works fine.
But on specific clusters, we get a higher amount of memory usage (resulting in OOMKilled).
What factors can cause increased argoexec memory usage? We noticed a 3 MB memory increase in endpoints init compared to the other clusters, does the memory used scale with the amount of endpoints in the namespace?

@taoc2021 You can take a look at the code starting from here and see if you can find anything that could relate to your issue.

@juliev0 We are seeing the same thing, specifically in our KubeFlow pipelines which take two inputs as KubeFlow InputPath objects. Basically just dynamically resolved paths.
We expect our init container running Argoexec to download these artifacts specified by the input paths (from S3). However, we get an OOM. It appears that Argoexec is loading these artifacts in their entirety into memory, while we expected the behavior to be that these artifacts are streamed (and chunked).
Can you clarify if this is indeed the behavior of Argoexec?

@juliev0 We are seeing the same thing, specifically in our KubeFlow pipelines which take two inputs as KubeFlow InputPath objects. Basically just dynamically resolved paths.
We expect our init container running Argoexec to download these artifacts specified by the input paths (from S3). However, we get an OOM. It appears that Argoexec is loading these artifacts in their entirety into memory, while we expected the behavior to be that these artifacts are streamed (and chunked).
Can you clarify if this is indeed the behavior of Argoexec?

Here I see it is downloading it to a file, not loading it into memory. For S3 that's ultimately calling this. (Not sure how that one operates under the hood.)

Oh, I think it may be that the shared volume on the Pod (so main container and init container can share these input files) is of "EmptyDir" type which could be storing in memory? I'm seeing this here:
The emptyDir.medium field controls where emptyDir volumes are stored. By default emptyDir volumes are stored on whatever medium that backs the node such as disk, SSD, or network storage, depending on your environment. If you set the emptyDir.medium field to "Memory", Kubernetes mounts a tmpfs (RAM-backed filesystem) for you instead. While tmpfs is very fast, be aware that unlike disks, tmpfs is cleared on node reboot and any files you write count against your container's memory limit.

That's a interesting consideration. Our EmptyDir is specified with
EmptyDir: {}
So I'd expect it to be saved to disk, unless there is some way it could be still using RAM. Will see if I can verify

have u got large input artifact? I used to have OOM on it but setting my init container to 160MB fixed it

How did you set the initcontainer memory?

That's a interesting consideration. Our EmptyDir is specified with EmptyDir: {}  So I'd expect it to be saved to disk, unless there is some way it could be still using RAM. Will see if I can verify

We just ran into same issue. I tried to investigate more, but wasn't able to found anything as of init is running for a short time and it's hard to debug. Describe give info that volumes:
input-artifacts:
Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
Medium:
SizeLimit:
So it's not Medium: Memory
But with size of artifacts init starts failing.

I'd expect larger objects to require more memory during unarchiving/decompression, so OOM seems reasonable. You could prove it by disabling artifact compression compressionLevel: 0 or removing "archiving" (the act of putting all the artifacts into a tar container)
archive:
  none: {}

have u got large input artifact? I used to have OOM on it but setting my init container to 160MB fixed it

How did you set the new resources settings for the initContainer?

We are using the podSpecPatch to path the containers.  For templates that launch a "work" container, it looks like this:
  templates:
    - name: main
      podSpecPatch: |
        initContainers:
          - name: init
            resources:
              requests:
                cpu: 100m
                memory: 400Mi
              limits:
                memory: 900Mi
        containers:
          - name: wait
            resources:
              requests:
                cpu: 100m
                memory: 400Mi
              limits:
                memory: 900Mi
      steps:

For a template that creates a resource, it looks like this:
    - name: re-index-a
      inputs:
        parameters:
          - name: district
          - name: process-time
      retryStrategy:
        limit: 3
      synchronization:
        semaphore:
          configMapKeyRef:
            name: controller-synchronization
            key: re-index-a
      podSpecPatch: |
        initContainers:
          - name: init
            resources:
              requests:
                cpu: 100m
                memory: 400Mi
              limits:
                memory: 900Mi
        containers:
          - name: main
            resources:
              requests:
                cpu: 100m
                memory: 400Mi
              limits:
                memory: 900Mi
      resource:
        action: create
        manifest: |

But the issue that we are seeing is that the memory requirements for the containers in the pods seem awfully large.  Generally, they start with just under 400Mi and sometimes go up from that.  I wouldn't think the command should need that much memory.


Release 0.10.0

@kostub I prepared the release for you, hoping you can give this a quick merge and tag.

Updates change log
Bumps version number in podspec to 0.10.0

Closes #127

@kostub Could we plan a release? Maybe not this one, but one that includes the stackrel command support in #129?

@kostub this PR to release 0.10.0 has been opened since September. Have you dropped iosMath? No longer maintaining it? If you don't have the time, I'd like to help. Maybe you can make a maintainer and I can handle some of these things.

I can merge this in. But I couldn't get a new pod release out as I had a some difficulty building it and didn't have time to investigate.

What do you mean difficulty building it? Building the project? It builds fine for me.

Maybe I can add a simple CI to this project. Would you be onboard for it?


Generate bindings for indexed struct properties

This allows to export fields of tuple-like structs as indexed JS properties.
While we could rename it to _0, $0 or something else, this feels like the most natural mapping of "indexed" properties to JavaScript concepts, and just works out of the box with current JS and TypeScript codegens.

Seems reasonable to me, thanks @RReverser! Could you ensure that this is documented in the reference as well?

Ah yes. I'm leaving for the Easter holiday now but can back to it afterwards.

@alexcrichton Hmm, I might need help figuring out where best to put it. There currently doesn't seem to be a dedicated section describing how named properties are bound on the JS side? (I've found only exported_types.rs, but it doesn't demonstrate properties usage, only the class itself)

Ah that's true yeah, mind starting a page which describes the JS api created for exported rust structures? It could go in the area for attributes on exports perhaps in the reference

I'm thinking maybe just adding some property usage to the same existing exported-rust-types.md + exported_types.rs + exported_types.js?

I've added property examples to files mentioned above, let me know how it looks.

Thanks!


NEW: add Idle Finance

Add Idle Finance security contact and deployed addresses link

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Hi @bugduino
Thank you for your contribution


Add new rule for validating email fields

This new rule will validate those columns in the dictionary that are emails. For now, the list of email columns will be hardcoded in the rule.

PR: #87


Shinyappsio deploy

@afwillia I have merged your docs from main to develop. That's why there is no difference.
I suggest you change .txt to .md. It will make your dos shown in the PR and I think markdown is easier to read.

@afwillia
I have added the CLI to auto add secrets and also updated some steps based on your docs, here.
Please have a look if you think that makes sense.


Feather set displays wrong icons

I've just updated RN vectors icons to the latest version. My project is using Feather icon set, after updating, all the icons display wrongly.

+1

I've got the same issue on Android but not on iOS

package display pocket
message-circle display package
thumbs-up display video-off
heart display log-out

It seem there is a shift of 18 in the font range.

Same mess, icons display wrongly.

Have you tried this? https://github.com/oblador/react-native-vector-icons#wrong-icons-are-shown-after-upgrading-this-package

It was that, it's fixed now, thank's ! And sorry to forgot to read the Troubleshooting section 😅

No worries man, you'll remember next time 😉 Closing this as it probably solves this problem for the rest of you as well (it's a common issue on Android), otherwise feel free to reopen this issue 🙂


[Codegen] Add op for copying tensor operands

This is useful for providing an anchor to tile a copy of a particular tensor operand. The advantage of this over alternatives like pad and pack is that it does not require any fixup operations on the destination of a linalg op.

Yeah pretty much. This is just useful for experimentation so I didn't bother sending it upstream.


Finalize release 3.2.1

v3.2.1 is referenced in the changelog, and has an updated NTP leapseconds file which is most useful prior to 2017/1/1.
However, a release hasn't been finalized and uploaded to supermarket. Would it be possible to get this done?

3.3.1 is up now


Dhook/beta merge conflict resolution

Alaska Airlines Pull Request
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes: # (issue, if applicable)
Summary:
Please summarize the scope of the changes you have submitted, what the intent of the work is and anything that describes the before/after state of the project.
Type of change:
Please delete options that are not relevant.

[ ] New capability
[ ] Revision of an existing capability
[ ] Infrastructure change (automation, etc.)
[ ] Other (please elaborate)

Checklist:

[ ] My update follows the CONTRIBUTING guidelines of this project
[ ] I have performed a self-review of my own update

By submitting this Pull Request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Pull Requests will be evaluated by their quality of update and whether it is consistent with the goals and values of this project. Any submission is to be considered a conversation between the submitter and the maintainers of this project and may require changes to your submission.
Thank you for your submission!
-- Auro Design System Team

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.4 out of 5 committers have signed the CLA.:white_check_mark: blackfalcon:white_check_mark: jason-capsule42:white_check_mark: DukeFerdinand:white_check_mark: jordanjones243:x: semantic-release-botYou have signed the CLA already but the status is still pending? Let us recheck it.


Not required to pass -DefaultProfile

It's not required to pass -DefaultProfile  for this command to work as indicated in here -> https://docs.microsoft.com/en-us/powershell/module/az.operationalinsights/set-azoperationalinsightsintelligencepack?view=azps-4.1.0

@nthewara : Thanks for your contribution! The author(s) have been notified to review your proposed change.


Add Ev3 Sensor Modes

Description
Depends on #8
Adds ColorSensorMode (reflected, ambient, color) for the Lego Ev3ColorSensor. Adds GyroSensorMode (angle, rate) for Lego Ev3GyroSensor.
Also removes old methods like SetReflectedMode and SetAngleMode from components, because there's no reason to have them now that we have informative dropdowns.
Testing
Upgrading
I tested that blocks get properly upgraded using this project: test10.zip
They go from this:

To this:

Functionality
I wasn't able to test the functionality as I don't own an Ev3. But I did test that setting and getting the values works as expected
Recommended Method for Review
Commit-wise

Forgot about the ultrasonic sensor! It now has similar changes to the other sensors for its Unit setter.


Challenge view

If the user has a result for the challenge, don't display it on the profile

[x] Checked on staging


Add Appendix A: Keywords to Sway book

Description
closes #4932
Checklist

[ ] I have linked to any relevant issues.
[ ] I have commented my code, particularly in hard-to-understand areas.
[ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book).
[ ] I have added tests that prove my fix is effective or that my feature works.
[ ] I have added (or requested a maintainer to add) the necessary Breaking* or New Feature labels where relevant.
[ ] I have done my best to ensure that my PR adheres to the Fuel Labs Code Review Standards.
[ ] I have requested a review from the relevant team or maintainers.

I have not checked all the links to ensure that they point to where they ought to
Unfortunately, I really do not have the bandwidth to make individual suggestions for each definition but I would re-write most / almost all of the definitions to be more accurate / concise. Most aren't bad but ought to be updated imo

Appreciate the review, all the links I found should check out! As far as the definitions I tried to make it as boiled down as possible, using rust's appendix as reference (https://doc.rust-lang.org/book/appendix-01-keywords.html). However, I can change any you feel need to be updated.

Thank you for your contribution! Can you update the links to the sway book so that they are all relative instead of absolute urls? This way the versions won't need to be updated.

I went ahead and set all the urls to the relative path in the book, but lost some precision the links had. Let me know if this works, or if there is a better way of doing it!

Thank you for your contribution! Can you update the links to the sway book so that they are all relative instead of absolute urls? This way the versions won't need to be updated.

I went ahead and set all the urls to the relative path in the book, but lost some precision the links had. Let me know if this works, or if there is a better way of doing it!

The reference seems to always point to a page instead of a specific heading. I don't recall if I did that because I couldn't link it precisely or because each section was meant to be a small page. If the page is too full then changing that page will inevitably lead to headings being changed and links being broken so it's better to structure content per page in a digestible manner.
I haven't tested the links but I wonder if we should be mixing the book and reference. The reference was meant to entirely replace the book, and hopefully it will before mainnet.

Thanks! I have one more nit: can you move this page into the existing Sway Reference section and remove the Appendix section?

Which you mind further elaborating where inside the reference section you would prefer this to be moved to?
Should I create an Appendix in the Reference section?

Thanks! I have one more nit: can you move this page into the existing Sway Reference section and remove the Appendix section?

Would you mind further elaborating where inside the reference section you would prefer this to be moved to? Should I create an Appendix in the Reference section?

Move entire section from the book into the reference at the bottom

Number 11 in the navigation of the Sway Book is "Sway Reference". You can move the keywords page into that section, add to the existing index.md with a link, and delete the apendix folder.


Releases, changelogs, and/or tags for major, minor, and patches

There are currently no releases (on github), changelogs, or tags for any versions of this library.  I'd ideally like to see them for all major, minor, and patch versions released to npm so I can see what changed.

Sorry. We prioritised getting bug fixes out over writing release notes this week. We'll get this in order soon.

@gaearon I think the CHANGELOG.md is fine for now for the release notes, but tagging is a simple way to show up on Releases without much effort.
You can add one line before publishing to npm, based on:
https://docs.npmjs.com/cli/version

We'll be tagging future releases.


*** NotImplementedError: Deep copy doesn't work for mutables.

when I try to copy.deepcopy a model designed by nas mutables, it alerts *** NotImplementedError: Deep copy doesn't work for mutables.

This is by design. Deep copy on mutables will cause problems thus we forbid it.
And we are not maintaining the old versions of NAS any more. Please try to use Retiarii if possible.


MacOS "can't open dynamic library / not found in the current scope" errors

After installing the plugin, I was unable to use SteamMultiplayerPeer. I resolved the issue by updating three lines in the steam-multiplayer-peer.gdextension file. Specifically, I added "macos.framework" to the paths of the lines that began with macos.debug, macos.release, and macos.universal. Additionally, I had to remove the ".framework" extension from the release and debug lines.
After making these changes, I encountered errors stating, "... can't be opened because Apple cannot check it for malicious software." To resolve this, I had to manually open each file within the macos.framework directory through Finder to approve.
I am not opening a pull request because I'm unsure if this is an acceptable solution. Thank you.
Updated Lines:
macos.debug = "macos/macos.framework/libsteam-multiplayer-peer.macos.template_debug"
macos.release = "macos/macos.framework/libsteam-multiplayer-peer.macos.template_release"
.
.
.
macos.universal = { "macos/macos.framework/libsteam_api.dylib": "" }
Godot Version: v4.2.2.stable.official [15073afe3]
Steam Multiplayer Peer Version: 0.1.1
OS: MacOS Sonoma 14.4.1

yeah I had the same issue. Even fixing the file path, the library still fails on create_host call for me with error code 20

yeah I had the same issue. Even fixing the file path, the library still fails on create_host call for me with error code 20

same problem here, godot 4.3 on macos, fixed the paths but got error on create_host with code 2
windows is working
func _on_lobby_created(conn, id) -> void:
	print("Lobby creation attempt. Result: ", conn)
	if conn == 1:
		lobby_id = id
		print("Lobby ID: ", lobby_id)
		print("Creating host...")
		var my_name : String = Steam.getPersonaName()
		if len(my_name) > 17:
			my_name = my_name.substr(0,17) + '...'
		Steam.setLobbyData(lobby_id, "name", (my_name+"'s Lobby"))
		Steam.setLobbyJoinable(lobby_id, true)
		multiplayer_peer = SteamMultiplayerPeer.new()
		print("multiplayer_peer: ", multiplayer_peer)
		var error = multiplayer_peer.create_host(8004)
		print("Host creation result: ", error)
		if error != OK:
			print("Error code: ", error)
			multiplayer_peer.close()
			Steam.leaveLobby(lobby_id)
			SignalBus.display_error.emit("ERROR CREATING HOST CLIENT\nCODE: " + str(error))
			return
		multiplayer.set_multiplayer_peer(multiplayer_peer)
		players[1] = {"name": my_name, "id": Steam.getSteamID()}
		Steam.allowP2PPacketRelay(true)
		_transition_to_lobby()
	else:
		SignalBus.display_error.emit('ERROR CREATING STEAM LOBBY\nCODE: '+str(conn))

logs:
Initializing Steam...
Steam init result: { "status": 0, "verbal": "" }
Steam init result: true
Steam API initialized successfully
Lobby creation attempt. Result: 1
Lobby ID:<PHONE_NUMBER>20987967
Creating host...
multiplayer_peer: [Wrapped:0]
Host creation result: 2
Error code: 2

yeah I had the same issue. Even fixing the file path, the library still fails on create_host call for me with error code 20

same problem here, godot 4.3 on macos, fixed the paths but got error on create_host with code 2 windows is working
func _on_lobby_created(conn, id) -> void:
	print("Lobby creation attempt. Result: ", conn)
	if conn == 1:
		lobby_id = id
		print("Lobby ID: ", lobby_id)
		print("Creating host...")
		var my_name : String = Steam.getPersonaName()
		if len(my_name) > 17:
			my_name = my_name.substr(0,17) + '...'
		Steam.setLobbyData(lobby_id, "name", (my_name+"'s Lobby"))
		Steam.setLobbyJoinable(lobby_id, true)
		multiplayer_peer = SteamMultiplayerPeer.new()
		print("multiplayer_peer: ", multiplayer_peer)
		var error = multiplayer_peer.create_host(8004)
		print("Host creation result: ", error)
		if error != OK:
			print("Error code: ", error)
			multiplayer_peer.close()
			Steam.leaveLobby(lobby_id)
			SignalBus.display_error.emit("ERROR CREATING HOST CLIENT\nCODE: " + str(error))
			return
		multiplayer.set_multiplayer_peer(multiplayer_peer)
		players[1] = {"name": my_name, "id": Steam.getSteamID()}
		Steam.allowP2PPacketRelay(true)
		_transition_to_lobby()
	else:
		SignalBus.display_error.emit('ERROR CREATING STEAM LOBBY\nCODE: '+str(conn))

logs:
Initializing Steam...
Steam init result: { "status": 0, "verbal": "" }
Steam init result: true
Steam API initialized successfully
Lobby creation attempt. Result: 1
Lobby ID:<PHONE_NUMBER>20987967
Creating host...
multiplayer_peer: [Wrapped:0]
Host creation result: 2
Error code: 2

Same for me, I am having the issue right now. Any solutions found or will this be fixed anytime soon/

Just adding one to this - same problem

same problem

same here too

I no longer use the multiplayer peer project and don’t have an example project to test. Therefore, I won’t verify this directly. However, for a similar issue in another project, someone suggested that the problem might rise from the App Sandbox in macos. After fixing the paths, instead of running the game in the editor, try building, exporting, and running the game as a standalone.
Secondly, you could try using a custom entitlement file to disable the App Sandbox. However, be aware that creating custom entitlements will override all other entitlements (possibly default values for Network Server etc.), as mentioned in the docs.
https://docs.godotengine.org/en/stable/tutorials/export/exporting_for_macos.html#app-sandbox-entitlement

This is bug close because problema is simple folder organization, but problem stay with bug issue https://github.com/expressobits/steam-multiplayer-peer/issues/9


Better detect a invalid/expired Vault token

If the EnvelopeEncryption configuration passes an invalid or expired token to Vault when trying to perform an encryption operation, the filter will get a 403 response and the filter will retry the operation.  It won't necessarily be clear to the operator that the token is expired/invalid. This might make root cause problem determination longer.
One idea that occured to me, could the Vault KMS make judicious use of lookup-self endpoint to give a clearer error.

My embryonic idea:
if the Vault KMS encounters a 403 from a normal API call, it should probe the token using lookup-self.  If the token is invalid, the error should be treated as fatal (i.e. don't go into a retry loop) and close the client's connection.  The log should give a clear error message "Token does not exist or has expired".
The VaultKMS implementation could also probe the token on start-up.

Do we want a separate KmsAuthenticationException (subclass of KmsException) to cover this? That would allow the caller to distinguish this case from other KMS exceptions where retrying is a suitable response?
FWIW Apache Kafka has a separate RetriableException classto encode retriability into the type hierarchy. I'm reluctant to follow the same pattern here (at least right now) because it's a kind of layering violation: the KMS implementation ends up needing to know something about how it's being used.

Do we want a separate KmsAuthenticationException (subclass of KmsException) to cover this?

I wonder whether KmsAuthenticationException is quite the right abstraction.  If you were authenticating using a TLS certificate, distinguishing authentication exception from other cases might be tricky.
Maybe something more general - KmsFatalException would be better?  One of my motivations for #1076 is to help inform the KMS API evolution.  Having another data point will help us see more clearly.


Support for changing email address and sending password reset emails

added update_user_email_address()
added send_password_reset()
updated README and pypi version

Looks like the pipeline scan isn't running due to a credentials issue (exit code 255)


HBASE-25032 Wait for region server to become online before adding it to online servers in Master

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

_ Prechecks _

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

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

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

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
4m 14s
branch-2 passed

+1 :green_heart:
checkstyle
1m 16s
branch-2 passed

+1 :green_heart:
spotbugs
2m 15s
branch-2 passed

_ Patch Compile Tests _

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

-0 :warning:
checkstyle
1m 16s
hbase-server: The patch generated 3 new + 59 unchanged - 0 fixed = 62 total (was 59)

+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:
spotbugs
2m 14s
the patch passed

_ Other Tests _

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

39m 13s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2771/1/artifact/yetus-general-check/output/Dockerfile

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

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle

uname
Linux 053893c6854c 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
branch-2 / 9c2f1f7a2b

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

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

modules
C: hbase-server U: hbase-server

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

versions
git=2.17.1 maven=3.6.3 spotbugs=3.1.12

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

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

_ Prechecks _

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
4m 48s
branch-2 passed

+1 :green_heart:
compile
1m 11s
branch-2 passed

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

+1 :green_heart:
javadoc
0m 43s
branch-2 passed

_ Patch Compile Tests _

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

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

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

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

+1 :green_heart:
javadoc
0m 41s
the patch passed

_ Other Tests _

-1 :x:
unit
11m 46s
hbase-server in the patch failed.

42m 29s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2771/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 83bf0e7e2d74 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
branch-2 / 9c2f1f7a2b

Default Java
AdoptOpenJDK-11.0.6+10

unit
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2771/1/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-2771/1/testReport/

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

modules
C: hbase-server U: hbase-server

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

versions
git=2.17.1 maven=3.6.3

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

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

_ Prechecks _

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
5m 31s
branch-2 passed

+1 :green_heart:
compile
1m 15s
branch-2 passed

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

+1 :green_heart:
javadoc
0m 39s
branch-2 passed

_ Patch Compile Tests _

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

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

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

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

+1 :green_heart:
javadoc
0m 36s
the patch passed

_ Other Tests _

-1 :x:
unit
11m 49s
hbase-server in the patch failed.

44m  4s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2771/1/artifact/yetus-jdk8-hadoop2-check/output/Dockerfile

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux a0a75fc0bc1b 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
branch-2 / 9c2f1f7a2b

Default Java
AdoptOpenJDK-1.8.0_232-b09

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

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

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

modules
C: hbase-server U: hbase-server

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

versions
git=2.17.1 maven=3.6.3

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

_ Prechecks _

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

+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.

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
3m 43s
branch-2 passed

+1 :green_heart:
checkstyle
1m 15s
branch-2 passed

+1 :green_heart:
spotbugs
2m 19s
branch-2 passed

_ Patch Compile Tests _

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

-0 :warning:
checkstyle
1m 16s
hbase-server: The patch generated 3 new + 59 unchanged - 0 fixed = 62 total (was 59)

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

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

+1 :green_heart:
spotbugs
2m 37s
the patch passed

_ Other Tests _

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

39m 37s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2771/2/artifact/yetus-general-check/output/Dockerfile

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

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle

uname
Linux 1f486fc89f3b 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
branch-2 / 9c2f1f7a2b

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

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

modules
C: hbase-server U: hbase-server

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

versions
git=2.17.1 maven=3.6.3 spotbugs=3.1.12

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

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

_ Prechecks _

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
6m  9s
branch-2 passed

+1 :green_heart:
compile
1m 32s
branch-2 passed

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

+1 :green_heart:
javadoc
0m 49s
branch-2 passed

_ Patch Compile Tests _

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

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

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

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

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

_ Other Tests _

-1 :x:
unit
206m 13s
hbase-server in the patch failed.

244m 36s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2771/2/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux c6c398b2306a 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
branch-2 / 9c2f1f7a2b

Default Java
AdoptOpenJDK-11.0.6+10

unit
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2771/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-2771/2/testReport/

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

modules
C: hbase-server U: hbase-server

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

versions
git=2.17.1 maven=3.6.3

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

_ Prechecks _

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

+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.

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
4m 26s
branch-2 passed

+1 :green_heart:
compile
3m 36s
branch-2 passed

+1 :green_heart:
checkstyle
1m 16s
branch-2 passed

+1 :green_heart:
spotbugs
2m 16s
branch-2 passed

_ Patch Compile Tests _

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

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

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

-0 :warning:
checkstyle
1m 17s
hbase-server: The patch generated 1 new + 139 unchanged - 0 fixed = 140 total (was 139)

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

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

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

_ Other Tests _

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

49m 24s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2771/3/artifact/yetus-general-check/output/Dockerfile

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

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux 6652c8e1cd50 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
branch-2 / 80529af963

Default Java
AdoptOpenJDK-1.8.0_282-b08

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

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

modules
C: hbase-server U: hbase-server

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

versions
git=2.17.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

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

_ Prechecks _

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
4m  2s
branch-2 passed

+1 :green_heart:
compile
1m  0s
branch-2 passed

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

+1 :green_heart:
javadoc
0m 37s
branch-2 passed

_ Patch Compile Tests _

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

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

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

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

+1 :green_heart:
javadoc
0m 36s
the patch passed

_ Other Tests _

-1 :x:
unit
214m  5s
hbase-server in the patch failed.

241m 24s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2771/3/artifact/yetus-jdk8-hadoop2-check/output/Dockerfile

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 8f2879a2887b 4.15.0-136-generic #140-Ubuntu SMP Thu Jan 28 05:20:47 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / c8c043a413

Default Java
AdoptOpenJDK-1.8.0_282-b08

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

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

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

modules
C: hbase-server U: hbase-server

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

versions
git=2.17.1 maven=3.6.3

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

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

_ Prechecks _

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
5m 22s
branch-2 passed

+1 :green_heart:
compile
1m 21s
branch-2 passed

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

+1 :green_heart:
javadoc
0m 47s
branch-2 passed

_ Patch Compile Tests _

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

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

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

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

+1 :green_heart:
javadoc
0m 44s
the patch passed

_ Other Tests _

-1 :x:
unit
222m  2s
hbase-server in the patch failed.

256m  4s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2771/3/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 6c9fc5a00c90 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
branch-2 / 80529af963

Default Java
AdoptOpenJDK-11.0.10+9

unit
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2771/3/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-2771/3/testReport/

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

modules
C: hbase-server U: hbase-server

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

versions
git=2.17.1 maven=3.6.3

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

_ Prechecks _

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

+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.

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
4m 47s
branch-2 passed

+1 :green_heart:
compile
3m 48s
branch-2 passed

+1 :green_heart:
checkstyle
1m 27s
branch-2 passed

+1 :green_heart:
spotbugs
2m 45s
branch-2 passed

_ Patch Compile Tests _

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

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

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

-0 :warning:
checkstyle
1m 26s
hbase-server: The patch generated 1 new + 100 unchanged - 0 fixed = 101 total (was 100)

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

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

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

_ Other Tests _

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

53m 17s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2771/4/artifact/yetus-general-check/output/Dockerfile

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

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux 5908f90abea5 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
branch-2 / 80529af963

Default Java
AdoptOpenJDK-1.8.0_282-b08

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

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

modules
C: hbase-server U: hbase-server

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

versions
git=2.17.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

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

_ Prechecks _

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
5m 11s
branch-2 passed

+1 :green_heart:
compile
1m 19s
branch-2 passed

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

+1 :green_heart:
javadoc
0m 46s
branch-2 passed

_ Patch Compile Tests _

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

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

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

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

+1 :green_heart:
javadoc
0m 51s
the patch passed

_ Other Tests _

-1 :x:
unit
227m 20s
hbase-server in the patch failed.

261m 44s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2771/4/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 3aee97a4ddc5 4.15.0-136-generic #140-Ubuntu SMP Thu Jan 28 05:20:47 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / 80529af963

Default Java
AdoptOpenJDK-11.0.10+9

unit
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2771/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-2771/4/testReport/

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

modules
C: hbase-server U: hbase-server

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

versions
git=2.17.1 maven=3.6.3

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

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

_ Prechecks _

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
4m 23s
branch-2 passed

+1 :green_heart:
compile
1m  2s
branch-2 passed

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

+1 :green_heart:
javadoc
0m 39s
branch-2 passed

_ Patch Compile Tests _

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

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

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

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

+1 :green_heart:
javadoc
0m 37s
the patch passed

_ Other Tests _

-1 :x:
unit
242m 55s
hbase-server in the patch failed.

272m 25s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2771/4/artifact/yetus-jdk8-hadoop2-check/output/Dockerfile

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux b95676db00a3 4.15.0-136-generic #140-Ubuntu SMP Thu Jan 28 05:20:47 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / 80529af963

Default Java
AdoptOpenJDK-1.8.0_282-b08

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

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

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

modules
C: hbase-server U: hbase-server

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

versions
git=2.17.1 maven=3.6.3

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

_ Prechecks _

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

+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.

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
4m 24s
branch-2 passed

+1 :green_heart:
compile
3m 34s
branch-2 passed

+1 :green_heart:
checkstyle
1m 23s
branch-2 passed

+1 :green_heart:
spotbugs
2m 13s
branch-2 passed

_ Patch Compile Tests _

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

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

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

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

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

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

+1 :green_heart:
spotbugs
3m  2s
the patch passed

_ Other Tests _

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

49m 33s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2771/5/artifact/yetus-general-check/output/Dockerfile

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

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux 20973b14be92 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
branch-2 / 124ea5eee3

Default Java
AdoptOpenJDK-1.8.0_282-b08

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

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

modules
C: hbase-server U: hbase-server

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

versions
git=2.17.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

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

_ Prechecks _

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
5m 17s
branch-2 passed

+1 :green_heart:
compile
1m 19s
branch-2 passed

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

+1 :green_heart:
javadoc
0m 49s
branch-2 passed

_ Patch Compile Tests _

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

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

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

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

+1 :green_heart:
javadoc
0m 45s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
210m 45s
hbase-server in the patch passed.

244m 52s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2771/5/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux e92417d93f64 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
branch-2 / 124ea5eee3

Default Java
AdoptOpenJDK-11.0.10+9

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

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

modules
C: hbase-server U: hbase-server

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

versions
git=2.17.1 maven=3.6.3

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

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

_ Prechecks _

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
3m 48s
branch-2 passed

+1 :green_heart:
compile
0m 59s
branch-2 passed

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

+1 :green_heart:
javadoc
0m 37s
branch-2 passed

_ Patch Compile Tests _

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

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

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

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

+1 :green_heart:
javadoc
0m 36s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
221m 43s
hbase-server in the patch passed.

248m 51s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2771/5/artifact/yetus-jdk8-hadoop2-check/output/Dockerfile

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 2795a97de3be 4.15.0-136-generic #140-Ubuntu SMP Thu Jan 28 05:20:47 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / 124ea5eee3

Default Java
AdoptOpenJDK-1.8.0_282-b08

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

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

modules
C: hbase-server U: hbase-server

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

versions
git=2.17.1 maven=3.6.3

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

This message was automatically generated.

@bharathv @saintstack can we merge this one too?


Client cannot work for polymorphic model when sever side is upgraded

Problem statement
I can see the generated code for polymorphic model in client. And the unmarshal func will validate the discriminator. For example
return nil, errors.New(422, "invalid name value: %q", getType.Name)

My question is what if the server side add new sub-models? what if the user doesn't upgrade the client SDK?
Looks the their old SDK will get panic.
I didn't find a solution, so create this request. Could you give me a solution? Thanks.
Swagger specification
Swagger 2.0
Steps to reproduce
Environment
swagger version: 0.15.0
go version: 1.10.3
OS: Mac OS

it would fail yes, but since the spec is upgraded you're effectively working with a new version of the server api, in that case the client does need to regenerate.  But at least you have defined behavior instead of undefined behavior.

@casualjim  But users/customer may not be want to upgrade their SDK, If we force they do this, they may not be happy. And also, since we have lots of polymorphic APIs, some of them are upgraded very frequently, If they get failed frequently, I don't think they are happy. Actually, I prefer to ignore the new added sub-models.

One solution can also be to implement a default implementation of the polymorphic base type and return an instance of that. At least you'd get basic functionality.
the files to change are these:
https://github.com/go-swagger/go-swagger/blob/master/generator/templates/schema.gotmpl
https://github.com/go-swagger/go-swagger/blob/master/generator/templates/schemabody.gotmpl

Thanks, I will try it.

When I tried to update the schema template, I got below error message. Looks I cannot override the templates except I update the code of go-swagger. If there any ways to let it effect?
Could not complete template processing in directory "../go-swagger-local/templates": Could not add template: Cannot overwrite protected template schema

generate, modify then reuse model with x-go-type

I think the solution cannot get the purpose. And we're gonna to force our customers to upgrade their SDK version if there are new sub-models.


Clarify the difference between kinds and resources in the API

As we prepare to expose additional endpoints for pod status, cloning,
binding, and templating, we should clarify the terminology and
distinctions. Use pod status as an example of an alternative "resource"
that shares the same "kind" (schema) as pods.
@bgrant0607

I'm done making comments for now. Thanks for updating this doc.

Updated with comments, and one clarification about naming "spec".  Let me know your feedback on that (last paragraph of "Spec and Status").  I think forcing every possible resource to have a spec may be abusive - i think we discussed this but I don't remember whether we had already said there are cases where spec could be absent or renamed for objects that aren't in the "desired / current" category.  For instance, we store users - I could see them having status, but "spec" doesn't feel right for describing a user object.

Looks pretty good.
I agree regarding requiring Spec -- Endpoints is a topical example.
I asked for one more thing to be added, but I'm fine with doing that in a PR myself, if I can dig out of my review backlog.
Feel free to self merge.


🚀 Feature: Decouple share name from URL token

🔖 Feature description
Right now, the generated token in the link is considered the name of the share. I think it would be better if those were decoupled and it will autogenerate a hard-to-guess URL token, that can be edited too if desired.
Additionally, isn't the currently generated token/name too short security-wise?
🎤 Pitch
If I share a photo album to my friends, I can't just name the link "Lisas Birthday" because it would be an easy-to-guess URL. Otherwise, if I take the generated token (or a longer one), the preview in Whatsapp for example will show "Share Y252aXsta...", so it doesn't look appealing for others 😅

Yes, both issues have the same goal :)

Okay, I'll close this issue then as the other issue is older.

So it's not planned?

Oh, sorry, I forgot that I had closed the other issue. This feature is definitely a good suggestion.

Thank you very much!

I've just implemented this feature. It will be released in the next release :)


Agenda child items disappear if manager sort items

It a manager sorts agenda items (move some items as child) then some items (only the childs?) disappear after autoupdate in agenda list view for normal users.
Maybe a permission and/or tree problem?

Works for me on current master. If you can reproduce it on the master, then please tell me how. If not, then close this issue

I can't reproduce it any more. So closed.


New report: Loading metrics

Metrics:
First Meaningful Paint, Time-to-first-Interactive, Time-to-consistently-interactive
Source: WebPageTest Lighthouse reports
Visualization: time-series charts similar to http://beta.httparchive.org/reports/js
URL: http://beta.httparchive.org/reports/loading
From @igrigorik

We'd also want a companion "deep-dive" report for each individual run, with full histograms for each metric, etc.

Example query to get desired metrics:
SELECT
  JSON_EXTRACT(report, "$.audits.consistently-interactive.rawValue") AS ttci,
  JSON_EXTRACT(report, "$.audits.first-interactive.rawValue") AS ttfi,
  JSON_EXTRACT(report, "$.audits.first-meaningful-paint.rawValue") AS fmp
FROM
  [httparchive:har.latest_lighthouse_mobile]

Progress on this:
http://beta.httparchive.org/reports/loading?start=latest

http://beta.httparchive.org/reports/loading

Implementation notes...
I really wanted to write the histogram queries to use a table wildcard, eg har.*, but it just wouldn't work because of how heterogeneous the har dataset is. See https://github.com/HTTPArchive/httparchive/issues/112 for prior discussion on this issue. As a workaround, I created a new lighthouse dataset that duplicates all of the LH tables that are in har. The dataflow pipeline isn't updated to write to both places, this was more of a proof of concept. I'm in favor of more homogeneous datasets like this to make querying easier, so I think it would be a good change to redirect the LH output solely to the lighthouse dataset.


Add Woopra analytics

We need to create a new woopra instance for subsite. We then need to enable and update tracking code on the pacific hub

https://github.com/WikiNewZealand/pacific/commit/5230791f714fabe0c8182f304a45ca76ecf70e44 Committed woopra code, waiting to see if it works

Checked and live


fix(tsconfig): omitting declaration in custom config does not fail tsconfig validation

jsii will fail if no declarations are emitted.
This setting was not previously enforced, because tsc defaults to emitting declarations in some situations. However since its not the default for all allowed configurations, we should enforce it.
Also adds emitDeclarationOnly: true to the list of incompatible settings. Without compiled js files, jsii programs don't work either.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

💚 All backports created successfully

Status
Branch
Result

✅
maintenance/v5.3

Questions ?
Please refer to the Backport tool documentation and see the Github Action logs for details


On clicking the link received by second participant, they will be directed to a landing page where they see three options (register, login, join as guest) to join the debate room.

d77dae2a8f03b2b2888e7de0f18a9d3f5591eca6


Add Slant Axis

Fonts to be onboarded that have this axis:

https://github.com/google/fonts/issues/4286
https://github.com/google/fonts/issues/4059
https://github.com/google/fonts/issues/3789

@RosaWagner, at https://github.com/google/fonts/issues/4286#issuecomment-1041332542 you said that the Nunito Sans update needs registration of a slant axis (and also an xheight one). But we do have a 'slnt' axis!
https://github.com/googlefonts/axisregistry/blob/main/Lib/axisregistry/data/slant.textproto

The slant axis has empty fallback values, therefore italic styles can’t be generated by the API. It would therefore create regression if we onboard an upgrade with a slant axis instead of 2 VF Roman/Italic

But we can do as Nunito and onboard it as 2 VF but since it requires another axis and (I think) change of politic around the mvar table, we may as well wait.

This can be closed, can it not?

Slant Axis discussion is open in #295

Thanks for the cross-referencing, @vv-monsalve

This can be closed, can it not?

This issue can only be closed once the axis is properly added, or if we formaly reject the proposal.
In the case of rejections, I think it would be useful to keep a log file at this repo describing the formal reasoning for each rejection.

Other discussion open there: https://github.com/google/fonts/issues/2606


[13pt] NWM lake polygon masking for upstream branch catchments

Current GMS solution allows for some upstream branch catchments to inundate some NWM lake areas using flowline from downstream of the water body. Need to identify solution to prevent unwanted inundation within the NWM lake polygons.
Example of a NWM waterbody showing inundation (FIM <IP_ADDRESS>) in huc 11140305 -->

HUC 12030109 (NWM lake id: 1445978) is inundated due to branch 02. The headwater catchment for the branch (hydroid 24450001) begins with a NWM streamline (order=3) at the lake outlet. There is a NWM streamline (order=3) upstream of this one inside the lake polygon (red flowline in image below). It is currently filtered when generating the nwm_subset_streams_levelPaths_dissolved.gpkg file (removes lakeid flowlines).

This issue is an extension of #663


perf(semantic): avoid counting nodes

Instead of visiting AST to count AST nodes in SemanticBuilder, just make high estimates of counts for nodes, scopes, symbols and references, based on source text length. These estimates are the maximum number of items theoretically possible for a given source text length. Almost always they'll be vast over-estimates, but should never be an under-estimate.
This ensures AstNodes, ScopeTree and SymbolTable's allocations will not grow during their construction, which is a major performance hit, but avoids the complete AST traversal we were using previously to get accurate counts.
This "estimate high" approach is a viable strategy on 64-bit systems with virtual memory, where:

The memory space is so large that it's almost impossible to exhaust.
Allocating memory only consumes virtual memory, not physical memory.

So use this faster "estimate high" method as standard, and the slower visitor-based counter on 32-bit systems and WASM.
Note: I tried using shrink_to_fit on the Vecs once semantic run is complete, to free up the excess memory. But this caused the Vecs to all reallocate, which negated the performance gains. It was an artefact of the custom global allocator we use in our benchmarking setup. Shrinking allocations does not cause reallocation.

#5703  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @overlookmotel and the rest of your teammates on  Graphite

TODO: Allow passing existing node counts into SemanticBuilder instead of basing counts on source text length.
This is necessary when re-running semantic on an AST which has been transformed/minified. Nodes / scopes / symbols / references counts may have increased in transformation, but the source text has not changed, so estimating based on source text length will be inaccurate. Additionally, the actual counts will be accurate, unlike estimating from source text length.
At present all test pass but this is an accident because the over-estimates are so large that they obscure this problem. It would be possible to produce panics with the right input.

As an experiment, I hard-coded the exact counts into SemanticBuilder for our benchmark fixtures, so it doesn't over-allocate.
This has little effect on most of semantic benchmarks, but it does noticeably speed things up for semantic[RadixUIAdoptionSection.jsx] (+4%).
So, while over-allocating is not too bad, it's not as good as accurate counts for small files.
The over-allocating version is massively over-allocating. For RadixUIAdoptionSection.jsx:

Actual
Estimated

nodes
392
5041

scopes
2
1261

symbols
11
1259

references
28
1261

So likely the reason for the slowdown of over-allocating is that the much larger estimated counts push the allocations up a size class in the system allocator. I believe system allocator serves small allocations from a thread-local pool, rather than taking from the main cross-thread pool. The former is faster as it doesn't involve any synchronisation.
I feel that small files are the most representative of the code Oxc will be processing in the "real world", so the RadixUIAdoptionSection.jsx benchmark is probably the most important one.
Conclusion: Getting accurate counts in the parser will be a better solution if it doesn't cost much in the parser. According to @DavidHancu on Discord cost of compiling counts in parser is about -0.3%. That's pretty cheap.

Close as stale.

Archived on overlookmotel/semantic-avoid-counting-nodes branch.


Git plugin blocks Windows export from Linux (due to the editor attempting to export a GDNative plugin for a platform it's not compiled for)

Godot version:

3.2.3, 3.2.3 mono
OS/device including version:

Ubuntu 20.04
Issue description:

Attempts to export to Windows result in "export template appears to be missing" error. Exports to Linux/X11, HTML5 and Max OSX all succeed. Problem only happens when the Git plugin has been added to the project.
Steps to reproduce:
In a project with the git plugin installed and "Windows Desktop" configured in export_presets.cfg:
godot --export "Windows Desktop" demo.exe
ERROR: copy: Failed to open res://bin/win64/release/libgitapi.dll
   At: core/os/dir_access.cpp:298.
ERROR: _fs_changed: Project export failed for preset 'Windows Desktop', the export template appears to be missing.
   At: editor/editor_node.cpp:753.

Minimal reproduction project:

Unable to: git plugin causes project to exceed 10MB limit.
Also reported against godot-git-plugin as https://github.com/godotengine/godot-git-plugin/issues/51

For a workaround, You can disable git-plugin in GDNative tab from project settings before exporting for Windows. Although I recommend to do it before any export or the plugin will be shipped into the exported project increasing its size for no use.

Since you are on Ubuntu, it is most likely that you do not have the res://bin/win64/release/libgitapi.dll file. Could you confirm that? If yes then you get that file from the Windows release here. Maybe then you may be able to export the game.
Or simply just disable the plugin.
But still the above are workarounds. The plugin shouldn't really be exported in the first place. It should behave like an editor-only tool, because it registers itself as a tool class.

Since you are on Ubuntu, it is most likely that you do not have the res://bin/win64/release/libgitapi.dll file. Could you confirm that? If yes then you get that file from the Windows release here. Maybe then you may be able to export the game.

This might be a certain case and can happen on windows too. We should release the plugin with both binaries. Although not sure how.

But still the above are workarounds. The plugin shouldn't really be exported in the first place. It should behave like an editor-only tool, because it registers itself as a tool class.

AFAIK registering it as a tool only allows the plugin to run inside the editor, same as tool keyword.

@Janglee123 Earlier we used to distribute both Windows and Linux the binaries with pre-release versions and IIRC till v1.1 of the plugin as well. I guess we had this coming with having separate release artefacts. Indeed, we should either distribute all of them or add some sort of warnings/head-up on the release descriptions for the OS-specific releases or do both.

same as tool keyword

Yes, that is how it should work based on our discussions earlier on #godotengine-gdnative with karroffel

Since you are on Ubuntu, it is most likely that you do not have the res://bin/win64/release/libgitapi.dll file. Could you confirm that? If yes then you get that file from the Windows release here. Maybe then you may be able to export the game.

Confirmed: there is no res://bin/win64/anything.

Or simply just disable the plugin.

Yeah, that works for getting an export done, but not great for ongoing development :)

Additional point: the export works in 32 bits but not 64 bits.

I encountered the same thing. Exporting from Ubuntu to Windows. When I launch the build I see this error:

I tried excluding "bin/, git_api." but that had no affect on the export. I'll be just doing git from the command line for now, but I did want the git plugin to work as that would save me time. Thanks.

I think it's important to have working version control built into the editor. However, having to enable it every time you open a project (and setup on every new project) is a bit of a hassle. I wasn't sure if that was a bug or something with my system. And the functionality is pretty basic, you cannot even push (meaning you need to go to the command line anyhow, why not just do it all from there). Maybe not all the advanced features like branches and stuff are needed, but you should be able to push. Hopefully it can be improved.

For a workaround, You can disable git-plugin in GDNative tab from project settings before exporting for Windows. Although I recommend to do it before any export or the plugin will be shipped into the exported project increasing its size for no use.

i tried to disable it in project settings but to no avail
Disabled GDNative Singleton
 core/os/dir_access.cpp:297 - Failed to open res://bin/win64/release/libgitapi.dll
 editor/project_export.cpp:872 - Failed to export the project for platform 'Windows Desktop'.


Autofocus Trix Editor

Is there any option to focus on the editor ?

Hi @dennyjohnk , did you work this out? I need to try and focus the editor using Javascript.


Full-width row

I suggest adding a full-width row, so we'll be able to align text e.g. to the left edge of the viewport. Usage example - responsive e-mail signature

Hi @selrond You can use full-width on mj-section

Yeah I see, but I need the text to be aligned to the left of the viewport, now it is still centered.  Basically - I need to be able to align the columns (or the the centered container that contains them) to the left

@selrond sorry for the slow answer here. If I understand well, you don't want the main container to be centered, is that right? If yes, I'm afraid it's not possible at the moment with our current HTML layout.
What are you trying to achieve here?
Thanks for the feedback

To use it for email signature for instance - where you need to have everything left-aligned maybe in some full-width container

@selrond did you manage to solve this?
I'm in the same exact situation right now and it's driving me mad

@mattpirelli I kinda did — I hand–coded it 😛
I used this https://html-online.com/editor/ + stackexchange

@selrond same here.
Thinking about it, it's understandable that this is not a "feature", since ours is a bit of a fringe case.
I may or may not end up coding a custom component for that.

I believe you'll need to write your own custom component for that, I think this is out of the spec from what MJML try to achieve.
Here's how to start : https://mjml.io/documentation/#create-a-component Feel free to share it with us, we may add it to the main README !

@mattpirelli Oh and I forgot one great tool: Premailer: http://premailer.dialect.ca/ which is a great tool! Definitely check that out


[next-css] cssLoaderOptions.module.auto = true

cssLoaderOptions.modules.auto = true not applied in nextjs

Hi, thanks for creating an issue. We currently recommend using nextjs.org/docs/basic-features/built-in-css-support as the plugins have been deprecated in favor of the built-in support.


🤓 Fix typo in README

Fixing a typo in the README.

Ha thanks Nick! If you feel up to more Macmoji could definitely use some love receiving the more recent emoji additions! :)


Transparent PNG image not being transparent

When I use hyprlock to draw a transparent png using the image module, it does not draw it transparent and it draws it with a white background.
What I want to achieve in the end is having a blurred screenshot of my desktop in the background. Then have a transparent png in the middle of it over the background.
It is interesting that the background module supports rendering the transparent png properly but I cannot use that because it is not possible to change the size of it. Size is only supported in the image module.
Hyprland version: v0.41.2
Hyprlock version: 0.4.0-1
OS: Arch Linux x86_64 - Linux 6.6.40-1-lts
This is my hyprlock config:
# background image will be a blurred screenshot
background {
    monitor =
    path = screenshot
    color = rgba(25, 20, 20, 1.0)
    blur_passes = 1
    blur_size = 3
    noise = 0.2
    contrast = 0.8916
    brightness = 0.8172
    vibrancy = 0.5
    vibrancy_darkness = 0.5
}
# The transparent png (not working)
image {
    monitor =
    path = ~/transparent-pic.png
    size = 200
    rounding = 0
    border_size = 1
    border_color = rgb(221, 221, 221)
    rotate = 0
    reload_time = -1
    position = 0, 200
    halign = center
    valign = center
}

That is because currently when border_size is used, the image draws a solid rectangle in border_color below it.
if you set border_size = 0 it should be transparent.

It worked with the border_size = 0 option. Thanks!


NFTX cryptopunks floor data at 1 min interval

Hey @mikeyrf
Made a simple script in case we want to try out other NFT projects in the future.
It can be used like this:
python scripts/nftx_data.py --source nftx_floor_punks.csv --periodicity 1min
The data that we require as input to the market impact script is this: nftx_floor_punks_1min.csv
Lemme know if it works! :)

Looks good! Renamed to clean_data.py and specified path as csv/ so we dont have a bunch of super large csvs in the repo (.gitignore).


Compbiomed devel

Reknit vignette with .png images to make vignette smaller size + speed up knitting

Pull Request Test Coverage Report for Build 601

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 95.571%

Totals

Change from base Build 597:
0.0%

Covered Lines:
2503

Relevant Lines:
2619

💛  - Coveralls


call of environment:: in fewer places

Signed-off-by: Axel Nennker<EMAIL_ADDRESS>New utility method to create pool test_pool_create_poolfile simplifies tests code

It seems adding a command that deletes this directory before the Windows tests run will help
C:\\Users\\jenkins\\AppData\\Local\\Temp\\indy_client
That is probably %TEMP%\indy_client


Add ", line 6

Actually, I think some of the other companies aren't formatted according to "NAME", either. Is this intentional?

@ArnavSood Thanks, good catch.
I think I'll leave it as is --- good training for dealing with messed up data files (the most common variety).

No problem. Sounds good, and about right.


selectable default "show # entries" in File Manager

I have just requested a feature enhancement to Webmin to allow any theme the ability to set this default: https://github.com/webmin/webmin/issues/857
Given that changing this default is already available for "old" themes, perhaps there is a limitation which now forces such a decision on themes themselves.
If so, I hope that Authentic Theme (itself) could be enhanced to allow setting a default "show # entries" in File Manager

If this request "has" to be done in Authentic Theme (and not in Webmin itself for some reason),
perhaps you could add a file manager configuration section at "/webmin/edit_themes.cgi" -- the section could be descriptively named "File Manager" and other default configuration options could be added there.
Some other useful features to eventually add could be selecting which default columns are to be displayed, the default sort column, the default sort order.
Continued thanks for this awesome Webmin theme!

I'll check a little bit later today.

Done.

Works great in Authentic Theme 19.10-beta2
Thank you so much!