Process (various kinds of) target data similarly to input data

The idea is that whatever perturbations are applied to the input are reflected in the target data
Scenarios:

Input
Target

Audio
class(es), fixed length, not correlated with the input length. Low priority.

Audio
Time series of class(es). E.g. predict class for each frame of 25 ms with hop size 10 ms. Medium priority.

Audio
Audio (length same as the input). This one has the highest priority

Nice! This is definitely THE feature that would make me switch to torch-audiomentations.

We should make examples of what the API should look like in each scenario

Yeah, I agree that this would be super cool, but how would it look like? @hbredin do you have API ideas in mind?

The last one, "Audio (length same as the input)" is supported already by doing this:
augment = ExampleTransform(...)

augment(samples, sample_rate)
augment.freeze_parameters()
augment(other_samples, sample_rate)
augment.unfreeze_parameters()

We can refine the API for this scenario later

Interesting!
I get a feeling that it could blow up in complexity if we want to cover all use cases in one class. Maybe it makes sense to make separate "variants" of each transform? Or should we try to handle the various cases in one class?
I had a quick look at your draft PR, and my first thought was that it introduces breaking changes in all transforms (they return a tuple instead of a tensor), which then again led me to check out how computer vision data augmentation libs do it. For example, albumentations has the power to process a target (image/mask, bounding boxes or set of points) in the same way as the input image. In albumentations each transform returns a dictionary, which leaves some flexibility in what is included in the returned value. Maybe that's a useful pattern to adopt here?
# basic example without target
transformed = transform(image=image)
transformed_image = transformed["image"]

# basic example with a target that is a mask image
transformed = transform(image=image, mask=mask)
transformed_image = transformed['image']
transformed_mask = transformed['mask']

In particular, it is not clear to me what per_samples, per_channel, per_batch would mean for such transforms.

Could you elaborate on what feels unclear?
Anyway, I think it would make sense to first design the API, then implement it for a simple transform, like Shift or TimeInversion. also, if we're going to make backwards-incompatible (breaking) changes, it would be nice to release a version with future warnings first.

I get a feeling that it could blow up in complexity if we want to cover all use cases in one class. Maybe it makes sense to make separate "variants" of each transform? Or should we try to handle the various cases in one class?

We should probably start by listing the type of targets used in audio.
I personally can't think of any that cannot be shaped as one of the three you mentioned in the original issue.

I had a quick look at your draft PR, and my first thought was that it introduces breaking changes in all transforms (they return a tuple instead of a tensor),

Actually, I made sure not to break the user facing API -- only the internal methods apply_transform and randomize_parameters have changed. I only had to change a few unit tests that were calling apply_transform directly. Any tests that used the augment(samples, sample_rate) API passed.
It only returns a tuple when the user passes the additional target=... argument.

which then again led me to check out how computer vision data augmentation libs do it. For example, albumentations has the power to process a target (image/mask, bounding boxes or set of points) in the same way as the input image. In albumentations each transform returns a dictionary, which leaves some flexibility in what is included in the returned value. Maybe that's a useful pattern to adopt here?

It would also mean breaking the API right? I really like the current simple perturbed_samples = augment(samples).

In particular, it is not clear to me what per_samples, per_channel, per_batch would mean for such transforms.

Could you elaborate on what feels unclear?

I was refering to the original transform that made me think about this PR: SumTwoSamples.
What would per_batch mean for such a transform? It would return samples unchanged, right?

Anyway, I think it would make sense to first design the API, then implement it for a simple transform, like Shift or TimeInversion. Also, if we're going to make backwards-incompatible (breaking) changes, it would be nice to release a version with future warnings first, even though we're still in alpha 🤓

As stated a few lines above, PR #123 does not make breaking changes, as in: "code that relies on the documented user facing API will still work". Custom augmentations would need to be updated though -- unless we add a supports_target attribute that defaults to False and make sure to honor it in BaseWaveformTransform.forward.
PR #123 does implement target support for TimeInversion.

We should probably start by listing the type of targets used in audio. I personally can't think of any that cannot be shaped as one of the three you mentioned in the original issue.

Agreed. So it comes down to the shape of the time series data then. I don't think I have any better suggestion than the shape you suggested in your PR.

Actually, I made sure not to break the user facing API

Good! I haven't looked at it in detail yet ^^ I might have time for that on friday. Thanks for your patience :)

It only returns a tuple when the user passes the additional target=... argument.

So the output type is either tensor or tuple, based on the parameters given? I'm not sure if this is a good pattern. Do you know of other python libraries that do it like that? Usually functions give the same output type (or sometimes None) regardless of the inputs.

It seems imgaug uses this pattern (returns a tuple of a target is provided):
seq = iaa.Sequential([
    iaa.Crop(px=(0, 16)), # crop images from each side by 0 to 16px (randomly chosen)
    iaa.Fliplr(0.5), # horizontally flip 50% of the images
    iaa.GaussianBlur(sigma=(0, 3.0)) # blur images with a sigma of 0 to 3.0
])

for batch_idx in range(1000):
    # 'images' should be either a 4D numpy array of shape (N, height, width, channels)
    # or a list of 3D numpy arrays, each having shape (height, width, channels).
    # Grayscale images must have shape (height, width, 1) each.
    # All images must have numpy's dtype uint8. Values are expected to be in
    # range 0-255.
    images = load_batch(batch_idx)
    images_aug = seq(images=images)

seq = iaa.Sequential([
    iaa.Multiply((1.2, 1.5)), # change brightness, doesn't affect BBs
    iaa.Affine(
        translate_px={"x": 40, "y": 60},
        scale=(0.5, 0.7)
    ) # translate by 40/60px on x/y axis, and scale to 50-70%, affects BBs
])

# Augment BBs and images.
image_aug, bbs_aug = seq(image=image, bounding_boxes=bbs)

albumentations on the other hand, always returns a dict

Maybe we should post a vote on those two options in Slack?

# Always return a dict (inspired by albumentations - 9.9k stars, actively maintained)
## pro: Consistent output type regardless of input. Makes type hinting and code changes easier.
## pro: Gives more flexibility in what we can include in the output. For example: output sample rate could be included without breaking API change
## con: More lines of code
## con: When we change our outputs to dict, it will be a breaking change in the user-facing API

# Example without target
transform = Shift()
transformed_audio = transform(my_audio, sample_rate)["audio"]

# Example with target
transform = Shift()
transformed = transform(my_audio, sample_rate, target=my_target, target_rate=my_target_rate)
transformed_audio = transformed["audio"]
transformed_target = transformed["target"]

# Return tensor or tuple depending on input (inspired by imgaug - 12.4k stars, abandoned project)
## pro: Fewer lines of code
## pro: No breaking change in the user-facing API
## con: Less flexibility in what we can include in the output
## con: Return type depends on the input. This could be a source of bugs in users' code.

# Example without target
transform = Shift()
transformed_audio = transform(my_audio, sample_rate)

# Example with target
transform = Shift()
transformed_audio, transformed_target = transform(my_audio, sample_rate, target=my_target, target_rate=my_target_rate)

I posted it in asteroid and thesoundofai. At the moment all 5 votes are in favor of dict. @mpariente suggested that we add support for attribute access
If I should conclude early, I think it's best to return an ObjectDict instead of a tuple or a tensor. ObjectDict behaves like a dict, but also supports access by attribute, so the two following lines would give the same result:
hello = my_object_dict.my_property
hello = my_object_dict["my_property"]

Adding a PR for that here


Update teams-contact-center.md

Fixing important typo

@JohanFreelancer9 Copy editing is needed for this PR. Thanks.


Vulnerability roundup 85: libupnp-1.12.0: 1 advisory [7.5]

search, files

[ ] CVE-2020-13848 CVSSv3=7.5 (nixos-unstable)

Scanned versions: nixos-unstable: 22c98819ccd. May contain false positives.

Fixed in 1.12.2  - but upstream never actually released that version! https://github.com/pupnp/pupnp/commit/c805c1de1141cb22f74c0d94dd5664bda37398e0
Note: 1.12.2 was never released - another X months of commits were added and 1.14.0 was born.
I can't see any reason why we can't go to 1.14.0 but I would like a second and third opinion.
In theory we could just backport the security fix...
Thoughts?

The needs_reviewer label is for marvin and should only be applied to PRs by the bot. Removing it here.

thanks for the heads-up @timokau - is there a list of labels that are bot-specific?

No, unfortunately not. Marvin uses the awaiting_* and needs_* labels. ofBorg sets a bunch of labels, for example for the rebuild count. I think it doesn't hurt much to change those manually though.
It doesn't really hurt much to change marvin's labels manually either, it can just be a bit confusing when using them to search for PRs to review.

#93048 updated libupnp to 1.14.0.


What is the difference between 'Usage Policy' and License?

Since Usage Policies is the 'new' part of what IDS is capable of doing, I think it needs to be explained how it relates to 'licenses' like e.g. 'Creative Commons' and other, also proprietary licenses (paper contracts).
Opinions on that?

Licenses are a legal aspect and therefore part of the legal layer of a dataspace. However, a usage policy can reference a license or even enforce a license.
If a data plane is used where the enforcement of the license is technically not possible or insufficient then the obligation to follow the license agreement moves into the legal domain.
This is no different from data sharing agreements/licensing agreements without dataspaces. If one party violates the license there will be legal consequences.

I totally agree: Usage policies are technical means to enforce or, if not possible, at least document usage agreements. They can refer to a license, but are not necessarily the same.


[DOC] New content: Install OpenSearch Dashboards

Signed-off-by: vagimeli<EMAIL_ADDRESS>Description
Create new content for installing OpenSearch Dashboards
Issues Resolved
#941
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Current docs published on doc site


Erdtree on ArchLinux broken

It appears that the official ArchLinux package ships a broken erdtree. Or at least I don't seem to get it working.
I always get this error:
$ /usr/bin/erd                                                                                 ✔     18874  10:58:37 
error: unexpected argument '--inverted' found

  note: to pass '--inverted' as a value, use '-- --inverted'

Usage: -- <DIR|--color <COLOR>|--disk-usage <DISK_USAGE>|--follow|--human|--no-ignore|--icons|--long|--group|--ino|--nlink|--octal|--time <TIME>|--time-format <TIME_FORMAT>|--level <NUM>|--pattern <PATTERN>|--glob|--iglob|--file-type <FILE_TYPE>|--prune|--sort <SORT>|--dir-order <DIR_ORDER>|--threads <THREADS>|--unit <UNIT>|--layout <LAYOUT>|--hidden|--no-git|--completions <COMPLETIONS>|--dirs-only|--no-config|--no-progress|--suppress-size|--truncate>

For more information, try '--help'.

I have
$ pacman -F /usr/bin/erd
usr/bin/erd is owned by extra/erdtree 3.0.2-1

Any clues or advice?

Do you happen to have a config file? If so --inverted needs to be --layout inverted. Unfortunately it wasn't made super clear in the release notes, but let me know if that works for you.

Doh! That was it. Thanks for the quick reply :)


Add DBTX Param config option

Problem
I'd like to be able to define a type that wraps a small interface along the lines of
type WidgetInserter interface {
    InsertWidget(ctx context.Context, db DBTX, name string) error
}

Using sqlc to generate the underlying code today would give a *Queries that has these two relevant methods:
InsertWidget(ctx context.Context, name string) error
WithTx(tx *sql.Tx) *Queries

Because *Queries operates against an internal DBTX, to use InsertWidget against a pre-existing transaction then requires creating a new *Queries by use of its WithTx method. But because WithTx returns *Queries, it's non-trivial to keep this as just an implementation detail—to have an interface that doesn't expose the underlying *Queries requires either:

manually adding variant implementations of WithTx that return the desired interface (which also requires now that the interface be accessible to the generated package, instead of being defined potentially only at the consumer site), or
requiring that the interfaces being used compose the entire generated query set (i.e. the generated Querier instead of just one of its methods)

Some of the why for both of these is covered in https://github.com/kyleconroy/sqlc/issues/383 and https://github.com/golang/go/issues/7512.
Proposal
Support a new configuration parameter dbtx_param that modifies the generated method sets to provide methods like shown in WidgetInserter. If set to true, the generated *Queries omits storing a DBTX as a struct field and requires it be passed in to all method calls. In doing so, it allows callers to easily provide the connection for standalone use or for use as part of a broader transaction and makes it easy for the surrounding code to use a narrowly defined interface.
Notes
This PR's current implementation treats emit_prepared_queries and dbtx_param as mutually exclusive config options. The thought being that since prepared queries are prepared against a particular database connection, and because executing the queries would now use a caller-provided connection, these two connections may end up distinct and void the value of preparing the queries. The implementation can be changed to support two the config options together, it'd just be more involved to do so.

Instead of adding an test case in the examples, can you create one in the internal/endtoend/testdata directory?
I also think we can improve the configuration option name. Instead of dbtx_param, I'd pick emit_methods_with_db_argument. More wordy, but more clear. Thoughts?

Appreciate the feedback, thanks. I agree that name is more clear (and more consistent). I'll push up another commit accordingly.


fix(controller): return 403 when a user does not have permission

closes #2858
rebased off of #2898 since those are the main blockers for this change.

This needs to be rebased, but LGTM!

rebased

note that the code comes straight from https://github.com/tomchristie/django-rest-framework/blob/a7567efa8d6fd008ba0a48f0e8fa7028703af386/rest_framework/mixins.py#L39-L46

:ship:


irssi: 1.4.1 -> 1.4.2

Description of changes
https://irssi.org/2022/07/17/irssi-1.4.2-released/

Things done

Built on platform(s)

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

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

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

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.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
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

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

1 package failed to build:

irssi_fish

1 package built:

irssi

irssi_fish

I fixed this in #182629, but this is unrelated to this bump -- it's been broken for a while.


Added paper and bib

Hi Peng!
I think this is ready for your review. I left one section for you, where you can describe the structure of the code for Xspline.
Best wishes,
Sasha.

Replace this PR by #23, that way we can all editing the branch and the PR.


.grid-bottom classes are flexbox?

At 8:55 mins into the video,  you start working on moving the main nav down to the bottom of the header.   To do that you reference the .grid-bottom class.  I took notes on your entire modular code series, and I didn't recall seeing anything about this.  So I went to the code here on the repo and found this:
.grid-bottom {
	-webkit-align-items: flex-end;
	-ms-align-items: flex-end;
}

// opera and .unit code here

.grid-bottom .unit {
	vertical-align: bottom;
}

I brought these classes into the demo project i am using to work this and nothing happens for me, the nav does not move.
First thing that strikes me is that these are flexbox classes.  I don't recall you mentioning that flex-box is necessary to get this grid system to work.  Also,  I'd prefer not to use flexbox until compatibility issues get better -- and definitely not without a strong fallback.
Do you have a more conventional strategy for moving these items vertically in the grid?  ie what is the most widely supported responsive and reliable way to make this happen - thanks ..

It’s likely at some point that I switch to using my grid generator, “Gridifier”. (I fell like I mention and show it in one of the videos but can't remember which one.) The videos show the basics of how to set up a responsive grid but when making websites I almost always just use the generated version.
https://thomasjbradley.github.io/gridifier/
It uses a combination of display: inline-block (for older browsers) and display: flex (for newer browsers) to get the most features.

Yes I noted that you use a generator,  however I'm implementing everything by hand and need to thoroughly understand how the mechanics of this work.
I've actually transcribed most of your modular videos to notes - and have converted this grid system into a Sass framework I'm building.   I'm a bit stuck on this issue right now, its key to getting grid units to reliable move vertically inside grid rows.
How are exactly are you using display: inline-block in this context?  thanks

You can definitely get the units to move to the bottom and the top using display: inline-block.
The key is to set the .unit to display: inline-block instead of float. But that creates extra space between each grid unit because the space around the HTML tags counts. So, the Gridifier changes the letter spacing on .grid to a negative number, then the .unit classes set the letter spacing back to normal.
This is similar to how Yahoo’s Pure framework's grids work: http://purecss.io/grids/

Great!  That works well and I was able to finish the tutorial from there with few issues.
Here's an excellent explanation of how this method works:
http://blog.purecss.io/post/60789414532/how-we-improved-grids-in-pure-030


Upgrade the solution to use VS 2015 tooling

Upgrade the solution and projects to use Visual Studio 2015. The new Visual Studio has some nice tools to help writing WPF code, I think I could do with the extra help.

Nothing much to the upgrade in the end. Visual Studio 2015 reads Visual Studio 2013 solution and project files quite happily. Only part of the upgrade was changing the default version to be used when opening the solution file, everything else is exactly the same.


Hosted clusters are not deployed on Rancher Hosted setup after upgrade

Rancher Server Setup

Rancher version: 2.6-head commit id: ba43472 tenant on 2.5.9
Installation option (Docker install/Helm Chart): Helm

If Helm Chart, Kubernetes Cluster and version (RKE1, RKE2, k3s, EKS, etc): k3s on k3s

Proxy/Cert Details: rancher generated

Information about the Cluster

Kubernetes version: v1.20.10+k3s1
Cluster Type (Local/Downstream): both downstream tenant and hosted rancher local

Describe the bug
Hosted clusters are not deployed on Rancher Hosted setup
To Reproduce

Deploy EKS v2/AKS v2
Clusters are stuck in Provisioning state with message Waiting on eks crd to be initialized

Rancher server logs:

2021/09/21 06:56:46 [ERROR] error syncing 'c-cnm8d': handler aks-operator-controller: waiting aks crd to be initialized, cluster: c-cnm8d, handler cluster-provisioning-operator: can't find system project, requeuing
--
Mon, Sep 20 2021 11:56:47 pm | 2021/09/21 06:56:47 [ERROR] error syncing 'c-fx4vq': handler eks-operator-controller: waiting eks crd to be initialized, cluster: c-fx4vq, handler cluster-provisioning-operator: can't find system project, requeuing

On 2.5.9 hosted rancher running 2.6-head commit id: 10dfee4 tenant rancher
Provisioning of GKE/EKS/AKS v2 clusters work.

The solutions is Create a NameSpace cattle-fleet-system if you don´t have in your Cluster.


Compliance Policy Issue

Hi Team,
I have deployed the destreamer application perfectly. Due to some ad-hoc compliance policy issues, the browser asked for extensions installations which are not allowed in automated-test browser's. I tried changing the executable path in destreamer.ts & token.ts files with the local browser path as instructed in the ReadME.md.
But still, no luck throwing the same error. Will the manual addition of token solves the problem? if so, how to get the token from the Microsoft streams browser?

I have the same problem here. Any updates?

The trick is to change the default browser (Edge) in which multifactor authentication happens for the first time. And later it doesn't ask any.


bitcount argument to shift_out()

Changes allow arbitrary bit count to be handled by shift_out().  Default parameter value preserves old behavior.  Note this does fail when bitcount > 2^31

@iraytrace  Thanks for adding the exception. I can't merge this until the PyLint check for Travis passes (pylint log here: https://travis-ci.com/adafruit/Adafruit_CircuitPython_SimpleIO/builds/117231893#L556).

LGTM!


Phan should differentiate between boolean in phpdoc and boolean in actual method signature

The below snippet of code emits no errors when analyzed with phan
<?php

function foo33() : boolean {
    return false;
}
foo();

Attempting to execute this results in
Fatal error: Uncaught TypeError: Return value of foo33() must be an instance of boolean, boolean returned in badbool.php:4
This should warn that bool cannot cast to the class named boolean.
src/Phan/Language/Type.php seems to cause this issue
When fixing this, annotations such as '@return int|boolean' should continue working.
Suggested fix: pass bool $isPhpdoc = false to functions such as Type::make(), Type::fromNamespaceAndName(), Type::canonicalNameFromName(), etc.

Same bug exists for callback and integer - (float works as expected)

Fixed in https://github.com/etsy/phan/pull/529


replace DefinitionAfterGroup with better approach, as per discussion

[https://github.com/Azure/azure-sdk-for-java/pull/737/files/261adf1f98e173b5ad59253b4668ce6af804979c#r64965905]

wound up killing this whole thing altogether due to complexity


Added example patterns of the tenant url value

Why:
Closes [issue link]

What's being changed (if available, include any code snippets, screenshots, or gifs):
Added patterns of the tenant url value, this info does not exist explicitly in either MicrosoftDocs or GitHub docs
Check off the following:

[x] I have reviewed my changes in staging (look for the "Automatically generated comment" and click the links in the "Preview" column to view your latest changes).
[x] For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

[ ] This pull request impacts the contribution experience

[ ] I have added the 'writer impact' label
[ ] I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

Thank you for looking into my suggestion. It makes sense to put in specific Microsoft doco. I see Step 2 has highlighted this detail.

You're welcome, and thanks for working with me 😄 I'll go ahead and close this—let us know if you see any further opportunities to improve the documentation 🙏🏻


ecr-credential-provider RPM CI builds

This is a first attempt at putting the correct prerequisites in place to build the ecr-credential-provider rpm in CI.
We may need changes down the line, but I'm not aware of a way to tell CI to use this branch.

/lgtm
/approve


Bug: Tokens sent reporting appears incorrect

Issue
As shown below, I'm seeing it reporting usage of a very large amount of tokens, but the /tokens command suggests it's not doing so.  See highlighted box in the attached screenshot.

Version and model info
No response

Hi, I've been looking for something else but bumped into this related issue https://github.com/paul-gauthier/aider/issues/1023

This issue should be fixed in the latest version.


Add project release config and use Travis build stages.

Refs #378.

@hugovk @claudep To fully automate the release process it's strongly recommended to use setuptools-scm to get the version string from Git during the build process (and effectively allowing to do releases simply by creating a Git tag). That would remove the need to update Python files to bump up the version. This strategy has worked very well with many other Python projects including Jazzband projects. Just want to give you a heads-up that this will contain this change as well.

+1 for setuptools-scm, it makes versioning and releases much easier.
One important thing to note: by default it includes everything from Git in the package, making the releases bigger. If we don't want all that, we'll need to explicitly exclude/prune other files/dirs.
For example: https://github.com/hugovk/pypistats/pull/63

@hugovk I'm glad you approve! That said, from the Python packaging conceptual side speaking, the purpose of source distributions is to ship all files that developers may want to use to inspect a file, including test files etc. So while the dist files may be bigger, they would also be matching the expectation of users.

Sure, that's fine and makes sense! It's probably only a few KB bigger anyway, just wanted to flag it up as it has surprised some people in the past :)

Yep, much appreciated that you're raising this.

Wow, many thanks for pushing that! Packaging stuff has always been a weak point for me, so I'm glad you're taking the lead on that part.


Missing stdlib modules

What are the plans for missing stdlib modules.

The plan is to support all the same stdlib modules that CPython has. If you have a specific module you're interested in, please file an issue for that module. Thanks!


[BugFix] Fix Struct serialization bug

What type of PR is this：

[x] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Which issues of this PR fixes ：

In this pr:

We don't serialize Struct's field name anymore, because the field name is created from TypeDescriptor, and doesn't need to transfer by the network.
Fix struct serialization error implementation.

Problem Summary(Required) ：

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto backported to target branch

[x] 2.5
[ ] 2.4
[ ] 2.3
[ ] 2.2

@Mergifyio backport branch-2.5


BUG Use civis-jupyter-notebook which doesn't clobber dependencies

The versions of civis-jupyter-notebook <0.2.4 have strict requirements which, for example, will force a downgrade to civis==1.6. Update to a bugfix version with more permissive requirements.

The civis-jupyter-notebook installation here modifies a couple of already-installed packages:
Installing collected packages: notebook, ipython, civis-jupyter-extensions, civis-jupyter-notebook, cloudpickle
  Found existing installation: notebook 5.0.0
    DEPRECATION: Uninstalling a distutils installed project (notebook) has been deprecated and will be removed in a future version. This is due to the fact that uninstalling a distutils project will only partially uninstall the project.
    Uninstalling notebook-5.0.0:
      Successfully uninstalled notebook-5.0.0
  Found existing installation: ipython 5.3.0
    DEPRECATION: Uninstalling a distutils installed project (ipython) has been deprecated and will be removed in a future version. This is due to the fact that uninstalling a distutils project will only partially uninstall the project.
    Uninstalling ipython-5.3.0:
      Successfully uninstalled ipython-5.3.0
  Found existing installation: cloudpickle 0.5.1
    Uninstalling cloudpickle-0.5.1:
      Successfully uninstalled cloudpickle-0.5.1
Successfully installed civis-jupyter-extensions-0.1.3 civis-jupyter-notebook-0.2.4 cloudpickle-0.3.1 ipython-5.5.0 notebook-5.2.1

I think this is okay.


Low contrast code blocks.

browser: Firefox 89.0 on Linux.
in fact. playing around with the default fonts in the browser, maybe this is a Noto Mono issue. changing the font to Droid San Mono appears to "fix" it.
Noto Sans Mono:

Droid Sans Mono:

either way the colors are probably not ideal. Maybe it's better to set an explicit preformatted text font family?

Can you check it now? I just pushed a massive improvement to how code blocks are rendered.

LGTM :+1:


💬 RFC: New Frontend System: naming considerations for 'blueprint', 'feature', 'extension'

🔖 Need
I have begun using the new frontend system, and the use of some of the terms for the building blocks is often hard to read in the example code and understand conceptually.
There is general confusion on my part between the use of the following terms in the code and across the documentation:

'feature'
'plugin'
'extension'
'blueprint'

After spending hours in the documentation, my understanding is the following:
'feature': new term for any frontend piece of functionality
'plugin': a type of feature that is a collection of other features
'extension': a feature attached to a plugin
'blueprint': a PluginFeatureFactory with defaults for a particular frontend scenario
🎉 Proposal
In the new frontend system, rename the uses of 'extensions' to 'features'. If this is not recommended, it would be nice to have some clarity when one is used (e.g. createApp({ features })) versus when the other is used (e.g. createFrontendPlugin({ extensions })).
Possible Clarifying Fixes:

Rename extensions to pluginFeatures throughout all new frontend system. For example, you pass in pluginFeatures to createFrontendPlugin.
Rename Blueprint to PluginFeatureFactory or FeatureFactory. The idea of blueprints is rather generic. It seems to me preferable to use a known term like factory since that is the software design pattern that is being employed.

It is quite possible I am not making any sense because I did not understand the existing documentation. Please note that if something above does not make sense, this is a great opportunity for us to just make the documentation and code comments a little clearer!
〽 Alternatives
Updating documentation to clarify my confusion above!
❌ Risks
The biggest risks with any name changes is of course is backwards compatibility and making sure all the existing codebase is consistent.
👀 Have you spent some time to check if this RFC has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Hey @joshjung  :wave:
Thanks for raising this! Good to keep us in check!
So I think we can probably clarify a few things here and try and get the docs updated to reflect that.
So a Feature is simply a Plugin or a Module, this now aligns perfectly with how the Backend System works.
And a Plugin or a Module is a collection of Extensions.
I'm a little torn on the rename of Blueprint but erring on the side of not. Wondering if we can just update the docs to talk more about ExtensionBlueprints rather than just Blueprints which might clear some things up for what they're actually used for. We could have called them ExtensionFactories but it gets a little unfortunate for the consumption side maybe, for ScaffolderFieldExtensionFactory.make rather than ScaffolderFieldBlueprint.make?
Thinking that the name of Blueprint is quite unique to Backstage too, which I think is a positive too, so would like to keep that naming if possible to be honest. Maybe some better diagrams how things fit together could help also?

Hey @joshjung 👋
Thanks for raising this! Good to keep us in check!
So I think we can probably clarify a few things here and try and get the docs updated to reflect that.
So a Feature is simply a Plugin or a Module, this now aligns perfectly with how the Backend System works.
And a Plugin or a Module is a collection of Extensions.
I'm a little torn on the rename of Blueprint but erring on the side of not. Wondering if we can just update the docs to talk more about ExtensionBlueprints rather than just Blueprints which might clear some things up for what they're actually used for. We could have called them ExtensionFactories but it gets a little unfortunate for the consumption side maybe, for ScaffolderFieldExtensionFactory.make rather than ScaffolderFieldBlueprint.make?
Thinking that the name of Blueprint is quite unique to Backstage too, which I think is a positive too, so would like to keep that naming if possible to be honest. Maybe some better diagrams how things fit together could help also?

If I may push back just a little bit from a "developer experience" perspective. Purely as an FYI, Blueprint is a super common name for any gaming industry coders :) And generally it is used in reference to a prefabricated physical 3D object. That's where my brain went right away.
My initial thought would be that the naming of the object should most closely resemble the software design pattern that is followed:
https://refactoring.guru/design-patterns/creational-patterns
In this case, it probably is closest to a prototype or an abstract factory, maybe. Maybe renaming Blueprint is a bridge too far (good movie) for now. However, going forward I think that as a general principle for the Backstage library, naming things to match the software design pattern would be a good approach to help incoming software engineers quickly understand what is happening.
All of that rambling aside, I 100% agree that calling them ExtensionBlueprint would be a big improvement! My brain is immediately going to think "oh, what's an extension".

Note: I know this is pedantic, but I also think it would help a lot for newcomers if they were called "AppFeatures" instead of "Features" and if they were called "PluginExtensions" instead of just "Extensions".
The ambiguity in these words makes it super hard to read the docs!
Let me give a specific example of confusion in the docs using the current naming. According to the new system a "Feature" is a "Plugin or a Module".
In the introductory terms in the new frontend system - in one of the very first documents -,there is the following sentence (see https://backstage.io/docs/frontend-system/architecture/index):
"Plugins provide the actual features inside an app."
Because the word "Feature" is now a word used to describe a Plugin or a Module, a person could easily be confused for a second and wonder how a plugin could both be a feature and also provide features. Does this mean a plugin can have multiple child plugins or modules?
There is also a problem of inconsistency when using the word "extension". For example, in the docs and code, sometimes it is called a "plugin extension" and other times it is just called an "extension". On the surface this might seem innocuous, but if I see "plugin extension" used, I would expect to find an object somewhere in the library called "PluginExtension". I do:
const pluginExtensions = new Map<
    LegacyBackstagePlugin,
    ExtensionDefinition[]
  >();

Now, since it is called pluginExtensions, my initial thought is that ExtensionDefinition is something different than a plugin extension. This is incorrect. ExtensionDefinition is actually a PluginExtensionDefinition.
My recommendation would be to define terms and variable names a little more precisely, even if it means they are more lengthy, simply to reduce the possibility for confusion. And then to make sure the docs team is consistent in the use of these terms. Like for example by highlighting throughout the docs terms like "Plugin Extension" so that people know it is a system-wide term.

Note, I have already begun a new PR here to try and address things:
https://github.com/backstage/backstage/pull/26934


What does toObject do?

A lot of sb-edit primitives currently have a toObject function, which is not documented and never called. What is this function supposed to do?

/cc @PullJosh

Excellent question. 😛 It converts the class instance into a plain JS object. I thought it was being used in the tests to create snapshots, but apparently not. Should probably be removed. (Can't forget to remove them all!)

I just remembered what toObject does. :P Not a concern, though. That code doesn't belong here.


UI - TCP load balancer still shows stickiness options

When selecting TCP for the load balancer, stickiness options are still present in the UI. Maybe for TCP stickiness could be based on IP but certainly not cookie or existing cookie.

@alena1108 Is this stickiness option supported in the API for load balancers with TCP?

No; they work by reading/setting cookies and TCP mode means it is blindly copying the message because haproxy will have no idea what protocol it it.  The stickiness options should be grayed out unless there is at least one http listener.

v0.37.0-rc1
Verified Fixed. When selecting a tcp protocol in load balancer, the stickiness is disabled.


Use reference types where possible

Hi
This PR changes const parameters of big things (strings and arrays) to reference instead of value types.
I also changed some internal data loading function to use pointer+length to accommodate both TArray and TArray64 interfaces.
Just adding a & to an already const parameter does not change the Blueprint interface or how the nodes are shown in the Blueprint editor so no Blueprint updates or recompiling required with this change. Similarly the C++ interface does not change and no code update should be needed.
One exception are two changes to the class FglTFRuntimeParser where I changed the array parameters to more flexible pointer+length variants.
If you think these functions are commonly publicly used outside the library, it would make sense to add wrapper functions back in like this:
static FORCEINLINE TSharedPtr<FglTFRuntimeParser> FromBinary(const TArray64<uint8> Data) { return FromBinary(Data.GetData(), Data.Num()); }
static FORCEINLINE TSharedPtr<FglTFRuntimeParser> FromData(const TArray64<uint8> Data) { return FromData(Data.GetData(), Data.Num()); }

Cheers

Thanks a lot!, can you add the wrappers you mentioned ? i would like to not break the current api

While writing the description of the PR I realized that FglTFRuntimeParser isn't internal, as I first assumed, so this makes total sense.
Just updated the PR!


Deleting last node causes node to come back in invalid (bad) pool

Rancher versions: 2.0 master 2/20
Steps to Reproduce:

Create a cluster (any kind) with 1 node
After the cluster has fully provisioned, go to the Nodes list page
Delete the node

Results:  The node is removed and then comes back in an invalid pool (bad pool)

I'm unable to reproduce in the latest master (3/1)
Created a DO cluster with 1 node.
Waited until the cluster was active.
Deleted the node.
The original node doesn't get fully removed and a new node is spun up but it never actually gets setup because the etcd info has been lost.

@tfiduccia I don't think nodes are going back to invalid pools. What I described is still happening, but it seems that eventually you are left with 1 node in removing state.

Can't delete last node in cluster anymore


[Brick] Switch to CMake build support for windows

Recent changes in dmlc's other project makes us feel that cmake might be a more portable solution for maintaining windows projects than vs solutions in https://github.com/dmlc/xgboost/tree/brick
So I am thinking of switching to cmake builds as default build support for windows, I am not expert in this, and would be great to get someone's contribution on it.

The new version is now merged into master #759  with a mingw solution.
However, there is not yet cmake solution yet.


CallKit - Screen not dimming when making calls

Description
When using the latest SDK with CallKit and receiving calls the proximity sensor is triggered and the screen locked/dimmed when approaching my face, but the screen keeps on when making calls.
Steps to Reproduce

make a call
place the device close to the face or cover the proximity sensor with your hand
the screen is still on

Voice iOS SDK
Experienced since pod 2.0.0-beta10
iOS Version
10.3.3
iOS Device
iPhone 6

HI @fabriziomoscon
I tried the latest beta15 but was not seeing the issue both when making or accepting calls.
Could you share with us how & when is the proximity-sensor being turned on and off in the native integration layer of the framework?
I tried to enable the sensor when getting the callDidConnect: callback and tried to disable it when getting the callDidDisconnect: callback by using
  UIDevice* device = [UIDevice currentDevice];
  device.proximityMonitoringEnabled = YES;  // or NO

-bobie

I see,
I am using the react native integration, but usually that doesn't prevent me to follow this repository almost 1:1.
I did not try any additional expression like the 2 lines you posted. I assumed that CallKit was managing the proximity automatically since it is triggered when answering.
If I understand correctly @bchen-twilio you suggest to use the 2 lines you wrote explicitly?

HI @fabriziomoscon
Sorry for the delay of my responding back to you.
Yes, I also thought that CallKit framework should just take care of the proximity sensor but apparently it doesn't seem like so. There isn't documentation from Apple showing how to configure the framework with the sensor.
We'll keep tracking this issue and see if this is due to the way the SDK configures the AVAudioSession. For now yes, I would suggestion you use the lines in your application.
Thanks
-bobie


road_access_test.cpp::RoadAccessWriter_ConditionalMerge fails

./generator_tests
Running road_access_test.cpp::RoadAccessWriter_ConditionalMerge
FAILED
generator_tests/road_access_test.cpp:405 TEST(ExistsConsecutiveLines(buffer.str(), lines)) Car  3       2       Private 12:00-19:00     No      Mo-Su
Car     2       1       Private 10:00-20:00
Car     1       1       No      Mo-Su
 [5: Car 3 2 Private 12:00-19:00 No Mo-Su ]
Test took 141 ms

Running road_access_test.cpp::RoadAccessWriter_Conditional_WinterRoads
FAILED
generator_tests/road_access_test.cpp:459 TEST(ExistsConsecutiveLines(buffer.str(), lines)) Pedestrian   2       1       No      Mar - Nov
Pedestrian      1       1       No      Mar - Nov
Bicycle 2       1       No      Mar - Nov
Bicycle 1       1       No      Mar - Nov
Car     2       1       No      Mar - Nov
Car     1       1       No      Mar - Nov
 [3: Pedestrian 2 1 No Mar - Nov ]
Test took 138 ms

This one is fixed. Now we have "RoadGraph_NearestEdges" failed.


Update sbt-scala-native to 0.4.16

About this PR
📦 Updates org.scala-native:sbt-scala-native from 0.4.4 to 0.4.16
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-native", artifactId = "sbt-scala-native" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.scala-native", artifactId = "sbt-scala-native" }
}]

labels: sbt-plugin-update, early-semver-minor, semver-spec-patch, commit-count:1

Superseded by #111.


Added fullscreen preview for images inside editor

Fixes #1083

Description

Added: Fullscreen preview for images inside editor

Checklist
- [ ] I have made corresponding changes to the documentation.
- [ ] I have updated the types definition of modified exports.

[x] I have verified the functionality in some of the neeto web-apps.
[x] I have added the necessary label (patch/minor/major - If package publish
is required).

Reviewers
@AbhayVAshokan _a

Image: https://github.com/bigbinary/neeto-editor/assets/35297280/b3a5a68a-1628-47df-9e1a-a5ec95997a6a

I will take a look at the styles issue using this image.

@AbhayVAshokan Please let me know if these changes looks good: https://gaagul-gigi.neetorecord.com/watch/54d5696e-2352-4af5-bb7b-d7d2e4dd01fd, We can merge once confirmed.

@gaagul the changes look great!


Conflict between GET handler in +server.js and dynamic routes

Describe the bug
Not sure if it's a bug, but two independant routes handlers are called at the same time :
my routes are like so :
- (admin)
    - admin
      - api
        - route
          - +server.js // <— GET handler that return json
- (public)
  - [path]
    - +page.js
    - +page.svelte
  - ...

I have a GET handler in (admin)/admin/api/route/+server.js which return json data :
In a browser if I go to /admin/api/route I get my json as expected, but also an error in the terminal console that comes from (public)/[path]/+page.svelte, as the (public)/[path]/+page.js load function is also called but it doesn't get it's params.
In the doc here : https://kit.svelte.dev/docs/routing#server-content-negotiation :

GET/POST/HEAD requests are treated as page requests if the accept header prioritises text/html (in other words, it's a browser page request), else they are handled by +server.js

As json is returned by the API route, I am expecting that SvelteKit doesn't treat that route as a page request.
And as there is no +page.svelte in my route API, it looks like sveltekit fallback to the dynamic route which match everything, which is weird as json is returned, and also both routes are in separate parenthesis folders.
However It seems that it only appears in the browser probably because of the accept "text/html", no problem with a fetch method.
(admin)/admin/api/+server.sj

(public)/[path]/+page.js

Reproduction
A minimal reproduction :
https://github.com/anthonyivol/sveltekit-routes-issue/tree/main
Logs
No response
System Info
System:
    OS: macOS 14.4.1
    CPU: (8) arm64 Apple M2
    Memory: 41.48 MB / 8.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 21.4.0 - ~/.nvm/versions/node/v21.4.0/bin/node
    npm: 10.2.4 - ~/.nvm/versions/node/v21.4.0/bin/npm
    pnpm: 9.1.1 - /opt/homebrew/bin/pnpm
    bun: 1.1.8 - /opt/homebrew/bin/bun
  Browsers:
    Brave Browser: <IP_ADDRESS>
    Chrome: 124.0.6367.208
    Safari: 17.4.1
  npmPackages:
    @sveltejs/adapter-auto: ^3.0.0 => 3.2.0
    @sveltejs/kit: ^2.0.0 => 2.5.8
    @sveltejs/vite-plugin-svelte: ^3.0.0 => 3.1.0
    svelte: ^4.2.7 => 4.2.17
    vite: ^5.0.3 => 5.2.11

Severity
annoyance
Additional Information
No response

I can't seem to reproduce this by clicking on the api route link in the reproduction. Are there additional steps to reproduce the issue?
https://stackblitz.com/~/github.com/anthonyivol/sveltekit-routes-issue

I can't seem to reproduce this by clicking on the api route link in the reproduction. Are there additional steps to reproduce the issue? https://stackblitz.com/~/github.com/anthonyivol/sveltekit-routes-issue

I think it's probably because the stackblitz environment is emulating something, can you try on a local environment ?
https://github.com/sveltejs/kit/assets/19983700/9c567cfa-80ea-42f1-af46-3bcf0e870224

Yeah, running it locally on MacOS reproduces the issue. I wonder if it's the same on other platforms or if it's MacOS specific.

Yeah, running it locally on MacOS reproduces the issue. I wonder if it's the same on other platforms or if it's MacOS specific.

Unfortunately I have no way to test it on other plateforms, but I can tell that the same issue appears with node 20

So the issue is caused by the browser issuing a favicon request when visiting the endpoint in the browser. That favicon request then hits the dynamic parameter route since it matches /favicon.ico. You can test this by logging the request url in any server-side function. I guess this is intended behaviour...? (I have no clue what to think)
As an aside, thank you for the reproduction and issue. This was certainly an interesting one.

Ahhhhh, I already had this /favicon.ico issue, with one in the static folder the error disappear, I think it's a defendable behaviour, like if you want to generate static assets (resized images,...) on the fly when requesting a static route, I don't know...
Thanks for your time anyway !


Add PagePermissions extension

We have talked before about adding the UserProtect extension to Canasta:
https://www.mediawiki.org/wiki/Extension:UserProtect
It's useful, but I think its user interface is unnecessarily complicated, and its DB structure seems needlessly complex as well (and to a lesser extent, its name is confusing). Thankfully, @sanjay-thiyagarajan created the PagePermissions extension, whose code is copied in part from UserProtect, but which has a simpler UI:
https://www.mediawiki.org/wiki/Extension:PagePermissions
We're still waiting for the translation process to start on this extension, but I think this is a very workable extension already, and I think it would be great to add it Canasta.

With a disclaimer that I designed UserProtect, I don't think this is less confusing. It introduces a completely new concept of "roles", which adds more complication to a wiki. Why not just use the User Groups? From what I can tell, roles and groups are essentially the same. Instead of creating the concept of a role, you could assign a user to an existing user group for only one page. That doesn't make much sense for bureaucrat-type permissions since they aren't tied to a page, but I still like it better.
There's also a major bug here: commas can be part of MediaWiki usernames by default: https://www.mediawiki.org/wiki/Manual:$wgInvalidUsernameCharacters. This may be more common than you think. Wikis can use "Lastname, Firstname" for their username schemes, especially for enterprise. UserProtect already offers autocomplete with tokens for user names so there's no need for any delimiter. Why drop that feature? It introduces this delimiter problem and is also less user-friendly.
I also don't see any problem with UserProtect in the first place, but I guess that's a matter of taste.

That's true, "tokenized autocompletion" would be a better solution - easier to use, and would avoid problems with specific characters.
I don't know how this would work with actual user groups. The defaullt roles in PagePermissions are "reader", "editor", "manager" and "owner" - what user groups do any of those correspond to? Besides the lack of direct correspondence, I think it would just cause needless confusion, since the two things are not the same: "roles" are per page, while user groups of course are across an entire wiki.
We can talk more about the UI differences, but the first step is getting the autocompletion stuff set up - I'll let you know if/when that's done.

Okay, PagePermissions now uses a tokens-style input for entering usernames, using similar JS code to that of UserProtect. Which fixes the problem with comma delimiters, as well as just being easier for users.
I think PagePermissions is now ready to be added to Canasta - so this would be a good time to talk about why I think its UI is preferable to that of UserProtect. To demonstrate, let me give one example scenario: there is a user who is a sysop/admin, but for a specific page, you only want them to be able to read and write that page, with no other rights. With UserProtect, here is what you would have to do:

Add their username to "Remove rights > Move"
Add their username to "Remove rights > Delete"
Add their username to "Remove rights > Roll back edits"
Add their username to "Remove rights > User protect"

With PagePermissions, on the other hand, there's just one step:

Add their username to "Editor"

In general, I think a role-based approach is a lot easier to use than a rights-based approach - admins don't have to know about users' current rights, they don't really have to think about each individual right, and there's less typing involved.
Conversely, of course, a more explicit system like UserProtect allows for much more flexibility in setting permissions, but I think that extra flexibility is generally not needed, because most combinations would never be used.

OK. I can see a use case where role-based input is easier. I still think you should use user groups for it. To answer your question, you would create new user groups that give each of them the individual rights they should have. Basically, in the same way you create new roles with those rights, you can create new user groups with those rights. Yes, usually user groups are across the wiki, but the standard Protect action will remove the rights of certain groups on specific pages. I know it's not the same thing, but there is a precedent for user groups to be applied differently on individual pages.
To be clear, I don't have any issue with this extension being added to Canasta.

What is the benefit of structuring these roles as user groups?

It's a matter of taste, I guess. To me introducing a new concept of role adds complexity, technically and conceptually. The user groups already exist as a concept so users already understand them and the rights can be administered with core functionality. For example, you can set the group rights with a core global and see group rights via special page.

Per #205, this extension needs to be seconded by a member of the community before it can be considered for inclusion. There are currently no other seconders.


replace container-interop package dependencies

Package container-interop/container-interop is abandoned, you should avoid using it. Use psr/container instead.

superseded by #414


Add support for expr satisfies Type expressions

Fixes #765
To help everyone out, please make sure your PR does the following:

[ ] Update the first line to point to the ticket that this PR fixes
[ ] Add a message that clearly describes the fix
[ ] If applicable, add a test that would fail without this fix
[ ] Make sure the unit and integration tests pass locally with pnpm run tests and cd integration && pnpm run tests
[ ] Includes a changeset if your fix affects the user with pnpm changeset

I'm investigating the error.

Awesome - thanks for pushing this through! Mind adding a changeset?

I need to do an update vitest snapshot because for some reason the project followed my local vscode setup (indentation spacing, semicolons at the end of each line of code, etc...).
@AlecAivazis  or @jycouet, how do you think we should handle this?
I thought that my vscode would follow the project's setup and not something "global" in my environment. Other than that everything looks normal.

Awesome - thanks for pushing this through! Mind adding a changeset?

Hey @AlecAivazis
I will create. First I would like help, please, with this question I commented on vitest.

Huh that's strange. We should definitely try to figure out why the snapshot isn't respecting the project setup. Do you have a .vscode directory locally?

h that's strange. We should definitely try to figure out why the snapshot isn't respecting the project setup. Do you have a .vscode directory locally?

Not in this fork of Houdini 🫤

I believe it could be the following:
Maybe in your project you have vscode user settings, which don't exist in the project's local setup. So in my environment prevailed the configurations that I also have related to the user. But this is just a suspicion.

When you have time, if you can, could you run the tests again and a new snapshot to see if it changes again?

When you have time, if you can, could you run the tests again and a new snapshot to see if it changes again, using this fork?

FYI, I'm looking at this format thing right now @524c

I think that it's related to: https://github.com/benjamn/recast/pull/1247
Quote of the important part 👇

However, many/most TypeScript programmers would probably expect to see semicolons here instead of commas/nothing. We could make this configurable, but I'm not sure it's even controversial, so I'll wait for someone to ask.

This is part of "recast": "^0.23.1" (The version you bumped to), it's a "next" version, not the official one.
In "recast": "^0.22.0" "latest", this is not there yet, so snapshots don't change.
Maybe you can downgrade to latest?
Changing the format of generated code might be a thing to do when the lib will be officially released with it?
Let me know what do you think

Perfect, thanks for finding this.
I will downgrade and test everything again.

I forget things very quickly,but I remembered that I tried to use "recast": "^0.22.0", but it turns out that the current 0.22.0 depends on "ast-types": "0.15.2", which in turn does not support the new typescript operator.
I believe it will be better to wait until they release the "recast": "^0.23.1" as final.

Imo as long as we understand the change in format and that it's not because of some setup in your config, I think using the next version that supports it seems like a reasonable thing to do

FYI, @jycouet and @AlecAivazis,
With "recast": "^0.22.0" i get erros like this (because the "ast-types": "0.15.2"):
houdini:typedefs:   Type 'TaggedTemplateExpression' is not assignable to type 'ExpressionKind | DeclarationKind'.
houdini:typedefs:     Type 'import("/mnt/data/projects/houdini/node_modules/.pnpm/ast-types@0.16.1/node_modules/ast-types/lib/gen/namedTypes").namedTypes.TaggedTemplateExpression' is not assignable to type 'import("/mnt/data/projects/houdini/node_modules/.pnpm/ast-types@0.15.2/node_modules/ast-types/gen/namedTypes").namedTypes.TaggedTemplateExpression'.
houdini:typedefs: /mnt/data/projects/houdini/packages/houdini/src/codegen/utils/moduleExport.ts (24,50): Argument of type 'ExpressionKind' is not assignable to parameter of type 'ExpressionKind | null | undefined'.

Imo as long as we understand the change in format and that it's not because of some setup in your config, I think using the next version that supports it seems like a reasonable thing to do

At least it's nothing with vscode 🙏

exactly. and looking closer at the version, I dont think this is a pre-release version or something like that.  It seems like you just installed the latest version published on npm 👍

exactly. and looking closer at the version, I dont think this is a pre-release version or something like that. It seems like you just installed the latest version published on npm 👍

Yes, I installed via npm, although it is not listed. But as I saw on the github of the project that there was a more recent one that deals with the problem (0.23.1), i decided to try.

Yes, I installed via npm, although it is not listed. But as I saw on the github of the project that there was a more recent one that deals with the problem (0.23.1), i decided to try.

Oh, it is a next version. hmm okay. I'm still not totally against it but i want to investigate it a little more

Okay, thinking about this some more I think it's probably the right move to merge this since people will be using satisfies a lot in 1.0. If we run into issues we can resolve it then

Yes, with the release of 1.0 things got a little hectic and a lot of people updating their stuff.


improved test coverage and fixed some bugs

Added tests to address https://github.com/amphp/socket/issues/39
I also fixed some bugs along the way.

Thanks!


[Build] TI applications fail to build (intelhex)

Build issue(s)
The pump-contoller-app and the lighting-app fail to build.

 2045  git clone https://github.com/project-chip/connectedhomeip.git
 2046  cd connectedhomeip/
 2047  git submodule update --init
 2048  source ./scripts/bootstrap.sh
 2049  cd examples/pump-controller-app/cc13x2x7_26x2x7/
 2050  gn gen out/debug --args="ti_sysconfig_root=\"$HOME/ti/sysconfig_1.15.0\""
 2051  ninja -C out/debug

ninja: Entering directory `out/debug'
[1/9] ACTION //:pump_controller_app.bin(//third_party/connectedhomeip/build/toolchain/arm_gcc:arm_gcc)
FAILED: chip-LP_CC2652R7-pump-controller-example.bin
python ../../third_party/connectedhomeip/third_party/pigweed/repo/pw_build/py/pw_build/python_runner.py --gn-root ../../ --current-path ../.. --default-toolchain=//third_party/con
nnectedhomeip/build/toolchain/arm_gcc:arm_gcc --capture-output --python-virtualenv-config python/gen/third_party/connectedhomeip/third_party/pigweed/repo/pw_env_setup/pigweed_buil
adata_path_list.txt -- ../../third_party/connectedhomeip/third_party/ti_simplelink_sdk/repo_cc13xx_cc26xx/tools/common/oad/oad_image_tool.py --verbose ccs . 7 -hex1 chip-LP_CC2652
../third_party/connectedhomeip/third_party/ti_simplelink_sdk/repo_cc13xx_cc26xx/tools/common/oad/private.pem
Traceback (most recent call last):
  File "../../third_party/connectedhomeip/third_party/ti_simplelink_sdk/repo_cc13xx_cc26xx/tools/common/oad/oad_image_tool.py", line 22, in <module>
    import intelhex
ModuleNotFoundError: No module named 'intelhex'
ninja: build stopped: subcommand failed.

jmarkel@ILA1LT7WDN593:~/connectedhomeip/examples/lighting-app/cc13x2x7_26x2x7$ ninja -C out/debug
ninja: Entering directory `out/debug'
[1086/1097] ld ./chip-LP_CC2652R7-lighting-example.out
FAILED: chip-LP_CC2652R7-lighting-example.out chip-LP_CC2652R7-lighting-example.out.map
arm-none-eabi-g++ -L../../third_party/connectedhomeip/third_party/ti_simplelink_sdk/repo_cc13xx_cc26xx/source gen/sysconfig/ti_utils_build_linker.cmd.genlibs -T../../third_party/connectedhomeip/src/platform/cc13xx_26xx/cc13x2_26x2/cc13x2x7_cc26x2x7_freertos_ot
a.lds -march=armv7e-m -mcpu=cortex-m4 -mabi=aapcs -mfpu=fpv5-sp-d16 -mfloat-abi=hard -mthumb -Os --specs=nosys.specs --specs=nano.specs -Werror -Wl,--fatal-warnings -fdiagnostics-color -Wl,--gc-sections -nostartfiles -fno-exceptions -fno-unwind-tables -Wl,-Map
,./chip-LP_CC2652R7-lighting-example.out.map -Wl,--cref @./chip-LP_CC2652R7-lighting-example.out.rsp -o ./chip-LP_CC2652R7-lighting-example.out
/home/jmarkel/connectedhomeip/.environment/cipd/packages/arm/bin/../lib/gcc/arm-none-eabi/12.2.1/../../../../arm-none-eabi/bin/ld: section .nvs VMA [000aa000,000adfff] overlaps section .rodata VMA [00095ea0,000ad09e]
/home/jmarkel/connectedhomeip/.environment/cipd/packages/arm/bin/../lib/gcc/arm-none-eabi/12.2.1/../../../../arm-none-eabi/bin/ld: section .ARM.exidx VMA [000add6c,000add73] overlaps section .nvs VMA [000aa000,000adfff]
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

Platform
cc13x2_cc26x2
Anything else?
jmarkel@ILA1LT7WDN593:~/connectedhomeip/examples/pump-controller-app/cc13x2x7_26x2x7$ pip install intelhex
Requirement already satisfied: intelhex in /home/jmarkel/connectedhomeip/.environment/pigweed-venv/lib/python3.8/site-packages (2.3.0)

jmarkel@ILA1LT7WDN593:~/connectedhomeip/examples/lock-app/cc13x2x7_26x2x7$ pip list | grep intel
**intelhex                      2.3.0**

Interestingly, checking out a prior commit and building will work, as will switch back to the original/master (if the out/debug directory remains intact):
$ git checkout 66b2d01b0f47c2952495e88a95c2d6913b83e0e8
jmarkel@ILA1LT7WDN593:~/temp/connectedhomeip/examples/pump-controller-app/cc13x2x7_26x2x7$ ninja -C out/debug
ninja: Entering directory `out/debug'
[0/1] Regenerating ninja files
[402/402] stamp obj/default.stamp

jmarkel@ILA1LT7WDN593:~/temp/connectedhomeip/examples/pump-controller-app/cc13x2x7_26x2x7$ **git switch -**
Previous HEAD position was 66b2d01b0f [OIS] Platform improvements (#27291)
Switched to branch 'master'
**Your branch is up to date with 'origin/master'.**
jmarkel@ILA1LT7WDN593:~/temp/connectedhomeip/examples/pump-controller-app/cc13x2x7_26x2x7$ ninja -C out/debug
ninja: Entering directory `out/debug'
[0/1] Regenerating ninja files
[400/400] stamp obj/pump_controller_app.ota.stamp

but removing and regenerating the out/debug folder
jmarkel@ILA1LT7WDN593:~/temp/connectedhomeip/examples/pump-controller-app/cc13x2x7_26x2x7$ rm -rf out/
jmarkel@ILA1LT7WDN593:~/temp/connectedhomeip/examples/pump-controller-app/cc13x2x7_26x2x7$ gn gen out/debug --args="ti_sysconfig_root="$HOME/ti/sysconfig_1.15.0""
Done. Made 272 targets from 226 files in 95ms
jmarkel@ILA1LT7WDN593:~/temp/connectedhomeip/examples/pump-controller-app/cc13x2x7_26x2x7$ ninja -C out/debug
ninja: Entering directory `out/debug'
[1076/1084] ACTION //:pump_controller_app.bin(//third_party/connectedhomeip/build/toolchain/arm_gcc:arm_gcc)
FAILED: chip-LP_CC2652R7-pump-controller-example.bin
python ../../third_party/connectedhomeip/third_party/pigweed/repo/pw_build/py/pw_build/python_runner.py --gn-root ../../ --current-path ../.. --default-toolchain=//
onnectedhomeip/build/toolchain/arm_gcc:arm_gcc --current-toolchain=//third_party/connectedhomeip/build/toolchain/arm_gcc:arm_gcc --capture-output --python-virtualen
on/gen/third_party/connectedhomeip/third_party/pigweed/repo/pw_env_setup/pigweed_build_venv/venv_metadata.json --python-dep-list-files gen/pump_controller_app.bin_m
list.txt -- ../../third_party/connectedhomeip/third_party/ti_simplelink_sdk/repo_cc13xx_cc26xx/tools/common/oad/oad_image_tool.py --verbose ccs . 7 -hex1 chip-LP_CC
ontroller-example.hex -o chip-LP_CC2652R7-pump-controller-example -k ../../third_party/connectedhomeip/third_party/ti_simplelink_sdk/repo_cc13xx_cc26xx/tools/common
pem
Traceback (most recent call last):
File "../../third_party/connectedhomeip/third_party/ti_simplelink_sdk/repo_cc13xx_cc26xx/tools/common/oad/oad_image_tool.py", line 22, in
import intelhex
ModuleNotFoundError: No module named 'intelhex'
ninja: build stopped: subcommand failed.

I worked through this with @ReneJosefsen yesterday. He suggested the following workaround, which was successful:
As a workaround, it seems like you can add:
intelhex
to connectedhomeip/scripts/setup/requirements.ti.txt and then add
pw_build_PIP_REQUIREMENTS += [ "${chip_root}/scripts/setup/requirements.ti.txt" ]
to connectedhomeip/examples/lock-app/cc13x2x7_26x2x7/.gn, just below import("//args.gni")
Also, please query TI for when the CC26x2x7 builds will be enabled again in the workflows.

We should find a way to get this added to the TI platform in a way that is get applied for all applicable examples. The above is mainly to get unblocked. Given this is related to OTA it could also be worth to only require these modules if OTA is enabled.

Given the mentioned PR have merged, I would assume this issue is ok to close.

it looks like the issue was resolved
additionally, we are now supporting cc13x4_26x4 instead of cc13x2_26x2, I assume we can close this


Enable project level content trust, controlled by environment variable

Coverage increased (+0.2%) to 55.668% when pulling ebbdbe1b3eb05f3f17414a1208fab4075a54d245 on reasonerjt:create-reverse-proxy into 7b0daca06a058ef113929a1639328f9cb93dc800 on vmware:master.

Covers #2258, #2259

Coverage increased (+0.2%) to 55.66% when pulling fd8fd2fbe13bd9ad7b6b1c444eddd19471332ab6 on reasonerjt:create-reverse-proxy into 7b0daca06a058ef113929a1639328f9cb93dc800 on vmware:master.

Coverage increased (+0.2%) to 55.66% when pulling fd8fd2fbe13bd9ad7b6b1c444eddd19471332ab6 on reasonerjt:create-reverse-proxy into 7b0daca06a058ef113929a1639328f9cb93dc800 on vmware:master.


https://docs.rs/rsa/latest/rsa/struct.RsaPrivateKey.html#method.precompute is public

While looking at perf, I noticed this precompute method: https://docs.rs/rsa/latest/rsa/struct.RsaPrivateKey.html#method.precompute
In https://github.com/RustCrypto/RSA/issues/23#issuecomment-525251114 it mentions that this should be private and that it is implicitly called during construction.
That issue was closed, but it seems like this still needs to be resolved

Yeah, it should be removed from the public API. We can at least deprecate it.

I believe that the method should remain public so that users of the PrivateKeyParts trait can know when the different pre-computed values have been prepared (see this Zulip conversation as well). Without it, there's no other guarantees that a instance of RsaPrivateKey has these values available internally since its primarily just an implementation detail. We specifically need it to support "exporting" into a JWK format, which requires all of the additional values.


Add typechecking to the CI

Our Python SDK makes use of type annotations throughout, but currently we do not check that these annotations are correct.  Using mypy, we can check these type annotations statically.  This is a good candidate for our CI checks, along with our other linters.
We have some minor typechecking errors in the codebase, especially relating to covariance, which should be fixed along with this.

It looks like we only typecheck our examples: https://github.com/bloomberg/blazingmq-sdk-python/blob/d3e3f4302f9bb20429ff410ec1925293c06aa873/Makefile#L89


Update references to rhel-openssl engine with explanation

When we ask our users to add rhel-openssl-1.0.x to binaryTargets we should explain what that means.

Does this refer to a specific part of the docs, @jharrell ?

@nikolasburk I don't remember but I suspect this is in regards to the Lambda docs

Thanks, makes sense! I found this section in the docs:

What additional information do you think would be useful here?


minSDK 16 in build.gradle but manifest is 9

I'm getting a conflict. My build.gradle has minSDK 15 but your library is 16, tho' in your AndroidManifest you have it set to 9. Does it really need a minSDK 16 to work or ... ?!

build.gradle values always override those in AndroidManifest.xml, so yes, it's minSDK 16.


Communication

Hi Bill
You emailed me but if I try to reply - your spam filter bounces my emails - here's the one I just wrote
Couple of things – I’m trying out your new version
https://github.com/billw2/rpi-clone
In the docs – first clone to a new SD card..
pi@rpi0: $ sudo ./rpi-clone sdb
That can’t be right – only works with the ./ missing….
Secondly when running..
“Writing superblocks and filesystem accounting information: “
That colon at the end maybe should be … to indicate it is doing something – kind of looks like it has stalled…
When I tried the original version on the Orange Pi Plus 2e it did not work – or rather it did – but then the resulting SD didn’t do anything…. Hoping this version will do better… time will tell (it takes a while)..
Pete.

My ISP gives me trouble and I don't see anything in the spam box, so I don't trust that means
anything.  Try mllerk60--at--gmail.com
Yes, the ./rpi-clone is wrong and was pasted from my test runs.  I'll fix it.


Art needed for 1.0.0

@Lance5057 This is a list of all the models and textures that we need for 1.0.0. If you'd prefer we do this some other way, we can do that. I figured this is better than just $tell-ing you all the things.

[x] Zinc research table: Single block table made of zinc for the top and sticks for the legs.
[x] Microscope: Placed on top of the research table on the right hand side, should aim over the petri dish.
[ ] Petri dish: Placed on the top of the research table in the center. Where you put items to look at in the microscope.
[ ] Microscope GUI
[ ] Soil Sampling Kit texture
[ ] Biome Log texture
[ ] Kit Bag texture
[ ] Copper pipe models (see the brass pipe models- we have one for a connection, one for the middle, and one for a pipe with no connections. Using the model JSON system they are added together to form a single pipe model. This is basically the standard way to do pipes and stuff like that) and according textures. Perhaps a different model or texture or something for the different modes: extracting (pulls from things into pipes), inserting (puts fluid into things from pipes), and transferring (moves across pipes)
[ ] Pipe mold block texture (see textures/models/moldIngot)
[ ] Pipe mold item texture
[ ] Sword mold block texture
[ ] Sword mold item texture
[ ] Pickaxe mold block texture
[ ] Pickaxe mold item texture
[ ] Axe mold block texture
[ ] Axe mold item texture
[ ] Shovel mold block texture
[ ] Shovel mold item texture
[ ] Hoe mold block texture
[ ] Hoe mold item texture
[ ] Buzzsaw model. The rotating blades should slowly speed up while being extended forward until it's fully wound up, then they'll just sit there and spin
[ ] Plonker model
[ ] Wooden Cone model/textures: It's an upside down hopper, basically, and made of wood.
[ ] Nether Brick Dust item
[ ] Raw Hellforge Brick item
[ ] Hellforge Brick item
[ ] Hellforge Crucible texture (just modify the existing Nether Crucible texture to match the Hellforge Brick item texture above; it's located at textures/blocks/hell_crucible_side.png)

Not yet developed:

[ ] Turbine model and texture
[ ] Drive shaft model and texture
[ ] Water wheel model and texture
[ ] Windmill model and texture

@Lance5057 Can you get on this? Mainly the item textures


[goalc] Fix some small issues with float to int

It turns out I did not read the manual close enough, and our behavior with floats/ints was not correct.
I think the only likely way this could have gone wrong is if you have code that does fpr -> gpr, then expects the fpr to sign extend and does a (64-bit) slt.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

15 of 19 (78.95%)  changed or added relevant lines in 6 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.003%) to 64.509%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

goalc/compiler/compilation/Function.cpp
1
3
33.33%

goalc/compiler/compilation/Type.cpp
1
3
33.33%

Totals

Change from base Build<PHONE_NUMBER>:
0.003%

Covered Lines:
39837

Relevant Lines:
61754

💛  - Coveralls


Run commands asynchronously

Performance wise, it is critical to avoid blocking some callbacks (typically, Isolator::usage()) while running the associated command. Mesos is designed to allow those callbacks to run concurrently, asynchronously. This PR leverages libprocess' primitive to avoid typically pitfall of synchronous calls.

LGTM


[LIVY-706] ThriftServer does not actually cancel jobs if we Interrupt querys from beeline

What changes were proposed in this pull request?
If we type Ctrl + c to interrupt a query from beeline, it does not cancel itself, the job still can be seen running from spark historyServer.
How was this patch tested?
Tested in my own environment.

Codecov Report

Merging #254 into master will increase coverage by 0.08%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             master   #254      +/-   ##
==========================================
+ Coverage     67.92%    68%   +0.08%
- Complexity      939    940       +1
==========================================
  Files           102    102
  Lines          5876   5876
  Branches        891    891
==========================================
+ Hits           3991   3996       +5
+ Misses         1314   1309       -5
  Partials        571    571

Impacted Files
Coverage Δ
Complexity Δ

...main/scala/org/apache/livy/server/LivyServer.scala
32.87% <0%> (-0.46%)
11% <0%> (ø)

...ain/java/org/apache/livy/rsc/driver/RSCDriver.java
81.58% <0%> (+0.83%)
45% <0%> (ø)
:arrow_down:

...ain/scala/org/apache/livy/utils/SparkYarnApp.scala
67.32% <0%> (+1.3%)
40% <0%> (ø)
:arrow_down:

...c/main/scala/org/apache/livy/repl/ReplDriver.scala
33.33% <0%> (+2.56%)
7% <0%> (ø)
:arrow_down:

...cala/org/apache/livy/scalaapi/ScalaJobHandle.scala
55.88% <0%> (+2.94%)
7% <0%> (ø)
:arrow_down:

Continue to review full report at Codecov.

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

@yiheng would you please help to review this PR? Thanks.

@mgaido91 would you please help to review, thanks.


syntax broken in .css.scss file

Have not tried other file yet, all default setting for indentLine and it broken .css.scss file syntax highligh
with indentLine

Manually removed indentLine char

More screen capture

fixed by fixing issue #91


[wallet CLI] use --no-shell by default

By default, running ./wallet drops into an interactive session. Many common uses of the wallet and tutorial are single-shot commands that all require --no-shell to avoid this behavior. Let's make --no-shell the default and use an explicit --interactive or -i to drop into a session.

Let's make sure we update the docs once this lands (@Clay-Mysten)


fix: 处理 getMultiData 在找不到数据时的报错信息

👀 PR includes

✨ Feature

[ ] New feature

🎨 Enhance

[ ] Code style optimization
[ ] Refactoring
[ ] Change the UI
[ ] Improve the performance
[ ] Type optimization

🐛 Bugfix

[ ] Solve the issue and close #0

🔧 Chore

[ ] Test case
[ ] Docs / demos update
[ ] CI / workflow
[ ] Release version
[ ] Other ()

📝 Description
在传入的 query 是不存在的时:

🖼 Screenshot

Before
After

❌
✅

🔗 Related issue link

🔍 Self-Check before the merge

[ ] Add or update relevant docs.
[ ] Add or update relevant demos.
[ ] Add or update test case.
[ ] Add or update relevant TypeScript definitions.

:tada: This PR is included in version @antv/s2-v1.54.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[Feature] Add Application Version

Is your feature request related to a problem? Please describe.
Now kubevela uses incremental number to name application version, e.g, v1, v2,v3. But it is irrelevant to application's version (releasing new version of the application, usually with a new release tag and image tag). It's just snapshots or deployment history of the application.
There is no way to know which application version a revision is related to. When it comes to traffic management or rollout, it's hard to tell which release version of the application is running on the component with a revision named like 'v123', and the platform users are not sure which revision to choose.
We need a way to differentiate version and revision. I think different versions of application can exist at the same time, but different revisions of the same version of an application don't. If we use Kubevela to build an application management platform, platform users care more about the application version rather than revision, so there should be a way to list/show and set the application version (might be shown on UI).
Dependent components of an application like mysql, redis should be deployed according to application version or be singleton to the application, it depends on the user's decision. I am not sure if the introduction of Workflow can solve this.
Describe the solution you'd like
There should be an ApplicationVersion crd describing a specific version of an application. Just like ApplicationRevision, it stores the definitions, components and application objects, but they are of the last revision.
apiVersion: core.oam.dev/v1beta1
kind: ApplicationVersion
metadata:
  name: hello-world-v1-0-1
  namespace: default
  labels:
    app.oam.dev/name: hello-world
    app.oam.dev/version: v1.0.1
spec:
  application: xxx
  components: xxx
  componentDefinitions: xxx
  traitDefinitions: xxx

User can declare version of the application at the annotations of Application:
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: hello-world
  namespace: default
  annotations:
     app.oam.dev/version: v1.0.1
spec:
  components:
    - name: express-server
      type: webservice

When version name is declared by user, application_controller is responsible for syncing the latest revision of ApplicationVersion.
The name of ApplicationRevision should include the name of ApplicationVersion:
metadata:
  name: hello-world-v1-0-1-1
kind: ApplicationRevision
  spec:
    ...

ApplicationVersion can be referenced by AppRollout or AppDeployment:
apiVersion: core.oam.dev/v1beta1
kind: AppRollout
metadata:
  name: rolling-example
spec:
  sourceAppVersionName: hello-world-v1.0.1
  targetAppVersionName: hello-world-v1.0.2
  ...

apiVersion: core.oam.dev/v1beta1
kind: AppDeployment
metadata:
  name: first-vela-app-deployment
spec:
  appRevisions:
    - versionName: hello-world-v1.0.1
      placement:
        - distribution:
            replicas: 2
    - versionName: hello-world-v1.0.2
      placement:
        - distribution:
            replicas: 1

@BinaryHB0916

Thanks for bring this up. Let me sync with the team to see how we could address it.

Thanks for raising this issue. This problem is quite common.
Nonetheless, I don't think we should add a new "version" besides the current revision concept. We should make a solution based on existing revision-mechanism.
Instead, we should add Component revision and use them in the rollout and traffic split config. Additionally, we should add a new feature to TraitDefinition that indicates changing the trait shouldn't generate a new Component revision. Then we can put all these operational changes to Traits.

I think for a quick fix, we can allow revision created by outside system. So we should add a mechanism to check if the revision already exist.
The quick solution could be:

calculate the revision hash
list all revision related(label selector app name)
check if there's existing revision with same hash and compare the spec. If they are deep equal, don't generate.

I think the quick fix mentioned by @wonderflow can solve this issue by this time.
Also, adding an indicator to decide if it should generate a new trait version in TraitDefinition is a feature we should implement.

@kinsolee Yes, also commented in #1818

We have publishVersion annotation for this feature now, closing


change 2144 magic number in dsl file to be a magic constant with a test to ensure its always true

## Problem
Here we hardcode the proof size, https://github.com/AztecProtocol/aztec-packages/blob/c22a6876f9618a9172f9b47ff2782dbd3346e1fd/barretenberg/cpp/src/barretenberg/dsl/acir_proofs/acir_composer.cpp#L129 to be 2144.
This is problematic if the proof system changes in such a way that changes the proof.
Solution
Create a constant instead and then create a test that will fail if the proof size is not equal to that constant

Hi, @kevaundray is this issue still open?

can i take on this issue ?

Have solved the issue in #9984


Picker shouldn't open on focus (make this behaviour optional)

Fix for (https://github.com/flatpickr/flatpickr/issues/2703)
When the date picker input field is the first field in a modal dialog it should be focussed automatically (as per web authoring standards) when the modal opens and thus the picker opens also, which is unexpected, annoying, distracting and can obscure some of the content of the modal.
Also, when tabbing through a large form, such as when skipping over optional fields, or navigating to a field to correct an error, if the user tabs through one or several date picker fields, this is annoying and distracting, adding cognitive load.

@chmln is there anything we can do to move this along?

Hey! Any updates about it?

Hey! Any updates about it?


ft: make lint and tests working

/bypass_build_status

Hello vrancurel,
My role is to assist you with the merge of this
pull request. Please type @bert-e help to get information
on this process, or consult the user documentation.
Status report is not available.

Conflict
A conflict has been raised during the creation of
integration branch w/1.1/feature/make-tests-lint-working with contents from feature/make-tests-lint-working
and development/1.1.
I have not created the integration branch.
Here are the steps to resolve this conflict:
 $ git fetch
 $ git checkout -B w/1.1/feature/make-tests-lint-working origin/development/1.1
 $ git merge origin/feature/make-tests-lint-working
 $ # <intense conflict resolution>
 $ git commit
 $ git push -u origin w/1.1/feature/make-tests-lint-working

The following options are set: bypass_build_status

Integration data created
I have created the integration data for the additional destination branches.

this pull request will merge feature/make-tests-lint-working into
development/1.0
w/1.1/feature/make-tests-lint-working will be merged into development/1.1 (pull request #3)
w/2.0/feature/make-tests-lint-working will be merged into development/2.0 (pull request #4)

Follow integration pull requests if you would like to be notified of
build statuses by email.
The following options are set: bypass_build_status

/bypass_author_approval

In the queue
The changeset has received all authorizations and has been added to the
relevant queue(s). The queue(s) will be merged in the target development
branch(es) as soon as builds have passed.
The changeset will be merged in:

:heavy_check_mark: development/1.0

:heavy_check_mark: development/1.1

:heavy_check_mark: development/2.0

There is no action required on your side. You will be notified here once
the changeset has been merged. In the unlikely event that the changeset
fails permanently on the queue, a member of the admin team will
contact you to help resolve the matter.
IMPORTANT
Please do not attempt to modify this pull request.

Any commit you add on the source branch will trigger a new cycle after the
current queue is merged.
Any commit you add on one of the integration branches will be lost.

If you need this pull request to be removed from the queue, please contact a
member of the admin team now.
The following options are set: bypass_build_status, bypass_author_approval

I have successfully merged the changeset of this pull request
into targetted development branches:

:heavy_check_mark: development/1.0

:heavy_check_mark: development/1.1

:heavy_check_mark: development/2.0

Please check the status of the associated issue None.
Goodbye vrancurel.


Error on composer require orchid/platform:dev-master

Expected Behavior
composer require orchid/platform:dev-master => adding all required packages to project.
Actual Behavior
An error is thrown on artisan package:discover

Steps to Reproduce the Problem

laravel new project
cd project
composer require orchid/platform:dev-master

Specifications

PHP Version: 7.1
Database Version: 5.7.20

Hey. I'm sorry that you came across this, the package is in development.
Such a problem should no longer be.


StyleGuide - 07-xx

I will transcript here a discussion about loading providers at bootstrap or app component:
Ward said:

For now ... the "rule" should be _Put app wide services in AppComponent unless there is a compelling reason to do otherwise_

We have two compelling reasons so far:

HTTP_PROVIDERS and configuration of them (e.g., HTTP or backend overrides)
ROUTE_PROVIDERS

One key reason is that you need to configure providers before they are used by AppComponent.

That's the reason for ROUTE_PROVIDERS which will soon patch ROUTE_DIRECTIVES into PLATFORM_DIRECTIVES, obviating the need to add ROUTE_DIRECTIVES everywhere.  Could not do this in AppComponent, it would be too late

Same idea with HTTP_PROVIDERS ... which you may need to patch before AppComponent sees it

So the key compelling reason is _Because we must patch something - providers, directives, pipes - before AppComponent can use it_

Let's #close this ... and move to #1152


This thing is f*cking awesome. Some simple ideas inside here!

This thing got me a whole shift today! It picks up dropped shifts really well, but I struggle to get shifts at noon each day when they do the big "main" shift drop. Even with the interval set to 1 second, it kind of stalls on the "days of the week / Find shift" page a few more seconds than that for me. At my job site, when the jobs post at noon they really are only claimable for about a second and a half. So far the bot has missed all of those. It just happens too quickly for the bot to keep up.
Is there anyway to make this thing run as fast as it possibly can with no wait interval? The only thing I can think to do is make it much faster, or to do it all with requests instead of a full browser window.
Regardless, thank you so much for this. It's a nice tool that is like backing up my schedule on top of what shifts I can get for myself.

You can make it run as fast as the atoz web app allows.  I updated the code and added comments to the lines that can be adjusted to decrease wait times between checks.  It might require testing different wait times on your end before finding what works for the fastest speeds when adding shifts.

Oh dude.  I set the after login wait time to 5s and the rest to 1s. OMG.


Fix sorting of segmentation image frames

I think the issue (#117) was closed without need for further changes to the library. Should we just merge this as it is now? @hackermd


Multiple export functions and support of array

Export function has been refactored (export, export_df, export_untyped)
Added ready to use types in legion.model (int16, boolean, string and etc.)
Added opportunity to handle arrays (using HTTP fields that end with [])
Examples has been refactored

@akharlamov

:-1: Comments inline


Github wide isn't wide anymore

Similar or same as #74. From one day to the next, my Github isn't doing what it did with your style active.
No more Github wide. Github now acts and looks as if the style isn't active anymore
NOTE: I tried both the version in this repo and the fork by cfoellmann

yes, github updated its frontend and that breaks the styling.
As you can see the style is working on pages of the repo other than the code view. Like this issue and pull requests.

I'll be... I visited this issue from the email notification, which of course opened my system browser. However I wasn't logged on at Github in that one and much to my susprise every github page opened in wide view... even the code view
So code view not showing page wide depends on being logged on or not...

I have added
.Box-sc-g0xbh4-0 {
    max-width: 100%;
}
.Layout--sidebarPosition-end {
    margin-right: 25px;
}

maybe this holds!?
Please test this.
And @FaceCrap you are right. for logged out users it is still wide :-(

The few repo's I tried now all have the code view wide again.

It seems to work.
Now I have the problem that I can not get into my userstyles.org account to update the style.
Maybe they react on email. Will see...

Mirror: https://userstyles.world/style/13914/github-wide


[SSU-3]: Create typography components

TASK: SSU-3

For the css-variables, we already have it inside the src/config//theme folder.
As for the global, we have the main index css itself, inside the src/index.css.
You can update there too 😁


Issues in RN upgrade build.

1.Deep link modals are not opening up properly for keeper request. Might be happening for all types of dl

Works sometimes only.

2.Try entering OTP to accept share on IOS, one has to continuously do upper case..the cursor does not move to the next box easily.
3.It is taking 14/15 sec on home screen.
-Tested on 1.2.1(135)

This should be retested in 144.
If there are is more than one defect then each should have its own issue is.

-Verified this issue on Dev version 1.3.0(145)
-All the points are related to the same issue that's why I mentioned it in this issue.


[Controller] Update CHIPController to use the Invoke API instead of r…

…elying on CHIPClusters
Problem
CHIPDeviceController and CHIPDeviceCommissioner stills uses APIs defines into CHIPClusters.cpp. As far as I know this is the last consumer of this code, which forces us to keeps ChipClusters.cpp, ChipClientCallbacks.cpp, some handler code into IMClusterCommandHandler.cpp. So removing it may allow to remove a lot of extra code.
Change overview

Replace IM calls to use the Invoke API

/rebase

Fast tracking, given > 3 days for review.

To minimise the amount of changes I have rewritten this PR to "only" contains conversion from CHIPCallback to the InvokeCommand API.


Fix wrong NativeImage method names

Fixes #719

Note the current names are incorrect since NativeImages do not use ARGB, it's just that mojang's strings specified in exceptions are wrong.

uhh let's stick to rgba, just note this is from least to most significant bits.
It's a common practice to put values from least to most significant bits (especially when the value is array-esque), such as jvm class file versions, where major versions are in the lower bits while minor versions are in higher bits

Also see my uv example in that issue above

uhh let's stick to rgba

This has the same energy as using motive because the registry says motive.
I am putting my foot and and I am saying we should use the proper color format for the method name, or change to get/setPixelColor

We should probably call it big/little endian rgba instead.