Enforce Gitea environment for pushes

Numerous bug reports and problems in the end come down to the user pushing over ssh using a key that is not managed by Gitea, using a plain simple username/password over ssh or even just pushing locally.
Prior to this PR, if you were to push like this - the pre-receive and post-receive hooks will simply not run and branch protection, webhooks, notifications, setting repository as non-empty etc. will all not occur - leading to heisenbugs and unreproducible bug reports.
There simply is no good reason why a user should want to push like this without hooks running. Hooks should therefore cause the push to fail and explain why.
If a user does not or cannot go through Gitea serv they should the set variables themselves - which I have listed on specific-variables.en-us.md with a warning stating that they should consider themselves acting outside of supported behaviour.

Codecov Report

Merging #8982 into master will decrease coverage by 0.03%.
The diff coverage is 4.54%.

@@            Coverage Diff             @@
##           master    #8982      +/-   ##
==========================================
- Coverage   41.27%   41.23%   -0.04%
==========================================
  Files         546      546
  Lines       71037    71053      +16
==========================================
- Hits        29317    29302      -15
- Misses      38003    38032      +29
- Partials     3717     3719       +2

Impacted Files
Coverage Δ

cmd/hook.go
0% <0%> (ø)
:arrow_up:

modules/setting/setting.go
45.78% <100%> (+0.08%)
:arrow_up:

modules/process/manager.go
74.32% <0%> (-4.06%)
:arrow_down:

models/pull_list.go
57.74% <0%> (-2.12%)
:arrow_down:

models/repo_indexer.go
66.54% <0%> (-1.82%)
:arrow_down:

modules/log/event.go
64.61% <0%> (-1.03%)
:arrow_down:

models/error.go
32.67% <0%> (-0.6%)
:arrow_down:

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 a3e42bf...810cdc1. Read the comment docs.

Since default value of OnlyAllowPushIfGiteaEnvironmentSet is true, this should be a compitable change and we could remove the break label. @zeripath

@lunny ONLY_ALLOW_PUSH_IF_GITEA_ENVIRONMENT_SET = true is the breaking case since it will block some push that were possible before outside gitea previously. It should be minor and only very few people should be impacted but it could break some use case of thoses people that would need to set it to false knowing the underlying impact (interaction not tracked by gitea).


Expand Latin Hypercube sampling beyond uniform distribution

Currently the lhs_prcc function  only supports sampling from the uniform distribution.
In a previous issue @robmoss mentioned his package lhs. This package may provide features for overcoming this issue.

Good point, this isn't something that can be achieved with the current lhs_prcc() function. Hmm. One option would be to allow the parameters_df argument to take one of two forms:

The currently supported option of a data frame that contains 'Lower Bound' and 'Upper Bound' columns, and is indexed by parameter name; or
A dictionary that maps parameter names to ppf() functions that transform the uniform samples into any desired distribution.

Having a quick look through lhs_and_prcc.py, I think this could be achieved with relatively few modifications to the code — I've written a proof-of-concept as a PR if you're interested. Feel free to accept, reject, rewrite :smile:

@robmoss thanks for your contribution. Your pull request has been accepted. As a result your additions I have published v0.2.0 of MetaCaster.


PreValue config - swap dropdown with a "Doc Type Picker"

NOTE: Logging here, so I don't forget about this in future.
This is not yet an actionable task.

Rather than using a dropdown, we could do similar to how the DocType "Allow children" permission UI works. Use the overlay directive to display a doctype picker.
https://github.com/umco/umbraco-inner-content/blob/develop/src/Our.Umbraco.InnerContent/Web/UI/App_Plugins/InnerContent/views/innercontent.doctypepicker.html#L20
This is purely a cosmetic / consistent UI idea.

I'm thinking along the lines of the List View's layout control...

Where the "icon" picker would be a document-type, the "Name" and "Layout path" would be for the Name Template and Tab dropdown respectively.


Update kotlinpoet to 2.0.0

See https://github.com/square/kotlinpoet/releases/tag/2.0.0
It bumps Kotlin to 2.0.10 from 2.0.0 which should be fine and is otherwise backward compatible.

🛠 Docs Preview Building...

Configuration
{
  "repoOverrides": {
    "apollographql/apollo-kotlin@main": {
      "remote": {
        "owner": "apollographql",
        "repo": "apollo-kotlin",
        "branch": "update-kotlinpoet"
      }
    }
  }
}

88992ab155866a5219c665ec9d3a08dba19d7a31


not left side view, only right side view

requiement: just need right side view, no needed for left side view.
is it this method only, https://github.com/John-Lluch/SWRevealViewController/issues/366, not other, can not set the config or property
thanks

solve myself. when init SWRevealViewController, set initWithRearViewController for nil, and the rightViewController，it's ok

closes #389


Add conversion of existing library to GNPS batch library submission

Import library
export batch submission formats: mgf and tsv

TODO

add direct link to validator (https://gnps-quickstart.ucsd.edu/validatebatch)
instruct on submission

revisions done


fix: TC201 should never emit for classes defined in-file

I found another false positive for TC201 when a wrapped annotation is more complex than directly referring to a defined class name.
I changed the condition for class_name to match the one for import_name. This should be more consistent.

There are actually quite a few more false-positives for declarations other than classes, such as TypeVar or TypeAlias, we will probably need to remember those in a list, similar to class_names. Or change it to local_names and put everything in there.
But that can wait for a separate pull request.

I realize now that the only reason this class_names lookup was probably added was to avoid false-positives for classes referring to themselves in their own annotations, but the change still makes sense in that context.

I realize now that the only reason this class_names lookup was probably added was to avoid false-positives for classes referring to themselves in their own annotations, but the change still makes sense in that context.

Yeah you're right, but also agree this seems beneficial :+1: Thanks!


Fixes #768: make filters unique by display name

We've adjusted the form over time so this used to be just "Homemade masks" and then was updated:

So this is the case of handling form values changing over time. We could try and fix a level up and I'm open to that before merging but seemed like we might end up just needing this anyways

K -- I'm fine with it here :+1:


Upgrade go version from 1.22 to 1.23

Fixes https://github.com/mlflow/mlflow-go/issues/65

Upgrade go version from 1.22 to 1.23
Run go mod tidy
Upgrade golangci-lint, mockery and proton-gen-go
regenerate mocks and protos

Please also update golangci-lint: https://github.com/golangci/golangci-lint/releases/tag/v1.61.0
and mockery: https://github.com/vektra/mockery/releases/tag/v2.46.3
Perhaps (https://pkg.go.dev/google.golang.org/protobuf/cmd/protoc-gen-go, do in separate commit, see what CI says, if negative don't go for it)

@fabiovincenzi there were a couple of //nolint:ireturn comments that were removed.
You need to restore these. The clue is that the linter should now not mark these as false positives anymore.


Find optimal image gen model

We should make sure that we find the optimal model in speed and results:

The model should fit on an 8GB VRAM GPU (such as the GTX 1080)
The loading should take max 1 minute
The pipe parameters are optimized for mnemonic (the image does not need to be spectatular, just memorable)
Look into quantized options: https://huggingface.co/aifoundry-org/FLUX.1-schnell-Quantized

To test we should run a prompt on all models and compare the results.
https://huggingface.co/black-forest-labs/FLUX.1-dev
https://huggingface.co/black-forest-labs/FLUX.1-schnell
https://huggingface.co/docs/diffusers/main/en/api/pipelines/flux

Look into this when having issues: https://www.youtube.com/watch?v=mdOLkX7PEHg

Added new model deck, still needs to be tested

See discussions about lower VRAM / performance:

https://huggingface.co/black-forest-labs/FLUX.1-schnell/discussions/5
https://huggingface.co/black-forest-labs/FLUX.1-schnell/discussions/17

https://huggingface.co/rupeshs/FLUX.1-schnell-openvino-int4

https://huggingface.co/Kijai/flux-fp8

https://gist.github.com/AmericanPresidentJimmyCarter/873985638e1f3541ba8b00137e7dacd9

https://huggingface.co/city96/FLUX.1-dev-gguf

Could use https://github.com/william-murray1204/stable-diffusion-cpp-python
In combination with quantized models like: https://huggingface.co/aifoundry-org/FLUX.1-schnell-Quantized

Installation instructions:
Download CUDA 12.6 (or other version) from: https://developer.nvidia.com/cuda-downloads
Make sure everything is set correctly on the system path.
$env:CMAKE_ARGS="-DSD_CUBLAS=ON"
$env:CMAKE_ARGS="-DLLAMA_CUDA=on -DCMAKE_GENERATOR_TOOLSET='cuda=C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.6'"
pip install stable-diffusion-cpp-python --upgrade --force-reinstall --no-cache-dir

In case of CMake error do this: https://stackoverflow.com/questions/56636714/cuda-compile-problems-on-windows-cmake-error-no-cuda-toolset-found

Also try downloading with local_dir instead of cache_dir: https://huggingface.co/docs/huggingface_hub/en/guides/download#download-files-to-a-local-folder

Let's try without the stable-diffusion-cpp as installing it is a hell...
For now stick with pure huggingface packages: https://gist.github.com/AmericanPresidentJimmyCarter/873985638e1f3541ba8b00137e7dacd9

Other option: https://huggingface.co/HighCWu/FLUX.1-dev-4bit

Could save our own 4bit model using: https://gist.github.com/Stella2211/10f5bd870387ec1ddb9932235321068e

or use these 4 bit safetensors: https://huggingface.co/argmaxinc/mlx-FLUX.1-schnell-4bit-quantized/tree/main

Leaderboard text2img: https://artificialanalysis.ai/text-to-image/arena

Medium will be released 29 oct


Added ENV support for aerospike, rethinkdb and mongodb.

Part of #763.

Fixed merge conflict.

Thanks! Great additions 👍


Fix the check for build agent to enable QIR Runtime CI

The QIR Runtime CI hasn't been running because of an incorrect check in set-env.ps1. If they were, they would catch a build break on Linux and find find inconsistencies between tests setup across platforms.
The bootstrap logic is doing more than just preparing for the build. The bootstrap scripts are also inconsistent across platforms. To begin with, I've switched the CI build not to use bootstrap scripts. Those are still useful for setting the repo for local development and I don't understand all requirements here, so keeping them intact.

@anpaz , could you please take a look?

/azp run


Unable to upload file to S3.

Hi,
I am using this package and it gives me S3: AWS Key undefined, S3: AWS Secrete undefined, S3: AWS bucket undefined.
I just print the S3 value there I found these(AWS Key, secrete and bucket) configuration.
I am not able to upload file to S3, Its also giving me an error.
Log Attachment :
https://cloud.githubusercontent.com/assets/20944242/20460896/b8e43a6a-af17-11e6-8257-1b655e6ec0fc.png
Meteor version: <IP_ADDRESS>
Lepozepo version: latest one.

Hey! The package is still scoped globally, are you importing it anywhere?


server.invalid_dependencies

fixed this god damn error

This creates other issues like listing the dependencies the number of times they exist in the database


conform.nvim checkhealth error

When I used neovim's checkhealth to check the conform.nvim plugin, this error occurred:

Here is my conform.nvim plugin configuration:

How to solve this problem?

You need to move the format_on_save block outside of formatters_by_ft


'ui' package is deprecated

Since it released after 1.0, how about replacing with it blaze? Or do you have project on 0.9?
flow-component also uses ui package.

Okay sure. I'm okay with that. Send me a PR.

@arunoda How about api.versionsFrom(METEOR@0.9.2)? I don't know how it effects project. But it looks little weird :), since we are all using 1.0.

Yes. Use 1.0. That's fine.
I got this from a old repo.
On 2015 මාර්තු 30, සඳුදා at ප.ව. 4.02 Delgermurun Purevkhuu <
<EMAIL_ADDRESS>wrote:

@arunoda https://github.com/arunoda How about
api.versionsFrom(METEOR@0.9.2)? I don't know how it effects project. But
it looks little weird :), since we are all using 1.0.
—
Reply to this email directly or view it on GitHub
https://github.com/meteorhacks/flow-layout/issues/7#issuecomment-87629568
.


Use pyre's stubs

pyre provides stubs for Django. By using them (as
opposed to letting pyre discover the types from the code itself), we get
more accurate type coverage. The former comes from properly configuring
pyre. The latter allows us to drop the HttpRequestWithUser type that
prevents the code from running.

This will fail its type checks until we can take advantage of facebook/pyre-check#256.

I added pyre-ignore comments to get us through to when the stubs are available upstream.


Add test for verifying that extended ascii utf-8 representation

Added test for verifying that extended ascii utf-8 representation works as expected.
fixes https://github.com/hazelcast/hazelcast-cpp-client/issues/539

Linux test PASSed.

Linux test PASSed.

Windows test PASSed.

Windows test PASSed.

Windows test PASSed.


Revert "all: downgrade to go1.19 for now"

This reverts commit a0df30d1ef4858b51bdfe96b7f6c507a0f08fb81.
Change-Id: I01936ab12db9e34f3a8660edf132eab3224d8727

We merge this via the CL. This PR was just for testing.


Contradictions about PR's

https://github.com/roboblazers7617/code-standards/blob/afdcb93106a8ea6e44617e9e5afd68a19ccd4e3c/docs/git-workflow.md?plain=1#L39
This says that PR's should be small, incremental changes and large, major changes.

Duplicate of #3.


Chore/merge 2.0

This merge brings Pl^g 2.0 which is released in the branch 2.0.0 into develop.

I think the history is entirely different so a merge is not really possible

Sorry @KarishmaBothara and @holygits, I have to recreate this PR with a new merge strategy.


pull request for e2e test at 01/29/2017 16:45:12

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


ARM assembly pack: translate bit-sliced AES implementation to AArch64

This addresses a performance issue on the Raspberry Pi 4, when running in AArch64 mode. This device feature a Cortex-A72 CPU, without the cryptography extensions. OpenSSL includes a bit-sliced AES implementation for Arm cores which is used by the Raspberry Pi 4 in AArch32 mode, but this has not been usable in AArch64 mode until now. In fact, it runs a little faster on AArch64 than AArch32 because there are more registers available (so less spilling of variables to the stack is required) and I have been able to schedule the instructions to better suit modern CPUs that are superscalar for SIMD instructions.
The AArch32 version featured a build variant which was used at one point in the past when the same source file was built into the Linux kernel. Linux has since replaced this with a dedicated implementation, so this build variant is not carried across to the AArch64 version.
Here are some benchmarks for a 1.5 GHz Raspberry Pi 4, using openssl speed -evp <type> first with and then without -decrypt:
Before

type
16 bytes
64 bytes
256 bytes
1024 bytes
8192 bytes
16384 bytes

aes-256-cbc
21080.06k
40463.08k
41510.40k
41852.25k
41891.16k
41888.43k

aes-256-cbc
27555.58k
29389.46k
29891.16k
30134.27k
30203.90k
30201.17k

aes-256-ctr
26520.26k
28642.93k
29177.51k
29296.64k
29379.24k
29365.59k

aes-256-ctr
26820.86k
28640.92k
29159.85k
29328.04k
29379.24k
29360.13k

aes-256-xts
12279.51k
18661.29k
21331.88k
22198.12k
22407.85k
22499.23k

aes-256-xts
14026.19k
23280.00k
27721.05k
29099.01k
29523.97k
29545.81k

After

type
16 bytes
64 bytes
256 bytes
1024 bytes
8192 bytes
16384 bytes

aes-256-cbc
44849.12k
53817.86k
64527.36k
69826.22k
71808.34k
71882.07k

aes-256-cbc
27696.58k
29474.52k
30020.78k
30164.31k
30203.90k
30195.71k

aes-256-ctr
46442.28k
54218.82k
74725.72k
82485.59k
85437.10k
85469.87k

aes-256-ctr
46926.52k
54436.48k
74833.66k
82547.37k
85483.52k
85590.02k

aes-256-xts
15969.11k
25832.09k
59270.91k
67184.64k
70331.05k
70593.19k

aes-256-xts
16285.46k
29252.31k
68226.22k
79236.44k
82747.39k
83050.50k

This demonstrates a significant speed-up in all cases except CBC encryption (which by its nature is impossible to parallellise across multiple crypto blocks in the manner performed by bit-slicing).
The make test suite passes.
A separate PR #14578 has been raised to apply the equivalent change to branch OpenSSL_1_1_1-stable.
One thing that I noticed during debugging is that the make test suite occasionally calls the functions with identical input and output pointers. The C prototypes are defined by the types cbc128_f and ctr128_f in modes.h and struct EVP_AES_XTS_CTX member stream in e_aes.c. In all these cases, the in and out arguments to the function pointers do not feature a restrict qualifier, so this is a valid way to call them as far as a C compiler is concerned.
However, I'm aware that the AArch32 implementations (and doubtless many others) do not honour calls with pointers that alias in any other manner than strict equality - in other words, if the input and output buffers only partially overlap. At least for now, this is also the case with my AArch64 implementation. Since the input and output data are of identical size, this could be handled by memmoveing the source to the destination, then performing in-place de/encryption at the destination address. Since this would be a fix required in many places, I wonder whether it would be better implemented as a generic wrapper in some way?
The other course of action, of course, is to leave things as they are. But in that case, may I suggest that it's documented somewhere that identical in and out pointers are permitted, but that is the only form of pointer aliasing that is?

This PR is in a state where it requires action by @openssl/otc but the last update was 30 days ago

I'm not qualified to review the ASM properly. The rest looks okay.

One question that is probably worth asking in such cases is how confident we are that there is test coverage for any edge cases in in the implementation (carry bits, max range for intermediate values, etc).  Since this is supposed to just be translating an existing implementation to a new architecture it's possible that the exsiting test coverage is fine, but it would be reassuring if someone could say that they looked into it and confirm that there are tests exercising the edge cases.

how confident we are that there is test coverage for any edge cases in in the implementation

If it helps, I can share the fuzz testers I used during development: https://github.com/bavison/openssl/commit/d5919b335e97add46076f79458e51ad4de861146. They're only really any use for comparing the 32-bit and 64-bit ARM implementations, since they link directly to the accelerated functions. Also, this won't build if you cherry-pick it directly onto the PR, because it requires that all functions have exported symbols for the linker to use (that's just a matter of temporarily adding a handful of .global directives though).
Iit demonstrates that I've exercised many different text lengths (important for checking all the different code paths for mopping up the final few blocks at a lower degree of parallelism than is used in the inner loop) and lots of different key lengths (actually more than are used in practice).
What my tests didn't pick up was the requirement to handle in-place en/decryption, but make test did find a bug where I was writing to an address ahead of reading its old value if the plaintext and ciphertext pointers were the same. That's what alerted me to the potential problem if the input and output buffers only partially overlap.
If you examine the comments I've inserted at the top of each function, you'll find I've deduced some of the calling constraints (by inspection of the 32-bit version), such as the length of the ciphertext/plaintext being greater than 0 and/or a multiple of 16 bytes. Higher layers may actually impose tighter constraints, but I couldn't find any such documented anywhere and I didn't fancy trying to figure them out :)

24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set.  Please review the updates and set the label manually.

Merged to master.  Thanks for this contribution.

If it helps, I can share the fuzz testers I used during development

thanks, that does help.

@bavison, is it possible to get this change converted to perlasm?
It's not working for OS/X on M1.

We're reverting this for the moment.

The assembler breaks trying to assemble this.  It's not a function of the capabilities of the processor.

I meant, I was wondering if the easiest approach might be, at configuration time, to omit the offending file from the build if it's targeting OSX (on the assumption that every ARM processor that runs OSX doesn't actually benefit from the optimisation anyway). That way, the assembler never gets run on this file for OSX builds.

That would be an option.  Better would be to get this working with Perlasm :)

@bavison Hi, I have a fix for your build issue, would you like me to push a commit to this PR or a diff?

@tom-cosgrove-arm Thanks, that would be great - I still hadn't had chance to get to grips with perlasm yet. The PR branch is open to edits by maintainers of openssl/openssl, so if you are one then you should be able to add a commit. If not, I guess you could raise a PR targeting branch bsaes-aarch64-master on my fork.

@bavison done, you have a PR on your fork

I just removed the merge commit that GitHub added - guessing that's not wanted upstream!

Cross-compilation aarch64-linux-gnu- failure is due to
commit 3675334e2b92eabedbd2f0eb452ade30283b0e56
Author: Pauli<EMAIL_ADDRESS>Date:   Tue May 25 10:40:44 2021 +1000

    aes: rename new bsaes_ symbols -> ossl_bsaes_ ones

    bsaes_cbc_encrypt -> ossl_bsaes_cbc_encrypt
    bsaes_ctr32_encrypt_blocks -> ossl_bsaes_ctr32_encrypt_blocks
    bsaes_xts_decrypt -> ossl_bsaes_xts_decrypt
    bsaes_xts_encrypt -> ossl_bsaes_xts_encrypt

    Reviewed-by: Shane Lontis<EMAIL_ADDRESS>    (Merged from https://github.com/openssl/openssl/pull/15445)

Those renames will need to be made to the source branch for this PR.

The build that failed (cross riscv64-linux-gnu-) appears to have done so because it couldn’t connect to packages.microsoft.com to download packages, not because of anything in this PR

@paulidale can we remove the stalled: awaiting contributor response flag please?

Removed.

Was @appro involved in this, or just the title used in his honor? :)

Was @appro involved in this, or just the title used in his honor? :)

I guess you meant @dot-asm ?

@paulidale what's needed to get this moving again? Can it go into the "after beta period" bucket?

Perlasm would be the best way forwards.  Failing that, better tool chain detection so the assembler failure doesn't occur.
This is definitely post 3.0 beta period.

Hmmm, I must have missed that :disappointed:

Too late to get into 3.0.

Unfortunately this is not usable in the current form - the suggestion is to use the perlasm to avoid build breakage on some platforms.

@t8m I think you may have overlooked the commit from @tom-cosgrove-arm that adds perlasm support?

@t8m I think you may have overlooked the commit from @tom-cosgrove-arm that adds perlasm support?

Ah, you're right, I was looking at the older version of the PR.

Hi I'm interested in building this to get speedup on RPi 4b 64bit.
So just to get som eclarification, this hasn't made it though PR yet?

No this hasn't been merged to the mainline yet.
You could grab the commits from here and build them.

This pull request is ready to merge

Merged to master branch. Thank you for your contribution!


fix: Spacing between sections in gallery item

Thank you for your contribution to the KodaDot - One Stop Shop for Polkadot NFTs.
👇 __ Let's make a quick check before the contribution.
PR Type

[x] Bugfix

Needs Design check

@exezbcz please review

Context

[x] Closes #7948
[ ] Requires deployment <snek/rubick/worker>

Did your issue had any of the "$" label on it?

[x] My DOT address: Payout

Screenshot 📸

[x] My fix has changed UI

Copilot Summary

🤖 Generated by Copilot at 1645fa2
Added a new utility class .mt-10 for vertical spacing and applied it to the GalleryItem.vue component. This improves the layout and readability of the NFT details and carousels.

🤖 Generated by Copilot at 1645fa2

GalleryItem changed
.mt-10 adds more space
Autumn leaves breathe out

Thanks!
pay 30 usd

😍 Perfect, I’ve sent the payout
💵 $30 @ 4.86 USD/DOT ~ 6.173 $DOT
🧗 16SjUbGKSdjCdWTy3NNT3JxbRVGGqD4mwkHpc6BD9U2Rp29Z
🔗 0xc3ade164db4f1a03b957c2675ecb2a36b2d435a7bd535826724710e728c8b139
🪅 Let’s grab another issue and get rewarded!
🪄 github.com/kodadot/nft-gallery/issues


Fixed missing yieldToInput renaming in inner loops

The yieldToInput attribute is not renamed in inner loops. As a result you get the error message Cannot yield non-existing variable XXXX whenever you want to add some data to the loop again.
See the following example. It should be an infinite loop. However, it aborts with the above error.
This pull request includes a unit test to reproduce the behaviour and adds the renaming in the ProcessChainGenerator
api: 4.6.0
name: Iterator Test - Einfaches Yield to input geht nicht
vars:
  - id: wrapperList
    value: ['1']
actions:
  - type: execute
    service: touch
    outputs:
      - id: file
        var: touchOut

  - id: wrapper
    type: for
    input: wrapperList
    enumerator: currentWrapper
    actions:

      - type: for
        input: touchOut
        enumerator: innerEnumerator
        yieldToInput: copy
        actions:
          - type: execute
            service: cp
            inputs:
              - id: input_file
                var: innerEnumerator
            outputs:
              - id: output_file
                var: copy

Nice catch! Thank you!


Config by hostname

this enables by-hostname configuration for resque-pool.
environment variables can still be used as usual.
example

general_job1: 1
general_job2: 1

staging:
    staging_worker: 1

workers-production-1:
    can_only_be_run_once: 1
    generic_worker: 5

workers-production-2:
    generic_worker: 10

I think this is obsoleted by ERB support (in 0.4.0) and also by the #85 PR (which I do hope to revisit and merge into master soon).  Thanks for your contributions!


Clearly define how traits should be applied

Reason/Context
Because traits can be somewhat hard to get right, we need to ensure that all parsers apply them correctly and provide all the necessary documentation to achieve it.
Related issues:
Spec issue: https://github.com/asyncapi/spec/issues/505
Spec PR: https://github.com/asyncapi/spec/pull/532

Thanks for bringing this up!
In this JSFiddle I've provided two example implementations in JavaScript, in the case that we want to go with the approach proposed in #532:

https://jsfiddle.net/FannonF/yLsonr57/latest/

The first implementation (function apply(origin, patch)) is based on JSON Merge patch and deletes target properties if null is passed.
The second implementation (function merge(...objects)) is very similar, but skips on the special null behavior (my personal preference)
In general, I'm unsure whether we should base trait inheritance on the JSON Merge patch RFC, as its semantics are different from what we want to have from traits. Merge Path is basically about the patch overwriting the target. Inheritance / Traits are about applying information from the source to the target, but never overwriting the target.
I'm also unsure on the Merge Patch behavior of using null to remove a property. This is essential for patches, but I can see how this is misleading (and I think even unnecessary) for trait inheritance.
Please be aware that there are no unit-tests for this implementation. Before putting it into the spec, we should write unit-tests with various example data.


Shell.chop() only on a single face

Chop only the first block of a shell, other blocks should copy from it.
When Shell will be made from disconnected faces, a warning should be issued (a matter of discussion?).

Fixed with commit 512c9a5


HBASE-26834 Adapt ConnectionRule for both sync and async connections (branch-2)

This is needed primarily for branch-2 codelines where there's no easy bridge from AsyncConnection to Connection.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

-0 :warning:
yetus
0m  9s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck --skip-errorprone --hadoop-profile --exclude-tests-url --build-thread --surefire-first-part-fork-count --surefire-second-part-fork-count

_ Prechecks _

_ branch-2 Compile Tests _

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

-1 :x:
mvninstall
0m 19s
root in branch-2 failed.

-1 :x:
compile
0m 26s
hbase-it in branch-2 failed.

-1 :x:
compile
0m 17s
hbase-server in branch-2 failed.

-0 :warning:
javadoc
0m  9s
hbase-it in branch-2 failed.

-0 :warning:
javadoc
0m 10s
hbase-server in branch-2 failed.

_ Patch Compile Tests _

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

-1 :x:
mvninstall
0m  9s
hbase-it in the patch failed.

-1 :x:
mvninstall
0m 10s
hbase-server in the patch failed.

-1 :x:
compile
0m 10s
hbase-it in the patch failed.

-1 :x:
compile
0m  8s
hbase-server in the patch failed.

-0 :warning:
javac
0m 10s
hbase-it in the patch failed.

-0 :warning:
javac
0m  8s
hbase-server in the patch failed.

-0 :warning:
javadoc
0m 10s
hbase-it in the patch failed.

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

_ Other Tests _

-1 :x:
unit
0m  9s
hbase-it in the patch failed.

-1 :x:
unit
0m 10s
hbase-server in the patch failed.

6m 19s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit compile

uname
Linux 18ae33184c8b 5.4.0-90-generic #101-Ubuntu SMP Fri Oct 15 20:00:55 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / 50e12309ea

Default Java
AdoptOpenJDK-11.0.10+9

mvninstall
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4220/1/artifact/yetus-jdk11-hadoop3-check/output/branch-mvninstall-root.txt

compile
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4220/1/artifact/yetus-jdk11-hadoop3-check/output/branch-compile-hbase-it.txt

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

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

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

mvninstall
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4220/1/artifact/yetus-jdk11-hadoop3-check/output/patch-mvninstall-hbase-it.txt

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

compile
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4220/1/artifact/yetus-jdk11-hadoop3-check/output/patch-compile-hbase-it.txt

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

javac
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4220/1/artifact/yetus-jdk11-hadoop3-check/output/patch-compile-hbase-it.txt

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

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

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

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

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

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

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

modules
C: hbase-it hbase-server U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4220/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.

The master forward-port is posted on #4221

@busbey do you have any idea why this might be? Is there something missing from the hadoop.three profile in one of the submodules that is required for invoking tests on this module? The failing build is prefixed with this warning.
cd /home/jenkins/jenkins-home/workspace/Base-PreCommit-GitHub-PR_PR-4220/yetus-jdk11-hadoop3-check/src
/opt/maven/bin/mvn --batch-mode -Dmaven.repo.local=/home/jenkins/jenkins-home/workspace/Base-PreCommit-GitHub-PR_PR-4220/yetus-m2/hbase-branch-2-patch-1 -fae clean install -DskipTests=true -Dmaven.javadoc.skip=true -Dcheckstyle.skip=true -Dfindbugs.skip=true -Dspotbugs.skip=true
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for org.apache.hbase:hbase-build-configuration:pom:2.6.0-SNAPSHOT
[WARNING] 'profiles.profile[hadoop-3.0].dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)' must be unique: org.apache.hadoop:hadoop-mapreduce-client-app:test-jar -> duplicate declaration of version ${hadoop-three.version} @ org.apache.hbase:hbase:2.6.0-SNAPSHOT, /home/jenkins/jenkins-home/workspace/Base-PreCommit-GitHub-PR_PR-4220/yetus-jdk11-hadoop3-check/src/pom.xml, line 3527, column 22
[WARNING]
[WARNING] Some problems were encountered while building the effective model for org.apache.hbase:hbase:pom:2.6.0-SNAPSHOT
[WARNING] 'profiles.profile[hadoop-3.0].dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)' must be unique: org.apache.hadoop:hadoop-mapreduce-client-app:test-jar -> duplicate declaration of version ${hadoop-three.version} @ line 3527, column 22
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]

@busbey do you have any idea why this might be? Is there something missing from the hadoop.three profile in one of the submodules that is required for invoking tests on this module? The failing build is prefixed with this warning.
cd /home/jenkins/jenkins-home/workspace/Base-PreCommit-GitHub-PR_PR-4220/yetus-jdk11-hadoop3-check/src
/opt/maven/bin/mvn --batch-mode -Dmaven.repo.local=/home/jenkins/jenkins-home/workspace/Base-PreCommit-GitHub-PR_PR-4220/yetus-m2/hbase-branch-2-patch-1 -fae clean install -DskipTests=true -Dmaven.javadoc.skip=true -Dcheckstyle.skip=true -Dfindbugs.skip=true -Dspotbugs.skip=true
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for org.apache.hbase:hbase-build-configuration:pom:2.6.0-SNAPSHOT
[WARNING] 'profiles.profile[hadoop-3.0].dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)' must be unique: org.apache.hadoop:hadoop-mapreduce-client-app:test-jar -> duplicate declaration of version ${hadoop-three.version} @ org.apache.hbase:hbase:2.6.0-SNAPSHOT, /home/jenkins/jenkins-home/workspace/Base-PreCommit-GitHub-PR_PR-4220/yetus-jdk11-hadoop3-check/src/pom.xml, line 3527, column 22
[WARNING]
[WARNING] Some problems were encountered while building the effective model for org.apache.hbase:hbase:pom:2.6.0-SNAPSHOT
[WARNING] 'profiles.profile[hadoop-3.0].dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)' must be unique: org.apache.hadoop:hadoop-mapreduce-client-app:test-jar -> duplicate declaration of version ${hadoop-three.version} @ line 3527, column 22
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]

Oh. That mvn invocation is missing the -Dhadoop.profile=3.0 that is required for building under JDK11.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

-0 :warning:
yetus
0m  4s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck --skip-errorprone --exclude-tests-url --build-thread --surefire-first-part-fork-count --surefire-second-part-fork-count

_ Prechecks _

_ branch-2 Compile Tests _

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

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

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

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

_ Patch Compile Tests _

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

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

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

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

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

_ Other Tests _

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

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

159m 47s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit compile

uname
Linux a49bb08d3d44 5.4.0-90-generic #101-Ubuntu SMP Fri Oct 15 20:00:55 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / 50e12309ea

Default Java
AdoptOpenJDK-1.8.0_282-b08

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

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

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

modules
C: hbase-server hbase-it U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4220/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.

Oh. That mvn invocation is missing the -Dhadoop.profile=3.0 that is required for building under JDK11.

that flag is supposed to get set over here:
https://github.com/apache/hbase/blob/master/dev-support/hbase-personality.sh#L170-L175
so either our branch pattern matching is broken, something else is overriding the setting, or this execution flow somehow skips personality_modules

Okay, well. JDK11 aside, the failures in JDK8 build look like worker resource exhaustion and unrelated to this change. None of those test classes use this Rule, so...

@busbey my earlier diagnosis was not entirely accurate -- this is not PR's fault. I reproduce the same behavior when I run a single test out of a single module (with JDK11, Hadoop3, branch-2). i.e.,
$ env JAVA_HOME=/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home mvn clean install -Dhadoop.profile=3.0
$ env JAVA_HOME=/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home mvn -pl hbase-server test -Dhadoop.profile=3.0 -Dtest=TestApiV1ClusterMetricsResource

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 57s
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 --skip-errorprone --hadoop-profile --exclude-tests-url --build-thread --surefire-first-part-fork-count --surefire-second-part-fork-count

_ Prechecks _

_ branch-2 Compile Tests _

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

-1 :x:
mvninstall
0m 15s
root in branch-2 failed.

-1 :x:
compile
0m 27s
hbase-it in branch-2 failed.

-1 :x:
compile
0m 17s
hbase-server in branch-2 failed.

-0 :warning:
javadoc
0m 10s
hbase-it in branch-2 failed.

-0 :warning:
javadoc
0m 10s
hbase-server in branch-2 failed.

_ Patch Compile Tests _

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

-1 :x:
mvninstall
0m 11s
hbase-it in the patch failed.

-1 :x:
mvninstall
0m 10s
hbase-server in the patch failed.

-1 :x:
compile
0m 10s
hbase-it in the patch failed.

-1 :x:
compile
0m  9s
hbase-server in the patch failed.

-0 :warning:
javac
0m 10s
hbase-it in the patch failed.

-0 :warning:
javac
0m  9s
hbase-server in the patch failed.

-0 :warning:
javadoc
0m  9s
hbase-it in the patch failed.

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

_ Other Tests _

-1 :x:
unit
0m 10s
hbase-it in the patch failed.

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

6m 41s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit compile

uname
Linux<PHONE_NUMBER>d8 5.4.0-90-generic #101-Ubuntu SMP Fri Oct 15 20:00:55 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / fdc7c49c01

Default Java
AdoptOpenJDK-11.0.10+9

mvninstall
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4220/2/artifact/yetus-jdk11-hadoop3-check/output/branch-mvninstall-root.txt

compile
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4220/2/artifact/yetus-jdk11-hadoop3-check/output/branch-compile-hbase-it.txt

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

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

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

mvninstall
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4220/2/artifact/yetus-jdk11-hadoop3-check/output/patch-mvninstall-hbase-it.txt

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

compile
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4220/2/artifact/yetus-jdk11-hadoop3-check/output/patch-compile-hbase-it.txt

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

javac
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4220/2/artifact/yetus-jdk11-hadoop3-check/output/patch-compile-hbase-it.txt

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

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

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

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

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

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

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

modules
C: hbase-it hbase-server U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4220/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.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

-0 :warning:
yetus
0m  9s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck --skip-errorprone --hadoop-profile --exclude-tests-url --build-thread --surefire-first-part-fork-count --surefire-second-part-fork-count

_ Prechecks _

_ branch-2 Compile Tests _

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

-1 :x:
mvninstall
0m 16s
root in branch-2 failed.

-1 :x:
compile
0m 10s
hbase-it in branch-2 failed.

-1 :x:
compile
0m 11s
hbase-server in branch-2 failed.

-0 :warning:
javadoc
0m 11s
hbase-it in branch-2 failed.

-0 :warning:
javadoc
0m 11s
hbase-server in branch-2 failed.

_ Patch Compile Tests _

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

-1 :x:
mvninstall
0m 10s
hbase-it in the patch failed.

-1 :x:
mvninstall
0m 13s
hbase-server in the patch failed.

-1 :x:
compile
0m 10s
hbase-it in the patch failed.

-1 :x:
compile
0m 11s
hbase-server in the patch failed.

-0 :warning:
javac
0m 10s
hbase-it in the patch failed.

-0 :warning:
javac
0m 11s
hbase-server in the patch failed.

-0 :warning:
javadoc
0m  9s
hbase-it in the patch failed.

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

_ Other Tests _

-1 :x:
unit
0m 11s
hbase-it in the patch failed.

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

6m 13s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit compile

uname
Linux 7d286feaa68c 5.4.0-90-generic #101-Ubuntu SMP Fri Oct 15 20:00:55 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / fdc7c49c01

Default Java
AdoptOpenJDK-11.0.10+9

mvninstall
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4220/3/artifact/yetus-jdk11-hadoop3-check/output/branch-mvninstall-root.txt

compile
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4220/3/artifact/yetus-jdk11-hadoop3-check/output/branch-compile-hbase-it.txt

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

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

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

mvninstall
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4220/3/artifact/yetus-jdk11-hadoop3-check/output/patch-mvninstall-hbase-it.txt

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

compile
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4220/3/artifact/yetus-jdk11-hadoop3-check/output/patch-compile-hbase-it.txt

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

javac
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4220/3/artifact/yetus-jdk11-hadoop3-check/output/patch-compile-hbase-it.txt

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

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

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

unit
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4220/3/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-hbase-it.txt

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

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

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

modules
C: hbase-it hbase-server U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4220/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
1m 15s
Docker mode activated.

-0 :warning:
yetus
0m  6s
Unprocessed flag(s): --quick-hadoopcheck --exclude-tests-url --asf-nightlies-general-check-base --build-thread --surefire-first-part-fork-count --surefire-second-part-fork-count

_ Prechecks _

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

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

_ branch-2 Compile Tests _

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

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

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

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

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

_ Patch Compile Tests _

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

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

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

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

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

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

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

_ Other Tests _

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

19m 16s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense javac spotbugs checkstyle compile

uname
Linux fd4d73f9eb6a 5.4.0-1025-aws #25~18.04.1-Ubuntu SMP Fri Sep 11 12:03:04 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / fdc7c49c01

Default Java
AdoptOpenJDK-1.8.0_282-b08

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

modules
C: hbase-server hbase-it U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4220/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 16s
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 _

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

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

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

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

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

_ Patch Compile Tests _

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

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

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

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

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

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

_ Other Tests _

-1 :x:
unit
9m  8s
hbase-server in the patch failed.

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

21m 30s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 80ea8e956cc5 5.4.0-90-generic #101-Ubuntu SMP Fri Oct 15 20:00:55 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / 26af3b9822

Default Java
AdoptOpenJDK-1.8.0_282-b08

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

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

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

modules
C: hbase-server hbase-it U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4220/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
0m 54s
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 _

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

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

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

+1 :green_heart:
checkstyle
0m 51s
branch-2 passed

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

_ Patch Compile Tests _

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

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

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

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

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

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

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

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

_ Other Tests _

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

31m 29s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux e11fb3d49266 5.4.0-1025-aws #25~18.04.1-Ubuntu SMP Fri Sep 11 12:03:04 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / 26af3b9822

Default Java
AdoptOpenJDK-1.8.0_282-b08

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

modules
C: hbase-server hbase-it U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4220/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 44s
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 _

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

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

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

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

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

_ Patch Compile Tests _

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

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

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

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

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

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

_ Other Tests _

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

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

47m 11s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 3ae2dc5aaf57 5.4.0-90-generic #101-Ubuntu SMP Fri Oct 15 20:00:55 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / 26af3b9822

Default Java
AdoptOpenJDK-11.0.10+9

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

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

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

modules
C: hbase-server hbase-it U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4220/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.

The failed UT seems because I set java.io.tmpdir to target on the mvn command line...
We should have set it explicitly in surefire arg line, not sure why setting it on mvn command line would effect this...
Let me dig more.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 41s
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 _

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

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

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

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

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

_ Patch Compile Tests _

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

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

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

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

+1 :green_heart:
checkstyle
1m 37s
the patch passed

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

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

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

_ Other Tests _

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

48m 16s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux e226853a0d84 5.4.0-1054-aws #57~18.04.1-Ubuntu SMP Thu Jul 15 03:21:36 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / b5d5fe8fe5

Default Java
AdoptOpenJDK-1.8.0_282-b08

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

modules
C: hbase-server hbase-it U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4220/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.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 39s
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 _

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

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

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

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

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

_ Patch Compile Tests _

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

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

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

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

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

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

_ Other Tests _

-1 :x:
unit
202m 31s
hbase-server in the patch failed.

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

222m 29s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux a87f82c96741 5.4.0-1054-aws #57~18.04.1-Ubuntu SMP Thu Jul 15 03:21:36 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / b5d5fe8fe5

Default Java
AdoptOpenJDK-11.0.10+9

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

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

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

modules
C: hbase-server hbase-it U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4220/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.

Failure in TestReplicationSource is unrelated.


External Kernel API shouldn't require a notebookDocument to create a kernel

Right now our API requires a NotebookDocument to be passed in to create a kernel:
https://github.com/microsoft/vscode-jupyter/blob/e6d86dabc25d9e63b850251b7e5e576dfb86aaea/src/platform/api/extension.d.ts#L281
This is rather limiting and forces callers to create dummy notebook documents.
We really only need a unique key to make sure we don't create the same kernel more than once.

perhaps we can create a notebook document internally .
i don't want to change our code just to accommodate 3rd parties just yet (feels too early).
using a notebook document is easy so that we can manage the lifetime and the like.
i totally agree it's not ideal and it is limiting, however if we have more users if the api then i think we should change, else prefer the simplicity it offers.

The problem right now is that the notebook document (unless it's shown) seems to auto dispose itself. Which in turn kills the kernel.

Maybe internally we can create a dummy notebook that is just the same interface but not actually backed by anything. In fact I bet @pwang347 could try that.

backed by anything. In fact I bet @pwang347 could try that.

that's exactly the code sample i provided (provided that some time ago with a sample to use this api). you can create an ipynb notebook easily today.

Is the sample still available? Maybe we should link to it in the doc for the api?

@rchiodo @DonJayamanne I can confirm that a dummy class implementing the interface works

Power tools extension verifies this is true.
/verified


Make 'ghcid' work with 'clashi' (proposals)

Over at https://github.com/clash-lang/clash-compiler we're building a Haskell to hardware compiler, Clash. Every program written in Clash is also a valid Haskell program, which basically means that we get a "Clash to x86" - therefore a "hardware simulator" - compiler for free. This means we can also use GHCi to build Clashi:
Clashi, version 1.1.0 (using clash-lib, version 1.1.0):
https://clash-lang.org/  :? for help
Clash.Prelude>

ghcid doesn't currently work with clashi due to it not recognizing the version string. We could:

Add Clashi, version  to the list
Match on [a-zA-z]+i, version  instead
Launch the REPL processes with an environment flag set (LAUNCHED_BY_GHCID=1?) such that the process can output ghcid compatible strings

I'm willing to make a PR for any of these. Would any of these PRs be accepted?

I'd certainly accept 1, and it seems the least effort, so I suggest we do that. Also happy with 3, if you think that's easier. I have minor concerns with 2, about spotting incorrect things as versions, so unless that's got other benefits, let's not do it now.

I've made a release, v0.7.6, so you can use it installed.

That's great! Thanks!


Is there any way to ignore transparent background in png?

Hi, I'm trying to convert signature to vector image. I have png image with transparent background, but when I transform image to SVG, it fills out whole backgound with colored path. Is there any way to avoid that.
Used options:
            //detailed
            pathomit:0,
            roundcoords:2,
            ltres:0.5,
            qtres:0.5,
            //curvy
            linefilter: true,
            rightangleenhance:false,
            //grayscale
            colorsampling:0,
            colorquantcycles:1,
            numberofcolors:2,

Another question is: Can you advice me best option to make curved, smooth and noisyless options, thanks
Images attached here:
Archive.zip

@arsenanai were you able to find the answer to making smooth, noisyless curves? Mine look like this

Hi,
@arsenanai : this can be related to Issue #31  , I'm working on it.
@r-zammit : we will discuss this question in Issue #40

Hi,
@arsenanai : This should be fixed in version 1.2.6, please test.
@r-zammit : I close this Issue, we will continue in Issue #40


fix(auth): Replace force unwrap to throw an error in AWS credentials

Issue #, if available:
Description of changes:
Check points:

[x] Added new tests to cover change, if needed
[x] All unit tests pass
[ ] All integration tests pass
[ ] Documentation update for the change if required
[x] PR title conforms to conventional commit style

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

Codecov Report

Merging #1476 (4d75b3b) into main (53b828a) will increase coverage by 0.07%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #1476      +/-   ##
==========================================
+ Coverage   58.34%   58.42%   +0.07%
==========================================
  Files         678      678
  Lines       20652    20674      +22
==========================================
+ Hits        12050    12079      +29
+ Misses       8602     8595       -7

Flag
Coverage Δ

API_plugin_unit_test
61.57% <ø> (+0.09%)
:arrow_up:

AWSPluginsCore
72.99% <ø> (ø)

Amplify
45.98% <ø> (+0.08%)
:arrow_up:

Analytics_plugin_unit_test
71.76% <ø> (ø)

Auth_plugin_unit_test
78.96% <100.00%> (+0.20%)
:arrow_up:

DataStore_plugin_unit_test
74.74% <ø> (+0.01%)
:arrow_up:

Predictions_plugin_unit_test
26.81% <ø> (ø)

Storage_plugin_unit_test
58.06% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...AuthorizationProviderAdapter+SignedInSession.swift
91.66% <100.00%> (+0.26%)
:arrow_up:

...uthorizationProviderAdapter+SignedOutSession.swift
100.00% <100.00%> (ø)

...lugin/Support/Utils/AWSCredentials+Extension.swift
100.00% <100.00%> (ø)

...nitoAuthPlugin/Support/Utils/AuthErrorHelper.swift
77.20% <100.00%> (+0.34%)
:arrow_up:

.../DataStore/Model/Internal/Schema/ModelSchema.swift
62.50% <0.00%> (-2.09%)
:arrow_down:

...comingAsyncSubscriptionEventToAnyModelMapper.swift
37.50% <0.00%> (+2.08%)
:arrow_up:

...CategoryPlugin/Operation/AWSGraphQLOperation.swift
52.32% <0.00%> (+2.32%)
:arrow_up:

...s/AWSHubPlugin/Internal/HubChannelDispatcher.swift
88.23% <0.00%> (+8.82%)
:arrow_up:

Amplify/Categories/Hub/HubFilter.swift
57.89% <0.00%> (+10.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 53b828a...4d75b3b. Read the comment docs.


PSS and padding options for Node 0.12

Replaces https://github.com/quartzjer/ursa/pull/66

I don't have enough experience to thoroughly test this, but it looks great, thank you!
I'll merge it to master and bump a new npm minor version this week :)

@quartzjer thanks for merging. I did add some tests in there and the existing ones run fine.
That means everything will be fine, right? :grinning:


Prediction of Organic Molecular Eutectic Structure

Hello author, may I ask if GAN can be used to predict the eutectic structures of two organic compounds, such as CL20 and BTF? Currently, the eutectic structures of these two compounds have not been prepared yet. Is this project feasible? We look forward to your reply.

Our model is trained on a crystal database and is designed to generate crystals rather than organic compounds. While generative frameworks can be used to predict eutectic structures by utilizing an appropriate structure embedding to establish a generative model.

Thank you for your reply. Mr. Cao, currently my supervisor has asked me to modify the generative model in an article: Composite Conditioned Crystal GAN, which is applied to generate Mg-Mn-O ternary materials for eutectic prediction. I am wondering if this model is not suitable for eutectic prediction, as the difficulty lies in extracting the features of two organic crystals. Finally, Mr. Cao, may I ask if there is currently a similar generative model (open-source) available for predicting eutectic structures. Excuse me

Thank you for your reply. Mr. Cao, currently my supervisor has asked me to modify the generative model in an article: Composite Conditioned Crystal GAN, which is applied to the generation of Mg-Mn-O ternary materials. To conduct eutectic prediction of CL20/BTF, it is difficult to determine whether this model is not suitable for eutectic prediction, as the difficulty lies in extracting the features of the two organic crystals. Finally, Mr. Cao, may I ask if there is currently a similar generative model (open-source) available for predicting eutectic structures. Excuse me

Thank you for your interest in our work. Some research findings related to eutectic formation do not align with the key points of our study. You may find additional insights in this article: https://www.nature.com/articles/s41524-024-01385-5.


FAQ: Sending MATIC from an Exchange to the Polygon Network w/o the bridge (Nominal Gas Fee)

Proposal (For Review) - Matic to Polygon Bridge Alternative (FAQ)
Mission:

Challenge: Getting MATIC tokens from an exchange onto the Polygon Network is really confusing. Traditional bridge is expensive for first timers.
Biomimicry: How do synapses transmit information across different sections of our neural network?
Goal: Create FAQ section for how purchase MATIC on Okcoin and send to [WALLET] to mint Horsemen tokens

Roadmap:

Create documentation for walkthrough in GitHub

Set up Okcoin
purchase MATIC (wait X amount of days)
download EF promoted wallet
add polygon network to the downloaded wallet
transfer MATIC to the wallet
connect wallet to minting dApp
purchase Free Horsemen Intro NFT (see below)
done

Discuss where else documentation gets shared:

Gitbook?
Notion?
Medium?
Substack?

Free to mint polygon NFT for people who complete the walkthrough

EF Designed Stamps that introduce the different characters
Or Jiba can do a quick/sketched comic strip for the diff characters guiding people from web3 into into the Horsemen web3 universe with EF Learning Lab documentation.

Deliverables:

Learning Engine Case Study as a summary
Matic to Polygon Tutorial NFT
URL for completed documentation

GitHub
Notion
Medium?
Substack?

Share completed documentation to the network

Discord
Twitter
Instagram?
Medium?
Substack?

"Free to mint polygon NFT for people who complete the walkthrough" - I love this! Kind of like proof-of-view?

Yea! If they follow the tutorial and can purchase the free NFT with some MATIC gas it'll prove they learned something new and upgraded their powers. Maybe whichever one of the Horsemen that's most welcoming is infusing their powers in the people who complete this tutorial. Could use EF Stamps like learning badges and a way to track engagement/views.

I also like the biomimicry approach. It's different, but it's also anti-fragile, which is RAD. This is another aspect of our approach that differentiates us from the crowd.

That all sounds awesome! I know nothing about learning management systems, so that's all way over my head. Would be so cool to have those kinds of metrics.
I'll get to work on the actual thing you asked me to do in the first place haha (the steps to go from exchange to minting). At this stage I was thinking about keeping it simple and just putting documentation here on GitHub (or GitBook/Notion?), and one of the steps in the documentation would take them to the free minting dApp. If people actually mint some free NFTs and proceed to mint horsemen NFTs we'll know we're onto something.
I'll start working on the steps tomorrow, and I'll keep you posted! Do you have a preferred Wallet that EF will recommend people sent their MATIC to now that wallet connect is set up??

Hmmm… I have some Unstoppable Domains that we could dust off for this project. I’ll check into that today!

I've found a UI pattern we can follow for this experience. It would be great if we could keep them in the minting experience without sending them to an LMS.

Wow this is great! So this is the decentraland app??? Also what does LMS stand for?

This is an app made by one of the members of our Teams group. Decentral Games is basically all about playing poker in the metaverse. Thing is, you can stake NFTs to players in the game for passive income. Cool, right? Anyway, LMS stands for Learning Management System. They’re kind of like stand alone websites for taking classes, completing courses, taking quizzes and tests. Scores, grades, and progress reports are output from the system for instructors and administrators to evaluate results. All-in-all, that’s probably too much for what we’re trying to do - lol

That's such a cool concept, and yea amazing flow. So cool that's someone in the group. Is their code open source??? We might be able to easily adapt it for this.
Ah okay cool yea probably soon for LMS but I'll definitely be looking into them more. Thanks for clarifying!


Feature request - get all reviewers of a PR, requested or not

For some yet unknown reason the API always states that there are no reviewers for any PR.

The API is actually returning the requested reviewers, that is the users that the PR author has requested a review from.
These are the ones that in the WebUI appear with a yellow dot.
If we want to have something similar to what the WebUI shows, then we need to retrieve pullRequestReviews.author.login and pullRequestReview.state. Also, since I user can leave multiple reviews, we need to "merge" them, so we only show the "strongest" one (eg: if a user leaves CHANGES_REQUESTED and COMMENTED, only CHANGES_REQUESTED). I think that is what the WebUI does, but thats probably work for a new PR
Originally posted by @pwntester in https://github.com/pwntester/octo.nvim/issues/121#issuecomment-793666563

Fixed in #130


^0.8 & ^0.7 releases depends on alpha dependencies

Currently in order to use this package without allowing dev dependencies I need to do this
    "memio/spec-gen": "*",
    "memio/memio": "@alpha",
    "memio/linter": "@alpha",
    "memio/validator": "@alpha",
    "memio/model": "@alpha",
    "memio/pretty-printer": "@alpha",
    "memio/twig-template-engine": "@alpha",

(substituting the * for the appropriate version), this is a total pain. Can we have tagged releases of the used repositories?

Hey @PurpleBooth! I'll look into it in the following days

Done :white_check_mark:

Thanks! Love the extension btw!


VIH-9699 use in memory database

JIRA link (if applicable)
VIH-9699
Change description

use in memory database
Use the test server and stubs to run API tests

Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[x] No

/azp run

/azp run


Precommit Hook Linting

I jumped on this before I saw that @aterranova-bv was going to take it. Sorry about that!
Lint script and hook working as expected.
https://github.com/ersel/spotify-cli-mac/issues/14
Thanks!

Lol I'm just seeing this - no worries.
You can take your pick between this and #17 lol.
Happy Hacktoberfest!

Thanks for your contribution @jakehasler. I have already merged @aterranova-bv 's commit.


[BFCL] Wether there is any semantic checker for the parameters' value？

Describe the issue
When we do the evaluation, do we have some checker that checks the semantic consistency of the parameters instead of simply matching them from the candidate list？
It seems too harsh that  some minor errors that lead to errors, such as San Diego and San Diego, CA are different in format, but the two are semantically consistent.
What's more, like this error "Invalid value for parameter 'items': ['pumpkin', 'egg']. Expected one of [['pumpkins', 'eggs'], ['pumpkin', 'dozen eggs']]."
Looking forward to your reply.

Hi @Ghevil,
Unfortunately, we don't have any semantic checkers at this moment.
In addition to trying to make the candidate list as comprehensive as possible, we have also tried to be clear and pose restrictions on the parameter formats in the function documentation. For example, in the location example you provided, we would phrase it as the following so that only San Diego, CA is correct and San Diego would be wrong.
{
    "location": {
        "type": "string",
        "description": "The location in 'city, state' format."
    }
}

As another example, for things like date, there would only be one correct ground truth.
{
    "end_date": {
        "type": "string",
        "description": "The ending date until which to retrieve stock prices. Format: 'yyyy-mm-dd'."
    }
}

If you have any other good solutions, we would love to hear your thoughts.


hello world? Which end is up?

I'm very interested to understand how you expect this to work. But I can't quite tell by looking through the tests and such what's supposed to be going on.
Here's hoping you're inspired to write a paragraph or two and add a hello world in your README.
Alternatively, I could interview you for 10 minutes by chat / screenshare / etc., write up what I learned, and submit it as a PR.
p.s. it was nice meeting you in Boulder in April, @kumavis

checkout the new introductory repos!
https://github.com/lavamoat/overview
https://github.com/lavamoat/lavamoat-browserify-examples

Interesting. Thanks.
In particular, via the overview, I discovered https://github.com/Agoric/SES/blob/master/docs/secure-coding-guide.md , which I had not seen.


Fix off-by-one error that could panic.

Required for all non-trivial PRs

[X] Rebased/mergable
[X] Tests pass
[ ] CHANGELOG.md updated
[X] Sign CLA (if not already signed)

Fix off-by-one error that could panic.

Nice catch.
/cc @jwilder


feature request: Make DependecyTypes from RemoteDependencyConstants public

Is your feature request related to a problem?
DependencyTelemetry.Type is a string but is set using constants from RemoteDependencyConstants. It would be nice to be able to use those constants instead of comparing to magic strings, for example "HTTP".
Describe the solution you'd like.
Some properties related to operation details in RemoteDependencyConstants got moved out to its own class in #2524. I suggest a similar solution here.
Describe alternatives you've considered.
Leave it as-is. Make the entire class RemoteDependencyConstants public. Use an enum.
Additional context.
This is suggested by @older in #1326.

Not stale

@cijothomas Does this seem like a good idea? I think I can open a PR if it does.
My suggestion: Move Microsoft.ApplicationInsights.DependencyCollector.Implementation.RemoteDependencyConstants  down a notch to Microsoft.ApplicationInsights.DependencyCollector.RemoteDependencyConstants and make it public. What do you say?

While the idea is good, I think its best to look into the OpenTelemetry based solutions (which are not quite as feature rich as this sdk, but getting there..), given that OTel is the long term direction for telemetry sdks.
(You may have noticed that this repo has stopped making any changes except security issues/updates to support newer .NET runtimes etc.)


[Todo] Consider darkening the background

To better resemble current feathericons.com.

Is this repo currently taking pull requests? I can close some of the available issues if needed!

Absolutely! I can’t guarantee I will accept all of them but you’re more than welcome to contribute.
If you try to build this locally, you’ll need to run yarn tw-dev first in order to build Tailwind CSS. Besides that, you should be able to get started!

Thanks, I'll get started then!

Just to clarify, do you mean you want a color that's closer to black? The same black color that feathericon uses? Or just a darker gray color.

This one I’m not 100% sure we need to actually do. I was just recommended it is all. The idea was to make the new site feel more like the whole site but that’s not a huge priority of mine. I think the other issues would be more worthwhile than this one.


Tv Shows with a (written) number in title

Hi shows that have a written number in the title aren't found for Example Brooklyn Nine Nine and Hawaii Five-O.
In the log it is searching for Brooklyn 99 and hawaii 5 o

This one will be a little trickier, but I'll look into it.

@nawo69 Alexa is doing things correctly, it is the way the show is titled and then marketed that is the problem.
When saying "Hawaii Five-O" you are probably (and understandably) saying "five oh",  but the "oh" is actually a "zero". It might work if you said "hawaii five zero"
Fun fact from wikipedia: The title of the new show uses a zero ("0") rather than the letter "O" used in the 'Five-O' of the original.
The same is true with "double oh seven", it should be pronounced "zero zero seven"
You could try changing the titles in your library to what Alexa thinks you are saying.

@digiltd it is the Five in Hawaii Five 0 that is causing the issue not the 0 anyway :)
Changing the titles might work but on a automatic download/renaming system would have to do this manually every time a episode is downloaded.
It isn't a massive issue just thought it was worth flagging up

The skill could try querying the database in different ways, but there'd be a speed tradeoff there too.
Alternatively -- at least for now -- you can always add it to your SHOWS slot.

FWIW, this becomes a much larger problem if we start thinking about internationalization too...

Not too sure it actually would because all the shows names are pronounced the English way, at least in Germany. It's "Haway feif oh" ;)

@ausweider , I don't mean for this particular show.  I mean for shows with titles in other languages that might have a similar problem.  Granted, this is already a problem for English speakers that watch foreign shows/films.

Alternatively -- at least for now -- you can always add it to your SHOWS slot.

I already have them in my Shows slot; For example I have: Brooklyn Nine-Nine

I have been struggling with a similar issue for PVR channel names. In the UK the channel names are often abbreviated by the provider. 'Horror chnl' rather than 'horror channel'. I'm not ever going to say 'alexa, as cody to watch horror chnl'.
What I implemented was a list of 'aliases' that act as alternative names for certain channels. The issue is that this is a hard coded list. One solution I was toying with was to create a user friendly webapp to manage this list and have the kodi-alexa skill grab this list. The problem is this complicating things. I love the idea of a simple lambda function.

Might be solved by PR #54.  Will verify.

PR #54 solves the problem for at least Hawaii Five-O for me.
@nawo69, can you test with PR #54 and confirm?

@freemans13, I'd also really be interested to know if it removes the need for the channel aliases, if you don't mind giving it a go.

@jingai Yip that is working fine for me with Brooklyn Nine Nine and Hawaii Five-O great work guys

Just awaiting input from @freemans13 before closing.

Thankfully I've been using fuzzywuzzy too :)
I've not checked the specific Brooklyn Nine Nine and Hawaii Five-O scenarios (I think they could work actually). The more challenging part for me is 'BBC Northen Ireland'->'BBC NI', 'BBC 2'->'BBC Two Eng', 'Horror Channel plus 1'->'Horro ch+1'.
I'll take a closer look.

@freemans13, it'd be useful to see what we can solve without aliases.  If you could test calling for channels in your area without aliases and post back here with the results, I'd appreciate that.

Closing this since the specific problem referenced in this Issue has been resolved.  We can continue discussion about the PVR stuff on PR #47.

Finally! I've run some tests that don't use aliasing.
I can report Brooklyn Nine-Nine and Hawaii Five-O work well without aliasing (using fuzzywuzzy matching only).
Where fuzzywuzzy can't help is where the PVR channel name coming from Kodi is abbreviated.
Examples:
BBC Two Eng
(should be BBC Two England)
horror ch+1
(Horror Channel plus 1)
True Ent
(True Entertainment)
BBC One S West
(BBC One South West)

My fuzzywuzzy logic is already on the branch BTW.
What i'd like is a steer on

the 'media type'
the utterances


how to predict the datasets, I have trained cifar-10. Need your help!!!

I have successfully trained the cifar-10, then how to predict? I have no idea, Thx for your help!!!

load your model and use mode.predict(X=test)

I am newer for mxnet or say DL. so can you explain more details, where I can find the model and what can I do to run the code? write a new script? thx!!

see here https://github.com/dmlc/mxnet/blob/master/example/image-classification/train_model.py#L40 to save model when training and here https://github.com/dmlc/mxnet/blob/master/example/image-classification/train_model.py#L29 to load model and then you can do predict with model.predict(X=test) where test is the dataiter

thx so much! another question is what's .ipynb file for?

I trained cifar-10 successfully like this 'python train_cifar10.py --batch-size 128 --lr 0.1 --lr-factor .94 --num-epoch '  so I think I have saved model and loaded model. and next how to predict with model.predict(X=test)?

thx for your help, now i can use 'cifar10.ipynb' step by step and predict successfully. and the next is I need to find out the predict result, as i know in mxnet the format of images is '.rec', so what's the output format, and what I need to do to convert to one format such as '.jpg' or '.bmp', that represent the result we can see directly? waiting for your help, THx.

Closing for now. Please feel free to re-open if needed.


Controller populated and functional

What
Controller now populated and functional
Further info can be found on the README.md file
How to review

Check that everything is functional and as expected
Ensure that project criteria has been met, see trello tickets and Miro board for details
Make sure there are no security issues in the project
Make sure that there are enough tests and correct coverage

Who can review
Anyone except me

Also missing the following from Makefile:
BUILD_TIME=$(shell date +%s)
GIT_COMMIT=$(shell git rev-parse HEAD)
VERSION ?= $(shell git tag --points-at HEAD | grep ^v | head -n 1)

Also ci scripts and yaml files for unit and build are incomplete and hence concourse-ci throwing error
We should now be using the latest go version 1.13.7, this should be reflected in ci and go.mod file, also dp-api-clients.go is not on the latest version, might as well bump it to latest.
If you need help with any of this, just ask Im happy to give you a hand


json_pack appears to fail when used with multiple nested objects

I have encountered a segmentation fault that appears to be a bug with json_pack/json_pack_ex.
My original use case/test (gives a segmentation fault):
json_t* pNestedTest = json_pack_ex(&error, 0, "{ s:i, s:{s:i}, s:{s:i}, s:{s:f} }",     "outerObjectId", 1,     "firstNested",         "firstData", 1,     "secondNested",         "secondData", 2,     "thirdNested",         "thirdData", 0.333);
With further testing, I noticed this also fails (still two nested objects, both are now empty):
json_t* pNestedTest = json_pack_ex(&error, 0, "{ s:i, s:{}, s:{} }",             "outerObjectId", 1,             "firstNested"             "secondNested")
Yet this succeeds (one nested object):
json_t* pNestedTest = json_pack_ex(&error, 0, "{ s:i, s:{} }",             "outerObjectId", 1,             "firstNested"

My bad - I was using a custom routine for printing to console and just realized that my issue stemmed from overflow of the output buffer in cases where my JSON object had grown too large.  Please disregard.


refactor: remove alert dependency

Hey @chrisspiegl,
The "alert" package was deprecated long time ago.
I've made a small update which removes the "alert" package dependency since it was not used. Could you please bump the version and push this change to npm? This way, your package won't be a dependent of the "alert" package anymore.
Cheers,
Patrick

@gxrsti Sorry this took so long. I don't really use these alfred workflows anymore. Luckily alert wasn't even used in the package. I will look into getting these workflows updated / deprecated as applicable in the future.


Recognize unicode variants of special symbols ::, ->, =>

I agree that copy-paste is to be avoided. On the other hand, moving string comparison into patterns will leverage ghc's pattern compiler to produce a state machine that will determine with a singe test whether the given token is double colon, for example. While approach with elem will make as many comparisons as there're tokens.
Perhaps the best way to unify these would be to perform some lexical analysis before looking for tag constructs, e.g. data. Then tokenized input will be a list of some intermediate tokens of type
data LexicalToken =
    Name Text
    | TokArrow -- handles both "->" and unicode version
    | TokDoubleColon -- ditto
    ...

With input tokenized in such a way, tests for constructs like function signature will also be able to determine whether token is a double colon with a single operation. I think alex will be a good way to do such lexical analysis.
Regarding your comment about duplication in stripOptContext function,
stripOptContext :: [Token] -> [Token]
stripOptContext (stripBalancedParens -> (Pos _ (Token _ implies) : xs))
  | implies == "=>" || implies == "⇒" = xs
stripOptContext (stripSingleClassContext -> Pos _ (Token _ implies) : xs)
  | implies == "=>" || implies == "⇒" = xs
stripOptContext xs = xs

I'm not sure on how to unify duplicate cases because they use different view patterns. So I only changed test for implies tokens to use elem.
NB I updated the commit instead of creating a new one.

Yeah, elem is probably less efficient.  I assumed for a two element list it's not a big deal, but we are going for speed here.  If you want to keep it in the pattern match that's fine too, but in that case maybe you could factor 'reverse $ mkTag pos prefix name funcTag : tags' into a local definition.  Or maybe that would obscure more than clarify... it's your call.
I missed the view difference in stripOptContext, sorry!  As above 'elem' is probably slightly slower... but a two element list really is quite fast.  Up to you though.
So if you still like the pattern matches, then you can switch back and I'll merge that.  Otherwise, if you like it as it is now, let me know and I'll merge as-is.
Also I agree something like alex could be the next step up, but it seems to add a lot of complexity, so maybe we can keep getting along without it.  In theory you'd want t reuse ghc's tokenizer but I'll bet that's super complicated.

I think elem is good enough for now, let's go with it.
GHC lexer looks like a good idea, but it doesn't work with Text and uses GHC's FastStrings with vanilla Strings in its tokens. So it's not clear whether we cannot make some simple tokenizer, similar to one already present in fast-tags, that will beat special-purpose ones.
There's also haskell-src-exts lexer that doesn't work with Text either. I'm going to try some alternatives later.

Ok sounds good to me, merging.  Thanks!


displayName and forwardRef not handled as described in React docs

I think that displayName might not handled correctly.
I am not seeing the display names of styled components in the react profiler.

I think this issue is related to how the display name is set here:
https://github.com/styled-components/styled-components/blob/c098fd7deb610717fa0fbc33d6ec2f9cf0e69edc/packages/styled-components/src/models/StyledComponent.js#L280-L288
As per the React docs the displayName should be set on the function passed to React.forwardRef and not on its return value. See also this issue
System:

OS: macOS 10.14.4
CPU: (12) x64 Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
Memory: 416.54 MB / 32.00 GB
Shell: 2.7.1 - /usr/local/bin/fish

Binaries:

Node: 10.15.0 - /usr/local/bin/node
Yarn: 1.13.0 - /usr/local/bin/yarn
npm: 6.5.0 - /usr/local/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman

npmPackages:

babel-plugin-styled-components: ^1.10.0 => 1.10.0
styled-components: ^4.2.0 => 4.2.0
react: 16.8.3
react-native: 0.59.2

Send a PR, thanks!
On Wed, Apr 17, 2019 at 6:27 PM Tobias Lohse<EMAIL_ADDRESS>wrote:

I think that displayName might not handled correctly.
I am not seeing the display names of styled components in the react
profiler.
[image: Screen Shot 2019-04-17 at 17 05 49]
https://user-images.githubusercontent.com/1285032/56324788-84c25500-6135-11e9-9ee5-1608e40905b8.png
I think this issue is related to how the display name is set here:
https://github.com/styled-components/styled-components/blob/c098fd7deb610717fa0fbc33d6ec2f9cf0e69edc/packages/styled-components/src/models/StyledComponent.js#L280-L288
As per the React docs
https://reactjs.org/docs/forwarding-refs.html#displaying-a-custom-name-in-devtools
the displayName should be set on the function passed to React.forwardRef
and not on its return value. See also this issue
https://github.com/facebook/react/issues/13703
System:

OS: macOS 10.14.4
CPU: (12) x64 Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
Memory: 416.54 MB / 32.00 GB
Shell: 2.7.1 - /usr/local/bin/fish

Binaries:

Node: 10.15.0 - /usr/local/bin/node
Yarn: 1.13.0 - /usr/local/bin/yarn
npm: 6.5.0 - /usr/local/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman

npmPackages:

babel-plugin-styled-components: ^1.10.0 => 1.10.0
styled-components: ^4.2.0 => 4.2.0
react: 16.8.3
react-native: 0.59.2

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/styled-components/styled-components/issues/2507, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAELFVSBMEEEO6C5ATLJG23PQ6P3HANCNFSM4HGYJSKQ
.


Github action to run Supabase migration test script

A migration test script whose purpose is to move test data from Google Tables to Supabase should be run whenever changes to a migration script are made. The work for the test script is captured by https://github.com/ParkingReformNetwork/reform-map/issues/306

We're going with Directus instead.


Replace CLA by DCO in review guidelines

What this PR does / why we need it:
CLA is replaced by DCO, see https://www.helm.sh/blog/helm-dco/index.html
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Special notes for your reviewer:

i have no objections on that
/lgtm

/lgtm

/ok-to-test