Prototype for new make upstream targets for patch resolution

This is a prototype PR for a more ergonomic Makefile target for resolving patch conflicts.
Idea
Except for the message displayed to the user on failure, make upstream (and other "normal" commands) work exactly as before.
I have removed make start-patch and make finish-patch, replacing them with make upstream.rebase and make upstream.toPatches. make upstream.rebase applies the patch set (the files in ./patches) to the upstream. Each file is applied as an individually named commit. make upstream.toPatches takes the set of commits that are currently applied to upstream (beyond what was there before make upstream.rebase was called) and turns that into the patch set.

Separately: to improve the user experience and remove sharp edges, if there is a rebase in progress and make upstream or make upstream.rebase is run, the user will get an error message explaining that the action will overwrite the current rebase give instructions on how to resolve proceed:
𝛌 make upstream
A rebase is already in progress. To finish the current rebase,
complete the `git rebase` in `./upstream` and then run:

    make upstream.toPatches

If you want to abandon the rebase currently in progress and
execute this target anyway, run:

    rm rebase-in-progress && make upstream

gmake: *** [Makefile:201: upstream] Error 1

Examples
To better explain how that works in practice, lets walk through 3 common scenarios that happen during an upgrade:
Lets assume that we are upgrading this repository (pulumi-gitlab) from v3.19.0 to v3.20.0.

Our patches conflict with the new upstream.

As the upgrader, we don't know that patches will conflict. We just run (or upgrade-provider just runs) make tfgen with the new upstream commit checked out:
𝛌 (cd upstream && git checkout v3.20.0) && git add upstream
Previous HEAD position was 8a62fb0a Merge branch 'changelog/v3.19.0' into 'main'
HEAD is now at ac18ce41 Do not depend on artifacts in release stage

𝛌 make tfgen
[ -x "/Users/ianwahbe/go/bin/pulumi" ] || curl -fsSL https://get.pulumi.com | sh
Submodule path 'upstream': checked out 'ac18ce416d9029f8895fc3719f2aa93e785dc154'
Applied patch to 'internal/provider/resource_gitlab_project.go' with conflicts.
U internal/provider/resource_gitlab_project.go
Resolved 'internal/provider/resource_gitlab_project.go' using previous resolution.

`make upstream` failed to apply a patch. This is because there is a conflict between
the checkout version of upstream and the patch set. To resolve this conflict
run

    make upstream.rebase FROM=$LAST_KNOWN_GOOD_COMMIT

This will walk you through resolving the conflict and producing a new patch set
that applies cleanly to `$DESIRED_COMMTI`.

gmake: *** [Makefile:211: upstream] Error 1

We now get a helpful error message explaining what happened and telling us what the next step is to continue. We know that our current patch set applied cleanly to v3.19.0 since that is the version of upstream currently released. Trying that, we get:
𝛌 make upstream.rebase FROM=v3.19.0
git submodule update --force --init
Submodule path 'upstream': checked out 'ac18ce416d9029f8895fc3719f2aa93e785dc154'
cd upstream && git fetch
# TO not specified, assuming TO is the upstream SHA currently commited
cd upstream && git checkout -B local
Switched to and reset branch 'local'
# We use a local tag branch here because our upstream is almost always a tag, and
# we can't rebase into a tag.
cd upstream && git checkout -B pulumi-patch v3.19.0
Switched to and reset branch 'pulumi-patch'
Your branch is behind 'local' by 82 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)
cd upstream && git branch --set-upstream-to=local pulumi-patch
branch 'pulumi-patch' set up to track 'local'.
Applying patches/0001-fork.patch
Applied patch to 'internal/provider/resource_gitlab_project.go' cleanly.
[pulumi-patch 27879929] fork
 1 file changed, 21 insertions(+), 20 deletions(-)
Applying patches/0002-expose-provider.patch
Falling back to direct application...
[pulumi-patch 2cb8dddc] expose-provider
 1 file changed, 10 insertions(+)
 create mode 100644 shim/shim.go
Auto-merging internal/provider/resource_gitlab_project.go
CONFLICT (content): Merge conflict in internal/provider/resource_gitlab_project.go
error: could not apply 27879929... fork
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
Resolved 'internal/provider/resource_gitlab_project.go' using previous resolution.
Could not apply 27879929... fork

The patch set did not apply cleanly. You need to manually resolve
rebase conflicts directly in `./upstream`. When you have completed
the rebase, run

    make upstream.toPatches

This will finalize the changes you made back into the patch set.

Most of this is output from the git patching process, but the important part is the message at the end. It tells us that we need to manually resolve the conflict directly in the ./upstream repo. We can do that with whichever tool we want. I use emacs:
𝛌 emacs internal/provider/resource_gitlab_project.go

Now that the conflict is resolved, we can run make upstream.toPatches, just like we were told to:
𝛌 make upstream.toPatches
cd upstream && git format-patch local -o ../patches
../patches/0001-fork.patch
../patches/0002-expose-provider.patch

We see a list of all our patches. make tfgen will now work. We are done!

We need to add a new patch because we have found a bug in the next upstream version.

We have discovered that terraform-provider-gitlab v3.20.0 only works if there is a file called please-work.txt next to the go.mod that defines the TF provider. We need to add such a file. We want to edit the upstream patch set, so we run make upstream.rebase.
Note: This is always the command that we start patch set edits with.
𝛌 make upstream.rebase
git submodule update --force --init
Submodule path 'upstream': checked out 'ac18ce416d9029f8895fc3719f2aa93e785dc154'
... # Abbreviated for readability
Falling back to direct application...
[pulumi-patch d63ce0d1] expose-provider
 1 file changed, 10 insertions(+)
 create mode 100644 shim/shim.go
Current branch pulumi-patch is up to date.

The full patch set has been cleanly applied to the `./upstream` repository.
To "edit" the patch set, commit changes directly to `./upstream`. When
you are done making changes, run

    make upstream.toPatches

to finish the rebase and commit those changes into the patch set.

Here we see a slightly different user message than before. It says our patch applied cleanly, so we can just make edits on upstream. Let's make the edit we need.
𝛌 cd upstream
𝛌 touch please-work.txt
𝛌 git add please-work.txt
𝛌 git commit -m "Say please"
[pulumi-patch 7881a53d] Say please
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 please-work.txt

To finish, we run make upstream.toPatches. This is how we end all patch set edits.
𝛌 make upstream.toPatches
cd upstream && git format-patch local -o ../patches
../patches/0001-fork.patch
../patches/0002-expose-provider.patch
../patches/0003-Say-please.patch

That's it. We are done.

The final scenario has us wanting to clarify the patch set. The 0001-fork.patch has runtime changes to internal/provider/resource_gitlab_project.go, but also docs changes to docs/index.md. We want to split these into separate patches so its easier for reviewers to tell what the patch set contains.

At this point, you can probably guess how we start:
𝛌 make upstream.rebase
git submodule update --force --init
Submodule path 'upstream': checked out 'ac18ce416d9029f8895fc3719f2aa93e785dc154'
cd upstream && git fetch
... # Abbreviated for readability
The full patch set has been cleanly applied to the `./upstream` repository.
To "edit" the patch set, commit changes directly to `./upstream`. When
you are done making changes, run

    make upstream.toPatches

to finish the rebase and commit those changes into the patch set.

We have three commits, and we need to edit the deepest one:
𝛌 git log HEAD...local
commit 53c2df1c2ac8151d43b5d5496f908d4cc9688254 (HEAD -> pulumi-patch)
Author: Ian Wahbe<EMAIL_ADDRESS>Date:   Thu Apr 27 18:39:32 2023 -0700

    Say-please

commit fca02b2961e8e04e55c6db90304d6b1ac2504bbc
Author: Ian Wahbe<EMAIL_ADDRESS>Date:   Thu Apr 27 18:39:32 2023 -0700

    expose-provider

commit c6ddb77a69ee82a49a75ab5bb79864639517fff7
Author: Ian Wahbe<EMAIL_ADDRESS>Date:   Thu Apr 27 18:39:32 2023 -0700

    fork

We can now perform the normal process for splitting up an old commit:
𝛌 git rebase -i HEAD~3
𝛌 git add docs/index.md && git commit -m "Improve top level docs"
𝛌 git add internal/provider/resource_gitlab_project.go && git commit --amend -m "Remove conflicts-with"
𝛌 git rebase --continue

We now have history in our preferred shape, so we finilze our patch set edit the same way we finalize all patch set edits: make upstream.toPatches.
𝛌 make upstream.toPatches
cd upstream && git format-patch local -o ../patches
../patches/0001-Improve-top-level-docs.patch
../patches/0002-Remove-conflicts-with.patch
../patches/0003-expose-provider.patch
../patches/0004-Say-please.patch

We are done.
Conclusion
We still have all the benefits of a patched provider: All changes are local and checked in. make tfgen will just work™ in the happy case. This change makes conflict resolution exactly as simple as git rebase, because it turns conflict resolution into git rebase. This allows each developer to use their preferred tooling for rebase resolution and keeps patched provider operations as close as possible to normal git operations.
Next steps
Add these change to our generated makefiles via ci-mgmt. That's it.

However in the grand scheme of things I'm pondering how is maintaining a set of patches with custom generic (it does not use Pulumi knowledge) tooling we're obligated to build and maintain is better than using off-the-shelf tooling with a larger user base.

is it really easier than managing forks with Git?

Our fork changes are checked in with the rest of our changes, and we see inline git blame results. Updates are atomic and PR based. I do think this is easier.

did we look at other tooling? If we do not like forks and submodules maybe https://www.atlassian.com/git/tutorials/git-subtree ?

We looked at other tooling. There is existing tooling (such as git subtree) to maintain a nested repo locally. There is not tooling to maintain a nested repo with modifications.[^1] We would either need to push unreviewed branches to a fork (and then not change them) every update, or we would need to maintain a normal fork and do two PR reviews every update.
The first is error prone and the second is prohibitively manual for a situation where we hit the easy path 80% of the time.
[^1]: Especially since the set of available tooling is constrained by what most developers have on their local machine.

This proposal merged into ci-mgmt as https://github.com/pulumi/ci-mgmt/pull/401.


Async demo has undefined behavior

In the asynchronous REQREP demo, an exception is thrown in the callback [1]. However, the callback takes a direct function pointer [2] and nng may or may not have been built with -fexception (or equivalent) [3]. There is a function-try-block which looks like it will catch errors in the callback but the thread running the callback originates inside of the nng threadpool - which is in C.
One way to solve this could be to not directly provide nng with the user-provided callback. Instead, have the aio constructor take an std::function and provide that to an argument to a "trampoline" function which catches any and all exceptions from the user-provided function. This trampoline is what you would then provide to nng as the AIO callback.

You are correct. We shouldn't be emitting exceptions from nng callbacks.
Your suggestion is a safe way to ensure this never happens.

Found the same problem. May I ask, has there been update on this?
@neachdainn what was your solution?
Do you know how nng reacts on errors in this situation? Lets say there's an error sending inside the callback (in my case that would happen additionally asynchronously) should we try managing the failed message ourselves or does nng do the management in some way?

This really isn't an nng thing - it comes down to the behavior of the compiler. The nng library operates within the C specification - meaning it doesn't address C++ exceptions at all. I think most modern compilers do something sane (I think), but the real solution is to catch exceptions at the FFI boundary.
In my own code, I catch exceptions at the FFI boundary (i.e., the callback). In my older code, I would occasionally check a flag in my own threads to see if an exception occurred. In my newer code, I just abort the program if I catch an exception - not ideal but better than undefined behavior. If someone comes up with a better solution, I would love to hear it.

One thing that might mostly work is to have aio_view::wait check a global / aio / context / socket specific variable and re-raise the exception if present. That should work if you can require that each asynchronous operation eventually is waited on, though that probably ends up being a project-specific policy rather than something a library can enforce.

@neachdainn Thanks much for coming back. I've added a thread-safe context to our worker class which allows me to inform the server coordinator in case of an error inside the callback. The problem is only... what then? As you said, we can't allow undefined behavior. But are there cases where we can save the running process? And when will we get errors in the first place? Does nng e.g. retry sending failed messages before it emits the error? Anyway, that's questions for Garrett/nng

Apologies if these responses are too delayed to be of any use.
I believe that if NNG reports an error, it will not attempt to do anything else with the message. That's the logical expectation given that the user owns the message upon error. That being said, some protocols are more "reluctant" to return an error than others; some have built-in retry (e.g., REP) and others will just drop messages (e.g., PUB).
If you're the one consuming the code, then the correct answer is probably pretty specific to your application. If you're writing a library, I don't know if there's a perfect answer. In my wrapper, I document that the user needs to either come up with their own scheme for handling errors or just not emit errors (though I could see plenty of argument for silently eating the errors instead of killing the program).

Apologies if these responses are too delayed to be of any use.
I believe that if NNG reports an error, it will not attempt to do anything else with the message. That's the logical expectation given that the user owns the message upon error. That being said, some protocols are more "reluctant" to return an error than others; some have built-in retry (e.g., REP) and others will just drop messages (e.g., PUB).
If you're the one consuming the code, then the correct answer is probably pretty specific to your application. If you're writing a library, I don't know if there's a perfect answer. In my wrapper, I document that the user needs to either come up with their own scheme for handling errors or just not emit errors (though I could see plenty of argument for silently eating the errors instead of killing the program).


Send help response to all user messages that don't find a match

Description
Firstly, huge fan of Bolt! 🎉 Loving it so far!
My issue is I want to be able to write a catch all response, so that if the user submits a message not covered by the bot API - it sends a helpful message, rather than doing nothing.
Other bots usually have a setting like options.onlyFirstMatch - so that you can write matches like I have below:
app.message(':wave:', async ({ message, say }) => {
  await say(`Hello, friend!`);
});

app.message(new RegExp('.+'), async ({ message, say }) => {
  await say(
    "I'm sorry, I don't understand!"
  );
});

// Expected Slack responses:

>> :wave:
> Hello, friend!

>> Where is Wakanda?
> I'm sorry, I don't understand!

I guess my question is: how would you write a catch all response for all the messages you haven't programmed a response for with Bolt? Is that possible? Am I missing something in the docs where it explains how to do this?
Apologies if this is documented. I have searched and read through the docs, as I'd imagine this is quite a common use case, but can't find anything - if this is a well known feature, I'd love to add to the docs to make it more explicit.
What type of issue is this?

[ ] bug
[ ] enhancement (feature request)
[x] question
[ ] documentation related
[ ] testing related
[ ] discussion

Requirements

[x] I've read and understood the Contributing guidelines and have done my best effort to follow them.
[x] I've read and agree to the Code of Conduct.
[x] I've searched for any related issues and avoided creating a duplicate issue.

Hi @alexjackhughes! So great to hear that you're loving Bolt so far. 😄
Thanks for bringing this question to us -- you didn't miss anything in the documentation! At this time, there is no built-in "catch-all" response functionality, but your question has resulted in a conversation about how we might support this going forward in the next major version.
I'm providing a workaround below that came from this discussion that might work for your use case in the meantime. Below is an except listener middleware which can be used to filter out messages that are handled by other listeners. messagePatterns needs to contain all patterns that are otherwise handled.
function except(excludePatterns) {
  return async ({ message, next }) => {
    for (const excludePattern of excludePatterns) {
      if (message.text === undefined) {
        return;
      }
      if (typeof excludePattern === 'string'
        && message.text.includes(excludePattern)) {
        return;
      } else if (message.text.match(excludePattern) !== null) {
        return;
      }
    }
    await next();
  };
}

const messagePatterns = [];
const wave = ':wave:';
messagePatterns.push(wave);

app.message(wave, async ({ message, say }) => {
  await say(`Hello, friend!`);
});

app.message(except(messagePatterns), async ({ message, say }) => {
  await say("I'm sorry, I don't understand!");
});

Let us know if this works for you and if so, feel free to close this issue!

Hey Alissa! Thanks for the quick response!
Yep, that worked perfectly - thanks for the snippet 😊 Excited to see how this could be supported natively in the future, but agree this is a good middle ground for now.


New Admob Support!?

Hi,
I've already implemented this plugin to my unity and it works well. However, I'm just wondering whether this plugin supports the new Admob or not!? Since after August 31, Google will stop the old Admob, just only the new one.
Thanks!

This issue is being closed due to its age. For bugs in the plugin open a new issue or reach out on our support group at https://groups.google.com/forum/#!forum/google-admob-ads-sdk.
Ram


init: fix build error when trace is enabled

[Detail]
Fix the linking error: "undefined reference to TRACE_INIT" when trace is
enabled.
[Verified Cases]
Build Pass: <py_engine_demo>
Test Pass:  <py_engine_demo>

感谢提交 Pull Requests！
Thanks for submitting a pull request.

Security Check : 6b0fdc967be75f7fdd319adc5399b31e724dd5dc

auto build success,number:78

autotest success,number:1149


improve demo view for amp-bind sample

@kul3r4 PTAL - what do you. think about this approach?

I agree, it doesn't look nice at the moment. LGTM


Set/GetBackgroundValue missing on SignedMaurerDistanceMapImageFilter

It seems the Set/GetBackgroundValue API is missing on SignedMaurerDistanceMapImageFilter:
ITK docs:
https://itk.org/Doxygen/html/classitk_1_1SignedMaurerDistanceMapImageFilter.html
SimpleITK docs:
https://itk.org/SimpleITKDoxygen/html/classitk_1_1simple_1_1SignedMaurerDistanceMapImageFilter.html

Thanks!


Failed to obtain access token

When i access to /api/login an then it redirects me to /api/auth says Internal Server Error an the console:
InternalOAuthError: Failed to obtain access token
    at Strategy.OAuth2Strategy._createOAuthError (/srv/node_modules/passport-oauth2/lib/strategy.js:408:17)
    at /srv/node_modules/passport-oauth2/lib/strategy.js:175:45
    at /srv/node_modules/oauth/lib/oauth2.js:191:18
    at ClientRequest.<anonymous> (/srv/node_modules/oauth/lib/oauth2.js:162:5)
    at emitOne (events.js:116:13)
    at ClientRequest.emit (events.js:211:7)
    at TLSSocket.socketErrorListener (_http_client.js:401:9)
    at emitOne (events.js:116:13)
    at TLSSocket.emit (events.js:211:7)
    at emitErrorNT (internal/streams/destroy.js:66:8)

Any ideas?

I'm getting the same error, any update on this getting fixed?

I've updated all dependencies in the package.json and it has not resolved the issue, there's alterations to the code that will need to be made.

Go into your Discord Developer Portal app settings and make sure the Redirect URI only points to the /api route, for example:
https://us-central1-<project-id>.cloudfunctions.net/api <-- Notice there is no /auth at the end as the read me previously stated.
I have updated the read me to prevent users from running into this error. If you still have issues after updating your Redirect URI please open another issue.
Sorry it took so long to respond, it is now working and tested with a live demo available.
Happy coding!

Go into your Discord Developer Portal app settings and make sure the Redirect URI only points to the /api route, for example:
https://us-central1-<project-id>.cloudfunctions.net/api <-- Notice there is no /auth at the end as the read me previously stated.
I have updated the read me to prevent users from running into this error. If you still have issues after updating your Redirect URI please open another issue.
Sorry it took so long to respond, it is now working and tested with a live demo available.
Happy coding!


Location display auto pan mode change handler performing UI change on background thread

Runtime error encountered in MapViewController+LocationDisplay.swift L27.

UIButton.setImage(_:for:) must be used from main thread only

Potential solution is to dispatch UI operation to main queue.

Fixed in https://github.com/Esri/maps-app-ios/releases/tag/1.0.1


[routing-manager] generate random nat64 prefix and add it to netdata

This commit generates a random NAT64 prefix (defaults to the well-known prefix) and adds the prefix to NetworkData if none exits. The prefix will be saved in Settings for recovery.
It also adds a new CLI command "br nat64prefix" to show the local nat64 prefix.
A new config OPENTHREAD_CONFIG_BORDER_ROUTING_NAT64_ENABLE is defined and used to guard the change.
This initial implementation only supports a single BR.

@xuyirio a few TODO items:

Add feature flag for CMake and other build systems;
Add tests in here https://github.com/openthread/openthread/blob/main/tests/scripts/thread-cert/border_router

@xuyirio a few TODO items:

Add feature flag for CMake and other build systems;
Add tests in here https://github.com/openthread/openthread/blob/main/tests/scripts/thread-cert/border_router

+1 for adding tests.
I guess this PR alone can be tested with a virtual time simulation.

I guess this PR alone can be tested with a virtual time simulation.

If we foresee incoming enhancements which requires validations from real time simulations, probably better to add the tests in border_router directly.

@xuyirio Congrats on your first PR to OpenThread!!! :+1:


Create uniform SentenceParser interface

I.e. with the new parser classes there should ideally be some base class that defines the interface?

Yeah -- other than the parse method, do we need any other functionality exposed that isn't parser specific? Multiprocessing? Maybe turn on whitespace tokenization?
class Parser(object):
  def parse(self, doc, doc_id=None, doc_name=None):
     raise NotImplementedError

Unfortunately my current branch has diverged a bit... but I am using a parse_docs method too, which takes in a list of Document objects.  This is instead of having the DocParser call a SentenceParser internally, for a bit cleaner separation
Other than that, yeah I guess some way to pass in configs?  @thodrek @netj any other thoughts on generic interfaces to the parser?

That seems reasonable. I've been doing something similar, using a Corpus object with a DocParser object to generate Documents and applying a Parser and TextTransform in the corpus object.  The TextTransform is useful for hacking in various things (e.g., removing special anonymizing tokens in MIMIC-III text data), so maybe that should be a separate addition.


Markdown comments is displayed to HTML

Thank you for awsome product!!
I'm writing an article via Zenn for the first time.
I write markdown file like this.
# title

this is article.

Then, I ran npx zenn preview. (I'm using<EMAIL_ADDRESS>Zenn display

 to HTML.
Does't Zenn support comment block?

Currently Zenn does not support html comment on markdown.
But will think about it.

Thanks!!

@catnose99
If enable html option, Is there any problem?
// enable everything
var md = require('markdown-it')({
  html: true,
  linkify: true,
  typographer: true
});

https://github.com/markdown-it/markdown-it#init-with-presets-and-options

I guess it might cause XSS.
It's better to use the plugin like this or develop from scratch...
https://github.com/jay-hodgson/markdown-it-inline-comments

@toshi-toma
Now you can use inline comment !
If you're using zenn-cli, please run npm run install zenn-cli@latest.

@catnose99
Awesome!!
Thank you for fix the issue!!


Gui tcl eval file fix

It does not look like error handling in the OpenSTA source implementation is always better than tclsh. tclsh has stack traces. IMO, simpler errors are easier to read with the OpenSTA syntax, but harder errors are harder to track down.
$ openroad -exit foo.tcl
OpenROAD v2.0-14708-g0e7dcb1f9
Features included (+) or not (-): +Charts +GPU +GUI +Python
This program is licensed under the BSD-3 license. See the LICENSE file for details.
Components of this program may be licensed under more restrictive licenses which must be honored.
Script running:
Error: blah.tcl, 3 invalid command name "asdf"
$ tclsh foo.tcl
Script running: blah.tcl
invalid command name "asdf"
    while executing
"asdf"
    (file "blah.tcl" line 3)
    invoked from within
"source blah.tcl"
    (file "foo.tcl" line 1)
$ cat foo.tcl
source blah.tcl

$ cat blah.tcl
puts "Script running: [info script]"

asdf

@oharboe I was wrong I think it is the echo and verbose flags that get added plus the std redirection that is added by opensta

@gadfort Thanks for all the information :-)
I think at this point, it is useful to just gather some more info in these pull requests so leaving open for review in that regard.
Not sure where this is all going to lead after the information has come all in though...

More spelunking and contemplation needed...


added steps to support bootstrapping by loading filepath to CA

@thomastaylor312 hello there,
tried to fix #642
please let me know if Im on the right track or totally off ☹

This is looking good! Just the small fix around base64 encoding


Gated mandatory sub rule?

Is it possible to declare a sub rule that is mandatory if a gated condition is met but otherwise skipped?
Using a gate with OPTION does not enforce that the option must be conformed with if the gate returns true, so this is not what I want.
The only way I've found to do this is with OR like this:
          this.OR({
            DEF: [
              {
                GATE: () => arg === "projection",
                ALT: () => this.SUBRULE(this.frameIdClause)
              },
              {
                GATE: () => arg !== "projection",
                ALT: () => {
                  // not expecting any token
                }
              }
            ], ERR_MSG: arg === "projection" ? "'ID'" : "'VALUE'"
          })

But this seems a bit clunky, is there a less verbose way of doing this?

The way you described above is probably the best.
A GATE only adds a condition to the grammar part, but it cannot define anything as mandatory.
GATEs can normally be replaced with some grammar duplication.
However that would probably more verbose...

Closing,
Re-open if there are any other questions on this topic.


[5.10] PredictableMemOpt: fix wrong handling of re-borrows of a load_borrow

Explanation:  When promoting a load_borrow, the PredictableMemOpt pass doesn't consider re-borrows. This can lead an ownership verifier error or a mis-compile resulting in leaked values.

Issue: rdar://118402432

Risk: Low. It's a trivial change which makes the optimization more conservative.

Reviewer: @atrick

Main branch PR: https://github.com/apple/swift/pull/69886

@swift-ci test


Added new video

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Hi @dabit3 –– Please wrap your frontmatter descriptions with double quotes (as you're already using single quotes within the description bodies, which confuses the parser). Upon doing this, the content validation check should pass just fine 👍

@harrysolovay thanks for the heads up!


🐛 Bug Report: catalog-unprocessed-entities plugin: Filter and column sorting doesn't work

📜 Description
After installing the catalog-unprocessed-entities plugin and the catalog-backend-module-unprocessed plugin and then navigating to the catalog-unprocessed-entities page, the filter and column sorting doesn't work.
When I try to enter any letters into the filter, I get no results in the unprocessed entities list even though there are items that match those letters.
Column sorting also doesn't work. If I select the arrow next to ENTITYREF, KIND, OWNER, or RAW labels, the order of items doesn't change.
👍 Expected behavior
When I type letters into the Filter search bar, I should see results show up that match those letters.
When I click the arrow next to the head of a column, that should sort the column's items.
👎 Actual Behavior with Screenshots
When I type letters into the Filter search bar, no items show up. The results are completely empty even though there are items that match the letters.
When I click the arrow next to the head of a column, the list of items stays the same and doesn't get sorted.
👟 Reproduction steps

Install and configure the catalog-backend-module-unprocessed plugin
Install and configure the catalog-unprocessed-entities plugin
Start your application locally
Navigate to /catalog-unprocessed-entities
You will need a list of unprocessed entities already showing up under the Failed tab in order to test the filter
Type any letter into the Filter search bar to see the filter issue
Click the arrow next to the ENTITYREF, KIND, OWNER, or RAW labels to see the column sorting issue

📃 Provide the context for the Bug.
No response
🖥 Your Environment
node: v16.14.2
yarn: 1.22.19
backstage:  1.15.0
Dependencies:
@backstage/plugin-catalog-backend-module-unprocessed  0.1.0
@backstage/plugin-catalog-unprocessed-entities: 0.1.0
👀 Have you spent some time to check if this bug has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
None

@gracemkas sounds like we should fix this - is this something you want to contribute and help? :pray:

Also ping @alde

Hey there :slightly_smiling_face:
We are facing the same issue and unfortunately, we don't have time to take this right now. Would it be okay to disable search until somebody has time to look at this bug? If yes, I would open a PR.


Preview Not Working?

Hi,
Preview not working? Why is that?
Thanks.
$("textarea[data-provide=markdown]").markdown({language:'tr'});

did you include a markdown parser lib? See note at the bottom of the page http://www.codingdrama.com/bootstrap-markdown/

NOTE
Altought the primary purpose of this plugin is to provide Markdown editor, the design is allowing the plugin to be used as a general purpose editor.
The preview functionalities and html to markdown conversion are provided by 3rd party codes : markdown-js, marked (default failover if markdown-js lib not available) and to-markdown. Without them, this plugin would still work and convert the content as-is, so you could easily modify those functionalities yourself via available hooks.

I have the same problem: It is working with markdown.js but not with marked.js .

This should be on the front page. I had to dig to find this.

I agree it should be mentioned.  Been digging for 30 minutes as to why the preview button wasn't working.

+1, The NOTE should be put on the head of the page 😢


Fix exampleCode to be UUIDv4

just make the sample code a uuidv4

very important

Hi @m4tonoob ! Ty for your PR I really appreciate it.
FYI, currently example code is following this pattern:
a  b  c  d  e  f   g  h  i  j  k  l  m  n  o  p
  0  1  2  3  4  5  6  7  8  9  0  1   2  3  4  5

That's why currently value is: a0b1c2d3e4f5g6h7i8j9k0l1m2n3o4p5, but I can change this to be UUIDv4.

Yeah I saw the pattern, but a uuis is more accurate lol I'm in the mood
today
On Sun, Sep 8, 2024 at 23:11 Leo López @.***> wrote:

Hi @m4tonoob https://github.com/m4tonoob ! Ty for your PR I really
appreciate it.
FYI, currently example code is following this pattern:
a  b  c  d  e  f   g  h  i  j  k  l  m  n  o  p
0  1  2  3  4  5  6  7  8  9  0  1   2  3  4  5
That's why currently value is: a0b1c2d3e4f5g6h7i8j9k0l1m2n3o4p5, but I can
change this to be UUIDv4.
—
Reply to this email directly, view it on GitHub
https://github.com/Ciensprog/Aerial-Launcher/pull/17#issuecomment-2336825341,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANBU37MMV4FZQROTNWGULJLZVS4ONAVCNFSM6AAAAABN3I5ZPWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZWHAZDKMZUGE
.
You are receiving this because you were mentioned.Message ID:
@.***>

Ohhh no problem, thanks 🍻!


creation of labels not complete

hello
This is the error i get when i run the step 02.
forced-alignment using HTK tools... ---preparing enverionment ---checking data ---extracting features Sun Nov 18 17:20:52 2018 ---feature_normalisation Sun Nov 18 17:20:56 2018 ---making proto Sun Nov 18 17:20:56 2018 ---training HMM models Traceback (most recent call last):   File "/home/ubuntu/merlin/misc/scripts/alignment/state_align/forced_alignment.py", line 381, in <module>     aligner.train_hmm(7, 32)   File "/home/ubuntu/merlin/misc/scripts/alignment/state_align/forced_alignment.py", line 285, in train_hmm     stdout=PIPE)   File "/usr/lib/python2.7/subprocess.py", line 541, in check_call     raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['/home/ubuntu/merlin/tools/bin/htk/HERest', '-C', '/home/ubuntu/merlin/egs/build_your_own_voice/s1/labels/config/cfg', '-S', '/home/ubuntu/merlin/egs/build_your_own_voice/s1/labels/config/train.scp', '-I', '/home/ubuntu/merlin/egs/build_your_own_voice/s1/labels/config/mono_phone.mlf', '-M', '/home/ubuntu/merlin/egs/build_your_own_voice/s1/labels/model/hmm_mix_1_iter_1', '-H', '/home/ubuntu/merlin/egs/build_your_own_voice/s1/labels/model/hmm0/macros', '-H', '/home/ubuntu/merlin/egs/build_your_own_voice/s1/labels/model/hmm0/hmmdefs', '-t', '250.0', '150.0', '2000.0', '/home/ubuntu/merlin/egs/build_your_own_voice/s1/labels/mono_phone.list']' returned non-zero exit status -11 ls: cannot access 'labels/label_state_align': No such file or directory Force-alignment unsucessful!! Please check /home/ubuntu/merlin/misc/scripts/alignment/state_align/forced_alignment.py Copying labels to duration and acoustic data directories... cp: cannot stat 'labels/label_state_align': No such file or directory cp: cannot stat 'labels/label_state_align': No such file or directory ls: cannot access 'labels/label_state_align': No such file or directory ls: cannot access 'labels/label_state_align': No such file or directory done...!
Can any one help me to overcome this issue

Hi,
the forced alignmetn procedure has failed (line 285 in /home/ubuntu/merlin/misc/scripts/alignment/state_align/forced_alignment.py)
I suggest you run the forced alignment procedure separately to debug the issue.

Rasmus


Documents for sequence labeling are not in correct order

Thank you for this great tool!
I seem to have run across a bug with the sequence labeling. It does not show documents in the correct order (matching the order in the database). I have Randomize Document Order set to False. I have even seen it show duplicate documents while omitting others.
I used the deploy to azure button in the readme and made no other modifications.
Has anyone seen this before?

Please raise a new issue if you still face this phenomenon.


Merged TTigress TSiLi TS3 changes + fixes + additions

Fixed tigress addback
Added SiLi positions
Made  S3 more generic
Added Mohamads waveform fit for SiLi
Added start of addback to SiLi
Added blur option to Tigress, S3 and SiLi positions
Changed  Tigress get functions back to pointers
Made makefile not require git

In the addback multiplicity function, the first tigress hit still needs to
be summed against itself in order to have the LastPostion function return
correctly. Same for when we don't find an a match the first time through.
I am confused why these where removed?  (lines 128 and 144 in the
TTigress.cxx change above)
On Fri, Oct 28, 2016 at 8:57 AM, Ryan Dunlop<EMAIL_ADDRESS>wrote:

Merged #810 https://github.com/GRIFFINCollaboration/GRSISort/pull/810.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/pull/810#event-840005260,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAacI-ajzsAyxrUWthd1lo1Xrytx48rYks5q4fEygaJpZM4Ki_gA
.

This was resulting in the hit having twice it's actual energy. That's why it was removed.

Well I out those lines back in. I’ll let you guys who have access to Tigress data figure this one out.

That is just a bug, we can fix that...
On Fri, Oct 28, 2016 at 10:08 AM, Ryan Dunlop<EMAIL_ADDRESS>wrote:

Well I out those lines back in. I’ll let you guys who have access to
Tigress data figure this one out.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/pull/810#issuecomment-256929590,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAacI9ui5GYeHUJ10wTZNLiLIBbR1g5_ks5q4gH7gaJpZM4Ki_gA
.

I agree, there should be a way to have it do a check first before screaming/failing.


[18.09] backport fwup updates

Motivation for this change
Bugfix releases: https://github.com/fhunleth/fwup/releases/tag/v1.2.6 https://github.com/fhunleth/fwup/releases/tag/v1.2.7
Original PRs: #50132 #52326
Building currently fails.
Things done

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

[ ] NixOS
[ ] 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 nox --run "nox-review wip"
[ ] 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)
[ ] Assured whether relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build fwup

Closing this as it has been a while and 19.03 is round the corner anyway.


Fix misspelling of environment variable

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

@bors: r+

@bors: r+

:pushpin: Commit 7bec315e8ba1d2962d580cf0f18766b96c863a3a has been approved by alexcrichton

:pushpin: Commit 7bec315e8ba1d2962d580cf0f18766b96c863a3a has been approved by alexcrichton

:hourglass: Testing commit 7bec315e8ba1d2962d580cf0f18766b96c863a3a with merge 89801a3d6307fa96c50cf052657eba0325b26a93...

:hourglass: Testing commit 7bec315e8ba1d2962d580cf0f18766b96c863a3a with merge 89801a3d6307fa96c50cf052657eba0325b26a93...

:broken_heart: Test failed - checks-actions

:broken_heart: Test failed - checks-actions

The man pages need to be rebuilt.  Go to the src/doc directory and run the ./build-man.sh script (documented here).

The man pages need to be rebuilt.  Go to the src/doc directory and run the ./build-man.sh script (documented here).

@ehuss Thank you for your guidance.
@rustbot modify labels: -S-waiting-on-author

@ehuss Thank you for your guidance.
@rustbot modify labels: -S-waiting-on-author

Thanks!
@bors r+

Thanks!
@bors r+

Thanks!
@bors r+

Thanks!
@bors r+

:pushpin: Commit 159e88a69d96b356f050d66d9943f02c34b9b74e has been approved by ehuss

:pushpin: Commit 159e88a69d96b356f050d66d9943f02c34b9b74e has been approved by ehuss

:pushpin: Commit 159e88a69d96b356f050d66d9943f02c34b9b74e has been approved by ehuss

:pushpin: Commit 159e88a69d96b356f050d66d9943f02c34b9b74e has been approved by ehuss

:hourglass: Testing commit 159e88a69d96b356f050d66d9943f02c34b9b74e with merge 7f41cf6f787a0bbca441b638be3a45f062045a3c...

:hourglass: Testing commit 159e88a69d96b356f050d66d9943f02c34b9b74e with merge 7f41cf6f787a0bbca441b638be3a45f062045a3c...

:sunny: Test successful - checks-actions
Approved by: ehuss
Pushing 7f41cf6f787a0bbca441b638be3a45f062045a3c to master...

:sunny: Test successful - checks-actions
Approved by: ehuss
Pushing 7f41cf6f787a0bbca441b638be3a45f062045a3c to master...


Request for VIGOR dataset

Hello Authors:
Good evening, thank you for taking the time out of your busy schedule to read my comment..
I have filled the data-set request form & would like to have a link to the data-set for research .
Thanks and Best wishes.
Zhou zi yang

We do NOT accept personal email. Please read the questionnaire carefully before you submit it.


Release version 0.3.0

@mcfadden8 - our coverage has dropped significantly over this past few months. I'll log an issue and look at fixing this.


Enable metric export for Acknowledgement Queue

Describe the Improvement
Expose useful metrics when AcknowledgementQueue is being used. The first useful metric would be a gauge on queue size.
Rationale
When Atleon is in charge of maintaining in-order acknowledgement of messages from an append-only log (like Kafka), users may find it useful to know metrics about that queue.
Implementation Ideas
In order to match existing conventions, should consider some form of a listener that can passed to AloQueueingSubscriber through OrderManagingAcknowledgementOperator

Implemented and documented


[Obsolete] 'congenital absence/hypoplasia of fingers excluding thumb, bilateral'

Mondo term (ID and Label)
MONDO:0017508 'congenital absence/hypoplasia of fingers excluding thumb, bilateral'
Reason for deprecation
obsolete in Orphanet
Suggested term to consider
none

sorry @twhetzel, I just took care of this on another PR.


[TableRow] Adjust CSS for components other than

TableRow has component prop similar to ListItem. This allows us to use components such as a tag and react-router's Link, as can be seen in ListItem's simple list example. But the same does not work as expected in case of TableRow. Check the images below for clarity. Here the TableRow with Oreo has component="a".
Before

After

The fix is quite simple, however, please feel free to point out if I missed anything.
Hope this will get merged, as it will be very useful to our team! :smile:

@chaitan94 Looks great! We have been doing similar fixes for other components where the default html element comes with some specific user-agent styles.

Oops, I have missed this warning from React. It's broken in production:

main.js:98 Warning: validateDOMNesting(...):  cannot appear as a child of . See BasicTable > withStyles(TableBody) > TableBody > tbody > withStyles(TableRow) > TableRow > a.

I'm gonna change the demo.


Want to improve the login and sign up page of the website

##Description
Want to improve the login and sign up page of the website
##Screenshot

@AtriSukul1508 I want to fix this issue kindly Assign it to me :)


fs: support openat/fchmodat/mkfifoat/fstatat/...at api

Summary
fs: support openat/fchmodat/mkfifoat/fstatat/...at api
Refs to:
https://linux.die.net/man/2/openat
Impact
support file api with relative directory path spicified dirfd
Testing
local test

@yamt openat api is ready for review.


proposal: x/crypto/ssh: expose negotiated algorithms

Folks running production servers are under opposing pressures, to both

stop supporting obsolete or vulnerable algorithms and/or key sizes.
keep serving customers and migrate them away from obsolete algorithms

they can only make informed decisions on what to do (reach out to customers, switch off algorithms etc.) if they have data which algorithms are actually in use.
For the TLS library,  I think this can be achieved by inspecting https://pkg.go.dev/crypto/tls#ConnectionState.
The SSH library doesn't expose this information, more in particular:

Cipher, MAC, Compression in read/write directions
host key algorithm
key exchange algorithm.

this information is captured in type algorithms
https://cs.opensource.google/go/x/crypto/+/master:ssh/common.go;l=185;drc=6fad3dfc18918c2ac9c112e46b32473bd2e5e2f9
the proposal is to export type algorithms, and add
func Algorithms() Algorithms
to the ssh.Conn type.
This is technically an incompatible API  change. However, the ssh.Conn (as well as ssh.Channel) are misdesigned, and should have been structs instead. They are not meant to be implemented by other package, so I think it's OK to add this method to the interface.

CC @golang/security

The compatible way to do this would be to define
type AlgorithmsConn interface {
    Conn
    Algorithms() Algorithms
}

Talked to @FiloSottile. In general we are supportive of expanding things here. The algorithms struct right now has lots of other unexported fields. It is unclear to us what exactly the public API for Algorithms would be.

my proposal is
type DirectionAlgorithms struct {
	Cipher      string
	MAC         string
	Compression string
}
type Algorithms struct {
	Kex     string
	HostKey string
	W       DirectionAlgorithms
	R       DirectionAlgorithms
}

Regarding
type AlgorithmsConn interface {
    Conn
    Algorithms() Algorithms
}

This is backward compatible, but runs the risk that we'd create a new interface for every bit of info we'd want to add down the line.
Maybe we could do  func AlgorithmsOf(c Conn) *Algorithms instead?

What do W and R stand for and are those the right names?

Oh, sure. How about:
type Algorithms struct {
	Kex     string
	HostKey string
	Write       DirectionAlgorithms
	Read       DirectionAlgorithms
}

We could also do
type Algorithms struct {
	Kex     string
	HostKey string
	ClientToServer       DirectionAlgorithms
	ServerToClient       DirectionAlgorithms
}

which is probably a bit more self-explanatory for callers, but it means slightly more complexity on the implementation side.
Also, I think callers will typically only be implementing either the client or the server, so Read and Write are sufficiently unambiguous.

 I'd probably vote for something like func AlgorithmsFor(Conn) Algorithms instead.
In terms of the shape of Algorithms I think just exporting all of the currently private fields seems fine. I don't think the ClientToServer/ServerToClient names are particularly clearer. I think it'd probably be simpler to just expand w and r to Write and Read, which paired with the Direction part of DirectionAlgorithms I think makes it clear what they represent.

Re AlgorithmsConn vs AlgorithmsFor(Conn), we've established the AlgorithmsConn "extension interface" pattern in other contexts already, specifically the fs.FS interface and its extension interfaces, so I think that's probably okay. So it sounds like
type Algorithms struct {
	Kex     string
	HostKey string
	Read       DirectionAlgorithms
	Write       DirectionAlgorithms
}

type AlgorithmsConn interface {
	Conn
	Algorithms() Algorithms
}

type DirectionAlgorithms struct {
	Cipher      string
	MAC         string
	Compression string
}

Do I have that right?

Yup, sounds right.

This seems like a case where ssh.Conn should have been a concrete type to permit future expansion.
Perhaps we should add a concrete type, and say that the Conns returned by ssh package constructors can always be type asserted to *ssh.SSHConn? That would avoid the need to add a new interface every time we think of something that should be exposed.

This seems like a case where ssh.Conn should have been a concrete type to permit future expansion.

yes, I was a young and innocent Go developer :-)

Perhaps we should add a concrete type, and say that the Conns returned by ssh package constructors can always be type asserted to *ssh.SSHConn? That would avoid the need to add a new interface every time we think of something that should be exposed.

I like that idea better than the extended interfaces, but it will be a bit of work to add the type. Maybe ssh.Connection (to avoid the stutter.)

If we use https://github.com/golang/go/issues/58523#issuecomment-1601153926, have all concerns been addressed?

I wanted to do something like https://go-review.git.corp.google.com/c/crypto/+/507779
then we can add the algorithms as a normal method on Connection

Having both Conn and Connection doesn't sound right, even as a way to deal with legacy questions.

Having both Conn and Connection doesn't sound right, even as a way to deal with legacy questions.

aside from naming, are saying it is better that we should add a new interface for every method we add?

/cc @drakkan and @FiloSottile for thoughts

Are there a bunch more methods that will need to be added?

When I implemented this, I noted,
        // TODO(hanwen): consider exposing:
        //   RequestKeyChange
        //   Disconnect

Disconnect isn't very useful (just closing the network connection works just as well). RequestKeyChange shouldn't be necessary for end-users, as we schedule a key change according to predefined limits
number of packets that can send under the negotiated algorithms. We could probably also implement by implementing a SendRequest message that is interpreted locally. That works but may be a bit hacky.
I'm more worried by things like https://github.com/golang/go/issues/61447. There is a logging hook in the server

The type should be type NegotiatedAlgorithms struct... to distinguish from algorithms supported by the package.
Does it make sense to treat all the discussions on algorithms together, that is:

https://github.com/golang/go/issues/58523 (this one)
https://github.com/golang/go/issues/61537
https://github.com/golang/go/issues/61536

The use case here is getting negotiated algorithms after successful authentication, and do something if a particular client is using an old/deprecated algorithm.
I think it doesn't makes much difference whether they are part of ssh.ConnMetadata or ssh.Conn as long as the application can get them.
Something interesting we could consider, since we are discussing about this part, is exposing an API to allow algorithms based on client/server version.
Take a look here for example.
It seems that when we call findAgreedAlgorithms we already have both the client and server version.
I think this is a fairly niche use case, but if you think it's interesting I can try to do a more in-depth analysis and open a new related proposal.

Is this one the final proposal?
type NegotiatedAlgorithms struct {
	Kex     string
	HostKey string
	Read    DirectionAlgorithms
	Write   DirectionAlgorithms
}

type NegotiatedAlgorithmsConn interface {
	Conn
	Algorithms() NegotiatedAlgorithms
}

type DirectionAlgorithms struct {
	Cipher      string
	MAC         string
	Compression string
}

The use case here is getting negotiated algorithms after successful authentication, and do something if a particular client is using an old/deprecated algorithm.

if the algorithm choice is available at auth time, I am sure eventually someone will want to have it there. There's even an  obvious use-case: you could show a "You are using a deprecated algortihm XYZ" banner as part of auth flow.

@hanwen you are right, so we should do something liks this
type NegotiatedAlgorithms struct {
	Kex     string
	HostKey string
	Read    DirectionAlgorithms
	Write   DirectionAlgorithms
}

type AlgorithmsConnMetadata interface {
	ConnMetadata
	Algorithms() NegotiatedAlgorithms
}

type DirectionAlgorithms struct {
	Cipher      string
	MAC         string
	Compression string
}

do you agree?

@hanwen, what do you think of @drakkan's last message?

:+1:
(modulo nits: Kex vs KEX vs KeyExchange)

Have all remaining concerns about this proposal been addressed?
The proposal is to add
type NegotiatedAlgorithms struct {
	Kex     string // or maybe KEX
	HostKey string
	Read    DirectionAlgorithms
	Write   DirectionAlgorithms
}

type AlgorithmsConnMetadata interface {
	ConnMetadata
	Algorithms() NegotiatedAlgorithms
}

type DirectionAlgorithms struct {
	Cipher      string
	MAC         string
	Compression string
}

The canonical casing of Kex vs KEX should be decided, and it should match the decision in #61537.

can we use KeyExchange instead of Kex as discussed in #61537 ?

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group
The proposal is to add
type NegotiatedAlgorithms struct {
	KeyExhcange string
	HostKey string
	Read    DirectionAlgorithms
	Write   DirectionAlgorithms
}

type AlgorithmsConnMetadata interface {
	ConnMetadata
	Algorithms() NegotiatedAlgorithms
}

type DirectionAlgorithms struct {
	Cipher      string
	MAC         string
	Compression string
}

@rsc sorry for my late reply here. I think we should consider removing compression since we decided to remove it in #61537

Maybe we can also use HostKeyAlgorithm instead of HostKey. In #61537 we have HostKeyAlgorithms

Probably 61537 is wrong and we should drop Algorithms from the remaining struct fields in 61537. It is strange to have it in some fields but not others, and the overall struct is named Algorithms so having that word in the fields is redundant.

Probably 61537 is wrong and we should drop Algorithms from the remaining struct fields in 61537. It is strange to have it in some fields but not others, and the overall struct is named Algorithms so having that word in the fields is redundant.

We already have HostKeyAlgorithms in ClientConfig and PublicKeyAuthAlgorithms in ServerConfig, keeping the same name may avoid confusion even if Algorithm is redundant, anyway we can also improve docs to avoid any confusion

I still think we should drop Algorithms inside the Algorithms struct. It is defensible to have them in ClientConfig and ServerConfig since that is not ClientConfigAlgorithms and ServerConfigAlgorithms.

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group
The proposal is to add
type NegotiatedAlgorithms struct {
	KeyExchange string
	HostKey string
	Read    DirectionAlgorithms
	Write   DirectionAlgorithms
}

type AlgorithmsConnMetadata interface {
	ConnMetadata
	Algorithms() NegotiatedAlgorithms
}

type DirectionAlgorithms struct {
	Cipher      string
	MAC         string
}

Thanks for accepting this proposal!
I rebased and adapted the CL  that implements it. It depends on #61537 and approval of #54743 should also be discussed to avoid to have KEX algorithms supported only on the client side


add calendar for next events

Add a calendar of upcoming ticker events
Only dividends and earnings, if available
Yahoo does not provide splits or merges in this query

Good but need to be smarter with earningsDate. When Yahoo only knows the earnings week not day, it returns 2 dates: Monday, Friday. The old Ticker.calendar used to return two dates in a completely different format to single date - here is my old code:
cal = dat.calendar
if cal is None or cal.shape[1] == 0:
  cal = None
if cal is not None:
  if cal.shape[1] == 1:
    cal_release_dates = [cal["Value"]['Earnings Date']]
  else:
    cal_release_dates = [cal[i]["Earnings Date"] for i in range(cal.shape[1])]

Not saying you have to preserve API, just is hard to do worse. Do what you think good.

@ValueRaider Where can I see your old code? Because this property was marked as Not Implemented
And it's not replacment of data from calendar page

By old code, I mean code that used to access Ticker.calendar. Implementation is here (warning broken), and no this didn't fetch from calendar page either.

Ok. So we, have two dates (start and end of week for earning). May be I will return no Dataframe, but properties: next_dividend_date, past_dividend_date and next_earning_date. The last as string represintation of date or list of two date.

@ValueRaider
I not sure, that we should include earnings stat, because we have special property for it. In my opinion, calendar should return only events dates
from yfinance import Ticker
ticker = Ticker("AAPL")
print(ticker.ticker)
print(ticker.calendar)
print(ticker.calendar.attrs["earnings"])

ticker = Ticker("LLY")
print(ticker.ticker)
print(ticker.calendar.head())
print(ticker.calendar.attrs["earnings"])

output is:
AAPL
              Event                     Date
0     Dividend Date               2023-11-16
1  Ex-Dividend Date               2023-11-10
2     Earnings Date  2024-01-31 - 2024-02-05
                                   Value
Key
earningsDate     2024-01-31 - 2024-02-05
earningsAverage                     1.94
earningsLow                         1.88
earningsHigh                         2.0
revenueAverage<PHONE_NUMBER>00
revenueLow<PHONE_NUMBER>00
revenueHigh<PHONE_NUMBER>00
LLY
              Event        Date
0     Dividend Date  2024-03-08
1  Ex-Dividend Date  2024-02-14
2     Earnings Date  2024-02-06
                      Value
Key
earningsDate     2024-02-06
earningsAverage        2.78
earningsLow            2.64
earningsHigh           2.88
revenueAverage<PHONE_NUMBER>
revenueLow<PHONE_NUMBER>
revenueHigh<PHONE_NUMBER>

A flat dict might be best. What analysis is made harder by calendar dates not being a Pandas.Series?

@ValueRaider
AAPL
{'Dividend Date': datetime.date(2023, 11, 16),
 'Earnings Average': 1.94,
 'Earnings Date': [datetime.date(2024, 1, 31), datetime.date(2024, 2, 5)],
 'Earnings High': 2.0,
 'Earnings Low': 1.88,
 'Ex-Dividend Date': datetime.date(2023, 11, 10),
 'Revenue Average':<PHONE_NUMBER>00,
 'Revenue High':<PHONE_NUMBER>00,
 'Revenue Low':<PHONE_NUMBER>00}
LLY
{'Dividend Date': datetime.date(2024, 3, 8),
 'Earnings Average': 2.78,
 'Earnings Date': [datetime.date(2024, 2, 6)],
 'Earnings High': 2.88,
 'Earnings Low': 2.64,
 'Ex-Dividend Date': datetime.date(2024, 2, 14),
 'Revenue Average':<PHONE_NUMBER>,
 'Revenue High':<PHONE_NUMBER>,
 'Revenue Low':<PHONE_NUMBER>}

I cann't squash commits. So if everything is ok, i will recreate PR with one clean commit

Your mistake was merging in dev - better to rebase #1080. Go ahead with new PR.


Fix added combined error and extension

GraphQL error might have an optional field "extensions" which is a dictionary and might have additional data (like error code).
http://spec.graphql.org/draft/#sec-Errors.Error-result-format
Also now if there are GraphQL errors they won't be dropped in case of parsing issues
Example: Query asked for some non optional Entity, but requesting user was suspended/deleted, thus GraphQL will deliver something like this:
{
   "errors":[
      {
         "message":"The current user is not authorized to access this resource.",
         "locations":[
            {
               "line":2,
               "column":3
            }
         ],
         "path":[
            "userobjectType__1utyewuixim09"
         ],
         "extensions":{
            "code":"AUTH_NOT_AUTHENTICATED"
         }
      }
   ],
   "data":{}
}

As you can see data field is empty and as such can't be parsed, thus we should combine parsing error and the one about Auth

Hey 👋 ,
Thank you for opening this PR. I love the addition of extensions - good catch 👍 .
I am not entirely sure about combined errors. Do you maybe have any other idea of how we could throw an array of errors? I don't think we'll ever need a tree-like structure that's possible now. I have struggled with this and concluded that it makes sense to do it the way I've done it, but I know it's not ideal.
I didn't want a tree structure because it seems like a combined error could have a combined error inside, which isn't the case in practice. Additionally, the only case when the code goes haywire is when a top-level field (e.g. a query field) is non-null, your selection expects a non-null value, and the server returns a null data value.  Then, the parser complains only about parsing despite execution errors.
I approached this problem like I did because if you are confident that a top-level query will be non-null, the parser should complain since you are breaking the contract. If you make it nullable, on the other hand, it should return errors. I am not sure anymore if the code follows this, though...
Does that make sense?
I genuinely don't like the "indirect" idea - I've also thought of it, but I believe there's a cleaner solution to the problem. Do you maybe have some ideas?

Hi. indirection is actually not a big problem here as it's just more specialized version of any other error containing other error (like CombinedError.parsing or unknown).
If you really don't like it we can try to see how it goes by choosing other solution by simply ignoring parse error if there was any other errors (though it's still an array of errors, so dunno if it helps)

Another question:
In my graphql api, if return errors, data will be undefind,
SwiftGraphQLClient/Client/Selection.swift
 125           let data = try selection.decode(raw: self.data)

self.data is nill , will throw an error:

throw ObjectDecodingError.unexpectedObjectType(
                    expected: "Dictionary",
                    received: codable.value
                )

I don't agree with this method. ``self.data == nil should be skipped
Keep the errors from graphql api.

Yeah, you probably right, this was one of the ways to fix the issue, but I wasn't sure if that's ok. Will update code


Not an issue, just wanted to say thanks!

Thanks for adding this fantastic feature that was missing from VS Code!!
Have you thought of submitting a pull request for it?

Thanks man! Once you're hooked, you know.
I might look into that some day. Would be an interesting exercise.


feat(pymongo): Set MongoDB tags directly on span data

Another PR to iron out some inconsistencies between the Python and Node SDKs. OTel attaches MongoDB tags directly on the span data, rather than in the tags databag. This change is necessary so that Relay can parse MongoDB spans in Python for metrics extraction.
Node SDK Spans:
Relevant MongoDB data is set directly as span data

Python SDK Spans:
Relevant MongoDB data is set in the tags databag

@szokeasaurusrex That's a good point, but consistency is still more important so that we can extract metrics for multiple SDKs. I believe the Python SDK in the near future will be implementing OTel's SDK under the hood, just like the JS SDK, so this exact change will occur and break dashboards for users who rely on these tags anyways

@0Calories I think this change will still require a major version bump if it is breaking. I understand that consistency matters, but semantic versioning dictates a major version bump for any breaking change.
We are in progress with implementing POTel in Python and intend to release a major when we do so, so I guess we can include this change then.

I suppose the change could be made backwards-compatible by setting this data both as tags and as data on the span. The data would of course be redundant, and we would probably need to consider implications in terms of storage costs on the server, but then we could include this change in a minor without violating semantic versioning

That makes sense to me, I'll update this to include the data on both tags and data

Awesome thanks @szokeasaurusrex! Could you also please merge the PR for me? It seems I don't have permission to do so on my own

@0Calories the PR needs to be updated with the base branch before you can merge


List and search for possible values when inviting a team within an environment

Is your idea related to a problem? Please describe.
In the current version, when you want to invite a team in an environment, data.all only lists the teams you are part of (as a data.all user). If I want to invite a team that my user is not part of, I need to provide it's name (free text). This is error prone as users can make a typo when providing the name, which will lead to problems down the road when trying to assume the role.
Describe the solution you'd like
When inviting teams, users should be able to list all "data.all" teams (drop-down list). There should also be a "search feature" to find the correct team to invite based on it's name.

Implementation details
Backend:

Add a new Cognito handler in backend/aws/handlers with a list Groups method [https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/cognito-idp.html#CognitoIdentityProvider.Client.list_groups](boto3 call)
Add a new API of type Query in Groups object with its correspondent resolver that uses the Cognito handler

Frontend:

define a Groups object in src/api and add the definition of the API
modify the Environment view EnvironmentTeamInviteForm --> import the API + fetchGroups function with this API in useEffect + modify the textField to be a dropdown (Menu item) and map the values of fetchGroups with the values in this dropdown

@dlpzx we also though about giving the user more information about the users associated to a group for example which relates to this feature request. Aside the Cognito pool integration are you also considering querying the Azure AD?

Hi @degoldner, not yet. In the implementation we have created a new graphQL object called CognitoGroup. Right now it only includes the group name, but in the future it could also include other info such as "label" (for the case of non human readable names that come from azureAD) or even info about their creaton date...

Included in v1.2.0 release


When load the folder contains PHP file and edit it, the ediotr often appears unresponsive

The version is the lastest, PHP is 5.5.3。

duplicate of #160


Can table cells just contain an icon?

Is it possible to render icons inside column cells without having any other corresponding data that's coming from the source the table's pulling from for the other table values? I'm just trying to make a column of right-facing arrows at the end of each row. FWIW, this additional column is supposed to have a blank header.

Whoops, just realized I was in the wrong repository. Sorry!


File name casing on linux can break builds

OMG...
So...
Linux is case-sensitive for file names...
And we just happen to have two Directory.build.props files.
What's the problem?
Build has to have a capital B, or else they might not be included for the build.
An Ubuntu 24.04 VM I was testing on was having ridiculous dependency resolution and targeting issues that made zero sense...
Until I saw that lower-case b and renamed the files. Then it all worked perfectly.
The powershell modules also weren't loading properly on that VM, because just one of the files has Powershell in its name, rather than PowerShell, as specified in the manifest.
Anyway, here comes a no-code PR to rename 3 files to fix broken builds for case-sensitive environments (so likely quite a few linux distros or versions thereof and maybe MacOS as well).
And case-only changes on Windows are dumb, too, since it ignores case and you have to rename twice to do it. 😒

Also, a fun thing to note on Windows:
After merge, whenever you pull to sync your local copy, the file names won't change by default, either (though it doesn't matter on Windows unless you try to run a WSL environment on top of it).
Before pulling, set this option in git, to make it force case changes:
git config core.ignorecase false
and, if you want that to be your global default (requires elevated console), also do:
git config core.ignorecase false --global

This matters if someone does a force push and the names get clobbered again, so please at least set it for your repo working directory.

There we go. Titled to blame my file names rather than Linux itself since it was my bad in the first place. 😅

Also, if you do not change that setting BEFORE pulling after this gets merged, you will have two of each file, because NTFS is case sensitive. It's the win32 APIs and the way they're used and configured, by default, on every existing windows version.
Gripes follow... Leave now for your own sanity.
PowerShell itself is not case sensitive for anything but variable names, on all platforms.
....But the file system still is, and the module import process HAS to respect file case for correct behavior...


Linux Build

Right now V2022.8.0 only has a Windows build as that is what I used to develop the Qt rewrite. However, I don't mean to leave all my wonderful Linux users behind. For V2022.8.1, there will be a Linux build as well!

Just have to set up my WSL2 dev environment.

Just in case, Why did you rewrite your app. It already looked good.

silly me #42

I'm happy to announce, I'm rewriting back to GTK 4 and Libadwaita. Expect a release by the end of this week!

This is awesome to hear! I've been using a "web app" created with Epiphany as a workaround, but a native GTK 4 app (or wrapper) is going to be much better.
Will it support light/dark theme and apply it to the app itself?

@nlogozzo you have a lot of energy! Do yoi want to create it with gtkmm 4 or just gtk?

Yes, it's look and function just like the previous gtk version of the app (2022.6.3) which is still available and usable on flathub. This new version will just include some bug fixes and improvements to performance that I included in the Qt version.

@nlogozzo you have a lot of energy! Do yoi want to create it with gtkmm 4 or just gtk?

Haha yes I do. Windows and Qt just weren't cutting it. And I finally got fedora 36 working on my laptop with wifi drivers (had to install kernel 5.10) so now I'm good to go again :)
The gtk side will be pure C, which will be easier working with libadwaita cause there is no "adwaitamm" . And then the app functionally will be done in C++ . Just like the previous gtk version of the app was written.

You can take a look at a skeleton architecture for the app here: https://github.com/nlogozzo/NickvisionApplication

https://github.com/nlogozzo/NickvisionTagger/commit/143e7f92f3fd841ccef879e91eeba255f3c9de08

Look out for a release soon!

https://github.com/nlogozzo/NickvisionTagger/releases/tag/2022.9.0-beta1


Fix font color typo in minimalSelect.styles.js

The MinimalSelect component is a select box with a white background color.  The font color was an extremely-light purple, which was extremely difficult to see on the white background.
I took a look at the source and I'm pretty sure that shade 50 is supposed to be 500.
Using value 50:

Using value 500:

This PR fixes issue #956

Awesome! thanks will merge and release today.


Show sha256 for Xray's DBSyncV3 files that will be downloaded

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

We're adding tests to ensure the code works as expected, regardless of whether the functionality has an external affect or not.

Testing this porperly is super easy. No extra logic what so ever. Simply have a function that returns the log output as a string, and then test its output. The tests table should include all cases.

I've extracted getting the filename string to a different function and changed the test to check that returned string.
Works for you?
I think adding a function that is "get string for specific log" is a bad code-smell, at least parsing the filename is reasonably something that justify being its own function and we can put in the test you desire.


CORE-1469: Support Pulling Pages by Name

Our Page API currently only support pulling pages by Module name. Heidrick and Struggles (as well as internal users here at Skuid) are requesting the ability to pulling one or more pages by name, rather than having to pull an entire module at a time (hitting heap errors).

@joshchandler is this ready to be looked at?

@jgoodlet is this ready to be reviewed?

@jgoodlet, I went ahead and changed that parameter since the changes were small and I was already looking at the branch. However, that's the first time I've ever written Go code, so you might want to pull this branch and functionally test it again.

@BravoEncore All seems well. Thanks for going ahead and making those changes.


add confirm to reboot

Proposed feature for #185

test broke on circle compared to local. will update

Current coverage is 80.95% (diff: 30.00%)

Merging #224 into master will decrease coverage by 2.55%

@@             master       #224   diff @@
==========================================
  Files            29         29
  Lines          2959       2987    +28
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
- Hits           2471       2418    -53
- Misses          488        569    +81
  Partials          0          0

Powered by Codecov. Last update 6bfdfc2...b4b5b0c

@cglewis updated the commit to be circle-ci happier

@cglewis done


Delay syntactic sugar

Coverage increased (+0.04%) to 97.111% when pulling 3bfc7ebe754b0e9612d53ce1c0fb866193423753 on delay-syntactic-sugar into 8040ff6df5e16a3af7fbb4a9b8868e3cce87b090 on master.


Update types and expand tests

I noticed there were a few options and functions missing from the type declarations, so I added them

Thank you!


[Synapse] January release

Re-generating with latest swagger which includes new operations for Metastore

API changes have been detected in @azure/synapse-artifacts. You can review API changes here


Extra71 give wrong result

Extra71 give wrong result
7.1 [extra71] Ensure users with AdministratorAccess policy have MFA tokens enabled (Not Scored) (Not part of CIS benchmark)
after scanning process, I checked with aws console but I found user in admin group already enabled MFA.
Please check and fix issue.

if your user has  AdministratorAccess policy and MFA is not showed by Prowler. Should it be shown as PASS?

Probably it should do it to keep consistency with other checks in Extras.

I have reviewed that check and it looks for AdministratorAccess policy in groups, not in users. I'm going to change the title to show what it actually checks, for users with console access and MFA enabled there is already check12.


RangeError: Maximum call stack size exceeded on Tizen WebView when playing DRM content

Have you read the FAQ and checked for duplicate open issues?
Yes
If the problem is related to FairPlay, have you read the tutorial?
Not applicable, as this issue is not related to FairPlay.
What version of Shaka Player are you using?
I am using Shaka Player version 4.11.7
Can you reproduce the issue with our latest release version?
Yes
Can you reproduce the issue with the latest code from main?
Yes
Are you using the demo app or your own custom app?
I am using my own custom app on the Tizen platform.
If custom app, can you reproduce the issue using our demo app?
The demo app is not directly available on Tizen, but testing was performed using a content URL from the demo app: https://storage.googleapis.com/shaka-demo-assets/sintel-widevine/dash.mpd
What browser and OS are you using?
WebView on Tizen 8.0, SMART-TV. User Agent details: "5.0 (SMART-TV; LINUX; Tizen 8.0) AppleWebKit/537.36 (KHTML, like Gecko) 108.0.5359.1/8.0 TV Safari/537.36"
For embedded devices (smart TVs, etc.), what model and firmware version are you using?
Samsung UE65DU7172UXXH, firmware version 1120
What are the manifest and license server URIs?
https://storage.googleapis.com/shaka-demo-assets/sintel-widevine/dash.mpd
What configuration are you using?  What is the output of player.getNonDefaultConfiguration()?
{}
What did you do?
Trying to play content from https://storage.googleapis.com/shaka-demo-assets/sintel-widevine/dash.mpd without DRM configuration.
What did you expect to happen?
I expected a player error NO_LICENSE_SERVER_GIVEN (6012)
What actually happened?
The error encountered is RangeError: Maximum call stack size exceeded which points to an issue in the method alphabeticalKeyOrderStringify_ of the file shaka-player.ui.debug.js. The same error occurs if DRM settings are present in the configuration even if the content being played does not have DRM (https://storage.googleapis.com/shaka-demo-assets/angel-one/dash.mpd). If I remove DRM settings, then it plays fine.

This issue seems to stem from v4.4, because v4.3 works fine.

@tykus160 can you review it? Thanks!

I'm not able to reproduce the issue on QE55QN91AAT (Tizen 6) using current main branch. My model is premium though, maybe that's the difference.

alphabeticalKeyOrderStringify_ recurses through an object, but a circular reference could cause a major issue.
It is only used in serializing decoding configs to use as cache keys, though, so I don't expect a circular reference should exist.  On the other hand, that's a lot of recursive calls in the screenshot.  The structure should never be that deep.
Honestly, I always worried that the cache on MediaCapabilities would cause problems some day.  So if someone has a clever solution to remove it, I'm open to that.
@sreinus, since we can't reproduce this, could you modify Shaka to capture the structure in the initial call to alphabeticalKeyOrderStringify_ from getDecodingInfosForVariant_?  I'd love to see what JSON.stringify() makes of it.
It also occurs to me that perhaps we could end up with a circular reference through a bug in lib/polyfill/media_capabilities.js, if that somehow modified the input decoding config by mistake.

alphabeticalKeyOrderStringify_ recurses through an object, but a circular reference could cause a major issue.
It is only used in serializing decoding configs to use as cache keys, though, so I don't expect a circular reference should exist. On the other hand, that's a lot of recursive calls in the screenshot. The structure should never be that deep.
Honestly, I always worried that the cache on MediaCapabilities would cause problems some day. So if someone has a clever solution to remove it, I'm open to that.
@sreinus, since we can't reproduce this, could you modify Shaka to capture the structure in the initial call to alphabeticalKeyOrderStringify_ from getDecodingInfosForVariant_? I'd love to see what JSON.stringify() makes of it.
It also occurs to me that perhaps we could end up with a circular reference through a bug in lib/polyfill/media_capabilities.js, if that somehow modified the input decoding config by mistake.

Replacing alpahbeticalKeyOrderStringify with JSON.stringify() fixes the issue. I have no idea why this happens with my setup, but I agree that the current solution with the circular reference is not the best.

If JSON.stringify fixes it, it might not be a circular reference.  Here's what I found in the JS debugger in Chrome, at least:
a = {}
a.a = a
JSON.stringify(a)

VM122:1 Uncaught TypeError: Converting circular structure to JSON
    --> starting at object with constructor 'Object'
    --- property 'a' closes the circle
    at JSON.stringify (<anonymous>)
    at <anonymous>:1:6

Still, I wonder why we get into a seemingly-infinite recursion in your case and not for any of us.  Could your device produce different results for "for (const key in obj)" or "for (const key of keys)" or "if (value instanceof Object)" that would lead to deeper recursion?  For example, if "prototype" shows up in the keys, that could break things.  It might be interesting if you could log "obj" and "keys" right after "keys.sort()" and show us what the first few iterations look like.

A related report came into video-dev Slack.  In that, there seems to be a point where an array has extra properties that lead to the array constructor and therefore a circular reference.  (Because for function x, x.prototype.constructor.prototype === x.prototype.)
So I'm suspicious of polyfills or app frameworks that modify Array.

Speculative draft PR here: https://github.com/shaka-project/shaka-player/pull/7721
It adds special cases for arrays and functions.

Reporter on video-dev Slack confirms that the PR above fixes the issue for him!


takeScreenshot ignores Path Pattern Placeholders

What is your Scenario?
Trying to specify name for the screenshot ad it ignores Path Pattern Placeholders specified in config file.
What is the Current behavior?
it ignores Path Pattern Placeholders specified in config file
What is the Expected behavior?
have to use Path Pattern Placeholders
What is the public URL of the test page? (attach your complete example)
N/A
What is your TestCafe test code?
await t.takeScreenshot("asd"); -> saves in ./artifacts/screenshots/asd.png
await t.takeScreenshot("${DATE}${TIME}/${TEST}/asd.png"); -> saves in ./artifacts/screenshots/${DATE}${TIME}/${TEST}/asd.png
Your complete configuration file
screenshots: {
path: "./artifacts/screenshots",
takeOnFails: true,
pathPattern: "${DATE}${TIME}/${TEST}/${FILE_INDEX}${QUARANTINE_ATTEMPT}.png",
thumbnails: false
},
Your complete test report
No response
Screenshots
No response
Steps to Reproduce
N/A
TestCafe version
3.4.0
Node.js version
v18.17.0
Command-line arguments
npx testcafe
Browser name(s) and version(s)
No response
Platform(s) and version(s)
No response
Other
No response

Hello @vasilyevi,
When you add a path in the takeScreenshot method the argument overrides the relative path specified with the default or custom path patterns from your config file.
Please refer to the following help topic: t.takeScreenshot Method

I do understand that it overrides, but my need is to make a screenshot with a custom name, but save it exactly to the same folder. Is it supported? what's the reason if not?

TestCafe does not support this functionality, and we cannot classify it as a bug. We can accept this ticket as an enhancement request. However, we cannot specify estimates for when this feature may be implemented.

I definitely disagree as one feature bakes the logic of another one. I surprised it wasn't reported previously. Anyway it's up to you


Refactor DGP off Sarif4k

Is the remaining action that we should refactor DGP off Sarif4k so that

Respecting KGP compileOnly dependency
Not exposing transitive dependency when our client/users depends on KGP

Originally posted by @chao2zhang in https://github.com/detekt/sarif4k/issues/43#issuecomment-1445413535

There are two ways I can think of

Depend on simplejson to do lightweight parsing and merging
Because gradle bundles with GSON or Jackson, we can define the object mapping for Sarif in Gson or Jackson.

Because gradle bundles with GSON or Jackson, we can define the object mapping for Sarif in Gson or Jackson.

I would prefer this one as it won't bring any extra dependency

Yup that's also an option. Still we use just one method of Sarif4k in DGP, so refactoring might be preferred

I was curious how it would look like, so I raised https://github.com/detekt/detekt/pull/6117.


Staging to Master: new set of algos, hyperparameters tuning and more

Checklist:

[x] My code follows the code style of this project, as detailed in our contribution guidelines.
[x] I have added tests.
[x] I have updated the documentation accordingly.

Hi, I noticed that the notebook's readme file, both for quick start and deep dive, does not include RBM description.

great catch @WessZumino, do you want to add the description? if you do a PR to staging it will directly enter on this PR

Replace "AML" with "Azure Machine Learning" as per #483

hey @loomlike, regarding your comments, can you directly change the files and add a PR, which can be reviewed by @WessZumino and others? I have done some changes in some of these files, please see https://github.com/Microsoft/Recommenders/pull/504

Forgot to create a new branch and directly pushed to staging... so I just reverted the last commit I made. Will create a new PR for those changes.

@miguelgfierro I was about to merge this but one of the tests failed. I'm not sure if it's just a fluke, but it's too late for me to dig into it. If you can take a look when you have time and merge to master I'd appreciate it. I'll bump the PR just to see if the tests run through ok, maybe too many things pushed all at once?


Enhance Login and Signup Interfaces with Navigation Bar and Modern Design

I would like to propose an enhancement for our open contribution platform regarding the login and signup interfaces. Currently, the user experience when trying to access these features is not available.
Key Points:

Absence of Navigation Bar: The lack of a navigation bar on the site can lead to confusion for new users trying to sign up or log in. This PR introduces a clear navigation bar that guides users through the signup and login processes.

Modern Design: A modern, aesthetically pleasing design has been implemented to significantly improve user engagement. This includes:

Clean input fields with icons.
Distinctive buttons with hover effects.
Clear messaging that indicates transitions between login and signup forms.
A background that matches the overall theme of the site, enhancing the visual appeal.

I believe these changes will greatly enhance the user experience and look forward to your feedback!

@Abhilash107 yes

@Abhilash107  Could you tell me what kind of website this is so I can design a feedback form for you too?

"Can you add the Hacktoberfest label to it? It would mean a lot to me if you could."

@Abhilash107 yes

Hey there! Don't forget to star the repository and give me a follow!


fix: accessibility issues

Hi, I noticed that the website has some accessibility issues like low color contrast and missing alt text for images. I would love to fix this so that the website does better on Google, and to help people with eye issues.
If you want to see the issues yourself, you can look at WAVE analysis of WalkingPal
I would like to fix the following things:

Color contrast in navbar,
Color contrast in 'Get your walking buddy' section
Color contrast in 'Reimagine your daily commute' section
Alternative text for images
Empty links

Let me know if you're interested in this 😊

please make separate PRs for different pages

Sure thing!

@ashuvssut The questions and answers in the FAQ could also use a bit of change in contrast/weights to establish a better visual hierarchy and make it easier to differentiate. As this similar issue was already up, adding this suggestion as a comment.

@astro3012 right!
When I was creating those sections we followed this figma design board created by the team
I really do not understand what contrast changes are... I guess they might be simple color changes only
make sure we do not deviate from the original color theme too much. tbh I suck at design skills. I am just good at replicating designs in code. @lovelacecoding can you just show me what kind of contrast changes were you referring to (using screenshots)
I am completely fine with ARIA labels n stuff. I am just little concerned about contrast changes. A few screenshots showing how it looked"before" and how its gonna look "after" the contrast change will help.

That you already have a color palette makes it way easier @ashuvssut. Let me change it more to that. I'll come back with screenshots shortly

Oh no, don't refer the color palette section given in the figma design. @lovelacecoding The color palette we follow is in theme.ts. We created that color palette by refering the designs in figma. we have .docs/style-guide.md that  describes the palette. Refer theme.ts.

Alright. Then I'll use that instead. I'll come back to you :)

Okay so for the front page I made the following changes when it comes to contrast.
The navbar
Made a slight change from #828282 to #737373. This passes the accessibility contrast check.
 So I decided that instead of a color to go for a bold font to not get away from the theme too much.
Before:

After:

Let me know what you like and do not like. All of these changes now pass the contrast check on webaim, which means it's accessible for most people and that search engines will be happier with you :)

LGTM!
please make the PR

Done! You can find what I fixed on PR #40


Display latest version compatible with input spec

Dear maintainer,
Whenever using cargo info <pkg>@<spec> where <spec> does not select the latest version, the command displays the latest version available on the used registry. This is a fine feature that should be kept, but in addition, it would be nice if it could also display the latest available version that matches the given spec. This would enable me to easily detect whether a currently-installed package is in the latest version available that matches a configured spec or not, to then know whether it needs an update or not.
For example, if <pkg> has 0.1.0, 0.1.1 and 0.2.0 available, then cargo info<EMAIL_ADDRESS>should display version: 0.1.0 (latest compatible 0.1.1) (latest 0.2.0) or even just version: 0.1.1 (latest 0.2.0), but that might too drastic of a change -- I'll let you judge on that.
From what I can see in src/ops/info.rs and src/ops/view.rs, all versions of a package are retrieved from the registry and then filtered offline to only keep the ones compatible, so adding this should not be too big of a change, right?
Cheers,
Paul.

Crates.io tends to highlight the latest version in every major version: https://crates.io/crates/clap/versions
This is an interesting idea to do something similar here.  My main concern is bloat in the output.  I mentioned in another issue the idea of putting some information behind --verbose.  This might be a possibility.
Note that MSRV compatibility is another dimension.
Also, I am looking at trying to communicate some of this information in cargo update for direct dependencies so that a dry-run would be kind of like cargo outdated and could help advise you on situations like this.  Personally, I think this is more of where we should focus this interaction since that is the tool users will be using for dealing with versions.

My main concern is bloat in the output. I mentioned in another issue the idea of putting some information behind --verbose. This might be a possibility.

That's a possibility indeed, although the output bloat wouldn't be that high I think.

Note that MSRV compatibility is another dimension.

Yes, you're right, there should be a MSRV filtering similar to what is already done.

Personally, I think this is more of where we should focus this interaction since that is the tool users will be using for dealing with versions.

True, libraries are more important in this aspect. However, I'm specifically considering only binary packages here, for example installed through cargo install, so things that would be unrelated to any kind of current workspace.

For some reason, I missed that this suggested we pick the highest within a spec.  That was implemented in #53.
e.g. try
$ cargo info clap@3
clap #argument #cli #arg #parser #parse
A simple to use, efficient, and full-featured Command Line Argument Parser
version: 3.2.25 (latest 4.5.3)
...

Oh, right, thanks! Maybe it had not been in a release yet when I tested my things :thinking:
If this is indeed what I initially meant, then the current issue can be closed.


Use QualifiedIdents for decls when constructing dependency graphs

update inferDecl* methods to store inferred types on the decls/patterns themselves instead of using Env
update inferDecl* to accept list instead of a single Decl
get basic deps working in some cases

Codecov Report
Attention: Patch coverage is 59.20139% with 235 lines in your changes are missing coverage. Please review.

Project coverage is 81.81%. Comparing base (0fd6b4b) to head (b4a16cf).

Files
Patch %
Lines

src/Escalier.TypeChecker/QualifiedGraph.fs
58.00%
231 Missing :warning:

src/Escalier.Interop/Migrate.fs
66.66%
4 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #228      +/-   ##
==========================================
- Coverage   83.11%   81.81%   -1.30%
==========================================
  Files          22       23       +1
  Lines        9611    10173     +562
  Branches     1370     1463      +93
==========================================
+ Hits         7988     8323     +335
- Misses       1623     1850     +227

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Fix: Left operand of 'is' is a previously freed instance.

I got the following error. I fixed it by placing a verification.
The error:

ERROR: Attempted to find an invalid (previously freed?) object instance into a 'TypedArray.
at: validate_object (core/variant/container_type_validate.h:116)
ERROR: Condition "!_p->typed.validate(value, "find")" is true. Returning: -1
at: find (core/variant/array.cpp:354)
SCRIPT ERROR: Left operand of 'is' is a previously freed instance.
at: change_active_object (res://addons/m_terrain/gui/mtools_edit_mode_selector.gd:109)

How I fixed:

if object:

	if object is MTerrain:
		active_object = object
		edit_selected_button.text = "Click to Sculpt " + object.name
	elif object is MGrass or object is MNavigationRegion3D:
		active_object = object
		edit_selected_button.text = "Click to Paint " + object.name
	elif object is MPath or object is MCurveMesh:
		active_object = object
		edit_selected_button.text = "Click to Edit " + object.name
	else:
		edit_selected_button.visible = false

This is on Godot Engine v4.4.dev.custom_build.9e8447c63