Proposal: Convert our static strings in errors to something else...

Problem:
Right now the daemon will return errors as plain text in the HTTP body. For
example:
$ docker stop qwe
results in:

HTTP/1.1 404 Not Found
Content-Type: text/plain; charset=utf-8
Date: Fri, 21 Nov 2014 19:24:28 GMT
Content-Length: 23

No such container: qwe

This makes it impossible for any kind of i18n support in the future. This
also encourages people to write very brittle code that searches the output,
and errors, for static English strings. For example, there are places in
the code where we search for "no such" and then make decisions based on the
absence or presence of that string. This is very brittle and error-prone
if someone decides to tweak the text of the messages.
Proposal:
For backwards compatibility we need keep the HTTP body as is.
However, we can add new HTTP headers to the response that will allow for
better error processing on the client
For example:
    X-Docker-Err: {"id":"NoContainerID","args":["123123123"]}

could be returned in the sample error case shown above - where "Msg-Err"
is a JSON encoding of the error. The error includes a unique ID (that can be
used for error message look-up), and a set of args (strings) that can be used
as %s/sprintf substitutions into that error message.
In subsequent versions of Docker, like v2, when can break compatibility,
we can move these headers into the HTTP body - e.g.:
    HTTP/1.1 404 Not Found
    Content-Type: text/plain; charset=utf-8
    Date: Fri, 21 Nov 2014 19:24:28 GMT
    Content-Length: xx

    {
    "id" : "NoContainerID",
    "args":["123123123"]
    }

In order for this to work, we need to make sure all errors that bubble
back to the HTTP daemon contain enough information to produce the correct
output on the HTTP response flows. To do this the JSONError struct has been
modified to include all information needed to encode the error.
JSONError now extends 'error', which means we can return it wherever
we currently 'error'. Hopefully, this should minimize the impact on the
code during the migration from 'error' to 'JSONError'. Ultimately, I think
all errors generated by the Docker code should be JSONError - however, we'll
still need to deal with non-JSONError's since non-Docker code will generate
those.
Stage 1:
During stage 1 we should just convert things over to use JSONError and
have just a static English look-up table. This will allow us to work on
the migration of the code to use JSONError and ensure we have the basic
error reporting infrastructure correct.
CLI support will initially consist of the DockerCli.call() method
looking for the new X-Docker-Err... HTTP headers and, if present,
generate 'JSONError's instead of 'error's. We can then convert any code
that prints static English to use our the new look-up methods.
Stage 2:
Convert the English look-up table to full-i18n support. We can either
develop our own or use an existing one like:
https://github.com/nicksnyder/go-i18n
Note we will eventually need this for non-error messages as well but we
can start with the error cases first. Actually, I'd prefer if the REST API
always returned JSON for all ops, when possible, but we can deal with
those later. I think dealing with the error cases with the current APIs
is easier and less intrusive.
Additional Things:
Looking at the go-i18n repo, it looks nice but what kind of bothers me
is how verbose the usage can be. For example:
    fmt.Println(T("person_greeting", map[string]interface{}{
    "Person": "Bob",
    }))

Having to create the 'map' seems like overkill. I'm not sure, but I think
you can rewrite it as:
fmt.Println(T("person_greeting", "Bob"))
and it will just grab the args in the order specified. Which is nice.
However, it assumes the order of the %s's will be the same in all languages.
Unless I missed it, it would be nice if you could specify the substitution
strings as {{.1}} (meaning the 1st arg).
For now I've pretty much ignored this part of the problem in the docs
and proof-of-concept code I wrote as I think its a secondary issue. An
important one, but secondary and we can work on that once we agree to
the high-level direction
This PR has the doc changes necessary for this and the basic code changes
needed for the infrastructure to support this.  I'm not 100% sure the code is
fully ready but before I went too much further I wanted to get the overall idea
reviewed.
To play with it use the "docker inspect" command as well as:
curl http://..../containers/foo/json
to see the new headers in action.
Signed-off-by: Doug Davis<EMAIL_ADDRESS>

@crosbymichael I haven't had a chance to ping you on irc to discuss this, so perhaps we can do it here. I view this PR as having a couple of key steps:
1 - find and remove all static strings so that we do some kind of look-up.  This can, initially, be limited to just the server but I think the most important thing is that we start the tedious process of finding those strings and putting in place something that will catch new ones that people try to add. So, I think forcing all errors to be Derrors and having a check in the http server code to catch non-derrors will set us up for whatever future message processing steps we want to take.  This first step can technically be done irrespective of what else we do because the main point is to find/replace static strings.
2 - determine the proper string look-up mechanism was want. Initially what we use in step 1 for this isn't really important as long as we can easily replace it with the "real" one we eventually decide on.  The hard part will already be done so this will be a minor coding change.
3 - decide if we want to add new http headers to the existing error flows to include the machine readable error info, or wait for the next major rev of the API.  This doesn't need to be decided on right now, we can decide if/when to do this once the other two steps are done.
So, for now, I'd like to see if we can get agreement on just the infrastructural change of getting rid of the static strings.  Thoughts?

@vieux can you help out here?  This looks like something that would be very valuable for consumers of the API.

I agree we should have machines readable errors.
Although, I don't think using the headers are such a good idea.
I think it should wait the API v2 where we will have something like.
{
  code:4242
  message: "no such container"
}

@vieux sure but in the current v1 timeframe we could still do the tedious task of removing the static strings for a lookup, right?  Also, when is API v2 supposed to happen?

A couple things to keep in mind:
JSONError already exists, and is (sometimes) used to wrap errors to include http status codes:
https://github.com/docker/docker/blob/master/utils/jsonmessage.go#L15
During streaming operations (pull/push, etc) we cannot write http headers to provide error context (nor change the http status) since the http response has already begun.  Extending JSONError to include i18n support should be possible, however, without breaking current clients.

@dkjer I just noticed that JSONError doesn't subclass Error - if it did then it would be a much less disruptive change because then all existing func signatures that have 'error' can still work as is.  Any reason not make JSONError an Error ?

I just opened #11731 to address the engine eating real go errors.  Once this is done it will make implementing this trivial ( atleast I think it will ).

@crosbymichael do you have a preference for whether we reuse JSONError or create a new DError type of thing?

@dkjer I merged Derrors into JSONError and created constants for the strings/IDs.
@crosbymichael I'd like to see if we can agree on the basic premise of this so that I can start to convert all of our hardcoded strings into messages look-ups, but do it in chunks and merge into 'master' as I go. Otherwise I'll be constantly re-basing my PR over and over.  Thoughts?

@crosbymichael been thinking about how to speed this along... what if, for 1.7, we tag this feature a "experimental" (as was suggested a while ago for new features)?  Then we can always change, or even remove, the new header easily but I can at least get started on the error message conversion process.

we tag this feature a "experimental"

+1 on introducing "experimental" features; I think it will give more freedom to introduce new features and having a bigger "testing" audience, without being "tied" to them (and no longer being able to change without breaking BC)
@duglin will this be something that can be enabled/disabled through a flag during the "experimental" phase? Or won't that make sense/possible? (Not looking in the code right now)

@thaJeztah we could enable/disable the new http header via a flag if we wanted but the code changes that have us use an error message look-up table vs hard-coded strings couldn't be (at least not w/o a lot of pain).

@duglin yes, I was expecting that; but (IIUC); the look-up table will only be used if a X-Docker-Err is present in the response?

@thaJeztah I've updated based on your comments - thanks.
Once we start down this path the look-up table will be used all the time because when we generate an error the code will be something likle:
i18n.NewError(i18n.NoContainerImageID, name)

And then at the point where we generate the HTTP response we'll need to convert this error structure (a JSONError) into the proper text string using the look-up table and putting that in the http response body - this keep us backwards compatible.  Then we can have the flag to decide if we want an HTTP header carrying the json encoding of the JSONError struct.

@duglin sounds good (well, anything to get rid of the literal string parsing, because that's really hacky :smile_cat:).

@duglin The feedback I have here is entirely related to the error format.

I suggest that we match the format used in the Docker Registry HTTP API V2. This format is fairly flexible and non-committal. It supports more than one error, as well. There is library code for it already (https://github.com/docker/distribution/blob/master/registry/api/v2/errors.go#L133) which can be moved to a more central location if we find it to be generally useful.
The header approach is okay, but this is really a job for content/accept headers. For the current case, where no Accept header is provided, the response can be in backwards compatible "text/plain". For cases where a JSON body is supported, the client can include an Accept header for the content format. The error response should match that Accept header with the body.
For every error, we have a code that maps to a descriptor table, with a message. The message is advisory but could be locked down every time that error is thrown. Given a golang/x/net/context.Context with a locale, we could map these error codes into a translation table, if required. We may want to follow this model in the engine. This would be a further stretch.

Sorry for the wall of text, but I hope this helps. Let me know if you're interested going in this direction and we could break out the non-api related error serialization code (ie Error, Errors`, etc.) into a library.

@stevvooe thanks for the comment. To your points:

the 'errors' structure looks fine. My only suggestion is that there be an option slice of strings that can be added to hold the substitution variables for the error message.
the header stuff I talk about was just a stop-gap solution for the current CLI/API to avoid breaking existing clients. Ideally this stuff should be in the body.  I'd prefer to do everything in json on the wire but that's more of a API v2 discussion.
I believe @crosbymichael has also been working on some code that touches on this space. I agree we should put this code into a common spot to be reused across the various Docker projects. I don't really have a preference for one over another.   @crosbymichael do you want to share what you have?

To be honest, right now I'm just eager to start the conversion from static strings to some kind of constant because that will be the most tedious task.  Once that's in place, swapping out the generation/serialization code is trivial in comparison.

@duglin Sounds like a decent plan.

the 'errors' structure looks fine. My only suggestion is that there be an option slice of strings that can be added to hold the substitution variables for the error message.

This is an excellent suggestion. Perhaps, we could add a ErrorCode.Format(a ...interface{}) error method that would take the message arguments when generating the error. Right now, we do allow the message to be overridden, which will make internationalization harder. This isn't as important for the distribution code base, but is critical for this use case.

the header stuff I talk about was just a stop-gap solution for the current CLI/API to avoid breaking existing clients. Ideally this stuff should be in the body. I'd prefer to do everything in json on the wire but that's more of a API v2 discussion.

I'm not sure if I explained the concept of using Accept headers well enough above, but it is expressly to deal with the backwards compatibility. Basically, clients declare the content type they accept. If the client doesn't express a preference, we fall back to the old text format.

I think it's hard to find organizations as aware of language barriers as Docker. I'm pretty sure if we sum the number of languages maintainers speak we can count at least 6. I18N should be important to us, but the reality is that it's really hard to do it right.
Error messages are only the tip of the iceberg, and probably the least important piece of a huge puzzle. Before people arrive to read an error message they probably need to learn how to use docker and how to use the command line client. That involves translating the whole documentation to other languages, as well as the command line messages. The work doesn't end when a translation is incorporated, every new release requires translating new documentation that we might have added and making sure that outdated documentation is also properly corrected. I18n is a huge undertaking.
People that use docker needs to get used to using the command line, and they need interact with the operating system. Unfortunately, there is a terrible lack of I18n in command line tools. This fact actually plays in our advantage, giving people certain exposure to english as a lingua franca for systems administration.
There is nothing wrong with this PR, I really appreciate the effort. But I don't think doing I18n right is a priority for the project, and it's not going to be at least this year. Which is going to cause to have this PR hanging around in the list forever.
I'm going to close this PR. I'll gladly join a more thoughtful conversation about I18n if we want to make it one of our priorities. But I'm afraid this is not going to happen just yet.

I think there's an aspect of this PR that's been missed, and that's the brittleness of things like: https://github.com/docker/docker/blob/master/api/server/server.go#L214  which (as noted in the code itself) is wrong.  So, this PR was designed to address not just a first (very baby) step towards i18n, but also a real code issue that exists.
I totally agree that i18n is far more than just doing the error messages but its a start.  To be honest, I thought it was a pretty small start too and given the desire for smaller PRs instead of larger ones, I figured it would be the best place to start.  And keep in mind, nothing in this PR actually did i18n anything, it was just laying the foundation for it to come later by simply putting static strings into a look-up table, and in the process would stop new static strings from appearing.
I'm disappointed that volunteering to do something as tedious as this conversion, that should have no UX impact, but help make the code less brittle would be rejected.

I'm on @duglin's side here; getting rid of that duct-tape code is the strongest improvement here; I just managed to prevent it being broken on several occasions where people wanted to make small textual changes to the error messages. Perhaps the PR shouldn't have been named something with i18n?
Also wondering; if multiple LGTMs are required to merge, doesn't the same apply for closing a PR ? (Some exceptions may apply of course)

About i18n: I believe Docker is not ready to support it (read, maintaining it) and it's not a current priority.
About refactoring the part @duglin mentioned, I'm totally +1 for it, it's more than welcome. Maybe if the package name was not i18n but more an errmsg package (was thinking errors initially but didn't want to conflict with the stdlib package of the same name).
@jfrazelle @calavera if we agree on this should we continue on this PR and just change the title of it?

I'd rather start clean, tbh. I don't want to carry any baggage from trying to internationalize messages.

aside from the title there was no i18n code in there. I would have preferred to have an open discussion about this issue first before it was closed.

okay, let's move away from the i18n. Reopening!

@duglin two things we need to decide on:

package name :) do you like api/errmsg ?
how are errors during streaming handled? Also if we go with an HTTP header (which doesn't seem to have unanimity), I'd prefer the name X-Docker-Error.
@crosbymichael is this in line with how you envision api v2 ?

@tiborvass I am a huge :-1: on the addition of a header for sending errors. It is really bad design and sets a bad precedent.
@duglin More food for thought: I'm a monolingual, so please disregard if I'm way off here. I used to make a habit of reading the russian version of the nginx documentation. They used to be much clearer and have better examples. If the configuration or log messages were internationalized to english to make it "easier" for me, this would have been impossible. Furthermore, if I searched log or error messages, sometimes I would get answers on russion language mailing lists that would be very helpful.
Having "容器不存在" instead of "No such container" does not help the user if the issue is obtuse in any kind of way. It will just act to partition the information by language, further isolating non-english speakers. The error message just has to be unique to the error to point to a particular problem, which could have a solution, indexed under "No such container" in Italian or Tagalog. The main issue here with log or error output is that now we have to document the error messages and cross-index in hundreds of different languages rather than just one. Search engines are not likely to cross-index these errors for us. It will make a huge amount of information unavailable to users in other languages that would be available by just blindly googling the english error message.
That said, more descriptive user errors, such as those defined in the docker client (imagine the one about --insecure-registry), are prime candidates for internationalization. The error protocol messages are not.

Having (mostly) read through all comments, I'm a +1 billion on typed errors and a "lookup table" for string conversion! Yes, this would be a very important step toward i18n, which I agree we don't need yet.
Regarding the ongoing discussion about the header: I'm not an expert here, so I'm going go with @stevvooe's opinion. It seems a bit weird, plus we bump the API version with each Docker release, so I don't see what's wrong about a breaking change.
Finally, I agree with @calaera that now that the discussion has properly refined to the current idea, a new PR with no mention of i18n would probably be more easier to get into.

renamed the PR. I didn't want to lose the history of the chat (or have to bounce around to an old PR) by creating a new one.
re: header - wasn't going to include that as part of this PR - this will just focus on getting rid of the static strings
More later... super busy today....

Thanks @duglin <3

@stevvooe finally coming back to this.
In looking at your code: https://github.com/docker/distribution/blob/master/registry/api/v2/errors.go If ErrorCode is going to be an int (iota) we need to guarantee (with tests) that no one *ever inserts or removes one from the list.  Reusing one might be ok after a long deprecation period, but still worries me. Using strings instead might be safer ( see: https://github.com/docker/docker/pull/9509/files#diff-cbb3fa40c73b4f6bc9e8c362e3167684R7 ) but I'm not sure.
In an attempt to make the code short and easy to write when people do generate an error, I'm thinking about something like this:
errMsg.NewError( SomeConstant, ...optional list of substitution values... )
e.g:
if ( x != y ) {
    return errMsg.NewError( errMsg.InvalidTag )
}

What do you think?
What's the purpose the errors stack notion?

@duglin Please read the comment carefully. This situation is covered:
// ErrorCode represents the error type. The errors are serialized via strings
// and the integer format may change and should *never* be exported.
type ErrorCode int

Effectively, these are strings and the only thing that is communicated externally are the strings. We represent them as integers to lower memory usage and to provide fast comparisons but the integer itself is never exported in any way (we should probably also implement MarshalBinary/UnmarshalBinary to make this a certainty). The descriptors table sets the mapping. We'll have to build a special error package to move these out of the api v2 package for use in other contexts.
I think requiring one to call a NewError function with every error represents an unnecessary burden. One should be able to return an error code directly as an error, or be able to use an errors structure to collect errors into a collection. No extra code should be required for the simple case to support the complex case. Certain error codes may have a format, but we should define a function on the error code for those cases where it's require. This definition can be part of the descriptor.
The purpose of the errors stack is to have an error context that can collect and report many errors, with or without codes, in some execution context (function call, request, etc.). Yes, these are tied to API-level errors, but it is handy in certain cases.

@stevvooe you said One should be able to return an error code directly as an error... did you mean "Error struct" or "ErrorCode" - if "ErrorCode", wouldn't it need an Error() func on it?
But to your other point, yes I agree about returning an Error 'something' instead of call NewError that would be easier.
If the ErrorCodes are not exportable, do you see anything be exportable? Like the errorDescriptors ?
What do you think about substitution parameters?

@duglin When I am talking about "export" here, I am referring to the integer value of the error code. The mapping can be unique to a build, as long as the text values are used for serialization. This means we always send "UNKNOWN" instead of the integer value for ErrUnknown. We can add Error() string to the implementation, if needed. We can also add a convenience method, such as this:
func FormatErr(err ErrorCode, args...interface{}) error

This could format the error message with the provide arguments if the description has parameters. It would return a populated Error struct. We can also place runtime checks to panic when errors that require formats aren't formatted. For example, one can directly return ErrUnknown, since it has no format characters but returning ErrWithFormatSpecifiers because it's descriptor requires formatting before using it.
To be honest, I am not that keen on substitution parameters since it makes it harder to identify the line of code that generated the error. The main purpose of error codes is to simplify clients handling of errors into classes. Most of this can be mitigated by including detail along with the generated error.

@stevvooe we can see how it plays out w.r.t. substitution params and add them later I guess.  Assuming they're in the "details" section worries me because that's usually not i18n'd.  But, let's start w/o them.
So, how do you want to work this?  'pkg' your stuff so it can be shared between 'distribution' and 'docker'

@duglin The best way to proceed would be to start an effort to pull out the common components of the api/v2 package into a common errors or errcode package (PR against distribution). This new package would provide types for errors, defining error codes (tools for descriptor tables) and maybe some tools for scanning a project and identifying error codes. Once this is accepted, we can begin the effort of bringing the rest of the docker platform on to these error types.
Regarding i18n, I'd still like to see a decent response to this point:

Having "容器不存在" instead of "No such container" does not help the user if the issue is obtuse in any kind of way. It will just act to partition the information by language, further isolating non-english speakers. The error message just has to be unique to the error to point to a particular problem, which could have a solution, indexed under "No such container" in Italian or Tagalog. The main issue here with log or error output is that now we have to document the error messages and cross-index in hundreds of different languages rather than just one. Search engines are not likely to cross-index these errors for us. It will make a huge amount of information unavailable to users in other languages that would be available by just blindly googling the english error message.

Regarding i18n, I'd still like to see a decent response to this point

I'm +1 on keeping it English. I don't think we have the capacity to support people in all languages (and to translate and maintain the documentation), especially not at the pace that Docker and related projects are moving.
IMO, Docker is not an "end user" package; most terminology is already in English, and it should be fair to expect the users to have at least a basic knowledge of the English language.
Don't know what the future brings, but at this point; just English should be fine (just my 0.02c)

@duglin @stevvooe can someone update the description of the PR to reflect exactly what this is supposed to do (i understood the static strings that's great, but there is an HTTP header involved, and a debate on error codes) I think that would help a lot moving forward to code review.

@tiborvass yup will do probably tomorrow or Thursday once I have a better feel for exactly what this PR will cover.

No problem :)

@stevvooe
Was just reviewing a PR and it reminded me of a case where substitution parameters might be needed.  Say we're calling some lower level library (e.g. go's http stuff) and it generates an error but then we want to wrapper that error with something more specific about what we were doing to help the end-user. In that case I think the low-level error message's text might end up being a substitution variable.  Just FYI.
As for the i18n question, I'd actually prefer to not get into that right now because I fear it will derail the discussions. I don't think Docker is ready for it quite yet anyway.  As long as our current task (getting rid of static strings and developing a shared err pkg) doesn't make any decision that would preclude us from morphing it into a (or using an) i18n package in the future then that's all that matters to me right now.

@stevvooe
Please take a look at: https://github.com/duglin/distribution/tree/MoveErrors  and see what you think.
I tried move all the ErrorCode (and related logic) into pkg/errcode/. All tests from errors_test.go remained except for 2 because they were registry specific.  I just commented them out for now so they're easy to spot.
I also moved the definition of the errorDescriptors from descriptors.go to errors.go - just so all 'errcode' related things are in one file.  I can move them back if you want.
Question for ya... in the definition of ErrorDescriptor you have:
HTTPStatusCodes []int

Why is it a slice instead of a single int?  When an error is generated I would think it would always produce the same http status code - if not then the client would see inconsistent results and I would think it would be better to have separate ErrorCodes in those cases. And when there's more than one, which one would the server choose to send back?

@duglin The branch looks like a good start. We can tweak details at review time.
Regarding HTTPStatusCodes, @endophage had pointed this out, as well. The main reasoning behind this was to provide a list of responses under which the error condition may be seen. In reality, managing this is a bit of a pain, so we may want to take this time to have the error codes mapped to unique response codes. This would require a slight change to the specification but nothing that would be a huge problem. This is a bigger change but we should get this right.
Let's do the following:

De-pluralize HTTPStatusCodes to HTTPStatusCode.
Remove 404 from DIGEST_INVALID, TAG_INVALID, and NAME_INVALID. You may need to update the route descriptions accordingly.
Restrict BLOB_UNKNOWN to 404 only and define a new error code for MANIFEST_BLOB_UNKNOWN with 400 error that corresponds with the manifest validation error. This is the main specification change but the impact is minimal.
UNKNOWN error should always be a 500.
Under a multiple error situation, we should specify that the response should take on the status code of the first encountered error unless a 500 error is encountered. For example, if the errors are [DIGEST_INVALID, BLOB_UNKNOWN], the app should return a 400, rather than a 404. However, if [DIGEST_INVALID, UNKNOWN] is returned, the app should return a 500, since UNKNOWN should always be a 500.

The impact this will cause now is minimal but it will greatly simplify implementation.
cc @dmcgowan

@stevvooe
I updated the branch based on your comments. See if its ok. I wasn't sure where MANIFEST_BLOB_UNKNOWN would be used so, while I defined it, its not used yet.
As your point 5 - I wasn't sure if you wanted me to try to update the registry code to do that logic. I tried to see where it would go but I didn't see any code that took the Errors and used that info to determine the http status code. I thought perhaps it might be in the apps handler, or in serveJSON but no luck.  Is this related to what you were saying yesterday about a possible refactoring of the code to deal with all http stuff in one spot?

@stevvooe
Thinking about the next steps...  (and sorry for the long rambling comment - too bad we didn't talk about this yesterday):
How do you envision funcs returning errors to look?  For example - any of these?
func doit(...) ErrorCode {...code...}
func doit(...) []ErrorCode {...code...}
func doit(...) Error {...code...}
func doit(...) Errors {...code...}

I think this is a key design point since we want to make it as easy as possible for people to generate/return errors.  A high-order question I have is around the use of ErrorCode vs Error (or Errors).  I was assuming that ErrorCode is the thing that developers should return and play with. Error (because it contains more than just the code but also the msg and details), is really only used when we need the full error metadata, like when we display it for the user.  So the first two options above were the choices I thought you were thinking of, but I'm not sure.
My current thinking is that I would want to be able to write something like:
    return pkg.BadValue

where pkg.BadValue is of type ErrorCode.  This would imply the first func signature from above.
Of course, that only works for single error cases and you said you wanted to support multiple errors being returned.  To support that we may need to require people to write:
   return []ErrorCode { pkg.BadValue }  // if we're returning ErrorCodes
   return Errors{ []Errors{Error{pkg.BadValue} } }  // if we're returnig Errors

We could create a utility func so it could look like:  return NewErrors(pkg.BadValue) for the 2nd case. Not quite as nice but not too bad either.
But either way this would require the caller to expect a multi-values 'something' as the result and not just a single Error or ErrorCode.  Which means even in code that only deals with single errors they would need to use some kind of if err.Contains(pkg.BadValue) func instead of just if err == pkg.BadValue.   Just something I'm thinking about w.r.t. easy of use.
Another option that I wanted to float by you was the option of making ErrorCode (or Error if Error is the entity you saw being passed around) so that it had a pointer to the 'next' ErrorCode.  Then, rather than returning a slice we always just return a single 'thing' and that 'thing' will only point to a second 'thing' in cases where more than one error can be generated (which btw I don't think is done in Docker engine at all right now).
Anyway, enough rambling for now... let me know what you were thinking in this space.

I've been thinking about how best to do this. There is (precedent)[http://blog.golang.org/error-handling-and-go] for functions returning a custom type rather than the generic error interface and I think this is probably OK for http handlers that should themselves be wrapped in something to generically form and return HTTP error responses when detected.
However, it would be best to keep anything deeper in the call stack to returning error compatible types as some of those packages are used in other non-HTTP contexts.

@endophage I do agree with having whatever we return support the error interface - mainly because then I should be able to convert the engine code over in small chunks instead of having to do it all at once  :-)

@stevvooe and to add a little more to the discussion, in the past we talked about the possible need for substitution values.  Looking at just one example from Docker's builder:  https://github.com/docker/docker/blob/master/builder/evaluator.go#L345  we need to think about how easy we make it for people to return those too.  I know you were questioning if we needed it, but I do think there will be times when we need to either wrapper other info (or error) in something more meaningful, or we need to include dynamically obtained data to display useful error message.
E.g.
return errcode.New( pkg.BadInstruction, cmd)

perhaps returns an ErrorCode struct (not int).
FYI: https://gist.github.com/duglin/689b041823602de05e00

@duglin Re: refactoring distribution. MANIFEST_BLOB_UNKNOWN would be used when handling ErrManifestVerification encountering distribution.ErrManifestBlobUnknown. This is probably more work but I think it would be sufficient to remove all the places that w.WriteHeader is called with an error push. There is a line in app.go where serveJson is called. Before that is called, the status code should be looked up and sent. This would fix docker/distribution/525 and I would owe you a favor.
ErrorCode should probably implement error. In general, I am against alternative error types but, as @endophage pointed out, there is precedent for it.
We can unite the ErrorCode and Error type somewhat through an interface that exposes the code. The Error type effectively becomes a decorated error code. Let's try the following:
type ErrorCoder interface {
    ErrorCode()
}

type ErrorCode int
func (ec ErrorCode) Error() string
func (ec ErrorCode) ErrorCode() ErrorCode { return ec }

type Errors struct { // ... use current fields }
func NewError(code ErrorCode, /* ...whatever you were suggesting above ... */)
func (e Errors) Error() string
func (e Errors) ErrorCode() ErrorCode { return e.Code }

With these implementing a common interface, we can use a type switch to check the error code, if needed:
err := riskyFunction()
switch err := err.(type) {
case ErrorCoder:
    switch err.ErrorCode() {
    case v2.ErrManifestUnknown:
    ...
    }
}

This is slightly more verbose than value checking but it is very future proof. I am not sure if we should unify Errors with this, since that is a lot more special.
@dmcgowan
It might be even better to drop the whole notion of using iota and move to value types. Errors can be declared in each package:
var ErrMyInterestingCondition = errcode.New(, errcode.Descriptor{
    Value: "MY_INTERESTING_CONDITION",
    Message: "A default error message",
    Description: "A long, human-readable description for use in documentation",
    HTTPStatusCode: 400, // only set this if there is a default status code.
})

The errors then have a value type but don't require iota. They can also indexed by package by inspecting the caller. Functions can be provided to get access to collections of errors by package so we can autogen documentation (checkout docs/spec/api.md.tmpl in docker/distribution towards the bottom for an example).

Another option that I wanted to float by you was the option of making ErrorCode (or Error if Error is the entity you saw being passed around) so that it had a pointer to the 'next' ErrorCode. Then, rather than returning a slice we always just return a single 'thing' and that 'thing' will only point to a second 'thing' in cases where more than one error can be generated (which btw I don't think is done in Docker engine at all right now).

This is too crafty. Slices are great. Embrace them! ;)
Jokes aside, something like this is useful for cause tracking, complete with stack traces.  Adding a field to Error as Cause error and add a Push method to error might work. This would allow us to get rid of the Errors type, as long was we maintained some way to generate the json, albeit we can just have the Error type generate the Errors json.

It seems the conversation had slid to implementation, which is somehow encouraging ;-) I'm pushing this to code review. @stevvooe please give it another look if you have a moment!

Actually, the real code is being done in the 'distribution' repo for now ( https://github.com/docker/distribution/pull/548 ) and when that work is completed we'll try to move it into Docker as a pkg/vendor.  So I'm moving this back to design review for now.

Ok, does it mean we should close this one then? A PR is meant to be merged or closed: can this be merged?

@icecrime almost. If you want I can close this until its ready, but I need to make a few minor tweaks to the code in the distribution repo and then we can look at importing it into Docker.

Sounds good, thanks!


[SMALLFIX] Deleting a file or directory should lock the parent directory

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/12429/Failed Tests: 1org.alluxio:alluxio-tests: 1alluxio.master.file.FileSystemMasterIntegrationTest.concurrentCreateDeleteTest
Test FAILed.

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

Merged build finished. Test PASSed.

@aaudiber Thanks for the review! I updated the PR.

Merged build finished. Test PASSed.

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


[MM-16919] Add support for get posts before/after

Summary
PR implements an action for loadtesting the get posts before/after endpoint.
Ticket
https://mattermost.atlassian.net/browse/MM-16919

This issue has been automatically labelled "stale" because it hasn't had recent activity.
A core team member will check in on the status of the PR to help with questions.
Thank you for your contribution!
/cc @jasonblais @hanzei


Multi conatiner app

Can we run locally and debug app with multiple conatiners?

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

ID: 0b3d2f14-f40d-1f84-0506-c87d7f8db59b
Version Independent ID: a16becae-3e1f-78ed-0031-758f331e7021
Content: Use Draft with AKS and Azure Container Registry
Content Source: articles/aks/kubernetes-draft.md
Service: container-service
GitHub Login: @iainfoulds
Microsoft Alias: iainfou

@girishgouda I went through some of the draft examples. All of them speaks about deploying one container only. Lets get some help.
@michelleN Saw your contribution to draft. I think you can help us with this question :-).

@girishgouda I think you can have multiple apps with draft configured for same kubernetes server under different folders.
Since all are in different folders, You can run draft up on them to get it deployed.
Please try this and let me know.

@girishgouda Is there any update?

Ok thanks

From: jakaruna-MSFT<EMAIL_ADDRESS>Sent: Monday, December 31, 2018 11:00 AM
To: MicrosoftDocs/azure-docs
Cc: Girish; Mention
Subject: Re: [MicrosoftDocs/azure-docs] Multi conatiner app (#21280)
@girishgoudahttps://github.com/girishgouda Is there any update?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/azure-docs/issues/21280#issuecomment-450609829, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AImSQiJtmZbWufXQBjJ0XPM8KynCzQRSks5u-aD3gaJpZM4Zhwa9.

@girishgouda I will close this out for now. If you need additional help please let me know and we can reopen and continue.


ACS Deprecation

This page describes using the deprecated app-only ACS model to access SharePoint. The page should state that this is deprecated and explain the alternatives.

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

ID: 8d9fd1db-042c-5f44-ee84-f1a9386fb3e3
Version Independent ID: 81cb2e37-a80c-a48a-68bd-1a03499119a7
Content: Copy data from SharePoint Online List - Azure Data Factory & Azure Synapse
Content Source: articles/data-factory/connector-sharepoint-online-list.md
Service: data-factory
Sub-service: data-movement
GitHub Login: @jianleishen
Microsoft Alias: jianleishen

@Stevef1
Thanks for your feedback! We will investigate and update as appropriate.

Hi @Stevef1
Please go through the link below for your reference. It provides information about alternative methods available for accessing SharePoint.
https://learn.microsoft.com/en-us/sharepoint/dev/sp-add-ins/retirement-announcement-for-azure-acs#:~:text=To learn more about how to migrate Azure ACS usage for SharePoint Online and how to migrate SharePoint Add-Ins to alternative solutions check out these articles and accompanying videos.
Please view below documentation for alternative solutions.
https://learn.microsoft.com/en-us/sharepoint/dev/sp-add-ins-modernize/sp-add-in-modernize

@Stevef1
We are going to close this thread, but if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation.
#Please-close

@Naveenommi-MSFT
Thank you for providing this information. The problem remains with the SharePoint Online List connector in ADF.
The connector requires App ID and Secret parameters as specified here.
As per the following link, when moving to Azure AD App from ACS, secret based authentication is not allowed.
https://learn.microsoft.com/en-us/azure/data-factory/connector-sharepoint-online-list?tabs=data-factory#linked-service-properties
We now have to use certificate based authentication and the current implementation of this connector does not appear to support that.

@Naveenommi-MSFT, Same question as above. Since ACS apps are retired and will stop working in 2026, How we can connect to SharePoint online (List or Library) using apponly token in supported way? SPO REST API only supports certificate and does not support clientsecret when it comes to AAD apps with application permission. ADF Web Activity or "SharePoint list activity" does not provide a way to supply a certificate and all documentation shows to use accounts.accesscontrol.windows.net (means use ACS which is retired). Thanks


k8s: Expand documentation on deployment usage

In #84, we added a Kubernetes deployment with a sample secret. We should expand that document with steps that help understanding the KBS and the way it is intended to use:

How can I reference the example secret we added to the KBS?
How can I use the KBS deployment to encrypt a local image with skopeo? (Port-forward etc.)
Provide some curl requests to show the KBC Protocol and the available endpoints.

How can I reference the example secret we added to the KBS?

Steps after this linked section will be useful for the above:
https://github.com/kinvolk/azure-cvm-tooling/blob/6329c65/docs/end-to-end-test.md#run-attestation-agent

Previous discussion happend in https://github.com/confidential-containers/kbs/pull/84#discussion_r1204024132

@katexochen @surajssd Is this issue still active? Or we can close it

@Xynnn007 This hasn't been implemented yet.


Use SSL to secure data in transit

Example: RDS
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html

https://ssl-config.mozilla.org


Issue #644 : dapr sidecar kubernetes services are not removed

Description
Uninstalling a service and pod  is not removing the dapr side car service.
Issue reference
https://github.com/dapr/dapr/issues/644
Checklist
Please make sure you've  completed the relevant tasks for this PR, out of the following list:

[x] Code compiles correctly
[ ] Created/updated tests
[ ] Unit tests passing
[ ] End-to-end tests passing
[ ] Extended the documentation
[ ] Specification has been updated
[ ] Provided sample for the feature

@shalabhms Can we add unit-test for this ? I know we did not write any unit-test for these codes. at minimum, I would add unit-test for dapr_handler.

@shalabhms Can we add unit-test for this ? I know we did not write any unit-test for these codes. at minimum, I would add unit-test for dapr_handler.

@youngbupark  and I discussed, need to first make kubernetes package testable and have tests around it.

Seem like this needs unit tests?

Discussed with @youngbupark , need to first make kubernetes package testable and have unit tests. Agreed to merge this PR.


Change link for our tutorial

It was linking to an old version of the materials. Put right link in here.

@pjbull ty!


Built in caching support

Potentially add support for caching within the client itself. This should make use of the IDistributedCache interface to be as open as possible. It should also not force the user to implement caching if they choose not to.
This would help reduce load on the Forecast service, as is mentioned on the Harvest GitHub README

IDistributedCache is probably not appropriate for this scenario because of issues around user permissions and viewing different results


TypeError: n.subarray is not a function (regression in v5.25)

Describe the bug
Heya – thank you for maintaining Statoscope! Incredibly useful tool.
Since I upgraded to v5.25, Statoscope started crashing when loading the UI. The error reads like this:
statoscope-unnamed-187619ba9f701cb87367.html:78 Uncaught TypeError: n.subarray is not a function
    at Object.inflate (statoscope-unnamed-187619ba9f701cb87367.html:78:38851)
    at window.Pako.la.push (statoscope-unnamed-187619ba9f701cb87367.html:78:45733)
    at statoscope-unnamed-187619ba9f701cb87367.html:1299:28
    at Array.map (<anonymous>)
    at Object.parse (statoscope-unnamed-187619ba9f701cb87367.html:1290:43)
    at statoscope-unnamed-187619ba9f701cb87367.html:1327:24

The relevant line seems to be this (this is the only mention of .subarray() in the diff between v5.24 and v5.25):
https://github.com/statoscope/statoscope/blob/e5f168391f5fbd59cb065441986d57ad7d60cadf/packages/report-writer/src/utils.ts#L72
If you pause at the exception, you’ll notice n is defined, it just doesn’t have the subarray function (because it’s a regular array):

To Reproduce
Steps to reproduce the behavior:

Run
git clone git@github.com:appsmithorg/appsmith.git --depth 1
cd appsmith/app/client
cp .env.example .env
yarn

Install Statoscope:
yarn add @statoscope/webpack-plugin

Add Statoscope to craco.common.config.js:
const StatoscopeWebpackPlugin = require("@statoscope/webpack-plugin").default;

module.exports = {
  // ...
  webpack: {
    // ...
    configure: {
      // ...
      plugins: [new StatoscopeWebpackPlugin({ statsOptions: { all: true }, open: "file" })],
    }
  }
}

Build the app:
yarn build

Observe how the report opens but hangs at “Parsing...”. Observe the above error in the JS console

Expected behavior
The report should load successfully.
Screenshots

Versions:

Node (for non-browser bug):
Browser (for browser-bug): 109.0.5414.119 (Official Build) (arm64)
Webpack: 5.73.0
Statoscope: 5.25

@iamakulov Thanks! Working on it

@iamakulov there was several problems. I've fixed these
Published in 5.25.1


[FLINK-33500][Runtime] Run storing the JobGraph an asynchronous operation

What is the purpose of the change
Currently, submitting a job starts with storing the JobGraph (in HA setups) in the JobGraphStore. This includes writing the file to S3 (or some other remote file system). The job submission is done in the Dispatcher's main thread. If writing the JobGraph is slow, it would block any other operation on the Dispatcher.
Brief change log

The ZooKeeperStateHandleStore create path in ZooKeeper and locks it then write asynchronously state in Executor
The KubernetesStateHandleStore stores key in ConfigMap and write asynchronously state in Executor
*The dispatcher put JobGraph asynchronously in ioExecutor *
*The dispatcher write To ExecutionGraphInfoStore asynchronously in ioExecutor *

Verifying this change
This change added tests and can be verified as follows:

Added  the Dispatcher JobSubmission test, use ZooKeeperStateHandleStore as JobGraphStore
Added  the Dispatcher JobSubmission test, use KubernetesStateHandleStore as JobGraphStore

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (yes)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not applicable)

@flinkbot run azure

@flinkbot run azure


s3Upload fails with duplicate class definition of com.amazonaws.event.ProgressEvent

Hello,
I've been getting this error for plugin version 1.43, Jenkins version 2.277.4:
java.lang.LinkageError: loader (instance of  hudson/ClassicPluginStrategy$AntClassLoader2): attempted  duplicate class definition for name: "com/amazonaws/event/ProgressEvent"
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(Unknown Source)
	at jenkins.util.AntClassLoader.defineClassFromData(AntClassLoader.java:1155)
	at hudson.ClassicPluginStrategy$AntClassLoader2.defineClassFromData(ClassicPluginStrategy.java:718)
	at jenkins.util.AntClassLoader.getClassFromStream(AntClassLoader.java:1326)
	at jenkins.util.AntClassLoader.findClassInComponents(AntClassLoader.java:1377)
	at jenkins.util.AntClassLoader.findClass(AntClassLoader.java:1342)
	at jenkins.ClassLoaderReflectionToolkit._findClass(ClassLoaderReflectionToolkit.java:107)
	at hudson.ClassicPluginStrategy$DependencyClassLoader.findClass(ClassicPluginStrategy.java:637)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at jenkins.util.AntClassLoader.findBaseClass(AntClassLoader.java:1406)
	at jenkins.util.AntClassLoader.loadClass(AntClassLoader.java:1085)
	at java.lang.ClassLoader.loadClass(Unknown Source)
Caused: java.lang.BootstrapMethodError
	at de.taimos.pipeline.aws.S3UploadStep$RemoteUploader.invoke(S3UploadStep.java:626)
	at de.taimos.pipeline.aws.S3UploadStep$RemoteUploader.invoke(S3UploadStep.java:481)
	at hudson.FilePath.act(FilePath.java:1164)
	at hudson.FilePath.act(FilePath.java:1147)
	at de.taimos.pipeline.aws.S3UploadStep$Execution.run(S3UploadStep.java:463)
	at de.taimos.pipeline.aws.S3UploadStep$Execution.run(S3UploadStep.java:295)
	at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
	at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
	at java.util.concurrent.FutureTask.run(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

The build is setup via a scripting pipeline.
The path to upload is a directory with multiple child folders and files.
Starting the upload via CLI works as intended.
AWS credentials are correct.
The only Amazon-related plugin installed is Pipeline: AWS Steps and its dependencies. I thought at first some other plugin may be loading a different version of ProgressEvent but that wasn't the case.

Did anyone encounter anything similar? I can't find any good resources on what else to check and how to fix this issue. Is it possible multiple uploads load the same class and cause a collision?

In case somebody runs into the same issue, we still haven't solved it but instead avoided it by replacing the plugin with a direct batch call to AWS CLI:
withCredentials([[$class: 'AmazonWebServicesCredentialsBinding', accessKeyVariable: 'KEY_ID', credentialsId: 'CRED-ID', secretKeyVariable: 'ACCESS_KEY']])
{
	echo bat(returnStdout: true, script: "aws s3 cp --recursive ${FOLDER_FROM} ${FOLDER_TO}").trim()
}

If on Windows, make sure that the Jenkins service runs with a Windows user that has privileges to access FOLDER_FROM and call aws s3 cp.


[CDN: NPM package integration]

Registry
npmjs.com
Package name
@tweakpane/core
Package version
latest
Package license
MIT
Registry URL
No response
Checklist

[X] requested version of the npm package not already in Youwol CDN (use cdn-explorer)
[X] npm package exists in the npm registry specified with the name, version and license specified

Other informations
No response

Core seem to be only required @ dev times


add gitter on website near irc channel

we seriously need a better website.
babel one is really cool.

Done


macos: work around posix_spawn() cwd bug

Trying CI for a suspected posix_spawn() bug. - edit: confirmed

macOS 10.15 has a bug where configuring the working directory with
posix_spawn_file_actions_addchdir_np() makes posix_spawn() fail
with ENOENT even though the executable is spawned successfully.

We reimplement this part of posix_spawn because of multiple other bugs related to bad handling of relative paths. Could we add an additional check to https://github.com/libuv/libuv/blob/d777af2fb92505e2a0ae73e789e1c139221b3f23/src/unix/process.c#L732 to fix this?

I'm not sure what additional check you mean?

Ping @vtjnash

This was apparently known, but I though we had worked around it already. Otherwise, there was a more complete version of your patch at https://github.com/libuv/libuv/pull/3257#issuecomment-891374523, but might have gotten lost in the mess of other bugs with posix_spawn we hit.

And to be precise, I think we do not call the broken function (posix_spawnp) in the case where you claim macOS is broken, so this is potentially a bug in our fix for this issue, rather than an underlying bug

posix_spawnp

Is that a typo? The bug is in posix_spawn (sans p) + posix_spawn_file_actions_addchdir_np. The test case exercises exactly that code path.

@bnoordhuis when I reported the bug I was only able to repro with posix_spawnp https://gist.github.com/deepak1556/39d8feb1e572306223fc8203d3eb1a99 is extracted from the bug I filed with feedback assistant.

@deepak1556 Oh, interesting. Rust's libstd indeed calls posix_spawnp() but libuv calls posix_spawn() and seems to trigger the same bug.
(It definitely triggers a bug as the test case demonstrates. And only on 10.15, 10.14 is unaffected.)

libuv calls posix_spawn() and seems to trigger the same bug.

Maybe I might have misunderstood the code path, it looks like libuv also triggers posix_spawnp for relative paths https://github.com/libuv/libuv/blob/v1.x/src/unix/process.c#L674-L685 ?

No, it's me that misunderstood the relevant logic - it indeed ends up calling posix_spawnp() 🤦
In my defense, src/unix/process.c has turned into a real twisty maze of if statements, all alike.


Frozen String Literal Behavior is Confusing

According to the docs, my understanding was that in order for the cop to be satisfied, we had to add # frozen_string_literal: true to the top of the file.
However, after finding what appeared to be a false negative in one of my projects, I found #7241 and its corresponding fix in #7251 that highlighted that adding # frozen_string_literal: false to the top can still pass this cop.  Two points:

I think the docs should be updated to reflect that false is accepted in the magic comment
Is there a way to configure the cop so that it enforces # frozen_string_literal: true only?

Rubocop Info
0.75.0 (using Parser <IP_ADDRESS>, running on ruby 2.6.5 x86_64-linux)

Good points.

I think the docs should be updated to reflect that false is accepted in the magic comment

Yeah, it will be easy to understand if it is documented.

Is there a way to configure the cop so that it enforces # frozen_string_literal: true only?

AFAIK, there is no such configure option, so enhancement will be necessary.

@koic : Thanks for your reply!
I imagine a docs change is something people wouldn't object to.
The enhancement would be nice.  Would be curious to know if people have any objections.

I assumed the Style/FrozenStringLiteralComment cop already checked for true, to be honest.
For reference, current RuboCop default configuration options are;
  EnforcedStyle: always
  SupportedStyles:
    # `always` will always add the frozen string literal comment to a file
    # regardless of the Ruby version or if `freeze` or `<<` are called on a
    # string literal. If you run code against multiple versions of Ruby, it is
    # possible that this will create errors in Ruby 2.3.0+.
    - always
    # `never` will enforce that the frozen string literal comment does not
    # exist in a file.
    - never

Would it make sense to add a new SupportedStyle of alwaystrue?
    # `alwaystrue` will enforce that the frozen string literal comment exists
    # and is set to `true` (i.e. enforcing that string literals _are_ frozen).
    - alwaystrue

I think defaulting to always (the current default) is most intuitive. If someone explicitly uses frozen_string_literal: false they are intentionally not freezing strings, rather than accidentally not freezing strings. An alwaystrue configuration option hopefully solves everyone's use-cases, while maintaining backwards compatibility.

@olliebennett : My thoughts exactly.  I wanted to see if there were any maintainer objections though on this before proceeding with an enhancement.


[Article]: Everything about Integrating Payment Gateways into Your Website or App

Problem Statement:
Write an article on "Everything about Integrating Payment Gateways into Your Website or App"
Overview:
We are expanding our knowledge base and are looking for contributors to write insightful articles. This issue is focused on providing a comprehensive guide for developers and business owners on integrating payment gateways into their websites or apps. The article should cover essential steps, best practices, and key considerations for ensuring a smooth integration process and an optimal payment experience.
Goal:
Your article should provide a detailed guide on how to integrate payment gateways into websites or apps, covering different types of payment gateways, the technical steps involved, and how to choose the right payment gateway for your business. It should also emphasize security best practices, compliance considerations, and tips for enhancing the customer payment experience.
Article Structure:

Introduction

Provide a brief overview of payment gateways and their role in online transactions.

Types of Payment Gateways

Hosted vs. integrated payment gateways
Popular payment gateway options (e.g., PayPal, Stripe, Razorpay, etc.)

Steps for Integrating a Payment Gateway (Feel free to dive deep here)

Setting up a merchant account
Choosing the right gateway for your business
Technical setup: API integration and SDKs
Testing the payment gateway

Best Practices for Payment Gateway Integration

Ensuring security with PCI-DSS compliance
Optimizing user experience during checkout
Handling different currencies and payment methods
Payment failures and retries handling

Optimizing with Payment Orchestrators

Introduce the concept of payment orchestrators and how they enhance the payment gateway integration process.
Benefits of using orchestrators, such as:

Smart routing to reduce transaction failures
Consolidating multiple gateways for a smoother checkout experience
Supporting global payments with local payment methods
Automating retries for failed payments

Discuss how orchestrators can simplify scaling payment infrastructure as businesses grow.

Key Considerations

Transaction fees and settlement times
Supporting global payments and local payment methods
Scalability and performance of the gateway

Conclusion

Summarize the key steps and best practices, and encourage developers and business owners to choose the right payment gateway to ensure seamless payment processes.

Writing Guidelines:
Refer to this Document.
Submission Process:

Ask the maintainers for assignment of the issue, you can request for assignment by commenting on the issue itself.
Once assigned, share the google doc link to the article content, in the following google form.

Maintainers will review and provide feedback, if any.
Once approved, Assigned person will publish the content on Dev.to and Medium and share the final link.
Maintainers can un-assign issues due to inactivity, read more here.

Refer here for Terms and conditions for the contest.

Hey @Yash-sudo-web Assigning this issue to you, thanks for the participation.

@gorakhnathy7
https://docs.google.com/document/d/1pdT9SYMcSNHCPDiphw2NjqnA6K7nfN7DjBi90wddcxM/edit?usp=sharing
here's the link to the article, let me know if anything has to be changed

Hey @Yash-sudo-web Kindly fill it via the google form mentioned in the submission process.


.github/workflows: Wasm tests often fail with websocket url timeout reached

Ebitengine Version
main (10d96601250f34a9e7d0ba5691b04edb230c0d3b)
Operating System

[X] Windows
[ ] macOS
[X] Linux
[ ] FreeBSD
[ ] OpenBSD
[ ] Android
[ ] iOS
[ ] Nintendo Switch
[ ] PlayStation 5
[ ] Xbox
[X] Web Browsers

Go Version (go version)
Go 1.19-1.22
What steps will reproduce the problem?
Run the CI tests.
What is the expected result?
The Wasm tests pass.
What happens instead?
The Wasm tests often fail.
https://github.com/hajimehoshi/ebiten/actions/runs/8965068190
websocket url timeout reached

Anything else you feel useful to add?
No response

Now this doesn't happen?

This happens again.


Long build times & cryptic error messages!

Is this really of the included features? Isn't there a typo?

It was meant as a bit of humor and a caveat that there are downsides to this library.


Node pool with instance_size: 0 and autoscaling.min_instances: 0 still gets one node right away

Hi! I've just bootstrapped a new cluster with this configuration and find that the amd64-large worker node pool immediately has one node in it:

`cluster.yaml`
---
cluster_name: github-arc
kubeconfig_path: "./kubeconfig.yaml"
k3s_version: v1.28.1-rc2+k3s1
public_ssh_key_path: "id_ed25519.pub"
private_ssh_key_path: "id_ed25519"
use_ssh_agent: false # set to true if your key has a passphrase or if SSH connections don't work or seem to hang without agent. See https://github.com/vitobotta/hetzner-k3s#limitations
# ssh_port: 22
ssh_allowed_networks:
  - <IP_ADDRESS>/0 # ensure your current IP is included in the range
api_allowed_networks:
  - <IP_ADDRESS>/0 # ensure your current IP is included in the range
private_network_subnet: <IP_ADDRESS>/16 # ensure this doesn't overlap with other networks in the same project
disable_flannel: false # set to true if you want to install a different CNI
schedule_workloads_on_masters: false

image: ubuntu-22.04
cloud_controller_manager_manifest_url: "https://github.com/hetznercloud/hcloud-cloud-controller-manager/releases/download/v1.18.0/ccm-networks.yaml"
csi_driver_manifest_url: "https://raw.githubusercontent.com/hetznercloud/csi-driver/v2.5.1/deploy/kubernetes/hcloud-csi.yml"
system_upgrade_controller_manifest_url: "https://raw.githubusercontent.com/rancher/system-upgrade-controller/master/manifests/system-upgrade-controller.yaml"

masters_pool:
  instance_type: cax11
  instance_count: 1
  location: hel1

worker_node_pools:
- name: default
  instance_type: cpx21
  instance_count: 1
  location: hel1

- name: amd64-small
  instance_type: cpx21
  instance_count: 1
  location: hel1
  labels:
    - key: arc-worker-pool
      value: small
  taints:
    - key: workload
      value: arc-job:NoSchedule
  autoscaling:
    enabled: true
    min_instances: 1
    max_instances: 3

- name: arm64-small
  instance_type: cax11
  instance_count: 1
  location: hel1
  labels:
    - key: arc-worker-pool
      value: small
  taints:
    - key: workload
      value: arc-job:NoSchedule
  autoscaling:
    enabled: true
    min_instances: 1
    max_instances: 3

- name: amd64-large
  instance_type: cpx41
  instance_count: 0
  location: hel1
  labels:
    - key: arc-worker-pool
      value: large
  taints:
    - key: workload
      value: arc-job:NoSchedule
  autoscaling:
    enabled: true
    min_instances: 0
    max_instances: 4

- name: arm64-large
  instance_type: cax41
  instance_count: 0
  location: hel1
  labels:
    - key: arc-worker-pool
      value: large
  taints:
    - key: workload
      value: arc-job:NoSchedule
  autoscaling:
    enabled: true
    min_instances: 0
    max_instances: 4

I also find that the master node does not have a NoSchedule taint for being a control plane despite schedule_workloads_on_masters: false.

It seems after a few minutes autoscaler removed the node again.

The issue with the taints also holds true for the explicit ones mentioned in the config. Happy to file a separate issue for this if you like.

Since it was probably just some issue with the autoscaler, and it goes back to zero relatively quickly, I'll close this again. I've opened #317 for taint/label support in auto-scaled node pools.


Handle Null parameters the right way with Vert.x SQL client

Based on this comment,  it seems that we are  not handling nul values the right way:.
See https://vertx.io/docs/vertx-mssql-client/java/#_handling_null

Yeah, but frankly I'm a bit confused by that comment. I mean, none of the other Vert.x clients seem to require this, nor do they have that section in the documentation. So why is this a requirement of the SQL Server client?

I have no idea yet. This issue is mostly a reminder for us (mostly me maybe) to check what's going on.

Well if it's necessary I guess it's easy enough to stick an object with a JDBC type code in the map of bound parameter values, and then translate it to whatever the SQL Server client needs.

On it.


[Lora] Allow more Lora hyperparams

Allow r and alpha to be set in Create request

All configs in the PeftConfig class are supported to be passed in as hyperparameters! Note that the name of the param is lora_alpha instead of alpha.
e.g.
FineTune.create(hyperparams={"peft_config": {"lora_alpha": 32, "r": 8}})


mkstemps() causes linker errors with glibc<2.7

In recent versions of libxsmm, libxsmm_trace.c and src/libxsmm_malloc.c call mkstemps().
This function only exists in versions of glibc since 2.7 (http://man7.org/linux/man-pages/man3/mkstemp.3.html), but I'm trying to link against libxsmm on an old cluster running RHEL 5, which only has glibc 2.5. So I get linker errors complaining that mkstemps is an undefined symbol.
The hardware I'm using is sufficiently old that upgrading is not feasible. Does this mean that I am stuck with version 1.5.2 of libxsmm, or is there a way to work around this problem?
If glibc 2.7 is a requirement, is there somewhere I could have seen this in the documentation? If so, please accept my apologies for missing it.

No you're not stuck. I will resolve this asap and you can rely on LIBXSMM/master (or a specific SHA/commit) until v2.0 is released.

For the time being (prior to v2.0), you may take any of the following (or the master revision):

https://github.com/hfp/libxsmm/archive/580fd06301ea1c17662860a5ab6d1513a4deb9a2.tar.gz
https://github.com/hfp/libxsmm/archive/580fd06301ea1c17662860a5ab6d1513a4deb9a2.zip

The revisions noted above shall fix the issue. Thank you for reporting!
Note: Needless to say that RHEL5 is well-agend with a lot of things that already need some maintenance e.g., an updated libssl in order to keep tools working [wget, curl, git]). It should be also noted that the default compiler (GCC v4.1) is below LIBXSMM's (official) baseline requirement. I am still maintaining compatibility with below-baseline (but without any claims).

Thank you very much for the quick response, @hfp! I was able to build the latest master branch. I'll watch for version 2.0 to go back to a stable release. I understand about RHEL5 being ancient, and I've already been hard at work updating many packages, including those you mention. I've installed GCC v7.3.0, which seems to be working well so far.

GCC v7.3 is a very reasonable choice; no issues from that side with LIBXSMM! Of course, the whole issue was just caused by an missing feature test on our end. Regarding stability, the SMM domain is stable and usually one can take our master if it says: . I guess v2.0 is still some weeks away (if not two months).


Nested objects and arrays

Really interesting library already!
There does not seem to be support for nested objects and arrays yet, AFAICT.
For example based on a schema like this:
const schema = z.object({
  name: z.string(),
  contact: z.object({ email: z.string().nonempty().email() }),
  addresses: z.array(
    z.object({
      address: z.string(),
      country: z.string()
    })
  ),
});

It seems like it should be pretty easy to do this using register etc. from react-hook-form, but it would be nice to have support for that in remix-forms.

Hey, @02JanDal! Thanks for creating this issue :muscle:
We don't have support for objects and arrays in the schema yet, but it is high on our priority list to add it :)
In the meantime, you can still use Remix Forms for the schema above, but instead of rendering a Field component, you'll need to render a custom UI directly inside of Form's children, with the help of register and other react-hook-form props. I haven't tested it yet, but I think all the client-side validations will work correctly that way.
The server-side validations do work with objects and arrays already, so you're covered on that end.
Can you please let us know if this works?

Hey, @danielweinmann. I tried this with a set off checkboxes, all with the same name. This is my Zod schema:
const schema = z.object({
  name: z.string().nonempty(),
  age: z.number(),
  hobbies: z.array(z.string()).nonempty("Must have at least one hobby")
});

When I have two or more checkboxes checked, I get the correct values passed into my mutation function. But, if I have only one checkbox checked, the form doesn't submit. I (strongly!) suspect this is because a single value is passed as a scalar, rather than as an array. Do you know how I might patch this up?

Hey, @gederer! Can you share a complete example of how you made it work with us? I'm designing an API to deal with nested objects and arrays, and it would be great to contemplate your use case when thinking about it.


[feature] Option to keep synthetics

Some obfuscators purposefully mark all classes/methods/etc as synthetic, with the intention to break decompilers which automatically remove them (like JADX atm). A setting on JadxArgs like setKeepSynthetics would be nice (maybe for bridge methods too?)

@NebelNidas can you share a sample for such cases?
As I remember, just adding synthetic modifier should not cause method removing (jadx don't trust modifiers). So it looks like a bug to me. Anyway, I will investigate this further and sample will be very helpful :slightly_smiling_face:


buttons.css should include classnames

add .button, .primary, .light, .dark to the buttons file and add examples of usage on the demo page

May I suggest to use/add visually neutral names like .primary, .secondary, and .accent that could eventually define whatever colour theme a site's using. In some areas we found these thee meaningful major colours need a neutral companion and added .compl for the then visually complementary stuff (buttons, badges, icons).
.light and .dark only make sense if all colour themes allow for such a visual concept. What shade does the .dark button of a dark theme have if the primary is dark already?
A secondary button or element however could be either dark or light based off the CD and the active colour theme/context.
Our version of .button is also used to style anything that isn't a real <button> to look like one (+ JS for the fun) and .link-like to make real buttons look like anchors.
For our CTA set we also added "modifiers" .-ghost and .-contour that modify button fill, borders and outlines, but take the colours from whatever is defined by one of the mutually exclusive main classes (primary, secondary, accent).
This quartet is also applied for other coloured things to carry meaning or purposes of an element or area (--surface-secondary).
 Button Modifiers
They're almost utility classes but with a stricter scope.
.btn {
  &.-primary {
	--btn-shade: var(--brand-primary-100);
	--btn-base: var(--brand-primary-400);
	--btn-border: var(--brand-primary-400);
	--btn-hover: var(--brand-primary-600);
	--btn-text: var(--color-10);
	--btn-text-hover: var(--color-10);
  }
  &.-secondary {
	--btn-shade: var(--brand-secondary-100);
	--btn-base: var(--brand-secondary-400);
	--btn-hover: var(--brand-secondary-600);
	--btn-text: var(--color-10);
	--btn-text-hover: var(--btn-shade);
  }
  &.-accent {
	--btn-shade: var(--brand-accent-100);
	--btn-base: var(--brand-accent-400);
	--btn-hover: var(--brand-accent-600);
	--btn-text: var(--color-10);
	--btn-text-hover: var(--btn-shade);
  }
  &.-compl {
	--btn-shade: var(--brand-compl-100);
	--btn-base: var(--brand-compl-400);
	--btn-hover: var(--brand-compl-600);
	--btn-text: var(--color-10);
	--btn-text-hover: var(--btn-shade);
  }
  &:not(.-primary) {
	--btn-border: var(--btn-base);
  }
  &.-ghost {
	--btn-base: var(--surface-10);
	--btn-border: var(--btn-text);
  }
  &.-big { ... }
  &.-half { ... }
}

As you can see they're actually all "modifier classes" that don't work on their own and each will change different properties. They must be used with .btn but can be combined.
There can always be a primary, secondary or accented "thing", i.e. for the card component we use the aptly named .card to define their basic look and there are equally named modifiers to make adjustments where we see fit.
You can throw in any colours you want (-100 = darkest, -900 = lightest)

One of the ideas of this was to allow specifying the buttons to be only dark or only light, but i hear ya about neutral naming!
this issue will need to create an entirely different button stylesheet for import, that's just utilities 👍🏻  thanks for sharing y'all's process and setup. looks pretty standard (i mean that in a good way!). can you believe some people think buttons are easy? 😂

not only are buttons easy, they also work wonders: need a new app or site feature? just slap "a button" on it and you're done (according to user's feature requests). 🦄✨

the ideas of this was to allow specifying the buttons to be only dark or only light,

sure, hence:

What shade does the .dark button of a dark theme have ... ?

The concept of "dark" and "light" only works with specific themes / environments. One will soon end up with something called dark that eventually isn't.
That's why I suggested the generic accent and complementary variants :-)
For that very reason I also abandoned classes like "red" or "blue" +20 years ago, even if these would've been the main two corporate colours -- and dark-themes weren't really a thing then, but maybe print in black and white.
There'll always be some situation in any design job where identifying sth. by colour name/shade only is virtually meaningless or even obstructive in communication.
Happy New Year! 🍾


Cannot read property 'getComputedStyle' of null  - when position of object tag is set to absolute

All of the animations work fine until I set the position of the object tag to absolute.  Then I get this error. How should I go about using absolute positioning on my SVG graphic without breaking the animations?

It looks like the Position has to be set to 'absolute' when the SVG is loaded. If you change it later using JS or manually in devtools, you'll get this error.


[Regression] False positive type check for method arguments with defineExpose

Summary
vue-tsc shows false positive type check for this piece of codes
<script setup lang="ts">

interface Bar {
    foo(bar: string): void;
}

defineExpose<Bar>({
    foo(bar) {
        console.log('foo', bar);
    }
})
</script>

The error is error TS7006: Parameter 'bar' implicitly has an 'any' type.
This bug happens since 0.34.15+
Reproduce repo

Check out https://github.com/ahnpnl/volar-starter-vite/tree/bug/args-type-define-expose (branch args-type-define-expose)
Install deps with yarn
Run yarn type-check

Expectation
The error should not be there.

I've found that I still have this bug on 1.8.16, and the version of vue I'm using now is 2.7.14

@Tarrowren Open a new issue.


Create plugin to monitor for mismatched storage/host pairings

This may take some work to get right, but this plugin is intended to detect VMs housed on datastores that are distant to the hosts that are running them.
In our environment we have a total of 6 hosts. Three are in one datacenter, three are in another datacenter. Years ago the workload was light enough and the network connection between the DCs fast enough that most of our VMs could run on any set of hosts with minimal impact. At present attempting this causes no end of headaches.
Even numbered hosts are in one DC, odd numbered hosts are in the other. Datastores are prefixed with DC location. Knowing this, we can hard-code pair patterns to note when we have a mismatch.
The vSphere structure is composed of only a single datacenter, so we can't use DC separation as a search pattern. We could use a set of flags to specify a set of hostnames and datastore prefixes. The plugin could list all VMs housed on the datastores and verify what hosts they're running on. One of two flags would (or a boolean single flag) could identify whether a mismatch is considered WARNING or CRITICAL.
Regarding the service check, I suspect it would be easier to configure one service check per set of datastores & hosts. Presumably this would mean if there were 3 separate locations with storage intended for each (though connected to other hosts as a "fallback" option), this would mean three service checks.
An enhancement to this plugin could pivot to using tags or attributes to identify pairings and alert when a mismatch is found. This is likely the most flexible option for long-term use. This could catch for example an I/O demanding VM running on a lower tier of storage hardware, or a VM used by one team running on a datastore intended for another team.

References:

https://docs.vmware.com/en/VMware-vSphere/6.0/com.vmware.vsphere.hostclient.doc/GUID-25244732-D473-4857-A471-579257B6D95F.html
https://www.virtuallyghetto.com/2015/01/custom-attributes-vsphere-tags.html
https://www.virtuallyghetto.com/2016/03/applying-custom-attributes-beyond-just-host-virtual-machine-objects.html

Will likely rely on the work for GH-6 in order to implement this plugin.

Will likely rely on the work for GH-6 in order to implement this plugin.

Reading more (and testing), it appears that vSphere Custom Attributes may be per object, but they're stored in vCenter and (at least in our environment) are not read/write by default to our team. Once the values are set however, we're able to read those values programmatically, so it's still a viable approach here.
As I noted previously the ESXi hosts use a Location Custom Attribute where the datacenter name is a prefix for the value, not the whole value as with datastores (now). The prefix value is also CamelCase compared to capitalizing only the first letter in the Attribute value. This would necessitate changing the values (likely not viable for some future users of this plugin), or folding the case of the "prefix" for comparison.
An early draft of this plugin should probably use a folded case "prefix" value for comparison across hosts and datastores, simplifying the options as much as possible. Once the design takes shape I may have a better idea how to handle this.

Reading more (and testing), it appears that vSphere Custom Attributes may be per object, but they're stored in vCenter and (at least in our environment) are not read/write by default to our team. Once the values are set however, we're able to read those values programmatically, so it's still a viable approach here.
As I noted previously the ESXi hosts use a Location Custom Attribute where the datacenter name is a prefix for the value, not the whole value as with datastores (now). The prefix value is also CamelCase compared to capitalizing only the first letter in the Attribute value. This would necessitate changing the values (likely not viable for some future users of this plugin), or folding the case of the "prefix" for comparison.
An early draft of this plugin should probably use a folded case "prefix" value for comparison across hosts and datastores, simplifying the options as much as possible. Once the design takes shape I may have a better idea how to handle this.

From the 2016/03 virtuallyghetto.com article (link in the OP):

Finally, it is time to retrieve these Custom Attributes to see if they were indeed properly set. We first need to build up a hash table of the key's name, so we can easily correlate the specific Custom Attribute name with the unique key ID. Next, we can then extract the Value property which extends CustomFieldStringValue and contains both the key which we can look up from our look up table and most importantly, the value which contains the data that we had set earlier.

Based on what I saw previously during testing, this seems to confirm that the Custom Attribute (once set) shares a key ID with other instances of that same Custom Attribute. While the value may be object specific, it seems that the Custom Attribute name is unique. Not sure yet whether this is across all of vSphere (all datacenters) or just one datacenter.

From the 2016/03 virtuallyghetto.com article (link in the OP):

Finally, it is time to retrieve these Custom Attributes to see if they were indeed properly set. We first need to build up a hash table of the key's name, so we can easily correlate the specific Custom Attribute name with the unique key ID. Next, we can then extract the Value property which extends CustomFieldStringValue and contains both the key which we can look up from our look up table and most importantly, the value which contains the data that we had set earlier.

Based on what I saw previously during testing, this seems to confirm that the Custom Attribute (once set) shares a key ID with other instances of that same Custom Attribute. While the value may be object specific, it seems that the Custom Attribute name is unique. Not sure yet whether this is across all of vSphere (all datacenters) or just one datacenter.

Not sure yet whether this is across all of vSphere (all datacenters) or just one datacenter.

Found this in the same article:

There are several major benefits to vSphere Tags over Custom Attributes. One they are multi-vCenter Server aware when joined to the same SSO Domain, which means existing Tags/Tag Categories are automatically made available versus Custom Attributes which are bounded by a single vCenter Server.

vCenter Server "wide" then.

Not sure yet whether this is across all of vSphere (all datacenters) or just one datacenter.

Found this in the same article:

There are several major benefits to vSphere Tags over Custom Attributes. One they are multi-vCenter Server aware when joined to the same SSO Domain, which means existing Tags/Tag Categories are automatically made available versus Custom Attributes which are bounded by a single vCenter Server.

vCenter Server "wide" then.

Another remark from the same 2016/03 article:

For Custom Attributes, you would need to first identity the object which means you must search through all objects unless you know the one you are looking for first and then iterate through the list of Custom Attributes looking for the specific key and then finally the value.

This is relevant to what we'll need to attempt here.

Another remark from the same 2016/03 article:

For Custom Attributes, you would need to first identity the object which means you must search through all objects unless you know the one you are looking for first and then iterate through the list of Custom Attributes looking for the specific key and then finally the value.

This is relevant to what we'll need to attempt here.

Reading more (and testing), it appears that vSphere Custom Attributes may be per object, but they're stored in vCenter and (at least in our environment) are not read/write by default to our team.

Based on KB 1005720 I see why:

Minimum required privileges:
Global > Manage Custom Attributes
Global > Set Custom Attributes
Virtual Machine > Configuration > Rename
Virtual Machine > Configuration > Set Annotation

Since we're not admins across the cluster, by design we're not allowed to create new Custom Attributes. Presumably doing so would introduce a security risk of some sort. Minor reading seems to indicate that privileges can be bestowed based on Custom Attributes set on an object. I read it quickly, so maybe it was specific to tags instead? Either way, this makes more sense now.

Reading more (and testing), it appears that vSphere Custom Attributes may be per object, but they're stored in vCenter and (at least in our environment) are not read/write by default to our team.

Based on KB 1005720 I see why:

Minimum required privileges:
Global > Manage Custom Attributes
Global > Set Custom Attributes
Virtual Machine > Configuration > Rename
Virtual Machine > Configuration > Set Annotation

Since we're not admins across the cluster, by design we're not allowed to create new Custom Attributes. Presumably doing so would introduce a security risk of some sort. Minor reading seems to indicate that privileges can be bestowed based on Custom Attributes set on an object. I read it quickly, so maybe it was specific to tags instead? Either way, this makes more sense now.

Based on very brief testing (and probably too-light reading), a Custom Attribute is per object type. If a Location Attribute is defined for a HostSystem and again for a Datastore, the underlying key ID values may (very likely will) be different.
In testing, I found that a Host has a key ID value of 6 for the field, whereas a Datastore has a value of 501.
Based on this, I suspect that I would need to first query based on the object type, then use that to retrieve the Attribute value.

Based on very brief testing (and probably too-light reading), a Custom Attribute is per object type. If a Location Attribute is defined for a HostSystem and again for a Datastore, the underlying key ID values may (very likely will) be different.
In testing, I found that a Host has a key ID value of 6 for the field, whereas a Datastore has a value of 501.
Based on this, I suspect that I would need to first query based on the object type, then use that to retrieve the Attribute value.

After some head scratching, I realized/learned/discovered:

ManagedEntity has a CustomValue field. The CustomValue field is of type []types.BaseCustomFieldValue.
The BaseCustomFieldValue is an interface with a single GetCustomFieldValue() method. This method returns a *CustomFieldValue type.
The CustomFieldValue type is a struct. This struct has a GetCustomFieldValue() method that returns a *CustomFieldValue.
By using %+v and %#v against a types.BaseCustomFieldValue and the  returned *types.CustomFieldValue from func (types.BaseCustomFieldValue).GetCustomFieldValue(), I can tell that we want  to end up with a &types.CustomFieldStringValue type in order to expose the Value field.
Since the CustomFieldStringValue type contains a CustomFieldValue, this satisfies an "Is A" relationship, but just as importantly the Is A relationship mentioned before allows both types to satisfy the BaseCustomFieldValue interface type, which means that we can convert the BaseCustomFieldValue type to a CustomFieldStringValue type. This allows us to get at both fields, Value and Key

Getting the AvailableField values is simpler.
This seems to do roughly what I want, though admittedly we can list specific properties in place of nil (acts as a wildcard) to improve performance:
  // ...
  var hs []mo.HostSystem
  err = v.Retrieve(ctx, []string{"HostSystem"}, nil, &hs)
  // ...
  for _, host := range hs {
    fmt.Println("Host:", host.Name)
    for _, cf := range host.CustomValue {
      fmt.Printf("Type assert to CustomFieldStringValue: %+v\n", cf.(*types.CustomFieldStringValue))
      fmt.Printf("CustomFieldStringValue (Key): %+v\n", cf.(*types.CustomFieldStringValue).Key)
      fmt.Printf("CustomFieldStringValue (Value): %+v\n", cf.(*types.CustomFieldStringValue).Value)
    }

    for _, af := range host.AvailableField {
      fmt.Printf("AvailableField.Key %v\n", af.Key)
      fmt.Printf("AvailableField.Name: %v\n", af.Name)
    }

After some head scratching, I realized/learned/discovered:

ManagedEntity has a CustomValue field. The CustomValue field is of type []types.BaseCustomFieldValue.
The BaseCustomFieldValue is an interface with a single GetCustomFieldValue() method. This method returns a *CustomFieldValue type.
The CustomFieldValue type is a struct. This struct has a GetCustomFieldValue() method that returns a *CustomFieldValue.
By using %+v and %#v against a types.BaseCustomFieldValue and the  returned *types.CustomFieldValue from func (types.BaseCustomFieldValue).GetCustomFieldValue(), I can tell that we want  to end up with a &types.CustomFieldStringValue type in order to expose the Value field.
Since the CustomFieldStringValue type contains a CustomFieldValue, this satisfies an "Is A" relationship, but just as importantly the Is A relationship mentioned before allows both types to satisfy the BaseCustomFieldValue interface type, which means that we can convert the BaseCustomFieldValue type to a CustomFieldStringValue type. This allows us to get at both fields, Value and Key

Getting the AvailableField values is simpler.
This seems to do roughly what I want, though admittedly we can list specific properties in place of nil (acts as a wildcard) to improve performance:
  // ...
  var hs []mo.HostSystem
  err = v.Retrieve(ctx, []string{"HostSystem"}, nil, &hs)
  // ...
  for _, host := range hs {
    fmt.Println("Host:", host.Name)
    for _, cf := range host.CustomValue {
      fmt.Printf("Type assert to CustomFieldStringValue: %+v\n", cf.(*types.CustomFieldStringValue))
      fmt.Printf("CustomFieldStringValue (Key): %+v\n", cf.(*types.CustomFieldStringValue).Key)
      fmt.Printf("CustomFieldStringValue (Value): %+v\n", cf.(*types.CustomFieldStringValue).Value)
    }

    for _, af := range host.AvailableField {
      fmt.Printf("AvailableField.Key %v\n", af.Key)
      fmt.Printf("AvailableField.Name: %v\n", af.Name)
    }

I've got a first draft ready to refine further. I've archived the current state and am about to work on polishing the plugin for deployment in our environment. There is a lot of code in this plugin which needs refactoring, but the overall functionality appears to be work as intended.

I've got a first draft ready to refine further. I've archived the current state and am about to work on polishing the plugin for deployment in our environment. There is a lot of code in this plugin which needs refactoring, but the overall functionality appears to be work as intended.


0.5.1 Dev Bug Fixes

idk..pull request ig

@planet-exe if you would like this to be merged into the main project, you will have to make sure that no functionality is removed from branch 5.0.0 and 5.0.1 since you used an outdated version of the project for your update

@planet-exe Converting to a draft until ready once you have made you changes work with the current dev branch feel free to try again if you have any questions ask any of the core members 👍

huh? u saying that when i added to the project i was a version behind, so now this stuff isnt useful?

ok ill try

i need push acess to dev branch DDDD:

No, you need to update this branch, then we will push it for you


ArrayIndexOutOfBounds exception when selecting something in a VisTextArea

Java version used: JavaSE 11
libGDX version used: 1.9.9 with lwjgl3 backend
visUI version used: 1.4.2
Ways to reproduce:

have multible lines of text in a VisTextArea.
make sure that the first line is empty (just a linebreak)
start selection in line 2 by holding left mouse button
click drag the selection up to 0,0 (as you would do if you want to select everything before the point you started the selection on)

The Application crashes with the following Stacktrace: https://pastebin.com/BTiDiKeS

Fixed, thanks for reporting


intel: add intel-media-driver

Provides hardware accelerated video playback from Broadwell onwards.
Older boards (e.g. Sandy Bridge) are not supported. I'm not sure if they should specifically be excluded.
More info:

https://github.com/intel/media-driver#supported-platforms
https://wiki.archlinux.org/index.php/Hardware_video_acceleration#Intel

Closes #99.

Sorry I missed your comment on the other thread, I don't know why I never sent it... this looks good to me too. Thanks!

I would like to verify that this doesn't break sandy bridge, but I have no way of doing so :(

I vote to merge and hope for the best. Other option is to inject /proc/cpuinfo into the configuration somehow

Should this also not enable the HuC firmware, whatever that is? https://github.com/intel/media-driver/blob/master/README.md#known-issues-and-limitations

Sandy bridge testers becomes quite rare these days.

I've got sandy bridge but my chipset doesn't support the integrated video card :/

@wmertens regarding HuC, there's some info on the Arch wiki.
And a pretty nice chart of supported features on each architecture, courtesy of the Gentoo wiki.

And it seems like HuC is only supported from Skywell onwards, which means we should make it conditional. Broadwells are still pretty common, I reckon.


Fix reading font from configuration file

*cppcheck found this, and it fixes a failure to apply the font asked for in the configuration json file
*In at least some build environments, shadowing the outer variable declaration causes the new value to be discarded it seems. In this case, it causes the font selected by the user to be ignored.

Fixes

button blurriness is probably the usual scaling issue with GtkPixBuf, will look at that too

It's strange that the compiler didn't complain about this...
Anyway, thanks!


Wsl swap bug

Windows Version
Microsoft Windows [10.0.22000.2416]
WSL Version
<IP_ADDRESS>
Are you using WSL 1 or WSL 2?

[X] WSL 2
[ ] WSL 1

Kernel Version
5.15.123
Distro Version
Ubuntu-22.04.3
Other Software
Xfce4
Repro Steps
Idk
Expected Behavior
I'm ROM builder and I'm using wsl to build roms but few days ago I started to use swap from wsl.config file instead of distro swap and expected to continue building like before
Actual Behavior
What happened is while building PC froze and for unknown reason it didn't run anything at all so I had to restart but that's not the problem, the problem is swap size still taken from C drive and there's no much space in C, tried many different ways to delete old swap but nothing (wen wsl starts to use swap it takes from c drive, wen u shutdown wsl it deletes that swap)
Plz help
Diagnostic Logs
No response

Nvm, I found swap file at C/users/$username/AppData/Temp
It's vhdx file btw hope wsl gets better soon I really like it


[FEATURE] Scroll To Top button

Description
Scroll to top button allows users to quickly navigate to the top of a page with a single click or tap. It offers a convenient way to return to the beginning of a long webpage without manually scrolling.
Screenshots
No response
🥦 Browser
Google Chrome
Checklist ✅

[X] I checked and didn't find similar issue
[X] I have read the Contributing Guidelines
[X] I am willing to work on this issue (blank for no)

Please do not create duplicate issues, this is already being done in #944