Feature: Add draggable spots functionality for LineChart

Hello!
First of all, thank you and all contributors for this awesome package, you rule :fire:
This PR closes #1420, closes #1247,  I believe this package definitely needs this type of feature. So here is my approach to achieve it.
What's done

Added parameter isDraggable for the LineChartBarData.
Added dragSpotUpdateFinishedCallback for the LineTouchData which returns UpdatedDragSpotsData. It allows us to do some logic after dragging has been finished.
If there is any LineChartBarData with an isDraggable flag, we cache lineBarsData inside _LineChartState and update them if we need to, depending on FlTouchEvent.
Added didUpdateWidget for _LineChartState in order to react to updates in the widget's configuration changes.
Added a simple sample (preview of it is down below)

Preview

Please check if this approach fits for you and let me know, I'll finish it up and add more docs, also feel free to suggest what's can be done better :)

Great, this is the effect I imagined, this is really great.

Great, this is the effect I imagined, this is really great.

Thanks a lot, I'm still waiting for updates from the maintainer, in meanwhile, you can use my fork and in case of any bugs feel free to report them here :)

@G33kFreak holy cow, this is awesome 🚀

Great man, I really wanted that feature as this is my requirement.

Thank you for this great contribution!
I will add some comments now:

Can you please update your branch? Then I can take a look again.
Thanks!

Can you please update your branch? Then I can take a look again. Thanks!

I'll do it as soon as I have some free time :)

Well, it's been a while since I created this PR (shame on me), however, rebased it for you so now you can take a look, I'll try my best to finish it this time :)

Hi, it seems there is a conflict on CHANGELOG.md. You don't need to update the CHANGELOG.
Also, there are 152 commits on your branch. Are you sure you want to keep them all?

Closing, because it had no activity for a while


Import the Purdue benchmark data in UniTime

How am I supposed to try the Purdue datasets in Unitime (https://www.unitime.org/uct_datasets.php)? I tried importing in the data exchange page but it just prompts Waiting

The course timetabling benchmark datasets cannot be imported into UniTime. They are in the format that is used by the constraint solver (see here) and only contain the information that is needed by the solver (see here). They are anonymized and do not have enough information -- for example, in UniTime you can set preferences and requirements on different levels, but the solver file only contains a list of available rooms and times for each class with the preferences translated into penalties.
The purpose of these data sets is for other researchers to be able to replicate our results and possibly to use the data sets in their own research, building their own solver algorithms. If you are interested in this, please take a look at the International Timetabling Competition (www.itc2019.org) that we have co-organized.

Thanks so much!
One more question, if I want to use UniTime for the course scheduling problem for my university, should I manually enter the data via the interface?

A lot of the data can be imported using the XML interfaces described at www.unitime.org/uct_interfaces.php.
But it is also possible to enter most of the data through the UniTime user interface (all except students and their course demands or last-like demands -- though, it is possible to build the course timetable without that, using curricula instead).


hw/mcu/dialog: Use 256kHz clock during XTAL32M settling

RC32K was used to wait for XTAL32M to settle.
Unfortunately it's declared frequency range is 25kHz to 39kHz.
XTAL32M settling time was taken into account for CMAC wakeup
calculation but it can be very inaccurate when RC32K is used.
This can result in CMAC crashes due to assert when Cortex-M0
wakes up to late.
This switches to 256kHz clock (derived from RC32M) that is much
mode precise.

@kasjer I've been testing on this for a couple of days and have not seen a CMAC crash.
@andrzej-kaczmarek If this looks good to you, would you approve?


revert E404 to -1 temporarily

There is a lot of dependencies on -1. Will keep it like that for now, until I handle it dependencies cleanly

Moot, #608


Sider收起来时，但是菜单项比较多，支持虚拟滚动

This function solves the problem (这个功能解决的问题)
解决菜单项展示不全的问题
Expected API (期望的 API)
无

This issue does not have any recent activity. If you are still experiencing similar problems, open a new error, including a minimal copy of the problem


merge from template-arlac77-github

.github/workflows/ci.yml

chore(deps): add 20.4.0 remove 20.3.1 (jobs.test-node.strategy.matrix.node-version)

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 98.485%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
61

Relevant Lines:
61

💛  - Coveralls

:tada: This PR is included in version 1.0.4 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Visualization search + likes

During some unrelated QA check @rochoa found that "Search in liked view: results are restricted to liked" did not work as expected.
1.- Search box should also search in your liked datasets/maps (currently it only searches on datasets/maps you own).
2.- If you're in "Liked" tab search should be restricted to liked.
Do you agree, @saleiva?

This happens because of sent URL:
http://central-user-1.localhost.lan:3000/api/v1/viz/?tag_name=&q=Gues&page=1&type=&exclude_shared=false&per_page=9&tags=&shared=yes&locked=null&only_liked=null&order=updated_at&types=derived
Which should sent only_liked=true.
http://central-user-1.localhost.lan:3000/api/v1/viz/?tag_name=&q=Gues&page=1&type=&exclude_shared=false&per_page=9&tags=&shared=yes&locked=null&only_liked=true&order=updated_at&types=derived

No no, search is generic, it searches everywhere, not in the context the user is. And if we want to include liked datasets/maps we will need a new parameter, not only_liked. It should be liked with 3 options, yes, no or only, as we do with shared parameter, for example.

Ok, I'll fix smoke test templates then.


chore(release): 0.18.0

See CHANGELOG

A side-by-side comparison of this PR and the previous 0.18.0 version bump PR (https://github.com/aws/aws-rfdk/pull/159) show the only additional commits are the three fixes:

fix(core): Remove encryption on lifecycle SNS Topic (#163) 5b663ca
fix(integ): fix when PRE_COMPONENT_HOOK is undefined (#166) b4bfd4e
fix(deadline): Disable client SSL config for HTTP Render Queue (#167) fe347fa


Geckolib is no longer working, starting with the first snapshot of 2023.4

Due to the changes made during MCreator, all the functionality does not work.

This issue is invalid as geckolib simply does not support that version yet.


Delayed events in parallel states cannot be reset

Description
Delayed event with after property cannot be reset by a transition if it is in a parallel state.
Expected Result
The timer can be reset in the waiting state by firing the RESET event.
Actual Result
The timer is not reset in the waiting state by firing the RESET event, if it is a parallel state.
Reproduction

XState Visualizer

Additional context
If the otherState state is removed it works as expected. Non-parallel states also work as expected.

Sorry. Is already fixed in 4.7.0-rc5.


Update serialport version

Updated the serialport version dependency to latest stable release to support new NodeJs versions. 3.1.2 shouldn't have API changes as far as I can see.

Thanks!


artisan schedule:test cannot differentiate between scheduled closures

Laravel Version
10.15.0
PHP Version
8.2.7
Database Driver & Version
Not applicable
Description
I have multiple scheduled closures, using $schedule->call(...) in the app/Console/Kernel::schedule() method. When I run php artisan schedule:test, all scheduled closures show up in the task list with the name Callback. No matter which closure-based task index number I input, the first scheduled closure task is run.
It looks to me like this is because the code which chooses a task based on user input bases its task search on the task name that's generated by the schedule:test command, rather than the index number inputted by the user. See here:
https://github.com/laravel/framework/blob/9c44052743b0ee7f3adea36994918b4d8019e8b3/src/Illuminate/Console/Scheduling/ScheduleTestCommand.php#L62-L66
Since all the closure tasks have the same $commandName, $index always ends up being the first closure task.
There's a second part of the problem that I noticed while reading the code: if you run php artisan schedule:test --name Callback with multiple closure-based tasks, you get the message No matching scheduled command found., because there is more than one match found:
https://github.com/laravel/framework/blob/9c44052743b0ee7f3adea36994918b4d8019e8b3/src/Illuminate/Console/Scheduling/ScheduleTestCommand.php#L48-L59
Happy to make a PR for this if that would be welcome. Repro steps below.
Steps To Reproduce
My reproduction repo is here: https://github.com/jlevers/laravel-schedule-test-bug-repro
Note that these two lines are the only thing I added to the base repo produced by laravel new bug-report --github="public":
$schedule->call(fn () => logger()->debug('first callback'))->everyMinute();
$schedule->call(fn () => logger()->debug('second callback'))->everyMinute();

Steps to reproduce:
$ git clone git@github.com:jlevers/laravel-schedule-test-bug-repro.git && cd laravel-schedule-test-bug-repro
$ composer install
$ php artisan schedule:test

  Which command would you like to run?
  Callback ....................................................................................................................................... 0
  Callback ....................................................................................................................................... 1
> 1
  Running [Callback] ...................................................................................................................... 7ms DONE

If you check your logs, you should see local.DEBUG: first callback, even though we selected the index of the second task.
To reproduce the second problem I mentioned:
$ php artisan schedule:test --name Callback

  INFO  No matching scheduled command found

There are in fact two matching commands, so that message is clearly wrong.

Thanks for this detailed issue! Would be cool to get a PR for this with passing tests.

Looks like we won't be making any changes for this sorry. Please use unique names for commands.

Hi @driesvints @taylorotwell
I understand that we can avoid this issue by using unique names for commands like
protected function schedule(Schedule $schedule): void
{
        $schedule->call(fn () => logger()->debug('first callback'))->everyMinute()->name('first command');
        $schedule->call(fn () => logger()->debug('second callback'))->everyMinute()->name('second command');
}

though here are a few inputs from my end on this if you would like to take this into consideration
if you add these two lines in this file \app\Console\Kernel.php
protected function schedule(Schedule $schedule): void
{
        $schedule->call(fn () => logger()->debug('first callback'))->everyMinute();
        $schedule->call(fn () => logger()->debug('second callback'))->everyMinute();
}

the command names will be auto-generated as Callback
because of the below code inside this file - laravel\framework\src\Illuminate\Console\Scheduling\CallbackEvent.php
public function getSummaryForDisplay()
{
        if (is_string($this->description)) {
            return $this->description;
        }
        return is_string($this->callback) ? $this->callback : 'Callback';
}

that function will be triggered from here - laravel\framework\src\Illuminate\Console\Scheduling\ScheduleTestCommand.php
foreach ($commands as $command) {
    $commandNames[] = $command->command ?? $command->getSummaryForDisplay();
}

so the PR I provided above had logic to show a prompt to users stating multiple command names found and which one would they like to run?
also in any case if there are more then one command found with the same name
you get the message "No matching scheduled command found" because there is more than one match found. the message itself could be misleading
would love to know your thoughts on this please
do let me know if any changes are needed in the pull request as well
Thanks

We have no plans to make changes here, sorry. Please use unique names for all commands just like on web routes.


Non-Responsive Button at the tools/generator Page

Describe the bug
Non Responsive Button at the url specified below
How to Reproduce
Steps to reproduce the issue:

Visit this page in mobile

Screenshots

Desktop View
At Top

Mobile View
At Top

At Bottom

Link to GitHub repository with project that has issues
Files that can help reproduce the issue, like your AsyncAPI file, either paste inside the issue in a code block or in a sharable gist

Expected behavior
It is Expected to have Responsive view.
At Top

At Bottom

@sambhavgupta0705 @derberg @akshatnema please review my pull request here

@akshatnema please review this pull request.

relevant issue
fixes https://github.com/asyncapi/website/pull/2464

I already made a pull request for it @sambhavgupta0705


openssl 1.1.1.d  CRYPTO_THREAD_write_lock Program received signal SIGSEGV

[Test Environment]

OS : CentOS 6.7 64bit
linux kernel 2.6.32-573.el6.x86_64
ldd (GNU libc) 2.12
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16)
openssl version 1.1.1d

[Test sequence]

Static build of openssl 1.1.1d
{openssl source}/config
make
libcrypto.a &  libss.a

A segment fault occurs when running program static link.
gcc -g  -Wall -Wno-write-strings -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64  ....... libssl.a   libcrypto.a   ldl -lm -lrt -lpthread

The program is a single-thread program.

lock = 0x0 causes segment fault
Please help me with what's wrong.
#0  0x000000321fe0ac9a in pthread_rwlock_wrlock (lock=0x0) from /lib64/libpthread.so.0
#1  0x0000000000488ce9 in CRYPTO_THREAD_write_lock ()
#2  0x0000000000488d2b in CRYPTO_atomic_add ()
#3  0x0000000000477231 in rand_drbg_get_nonce ()
#4  0x00007ffff1d58dfd in RAND_DRBG_instantiate () from /----.so
#5  0x00007ffff1d59b90 in drbg_setup () from /----.so
#6  0x00007ffff1d59c7b in do_rand_drbg_init_ossl_ () from /----.so
#7  0x000000321fe0cdb3 in pthread_once () from /lib64/libpthread.so.0
#8  0x00007ffff1d85a29 in CRYPTO_THREAD_run_once () from /----.so
#9  0x00007ffff1d59bd4 in RAND_DRBG_get0_private () from /----.so
#10 0x00007ffff1d5a405 in RAND_priv_bytes () from /----.so
#11 0x00007ffff1dcb76a in bnrand () from /----.so
#12 0x00007ffff1dcba16 in bnrand_range () from /----.so
#13 0x00007ffff1dc47ec in BN_BLINDING_create_param () from /----.so
#14 0x00007ffff1d6173e in RSA_setup_blinding () from /----.so
#15 0x00007ffff1d619c9 in RSA_blinding_on () from /----.so
#16 0x00007ffff1beae5e in SZRSA_PublicByteDec (_pSZRSA=0x7fffffffa3f8,

So are you saying you're mixing 2 libcrypto libraries? That is, RAND_DRBG_instantiate() comes from libcrypto.so that you've linked to, and it calls rand_drbg_get_nonce from libcrypto.a, and then things get confused because you have 2 instances of all variables and functions?

So are you saying you're mixing 2 libcrypto libraries? That is, RAND_DRBG_instantiate() comes from libcrypto.so that you've linked to, and it calls rand_drbg_get_nonce from libcrypto.a, and then things get confused because you have 2 instances of all variables and functions?

Use only libssl.a and libcrypto.a.

Try running ldd on your test program.

In any case, in your backtrace you're saying "from /----.so" all the time, which seems to indicate that you do link to libcrypto.so

Try running ldd on your test program.

[root@localhost lib]# ldd SZUpdateCtrl.so
linux-vdso.so.1 =>  (0x00007ffd5999f000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f41d8ecc000)
libm.so.6 => /lib64/libm.so.6 (0x00007f41d8c48000)
librt.so.1 => /lib64/librt.so.1 (0x00007f41d8a3f000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f41d8822000)
libc.so.6 => /lib64/libc.so.6 (0x00007f41d848e000)
/lib64/ld-linux-x86-64.so.2 (0x00005586c4d85000)

That's an .so your test program links to, not your test program itself?

테스트 프로그램 자체가 아니라 테스트 프로그램이 연결되어 있습니까?

SZUpdate  is test program
SZUpdate --->diynmic loading --> SZUpdateCtrl.so(static link with libssl.a & libcrypto.a)
[root@localhost bin]# ldd SZUpdate
linux-vdso.so.1 =>  (0x00007fff7bd86000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f98e9ec4000)
libm.so.6 => /lib64/libm.so.6 (0x00007f98e9c40000)
librt.so.1 => /lib64/librt.so.1 (0x00007f98e9a37000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f98e981a000)
libc.so.6 => /lib64/libc.so.6 (0x00007f98e9486000)
/lib64/ld-linux-x86-64.so.2 (0x000055c1d24d9000)

I currently don't why lock is NULL. In 10, RAND_priv_bytes, we call RAND_get_rand_method(), which should call do_rand_init, which call CRYPTO_THREAD_lock_new(). And only after that we call RAND_DRBG_get0_private(). The locks should all exist.
I assume that in CentOS 7 you don't need that lock because it's using atomics, but before you reached that, it should already have used the other locks.

I think in your main program these symbols are overwriting the
corresponding symbols from the .so:
#1 0x0000000000488ce9 in CRYPTO_THREAD_write_lock ()
#2 0x0000000000488d2b in CRYPTO_atomic_add ()
#3 0x0000000000477231 in rand_drbg_get_nonce ()
I think a symbol from the .so will only be used when the application
is not already providing that, it may depend on the OS in a way,
for instance if the app is linked as -pie executable.
I think you should not link a static libcrypto in a .so.  better use
openssl as a shared object, that is a supported configuration.

The problem has been resolved. Thank you for your answers.
SZUpdate : Main execution program static link to libssl.a + libcrypto.a)
SZUpdateCtrl.so : Use dynamic loading from SZUpdate(static link to libssl.a + libcrypro.a)

I removed libssl.a and libcrypto.a from SZUpdate.exe
The problem has been resolved.

I am having the same problem with a slightly different configuration on Debian 10 (Buster)/64bit: An executable is linked against the shared objects -ldl and -lpthread. Anything else is static, i.e. libcrypto.a, libssl.a, and libz.a. The static libraries are linked with GNU ld 'whole archive' option, i.e.:
-Wl,--whole-archive libcrypto.a libssl.a libz.a -Wl,--no-whole-archive
I have a second configuration that links everything dynamically and works just fine. The above mentioned static configuration yields a SIGSEGV (according to gdb and the core file):
#0  __pthread_rwlock_wrlock_full (abstime=0x0, rwlock=0x0) at pthread_rwlock_common.c:576
#1  __GI___pthread_rwlock_wrlock (rwlock=0x0) at pthread_rwlock_wrlock.c:27
#2  0x00000000005b750d in CRYPTO_THREAD_write_lock (lock=0x0) at crypto/threads_pthread.c:78
#3  0x000000000050c0b8 in ENGINE_finish (e=0x11b7ab0) at crypto/engine/eng_init.c:101
The line numbers come from OpenSSL 1.1.1i.
The program loads the builtin RAND engine to enable the CPU hardware random stuff. That's why ENGINE_finish gets called.
Any ideas? Thanks.

How do you configure your static openssl ?

Quite straightforward:
./config no-rc4 no-rc5 no-idea no-md2 no-md4 no-mdc2 zlib no-shared --debug
(--release for the release build); I just kicked old algorithms or algorithms with license issues out, respectively. "make && make test" ran without any problems but I doubt that this special engine issue is covered by the OpenSSL tests.
Btw, the same stuff is built on Windows 10/64bit as well. Of course, there is no POSIX thread stuff in it, and this works either statically or dynamically without problem. Only the above mentioned CRYPTO_THREAD_write_lock (using POSIX semantics) does fail in the static case.
I have attribute((constructor)) (and destructor) in another static library, which initializes OpenSSL or performs the cleanup, respectively. So the problem occurs AFTER main (of the test program in my case) was left. So this is in destructor call -> OpenSSL cleanup -> ENGINE_finish -> CRYPTO_THREAD_write_lock.
Another strange thing: If I execute the identical thing using valgrind (which heavily patches libc pointers, I know), then valgrind DOES NOT complain about any SIGSEGV and reports no memory leaks and no strange/bad accesses.
This is completely beyond me...
Thanks in advance.

My guess is that an incompatible engine is loaded into your process with the static libcrypto,
because you have provided a call stack with ENGINE_finish (e=0x11b7ab0).
Try to build with no-pic no-dso instead of no-shared, does that work better?

I have met the same problem with the  call stack below, anyone
(gdb) bt
#0  __pthread_rwlock_wrlock_full (abstime=0x0, clockid=0, rwlock=0x0) at pthread_rwlock_common.c:604
#1  __GI___pthread_rwlock_wrlock (rwlock=0x0) at pthread_rwlock_wrlock.c:27
#2  0xb68a21fc in CRYPTO_THREAD_write_lock () from /usr/lib/libcrypto.so.1.1
#3  0xb687b618 in RAND_get_rand_method () from /usr/lib/libcrypto.so.1.1
#4  0xb687b944 in RAND_priv_bytes () from /usr/lib/libcrypto.so.1.1
#5  0xb6dae810 in vos_get_random_array () from /opt/pme/lib/libcommon.so.0
#6  0xb6713db8 in kmc_get_random_number (buff=<optimized out>, buffLen=<optimized out>) at /home/workspace/V2R2_trunk/application/src/libs/kmc/src/kmc_callbacks.c:654
#7  0xb66f66b4 in CacRandom (buff=buff@entry=0xb672a284 <g_maskCode>, buffLen=buffLen@entry=256) at /home/workspace/V2R2_trunk/platforms/kmc/src/cac/cacv2_openssl.c:494
#8  0xb670c658 in InitMaskCode () at /home/workspace/V2R2_trunk/platforms/kmc/src/mip/other/maskinfo_other.c:24
#9  0xb67073c8 in MemRefreshMkMaskEx () at /home/workspace/V2R2_trunk/platforms/kmc/src/kmc/kmcv2_ksm.c:1138
#10 0xb66ff00c in KmcRefreshMkMaskEx () at /home/workspace/V2R2_trunk/platforms/kmc/src/kmc/kmcv2_itf.c:1209
#11 0xb67155c4 in kmc_check_if_ksf_available (ksf_name=0x36ee80) at /home/workspace/V2R2_trunk/application/src/libs/kmc/src/kmc_common.c:175
#12 0xb5577860 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Fix for this in #14603


FIX-#5977: use wrapper.materialize instead of wait_partitions

What do these changes do?

[x] first commit message and PR title follow format outlined here

NOTE:  If you edit the PR title to match this format, you need to add another commit (even if it's empty) or amend your last commit for the CI job that checks the PR title to pick up the new PR title.

[x] passes flake8 modin/ asv_bench/benchmarks scripts/doc_checker.py
[x] passes black --check modin/ asv_bench/benchmarks scripts/doc_checker.py
[x] signed commit with git commit -s
[x] Resolves #5977
[ ] tests added and passing
[x] module layout described at docs/development/architecture.rst is up-to-date

@anmyachev could you confirm that this fixes the issue by running the push-to-main to trigger on changes to your branch? I missed that test-ray-client was the test that was failing when I made my "fix".

@pyrito I see botocore.exceptions.NoCredentialsError: Unable to locate  in https://github.com/modin-project/modin/actions/runs/4671549630/jobs/8272679284?pr=5982

@anmyachev I think I figured it out. If you take a look at how we initialize Ray normally here: https://github.com/modin-project/modin/blob/master/modin/core/execution/ray/common/utils.py#L81-L88, you can see that we actually do pass in the mock keys to Ray init. We initialize the Ray client differently on CI: https://github.com/modin-project/modin/blob/master/modin/conftest.py#L587-L591. My guess is that we need to pass in these env variables through here as well.

@anmyachev I think I figured it out. If you take a look at how we initialize Ray normally here: https://github.com/modin-project/modin/blob/master/modin/core/execution/ray/common/utils.py#L81-L88, you can see that we actually do pass in the mock keys to Ray init. We initialize the Ray client differently on CI: https://github.com/modin-project/modin/blob/master/modin/conftest.py#L587-L591. My guess is that we need to pass in these env variables through here as well.

@pyrito good catch! Let's try.

@anmyachev please see here: https://github.com/modin-project/modin/pull/5984/commits/464185f91f50267a3336685cfd20581be2cdb30b


Request: XFadeFilter implementation

Would like to request an XFadeFilter implementation
https://superuser.com/questions/1683630/timebase-error-while-giving-effect-using-ffmpeg

Not nuget now, but you can copy to your source

Thank you, please let me know when the update is in nuget.

Not nuget now, but you can copy to your source
hi, are the changes in Nuget?

Just add this code to your project, use as extension.
For nuget, wait until large change.
I've been busy lately

Not a problem at all. I can wait, thank you!

Just add this code to your project, use as extension. For nuget, wait until large change. I've been busy lately

Not a problem at all, i can wait, thank you!

FFmpegArgs.Filters 1.4.3 is on nuget now

FFmpegArgs.Filters 1.4.3 is on nuget now

Thank you!


No In App updates until app killed and relaunched

Description
I integrated the SDK (pretty simple setup) and included the Distribute module. I do get in-app updates, but only after killing the initial build running app center sdk on the device and relaunching.
The iOS SDK does do this properly, as did our previous Android Hockeyapp SDK powered app.
Repro Steps
Please list the steps used to reproduce your issue.

push up a test build to app center
install that build on device; launch it to setup in-app updates
push up another build with incremented bundle and version
expect in app update prompt, but none. background the app, then foreground it — still no in app update
kill app; launch again. Now we see the in-app update prompt.

Details

Which SDK version are you using?
2.5.0
Which OS version did you experience the issue on?
-Android 9
What device version did you see this error on?  Were you using an emulator or a physical device?
Samsung Galaxy S8
What third party libraries are you using?
This is a React Native app if that makes any difference. The RN SDK didn't have support Distribute/in-app-update support, so went native SDK
I have done just that but would like to pass this along privately as there may be sensitive info there.

The team just took up this feature today. I will share an update once the feature nears completion.

Closing this as the the feature branch of this one has been merged. Feel free to reopen it for any follow-up questions.


DHE-643 Create service deliveries models

Codecov Report

:exclamation: No coverage uploaded for pull request head (dhe-643-service-deliveries-model@f6448f7).

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 e841368...f6448f7. Read the comment docs.

Can one of the admins verify this patch?


[react_native_pods.rb] Introduce a reusable resolve_node_module function

Summary:
The React Native project and its related packages ship Ruby code, through packages published on NPM.
To successfully resolve the path of these "node modules", the project has historically made assumptions on the relative location of these packages. This however breaks down in the context of modern package managers and features such as NPM / Yarn workspaces, since packages may be (partially) hoisted to a parent / root package.
In recent times we've made changes to some of these Ruby files that makes it easier to consume in a hoisted environment: https://github.com/facebook/react-native/pull/36485
I suggest we generalise this by introducing a function, which the other scripts, developers apps and library authors can rely on to successfully resolve a path using the node modules resolution algorithm.
As an alternative, I've considered adding this as a function on the ReactNativePodsUtils module, but I felt this is such a versatile helper that it should be globally available. I'd be happy to change this if deemed necessary.
I'd love to follow up with additional PRs, introducing use of this utility function in more of the Ruby files of the project and related packages.
Changelog:
[IOS] [ADDED] - Add a resolve_node_module function to the react_native_pods.rb script, which will call Node.js to resolve a module path using the node modules resolution algorithm.
Test Plan:
I've made the change locally and tested that the bundle exec pod install command works as expected and verified that the resolve_node_module is available and works as expected from the .podspec of a library that has been installed into the React Native app that I'm testing with.

It looks like main diverged too much for this to be relevant, although I still see lots of ../node_modules in the files (which doesn't embrace the node modules resolution algorithm). What do you think @robhogan? You were also cooking something in this area if I remember correctly.


Expand() usage does not pickup .output if task with expand comes before in yaml def/dict keys of task referenced in expand

If you have something like
Tasks:
   Task1:
      ...
      Dependencies: [Task2]
      Expand:
         Some_arg: Task2.output

   Task2:
      ...

Then when dagbuilder parses the tank/duct is does not properly change the expand arg to a referenced Xcom and it remains as a are

Thanks a lot for reporting this issue, @StephenOTT ! Would you be willing to contribute a fix? We should add an example DAG that leverages this so we can avoid regressions, once we fix this.


led-base-16384 summary results

Hello, I’m trying to use LED for long document summarization. That said, I tried: pip installing the Longformer repo, following LED’s summarization.py 1 and downloading the led-base-16384 pretrained model. I noticed that it referenced arxiv articles so my input_data below is one of those articles. However, after running the snippet below:
import logging
import json
import os
import pandas as pd
import torch
from longformer import LongformerEncoderDecoderConfig,LongformerEncoderDecoderForConditionalGeneration
from longformer.sliding_chunks import pad_to_window_size
from transformers import LongformerTokenizer

logger = logging.getLogger(__name__)

ATTENTION_WINDOW = 512
ATTENTION_MODE = 'sliding_chunks'
DROPOUT = 0.1
SMOOTHING = 0.0
MODEL_PATH = 'longformer-encdec-base-16384/'

def _prepare_input(input_ids):
    attention_mask = torch.ones(input_ids.shape, dtype=torch.long, device=input_ids.device)
    attention_mask[input_ids == tokenizer.pad_token_id] = 0
    if isinstance(model, LongformerEncoderDecoderForConditionalGeneration):
        attention_mask[:, 0] = 2  # global attention on one token for all model params to be used, which is important for gradient checkpointing to work
        if config.attention_mode == 'sliding_chunks':
            half_padding_mod = model.config.attention_window[0]
        elif config.attention_mode == 'sliding_chunks_no_overlap':
            half_padding_mod = model.config.attention_window[0] / 2
        else:
            raise NotImplementedError
        input_ids, attention_mask = pad_to_window_size(  # ideally, should be moved inside the LongformerModel
            input_ids, attention_mask, half_padding_mod, tokenizer.pad_token_id)
    return input_ids, attention_mask

if __name__ == "__main__":
    device = torch.device('cpu')
    logger.info('load data')
    input_data = """
    'additive models @xcite provide an important family of models for semiparametric regression or classification . some reasons for the success of additive models are their increased flexibility when compared to linear or generalized linear models and their increased interpretability when compared to fully nonparametric models .it is well - known that good estimators in additive models are in general less prone to the curse of high dimensionality than good estimators in fully nonparametric models .many examples of such estimators belong to the large class of regularized kernel based methods over a reproducing kernel hilbert space @xmath0 , see e.g. @xcite . in the last yearsmany interesting results on learning rates of regularized kernel based models for additive models have been published when the focus is on sparsity and when the classical least squares loss function is used , see e.g. @xcite , @xcite , @xcite , @xcite , @xcite , @xcite and the references therein . of course , the least squares loss function is differentiable and has many nice mathematical properties , but it is only locally lipschitz continuous and therefore regularized kernel based methods based on this loss function typically suffer on bad statistical robustness properties , even if the kernel is bounded .this is in sharp contrast to kernel methods based on a lipschitz continuous loss function and on a bounded loss function , where results on upper bounds for the maxbias bias and on a bounded influence function are known , see e.g. @xcite for the general case and @xcite for additive models .therefore , we will here consider the case of regularized kernel based methods based on a general convex and lipschitz continuous loss function , on a general kernel , and on the classical regularizing term @xmath1 for some @xmath2 which is a smoothness penalty but not a sparsity penalty , see e.g. @xcite .such regularized kernel based methods are now often called support vector machines ( svms ) , although the notation was historically used for such methods based on the special hinge loss function and for special kernels only , we refer to @xcite .    in this paper we address the open question , whether an svm with an additive kernel can provide a substantially better learning rate in high dimensions than an svm with a general kernel , say a classical gaussian rbf kernel , if the assumption of an additive model is satisfied .our leading example covers learning rates for quantile regression based on the lipschitz continuous but non - differentiable pinball loss function , which is also called check function in the literature , see e.g. @xcite and @xcite for parametric quantile regression and @xcite , @xcite , and @xcite for kernel based quantile regression .we will not address the question how to check whether the assumption of an additive model is satisfied because this would be a topic of a paper of its own .of course , a practical approach might be to fit both models and compare their risks evaluated for test data .for the same reason we will also not cover sparsity .consistency of support vector machines generated by additive kernels for additive models was considered in @xcite . in this paperwe establish learning rates for these algorithms .let us recall the framework with a complete separable metric space @xmath3 as the input space and a closed subset @xmath4 of @xmath5 as the output space .a borel probability measure @xmath6 on @xmath7 is used to model the learning problem and an independent and identically distributed sample @xmath8 is drawn according to @xmath6 for learning .a loss function @xmath9 is used to measure the quality of a prediction function @xmath10 by the local error @xmath11 ._ throughout the paper we assume that @xmath12 is measurable , @xmath13 , convex with respect to the third variable , and uniformly lipschitz continuous satisfying @xmath14 with a finite constant @xmath15 ._    support vector machines ( svms ) considered here are kernel - based regularization schemes in a reproducing kernel hilbert space ( rkhs ) @xmath0 generated by a mercer kernel @xmath16 . with a shifted loss function @xmath17 introduced for dealingeven with heavy - tailed distributions as @xmath18 , they take the form @xmath19 where for a general borel measure @xmath20 on @xmath21 , the function @xmath22 is defined by @xmath23 where @xmath24 is a regularization parameter .the idea to shift a loss function has a long history , see e.g. @xcite in the context of m - estimators .it was shown in @xcite that @xmath22 is also a minimizer of the following optimization problem involving the original loss function @xmath12 if a minimizer exists : @xmath25    the additive model we consider consists of the _ input space decomposition _@xmath26 with each @xmath27 a complete separable metric space and a _ hypothesis space _@xmath28 where @xmath29 is a set of functions @xmath30 each of which is also identified as a map @xmath31 from @xmath3 to @xmath5 .hence the functions from @xmath32 take the additive form @xmath33 .we mention , that there is strictly speaking a notational problem here , because in the previous formula each quantity @xmath34 is an element of the set @xmath35 which is a subset of the full input space @xmath36 , @xmath37 , whereas in the definition of sample @xmath8 each quantity @xmath38 is an element of the full input space @xmath36 , where @xmath39 .because these notations will only be used in different places and because we do not expect any misunderstandings , we think this notation is easier and more intuitive than specifying these quantities with different symbols .the additive kernel @xmath40 is defined in terms of mercer kernels @xmath41 on @xmath27 as @xmath42 it generates an rkhs @xmath0 which can be written in terms of the rkhs @xmath43 generated by @xmath41 on @xmath27 corresponding to the form ( [ additive ] ) as @xmath44 with norm given by @xmath45 the norm of @xmath46 satisfies @xmath47    to illustrate advantages of additive models , we provide two examples of comparing additive with product kernels .the first example deals with gaussian rbf kernels .all proofs will be given in section [ proofsection ] .[ gaussadd ] let @xmath48 , @xmath49 $ ] and @xmath50 ^ 2.$ ] let @xmath51 and @xmath52.\\ ] ] the additive kernel @xmath53 is given by @xmath54 furthermore , the product kernel @xmath55 is the standard gaussian kernel given by @xmath56 define a gaussian function @xmath57 on @xmath58 ^ 2 $ ] depending only on one variable by @xmath59 then @xmath60 but @xmath61 where @xmath62 denotes the rkhs generated by the standard gaussian rbf kernel @xmath63 .the second example is about sobolev kernels .[ sobolvadd ] let @xmath64 , @xmath65 $ ] and @xmath58^s.$ ] let @xmath66 : = \\bigl\\{u\\in l_2([0,1 ] ) ; d^\\alpha u \\in l_2([0,1 ] ) \\mbox{~for~all~}|\\alpha|\\le 1\\bigr\\}\\ ] ] be the sobolev space consisting of all square integrable univariate functions whose derivative is also square integrable .it is an rkhs with a mercer kernel @xmath67 defined on @xmath68 ^ 2 $ ] .if we take all the mercer kernels @xmath69 to be @xmath67 , then @xmath70 $ ] for each @xmath71 .the additive kernel @xmath72 is also a mercer kernel and defines an rkhs @xmath73\\right\\}.\\ ] ] however , the multivariate sobolev space @xmath74^s)$ ] , consisting of all square integrable functions whose partial derivatives are all square integrable , contains discontinuous functions and is not an rkhs .denote the marginal distribution of @xmath6 on @xmath27 as @xmath75 . under the assumption that @xmath76 for each @xmath71 and that @xmath43 is dense in @xmath29 in the @xmath77-metric , it was proved in @xcite that @xmath78 in probability as long as @xmath79 satisfies @xmath80 and @xmath81 .the rest of the paper has the following structure .section [ ratessection ] contains our main results on learning rates for svms based on additive kernels . learning rates for quantile regressionare treated as important special cases .section [ comparisonsection ] contains a comparison of our results with other learning rates published recently .section [ proofsection ] contains all the proofs and some results which can be interesting in their own .in this paper we provide some learning rates for the support vector machines generated by additive kernels for additive models which helps improve the quantitative understanding presented in @xcite .the rates are about asymptotic behaviors of the excess risk @xmath82 and take the form @xmath83 with @xmath84 .they will be stated under three kinds of conditions involving the hypothesis space @xmath0 , the measure @xmath6 , the loss @xmath12 , and the choice of the regularization parameter @xmath85 .the first condition is about the approximation ability of the hypothesis space @xmath0 .since the output function @xmath19 is from the hypothesis space , the learning rates of the learning algorithm depend on the approximation ability of the hypothesis space @xmath0 with respect to the optimal risk @xmath86 measured by the following approximation error .[ defapprox ] the approximation error of the triple @xmath87 is defined as @xmath88    to estimate the approximation error , we make an assumption about the minimizer of the risk @xmath89    for each @xmath90 , define the integral operator @xmath91 associated with the kernel @xmath41 by @xmath92 we mention that @xmath93 is a compact and positive operator on @xmath94 . hence we can find its normalized eigenpairs @xmath95 such that @xmath96 is an orthonormal basis of @xmath94 and @xmath97 as @xmath98 . fix @xmath99 .then we can define the @xmath100-th power @xmath101 of @xmath93 by @xmath102 this is a positive and bounded operator and its range is well - defined .the assumption @xmath103 means @xmath104 lies in this range .[ assumption1 ] we assume @xmath105 and @xmath106 where for some @xmath107 and each @xmath108 , @xmath109 is a function of the form @xmath110 with some @xmath111 .the case @xmath112 of assumption [ assumption1 ] means each @xmath113 lies in the rkhs @xmath43 .a standard condition in the literature ( e.g. , @xcite ) for achieving decays of the form @xmath114 for the approximation error ( [ approxerrordef ] ) is @xmath115 with some @xmath116 . herethe operator @xmath117 is defined by @xmath118 in general , this can not be written in an additive form .however , the hypothesis space ( [ additive ] ) takes an additive form @xmath119 .so it is natural for us to impose an additive expression @xmath120 for the target function @xmath121 with the component functions @xmath113 satisfying the power condition @xmath110 .the above natural assumption leads to a technical difficulty in estimating the approximation error : the function @xmath113 has no direct connection to the marginal distribution @xmath122 projected onto @xmath27 , hence existing methods in the literature ( e.g. , @xcite ) can not be applied directly .note that on the product space @xmath123 , there is no natural probability measure projected from @xmath6 , and the risk on @xmath124 is not defined .    our idea to overcome the difficulty is to introduce an intermediate function @xmath125 .it may not minimize a risk ( which is not even defined ) .however , it approximates the component function @xmath113 well .when we add up such functions @xmath126 , we get a good approximation of the target function @xmath121 , and thereby a good estimate of the approximation error .this is the first novelty of the paper .[ approxerrorthm ] under assumption [ assumption1 ] , we have @xmath127 where @xmath128 is the constant given by @xmath129      the second condition for our learning rates is about the capacity of the hypothesis space measured by @xmath130-empirical covering numbers .    let @xmath131 be a set of functions on @xmath21 and @xmath132 for every @xmath133 the * covering number of @xmath131 * with respect to the empirical metric @xmath134 , given by @xmath135 is defined as @xmath136 and the * @xmath130-empirical covering number * of @xmath137 is defined as @xmath138    [ assumption2 ] we assume @xmath139 and that for some @xmath140 , @xmath141 and every @xmath142 , the @xmath130-empirical covering number of the unit ball of @xmath43 satisfies @xmath143    the second novelty of this paper is to observe that the additive nature of the hypothesis space yields the following nice bound with a dimension - independent power exponent for the covering numbers of the balls of the hypothesis space @xmath0 , to be proved in section [ samplesection ] .[ capacitythm ] under assumption [ assumption2 ] , for any @xmath144 and @xmath145 , we have @xmath146    the bound for the covering numbers stated in theorem [ capacitythm ] is special : the power @xmath147 is independent of the number @xmath148 of the components in the additive model .it is well - known @xcite in the literature of function spaces that the covering numbers of balls of the sobolev space @xmath149 on the cube @xmath150^s$ ] of the euclidean space @xmath151 with regularity index @xmath152 has the following asymptotic behavior with @xmath153 : @xmath154 here the power @xmath155 depends linearly on the dimension @xmath148 .similar dimension - dependent bounds for the covering numbers of the rkhss associated with gaussian rbf - kernels can be found in @xcite .the special bound in theorem [ capacitythm ] demonstrates an advantage of the additive model in terms of capacity of the additive hypothesis space .the third condition for our learning rates is about the noise level in the measure @xmath6 with respect to the hypothesis space . before stating the general condition, we consider a special case for quantile regression , to illustrate our general results .let @xmath156 be a quantile parameter .the quantile regression function @xmath157 is defined by its value @xmath158 to be a @xmath159-quantile of @xmath160 , i.e. , a value @xmath161 satisfying @xmath162 the regularization scheme for quantile regression considered here takes the form ( [ algor ] ) with the loss function @xmath12 given by the pinball loss as @xmath163    a noise condition on @xmath6 for quantile regression is defined in @xcite as follows . to this end , let @xmath164 be a probability measure on @xmath165 and @xmath166 . then a real number @xmath167 is called @xmath159-quantile of @xmath164 , if and only if @xmath167 belongs to the set @xmath168\\bigr ) \\ge\\tau     \\mbox{~~and~~ } q\\bigl([t , \\infty)\\bigr ) \\ge 1-\\tau\\bigr\\}\\,.\\ ] ] it is well - known that @xmath169 is a compact interval .[ noisecond ] let @xmath166 .    1 .a probability measure @xmath164 on @xmath165 is said to have a * @xmath159-quantile of type @xmath170 * , if there exist a @xmath159-quantile @xmath171 and a constant @xmath172 such that , for all @xmath173 $ ] , we have @xmath174 2 .let @xmath175 $ ] .we say that a probability measure @xmath20 on @xmath176 has a * @xmath159-quantile of @xmath177-average type @xmath170 * if the conditional probability measure @xmath178 has @xmath179-almost surely a @xmath159-quantile of type @xmath170 and the function @xmath180 where @xmath181 is the constant defined in part ( 1 ) , satisfies @xmath182 .one can show that a distribution @xmath164 having a @xmath159-quantile of type @xmath170 has a unique @xmath159-quantile @xmath183 .moreover , if @xmath164 has a lebesgue density @xmath184 then @xmath164 has a @xmath159-quantile of type @xmath170 if @xmath184 is bounded away from zero on @xmath185 $ ] since we can use @xmath186\\}$ ] in ( [ tauquantileoftype2formula ] ) .this assumption is general enough to cover many distributions used in parametric statistics such as gaussian , student s @xmath187 , and logistic distributions ( with @xmath188 ) , gamma and log - normal distributions ( with @xmath189 ) , and uniform and beta distributions ( with @xmath190 $ ] ) .the following theorem , to be proved in section [ proofsection ] , gives a learning rate for the regularization scheme ( [ algor ] ) in the special case of quantile regression .[ quantilethm ] suppose that @xmath191 almost surely for some constant @xmath192 , and that each kernel @xmath41 is @xmath193 with @xmath194 for some @xmath195 .if assumption [ assumption1 ] holds with @xmath112 and @xmath6 has a @xmath159-quantile of @xmath177-average type @xmath170 for some @xmath196 $ ] , then by taking @xmath197 , for any @xmath198 and @xmath199 , with confidence at least @xmath200 we have @xmath201 where @xmath202 is a constant independent of @xmath203 and @xmath204 and @xmath205    please note that the exponent @xmath206 given by ( [ quantilerates2 ] ) for the learning rate in ( [ quantilerates ] ) is independent of the quantile level @xmath159 , of the number @xmath148 of additive components in @xmath207 , and of the dimensions @xmath208 and @xmath209 further note that @xmath210 , if @xmath211 , and @xmath212 if @xmath213 . because @xmath214 can be arbitrarily close to @xmath215 , the learning rate , which is independent of the dimension @xmath216 and given by theorem [ quantilethm ] , is close to @xmath217 for large values of @xmath177 and is close to @xmath218 or better , if @xmath211 .      to state our general learning rates, we need an assumption on a _ variance - expectation bound _ which is similar to definition [ noisecond ] in the special case of quantile regression .[ assumption3 ] we assume that there exist an exponent @xmath219 $ ] and a positive constant @xmath220 such that @xmath221    assumption [ assumption3 ] always holds true for @xmath222 . if the triple @xmath223 satisfies some conditions , the exponent @xmath224 can be larger .for example , when @xmath12 is the pinball loss ( [ pinloss ] ) and @xmath6 has a @xmath159-quantile of @xmath177-average type @xmath225 for some @xmath196 $ ] and @xmath226 as defined in @xcite , then @xmath227 .[ mainratesthm ] suppose that @xmath228 is bounded by a constant @xmath229 almost surely . under assumptions [ assumption1 ] to [ assumption3 ] ,if we take @xmath198 and @xmath230 for some @xmath231 , then for any @xmath232 , with confidence at least @xmath200 we have @xmath233 where @xmath234 is given by @xmath235 and @xmath202 is constant independent of @xmath203 or @xmath204 ( to be given explicitly in the proof ) .we now add some theoretical and numerical comparisons on the goodness of our learning rates with those from the literature . as already mentioned in the introduction, some reasons for the popularity of additive models are flexibility , increased interpretability , and ( often ) a reduced proneness of the curse of high dimensions .hence it is important to check , whether the learning rate given in theorem [ mainratesthm ] under the assumption of an additive model favourably compares to ( essentially ) optimal learning rates without this assumption . in other words ,we need to demonstrate that the main goal of this paper is achieved by theorem [ quantilethm ] and theorem [ mainratesthm ] , i.e. that an svm based on an additive kernel can provide a substantially better learning rate in high dimensions than an svm with a general kernel , say a classical gaussian rbf kernel , provided the assumption of an additive model is satisfied .our learning rate in theorem [ quantilethm ] is new and optimal in the literature of svm for quantile regression .most learning rates in the literature of svm for quantile regression are given for projected output functions @xmath236 , while it is well known that projections improve learning rates @xcite . here the projection operator @xmath237 is defined for any measurable function @xmath10 by @xmath238 sometimes this is called clipping .such results are given in @xcite .for example , under the assumptions that @xmath6 has a @xmath159-quantile of @xmath177-average type @xmath170 , the approximation error condition ( [ approxerrorb ] ) is satisfied for some @xmath239 , and that for some constants @xmath240 , the sequence of eigenvalues @xmath241 of the integral operator @xmath117 satisfies @xmath242 for every @xmath243 , it was shown in @xcite that with confidence at least @xmath200 , @xmath244 where @xmath245 here the parameter @xmath246 measures the capacity of the rkhs @xmath247 and it plays a similar role as half of the parameter @xmath147 in assumption 2 . for a @xmath193 kernel and @xmath112, one can choose @xmath246 and @xmath147 to be arbitrarily small and the above power index @xmath248 can be taken as @xmath249 .the learning rate in theorem [ quantilethm ] may be improved by relaxing assumption 1 to a sobolev smoothness condition for @xmath121 and a regularity condition for the marginal distribution @xmath250 .for example , one may use a gaussian kernel @xmath251 depending on the sample size @xmath203 and @xcite achieve the approximation error condition ( [ approxerrorb ] ) for some @xmath252 .this is done for quantile regression in @xcite .since we are mainly interested in additive models , we shall not discuss such an extension .[ gaussmore ] let @xmath48 , @xmath49 $ ] and @xmath50 ^ 2.$ ] let @xmath51 and the additive kernel @xmath72 be given by ( [ gaussaddform ] ) with @xmath253 in example [ gaussadd ] as @xmath52.\\ ] ] if the function @xmath121 is given by ( [ gaussfcn ] ) , @xmath191 almost surely for some constant @xmath192 , and @xmath6 has a @xmath159-quantile of @xmath177-average type @xmath170 for some @xmath196 $ ] , then by taking @xmath197 , for any @xmath145 and @xmath199 , ( [ quantilerates ] ) holds with confidence at least @xmath200 .    it is unknown whether the above learning rate can be derived by existing approaches in the literature ( e.g. @xcite ) even after projection .note that the kernel in the above example is independent of the sample size .it would be interesting to see whether there exists some @xmath99 such that the function @xmath57 defined by ( [ gaussfcn ] ) lies in the range of the operator @xmath254 .the existence of such a positive index would lead to the approximation error condition ( [ approxerrorb ] ) , see @xcite .    let us now add some numerical comparisons on the goodness of our learning rates given by theorem [ mainratesthm ] with those given by @xcite .their corollary 4.12 gives ( essentially ) minmax optimal learning rates for ( clipped ) svms in the context of nonparametric quantile regression using one gaussian rbf kernel on the whole input space under appropriate smoothness assumptions of the target function .let us consider the case that the distribution @xmath6 has a @xmath159-quantile of @xmath177-average type @xmath170 , where @xmath255 , and assume that both corollary 4.12 in @xcite and our theorem [ mainratesthm ] are applicable .i.e. , we assume in particular that @xmath6 is a probability measure on @xmath256 $ ] and that the marginal distribution @xmath257 has a lebesgue density @xmath258 for some @xmath259 . furthermore , suppose that the optimal decision function @xmath260 has ( to make theorem [ mainratesthm ] applicable with @xmath261 $ ] ) the additive structure @xmath207 with each @xmath104 as stated in assumption [ assumption1 ] , where @xmath262 and @xmath263 , with minimal risk @xmath86 and additionally fulfills ( to make corollary 4.12 in @xcite applicable ) @xmath264 where @xmath265 $ ] and @xmath266 denotes a besov space with smoothness parameter @xmath267 .the intuitive meaning of @xmath248 is , that increasing values of @xmath248 correspond to increased smoothness .we refer to ( * ? ? ? * and p. 44 ) for details on besov spaces .it is well - known that the besov space @xmath268 contains the sobolev space @xmath269 for @xmath270 , @xmath271 , and @xmath272 , and that @xmath273 .we mention that if all @xmath41 are suitably chosen wendland kernels , their reproducing kernel hilbert spaces @xmath43 are sobolev spaces , see ( * ? ? ?* thm . 10.35 , p. 160 ) .furthermore , we use the same sequence of regularizing parameters as in ( * ? ? ?4.9 , cor . 4.12 ) , i.e. , @xmath274 where @xmath275 , @xmath276 , @xmath277 $ ] , and @xmath278 is some user - defined positive constant independent of @xmath279 . forreasons of simplicity , let us fix @xmath280 .then ( * ? ? ?4.12 ) gives learning rates for the risk of svms for @xmath159-quantile regression , if a single gaussian rbf - kernel on @xmath281 is used for @xmath159-quantile functions of @xmath177-average type @xmath170 with @xmath255 , which are of order @xmath282 hence the learning rate in theorem [ quantilethm ] is better than the one in ( * ? ? ?4.12 ) in this situation , if @xmath283 provided the assumption of the additive model is valid .table [ table1 ] lists the values of @xmath284 from ( [ explicitratescz2 ] ) for some finite values of the dimension @xmath216 , where @xmath285 .all of these values of @xmath284 are positive with the exceptions if @xmath286 or @xmath287 .this is in contrast to the corresponding exponent in the learning rate by ( * ? ?* cor . 4.12 ) , because @xmath288    table [ table2 ] and figures [ figure1 ] to [ figure2 ] give additional information on the limit @xmath289 .of course , higher values of the exponent indicates faster rates of convergence .it is obvious , that an svm based on an additive kernel has a significantly faster rate of convergence in higher dimensions @xmath216 compared to svm based on a single gaussian rbf kernel defined on the whole input space , of course under the assumption that the additive model is valid .the figures seem to indicate that our learning rate from theorem [ mainratesthm ] is probably not optimal for small dimensions . however , the main focus of the present paper is on high dimensions ..[table1 ] the table lists the limits of the exponents @xmath290 from ( * ? ? ?* cor . 4.12 ) and @xmath291 from theorem [ mainratesthm ] , respectively , if the regularizing parameter @xmath292 is chosen in an optimal manner for the nonparametric setup , i.e. @xmath293 , with @xmath294 for @xmath295 and @xmath296 .recall that @xmath297 $ ] .[ cols= " > , > , > , > " , ]'

    """

    logger.info('define model and model parameters')
    label_smoothing = SMOOTHING
    tokenizer = LongformerTokenizer.from_pretrained(MODEL_PATH,use_fast=True)

    config = LongformerEncoderDecoderConfig.from_pretrained(MODEL_PATH)
    config.attention_dropout = DROPOUT
    # config.gradient_checkpointing = grad_ckpt
    config.attention_mode = ATTENTION_MODE
    config.attention_window = [ATTENTION_WINDOW] * config.encoder_layers

    #longformer-encdec-base-16384/
    model = LongformerEncoderDecoderForConditionalGeneration.from_pretrained(MODEL_PATH, config=config)

    logger.info('tokenize/encode input summary')
    input_ids = tokenizer.encode(input_data, return_tensors="pt").to(device)
    logger.info('get attention mask')
    input_ids, attention_mask = _prepare_input(input_ids)
    logger.info('summarizing article...')
    summary_ids =  model.generate(input_ids=input_ids, attention_mask=attention_mask,
                                                use_cache=True,
                                                num_beams=4,
                                                min_length=200,
                                                max_length=300,
                                 )
    print(tokenizer.batch_decode(summary_ids.tolist(), skip_special_tokens=True))

It ends up generating the following summary which doesn't seem to make sense
[' [ [ ] we have @xmath6, @xmath6, @xmath6, @xmath6, @xmath6, and @xmath6, @xmath6, @xmath6, @xmath6, and @xmath6, @xmath6, and @xmath6, respectively. we have @xmath6, @xmath6, @xmath6, and @xmath6, @xmath6, and @xmath6. we have @xmath6, @xmath6, @xmath6, @xmath6, and @xmath6, @xmath6, @xmath6, and @xmath6, @xmath6, and @xmath6, and @xmath6, and @xmath6, and @xmath6, and @xmath6, and @xmath6, and @xmath6, and @xmath6, and @xmath6, and @xmath6, and @xmath7, and @xmath6, and @xmath6, and @xmath6, and @xmath6, and @xmath7, and @xmath6, and @xmath7, and @xmath6, and @xmath7, and @xmath6, and @xmath6, and @xmath7, and @xmath6, and']

I’m wondering what I might be doing wrong/what I might be missing? I’d greatly appreciate any help/feedback with this

I even used no_repeat_ngram_size=2 but still got an odd output summary. Am I using the token batch_decoder incorrectly?


Google static map key error

Sometimes when a location is posted the following image is displayed

Hello,
I'm not sure to understand this issue ?

Oops, sorry, completely wrong project


(maint) Switch PDB container off of Alpine

Alpine seems to still be having issues with DNS resolutions inside
an LCOW environment. In an effort to reduce these transient
problems, switch the base container to a non-Alpine platform.
A ticket has been filed with a repro for Alpine DNS issues under LCOW
https://github.com/docker/libnetwork/issues/2371

While this may increase the image size by about 100MB, the goal here
is reliability and robustness
for the builder container:
clojure:lein-alpine was about 142MB
clojure:openjdk-8-lein is about 507MB
for the target container:
openjdk:8-jre-alpine was about 85MB
openjdk:8-buster-slim is about 184MB

Ubuntu 18.04 shares a lineage with debian buster, which should
be a well supported platform for PDB
All OpenJDK container variants are listed at:
https://github.com/docker-library/docs/blob/master/openjdk/README.md#supported-tags-and-respective-dockerfile-links

I'm not sure if we can get away with an alpine builder still or not? I would expect not for a C++ application unless it was explicitly cross-compiling, but I'm not sure on our Java code.

CLA signed by all contributors.


Automatic PR from RestAPI-PR1107

Generated from RestAPI PR: https://github.com/Azure/azure-rest-api-specs/pull/1107

Codecov Report

Merging #1094 into master will increase coverage by 0.01%.
The diff coverage is 53.65%.

@@            Coverage Diff             @@
##           master    #1094      +/-   ##
==========================================
+ Coverage   56.48%   56.49%   +0.01%
==========================================
  Files        2027     2032       +5
  Lines       57053    57104      +51
==========================================
+ Hits        32227    32262      +35
- Misses      24826    24842      +16

Impacted Files
Coverage Δ

azure-mgmt-sql/azure/mgmt/sql/models/database.py
100% <ø> (ø)
:arrow_up:

...mt-sql/azure/mgmt/sql/models/edition_capability.py
62.5% <ø> (ø)
:arrow_up:

...re/mgmt/sql/models/service_objective_capability.py
41.66% <0%> (-3.79%)
:arrow_down:

...azure/mgmt/sql/models/server_version_capability.py
55.55% <0%> (-6.95%)
:arrow_down:

...ure/mgmt/sql/models/sql_management_client_enums.py
100% <100%> (ø)
:arrow_up:

azure-mgmt-sql/azure/mgmt/sql/version.py
100% <100%> (ø)
:arrow_up:

azure-mgmt-sql/azure/mgmt/sql/models/__init__.py
100% <100%> (ø)
:arrow_up:

...ure-mgmt-sql/azure/mgmt/sql/operations/__init__.py
100% <100%> (ø)
:arrow_up:

...e-mgmt-sql/azure/mgmt/sql/sql_management_client.py
100% <100%> (+26.66%)
:arrow_up:

.../azure/mgmt/sql/operations/databases_operations.py
24.37% <4.34%> (ø)
:arrow_up:

... and 11 more

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 e3cc79e...5117711. Read the comment docs.


Add graph for messages per aircraft per second

A graph like this could be a useful aid in testing antenna/filter/amplifier performance. The aim would be to achieve a high message per a/c per second rate.
A sample graph could look like this:
msg_sec_ac_graph() {
rrdtool graph
"$1"
--start end-$4
--width 480
--height 200
--step "$5"
--title "$3 Message Rate / AC / Second"
--vertical-label "Rate/AC/Second"
--lower-limit 0
--units-exponent 0
"TEXTALIGN:center"
"DEF:all=$2/dump1090_aircraft-recent.rrd:total:AVERAGE"
"DEF:messages=$2/dump1090_messages-local_accepted.rrd:value:AVERAGE"
"CDEF:rate=messages,all,/"
"VDEF:avgrate=rate,AVERAGE"
"VDEF:maxrate=rate,MAXIMUM"
"GPRINT:avgrate:Average:%3.0lf "
"GPRINT:maxrate:Maximum:%3.0lf "
"LINE1:all#990000:A/C"
"LINE1:rate#0000FF:Rate"
"LINE1:maxrate#FF0000:Max Rate"
"LINE1:avgrate#666666:Avg Rate:dashes"
--watermark "Drawn: $nowlit";
}

Will add this graph to the admin branch as soon as I fix the Boolean issue.

Graph added in commit 358e955c54cbdc2b882452177efac6c35b13cc75. However the new graph has not been tested yet due to the fact I do not have access to a working dump1090 device at the moment.

Let me know if/how I can help with testing. I'll have access to my secondary Pi later this evening.

Installation information is here: http://discussions.flightaware.com/post187558.html#p187558
May be some issues it is not tested on a RTL-SDR equipped device. Will be testing it out tonight on a proper device tonight as well.

Graph added to the portal and merged into master by pull request #68.


[docs] Demo SearchIcons crashes

[ ] I have searched for similar issues in this repository and believe that this is not a duplicate.

Steps to Reproduce

Visit https://mui.com/components/material-icons/?theme=Outlined&query=user
??
demo SearchIcons crashes

Your Environment

Tech
Version

MUI
v5.5.0

netlify deploy
https://622bf492b027b5000960dea3--material-ui-docs.netlify.app

Browser
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36

Same problem for me even after several tries and on several Icons

same problem


Keep dead_letters table/client on demand

We don't want to waste resources with dead_letters table and s3/dynamodb clients. Thus, it makes more sense to create/close those resources on demand

cc @xianwill


sys.getsizeof() may raise TypeError

Not all implementations have to implement getsizeof() and may raise
TypeError instead. Notably, Pypy will always raise TypeError (unless a
default value is provided).

Codecov Report

Merging #117 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #117   +/-   ##
=======================================
  Coverage   85.77%   85.77%
=======================================
  Files          29       29
  Lines        3985     3985
=======================================
  Hits         3418     3418
  Misses        567      567

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 1f38b8e...947e13b. Read the comment docs.

Thank you! ;-)


Rewrite deploy.sh to Ruby

The deploy.sh script is becoming quite fat and since our container already has Ruby bundled, it would be better if the script was written in Ruby. Having the script in Ruby over Bash is better just in and of itself, but having it in Ruby would also allow us to add simple and fast RSpec tests for it instead of having to run the container for every little thing.

Seems like jirutka/rake-jekyll already does what we want. Perhaps better to just use it rather than reinventing the wheel in Bash?

I just discovered GitHub Pages Action that is written in TypeScript and seems very full-featured.

I just discovered GitHub Pages Action that is written in TypeScript and seems very full-featured.

Nice find!

@dependebot


Change status

Status font stuff is absolutely massive not sure if you meant for it to be like that but you cant see the icons too

Oh no not this again. I thought I fixed it yesterday and pushed it. Weird. This is most likely to do with discord updating and renaming the id of the popup. Thanks for letting me know I will change this tmrw when I wake up


test: Setup test and release

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


(modal, feature): Add ability to overlay a specific element

Currently, modal can block the whole page only. However, if you have a more complex layout, you often want to be able to have an interactive component allowing to overlay just a specific element without blocking the rest of the page.
The quick example could be a layout containing a header menu and a tab set below. Each tab content represents components user could interact independently with. In this case, if such component wants to show a modal, it should not block the rest of the page, i.e. menu, switching to other tabs, etc.

For what I have read, the Modal purpose is to block the page against a needed user notification or action. If there is not a need for that, you shouldn't use a Modal at all.
The problem is that the modal-backdrop is appended at the end of the body, and only one modal can appear in the page at a time.
It's not quantum science to make your own modal appear using bootstrap's SCSS, or jQuery for that matter. You would need to append a backdrop to the parent tag, show the modal, and have the right event listeners.

@ItaloBC , Right, but are there any technical issues, BS API worsening or unreasonable effort to make the current modal so flexible, that it appends its modal-backdrop to the end of a specific element instead of body and allow multiple instances of it?
Sure, I can implement my own one, but I'd like to propose we have this flexibility in BS out-of-the-box.
It's fine it could be only modal at a time.

@AbakumovAlexandr I sincerely think that over a mobile-first web, multiple modals would be a cluster f*. IF you need to hook a modal to a parent, I think modals its not what you need. And extending Bootstrap to multi-modals would hinder the experience unless you are doing an SPA JS-driven App, were you can save the state of the page. In the latter case, you would make your own implementation.

You probably right about multiple modals in mobile web apps. However even in this case, forcibly leaving framework users with a single modal at a time feels like not the best approach.
Moreover, there are huge number of BS apps that do not care about how they good they are on mobile devices.
My point is that devs of the specific app must be able to decide what is right and what is not when it comes to their app's UX and BS should not limit them in cases where it easily could provide flexibility.

First, I don't think BS will ever get multiple modal in the short term. Modals behave like iOS modals, where you are bound to take a decision (like accepting or dismissing) that you can't avoid. That's the point of the modal. If you need to make multiple modals, modals may not be what need. You may want to take a look into making Notifications instead.

Bootstrap only supports one modal window at a time. Nested modals aren’t supported as we believe them to be poor user experiences.

Second, and again, you're free to make your own implementation using Bootstrap as a foundation, and adding the event listeners you need to make.

My point is that devs of the specific app must be able to decide what is right and what is not when it comes to their app's UX and BS should not limit them in cases where it easily could provide flexibility.

Nobody said BS limits you. You can still use the modal classes to bring your own modal implementation a bound it to a parent if you think modals is the only way to fix your problem. If you think BS limits development then you should make your own framework without these self-imposed limits or understand better the concept of a front-end framework.

@ItaloBC , the very point of the statement you've quoted from the BS docs:

Nested modals aren’t supported as we believe them to be poor user experiences.

is that:
We understand that nested modals is a valid real-world scenario, but we believe them to be poor user experiences.
This is to answer to your first point.
As per second, BS team

believes them to be poor user experiences

Since it's opinion-based decision, as I already said this issue is opened in attempt to reconsider it, since there are valid real-world scenarios for it and it does not seem to be the best approach to leave framework users with limited functionality when you could provide flexibility with ease, and only then.
Also, since it's a valid scenario which could benefit the community, there is no point in saying "make your own framework, if you need it".

Then extend Bootstrap.
I rest my case, your honor.

No, I still would like to go the better way: proposing a feature and openly discussing its pros and cons with the team (hopefully) and the community :)

IMO we wont change that behavior that's a design choice, multiple modal for us is a bad practice and as a framework we shouldn't encourage this practice.
/CC @mdo

@Johann-S , thank you. We understand that the team considers it to be a bad practice.
My thoughts on encouraging part. I think we have to answer this question:

If we add the ability to have multiple modals, would people, who otherwise does not intend to have a design with multiple modals, use it just because this feature exists?

My common sense says "No". Every framework we use has tons of features including those that could be considered bad under certain circumstances. However, we do not use them if we do not need them and use them when our design requirements dictate so.
Moreover, having added this feature, you always could add a clear message "You can even open multiple modals, but we strongly believe it is a bad practice and discourage you from using it" to the docs.

@AbakumovAlexandr try this JS code. Been using it for stacked modals for years with BS3 and seems to work unchanged with BS4:
$(document).on({
    'show.bs.modal': function () {
        var zIndex = 1040 + (10 * $('.modal:visible').length);
        $(this).css('z-index', zIndex);
        setTimeout(function () {
            $('.modal-backdrop').not('.modal-stack').css('z-index', zIndex - 1).addClass('modal-stack');
        }, 0);
    },
    'hidden.bs.modal': function () {
        if ($('.modal:visible').length > 0) {
            // restore the modal-open class to the body element, so that scrolling works
           // properly after de-stacking a modal.
            setTimeout(function () {
                $(document.body).addClass('modal-open');
            }, 0);
        }
    }
}, '.modal');

@bpierson , thank you! I'll give it a try and am sure it'll be helpful for others dealing with multiple modals in BS.

Modal is a blocking UI element—no intentions to change this or add other variations.


fix: specify content-type headers when making json post requests

Fixes issue #159

@googlebot I signed it!

Can confirm this fixes https://github.com/fastlane/fastlane-plugin-firebase_app_distribution/issues/159. Our builds are back to normal. Thanks!


[IDE] Enable 'IgnoreSwiftSourceInfo' in code completion

Getting source locations from .swiftsourceinfo is currently expensive. Since they are not necessary for code completion, set IgnoreSwiftSourceInfo to true.
rdar://problem/57194358
https://bugs.swift.org/browse/SR-11767

@swift-ci Please smoke test

There seems to be a lot of places that needed update, how about adding some processCompilerInvocationForCodeCompletion function that all these places can call into and if we need more adjustments for code-completion we can modify a single place, instead of searching for all the different places?

I agree we should have some unified place for adjusting invocation/instance for completion operations. We already have some duplicated code between completion/typecontextinfo/conformingmethodlist. I will see how we could consolidate them.

@akyrtzi Since it's not trivial change, can I do that in separate pull request (#28322)?

Sure!


Fails to update styles on resize

Demo: http://emberjs.jsbin.com/pixuva/1/edit?html,css,output
Steps to reproduce:

Start with a narrow window. See list items be correctly colored red.
Enlarge the window. See list items correctly become transparent.
Shrink the window back.

What i expect: list items should become red again.
What actually happens: list items remain transparent.

Works fine for me.

I'm seeing it too lolmaus. (Chrome 43.0.2357.124 (64-bit), Mac Yosemite)

same problem here (Chrome 44.0.2403.52 beta - 64-bit - Mac Yosemite)

Yep, ResizeSensor seems to be somewhat broken. I hooked up ElementQueries to https://github.com/wnr/element-resize-detector and now all is well.

:+1:

Still having the issue, other example: http://jsbin.com/bimotoyoyo/edit

Works for me in Chrome, Safari and Firefox @ OSX. Maybe the newest version just fixed it. Could you please provide more information about that topic? browser, OS, and if this issue is still open.


Rain Creates Particles Only at y=0

I have not tested coords below y=0, but values above y=0 will not produce rain particles.

Can confirm. Droplet particles appear at y=0 only, not above or below. Rain glitches through all terrain until y=0 and then turns into the droplets there, even if there is a ceiling or y=0 is an air block.

Probably because rain is calculated like sky lighting, and is dependent on the highest block.

As far as I know, currently it's not calculated at all.


Type consistency discussion

Should we avoid inconsistent serialization? For example, if a field type is number, and we mark its borsh type is u64, currently the serialization will success, but should we throw an error here? because when we deserialize, constructed type will be bigint, they are inconsistent, and may cause unexpected behavior.
This also refers to

number[] v.s. @field({ type: Uint8Array }) @field({ type: vec('u8') }) @field({ type: fixedArray('u8', n) })
any v.s. @field({ type: 'bool' })

Yeap, I agree with you, there are a few inconsistencies regarding serialization. Initially the idea was to have relaxed constraints (limited type checking) to make this library one of the fastest serialization libraries in js.
There is now an "unchecked" flag one can pass to make it even more relaxed. But, this is kind of in the other direction. Perhaps another flag would be necessary, or an enum
serialize(x, { validation: 'none' |  'strict' | 'normal' })

Also it may be good to support typed  arrays https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/TypedArray . It may end up in better performance too.


Overlapping side bar menu and documentation card

This is at 100% Zoom on a 13 inch screen. There is overlapping of text in documentation and side bar menu.

View at 90% Zoom.

@foxeyes


Illegal Argument Exception Crashes Server

Issue Description:
Server crashes on 1.10.2
What happens:
Server crashes with the above exception.
What you expected to happen:
The server to remain running normally.
Steps to reproduce:
I haven't been able to consistently replicate the issue.
...

Affected Versions (Do not use "latest"):

EnderIO: 1.10.2-3.1.157
EnderCore: 1.10.2-<IP_ADDRESS>-beta
Minecraft: 1.10.2
Forge: <IP_ADDRESS>5

Your most recent log file where the issue was present:
https://gist.github.com/Renari/43ac8a41a73bfe030d0410fd3feb3069

see #3939


[Creator] Create an API template based on OpenAPI Spec

A change from the original plan which was to perform the Open API to API Management conversion as part of this tool: As Azure API Management already supports the conversion from Open API spec, we are switching to embedding the OpenAPI file and policy files into an ARM template that the users can then deploy to Azure and the conversion will be done on the API Management side. This avoids duplication of effort between this tool and the APIM dev team


Added support for GoExecutor

Signed-off-by: Rahul M Chheda<EMAIL_ADDRESS>
What this PR does / why we need it:
Please merge the kube-helper PR, and then will update the /vendor of the PR
https://github.com/litmuschaos/kube-helper/pull/13
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Special notes for your reviewer:
Checklist:

[ ] Fixes #
[ ] Labelled this PR & related issue with documentation tag
[ ] PR messages has document related information
[ ] Labelled this PR & related issue with breaking-changes tag
[ ] PR messages has breaking changes related information
[ ] Labelled this PR & related issue with requires-upgrade tag
[ ] PR messages has upgrade related information
[ ] Commit has unit tests
[ ] Commit has integration tests

To send empty string slices for Arguments, and Commands, need to remove the kube-helper checks, else runner creation will fail


Bonitoo sp6 - Kapacitor Open Source Security

Contains new document content/kapacitor/v1.4/administration/security.md
Stage is here.
http://ec2-54-153-106-230.us-west-1.compute.amazonaws.com:1414/kapacitor/v1.4/administration/security/

Note: that at one point the document content/influxdb/v1.4/administration/security.md was committed by mistake.  After realizing the error I reverted it back to the version in master.  Just to be sure that this merge will not overwrite or lead to conflicts with any other changes.

I've just added content/enterprise_kapacitor/v1.4 to this PR - including an update to data/default_versions.toml.
@nathanielc do you have the CHANGELOG.md for enterprise kapacitor for the 1.4 release?  Can you send it by email? The content of the document content/enterprise_kapacitor/v1.4/release-notes-and-changelog.md will need to be updated, however I have no access to the enterprise_kapacitor project on github.

@karel-rehor The Enterprise Kapacitor 1.4 release was only a bug fix release + the OSS features. So the changelog is the same as the OSS Kapacitor 1.4 release.


Doesn't respect chrome zoom

The text is massive on my monitor.
Instinctively I hit CMD+-.
Zooming has no effect.
I literally had to move my chair back so I comfortably view the site.

What browser are you using?
This project uses viewport units which causes zooming OUT a little bit weird than normal.


Allow the body.raw_source field to be mutated

With frozen string literals the raw_source field on body can’t be mutated as it’s initialized with an empty frozen string.
This is needed for the Mailkick gem where it attempts to mutate the raw_source for all parts of the email to replace a unsubscribe string with a live token - https://github.com/ankane/mailkick/blob/master/lib/mailkick/processor.rb#L23

Mutating raw_source directly is going to be (very) error-prone and generally undesirable. Consider gsubbing against each part's decoded body and assigning the body back to the part. That guarantees that any other memoized vars won't go stale (unaware of the hidden mutation) and will work with other transfer encodings, like base64, that aren't so amenable to direct modification.


Differentiate CloudProviderName and KubeletCloudProviderName in templates

What this PR does / why we need it:
We currently use the CloudProviderName field in templates for:

the --cloud-provider flag in the Kubelet service
running commands only for some provider(s)

However, CloudProviderName contains the value returned by GetCloudConfig function. This function returns the cloud provider name used by Kubelet, and only if the provider has an in-tree cloud provider implementation (in-tree CCM). In other words, CloudProviderName will be empty on providers such as Nutanix, DigitalOcean, Hetzner, etc...
We encountered the issue when we tried to install some packages only on Nutanix machines in #1161. Because Nutanix doesn't have in-tree CCM, .CloudProviderName is empty, and the Nutanix-specific logic is not executed.  Therefore, this PR is a prerequisite for #1161.
This issue is fixed by differentiating CloudProviderName and KubeletCloudProviderName:

CloudProviderName is providerConfig.CloudProvider. It's used in templates when we want to run cloud-provider-specific logic (e.g. install some packages only for one provider)
KubeletCloudProviderName is from GetCloudConfig). It's passed to Kubelet via --cloud-provider` flag

Optional Release Note:
Differentiate CloudProviderName and KubeletCloudProviderName in templates

/assign @embik @moadqassem @ahmedwaleedmalik

/approve


GDPR Compliance Module PS 1.7 - Duplication of Compliant Modules in Multistore

I have multi store with 2 shops and I have installed the official GDPR compliance module for PS 1.7.
Whenever I enter the module it shows me duplicated compliant modules (in the "personal data management tab") and duplicate checkboxes (in the "consent checkbox customization" tab). I've tried clearing cache and logging in and out to no avail.
It appears to show the information of both shops on one page as opposed to segregating it by shop.
Please refer to screenshots below.
Screenshots

Additional information
PrestaShop version: <IP_ADDRESS>

Hi as reported in this ticket:
https://github.com/PrestaShop/PrestaShop/issues/12449#issuecomment-461369687
I manage to reproduce the same issue with psgdpr v1.1.2.

Module list id duplicated

Fields are duplicated

When Shop 2 is selected, we try to edit those contents:
3.1 Contact form
3.2 Newsletter subscription
3.3 Mail alerts

And we click save => nothing happens => the shop takes information from the main shop.
@pdkey, thanks!


DISCUSSION: Is there a way for a Transaction to indicate success/failure from exit

From #336.
Currently, there is no way to determine if this occurs. It's unclear what a way forward would look like but in ndb transactions have retries and can create Future objects which know about the success or failure.

The transaction package has a concept of a "doomed" transaction:  one which is in a hosed state, from which it can never be committed.  Having our code fail inside __exit__ would be something like that with two sharp edges:

Failing while committing is actually more reasonable:  the back-end might actually barf here.
Failing while aborting is a real problem:  which exception should surface?

FWIW, the Zope transaction's "two-phase commit" tries to deal with the problems of the first, by breaking up the "commit" into slices, for distribution across multiple resource managers (e.g., a database and a mail-sender).  For each of the following methods, the transaction calls each resource manager in turn):

tpc_begin (can we commit?)
commit(do the work, but don't finalize)
tpc_vote (were there problems?  last chance to back out)
tpc_finish (finalize;  this must never fail:  if it does, we've lost consistency)
tpc_abort (called if any RM raises from tpc_vote:  must never fail).

For the most part the backend handles this.
It seems a concept of "doomed" would be nice since it would make it so that.
txn = Transaction()
with txn:
    entity.save()
    ...

# This fails since txn has already been used, hence is doomed.
with txn:
    new_entity.save()

I was thinking something simple along the lines of
>>> txn.in_progress
False
>>> txn.succeeded
True
>>> txn.finished
True

There seem to be less than 8 states (implied by 3 bools) but more than 4, so maybe there is a better way to get the information to answer the questions:

txn is in progress or not?
txn has already been "used"?
txn finished in commit (success) or rollback (failure)

You also need some way to get auto allocated keys back from the transaction right? Could this be incorporated into the method which indicates failure or success?


Inherit repository and licence Cargo properties from workspace

Closes #121

Codecov Report
Patch and project coverage have no change.

Comparison is base (f1681d9) 100.00% compared to head (55b74dd) 100.00%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@            Coverage Diff            @@
##              main      #189   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files          123       123
  Lines         8549      8549
=========================================
  Hits          8549      8549

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


[fix](routine load) replace heavy work pool with routine load thread pool for metadata fetching (#44907)

pick #44907
In production, we encountered an issue where the librdkafka consumer stucked during destruction, causing the heavy work pool to become saturated, which in turn made all heavy work pool-dependent functionalities, such as querying, unusable. To mitigate this impact, we replaced the heavy work pool with routine load threads for metadata fetching.
What problem does this PR solve?
Issue Number: close #xxx
Related PR: #xxx
Problem Summary:
Release note
None
Check List (For Author)

Test

[ ] Regression test
[ ] Unit Test
[ ] Manual test (add detailed scripts or steps below)
[ ] No need to test or manual test. Explain why:

[ ] This is a refactor/code format and no logic has been changed.
[ ] Previous test can cover this change.
[ ] No code files have been changed.
[ ] Other reason

Behavior changed:

[ ] No.
[ ] Yes.

Does this need documentation?

[ ] No.
[ ] Yes.

Check List (For Reviewer who merge this PR)

[ ] Confirm the release note
[ ] Confirm test cases
[ ] Confirm document
[ ] Add branch pick label

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.
Please clearly describe your PR:

What problem was fixed (it's best to include specific error reporting information). How it was fixed.
Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
What features were added. Why was this function added?
Which code was refactored and why was this part of the code refactored?
Which functions were optimized and what is the difference before and after the optimization?

run buildall


How to see which processor has which gateset

Is your feature request related to a use case or problem? Please describe.
It would be great if the processor would "know" what gateset it accepts - instead of having to pass that in. I find this rather odd. While there is a way to list processors using the Engine API or the UI, there is no way to tell what gate set a processor accepts. The processor.get_device() method takes a list of gate sets which then it uses to validate operations.
processor = engine.get_processor('rainbow')
# Print the device showing qubit connectivity for the Sycamore gateset.
device = processor.get_device([cg.SYC_GATESET])

Describe the solution you'd like
Instead it would be great if a gate set could be determined based on a processor ID.
Describe alternatives/workarounds you've considered
Alternative is to ask someone, use documentation/datasheets (if available).
What is the urgency from your perspective for this issue? Is it blocking important work?
P3 - I'm not really blocked by it, it is an idea I'd like to discuss / suggestion based on principle

@verult I think this can be closed as part of the device spec work.

Yep, closing in favor of https://github.com/quantumlib/Cirq/issues/5050


Add 'Search Bitwarden Vault Items' Extension

Description

Add a bitwarden extension allowing to search items from your vault.
Type of change

New extension

Screencast

Checklist

[x] I read the documentation about publishing

If it's ok with everyone, I would really like to review this again before it gets merged. I should have a chance tomorrow.

@PSalant726, @pomdtr, this question popped up on Twitter. Could you please help me with understanding whether this is an expected behavior, and whether it is potentially an issue?

For instance, it seems that once it has been opened the Vault doesn't automatically locks itself. Can this become a potential security breach?

I replied on Twitter. To close the loop here: it's correct that the vault does not auto-lock based on any system event (ex. "sleep" or "screen saver"), but that's because of the nature of Raycast and extensions. Raycast does not support long-lived processes that can monitor/listen for those events, and execute scripts when they occur (nor do I believe it should). Instead, there is a lock-vault.ts script that enables a user to manually lock an unlocked vault. This is undoubtedly less secure than an automatic lock mechanism, but it's no less secure than leaving your entire system unlocked when you walk away from your computer, and it's the best we were able to do within the limitations of Raycast.

The extension use the same logic as the cli. I store the session token, and check if it is still valid when the user launch the extension. If it is not the case, the extension ask the user for a password.

We could add an artificial auto-lock feature by storing when the last session token was generated.

@pomdtr

We could add an artificial auto-lock feature by storing when the last session token was generated.

In general I think this would be nice to add, as long as it were adequately configurable. Still I don't think it completely addresses the concern from the tweet. My assumption is that the user is attempting to find feature-parity between the official Bitwarden apps and this Raycast extension. We simply won't be able to expire a CLI token based on system events unless the macOS keychain supported it. Even then, that would only affect the validity of the token with respect to the extension. If a user were to submit CLI commands directly, and include the "expired" token, those commands would still succeed because Bitwarden itself has not deemed the token invalid.


clarify MFA license requirements

https://github.com/MicrosoftDocs/windows-itpro-docs/issues/5594

Dear @JohanFreelancer9,
kindly do the copy editor review for this PR.
Dear @e0i, for your information
Thank you

Dear @JohanFreelancer9,
kindly do the copy editor review for this PR.
Dear @e0i, for your information
Thank you

Dear @mapalko ,
could you please have a look now?
Thank you

Dear @mapalko ,
could you please have a look now?
Thank you


Rename and restructure folders

Rename and restructure folders for some classes in core lib

Codecov Report

Merging #607 (52c0cfc) into develop (0159c22) will increase coverage by 2.29%.
The diff coverage is 68.33%.

:exclamation: Current head 52c0cfc differs from pull request most recent head fbfca8c. Consider uploading reports for the commit fbfca8c to get more accurate results

@@             Coverage Diff             @@
##           develop     #607      +/-   ##
===========================================
+ Coverage    64.24%   66.54%   +2.29%
===========================================
  Files           35       39       +4
  Lines         1351     1357       +6
  Branches       238      235       -3
===========================================
+ Hits           868      903      +35
+ Misses         483      454      -29

Impacted Files
Coverage Δ

packages/core/src/logger/SFPLogger.ts
51.61% <0.00%> (-3.56%)
:arrow_down:

.../core/src/sfpcommands/apextest/TriggerApexTests.ts
21.68% <ø> (ø)

packages/core/src/apex/ApexClassFetcher.ts
42.85% <42.85%> (ø)

packages/core/src/apex/ApexTriggerFetcher.ts
42.85% <42.85%> (ø)

.../apex/coverage/ApexCodeCoverageAggregateFetcher.ts
42.85% <42.85%> (ø)

packages/core/src/permsets/AssignPermissionSets.ts
92.30% <81.81%> (ø)

packages/core/src/queryHelper/QueryHelper.ts
88.88% <88.88%> (ø)

.../core/src/apex/coverage/IndividualClassCoverage.ts
88.88% <100.00%> (ø)

packages/core/src/package/SFPPackage.ts
83.33% <100.00%> (ø)

...s/core/src/package/coverage/PackageTestCoverage.ts
95.23% <100.00%> (+36.22%)
:arrow_up:

... and 7 more

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 3e29757...fbfca8c. Read the comment docs.