[bug] streams are not playable when 'reuseport' is specified

Hello, the module has worked fine for me for a long time. I planned to run Nginx in multi-processes mode to take advantage of high performance of it, so I deployed Nginx as you mention in Note and it worked fine. However, it was not load-balanced:

Then I hacked source files and found that the module might support reuseport, I tried to deploy it again and fortunately my testing OS supported it. But something weird happened, I got lots of errors as below:
2019/12/28 20:57:49 [error] 5997#0: *803 live: stream not found, client: ::ffff:<IP_ADDRESS>, server: [::]:1935
2019/12/28 20:57:49 [error] 5997#0: *804 live: stream not found, client: ::ffff:<IP_ADDRESS>, server: [::]:1935
2019/12/28 20:57:49 [error] 5997#0: *805 live: stream not found, client: ::ffff:<IP_ADDRESS>, server: [::]:1935
2019/12/28 20:57:49 [error] 5997#0: *806 live: stream not found, client: ::ffff:<IP_ADDRESS>, server: [::]:1935

If I omitted the option reuseport, it worked. If I added it, errors again appeared. Is it just the bug you have expected to fix? Please ignore it if it is.
It is beyond my ability to fix the bug, so no PR this time:(
Many thanks!
Expected behavior
Streams can be played when reuseport is specified.
Actual behavior
Lots of stream not found errors when reuseport is specified.
Steps to reproduce the behavior
1.Make sure you have an OS that supports reuseport option.
2.Specify option reuseport for the directive listen and turn on the directive rtmp_auto_push and run Nginx in multi-processes mode.
3.Push a stream to Nginx and then initiate many play requests to it.
My OS is CentOS 7.5 and my nginx.conf:
user www-data www-data;

worker_processes  auto;
worker_cpu_affinity auto;

error_log  logs/error.log error;

events {
    worker_connections  4096;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    keepalive_timeout  65;

    server {
        listen       80 reuseport;
        server_name  xxx;

        location / {
            root  /var/www;
            index index.html index.htm;
        }

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }

        location /live {
            flv_live on;

            chunked_transfer_encoding on;

            add_header 'Access-Control-Allow-Origin' '*';
            add_header 'Access-Control-Allow-Credentials' 'true';
        }

        location /control {
            rtmp_control all;
        }

        location /stat {
            rtmp_stat all;
            rtmp_stat_stylesheet stat.xsl;
        }

        location /stat.xsl {
            root /var/www/rtmp;
        }
    }
}

rtmp_auto_push on;
rtmp_auto_push_reconnect 1s;

rtmp {
    out_queue   4096;
    out_cork    8;
    chunk_size  512;
    publish_time_fix on;
    idle_streams off;

    server {
        listen 1935 reuseport;

        application myapp {
            live on;
            gop_cache on;

            wait_video on;
            wait_key on;
        }
    }
}

Hi, @HeyJupiter, it's not the bug written in README that I have not resolved.
My OSes are Debian 7.x and CentOS 6.x, whose kernels are too old to support socket option SO_REUSEPORT. In addition, because of the bug I haven't resolved, I've almost tested the module in single process mode. These are reasons I have not found the bug.
I tested it as you deployed on a cloud server which ran CentOS 7.6 on it and the bug was reproduced.
I will fix it later, thanks for posting the issue!

Hi, @HeyJupiter, the bug was fixed, looking forward to your feedback, thank you!

@winshining Excellent!
Confirmed that it worked without any error and load was evenly distributed to each process:

Thank you very much!


re-enable cabal-sort

Henning released <IP_ADDRESS>

Thanks! Feel free to push directly to master, it's not going to impact what I'm doing.


file watcher continuously eats CPU

windows 10, Node v6.6.0

also runs out of memory eventually:
Security context: 2EE7B815 <JS Object>
    1: _send [internal/child_process.js:627] [pc=38793FA3] (this=2EE860DD <a process with map 0C50E9AD>,message=0492EEDD <an Object with map 12E32085>,handle=2EE081D9 <undefined>,options=0492EB5D <an Object with map 12E31AD9>,callback=2EE081D9 <undefined>)
    2: send [internal/child_process.js:538] [pc=387692A0] (this=2EE860DD <a process with map 0C50E9AD>,message=0492EEDD <an Object with map 12E320...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
fileListingWorker worker restarting. Don't know why it stopped with code: 3

Which version of alm? This happened to me on a folder too big. Should have errored instead of crashing badly.
refs https://github.com/alm-tools/alm/issues/233 which was fixed in 2.3.0 :rose:

alm 2.5.2

How many files in working dir?

Maybe 500

Total files please. The file watcher looks at all files and essentially powers file open + tree view.
More than 100000 or less https://github.com/alm-tools/alm/commit/e292122b61fd3a8365e6ac743e53bfc39aedd9ad#diff-d67e176d5b2909056b10c3b5ed4a1c8eR15

2500 files

2500 files

That is not a lot at all. Thanks for helping me with the stats.
Sadly, short of reimplementing chokidar I can't think of a better solution. Closing as external for now (similar to https://github.com/alm-tools/alm/issues/202)


Tact's dump function does nothing when processing messages

The debug mode should be activated either by default or there should be some way to enable it. Or the IDE could ask the user if they would like to enable it if the contract contains dump

Users can enable this feature from settings panel. It's off by default. We can make it default active.

We can make it default active.

this looks like a nice default, indeed


icon: Keep symbol viewBox value when register an iconSet

Bug, feature request, or proposal:
Bug
What is the expected behavior?
When registering an SVG iconSet, every symbol may provide a custom viewBox attribute. This attribute should be keep in the newly SVG element created.
What is the current behavior?
The viewBox attribute is swallowed.
What are the steps to reproduce?
What is the use-case or motivation for changing an existing behavior?
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
At least since beta 7
Is there anything else we should know?
This is related to #5188 #2981
For SVG icon set with symbol, see https://css-tricks.com/svg-symbol-good-choice-icons/

I think this is captured by work on #5188. md-icon is specifically intended to cover the Material Design icon treatment; a cdk-svg directive would be able to be a lot more general.

hi, i don't see the fix of @ilaborie in the current MatIconRegistry ? The fix is current and I always need a override of MatIconRegistry  with this fix.

I still do not understand why this 3-lines patch is not applied?

hi @jelbourn, any news please ?

I struggled with trying to use a sprite svg file exported from FlatIcon.com (svg file using inline  elements) with the addSvgIconSetInNamespace function. I finally realized the viewBox attribute is NOT inserted into the output svg code with the mat-icon component. I'm glad I found this github issue to confirm.
I'm wondering if anyone has a solution? Without the viewBox values, the SVG cannot be rendered and scaled properly. Is it just not possible? I'll register the icons individually with addSvgIcon if I have to; just thought it would be so much more efficient to have one combined svg file. Advice?

Potentially revisiting this now

Do you support both <defs> and <symbol> in an svg icon set? Symbols seem to work with the exception of the viewbox missing, which causes the icons to not be centered. I'm hesitant to manually fix my entire sprite file since it was easily dynamically generated, unless you don't support <symbol>.

Here is the fix I applied in my code by overriding _toSvgElement method exactly like @ilaborie did:
@NgModule({
  providers: [
    {
      provide: APP_INITIALIZER,
      deps: [MatIconRegistry],
      useFactory: preserveSvgViewBox,
      multi: true
    }
  ]
})
export class IconModule {
}

function preserveSvgViewBox(matIconRegistry: MatIconRegistry) {
  return () => {
    const oldToSvgElement = matIconRegistry['_toSvgElement'];

    matIconRegistry['_toSvgElement'] = (element: Element) => {
      const svg = oldToSvgElement.call(matIconRegistry, element);

      const viewBox = element.getAttribute('viewBox');
      if (viewBox !== null) {
        svg.setAttribute('viewBox', viewBox);
      }
      return svg;
    };
  };
}

Wonderful @Humberd . It is working like a charm. What a bad documentation though. And hard to find some issues. A pity foor such a good framework.

@bsteffl , from material documentation on icon sets:

This is done by creating a single root  tag that contains multiple nested  tags in its  section. Each of these nested tags is identified with an id attribute. This id is used as the name of the icon.

The problem is that icons services like icomoon.io creats icon sets with <symbol>. You can replace it to <svg>, but why?

I think it's fixed in the latest version :
https://github.com/angular/components/blob/d6e7893691425bbf17f610754e37ced7793a8029/src/material/icon/icon-registry.ts#L530-L537


README.md leads to deadlink

In the README.md is a link contained to the documentation of opis/utils but this leads to a github 404 page.
http://www.opis.io/utils
The same issue exists on the http://www.opis.io/ page, when you click on "documentation" for opis/utils.

Yeah, sorry about that. This library is not under active development anymore. We're keeping it just because some old customer is still using it. We are about to rebuild and improve our website and a proper cleanup will be made once we are done with rebuilding. Thanks for letting us know.


actions/setup-java@v2 - Support different distributions

Description:
This pull-request reworks installer approach and create abstract base that can be used for adding new Java distributions. Also this pull-request adds support for Azul and Adoptium (AdoptOpenJDK) distributions.
These changes are going to be released as actions/setup-java@v2 so breaking changes are expected.
Note: we have decided to split changes to a few pull-requests to simplify review process:

Installers: (this pull-request) (workflows are temporary removed, they are added back in next PR)
Tests: https://github.com/actions/setup-java/pull/133
Docs: https://github.com/actions/setup-java/pull/134
Related ADR: https://github.com/actions/setup-java/pull/97

A few technical notes:

Added distribution input without default value.
Added support for two distributions: zulu (Azul OpenJDK), adoptium (Adopt OpenJDK)
The approach for searching Azul Java versions was reworked from scratch. Previously, actions/setup-java@v1 parsed html page https://static.azul.com/zulu/bin/ and use regex to find Java versions.
We have reworked it to use Azul API: https://app.swaggerhub.com/apis-docs/azul/zulu-download-community/1.0. Potentially, it could cause some differences in version resolving but we have tested all major use-cases and didn't find any issues.
Use Adopt API V3 https://api.adoptopenjdk.net/swagger-ui/ to get the list of versions. Unfortunately, API has very hard limitation (20 items per page) so need to paginate pages.
Use the following tool naming in toolcache: Java_${distribution}_${packageType} to make sure that we can cache different vendors side by side.
Also, adds -ea postfix for version in toolcache to distinguish stable and unstable versions (in V1 - it could cause issues)
Bumped all dependencies to latest versions (no risk since it is major release)
We have decided to make distribution and java-package properties optional to simplify use-cases when task is used for setting up Maven publishing (settings.xml), customers don't really need to spend time on Java setup. So if distribution and java-version properties are specified - Java will be installed. Otherwise - only settings.xml will be created. Also both distribution and java-package should be specified together (if only one is specified - error will be raised)
Java versions are stored in tool-cache with 3 digits like (11.0.3) despite the fact that Java versioning is 4 digits (the fourth is build). The same behavior was in V1. It could cause some confusing but neither V1 nor V2 support specifying versions with 4 digits in input - so it shouldn't be an issue. Also, looks like toolkit/toolcache doesn't support 4 digits versions because of semver.clean invocation.
Minor refactoring of auth / gpg code: moving methods to the separate files, replace console.log with core.info, apply styling. No major changes there.
Remove version input in favor of java-version (V1 supported both for backward compatibility)

@giltene , distribution property is mandatory when java-version is specified.
When customer doesn't need to install Java at all and use task to only generate settings.xml and configure signing, he will be able to skip both java-version and distribution properties. But when java-version is specified, distribution is mandatory. Otherwise, task will fail.
See related code: https://github.com/actions/setup-java/blob/implement-v2-installers/src/setup-java.ts#L17

We have decided to make distribution and java-package properties optional to simplify use-cases when task is used for setting up Maven publishing (settings.xml), customers don't really need to spend time on Java setup. So if distribution and java-version properties are specified - Java will be installed. Otherwise - only settings.xml will be created. Also both distribution and java-package should be specified together (if only one is specified - error will be raised)

@giltene , thank you for sharing https://github.com/giltene/jdkTestingMatrix.
We have validated the most of versions via https://github.com/actions/setup-java/blob/implement-v2-tests/.github/workflows/e2e-versions.yml
I will try to validate V2 via your matrix tomorrow

@giltene , distribution property is mandatory when java-version is specified.
When customer doesn't need to install Java at all and use task to only generate settings.xml and configure signing, he will be able to skip both java-version and distribution properties. But when java-version is specified, distribution is mandatory. Otherwise, task will fail.

This is an inconsistent approach. We should either require distribution to be specified explicitly in all cases, or make it optional in all cases (which means there is an implied default distribution). The argument for making it optional for some uses, like ones where no java version is specified [a use case that does not currently exist for this action], is not different than making it optional when e.g. a java version is specified but the update level or build detail was not. We either accept that all uses of this action will start requiring the specification of a distro, or we don't.
On a related note, changing java-version to be optional seems like a very (very!) bad idea. Just think of the configuration control nightmare that would be introduced (and encouraged) by this. Leaving the major java version selection up to "whatever happens to be around today" is a sure way to make common things that work today break tomorrow. It's a bad habit that none of the current (teams of thousands of happy and successful) users of the seta-java action have, but one that that would pop up immediately when enabled.
The main role of the setup-java action is to set up java. Not to set up maven files or gradle files or gpg stuff. Having those other things ride along with setup-java for convenience makes sense to some degree (separate discussion), but changing the main java version setup action to not do its primary job in order to accommodate a convenience path of a side effect is wrong. Maybe there should be a separate maven action to deal with such e.g. maven convenience asks?

The main role of the setup-java action is to set up java. Not to set up maven files or gradle files or gpg stuff. Having those other things ride along with setup-java for convenience makes sense to some degree (separate discussion), but changing the main java version setup action to not do its primary job in order to accommodate a convenience path of a side effect is wrong. Maybe there should be a separate maven action to deal with such e.g. maven convenience asks?

As an open source maintainer I have to agree with @giltene here. I was not even aware that the "setup-java" action does things like maven / gradle settings configuration. This is totally unexpected. Making the java-version optional is a recipe for disaster for already strained open source maintainers. The default containers where GitHub actions are running have some kind of a java version available. This means that compiling might work, but in an unexpected way.
I would ask you to reconsider this approach.

@giltene, thank you for your input on distribution naming. We have renamed adoptium to adopt across all code. It looks shorter and more familiar for customers.
Also, we have validated V2 against your matrix: https://github.com/giltene/jdkTestingMatrix, thank you for sharing it, really great coverage.
Everything works as expected except a few versions that are missed in Azul API for some reason but available on this HTML page https://static.azul.com/zulu/bin/ :

JDK 15.0.0-ea.2 (Azul API provides only 15.0.0-ea.11 and higher)
JDK 16.0.0+5 (Azul API provides only 16.0.0+8 and higher)
JRE macOS 11.0.6, 11.0.7, 11.0.8, 11.0.9, 8.0.242, 8.0.252, 8.0.262, 8.0.265, 8.0.272, 8.0.275

@giltene , @filiphr , agree that having extra functionality related to Maven / gpg in setup-java task looks confusing but we have to live with it since it is already implemented and we don't have plans to drop it in V2.
We don't see any problems with making these inputs optional because it is pretty clear that java-version should be specified in order to set up Java. Also, README and other documentation says about it. If user doesn't specify Java version in setup Java task - what version they are expecting to get?
On the other hand, setting singing / GPG only (without changing Java version) is absolutely valid use-case. And it looks strange to force user to specify java-version and distribution inputs in YAML file when he doesn't really need to change Java version. Also Java installation takes additional time - it doesn't make sense to spend user's build time on installing it.

The main reason why setup-java has Maven functionality in it is so that it's easier to publish to GitHub package registry. When the initial maven publishing feature was added there was a pretty lengthy debate (and I was very much against adding the functionality to setup-java) but we ultimately decided to do it so that publishing would "just work" without any extra configurations or any other actions. I agree that it somewhat distorts the single purpose intent that setup-java initially was meant to provide (and that most users think it provides) but we ultimately decided that the pros outweight the cons.
One solution that was floating around was to create a separate setup-maven or setup-gradle package but we don't have the bandwidth to support yet another action and the maintenance burden would also be very high so we just extended setup-java
Before we started work on the v2-preview, we had some discussions regarding what to do with the existing Maven publishing functionality and the general consensus was to just leave it as is. Don't prioritize any new features for it, don't break what we currently have, but keep the current functionality as is because we still want publishing to GitHub packages to "just work".
Given that we're maintaining the existing Maven publishing functionality, allowing people to use it without specifying any input is a valid scenario considering our hosted runners already have certain Java versions pre-installed and ready to go.

Perhaps too late for setup-java@v2, may be a good starting point for setup-java@v3, but here's what I (as an early adopter of GH Actions, writer of the hello-world-java-action and maintainer of install-jdk.sh used by Travis CI) think about setup-java.
Make users think about and commit to a Java version
Compare how GH users select an OS: xyz-latest, or xyz-VERSION - there's no plain xyz. Users must explicitly state that they either don't care for the actual version (gimme "latest-and-greatest", I'll care about problems when they occur) or that they want exactly xyz-VERSION OS (perhaps, they make use of pre-installed software of the OS image).
Make one thing good
Also, splitting setup-java  into dedicated setup-java, setup-maven, setup-xyz ... actions is a good idea! Focus on setting up Java, nothing more, nothing less - and let the other projects provide their own customized setup actions, building on a stable and clean setup-java action. I bet, Maven committers (as myself) or Gradle devs and others are eager to maintain a dedicated GH for their tool(ing).
Another fine aspect of making a dedicated setup-java action is to leverage pre-installed JDK(s) for the sake of speed. For example, if a user requests a java-version: 11 (and doesn't specifiy any other arguments) and the current image has a matching JDK pre-installed: use it! Zero time lost. If there's no matching version, install (emitting a note that 11 is pre-installed and could be used without overhead) and use that installation. Side-effect: if 90% users request 17 some day, pre-install 17.

The initial description of this PR doesn't mention the jdkFile: input variable supported by setup-java@v1.
In https://github.com/sormuras/download-jdk I am making use of it (right next the good java-version input).
Will setup-java@v2 support the jdkFile: input unchanged?

@sormuras , thank you for feedback.

V2 will be able to use pre-cached versions on Hosted images if they exist. We are doing related changes on images side (all platforms). Example: https://github.com/actions/virtual-environments/pull/2883 . So pre-cached versions will be switched without latency.
Yes, jdkFile is still supported in V2 with minor syntax change. See https://github.com/actions/setup-java/pull/134/files#diff-e8f077830705686ec3300dbcec8ee6ac6345ae9a2965508ff3abc4146d520bf8R77

I don't see a problem with maven uses needing to specify the java version that maven would use when using the setup-java action to do maven things, including publishing. I frankly can't see any value in committing it, in even in the most trivial use cases. I see the mandatory specification of a major java version as a necessity (both for configuration control reasons, and since maven behavior itself can be sensitive to java versions), and see the ability to do anything with setup-java without specifying the java version as introducing a huge negative. E.g. mvn build can [and will] go very badly wrong, in both silent and non-silent ways, if used with changed-at-some-random-point-in-the-futrure java versions. And this will happen (and propagate by example to thousands of places) the minute "simple" uses of maven start working (temporarily) without java-version specified.
I strongly recommend that java-version remain a required property, like it is currently in v1.x.

@maxim : On the caching subject: can we discuss this in some more detail? [and is there a separate thread to do that on?] E.g. will caching check that the cached versions are actually identical (e.g. have the same checksum or hash) as the thing that would have been downloaded had a cached version not been found? There are many update scenarios (e.g. whenever quarterly OpenJDK updates are rolled out, and whenever out-of-cycle critical updates are released, both of which are frequent enough to not ignore) where stale cache decisions could be very problematic, and such decisions an be avoided if the cache logic verifies the checksums of what is available in the cache against the checksums of what would be downloaded.
We are adding hash/checksum information capability in the Disco API for this very reason, with the intent to enable all distros to provide hash value for their download URIs in order to facilitate proper caching functionality.

@maxim : On the caching subject: can we discuss this in some more detail? [and is there a separate thread to do that on?] E.g. will caching check that the cached versions are actually identical (e.g. have the same checksum or hash) as the thing that would have been downloaded had a cached version not been found? There are many update scenarios (e.g. whenever quarterly OpenJDK updates are rolled out, and whenever out-of-cycle critical updates are released, both of which are frequent enough to not ignore) where stale cache decisions could be very problematic, and such decisions an be avoided if the cache logic verifies the checksums of what is available in the cache against the checksums of what would be downloaded.

@giltene , caching logic will work the same way like it works for other tools (go, node, python, haskell) - compare version only, not checksum.
Images will contain latest version of every LTS and will be updated with 1-week delay.
First, action tries to find version that satisfies input locally. If it is not found locally, it will download and install version in runtime.
If you specify exact version like 11.0.10+9 but image contains only 11.0.10+8, then 11.0.10+9 will be downloaded in runtime.

@sormuras , we have validated actions/setup-java@v2 with your repository: https://github.com/dmitry-shibanov/download-jdk/actions/runs/645961061 - it works as expected

@maxim-lobanov I'm a somewhat heavy user of setup-java and cannot think of a single reason not to specify java-version. The Maven/Gradle setup is a convencience (that I like), but if that was the only thing I'd need, I would definitely not use setup-java. Please, make the java-version and distribution properties mandatory!

Thank you for providing your input, I have pushed PR update to mark java-version and distribution properties as required.

,,,Images will contain latest version of every LTS and will be updated with 1-week delay.
First, action tries to find version that satisfies input locally. If it is not found locally, it will download and install version in runtime.
If you specify exact version like 11.0.10+9 but image contains only 11.0.10+8, then 11.0.10+9 will be downloaded in runtime.

@maxim-lobanov I think this will cause a lot of issues. Bringing in a later-than-cached-version only of it is explicitly specified is both counter-intuitive and will likely break many of the commonly relied on behaviors of setup-java.
For example, a common [best] practice is to run tests both against a statically and explicitly selected update version (e.g. "11.0.7") and the latest update version (e.g. "11") of the same java versions, for any version that is currently maintained and has new updates posted multiple times per year. The simple reason for this is to help triage and identify whether tests break because of a change in the jdk or a change in the repo. It is [unfortunately] common for new updates to break things. E.g. just in the recent few months, OpenJDK 8u262, 8u272, and 11.0.9 all had significant real-world breakages found post release, leading to the release of the out of cycle 8u265, 8u275, and <IP_ADDRESS> within weeks. Things that had such breakages revealed in post-release tests included e.g. hadoop and solo.
A one week delay in testing new updates due to caching of e.g. LTS updates would create wide ranging negative impacts, both for the tested repos (which will find out a week late that stuff is newly broken that they may need to be aware of work around, or that new out of cycle stuff has a fix that needs to be urgently used), and for OpenJDK in general: the wide ranging testing of new updates in the hours and days immediately after release can help drive the feedback that identify these things. With 60K+ Github workflows currently testing openjdk updates as they appear, this quick post-release exposure is very helpful, and delaying it by a week would be sad.
I'd like to suggest that, at the very least, the lookup and resolution of the semver specified versions to URIs be done on each run with no attempt to cache that logic, but that the download URI itself be used as a key for caching. This way updates will show up immediately in tests that run after they appear. A preferred solution would cache the hash or checksum to make sure that even replaced binaries at the same URI are treated properly, but URI based caching is probably the next best thing.

By default, action should always check cache firstly. The most of users prefer to use cached version (speed up their builds by 10-30 seconds and more reliable since there is no any change to fail randomly via connection issue) but get up-to-date version with a few days delay. The same way like actions/setup-go, actions/setup-python, actions/setup-node work.
The use-case that you have described makes sense but it shouldn't be a default behavior. For Node.JS, it is achieved via separate flag check-latest so probably we should consider adding something similar to cover this use-case.

Merged these changes to v2-preview branch. Feel free to create an issue for any suggestions / found bugs.
The v2-preview version can be consumed via
- name: setup-java
  uses: actions/setup-java@v2-preview
  with:
    java-version: 'adopt'
    distribution: '11'

I have to admit, I don't know where the cache duration is handled. But I have to concur with @giltene's reasoning.

By default, action should always check cache firstly. The most of users prefer to use cached version (speed up their builds by 10-30 seconds and more reliable since there is no any change to fail randomly via connection issue) but get up-to-date version with a few days delay.

Caching, yes, please. But definitely not for a week! If I specify java-version: 11 I expect to get the newest release within hours of it's availability.
Also, you have discarded my comment about downloading the entire list of available JDKs and the possible connection failures. Now you're using the exact same argument for an insanely long cache timeout.
You can always fall back to using the cache (if available) on connection failures and report a warning.

The same way like actions/setup-go, actions/setup-python, actions/setup-node work.
The use-case that you have described makes sense but it shouldn't be a default behavior. For Node.JS, it is achieved via separate flag check-latest so probably we should consider adding something similar to cover this use-case.

A flag/timeout option is fine with me, but it should default to getting new releases fast.

Caching the contents of a chosen JDK download makes perfect sense, and can save 20-30 seconds and a bunch of bandwidth. Catching the decision of which JDK to choose to download does not. It would only save a small fraction of a second and practically no bandwidth, and lead to operational changes compared to the current behavior seen by the many users of 1.x.
In addition, inconsistent functionality behavior that depends on under-the-hood  choice to selectively cache JDKs (only LTS? Only some distros?) in ways that cause widely varying behavior in terms of how up to date the JDK is (compared to what is currently available for that version spec and distro) will add “surprising” outcomes. Java has an industry-aligned cadence for quarterly updates (across all coordinating distros), so varying this behavior by version spec and distro will lead to some weird stuff.
is there any reason not to just reactively cache all resolved JDK URIs for some reasonable amount of time? Or maybe cache the few hundred recent or hotly used ones of the number or space is a concern?

@maxim-lobanov would you please get back to the caching issue? Just not answerig anymore isn't a solution. Or did I miss a separate thread?

As for the caching timeline - Hosted images are updated on weekly basis so the image cache can't be updated more often.
As for the caching behavior:

Context: we have an image with cached Java 11.0.7+3. Yesterday, Java 11.0.7+4 was released.
User specifies task input java-version: 11

We have two different behavior options:

Java 11.0.7+3 will be chosen without delay and without checking remote source since it is in cache and satisfies user's input. User will be able to specify exact version 11.0.7+4 as input to get the new version earlier.
Action will check the latest version and find that 11.0.7+4 is available. Then action will download and install 11.0.7+4 in runtime with some time delay.

@konradpabjan , The first option will satisfy users who more interested in getting fast and lower-cost builds and don't care much about 1-week delay with updates. We use this approach with other tools and it works perfectly.
The both cases make sense for me but in my understanding, the default task behavior should be the 1st option to use image cache as much as possible and reduce customers' build time like other 1st-party actions do.
In setup-node, we resolved this case with additional flag like check-latest that forces action to use the 2nd option and keeping 1st option by default.

As @giltene already mentioned, the delay of case 2) is only there if there is actually a newer version. In the majority of builds, there is no newer version and the only delay is the API call, not the actual JRE/JDK download.
If you're so concerned about API call timeouts and delays, make the behavior configurable with check-latest and reduce the amount of API calls necessary to retrieve the wanted version.

The first option will satisfy users who more interested in getting fast and lower-cost builds and don't care much about 1-week delay with updates. We use this approach with other tools and it works perfectly.

I really like the approach that setup-node takes. I think most users would prefer to have their workflows just run fast and use whatever is cached on the image by default. In the scenario where a very recent version is needed that is not cached then an extra input such as check-latest makes sense.
@maxim-lobanov let's try to squeeze that into v2-preview 😃
Thanks everyone for the feedback and discussion!

Hello everyone. We prepared pull request with adding check-latest flag. At the moment the tests are failing but it will be fixed by this pull request.


GPU memory-leak

wouldn't it be easier to implement the function as in pytorch?
Like:
torch.cuda.empty_cache()
https://github.com/dmlc/xgboost/issues/4668

Will keep the discussion in linked PR.


Input VCF from somatic variant callers

As briefly mentioned in #14, based on my own variant calling in our cancer dataset and the respective manuscripts, long-read somatic variant callers such as nanomonsv outperform current germline callers like sniffles and cuteSV and call fewer false positives.
I imagine many of decoil users will also be working with cancer data to detect ecDNA so it would be helpful to be able to input VCFs from such callers.
Nanomonsv has an example VCF here. Which is format 4.3
other potential somatic SV callers:
SAVANA appears to be VCF file format 4.2
Severus is less clear to me

@MJoseMo It doesn't seem happy with the VCF output directly from nanomonsv. I get the same WARNING - Corrupted VCF line for all the variants in the VCF file and the output does not detect any ecDNA.
decoil reconstruct \
--bam ${BAM_INPUT} \
--vcf ${VCF_INPUT} \
--coverage ${COV_INPUT} \
--outputdir ${OUTPUT_FOLDER} \
--name ${NAME} \
--reference-genome ${GENOME} \
--annotation-gtf ${ANNO} \
--fragment-min-cov 40 \
--min-cov 40 \
--min-cov-alt 20 \
--min-vaf 0.01 \
--filter-score 40 \
--fragment-min-size 1000 \
--min-sv-len 5000

Set QUAL.MEAN_COVERAGE_WGS to  31.379556649380174
Set QUAL.MINIMAL_FRAGMENT_COVERAGE to  40
2024-09-30 16:22:39,846 - reconstruct.encode - INFO - 0. Start processing
2024-09-30 16:22:39,846 - reconstruct.encode - INFO - nanomonsv.result.vcf
2024-09-30 16:22:39,846 - reconstruct.encode - INFO - 1. Get all breakpoints and parse SV information
2024-09-30 16:22:39,866 - reconstruct.encode - WARNING - Corrupted VCF line chr10	10389704	d_65	C	<DEL>	.	PASS	END=10389755;SVTYPE=DEL;SVLEN=-51	TR:VR	30:19	68:0

Thanks @eesiribloom, I tried the software with the example data, and it completed quickly. However, have you tested it with any real sample? I ran decoil-pipeline command, and it has been running for over a day without generating any new files. How can I check the progress or what step is frozen?

@MJoseMo  and @eesiribloom,
you can now run decoil reconstruct using the VCF files generated by sniffles2, cutSV, and nanomonsv . So please use the parameter --sv-caller nanomonsv if your input file is in nanomonsv format.
If you have other questions please open another issue.

@MJoseMo It doesn't seem happy with the VCF output directly from nanomonsv. I get the same WARNING - Corrupted VCF line for all the variants in the VCF file and the output does not detect any ecDNA.
decoil reconstruct \
--bam ${BAM_INPUT} \
--vcf ${VCF_INPUT} \
--coverage ${COV_INPUT} \
--outputdir ${OUTPUT_FOLDER} \
--name ${NAME} \
--reference-genome ${GENOME} \
--annotation-gtf ${ANNO} \
--fragment-min-cov 40 \
--min-cov 40 \
--min-cov-alt 20 \
--min-vaf 0.01 \
--filter-score 40 \
--fragment-min-size 1000 \
--min-sv-len 5000

Set QUAL.MEAN_COVERAGE_WGS to  31.379556649380174
Set QUAL.MINIMAL_FRAGMENT_COVERAGE to  40
2024-09-30 16:22:39,846 - reconstruct.encode - INFO - 0. Start processing
2024-09-30 16:22:39,846 - reconstruct.encode - INFO - nanomonsv.result.vcf
2024-09-30 16:22:39,846 - reconstruct.encode - INFO - 1. Get all breakpoints and parse SV information
2024-09-30 16:22:39,866 - reconstruct.encode - WARNING - Corrupted VCF line chr10	10389704	d_65	C	<DEL>	.	PASS	END=10389755;SVTYPE=DEL;SVLEN=-51	TR:VR	30:19	68:0

@eesiribloom, this format does not contain the STRAND information this is why it did not work. Which means the VCF file it is not correct, and the method will not work because the SV information it is not complete.
A compatibility with nanomonsv  is now possible. Let me know if it worked for you using decoil reconstruct with --sv-caller nanomonsv


Would love to make this my 1st fork this assume.

Need help if any one can he me on mobile device


Fix/3004/icon in footer not clickable

What is the context of this PR?
As the custom poweredBy accepts HTML and the IDS website is using this to render a more complicated set up than a simple icon image - it has been agreed that IDS would instead add the links to their existing html. Any other implementation would result in a breaking change, requiring either IDS to simplify their existing footer (i.e. providing only an image) or us to scope an enhancement to the current footer modelled after IDS's current set up.
Whether ourselves or IDS feel that this enhancement should be made is up for discussion, but is beyond the scope of this ticket.
As such, the ticket has been adjusted to focus on providing links for the existing default ONS icons which are responsive to the language selection (i.e. the Welsh language version which renders the Welsh variant of the default icon has a link to the Welsh site, and vice versa for the English language version).
fixes #3004
How to review this PR
Run locally and head to the footer component, checking example footer cymraeg for the Welsh language version and example footer default for the English language version.
Checklist
This needs to be completed by the person raising the PR.

[x] I have selected the correct Assignee
[x] I have linked the correct Issue

Have you pushed your latest changes? I cant see any extra commits since I last looked


Create container-orchestration.md in hindi

Describe your changes
I have added the container-orchestration.md in hindi
Related issue number or link (ex: resolves #issue-number)
resolves #1977
Checklist before opening this PR (put x in the checkboxes)

[x] This PR does not contain plagiarism

don’t copy other people’s work unless you are

[x] I have signed off on all commits

signing off (ex: git commit -s) is to affirm that commits comply quoting and contributing it to them.

[x] I have signed off on all commits

signing off (ex: git commit -s) is to affirm that commits comply DCO. If you are working locally, you could add an alias to your gitconfig by running git config --global alias.ci "commit -s".

Reviewers:
Please looks on this PR

@ARYANis0001 It looks like you are proposing changes to 2 different files with same PR. Consider removing your 2nd commit and raising it through a different PR.


LightmapGI doesn't take CameraAttributes into account when baking indirect light in lightmaps (and only partially for direct light)

Related to https://github.com/godotengine/godot/issues/74134.

Godot version
4.0.rc6
System information
Fedora 37, GeForce RTX 4090 (NVIDIA 525.85.05)
Issue description
LightmapGI doesn't take CameraAttributes into account when baking indirect light in lightmaps (and only partially for direct light, i.e. when using Static bake mode).
DirectionalLight3D bake mode set to Dynamic
Regardless of the presence of a CameraAttributes resource in the LightmapGI's properties, this is the result after baking.

DirectionalLight3D bake mode set to Static, LightmapGI with CameraAttributesPhysical
This works as expected, but changing exposure parameters then baking again doesn't affect light brightness at all even after rebaking lightmaps (be it aperture, shutter speed, ISO or multiplier).
Also note that using a CameraAttributesPractical results in the same lighting, which is unexpected.

DirectionalLight3D bake mode set to Static, LightmapGI without CameraAttributesPhysical
This is overly bright as expected (which shows that the presence of the CameraAttributes is taken into account by LightmapGI somehow).

Steps to reproduce

Follow Physical light and camera units documentation to enable physical light and camera units in a project.
Set up LightmapGI then bake it.

Minimal reproduction project
physical_light_camera_units_lightmap.zip

I'll take a deeper look soon. But it doesn't look like there is a bug here. The Camera attributes that is used by GI (both Lightmap and Voxel) is only used for adjusting the dynamic range when baking. At render time, the exposure will be adjusted to match the CameraAttributes that is used at render time.
You want the bake-time exposure to be as similar to the render-time exposure as you can to reduce banding.


Love this idea! Having issues, though.

First of all, thank you for creating this! Mermaid diagrams are such a mess on docusaurus when they're large and complicated.
Additional Context: I'm on the latest version of Docusaurus right now (3.5.2).
I did have one issue when trying to install it.  I couldn't install it with yarn or npm using yarn add docusaurus-plugin-panzoom or npm install docusaurus-plugin-panzoom. It couldn't find it in the registry, so I had to use yarn add @actinc/docusaurus-plugin-panzoom. So, you probably just need to update the README.
It would be really helpful to throw some more documentation in the README on how you might use this in Docusaurus. I know you link to the Panzoom package, but it would be helpful showing how we'd use your plugin in a Docusaurus site (e.g. for Mermaid Diagrams, etc) and in our .md or .mdx files.
Second issue, I'm having now is it failing when I kick off yarn start. No errors in my terminal but when you view localhost:3000 you will get this in your Chrome console:
PanZoom.js:1 Uncaught TypeError: Cannot read properties of undefined (reading 'selectors')
    at eval (PanZoom.js:1:1)
    at<EMAIL_ADDRESS>(main.js:55:1)
    at __webpack_require__ (runtime~main.js:34:32)
    at fn (runtime~main.js:334:21)
    at eval (client-modules.js:1:1)
    at ./.docusaurus/client-modules.js (main.js:31:1)
    at __webpack_require__ (runtime~main.js:34:32)
    at fn (runtime~main.js:334:21)
    at eval (App.js:7:83)
    at<EMAIL_ADDRESS>(main.js:63:1)

I haven't done anything other than install the package and add the plugin to my docusaurus.config.js.
plugins: [
    require.resolve("docusaurus-lunr-search"),
    "@actinc/docusaurus-plugin-panzoom",
  ],

Let me know if I can help in any way. I have seen tons of StackOverflow questions and other people out there wanting to be able to pan/zoom their Mermaid diagrams in Docusaurus.

try to add zoom in themeConfig in docusaurus.config.ts
themeConfig: {
zoom: {},
works for me :)

try to add zoom in themeConfig in docusaurus.config.ts
themeConfig: { zoom: {},
works for me :)

This exactly is what I did additionally to get it working:
     zoom: {         selectors: ['.panzoom-mermaid'], // Your specific selectors for elements to apply panzoom         wrap: true, // Optional: whether to wrap elements in a div with overflow hidden         timeout: 1000, // Optional: delay before initializing panzoom, in milliseconds         options: {           maxScale: 3, // Maximum zoom scale           minScale: 1, // Minimum zoom scale           contain: 'inside', // How the zoom should be contained         },       },


"module" is not a known member of module Pylance(reportGeneralTypeIssues)

I cooked this down to a tiny setup:

test.py - see snippet below
mypack - folder

__int__.py - empty
module1.py - containing function stub def do_something():\n    return
module2.py - empty

In test.py there is:
import mypack.module1

def main():
    import mypack.module2

    mypack.module1.do_something() # <-

if __name__ == '__main__':
    main()

So I do a lazy import in my function and now I get module1 highlighted:

Although this never seems to be a problem! I'm aaalmost sure we discussed this somewhere else already but currently I can't remember what was wrong with this. In this setup when I debug step through it or even print mypack.module1 is always there and seems untouched by the import. In any Python version! Is there a way to make it break like that? 🤔
Environment data

Language Server version: v2021.9.2
Python Extension: v2021.9.1246542782
Python version: 3.9.7, 3.8.10, 2.7.18

Version: 1.60.1 (user setup)
Commit: 83bd43bc519d15e50c4272c6cf5c1479df196a4d
Date: 2021-09-10T17:07:10.714Z (1 wk ago)
Electron: 13.1.8
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Windows_NT x64 10.0.19043

This is a duplicate of https://github.com/microsoft/pylance-release/issues/1834.

Some explanation like this one from @erictraut  in #1834 should be on the report about this.
To the user this seems super broken while the code obviously works.
To my question:

Is there a way to make it break like that? 🤔

was no answer.
So this should rather be a "warning" with a tip on how to fix it than an red-underlined issue.


MINOR: Fix call order for HB error and group manager

Fix to ensure that the group manager is notified about HB errors only after having propagated the error to the app thread via en ErrorEvent. This is to ensure that the app thread is aware of the error if ever there is an ongoing unsubscribe operation processing background events in the app thread.

Hello @chia7712 , any chance you could take a look at this small fix? Thanks!

@lianetm Thanks for the patch. The fix makes sense to me. Could you open a JIRA for it since it's a bug fix? Additionally, should we also fix onFailure? It similarly completes the ongoing unsubscribe before sending an ErrorEvent.
https://github.com/apache/kafka/blob/18199028a672fd973ac37bf26316994babc2a6da/clients/src/main/java/org/apache/kafka/clients/consumer/internals/AbstractHeartbeatRequestManager.java#L308

Hi @chia7712, added the fix and test to the onFailure path too, good catch. Thanks for the review!


fixed version of the bot  ?

Is there a version of the bot that includes all the fixes made by the author and the contributors?

I'm not the author of this bot, but I'm pretty sure the 'improved version' you are talking about isn't publicly available and won't be any time soon. Any and all improvements likely went into their closed source trading platform AESIR. I would personally recommend giving AESIR a try if you're looking for something easy to use.
That being said, I'm developing a modern open source bot which is based on the same strategy here. Looking for testers and contributors to improve this further, so join us if you can!


Add sharedparentname to add/update drivefile

This allows the user to select a parent folder other that one she owns, a shared folder typically
Documentation updates

No progress here, back to vault updates


Correct typo in function docs

Description of changes: simple typo fix
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Closing because I think the current comment is correct. Please reopen if you have a link that shows otherwise.


Implement incr

closes #4

Needed to update lock scheme because if there were many concurrent connections, another process could get the lock between reading the value and writing the value and change it part way through. Though slower, this new lock implementation will reduce race conditions.


On Bootstrap 5.3 web, "multiple" select example does not work.

Prerequisites

[X] I have searched for duplicate or closed issues
[X] I have validated any HTML to avoid common problems
[X] I have read the contributing guidelines

Describe the issue
On page:
https://getbootstrap.com/docs/5.3/forms/select/
The example for "multiple" which is a  multiselect does not work.
It should: provide checkboxes for selection and allow for multiple items
to be selected. It does neither.
Reduced test cases
N/A
What operating system(s) are you seeing the problem on?
Windows
What browser(s) are you seeing the problem on?
Firefox
What version of Bootstrap are you using?
5.3

It's working as intended. You need to press SHIFT and click on each item to select.
See MDN docs for details: https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/multiple
(I realise it's not intuitive though, if I was using a select with multiple attribute on a site I would explain how a user can select more than one - see accessibility concerns here: https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/multiple#accessibility_concerns)

Closing this issue based on @coliff's answer


Row select using right click?

Is there anyway i can get the row data by using right click?
Edit: Thank you for this super-flexible grid.

You could do the same row to data conversion grid does.
var data = {};
var row = clicked_row_element;
var grid = new MvcGrid(element);

grid.columns.forEach(function (column, i) {
    data[column.name] = row.cells[i].innerText;
});

Do I implement your code in here?
document.addEventListener('rowclick', function (e) {     . . . . });
or in a separate function that listens to a right click event?

You add it in your own right click listener.

Got it. Thanks.


DNxHR Support on Linux

There is no DNxHR Support.
Would be very nice if someone can implement this, FFMPEG v3 supports the new DNxHR and DNxHD formats.
So far I am only able to play them with ffplay, would be nice to have a GUI like movie-nomad.

Hello @magdesign,
FFmpeg considers dnxhr to be a profile of dnxhd since dnxhr is meant to be backwards compatible.
Looking over the different profiles, Movie Monad supports the dnxhd profile since GStreamer supports it if you have gst-libav installed.
ffmpeg -h encoder=dnxhd
ffmpeg version 3.4.2 Copyright (c) 2000-2018 the FFmpeg developers
Encoder dnxhd [VC3/DNxHD]:
    General capabilities: threads
    Threading capabilities: frame and slice
    Supported pixel formats: yuv422p yuv422p10le yuv444p10le gbrp10le
dnxhd AVOptions:
  -nitris_compat     <boolean>    E..V.... encode with Avid Nitris compatibility (default false)
  -ibias             <int>        E..V.... intra quant bias (from INT_MIN to INT_MAX) (default 0)
  -profile           <int>        E..V.... (from 0 to 5) (default dnxhd)
     dnxhd                        E..V....
     dnxhr_444                    E..V....
     dnxhr_hqx                    E..V....
     dnxhr_hq                     E..V....
     dnxhr_sq                     E..V....
     dnxhr_lb                     E..V....

I tried the other dnxhr_* profiles and yes you are correct. Movie Monad cannot play them since GStreamer cannot.
When attempting to discover a mxf file encoded with the dnxhr_* profile, GStreamer reports an internal data stream error.
An error was encountered while discovering the file
 Internal data stream error.

Not sure if this is a bug with GStreamer.
When attempting to discover a mov file encoded with the dnxhr_* profile, GStreamer reports missing plugins.
Missing plugins
 (gstreamer|1.0|gst-discoverer-1.0|video/x-gst-fourcc-AVdh decoder|decoder-video/x-gst-fourcc-AVdh)

GStreamer should support the other profiles since it uses FFmpeg which supports all the profiles listed up above.
gst-inspect-1.0  | grep -i dnxhd
libav:  avenc_dnxhd: libav VC3/DNxHD encoder
libav:  avdec_dnxhd: libav VC3/DNxHD decoder

I'll have to open a ticket with GStreamer to see if it should already support dnxhr and if not, can they add it to gst-libav.
Once GStreamer supports the various dnxhr_* profiles, Movie Monad will be able to play any video encoded with dnxhr.
:+1:

Thanks!
Hopefully the get an ear for this...


Fix typo

@kenwith
Can you review the proposed change?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

Thank you for catch and fix, much appreciated!
#sign-off


Text Dragabble

Hi All,
Is there a way to drag and place the text dynmaically, rather than specifying the position

@sathishrajendrian  any update on this?


Update MD file on new branch 2017-12-01_17-43-30

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

split/content1.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


tooling API

Cant access resources in the tooling API
https://developer.salesforce.com/docs/atlas.en-us.200.0.api_tooling.meta/api_tooling/intro_rest_resources.htm

I would also like to see some methods for query/update against the tooling api endpoints
maybe add ToolingQueryAsync and ToolingUpdateAsync


What is the correct integration option with Angular SPA's to workaround SameSite cookie changes

Please follow the issue template below. Failure to do so will result in a delay in answering your question.
Library

[ ]<EMAIL_ADDRESS>or<EMAIL_ADDRESS>[ ]<EMAIL_ADDRESS>[ ]<EMAIL_ADDRESS>[x]<EMAIL_ADDRESS>[ ]<EMAIL_ADDRESS>
Description
What is the expectation for current MSAL-Angular users who have a Single Page Application? We need to update our authentication flow to workaround the changes to SameSite cookie handling (ITP). It seems that the advice is to use the PKCE flow, which is available in MSAL-Browser v2.x. However MSAL-Angular targets the 1.x framework, and I don't see that changing in the roadmap.
Is the expectation for applications like ours to re-integrate with MSAL-Browser, or is there an option with MSAL-Angular, either now or in the future?
Apologies if this is obvious, I looked through a number of related issues and the docs and I just couldn't work out a clear answer.

Just saw another issue #2042 raising this same problem.


Hyperd reported wrong IPs after pod has been restarted

The pod IP is remaining old one after pod has been restarted:
hyperctl exec 06a17596ae1a796da5cb5d7dc02bdb5c72840ee6879d906db8ec49692499fe64 ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:ac:23:1b:7a brd ff:ff:ff:ff:ff:ff
    inet <IP_ADDRESS>/24 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:acff:fe23:1b7a/64 scope link
       valid_lft forever preferred_lft forever

echo -e "GET /pod/info?podName=xxxxxx HTTP/1.0\r\n" | socat unix-connect:/var/run/hyper.sock STDIO
HTTP/1.0 200 OK
Content-Type: application/json
Server: Docker/library-import (linux)
Date: Tue, 13 Dec 2016 06:32:27 GMT

...
"podIP":["<IP_ADDRESS>"]
...

has this been fixed @feiskyer ?

@gnawux Yep, already fixed.


DOC: sparse.linalg.gcrotmk: add missing backticks

Added hyperlink for LinearOperator in parameter description of A and M

Also, it'd be good to fix the order of Examples and References` sections while you're at it. That would get this docstring in good shape.

Done! Also spotted a similar ordering issue in scipy.interpolate.CubicHermiteSpline so fixed that one too.


Compare product page can be enhanced

Is your feature request related to a problem? Please describe.
The add to cart button is breaking into two lines in the dutch locale. Please find the screenshot Here
Describe the solution you'd like
The remove and wishlist icons should be just below of add to cart button on compare page. Please take a reference from the below screenshot.

Describe alternatives you've considered
No response
Additional context
No response

@Sanjaybhattwebkul assign this issue to me

@jitendra-webkul  @shagun2405
I am reopening this issue because I am getting the UI issue with the wishlist icon. on the product's view page.
Please find the screenshot Here.
@papnoisanjeev    Please look into it.

@jitendra-webkul
Now, this issue is fixed. so I am closing this issue.
And I have attached a screenshot Here, for future reference.


update rdns-server chart to for new release

should be rebased with #22

When updating chart versions, can we do a copy commit and then an update commit so I can actually see a diff? Challenge with these is the new versions are all new files making it hard to see what changed.


Add overview image

@ArvindHarinder1 : Thanks for your contribution! The author(s) have been notified to review your proposed change.


Fix minimum wage rates for people aged 24

Trello card: https://trello.com/c/n72PekVB
A problem in the minimum_wage_data.yml file meant that responding to the am-i-getting-minimum-wage "age" question with "24" resulted in exceptions being logged in errbit.
I've fixed the problem in minimum_wage_data.yml and have also updated the data so that the National Living Wage only applies from 1 Apr 2016 (instead of 1 Oct 2015).

:+1: Thanks for fixing @chrisroos


Make a #TeamTrees announcement

A lot of you have probably seen youtube videos about teamtrees with the goal to raise $20M by 2020, and for every dollar donated, the Arbor Day Foundation will plant a tree.
Lets put an announcement in #announcements for it to help raise more awareness and money!
Website is teamtrees.org

Yes @thebeanogamer can we do this please?

Ngl think there's better causes to raise money for

I had hoped this would be a quick issue for an announcement that, while not related to the server, is still important.
It hasn't been quick and I'm not sure how much point there is in leaving this open.
If staff come along later and think an announcement for this would be cool, me closing this now will not stop them.


Trained Models and Example Input Data

Hi, I was just reading the associated Nature paper, which says that pre-trained models used in the paper can be found at this repository. Can you point me to where I can find these as well as an example of the input data so that I can give the model a try.

Hi, the model has been added. However, due to the file size limit, the keras files are in pieces. You may need to merged them after downloading.

Hello, I would also like to run this model. Could you please refer me to the place you mentioned the input file format for predict_cancer.py?

Hi Max,
did you ever get this working?
Particularly interested in --input_file format for DNN-Model/predict_cancer.py.
Bruce

Hi Bruce,
I did not, while they provided the model, they did not provide example input data or script to get the input from vcf.

Shame, thanks for coming back to me.

Hi, the model has been added. However, due to the file size limit, the keras files are in pieces. You may need to merged them after downloading.

hi, i merge them by 'cat ensemble_model.keras.a* > ensemble_model.keras',but i can't load model. the error is "OSError: SavedModel file does not exist at: /public/slst/home/ningwei/TCGA/ensemble_model.keras/{saved_model.pbtxt|saved_model.pb}"
do you know where i am wrony, and what i should do??
thank you very much！


add app_launcher docs and basic options descriptions

Refer to #130
I was actually trying to implement something exactly like this myself without knowing it already existed.  Hopefully adding the docs will help someone else find it on the bling website.
Couple things in this documentation.

I wasn't sure the proper way to give a description of every option, some I left blank because I don't understand what the options do.  (save_history, the commands options, and the rubato option)
I noticed a typo on the shrink_width option, but I didn't want to fix it without running it by your team first.  The correct move would be to rename from shirnk_width to shrink_width but I don't know the downstream effects or how you normally disseminate breaking changes like that, so I left it as shirnk_width and documented it as such.  Should I add a more clear note in these docs letting end users know that it's not a typo in the docs, rather the real option name?
Do you want more images to demonstrate the options?  I wasn't sure so I just used the image @JavaCafe01 posted a little bit ago in one of the PRs (https://github.com/BlingCorp/bling/pull/103#issuecomment-960128253).

Let me know what I can improve on this, and thank you all so much for bling.

Very cool that you did that, thank you

don't understand what the options do. (save_history, the commands options, and the rubato option)

Not a huge user of the module myself. My guesses are that Rubato is probably there to make the launcher "fly" into the screen and should be a table { x = rubato_animation_x, y = rubato_animation_y }. search_commands should be a boolean that determines whether the app launcher should not only match the name of the app but also the commandline command with which it would start (https://lazka.github.io/pgi-docs/Gio-2.0/interfaces/AppInfo.html#Gio.AppInfo.get_commandline). So skip_commands would be the same as skip_names but for commandline options (eg maybe something like skip all that have a "--whatever" flag). Maybe @Kasper24 or @JavaCafe01 can provide more insights?

rename from shirnk_width to shrink_width but I don't know the downstream effects or how you normally disseminate breaking changes

I would say, just rename the option. We don't do releases so there is no good way to fix something like that

Do you want more images to demonstrate the options?

One image is enough, it's just there so people can get an idea. We handle it like that in other modules too :+1:

@Kasper24 Question for you about how you intended for the skip_commands option to work.
Was it intended to allow me to skip some granular levels of commandline command like Noo037 mentioned above?
Let's say I want to have some Thunar commands show in the list, but not all of them.  I normally have

thunar %F (Thunar File Manager)
thunar --bulk-rename %F (Bulk Rename)
thunar-settings (File Manager Settings)
thunar-volman-settings (Removable Drives and Media)
in my app launcher.

Say I don't want the Bulk Rename option to show, should I be able to pass in --bulk-rename %F to skip that app?
or
Should I pass in thunar --bulk-rename %Fto skip it?
Right now, neither of those is what actually happens for me, so maybe I still don't understand the intent.

Kasper seems to be awol for the time being. Thank you for your contribution of making his work usable for other people too, very much appreciated


Orders table

isnt better to add orders table ?
i mean after checkout, everything goes to orders table so u  can keep track of orders while having an empty cart?

Indeed. But this library only focuses on handling the cart and leaves all the orders related logic. So that you can have a separate Order model, move cart items to it and clear the cart after checkout.


serverless-python-requirements doesn't seem to remove .pyc, .pyo, or other files from lambda zip, irrespective of options specified in serverless.yml

It appears that the serverless-python-requirements plugin is exhibiting some odd behavior. It doesn't appear to be slimming the contents of the package that's deployed to Lambda, and includes the entire contents of the venv directory in the package, irrespective of whether or not athe zip option was selected.
Here's what our serverless.yml looks like:
plugins:
  - serverless-python-requirements
custom:
  pythonRequirements:
    useDownloadCache: false
    useStaticCache: false
    invalidateCaches: true
    zip: true
    slim: true
    slimPatternsAppendDefaults: false # we need to overwrite default dist-info
    slimPatterns:
      # "normal" exclusions:
      - '**/tests/*'
      # default dist-info with !(lib_name*) - matches only if name is not present:
      - "**/!(lib_name*)*.dist-info/*"
      # the rest of defaults:
      - '**/*.py[c|o]'
      - '**/__pycache__*'
  stage: 'dev'
package:
  individually: true
provider:
  name: aws
  runtime: python3.8
  timeout: 20
  region: us-west-2
functions:
  train-model:
    handler: src/python/aws/lambda/train_model.handler

The reason for the slimPatterns is the following comment:

I have found a workaround, sadly it's a bit inconvenient to use  At least it works

    slim: true
    slimPatternsAppendDefaults: false # we need to overwrite default dist-info
    slimPatterns:
      # "normal" exclusions:
      - '**/tests/*'
      # default dist-info with !(lib_name*) - matches only if name is not present:
      - "**/!(lib_name*)*.dist-info/*"
      # the rest of defaults:
      - '**/*.py[c|o]'
      -  '**/__pycache__*'

Okay fine, but even that doesn't seem to work. Now with the zip: true above, I do get the .requirements.zip. Woo hoo! It's ~59 megs. BUT, here's my Serverless package:
$ ls -alh train-model.zip
-rw-r--r-- 1 ryancammer ryancammer 281M Dec  8 20:27 train-model.zip

And why is it so huge?
$ unzip train-model.zip
inflating: venv/lib64/python3.8/site-packages/websocket/tests/__pycache__/test_cookiejar.cpython-38.pyc
  inflating: venv/lib64/python3.8/site-packages/websocket/tests/__pycache__/test_websocket.cpython-38.pyc
  inflating: venv/lib64/python3.8/site-packages/websocket/tests/data/header01.txt
  inflating: venv/lib64/python3.8/site-packages/websocket/tests/data/header02.txt
  inflating: venv/lib64/python3.8/site-packages/websocket/tests/test_cookiejar.py
  inflating: venv/lib64/python3.8/site-packages/websocket/tests/test_websocket.py
  inflating: venv/lib64/python3.8/site-packages/websocket_client-0.56.0.dist-info/INSTALLER
  inflating: venv/lib64/python3.8/site-packages/websocket_client-0.56.0.dist-info/LICENSE
  inflating: venv/lib64/python3.8/site-packages/websocket_client-0.56.0.dist-info/METADATA
  inflating: venv/lib64/python3.8/site-packages/websocket_client-0.56.0.dist-info/RECORD
  inflating: venv/lib64/python3.8/site-packages/websocket_client-0.56.0.dist-info/WHEEL
  inflating: venv/lib64/python3.8/site-packages/websocket_client-0.56.0.dist-info/top_level.txt
  inflating: venv/lib64/python3.8/site-packages/yaml/__init__.py
  inflating: venv/lib64/python3.8/site-packages/yaml/__pycache__/__init__.cpython-38.pyc
  inflating: venv/lib64/python3.8/site-packages/yaml/__pycache__/composer.cpython-38.pyc
  inflating: venv/lib64/python3.8/site-packages/yaml/__pycache__/constructor.cpython-38.pyc
  inflating: venv/lib64/python3.8/site-packages/yaml/__pycache__/cyaml.cpython-38.pyc
  inflating: venv/lib64/python3.8/site-packages/yaml/__pycache__/dumper.cpython-38.pyc
  inflating: venv/lib64/python3.8/site-packages/yaml/__pycache__/emitter.cpython-38.pyc
  inflating: venv/lib64/python3.8/site-packages/yaml/__pycache__/error.cpython-38.pyc
  inflating: venv/lib64/python3.8/site-packages/yaml/__pycache__/events.cpython-38.pyc
  inflating: venv/lib64/python3.8/site-packages/yaml/__pycache__/loader.cpython-38.pyc
  inflating: venv/lib64/python3.8/site-packages/yaml/__pycache__/nodes.cpython-38.pyc
  inflating: venv/lib64/python3.8/site-packages/yaml/__pycache__/parser.cpython-38.pyc
  inflating: venv/lib64/python3.8/site-packages/yaml/__pycache__/reader.cpython-38.pyc
  inflating: venv/lib64/python3.8/site-packages/yaml/__pycache__/representer.cpython-38.pyc
  inflating: venv/lib64/python3.8/site-packages/yaml/__pycache__/resolver.cpython-38.pyc
  inflating: venv/lib64/python3.8/site-packages/yaml/__pycache__/scanner.cpython-38.pyc
  inflating: venv/lib64/python3.8/site-packages/yaml/__pycache__/serializer.cpython-38.pyc
  inflating: venv/lib64/python3.8/site-packages/yaml/__pycache__/tokens.cpython-38.pyc
  inflating: venv/lib64/python3.8/site-packages/yaml/composer.py
  inflating: venv/lib64/python3.8/site-packages/yaml/constructor.py
  inflating: venv/lib64/python3.8/site-packages/yaml/cyaml.py
  inflating: venv/lib64/python3.8/site-packages/yaml/dumper.py
  inflating: venv/lib64/python3.8/site-packages/yaml/emitter.py
  inflating: venv/lib64/python3.8/site-packages/yaml/error.py
  inflating: venv/lib64/python3.8/site-packages/yaml/events.py
  inflating: venv/lib64/python3.8/site-packages/yaml/loader.py
  inflating: venv/lib64/python3.8/site-packages/yaml/nodes.py
  inflating: venv/lib64/python3.8/site-packages/yaml/parser.py
  inflating: venv/lib64/python3.8/site-packages/yaml/reader.py
  inflating: venv/lib64/python3.8/site-packages/yaml/representer.py
  inflating: venv/lib64/python3.8/site-packages/yaml/resolver.py
  inflating: venv/lib64/python3.8/site-packages/yaml/scanner.py
  inflating: venv/lib64/python3.8/site-packages/yaml/serializer.py
  inflating: venv/lib64/python3.8/site-packages/yaml/tokens.py

So basically, the plugin is including the venv directory anyway, .pyc and all. Using dockerizePip: true,  this is the result on OSX:
✗ ls -h
-rw-r--r--   1 cory  staff    64M Dec  8 20:46 .requirements.zip
-rw-r--r--   1 cory  staff    76M Dec  8 20:46 train-model.zip

Again, that train-model.zip file was chock full of .pyc files. I've tried with and without the slimPatterns, with and without zip: true, but no matter what, the end result is a massive lambda zip that's full of .pyc files.

I am also having this same problem, on both Linux and MacOS - seems that the slim feature just doesn't work at all. I'm using this with multiple functions specified with the module option.
It's been marked as a bug, and there are several related issues also marked as bug, but would be great to have more information on it in case there's a work-around or if I'll have to figure out another solution.

I'm having this issue as well. slim: true does not seem to do anything.

So, I tried this and I can't replicate this problem.  First let me ask, do you guys know that slim only works against the installed requirements?  So, after the requirements.txt is handled and all reqs are installed into a subdirectory, then that folder is run through the slim patterns.  So slim will not exclude files in your folder already.  If you'd like that, serverless has an "excludes" feature built-into it defined at the top-level.
If I'm missing something else here, please explain/show me in more detail.

@ryancammer / @dashmug  / @matthewhanson / anyone else: Please provide more details and/or a repo that highlights this problem so I can debug further

@AndrewFarley I'll post a repro repo later today.

@AndrewFarley Here's the repro: https://github.com/dashmug/serverless-python-requirements-issue-437
Let me know what you think and if there's anything I can help with. Thanks.

@dashmug I tried your repo, the zip looks good to me.  It slimmed perfectly.  Admittedly, I did modify the serverless.yml a bit though.  Also, I didn't use the version of serverless from your package.json, I used the latest release.   I narrowed it down considerably. It appears that pymysql is causing the package to not slim. I have:
pythonRequirements:
slim: true
usePoetry: true
strip: false

@bsamuel-ui
I am also hitting this issue. I don't know if it helps but can describe how it happened:

Setup serverless application and deploy a function with this config:

custom:
  pythonRequirements:
    dockerizePip: non-linux

    layer: true

And this point everything is working fine 🚀

Change config to this one (just added slim: true):

custom:
  pythonRequirements:
    dockerizePip: non-linux

    layer: true

    slim: true

And I noticed that I don't have Docker running anymore (I am using macOS + dockerizePip: non-linux) and also useless files don't get removed from the ZIP according to the documentation of slim: true option.

What really helped me was cache reset. I don't know for sure but I suppose that serverless-python-requirements plugin looks at changes in requirements.txt and makes a decision to use a cached version from the previous deployment or not. And this is incorrect because it completely ignores any changes to config in serverless.yml.

Exactly this command helped me (and I have to do it every time I change config of the plugin): serverless requirements cleanCache. Docker got running and also useless files got removed by slim: true option and made my pythonRequirements.zip file 5 MB lighter 👍
Also, it's a pity that this command isn't documented in README.md... I found it wandering in the source code.
@AndrewFarley Maybe because you didn't have cache on your machine for that project you couldn't reproduce the issue here

Thanks @GarrisonD, serverless requirements cleanCache did the trick!

serverless requirements cleanCache definitely should be mentioned in the README. slim didn't worked for me and my several teammates without this command. so we just never used slim at all...

useStaticCache: false or serverless requirements cleanCache have done the trick for me.
@AndrewFarley Would it be possible to use a hash of the slimPatterns array in the name of the cache file to determine if it needs regeneration?

 I was using slim: true and it was removing the dist-info directories I needed because Langchain in their newer version used a new version of metadata package that relies on the .dist-info directories.
See issue #441 and Freek Wiekmeijer comments at the bottom.
Despite the new changes to exclude the .dist-info directories from being removed, this kept excluding them due to the cached dependencies this was leaning on. Running serverless requirements cleanCache if I make any requirements.txt changes has helped thus far. It does take a lot longer to run deployment but it has solved my issue thus far. Thanks @GarrisonD !!!
I hope this information helps someone save time. Time wasted: 11 hours. (Mostly waiting on serverless deploy to do its thing.)
This was my exact error
`

[ERROR] PackageNotFoundError: No package metadata was found for openaiTraceback (most recent call last):  File "/var/task/serverless_sdk/__init__.py", line 144, in wrapped_handler    return user_handler(event, context)  File "/var/task/lib/handler.py", line 236, in main    chat = ChatOpenAI(  File "/var/task/langchain/load/serializable.py", line 97, in __init__    super().__init__(**kwargs)  File "pydantic/main.py", line 339, in pydantic.main.BaseModel.__init__    values, fields_set, validation_error = validate_model(__pydantic_self__.__class__, data)  File "pydantic/main.py", line 1102, in pydantic.main.validate_model    values = validator(cls_, values)  File "/var/task/langchain/chat_models/openai.py", line 298, in validate_environment    if is_openai_v1():  File "/var/task/langchain/utils/openai.py", line 9, in is_openai_v1    _version = parse(version("openai"))  File "/var/lang/lib/python3.10/importlib/metadata/__init__.py", line 996, in version    return distribution(distribution_name).version  File "/var/lang/lib/python3.10/importlib/metadata/__init__.py", line 969, in distribution    return Distribution.from_name(distribution_name)  File "/var/lang/lib/python3.10/importlib/metadata/__init__.py", line 548, in from_name    raise PackageNotFoundError(name) | [ERROR] PackageNotFoundError: No package metadata was found for openai Traceback (most recent call last):   File "/var/task/serverless_sdk/__init__.py", line 144, in wrapped_handler     return user_handler(event, context)   File "/var/task/lib/handler.py", line 236, in main     chat = ChatOpenAI(   File "/var/task/langchain/load/serializable.py", line 97, in __init__     super().__init__(**kwargs)   File "pydantic/main.py", line 339, in pydantic.main.BaseModel.__init__     values, fields_set, validation_error = validate_model(__pydantic_self__.__class__, data)   File "pydantic/main.py", line 1102, in pydantic.main.validate_model     values = validator(cls_, values)   File "/var/task/langchain/chat_models/openai.py", line 298, in validate_environment     if is_openai_v1():   File "/var/task/langchain/utils/openai.py", line 9, in is_openai_v1     _version = parse(version("openai"))   File "/var/lang/lib/python3.10/importlib/metadata/__init__.py", line 996, in version     return distribution(distribution_name).version   File "/var/lang/lib/python3.10/importlib/metadata/__init__.py", line 969, in distribution     return Distribution.from_name(distribution_name)   File "/var/lang/lib/python3.10/importlib/metadata/__init__.py", line 548, in from_name     raise PackageNotFoundError(name)
-- | --

`

Thanks for pointing out this solution @ralliart2004. This configuration solve the error "No package metadata was found for openai"
pythonRequirements:
useDownloadCache: false
useStaticCache: false
slim: true
slimPatternsAppendDefaults: false
slimPatterns:
- '/*.py[c|o]'
- '/pycache*'


MSID: 87423 Version: 1 DOI: 729491

[PLACE MANUSCRIPT AND EDITOR DETAILS HERE WHEN AVAILABLE] See step 3
[PLACE PDF URL HERE WHEN AVAILABLE] See step 7
Step 1. Inform bioRxiv
Who can help: @QueenKraken, @nlisgo, @scottaubrey

[x] Manuscript is in data hub index (https://data-hub-api.elifesciences.org/enhanced-preprints/docmaps/v2/by-publisher/elife/get-by-manuscript-id?manuscript_id=87423)

Step 2. Create preview of manuscript
Who can help: @fred-atherden, @nlisgo, @scottaubrey

[ ] Manuscript is available for preview (https://prod--epp.elifesciences.org/preview/87423/v1)

[ ] Trigger import for staging: https://prod--epp.elifesciences.org/import
[ ] Sync data folder with s3://prod-elife-epp-data/data
[ ] Trigger import for staging: https://staging--epp.elifesciences.org/import
[ ] Sync data folder with s3://staging-elife-epp-data/data
[ ] Pull request created to enhanced-preprint-data
[ ] Post link to pull request below

Pull request: [PLACE LINK TO PULL REQUEST HERE]
Detailed instructions: https://github.com/elifesciences/enhanced-preprints-data#add-a-manuscript
Step 3: Awaiting public reviews and QC
Who can help: Production team

[ ] QC passed or QC not needed

Who can help: Editorial team

[ ] Public reviews available on sciety (https://sciety.org/articles/activity/10.1101/729491)
[ ] Manuscript and editor details at the top of this issue (Supplied by Editorial team)
[ ] Reviews returned by EPP - https://prod--epp.elifesciences.org/api/reviewed-preprints/87423/v1/reviews

Example
"msas": "Genetics and Genomics", "Neuroscience"
"msid": "84628"
"version": "1"
"preprintDoi": "10.1101/2<IP_ADDRESS>4241"
"articleType": "Reviewed Preprint"
"status": "Published from the original preprint after peer review and assessment by eLife."

"Reviewed Preprint posted": "2023-01-02"
"Sent for peer review": "2022-10-28"
"Posted to bioRxiv": "2022-11-21" (link: "Go to bioRxiv": "https://www.biorxiv.org/content/10.1101/2<IP_ADDRESS>4241v1")

Editors:
Reviewing Editor
Michael B Eisen
University of California, Berkeley, United States
Senior Editor
Michael B Eisen
University of California, Berkeley, United States

Step 4: Modify manuscripts.json (no PDF)

[ ] Reviewed preprint is published to EPP (https://elifesciences.org/reviewed-preprints/87423)

[ ] Pull request created to enhanced-preprint-client
[ ] Pull request switched to "Ready for review"
[ ] Post link to pull request below

[ ] Request that a doi be registered

[ ] Post link to #enhanced-preprint comment below

Pull request: [PLACE LINK TO PULL REQUEST HERE]
#enhanced-preprint comment thread: [PLACE LINK TO COMMENT HERE]

Instructions to modify manuscripts.json

Visit: https://github.com/elifesciences/enhanced-preprints-client/actions/workflows/publish-manuscript.yaml
Click: Run workflow
Complete the form and click "Run workflow"
A successful run should result in a new pull request at https://github.com/elifesciences/enhanced-preprints-client/pulls
Open the pull request and click the "Ready for review" button to trigger tests
Once the tests pass and you are happy with the changes the PR can be merged

Example pull request: https://github.com/elifesciences/enhanced-preprints-client/pull/334/files
Once the pull request is merged in it should be available a few minutes later.

Request that a doi
Post the following in #enhanced-preprint:
@Fred can you register a doi for https://elifesciences.org/reviewed-preprints/87423

Step 5: Awaiting search reindex

[ ] Reviewed preprint is avaliable on journal homepage (https://elifesciences.org)

The search reindex is triggered once an hour. We need the reviewed preprint to be indexed as the search application serves the journal homepage.

Additional info
If needed, the jenkins pipeline to reindex search can be triggered sooner.
https://alfred.elifesciences.org/job/process/job/process-reindex-reviewed-preprints/

Step 6: Published! Request PDF generation

[ ] Post the link to the PDF url at the top of the issue

[ ] Post link to #enhanced-preprint comment below

#enhanced-preprint comment thread: [PLACE LINK TO COMMENT HERE]
Post the following to the #enhanced-preprint on slack:
@Ryan Dix-Peek please can you generate a PDF for https://elifesciences.org/reviewed-preprints/87423

Step 7: Introduce PDF to data folder and git repo

[ ] PDF is avaliable at https://github.com/elifesciences/enhanced-preprints-data/raw/master/data/87423/v1/87423-v1.pdf

Detailed instructions: https://github.com/elifesciences/enhanced-preprints-data#add-a-pdf
Step 8: Add PDF url to manuscripts.json

[ ] Reviewed preprint PDF is available for download (https://prod--epp.elifesciences.org/reviewed-preprints/87423)

[ ] Pull request created to enhanced-preprint-client
[ ] Pull request switched to "Ready for review"
[ ] Post link to pull request below

[PLACE LINK TO PULL REQUEST HERE]

Instructions to add PDF url to manuscripts.json

Visit: https://github.com/elifesciences/enhanced-preprints-client/actions/workflows/add-pdf-url-to-manuscript.yaml
Click: Run workflow
Complete the form and click "Run workflow"
A successful run should result in a new pull request at https://github.com/elifesciences/enhanced-preprints-client/pulls
Open the pull request and click the "Ready for review" button to trigger tests
Once the tests pass and you are happy with the changes the PR can be merged

Example pull request: https://github.com/elifesciences/enhanced-preprints-client/pull/397/files
Once the pull request is merged in it should be available a few minutes later.

Step 9: Done!

[ ] Kettle is on!

@acollings just want to double check with this one - the preprint was published in 2020. Are the authors likely to update it prior to posting the reviews or is this the version they want?

Hi @fred-atherden it does look like a mistake (thanks for checking), but amazingly this is correct. Let's use the preprint from 2020.

Good to know, thanks Andy.


feat: responsive config for group widgets

Description

Added auto layout configuration for checkbox, switch & radio group widgets.

Add a TL;DR when description is extra long (helps content team)

Fixes #20598

if no issue exists, please create an issue and ask the maintainers about this first

Media

A video or a GIF is preferred. when using Loom, don’t embed because it looks like it’s a GIF. instead, just link to the video

Type of change

Please delete options that are not relevant.

New feature (non-breaking change which adds functionality)

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions, so we can reproduce.
Please also list any relevant details for your test configuration.
Delete anything that is not important

Manual

Test Plan

Add Testsmith test cases links that relate to this PR

Issues raised during DP testing

Link issues raised during DP testing for better visiblity and tracking (copy link from comments dropped on this PR)

Checklist:
Dev activity

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] PR is being merged under a feature flag

QA activity:

[ ] Test plan has been approved by relevant developers
[ ] Test plan has been peer reviewed by QA
[ ] Cypress test cases have been added and approved by either SDET or manual QA
[ ] Organized project review call with relevant stakeholders after Round 1/2 of QA
[ ] Added Test Plan Approved label after reveiwing all Cypress test

Some issues when resizing the group widgets - https://github.com/appsmithorg/appsmith/issues/20676


Uses CUDA 10, PyTorch 1.0.1

Updates to latest cuda and pytorch. Need to test this on my personal gpu rig first; do not merge yet.
:rainbow: :unicorn:

Disclaimer: I'm looking into this for my personal side projects; I don't have write permissions any longer.

At me if you need a merge or anything else short-term @daniel-j-h.

@daniel-j-h
Glad to see you're somehow back on the project :)
Let me know if there's any way to merge again RoboSat.pink and RoboSat in a single project.

@jacquestardie please merge


Microsoft.FeatureManagement documentation link is broken (returns a 404)

The link at the bottom of the article is broken [Microsoft.FeatureManagement documentation]
(https://learn.microsoft.com/en-us/dotnet/api/microsoft.featuremanagement)
It returns a 404.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: fa18f095-325a-628d-9c05-551c09f7392e
Version Independent ID: 5db3af04-a314-24fd-6202-772aaa62a28d
Content: Tutorial for using feature flags in a .NET Core app
Content Source: articles/azure-app-configuration/use-feature-flags-dotnet-core.md
Service: azure-app-configuration
GitHub Login: @maud-lv
Microsoft Alias: malev

Thank you for your feedback! We will review and update as appropriate.

Thank you for bringing this to our attention @arondoss.
@Muksvso, could you please check if FeatureManagement-Dotnet is the correct link or if there's more appropriate one?

The link has been fixed. #please-close


Improve navigation - Closes #1437

Closes #1437

I think font and alignment on the selected sidebar is different from the design.

the font size and weight should be the same
alignment of the letter should not change

the border style / top bar style is different from the design, but is this aligned with @ann-vashchenko ?

I think as per design, selected link shouldn't have blue background?

Yes I think it should, the desired design is also displayed in the issue description #1437

Ah sorry, it is correct it should have background blue.
The  design wise, it should be the whole raw (but i think it would be difficult?). If so, I think it should have some padding on left so the letter is not sticked to the left boarder (maybe discuss with @ann-vashchenko

Yes, I think it would make it more difficult to have the background color the whole row. Some small padding would be the easier solution. Maybe we can go for the easy solution now, and then request Annas review? If she has any objections, she can include it there.

Hi @Tschakki @shuse2 What do you think if the active item will look like this?


⚠ Bofrost.de has degraded performance

In 676936d, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1652 ms

Resolved: Bofrost.de performance has improved in e491eb9 after 8 minutes.


Meeting information not in expected location

The README says:

Meeting dial-in details, meeting notes and agendas are announced and published to the open-cluster-management mailing list on Google Groups

...but there's no information in the google group; the meeting details appear to be on the project board instead. Update the README? Or post to the mailing list?

Apologies we were late in posting this:  https://groups.google.com/g/open-cluster-management

google group and meeting info is now being posted.


highlights.scm: @boolean -> @constant.builtin.boolean, @repeat -> @keyword.control.repeat

:wave: I'm trying to clean up some of the themes in helix, noticed https://github.com/helix-editor/helix/blob/master/runtime/queries/lean/highlights.scm is the only highlight query using @boolean, everything else uses @constant.builtin.boolean.
The benefit of this is that a helix theme or treesitter color config which defines @constant or @constant.builtin will also apply.
I also notice there is a @repeat, which might make sense as @keyword.control.repeat, unless it's a @function.builtin.
I'm hoping to update https://docs.helix-editor.com/themes.html to something for all treesitter syntax highlighting queries, so I'll probably be back with doc about that ;-)

Hi there! Thanks for the issue.
I'm not sure @constant.builtin.boolean works in neovim -- are you sure it does? At least according to :h treesitter-highlight-groups the examples show @constant.builtin but for boolean they show @boolean.
On the other hand, work on tree-sitter-lean is effectively stalled (on the grammar being too big to use) which means I basically am not actively working on any of those queries unfortunately...

Wow, https://neovim.io/doc/user/treesitter.html#treesitter-highlight really doesn't align with the highlight.scm files over in https://github.com/tree-sitter.
For example, https://github.com/tree-sitter/tree-sitter-ruby/blob/master/queries/highlights.scm uses @function.method not @method, @variable.parameter not @parameter. Clearly I am missing some magic here, I'll dig in. Thanks for the reference, that's really useful.

BTW, I'm absolutely planning on providing the patch, just wanted to talk before I threw something over the wall. Thanks for the quick feedback.

Closing this given the above, but yeah if there's something here that can help and that also is correct for nvim, obviously happy to merge a PR, just unlikely to look at doing this myself unless tree-sitter-lean becomes viable again! Appreciated though.


Remove the need for registering an ObjectStore for remote files

Is your feature request related to a problem or challenge? Please describe what you are trying to do.
Currently, we need to register an ObjectStore to register remote files stored in S3, https, etc. This could be more ergonomic from a DX perspective.
Describe the solution you'd like
Automatically detect if an ObjectStore is needed, like in the datafusion-cli; see here.
Describe alternatives you've considered
keep it as it is now
Additional context
We should increase the test coverage for ObjectStore

Just like delta-rs, polars etc  we should just take the objectstore from the  uri and then parse the storage options either as parameter or env variables

Related, though not yet on crates.io: https://github.com/developmentseed/object-store-rs

Related, though not yet on crates.io: developmentseed/object-store-rs

I'd be happy to work with you to use this! Indeed this is the explicit goal of pyo3-object_store, to define the Python builders for ObjectStore once and then reuse them for multiple projects.


Managing Foreign Key Relationship without Managing Schema in Atlas

I am currently using Supabase and have a column with a foreign key constraint on the auth.users table. Here is an example of the foreign key definition in Atlas:
foreign_key "fk_uid" {
  columns     = [column.uid]
  ref_columns = [table.users.column.id]
  on_update   = NO_ACTION
  on_delete   = NO_ACTION
}

However, I do not want to manage the auth schema in Atlas, as it is handled separately by Supabase. Is there a way to reference the auth.users table without managing its schema in Atlas?
Expected Behavior:
I would like to maintain the foreign key relationship with the auth.users table without having to manage its schema in Atlas. Ideally, the foreign key constraint should still be enforced and any changes made to the auth.users table should reflect in the referencing table.

Hey @srossross I've made a PoC with Atlas + Supabase which uses the auth.user_id foreign key in the public schema:
https://github.com/fenos/supabase-atlas-migrations/tree/main
The trick is to instrospect the auth schema with atlas, which will generate the HCL
Then run atlas migrate diff to generate the sql migration
When you are ready to apply pass --baseline=<version> flag to the atlas migrate command with the version equal to the just generated sql

I have faced exactly the same issue and I guess it exist in any ORM/migration management software. Initially I was trying to use Prisma to manage my DB schema, but as my public.profiles table referenced the auth.users.id field I was getting the same error.
The problem here, as I see it, is that Atlas (and any other tool) assumes that it has full control over the database and over all the tables/schemes. So such tools relay on the assumption that all schemes/tables are specified in the definition file and other parts of the DB is empty. It seems there is no way to define 'stale' reference in the definition file, because it's assumed that this file defines everything in the database.
And the other problem is how to represent these 'dummy' references in the "shadow/dev database" (which is created purely from schema.hcl and this "external" referenced field (or trigger/function/etc.) indeed does not exist
One of the possible solutions I can imagine (except adding all supabase's tables like realtime, storage, auth to schema.hcl) is to add special compiler/executor pragma that will exclude the 'stale' references from the DB-to-Schema.hcl difference calculations and will add them directly to the migration files.
(but this approach also is not perfect as it seems that such references will be added to every migration sql as it's not tracked in shadow/dev database) 🫠

Ou, one of the interesting solutions that just came to my mind is to provide CLI/Configuration option to specify the SQL file with the baseline for shadow database. So it will be created not from scratch, but will already have some definitions and will sync with the existing schema in real DB. Moreover, this will solve the issue of creating 'dangling' references, as such references will exist inside dev DB and will be generated as normal SQL
Any ideas on the proposal?

I've been trying to figure this out as well. The baseline functionality in the dev docker image doesn't work for this with Supabase's image, because while that keeps it from stepping on the Supabase-provisioned tables, it means that it's then impossible to reference those tables.
I'm wondering if a short term solution here could be to add a sql() escape hatch like there is for types, like:
trigger "do_a_thing_on_preexisting_table" {
  on = sql("\"fully_qualified\".\"table_name\"")
  ...
}

Any chance this will happen sometime? It's still a necessary prerequisite to make non-toy use of baseline, which as-is is kind of pointless outside of installing extensions.

Hey! There is currently no way to reference external tables in HCL when defining foreign-keys. However, the current workaround is to define the HCL schema without the foreign key and then extend the schema using an SQL file that creates it. Then, compose one desired schema using the composite_schema data-source and pass it to Atlas.
data "composite_schema" "project" {
  schema "public" {
    url = "file://path/to/schema.hcl"
  }
  schema "public" {
    url = "file://path/to/schema.sql"
  }
}

env "dev" {
  src = data.composite_schema.project.url
  dev = "docker://postgres/15/dev"
}


Fix the issue of calling Async::Container::Forked with the wrong number of arguments.

Coverage increased (+1.0%) to 80.0% when pulling 084cfc91736b9cf6a68f6f6a7292a5df0a3ad2c5 on huba:master into e3a848f73cefd9816508e08c23b64fec45d59306 on socketry:master.

Here is a simple solution. Use fork directly.
As in:
pid = fork do
    # server code
end

And for stop
Process.kill(:TERM, pid)

I made a quick hack to fix this.... but need to do something better.


Update defaults and docs to latest stable OCP version

Signed-off-by: Yussuf Shaikh<EMAIL_ADDRESS>

/cc @Prajyot-Parab @cs-zhang

New changes are detected. LGTM label has been removed.

Sorry I accidentally pushed another commit to this PR. @Prajyot-Parab please help with your approval again.