Refactor Jenkins CI

Move scripts in macros.yaml to separate shell files in order to ensure maintainability.
run-k8s-e2e-test.sh: Move KUBE_CONFORMANCE_IMAGE_VERSION initialization before _usage. Otherwise, this var is unset.
Set kube conformance image version from v1.18.0-beta.1 to v1.18.5.
sonobuoy: v0.17.2 -> v0.18.5

Fixed: #768

Codecov Report

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

@@             Coverage Diff             @@
##           master    #1240       +/-   ##
===========================================
- Coverage   56.06%   42.58%   -13.49%
===========================================
  Files         108       76       -32
  Lines       11887    10917      -970
===========================================
- Hits         6665     4649     -2016
- Misses       4634     5898     +1264
+ Partials      588      370      -218

Flag
Coverage Δ

#integration-tests
?

#unit-tests
42.58% <ø> (+0.34%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

 So that the issue gets closed when you merge this.

/skip-hw-offload

@lzhecheng please also mention in the commit message and PR description that we are updating the kube conformance image version (from v1.18.0-beta.1 to auto).

@antoninbas , I verified on Jenkins today. "auto" as k8s-conformance-image won't work for networkpolicy testcases. It failed at "[sig-network] NetworkPolicy [LinuxOnly] NetworkPolicy between server and client [It] should allow ingress access from updated pod [Feature:NetworkPolicy]". I tried on a private testbed and it worked.
"auto" means to be set to cluster's version. So if user's cluster is at an old version, with sonobuoy, flaws in upstream code could lead to testcase failure. I guess failure is related with testbed setup.
Then I set k8s-conformance-image to v1.18.5 and sonobuoy to v0.18.5 and it works for CI. I could continue investigating the failure.

@lzhecheng Thinking about it some more, it's probably better to have a static version there anyway, so we know exactly which versions of the tests we are running. We just have to remember to update it regularly.

@lzhecheng Thinking about it some more, it's probably better to have a static version there anyway, so we know exactly which versions of the tests we are running. We just have to remember to update it regularly.

Makes sense. Thanks!.
/skip-all

VMC Jenkins VMs are at kubernetes v1.17.3, so the kube-conformance-image-version: "auto" leads to old conformance image.


Kafka 6906: Fixed Kafka Streams to commit transactions if data is produced via wall-clock punctuation.

https://issues.apache.org/jira/browse/KAFKA-6906
Fixed Class : StreamTask  to commit transactions if data is produced via wall-clock punctuation.
More detailed description of your change,
if necessary. The PR title and PR message become
the squashed commit message, so use a separate
comment to ping reviewers.
Summary of testing strategy (including rationale)
for the feature or bug fix. Unit and/or integration
tests are expected for any behaviour change and
system tests should be considered for larger changes.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

retest this please

Closing this pull as part of the requirement dependent on KIP-211 is moved to other Jira.


du: add --one-file-system

From original GNU du:
  -x, --one-file-system    skip directories on different file systems

Two directories are considered in the same file system if they have the same device id.

I guess it is hard to test but it would be nice to have at least the option set in a test

There's a segfault, not sure why.

Doesn't seem to be your fault, I'll try to rerun the CI. Unrelated: could you take a loop at the clippy lints for this PR?

Probably I'll make another PR for the clippy warning.
I believe the failing test isn't related to du.


python_history

This can be a suggestion-
https://unix.stackexchange.com/questions/630642/change-location-of-python-history

This seems very complicated at first glance, I'll have to look at it later.

Added in d6e4de0e68920c57779361f6983f884ef2e8d9e6.

I think this solution is incomplete. ~/.python_history is still created since the hook to write to ~/.python_history isn't removed / disabled. I wrote a more complete solution in this answer (on the same post linked above): https://unix.stackexchange.com/a/747364/321263


examples/principal benchmarks

Re-write the example at examples/principals in Rust/Motoko and generate corresponding benchmarks.

[ ] Rust
[ ] Motoko
[ ] Azle
[ ] Benchmarks

Our benchmarking strategy is now to use the DFINITY benchmarking repo and flamegraphs, or wait for an API that allows us to benchmark canister projects without changing their source code.


But I had very similar comments to @Vielheim


Gamification

bugfixes and other improvements

Nice to see that you're working on gamification :)

We've been working on it for a while :). Please let us know what you think.
On Wed, May 4, 2016 at 9:37 PM Manuel Martín<EMAIL_ADDRESS>wrote:

Nice to see that you're working on gamification :)
—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub
https://github.com/openml/website/pull/47#issuecomment-216977468

Is there any demo server I can check?

Nevermind, I just found this: http://www.openml.org/guide#!gamification
Wow, great work guys. I really like the new changes, now it makes me want to achieve those badges! :)
And sorry, I know a commit is not the place for these types of comments :)


Validating array of objects reading one at a time.

Hello,
I need to deserialize a very large array of objects one at a time, while validating both the entire body and each object.  I am having trouble with validating the entire body.  For example, if I exclude the end array brace from my JSON the code I have written does not pick up on that validation error.
Please let me know what is the best approach for doing this.  Below is sample code and JSON.  Do I have to do this manually or am I missing a technique where JSON.NET can do this for me in this approach.
Here is sample good JSON:
[
   {
      "Body":"{\"Data\":\"123\",\"Timestamp\":\"2015-01-01T05:00:00Z\"}",
      "IsBodyBase64":false,
      "BrokerProperties":null,
      "UserProperties":{
         "DSP-Type":"TimestampedEventSeries",
         "DSP-Id":"ca9aa96a-5ffc-4177-af09-283180183fac"
      }
   },
   {
      "Body":"{\"Data\":\"456\",\"Timestamp\":\"2015-01-02T05:00:00Z\"}",
      "IsBodyBase64":false,
      "BrokerProperties":null,
      "UserProperties":{
         "DSP-Type":"TimestampedEventSeries",
         "DSP-Id":"ca9aa96a-5ffc-4177-af09-283180183fac"
      }
]

Here is sample bad JSON (missing end array brace) that generates no errors:
[
   {
      "Body":"{\"Data\":\"123\",\"Timestamp\":\"2015-01-01T05:00:00Z\"}",
      "IsBodyBase64":false,
      "BrokerProperties":null,
      "UserProperties":{
         "DSP-Type":"TimestampedEventSeries",
         "DSP-Id":"ca9aa96a-5ffc-4177-af09-283180183fac"
      }
   },
   {
      "Body":"{\"Data\":\"456\",\"Timestamp\":\"2015-01-02T05:00:00Z\"}",
      "IsBodyBase64":false,
      "BrokerProperties":null,
      "UserProperties":{
         "DSP-Type":"TimestampedEventSeries",
         "DSP-Id":"ca9aa96a-5ffc-4177-af09-283180183fac"
      }

Here is my sample DTO:
    public class HttpBrokeredMessage
    {
        public string Body { get; set; }
        public Dictionary<string, object> BrokerProperties { get; set; }
        public bool IsBodyBase64 { get; set; }
        public Dictionary<string, object> UserProperties { get; set; }
    }

Here is my sample Program:
    class Program
    {
        static void Main(string[] args)
        {
            var list = DeserializeMany<HttpBrokeredMessage>(Properties.Settings.Default.JsonBad);

            try
            {
                if (list != null)
                {
                    foreach (var body in list)
                    {
                        Console.WriteLine(body.Body);
                    }
                }
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.Message);
            }

            Console.WriteLine("Done");
            Console.ReadLine();
        }

        public static IEnumerable<TObject> DeserializeMany<TObject>(string val) where TObject : class
        {
            var serializer = new Newtonsoft.Json.JsonSerializer();

            using (var streamReader = new StringReader(val))
            {
                using (var jsonReader = new JsonTextReader(streamReader))
                {
                    using (var validatingReader = new JSchemaValidatingReader(jsonReader))
                    {
                        var generator = new JSchemaGenerator();

                        validatingReader.Schema = generator.Generate(typeof(TObject[]));
                        validatingReader.ValidationEventHandler += (o, error) => Console.WriteLine(error.Message);

                        while (validatingReader.Read())
                        {
                            if (validatingReader.TokenType == JsonToken.StartObject)
                            {
                                var result = serializer.Deserialize<TObject>(validatingReader);

                                yield return result;
                            }
                        }
                    }
                }
            }
        }
    }

Since you're manually reading from a JsonTextReader then you'll need to manually need to check that the last token is a JsonToken.EndArray

I tested your code out and I get an error when the second objects trailing curly brace is missing:
Unexpected end when deserializing object. Path '[1].UserProperties', line 18, position 7.
You will need to check for the trailing square brace yourself since you're manually reading from a JsonTextReader.

Thanks, I got the same as well, and that works as expected since I am calling the serialized for those objects.  As you said, for any json formatting surrounding the objects in the array I'll have to validate that manually.


add bulk action capability to GUI storage objects

Right now, each storage object has its own actions: 'edit', 'download', 'delete'
Bulk actions are not possible, such that if a user wants to delete a lot of items, she needs to do it one by one.
It would be great if the GUI were to support to 'download' and 'delete' operations in bulk.

@abeckn , how feasible is this?

Definitely feasible. I have to take a look at how to handle this with our current pagination approach, but it would look like in the screenshot below.

That looks good, thanks!
Regarding pagination, I think even bulk actions for a single page would be useful.
The pagination already works when a single item is deleted, so that the first item from the next page is already pulled to that first page. Hopefully, it will be the case when multiple items are deleted as well.

Gentle ping @abeckn.

The private storage as well as CRDTs are now visible via the GUI. This might need to be reflected on the solution here as well.


SimDem 2 Brain Dump: pexpect vs subprocess

This issue is to document an experiment I tried recently and possibly get suggestions for an alternative.
Pexpect doesn't let you run commands which take over the terminal.  (For example, running vi)  This is frustrating as that limits runnable commands that promote interactivity.
I experimented with Python's Subprocess and was hopeful, but ultimately it did not meet the needs.
python3
>>> import subprocess
>>> subprocess.call('vi /tmp/foo', shell=True)

Opens up VI session!  Great!  However, I could not find a way to keep the session open.  If I set an environment variable, then the next time I ran subprocess.call(), the env var was gone.
I'm hoping to be proven wrong, and would like to explore further, but this is the limitation I hit.  I tried using lower-level calls, such as communicate(), but could not make progress.
https://docs.python.org/3/library/subprocess.html#subprocess.Popen.communicate
Essentially subprocess lets you run a single command; however, I could not find a way to keep the session alive, as it appears to close upon hitting an EOF.  And once you called communicate(), the session was closed.

I always avoided commands that required human interaction. How can we automate that in a demo / test scenario? insteead I've used template files, environment variables and text processing to create necessary files in an automated way. This has the added advantage of forcing the author to provide template files with tokens for replacement.
But, to your question about subprocess. Originally I used Subprocess. One of the reasons I moved away was because, exactly as you say, it does not preserve the environment.

Ok, darn.  I was hoping you might have some magical insight that I missed.
Closing this point since we're on the right path.


Fix fallbackLng if namespaces are undefined

Fixes #1941
I did not understand why the existsSync mock returns false on the first call for all test cases in serversideTranslations.tests.tsx. Maybe it is related to #1302 and therefore obsolete? I have changed it to always return true, but since this change effects all tests, I'm not sure if this is the intended behaviour.
Additionally, it might make sense to "enable" server-side environment for all tests with something like
 beforeAll(() => {
      Object.assign(process, { browser: false })
      delete (global as any).window
    })

as is already the case for createConfig.tests.tsx. Currently createConfig is running in "client.side mode", which may not be the desired behavior for testing getServerSideTranslations? If this sounds reasonable to you @adrai, I can add changes to this PR or open another one - whichever you prefer.
Checklist

[x] only relevant code is changed (make a diff before you submit the PR)
[x] run tests npm run test
[x] tests are included
[x] commit message and code follows the Developer's Certification of Origin

yes, sounds reasonable... just do it here no problem @chrilis

Thank you @chrilis, it's included in v12.0.1


Interleave logs from multiple sources

Feature request to render logs sorted by timestamp, useful when inputs correspond to different services.

For the record, some earlier work/discussion is at https://github.com/trentm/go-ecslog/pull/14

I think this should be the default behaviour when it is ready, possibly with an option to turn off that sorting.


Add TxCount Table for Transaction to Block mapping

Describe the feature
we need a way to go from Transaction to Block which is currently not possible.
https://github.com/paradigmxyz/reth/pull/1664#discussion_r1131843464
suggests to add a new table for tx count to block number
Additional context
No response

To note here.
It shouldn't be the Count as the index is going to be different. We are modellin ranged here, and we want the TxNumber of the last transaction to be tied to the block num, so that this transaction is in the inclusive range.
TransactionBlock is probably a better name to show intention.
And blocks that don't have transactions should not be inserted.


t_blockCode test failure again with ICU 74

This is a reprise of

#94

Happens on macOS with ICU 74:
https://github.com/haskell/text-icu/actions/runs/8943327460/job/24567789387#step:12:636
t_blockCode: [Failed]
*** Failed! (after 25 tests):
Exception:
  toEnum{BlockCode}: tag (328) is outside of enumeration's range (0,327)
  CallStack (from HasCallStack):
    error, called at Data/Text/ICU/Char.hsc:495:17 in text-icu-<IP_ADDRESS>-FtrCGOmY2PD7vvbWpyQUDD:Data.Text.ICU.Char
'\191897'

Update: also fails on Windows with ICU 74.2:
https://github.com/haskell/text-icu/actions/runs/8943757763/job/24569171067#step:11:26
*** Failed! (after 13 tests):
Exception:
  toEnum{BlockCode}: tag (328) is outside of enumeration's range (0,327)
  CallStack (from HasCallStack):
    error, called at Data\Text\ICU\Char.hsc:495:17 in text-icu-<IP_ADDRESS>-inplace:Data.Text.ICU.Char
'\191528'

I'm afraid I don't have capacity to fix it now. But I would gladly accept a PR and publish a new text-icu version on Hackage. PR should be similar to the changes in #94.

Another instance (Windows): https://github.com/haskell/text-icu/actions/runs/9086457145/job/24972179956#step:11:26
*** Failed! (after 39 tests):
Exception:
  toEnum{BlockCode}: tag (328) is outside of enumeration's range (0,3[27](https://github.com/haskell/text-icu/actions/runs/9086457145/job/24972179956#step:11:28))
  CallStack (from HasCallStack):
    error, called at Data\Text\ICU\Char.hsc:495:17 in text-icu-<IP_ADDRESS>-inplace:Data.Text.ICU.Char
'\191620'
(used seed<PHONE_NUMBER>214507154)


Formatting cleanups for README [skip ci]

Fixed capitalization: JsonNet -> Jsonnet
Added language directive for syntax highlighting code snippets
Removed extra indent whitespace around code samples for readability
Minor wording changes for readability
Added link to Jsonnet homepage for more info

Thanks for formatting

@Neeke — thanks for merging my PR!
Could you please also fix the capitalization of "Jsonnet" on other related pages, e.g.,

https://pecl.php.net/package/jsonnet

so that it's not confused for Json.NET which is a .NET library for parsing JSON? Thanks again for developing this module!

@mbrukman
The 'Summary' and 'Description' of https://pecl.php.net/package/jsonnet is all ready fixed to "Jsonnet".
But the packages released before 1.3.1 can not reformat name because it's could not to renamed.


Remove LEAPP_DEVEL_SKIP_RHSM from docs

It has been replaced with a supported --no-rhsm option.

Can one of the admins verify this patch?

Actually it's not correct. There is --no-rhsm option, and LEAPP_NO_RHSM envar which people could use as well. So it should be documented as well.

It is missing also the overlay image size variable. And the link to the best practices is incorrect.


CondaForge.Miniforge3 v:24.3.0-0 upgrade fix

This fix done at version 23.3.1-0 but I removed that accidentally, so I am adding it again.
Checklist for Pull Requests

[x] Have you signed the Contributor License Agreement?
[ ] Is there a linked Issue?

Manifests

[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?

[x] Does your manifest conform to the 1.6 schema?

Note: <path> is the directory's name containing the manifest you're submitting.


Add convenience methods to simplify request parameter construction

Are there any future plans to add convenience interface for standard classes (i.e. Core Data Supported Types) when using the following API call:
public func appendBodyPart(#data: NSData, name: String)

At this time, I find myself having to do the following:
var numberType = NSNumber(longLong: 2)
let numberData = NSData(bytes: &numberType, length: sizeof(Int64))

var stringType = "This is a test"
stringType.dataUsingEncoding(NSUTF8StringEncoding)

// or

let stringData = NSData(bytes: &stringType, length: sizeof(String))

var dateType = NSDate()
let dateData = NSData(bytes: &dateType, length: sizeof(NSDate))

I'm using an existing API where I need to pass anywhere from 5 - 9 parameters depending on the API call.  Thus, I was thinking that it could be something similar to the following:
public func appendBodyPart(#data: String, name: String)
public func appendBodyPart(#data: NSDate, name: String)
public func appendBodyPart(#data: NSNumber, name: String)
public func appendBodyPart(#data: NSDecimalNumber, name: String)
...

Hi @conradwt, thanks for your question and feedback!
At the moment, I think this is something that we should not support. The reason being that there are just too many assumptions that need to be made to write these types of "convenience" methods.

How do we know which NSStringEncoding to use?
How do we know which type of NSDate formatter you want to use?

Because of this ambiguity, I think it's best to leave these types of methods out of Alamofire. IMO, they should instead be created as extensions on the MultipartFormData class that internally creates the encoded data that you need, then calls the appropriate Alamofire method.
Does that make sense?


Shell for UNKNOWN_VIRTUAL_ENVIRONMENT already activated.

Issue description
When deactivating a virtual environment created by pipenv shell and then trying to reactivate it using pipenv shell, I receive the error:
Shell for UNKNOWN_VIRTUAL_ENVIRONMENT already activated.
New shell not activated to avoid nested environments.

However, running unset PIPENV_ACTIVE resolves the issue. Modifying the deactivate function in the virtual environment's activate script to include unset PIPENV_ACTIVE also works.
Expected result
The virtual environment should reactivate without errors when running pipenv shell after deactivating it.
Actual result
The error message is displayed, and the virtual environment is not reactivated.
Steps to replicate

Create and activate a virtual environment using pipenv shell.
Deactivate the environment using the deactivate command.
Attempt to reactivate the environment using pipenv shell.

System details

OS: Darwin Machinename.local 23.5.0 Darwin Kernel Version 23.5.0: Wed May  1 20:17:33 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6031 arm64
pyenv version: pyenv 2.4.7
pipenv version: pipenv, version 2024.0.1
Python version: Python 3.12.4

Additional information
To resolve the issue temporarily, adding unset PIPENV_ACTIVE to the deactivate function in the virtual environment's activate script works. However, this seems to be an issue with pipenv itself.
pipenv_support.md

Pipenv forks the shell and activates the virtualenv in the forked shell, so you can just exit the shell (e.g. by running exit or Ctrl+d) instead of calling deactivate.
If you still want to re-use the forked shell, you can use the --anyway flag for pipenv shell.
If we want to unset PIPENV_ACTIVE, we would need to modify the deactivate function which is generated by virtualenv in the activation scripts for each shell type. But I'm not sure if we should go with this solution.

Thank you for your response.
I will start using exit instead of deactivate from now on, but it seems the issue still persists. I appreciate the advice and hope a good solution can be found.
Thanks again for your help.

Issue #6220 Analysis and Proposed Resolution
1. Problem Summary:
The issue highlights a problem with reactivating a Pipenv-created virtual environment after it has been deactivated using the deactivate command. When attempting to reactivate using pipenv shell, users encounter an error stating:
Shell for UNKNOWN_VIRTUAL_ENVIRONMENT already activated.
New shell not activated to avoid nested environments.

This error occurs because the PIPENV_ACTIVE environment variable remains set even after deactivation, leading Pipenv to believe the environment is still active.
2. Comments Analysis:

Naofal-Helal correctly points out that Pipenv forks the shell and activates the virtual environment within that forked shell. Therefore, using exit to leave the forked shell is the recommended way to deactivate the environment. They also suggest using the --anyway flag with pipenv shell to force reactivation within the same shell. However, the user (bakemocho) confirms that the problem persists even when using exit.
Naofal-Helal raises a valid concern about modifying the deactivate function generated by virtualenv. This is because it would involve altering code outside Pipenv's control, potentially leading to unforeseen issues.

3. Proposed Resolution:
Given the nature of the problem and the comments, the best approach is to follow Naofal-Helal's suggestion of using the --anyway flag. However, we should improve the user experience by:

Clarifying the error message: The current error message is confusing, as the environment is not truly "active" in the original shell. A more accurate message would be:
    Pipenv environment for this project was previously activated in this shell.     Use the '--anyway' flag with 'pipenv shell' to reactivate.
Documenting the recommended workflow: The documentation should clearly state that exit is the preferred way to deactivate a Pipenv environment, and that --anyway should be used for reactivation within the same shell.

4. Code Changes:
a) Modify the error message in pipenv/environments.py:
def is_in_virtualenv():
	  #... (existing code) ...

	  return virtual_env and not (pipenv_active or ignore_virtualenvs)

# In pipenv/cli/command.py
class PipenvGroup(DYMMixin, Group):
	  # ... (existing code) ...

	  def handle_error(self, exc_type, exc_value, traceback):
	      # ... (existing code) ...
	      elif isinstance(exc_value, exceptions.VirtualenvActivationException):
	          # Modify the error message here
	          click.secho(
	              'Pipenv environment for this project was previously activated in this shell.\n'
	              "Use the '--anyway' flag with 'pipenv shell' to reactivate.",
	              fg="yellow",
	              err=True,
	          )

b) Update the documentation in docs/advanced.md:
Add a section that clearly describes the recommended workflow for activating and deactivating Pipenv environments:
## Activating and Deactivating Environments

Pipenv automatically activates the virtual environment when you use `pipenv shell`.
This creates a forked subshell where the environment is active. To deactivate the environment,
simply exit the subshell by typing `exit` or pressing Ctrl+D.

If you wish to reactivate the environment within the same shell, you can use the `--anyway` flag with `pipenv shell`:

```bash
pipenv shell --anyway

**5. Additional Steps:**

- **Testing:** The proposed changes should be thoroughly tested to ensure they address the issue without introducing regressions.
- **User Feedback:**  Monitor user feedback on the updated documentation and error message to gauge their effectiveness.

This resolution prioritizes user experience by providing clear guidance and a more informative error message, while avoiding potentially disruptive modifications to external code.


[Bug Report] When < el-form-item > and < el-select multiple size= "small"> are used together, the size attribute doesn't work.

Element UI version
2.9.1
OS/Browsers version
macpro10.14.5     Google Chrome74.0.3729.169
Vue version
2.6.10
Reproduction Link
https://codepen.io/vivianus/pen/KLJPdw
Steps to reproduce
https://codepen.io/vivianus/pen/KLJPdw
When < el-form-item > and < el-select multiple size= "small"> are used together, the size attribute doesn't work：

What is Expected?
the size attribute will work.
What is actually happening?
the size attribute doesn't seem to work.

Adding size = "small" to  is effective .  https://codepen.io/vivianus/pen/KLJPdw

Adding size = "small" to the el-form tag is effective.    https://codepen.io/vivianus/pen/KLJPdw


Fix everything that pylint points out

This closes #642.
This also closes #644.

I'm willing to ignore codecov/patch for this one.

I'm rebasing this on #684 to see what Codecov says.

codecov/patch is complaining mainly because utils/priv_key.py has no tests.

Now rebasing this on #690 to see what Codecov says.

Rebasing on #691 to see what Codecov says.

Rebasing on #698 to see what Codecov says.

This PR changes lots of error message strings, and some of them are harder to reach in CI (how to invoke a subprocess failure etc).  Pylint doesn't need to wait for that.


Add PTZ Camera Frame Automation

Request as curl of the ptz camera:
curl 'http://<IP_ADDRESS>/cgi-bin/ptzctrl.cgi?ptzcmd&poscall&11' \
  -H 'Content-Type: application/x-www-form-urlencoded;charset=utf-8' \
  -H 'Cookie: CGISESSION=zeFdsRYOsksdEcWymqvAmVMJeQQqURuj' \
  --compressed \
  --insecure

Here we want to detect the Frame and set it properly based on the Event:
11: Chair under Imam for Khutbah Translations
12: Zoomed Out Imam + Iqama
13: Imam Khutbah
14: Zoomed Out everything

E.g: Khutbah Translation Time: 11, Khutbah Time: 13

After a year in production doing the framing manually, the first version can be easy like this:
Everyday:

Fajr Time: 11
After Fajr Time (+45 minutes): 14

Friday:

12:00: 11
12:15: 13
13:00: 11
13:15: 13
14:00: 14

It does not look like the PTZ is secured so anyone can troll when connecting to the network, so hopefully before anyone reads this I will isolate the PTZ in its own subnet 🤣 🤣 🤣 🤣
Also the above is a fake IP, it's not even the correct one 🥵 OR IS IT?


Appears to crash immediately on the LG V10 H901

I tried an app using cwac-cam2 on an LG V10 H901 and it crashed immediately. Unfortunately I didn't have crash logging set up and the phone isn't mine, so i don't have any more information. If someone who has access to an LG V10 H901 (http://www.lg.com/us/cell-phones/lg-H901-Space-Black) could try it, that would be very helpful.

Well, I couldn't get either the demo or the demo-playground app to crash, though the demo app was not liking the rear-facing camera much. I moved this device to use the ClassicCameraEngine, which cleared up that issue. Unless somebody can give me a more concrete scenario, I will assume that this, or past bug fixes, has cleared up this problem.

Addressed in v0.5.11.


java.util.ConcurrentModificationException after testng upgrade to 7.0.0-beta3

TestNG Version
7.0.0-beta3
Expected behavior
all tests classes run successfully as with testng 16.4.3
Actual behavior
some test classes get skipped and in Jenkins console we see:
[testng] Exception in thread "TestNG-test=X-3" Exception in thread "TestNG-test=X-2" java.util.ConcurrentModificationException
[testng] 	at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1134)
[testng] 	at org.testng.internal.TestMethodWorker.invokeBeforeClassMethods(TestMethodWorker.java:162)
[testng] 	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:122)
[testng] 	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[testng] 	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[testng] 	at java.base/java.lang.Thread.run(Thread.java:834)
[testng] java.util.ConcurrentModificationException
[testng] 	at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1134)
[testng] 	at org.testng.internal.TestMethodWorker.invokeBeforeClassMethods(TestMethodWorker.java:162)
[testng] 	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:122)
[testng] 	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[testng] 	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[testng] 	at java.base/java.lang.Thread.run(Thread.java:834)
Test case sample
The testng xml looks like:

<test verbose="1" name="Access Google" annotations="JDK">
		<classes>
		<class name="PRIVATE.tests.Google"/>
		<class name="PRIVATE.tests.Google1"/>
		<class name="PRIVATE.tests.Google2"/>
		<class name="PRIVATE.tests.Google3"/>
		<class name="PRIVATE.tests.Google4"/>
		<class name="PRIVATE.tests.Google5"/>
		<class name="PRIVATE.tests.Google6"/>
		<class name="PRIVATE.tests.Google7"/>
		<class name="PRIVATE.tests.Google8"/>
		<class name="PRIVATE.tests.Google9"/>
		<class name="PRIVATE.tests.Google10"/>
		</classes>
</test>
<test verbose="1" name="Access Yahoo" annotations="JDK">
		<classes>
		<class name="PRIVATE.tests1.Yahoo"/>
		<class name="PRIVATE.tests1.Yahoo1"/>
		<class name="PRIVATE.tests1.Yahoo2"/>
		</classes>
</test>
<listeners>
		<listener class-name="PRIVATE.tests.ScreenshotListener"/>
</listeners>

This is a duplicate of https://github.com/cbeust/testng/issues/2000
#2000 has been fixed. Please try again with the latest released version of TestNG viz., 7.0.0-beta5.
PS: You may need to add a repository entry to refer to JCenter as well.
This SO post should give you some help, if you are looking for any, with respect to specifying JCenter repository in your pom file.


Add PROXY protocol support

Support for the PROXY protocol

Needs support on the Postgres side as well. Unsure if there is much benefit until then. Maybe for fail2ban?
Latest Postgres patch thread

@chasers wrong link


mumble,murmur: 1.3.4 -> 1.4.230

Motivation for this change
Update version to 1.4.230
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

A stable release is out: https://www.mumble.info/blog/mumble-1.4.230/

Thanks for pinging. Working on it!

Happy to help test. Also, upstream just added a change that allows building with system rnnoise, might be worth looking into.

Any reason behind the rename? It'll break people's configs, and upstream seems to still use "murmur" all over the place.

Any reason behind the rename? It'll break people's configs, and upstream seems to still use "murmur" all over the place.

Please read the commit message.

Happy to help test. Also, upstream just added a change that allows building with system rnnoise, might be worth looking into.

Created a PR for porting it back to the 1.4.x branch. https://github.com/mumble-voip/mumble/pull/5464

Adding an option alias helps, but it doesn't fully fix the issue. The database path should probably be conditional on stateVersion as well.

Rebased. Fixed Pulseaudio & Pipewire support. Mumble is dynamically loading the libs.

Rebased. Fixed Pulseaudio & Pipewire support. Mumble is dynamically loading the libs.

qt5.mkDerivation might already provide a wrapper you can use for this - would it be double-wrapped otherwise?

Rebased. Fixed Pulseaudio & Pipewire support. Mumble is dynamically loading the libs.

@fpletz Thanks!

I created a new pull request for the version update. See #161663.
I will fix remaining issues in a few days, hopefully. At least the new version can be used then ;)


feat(async): adds AsyncScheduler and updates appropriate operators.

Adds Scheduler.async which will always schedule an action to happen in the future. Fixes #1339. Updates FutureAction to use setInterval instead of repeated setTimeout calls as discussed with @mattpodwysocki in #1391.

@trxcllnt why do we not have a separate schedule method like schedulePeriodic for when setInterval is necessary? Let's chat about this before merging because I want to bring in long running scheduling which avoids recursive scheduling which is what I'm retrofitting into v4...

@mattpodwysocki well, mostly because early on we knew we wanted a smaller scheduling API and that recursive scheduling could accomplish all scheduling variants. replacing the state and reusing the scheduled action is effectively tail-call optimization.

@mattpodwysocki I also ran some rudimentary tests in jsperf that show using setInterval is faster than setTimeout (in my Chrome), even if we only use it to run something once and dispose. So, as far as I can tell, there's no downside to using setInterval all the time.

@trxcllnt why do we not have a separate schedule method like schedulePeriodic for when setInterval is necessary?

I suggested the same thing in Slack.

there's no downside to using setInterval all the time.

... accept it's weird and confusing to look at in the code.

I'm really against breaking this API, @trxcllnt. It would be a breaking change.
Before Scheduler.scheduler(foo, 10) would have caused foo to execute 1 time at 10 milliseconds (or virtual frames, or whatever you're scheduling by).  With this PR it will repeat every 10ms.
It seems like what we really want is schedulePeriodic or scheduleInterval which would be more idiomatic for JS folks.
The other thing is the need to schedule things on a repeating basis is really an edge case for schedulers. Most of the time schedulers are scheduling one thing and they're done.
It is interesting that setInterval is faster in Chrome than setTimeout. But given that this is something that's happening on a delay anyhow, I'm not sure the perf win is going to be noticeable enough in any meaningful way to justify the breaking change.

even a Scheduler.schedule(fn: Function, delay: number = 0, state: any = null, repeat: boolean = false) API would be better IMO. Just as long as it doesn't break the current behavior.
... but I like scheduleInterval a little better.

@blesh With this PR it will repeat every 10ms.

No, that's incorrect. The behavior of schedule is exactly the same in the non-repeating case, and more idiomatic in the repeating case (see here and here).

@blesh

@trxcllnt why do we not have a separate schedule method like schedulePeriodic for when setInterval is necessary?

I suggested the same thing in Slack.

In the beginning, you and I set a goal of reducing the surface area of simplifying and optimizing the schedulers. We acknowledged that recursive scheduling was the most general case that would enable all the existing scheduling strategies while being simple enough to fully optimize. What's the point of making the API more complex than it has to be?

there's no downside to using setInterval all the time.

... except it's weird and confusing to look at in the code.

Does anybody ever really look at the scheduler internals much? Optimization ain't always pretty.

@trxcllnt Thank you for your PR, but I do think that the reason it is breaking in Angular is due to the recursive scheduling.  I am not asking any of you to fix it on your end, but if you could that would be great.
I think that setInterval should definitely be utilized, but I agree with @blesh in that it isn't really the best design choice to hack it in order to produce the same effect as setTimeout.  What would be the feasibility of doing a scheduleInterval?

@Guardiannw "recursive" in this context doesn't refer to literal recursion, but is a metaphor for the API that allows scheduled actions to reschedule themselves. Past versions of Rx did use recursion, which wasn't TCO, and we've optimized for in this case. This is not the source of your memory leak.

@trxcllnt I think I knew that already, but I am pretty sure that zone.js keeps track of that.  That zone.js actually monitors a stack trace through what set the timeout and then where it went and then what set it and then where it went and then...... so on and so forth.  Thereby creating an infinitely long stack trace full of leaked memory as the interval goes on and on.

@Guardiannw then it sounds like moving from repeated setTimeout calls to a single setInterval call would solve your problem, no?

@trxcllnt Yes I think it would.  I just think that it would be best not to use setInterval on occasions where setTimeout is desired.  But in the case of an IntervalObservable, I think it would be the most appropriate solution.

@trxcllnt Yes, I very much believe that that is what is causing the problem.

@Guardiannw I just think that it would be best not to use setInterval on occasions where setTimeout is desired

If there were any meaningful difference between canceling setInterval after it executes once and just calling setTimeout, including loss of performance, then I'd agree. We actually see the opposite here. And in fact, given the runtime scheduling differences between setTimeout and setInterval, I think a case can be made that we should always use setInterval, especially for single-run actions, because the runtime attempts to execute actions scheduled via setInterval more precisely.
This PR fixes multiple outstanding issues (including yours, it sounds like), is faster, doesn't contain any breaking changes, and doesn't increase API surface area. I don't know what more we could ask for in a PR.

Hey I'm open to hearing from guys much more intelligent than me.

@Guardiannw feel free to clone this branch and see whether you still see the memory leak or not.

@trxcllnt I cloned and ran tests on your branch and your PR does indeed fix my other memory leak issue.  I had to add the fix #1394 as well in order to be sure no memory leaks exist anymore.  After I did both your branch and that fix, things are working like a dream.  No memory leaks...  @blesh @mattpodwysocki Please move forward where you all want to, but please somehow incorporate this fix in some way so that we have this bug fixed.
Thank you all,

@blesh @mattpodwysocki as far as I can tell, we have two options here:

Modify the current scheduler API (either by adding a new schedulePeriodic method, or adding a flag to the current schedule method) to distinguish between actions scheduled once vs. actions scheduled periodically

Pros:

more explicit public API
distinguishes between scheduling actions with setTimeout and setInterval, which may be necessary if there are differences between when the time at which a runtime invokes identically scheduled setTimeout and setInterval callbacks under timer pressure

Cons:

breaking change (major semver rev)
find new solution for optimizing periodic scheduling with state
adds complexity to an API new users already have a difficult time understanding
changes everywhere we're currently scheduling an action that runs more than once
could reintroduce @Guardiannw's memory leak if a schedule-one action is scheduled repeatedly
introduces an unnecessary code path if a runtime doesn't distinguish between identically scheduled setTimeout and setInterval callbacks under timer pressure

Maintain the current scheduling API (what this PR does), but apply internal optimization that uses setInterval instead of setTimeout to achieve more idiomatic periodic scheduling, essentially assuming an action will re-schedule itself with the same due time, but cancels if it doesn't or the due time changes

Pros:

no breaking change
the scheduled action determines whether it's re-scheduled or not
one optimized code path for scheduling whether executes once vs. periodic

Cons:

using setInterval and canceling after the first execution may not be equivalent to using setInterval when a runtime is under memory pressure
difficult to tell that setInterval will be canceled after each execution if the scheduled action doesn't call this.schedule without carefully reading the source of FutureAction

I don't care which one we choose, but we've gotta choose one. I chose option 2 on the basis that it was less work, but if someone (not me) wants to take on the work for option 1, be my guest.

breaking change (major semver rev)

It's not a breaking change. Not even close. It's adding a new method to the type, and not at all changing the other method.
Unless I'm mistaken, what you're proposing is a breaking change.
Currently:
Scheduler.schedule(() => console.log('hi'), 1000) logs "hi" after 1000ms.
After the proposed change:
Scheduler.schedule(() => console.log('hi'), 1000) logs "hi" on an interval every 1000ms until something disposes of the returned subscription. That would be a "breaking change", for sure.
... either way, in a -beta. revision, we're not bumping up semver a major revision for a change like this.

Also, this PR is doing way too much.

Adds a new scheduler
Sets it as the default to multiple operators
Changes existing schedulers to set up intervals rather than timeout.

... all in one commit, and without much discussion by the community.
I'm not trying to be adversarial, @trxcllnt, but I don't think I agree with the PR, and it's even harder for me to agree with it when it's doing so much.

@blesh I'm sorry, this PR does not automatically re-execute the action unless it's disposed (added an inline comment showing where the interval is canceled if the action isn't rescheduled).
The API change would be a breaking change because it would break actions that reschedule themselves recursively (i.e. remove the ability for a scheduled action to call this.schedule() inside the action callback itself) since a user would now have to call schedulePeriodic when the action is first scheduled, instead of the current way of calling schedule and rescheduling inside the action if it needs to continue.

Okay... after reviewing this PR and discussing with Paul in Slack, I think what we've got here is fine.
I misunderstood the setInterval bit. It's a perf optimization for rescheduling, but doesn't change the behavior of the schedule method. It's just that if the action re-schedules, it will continue the interval. I'd like to keep the current API that allows the action to schedule itself again, because that opens the door for more dynamic scheduling down the road (for things like exponential stepback etc), where a schedulePeriodic would limit the API to only being able to schedule steady intervals.
The AsyncScheduler makes total sense, and I think we needed that. I'm dubious on the name, but it's fine for now I think, and "sounds" like it comes after asap, IMO.
The other changes to default some operators to use the async scheduler seem totally fine.

Also, I LOVE the fact that @trxcllnt commented the hell out of FutureAction to make sure the implementation is clear to those hopping into it. The setInterval bit is confusing at first blush without the comments.

LGTM

Kudos for the comments! :clap:
We should do it more. ;)

@trxcllnt this looks good, but I think I'm going to block it while #1364 is merged. Then the tests will need to be updated to TypeScript. Cool?

@blesh sure. do you need me to rebase and resolve merge conflicts?

@trxcllnt: If you'd be so kind, yes.

@blesh done

@blesh could we merge this PR now?

LGTM


Adds support for running in Istio environments

Changes to application

Adds --istio-enabled flag to command and codifies Istio proxy readiness check + quitquitquit wrapper around CRD actions

Changes to chart

Adds pod security policy
Adds network policy
Adds new values to control resource creation/behavior depending on deployment environment

@ddl-audi @steved I just need to add some tests and/or tweak this codecov config (I know, I know, coverage is 🤮).
One of the interesting things to note about this change is the way we handle PSP permissions specific to a cluster (i.e. RayCluster, SparkCluster, etc...). If you deploy the operator into an environment with the PSP admission controller enabled and Istio available, then these changes will allow the operator/crd install to work.
If you then try to create a RayCluster, as an example, that might fail. It all depends  the PSP/ServiceAccount/RBAC chain establish for that cluster.

Someone (externally) creates a PSP for their use and then provides that podSecurityPolicy name in the CR. Assuming the PSP is adequate (covers crazy Istio elevated permissions shiz), then this works.
Someone sets up the full PSP/ServiceAccount/RBAC chain externally and provides a serviceAccountName in the CR. Again, if it's correctly set up, then this works.
Someone tries to create a CR without any of the above 2 measures in the environment I described, then 🔥🔥🔥🔥.

I think we have covered internally, correct?
Initially, I decided NOT to create PSPs for clusters since I didn't want to manage external resources via a finalizer. But, since we're now using StatefulSets and clean up their PVCs on CR delete, perhaps this changes the equation? I don't think it obviates my initial concern but I'm curious to get your input.


fix: updating api check workflow

Description
Fixed API check workflow
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)

Further comments

Thanks for the PR!
Any successful deployments (not always required) will be available below.
Backend available
Once merged, code will be promoted and handed off to following workflow run.


Clock Example

I really like the appearance of this example! Great job.
I notice there is a tiny remnant of the second hand lingering at the 29 and 44 second position.

Fun fact which hit me when I was figuring out the function call that drew those 12 numbers of the clock face. Did you know that clocks using Arabic numerals, the digits are oriented vertically as you've done here, but for clock faces using Roman numerals, the "digit" orientation rotates according to the position, sign that the "V" of 5 o'clock is almost upside down?

Thanks - that it looks like a bug in the update code for lines.  I think I have a fix for that.
I didn't know that about the traditional arrangement of roman numerals, but that is something which Tempe currently lacks is the ability to render text at different angles.  I should probably add an issue for that.

I'll check this soon. Looking at some random VU meter pictures online, I'd say there's a mixture of vertically aligned digits and rotated digits (aligned with the tick marks). I can live with non-rotated text.
Thinking back on your stated goals, which include making pretty plots, seems like rotated text would be needed. At minimum 90 deg increments for Y-axis labels. Arbitrary for more fancy plots.


OptionsIn Library Util

The OptionsIn parameter there are potentially multiple options in formatted as per 6.1.7 on page 43 of the <IP_ADDRESS> Spec.
Additionally for <IP_ADDRESS> it should be noted that options in will be null or empty string.
The options in needs to be parsed correctly. I suggest adding a utility library that does this, as it will need to be done for other functions. It would be nice to have a com.hashmapinc.tempus.witsml.server.util library that holds static functions such as this.

For additional clarification:
The options in parameter is formatted as per the spec:
keyword1=value1
keyword1=value1;keyword2=value2
keyword1=value1;keyword2=value2;keyword3=value3
I would like a util class that would translate this into a Map<String,String> where the values would be:
keyword1,value1
keyword2,value2
keyword3,value3
The valid keywords start on page 55 of the <IP_ADDRESS> spec.
the pseudo-code is
Map<String,String> convertOptionsIn(String optionsIn){
    Map<String,String> options = new HashMap<>();
    String[] kvpairs = optionsIn.split(";");
    foreach(kvpairs kvpair){
           option[] = kvpair.split("=");
           options.add(option[0],option[1]);
    }
    return options;
}


Coerce integer ID scalar input

This change enables ID scalar inputs to be coerced from integer values as mentioned in the October 2016 version of the GraphQL specification.

Input Coercion
When expected as an input type, any string (such as "4") or integer (such as 4) input value should be coerced to ID as appropriate for the ID formats a given GraphQL server expects. Any other input value, including float input values (such as 4.0), must raise a query error indicating an incorrect type.

This PR has is made up of the following changes:

Add test cases for string and integer ID input
Add a case to ID.UnmarshalGraphQL switch statement to handle coercion/unmarshalling integer input
Move ID scalar implementation from graphql.go to its own file for neater code organization
Separate scanner.Int and scanner.Float argument literal parsing cases

LGTM

LGTM, thanks!


Remove redundant promise wrapper.

This change is

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


Avoid panic when writing UIDs/GIDs > 0x1fffff

The USTAR archive format can't encode UIDs or GIDs that can't be represented in 21 (7 * 3) bits, which creates errors when we modify headers to include such values.  When we do that, try to force a conversion to the PAX format, which can handle that.
This requires Go 1.10 or later, as the constants which need to be set in the header to indicate the format which should be used weren't exported before that.
Fixes #200.

LGTM
@flouthoc @TomSweeneyRedHat PTAL

Changes LGTM
would be nice to have an added test if possible

I am Late. But since right interface is implemented for old golang versions. LGTM


AQCU 1020 - Supposed gap error fix

Fixed what I thought was a gap error fix but was actually a problem with reading non-estimated timeseries. Also, fixed a test that was broken for me in uvhydrograph-render-test and added another test that does a similar check.

Coverage increased (+0.003%) to 97.516% when pulling bd097cf38d65506073b89d5a16d1f1a50133ddf3 on dpattermann-usgs:uvhydroBugFixes into 7e937f7073a3d3dc6edd49485e188654032cfa0a on USGS-R:master.

Coverage increased (+0.003%) to 97.516% when pulling bd097cf38d65506073b89d5a16d1f1a50133ddf3 on dpattermann-usgs:uvhydroBugFixes into 7e937f7073a3d3dc6edd49485e188654032cfa0a on USGS-R:master.

Coverage remained the same at 97.513% when pulling bd097cf38d65506073b89d5a16d1f1a50133ddf3 on dpattermann-usgs:uvhydroBugFixes into 7e937f7073a3d3dc6edd49485e188654032cfa0a on USGS-R:master.

Coverage remained the same at 97.513% when pulling bd097cf38d65506073b89d5a16d1f1a50133ddf3 on dpattermann-usgs:uvhydroBugFixes into 7e937f7073a3d3dc6edd49485e188654032cfa0a on USGS-R:master.

Coverage increased (+0.0007%) to 97.514% when pulling 3ac0a658125ad743b655163eb4c3ca0639186416 on dpattermann-usgs:uvhydroBugFixes into 7e937f7073a3d3dc6edd49485e188654032cfa0a on USGS-R:master.

Coverage increased (+0.0007%) to 97.514% when pulling 7d87959e3dbaff9b9d1d7c465412ce101d9275a1 on dpattermann-usgs:uvhydroBugFixes into 7e937f7073a3d3dc6edd49485e188654032cfa0a on USGS-R:master.


Godot should have native support for Google Play Games like it has for Apple GameCenter

3.0:

OS/device including version:
Android/Any
Issue description:
It's really a huge deterrent to compile Godot just to use a module for Play Services written by someone else, and IMO a huge turnoff for new people, specially people that want to use Godot for Mobile Game dev and want to ditch Unity for good.
Since Godot is already providing Android In-App Purchases, and iOS Game Center integration, the Android services can easily be extended by adding support for Play Games Services.

I can try to implement this if there's enough need for it tho. As I need it for my games going forward..

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.
The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.
If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!


Grunt issue when deploying to Heroku

When I deploy my app to Heroku, Grunt isn't building my production.min.css file the same way it does when I build locally. It seems to add a ton of css which causes my front end to display terribly. Right now, I'm not using SASS, just static css files that need to be included in a certain order. It looks as though several more files are included when I deploy to Heroku. See screenshots below.
Heroku:

Local:

Hi @teamshultz, not 100% sure what the specific issue is here, but there are known issues with Grunt on Heroku.  I would try using heroku-buildpack-nodejs-grunt on your project; it's helped us in the past.  You'll need to add a BUILDPACK_URL environment var in your app; you can do it in the Heroku dashboard or on the command line with:
heroku config:add BUILDPACK_URL=https://github.com/mbuchetics/heroku-buildpack-nodejs-grunt.git

then in the tasks/register/prod.js file, copy the existing prod tasks but rename it to heroku:production, e.g.:
	grunt.registerTask('heroku:production', [
		'compileAssets',
		'concat',
		'uglify',
		'cssmin',
		'sails-linker:prodJs',
		'sails-linker:prodStyles',
		'sails-linker:devTpl',
		'sails-linker:prodJsJade',
		'sails-linker:prodStylesJade',
		'sails-linker:devTplJade'
	]);

We are seeing this issue intermittently when deploying to Heroku as well.  Sometimes the deploy works, sometimes it doesn't.
Using this buildpack: https://elements.heroku.com/buildpacks/bemyapptech/heroku-buildpack-nodejs-grunt-compass
Heroku logs:
2016-06-15T16:21:47.052821+00:00 app[web.1]: Warning: connect.session() MemoryStore is not
2016-06-15T16:21:47.052833+00:00 app[web.1]: designed for a production environment, as it will leak
2016-06-15T16:21:47.052834+00:00 app[web.1]: memory, and will not scale past a single process.
2016-06-15T16:22:06.973469+00:00 app[web.1]: Error: The hook `grunt` is taking too long to load.
2016-06-15T16:22:06.973479+00:00 app[web.1]: Make sure it is triggering its `initialize()` callback, or else set `sails.config.grunt._hookTimeout to a higher value (currently 20000)
2016-06-15T16:22:06.973481+00:00 app[web.1]:     at Timeout.tooLong [as _onTimeout] (/app/node_modules/sails/lib/app/private/loadHooks.js:85:21)
2016-06-15T16:22:06.973482+00:00 app[web.1]:     at tryOnTimeout (timers.js:224:11)
2016-06-15T16:22:06.973482+00:00 app[web.1]:     at Timer.listOnTimeout (timers.js:198:5) { [Error: The hook `grunt` is taking too long to load.
2016-06-15T16:22:06.973484+00:00 app[web.1]: Make sure it is triggering its `initialize()` callback, or else set `sails.config.grunt._hookTimeout to a higher value (currently 20000)] code: 'E_HOOK_TIMEOUT' }
2016-06-15T16:22:08.082861+00:00 heroku[web.1]: Process exited with status 0
2016-06-15T16:22:08.088624+00:00 heroku[web.1]: State changed from starting to crashed


Update Volto Hands-On

I reworked lots of the training to be more in line with what the fundementals on working with Volto are. The update is definetely not done but I think it should be in a state, to be usable during this years training at the conference. Smaller amendments will probably follow tomorrow.


Merge into dev.

You'll need to manually resolve conflicts between release/2.1 and dev. Don't use the github UI for this.
Here is how I merge back to dev
git checkout dev
git pull
git checkout -b namc/merge-rel-21
git merge --no-commit --no-ff release/2.1
git checkout dev modules/
git checkout dev build/dependencies.props
git commit

Then open a PR using namc/merge-rel-21


Double dash, pass arguments and parameters to cli programs

Allow for the usage of double dashes after the command is finished to pass options and arguments to the underlying program that zqdgr is running, this follows POSIX conventions and it's what other similar programs do.

5805861d7ffea206f46b4981aeb53f264e84f353


🐛 files.include not working (at all)

Environment information
pnpm biome rage
CLI:
  Version:                      1.4.1
  Color support:                true

Platform:
  CPU Architecture:             aarch64
  OS:                           macos

Environment:
  BIOME_LOG_DIR:                unset
  NO_COLOR:                     unset
  TERM:                         "xterm-256color"
  JS_RUNTIME_VERSION:           "v20.9.0"
  JS_RUNTIME_NAME:              "node"
  NODE_PACKAGE_MANAGER:         "pnpm/8.10.0"

Biome Configuration:
  Status:                       Loaded successfully
  Formatter disabled:           false
  Linter disabled:              false
  Organize imports disabled:    false
  VCS disabled:                 true

Workspace:
  Open Documents:               0

What happened?
When specifying the files.include option in biome.json, it doesn't actually do anything.
The only way I managed to get biome format and biome check to work is by using files.ignore instead.
When using files.ignore, it doesn't matter if files.include is configured or not. It just doesn't appear to do anything.
However, if I don't specify files.ignore, then no files are checked (which is also weird). Imho, the natural expected behavior would be for files.include to widen the list and files.ignore to narrow it. And maybe, if no files.include is specified, include everything (or nothing, that's a matter of taste imho).
Expected result
files.include should work I guess ;-)
Code of Conduct

[X] I agree to follow Biome's Code of Conduct

Thank you @fubhy for filing the issue , could you please share a minimal reproduction, so we can investigate and help you? I'm aware that there are some issues, but we need a way to reproduce them.
As the issue stands , our hands are tight and we can't do anything because we don't have any concrete information to triage it.

I mean, as I said there's not much to set up in terms of a reproduction repo. Both include and ignore just don't work as documented as far as I can tell in the most simple combination even.
But here you go: https://github.com/fubhy/biome-broken-include-and-ignore

Also please let me know if I'm doing sth. wrong here. If this is actually broken in the way that it appears to me it would actually be kinda wild. I mean considering there are no other issues open about it (as far as I can tell) for what seems to be should be a widely used configuration option.

Also please let me know if I'm doing sth. wrong here. If this is actually broken in the way that it appears to me it would actually be kinda wild considering that there are no other issues open about it (as far as I can tell) for what should(?) be a widely used configuration option.

For example, one thing that you didn't mention is how you're running Biome. Biome is CLI and LSP, and they work in different environments. The reproduction doesn't have any scripts, so I guess you're using Biome via LSP?

Gotcha. I am seeing the issue when using the biome cli via e.g. biome check .

Gotcha. I am seeing the issue when using the biome cli via e.g. biome check .

Could you update the repository, please? Sorry for being peaky, doing biome check . could trigger a possible global installation and make things different

Gotcha. I am seeing the issue when using the biome cli via e.g. biome check .

Could you update the repository, please? Sorry for being peaky, doing biome check . could trigger a possible global installation and make things different

No it doesn't in my case. I'm using a Nix based setup throughout my entire system. I'm directly calling pnpm biome check . in this case.

I'm seeing a similar setup as well

I can confirm the bug with your reproduction. I tested with pnpm and npx:
$ pnpm biome check .
Checked 0 file(s) in 446µs
internalError/io ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✖ No files were processed in the specified paths.

$ npx biome check .
Checked 0 file(s) in 446µs
internalError/io ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  ✖ No files were processed in the specified paths.

I ran into a similar issue. I have this in biome.json:
  "files": {
    "include": ["**/*.mjs", "**/*.js", "**/*.css", "**/*.json"]
  },

If I run npx biome lint I get Missing argument <INPUT>. I was expecting it to default to the include and ignore globs set up in the config file.
Curiously, if I run npx biome lint ., it checks 4 files, which happens to be the number of files matching the file extensions in the list above. It's as if it didn't go recursively into subdirectories, based on the ** part of the path globs.


[DataTable] Overflow menu hidden behind scroll

Overflow Menu placed inside the Table is hidden behind a scroll instead of flowing out of the table container
Replicated in CodeSandbox

This is expected because of the scrolling overflow + position absolute. The alternative is using the fixed position prop, but the trade off is that the open menus will stay fixed to the viewport when you scroll.


Talk up server interfaces in Fern vs. OpenAPI

for server-side API development I think we should focus on server side interfaces earlier and explain why they are different from server side stubs . I think we need to explicitly talk about how generated code and written code can live in separate places and not conflict.

docs are being re-decompoed now so closing


Enable git signing commits and ssh-agent service

May relate to #262

[x] Manage git with home-manager
[x] Enable ssh commit sign with *.pub by #263
[x] Resolves #265

Very tired 😩
Made the world a little better for me ☺


🐛 Black screen on Redmi Note 11

What's happening?
I updated my camera to version 3.7.0. It works well on my Pixel 4a, but on my Redmi Note 11 Pro Plus, the camera shows a black screen. I've attached an image below for reference.

Reproduceable Code
const device = useCameraDevice(isFront ? 'front' : 'back');
const format = useCameraFormat(device, [
{ videoResolution: 'max' },
{ photoResolution: 'max' },
{ videoResolution: { width: 1280, height: 720 } },
{ photoResolution: { width: 1280, height: 720 } },
]);
<Camera
orientation="portrait"
format={format}
device={device}
isActive={true}
ref={cameraRef}
onError={(e) => {
console.log('eRROR-->', e);
}}
style={[StyleSheet.absoluteFill]}
photo={true}
video={true}
audio={true}
enableZoomGesture={true}
>

Relevant log output
14:38:07.629  E  [ERROR][PPROC  ] camxopenode.cpp:4173 UpdateBandwidth() cq2+m_currentrequestID is 63,m_previewrequestID=62,requestDelta=1
14:38:07.630  E  [ERROR][PPROC  ] camxopenode.cpp:8304 PrepareRSStatsMetadata() cq3+sensorWidth is 4000,sensorHeight=3000
14:38:07.662  E  [ERROR][PPROC  ] camxopenode.cpp:4173 UpdateBandwidth() cq2+m_currentrequestID is 64,m_previewrequestID=63,requestDelta=1
14:38:07.662  E  [ERROR][PPROC  ] camxopenode.cpp:8304 PrepareRSStatsMetadata() cq3+sensorWidth is 4000,sensorHeight=3000
14:38:07.698  E  [ERROR][PPROC  ] camxopenode.cpp:4173 UpdateBandwidth() cq2+m_currentrequestID is 65,m_previewrequestID=64,requestDelta=1
14:38:07.698  E  [ERROR][PPROC  ] camxopenode.cpp:8304 PrepareRSStatsMetadata() cq3+sensorWidth is 4000,sensorHeight=3000
14:38:07.728  E  [ERROR][PPROC  ] camxopenode.cpp:4173 UpdateBandwidth() cq2+m_currentrequestID is 66,m_previewrequestID=65,requestDelta=1
14:38:07.728  E  [ERROR][PPROC  ] camxopenode.cpp:8304 PrepareRSStatsMetadata() cq3+sensorWidth is 4000,sensorHeight=3000
14:38:07.763  E  [ERROR][PPROC  ] camxopenode.cpp:4173 UpdateBandwidth() cq2+m_currentrequestID is 67,m_previewrequestID=66,requestDelta=1
14:38:07.763  E  [ERROR][PPROC  ] camxopenode.cpp:8304 PrepareRSStatsMetadata() cq3+sensorWidth is 4000,sensorHeight=3000
14:38:07.796  E  [ERROR][PPROC  ] camxopenode.cpp:4173 UpdateBandwidth() cq2+m_currentrequestID is 68,m_previewrequestID=67,requestDelta=1
14:38:07.796  E  [ERROR][PPROC  ] camxopenode.cpp:8304 PrepareRSStatsMetadata() cq3+sensorWidth is 4000,sensorHeight=3000
14:38:07.829  E  [ERROR][PPROC  ] camxopenode.cpp:4173 UpdateBandwidth() cq2+m_currentrequestID is 69,m_previewrequestID=68,requestDelta=1
14:38:07.829  E  [ERROR][PPROC  ] camxopenode.cpp:8304 PrepareRSStatsMetadata() cq3+sensorWidth is 4000,sensorHeight=3000
14:38:07.862  E  [ERROR][PPROC  ] camxopenode.cpp:4173 UpdateBandwidth() cq2+m_currentrequestID is 70,m_previewrequestID=69,requestDelta=1
14:38:07.862  E  [ERROR][PPROC  ] camxopenode.cpp:8304 PrepareRSStatsMetadata() cq3+sensorWidth is 4000,sensorHeight=3000
14:38:07.897  E  [ERROR][PPROC  ] camxopenode.cpp:4173 UpdateBandwidth() cq2+m_currentrequestID is 71,m_previewrequestID=70,requestDelta=1
14:38:07.897  E  [ERROR][PPROC  ] camxopenode.cpp:8304 PrepareRSStatsMetadata() cq3+sensorWidth is 4000,sensorHeight=3000
14:38:07.928  E  [ERROR][PPROC  ] camxopenode.cpp:4173 UpdateBandwidth() cq2+m_currentrequestID is 72,m_previewrequestID=71,requestDelta=1
14:38:07.928  E  [ERROR][PPROC  ] camxopenode.cpp:8304 PrepareRSStatsMetadata() cq3+sensorWidth is 4000,sensorHeight=3000
14:38:07.963  E  [ERROR][PPROC  ] camxopenode.cpp:4173 UpdateBandwidth() cq2+m_currentrequestID is 73,m_previewrequestID=72,requestDelta=1
14:38:07.963  E  [ERROR][PPROC  ] camxopenode.cpp:8304 PrepareRSStatsMetadata() cq3+sensorWidth is 4000,sensorHeight=3000
14:38:07.996  E  [ERROR][PPROC  ] camxopenode.cpp:4173 UpdateBandwidth() cq2+m_currentrequestID is 74,m_previewrequestID=73,requestDelta=1
14:38:07.996  E  [ERROR][PPROC  ] camxopenode.cpp:8304 PrepareRSStatsMetadata() cq3+sensorWidth is 4000,sensorHeight=3000
14:38:08.030  E  [ERROR][PPROC  ] camxopenode.cpp:4173 UpdateBandwidth() cq2+m_currentrequestID is 75,m_previewrequestID=74,requestDelta=1
14:38:08.030  E  [ERROR][PPROC  ] camxopenode.cpp:8304 PrepareRSStatsMetadata() cq3+sensorWidth is 4000,sensorHeight=3000
14:38:08.063  E  [ERROR][PPROC  ] camxopenode.cpp:4173 UpdateBandwidth() cq2+m_currentrequestID is 76,m_previewrequestID=75,requestDelta=1
14:38:08.063  E  [ERROR][PPROC  ] camxopenode.cpp:8304 PrepareRSStatsMetadata() cq3+sensorWidth is 4000,sensorHeight=3000
14:38:08.096  E  [ERROR][PPROC  ] camxopenode.cpp:4173 UpdateBandwidth() cq2+m_currentrequestID is 77,m_previewrequestID=76,requestDelta=1
14:38:08.096  E  [ERROR][PPROC  ] camxopenode.cpp:8304 PrepareRSStatsMetadata() cq3+sensorWidth is 4000,sensorHeight=3000
14:38:08.131  E  [ERROR][PPROC  ] camxopenode.cpp:4173 UpdateBandwidth() cq2+m_currentrequestID is 78,m_previewrequestID=77,requestDelta=1
14:38:08.131  E  [ERROR][PPROC  ] camxopenode.cpp:8304 PrepareRSStatsMetadata() cq3+sensorWidth is 4000,sensorHeight=3000
14:38:08.164  E  [ERROR][PPROC  ] camxopenode.cpp:4173 UpdateBandwidth() cq2+m_currentrequestID is 79,m_previewrequestID=78,requestDelta=1
14:38:08.164  E  [ERROR][PPROC  ] camxopenode.cpp:8304 PrepareRSStatsMetadata() cq3+sensorWidth is 4000,sensorHeight=3000

Camera Device
LOG  {
  "sensorOrientation": "landscape-right",
  "hardwareLevel": "full",
  "maxZoom": 10,
  "minZoom": 1,
  "maxExposure": 24,
  "supportsLowLightBoost": false,
  "neutralZoom": 1,
  "physicalDevices": [
    "wide-angle-camera"
  ],
  "supportsFocus": true,
  "supportsRawCapture": true,
  "isMultiCam": false,
  "minExposure": -24,
  "name": "BACK (0)",
  "hasFlash": true,
  "hasTorch": true,
  "position": "back",
  "id": "0"
}
 LOG  {
  "sensorOrientation": "landscape-right",
  "hardwareLevel": "full",
  "maxZoom": 10,
  "minZoom": 1,
  "maxExposure": 24,
  "supportsLowLightBoost": false,
  "neutralZoom": 1,
  "physicalDevices": [
    "wide-angle-camera"
  ],
  "supportsFocus": true,
  "supportsRawCapture": true,
  "isMultiCam": false,
  "minExposure": -24,
  "name": "BACK (0)",
  "hasFlash": true,
  "hasTorch": true,
  "position": "back",
  "id": "0"
}

Device
Redmi Note 11 Pro Plus
VisionCamera Version
3.7.0
Can you reproduce this issue in the VisionCamera Example app?
I didn't try (⚠ your issue might get ignored & closed if you don't try this)
Additional information

[X] I am using Expo
[ ] I have enabled Frame Processors (react-native-worklets-core)
[X] I have read the Troubleshooting Guide
[X] I agree to follow this project's Code of Conduct
[X] I searched for similar issues in this repository and found none.

If you set the exposure of the Camera component to 0 you should see it fine in all devices.
<Camera ... exposure={0} />

@DidacClaria  Thanks for your response, this issue is fixed.

Logs are not relevant. You included logs that have nothing to do with VisionCamera. Please include the full adb logcat logs from your application.

Also, setting exposure to 0 is not a fix - it's a workaround. We need a real fix.

Some of our users also reported this problem on  Poco x4 pro and other devices.

Working on a fix for this issue here: https://github.com/mrousavy/react-native-vision-camera/pull/2494 👀
Still in development, so don't test yet. Long way to go, this is a really complicated issue (as you can see in the changes/Files of that PR)...

Just released VisionCamera 3.9.0-beta.1, which includes the big PersistentCaptureSession PR that aims to fix all the blackscreen issues.... :eyes::tada:
You can try that new beta out yourself and let me know if you still encounter blackscreen issues. I'll continue to test on more devices in the meantime, organize the code a bit better, and then I'll tackle the preview stretching, focus, and flash issues!
If that fixes the blackscreen issues for you, please consider sponsoring me on GitHub to say thanks! ❤


Numer of history search items

Hi.
Is there any ways to change the number of history search items? I want to show 4-5 instead of 2 (by default) but can't find the way how to change that.

Use setHistorySize method in SearchTable

Thank you, that works!


hyprland-activewindow: 1.0.2 -> 1.0.3

Description of changes
Changelog. TL;DR: compatibility with Hyprland breaking changes in  0.40.
Needs to have the Cargo.lock updated to avoid hitting a cargo error. Reported upstream in https://github.com/FieldofClay/hyprland-activewindow/issues/20 and fix in https://github.com/FieldofClay/hyprland-activewindow/pull/21.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Dropped the patch that was redundant due to upstream refreshing the 1.0.3 tag.
Updated via plain nix-update, resulting binary working fine in Hyprland 0.39.


Replace lodash.defaults with native Object.assign

This utility does not add much value but really confuses newcomers like
me. Also all per function lodash.* packages are deprecated so better
to avoid lodash usage if possible.

Hi @luin. Is this good to go?

Friendly ping @luin

Hi @luin What do you think about this change?

Friendly ping @luin

Sorry @TrySound I overlooked this PR. I agree with the direction to remove all lodash packages in favor of native ones. Will take a look!

The only pitfall is this introduces a potential backward compatibility issue when the provided option contains an undefined value due to the difference between _.defaults and Object.assign:
> const userOptions = { port: undefined }
> const defaultOptions = { port: 6379 }
> lodash.defaults({}, userOptions, defaultOptions)
{ port: 6379 }
> Object.assign({}, defaultOptions, userOptions)
{ port: undefined }

So I think we should include this in the next major version. WDYT?

I agree


fix: template generation failing

Fixes https://github.com/asyncapi/cli/issues/1425

/update

/rtm


Put helm template generation into generate-tarball

This addresses #11318
We move Helm template generation into generate-tarball and remove the need to manually update them.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/9186/
Test FAILed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/9187/
Test PASSed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/9188/
Test FAILed.

alluxio-bot, test this please

I don't think any public facing doc have instruction on generate-tarball so nothing is updated.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/9189/
Test PASSed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/9190/
Test FAILed.

Tests in error:
alluxio.server.ft.journal.TriggeredCheckpointTest.ufsJournal(alluxio.server.ft.journal.TriggeredCheckpointTest)
  Run 1: TriggeredCheckpointTest.ufsJournal:63->validateCheckpointInClusterRestart:124 » Timeout
  Run 2: TriggeredCheckpointTest.ufsJournal:63->validateCheckpointInClusterRestart:124 » Timeout

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/9205/
Test PASSed.

@madanadit I ran through the tests and they're good. I think with the current code change, in generate-tarballs release we generate the Helm templates w/o flag override (release is set to always have Helm generate), and thus the docker image part is good.
I'm working with @tieujason330 to make sure pipelines are good, and getting his approval.

Thanks @jiacheliu3. Does the golang helm client have an api to generate?

@tieujason330 Do you approve this PR or have anything for me to check?

lgtm, i assume you already did test runs for publishing the tarball right?

@tieujason330 I manually generated the tarball, built docker image against the tarball, tested the tarball and docker image. Note that the tests are all manual, not from the jenkins pipeline. I didn't want to risk publishing anything that is not from master branch.

alluxio-bot, merge this please.


Argument of type '"api::cookie.cookie"' is not assignable to parameter of type 'ContentType'.

After a fresh install I get 3 errors right away. I tried changing the two files:

./src/api/cookie/services/cookie.js
./src/api/cookie-category/services/cookie-category.js
like documented, but nothing changed.

No clue what to change that it works. I'm on the latest version of strapi.
2024-05-26 22:04:20 WARNING in ../node_modules/strapi-plugin-cookie-manager/admin/src/pages/App/index.js 10:44-52
2024-05-26 22:04:20 export 'NotFound' (imported as 'NotFound') was not found in '@strapi/helper-plugin' (possible exports: AnErrorOccurred, AppInfoContext, AppInfoProvider, AppInfosContext, AppInfosProvider, AutoReloadOverlayBlockerContext, AutoReloadOverlayBlockerProvider, Body, CheckPagePermissions, CheckPermissions, ConfirmDialog, ContentBox, ContentManagerEditViewDataManagerContext, CustomFieldsContext, CustomFieldsProvider, DateTimePicker, DynamicTable, EmptyBodyTable, EmptyStateLayout, FilterListURLQuery, FilterPopoverURLQuery, Form, GenericInput, GuidedTourContext, GuidedTourProvider, InjectionZone, LibraryContext, LibraryProvider, Link, LinkButton, LoadingIndicatorPage, NoContent, NoMedia, NoPermissions, NotAllowedInput, NotificationsContext, NotificationsProvider, OverlayBlockerContext, OverlayBlockerProvider, PageSizeURLQuery, PaginationURLQuery, RBACContext, RBACProviderContext, ReactSelect, RelativeTime, RemoveRoundedButton, Root, SearchURLQuery, SettingsPageTitle, SortIcon, Status, StopPropagation, StrapiAppContext, StrapiAppProvider, Table, TrackingContext, TrackingProvider, auth, contentManagementUtilRemoveFieldsFromData, difference, findMatchingPermissions, formatContentTypeData, formatPermissionsForRequest, getAPIInnerErrors, getFetchClient, getFileExtension, getOtherInfos, getType, getYupInnerErrors, hasPermissions, normalizeAPIError, onRowClick, prefixFileUrlWithBackendUrl, prefixPluginTranslations, pxToRem, request, setHexOpacity, shouldCheckPermissions, stopPropagation, to, translatedErrors, useAPIErrorHandler, useAppInfo, useAppInfos, useAutoReloadOverlayBlocker, useCMEditViewDataManager, useCallbackRef, useClipboard, useCollator, useCustomFields, useFetchClient, useFilter, useFocusInputField, useFocusWhenNavigate, useGuidedTour, useLibrary, useLockScroll, useNotification, useOverlayBlocker, usePersistentState, useQuery, useQueryParams, useRBAC, useRBACProvider, useSelectionState, useStrapiApp, useTableContext, useTracking, wrapAxiosInstance)
2024-05-26 22:04:20  @ ../node_modules/strapi-plugin-cookie-manager/admin/src/index.js
2024-05-26 22:04:20  @ ../node_modules/strapi-plugin-cookie-manager/strapi-admin.js
2024-05-26 22:04:20  @ ./.strapi/client/app.js 5:0-70 17:22-35
2024-05-26 22:04:20
2024-05-26 22:04:20 ERROR in ./src/api/cookie/controllers/cookie.ts:7:47
2024-05-26 22:04:20 TS2345: Argument of type '"api::cookie.cookie"' is not assignable to parameter of type 'ContentType'.
2024-05-26 22:04:20     5 | import { factories } from '@strapi/strapi'
2024-05-26 22:04:20     6 |
2024-05-26 22:04:20   > 7 | export default factories.createCoreController('api::cookie.cookie');
2024-05-26 22:04:20       |                                               ^^^^^^^^^^^^^^^^^^^^
2024-05-26 22:04:20     8 |
2024-05-26 22:04:20
2024-05-26 22:04:20 ERROR in ./src/api/cookie/routes/cookie.ts:7:43
2024-05-26 22:04:20 TS2345: Argument of type '"api::cookie.cookie"' is not assignable to parameter of type 'ContentType'.
2024-05-26 22:04:20     5 | import { factories } from '@strapi/strapi';
2024-05-26 22:04:20     6 |
2024-05-26 22:04:20   > 7 | export default factories.createCoreRouter('api::cookie.cookie');
2024-05-26 22:04:20       |                                           ^^^^^^^^^^^^^^^^^^^^
2024-05-26 22:04:20     8 |
2024-05-26 22:04:20
2024-05-26 22:04:20 ERROR in ./src/api/cookie/services/cookie.ts:1:18
2024-05-26 22:04:20 TS2304: Cannot find name 'createCoreService'.
2024-05-26 22:04:20   > 1 | module.exports = createCoreService('api::cookie.cookie', ({ strapi }) => ({
2024-05-26 22:04:20       |                  ^^^^^^^^^^^^^^^^^
2024-05-26 22:04:20     2 |   async find(params) {
2024-05-26 22:04:20     3 |     const { pagination } = await super.find(params);
2024-05-26 22:04:20     4 |     const results = await strapi.entityService.findMany("api::cookie.cookie", Object.assign(params, {

I am also facing the same exact error on my strapi build

Thanks for reporting the issue you are having with the latest Strapi version. I will take a look at it within the next couple of day, you will hear from me again.

@netzpixel I just found some time to investigate into the issue you are having. When using the latest strapi 4.24.3, I have encountered an issue with the automatic generation of the content types. Please report me if the following fixes your issue:

Upgrade the plugin to version 1.2.4
Delete the following content types folders which were generated by the plugin:
./src/api/cookie/
./src/api/cookie-category/
./src/api/cookie-popup/
Run strapi with yarn develop or npm develop
Make the changes according to the documentation inside of:
./src/api/cookie/services/cookie.js
./src/api/cookie-category/services/cookie-category.js
Now it should work

@netzpixel I just found some time to investigate into the issue you are having. When using the latest strapi 4.24.3, I have encountered an issue with the automatic generation of the content types. Please report me if the following fixes your issue:
1. Upgrade the plugin to version `1.2.4`

2. Delete the following content types folders which were generated by the plugin:
   `./src/api/cookie/`
   `./src/api/cookie-category/`
   `./src/api/cookie-popup/`

3. Run strapi with `yarn develop` or `npm develop`

4. Make the changes according to the documentation inside of:
   `./src/api/cookie/services/cookie.js`
   `./src/api/cookie-category/services/cookie-category.js`

5. Now it should work

This didn't worked for me

@netzpixel Alright, I managed to reproduce the issue when using strapi with typescript. It seems to be a bug with a strapi function which is called by the plugin when generating the content types. Unfortunately, I can't fix it in the plugin right now. But I can help you fixing it manually. Here's how you do it:

Make sure that the attributes draftAndPublish has the value false inside of
./src/api/cookie-popup/content-types/cookie-popup/schema.json
Copy and paste the routes & services folder from for example cookie-category into src/api/cookie-popup/. Then rename these files and the names inside the code accordingly from cookie-category to cookie-popup.
After saving the files, run yarn strapi ts:generate-types
Then last but not least, run yarn develop
Now the errors should be gone and the content types should have the correct fields in it

Worked for me thanks


fix wrong info plist assignment for framework

Apple rejects my app right after uploading it with the following e-mail:
We identified one or more issues with a recent delivery for your app, "TheApp" 1.0 (1). Please correct the following issues, then upload again.
ITMS-90511: CFBundleIdentifier Collision - The Info.plist CFBundleIdentifier value 'me.muukii.Cabinet' of 'TheApp.app/Frameworks/Rideau.framework' is already in use by another application.
I did some research and found that the framework target may use the wrong info.plist file (the one from the demo).

Released as 1.1.4 👍


regen default.nix to update cardano-report-server

@domenkozar https://hydra.iohk.io/jobset/serokell/cardano-pr-1151
the tests on hydra now pass (they where previously failing on most PR's)


Fixed crash in import fixes for augmented modules

fixes https://github.com/microsoft/TypeScript/issues/58907

@typescript-bot test it

The new error might be a positive change but I'm not entirely sure. Module augmentation is a weird beast.
Test case:
// @strict: true
// @module: nodenext
// @moduleResolution: nodenext
// @noEmit: true
// @skipLibCheck: true

// @filename: node_modules/urql/index.d.ts
type AnyVariables =
  | {
      [prop: string]: any;
    }
  | void
  | undefined;

declare function useQuery<Data = any, Variables extends AnyVariables = AnyVariables>(
  args: Variables
): Data;

export { AnyVariables, useQuery };

// @filename: src/index.ts
import { AnyVariables, useQuery } from 'urql';

declare module 'urql' {
  export function useQuery<Data = any, Variables extends AnyVariables = AnyVariables>(
    name: string,
    args: Variables
  ): Data;
}

The important ingredient here is skipLibCheck: true. The reported error gets reported with the current TS version only with skipLibCheck: false. With this branch it errors "consistently" with skipLibCheck and without it. Since the error is reported in both scenario in a .ts file... that's perhaps an improvement?
That said, I'm probably somewhat surprised that this is an error at all. I guess it's different to export a declaration using a modifier or using a separate export declaration but... it really feels like a detail that the user shouldn't be concerned with.

That said, I'm probably somewhat surprised that this is an error at all. I guess it's different to export a declaration using a modifier or using a separate export declaration but... it really feels like a detail that the user shouldn't be concerned with.

I agree that it's a detail that users shouldn't need to worry about. I haven't had time to fully review the PR yet, but I was able to strip your original test case even further (below). It's interesting that the completion works if you remove Container out of the export list in index.d.ts, and instead export the declaration: export interface Container
// @module: nodenext
// @Filename<EMAIL_ADDRESS>//// interface Container {
////   stores: unknown;
//// }
////
//// declare class Piece {
////   container: Container;
//// }
////
//// export { Piece, type Container };

// @FileName: ./augmentation.ts
//// declare module "@sapphire/pieces" {
////   interface Container {
////     client: unknown;
////   }
//// }

// @Filename: ./index.ts
//// import { Piece } from "@sapphire/pieces";
//// class FullPiece extends Piece {
////   /*1*/
//// }

I haven't had time to fully review the PR yet, but I was able to strip your original test case even further (below).

Thanks. I just stopped reducing at the point that test could be easily debugged and proceeded to fixing it 😅 I added this now as an extra test case here.

It's interesting that the completion works if in index.d.ts, you remove Container out of the export list, and instead export the declaration: export interface Container

That's likely related to the directly exported Container having .exportSymbol. The local symbol that gets exported through a separate export declaration doesn't have it.

Is there any progress on this? Like, a dev-release that can be installed through NPM with a fix, or maybe a workaround?

Is there any progress on this? Like, a dev-release that can be installed through NPM with a fix, or maybe a workaround?

Once this or another bug fix PR is merged, the nightly build of that day will contain the fix.

The new error might be a positive change but I'm not entirely sure. Module augmentation is a weird beast.
Test case:
// @strict: true
// @module: nodenext
// @moduleResolution: nodenext
// @noEmit: true
// @skipLibCheck: true

// @filename: node_modules/urql/index.d.ts
type AnyVariables =
  | {
      [prop: string]: any;
    }
  | void
  | undefined;

declare function useQuery<Data = any, Variables extends AnyVariables = AnyVariables>(
  args: Variables
): Data;

export { AnyVariables, useQuery };

// @filename: src/index.ts
import { AnyVariables, useQuery } from 'urql';

declare module 'urql' {
  export function useQuery<Data = any, Variables extends AnyVariables = AnyVariables>(
    name: string,
    args: Variables
  ): Data;
}

The important ingredient here is skipLibCheck: true. The reported error gets reported with the current TS version only with skipLibCheck: false. With this branch it errors "consistently" with skipLibCheck and without it. Since the error is reported in both scenario in a .ts file... that's perhaps an improvement?
That said, I'm probably somewhat surprised that this is an error at all. I guess it's different to export a declaration using a modifier or using a separate export declaration but... it really feels like a detail that the user shouldn't be concerned with.
I'm also not sure how to even augment this correctly since this is not allowed

The new error might be a positive change but I'm not entirely sure. Module augmentation is a weird beast.
Test case:
// @strict: true
// @module: nodenext
// @moduleResolution: nodenext
// @noEmit: true
// @skipLibCheck: true

// @filename: node_modules/urql/index.d.ts
type AnyVariables =
  | {
      [prop: string]: any;
    }
  | void
  | undefined;

declare function useQuery<Data = any, Variables extends AnyVariables = AnyVariables>(
  args: Variables
): Data;

export { AnyVariables, useQuery };

// @filename: src/index.ts
import { AnyVariables, useQuery } from 'urql';

declare module 'urql' {
  export function useQuery<Data = any, Variables extends AnyVariables = AnyVariables>(
    name: string,
    args: Variables
  ): Data;
}

The important ingredient here is skipLibCheck: true. The reported error gets reported with the current TS version only with skipLibCheck: false. With this branch it errors "consistently" with skipLibCheck and without it. Since the error is reported in both scenario in a .ts file... that's perhaps an improvement?
That said, I'm probably somewhat surprised that this is an error at all. I guess it's different to export a declaration using a modifier or using a separate export declaration but... it really feels like a detail that the user shouldn't be concerned with.
I'm also not sure how to even augment this correctly since this is not allowed

This new error seems "correct" in that those two useQuery declarations should be considered overloads of the same function, but the error itself is of course wrong, because they are both exported, even though TypeScript doesn't think so. This last part is a bug tracked by #58756.

having the same issue, is this ready to merge?

superseded by https://github.com/microsoft/TypeScript/pull/59582


How to update user agent ?

Some websites don't allow access by saying "out dated browser both android/ios".
How can I update the user agent so that webview uses relatively latest browser ?

Você pode definir um UserAgent:
<WebView
     userAgent='Mozilla/5.0 (Linux; Win64; x64; rv:46.0)r Gecko/20100101 Firefox/68.0''
/>

This UserAgent works for my to WhatsApp Web.

Updating the user agent (which you can do as @joelemanoel demonstrated) won't change the actual WebView version being used, only the version that it claims to be. I suppose if that's what those sites are using to detect whether things are "out dated," then you could use that to fool them... but if they're actually using feature detection or something, it wouldn't make any difference.
I've never seen that error before though so have no idea what the sites you're trying to use are expecting.


Use two separate .pylintrc files for nestor_api and tests

Really open to discussion on this PR as it is not the optimal solution (see description below) but having lint rules different between tests and "classic" source code does not seem that crazy, in my opinion.
Lint rules start to diverge between "real" source code and tests. To avoid cluttering test code with a lot of pylint disable rules, use a separate .pylintrc file.
To be replaced by a better solution using inheritance if this Pylint issue is ever resolved

In my opinion, I don't think having two pylint files is a bad thing. I would explore if there's a chance to somehow inherit the one we use for the source code and then disable the rules we don't need for the test .pylintrc ? Not sure if .pylint would allow that flexibility though or make it easy.


When LB is updating NICs to point at it, it'd be good to update them in parallel

right now, the updates are sequential
[ref: LoadBalancerImpl#afterCreating()]

attempted, but the basic issue turns out to be that Azure intentionally prevents the NICs of VMs from the same availability set from being updated in parallel (presumably because of the implications of what an availability set is about), so the current behavior seems to be by design.


Always wait for currently executing operations to finish

We should always be waiting until currently executing operations have completed before we set outputStream to nil, and avoid another concurrentOperation from accessing a nil outputStream.
Per the documentation on cancelAllOperations: https://developer.apple.com/documentation/foundation/nsoperationqueue/1417849-cancelalloperations
Canceling the operations does not automatically remove them from the queue or stop those that are currently executing

The onus for this change is a persistent but random crash on L241 of WebSocket.swift caused by output stream being nil https://github.com/daltoniam/Starscream/blob/a2ed45c0b2f996cb8c335c4f270ecc68c3bd4c0f/Sources/Starscream/WebSocket.swift#L241

good call 👍

This looks right to me, but it also looks like it duplicates logic in https://github.com/daltoniam/Starscream/pull/651 ?

This prevents the issue at the source rather than having if !connected checks everywhere

I'm going to go ahead and close this out as it is related to the old 3.X.X codebase. Thanks again for the PR!


remove dynamic log messages

We have a few of these left and they make log analysis difficult.
r: @jwolski @rf

:+1:

lgtm. thanks for this.


Possible to reposition the connecting nodes

I want my flow diagram to go from top to bottom, currently, the nodes are positioned left and right of the box, is there a way to position them top and bottom so that I can create a top-to-bottom flow diagram?

Found this issue which is a dupe of mine.


Question concerning sequence parallelism.

Hello. I am curious if it would be possible to implement Megatron-style sequence parallelism in the repository.
Sequence parallelism is important for reducing activation memory, which is difficult to distribute across GPUs otherwise.
The greatest benefit of using sequence parallelism is that activation checkpointing, which can increase training times by 30%, could be skipped. This would be highly beneficial but I am not sure if this could be made compatible with torch.compile.
Many people working on large-scale training would be very interested if this feature could be added.
Many thanks in advance!

Hi! Thanks for the question. I've been taking a look at the implementation used in Megatron, and it looks like it'd be a similar amount of effort to our current Tensor Parallelism implementation, which means it should be doable! I'll need to dive deeper to see if there might be any issues with torch.compile() though...

@ani300 Thank you for your quick response! I am greatly looking forward to the feature.

Hello! Megatron has recently announced "context parallelism", an extension of sequence parallelism that splits activations along sequences even more than the original sequence parallel.
Link 1: https://docs.nvidia.com/megatron-core/developer-guide/latest/api-guide/context_parallel.html
Link 2: https://oslo.eleuther.ai/CONCEPTS/parallel_context.html
Would it be possible to implement these in the IBM FMS Llama models for training?
I believe that they would be very helpful for training large models and/or long sequences.
The biggest challenge that I see is that different communication collectives would have to be used during forward and backward, which may be difficult to implement in a way compatible with torch.compile.
I think that many users would be interested in this feature as activations can take up large portions of memory during training, however.


AccessibilityManager should be optional

I noticed that AccessibilityManager is enabled by default in dev branch. I really think that there should be a way to disable AccessibilityManager.js within a PixiCanvas. It adds unnecessary overhead by introducing DOM manipulation. This is really important since the only reason we're using Pixi is to get rid of DOM changes which lead to layer compositing and paint executions which are relatively expensive in our target devices (mobile) especially since they're not needed.

Thanks for the heads up @mathatan. The accessibility layer should be not effect the DOM unless there are actually have any accessible items in your pixi scene. (All elements are not accessible by default)

closing for now, let me know if if this is still an issue @mathatan!