Issue with running on ADO build agents

Hello, the Get-FolderContents code seems to work locally (Windows 10) but when run on an ADO build agent it gives me the following:

Something appears to be going on with the JWTs specifically run on vs2017-win2016 build agents. Super confusing why this is a problem.

Hello! 403 is forbidden.

@RichieBzzzt  That indeed was the issue with using key vault secrets. I was bungling that. I do however have another issue with 429 problems and I will open another issue for that.


Different page link styles in settings

Hi,
Just wanted to add another issue, but I think it could be connected to this one. Kindly asking if it is possible to add slight different colour to page links.
Other than that, your work is pretty damn good. I like to minimalistic style of it.
Cheers!


Add the eslint-plugin-testing-library to app

Problem: Lack of tools to help avoid common mistakes and bad practices in test files.
In project worked on by multiple developers, it can be difficult to follow best practices and avoid common mistakes when in comes to testing. Developers may miss important aspects like missing assertions, unused queries, or problematic testing patterns. Without proper tooling, it's challenging to maintain consistency and catch these errors early in the development process.
Solution:
Adding eslint-plugin-testing-library to ensure that developers follow recommended practices when writing tests with React Native Testing Library. This includes enforcing conventions, preventing common mistakes, and promoting readable and maintainable test code.
This library offers specific presets tailored for different testing libraries. For React Native Testing Library, we can utilize the React preset, ensuring that the rules are optimized for the nuances of testing in a React Native environment. This preset streamlines the configuration process, making it easy for teams to adopt eslint-plugin-testing-library without extensive setup overhead.
The plugin provides a set of rules that can be configured in ESLint configuration file. These rules cover various aspects of testing with RNTL,  such as preferring specific query methods, enforcing async/await usage, discouraging direct DOM access, and more.
It is worth noting that this approach is recommended by RNTL maintainers: Maciej Jastrzębski on Twitter / X .
We could implement following rules:
'testing-library/await-async-queries': 'error',
'testing-library/await-async-utils': 'error',
'testing-library/no-debugging-utils': 'error',
'testing-library/no-manual-cleanup': 'error',
'testing-library/no-unnecessary-act': 'error',
'testing-library/prefer-find-by': 'error',
'testing-library/prefer-presence-queries': 'error',
'testing-library/prefer-screen-queries': 'error',

Setting the above rules will require updating 7 test files, which can be done along with adding the configuration.
cc @OlimpiaZurek

This is done now, no payments required


[boost-vcpkg-helpers] Build error

Package: boost-vcpkg-helpers[core]:x64-windows -> 1.81.0#2
Host Environment

Host: x64-windows
Compiler: MSVC 19.34.31937.0
vcpkg-tool version: 2023-01-24-8a88d63f241d391772fbde69af9cab96c3c64c75
vcpkg-scripts version: 0ba60bfef 2023-02-03 (3 days ago)

To Reproduce
vcpkg install osgearth:x64-windows
Failure logs
-- Downloading https://raw.githubusercontent.com/boostorg/boost/boost-1.81.0/LICENSE_1_0.txt -> boost_LICENSE_1_0.txt...
[DEBUG] To include the environment variables in debug output, pass --debug-env
[DEBUG] Feature flag 'binarycaching' unset
[DEBUG] Feature flag 'compilertracking' unset
[DEBUG] Feature flag 'registries' unset
[DEBUG] Feature flag 'versions' unset
Downloading https://raw.githubusercontent.com/boostorg/boost/boost-1.81.0/LICENSE_1_0.txt
warning: Download failed -- retrying after 1000ms
warning: Download failed -- retrying after 2000ms
warning: Download failed -- retrying after 4000ms
error: Failed to download from mirror set
error: https://raw.githubusercontent.com/boostorg/boost/boost-1.81.0/LICENSE_1_0.txt: WinHttpSendRequest failed with exit code 12002
error: https://raw.githubusercontent.com/boostorg/boost/boost-1.81.0/LICENSE_1_0.txt: WinHttpSendRequest failed with exit code 12002
error: https://raw.githubusercontent.com/boostorg/boost/boost-1.81.0/LICENSE_1_0.txt: WinHttpSendRequest failed with exit code 12002
error: https://raw.githubusercontent.com/boostorg/boost/boost-1.81.0/LICENSE_1_0.txt: WinHttpSendRequest failed with exit code 12002
[DEBUG] D:\a\_work\1\s\src\vcpkg\base\downloads.cpp(956):
[DEBUG] Time in subprocesses: 0 us
[DEBUG] Time in parsing JSON: 6 us
[DEBUG] Time in JSON reader: 0 us
[DEBUG] Time in filesystem: 25529 us
[DEBUG] Time in loading ports: 0 us
[DEBUG] Exiting after 2.94 min (175695478 us)

CMake Error at scripts/cmake/vcpkg_download_distfile.cmake:32 (message):

      Failed to download file with error: 1
      If you use a proxy, please check your proxy setting. Possible causes are:

      1. You are actually using an HTTP proxy, but setting HTTPS_PROXY variable
         to `https://address:port`. This is not correct, because `https://` prefix
         claims the proxy is an HTTPS proxy, while your proxy (v2ray, shadowsocksr
         , etc..) is an HTTP proxy. Try setting `http://address:port` to both
         HTTP_PROXY and HTTPS_PROXY instead.

      2. You are using Fiddler. Currently a bug (https://github.com/microsoft/vcpkg/issues/17752)
         will set HTTPS_PROXY to `https://fiddler_address:port` which lead to problem 1 above.
         Workaround is open Windows 10 Settings App, and search for Proxy Configuration page,
         Change `http=address:port;https=address:port` to `address`, and fill the port number.

      3. Your proxy's remote server is out of service.

      In future vcpkg releases, if you are using Windows, you no longer need to set
      HTTP(S)_PROXY environment variables. Vcpkg will simply apply Windows IE Proxy
      Settings set by your proxy software. See (https://github.com/microsoft/vcpkg-tool/pull/49)
      and (https://github.com/microsoft/vcpkg-tool/pull/77)

      Otherwise, please submit an issue at https://github.com/Microsoft/vcpkg/issues

Call Stack (most recent call first):
  scripts/cmake/vcpkg_download_distfile.cmake:273 (z_vcpkg_download_distfile_show_proxy_and_fail)
  ports/boost-vcpkg-helpers/portfile.cmake:4 (vcpkg_download_distfile)
  scripts/ports.cmake:147 (include)

Duplicate of https://github.com/microsoft/vcpkg/issues/29395.


Add Privacy Statement and License menu items

Add the following two menu items into Help

View License goes to https://github.com/Microsoft/sqlopsstudio/blob/master/LICENSE.txt
Privacy Statement goes to https://privacy.microsoft.com/en-us/privacystatement


Bump to 0.4.0

@jlowry Want to test pulling this in as a branch before we release?

Gentle nudge.

It's in use on legion_v2 and seems to be working.

@jlowry I gave you write permissions to this repo, which should enable bors to work for you in the future.
bors r+

@jlowry I gave you write permissions to this repo, which should enable bors to work for you in the future.
bors r+

bors r+

bors r+

serde-diff and serde-diff-derive v0.4.0 have been released.

serde-diff and serde-diff-derive v0.4.0 have been released.


Add error metrics and DLQ support to GCS/File write schema transforms

Add metrics to all FileWriteSchemaTransforms. A few refactoring is needed to make this possible

Change all FileSchemaTransformFormatProvider to returning PCollectionTuple instead of just PCollection<String> to plumb error rows out
Add an ErrorCounterFn that can be used generally with all FileSchemaTransforms.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

r: @Dippatel98 @manavgarg @johnjcasey

Thanks Nick for the changes. Please address the remaining comments from John but otherwise LGTM.

lgtm


Fix not found errors of tensor expr tutorial

I'm not sure this fix is appropriate or not because there are bunch of tvm.testing in this repository, but tvm.testing was not found on tvmai/demo-cpu docker image.

I found that tvm in the docker image was v0.4.0 which did not have tvm.testing.


NLB - support - a topic here?

It is my understanding that NLB and ALB use the same (similar) API for configuration.
Is NLB support a topic here?

@pmoosh Yeah, as far as I understand, with targetgroups, the API is quite similar.
However, based on discussion in sig-aws, it seems there's intention to replace the native ELB integration with the NLB.
In fact I believe @micahhausler is working on it so perhaps he can provide some context.
If we find a need (or someone makes the case) for including the NLB provision in the ALB controller, i'm open to it.

@joshrosso - thanks for your rapid reply.
Do you have a pointer to ongoing discussion at aws-sig?
Replacing/Adding the NLB to the native (classic) ELB integration seems a lot of work.
I glazed over the changes a bit an it seems that the main differentiator is the LoadBalancerType, which I don't think you guys set as you rely on the default setting. Although I haven't where you would define the optional EIP for the NLB. I am a go beginner, so I am trying to make sense of the code :-)
again thanks

@pmoosh : no problem.
I'm not certain how much work it would be regarding the default Loadbalancer integration (haven't looked into the code myself).
The GitHub issue is https://github.com/kubernetes/kubernetes/issues/52173.
Hope this helps.

Hi all,
On the sig-aws call on Friday, it sounded to me like the intent is to add support for (but not replace) NLB's. I've been working on kubernetes/kubernetes#52173, and have made good progress, however the API requires more calls for an NLB than a classic ELB, but its totally doable.
As noted in previous comments, the API for NLB is very similar to ALB, but I don't think that NLB would work that well for an k8s ingress controller. K8s ingress controllers route based on paths and hostnames, so ALB is a great natural fit. The only thing you can do with NLB is route TCP traffic, so any ingress rules that specify hostnames or paths would be kind of useless.

One more thought: an NLB would work very well paired with an in-cluster ingress-controller, as the source-IP would be preserved all the way to the ingress controller.
Right now in order to preserve the source IP, you have to turn on PROXY protocol on the ELB and your ingress controller has to support PROXY protocol.

@micahhausler - In my use case  source IP preservation and Static IP Addresses are the reasons to use NLB.

Agree with all the comments made by @micahhausler above. NLB integrated (as on option rather than replacement) for k8s-aws Loadbalancer integration is likely to be better for the community as a whole rather than rolling it into this controller.
Whether to use ALB -> nodeports -> pods or NLB -> ingress controller -> pods will really come down to an architectural preference.

Sounds good to me.

Is the NLB supported already here?
I find NLB really useful here as API Gateway is a service that lives outside the VPC; it is completely hosted and maintained in an AWS owned VPC, and its underlying infrastructure is invisible. API Gateway uses AWS PrivateLink technology to connect to the private resources. PrivateLink publishes services based on Network Load Balancers. As such, API Gateway can only connect to the private resources through an internal NLB. In the API Gateway console, you can create a VPC Link pointing to this NLB. The VPC Link can be used in your API Gateway definitions.

@Passpes
Hi, the NLB support is built into k8s, you can add annotation service.beta.kubernetes.io/aws-load-balancer-type: "nlb" to your service, which will provision an nlb instead of default elb.

Actually I know that annotation but in my case we need multiple target groups for different services and alb-ingress-controller supports that but misses the NLB, would be great to include it as it’s helpful for Microservices architechture linked with API gateway and VPC link.

@Passpes
Hi, actually we have thought of build an ingress controller based on API gateway and NLB as well.
Would you help share us the gaps between APIGateway and ALB that make this architecture?
Currently, i'm only aware the rate limiting feature.

Well basically API gateway supports some good security features and authentication for example with cognito and also a great API to call multipe AWS resources at the same time and link them together, so on of these resources are the microservices leaving on k8s therefore we need to link API gateway to those microservices -> the only way to do that is using NLB as explained, I think first step you can help implement NLB annotation as it’s supported by kubernetes already if possible soonish and later maybe adding API gateway from there.


cargo-whatfeatures: 0.9.7 -> 0.9.9

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/cargo-whatfeatures/versions.
meta.description for cargo-whatfeatures is: "A simple cargo plugin to get a list of features for a specific crate"
meta.homepage for cargo-whatfeatures is: "https://github.com/museun/cargo-whatfeatures"
meta.changelog for cargo-whatfeatures is: ""
Updates performed

Rust version update

To inspect upstream changes

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.9.9 with grep in /nix/store/124m5xzlncddpzb4vq34a50wqw8hdhvm-cargo-whatfeatures-0.9.9
found 0.9.9 in filename of file in /nix/store/124m5xzlncddpzb4vq34a50wqw8hdhvm-cargo-whatfeatures-0.9.9

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
cargo-whatfeatures

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/124m5xzlncddpzb4vq34a50wqw8hdhvm-cargo-whatfeatures-0.9.9 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A cargo-whatfeatures https://github.com/r-ryantm/nixpkgs/archive/d7af68bd878ab7a6385f192d670e6a0122c46337.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/124m5xzlncddpzb4vq34a50wqw8hdhvm-cargo-whatfeatures-0.9.9
ls -la /nix/store/124m5xzlncddpzb4vq34a50wqw8hdhvm-cargo-whatfeatures-0.9.9/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

cargo-whatfeatures

Maintainer pings
cc @bobrik for testing.

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

1 package built:

cargo-whatfeatures


Android adaptive app icon not properly sized for round icons

I created both legacy and adaptive icons for my android project
/resources
     -> icon.png (1024x1024)
     -> splash.png (2732x2732)
   /android
      -> icon-foreground.png (432x432)

cordova-res android --icon-background-source "#FFFFFF"

But on my Pixel3a uses the round icons shows like the inner 50% of png file - like if you zoomed in to 150%.  Its not sized properly.   How can I correct this?

Where are all the icons copied to so I can delete them?
There is now app/src/main/res/icon folder similar to the projectRoot/resources/android/icon folder the new icons are created in.

Exactly the same issue here, the images end up being displayed as about the 50% of the icon, whilst using the same images to make android studio generate the adaptive icons (new image assets) renders the correct result. Is an example-setup for adaptive icons a possibility?

@iwantwin - I tried using the Image Asset studio tool and it creates all my images but it does not create the ic_launcher_foreground.xml file - without it the build fails because ic_launcher.xml and ic_launcher_round.xml both reference the foreground.xml file.  I am using a legacy app icon.png for my Asset image and using a white color as the background,  it generates all the png files and the ic_launcher_background.xml file - but again, not the foreground.xml file.  I noticed if I use a png for the background as well, that it too does not generate the ic_launcher_background.xml file.  All of this is driving me nuts and I am wasting a huge amount of time on this.

@rolinger I used cordova-res to generate the adaptive icons, then I used the Asset studio tool with my source images, I made sure to select the foreground, and background image, then in the tab for 'other settings' I selected 'no' for all legacy icon options. I then worked fine for me, but it is an undesired workaround ofcourse.
I did not experience issues with any xml file during this flow.

@iwantwin - I will give that a shot.  Which cordova-res images did you specifically use as the source images for the Image Asset tool?
Regarding the cordova-res issue, all the file sizes generated appear to be the correct img sizes for all the respective mipmap/drawable folders.  So not certain why my devices using adaptive icons are zoomed in on my icons.  I have posted for help on this for three days across several forums (and the Image Asset problem too) and you are the first to respond to any of my questions/queries.  That too has been adding to my frustration.

File structure:
resources/icon.png
resources/splash.png
resources/android/icon-background.png
resources/android/icon-foreground.png
I used the icon-background & icon-foreground images in the Image Asset tool.

Same for me, the images seem to be fine, and no  configuration seems to change when using the Image Asset tool, so I'm absolutely blank on what is wrong with the generated output. Perhaps @dwieeb could shed some light here?

@iwantwin - but in cordova-res we create our own icon-background.png and icon-foreground.png files and place them in the resources/android/ folder.  So if you are using those files for Image Asset tool in Android Studio, then technically you are using your own files that you physically created.  Or am I missing something?

Yes, I'm actually using the files I created myself that I would usually feed to cordova-res. So I'm not sure the cordova-res step is even necessary if you are going to build it with the Asset tool (but,  for my use case, cordova-res is absolutely the preferred case, so I hope we get either a fix or clarity soon)

@iwantwin - well, I turned to cordova-res because of my earlier statements regarding Image Asset tool not generating the ic_launcher_foreground.xml file.  Because of those issues, I turned to cordova-res and had a lot more success - except for the sizing issue that I, like you, can't seem to resolve.  So at the moment, for devices that use adaptive icons, my icon is either all white (Image Asset) or my app icon is the inner 50% (cordova-res).  In both cases, all my legacy square icons are correct for devices that don't use adaptive icons.

Hope we get more information to resolve this issue soon :)

With adaptive icons, only the inner 66.66% of the inner image is shown. See Figure 2 of https://developer.android.com/guide/practices/ui_guidelines/icon_design_adaptive.

Both layers must be sized at 108 x 108 dp.
The inner 72 x 72 dp of the icon appears within the masked viewport.
The system reserves the outer 18 dp on each of the 4 sides to create interesting visual effects, such as parallax or pulsing.

The foreground image you use must be scaled for use with adaptive icons. Does this sound like your issue?

@dwieeb  - the docs say to create an /resources/android/icon-foreground.png image of at least 432x432.  Thats what I did.   Then all the images are auto-generated.  But its sounds like that 432x432 is incorrect.  What should the source file size be?

432x432px is the correct size. 432px is 108dp at a pixel density of 4x, which is currently the maximum pixel density supported by the Android platform. See https://developer.android.com/training/multiscreen/screendensities
I think your issue is that you're not accounting for the mask. You're just reusing icon.png for icon-foreground.png. Correct me if I'm wrong. The icon-foreground.png should fit within the safe area demonstrated in the Android documentation.

So your saying my actual image for icon-foreground.png needs to be 66% of the 432x432?  Thus my actual image would be 288x288 (66%) and the remaining 33% would be transparent/white space around the centered image?
If thats the case this is not explained very well at all.  The docs indicate if you provide an image of 432x432 the plugin will shrink it accordingly - as in shrink the image to that 66% for you and include the whitespace/transparency around the image for you.

@dwieeb - as well, I am now using Android Studio Image Asset (which I finally got working correctly), and I size my image to be within the "safe zone" in the tool and then export all my images and link the resource files properly in my config.xml - when my app builds it shows the same "zoomed" in image as cordova-res is showing me.

@dwieeb -well, kudos to you.  In Image Asset tool I was trimming my image which was then auto-fitting it to the safe zone.  But that wasn't working.  So I set "trim" to no then sized my image manually down to the safe zone - and that worked!  friggin' finally.
I think cordova-res should take a 432x432 file an auto-size it down to the safe zone and provide the mask around the image.  The whole point of a tool like this is to automate the process - and that automation would ensure the proper sized image - with safe zone and proper masks - for everyone, taking out all the guess work.

Good to hear.

I think cordova-res should take a 432x432 file an auto-size it down to the safe zone and provide the mask around the image.

It's a fair point. It's hard to know where to draw the line with tools like this. We can't take out all the guess work. At some point, the dev needs to understand how adaptive icons work. I think the answer is we just need more documentation. Although I think the current behavior is best at this time, we could potentially have an option for the behavior you're asking for.

@dwieeb  -  Agreed.  More documentation.  I have been building apps for 3 years and these adaptive icons threw me fits for nearly 4 days.  A simple update to the docs:
Image size should be at least 432x432 dpi - and this size should include the mask around the  centered image.  If the  image takes up the full 432x432, the generated adaptive icons will look zoomed in on - or something to that effect.  Just that wording alone would have clued me in to details I was overlooking.

I'm closing this in favor of https://github.com/ionic-team/cordova-res/issues/118. The upcoming --icon-foreground-trim option is exactly what you (@rolinger and others) want. Thanks for being so responsive and helpful! 🍻

@dwieeb - you rock.  Where do I send beers to?!

@dwieeb awesome! Sounds like it's exactly what we need! :) Be sure to mention it in the docs as well 👍

I spent a few days on this... for anyone else who is still having problems getting icons to show up properly and not be cut off.

Import your Cordova project into Android Studio
Click on the 'app' folder in the left pane
In the menu go to File -> New -> Image Asset
Fill out the form with your image and make sure the image is not larger than the offset
Copy the images generated in the Android project folder  platforms\android\app\src\main\res into your res\android
Use the following code in your config.xml platform android section

`

    <resource-file src="res/android/values/ic_launcher_background.xml" target="app/src/main/res/values/ic_launcher_background.xml" />

    <!-- any dpi -->
    <resource-file src="res/android/mipmap-anydpi-v26/ic_launcher.xml" target="app/src/main/res/mipmap-anydpi-v26/ic_launcher.xml" />
    <resource-file src="res/android/mipmap-anydpi-v26/ic_launcher_round.xml" target="app/src/main/res/mipmap-anydpi-v26/ic_launcher_round.xml" />

    <!-- ldpi -->
    <resource-file src="res/android/mipmap-ldpi/ic_launcher.png" target="app/src/main/res/mipmap-ldpi/ic_launcher.png" />

    <!-- ldpi v26-->
    <resource-file src="res/android/mipmap-ldpi-v26/ic_launcher_foreground.png" target="app/src/main/res/mipmap-ldpi-v26/ic_launcher_foreground.png" />
    <resource-file src="res/android/mipmap-ldpi-v26/ic_launcher_background.png" target="app/src/main/res/mipmap-ldpi-v26/ic_launcher_background.png" />
    <resource-file src="res/android/mipmap-ldpi-v26/ic_launcher.xml" target="app/src/main/res/mipmap-ldpi-v26/ic_launcher.xml" />

    <!-- mdpi -->
    <resource-file src="res/android/mipmap-mdpi/ic_launcher.png" target="app/src/main/res/mipmap-mdpi/ic_launcher.png" />
    <resource-file src="res/android/mipmap-mdpi/ic_launcher_round.png" target="app/src/main/res/mipmap-mdpi/ic_launcher_round.png" />
    <resource-file src="res/android/mipmap-mdpi/ic_launcher_foreground.png" target="app/src/main/res/mipmap-mdpi/ic_launcher_foreground.png" />

    <!-- mdpi v26-->
    <resource-file src="res/android/mipmap-mdpi-v26/ic_launcher_foreground.png" target="app/src/main/res/mipmap-mdpi-v26/ic_launcher_foreground.png" />
    <resource-file src="res/android/mipmap-mdpi-v26/ic_launcher_background.png" target="app/src/main/res/mipmap-mdpi-v26/ic_launcher_background.png" />
    <resource-file src="res/android/mipmap-mdpi-v26/ic_launcher.xml" target="app/src/main/res/mipmap-mdpi-v26/ic_launcher.xml" />

    <!-- hdpi -->
    <resource-file src="res/android/mipmap-hdpi/ic_launcher.png" target="app/src/main/res/mipmap-hdpi/ic_launcher.png" />
    <resource-file src="res/android/mipmap-hdpi/ic_launcher_round.png" target="app/src/main/res/mipmap-hdpi/ic_launcher_round.png" />
    <resource-file src="res/android/mipmap-hdpi/ic_launcher_foreground.png" target="app/src/main/res/mipmap-hdpi/ic_launcher_foreground.png" />

    <!-- hdpi v26-->
    <resource-file src="res/android/mipmap-hdpi-v26/ic_launcher_foreground.png" target="app/src/main/res/mipmap-hdpi-v26/ic_launcher_foreground.png" />
    <resource-file src="res/android/mipmap-hdpi-v26/ic_launcher_background.png" target="app/src/main/res/mipmap-hdpi-v26/ic_launcher_background.png" />
    <resource-file src="res/android/mipmap-hdpi-v26/ic_launcher.xml" target="app/src/main/res/mipmap-hdpi-v26/ic_launcher.xml" />

    <!-- xhdpi -->
    <resource-file src="res/android/mipmap-xhdpi/ic_launcher.png" target="app/src/main/res/mipmap-xhdpi/ic_launcher.png" />
    <resource-file src="res/android/mipmap-xhdpi/ic_launcher_round.png" target="app/src/main/res/mipmap-xhdpi/ic_launcher_round.png" />
    <resource-file src="res/android/mipmap-xhdpi/ic_launcher_foreground.png" target="app/src/main/res/mipmap-xhdpi/ic_launcher_foreground.png" />

    <!-- xhdpi v26-->
    <resource-file src="res/android/mipmap-xhdpi-v26/ic_launcher_foreground.png" target="app/src/main/res/mipmap-xhdpi-v26/ic_launcher_foreground.png" />
    <resource-file src="res/android/mipmap-xhdpi-v26/ic_launcher_background.png" target="app/src/main/res/mipmap-xhdpi-v26/ic_launcher_background.png" />
    <resource-file src="res/android/mipmap-xhdpi-v26/ic_launcher.xml" target="app/src/main/res/mipmap-xhdpi-v26/ic_launcher.xml" />

    <!-- xxhdpi -->
    <resource-file src="res/android/mipmap-xxhdpi/ic_launcher.png" target="app/src/main/res/mipmap-xxhdpi/ic_launcher.png" />
    <resource-file src="res/android/mipmap-xxhdpi/ic_launcher_round.png" target="app/src/main/res/mipmap-xxhdpi/ic_launcher_round.png" />
    <resource-file src="res/android/mipmap-xxhdpi/ic_launcher_foreground.png" target="app/src/main/res/mipmap-xxhdpi/ic_launcher_foreground.png" />

    <!-- xxhdpi v26-->
    <resource-file src="res/android/mipmap-xxhdpi-v26/ic_launcher_foreground.png" target="app/src/main/res/mipmap-xxhdpi-v26/ic_launcher_foreground.png" />
    <resource-file src="res/android/mipmap-xxhdpi-v26/ic_launcher_background.png" target="app/src/main/res/mipmap-xxhdpi-v26/ic_launcher_background.png" />
    <resource-file src="res/android/mipmap-xxhdpi-v26/ic_launcher.xml" target="app/src/main/res/mipmap-xxhdpi-v26/ic_launcher.xml" />

    <!-- xxxhdpi -->
    <resource-file src="res/android/mipmap-xxxhdpi/ic_launcher.png" target="app/src/main/res/mipmap-xxxhdpi/ic_launcher.png" />
    <resource-file src="res/android/mipmap-xxxhdpi/ic_launcher_round.png" target="app/src/main/res/mipmap-xxxhdpi/ic_launcher_round.png" />
    <resource-file src="res/android/mipmap-xxxhdpi/ic_launcher_foreground.png" target="app/src/main/res/mipmap-xxxhdpi/ic_launcher_foreground.png" />

    <!-- xxxhdpi v26-->
    <resource-file src="res/android/mipmap-xxxhdpi-v26/ic_launcher_foreground.png" target="app/src/main/res/mipmap-xxxhdpi-v26/ic_launcher_foreground.png" />
    <resource-file src="res/android/mipmap-xxxhdpi-v26/ic_launcher_background.png" target="app/src/main/res/mipmap-xxxhdpi-v26/ic_launcher_background.png" />
    <resource-file src="res/android/mipmap-xxxhdpi-v26/ic_launcher.xml" target="app/src/main/res/mipmap-xxxhdpi-v26/ic_launcher.xml" />

`

I spent a few days on this... for anyone else who is still having problems getting icons to show up properly and not be cut off.

Import your Cordova project into Android Studio
Click on the 'app' folder in the left pane
In the menu go to File -> New -> Image Asset
Fill out the form with your image and make sure the image is not larger than the offset
Copy the images generated in the Android project folder  platforms\android\app\src\main\res into your res\android
Use the following code in your config.xml platform android section

`

    <resource-file src="res/android/values/ic_launcher_background.xml" target="app/src/main/res/values/ic_launcher_background.xml" />

    <!-- any dpi -->
    <resource-file src="res/android/mipmap-anydpi-v26/ic_launcher.xml" target="app/src/main/res/mipmap-anydpi-v26/ic_launcher.xml" />
    <resource-file src="res/android/mipmap-anydpi-v26/ic_launcher_round.xml" target="app/src/main/res/mipmap-anydpi-v26/ic_launcher_round.xml" />

    <!-- ldpi -->
    <resource-file src="res/android/mipmap-ldpi/ic_launcher.png" target="app/src/main/res/mipmap-ldpi/ic_launcher.png" />

    <!-- ldpi v26-->
    <resource-file src="res/android/mipmap-ldpi-v26/ic_launcher_foreground.png" target="app/src/main/res/mipmap-ldpi-v26/ic_launcher_foreground.png" />
    <resource-file src="res/android/mipmap-ldpi-v26/ic_launcher_background.png" target="app/src/main/res/mipmap-ldpi-v26/ic_launcher_background.png" />
    <resource-file src="res/android/mipmap-ldpi-v26/ic_launcher.xml" target="app/src/main/res/mipmap-ldpi-v26/ic_launcher.xml" />

    <!-- mdpi -->
    <resource-file src="res/android/mipmap-mdpi/ic_launcher.png" target="app/src/main/res/mipmap-mdpi/ic_launcher.png" />
    <resource-file src="res/android/mipmap-mdpi/ic_launcher_round.png" target="app/src/main/res/mipmap-mdpi/ic_launcher_round.png" />
    <resource-file src="res/android/mipmap-mdpi/ic_launcher_foreground.png" target="app/src/main/res/mipmap-mdpi/ic_launcher_foreground.png" />

    <!-- mdpi v26-->
    <resource-file src="res/android/mipmap-mdpi-v26/ic_launcher_foreground.png" target="app/src/main/res/mipmap-mdpi-v26/ic_launcher_foreground.png" />
    <resource-file src="res/android/mipmap-mdpi-v26/ic_launcher_background.png" target="app/src/main/res/mipmap-mdpi-v26/ic_launcher_background.png" />
    <resource-file src="res/android/mipmap-mdpi-v26/ic_launcher.xml" target="app/src/main/res/mipmap-mdpi-v26/ic_launcher.xml" />

    <!-- hdpi -->
    <resource-file src="res/android/mipmap-hdpi/ic_launcher.png" target="app/src/main/res/mipmap-hdpi/ic_launcher.png" />
    <resource-file src="res/android/mipmap-hdpi/ic_launcher_round.png" target="app/src/main/res/mipmap-hdpi/ic_launcher_round.png" />
    <resource-file src="res/android/mipmap-hdpi/ic_launcher_foreground.png" target="app/src/main/res/mipmap-hdpi/ic_launcher_foreground.png" />

    <!-- hdpi v26-->
    <resource-file src="res/android/mipmap-hdpi-v26/ic_launcher_foreground.png" target="app/src/main/res/mipmap-hdpi-v26/ic_launcher_foreground.png" />
    <resource-file src="res/android/mipmap-hdpi-v26/ic_launcher_background.png" target="app/src/main/res/mipmap-hdpi-v26/ic_launcher_background.png" />
    <resource-file src="res/android/mipmap-hdpi-v26/ic_launcher.xml" target="app/src/main/res/mipmap-hdpi-v26/ic_launcher.xml" />

    <!-- xhdpi -->
    <resource-file src="res/android/mipmap-xhdpi/ic_launcher.png" target="app/src/main/res/mipmap-xhdpi/ic_launcher.png" />
    <resource-file src="res/android/mipmap-xhdpi/ic_launcher_round.png" target="app/src/main/res/mipmap-xhdpi/ic_launcher_round.png" />
    <resource-file src="res/android/mipmap-xhdpi/ic_launcher_foreground.png" target="app/src/main/res/mipmap-xhdpi/ic_launcher_foreground.png" />

    <!-- xhdpi v26-->
    <resource-file src="res/android/mipmap-xhdpi-v26/ic_launcher_foreground.png" target="app/src/main/res/mipmap-xhdpi-v26/ic_launcher_foreground.png" />
    <resource-file src="res/android/mipmap-xhdpi-v26/ic_launcher_background.png" target="app/src/main/res/mipmap-xhdpi-v26/ic_launcher_background.png" />
    <resource-file src="res/android/mipmap-xhdpi-v26/ic_launcher.xml" target="app/src/main/res/mipmap-xhdpi-v26/ic_launcher.xml" />

    <!-- xxhdpi -->
    <resource-file src="res/android/mipmap-xxhdpi/ic_launcher.png" target="app/src/main/res/mipmap-xxhdpi/ic_launcher.png" />
    <resource-file src="res/android/mipmap-xxhdpi/ic_launcher_round.png" target="app/src/main/res/mipmap-xxhdpi/ic_launcher_round.png" />
    <resource-file src="res/android/mipmap-xxhdpi/ic_launcher_foreground.png" target="app/src/main/res/mipmap-xxhdpi/ic_launcher_foreground.png" />

    <!-- xxhdpi v26-->
    <resource-file src="res/android/mipmap-xxhdpi-v26/ic_launcher_foreground.png" target="app/src/main/res/mipmap-xxhdpi-v26/ic_launcher_foreground.png" />
    <resource-file src="res/android/mipmap-xxhdpi-v26/ic_launcher_background.png" target="app/src/main/res/mipmap-xxhdpi-v26/ic_launcher_background.png" />
    <resource-file src="res/android/mipmap-xxhdpi-v26/ic_launcher.xml" target="app/src/main/res/mipmap-xxhdpi-v26/ic_launcher.xml" />

    <!-- xxxhdpi -->
    <resource-file src="res/android/mipmap-xxxhdpi/ic_launcher.png" target="app/src/main/res/mipmap-xxxhdpi/ic_launcher.png" />
    <resource-file src="res/android/mipmap-xxxhdpi/ic_launcher_round.png" target="app/src/main/res/mipmap-xxxhdpi/ic_launcher_round.png" />
    <resource-file src="res/android/mipmap-xxxhdpi/ic_launcher_foreground.png" target="app/src/main/res/mipmap-xxxhdpi/ic_launcher_foreground.png" />

    <!-- xxxhdpi v26-->
    <resource-file src="res/android/mipmap-xxxhdpi-v26/ic_launcher_foreground.png" target="app/src/main/res/mipmap-xxxhdpi-v26/ic_launcher_foreground.png" />
    <resource-file src="res/android/mipmap-xxxhdpi-v26/ic_launcher_background.png" target="app/src/main/res/mipmap-xxxhdpi-v26/ic_launcher_background.png" />
    <resource-file src="res/android/mipmap-xxxhdpi-v26/ic_launcher.xml" target="app/src/main/res/mipmap-xxxhdpi-v26/ic_launcher.xml" />

`

@nomaam, I can not find the 'Image Asset' option did you do anything special when importing the project?

Nevermind I found it, I import the android folder within the Cordova Project, which enables the Android View.


Can you upload to CocoaPods please?

Hi @konotori,
YouTubePlayerKit can be easily added via the Swift Package Manager or manually by dragging the Sources folder into your project.


ansible on localhost - Additional properties are not allowed ('pipelining', 'ssh_args' were unexpected)

root@linux:~/.ansible/roles/podman# molecule converge -s default
CRITICAL Failed to validate /root/.ansible/roles/podman/molecule/default/molecule.yml

["Additional properties are not allowed ('pipelining', 'ssh_args' were unexpected)"]

The workaround is to delete three lines starting from https://github.com/alvistack/ansible-role-podman/blob/master/molecule/default/molecule.yml#L44

Please refer https://github.com/alvistack/ansible-role-podman/issues/13#issuecomment-1302965418 for some detail setup.
Moreover, these config is passing with our GitLab CI (see https://gitlab.com/alvistack/ansible-role-podman/-/jobs/3187525820), so it is most likely related to different setup ;-)


Update avro4s-core to 5.0.5

About this PR
📦 Updates com.sksamuel.avro4s:avro4s-core from 5.0.0.M1 to 5.0.5
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.sksamuel.avro4s", artifactId = "avro4s-core" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "com.sksamuel.avro4s", artifactId = "avro4s-core" }
}]

labels: library-update, commit-count:1

Superseded by #196.


[ISSUE] Upgrade to camunda 8.1.6 has issue with optimize

Describe the issue:
When I upgraded from 8.1.2 to 8.1.6, I cannot browse to optimize anymore. Logs from optimize are filled with:
Logs:
Caused by: org.camunda.optimize.service.exceptions.OptimizeRuntimeException: The Elasticsearch Optimize schema version [3.9.1] doesn't match the current Optimize version [3.9.3]. Please make sure to run the Upgrade first.
Environment:

Platform: AWS
Chart version: 8.1.6
Values file:

operate:
  service:
    type: NodePort
identity:
  service:
    type: NodePort
  keycloak:
    service:
      type: NodePort
    extraEnvVars:
      - name: KEYCLOAK_PROXY_ADDRESS_FORWARDING
        value: "true"
      - name: KEYCLOAK_FRONTEND_URL
        value: "https://keycloak.example.com"
  env:
    - name: IDENTITY_URL
      value: "https://identity.example.com"
tasklist:
  service:
    type: NodePort
optimize:
  service:
    type: NodePort
zeebe-gateway:
  service:
    type: NodePort
global:
  identity:
    auth:
      publicIssuerUrl: "https://keycloak.example.com/auth/realms/camunda-platform"
      operate:
        redirectUrl: "https://operate.example.com"
      tasklist:
        redirectUrl: "https://tasklist.example.com"
      optimize:
        redirectUrl: "https://optimize.example.com"

@hoangduy1912 Is that issue still happening with the latest 8.1 version?

Closing this since Camunda 8.1 reached EOL.


Security support

Inspired by https://github.com/timber/timber/issues/2936
Timber is missing dealing with security. I propose to:

add "how to disclose vulnerabilities" - they shouldn't be public at first
using https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/creating-a-repository-security-advisory
adding docs regarding handling security

Thank you for your response, I have followed the steps you outlined. However, regarding the vulnerability report in the issue section, I couldn't find a place to delete it

I deleted the issue. Let’s continue working on the issue in the private security advisory.


[Usage]: Cant use vllm on a multiGPU node

Your current environment
collect_env.txt
How would you like to use vllm
model: meta-llama/Llama3-8B-Instruct
quantization: none
tensor_parallel_size: 2
GPUs: 2xA30
vllm: 0.6.4.post1v (also tried with 0.5.4 and 0.5.0)
strongly related to this issue: https://github.com/vllm-project/vllm/issues/6152
Can't run the script for multi GPUs (it works for a single GPU). Teh following error occurs:
(VllmWorkerProcess pid=13824) ERROR 11-20 12:20:01 multiproc_worker_utils.py:226] RuntimeError: Cannot re-initialize CUDA in forked subprocess. To use CUDA with multiprocessing, you must use the 'spawn' start method
I tried to set env variavle to "spawn" or use the latest vllm version:
os.environ["VLLM_WORKER_MULTIPROC_METHOD"]="spawn"
The problems is that the calling script runs the script again as a child process , but this is not the desired behavior. And as expected, the following error is thrown:
================================================================================
RuntimeError:
An attempt has been made to start a new process before the
current process has finished its bootstrapping phase.
    This probably means that you are not using fork to start your
    child processes and you have forgotten to use the proper idiom
    in the main module:

        if __name__ == '__main__':
            freeze_support()
            ...

    The "freeze_support()" line can be omitted if the program
    is not going to be frozen to produce an executable.

================================================================================
The code that loads the llm is
llm = LLM(model=model_path, device="auto", dtype="auto", max_model_len=8192, gpu_memory_utilization=GMU, tensor_parallel_size=gpu_units)

and for inference
sampling_params = SamplingParams(temperature=temperature, max_tokens=max_new_tokens, top_p=0.95)
results = model.generate(prompt , sampling_params)

More info:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
INFO 11-20 13:28:39 llm_engine.py:249] Initializing an LLM engine (v0.6.4.post1) with config: model='models/meta-llama/Meta-Llama-3.1-8B-Instruct', speculative_config=None, tokenizer='models/meta-llama/Meta-Llama-3.1-8B-Instruct', skip_tokenizer_init=False, tokenizer_mode=auto, revision=None, override_neuron_config=None, tokenizer_revision=None, trust_remote_code=False, dtype=torch.bfloat16, max_seq_len=8192, download_dir=None, load_format=LoadFormat.AUTO, tensor_parallel_size=2, pipeline_parallel_size=1, disable_custom_all_reduce=False, quantization=None, enforce_eager=False, kv_cache_dtype=auto, quantization_param_path=None, device_config=cuda, decoding_config=DecodingConfig(guided_decoding_backend='outlines'), observability_config=ObservabilityConfig(otlp_traces_endpoint=None, collect_model_forward_time=False, collect_model_execute_time=False), seed=0, served_model_name=models/meta-llama/Meta-Llama-3.1-8B-Instruct, num_scheduler_steps=1, chunked_prefill_enabled=False multi_step_stream_outputs=True, enable_prefix_caching=False, use_async_output_proc=True, use_cached_outputs=False, chat_template_text_format=string, mm_processor_kwargs=None, pooler_config=None)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Same issue exists on different GPUs (V100). What is the problem here?
I attach the results of collect_env.py script.
Before submitting a new issue...

[X] Make sure you already searched for relevant issues, and asked the chatbot living at the bottom right corner of the documentation page, which can answer lots of frequently asked questions.

I have the same question

same question. I run vllm on 2A100. By the way, 23090 all ok.

Ao, look this: https://github.com/vllm-project/vllm/issues/10800
Error code:
major, minor = torch.cuda.get_device_capability('cuda:0')
dtype = torch.float16
if major >= 8:
    dtype=torch.bfloat16

just remove this code block.
May mainly because: torch.cuda.get_device_capability('cuda:0'), which call _cuda_init() ????
interesting


Timex 3 support

Timex 3 is the latest major version, so Verk should probably support that. Opening this ticket to track that support.

Would dropping Timex in favor of standard Elixir/Erlang times be something to consider if it's a breaking change anyway?

I think its worth considering, though its not just a matter of the date/time structs, which AFAIK is primarily what elixir standardized in 1.3. Timex also adds niceties for dealing with things like durations and timezones that can still be a PITA with the stock functions.  That said, I think the primary use of datetimes in Verk is to mark when jobs were enqueued and whether enough time has passed, which can probably done with the standard library functions.

Reviewing the usages of Timex, the primary utility is to get the current unix time, which can easily be replaced by standard lib. There are a couple of ancilliary uses of Timex.shift and Timex.compare which could be abstracted away if maintainers feel like dropping the dependency is worthwhile. My 2 cents is to be generally in favor of killing dependencies when the utility of them is shallow, as I think it is in this case.

Thanks @mitchellhenke and @karmajunkie. I would be keen to move to ~> 1.3 and remove Timex from our dependencies. What do you folks think?
@karmajunkie, would you be interested in creating a PR? I can definitely work on this till the end of the week (2-3 days from now).
Seems legit?
Then I will just need to update Verk Web to either work with Timex 3 or use standard Elixir :)

Not part of this work but I will also use this moment to move to Poison 2 and remove this code https://github.com/edgurgel/verk/blob/master/lib/verk/poison_version.ex

@edgurgel i've got it mostly done now, but having a hard time figuring out how to get meck to work. Its not a library I've used before, and in general I try to avoid that kind of mocking so not sure what needs to change to get those tests passing. I'm sure I've made worse whatever my original testing issue was, but maybe you can take a look at it and see. I'll try to get the work I did today to remove Timex pushed up tonight or tomorrow morning on #79.

That sounds super to me
On Mon, Sep 19, 2016 at 10:51 PM Eduardo Gurgel<EMAIL_ADDRESS>wrote:

Not part of this work but I will also use this moment to move to Poison 2
and remove this code
https://github.com/edgurgel/verk/blob/master/lib/verk/poison_version.ex
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/edgurgel/verk/issues/78#issuecomment-248194510, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABXTq0_abD2o9ID0C_hbmj4v4kqrZ5V0ks5qr1hXgaJpZM4KApGn
.

Cool I will take a look at this today! Thank you again for starting this :)

Closing this as #79 was merged in, resolving the issue

Awesome! I will update Poison and others libs then release a new major version! Thanks again :)

Verk 0.13.0 is out https://github.com/edgurgel/verk/releases/tag/v0.13.0 https://hex.pm/packages/verk/0.13.0
Thanks!


Firestore-stripe-payments - Duplicate Customers

Bug report

Extension name: [e.g. firestore-stripe-payments]

Describe the bug
Every time a customer creates an account within my chrome extension, then buys a subscription via Stripe Payment Links, two customers are created within the Stripe portal (I have confirmed with Stripe that this is an issue with the Firestore-Stripe-Payments extension as they checked on their side). When the customer's account is duplicated two times in Stripe, one of the accounts is blank except for the email field and the other is filled with the customer's name and payment information. The Stripe customer's name and Customer ID does not match with the one in Firestore AND Firestore doesn't even create a "Subscription" collection with the Customer's Document.
To Reproduce

Download the Chrome Extension at https://theminutejournal.com/
Create an account in the Minute Journal
Click "Start Day" upon New Tab
Buy a Stripe subscription (Monthly or Annually)
Confirm payment success
Close Chrome
Reopen or create a new tab to use the Minute Journal
Click "Start Day" (same as step 3)
You will be brought to the pricing plans again
Once you have done the steps above, I can confirm the duplicate customer within Stripe.

Expected behavior
Users should have a Subscription Collection within their Firestore Document that confirms they are a paying customer and should be able to access the Minute Journal's features. Furthermore, there should only be one Customer within Stripe created.
Screenshots
Duplicate Customers within Stripe:

How it should look or behave via Firestore:

How it looks currently via Firestore:

System information

macOS
Google Chrome

Additional context
THIS IS URGENT AS I AM LOSING PAYING CUSTOMERS!

HI @tlorenz34 @Spitzbua.
Can you provide any logs from the extension function. This can be accessed through by:

Navigate to the Extensions Dashboard
Select the Stripe Payments  Installation
Choose Apis and resources
Select the payments function logs

Additionally, could you confirm that you only have one instance of the extension installed to confirm this isn't an issue caused by multiple instances.

With Stripe allowing multiple customers with the same email address, could suggest this is created upon a new checkout session. Although this bug doesn't seem obvious in the extension.
If you navigate to both users and select Events and Logs, could you provide information on how each customer was created for debugging purposes?
https://dashboard.stripe.com/test/customers/{Stripe_Customer_ID}

Payment Links/Checkout will by default create a new Customer object if no customer parameter is provided on session creation:

If blank for Checkout Sessions in payment or subscription mode, Checkout will create a new Customer object based on information provided during the payment flow.

Based on the limited information above, I expect that your integration is creating multiple Checkout Session objects simultaneously.

I had the same problem, every 1-3 out of 100 payments creates a duplicate account in Stripe and links the wrong Stripe customer to the Firestore user.
In the error cases, I create a user and then directly run a checkout session. However, the createCustomer event happens too closely to the checkout session createCheckoutSession. In most cases it works fine, but when createCustomer takes too long, createCheckoutSession also creates a customer. See below:
if (!customerRecord?.stripeId) {
        const { email, phoneNumber } = await admin
          .auth()
          .getUser(context.params.uid);
        customerRecord = await createCustomerRecord({
          uid: context.params.uid,
          email,
          phone: phoneNumber,
        });
    }

Based on the logs, I assume this was my problem. I'll either add a delay or wait for the Firestore update before creating the checkout session.
Suggestions:

I assume account creation followed by checkout is a common behaviour for websites with subscriptions, and it would be good to communicate this edge case.
In my case, I'd prefer createCheckoutSession to wait for the stripeId update, instead of creating a new customer. But this is probably not best for all use cases.


Im not able to join matches?

Im not able to join matches with the cheat injected? I know that its bannable i don't care about that. What can i change for the build to able to be used in cs2? and my launch options is empty.

because loadlib call and the game detected non-authorized dll, u have to find a way to bypass this, ex manual map(read premake5.lua)


add zalo services

Zalo is most popular chat app in Vietnam. Hope you guys can put this chat app in Franz

@adlk Please review it


Cash karp ckrk

Summary
This PR address #2334 by adding Cash-Karp integrator function ode_ckrk & ode_ckrk_tol, following existing naming pattern. The new integrator is shown in #2334 to be able to improve numerical ode solution performance to problems that could become semi stiff under certain parameter samples.
Tests
./rev/functor/ode_ckrk_tol_rev_test.cpp
./rev/functor/ode_ckrk_grad_test.cpp
./rev/functor/ode_ckrk_rev_test.cpp
./prim/functor/ode_ckrk_prim_test.cpp
./prim/functor/ode_ckrk_tol_prim_test.cpp

Side Effects
n/a
Release notes
Adding Cash-Karp numerical integrator to improve numerical integration of ODEs with semi-stiffness and/or rapid oscillations.
Checklist

[x] Math issue #2334

[x] Copyright holder: (fill in copyright holder information)
The copyright holder is Metrum Research Group. By submitting this pull request, the copyright holder is agreeing to the license the submitted work under the following licenses:
- Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)
- Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

[x] the basic tests are passing

unit tests pass (to run, use: ./runTests.py test/unit)
header checks pass, (make test-headers)
dependencies checks pass, (make test-math-dependencies)
docs build, (make doxygen)
code passes the built in C++ standards checks (make cpplint)

[x] the code is written in idiomatic C++ and changes are documented in the doxygen

[x] the new changes are tested

The new integrator is shown in #2334 to be able to improve numerical ode solution performance

I think the merge conditions on this are the same as the vector absolute tolerances thing.
It is good we have more options cause then people can solve more problems.
But we really need a guide to use ODEs that makes it obvious the steps of picking one thing or another (and presumably the need for this solver will be justified by that process):

If you know nothing else about your problem, pick Cash Karp
If you know X about your problem (or can test it with this technique), switch to RK45
If you aren't sure about stiffness, profile between RK45, BDF, and Adams, ...

Maybe the first step of any ODE inference problem is simulated data or something, or prior-only simulations, or something like this.

The new integrator is shown in #2334 to be able to improve numerical ode solution performance

I think the merge conditions on this are the same as the vector absolute tolerances thing.
It is good we have more options cause then people can solve more problems.
But we really need a guide to use ODEs that makes it obvious the steps of picking one thing or another (and presumably the need for this solver will be justified by that process):

If you know nothing else about your problem, pick Cash Karp
If you know X about your problem (or can test it with this technique), switch to RK45
If you aren't sure about stiffness, profile between RK45, BDF, and Adams, ...

Maybe the first step of any ODE inference problem is simulated data or something, or prior-only simulations, or something like this.

But we really need a guide to use ODEs that makes it obvious the steps of picking one thing or another (and presumably the need for this solver will be justified by that process):

@bbbales2 without knowing anything, I'd say choose rk45. All other choices should be chosen based on some knowledge of the system. Among the three models in #2334, SIR & Van del Pol oscillator are known to become stiff in certain occasion, and predator-prey is usually considered non-stiff. Which one to choose is also tied to how parameters are sampled, as you pointed out. I'd say this "which one to choose" is more complicated than vector atol issue.

But we really need a guide to use ODEs that makes it obvious the steps of picking one thing or another (and presumably the need for this solver will be justified by that process):

@bbbales2 without knowing anything, I'd say choose rk45. All other choices should be chosen based on some knowledge of the system. Among the three models in #2334, SIR & Van del Pol oscillator are known to become stiff in certain occasion, and predator-prey is usually considered non-stiff. Which one to choose is also tied to how parameters are sampled, as you pointed out. I'd say this "which one to choose" is more complicated than vector atol issue.

We should probably come up with a template based on profiling. We can make the bdf solver the one driving the inference, but let all the others also return the solutions. Each solver is run in its own profile block and then we will know quickly with a few samples which one wins during the wild warmup phase... and that‘s your solver most likely (a „data“ driven approach).

We should probably come up with a template based on profiling. We can make the bdf solver the one driving the inference, but let all the others also return the solutions. Each solver is run in its own profile block and then we will know quickly with a few samples which one wins during the wild warmup phase... and that‘s your solver most likely (a „data“ driven approach).

The reason is that whenever a solver throws we then wont get the result of the others...

Yeah good point. And maybe with this in mind running the ODE with priors only in the generated quantities block is step 1.
Once everything is running, move to the model block and that will mean that the sensitivity equations get added (and maybe everything gets changed).
It sounds really primitive and like a lot of work but guess and check moving between solvers will be a lot of work too.

The reason is that whenever a solver throws we then wont get the result of the others...

Yeah good point. And maybe with this in mind running the ODE with priors only in the generated quantities block is step 1.
Once everything is running, move to the model block and that will mean that the sensitivity equations get added (and maybe everything gets changed).
It sounds really primitive and like a lot of work but guess and check moving between solvers will be a lot of work too.

The "data-based" approach might be tricky when we don't know winning criteria: faster is not necessarily better. If rk45 can be faster by failing early throwing out nan of inf results but it could miss samples that matters. In general testing the solver in different blocks & with tentative prior makes more sense to me.

The "data-based" approach might be tricky when we don't know winning criteria: faster is not necessarily better. If rk45 can be faster by failing early throwing out nan of inf results but it could miss samples that matters. In general testing the solver in different blocks & with tentative prior makes more sense to me.

In general testing the solver in different blocks & with tentative prior makes more sense to me.

Yeah if we can get the ODE 20 questions written down it'll make it a lot easier to add complexity.

In general testing the solver in different blocks & with tentative prior makes more sense to me.

Yeah if we can get the ODE 20 questions written down it'll make it a lot easier to add complexity.

@bbbales2 do we want to continue the discussion or move on to reviewing? I'm fine either way.

@bbbales2 do we want to continue the discussion or move on to reviewing? I'm fine either way.

Can we do the docs? If we have text that makes it easy to pick between the six solvers we have, that'll make everything much easier to understand.
Then when it comes to justifying this, it's just adding if statements to the doc that tell someone how to pick it. And if it comes down to profiling rk45 vs. ckrk on every problem, that's okay.
As far as code, we should try to do a little work to compress all the ODE tests -- there's a ton of them now and it could probably be a little more maintainable. But that can wait.

Can we do the docs? If we have text that makes it easy to pick between the six solvers we have, that'll make everything much easier to understand.
Then when it comes to justifying this, it's just adding if statements to the doc that tell someone how to pick it. And if it comes down to profiling rk45 vs. ckrk on every problem, that's okay.
As far as code, we should try to do a little work to compress all the ODE tests -- there's a ton of them now and it could probably be a little more maintainable. But that can wait.

Can we do the docs? If we have text that makes it easy to pick between the six solvers we have, that'll make everything much easier to understand.

I agree we can work on docs first but I'm not sure how to come up a guideline without scope creeping. Choosing integrator requires some understanding of the problems just under deterministic context, and in Stan context the topic becomes even  fuzzier.

As far as code, we should try to do a little work to compress all the ODE tests -- there's a ton of them now and it could probably be a little more maintainable. But that can wait.

I've started doing this in this PR by consolidating finite diff test so one can apply it to multiple ODE system & integrators relatively easily(it's used to test ckrk on two systems). The work can continue after this.

Can we do the docs? If we have text that makes it easy to pick between the six solvers we have, that'll make everything much easier to understand.

I agree we can work on docs first but I'm not sure how to come up a guideline without scope creeping. Choosing integrator requires some understanding of the problems just under deterministic context, and in Stan context the topic becomes even  fuzzier.

As far as code, we should try to do a little work to compress all the ODE tests -- there's a ton of them now and it could probably be a little more maintainable. But that can wait.

I've started doing this in this PR by consolidating finite diff test so one can apply it to multiple ODE system & integrators relatively easily(it's used to test ckrk on two systems). The work can continue after this.

without scope creeping

Well we have 6 integrator functions, two of which are kinda speculative (the adams solvers). Including the two functions here and the adjoint ODE function, we're looking down the barrel of 9 ODE functions. So I think we're scope creeping already on the coding front and the docs need to catch up.
We need to be justifying these things cause they are not simple. I forget the differences in all these functions all the time, and I've written a fair share of the code (and dug in basically all of it). The most important thing we can do for current and future devs and users is explain the role of each of the solvers and why they are here. Looking at #2334 my thought is we should be deprecating rk45 and rolling with this (even with https://github.com/stan-dev/math/pull/2336#issuecomment-768552368 -- what isn't stiff occasionally? -- ckrk seems more robust if this is the case). I kinda feel the same about the adams solver too.
Our current docs are assuming that people come to Stan knowing a lot about their differential equations and how to solve them. I don't really believe this. People come to Stan with their ODEs because they want to do their science thing, and in the process they end up having to learn about solving their ODEs. We gotta explain how to use the functionality in Stan to learn about solving their ODEs.

in Stan context the topic becomes even fuzzier.

Yeah, and this is why more docs are important.
Compare the current ODE landing page: https://mc-stan.org/docs/2_26/stan-users-guide/ode-solver-chapter.html
To section 3.5: https://mc-stan.org/docs/2_26/stan-users-guide/stiff-ode-section.html
Section 3.5 has really useful stuff like:

Stiffness is a numerical phenomena that causes some differential equation solvers difficulty ... The phenomena is common in chemical reaction systems
If it is not known for sure that an ODE system is stiff, run the model with both the rk45 and bdf solvers and see which is faster.

Here's some things in general:

How to interpret chains not mixing
How to pick between rk45/ckrk/adams/bdf
How to know when to change max_num_steps
How to know when to change tolerances
Higher tolerances are not always slower (very surprising!)
How to handle solutions that go near zero
Scalability of sensitivity equations
Why sometimes people end up writing trapazoid method

I would rather review stuff like this than add more ODE code honestly.

I would rather review stuff like this

To clarify, to review this I have to figure out how this function fits in the big picture of everything ODEs, and I'd rather have that written down somewhere then just inevitably forgetting it a week from now.

Our current docs are assuming that people come to Stan knowing a lot about their differential equations and how to solve them. I don't really believe this. People come to Stan with their ODEs because they want to do their science thing, and in the process they end up having to learn about solving their ODEs. We gotta explain how to use the functionality in Stan to learn about solving their ODEs.

Hmm... I don't mind the perspective that Stan is a thing solving science problems. It's just that ODEs are tricky and we can't take that away from the user. So a user needs to understand something about ODEs is what I would think is reasonable here. That is not to say we should not document anything nor guide anything here. It's just that we cannot solve someones problem without having seen it. Still, a big picture thing doc makes sense as long as we still say that specifics can overrule the big picture thing possibly (and some things will remain empirical - meaning "you need to try").
@yizhang-yiz I was applying this solver to the linked mass toy example from the adjoint solver branch. This system is non-stiff, but can easily become stiff if wild parameters are being sampled - at least that was my intention here. It turns out that RK45 and ckrk basically do the same in terms of speed and result while bdf blows them away with a 2x faster inference time. From this example it looks as if ckrk is not adding any value here.
I think it would be nice to find an end-to-end example where ckrk is the clear choice. The argument that the solver is better for mildly stiff problems is a good one, but ideally we also demonstrate that in an example. At least this is what I would think would be good here. It's just that we want to avoid unnecessary feature creep here.
Like I said before, from my intuition this solver should show benefits as it can survive mild stiffness, but it would still be very convincing to see an actual model run significantly better (faster/more stable/whatever metric is adequate).
My intuition for the big picture guide would be: Use a non-stiff solver if it's not stiff - if that is not known, then just try bdf and RK45. In case mild stiffness is something which can occur for a non-stiff problem (as it happens with wide priors), then ckrk is a possible alternative to RK45. Adding ckrk to the picture here adds complexity which we should justify by observing it's advantages end-to-end.

Oh on the docs front, I was talking to @charlesm93 today and I told him I'd try to start writing some of this stuff down later today. He's interested in workflow stuff. It's kinda unfair for me to ask Yi to read my mind on this -- maybe if I get some example text written it'll be clearer.

Use a non-stiff solver if it's not stiff - if that is not known, then just try bdf and RK45

This is the vague template lol.

This is the vague template lol.

Well, finding out emprically is the simplest way. Of course, we should write about stiff is "involves multiple length/time-scales", but this is where it often ends up being useful to me. It's really about bdf takes 5s and RK45 10s for some toy setup... problem solved! At least this is how I see it. Given that function signatures are anyway basically the same it is easy to try that out quickly.

@bbbales2

So I think we're scope creeping already on the coding front and the docs need to catch up.

By scope creep I didn't mean getting more & more integrator but initiate a large benchmark & research project from documentation. There are a lot of things conflated here. Specifically

How to interpret chains not mixing

This is not just an ODE issue, why should it be discussed here?

How to pick between rk45/ckrk/adams/bdf

In deterministic context, this is not too hard to answer. In sampling context, I don' know any guideline that is backup up by large-scale benchmark and/or credible literature. There's a lot of work to do before we can say anything in our doc. This is what I mean when saying scope creep.

How to know when to change max_num_steps

This is problem dependent.

How to know when to change tolerances

This is addressed in my previous doc PR.

Scalability of sensitivity equations

I don't understand what this means.

Why sometimes people end up writing trapazoid method

Is this even a doc issue?
So from your list I can only see the question of "How to pick between rk45/ckrk/adams/bdf" becomes harder to answer when is ckrk is added, which is the focus of our previous discussion. Some from that list may not even be a doc issue.
@wds15

Hmm... I don't mind the perspective that Stan is a thing solving science problems. It's just that ODEs are tricky and we can't take that away from the user. So a user needs to understand something about ODEs is what I would think is reasonable here. That is not to say we should not document anything nor guide anything here. It's just that we cannot solve someones problem without having seen it.

Exactly.

I think it would be nice to find an end-to-end example where ckrk is the clear choice. The argument that the solver is better for mildly stiff problems is a good one, but ideally we also demonstrate that in an example. At least this is what I would think would be good here. It's just that we want to avoid unnecessary feature creep here.

In general it's not too hard to come up a non-stiff model that explicit method(like ckrk) could outperform implicit(like bdf), as if the system dimension is large enough BDF's advantage of stepsize can be eaten by nonlinear iteration. For example we can continue the lotka-volterra where ckrk is shown could be better than rk45, here's a modified "enlarged" version(in the original version they perform similarly).
functions {
  real[] dz_dt(real t,       // time
               real[] z,     // system state {prey, predator}
               real[] theta, // parameters
               real[] x_r,   // unused data
               int[] x_i) {
    real u = z[1];
    real v = z[2];

    real alpha = theta[1];
    real beta = theta[2];
    real gamma = theta[3];
    real delta = theta[4];

    real du_dt = (alpha - beta * v) * u;
    real dv_dt = (-gamma + delta * u) * v;

    return { du_dt, dv_dt,
                 du_dt, dv_dt,
                 du_dt, dv_dt,
                 du_dt, dv_dt,
                 du_dt, dv_dt };
  }
}
data {
  real rtol;
  real atol;
  int<lower = 0> N;          // number of measurement times
  real ts[N];                // measurement times > 0
  real y_init[2];            // initial measured populations
  real<lower = 0> y[N, 2];   // measured populations
}
parameters {
  real<lower = 0> theta[4];   // { alpha, beta, gamma, delta }
  real<lower = 0> z_init[2];  // initial population
  real<lower = 0> sigma[2];   // measurement errors
}
transformed parameters {
  real z[N, 10];
  real z_init_max[10];
  for (i in 1:5) {
  z_init_max[(i-1) * 2 + 1] = z_init[1];
  z_init_max[(i-1) * 2 + 2] = z_init[2];
}
    z = integrate_ode_xxx(dz_dt, z_init_max, 0, ts, theta, //ckrk surrogate
                          rep_array(0.0, 0), rep_array(0, 0),
                          rtol, atol, 5e2);
}
model {
  theta[{1, 3}] ~ normal(1, 0.5);
  theta[{2, 4}] ~ normal(0.05, 0.05);
  sigma ~ lognormal(-1, 1);
  z_init ~ lognormal(log(10), 1);
  for (k in 1:2) {
    y_init[k] ~ lognormal(log(z_init[k]), sigma[k]);
    y[ , k] ~ lognormal(log(z[, k]), sigma[k]);
  }
}

ckrk:
Chain 1 finished in 323.5 seconds.

bdf:
Chain 1 finished in 385.6 seconds.

And how does rk45 do here?

And how does rk45 do here?

See linked issue. Specifically,
https://user-images.githubusercontent.com/33104304/105651750-8bced900-5e6c-11eb-9608-5523d2e9d575.png

Alright I started trying to write docs: https://github.com/stan-dev/docs/pull/333
I tried to start answering the questions you brought up there. We need to get this stuff written down. I feel like there's a ton of text about picking tolerances and performance of ODEs and stuff from that last thread.

@bbbales2
Now I'm confused. We do have an ongoing discussion of how to pick integrators among rk45/adams/bdf and possible ckrk. But I don't think I've brought up discussion of things like max step & tolerance etc. In addition, isn't picking tolerance addressed in https://github.com/stan-dev/docs/pull/311 , reviewed by you?

Want to do a hangouts? I'm free other than 1:30 to 3 EST tomorrow.
#311 was an improvement, but there are other things I think we know something about:

When should a user consider changing the defaults?
Should a user pick the solver first or the tolerances first?
What happens when max_num_steps is exceeded (https://github.com/stan-dev/docs/issues/283)?

There was discussion of something like scales of noise or something in the last thread, and also lots of discussion about the not-simple relationship between tolerance and how long it takes a solve to run.

how to pick integrators among rk45/adams/bdf and possible ckrk

Yeah this is good. I didn't get that far in the writeup. Feel free to add. I believe what we have discussed so far is:

Start with rk45
If that is slow, try BDF

I don't know when to go to Adams, or how to know if rk45 is slow other than just running rk45 and BDF together and seeing with profile like Sebastian said (https://github.com/stan-dev/math/pull/2336#issuecomment-771962398). And if that is the only reliable way, that is what we should recommend.

Want to do a hangouts? I'm free other than 1:30 to 3 EST tomorrow.

How about 9 PST(noon EST)?
Now I see by "last thread" you probably mean #2244, which mostly focuses on the intended use of tolerance. I don't see how that's related to adding new integrator here. IMO the current thread is just about: a) does ckrk bring any benefit? and b) how do we help user choose it?

How about 9 PST(noon EST)?

That works. I sent a link.

I don't see how that's related to adding new integrator here.

At what point does the user switch from worrying about solvers to worrying about tolerances? Or are the tolerances first?

At what point does the user switch from worrying about solvers to worrying about tolerances? Or are the tolerances first?

I think tolerances should be driven by what your problem needs. It's an independent choice of the solver in my view. It is determined by what you measure and what accuracy you need your solution. The somewhat more complicated question is what HMC needs as a precision to do it's job. This probably translates into leaning on the somewhat conservative side with tolerances.

@rok-cesnovar any idea why it didn't pass "lub_constrain_test.cpp" test?

I know why it failed: the mix tests can sometimes be too much for g++ 4.9.3, especially with all new stuff added like varmat and they sometimes need to be split in two or more files. I know, lol, but that mingw g++ 4.9.3 for you. Hopefully we will stop supporting it in a few months.
I am less sure why it failed here and not when it was added, its probably right at the limit of 4.9.3 and you were a bit unclucky: https://github.com/stan-dev/math/blob/develop/test/unit/math/mix/fun/lub_constrain_test.cpp
So dont worry, will make a PR to split it and you can just merge it in. You could try restarting the tests, maybe you get luckier.

You could try restarting the tests, maybe you get luckier.

I merged develop before started another test. So this is strike No. 2. I think I'd wait.

@yizhang-yiz merge develop in and you should be good. Sorry for the inconvenience.

@rok-cesnovar thanks, but looks like the compiler is still complaining.

Ah man, sorry. A do-over then, yay :)

@rok-cesnovar No worries. Just wondering, if by "stopping supporting it" you mean moving to RTools 4.0 on windows, what will be the hurdle for doing it now?

Yes, moving to RTools 4.0.
The hurdle is essentially RStan, cause it still has to build with R 3.6 on CRAN (and for CRAN 3.6 windows tests they use RTools 3.5 obviously). It has to build until R 4.1 is release because at that point R-oldrel (the old release CRAN also tests with) will be 4.0.x and R-release will be 4.1.0. Right now R-release is 4.0.4 and R-oldrel is 3.6.X.
I am fairly confident this will happen before 2.27 is on CRAN (we still havent published 2.26), which would mean we can just do it now. But no guarantees (they dont really have a fixed schedule).
We could also just decide rstan 2.27 will wait for 4.1.0 as a backup though. I would be very happy to do that. This is very annoying and frustrating. Rtools 3.5 just want built for this.

Our jenkins tests for Windows are already all on RTools 4.0, we just have this one on Github Actions on 3.5.

@rok-cesnovar is it that the test/unit/math/mix/fun/lub_constrain_3_test.cpp just needs broken up more?

If so I'll open pull

@bbbales2 I think it died on the 1st test:
https://github.com/stan-dev/math/pull/2336/checks?check_run_id=1954379971#step:10:1849

@rok-cesnovar is it that the test/unit/math/mix/fun/lub_constrain_3_test.cpp just needs broken up more?

I think the first one need to be split a bit more. I should have run a few more tests not do a victory lap the first time it passed. I split in in two parts and then had to split the 2nd file further. Seems we need to do the same for the 1st one.

I made a pull here: https://github.com/stan-dev/math/pull/2386

I don't know why this is causing a problem in this branch though. Like apparently the split lub tests worked well enough to merge to master already -- why the problem here?
I'm going to merge the new lub splits into this branch directly and see if there's a different between this and https://github.com/stan-dev/math/pull/2386.

I'm approving this. I assume something will fail and we'll need to revert code but the basic branch is fine. So once the failing lub tests get sorted out this can go in.

I'm gonna hop over to Windows and see if I can reproduce this error in the 3.5 mix/fun tests. It's not clear why the tests fail here but the same test passed here: https://github.com/stan-dev/math/pull/2391 (unless there is some other difference).

I made a follow up issue for the testing cleanup: https://github.com/stan-dev/math/issues/2395


Generated configuration is incompatible with newer macOS & iOS

Newer macOS and iOS patched a hacky workaround used by WG causing connections to fail with a mysterious error and no logs.
Workaround was posted by the authors and is as simple as adding any DNS to client config:
[Interface]
DNS = <IP_ADDRESS>

Upstream fix in progress: https://git.zx2c4.com/wireguard-apple/commit/?id=20bdf46792905de8862ae7641e50e0f9f99ec946

The fix was delivered within wg update.

The fix was delivered within wg update.


Logging

It might be nice to report some of the logic (which streams were polled, their "alive" numbers, which one was picked, etc) and of course errors to a log.

winston seems to be the best option here.


Feature request: emojis

Love this project. Would be great if you could add support for basic unicode emojis 🙏

Love this project. Would be great if you could add support for basic unicode emojis 🙏

Good point. Absolutely. I think I have to rethink some internal decisions, because I am not quite sure how feasible it is. Same applies to support for Chinese characters.

Cool thanks

I look forward to when this feature is ready. 😊
Nice tool by the way. Thx!


feature request: shortcut to scroll preview window

Did you check existing requests?

[X] I have searched the existing issues

Describe the feature
First off: Thanks a ton for the plugin, this is fantastic, fantastic work.
In telescope, I can scroll the preview of the currently selected item via <c-u> <c-d> - would be awesome to have something similar here to allow oil.nvim
Thanks a ton!
Provide background
I'm trying to improve the speed at which I can explore a repo quickly - a key part of that is being able to browse previews quickly to get a rough overview of the code in each module
Additional details
No response

I've added two new actions you can use for this purpose: actions.preview_scroll_down and actions.preview_scroll_up. You can view all available actions at :help oil-actions now.

You're amazing, thanks so much for all your work on this!


[Communication SDK for Android]: Bump up version number for communication-common and communication-chat

It seems there is a problem with CI. Victor's PR is suffering the same thing. I'll wait a bit to see if "/azp run" can fix it.

/azp run

@weshaggard Can you please play the same magic you did for Victor's PR? This is in the same trouble I believe.

/azp run azure-sdk - ci

/check-enforcer override

/azp run azure-sdk - ci

/azp run azure-sdk - ci

/azp run

/azp run android - communication - ci

/azp run android - communication

/azp run android

/azp run java - android- ci

/azp where

/azp run android - communication - ci

/azp run android - communication - ci


Make @end_trial (or @omit_update(v)) replace the new_trial functionality

Proposal from Magnus:
We take away new_trail and replace it with an end_trial keyword
like this
@phase ....
START ...
...
REWARD       reward     | @end_trial
NO_REWARD    no_reward  | @end_trial

This has four consequences:

w(reward) and w(no_reward) are not updated
v(reward->whatever response) and v(no_reward-> whatever response) are
not updated
end_trial is logged by the program but no arbitrary response to e.g
reward is logged
Jumps to the beginning of the script (we might increase the
functionality here and allow jumps to anywhere).

We still keep the binding on/off options so we can quickly switch
To me this is more clear in several ways than the new_trial solution.
First, it is very clear where things operate, the stimulus is on the
same row as the end_trial keyword. Second, it also becomes more clear
that one must end the trial properly supplying reinforcement to all
outcomes.
Perhaps the keyword @end_trial can be replaced by @omit_update(v)
or something like that which can be used to control which state variables to
avoid updating.
After issue #92 is done, we may need a @cleartrace to flush the trace memory, in the same way.

[x] Add unit tests of trace that compares both "learning to respond to a stimulus" and "learning a chain" with and without trace (with and without @cleartrace), and with and without conditional reinforcment (w) (in other words, compare SR to A-learning (GA)).

Regarding point 3, I would still log what response is chosen. I think it's best not to throw away information.

Addressed. See https://github.com/learningsimulator/learningsimulator/issues/162 for remaining issue.


chore(package): update nyc to version 11.0.1

Closes #113

Codecov Report

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

@@           Coverage Diff           @@
##           master     #114   +/-   ##
=======================================
  Coverage   86.38%   86.38%
=======================================
  Files           1        1
  Lines         191      191
=======================================
  Hits          165      165
  Misses         26       26

Continue to review full report at Codecov.

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


S3 TokenStore

Hey, what do you think about an S3 token store? I started putting some code together here: https://github.com/vscerchia/passwordless-s3. I have a use case where this would be convenient.

Good idea! Does it already work? Should I add a link to the passwordless homepage?


Add support for overriding variables such as INSTALL_BASE

I notice global vars such as
INSTALL_BASE="$HOME/.ghcup"
GHC_LOCATION="$INSTALL_BASE/ghc"
BIN_LOCATION="$INSTALL_BASE/bin"

which would be desirable to allow to be customized in a way that survives self-update; I can think of two common options, either

have vars such as INSTALL_BASE  default to set the value of e.g. a GHCUP_INSTALL_BASE env-var if it's set and non-empty (useful for export GHCUP_INSTALL_BASE=... in your .profile script), or
simply add a couple long-opts, --install-base=, --ghc-location=... etc (this however requires using an alias in your .profile scripts if it's supposed to be a persistent setting)

I think that's tricky. Overwriting INSTALL_BASE (if done wrong) might result in very unexpected and dangerous behavior when we recursively remove ghc versions:
https://github.com/hasufell/ghcup/blob/644a2829e4fc24d752ec370f27bf1a6f89c4a68f/ghcup#L770-L785
It will make validation more complicated. Did the user do something weird or funny? The only thing that should be supported here, imo is changing HOME, which ofc is already possible, but not really an option to control this script behavior.
So, controlling the <something> directory of <something>/.ghcup is quite possible and safe. Would that suffice? I would simply exchange that for an environment variable that defaults to HOME.

@hasufell Well, the motivation is that a very common layout (mostly because I made it popular :-) )  is to install into /opt/ghc/<ver>/ and put symlinks into /opt/ghc/bin. This is e.g. what my PPA does as well as what  https://haskell.futurice.com/ does; and even when I manually install ghc from bindists on non-Debian/Ubuntu, I manually set-up that fs-layout for consistency.

Hi I'm using ghcup in my project, and I'm really interested in this feature, could you give me some more details that you think are important, so that I could implement it?

What is the use case? I really don't like the idea of configurable directories. It's hard to make assumptions in the script. The configured directory may be a file, missing, point to / accidentally or other funny things. Then users will report "your script wiped my whole home directory", because although we require user interaction on rm -rf, people may just hit enter anyway or miss the message.
ghcup is not a package manager and has no knowledge of installed files. I would rather keep it simple.

It's hard to make assumptions in the script. The configured directory may be a file, missing, point to / accidentally or other funny things. Then users will report "your script wiped my whole home directory"

If you only customized where the .ghcup dir would be created, i.e. if you had a customizable variable INSTALL_BASE_PREFIX and defined:
INSTALL_BASE="${INSTALL_BASE_PREFIX}/.ghcup" that wouldn't be an issue, because ghcup only works  inside INSTALL_PREFIX and at most deletes INSTALL_PREFIX, which was created by ghcup, anyways. Also, if you mistakenly assign INSTALL_BASE_PREFIX to a file, then the mkdir at https://github.com/haskell/ghcup/blob/master/ghcup#L1709 will fail, and if it's missing mkdir -p will create it (this may be problematic, maybe).
As far as the use case is concerned, if it doesn't pose many issues, it seems like a cool thing to customize where your data will be put

that wouldn't be an issue, because ghcup only works inside INSTALL_BASE and at most deletes INSTALL_BASE, which was created by ghcup, anyways.
Also, if you mistakenly assign INSTALL_BASE_PREFIX to a file, then the mkdir at https://github.com/haskell/ghcup/blob/master/ghcup#L1709 fails.
Otherwise, if you assign INSTALL_BASE_PREFIX to a missing directory, the mkdir -p at that line will create it (this may be problematic, maybe).

That sounds possible.

Although, now I see that this wouldn't be sufficient to support hvr's layout.

That's a different question and I don't see any use for that currently. Changing layout is also quite intrusive, requires more code change and may break assumptions of users.


API Proposal: refactor file adding

Background
We're in the process of unifying the js-ipfs and js-ipfs-api APIs to be consistent, provided by the interface-ipfs-core interface. For the roadmap, see this issue.
Part of this process is identifying what API calls from js-ipfs-api should be part of the IPFS Core API, and which are auxiliary functions that aren't specific to the core.
Proposed Change
One such API call from js-ipfs-api that doesn't fit well into Core is the ability to add a file or directory using add. Core needs to be as agnostic as possible, and shouldn't be responsible for interacting with the underlying file system at all (think browser support).
This is useful functionality to have though, so I suggest moving the file/directory adding logic into a separate method on the API, like addFiles, which can perform the filesystem operations within this module, and translate them to an array of streams and paths to be handed over to the Core API.
Steps

[x] remove file/directory adding from add
[x] introduce a new api call that does adding files from the local filesystem (addFiles)
[x] remove url adding from add
[x] introduce a new api call that does adding files from a URL (addURL)
[x] use interface-ipfs-core for testing add
[x] bump a major semver to make it clear that this is a breaking change

ping @diasdavid @nginnever @dignifiedquire

This is all done now 🎉 It was merged with the "next-generation" PR :)


Improve CI/CD

Resolves #82

After we merge it, I will publish v1.0.0-dev.0 just to check if CD fully works

Am I right in thinking that the workflow release will execute after manually creating the github release?

Am I right in thinking that the workflow release will execute after manually creating the github release?

Yes, that was the point. I want to explicitly create releases.


E Compile Eror

Reason:
Error: Cannot declare class supercrafter333\theSpawn\supercrafter333\theSpawn\libs\EasyUI\Form, because the name is already in use
File: plugins/theSpawn.phar/src/libs/EasyUI/Form
Line: 17
Type: E_COMPILE_ERROR
I use plugin ver: 2.0.0-poggit

I can confirm this. It's a poggit bug and I reported it to the poggit-team.

i had same issue

Fixed in the latest poggit-release of theSpawn. (v2.0.1-poggit)


Release 1.2.8?

The latest release appears to be 1.2.7
https://github.com/yahoo/kafka-manager/releases
Yet the build file shows it is up to 1.2.9
Any plans to tag 1.2.8 or 1.2.9 in github? This would make it easier for those who create packages to know what commit to choose.
Looks like this was the release for 1.2.9
https://github.com/yahoo/kafka-manager/commit/d8858d6a363c9dd8b6ceb504dc975920fb07c2d0#diff-fdc3abdfd754eeb24090dbd90aeec2ce
And this was the release for 1.2.8
https://github.com/yahoo/kafka-manager/commit/acacac283129080940ca3a02f7160318c7a01421#diff-fdc3abdfd754eeb24090dbd90aeec2ce

Sorry, need to tag them.  However, 1.2.7 is most stable on large clusters.  Consumer offset polling needs to be refactored to be less aggressive.

We're close, upgrading to latest version of play, i just need to test it out before merging and tagging.

<IP_ADDRESS> has been released.  Please give it a try, there is a hard java 8 requirement.


[Help] Where to find script directory?

Hello:
Thanks for making this plugin—very helpful!
I've noted that the plugin can be used for custom clipboard transformations using JavaScript. Unfortunately, however, I don't know where to access the script directory, although I can see that it defaults to advpaste.
Where would I find the directory so that I can create custom transformations? I recognize that editing the scripts in Obsidian won't work, but I also can't find a script directory in the normal Windows File Explorer.
Also, although I think I can figure it out on my own, the transformation I'm aiming for is pretty simple, and maybe you know right away how to do it. I was hoping to do just two things with clipboard text before pasting:

1). Replace every instance of * with \*
2). Replace every line break with the <br>

By default, the plugin looks for the advpaste dir under the root dir of your vault. If it doesn't exist, then you need to create it.


⚠ Bofrost.lu has degraded performance

In 68e8f2e, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 2032 ms

Resolved: Bofrost.lu performance has improved in bce7c4c after 6 minutes.


update RELEASED_VERSIONS for patch releases on 3.73.x

Update RELEASED_VERSIONS as part of 3.73.4 release.
Noticed that 3.73.3 was missing from the list, added it with release 3.12.2 as per https://github.com/stackrox/stackrox/blob/3.73.3/COLLECTOR_VERSION.

It'd be nice to know why we are not getting the automated PRs, anything I can look into?

This bug is still present in release-3.73 release automation, causing the automated PR to be skipped.
I made a note to cherry-pick the fix.


Render data-editable-content on initialization, so we don't need to provide it manually for element-list items

On the left is a list of elements. The Text/Markup inside these elements is manually provided, and not read from the  data-editable-content attribute. This causes different text after the element is added to the canvas.
Fix:  Render the data-editable-content value to text, on initialization, for the elements in the left-side list of elements-to-add.

expose a "renderTo" (or so) function in the custom jqueryUI editing plugin.
borrow the method $.mock.editText.prototype._leaveEditMode before actually initializing the plugin (?)

Seems to be a bit tricky.

Borrowing a method from a jqueryUI plugin seems to be a great idea
I could try to initialize the function on the element in the sidebar and that activate the actual editing function when adding the dragged clone to the canvas.

I add a maybelater lable and close it for now. All solutions which came to my mind would make the code harder to maintain.


Special groups are not dispayed in the profile page

Is your feature request related to a problem? Please describe.
Special groups which the current user belong to are not showed in the list present in the profile page
Describe the solution you'd like
The profile page should also display the list of group which the current user belong to.
This could be done by adding a new specialGroups link to the response from api/authn/status endpoint. On angular side we could use this link to show also the special groups if any
Additional context
https://github.com/DSpace/DSpace/issues/8161

@tdonohue
The estimation for the solution described in the issue is about 16hours for REST and Angular implemenation

@atarix83 : I agree this would be very useful. I didn't realize that Special Groups were not already displayed.
I'll move this over to the 7.3 board & assign to you. If your team can fit this into 7.3, I think it'd be useful to fix soon.


Python: fix for 'run all' paragraphs

What is this PR for?
Switch to FIFO scheduler as in current implementation .interpret() is not thread-safe and so in parallel one 'Run All' fails some paragraphs with NPE in logs
What type of PR is it?
Bug Fix | Improvement
How should this be tested?
'Run All' passes without NPE in logs i.e on this Zeppelin notebook for python
Questions:

Does the licenses files need update? No
Is there breaking changes for older versions? No
Does this needs documentation? No

LGTM

LGTM

CI failed due to networking issues
INFO: I/O exception (java.net.SocketException) caught when processing request to {s}->https://repo.maven.apache.org:443: Connection reset
Jun 17, 2016 6:10:43 AM org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec execute
INFO: Retrying request to {s}->https://repo.maven.apache.org:443

Merging if there is no further discussion


how can i get a contains line and column error message from DiagnosticBuilder?

Question

db.span returns MultSpan


Typo in README: "Inspair"

The README has a typo: "Inspair" instead of "Inspired".

Thank you, it fix now


SSR warning

The issue description is incomplete. The mismatch can have different origins.

Mismatch of NODE_ENV #5973
Mismatch of user-agent, we have some old closed issue with it

Anyway, I fear that the SSR aspect of v0.x was kind of hidden an poorly documented. It's now core with v1-beta. You will find a documentation guide section about it.


Feature request: Don't push to any registry

How can I build a docker image without a manual Dockerfile, but without pushing to a registry - even local? I can handle the upload myself after.

I think you're looking for https://github.com/dotnet/sdk-container-builds/issues/283.

@menasheh how would you use the image/layers if not TAR'd? That's the format that OCI Registries are primarily work with, can you clarify what you'd do with the non-TAR'd assets?

Same here, just build the Docker image during publish but do not push it.
Besides the the flexibility to reuse existing push build logic this allows execution of other build logic before pushing.
In my case I spin up the built Docker image and execute automated system tests.
If those fail I don't push the Docker image.


feat(OHIFv3):Add static e2e data

Make e2e tests run against static data served up by the standard webpack process.

@swederik - how do I make the CI builds also use the static data?
I'm reconsidering where to store the data - I think it should be stored direct in viewer-testdata as an external git include from standard OHIF, already converted to dicomweb.


Add a common MDN network interface (consistent with new DensityEstimators)

Description
The MDN i.e. Gaussian Mixture Density network, is a density estimator which gets a lot of "special" treatment.

SNPE_A requires it, and implements a special "corrected" SNPE_A_MDN wrapper.
SNPE_C has a special loss for it
conditional_density.py implements a special ConditionedMDN to use the "marginalization" properties.

Hence it may be good to collapse all current MDN wrappers/functionalities into a single class MDNDensityEstimator, which does follow the new DensityEstimator.
Advantages:

Reducing code duplication.
Better typing.

I find the SNPE_A_MDN class quite confusing. Is there a loss implemented for it yet? Why does it only inherit from DensityEstimator but not implement all methods?