Feature Request - Multi-select support for custom forms

I know you closed a couple issues about multi-selects, but it would be helpful to know if this is in plans for the future, or if we should just work out something different and try to match the styles. Thanks!

@icyz your site http://www.andreamariani.net seems to be down FYI.

@harlantwood yes, I'm sorry for this but you can get the repo here: https://github.com/icyz/zurbfoundation5-multiselect
sorry for late answer, but at the moment I'm really busy

Please reopen this bug and mark for the F7.


Add option to use 64 bits for matrix computations

See https://forum.babylonjs.com/t/problem-with-matrix-multiplication/12420/5 for eg, or https://forum.babylonjs.com/t/how-to-do-high-precision-transformations/2497/4.
This PR adds the option to use 64 bits for matrix computations.
There is a problem with static matrices: they are created according to the default value of Matrix.Use64Bits in effect in the Babylon package...
For eg, BABYLON.TmpVectors.Matrix[0]._m is a Float32Array if Matrix.Use64Bits = false and should be converted to a regular array if the user set Matrix.Use64Bits = true later on.
I tried to deal with the problem by keeping track of the matrix instances and recreating the _m property when the Use64Bits value change. However, it would be too much to keep track of all instances when only static instances matter, so there's a flag in the constructor for that. However, it relies on the Babylon developper to create static matrices with the right flag, else it won't be tracked... I have done it for the TmpVectors.Matrix array, but we would need to review all the source code to locate where static matrices are created and do the change.
We could simplify this by doing something like:

by default, the Matrix class keeps track of all instance creations
we add a method like Matrix.StopTrackingInstances
this method is called at the very beginning of the Engine constructor

That way, all matrices created before creating the engine are tracked. As creating the engine is normally the very first thing you do in a Babylon app, it's a crude way to collect static matrix instances... That would simplify the problem a lot as we don't need to review all the source code anymore, and future code is foolproof too.
[...] Even easier: use the Use64Bits setter to stop tracking the instances! As above, matrix instances are tracked by default and when Use64Bits is assigned a different value from the previous one, the tracking is disabled. It avoids adding a method to be called by the Engine constructor. That means we can change Use64Bits a single time, but I think it's ok: we should not allow the user to change it multiple times, else we would need to track all matrix creations. We should make clear in the doc that changing Use64Bits should be done early and can be done only a single time [...] Ah, that does not work if we never change the precision to 64 bits... So we still need a StopTrackingInstances method to be called early in the process  => I have updated the PR accordingly, let me know what you think. To make clear we can change the precision a single time, I have renamed the method switchTo64Bits.
Note: I have set Use64Bits = true in the PR to verify that the unit tests are ok when the value is true. I will revert it to false when/if the PR is merged.

I think we should do something simpler. The matrices created before the switch will stay the way they are
It is a setup you need to run at the very beginning of your code. We should not support an intermediate state
My recommendation is to override the functions. By default the matrix will call a function to create the content with a floatarray but if we call a static function (like SwitchToHighPrecision) then we will overwrite the creation function AT run time at tprototype level

I'm ok to do that but that means some computation will automatically switch to low precision when the code is using matrices declared as static (which can happen in quite a place to avoid garbage collection - notably all the code using the Math.TmpVectors.Matrix array), because those matrices will stay low precision. The user won't know that it happens under the hood and won't be able to do anything to prevent it.
If that's ok for you, I will perform the changes.

What if the flag was on the engine? This way the first time we are going to hit Matrix the flag will be already set

I don't understand...
Do you mean the Use64Bits flag? If yes, how putting it in the Engine will help regarding the static matrices problem?

by setting it on the engine it should be ready before we go to the Matrix static creation. The static properties are defined and executed the first time you reference the matrix class

In fact overwriting the constructor does not work, because the generated js code does not use prototype.constructor to create matrix instances.
The typescript code for the Matrix class is expanded to:
var Matrix = /** @class */ (function () {
    function Matrix() {
        this._isIdentity = false;
        this._isIdentityDirty = true;
        this._isIdentity3x2 = true;
        this._isIdentity3x2Dirty = true;
        this.updateFlag = -1;
        this._m = new Float32Array(16);
        this._updateIdentityStatus(false);
    }
    Matrix.prototype._markAsUpdated = function () {
        [...]
    };
    Matrix.prototype._updateIdentityStatus = function (isIdentity, isIdentityDirty, isIdentity3x2, isIdentity3x2Dirty) {
        [...]
    };
    [...]
    return Matrix;
}());

So, I don't see a way to replace the constructor by another one. The only thing I could do is move the this._m = new Float32Array(16); initialization in a function and overwrite this function (but it's an additional function call compared to the existing code).
Also, the TmpVectors static is expanded like this in js:
var TmpVectors = /** @class */ (function () {
    function TmpVectors() {
    }
    [...]
    TmpVectors.Matrix = ArrayTools.BuildArray(8, Matrix.Identity); // 8 temp Matrices at once should be enough
    return TmpVectors;
}());

So, TmpVectors.Matrix is created as soon as the code is parsed, meaning as soon as the babylon package is referenced by the script tag: it's before any user code could be executed, so before we run the Engine constructor.

Ok so let's keep the tracking and add a call to a function to construct the content
We should then create a ummy pg wth 20000 spheres where we call comptueWorldMatrix(true) on each frame so we can see if there is an impact (or not :))

I have simplified a bit, let me know what you think.
I did not create a separate "init" function (called by the constructor) because I think the current if (Matrix._TrackPrecisionChange) { should execute faster than a function call.
Also, I think having this as an option at engine construction is a good idea, that way we don't have to explain in docs that the user should call the SetPrecision method before creating the engine.
I will make the PG test quickly.

So, regarding performances, I used:

https://www.babylonjs-playground.com/#CM3M94#1 to test 32 bits
https://www.babylonjs-playground.com/#CM3M94 to test 64 bits

Of course, both are the same currently on the playground because the code is not deployed yet.
It is doing 200 x 100000 = 20M computeWorldMatrix(true).
So, on my computer with Chrome it is taking:

~12.5s on the playground (so with the existing code) and on my computer with the new code using 32 bits precision (so same perf for the same settings)
~11.5s on my computer when enabling 64 bits precision

I get roughly the same results with Firefox.

wait is it faster with 64bits????
Because then it will be even easier :)

I had to change:
    public setMatrix3x3(uniformName: string, matrix: Float32Array): Effect {
        this._valueCache[uniformName] = null;
        this._engine.setMatrix3x3(this._uniforms[uniformName], matrix);

        return this;
    }

to:
public setMatrix3x3(uniformName: string, matrix: Float32Array | Array<number>): Effect {
        this._valueCache[uniformName] = null;
        this._engine.setMatrix3x3(this._uniforms[uniformName], Array.isArray(matrix) ? new Float32Array(matrix) : matrix);

        return this;
    }

in Effect and ShaderMaterial.
However, there is a creation of a new Float32Array each time those functions are called, and this can be avoided.
Indeed, the final function called is uniformMatrix4fv which can take a regular array. So, we could do:
    public setMatrix3x3(uniformName: string, matrix: Float32Array | Array<number>): Effect {
        this._valueCache[uniformName] = null;
        this._engine.setMatrix3x3(this._uniforms[uniformName], matrix as Float32Array);

        return this;
    }

to make TS happy and still have th code working.
Note that it's already what happens:
    public setMatrix(uniformName: string, matrix: IMatrixLike): Effect {
        if (this._cacheMatrix(uniformName, matrix)) {
            this._engine.setMatrices(this._uniforms[uniformName], matrix.toArray() as Float32Array);
        }
        return this;
    }

toArray() now returns Float32Array | Array<number>, so in all strictness matrix.toArray() as Float32Array is wrong and we should check the type returned by toArray(). But as explained, those calls are used to update the matrix uniform, and the gl function also accepts a regular array, so the output of toArray() works in both cases.
Should I revert my changes and simply do a cast?

I have also updated the what's new file.

I have also updated the NullEngine class, I think I had to?

yep!

Wait..I thought we were not even using FLoat32 at all right? if number is faster why not simply using number all the time?

It is a fair point.. then let's keep as is. it is great but jsut remove the change on thinengine. I do not want to incresae its size with matrix.
thinengine will only use float32 this is fine

thinengine will only use float32 this is fine

There's a problem because the matrix instances are tracked, and it's when calling Matrix.SetPrecision that the tracking is disabled...
So, if I remove the call from the ThinEngine constructor to move it to Engine, all matrix instances will be tracked if one use ThinEngine and not Engine, which we don't want... But is it even leggit to create a ThinEngine instance?

I guess the error I get in the Module Tests step is linked to ThinEngine now importing vector math:
[18:10:47] New size: 167005 bytes is bigger than baseline size : 116308 bytes on thinEngineOnly.

?

If you don't want ThinEngine to link to math, then I don't see any other solution than switchin the matrix type to Array unconditionnally and removing Float32Array support as you suggested above...

Yes even broader like PerformanceConfigurator (pinging @sebavan for other ideas :)) so we can in the future define there other options

Something like that:
/** @hiddden */
export class PerformanceConfigurator {
    /** @hidden */
    public static MatrixUse64Bits = false;
    /** @hidden */
    public static MatrixTrackPrecisionChange = true;
    /** @hidden */
    public static MatrixCurrentType: any = Float32Array;
    /** @hidden */
    public static MatrixTrackedMatrices: Array<any> | null = [];

    /** @hidden */
    public static SetMatrixPrecision(use64bits: boolean) {
        PerformanceConfigurator.MatrixTrackPrecisionChange = false;

        if (use64bits && !PerformanceConfigurator.MatrixUse64Bits) {
            if (PerformanceConfigurator.MatrixTrackedMatrices) {
                for (let m = 0; m < PerformanceConfigurator.MatrixTrackedMatrices.length; ++m) {
                    const matrix = PerformanceConfigurator.MatrixTrackedMatrices[m];
                    const values = matrix._m;

                    matrix._m = new Array(16);

                    for (let i = 0; i < 16; ++i) {
                        matrix._m[i] = values[i];
                    }
                }
            }
        }

        PerformanceConfigurator.MatrixUse64Bits = use64bits;
        PerformanceConfigurator.MatrixCurrentType = PerformanceConfigurator.MatrixUse64Bits ? Array : Float32Array;
        PerformanceConfigurator.MatrixTrackedMatrices = null; // reclaim some memory, as we don't need _TrackedMatrices anymore
    }
}

Should I add the file to the Engine directory?

Easier to ask forgiveness than permission, so I performed the changes, let me know if it's ok :)

There's no measurable difference in perf between applying this latest change or not, so the measuring given a number of posts above still hold.

Good job as always buddy! thanks!
waiting for the tests to end and I'll merge


x509 certificate signed by unknown authority

Describe the bug
After deleting a broker, jetstream controller can not do finalization of underlying channel because of comminication error with nats-webhook.
Expected behavior
Broker/channel delete is working.
Knative release version
1.3.2
Additional context
eventing-natss version is 1.3.5
I create a broker and then deleted it, then observed that channel has not been deleted. And observer error logs.
jetstream-channel-controller:
{
    "level": "error",
    "ts": "2022-12-23T11:30:23.039Z",
    "logger": "jetstream-channel-controller",
    "caller": "controller/controller.go:559",
    "msg": "Reconcile error",
    "knative.dev/pod": "jetstream-ch-controller-57c65d84fb-5p5pm",
    "knative.dev/controller": "knative.dev.eventing-natss.pkg.channel.jetstream.controller.Reconciler",
    "knative.dev/kind": "messaging.knative.dev.NatsJetStreamChannel",
    "knative.dev/traceid": "b83875e4-319c-447c-ae15-0cff0e8ab9e3",
    "knative.dev/key": "viax/internal-kne-trigger",
    "duration": 0.049331877,
    "error": "failed to clear finalizers: Internal error occurred: failed calling webhook \"webhook.nats.messaging.knative.dev\": Post \"https://nats-webhook.knative-eventing.svc:443/defaulting?timeout=2s\": x509: certificate signed by unknown authority (possibly because of \"x509: ECDSA verification failure\" while trying to verify candidate authority certificate \"nats-webhook.knative-eventing.svc\")",
    "stacktrace": "knative.dev/pkg/controller.(*Impl).handleErr\n\tknative.dev/pkg@v0.0.0-20220301181942-2fdd5f232e77/controller/controller.go:559\nknative.dev/pkg/controller.(*Impl).processNextWorkItem\n\tknative.dev/pkg@v0.0.0-20220301181942-2fdd5f232e77/controller/controller.go:536\nknative.dev/pkg/controller.(*Impl).RunContext.func3\n\tknative.dev/pkg@v0.0.0-20220301181942-2fdd5f232e77/controller/controller.go:484"
}

and nats-webhook logs:
{"level":"info","ts":"2022-12-23T13:40:55.322Z","logger":"nats-webhook","caller":"webhook/admission.go:90","msg":"Webhook ServeHTTP request=&http.Request{Method:\"POST\", URL:(*url.URL)(0xc000a02cf0), Proto:\"HTTP/1.1\", ProtoMajor:1, ProtoMinor:1, Header:http.Header{\"Accept\":[]string{\"application/json, */*\"}, \"Accept-Encoding\":[]string{\"gzip\"}, \"Content-Length\":[]string{\"37445\"}, \"Content-Type\":[]string{\"application/json\"}, \"User-Agent\":[]string{\"kube-apiserver-admission\"}}, Body:(*http.body)(0xc0008b7700), GetBody:(func() (io.ReadCloser, error))(nil), ContentLength:37445, TransferEncoding:[]string(nil), Close:false, Host:\"nats-webhook.knative-eventing.svc:443\", Form:url.Values(nil), PostForm:url.Values(nil), MultipartForm:(*multipart.Form)(nil), Trailer:http.Header(nil), RemoteAddr:\"<IP_ADDRESS>:38352\", RequestURI:\"/defaulting?timeout=2s\", TLS:(*tls.ConnectionState)(0xc00019d6b0), Cancel:(<-chan struct {})(nil), Response:(*http.Response)(nil), ctx:(*context.cancelCtx)(0xc0008b7740)}"}
{"level":"info","ts":"2022-12-23T13:40:55.341Z","logger":"nats-webhook","caller":"defaulting/defaulting.go:158","msg":"Kind: \"messaging.knative.dev/v1alpha1, Kind=NatsJetStreamChannel\" PatchBytes: null","knative.dev/kind":"messaging.knative.dev/v1alpha1, Kind=NatsJetStreamChannel","knative.dev/namespace":"viax","knative.dev/name":"internal-kne-trigger","knative.dev/operation":"UPDATE","knative.dev/resource":"messaging.knative.dev/v1alpha1, Resource=natsjetstreamchannels","knative.dev/subresource":"","knative.dev/userinfo":"{system:serviceaccount:knative-eventing:jetstream-ch-controller 1d7b066d-347a-4466-9374-fcf4d8529081 [system:serviceaccounts system:serviceaccounts:knative-eventing system:authenticated] map[authentication.kubernetes.io/pod-name:[jetstream-ch-controller-57c65d84fb-fw8td] authentication.kubernetes.io/pod-uid:[a05e83d6-0041-4728-b9d6-aab1ead4b94c]]}"}
{"level":"info","ts":"2022-12-23T13:40:55.341Z","logger":"nats-webhook","caller":"webhook/admission.go:133","msg":"remote admission controller audit annotations=map[string]string(nil)","knative.dev/kind":"messaging.knative.dev/v1alpha1, Kind=NatsJetStreamChannel","knative.dev/namespace":"viax","knative.dev/name":"internal-kne-trigger","knative.dev/operation":"UPDATE","knative.dev/resource":"messaging.knative.dev/v1alpha1, Resource=natsjetstreamchannels","knative.dev/subresource":"","knative.dev/userinfo":"{system:serviceaccount:knative-eventing:jetstream-ch-controller 1d7b066d-347a-4466-9374-fcf4d8529081 [system:serviceaccounts system:serviceaccounts:knative-eventing system:authenticated] map[authentication.kubernetes.io/pod-name:[jetstream-ch-controller-57c65d84fb-fw8td] authentication.kubernetes.io/pod-uid:[a05e83d6-0041-4728-b9d6-aab1ead4b94c]]}","admissionreview/uid":"f32148bf-86b0-465a-b048-133d866910d3","admissionreview/allowed":true,"admissionreview/result":"nil"}
{"level":"debug","ts":"2022-12-23T13:40:55.341Z","logger":"nats-webhook","caller":"webhook/admission.go:134","msg":"AdmissionReview patch={ type: JSONPatch, body: null }","knative.dev/kind":"messaging.knative.dev/v1alpha1, Kind=NatsJetStreamChannel","knative.dev/namespace":"viax","knative.dev/name":"internal-kne-trigger","knative.dev/operation":"UPDATE","knative.dev/resource":"messaging.knative.dev/v1alpha1, Resource=natsjetstreamchannels","knative.dev/subresource":"","knative.dev/userinfo":"{system:serviceaccount:knative-eventing:jetstream-ch-controller 1d7b066d-347a-4466-9374-fcf4d8529081 [system:serviceaccounts system:serviceaccounts:knative-eventing system:authenticated] map[authentication.kubernetes.io/pod-name:[jetstream-ch-controller-57c65d84fb-fw8td] authentication.kubernetes.io/pod-uid:[a05e83d6-0041-4728-b9d6-aab1ead4b94c]]}","admissionreview/uid":"f32148bf-86b0-465a-b048-133d866910d3","admissionreview/allowed":true,"admissionreview/result":"nil"}
2022/12/23 13:40:55 http: TLS handshake error from <IP_ADDRESS>:50934: remote error: tls: bad certificate

is it really certificate problem? one strange thing is this message: AdmissionReview patch={ type: JSONPatch, body: null } from the last debug log before error log remote error: tls: bad certificate
Any thoughts?
cc
@dan-j
@lionelvillard
@zhaojizhuang

It looks like similar to https://github.com/tektoncd/triggers/issues/875
Few things I'm trying to understand:

Does it really do anything usefull? I'm looking at stub code and can not get what does it do https://github.com/knative-sandbox/eventing-natss/blob/release-1.3/pkg/webhook/controller.go
Could it happen because of we added cert manager?
I've checked this https://github.com/tektoncd/triggers/issues/875#issuecomment-997084884 and I see the same ValidatingWebhookConfiguration caBundle is the same as secret nats-webhook-certs ca-cert.pem, so it is not the case then?

Another thing is from webhook.Options
	// SecretName is the name of k8s secret that contains the webhook
	// server key/cert and corresponding CA cert that signed them. The
	// server key/cert are used to serve the webhook and the CA cert
	// is provided to k8s apiserver during admission controller
	// registration.
	// If no SecretName is provided, then the webhook serves without TLS.
	SecretName string

and webhook has secretname hardcoded
const (
	// Component is the name of this component and is used in logging and leader-election
	Component = "nats-webhook"

	// SecretName must match the name of the Secret created in the configuration.
	SecretName = "nats-webhook-certs"
)

We have mTLS and using istio, then we do not need webhook tls at all and we can not change that. Do we need to make it optional, like NameFromEnv() maybe have SecretNameFromEnv() ?

Ok, we found a way how to reproduce it:

provision eventing jsm as normal (from https://github.com/knative-sandbox/eventing-natss/releases/download/knative-v1.3.5/eventing-jsm.yaml)
observe that evething is working, e.g. create/delete a broker
delete nats-webhook-certs secret or it's data
see nats-webhook reconcile it successfully
create e.g. a broker, now nats-webhook writes errror

{"level":"error","ts":"2022-12-27T13:24:11.453Z","logger":"nats-webhook.DefaultingWebhook","caller":"controller/controller.go:559","msg":"Reconcile error","knative.dev/traceid":"d2b98046-a51c-4912-aa27-c3ff928d9501","knative.dev/key":"defaulting.webhook.nats.messaging.knative.dev","duration":0.000133991,"error":"error retrieving webhook: mutatingwebhookconfiguration.admissionregistration.k8s.io \"defaulting.webhook.nats.messaging.knative.dev\" not found","stacktrace":"knative.dev/pkg/controller.(*Impl).handleErr\n\tknative.dev/pkg@v0.0.0-20220301181942-2fdd5f232e77/controller/controller.go:559\nknative.dev/pkg/controller.(*Impl).processNextWorkItem\n\tknative.dev/pkg@v0.0.0-20220301181942-2fdd5f232e77/controller/controller.go:536\nknative.dev/pkg/controller.(*Impl).RunContext.func3\n\tknative.dev/pkg@v0.0.0-20220301181942-2fdd5f232e77/controller/controller.go:484"}
2022/12/27 13:36:29 http: TLS handshake error from <IP_ADDRESS>:49317: remote error: tls: bad certificate

After above steps we can not fix badcertificate problem. Tried to delete pods, deployments, restarting webhook and controller, nothing helps.

@zhaojizhuang , @lionelvillard , do you any ideas how to fix that? Is there any caching of certificates somewhere?

Hi @astelmashenko  encountered this error, just delete and recreate webhook validation and mutation resolve the problem
This will force to recreate cert webhook

new investigations, according to logs:
{"level":"info","ts":"2022-12-28T16:32:44.280Z","logger":"nats-webhook","caller":"webhook/admission.go:90","msg":"Webhook ServeHTTP request=&http.Request{Method:\"POST\", URL:(*url.URL)(0xc000949830), Proto:\"HTTP/1.1\", ProtoMajor:1, ProtoMinor:1, Header:http.Header{\"Accept\":[]string{\"application/json, */*\"}, \"Accept-Encoding\":[]string{\"gzip\"}, \"Content-Length\":[]string{\"37445\"}, \"Content-Type\":[]string{\"application/json\"}, \"User-Agent\":[]string{\"kube-apiserver-admission\"}}, Body:(*http.body)(0xc0009ba980), GetBody:(func() (io.ReadCloser, error))(nil), ContentLength:37445, TransferEncoding:[]string(nil), Close:false, Host:\"nats-webhook.knative-eventing.svc:443\", Form:url.Values(nil), PostForm:url.Values(nil), MultipartForm:(*multipart.Form)(nil), Trailer:http.Header(nil), RemoteAddr:\"<IP_ADDRESS>:52401\", RequestURI:\"/defaulting?timeout=2s\", TLS:(*tls.ConnectionState)(0xc00083fc30), Cancel:(<-chan struct {})(nil), Response:(*http.Response)(nil), ctx:(*context.cancelCtx)(0xc0009ba9c0)}"}
{"level":"info","ts":"2022-12-28T16:32:44.297Z","logger":"nats-webhook","caller":"defaulting/defaulting.go:158","msg":"Kind: \"messaging.knative.dev/v1alpha1, Kind=NatsJetStreamChannel\" PatchBytes: null","knative.dev/kind":"messaging.knative.dev/v1alpha1, Kind=NatsJetStreamChannel","knative.dev/namespace":"viax","knative.dev/name":"internal-kne-trigger","knative.dev/operation":"UPDATE","knative.dev/resource":"messaging.knative.dev/v1alpha1, Resource=natsjetstreamchannels","knative.dev/subresource":"","knative.dev/userinfo":"{system:serviceaccount:knative-eventing:jetstream-ch-controller eabc9d9c-bfc6-4410-932f-3e37b5aa6b15 [system:serviceaccounts system:serviceaccounts:knative-eventing system:authenticated] map[authentication.kubernetes.io/pod-name:[jetstream-ch-controller-57c65d84fb-9h2c7] authentication.kubernetes.io/pod-uid:[d0e2ebd1-aa22-4700-823f-cea550500b29]]}"}
{"level":"info","ts":"2022-12-28T16:32:44.297Z","logger":"nats-webhook","caller":"webhook/admission.go:133","msg":"remote admission controller audit annotations=map[string]string(nil)","knative.dev/kind":"messaging.knative.dev/v1alpha1, Kind=NatsJetStreamChannel","knative.dev/namespace":"viax","knative.dev/name":"internal-kne-trigger","knative.dev/operation":"UPDATE","knative.dev/resource":"messaging.knative.dev/v1alpha1, Resource=natsjetstreamchannels","knative.dev/subresource":"","knative.dev/userinfo":"{system:serviceaccount:knative-eventing:jetstream-ch-controller eabc9d9c-bfc6-4410-932f-3e37b5aa6b15 [system:serviceaccounts system:serviceaccounts:knative-eventing system:authenticated] map[authentication.kubernetes.io/pod-name:[jetstream-ch-controller-57c65d84fb-9h2c7] authentication.kubernetes.io/pod-uid:[d0e2ebd1-aa22-4700-823f-cea550500b29]]}","admissionreview/uid":"61b4f1df-0e47-484c-98ce-c064e6cd9e68","admissionreview/allowed":true,"admissionreview/result":"nil"}
2022/12/28 16:32:44 http: TLS handshake error from <IP_ADDRESS>:45837: remote error: tls: bad certificate

webhook receives request and admission.go admissionHandler is called. It mean that error happens it tries to write response back?

One more thing is I'm able to reproduce it on working cluster only, which is 1.21 version. It does not reproduce on 1.23 local minikube setup.

oh, god, I found the issue. There was MutatingWebhookConfiguration left from previous installation of eventing-natss.yaml, it's name was webhook.nats.messaging.knative.dev and then it got renamed to defaulting.webhook.nats.messaging.knative.dev.


How to add "MarkerClusterer"?

How can I add "MarkerClusterer" to map instance?

This is unfortunately not supported yet. But considering how popular this feature seems to be I'll look into adding it when I have some spare time.

@asoltani927 thanks for adding this request, I also need this functionality in my project. but it seems that it is not supported.
@HusamIbrahim  can you please share any status related this ?

@HusamIbrahim This package needs cluster support so badly.... please can you add it?

I'll hopefully take a stab at it this weekend

Added in v0.11.0. Basic syntax is:
<MarkerCluster>
  <Marker v-for="(location, i) in locations" :options="{ position: location }" :key="i" />
</MarkerCluster>

Documentation to be added soon

@HusamIbrahim Thanks for adding this!
I've given it a try and can confirm it is working with regular markers. However it isn't working with custom markers from the vue3-gmap-custom-marker library
With regular markers I see the clusters but with the custom markers, which are otherwise working, when I add your MarkerCluster then all my custom markers just disappear

@HusamIbrahim That would be great if you could add custom markers natively.
Previously I was using gmap-vue in combination with vue2-gmap-custom-marker, and since gmap-vue has issues with their native clusters, I was actually pulling in the cluster from vue2-google-maps. Seems a bit chaotic.. yet somehow it just worked anyway.
Based on that, I would imagine that it would be possible to make your clusters work with vue3-gmap-custom-marker, or maybe that author would need to add support. Either way, as much as I need the cluster functionality, I cannot give up my custom markers so I will have to wait some more until this is possible.
Many thanks!

@vesper8 These libraries being forks might explain the compatibility in that case 🙂
I would try reaching out to vue3-gmap-custom-marker's author to see if he can make it work. The readme points to the lack of clustering support in this library but leaves open the possibility of adding support on their end:
https://github.com/eregnier/vue3-gmap-custom-marker#features
Again this is only if you need it urgently. I'll have custom markers implemented natively in this library eventually.

@HusamIbrahim I bet you could have custom markers implemented in 30 minutes ;-)

@vesper8 Custom markers added in v0.12.0
https://github.com/inocan-group/vue3-google-map#custom-marker


Add interfaces for Multicall, Multicall2, and Multicall3

As discussed in #53, providing interfaces is necessary so that this repo can be imported and used in a Foundry project.
New files:

interfaces/IMulticall.sol
interfaces/IMulticall3.sol
interfaces/IMulticall3.sol

I have moved the structs in these files so that they are not duplicated, and have updated the tests to use the structs from here.
Note: I have formatted the interfaces with forge fmt using this configuration.

If this is merged, the commits should be squashed to avoid giving the impression in the git history that the src contracts have ever changed.

Good call, will definitely squash. I think previously you had updated tests to use e.g. IMulticall3.Call3Value[] instead of Multicall3.Call3Value[], which seemed like a good sanity check on the interface correctness. Would you mind adding that back? If you prefer I'm happy to make those final changes before merging, since I appreciate all your recent contributions

Unfortunately, we cannot use the interface structs in the tests. I just tried and got this error:
Compiler run failed
error[9553]: TypeError: Invalid type for argument in function call. Invalid implicit conversion from struct IMulticall.Call memory[] memory to struct Multicall.Call memory[] memory requested.
  --> src/test/Multicall.t.sol:25:76:
   |
25 |     (uint256 blockNumber, bytes[] memory returnData) = multicall.aggregate(calls);
   |


How Can I setup ServiceMonitor if applications are routing through a API gateway.

What did you do?
I have may applications on Kuberentes and they are routed through a API Gateway.
What did you expect to see?
I have need to add service monitor for my application,but since they are routed through API Gateway,I have to setup service monitor for that routing app.
What did you see instead? Under which circumstances?
So,when my application is deleted,the alert came as the main routing app is down. How can I add service monitor for each app when, they are  are routing through a API gateway
Environment
GCP

Kubernetes version information:
insert output of kubectl version here

Kubernetes cluster kind:
insert how you created your cluster: kops, bootkube, tectonic-installer, etc.

Manifests:

insert manifests relevant to the issue

Prometheus Operator Logs:

insert Prometheus Operator logs relevant to the issue here

I have need to add service monitor for my application,but since they are routed through API Gateway,I have to setup service monitor for that routing app.

This sounds like you are not performing whitebox monitoring. Could you elaborate on what your architecture looks like? Generally the recommendation is to have the Prometheus server as close to the target as possible with as little indirections inbetween as possible. Ideally there is no proxy or anything in between the target and Prometheus and Prometheus directly requests the target's IP.

Hi brancz,
We are using Kong API Gateway as a  middleware for our  API-based applications. Could you please share me a useful link for configuring  Whitebox monitoring in this Prometheus setup.

Hi, Please close this issue, It is fixed :)


feat: Add maven package ecosystem detection

Pull Request

Proposed Changes
Add support for maven package ecosystem to be detected by pom.xml file in root of repositories.
Readiness Checklist
Author/Contributor

[x] If documentation is needed for this change, has that been included in this pull request
[x] run make lint and fix any issues that you have introduced
[x] run make test and ensure you have test coverage for the lines you are introducing
[x] If publishing new data to the public (scorecards, security scan results, code quality results, live dashboards, etc.), please request review from @jeffrey-luszcz

Reviewer

[ ] Label as either fix, documentation, enhancement, infrastructure, maintenance or breaking

Thanks for submitting this pull request! I appreciate the effort to expand the supported package ecosystems. I think it's a great idea to add support for maven! Can we add some test cases to cover this package manager so we can maintain confidence that future changes don't break this new functionality?

Thanks, I added a basic test case for maven package manager. If you have further test cases in mind please let me know.


Update

Would it be possible to publish an update on from the latest SDE? The latest update should have for blueprint 57516, the material type 3645 in quantity 1250.

I get waaay too many github notices and never saw this - looks like travis-ci.org fully shut down so the autoupdate cron job is dead; I'll need to migrate to a github action.

That would be great if it could :)

That would be great if it could, I'd love to use this as an automagic dependency rather than do it myself.

I doubt anyone cares, but I've had this nagging me at the end of my TODO list for years - finally got around to migrating to an action today. Once again, this repo and npm package should auto-update. Probably. After a short 2.5-year gap.


External DTD problem

After added in my pom the quarkus-cxf dependency, I receive a Fatal Error when building with quarkus-maven-plugin:
[Fatal Error] :20:70: External DTD: Failed to read external DTD 'properties.dtd', because 'http' access is not allowed due to restriction set by the accessExternalDTD property.
I tried to set the JVM arg -Djavax.xml.accessExternalDTD=all or -Djavax.xml.accessExternalDTD=http and -Djavax.xml.accessExternalSchema=all but nothing solved the issue.
I'm using quarkus-cxf version 1.7.2 and quarkus platform version 2.15.0.Final.
I noticed that the 'properties.dtd' is the one referenced in the wsdl.plugin.xml file inside cxf-rt-bindings-soap-3.5.5 jar (https://github.com/apache/cxf/blob/main/rt/bindings/soap/src/main/resources/META-INF/wsdl.plugin.xml)
and I also receive a warning after the fatal error:
[WARNING] [io.quarkiverse.cxf.deployment.QuarkusCxfProcessor] can not merge wsdl.plugin.xml
I'm building an uber-jar (don't know if it is relevant)
How can I solve the issue?
Thanks

Hi @asyle83 The reason non of the JVM args work is because we currently explicitly disable external DTD processing in the code.
The referenced PR should address this issue.

@shumonsharif  thanks! Witch platform version will contains this fix? Or how can I take it? Thanks

@ppalaga and @famod handle the releases these days, so perhaps they can help you with your question.

Having this in 1.7.3 would be logical (for me). Right now we are having some release/build issues and Peter seems to enjoy some time off screen.

Ok @famod, I'll wait for next release... Hope you'll solve build issues soon :)

@famod any news about the release? :)

@asyle83 we are having some issues with the test setup (follow #669 if you are interested in details). Sorry for the delay.

@asyle83 1.7.3 is now available and should fix this problem.

Thanks it worked ;)


Wrong link in docs

Hi! Thanks for the awesome project!
In Tutorial paths section of the docs Create some clipping planes subsection leads to the SimpleRaycaster example instead of SimpleClipper.

Fixed! Thanks


Segmentation fault on CentOS and Debian

The tool works great on Ubuntu however we're experiencing crashes on CentOS and Debian. I've included 2 patched binaries one created under latest Debian and another created under Centos 6.10. Let us know if there is anything we can do to help.
debian-ls-patched-crashing.gz
centos-ls-patched-crashing.gz
[root@localhost drow]# cp /bin/ls ./
cp: overwrite `./ls'? y
[root@localhost drow]# ./build/drow ls ./build/rappers_delight.bin ls-bd
____  ____  _____  _    _
(  _ (  _ (  _  )( // )
)() ))   / )()(  )    (
(__/()_)(___)(/_)
[] Mapping file: ls
[] Mapping file: ./build/rappers_delight.bin
[] Finding last section in executable segment ...
[+] Found executable segment at 0x00000040 (size:000001c0)
[+] Found executable segment at 0x00000000 (size:0001851c)
[+] Found .eh_frame at 0x00016540 with a size of 8156 bytes
[] Expanding .eh_frame size by 8192 bytes...
[] Adjusting Section Header offsets ...
[] Adjusting Program Header offsets ...
[] Adjusting ELF header offsets ...
[] Modifying ELF e_entry to point to the patch at 0x0001851c ...
[] Exporting patched ELF to ls-bd ...
[] Writing first part of ELF (size: 99612)
[] Setting old and new e_entry values in stager ...
[] Writing stager stub (size: 49) ...
[] Writing patch/payload (size: 289)
[] Writing pad to maintain page alignment (size: 7854)
[*] Writing remaining data (size: 9596)
[+] ELF patched successfully!
[root@localhost drow]# ./ls-bd
Segmentation fault (core dumped)

Bummer, due to a limitations in the technique that drow uses there must be atleast a page (4096 bytes) of slack space between the end of the RX segment and the start of the next segment.
So, what is likely occuring is it is successfully injecting the code into the binary and adjusting the offsets. However, the .fini and the .rodata sections have overlapping virtual mappings (see below). The dynamic linker is likely trying to map the .fini section overtop of part of the .rodata section. Causing it to crash.

This is likely not an issue with the binaries tested on Ubuntu because either the RX segment was the last segment in the binary, or there was plenty of slack space between where the RX segment is mapped relative to where the next segment is mapped in memory. I will modify drow to error out under these conditions.

Checkout 2-overlapping-mapping-check, build it, and try to run it against your version of ls again. I expect it to bail and not create the patched binary. Also, would you mind sharing the unmodified version of those binaries? I'd like to look into how I can still make it work. With position-independent binaries I could likely modify the DT_DYNAMIC entries to move around segments. Unfortunately you can't do that with position-dependent binaries.

Thanks for looking into this. I just checked out the new branch it does indeed throw an error and bails out. I've also attached the ls binaries from Centos 6.0 and latest Debian.
centos_ls.gz
debian_ls.gz
[user@localhost build]$ ./drow ls ./rappers_delight.bin ls-bd
____  ____  _____  _    _
(  _ (  _ (  _  )( // )
)() ))   / )()(  )    (
(__/()_)(___)(/_)
[] Mapping file: ls
[] Mapping file: ./rappers_delight.bin
[*] Finding last section in executable segment ...
[+] Found executable segment at 0x00000040 (size:000001c0)
[!] RX segment is not injectable. Must contain atleast 4096 bytes of slack space before next segment mapping

Backdoor Factory for example tries to fit within code caves without expanding the size of segments. I'll likely add a feature that first checks if the payload can fit in the slack space between two sections in the RX segment or at the end of the RX segment on the last page of memory. If it won't fit, then it will check if it can expand the size of the RX segment without overlapping with the next segment. Unfortunetely, I don't think I'll have time to look at this until atleast Friday. I'll let you know when I have something worth testing.

@EMCELLY I've just pushed code that works for your debian ls binary (I did not test with CentOS). Pull latest on 2-overlapping-mapping-check. See the commit here:
https://github.com/zznop/drow/pull/3/commits/7b8bd9c2ca8388f6f43e9cfd4d9a8e7cd164b47c
This adds a second technique. Drow now attempts to inject at the end of the last page of the RX segment without expanding. If the payload won't fit, it will determine whether or not it's safe to expand the segment. If it can safely expand the segment it will do so and inject in the newly added pages. Otherwise, it will bail.
I have not tested if there are any regressions with the Ubuntu binaries as a result of this change. Please try out the changes and let me know if you have any issues.

I did some quick testing here are the results.
Centos 8.1 - works as expected.
Ubunutu 18 - segfault in drow
Ubuntu 16 - segfault in drow
Centos 7.-0 - segfault in drow
Centos 6.0 - segfault in drow
Attaching some gdb logs and a core file since they all seem to be the same issue.
core.15948.gz
ubuntu-18.crash.txt
ubuntu-16.crash.txt
centos-7.0.crash.txt
centos-6.0-crash.txt


Update README to latest version

Nice library, exactly what I needed, thanks!
Here's a minor fix: setting the latest version number in the README.

Oh, the 1.4.1. is not yet released to Maven Central. Or is there no 1.4.1 'release' yet? I just triggered on the latest version config in gradle to guess the latest release.

Nvm, I see now it's just there for the next version to release in the future.


Update process-security-and-access-rights.md

Fix the formatting of the enumerations at the bottom of the page.

@turingcompl33t : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off


Add ability to enter public key for recipient address manually

Is your feature request related to a problem? Please describe.
When a message is sent to an address that has not sent a transaction, the mailchain application returns an error.
Describe the solution you'd like
A user should be able to specify the public key that matches the recipient address.
Additional context
related to issue: #35

Closing due to archiving repository


Builtin SHA256 hashing

Expose the functionality of Zig's std.crypto.hash.sha2.Sha256 through a pure-functional interface to Roc.
Not currently working.

@MatthewJohnHeath I tried to push to your branch but I got permission denied. Made a PR in case that helps.

Hi Luke,
Sorry I'm slow to respond. I've been travelling. There are definitely some
problems on the branch; it builds but then in the REPL the functions seem
to be missing (although triggering a different error to actually
non-existent function names). I created the initial PR mostly in order to
get feedback on what might be wring (I was also expecting to be able to get
more time online these couple of weeks).
I think I am going to need some help to get it working.
On Wed, 14 Aug 2024 at 02:26, Luke Boswell @.***> wrote:

@MatthewJohnHeath https://github.com/MatthewJohnHeath I tried to push
to your branch but I got permission denied. Made a PR in case that helps.
—
Reply to this email directly, view it on GitHub
https://github.com/roc-lang/roc/pull/6977#issuecomment-2287656759, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AEZKVQQ7LL7GIFEDIJSQHBTZRKW3PAVCNFSM6AAAAABMI4AGLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBXGY2TMNZVHE
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Matthew Heath http://mattheath.wordpress.com

The shape of this PR is a good start, but I'm seeing a potential issue if we add other cryptographic code to this module, which would be quite unsurprising. You have emptySha256, addBytes, and digest. The first is named based on the hash, but the second and third are nominally agnostic to the hash, but only work for SHA-256. Could you rename them to addBytesSha256 or something similar?

Otherwise, I'm attempting to get things running

Okay, I'm almost done getting this working, just need to coordinate the Zig and Roc builtin types.

The REPL worked for me! We'll still need some tests, but it should be good to go, above comments notwithstanding.

Also, there's no code currently to extract state from the new Digest256 opaque type. Could you add a function or something to do that? Maybe Crypt.digest256ToBytes : Digest256 -> List U8?

Also, there's no code currently to extract state from the new Digest256 opaque type. Could you add a function or something to do that? Maybe Crypt.digest256ToBytes : Digest256 -> List U8?

I was thinking of  (only) having the type implement  Eq. Can you think of use cases where the individual bytes would be needed?

I was thinking of (only) having the type implement Eq. Can you think of use cases where the individual bytes would be needed?

If I want to store the hash for future comparison. Not that using SHA-256 would be recommended over Argon2, but the idea holds. There are a few algorithms out there that use SHA-256 digest bytes for computation (Wikipedia), at least UUID v5 uses SHA-1 in that way.

Tests are currently failing. @MatthewJohnHeath do you have time to implement the above fixes any time soon? If not, I can help, but it's your PR, so I'll defer to you.

Tests are currently failing. @MatthewJohnHeath do you have time to implement the above fixes any time soon? If not, I can help, but it's your PR, so I'll defer to you.

@smores56 It's not really clear to me why the build is hanging (which seems to be what is happening). I will try a few things, but might need to ask for help

@smores56 It's building now. Hopefully I can do those last  2  renamings of functions you asked for tomorrow.

If this gets through the tests, would it be to merge and then do docs and tests? Or do those need to be there first?

It's always preferable to do at least testing, but ideally also docs, in the same PR. We'd usually avoid them if they're going to make the PR too big, or if they're blocking us merging an important change/bug fix. Since it's neither of those, I'd prefer if we can get them in this change. I'm happy to help with either the tests or docs!

This all looks great! A heads up, we're considering how we should name the module Crypt in Zulip, but that would if anything change things after this PR.

The test that is blocking merge is unrelated, I'll look into unblocking this PR on Sunday, unless someone else gets the chance to fix this before then.

I'm a little concerned nothing seemed to fail as a result of fromHexString having been wrong. Is there a known reason that the "expects" in Crypt.roc wouldn't be checked?

So I made progress on running things. Tests are running for the builtins, and there is some LLVM issue I'll have to investigate tomorrow:
smores@smortress:~/dev/roc$ cargo run --release --bin roc -- test crates/compiler/builtins/roc/Crypt.roc
    Finished release [optimized] target(s) in 0.16s
     Running `target/release/roc test crates/compiler/builtins/roc/Crypt.roc`
Call parameter type does not match function signature!
%list.RocList %"#arg2"
 ptr  %call_builtin = call i64 @roc_builtins.crypt.sha256AddBytes(i64 %"#arg1", %list.RocList nocapture nonnull readonly byval(%list.RocList) %"#arg2"), !dbg !1635

Function "Crypt_sha256AddBytes_ade2dc9e385e74c61c8d36210907131d7823a7fe8d06c7bd978c1f46a9d3830" failed LLVM verification in NON-OPTIMIZED build. Its content was:

define internal fastcc i64 @Crypt_sha256AddBytes_ade2dc9e385e74c61c8d36210907131d7823a7fe8d06c7bd978c1f46a9d3830(i64 %"#arg1", %list.RocList %"#arg2") !dbg !1634 {
entry:
  %call_builtin = call i64 @roc_builtins.crypt.sha256AddBytes(i64 %"#arg1", %list.RocList nocapture nonnull readonly byval(%list.RocList) %"#arg2"), !dbg !1635
  ret i64 %call_builtin, !dbg !1635
}
thread 'main' panicked at crates/compiler/gen_llvm/src/llvm/build.rs:5810:21:
😱 LLVM errors when defining function "Crypt_sha256AddBytes_ade2dc9e385e74c61c8d36210907131d7823a7fe8d06c7bd978c1f46a9d3830"; I wrote the full LLVM IR to "/tmp/nix-shell.7F740v/test.ll"
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I've been distracted, but I'll be looking at this again today. I might have to ask for help from @bhansconnect since I'm not much of an LLVM guy, which seems to be the last issue here. Needless to say, @MatthewJohnHeath there's nothing left that you need to do on this PR. If you have any changes you want to make, feel free, but otherwise I'm planning on merging as soon as I fix the LLVM issue.

I merged in main, renamed to Crypto, fixed the LLVM issues (I think -- at least it's compiling now).

I had a brief crack at the suggestion from @bhansconnect to change to [7]u128 align(16) but my zig foo isn't up to scratch.

I hadn't noticed this was in progress again. I will see if I can work out what is going on

@lukewilliamboswell I meant to rebase all of this to the current upstream and then force push, but I messed it up and lost your 3 recent commits. Sorry. Could you please push them again please?

@MatthewJohnHeath -- thank you for your patience with this one. 😃
I'm really looking forward to having this in the builtins, and laying the foundation for more cryptographic primitives.

The bug was it converting u128 to bytes as big-endian, which was (almost always) wrong
Now it converts them as little-endian and the test spass (on my  computer, and presumably almost all others).
But it probably should also support builds for big-endian machines
@lukewilliamboswell would trying to merge it like this and raising a separate ticket to fix it for bi-endian architectures be reasonable?

I'm having some issues with memory running tests locally. There seems to be a failure in crates/repl_test/src/tests.rsand I can't see how it would be related

I am having some trouble running test locally (insufficient disc space). There seems to be a failure in interpolation_with_nested_strings. I can't see how that could be related.

I am having some trouble running test locally (insufficient disc space). There seems to be a failure in interpolation_with_nested_strings. I can't see how that could be related.

Oh I think it must be related. I didn't realise how early in the process that test was. I will try to unpick it sometime this week


[Frontend] Added frontend with list product & create product

it appears that you haven't run the following command from oursky's create-react-app https://github.com/oursky/create-react-app-oursky when this frontend was set up
curl -sSL https://raw.githubusercontent.com/oursky/create-react-app-oursky/master/bootstrap.py | python3 - .

@MartinLam-Oursky to share styles, look for @mixin and @include in https://sass-lang.com/guide
css-module: https://github.com/css-modules/css-modules


⚠ Bofrost.es has degraded performance

In 02cc899, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1339 ms

Resolved: Bofrost.es performance has improved in f19cea3 after 6 minutes.


introduction

I am Santiago García Espinosa, I am 18 years old, I study as a technologist in Analizis and software development at SENA Colombia.
Looking for more ways to learn incontre. Binary Studio Academy and it motivated me to participate to consolidate knowledge and learn new things that serve me in my work and professional environment


new(cli): Introduce eofwrap tool

🗒 Description
There are many general EVM tests in ethereum/tests which provide coverage for opcodes and patterns which should behave independently from whether they run as legacy or as EOF code. Think ADDMOD, SSTORE, SHL etc... These likely will eventually be migrated manually to EEST, and then the existing tools will be there to wrap them in EOF containers. However, this is a long term task, and we would like to have the coverage early, in preparation for the EOF fork.
It turns out many of ethereum/tests state tests (here using their blockchain_test format, read on to see why) can be opportunistically (that is if they "wrap" easily - good, if not - skip) wrapped into EOF containers and executed and the same expectations on post state will apply.
This PR introduces a new CLI tool eofwrap accomplishes this. I've used it on v14.1 release ethereum/tests (subdir BlockchainTests/GeneralStateTests/). The metrics.json contents is:
{
    "files_generated": 1108,
    "files_skipped": 1656,
    "fixtures_generated": 11110,
    "fixtures_cant_wrap": 7973,
    "fixtures_cant_generate": 262,
    "accounts_wrapped": 53344,
    "unique_accounts_wrapped": 1165,
    "accounts_invalid_eof": 102192,
    "accounts_cant_generate": 855,
    "validation_errors": {
        "err: undefined_instruction": 89507,
        "err: stack_underflow": 12346,
        "err: no_terminating_instruction": 2,
        "err: truncated_instruction": 106,
        "err: invalid_non_returning_flag": 1,
        "err: invalid_container_section_index": 2,
        "err: unreachable_instructions": 203,
        "err: invalid_code_section_index": 1,
        "err: container_size_above_limit": 12,
        "err: max_stack_height_above_limit": 12
    },
    "generation_errors": {
        "unexpected balance for account...": 223,
        "incorrect value in address 0x0...": 9,
        "Account missing from allocatio...": 19,
        "unexpected nonce for account 0...": 9,
        "incorrect value in address 0xc...": 2
    }
}

If one collects the traces with evmone, but modifying it to only trace EOF code execution, then after some sorting/counting (cat trace.log | grep -o '\"opName\"\:\".*\"' | sort | uniq -c), one can get the following summary of the opcodes executed in EOF:
 305517 "opName":"ADD"
    131 "opName":"ADDMOD"
     15 "opName":"ADDRESS"
    105 "opName":"AND"
    185 "opName":"BALANCE"
     24 "opName":"BASEFEE"
     23 "opName":"BLOBBASEFEE"
     34 "opName":"BLOBHASH"
      1 "opName":"BLOCKHASH"
    114 "opName":"BYTE"
  17335 "opName":"CALLDATACOPY"
 151069 "opName":"CALLDATALOAD"
     28 "opName":"CALLDATASIZE"
     30 "opName":"CALLER"
     14 "opName":"CALLVALUE"
      2 "opName":"CHAINID"
     64 "opName":"COINBASE"
      1 "opName":"DATASIZE"
    159 "opName":"DIV"
     51 "opName":"DUP1"
      3 "opName":"DUP10"
      2 "opName":"DUP11"
      2 "opName":"DUP12"
      2 "opName":"DUP13"
      2 "opName":"DUP14"
      2 "opName":"DUP15"
      2 "opName":"DUP16"
     30 "opName":"DUP2"
     22 "opName":"DUP3"
     19 "opName":"DUP4"
     22 "opName":"DUP5"
     17 "opName":"DUP6"
     19 "opName":"DUP7"
     17 "opName":"DUP8"
      2 "opName":"DUP9"
    116 "opName":"EQ"
    883 "opName":"EXP"
     45 "opName":"GASLIMIT"
     32 "opName":"GASPRICE"
    111 "opName":"GT"
     34 "opName":"INVALID"
    105 "opName":"ISZERO"
1193406 "opName":"JUMPDEST"
    265 "opName":"KECCAK256"
     40 "opName":"LOG0"
     40 "opName":"LOG1"
     35 "opName":"LOG2"
     36 "opName":"LOG3"
     31 "opName":"LOG4"
    107 "opName":"LT"
     22 "opName":"MCOPY"
 205043 "opName":"MLOAD"
    112 "opName":"MOD"
     60 "opName":"MSIZE"
 259944 "opName":"MSTORE"
    180 "opName":"MSTORE8"
    551 "opName":"MUL"
    161 "opName":"MULMOD"
    112 "opName":"NOT"
     61 "opName":"NUMBER"
    105 "opName":"OR"
      3 "opName":"ORIGIN"
    693 "opName":"POP"
     30 "opName":"PREVRANDAO"
     26 "opName":"PUSH0"
1708938 "opName":"PUSH1"
      5 "opName":"PUSH10"
      7 "opName":"PUSH11"
      3 "opName":"PUSH12"
     18 "opName":"PUSH13"
     24 "opName":"PUSH14"
      9 "opName":"PUSH15"
    282 "opName":"PUSH16"
      5 "opName":"PUSH17"
     11 "opName":"PUSH18"
      1 "opName":"PUSH19"
 169477 "opName":"PUSH2"
    159 "opName":"PUSH20"
      4 "opName":"PUSH21"
      2 "opName":"PUSH22"
      1 "opName":"PUSH23"
      1 "opName":"PUSH24"
      4 "opName":"PUSH25"
      1 "opName":"PUSH26"
      3 "opName":"PUSH27"
      3 "opName":"PUSH28"
      3 "opName":"PUSH29"
     66 "opName":"PUSH3"
     12 "opName":"PUSH30"
     11 "opName":"PUSH31"
   2280 "opName":"PUSH32"
    341 "opName":"PUSH4"
     18 "opName":"PUSH5"
      8 "opName":"PUSH6"
   1156 "opName":"PUSH7"
    145 "opName":"PUSH8"
      8 "opName":"PUSH9"
 151214 "opName":"RETURN"
      6 "opName":"RETURNDATACOPY"
      2 "opName":"RETURNDATASIZE"
   3664 "opName":"REVERT"
    115 "opName":"SAR"
    119 "opName":"SDIV"
     31 "opName":"SELFBALANCE"
    106 "opName":"SGT"
    232 "opName":"SHL"
    108 "opName":"SHR"
     22 "opName":"SIGNEXTEND"
 100951 "opName":"SLOAD"
    103 "opName":"SLT"
    115 "opName":"SMOD"
 343150 "opName":"SSTORE"
 193260 "opName":"STOP"
    279 "opName":"SUB"
     10 "opName":"SWAP1"
      2 "opName":"SWAP10"
      2 "opName":"SWAP11"
      2 "opName":"SWAP12"
      2 "opName":"SWAP13"
      2 "opName":"SWAP14"
      2 "opName":"SWAP15"
      2 "opName":"SWAP16"
      7 "opName":"SWAP2"
      4 "opName":"SWAP3"
      7 "opName":"SWAP4"
      4 "opName":"SWAP5"
      4 "opName":"SWAP6"
      4 "opName":"SWAP7"
      3 "opName":"SWAP8"
      4 "opName":"SWAP9"
     50 "opName":"TIMESTAMP"
     22 "opName":"TLOAD"
     22 "opName":"TSTORE"
    110 "opName":"XOR"

Open questions

Right now eofwrap takes an opportunistic approach - if the test wraps something and passes, it's worthwhile to wrap and run it. For example, there are tests where it is not the most important code under test being EOF-wrapped, but some auxiliary contract which merely interacts with the important one. Opportunistic here means we still keep this test, to potentially test some edge cases of interactions between legacy and EOF contexts. Other aspect is that there are test categories where many of the fixtures are unwrappable, but several remain. Opportunistic means then that we nevertheless keep the ones which wrapped.
The opposite side of the spectrum is to be more "systematic", i.e. filter out more test categories where the test is "weaker" and include tests more coarsely, only where we're certain EOF opcodes are executed.
For now we err on the side of opportunistic, since this is intended to be a low-cost, stop-gap solution, and postpone the systematic effort until proper migration to EEST.
Not sure how would those JSON files be published. One idea is to include an invocation of such eofwrap in the eip7692 prerelease builds, and just include the JSON files in the resulting directory structure. This maximizes the chance that the EVM implementations will actually run these tests, but might come off as messy.
Why use blockchain test format even though those are actually state tests? It includes the detailed post state assertions, which makes it a lot easier to generate meaningful tests (credit to @chfast for this idea)

🔗 Related Issues
NA
✅ Checklist

[ ] All: Set appropriate labels for the changes.
[ ] All: Considered squashing commits to improve commit history.
[ ] All: Added an entry to CHANGELOG.md.
[ ] All: Considered updating the online docs in the ./docs/ directory.
[ ] Tests: All converted JSON/YML tests from ethereum/tests have been added to converted-ethereum-tests.txt.
[ ] Tests: A PR with removal of converted JSON/YML tests from ethereum/tests have been opened.
[ ] Tests: Included the type and version of evm t8n tool used to locally execute test cases:  e.g., ref with commit hash or geth 1.13.1-stable-3f40e65.
[ ] Tests: Ran mkdocs serve locally and verified the auto-generated docs for new tests in the Test Case Reference are correctly formatted.

@marioevz @danceratopz Thank you for your comments, I think I've addressed all except the plugin - would be better to leave for a separate PR indeed. I see the benefits, but not sure if I know where to start, and also it is indeed more of a one-off tool (hopefully temporary, until migration, but I have some level of fear that it will be "permanently-temporary", the migration is a lot to take on).
Do we want to tackle including of these tests in the eip7962 prerelease at this PR? I thought I've seen a comment on this somewhere, but I cannot find it anymore. How can we approach it?


Window size become 0 after scale factor change[bug]

Describe the bug
WIndow almost disapper when changing the scale factor
Reproduction
Replay steps:

Set the windows.width to 1280(800 works fine)
change the scale factor from 1.5 to 1
tauri hello world window almost disapper

As you can see, window almost disapper

Expected behavior
Window zoom with the scale factor.
Platform and versions
Environment
› OS: Windows 10.0.22000 X64
› Webview2: 105.0.1343.53
› MSVC:
- Visual Studio Enterprise 2022
› Node.js: 16.17.0
› npm: 8.15.0
› pnpm: Not installed!
› yarn: 1.22.19
› rustup: 1.25.1
› rustc: 1.63.0
› cargo: 1.63.0
› Rust toolchain: stable-x86_64-pc-windows-msvc
Packages
WARNING: no lock files found, defaulting to npm
› @tauri-apps/cli [NPM]: 1.1.1
› @tauri-apps/api [NPM]: Not installed!
› tauri [RUST]: 1.1.1,
› tauri-build [RUST]: 1.1.1,
› tao [RUST]: 0.14.0,
› wry [RUST]: 0.21.1,
App
› build-type: bundle
› CSP: unset
› distDir: []
› devPath: []
App directory structure
├─ .changes
├─ .devcontainer
├─ .docker
├─ .git
├─ .github
├─ .husky
├─ .scripts
├─ .vscode
├─ audits
├─ core
├─ examples
├─ target
└─ tooling
Stack trace
No response
Additional context
No response

Can't reproduce, please provide a minimal repro.

Same issue in development mode.
Screen resolution > 1080P > Change resolution to 2160P and zoom 100% > bug.
OS: Windows 11 (latest update)
Driver: AMD Adrenalin 22.11.2


Adds missing pd.Series methods

I believe this PR also
closes predictive-analytics-lab/data-science-types#165

@thomkeh thanks for the feedback and fast turnaround! I think I've addressed your comments. Please have a second look.

Looks good!


Optimize svg

Optimizations for #51.
As a rough estimate of the optimization, I looked at how much smaller the generated markup got if all platforms are selected at once:
Line: down 22%
Line circle: down 25%
Solid: down 27%
Solid circle: down 20%

Amazing, thanks so much!


Add stdweb support

Create new features in the example and in the main crate to choose
between 'web-sys' and 'stdweb' (with the default being web-sys to avoid
breaking existing users)

Behind the stdweb feature flag, implement the same code as the web-sys
backend with as little overhead as possible

Addresses #43

Did you have to make many changes to HasContext for stdweb?

Nope, the API should be exactly the same.

Also could you add a line to the Travis configuration to build stdweb, and rebase to remove the merge commit?

Will do!

Ok, commits all squashed down to one.

Thanks! :shipit:
bors r+


Parsing failure while processing an index with no search term.

    @Test
    fun index(jp: JavaParser) = assertParsePrintAndProcess(
        jp, CompilationUnit, """
            /**
             * {@index}
             */
            public class A {
                void method() {}
            }
        """
    )

fixed as of latest HEAD


Truncate completion options which are too long

Fixes #226.
To indicate truncation it uses three full stops on Windows, an ellipsis otherwise.
This sets the overall max width of the completions window to 75.

What do you think about making it 65? Were there cases where that seemed too low?

I made the width a bit larger because when the display value is wide, there isn't much room left for the hint.
Here's a screenshot with a max width of 65:

(Please ignore the misalignment on the right hand side for now; that's a bug which wasn't there when the width was 75, and which I'll fix.)

Alternatively we could calculate the available width of the window and use that (with some padding) as a maximum width.

I have fixed the alignment bug above.
I also extracted g:kite_completion_max_width (default 75) so the user can tweak it easily.
@adamsmith The width is a trade-off between those occasions when the LHS is large (e.g. json.dump() call signatures), and those when the RHS is large (e.g. union types).  I have been assuming that we should never truncate the LHS.

Ok sounds good to me @ 75.
@its-dhung please weigh in if you have any opinions or thoughts.
Thanks all!

@jansorg The completion menu takes only as much space as needed now.
It sets its max width to the smaller of g:kite_completion_max_width (default 75) and the remaining space in the window.  If the actual width would be wider than the max width, it truncates first the right hand side (while keeping the Kite symbol) and then the left hand side.

thank you @airblade , this is much better.
Is it possible that some extra padding is applied when computing the max width? In a small window it's not spanning all remaining space on the right. Would it be possible to use more of the available space in a case like this?
(Linux, gVim)

@jansorg It was underestimating the width in the case where there was no sign column and/or no number column.  It should be more accurate now.


Update requirements for Python client recipe

This PR address my review comments for https://github.com/TileDB-Inc/tiledbsoma-feedstock/pull/9

Here are the Azure builds running thee changes on my fork: https://dev.azure.com/jdblischak/feedstock-builds/_build/results?buildId=199&view=results


Release Key Management to Nuget

The key management feature is not on Nuget at the moment

done with 0.2.0


Load YAML from external files with no summary/description. Fixes #93

If there's no '---' in the text, but it's from an external file, assume
it's all YAML, but if it's not from an external file, assume there is no
YAML (i.e., it's all docstring).

Coverage decreased (-0.2%) to 90.401% when pulling d4a998ee7cb8e7456bc782630caaf5cf4763d140 on schamp:master into 7dc513506c3c946df728bb1a07805da09f4129db on rochacbruno:master.

I think the only other way to increase the coverage is to add test cases that reference external YAML files that have no swagger spec in them, just a description.  Not sure how helpful that will be...

Found a bug, going to clean up that first commit and try again.

Coverage increased (+0.07%) to 90.674% when pulling e611e6dc2b61815d0ee94d64e63bbff2f21c840c on schamp:master into 7dc513506c3c946df728bb1a07805da09f4129db on rochacbruno:master.

Forgive the churn, I'm new at this.

Coverage increased (+0.07%) to 90.674% when pulling e611e6dc2b61815d0ee94d64e63bbff2f21c840c on schamp:master into 7dc513506c3c946df728bb1a07805da09f4129db on rochacbruno:master.


Laravel 5.4 support

Currently this package does not support 5.4 and blocks installation. Any idea on a timeline for 5.4 support?

Yes, 2.x supports Laravel 5.4. :)

You can see the changes here: https://github.com/AltThree/Locker/compare/1.6...master.

Whoops. Totally missed the major version release! My apologies 😅


flannel network not working in my kubernetes setup

I've deployed a custom k8s cluster using typhoon as a base.  The only thing I've customised is the networking side (everything inside a private subnet, with the exception of the load balancer), and added iam roles to the instances, and cloud_provider set to aws.
When I deploy, the cluster comes up fine, but for any pods created in the flannel network, I cannot reach any other pod, or the outside world.
The flannel pods look like they start fine, but are stuck(?) at watching for new subnet leases
$ k -n kube-system logs kube-flannel-f5lqt kube-flannel
I1024 08:50:56.465274       1 main.go:416] Searching for interface using <IP_ADDRESS>
I1024 08:50:56.465503       1 main.go:487] Using interface with name eth0 and address <IP_ADDRESS>
I1024 08:50:56.465514       1 main.go:504] Defaulting external address to interface address (<IP_ADDRESS>)
I1024 08:50:56.477351       1 kube.go:130] Waiting 10m0s for node controller to sync
I1024 08:50:56.477383       1 kube.go:283] Starting kube subnet manager
I1024 08:50:57.477486       1 kube.go:137] Node controller sync successful
I1024 08:50:57.477511       1 main.go:234] Created subnet manager: Kubernetes Subnet Manager - ip-10-156-74-65.eu-west-1.compute.internal
I1024 08:50:57.477516       1 main.go:237] Installing signal handlers
I1024 08:50:57.477604       1 main.go:352] Found network config - Backend type: vxlan
I1024 08:50:57.477661       1 vxlan.go:119] VXLAN config: VNI=1 Port=0 GBP=false DirectRouting=false
I1024 08:50:57.477934       1 main.go:299] Wrote subnet file to /run/flannel/subnet.env
I1024 08:50:57.477943       1 main.go:303] Running backend.
I1024 08:50:57.477949       1 main.go:321] Waiting for all goroutines to exit
I1024 08:50:57.477966       1 vxlan_network.go:56] watching for new subnet leases

the subnet.env file looks like:
$ k -n kube-system exec -ti kube-flannel-24jj7 -- cat /run/flannel/subnet.env
Defaulting container name to kube-flannel.
Use 'kubectl describe pod/kube-flannel-24jj7 -n kube-system' to see all of the containers in this pod.
FLANNEL_NETWORK=<IP_ADDRESS>/16
FLANNEL_SUBNET=<IP_ADDRESS>/24
FLANNEL_MTU=8951
FLANNEL_IPMASQ=true

The daemonset description is as follows:
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: kube-flannel
  namespace: kube-system
  labels:
    tier: node
    k8s-app: flannel
spec:
  selector:
    matchLabels:
      tier: node
      k8s-app: flannel
  template:
    metadata:
      labels:
        tier: node
        k8s-app: flannel
      annotations:
        seccomp.security.alpha.kubernetes.io/pod: 'docker/default'
    spec:
      serviceAccountName: flannel
      containers:
      - name: kube-flannel
        image: ${flannel_image}
        command: [ "/opt/bin/flanneld", "--ip-masq", "--kube-subnet-mgr", "--iface=$(POD_IP)"]
        securityContext:
          privileged: true
        env:
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: POD_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
        volumeMounts:
        - name: run
          mountPath: /run
        - name: cni
          mountPath: /etc/cni/net.d
        - name: flannel-cfg
          mountPath: /etc/kube-flannel/
      - name: install-cni
        image: ${flannel_cni_image}
        command: ["/install-cni.sh"]
        env:
        - name: CNI_NETWORK_CONFIG
          valueFrom:
            configMapKeyRef:
              name: kube-flannel-cfg
              key: cni-conf.json
        volumeMounts:
        - name: cni
          mountPath: /host/etc/cni/net.d
        - name: host-cni-bin
          mountPath: /host/opt/cni/bin/
      hostNetwork: true
      tolerations:
      - effect: NoSchedule
        operator: Exists
      - effect: NoExecute
        operator: Exists
      volumes:
        - name: run
          hostPath:
            path: /run
        - name: cni
          hostPath:
            path: /etc/kubernetes/cni/net.d
        - name: flannel-cfg
          configMap:
            name: kube-flannel-cfg
        - name: host-cni-bin
          hostPath:
            path: /opt/cni/bin
  updateStrategy:
    rollingUpdate:
      maxUnavailable: 1
    type: RollingUpdate

the config is:
apiVersion: v1
data:
  cni-conf.json: |
    {
      "name": "cbr0",
      "cniVersion": "0.3.1",
      "plugins": [
        {
          "type": "flannel",
          "delegate": {
            "hairpinMode": true,
            "isDefaultGateway": true
          }
        },
        {
          "type": "portmap",
          "capabilities": {
            "portMappings": true
          }
        }
      ]
    }
  net-conf.json: |-
    {
      "Network": "<IP_ADDRESS>/16",
      "Backend": {
        "Type": "vxlan"
      }
    }
kind: ConfigMap
metadata:
  creationTimestamp: 2018-10-23T12:58:03Z
  labels:
    k8s-app: flannel
    tier: node
  name: kube-flannel-cfg
  namespace: kube-system
  resourceVersion: "347"
  selfLink: /api/v1/namespaces/kube-system/configmaps/kube-flannel-cfg
  uid: 4769cd11-d6c3-11e8-9a3d-02f94dd0b736

Expected Behavior
I'd expect contact with the outside world to work, so an apk update should actually work
I'd expect to be able to nslookup cluster services.
Current Behavior
$ k run -it test --image=alpine --restart=Never -- apk update
If you don't see a command prompt, try pressing enter.
ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.8/main: temporary error (try again later)
WARNING: Ignoring APKINDEX.adfa7ceb.tar.gz: No such file or directory
fetch http://dl-cdn.alpinelinux.org/alpine/v3.8/community/x86_64/APKINDEX.tar.gz
ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.8/community: temporary error (try again later)
WARNING: Ignoring APKINDEX.efaa1f73.tar.gz: No such file or directory
2 errors; 13 distinct packages available
pod default/test terminated (Error)

$ k run -it test --image=alpine --restart=Never -- nslookup kube-system.default.svc.cluster.local <IP_ADDRESS>
If you don't see a command prompt, try pressing enter.
Address 1: <IP_ADDRESS>

nslookup: can't resolve 'kube-system.default.svc.cluster.local': Try again
pod default/test terminated (Error)

Possible Solution
I have none.
Steps to Reproduce (for bugs)
Context
A vanilla typhoon project starts up and the flannel network works just fine.  So presumably, my iam privileges or vpc setup is squiffy.
I've moved to flannel for a couple of reasons:

Calico stopped working in this environment when upgrading from 1.11.2 to 1.12.1 (k8s)
I want to use the ipsec capability of flannel.  I figure if I can't get a vanilla vxlan to work, ipsec is unlikely to work either.

Your Environment

Flannel version: 0.9.1 and 0.10.0
Backend used (e.g. vxlan or udp): vxlan
Etcd version: v3.3.10
Kubernetes version (if used): 1.12.1
Operating System and version: CoreOS Container Linux stable 1855.4.0 (HVM)
Cloud: AWS

It's worth noting that I opened the security groups so that it accepted traffic from everywhere, and the iam permissions were set to:
      "autoscaling:DescribeAutoScalingGroups",
      "autoscaling:DescribeAutoScalingInstances",
      "autoscaling:DescribeLaunchConfigurations",
      "autoscaling:DescribeTags",
      "autoscaling:SetDesiredCapacity",
      "autoscaling:TerminateInstanceInAutoScalingGroup",
      "autoscaling:UpdateAutoScalingGroup",
      "ec2:AttachVolume",
      "ec2:AuthorizeSecurityGroupIngress",
      "ec2:CreateRoute",
      "ec2:CreateSecurityGroup",
      "ec2:CreateTags",
      "ec2:CreateVolume",
      "ec2:DeleteRoute",
      "ec2:DeleteSecurityGroup",
      "ec2:DeleteVolume",
      "ec2:DescribeAvailabilityZones",
      "ec2:DescribeInstances",
      "ec2:DescribeRegions",
      "ec2:DescribeRouteTables",
      "ec2:DescribeSecurityGroups",
      "ec2:DescribeSubnets",
      "ec2:DescribeSubnets",
      "ec2:DescribeVolumes",
      "ec2:DescribeVolumesModifications",
      "ec2:DescribeVpcs",
      "ec2:DetachVolume",
      "ec2:ModifyInstanceAttribute",
      "ec2:ModifyVolume",
      "ec2:ReplaceRoute",
      "ec2:RevokeSecurityGroupIngress",
      "elasticloadbalancing:DescribeListeners",
      "elasticloadbalancing:DescribeLoadBalancerAttributes",
      "elasticloadbalancing:DescribeLoadBalancerPolicies",
      "elasticloadbalancing:DescribeLoadBalancers",
      "elasticloadbalancing:DescribeTargetGroups",
      "elasticloadbalancing:DescribeTargetHealth",
      "iam:GetServerCertificate",
      "iam:ListServerCertificates",

Never mind.  Tracked the issue down to a network acl rule issue.

@pms1969 What was the acl issue? I am having this same error.

@amitnjha IIRC, I hadn't enabled udp traffic

I had to update my R-Pi OS to Stretch to solve this error. I was having Operation Not Permitted error for vxlan in Jessie otherwise.


Switch to using thirdparty cask for dockutil

This is intended as a temporary change
Waiting on PR: https://github.com/Homebrew/homebrew-core/pull/97394 to
update dockutil to version 3.0.2

Fixes #316
Authored-by: Sam Mirza<EMAIL_ADDRESS>

There might still be an issue I'm seeing on my machine but this is a move in the right direction.


Avoid duplicate output in acyclic_breadth_first

Fix #3244:
from nltk.corpus import wordnet as wn
ss=wn.synset("calamagrostis.n.01")
print(list(ss.closure(lambda s: s.hypernyms())))

[Synset('gramineae.n.01'), Synset('monocot_genus.n.01'), Synset('monocot_family.n.01'), Synset('genus.n.02'), Synset('family.n.06'), Synset('taxonomic_group.n.01'), Synset('biological_group.n.01'), Synset('group.n.01'), Synset('abstraction.n.06'), Synset('entity.n.01')]

This PR includes #3218, which fixes the problem raised by @rmccampbell, concerning excessive verbosity in the warnings.

The acyclic_breadth_first() function uses two structures to manage the relation closure: traversed, a set of nodes already seen, and queue, a deque of (child, level) pairs to lookup next.
This picture shows how 'taxonomic_group.n.01', is added to the queue twice, while not yet added to the traversed set. The problem occurs later, when popping duplicates from the queue without checking traversed. So there are two ways of solving the problem, either checking traversed, or preventing duplicates in the queue. This PR implements the first solution, but it might be interesting to consider the second instead.

Calculating the transitive hypernymic closure of all the 82115 noun synsets in WordNet 3.0 with either solution yields identical closures in both cases, but the solution implemented in this PR is 15% quicker.

Finally, sorry


feat(cli): Support specifying a line number when filtering tests

Description
closes #5445.

Added a function to parse filters into { filename, lineNumber? }.  The function attempts to parse each filter with the format <filename>:<line_number>.  If succssful, lineNumber is set, and we have a "location filter", otherwise line number is not set and the filter is treated as a regular filter.

Added locationFilters to UserConfig and to VitestRunnerConfig.
Note that the we only store filters that have lineNumber, in order to use them in interpretTaskModes.

The parsing is done in cac.ts:start because that's the place where we have access to both the options and filters.

I think I know where to do stuff for the most part, but I need help with some stuff:

I'm not sure how to report errors in case the user included a range instead of a line number.

I'm not happy with my use of Required in Required<Filter[]>, but I'm not sure what would be a better way to do it.

I think we should match filename strictly when location filter is provided, but I'm not sure how to.  Should I be using something similar to WorkspaceProject.filterFiles()?
if (isAbsolute(f) && t.startsWith(f)) {
    return true
}

As for printing an error when the user provides a wrong line number, it's a bit tough with interpretTaskModes being a recursive a function.  What I have in mind is to keep track of all the filters and wether it was matched or not, and print out errors once we've been through all the tests.
The part I'm having an issue with is where to keep track of that.  That would involve major changes to how interpretTaskModes is written.  I could move the
See 36c88e9574eafcdc6be2aa582056b118d4ebb33c

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[ ] It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
[ ] Ideally, include a test that fails without this PR but passes with it.
[x] Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.

Tests

[ ] Run the tests with pnpm test:ci.

Documentation

[ ] If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

[ ] Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.

Vitest has specs that describe the test behaviour:
https://github.com/vitest-dev/vitest/blob/83638eb9ad58b9addfe74121f7ef2952518aeb96/packages/vitest/src/node/core.ts#L1083
I would prefer if we passed down locations there to keep the scope clean and avoid polluting the config.

As far as I can tell, globTestSpecs is run before we have access to tests (not collected yet), and I need access to the tests to filter based on line number.

We don't need to collect tests for this to work, spec defines what tests to run. This is the perfect place to tell Vitest to limit what test functions to run.

I went with this approach as it is more similar to how -t, --testNamePattern is handled (#332)

I know. This doesn't really explain why it should follow the same implementation.

I might be missing something.  What kind of information do I have access to in a spec?  How would I access the line numbers of a test?
I see location in TaskBase.  Do I have access to it in globTestSpecs?

I might be missing something. What kind of information do I have access to in a spec? How would I access the line numbers of a test?
I see location in TaskBase. Do I have access to it in globTestSpecs?

Spec is a specification, it doesn't have any information about the test or a file. It tells what file to run and how to run it. TestCase is the result. You need to pass down this information somewhere in the pool:
https://github.com/vitest-dev/vitest/blob/83638eb9ad58b9addfe74121f7ef2952518aeb96/packages/vitest/src/node/pools/threads.ts#L105
Maybe you can populate the provided context somehow or inject the config value, that's up to you, but the processing should happen there.

You can keep the filtering in the test like it is, but change how the values are passed down from the main process.

Do you mean that the issue at hand is not filtering inside interpretTaskModes, but rather the use of VitestRunnerConfig and UesrConfig to pass the values to interpretTaskModes?

Maybe you can populate the provided context somehow or inject the config value, that's up to you, but the processing should happen there.

Is the issue that we should provide each worker with only the values that are relevant values to its files (unlike testNamePatter which is global for all files)?

Do you mean that the issue at hand is not filtering inside interpretTaskModes, but rather the use of VitestRunnerConfig and UesrConfig to pass the values to interpretTaskModes?

Yes. The interpretTaskModes code is fine.

Is the issue that we should provide each worker with only the values that are relevant values to its files (unlike testNamePatter which is global for all files)?

Yes, that's the idea.

@sheremet-va
I gave it a try.  See 76bd9212b4f3abecce3e4cbc5178ec00d2069348.  Previous code will be removed of course.
In globTestSpecs, the filters will be matched against the files, and if there is a location in the filter, it will be included with its file, in a FileSpec: { path, testLocations? }.
I thought it would be a good idea to include the files with the location in the same object, instead of having them in their own attribute in the config and then matching based on the path or something.  But I ended up having to modify types everywhere to get this to work.
I had to modify groupFilesByEnv to include the testLocations in its output, and also modify pools to pass the test locations to runFiles.
Much of the code in this commit is hacked together, but I had to get something that somewhat works, sometimes, just to see if I'm on the right track.
Would appreciate inputs on this before I commit to making more changes.

The general direction seems fine to me, but there are some changes that we cannot make because it would be a breaking change.

One thing I shouldn't be doing is parsing the filters in cac.ts:start, this is forcing me to change types more than I have to.
https://github.com/vitest-dev/vitest/blob/76bd9212b4f3abecce3e4cbc5178ec00d2069348/packages/vitest/src/node/cli/cac.ts#L265
If I were to do the parsing inside globTestSpecs it will solve the type change related to Filter.
How about Instead of using an incompatible type like FileSpec, we use a superset type, maybe something like string[] | FileSpec[] or (FileSpec | string)[], would that do for now?  Do you have any other suggestions?

Unless you want to have this merged in a year,

This has been labelled a "nice to have", but I'm not sure I'll be here in a year :)

How about Instead of using an incompatible type like FileSpec, we use a less restrictive superset type, maybe something like string[] | FileSpec[] or (FileSpec | string)[], would that do for now? Do you have any other suggestions?

I guess that would work but I don't understand why you need this if you will still parse it inside, right?

I guess that would work but I don't understand why you need this if you will still parse it inside, right?

I Forgot to add the declaration of FileSpec, my bad.
export interface FileSpec {
  file: string
  testLocations: number[] | undefined
}

The intention of this is to pass both the filepath and the testLocations togther, instead of just passing the filepath as string.

Cleaned up a bit

I'm not sure if I should update these types to string [] | FileSpec[] too.
https://github.com/vitest-dev/vitest/blob/8f49e9e544086544f4efa4bccc1256148d560606/packages/runner/src/run.ts#L516
https://github.com/vitest-dev/vitest/blob/8f49e9e544086544f4efa4bccc1256148d560606/packages/runner/src/run.ts#L498
https://github.com/vitest-dev/vitest/blob/8f49e9e544086544f4efa4bccc1256148d560606/packages/vitest/src/runtime/runBaseTests.ts#L21
https://github.com/vitest-dev/vitest/blob/8f49e9e544086544f4efa4bccc1256148d560606/packages/vitest/src/runtime/runVmTests.ts#L25-L26

In interpretTaskModes, I've renamed the argument to file.  It seems to me that only a file gets passed.  Please confirm.
https://github.com/vitest-dev/vitest/blob/8f49e9e544086544f4efa4bccc1256148d560606/packages/runner/src/utils/collect.ts#L9
and I'm not sure how to handle error reporting in case a wrong line number was provided.  Pointers would be appreciated.

I've tried to minimize the changes in packages/vitest/src/node/pools/forks.ts.  I will replicate them for all pool types.
https://github.com/vitest-dev/vitest/blob/8f49e9e544086544f4efa4bccc1256148d560606/packages/vitest/src/node/pools/forks.ts#L280
Moved away from using a variable, because I wasn't sure what to name.

I hope I'm in the right direction.  Thank you for you time @sheremet-va!

squashed and rebased.  Should be up to date with main, will check it later.
For now, I've added an error IncludeTaskLocationDisabledError, it is ok?  I'm thinking of adding a new one for range line number (location filters don't accept ranges).

@sheremet-va Should be good, if you can take a look.
Thanks you!

@sheremet-va Should be good, if you can take a look.
Thanks you!

There are issues in CI it seems. Something with benchmarking?

There are issues in CI it seems. Something with benchmarking?

Aha, thought it had to do with stuff not related to me, will look into it.

@sheremet-va should be mostly good.
Build is good.  Test is good, but not for windows (or sometimes macos), idk why
Changed code to throw an error when a given filter doesn't match -- covered this in test cases by having math.test.ts and math-with-dashes-in-name.test.ts; specifying math:99 should result in an error.

Test is good, but not for windows (or sometimes macos), idk why

It's probably related to / and \ difference. MacOS is just flaky, but your Windows tests are clearly failing because there is a bug somewhere

Looks good to me! Do you think you can fix the Windows errors?

Thank you for keeping this PR up-to-date!


[AutoPR web/resource-manager] Add HyperV property for AppServicePlan and Site model and deprecating…

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/3667

(message created by the CI based on PR content)

This PR has been merged into https://github.com/Azure/azure-sdk-for-python/pull/2065


add merge=union gitattributes for CHANGELOG.md

My thank to @cgmb for providing this change
This update reduces merge conflicts if there are multiple concurrent edits to CHANGELOG.md

I included some workflow guidelines for this change in a comment here: https://github.com/ROCmSoftwarePlatform/rocBLAS-internal/pull/429#issuecomment-726310516
The important one is: make sure that your only conflicts within the changelog occur due to adding changelog entries, as this strategy will not correctly handle two people fixing the same typo in old changelog entries.


doesn't print red failed report if all tests pass

With this change, we can quickly determine if all the tests have passed by color without having to check all the red text.

LGTM!


Header Host contains invalid characters

Hi @pozil - I'm editing Katia Hage's custom channels badge and I'm getting the following error when I run through the steps: Error: Header "Host" contains invalid characters
Things worked fine yesterday but after testing today with two fresh pre-release orgs ran into the same issue both times. Any idea what could be going on?

Just following up on this @pozil - The issue was an artifact when copying the instance_url from the token details view. I'm guessing most devs will be able to troubleshoot this, but we might want to add a note to the instructions since we're pointing some Trailhead content to these instructions. Thanks!

Hi @thoffman-sfdc. Thanks for the extra info, I wish we could automate this part and get rid of the instance_url copy/pasting. My guess is that you also copied a line break.
I'm going to update the instructions to warn users.


Breaking changes (3)

Fixes #43635
Fixes #43379
Fixes #43564

Internal previews

📄 File
🔗 Preview link

docs/core/compatibility/9.0.md
Breaking changes in .NET 9

docs/core/compatibility/aspnet-core/9.0/legacy-apis.md
Legacy Mono and Emscripten JavaScript APIs not exported to global namespace

docs/core/compatibility/containers/9.0/monitor-images.md
".NET Monitor images simplified to version-only tags"

docs/core/compatibility/core-libraries/9.0/oob-packages.md
New version of some OOB packages

docs/core/compatibility/toc.yml
docs/core/compatibility/toc

Thanks for the reviews.


Bug: Property 'onDone' does not exist on type Actor

Description
doc example
import { createMachine, createActor } from 'xstate';

const currencyMachine = createMachine({
  // ...
  states: {
    converting: {
      // ...
    },
    converted: {
      type: 'final',
      output: ({ context }) => ({
        amount: context.amount,
        currency: context.currency,
      }),
    },
  },
});

const currencyActor = createActor(currencyMachine, {
  input: {
    amount: 10,
    fromCurrency: 'USD',
    toCurrency: 'EUR',
  },
});

currencyActor.onDone(() => {
  console.log(currencyActor.getSnapshot().output);
  // logs e.g. { amount: 12, currency: 'EUR' }
});

Expected result
TypeError
currencyActor.onDone is not a function
$csb$eval
index.ts:28:14
  25 |   }
  26 | });
  27 |
> 28 | currencyActor.onDone(() => {
     |              ^
  29 |   console.log(currencyActor.getSnapshot().output);
  30 |   // logs e.g. { amount: 12, currency: 'EUR' }
  31 | });

Actual result
{ amount: 12, currency: 'EUR' }
Reproduction
https://codesandbox.io/s/boring-dew-h92t84?file=/src/index.ts
Additional context
No response

In v5 we removed onDone in favor of the existing complete callback that you can use together with subscribe:
currencyActor.subscribe({
  complete: () => {
    console.log(currencyActor.getSnapshot().output);
    // logs e.g. { amount: 12,  }
  }
});

Full example: https://codesandbox.io/s/festive-night-hy9cf3?file=/src/index.ts

Thank you. The documentation needs to be updated.

Thank you. The documentation needs to be updated. https://stately.ai/docs/final-states#output

Done here, feel free to review: https://github.com/statelyai/docs/pull/249


[Differentiation] Promoted banner for Articles

Mobile version of https://github.com/artsy/force-private/issues/5254

Sketch file: https://www.dropbox.com/s/d4x3may28sdv2jr/DifferentiationMobileSpec.sketch?dl=0

@owendodd -- I wanted to check in about the titles for the promoted content bar -- currently titles give the auction house and the name of the sale in many cases but not all.  Two options I've explored are showing the full name, or clipping off anything following a colon, which looks like the example you sent above.

@eessex I think the full name will work!


Question re init.vim

Hi there,
What exactly does this do?
augroup highlight_yank
    autocmd!
    autocmd TextYankPost * silent! lua require'vim.highlight'.on_yank("IncSearch", 50)
augroup END

Will need @ThePrimeagen to take a look as I believe this is related to his vimrc.

:h on_yank


because of "remove operator because region disappeared" ,my cdc mission blocked more than 24 hours,out of gc-ttl

Bug Report
Please answer these questions before submitting your issue. Thanks!
1. Minimal reproduce step (Required)

2. What did you expect to see? (Required)
3. What did you see instead (Required)
4. What is your TiDB version? (Required)

Hi, CDC is maintained in https://github.com/pingcap/tiflow . I have moved your issue

@iceran could you please provide more info following the bug report template?