Flexible plaintext mod

Making plaintext modulus customizable.

This seems to have broken cargo bench, though I'm not familiar enough with Rust to immediately grasp why:
~/rust/Cupcake main
❯ git rev-parse HEAD
c8ee75a9127fa907dc6d0d8186c28b3a0d6a4d00

~/rust/Cupcake main
❯ cargo bench
   Compiling Cupcake v0.1.1 (/home/user/rust/Cupcake)
error[E0282]: type annotations needed
   --> benches/example.rs:185:20
    |
185 |         let _ = fv.decrypt(&ct, &sk);
    |             -      ^^^^^^^ cannot infer type for type parameter `PT` declared on the trait `SKEncryption`
    |             |
    |             consider giving this pattern a type

error: aborting due to previous error

For more information about this error, try `rustc --explain E0282`.
error: could not compile `Cupcake`

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: build failed

While if I try the previous commit:
~/rust/Cupcake main
❯ git checkout HEAD^
HEAD is now at 381b99e Adding serialization capability.  (#3)

~/rust/Cupcake @381b99ee
❯ git rev-parse HEAD
381b99ee09fdb7192664224d85d32ac494bf521a

~/rust/Cupcake @381b99ee
❯ cargo bench
   Compiling Cupcake v0.1.1 (/home/user/rust/Cupcake)
    Finished bench [optimized] target(s) in 1.36s
     Running unittests (target/release/deps/cupcake-ea89701d0927524e)

running 28 tests
test fv_scalar_tests::test_add_plain_scalar ... ignored
test fv_scalar_tests::test_add_scalar ... ignored
... (all tests pass)


fix: soon to be broken link

Hello @dawsers,
I recently changed my Github handle and realized I must keep existing references up to date, in order to prevent breaking your setup or, worse, exposing you to a security risk as a result of someone taking over my old handle and creating a repo with the same name.
Now, sqlite.lua link is updated.

kkharji Thank you!


@commitlint/config-conventional does not validate subject correctly

Expected Behavior
According to https://conventionalcommits.org/#examples
feat: allow provided config object to extend other configs should be valid when using @commitlint/config-conventional.
Current Behavior
subject must not be sentence-case,start-case,pascal-case,upper-case
Affected packages

[ ] cli
[x] core
[ ] prompt
[ ] config-angular

Possible Solution

Steps to Reproduce (for bugs)
const {lint, load} = require("@commitlint/core");
const config = require("@commitlint/config-conventional");

async function test(message) {
    const {rules} = await load(config);
    const {valid, errors, warnings} = await lint(message, rules);
    errors.forEach(({message}) => {
        console.log(message)
    });
    process.exit(valid ? 0 : 1);
}

test("feat: allow provided config object to extend other configs");

Context
Usage in a  GitHub bot.
Your Environment
    "@commitlint/config-conventional": "^7.0.1",
    "@commitlint/core": "^7.0.0",

It appears to be fixed in this commit https://github.com/marionebl/commitlint/commit/1f46b9fecd8ba76bdbdaf75775b97ff6f532cbae but 7.0.1 hasn't made it on to npm yet.

Turns out the project I was working on had a different version defined in the yarn lockfile. Whoops...


When using docker http request, adding the parameter "only_text": True will cause error: crawl4ai.content_scrapping_strategy.WebScrapingStrategy.scrap() got multiple values for keyword argument 'only_text'"

First of all, thank you very much for releasing the latest version 0.3.75. The docker image can finally be used normally. But when I set only_text to True, an error will appear: crawl4ai.content_scrapping_strategy.WebScrapingStrategy.scrap() got multiple values for keyword argument 'only_text'". I don't know which one adds multiple values to only_text. I hope it can be fixed.

Maybe I know the reason for the problem.
The error occurs in  "crawl4ai.async_webcrawler.AsyncWebCrawler.aprocess_html"
only_text is set in **kwargs, but aprocess_html also sets it once, which triggers the problem

@chenm1xuexi Thanks for using the library. This is already fixed in the pull request and merged to the main branch. Please try it again. Thank you.


Upgrade to node 10.14.2

Pull Request Test Coverage Report for Build 2773

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

Totals

Change from base Build 2770:
0.0%

Covered Lines:

Relevant Lines:
0

💛  - Coveralls


matrix_row_t unknown type name in encoder.c

Greetings,
When I try to compile the Cheapinov2 in QMK I get the error below:
Compiling: drivers/encoder/encoder_quadrature.c                                                    In file included from drivers/encoder/encoder_quadrature.c:6: keyboards/cannonfodder/encoder.h:5:25: error: unknown type name 'matrix_row_t' 5 | void fix_encoder_action(matrix_row_t current_matrix[]);
'matrix_row_t' is used encoder.c, ghosting.c, ghosting.h and matrix.c without throwing an error.
Do you have any idea why this is happening or how to correct it?

Hey. From the error it seems like you did some modding? It should compile if you follow the firmware guide step by step?

Greetings,
Tried to compile the stock code from https://github.com/tompi/vial-qmk/tree/cheapinov2 and I get the error below for the default keyboard.
Compiling: keyboards/cheapino/encoder.c                                                            keyboards/cheapino/encoder.c: In function 'turned': keyboards/cheapino/encoder.c:28:5: error: implicit declaration of function 'encoder_exec_mapping' [-Werror=implicit-function-declaration]    28 |     encoder_exec_mapping(0, clockwise);
When I try Vial keyboard I get the errors below:
Compiling: quantum/keymap_introspection.c                                                          In file included from quantum/quantum.h:210,                  from ./.build/obj_cheapino_vial/src/default_keyboard.h:27,                  from ./keyboards/cheapino/keymaps/vial/keymap.c:1,                  from quantum/keymap_introspection.c:5: quantum/encoder.h:115:13: error: excess elements in array initializer [-Werror]   115 |             { (cw), (ccw) }       |             ^ ./keyboards/cheapino/keymaps/vial/keymap.c:17:15: note: in expansion of macro 'ENCODER_CCW_CW'    17 |     [0] =   { ENCODER_CCW_CW(KC_MS_WH_UP, KC_MS_WH_DOWN)},       |               ^~~~~~~~~~~~~~ quantum/encoder.h:115:13: note: (near initialization for 'encoder_map[0]')   115 |             { (cw), (ccw) }       |             ^ ./keyboards/cheapino/keymaps/vial/keymap.c:17:15: note: in expansion of macro 'ENCODER_CCW_CW'    17 |     [0] =   { ENCODER_CCW_CW(KC_MS_WH_UP, KC_MS_WH_DOWN)},       |               ^~~~~~~~~~~~~~ quantum/encoder.h:115:13: error: excess elements in array initializer [-Werror]   115 |             { (cw), (ccw) }       |             ^ ./keyboards/cheapino/keymaps/vial/keymap.c:18:15: note: in expansion of macro 'ENCODER_CCW_CW'    18 |     [1] =   { ENCODER_CCW_CW(RGB_HUD, RGB_HUI)  },       |               ^~~~~~~~~~~~~~ quantum/encoder.h:115:13: note: (near initialization for 'encoder_map[1]')   115 |             { (cw), (ccw) }       |             ^ ./keyboards/cheapino/keymaps/vial/keymap.c:18:15: note: in expansion of macro 'ENCODER_CCW_CW'    18 |     [1] =   { ENCODER_CCW_CW(RGB_HUD, RGB_HUI)  },       |               ^~~~~~~~~~~~~~ quantum/encoder.h:115:13: error: excess elements in array initializer [-Werror]   115 |             { (cw), (ccw) }       |             ^ ./keyboards/cheapino/keymaps/vial/keymap.c:19:15: note: in expansion of macro 'ENCODER_CCW_CW'    19 |     [2] =   { ENCODER_CCW_CW(RGB_VAD, RGB_VAI)  },       |               ^~~~~~~~~~~~~~ quantum/encoder.h:115:13: note: (near initialization for 'encoder_map[2]')   115 |             { (cw), (ccw) }       |             ^ ./keyboards/cheapino/keymaps/vial/keymap.c:19:15: note: in expansion of macro 'ENCODER_CCW_CW'    19 |     [2] =   { ENCODER_CCW_CW(RGB_VAD, RGB_VAI)  },       |               ^~~~~~~~~~~~~~ quantum/encoder.h:115:13: error: excess elements in array initializer [-Werror]   115 |             { (cw), (ccw) }       |             ^ ./keyboards/cheapino/keymaps/vial/keymap.c:20:15: note: in expansion of macro 'ENCODER_CCW_CW'    20 |     [3] =   { ENCODER_CCW_CW(RGB_RMOD, RGB_MOD) },       |               ^~~~~~~~~~~~~~ quantum/encoder.h:115:13: note: (near initialization for 'encoder_map[3]')   115 |             { (cw), (ccw) }       |             ^ ./keyboards/cheapino/keymaps/vial/keymap.c:20:15: note: in expansion of macro 'ENCODER_CCW_CW'    20 |     [3] =   { ENCODER_CCW_CW(RGB_RMOD, RGB_MOD) },       |               ^~~~~~~~~~~~~~ quantum/encoder.h:115:13: error: excess elements in array initializer [-Werror]   115 |             { (cw), (ccw) }       |             ^ ./keyboards/cheapino/keymaps/vial/keymap.c:21:15: note: in expansion of macro 'ENCODER_CCW_CW'    21 |     [4] =   { ENCODER_CCW_CW(KC_NO,KC_NO)  },       |               ^~~~~~~~~~~~~~ quantum/encoder.h:115:13: note: (near initialization for 'encoder_map[4]')   115 |             { (cw), (ccw) }       |             ^ ./keyboards/cheapino/keymaps/vial/keymap.c:21:15: note: in expansion of macro 'ENCODER_CCW_CW'    21 |     [4] =   { ENCODER_CCW_CW(KC_NO,KC_NO)  },       |               ^~~~~~~~~~~~~~ quantum/encoder.h:115:13: error: excess elements in array initializer [-Werror]   115 |             { (cw), (ccw) }       |             ^ ./keyboards/cheapino/keymaps/vial/keymap.c:22:15: note: in expansion of macro 'ENCODER_CCW_CW'    22 |     [5] =   { ENCODER_CCW_CW(KC_NO,KC_NO)  },       |               ^~~~~~~~~~~~~~ quantum/encoder.h:115:13: note: (near initialization for 'encoder_map[5]')   115 |             { (cw), (ccw) }       |             ^ ./keyboards/cheapino/keymaps/vial/keymap.c:22:15: note: in expansion of macro 'ENCODER_CCW_CW'    22 |     [5] =   { ENCODER_CCW_CW(KC_NO,KC_NO)  },       |               ^~~~~~~~~~~~~~ quantum/encoder.h:115:13: error: excess elements in array initializer [-Werror]   115 |             { (cw), (ccw) }       |             ^ ./keyboards/cheapino/keymaps/vial/keymap.c:23:15: note: in expansion of macro 'ENCODER_CCW_CW'    23 |     [6] =   { ENCODER_CCW_CW(KC_NO,KC_NO)  },       |               ^~~~~~~~~~~~~~ quantum/encoder.h:115:13: note: (near initialization for 'encoder_map[6]')   115 |             { (cw), (ccw) }       |             ^ ./keyboards/cheapino/keymaps/vial/keymap.c:23:15: note: in expansion of macro 'ENCODER_CCW_CW'    23 |     [6] =   { ENCODER_CCW_CW(KC_NO,KC_NO)  },       |               ^~~~~~~~~~~~~~ quantum/encoder.h:115:13: error: excess elements in array initializer [-Werror]   115 |             { (cw), (ccw) }       |             ^ ./keyboards/cheapino/keymaps/vial/keymap.c:24:15: note: in expansion of macro 'ENCODER_CCW_CW'    24 |     [7] =   { ENCODER_CCW_CW(KC_NO,KC_NO)  }       |               ^~~~~~~~~~~~~~ quantum/encoder.h:115:13: note: (near initialization for 'encoder_map[7]')   115 |             { (cw), (ccw) }       |             ^ ./keyboards/cheapino/keymaps/vial/keymap.c:24:15: note: in expansion of macro 'ENCODER_CCW_CW'    24 |     [7] =   { ENCODER_CCW_CW(KC_NO,KC_NO)  }       |               ^~~~~~~~~~~~~~ quantum/keymap_introspection.c: In function 'encodermap_layer_count_raw': quantum/keymap_introspection.c:50:70: error: division by zero [-Werror=div-by-zero]    50 | #    define NUM_ENCODERMAP_LAYERS_RAW ((uint8_t)(sizeof(encoder_map) / ((NUM_ENCODERS) * (NUM_DIRECTIONS) * sizeof(uint16_t))))       |                                                                      ^ quantum/keymap_introspection.c:53:12: note: in expansion of macro 'NUM_ENCODERMAP_LAYERS_RAW'    53 |     return NUM_ENCODERMAP_LAYERS_RAW;       |            ^~~~~~~~~~~~~~~~~~~~~~~~~ quantum/keymap_introspection.c: At top level: quantum/keymap_introspection.c:50:70: error: division by zero [-Werror=div-by-zero]    50 | #    define NUM_ENCODERMAP_LAYERS_RAW ((uint8_t)(sizeof(encoder_map) / ((NUM_ENCODERS) * (NUM_DIRECTIONS) * sizeof(uint16_t))))       |                                                                      ^ quantum/keymap_introspection.c:60:41: note: in expansion of macro 'NUM_ENCODERMAP_LAYERS_RAW'    60 | _Static_assert(NUM_KEYMAP_LAYERS_RAW == NUM_ENCODERMAP_LAYERS_RAW, "Number of encoder_map layers doesn't match the number of keymap layers");       |                                         ^~~~~~~~~~~~~~~~~~~~~~~~~ quantum/keymap_introspection.c:60:38: error: expression in static assertion is not constant    60 | _Static_assert(NUM_KEYMAP_LAYERS_RAW == NUM_ENCODERMAP_LAYERS_RAW, "Number of encoder_map layers doesn't match the number of keymap layers");       |                                      ^ quantum/keymap_introspection.c: In function 'keycode_at_encodermap_location_raw': quantum/keymap_introspection.c:50:70: error: division by zero [-Werror=div-by-zero]    50 | #    define NUM_ENCODERMAP_LAYERS_RAW ((uint8_t)(sizeof(encoder_map) / ((NUM_ENCODERS) * (NUM_DIRECTIONS) * sizeof(uint16_t))))       |                                                                      ^ quantum/keymap_introspection.c:63:21: note: in expansion of macro 'NUM_ENCODERMAP_LAYERS_RAW'    63 |     if (layer_num < NUM_ENCODERMAP_LAYERS_RAW && encoder_idx < NUM_ENCODERS) {
When I try tompi keyboard I get the below error for each layer:
Compiling: quantum/keymap_introspection.c                                                          In file included from quantum/keymap_introspection.c:5: ./.build/obj_cheapino_tompi/src/keymap.c:13:380: error: macro "LAYOUT_split_3x5_3" requires 37 arguments, but only 36 given    13 | T(KC_E), LALT_T(KC_I), LGUI_T(KC_O), KC_Z, KC_X, KC_C, KC_D, LT(5,KC_V), LT(1,KC_K), KC_H, KC_COMM, KC_DOT, KC_SLSH, LT(6,KC_ESC), LT(3,KC_SPC), LT(5,KC_TAB), LT(1,KC_DEL), LT(2,KC_BSPC), LT(4,KC_ENT)),
So I started with a blank keyboard and started importing the matrix then ghost features.  They work.  Modified the RGB for capslock.
The only thing left is encoder.  I cant get it to work because it uses the scan  routing for the common leg vice ground.  Trying to avoid cutting the trace for row_4 to pin C and grounding pin C to to follow QMK encoder configuration.
All of this came about because I wanted to have the LED change color for capslock and a different color for a seperate default layer :)
As side note, the RGB LED on the RP2040-Zero I'm using have the red and green diodes swapped.  Don't know if this is standard for them or I got  a nonstandard module.  Took me for ever to figure it out trying to set the color using HSV.  The colors were always wrong.  When I switched to setting it by RGB I finally figured it out.
Love the keyboard by the way.

The changes in quantom/encoder.c and .h files.

P.S. In regular qmk I just called a user function, but in Vial, this was no good and you could not control encoder from vial, hence the hack...

Looks like QMK did a major overhaul of the encoder function. encoder_exec_mapping is no long in quantum/encoder.c.  It is now 297 line vice 179.  Look like I'll have to figure out what the new equivalent function is.

Hey, just tested myself, and it compiled fine with the existing branch, right? Are you trying to get it up to latest qmk version? (cause that might be difficult with vial i think...)
This is what I dit:
git clone git@github.com:tompi/vial-qmk.git qmk_test
cd qmk_test
make git-submodules
qmk compile -kb cheapino -km vial

Thomas,
Yes, I'm trying with the latest QMK.  I did the RGB and encoder from scratch.  I works with the standard QMK build.
Got issues with the vial build to work.  Been a bit busy with so I haven't had time to work on it.
When I get a chance I'll try your instructions above.
Thanks for a great design.  I just have to get my muscle memory to adjust to the new setup.
Have great  day,
Randy

I assume problem was trying to merge latest qmk into current vial(which wont work, vial is locked to older qmk)


minigames fix

please check out the code in the minigames.py file, all dank minigames are embed based.
replace message.content and use embed.to_dict()["description"], add for embed in message.embeds to fix.
also check your requirements again, can't run the py version as they're incompatible.

Fixed


Avoid overwriting NVMe root volumes on current-gen AWS instances (addresses #2252)

c5, i3.metal, c5d, m5, and m5d instances all have their EBS volumes
show up as NVMe devices. Previously toil assumed that all NVMe devices
were ephemeral, so it formed a RAID device from them. On these
instance types, though, the root volume would be reformatted,
corrupted, and then remounted as readonly, causing failures.

http://jenkins.cgcloud.info/job/toil-pull-requests/4130/
http://jenkins.cgcloud.info/job/toil-pull-request-integration-tests/2420/

Jenkins, test this please.


Extend beyond mpris?

So, I don't know if this could even be in your interests..
Still I found your service is like the only one on the whole internet that "takes a standard agnostic format" and converts it to DRPC (rather than just directly hooking into programs and sending it directly to it).
And I was wondering if your fine work couldn't be made a bit more general-purpose (or something at least enough for games I guess).
Unfortunately there isn't really an xdg specification specific to this, still d-bus is extensible enough that I'd hope it shouldn't be too hard to design a simple custom api.

I'm not really sure what you're asking for. This tool was made specifically for the mpris interface and uses Discord's RPC protocol to provide the necessary information to the Discord client. The protocol is documented and has a reference implementation in C, as well as a couple implementations in different languages. At the time I worked on this, I didn't find an existing library to my liking (especially one supporting asyncio), so I reused my own implementation I made for https://github.com/Snazzah/SublimeDiscordRP. In the meantime, more libraries have been written and I have collected references to those over time that I will reevaluate when I reserve time to work on this again. I remember at least one or two seeming promising and allowing me to drop my custom and occasionally flaky implementation.
If you're looking for a generic dbus proxy interface to access Discord's rich presence protocol, I suggest using or writing a different application, as that would be entirely out of scope.

For a generic interface, you first need some specification (because there is none for d-bus on the line of mpris, that I know).
But I see you don't care much about the idea, so thanks anyway.


Add installation procedure

I think this is a simple and very nice project.
Thank you for making this project available to the public. 👍
If you don't mind, could you let me add the installation instructions to the documentation?
If you merge this pull request, the installation instructions will be added to the README.md.
There is no change in the code.

Thanks for your nice pull request! 👍

I didn't originally intend to make any changes to the code in this PR.
Since I was working without changing the branch, the code changes were unintentionally included.
The code changes were included in the following commits:
2d069881cbd440eba7365374126459b3081cef04
3a591824cc89f4e71cb928ca93573c91e18fd815
Can you check to make sure it's OK?

I was going to make separate Pull Requests for these commits.
If you think you should revert this PR, please do so.
If you do, I create Pull Requests to update the documentation and to change the code.
Let me know if you have any questions about commits.
I am aware that these code changes is backward compatible.


HCP Packer Support

I'm currently making use of this plugin to generate Raspberry Pi images.
(which it does very well, by the way)
I'd like to be able to hook into HCP Packer, to keep track of image versions (which are stable, which I'm still testing, etc.)
My wise colleagues over in the HCP Packer team advise me this is usually relatively straightforward, and requires updating the Artifact metadata
https://www.packer.io/docs/plugins/hcp-support
I'm not entirely sure what such a metadata would look like in the context of this plugin, as (currently, as far as I can see) it just creates local disk images (and optionally flashes them), with the user running Packer responsible for copying those images somewhere.
But if you have thoughts as to how it could work, and would be happy accepting a PR, I'm up for experimenting with it.

Hi @lucymhdavies, I'm not very familiar with HCP, so I can provide guidance on how it would work.. I am happy to accept PR related to it, as from the link you sent, it seems useful!

Thanks. No ideas when I'd be able to get around to doing it, but I've had some initial thoughts on what it could look like. I'll experiment and let you know how it turns out.
Looking at the Image type...
    // ImageID is a unique reference identifier stored on the HCP Packer registry
    // that can be used to get back the built artifact of a builder or post-processor.
    ImageID string

As this plugin outputs directly to files, then just the filename would make sense here. It's not really a "unique" reference, but it's the best we've got for how this plugin works.
    // ProviderName represents the name of the top level cloud or service where the built artifact resides.
    // For example "aws, azure, docker, gcp, and vsphere".
    ProviderName string

Here, just arm-image or something like it makes sense to me.
    // ProviderRegion represents the location of the built artifact.
    // For cloud providers region usually maps to a cloud region or zone, but for things like the file builder,
    // S3 bucket or vsphere cluster region can represent a path on the upstream datastore, or cluster.
    ProviderRegion string

As the plugin isn't responsible for uploading the file anywhere in particular, I think we may be able to leave this blank. This plugin doesn't really have a concept of "region".
    // Labels represents additional details about an image that a builder or post-processor may with to provide for a given build.
    // Any additional metadata will be made available as build labels within a HCP Packer registry iteration.
    Labels map[string]string

Potentially a checksum of the image would be useful to add here. Unlike with plugins which build things like Amazon Machine Images, we don't really have a well defined concept of a unique ID for the created image.
    // SourceImageID is the cloud image id of the image that was used as the
    // source for this image. If set, the HCP Packer registry will be able
    // link the parent and child images for ancestry visualizations and
    // dependency tracking.
    SourceImageID string

We do have a well defined concept for this one.
iso_url can be used for this.
For comparison, here's what we see for an image I've built in AWS:

The "Build Labels" are metadata I've added myself, and the eu-west-* and ami-* metadata corresponds to Image ID and Provider region.


skrive: init at 0.10.0

Description of changes
This adds Skrive, a medicine dosage logger for the terminal
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

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

Result of nixpkgs-review pr 285894 run on x86_64-linux 1

1 package built:

skrive

@dotlambda could you approve this PR? It's blocking the merge


FIX: Don't auto-generate indexes for Text field types (fixes #7900)

https://github.com/silverstripe/silverstripe-framework/issues/7900

Ping @dhensby

merge on green


rbd: remove features_nautilus.go

Checklist

[ ] Added tests for features and functional changes
[ ] Public functions and types are documented
[ ] Standard formatting is applied to Go code
[ ] Is this a new API? Added a new file that begins with //go:build ceph_preview
[ ] Ran make api-update to record new APIs

New or infrequent contributors may want to review the go-ceph Developer's Guide including the section on how we track API Status and the API Stability Plan.
The go-ceph project uses mergify. View the mergify command guide for information on how to interact with mergify. Add a comment with @Mergifyio rebase to rebase your PR when github indicates that the PR is out of date with the base branch.

I'm setting the 'no-api' label as this only moves code, converging the features.go and features_nautilus.go as there are no pre nautilus build tags any more.

I'm going to wait one more day for the ceph main branch to have a build with the mgr fixes. If it's not done by then I think I'll just merge this manually w/o waiting for main to be fixed.


Implement quorom management service and its shell commands

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/4672/
Test FAILed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/4678/
Test PASSed.

@LuQQiu PTAL. Thanks!

Thanks for adding the quorum management! Two high level comments are left:
(1) Could we put getQuorumInfo and removeQuorumServer in  MetaMaster instead of JournalMaster?
The names of embedded journal and UFS journal is more about the Journal (which determines the ways of storing journal logs). Embedded journal comes with Copycat quorum which helps us to do the internal leader election. For the leader election part, we all use internal leader election to refer to it in our official docs instead of embedded journal. Besides that, UFS journal has nothing to do with leader election or quorum. MetaMaster on the other hand contains methods about masters. @gpang What's your opinion about where we put the quorum methods in?
(2) do we want to use the word quorum externally?
It makes sense if we only want experience users to use the fsadmin quorum to get internal leader election information or remove a master node from the internal leader election. For normal users, quorum may make them confuse. I will prefer fsadmin leaderElection or something easier for users to understand. @calvinjia Any ideas of what term should we expose to users?

@LuQQiu
This PR hasn't introduced any distinction between embedded journal and UFS. Distinction is between MASTER and JOB_MASTER. So I'm not sure why you mentioned that.
MetaMaster only lives in alluxio master process. Because of that it can't be used to manage job_master journal. This is the reason I have a dedicated JournalMaster service that is served by both alluxio and job_master processes.
Existing checkpointcommand lives in MetaMaster and can't work with job_master journal because of this. Please see https://github.com/Alluxio/alluxio/issues/9538. Once this PR is in, we can move checkpoint command to new JournalMaster for overcoming this limitation.
I agree quorum command might be confusing when it's detached from the context of journals. Once we're done with this and the above issue, we can unify both commands under high-level journal command, under which both checkpoint and quorum would make better sense. Please see https://github.com/Alluxio/alluxio/issues/9542.

Got it, if the JournalMaster can work with both master and job_master, include more other journal related methods (like checkpoint), then it makes sense to have this separate master.
For CLI, I agree to uniform the different journal related commands and improve user experience.
Thanks!

@calvinjia PTAL. Thanks!

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/4688/
Test FAILed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/4690/
Test PASSed.

@calvinjia domain argument is used by both commands to select the correct JournalMasterClient.

@ggezer Right, but the implementation of both remove calls is unrelated to the domain?

@calvinjia, Correct. But we still need an argument at command level for forwarding the call to appropriate implementation.

An alternative could be to show quorum info for both through the status call?

alluxio-bot, merge this please.


Example:
.config/yazi/ # original input
# press ctrl-w
.config/yazi  # w/o this PR
.config/      # w/ this PR

Can we add it behind a parameter like kill forward --big-word?

Sorry for the late update since I have a busy month. Now this behavior is controlled by the argument.

I'm going to close this because it still needs some work and hasn't seen any activity recently. @XOR-op thanks for the effort!


Clean up filter terms

Textures, cells, and shape each have a mess of filter terms. We need to decide which terms should go in each and make sure we can agree on their definitions.

After gaining some experience entering galls, I'm wondering if we shouldn't revisit having texture and shape as filter items to begin with. They seem so subjective.
With the idea that we could take a templated approach in general to certain descriptive features, could we simply make those fields typable and use our discretion? What I'm imagining is something similar to that image Jeff posted in the deployments section on Slack where it pulled in the colors and locations.

The tension I keep coming back to on this is that a tag/filter term is just not very useful if it's not comprehensive. Like we can warn users that they're not comprehensive, but for me that always means I should just not use it and look through the full host list instead, just in case the one I need to find is not tagged. Allowing custom tags would make that problem worse.

In my vision, it wouldn't be a tag at all. Just descriptive text next to the image.

I see. In that case I'm not sure we'd need to handle this separately from the actual description? Maybe we could have an automatically generated one for most species with an option to rewrite it manually? Or replace with the ID notes manually?

I wrote up a proposed revision of the filter terms. I tried to define each of them in a way that would be as unambiguous as possible. I proposed a fully new filter category but otherwise tried to limit the proliferation of specific terms where the same thing could be expressed by a combination of two existing terms (eg the common erineum cup would be "leaf blister+erineum"). It is of course still very far from being able to adequately capture the range of structures, and lots of other textures and shapes especially probably still merit inclusion.
I guess just have at it in terms of adding, questioning, contesting, etc. I think by now we've each developed a sense of of our own subjective definitions of these forms and at least some of these terms and hopefully that means we can triangulate some common, consistent usage on them.

This looks great, Adam. I'm struggling a little bit on form. I just spent some time going through a handful of galls to see what I would assign to them and for the most part I can line up the other fields using the descriptions. What form would I use for Andricus tubifaciens? Also, can we add club or clubbed to shape?

Under my proposal, A tubifaciens would either not be tagged at all or tagged as "gall," depending on whether we decided to handle that as a default case or an actively applied tag.
My thought was that if you want to propose additional terms you need to write a definition and then see if others agree that your definition is reasonable. But yeah I think club is probably reasonable; it gets used fairly often in the literature.

If no one has any more comments on this at the moment, should we go ahead and implement it and see what issues come up then? I'm sure that it's better than what we have now, no matter how we might improve it in the future.

I vote we proceed with the proposed changes and agree additional terms can be discussed and added as they come up.

One other (minor?) advantage of using the Form category as distinct from Shape is that the generated comments would be more specific. So eg for a scale that doesn't have a picture it would say "A detachable scale" rather than gall, or "an integral leaf curl" etc

It would also permit us to add a button, if we decide such a thing would be valuable in the future, that removed all gall-adjacent-but-not-gall structures from the ID filter results.

This is a decently large amount of work that will require migrating all of the current data to the new fields as well as work across the UI (ID, details display). As for the migration, every gall that uses one of the old fields will have to be migrated. If we can come up with a mapping old->new this can be automated. If the decisions are case-by-case, then someone will have to manually migrate them all. Manual migration is tricky because we have to make sure that no one is editing information for the duration of the manual migration, otherwise data will be lost or made incorrect. There are things that we can do to shorten the window but that will require extra work on my end.
In general, what it sounds like you are really after is an admin controlled and curated tagging system.
Overall this is a major change to the system and I think that we need to plan it out at a level of detail that we mostly have not done so far. This brings up the prioritization of this vs other things. I will raise that separately for discussion.

I was hoping this wouldn't require that much on your end. Eg I'm not sure I understand what part of this would require "migration"? To be clear: here's what I'm proposing:

Add new field (Form)

[ ]  add to Edit Gall admin UI
[ ] add to ID filter selection UI.

I had the impression that when you added Seasons this was not a major change, but if that's not the case maybe that should be a distinct feature request? No data currently exists that could map to this field so no migration of data here.

Add a few terms to existing fields

Remove a few terms from existing fields (afaik terms that have not been applied, though if this is not the case and people have been using them, then we might need to reconsider removing them)

Renaming a few existing terms (eg "2-10" becomes "polythalamous")

There's only one case (scattered and cluster move from Cells to Shape) where data would theoretically move from one field to another but afaik neither of those terms have been applied to any galls so no migration there either (ie no data would be lost if we simply deleted those and made new ones rather than mapping existing data manually or automatically). I was basically planning on going over all of the existing galls after the change no matter what, since many of these terms would have no existing counterpart.
Is that basically what you had understood or does that change your impression of how difficult this would be at all?

If there is little data to migrate then this should not be a big deal. I was under the mistaken impression that we would have to migrate a lot of field data. Renaming is easy. The tricky part is if we need to remap things to new things and delete old things.

@Megachile we need to decide what to do with all of the following data. N.B., Any and all of these may change between now and when any migration is actually run on the database. Once we figure out what we want done with these I will understand the complexity of the migration.

Gall IDs 913 and 970 have shape compact
Gall IDs 273, 461, 964, 975 have shape linear
203, 374, 918, 933, 945, 948, 951, 956, 964, 978, 989, 1118, 1130 have texture waxy
636, 759, 795, 896, 901, 905, 910, 980, 1054, 1064, 1070, 1072, 1083, 1087, 1093, 1101, 1126, 1149 have texture stiff
904, 906, 908, 994, 995, 996, 1069	have texture felt
284, 211, 47, 264, 245, 54, 261, 252 have cells cluster
currently no gall has cells scattered
currently no gall has walls broken
869 has alignment drooping

Also I have converted the spreadsheet to a migration script so any edits you make to that from hence forth will NOT be included. If you want anymore changes please list them here on this issue as a comment.

The requirement that:

Pubescent (always checked in conjunction with “hairy”): the hair covering the gall is short, soft, and dense. May or may not obscure the color and texture of the surface, but not concealing its shape
Woolly (always checked in conjunction with “hairy”): the hair covering the gall is long, soft, and thick, often concealing the surface and structure of the gall completely

Is all new functionality and is non-trivial to deal with and is IMO a mistake to add. I would instead recommend that we have either 2 or 3 options that are discrete and not co-dependent. This may require re-wording or whatever.

The requirement that:
* Pubescent (always checked in conjunction with “hairy”):

I sorry I meant for that to be like, a best-practice on the part of the admin, not a part of the code

But I am definitely open to the idea of generally rethinking the vocabulary for hairs, nightmare that it is to contemplate doing so.

I guess if we're using them that much already, some of those terms might as well stick around. I added definitions for stiff, linear, and drooping. But I think the rest still ought to go unless someone really wants to stand up for them. I'm struggling to define compact, waxy, and felt in ways that could be consistently applied (or in the latter case are consistently distinct from pubescent).
Since we have a list of the galls with felt and cells: cluster, I can go in and add "pubescent" and "form: cluster" manually after the deployment. I assume that deleting doesn't require any manual work, they'll just be gone after the terms are removed?

What we should do is decide how we handle each term that we are going to delete. The options are:

delete, this will simply remove the term from any gall that it is associated with
remap, this requires that we decide up front what we want to map the deleted term to
leave alone

What we can not do is rely on me generating a list from the database since that list will be out of date as soon as I generate it. The only way that will work is if we halt all editing, I generate the list, we decide on changes, apply changes, deploy, and then re-enable editing. I strongly discourage this approach and recommend the above instead.

 All the other changes, additions, renames, new descriptions, will be as in the sheet.
The full migration script can be seen here: https://github.com/jeffdc/gallformers/pull/201/files#diff-55c58b31ae4fcbb5330ea6a95aa2f31f0bb4d3193c97d19f58311d9d07ea5911
Please do not make any more edits to the Google Sheet. Any problems can be addressed here on GitHub via the code review mechanisms.

These are the species that have texture:waxy:
783
978
1647
1663
1675
1679
1682
1687
1696
1716
1727
1958
1979
shape:compact:
1640
1701

Here is what I have come up with

This is what I had in mind, I feel like we had a miscommunication somehow and I got the impression this was exactly what you didn't want to do.

* delete cells:scattered no other action (maybe should be mapped to shape:numerous?)

Yes, though afaik it won't make a difference if there are none with that value?
The only thing this won't work for I think is waxy, since some but not all of the current values in the db are using waxy to mean "glaucous" (yet another reason it should be removed). This is something I can just click through this list and change manually though. Otherwise I think this is good to go.

Yeah sounds like we had/have a miscommunication. I need to map cells:scattered, because I have no way of knowing that it will not have been used by the time the migration is run. RE waxy if any one adds waxy to the data between when you manually went through and when I run the migration (not sure when that will happen) they will be deleted. The larger point that I am trying to make clear is that manual intervention is unreliable unless we stop all other editing of the data.

I understand now, sorry. So are we good to go with this? Anyone have any last-minute objections to the changes?

I am good to go. I will post another message before I run the migration and do the deployment. I still need to work on the UI side.


When I created the coverage, the mock file was missed.

tests/testdemo.test.js

testdemo/mocks /sum.js

testdemo /sum.js

after  jest --coverage  the sum.js is missing,I don't know why.Because if this file is missed, i won't know other functions in this file, whether it's  tested and covered.

Mocks aren't included in coverage information. If you mock a module, that module is not included in coverage because it isn't being executed. This is expected behavior.


You don't need kamel local build at all for just deploying an integration to a K8s cluster.
Looking at the log, it appears that there is something wrong with the registry settings. Make sure you followed the steps here with the correct credentials:
https://camel.apache.org/camel-k/1.9.x/installation/platform/kind.html

@bjethwan If you've just uninstalled Camel K operator, the IntegrationKits used for the build is still there. So long as you keep the IntegrationKits Camel K won't recreate the container image with the hash. As you say, if you recreating the entire kind cluster the IntegrationKits are also gone and you'll need to rebuild the images.

@tadayosi So if I take this solution to production, camel-k will not use the tested kit-* but recreate a new one?
Can't I export and import the integrationkit? Will that skip camel-k from rebuilding in production env?

I think the new kamel promote (https://github.com/apache/camel-k/pull/3325) may be your solution. You can already use installing nightly build or waiting for 1.10 release.


Updated dependencies: psr/http-message 2.x & league/uri 7.x

Support for psr/http-message 2.x
v2.x added return types to the interfaces, should be fine - tests running

Support for league/uri 7.x
This package is only used within \League\OpenAPIValidation\Schema\TypeFormats\StringURI to check if an url is parsable:

try {
    UriString::parse($value);

    return true;
} catch (SyntaxError $error) {
    return false;
}

An Update for respect/stringifier might also be good, and could also be done in a separate PR.

@MaSpeng I've just taken a look at it, but noticed it's not a explicit dependency of this package, but an implicit one via respect/validation.
The latest version of that package is already supported by the current required version:
"respect/validation": "^1.1.3 || ^2.0",
Requests for bumping the stringy version then need to be added here: https://github.com/Respect/Validation
Hope that helps :)

Any chance of progressing this PR at all?
I have a dependency on league/uri ^7.0, but this package is preventing that upgrade unfortunately :-(.

@schodemeiss feel free to use my branch in the meantime by adding the repository to your composer file
"repositories": [
    {
        "type": "vcs",
        "url": "https://github.com/deegital/openapi-psr7-validator"
    }
],

and this version of the package to require/require-dev:
"league/openapi-psr7-validator": "dev-dependency-updates",

I will keep it at least until the PR is merged or it is added to the lib by other commits

@scaytrase sorry for tagging, but I've noticed you did the last approval of an MR for this repo. What's missing to move on with this MR?


[pcre] Update to v8.44

Drop patches (fixed upstream):
fix-option-2.patch
fix-arm64-config-define.patch
fix-arm-config-define.patch
Add patch
pcre-8.44_suppress_cmake_and_compiler_warnings-errors.patch

Describe the pull request

What does your PR fix? Fixes issue #
Update pcre to new upstream version 8.44
https://www.pcre.org/original/changelog.txt
Which triplets are supported/not supported? Have you updated the CI baseline?
CI baseline:
osg-qt:x64-linux passes now, removed from scripts/ci.baseline.txt:
'osg-qt:x64-linux=fail'
Does your PR follow the maintainer guide?
Yes

Info concerning previous patches:

fix-option-2.patch
The patch is not needed any more.
The typo in CMakeLists.txt has been fixed upstream in v8.41,
see revision 1677:
https://vcs.pcre.org/pcre/code/trunk/CMakeLists.txt?r1=1659&r2=1677
The rest of fix-option-2.patch was to suppress a cmake warning
concerning OLD behavior for policy CMP0026
and some MSVC compiler warnings (/wd4703 /wd4146 /wd4308).

more info to be added here ...

I like it! Thanks @c72578, this is great :)


measure Tuya TS0121_plug

Device information
https://www.zigbee2mqtt.io/devices/TS0121_plug.html
Home Assistant Device information
10A UK or 16A EU smart plug (TS0121_plug)
by Tuya

Checklist

[x] I have created a single PR per device. When you have multiple submissions please create separate PR's.
[x] For lights - I have only included the gzipped files (*.gz), not the raw CSV files.
[x] For lights - I have provided a CSV file per supported color mode. Look that up in Developer Tools -> States

Additional info

TS0121 looks like it's a generic zigbee model.
Could you check which manufacturer/brand and model the actual plug is?

TS0121 looks like it's a generic zigbee model. Could you check which manufacturer/brand and model the actual plug is?

As far as I can tell they are not generic. Instead its a case of white label device which is sold under multiple brands. Meaning the same device got a sticker on it and is sold under different names.
Mine got no name, no model and no markings on it. So it's the white label version. ;)

TS0121 looks like it's a generic zigbee model. Could you check which manufacturer/brand and model the actual plug is?

As far as I can tell they are not generic. Instead its a case of white label device which is sold under multiple brands. Meaning the same device got a sticker on it and is sold under different names.
Mine got no name, no model and no markings on it. So it's the white label version. ;)

I see, thanks!


[BUG]We have executed the scanner tool on whole SharePoint Online tenancy and received feedback from a user for the generated report that this scanner tool has not traced a SharePoint site collection where SharePoint 2010 workflow is available

Thank you for reporting a bug. We appreciate your feedback - to help the team to understand your needs, please complete the below template to ensure we have the necessary details to assist you. Thanks!
Problem Area
[ ] Page Transformation: Error during the use of page transformation from PnP PowerShell
[ ] Page Transformation: Error during the use of page transformation from .Net
[ ] Page Transformation: Page is not looking correct after transformation
[ ] Modernization Scanner: something went wrong...
Expected or Desired Behavior
If you are reporting a bug, please describe the expected behavior. If you are suggesting an enhancement please
describe thoroughly the enhancement, how it can be achieved, and expected benefit.
Observed Behavior
If you are reporting a bug, please describe the behavior you expected to occur when performing the action. If you are making a suggestion, you can delete this section.
Steps to Reproduce
If you are reporting a bug please describe the steps to reproduce the bug in sufficient detail to allow testing. Only way to fix things properly, is to have sufficient details to reproduce it. If you are making a suggestion, you can delete this section.
Submission Guidelines
Delete this section after reading

All suggestions or bugs are welcome, please let us know what's on your mind.
If you checked the "Page Transformation: Error during the use of page transformation from PnP PowerShell" checkbox then please provide:

The output you see in your PowerShell session
The output generated by calling Get-PnPException
The PnP PowerShell version. Run get-module -Name SharePointPnPPowerShellOnline and copy the version info

If you checked the "Page Transformation: Error during the use of page transformation from .Net" checkbox then please provide:

The exact error message you get
The stack trace of the error
The version of the SharePointPnP.Modernization.Framework.dll assembly

Thanks for your contribution! Sharing is caring.

Hi @Alok-sys123 , did you run using the latest version of the scanner? Can you confirm the site collection in question was listed in the site report generated as part of the scanner output

Hi Jansen,
Yes we had run using the latest version(<IP_ADDRESS>) of scanner . And It has not been generated in the report

Latest version is 2.18. Please scan that single site having the workflow and see what you get as a result.

Hi Jansen,
Can you please provide the steps to download the latest version of the scanner tool ?
Thanks

https://github.com/pnp/sp-dev-modernization/tree/master/Tools/SharePoint.Modernization/Releases

Closing per no feedback anymore. If this is still an issue please open a new issue


Rarity items dont work

The rarity of things does not want to be shown. The language changed to English everywhere. Both in the profile and in the game.
Screen: https://i.imgur.com/lMhi3L5.png
What else can you try to do?
Version mod: SkyBlockcatia-1.8.9-inv-fix.jar
Modlist: https://i.imgur.com/ff24VAX.png
Resource Packs:  https://i.imgur.com/iu85bAn.png

Fixed in 1.0.9


new: allow utf16 string with length

Patches Nan::New so that it can be initialized with pointer to wides string and length.
Without this the following code failed:
Nan::New(pointer, length)

But the following code worked:
Nan::New<v8::String>(pointer, length)

After this patch they both work. It also adds tests and documentation for this feature.

Merged as 66ac6e65c8ab9394ef588adfc59131b3b9d8347b

Nice :+1:


Header "X-Forwarded-Prefix" wrongly handled by Banana Cake Pop

Bug description
Header "X-Forwarded-Prefix" (set by Traefik reverse proxy) was wrongly handled by Banana Cake Pop when fetching schema.
To Reproduce
Open link https://proxy_url/config/graphql
The path /config was stripped from the proxy and the browser try to retrieve schema without /config path.
Error from Banana Cake Pop console:

Expected behavior
Banana Cake Pop have to load schema with proxied url.
Additional context
dotNet 5
HotChocolate 11.3.4

After more investigation I found that the problem is linked to authorization.
If I add authorization attribute to the query class I have the problem:
[HotChocolate.AspNetCore.Authorization.Authorize]
public partial class Queries
{
    ...

I moved the authorization attribute on every single query method:
/// <summary>
/// Handle entities of type ...
/// </summary>
/// <param name="dbContext"></param>
/// <returns></returns>
[UseDbContext(typeof(SomeDbContext))]
[UseProjection]
[HotChocolate.AspNetCore.Authorization.Authorize]
public IQueryable<SomeEntity> GetEntities([ScopedService] SomeDbContext dbContext) =>
    dbContext.Entities;

I don't know if this is the correct practice, but now the schema is visible to everyone.
It's possible to pass a "global" auth token to Banana Cake Pop in this case?


Phoenix 1.4 support

Resolves #15
I'll merge this in once a new version of ExOauth2Provider has been released.

Closed in favor of #21


Converting Readme from markdown to adoc

What is the purpose of this change? What does it change?
This PR converts the Readme from a markdown to an Asciidoc file

@cdrage please take a look at this PR. I have converted the readme file from .md to .adoc.
I have added a TOC to this since the document is long. However the OpenShift icon does not render if I get the TOC to work. On the other hand if I get the Image to work the TOC rendering goes for a toss. If it's an either/or I would prefer to keep the TOC for easy navigation through the doc. Do you have any suggestions wrt the icon?

@Preeticp My only suggestions with the icon is perhaps having it at the very top of the document? It'd be nice to have the OpenShift logo there.

@cdrage PTAL, I have added the OpenShift logo and have the TOC rendered too. I had to reduce the logo size. If I used the previous size, the 'OpenShift' name below the logo almost seemed to be the same size as the OpenShift in the heading, which made it seem as if we had written OpenShift twice. Also I see too much white space above the title.
See below for what I describe above:

I have tried multiple permutations and combinations for this, and this seems the best for now. Let me know your thoughts.
This is how it renders now:

@Preeticp Are you also planning to apply the same adoc format to other .md file ? I am asking because imo doc format should be in sync in the whole odo repo

Yes @amit absolutely, I will be converting all the .md files to adoc.
Meanwhile, on another note, @cdrage, team, I had expected changes in the Getting Started as per my merged PR, to be reflected on the website here: https://openshiftdo.org/getting-started/ but they don't.
Can you please let me know if there is any additional step required for the website to render updated docs.

@Preeticp thanks. Looks like the bot has no access.. I'll have to fix it: https://travis-ci.org/openshift/odo/jobs/514686848

You are right, replaced with original image.
But I still have 2 concerns, we do not have the TOC rendered and the image seems too big, as in it is reaching way down to the overview itself.
If you are fine with the above 2 issues then we can go ahead and merge this in. We can always fine tune later. For now this seems alright.

/retest

/approve

@Preeticp I don't think the TOC is very necessary on such a small README.md doc, we could work on fixing the issue later.
Please add a commit to delete the .md file and then we can merge this in :+1: thanks so much for being so patient.

@cdrage  @kadel Closing this PR as I am unable to resolve conflict in a branch which has deleted the file I am supposed to resolve the conflict in. I have raised a new PR with all the changes at #1566


remove Workbench , JDBC, ODBC, CLI,   workflows and code

Is your feature request related to a problem?
see https://github.com/opensearch-project/sql/issues/640
As part of the reorganization of the SQL plugin into multiple smaller plugins, the removed code that has become the new plugins
needs to be removed from the main SQL plugin that now becomes the backend plugin for the SQL projects
What solution would you like?
As part of the reorganization of the SQL plugin into multiple smaller plugins, the removed code that has become the new plugins
needs to be removed from the main SQL plugin that now becomes the backend plugin for the SQL projects
SQL projects include:

https://github.com/opensearch-project/sql  -- backend support for all SQL/PPL Api
https://github.com/opensearch-project/sql-jdbc -- JDBC driver support for opensearch as backend
https://github.com/opensearch-project/sql-odbc -- ODBC driver support for opensearch as backend
https://github.com/opensearch-project/sql-cli -- command line Interface for interaction with the SQL backend
https://github.com/opensearch-project/dashboards-query-workbench -- fornt-end support

What alternatives have you considered?
A clear and concise description of any alternative solutions or features you've considered.
Do you have any additional context?
Add any other context or screenshots about the feature request here.

Just a kindly reminder, please pay attention to the dependency between SQL and other components. For example, SQL comparison test task depends on JDBC driver on source code level. Doctest may also depend on SQL CLI.


[Feature]: New hook beforeEachSuccessiveTest which is like beforeEach, but only for successive tests in the suite

🚀 Feature Proposal
Add the beforeEachSuccessiveTest hook, which runs before every test that is defined after this hook.
This idea continues the idea presented in #14614. I created a prototype for that idea and while it solved my use case it was also somewhat problematic in that one test case failure would fail all tests.
This proposal integrates much better with Jest as a whole too. It's just another hook you can use within your existing tests. You don't have to build around your tests being successive.
Motivation
When performing integration tests that rely on complex data setup you have to either duplicate setup code in each test, extract it to a reused function or have tests that fail if you do not run them from start to finish.
Example
The naive approach
The naive way of creating this test suite in the most readable manner would be to rely on state from previous test cases. This is problematic in that it makes Jest harder to use and that for slower tests you have to run the entire test suite regardless.

Naive example
describe("article creation endpoint", () => {
    let authorization;

    beforeAll(async () => {
        authorization = await fetch("http://localhost:3000/login", {
            method: "POST",
            headers: {
                "Content-Type": "application/json",
            },
            body: JSON.stringify({
                username: "test",
                password: "test",
            }),
        })
            .then((response) => response.json())
            .then((data) => data.token);
    });

    test("it creates the article", async () => {
        await fetch("http://localhost:3000/articles", {
            method: "POST",
            headers: {
                "Content-Type": "application/json",
                "Authorization": `Bearer ${authorization}`,
            },
            body: JSON.stringify({
                title: "My first article",
                content: "This is the content of my first article",
            }),
        });

        const articles = await fetch("http://localhost:3000/articles", {
            headers: {
                "Authorization": `Bearer ${authorization}`,
            },
        })
            .then((response) => response.json());

        expect(articles).toContainEqual({
            id: expect.any(String),
            title: "My first article",
            content: "This is the content of my first article",
        });
    });

    test("it creates the second article", async () => {
        await fetch("http://localhost:3000/articles", {
            method: "POST",
            headers: {
                "Content-Type": "application/json",
                "Authorization": `Bearer ${authorization}`,
            },
            body: JSON.stringify({
                title: "My second article",
                content: "This is the content of my second article",
            }),
        });

        const articles = await fetch("http://localhost:3000/articles", {
            headers: {
                "Authorization": `Bearer ${authorization}`,
            },
        })
            .then((response) => response.json());

        expect(articles).toContainEqual({
            id: expect.any(String),
            title: "My second article",
            content: "This is the content of my second article",
        });
    });

    test("it only deletes one article at a time", async () => {
        const articleId = await fetch("http://localhost:3000/articles", {
            headers: {
                "Authorization": `Bearer ${authorization}`,
            },
        })
            .then((response) => response.json())
            .then((articles) => articles[0].id);

        await fetch(`http://localhost:3000/articles/${articleId}`, {
            method: "DELETE",
            headers: {
                "Authorization": `Bearer ${authorization}`,
            },
        });

        const articles = await fetch("http://localhost:3000/articles", {
            headers: {
                "Authorization": `Bearer ${authorization}`,
            },
        })
            .then((response) => response.json());

        expect(articles).toHaveLength(1);

        expect(articles).not.toContainEqual({
            id: expect.any(String),
            title: "My first article",
            content: "This is the content of my first article",
        });
    });
});

Duplicating setup code
To keep test state local, we can duplicate all setup steps, but that quickly becomes very verbose.

Duplicated setup
describe("article creation endpoint", () => {
    let authorization;

    beforeEach(async () => {
        authorization = await fetch("http://localhost:3000/login", {
            method: "POST",
            headers: {
                "Content-Type": "application/json",
            },
            body: JSON.stringify({
                username: "test",
                password: "test",
            }),
        })
            .then((response) => response.json())
            .then((data) => data.token);
    });

    test("it creates the article", async () => {
        await fetch("http://localhost:3000/articles", {
            method: "POST",
            headers: {
                "Content-Type": "application/json",
                Authorization: `Bearer ${authorization}`,
            },
            body: JSON.stringify({
                title: "My first article",
                content: "This is the content of my first article",
            }),
        });

        const articles = await fetch("http://localhost:3000/articles", {
            headers: {
                "Authorization": `Bearer ${authorization}`,
            },
        }).then(
            (response) => response.json(),
        );

        expect(articles).toContainEqual({
            id: expect.any(String),
            title: "My first article",
            content: "This is the content of my first article",
        });
    });

    test("it creates the second article", async () => {
        await fetch("http://localhost:3000/articles", {
            method: "POST",
            headers: {
                "Content-Type": "application/json",
                Authorization: `Bearer ${authorization}`,
            },
            body: JSON.stringify({
                title: "My first article",
                content: "This is the content of my first article",
            }),
        });
        await fetch("http://localhost:3000/articles", {
            method: "POST",
            headers: {
                "Content-Type": "application/json",
                "Authorization": `Bearer ${authorization}`,
            },
            body: JSON.stringify({
                title: "My second article",
                content: "This is the content of my second article",
            }),
        });

        const articles = await fetch("http://localhost:3000/articles",
            headers: {
                "Authorization": `Bearer ${authorization}`,
            },
        }).then(
            (response) => response.json(),
        );

        expect(articles).toContainEqual({
            id: expect.any(String),
            title: "My second article",
            content: "This is the content of my second article",
        });
    });

    test("it only deletes one article at a time", async () => {
        await fetch("http://localhost:3000/articles", {
            method: "POST",
            headers: {
                "Content-Type": "application/json",
                Authorization: `Bearer ${authorization}`,
            },
            body: JSON.stringify({
                title: "My first article",
                content: "This is the content of my first article",
            }),
        });
        await fetch("http://localhost:3000/articles", {
            method: "POST",
            headers: {
                "Content-Type": "application/json",
                "Authorization": `Bearer ${authorization}`,
            },
            body: JSON.stringify({
                title: "My second article",
                content: "This is the content of my second article",
            }),
        });

        const articleId = await fetch("http://localhost:3000/articles", {
            headers: {
                "Authorization": `Bearer ${authorization}`,
            },
        })
            .then((response) => response.json())
            .then((articles) => articles[0].id);

        await fetch(`http://localhost:3000/articles/${articleId}`, {
            method: "DELETE",
            headers: {
                "Authorization": `Bearer ${authorization}`,
            },
        });

        const articles = await fetch("http://localhost:3000/articles", {
            headers: {
                "Authorization": `Bearer ${authorization}`,
            },
        }).then(
            (response) => response.json(),
        );

        expect(articles).toHaveLength(1);

        expect(articles).not.toContainEqual({
            id: expect.any(String),
            title: "My first article",
            content: "This is the content of my first article",
        });
    });
});

Splitting out reused functionality
Splitting out reused functionality is what I would probably consider the best approach as of today. The downside is that it can make the flow of the code much harder to follow. Especially for complex setup. It also lends itself to overly abstracting the test code in ways that lead to difficult to change tests.

Splitting out reused functionality
let authorization;

const createFirstArticle = () =>
    fetch("http://localhost:3000/articles", {
        method: "POST",
        headers: {
            "Content-Type": "application/json",
            Authorization: `Bearer ${authorization}`,
        },
        body: JSON.stringify({
            title: "My first article",
            content: "This is the content of my first article",
        }),
    });

const createSecondArticle = () =>
    fetch("http://localhost:3000/articles", {
        method: "POST",
        headers: {
            "Content-Type": "application/json",
        },
        body: JSON.stringify({
            title: "My second article",
            content: "This is the content of my second article",
        }),
    });

describe("article creation endpoint", () => {
    beforeEach(async () => {
        authorization = await fetch("http://localhost:3000/login", {
            method: "POST",
            headers: {
                "Content-Type": "application/json",
            },
            body: JSON.stringify({
                username: "test",
                password: "test",
            }),
        })
            .then((response) => response.json())
            .then((data) => data.token);
    });

    test("it creates the article", async () => {
        await createFirstArticle();

        const articles = await fetch("http://localhost:3000/articles", {
            headers: {
                "Authorization": `Bearer ${authorization}`,
            },
        }).then(
            (response) => response.json(),
        );

        expect(articles).toContainEqual({
            id: expect.any(String),
            title: "My first article",
            content: "This is the content of my first article",
        });
    });

    test("it creates the second article", async () => {
        await createFirstArticle();
        await createSecondArticle();

        const articles = await fetch("http://localhost:3000/articles", {
            headers: {
                "Authorization": `Bearer ${authorization}`,
            },
        }).then(
            (response) => response.json(),
        );

        expect(articles).toContainEqual({
            id: expect.any(String),
            title: "My second article",
            content: "This is the content of my second article",
        });
    });

    test("it only deletes one article at a time", async () => {
        await createFirstArticle();
        await createSecondArticle();

        const articleId = await fetch("http://localhost:3000/articles", {
            headers: {
                "Authorization": `Bearer ${authorization}`,
            },
        })
            .then((response) => response.json())
            .then((articles) => articles[0].id);

        await fetch(`http://localhost:3000/articles/${articleId}`, {
            method: "DELETE",
            headers: {
                "Authorization": `Bearer ${authorization}`,
            },
        });

        const articles = await fetch("http://localhost:3000/articles", {
            headers: {
                "Authorization": `Bearer ${authorization}`,
            },
        }).then(
            (response) => response.json(),
        );

        expect(articles).toHaveLength(1);

        expect(articles).not.toContainEqual({
            id: expect.any(String),
            title: "My first article",
            content: "This is the content of my first article",
        });
    });
});

With beforeEachSuccessiveTest we are much closer to what we wanted with the first example, but the test cases are independent and expensive operations can be scoped to single test cases.
describe("article creation endpoint", () => {
    let authorization;

    beforeEach(async () => {
        authorization = await fetch("http://localhost:3000/login", {
            method: "POST",
            headers: {
                "Content-Type": "application/json",
            },
            body: JSON.stringify({
                username: "test",
                password: "test",
            }),
        })
            .then((response) => response.json())
            .then((data) => data.token);
    });

    // This runs 3 times and is equivalent to a beforeEach
    beforeEachSuccessiveTest(async () => {
        await fetch("http://localhost:3000/articles", {
            method: "POST",
            headers: {
                "Content-Type": "application/json",
                "Authorization": `Bearer ${authorization}`,
            },
            body: JSON.stringify({
                title: "My first article",
                content: "This is the content of my first article",
            }),
        });
    });

    test("it creates the article", async () => {
        const articles = await fetch("http://localhost:3000/articles", {
            headers: {
                "Authorization": `Bearer ${authorization}`,
            },
        })
            .then((response) => response.json());

        expect(articles).toContainEqual({
            id: expect.any(String),
            title: "My first article",
            content: "This is the content of my first article",
        });
    });

    // This runs 2 times
    beforeEachSuccessiveTest(async () => {
        await fetch("http://localhost:3000/articles", {
            method: "POST",
            headers: {
                "Content-Type": "application/json",
                "Authorization": `Bearer ${authorization}`,
            },
            body: JSON.stringify({
                title: "My second article",
                content: "This is the content of my second article",
            }),
        });
    });

    test("it creates the second article", async () => {
        const articles = await fetch("http://localhost:3000/articles", {
            headers: {
                "Authorization": `Bearer ${authorization}`,
            },
        })
            .then((response) => response.json());

        expect(articles).toContainEqual({
            id: expect.any(String),
            title: "My second article",
            content: "This is the content of my second article",
        });
    });

    // This runs 1 time
    beforeEachSuccessiveTest(async () => {
        const articleId = await fetch("http://localhost:3000/articles", {
            headers: {
                "Authorization": `Bearer ${authorization}`,
            },
        })
            .then((response) => response.json())
            .then((articles) => articles[0].id);

        await fetch(`http://localhost:3000/articles/${articleId}`, {
            method: "DELETE",
            headers: {
                Authorization: `Bearer ${authorization}`,
            },
        });
    });

    test("it only deletes one article at a time", async () => {
        const articles = await fetch("http://localhost:3000/articles", {
            headers: {
                Authorization: `Bearer ${authorization}`,
            },
        })
            .then((response) => response.json());

        expect(articles).toHaveLength(1);

        expect(articles).not.toContainEqual({
            id: expect.any(String),
            title: "My first article",
            content: "This is the content of my first article",
        });
    });
});

Pitch
beforeEachSuccessiveTest integrates nicely with the existing Jest platform and will let you build tests with complex incremental state changes in an easy to read manner.

I'll happily take a look at implementing this if there's interest for it.
Implementation not taking test.each or thedone argument:
"use strict";

let foundSpecs = 0;
let specNumber = 0;

beforeAll(() => {
    specNumber = 0;
});

afterEach(() => {
    specNumber++;
});

global.beforeEachSuccessiveTest = (closure) => {
    const startAfter = foundSpecs;
    beforeEach(() => {
        if (specNumber >= startAfter) {
            return closure();
        }
    });
};

const test = global.test;

["test", "it"].forEach((ident) => {
    global[ident] = function (name, fn) {
        foundSpecs++;
        test.call(this, name, () => {
            return fn();
        });
    };
    Object.assign(global[ident], test);
});

I'll happily look into this if you like the idea.
Minimal implementation excluding support for support.each and the done-callback:
let beforeEachSuccessiveCallbacks = [];

global.beforeEachSuccessiveTest = (closure) => {
    beforeEachSuccessiveCallbacks.push(closure);
};

const test = global.test;

["test", "it"].forEach((ident) => {
    global[ident] = function (name, fn) {
        const beforeCallbacks = beforeEachSuccessiveCallbacks.slice();
        test.call(this, name, () => {
            beforeCallbacks.forEach((cb) => cb());
            return fn();
        });
    };
    Object.assign(global[ident], test);
});


Apotheotic Bosses Spawn Too Much

Title. The apotheotic bosses spawn approximately every 5-7 minutes... please decrease or at least give the option to disable them!

All in the config file


Roll Flutter Engine from 569c62d11084 to 0aabde8bdb7b (3 revisions)

https://github.com/flutter/engine/compare/569c62d11084...0aabde8bdb7b
2023-03-03<EMAIL_ADDRESS>Roll Fuchsia Mac SDK from 4BjO0CPYCTfpHYDyO... to Aarq5ppBEACFT-OYe... (flutter/engine#40053)
2023-03-03<EMAIL_ADDRESS>Roll Dart SDK from b1016d8f293a to c757f4bf468d (2 revisions) (flutter/engine#40052)
2023-03-03<EMAIL_ADDRESS>Roll Skia from 35aef51800ea to 78b8b95fdb15 (1 revision) (flutter/engine#40051)
Also rolling transitive DEPS:
fuchsia/sdk/core/mac-amd64 from 4BjO0CPYCTfp to Aarq5ppBEACF
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC jsimmons@google.com,rmistry<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

AutoRoller is stopped; closing the active roll.


[proposal] scheduler support gang scheduling

What is your proposal:
scheduler support gang scheduling between pods.
Why is this needed:
in AI scenario,  we may want worker launch at same time.
Is there a suggested solution, if so, please add it:
https://github.com/koordinator-sh/koordinator/pull/333

already has same issue #203.


On some versions of MacOS you need to #include <sys/ucontext.h> instead of #include <ucontext.h>

On some versions of MacOS you need to #include <sys/ucontext.h> instead of #include <ucontext.h>

Do you have more information on pre-processor checks that can be used?

can you compile at all? i'm getting a lot of errors on 10.12

@catolm excuse me but why?
Whats the difference between ucontext.h and sys/ucontext.h?
danke!

probably just the symbolic link..
sre, 11. dec 2019. 14:27 liuziangexit<EMAIL_ADDRESS>je
napisao/la:

@catolm https://github.com/catolm excuse me but why?
Whats the difference between ucontext.h and sys/ucontext.h?
danke!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/xoreaxeaxeax/sandsifter/issues/20?email_source=notifications&email_token=ABNCTCZDXJ5NXJJUTKYAQBLQYDTC5A5CNFSM4DU6HI52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGTCZDY#issuecomment-564538511,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABNCTC3FGCW4IQXIS52W7S3QYDTC5ANCNFSM4DU6HI5Q
.

yeah i noticed that in some newer version of macOS(like 10.14), the ucontext won't work... it will gives you unexpected segfault. i have no idea with this.


Some callbacks never called

I am trying to use callbacks but none - except 'clicked' is ever called. I'm on 1.3.5.

I, too, am having issues with some callbacks not being called, particularly the "dropped" callback. I am using the very same code as shown in the main page of the project:

Except for I added the "" property.
In my js file I have
$scope.treeOptions = {
      dragStart: function(event) {
        console.log('Start dragging', event);
      },
      dropped: function(event) {
        console.log('dropped', event);
      },
    };

The dragStart function IS being called, but "dropped" isn't.


fix Fix sql block when new optimizer is enabled

Proposed changes
The check would skipped since when checkBlockPolicy get invoked, new optimizer doesn't do plan yet
Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

(From new machine)TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 47.01 seconds
stream load tsv:          531 seconds loaded<PHONE_NUMBER>9 Bytes, about 134 MB/s
stream load json:         20 seconds loaded<PHONE_NUMBER> Bytes, about 112 MB/s
stream load orc:          64 seconds loaded<PHONE_NUMBER> Bytes, about 16 MB/s
stream load parquet:          31 seconds loaded 861443392 Bytes, about 26 MB/s
insert into select:          28.8 seconds inserted 10000000 Rows, about 347K ops/s
storage size:<PHONE_NUMBER>0 Bytes

run buildall

(From new machine)TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 49.12 seconds
stream load tsv:          528 seconds loaded<PHONE_NUMBER>9 Bytes, about 135 MB/s
stream load json:         20 seconds loaded<PHONE_NUMBER> Bytes, about 112 MB/s
stream load orc:          64 seconds loaded<PHONE_NUMBER> Bytes, about 16 MB/s
stream load parquet:          31 seconds loaded 861443392 Bytes, about 26 MB/s
insert into select:          29.0 seconds inserted 10000000 Rows, about 344K ops/s
storage size:<PHONE_NUMBER>6 Bytes

run buildall

(From new machine)TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 48.28 seconds
stream load tsv:          535 seconds loaded<PHONE_NUMBER>9 Bytes, about 133 MB/s
stream load json:         20 seconds loaded<PHONE_NUMBER> Bytes, about 112 MB/s
stream load orc:          65 seconds loaded<PHONE_NUMBER> Bytes, about 16 MB/s
stream load parquet:          32 seconds loaded 861443392 Bytes, about 25 MB/s
insert into select:          29.1 seconds inserted 10000000 Rows, about 343K ops/s
storage size:<PHONE_NUMBER>4 Bytes

run buildall


Replace magic __call method with real routing methods

Solves #504 and simplifies tests.

Thanks, @jansvoboda11; merged for an upcoming 2.1.0 release.


Confusion about clockwise order of vertices in custom geometry tutorial

The tutorial on custom geometries has been very helpful. Thanks a lot!
There's one detail I had to struggle with. The tutorial states:

The order we specify the vertices is important. To be pointing toward the outside of the cube
they must be specified in a clockwise direction when that triangle is facing the camera.

However, I realized that in contrast to this statement, faces become visible only when the camera-facing side is created in counter-clockwise order. I came across this stackoverflow answer that also states that the default is CCW. Actually, everything works as expected when connecting vertices in CCW direction.
I'm probably missing something, but maybe it would help to clarify the mechanics in the tutorial.

Thanks! You're right. Fixed
https://github.com/greggman/threejsfundamentals/commit/ec72af3ab9b2b8a1a9f91f9d5da02bee4add5dc1


noManifest error on Sierra with VSCode.

I can compile both debug and release binaries fine, I copy the LanguageServer binary to /usr/local/bin and open a project within VSCode, but I get the following error:
fatal error: 'try!' expression unexpectedly raised an error: PackageModel.Package.Error.noManifest(baseURL: "/Users/rob/Projects/ios-quizzer", version: nil): file /Library/Caches/com.apple.xbs/Sources/swiftlang/swiftlang-802.0.48/src/swift/stdlib/public/core/ErrorType.swift, line 182
Current stack trace:
0    libswiftCore.dylib                 0x0000000103fa9160 swift_reportError + 129
1    libswiftCore.dylib                 0x0000000103fc5a70 _swift_stdlib_reportFatalErrorInFile + 100
2    libswiftCore.dylib                 0x0000000103db6350 (_assertionFailure(StaticString, String, file : StaticString, line : UInt, flags : UInt32) -> Never).(closure #1).(closure #1).(closure #1) + 124
3    libswiftCore.dylib                 0x0000000103f6d390 partial apply for (_assertionFailure(StaticString, String, file : StaticString, line : UInt, flags : UInt32) -> Never).(closure #1).(closure #1).(closure #1) + 93
4    libswiftCore.dylib                 0x0000000103db5a00 specialized specialized StaticString.withUTF8Buffer<A> ((UnsafeBufferPointer<UInt8>) -> A) -> A + 342
5    libswiftCore.dylib                 0x0000000103f6f8b0 partial apply for (_assertionFailure(StaticString, String, file : StaticString, line : UInt, flags : UInt32) -> Never).(closure #1).(closure #1) + 144
6    libswiftCore.dylib                 0x0000000103db5f10 specialized specialized String._withUnsafeBufferPointerToUTF8<A> ((UnsafeBufferPointer<UInt8>) throws -> A) throws -> A + 127
7    libswiftCore.dylib                 0x0000000103f30f70 partial apply for (_assertionFailure(StaticString, String, file : StaticString, line : UInt, flags : UInt32) -> Never).(closure #1) + 185
8    libswiftCore.dylib                 0x0000000103db5a00 specialized specialized StaticString.withUTF8Buffer<A> ((UnsafeBufferPointer<UInt8>) -> A) -> A + 342
9    libswiftCore.dylib                 0x0000000103ee6c30 specialized _assertionFailure(StaticString, String, file : StaticString, line : UInt, flags : UInt32) -> Never + 144
10   libswiftCore.dylib                 0x0000000103dde8d0 swift_unexpectedError_merged + 289
11   LanguageServer                     0x0000000103b54050 specialized Server.init(inDirectory : AbsolutePath) -> Server + 3101
12   LanguageServer                     0x0000000103b4a120 Server.__allocating_init(InitializeParams) -> Server? + 155
13   LanguageServer                     0x0000000103889200 specialized handle(Request) -> Response + 5625
14   LanguageServer                     0x00000001038876e0 (closure #1) + 751
15   LanguageServer                     0x0000000103888190 thunk + 66
16   Foundation                         0x00007fff9814ab5e -[__NSObserver _doit:] + 304
17   CoreFoundation                     0x00007fff96721500 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12
18   CoreFoundation                     0x00007fff96721260 _CFXRegistrationPost + 427
19   CoreFoundation                     0x00007fff96721140 ___CFXNotificationPost_block_invoke + 50
20   CoreFoundation                     0x00007fff966dde80 -[_CFXNotificationRegistrar find:object:observer:enumerator:] + 1827
21   CoreFoundation                     0x00007fff966dd380 _CFXNotificationPost + 604
22   Foundation                         0x00007fff98101955 -[NSNotificationCenter postNotificationName:object:userInfo:] + 66
23   Foundation                         0x00007fff981bea3c _performFileHandleSource + 1144
24   CoreFoundation                     0x00007fff9672b3b0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
25   CoreFoundation                     0x00007fff9670c0a0 __CFRunLoopDoSources0 + 557
26   CoreFoundation                     0x00007fff9670b420 __CFRunLoopRun + 934
27   CoreFoundation                     0x00007fff9670b020 CFRunLoopRunSpecific + 420
28   Foundation                         0x00007fff9811d45d -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 277
29   Foundation                         0x00007fff9811d3fe -[NSRunLoop(NSRunLoop) run] + 76
30   LanguageServer                     0x00000001038873f0 main + 723
31   libdyld.dylib                      0x00007fffabe6e234 start + 1

This happens on all of my projects (all were created in xcode). Any help would be appreciated! Thanks :)

If you run it from the directory that you built it from (e.g., $SRC/.build/release/LanguageServer) do you still get this error?

No, it doesn't. I'm trying to use it with VSCodes swift extension, and it looks by default in /usr/local/bin so I put it there, unaware of what external dependencies it carries. I'm not sure if I missed some documentation on this?

Yes, same error no matter where the binary is, if it's debug or release, etc.
I should note I only get this error from within VSCode. I can run the LanguageServer binary from anywhere if I start it from the shell. (or it seems to be running anyway, it just sits there not outputting anything).

I'm reasonably confident this is a duplicate of #25 and #22.


chore(docs): improve documentation

Documentation Update

[x] Add config reference for server and client configs
[x] Update roadmap with upcoming long term and short features of Guardian
[x] Add contribution guide for adding a new provider
[x] Create a concept guide for appeal, policy, and providers. Update diagrams for better representation.
[x] Add usage examples of fields in the reference section of appeal, policy, and provider.
[x] Add deployment guide using helm, docker
[x] Update architecture guide

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
5952

Relevant Lines:
8039

💛  - Coveralls

@haveiss should the commit prefix be docs instead of chore ?

@haveiss should the commit prefix be docs instead of chore ?

@mabdh sure, done 🙏


[nitro-protocol] Enhance testing of ERC20 deposits and withdrawals

Headlines:
ERC20AssetHolder.deposit:
Deposits Tokens (expectedHeld = 0):
76024 gas

Deposits Tokens (expectedHeld = 1):
46024 gas

Most expensive for first person to deposit, since they must create (instead of modify) a storage slot. Perhaps some interesting game theory there!
concludePushOutcomeAndTransferAll:
{ERC20: {A: 1, B: 1}}:
140121 gas

{ERC20: {At: 1, Bt: 1}} (At and Bt already have some TOK, so it's cheaper to pay out-- this is probably the norm, though):
110109 gas

10 TOK payouts:
406,543 gas

50 TOK payouts:
1,589,293 gas

100 TOK payouts:
2,656,645 gas

Context: that block gas limit of 8million.

Might be more realistic / interesting to test the case where 98 of the 100 destinations are actually internal (i.e. channel ids).


dataset

Hello, if I use the got-10k data set provided by the official website, does the dataset need to be preprocessed before training? (for example, siamrpn + +, I need to do pre_crop 511 12 before training). If I want to add other training datasets, such as coco vid, is the configuration file of the datasets the same as that of got10K.py？Thank you very much for your answer

@anchor666  the got-10k does not need to be preprocessed in this project.  We do this process in the training process. If you want to add another dataset,  you can write a datasetxxx.py like other datasets in data/dataset/dataset_impl.  And you can just add your dataset in the config yaml file to use it.

@anchor666 May we close this issue since no further discussion persists?

@anchor666 May we close this issue since no further discussion persists?

Of course it can be closed，Thanks again！


iOS: Add footer to info reference asset

Depends on #161
To better model some real world scenarios, the info asset should be able to render content below the actions.
Render the footer for  the SwiftUI reference asset

Hi, can I work on this issue? (I'm Vivian Zhu from Intuit)


Token URI change bug

Should fix https://github.com/OpenZeppelin/openzeppelin-subgraphs/issues/18

See #18 for discussion.
TLDR: that would be super ineffective and would greatly slow down indexing. It would also not be effective for tokens that are not transferred. Its unfortunate that ERC721 is not designed better.


Not able to create new project with Angular + windows10

Getting error while creating new project.
Versions.
Windows_NT 10.0.15063
angular/cli 1.3.0
node v8.2.1
npm  v5.2.0
The log given by the failure.
11475 verbose unlock done using C:\Users\XXX\AppData\Roaming\npm-cache_locks\staging-e586857f35c37a81.lock for G:\workspace\first-angular-pjt\node_modules.staging
11476 warn enoent ENOENT: no such file or directory, open 'G:\workspace\first-angular-pjt\package.json'
11477 verbose enoent This is related to npm not being able to find a file.
11478 warn first-angular-pjt No description
11479 warn first-angular-pjt No repository field.
11480 warn first-angular-pjt No README data
11481 warn first-angular-pjt No license field.
11482 warn optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules\fsevents):
11483 warn enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'G:\workspace\first-angular-pjt\node_modules.staging\fsevents-03b228b5\node_modules\abbrev' -> 'G:\workspace\first-angular-pjt\node_modules.staging\abbrev-e431bcc4'
11484 verbose enoent SKIPPING OPTIONAL DEPENDENCY: This is related to npm not being able to find a file.
11484 verbose enoent SKIPPING OPTIONAL DEPENDENCY:
11485 verbose type OperationalError
11486 verbose stack Error: sha1-OfaZ86RlYN1eusvKaTyvfGXBjMY= integrity checksum failed when using sha1: wanted sha1-OfaZ86RlYN1eusvKaTyvfGXBjMY= but got sha1-Rq++iNFVBOku6G/VwrmLALuQ+vA=. (10513 bytes)
11486 verbose stack     at Transform.on (C:\Users\XXX.webclipse\npm\5.2.0\node_modules\ssri\index.js:275:19)
11486 verbose stack     at emitNone (events.js:110:20)
11486 verbose stack     at Transform.emit (events.js:207:7)
11486 verbose stack     at endReadableNT (_stream_readable.js:1045:12)
11486 verbose stack     at _combinedTickCallback (internal/process/next_tick.js:138:11)
11486 verbose stack     at process._tickCallback (internal/process/next_tick.js:180:9)
11487 verbose cwd G:\workspace\first-angular-pjt
11488 verbose Windows_NT 10.0.15063
11489 verbose argv "C:\Users\XXX\.webclipse\nodejs\8.2.1\node.exe" "C:\Users\XXX\.webclipse\npm\5.2.0\bin\npm-cli.js" "install" "<EMAIL_ADDRESS>11490 verbose node v8.2.1
11491 verbose npm  v5.2.0
11492 error code EINTEGRITY
11493 error sha1-OfaZ86RlYN1eusvKaTyvfGXBjMY= integrity checksum failed when using sha1: wanted sha1-OfaZ86RlYN1eusvKaTyvfGXBjMY= but got sha1-Rq++iNFVBOku6G/VwrmLALuQ+vA=. (10513 bytes)
11494 verbose exit [ 1, true ]

I had this too but I did not do 'ng new projectname' in the the folder where the package.json was located. Please make sure you do it correctly :-)

Yeah this error isn't with Angular CLI itself but with npm. You seem to be getting integrity checksum failed when using sha1 error that prevent you from installing packages. Have a look at https://github.com/npm/npm to see if the error you have is known.


Recommended install not working

Hello nice people @UENO, both:
yarn create ueno-app  project-name

Hi,
Thanks for reporting. It has been fixed on latest version of<EMAIL_ADDRESS>


[Chats] Incorrect chat date and time format

Environment: OnePlus 7, Android <IP_ADDRESS>
Reproducible: always.
Build found: 1.0.178
Preconditions
User logged in.
Car app is opened.
Chat is created.
Steps to reproduce

Click on 'Chats' tab.
Pay attention to the details of the chat.

Actual result
Chat format is "Starts at: DD.MM 00:00".
Expected result
Char should have the following format: "starts at DD.MM, 00:00".
User story and test case links
E.g.: "User story #376
Labels to be added
"Bug" ("bug"), Priority ("pri: ")

Bug fixed.


Not working bind values in CreateCommand

Hello! I have problem in binding params...
I use:

Yii::$app->db->createCommand('SET TIME ZONE :timezone', [':timezone' => $timezone])->execute();

or

Yii::$app->db->createCommand('SET TIME ZONE :timezone', [':timezone' => [$timezone, PDO::PARAM_STR]])->execute();

And i get error:

SQLSTATE[42601]: Syntax error: 7 ERROR: syntax error at or near "$1"
LINE 1: SET TIME ZONE $1
^
The SQL being executed was: SET TIME ZONE 'Europe/Moscow'
Error Info: Array
(
[0] => 42601
[1] => 7
[2] => ERROR:  syntax error at or near "$1"
LINE 1: SET TIME ZONE $1
^
)

Tell me what to do? Thanks for all!
Yii 2.0 - stable
php 5.4
PSQL 9.3

The continuing problem when trying to pass a parameter as a string for example
Yii::$app->db->createCommand("TRUNCATE TABLE :tableName", [':tableName'=> $tableName]);
Any solution???

You can't bind table names or column names. These should be properly escaped and then concatenated w/ SQL string.


feat: implement event moving in time grid

Please check if the PR fulfills these requirements

[x] It's submitted to right branch according to our branching model
[x] It's right issue type on title
[x] When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)
[x] The commit message follows our guidelines
[x] Tests for the changes have been added (for bug fixes/features)
[ ] Docs have been added/updated (for bug fixes/features)
[ ] It does not introduce a breaking change or has description for the breaking change

Description
https://user-images.githubusercontent.com/14539203/155462678-f9d5ee7b-b55b-424c-8fab-330216281648.mov

Feature: Implemented an event-moving functionality in the time grid.
Test: Created test utility functions.

It will be used various integration tests in favor of using testing-library directly.

Fix: Shared preference problem between EventUIModels.

Thank you for your contribution to TOAST UI product. 🎉 😘 ✨

많은 수의 이벤트가 랜더링 된 상태에서(스토리북의 'Random Events' 페이지) 개발자 도구를 킨 채로 실험해보았을 때 아직도 전반적인 퍼포먼스 문제가 남아있다는 것을 확인했습니다.
해결을 위해 전반적인 D&D 인터렉션에 대한 리팩터링이 필요한데 이는 별도의 PR로 올릴 예정입니다.


chore: ini pods

Current dependencies on/for this PR:

main

PR #136   👈

This comment was auto-generated by Graphite.


Make update-copyright end files with a newline

@marcboulle
I added the .rc files to the config and it compiles.


Fix url parse issue

Fix url format so hugo server runs as expected without errors.
This is a partial solution (no. 3) for https://github.com/dapr/docs/issues/4281

LGTM


Add reminder email to recommender when 2 reviews are in

 Add reminder email to recommender when 2 reviews are in


fix: Cast var to float before calculating standard deviation

Description
This pull request ensures that the standardize function always returns a float output. Previously, if the input var was not a float, the function might return a non-float output, potentially leading to unexpected behavior in downstream code.
Changes
Cast var to float using float() before calculating the standard deviation in the standardize function.

I employee this request.


[QUESTION] Is it bad practice to repurpose asyncValidate for integrating a Promise-returning validation library?

My understanding is that asyncValidate() is provided to support the "Is this username taken?" and similar use cases where server-side logic is required to run in order to validate one or more fields before the actual form submission.
I've been looking at integrating the Joi-inspired Yup library (https://github.com/jquense/yup) as detailed in this blog post:
http://www.davidboyne.co.uk/2016/04/29/redux-form-validation-with-yup.html
I like yup's declarative paradigm, but its validate() function is Promise-returning, which I thought I could await in RF's synchronous validate() function but there is no way to actually wait for the promise to settle before returning from validate() so that doesn't work.
It would work using asyncValidate(), but would you advise against repurposing asyncValidate for integrating a Promise-based validation library like this?

Sorry, I just realized this is more appropriate for SO:
http://stackoverflow.com/q/40363850/6439734


Kinesis - DescribeStream(): Implement Filter-param

Fixes #691

Codecov Report

Merging #4391 (f9d57af) into master (4795888) will decrease coverage by 0.00%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #4391      +/-   ##
==========================================
- Coverage   95.07%   95.07%   -0.01%
==========================================
  Files         495      496       +1
  Lines       56041    56051      +10
==========================================
+ Hits        53283    53292       +9
- Misses       2758     2759       +1

Flag
Coverage Δ

servertests
48.89% <100.00%> (+0.01%)
:arrow_up:

test_responses
32.73% <20.00%> (+0.01%)
:arrow_up:

unittests
94.98% <100.00%> (-0.01%)
:arrow_down:

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

Impacted Files
Coverage Δ

moto/kinesis/models.py
88.81% <100.00%> (+0.07%)
:arrow_up:

moto/kinesis/responses.py
96.69% <100.00%> (+0.02%)
:arrow_up:

moto/ec2/models.py
94.76% <0.00%> (-0.09%)
:arrow_down:

moto/kinesis/utils.py
100.00% <0.00%> (ø)

moto/events/utils.py
100.00% <0.00%> (ø)

moto/events/models.py
94.61% <0.00%> (+0.27%)
:arrow_up:

moto/events/responses.py
95.18% <0.00%> (+0.31%)
: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 4795888...f9d57af. Read the comment docs.


heatmap readme update

@vtkalek,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot