net: please make it easy to get the destination address and port of a datagram received on an unconnected UDP socket

Hi,
In a UDP server running on a host with multiple addresses, it is necessary to use the address on which a request was received in order to send the reply.  This can be done either by binding a socket to each address of the local host, and monitoring the coming and going of addresses (which I find tedious and errorprone), or by using IP(V6)_PKTINFO in both recvmsg and sendmsg (which I prefer).
It looks like net.UDPConn does not expose the PKTINFO information.  Please?

What would the API for this look like?
Is there any reason this could not go into golang.org/x/net/{ipv4,ipv6}?  That would definitely be preferable if possible.

The net package aims to be a portable interface across many operating systems. What Go API would you propose and would it work on Windows, Solaris, Mac, Plan 9, etc?

would it work on Windows, Solaris, Mac, Plan 9, etc?

IPV6_PKTINFO is documented in RFC 3542, so it should in principle be
supported by any system that has IPv6 sockets.  IP_PKTINFO is
a traditional BSD interface, and should therefore be supported by any
implementation of sockets.  (I've just checked that MSDN documents both.)
I have no idea about Plan9 (which I'm told uses a Unixy interface instead
of BSD sockets).

What Go API would you propose

I'm sure you have better taste and more experience than I do.
One possibility would be to mimick the treatment of the oob parameter, and
have a *net.IP parameter that's filled in by Recvmsg, and used by Sendmsg.
That's simple and type-safe, but not extensible.
Another possibility would be to have a new API that selects desired cmsgs.
Then have the Recvmsg function return a map[string]interface{} with the
received cmsgs, and Sendmsg take a similar map.  (In which case the oob
parameter could be omitted, they're redundant with cmsg.)

Are ipv4.ControlMessage and ipv6.ControlMessage insufficient to manipulate ancillary information on each IP datagram?

@mikioh, I haven't tried, but I think I'd prefer something that's better integrated with net.UDPConn.  First, this is basic functionality, that is required by every single UDP server that wishes to support multihomed hosts, or even hosts with multiple addresses.  Second, using the ipv6 and ipv4 addresses for dual-protocol sockets feels clumsy to me.  (I'd love to be proved wrong — can you show me how to write a double-stack multihomed UDP server without excessive per-protocol special-casing?)

First, ...

I don't understand. Those are IP-level ancillary information and not specific to UDP. It's application's responsibility to choose and manipulate appropriate options.

Second, ...

I'd recommend that you take a look at each operating system's online manual. A transport protocol connection endpoint that can accommodate both IPv4 and IPv6 addresses by using a wildcard address with AF_INET6 is just for convenience of IPv4-IPv6 transition and the behavior is different between platform implementations. One accepts both IPv4 and IPv6-level options, some accepts only IPv6 options, and the others prohibit from creating such transport protocol over dual IP stack connection endpoints. In general, it's better to have two transport protocol connection endpoints that have two different address families if you want deterministic operations.
For more questions, please have a look at https://github.com/golang/go/wiki/Questions.

I don't understand. Those are IP-level ancillary information and not specific
to UDP.

Easy access to the received packet's destination address is a required
feature in order to write a UDP server.  It's not usually required for
writing a TCP server, where the transport layer sets the outgoing packet's
source address with no help from the application.

It's application's responsibility to choose and manipulate appropriate
options.

Yes.  And the networking library should make the common cases easy for the
application.  (Which, admittedly, the sockets API fails to do.)

I'd recommend that you take a look at each operating system's online manual.

[...]

For more questions, please have a look at
https://github.com/golang/go/wiki/Questions.

I cannot help but feel that I'm being patronised here.

feel that I'm being patronised here.

I may have given a misleading impression. That's just an answer to your question; can you show me how to write .... Sorry to cause you trouble due to my poor language ability.

Easy access to the received packet's destination address is a required feature in order to write a UDP server.

Accessing the source address of UDP datagram is already both possible and easy, using either net.UDPConn.ReadFrom or net.UDPConn.ReadFromUDP (both of which return the source address).
You can also get the source interface for advanced use-cases with ipv[46].ControlMessage from x/net:
udpConn, err := net.ListenUDP("udp4", addr)
pkConn := ipv4.NewPacketConn(udpConn)
pkConn.SetControlMessage(ipv4.FlagInterface, true)

_, cm, from, _ := pkConn.ReadFrom(nil)
log.Printf("got udp message from %v via interface %d", from, cm.IfIndex)

Easy access to the received packet's destination address is a required
feature in order to write a UDP server.

Accessing the source address of UDP datagram is already both possible and
easy, using either net.UDPConn.ReadFrom or net.UDPConn.ReadFromUDP (both of
which return the source address).

I know that.  The report is about the destination address of the
received packet.

You can also get the source interface for advanced use-cases with ipv
[46].ControlMessage from x/net:

I know that.  However, since this is required functionality for even
a basic UDP server, this is not an "advanced" used case -- it's required
functionality.
The (C-based) sockets API requires parsing a control message in order to
get the destination address.  This is a flaw of the sockets API, and Go
should not be repeating that particular mistake.
Please make it easy to get at the destination address and port of
a datagram received on an unconnected UDP socket.
-- Juliusz

Please make it easy to get at the destination address and port of
a datagram received on an unconnected UDP socket.

I'm not a networking expert, so that's the first line in this bug report that I fully understood.
Could we retitle the bug to something like that?
Looking at
https://golang.org/pkg/net/#UDPConn.ReadFromUDP
and
https://golang.org/pkg/net/#UDPConn.ReadMsgUDP
... both are kinda gross. I'd hate to add another gross one. I wish we would've used some extensible type instead where we could add a field or method to some existing type rather than adding new UDPConn methods with yet more complicated signatures. But it seems that's what we'd need to do here.
Brainstorming:
// UDPMessage is the input & output for a UDPConn.ReadUDP call etc etc write real docs.
type UDPMessage struct {
	Data     []byte // if non-nil, data to read
	OOB      []byte // if non-nil, OOB to read
	DataRead int // populated by UDPConn.ReadURP
	OOBRead  int // populated by UDPConn.ReadURP
	Flags    int // populated by UDPConn.ReadURP
	SrcAddr  *UDPAddr // if non-nil, UDPConn.ReadURP sets this
	DstAddr  *UDPAddr // if non-nil, UDPConn.ReadURP sets this
}

// ReadUDP reads a UDP message and populates m.
func (c *UDPConn) ReadUDP(m *UDPMessage) error { /* ... */ }

type UDPMessage struct {

Makes sense to me.

SrcAddr  *UDPAddr
DstAddr  *UDPAddr

Is there any reason why these are pointers rather than inline values?

func (c *UDPConn) ReadUDP(m UDPMessage) error { / ... */ }

The buffer pre-allocated by the caller, right?
What's the symmetric sending function, that picks the source address?

Is there any reason why these are pointers rather than inline values?

Yes, so the caller gets to decide whether getting either/both of those values is worth the cost to them. If they leave it nil, they can get more throughput if they don't care about, say, the destination address.

The buffer pre-allocated by the caller, right?

Yes, the []byte fields would be pre-allocated by the caller like the current two+ methods.

What's the symmetric sending function, that picks the source address?

https://golang.org/pkg/net/#DialUDP already lets you set the source address. Then you can reuse that conn to call https://golang.org/pkg/net/#UDPConn.WriteMsgUDP with different dst addresses.

What's the symmetric sending function, that picks the source address?

https://golang.org/pkg/net/#DialUDP already lets you set the source address.
Then you can reuse that conn to call
https://golang.org/pkg/net/#UDPConn.WriteMsgUDP with different dst
addresses.

That makes my socket into a connected socket, right?  Connected UDP
sockets have different semantics for a few things (notably receive
filtering and error handling), so I'm not sure that would work.
Even if DialUDP doesn't connect the socket (I'd have to look at the
source, I don't think it's documented), then using it makes things much
more messy.  If you have a symmetric SendUDP function, then a UDP server
looks something like (omitting error handling for the sake of brevity):
sock := ListenUDP()
for {
    r := ReadUDP(sock)
    data := process(sock.Data)
    s := UDPMessage{Data = data, SrcAddr = r.DstAddr, DstAddr = r.SrcAddr}
    SendUDP(sock, s)
}

On the other hand, if you need to call DialUDP, there's a jarring
asymmetry between the receive and the send side.
-- Juliusz

That makes my socket into a connected socket, right?

I have no clue what a connected vs unconnected UDP socket even means. It's just bytes on a wire, right?
I'll bow out of this bug and defer to @mikioh who speaks networking.

I have no clue what a connected vs unconnected UDP socket even means.

Two almost, but not quite, completely incompatible APIs to speak UDP using
the sockets API.  The connected API is easier to use, but the disconnected
API is more general.

It's just bytes on a wire, right?

The distinction is at the API level, the on-the-wire protocol is the same.

You realize we're not built on C, right? We're not constrained by libc's API choices.

You realize we're not built on C, right?  We're not constrained by
libc's API choices.

I'm reasonably sure that the connected/unconnected distinction is kernel-side
state.
-- Juliusz

Again, I defer to @mikioh or others who know networking details in depth.

On Linux we also have the IP_RECVORIGDSTADDR control message. I think that should probably be preferred over IP_PKTINFO when available, though I haven't exhaustively tested them. The former is not affected by e.g. local iptables rules, while the latter is. You need the former for certain types of proxying applications.

On Linux we also have the IP_RECVORIGDSTADDR control message. I think that
should probably be preferred over IP_PKTINFO when available,

I believe that they are different things, and that IP_PKTINFO is what is
needed here.

The OP still does not address @ianlancetaylor's question, which comes from https://golang.org/doc/faq#x_in_std.
I personally think it's fine to have a UDP-specific package in golang.org/x/net repository like #8328 because we now see https://tools.ietf.org/html/draft-touch-tsvwg-udp-options. But for adding something to the net package of standard library, still not sure whether it's worth vendoring control message and option parsers from a few packages in golang.org/x/net repository.

It seems like there's a definite lack here as far as API, but also a lack of consensus about what the new API should look like. Should we experiment with something new in x/net and maybe elevate to standard library once people are happy?

@mikioh @rsc Agreed, x/ seems like the right place to experiment with a better API.

Declining proposal; per discussion above, work in x/net for now and please submit a new proposal once the API is clear.


New version: ChrisKlimas.Twine version 2.8.0

Pull request has been created with WinGet Automation :rocket:
Microsoft Reviewers: Open in CodeFlow

Automatic Validation ended with:

Automatic Validation ended with:


android auth does not redirect back to app

See video below:
IMG_0277.MOV.zip

Did you register the redirect url in the Android manifest, in the Android directory?

Resolved this issue by using the proper redirect.html:
function getParameterByName(name) {
   var match = RegExp('[?&]' + name + '=([^&]*)').exec(window.location.search);
   return match && decodeURIComponent(match[1].replace(/\+/g, ' '));
 }

 var authResponse = getParameterByName('authResponse')
 window.location="myblockstackapp:" + authResponse


Add custom User model

Context
We need user login so we can support more than one consultation and also support upload.
Changes proposed in this pull request

create a separate app. because Django insists on a single core user model, auth will be a shared concern between the frontend and the admin, so pull out the bare bones and let each of those add metadata as appropriate in their own apps. (e.g. the admin side will probably use cognito)
generate dummy passwords as we'll use magic links
define a User model with inspiration from https://github.com/jmfederico/django-use-email-as-username
add tests

Guidance to review
Does the app split make sense?
How does the User model code look?
Link to JIRA ticket
https://technologyprogramme.atlassian.net/jira/software/projects/CON/boards/418?selectedIssue=CON-48
Things to check

[X] I have added any new ENV vars in all deployed environments and updated the .env.example and .env.test files in the repo

Thanks @nmenezes0, fixes shortly!


how to delete an app from itunes connect?

Question Checklist

[x] Updated fastlane to the latest version
[x] I read the Contribution Guidelines
[x] I read docs.fastlane.tools
[x] I searched for existing GitHub issues

Question Subject
spaceship
Question Description
The new version of iTunes Connect already supports removing apps, Any corresponding  API to  implement this function in fastlane?
like this:
app = Spaceship::Tunes::Application.find('xxx')
app.delete!

@MTBug Heyyy 👋  I was actually not aware that the new version of App Store Connect allow you to do this 😱 This does use the new API which we don't fully support yet but we should be able to add this in somehow. I will add this to my list 💪

@joshdholtz Good luck, Looking forward to your completion 💪

Note: you will not be able to re-use the same bundleID again though (as far as I know at present). You can resuse the released app name string, just not the bundleID. So for logically-minded folks who think a workflow like: app causing issues, wipe app, reinstall same app, carry on ... may help, it won't, not directly.


Emit stress test metrics in Fortio format.

This addresses the instrumentation aspect of #573 which is emitting performance metrics from E2E tests and saving them to a folder in JSON format compatible with Fortio.
By default stress test results are saved in build/.perf directory.

Is this on hold until we're happy with #573 ?

Is this on hold until we're happy with #573 ?

This is a small component of the solution, I'm hoping not a controversial one, unless we don't want to do Fortio at all.

@jkowalski Possibly we need to add a small description of make stress-test-e2e in a build/README.md file:
https://github.com/GoogleCloudPlatform/agones/blob/4ee2602c77bad8293d5dc8a86486ddd5c74fd844/build/README.md#L41
It is hard to guess the suitable cluster size needed to run test with STRESS_TEST_LEVEL=20
Currently only stress test levels <= 2 can be executed on default gcloud-test-cluster.


request size check

Hello Kevan,
Is there a ticket for this PR? Maybe attach it to one of the existing ones ?


Documentation: Clarify speed column in devtool chart

Do you want to request a feature or report a bug?
report a bug in the documentation

What is the current behavior?
Currently the documentation for devtool configuration is unclear to me, at least for the speed section. It seems like plusses mean that it runs faster. But maybe it means it takes more time? What does o mean? What does - mean?
What is the expected behavior?
It seems like one or more of the following would help:

a legend describing what the speed symbols mean
using different symbols (maybe "N/A" or "not applicable" if it is not applicable to that feature)

Crazy idea:

using a static gauge image of some sort to show the relative speeds for each section

Thanks!

Can you re-open this at the docs repo? Thanks.

Sounds good, sorry I put in the wrong place!
On Mar 22, 2017 3:01 PM, "Juho Vepsäläinen"<EMAIL_ADDRESS>wrote:

Can you re-open this at the docs repo
https://github.com/webpack/webpack.js.org/issues? Thanks.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/webpack/webpack/issues/4543#issuecomment-288505242,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADHsP81H6s0LI2Od_4klrsU_yd1tXW7ks5roXAdgaJpZM4Mlkjm
.


fix potential performance drop of URL operations introduced in #4310

Avoid map instance recreation.

Thanks @zhaixiaoxiang , I will merge it now.


Move configuration to  a resume folder, use YAML

This move the configuration presents in the source code directory src/ to a dedicated configuration folder  resume/ where we can store our résumé's related data, data.yml, and our profile-picture, id.jpg.
To enhance the readability of the former person.js file, it's now a "yaml" file data.yml.
In fact it's still a js one, but more or less yamlified for everyone's accessibility on their favorite editor.
To sum up:
This contains opinionated and breaking changes, the goal is to be more "beginner friendly"
Discussion is open before merging.

As you said, we need some discussion here.
I think your yaml-file has a better readability than the previous json-format.
But I'm not sure if that's worthful enough for the breaking change.

It is a breaking change but the .yml file is so much easier to read! So I would really like to merge this. Would you mind @j8r, to fix the conflicts?


Tracking issue: Opaque API

This issue provides a central place for questions and discussion around the Opaque API.
Please read the Opaque API announcement blog post (draft) first!
Before posting questions, please check if the Opaque API FAQ answers your question.
Release Plan / Status

[x] File this tracking issue
[x] Merge code changes into protobuf repository
[x] Update documentation on protobuf.dev
[x] Publish go.dev announcement blog post: https://go.dev/blog/protobuf-opaque
[x] Publish open2opaque migration tool: https://google.golang.org/open2opaque

Is there a proposal somewhere that took into account community feedback? I can't seem to find anything on the mailing lists, github or code review older than a week ago. It seems like we just went through a major API break in Go protobuf and we have yet another in just 4 years. There are still projects that are trying to migrate to the last set of big changes.
The departure of the gogo project was a net loss for the protobuf community after the 2020 change. It required a massive amount of work and testing to move to the new API with a lot of risk and very little benefit. Looking at the new motivations enumerated in the blog post, I wouldn't really put any of those concerns on even my top 10 problems when using protobuf and grpc. Even when I have encountered these problems, I was able to workaround the problem with an existing plugin, bespoke code generation or static analysis (rulesguard for the pointer compare is trivial).
Looking at the changes, its unclear why this can't be an alternative plugin, rather than a core breaking feature. At a minimum, it would seem prudent to release the Opaque API as an experimental plugin to get some feedback before considering it as a "default" in the 2024 edition. Getting some outside usage will make sure we won't have the same issues that occurred with the last API change.
I've been a long term advocate of Protobuf and GRPC for a number of projects. I've taken some criticism for that backing over the years due to the problems that has brought to projects, so it's going to be hard to continue that advocacy with yet another major change to such a foundational project. While I don't want to take away the engineering accomplishment made here, I would just hope to see some time for feedback to ensure this is the right direction.

Hey Stephen
Thank you for your message. I will try and address some of your points as best as I can, but note that I joined the project in 2022, and the Opaque API project was going on for much longer.

Is there a proposal somewhere that took into account community feedback? I can't seem to find anything on the mailing lists, github or code review older than a week ago.

There is no public proposal for this change, but we did involve the community (privately) as early as 2023 and again, in multiple feedback rounds, over the recent few weeks leading up to yesterday’s release.
Your name did not pop up when I compiled the list of folks to reach out to. If you would like to be included in the future, please let me know which company or organization you are speaking for and provide an e-mail address so we can reach out to you.

It seems like we just went through a major API break in Go protobuf and we have yet another in just 4 years.

No, this change is not a breaking API change. Your existing programs continue to work as before (nothing breaks), and the announcement clearly states that there is no obligation or expectation to migrate.
Even when the default API level changes with edition 2024, it is easy to stick to the Open Struct API by invoking protoc with the --go_opt=default_api_level=API_OPEN command-line flag (if that’s easy in your environment) or by setting the api_level editions feature option in your .proto file.

The departure of the gogo project was a net loss for the protobuf community after the 2020 change. It required a massive amount of work and testing to move to the new API with a lot of risk and very little benefit.

Just to be clear: the gogo/protobuf project was a community-driven project which was not coordinated with the Go Protobuf project.

At a minimum, it would seem prudent to release the Opaque API as an experimental plugin to get some feedback before considering it as a "default" in the 2024 edition.

We have already incorporated a lot of feedback over the last few years as we migrated Google’s Go codebase to the Opaque API. While the implementation can always be improved, the generated API itself seems pretty stable at this point.
If you have suggestions for specific changes, feel free to file them as a feature request in this issue tracker.
Thanks

I'd love to give feedback early if given the opportunity (and do reach out to me, I'm at Docker now) but I would feel better if the project could commit to public proposals in the future. Involving the community privately here is the problem. That is a very unwelcoming and un-inclusive model for change and its easy to cherry pick positive responses in such an environment. I understand why its easier to do some things in private but this project is used widely.
While its stated this is not a breaking change, if one does nothing and upgrades protoc and the go proto compiler, the generated code will be broken with the 2024 edition. I know its been tried internally at Google, but Google has a very different environment than most developers. The world that uses protobuf is not contained in a monorepo with automated refactoring and collisions in generated code between the Open and Opaque APIs may lead to problems and expensive changes.
A few problems I foresee:

Anyone exporting generated protobuf types will be forced to maintain the hybrid generated code. Those package maintainers can't stay on the Open API without creating problems for users of the new Opaque API and they can't move to Opaque without breaking their Open API users and matching stability expectations.
Controlling generation behavior in files can make portability difficult. Let's say that a rust project sets api_level to be Opaque and we need to use them in a project that is still using the Open API. One must pre-process the file to remove the setting before generating the code or be forced to update to the Opaque API.
Do the performance gains reference hold even when having to use a Builder+Opaque object in performance sensitive code?
The proposed names collide with already existing things. For example, "Open Struct API" used as "Open API" in several places, collides with "OpenAPI", which is a REST IDL. The "Opaque API" collides with an old term for unknown but carried message fields that people use to call "opaque fields" (which were broken sometime around the "syntax3" release).

I'll give the new Opaque API a try and get back to you if I discover more issues or if these aren't that big of a problem.

Just to be clear: the gogo/protobuf project was a community-driven project which was not coordinated with the Go Protobuf project.

No, it wasn't but the decisions of the Go Protobuf project effectively killed the vibrant community around that project. The Gogo project solved a number of problems that the main implementation ignored or didn't see as an issue. I hope that the attitude isn't that it is lesser because it was community-driven. Either way, it's important that this project take care not to create unintended consequences.
The specific changes I'm asking for are the following:

The Opaque API be marked as unstable or experimental until an appropriate feedback period has been completed. It will take time for downstream projects to digest the changes. This will let folks digest the changes and provide fixes before the impact becomes unfixable. You can set the timeline but make it public.
This be released as a separate plugin, ie --go_opaque_out, so that we can add it seamlessly to existing build steps and test it out separately.

I think these are reasonable actions that can be taken to create trust across the community and show folks that this can continue to be a strong, foundational dependency in their products.
Appreciate you hearing me out.

As a former maintainer, I can give some historical context (also as someone who's outside of Google now).
The protobuf reflection and opaque API both began around the same time around 2018. The opaque API was motivated by at least two reasons 1) better performance not using pointers to represent presence, and 2) better compliance with the protobuf language itself. Protobuf reflection was a prerequisite in order to pursue the opaque API because there was a lot of code that used Go reflection on protobuf messages and assumed that it was of a particular representation.
Another motivation for the protobuf reflection API was because Google consistently ran into panics due to Go reflection assuming that the protobuf message was produced by the golang/protobuf generator when it was actually produced by the gogo/protobuf generator, and vice-versa. Protobuf reflection is agnostic to the underlying generated representation.
A proposal for protobuf reflection was announced to the Go community back in 2018 and feedback was sought. Back then people had already raised concerns about gogo/protobuf and the intention was for gogo/protobuf to support protobuf reflection (in which case there would be no compatibility issues. Unfortunately, the maintainer of gogo/protobuf was unable to commit time to implement protobuf reflection. I offered to help, but when I started diving into the gogo/protobuf codebase, I realized that the great many features it supported allowed users to specify behavior that fundamentally went against the protobuf language and was therefore impossible to properly represent through protobuf reflection. Technically, it probably would have been possible to implement reflection for most features, but the large feature space of gogo/protobuf (while enjoyed by many users) was also its fatal Achilles' heel as it led to a very high maintenance burden.
(As an aside: Personally I think some of the gogo/protobuf features are reasonable. Philosophically, gogo/protobuf takes a stance of making generated Go protobufs great in Go, which is stance that many Go enthusiasts are happy with. However, the golang/protobuf project is a sub-project is part of the wider protobuf project, which has the goal of making protobufs decent in all languages, but not become overly-specialized to any particular language. Many requested features of golang/protobuf are rejected because of this philosophical difference.)
Going back to the opaque API, the intention was start the process to open source the opaque API after the release of protobuf reflection in 2020, which would have included a much more discussion and feedback about what it should eventually entail. However, due to internal company turmoil, I left Google not long after, which resulted in golang/protobuf staying somewhat at a stand still and the opaque API (which was already being massively used inside Google) to functionally become frozen as stable over the years. Thus, the fault of the opaque API not being more widely discussed ahead-of-time is my fault and not the present maintainers. In fact, they are the ones who have to deal with my sins, so I thank them for that.

Controlling generation behavior in files can make portability difficult. Let's say that a rust project sets api_level to be Opaque and we need to use them in a project that is still using the Open API.

I'm not sure I see this problem. The option is scoped to the Go language:
option features.(pb.go).api_level = API_OPAQUE;

@dsnet I'll respond in more detail but want to give you a quick answer. I think the point about rust was confusing but the classic problem with this was having generation ignore language-specific directives.
Let's assume the entire projects are in Go and is set to use the Open API:
option features.(pb.go).api_level = API_OPEN;

But, then, I have a dependency that has this:
option features.(pb.go).api_level = API_OPAQUE;

Now, one is required to adopt the opaque api if they want to use the dependency or write some dependency post-processing to remove or ignore the line.

[…] I would feel better if the project could commit to public proposals in the future.

I agree that working in the public as much as possible is best for Open Source projects in general, and that’s also what I aim for in general.
But I would also like to remark that in this particular case, it would not have made sense for me to create a public proposal. As Joe has already outlined, the Opaque API was already rolled out within Google, and rolling it back was concluded to be prohibitively expensive.
The only options I saw were “forever fork Go Protobuf inside/outside Google” (clearly not great for anyone) or “release the Opaque API as-is and improve from there”. We went with the latter. In other words: the community could (and did!) affect the “how”, but not the “if”.

While its stated this is not a breaking change, if one does nothing and upgrades protoc and the go proto compiler, the generated code will be broken with the 2024 edition.

Your description glosses over this (“with the 2024 edition”), so I want to stress again: If you do nothing and upgrade protoc and protoc-gen-go, your code will keep working.
If you migrate your .proto definitions to edition 2024 with prototiller, the file will be changed such that the old behavior remains.
Only if you actively signal that you want to opt into the new behavior (by selecting edition 2024 without any options that keep the old behavior), behavior will change. I think that’s reasonable.

Anyone exporting generated protobuf types will be forced to maintain the hybrid generated code. Those package maintainers can't stay on the Open API without creating problems for users of the new Opaque API and they can't move to Opaque without breaking their Open API users and matching stability expectations.

What sort of “problems” are you referring to here? Programs are free to work with .proto files on different API levels.

Do the performance gains reference hold even when having to use a Builder+Opaque object in performance sensitive code?

For performance-relevant code, we recommend you prefer Setters over Builders: https://protobuf.dev/reference/go/opaque-faq/#builders-faster and https://protobuf.dev/reference/go/opaque-faq/#builders-vs-setters

The proposed names collide with already existing things. For example, "Open Struct API" used as "Open API" in several places, collides with "OpenAPI", which is a REST IDL. The "Opaque API" collides with an old term for unknown but carried message fields that people use to call "opaque fields" (which were broken sometime around the "syntax3" release).

We tried to refer to the old API as “Open Struct API” throughout, but that realization came late in the process (based on external user feedback, actually). Can you let me know where you saw a reference (in prose, not code) to “Open API” please?

@dsnet Thanks for the context.  While I concede that gogo did have its share of design problems, it was stable and it gave a lot of protobuf users agency over generation, supporting many more plugins and capabilities. I am not sure the reflection API was worth the loss of that project nor do I think they had to be mutually exclusive. I hope we can look back on that situation and avoid repeating Go protobuf's part in that outcome.
@stapelberg

What sort of “problems” are you referring to here? Programs are free to work with .proto files on different API levels.
If I have a package that exports Open Struct API today, one cannot remove that and move to Opaque API without breaking downstream users of the package. One must stay on the "Hybrid" model. While protobuf itself may not break compatibility, it may introduce breaks in other packages and users that incidentally make these changes. Packages won't be "free to work with .proto files on different API levels". Project maintainers will be forced into enabling these APIs to satisfy downstream users.

The only options I saw were “forever fork Go Protobuf inside/outside Google” (clearly not great for anyone) or “release the Opaque API as-is and improve from there”. We went with the latter. In other words: the community could (and did!) affect the “how”, but not the “if”.
I suggested another option: release the Opaque API as a separate generator. The community has been doing this for a long time it is a tried and true technique in introducing alternatives. Introducing this as a separate generator will allow the community to evolve naturally and avoid unintended outcomes. It might be prudent to offer it as an option while leaving the rest of the changes in place.

Thank you for taking the time to hear me out. I hope you'll consider these suggestions carefully and thoughtfully. Like I said, I'll give this a try and get back to you.

What sort of “problems” are you referring to here? Programs are free to work with .proto files on different API levels.

If I have a package that exports Open Struct API today, one cannot remove that and move to Opaque API without breaking downstream users of the package. One must stay on the "Hybrid" model.

Yes, that’s correct.

While protobuf itself may not break compatibility, it may introduce breaks in other packages and users that incidentally make these changes.

I don’t understand what you mean by that. Can you rephrase please, or perhaps spell out an example?

The only options I saw were “forever fork Go Protobuf inside/outside Google” (clearly not great for anyone) or “release the Opaque API as-is and improve from there”. We went with the latter. In other words: the community could (and did!) affect the “how”, but not the “if”.

I suggested another option: release the Opaque API as a separate generator. The community has been doing this for a long time it is a tried and true technique in introducing alternatives. Introducing this as a separate generator will allow the community to evolve naturally and avoid unintended outcomes. It might be prudent to offer it as an option while leaving the rest of the changes in place.

I don’t understand what advantages you see in requiring users to use a separate generator name, especially at this point when the Opaque API has already been released.
Are you suggesting we un-release the Opaque API? That’s not going to happen.
Are you suggesting we change the configuration surface post-release? That’s not going to happen either.
The only kind of changes we can make at this point are additions, and adding a new generator name does not seem useful to me.
If we had any doubts regarding the stability of protoc-gen-go and wanted to keep the code separate, I think a separate generator binary would have been a good option. But that’s not the case: this code has been stable for years and has been released by now, thus far without causing any issues.

I will be out of office soon and will return to this conversation in January. Thank you for your feedback and happy holidays!

Transitioning a project outside the google ecosystem can uncover significant challenges. Engaging maintainers with large protobuf codebases can provide insights into potential issues during a controlled migration to new types. While the migration tool is valuable, it doesn't address dependencies outside a maintainer's control. Comprehensive documentation on the transition process can assist maintainers in overcoming these hurdles, though uncertainty persists.
A major concern is shifting from Open Struct to Opaque in widely used packages. For instance, the containerd API depends on Open Struct-generated protobufs. Switching entirely to Opaque could disrupt users and may necessitate maintaining a Hybrid mode indefinitely. Incrementing major versions for minor type changes may not be well-received. Additionally, maintainers adopting the Opaque API without Hybrid mode risk compatibility issues, placing significant responsibility on them. A separate generation plugin may be a good tool in easing this transition.
Since the Opaque API has been available for only about a week with no major migrations, it's premature to declare success. We've already encountered issues like golang/protobuf issue #1661. I don't advocate reverting to the previous API; the Opaque API has clear advantages. Instead, I suggest just slowing down the suggested adoption of Opaque generation configuration until its been vetted outside Google.
Currently, these usability challenges are the most significant barrier to protobuf adoption. When recommending protobufs, colleagues face various issues with protoc or Go generation and dependencies, making it harder to advocate for protobuf adoption in new projects. A shift in philosophy for this project to address these problems will go a long way.

Enjoy your time off! Merry christmas! 🎄

Hi, I noticed that scalar fields are not pointers in the builders when a syntax=proto3 file is compiled to Opaque API using the --go_out=default_api_level=API_OPAQUE. Is this non-pointer scalars in builders intended behavior for the long-term?

Hi, I noticed that scalar fields are not pointers in the builders when a syntax=proto3 file is compiled to Opaque API using the --go_out=default_api_level=API_OPAQUE. Is this non-pointer scalars in builders intended behavior for the long-term?

I believe the intention is that the builders would present (at least) a sort of gap-coverage from the open API to the opaque API, so it follows the same “scalar fields are default non-pointers” when the syntax is proto3. This then reduces the chances of an automated conversion needing to move from &pb.Message{ Field: 42 } to pb.Message_builder{ Field: proto.Int64(42) }.Build(), it can instead just move to pb.Message_builder{ Field: 42 }.Build().


BLUR filterType is listed twice on filter reference page

Actual Behaviour
On the filter() reference page, the filterType BLUR is listed twice under the Parameters section.
Steps to reproduce it

Navigate to https://p5js.org/reference/#/p5.Image/filter
Scroll down to information about Parameters
Note that the BLUR constant is listed twice

Screenshots of the issue

Would you like to work on the issue?
I can work on this!

Do go ahead and file a PR when you are ready. I'll assign the issue to you.

Do go ahead and file a PR when you are ready. I'll assign the issue to you.

It's already been fixed! https://github.com/processing/p5.js/pull/4863/files
It looks like this copy is being updated via the Grunt file (on this repo) by pulling from the documentation on the p5.js repo.
However, I think the website is pulling an outdated version (tag 1.1.9) as opposed to the most recent one (tag 1.2.0).

It's already been fixed! https://github.com/processing/p5.js/pull/4863/files
It looks like this copy is being updated via the Grunt file (on this repo) by pulling from the documentation on the p5.js repo.
However, I think the website is pulling an outdated version (tag 1.1.9) as opposed to the most recent one (tag 1.2.0).

Ah right, I'll manually update that since there was a deployment issue recently. Thanks still!

Ah right, I'll manually update that since there was a deployment issue recently. Thanks still!

@lmccart Actually there's something weird going on so I won't modify things for now, namely the package.json file still list the version as 1.1.9 while on NPM 1.2.0 is available. Is the version bump commit not pushed? Although the 1.2.0 tag is pushed. It's all a bit weird here so if you have an idea or a fix I'll let you do it instead.

@lmccart Actually there's something weird going on so I won't modify things for now, namely the package.json file still list the version as 1.1.9 while on NPM 1.2.0 is available. Is the version bump commit not pushed? Although the 1.2.0 tag is pushed. It's all a bit weird here so if you have an idea or a fix I'll let you do it instead.


Can be converted to specs

1. (libdiscord.h:78-239) audit log (and its inner objects)   (specs/wip/audit_log.json)
2. (libdiscord.h:368-379) channel::message::get_list()
3. (libdiscord.h:382-406) channel::message::create()
4. (libdiscord.h:409-420) channel::message::edit()
5. (discord-common.h:338-421) identify object (and its inner objects)

MISSING CHANNEL FUNCTION SPECS

https://discord.com/developers/docs/resources/channel#modify-channel
https://discord.com/developers/docs/resources/channel#get-reactions
https://discord.com/developers/docs/resources/channel#bulk-delete-messages
https://discord.com/developers/docs/resources/channel#edit-channel-permissions
https://discord.com/developers/docs/resources/channel#create-channel-invite
https://discord.com/developers/docs/resources/channel#follow-news-channel
https://discord.com/developers/docs/resources/channel#group-dm-add-recipient

MISSING EMOJI FUNCTION SPECS

https://discord.com/developers/docs/resources/emoji#create-guild-emoji
https://discord.com/developers/docs/resources/emoji#modify-guild-emoji

MISSING GUILD FUNCTION SPECS

https://discord.com/developers/docs/resources/guild#create-guild
https://discord.com/developers/docs/resources/guild#modify-guild
https://discord.com/developers/docs/resources/guild#create-guild-channel
https://discord.com/developers/docs/resources/guild#modify-guild-channel-positions
https://discord.com/developers/docs/resources/guild#add-guild-member
https://discord.com/developers/docs/resources/guild#modify-current-user-nick
https://discord.com/developers/docs/resources/guild#modify-guild-role-positions
https://discord.com/developers/docs/resources/guild#modify-guild-role
https://discord.com/developers/docs/resources/guild#get-guild-prune-count
https://discord.com/developers/docs/resources/guild#begin-guild-prune
https://discord.com/developers/docs/resources/guild#create-guild-integration
https://discord.com/developers/docs/resources/guild#modify-guild-integration

MISSING TEMPLATE FUNCTION SPECS

https://discord.com/developers/docs/resources/template#create-guild-from-template
https://discord.com/developers/docs/resources/template#create-guild-template
https://discord.com/developers/docs/resources/template#modify-guild-template

MISSING USER FUNCTION SPECS

https://discord.com/developers/docs/resources/user#modify-current-user
https://discord.com/developers/docs/resources/user#modify-current-user
https://discord.com/developers/docs/resources/user#create-group-dm

MISSING WEBHOOK FUNCTION SPECS

https://discord.com/developers/docs/resources/webhook#create-webhook
https://discord.com/developers/docs/resources/webhook#modify-webhook
https://discord.com/developers/docs/resources/webhook#execute-webhook
https://discord.com/developers/docs/resources/webhook#edit-webhook-message

MISSING CHANNEL FUNCTION SPECS

https://discord.com/developers/docs/resources/channel#modify-channel
https://discord.com/developers/docs/resources/channel#get-reactions
https://discord.com/developers/docs/resources/channel#bulk-delete-messages
https://discord.com/developers/docs/resources/channel#edit-channel-permissions
https://discord.com/developers/docs/resources/channel#create-channel-invite
https://discord.com/developers/docs/resources/channel#follow-news-channel
https://discord.com/developers/docs/resources/channel#group-dm-add-recipient

These are done

MISSING TEMPLATE FUNCTION SPECS

https://discord.com/developers/docs/resources/template#create-guild-from-template
https://discord.com/developers/docs/resources/template#create-guild-template
https://discord.com/developers/docs/resources/template#modify-guild-template

These are done.

MISSING EMOJI FUNCTION SPECS

https://discord.com/developers/docs/resources/emoji#create-guild-emoji
https://discord.com/developers/docs/resources/emoji#modify-guild-emoji

These are done

MISSING TEMPLATE FUNCTION SPECS

https://discord.com/developers/docs/resources/template#create-guild-from-template
https://discord.com/developers/docs/resources/template#create-guild-template
https://discord.com/developers/docs/resources/template#modify-guild-template

These are done.

MISSING USER FUNCTION SPECS

https://discord.com/developers/docs/resources/user#modify-current-user
https://discord.com/developers/docs/resources/user#modify-current-user
https://discord.com/developers/docs/resources/user#create-group-dm

Done

MISSING USER FUNCTION SPECS

https://discord.com/developers/docs/resources/user#modify-current-user
https://discord.com/developers/docs/resources/user#modify-current-user
https://discord.com/developers/docs/resources/user#create-group-dm

Done

MISSING WEBHOOK FUNCTION SPECS

https://discord.com/developers/docs/resources/webhook#create-webhook
https://discord.com/developers/docs/resources/webhook#modify-webhook
https://discord.com/developers/docs/resources/webhook#execute-webhook
https://discord.com/developers/docs/resources/webhook#edit-webhook-message

Done

Awesome, thank you very much.

We will implement these based on the needs.

Every datatype we could cover currently has been covered.


Faster implementation without bigint.

Since incrementing a (decimal) number leaves most of it unchanged, it's much faster to work on the decimal digits itself, instead of converting to binary and back.
It is of course very important add-one is fast and efficient, so we can call it repeatedly to increment more than one. ;)
Running the testcase on both the original bigint version, and this decimal implementation:
add_one_bigint  ... bench:       5,571 ns/iter (+/- 101)
add_one_decimal ... bench:       1,658 ns/iter (+/- 159)

The difference is much more dramatic for extremely large numbers (e.g. of several gigabytes).

This is really cool @m-ou-se, It's crazy how complex a simple "add-one" function can become when things are done right.
Thanks again !!

Ther is also @Kixunil that we need to add as a contributor by the way.

Haha. Not sure if I'd call over-complicating things 'right', but it's definitely fun to try to (over)optimize things like this. ;)


/list: All options are required in request, except recursive

You must specify all of the options to use the /list endpoint (except recursive, which has a default of 0). We should choose some strong defaults and make these into options.

This will not be implemented in this repository.
Please see the new HTTP API:
https://github.com/irods/irods_client_http_api


Fixes #2333 - added $versions operation

coverage: 94.296% (+0.001%) from 94.295% when pulling 6d57db0d6f9088ebcbc3f499314a1107d9a3f1fd on cody-fhir-versions into c02cf1ae8bb5931fd1a2d2a4482cab8e9d649502 on main.


The name of the helm chart in the rancher-stable repository contains a space, can therefore not be installed

What kind of request is this (question/bug/enhancement/feature request):
Steps to reproduce (least amount of steps as possible):
Result:
Other details that may be helpful:
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI):
Installation option (single install/HA):

Cluster information

Cluster type (Hosted/Infrastructure Provider/Custom/Imported):
Machine type (cloud/VM/metal) and specifications (CPU/memory):
Kubernetes version (use kubectl version):

(paste the output here)

Docker (use docker info):

(paste the output here)

wrong account


Fix scheduler failure on startup with MS SQL Server as backend

Dear Airflow maintainers,
Please accept this PR. I understand that it will not be reviewed until I have checked off all the steps below!
JIRA

https://issues.apache.org/jira/browse/AIRFLOW-1706

Description

Fix scheduler failure on startup with MS SQL Server as backend

Tests

Current tests cover this case

Commits

[ ] My commits all reference JIRA issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

Codecov Report

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

@@           Coverage Diff           @@
##           master    #2733   +/-   ##
=======================================
  Coverage   72.48%   72.48%
=======================================
  Files         154      154
  Lines       11843    11843
=======================================
  Hits         8584     8584
  Misses       3259     3259

Impacted Files
Coverage Δ

airflow/jobs.py
79.22% <ø> (ø)
:arrow_up:

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 b3c247d...57761fb. Read the comment docs.


fix: fully defines the define property for esbuild string replacement

Description
Fixes https://github.com/payloadcms/payload/issues/4060

[x] I have read and understand the CONTRIBUTING.md document in this repository.

Fully defines the define object for esbuild's string replacement.
Type of change

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

Checklist:

[ ] I have added tests that prove my fix is effective or that my feature works
[x] Existing test suite passes locally with my changes
[ ] I have made corresponding changes to the documentation

Fix will be in "@payloadcms/bundler-vite": "^0.1.5" after next release.


Audit Scanner fails completely with typo in policy

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
Using this policy (example from https://artifacthub.io/packages/kubewarden/verify-image-signatures/verify-image-signatures)
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: verify-image-signatures
spec:
  module: ghcr.io/kubewarden/policies/verify-image-signatures:v0.1.7
  rules:
  - apiGroups: ["", "apps", "batch"]
    apiVersions: ["v1"]
    resources: ["pods", "deployments", "statefulsets", "replicationcontrollers", "jobs", "cronjobs"]
    operations:
    - CREATE
    - UPDATE
  mutating: true
  settings:
    signatures:
    - image: "*"
      githubActions:
        owner: "kubewarden"
        repo: "app-example"

with kubewarden-controller-2.1.0 kubewarden-crds-1.5.1 kubewarden-defaults-2.0.3  ends up in audit-scanner failing fatal with the following
kubectl -n kubewarden logs audit-scanner-28655400-49zwv
{"level":"info","RunUID":"b87b30fc-5633-42c8-ab21-bf585d6826a6","time":"2024-06-25T14:00:01Z","message":"clusterwide resources scan started"}
{"level":"fatal","error":"no matches for apps/v1, Resource=pods","time":"2024-06-25T14:00:02Z","message":"Error on cmd.Execute()"}

Expected Behavior
Audit scanner must not fail completely if a policy is not perfect ok.
Steps To Reproduce
See above - more details here:https://github.com/Martin-Weiss/rancher-fleet/tree/bb68ca7288b42dcc7ddea27d5ffabde7fe241d22/kubewarden
Environment
rke2 1.28.10 x86_64 on linux

Anything else?
No response

Hi, there's several problems here.
The reproduced is misconfigured:

The policy module is an old tag v0.1.7, from 2022-08,  and this policy version is incompatible with the provided spec.settings.
The spec.rules is incorrect and ambiguous (how does k8s know that apiGroups
batch applies only to cronjobs and not pods for example?).

At first view, one could think that the reproducer was crafted from the
README.md example, but the rules don't match it.
The easiest solution is to use kwctl, which takes into account the metadata of the policy
to provide with a correct ClusterAdmissionPolicy, and craft from there. This is normally shown on artifacthub "install" button (but not for this policy as its latest release happened a while ago).
kwctl pull ghcr.io/kubewarden/policies/verify-image-signatures:v0.2.8
kwctl scaffold manifest -t ClusterAdmissionPolicy registry://ghcr.io/kubewarden/policies/cel-policy:v0.2.8

Solutions

Scaffold policy correctly.
[ ] Improve this policy's UX: Update its metadata.yml with more spec.rules, make new release.

Policy targeting nonexistent resources
The reproducer policy has wrong and ambiguous spec.rules. The policy would apply for example to apiGroups apps, apiVersion v1,  resource pods, which doesn't exist (apiGroups for Pods is the empty string).
A request for this specific GroupVersionKind would never come from the K8s API Server, but can coming from the audit-scanner, as we don't use the spec.rules until policy execution.
It would be good to validate the spec.rules ahead of time. Yet the policy spec.rules can't be validated on policy instantiation, as the GroupVersionKind resources available in the cluster can vary over time (with K8s upgrades, or CRDs for example). I will see if anything can be done in the audit-scanner.
Audit-scanner erroring and stopping when a specific policy has an error
If the audit-scanner sends a request to a policy that errors on execution (e.g: reproducer but with tag v0.2.8), we currently abort the audit-scan run. We do this for security reasons; this way misconfigured policies will not silently be ignored. We could improve this UX somehow.

Thanks a lot for the analysis and the feedback. Basically I believe that the error in the audit scanner leading to a full stop of the complete cluster scan is not a good practice. Admins might not even realize that the audit-scanner pod fails to run on the scheduled plan when they adjust any of the policies.
To address this I believe we need some sort of policy validation already in the policy server and we should see the policy server to fail starting. Also keep in mind that the audit scanner is an optional functionality that even might not be enabled.
In addition to that the logs in the audit scanner do not give any good indication on which policy it is failing and why..  so from a usability point of view I guess this should be changed - the audit scan should continue to scan all other stuff as well but the reports it creates should show where something is not ok..


customize session create method getting routing error

I am using devise and i have user table with admin field where admin value is tru if he login as admin.
i am login from home page by rendring new.html file from session view.
I customize session controller in  user controller
I really like to authenticate my devise user through 2 different interfaces with a view to have 2 different layout.
For example I would be able to use /users/sign_in and /admin/sign_in based on the same User model.
please hemp me.

routes.rb

devise_for :users, :controllers => {:sessions => 'devise/sessions', :registrations => 'devise/registrations'} do
get "/login", :to => "devise/sessions#new", :as => :login
get "/signup", :to => "devise/registrations#new", :as => :signup
get "/logout", :to => "devise/sessions#destroy", :as => :logout
match "users/create/:resource_name", :to => "users#create", :as => :session
match "/admin/index/:resource_name", :to => 'admin#index', :as => :admin
match "/home/index/:resource_name", :to  => 'home#index', :as => :user
end
root :to => "home#index"
resources :items
resources :regions
resources :categories
resources :items
end

User controller

class UsersController < Devise::SessionsController
prepend_before_filter :allow_params_authentication!, :only => :create
def view
@users = User.all
end
def create
resource = warden.authenticate!(auth_options)
set_flash_message(:notice, :signed_in) if is_navigational_format?
sign_in(resource_name, resource)
respond_with resource, :location => after_sign_in_path_for(resource)
end
def after_sign_in_path_for(resource)
if current_user.admin?
stored_location_for(resource) || admin_path
else
stored_location_for(resource) || user_path
end
end
protected
def auth_options
{ :scope => resource_name, :recall => "#{controller_path}#new" }
end
end

new.html.erb

<%= form_for(resource, :as => resource_name, :url => session_path(resource_name)) do |f| %>
  <%= f.label :email %>
  <%= f.email_field :email, :size => "20" %>
<%= f.label :password %>
  <%= f.password_field :password, :size => "20"%>
<% if devise_mapping.rememberable? -%>
<%= f.check_box :remember_me %> <%= f.label :remember_me %>
<% end -%>
<%= f.submit "Sign in" %>
<% end %>

error i am getting

rocessing by UsersController#create as HTML
Parameters: {"commit"=>"Sign in", "authenticity_token"=>"ax/xb5znIAvyVBMGCQa0i/rQWLXNKV0eKaf10ClF/Lo=", "utf8"=>"\342\234\223", "resource_name"=>"user", "user"=>{"remember_me"=>"0", "password"=>"[FILTERED]"<EMAIL_ADDRESS>User Load (0.2ms)  SELECT users.* FROM users WHERE users.email =<EMAIL_ADDRESS>LIMIT 1
Redirected to http://localhost:3000/index
Completed 302 Found in 184ms (ActiveRecord: 0.0ms)
Started GET "/index" for <IP_ADDRESS> at Wed Feb 15 19:03:32 +0530 2012
ActionController::RoutingError (No route matches [GET] "/index"):
actionpack (3.2.0.rc2) lib/action_dispatch/middleware/debug_exceptions.rb:21:in call'   actionpack (3.2.0.rc2) lib/action_dispatch/middleware/show_exceptions.rb:56:in call'
railties (3.2.0.rc2) lib/rails/rack/logger.rb:26:in call_app'   railties (3.2.0.rc2) lib/rails/rack/logger.rb:16:in call'
actionpack (3.2.0.rc2) lib/action_dispatch/middleware/request_id.rb:22:in call'   rack (1.4.0) lib/rack/methodoverride.rb:21:in call'
rack (1.4.0) lib/rack/runtime.rb:17:in call'   activesupport (3.2.0.rc2) lib/active_support/cache/strategy/local_cache.rb:72:in call'
rack (1.4.0) lib/rack/lock.rb:15:in call'   actionpack (3.2.0.rc2) lib/action_dispatch/middleware/static.rb:53:in call'
railties (3.2.0.rc2) lib/rails/engine.rb:479:in call'   rack (1.4.0) lib/rack/content_length.rb:14:in call'
railties (3.2.0.rc2) lib/rails/rack/log_tailer.rb:14:in call'   rack (1.4.0) lib/rack/handler/webrick.rb:59:in service'
/usr/lib/ruby/1.8/webrick/httpserver.rb:104:in service'   /usr/lib/ruby/1.8/webrick/httpserver.rb:65:in run'
/usr/lib/ruby/1.8/webrick/server.rb:173:in start_thread'   /usr/lib/ruby/1.8/webrick/server.rb:162:in start'
/usr/lib/ruby/1.8/webrick/server.rb:162:in start_thread'   /usr/lib/ruby/1.8/webrick/server.rb:95:in start'
/usr/lib/ruby/1.8/webrick/server.rb:92:in each'   /usr/lib/ruby/1.8/webrick/server.rb:92:in start'
/usr/lib/ruby/1.8/webrick/server.rb:23:in start'   /usr/lib/ruby/1.8/webrick/server.rb:82:in start'
rack (1.4.0) lib/rack/handler/webrick.rb:13:in run'   rack (1.4.0) lib/rack/server.rb:265:in start'
railties (3.2.0.rc2) lib/rails/commands/server.rb:70:in start'   railties (3.2.0.rc2) lib/rails/commands.rb:55   railties (3.2.0.rc2) lib/rails/commands.rb:50:in tap'
railties (3.2.0.rc2) lib/rails/commands.rb:50
script/rails:6:in `require'
script/rails:6
Rendered /usr/lib/ruby/gems/1.8/gems/actionpack-3.2.0.rc2/lib/action_dispatch/middleware/templates/rescues/routing_error.er

Please use the mailing list for questions or general help. If you think this is a Devise error, please isolate it by pushing an app that reproduces the error to github or a failing test, thanks.


BUG - wrong file breaks crawler process

Describe the bug
A file with wrong data can break all crawler process from a center. We need to provide a method to exclude certain files from being processed when we found they have a problem or are not right.
RT Ticket Number
Error on Jun 11th
To Reproduce
Steps to reproduce the behaviour:

Upload a file without header
It fails with following output:

2020-06-11 11:34:23,190 crawler.main    :101 INFO    ********************************************************************************
2020-06-11 11:34:23,190 crawler.main    :102 INFO    Processing xxxxx
2020-06-11 11:34:23,711 crawler.helpers :147 INFO    Downloading CSV files...
2020-06-11 11:34:27,618 crawler.helpers :268 INFO    Merging daily files of xxxxx
2020-06-11 11:34:27,619 crawler.helpers :272 INFO    59 files to merge into master file
2020-06-11 11:34:37,357 crawler.main    :139 ERROR   dict contains fields not in fieldnames:....
Traceback (most recent call last):
  File "/code/crawler/main.py", line 112, in run
    master_file_name = merge_daily_files(config, centre)
  File "/code/crawler/helpers.py", line 321, in merge_daily_files
    writer.writerow(row)
  File "/usr/local/lib/python3.8/csv.py", line 154, in writerow
    return self.writer.writerow(self._dict_to_list(rowdict))
  File "/usr/local/lib/python3.8/csv.py", line 149, in _dict_to_list
    raise ValueError("dict contains fields not in fieldnames: "
ValueError: dict contains fields not in .....
2020-06-11 11:34:38,633 crawler.main    :143 INFO    0 documents inserted
2020-06-11 11:34:38,634 crawler.main    :101 INFO    ********************************************************************************

Expected behaviour

File is ignored if it is set in a black list.
A wrong file is ignored from process, but does not break all load

Additional context
Add any other context about the problem here.

Check what has been received today in AssetAudits and if it hasnt created in Sequencescape because of Lighthouse trigger again the reception of labware.

Just for the record;
MK uploaded two plate map files for the same day on the 10th June to SFTP.
MK_sanger_report_200610_0001 – Misplaced header (is at row 512) , Missing data for RNA ID, RNA-PCR ID and just 525 samples.  Note hhmm timestamp what we typically see; ie 0001
MK_sanger_report_200610_2000 – Defacto standard file, ~25k samples however hhmm timestamp is unusual
Cristina A raising with MK. -


⚠ Bofrost.at has degraded performance

In c1f844b, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 881 ms

Resolved: Bofrost.at performance has improved in 194de24.


A typo

The process object is now no longer available, as the echoapp.exe process is no longer running.

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

ID: f5abd01e-3c7e-11a8-a6c6-62bfba0ef8b6
Version Independent ID: dceb81b3-b20f-91d1-85d0-fa68c762482b
Content: Debug Universal Drivers - Step-by-Step Lab (Echo Kernel Mode)
Content Source: windows-driver-docs-pr/debugger/debug-universal-drivers---step-by-step-lab--echo-kernel-mode-.md
Product: windows-hardware
GitHub Login: @DOMARS
Microsoft Alias: domars

Just that one tiny letter? Got it!!
Thanks for the Issue, @csujedihy
@DOMARS just FYI.

@EliotSeattle - Thanks!


fix(molecules): not reacting v-model in SfSelect

Related issue
fixes  #561
Scope of work

refactor how the component handle the data attribute index from watch + data to a computed property
add a knob in storybook to change the v-model value from 'outside the component '

Screenshots of visual changes
No visual changes
Checklist

[x] I followed composition rules for my component
[x] I tested the component in most common device sizes (can be tested in Storybook from viewport addon in top menu)

@przspa Assigning you for review since I think you worked on this code the most
@EduardDopler could you verify that my changes to the story do not hinder the automated docs creation?

@DonNicoJs There is just a minor naming thing which the docs-auto-generation relies on (it isn't strictly part of your changes, but a nice place to fix it 🙃)
All in all it works great though, take a look:

Maybe we should use a more meaningful errorMessage in the docs? Like "Please select a color" or sth.?
Also I noticed a warning in the browser console but I'm not sure whether it's just the stories or if the component always outputs them.
[Vue warn]: Avoid mutating a prop directly since the value will be overwritten whenever the parent component re-renders. Instead, use a data or computed property based on the prop's value. Prop being mutated: "selected"

@DonNicoJs it looks awesome, I totally forgot about this computed use case 🎉.
Can you move selected props to data, probably its most common use case :)
After @EduardDopler minor changes approved I can merge this PR.

@EduardDopler changes done! The warning is normal because to have the knobs working I need to have the component to actually change a prop which is illegal in vue but since is just a storbyook shenanigan is okay!
@pspaczek Changes done :) all good! Thanks for the review
Note for the future, maybe we should adopt a way that changes 'outside' the changed files in a PR should be addressed in a separate issue / PR. Recently I am working like this and it helps define boundaries, what I mean is that by looking at this PR you will not see that errorMessage label could be affected by this!
Clearly is something minor, but maybe we can have a conversation around it!

@DonNicoJs sure, we should try to check PR just for addressed Issue, but sometimes it's not easy. When you see some bug then you write about that. Probably we should create new issue for that and CR just addressed changes

Yes, you're right @DonNicoJs. I like to have PRs and commits address only specific scopes (that's also a reason why I'm not keen on squash commits…). For small changes I tend towards "just doing them" – without all the overhead of another issue and PR and merge.
I suggest to just ask the PR owner what he/she is in favor of. When he/she is fine with doing a small (e.g. one-line) change which is actually unrelated to the PR in the PR, then it's okay. Otherwise I will happily open a new issue.

@EduardDopler @pspaczek Yeah I agree that trivial change may not justify the overhead of a new issue / PR but on the other hand is about taking a direction and sticking to it, let's talk about it more on discord!
Thanks!


Support Comparisons with RegEx

Are there plans to support Comparisons with RegEx? Are PRs introducing this feature welcome?

Hi, @hugobessa !
Sorry for a delayed response, we've missed somehow.
Anyway, there were no plans to support RegEx. For me it's hard to imagine cases, when RegEx search is an optimal solution for an API filter, do you have some?
Also, I may be mistaken, but I think that various DB engines have different RegEx flavours, so it seems a hard task to solve generically.
Team @zzzevaka, @marcserrat, @ffaraoneim, what do you think?

@maxipavlovic you are right, regex syntax is DB dependent, it would be strange that an API consumer would know the DB engine behind the API. But for lib-rql perhaps it makes sense. What do you think?

I see your point @ffaraoneim. I like the idea of support for filtering by Python regex in Python part.

In theory, the __regex lookup on Django converts from Python regex to a format that the database understands. That's what the documentation says, at least

What I mean is that it would make sense for lib-rql but also for django-rql

Frankly speaking, personally I wouldn't want to expand this further than python version only, as we are also thinking of adding parsing to https://github.com/cloudblue/javascript-rql and regular expressions seem to be different in Python / JS, at least according to this and somehow they could affect grammar.
IMHO, LIKE functionality seems to cover most of the cases in Django-RQL.

@hugobessa CLA is now ready and automated :)


I suggest to change terms to improve consistency

Hi I think it's better if we use terms similar to each other in the code.
Instead of seconds, msecs, minutes, "sec", "msec", and "min" look better.
It's just my opinion. Thansk !

Agreed. Looks better. Thanks!


Webdash Calibre plugin

originally discussed in #57

I will start working on this plugin this week, just need to finish some outstanding issues in other plugins.

Let's get the basics out of the way:

I will use the CLI of course (as a node client), it looks really cool
I'll also give you feedback on the CLI (if any)
thanks of offering a chat! I think we can get away with just messaging on git

For v1, I'll focus on a read-only plugin (you can interact with calibre, see data, graphs, etc.. but cannot request a new snapshot for example).. if it ended up being used by people, I can then easily add write functionalities
@benschwarz what do you think?

I'm thinking that the plugin's dashboard would show something similar to this as the initial screne:

but also showing the Moto G number metrics:

and then you'll be able to drill down and see more info. For example, clicking on B score would show you the failing criteria from lighthouse.
Let me know what you think about this & if you think there's something we should also add to this

Btw Kudos for Calibre, I think it's a must have for any tech company!
Cheers

@jadjoubran I forgot to reply and give a 👍
Right now we don't have Lighthouse audit reports available from the CLI API, but that isn't too far off. You'd definitely be able to get a start with everything else though.

Alright sounds good 👍
yep that's more than enough to start


2 - Integrate As Legacy's Contextual Programming Code

 2 - Integrate As Legacy's Contextual Programming Code


Added optional feedback parameters.

ref #8 : it is now possible to add COMPLUS and PARAMPLUS feedback parameters

@GhaziTriki Hi, that looks interesting. Before I merge it, could you just explain a little bit about what this feature does, and an example of how it is used (we could then also add the example to the readme)?

Yes of course if you take a look here : http://www.barclaycard.co.uk/business/files/ePDQ_Advanced_Integration_Guide.pdf
In page 29 it says:
The merchant can send us two extra parameters in the hidden fields of the order form, in order to
retrieve them as feedback parameter after the payment. The following hidden fields are available:
<input type="hidden" name="COMPLUS" value="">
<input type="hidden" name="PARAMPLUS" value="">

More explanation is given in page 30
I have devoured the documentation and more pull requests are coming.

I will create another pull request with README update to explain how the library can be used it as it has some minor difference from the common Omnipay.

I have created a README udpate branch https://github.com/inhanx/omnipay-barclays-epdq/tree/readme-update
Once you merge this pull request I will update the README to explain additional parameters usage.

The explanation was added to readme update pull request. All pull requests are now ready to be merged. Can you please tag a new version after merging them all?


Add host prefix to NVCC_PREPEND_FLAGS when using conda-build

Adds the host requirements prefix include-paths and linking-search-paths to the NVCC_PREPEND_FLAGS for conda-build (because those two prefixes are separate) by using an activation script only when conda-build is active.
Outside of the conda-build context, these paths are not needed because nvcc would share a prefix with all the cuda libs.
I didn't do anything for Windows because it's skipped.

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Closes #18
Closes https://github.com/conda-forge/libcublas-feedstock/issues/11
Requires https://github.com/conda-forge/cuda-nvcc-impl-feedstock/pull/2

Thanks Daniel! 🙏
Had a question above 🙂

I don't think we should introduce new env variables into the mix. Better to use NVCC_PREPEND_FLAGS.

I tested this on a local build of the magma-feedstock. It seems to work, but silently. i.e. The args don't appear in the build logs.

The args don't appear in the build logs.

Maybe we should considering adding set -x at the top and set +x at the end (since it is sourced)?

This is the one, people. Let's get this patch out before the CUDA 12 migration is too far along. 😆

Thanks Daniel for the PR and everyone for reviewing! 🙏
Let's get this change out. We can follow up on anything else separately

I don't think we should introduce new env variables into the mix. Better to use NVCC_PREPEND_FLAGS.

I wanted to use a different env variable and inject into nvcc.profile so that CMake would be able to use these include and link directories as they would be in the INCLUDES and LIBRARIES output of nvcc ( https://gitlab.kitware.com/cmake/cmake/-/issues/24915 ). By using NVCC_PREPEND_FLAGS those directories will not be considered by CMake as that is a user flag and not part of the compiler implicit information.


AspNet core 2.2 sample multipart/formdata, application/www-form-url-encoded => 415 Unsupported Media Type

When testing the asp net core 2.2 pet store example I noticed that the examples that consume multipart/formdata and application/www-form-url-encoded don't work. The server returns  415 Unsupported Media Type. This is for both documents (swagger and openapi).
The example does work in AspNet core 2.1
Is this still something that needs work? Or is the sample not updated?
Thanks

This is a known "bug" in .Net Core 2.2. It's been fixed in 3.0 and might be fixed in a service release för 2.2
.Net Core GitHub issue

Did anyone ever figure out the reason for this? Did any of you do your initial migration, and check your model types? When i've gotten that in the past it's been due to an incompatible data type with the version or some invalid media type, same for Laravel 5.7 with the whole json/text type migration.
I think i've got it patched.


How can upper body and Lower body segmentation can be separated out?

Hi,
Thanks for sharing this amazing work. Would like to know, once I have generated the output results, how I can separate out the upper body and lower body clothes from the image and process these two individual object for further task? Also, is their a JSON file that is being generated as output specifying the object detected in the image?
Please help.
Thanks

By color.

Hi @karndeepsingh
For pretrained model download with inference script for Alpha Image generation and Cloth segmentation, please check this
https://github.com/wildoctopus/huggingface-cloth-segmentation
Have cleaned, modified the scripts to run on latest pytorch and other libraries and Its very simple to use as well.
The script will automatically download the pretrained model. So no worry at all.
You guys can also check the live demo at huggingface - https://huggingface.co/spaces/wildoctopus/cloth-segmentation
If you guys like this, please drop a star to my repo.
Thanks :)


Add Pattern35.js

Add Pattern35.js

Fixes Issue #45

@sushma1031 you can star this repo if you liked it.


chore: add hlx5 flag

:tada: This PR is included in version 6.38.1 :tada:
The release is available on:

GitHub release
v6.38.1

Your semantic-release bot :package::rocket:


The non-text contrast ratio of all 'Edit Label' borders is less than minimum required of 3:1 ratio.

Environment Details
Application Name: WPF in .NET4.8.1
Windows OS Build: Version 22H2(OS Build 25281.1000)
Visual Studio Enterprise 2022 - Target Framework - .NET Framework4.8.1
AT: Color Contrast
Prerequisite
To use the samples with Git, clone the WPF-Samples repository with or download zip file and extract https://github.com/microsoft/WPF-Samples/tree/net481-sdk
After cloning the WPF-Samples repository, please open the solution file, WPF-Samples.sln in the root directory.
To build the samples, open the solution file in Visual Studio 2022 and build the specific project you’re interested in. You can then right-click on the project file and select Debug -> Start new instance to run the application
Install color contrast analyser
Repro steps:
Launch Visual Studio 2022
Navigate to Sample applications and navigate to 'ExpenseltDemo' project.
Then right click on 'ExpenseltDemo' and then Click on Debug-->Set as startup project.
Click on “Start” button.
Navigate to Expenselt Standalone pane and observe color contrast of border for edit fields
Actual Result:

Color contrast of the non-text is less than minimum required of 3:1 ratio. The ratio of all the 'Edit field labels' border is 2.2:1.
Similar issue is observd for table border in 'create expense report' page

Expected Result:
Color contrast of the non-text should meet the required of 3:1 ratio.
User Impact:
Users with visual impairments will face difficulty if the non-text contrast ratio doesn't meet the minimum required ratio.

unsubscribe
At 2023-07-31 18:04:24, "Rishabh Chauhan" @.***> wrote:
Closed #455 as completed.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: @.***>


Add optional initial_selection to DOM.select.

Thanks for the PR! We’re probably going to deprecate DOM.select and related methods (see #31) in the near future in favor of HTML tagged template literals, so I don’t think it makes sense to add new functionality at this time.
For a static dropdown, I’d say:
html`<select>
  <option value="red">red</option>
  <option value="green" selected>green</option>
  <option value="blue">blue</option>
</select>`

For a data-driven one, something like:
colors = ["red", "green", "blue"]

html`<select>${colors.map(c => `
  <option value="${c}" ${c === "green" ? " selected" : ""}>${c}</option>`)}
</select>`


Unable to Filter to Tasks or Emails

I am using Windows 10 on a Surface. I am only able to filter to calendar only. There is no option to change the view from calendar to task or emails.

This is a limitation of the outlook view control which this app users, out of my control.


ng build --prod: duplicate hashes issue

Versions

Angular CLI: 1.6.8
Node: 8.9.4
OS: win32 x64
Angular: 5.2.9
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router

@angular/cdk: 5.2.4
@angular/cli: 1.6.8
@angular-devkit/build-optimizer: 0.0.42
@angular-devkit/core: 0.0.29
@angular-devkit/schematics: 0.0.52
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.9.8
@schematics/angular: 0.1.17
typescript: 2.6.1
webpack: 3.10.0

Repro steps

ng build --prod --build-optimizer=false --vendor-chunk

Observed behavior

and run previous command for instance 3 times, note the hashes:
> ng build --prod --build-optimizer=false --vendor-chunk

Node#moveTo was deprecated. Use Container#append.
Date: 2018-04-05T17:37:06.484Z
Hash: 6567769b926051187dab
Time: 57784ms
chunk {0} 0.016a9bf2be18abb170c1.chunk.js () 277 kB  [rendered]
chunk {1} main.e0d0b3bda5f04942944e.bundle.js (main) 2.94 MB [initial] [rendered]
chunk {2} polyfills.71070f1467b9cb77b8e5.bundle.js (polyfills) 98 kB [initial] [rendered]
chunk {3} styles.cd345cc5c6bcd7bb27a3.bundle.css (styles) 57.9 kB [initial] [rendered]
chunk {4} vendor.d630d3fc882739714918.bundle.js (vendor) 13.8 kB [initial] [rendered]
chunk {5} inline.527949f9a57d47da562e.bundle.js (inline) 1.49 kB [entry] [rendered]

> ng build --prod --build-optimizer=false --vendor-chunk

Node#moveTo was deprecated. Use Container#append.
Date: 2018-04-05T17:39:00.912Z
Hash: 45003e7908aa536afe88
Time: 65516ms
chunk {0} 0.016a9bf2be18abb170c1.chunk.js () 277 kB  [rendered]
chunk {1} main.9dc9feff3e3f630123f0.bundle.js (main) 2.94 MB [initial] [rendered]
chunk {2} polyfills.71070f1467b9cb77b8e5.bundle.js (polyfills) 98 kB [initial] [rendered]
chunk {3} styles.cd345cc5c6bcd7bb27a3.bundle.css (styles) 57.9 kB [initial] [rendered]
chunk {4} vendor.d630d3fc882739714918.bundle.js (vendor) 13.8 kB [initial] [rendered]
chunk {5} inline.052178568c89a21b8291.bundle.js (inline) 1.49 kB [entry] [rendered]

and the last one after done changes in styles files, vendor and polyfills files. also and for main file but it's regenerates each time
> ng build --prod --build-optimizer=false --vendor-chunk

Node#moveTo was deprecated. Use Container#append.
Date: 2018-04-05T17:55:53.295Z
Hash: 3d6edf77a1bf5bb2e071
Time: 55952ms
chunk {0} 0.016a9bf2be18abb170c1.chunk.js () 277 kB  [rendered]
chunk {1} main.b8a947f8ae3a97cc3727.bundle.js (main) 2.94 MB [initial] [rendered]
chunk {2} polyfills.71070f1467b9cb77b8e5.bundle.js (polyfills) 98 kB [initial] [rendered]
chunk {3} styles.cd345cc5c6bcd7bb27a3.bundle.css (styles) 57.9 kB [initial] [rendered]
chunk {4} vendor.d630d3fc882739714918.bundle.js (vendor) 13.8 kB [initial] [rendered]
chunk {5} inline.009d2384a8e227c15045.bundle.js (inline) 1.49 kB [entry] [rendered]

Desired behavior

I didn't understand what's the correct behavior in case of angular-cli to generate new hashes for every file or not but anyway they are regenerated by some obscure principle.
as you can see there is a very dangerous behavior. somehow angular-cli generates the same hashes for chunks, styles, vendor and polyfills files even if they are changed.
as for me the process of generating hashes must be under a user control (!)
I've spent a lot of time to parse generated files, I meant index.html and inline.js in purpose for cache during deployment process.
at least in the end, a user should get different hashes.

@angular-cli guys, it's a meter of time to fix such an issue and I can make the fix on my own but I need to be sure in what direction I should start. sure it can be a workaround or a small quick fix but I'm really not sure that's enough

I really don't get what you are doing here. If you haven't done any major changes to the code, it is completely normal and expected that e.g. the vendor part (which is mostly Angular runtime you don't ever touch) does not change and therefore obviously doesn't change the hash.
If you think something is wrong, you would have to post some example source code of yours and show the changes you've made that you think should be enough to change the built chunks.
Also, is there any reason why you are disabling the build optimizer and enabling vendor chunks? It only makes the output unnecessarily big.

I really don't get what you are doing here. If you haven't done any major changes to the code, it is completely normal and expected that e.g. the vendor part (which is mostly Angular runtime you don't ever touch) does not change and therefore obviously doesn't change the hash.

I thought so too but seems that it's not or I missed something. of course, at first you think you made a mistake

If you think something is wrong, you would have to post some example source code of yours and show the changes you've made that you think should be enough to change the built chunks.

unfortunately I'm not able to provide the whole code as you are and I'm sure it's not needed.
if you were a little more careful, you could notice that between 2nd and 3rd run I've left a comment. I can describe only that I've tried not just to change amount of code but I made some significant changes that were supposed to affect the generation of a new hash. I also played with vendors' libraries versions but haven't succeed that's why I've created that issue in the end.

Also, is there any reason why you are disabling the build optimizer and enabling vendor chunks? It only makes the output unnecessarily big.

in the demonstration purposes of course. I don't mindlessly shoved parameters in all holes trying to solve the problem. vendor chunk can be easily disabled.

We are about to go to production with cli based build and during testing we experienced an issue (something like e is undefined of something when trying to load lazy module) that I think has something to do with compatibility between chunks.
For example let's say we have a main module and a lazy loaded admin module. We do many changes in the main module for the next release, but nothing gets changed inside admin module and hence the hash for it remains the same (it's content based?) and therefore it would be served from cache for any active user. @D2KX Do you know if compatibility between main module and admin module is guaranteed ?
Build output looks a bit suspicious:
Prod build:
Date: 2018-04-12T12:13:32.871Z
Hash: 4a60d15af5c6777a962c
Time: 60364ms
chunk {scripts} scripts.60b956f64c64b10e5d7c.bundle.js (scripts) 155 kB [initial] [rendered]
chunk {0} 0.952318620de0409b96cf.chunk.js (common) 12.9 kB  [rendered]
chunk {1} *1.5063733610933b17d5fb.chunk.js* () 2.44 MB  [rendered]
chunk {2} 2.937abbae3b5b3d2ca59e.chunk.js () 86.9 kB  [rendered]
chunk {3} *main.78fb6b7c23dcf8a3ff62.bundle.js* (main) 1.69 MB [initial] [rendered]
chunk {4} polyfills.297be5fbf101f3da2b5b.bundle.js (polyfills) 101 kB [initial] [rendered]
chunk {5} styles.1d6dd6ed35bc3e3bf314.bundle.css (styles) 534 kB [initial] [rendered]
chunk {6} inline.673c1130c6b55c08c682.bundle.js (inline) 1.45 kB [entry] [rendered]

Another build after adding a throw new Error('foo'); in a random file that is part of main main module, and is also referenced (just because of type, value is provided via DI) in chunk 1. It does not cause any API changes (so TS is happy), but could lead to runtime errors.
Date: 2018-04-12T12:14:54.016Z
Hash: 24c8871d4f449f326f3f
Time: 58144ms
chunk {scripts} scripts.60b956f64c64b10e5d7c.bundle.js (scripts) 155 kB [initial] [rendered]
chunk {0} 0.952318620de0409b96cf.chunk.js (common) 12.9 kB  [rendered]
chunk {1} *1.5063733610933b17d5fb.chunk.js* () 2.44 MB  [rendered]
chunk {2} 2.937abbae3b5b3d2ca59e.chunk.js () 86.9 kB  [rendered]
chunk {3} *main.aba7e6b51a728282ba32.bundle.js* (main) 1.69 MB [initial] [rendered]
chunk {4} polyfills.297be5fbf101f3da2b5b.bundle.js (polyfills) 101 kB [initial] [rendered]
chunk {5} styles.1d6dd6ed35bc3e3bf314.bundle.css (styles) 534 kB [initial] [rendered]
chunk {6} inline.673c1130c6b55c08c682.bundle.js (inline) 1.45 kB [entry] [rendered]

I have changed in file so many time and so many things even unique number not generating. can you help me how I can add timestamp in file name.
I am facing  lot a issues because of this.  I think I have same issue as I am using lazy load functionality.

I faced the issue during soft update of files in deployment process when a user mustn't see any old cached files and moreover none empty page.
due to I'm using a CDN service it's not a big deal to check not a name but a date.
maybe it's not applicable for you @krishnpatel1 but anyway.


access restrictions for projects/aplications

How to limit which cluster and namespaces plugin can get resources from?
Or does argo-cd limit it as projects/application permissions?

Hi, you have to restrict the RBAC permissions on the service account associcated with the argocd-repo-server


Strider (2014) has lighting / texture issues.

Capcom's Strider has some rendering issues, showing some areas in black. Running the game without DXVK shows similar glitches (with OpenGL, some effects aren't rendering at all).

Software information
Strider (2014) on Steam, all graphical settings apply.
System information

GPU: GTX970
Driver: Nvidia 396.24.02
Wine version: 3.10 Staging
DXVK version: 0.60

Apitrace file(s)

https://mega.nz/#!Op5kRIIQ!tTESNRe8EB8WztaO4culVZwWK4BaXMeBQadLm0AaWUQ

Log files

d3d11.log: StriderX64_r_d3d11.log
dxgi.log: StriderX64_r_dxgi.log

Can you point out what is wrong in your screenshot, or post a screenshot of what it should look like?

Sure, here is what it's supposed to look like on PC:

Here is the Let's Play this is from: https://www.youtube.com/watch?v=APSWtoOIG08&index=6&list=PLqUI_YQcw3DY7rfSq_-orAwH2CBNIeDIU

Here is a trace produced on Windows 10, with Direct3D: https://mega.nz/#!it4GCATC!3XnWl6Gps9vuIM80CSAGQP5sKqN9AAyhJXGWFUY-r2o
I tried replaying the trace and it looked fine, no glitches there.

Good news, I've managed to get the game to render without issues!
I've edited the game's config file in Steam/userdata/10042493/235210/local/vars_pc.cfg to change
video_multithreadedRendering to false.
Based on that, it seems that the original issue is related to a multi-threading issue, which now makes more sense.

First at all, thanks to the devs and community for this awesome effort!
In my case not work. I change de config in file, but the game reset in each start. If put only read file, same situation. If possible Multithreaded Rendering a feature to implement in dxvk? Thanks community! :)

Multithreaded Rendering is an in-game option, not a D3D11 feature.

Multithreaded Rendering is an in-game option, not a D3D11 feature.

I see, and this bug or problem, because happens? Driver(I have nvidia gtx1060) wine or wine-staging part?

Well, only I want to help well. I mean, if not report here... where is the best place to report this issue to help to find some solution. Is a very "silly" bug for a great game, that in all the rest work perfectly, even in the part of dxvk that give extraordinary support to run dx11 at superb performance. Thanks in advance.

Well, I try to play in proton only. Then now I think check in native wine-staging session and the workaround work well. Change de .cfg to false and Render Ok. I think this issue is for report in proton.
For the issue of the Multithreaded Rendering I don’t known where, any ideas?
Thanks again and apologizes for the mistake to report. Greetings.

I don't really understand that last comment. What are you trying to say?

It did seem like a game bug but as I said, take what I said with a grain of salt and please don't open additional issues about this before confirming it.

It did seem like a game bug but as I said, take what I said with a grain of salt and please don't open additional issues about this before confirming it.

Okay, I did not understand that it was a bug of the game itself. Rather a feature that fails to reproduce the same.


feat(get-all-groups): Add Client API to get all groups from Artifactory

[x] All tests passed. If this feature is not already covered by the tests, I added new tests.
[x] All static analysis checks passed.
[x] This pull request is on the dev branch.
[x] I used gofmt for formatting the code before submitting the pull request.

I have read the CLA Document and I hereby sign the CLA

HI @eyalbe4, I see all the tests are passing, what's the process for getting this merged and released?

Hey @eyalbe4, thanks for the suggestion, I've added the additional tests

Hey @eyalbe4 any chance of getting a re-review?


Update in-app-purchase to support packing via crosswalk-app-tools

Before the in-app-purchase was built via make_apk because long form permissions
(like com.android.vending.BILLING) cannot be added to crosswalk application
project via crosswalk-app-tools, but after the long form permisssions issue being
fixed, when we tried to build it via crosswalk-app-tools, it didn't work well.
Now we build a new apk via crosswalk-app-tools and upload this apk
to Google Play so this example can work well and does not depend on
the way of building apk.

LGTM, thank you for the patch!


nginx: support multidomain certificates

While I think I've understood CN should contains the FQDN, what about alternate subject ?
I can't get my multi wildcard certificate working with all subdomains I want to cover. Typically we have several levels, with few subdomains at each level. How to handle this ?
TIA

+1

@webattitude How can one generate such a certificate for testing, either using openssl or anything else.

I'm using right now Let's encrypt with kube lego, it's awesome.

@webattitude How do you reproduce this issue? Do you mean sub of subdomain like ..example.com or multiple top level domains? Eg. a.com and b.com in one cert?

@lihan every type you define can be secured with https, every level of subdomains.

@webattitude please check if the image quay.io/aledbf/nginx-ingress-controller:0.147 solves the issue

Ok thanks, I've just replaced the controller with yours, I'll check asap


docs: add a HISTORY file for tracking version changes

This PR renames the RocksDB HISTORY file to HISTORY_ROCKSDB.md and
adds a HISTORY file for tracking Speedb-specific changes.
The PR is made of two commits, the first one for the rename and the other one
for the creation of the file, in order to ease rebasing on future RocksDB versions
later on.

We would like to have all Speedb and Rocksdb changes in the same History file to preserve the convention and we will have the Release notes under the Releases section in Github.


hot reloading not functioning

any ideas why it is failing to hot reload?  Am required to refresh in order to update while working on your react-dnd chess tutorial, thanks :)
not sure if am doing something incorrectly but needed to add es6 and jsx regex to the loaders as well as a resolve key for the extensions for it to render properly.
*11.7.2015 - installed Node 4.x, still not working unfortunately.
Re-installed webpack-dev-server globally after the new node install and it's now working.

Having the same problem @Cryptolemming

Did not work for me at first. After installing Node 4 and the latest versions of node-gyp and npm hot module reloading works. Maybe my comment in this thread helps others: https://github.com/nodejs/node-gyp/issues/629#issuecomment-158742175

Hi, for me it does not work as well, even if I have installed Node 4. Can't reload content at all.

.., Sorry, have to rectify... For me, it does still not work. Sometimes hot code reloading works, sometimes not. Very strange...

What I noticed this is all about some bad settings/packages/versions in node. At work I normally installed boilerplate and it was working like a charm. At home I have problems. I need to reinstall completely my env ^^

Maybe this could help you: I hat the same issue. At work it worked like a charm, at home sometimes yes, sometimes no. Thus, it had to be any timing issue. I played around with some WebpackDevServer options. Try this:
...
new WebpackDevServer(webpack(config), {
  watchOptions: {
    aggregateTimeout: 300,
    poll: 300
  },
})
...

Now, webpack hot reloading works for me.
Tried it with node 4.2.2, npm 3.5.0, webpack 1.12.9, webpack-dev-server 1.14.0

I have experienced this issue. I tried @stevenpietzsch's solution and it seems working but no idea what I'm doing actually. Where the problem comes from is my concern now, any idea?

Yep @stevenpietzsch your addition worked for me as well. So my server.js now looks like:
new WebpackDevServer(webpack(config), {   publicPath: config.output.publicPath,   hot: true,   historyApiFallback: true,   watchOptions: {     aggregateTimeout: 300,     poll: 300   },

@stevenpietzsch   Yeah! It works! But there should not be a default configuration.

hi guys. Not sure if you guys are still experiencing this problem. The solution that works for me was to remove "hot: true" from the server.js.
The reason for this is you are already using webpack.HotModuleReplacementPlugin along with the React Hot Loader module. Dan gives a specific note within his wiki to not call out --hot. --hot is the same as hot: true for Inline Dev Server.
See: http://gaearon.github.io/react-hot-loader/getstarted/
Also: https://webpack.github.io/docs/webpack-dev-server.html#inline-mode-with-node-js-api

This is all very confusing. I tried @Prophet32j's recommendation and that got my app refreshing completely upon each update. I replaced 'hot: true' and tried what @stevenpietzsch suggested and now it updates only the specific component when it detects a change, checking every .3 seconds I assume?

I think, I found the solution for the problem. I found the clue here: https://webpack.github.io/docs/webpack-dev-server.html#working-with-editors-ides-supporting-safe-write
You should have a look at your IDE, in my case PHPStorm, and disable the safe mode. After that, hot reloading works like a charm, even without
hot: true,
watchOptions: {
  aggregateTimeout: 300,
  poll: 300
}

thanks @stevenpietzsch, I'll look into this but I'm just using sublime and running from my terminal... will let you know if I find any kind of safe mode though.

Closing as most of it is related to Webpack, and we can’t fix these issues here.

Not sure this is relevant, but leaving a note just in case: I had a strange and subtle hot-reloading bug due to a caps case issue. When my file path used the incorrect casing, everything still worked except for hot-reloading on that module. The app was working, but hot-reloading failed silently.
I changed the incorrect import Home from '../components/Home'; to the correct import Home from '../Components/Home'; ('C' -> 'c') and hot reloading worked again. Sneaky.
It looks like caps-case issues have bitten others in similar situations: https://github.com/gaearon/react-hot-boilerplate/issues/8


[Feature Request]: Styling the "Terms and conditions" and "Privacy policy" pages

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description
Hey @apu52 ,
I want to suggest this feature so as to improve the visual enhancement of the website.
I want to style the current "terms and condtions" & "privacy policy" pages so that they can match the color theme of the Website,
Currently,
the terms and condtions page look like this -

and privacy policy page look like this -

Use Case
As a user, When i tend to open the terms and condition or privacy policy page...for us, it should enhance the visuality of it..And that can happen only when these pages follows the same color theme as the website.
Benefits
No response
Add ScreenShots
No response
Priority
High
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[ ] I'm a VSOC'24 contributor
[X] I have starred the repository

@apu52

Hey @apu52 , Please assign me this issue

Hey @apu52 , Please assign me this issue

@aslams2020 u are assigned

@apu52