UnmixedAudioBuffers is null

Describe the issue
I am working on the PolicyRecordingBot sample, I have set
new AudioSocketSettings                 {                     StreamDirections = StreamDirection.Recvonly,                     SupportedAudioFormat = AudioFormat.Pcm16K,                     ReceiveUnmixedMeetingAudio = true,                 }
and I want to record unmixed audio of a meeting in a file (.wav), I make http call to /JoinCall as in AudioVideoPlaybackBot sample.
On OnAudioMediaReceived event  the e.Buffer.UnmixedAudioBuffers is always null. I tried to save e.Buffer.Data to .wav file and it seems that unmixed audio goes there. I tried to listening it and is a fast forward audio with a lot of cuts, like if in every audio buffer frame its changed participants' audio. I didn't have trouble recording mixed audio.
Expected behavior
I was expected the e.Buffer.UnmixedAudioBuffers to have value like the documentation says.
Graph SDK :

Don't know where this is.
Microsfot.skype.bots.media nuget is <IP_ADDRESS>-alpha
Microsoft.Graph.Communications.* nugets are <IP_ADDRESS>0

Call ID
457f835d-5d53-4aa6-ad2d-a1627f84432a
Logs
2020-06-29T11:13:51.5050373Z Info: GraphAuthClient.cs:100 SendHttpRequestAsync
ScenarioId: 757aee3b-21cb-4df9-8194-ea5663c25e5e
AppId: 0980ff84-61c1-43f4-927a-4a7b31ae5dd2
AppName: Sample.PolicyRecordingBot.FrontEnd
TransactionDirection: Outgoing
TraceType: HttpRequest
request: POST https://graph.microsoft.com/v1.0/communications/calls
headers:
  Scenario-Id: 757aee3b-21cb-4df9-8194-ea5663c25e5e
  Client-Request-Id: 6eecc24c-6bf2-44d0-a66b-23dde5763ac5
  User-Agent: GraphCommunicationsClient-Sample.PolicyRecordingBot.FrontEnd/<IP_ADDRESS>0
  Authorization: (redacted)
  Content-Type: application/json; charset=utf-8
{
<EMAIL_ADDRESS>"#microsoft.graph.call",
  "direction": "outgoing",
  "callbackUri": "https://teambot.abc:10101/api/calling/notification",
  "source": {
<EMAIL_ADDRESS>"#microsoft.graph.participantInfo",
    "identity": {
<EMAIL_ADDRESS>"#microsoft.graph.identitySet",
      "application": {
<EMAIL_ADDRESS>"#microsoft.graph.identity",
        "displayName": "(Identity: qwer)",
        "id": "example-guid"
      },
      "guest": {
<EMAIL_ADDRESS>"#microsoft.graph.identity",
        "displayName": "(Identity: asdf)",
        "id": "example-guid"
      }
    }
  },
  "requestedModalities": [
    "audio"
  ],
  "mediaConfig": {
<EMAIL_ADDRESS>"#microsoft.graph.appHostedMediaConfig",
    "blob": "{\"mpUri\":\"net.tcp://teambot.abc:20101/MediaProcessor\",\"audioRenderContexts\":[\"73cfbf4f-ae42-47af-a741-6b1b8ddf7185\"],\"videoRenderContexts\":[],\"audioSourceContexts\":[null],\"videoSourceContexts\":[],\"dataRenderContexts\":null,\"dataSourceContexts\":null,\"supportedAudioFormat\":\"Pcm16K\",\"videoSinkEncodingFormats\":[],\"mpMediaSessionId\":\"93aeb344-2196-4a16-97a9-e3d2ab6aabd4\",\"regionAffinity\":null,\"skypeMediaBotsVersion\":\"<IP_ADDRESS>5\",\"mediaStackVersion\":\"2<IP_ADDRESS>\",\"mpVersion\":\"<IP_ADDRESS>53\",\"callId\":\"457f835d-5d53-4aa6-ad2d-a1627f84432a\",\"receiveUnmixedMeetingAudio\":true}"
  },
  "chatInfo": {
<EMAIL_ADDRESS>"#microsoft.graph.chatInfo",
    "threadId"<EMAIL_ADDRESS>    "messageId": "0"
  },
  "meetingInfo": {
<EMAIL_ADDRESS>"#microsoft.graph.organizerMeetingInfo",
    "organizer": {
<EMAIL_ADDRESS>"#microsoft.graph.identitySet",
      "user": {
<EMAIL_ADDRESS>"#microsoft.graph.identity",
        "id": "example-guid",
        "tenantId": "example-guid"
      }
    }
  },
  "tenantId": "example-guid",
  "callOptions": {
<EMAIL_ADDRESS>"#microsoft.graph.outgoingCallOptions",
    "allowGuestToBypassLobby": null
  }
}

It's because it gets considered as an anonymous user join. Assuming you've taken parts of the AudioPlaybackBot sample, can you remove this code snippet and try again?
            if (!string.IsNullOrWhiteSpace(joinCallBody.DisplayName))
            {
                // Teams client does not allow changing of ones own display name.
                // If display name is specified, we join as anonymous (guest) user
                // with the specified display name.  This will put bot into lobby
                // unless lobby bypass is disabled.
                joinParams.GuestIdentity = new Identity
                {
                    Id = Guid.NewGuid().ToString(),
                    DisplayName = joinCallBody.DisplayName,
                };
            }

Thank you very much, it worked!
ut when nobody is speaking the e.Buffer.UnmixedAudioBuffers is null instead of an empty array, is this intended?

Yes, this is by design. When no one is speaking e.Buffer.UnmixedAudioBuffers will be null. It will appear as a silent "mixed buffer" type of a packet. So IsSilence property on the AudioMediaBuffer will be true, the Data property will point to valid (silence) data, and the Length will be the length of the silence buffer. We recommend you write this buffer to all the individual .wav files you have for each speaker so that it accounts for the silence in between the speech.

Thank you very much again. That explains a lot.


Implemented Responsive Contact Us Component

I have implemented the Contact Us component with a responsive design that matches the Figma file's UI, using the same sizes specified in the Figma design.
Fixes: Closes issue #26
Screenshots:

I am open to feedback and suggestions for further improvements. Thank you for considering my pull request.
Thank you!
Janani

Hi @MadhushaPrasad, My pull request is ready for merging. It has the solution for issue #26. Could you please review it when you have a moment?
Thank you!

Hi @Janani-Balasooriya, If you can also add validations, that's a great job.

Thank you for your feedback, @supuna97!! I will add validations too.

I've added validation to the Contact Us component. Please review the changes when you have a moment.
Screenshot:

Thank you!


Resource query string is inaccessible for modification in symbolId

Do you want to request a feature, report a bug or ask a question?
bug
What is the current behavior?
symbolRegExp does not include query string / resourceQuery to match. Thus, the query string is always appended to the symbol id and there's no way to remove from the output symbol id (that I can tell).
entry.js
import './my-image.svg?sprite';

webpack config svg-sprite-loader rule
let rule = {
  test: /\.svg$/,
  resourceQuery: /sprite/,
  loader: 'svg-sprite-loader',
  options: {
    extract: true,
    symbolRegExp: /(.+)--sprite$/,
    symbolId: '[1]'
  }
}

sprite.svg output
<svg>
<symbol ... id="[1]--sprite" />
...

What is the expected behavior?
sprite.svg output
<svg>
<symbol ... id="my-image" />
...

Please tell us about your environment:

Node.js version: 8.11.1
webpack version: 4.8.3
svg-sprite-loader version: 3.7.3
OS type & version: macOS High Sierra 10.13.4

Unfortunately loader-utils#interpolate doesn't support query string interpolation, so I add ability to use symbolId as function which accepts 2 arguments - image path and image query, so you can do something like this:
const path = require('path');

let rule = {
  test: /\.svg$/,
  resourceQuery: /sprite/,
  loader: 'svg-sprite-loader',
  options: {
    extract: true,
    symbolId: path => path.basename(path, '.svg')
  }
}


Patch hadoop fix: update hadoop version

Hi @qinchen123 @ydye @hwuu , I cherry-pick the hadoop fix to v0.6.y.

Coverage remained the same at 50.957% when pulling b8a3366edae6676ff9c3be179689635ebe4e3109 on yuan/apply_hadoop_fix into 2110b4bdca105981166248465d66c70a9f304a8c on pai-0.6.y.

Coverage remained the same at 50.957% when pulling b8a3366edae6676ff9c3be179689635ebe4e3109 on yuan/apply_hadoop_fix into 2110b4bdca105981166248465d66c70a9f304a8c on pai-0.6.y.


Proguard is weak

Hi,
I see in consumer-proguard-rules.pro these lines.:
-keep public class * {
public protected *;
}
if we include this library in a multi module project, Proguard keep ALL classes, even those are not in this library. (Indeed Android Studio Plugin append all Proguard files)

What is the right way to keep the public classes of this lib? should i instead use
-keep public class de.mateware.snacky.* {
    public protected *;
}

What is the right way to keep the public classes of this lib? should i instead use
-keep public class de.mateware.snacky.* {
    public protected *;
}

This seems much better, because it'll only affect the library code and not the entire project in which it is used.
With the current configuration I can't correctly obfuscate a project in which I'm using Snacky. This fix would be very much appreciated.

Is the Proguard issue fixed in current version?

changed the consumer poguard file, hope everything is fine now ... looking for feedback


tests(fix): use tx sim for populating blocks (BEFP for swamp tests)

This builds on https://github.com/celestiaorg/celestia-node/pull/2553 swapping out FillBlocks by using the txsim

What is the status on this?

Closed in favour of malicious package provided by the app team


If you are using Wikidata, it requires User-Agent

You can't query Wikidata without an User-Agent, so I propose to leave a note in the README to say that you should do things like:
 SPARQL::Client.new(endpoint, :method => :get, :headers => { 'User-Agent': 'MyBotName'}) to use Wikidata.

Actually, the library should provide a default for User-Agent. I'll add something suggesting that applications override this.


Fix misspelled gradlew commands in the documents

Describe the bug
There are some misspelled gradlew commands in the documents. It would be better to fix them so that users can copy-and-paste the command as it is.
$ git grep gardlew
docs/kit/operation-view/page03_local_setup_controlplane.md:./gardlew :edc-controlplane:edc-controlplane-postgresql-hashicorp-vault:dockerize
docs/kit/operation-view/page04_local_setup_dataplane.md:./gardlew :edc-dataplane:edc-dataplane-hashicorp-vault:dockerize
edc-controlplane/edc-controlplane-postgresql-hashicorp-vault/README.md:./gardlew :edc-controlplane:edc-controlplane-postgresql-hashicorp-vault:dockerize
edc-controlplane/edc-controlplane-postgresql/README.md:./gardlew :edc-controlplane:edc-controlplane-postgresql:dockerize
edc-dataplane/edc-dataplane-azure-vault/README.md:./gardlew :edc-dataplane:edc-dataplane-azure-vault:dockerize
edc-dataplane/edc-dataplane-base/README.md:./gardlew :edc-dataplane:edc-dataplane-base:build
edc-dataplane/edc-dataplane-hashicorp-vault/README.md:./gardlew :edc-dataplane:edc-dataplane-hashicorp-vault:dockerize

Hi Tractus-X team,
Recently I'm interested in Tractus-X and trying to run it locally. During that trial, I found some minor issues mainly in its documentation. I'd be glad if I could contribute PRs for them.

Hey, we are happy about every contribution 😉 Please allow me to make a quick reference to our https://github.com/eclipse-tractusx/tractusx-edc/blob/main/pr_etiquette.md regarding providing PRs.
Regarding this issue: thanks a lot for your discoveries! If you want, you can create a PR for it. This would be a "good first issue".

Thanks for the reply! I'll confirm the PR etiquette and submit a PR soon.


Add dashdoad of lifekeeper 20240112

Summary
A concise description of the changes being introduced. Please review the pre-merge checklist section to validate this pull request is ready for review and merge. If it is not ready, please mark the pull request as a draft.
The owners of this repo are not experts in the subject matter of the quickstarts. We review for the quickstart to be functional and for security risks. If you are seeking feedback on the content of the quickstart, please seek out a subject matter expert. If you are not an internal NR contributor, we can do our best to connect you with a content reviewer.

Pre merge checklist

[YES] Did you check you NRQL syntax? - Does it work?
[] Did you include a Data source and Documentation reference?
[YES] Are all documentation links publicly accessible?
[YES] Did you check your descriptive content for voice and tone?
[YES] Did you check your descriptive content for spelling and grammar errors?
[YES] Did you review your content with a subject matter expert? (e.g. a Browser agent quickstart is reviewed with a member of the Browser Agent team)

Dashboards

[YES] Does the PR contain a screenshot for each of your dashboards?
[YES] Do your screenshots show data?
[YES] Has the sanitization script been run on each dashboard?

Alerts

[not used] Did you check that your alerts actually work?

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@unosios Hello! It seems that there is no quickstart associated with this dashboard.
You'll need to create a quickstart with the same name as this dashboard.
Here is the docs for how to create a quickstart

@unosios hi there.  Do you need some guidance to finish this PR? We are ready to review and merge as soon as this is complete


PIM Wizard got Deprecated this Page documentation should be updated correctly.

There is not Wizard option this got already deprecated by Ms and the document is not updated.

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

ID: 35205d31-e185-704a-9adb-58302cfe0f59
Version Independent ID: b621d6e3-30b6-f56d-bb3f-c6c8e54a13ee
Content: Azure AD roles security wizard in PIM - Azure Active Directory
Content Source: articles/active-directory/privileged-identity-management/pim-security-wizard.md
Service: active-directory
Sub-service: pim
GitHub Login: @curtand
Microsoft Alias: curtand

@PaddyMaddy last I heard the wizard was temporarily unavailable. Assigning this to the author to investigate and update if needed.

https://www.paddymaddy.com/wp-content/uploads/2020/04/PIM-1.png
Getting this Error When typed dirt URL

Hi @PaddyMaddy
Thanks for your feedback. The wizard has been replaced and the document updated. It is true as I understand it that the wizard was simply not available for a time.
https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-security-wizard
#please-close


fleet doesn't validate any configuration parameters

fleet should validate at least the etcd server urls and the public ip.

+1. Are there any updates on enabling signed unit tests?

Yes, each configuration parameters should be verified one by one.


Issues installing 1.9.1 on OSX

ref: https://github.com/kivy/kivy/issues/3235

When I try to install via pip (OSX Yosemite), I get the following error: /private/var/folders/q9/b7l6vkkn70b1w16vvxgm5kgw0000gn/T/pip-build-7IPf8J/kivy/kivy/core/image/img_imageio.c:241:10: fatal error: 'CoreGraphics/CGDataProvider.h' file not found
I've installed/updated all the dependencies on the "Install via pip" docs, with Homebrew. I'm running anaconda python 2.7.11.

@sirpercival do you have command line tools installed ?

@akshayaurora yes, the most recent version (v7.2, installed 22 Dec 2015).

@sirpercival can you try installing by specifying a version, I just want to be sure pip is trying to install the correct version.
pip install kivy==1.9.1

Exactly the same problem.

@sirpercival if you still have the issue, could you try setting these three env vars before installation?
https://github.com/kivy/kivy/blob/master/.travis.yml#L97-L99


[glide] Update tally dependency to be compatible with any 3.x.x version

To take advantage of the new sanitization features of tally we need to use the newest release which is 3.1.0. However, we pin the version of tally to 3.0.0 in many of the repos under m3db which means that any package which depends on them cannot upgrade. This PR, therefore, is to change the version of tally from 3.0.0 to ^3.0.0, so we can use any 3.x.x release.
cc @xichen2020 @prateek

Coverage remained the same at 84.21% when pulling cc80bf719cf5e28f93305aeea6767b5ff657f92e on jeromefroe/glide/update-tally-version into 54062210ca0c1b65ada31f7b34c2f4d30ae99021 on master.


[BUG] Triggered a command after mentioning the bot

[x] I am using the latest version of the program.
[x] I have read the Known-issues section and Issues page, and made sure that this problem was not already described elsewhere.

Describe the bug:
Whenever you mention the bot name and type the command without using the prefixes, it will trigger the command
Screenshots:

Not the bug, just the way it works, and it's noted in Important-Notes
Mention prefix and symbolic prefixes are even. Don't want to change it, I'll better simply transfer commands to the slash-based ones someday later.


Support a case where none of the GenTL entities does not have XML file but only the remote device does.

Describe the bug
I am testing the potential use of Harvester with a private (not freely available) CTI and camera. In this particular System > Interface > Device > RemoteDevice scenario I believe that only the RemoteDevice has a node map available.
In ImageAcquirer.__init__() it seems to me that this case is almost, but not quite, supported:
https://github.com/genicam/harvesters/blob/0835ce0cf473e22d4463bdb949901841ae28900a/src/harvesters/core.py#L1754-L1801
The first issue I encounter is that _get_port_connected_node_map() throws LogicalErrorException('The target port does not hold any URL.'), which is not caught by the GenericException block. I don't know if this is intended behaviour or not, but if I modify each except block to except (GenericException, LogicalErrorException) as e: it will then keep trying to extract the node map from the next component in the chain.
However, with the above modification once the node map of the RemoteDevice is loaded it attempts to create RemoteDevice with a reference to its parent self._device. In this scenario this object has not been created because the node map could not be found.
Now, all of this is dependent on my scenario of only having a valid node map for RemoteDevice being a valid scenario; please let me know if this is not the case with GenICam. I see that System, Interface, Device and RemoteDevice all accept None as a potential argument for node_map so this would suggest that no single one of them requires a valid node map.
If this is the case then perhaps the following would be a suitable fix:
        try:
            node_map = _get_port_connected_node_map(
                port=system.port, logger=self._logger,
                xml_dir=self._xml_dir
            )
        except (GenericException, LogicalErrorException) as e:
            self._logger.error(e, exc_info=True)
            node_map = None
        self._system = System(module=system, node_map=node_map)

        #
        try:
            node_map = _get_port_connected_node_map(
                port=interface.port, logger=self._logger,
                xml_dir=self._xml_dir
            )
        except (GenericException, LogicalErrorException) as e:
            self._logger.error(e, exc_info=True)
            node_map = None
        self._interface = Interface(
            module=interface, node_map=node_map, parent=self._system
        )

        #
        try:
            node_map = _get_port_connected_node_map(
                port=device.local_port, logger=self._logger,
                xml_dir=self._xml_dir
            )  # Local device's node map
        except (GenericException, LogicalErrorException) as e:
            self._logger.error(e, exc_info=True)
            node_map = None
        self._device = Device(
            module=device, node_map=node_map, parent=self._interface
        )

        #
        try:
            node_map = _get_port_connected_node_map(
                port=device.remote_port, logger=self._logger,
                file_path=file_path, xml_dir=self._xml_dir
            )  # Remote device's node map
        except (GenericException, LogicalErrorException) as e:
            self._logger.error(e, exc_info=True)
            node_map = None
        self._remote_device = RemoteDevice(
            module=self._device, node_map=node_map, parent=self._device
        )

If at least one node map is required then this could easily be checked for.
This would then lead to two other changes:

ImageAcquirer._setup_data_streams() would require the same change to the except block as above

https://github.com/genicam/harvesters/blob/0835ce0cf473e22d4463bdb949901841ae28900a/src/harvesters/core.py#L1968
Should perhaps be self.remote_device.node_map.disconnect()

To Reproduce
Steps to reproduce the behaviour:

Use a camera and CTI system in which the only node map present is found in the RemoteDevice
Load the CTI and perform an update() with the camera connected
Call create_image_acquirer()
See error

Expected behaviour
I expected the System, Interface and Device objects to be created without node maps, with all information contained by RemoteDevice.
Desktop (please complete the following information):

OS: Windows10
Python: 3.7
Harvester: 1.2.0
GenTL Producer: Own
Camera: Own

Thanks for your work on this project. Your attitude and enthusiasm are delightful.

@JamesMTSloan
Hi James, thank you for trying out Harvester. Do you mean you have a scenario where none of the GenTL entities other than a remote device has its XML file? If so, it's also a totally valid use case but I had never thought about it before. Okay, I will change Harvester so that it can handle your use case. I will let you know once I created a development branch that you can try.

Thanks for your work on this project. Your attitude and enthusiasm are delightful.

Thank you for your kind words. However, to be honest, I do not know if I'm doing something valuable for other people. Yeah, I'd be happy if their works are making other people happy though. But sometimes it's annoying to handle a case where I need to respond to some rude/lazy/sloppy guys...
Anyway, I've got your use case and I'll ping you once it turned available. /Kazunari

Yes that is indeed the scenario I am trying to describe. Great, thanks.
I'm sure it has already been valuable for many people, for example it has already helped me locate some flaws in our CTI implementation. The longer this is around and the more mature it gets, the more likely it is that it will have played some part in positive projects and end-applications.

@JamesMTSloan Hi, James. I have just pushed the change to a development branch called _issue_159. Could you try that out when you can and let me know if it worked for you, please?

OK that looks good to me, I seem to get the same funcionality that I was able to reach after my own tweaks. Thanks for getting round to this so quickly.
My only comment on the code would be that you have added an import for itertools that it looks like you didn't use in the end.

@JamesMTSloan I have just removed that import statement. Thanks! If you are okay to merge the changes in the master please let me know anytime. I'll do that when I can.

I think this can be closed and merged yeah. Cheers.

@JamesMTSloan Thanks. Cheers.


Develop

Rebase all feature

@kensupermen not sure why our previous review isn't visible here.. but anyway thanks for the submission.
Next step
Let's schedule a quick call to confirm that this course is a right fit for you.
We also would like to know a little more about your experience.
Please book a slot from here.

Hi @kensupermen, sorry for unexpected incident with the previous review from us. Thanks for your hard work, you've done a good job so far. This is some feedback from us:
Great things:

You've done all required features
You've added almost all required (except the article view-count)
Clean and clear README file, as well as Walkthrough.gif
You listed many additional features you wanna add.

Suggestion:

It's great to follow a good Ruby code style. We recommend this:
Ruby Style Guide
You should use bootstrap form-group class for your forms (Commenting, Posting)
Style flash alerts in bootstrap style. Instead of
Article was successfully destroyed.
, consider rendering it as
Article was successfully destroyed.
. Here's an example of how to do it.
Links on your page will turn to black when hovering on it due to conflict of boostrap 4 with scaffold style. You can remove scaffolds.scss file to solve this.
Last but not least, you should have validation in your model to prevent user input wrong/empty record. This is sample:

# article.rb
validates :title, :body, presence: true
# comment.rb
validates :message, presence: true

You can continue improve your app and request us to review it again anytime, we love to see your progress has been improve day by day. It would be great if you can implement all additional features as you listed.
And if haven't take an interview with us , please book a slot from here. We would like to confirm that this course is a right fit for you and also to know a little more about your experience.

@kensupermen can you make some changes by on our suggestions? We have many good submissions this time. For you to be accepted, I'd still like to see that you can improve upon our feedback :)

@coderschoolreview  Thanks for you suggest.
I submitted at master branch follow your suggest.


[Event Request] table 5900 "Service Header" - OnRecreateServiceLinesOnBeforeCopyReservEntryFromTemp

Describe the request
Can we please get the following event? (just like a simular event in the salesheader)
[IntegrationEvent(false, false)]
local procedure OnRecreateServiceLinesOnBeforeCopyReservEntryFromTemp(var ServLine: Record "Service Line"; var TempServLine: Record "Service Line" temporary; var ServiceHeader: Record "Service Header"; xServiceHeader: Record "Service Header")
begin
end;

this event can be called once before the  line "CopyReservEntryFromTemp(TempServLine, ServLine."Line No.");" in procedure CreateServiceLines

Additional context
just like a simular event in the salesheader we need an event after the line insert has been executed

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 14158.


🐛 Fix losing model config in create_cloned_field

Summary
Until now, the function utils.create_cloned_field called utils.create_response_field without passing along the model config (among other arguments), which caused an error in the latter function, whenever an arbitrary type was used for the field, even if the appropriate model configuration was done.
The workaround so far was to monkey-patch the pydantic.BaseConfig. With these small changes, the fields will just work as expected.
Reproducible example
Previously, running the following piece of code passed the test-block without a problem, but threw an error at the route decorator:

Click here
from __future__ import annotations
from typing import Union

from fastapi import FastAPI
from pydantic import BaseModel

class Foo:
    def __init__(self, value: int) -> None:
        self.value = value

    def __eq__(self, other: object) -> bool:
        if not isinstance(other, Foo):
            return NotImplemented
        return self.value == other.value

    def __repr__(self) -> str:
        return f"Foo(value={self.value})"

    @classmethod
    def __get_validators__(cls):
        yield cls.validate

    @classmethod
    def validate(cls, v: Union[int, Foo]) -> Foo:
        if isinstance(v, Foo):
            return v
        if isinstance(v, int):
            return Foo(v)
        raise TypeError("Invalid Foo type")

    @classmethod
    def __modify_schema__(cls, field_schema: dict) -> None:
        field_schema.update(
            type="number",
            examples=[-1, 0, 1024],
        )

class MyModel(BaseModel):
    foo: Foo

    class Config:
        arbitrary_types_allowed = True
        json_encoders = {
            Foo: lambda foo: foo.value,
        }

# Test:
_obj = MyModel(foo=Foo(123))
_parsed_obj = MyModel.parse_raw(_obj.json())
assert _obj == _parsed_obj
MyModel.schema()

api = FastAPI()

@api.get("/model/", response_model=MyModel)
def example_route():
    return MyModel(foo=Foo(123))

The error was documented in the issues listed below.

Fixes

#1186
#2382
#3937

Bonus
That second commit is just to finally scratch that itch we all feel at that 99% coverage every time... Or is it just me? 😛

Thank you! It seems this was covered in another PR, so I'm gonna close this one now. But thanks for the effort! :cake:


Using haxm in an INTEL Xeon E5-2640v3...

Hi have a Intel computer with an INTEL Xeon E5-2640v3 and a motherboard Machinist X99 - K9.
I´m using the good and old Windows 7 Professional...
I want, if possible, to accelerate an QEMU package with many MS-Dos chess programs...
https://c.gmx.net/@317206859884790529/mxiarkplSI2G-H1JAT8dbw
Please, could someone help-me?
Problem 0: Can I use haxm to accelerate this MS-DOS package?
Problem 1: I can´t to find the option to enable "Intel Virtualization"  in my Bios...
Problem 2: I don´t know how to insert the call to haxm in the batch file...
I´m don´t need to install QEMU in my computer to run this package...
Only unzip and run using the bvatch file...
Must I to install other programs that no haxm?
Best regards...

I need new version of intelHAXM for Mac OS Monterey version 12.5.1

I need new version of intelHAXM for Mac OS Monterey version 12.5.1


Duplicate documentation env.email and env.password

The variables env.email and env.password are documented twice in the table.
Best regards
Matthias

@MatthiasLohr thanks, removed the duplicated values.


Update apiserver-proxy sidecar image version

How to categorize this PR?

/area networking
/kind enhancement
What this PR does / why we need it:
Similar to https://github.com/gardener/gardener/pull/6828 - this PR updates the apiserver-proxy sidecar image. Around my changes in the apiserver-proxy, I executed the release tests and the default tests in my local setup against apiserver-proxy images that are based on revisions after v0.7.0. During the testing there was no test failure or I was not able to notice abnormal thing.
That's why I rather assume that the reason for the flakes back then was another one.
Release note:

The following image is updated:
- eu.gcr.io/gardener-project/gardener/apiserver-proxy: v0.6.0 -> v0.7.0

Do we need this intermediate update? Isn't the plan to anyways cut v0.8.0 to fix #6818?

Do we need this intermediate update? Isn't the plan to anyways cut v0.8.0 to fix #6818?

Yes, that's the plan. If you want, I can close this PR and we then directly go with v0.6.0 -> v0.8.0 update.

OK, I don't have any preference, I was just curious whether this is prerequisite. I assume we don't want to ship this with v1.58, do we? In this case, we can probably wait for v0.8.0 - otherwise, let's assign the milestone and merge this PR.

The PR is not urgent, so no need to rush for the v1.58 milestone. Then, I will close this PR and let the automation open PR when the v0.8.0 release is cut. 👍
/close

I actually changed my mind. It won’t hurt if we do the v0.7.0 update first - just to prove that there is nothing wrong with it.
/reopen

/reopen

/close
in favour of https://github.com/gardener/gardener/pull/6869


Consistent generics for vector(tile) layers, sources, formats

Fixes #15858
In addition to fixing several type issues, this pull request sets defaults for all type parameters to layers, sources and formats - this way no generics need to be specified any more when the defaults are used.

Marked ready for review. I think this is as good as it gets. I experimented with extracting the FeatureType from the SourceType‘s FestureType type argument, but could not get it to work.

This seems to have fixed the issues I had with VectorLayers and VectorSources.

Added a test to make sure we continue to pass tsconfigs with skipLibCheck: false in the future.
Thanks for any review.


[DRAFT] Update name and interface for textmapgetter/textmapsetter

When working on #44 (see draft), I learned that ngx.req.set_header does not set response headers. There is also a special method for getting response headers (ngx.resp.get_headers()). To avoid confusion, I renamed text_map_getter and text_map_setter to request_header_getter and request_header_setter.
To maintain symmetry between request_header_* and response_header_*, I also updated the propagators to assume that ngx was passed to them (instead of ngx.req). If we do not change this assumption, then the trace context propagator and baggage propagator would accept ngx.req as a carrier, while the traceresponse propagator would accept ngx.
This would be a breaking change.  It's OK if you'd rather not change the existing propagators @yangxikun, just let me know.

Seems we need a new "trace context propagator" to extract traceresponse from upstream response header and inject traceresponse to downstream response. So maybe we can keep the trace context propagator and baggage propagator accept ngx.req as a carrier.
Sorry for the quickly say "sure" on #44. After checking opentelemetry specification, I found there was not spec about traceresponse. And traceresponse still in w3c trace context draft, maybe we can wait for the opentelemetry specification to include traceresponse.
Does your service need this feature now?

Sorry for the quickly say "sure" on #44. After checking opentelemetry specification, I found there was not spec about traceresponse. And traceresponse still in w3c trace context draft, maybe we can wait for the opentelemetry specification to include traceresponse.

No problem! We do need this feature, but we can implement elsewhere if you do not want it in opentelemetry-lua yet!

Seems we need a new "trace context propagator" to extract traceresponse from upstream response header and inject traceresponse to downstream response.

Yes, I have a draft of that here 😄 https://github.com/plantfansam/opentelemetry-lua/pull/2. I think it makes sense to keep carrier as ngx.req for the TextMapPropagator.

Closing this until we actually want it.


docs: Wellcome is using Argo in our Data Labs division

We're using it to power pipelines around grants, publications and funding data.
Checklist:

[ ] Either (a) I've created an enhancement proposal and discussed it with the community, (b) this is a bug fix, or (c) this is a chore.
[ ] The title of the PR is (a) conventional, (b) states what changed, and (c) suffixes the related issues number. E.g. "fix(controller): Updates such and such. Fixes #1234".
[ ] I've signed the CLA.
[ ] I have written unit and/or e2e tests for my change. PRs without these are unlikely to be merged.
[ ] My builds are green. Try syncing with master if they are not.
[x] My organization is added to USERS.md.

Thank you. Please sign CLA.


M1: Implement Query Validator

We need to validate if the query that we received as input complies with the specifications of the standard.
For that, try to follow the session Payload definition for Headers and Query Argument transmission of the this wiki. Number 4, 5, 6, 8 are out of the scope of this ticket.
Input:

CMCD query. In the folder examples you can find 20 queries that you can use to test your function

Output:

If there is an error, save it taking into account the following structure.

"error":
    {
      "type": <missing-header|parameter-value|parameter-encoding|missing-parameter|invalid-header|unknown-parameter|invalid-header-encoding|invalid-json|etc...>,
      "key": <string>
      "value": <any-type>
      "description": <string (description for humans)>
    }

CMCD query. (The same that you received as an input)

Acceptance Criteria.

Create a function to check if the query is correct based on the standard.

@pollingerMaxi , @arrivillagaTomas , @sebastianpiq , @mcamardon
Based on the rules I created the queryValidator. I also created test.js where I tested this function with 11 diferent types of scenarios.

Correct Query
Query with another request at the end
Query with another reques before CMCD
Query with another request before and after the CMCD query
Query not encoded
Query with more than one CMCD request
Query with bool value on true
Querty with a string without ""
Query with key/value pair without =
Query without , separating key/value pairs
Query with toke value between ""

Please let me know if there are any scenarios I missed.


Add Spark RegexTokenizer as FeatureTransformer

I have integrated the RegexTokenizer of Spark as Feature Transformer according to the documentation because I use it in my pipelines and would like to use mleap for pipeline execution.
A merge would be very much appreciated, hope I forgot nothing...

Hey,
Just glanced briefly and it looks great. Will merge this in sometime today.
Thank you for the contribution!


[SA] cfs-google-cloud-storage

Google Cloud Storage has similar features to AWS S3.
There is a node.js client library.
The API for Google Cloud storage is located here.

Hii, I am interesting in this feature too. Does someone start something? Can I help? :)


FPS drops

Hey since today i get MASSIV FPS Drops when i install This plugin,

maybe dalamud thing.

Not enough info at all to even start investigation.


Using vars instead of secrets: Update github actions and documentation for the Sample app

Describe the Issue
The team has decided to use for the GitHub actions that deploy the sample apps the newly introduced environment variables instead of secrets.
The documentation will need to be updated indicating where to introduce the variables and the GitHub action scripts will need to change to use them instead of secrets.
The changes in the code are easy, basically is to replace the secrets prefix by the vars prefix. For example (in line 37 of push_manual.yml) would be to replace

role-to-assume: ${{ secrets.TERRAFORM_DEPLOY_ROLE_ARN }}

by

role-to-assume: ${{ vars.TERRAFORM_DEPLOY_ROLE_ARN }}

To add the new variables, select the (new) Variables tab in Settings > General > Security > Secrets and Variables > Actions

Additional Context
Screenshot of the decision adopted in the Scrum meeting of April 12, 2023

Acceptance Criteria

The Actions in the Sample app repos now use vars instead of secrets (serverless and containers sample app repos)
The Readme and documentation (How To... stored in the Team folder) associated to both have been updated to reflect the use of vars instead of secrets

Documentation updated for Serverless and Containers app
How To's updated for Serverless and Containers app
Workflows modified to use vars instead of secrets
PR initiated
Note: the GitHub repos will need to be manually modified to add the variables instead of secrets. I will do it once all the PR have been approved


[BUG]: Efiling - Delay Condonation Application

For the page "Delay Condonation Application", I am unable to click the button "No". It is by default "yes" and I cant change it if I want.
I should be able to Click "No" and submit a condonation application.

Hi @supriyasankarangill  About this is issue. The yes and no values are dependent on "date of accrual of cause of action" .
The info of which we can see in legal and demand notice. Which is again dependent on cheque details
Attaching a Video reference below for the same.
https://jam.dev/c/2b767ec6-0181-4200-8b86-dcfd9869ceca


Show notifications across Servers

I have two servers setup, one for work, one for family.
Whenever I'm focused on one in the desktop app, notifications for the other go completely unnoticed. I'll click back over to the other server and Whoa! There's a ton of messages waiting over here that I had no idea about.
I want to get notifications for any server I'm logged into, regardless of whether I'm 'focused' on it or not.

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/29034182-show-notifications-across-servers?utm_campaign=plugin&utm_content=tracker%2F19476668&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F19476668&utm_medium=issues&utm_source=github).

I believe that was part of https://github.com/RocketChat/Rocket.Chat.Electron/pull/52, which was closed for some reason. But I agree, it would be nice to have notifications from all servers added.

At the very least, there should be a number badge showing unread notices on any other servers. Is this part of the Rocket.Chat core? Or is this only relevant to Electron? I'd love to contribute on this issue if needed.

This is a problem also for my use case, internal and external work chat.

Same here.

Latest beta seems to support this function, so this ticket is fixed as far as I am concerned.

Yes, seems to be working just fine :+1:

@SloMusti would you mind sharing where you found the latest beta? I'm on 0.0.9 and it's still not working.

@NickBusey https://github.com/RocketChat/Rocket.Chat.Electron/releases

Yup, works for me in the latest. Thanks guys!


How to add additional nodes after the initial deployment

When I initially deploy the cluster I get to choose the number of data nodes that make up the cluster.
How can I add more data nodes for scalability after the initial deployment? Is it possible to do this without downtime?

@mario-paniccia Take a look at the documentation: https://www.elastic.co/guide/en/elastic-stack-deploy/current/azure-arm-template-elasticsearch.html#azure-arm-template-scaling-nodes
As per the documentation, I would only use this when you have dedicated master nodes, and not master-eligible nodes; When using master-eligible nodes, the configuration on each node needs to be changed and the node restarted, which the Azure infrastructure will control.

@russcam I completely missed the ARM template documentation on www.elastic.co! Cheers


important

If the app is killed, the incoming call notification does not start. please check

@baron7272 Can you explain more?
For IOS, you need to setup Pushkit and VoIP,
For Android, Just call it when receiving push notification from background

hi @hiennguyen92. If the app is in background, when a call incoming. How to get the data? Thanks

@dhpl you should combine
CallEvent.ACTION_CALL_INCOMING và activeCalls


teascript: add package

https://github.com/xmake-io/xmake-repo/actions/runs/8672784610/job/23783467582?pr=3768 fails but is supposed to be ignored.


HTML formatted email not showing up at all in Gmail

The email was not coming in the default expected template format as Gmail no longer supports the Style tag.
Testing done
Done

### Submitter checklist
- [x] Make sure you are opening from a **topic/feature/bugfix branch** (right side) and not your main branch!
- [x] Ensure that the pull request title represents the desired changelog entry
- [x] Please describe what you did
- [ ] Link to relevant issues in GitHub or Jira
- [ ] Link to relevant pull requests, esp. upstream and downstream changes
- [ ] Ensure you have provided tests - that demonstrates feature works or fixes the issue

I am not willing to merge a pull request whose Testing Done section reads "None"

using default groovy template

with my current diff

@basil thanks for accepting PR
I'd like to ask how to submit environment variables or job parameters in a Groovy template. If possible, an example would greatly assist me in understanding. Thank you for your help!


Minor update to Numpy sctypeDict

It seems Numpy has deprecated typeDict in newer versions. This minor update should fix warnings and/or issues when runnning with newer versions of Numpy.
EDIT: Sorry it is clunky, also added an entry in the .gitignore file for a virtual env folder when developing locally.

Changes were added from another commit


cmd/cue: mod publish includes unstable output for ~same module

What version of CUE are you using (cue version)?

$ cue version
cue version v0.9.0-alpha.4

go version go1.22.2
      -buildmode exe
       -compiler gc
       -trimpath true
     CGO_ENABLED 0
          GOARCH arm64
            GOOS linux
cue.lang.version v0.9.0

Does this issue reproduce with the latest release?
The latest pre-release, yes.
What did you do?
https://review.gerrithub.io/c/cue-lang/cuelang.org/+/1194141 was the change that upgraded https://cuelang.org to v0.9.0-alpha.4. Within that CL however we were forced into making a couple of changes like:
https://review.gerrithub.io/c/cue-lang/cuelang.org/+/1194141/6/content/docs/tutorial/publishing-modules-to-the-central-registry/en.md
because the output of cue mod publish was no longer stable.
https://review.gerrithub.io/c/cue-lang/cuelang.org/+/1194143/1 and the associated trybot failure demonstrates the issue. After a re-run of the preprocessor skipping the cache we get the following diffs:
diff --git a/hugo/content/en/docs/tutorial/publishing-modules-to-the-central-registry/index.md b/hugo/content/en/docs/tutorial/publishing-modules-to-the-central-registry/index.md
index aa2c3326..a1cd1745 100644
--- a/hugo/content/en/docs/tutorial/publishing-modules-to-the-central-registry/index.md
+++ b/hugo/content/en/docs/tutorial/publishing-modules-to-the-central-registry/index.md
@@ -201,7 +201,7 @@ module.
 Publish the first version of this module:
 ```text { title="TERMINAL" codeToCopy="Y3VlIG1vZCBwdWJsaXNoIHYwLjAuMQ==" }
 $ cue mod publish v0.0.1
-published<EMAIL_ADDRESS>to registry.cue.works/github.com/cueckoo/frostyconfig:v0.0.1@sha256:a9e174a2e17e244[61](https://github.com/cue-lang/cuelang.org-trybot/actions/runs/8912297589/job/24475454801#step:40:62)ae16db9c5d07a749c24fa827fecc575990ef72060fa42ee
+published<EMAIL_ADDRESS>to registry.cue.works/github.com/cueckoo/frostyconfig:v0.0.1@sha256:06b8016ebe451ebb21e6d1ca28361bd066d2ad423149f8d51b7b98c92f397c10
...

This indicates that the output of cue mod publish is not stable.
What did you expect to see?
Stable output from cue mod publish.
What did you see instead?
Per above. Which indicates that cue mod publish is not itself repeatable.
The thing to note in this example is that we are using git as a source. When the preprocessor re-runs a guide, it does so with a fresh git repo. Which means the commit that results from the re-running of the guide will ~never have the same commit ref. So it makes sense that it the output from cue mod publish is a function of the metadata including that commit hash then it would change.
I guess part of the issue here is that it's not clear to me we want/need to be outputting this level of detail by default. It's noise at best.

Ok so here is something that confirms we appear, at least from the output, that the same git commit is stable:
env HOME=$WORK/.home
env CUE_EXPERIMENT=modules

mkdir $HOME
cd example

exec git config --global user.email<EMAIL_ADDRESS>exec git config --global user.name cueckoo

# Start two registries for good measure
exec cue mod registry localhost:5000 &
exec cue mod registry localhost:6000 &
exec sleep 1

exec git init -q
exec cue mod init --source=git glacial-tech.example/frostyconfig@v0

exec cue mod tidy

exec git add -A
exec git commit -q -m 'Initial commit'
exec git status
exec ls -la

env CUE_REGISTRY=localhost:5000/cuemodules
exec cue mod publish v0.0.1
cp stdout $WORK/reg1.golden

env CUE_REGISTRY=localhost:6000/cuemodules
exec cue mod publish v0.0.1
cmp stdout $WORK/reg1.golden

-- example/config.cue --
package frostyconfig

// #Config defines the schema for the FrostyApp configuration.
#Config: {
	// appName defines the name of the application.
	appName!: string
	// port holds the port number the application listens on.
	port!: int
	// debug holds whether to enable debug mode.
	debug?: bool
	// features holds optional feature settings
	features?: {
		// logging enables or disables logging.
		logging?: bool
		// analytics enables or disables analytics.
		analytics?: bool
	}
}

Notice the output (on a local run):
> cmp stdout $WORK/reg1.golden
--- stdout
+++ $WORK/reg1.golden
@@ -1,1 +0,0 @@
-published<EMAIL_ADDRESS>to localhost:6000/cuemodules/glacial-tech.example/frostyconfig:v0.0.1@sha256:09bdcf220178e0722dd6fc5b5e02e803edc73ad5a1b3a96a01203acc5a0691f1
@@ -0,0 +1,1 @@
+published<EMAIL_ADDRESS>to localhost:5000/cuemodules/glacial-tech.example/frostyconfig:v0.0.1@sha256:09bdcf220178e0722dd6fc5b5e02e803edc73ad5a1b3a96a01203acc5a0691f1

FAIL: /tmp/testscript3671823808/repro.txtar/script.txtar:31: stdout and $WORK/reg1.golden differ

The diff appears in the registry, but the sha256 is stable. So modulo checking some further details, let's assume the contents published by cue mod publish are fine.
So this I think shifts this issue to what we output when running cue mod publish:

Do we need/want to publish anything on a successful publish?
Is the sha256 a relevant detail for me when I publish? It feels noisy by default to emit it.
I thought cue mod resolve was introduced precisely to tell us which registry we will "target" with a publish - do we need to emit this too?

My hunch is that we can/should be silent on success, unless we have -v or similar.

In conversation with @rogpeppe we agreed to not output the sha.


[WIP] Update to klog v2.3.0

What type of PR is this?
/kind cleanup
What this PR does / why we need it:
Update to klog v2.3.0
Which issue(s) this PR fixes:

Special notes for your reviewer:
Need to rebase out https://github.com/kubernetes-sigs/k8s-container-image-promoter/pull/264 once it merges.
Does this PR introduce a user-facing change?

NONE

/assign @dims

Out of curiosity, are you just using gazelle to do the updates to the klog dependency?

Closing this in favor of removing klog in https://github.com/kubernetes-sigs/k8s-container-image-promoter/pull/282 and https://github.com/kubernetes-sigs/k8s-container-image-promoter/pull/283.

Out of curiosity, are you just using gazelle to do the updates to the klog dependency?

@listx -- to answer this, yep (via make update)!
bazel run //:gazelle -- update-repos \
  --from_file=go.mod --to_macro=repos.bzl%go_repositories \
  --build_file_generation=on --build_file_proto_mode=disable_global \
  --prune
bazel run //:gazelle -- fix

/close


Is Metadata.id neccesary?

Do we need transaction metadata id? Is there a use case for it that can't be served by using [txid].metadata?

What do you mean by [txid].metadata?

I mean, that you can use the transaction id to refer to the metadata, since they have a 1:1 relationship and the transaction contains the metada. So, [txid] gets you the transaction, and .metadata deferences the metadata inside the transaction:
def get_metadata_by_txid(bigchain, txid):
    tx = bigchain.get_transaction(txid)
    return tx.metadata

I mentioned this in person, but for the record:
What if someone wants to find all transactions with some particular metadata? For example, maybe someone sets the metadata data to "Submitted by Alex P. Goodwin of Beaverton." in every transaction that they submit. Now they want to find all transactions with that particular metadata data.
Admittedly, we don't have that today: the current metadata.id is random per transaction. It's not a hash of the metadata data. Is it possible to index the metadata data? AFAIK we allow arbitrary (nested) JSON in the metadata data so maybe indexing that isn't practical (or is it)?

There's a related question:
If we do get rid of the metadata id, then what's the point of having "metadata data" --- why not just have "metadata"?

Yep, that follows: https://github.com/bigchaindb/bigchaindb/commit/005ad5a93add96da9821c91790b9e13ae40c20c2


feat: Manual scaling for trace and metric gateways

Description

Changes proposed in this pull request:

Add static scaling API for metric and trace gateway to Telemetry CR
Add e2e test for static scaling API

Related Issues and Documents

Closes:
Related issues:
https://github.com/kyma-project/telemetry-manager/issues/430
Traceability

[x] The PR is linked to a GitHub Issue.
[ ] New features have a milestone label set.
[x] New features have defined acceptance criteria in a corresponding GitHub Issue, and all criteria are satisfied with this PR.
[x] The corresponding GitHub Issue has a respective area label.
[ ] The follow-up issues (if any) are linked in the Related Issues section.

Testability
The feature is unit-tested:

[x] Yes.
[ ] No, because unit tests are not needed.
[ ] No, because of ...

The feature is e2e-tested:

[x] Yes.
[ ] No, because e2e-tests are not needed.
[ ] No, because of ...

Tests conducted for the PR:

Codebase

[x] My code follows the Effective Go style guidelines.
[x] The code was planned and designed following the defined architecture and the separation of concerns.
[ ] The code has sufficient comments, particularly for all hard-to-understand areas.
[x] This PR adds value and shows no feature creep.
[ ] I have augmented the test suite that proves my fix is effective or that my feature works.
[ ] Adjusted the documentation if the change is user-facing.

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/retest


role openshift-volume-quota doesn't check if the filesystem exists

BUG REPORT INFO
Environment

The openstack-ansible-contrib version (commit) (git rev-parse --short HEAD):

142627f
openshift-volume-quota role doesn't check if the expected filesystem exists on the target device
Problem Description
When  preparing machines  with the following  playbook
- hosts: nodes
  tags: docker
  roles:
  - role: openshift-volume-quota
    local_volumes_device: /dev/sdd

I expect
Running the playbook multiple times results in an all-green
instead
Once an emptydir volume is provisioned, further runs fails.
Proposed Change
I'd like to check if the emptydir volume is already formatted before creating the fs
Implementation
--- a/roles/openshift-volume-quota/tasks/main.yaml
+++ b/roles/openshift-volume-quota/tasks/main.yaml
@@ -1,5 +1,10 @@
 ---
-- name: Create filesystem for /var/lib/origin/openshift.local.volumes
+- name: Create filesystem for /var/lib/origin/openshift.local.volumes only if it's not present.
+  when:
+  - >-
+    ansible_mounts | json_query("[?device=='" + local_volumes_device + "']") | length == 0
+  - >-
+    ansible_mounts | json_query("[?mount=='" + local_volumes_path + "']") | length == 0
   filesystem:
     fstype: "{{ local_volumes_fstype }}"
     dev: "{{ local_volumes_device }}"

Acceptance criteria
Running twice the role on a group of nodes doesn't fail.
Nodes are provisioned as requested.
Testing
Running twice the role on a group of nodes doesn't fail.

/close


Badges as Stickers

Devs love their laptop stickers, and it would be amazing to offer these badges as vinyl stickers to recipients! At the end of the day, Open Badges are just images, so it will be impossible to prevent counterfeits. However, a happy-path to receiving stickers for those what want them will help to solidify Node.js Badges as an important part of the community culture.
The easiest way to make this happen is to just make all Badges available as stickers in a Node.js store. This can either be through the existing store.nodejs.org storefront, or through a new account from a service like RedBubble. Badge descriptions can include a link to the official store page where the badge stickers (or pins?!) may be purchased.
It would be nice to limit official purchases of stickers to those that can prove they've been awarded the badge. I'd be interested to hear proposals for how we can pull this off, but I don't want to see it to block us from offering Badge specific merchandise.
There are also opportunities to provide Badge related merchandise at conferences and in-person meetups. This should be considered on a by-event basis, but it may be good to offer guidance for how to plan ahead for event-specific Badges.
@bnb, who would have information about the current storefront, who maintains it, and what kinds of product offerings we can make through it? Those details will help dictate what we're allowed to actually offer and/or what platforms we're allowed to use.
Other outstanding questions off the top of my head:

Do we have an exclusive deal with the vendor who runs store.nodejs.org?
How are sales handled? Do we sell at-cost? Where does the money go if we make a profit?
Do we need special outreach / approval process to print and provide badges at Node.js sponsored conferences / events?

I've been ranting quite a lot lately about not having enough sticker, and especially not having Node stickers on my laptop, so I'll definitely agree with this :smile:

@amiller-gh I believe @gtewallace can at least point you to the correct person, if he's not the correct person himself.
Regardless of whatever supplier/method we use I'd like to ensure that they will follow the standard hex format. I know there've been official Node.js stickers in the past that haven't followed the official/standard format, which is a pain point and would limit the usefulness and love these can potentially get. See hexb.in for some more details (and I'm happy to help with this however I can).

@bnb, thats the plan! Don't worry, we won't mess up your transparent mac shell ;)
https://twitter.com/bitandbang/status/968884525819465728
The hex icon is kind of Node's thing. I'd be very concerned if we stray from that in https://github.com/nodejs/badges/issues/7
@gtewallace, excited to hear about any information you have on the current store's vendor, happy to jump on a quick call to chat if thats easier.

The idea of offering dev stickers is awesome and also fascinating for sticker lovers, attracting more of them to contribute and earn badges :wink: :stuck_out_tongue_winking_eye:
But we should ensure authenticated badges issuing so that no user shall buy a badge without completing the task/ earning the badge.

I'd like to ensure that they will follow the standard hex format
@bnb the standard hex format is awesome to be included and worked upon and yes we would love including this standard design if we propose some design principle for issuing badges.
Also, find a great blog post - https://hexstickers.com/blog/whyhexagon/

The nodejs decal stickers still on sale :heart: https://store.nodejs.org/collections/decals

Also, find a great blog post - hexstickers.com/blog/whyhexagon

Their cert expired. Are they still actively producing and shipping stickers?


Needs a .jar release for better portability

Being a Java program, I can't fathom why the pre-built release package would be in PE32 Windows Executable format. The release should be cross-platform...
./run_linux.sh
Exception in thread "main" java.lang.UnsupportedClassVersionError: org/terasology/engine/Terasology : Unsupported major.minor version 52.0
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
    at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482)

...yet it somehow isn't. This is a colossal fuckup in my view.

Upon further inspection, it appears that the problem may be with my java runtime.

Yep that just looks like a Java other than 8. Happens from time to time.
Current zip has executables for Windows, Linux, and Mac OS plus you can launch via .jar directly from command line.
I think the closest to Windows-specific stuff we do is try to fix line endings in some text files during the build so they'll look nicer on Windows (actually have newlines). I'm not sure if that can risk any issues on Linux. If you come across anything we could do better please let us know :-)


Implement geode/tecrocks mode wizard [#181065898]

PT: [#181065898]
Demo: https://tectonic-explorer.concord.org/branch/mode-wizard/index.html

@pjanik One more wrinkle -- project team wants the reload button (the internal one on the top bar) to return to the mode selection screen.


Your New Awesome Talk

level: beginner
language: en
twitter: YourTwitterHandle

Your new awesome talk description

@PatrickHeneise: please create an Event first, then label the issue as a talk.

@PatrickHeneise please create an Event first, then label the issue as a talk.


[WIP] Cut Vertices and BCC

Contains iterators over cut vertices and BCCs of an undirected graph.
Both:

Time: O(n+m)
Space: O(n+m) bits

(Also made some adjustments to the DFS user calls, and added windmill graph creation.)

Coverage increased (+0.3%) to 78.272% when pulling 601f2ec7ebefc6264df1806135007888d6772189 on shsr04:cut-vertex into c6c6489ab2557b8a861b76667bf8f1a7b4f8bab1 on thm-mni-ii:master.


Expose CEL/OpenAPI validation rules as documentation to users

What would you like to be added:
Expose validation rules to reference documentation on the website (and/or so it shows up in kubectl explain
Why this is needed:
Users have asked for this: https://github.com/istio/istio/issues/52225

Is there a reason why we have this limit in the API? Shouldn't the limits be enforced by the implementation of the gateway controller?

The main reasons to have this in the API rather than the implementations are:

Users get feedback earlier, at apply time, rather than having the apply succeed and then their configuration (or even worse, only some of their configuration), fail to work.
Allowing implementations to control this themselves would allow implementations to choose their own numbers here, which would break portability - since a Gateway that was valid in one implementation might not be in another, based on the number of Listeners.

That's why this is done at the API level.
As to why there are limits - the main reasons are the etcd size limit (records stored in etcd can't be over a certain size, which is 1MB by default, and records that exceed this size simply won't be accepted by Kubernetes), and the complexity which would ensue if you could have n Listeners x m Attached Routes x l Route rules x o Matches inside Rules. The complexity goes up very quickly with that sort of multiplicative relationship.

/remove-lifecycle stale


Fix traceback error output from test_realm_scenarios

I think this error output is the result of our having recently changed the queue processors to run the consume methods when queue_json_publish is called in tests.  Not sure yet.
Running zerver.tests.test_messages.TestCrossRealmPMs.test_realm_scenarios
2017-10-27 23:29:50.575 ERR  [] Error queueing internal message by<EMAIL_ADDRESS>You can't send private messages outside of your organization.
Traceback (most recent call last):
  File "/home/tabbott/zulip/zerver/lib/actions.py", line 1760, in check_message
    forwarder_user_profile, sender)
  File "/home/tabbott/zulip/zerver/lib/actions.py", line 1544, in recipient_for_user_profiles
    recipient_profile_ids = validate_recipient_user_profiles(user_profiles, sender)
  File "/home/tabbott/zulip/zerver/lib/actions.py", line 1523, in validate_recipient_user_profiles
    raise ValidationError(_("You can't send private messages outside of your organization."))
django.core.exceptions.ValidationError: ["You can't send private messages outside of your organization."]

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/tabbott/zulip/zerver/lib/actions.py", line 1811, in _internal_prep_message
    content, realm=realm)
  File "/home/tabbott/zulip/zerver/lib/actions.py", line 1763, in check_message
    raise JsonableError(e.messages[0])
zerver.lib.exceptions.JsonableError: You can't send private messages outside of your organization.
2017-10-27 23:29:50.645 ERR  [] Error queueing internal message by<EMAIL_ADDRESS>You can't send private messages outside of your organization.
Traceback (most recent call last):
  File "/home/tabbott/zulip/zerver/lib/actions.py", line 1760, in check_message
    forwarder_user_profile, sender)
  File "/home/tabbott/zulip/zerver/lib/actions.py", line 1544, in recipient_for_user_profiles
    recipient_profile_ids = validate_recipient_user_profiles(user_profiles, sender)
  File "/home/tabbott/zulip/zerver/lib/actions.py", line 1523, in validate_recipient_user_profiles
    raise ValidationError(_("You can't send private messages outside of your organization."))
django.core.exceptions.ValidationError: ["You can't send private messages outside of your organization."]

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/tabbott/zulip/zerver/lib/actions.py", line 1811, in _internal_prep_message
    content, realm=realm)
  File "/home/tabbott/zulip/zerver/lib/actions.py", line 1763, in check_message
    raise JsonableError(e.messages[0])
zerver.lib.exceptions.JsonableError: You can't send private messages outside of your organization.
2017-10-27 23:29:50.713 ERR  [] Error queueing internal message by<EMAIL_ADDRESS>You can't send private messages outside of your organization.
Traceback (most recent call last):
  File "/home/tabbott/zulip/zerver/lib/actions.py", line 1760, in check_message
    forwarder_user_profile, sender)
  File "/home/tabbott/zulip/zerver/lib/actions.py", line 1544, in recipient_for_user_profiles
    recipient_profile_ids = validate_recipient_user_profiles(user_profiles, sender)
  File "/home/tabbott/zulip/zerver/lib/actions.py", line 1523, in validate_recipient_user_profiles
    raise ValidationError(_("You can't send private messages outside of your organization."))
django.core.exceptions.ValidationError: ["You can't send private messages outside of your organization."]

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/tabbott/zulip/zerver/lib/actions.py", line 1811, in _internal_prep_message
    content, realm=realm)
  File "/home/tabbott/zulip/zerver/lib/actions.py", line 1763, in check_message
    raise JsonableError(e.messages[0])
zerver.lib.exceptions.JsonableError: You can't send private messages outside of your organization.
2017-10-27 23:29:50.775 ERR  [] Error queueing internal message by<EMAIL_ADDRESS>You can't send private messages outside of your organization.
Traceback (most recent call last):
  File "/home/tabbott/zulip/zerver/lib/actions.py", line 1760, in check_message
    forwarder_user_profile, sender)
  File "/home/tabbott/zulip/zerver/lib/actions.py", line 1544, in recipient_for_user_profiles
    recipient_profile_ids = validate_recipient_user_profiles(user_profiles, sender)
  File "/home/tabbott/zulip/zerver/lib/actions.py", line 1523, in validate_recipient_user_profiles
    raise ValidationError(_("You can't send private messages outside of your organization."))
django.core.exceptions.ValidationError: ["You can't send private messages outside of your organization."]

I fixed this in 453585abb while working on #7522:
    test_messages: Clean up some error spew by updating a test.

    This test would produce a bunch of log messages with tracebacks,
    complaining that<EMAIL_ADDRESS>tried to send cross-realm PMs
    and can't.  The issue is that the test overrides
    `settings.CROSS_REALM_BOT_EMAILS`, and hasn't kept up with additions
    to the normal value for that setting.  Update it so that welcome-bot
    is permitted as usual.

The hypothesis about recently starting to run consume methods makes sense as what would have triggered these exceptions to actually start firing.


Make it possible to run specified setup scripts synchronously

Make it possible to run specified setup scripts synchronously so that those of them which interact with a person who deploys an app (like this one) do not interfere with each other prompting user simultaneously and messing up each other's console dialogs.

Not relevant for impress 2.x


Automatic argument conversion based on Python 3 function annotations

If a library is implemented using Java, we automatically convert arguments to correct types based on the types in the keyword signature. Similar support would be very handy also with Python based libraries, but Python 2 doesn't have a built-in way to specify type information.
Python 3 supports function annotations that can be used for various purposes, for example, to provide type hints. We could use annotations to get type information and convert arguments based on that. In practice that would mean that keyword like
def example(argument: int):
    # ...

would get the argument as an integer when used like Example    42 in the test data. This would avoid the need to add argument = int(argument) to the keyword or using Example    ${42} in the data.
A problem with Python 3 only solution is that those still using Python 2 don't benefit from it, but this kind of very useful feature would also give a good reason to migrate. Python 2 end-of-life is less than 1.5 years from this day, so spending extra effort to support it doesn't feel beneficial either. A bigger problem is that function annotations are not at all compatible with Python 2, so libraries using them will be incompatible with Python 2 as well. This means Robot's own standard libraries cannot start using this functionality.
Once the support for argument conversion has been added to Python based static libraries, we need to think how to add it to the dynamic library API and to the remote library API. The former has already requested by #2068.
I'd really like to see this already in RF 3.1 and add it to it in high priority. May still be descoped if implementation turns out to be complicated.

One thing to consider is that do we want to handle list and dicts somehow specially. If we implement #2699, we need a utility to parse strings to lists/dicts, and using the same utility if someone uses list/dict as the argument type sounds like a good idea. In practice that would mean that keyword like
def example(arg: dict):
    # ...

would get a dictionary as an argument, not a string looking like a dictionary, when used like
Example    {'a': 1, 'b': 2}

Another thing to consider is how to handle non-string values when a type is specified. Should we validate that the argument is of correct type? If not, should we convert the argument or make it an error?

I think for this case it would make sense to:

try to convert to the type
if conversion fails, there could be two options:

Raise a warning (Warning: could not convert x to y..) and send the data as string (as before)
Raise an error and fail the test

I would go with option 1 for the sake of backwards compatibility with already available tests.

I think that if we try to convert an argument and it fails, we should make it an error similarly if there are other problems with arguments. I think this is how we handle conversion with Java libraries where this functionality already exists. It's a good point that is backwards incompatible, but I doubt such conflict is common. I actually doubt there are many libraries that use annotations in the first place because they couldn't be used at all until RF 3.3 (#2627).
The bigger questions is, what arguments should we try to convert. For example, if we have a keyword
def kw(arg: int):
    pass

and it is passed a string, we naturally convert it. But what should we do if it is given a float like 1.5? Should we pass it as-is, convert it to int, or make it an error? I think it would be best to convert also in this case. The user has clearly declared that the argument should be an int, and we should guarantee that.

Convert in any case, as the signature expects a specific format.

Regarding the list / dict typing: I've dealt with this before using the List and Dict from the typing module and while you have to use an internal to get the types inside of lists / dicts, it proved to be a workable solution for the project I was working on at the time. I've included a runnable snippet below, perhaps this might offer some inspiration.
p.s. Using that internal actually breaks somewhere between Python 3.3 and 3.5.2, as it moved from __parameters__ to __args__, afaik this module still does not expose these properly - but perhaps I'm just not seeing the proper solution here.
import inspect
from typing import List, Dict

def f(list_arg: List[int], dict_arg: Dict[str, int], int_arg: int, default_arg):
    pass

signature = inspect.signature(f)

for name in list(signature.parameters.keys()):
    type_ = signature.parameters[name].annotation
    if type_ is inspect._empty:
        print(name, "defaults to", str)
    elif issubclass(type_, list):
        print(name, "is a", type_, "of", getattr(type_, "__args__", str))
    elif issubclass(type_, dict):
        print(name, "is a", type_, "of", getattr(type_, "__args__", (str, str)))
    else:
        print(name, "is a", type_)

Output:
list_arg is a typing.List[int] of (<class 'int'>,)
dict_arg is a typing.Dict[str, int] of (<class 'str'>, <class 'int'>)
int_arg is a <class 'int'>
default_arg defaults to <class 'str'>

Thanks @jeroenroosen, that's very interesting! If we want to do validation for list/dict items we need to do something like this, but at least in the beginning just making sure keywords accepting lists/dicts get correct types might be enough. I've just got named-only argument support finalized and plan to look at this topic next.

Just realized we could do type conversion also based on argument default values. For example, if we have a keyword with a signature def example(good=False), we can see that good is a Boolean and could do type conversion based on that. This would be very handy and work also with Python 2 code, but could also cause backwards compatibility problems. It would also mean we needed to be more careful when designing the rules for conversion.

This is but problematic with code that defaults to None, which is allowed in Python.
Take this for example:
`
def spam(eggs: int=None):
print(eggs, type(eggs))
spam()
spam(3)

will output:
None <class 'NoneType'>
3 <class 'int'>
`
In cases like these I would expect types to not change if the method is called without arguments, but change if called with something like a float.

I'm not too familiar with RF internals to make a proper judgement of this, but wouldn't this be quite inconsistent? arg=None comes to mind

How to handle None is an important question in general. I think that regardless what type is specified, we need to pass actual Python None object as-is and also convert string None to a None object.
How to handle numbers is another important question. I guess we could argue that if a keyword is defined like spam(eggs: int) and called with a float, converting the float to an integer makes sense. On the other hand, if a keyword is defined just like spam(eggs=0), converting 0.5 to 0 doesn't sound good and would also be badly backwards incompatible. I'm starting to think we shouldn't convert between numerical types.
Perhaps it would be safest to do conversion only if the passed argument is a string. The main motivation of this enhancement is to automatically allow using Spam    42 and not Spam    ${42} in the test data. Doing conversion if you explicitly use Spam    ${42.5} would probably cause more problems than have benefits. Not doing conversion if the argument is not a string would also avoid problems in cases like def maps(eggs: dict) when used like Maps    ${my custom mapping}.

Another design decision related to handling numbers. Let's assume we have keywords
def int_type(arg: int):
    # ...

def int_default(arg=0):
    arg = float(arg)
    # ...

and they are used like
Int type       1.5
Int default    1.5

How should this situation be handled? In the former case it feels pretty logical to consider this an error, but with the latter case that would be a backwards incompatible change. Possible solutions I see:

Don't do any automatic conversion based on default values. I don't like that.

Different conversion logic based on is type information got from explicit annotations or from default values. Possible but adds extra code and makes logic somewhat inconsistent.

If type is int, first try to convert the string to an int and then try float if it fails. In other words, both the above examples would work. It can be considered a problem that if there is an explicit annotation arg: int we still pass a float. Personally I don't think that's a big problem because a) Python in general doesn't enforce types, b) I don't see any real problems caused by this, and c) it's easy to add assert isisntance(arg, int) into the keyword if an int is absolutely mandatory.

What do others think about this?

+1 for passing None as the actual Python object, it would make life much easier in all cases
I would argue that if a method does not expose type hinting then conversion shouldn't be performed at all and arguments are sent as defined in the test scripts. I've seen devs validating arg value with if not arg: which works both for 0 and for None, so cases like method(arg=0) are not uncommon (although not particularly nice as opposed to method(arg=None)).
It could also mean that the method doesn't really care if the type is int, str or x as it will do internal casting, or use the value as-is.

I wrote this earlier but got a little distracted before posting, so I ended up repeating you a little:

I agree that it would make sense to only convert str values, especially if you consider that the more complex types (like dicts, but also Selenium's WebElements come to mind) will usually already be of the proper type for their respective contexts.
Regarding the Python 2 solution, I think it's a bad idea to make assumptions about the type of an argument based on the default value, as you cannot say with certainty whether this is the only or one of many accepted data types, and the function might do conversion differently than RF might (whether this is proper keyword programming is a different discussion.)
To get back to the origin of this issue: in Java you can convert because you know the function's signature. In Python 2 you simply don't have these typing hints (unless you were to e.g. decorate the keyword functions and annotate them that way) so whatever you do is a guess at best: that def kw(arg=0) may actually be intended as a float, so even if its input is a str I don't think it's wise to naively convert it to an int.
The same is of course true for Python 3 functions without type hints (or typing.Any.)
As for adoption of this feature in Python, only converting type hinted arguments might also be a good way to gradually introduce this feature into libraries without causing too many compatibility issues and not having to deal with Python 2 at all.

We seem to agree that only strings should be converted and that 'None' should be converted to None, but there's clear disagreement should we do type conversion also based on default values or not. I agree conversion based on defaults is more error prone, but I also think it would be very useful and ought to be done so that it is safe. Let's anyway make it so that this issue deals about conversion based on type annotations (as the title of the issue says) and then have another issue about conversion based on defaults. Easier to talk about that once this basic issue is done first anyway.

Next question, which types should be convert automatically and how? I'm currently thinking the following. Notice that all these expect the original value to be a string. Also, NONE case-insensitively converted to None object in all cases.

int: Both integers and floats. Convert to float only if converting to integer fails. Other values cause an error.
float: Both integers and floats. Always converted to a float. Other values cause an error.
bool: TRUE and FALSE case-insensitively. Other values passed as-is.
list: Anything that ast.literal_eval converts into a list. Other values cause an error.
dict: Anything that ast.literal_eval converts into a dictionary. Other values cause an error.

In addition to these we probably could consider at least bytes and datetime/data/timedelta but I'm not sure are used enough to be worth the effort. Could obviously be added later.

+0.5
+1
+1
+1

I would personally chose the more explicit (strict) approach to convert to the specified type and if that fails then error out. More precise, for point 1. if int conversion fails then error out.
My reasoning for the prevention of type conversion on point 1. to float is that we work with embedded systems and writing (or trying to write) non-ints  to sysfs devices (e.g,. GPIOS, network devices, etc.)  would have problematic consequences (e.g. unwanted failures/exceptions/more time spent to analyze and debug).
For example:
# echo 1.2 > value | cat value
-sh: write error: Invalid argument
0
# echo 1 > value | cat value
1

Invalid argument is not the most explicit error description and even more discerning is that the example below works fine due to expansion:
# echo "0" > value | cat value
0

Hence the dynamic library (in our case) will do strict type checking and prevent calling the method. I decided not to perform type conversion and just assert to return the responsibility to create proper test data to the tester and not rely on (too many) internal type conversions.
We could also create a slight overhead with a --allow-lazy-type-conversion flag, which would then bypass strict checking and try to convert to float for point 1. in case of failure to convert to int.

Conversion of 0 and 1 to True and False is an interesting proposition, especially since in Python bool is a subclass of int (i.e. isinstance(True, int) is True).
What's also interesting from a language perspective, you can change to bool any int, with 0 being False and everything else True.
Here are some more interesting use cases for bool conversion:
>>> a = bool(0)
>>> a
False
>>> a = bool(30)
>>> a
True
>>> a = bool(-2)
>>> a
True
>>> a = bool(0.0)
>>> a
False

I brought up 0 and 1 because these are well known synonyms for True and False. I don't think it's a good idea to convert just anything: bool("False") is True after all, so the behaviour would be inconsistent if we were to evaluate that as False instead.
I was more thinking among the lines of ConfigParser.getboolean, as those conversions feel pretty natural to me.

Thanks for the feedback! Some new comments:

I don't feel strongly should we try to convert to a float if the type is specified to be an int and int conversion fails. I guess it would be more correct to be strict, but I don't see much harm accepting strings like 1.2 as well, especially when we pass actual floats (e.g. ${1.2}) forward as-is anyway. If we do add type conversion also based on default values, there float conversion in this case is more important to avoid backwards incompatibility issues. We already agreed not to talk about that in this issue, though.

I definitely don't want command line options to control this behavior.

Converting strings 0 and 1 to False and True, respectively, can be considered. That's something that could actually be added to our existing utils.is_truthy utility that is widely used by Robot itself as well as many external libraries like SeleniumLibrary and SSHLibrary. If we'd use is_truthy for conversion here, then also NO would be considered False which ought to be fine. As I already commented, other strings should be passed as-is without any errors.

If we handle bytes, then we probably should do direct Unicode code point to byte conversion. You could then represent the null byte with \x00, byte 228 as \xe4 or ä, and so on. Bytes above 255 would naturally cause an error. In practice this would mean encoding the string using Latin-1.

If we'd handle datetime.datetime/date/timedelta, we should use our own DateTime library for conversion. That would be consistent with how many libs currently handled dates and times and would also make using dates/times pretty convenient.

Support for enums sounds like a good idea. Perhaps @jeroenroosen can provide a pull request adding that once the functionality is ready otherwise. It ought to be easy to add conversion for new times in general.

We could also consider supporting [Decimal}(https://docs.python.org/3/library/decimal.html).

My prototype code worked so well that I decided to push it into a remote branch for others to see and test. Easier to discuss about the details when we have something concrete that actually works.
I won't have time to continue working with this more during the weekend, other than possibly answering questions via mobile. Next week I ought to have some time, but I also need to continue our woodshed project at the summer cottage. =)

I added enum support as well.

Thanks @jeroenroosen! I added few comments to your PR but in general the enum support looks nice and is definitely worth adding. I'm still on holiday next week and unless it gets rainy I won't be coding much. I'll return back to this more actively the week after.

Support for these types has been added in the remote branch lately:

enums (by @jeroenroosen)
bytes
Decimal
datetime, date and timedelta

We ought to now support all the most important "normal" types. Next I plan to look at the typing module to see what types from there we should support.

I rebased the feature branch where I've been working and needed to force push changes to the remove branch. If someone is working with the remote branch, you need to checkout the branch again. Soon it's time to merge this to master to avoid the need for rebasing.

Now also Libdoc shows annotations. This functionality ought to ready to be merged to the master, but still want to look at the code once more with fresh eyes. Feedback also from others is highly appreciated as well. The remote branch with the changes is here:
https://github.com/robotframework/robotframework/compare/type-conversion
Looking at the comments above, there are two decision to be made:

What to do if argument has int type but the value that is used is like '1.2'? At the moment we convert such values a float, but it would be a bit more pedantic to raise an error instead. The reason I don't think error isn't mandatory is that it would anyway be possible to use such a keyword with an actual float (we only convert strings, don't do general argument type validation). Also if someone has declared argument to be something like List[int], we only convert the argument into a list and don't look at the internal values.

Should we follow ConfigParser.getboolean when deciding which values are true and which false. At the moment the main difference is that we don't consider strings 'off' and '0' false. That could be easily changed in utils.is_truthy, but it would need a separate issue. Another small difference is that we return strings like 'True' and 'on' as-is while the aforementioned utility converts them to True. Because all non-empty strings are considered true, that shouldn't matter much.

One thing I've implemented in our codebase is automatic conversion to Enum types from robot input using a decorator. This means you can use python enums in all your library code, and simply pass the names of the Enums as strings in from Robot.
I thought this might be useful for you, I've provided an example and my implementation here
# python library
class SomeEnum(Enum):
    ONE = 1

@enumify
def some_robot_keyword_function(enum_param: SomeEnum):
    ...

# robot file
# the str param "ONE" will automatically get converted to SomeEnum.ONE
some_enum_func  ONE

Implementation
def _should_param_be_enumified(value, param: Parameter) -> bool:
    return isinstance(value, str) and issubclass(param.annotation, Enum)

def enumify(func):
    def wraps(*args, **kwargs):
        sig = signature(func)

        new_args = []
        new_kwargs = {}

        # inspect kw args
        for arg_name, arg_value in kwargs.items():
            if arg_name in sig.parameters:  # arg is declared in func signature
                param = sig.parameters[arg_name]
                if _should_param_be_enumified(arg_value, param):
                    enum = param.annotation[arg_value]  # cast to enum from str value
                    new_kwargs[arg_name] = enum  # update kwargs
                else:
                    new_kwargs[arg_name] = arg_value

        # go through non-kw args
        for arg_value, param in zip(args, sig.parameters.values()):
            if _should_param_be_enumified(arg_value, param):
                enum = param.annotation[arg_value]  # cast to enum from str value
                new_args.append(enum)
            else:
                new_args.append(arg_value)

        return func(*new_args, **new_kwargs)

    return wraps

Enum support had been already implement by @jeroenroosen and merged into the remote branch. Does it work for you or would it need to be adapted somehow?

Ah, my apologies, I was looking at the wrong branch and didn't realize this had been implemented already. Continue on with the good work!

Submitted #2927 to consider '0' and 'off' to be false in general and now they are considered false also when doing type conversion. Also changes 'on', 'yes', and '1' to yield True and '' to yield False. Earlier they were returned as-is.
I think I won't touch integer conversion now but it can still be changed later. Plan to merge this to master after lunch, but not sure do I have time for it. Soon anyway.

These changes have now been merged to master. I think the only missing thing related to type conversion based on type annotations is documentation. Adding type conversion to the dynamic API and doing it based on argument default values are highly related enhancements but require separate issues.

Been implementing type conversion based on default values (#2932) and decided to do some changes to the underlying conversion logic:

If type is explicitly specified to be int using annotations, don't try converting to float if int conversion fails. This will work differently if the type is got implicitly from default values.

Add support for bytearray. Main reason is to support bytes with Python 2 where the distinction between "normal" bytes and strings is not clear.

Support type(None) (and possibly also plain None) to indicate that string NONE should be converted to the None object.

I was also thinking should we make bool conversion stricter and only support known false and true strings making other strings failures. This would be consistent with the stricter int conversion as well as with how ConfigParser.getboolean behaves, but it would limit the possibility to consider also some other strings false. For example, some of the Robot's own BuiltIn keyowrds consider no values false when used with the values argument and in non-English environments using something like ei (Finnish) or 不 (Chinese) could be nice. In the end I considered the benefits of passing non-recognized strings as-is greater than stricter validation.

Thought this issue is ready, except for writing documentation and possibly slightly enhanced error reporting, but then executed tests on Python 3.7 and noticed that the typing module has changed so that the current implementation doesn't recognize the types it exposes.: https://bugs.python.org/issue34568
Unless the old behavior of the typing module is restored or there's some other clean way to recognize these types, it might be easiest just to explicitly document we don't support it.

PEP-563 adds from __future__ import annotations that changes how annotations are evaluated. We need to take that into account but that can be done after alpha 2. Reopening this to make sure we don't forget about it.


_1password-gui-beta: 8.10.26-1 → 8.10.26-38

https://releases.1password.com/linux/beta/#1password-for-linux-8.10.26-38
Description of changes

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

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

I would be tempted to reenable Wayland support, as I've not had crashes happen since 8.10.24, but I don't believe 1p has said anything about fixing this so this might be entirely unintentional and could break again.

Actually, searching the forums, there seem to be a lot of complaints about Wayland support being broken still under a variety of configurations, so it's probably not worth bringing back the same mechanism as the rest of electron has.

If it works for you I recommend you an overlay, but I don't think it's a good idea to do it in nixpkgs as we can't really do something then rollback on bigger issues...


Prepare plugin does not work for texture atlas

Hi,
I just noticed that preparing individual objects in a texture atlas works, but preparing the whole atlas once and for all does not work. According to the plugin docs, prepare should accept a BaseTexture, but this does not give any performance boost in my case.
The 'actiondetails' texture referenced below is a 4096x4096 atlas.
    var hull = new PIXI.Sprite(textures.get('actiondetails')[`${scls.toFilename(newObj.id)}_hull.png`]);
    renderer.plugins.prepare.upload(hull); //SPEEDY on first GPU load!
    //renderer.plugins.prepare.upload(textures.get('actiondetails')); //SLOW on first GPU load!

Environment

pixi.js version: 5.2.0
platform: Windows 10 desktop and iPhone 6

What prepare does: it goes recursively in scene and searches for BaseTexture's.
Its not possible to upload single Texture of atlas, only whole atlas has be uploaded. It actually calls renderer.texture.bind(myAtlasBaseTexture)  - that's all that it does.
https://github.com/pixijs/pixi.js/blob/805387d190d36812fe53d382f3ddc5242d4d6a06/packages/prepare/src/Prepare.js#L68-L70
Prepare/BasePrepare classes are plain JS code , no webgl magic. People found many problems with it in v5, you should debug it for your case too :)

Okidoke. I have located the problem.
First, there was an error on my side. I supplied a texture received from the resource loader, which is not of PIXI.BaseTexture type. So naturally, there was no hook for it in Prepare.
However, when fixing that error and supplying a BaseTexture as received from the resource loader, this didn't work either. The reason for this is that there is no hook for BaseTexture's, but only for objects having a baseTexture as a property, look here.
So, either I think this doc should be clarified, or the hooks should be updated to support that the supplied item actually is of the documented types.
I suggest the latter solution.
With the current design, however, it works fine to supply the resource loader's resource.spritesheet member to the Prepare.upload method if immediate preparation of all loaded resources is intended.

Make a PR. Both solutions  have a high probability of approval. Of course, docs PR are easier to review.


[DO NOT MERGE] Add API documentation for the NuGet.org deprecate API

DO NOT MERGE YET.
This feature is currently in private preview, and we are evaluating the timeline of making it into a public preview.

Learn Build status updates of commit ac57d8c:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs/api/package-publish-resource.md
:warning:Warning
View
Details

docs/api/rate-limits.md
:white_check_mark:Succeeded
View

docs/api/package-publish-resource.md

Line 112, Column 51: [Warning: bookmark-not-found] Cannot find bookmark '#delete-a-package' in 'api/package-publish-resource.md', did you mean '#relist-a-package'?

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Learn Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings or suggestions unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

Learn Build status updates of commit a7961f1:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/api/package-publish-resource.md
:white_check_mark:Succeeded
View

docs/api/rate-limits.md
:white_check_mark:Succeeded
View

docs/TOC.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

Learn Build status updates of commit aede829:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/api/package-publish-resource.md
:white_check_mark:Succeeded
View

docs/api/rate-limits.md
:white_check_mark:Succeeded
View

docs/TOC.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

@joelverhagen - Is this still needed or can we close?

We still need this. I have not had the time to push the Deprecation API work through. Once I do, this PR will be able to move out of the draft state, take reviews, and be merged.