Authentication with v1.0.0.alpha

Hi,
I've created a angular wrapper based on version 0.2.9.alpha, which isn't working because of #263, RSocketWebsocketClient is not a constructor (likely it has more errors, couldn't test).
Link to the repo https://github.com/saleweaver/angular-rsocket (qwen coder made a mistake with async code, will be fixed...)
Now I was looking into upgrading to v1.0.0.alpha, but can't find a way to pass authentication to the client.
In version 0.0.29.alpha I could add tokens using WellKnownMimeTypes, but I can't find any documentation on v1 auth, and, looking through the code, can't find anything that seems related to auth.
I'm sure I'm missing something, can someone tell me what it is? Is there an option to add auth? If not, has there ever been a version 0.0.xxx where RSocketWebsocketClient could be instantiated in the browser - and if not, do you still accept pull requests for version 0.0.29?
Thanks a lot!
Here's some code how I added tokens to metadata to be read by spring rsocket.
// Adding token to setup payload

private getSetupPayload(): any {
    const metadataPairs: [WellKnownMimeType, Buffer][] = [];

    // If a token is provided, include it in the setup payload
    if (this.config!.token) {
      const token = this.resolveProvidedToken(this.config!.token);
      if (token) {
        metadataPairs.push([MESSAGE_RSOCKET_AUTHENTICATION, encodeBearerAuthMetadata(token)]);
      }
    }

    const compositeMetadata = encodeCompositeMetadata(metadataPairs);

    return {
      metadata: compositeMetadata,
    };
  }

// Adding token to request Metadata

  private getCompositeMetadata(token: string | Signal<string> | (() => (string | Signal<string>)) | undefined, route: string) {
    const resolvedToken = this.resolveProvidedToken(token);

    const metadataPairs: [WellKnownMimeType, Buffer][] = [
      [MESSAGE_RSOCKET_ROUTING, encodeRoute(route)],
    ];

    if (resolvedToken) {
      metadataPairs.push([
        MESSAGE_RSOCKET_AUTHENTICATION,
        encodeBearerAuthMetadata(resolvedToken),
      ]);
    }

    return encodeCompositeMetadata(metadataPairs);
  }

EDIT:
I've converted the RSocketWebsocketClient to typescript, now it works with v0.0.29

I had the code working on a node version, but the constructor error kills the angular app
const {
    RSocketClient,
    JsonSerializer,
    IdentitySerializer,
    encodeCompositeMetadata,
    encodeRoute, WellKnownMimeTypeEntry, WellKnownMimeType, APPLICATION_JSON, MESSAGE_RSOCKET_COMPOSITE_METADATA,
    TEXT_PLAIN, MESSAGE_RSOCKET_ROUTING, MESSAGE_RSOCKET_AUTHENTICATION, encodeBearerAuthMetadata, BufferEncoders,
} = require('rsocket-core');
const RSocketWebSocketClient = require('rsocket-websocket-client').default;

// Your JWT token
const token = 'jwt here'

// Create an RSocket client
const client = new RSocketClient({
    serializers: {
        data: IdentitySerializer,
        metadata: IdentitySerializer,
    },
    setup: {
        keepAlive: 60000,
        lifetime: 180000,
        dataMimeType: APPLICATION_JSON.string,
        metadataMimeType: MESSAGE_RSOCKET_COMPOSITE_METADATA.string,
        payload: {
            metadata: encodeCompositeMetadata([
                [MESSAGE_RSOCKET_AUTHENTICATION, encodeBearerAuthMetadata(token)],
                [MESSAGE_RSOCKET_ROUTING, encodeRoute('board.updates')],

            ])
        },
    },
        transport: new RSocketWebSocketClient({
            url: 'ws://localhost:8080/rsocket',
        },
            BufferEncoders),
});

// Connect to the RSocket server
client.connect().subscribe({
    onComplete: (socket) => {
        console.log('Connected to RSocket server');
        const compositeMetadata = encodeCompositeMetadata([
            [MESSAGE_RSOCKET_ROUTING, encodeRoute('board.updates')],
            [MESSAGE_RSOCKET_AUTHENTICATION, encodeBearerAuthMetadata(token)],

        ]);

        // Request a stream from the server using the "board.updates" route
        socket.requestStream({
            data: null,
            metadata: compositeMetadata
        }).subscribe({
            onComplete: () => console.log('Stream completed'),
            onError: (error) => {
                console.error(`Stream error: ${error}`);
                console.log(error);
            },
            onNext: (payload) => {
                console.log('Received data:', payload);
                try {
                    const jsonString = payload.data.toString(); // Convert Buffer to string
                    const jsonData = JSON.parse(jsonString); // Parse string to JSON
                    console.log('Received data:', jsonData);
                } catch (err) {
                    console.error('Error parsing JSON:', err);
                }
            },
            onSubscribe: (subscription) => {
                console.log('Subscribed to stream');
                console.log(subscription.request(2147483647));
            },
        });
    },
    onError: (error) => console.error(`Connection error: ${error}`),
    onSubscribe: (cancel) => {
        console.log('Subscribed'); },
});

Hi @saleweaver -- I've added a basic example which shows how you can accomplish authentication at request time using composite metadata. Apologies this wasn't more straight forward / discoverable on your own.
Please see https://github.com/rsocket/rsocket-js/pull/286.

Hey Kevin,
thanks for that, I'll give it a try. I didn't find the well known metadata enums in v1, but I likely didn't look close enough. Will have a look.
Thanks for the example!


Handle depends_on "homebrew/core/foo" for HOMEBREW_INSTALL_FROM_API

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew typecheck with your changes locally?
[ ] Have you successfully run brew tests with your changes locally?

See https://github.com/Homebrew/brew/issues/12326
Before, third-party formulae that had a depends_on "homebrew/core/foo" line wouldn't work as expected. This PR fixes the way that they are handled.

Now, homebrew/core won't be automatically tapped
Dependencies can be installed correctly

I don't think this is fully correct yet. At the moment, any time Dependency#to_formula is called on a core formula that isn't installed already, its bottle will be downloaded. I'm not 100% sure that this is what we want, though, because there may be some cases where we'd rather it to just fail. I thought this through more clearly a while back but I can't remember exactly what I decided.
Also, this means that bottles will be downloaded unecessarily for core formulae that are installed. For example, if a formula has depends_on "homebrew/core/hello" and hello is installed, installing that formula will download the hello bottle even though it doesn't need to install hello. Later, it realizes this and doesn't both using the downloaded bottle. It seems like Formulary.factory needs to be trained so that if it gets a ref like homebrew/core/foo, it should first look for any installed formulae with that name that have homebrew/core set as its tap (in it's tab).

Okay, I've made some changes that I think are better. Now, Formulary::factory, when passed a ref that starts with homebrew/core/, will first check for installed formulae with that name and try to load from that instead of through the TapLoader that will fail. In the case where the formula isn't already installed, a CoreTapFormulaUnavailableException will be thrown which will need to be handled by whatever tried to load the formula. In the case of installing formulae that have specified depends_on "homebrew/core/foo" where foo isn't installed, this means adding a rescue to verify_deps_exist that, for core formulae that don't exist, will retry after downloading bottles.
There is still at least one known issue with this: if a formula has depends_on "homebrew/core/foo" and foo from homebrew/core isn't installed but another formula called foo from another tap is installed, the correct foo won't be installed and the incorrect foo will be accepted as the correct dependency. I did, originally, add in a check for this but it ended up causing more problems. Not sure whether this is an allowable oversight or should be fixed.

I did, originally, add in a check for this but it ended up causing more problems. Not sure whether this is an allowable oversight or should be fixed.

I'd probably say it should be fixed but I do have a few follow up questions to ask at some point about formula loading in general, which will tie in a lot with what solution is chosen here (e.g. what happens if we have a stale bottle file with old syntax?). Happy to chat about it at some point we're free.

I think this also brings up a question about the way we install formulae from the API. Currently, we download all the needed dependency bottles for the formula we're installing before we start (they're all specified in the bottle API). However, for installing non-core formulae that depend on core formulae, this doesn't really work because there's no bottle API file to indicate the dependencies. So, we download the bottles on the fly as we're checking dependencies (that's part of what's been added in this PR).
So, since that's what we do for non-core formulae, is there a reason we shouldn't do this for core formulae too? Doing so would mean that the bottle API wouldn't need to include dependencies and we would just download the bottles for formulae that are needed as we encounter CoreTapFormulaUnavailableExceptions.
Another benefit of doing so is that, at the moment, build dependencies aren't included in the bottle API, so brew install -s doesn't always know to download the bottles for build-only dependencies. Although, as I'm writing this, I'm realizing that it's possible that this PR fixes that.
One concern of mine with how this seems to be going is that it feels like the ability to install using the API is just hacked over the existing formula installation process (because that's, in fact, what has been happening). So, whenever there's a bug that pops up, it's patched in another place. The whole thing feels very messy to me and it's difficult to track down where errors are happening. Since this is hopefully going to become the default for most users (and most formulae that we install come from homebrew/core), I think it may be worth some time re-thinking how all of this is handled and potentially rewriting some of it to make installing from the API more built-in and less hacky. Sorry, this is a bit rambly but I hope what I'm trying to say makes sense. Also, as I'm typing this I see your comment @Bo98 and I agree and that this uneasiness that I have is likely related.
CC @MikeMcQuaid for thoughts.

I think I'm going to merge and tag once CI passes so users can get the HOMEBREW_INSTALL_FROM_API fixes, but I'd like the conversation to continue.

I think it may be worth some time re-thinking how all of this is handled and potentially rewriting some of it to make installing from the API more built-in and less hacky. Sorry, this is a bit rambly but I hope what I'm trying to say makes sense. Also, as I'm typing this I see your comment @Bo98 and I agree and that this uneasiness that I have is likely related.

Yeah I agree.
I even see us having a world where we don't load formula files at all, unless we are building from source, since all information we need should be stored in the API. And when we do build from source we could download the latest formula file rather than a bottle. I think this will help separate logic a lot better and address a few concerns (including my stale formula file example).
That's just one idea though without having discussed or dug into this much. There's probably many other paths we can take.

And when we do build from source we could download the latest formula file rather than a bottle.

That's true. We already store copies of all cask files in the API (/api/cask-source/foo.rb) so we could definitely do so for formulae, too.
Actually, doing that would make brew info work much more easily. Right now it doesn't work because we don't want to download an entire bottle just to get access to the formula file when the information that's needed is available in the normal formula API (/api/formula/foo.json). We just don't have a way to easily transfer that information back into the format we need to output. If we, instead, load the formula from its file which we get from the API, there's no need to rewrite any of the brew info code.

I'm going to log off in a moment but just a couple of short questions:

That's true. We already store copies of all cask files in the API (/api/cask-source/foo.rb) so we could definitely do so for formulae, too.

What are the advantages of /api/cask-source over just downloading the file directly from GitHub?

Actually, doing that would make brew info work much more easily. Right now it doesn't work because we don't want to download an entire bottle just to get access to the formula file when the information that's needed is available in the normal formula API (/api/formula/foo.json). We just don't have a way to easily transfer that information back into the format we need to output. If we, instead, load the formula from its file which we get from the API, there's no need to rewrite any of the brew info code.

I could see us having some abstract formula class or something that both from-file and from-API base from.
A complication I forgot about and edited in to my last comment is postinstall. It's the spanner in most solutions since it requires execution of Ruby, and changes to postinstall have historically not resulted in new bottles published.

What are the advantages of /api/cask-source over just downloading the file directly from GitHub?

Speed, mainly (I believe). @MikeMcQuaid can probably elaborate (I can't scroll back far enough in our slack message history to find where we discussed this so sorry for putting you on the spot).

I could see us having some abstract formula class or something that both from-file and from-API base from.

Yeah, something like that could probably work but I also think it may end up being more work than it's worth because the only time the loading from API would be used (I think) it for brew info.

A complication I forgot about and edited in to my last comment is postinstall. It's the spanner in most solutions since it requires execution of Ruby, and changes to postinstall have historically not resulted in new bottles published. However not all formulae need a postinstall.

Good point. Right now, postinstall can occur, but yeah, changes to the postinstall block without new bottles will mean that users using HOMEBREW_INSTALL_FROM_API won't ever get them. The solution to this, though, may just be to require new bottles for postinstall changes.

The solution to this, though, may just be to require new bottles for postinstall changes.

This would be new bottles for any form of syntax change we may make in the future from deprecations, which includes situations where we do stuff like mass-replacing thousands of formula like we did to the bottle block, which is going to be a bit of a pain (though I think bottle block disappears when placed into bottles, but you get the point).

This would be new bottles for any form of syntax change we may make in the future from deprecations, which includes situations where we do stuff like mass-replacing thousands of formula like we did to the bottle block, which is going to be a bit of a pain (though I think bottle block disappears when placed into bottles, but you get the point).

Yeah, good point. I guess I was thinking more along the lines of requiring new bottles when a functional change is made. Of course, that's much harder to enforce and relies on maintainers to know when to merge with/without bottles.

This would be new bottles for any form of syntax change we may make in the future from deprecations, which includes situations where we do stuff like mass-replacing thousands of formula like we did to the bottle block, which is going to be a bit of a pain (though I think bottle block disappears when placed into bottles, but you get the point).

Yeah, good point. I guess I was thinking more along the lines of requiring new bottles when a functional change is made. Of course, that's much harder to enforce and relies on maintainers to know when to merge with/without bottles.

Even then, changes from deprecations are still important as they will in the future render the formula unreadable.
The problem is Homebrew itself is evergreen but formula files in bottles are not. We'd basically need to guarantee the formula Ruby API never ever changes, which is something we've never guaranteed before.

Good point. This is another reason why having a formula-source API would helpful. That way, we don't need to rely on the old formula files that are embedded in the bottle to install the formula.

So, since that's what we do for non-core formulae, is there a reason we shouldn't do this for core formulae too? Doing so would mean that the bottle API wouldn't need to include dependencies and we would just download the bottles for formulae that are needed as we encounter CoreTapFormulaUnavailableExceptions.

This seems reasonable. I'd like to see a PR to compare whether the code seems cleaner/not.

One concern of mine with how this seems to be going is that it feels like the ability to install using the API is just hacked over the existing formula installation process (because that's, in fact, what has been happening). So, whenever there's a bug that pops up, it's patched in another place. The whole thing feels very messy to me and it's difficult to track down where errors are happening. Since this is hopefully going to become the default for most users (and most formulae that we install come from homebrew/core), I think it may be worth some time re-thinking how all of this is handled and potentially rewriting some of it to make installing from the API more built-in and less hacky. Sorry, this is a bit rambly but I hope what I'm trying to say makes sense. Also, as I'm typing this I see your comment @Bo98 and I agree and that this uneasiness that I have is likely related.

Yes, I agree. I wonder if there's a place to either have a FormulaApiInstaller or FormularyApi or some other abstractions/replacements to handle this and have logic separated or shared depending on what flows we use.

Speed, mainly (I believe). @MikeMcQuaid can probably elaborate (I can't scroll back far enough in our slack message history to find where we discussed this so sorry for putting you on the spot).

Speed and the fact that GitHub won't really like us scraping their web frontend for formula files when we could be caching them. Some folks are already 🤨 about our usage of "Git as a CDN" but GitHub Pages is fine because it is backed by an actual CDN.

The problem is Homebrew itself is evergreen but formula files in bottles are not. We'd basically need to guarantee the formula Ruby API never ever changes, which is something we've never guaranteed before. The millions of outstanding brew extract bugs and existing monkey patches are an example of this.
...
Good point. This is another reason why having a formula-source API would helpful. That way, we don't need to rely on the old formula files that are embedded in the bottle to install the formula.

Formula files in bottles should be seen as a fallback if the formula no longer exists in the repository and/or you're offline. We've been using them for more than that and I think that's fine but I think a formula-source API (with graceful timeout handling) would make sense, agreed.
I'm glad we're thinking through how this can be the default behaviour.

This seems reasonable. I'd like to see a PR to compare whether the code seems cleaner/not.

If I have time this week I'll try to open one.

Yes, I agree. I wonder if there's a place to either have a FormulaApiInstaller or FormularyApi or some other abstractions/replacements to handle this and have logic separated or shared depending on what flows we use.

It's not immediately clear to me how this would work. Most of the install logic shouldn't change, I think it's only the pre-install stuff (i.e. fetching) that needs to be looked at. Plus, since installing from the API is still needed when installing non-core formulae, we can't totally separate the logic.

Formula files in bottles should be seen as a fallback if the formula no longer exists in the repository and/or you're offline. We've been using them for more than that and I think that's fine but I think a formula-source API (with graceful timeout handling) would make sense, agreed.

Agreed

If I have time this week I'll try to open one.

If it saves time: don't worry about green CI (beyond a brew style --fix run).

It's not immediately clear to me how this would work. Most of the install logic shouldn't change, I think it's only the pre-install stuff (i.e. fetching) that needs to be looked at.

Having a FormulaFetcher or FormularyApi or something might make sense to me.

Plus, since installing from the API is still needed when installing non-core formulae, we can't totally separate the logic.

I think the goal is consolidation rather than separation. A formula should call the relevant class for e.g. fetching the bottle/getting the formula depending on whether it's core or non-core and whether the API env is set.

If there's anything in particular you want me to help draft out (like the abstract formula class idea) let me know. Happy to try things out just to see how they look.

If there's anything in particular you want me to help draft out (like the abstract formula class idea) let me know. Happy to try things out just to see how they look.

If you've got something in mind then yeah that would be great!

Here's a quick prototype demonstrating a possible implementation to allow offline usage under HOMEBREW_INSTALL_FROM_API, as well as fixing things like brew info not working for not-installed formulae: https://github.com/Bo98/brew/commit/726f4ab8871df13a5d6e10e4c87b15e08af50c27
Just a draft so there's plenty of caveats (all fixable):

The download of formula.json has zero integrity checks.
The download of formula.json does not handle interruptions well (corrupt file).
The download of formula.json should probably make use of ETags (and the easy method unfortunately needs Curl 7.68).
Building from source is not supported yet (need to download the formula file).
Post install is skipped (same reason).
Casks are not supported yet.
Keg-only reasons are fixed to "TODO" (need to add this to API).
Aliases probably don't work.
It's not fully offline everywhere - there's a few API::Versions calls still for example (but they might not be needed with this?).

But HOMEBREW_INSTALL_FROM_API=1 brew info <formula> should now work with this, and hopefully most things that were working previously.

Here's a quick prototype demonstrating a possible implementation to allow offline usage under HOMEBREW_INSTALL_FROM_API, as well as fixing things like brew info not working for not-installed formulae: Bo98@726f4ab

@Bo98 Love this. Looking forward to a PR!

The download of formula.json has zero integrity checks.

Out of interest: how do you see this being fixable? Not sure I can see a way 😅

The download of formula.json does not handle interruptions well (corrupt file).

Corrupt file, re-download, I guess?

The download of formula.json should probably make use of ETags (and the easy method unfortunately needs Curl 7.68).

I think having a time-based cache might make sense here as well (kinda like HOMEBREW_AUTO_UPDATE_SECS)?
Like the idea of using ETags here, though.

Building from source is not supported yet (need to download the formula file).

I think it'd be OK to remove the "yet" here entirely and just punt on this.

Post install is skipped (same reason).

Should be able to do this from the formula file in the bottle?

Build flags are not tested (they might work, but we should probably reconsider how we handle BUILD_FLAGS), though this doesn't really matter for Homebrew/core.

Punt on it. This feature only makes sense for homebrew/core.

But HOMEBREW_INSTALL_FROM_API=1 brew info <formula> should now work with this, and hopefully most things that were working previously.

🎉

Out of interest: how do you see this being fixable? Not sure I can see a way 😅

Signatures maybe.

Corrupt file, re-download, I guess?

The concern is mostly making sure we don't replace a perfectly good download with a bad one. Downloading to a temporary file and moving it once we verify it's readable will cover this.

Should be able to do this from the formula file in the bottle?

The concerns raised earlier was that formula files in bottles become stale. For example, if we wanted to do a mass change like we did to sha256 in the bottle block, we would have to rebottle every single formula (or at least those with a post-install). See the above discussion about a possible formula-source API.

This looks great! I'll have more time soon (I really hope) to take a close look. Thanks for working on this, @Bo98!

I took a look and left a few minor comments on that commit. I think this implementation makes a lot of sense because it restores the ability to use these features when offline. I think the remaining API::Versions called can probably be made to fall back on the cached formula store without too much trouble.
One question I have, though, is since we need an internet connection to install formulae anyway, why not store the formula files online and just download them and install them from the file (like the current implementation does for casks)? It seems that doing so would remove the need for a complicated FormulaAPILoader class that would need to be updated every time a change is made to Formula and/or Formula#to_json (or #to_hash, can't remember what it's called).
A while ago I was thinking about adding some sort of test to make sure that changes that we made to the formula API were always backward compatible (API-field-wise) and maybe this is a good time to add such a test (but I need to think about it more because I'm not 100% sure what it will need to look like)

Building from source is not supported yet (need to download the formula file).
Post install is skipped (same reason).

This is something that would be solved if we install from the formula file always. But I agree, it's probably not that necessary. Especially if #10846 and #12534 succeed.

Casks are not supported yet.

Why not, these shouldn't be affected, right? I must be missing something (I probably need to revisit the logic for all of this)

One question I have, though, is since we need an internet connection to install formulae anyway, why not store the formula files online and just download them and install them from the file (like the current implementation does for casks)?

Agreed.
Personally, I don't think it's worth optimising at all for the "what if I'm offline" case until we've actually shipped the online-only case. Supporting offline/caching feels like scope creep which is going to be harder to get this in the hands of users.

One question I have, though, is since we need an internet connection to install formulae anyway, why not store the formula files online and just download them and install them from the file

Yeah the plan is to do that for installing formulae. Under the current implementation, it would only strictly necessary to use a formula file if a post-install is defined or we are building from source but the current implementation may of course not be what is used.

Why not, these shouldn't be affected, right? I must be missing something (I probably need to revisit the logic for all of this)

I worded that weirdly. Read that as "I've not checked whether there's anything on the Cask side that would benefit from the same changes". The answer is probably that there is - I've just not looked at it at all.

Personally, I don't think it's worth optimising at all for the "what if I'm offline" case until we've actually shipped the online-only case. Supporting offline/caching feels like scope creep which is going to be harder to get this in the hands of users.

We'd effectively be disabling features like completion if we ignore the offline case though.
Set the offline part to one side. Right now, core features like brew install work, but other things like brew info don't regardless of connectivity status. And it seems like the process of fixing those commands is going to need special code on a case-by-case basis. I was attempting to implement it in a way that nothing needed modifying for it to work. In fact, I've removed some API-specific code as a result. The offline part is just a secondary goal I had in mind when choosing the approach.

We'd effectively be disabling features like completion if we ignore the offline case though.

Fair comment, worth considering from that perspective alone, I think. I do think the "list of formulae that can be installed" is a tighter scope, though.

And it seems like the process of fixing those commands is going to need special code on a case-by-case basis. I was attempting to implement it in a way that nothing needed modifying for it to work. In fact, I've removed some API-specific code as a result. The offline part is just a secondary goal I had in mind when choosing the approach.

Yup, that's fair.

Making sure there's minimal API-specific code required in individual commands should in fact mean that we end up shipping this quicker to users.

Maybe? I think I'd be more supportive of this approach if we were discussing an open, green PR rather than a commit on a fork.


Performance Optimizations

Use Lazy NTT
Other performance optimizations on random sampling, etc
Refactored benchmarks into scheme, polynomial, and integer level. Add micro benchmarks

Left some Rust ic comments - I tend to avoid for as much as I can in Rust - easier to parallelize later. Maybe also good to run a format pass via cargo +nightly fmt and a linter pass with cargo clippy


The django_q/tests directory isn't in the tarball

The django_q/tests directory isn't included in the MANIFEST.in file, as a result it isn't shipped with the tarball on PyPI, and those users can't run the test suite. Please include it.

@Koed00 is it possible to share the responsibility to close issues?
It seems quite a few are already resolved but not closed

@Eagllus I've invited you as a collaborator.  That should give you enough rights.
Just pull requests on master are protected.

@Koed00 thank you, I want meddle in merging pull request. 😉
This way I can close issues that are resolved/no longer relevant


Rxjs use of instanceof breaks subscription with multiple bundles

Bug Report
Current Behavior
Hi, we are building a components that exposes rxjs observables for plugins to connect to. Our component is primarely used prebundled, which means that our plugin creators might have double of some parts of rxjs. Though, somewhat wastefull this worked fine with rxjs 5, but after upgrading to rxjs 6, things started breaking in Firefox and Chrome Canary 69. Here's the error message they get when trying to subscribe:
TypeError: You provided an invalid object where a stream was expected. You can provide an Observable, Promise, Array, or Iterable.

Which pointed at the subscribeTo function, where I suspect that this line is the culprit: https://github.com/ReactiveX/rxjs/blob/80ceea00cc86b8634047ad0201a90115ce97bb34/src/internal/util/subscribeTo.ts#L15
instanceof seems to be a bit unreliable and appears to work differently under the hood in each browser, especially if the class appears twice and originated from the same source.
Reproduction

Create two bundles referencing rxjs 6.2.0, one exposing an observable, another subscribing to it and using its own operators.
Try to subscribe.

Expected behavior
Should subscribe since there is nothing (?) stopping it from doing so.
Environment

Chrome 69 & Firefox 60
RxJS version: 6.2.0

If anyone knows a workaround I'd be happy with that, since I know some would probably regard this as a non-issue.

It sounds like you're bundling two instances of RxJS. That's not going to be good for your app size. Your libraries shoudl have RxJS as a peer dependency, and that will solve the problem most likely.
However, there are workarounds:

Load a polyfill for Symbol.observable.  RxJS 5 used to polyfill it for you. RxJS 6 doesn't, because libraries shouldn't be doing that. If Symbol.observable is present, then each copy of RxJS will coerce to it's own Observable type using that.

Use a from call to wrap observables you think come from other libraries.

... but the real solution here is that you'd want RxJS to be a peer dependency.

We might start using our isObservable implementation internally, and they could solve this issue, but it's also sort of a smell in the usage here. We'll discuss it at the next core team meeting.

Thank you for the help Ben! Yes, our current setup isn't ideal. Your suggestions will have to serve as a band aid for the time being until we get our distribution setup sorted out.

After some discussion with the team today, we've decided to leave the instanceof checks as is. Because:

There are performance implications of moving away from instanceof checks
The work around is as easy as polyfilling Symbol.observable.


can't send message from bot to public channel

i was try to send message from my bot to public channel with bot.sendMessage(chat_id="@ChannelName, text="some text") but I get an error message like this ('Bad Request: need administrator rights in the channel chat', 400, {'ok': False, 'error_code': 400, 'description': 'Bad Request: need administrator rights in the channel chat'})
how to fix it even though I have added the bot as an administrator on my channel ?
and below is the bot settings

thanks
sorry if my english bad

Did you figure it out?
If not:
If i'm right, in the What can this admin do? field, Post messages is disabled, though for it to be able to send messages there it needs to be enabled for the bot.


Merging DLRM integration with MLPerf loadgen (part 2)

Latest commits start on April 23. Previous commits have already been merged in https://github.com/mlperf/inference/pull/586.

@googlebot I consent

@googlebot I consent

@googlebot I consent

@googlebot I fixed.

It seems that everyone has signed CLA and consented at least a few times.
Can somebody point out what is missing for the CLA check?

@googlebot I fixed it

@googlebot I consent

@googlebot I fixed.


Reproduces issue #44.

  1) Mongoid::Orderable SimpleOrderable inserting parallel
     Failure/Error: expect(positions).to eq([1, 2, 3, 4, 5, 6, 7])

       expected: [1, 2, 3, 4, 5, 6, 7]
            got: [1, 2, 3, 4, 5, 6, 6]

       (compared using ==)
     # ./spec/mongoid/orderable_spec.rb:217:in `block (4 levels) in <top (required)>'

Awesome, are you going to provide a fix for it?

I thought about how to fix it and I don't see a good solution ATM :(

This will be addressed in #61. I've written alternate specs.

This will be addressed in #61. I've written alternate specs.


Groupby multi agg

Previously this didn't work for the case of a list of single column. Fixes #1169.

+1


[SMALLFIX] Fix Alluxio/new-contributor-tasks#624

Fixes Alluxio/new-contributor-tasks#624
https://github.com/Alluxio/new-contributor-tasks/issues/624

@nand-porko please sign the CLA so that we can accept your contribution.

I have mailed the CLA. Thank you!

@HelloHorizon please check if the CLA has been received.

alluxio-bot, merge this please


Moving cloudidentity (2) resources to v1beta1 version

Moving 2 resources to v1beta1 version

[ ] google_cloud_identity_group
[ ] google_cloud_identity_group_membership

The resources required a Cloud Identity:
https://support.google.com/cloudidentity/answer/7389973?hl=en


Vim Starts in Replace Mode Randomly

Environment
Windows build number: 10.0.19041.0
Windows Terminal version: 1.2.2022.0 (Preview Build)
WSL2 Debian or Ubuntu

Steps to reproduce

Open a Debian or Ubuntu WSL2 instance in a Windows Terminal
Open vim and it will sometimes open in REPLACE mode. This happens seemingly at random, so you may need to quit and reopen vim a few times until you see the --REPLACE-- on the bottom left.
I've reproduced the same behavior over SSH on various systems running different versions and flavors of Linux with various vanilla or custom .vimrc files. This behavior is not reproducible in other terminal emulators (specifically MobaXterm). This behavior also does not appear to affect Neovim in Windows Terminal.

Expected behavior
vim opens in Normal mode every time.
Actual behavior
vim randomly opens in Replace mode sometimes.

Thanks for the report! This is https://github.com/microsoft/terminal/issues/1637, which is marked an external tracking bug for win32-openssh. Unfortunately, the SSH client shipped with Windows is emitting an unusual or unexpected sequence in reply to Vim. More info at https://github.com/microsoft/terminal/issues/1637#issuecomment-663865934.
/dup #1637


Codeunit 6500 - Item Tracking Management - OnBeforeCannotMatchItemTrackingErr new event

I am working on a modification to allow users to pick more than originally requested based on rleased production orders but there is an error I have not been able to circumnavigate. I want to record the quantity picked and then consume manually before then posting actual output and returning any unused inventory to the warehouse.
I tried back tracking but could not find anything else to use with a "IsHandled" boolean and I would rather not copy the function to a custom area in case it changes in the future.
local procedure RegisterNewItemTrackingLines(var TempTrackingSpec: Record "Tracking Specification" temporary)
var
TrackingSpec: Record "Tracking Specification";
ReservEntry: Record "Reservation Entry";
ReservMgt: Codeunit "Reservation Management";
ItemTrackingLines: Page "Item Tracking Lines";
QtyToHandleInItemTracking: Decimal;
QtyToHandleOnSourceDocLine: Decimal;
QtyToHandleToNewRegister: Decimal;
begin
OnBeforeRegisterNewItemTrackingLines(TempTrackingSpec);
    TempTrackingSpec.SetCurrentKey(
      "Source ID", "Source Type", "Source Subtype", "Source Batch Name", "Source Prod. Order Line", "Source Ref. No.");

    if TempTrackingSpec.FindSet() then
        repeat
            TempTrackingSpec.SetSourceFilter(
              TempTrackingSpec."Source Type", TempTrackingSpec."Source Subtype",
              TempTrackingSpec."Source ID", TempTrackingSpec."Source Ref. No.", false);
            TempTrackingSpec.SetRange("Source Prod. Order Line", TempTrackingSpec."Source Prod. Order Line");

            TrackingSpec := TempTrackingSpec;
            TempTrackingSpec.CalcSums("Qty. to Handle (Base)");

            QtyToHandleToNewRegister := TempTrackingSpec."Qty. to Handle (Base)";
            ReservEntry.TransferFields(TempTrackingSpec);
            QtyToHandleInItemTracking :=
              Abs(CalcQtyToHandleForTrackedQtyOnDocumentLine(
                  ReservEntry."Source Type", ReservEntry."Source Subtype", ReservEntry."Source ID", ReservEntry."Source Ref. No."));
            QtyToHandleOnSourceDocLine := ReservMgt.GetSourceRecordValue(ReservEntry, false, 0);

Add >>
OnBeforeCannotMatchItemTrackingErr(TempTrackingSpec, QtyToHandleToNewRegister, QtyToHandleInItemTracking, QtyToHandleOnSourceDocLine);
<< Add <<

            if QtyToHandleToNewRegister + QtyToHandleInItemTracking > QtyToHandleOnSourceDocLine then
                Error(CannotMatchItemTrackingErr);

            TrackingSpec."Quantity (Base)" :=
              TempTrackingSpec."Qty. to Handle (Base)" + Abs(ItemTrkgQtyPostedOnSource(TrackingSpec));

            OnBeforeRegisterItemTrackingLinesLoop(TrackingSpec, TempTrackingSpec);

            Clear(ItemTrackingLines);
            OnRegisterNewItemTrackingLinesOnAfterClearItemTrackingLines(ItemTrackingLines);
            ItemTrackingLines.SetCalledFromSynchWhseItemTrkg(true);
            OnRegisterNewItemTrackingLinesOnBeforeRegisterItemTrackingLines(TempTrackingSpecification, ItemTrackingLines);
            ItemTrackingLines.RegisterItemTrackingLines(TrackingSpec, TrackingSpec."Creation Date", TempTrackingSpec);
            TempTrackingSpec.ClearSourceFilter();
        until TempTrackingSpec.Next() = 0;

    TempTrackingSpec.SetCurrentKey("Entry No.");
end;

Add >>
[IntegrationEvent(false, false)]
local procedure OnBeforeCannotMatchItemTrackingErr(var TempTrackingSpecification: Record "Tracking Specification"; var QtyToHandleToNewRegister: Decimal; var QtyToHandleInItemTracking: Decimal; var QtyToHandleOnSourceDocLine: Decimal)
begin
end;
<< Add <<

Can I get an update on this event request?

Can I get an update on this event request?

Can I get an update on this event request?

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 10481.


namechange: Switch syncbot forum DNS to forums.balena.io

Change-type: minor
Signed-off-by: Jack Brown<EMAIL_ADDRESS>

Already done, closing PR


Pydantic v2 support

Currently heliclockter is incompatible with the latest version of Pydantic (2.0+).
Migration guide is here: https://docs.pydantic.dev/latest/migration/

Apparently pydantic has implemented AwareDatetime and NaiveDatetime in March, which became available for the first time in pydantic v2.0. However, it isn't mentioned in the migration guide nor changelog.
It was added in this PR: https://github.com/pydantic/pydantic/pull/4812
So we have to determine whether AwareDatetime covers all use cases/functionality of heliclockter. In case we want to make a heliclockter release that supports pydantic v2, we can look at the above PR for inspiration on how to implement/test this (specifically how to write __get_pydantic_core_schema__()).


Use patch instead of update when tests patch policies

This prevents race conditions of the different controllers updating the policy when the test tries to update the remediation action.

I bet this is a flakey test: https://github.com/open-cluster-management-io/governance-policy-framework-addon/actions/runs/3053002798/jobs/4923066818#step:10:6892.
I wonder if we should change the fail-fast strategy in the matrix, like in https://github.com/stolostron/governance-policy-framework/blob/main/.github/workflows/kind.yml#L22-L25

Why is patch better than update? I don't have a problem with it, and I do like it in a separate function. I'm just curious.

The issue with update is you need to get the object from the API, make changes, and resubmit it. If there was a change made to that object since you got the object from the API, the update fails. A patch doesn't have this same limitation and it's cleaner than retries.

I bet this is a flakey test: https://github.com/open-cluster-management-io/governance-policy-framework-addon/actions/runs/3053002798/jobs/4923066818#step:10:6892.

I'll try to address this in the PR. I'm having trouble reproducing this locally.

I wonder if we should change the fail-fast strategy in the matrix, like in https://github.com/stolostron/governance-policy-framework/blob/main/.github/workflows/kind.yml#L22-L25

I think there's value to that, but I don't have a strong preference.

/hold for debugging unrelated CI failure

Neat. Well, this time it passed... 🤷

/unhold


Updating fileshare name and description when the status is in "creating" status

Is this a BUG REPORT or FEATURE REQUEST?:
=== RUN   TestUpdateFileShare
2019/06/04 12:27:12
StatusCode: 202 Accepted
Response Body:
{"id":"0ed91af2-2451-4222-8bc3-e139b4e4e931","createdAt":"2019-06-04T12:27:12","updatedAt":"2019-06-04T12:27:12","tenantId":"e93b4c0934da416eb9c8d120c5d04d96","name":"test","description":"This is a test","size":1,"availabilityZone":"default","status":"creating","profileId":"d1ac0d2e-0cb3-431e-925d-e0070986f695"}
2019/06/04 12:27:12
StatusCode: 200 OK
Response Body:
{"id":"0ed91af2-2451-4222-8bc3-e139b4e4e931","createdAt":"2019-06-04T12:27:12","updatedAt":"2019-06-04T12:27:12","tenantId":"e93b4c0934da416eb9c8d120c5d04d96","name":"test","description":"This is a test","size":1,"availabilityZone":"default","status":"available","poolId":"981eed4a-be16-5dac-b529-51148754ba5d","profileId":"d1ac0d2e-0cb3-431e-925d-e0070986f695","exportLocations":["<IP_ADDRESS>:/var/test"],"metadata":{"lvPath":"/dev/opensds-files-default/test","nfsFileshareID":"0ed91af2-2451-4222-8bc3-e139b4e4e931","nfsFileshareName":"test"}}
2019/06/04 12:27:12
StatusCode: 200 OK
Response Body:
{"id":"0ed91af2-2451-4222-8bc3-e139b4e4e931","createdAt":"2019-06-04T12:27:12","updatedAt":"2019-06-04T12:27:12","tenantId":"e93b4c0934da416eb9c8d120c5d04d96","name":"UpdateFileShareName","description":"Update FileShare Description","size":1,"availabilityZone":"default","profileId":"d1ac0d2e-0cb3-431e-925d-e0070986f695","exportLocations":["<IP_ADDRESS>:/var/test"],"metadata":{"lvPath":"/dev/opensds-files-default/test","nfsFileshareID":"0ed91af2-2451-4222-8bc3-e139b4e4e931","nfsFileshareName":"test"}}

Uncomment only one, leave it on its own line:
/kind bug
/kind feature

What happened:
What you expected to happen:
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:

Hotpot(release/branch) version:
OS (e.g. from /etc/os-release):
Kernel (e.g. uname -a):
Install tools:
Others:

@Shruthi-1MN , please mention and provide details on what is expected and how to reproduce..

Tested with latest master branch, it updating file share name and description, only when status is available.
root@shruthi-VirtualBox:~/go/src/github.com/opensds/opensds# curl --header "Content-Type: application/json" --data '{"name": "31test", "description":"test fileshare", "size":2}' http://<IP_ADDRESS>:50040/v1beta/e93b4c0934da416eb9c8d120c5d04d96/file/shares
{"id":"4a845d56-762c-4f7b-bd42-5a280ac907ea","createdAt":"2019-06-12T11:26:32","updatedAt":"2019-06-12T11:26:32","tenantId":"e93b4c0934da416eb9c8d120c5d04d96","name":"31test","description":"test fileshare","size":2,"availabilityZone":"default","status":"creating","profileId":"abc19154-a964-4627-b5a4-ce5313259f57"}
root@shruthi-VirtualBox:~/go/src/github.com/opensds/opensds# curl -X GET http://<IP_ADDRESS>:50040/v1beta/e93b4c0934da416eb9c8d120c5d04d96/file/shares/4a845d56-762c-4f7b-bd42-5a280ac907ea
{"id":"4a845d56-762c-4f7b-bd42-5a280ac907ea","createdAt":"2019-06-12T11:26:32","updatedAt":"2019-06-12T11:26:33","tenantId":"e93b4c0934da416eb9c8d120c5d04d96","name":"31test","description":"test fileshare","size":2,"availabilityZone":"default","status":"available","poolId":"ce8cf5ee-d6a4-529c-8f31-a38fce95105b","profileId":"abc19154-a964-4627-b5a4-ce5313259f57","exportLocations":["<IP_ADDRESS>:/var/31test"],"metadata":{"lvPath":"/dev/opensds-files-default/31test","nfsFileshareID":"4a845d56-762c-4f7b-bd42-5a280ac907ea","nfsFileshareName":"31test"}}
root@shruthi-VirtualBox:~/go/src/github.com/opensds/opensds# curl -X PUT --header "Content-Type: application/json" --data '{"name":"test11", "description":"sample test"}' http://<IP_ADDRESS>:50040/v1beta/e93b4c0934da416eb9c8d120c5d04d96/file/shares/4a845d56-762c-4f7b-bd42-5a280ac907ea
{"id":"4a845d56-762c-4f7b-bd42-5a280ac907ea","createdAt":"2019-06-12T11:26:32","updatedAt":"2019-06-12T11:27:59","tenantId":"e93b4c0934da416eb9c8d120c5d04d96","name":"test11","description":"sample test","size":2,"availabilityZone":"default","status":"available","poolId":"ce8cf5ee-d6a4-529c-8f31-a38fce95105b","profileId":"abc19154-a964-4627-b5a4-ce5313259f57","exportLocations":["<IP_ADDRESS>:/var/31test"],"metadata":{"lvPath":"/dev/opensds-files-default/31test","nfsFileshareID":"4a845d56-762c-4f7b-bd42-5a280ac907ea","nfsFileshareName":"31test"}}

You can close it.


go mod tidy -v does not print information about removed modules

What version of Go are you using (go version)?

$ go version
go version go1.14 darwin/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env

What did you do?

go help mod tidy

usage: go mod tidy [-v]

Tidy makes sure go.mod matches the source code in the module.
It adds any missing modules necessary to build the current module's
packages and dependencies, and it removes unused modules that
don't provide any relevant packages. It also adds any missing entries
to go.sum and removes any unnecessary ones.

The -v flag causes tidy to print information about removed modules
to standard error.

go mod tidy -v
echo $?

What did you expect to see?
Print information about removed modules as the documentation says
What did you see instead?
no information printed.

Duplicate of #33284

Actually, maybe not. What information did you expect it to print?
Ideally, please provide a code sample, such as a reference to a specific repository and commit, for which go mod tidy removes modules from the dependency graph (as reported by go mod graph) but does not print that those modules have been removed.

Hi, @bcmills
Thanks for your reply. Sorry for the lack of information.
Normally when I use go mod tidy -v, it will print the unused package.
For example, this repository (https://github.com/SunRunAway/testgomod) works normally.
[sunrunaway:/tmp/testgomod]$ go mod tidy -v
unused go.uber.org/atomic

But in this repository (https://github.com/SunRunAway/tidb/tree/964f9baa063c5ce282dfeee60678762e0bdc4c46),
When I run go mod tidy -v, it prints nothing but actually removed two line in the go.sum file.
[sunrunaway:...src/github.com/pingcap/tidb]$ git checkout 964f9baa063c5ce282dfeee60678762e0bdc4c46                                                   (964f9baa0)
HEAD is now at 964f9baa0 build: `make tidy` should reports error
[sunrunaway:...src/github.com/pingcap/tidb]$ git status -s                                                                                (964f9baa0)
[sunrunaway:...src/github.com/pingcap/tidb]$ go mod tidy -v                                                                                (964f9baa0)
[sunrunaway:...src/github.com/pingcap/tidb]$ git status -s                                                                                (964f9baa0✱)
 M go.sum

go.sum entries are checksums, not dependencies. (Dependencies are listed in the go.mod file and in the go.mod files of the module versions listed therein.)
go mod tidy only prints information about dependencies removed from the go.mod graph, not the go.sum file.

As far as I can tell this is working as documented, but please let us know if you have additional detail that may indicate a bug.

Thank you for your patient explanation. Sorry for bothering you.
Have no other questions.


Intellij cannot resolve methods (info, debug) for log (using @Slf4j)

Short description
Intellij is unable to resolve the log methods for some reason. The log variable is being resolved just fine. Version information is below. I installed the plugin using the Intellij marketplace.

Version information
IDEA Version
IntelliJ IDEA 2020.2.2 (Ultimate Edition)
Build #IU-202.7319.50, built on September 14, 2020
Runtime version: 11.0.8+10-b944.31 x86_64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
macOS 10.15.6
GC: ParNew, ConcurrentMarkSweep
Memory: 3987M
Cores: 16
Non-Bundled Plugins: IdeaVIM, Lombook Plugin, org.jetbrains.kotlin, com.intellij.lang.jsgraphql

JDK Version: JDK 8 (for project)
OS Type & Version: OS X 10.15.6
Lombok Plugin Version: 0.32-2020.2

You don't have a logger implementation in your classpath or at least Idea can't find it.
Please check that you have implementation of logger in your classpath.
For example: for slf4j it's slf4j-simple

It was in the classpath. I had to reboot my MacBook pro for other reasons and the problem went away.


Add V4 Resource Resolution Migration Mechanism and Insights

This PR contains two commits targeted at helping us migrate from V3 resource resolution algorithm to V4.

The first adds a dynamic property that can effect the probability the old or new algorithm will be used.
The second commit adds a dynamic property that will dry run the V4 command resolution logic and capture the results for debugging/inspection by pertinent parties so that we can tackle as many as we can before the property used in the first commit starts being used. This was requested by the internal configuration admin team

Coverage increased (+0.01%) to 92.83% when pulling c2a96a017cb69a09d0fc1177768154e64b32eea1 on tgianos:GENIE-515 into d3c6ab1cf4a038958725a6899a5748f54fd1b564 on Netflix:master.


Fix the pandas byteorder bug

Pandas only supports data stored in the native byteorder format.  The most common platform (x86) uses little endian, however the FITS file format stores data in big endian, and so it is common for lightkurve to pass data in the wrong byteorder to pandas (e.g. see #188).
This PR adds a fix in to_pandas() to ensure we always pass little endian to pandas.  I also added unit tests to verify the correct byteorder behavior.
@gully Please review and merge!

Codecov Report

Merging #343 into master will decrease coverage by 0.07%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #343      +/-   ##
==========================================
- Coverage   89.78%   89.71%   -0.08%
==========================================
  Files          26       26
  Lines        3937     3946       +9
==========================================
+ Hits         3535     3540       +5
- Misses        402      406       +4

Impacted Files
Coverage Δ

lightkurve/lightcurve.py
93.84% <100%> (+0.24%)
:arrow_up:

lightkurve/tests/test_lightcurve.py
98.48% <100%> (+0.01%)
:arrow_up:

lightkurve/tests/test_targetpixelfile.py
100% <100%> (ø)
:arrow_up:

lightkurve/prf/tpfmodel.py
75.7% <0%> (-1.58%)
:arrow_down:

Continue to review full report at Codecov.

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

Since those systems are presumably uncommon, I'm fine with this solution as it presently stands

They are probably mostly restricted to some POWER and SPARC systems, which you are most likely to encounter in supercomputing environments these days, if at all.
It should be fairly straightforward to amend the patch for those, even if you don't wish to check sys.byteorder, by changing to
data[col] = data[col].byteswap().newbyteorder('=')

Since those systems are presumably uncommon, I'm fine with this solution as it presently stands

They are probably mostly restricted to some POWER and SPARC systems, which you are most likely to encounter in supercomputing environments these days, if at all.
It should be fairly straightforward to amend the patch for those, even if you don't wish to check sys.byteorder, by changing to
data[col] = data[col].byteswap().newbyteorder('=')


Esc/enter keys accept or dismiss dialog on UWP

Please check all of the platforms you are having the issue on (if platform is not listed, it is not supported)

[] iOS
[] Android
[*] UWP
[] NET Standard 2.0

Version of OS(s) listed above with issue (if android - please include version of Xamarin.Android.Support.* you are using)
N/A.
Version of ACR UserDialogs Library
Latest.
Expected Behaviour
Can keyboard events be added for Enter and Esc keys on UWP?
ie. For Prompt, Login controls:

Enter key accepts prompt.
Esc key dismisses prompt.

Actual Behavior
Not currently implemented.
We would be happy to implement and submit a PR.

Would like to see this too

So @aritchie I am about to start work on this and I hope to put up a PR soon. Would you be in favor of setting up a keyboard event handler in each method where it makes sense in UWP.UserDialogsImpl and then adding/removing the event handler in the Dispatch and Dispose action params? This way we keep the listener very localized and avoid global listeners that could live on beyond the lifetime of the dialog? So using Login as an example, something like this:
`        public override IDisposable Login(LoginConfig config)
{
var vm = new LoginViewModel
{
LoginText = config.OkText,
Title = config.Title ?? String.Empty,
Message = config.Message ?? String.Empty,
UserName = config.LoginValue,
UserNamePlaceholder = config.LoginPlaceholder,
PasswordPlaceholder = config.PasswordPlaceholder,
CancelText = config.CancelText
};
vm.Login = new Command(() =>
config.OnAction?.Invoke(new LoginResult(true, vm.UserName, vm.Password))
);
vm.Cancel = new Command(() =>
config.OnAction?.Invoke(new LoginResult(false, vm.UserName, vm.Password))
);
var dlg = new LoginContentDialog
{
DataContext = vm
};
        void onKeyDown(CoreWindow s, KeyEventArgs e)
        {
            var keyboardKey = e.VirtualKey;
            if (keyboardKey == VirtualKey.Enter)
            {
                vm.Login.Execute(null);
            }
            else if (keyboardKey == VirtualKey.Escape)
            {
                vm.Cancel.Execute(null);
            }
        }

        return this.DispatchAndDispose(
            () =>
            {
                Window.Current.CoreWindow.KeyDown += onKeyDown;
                dlg.ShowAsync();
            },
            () =>
            {
                dlg.Hide();
                Window.Current.CoreWindow.KeyDown -= onKeyDown;
            }
        );
    }`

Let me know. Thanks.

That works.  There should be an option to control whether enter/esc keys are active in each config.
UwpCancelEscKey (boolean)
UwpActionEnterKey (boolean)
or something to that effect.

@aritchie I think my work is ready but I am getting a method not found on UserDialogs.Instance trying to run the UWP Samples app.

Hi @aritchie. Any feedback on PR #513? We are a couple weeks away from shipping the latest version of our product and would like to see if this could get in before that.

Would really love to see this in the next release of the package, really useful and needed!


NuGet Package Targeting dnxcore50

I cannot include the NuGet package as a dependency of any portable library. I get an error related to its targeting of dnxcore50. See the following blog post for details:
https://oren.codes/2015/07/29/targeting-net-core/
Here's the error I get when I try to add the reference to a portable library:

Thanks. Do you by chance want to take a stab at fixing it? My time is a bit limited these days.

I think the next step is to support .NET Standard. DNX is already made obsolete.

Will be fixed by #196 (I think).


[TEST] fix flaky test_rebuild_with_restoration, test_single_replica_restore_failure

What's the test to develop? Please describe
test_rebuild_with_restoration is flaky on Rocky Linux 9.3 ARM64 pipeline :
It's because when test case trying to delete a replica from a restoring volume, the volume already retore completed.
AttributeError: 'dict' object has no attribute 'replicaRemove'

Related test case

test_rebuild_with_restoration
test_single_replica_restore_failure

Describe the tasks for the test
Increase data size in backlup volume make the volume restore process take longer time
Additional context
N/A

Test case test_rebuild_with_restoration, test_single_replica_restore_failure are stable in sles pipeline
For Rocky Linux 9.3 ARM64 : 10 times passed
Close this ticket, thank you.


moduleFileExtensions extensions is now passed to babel-jest

Fix for issue https://github.com/facebook/jest/issues/4637.
Transform extensions hardcoded in babel-core 6. Pull request make moduleFileExtensions option to be passed to babel-core as `altExts'.

Can you add a test showing what it enables?
And please update the changelog as well

Codecov Report

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

@@          Coverage Diff           @@
##           master   #5110   +/-   ##
======================================
  Coverage    60.6%   60.6%
======================================
  Files         201     201
  Lines        6688    6688
  Branches        4       4
======================================
  Hits         4053    4053
  Misses       2635    2635

Continue to review full report at Codecov.

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

Under which version?

Do the same as https://github.com/facebook/jest/pull/5138/files#diff-4ac32a78649ca5bdd8e0ba38b7006a1e


Update nats example

Maybe we could provide in a _example directory in this repo for simplicity but thinking about this one:
https://github.com/ThreeDotsLabs/nats-example

I've created a relevant PR https://github.com/ThreeDotsLabs/watermill/pull/278

Thanks for this @VeryStrongFingers - regarding your note on stability I do have a draft PR in the watermill-nats repo that could upset the apple cart a little.  But I think leave all this in a better place long term.
I was thinking of something that lives inside this repo that can be used as a test harness for local changes using replace - see https://github.com/AlexCuse/watermill-nats/tree/master/_examples.  The linked example in the original issue is a bit more built out but the examples you point to are a super quick way to get there and work the system just fine for our purposes.


Add option to make fine control as default control method for keyboard

Before opening the issue, have you...?

[X] Searched for existing issues

Is your feature request related to a problem? Please describe
Currently OSD/keyboard control conforms to the macOS default (one OSD chiclet at a time). Using cmd+shift+media key  it is possible to increase/decrease brightness and volume by 1 as well. Some would prefer the latter to be the default control.
Describe the solution you'd like
Add an option to make fine control as default for keyboard controls as mentioned by @JoniVR here: https://github.com/MonitorControl/MonitorControl/issues/278#issuecomment-915452462
Describe alternatives you've considered
n/a
Anything else?
No response

Something like this:

Screenshot (separate setting for brightness and volume fine control as usually the latter needs it):

See screenshots of the implementation in the v3.1.0 preliminary discussion.


Bug: getrawtransaction Command Not Found in florestad

When running the getrawtransaction command, floresta_cli returns an error indicating that the method is not found in florestad.
$ ./floresta_cli getrawtransaction 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
Error: JsonRpc returned an error RPC error response: RpcError {
    code: -32601,
    message: "Method not found",
    data: None
}

Steps to Reproduce

Checkout the master branch at commit  Current HEAD: 6615959
Run the getrawtransaction command with a valid transaction hash:$ ./floresta_cli getrawtransaction 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b

Observe the response:Error: JsonRpc returned an error RPC error response: RpcError {
    code: -32601,
    message: "Method not found",
    data: None
}

Investigation
Upon reviewing the source code, I found a potential mismatch in the RPC method's name declaration.
In server.rs, the RPC method is defined as gettransaction instead of getrawtransaction:
#[rpc(name = "gettransaction")]
fn get_transaction(&self, tx_id: Txid, verbosity: Option<bool>) -> Result<Value>;

To test, I modified the annotation:
#[rpc(name = "getrawtransaction")]

After rebuilding the project, the command returned:
$ ./floresta_cli getrawtransaction 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
Error: JsonRpc returned an error RPC error response: RpcError {
    code: 3,
    message: "Transaction not found",
    data: None
}

This error (Transaction not found) seems expected because, if I understand the code correctly, the getrawtransaction RPC method only works with watch-only wallets.
Clarification Needed
Since I’m not a Rust developer, I’m unsure if:

This is the intended behavior (e.g., I am using the command incorrectly), or

This is a bug that requires fixing.

Expected Behavior

The getrawtransaction command should work as documented or provide a clear explanation of its usage restrictions.

Environment Details

System Information

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 22.04.5 LTS
Release:	22.04
Codename:	jammy

commit 6615959aa31c3e4d80879be0f2762b048b99e3d1 (HEAD -> master, tag: 0.7.0, origin/master, origin/HEAD, origin/0.7.x)
Author: Davidson Souza<EMAIL_ADDRESS>Date:   Wed Dec 4 10:27:23 2024 -0300

    bump version (#293)

Let me know if further clarification is needed.

AFAIK Floresta doesn't index transactions, getrawtransaction will only work on transactions currently on the mempool. In Bitcoin Core, you would need to set txindex=1 to be able to query any transaction not in the mempool.

You can open a PR to change 'gettransaction' to 'getrawtransaction', seems a good change for me.
In other way, its exactly what @luisschwab said in the comment above. we arent indexating yet. that means we discart the blocks after validating it.

AFAIK Floresta doesn't index transactions, so getrawtransaction will only work on transactions currently on the mempool. In Bitcoin Core, you would need to set txindex=1 to be able to query any transaction not in the mempool.

In core, if you pass the block hash, then no need for txindex.
@lucasbalieiro usually, gettransaction is used for wallet transactions, while getrawtransaction for arbitrary transactions. I think the gettransaction you mentioned returns wallet transactions. So we may just rename it in the CLI.

In core, if you pass the block hash, then no need for txindex

TIL


 is converted to useless element

Basically the same as #32. Replaceable in regular text should become single backtick literal.
Inside screen it should only be the text in the tags without additional formatting.

Needs example

Input:
https://github.com/SUSE/doc-caasp/blob/adoc/xml/admin_software.xml#L217
Output:
https://github.com/SUSE/doc-caasp/blame/adoc/adoc/admin_software.adoc#L146
These [replaceable] should be removed and the string encased in single backticks.

Replaceable doesn't work in code examples so it needs to be stripped from all inline and  examples. Otherwise you end up with a single backtick to start the inline code and then various backticks for the replaceable notation. Example:
Input:
https://github.com/SUSE/doc-caasp/blob/adoc/xml/admin_software.xml#L1061
Output:
https://github.com/SUSE/doc-caasp/blame/adoc/adoc/admin_software.adoc#L785


document more in readme

events
systems
components
archetypes
world creation
specialized arguments

SharedState
EventArgument

synchronization

waitDispatch
waitEvent
dependOn (TODO: not yet implemented)  #23

This is mostly resolved


Edit .enaml files as text file

From<EMAIL_ADDRESS>on 2013-01-22T04:45:30Z
Please note that reporting bugs from Spyder's help menu ("?" > "Report
issue...") will fill version details for Spyder, Python and Qt in this description for you.
What steps will reproduce the problem?

See .enaml file in file explorer
Double click What is the expected output? What do you see instead? Expect open as text file in integrated editor. Instead ask for external editor. What version of the product are you using? On what operating system? Win7, spyder 2.1.12

Please provide any additional information below
. enaml is a syntax for enthought's traits-based UI, superset of python: http://docs.enthought.com/enaml/tech_ref/enaml_file.html
Original issue: http://code.google.com/p/spyderlib/issues/detail?id=1234

From ccordoba12 on 2013-03-16T13:37:33Z
Labels: MS-v2.2

From ccordoba12 on 2013-03-17T06:51:59Z
This issue was updated by revision 65580cc7b6f5 .
Status: Fixed


QRNG airnode response time in Fantom network

Using Quintessence Random Numbers provider:
airnode 0x224e030f03Cd3440D88BD78C9BF5Ed36458A1A25
xpub xpub6CyZcaXvbnbqGfqqZWvWNUbGvdd5PAJRrBeAhy9rz1bbnFmpVLg2wPj1h6TyndFrWLUG3kHWBYpwacgCTGWAHFTbUrXEg6LdLxoEBny2YDz
endpointIdUint256 0xffd1bbe880e7b2c662f6c8511b15ff22d12a4a35d5c8c17202893a5f10e25284
In Fantom (Mainnet) with AirnodeRrpV0 address 0xa0AD79D995DdeeB18a14eAef56A549A04e3Aa1Bd it takes nearly 110 blocks to get a Fulfill response. (132 seconds or 2.2 minutes).
But documentation states that minConfirmations is 1. Is that problem with node or it's standard response time?
2 minutes is way too long for comfort user experience...
We also discussed this in API3 Forum. Can you please add the risky option to get Fulfill after a 1-3 blocks? Because from my point of view, even if reorg occurs, it will just cancel the transactions, but a lot of time will be saved in total.

As discussed in the forum post, we will be rolling out an endpoint with 1 minConfirmation soon, expected timeline is 1-2 weeks after v0.11 launches


db/leases not found

When accessing the webserver from the browser. Browser reports back that db/leases is not found. It is not loaded in sources either. What is required to make it acessible ?

@JUDOKICK in which system are you running KiBRA? Have you installed all the dependencies?

Its running on a RaspberryPi and yes all dependencies have been installed. Although I can't say I'm sure because the list for deps isn't posted.

This is the list of required packages: https://github.com/KiraleTech/KiBRA#requirements
In any case the error you mention is likely due to the DHCP server not being enabled. This can be done by adding these lines in /opt/kirale/kibra.cfg:
{
  "autostart": "1",
  "prefix_dhcp": "1"
}

And forcing a KiBRA restart after:
service kibra restart

Thanks. Gave this a go and it started running!


relays_presence message not consistently broadcasted

In the local dev environment, if you bring everything up, and then issue a docker compose restart relay-1 relay-2, the Gateway shows this:
gateway-1  | 2024-06-25T04:06:46.537834Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[],"disconnected_ids":["f901cfc2-c7f1-4041-9750-a9be2a09eeb2"]}}
gateway-1  | 2024-06-25T04:06:46.541205Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[],"disconnected_ids":["f901cfc2-c7f1-4041-9750-a9be2a09eeb2"]}}
gateway-1  | 2024-06-25T04:06:46.544141Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[],"disconnected_ids":["f901cfc2-c7f1-4041-9750-a9be2a09eeb2"]}}
gateway-1  | 2024-06-25T04:06:46.545699Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[],"disconnected_ids":["f901cfc2-c7f1-4041-9750-a9be2a09eeb2"]}}
gateway-1  | 2024-06-25T04:06:46.546494Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[],"disconnected_ids":["584d40eb-ea8e-445c-84b4-b27fac2ab64e"]}}
gateway-1  | 2024-06-25T04:06:46.547962Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[],"disconnected_ids":["584d40eb-ea8e-445c-84b4-b27fac2ab64e"]}}
gateway-1  | 2024-06-25T04:06:46.550576Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[],"disconnected_ids":["584d40eb-ea8e-445c-84b4-b27fac2ab64e"]}}

It rarely sees the connected list being populated.
There seems to be some kind of race condition or state bug in the portal not broadcasting newly connected Relays to Gateways. Possible cause of #5519

Here's the output on the Gateway from doing a docker compose restart relay-1 && docker compose restart relay-2:
gateway-1  | 2024-06-25T04:22:54.651970Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[{"id":"f901cfc2-c7f1-4041-9750-a9be2a09eeb2","type":"turn","addr":"<IP_ADDRESS>:3478","username":"1720498974:vb6ifWRSDo7v5fmMGK-7Qg","password":"43y3/nfcfszTTVC9kqJeKEYpYM+jnTASFKNfzA13F18","expires_at":1720498974}],"disconnected_ids":["584d40eb-ea8e-445c-84b4-b27fac2ab64e"]}}
gateway-1  | 2024-06-25T04:22:54.652200Z  INFO snownet::node: Added new TURN server id=f901cfc2-c7f1-4041-9750-a9be2a09eeb2 address=V4(<IP_ADDRESS>:3478)
gateway-1  | 2024-06-25T04:22:54.652226Z TRACE wire: to="network" src=None dst=<IP_ADDRESS>:3478 num_bytes=20
gateway-1  | 2024-06-25T04:22:54.652754Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[{"id":"f901cfc2-c7f1-4041-9750-a9be2a09eeb2","type":"turn","addr":"<IP_ADDRESS>:3478","username":"1720498974:CP-f6bCPrCIA8iOtQCY_bA","password":"WASEmpOii2OsvzSxlODhHZBOZHCVO0Jj+bOAF8zqE1U","expires_at":1720498974}],"disconnected_ids":["584d40eb-ea8e-445c-84b4-b27fac2ab64e"]}}
gateway-1  | 2024-06-25T04:22:54.653417Z DEBUG refresh{relay=None}: snownet::allocation: Refreshing allocation
gateway-1  | 2024-06-25T04:22:54.653512Z TRACE wire: to="network" src=None dst=<IP_ADDRESS>:3478 num_bytes=20
gateway-1  | 2024-06-25T04:22:54.653811Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[{"id":"f901cfc2-c7f1-4041-9750-a9be2a09eeb2","type":"turn","addr":"<IP_ADDRESS>:3478","username":"1720498974:qGQNWNWXAqgVbqIqmzbdvw","password":"u3ISgeMQgWN8Afbzs7a01HbiQ6y9h8MSfs/a3aN5i6c","expires_at":1720498974}],"disconnected_ids":["584d40eb-ea8e-445c-84b4-b27fac2ab64e"]}}
gateway-1  | 2024-06-25T04:22:54.653914Z DEBUG refresh{relay=None}: snownet::allocation: Refreshing allocation
gateway-1  | 2024-06-25T04:22:54.654077Z TRACE wire: to="network" src=None dst=<IP_ADDRESS>:3478 num_bytes=20
gateway-1  | 2024-06-25T04:22:54.655410Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[{"id":"f901cfc2-c7f1-4041-9750-a9be2a09eeb2","type":"turn","addr":"<IP_ADDRESS>:3478","username":"1720498974:6kd6avB21Z1izgkMhkZN5w","password":"bDZibJpZAlsdcPZsNa9GwcfbqqCMf05WQco2hw1yyk0","expires_at":1720498974}],"disconnected_ids":["584d40eb-ea8e-445c-84b4-b27fac2ab64e"]}}
gateway-1  | 2024-06-25T04:22:54.656015Z DEBUG refresh{relay=None}: snownet::allocation: Refreshing allocation
gateway-1  | 2024-06-25T04:22:54.656140Z TRACE wire: to="network" src=None dst=<IP_ADDRESS>:3478 num_bytes=20
gateway-1  | 2024-06-25T04:22:54.656567Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[{"id":"f901cfc2-c7f1-4041-9750-a9be2a09eeb2","type":"turn","addr":"<IP_ADDRESS>:3478","username":"1720498974:Eo6k2Nh_29Augc1Uc2CwGg","password":"Xt4v2oxnWbs9ao/j1oeRUzMmhW686XLg2YRoIugEFos","expires_at":1720498974}],"disconnected_ids":["584d40eb-ea8e-445c-84b4-b27fac2ab64e"]}}
gateway-1  | 2024-06-25T04:22:54.656657Z DEBUG refresh{relay=None}: snownet::allocation: Refreshing allocation
gateway-1  | 2024-06-25T04:22:54.656718Z TRACE wire: to="network" src=None dst=<IP_ADDRESS>:3478 num_bytes=20
gateway-1  | 2024-06-25T04:22:54.657554Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[{"id":"f901cfc2-c7f1-4041-9750-a9be2a09eeb2","type":"turn","addr":"<IP_ADDRESS>:3478","username":"1720498974:PfzLTTy_NQc1fRXpsDiwjQ","password":"Ko0vSSZLDHOD6LIV0/o7hP+rk9ZYTXpcQPQhvwsN86o","expires_at":1720498974}],"disconnected_ids":["584d40eb-ea8e-445c-84b4-b27fac2ab64e"]}}
gateway-1  | 2024-06-25T04:22:54.657632Z DEBUG refresh{relay=None}: snownet::allocation: Refreshing allocation
gateway-1  | 2024-06-25T04:22:54.657666Z TRACE wire: to="network" src=None dst=<IP_ADDRESS>:3478 num_bytes=20
gateway-1  | 2024-06-25T04:22:54.658523Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[{"id":"f901cfc2-c7f1-4041-9750-a9be2a09eeb2","type":"turn","addr":"<IP_ADDRESS>:3478","username":"1720498974:YdRa_hD79ytDdqxLP2AHFQ","password":"IATDtFmJE7jtvo0psixphHdfQ1XuxVj6NNoRbtaSBIg","expires_at":1720498974}],"disconnected_ids":["584d40eb-ea8e-445c-84b4-b27fac2ab64e"]}}
gateway-1  | 2024-06-25T04:22:54.659910Z DEBUG refresh{relay=None}: snownet::allocation: Refreshing allocation
gateway-1  | 2024-06-25T04:22:54.660013Z TRACE wire: to="network" src=None dst=<IP_ADDRESS>:3478 num_bytes=20
gateway-1  | 2024-06-25T04:22:54.660300Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[{"id":"f901cfc2-c7f1-4041-9750-a9be2a09eeb2","type":"turn","addr":"<IP_ADDRESS>:3478","username":"1720498974:rkHzvne8YNKRKGyBbB9pbw","password":"GlczkVvEVOdX3VpHTnyceKiKl0+Mk4EcIDhKKqYtpVE","expires_at":1720498974}],"disconnected_ids":["584d40eb-ea8e-445c-84b4-b27fac2ab64e"]}}
gateway-1  | 2024-06-25T04:22:54.660389Z DEBUG refresh{relay=None}: snownet::allocation: Refreshing allocation
gateway-1  | 2024-06-25T04:22:54.660543Z TRACE wire: to="network" src=None dst=<IP_ADDRESS>:3478 num_bytes=20
gateway-1  | 2024-06-25T04:22:54.661459Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[{"id":"f901cfc2-c7f1-4041-9750-a9be2a09eeb2","type":"turn","addr":"<IP_ADDRESS>:3478","username":"1720498974:ZiB0d95J-Cl6k-fKGoQa8A","password":"wxvpFvnxnp082V7VKek3icChZ7dP9X1t/8ly724fj1M","expires_at":1720498974}],"disconnected_ids":["584d40eb-ea8e-445c-84b4-b27fac2ab64e"]}}
gateway-1  | 2024-06-25T04:22:54.661591Z DEBUG refresh{relay=None}: snownet::allocation: Refreshing allocation
gateway-1  | 2024-06-25T04:22:54.661675Z TRACE wire: to="network" src=None dst=<IP_ADDRESS>:3478 num_bytes=20
gateway-1  | 2024-06-25T04:22:54.662408Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[{"id":"f901cfc2-c7f1-4041-9750-a9be2a09eeb2","type":"turn","addr":"<IP_ADDRESS>:3478","username":"1720498974:jlEQuoSq3uh5p9t3JrfXow","password":"Ce9/pCJRwLbI10qInq4hVM7wd5q3EWdX/FJHYm3ANr8","expires_at":1720498974}],"disconnected_ids":["584d40eb-ea8e-445c-84b4-b27fac2ab64e"]}}
gateway-1  | 2024-06-25T04:22:54.662523Z DEBUG refresh{relay=None}: snownet::allocation: Refreshing allocation
gateway-1  | 2024-06-25T04:22:54.662919Z TRACE wire: to="network" src=None dst=<IP_ADDRESS>:3478 num_bytes=20
gateway-1  | 2024-06-25T04:22:54.664457Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[{"id":"f901cfc2-c7f1-4041-9750-a9be2a09eeb2","type":"turn","addr":"<IP_ADDRESS>:3478","username":"1720498974:gqyGWODhC-7OiOb-upQeaA","password":"+obR/GA47grKf5pKcRbFR07lA3xBJZ94JVu2HN8PaQo","expires_at":1720498974}],"disconnected_ids":["584d40eb-ea8e-445c-84b4-b27fac2ab64e"]}}
gateway-1  | 2024-06-25T04:22:54.664725Z DEBUG refresh{relay=None}: snownet::allocation: Refreshing allocation
gateway-1  | 2024-06-25T04:22:54.664809Z TRACE wire: to="network" src=None dst=<IP_ADDRESS>:3478 num_bytes=20
gateway-1  | 2024-06-25T04:22:54.665416Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[{"id":"f901cfc2-c7f1-4041-9750-a9be2a09eeb2","type":"turn","addr":"<IP_ADDRESS>:3478","username":"1720498974:lKIbuWTGn0PX3khOnkk5lg","password":"7YV+ibfMSTnCw4LpWoLw/+uJhZCaopIMiRz289dQqY0","expires_at":1720498974}],"disconnected_ids":["584d40eb-ea8e-445c-84b4-b27fac2ab64e"]}}
gateway-1  | 2024-06-25T04:22:54.665715Z DEBUG refresh{relay=None}: snownet::allocation: Refreshing allocation
gateway-1  | 2024-06-25T04:22:54.665800Z TRACE wire: to="network" src=None dst=<IP_ADDRESS>:3478 num_bytes=20
gateway-1  | 2024-06-25T04:22:54.666571Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[{"id":"f901cfc2-c7f1-4041-9750-a9be2a09eeb2","type":"turn","addr":"<IP_ADDRESS>:3478","username":"1720498974:VfYij736buxynlEoBdgWQg","password":"psyniy+k5O2FYjMijtSgx6ob9q7TOZgN62bWXVgFIfU","expires_at":1720498974}],"disconnected_ids":["584d40eb-ea8e-445c-84b4-b27fac2ab64e"]}}
gateway-1  | 2024-06-25T04:22:54.666918Z DEBUG refresh{relay=None}: snownet::allocation: Refreshing allocation
gateway-1  | 2024-06-25T04:22:54.667057Z TRACE wire: to="network" src=None dst=<IP_ADDRESS>:3478 num_bytes=20
gateway-1  | 2024-06-25T04:22:54.668304Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[{"id":"f901cfc2-c7f1-4041-9750-a9be2a09eeb2","type":"turn","addr":"<IP_ADDRESS>:3478","username":"1720498974:3rvaOtiu-otiT2husJ8bpg","password":"OCrJR154tEEZUkD6jA2nalpfjkGPZDasCw3jcFrcyn4","expires_at":1720498974}],"disconnected_ids":["584d40eb-ea8e-445c-84b4-b27fac2ab64e"]}}
gateway-1  | 2024-06-25T04:22:54.668551Z DEBUG refresh{relay=None}: snownet::allocation: Refreshing allocation
gateway-1  | 2024-06-25T04:22:54.668607Z TRACE wire: to="network" src=None dst=<IP_ADDRESS>:3478 num_bytes=20
gateway-1  | 2024-06-25T04:22:54.669622Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[{"id":"f901cfc2-c7f1-4041-9750-a9be2a09eeb2","type":"turn","addr":"<IP_ADDRESS>:3478","username":"1720498974:xgvRbwfKgvhw7wZGUPKRxg","password":"KXd4l0I2chI3WuRPk/tr2JybMAPyOopZfjKzsP43314","expires_at":1720498974}],"disconnected_ids":["584d40eb-ea8e-445c-84b4-b27fac2ab64e"]}}
gateway-1  | 2024-06-25T04:22:54.669756Z DEBUG refresh{relay=None}: snownet::allocation: Refreshing allocation
gateway-1  | 2024-06-25T04:22:54.669864Z TRACE wire: to="network" src=None dst=<IP_ADDRESS>:3478 num_bytes=20
gateway-1  | 2024-06-25T04:22:54.670469Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[{"id":"f901cfc2-c7f1-4041-9750-a9be2a09eeb2","type":"turn","addr":"<IP_ADDRESS>:3478","username":"1720498974:AD3JfgY75Q_h3hqd719-Hw","password":"9gdnlP6+GTrJAwzjfZ2X116InkZDLc4w5NYey4X/R1s","expires_at":1720498974}],"disconnected_ids":["584d40eb-ea8e-445c-84b4-b27fac2ab64e"]}}
gateway-1  | 2024-06-25T04:22:54.670587Z DEBUG refresh{relay=None}: snownet::allocation: Refreshing allocation
gateway-1  | 2024-06-25T04:22:54.670639Z TRACE wire: to="network" src=None dst=<IP_ADDRESS>:3478 num_bytes=20
gateway-1  | 2024-06-25T04:22:54.671410Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[{"id":"f901cfc2-c7f1-4041-9750-a9be2a09eeb2","type":"turn","addr":"<IP_ADDRESS>:3478","username":"1720498974:6YkjxHi7JqsavTtkSg7QkA","password":"tWqVHq/rWlhFRiFpdalMTO1hL4Jf7vssl0AaMKwBQTI","expires_at":1720498974}],"disconnected_ids":["584d40eb-ea8e-445c-84b4-b27fac2ab64e"]}}
gateway-1  | 2024-06-25T04:22:54.671512Z DEBUG refresh{relay=None}: snownet::allocation: Refreshing allocation
gateway-1  | 2024-06-25T04:22:54.671567Z TRACE wire: to="network" src=None dst=<IP_ADDRESS>:3478 num_bytes=20
gateway-1  | 2024-06-25T04:22:54.672295Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[{"id":"f901cfc2-c7f1-4041-9750-a9be2a09eeb2","type":"turn","addr":"<IP_ADDRESS>:3478","username":"1720498974:FUetTQ0rcOgQ7K2VFosJ0w","password":"fxH4TjRGwR/82ltikooKA1aIIgPTL7IHqbSd40fdPVU","expires_at":1720498974}],"disconnected_ids":["584d40eb-ea8e-445c-84b4-b27fac2ab64e"]}}
gateway-1  | 2024-06-25T04:22:54.672539Z DEBUG refresh{relay=None}: snownet::allocation: Refreshing allocation
gateway-1  | 2024-06-25T04:22:54.672632Z TRACE wire: to="network" src=None dst=<IP_ADDRESS>:3478 num_bytes=20
gateway-1  | 2024-06-25T04:22:54.672812Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[{"id":"f901cfc2-c7f1-4041-9750-a9be2a09eeb2","type":"turn","addr":"<IP_ADDRESS>:3478","username":"1720498974:TfIU6dwl_ZSGAashW1aUsA","password":"3pkkScCa+f0uvQ8TMb/+moaykb1ANiL1zggIq0oQA2M","expires_at":1720498974}],"disconnected_ids":["584d40eb-ea8e-445c-84b4-b27fac2ab64e"]}}
gateway-1  | 2024-06-25T04:22:54.672873Z DEBUG refresh{relay=None}: snownet::allocation: Refreshing allocation
gateway-1  | 2024-06-25T04:22:54.673102Z TRACE wire: to="network" src=None dst=<IP_ADDRESS>:3478 num_bytes=20
gateway-1  | 2024-06-25T04:22:54.673879Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[{"id":"f901cfc2-c7f1-4041-9750-a9be2a09eeb2","type":"turn","addr":"<IP_ADDRESS>:3478","username":"1720498974:_FRN23py7zecgxAifv0xNA","password":"14B/tQ2jLgO0Gq96OhdChIyzMdcYZ2N0l+erVw2VFIE","expires_at":1720498974}],"disconnected_ids":["584d40eb-ea8e-445c-84b4-b27fac2ab64e"]}}
gateway-1  | 2024-06-25T04:22:54.674069Z DEBUG refresh{relay=None}: snownet::allocation: Refreshing allocation
gateway-1  | 2024-06-25T04:22:54.674117Z TRACE wire: to="network" src=None dst=<IP_ADDRESS>:3478 num_bytes=20
gateway-1  | 2024-06-25T04:22:54.674580Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[{"id":"f901cfc2-c7f1-4041-9750-a9be2a09eeb2","type":"turn","addr":"<IP_ADDRESS>:3478","username":"1720498974:kkKRVchwLvZLGpfpyKGA5A","password":"sOVaRXcyxehQv5X5slwnczxD5qJuRDgmPCY851KYxXE","expires_at":1720498974}],"disconnected_ids":["584d40eb-ea8e-445c-84b4-b27fac2ab64e"]}}
gateway-1  | 2024-06-25T04:22:54.674691Z DEBUG refresh{relay=None}: snownet::allocation: Refreshing allocation
gateway-1  | 2024-06-25T04:22:54.674734Z TRACE wire: to="network" src=None dst=<IP_ADDRESS>:3478 num_bytes=20
gateway-1  | 2024-06-25T04:22:54.675467Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[{"id":"f901cfc2-c7f1-4041-9750-a9be2a09eeb2","type":"turn","addr":"<IP_ADDRESS>:3478","username":"1720498974:6teKNqm9pnU2CyEBfguOSw","password":"lHKDo480JafXI6IqABw+h6IvkZVbaCdKwQFvd2/Ut0Y","expires_at":1720498974}],"disconnected_ids":["584d40eb-ea8e-445c-84b4-b27fac2ab64e"]}}
gateway-1  | 2024-06-25T04:22:54.675557Z DEBUG refresh{relay=None}: snownet::allocation: Refreshing allocation
gateway-1  | 2024-06-25T04:22:54.675622Z TRACE wire: to="network" src=None dst=<IP_ADDRESS>:3478 num_bytes=20
gateway-1  | 2024-06-25T04:22:54.676299Z TRACE wire: from="portal" {"event":"relays_presence","ref":null,"topic":"gateway","payload":{"connected":[{"id":"f901cfc2-c7f1-4041-9750-a9be2a09eeb2","type":"turn","addr":"<IP_ADDRESS>:3478","username":"1720498974:SGaTlYbO6y1VlCbiO2ae8g","password":"vcYh3cRZ6Vmjtn1Kx6L+fPpw+HpDsCbrntE9RwzuUss","expires_at":1720498974}],"disconnected_ids":["584d40eb-ea8e-445c-84b4-b27fac2ab64e"]}}
gateway-1  | 2024-06-25T04:22:54.676530Z DEBUG refresh{relay=None}: snownet::allocation: Refreshing allocation
gateway-1  | 2024-06-25T04:22:54.676583Z TRACE wire: to="network" src=None dst=<IP_ADDRESS>:3478 num_bytes=20

I don't think the above would cause the issue though. I think this reproduces the issue seen in #5519
docker compose up -d
# wait for everything to come online

# restart API
docker compose restart api

# gateways / relays automatically reconnect

# stop relays one-by-one. we should see a `relays_presence` message.
docker compose stop relay-1
docker compose stop relay-2

# no `relays_presence` message

There seems to be some kind of race condition or state bug in the portal not broadcasting newly connected Relays to Gateways.

We do not broadcast all newly connected relays, when Gateway connects it gets a few relays and subscribes to events for them. I think what is happening is that in dev env gateway connects before relay and gateway has nothing to subscribe for.


Issue when trying this in us-central1

I have set region/zone to us-central1/us-central1-a, but the demo has failed. By looking at the logs, it seems that the script tried to create a NAT Gateway in us-west1... why ? given that the default region is us-central1.
`google_compute_router.router: Creation complete after 9s [id=us-west1/test-cluster-cloud-router]
google_compute_firewall.bastion-ssh: Still creating... [10s elapsed]
google_compute_subnetwork.subnetwork: Still creating... [10s elapsed]
google_compute_firewall.bastion-ssh: Creation complete after 16s [id=test-cluster-bastion-ssh]
google_compute_subnetwork.subnetwork: Still creating... [20s elapsed]
google_compute_subnetwork.subnetwork: Still creating... [30s elapsed]
google_compute_subnetwork.subnetwork: Creation complete after 39s [id=us-west1/my-subnet]
google_compute_router_nat.nat: Creating...
google_compute_instance.instance: Creating...
Error: Error waiting to patch router us-west1/test-cluster-cloud-router: Error waiting for Patching router: error while retrieving operation: googleapi: Error 401: Invalid Credentials, authError
on network.tf line 109, in resource "google_compute_router_nat" "nat":
109: resource "google_compute_router_nat" "nat" {
Error: Error waiting for instance to create: error while retrieving operation: Get https://www.googleapis.com/compute/v1/projects/my-apigee-project/zones/us-west1-a/operations/operation-1564478751498-58ee2983de116-77b5505e-ecefd8fe?alt=json&prettyPrint=false: oauth2/google: incomplete token received from metadata
on network.tf line 169, in resource "google_compute_instance" "instance":
169: resource "google_compute_instance" "instance" {
`

This should be fixed now


Unknown word on LESS mixin

<css input>:17:3: Unknown word
.iconButton {
  cursor: pointer;
  color: @grey;

  &:hover {
    color: @blue;
  }
}

.buttons {
  position: absolute;
  top: 5px;
  right: 0;
  opacity: 0.5;

  & > * {
    .iconButton();
  }
}

Unfortunately, atom-postcss-sorting doesn't support LESS syntax atm.
Will be added in future release with this PR https://github.com/lysyi3m/atom-postcss-sorting/pull/27


Lokalise: Translations update

This pull request was initiated by Lokalise (user Peter Murray) at 2022-04-01 18:53:38

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Bump :lang haskell

Switch to haskell-language-server, see https://neilmitchell.blogspot.com/2020/09/dont-use-ghcide-anymore-directly.html

Would you mind bumping the other packages in this module (M-x doom/bump-module RET :lang haskell), then rewording the commit to:
Bump :lang haskell

emacs-lsp/lsp-haskell@17d7d4c -> emacs-lsp/lsp-haskell@a56667b
haskell/haskell-mode@41683c0 -> haskell/haskell-mode@e726776
jyp/attrap@4cf3e4a -> jyp/attrap@9c88154
jyp/dante@c516bc9 -> jyp/dante@e2acbf6

Switch to haskell-language-server, see
https://neilmitchell.blogspot.com/2020/09/dont-use-ghcide-anymore-directly.html

Bump commits must follow a particular format, so they are machine-readable by future CI.

Thanks for your help!


gtk3: fix build on darwin

Motivation for this change
gdkquartz-gtk-only.h is now included in distribution tarballs https://gitlab.gnome.org/GNOME/gtk/-/commit/235d28f02d54e6601cef51fec91d46961f64009e
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[X] NixOS
[X] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

Hm, should this be staging, I wonder? @LnL7 maybe you have some advice?

I think it's safe to go to master, since it only affects darwin, and those packages are currently broken

Yeah, nixpkgs-unstable is blocked https://hydra.nixos.org/build/113759839

@GrahamcOfBorg build gtk3
this didn't build on darwin for some reason

Confirmed this wasn't a problem on stable https://hydra.nixos.org/job/nixpkgs/nixpkgs-20.03-darwin/gtk3.x86_64-darwin


generate extern files

Hello,
I was secure to find this issue already written, but with search I don't found it.
My request is adds a output_info to generate files to add as extern in compilation of another file .
I see there is: http://www.dotnetwise.com/code/externs/ but I think it should be better add it on compiler.
As plus I use the post api to compile local files and should be great if I can generate externs files also.
I am pretty sure it was already discussed, but I don't find the old discussion...
Regards,
Antonino Perricone
Ps. I attached my simple builder in vb.net, maybe someone is curious.
mybuild.vb.txt

There's an ExternExportsPass which creates an externs file containing all exported symbols and properties, but I don't think there's a command line flag for that (yet).

I see it was created almost 6 years ago, it looks abandoned...

There is a flag for it in the Google-internal version of the compiler, and it is used by a variety of projects.

Is anyone planning to add this flag to the open-source compiler?  If not, I volunteer as tribute.

@joeyparrish I don't think anyone's actively working on adding this flag, so welcome!


Request for Legacy Support of linearmouse App for macOS Mojave 10.14.6

OS
macOS Mojave 10.14.6
LinearMouse
No response
Is your feature request related to a problem?
Hello,
Linearmouse is a great macOS utility for improving external mouse performance and functionalities. I am reaching out today to discuss a matter concerning compatibility with legacy macOS versions from Intel platforms. Specifically, a lot of users are still using macOS Mojave (10.14) from intel platforms and I've been encountering some difficulties running the latest versions of the linearmouse app. I understand the complexities of maintaining support for legacy operating systems in parallel with developing new features and maintaining up-to-date system compatibility. However, given that Mojave 10.14 still has a significant user base, it would be greatly beneficial if linearmouse could extend its support to include this version.
I believe this legacy support would not only assist myself, but also other users who may not have the option to upgrade their OS due to hardware limitations or other constraints. There may also be users who prefer the Mojave OS for its unique features and stability.
It would be fantastic if your team could consider this request and perhaps provide an update or patch that ensures linearmouse runs smoothly on macOS Mojave 10.14. I truly appreciate your consideration of this issue, and I believe it would make a great difference to users like myself.
Thank you for your time and consideration.
Describe the solution you'd like
Add support for macOS Mojave 10.14.6
Describe alternatives you've considered
No response
Additional context
No response

Currently, the biggest obstacle to supporting earlier versions of macOS is that the user interface technology (specifically, SwiftUI) used by LinearMouse only supports macOS Catalina and newer versions. This means that achieving this goal would require replacing the user interface technology and rewriting the entire user interface, which would be a significant undertaking.
However, I have noticed some performance and compatibility issues with SwiftUI, and since it is closed-source, these issues are not easy to address. Hence, it is possible that I might switch to a different user interface technology in the upcoming major release, which could potentially offer support for Mojave.

Thanks @lujjjh for the follow up.
I agree, user interface might be a big challenge, if we can separate out it with logic foundations, this might not only apply to legacy macOS, might also be possible to ported to other OS as well.


Is shellscript meant to work for *.sh files?

Hi,
I couldn't get the bash snippets to work on *.sh named files.
But they do seem to work with python.
Using luasnip so wondering if the shellscript is meant to be used for bash scripts.

Yes, snippets from shell are meant to work with sh files. I just tested and they work for me.

Wondering how to get this more verbose, as they are not appearing at all.

Weird I gotten it to work after switching the package.json from language shellscript to sh or shell.

Weird I gotten it to work after switching the package.json from language shellscript to sh or shell.

mmmm... yeah that's weird. Thanks for letting me know, I'll add sh and shell to the language in case anyone else has your problem.


Fix base64 padding with multiple =-signs. An equal amount of dots is …

…required in output
instead of merging all =-signs into one dot, which can then not be decoded. Test string:
SELECT * from version  where "isHelper" order by "order" desc
will be encode to
U0VMRUNUICogZnJvbSB2ZXJzaW9uICB3aGVyZSAiaXNIZWxwZXIiIG9yZGVyIGJ5ICJvcmRlciIgZGVzYw.
missing a dot at the end making it undecodable.
Since =-signs only appear at the end anyway, we don't need the explicit '$' in the regexp

I'll look into this. Base64 was not really a good choice so it'll be replaced with something more robust in near future.

Maybe; but the currently implementation is broken and my commit fixes it.
If you include this fix; there is less need for an alternative solution imo

Im more that happy to merge this PR, could you please include a few example queries that did not work for you. I tried the query you provided and it went through just fine (no issues with decoding).
Also, which pgweb version are you on?

It seems a ; fell off, added that to my initial comment. I'm using the latest release, 0.9.5
Providing additional queries is difficult as I cannot predict when multiple padding-chars are added


SAKIII-4226 specify an increased height for both image/checkbox so they d

SAKIII-4226 specify an increased height for both image/checkbox so they dont change the height of the div
https://jira.sakaiproject.org/browse/SAKIII-4226

New pull request for this issue at https://github.com/sakaiproject/3akai-ux/pull/1245


Error in adding a day to a date template

Description of the bug
adding 1 day to now function using the response template returns the current date and not adding 1 day to now function reduces the date by 1010 years, please used the below date templates to reproduce to reproduce the issue
Steps to reproduce the issue
compare the result of the below two templates
(1) "{{now '' 'Mon, 01 Feb 2021 17:15:13 GMT'}}"
(2) "{{now '1d' 'Mon, 01 Feb 2021 17:15:13 GMT'}}"

Observed result
Hoverfly error messages seen (If none, say none)
(1)Mon, 02 Feb 1012 27:20:28 GMT
(2)Tue, 02 Feb 2022 27:20:28 GMT

Template in Simulation file

response Output

Expected result
(1)Mon, 01 Feb 2022 27:20:28 GMT
(2)Tue, 02 Feb 2022 27:20:28 GMT

Additional relevant information

Hoverfly version: 1.3.1
Anything that might help us to diagnose the problem

That's because Golang requires date formating to use a "special" layout parameter (🤷♂ ): https://yourbasic.org/golang/format-parse-string-time-date-example/
this one should work:
{{ now '' 'Mon, 02 Jan 2006 15:04:05 MST' }}
I'll update the doc to make it a bit more clear

Thanks @tommysitu  , that works !