Move Interface Enabled to metadata textproto

PiperOrigin-RevId: 548023881

Pull Request Functional Test Report for #1886 / 40633c38268944077790749f189125dd8c814568
Virtual Devices

Device
Test
Test Documentation
Job
Raw Log

Arista cEOS

RT-5.3: Aggregate BalancingP4RT-1.1: Base P4RT FunctionalityTE-1.1: Static ARPTE-11.3: Backup NHG: ActionsTE-13.2: gRIBI route DELETE during FailoverRT-1.2: BGP Policy & Route InstallationRT-1.7: Local BGP TestP4RT-3.2: Google Discovery Protocol: PacketOutgNMI-1.15: Set RequestsgNMI-1.10: Telemetry: Basic CheckDP-1.14: QoS basic testDP-1.4: QoS Interface Output Queue CountersTE-3.7: Base Hierarchical NHG UpdateDP-1.8: Two strict priority queue traffic testRT-5.4: Aggregate Forwarding ViableDP-1.10: Mixed strict priority and WRR traffic testDP-1.9: WRR traffic testP4RT-5.2: Traceroute PacketoutTE-14.1: gRIBI ScalingTE-8.1: DUT Daemon FailureDP-1.11: Bursty traffic testTE-13.1: gRIBI route ADD during FailoverP4RT-6.1: Required Packet I/O rate: PerformanceTE-11.1: Backup NHG: Single NHP4RT-7.2: LLDP: PacketOutRT-1.10: BGP Keepalive and HoldTimer Configuration TestP4RT-5.1: Traceroute: PacketInTE-1.2: My Station MACTE-15.1: gRIBI ComplianceTE-8.2: Supervisor FailureP4RT-1.2: P4RT Daemon FailureDP-1.7: One strict priority queue traffic testRT-3.1: Policy based VRF selectionTE-4.2: Persistence ModeRT-2.1: Base IS-IS Process and AdjacenciesTE-2.1: gRIBI IPv4 EntryRT-1.3: BGP Route PropagationTE-6.2: Route Removal In Non Default VRFRT-5.1: Singleton InterfaceOC-1.2: Default Address FamiliesP4RT-7.1: LLDP: PacketIngNOI-2.1: Packet-based Link QualificationTE-5.1: gRIBI Get RPCTE-3.2: Traffic Balancing According to WeightsP4RT-3.1: Google Discovery Protocol: PacketInTE-3.1: Base Hierarchical Route InstallationRT-1.5: BGP Prefix LimitRT-5.2: Aggregate InterfacesRT-6.1: Core LLDP TLV PopulationRT-3.2: Multiple <Protocol, DSCP> Rules for VRF SelectionTE-3.6: ACK in the Presence of Other RoutesTE-3.5: Ordering: ACK ReceivedRT-2.2: IS-IS LSP UpdatesTE-11.2: Backup NHG: Multiple NHTE-4.1: Base Leader ElectionTE-6.1: Route Removal via Flush

Cisco 8000E

RT-5.3: Aggregate BalancingP4RT-1.1: Base P4RT FunctionalityTE-1.1: Static ARPTE-11.3: Backup NHG: ActionsTE-13.2: gRIBI route DELETE during FailoverRT-1.2: BGP Policy & Route InstallationRT-1.7: Local BGP TestP4RT-3.2: Google Discovery Protocol: PacketOutgNMI-1.15: Set RequestsgNMI-1.10: Telemetry: Basic CheckDP-1.14: QoS basic testDP-1.4: QoS Interface Output Queue CountersTE-3.7: Base Hierarchical NHG UpdateDP-1.8: Two strict priority queue traffic testRT-5.4: Aggregate Forwarding ViableDP-1.10: Mixed strict priority and WRR traffic testDP-1.9: WRR traffic testP4RT-5.2: Traceroute PacketoutTE-14.1: gRIBI ScalingTE-8.1: DUT Daemon FailureDP-1.11: Bursty traffic testTE-13.1: gRIBI route ADD during FailoverP4RT-6.1: Required Packet I/O rate: PerformanceTE-11.1: Backup NHG: Single NHP4RT-7.2: LLDP: PacketOutRT-1.10: BGP Keepalive and HoldTimer Configuration TestP4RT-5.1: Traceroute: PacketInTE-1.2: My Station MACTE-15.1: gRIBI ComplianceTE-8.2: Supervisor FailureP4RT-1.2: P4RT Daemon FailureDP-1.7: One strict priority queue traffic testRT-3.1: Policy based VRF selectionTE-4.2: Persistence ModeRT-2.1: Base IS-IS Process and AdjacenciesTE-2.1: gRIBI IPv4 EntryRT-1.3: BGP Route PropagationTE-6.2: Route Removal In Non Default VRFRT-5.1: Singleton InterfaceOC-1.2: Default Address FamiliesP4RT-7.1: LLDP: PacketIngNOI-2.1: Packet-based Link QualificationTE-5.1: gRIBI Get RPCTE-3.2: Traffic Balancing According to WeightsP4RT-3.1: Google Discovery Protocol: PacketInTE-3.1: Base Hierarchical Route InstallationRT-1.5: BGP Prefix LimitRT-5.2: Aggregate InterfacesRT-6.1: Core LLDP TLV PopulationRT-3.2: Multiple <Protocol, DSCP> Rules for VRF SelectionTE-3.6: ACK in the Presence of Other RoutesTE-3.5: Ordering: ACK ReceivedRT-2.2: IS-IS LSP UpdatesTE-11.2: Backup NHG: Multiple NHTE-4.1: Base Leader ElectionTE-6.1: Route Removal via Flush

Cisco XRd

RT-5.3: Aggregate BalancingP4RT-1.1: Base P4RT FunctionalityTE-1.1: Static ARPTE-11.3: Backup NHG: ActionsTE-13.2: gRIBI route DELETE during FailoverRT-1.2: BGP Policy & Route InstallationRT-1.7: Local BGP TestP4RT-3.2: Google Discovery Protocol: PacketOutgNMI-1.15: Set RequestsgNMI-1.10: Telemetry: Basic CheckDP-1.14: QoS basic testDP-1.4: QoS Interface Output Queue CountersTE-3.7: Base Hierarchical NHG UpdateDP-1.8: Two strict priority queue traffic testRT-5.4: Aggregate Forwarding ViableDP-1.10: Mixed strict priority and WRR traffic testDP-1.9: WRR traffic testP4RT-5.2: Traceroute PacketoutTE-14.1: gRIBI ScalingTE-8.1: DUT Daemon FailureDP-1.11: Bursty traffic testTE-13.1: gRIBI route ADD during FailoverP4RT-6.1: Required Packet I/O rate: PerformanceTE-11.1: Backup NHG: Single NHP4RT-7.2: LLDP: PacketOutRT-1.10: BGP Keepalive and HoldTimer Configuration TestP4RT-5.1: Traceroute: PacketInTE-1.2: My Station MACTE-15.1: gRIBI ComplianceTE-8.2: Supervisor FailureP4RT-1.2: P4RT Daemon FailureDP-1.7: One strict priority queue traffic testRT-3.1: Policy based VRF selectionTE-4.2: Persistence ModeRT-2.1: Base IS-IS Process and AdjacenciesTE-2.1: gRIBI IPv4 EntryRT-1.3: BGP Route PropagationTE-6.2: Route Removal In Non Default VRFRT-5.1: Singleton InterfaceOC-1.2: Default Address FamiliesP4RT-7.1: LLDP: PacketIngNOI-2.1: Packet-based Link QualificationTE-5.1: gRIBI Get RPCTE-3.2: Traffic Balancing According to WeightsP4RT-3.1: Google Discovery Protocol: PacketInTE-3.1: Base Hierarchical Route InstallationRT-1.5: BGP Prefix LimitRT-5.2: Aggregate InterfacesRT-6.1: Core LLDP TLV PopulationRT-3.2: Multiple <Protocol, DSCP> Rules for VRF SelectionTE-3.6: ACK in the Presence of Other RoutesTE-3.5: Ordering: ACK ReceivedRT-2.2: IS-IS LSP UpdatesTE-11.2: Backup NHG: Multiple NHTE-4.1: Base Leader ElectionTE-6.1: Route Removal via Flush

Juniper cPTX

RT-5.3: Aggregate BalancingP4RT-1.1: Base P4RT FunctionalityTE-1.1: Static ARPTE-11.3: Backup NHG: ActionsTE-13.2: gRIBI route DELETE during FailoverRT-1.2: BGP Policy & Route InstallationRT-1.7: Local BGP TestP4RT-3.2: Google Discovery Protocol: PacketOutgNMI-1.15: Set RequestsgNMI-1.10: Telemetry: Basic CheckDP-1.14: QoS basic testDP-1.4: QoS Interface Output Queue CountersTE-3.7: Base Hierarchical NHG UpdateDP-1.8: Two strict priority queue traffic testRT-5.4: Aggregate Forwarding ViableDP-1.10: Mixed strict priority and WRR traffic testDP-1.9: WRR traffic testP4RT-5.2: Traceroute PacketoutTE-14.1: gRIBI ScalingTE-8.1: DUT Daemon FailureDP-1.11: Bursty traffic testTE-13.1: gRIBI route ADD during FailoverP4RT-6.1: Required Packet I/O rate: PerformanceTE-11.1: Backup NHG: Single NHP4RT-7.2: LLDP: PacketOutRT-1.10: BGP Keepalive and HoldTimer Configuration TestP4RT-5.1: Traceroute: PacketInTE-1.2: My Station MACTE-15.1: gRIBI ComplianceTE-8.2: Supervisor FailureP4RT-1.2: P4RT Daemon FailureDP-1.7: One strict priority queue traffic testRT-3.1: Policy based VRF selectionTE-4.2: Persistence ModeRT-2.1: Base IS-IS Process and AdjacenciesTE-2.1: gRIBI IPv4 EntryRT-1.3: BGP Route PropagationTE-6.2: Route Removal In Non Default VRFRT-5.1: Singleton InterfaceOC-1.2: Default Address FamiliesP4RT-7.1: LLDP: PacketIngNOI-2.1: Packet-based Link QualificationTE-5.1: gRIBI Get RPCTE-3.2: Traffic Balancing According to WeightsP4RT-3.1: Google Discovery Protocol: PacketInTE-3.1: Base Hierarchical Route InstallationRT-1.5: BGP Prefix LimitRT-5.2: Aggregate InterfacesRT-6.1: Core LLDP TLV PopulationRT-3.2: Multiple <Protocol, DSCP> Rules for VRF SelectionTE-3.6: ACK in the Presence of Other RoutesTE-3.5: Ordering: ACK ReceivedRT-2.2: IS-IS LSP UpdatesTE-11.2: Backup NHG: Multiple NHTE-4.1: Base Leader ElectionTE-6.1: Route Removal via Flush

Nokia SR Linux

RT-5.3: Aggregate BalancingP4RT-1.1: Base P4RT FunctionalityTE-1.1: Static ARPTE-11.3: Backup NHG: ActionsTE-13.2: gRIBI route DELETE during FailoverRT-1.2: BGP Policy & Route InstallationRT-1.7: Local BGP TestP4RT-3.2: Google Discovery Protocol: PacketOutgNMI-1.15: Set RequestsgNMI-1.10: Telemetry: Basic CheckDP-1.14: QoS basic testDP-1.4: QoS Interface Output Queue CountersTE-3.7: Base Hierarchical NHG UpdateDP-1.8: Two strict priority queue traffic testRT-5.4: Aggregate Forwarding ViableDP-1.10: Mixed strict priority and WRR traffic testDP-1.9: WRR traffic testP4RT-5.2: Traceroute PacketoutTE-14.1: gRIBI ScalingTE-8.1: DUT Daemon FailureDP-1.11: Bursty traffic testTE-13.1: gRIBI route ADD during FailoverP4RT-6.1: Required Packet I/O rate: PerformanceTE-11.1: Backup NHG: Single NHP4RT-7.2: LLDP: PacketOutRT-1.10: BGP Keepalive and HoldTimer Configuration TestP4RT-5.1: Traceroute: PacketInTE-1.2: My Station MACTE-15.1: gRIBI ComplianceTE-8.2: Supervisor FailureP4RT-1.2: P4RT Daemon FailureDP-1.7: One strict priority queue traffic testRT-3.1: Policy based VRF selectionTE-4.2: Persistence ModeRT-2.1: Base IS-IS Process and AdjacenciesTE-2.1: gRIBI IPv4 EntryRT-1.3: BGP Route PropagationTE-6.2: Route Removal In Non Default VRFRT-5.1: Singleton InterfaceOC-1.2: Default Address FamiliesP4RT-7.1: LLDP: PacketIngNOI-2.1: Packet-based Link QualificationTE-5.1: gRIBI Get RPCTE-3.2: Traffic Balancing According to WeightsP4RT-3.1: Google Discovery Protocol: PacketInTE-3.1: Base Hierarchical Route InstallationRT-1.5: BGP Prefix LimitRT-5.2: Aggregate InterfacesRT-6.1: Core LLDP TLV PopulationRT-3.2: Multiple <Protocol, DSCP> Rules for VRF SelectionTE-3.6: ACK in the Presence of Other RoutesTE-3.5: Ordering: ACK ReceivedRT-2.2: IS-IS LSP UpdatesTE-11.2: Backup NHG: Multiple NHTE-4.1: Base Leader ElectionTE-6.1: Route Removal via Flush

Openconfig Lemming

RT-5.3: Aggregate BalancingP4RT-1.1: Base P4RT FunctionalityTE-1.1: Static ARPTE-11.3: Backup NHG: ActionsTE-13.2: gRIBI route DELETE during FailoverRT-1.2: BGP Policy & Route InstallationRT-1.7: Local BGP TestP4RT-3.2: Google Discovery Protocol: PacketOutgNMI-1.15: Set RequestsgNMI-1.10: Telemetry: Basic CheckDP-1.14: QoS basic testDP-1.4: QoS Interface Output Queue CountersTE-3.7: Base Hierarchical NHG UpdateDP-1.8: Two strict priority queue traffic testRT-5.4: Aggregate Forwarding ViableDP-1.10: Mixed strict priority and WRR traffic testDP-1.9: WRR traffic testP4RT-5.2: Traceroute PacketoutTE-14.1: gRIBI ScalingTE-8.1: DUT Daemon FailureDP-1.11: Bursty traffic testTE-13.1: gRIBI route ADD during FailoverP4RT-6.1: Required Packet I/O rate: PerformanceTE-11.1: Backup NHG: Single NHP4RT-7.2: LLDP: PacketOutRT-1.10: BGP Keepalive and HoldTimer Configuration TestP4RT-5.1: Traceroute: PacketInTE-1.2: My Station MACTE-15.1: gRIBI ComplianceTE-8.2: Supervisor FailureP4RT-1.2: P4RT Daemon FailureDP-1.7: One strict priority queue traffic testRT-3.1: Policy based VRF selectionTE-4.2: Persistence ModeRT-2.1: Base IS-IS Process and AdjacenciesTE-2.1: gRIBI IPv4 EntryRT-1.3: BGP Route PropagationTE-6.2: Route Removal In Non Default VRFRT-5.1: Singleton InterfaceOC-1.2: Default Address FamiliesP4RT-7.1: LLDP: PacketIngNOI-2.1: Packet-based Link QualificationTE-5.1: gRIBI Get RPCTE-3.2: Traffic Balancing According to WeightsP4RT-3.1: Google Discovery Protocol: PacketInTE-3.1: Base Hierarchical Route InstallationRT-1.5: BGP Prefix LimitRT-5.2: Aggregate InterfacesRT-6.1: Core LLDP TLV PopulationRT-3.2: Multiple <Protocol, DSCP> Rules for VRF SelectionTE-3.6: ACK in the Presence of Other RoutesTE-3.5: Ordering: ACK ReceivedRT-2.2: IS-IS LSP UpdatesTE-11.2: Backup NHG: Multiple NHTE-4.1: Base Leader ElectionTE-6.1: Route Removal via Flush

Help


Add description for AS Number requirements.

In Microsoft Peering, we can set peer ASN and customer ASN.
Peer ASN can be public and private ASN, but customer ASN can only be public ASN.
We need to add this explanation because the current documentation confuses customers.

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

#sign-off

#sign-off


Error with 2FA

Gogs version (or commit ref): <IP_ADDRESS>0
Git version: 2.1.4
Operating system: Debian 8
Database (use [x]):

[ ] PostgreSQL
[x] MySQL
[ ] MSSQL
[ ] SQLite

Can you reproduce the bug at https://try.gogs.io:

[ ] Yes (provide example URL)
[x] No
[ ] Not relevant

Log gist (usually found in log/gogs.log): https://hastebin.com/ixisudixux.sql

Description
I can't confirm the 2FA because everytime i get this error(i use authy or google authenticator to generate the code) http://prntscr.com/j9namy

It is possible that your server SECRET_KEY has been modified, in that case... you would have to disable all current 2FA and reenable them.


Broken Link for Java book

3D Programming in Java - Daniel Selman
http://www.mat.uniroma2.it/~picard/SMC/didattica/materiali_did/Java/Java_3D/Java_3D_Programming.pdf

What do you mean bey broken?
It opens fine for me

I guess the link was down when I first came across it. It's working for me now! Sorry, I am closing the issue.


Why?

Why are you developing this app? You have a MacBook and don't have few bucks a month for unlimited music? If you don't, you have to listen to the ads – that's how it works. Or if you hate ads and don't want to pay for it, don't use Spotify at all. But this automatic muting is stealing or at least unethical, don't you think?
Maybe the time you invested into the development (150 commits isn't few) you could use to make some money to remove the ads (and get better quality, offline usage and better mobile support too).
Last think, have you even read EULA (I haven't), I think there can be something about this.

Why are you developing this app?

For experience. I just love to code and maintaining a real application helps you to get better. It is fun for me and I like to do it in my free time.

You have a MacBook and don't have few bucks a month for unlimited music?

I personally do have a Spotify subscription but anyway, just because you are on a Mac OS does not imply that you have a lot of money. As a pupil or student maybe you have got a Mac from your parents. In Germany a subscription would cost converted 13,87US$ / month. That would be 166,44US$ a year. I do not think that this are "a few bucks" for those kind of poeple.
Furthermore there are many countries Spotify does not accept payments from. @ArtemGordinsky for example started to write his little AppleScript because this was the only way for him to experience Spotify without ads.

This automatic muting is stealing or at least unethical, don't you think?

We are just muting the ads. The only one damaged are the companies which ads are played because we do not hear their ads but nevertheless they have to pay for it and personally I do not think this will hurt them. I could be wrong though. Please feel free to tell me if you think differently. Spotify or the Artists will get the same amount of money they would get if the ads were not muted.

Maybe the time you invested into the development (150 commits isn't few) you could use to make some money to remove the ads

As I said, I love to invest time into development. It is fun to write code. Apart from this I do have a Spotify subscription...
I hope I could answer most of your questions. This just reflects my own opinion, so if you disagree or if there are any questions left open, feel free to comment.

Thanks for writing that response EneasR. Excellent, thoughtful, well reasoned reply. I'd just like to voice extreme gratitude and appreciation that you guys do provide this service. It's rare to see something as a niche open source project that's so well maintained, regularly updated, and that just works.
Cheers,
Ben

Sorry, "a few bucks" really was an exaggeration, especially for a student. But
it's still much better than buying every song you listen to.
I understand you a bit, I love development too. But imagine everyone would use
Spotifree, Spotify would has to cancel its free program, because no one would
like to advertise there.
Anyway, thank you for sharing your point of view.
On Tue, Jan 05, 2016 at 12:07 PM, Eneas <<EMAIL_ADDRESS><EMAIL_ADDRESS>> wrote:
Why are you developing this app?
For experience. I just love to code and maintaining a real application helps you
to get better. It is fun for me and I like to do it in my free time.
You have a MacBook and don't have few bucks a month for unlimited music?
I personally do have a Spotify subscription but anyway, just because you are on
a Mac OS does not imply that you have a lot of money. As a pupil or student
maybe you have got a Mac from your parents. In Germany a subscription would cost
converted 13,87US$ / month. That would be 166,44US$ a year. I do not think that
this are "a few bucks" for those kind of poeple.
Furthermore there are many countries Spotify does not accept payments from. @ArtemGordinsky [https://github.com/ArtemGordinsky] for example started to write his little AppleScript because this was the only
way for him to experience Spotify without ads.
This automatic muting is stealing or at least unethical, don't you think?
We are just muting the ads. The only one damaged are the companies which ads are
played because we do not hear their ads but nevertheless they have to pay for it
and personally I do not think this will hurt them. I could be wrong though.
Please feel free to tell me if you think differently. Spotify or the Artists
will get the same amount of money they would get if the ads were not muted.
Maybe the time you invested into the development (150 commits isn't few) you
could use to make some money to remove the ads
As I said, I love to invest time into development. It is fun to write code.
Apart from this I do have a Spotify subscription...
I hope I could answer most of your questions. This just reflects my own opinion,
so if you disagree or if there are any questions left open, feel free to
comment.
—
Reply to this email directly or view it on GitHub
[https://github.com/ArtemGordinsky/Spotifree/issues/71#issuecomment-168973266] .[https://github.com/notifications/beacon/ADPHO7EBktbnQVHRXgexzB0NVd9kEUalks5pW5uFgaJpZM4G-Oj2.gif]

But imagine everyone would use Spotifree, Spotify would has to cancel its free program, because no one would like to advertise there.

You are right, but there is no need to imagine a scenario like this. According to this source there are 75 million active Spotify users. Minus the 20 million subscribers, there are 55 million users with ads. Spotifree was downloaded about 50.000 times. These are just downloads but because I don't know how many of these are active users, I'll just use all of them. This would make 0,09% relevant Spotify users who are muting ads with Spotifree. I don't see any danger here.
Furthermore there are are video ads and popups, which are not blocked by Spotifree. Advertisers are still able to reach Spotifree users.
I think in the end, like it is with every other ad blocker, it is open for everyone to decide for himselft whether using it is acceptable or not. If you don't think it is, don't use it. It is just giving them an opportunity.

Yes, I agree it's everyone's choice.


Add options to document list component

Adds the following...
Add 'subtext' option, small grey text to appear beneath metadata. This is needed for search results in finders, (where we want to use the document list component) and has been styled to match the existing look.

Add 'highlight' option, including optional highlight text. This is needed to highlight the 'top result' in finders.

Trello card: https://trello.com/c/DAblviIN/793-investigate-using-more-components-in-finder-frontend
Some examples of what this looks like currently:

subtext (to be added)
highlight option can be seen here, but you need to set a request header of GOVUK-ABTest-FinderAnswerABTest to B (I'd suggest using this chrome extension). In the real world it wouldn't have the metadata beneath the description text, I just left this in for the component guide to make sure the layout still worked okay.

@andysellick Have you got links to finders with these on? Specifically, the subtext one

@andysellick Have you got links to finders with these on? Specifically, the subtext one

I haven't, unfortunately. The only way I know what these things look like is by putting debug code into my local so it outputs. But I'll try to find some examples when I look at addressing the reviews.

I'm wondering if the subtext addition could be structured as part of gem-c-document-list__item-metadata (potentially with a modifier for the grey font colour) instead of a new element (gem-c-document-list__subtext)

@alex-ju that's an approach I hadn't considered probably because of the way the data in finder-frontend gets assembled before it (would be) passed to the component. I'm in no huge rush to merge this, shall we chat about it offline? Would appreciate your input.

I'm wondering if the subtext addition could be structured as part of gem-c-document-list__item-metadata (potentially with a modifier for the grey font colour) instead of a new element (gem-c-document-list__subtext)

@alex-ju just to summarise the conversation we just had - I'm going to leave the subtext option in place, but remove the styling from the component, as the appearance of this is specific to the application I'm going to use it in (finder-frontend) and there's additional styling already in finder-frontend for the debug stuff that will also be inside the subtext element.

@vanitabarrett turns out the subtext 'First published by' is broken 😱 but it's being fixed in this PR 🎉

@vanitabarrett the 'First published by' is fixed and deployed, I've added an example link to the PR but it's also live at the link below. I've removed the styling for the subtext option as it feels more appropriate for it to go in finder-frontend (there's going to be more than just this inside this element).
Are you happy with this PR?
https://www.gov.uk/search/all?parent=&keywords="every+child+matters"&level_one_taxon=&manual=&public_timestamp[from]=&public_timestamp[to]=&order=relevance

@andysellick Looks good to me 👍 The only comment I have is maybe the first commit message needs to be changed to reflect the fact that you're not styling it to match the existing look, and that styles will be applied within finder-frontend?


Added support for cc, bcc, and replyTo fields for email API

VulcanEmail.send and VulcanEmail.buildAndSend now accepts cc, bcc, and replyTo fields.
VulcanEmail.buildAndSendHTML doesn't not support cc, bcc, and replyTo in order to keep it backwards compatible.

@SachaG you are right. Makes sense to add them to the end.
There are two more arguments: textand throwErrors at the end of VulcanEmail.send. Then when calling it should we add undefined for those variables?

Yeah. Although ideally we would replace all arguments with a single object argument like we've been doing elsewhere, and bypass the issue entirely. You can even do it in a backwards-compatible way with the following pattern:
f = (a, b, c) => {
  if (typeof a === 'object') {
    var { a, b, c } = a;
  }
  console.log({ a, b, c });
}

@SachaG what do you think on the last changes. Now is backward compatible.
I've discussed it with @ochicf and he suggested to add a Utils helpers to deal with this refactoring. See changes. ;)

Nice, but I'm not sure if we really need that helper? If your function is VulcanEmail.send = (options) => {...} then options is already your object?
Then you just need to handle the backwards-compatibility case with:
if (arguments.length === 1) {
  ({ foo, bar, baz } = options)l
} else {
  ([ foo, bar, baz ] = arguments);
}

At least I think this should work?

It is a different approach. By using the helpers, we avoid repeating the extraction logic for every single function that gets refactored. It was a way to implement DRY.
You are the owner 😅, let me know if you prefer your way and I'll make the changes. 😉

I just think using the helper in this way makes the code overly complex. Keeping things DRY is a good idea but the downside is that it introduces one more layer of things that can go wrong. So in this case let's KISS instead of DRY ;)

Changes made

Nice, thanks!


[REQUEST] set custom binary file name

What would you like to have implemented?
Add an option to set the different name for the binary chrome file, so instead 'chromium' set 'chromium-1' or any.

As a new option, for example customName
Why would it be useful?
When we run browser in AWS Lambda with web scrapping Crawlee and want to use AutoscaledPool to run crawlers simultaneously we can't do that because /tmp/chromium is locked and get an error. The idea is when we extract file to /tmp use different names to avoid that. Then we can run many browsers in AWS Lambda and scrapping will be much faster.

Probably not. You should just run parallel lambdas


[sensor] Visualize observation from depth sensor

Motivation and Context
As titled. In current GUI mode (viewer), we do not have a way to visualize the depth info which is not displayable. This diff is to address this problem.

It introduces a new class called SensorInfoVisualizer as a helper class, which provides and manages the framebuffer, renderbuffer, shaders that are necessary in the visualization.
It introduces a new shader class called DepthVisualizerShader that leverages the existing depth.vert and depth.frag to visualize the depth info.
It would work for regular depth sensor, and also the fisheye depth sensor (TODO).
Scalable: This framework can be easily extended to visualize the other sensor info other than the depth map.
In viewer, press key '7' to switch between rgb sensor and the depth sensor.
Regular RGB sensor:

Depth sensor in the same camera angle:

How Has This Been Tested

Types of changes

[ ] Docs change / refactoring / dependency upgrade
[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have completed my CLA (see CONTRIBUTING)
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Unrelated: it's interesting how @bigbike and @eundersander have almost the same avatar, what's the probability of that happening? :smile:

I feel like I already spent more time on the review here than it would take to implement a TextureVisualizer shader directly in magnum, so just in short -- this is how I think it should work:

Render everything the usual way into a framebuffer X, with depth unprojected to a texture from a depth buffer. Or render just the depth, because the color will get discarded anyway.
Draw a full-screen quad into the same framebuffer X, visualizing the depth using a color map, only color, with depth test disabled.

That way you:

end up with a framebuffer that has the depth visualized but also the depth correct, which satisfies your point about "interaction",
don't need to do anything special with gl_FragDepth,
don't need a whole new Visualizer class with yet another color and depth framebuffer and all the scaffolding and documentation and testing around, as this is reusing what's already there,
don't need to conflate the depth unprojection shader with visualization (seriously, from a design perspective, it just doesn't make sense to conflate the two, it will only cause problems down the road),
and everything is much more modular and easier to extend -- if, let's say, a semantic ID visualization needs to be done (and it can't be done with MeshVisualizer for some strange reason), it means rendering just another fullscreen triangle with another custom shader to the same color buffer, without the shader again having to take care of depth unprojection or writing to gl_FragDepth

Dear reviewers:
The diff is ready to be reviewed again. Code has been significantly refactored based on the reviewers' comments.
In this version the Magnum::ColorMap is adopted and the parameter is fine tuned.
See the results (depth sensor) as follows:

@mosra: This is diff is ready to be reviewed again.


removes generated manpages from devel

Please let us remove the noise of uncommitted files that
we always get when building in maintainer mode.

Does it work when building packages and such?
I have no doubt it will, but we should have a test run of that and manually verify that the manpages are generated and installed after the fix.

cmake/ArangoDBInstall.cmake +48
install(DIRECTORY ${PROJECT_SOURCE_DIR}/Documentation/man/
  DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/man)

Looks a bit fishy to me I would expect that the man target is a dependency of the installation step or that the files MAN_FILES are listed.

make install works on linux


Generate worker metadata.json at build time

💡 Feature request

Overview and problem statement
We use wrangler to build our project but not publish it. Since the metadata file is only generated at publish time, we are force to write it on our own.
Metadata generation was moved to the publish phase because of KV bindings.
Basic example
I suggest introducing a flag --write-metadata for the wrangler build command which will generate and write the metadata.json file.
This should throw if KV binbings are detected.

This should throw if KV bindings are detected.

Why? because of

Metadata generation was moved to the publish phase because of KV bindings.

? it was moved to the publish phase when we added kv bindings, but that was simply because the bindings were not used (by wrangler) at the build stage.

I don't exactly rememeber the issue with KV to be honest, but if you are sure there's isn't I'm fine.

I'm not quite sure why we would move this to the build stage - is this for debug purposes? We could add a log::debug that includes the constructed file content if that is the goal?

@EverlastingBugstopper

We use wrangler to build our project but not publish it

Is there a reason for building with wrangler and not publishing with it? Is there something that wrangler publish is not doing that it should be?

Is there a reason for building with wrangler and not publishing with it? Is there something that wrangler publish is not doing that it should be?

FPW

oh duh.. makes sense.

Is there a reason for building with wrangler and not publishing with it? Is there something that wrangler publish is not doing that it should be?

Even without FPW use case publishing with regular curl is much more flexible than wrangler publish a at the moment:

using API Tokens is not supported with wrangler
publishing script without specifying route
configure account ID, script name, API token through environment variables. It's much more flexible with TeamCity setup than dealing with multiple environments in .toml file.

Hi @sejoker! We are actively working on those for wrangler

API Token support will be available in the next release
I'm not quite sure what you mean by publishing a script without specifying a route, could you elaborate?
Wrangler will respect CF_ACCOUNT_ID, CF_NAME in the current release, and will respect CF_API_TOKEN in the next release (this is not documented, but should be added to the documentation by the end of November)

@EverlastingBugstopper re: 2 because upload and add route are different endpoints, you can actually upload a script to the workers config api without sending it to the edge by simply not calling the POST /route endpoint. wrangler just doesn't allow this. idk how much we want to push that, as generally we aren't in the business of just arbitrarily storing inactive scripts, but it's not as expensive so perhaps like a --draft flag would be helpful, idk.

That makes sense, I'm wondering what the use case for that is?

@EverlastingBugstopper one word: "migration". I have already deployed script (through UI) which runs on all requests: "example.com/*". API returns an error when I deploy new script against existing route. Maybe a flag --overrideExisting could address the need, but currently it's a blocker for me to use wrangler for deployments.

I believe we already had some discussion about a --force flag which could overide this kind of things.

@xtuc @sejoker if we implemented wrangler publish --draft (this seems semantically more appropriate than --force, which is rather general), is that preferred to this? This seems like a stop-gap proposal to get around the absence of the above features, but all are supported in the next release except the idea of a draft publish.

@sejoker that makes sense! For now, if you name the script the same as what's named in the dash, you won't get that pesky API error.

This issue is about generating the metadata at build time. Is this fixed in the next release?

@xtuc sorry this discussion got a bit derailed.
As for getting this in for this release, the team has not triaged this specific issue and likely won't before the end of this week. That being said we would more than welcome a community PR that addresses this!

@xtuc no. what i was asking was whether this issue is actually a thing you want, or if it is a counter-measure against other missing wrangler features. putting it behind a flag seems chill, but if the only reason it is happening is because wrangler isn't meeting your needs in ways that it could, i'd personally prefer to improve wrangler.
maybe we do both. idk. just wondering if you are asking for a lemon when you actually want a lime but don't think we have it to give 🙃

Regarding permanent improvements - I don't think that wrangler will support FPW until their deploy process changes, so this flag seems like a good stopgap.

If there's no issue moving back the metadata generation in the build command, that would be a permanent improvement that fixes this issue.
FPW support in wrangler, is another issue but we are slowly getting there. Maybe we could start a doc internally about current issues.

gonna keep all wrangler build milestone items open


Make Theme.of non-nullable

Note to reviewers: theme.dart contains the only interesting change. Everything else is mechanical removal of 280 !s.
Description
Make Theme.of non-nullable by removing the shadowThemeOnly param. That param has been replaced with InhertiedTheme.capture, see https://github.com/flutter/flutter/pull/69050.
Related Issues
Fixes #67163.
Tests
I added the following tests:
n/a
Checklist
Before you create this PR, confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I signed the CLA.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I updated/added relevant documentation (doc comments with ///).
[x] All existing and new tests are passing.
[x] The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Did any tests fail when you ran them? Please read Handling breaking changes.

[ ] No, no existing tests failed, so this is not a breaking change.
[x] Yes, this is a breaking change. If not, delete the remainder of this section.

[x] I wrote a design doc: https://flutter.dev/go/template https://docs.google.com/document/d/1LKBL0S1uyhACDiUXILhLKFZH8Cpl_w3mXjHgaE8_--U/edit?usp=sharing
[ ] I got input from the developer relations team, specifically from: Replace with the names of who gave advice
[ ] I wrote a migration guide: https://flutter.dev/go/breaking-changes-template Replace this with a link to a pull request that adds the migration guide to https://flutter.dev/docs/release/breaking-changes

"Google testing" failures are from an unrelated change.


Are units ordered?

Right now we have Eq and Ord instances for Dimensional, so we have one for Ord a => Unit d a.
Is this desirable or objectionable? AFAICS, the NIST guide doesn't say anything about it one way or the other.
(Asking because it isn't automatic in the land of named units.)

I don't feel strongly about it and don't have a solid use case. Perhaps for building a UI where you want may want your units sorted by magnitude. Something along the lines of:
units = [ (centi meter, "cm")
        , (meter, "m")
        , (kilo meter, "km")
        , (foot, "ft")
        ]

… populateMenu (sort units) …

(Which can surely be done much nicer with named units!)
But I'm not sure it is a realistic case and it could be worked around using something ugly like e.g.:
sortUnits = map (\(_,u,s) -> (u,s)) . sort . map (\(u,s) -> (1*~ u, u, s))

If it is causing trouble for you I suggest you limit the Ord instance to quantities. We can always add it back later if we change our mind, and it seems like a preferable to have the option of adding functionality if a need is demonstrated, rather than being forced to remove it later because it was a bad idea in the first place.

It doesn't cause any trouble, but I'm tempted to leave it out anyway for the reason you mentioned.
It also strikes me as against the "spirit" of the NIST guide, but I admit that is just a vague impression.

Let’s leave it out then!
On Wed, May 20, 2015 at 2:36 PM, Douglas McClean<EMAIL_ADDRESS>wrote:

It doesn't cause any trouble, but I'm tempted to leave it out anyway for the reason you mentioned.
It also strikes me as against the "spirit" of the NIST guide, but I admit that is just a vague impression.
Reply to this email directly or view it on GitHub:
https://github.com/bjornbm/dimensional-dk/issues/74#issuecomment-103866458


Bug: Cannot vagrant after cloning teracy-dev-entry

$ TERACY_DEV_ENTRY_LOCATION_GIT_REMOTE_ORIGIN=git@github.com:iorad/teracy-dev-entry.git \
>   TERACY_DEV_ENTRY_LOCATION_GIT_BRANCH=develop TERACY_DEV_ENTRY_LOCATION_SYNC=true \
>   vagrant status
[TeracyDev::Location::GitSynch][INFO]: cd F:/teracy/iorad-dev/lib/../workspace && git clone git@github.com:iorad/teracy-dev-entry.git teracy-dev-entry
F:/teracy/iorad-dev/lib/teracy-dev/location/git_synch.rb:93:in `block in sync'
Cloning into 'teracy-dev-entry'...
remote: Enumerating objects: 48, done.
remote: Counting objects: 100% (48/48), done.
remote: Compressing objects: 100% (34/34), done.
remote: Total 48 (delta 22), reused 39 (delta 13), pack-reused 0
Receiving objects: 100% (48/48), 8.06 KiB | 1.01 MiB/s, done.
Resolving deltas: 100% (22/22), done.
[TeracyDev::Location::GitSynch][INFO]: cd F:/teracy/iorad-dev/lib/../workspace/teracy-dev-entry && git checkout develop
F:/teracy/iorad-dev/lib/teracy-dev/location/git_synch.rb:98:in `block in sync'
Already on 'develop'
Your branch is up to date with 'origin/develop'.
[TeracyDev::Loader][INFO]: reloading...
F:/teracy/iorad-dev/lib/teracy-dev/loader.rb:130:in `sync_teracy_dev_entry'
[TeracyDev::Location::GitSynch][WARN]: `F:/teracy/iorad-dev/lib/..` has untracked changes, auto update is aborted!
 On branch develop
Your branch is up to date with 'origin/develop'.
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        dev-setup/
nothing added to commit but untracked files present (use "git add" to track)
F:/teracy/iorad-dev/lib/teracy-dev/location/git_synch.rb:71:in `block in sync'
[TeracyDev::Location::GitSynch][INFO]: cd F:/teracy/iorad-dev/lib/../extensions && git clone https://github.com/teracyhq-incubator/teracy-dev-certs.git
F:/teracy/iorad-dev/lib/teracy-dev/location/git_synch.rb:93:in `block in sync'
Cloning into 'teracy-dev-certs'...
remote: Enumerating objects: 63, done.
remote: Counting objects: 100% (63/63), done.
remote: Compressing objects: 100% (39/39), done.
remote: Total 63 (delta 22), reused 53 (delta 12), pack-reused 0
Unpacking objects: 100% (63/63), done.
[TeracyDev::Location::GitSynch][INFO]: cd F:/teracy/iorad-dev/lib/../extensions/teracy-dev-certs && git checkout develop
F:/teracy/iorad-dev/lib/teracy-dev/location/git_synch.rb:98:in `block in sync'
Already on 'develop'
Your branch is up to date with 'origin/develop'.
[TeracyDev::Location::GitSynch][INFO]: cd F:/teracy/iorad-dev/lib/../extensions && git clone git@github.com:iorad/teracy-dev-iorad-common.git
F:/teracy/iorad-dev/lib/teracy-dev/location/git_synch.rb:93:in `block in sync'
Cloning into 'teracy-dev-iorad-common'...
remote: Enumerating objects: 139, done.
remote: Counting objects: 100% (139/139), done.
remote: Compressing objects: 100% (82/82), done.
remote: Total 139 (delta 40), reused 131 (delta 33), pack-reused 0
Receiving objects: 100% (139/139), 30.62 KiB | 130.00 KiB/s, done.
Resolving deltas: 100% (40/40), done.
[TeracyDev::Location::GitSynch][INFO]: cd F:/teracy/iorad-dev/lib/../extensions/teracy-dev-iorad-common && git checkout develop
F:/teracy/iorad-dev/lib/teracy-dev/location/git_synch.rb:98:in `block in sync'
Already on 'develop'
Your branch is up to date with 'origin/develop'.
[TeracyDev::Plugin][INFO]: installing plugin: {"_id"=>"essential-0", "name"=>"vagrant-hostmanager", "version"=>"", "state"=>"installed", "config_key"=>"hostmanager", "enabled"=>true, "options"=>{"enabled"=>true, "manage_host"=>true, "manage_guest"=>true}, "sources"=>["https://rubygems.org/", "https://gems.hashicorp.com/"]}
F:/teracy/iorad-dev/lib/teracy-dev/plugin.rb:35:in `block in sync'
C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/win32/registry.rb:185:in `encode!': code converter not found (UTF-16LE to Windows-1258) (Encoding::ConverterNotFoundError)
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/win32/registry.rb:185:in `initialize'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/win32/registry.rb:250:in `exception'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/win32/registry.rb:250:in `raise'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/win32/registry.rb:250:in `check'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/win32/registry.rb:320:in `QueryValue'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/win32/registry.rb:644:in `read'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/win32/resolv.rb:67:in `read_s'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/win32/resolv.rb:101:in `block in get_info'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/win32/registry.rb:435:in `open'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/win32/registry.rb:542:in `open'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/win32/resolv.rb:91:in `get_info'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/win32/resolv.rb:21:in `get_resolv_info'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/resolv.rb:1002:in `default_config_hash'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/resolv.rb:1019:in `block in lazy_initialize'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/resolv.rb:1012:in `synchronize'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/resolv.rb:1012:in `lazy_initialize'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/resolv.rb:358:in `block in lazy_initialize'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/resolv.rb:356:in `synchronize'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/resolv.rb:356:in `lazy_initialize'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/resolv.rb:516:in `fetch_resource'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/resolv.rb:510:in `each_resource'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/resolv.rb:491:in `getresource'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/rubygems/remote_fetcher.rb:105:in `api_endpoint'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/rubygems/source.rb:47:in `api_uri'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/rubygems/source.rb:183:in `load_specs'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.0/gems/vagrant-2.2.0/lib/vagrant/bundler.rb:424:in `block in validate_configured_sources!'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/rubygems/source_list.rb:98:in `each'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/rubygems/source_list.rb:98:in `each_source'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.0/gems/vagrant-2.2.0/lib/vagrant/bundler.rb:422:in `validate_configured_sources!'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.0/gems/vagrant-2.2.0/lib/vagrant/bundler.rb:330:in `internal_install'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.0/gems/vagrant-2.2.0/lib/vagrant/bundler.rb:128:in `install'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.0/gems/vagrant-2.2.0/lib/vagrant/plugin/manager.rb:138:in `block in install_plugin'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.0/gems/vagrant-2.2.0/lib/vagrant/plugin/manager.rb:148:in `install_plugin'
        from F:/teracy/iorad-dev/lib/teracy-dev/plugin.rb:36:in `block in sync'
        from F:/teracy/iorad-dev/lib/teracy-dev/plugin.rb:16:in `each'
        from F:/teracy/iorad-dev/lib/teracy-dev/plugin.rb:16:in `sync'
        from F:/teracy/iorad-dev/extensions/teracy-dev-core/lib/teracy-dev-core/config/plugins.rb:17:in `configure'
        from F:/teracy/iorad-dev/lib/teracy-dev/config/manager.rb:40:in `block in configure'
        from F:/teracy/iorad-dev/lib/teracy-dev/config/manager.rb:38:in `each'
        from F:/teracy/iorad-dev/lib/teracy-dev/config/manager.rb:38:in `configure'
        from F:/teracy/iorad-dev/lib/teracy-dev/loader.rb:185:in `configure'
        from F:/teracy/iorad-dev/lib/teracy-dev/loader.rb:192:in `block in configure_vagrant'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.0/gems/vagrant-2.2.0/lib/vagrant/config/v2/loader.rb:37:in `load'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.0/gems/vagrant-2.2.0/lib/vagrant/config/loader.rb:126:in `block (2 levels) in load'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.0/gems/vagrant-2.2.0/lib/vagrant/config/loader.rb:119:in `each'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.0/gems/vagrant-2.2.0/lib/vagrant/config/loader.rb:119:in `block in load'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.0/gems/vagrant-2.2.0/lib/vagrant/config/loader.rb:116:in `each'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.0/gems/vagrant-2.2.0/lib/vagrant/config/loader.rb:116:in `load'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.0/gems/vagrant-2.2.0/lib/vagrant/vagrantfile.rb:29:in `initialize'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.0/gems/vagrant-2.2.0/lib/vagrant/environment.rb:793:in `new'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.0/gems/vagrant-2.2.0/lib/vagrant/environment.rb:793:in `vagrantfile'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.0/gems/vagrant-2.2.0/lib/vagrant/environment.rb:178:in `initialize'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.0/gems/vagrant-2.2.0/bin/vagrant:144:in `new'
        from C:/HashiCorp/Vagrant/embedded/gems/2.2.0/gems/vagrant-2.2.0/bin/vagrant:144:in `<main>'
Administrator@CBS85CFXNI4FWJ5 /cygdrive/f/teracy/iorad-dev
$```

maybe the latest version of vagrant (2.2.0) cause this, pls try the older one (2.1.2) to see if it is working:
https://releases.hashicorp.com/vagrant/
https://github.com/hashicorp/vagrant/issues/10303#issuecomment-431170734

Seem it is working with the downgrade, @hoavt can you confirm

$ vagrant status
[TeracyDev::Util][WARN]: The _id: '0' is deprecated, use the _id: 'kernel-core' instead for {"_id"=>"0", "location"=>{"git"=>{"remote"=>{"origin"=>"https://github.com/teracyhq-incubator/teracy-dev-core.git"}, "branch"=>"develop"}}, "require_version"=>">= 0.4.0-SNAPSHOT"}

[TeracyDev::Plugin][INFO]: installing plugin: {"_id"=>"essential-0", "name"=>"vagrant-hostmanager", "version"=>"", "state"=>"installed", "config_key"=>"hostmanager", "enabled"=>true, "options"=>{"enabled"=>true, "manage_host"=>true, "manage_guest"=>true}, "sources"=>["https://rubygems.org/", "https://gems.hashicorp.com/"]}

[TeracyDev::Plugin][INFO]: installing plugin: {"_id"=>"essential-0", "name"=>"vagrant-hostmanager", "version"=>"", "state"=>"installed", "config_key"=>"hostmanager", "enabled"=>true, "options"=>{"enabled"=>true, "manage_host"=>true, "manage_guest"=>true}, "sources"=>["https://rubygems.org/", "https://gems.hashicorp.com/"]}

C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/win32/registry.rb:185:in `encode!': code converter not found (UTF-16LE to Windows-1258) (Encoding::ConverterNotFoundError)
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/win32/registry.rb:185:in `initialize'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/win32/registry.rb:250:in `exception'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/win32/registry.rb:250:in `raise'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/win32/registry.rb:250:in `check'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/win32/registry.rb:320:in `QueryValue'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/win32/registry.rb:644:in `read'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/win32/resolv.rb:67:in `read_s'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/win32/resolv.rb:101:in `block in get_info'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/win32/registry.rb:435:in `open'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/win32/registry.rb:542:in `open'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/win32/resolv.rb:91:in `get_info'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/win32/resolv.rb:21:in `get_resolv_info'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/resolv.rb:1002:in `default_config_hash'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/resolv.rb:1019:in `block in lazy_initialize'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/resolv.rb:1012:in `synchronize'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/resolv.rb:1012:in `lazy_initialize'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/resolv.rb:358:in `block in lazy_initialize'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/resolv.rb:356:in `synchronize'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/resolv.rb:356:in `lazy_initialize'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/resolv.rb:516:in `fetch_resource'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/resolv.rb:510:in `each_resource'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/resolv.rb:491:in `getresource'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/rubygems/remote_fetcher.rb:105:in `api_endpoint'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/rubygems/source.rb:47:in `api_uri'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/rubygems/source.rb:183:in `load_specs'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.2/gems/vagrant-2.1.2/lib/vagrant/bundler.rb:360:in `block in validate_configured_sources!'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/rubygems/source_list.rb:98:in `each'
        from C:/HashiCorp/Vagrant/embedded/mingw64/lib/ruby/2.4.0/rubygems/source_list.rb:98:in `each_source'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.2/gems/vagrant-2.1.2/lib/vagrant/bundler.rb:358:in `validate_configured_sources!'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.2/gems/vagrant-2.1.2/lib/vagrant/bundler.rb:285:in `internal_install'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.2/gems/vagrant-2.1.2/lib/vagrant/bundler.rb:106:in `install'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.2/gems/vagrant-2.1.2/lib/vagrant/plugin/manager.rb:62:in `block in install_plugin'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.2/gems/vagrant-2.1.2/lib/vagrant/plugin/manager.rb:72:in `install_plugin'
        from F:/teracy/iorad-dev/lib/teracy-dev/plugin.rb:36:in `block in sync'
        from F:/teracy/iorad-dev/lib/teracy-dev/plugin.rb:16:in `each'
        from F:/teracy/iorad-dev/lib/teracy-dev/plugin.rb:16:in `sync'
        from F:/teracy/iorad-dev/extensions/teracy-dev-core/lib/teracy-dev-core/config/plugins.rb:17:in `configure'
        from F:/teracy/iorad-dev/lib/teracy-dev/config/manager.rb:40:in `block in configure'
        from F:/teracy/iorad-dev/lib/teracy-dev/config/manager.rb:38:in `each'
        from F:/teracy/iorad-dev/lib/teracy-dev/config/manager.rb:38:in `configure'
        from F:/teracy/iorad-dev/lib/teracy-dev/loader.rb:185:in `configure'
        from F:/teracy/iorad-dev/lib/teracy-dev/loader.rb:192:in `block in configure_vagrant'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.2/gems/vagrant-2.1.2/lib/vagrant/config/v2/loader.rb:37:in `load'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.2/gems/vagrant-2.1.2/lib/vagrant/config/loader.rb:126:in `block (2 levels) in load'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.2/gems/vagrant-2.1.2/lib/vagrant/config/loader.rb:119:in `each'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.2/gems/vagrant-2.1.2/lib/vagrant/config/loader.rb:119:in `block in load'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.2/gems/vagrant-2.1.2/lib/vagrant/config/loader.rb:116:in `each'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.2/gems/vagrant-2.1.2/lib/vagrant/config/loader.rb:116:in `load'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.2/gems/vagrant-2.1.2/lib/vagrant/vagrantfile.rb:28:in `initialize'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.2/gems/vagrant-2.1.2/lib/vagrant/environment.rb:777:in `new'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.2/gems/vagrant-2.1.2/lib/vagrant/environment.rb:777:in `vagrantfile'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.2/gems/vagrant-2.1.2/lib/vagrant/environment.rb:523:in `host'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.2/gems/vagrant-2.1.2/lib/vagrant/environment.rb:191:in `block in action_runner'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.2/gems/vagrant-2.1.2/lib/vagrant/action/runner.rb:33:in `run'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.2/gems/vagrant-2.1.2/lib/vagrant/environment.rb:510:in `hook'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.2/gems/vagrant-2.1.2/lib/vagrant/environment.rb:759:in `unload'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.2/gems/vagrant-2.1.2/bin/vagrant:164:in `ensure in <main>'
        from C:/HashiCorp/Vagrant/embedded/gems/2.1.2/gems/vagrant-2.1.2/bin/vagrant:164:in `<main>'

Administrator@CBS85CFXNI4FWJ5 /cygdrive/f/teracy/iorad-dev
$ vagrant --version
Vagrant 2.1.2

Administrator@CBS85CFXNI4FWJ5 /cygdrive/f/teracy/iorad-dev``

@datphan vagrant is still not working with vagrant 2.1.2

this bug maybe is only happen to win 7, and the solution is to set region to US:
Control Pane > Region >
> Location > Home Location > United States
> Administrative > Change system locale… > Chose English (United States) > Apply

so this is not really a bug to teracy-dev but vagrant, we need to update docs for this case.
assigned to @hoavt

phuonglm8:52 AM
99% la do system locale
￼￼￼￼￼
8:52 AM
restart xong check lại nhé
8:55 AM
http://maytinhadongjsc.com/1-thu-thuat-tin-tuc/135-huong-dan-khac-phuc-loi-utf-16le-to-windows-1258.html
phuonglm [9:01 AM]
cái doc của mình cũng nên ghi là chỉ support windows 7 SP1 x64 trở lên
SP1 còn chứ sao bỏ được nhỉ
ghi chung chung windows 7 8 10 user dùng bản 32 bit là bị lỗi


Avatar - Inconsistent default profile Avatar in Settings page

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Go to staging.new.expensify.com
Log in<EMAIL_ADDRESS>Go to Avatar>Settings page

Expected Result:
Avatar image should be the same as on main page
Actual Result:
Default profile Avatar is inconsistent in different pages.
When user navigates to Settings page - avatar logo lost original background
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[x] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[ ] MacOS / Chrome / Safari
[x] Windows / Chrome

Version Number: 1.3.79-3
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/78819774/37569c07-5f61-4bf4-a8b9-0df2cc73c43c
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
View all open jobs on GitHub

Cannot reproduce


Adding notes to annotation APIs

Codecov Report

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

@@            Coverage Diff            @@
##             master     #353   +/-   ##
=========================================
  Coverage     72.39%   72.39%
  Complexity     1195     1195
=========================================
  Files           131      131
  Lines          4484     4484
  Branches        459      459
=========================================
  Hits           3246     3246
  Misses         1029     1029
  Partials        209      209

Continue to review full report at Codecov.

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


Make srdash compatible with default build script

Signed-off-by: Peter Zhu<EMAIL_ADDRESS>Description
Make srdash compatible with default build script
Issues Resolved
https://github.com/opensearch-project/opensearch-build/issues/2649
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Should this also be changed in the template that generated the plugin?


Rename DevExpress.XAF.Packages namespace to Xpand.XAF

Repository is also renamed https://github.com/eXpandFramework/XAF

Closing issue for age. Feel free to reopen it at any time.
.Thank you for your contribution.


Add asynchronous mode

For sites with lots of people getting notified, we need to send notifications in a separate thread. I think this makes most sense in a cron one-off task, as combined with Cavalcade, this solves all our problems.

https://github.com/techcrunch/wp-async-task?

@BronsonQuick In this case, cron is the better option :)


Node Version Mismatch Error

Got this error message when hitting enter key after search for a snippet.

Did you download a copy or using a build?

I built it on my machine. Now I know it was because of the instruction I missed in the README about post install step. Anyways, I figured out an alternative before I saw that.

I'll close this after a pull request to automate this.

#4


Code for binary tree done

🛠 Issue (Number)

Issue no #92
👨💻 Changes proposed

✔ Check List (Check all the applicable boxes)

[✔ ] My code follows the code style of this project.
[ ✔] This PR does not contain plagiarized content.
[✔ ] The title of my pull request is a short description of the requested changes.

📄 Note to reviewers

📷 Screenshots

okay doing these changes right away

I am facing difficulty solving this issue code Factor is suggesting. Can the mentors help me out here

All SSoC'23 PRs will be accepted after 1st June 2023


doc(tutorials): Update prerequisites - make it more readable

Description
Minor changes - the commands are now displayed in separate code blocks -> easier to copy and execute step by step.

Pre-review checks
Please ensure to do as many of the following checks as possible, before asking for committer review:

[ ] DEPENDENCIES are up-to-date. Dash license tool. Committers can open IP issues for restricted libs.
[ ] Copyright and license header are present on all affected files

@JohannesARENA2036 i am a little bit confused. Didn't we already merge these changes with your pach4? Can we please sync again? Thx

@JohannesARENA2036 i merged main into your branch… what is left right now in the PR are the separate code snippets… it makes it easier to copy and execute them. THX

Only thing is left is dependencies check. The rest looks good to me

[ ] DEPENDENCIES are up-to-date. Dash license tool. Committers can open IP issues for restricted libs.

Only thing is left is dependencies check. The rest looks good to me

[x]  DEPENDENCIES are up-to-date. Dash license tool. Committers can open IP issues for restricted libs.

done


Progress report for COPY FROM

Use case
For potentially long running queries like COPY FROM it would be nice to have some indication about the progress.
Feature description
There is already sys.jobs and sys.operations which output information about active queries. They could be extended to show additional information.
A concrete first case would be COPY FROM where we could indicate how many lines were read & inserted already. Maybe also display some information regarding current memory use and bytes read.
Follow up
There could also be a way for a client like crash to figure out the job-id of the query it invoked, so that it could automatically display progress if appropriate.
(One way to do that might be to have some way in CrateDB to get an id per connection, and to query the job-id of a session using another connection. We'll need this id-per-connection concept for https://github.com/crate/crate/issues/11723 anyways)

One way to report progress could be through a NoticeResponse (see https://www.postgresql.org/docs/current/protocol-flow.html ) I suspect this is what is used when a RAISE WARNING occurs in PostgreSQL.
Similar to how progress on backup and restore operations is reported in MSSQL when using the STATS option, see screenshots on https://www.mssqltips.com/sqlservertip/2343/how-to-monitor-backup-and-restore-progress-in-sql-server/


aiven_pg: Properties in pg_user_config.pg are not Lifecycle Managed Correctly

Scenario 1
What happened?
If an aiven_pg Terraform resource pg_user_config.pg option is applied and then subsequently removed, a terraform plan shows no changes.
e.g.
Initial Configuration
resource "aiven_pg" "pg" {
  project      = data.aiven_project.pr1.project
  cloud_name   = "google-europe-west1"
  plan         = "startup-4"
  service_name = "my-pg1"
  pg_user_config {
    pg {
      log_min_duration_statement = -1
      bgwriter_delay             = 250
    }
  }
}

Updated Configuration
resource "aiven_pg" "pg" {
  project      = data.aiven_project.pr1.project
  cloud_name   = "google-europe-west1"
  plan         = "startup-4"
  service_name = "my-pg1"
  pg_user_config {
    pg {
      bgwriter_delay = 250
    }
  }
}

What did you expect to happen?
The terraform plan should show the removal of the option.
Scenario 2
What happened?
If a Postgres service pg advanced configuration option is configured within the Aiven UI but the option is not specified within the pg_user_config.pg block in an associated aiven_pg Terraform resource configuration, a terraform plan shows no changes.
What did you expect to happen?
The terraform plan should show the removal of the option.
What else do we need to know?
Aiven Terraform Provider version: 4.22.0

Hey, the API doesn't allow the removal of existing configurations—TF can only override them. So, there's not much we can do here. The UI also can't remove set options.

Thanks for the response @byashimov. Can I suggest that documentation is added to the resource property detailing this, and even better would be warnings from the provider when this scenario occurs.

Hey @rsalevsky, @staceysalamon-aiven! Please take a look at this 🙏


Flask test_client retaining lock on files, preventing os.remove() on Windows

Originally logged as https://github.com/pallets/flask/issues/2659. Moving here as the issue is believed to be with Werkzeug not Flask

Expected Behavior
Given the barest possible flask app (See this repo for full example: https://github.com/andymantell/flask-test-client-sendfile-lock)
from flask import Flask

app = Flask(__name__)

if __name__ == "__main__":
    app.run()

And the following test script:
import os
from app import app

test_client = app.test_client()

filename = 'static/test.txt'
with open(filename, 'w+') as file:
    file.write('Hello')

response = test_client.get('/static/test.txt')

response_data = response.data.decode('utf-8')
assert response_data == 'Hello'

os.remove(filename)  # This throws an exception on windows, claiming that the file is busy

I would expect that the file /static/test.txt will be created, requested from the test_client, and then removed again. And indeed this is what happens on Linux.
Actual Behavior
On Windows, the os.remove line throws an exception saying that the file is busy. It appears as if something inside the test client is locking the file.
If I switch to requests.get and fetch /static/test.txt over http instead of through the test client, the error does not occur, the file is not locked, and Windows successfully deletes the file.
(env) C:\projects\flask-test-client-sendfile-lock-master>python test.py
Traceback (most recent call last):
  File "test.py", line 15, in <module>
    os.remove(filename)  # This throws an exception on windows, claiming
 that the file is busy
PermissionError: [WinError 32] The process cannot access the file because it is
being used by another process: 'static/test.txt'

Environment

Windows 7
Python version: 3.4
Flask version: 0.12
Werkzeug version: 0.7

I have the exact same issue with my test cases.

I just had the same issue and I found that if I close my response then I can safely delete the file.
res = client.get(f"/binary/{self.mock_project_id}")
assert res.status_code == 200
res.close()

Apologies for the long delay. Just tried the above and it sorted the problem, thanks very much @bizzard4 :-)


Move simple classes to  API

Move RapidsShuffleHeartbeatHandler and messages
Move GpuKryoRegistrator

contributes to #6565
Signed-off-by: @gerashegalov

Is there any risk that the version of kryo is going to change with different versions of Spark so we would need to recompile?

Good question @revans2 . The risk is there but it is not affected by this move. sql-plugin-api is still compiled with all supported versions of spark and binary-dedupe will fail the build.
There is a caveat for CDH.
In sql-plugin-api  we don't have the same dependency overrides as in sql-plugi, which I noticed working on https://github.com/NVIDIA/spark-rapids/pull/9508/files#diff-460fedde0150cecb6b5fa0f3d743937742f1241d905019b57b4013703fe6b1a6R24
However, since we don't override kryo there. I double-checked the kryo dependency version is identical, 4.0.2` in dependency:tree for sql-plugin-api and sql-plugin across 321cdh,330cdh,332cdh

build


Richer R syntax definition by R-Box

This syntax in my Ikuyadeu/vscode-R#10 based on https://github.com/randy3k/R-Box.
But I think this syntax file should in this project.
Improve

Roxygen comments
Call function
Some buildin function

before

after

but making  new test is not yet, so i'll update test_r.json as soon as possible if need.

@Ikuyadeu How did you convert it? Manually, or is there a script? We can add that to our 'update-grammar' script

@aeschli First convert by script sublime-syntax(as yaml) to json, but some values(ex:push) are Manually. So script is not complete yet.

@aeschli Thank you for your review, I fixed.

Did you had a chance to look at a script?

@aeschli I just used this script
var inputfile = 'R.sublime-syntax',
outputfile = 'r.json',
yaml = require('yamljs'),
fs = require('fs'),
obj = yaml.load(inputfile);

fs.writeFileSync(outputfile, JSON.stringify(obj, null, 2));

And fixed manually.
I think better way is importing converted json from here by update-grammar.
It need just change r/package.json script url.

Thanks for the pointers.
I'm curious how the sublime  syntax to textMate works. I was under the impression that the difference are more than just semantics.

Thank you share your think, actually copy sublime syntax is difficult.
But https://github.com/textmate/r.tmbundle/blob/master/Syntaxes/R.plist is not updated in 5 years.
How is change https://github.com/Microsoft/vscode/blob/master/extensions/r/package.json#L7
to
"update-grammar": "node ../../build/npm/update-grammar.js textmate/vscode-r syntax/r.json ./syntaxes/r.tmLanguage.json"

or
"update-grammar": "node ../../build/npm/update-grammar.js lee-dohm/language-r grammars/r.cson ./syntaxes/r.tmLanguage.json"

I'm happy to switch to a better grammar. Important for us would be that

it is maintained
has an OS licence statement, preferably MIT

https://github.com/lee-dohm/language-r also is no longer maintained. But if it's the best option out there, I can switch to it.
Or are you are interested in hosting and maintaining the grammar? If so, set up a repo!

@aeschli Yes, I'll maintain my repository until RTVS team will create official extension.
But I'll update grammar only when https://github.com/randy3k/R-Box is updated or issue/PR is submitted here/mine.

@Ikuyadeu Great. What's the URL of the repo?

@aeschli Here is my repo's syntax file https://github.com/Ikuyadeu/vscode-R/blob/master/syntax/r.json.

Thanks @Ikuyadeu. It would be nice to have a separate repo just for the grammar, to signal that also other products can use it.
But for now it's fine, I'll update to it.

I switched to your repo: https://github.com/Microsoft/vscode/commit/012d7da5bcddc125e898fc35439ea1723c5bb9e4
Closing the PR, thanks @Ikuyadeu for your work!

@aeschli Thank you.

@aeschli Could you put about 012d7da in https://github.com/Microsoft/vscode-docs/blob/vnext/release-notes/v1_17.md#languages?
If you inform to users I can improve the syntax based on the user's issue.

@Ikuyadeu Done. (https://github.com/Microsoft/vscode-docs/commit/08a21220896deec3cc8008e2aeafb25e6b8c2c6e)

@aeschli Thank you for your prompt work!


Sara Trappetti profile update

Sara Trappetti profile update

Hi, I have updated my Ambassador profile when I made the pull request, it failed because the Enforce PR label check failed.
Is it something you will fix, or do I need to do something?


feat(ci): use dependabot to bump deps versions

i dont think using a dependabot is a good idea.
we might have supply chain attack issue.
it's very own security news.

Aha, it's indeed a potential risk. Maybe we can revert this commit.

agree


Access CI instance from routes callback function

I have a problem while using callbacks in routing. I need to access CI instance to load some contents and I can't do this. using load_class also doesn't help because these components aren't only libraries. I need cache driver and some models so it's not possible to access CI instance in route callback. Am I doing something wrong in my logic or does CI miss this future?
I have seen in other frameworks and most of them allows to access components from routing. Any optional variants I have?

Sorry, but we don't provide support via GitHub, unless you have a bug to report. Please ask your questions on the forums instead.


Reverse of a given string.

I would like to write a code to get the reverse of a given string in java, please assign this task for Hacktober fest,Thank you.

I want to write a code to get reverse of given string using c++ , Please assign this to me

Kindly Please assign me this issue.

Kindly Please assign me this issue.


Question about add replayui Creep Score

Hey, quick question. Why you not add reading creep score from replay ui?

first line is creep score value for random player in spectator mode

The testing I did showed that the values in the replay ui only updated when the ui is active, and since many tools hide the UI to add their own, this means that the values never update. At least this is what I observed.
Do the values always update for you? If yes, would you mind sharing what objects in memory you looked at to get the data and what your settings were in game?

You can use LiveEvents API to calculate the creepyscore.
Non neutral Minions: +1
SRU_MurkwolfMini: +1
SRU_Razorbeak: +2
SRU_Razorbeak "Mini": +0.4 (this is not exact if the player don't kill all the Minis)
SRU_Krug: +4
Other Minis: +4
SRU_Murkwolf: +2
Barrel: 0
Other Mini: 0
Rest: +1
This calculations are not exact, but later you can correct with InGame API when data is refreshed after search 10 untis on each player


I'm missing the slides from the workshop

There were reveal.js-slides on the #jenadevs workshop that I'd like to supplement

Finally! https://github.com/jenadevs/reveal.js/tree/meetup_1_practice


SelfSigned Issuer limits certificate duration to 90 days

Bugs should be filed for issues encountered whilst operating cert-manager.
You should first attempt to resolve your issues through the community support
channels, e.g. Slack, in order to rule out individual configuration errors.
Please provide as much detail as possible.

Describe the bug:
SelfSigned Issuer limits certificate duration to 90 days
Expected behaviour:
App developer should be able to get selfsigned certificates for longer periods of time
Steps to reproduce the bug:
Create a selfsigned issuer
Create a certificate with this issuer with a duratino longer than 90 days
Get a certificate valid only for 90 days.
Anything else we need to know?:
Environment details::

Kubernetes version (e.g. v1.10.2): 1.15.7
Cloud-provider/provisioner (e.g. GKE, kops AWS, etc): AKS
cert-manager version (e.g. v0.4.0): 0.12.0
Install method (e.g. helm or static manifests): static manifests with kubectl apply

/kind bug

This is infact works as expected.
Turns out I had a typo in my checks and using the old cert without duration set.

Happened to me today. Turns out I just deleted the Certificate object but not the Secret. 🤦🏻♂
I deleted both and re-apply the Certificate again. It worked and the validity is > 90 days as per the duration attribute set in my Certificate object.


Compatibility with Unity

As discussed previously, some of the color conversions have rendered the colore library incompatible.
Are we agreed that setting up a separate build specifically for Unity is the way forward?

Unless we want to completely remove conversion between different format and only support the regular, and encourage users to use the ColorMine library you mentioned?
Or is the usage of the implicit cast operators on Color too important to get rid of?

Sorry for chiming in uninvited, but would it be possible to use the uint representation internally and extract the whole color issue into a different project? That way one could write different access modules, one for WPF colors, one for unity colors, etc. I'd happy to join in, and help, if you want me to.

Problem with that is we can't have the nice cast operators we currently have (so you can pass in a System.Color to any Colore function accepting a Color struct and it will convert automatically).
Moving Color stuff to a separate project is a neat idea but then we may as well leave the conversion up to the users with a third party library like ColorMine since we can't use the cast operators which is the main drive for having it baked into Color.

It doesn't necessarily have to be another project, as long as there is a dll somewhere in there not depending on wpf or log4j or any other non .net-2.0 subset compatible assembly. In my fork, I replaced all occurences of Color and was done in like 2 hours, so it's not a lot of work to replace it with fixed uint values. The test cases wouldn't necessarily be affected, since the class would still exist, it just wouldn't be used that deep in the code.

Replacing Color with some new arbitrary object is not an option as it adds too much complexity and maintainability issues, not to mention the humongous refactoring problems it would introduce when something has to be changed.
Both Colore and log4net use .NET 3.5. Unity using a modified version of .NET 2.0 is a bit of an issue because of that sometimes but we can't sensibly drop support down to a .NET version that is over 10 years old as we probably use features that were only added in 3.5.
Other than PresentationCore not being available to Unity, I haven't heard any issues about log4net from the people currently using it in Unity, is there more information on this?

Well color does not need to be replaced, I was merely suggesting, using the uint that represents the color inside the Color object throughout the original library and adding a "compatibility-layer" (being the current Color object for all .NET-3.5 users) so the interface of the library doesn't change. Then switching to a unity compatible version would only necessitate another class that takes unity colors instead of the current color object. This could look something like the attached UML diagram. This would allow you to maintain a common core for both versions without much work.
Regarding the log4net issue, I have no idea, I just removed any dlls I didn't really need in order to find out what worked in Unity and what didn't. I got the stuff to work without it and just filed it as solved, that's why I mentioned it. Might be nonsensical.
colore-layered.pdf
.

The only problem unity has with Colore is with any references to wpfcolor as discussed a while ago.
Sent from my iPhone

On 19 Apr 2016, at 13:41, Christopher Guckes<EMAIL_ADDRESS>wrote:
Well color does not need to be replaced, I was merely suggesting, using the uint that represents the color inside the Color object throughout the original library and adding a "compatibility-layer" (being the current Color object for all .NET-3.5 users) so the interface of the library doesn't change. Then switching to a unity compatible version would only necessitate another class that takes unity colors instead of the current color object. This could look something like the attached UML diagram. This would allow you to maintain a common core for both versions without much work.
Regarding the log4net issue, I have no idea, I just removed any dlls I didn't really need in order to find out what worked in Unity and what didn't. I got the stuff to work without it and just filed it as solved, that's why I mentioned it. Might be nonsensical.
colore-layered.pdf
.
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

If I remeber correctly, System.Drawing caused problems as well.

@njbmartin: So you can confirm log4net works fine with Unity?

So, if developers are able to change the API level in Unity from the default, then only WPFColor prevents Colore from loading.
As @cguckes is suggesting, if it's set to the default... there are other issues.
Do we then cater to people using (forced to use) the default setting? In @cguckes case, it's a mod for Kerbal Space Program which is using the default API level.

forced to use

Are people unable to change the API level to something sensible like 3.5?
For games I suppose it makes sense, but we also can't drop Colore down to 2.0 which would be required in addition to remove other stuff, which means we have to drop everything that doesn't exist in 2.0. If we are using LINQ anywhere that is going out the window.

In the case of mods, developers are stuck with whatever the game developers set it to.

The fork I made works with .net2.0. So I don't see any problem there... As I said, all I did was replace the Color class...

@Sharparam You suggested a while ago having a 3rd build target specifically for Unity. I suggest we go ahead with that, and use the work @cguckes has done as the base for what changes need to be made.

@cguckes I've had a look at your fork. I don't recommend it a suitable solution for supporting Unity.
<Reference Include="UnityEngine">
      <HintPath>..\..\..\Games\SteamApps\steamapps\common\Kerbal Space Program\KSP_x64_Data\Managed\UnityEngine.dll</HintPath>
 </Reference>

This file path won't be the same for everyone, and is of course very specific to Kerbal.

Oh right, thats a remnant of me not knowing much about c#. Is there a way to locate the dll automatically? The Color class is the only one taken out of that dll, maybe there is another way to get it...

No it wouldn't be possible. In the case of mods, you'd have to target the specific version of the unity dll that the game is using too.
In any case, Colore should not be referencing Unity at all, and any conversion from Unity's color should be done within the game / mod itself, not the Colore library. Within Unity or the mod, you can have just done:
var color= new Corale.Colore.Core.Color(_unity._Color.R, _unity._Color.G, _unity._Color.B); after modifying the Color class to remove references to System.Drawing and WPFColor.

@njbmartin The third build target was when the only change needed was to drop WPF color support. If we have to support .NET 2.0 as well it would be thousands of pre-processor #ifs all over the place in addition to supporting an entirely different .NET level.
If Unity support requires .NET 2.0 then we can't just remove stuff to make Colore "compatible". If Colore still targets .NET 3.5 then it is by definition incompatible with .NET 2.0, that it happens to work with it with certain removals is just coincidence and nothing that can be relied upon or supported by us.

Yes I agree to that point, however we should still continue to support Unity as much as we can considering the value it has.
Unity is still very confused in terms of what framework they support.

Unity currently supports .NET 2.0/3.5 era functionality for both the C# compiler and the class libraries.

But it's still referred as 2.0 within Unity. The subset is a portable version of it, which further removes a number of classes to help keep the filesize down.

So, what's the plan with this?

Can we implement this into the next major release?

Discussing implementation in Slack.  For the record the options are:

#IF Guards against all  System.Windows.Media.Color and System.Drawing.Color references with a Unity build.  This would reduce overall readability of some classes (however this is minor).
Move the above references to their own projects.  This adds extra sprawl to Colore as a whole, as a new set of tests would be required, and NuGet configuration.

I have implemented the second option that @brandonscott noted above in the feature/separate-integrations branch. We can use that branch to see what usage would be like with the project separation method.

@njbmartin Have you checked in with any Unity devs on the above?

Sorry no i haven't. I will check it works with Unity later.

The idea is to make Colore available as an asset in the Unity Asset Store, making it super easy for developers to include in their Unity projects.
https://www.assetstore.unity3d.com/

I have a local clone of the repo. In it, I stripped System.Windows.Media.Color, System.Drawing.Color removed, and log4net (and linked it against UnityEngine.Debug.Log instead - which I would strip out for Release).
For work licensing reasons, I only have a licensed copy of Visual Studio 2012, so I also downgraded any C# 6 language features (all of it is due to lambda getters, null-conditional operator, and nameof() expressions) so it will compile in the older compiler in .NET Framework 3.5 which Unity requires. The final result is then usable in Unity.
If anything, I would highly recommend not using any C# 6 features in order to support older versions of Visual Studio.

Thanks for your input @Xinhuan. Much appreciated.
We definitely need to ensure Unity support, and it would be unwise to not provide support to Unity developers.
However, VS2012 is a little too old to support, and I would advise upgrading your licenses to at least 2013, if not 2015.

I think we'll be moving to extract WPF and WinForms functionality to two separate projects which can then be added via NuGet (so people that need WPF stuff can just add the package Colore.WPF or some-such in the future).
As for C# 6.0 features, usage of them will not affect the binary releases which are compatible with anything that supports .NET 3.5 and higher. There's also the free community version of Visual Studio which can be used to do develop work on Colore and I think there was some kind of "backport"-esque thing to bring Roslyn compilers to older versions of Visual Studio? Not sure about the last one and if it can be added without modifying the project.
log4net has earlier been reported as working with Unity so I don't see a reason to stripping that out and losing the logging functionality which would also gimp support as there won't be any data to analyze. log4net can be configured to output its logging data to any supported pipelines or custom ones so if integration with Unity's logging system is what is important that can be solved in the application itself.

Well, for the moment, I needed to manually recompile the dll in order to remove the non-Unity supported Color stuff, which necessitated removing C# 6.0 features.
The free community version of VS cannot be used for commercial purposes. Requiring developers to buy newer versions of VS, or jump through hoops to bring newer compiler support to older versions of VS is not what I call "providing support to Unity developers", the experience should be as hassle free as possible, and be supported as widely as possible. Requiring the latest compiler is the opposite, which is very narrow support.
The final release binary should also have all logging stripped out of being compiled. It is currently yet another hassle to have to download and include the log4net binary separately into a Unity game project, which is why I think it should not have logging included, or provide alternative builds without their use.

Thanks for your comments. Are you integrating Razer Chroma into a commercial product or game? If so, may I ask which?
If you'd prefer not to say publicly, feel free to email me<EMAIL_ADDRESS>We can then discuss your requirements.

As of right now, Colore is not supported in Unity projects outright. The aim is to bring back support for Unity, and that focus is on supporting Mono (.Net 3.5).
We previously had it compiling just fine for Unity, until we were made by a Unity dev that the new WPF color conversions prevented it from being loaded into Unity. The log4net does not cause any issues, and it is already included within the release binaries of Colore.
As for the VS2012 and C# 6.0, this should not affect you if you are using our release binaries (once we've merged and compiled the proposed changes for Unity support).
I'd suggest waiting until we have completed this task, and then you can simply download the release binaries without needing to compile them yourself and thus, no requirement for VS2012.
We'd love to see if that works for you. If it's not fit for your solution, then by all means continue with your own fork.

I am integrating Razer Chroma into this game:
https://www.kickstarter.com/projects/13978330/masquerada-songs-and-shadows/posts/1586656?cursor=13461657
Most of the integration is already done, so there should be little need for me to update or recompile Colore (though I may need to add support for CustomKey otherwise keybinds might not highlight properly on different keyboard layouts, not 100% sure yet - I am also uncertain if using CustomKey would break backwards compatibility with users who do not update their Chroma and device drivers). I am just providing feedback on my integration experiences so far to help future Unity developers.

Your feedback is greatly appreciated. Sorry it's been a little difficult getting Colore working with Unity and I can imagine the tight deadline too.

After the changes in #177 and #185, Colore is now compatible with all Unity versions, closing this issue as resolved.


bug: unable to select default model in v0.1.125 in mobile interface

Bug Report
Description
Bug Summary:
In a UI overhaul in v0.1.125, the "set default model" option is missing from the conversation page when the window is narrow enough or using in a mobile device.
Steps to Reproduce:

Update Open WebUI to v0.1.125
Open the service in a mobile browser or a narrow browser window (I "pin" the website as a PWA on my PC)
Start a conversation
Select a model
Noticing that you can't choose a model as a default one

Expected Behavior:
Users should be able to choose a default model under any circumstances.
Actual Behavior:
Users cannot choose the default model in mobile view.
Environment

Open WebUI Version: 0.1.125

Ollama (if applicable): 0.1.38

Operating System: Windows 10 22H2

Browser (if applicable): Vivaldi 6.7.3329.31 (Stable channel) (64-bit)

Reproduction Details
Confirmation:

[x] I have read and followed all the instructions provided in the README.md.
[x] I am on the latest version of both Open WebUI and Ollama.
[ ] I have included the browser console logs.
[ ] I have included the Docker container logs.

Logs and Screenshots
Browser Console Logs:
N/A
Docker Container Logs:
N/A
Screenshots (if applicable):

You can set default models in desktop view (wide-screen mode)

But the option is missing in mobile view (narrow-screen mode)

Installation Method
Docker
Additional Information
N/A
Note
If the bug report is incomplete or does not follow the provided instructions, it may not be addressed. Please ensure that you have followed the steps outlined in the README.md and troubleshooting.md documents, and provide all necessary information for us to reproduce and address the issue. Thank you!

It's been removed as a part of a UI redesign.


Update known_translations for contributor names and also fix a small issue in translate-contributors.py

What changes were proposed in this pull request?
This PR updates dev/create-release/known_translations to add more contributor name mapping. It also fixes a small issue in translate-contributors.py
How was this patch tested?
manually tested

Test build #70680 has started for PR 16423 at commit 9ce7ef8.

Test build #70680 has finished for PR 16423 at commit 9ce7ef8.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/70680/
Test PASSed.

Merged build finished. Test PASSed.

Thanks. Merging to master.

hi @yhuai, could you also:
add:
lw-lin - Liwei Lin

update:
sharkdtu - Xiaogang Tu
cenyuhai - Yuhai Ceng

Sure.


Technical documentation

i.e. usable README.md

it is not perfect, but for now there is a small documentation


Chore: Make integration tests required for merge

Description
Latest dep update pr auto-merged before integration tests finished.

Done.


assert(False) succeeds and some strange behaviour with ST

In the following code, assert(False) succeeds.
module Fail

val foo : unit -> ST unit
                     (requires (fun _ -> True))
                     (ensures  (fun _ r _  -> True))
let foo  () = ()

val test : unit -> unit
let test () = ()

(* val bar : unit -> unit *)
let bar () = let u = foo () in assert(False) //; test ()

There is also some additional strange behaviour:

Any reasonble explicit type I tried to give to bar caused the assertion to fail.
(except for something like val bar : u:unit{False} -> unit. However, if I use the option --log_types it prints the type
let bar : (_1_10:unit -> STATE (unit)))

If i add a function call to any other function (e.g., test), the assertion fails

assert(False) does not succeed in the body of foo, but without the call to foo assert(False) does not succed in bar

This seems to be specific to ST (and also ST2). If i give the same type to foo in Pure or Div the assertion fails.

Discovered that log_types ignores effect arguments, but you can print them with print_effect_args:
../../bin/fstar.exe bug289.fst --log_types --print_effect_args
val Bug289.foo : (unit -> St (unit) )
let foo : (unit -> St (unit) )
let bar : (_1_2:unit -> STATE (unit) (fun post h0 -> ((forall (a). (forall (h). (if True then (forall (a). (forall (h1). ((True /\ True) ==> (forall (x). ((False /\ True) ==> ((x == (_assert False ())) ==> ((~ (a == x)) \/ (~ (h == h1))))))))) else True \/ (post a h)))) /\ if True then (True /\ (forall (a). (forall (h1). ((True /\ True) ==> (False /\ (forall (x). (True ==> ((x == (_assert False ())) ==> True)))))))) else False)), (fun post h0 -> (forall (a). (forall (h). (if True then (forall (a). (forall (h1). ((True /\ True) ==> (forall (x). ((False /\ True) ==> ((x == (_assert False ())) ==> ((~ (a == x)) \/ (~ (h == h1))))))))) else True \/ (post a h))))))

This shows the wp F* is inferring for this ... hope it helps diagnose this better.

Discussed this with Nik today. This is expected behavior, perhaps not intuitive.
For all effects except ST, if the programmer does not write a val declaration, F* checks the inferred wp w.r.t. a default wp (see default effects in prims). This end up verifying the internal assertions of the function.
For ST, this is not the case, there is no default wp: the assertions are just added to the inferred wp and not verified (until the function is called), which is what's happening here.

If a val decl. is added for bar, F* tries to verify the internal assertion, and hence fails as expected.

'test' is in ALL effect. Calling test in bar makes the inferred type of bar to be in ALL, which means F* uses default ALL wp, and hence assertion fails.

foo has a val decl., hence assert(False) fails in foo. If call to foo is removed from bar, then bar is just in PURE, which means F* uses PURE default wp, and hence assertion fails.

This seems wrong. What's the reason for not providing a default for St as well?

Otherwise I would propose to reject all computations in St without an explicit annotation. Allowing them is simply unsound.

Here is an annotation one can give to bar without triggering the assertion failure:
val bar : unit -> STATE unit (fun (post:unit->heap->Type) _ -> False)
                             (fun (post:unit->heap->Type) _ -> False)
let bar () = let u = foo () in assert(False)

I find this disturbing.
(It's also strange that if I write _ instead of (post:...) this fails with Kinds "(_1_2:U6448 -> _1_4:(U6451 _1_2) -> Type)" and "((unit -> heap -> Type) -> heap -> Type)" are incompatible)

OK, nevermind my last comment. The type I wrote is equivalent to this:
val bar : unit -> ST unit (requires (fun _ -> False))
                          (ensures (fun _ _ _ -> False))

which is also accepted, but this is reasonable. The problem is when False is not an explicit precondition.

Why is the last example you gave strange, if you have False in context, anything goes. It has nothing to do with ST.
val foo: unit -> PURE unit (fun 'p -> False) (fun 'p -> False)
let foo _ = assert (False)
val bar: unit -> Lemma (requires False) (ensures True)
let bar _ = assert (False)

Tried adding a default for STATE just to see what would happen:
default effect XXX (a:Type) =
         STATE a (st_null_wp heap a) (st_null_wp heap a)

and it breaks 3 of our tests

examples/algorithms/counters.fst fails:

../../bin/fstar.exe  --admit_fsi Set ../../lib/set.fsi ../../lib/heap.fst ../../lib/list.fst ../../lib/string.fst ../../lib/st.fst counters.fst intsort.fst insertionsort.fst mergesort.fst
counters.fst(58,79-58,84): Subtyping check failed; expected type (unit -> InvST (int)); got type (_6_32:unit -> XXX (int))
counters.fst(73,41-73,46): Subtyping check failed; expected type (unit -> InvST (int)); got type (_6_50:unit -> XXX (int))
Error: 2 errors were reported (see above)

examples/security/acls2.fst fails:

../../bin/fstar.exe  --admit_fsi Set ../../lib/set.fsi ../../lib/heap.fst ../../lib/list.fst ../../lib/string.fst ../../lib/st.fst acls.fst acls2.fst
acls2.fst(93,10-93,16): pre-condition at acls2.fst(74,48-74,60)

examples/unit-tests/unit1.fst fails:

../../bin/fstar.exe  --admit_fsi Set ../../lib/set.fsi ../../lib/heap.fst ../../lib/list.fst ../../lib/string.fst ../../lib/st.fst ../../lib/int32.fst unit1.fst unit2.fst testset.fst short-circuit.fst
unit1.fst(382,8-382,19): Subtyping check failed; expected type (x:(ref int) -> ST (int)); got type (y:(ref int) -> ST (int))

as well as st2.fst, which fails all over even if adding a similar default to STATE2:

type st2_null_wp (heap:Type) (a:Type)
                 (p:STPost_h heap2 a) (h:heap2) =
     (forall (x:a) (h:heap2). p x h)
default effect XXX2 (a:Type) =
         STATE2 a (st2_null_wp heap a) (st2_null_wp heap a)

Both with or without XXX2 the errors are these:
../bin/fstar.exe st2.fst
st2.fst(53,0-53,33): post-condition at st2.fst(52,41-52,75)
st2.fst(62,0-62,43): post-condition at st2.fst(61,41-61,74)
st2.fst(72,0-72,35): post-condition at st2.fst(71,41-71,74)
st2.fst(82,0-82,35): post-condition at st2.fst(81,41-81,74)
st2.fst(92,0-92,35): post-condition at st2.fst(91,41-91,74)
st2.fst(102,0-102,35): post-condition at st2.fst(101,41-101,74)
st2.fst(112,0-112,35): post-condition at st2.fst(111,41-111,79)
st2.fst(122,0-122,35): post-condition at st2.fst(121,41-121,102)
st2.fst(135,0-135,67): post-condition at st2.fst(134,62-134,94)
st2.fst(206,0-206,66): post-condition at st2.fst(205,54-205,108)
st2.fst(304,0-307,37): post-condition at st2.fst(303,42-303,73)

I think the current choices of defaults are (mostly) justifiable.
First, recall that if a default effect is applied, the precise WP inferred for the program is lost. With that in mind, one should think to apply defaults as seldom as possible.
In the case of the PURE monad, the current default is Tot. The reasoning here is that if the Tot default succeeds, then there really is no loss in precision---the rest of the program can still reason about the Tot function via its definition.
The same reasoning applies for GHOST and GTot.
For the ALL effect, the default is ML. The reasoning here is that for compatibility with ML programs, if you're writing an ALL-effects function and you didn't annotate anything, then you probably want just the plain old ML type.
There is currently a default for EXN which is Ex, and DIV which is Dv. These are unjustified, IMO. I'd like to remove them.
There is no default for STATE.
Of course, if you want a default, you can always add your own default effect in your file, so long as a default is not already configured in Prims.

Closing this issue, since all the issues raised are explained. We could revisit the default definitions, at some point, if it becomes necessary.