Break the drag functionality

Hey all,
@TylerMulick @ruthluo91 @clairemerriman
When you get the chance, run the follow commands below into your terminal to get the latest version of the code and try to break our drag functionality/find any flaws. If you do, please comment below with what the issue was and how we can reproduce it.  We are planning on modifying our goals for this week by a little :+1: because of this progress.
cd /path/to/project/repo
git checkout oop-migration
git pull
jekyll serve

Point your browser to localhost:4000/playground
Cheers! :tropical_drink:

Looks great for me. Good work guys! Let me know when the "master importer" is done, then we can really start cleaning up and organizing this code. I'm getting really excited again.

I played around with it last night and again today, and it worked great!
Best,
Claire
On Feb 24, 2016, at 12:27 PM, cmalk <notifications<EMAIL_ADDRESS>wrote:
Looks great for me. Good work guys! Let me know when the "master importer" is done, then we can really start cleaning up and organizing this code. I'm getting really excited again.
—
Reply to this email directly or view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_project415x_project415x.github.io_issues_81-23issuecomment-2D188394110&d=BQMCaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zlNE1vs0fI2XzPVFJ0MbMVhBDrEHRgTBRAwX6v2hggg&m=brRAZx8uCmrGjDhcNEVjRlFNvcYcWOx7X8dkIVrcqHE&s=s2iA9Yd7vZ5kSpiYGuzJ-n0Y8JGZQ0YcfBNozLlBex4&e=.

OK, I've broken it now. If you click on the output canvas then the vector moves as if you had clicked on the input canvas. The behavior should be: clicking on the output canvas does nothing.


Merge V1.0.0 fixes with master

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

110 of 110 (100.0%)  changed or added relevant lines in 7 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
166

Relevant Lines:
166

💛  - Coveralls


Would it make more sense to make RocksDB a table AM instead of a FDW?

https://www.postgresql.org/docs/devel/tableam.html

Hi David, thanks for coming here and giving suggestion. One hesitation for me to use AM instead of FDW, (please confirm it is true or not), I have to store all data in table instead of all in index. We wish we can put all data in the index. Otherwise, AM method is more promising for us.

Hi David, thanks for coming here and giving suggestion. One hesitation for
me to use AM instead of FDW, (please confirm it is true or not), I have to
store all data in table instead of all in index. We wish we can put all
data in the index. Otherwise, AM method is more promising for us.
On Fri, 15 May 2020 at 15:47, David Fetter<EMAIL_ADDRESS>wrote:

https://www.postgresql.org/docs/devel/tableam.html
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/vidardb/PostgresForeignDataWrapper/issues/25, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AA4EX33GRKF34QKSXAOMQ5DRRWL57ANCNFSM4NCQNO3A
.

Thanks for getting back to me on this. There are also index AMs. If you want to store the data in indexes, they might be a good fit. https://www.postgresql.org/docs/devel/indexam.html

Cool! Seems exactly what we need! I will carefully read the doc. Appreciated.

After reading the doc and related presentations as well as ZomboDB's implementation, I finally figure out the exact difference between table AM, index AM and FDW. The ultimate best choice for us should be table AM as you suggested. But we will wait for more table AM implementations and then do the migration.


ChaCha20-Poly1305 support?

Hello.
ChaCha20 and Poly1305 support was added in OpenSSL 1.1.0, and can normally working with OpenVPN since 2.4.3 version (see: https://community.openvpn.net/openvpn/ticket/759#comment:11)
Can you please add ChaCha20 (and ChaCha20-Poly1305) options to install script?
Many thanks!

That would be great, but I checked on Debian 9, and OpenVPN is built with OpenSSL 1.0.2:
root@nope:~# openvpn --version
OpenVPN 2.4.5 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Mar  1 2018
library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.08
Originally developed by James Yonan
Copyright (C) 2002-2018 OpenVPN Inc<EMAIL_ADDRESS>Compile time defines: enable_async_push=no enable_comp_stub=no enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dependency_tracking=no enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=needless enable_fragment=yes enable_iproute2=yes enable_libtool_lock=yes enable_lz4=yes enable_lzo=yes enable_maintainer_mode=no enable_management=yes enable_multihome=yes enable_pam_dlopen=no enable_password_save=yes enable_pedantic=no enable_pf=yes enable_pkcs11=yes enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_silent_rules=no enable_small=no enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=yes enable_werror=no enable_win32_dll=yes enable_x509_alt_username=yes with_aix_soname=aix with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_plugindir='${prefix}/lib/openvpn' with_sysroot=no

I also tested with the backports and OpenVPN repo.
So no sorry we can't add it, but as soon as we can get OpenVPN releases built against OpenSSL 1.1.0, I'll be sure to add it. (That's not likely to be soon though)

@Angristan why raspbian has already 1.1.0f? Just checked my pi.

@cezar97 you mean it's already built against 1.1.0f?

@Angristan @cezar97 I also can confirm, my Raspberry Pi 3 B+ running on ArchLinux and has OpenSSL 1.1.0h
root@RPi3> uname -a
Linux RPi3 4.15.15-1-ARCH #1 SMP Sat Mar 31 21:00:14 MDT 2018 aarch64 GNU/Linux

root@RPi3> openvpn --version
OpenVPN 2.4.5 aarch64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Mar  5 2018
library versions: OpenSSL 1.1.0h  27 Mar 2018, LZO 2.10
Originally developed by James Yonan
Copyright (C) 2002-2018 OpenVPN Inc<EMAIL_ADDRESS>Compile time defines: enable_async_push=no enable_comp_stub=no enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=yes enable_fragment=yes enable_iproute2=yes enable_libtool_lock=yes enable_lz4=yes enable_lzo=yes enable_management=yes enable_multihome=yes enable_pam_dlopen=no enable_pedantic=no enable_pf=yes enable_pkcs11=yes enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_small=no enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=yes enable_werror=no enable_win32_dll=yes enable_x509_alt_username=yes with_aix_soname=aix with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_sysroot=no

Can you send openssl --show-ciphers?

Sorry, I misunderstood. Checked only openssl version, as openvpn is built with the 1.0.2l one.

Ok so it's not related to the Rapsberry Pi but to Arch then

Invalid command '--show-ciphers'; type "help" for a list.

Same on raspbian BTW.

Yes it's openssl ciphers and openvpn --show-ciphers (which may not be the same)

root@RPi3> openvpn --show-ciphers
The following ciphers and cipher modes are available for use
with OpenVPN.  Each cipher shown below may be use as a
parameter to the --cipher option.  The default key size is
shown as well as whether or not it can be changed with the
--keysize directive.  Using a CBC or GCM mode is recommended.
In static key mode only CBC mode is allowed.

AES-128-CBC  (128 bit key, 128 bit block)
AES-128-CFB  (128 bit key, 128 bit block, TLS client/server mode only)
AES-128-CFB1  (128 bit key, 128 bit block, TLS client/server mode only)
AES-128-CFB8  (128 bit key, 128 bit block, TLS client/server mode only)
AES-128-GCM  (128 bit key, 128 bit block, TLS client/server mode only)
AES-128-OFB  (128 bit key, 128 bit block, TLS client/server mode only)
AES-192-CBC  (192 bit key, 128 bit block)
AES-192-CFB  (192 bit key, 128 bit block, TLS client/server mode only)
AES-192-CFB1  (192 bit key, 128 bit block, TLS client/server mode only)
AES-192-CFB8  (192 bit key, 128 bit block, TLS client/server mode only)
AES-192-GCM  (192 bit key, 128 bit block, TLS client/server mode only)
AES-192-OFB  (192 bit key, 128 bit block, TLS client/server mode only)
AES-256-CBC  (256 bit key, 128 bit block)
AES-256-CFB  (256 bit key, 128 bit block, TLS client/server mode only)
AES-256-CFB1  (256 bit key, 128 bit block, TLS client/server mode only)
AES-256-CFB8  (256 bit key, 128 bit block, TLS client/server mode only)
AES-256-GCM  (256 bit key, 128 bit block, TLS client/server mode only)
AES-256-OFB  (256 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-128-CBC  (128 bit key, 128 bit block)
CAMELLIA-128-CFB  (128 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-128-CFB1  (128 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-128-CFB8  (128 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-128-OFB  (128 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-192-CBC  (192 bit key, 128 bit block)
CAMELLIA-192-CFB  (192 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-192-CFB1  (192 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-192-CFB8  (192 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-192-OFB  (192 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-256-CBC  (256 bit key, 128 bit block)
CAMELLIA-256-CFB  (256 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-256-CFB1  (256 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-256-CFB8  (256 bit key, 128 bit block, TLS client/server mode only)
CAMELLIA-256-OFB  (256 bit key, 128 bit block, TLS client/server mode only)
SEED-CBC  (128 bit key, 128 bit block)
SEED-CFB  (128 bit key, 128 bit block, TLS client/server mode only)
SEED-OFB  (128 bit key, 128 bit block, TLS client/server mode only)

The following ciphers have a block size of less than 128 bits,
and are therefore deprecated.  Do not use unless you have to.

BF-CBC  (128 bit key by default, 64 bit block)
BF-CFB  (128 bit key by default, 64 bit block, TLS client/server mode only)
BF-OFB  (128 bit key by default, 64 bit block, TLS client/server mode only)
CAST5-CBC  (128 bit key by default, 64 bit block)
CAST5-CFB  (128 bit key by default, 64 bit block, TLS client/server mode only)
CAST5-OFB  (128 bit key by default, 64 bit block, TLS client/server mode only)
DES-CBC  (64 bit key, 64 bit block)
DES-CFB  (64 bit key, 64 bit block, TLS client/server mode only)
DES-CFB1  (64 bit key, 64 bit block, TLS client/server mode only)
DES-CFB8  (64 bit key, 64 bit block, TLS client/server mode only)
DES-EDE-CBC  (128 bit key, 64 bit block)
DES-EDE-CFB  (128 bit key, 64 bit block, TLS client/server mode only)
DES-EDE-OFB  (128 bit key, 64 bit block, TLS client/server mode only)
DES-EDE3-CBC  (192 bit key, 64 bit block)
DES-EDE3-CFB  (192 bit key, 64 bit block, TLS client/server mode only)
DES-EDE3-CFB1  (192 bit key, 64 bit block, TLS client/server mode only)
DES-EDE3-CFB8  (192 bit key, 64 bit block, TLS client/server mode only)
DES-EDE3-OFB  (192 bit key, 64 bit block, TLS client/server mode only)
DES-OFB  (64 bit key, 64 bit block, TLS client/server mode only)
DESX-CBC  (192 bit key, 64 bit block)
IDEA-CBC  (128 bit key, 64 bit block)
IDEA-CFB  (128 bit key, 64 bit block, TLS client/server mode only)
IDEA-OFB  (128 bit key, 64 bit block, TLS client/server mode only)
RC2-40-CBC  (40 bit key by default, 64 bit block)
RC2-64-CBC  (64 bit key by default, 64 bit block)
RC2-CBC  (128 bit key by default, 64 bit block)
RC2-CFB  (128 bit key by default, 64 bit block, TLS client/server mode only)
RC2-OFB  (128 bit key by default, 64 bit block, TLS client/server mode only)

Thanks @fconn... I don't see CHACHA :/

Yes we can but since the beginning I don't want to compile OpenVPN. The goal is to have something fast and easy to set up

Ah good call, plus when it comes to security the latest isn't always the greatest.  Granted there could be major upsides to compiling the binaries ourselves.  We could use GitLab CI/CD and Docker to auto compile and publish the binaries for wget/curl ourselves and maybe offer the ability for people to compile their own somehow.  The benefit reaped from using GitLab is that we can likely allow everyone to see the whole compile process and see the hashed binaries as they roll right out of the compiler for integrity checking etc.
Then the tinfoil hatters could pull the containers and build it themselves if they desired.  The best part is we could have GitLab mirroring the respective repositories and set up a network of HTTP hooks for triggering builds when any of the upstream push updates to their own git repos.  I wouldn't exactly mind contributing to this somewhat but I'm not certain my shell-jit-su is all up to snuff with everyone else here.

Does OpenVPN Android client s supports ChaCha20 ?

@testcaoy7 didn't tested but it should, at least for OpenVPN for Android (Arne Schwabe).

What version of openvpn is in Ubuntu 18.04 preview?  This all might be
meaningless in a month if they include ChaCha20. Also what're researchers
saying about it?
On Wed, Apr 4, 2018, 4:37 AM Angristan<EMAIL_ADDRESS>wrote:

On recent ARM chips, CHACHA20 may not be faster since they have AES
intrutions
https://en.wikipedia.org/wiki/AES_instruction_set#Hardware_acceleration_in_other_architectures
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Angristan/OpenVPN-install/issues/190#issuecomment-378524504,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABBNVnhnnQvWsgyc5NMtk6H7aZtbTJLCks5tlIY7gaJpZM4TCx68
.

What version of openvpn is in Ubuntu 18.04 preview?

I added repos for bionic on my 16.04: openvpn from Ubuntu repos on 18.04 seems to be v2.4.4 built with openssl 1.1.0g and hasn't got ChaCha20.
Tried with openvpn official repo too but obviously got an 404 error as it hasn't got anything for bionic yet.
In other words we should wait for the release and see if there's any updates then.

tell me how to enable chacha20?

Update OpenVPN to 2.5 and then it will work with ChaCha20-Poly1305
https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos?__cf_chl_jschl_tk__=0j8x56jbw3AHFY0BZ.zXRqDEuIRPuWnQ24htwFZeZVs-1636985987-0-gaNycGzNCH0


(WIP) Recursive push

Recursive push
I'm working on adding support for recursive pushing of submodules to the PushCommand.
The eventual goal is adding support for this to the Git plugin's publisher.
Changes
PushCommand
I added recurseSubmodules(String recurseOption) to the PushCommand interface.
I contemplated making recurseOption an enum, but decided against it for simplicity's sake.
CliGitAPIImpl
For the CLI implementation I simply add --recurse-submodules=${option} to the command args. In line with all the other options.
JGitAPIImpl
As far as I can tell, JGit doesn't seem to support this at the time, so I left this empty with a TODO for now. Should I leave it as is or try to find a workaround?
GitAPITestCase
I added a zipped up test setup to the resources containing a number of repositories.
Their links are all relative so I just unzip it, execute my push command and check the results.
I added three tests, testing each valid option respectively.
Originally, I created the test setup from scratch, which made their contents clearer, but made the tests themselves rather big. Which approach do you prefer?
Other
I removed some unused imports throughout the files I touched.

Thank you for this pull request! Please check this document for how the Jenkins project handles pull requests.


Version 2.0.0 causes issues with Django 4.x due to missing sourcemaps

django-json-widget version: 2.0.0
Django version: 4.0.10
Python version: 3.10
Operating System: MacOS

Description
This commit reintroduces //# sourceMappingURL=jsoneditor.map at the end of jsoneditor.min.js which breaks Django 4.x upgrade. This line was previously removed in #70.
What I Did
Tried upgrading to version 2.0.0 to resolve sourcemap issue but collectstatic still fails while using ManifestStaticFilesStorage.

Fixed in 2.0.1 version


Interesting... could you try to repro with:
$ gdb chiaharvestgraph
>>> run ~/.chia/mainnet/log

And when it crashes, type
>>> where
And report back with any info from the terminal?
Thx!

I got this fixed on #38

The real issue is still unclear to me, but it did get fixed in commit 9fca9af47730217731f974571958a5ea3ab01a20


[minor] add radius argument to StrictSearch function for user custom radius search

add radius argument to StrictSearch function
before
func StrictSearch(vec []float64, size int, epsilon float32) ([]StrictSearchResult, error)

after
func StrictSearch(vec []float64, size int, epsilon, radius float32) ([]StrictSearchResult, error)

#7 is now resolved by this PR

Codecov Report

Merging #10 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master      #10   +/-   ##
=======================================
  Coverage   68.31%   68.31%
=======================================
  Files           1        1
  Lines         385      385
=======================================
  Hits          263      263
  Misses         89       89
  Partials       33       33

Impacted Files
Coverage Δ

gongt.go
68.31% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


New Release

The changelog mentions a few unreleased features. @Lawouach when can we expect a new release?

Arrgh... I am so sorry for not responding earlier. You are right, a release is more than expected. I will do one this week!


annovar databse file downloading error

Error: the database file humandb/hg19_ljb23_all.txt is not present
getting this error while working with annovar. please help!!

Did you change the configure file or annovar cmd for the datasets? InterVar now are using  dbnsfp42a to get multiple in silico predictions not ljb23 dataset.

Im are working on installing and to run ANNOVAR . I have the .vcf file
where i used hg38 reference genome.  While installing ,some database files
are failed to download.
I'm finding difficult to use annovar offline. Can you please help me with
this?
On Wed, 22 Dec 2021, 18:13 Quan LI, @.***> wrote:

Did you change the configure file or annovar cmd for the datasets?
InterVar now are using dbnsfp42a to get multiple in silico predictions not
ljb23 dataset.
—
Reply to this email directly, view it on GitHub
https://github.com/WGLab/InterVar/issues/72#issuecomment-999549340, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AXANMRSYI76BUB2L5DFZDM3USHBXHANCNFSM5KSFSTGQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>


sweethome3d: 6.2 -> 6.3

Motivation for this change
unfortunately still needs me to manually roll back the mesa version
from 20.0.2 (or 20.0.4) to 19.3.3 as discussed in
https://discourse.nixos.org/t/glx-not-recognised-after-mesa-update/6753
using 'sweethome3.application'
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

@raboof so is this WIP, waiting on some fixes in mesa?

@aanderse it's 'equally broken' for me on 6.2 and 6.3, so I'd say the update and the mesa problem are independent

@GrahamcOfBorg build sweethome3d


Support one click upgrade option for cluster/project monitoring.

Rancher server version - v2.2.4-rc5
Currently we expect users to upgrade cluster/project monitoring related apps individually.
Following are some of the the workflows that are not obvious to the user when "upgrade available" options are made available on the cluster/project monitoring related apps.

Cluster monitoring relies on both cluster-monitoring app  and  monitoring-operator app , we expect users to upgrade BOTH these app  so that  are  up to date for a given rancher server version .
Project Monitoring relies on  monitoring-operator (deployed in system project)  and project-monitoring (deployed in users project ) . Ideally when project-monitoringis upgraded , we would expect  monitoring-operator (deployed in system project) to also be upgraded .

I almost feel like there should be 1 click to upgrade cluster monitoring/project monitoring which should do the upgrade of all the necessary apps  .Otherwise there is going to be lot of confusion. Just like enabling/disabling monitoring in a single click , Upgrade should also be 1 click which should not require users to be doing multiple app upgrades.
At this time , a project owner will not have the ability to  upgrade monitoring-operatorwhich is in the “System” project ? We will not have the need to be doing a project monitoring upgrade for this release. But this something that needs to be addressed as well.

Based on offline discussion with @sangeethah @loganhz and @cjellick, we are going to add a better UX around monitoring upgrade. There will be a UI option to upgrade cluster monitoring, that would trigger app upgrade. So user doesn't have to go and manually update 2 monitoring apps.

Replication:
v2.2.4-rc5
I enabled cluster monitoring on one cluster and project monitoring on another cluster.

Downgraded the cluster monitoring and operator to v0.0.2 (need to do this because latest is v0.0.3 so I wouldn't have anything to upgrade to and in v2.2.3 we didn't have an option for project monitoring).
Downgraded to v0.0.1 for project monitoring because downgrading to v0.0.2 does not work due to errors.

I agree there is no easy way to do upgrades. You have to manually go to each app in the System project and upgrade each app individually for both project and cluster monitoring.
Validation:
v2.2.4-rc5 -> master upgrade (Master (v2.3) (5/30/19))
I upgraded to the latest master build available to me at the time and tested the one-click upgrade feature for cluster and project monitoring.
I observed the new "Upgrade Available" notice at the top of monitoring config.

From the drop down I can choose to keep current v0.0.2 or upgrade to now v0.0.3 available. I upgraded to v0.0.3. All I had to do was pick this and then click "Save"
I quickly switched to System > Apps and watched both the cluster-monitoring and monitoring-operator update to v0.0.3. This worked without any issues.
If I go back to the cluster monitoring config page now I no longer see the alert that an update is available. You also cannot downgrade which I think is fair. If for some unique reason a user must downgrade they should probably do this manually for each app.

I did the same test but for the cluster that had project monitoring enabled. It was basically the same process.

This upgraded project-monitoring to the latest v0.0.3 and upon checking the project monitoring config page again I no longer see the alert that it is out of date.
--
I smoke tested both cluster monitoring and project monitoring post-upgrade (project monitoring ensure endpoints functional). I didn't observe any issues.


Minor typo in README

Awesome gem, it's so nice when I don't have to muck around with lots of images, stylesheets, and javascripts on my system.  Anyways I noticed a small error in the README and wanted to submit this patch to fix it.
Thanks and keep it real :)

Thanks! The typos were in, because I in fact use slim instead of haml. And here you have to use {{ }} in order to prevent escaping, which should not happen in javascript. But yeah, I wrote it's a haml example so you are right of course. Thanks again, pulled :)

Nice, thanks!


DOC: Migrate peer review description from Gerrit to GitHub

Thanks for the review, Jon!
Your thoughts on these PRs are appreciated.
I am also using the PRs to bootstrap testing of the new continuous integration, so I may merge them before they have had a chance for normal review.

No worries. I understand. I think it's working great.
I've noticed the new checks; I guess it is still WIP, and that you're putting in place everything needed. I ignore why we are missing the circleCI or CDash builds in this repository.
Although, since a couple of days the PR's have a new tab called Checks where GitHub marketplace apps are supposedly able to provide information. I ignore how this can benefit our repos.
One thing that I think ITKExamples is missing, as opposed to the ITKSoftwareGuide repository, is to request reviews before merging for each PR, as mentioned in this ISC card. I cannot do this due to my limited rights on the repostory.

Yes, CI-builds are on their way in #55 . After we get CI up, we could enable required reviews. It looks like it will be an incremental process -- all three platforms have build issues or test failures.  That's what happens when you don't have good regression testing :-P. We should be able to get Linux clean, and incrementally get Windows and macOS clean.


“Syntax error in INSERT INTO statement” - Watch for Jet4.0 Reserve Words

https://support.microsoft.com/en-us/kb/892608
If you can't change the database name as suggested in above link, then place square brackets ([]) around the reserved word in the query. This allows the query to be executed even though the reserved word is in use. For example,
SELECT Usage From Table1

would become
SELECT [Usage] From Table1

Posted for future fellas.


Regression: Root user can't be used anymore

If root user is being used to setup e.g. the KVM host the scripts are failing.

Already fixed.


Expo requires Android's versionCode to be a integer (not a string)

When I try to build the application via Expo, I see this error:
Field: android.versionCode - should be integer.

For reference: versionCode - Expo Documentation
Seems like this can be easily fixed here:
https://github.com/googleapis/release-please/blob/9cb84cb18211c61ed94d856b936fff30036b0988/src/updaters/expo/app-json.ts#L89

Hi, this fix is currently not coming through in the github action because that needs to be updated separately. or is there a different way I can start using it right now? thanks :)


Non-Darwin SDKs product results in per-arch directories.

However, the build system was placing the build results in the
platform/OS folder, instead of the per-architecture folder. Having two
architectures side by side was impossible.
After applying the above patch in the Swift compiler, non-Darwin
platforms will look into the per-architecture folders, so the sibling
projects need to leave the products in the right place.

@drodriguez can we stage the installation so that we put a copy as a workaround in the old location as well so that we can merge this without the rest of the changes?  Having fewer dependent changes makes things easier.

I suppose that it might work. We can only put one architecture in the old location, though, but Jenkins only builds one architecture, so it should work.


Add resistor values documentation

First try of documenting all resistor values in one place.

Thanks for the PR.
Your measurements are within ~1% from mine, and the range of accepted values is actually quite a bit wider (+/- 300Ohm still works fine) so it's probably not necessary to break it down this much.
RPT/ENT button (which I call TMark) is certainly interesting since its effect during recording (that is, inserting a track mark) is not really documented. As far as I can tell, user manuals always tell you to press track mark on the device itself. But it works - whether by design or accidentally...
I think I will just add a comment in settings.conf explaining what value each button should correspond to but the rest would be likely better suited for e.g. minidisc.wiki

Added in https://github.com/fijam/gmdrec/commit/a19ab9e3aab447948519eb3c6fd8bf21c055be98

I put the rest up here now with some additional information:
https://thp.io/2022/md-remote-resistor-values.html


Packaging request: pythonPackages.rdflib-jsonld

Project description
This is an implementation of JSON-LD for RDFLib.
Metadata

homepage URL: https://pypi.org/project/rdflib-jsonld/
source URL: https://github.com/RDFLib/rdflib-jsonld
license: bsd
platforms: linux

Awaiting PR acceptance #95711

added


[FLINK-22001] Add missing check for empty job graph

The PR is based on https://github.com/tillrohrmann/flink/pull/27

Merged.


[Bug]: Vertical Scroll Cannot Be Removed When Layout Should Fit to Page

Is there an existing issue for this?

[X] I have searched the existing issues

Description
A vertical scroll bar is shown and cannot be removed when the layout/content should actually fit the page.
Check this loom screen-recording:
https://www.loom.com/share/03866f8346c44167a20233baf5a149a8
Steps To Reproduce

Create a new app and add some widgets. The layout should fit the page.
Note that the scroll is shown in both edit and deployed mode.

Public Sample App
https://app.appsmith.com/applications/62a841c284b91337251a1411/pages/62a841c284b91337251a1414
Version
Cloud

Why doesn't the canvas auto-resize to occupy minimum width? What is the logic that we use today
@riodeuno can you help? How do we change the size of the canvas in the apps?


[WIP] Add support for data write to MySQL storage table

I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en

Almost done, could someone help review this?

@sundy-li as a potential user it would be nice to have a config option to allow ON DUPLICATE KEY

I'm also interested in this task. Maybe we can work together to make it better?
I've listed several improvements that we might be able to do together : ) :

[ ] Build write to mysql using prepared_statement
[ ] Support INSERT INTO  mysql() SELECT * FROM table
[ ] Add a new parameter at TableFunctionMySQL for ON DUPLICATE KEY

Look forward to your reply @sundy-li  : )

@zhang2014  Great to hear that.  Let's work it together!!!

As I remember, the most efficient way to insert data is LOAD DATA LOCAL INFILE, but current solution seems good enough and I don't care.

Support INSERT INTO mysql() SELECT * FROM table

I see no reason why it shouldn't work automatically.

Add a new parameter at TableFunctionMySQL for ON DUPLICATE KEY

And REPLACE. It can be postponed for the next commit.

I see no reason why it shouldn't work automatically.

Because Table functions can only be specified in the FROM clause for select usage.

Add a new parameter at TableFunctionMySQL for ON DUPLICATE KEY

The ON DUPLICATE KEY and REPLACE INTO clauses are only used in the MySQL insert query. But from now on table functions  can only be  select usage.  So will it be ok to add this two config option as the engine configs?
Such as Use ENGINE = mysql(host_port, database_name, table_name, user_name, password, on_duplicate_clause, replace_query ) . The user could create another table if he wants to have different on duplicate settings.

I created a issues[#2346] to track subsequent changes.

Could you please also add something into dbms/tests/integration?

@alexey-milovidov    thanks for your detail comment,  I will do those improvement.


Build(deps-dev): Bump webpack-cli from 4.10.0 to 5.0.0 (#4389)

Pull request opened by the merge tool on behalf of #4389

Merged in 3583ef6e3a42779c5313da83489dff5126772d28


reads min/target sdk versions from localproperties

This PR changes the build.gradle files to read the flutter.minSdkVersion and flutter.targetSdkVersion from the generated local.properties, and if not found, keep the default one (which is set at flutter.gradle)
It changes all build.gradle files from examples/* and the integration_test/example.
It doesn't change build.gradle files from dev projects at dev/* but they can be changed too upon further request.
It changes both java and kotlin build.gradle templates.
It changes the default app test to expect the new strings on build.gradle.
It doesn't apply the same concept to flutter.compileSdkVersion, so having it on local.properties doesn't change the value set at flutter.gradle, this can also be added upon further request.
This PR also changes flutter.gradle to detect and warn the developer with a logger.quiet message about mismatches with plugins API level. If a mismatch is found, it also checks if the variables flutter.minSdkVersion and flutter.targetSdkVersion were set at local.properties
It also changes the gradle_errors.dart to update the box message about how to fix the API level error, while adding a reference to the docs. The test was also updated.
Images:

[Before] New project with a dependency requiring higher sdk version.

[After] New project with a dependency requiring higher sdk version.

[After] New project with the variables INcorrectly set at local.properties.

[After] New project with the variables correctly set at local.properties.

It closes #95533
Partially solves #95485 (Android part)
Could be a solution to #95514
Extra - Not related: at https://github.com/flutter/flutter/pull/95684/commits/044079046a3765cfba82991e7002a3339af9b7d7 I fixed the command required to export the FLUTTER_ROOT variable in order to run tests.

How to set this properties on CI server? the local.properties in .gitignore, no upload to git repository.

PTAL @christopherfujino

@SPiercer Looks like this change was reverted in https://github.com/flutter/flutter/pull/99191. You can update the minSdkVersion and targetSdkVersion directly in the build.gradle configuration file located at [your project]/android/app . For more information, see https://docs.flutter.dev/deployment/android#reviewing-the-gradle-build-configuration.


Adjust space in property/subscript declarations

This is just a very simple cleanup to maintain consistency with the code style presented at [The Swift Programming Language] (https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language).

Thank you!  Could you revert the changes to trailing whitespace from the diff?

Hmmm, I can see it by running git diff --ignore-space-at-eol HEAD^...

I'd just edit the patch by hand and remove the @@ hunks that contain whitespace changes.

Had the setting "trim_trailing_white_space_on_save": true on my editor. Anyways, guess everything is ok now :smile:

Thanks again!


What could cause widely varying inference time when using pre-trained opus-mt-en-fr model with python transformers library?

I have been testing pre-trained Opus-MT models ported to transformers library for python implementation. Specifically, I am using opus-mt-en-fr for English to French translation. And the tokenizer and translation model is loaded via MarianTokenizer and MarianMTModels--similar to code examples shown here on huggingface. Strangely, for the same pre-trained model translating the same English input on an identical machine, I have observed anywhere between 80+ ms and (whopping) 4 s per translation (example input = "kiwi strawberry").
Wonder if anyone has observed similar behaviours, and what could cause such a wide variation? Thank you very much!

Maybe asking people at huggingface and the transformers git repo would help?

Good afternoon. Hypothetically, maybe the CPU or GPU load affected the performance of the model? Have you tried to monitor the load on the hardware component while performing measurements?


Use of Optional<> in Features API.

This fixes #207

There are still differen import Orders. In some files.

There are still differen import Orders. In some files.

Yes, I see that too.

There are still differen import Orders. In some files.

Yes, I see that too.

Doh sorry that should be fixed now.


nanodbc: init at 2.13.0

Motivation for this change
Package request #130134
Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

Friendly ping to @NixOS/darwin-maintainers to maybe try and build this on Darwin. :)
It's not obvious what the problem can be with ofborg failures (no framework mentioned).

Try this change:
# backport the change in https://github.com/nanodbc/nanodbc/issues/274
postUnpack = ''
  mv VERSION VERSION.txt
'';

On darwin-x86, nix build .#nanodbc fails with the following error:
error: builder for '/nix/store/5mi5mv8c0z3l90kh4sxnyjqy35x7w8gn-nanodbc-2.13.0.drv' failed with exit code 2;
       last 10 log lines:
       > _Tp* __cxx_atomic_fetch_sub(__cxx_atomic_base_impl<_Tp*> volatile* __a, ptrdiff_t __delta, memory_order __order) _NOEXCEPT {
       >                                                                         ^
       > /nix/store/64nxa8d4zwvfycksdf3ahj4rxr2a08gj-libcxx-11.1.0-dev/include/c++/v1/atomic:1073:65: error: unknown type name 'ptrdiff_t'
       > _Tp* __cxx_atomic_fetch_sub(__cxx_atomic_base_impl<_Tp*> * __a, ptrdiff_t __delta, memory_order __order) _NOEXCEPT {
       >                                                                 ^
       > fatal error: too many errors emitted, stopping now [-ferror-limit=]
       > 20 errors generated.
       > make[2]: *** [CMakeFiles/nanodbc.dir/build.make:76: CMakeFiles/nanodbc.dir/nanodbc/nanodbc.cpp.o] Error 1
       > make[1]: *** [CMakeFiles/Makefile2:151: CMakeFiles/nanodbc.dir/all] Error 2
       > make: *** [Makefile:146: all] Error 2
       For full logs, run 'nix log /nix/store/5mi5mv8c0z3l90kh4sxnyjqy35x7w8gn-nanodbc-2.13.0.drv'.

Thank you @prusnak ! This seems OK now!

So, this can be merged now, isn't it?


encountered an error during hcsshim::System::waitBackground: failure in in windows container mode. on fast ring and latest 1909 release.

Description
encountered an error during hcsshim::System::waitBackground: failure in in windows container mode. on fast ring and latest 1909 release.
see also moby https://github.com/moby/moby/issues/40844
Steps to reproduce the issue:
docker run -it mcr.microsoft.com/powershell:lts-alpine-3.10

Describe the results you received:
PS /> exit
time="2020-04-22T09:58:24+02:00" level=error msg="Error waiting for container: failed to shutdown container: container
69fc778d98e49bc2cd3f6e54612ff27bb7663cbe891b2a152d707f9620e4d08a encountered an error during hcsshim::System::waitBackground: failure in a Windows system call: The virtual machine or container with the specified identifier is not running. (0xc0370110): subsequent terminate failed container 69fc778d98e49bc2cd3f6e54612ff27bb7663cbe891b2a152d707f9620e4d08a encountered an error during hcsshim::System::waitBackground: failure in a Windows system call: The virtual machine or container with the specified identifier is not running. (0xc0370110)"
PS C:\Users\bartp>

Client: Docker Engine - Community
Version:           19.03.8
API version:       1.40
Go version:        go1.12.17
Git commit:        afacb8b
Built:             Wed Mar 11 01:23:10 2020
OS/Arch:           windows/amd64
Experimental:      true
docker version
Server: Docker Engine - Community
Engine:
Version:          19.03.8
API version:      1.40 (minimum version 1.24)
Go version:       go1.12.17
Git commit:       afacb8b
Built:            Wed Mar 11 01:37:20 2020
OS/Arch:          windows/amd64
Experimental:     true
docker info
Client:
Debug Mode: false
Plugins:
app: Docker Application (Docker Inc., v0.8.0)
buildx: Build with BuildKit (Docker Inc., v0.3.1-tp-docker)
mutagen: Synchronize files with Docker Desktop (Docker Inc., testing)
Server:
Containers: 6
Running: 1
Paused: 0
Stopped: 5
Images: 359
Server Version: 19.03.8
Storage Driver: windowsfilter (windows) lcow (linux)
Windows:
LCOW:
Logging Driver: json-file
Plugins:
Volume: local
Network: ics internal l2bridge l2tunnel nat null overlay private transparent
Log: awslogs etwlogs fluentd gcplogs gelf json-file local logentries splunk syslog
Swarm: inactive
Default Isolation: hyperv
Kernel Version: 10.0 19608 (19608.1000.amd64fre.rs_prerelease.200410-1438)
Operating System: Windows 10 Pro Version 2004 (OS Build 19608.1006)
OSType: windows
Architecture: x86_64
CPUs: 4
Total Memory: 31.88GiB
Name: PCI
ID: KUM5:H6SV:J3EE:5FI3:Q5PL:TA2W:ZRIS:CNBG:52AF:EL3B:F7DB:H6SG
Docker Root Dir: C:\ProgramData\Docker
Debug Mode: true
File Descriptors: -1
Goroutines: 35
System Time: 2020-04-22T10:03:27.9886332+02:00
EventsListeners: 1
Registry: https://index.docker.io/v1/
Labels:
Experimental: true
Insecure Registries:
<IP_ADDRESS>/8
Live Restore Enabled: false
Product License: Community Engine

PS /> exit
time="2020-04-22T10:13:36+02:00" level=error msg="Error waiting for container: failed to shutdown container: container 55b3e99dc6bfda03d6e0be4ec000f5c6c3ee29e8d973389b0d3f1dbaea6cdaf4 encountered an error during hcsshim::System::waitBackground: failure in a Windows system call: The virtual machine or container with the specified identifier is not running. (0xc0370110): subsequent terminate failed container 55b3e99dc6bfda03d6e0be4ec000f5c6c3ee29e8d973389b0d3f1dbaea6cdaf4 encountered an error during hcsshim::System::waitBackground: failure
in a Windows system call: The virtual machine or container with the specified identifier is not running. (0xc0370110)"
docker version
Client: Docker Engine - Community
Version:           19.03.8
API version:       1.40
Go version:        go1.12.17
Git commit:        afacb8b
Built:             Wed Mar 11 01:23:10 2020
OS/Arch:           windows/amd64
Experimental:      true
Server: Docker Engine - Community
Engine:
Version:          19.03.8
API version:      1.40 (minimum version 1.24)
Go version:       go1.12.17
Git commit:       afacb8b
Built:            Wed Mar 11 01:37:20 2020
OS/Arch:          windows/amd64
Experimental:     true
docker info
Client:
Debug Mode: false
Plugins:
app: Docker Application (Docker Inc., v0.8.0)
buildx: Build with BuildKit (Docker Inc., v0.3.1-tp-docker)
Server:
Containers: 7
Running: 1
Paused: 0
Stopped: 6
Images: 377
Server Version: 19.03.8
Storage Driver: windowsfilter (windows) lcow (linux)
Windows:
LCOW:
Logging Driver: json-file
Plugins:
Volume: local
Network: ics internal l2bridge l2tunnel nat null overlay private transparent
Log: awslogs etwlogs fluentd gcplogs gelf json-file local logentries splunk syslog
Swarm: inactive
Default Isolation: hyperv
Kernel Version: 10.0 18363 (18362.1.amd64fre.19h1_release.190318-1202)
Operating System: Windows 10 Enterprise Version 1909 (OS Build 18363.752)
OSType: windows
Architecture: x86_64
CPUs: 12
Total Memory: 31.81GiB
Name: LT-BAP-T-NL
ID: AVXB:O6GT:DLC7:DZXN:OF46:3QIY:GANI:BMDV:R2TY:LN27:ZH44:YZ6X
Docker Root Dir: C:\ProgramData\Docker
Debug Mode: true
File Descriptors: -1
Goroutines: 49
System Time: 2020-04-22T10:13:53.2893047+02:00
EventsListeners: 1
Registry: https://index.docker.io/v1/
Labels:
Experimental: true
Insecure Registries:
<IP_ADDRESS>/8
Live Restore Enabled: false
Product License: Community Engine
cc: @StefanScherer , @simonferquel

I can reproduce on same versions. Seems to be a LCOW only issue. Works fine when engine is Linux (with WSL2 backend)

I can reproduce as well, running
Windows: 19608.1006
Docker Desktop: <IP_ADDRESS> (44472)
Docker Engine: 19.03.8

I can reproduce on same versions. Seems to be a LCOW only issue. Works fine when engine is Linux (with WSL2 backend)

Correct, no issue if the engine is set to Linux, we need the docker context @simonferquel

Same for me on 1909
Docker Desktop : <IP_ADDRESS>
Docker Engine: 19.03.8

I see have the same on the stable channel
Docker Desktop <IP_ADDRESS>

Windows 10.0.19041.208
Docker Desktop: <IP_ADDRESS> (44472)
Docker Engine: 19.03.8

I see have the same on the version stable.
Docker version 19.03.8, build afacb8b

Same here across 3 different computers.

They broke it with version <IP_ADDRESS>. Uninstalling Docker Desktop and installing version <IP_ADDRESS> resolved the issue. Noticed that they added a "Known issue" to the release notes for <IP_ADDRESS> saying:
"Some CLI commands fail if you are running Docker Desktop in the experimental Linux Containers on Windows (LCOW) mode. As alternatives, we recommend running either traditional Linux containers, or the experimental WSL backend."
Funny way of saying we broke the most fundamental thing of LCOW, please use a virtual machine instead.

Sad part is that this was working just 2 0.0.0.x versions ago. Completely breaking a feature as important as LCOW (even an experimental one) and putting a small aside in the release notes as "some cli commands fail" is pretty ridiculous.

The command '/bin/sh -c apk add --update redis' returned a non-zero code:<PHONE_NUMBER>: failed to shutdown container: container a0ec71fb66524cdd30fd9e3ff1501afa288ba6c51bea2255976faaad9889f6f0 encountered an error during hcsshim::System::waitBackground: failure in a Windows system call: The virtual machine or container with the specified identifier is not running. (0xc0370110): subsequent terminate failed container a0ec71fb66524cdd30fd9e3ff1501afa288ba6c51bea2255976faaad9889f6f0 encountered an error during hcsshim::System::waitBackground: failure in a Windows system call: The virtual machine or container with the specified identifier is not running. (0xc0370110)
i am having this error anyone can solve this ?

I have same error on windows. It happens always when dockerfile uses "RUN" command.

The same happen with Windows containers, not only with LCOW.  It work most of the time but sometime, a docker run fail with this message.

I met the same error with the official "Getting Started" docker tutorial. It happens in windows and linux containers too.
D:\temp\tmp2\app>docker build -t getting-started .
Sending build context to Docker daemon  65.67MB
Step 1/5 : FROM node:12-alpine
12-alpine: Pulling from library/node
cbdbe7a5bc2a: Pull complete                                                                                57d481011659: Pull complete                                                                                d6fabc993f17: Pull complete                                                                                834ca887ea10: Pull complete                                                                                Digest: sha256:663da4974c48ef1ac5abd10c432c6a154cb675a0e5ca2324d8f92a1edb8429e2
Status: Downloaded newer image for node:12-alpine
 ---> 1f52b7199ba6
Step 2/5 : WORKDIR /app
 ---> Running in 15c97e428b15
Removing intermediate container 15c97e428b15
 ---> 51e9ba18faad
Step 3/5 : COPY . .
 ---> 927acce29fc9
Step 4/5 : RUN yarn install --production
 ---> Running in 3866d3989bb3
yarn install v1.22.4
[1/4] Resolving packages...
[2/4] Fetching packages...
info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
Done in 20.20s.
The command '/bin/sh -c yarn install --production' returned a non-zero code:<PHONE_NUMBER>: failed to shutdown container: container 3866d3989bb31258f1e259e1face108ab8ac1fcaf64e715bb0f13c00a4b304ab encountered an error during hcsshim::System::waitBackground: failure in a Windows system call: The virtual machine or container with the specified identifier is not running. (0xc0370110): subsequent terminate failed container 3866d3989bb31258f1e259e1face108ab8ac1fcaf64e715bb0f13c00a4b304ab encountered an error during hcsshim::System::waitBackground: failure in a Windows system call: The virtual machine or container with the specified identifier is not running. (0xc0370110)

D:\temp\tmp2\app>docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
<none>              <none>              927acce29fc9        2 minutes ago       199MB
node                12-alpine           1f52b7199ba6        11 days ago         109MB

I don't think there is any solution for now. I just use a virtualbox now.

It happen with WCOW and LCOW.  For linux, of course there is alternative like WSL2 or Hyper-V.  But with Windows, there is no alternative.

Issue is present on server 2019 insider version 2004 build 20236.1000
Tested Docker <IP_ADDRESS> and Docker <IP_ADDRESS>
Step 3/6 : RUN yum install -y epel-release
 ---> Running in b06e80476769
Loaded plugins: fastestmirror, ovl
Determining fastest mirrors
 * base: centos.mirror.fr.planethoster.net
 * extras: centos.mirror.fr.planethoster.net
 * updates: centos.mirror.fr.planethoster.net
Resolving Dependencies
--> Running transaction check
---> Package epel-release.noarch 0:7-11 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package                Arch             Version         Repository        Size
================================================================================
Installing:
 epel-release           noarch           7-11            extras            15 k

Transaction Summary
================================================================================
Install  1 Package

Total download size: 15 k
Installed size: 24 k
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : epel-release-7-11.noarch                                     1/1
  Verifying  : epel-release-7-11.noarch                                     1/1

Installed:
  epel-release.noarch 0:7-11

Complete!
The command '/bin/sh -c yum install -y epel-release' returned a non-zero code:<PHONE_NUMBER>: failed to shutdown container: container b06e8047676935a1dc2944e5152a909f75526ae69f708e48e1403d72fbce2cc7 encountered an error during hcsshim::System::waitBackground: failure in a Windows system call: The virtual machine or container with the specified identifier is not running. (0xc0370110): subsequent terminate failed container b06e8047676935a1dc2944e5152a909f75526ae69f708e48e1403d72fbce2cc7 encountered an error during hcsshim::System::waitBackground: failure in a Windows system call: The virtual machine or container with the specified identifier is not running. (0xc0370110)```

I uninstalled and re-installed the latest version of the docker. It seems it is working now under WSL2.

Does not work on the latest Docker <IP_ADDRESS> and 2004 with WSL2

This happens for me when I include more than once volume definition in the compose.

I am still seeing this with

Docker Desktop 3.0.0 (50684)
Docker Engine 20.10.0
Windows 2009

Still an issue on

Docker Desktop: 3.1.0(51484)
Docker Engine: 20.10.2
Windows 20H2 (19042.746)

Simple example:
docker image build --platform linux --tag image:test .
Dockerfile
ARG BASE_IMAGE

FROM mcr.microsoft.com/mssql/server:2019-CU8-ubuntu-16.04

USER root

RUN apt-get -y update

Result:
Step 4/4 : RUN apt-get -y update
 ---> [Warning] The requested image's platform (linux/amd64) does not match the detected host platform (windows/amd64) and no specific platform was requested
 ---> Running in e07ea279a061
Get:1 http://archive.ubuntu.com/ubuntu xenial InRelease [247 kB]
Get:2 http://security.ubuntu.com/ubuntu xenial-security InRelease [109 kB]
Get:3 https://packages.microsoft.com/ubuntu/16.04/prod xenial InRelease [4003 B]
Get:4 https://packages.microsoft.com/ubuntu/16.04/prod xenial/main amd64 Packages [205 kB]
Get:5 http://archive.ubuntu.com/ubuntu xenial-updates InRelease [109 kB]
Get:6 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages [1928 kB]
Get:7 http://archive.ubuntu.com/ubuntu xenial-backports InRelease [107 kB]
Get:8 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages [1558 kB]
Get:9 http://archive.ubuntu.com/ubuntu xenial/restricted amd64 Packages [14.1 kB]
Get:10 http://archive.ubuntu.com/ubuntu xenial/universe amd64 Packages [9827 kB]
Get:11 http://security.ubuntu.com/ubuntu xenial-security/restricted amd64 Packages [15.9 kB]
Get:12 http://security.ubuntu.com/ubuntu xenial-security/universe amd64 Packages [983 kB]
Get:13 http://security.ubuntu.com/ubuntu xenial-security/multiverse amd64 Packages [8820 B]
Get:14 http://archive.ubuntu.com/ubuntu xenial/multiverse amd64 Packages [176 kB]
Get:15 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages [2434 kB]
Get:16 http://archive.ubuntu.com/ubuntu xenial-updates/restricted amd64 Packages [16.4 kB]
Get:17 http://archive.ubuntu.com/ubuntu xenial-updates/universe amd64 Packages [1540 kB]
Get:18 http://archive.ubuntu.com/ubuntu xenial-updates/multiverse amd64 Packages [26.2 kB]
Get:19 http://archive.ubuntu.com/ubuntu xenial-backports/main amd64 Packages [10.9 kB]
Get:20 http://archive.ubuntu.com/ubuntu xenial-backports/universe amd64 Packages [12.6 kB]
Fetched 19.3 MB in 3s (6103 kB/s)
Reading package lists...
The command '/bin/sh -c apt-get -y update' returned a non-zero code:<PHONE_NUMBER>: failed to shutdown container: container e07ea279a061592cbbd7ae4ae9f40b10d96e8109770fff87d81db08323cea773 encountered an error during hcsshim::System::waitBackground: failure in a Windows system call: The virtual machine or container with the specified identifier is not running. (0xc0370110): subsequent terminate failed container e07ea279a061592cbbd7ae4ae9f40b10d96e8109770fff87d81db08323cea773 encountered an error during hcsshim::System::waitBackground: failure in a Windows system call: The virtual machine or container with the specified identifier is not running. (0xc0370110)

Downloaded from public: http://maven.aliyun.com/nexus/content/groups/public/org/apache/commons/commons-compress/1.20/commons-compress-1.20.jar (632 kB at 108 kB/s)
[INFO] Replacing main artifact with repackaged archive
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  03:23 min
[INFO] Finished at: 2021-02-21T03:51:36Z
[INFO] ------------------------------------------------------------------------
Service 'backend' failed to build : The command '/bin/sh -c mvn package' returned a non-zero code:<PHONE_NUMBER>: failed to shutdown container: container 4f31232c41ca0eb8c06e838224f56449569d4591e133b49fb84566d5619e5fd6 encountered an error during hcsshim::System::waitBackground: failure in a Windows system call: The virtual machine or container with the specified identifier is not running. (0xc0370110): subsequent terminate failed container 4f31232c41ca0eb8c06e838224f56449569d4591e133b49fb84566d5619e5fd6 encountered an error during hcsshim::System::waitBackground: failure in a Windows system call: The virtual machine or container with the specified identifier is not running. (0xc0370110)
Me too， is there any solution to resolve this.

The command '/bin/sh -c npm install' returned a non-zero code:<PHONE_NUMBER>: failed to shutdown container:
container cd8b3a2e7097ac237b8fb0586b0d4432962d5cc3d856c78ebd5380dff0b90414 encountered an error during hcsshim::System::waitBackground: failure in a Windows system call: The virtual machine or container with the specified identifier is not running. (0xc0370110): subsequent terminate failed container cd8b3a2e7097ac237b8fb0586b0d4432962d5cc3d856c78ebd5380dff0b90414 encountered an error during hcsshim::System::waitBackgground: failure in a Windows system call: The virtual machine or container with the specified identifieri is not running. (0xc0370110)

The command '/bin/sh -c npm install' returned a non-zero code:<PHONE_NUMBER>: failed to shutdown container:
container cd8b3a2e7097ac237b8fb0586b0d4432962d5cc3d856c78ebd5380dff0b90414 encountered an error during hcsshim::System::waitBackground: failure in a Windows system call: The virtual machine or container with the specified identifier is not running. (0xc0370110): subsequent terminate failed container cd8b3a2e7097ac237b8fb0586b0d4432962d5cc3d856c78ebd5380dff0b90414 encountered an error during hcsshim::System::waitBackgground: failure in a Windows system call: The virtual machine or container with the specified identifieri is not running. (0xc0370110)

how to resolve this issue?

I have noticed that I will always get this error if my docker-compose file has a path with spaces in it. Why? Who knows. I want a volume pointing to where my MDF files live in SQL Server Management Studio. Single quotes don't work either for Windows Containers.

Also happens on dockerEE which version greater than 19.03.5

Also happens on dockerEE which version greater than 19.03.5
so it could be fixed by force downgrading the dockerEE version on Server 2019
Install-Package -Name docker -ProviderName DockerMsftProvider -Force -RequiredVersion 19.03.5

Thanks @Kagamia  - I had the same issue with Docker EE on Server 2019 and this works. How did you find that version? I tested downgrading to the versions returned using -AllVersions but only saw these:
Find-Package -Name Docker -ProviderName DockerMsftProvider -AllVersions

Name                           Version          Source           Summary
----                           -------          ------           -------
Docker                         17.06.2-ee-25    DockerDefault    Contains Docker EE for use with Windows Server.
Docker                         18.03.1-ee-12    DockerDefault    Contains Docker EE for use with Windows Server.
Docker                         18.09.14         DockerDefault    Contains Docker EE for use with Windows Server.
Docker                         19.03.17         DockerDefault    Contains Docker EE for use with Windows Server.
Docker                         20.10.6          DockerDefault    Contains Docker EE for use with Windows Server.

@danriggs I'm moving my personal server these days, my old server happen to installed 19.03.5 and it still works for WSL image build, so I tried every minor version on new server ONE-BY-ONE and finally got the last working version.

I've just confirmed that this can still fail on 19.03.5 when building a windows container that has a RUN command in it.

Issue is present on server 2019 insider version 2004 build 20236.1000
Tested Docker <IP_ADDRESS> and Docker <IP_ADDRESS>
Step 3/6 : RUN yum install -y epel-release
 ---> Running in b06e80476769
Loaded plugins: fastestmirror, ovl
Determining fastest mirrors
 * base: centos.mirror.fr.planethoster.net
 * extras: centos.mirror.fr.planethoster.net
 * updates: centos.mirror.fr.planethoster.net
Resolving Dependencies
--> Running transaction check
---> Package epel-release.noarch 0:7-11 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package                Arch             Version         Repository        Size
================================================================================
Installing:
 epel-release           noarch           7-11            extras            15 k

Transaction Summary
================================================================================
Install  1 Package

Total download size: 15 k
Installed size: 24 k
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : epel-release-7-11.noarch                                     1/1
  Verifying  : epel-release-7-11.noarch                                     1/1

Installed:
  epel-release.noarch 0:7-11

Complete!
The command '/bin/sh -c yum install -y epel-release' returned a non-zero code:<PHONE_NUMBER>: failed to shutdown container: container b06e8047676935a1dc2944e5152a909f75526ae69f708e48e1403d72fbce2cc7 encountered an error during hcsshim::System::waitBackground: failure in a Windows system call: The virtual machine or container with the specified identifier is not running. (0xc0370110): subsequent terminate failed container b06e8047676935a1dc2944e5152a909f75526ae69f708e48e1403d72fbce2cc7 encountered an error during hcsshim::System::waitBackground: failure in a Windows system call: The virtual machine or container with the specified identifier is not running. (0xc0370110)```

This is still a problem in mcr.microsoft.com/windows/servercore/insider:10.0.20348.1

Was this ever solved?

A reboot of the device was a functional workaround for me.

For me, a workaround in our CI (Team City) was to ignore the error, and immediately retry again, which skipped all the cached steps, and jumped straight to the problematic step that was giving the error. The 2nd time it worked successfully. Been monitoring this for about 10 builds with consistently successful results.

Yes, this has been going on for years and there has never been any fix for this, it's just really flaky, so people keep announcing they have found a work around because it works once, then they try again and it fails again.
In our CI build we have it retrying 5 times, and sometimes it still fails, and every time it fails, it hangs for 10 minutes before failing. Combine that with the enormous size of some Windows container images and you end up with a CI build that can take over an hour and still fail sometimes, just to run docker build, which should take seconds.
Windows containers are just awful in general. Avoid them like the plague if you can. Even if you get one to work it takes much longer to spin up a windows host to run one on, clouds tend to have less availability of Windows nodes so you hit capacity issues earlier, features are often missing from cloud hosting options when running Windows containers, and Windows containers are not secure. If you have anything tied to Windows-specific tech, just run that in a container, secure it away as well as you can from the outside world, and run Linux containers for everything else.

What about the proposed experimental WSL2.
At the moment, I have Windows Server 2022 with latest updates, that supports WSL2 and I have it installed.
Is there something I need to do in docker EE to explicitly tell it to use WSL2? That could be a potential solution for Windows Server 2022 users?

For us it happens when building a Windows container so the version of WSL does not make any difference, as it happens in Windows container mode.
I run docker desktop for Windows in WSL2 mode and when I build Windows containers this can still happen on any RUN command in the dockerfile.

I really would like that we wouldn't need to use Windows containers, or at very least, why don't we get a proper PowerShell based tool that actually works, without all these Docker issues

Hey,
Same issue for me, but going to a linux container fails for jenkins. It will create volumes as below
-v D:/Jenkins/jenkins_agent1/workspace/multipip_test_master/:D:/Jenkins/jenkins_agent1/workspace/multipip_test_master/
which is windows pathing, and cannot be adapted to linux as far as I know (I cannot edit to add // instead of /)
Am I just not going to be able to use jenkins+docker at all?

I'm facing this issue while building an image using the python package of docker.
Here is my code, it gives me an error from line number 4
image="alpine/git:latest"
repo_dir="repos/CryptoTerminal"
client = docker.from_env()
client.images.build(path=repo_dir) # Build gives error
client.containers.create(image)

Traceback (most recent call last):
  File "C:\Users\kirti\docker_project\run_docker.py", line 23, in <module>
    client.images.build(path=repo_dir)
  File "C:\Users\kirti\docker_project\venv\lib\site-packages\docker\models\images.py", line 306, in build
    raise BuildError(chunk['error'], result_stream)
docker.errors.BuildError: The command '/bin/sh -c pip3 install -r requirements.txt' returned a non-zero code: 1

Just a heads up. I was trying to address some possible HNS issues fixed in/around the KB5018485 timeframe and ended up experimenting with the registry keys here. I wasn't expecting these keys to make an impact on our image pull/rm times, but we noticed a significant improvement on 2019 LTSC with them in place (4x faster docker image pull, 6.4x faster docker image rm). Need to do a little more testing to see whether 0xc0370110 and 0xc0370105 still occur, but I figured I'd pass it along.


update to proj.4 6.0.0

Connected to issue #152
This depends on: https://github.com/OSGeo/proj.4/pull/1208
Also, one of the tests fails, but should be fixed with: https://github.com/OSGeo/proj.4/pull/1205
There are a ton of changes - mostly to work with the new API. Feel free to make comments, ask questions, and be thorough in the review.

Does this really add dependencies on sqlite and cmake?

Does this really add dependencies on sqlite and cmake?

They have moved from csv files to sqlite database:
"The use of a SQLite-based database for EPSG and other definitions will allow the projects to add more capability (area-aware validation), transition the custom peculiar data structures of the projects to something more universally consumable, and promote definition interoperability between many coordinate system handling software tools."
The cmake dependency makes building proj.4 from source very easy. However, there are other methods for compiling proj.4 without cmake. As aside note, if proj.4 is already installed, cmake is not required.

Maybe this would be a good time to remove the bundled proj4 source, and just require the library as a dependency.  Do your additions to the python API require proj4 6.0.0?

I think the changes I made make it required to have the proj.4 source installed to work. It has a step to compile the source for you in the setup.py internally, but that only works when installing locally from a clone of the repo. Otherwise it results in strange behavior with the path to files that should probably be handled better (could look into relative paths?). Otherwise it requires PROJ_DIR to be set beforehand.
The process definitely could be improved, simplified, or the behavior changed. cartopy is potentially a model that could be followed.
To answer your question, yes it will require version 6.0.0 of proj.4 to work due to the API changes.

Most recent wheel for Python 3.6 (worked alongside an older version of PROJ.4 installed for me) generated on Ubuntu 18.04.1: pyproj-2.0.0-cp36-cp36m-linux_x86_64.whl.zip

What needs to be done to get the tests passing?

What needs to be done to get the tests passing?

I think it has to do with the version of pip: https://pip.pypa.io/en/stable/reference/pip/#pep-517-and-518-support. I am pinning to pip>=10.0.1 and testing.

worked alongside an older version of PROJ.4 installed for me

For clarification, I have an older version of PROJ.4 on the system and the new version of PROJ.4 (6.0.0) in the wheel does not conflict with it.

The Python 2.7 & 3.6 manylinux wheels build okay, but the 3.4, 3.5, and 3.7 versions are not including the proj_data directory for some reason.

All manylinux wheels build properly now.

This is fantastic!

Looks like we will be able to merge this and make a new release when proj4 6.0.0 is released (supposedly March 1?)

The README should probably mention that proj4 version 6.0.0 is required.

@jswhit I definitely hope that pyproj can be released along with the next version of PROJ.4.
What are your thoughts about:

[ ] Using coveralls
[ ] Using pytest for testing instead of nose2
[ ] Switching to Sphinx for docs (you mentioned you may be interested above)

An example .travis.yml using pytest with coveralls is here.

I don't have an opinion on coveralls and pytest - I'll defer to those who know more about testing frameworks.  Switching to sphinx for docs really needs to be done before the release.

Sounds like a good plan to me. The test framework currently in use works fine, so a decision on that can be postponed to after the release. Would it be helpful for me to to add Sphinx docs to this PR?

Great! I think this is ready to merge now - what do you think @snowman2 and @micahcochran?   After merging, I'll create a ticket for sphinx doc updates which should be done before a release.

@jswhit, sounds good to me. No issues here. Do you have access to the windows wheels uploaded as artifacts in Appveyor?

Found them:
https://ci.appveyor.com/api/buildjobs/235jw58mg0qsi9xr/artifacts/dist%2Fpyproj-2.0.0-cp35-cp35m-win_amd64.whl
https://ci.appveyor.com/api/buildjobs/964dt9t1n9d27709/artifacts/dist%2Fpyproj-2.0.0-cp36-cp36m-win_amd64.whl
https://ci.appveyor.com/api/buildjobs/so47mvw7a53a7lsm/artifacts/dist%2Fpyproj-2.0.0-cp37-cp37m-win_amd64.whl
I am curious how they work. Need to test on a windows machine.
Should this release drop support for Python 2.7 since it it dies this year? Or do you want to add the Python 2.7 build back in appveyor?

The windows wheels are faulty. I have some ideas to try if you don't mind holding off merging for a bit.

The wheels with the proj.lib & sqlite3.dll aren't working either. Not sure why. Well, feel free to merge anyway and maybe an issue can be made to look into it later.


Installing error

Copying "package" to "C:\Users\91828\Documents\maya"...

ROBOCOPY     ::     Robust File Copy for Windows
Started : Tuesday, October 27, 2020 6:29:35 PM
Source : C:\WINDOWS\system32\package
Dest : C:\Users\91828\Documents\maya\
Files : *.*

Options : . /S /E /DCOPY:DA /COPY:DAT /R:1000000 /W:30

2020/10/27 18:29:35 ERROR 2 (0x00000002) Accessing Source Directory C:\WINDOWS\system32\package
The system cannot find the file specified.
Done. Press ENTER to exit.
Press any key to continue . . .
this error i am facing

Can you extract the installer ZIP file to your Desktop, e.g. in your case C:\Users\91828\Desktop\Maya2glTF, and run the batch file from that location? I'm not sure how you ended up extracting it in C:\WINDOWS\system32\package, but that folder requires administrator access.

Thank you so much for your reply. I am using your older version 1.1.0 of
Gltf exporter. It's working fine now.
[image: image.png]
Thank you so much for this tool.
On Tue, 27 Oct, 2020, 7:03 PM Peter Verswyvelen<EMAIL_ADDRESS>wrote:

Can you extract the installer ZIP file to your Desktop, e.g. in your case
C:\Users\91828\Desktop\Maya2glTF, and run the batch file from that
location? I'm not sure how you ended up extracting it in
C:\WINDOWS\system32\package, but that folder requires administrator
access.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/iimachines/Maya2glTF/issues/142#issuecomment-717246506,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ARQ7HKRKVZN53WBNE7QB77DSM3D4BANCNFSM4TAZNGTA
.


Correct azure storage type

According to https://rclone.org/azureblob/, the storage type for Azure is "azureblob" and not "azure blob storage".
This PR corrects that.

Hi @jgleonard, Thank you for this PR, it looks good!


Refactored module to use modern syntax and language features

I discovered your module and thought I could give it a quick polish :)
The changes are backwards-compatible of course.

Closing for inactivity


chore: remove deprecated createXxxx on MessengerBatch

In v0.8, all of MessengerBatch.createXxx will not be supported. Use MessengerBatch.sendXxx instead.
const { MessengerBatch } = require('messaging-api-messenger');

client.sendBatch([
  MessengerBatch.sendText(USER_ID, '1'),
  MessengerBatch.sendText(USER_ID, '2'),
  MessengerBatch.sendText(USER_ID, '3'),
  MessengerBatch.sendText(USER_ID, '4'),
  MessengerBatch.sendText(USER_ID, '5'),
]);

Codecov Report

Merging #448 into master will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #448      +/-   ##
==========================================
- Coverage   97.15%   97.14%   -0.02%
==========================================
  Files          13       13
  Lines         950      945       -5
  Branches      129      129
==========================================
- Hits          923      918       -5
  Misses         26       26
  Partials        1        1

Impacted Files
Coverage Δ

...ages/messaging-api-messenger/src/MessengerBatch.js
97.56% <ø> (-0.17%)
:arrow_down:

...ges/messaging-api-messenger/src/MessengerClient.js
98.99% <ø> (-0.01%)
:arrow_down:

Continue to review full report at Codecov.

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


playwright upload script(2hrs)

[x] Login script
[x] playwright upload script  (use puppeteer script, https://github.com/zhang0peter/youtube-upload-multi-videos) (https://github.com/microsoft/playwright/issues/4686) (use solutions provided in github to solve the issue)
[x] script to change details of uploaded file
[x] save already uploaded links
[x] subtitle yt language -> edition mapping (diff from hardcoded)
[x] Make meta data gen code
[x] Take user & pass from text/config file(git ignore it) , so I can atleast use git
[ ] Merge All with err handling
[ ] upload all subs (60mins)
[ ] upload all Translated titles & Description for each sub (if possible) (30mins)
[ ] group playlist wise (create playlist only at chap 1 & save the playlist name in state)

remember use translated meta, during upload

Design:


Feat/initial topology implementation

Implements a Stream Processing Topology which continuously reads CØSMOS transactions from an input Kafka topic,and serialize them them to an output topic as JSON.

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


Set StartupWMClass correctly for nightly builds

Fixes https://github.com/vector-im/element-web/issues/13780

Replaced by https://github.com/vector-im/element-desktop/pull/526


[BUG] It seems WingetGUI is totally ignoring the --override options

Please confirm these before moving forward

[X] I have searched for my issue and not found a work-in-progress/duplicate/resolved issue.
[X] I have tested that this issue has not been fixed in the latest (beta or stable) release.
[X] I have checked the FAQ section for solutions
[X] This issue is about a bug (if it is not, please use the correct template)

Describe your issue
It seems WingetGUI is totally ignoring the --override options
I tried:
winget install -e --id SomePythonThings.WingetUIStore  --accept-package-agreements  --accept-source-agreements   --silent  --disable-interactivity  --override "/NoAutoStart /ALLUSERS /silent /supressmsgboxes /norestart"
The override options are just ignored
Steps to reproduce the issue
No response
WingetUI Log
-

Package Managers Logs
-

Relevant information
No response
Screenshots and videos
No response

Running WingetUI.Installer.exe with this parameters does work?


No file of "pytorch_ipynb/mlp/mlp-sequential.ipynb"

In the folder of  pytorch_ipynb/mlp,I can't find the file "Sequential API and hooks [PyTorch]“.

Thanks for the note. It should have been /mechanics not /mlp. Just fixed that link: https://github.com/rasbt/deeplearning-models/blob/master/pytorch_ipynb/mechanics/mlp-sequential.ipynb


Using sar_disable_challenge_stats_hud 1 results in same voice line

Having sar_disable_challenge_stats_hud set to a value of 1 results in the voice line "Maybe I was wrong about you" for any finished time. No matter if it was a PB or not.

I've tried to fix this by reimplementing sar_disable_challenge_stats_hud to actually open challenge mode HUD for a split second (read the comment in that commit), but that not only seems inconsistent (leaderboards seem to open at random time for whatever reason) but difficult without spending more time on it. Either needs to be investigated again or abandoned completely once we figure out an alternative for in-game leaderboards (leaderboards+ soon? 👀)

Alternatively having a separate command something like sar_challenge_stats_close <X amount of ms> could be something nice to have as it could be customized more in coop and would possibly fix the voice line issue.

As talks about Funnel Catch spawns have started one thing that is certain is that if both players wait for the cm menu to pop up the resulting time is almost always a 2.48 (within a tick). Having something that can close the menu after a set amount of time will not only help test the spawns but also probably fix the voice line problem.

Technically solved with 48fbab97bc3b8d4e258e7a7c1fe3d4077b47e612 but should still be looked into why the old implementation doesn't work.

So the new approach of waiting after the leaderboard opens to close it works, but now it seems to choose between two voicelines instead (the infamous "maybe i was wrong about you" and "youre getting worse"). based on the observation that the time it takes to open is slightly random (3-4ish ticks after +leaderboard), that leads me to the hypothesis that the voiceline is pseudo-randomized each tick it's visible or exists or something. so if it were never visible it would never randomize and have the same voiceline. i did some investigation a while back and found that m_pLeaderboard->DoGladosSpokenReaction is the relevant function, but I have no source for it.


Export datacubes in FITS format

For compatibility with other software e.g. ds9, gist.
Belongs in a new method IFUCube.export_as_fits
@Chia-vie - inspired by looking over datacubes with you :P

Needed to run with Bayes-LOSVD...


API Record Calls do not work with multiple records,

Calls like /api/record/ucdrp:person/b78c058911b45047c56f3b5148381715,ucdrp:person/f9ef1e530c617cd598171497b4a49e82
Return un-expanded JSON objects.
["ucdrp:person/b78c058911b45047c56f3b5148381715","ucdrp:person/f9ef1e530c617cd598171497b4a49e82"]

fixed in dev with 9292bb1707be725ea42bb8f548ae55641f965c3c, created a sandbox PR for @jrmerz


Progressive JPEGs support

This feature would replace the progress indicator. Not sure if it's working on SDWebImage:
https://github.com/rs/SDWebImage/issues/1164
https://github.com/rs/SDWebImage/issues/1671

Good one @bre7 - we're looking to replace SDWebImage with an out of the box solution to get rid of the dependency or either replace it with PINRemoteImage 😄

Nice. I replaced it with PINR in a custom fork since I was already using it in an app.

Awesome - how are things looking with it? Would love to gain insight on your experience with it and see how things went. PINRemoteImage would be great for us since we already use ASDK all throughout Buffer.

PINRI is great: deals with caching (it's a separate lib for now, PINCache, I think there were plans to decouple the dependency), adds easy-to-use categories for several UI components, supports GIF/WebP/PJPEG, etc. That's why I submited #35, to allow each dev to use SDWI or any other image fetching library, though it's easier said than done. I think I managed to use it with my swift-only fork.
I've been wanting to try ASDK for the past year or so 😢

Thanks for adding this one @bre7. We have been working on switching out SDWebImage for PINRemoteImage within the Buffer project so will have this one done shortly within the Image Viewer. 👍

Awesome !

PINRemoteImage branch is over at https://github.com/bufferapp/buffer-ios-image-viewer/tree/task/pinremoteimage-plus-animated-gif-support will be trying this out a bit before merging.

👍 I'll give it a try this weekend. I've used PINRI with progressive JPEGs before and it has always worked flawlessly.

Notes:

If the user chooses to use `setPin_updateWithProgress:YES' (there's no API in the image viewer for this) then the progress view (DACircularProgressView) shouldn't be created.

Closing this one down as we've got PINRemoteImage in (merge also added gif support). We'll need to think about that setPin_updateWithProgress: scenario @bre7 mentioned as well 👍

Bump
Just a reminder, since this functionality should also ignore the new "URL Backloading" feature.

Hey @bre7 👋 - are you using a custom fork that uses updateWithProgress out of curiosity? Wondering if that should be something that API consumers can tweak with the image viewer (right now it's hardcoded not to). If it was, then we'd need to branch the logic as you mentioned if it's on with the progress indicator.

Hey Jordan, right now I'm using it out of the box but was planning on adding updateWithProgress. Also, am I not getting the point of or is backloading almost the same as PINRemoteImage's placeholder ?

Heya @bre7 sorry I missed this notification - you're right that they server almost the same exact purpose. The main reason is we might not always use PINRemoteImage and wanted all the control over the process.
Enabling progress does need better support, for a few different reasons progressive image loading isn't being used in Buffer which is the main reason why I haven't messed with it here. But in this library I think it makes sense to include. Will reopen this issue to revisit 👍