Deserialization and persistent identity

As specified each evaluation of a module block expression produces a new module block object. We also have the ability to serialize them and send them elsewhere.
However what is not obvious specced or clarified is whether or not these "clones" result in the same module record. As an example suppose we sent the same module many times to a worker, would the resulting import produce just a single module record?
I feel like the motivations of the proposal would suggest it should, this would ensure we can send a module to a worker multiple times but without reinstantiating it again and again (and instead just using the cached module namespace object).
As a code example demonstrating the above situation, should this print "Instantiated!" once or 10 times? (using structuredClone/import() on same thread instead of Worker, but same logic applies)
// There is a single module object
const mod = module {
    console.log("Instantiated!");

    export default {};
}

const instance = await import(mod);

for (let i = 0; i < 9; i++) {
    // However it can be cloned multiple times
    const modClone = structuredClone(mod);
    // But should this produce the same module record?
    const cloneInstance = await import(modClone);
    // If so this will be true
    console.log(instance === cloneInstance && instance.default === cloneInstance.default);
}

That's a very good point, which makes me think we have to be careful regarding garbage collection.
I believe the intent is to only cause a single instantiation for a given static record. Even if we make sure to create a new object representation for each static record when shared between agents / structured clone, the same module namespace object could be obtained from it.
Someone could technically use that namespace object as a weak target. Unless we say that only their observation in the local agent matters for their liveness definition, we risk entangling independent object graphs.

I would expect 10 separate instantiations. My mental modal is to have module blocks behave just like object literals. Clonding the same object 10 times will give you 10 unique copies of that object.
But I’m curious to hear more use-case driven arguments here.

I also expect 10 separate module initializations. I would furthermore expect 10 separate module initializations even without the clone. If mod corresponds to a static module record, I expect import(mod) and compartment.import(mod) to both work. A static module record can be initialized in different compartments with different module specifiers, and if different compartments have different “import maps”, the linkage of import specifiers may be different. Because the static module record doesn’t capture or communicate a unique module specifier for the module, there is no way for compartment.import(mod) to communicate a cache key for the module namespace instance. Therefore, these instances must be ephemeral. Therefore, each import(mod) must produce a new initialized module namespace object.

Just to clarify, what would the behavior be for the following modified example be:
// There is a single module object
const mod = module {
    console.log("Instantiated!");

    export default {};
}

// Logging "Instantiated!"
const instance = await import(mod);

for (let i = 0; i < 9; i++) {
    // Not cloning, loading the same module definition
    // I'd expect no further logging
    const cloneInstance = await import(mod);
    // I'd expect the following to be true
    console.log(instance === cloneInstance && instance.default === cloneInstance.default);
}

@mhofman Yep, I agree with your expectations in that code sample.. Importing the same module block should return the same module instance.

I would expect 10 separate instantiations. My mental modal is to have module blocks behave just like object literals. Clonding the same object 10 times will give you 10 unique copies of that object.
But I’m curious to hear more use-case driven arguments here.

It comes down to patterns for using these things in workers, because sending to a worker corresponds to a structuredClone. This leads to a weird thing were import() is idempotent on the same thread, but if we send it to another thread it could be evaluated over-and-over-and-over again.
i.e. As an example suppose we had some API that used a worker in the background for loading modules like this:
class Scene {
   async applyEffect(effectModule) {
       // send to worker to apply the effect
   }
}

And then we had a constant set of effects:
const effects = {
    balloons: module {
        export function renderEffect() {

        }
    },
    discoLights: module {
        export function renderEffect() {

        }
    },
}

If we were to do something like:
// When a dropdown changes the effect
effectSelectElement.addEventListener("change", async (event) => {
    const effectName = event.target.value;
    // Apply the effect
    await scene.applyEffect(effects[effectName]);
});

Then even applying the same effect multiple times results in multiple executions. However if we were to implement this same thread:
// When a dropdown changes the effect
effectSelectElement.addEventListener("change", async (event) => {
    const effectName = event.target.value;
    const effect = await import(effects[effectName]);
    // Apply the effect somehow
});

Then the evaluations of the modules would be idempotent if the same module has already been evaluated.
In my opinion this is fairly confusing, as even though the set of effects is constant and never changes, multiple evaluations of the "same module" on one thread is different to multiple evaluations of the "same module" on another thread.
And yes I get what you're saying is that the mental model should perhaps be that sending to a worker corresponds to a clone, but I don't really feel like this is the model I would've expected based on how import() works. i.e.  But using this module blocks feature despite being idempotent on the same-thread, is no longer idempotent cross-thread, this is quite a divergence from string specifiers.
This difference between string-specifiers and module-blocks leads to a situation where it is hard to design APIs that can take in modules and send them to workers without accidental reevaluation.
And perhaps this is a non-issue and engines will be extremely efficient at reevaluating the same module multiple times in a worker, although I am skeptical this is great to rely on in the presence of top-level-await where arbitrarily complex work might be involved to import a module.

The mental model I have is of the SharedArrayBuffer, which has a unique backing data block, but may have multiple object instances connected to it, possibly in different agents. The difference with SAB is that the backing data block is not reified as an object, where here we have module namespace objects.
I agree with @Jamesernator that the developer ergonomics would be better if a single instantiation occurred for a given module declaration, regardless of the identity of the JavaScript object that represents the module declaration in code. However as I also mentioned, we have to be careful that this doesn't introduce a shared identity that is observable across multiple agents, as that'd be a sure way to get into complex distributed garbage collection problems.
PS: I'm careful to differentiate realm and agents here, where the property of an agent is that it has it's own completely independent object graph with its own local gc. None of these problems exist across realms in the same agent as those objects graphs are already entangled, even with ShadowRealm.

I gave this issue more thought, and we should be fine as long as the program cannot observe the liveness of a module block shared with another agent.
This implies either of the following requirements must be enforced:

The identity of the module block value is not maintained through structure cloning, or
The liveness of the identity of the module block cannot be observed.

Let's assume we want to enable the developer ergonomics of sharing with another agent the same module block multiple times through postMessage, and that it should not result in multiple instantiation when imported.
The first requirement may be surprising to users, as the answer from @surma and @kriskowal seem to indicate. It may not be obvious that a same underlying static module record can have multiple representatives with different identities.
If instead we want a stable identity through structure clone, the second requirement would require that the module block liveness cannot be observed through a WeakRef. However any object should be accepted as a WeakRef target (cannot throw). Either we would have to consider the module block object an uncollectible root in the object graph, or we could make the module block value a primitive, which doesn't carry the same expectations.
There is currently a precedent in the spec for a primitive with unforgeable identity and unobservable liveness: Symbols. Those however cannot be used through structured cloning, I assume because of their unforgeable identity. I believe however it could be possible to roundtrip an identity bearing primitive to another agent and back, by using a WeakValueMap style association, e.g. using a UUID implicitly created when declaring the module block. As long as the primitive value cannot be used as a WeakRef target, there should be no problems of distributed garbage collection.
Credits to @erights for the idea of module blocks as primitive values.

If instead we want a stable identity through structure clone, the second requirement would require that the module block liveness cannot be observed through a WeakRef. However any object should be accepted as a WeakRef target (cannot throw). Either we would have to consider the module block object an uncollectible root in the object graph, or we could make the module block value a primitive, which doesn't carry the same expectations.
There is currently a precedent in the spec for a primitive with unforgeable identity and unobservable liveness: Symbols. Those however cannot be used through structured cloning, I assume because of their unforgeable identity. I believe however it could be possible to roundtrip an identity bearing primitive to another agent and back, by using a WeakValueMap style association, e.g. using a UUID implicitly created when declaring the module block. As long as the primitive value cannot be used as a WeakRef target, there should be no problems of distributed garbage collection.

So one of the pain points with symbols that is currently a stage-2 proposal to be changed is precisely the fact you cannot observe their liveness despite being unforgeable. That proposal seeks to allow symbols as entries in WeakMap, and targets of WeakRef/FinalizationRegistry.
Now because module blocks are serializable, some of the use cases for observable liveness become less of an issue (i.e. remote objects). However I feel like associating metadata with module blocks are likely to be fairly common, given these blocks can be generated arbitrarily many times like symbols, it would be unfortunate if there were no way to associate such data without preventing garbage collection. (i.e. As primitives, they would only be storable in a Map making collection of associated data difficult to impossible in general).
Although I do agree with concerns about observing liveness, but this makes me wonder, even if we did make module blocks primitive it would be useful to allow them as WeakMap keys, but NOT WeakRef/FinalizationRegistry targets. This would allow people to associate metadata with module blocks, but without causing memory leaks, and without creating weak targets (as from what I understand WeakMap doesn't enable weak targets, only WeakRef/FinalizationRegistry do).

I don’t think it would be good to violate the axiom that a WeakMap key, WeakSet member, and WeakRef target can all be the same kind of value.

I don’t think it would be good to violate the axiom that a WeakMap key, WeakSet member, and WeakRef target can all be the same kind of value.

I agree, and regardless allowing usage as WeakMap keys is sufficient to cause the problem in the presence of WeakRef in the realm. Aka you can add the module as key, and a plain sentinel object as value, and simply observe the sentinel. So my earlier distinction was pointless.
I don't believe there is a way to reconcile the ability to associate metadata with a module block, and block cross agent liveness observability. We have to either:

Have a stable identity between agents, but be unable to observe its liveness. That means no usage as WeakMap key or WeakRef target, which basically means a primitive.
Not have a stable identity through cloning. You could still have a local object representation as the value, and use it as WeakMap key or WeakRef target, but everytime you send a module block through structure cloning, you'd get a different object, so that realistically limits your ability to associate data to the realm in which the module was initially defined.

The primitive approach allows you to work across the ShadowRealm callable boundary without any more spec features (e.g. a cloner for module blocks that supports shadow realms).
The last alternative is to give up on preventing shared cross agent identity, at least on the agent cluster use case. That means that unless engines implement a single gc per agent cluster, cross agent cycles wouldn't be collectible. That still leaves the problem of cross agent cluster communication, which I believe this proposal intends on supporting as well. There is really don't believe that a stable identity is possible (unless you go into full cooperative distributed GC). I honestly don't think the use case of associating metadata to a module definition is worth it.
In the case of a primitive allowing usage as weakmap key could be implementation defined, as long as we have a predicate to test whether a value can be used in weak collection (which we're planning on having if record/tuples have ObjectPlaceholder).

So one of the pain points with symbols that is currently a stage-2 proposal to be changed is precisely the fact you cannot observe their liveness despite being unforgeable. That proposal seeks to allow symbols as entries in WeakMap, and targets of WeakRef/FinalizationRegistry.

FYI if ObjectPlaceholder from the Record/Tuple proposal makes it through, I doubt there will be any motivation for symbols as weakmap keys.

I agree, and regardless allowing usage as WeakMap keys is sufficient to cause the problem in the presence of WeakRef in the realm. Aka you can add the module as key, and a plain sentinel object as value, and simply observe the sentinel. So my earlier distinction was pointless.

That makes sense, thanks.

I honestly don't think the use case of associating metadata to a module definition is worth it.

Yeah it probably isn't over the other constraints, in most cases people should probably associate such metadata with the module namespace itself rather than the primitive, as the primitive could still refer to many module records (one per realm).
I have seen the odd use of associating metadata to specifiers before, but those are uncollectable as they're strings anyway, so in this regard module blocks being primitives would be no worse than the status quo for that.

Trying to catch up on this...
Would the problem go away if a structured clone’d module block maintains identity? Here’s two code examples to think along:

Thinking about this some more, I suspect preserving identity might be the right way to go. You can’t create “fresh copies” of modules right now, so I feel like Module Blocks should not behave differently here.

@surma, that's the core of the issue. If module blocks preserve identity through structure clone across agents (with an agent being the GC boundary in current implementations), then they shouldn't be usable as WeakMap keys.
If they preserve identity and are usable as WeakMap keys, you will either have memory leaks, or require implementations to have distributed GC.

@syg afaik v8 and JSC are working on a GC for an agent cluster, but what about sending a module block over postMessage to another cluster (e.g. SharedWorker or ServiceWorker)?

You can't share any memory outside of an agent cluster, so the identity preserving semantics would be disallowed, or it would be an actual copy. (What happens when you send an SAB over the agent cluster boundary?)

Also I don't think the module block needs to be a property-less object. As long as the value is stable in a given realm, it could very well be different objects in different realms and agents. Only the round trip property is observable.

Only the round trip property is observable.

True, but an implementation that only preserves the identity without doing actual sharing feels like a really weird cutout, and I would be against implementing such a thing.

Is it a reasonable expectation for developers that identity is preserved when sent to some targets but not others?

Definitely yes, because the "some targets but not others" distinction here is a process boundary, and it really behooves developers to understand what can be a process boundary and what cannot. Yes, it's the OS and security infra leaking through, but that's reality. Also this question only makes sense if the behavior were a transparent copy instead of an error, right?

Ok let's take a more probable scenario. You have a web page with some out of process iframes and some in process.
I believe a developer should be able to send module blocks to both. You're saying that a developer should understand which frames may be in a different process and won't round trip module blocks while preserving identity?

Btw, none of this is a problem if the module block is a new primitive value that is unusable as WeakMap keys.

I believe a developer should be able to send module blocks to both (so an error for out of process iframes is not appropriate). You're saying that a developer should understand which frames may be in a different process and won't round trip module blocks while preserving identity?

Yes? This is why we made COOP/COEP, right? It's certainly not ergonomic, but the tradeoff has been made for for better or for worse.
To be clear my position is, "if module blocks need to preserve identity to be usable as WeakMap keys across thread boundaries, then I prefer them to be actually shared things, and participate in the same restriction schemes as other shared things."

Btw, none of this is a problem if the module block is a new primitive value that is unusable as WeakMap keys.

That's certianly fine with me too as an implementer (and simpler). I have no horse in the race whether they should be usable in WeakMaps, I was responding to how I'd want the world to look if that was deemed important enough to try to enable.

I am a bit outside my realm of expertise, so I apologise for fluffy and vague terminology in what follow:
I was not making any statements about the “temporary” value in the other realm. I was proposing that if I send a module block to (let’s say) a worker and the worker sends it back, that the value I receive is identical to the one I originally sent. For all I care, the copy that the worker receives could be a completely independent copy and we restore the identity during structuredDeserialize() or something.
Would that allow to get the best of both worlds? I.e. keeping identity consistent within the same realm and allowing modules to be used in a WeakMap?
(Side note: It’s not a priority, so I am happy with either outcome here. I do think that using WeakMaps to store auxiliary data for types you don’t own is not that unusual, so it’d be nice to have.)

@surma whether the value in the other agent is different or not is completely unobservable, and can be considered an implementation detail (it would be observable for same origin realms).
I suppose one question I have for you is if you expect this round trip property to hold for out of process iframes/popups (e.g. 3rd party origin which hasn't or cannot opt into COOP/COEP)

I've been thinking about this again with regards to the new compartments/loaders proposal and I'm starting to think it matters less if multiple sends did correspond to multiple evaluations.
For APIs similar to blank worker a (weak) map could simply be maintained on the same thread:
class Worker {
    // Internally in worker
    // This could even be a WeakMap along with a FinalizationRegistry to allow
    // collection of such objects across threads
    readonly #cachedModuleWrapppers = new Map<ModuleSpecifier, WrappedModuleObject>();

    async addModule(module: Module | string): Promise<WrappedModuleObject> {
        if (this.#cachedModuleWrappers.has(module)) {
            return this.#cachedModuleWrappers.get(module);
        }
        // ....send module for evaluation to other thread
        // ....wait for evaluation
        // ....generate wrapper
        // ....store in cache
        // ....etc
        return moduleWrapper;
    }
}

For cases like my own example, users could instead just do:
// Incidentally I often wish there was an object version of Promise.all
const effects = {
    balloons: await worker.addModule(module {
        export function renderEffect(): ImageData {

        }
    }),
    discoLights: await worker.addModule(module {
        export function renderEffect(): ImageData {

        }
    }),
};

effects.balloons.renderEffect(); // Promise { ImageData }


s3 support for CloudImageService

I'm looking at using ImageProcessor.Web for processing images stored in s3.  Of course I can use it right now with the CloudImageService (have tested and it works fine) but I would have to make my buckets public and reference via http.
I was wondering if anyone has built a CloudImageService specifically for s3 that would enable you to specify the access key & secret and use the s3 api to retrieve the image?
If not, I might write one and contribute, would there be any interest?

Hi there,
Thanks for that.
ImageProcessor.Web uses the CloudImageService with http to ensure that there are not too many overheads fetching an image. I've a feeling adding service calls to S3 would incur many additional processing costs to the running server in comparison.
So unfortunately that would mean the additional functionality would not be something we are looking to add just now.
Incidentally, we're actually very close to releasing an S3 cache plugin and I'd love to have your input on that.
Cheers
James

Thanks for the quick response James.
Surprisingly I have done some benchmarking with another product which has native S3 support and it was still very fast, actually faster than ImageProcessor!  So I think the overhead is negligible if anything.
Anyway it would be pretty trivial to prototype it up, so if we settle on ImageResizer I will certainly look into it.


Changed Space and Mixed Tabs to Tabs per the .editorconfig File

Fixes #120

I am confused with these errors I not sure how to trouble shoot this issue!  It would help me to learn some new trouble shooting skills if someone could point me in the right direction!

I also apologize I completely spaced running a build locally before pushing to the GitHub.  But found the errors for some reason my VS was adding the required to several fields in the Tweets.cs and the Content.cs files l luckily had Rider available and it was not having that issue and the build was successful

I am not sure why the Playwright test failed here they ran to successfully in VS and Rider?

Looking at this now...  feels strange...

There I go thinking this would be a simple change, shouldn't break anything... Not!
Now I have to figure out why my VS was adding required to fields on it's own.

Thank you for following up on this.  I really appreciate these types of clean up tasks that ensure our code is consistent


Consider ed25519-zebra crate?

Presently the tendermint crate uses the ed25519-dalek vicariously through the signatory-dalek crate.
There's an alternative I think that's worth considering: ed25519-zebra. Both ed25519-dalek and ed25519-zebra are based on the underlying curve25519-dalek library. However, ed25519-zebra focuses on Ed25519 usage in consensus-critical (i.e. blockchain) contexts, where discrepancies in Ed25519 validation have been problematic in the past. Also, ed25519-zebra is written by curve25519-dalek author @hdevalence.
There are a few issues at play here: existing Ed25519 libraries don't properly implement RFC 8032, and RFC 8032 doesn't go far enough to remove edge cases in verification. Per @hdevalence, he aims for ed25519-zebra to be the first Ed25519 library to actually implement RFC 8032 verification logic correctly.
If you do decide to adopt ed25519-zebra it seems like you'd want to ensure the Go side has a matching solution, either by implementing the same verification checks that ed25519-zebra uses, or by using ed25519-zebra directly. I'm guessing the latter might be problematic as it seems unlikely Tendermint would adopt a Rust-based dependency.
More generally, even if you don't wind up adopting ed25519-zebra, I think it would make sense to more precisely specify the Ed25519 verification logic Tendermint uses as part of an overall Tendermint specification, as I assume it's presently "whatever Go does".
This seems like the sort of change it might be good to introduce in a chain upgrade (e.g. Stargate). Namely Tendermint only uses Ed25519 signatures for consensus, so previous chains' Ed25519 signatures are irrelevant (only the ECDSA/secp256k1 signed transactions are persisted across chain upgrades). This means introducing stricter Ed25519 verification logic during a chain upgrade carries no risk (to my knowledge) of existing signatures which previously verified but wouldn't verify under the stricter logic, since it's a brand new chain and therefore has no existing Ed25519 signatures to worry about.
/cc @zmanian

Just to update/clarify this: ed25519-zebra is aiming to implement ZIP 215 in its 2.x series and legacy Zcash-flavored validation in its 1.x series.
ZIP 215 defines precise validation criteria for Ed25519 signatures and verification keys to ensure that there are no edge cases in verification and that individual and batch verification produce identical results.  However, while these criteria are internally consistent (and thus suitable for consensus-critical applications), they aren't exactly the same as RFC8032 (which doesn't require conformant implementations to agree on whether signatures are valid) or the Go standard library (which does not conform to RFC8032 because it allows non-canonical point encodings).
However, it would not be difficult to implement ZIP 215 rules in Go and use that instead of the standard library implementation, and it might be preferable for a consensus-critical system like Tendermint to do so.  I'm not sure it's safe for tendermint-rs to use any Ed25519 implementation other than the existing Go one without carefully replicating its exact behavior (i.e., creating an ed25519-tendermint for the same reason that ed25519-zebra exists). I am also not sure what the policy of the Go standard library is around changes to Ed25519 validation criteria.  I assume that Go has a strong focus on maintaining compatibility, but if consensus-critical applications are not be top-of-mind, it's possible for breaking changes to be introduced under the guise of "stronger validation" as happened in libsodium.
The tracking issue for ZIP 215 support in ed25519-zebra is here: https://github.com/ZcashFoundation/ed25519-zebra/issues/16

Wow thanks for raising this and working on it.
Is it correct that neither ed25519-dalek nor ed25519-zebra are expected to be compatible with Go's x/crypto/ed25519 ?
And does the ambiguity in RFC 8032 apply even if not doing batch verification?
And what does ed25519-zebra 1.X target? Is it compatibility with some C++ implementation?
Presumably this is something other blockchain systems are going to be grappling with as well as ed25519 adoption picks up. We should probably open a corresponding issue in the Tendermint Go repo and target the next block protocol breaking release which will also include other changes to prepare Tendermint to support signature aggregation (eg. https://github.com/tendermint/tendermint/issues/2840)

Wow thanks for raising this and working on it.

Thanks, I'm glad it's useful work! I've been working on a cross-ecosystem survey of how different implementations behave on these edge cases using a list of test vectors I created for ZIP 215 and a blog post writeup explaining more of the context and motivation, but I haven't finished it yet.  I'd be happy to share a draft with you if you'd like.

Is it correct that neither ed25519-dalek nor ed25519-zebra are expected to be compatible with Go's x/crypto/ed25519 ?
And what does ed25519-zebra 1.X target? Is it compatibility with some C++ implementation?

Yes, ed25519-zebra 1.x is expected to be compatible with the specific point release of libsodium originally used in Zcash, and ed25519-zebra 2.x targets the ZIP 215 rules.  In general I think it's not safe to assume that any Ed25519 implementations are compatible unless they specifically advertise compatibility with each other. Even if they are coincidentally compatible at one point, if that compatibility isn't an explicit goal, a future release might be incompatible.  (This is what happened with libsodium, which changed validation criteria in point releases).

And does the ambiguity in RFC 8032 apply even if not doing batch verification?
Presumably this is something other blockchain systems are going to be grappling with as well as ed25519 adoption picks up and we'd presumably want to see something like ZIP 215 established as a common standard for libraries to target.

The ambiguity is in the spec, in the sense that conformant implementations are not required to agree on which signatures are valid.  It's possible to select a precise set of rules, but then it's not that an implementation is conformant with RFC 8032 or not, but with some specific choices.
Basically there are two choices to make:

Compatibility with batch verification -- do the validation rules allow implementations to perform batch verification, or not? In order to allow this, batch and individual verification must always agree, which means that individual verification MUST use the "cofactored" verification equation rather than the cofactorless one.

Compatibility with existing signatures accepted by other implementations (like Go's crypto/ed25519) that don't require canonically encoded points.  This is asking whether every signature that was considered valid by an existing implementation is considered valid under the new rules.  This allows using a new implementation in place of an existing one and "retconning" the new validation criteria onto the old signatures.  On the other hand, if the new rules are more strict than the previous ones, it might be possible for someone to insert a signature valid under the old rules and not the new ones, which could cause unexpected breakage. Note that there's no security impact to choosing the less strict validation criteria here, because they only affect signatures created with specially crafted low-order public keys -- the goal is just to have consistent criteria to prevent someone from injecting a signature into the chain that could later cause consensus divergence.

Each pair of choices on these decision points gives a different set of validation criteria.  The ZIP 215 rules are obtained by choosing yes to both, in order to allow batch verification and to ease the upgrade process.

Presumably this is something other blockchain systems are going to be grappling with as well as ed25519 adoption picks up and we'd presumably want to see something like ZIP 215 established as a common standard for libraries to target.
We should probably open a corresponding issue in the Tendermint Go repo and target the next block protocol breaking release which will also include other changes to prepare Tendermint to support signature aggregation (eg. tendermint/tendermint#2840)

Yes, I'd like it if other projects adopted these rules.  To this end I've started work on a Go implementation of these rules here: https://github.com/hdevalence/ed25519consensus
So far this just has vendored crypto/ed25519 source, but I should have the ZIP 215 rules (& tests) done soon. I'm less familiar with the practical mechanics of "doing Go" (from the software engineering point of view, releases, publishing, modules, api design, etc), so if you know anyone who'd like to help I'd appreciate a second set of eyes on it.

Update: I've added a VerifyConsensus function to that repo with an implementation of the ZIP215 rules.

cf https://github.com/golang/go/issues/40478#issuecomment-666043072

Update to this -- since this issue was filed, Tendermint now uses the ZIP215 rules. I've created https://github.com/penumbra-zone/ed25519-consensus for use in Penumbra.

Closed by #1046 / #1067


feat: rollback confirmation of credit option

Endpoint to call in the back button of Upload Documents Page

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

-17 of 19 (10.53%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.6%) to 86.734%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

app/routers/guest/applications.py
2
19
10.53%

Totals

Change from base Build<PHONE_NUMBER>:
-0.6%

Covered Lines:
1968

Relevant Lines:
2269

💛  - Coveralls

After the Calculator screen, there are two steps until the documents upload, first, it is the selection of the credit option and then there is confirmation, that is why a two-step rollback is needed.
Those fields that you mentioned are missing are the ones that are set in the selection step.
I'll add the new Application Action suggested.

@nahu any updates on this?


Update image spec fork with code from upstream

This PR updates our fork of image-spec with the commits from upstream so that we can vendor it into our containerd fork at fork/release/1.6. This is necessary because we currently rely on the ArgsEscaped field temporarily added in this fork, but containerd 1.6 relies on code in image-spec that's more up to date than this fork.
Once https://github.com/opencontainers/image-spec/pull/892 is merged in upstream, we can remove the need for this fork entirely. Since we don't know when that will happen, updating this fork to use in the meantime.

@kevpar fyi


asyncio.exceptions.IncompleteReadError after every request

getting the following warning after every request, besides the warning log itself everything works fine.
2024-10-02 10:45:14,122 WARNING asyncio_simple_http_server server.py _handle_client():219 - got a failure <class 'asyncio.exceptions.IncompleteReadError'>. disconnecting the client

Hi, I've added a http_server.trace_client_disconnection flag to enable/disable the client disconnection log https://github.com/matteobertozzi/asyncio-simple-http-server/commit/43a114caa86283ff4aef36f269e7e849282a31fd
http_server = HttpServer()
http_server.trace_client_disconnection = False
...


Why replace waybar config with the template?

Hi, can you tell me why you have this in the 96-generate-waybar-config.conf
# waybar config changes will only be respected every other time

'sleep 0.5 && cat $HOME/.config/waybar/config.template | sh /usr/share/sway/scripts/jsonreplace.sh .position $waybar_position >$HOME/.config/waybar/config'

With this code in the waybar will not load when I try and turn the num lock on by default when I add the code anywhere in the home config.  The code I am using to turn the num lock on is:
input * xkb_numlock enabled
But works great when I comment out the sleep section.

hi! this code is no longer present: https://github.com/Manjaro-Sway/desktop-settings/blob/sway/community/sway/etc/sway/config.d/96-waybar-config.conf
can you try to update the desktop-settings package from the manjao-sway repo?

It may be, that you could just have to remove /etc/sway/config.d/96-generate-waybar-config.conf

This might have something to do with my settings not being up to date.
warning: manjaro-sway-settings: local (4.3.2-5) is newer than community (1.0.0-1)
there is nothing to do

Did you try sudo pacman -Syyu manjaro-sway/manjaro-desktop?

This might have something to do with my settings not being up to date.
warning: manjaro-sway-settings: local (4.3.2-5) is newer than community (1.0.0-1)
there is nothing to do

This is because we're not an official community distro and did never update the package in the community repo. Which we definitely should.

Also when I updated the config, the home definitions file was called "defintions"  so none of it worked until I renamed the file.

Another change in the new config:  ~/.config/waybar/config
    "position": "bottom",
That overrides the $waybar_position setting in the definitions files.

yeah, that really is a problem. when we change things in the skeleton, those changes are not reflected in your home dir. this is how skeletons work and a problem across all distributions.
you can do that manually by copying the dotfiles from  /etc/skel/.config (waybar, sway) over the .config dir in your home directory. sorry for the inconveniences... this is basically the reason I tried to keep so much configuration in /etc/sway - so I can update stuff without issues like this.


GUA-514: Log record on error

To aid with debugging the integration with TxMA.
We'll want to revert this before we deploy the backend to production to make sure we don't log any personal or sensitive data.

Closing this because we figured out the problem before needing to log the events to CloudWatch


Flash improvement and added colorfade effect

I added a small feature so that the light can be used with the flash effect from Home Assistant out of the box.
Instead of looking only for the key "flash" in the JSON payload, it will now also check if there is a key called "effect" with the content "flash".
Now you can just add
effect: true
effect_list: [flash]

to your light configuration in HA. The number of flashes can be configured in config.h.

I also added the colorfade_slow and colorfade_fast effect which will cycle between 7 colors. The transition times can be configured in config.h.
The state is also shown correctly in HA. It is possible to adjust the brightness when in this mode and you can also trigger a flash and it will go back to fading afterwards.

Hey, @citruz. Thank you for the contribution! I'll try to make time this week to review and test this code, and then I'll merge it in.
(I just didn't want you to think I forgot about it.)

Did you already have time to review my changes?

Hi @citruz. Sorry for the delays, but I got a chance to review your changes and merge them in. I extended the feature a bit to support the new RGBW lights as well. If you get a chance to try out the updated version, please let me know.
Thanks for adding this feature!


Update gem loofah, remove gem haml (rm railroader)

Update the vulnerable gem "loofah" and remove the
vulnerable gem "haml".  The only quick way I found to do
this was to temporarily remove railroader :-(.
The plan is to restore railroader, but probably as a
separate executable which is a better idea anyway
(that will mean we have fewer gems internally to cause problems).
Signed-off-by: David A. Wheeler<EMAIL_ADDRESS>

I normally delay & wait for other comments. However, I really don't want to delay in this case.  It's not clear how exploitable this is, but I don't want to find out.


Removed deprecated params from documentation

SkipDocker was removed in https://github.com/Microsoft/Virtualization-Documentation/commit/0477dc59592a498c8b8db24dc7fc70f222840864
NATSubnetPrefix was removed in https://github.com/Microsoft/Virtualization-Documentation/commit/75098699b789d39a362a8d03866dc2503ab51237
So I removed them both from the README.

@mebersol @enderb-ms looks good to me :).  Look good to you?

@taylorb-microsoft

LGTM


SAA-875 small change to ensure when an acitivity end date is change we cannot end up with an allocation end before the start.

This resolves a gap in the update activity end date process whereby and allocation end date can end up before the allocation start date.

Codecov Report
Patch coverage: 100.00% and no project coverage change.

Comparison is base (26ae731) 85.06% compared to head (1353066) 85.06%.

Additional details and impacted files
@@            Coverage Diff            @@
##               main     #425   +/-   ##
=========================================
  Coverage     85.06%   85.06%
- Complexity     2120     2123    +3
=========================================
  Files           285      285
  Lines          8014     8016    +2
  Branches        463      463
=========================================
+ Hits           6817     6819    +2
  Misses          937      937
  Partials        260      260

Impacted Files
Coverage Δ

.../hmppsactivitiesmanagementapi/entity/Allocation.kt
94.87% <100.00%> (+0.06%)
:arrow_up:

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


MNT: Re-rendered with conda-smithy 3.1.6 and pinning 2018.06.19

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


QoL improvement: submit/next/prev buttons on navbar

Aside from an internal command line tool, we could have small buttons on the navbar to pop up a modal to submit a flag, to launch the next challenge, and to launch the previous challenge.

Hey everyone,
I noticed this issue has been open for a while. I'd love to work on it.

Sure, we'd love the help!
One issue is that we're running out of space in the nav bar. However, we have this little dude:

We could replace it with a hamburger (https://fontawesome.com/icons/bars?s=solid) and have stuff like:

Hide Navbar (or Show Navbar if Navbar is hidden)
If challenge is started: Submit Flag Restart Challenge Next Challenge Previous Challenge
If challenge is not started: Start Recent Challenge
Maybe move Admin over here?

Sounds like a good idea.
I see a solution for all points.
But I need some help for the start recent challenge:
How do I determine the recent challenge?
Iterate through all unsolved  dojos -> modules -> challenges ? They are sorted by index I guess ?

Hmm, good point… for now, let’s ignore the issue and just not have that one.On Jul 16, 2024, at 11:40 PM, Jens Häuser @.***> wrote:
Sounds like a good idea.
I see a solution for all points.
But I need some help for the start recent challenge:
How do I determine the recent challenge?
Iterate through all unsolved  dojos -> modules -> challenges ? They are sorted by index I guess ?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

What do you think about that layout ?

What about a button in the middle (https://fontawesome.com/icons/rotate-left?f=classic&s=solid) with the current challege name that says "Restart current".
And then maybe just something that more closely resembles the existing flag submit line at the bottom (we wouldn't need to say Mars anymore if its on the restart button):

Or something closer to that (fine if we have a slightly different feel to match this popup).
I'm mildly concerned about long challenge names and what that might do to this UI though (especially with the added 3rd button). You could test for example with some of the longer challenge names like in https://github.com/pwncollege/linux-luminarium.
Another edge case to consider: what if there isn't a prev/next challenge. I assume the current idea (which is totally fine!) is to only do prev/next relative to the current module. What do you think the UI should look like then?
Overall though, this feature sounds super exciting! Thank you!

I changed the layout and added the restart button.
If a challenge is the first or last the button could be display-none, invisible or just disabled 🙂
So far, starting the previous, current or next challenge works and the buttons change accordingly to the new previous, current and next challenges.
Submitting the flag also works.


Train/Test Split for Pretraining via imagenet

What is the train-test split used for the pre-training on ImageNet? Do you have a file that describes which image goes where? What is the split percentage?

It's the default train/val splits for imagenet.

It already comes divided into train and val. You can download it from multiple sources, e.g. https://huggingface.co/datasets/imagenet-1k/tree/main


Support websockets

Not sure exactly what this should look like, but for Actor it would be nice to be able to establish websocket connections to them to make it easier to implement realtime applications like chat and games.

Nats does web sockets and can leverage the many FDB instances as it was client side load balancing
The whole actor system with FDM seems like a great match with NATS.
i use nats with Wazero.
Nats has a KV and Blob store and so can act as a store and forward network into Nola too .
nats.go also compilesvto wasm . I use it inside browsers where it makes web socket connects to the nats server

I use it for serverless, because it is a control pane and a data plane. So you can configure an endpoint for a massage exchange, and then let many Actor use that endpoints.  You can also secure that endpoint and create users ( which the actors will i guess impersonate ) - see the NSC tool.
In terms of transpots you get NATS, WS and MQTT. Its easy to also make it work over http. you can even stick Caddy in front of it and then have both NATS and HTTP routing through it.
Free load balancing because the nats.go client does client side LB.
The NATS Server can be clustered and gatewayed. Typically 3 per DC and 3 DC's is enough for a global setup.
The NATS client will then route to the nearest NATS Server, and then to your Actor and then your WASM Func......
This client ( nats.go ) client can be compiled to wasm and run in a browser even.

Backgorund
NATS is really big and used by Intel, Nokia, Mastercard and many other projects that need a global control plane and data plane that self runs. Been around for 10 years. Before that it was TIBCO Rendevous, but the architect left and created NATS.
NATS can eiher run in mem or use durable store ( aka jetstream ).
When i saw the actors design you had NATS was an obvious thing.
Lots of projects using NATS with Wazero too: https://github.com/bots-garden/capsule
These are the bits you want. Copied out of my makefile:

# NATS-SERVER
# https://github.com/nats-io/nats-server
NATS_SERVER_BIN_NAME=nats-server
#NATS_SERVER_BIN_VERSION=v2.4.5
NATS_SERVER_BIN_VERSION=v2.9.9

# NSC
# https://github.com/nats-io/nsc
NATS_NSC_BIN_NAME=nsc
NATS_NSC_BIN_VERSION=2.7.5

# NATS_TOP
# https://github.com/nats-io/nats-top
NATS_TOP_BIN_NAME=nats-top
NATS_TOP_BIN_VERSION=v0.5.3

# NATS
# https://github.com/nats-io/natscli
NATS_CLI_BIN_NAME=nats
NATS_CLI_BIN_VERSION=v0.0.35

I also run wrapped for SSE and quic above it as needed . Web sockets works create as does mqtt.

Saw tons of registry issues. I use it as a registry too in lots of projects Nats kv and nats obj Store is useful for these use cases.
docs make it clear so you can check them


Update Jettison to 1.5

Thank you for the contribution. It was merged directly as 0e179dbac4d591e341d30e68f0da9c90fd279e3a to keep commit history cleaner. Your contribution is still credited to you.


[Win32] fails on '_file_time_now()'

The test/main.lua works fine for the most part. But some times I get this error:
Running tests...
-- directory_iterator --
-- non_member_functions --
Not same; value 1: 'file_time_type.filesystem: 00000218DE98A668', value 2: 'file_time_type.filesystem: 00000218DE98A938'
stack traceback:
        ./test/tests/non_member_functions.lua:251: in function 'non_member_functions.file_time_now'
-- path --
-- directory_entry --
...tests completed
-- Test summary --
        Tests   Checks
Total:     70      204
Failed:     1        1
>>> tests failed!

A difference of 0x2D0 == 720 nano-sec? A feature of the NTFS cache?
I'm on Win-10 using Lua-5.4. And filesystem.dll was built with MSVC (VS-2022 Preview).
But using clang-cl (the MSVC compiler driver from LLVM), it crashes in fs_read_symlink()!

I just noticed your issue that has opened almost 2 months ago, sorry for that.
To test Windows compatibility I used a Windows 10 VM (Virtual Box) on Linux (Manjaro). The sources and the Solution are in a directory in my Linux home directory which is shared with the VM.
I don't know which version of Visual Studio was used at the time the library was made public but running the tests again with Visual Studio 17.3.6 seems to have issues with symlinks as you already noticed.
I will try to debug the symlink issue on a non-VM Windows 10 and solve the the problem with file_time_now test.

The issues I had with the symlink function is likely  caused by the mechanism to share the directory with sources between my Linux host and the Windows 10 VM. There were no issues on a non-VM Windows 10 machine.
I've found the cause of the crash when the filesystem module is built with clang-cl by Visual Studio.
The workaround is removing noexcept on this line.
I think this is an issue with Clang since the all exceptions are handled by a catch( ... ) and no other C++ exception is thrown from the function. Maybe Clang is confused by long jumps that Lua uses to propagate errors.
The file_time_now test passed each time I ran the tests. The order in which the tests are executes is not deterministic and therefore hard to reproduce.
I have to do some more analyses.

A difference of 0x2D0 == 720 nano-sec? A feature of the NTFS cache?

The values printed by the failed test are object IDs / addresses, not values.
I think the issue the failing test is caused by the calculation of the time difference. The time difference is templated on a std::ratio for which the values of the numerator / denominator are platform defined.
The file system module converts the file time difference to seconds and is returned to the Lua world as a (floating point) number. At this point some accuracy may be lost and causes the test to fail.
I choose to convert the file time difference to seconds to avoid platform defined behavior in the Lua world.
There are two possibilities; accept the loss of accuracy and adapt the test with to tolerate an epsilon or create file time duration objects that behave like numbers. The latter may have performance impact since the duration object will be an user data object.

I been thinking about it for some time and will probably go for the duration userdata solution.

I just made a commit with the duration userdata solution.
For now I will wait for some time in case someone finds new related issues.


Support non-UTF-8 symbol probing

See conversation: https://github.com/aya-rs/aya/pull/742#discussion_r1291191539

https://github.com/aya-rs/aya/pull/765


Fix .footer-icon color syntax problem. Who did that?

Fix double # characters at the color's declaration

👍


Update Steam Avatar CDN URL + Player spawn hook

It seems like the #3 avatar issue is correct as double-checked. Here's an example of my avatar: https://avatars.cloudflare.steamstatic.com/23de107cbb6c38ccace7e8bda100fa872044918b_full.jpg
Added an if statement that should trigger if the CDN URL dies or changes, which will at least give a bit more input than the program outright crashing.
Add PlayerSpawn hook as requested in #4

Probably preferable to do something similar failsafe wise on the Lua end.

I'm not as 100% sure about the GLua end as do not write typically that much GLUA nowadays but the hook itself should be right, but not sure if it utilises the cached avatar correctly.


Standardise nomenclature of variants of concern and Variants of interest

In the config.yaml, the "variants to be highlighted" are called variants of concern (https://github.com/IKIM-Essen/uncovar/blob/master/config/config.yaml#L89).
In the report, the "variants to be highlighted" are called" Variants of interest(https://github.com/IKIM-Essen/uncovar/blob/master/workflow/scripts/generate-overview-table.py#L206).
This non-uniform nomenclature is confusing and wrong to use for single Mutations.
We should rename it in something like Mutation Profiles of VOC/VOIs. Maybe we should even split the Variants of interest into Variants of Concern, Variants of Interest, Variants Under Monitoring and find an automated way to get the latest Variants of something. Maybe pangolin repo offers VOCs, VOIs, and VUMs.
Who definitions are: (https://www.who.int/en/activities/tracking-SARS-CoV-2-variants/)
Variants of Concern (VOC)
A SARS-CoV-2 variant that meets the definition of a VOI (see below) and, through a comparative assessment, has been demonstrated to be associated with one or more of the following changes at a degree of global public health significance:

Increase in transmissibility or detrimental change in COVID-19 epidemiology; OR
Increase in virulence or change in clinical disease presentation; OR
Decrease in effectiveness of public health and social measures or available diagnostics, vaccines, therapeutics.

Variants of Interest (VOI)
A SARS-CoV-2 variant :

with genetic changes that are predicted or known to affect virus characteristics such as transmissibility, disease severity, immune escape, diagnostic or therapeutic escape; AND
Identified to cause significant community transmission or multiple COVID-19 clusters, in multiple countries with increasing relative prevalence alongside increasing number of cases over time, or other apparent epidemiological impacts to suggest an emerging risk to global public health.

Variants Under Monitoring (VUM)
A SARS-CoV-2 variant with genetic changes that are suspected to affect virus characteristics with some indication that it may pose a future risk, but evidence of phenotypic or epidemiological impact is currently unclear, requiring enhanced monitoring and repeat assessment pending new evidence.

Closed with Pr #416


cli: Option log-format=json is ignored for plugin logs

Describe the bug
Using -log-format=json does not apply to logging of (hc)plugin
To Reproduce
Steps to reproduce the behavior:

Start tusd using -log-format=json and (hc)plugin hook
Check logs
The logs of the main process are formatted as json, the plugin logs are formatted as plain text

Expected behavior
All logs are formatted as json
Setup details
I tried using both "log" and hc-log in the plugin.
Initializing the logger in the plugin using
hclog.New(&hclog.LoggerOptions{
		Level:      logLevel,
		JSONFormat: true,
	})

does not produce the desired results.
Instead I had to add JSONFormat: true, to https://github.com/tus/tusd/blob/50b9ff5623c26c856ec97e2e0a9a44c0f6baaceb/pkg/hooks/plugin/plugin.go#L36-L40
It would be nice to either pass the Json flag to the hclogger instance or if something like an hclog->slog adapter was use d (like https://github.com/evanphx/go-hclog-slog, but in the opposite direction. Not sure if such a package exists / is possible)
Log output "as is"
{"time":"2024-03-19T14:29:53.249651675Z","level":"INFO","msg":"Using '/srv/tusd-data/data' as directory storage."}
{"time":"2024-03-19T14:29:53.250772425Z","level":"INFO","msg":"Using 0.00MB as maximum size."}
{"time":"2024-03-19T14:29:53.250811027Z","level":"INFO","msg":"Using '/usr/local/bin/tusd-hook-plugin' to load plugin for hooks"}
2024/03/19 02:29:53.251028 [DEBUG] plugin: starting plugin: path=/usr/local/bin/tusd-hook-plugin args=["/usr/local/bin/tusd-hook-plugin"]
2024/03/19 02:29:53.251524 [DEBUG] plugin: plugin started: path=/usr/local/bin/tusd-hook-plugin pid=15
2024/03/19 02:29:53.251638 [DEBUG] plugin: waiting for RPC address: plugin=/usr/local/bin/tusd-hook-plugin
2024/03/19 02:29:53.259521 [DEBUG] plugin.tusd-hook-plugin: plugin address: network=unix address=/tmp/plugin1135885035 timestamp=2024-03-19T14:29:53.259Z
2024/03/19 02:29:53.262943 [INFO]  plugin.tusd-hook-plugin: Setup: timestamp=2024-03-19T14:29:53.26
...

Log output using: https://github.com/quality-leftovers/tusd/tree/plugin-log-json
{"time":"2024-03-19T14:13:11.704897099Z","level":"INFO","msg":"Using '/srv/tusd-data/data' as directory storage."}
{"time":"2024-03-19T14:13:11.705671906Z","level":"INFO","msg":"Using 0.00MB as maximum size."}
{"time":"2024-03-19T14:13:11.705711607Z","level":"INFO","msg":"Using '/usr/local/bin/tusd-hook-plugin' to load plugin for hooks"}
{"@level":"debug","@message":"starting plugin","@module":"plugin","@timestamp":"2024/03/19 02:13:11.705805","args":["/usr/local/bin/tusd-hook-plugin"],"path":"/usr/local/bin/tusd-hook-plugin"}
{"@level":"debug","@message":"plugin started","@module":"plugin","@timestamp":"2024/03/19 02:13:11.706353","path":"/usr/local/bin/tusd-hook-plugin","pid":13}
{"@level":"debug","@message":"waiting for RPC address","@module":"plugin","@timestamp":"2024/03/19 02:13:11.706474","plugin":"/usr/local/bin/tusd-hook-plugin"}
{"@level":"debug","@message":"using plugin","@module":"plugin","@timestamp":"2024/03/19 02:13:11.722045","version":1}
{"@level":"debug","@message":"plugin address","@module":"plugin.tusd-hook-plugin","@timestamp":"2024/03/19 02:13:11.722055","address":"/tmp/plugin3216457465","network":"unix","timestamp":"2024-03-19T14:13:11.721Z"}
{"@level":"info","@message":"Setup","@module":"plugin.tusd-hook-plugin","@timestamp":"2024/03/19 02:13:11.728717","timestamp":"2024-03-19T14:13:11.728Z"}

Thank you for reporting this. The easiest solution would be to set hclog.LoggerOptions.JSONFormat = true if the JSON format is specified in the flags. This could be passed in using a new field in the PluginHook struct. Would you be willing to open a PR for this?


How to mock or stub a local function

The following is the code to be tested, and they are all in json2xml.lua
--- json2xml.lua
local function FirstToUpper(str)
  return (str:gsub("^%l", string.upper))
end

local function LabBefore(tab,label)
  tab[#tab+1]="<"
  tab[#tab+1]=FirstToUpper(label)
  tab[#tab+1]=">"
end

if _TEST then
  M._IsArrayTable = IsArrayTable
  M._FirstToUpper = FirstToUpper
end

The following is unit test code:
   local json2xml = require "json2xml"
   describe("unit test of LabBefore",function()
        it("should be <label>",function()
        local tab = {}
        local key = key
        json2xml._LabBefore(tab,key)
        local str = table.concat(tab)
        assert.are.same("<key>",str)
        end)
    end)

When I attempted to make a unit test of LabBefore ,it reported the error :
unit test of json2xml.lua  unit test of LabBefore should be <label>
./json2xml.lua:54: attempt to index local 'str' (a nil value)

How could I mock or stub the function FirstToUpper? Or some way to invoke it?

not sure why you want to mock it (also wouldn't know how). Your problem is not with FirstToUpper but with the unit test. Specifically the line local key = key, most likely it should have been local key = "key". (using a linter like luacheck would have immediately triggered on this global access.)
So you could add an assertion to FirstToUpper like;
local function FirstToUpper(str)
  assert(type(str) == "string", "1st argument must be a string")
  return (str:gsub("^%l", string.upper))
end

and then add unit tests for it to prove it only accepts strings.

not sure why you want to mock it (also wouldn't know how). Your problem is not with FirstToUpper but with the unit test. Specifically the line local key = key, most likely it should have been local key = "key". (using a linter like luacheck would have immediately triggered on this global access.)
So you could add an assertion to FirstToUpper like;
local function FirstToUpper(str)
  assert(type(str) == "string", "1st argument must be a string")
  return (str:gsub("^%l", string.upper))
end

and then add unit tests for it to prove it only accepts strings.

The point is I wanna to make the unit test of LabBefore not 'FirstToUpper'.
When I attempted to make the function LabBefore , it invokes FirstToUpper in   LabBefore and reports an error. I wonder if it was the influence of the function  FirstToUpper. For this reason I tried to mock the FirstToUpper to avoid external influence

Then you need to expose FirstToUpper in the
  M._IsArrayTable = IsArrayTable
  M._FirstToUpper = FirstToUpper
end```
block. I don't think there is a way outside of doing nasty vm internal stuff to do exactly what you're asking.


Create collage_maker.py

@vasujindal1 please star the repo if u think this helped u for hacktoberfest :)


Very long system/startup time for loading clpz

ulrich@p0:/opt/gupu/new-trealla$ time ./tpl -f -g 'use_module(library(clpz)),halt'.

real	0m12.728s
user	0m8.488s
sys	0m4.075s
ulrich@p0:/opt/gupu/new-trealla$ time ./tpl -f -g 'halt'.

real	0m0.236s
user	0m0.207s
sys	0m0.023s

Compare this to Scryer:
ulrich@p0:/opt/gupu/scryer-prolog$ time target/release/scryer-prolog -f -g 'use_module(library(clpz)),halt'.

real	0m2.646s
user	0m2.461s
sys	0m0.059s
ulrich@p0:/opt/gupu/scryer-prolog$ time target/release/scryer-prolog -f -g 'halt'.

real	0m0.600s
user	0m0.497s
sys	0m0.012s

Probably goal_expansion / term_expansion. Never optimized for using that.
On Tue, Sep 19, 2023 at 4:57 PM UWN @.***> wrote:

@.***:/opt/gupu/new-trealla$ time ./tpl -f -g 'use_module(library(clpz)),halt'.
real	0m12.728s
user	0m8.488s
sys	0m4.075s
@.***:/opt/gupu/new-trealla$ time ./tpl -f -g 'halt'.
real	0m0.236s
user	0m0.207s
sys	0m0.023s
Compare this to Scryer:
@.***:/opt/gupu/scryer-prolog$ time target/release/scryer-prolog -f -g 'use_module(library(clpz)),halt'.
real	0m2.646s
user	0m2.461s
sys	0m0.059s
@.***:/opt/gupu/scryer-prolog$ time target/release/scryer-prolog -f -g 'halt'.
real	0m0.600s
user	0m0.497s
sys	0m0.012s
—
Reply to this email directly, view it on GitHub
https://github.com/trealla-prolog/trealla/issues/340, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFNKSETO2CEJWS2VZIFTLSDX3E66JANCNFSM6AAAAAA45ZWLXA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

I notice the source uses both get_atts/2 & get_attrs/2 (SWI compatible, which uses goal_expansion to the former). This should probably be fixed in source.

Much better, still I do not understand all the system time, where does this come from? Like all these clock_gettime and brkcalls...

ulrich@p0:/opt/gupu/new-trealla$ time ./tpl -f -g 'use_module(library(clpz)),halt'.

real	0m6.120s
user	0m4.277s
sys	0m1.632s   % where does this come from?

This is so extreme high. On the same machine, Scryer just uses (see above) sys	0m0.012s. System time is not so much relevant for its absolute value but it means that on a heavily loaded system, the Prolog will behave not very well.

For me...
~/trealla (devel) $ time tpl -f -g 'use_module(library(clpz)),halt'
real 0m1.045s
user 0m0.989s
sys 0m0.051s
~/trealla (devel) $ time scryer-prolog -f -g
'use_module(library(clpz)),halt'
real 0m0.513s
user 0m0.495s
sys 0m0.017s
~/trealla (devel) $
On Tue, Sep 19, 2023 at 8:41 PM UWN @.***> wrote:

@.***:/opt/gupu/new-trealla$ time ./tpl -f -g 'use_module(library(clpz)),halt'.
real	0m6.120s
user	0m4.277s
sys	0m1.632s   % where does this come from?
This is so extreme high. On the same machine, Scryer just uses (see above) sys
0m0.012s. System time is not so much relevant for its absolute value but
it means that on a heavily loaded system, the Prolog will behave not very
well.
—
Reply to this email directly, view it on GitHub
https://github.com/trealla-prolog/trealla/issues/340#issuecomment-1725257519,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFNKSET4COMFDH4K4VWW3TTX3FZGPANCNFSM6AAAAAA45ZWLXA
.
You are receiving this because you commented.Message ID:
@.***>

Sorry, I confused the numbers of Scryer (but there is still that big difference) Scryer uses 0m0.059s system time, and Trealla 0m1.632s. No remote file system involved. Should do this test on a newer machine.

g1:
Trealla
real    0m0.653s
user    0m0.621s
sys     0m0.032s

vs Scryer
real    0m0.396s
user    0m0.385s
sys     0m0.008s

Best I can do for now. Further improvement is of course possible.
~/trealla (devel) $ time tpl -f -g 'use_module(library(clpz)),halt'

real	0m0.586s
user	0m0.567s
sys	0m0.018s

~/trealla (devel) $ time scryer-prolog -f -g 'use_module(library(clpz)),halt'

real	0m0.513s
user	0m0.498s
sys	0m0.013s


added standard institue of technology

<EMAIL_ADDRESS>

@shiddhant Pull request merged. Thank you!


Skip formatting macro_rules! that are not using {}

A body of macro_rules! can be surrounded by {}, (); or [];. rustfmt can handle the first one, but cannot the others. IMO the latter two are rarely used, so this PR just skip formatting those to avoid panicking.
Closes #2466.

Thanks!


[Event Hubs Client] Track Two: Second Preview (.NET Core 3 Fix)  …

Summary
The intent of these changes is to correct a build error under .NET Core 3 preview (3.0.100-preview7-012821) regarding a decorator needed for cancellation of async enumerables.
Last Upstream Rebase
Thursday, August 8, 2019  11:18am (EDT)
Related and Follow-Up Issues

EventHubs fails to build with 3.0 preview7 SDK (#7151)

We might need to pull in newer SDK

We might need to pull in newer SDK

We're about a month from the announced GA date so things should be relatively stable.   It would be a helpful, I think, to think about bumping the CI environment.   Outside of messing around with global.json, is there a way that you know of which would allow us to build using the two different .NET Core SDKs as part of validation for PRs?

is there a way that you know of which would allow us to build using the two different .NET Core SDKs as part of validation for PRs?

I don't think we need two versions. We just need to update our current preview to a later one.


Update bundle_ko.properties files several projects

Hi, I'm Seongbae Chang who is a developer in South Korea. I have used DBeaver for a long time. I want to contribute your project by translating from English to Korean. From now, I want to translate bundle.properties files in your project continuously.

That's great, thanks!

Thank you!. Nowadays many developers in Korea are using DBeaver. I'll update other translation files soon.


Build on Windows

Having a look …

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Travis build actually passed: https://travis-ci.org/conda-forge/pkg-config-feedstock/builds/498873335
The red cross is just an artefact of my force pushes.
@conda-forge/pkg-config This is ready for review.


Issue140/movingemails

Closes #140.

So moving worked fine :D cool! But the List of Folders, was only targeting child folders on the first level. But on my Tonline Account e.g. all folders are a subfolder of the inbox. So the Move Menu only listed INBOX.
So i added a simple BFS to the Folder Tree, which will navigate and collection folders through all child folders. But still not very optimal.
There is a option to add submenus to a menu. So we should think about adding a dynamically generated submenu for each folder (which contains the children of each folder). I just added the Items retrieved from the BFS and add a few spaces for first level children. But i am not sure, whether we should create a new issue for "full" child-folder support, or include it in this one...What do you think? IMO it would take quite some time to correctly build a dynamic context menu with correct subfolders (and subfolders in them - if there are any)

Do we still need the Move to trash? We can do this with the new context menu, can't we?

?I would keep, but perhaps rename it "Delete".

From: David Hennemann<EMAIL_ADDRESS>Sent: 04 July 2018 22:49
To: hpi-swa-teaching/IMAPClient
Cc: Walter, Marius; Author
Subject: Re: [hpi-swa-teaching/IMAPClient] Issue140/movingemails (#143)
Do we still need the Move to trash? We can do this with the new context menu, can't we?

You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/hpi-swa-teaching/IMAPClient/pull/143#issuecomment-402557327, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AXwqYQb3I560I7dEmjt19R-kTjaMUXPzks5uDSpYgaJpZM4VBAKs.


Default notification settings should be global

Expected behavior
There should be a default notification setting in the global settings menu (ringtone, led, etc..), to simplify usage. It would be effective on all accounts which are not otherwise configured.
Actual behavior
Notificiations can only customized on a per-account base, which is inconvenient.
Steps to reproduce

Environment
K-9 Mail version:
5.600
Android version:
8.1
Account type (IMAP, POP3, WebDAV/Exchange):
n/a
Please take some time to retrieve logs and attach them here:

That would lead to a more complex user interface. Because every notification setting would have an added "use global default" value. Notification settings aren't changed that frequently. So I don't think the added complexity would safe users a lot of time.
With newer Android versions we can only influence the notification settings at creation time of the notification channel anyway. To modify the settings users have to configure the channel using Android's notification user interface.


Some fixes to avoid warnings from RGB24/UInt32 convert->reinterpret deprecation

This is cherry-picked from images-next.

Coverage decreased (-0.2%) to 78.706% when pulling d41946ba3faf9e91357d46083b46e676f210ead1 on teh/rgb24 into d20aa188c2bca35bd69b3d109991e6b91e82d05b on master.


Remove unused 'resident' option

Remove unused 'resident' option, fixes #340

Hi @lukeindykiewicz,
Thank you for your contribution! We really value the time you've taken to put this together.
Before we proceed with reviewing this pull request, please sign the Lightbend Contributors License Agreement:
http://www.lightbend.com/contribute/cla

To validate this pull request against other sbt modules, please visit this link.

@lukeindykiewicz Thanks for the contribution, having a look at it now, we'll see what the CI reports :smile:.

CLA assigned

To validate this pull request against other sbt modules, please visit this link.

It seems this requires a manual rebase, I'll do it as soon as I can.

To validate this pull request against other sbt modules, please visit this link.

Merging, things haven't changed here, it was a clean rebase. /cc @eed3si9n


Plans to fusing matmul with xentropy?

@mgmalek Hi, great work!
Do you have any plans to further fuse the torch.matmul with xentropy inside one kernel to get rid of the loops?
I think it's a little bit more involved as you may need to utilize super grouping tricks to match the performance with GEMMs if necessary.

I think a CUDA graph capture is enough. Writing back to global memory is unavoidable, fusion can only reduce the overhead of kernel launch.

@YouJiacheng yea, if doing addmm outside, I think the overhead is inevitable.
Also I think the benefits of current impls could be minor as we must allocate tensors for dw, for very large hidden size and relative small bsz x ctx, there's not much difference from the size of logits.
Maybe that's why flashattn does not provide such alg lol.


in_tail: Ensure to discard TailWatcher with missing target when follow_inodes

Which issue(s) this PR fixes:
Not related to a particular issue, but it can have something to do with reported log duplication or resource leak phenomenon about in_tail.
What this PR does / why we need it:
Ensure to discard TailWatcher with missing target when follow_inodes.
For example, when a rotation process is slow, there is a small time lag between moving and adding files.
There is a possibility that StatWatcher notifies too quickly to the TailWatcher before the new file is moved to that target path. From the TailWatcher, it appears as if the file is resurrected once it disappeared.
In this case, refresh_watcher can't recognize it, so TailWatcher needs to discard self correctly.
In the previous implementation, it was not done.
So it caused the handle leak and log duplication.
(Please check the added test case)
Because of the problem https://github.com/fluent/fluentd/pull/4237#issuecomment-1633358632, log duplication can still occur during rotate_wait.
We need to set rotate_wait 0 for a workaround.
(Duplication will occur if refresh_watcher is called during the rotate_wait. We need the mechanism not to add duplicated TailWathcer with detaching TailWatcher.)
Docs Changes:
Not needed.
Release Note:
Same as the title.
How to Reproduce:
<source>
  @type tail
  tag test
  path /path/to/test.log*
  pos_file /test/fluentd/pos/pos
  read_from_head true
  follow_inodes true
  refresh_interval 15s
  <parse>
    @type none
  </parse>
</source>

<match test.**>
  @type stdout
</match>

A: initial start

test.log

B: move the file

test.log1

C: add the new current file

test.log
test.log1

D: wait rerfresh_watcher TWICE

first: add TailWatcher for test.log (new inode)

this overwrites @tails[test.log] so old inode information is lost from @tails at this timing

second: add TailWatcher for test.log1 (old inode)

E:  append logs to test.log1

Because now there are 2 TailWatchers for test.log1, log duplication occurs.

TailWatcher(test.log, old inode) (orphan) (This actually opens the file handle of test.log1)
TailWatcher(test.log1, old inode)

When StatWatcher (or TimeTrigger) notifies between B and C, then the TailWatcher becomes an orphan, and a handle leak happens.

I will check this

https://github.com/fluent/fluentd/actions/runs/5539804706/jobs/10111142203?pr=4239

I will check this
* https://github.com/fluent/fluentd/actions/runs/5539804706/jobs/10111142203?pr=4239

I think this is just a list order problem. I will improve the test.

It seems that log duplication and handle leak still can occur on macOS...
I will check it 😢
https://github.com/fluent/fluentd/actions/runs/5539804708/jobs/10111141849?pr=4239
https://github.com/fluent/fluentd/actions/runs/5539804708/jobs/10111141988?pr=4239

It seems that log duplication and handle leak still can occur on macOS... I will check it 😢
https://github.com/fluent/fluentd/actions/runs/5539804708/jobs/10111141849?pr=4239 https://github.com/fluent/fluentd/actions/runs/5539804708/jobs/10111141988?pr=4239

It seems that this can happen only on macOS.
I can reproduce this on my macOS (Ventura, Apple M1) too, but I can't reproduce it on my Windows 10.

It seems that log duplication and handle leak still can occur on macOS... I will check it 😢
https://github.com/fluent/fluentd/actions/runs/5539804708/jobs/10111141849?pr=4239 https://github.com/fluent/fluentd/actions/runs/5539804708/jobs/10111141988?pr=4239

It seems that this can happen only on macOS. I can reproduce this on my macOS (Ventura, Apple M1) too, but I can't reproduce it on my Windows 10.

It can happen on Windows and macOS because StatWatcher does not work on those platforms (specification).
So this is merely a matter of the interval time between moving and adding files.
I will change the sleep time a bit longer for those platform to make the test valid for those platforms.

The above problems are fixed.

I'm sorry. There was an easy mistake.
https://github.com/fluent/fluentd/actions/runs/5539804706/jobs/10111142203?pr=4239

Rebased to the latest master.

Thanks!

Thanks for your review!


Basic ErrorPage functionality

This PR improves on the current error handling functionality, redirecting to an ErrorPage when an error occurs.
Currently the existing (ancient) ErrorPage has been used; styling and functionality requirements will need to be finalized and implemented before this PR can be considered ready for merging.
Error examples:

Google file not found:

Author does not have editor access to the brew:

I would suggest the following text to replace the GD 404 brew text:

Your brew is not here
This error tells us your file was saved on your Google Drive, but the link you tried to open doesn't work anymore. Since the Homebrewery cannot delete your your personal files from Google Drive without you clicking the delete button, there are three most likely possibilities:

You have accidentally deleted the Google Drive files. Look on your Google Drive and make sure the Homebrewery folder is still there, and that it holds your brews as text files.

You have accidentally changed the sharing settings for your files. If the files are still on Google Drive, change all of them to be shared "with everyone who has the link" so the Homebrewery can access them.

Rarely, it might mean that your Google Account is full or has been closed by Google (for inactivity, violating some policy of theirs). Make sure you can still access your Google Drive normally and upload/download files to it.

If you can't find it, Google Drive usually puts your file in your Trash folder for 30 days. Assuming you didn't empty the trash right after, it might be worth checking. You can also look on the right side of the page while logged into Google Drive and look at the Activity tab. This can help you pin down the exact date the brew was deleted and by whom.
If you still can't find it, some people have had success asking Google to recover accidentally deleted files. You can visit this link https://support.google.com/drive/answer/1716222?hl=en&ref_topic=7000946
At the bottom of the page there is a button that says "Send yourself an Email" and you will receive instructions on how to request the files be restored.
Also note, at no point are you "forced" to save your files on Google Drive. You can always set any brew to be stored on your own Google Drive, or on the Homebrewery servers, by clicking the Google drive icon by the brew title and choosing "transfer my brew to/from Google Drive".

The Devs

Please suggest any change needed, this is the answer we've been giving to people on reddit and here.

I would suggest the following text to replace the GD 404 brew text:

At this point in time, I have created an errorIndex.json file, which is just a JSON object using the reported error code as the key; I have used the suggested text on the "404" error:

Possibly this approach would work better with Homebrewery-specific internal error numbers, as the possibility exists that some other function will return a 404 and gets the Google Drive file missing error message.

Attempting to access a brew's Edit Page while not logged in as an author (not in errorIndex.json) results in this:

One downside of using a cookie to store the error information and expiring the cookie as soon as the error page has been loaded, is that refreshing the error page causes the error information to be lost.
An alternative that does not suffer this issue is to store the error information in query parameters instead - the error information will survive a refresh.

Changing the existing ErrorPage to use the base UIPage:
Google file missing:

Not an Author:

I made some changes so we don't have to redirect at all (user gets to keep the current URL in case it was a typo causing the error),  and hence we don't need to do the cookie thing.

Possibly this approach would work better with Homebrewery-specific internal error numbers

Yes. We should add a separate HBErrorCode or something to each error. The 404 status as you point out will occur for more than just the "google drive file missing" case, and each should have its own error text.

Current state of the PR:
Google Drive file has been deleted:

Brew does not exist in HB or Google Drive:

User is not an author:

Ok, I've made one more round of tweaks to the error texts. I'm sure there's plenty more improvement that can be made, but we can always reword things later. I put screenshots of the main errors here for ease of review, and adding the others as reviewers for final comments. Thoughts on the error text or style? Anything major we can put in a separate PR, but small things we can change here and then send live.

Error
Screenshot

Google Brew not found

Google Brew not found 2

Google Brew not found 3

Not signed in to edit

Not in author list

Brew not found

I think it's looking pretty good! That one failing test should be a pretty minor update to correct.

I've just tried pushing a commit from the work laptop - I had to edit the file in Notepad++ but I don't think I did anything to anger the Linter.

Confirmed - test is fixed now.

@calculuschild : would you agree that this PR will resolve #1924?

Yes.

Yes.

I've updated the top comment to link the original Issue to this PR.


:seedling: Refactor CI github actions, Dockerfile

Refactoring:

Split CI, one for repo tests and one for global tests

Only enable global CI on main (with a note)

Global CI configured like the multiarch build to cancel in progress runs in a new run starts

Repo CI bump the version of action codecov/codecov-action based on runtime warnings

Add --ignoreScripts to the npm clean-install in the Dockerfile to avoid running unnecessary postinstall scripts with the build running directly after the install.

Looks OK to me.


Subnet Selection (auto-detection) - Suggestion for Change.

I am definitely a fan of using auto-detection
Wondering if it could be more closely aligned to Kops given this is the suggested way to install Kuberenetes on AWS.
The tags given to subnets by default with kops are:
KubernetesCluster | $CLUSTER_NAME
kubernetes.io/cluster/$CLUSTER_NAME | owned

Kops seems to recommend naming clusters to match the domain name you set up for DNS records in order to ensure uniqueness between clusters. This could commonly be a pretty long cluster name; would this not break the auto-detection feature since the alb-ingress has a character limit in CLUSTER_NAME, which has to match the same tag on the subnets used by Kops?
I'm not sure if this is a separate issue to be discussed.

@blytheaw That was fixed via https://github.com/coreos/alb-ingress-controller/issues/223.
Specifically https://github.com/coreos/alb-ingress-controller/commit/918d034df4f3994ca34f5d70d3de81f74d55e934
If you are still having problems I would suggest raising another issue.

^ 👍 Let us know!

Sorry didn't mean to close -- @whithajess, you're suggesting re-using those existing kops annotations, correct?

@joshrosso Yeah basically it would just be nice if it found default tags created by kops, and by default would auto-select them without me having to either manually enter them in either my ingress setup or by tagging AWS resources.

These tags are a kubernetes convention in aws beyond kops
https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/aws/tags.go#L30

Oh cool so then follow Kubernetes convention not just Kops :) thanks for the info @ese

I too would like to see auto detection of subnets work with a cluster tag value of "owned". I can open a PR for the change if it wouldn't cause folks problems

Being able to use "owned" lifecycle subnets in addition to "shared" would be nice for being able to use w/ kops out of the box. However this would also require being able to change the other tag.
This component expects: kubernetes.io/role/alb-ingress
Where kops (and kubernetes) work with these tags: https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/aws/aws.go#L87-L93

Agreed on autodetecting a cluster tag value of owned. Kops doesn't currently support adding custom AWS tags to specific subnets. Maybe the alb ingress controller could take a set of subnet tag filters as a parameter somehow?
It could use the following order of preference:

subnets annotation on the ingress resource
filter parameter on the controller if set
Existing default of kubernetes.io/cluster/clustername=shared and kubernetes.io/role/alb-ingress

Another voice agreeing; the correct thing to do here is use kubernetes.io/cluster/$CLUSTER_NAME=owned. This is consistent with the Kubernetes conventions, as well as Kops. https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/aws/tags.go#L30
Does anyone have input on making this change prior to starting a PR?

To follow up on the comment from @jhohertz, is there a compelling reason to use kubernetes.io/role/alb-ingress instead of the preexisting label kubernetes.io/role/internal-elb?
According to AWS documentation, an ALB is a subtype of ELB. Therefore, I believe we should continue using the internal-elb label rather than creating a new one.

Elastic Load Balancing supports three types of load balancers: Application Load Balancers, Network Load Balancers, and Classic Load Balancers

Hi I've managed to create a method that discovers subnets based on the annotations
kubernetes.io/cluster/<cluster-name>=shared and kubernetes.io/role/alb-ingress='' also to sort them based on the scheme internal gets private subnets and internet-facing gets public subnets.
I'm gonna fix somethings up, but hopefully I'll be able to make a PR soon

@argeualcantara kubernetes.io/cluster/<cluster-name>=owned is going to be the most common use-case

@whithajess Ok, is there any difference (configuration, security groups, etc..) for the ALB ingress if the tag kubernetes.io/cluster/<cluster-name> has the shared or owned values?

I'm leaning towards using the same tags as the aws cloud provider, see https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/aws/aws.go#L87-L93

@bigkraig I think the point of auto-detection should be that it picks up defaults, if I have to set specific tags on my instances to do it then it defeats the purpose (as it exists in its current state I just set them manually rather then tagging) If it was implemented as suggested with elb tags I would still manually set it (very little difference to me tagging the instances manually and not really auto) I think nearly every use case would be to set it across the cluster, and for the edge cases they can do it manually.

@whithajess I am not sure I understand, if I go with the tags defined in that link, you would need to have 2 tags on your subnets which appear to be pretty standard.
All subnets:
kubernetes.io/cluster/<cluster name> = shared
Subnets for internal ALBs:
kubernetes.io/role/internal-elb = ``
Subnets for external ALBs:
kubernetes.io/role/elb = ``

@whithajess got it, so you are suggesting only require that tag? how should we know if its an internal or external subnet?

@bigkraig Yeah sorry you are right, I can't think of a way you could tell without setting that and I actually just checked my cluster and it does have kubernetes.io/role/elb = 1 not sure how I missed that the first time 👍 on your tag suggestions.

Have a look at #455

Should be able to close this now @bigkraig? or want me to verify with a new release?

@whithajess I just cut 1.0-beta.4, it'll be building for a while but we can close this one 👍


Consider extending SymbolInformation with metadata field

Hello, I have implemented a DocumentSymbolProvider to pick out MarkDown links from MarkDown files, so now I can get symbols whose name is e.g. [VS Code](https://code.visualstudio.com/), however, if I wanted to access either the text or the path of the link, I'd have to further parse the symbol text.
Alternatively I could either replace this symbol or accompany this symbol with two other symbols, one for the text and one for the path (and potentially bind the text and path symbols to the link one using containerName).
If I did that, I could centralize the link parsing in the symbol provider, but would make it harder for the consumer to identify pairs of symbols that together represent one link. It's not impossible, the symbols could be matched using the containerName, but it's not the most natural code to write, identifying these pairs.
I thought I could just create a new class extending SymbolInformation, but when obtaining the symbols using commands.execute('vscode.executeDocumentSymbolProvider'), the instances are transformed (presumably because they are serialized and deserialized, same thing that would happen over LSP).
Hence I'd like to propose either a new field was added for metadata or any unknown fields were preserved upon transfer so that something like textSymbol.associatedPathSymbolLocation (being a Location) could be used.

Not really sure what you are trying to achieve? Do you want to make links appear in the outline views? (tree, quick outline, breadcrumbs)

Sorry, I went about this wrong and since have found I way what I wanted to achieve.


Add spaces after "<" and before ">" for obj type declaration.

This is to avoid conflicting with the JSX syntax. It's a quick fix
intended to be temporary until the JSX stuff is more mature.
refmt is broken without this because type a = < x : int > becomes type a = <x : int> which then doesn't parse because refmt think it's some malformed JSX.

Looks good, thanks for fixing!


How to pass .secrets.baseline as command line argument?

For the pre-commit, I see the following:
    hooks:
    -   id: detect-secrets
        args: ['--baseline', '.secrets.baseline']

If I run detect-secrets scan --all-files in Terminal, detect-secrets will continue to find secrets I've audited in the .secrets.baseline. The arg '--baseline' does not exist as an argument for detect-secrets, so how is it using the baseline at all?

Hi @jason-ausmus-bfg, setup.py places two command-line utilities. detect-secrets-hook is what you are looking for.
I will make a different issue for documenting this better in the README 👍 Thanks for making this issue!
Also I don't see a reason why we can't add the --baseline option to the regular detect-secrets utility. It's not how we normally use it, but it still seems helpful to some people.

(Gonna close this for now, but I will make the other issues later.)
Feel free to ping me if you have any other questions :)

@KevinHock detect-secrets-hook does not allow me to use the --all-files flag to check all files.
Do you know of a way that I can do this? Context: I'm attempting to run detect-secrets as an automated step in our CI environment. The command I run needs to know about the baseline and it needs to execute on all files checked in to git.

It should default to the current directory, if you don't run it with --all-files. I think. (usage.py can shed some light on this if my answer is unsufficient.)
Behind the scenes, --all-files is passed to pre-commit's framework, not detect-secrets, which grabs all the git-tracked files, and then gives detect-secrets-hook the real list of files.


committing slack webhook documentation

This is my PR to add documentation and information about how to integrate Slack via the Keptn Webhook Service. This approach was discussed on keptn slack channel with Johannes Bräuer

Many thanks for the PR!
I would like to edit the PR directly since I see it as a replacement of: https://keptn.sh/docs/0.10.x/integrations/webhooks/slack/

@oleg-nenashev I have done some changes to this PR (however in a separate one) in order to position this example as a reference template for other Webhook-based integrations.
Can you please take a look here: #33
Once we have agreed on #33, I'm happy to merge this one.

After merging this PR, we should get rid of: https://keptn.sh/docs/0.10.x/integrations/webhooks/slack/


"Test" button for custom notification sound URLs

Describe the function you'd like to see added to CookieMonster
In the Options where you can specify sound URLs to play for various notifications it would be helpful to have a "Test" button that attempts to play the sound when clicked. This would be nice so you don't have to wait for a golden cookie/garden tick to occur to see if the new URL you've added actually works.
Additional files
I plugged https://freesound.org/people/aji_/sounds/66136/download/66136__aji__ding30603-spedup.wav in as the sound URL for golden cookies and it's not playing and it would be faster to iterate if I could just click "Test" instead of waiting.  Here is a non-direct link to this audio file - https://freesound.org/people/aji_/sounds/66136/

I'd actually be happier with a few good options to choose from on each sound. Maybe a few button options for the sound to use for each notification and then a final option for "insert your own URL"  which then causes the current sound URL field to appear.
I'm trying to make the golden cookie sound less aggressive, and to make the garden tick sound a shovel scooping dirt. (This URL works for the shovel sound: https://www.freesound.org/data/previews/121/121099_2193266-lq.mp3)

I'm going to add a test button to the settings page. I will not add a list of options, as I believe this will unnecessarily crowd the already crammed page. Planning this for next release!


The generic is changed if used extends

🔎 Search Terms
extends
🕗 Version & Regression Information
This is the behavior in every version I tried, and I reviewed the FAQ for entries about 'extends'
⏯ Playground Link
https://www.typescriptlang.org/play?ts=5.4.0-dev.20240101#code/PTAEBUGVQNwUwE4GcCWB7AdqArAOgMy4BMAUCQC4CeADnBHEuQDzgB8oAvBKHAB7lwMAEySgAhhkqgA-KEgBXAEbgGzNqABcoDHHgIA3GSq05SlYxbsuAQQQIxlJgGs4lNADMIrMu-kYAxuToWAIW4Dz8giKgAEpw-mgIQkyMCCgYAOYANKB+ThhoAO4YrKwAFOnU8uRa4ACUoADeJACQIBG0gXBCrQkYjKBpGQAW5JygAIzionkFxdOmyqpMxnAeoJXV7O0KS2HeLe6JoGV9Awig60OjDc0tLaugLlJcq1f6oO3P6+CtAL5kNpgApjPidARCHIAA3M5ChoEUcGGYhg6AuKFEINASDEAFs6OQ0KAobtYVDepgBoUEJgMuMpmIZhh8kUsIz6BY3p5NuRtmBYZZWkcLqdKWNCpdPNTabdWg8aHRnuMuaBCh92ql0hl-iQASQQBxDUbjSbTWbzRbLVaTWR2gBJUDI+CgQmgIRE8jDOhHAA2PqKLuGWpdRNxYhcxLJLoVqsSTgoMYAYiheN0BeAcglqJRwlx1HmIgJhKIJFJZKTllmc+wtDo9IYSL4AkFMC7VEQWIWoqI4gkkilyGlMjlZqzShUMFUahBZUCOvEIRT+uKaZl6QtR-N2cnU0IBSqeXzQDu08s2ELjqLl6rJarVxlZ-KTErXgr1mrPmBvp5fi0AX8gA
💻 Code
type Test<T> = T extends any ? SubTest<T> : never;

type SubTest<T> = Array<keyof T>

function test<T extends Record<string, unknown>>(input: T) {
	// expected
	const right = 1 as unknown as SubTest<typeof input> // SubTest<T>
	for (const r of right) {
		type key = typeof r; // keyof T
	}

	// not expected, `Test` behavior should same to `SubTest`
	const wrong = 1 as unknown as Test<typeof input> // Test<T>
	for (const w of wrong) {
		type key = typeof w; // string
	}
}

//=======================================================================

// I have to do the follow thing to make `Test` type work
type FixedTest<T, copyT = T> = T extends any ? SubTest<copyT> : never;

function test2<T extends Record<string, unknown>>(input: T) {
	// expected
	const wrong = 1 as unknown as FixedTest<typeof input> // FixedTest<T>
	for (const w of wrong) {
		type key = typeof w; // keyof T
	}
}

🙁 Actual behavior
type Test<T> = T extends any ? SubTest<T> : never;

type SubTest<T> = Array<keyof T>

function test<T extends Record<string, unknown>>(input: T) {
	// not expected, `Test` behavior is not same to `SubTest`
	const wrong = 1 as unknown as Test<typeof input> // Test<T>
	for (const w of wrong) {
		type key = typeof w; // string
	}
}

🙂 Expected behavior
type Test<T> = T extends any ? SubTest<T> : never;

type SubTest<T> = Array<keyof T>

function test<T extends Record<string, unknown>>(input: T) {
	// `Test`'s behavior should same to `SubTest`
	const a = 1 as unknown as Test<typeof input> // Test<T>
	for (const w of a) {
		type key = typeof w; // keyof T
	}
}

Additional information about the issue
my solution is copy the type to make SubTest's behavior is same to Test currently:
type Test<T, copyT = T> = T extends any ? SubTest<copyT> : never;

but this solution also has some issue that copyT is miss the type inference:
type Test<T, copyT = T> = T extends object ? SubTest<copyT> : never;
// TS konw T is an object after `?` but don't know copyT is what type.

No bug here; this is working as intended:
https://www.typescriptlang.org/docs/handbook/2/conditional-types.html#distributive-conditional-types
If you don't want the distributive behavior, you can rewrite the type as
type Test<T> = [T] extends [any] ? SubTest<T> : never;

No bug here; this is working as intended: https://www.typescriptlang.org/docs/handbook/2/conditional-types.html#distributive-conditional-types
If you don't want the distributive behavior, you can rewrite(重写) the type as
type Test<T> = [T] extends [any] ? SubTest<T> : never;

Sorry I don't think so, I understood the distributive-conditional-types rules but haven't union in my case.
maybe the keyof caused you to misunderstand, I updated the playground

Well, it seems to have something to do with distributivity because making the conditional type non-distributive fixes the issue:
Playground link

Well, it seems to have something to do with distributivity because making the conditional type non-distributive fixes the issue: Playground link

I trid that but not work in my case(muti extends), I think copyT is the best way to fix my issue, but I also hope this issue can be fixed by TypeScript if this is a bug
https://github.com/sindresorhus/type-fest/issues/649

I don't recall the motivating example, but IIRC it's not "safe" to keep the type parameter here so instead we have to fall back to the constraint. Both behaviors are correct.

In the wrong branch, not only have we inferred the type of w differently, but it's not assignable to a variable of type T anymore. let t:T = w; gives:

Type 'Record<string, unknown>' is not assignable to type 'T'.
'Record<string, unknown>' is assignable to the constraint of type 'T', but 'T' could be instantiated with a different subtype of constraint 'Record<string, unknown>'

In the 2.8 release notes I noticed something slightly funny:

In instantiations of a distributive conditional type T extends U ? X : Y, ... references to T within X have an additional type parameter constraint U (i.e. T is considered assignable to U within X).

I know that in the true branch, the type of T can't be simply the intersection T & any, since T & any is any. How is that assignability constraint represented if not an intersection? Is it possible that the assignability constraint is actually mangling the type?