I have obtained R-precision test results, but they differ from those reported in the paper.

I have not modified any hyperparameters.

The other results are consistent.

I‘m sorry that i modified the R_size.

All right. If you have any other concerns, please let me know.


Idea: Stripe webhook inlet

Listen for certain Stripe events, e.g. customer.subscription.created.

Resolved with 0f98c50e42a98231dfae9bd7f12660998687fbf1.


Let CI fail earlier if our server is down

Summary

When our server is down, the wget commands in our CI job retry 20 times with a long timeout. This reduces the timeout to 15 seconds and the retries to 2. With that, our CI should fail much earlier. Also, this does not really harm the user running make install.
Proposed changes

Related issues

Checklist

[ ] Run colcon build
[ ] Write documentation
[x] Test on your machine
[ ] Test on the robot
[ ] Create issues for future work
[x] Triage this PR and label it

Should it time out currently?

Yes


Import datasets with dict in metrics: extra

If datasets has a dict in yaml file - metrics: extra  - that cause the unknown error when import datasets using UI.

Actual results
Failed import datasets
Screenshots

Server log

How to reproduce the bug

Edit any Virtual datasets
Click on Metrics tab
Click on "Add Item" - create any new item - or even add item and click delete - it also create dict in extra field.
Save datasets
Click on Action - Export
Click Import  - choose zip file previously exported
enter "OVERWRITE"
See error

Environment

superset version: superset version 1.0.1
docker-compose-non-dev.yml

Additional context
If change dict to null in yaml file - import works as expected.

Closing this since it's stale and referring to an old version of Superset. I'm more than happy to re-open this and give it some attention if anyone on this thread can validate that it's still an issue with Superset 2.1.0.


EventID 15 - Bad Request

Hello,
I am having some trouble after reimaged a PC that was working with CloudLAPS. My issue is that this computer keeps failing with error code 15 - Bad Request. Here is what I have done already:

Wiped the stored credential from the ClouldLAPS web vault. I did this manually. There are no credentials stored for this computer any more. This changed the error code from "password rotation not allowed" to "Error 15 - Bad Request".

As a note I did not purge the key, only deleted it.

Checked the local logs on the device and found Error 15 - Bad Request. No further information was in the local logs.
Found the failed request within the monitor section of the CloudLAPS Function App on Azure. (this also didn't provide anything that indicated what was wrong. The request seemed like other requests that were successful.)

I am lost on what to do next. I can just try wiping the device again and reimaging. As a side note - other devices are working normally. No issues with any other device.
Any ideas?

In case anyone else comes across this: you must PURGE the key from the vault. Simply deleting the key will not work. Azure thinks that your trying to update the deleted secret instead of creating a new secret. Go to your CloudLAPS key vault give yourself permission to view secrets inside the key vault and permissions to purge the deleted secrets. After you have given yourself permissions, find the secret and delete the key. After the key is deleted, purge the key under "manage deleted secrets". Restart your computer and let CloudLAPS run again to properly onboard the device.
Make sure to remove permissions to from the key vault once your done :)

Hi,
Unfortunately, we have the same issue. (Event ID15 BadRequest, failed to update password)
We tried to perform your solution, but we did not find any key in the vault. (We added all permission to our ID as you suggested)
Do you have any other solution for this issue? Or do you have any idea why we do not find any key?


Use behavior api for p2p protocol

extracted from #1149
builds on #1184
What was wrong?
#1142 introduces the behavior API.  The basic p2p protocol has lots of functionality that can be migrated to this API.
How was it fixed?
Moved all of the basic p2p protocol functionality and APIs to be based on the "Behavior" API.
Now the peer class has a p2p_api property which exposes all of the APIs we use to interface with remote peers.
To-Do

[x] Clean up commit history

[x] Add entry to the release notes

Cute Animal Picture

Great questions.  Some answers to your main comments here.

I'm still a little skeptical of this design but I can't be sure this isn't just a difference in our preferred styles.

I'm honestly skeptical too, so I'm very open to this being reworked but my preference would be for that to happen as a result of others getting their hands dirty and using the APIs to build out functionality.  I know I'm prone to the mistake of forecasting architecture needs rather than being more adherent to YAGNI so I've tried to at least trim things down to only the functionality that's being actively used.

I don't get why Logic and Behavior are broken into two very intertwined classes

I think the simple explanation is "composition" instead of "inheritance".  Behavior is an internal class.  There is no expectation for a user to directly use or extend the BehaviorAPI.  Logic is a user facing API and it is very simple by design, requiring the user to implement a very minimal API and with very little built-in API that might collide with user defined APIs.
You can see a similar design in p2p.trio_service.  The Service class is akin to the Logic class, and the Manager class is akin to the Behavior class.  This design was directly inspired by our previous p2p.service.BaseService which combines these two, which results in awkward lifecycle management and lots and lots of APIs that the user has to be careful not to override.

I don't see why the Qualifier api exists, it doesn't seem like this wins anything over using first-class functions directly.

I think that the Qualifier API allows for and fully supports first-class functions.  However, the reason for the fancy Qualifier classes is that I found myself needing to re-use and combine qualifier functions and that simply using first-class functions resulted in a lot of boilerplate.  The tools in p2p.qualifiers are a direct result of trying it first with first-class functions and it being very boilerplate heavy.

having an applies_to method subclasses can override.

I did it this way first and it wasn't sufficiently expressive.  Lots of things need the same applies_to logic and using subclassing resulted in either the code not being DRY, lots of boilerplate, or gross Mixin classes that result in inheritance insanity.
More answers to inline comments incoming.

The Service class is akin to the Logic class, and the Manager class is akin to the Behavior class. This design was directly inspired by our previous p2p.service.BaseService which combines these two, which results in awkward lifecycle management and lots and lots of APIs that the user has to be careful not to override.

Yeah, this is a pretty good argument! Maybe Behavior could be called something like _Behavior to make it clear it's internal, but this makes more sense now.

I think that the Qualifier API allows for and fully supports first-class functions. However, the reason for the fancy Qualifier classes is that I found myself needing to re-use and combine qualifier functions and that simply using first-class functions resulted in a lot of boilerplate. The tools in p2p.qualifiers are a direct result of trying it first with first-class functions and it being very boilerplate heavy.

It sounds like this is a situation where I see the thing but not the thing that it's replacing, and I agree that being able to say qualifier = always is pretty nice!


JSX element type 'Provider' is not a constructor function for JSX elements.

The problem  upgrade the version to react16。Whether it is related to the official description of the document
JSX element type 'Provider' is not a constructor function for JSX elements.
Types of property 'render' are incompatible.
Type '() => string | number | false | Element | Element[]' is not assignable to type '{ (): string | number | false | Element | Element[]; (): false | Element; }'.
Type 'string | number | false | Element | Element[]' is not assignable to type 'false | Element'.
Type 'string' is not assignable to type 'false | Element'.

meet the same problem

react16 caused by the problem 。
can install  @tyeps/react 15.6

I fixed the problem by updating

"@types/react": "^16.0.10",
"@types/react-dom": "^16.0.1",
"mobx": "^3.2.2",
"mobx-react": "^4.3.3",
"react-dom": "^16.0.0",
"react": "^16.0.0"

although I don't know which one is the key of this problem

@ types/react: "^16.0.10"  is the key of this problem

As far as I can see this behaves correctly in the test suite. Could you try to reproduce it in our test suite? Maybe the compiler settings are different? See this test (use npm run test:ts to run it)

Unfortunately！
i use<EMAIL_ADDRESS>

Closing here, assuming the official types will be / are fixed? Feel free to reopen if it ain't in the near future

If anyone is still experiencing this issue and is using yarn, make sure that you clear node_modules and delete yarn.lock. That fixed it for me.
rm -rf node_modules && rm yarn.lock && yarn

It could be the same for NPM's package-lock.json, but I didn't test it.
See https://github.com/DefinitelyTyped/DefinitelyTyped/issues/21242 for details.


Problem occurs when using libmpk with multiple threads

I wrote a program as follows, and found that some threads exited abnormally when executing mpt_begin mpt_end.
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <mpt/mpt.h>
#include <climits>
#include <fcntl.h>
#include <sys/mman.h>

#define DOM_NUM 1024
#define MAX_THREAD 12

char *iso_data[DOM_NUM];
void (*funcs[DOM_NUM])(int);
int vpkeys[DOM_NUM];

void chain_func(int i) {
    mpt_begin(vpkeys[i], PROT_READ | PROT_WRITE);
    mpt_end(vpkeys[i]);
    funcs[i+1](i+1);
}

void end_func(int i) {
    mpt_begin(vpkeys[i], PROT_READ | PROT_WRITE);
    mpt_end(vpkeys[i]);
}

void init_domain(int num) {
    mpt_init(-1);
    for (int i = 0; i < num; i++) {
        vpkeys[i] = mpt_mmap((void **)&iso_data[i], 0x1000, PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_PRIVATE);
        funcs[i] = chain_func;
    }
    funcs[num - 1] = end_func;
}

typedef struct thread_info {
    pthread_t pid;
    unsigned long long res;
} info_t;

info_t threads_info[MAX_THREAD];

void *worker_func(void *arg) {

    int count = 10000;

    unsigned long long start = rdtsc();
    for (int i = 0; i < count; i++) {
        funcs[0](0);
    }
    unsigned long long end = rdtsc();

    ((info_t *)arg)->res = (end - start) / count;
    printf("thread with res %llu\n", (end - start)/ count);

    return NULL;
}

int main(int argc, char *argv[]) {
    int num = 30;
    int threads = 2;

    init_domain(num);

    for (int i = 0; i < threads; i++) {
        int ret = pthread_create(&threads_info[i].pid, NULL, &worker_func, &threads_info[i]);
        if (ret < 0) {
            printf("pthread_create failed\n");
            return -1;
        }
    }

    unsigned long long total = 0;
    for (int i = 0; i < threads; i++) {
        int ret = pthread_join(threads_info[i].pid, NULL);
        if (ret < 0) {
            printf("pthread_join failed\n");
            return -1;
        }
        total += threads_info[i].res;
        printf("thread %d time %llu\n", i, threads_info[i].res);
    }

    unsigned long long avg = total / threads;

    printf("%d,%llu,\n", num, avg);

    return 0;
}

The program chained num functions, inside each function it switches domain. When there is only one thread (threads = 1 in main()), the program works well. However, if threads = 2, some of threads may corrupt and exit early than return NULL in worker_func, as the res field turned out to be 0 for these threads.
And I found error messages thrown by kernel:
[77496.266736] BUG: unable to handle kernel NULL pointer dereference at<PHONE_NUMBER>000014
[77496.275514] IP: SyS_pkey_mprotect_evict+0x80/0xb0
[77496.281130] PGD 0 P4D 0
[77496.284558] Oops: 0002 [#48] SMP
[77496.288651] Modules linked in: xt_addrtype iptable_filter br_netfilter bridge stp llc overlay inte
l_rapl binfmt_misc x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_p
clmul crc32_pclmul ghash_clmulni_intel mgag200 ttm pcbc drm_kms_helper aesni_intel drm ipmi_ssif aes_
x86_64 crypto_simd glue_helper cryptd fb_sys_fops syscopyarea sysfillrect ipmi_si sysimgblt dcdbas in
tel_cstate mei_me ipmi_devintf ipmi_msghandler intel_rapl_perf nfit mac_hid acpi_power_meter mei acpi
_pad lpc_ich sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 igb megaraid_sas i2c
_algo_bit ahci dca libahci
[77496.348245] CPU: 34 PID: 76459 Comm: main Tainted: G      D    OE   4.14.2-mpk #1
[77496.356684] Hardware name: Dell Inc. PowerEdge R640/008R9M, BIOS 1.2.71 12/04/2017
[77496.365194] task: ffff9244e83b8000 task.stack: ffffb6cd49b0c000
[77496.372043] RIP: 0010:SyS_pkey_mprotect_evict+0x80/0xb0
[77496.378177] RSP: 0018:ffffb6cd49b0ff40 EFLAGS: 00010246
[77496.384293] RAX: 00000000ffffffff RBX: 00000000ffffffff RCX:<PHONE_NUMBER>000000
[77496.392299] RDX:<PHONE_NUMBER>000000 RSI:<PHONE_NUMBER>001000 RDI: 00007fdd3b5e7000
[77496.400297] RBP: ffffb6cd49b0ff48 R08: 00000000ffffffff R09:<PHONE_NUMBER>000000
[77496.408287] R10: ffff9244e0b01000 R11: ffff9244e83b8000 R12:<PHONE_NUMBER>000005
[77496.416272] R13:<PHONE_NUMBER>000003 R14:<PHONE_NUMBER>000000 R15: 00007ffc663f3ac0
[77496.424263] FS:  00007fdd39b6d700(0000) GS:ffff9244fc040000(0000) knlGS:0000000000000000
[77496.433208] CS:  0010 DS: 0000 ES: 0000 CR0:<PHONE_NUMBER>050033
[77496.439823] CR2:<PHONE_NUMBER>000014 CR3: 0000001fe1609005 CR4:<PHONE_NUMBER>4606e0
[77496.447829] DR0:<PHONE_NUMBER>000000 DR1:<PHONE_NUMBER>000000 DR2:<PHONE_NUMBER>000000
[77496.455835] DR3:<PHONE_NUMBER>000000 DR6: 00000000fffe0ff0 DR7:<PHONE_NUMBER>000400
[77496.463823] PKRU: 55555550
[77496.467388] Call Trace:
[77496.470688]  entry_SYSCALL_64_fastpath+0x1e/0xa9
[77496.476142] RIP: 0033:0x7fdd3adc9839
[77496.480556] RSP: 002b:00007fdd39b6cd98 EFLAGS: 00000246 ORIG_RAX:<PHONE_NUMBER>000151
[77496.488976] RAX: ffffffffffffffda RBX: 00007fdd2c000000 RCX: 00007fdd3adc9839
[77496.496964] RDX:<PHONE_NUMBER>000000 RSI:<PHONE_NUMBER>001000 RDI: 00007fdd3b5e7000
[77496.504953] RBP:<PHONE_NUMBER>021000 R08: 00000000ffffffff R09:<PHONE_NUMBER>000000
[77496.512940] R10:<PHONE_NUMBER>000000 R11:<PHONE_NUMBER>000246 R12: 00007fdd30000000
[77496.520925] R13:<PHONE_NUMBER>000000 R14: 00005596e56f2050 R15: 00007ffc663f3ac0
[77496.528907] Code: f8 1f 41 c1 e8 12 44 01 c0 25 ff 3f 00 00 44 29 c0 4c 63 c0 4f 8d 0c 40 49 c1 e1
 04 4d 01 d1 45 8b 01 41 83 f8 ff 75 cb 45 31 c9 <41> c7 41 14 ff ff ff ff e8 b3 97 da ff 5b 5d c3 49
 83 c1 08 41
[77496.549502] RIP: SyS_pkey_mprotect_evict+0x80/0xb0 RSP: ffffb6cd49b0ff40
[77496.557086] CR2:<PHONE_NUMBER>000014
[77496.561312] ---[ end trace 65f6d43ddbec5cb1 ]---

I have the following questions:

Do I use the interfaces provided by libmpk correctly? I am worried about that the problem is caused by coding incorrectly.
Does libmpk support multi-threaded programming? If so, can you provide a runnable version of multi-threaded benchmark? Or if there are some bugs, can you fix them?

Hi @guozhenwuai , diving in the codebase and comparing the kernel provided with the original linux one, I found a change in mm/mprotect.c that may be of your interest: https://github.com/sslab-gatech/libmpk/blob/master/kernel/mm/mprotect.c#L747
I suppose that's the case you're reaching in this case. The codebase has not been updated for more than 2 years, so I suppose the authors won't address it.