Add docs for ASN1_item_sign and ASN1_item_verify functions

This is to address part of issue #13192.

Checklist

[x] documentation is added or updated
[ ] tests are added or updated

The travis failure seems very strange - but unrelated to this PR.

Yes that is a bit weird..

Quite frankly, I'd like to throw these functions as far away as I can.  They are 100% geared for legacy, the entanglement with EVP_PKEY_ASN1_METHOD ctrl functions runs deep...

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

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

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

ping

This pull request is ready to merge

Thanks. Merged to master.


Add darwin64-arm64-cc build target for OpenSSL 1.1.1

This adds support for the Apple Silicon M1 hardware to OpenSSL 1.1.1 on macOS Big Sur and enables aarch64 assembly.
The changes have been adapted from master and were verified using an Apple MacBook Air (2020, M1) running macOS 11.1 Beta (20C5048l) and have been compiled with Xcode 12.3 beta (12C5020f).
The test suite passes and benchmarks show the expected speed-ups.
Related #12591 Fixes #12254

Benchmark Results
Benchmarks were done on an Apple MacBook Air (2020, M1) with 16GB RAM on macOS 11.1 Beta  (20C5048l).
Before Patch
$ openssl speed -evp aes-128-ctr
OpenSSL 1.1.1h  22 Sep 2020
built on: Sun Nov 22 20:29:09 2020 UTC
options:bn(64,64) rc4(int) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: clang -fPIC -arch arm64 -O3 -Wall -DL_ENDIAN -DOPENSSL_PIC -D_REENTRANT -DNDEBUG
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-ctr     296743.83k   303441.83k   303945.05k   301039.96k   301049.15k   300764.21k
$ openssl speed -evp aes-128-gcm
OpenSSL 1.1.1h  22 Sep 2020
built on: Sun Nov 22 20:29:09 2020 UTC
options:bn(64,64) rc4(int) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: clang -fPIC -arch arm64 -O3 -Wall -DL_ENDIAN -DOPENSSL_PIC -D_REENTRANT -DNDEBUG
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-gcm     170056.28k   172320.83k   167888.40k   167156.53k   167220.57k   167308.59k
$ openssl speed -evp chacha20-poly1305
OpenSSL 1.1.1h  22 Sep 2020
built on: Sun Nov 22 20:29:09 2020 UTC
options:bn(64,64) rc4(int) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: clang -fPIC -arch arm64 -O3 -Wall -DL_ENDIAN -DOPENSSL_PIC -D_REENTRANT -DNDEBUG
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
chacha20-poly1305   272939.17k   367433.11k   359265.71k   356910.42k   355388.07k   355068.59k

After Patch
$ openssl speed -evp aes-128-ctr
OpenSSL 1.1.1h  22 Sep 2020
built on: Sun Nov 22 21:07:38 2020 UTC
options:bn(64,64) rc4(int) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: clang -fPIC -arch arm64 -O3 -Wall -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-ctr    1132263.40k  3529939.22k  7579524.52k  9961685.33k 10911386.28k 11001217.02k
$ openssl speed -evp aes-128-gcm
OpenSSL 1.1.1h  22 Sep 2020
built on: Sun Nov 22 21:07:38 2020 UTC
options:bn(64,64) rc4(int) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: clang -fPIC -arch arm64 -O3 -Wall -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-gcm    1115565.20k  3058913.96k  4781916.30k  4637353.98k  4537237.50k  4602647.89k
$ openssl speed -evp chacha20-poly1305
OpenSSL 1.1.1h  22 Sep 2020
built on: Sun Nov 22 21:07:38 2020 UTC
options:bn(64,64) rc4(int) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: clang -fPIC -arch arm64 -O3 -Wall -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
chacha20-poly1305   384908.34k   582412.41k  1081279.31k  1727471.90k  1744085.02k  1740851.71k

Updated to split the CHANGES to a separate commit. This makes it easier to apply a patch to older 1.1.1 versions.

@felixbuenemann Is this PR not almost identical to #12369? The only difference is that this one updates the changelog. That PR has already been discussed, but is blocked from merging because OpenSSL 1.1 is in "bugfix only" mode and the maintainers believe that it is a stretch to call darwin-arm64 support a "bugfix". The OMC is currently discussing whether to create a new LTS+ release in parallel to the LTS release that can add support for new platforms.

Added the OMC hold label as per the comment above. Probably though this should be closed  in favour of the pre-existing #12369.

Yes, #12369 is fine, this can be closed as a dupe.
Isn't fixing ASM support on Darwin arm64 a bugfix? This doesn't add any new code to support it.

So to elaborate on the current situation:

When adding patches to Homebrew Formulae, the patches have to be pushed upstream, which is what I did here (sorry for the dupe).
This change is configuration only, the chance to break existing targets is zero.
The existing aarch64 assembly code is tested on iOS via ios64 assembly target.
The M1 chip is an evolution of those ARMv8 chips (it is ARMv8.4 compatible) and can even run existing iOS apps without emulation, showing it is indeed fully compatible.

Duplicate of #12369

@felixbuenemann Do you want to close this PR and post your elaboration comment in the main PR?

@richiksc Yeah, let's not split the discussion.

@felixbuenemann, I wonder why Apple's OpenSSL doesn't see these speed-ups even though it's compiled natively?
i.e LibreSSL 2.8.3,
/usr/bin/openssl: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
/usr/bin/openssl (for architecture x86_64):	Mach-O 64-bit executable x86_64
/usr/bin/openssl (for architecture arm64e):	Mach-O 64-bit executable arm64e

@felixbuenemann, I wonder why Apple's OpenSSL doesn't see these speed-ups even though it's compiled natively?
i.e LibreSSL 2.8.3,

Not much to wonder, since libressl 2.8.3 has zero armv8 assembly code:
https://github.com/libressl-portable/openbsd/tree/libressl-v2.8.3/src/lib/libcrypto/aes/asm
Note that  /usr/bin/openssl on macOS is mostly there for compatibility with scripts and apps calling it for example to generate certificates. You cannot link to it or anything like that.
You will get better speeds with arch -x86_64 /usr/bin/openssl speed … since Rosetta 2 translates the x86_64 SIMD instructions to equivalent arm64 code. I won't post complete benchmarks here to avoid confusion between LibreSSL and OpenSSL, but the translated x86_64 code reaches about 65% of the arm64 ASM results above for aes-128ctr.


2D Renderer Z scale is wrong

It seems the Contour and TwoDData renderers are scaling their height variables too much.
To reproduce:

Spin up Vapor, import a katrina file (/glade/p/cisl/vast/vapor/data/wrf/katrina)
Create a Contour or TwoDData renderer and apply the HGT height variable.  HGT has a maximum value of ~285 meters, however the rendering will exceed the +z side of the bounding box, which is ~3e6 meters.

.

Dataset in question was corrupt.

hi! how did you find that it was corrupted? im having the same issue

@sgpearse can you respond to this?


Problems when generating report

Found 2 problems when generating reports:

Some EC2 instances might not have Tags
Security groups are declared as set and cannot be serialized to JSON

Thanks for finding these and sending in the PR!


Enable sdcmonitor

Description
Adding support to sdc-monitor for powerflex driver through operator.
GitHub Issues
List the GitHub issues impacted by this PR:

GitHub Issue #

https://github.com/dell/csm/issues/477

Checklist:

[x] I have performed a self-review of my own code to ensure there are no formatting, vetting, linting, or security issues
[x] I have verified that new and existing unit tests pass locally with my changes
[ ] I have not allowed coverage numbers to degenerate
[ ] I have maintained at least 90% code coverage
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have maintained backward compatibility

Screenshots of sdc-monitor container:
The driver is working fine without any restarts with sdc-monitor enabled :

The container sdc-monitor is enabled when described worker node.

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Please also list any relevant details for your test configuration

[ ] Test A
[ ] Test B

Update with GitHub issue #.This is part of CSM operator feature, so you can include that.

Also, can you add some way for others to know that the SDC monitor side-car was deployed in the PR?

can we add unit tests for the new code added?

Are we able to disable the sdc-monitor car?
I see in samples,
https://github.com/dell/csm-operator/blob/8fe5a4c8bd2933bcf3d44ee0b133f01b74b595e4/samples/storage_csm_powerflex_v240.yaml#L41
but in screenshot its enabled

2.3 and 2.4 should both support enable/disable sdc-monitor
can we add the enable/disable flag to this section: https://github.com/dell/csm-operator/blob/8bb767883348cbfe4de48c79abcab74dc74dc069/samples/storage_csm_powerflex_v230.yaml#L38 as well?

Are we able to disable the sdc-monitor car? I see in samples,
https://github.com/dell/csm-operator/blob/8fe5a4c8bd2933bcf3d44ee0b133f01b74b595e4/samples/storage_csm_powerflex_v240.yaml#L41
but in screenshot its enabled

Yes, we can disable/enable it manually. By default it will be disabled.


Fixed handleTutorial double invocation

-Put handleTutorial invocation behind a check for the "mapDidLoad" event
Reasoning: While working on animation cancelling, this "double invocation" would cause unexpected behavior due to several duplicate async functions being called

Does this correspond to an open issue?
What does putting handleTutorial behind mapDidLoad change or fix?

Does this correspond to an open issue?
What does putting handleTutorial behind mapDidLoad change or fix?

This was something I encountered while working on animation cancelling. Since handleTutorial was being invoked twice (once on "mapDidLoad" and again on "levelDidLoad"), it would cause the cancellation to behave in unexpected ways. I'll add this to the initial comment, since this PR seems kind of random otherwise haha

I know we did a review of animation cancelling and did some feedback on it.
Is this PR still relevant in light of that review?

Is this PR still relevant in light of that review?

It's hard to say. Depending on how we implement animation cancelling (even with the event based approach), this may still cause unintended behavior


Store output of SciUnit tests in S3 bucket

SciUnit tests convey more information than ordinary unit tests.  Ultimately, to have a standalone information dashboard for SciUnit, we would like to have the output of these tests stored in an S3 bucket.
See also:

https://github.com/joebowen/model_completion_dashboard
http://docs.openworm.org/en/latest/Projects/muscle-neuron-integration/#model-completion-dashboard
#184 and #186

@rgerkin @slarson @cheelee

@gsarma @slarson @cheelee
I had originally envisioned using S3 for this, as Travis has very simple deployment of artifacts to S3 buckets.
However, S3 does cost money, and as cheap as it is (the bill will probably be in the ones of dollars total for the first few months) it will go up cumulatively as long as we are adding new testing artifacts.  As we test more things, more often, this could conceivably grow larger than any person feels comfortable paying.
So I'd like to entertain a free option, like Google Drive.  Thoughts?

That sounds reasonable to me, and of course, we can shift things to S3 in the future if it seems like the right thing.  As for now, will it be as straightforward as using S3?
Also referencing #144 and #145 as we should also be storing timing information in order to catch performance regressions.

Using OpenWorm S3 credentials provided by email.

What is the status of this?


WIP FE changes

Signed-off-by: Lucas O'Neil<EMAIL_ADDRESS>

https://pr-94-showcase-app-dev.apps.silver.devops.gov.bc.ca/


strict option mentioned in documentation does not seem to exist

Describe the bug
The documentation (https://lark-parser.readthedocs.io/en/latest/classes.html) refers to a strict option to Lark that does not seem to exist.
To Reproduce
parser = Lark(grammar, strict=True)

results in the following exception
lark.exceptions.ConfigurationError: Unknown options: dict_keys(['strict'])

What version of lark are you using? print(lark.__version__)

I thought I was using 1.2.2 but also had 1.1.1 on my system that was being picked up. PEBKAC. Sorry for the noise.


Improve the text at the top of the home page.

Received the latest home page text from the product team.

Loks good


Minor issues of WebUI

These are low priority issues and are not expected to fix by v1.0 due.

The width of some containers are incorrect on certain resolution/dpi/scale. I can't reproduce it on other devices. May be an antd bug.
Cannot search hyper-parameters by field (e.g. "conv_size: 5"). I don't know if "real" users will do this.
Mouse wheel is not functional in experiment error log window.
Refreshing/reopening the page clears most states.

@lvybriage could you update the status related to this issue?


MotionEvent.source does not contain InputDevice.SOURCE_MOUSE

Steps to reproduce
In MotionEvents triggered by a mouse, i found that they do not contain InputDevice.SOURCE_MOUSE in source even though i was using a mouse. ACTION_BUTTON_PRESS/RELEASE is not triggered in onGenericMotion  either.
I know WSA emulate mouse inputs as touches, is it why they do not have InputDevice.SOURCE_MOUSE in any MotionEvent? This emulation also causes the scroll wheel to be handled differently.
Google has this which allows developers to opt out of emulation by adding this to manifest, maybe WSA can use this or provide something similar?
<uses-feature
  android:name="android.hardware.type.pc"
  android:required="false" />

✔ Expected Behavior
probably have a way to opt out of input emulation
❌ Actual Behavior
see above
Other Software
No response
Please specify the version of Windows Subsystem for Android
2301

Thanks for the quick response and the info! It's surprising to me that even ChromeOS have this issue too (i don't have ChromeOS device, but I tried on Pixel with OTG mouse which input works perfectly and does report the correct source and button_press/release events). Is there an open external issue in Google's issue tracker for it?
https://learn.microsoft.com/en-us/windows/android/wsa/#mouse-input gives me the impression that WSA will reports correct input source, i guess this needs updating.

Thanks for the quick response and the info! It's surprising to me that even ChromeOS have this issue too (i don't have ChromeOS device, but I tried on Pixel with OTG mouse which input works perfectly and does report the correct source and button_press/release events). Is there an open external issue in Google's issue tracker for it?
https://learn.microsoft.com/en-us/windows/android/wsa/#mouse-input gives me the impression that WSA will reports correct input source, i guess this needs updating.

Unfortunately, this is a problem with third party apps rather than AOSP itself. It presents a tough trade off between app compat and input fidelity for apps that are doing the right thing. We'll keep this issue updated as we make progress on a solution.

We have several customers asking for WSA support of our components, but this is blocking us from doing so.
The WSA documentation on input clearly states what we need to do, with no mention that we can't actually do it or mentioning any current limitations with it.


az afd secret create not working

This is autogenerated. Please review and update as needed.
Describe the bug
Command Name
az afd secret create
Errors:
(InternalServerError) The server encountered an internal error. Please try again later.
Code: InternalServerError
Message: The server encountered an internal error. Please try again later.

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az afd secret create --resource-group {} --profile-name {} --secret-name {} --use-latest-version {} --secret-source {}

Expected Behavior
The secret (certificate) can be added from the keyvault it's in.
Environment Summary
Windows-10-10.0.22000-SP0
Python 3.8.9
Installer: MSI

azure-cli 2.34.1

Extensions:
front-door 1.0.16

Dependencies:
msal 1.16.0
azure-mgmt-resource 20.0.0

Additional Context
This doesn't work with the CLI or with the portal.

route to CXP team

For additional information, this error seems to occur when the tenant-based Service Principal has not been added. After adding it, this error doesn't occur anymore. Not closing the ticket, since the error information could be clearer.

@LotteVoorhorst I am not able to reproduce this.  I have tried this without adding CDN profile service principal to Key vault access policy and getting the correct error information -

I am using the same extension version as yours.

@LotteVoorhorst We will now proceed to close this thread as we haven't heard back. If there are further questions regarding this matter, please reopen it and we will gladly continue the discussion.


JobSelectionPolicy is un-used for the requester node

Both the Compute and Requester Node support a JobSelectionPolicy. At present, the Requester node accepts a policy in its configuration but fails to apply/use it anywhere. The task here is to re-enable support for the JobSelectionPolicy in the Requester Node.

This issue was discovered while investigating #2898 will will follow the fix there.

The removal of the JobSelectionPolicy from the requester was made while upgrading to the evaluation broker via: https://github.com/bacalhau-project/bacalhau/pull/2681/files#diff-db482b8c1643fdf50b3648bd443784dfa31ceac24f6c6994f421c42f73d419eaL132-L137
I believe we'll need to incorporate the previous logic of the JobSelectionPolicy into the Evaluation Brokers NodeRanker to preserve existing behavior.

Stale?

I think it's still an issue and we should still look to restore this feature. Stopping jobs that don't meet policy should be done as early as we can, i.e. in the Requester.

we can close this as we are moving more towards config files instead of cli flags to configure nodes #4014


Mark fields depending on source as optional *

As discussed in #48, language and framework should be *optional, because they only need to be included if we have source (which in turn is only required for some of the weight formats).

closes https://github.com/bioimage-io/configuration/issues/53

Pending #54


Add headless support

I followed the style of the openvpn-install repository and used some of its code. Thanks to everyone that contributed there.
The other additions are:

Allow customization of IP and NIC in headless mode, useful for servers with multiple IPs. openvpn-install repo will need this change too.

To consider:

The headless addition of an user will block the script waiting for a free IP if the one inserted is already in use. I'd suggest to handle the IP management of the clients automatically as happens with OpenVPN and users that want a specific IP for a device can manually edit the configuration files. Other suggestions, for example exiting instead of asking again for an IP (it isn't very friendly when the script is run interactively), are welcome.

The headless revocation of an user isn't friendly because we ask for a client number instead of a client name. openvpn-install repo will need this change too.

Changes aren't tested. PR is a draft while waiting for feedback on the above considerations @angristan .
Fix #21
EDIT: I've pushed some commits that would help with the above issues. Phrasing can be made more clear, but it's ready for review.

@angristan would love to see this included


Fix base branch for update-inspektor-gadget-version

The workflow run failed with an error message:
fatal: couldn't find remote ref master
Error: The process '/usr/bin/git' failed with exit code 128

@eiffel-fl it seems we need to enable settings to create PRs at ORG and REPO level as explained here. I don't have access to them by any chance you have it?

Okay Great. It works now, we have our PR ready! :partying_face:


Release new version

PyO3 is about to release a new version where it stops requiring nightly Rust. I'll release the latest Rust+Python taxonomy once this is out so it's more reliable.
Note to myself: I might need to do a PR to maturin to bump the Rust version of the Dockerfile to use a known working stable Rust.

0.5 released on crates.io and pypi


Basic example failing with RuntimeErrror: Failed to allocate tensors.

I tried running the latest beta release (1.9.2) on a Pi Zero W with the first run demo in the documentation. The following error occurred:
Traceback (most recent call last):
  File "classify_image.py", line 67, in <module>
    main()
  File "classify_image.py", line 58, in main
    engine = ClassificationEngine(args.model)
  File "/usr/local/lib/python3.5/dist-packages/edgetpu/classification/engine.py", line 38, in __init__
    super().__init__(model_path)
  File "/usr/local/lib/python3.5/dist-packages/edgetpu/swig/edgetpu_cpp_wrapper.py", line 308, in __init__
    this = _edgetpu_cpp_wrapper.new_BasicEngine(*args)
RuntimeError: Failed to allocate tensors.

I know this release is not official, but any idea what might be going on and how to resolve it? I’ve run the test scripts on a Pi 3 B+ using the same USB accelerator successfully, so I know I’ve got a working unit.

Did you try un-plugging / replugging the accelerator and/or rebooting ? I found that right after installation you have to replug the accelerator, otherwise this error occurs.

Just reinstalled with 1.9.2 on a clean pi zero w and the ccanned example (https://coral.withgoogle.com/docs/accelerator/get-started/)  worked great.
I'd suggest a clean reinstall I guess.

Yeah, I tried unplug/plug in, since the udev rules change on install.
I'll do clean install of Raspbian and 1.9.2, and also try it one another Pi Zero W.

@mtyka question: how did you connect the accelerator to the Pi Zero W? Directly with a USB-C to micro cable? Or via something like a powered USB hub? I'm wondering if my issue is power, not software.

Ugh, I think this was because I wasn’t using a USG OTG adapter. I’ll give that a try and confirm, but I’m pretty sure that’s it.

Good point about power. I'd recommend going through a powered hub, since Edge TPU can draw up to 2W during 100% utilization. So if pi0 cant supply enough voltage, your accelerator may brown out.

@mtyka (and anyone who comes across this one), I figured it out. I realized that on the Pi Zero in question, I had removed the default Raspbian pi user, and the user account I was using is only in the sudo group. When I tried the example code like this it worked:
$ sudo python3 classify_image.py \
--model ~/Downloads/mobilenet_v2_1.0_224_inat_bird_quant_edgetpu. \
--label ~/Downloads/inat_bird_labels.txt \
--image ~/Downloads/parrot.jpg

I checked the udev rules set up in the install script, and it applies to the plugdev group. So I needed to add my account to that group:
$ sudo usermod -aG plugdev [my username]

Problem solved.

Did you try un-plugging / replugging the accelerator and/or rebooting ?

This. I tried all the other solutions, but in my case the device started working only after rebooting the system.

hello I have unplugged and replugged. shut down and restarted and nothing works. can anyone suggest any other ideas on why the board is not being recognized. I keep seeing UniCorp Chip instead of Google <>.

I am having the same problem still. Is there any update on this? This is my error:
`
Image list successfully parsed! Category Num =  10
Traceback (most recent call last):
File "imprinting_learning.py", line 245, in
main()
File "imprinting_learning.py", line 199, in main
shape = _get_required_shape(args.model_path)
File "imprinting_learning.py", line 140, in _get_required_shape
tmp = BasicEngine(model_path)
File "/usr/lib/python3/dist-packages/edgetpu/basic/basic_engine.py", line 92, in init
self._engine = BasicEnginePythonWrapper.CreateFromFile(model_path)
RuntimeError: Internal: :77 tf_lite_type != kTfLiteUInt8 (1 != 3)Node number 0 (edgetpu-custom-op) failed to prepare.
Failed to allocate tensors.
`


Emoji picker freezes the app

Summary
When I open the emoji picker on my iPhone, the app freezes completely, and I am forced to do a hard reload in order to continue using the app. But it works perfect on Android.
Environment Information

Device Name: iPhone Xs (probably any iPhone)
OS Version: iOS 15.6 (probably any iOS)
Mattermost App Version: v2.1.0
Mattermost Server Version: v7.8

Steps to reproduce

Long press on a channel/private message
Tap emoji picker
Try to scroll and pick an emoji

Expected behavior
I can open and close the emoji picker, as well as scroll through all available emojis
Observed behavior (that appears unintentional)
Possible fixes
Totally no idea

Thanks for filing this, @Nick-Su!  I was coming here to file this exact issue.

Does this reproduce on the latest Mobile app version (v2.2.0)?

This version appears to solve the issue for me.

I confirm. v2.2.0 solves the issue. Yay!


Expand multi-server docs, especially networking?

I'd be happy to help contribute documentation on what I'm about to ask (I write quite a bit for a living), but need some guidance first on the most current/recommended way to communicate between two servers. Suppose you have Postgres on server A and an app on server B? What's the easiest/fastest/most bulletproof "Coolify way" to set this up?
Cloudflare tunnels are an option but the documentation seems to mostly focus on getting remote access e.g. to a server on a home or private LAN that you want to get to elsewhere. The docs don't really cover server-to-server comms.
Traefik as a proxy can do all kinds of wonderful things but at least IMO it's a more advanced concept for most. I'm not sure this is the best place for a newbie to start...
Obviously you have SaaS options like if you're in AWS cloud, you have the usual VPC mechanisms you would have with any other app. But they're vendor-specific and don't apply to all the cases where you can use Coolify.
Tailscale is an interesting option - it's really easy to set up, and addresses both server-to-server and admin-workstation-to-server needs. But it's not mentioned anywhere in the docs yet, so I'm not sure if it's really what the core maintainers want to recommend.
Ideally, what I'd like to achieve (and be happy to help document) is the simplest path to:

Set up Coolify on two servers.
Deploy app on A and postgres on B.
Add XYZ config, resource, or extra package and allow A to securely find and connect to B, a-la AWS Service Discovery, the way Docker Compose "services" work, or similar.

Any input would be appreciated. Thanks!

Just trying to keep this alive, it looks like the Docker Swarm option plus Cloudflare tunnels might be the best way to start for a lot of cases? It's not trivial to set up but...


Trace peer for chainsync clients

This makes it possible to track which peer presented us which header at what time. Useful for debugging/performance analysis.

Here are some pointers about how to deal with the stylish-haskell objection in the buildkite CI.
https://github.com/input-output-hk/ouroboros-network/#formatting

bors r+


Make changes to connect to Kafka with mutual TLS

Use this branch if you are working with an Apache Kafka (such as Aiven's) that uses mutualTLS for security.

Upstream changes mean this is no longer needed.


KO-384 Refactor out webhook and improve validation

This makes the webhook slightly more precise, in that we validate the namespace of the service that is used for the webhook is actually our namespace. I also added documentation on the webhook in the developer documentation folder. New additional validation happens here : https://github.com/datastax/cass-operator/blob/81a86a8f0571c32261ef4181f3039d2758ebcc6c/operator/cmd/manager/webhook.go#L34 and here: https://github.com/datastax/cass-operator/blob/81a86a8f0571c32261ef4181f3039d2758ebcc6c/operator/cmd/manager/webhook.go#L117

@eldondevat Is this PR just moving code to a different file? I'm totally on board with that I just want to make sure I didn't miss something.

Sorry @johntrimble I don't think this PR was really very precise before, and the single commit nature of it didn't make that easier, I've added some more detail. Thanks!


Feature:  Go Up should automatically detect and convert a text to a link.

Overview
Linked Data Vocabularies can populate the "up" field with data. This data is not in the form of [[a-link]]. In stead it is simple text "A-link". Therefore the Go Up function does not activate and user does not go up.

The current stop gap solution is to edit "broader: Authorship" into "broader: [[Authorship]]"

Describe the solution you'd like
As a user, I'd like to Go Up without having to revise the "up" field. It should remain text but still allow me to go up to a note with the same title.
Possible Solution
wrapping the text with getFirstLinkpathDest/getLInkPath should resolve this issue.

okay i got it!
If the 'parent' is the parent page, could we at least update the 'up' attribute to 'parent' to make it navigable?

You mistook me. With the recent update, you allowed the user to update the default "parent" field to use a user-chosen field. My goal is for a text only link such as Authorship to be take the user to the note "Authorship"

sorry for late answer!
if an Authorship note already exists, Do you want to move the "Author" text and [[Author]] (which is a link) to the parent note as well?


How to programmatically reveal SWRevealViewController menu without swipe or button press

Hi John,
I just need some quick advice.
I am using SWRevealViewController to produce a slide reveal menu and all is working wonderfully, as it should. I have it only affecting one View Controller within the app with a button and a swipe gesture recognizer to reveal the menu.
I am attempting to get the menu to automatically reveal when I move into the affected view controler but I am very unable to do it. I have tried to call the revealToggle: method directly, programmatically fire the button action and other variations with no success.
This is how it is implemented in viewdidload:
menu.target = self.revealViewController;
menu.action = @selector(revealToggle:);
[self.view addGestureRecognizer:self.revealViewController.panGestureRecognizer];
How do I reveal the menu automatically without the swipe or button press?
Thanks for the awesome work!

For swift 3 :-
self.revealViewController().revealToggle(self)

see, what I got to open and close SWRevealViewcontroller or reveal the menu
For right one using only button  -  self.revealViewController()?.rightRevealToggle(animated: true)


fix(#3393): Update to CronJob batch/v1

CronJob batch/v1beta1 is deprecated and will be removed soon. Updating to batch/v1 API
Fixes #3393
Fixes #2408
Release Note
Chore(deps): Update CronJob from batch/v1beta1 to batch/v1

@squakez maybe respin the failed openshift workflow job?

I doubt the batch/v1 group is available on OpenShift 3, which is used in the OpenShift workflow. One strategy would be to make the CronJob API optional, which would be useful beyond CI.

+1 for making it optional
beside that, should we really keep support for OpenShift 3

@astefanutti oh, I was not even looking at the failed workflow job error and thought it to be a flaky test run. many thanks!
let me see what it takes to make this optional. I think it is not only the trait that is using the CronJob API. I saw references to this all over the place.

beside that, should we really keep support for OpenShift 3

I think we are ready to remove OpenShift 3 support. The workflow is kept only because right now oc cluster up is the only way to test the OpenShift aspects of the features on GitHub. We'll not be able to have an alternative until MicroShift becomes usable.

oh, I was not even looking at the failed workflow job error and thought it to be a flaky test run. many thanks!

A short while ago we restored stability in our test suite. Now there shouldn't be so many flaky tests, so let's keep an eye on it and try not to introduce more failing tests.

let me see what it takes to make this optional. I think it is not only the trait that is using the CronJob API. I saw references to this all over the place.

We can also disable E2E tests for CronJob when they run on OpenShift 3, just like this:
https://github.com/apache/camel-k/blob/main/e2e/common/cli/install_test.go#L101-L107

Skipping the test won't solve the problem happening at runtime in Openshift 3. If we want to support OC3 then we need a different strategy (ie, creating a CronJobStrategy type and using the old dependencies when we detect OC3, or new dependencies otherwise). However it's too much hassle in my opinion. Any reason why we don't want to drop OC3 support and make it easier?

Any reason why we don't want to drop OC3 support and make it easier?

I'm fine with dropping OC3 support. It's just that if we remove the openshift workflow we lose a way to validate OpenShift related features such as S2I builds or Route easily in our daily CI.

I think the only reason to keep OpenShift 3.x support is for developers (and our GitHub actions CI) running on Minishift

I think the only reason to keep OpenShift 3.x support is for developers (and our GitHub actions CI) running on Minishift

We dropped Minishift support a while ago. What's running in the openshift workflow is the oc cluster up from OCP 3, which was another way to run a OCP cluster locally.

@christophd can we get this into 1.8.x and 1.9.x too?

@lburgazzoli @squakez @tadayosi we finally managed to make the CronJob functionality optional and only use it when the batch/v1 API is available. The e2e test is disabled when running on OpenShift 3.x
Are we good to merge?

fine with me

@christophd While this still passes CI there is an assertion failure here:
https://github.com/apache/camel-k/runs/7144173942?check_suite_focus=true#step:7:23
Can you have a look?

@tadayosi nice spot! Many thanks! Fixed with #3411


Docker-ci for armv7 / arm64 support

Closes #244

Added armv7 / arm64 support (k8s deprecated armv6)
Automated docker buildx & push to clastix quay.io registry using github actions
Added proprietary kubectl image from quay.io

Completely tested on amd64 / arm64

Regarding the quay.io/clastix.kubectl Image, may I ask you to share the Dockerfile and all the related files to the repository https://github.com/clastix/kubectl?

Just a single remark regarding the watched tags for the docker-ci workflow, but overall LGTM!

I've fixed it with last commit; docker-ci trigger works like a charm!

Regarding the quay.io/clastix.kubectl Image, may I ask you to share the Dockerfile and all the related files to the repository https://github.com/clastix/kubectl?

Sure; I'll also open an issue to automate clastix/kubectl release with gh actions (as done here).

Thanks for the big effort on this, really thrilled for landing this to Capsule!

Thank you @prometherion, I'm eager to see v0.1.0 tag!


Data types erroneous description

https://cairo-book.github.io/ch02-02-data-types.html#type-casting
"smaller" and "larger" reversed.
`

Closed by #95


Rename DS2.0 library to "Components"

Description
Rename DS2.0 library to "Components" or something thats clarifies it's a component library, not the entire system like it used to be in 1.0
Technical Details

Rename so its clear that its a component library
consider keeping naming convention consistent between colors, typography
Example:
Component / Core
Text Style / Small Screen
Text Style / Large Screen
Colors & Shadow / Light Theme
Colors & Shadow /  Dark Theme

Acceptance Criteria

Naming of libraries are consistent.
Component library is clear in its naming.

References

References go here.
Issue numbers. Links.
Slack threads.
Etc.


§3.4 (Sending Messages) in the book requires a different version of futures

Steps to reproduce

futures-preview = { version = "0.3.0-alpha.19", features = [ "async-await" ] } in Cargo.toml as recommended in §3.1.
Try to build the example in https://book.async.rs/tutorial/sending_messages.html

use futures::channel::mpsc; // 1
use futures::sink::SinkExt;
use std::sync::Arc;

type Sender<T> = mpsc::UnboundedSender<T>; // 2
type Receiver<T> = mpsc::UnboundedReceiver<T>;

async fn connection_writer_loop(
    mut messages: Receiver<String>,
    stream: Arc<TcpStream>, // 3
) -> Result<()> {
    let mut stream = &*stream;
    while let Some(msg) = messages.next().await {
        stream.write_all(msg.as_bytes()).await?;
    }
    Ok(())
}

What happens
error[E0599]: no method named `next` found for type `futures_channel::mpsc::UnboundedReceiver<std::string::String>` in the current scope
  --> core/src/main.rs:89:36
   |
89 |     while let Some(msg) = messages.next().await {
   |                                    ^^^^ method not found in `futures_channel::mpsc::UnboundedReceiver<std::string::String>`
   |
   = note: the method `next` exists but the following trait bounds were not satisfied:
           `futures_channel::mpsc::UnboundedReceiver<std::string::String> : async_std::stream::stream::StreamExt`
   = help: items from traits can only be used if the trait is in scope
help: the following trait is implemented but not in scope; perhaps add a `use` for it:
   |
7  | use futures_util::stream::StreamExt;
   |

It seems to work with futures = "0.3.0", and it's indeed what is being used in the a-chat example in the repo as of 122e87364bef463c5afbf7681ec3ce35a3a7f577.

@Ppjet6 Thanks for filing this! We should indeed fix this. I've marked this as "good first issue" as it should be relatively easy to update.

I like to take it if nobody is working on it now

As far as I can tell, this issue can be closed now, because this was fixed by https://github.com/async-rs/async-std/commit/4aa9928ece3d968ea229842cbdaf53dd81fc11c2#diff-a66f64c4985b3614f93e8bba0d7b7cd879f8db631a2ee2f4afd55973ad21de9a.


Error building package using Docker (official node image)

I am trying to build using docker with the official node (v6.12.0).
All dependencies are installed, when I launch the command npm run package and after a fair amount of time I get the following error, which seems a sort of infinite loop that is building the path.
npm ERR! Failed at the<EMAIL_ADDRESS>build-main script 'cross-env NODE_ENV=production node -r babel-register ./node_modules/webpack/bin/webpack --config webpack/webpack.confurces/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daed[650/1081]
-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daeda
lus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-
x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packag
er/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electr
on-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/a
pp/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/re
sources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-lin
ux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Dae
dalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linu
x-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-pack
ager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/elec
tron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources
/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/
resources/app/node_modules/babel-plugin-react-transform/test/fixtures/code-react-create-class-with-string-literal-display-name-with-render-method/actual.js'
    at Error (native)
  errno: -36,
  code: 'ENAMETOOLONG',
  syscall: 'unlink',
  path: '/ada/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-l
inux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/D
aedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/li
nux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-pa
ckager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/el
ectron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resourc
es/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x6
4/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus
-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64
/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/
linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-
packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/
electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resou
rces/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-
x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedal
us-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x
64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-package
r/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electro
n-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/ap
p/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/res
ources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linu
x-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daed
alus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/electron-packager/linux-x64/Daedalus-linux-x64/resources/app/node_modules/babel-plug
in-react-transform/test/fixtures/code-react-create-class-with-string-literal-display-name-with-render-method/actual.js' }

@sp4ke please use yarn and nix to build Daedalus locally as described in Daedalus README: https://github.com/input-output-hk/daedalus/blob/develop/README.md#yarn


Feature request: Control order of 'feature_column.input_layer'

On master (80e7c9f45c).
It seems that the mapping of features to columns in dense the input matrix is always sorted by the alphabetical order of the feature names. It would be nice is this was customizable, perhaps by respecting the order of the feature columns in the second argument to input_layer. Mainly useful  for debugging and introspecting the network to know which columns correspond to which features.
eg:
sess.run(tf.feature_column.input_layer({'a': [1], 'b': [2]}, [tf.feature_column.numeric_column('a'), tf.feature_column.numeric_column('b')]))

gives [1, 2],
as does switching the order of the feature columns:
sess.run(tf.feature_column.input_layer({'a': [1], 'b': [2]}, [tf.feature_column.numeric_column('b'), tf.feature_column.numeric_column('a')]))

I also tried giving the features as an OrderedDict, but input_layer doesn't seem to care about the ordering in that  situation either.

Yes, feature_columns's order is rearranged:
https://github.com/tensorflow/tensorflow/blob/b5df90f91cde6eb12af9cbe818bd2cf4a9bcc687/tensorflow/python/feature_column/feature_column.py#L224
However, I think your request is reasonable.

We sort feature columns to make order of variables/ops deterministic. Each worker should create them in same order. we cannot know the given fc order is deterministic or not.

Because feature_columns accepts an iterator, which can be either ordered (say,  list ) or unordered (say, set or map), so we always sorted the feature columns by name, right?

yes.

I still think it would be nice to have some kind of interface for exposing the relationship between columns and features to users, even if it's not user-specifiable.

I think it's doable without changing order. Currently we're returning vars related to FCs via cols_to_vars. We can similarly add an argument such as cols_to_slices.

I'm afraid that cols_to_slices is a little complicated. At least for tuple, it seems safe to respect its iterator's order.

A design that doesn't return to the original order is so un-human. Do designers not use their products very much？


Spike on byte keys for maps do we need to change up how we do momento.Bytes()

Currently our dictionaries can only support map[string]momento.Value we should spike to see what we can do if there is way to make more flexible so can support byte keys in the map in clean way for users.
Do we need to make any changes to momento.Bytes() prior to 1.0 release?

Addressed in ba3fe975 with the inclusion of an Element type that contains ElemField and ElemValue, both with the Value type. Also included are convenience methods to convert from maps with string, []byte, or Value values to []Element.


add CacheNamespace useCacheGlobally

Hi, as described in this issure https://github.com/mybatis/mybatis-3/issues/2633
The current problem is:
CacheNamespace defaults to using Cache for all methods under the current Mapper, which only makes sense when Options.useCache=false.
If you want to specify a specific method to use Cache, you must use subtraction to exclude all methods that do not use cache with Options.useCache=false, which is more complicated for developers in some aspects.
My train of thought:

Add the useCacheGlobally option to CacheNamespace, the default is true, which satisfies the current implementation idea
Developers can choose useCacheGlobally = false in Mapper. At this time, whether the method uses cache is completely handled by Options.useCache

Hello @xuwenping123 ,
As I explained in #2633 , there should be no problem with adding @Option(useCache = false) on particular methods unless you put many unrelated methods in one mapper.
I appreciate you taking the time to submit a PR, but I don't think this benefits a lot of users.

@harawata


Creating youtubes after the fact

I have a project where I'm creating youtubes after the page loads and for some reason I'm encountering a bug where the youtube video refuses to load again after it's already been loaded once on the page.
I can't replicate it via JSFiddle, but I did find a fix for myself.  When I change https://github.com/Selz/plyr/blob/master/src/js/plyr.js#L1608 to plyr.embed = new window.YT.Player(container, { then the problem goes away.  Other examples that I see online uses the container and not the container.id.
I guess I'm wondering if the code on that line is correct or should you be referencing the full container object?

I'll take a look - thanks for letting me know

Howdy! Just coming by to confirm that I'm hitting the same issue too whenever I dynamically create & destroy youtube videos. Trying to integrate Plyr with a custom modal I'm building for a site.
The video is dynamically created when a modal is opened and then destroyed when it is closed.
I've put together a reduced test of the issue. This is roughly how I'm going about creating & destroying. I've tested with Vimeo videos and this isn't an issue.
http://codepen.io/joshuapease/pen/qaYdLR
Notice the console error after you've toggled the video twice. Seems to be coming from youtube's JS.

PS. This is "by far" the best JS video player I've used, so great.

Thanks Josh. I'll try and fix this issue as soon as I get some time (possibly today/tomorrow).

Hey @SamPotts & @MHenley! I think I may have figured out what my issue was.
I was calling plyr.setup() before I'd actually appended the DOM element to the body. So while the element did exist, it wasn't part of the actual document tree.
Must be that Youtube and/or Plyr don't like that. I did notice that Plyr controls weren't showing up on the old demo.
Here's a new codepen that seems to show everything working. Simply involved swapping the order of a single line of code.
http://codepen.io/joshuapease/pen/LRALqQ

Hey @joshuapease,
Thanks for reporting back. So is there still a bug that needs fixing or are we good?

Yeah! Seems to be working well for me.
Although I'm curious if the route I took is a good way to dynamically
create Plyr instances. Is there a better way to do that programmatically?
On Sat, Oct 22, 2016 at 6:35 PM, Sam Potts<EMAIL_ADDRESS>wrote:

Hey @joshuapease https://github.com/joshuapease,
Thanks for reporting back. So is there still a bug that needs fixing or
are we good?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Selz/plyr/issues/377#issuecomment-255564233, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACC-zoIiOQCacMy8K9MA9fhTY8ORzB17ks5q2rnGgaJpZM4KG4JL
.


#2295 - Disposing the read stream after computing file hash.

/cc: @NTaylorMullen

:shipit:

:shipit: please check into release then port to dev.

@sornaks, this is checked in, isn't it?

Yes. I forgot to close sorry. https://github.com/aspnet/Mvc/commit/6e9533ce9cf48536c27a09bf61fd48b113c2107b


SingleFile was not able to archive the page

I'm trying to use archivebox in Synology Docker. I want to archive singlefile, but an error occurs.
At first, I downloaded the image file from the container manager and ran it, but the singlefile was not downloaded, so I tried increasing TIMEOUT to 600, and I also tried creating a new project and using sonic. but the result was the same
error code: SingleFile was not able to archive the page
docker-compose.yaml
version: '3.9'

services:
  archivebox:
    image: archivebox/archivebox:latest
    container_name: ArchiveBox
    hostname: archivebox
    healthcheck:
      test: curl -f http://localhost:8000/ || exit 1
    command: server --quick-init <IP_ADDRESS>:8000
    ports:
      - 8000:8000
    environment:
      - MEDIA_MAX_SIZE=2000m
      - SEARCH_BACKEND_ENGINE=sonic
      - SEARCH_BACKEND_HOST_NAME=sonic
      - SEARCH_BACKEND_PASSWORD=SecretPassword
      - TIMEOUT=600
      - PUBLIC_INDEX=False # set to False to prevent anonymous users from viewing snapshot list. Or set to True.
      - PUBLIC_SNAPSHOTS=False # set to False to prevent anonymous users from viewing snapshot content. Or set to True.
      - PUBLIC_ADD_VIEW=False # set to True to allow anonymous users to submit new URLs to archive.

    volumes:
        - /volume1/docker/archivebox/data:/data

index.json
{
  "archive_path": "archive/1729241500.668938",
  "base_url": "tsblog.simulz.kr/1298",
  "basename": "1298",
  "bookmarked_date": "2024-10-18 08:51",
  "canonical": {
    "archive_org_path": "https://web.archive.org/web/tsblog.simulz.kr/1298",
    "dom_path": "output.html",
    "favicon_path": "favicon.ico",
    "git_path": "git/",
    "google_favicon_path": "https://www.google.com/s2/favicons?domain=tsblog.simulz.kr",
    "headers_path": "headers.json",
    "htmltotext_path": "htmltotext.txt",
    "index_path": "index.html",
    "media_path": "media/",
    "mercury_path": "mercury/content.html",
    "pdf_path": "output.pdf",
    "readability_path": "readability/content.html",
    "screenshot_path": "screenshot.png",
    "singlefile_path": "singlefile.html",
    "warc_path": "warc/",
    "wget_path": "tsblog.simulz.kr/1298.html"
  },
  "domain": "tsblog.simulz.kr",
  "extension": "",
  "hash": "W4ECDPNXXVC8FAPPD2MD",
  "history": {
  "archive_org": [
    {
    "cmd": [
    "curl",
    "--silent",
    "--location",
    "--compressed",
    "--head",
    "--max-time",
    "600",
    "--user-agent",
    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36 ArchiveBox/0.7.2 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.5.0 (x86_64-pc-linux-gnu)",
    "https://web.archive.org/save/https://tsblog.simulz.kr/1298"
    ],
    "cmd_version": "curl 8.5.0 (x86_64-pc-linux-gnu)",
    "end_ts": "2024-10-18T08:56:58.346553+00:00",
    "index_texts": null,
    "output": "ArchiveError: Failed to find "content-location" URL header in Archive.org response.",
    "pwd": "/data/archive/1729241500.668938",
    "schema": "ArchiveResult",
    "start_ts": "2024-10-18T08:56:57.816756+00:00",
    "status": "failed"
    }
    ],
    "dom": [
    {
    "cmd": [
    "/usr/bin/chromium-browser",
    "--headless=new",
    "--no-sandbox",
    "--no-zygote",
    "--disable-dev-shm-usage",
    "--disable-software-rasterizer",
    "--run-all-compositor-stages-before-draw",
    "--hide-scrollbars",
    "--window-size=1440,2000",
    "--autoplay-policy=no-user-gesture-required",
    "--no-first-run",
    "--use-fake-ui-for-media-stream",
    "--use-fake-device-for-media-stream",
    "--disable-sync",
    "--user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36 ArchiveBox/0.7.2 (+https://github.com/ArchiveBox/ArchiveBox/)",
    "--window-size=1440,2000",
    "--dump-dom",
    "https://tsblog.simulz.kr/1298"
    ],
    "cmd_version": "Chromium 124.0.6367.29",
    "end_ts": "2024-10-18T08:56:27.959212+00:00",
    "index_texts": null,
    "output": "output.html",
    "pwd": "/data/archive/1729241500.668938",
    "schema": "ArchiveResult",
    "start_ts": "2024-10-18T08:56:17.488790+00:00",
    "status": "succeeded"
    }
    ],
    "favicon": [
    {
    "cmd": [
    "curl",
    "--silent",
    "--location",
    "--compressed",
    "--max-time",
    "600",
    "--output",
    "favicon.ico",
    "--user-agent",
    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36 ArchiveBox/0.7.2 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.5.0 (x86_64-pc-linux-gnu)",
    "https://www.google.com/s2/favicons?domain=tsblog.simulz.kr"
    ],
    "cmd_version": "curl 8.5.0 (x86_64-pc-linux-gnu)",
    "end_ts": "2024-10-18T08:51:41.455490+00:00",
    "index_texts": null,
    "output": "favicon.ico",
    "pwd": "/data/archive/1729241500.668938",
    "schema": "ArchiveResult",
    "start_ts": "2024-10-18T08:51:40.966539+00:00",
    "status": "succeeded"
    }
    ],
    "git": [],
    "headers": [
    {
    "cmd": [
    "curl",
    "--silent",
    "--location",
    "--compressed",
    "--head",
    "--max-time",
    "600",
    "--user-agent",
    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36 ArchiveBox/0.7.2 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.5.0 (x86_64-pc-linux-gnu)",
    "https://tsblog.simulz.kr/1298"
    ],
    "cmd_version": "curl 8.5.0 (x86_64-pc-linux-gnu)",
    "end_ts": "2024-10-18T08:51:41.815784+00:00",
    "index_texts": null,
    "output": "headers.json",
    "pwd": "/data/archive/1729241500.668938",
    "schema": "ArchiveResult",
    "start_ts": "2024-10-18T08:51:41.542515+00:00",
    "status": "succeeded"
    }
    ],
    "htmltotext": [],
    "media": [
    {
    "cmd": [
    "yt-dlp",
    "--write-description",
    "--write-info-json",
    "--write-annotations",
    "--write-thumbnail",
    "--no-call-home",
    "--write-sub",
    "--write-auto-subs",
    "--convert-subs=srt",
    "--yes-playlist",
    "--continue",
    "--no-abort-on-error",
    "--ignore-errors",
    "--geo-bypass",
    "--add-metadata",
    "--format=(bv*+ba/b)[filesize<=2000m][filesize_approx<=?2000m]/(bv*+ba/b)",
    "https://tsblog.simulz.kr/1298"
    ],
    "cmd_version": "2023.12.30",
    "end_ts": "2024-10-18T08:56:57.593718+00:00",
    "index_texts": [],
    "output": "media",
    "pwd": "/data/archive/1729241500.668938",
    "schema": "ArchiveResult",
    "start_ts": "2024-10-18T08:56:52.987575+00:00",
    "status": "succeeded"
    }
    ],
    "mercury": [
    {
    "cmd": [
<EMAIL_ADDRESS>    "https://tsblog.simulz.kr/1298"
    ],
    "cmd_version": "1.0.0",
    "end_ts": "2024-10-18T08:56:52.794829+00:00",
    "index_texts": null,
    "output": "mercury",
    "pwd": "/data/archive/1729241500.668938",
    "schema": "ArchiveResult",
    "start_ts": "2024-10-18T08:56:46.019037+00:00",
    "status": "succeeded"
    }
    ],
    "pdf": [
    {
    "cmd": [
    "/usr/bin/chromium-browser",
    "--headless=new",
    "--no-sandbox",
    "--no-zygote",
    "--disable-dev-shm-usage",
    "--disable-software-rasterizer",
    "--run-all-compositor-stages-before-draw",
    "--hide-scrollbars",
    "--window-size=1440,2000",
    "--autoplay-policy=no-user-gesture-required",
    "--no-first-run",
    "--use-fake-ui-for-media-stream",
    "--use-fake-device-for-media-stream",
    "--disable-sync",
    "--user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36 ArchiveBox/0.7.2 (+https://github.com/ArchiveBox/ArchiveBox/)",
    "--window-size=1440,2000",
    "--print-to-pdf",
    "https://tsblog.simulz.kr/1298"
    ],
    "cmd_version": "Chromium 124.0.6367.29",
    "end_ts": "2024-10-18T08:56:04.990673+00:00",
    "index_texts": null,
    "output": "output.pdf",
    "pwd": "/data/archive/1729241500.668938",
    "schema": "ArchiveResult",
    "start_ts": "2024-10-18T08:55:44.647568+00:00",
    "status": "succeeded"
    }
    ],
    "readability": [
    {
    "cmd": [
    "/app/node_modules/readability-extractor/readability-extractor",
    "/tmp/tmpgojmv8uu",
    "https://tsblog.simulz.kr/1298"
    ],
    "cmd_version": "0.0.11",
    "end_ts": "2024-10-18T08:56:45.745596+00:00",
    "index_texts": [
    "\ud050\ube57 \ud1a0\ub80c\ud2b8 \ub3c4\ucee4 \uc124\uce58\n\uc774\ubbf8\uc9c0 \uc124\uce58\n\n\n\ucee8\ud14c\uc774\ub108 \ub9e4\ub2c8\uc800\uc758 \ub808\uc9c0\uc2a4\ud2b8\ub9ac \ud654\uba74\uc73c\ub85c \uc774\ub3d9 \ud6c4, \u00a0qbittorrent\ub97c \uac80\uc0c9\ud569\ub2c8\ub2e4.\n\n\nlinuxserver/qbittorrent \ud56d\ubaa9\uc744 \ub354\ube14\ud074\ub9ad \ud558\uac70\ub098 \ub2e4\uc6b4\ub85c\ub4dc \ubc84\ud2bc\uc744 \ub20c\ub7ec \ucd5c\uc2e0 \ubc84\uc804(latest)\uc744 \ub0b4\ub824 \ubc1b\uc2b5\ub2c8\ub2e4. \ubc84\uc804\uc774 \ub9ce\uae30 \ub54c\ubb38\uc5d0 \ucf64\ubcf4 \ub9ac\uc2a4\ud2b8 \ubc18\uc751\uc774 \ub290\ub9bd\ub2c8\ub2e4.\n\n\n\ucee8\ud14c\uc774\ub108 \ub9e4\ub2c8\uc800\uc758 \uc774\ubbf8\uc9c0 \ud654\uba74\uc5d0\uc11c \ub0b4\ub824\ubc1b\uc740 \uc774\ubbf8\uc9c0\ub97c \uc2e4\ud589\ud574\uc11c \uc124\uce58\ub97c \uc2dc\uc791\ud569\ub2c8\ub2e4.\n\n\ucee8\ud14c\uc774\ub108 \uc124\uc815\n\n\n\uc7ac\ubd80\ud305\ud560 \ub54c\ub9c8\ub2e4 \uc0ac\uc6a9\ud558\ub824\uba74 \uc790\ub3d9 \uc7ac\uc2dc\uc791 \ud65c\uc131\ud654 \uc120\ud0dd\n\n\uace0\uae09 \uc124\uc815\n\ud3ec\ud2b8 \uc124\uc815, \ubcfc\ub968 \uc124\uc815\n\n\n\uae30\ubcf8 WEB_UI \ud3ec\ud2b8\ub294 8080\uc774\uba70, \uc5ec\uae30\uc11c\ub294 8282\ub85c \ubcc0\uacbd\ud574\ubd05\ub2c8\ub2e4. NAS\uc758 \ub85c\uceec \ud3ec\ud130\uac00 \ucee8\ud14c\uc774\ub108\uc5d0\uc11c \uc124\uc815\ud55c \ud3ec\ud2b8\uc5d0 \ub9e4\ud551\ub429\ub2c8\ub2e4.\n\ubcfc\ub968 \uc124\uc815\uc5d0 \ub85c\uceec \ud3f4\ub354\ub97c \ucd94\uac00\ud558\uc5ec \ub9c8\uc6b4\ud2b8 \ud569\ub2c8\ub2e4.\n/config/downloads\n\ud658\uacbd\n\n\nWEBUI_PORT \ubcc0\uc218\ub97c \ucd94\uac00\ud558\uace0 \ubcc0\uacbd\ud560 \ucee8\ud14c\uc774\ub108 \ud3ec\ud2b8 \ubc88\ud638\ub97c \uc785\ub825\ud569\ub2c8\ub2e4.\n\uc124\uc815\uc744 \uc644\ub8cc \ud6c4 \ucee8\ud14c\uc774\ub108\ub97c \uc2e4\ud589\ud569\ub2c8\ub2e4.\n\n\ub124\ud2b8\uc6cc\ud06c \uc124\uc815\n\ubc29\ud654\ubcbd \ud3ec\ud2b8 \ucd94\uac00\n\n\n\uc81c\uc5b4\ud310 - \ubcf4\uc548 - \ubc29\ud654\ubcbd - \uaddc\uce59 \ud3b8\uc9d1 - \uc0dd\uc131 \ub610\ub294 \ud3b8\uc9d1 - \uc18c\uc2a4 IP \ud2b9\uc815 IP \uc120\ud0dd - IP \uc785\ub825\n\ucee8\ud14c\uc774\ub108 IP \ub300\uc5ed\uc744 \ubc29\ud654\ubcbd\uc5d0 \ucd94\uac00\ud569\ub2c8\ub2e4. \uc11c\ube0c\ub137 \ub9c8\uc2a4\ud06c\ub294 \uc6d0\ud558\ub294 \ub9cc\ud07c \uc124\uc815\ud569\ub2c8\ub2e4.\n\n\ub9ac\ubc84\uc2a4 \ud504\ub85d\uc2dc\n\ub3c4\uba54\uc778 \uc8fc\uc18c\ub85c \uc811\uc18d\ud558\uace0 \uc2f6\ub2e4\uba74 \uc5ed\ubc29\ud5a5 \ud504\ub85d\uc2dc\ub97c \ucd94\uac00\ud569\ub2c8\ub2e4.\n\n\n\uc81c\uc5b4\ud310 - \ub85c\uadf8\uc778 \ud3ec\ud138 - \uace0\uae09 - \uc5ed\ubc29\ud5a5 \u00a0\ud504\ub85d\uc2dc - \uc0dd\uc131 \ub610\ub294 \ud3b8\uc9d1 - \uc815\ubcf4 \uc785\ub825\n\ud504\ub85c\ud1a0\ucf5c\uc740 HTTPS, \ud638\uc2a4\ud2b8 \uc774\ub984\uc5d0 \uc784\uc758\uc758 \uc11c\ube0c \ub3c4\uba54\uc778\uc744 \ud3ec\ud568\ud55c \uc8fc\uc18c\ub97c \uc785\ub825, \ud3ec\ud2b8\ub294 443\uc744 \uc785\ub825\ud569\ub2c8\ub2e4.\n\uc608) torrent.yourDNS.me\n\ub77c\uc6b0\ud130\uc5d0\uc11c\ub294 443 \ud3ec\ud2b8\ub97c NAS IP\ub85c \ud3ec\ud2b8 \ud3ec\uc6cc\ub529 \uc124\uc815\ud569\ub2c8\ub2e4.\n\uc678\ubd80\uc5d0\uc11c\ub294 HTTPS\ub85c\ub9cc \uc811\uc18d\ud558\uace0, \ub0b4\ubd80\ub9dd\uc740 IP \uc811\uc18d\uc774\ubbc0\ub85c \ub300\uc0c1 \ud504\ub85c\ud1a0\ucf5c\uc740 HTTP\ub85c \uc124\uc815\ud569\ub2c8\ub2e4.\ud3ec\ud2b8 \ubc88\ud638\ub294 \ucee8\ud14c\uc774\ub108\ub85c \uc5f0\uacb0\ub418\ub294 \ub85c\uceec \ud3ec\ud2b8\ub97c \uc785\ub825\ud569\ub2c8\ub2e4.\n\uc811\uc18d \uacfc\uc815\u27a1\ufe0f(\ube0c\ub77c\uc6b0\uc800)https://torrent.yourDNS.me\u27a1\ufe0f(NAS) \ub9ac\ubc84\uc2a4 \ud504\ub85d\uc2dc\u27a1\ufe0f(NAS)http://192.x.x.x:8282\u27a1\ufe0f(\ucee8\ud14c\uc774\ub108)http://172.x.x.x:8282\n\n\uc811\uc18d\n\uc704\uc5d0\uc11c \uc124\uc815\ud55c \uc5ed\ubc29\ud5a5 \ud504\ub85d\uc2dc\uc5d0 \uc785\ub825\ud55c \ud638\uc2a4\ud2b8 \uc774\ub984\uc73c\ub85c \uc811\uc18d\ud569\ub2c8\ub2e4.\n\uc608) https://torrent.yourDNS.me\u00a0\n\n\nqBitTorrent \ub85c\uadf8\uc778 \ud398\uc774\uc9c0\uac00 \ub098\ud0c0\ub0a9\ub2c8\ub2e4.\nUsername\uc740 admin\uc774\uba70, Password\ub294 \ucee8\ud14c\uc774\ub108 \ub85c\uadf8\uc5d0\uc11c \ud655\uc778\ud560 \uc218 \uc788\uc2b5\ub2c8\ub2e4.\n\uc554\ud638 \ud655\uc778\n\n\n\ucee8\ud14c\uc774\ub108 \uc18d\uc131\uc5d0\uc11c \ub85c\uadf8 \ud0ed\uc73c\ub85c \uc774\ub3d9\ud558\uba74 username\uacfc password\ub97c \ud655\uc778\ud560 \uc218 \uc788\uc2b5\ub2c8\ub2e4.\n\ub85c\uadf8\uc778 \ud6c4 \uc554\ud638\ub97c \ubcc0\uacbd\ud569\ub2c8\ub2e4.\n\n\n\uc124\uc815\n\u2699\ufe0f \uc544\uc774\ucf58\uc744 \ub204\ub974\uace0 \uc6f9 UI \ud0ed\uc73c\ub85c \uc774\ub3d9\ud569\ub2c8\ub2e4.\n\n\n\ub85c\uadf8\uc778 \ubcf4\uc548\n\uc0ac\uc6a9\uc790 \uc774\ub984\uacfc \uc554\ud638\ub97c \uc785\ub825 \ud6c4 \uc800\uc7a5\u00a0\ubc84\ud2bc\uc744 \ub204\ub974\uba74 \ub429\ub2c8\ub2e4.\n\n\uac31\uc2e0: 2024-04-17"
    ],
    "output": "readability",
    "pwd": "/data/archive/1729241500.668938",
    "schema": "ArchiveResult",
    "start_ts": "2024-10-18T08:56:41.590888+00:00",
    "status": "succeeded"
    }
    ],
    "screenshot": [
    {
    "cmd": [
    "/usr/bin/chromium-browser",
    "--headless=new",
    "--no-sandbox",
    "--no-zygote",
    "--disable-dev-shm-usage",
    "--disable-software-rasterizer",
    "--run-all-compositor-stages-before-draw",
    "--hide-scrollbars",
    "--window-size=1440,2000",
    "--autoplay-policy=no-user-gesture-required",
    "--no-first-run",
    "--use-fake-ui-for-media-stream",
    "--use-fake-device-for-media-stream",
    "--disable-sync",
    "--user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36 ArchiveBox/0.7.2 (+https://github.com/ArchiveBox/ArchiveBox/)",
    "--window-size=1440,2000",
    "--screenshot",
    "https://tsblog.simulz.kr/1298"
    ],
    "cmd_version": "Chromium 124.0.6367.29",
    "end_ts": "2024-10-18T08:56:17.346051+00:00",
    "index_texts": null,
    "output": "screenshot.png",
    "pwd": "/data/archive/1729241500.668938",
    "schema": "ArchiveResult",
    "start_ts": "2024-10-18T08:56:05.380987+00:00",
    "status": "succeeded"
    }
    ],
    "singlefile": [
    {
    "cmd": [
    "/app/node_modules/single-file-cli/single-file",
    "--browser-executable-path=chromium-browser",
    "--browser-args=[\"--headless=new\", \"--no-sandbox\", \"--no-zygote\", \"--disable-dev-shm-usage\", \"--disable-software-rasterizer\", \"--run-all-compositor-stages-before-draw\", \"--hide-scrollbars\", \"--window-size=1440,2000\", \"--autoplay-policy=no-user-gesture-required\", \"--no-first-run\", \"--use-fake-ui-for-media-stream\", \"--use-fake-device-for-media-stream\", \"--disable-sync\", \"--user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36 ArchiveBox/0.7.2 (+https://github.com/ArchiveBox/ArchiveBox/)\", \"--window-size=1440,2000\"]",
    "https://tsblog.simulz.kr/1298",
    "singlefile.html"
    ],
    "cmd_version": "1.1.46",
    "end_ts": "2024-10-18T08:55:44.423754+00:00",
    "index_texts": null,
    "output": "ArchiveError: SingleFile was not able to archive the page",
    "pwd": "/data/archive/1729241500.668938",
    "schema": "ArchiveResult",
    "start_ts": "2024-10-18T08:51:41.888695+00:00",
    "status": "failed"
    }
    ],
    "title": [
    {
    "cmd": [
    "curl",
    "--silent",
    "--location",
    "--compressed",
    "--max-time",
    "600",
    "--user-agent",
    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36 ArchiveBox/0.7.2 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.5.0 (x86_64-pc-linux-gnu)",
    "https://tsblog.simulz.kr/1298"
    ],
    "cmd_version": "curl 8.5.0 (x86_64-pc-linux-gnu)",
    "end_ts": "2024-10-18T08:56:41.517539+00:00",
    "index_texts": null,
    "output": "\uc2dc\ub180\ub85c\uc9c0 \ucee8\ud14c\uc774\ub108 - qBitTorrent v4.6 \uc124\uce58",
    "pwd": "/data/archive/1729241500.668938",
    "schema": "ArchiveResult",
    "start_ts": "2024-10-18T08:56:41.446938+00:00",
    "status": "succeeded"
    }
    ],
    "wget": [
    {
    "cmd": [
    "wget",
    "--no-verbose",
    "--adjust-extension",
    "--convert-links",
    "--force-directories",
    "--backup-converted",
    "--span-hosts",
    "--no-parent",
    "-e",
    "robots=off",
    "--timeout=600",
    "--restrict-file-names=windows",
    "--warc-file=/data/archive/1729241500.668938/warc/1729241788",
    "--page-requisites",
    "--user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36 ArchiveBox/0.7.2 (+https://github.com/ArchiveBox/ArchiveBox/) wget/GNU Wget 1.21.3",
    "--compression=auto",
    "https://tsblog.simulz.kr/1298"
    ],
    "cmd_version": "GNU Wget 1.21.3",
    "end_ts": "2024-10-18T08:56:41.310965+00:00",
    "index_texts": null,
    "output": "tsblog.simulz.kr/1298.html",
    "pwd": "/data/archive/1729241500.668938",
    "schema": "ArchiveResult",
    "start_ts": "2024-10-18T08:56:28.076037+00:00",
    "status": "succeeded"
    }
    ]
    },
    "icons": null,
    "is_archived": true,
    "is_static": false,
    "latest": {
    "archive_org": "ArchiveError: Failed to find "content-location" URL header in Archive.org response.",
    "dom": "output.html",
    "favicon": "favicon.ico",
    "git": null,
    "media": "media",
    "pdf": "output.pdf",
    "screenshot": "screenshot.png",
    "singlefile": "ArchiveError: SingleFile was not able to archive the page",
    "title": "\uc2dc\ub180\ub85c\uc9c0 \ucee8\ud14c\uc774\ub108 - qBitTorrent v4.6 \uc124\uce58",
    "warc": null,
    "wget": "tsblog.simulz.kr/1298.html"
    },
    "link_dir": "/data/archive/1729241500.668938",
    "newest_archive_date": "2024-10-18T08:56:57.816756+00:00",
    "num_failures": 2,
    "num_outputs": 10,
    "oldest_archive_date": "2024-10-18T08:51:40.966539+00:00",
    "path": "/1298",
    "schema": "Link",
    "scheme": "https",
    "snapshot_id": "bc9f3613-1b98-42c1-9ae7-8153bad242fc",
    "sources": [
      "/data/sources/1729241500-import.txt"
    ],
    "tags": null,
    "tags_str": "",
    "timestamp": "1729241500.668938",
    "title": "\uc2dc\ub180\ub85c\uc9c0 \ucee8\ud14c\uc774\ub108 - qBitTorrent v4.6 \uc124\uce58",
    "updated": "2024-10-18T08:51:40.966295+00:00",
    "updated_date": "2024-10-18 08:51",
    "url": "https://tsblog.simulz.kr/1298"
}

The older singlefile release in the v0.7.x :latest (aka :stable) build can fail for a number of reasons. In general each method is not expected to work on 100% of sites, that's why many methods are provided.
It's possible upgrading will fix the issue as the latest pre-release contains many fixes and improvements, including Singlefile updates.
If you're ok trying a BETA, back up your collection first and then edit docker-compose.yml image: to the latest archivebox/archivebox:dev tag. Otherwise wait till the next stable v0.9 release.

v0.7.x :latest(일명 ) 빌드 의 이전 단일 파일 릴리스는 :stable여러 가지 이유로 실패할 수 있습니다. 일반적으로 각 방법은 100%의 사이트에서 작동하지 않을 것으로 예상되므로 많은 방법이 제공됩니다.
최신 사전 릴리스에는 Singlefile 업데이트를 포함하여 많은 수정 사항과 개선 사항이 포함되어 있으므로 업그레이드하면 문제가 해결될 가능성이 있습니다.
베타를 시도해도 괜찮다면 먼저 컬렉션을 백업한 다음 docker-compose.yml image:최신 archivebox/archivebox:dev태그로 편집하세요. 그렇지 않으면 다음 안정적인 v0.9 릴리스까지 기다리세요.

I don't know why, but I couldn't run archivebox:dev. Instead, I ran archivebox:master, and a singlefile was archived.


Ocpp: handle nil timestamp

Fix https://github.com/evcc-io/evcc/issues/3929
Note: this will still panic if a nil ts is accepted and the next message contains a timestamp. Might be better to reject nil but that will break user's CP.
Why is the timestamp comparison required at all?

Note: this will still panic if a nil ts is accepted and the next message contains a timestamp. Might be better to reject nil but that will break user's CP.

Fixed


Update verify.py

When using a schema setup as proposed in the documentation like: ReadUser, CreateUser, UpdateUser and BaseUser in the combination with MongoDB / Beanie, the verify() method will not "enforce" the user_schema but instead will return the BaseUser which will cause serialisation errors as such:
pydantic.error_wrappers.ValidationError: 1 validation error for ReadUser
response -> id

because the mapping between MongoDBs internal _id and the Pydantic id does not work.

Nice catch, indeed 🙏  If you don't mind, I would prefer this approach to keep consistency with other routers:
user = await user_manager.verify(token, request)
return user_schema.from_orm(user)

I have updated my proposal

Perfect, thanks 👍
@all-contributors add @jankadel for bug


Two Vertex AI components

With regard to https://github.com/tensorflow/tfx/issues/4125, I think it'd be a good idea to have two components for Vertex AI:

One that would import a model into Vertex AI from the location provided by Pusher.
One that would deploy a given model from Vertex AI to an Endpoint.

With these two components, the users will actually be able to author end-to-end TFX pipelines that could be orchestrated on Vertex Pipelines that take the advantage of Vertex AI's services.
@deep-diver and I have worked on a PoC (Colab Notebook) that might be helpful for this purpose. We realized the following pipeline:

Cc: @rcrowe-google

Thanks for the Firebase Publisher proposal!  We also need proposals for these components. See the proposals README.

@1025KB Does this interaction with Vertex conflict with any of our current plans?

Can you folks please provide an update on this?

Google has released a Pusher for Vertex:
https://github.com/tensorflow/tfx/tree/master/tfx/extensions/google_cloud_ai_platform/pusher
So IIUC there are at least two choices here:

Migrate this design to use the Google Vertex Pusher instead of vertex_uploader/vertex_deployer, -or-
Publish vertex_deployer as an alternative way of deploying models to Vertex

That suggests that it would be good to weigh the advantages of vertex_uploader/vertex_deployer over the Google Vertex Pusher.  If there are use-cases where it's a better fit, then it would be good to focus on those.

The deployer component is able to actually deploy a given model resource and it's version to Vertex. Not sure what the pusher component does (haven't yet taken a look at the code yet). From the name of it, seems like something that can take a model and have it uploaded as a Vertex AI model resource.

Just a reminder, I don't see a project proposal for this yet.  We have one for the Firebase Publisher, but I think that's a separate project, right?

No before that I wanted to clarify the scope and know if these two components about coincide. Currently I don't have a clear idea and you also suggested weighing the advantages and disadvantages of these two components over the one you folks published. So, happy to talk more here.

Ok cool, I just wanted to make sure that you weren't stalled waiting for
a response.
Robert Crowe | TensorFlow Developer Engineer | @.***  |
@robert_crowe https://twitter.com/robert_crowe
On Mon, Sep 6, 2021 at 5:41 PM Sayak Paul @.***> wrote:

No before that I wanted to clarify the scope and know if these two
components about coincide. Currently I don't have a clear idea and you also
suggested weighing the advantages and disadvantages of these two components
over the one you folks published. So, happy to talk more here.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tensorflow/tfx-addons/issues/67#issuecomment-913914461,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKVWSW5D5TSARGJCQY7FPS3UAVNTJANCNFSM5B3FFKTA
.
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.

Sure. So, what should be the next steps? Would you like to investigate the two components a bit more (example) and let me know if I should proceed with a proposal?

Google has released a Pusher for Vertex:
https://github.com/tensorflow/tfx/tree/master/tfx/extensions/google_cloud_ai_platform/pusher
So IIUC there are at least two choices here:

Migrate this design to use the Google Vertex Pusher instead of vertex_uploader/vertex_deployer, -or-
Publish vertex_deployer as an alternative way of deploying models to Vertex

That suggests that it would be good to weigh the advantages of vertex_uploader/vertex_deployer over the Google Vertex Pusher. If there are use-cases where it's a better fit, then it would be good to focus on those.

+1 on clarify the difference for vertex_uploader/vertex_deployer vs tfx cloud Pusher (which upload the model to server for prediction)

Then the deployer component would make sense then since it takes a Vertex model and deploys it to an endpoint.

Since the canonical Vertex Pusher already deploys to an endpoint, are there any other advantages to these components?

Nope.


Adds test about http mime with truncated file

due to request.body_limit configuration value
Replaces #1095 with using suricata.yaml to set value for outputs

Merged in #1181, thanks!


chore: release v0.3.23

:robot: I have created a release beep boop
0.3.23 (2024-04-22)
What's Changed

chore(deps): bump github.com/coffeebeats/gdenv from 0.6.16 to 0.6.19 by @dependabot in https://github.com/coffeebeats/gdbuild/pull/152
chore(deps): bump github.com/pelletier/go-toml/v2 from 2.2.0 to 2.2.1 by @dependabot in https://github.com/coffeebeats/gdbuild/pull/153
fix(config): run the run_before hook action in the manifest's directory by @coffeebeats in https://github.com/coffeebeats/gdbuild/pull/154

Full Changelog: https://github.com/coffeebeats/gdbuild/compare/v0.3.22...v0.3.23

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/coffeebeats/gdbuild/releases/tag/v0.3.23 :sunflower:


133 new ubo submission system suport

Thanks @tasosz , I have added your changes. I kept the Ubos as this will be launched soon.


Driver for Bosch BME680 sensor added

I have written a driver for the brand new and famous product from Bosch Sensortronic's, the BME680 sensor. It integrates temperature, pressure, humidity and gas sensors with high accuracy within a single unit. It is a very low-power device developed specifically for mobile applications and wearables where size and low power consumption are key requirements.
Please add the library to the master branch of the repository.
p.s. Because I had to learn using github (I used CVS for more than 20 years :-( ) I made some mistakes, e.g., I did not create separate branches for my developments. So I uploaded SHT3x driver developed some weeks ago to the master branch from which I drew now a branch for uploading this BME680 driver. So I think uploaded files of the SHT3x driver that are part of an open pull request are probably also part of this pull request :-(

@gschorcht Have you learnt about git rebase -i master yet? That makes it easy to squash multiple patches into just one, for example to clean it up to get it ready to submit. After that it will be necessary to do a force push git push -f bme680-drive. Also take a look a git cherry-pick, useful for moving some patches across to a new branch to split them and then git rebase -i can be used to removed them from the prior branch. You can use that to make a branch for the sht3x patches and get them off your master branch, then reset your master branch back to the upstream master.

I closed the pull request for the moment because I'm thinking about a redesign of the drive before it is merged in the master branch. The redesign should make the driver interface clearer and easier to use. I'm not sure yet, a possible change could be to remove the implicit mean value computation during each measurement cycle and to make it the responsibility of the user, if this is required.
Since the driver was still not merged into the master branch there shouldn't be any compatibility problems.
I will readd the driver and open a new pull request once the redesign has been finished.


🆕 New plugin API (request for feedback)

Today, Knip has 55 plugins, and they're all using a somewhat complicated findDependencies function. Merging quite a few plugins, and seeing various requirements and implementations, gave me a better understanding of what we need here and how the plugin API could be improved.
So that's what I'm trying to do: gather your feedback! Just a thumbs up 👍 is great, too :)
New to Knip plugins? 🦄
If you're new to Knip plugins, perhaps it's best to ignore any history here and see whether the updated docs make sense: Writing A Plugin. Then you might want to skip straight to WDYT.
Implemented or fixed a plugin before? 😎
If you're part of Knip's elite Cool Club™ and implemented or fixed a plugin before, here are the subtle improvements:

No more timerify() wrapping
No more isProduction checks
No more basename(configFilePath) === 'package.json' checks
No more screaming uppercased CONFIG_FILE_PATTERNS exports, just config, entry, production
Subpath imports, e.g. '../../util/plugin.js' → '#p/util/plugin.js'
Plugin tests are now always "integration tests" using the main() function
The template to scaffold a new plugin is much easier to grasp

Yet the major difference is in what's currently the findDependencies function. Now there's just 3 functions to mix & match:

Use none of the functions (only entry or production patterns)
resolveConfig - get dependencies from config object (82% use this)
resolveEntryPaths - get entry paths from config object (20% use this)
resolve - for everything else (one plugin uses this)

On one hand it might feel hard to justify going from 1 function to 3. On the other hand, plugin implementations are arguably easier to understand and need less code. Here's a few side-by-side diffs:

Cypress
Next.js
tsup
...and many more lines removed in the same commit:

1008 insertions(+), 1585 deletions(-)

No breaking changes
There are no breaking changes, since no user config needs to change, and everything is still internal to Knip. Plugin API is not (yet?) exposed for external/custom plugins.
Try it before the release
The unit tests are passing, the integration suite too. But nothing beats actual coverage on your own projects! Would be great if you could run this version of Knip on your project(s):
npm install knip@plugins

Please report any regressions you may find.
WDYT?

In general, do you think the plugin API makes sense?
Is something still missing?
Are the docs (Writing A Plugin) helpful?
And how about the function names? Going from only findDependencies to:

name
desc

resolveConfig
Receive config object, extract & return dependencies

resolveEntryPaths
Receive config object, extract & return entry paths

resolve
No config object, none of the above, do anything

Nothing is set in stone, no rush. If you have ideas or know about similar examples (that have different APIs) I'm all ears! Thanks for reading 🙏

cc-ing a few people recently active in this area (hope you don't mind!) @beaussan @uncenter @jgoux @drodil @risu729 @jmcpeak @thenbe @what1s1ove @voxpelli

No problem on the ping! The changes look clean and helpful, and I've done some testing on a couple of repositories and can report zero regressions for the Eleventy and Netlify plugins.

Thanks @uncenter! Great to hear. Appreciate you've run it on those projects, this builds up confidence in the changes.
I forgot, the clearest view on the changes (next to the docs) is probably the new template: https://github.com/webpro/knip/blob/plugins/packages/knip/src/plugins/_template/index.ts

Plugin API is not (yet?) exposed for external/custom plugins.

Would this be a good time to start opening knip up to external/custom plugins? I'm working on a large application that has a need for custom plugins that are specific to the application and wouldn't really make sense as an internal feature of knip. It would be great to be able to do something like:
// knip.config.ts
import MyCustomPlugin from './my-custom-plugin';

const config: KnipConfig = {
  plugins: [MyCustomPlugin],
}

export default config;

No worries for the ping!

In general, do you think the plugin API makes sense?
Is something still missing?

First of all, I know this comes down to personal preferences so feel free to reject my idea.
I would love to expose a single object that can be strongly typed instead of relying on magic exports based on their names. This means that discoverability of api as a plugin is easier since they are automatically exposed via type completion, and it's a safer way to write a plugin given it's type safe.
There might be a reason this was not the case however that I might be missing 👀

Would this be a good time to start opening knip up to external/custom plugins?

My own proposal just got merged and released earlier today. Let's see how this goes. To be honest, at this point I'm a bit on the fence with the idea, since it'll obviously also increase API surface and maintenance burden.

No worries for the ping!

In general, do you think the plugin API makes sense?
Is something still missing?

First of all, I know this comes down to personal preferences so feel free to reject my idea.
I would love to expose a single object that can be strongly typed instead of relying on magic exports based on their names. This means that discoverability of api as a plugin is easier since they are automatically exposed via type completion, and it's a safer way to write a plugin given it's type safe.
There might be a reason this was not the case however that I might be missing 👀

The plugin's indeed have a single default-exported object. Just merged it earlier today :)
Like so? https://github.com/webpro/knip/blob/main/packages/knip/src/plugins/_template/index.ts#L33-L34
Realized not all plugins did this yet, so that's fixed up too now. Either way, since everything is internal to Knip we could still change anything :)

Exactly like so! I've must have looked at some plugins that didn't had their migration yet

Closing this one as it's merged. Thanks for the help & feedback!


break out of nest and keep base

Hi
I have this route config
<Router base="/admin">
    <Route path="/account" nest>
        <Route path="/login"/>
    <Route>
    <Route path="/home" nest>
        <Route path="/projects"/>
    <Route>
</Router>

I would like jump to /admin/home/projects from /admin/account/login, so I need use setLocation('~/admin/home/projects')
Is there a way to keep base and break out of nest?
like setLocation('@/home/projects') -->"/admin/home/projects"

No, there is no way to make it work like that at the moment. Actually, <Route nest> internally creates a new Router with a special base prop, so we can't really distinguish between nested routes and routers with base attribute. The ~ modifier only works with top-level paths.

I understand. Thank you for your answer.


feat(client): add certification layout for c sharp cert

Adds layout for C# certification. To test it, earn any cert and change line 217 in show-certification.tsx to:
  const { date, name: userFullName = null, username } = cert;
  let { certTitle } = cert;
  certTitle = certTypeTitleMap[certTypes.foundationalCSharp];

It won't show the correct URL in the address bar or the URL at the bottom of the cert - it will when it's the actual cert. Also, it's not 100% responsive, but it's pretty close.
Checklist:

[x] I have read and followed the contribution guidelines.
[x] I have read and followed the how to open a pull request guide.
[x] My pull request targets the main branch of freeCodeCamp.
[x] I have tested these changes either locally on my machine, or GitPod.

Closes #XXXXX

@Sboonny are you planning on making more changes or is this ready for review?

The layout should be functional to unblock Tom, I am not adding more changes, unless there is a need for it, I prefer creating different PR later when this is done.


Duplicate VimStates being created after updating vim-mode

see https://github.com/atom/vim-mode/issues/478 for more information.
The difference between issue #478 and this is

#478 was addressing duplication of VimState when moving a file between split panes
After updating vim-mode, it seems like a "global" VimState is being duplicated.

In this case, all files experience the duplication issue and closing and re-opening files does not remove the problem.
(I'm not sure if this is actually a problem and that we should be restarting Atom when updating packages anyway... in which case we can just close this issue.)

Is this still happening? I don't know why it happened originally, but I haven't seen it happen for the past few updates.

hm, I haven't been looking for along with the updates that I've been doing... but that also means I haven't noticed it either. Can't verify that I haven't just missed it as I've been doing a decent amount of restarting lately.

Ok, let's keep it open for now. I think it might be fixed though; can you try and see if anything strange happens on your next update?

yep, i'll let you know
On Fri, Feb 20, 2015 at 12:17 PM, Max Brunsfeld<EMAIL_ADDRESS>wrote:

Ok, let's keep it open for now. I think it might be fixed though; can you
try and see if anything strange happens on your next update?
—
Reply to this email directly or view it on GitHub
https://github.com/atom/vim-mode/issues/480#issuecomment-75278778.

--
Quentin Tai
CTO/Co-founder Lynxsy
c:<PHONE_NUMBER>
e<EMAIL_ADDRESS>Sign Up! Lynxsy http://lynxsy.com/
Follow Us: Facebook https://www.facebook.com/Lynxsy | Twitter
https://twitter.com/LynxsySays

Ah, I see it. It's because sometimes vim-mode fails to deactivate with an error like this:
Error deactivating package 'vim-mode' TypeError: Cannot read property 'setInputEnabled' of null
  at VimState.module.exports.VimState.destroy (/Users/maxbrunsfeld/.atom/packages/vim-mode/lib/vim-state.coffee:46:29)
  at Disposable.disposalAction (/Users/maxbrunsfeld/.atom/packages/vim-mode/lib/vim-mode.coffee:31:20)
  at Disposable.module.exports.Disposable.dispose (/Users/maxbrunsfeld/.atom/packages/vim-mode/node_modules/event-kit/lib/disposable.js:21:65)
  at CompositeDisposable.module.exports.CompositeDisposable.dispose (/Users/maxbrunsfeld/.atom/packages/vim-mode/node_modules/event-kit/lib/composite-disposable.js:28:22)
  at Object.module.exports.deactivate (/Users/maxbrunsfeld/.atom/packages/vim-mode/lib/vim-mode.coffee:34:18)
  at Package.module.exports.Package.deactivate (/Applications/Atom.app/Contents/Resources/app/src/package.js:603:21)
  at PackageManager.module.exports.PackageManager.deactivatePackage (/Applications/Atom.app/Contents/Resources/app/src/package-manager.js:501:12)
  at PackageManager.module.exports.PackageManager.update (/Applications/Atom.app/Contents/Resources/app/node_modules/settings-view/lib/package-manager.js:215:23)
  at PackageUpdateView.module.exports.PackageUpdateView.upgrade (/Applications/Atom.app/Contents/Resources/app/node_modules/settings-view/lib/package-update-view.js:175:34)
  at HTMLButtonElement.<anonymous> (/Applications/Atom.app/Contents/Resources/app/node_modules/settings-view/lib/package-update-view.js:78:24)
  at HTMLButtonElement.jQuery.event.dispatch (/Applications/Atom.app/Contents/Resources/app/node_modules/jquery/dist/jquery.js:4430:9)
  at HTMLButtonElement.elemData.handle (/Applications/Atom.app/Contents/Resources/app/node_modules/jquery/dist/jquery.js:4116:28)
/Applications/Atom.app/Contents/Resources/app/src/package.js:608 module.exports.Package.deactivate

That error prevents the command listeners from being unregistered.


Remove django-oauth-toolkit version pin

We need to wait for a new upstream release before this can be merged.

This isn't actually fixed, but the pinning can now be controlled authoritatively by django-composed-configuration.

This isn't actually fixed, but the pinning can now be controlled authoritatively by django-composed-configuration.


Add touchpad swipe gesture support in the Flutter Embedder

Use case
Currently the trackpad APIs only allow for 2-finger scrolling type gestures. This means that flutter applications and embedders have no way to introduce any kind of 3-finger swipe gestures to their users. A large majority of trackpads also support that feature. This change would allow for 3 finger or more gestures on the trackpad, dramatically improving Flutter's gesture abilities.
Proposal
I propose we add an API that either simply produces events for 3 swipe gestures or 4 swipe gestures, or an API where we report back the number of fingers on the trackpad and let flutter decide the internal logic.

We could add pointerCount to PointerPanZoom? Right now I just assume it to be 2 everywhere

Hmm yeah that would be the cleanest solution. I can't speak for MacOs and Windows but for GTK3, we aren't exposed to the number of fingers on the trackpad directly so we'll need to manually add 3 finger and 4 finger events.

I don't have the permission to assign this to myself so fyi I'm working on the Linux side of things :)

Doesn't the embedder already support this? Does the framework need support for these gestures?

@chinmaygarde double checked, the engine supports this. @jason-simmons mentions that maybe the linux embedder is missing this?

What APi refers to the pointer counter in the Embedder.h file?

I think a bit of confusion in terms here. Seems like the only actual work is to add pointer count. But there is some mixup with "swipe" vs "scroll"

Ah yes, I'm referring to the idea of being able to scroll with 2 fingers or more. So a PointerPanZoomEvent with a pointer count.

I didn't do it in the first place since on every other platform, 3/4 finger gestures are reserved for operating system gestures like window management

Yes but this becomes an issue when flutter is used in Embedded devices or as part of a Desktop Environment.

No problem with adding it just explaining why it's not there yet. Although the more you go towards a full DE or something, you may need to change the API shape, to expose individual finger touch positions. But from what you posted so far I don't think it's necessary.


Add support for .zuul-repos.d

This will use vexxhost mirrors for our container jobs.
Depends-On: https://github.com/ansible/ansible-builder/pull/272
Signed-off-by: Paul Belanger<EMAIL_ADDRESS>

recheck

Pull-request updated, HEAD is now 19d771c6f9ee4ce5a7bdca8e09f31405db3005cc

Pull-request updated, HEAD is now dbb9d19a5561daca1d846c45e78e30edb44dffaa


More Sorting Options

https://github.com/NickvisionApps/Tagger/issues/125#issuecomment-1662673452

https://github.com/NickvisionApps/Tagger/releases/tag/2023.8.1


Add Content-Type application/json for XHR

The content type should be set to JSON since it's a JSON payload.
Some servers will not interpret it as JSON otherwise.  For example, node's express server middleware will not parse the body and convert it to an object.
This is against branch 2.x since master does not have the XHR feature yet.  Let me know if I should resubmit against a different branch.
Thanks!

This is against branch 2.x

Looks like you accidentally targeted master in GitHub. Unfortunately GitHub doesn't let you change the target branch, so you'll have to re-open this as a new PR against 2.x.

Oh, and @mattrobenolt reminds me – we can't accept this patch.
If we specify this Content-type header value, browsers will trigger an OPTIONS preflight request as part of CORS. It also means this request will not work at all in IE8 and IE9, since they have more limited CORS implementations.
more here: http://stackoverflow.com/a/12320736

That however breaks on latest React / Android - adding console.log in react-native plugin gives me status: '0', message: 'Payload is set but no content-type header specified' which is coming from native java module.

I assume we could do this for React Native without triggering the OPTIONS preflight request?

I've decided to open an issue regardless, haven't expected such quick answer!  ( #526 ) I am not sure if the above concerns also apply to React Native since native code is involved on both platforms (e.g. okhttp on android)

Totally. My hunch is its ok for us to do it for React Native, but @benvinegar will need to confirm. Thanks for letting us know. :)

Yeah React Native basically ignores cross-origin rules. We can implement this in the React Native transport.