Further differentiate performance characteristics associated with pod level QoS

Feature Description

One-line feature description (can be used as a release note): Provide a reason why users would choose to run Guaranteed pods over Burstable pods.  Right now, Guaranteed pods have a penalty (due to cpu limit enforcement).  Ideally, we can optimize how the kubelet manages Guaranteed pods to provide material benefits over Burstable pods, particularly with respect to latency sensitivity.
Primary contact (assignee): @sjenning @ConnorDoyle
Responsible SIGs: sig-node
Design proposal link (community repo): https://github.com/kubernetes/community/issues/654
Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred: @vishh @derekwaynecarr
Approver (likely from SIG/area to which feature belongs): @derekwaynecarr
Initial target stage (alpha/beta/stable) and release (x.y): Alpha 1.8, Beta 1.10

@derekwaynecarr I didn't target this for 1.7 since it relies on our design.

/assign

@ConnorDoyle @dchen1107 - updated as follows:

Primary contacts to @sjenning and @ConnorDoyle
Link to design proposal added https://github.com/kubernetes/community/issues/654
Reviewers to @vishh and @derekwaynecarr
Approver to @derekwaynecarr
Target for Alpha in 1.8

xref #375

@ConnorDoyle @sjenning @kubernetes/sig-node-feature-requests any updates for 1.8? Is this feature still on track for the release?

@idvoretskyi yes, there were a series of PRs that were merged to enable this
1/6 https://github.com/kubernetes/kubernetes/pull/49186 (closed, broken out into following PRs)
2/6 https://github.com/kubernetes/kubernetes/pull/51132
3/6 https://github.com/kubernetes/kubernetes/pull/51140
4/6 https://github.com/kubernetes/kubernetes/pull/51357
5/6 https://github.com/kubernetes/kubernetes/pull/51180
6/6 https://github.com/kubernetes/kubernetes/pull/51041 (still open, e2e tests)

last PR looks like it's scheduled to merge. @sjenning, do you have a docs PR in flight?

@calebamiles Some docs related to CPU manager have already merged (https://github.com/kubernetes/kubernetes.github.io/blob/release-1.8/docs/tasks/administer-cluster/cpu-management-policies.md). There are some PRs in flight to update them.

Thanks for the update, @balajismaniam. @derekwaynecarr suggested that this feature issue was essentially a dupe of https://github.com/kubernetes/features/issues/375 but predates it. How would we feel about closing this issue in favor of https://github.com/kubernetes/features/issues/375?
cc: @kubernetes/sig-node-feature-requests, @kubernetes/kubernetes-release-managers

Depends on what else besides CPU manager @derekwaynecarr has in mind to differentiate the G class. If there's nothing specific planned for now then +1 to close it.

@balajismaniam @derekwaynecarr One thing seems missing in doc and proposal is, for example when I set  cpu: "2", what's the value should be in Pod level cgroup? We should skip container with cpu request >= 1 during ensuring pod qos.

updated beta status for 1.10

@ConnorDoyle @sjenning @derekwaynecarr @kubernetes/sig-node-feature-requests
Any plans for this in 1.11?
If so, can you please ensure the feature is up-to-date with the appropriate:

Description
Milestone
Assignee(s)
Labels:

stage/{alpha,beta,stable}
sig/*
kind/feature

cc @idvoretskyi

This feature current has no milestone, so we'd like to check in and see if there are any plans for this in Kubernetes 1.12.
If so, please ensure that this issue is up-to-date with ALL of the following information:

One-line feature description (can be used as a release note):
Primary contact (assignee):
Responsible SIGs:
Design proposal link (community repo):
Link to e2e and/or unit tests:
Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred:
Approver (likely from SIG/area to which feature belongs):
Feature target (which target equals to which milestone):

Alpha release target (x.y)
Beta release target (x.y)
Stable release target (x.y)

Set the following:

Description
Assignee(s)
Labels:

stage/{alpha,beta,stable}
sig/*
kind/feature

Once this feature is appropriately updated, please explicitly ping @justaugustus, @kacole2, @robertsandoval, @rajendar38 to note that it is ready to be included in the Features Tracking Spreadsheet for Kubernetes 1.12.

Please note that Features Freeze is tomorrow, July 31st, after which any incomplete Feature issues will require an Exception request to be accepted into the milestone.
In addition, please be aware of the following relevant deadlines:

Docs deadline (open placeholder PRs): 8/21
Test case freeze: 8/28

Please make sure all PRs for features have relevant release notes included as well.
Happy shipping!
P.S. This was sent via automation

Hi
This enhancement has been tracked before, so we'd like to check in and see if there are any plans for this to graduate stages in Kubernetes 1.13. This release is targeted to be more ‘stable’ and will have an aggressive timeline. Please only include this enhancement if there is a high level of confidence it will meet the following deadlines:

Docs (open placeholder PRs): 11/8
Code Slush: 11/9
Code Freeze Begins: 11/15
Docs Complete and Reviewed: 11/27

Please take a moment to update the milestones on your original post for future tracking and ping @kacole2 if it needs to be included in the 1.13 Enhancements Tracking Sheet
Thanks!


CXS GraphQL Reference Implementation

In order to do this we will have to :

Upgrade Apache Karaf from version 3 to version 4 in Apache Unomi project
Move the skeleton project that is in the java subdirectory to the Unomi project
Start connecting the skeleton project to the actual data

Closing it, we will use smaller issues instead


feat(events): support actor_scaled event

Feature or Problem
This PR adds a handler for the actor_scaled event which will be able to summarize all of the information in actors_started and actors_stopped with an idempotent event.
Though there's future work to really make this work with v0.82, this can be released at any time without problems as the event doesn't exist yet.
Related Issues
Requires https://github.com/wasmCloud/wasmCloud/pull/1336
Filed #239 to cover future work that can't be done today.
Release Information
v0.11.0
Consumer Impact
Note that, if testing with the unreleased v0.82.0, this may cause duplicate state updates because both the actors_started and actor_scaled events will be handled. I'll be creating an issue shortly to cover this update.
Testing

Unit Test(s)
I modified the test_all_state function to ensure functionality around starting/stopping/scaling up/down actors.
Acceptance or Integration

Manual Verification

Holding on the merge here just a moment to ensure we can release v0.82 before we start cutting wadm releases with this change. Only reason why is that here, for v0.82, we'll handle both the actorscaled and actorsstarted events so we might get incorrect state inbetween heartbeats.


Hello，When will it be open source?

Hello，When will it be open source?

sorry for the delay, somewhere around Interspeech decisions (June 6)

hello, now that interspeech is finished, any new timeline on releasing the code and model, as mentioned in the paper?


Listen server host cannot save demos

Bug
Hosting a listen server seems to prevent the host from saving demos
Steps to reproduce

Make sure you have demos enabled (join a server, play a round, close game, check Titanfall2\r2\ if the demo is in there)

log 1
demo_enabledemos 1
demo_autoRecord 1
demo_autoRecordName demo
demo_writeLocalFile 1

Host a listen server, play a round, close game, check whether the demo was saved
No demo was created from when hosting the server even though it should be there

Specifications

Northstar version: 1.5.0-rc3
Platform: Steam

Tested again to make sure and can confirm. Demo worked on joining random server but not when hosting my own listen server.

As demos basically just record and playback network packets and as a listen server doesn't talk over the network stack to the own client there's nothing to record.
Forcing to use the network stack via net_usesocketsforloopback 1 does result in demos being recorded. However we do not want to set that by default as it also applies to e.g. single player which can cause players to lag in singleplayer.


Replace shell scripts with more portable NodeJS script / NPM package

TODO: replace JSON key-sorting utility (native cross-platform CLI utility "jq") with more portable NodeJS script / NPM package:
jq:
https://stedolan.github.io/jq/manual/
...was introduced in this PR:
https://github.com/readium/readium-desktop/pull/506
Actual shell script:
https://github.com/readium/readium-desktop/blob/c6f6d0a3d3f839752109eca374cfd38db2884948/scripts/locales-utils.sh#L1-L26

TODO: replace JSON patcher with more portable NodeJS script / NPM package:
https://github.com/readium/readium-desktop/blob/1352b0170b7a622f01bc4bab6e8c727421c31dad/scripts/i18n-typed-patch.sh#L1-L5

Re-opening to address the second shell utility (prefix + suffix on JSON locale)


Make all the things responsive

This covers most of the layout to make it usable on smaller devices. This work will require changes to the root repo and a fix to the security page which isn't getting the javascript (should be merged already - not tested)

needs merge here as well https://code.platform.silverstripe.com/silverstripe/deploy-silverstripe-com/merge_requests/30

This doesn't merge cleanly. Can you rebase and then push your changes again?

@micmania1 done the rebase finally

Tested locally, there are a couple of quirks in small screen mode, but it's actually responsive so the in general it's a huge improvement.


'package version create' fails silently when compressing multiple folders under staticresources

Summary
We are attempting to build a 2GP package for our app and running into this issue.
When we run the package version create command, it fails silently. We do not get any extra info from --verbose or even --json. Just nothing.
After some heavy troubleshooting, I was able to reproduce the issue. It occurs when I try to create a package version with multiple uncompressed static resource folders. I'm not sure why this happens, but it is easily reproducible using the provided repo. The error seems to happen somewhere in the MetadataConverter's conversionPipeline, which makes it difficult to troubleshoot further. @salesforce/source-deploy-retrieve/lib/src/convert/metadataConverter.js
Steps To Reproduce
See https://github.com/gbutt-tr/package-version-create-error
Expected result
A package version is created
Actual result
CLI fails silently.
System Information
{
  "cliVersion"<EMAIL_ADDRESS>  "architecture": "darwin-arm64",
  "nodeVersion": "node-v18.17.1",
  "osVersion": "Darwin 22.5.0",
  "shell": "zsh",
  "rootPath": "/opt/homebrew/Cellar/nvm/0.39.5/versions/node/v18.17.1/lib/node_modules/@salesforce/cli",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 2.3.6 (core)",
    "@oclif/plugin-commands 2.2.23 (core)",
    "@oclif/plugin-help 5.2.17 (core)",
    "@oclif/plugin-not-found 2.3.37 (core)",
    "@oclif/plugin-plugins 3.2.7 (core)",
    "@oclif/plugin-search 0.0.22 (core)",
    "@oclif/plugin-update 3.1.32 (core)",
    "@oclif/plugin-version 1.3.8 (core)",
    "@oclif/plugin-warn-if-update-available 2.0.48 (core)",
    "@oclif/plugin-which 2.2.31 (core)",
    "@salesforce/cli 2.6.7 (core)",
    "apex 2.3.11 (core)",
    "auth 2.8.13 (core)",
    "community 2.2.9 (user)",
    "data 2.5.7 (core)",
    "deploy-retrieve 1.17.5 (core)",
    "info 2.6.39 (core)",
    "limits 2.3.31 (core)",
    "login 1.2.28 (core)",
    "org 2.10.3 (core)",
    "packaging 1.16.5 (user)",
    "schema 2.3.23 (core)",
    "settings 1.4.26 (core)",
    "sobject 0.2.6 (core)",
    "source 2.10.32 (core)",
    "telemetry 2.3.1 (core)",
    "templates 55.5.10 (core)",
    "trust 2.6.3 (core)",
    "user 2.3.29 (core)"
  ]
}

@gbutt-tr why packaging is under user and not core?

@AllanOricil updating the packaging plugin resolved the issue. Thanks!

course it does 😤
Now donate some money to charity

Adding some clarity about user versus core plugin for plugin-packing.  In the sf v2 CLI (e.g., the one you listed above) the plugin-packaging plugin is a JIT, meaning it's installed "just in time" upon first packaging command execution.  When installed, it is a user plugin and not a core plugin.  In previous versions of sf and sfdx, plugin-packaging was a core plugin.  JIT plugins allow for a slimmer CLI.  They are generally medium to large sized plugins that have fewer total executions per analytics data.
Thanks Allan for answering!


Spacing between the lists might not be very clear

Right now the new lists just look like they're yet another table row until you see the border. I've played around with it a bit, but can't settle on a good choice. Setting background-color to blue-dark-hover doesn't make it look any better to be honest.

Since it seems like we're going with alternating row-colors now, this will be handled.


Grading: Truncate long assessment titles

I was working on creating dummy data and chanced upon this. Grading table shows the entire assessment name resulting in having to scroll horizontally to view everything else.

It should be a simple fix for someone who is willing to take it up, set the column width to a fixed length and any overflow can be replaced with ellipses.

https://developer.mozilla.org/en-US/docs/Web/CSS/text-overflow
For anyone who wants to take up this issue


Implement view meetup architecture

Includes the following changes:

Add command for viewMeetUps
Add storage for MeetUpList
Add model for MeetUp

Closes #75

LGTM MENG YOU THE GOAT MY GOAT MY GOAT


Request for Support for Ascend Series Graphics Cards

Hello,
I hope this message finds you well. I am writing to kindly request your support for the Ascend series of graphics cards in your project.
As you may be aware, recent geopolitical circumstances have resulted in the inability for developers in China to access NVIDIA graphics cards due to export restrictions from the United States. As a result, many of us have turned to domestically produced alternatives, such as the Ascend series graphics cards, which have proven to be highly capable and efficient.
However, the lack of support for the Ascend series in many projects, including this one, has presented a significant challenge. It would be greatly appreciated if you could consider extending your support to include these graphics cards, thereby enabling us to continue contributing to and benefiting from your project.
I understand that this may require additional resources and effort on your part. To assist you in this endeavor, I have included the link to the official Ascend development resources on GitHub and their official website:
GitHub: https://github.com/Ascend
Official Website: https://www.hiascend.com/en/
These resources provide comprehensive documentation and development tools that should hopefully make the process of integrating support for the Ascend series more straightforward.
I sincerely appreciate your consideration of this request. The support for Ascend series graphics cards would not only benefit developers in China, but also those across the globe who may choose or need to use these cards.
Thank you for your time and understanding. I look forward to your positive response.

Thank you for your advice.
To my knowledge, Huawei Ascend series are NPU processors, which has a structure totally different from GPUs. This means our team members need specialized knowledge about its optimization. Meanwhile, its main APIs provided are limited to call operators defined in its CANN packages, which means its development model is not that open.
This is a small project and the develop team has very limited time and resources. we do not have enough support from Huawei and the author cannot obtain an Ascend NPU for debugging (#117). So this issue will be held for a future development, and you are welcomed to contribute code.


Question about turning on cancellation

If I include a module that wants to turn on cancellation after I have already made promises without enabling cancellation, Bluebird throws an error telling me that I should have turned on cancellation before I made any promises and that it can't be done anymore. I am therefore forced to turn on cancellation in my own code before I do anything else even though I believe I shouldn't care about it. The module itself may never need to be included.
Without going into the specifics of what code I have written, what is the proper behavior for a module that needs cancellation (or for the app requiring it)? Should I always require all of the modules I may need later? Should the module require a fresh new copy of Bluebird by manipulating Node's cache? Can I check in some way if cancellation can be enabled and manage without it if it can't?
Thanks in advance and sorry if n00bish.

The module should use their own bluebird instance http://bluebirdjs.com/docs/features.html#scoped-prototypes

Thanks!


nimble-linux: ble_hci_sock_init: Assertion `rc == 0' failed.

The linux examples failed to run in the latest code
bind() failed 16 hci0
nimble-linux: ../../../nimble/transport/socket/src/ble_hci_socket.c:828: ble_hci_sock_init: Assertion `rc == 0' failed.
Aborted

The root cause was ble_hci_sock_init duplicated called in ble_transport_ll_init and linux example code.
It was introduced by this PR https://github.com/apache/mynewt-nimble/pull/1597.
@sjanc @CW-B-W Could you tell me why we need to initialize ble_transport_ll_init when use external controller?

If it is indeed necessary to do so，i can fix it by remove ble_hci_sock_init  from ble_transport_ll_init  in ble_hci_socket.c

ble_hci_sock_init calls should be removed from apps.
ble_transport_ll_init initializes LL side of transport which in case of external controller is a HCI socket so the socket should be initialized there.

Hello @Fanhang32,
I'm only a user of this project, and I only played it with FreeRTOS, therefore the below might not be completely correct.

In mynewt-nimble v1.5.0, the architecture of HCI transport had been modified.
(You may refer to nimble/doc/transport.md for the current architecture.)
When I was migrating my personal project from v1.4.0 to v1.5.0, I found the examples at that time were not compatible with v1.5.0.
For adapting to the v1.5.0 architecture, I opened PR https://github.com/apache/mynewt-nimble/pull/1597 to resolve the issue.
Is the example you used porting/examples/linux?
As I saw porting/examples/linux has not been maintained for a long time, I think this example might be kinda outdated and need to be adapted to the new HCI transport architecture.
Would it be better if we keep ble_hci_sock_init() in ble_transport_ll_init()
https://github.com/apache/mynewt-nimble/blob/64067f5168bd4de097b7830a078862a5df95d9a5/nimble/transport/socket/src/ble_hci_socket.c#L836-L841
and the remove ble_hci_sock_init() in the example (porting/examples/linux)?
https://github.com/apache/mynewt-nimble/blob/64067f5168bd4de097b7830a078862a5df95d9a5/porting/examples/linux/main.c#L69-L70
I think ble_transport_ll_init() is a more upper-level API for users to initialize the controller, while ble_hci_socket_init() may be the platform-specific implementation for ble_transport_ll_init()?

@andrzej-kaczmarek @CW-B-W Got it , thanks a lot！ I‘ve removed ble_hci_sock_init in example apps in https://github.com/apache/mynewt-nimble/pull/1670


Added cypress and basic testing code

I have configured cypress and added basic testing code for the html files based on how they are coded, the only failing test case at the moment is the "toggleLightDark() not found" as this function is not defined yet.
I have also added a e2e-tests.yml filewhich works on CI.

@Suvrat1629, could you update your work with the latest changes to fix conflicts?

I think the conflicts are occurring in the package.json file if I am not wrong which is because i have added scripts to open and run cypress, which shouldn't be a problem. Is this the issue or is there any other conflict occurring?

@lcrojano updates?

@Suvrat1629  Thanks for your response! The conflict is actually in the package-lock.json file, not package.json. This typically happens when different branches modify the dependency tree, causing discrepancies in the lock file.
The package-lock.json ensures consistent dependencies across environments, so it's important to resolve this properly.
To resolve the conflict:
Pull the latest changes from the target branch (main, for example).
git pull origin main

Resolve the conflict in the package-lock.json. A simple approach is to delete the package-lock.json file, run npm install to regenerate it, and then commit the new lock file.
rm package-lock.json
npm install

After resolving, commit the new package-lock.json and push it to the PR branch:
git add package-lock.json
git commit -m "chore: solve package-lock.json conflict"
git push origin <your-branch>

Let me know what do you think.

I have made the changes and followed the steps as you have told me to but i think re-adding the package-lock.json has changed the placement of code please review it and tell me if there is any issue.


Spec: Draft the new versioned API spec via TPD or GitHub Discussion

Something to consider in the versioned API: an "experimental" flag that can allow enable broader testing / feedback on new endpoints that may get dropped w/o notice.

Redundant, see #7.


Block highlight too dark

I encountered a “code block” in the documentation of https://help.sumologic.com/docs/search/subqueries/|subqueries and the highlighted part is too dark.
Slack Message

Actually this is deliberate to block out the parts of the query and focus the user's attention on the rest of the query.


Flex Layout doesn't respect active/inactive Game Objects

Flex Layout shouldn't consider Game Objects that are inactive in the Hierarchy. Instead it lays out everything like those objects are active. Even if I disable Flex Layout component on inactive objects it doesn't do anything...

Seems like a duplicate of #18.


Update Setting_up_conda_on_clusters.md

Added some info about how to add packages to environment and how to update it.

I fixed it and committed to the branch. Does it show up for you?

I fixed it and committed to the branch. Does it show up for you?

yup, it does. thanks for the fix.


Fix: Use the version instances to compare router children

Description

Comparing router setups were not very comprehensive, because we limited the number of fields to compare on child experiments. This causes us to miss changes in child bot assistants. The change I made here is basically to use the version method on the child experiments to compare it to each other. This is very comprehensive and if we ever change the definition of an experiment version i.e. add or remove a field, then it would automatically apply when comparing router children as well. One slight concern I have with doing this is the memory footprint for large assistants, but let's see how it goes. I do think this is the right approach.
User Impact

Fixes the issue described above
Demo

N/A
Docs

N/A

Merging since this fix is needed


Vectorize the computation of MAC tags for malicious shuffle

On 2M records, good for about 10%, 17:30 → 15:45. https://draft-mpc.vercel.app/query/view/bushy-due2024-11-05T2234
This is on top of the Shuffleable PRs.

Currently, this changes the shuffle traits to take &[S] instead of I: IntoIterator. I am not sure what would be best here, since the non-malicious shuffles still want an owning iterator and passing a slice may keep the inputs in memory longer than needed. Possibly just passing the Vec into the shuffle?

Possibly just passing the Vec into the shuffle?
Yea I think that is definitely preferred


feat(test): Merge all coverage in one file to parse it with codecov.io

Codecov Report

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

@@           Coverage Diff           @@
##           master      #37   +/-   ##
=======================================
  Coverage   84.14%   84.14%
=======================================
  Files           7        7
  Lines         694      694
=======================================
  Hits          584      584
  Misses         79       79
  Partials       31       31

Continue to review full report at Codecov.

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


What is the time unit of  this tag ?. Is it for Access token or Refresh token ?

https://github.com/cesanta/docker_auth/blob/509a03a9622f460ded806a2c7b7b27717b3cb1f5/examples/reference.yml#L47

Seconds.
It's just an integer that get's added to the unix epoch at the time of token creation: https://github.com/cesanta/docker_auth/blob/dd8ea4b8429b5e31bf102f77fdda866186e2cb6f/auth_server/server/server.go#L302


[Proposal] Live Preview tab for comment editor

Feature Description
The issue and PR comment editing UI should be redesigned to have a "Live Preview" WYSIWYG tab and a "Source" tab for raw markdown.
Reasoning
Since Gitea is in the process of redesigning this feature, it is a good time to carefully consider the user experience. I propose that we deviate from the Github interface. Their approach (a markdown tab and a preview tab) has various shortcomings from the perspective of user experience. For example, users must switch to the preview tab to view images. It would be better to view images inline by default but have the option to switch to pure markdown if desired. This would resemble tools like Slack and Obsidian which allow users to toggle whether markdown is shown in a live preview editor. The combination of a "Live Preview" tab and a "Source" tab will give users an improved editing experience as well as access to pure markdown. This is more intuitive than a partially rendered tab (like EasyMDE) and a fully rendered preview. Ideally, we would include a user setting for enabling or disabling this feature in favor of a native textarea.
Design Considerations
There are some important practical considerations to address. Primarily, the "Live Preview" tab will almost certainly need to be rendered by the client. Currently, markdown is rendered server-side when the user toggles to the preview tab. To avoid maintaining two parallel markdown implementations, we would need to render markdown on the client-side only and the WYSIWYG library would need support for non-interactive rendering. This would also ensure that the "Live Preview" rendered markdown matches the final rendered markdown in a published comment. We will want to use comprehensive testing to ensure the consistency of rendered markdown before and after this change.
Screenshots
No response

Well, my problem with this approach is the following:

WYSIWYG

Why was EasyMDE (and SimpleMDE before it) removed? The answer is simple:
There's no such thing as an "easy and error-free" WYSIWYG editor.
Furthermore, these editors aren't even perfect WYSIWYG but pseudo-WYSIWYG instead.
All approaches there are error-prone with a myriad of possible issues. First of all, accessibility.
Why does GitHub not implement this? They probably haven't found a good implementation either.
Why don't we implement it ourselves? Hard no.
Unless you happen to find an error-free feature-complete WYSIWYG MD editor library, this proposal sounds as probable to me as dragons and unicorns.
That's why I'm against it.

The good thing is now Gitea has the ability to switch editors. So if there is a better markdown editor, I think maybe the legacy EasyMDE could be replaced by a new one. Then the native textarea still works everywhere, and the new markdown editor could satisfy many users who like WYSIWYG.

From a developer point of view I dislike WYSIWYG because often not every feature the underlying language provides is implemented. So you end up with a mix of styled but unfunctional markup. Then it's not what I get what I see. The minimalistic "just markdown code" works better for me.

I'd like to give a little more context for the motivation as to why this proposal is being made.
As a developer, I prefer plaintext markdown for most things.  I like GitHub's textarea UI.  But there are times when writing a long issue or PR description that I need to flip back and forth between writing and previewing, which is not ideal.
There are also less tech-savvy users such as reviewers and other project stakeholders who aren't necessarily writing code, but who interact with issues and pull requests.  These non-developer users look at markdown, see it as code, and they just can't handle it.  This isn't my opinion; we regularly talk to users who complain about this.  I've also seen a similar thing play out several times over the years, across several apps, where developers and their managers thought they could reduce work by allowing end users to edit a "human readable" format.  It was always a point of friction with non-developers.
Non-developers also don't care about having the markdown format.  Many benefits, like the fact that it can be mirrored in other platforms or copied and pasted to almost any other web editor, they have no interest in, are unaware of the benefits, or are unable to articulate it as a desire for a standard format.  Thus, they see fewer downsides to WYSIWYG.
Don't shoot the messenger, i.e. me, for typing the above.
All that said, I never want to give up plaintext completely.  When I use Slack, the first thing I do when I join a new community is disable the WYSIWYG editor, and I think many developers are the same.  This is why the proposal contains the user setting, which is a critical piece, as the level of comfort with working with markdown is different for every person.  It cannot be an instance-wide setting.
No one said it wouldn't be challenging.  Mobile editing is important.  It would need to recognize issue and PR links, @-mentions, task list checkboxes, and footnotes.  It would need to render mermaid diagrams.  And it's all client-side to reduce latency and avoid having multiple implementations.  This proposal is an attempt to set the vision for where we want to end up, not something that will happen overnight.

Related https://github.com/ckeditor/github-writer
Related https://github.com/ckeditor/github-writer/issues?q=is%3Aissue+is%3Aopen+label%3Abug 😏

The problem of maintaining two editors is that every feature needs to be implemented twice, hindering new feature development. That is why I'd like to remove EasyMDE in an upcoming release, likely for 1.21.
I do understand concerns from non-technical people who prefer WYSIWYG, but I don't see us realistically supporting it, at least not with all features that the textarea editor has and will have in the future.

Respectfully, I think that some of the persons who replied to @jackHay22's post might have misunderstood his suggestion.
I don't think what he meant is to replace easyMDE with another WYSIWYG text editor.
By "Live Preview", he probably meant to let the user type text in the simple textarea (like we currently do) while another area shows a live preview of the final message, pretty much similar to what Discourse forums feature:
Click the image to watch the demo video:

Here is a live demo if you want to test this live preview, located on the right side of their text editor: https://try.discourse.org/

IMO, the easyMDE text editor is redundant and should be removed.
I share the same feeling as others about WYSIWYG text editors. I've never felt comfortable using them.
I prefer the current simple textarea + a few buttons above the textarea that everyone (developers and non-technical people) can use to quickly format their words/sentences + still the possibility to use the markdown syntax.
A live preview area, as suggested by @jackHay22 would be very convenient.

Agreed. That would also solve the problem of #30474.
The only problem that would need to be tackled is how to avoid DDOSing the server with requests to preview the markdown on every single change.
Probably something like send a request every <configurable timeout, default 2s or 3s> if something changed would be the best compromise both from a user and the server perspective.

Alternatively, but more complicated to implement:

send a request  ms after the user finished typing

Agreed. That would also solve the problem of #30474. The only problem that would need to be tackled is how to avoid DDOSing the server with requests to preview the markdown on every single change.

As jackHay22 suggested in his original post, the "live preview" would most likely have to be rendered locally, mimicking what the final result will look like when the message is posted.

The problem with that is:
That is an enormous maintenance burden.
I don't think this burden is worth it.
After all, from time to time, new features are added to the Markdown parser.
I can foresee a lot of disconnects between the local parsing and the remote one.
Additionally, even implementing a first draft will already be a huge amount of work in and of itself:
For example, does the client then need any single language definition we support to adequately pre-render codeblocks?
There is a reason why we offer an API route to render markdown text.

The server based rendering would keep this feature down to perhaps a one-time 100 line change.
Client based rendering is in my first estimate probably rather ~10000 lines minimum.


Preparations for the 3.0.0 release:

update docs to the new version
set the project version to 3.0.0

LGTM


Cookies expired and my account reached limit of the copilot usage in a day.

Another issue sir! sorry if I bothered you.
I opened creating conversations about 100 times if not 150 today.

It’s Microsoft’s limit per day; there’s nothing I can do.

You can use another Bing account’s cookie file to create a bot to avoid this.
However, you still have a 300-message-per-day limit.

We don’t have this feature at the moment.

Can only run without cookies in some regions.


import/unambiguous confused typescript declaration file(d.ts)

when there are some declaration file exists in my projects, import/unambiguous rules always told me  This module could be parsed as a valid script  import/unambiguous
I think this is redundant.  Typescript isolatedModules config is enough, and this rule will ignore .d.ts file.
so, how to deal with it? If we want users to manually disable import/unambiguous rule(ignore .d.ts file), I feel that we need to update the sample config

The unambigous rule should only be run on .js files, since its entire purpose is to pretend that the Module and Script parse goals of JS don't overlap, so that you can use the esm package with .js files.
That rule should never run on .ts files, in other words.


fix(resizable-dialog): remove internal rxjs import

Description
Remove internal rxjs import.
Addresses rxjs import issue in https://github.com/Teradata/covalent/issues/1402#issuecomment-573593269
Test Steps

Run npm run serve
Navigate to http://localhost:4200/#/components/markdown-navigator/overview
View markdown navigator window demo and ensure it is still resizable.

General Tests for Every PR

[ ] npm run serve:prod still works.
[ ] npm run tslint passes.
[ ] npm run stylelint passes.
[ ] npm test passes and code coverage is not lower.
[ ] npm run build:lib still works.

Screenshots or link to StackBlitz/Plunker

LGTM 👍


Allow assining VLANs to regions

Environment

Python version:  3.7.1
NetBox version:  2.5.13

Proposed Functionality
Being able to assign VLANs to entire Regions and not being have to recreate and re-edit them in each site

Use Case
We usually assign the same major VLANs in entire regions

Database Changes
Add Region field in the VLAN object

External Dependencies
None

We're not currently accepting any feature requests that would require substantial changes to the data model. We might re-evaluate this at some point in the future.


Revert "Use semantics label for backbutton and closebutton for Android"

Reverts flutter/flutter#110873. Will create a bug with more detail

cc @math1man


Rendering Mob Crash

Hi, its me again :D
I've come with another issue. When I spawn spontaneus's mobs and wait for a while, the game crashes
crash-2023-05-27_18.15.31-client.txt
Crash report says theres a rendering issue so I hope you can fix it :)
Have a good day

I think sodium or indium etc. are incompatible with rendering this mob

I'm sorry for your effort but your mod's textures are so nice looking, the animations are good I dont want to uninstall this mod

I'm sorry for your effort but your mod's textures are so nice looking, the animations are good I dont want to uninstall this mod

its ok. If possible, I will try my best to solve it. Thank you for your support


Update to process get detailed usage

[New step to prepare Azure usage file and retrieve in alerts after it becomes available.]

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

ID: e301c2f1-5f0b-3151-cd8b-f3b4da3eb06c
Version Independent ID: e334683c-3dd5-fec3-331d-07a28ea73f62
Content: View and download Azure usage and charges - Microsoft Cost Management
Content Source: articles/cost-management-billing/understand/download-azure-daily-usage.md
Service: cost-management-billing
Sub-service: billing
GitHub Login: @bandersmsft
Microsoft Alias: banders

Thanks for your feedback @phsmiths. I'm investigating this with the Billing engineering team.

@phsmiths - Thanks for bringing this to our attention.
I'm going to assign this to the document author so they can review and update accordingly.

@phsmiths Can you please be more specific about exectly where in the article you think the new step to prepare Azure usage file is needed? And also, what you mean when you say retrieve in alerts after it becomes available?
Thanks.

https://github.com/MicrosoftDocs/azure-docs-pr/pull/227477

@phsmiths Yes, I see that there were changes to the Azure portal to download usage files for a Microsoft Customer Agreement. I've updated the article with new details as you've noted above.
Thanks very much for letting us know. I certainly appreciate it.
#please-close


No error is returned or thrown when chart fetching fails.

Chart fetching may fail for multiple reasons: database connection lost, chart is not found from the database etc. Currently null is returned and there might be some logging, but no good way to handle it in the code.
I had two ideas how to handle this:

Return object that contains chart and/or error
Throw error

First one seems like a better option to me, what do you think?

Edit: With brief look at the code I do not know where exactly it might have failed in such a way that it returns null even though there is a row in the database. It seems that xjog does not catch errors so those should bubble up, but it might be that some higher order functions eat those errors, await/async + higher order functions behave in mysterious ways sometimes.

Sorry for late response.
I think the standard solution is to have an optional callback and return a promise, if the callback has not been provided. It's idiomatic and both ways convey the same information.
getChart(charId: string , cid?: string): Promise<chart>; getChart(charId: string , cid?: string, cb: (err, chart) => void): void;
If there is a problem that is difficult to identify, turning on trace-level logging can help. There is a lot of logic, and as you noted, problems don't really bubble up. One notable case is a deadlock, which are not completely avoidable.

Main issue is that it is currently not possible to know programmatically if chart fetching failed of if chart does not exist (for example, it has been deleted from database for whatever reason).

When subscribing to a chart to show it to the user, we need to know if chart exists or not in the database as behaviour should be different in each case. Currently I do not think it is possible to determine that.
That is interesting, I was not aware of this. We added this mainly to get rid of code that tries machine A and if chart is not found, tries machine B etc, as it has worked from beginning for second and third level charts that have multiple options. But that has also then the same issue that there is a possibility for multiple matches.
I personally prefer to use explicitly returned errors (in golang style) to throwing errors or using callbacks. But I agree that throwing error is simpler.

Easiest first:

JS has its conventions and I think it's wise to follow them
I get the use case, but would recommend using URIs then (they probably
did not exist back in the day)
I would return null if it doesn't exist, and if there is a real error,
throw one

On Wed, 2 Oct 2024 at 21:45, Mart Välja @.***> wrote:

Main issue is that it is currently not possible to know programmatically
if chart fetching failed of if chart does not exist (for example, it has
been deleted from database for whatever reason).

When subscribing to a chart to show it to the user, we need to know
if chart exists or not in the database as behaviour should be different in
each case. Currently I do not think it is possible to determine that.
That is interesting, I was not aware of this. We added this mainly
to get rid of code that tries machine A and if chart is not found, tries
machine B etc, as it has worked from beginning for second and third level
charts that have multiple options. But that has also then the same issue
that there is a possibility for multiple matches.
I personally prefer to use explicitly returned errors (in golang
style) to throwing errors or using callbacks. But I agree that throwing
error is simpler.

—
Reply to this email directly, view it on GitHub
https://github.com/samihult/xjog/issues/16#issuecomment-2389449310, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AEZFPWPWK3YDT6SONMPNFBTZZQ5NPAVCNFSM6AAAAABOM7MRZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBZGQ2DSMZRGA
.
You are receiving this because you commented.Message ID:
@.***>

--
+358 50 475 3603


azure-keyvault-keys should use async safe context for http challenge

https://github.com/Azure/azure-sdk-for-python/blob/0e0d17e50a86b458b0dd9b459bbe1079b55254aa/sdk/keyvault/azure-keyvault-keys/azure/keyvault/keys/_shared/http_challenge_cache.py#L23-L25
Maybe we extract tracing_context in the core out of tracing and use it here.

Talked through this with Johan and Laurent, we couldn't come up with a scenario in which it's dangerous. A yield within the lock would be a problem, but in this case all we do while holding the lock is read or update a dictionary.


Improve events node buttons

octivgames (u/octivgames on Reddit) suggested that the events buttons are ok, but can be better.
I'm not the best at UI/UX side, so, I'm going to put this here to not forget about it and quote its suggestion:

Nice progress! Bit of feedback -- I think the expanding animations on the events box are cool (and I'm curious how they were done), but probably not the best UX. Moving buttons are frustrating. Maybe a popup tooltip with the text instead?
(...)
Awesome! UX is not so hard really. It's mostly just keeping in mind some basic principles like consistency, feedback, etc. There are some rather interesting psychological principles involved too, like "Gestalt". Definitely worth looking into.
And actually, now that I think about it more, it might be ideal to have a button to toggle between an "always visible" and "hover tooltip" mode for the text labels. If it's not too much work :D

I think the v0.2.0 editor is better. I'll reopen this issue if someone have problems with the design of the event node buttons.


add 'main' field to package.json

DO NOT MERGE
Opening this PR for discussion on a few issues that I ran into.
SDK Version: 0.1.0-alpha-4
Node: 10
1. Error importing the SDK
I was testing the SDK with CommonJS. I tried importing it using:
const Client = require("@paymentsds/mpesa").Client;

But it was throwing this error:
internal/modules/cjs/loader.js:638
    throw err;
    ^

Error: Cannot find module '@paymentsds/mpesa'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15)
    at Function.Module._load (internal/modules/cjs/loader.js:562:25)
    at Module.require (internal/modules/cjs/loader.js:692:17)
    at require (internal/modules/cjs/helpers.js:25:18)
    at Object.<anonymous> (/test-paymentsds/index.js:1:16)
    at Module._compile (internal/modules/cjs/loader.js:778:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
    at Module.load (internal/modules/cjs/loader.js:653:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
    at Function.Module._load (internal/modules/cjs/loader.js:585:3)

Adding this line to package.json file seems to have fixed the problem:
https://github.com/paymentsds/mpesa-js-sdk/blob/1f5553bc13efd7f1ce0c1f601cc8900d658403bf/package.json#L6
Not sure if this would be the best fix for the problem.
2. Error when calling receive()
After fixing the error described above, I ran into a second error when calling client.receive():
/node_modules/@paymentsds/mpesa/dist/service.cjs:118
          if (!Object.prototype.hasOwnProperty.call(intent, k) && Object.prototype.hasOwnProperty.call(this.config, correspondences[k])) {
                                                                                ^

TypeError: Cannot read property 'config' of undefined
    at map (/node_modules/@paymentsds/mpesa/dist/service.cjs:118:109)
    at Service.fillOptionalProperties (/node_modules/@paymentsds/mpesa/dist/service.cjs:129:18)
    at Service.handleRequest (/node_modules/@paymentsds/mpesa/dist/service.cjs:64:23)
    at Service.handleReceive (/node_modules/@paymentsds/mpesa/dist/service.cjs:49:19)
    at Client.receive (/node_modules/@paymentsds/mpesa/dist/client.cjs:31:27)
    at Object.<anonymous> (/index.js:16:8)
    at Module._compile (internal/modules/cjs/loader.js:778:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
    at Module.load (internal/modules/cjs/loader.js:653:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:593:12)

Here's my index.js file:
const Client = require("@paymentsds/mpesa").Client;

let client = new Client({
    apiKey: 'MY_API_KEY',             // API Key
    publicKey: 'MY_PUBLIC_KEY',          // Public Key
    serviceProviderCode: '171717' // input_ServiceProviderCode
});

let paymentData = {
    from: 'MY_PHONE_NUMBER',               // input_CustomerMSISDN
    reference: '11114',              // input_ThirdPartyReference
    transation: 'T12344CC',          // input_TransactionReference
    amount: '10'                     // input_Amount
};

client.receive(paymentData).then(function(r) {
    // Handle success scenario
    console.log(r);
}).catch(function(e) {
    // Handle success scenario
    console.error(e);
});

@edsonmichaque please check it. So, the global variable "this.config" is ignored inside of map method.
thanks @rosariopfernandes
`  fillOptionalProperties(opcode, intent) {
function map(correspondences) {
for (const k in correspondences) {
if (
!Object.prototype.hasOwnProperty.call(intent, k) &&
Object.prototype.hasOwnProperty.call(this.config, correspondences[k])
) {
intent[k] = this.config[correspondences[k]];
}
}
  return intent;
}

switch (opcode) {
  case C2B_PAYMENT:
  case B2B_PAYMENT:
    return map({ to: "service_provider_code" });

  case B2C_PAYMENT:
    return map({ from: "service_provider_code" });

  case REVERSAL:
    return map({
      initiator_identifier: "initiator_identifier",
      security_credential: "security_credential",
    });

  case QUERY_TRANSACTION_STATUS:
    return map({
      to: "service_provider_code",
    });
}

return intent;

}`

@rosariopfernandes, thank you for contributting. Putting "main" in package.json is a good path to follow in order to support Node.JS versions below v12, definitely it's a good decision to proceed so.
@eltonlaice and @rosariopfernandes  , the second error has to do with the scope of this reference, in ES6+ when using arrow functions it always points to the class instance itself, but it in ES5 it's specific to the scope of the nested function map, since it is not defined there it throws a TypeError. A solution to this is to bind this to self and change every this reference to self inside the nested function map, like this:
 fillOptionalProperties(opcode, intent) {
    const self = this;

    function map(correspondences) {
      for (const k in correspondences) {
        if (
          !Object.prototype.hasOwnProperty.call(intent, k) &&
          Object.prototype.hasOwnProperty.call(self.config, correspondences[k])
        ) {
          intent[k] = self.config[correspondences[k]];
        }
      }

      return intent;
    }

Please, try that and let me know if it works

@rosariopfernandes, we rename the PR to something broader than "add main field", something like "Fix CommoJS compatibility" since it intents to do it

@rosariopfernandes after fixing the error 2, run npm run build, to bulid commonjs module to dist, you will have to update manually the references of '.js' to '.cjs', because Babel doesn't do it automatically.

@edsonmichaque Thanks for the detailed explanation!
I did exactly as you instructed and it runs just fine now.
I updated the PR with the changes. It's ready to be merged.


Copy-FileToBCContainer: error if hostHelperFolder is changed in BcContainerHelper.config.json

Describe the issue
BcContainerHelper version  2.0.3
I've changed BcContainerHelper.config.json to change hostHelperFolder to "C:\ContainerHelper" instead of default value "c:\ProgramData\BcContainerHelper".
When I use Copy-FileToBCContainer an error occurs: "Access to the path 'C:\ProgramData\BcContainerHelper\662029ee-c613-4bc2-b4a1-82dc8e692388' is denied. at , : line 9".
I think the problem is "Copy-FileToBCContainer" uses the default hostHelperFolder instead of the new value changed.
This script ran successfully with NavContainerHelper and default hostHelperFolder in my old laptop.
Scripts used to create container and cause the issue
$containerName = 'BC17LATEST'
$assemblyProbingPath = "C:\Program Files\Microsoft Dynamics NAV\170\Service\Add-Ins\"
$dllFolders = @("C:\temp\add-ins\")

foreach ($dllFolder in $dllFolders) {
    Get-ChildItem -Path $dllFolder -Filter "*.*" -Recurse  | ForEach-Object {
        Copy-FileToBCContainer -containerName $containerName -localPath $_.FullName -containerPath (Join-Path $assemblyProbingPath $_)
    }
}

The source folder only contains a subfolder and a file. I think it run fine before change my laptop and install bccontainerhelper instead of navcontainerhelper, and I change the default hostHelperFolder
C:\temp>dir /s
 El volumen de la unidad C es OS
 El número de serie del volumen es: C486-3DEB

 Directorio de C:\temp

02/02/2021  08:57    <DIR>          .
02/02/2021  08:57    <DIR>          ..
02/02/2021  08:58    <DIR>          _Datanet
               0 archivos              0 bytes

 Directorio de C:\temp\_Datanet

02/02/2021  08:58    <DIR>          .
02/02/2021  08:58    <DIR>          ..
17/10/2018  09:29             4.608 DataNet_Zip.dll
               1 archivos          4.608 bytes

     Total de archivos en la lista:
               1 archivos          4.608 bytes

Full output of scripts
PS C:\Windows\system32>     foreach ($dllFolder in $dllFolders) {
        Get-ChildItem -Path $dllFolder -Filter "*.*" -Recurse  | ForEach-Object {
            Copy-FileToBCContainer -containerName $containerName -localPath $_.FullName -containerPath (Join-Path $assemblyProbingPath $_)
        }
    }

Copy C:\temp\_Datanet to container BC17LATEST (C:\Program Files\Microsoft Dynamics NAV\170\Service\Add-Ins\_Datanet\_Datanet)
Access to the path 'C:\ProgramData\BcContainerHelper\36b99af9-f7b2-4568-b5bd-9829007ae84e' is denied.
at <ScriptBlock>, <No file>: line 9
en Invoke-ScriptInBcContainer, C:\Program Files\WindowsPowerShell\Modules\BcContainerHelper\2.0.3\ContainerHandling\Invoke-ScriptInNav
Container.ps1: línea 44
en Copy-FileToBcContainer<Process>, C:\Program Files\WindowsPowerShell\Modules\BcContainerHelper\2.0.3\Misc\Copy-FileToNavContainer.ps
1: línea 35
en <ScriptBlock>, <sin archivo>: línea 3
en <ScriptBlock>, <sin archivo>: línea 2
Get-ChildItem : Access to the path 'C:\ProgramData\BcContainerHelper\36b99af9-f7b2-4568-b5bd-9829007ae84e' is denied.
En línea: 2 Carácter: 9
+         Get-ChildItem -Path $dllFolder -Filter "*.*" -Recurse  | ForE ...
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Access to the p...84e' is denied.:String) [Get-ChildItem], RuntimeException
    + FullyQualifiedErrorId : Access to the path 'C:\ProgramData\BcContainerHelper\36b99af9-f7b2-4568-b5bd-9829007ae84e' is denied.,
   Microsoft.PowerShell.Commands.GetChildItemCommand

Screenshots
If applicable, add screenshots to help explain your problem.
Additional context

does it happen all the time?
did it use to work?

Very strange, this bug should be fixed here: https://github.com/microsoft/navcontainerhelper/pull/1171
How do you configure the HostHelperFolder?
Could you share your bcContainerHelper.config.json?
Thanks

Ok, so your hostHelperFolder is not set.
Also you are trying to copy the folder and not the filename as it looks
(Copy C:\temp_Datanet to container BC17LATEST (C:\Program Files\Microsoft Dynamics NAV\170\Service\Add-Ins_Datanet_Datanet)
)

In order to set the hosthelperfolder, it must be specified in c:\programdata\bccontainerhelper\bccontainerhelper.config.json - that file does not move and hosthelperfolder cannot be set at runtime.
https://freddysblog.com/2020/10/10/bccontainerhelper-configuration/

This is the content of C:\ProgramData\BcContainerHelper\BcContainerHelper.config.json
The hostHelperFolder is setup ok, because when I create containers the extension subforders are create in C:\ContainerHelper\Extensions
{
    "use7zipIfAvailable":  true,
    "digestAlgorithm":  "SHA256",
    "mapCountryCode":  {
                           "ae":  "w1",
                           "br":  "w1",
                           "co":  "w1",
                           "ee":  "w1",
                           "fo":  "dk",
                           "gl":  "dk",
                           "hk":  "w1",
                           "hr":  "w1",
                           "hu":  "w1",
                           "id":  "w1",
                           "ie":  "w1",
                           "jp":  "w1",
                           "kr":  "w1",
                           "lt":  "w1",
                           "lv":  "w1",
                           "my":  "w1",
                           "pe":  "w1",
                           "ph":  "w1",
                           "pl":  "w1",
                           "rs":  "w1",
                           "ro":  "w1",
                           "sg":  "w1",
                           "si":  "w1",
                           "th":  "w1",
                           "tw":  "w1",
                           "vn":  "w1",
                           "za":  "w1"
                       },
    "hostHelperFolder":  "C:\\ContainerHelper",
    "timeStampServer":  "http://timestamp.digicert.com",
    "bcartifactsCacheFolder":  "c:\\bcartifacts.cache",
    "containerHelperFolder":  "C:\\ProgramData\\BcContainerHelper",
    "genericImageName":  "mcr.microsoft.com/businesscentral:{0}",
    "sandboxContainersAreMultitenantByDefault":  true,
    "defaultContainerName":  "bcserver",
    "usePsSession":  true,
    "defaultNewContainerParameters":  {                                    }
}

Ok, so your hostHelperFolder is not set.
Also you are trying to copy the folder and not the filename as it looks
(Copy C:\temp_Datanet to container BC17LATEST (C:\Program Files\Microsoft Dynamics NAV\170\Service\Add-Ins_Datanet_Datanet)
)

This is true, _Datanet is a folder, but I think somethink is wrong, because the folder in the error message 'C:\ProgramData\BcContainerHelper' should be "C:\ContainerHelper".
I tested it without folders and it run fine, so maybe only have a strange behavior about the folder name.
I think you can close this case, since I do your proposal in https://github.com/microsoft/navcontainerhelper/issues/1673#issuecomment-771475675 to replace Copy-FileToBCContainer by a shared folder for add-ins.
Thanks 👍

The reason for this is that the error comes from inside the container and since your containerHelperFolder is still c:\programdata\bccontainerhelper, then you get this error.
Mystery solved.

Ok, I understand, the folder "c:\programdata\bccontainerhelper" is the name inside the container, not the local folder in containerHelperFolder on host machine
👍


check out “nixvim”

https://github.com/juspay/nix-dev-home/blob/b1989154fb66ba37bf98f00761dfd32aaac99752/home/neovim.nix#L7

Scarce docs ... however I don't see any real benefit apart from the fact that it'll require more customisation from my part which I currently don't need.


Fix generics + nestedness in QueryMsg

Fixes and closes #1516
Doc comments in nested QueryMsg with generics caused schema gen errors (failed integrity check due to different schema structure). I removed the integrity check altogether. JSON Schema can represent the same Rust types in various ways and accounting for every possibility would just be maintenance hell. The representation could also change between versions of schemars and is pretty much its implementation detail.

Nice! Could you target the 1.1 branch and make a 1.1.x release with that patch?

Is that really needed though? I don't think this is a regression.

Is that really needed though? I don't think this is a regression.

okay, good. 1.2. will be out soon. I just thought it classifies as a bug. But we can also call it missing feature.


Implement and integrate adapters for data migrations

Summary of changes

Re-architected migration framework so that migrators use adapters to communicate with the underlying data store
Implemented an adapter that can communicate with a database implemented as a Python dictionary
Updated existing migrators, migrator creation script, and documentation accordingly
Implemented an adapter that can communicate with a MongoDB database—for demonstration purposes (will remove before merge)
"Regression": Migrators no longer contain a programmatically-consumable data structure that indicates which collections the migrator interacts with

An adapter is a Python class in which some predetermined operations (e.g. rename collection, find document) are implemented in a way that is specific to a given type of data store (e.g. Python dictionary, MongoDB database). Adapters allow the same migrators to be used with different data stores.
The nmdc-schema repository will contain a Python dictionary adapter, since the migration_recursion.py script is used to migrate a database that exists as a Python dictionary.
I expect the nmdc-runtime repository (specifically, the migration notebooks in it) to use a MongoDB adapter (which would be defined in the nmdc-runtime repository), since those notebooks are used to migrate databases that exist as MongoDB databases.

FYI - @brynnz22 and @turbomam: this is the (WIP) PR I want to discuss during tomorrow's meeting.

Nice work, @eecavanna
Let's think about how this code implements solutions that might be generalize-able to all LinkML users, and not just to NMDC users interacting with MongoDB.
I'd like for us to

feed this work back to the LinkML community if possible,
always be on the lookout for existing LinkML solutions, so we don't reinvent the wheel

I suspect that there isn't an existing LinkML solution corresponding to this code, but encourage you to become more involved in the LinkML community for the benefit of both NMDC and LinkML.
see also

LinkML Developers Meeting rolling agenda
LinkML Community Meeting rolling agenda

@pkalita-lbl @cmungall do you have anything to add to this?

These are great ideas @turbomam
I suggest though that Eric focuses on the functionality needed for NMDC, we can then look at aligning this with plans for a more generic common virtual database store abstraction in LinkML, see https://github.com/orgs/linkml/discussions/1818

Thanks @cmungall. That's a good path forward.
@eecavanna do you expect that this PR would interfere with my ability to dump database contents with pure-export and then validate them in the nmdc-schema environment? Or will this introduce new capabilities that would need to be added back into pure-export via an import?
see also

https://github.com/microbiomedata/nmdc-schema/issues/1621

Hi @turbomam, thanks for attending part of today's meeting. In response to your questions:

do you expect that this PR would interfere with my ability to dump database contents with pure-export and then validate them in the nmdc-schema environment?

No. The changes in this PR only come into play (in the nmdc-schema environment) when the migration_recursion.py file is processing the YAML-formatted data. As far as I know, that happens downstream from pure-export, which would have been used to generate that YAML-formatted data.
Regarding validation, I don't expect these changes to interfere. These changes only impact the data/data structure transformation process.

Or will this introduce new capabilities that would need to be added back into pure-export via an import?

I don't know (I haven't thought about this). I haven't had any other consumers of these changes in mind (other than the Migrator classes) as I have been designing and implementing them.

A note to myself (@eecavanna):
The following are still missing from this branch:

[ ] A place to register the Migration methods that utilize the adapter methods (the self._agenda dictionary was not designed for this—although maybe the design could be updated to accommodate it)
[ ] Determine whether the existing document-level transformation functions will be updated to use an adapter (now or later or never)

Still to do (note to self, @eecavanna):

[ ] Use terminology that is agnostic to the underlying data store (e.g. ~collection_name~ -> database_slot_name)

I may postpone that task for a future PR (TBD).

Based on recent comment I'll move to the new sprint. Please remove from sprint if not working on this.

Use terminology that is agnostic to the underlying data store (e.g. ~collection_name~ -> database_slot_name).

I'm a bit torn on this.

OK

Looks like some migrators were merged in today that do not fit into the current framework. I'll update those soon.

Thanks for reviewing this! Next, I'm going to test the MongoDB migrators locally (hopefully this afternoon); after which point I'll be ready for this to be merged in. I'll post a follow-up comment after I test them locally.

Hi @turbomam, I noticed a potential dependency-related issue today.
The MongoAdapter imports pymongo.
pymongo is currently a dev-dependency of this project; not a production dependency.
So, installing the nmdc-schema package from PyPI (once published with this branch) won't automatically install pymongo.
I consider that inconsistency ("mismatch") to be a bug.
Our options include:

Remove the MongoAdapter from this repository.
Make pymongo a production dependency instead of a dev-dependency.

I think option 1 will facilitate maintenance of the nmdc-schema package, as a whole. Downside: more difficult to keep the adapters' capabilities in sync over time (requires inter-repo coordination).
I think option 2 will facilitate maintenance of the adapters over time (both are in same repo). Downside: introduces a dependency that may not benefit most schema package consumers.
What do you think?

I would vote for 2. because I'm comfortable doing all of my work out of the nmdc-schema repo. But maybe too comfortable.
I mainly want an environment in which I can use the MongDB adapter without having to use dagster. Can I do that in a checkout of the nmdc-runtime repo, or iwth an import of the repo's code?
@mbthornton-lbl and I have been talking about potential other repos for data access. I think he would like to focus on methods that don't require any authentication, but I don't know how rigid he feels about that.
I would also like to include @sierra-moxon in this discussion.

Next, I'm going to test the MongoDB migrators locally (hopefully this afternoon); after which point I'll be ready for this to be merged in. I'll post a follow-up comment after I test them locally.

I finished testing the MongoDB migrators locally (i.e. I ran the unittests I have since committed to this branch).
Outstanding tasks (these are blocking the merge):

[ ] Designate pymongo as a production dependency (that's option 2 above)
[ ] Confirm that I can import MongoAdapter from outside this project (i.e. I would be using from nmdc_schema.migrators.adapters import MongoAdapter in a Jupyter notebook in nmdc-schema)

@mbthornton-lbl and I have been talking about potential other repos for data access.

I think he's focusing on things that access data via HTTP APIs; as opposed to focusing on things that access the underlying database directly. The adapter falls into the latter category.

I mainly want an environment in which I can use the MongDB adapter without having to use dagster. Can I do that in a checkout of the nmdc-runtime repo, or iwth an import of the repo's code?

I'm interpreting these questions as (in my own words):

If the adapter were to live in the nmdc-runtime repo, how could I use it in my nmdc-schema workspace?
If the adapter were to live in the nmdc-runtime repo, would I have to run Dagster in order to use the adapter?

Here are my responses:

There's an nmdc-runtime package on PyPI. I think you would be able to import that and get access to the adapter through that. However, nmdc-runtime already depends on nmdc-schema, so the result may be a circular dependency. I don't know how Python/pip/Poetry handles that.
No, Dagster wouldn't be involved.

On a side note, we are talking about using the adapters in more contexts than I have had in mind while implementing them. The only context I had in mind was the migration context. They might prove to be useful in other contexts also, but I'd prefer to explore that separately from this PR so that it doesn't delay the merging of this PR, since the implementation of migrators is currently blocked by the absence of the adapters (feature) in the berkeley-schema-fy24 repo.

All that's left for this branch before I'll be ready for it to be merged in is:

Designate pymongo as a production dependency (that's option 2 above)

I'm ready for this to be merged in (I won't use it until next week, though).


RFC: Allow js to reveal form input errors

Jira
http://vjira2:8080/browse/BDS-1284
Summary
Adds an event listener to bolt inputs for a new custom showerrors event.
Details
Currently, Bolt's HTML5 form validation issues are invisible until a user blurs an input field.  Additionally, only user input works for this-- scripts that fire the onblur event on an input intentionally do NOT reveal these errors (see http://vjira2:8080/browse/WWWD-2345 for an explanation of why we did that).
The goal of this PR is to add a way for js to intentionally reveal validation errors.  The primary use case would be when submitting a form-- if there are validation errors when the user submits, we could stop the submission and fire the showerrors event on any invalid field.
Questions for reviewers

Is a custom event the best way to allow javascript to show errors for a given field?
What's the best way to allow form submission to trigger this event for all invalid fields?  I'm thinking a declarative solution where you'd add a class like js-bolt-validate-before-submit to a <form> element.  If a form with this class contains any .c-bolt-input:invalid elements, you cancel submission and fire the showerrors event on those invalid elements.

How to test
On this branch, run the following script.  It should display red bolt form validation errors for the first invalid field on the page.
const invalidInput = document.querySelector('.c-bolt-input:invalid');
const showerrors = new CustomEvent('showerrors');
invalidInput.dispatchEvent(showerrors);

@remydenton just wanted to mention that I’m taking a look at this. Should hopefully have some feedback for ya tomorrow

I think I see where you're going/agree with this:

I think the code smell I'm sensing with this likely has to do with the not quite declarative but also the not quite imperative spot direction this is going

However, I don't really see the value/purpose of a "revalidate" property.  All fields should always validate on user-initiated blur (as they do already) and form submit (which they can't yet, which is the purpose of this PR).  Is there a compelling reason to make that configurable that I'm missing?

Dynamically injected input fields or entire forms being added dynamically wouldn't work with this approach, right?

Correct-- just like none of the existing form javascript will work in that scenario.  That needs to change as soon as we can (though it's a long outstanding issue and is separate from the goals of this PR).

Also FWIW, I'm not opposed to open-ended APIs via the custom event emitted route... I just feel like we should probably be the one emitting that custom event and having external JS optionally hook in if needed.

I agree with this, it just requires our form elements to be communicating with each other in a way that requires substantial re-writing of the form javascript.
Long story short, maybe this isn't the right approach, but this use case needs to be supported in any form re-writing we do.  We're also at a point where that re-writing has been delayed so long that it's becoming very difficult to create something that's acceptable on the production end of things.  Hopefully that will change soon, but we've been hearing that for a long time.
Finally:

Was there a specific reason why we didn't opt to use an off the shelf form validation library (ex. https://hyperform.js.org/docs/low_level_api.html)

No specific reason, other than that HTML5's validation API was adequate for the original/basic requirements when we first shipped forms.

I think I see where you're going/agree with this:

I think the code smell I'm sensing with this likely has to do with the not quite declarative but also the not quite imperative spot direction this is going

However, I don't really see the value/purpose of a "revalidate" property. All fields should always validate on user-initiated blur (as they do already) and form submit (which they can't yet, which is the purpose of this PR). Is there a compelling reason to make that configurable that I'm missing?

Are we 100% sure that all form fields on all forms always validate on blur vs for example, just form fields that are required?
I just want to make sure we’re accounting for every site’s different use cases vs just one site / just one form on one site’s use case.
For example:

Not all form fields are always required on every form: https://www.pega.com/ask-a-question
Not all form fields on every site immediately validate onblur by design: https://accounts.pega.com/register and possibly https://accounts.pega.com/user/login

I’m fine having us add this as an interim solution. I just want to make sure we can account for new use cases if/when things pop up; hence the declarative approach + smart defaults

Are we 100% sure that all form fields on all forms always validate on blur vs for example, just form fields that are required?

I believe the design intention is for validation failures to appear on blur regardless of what kind of validation problem it is (e.g. empty required field, invalid email pattern, etc).  @mikemai2awesome may be able to speak to whether there should be exceptions.
Of course, this still allows for fields that are not required-- if they're left empty, then there are no validation errors to reveal on blur.
And yes, I very much intend this to be an interim solution until the form javascript gets overhauled.  When that time comes, we can/should discuss the ideal behavior and architecture to get there.

@remydenton just double checking, can this get released as part of v2.5.0 or does this need to be fast tracked?

v2.5 is fine, thanks @sghoweri


MaterialCommunityIcons give question mark

<MaterialCommunityIcons
name="message-processing-outline"
size={20}
/>

gives me ? instead
Environment
React native - 0.59
react-native-vector-icons - 6.4.2

I have the same but only for iOS. I managed to fix the issue on android by adding apply from: "../../node_modules/react-native-vector-icons/fonts.gradle" to my buld.gradle file...

I tried using a qr icon and it gives me a question mark too
Apparently, the dictionary page is not synced with the current font so there's a couple of icons not available

MI has since been updated


[CRO-405] Problem: no readme/information for PoGSD multisig demo

Solution: Update multisig-demo docs with examples and pictures.

Maybe open an images folder to keep the images?

Done :)


Add time/date to webapp

Hi, thanks for developing this tool. I have a suggestion: Display the time and date of a measurement at the top of the webapp instead of just in the JSON menu

Thanks for the suggestion @kwaaak! It should be already online.


Update CONTRIBUTING.md

After adding awaiting and moredataneeded labels on the PR after 19 days there was no stale label and no comment from the bot.


add reward pallet modifications

Summary of changes
Changes introduced in this pull request:
-Scaffold for pallet modifications for rewards (AP VAnchor updating, etc)

@saiakilesh good to merge if you review and give it the go ahead.


Documentation: Add Building.md and walletconsole/README.md.

Description
Documentation only, new markdown files:

Building.md
walletconsole/README.md

Testing instructions
Types of changes

Documentation only

Checklist

[x] Prefix PR title with [WIP] if necessary.
[x] Add tests to cover changes as needed.
[x] Update documentation as needed.

Building.md and walletconsole/README.md are copy from http://developer.trustwallet.com/? no need to copy it here, we can just put reference link here

Building.md and walletconsole/README.md are copy from http://developer.trustwallet.com/? no need to copy it here, we can just put reference link here.

Yes...  Duplication is not good (likely will diverge over time), however, I think it is valuable that build instructions for a project are enclosed within the same repo.  Like for someone who uses only walletcore, clones only that repo, doesn't need to deal with docs for the whole Trust Wallet infrastructure docs.
So I don't know what's more important: self-repo-contained doc, or a complete centralized one (developer.tw.com), or no duplication?

I would suggest to link to developer.trustwallet.com and keep most of the instruction there.

we previously put them under the docs folder

I would suggest to link to developer.trustwallet.com and keep most of the instruction there.

OK, let's have developer.trustwallet.com the primary documentation place.

Updated as suggested, only pointers to developers.trustwallet.com.  Please approve.


Remove env prefix from stored path if present

We are no longer specifying the environment via the URI path; instead, environment is specified via the domain. Update the code to remove the environment prefix if it is present in the URI path.

Review checklist

[ ] First, the most important one: is this PR small enough that you can actually review it? Feel free to just reject a branch if the changes are hard to review due to the length of the diff.
[ ] If there are any migrations, will they the previous version of the app work correctly after they've been run (e.g. the don't remove columns still known about by ActiveRecord).
[ ] If anything changed with regards to the public API, are those changes also documented in the apiary.apib file?
[ ] Are all the changes covered by tests? Think about any possible edge cases that might be left untested.

@camallen because we can reliably expect the .path method of the URI object to return a string with a leading /, I'd prefer to use .start_with? - to me this is simple, clean and straightforward.
As for the use of slice!, maybe could use sub instead and make the update more explicit? Like so
      uri_path = uri.path

      env_prefix = '/' + Rails.env
      if uri_path.start_with? env_prefix # remove env prefix if present
        uri_path = uri_path.sub(env_prefix, '')
      end

I'm going to go ahead with the merge since the discussion over slice! vs sub isn't really worth holding up this PR over 😎


allergies: replace a match -> bool with a comparison

It feels a bit odd to match when the result is going to be a boolean,
and doesn't feel like an idiomatic use of matching.

I like the additional parens.

parens it is.


a fix to issues #4217

Description
Fixes issues/4217
Use blue icon in light theme and white icon in dark theme

Sorry about the unnecessary changes. Thanks for guide from ashishkumar468.  I will try to fix it with less changes to the project.

Codecov Report

Merging #4373 (30a88f9) into master (950205a) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head 30a88f9 differs from pull request most recent head ec58591. Consider uploading reports for the commit ec58591 to get more accurate results

@@            Coverage Diff            @@
##             master    #4373   +/-   ##
=========================================
  Coverage     10.21%   10.21%
  Complexity      469      469
=========================================
  Files           342      342
  Lines         13104    13104
  Branches       1072     1072
=========================================
  Hits           1338     1338
  Misses        11698    11698
  Partials         68       68

Continue to review full report at Codecov.

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

I replace the ic_share_blue_24dp.xml with ic_share_24dp.xml and set its color to attr/aboutIconsColor

Hi @finalrepublic , Thanks for the PR, looks good to me, can you follow the PR template, please. Also since this is a UI bug fix, please attach screenshots for dark and the usual theme.


Implement wildcards option

This PR adds the useWildcard enhancement discussed in #112.

name this option wildcards instead of useWildcards

Sure, no problem!

ignore escaped wildcards, e.g. ignore them in the following keyword: lor\?m, even if wildcards is true.

There is a problem with that...

If you pass a keyword of lor\?m, the escape is processed and the resulting string becomes lor?m which is indistinguishable from an unescaped lor?m.
If we double escape the keyword (lor\\?m), we would then have to remove the extra backslash during keyword processing, or the search would be performed against lor\?m and not lor?m. I'm not sure if removing the backslash would be a good idea, but it shouldn't harm anything as long as we are only doing it for that specific pattern (\\? or \\*).
Alternatively, maybe we could "escape" it with a forward slash?... this isn't ideal and may be confusing to both the user and developer - lor/?m.

What do you think?

Alternatively, maybe we could "escape" it with a forward slash?

I'm against this option, since it's not common.

If we double escape the keyword (lor\?m), we would then have to remove the extra backslash during keyword processing, or the search would be performed against lor?m and not lor?m. I'm not sure if removing the backslash would be a good idea, but it shouldn't harm anything as long as we are only doing it for that specific pattern (\? or \*).

If you look at the escapeStr function you'll notice that it does exactly that; adds two backslashes for sensitive characters like *. If the user passes a keyword like lor\\*m it'll be lor\*m in the plugin and thus be equivalent to the result of escapeStr. The point is, if you pass this to this function it'll still add another \, which is of course unnecessary. But from my point of view, this is all that needs to be done to allow passing escaped wildcards even if the wildcards option is true.

Hmm, well the setupWildcardsRegExp function is called before the escapeStr function to catch the wildcards before they are escaped... I'll look into this more later today.

In the last update, the wildcards option now has three settings:

"disable" (default)
"enable" - wildcards only target non-whitespace characters.
"includeWhitespace" - wildcards target all characters

So to get the demo in #119 working, you have two choices (see https://jsfiddle.net/Mottie/6kqr1d88/4/):

Set wildcards to "enable" and use the keyword `"Hello? World" ("?" matches the comma or any punctuation, but not the whitespace).
Or, set wildcards to "includeWhitespace" and use the keyword "Hello*World".

But, setting the option to include whitespace does have some consequences! if for example you use the keyword "lorem*ipsum", it will also mark "lorem dolor ipsum". See this demo: https://jsfiddle.net/Mottie/6kqr1d88/3/

First off, I incorrectly named an option in my last comment... it's not "includeWhitespace", it should be "includeSpaces".... maybe I should shorten this option to "withSpaces"? Or internally only look for "space" in case the wrong term is used?
I'm also starting to think we might need to change the "?" wildcard to match zero or one characters instead of only one character. That way you could use "World?s" to mark World's and Worlds as discussed in https://github.com/julmot/mark.js/issues/119#issuecomment-279233505.

I'm for "withSpaces"
I'd vote for naming it "enabled" and "disabled" instead of "enable" and "disable". What do you think?
I already thought that ? is open for either one or no match.  I'm doing some tests in the next hours and will come back with some review.

The disabled value was tested in the wildcards.js file (line 31); is that good enough, or should I add more?
HTML

        Lorenzom ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod
        tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
        Lorem ipsum dolor sit amet, consetetur sadipscing elitr. Loriem ipsum
        dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor
        invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
        Lorm ipsum Lorum ipsum, et Loram ipsum. Lor?m ipsum. Lor*m ipsum.

Script
new Mark($ctx4[0]).mark(["lor?m", "Lor*m"], {
    "separateWordSearch": false,
    "wildcards": "disabled",
    "done": done
});
// ...
it("should find wildcards as plain characters when disabled", function () {
    expect($ctx4.find("mark")).toHaveLength(2);
});


migrate to styled system 5

https://styled-system.com/guides/migrating/#migrating-to-v5

@gesquinca the build is failing because of no font-family. Does the test need to get removed to check for a font family now?

@gesquinca I'm not sure where it is coming from, but Heading has a margin: 0 that is getting applied and wiping out the existing top/bottom margins that already exist.

@gesquinca It looks like the font family for Labels has been changes to monospace - is that intentional?

@gesquinca - Looks like inputs don't have their original drop shadows anymore - is that intentional?

@gesquinca Also for Heading any m props that get added to the component aren't getting honored because there is a margin: 0 that is getting applied last. Not sure where it's coming from.

@gesquinca the build is failing because of no font-family. Does the test need to get removed to check for a font family now?

Yes, font-family needs to get applied to a common parent and cascade down. Not the individual components.

@gesquinca I'm not sure where it is coming from, but Heading has a margin: 0 that is getting applied and wiping out the existing top/bottom margins that already exist.

I think I fixed this now.

@gesquinca Also for Heading any m props that get added to the component aren't getting honored because there is a margin: 0 that is getting applied last. Not sure where it's coming from.

I think this is resolved now, but we should look at it together.


The Button ‘Aktuelle Parameter anpassen’ does not work for ‘Zeit bis Tod möglich’

If you look at the attitude towards dying possibly after... to the maximum value. You then start the simulation. If you then restart the simulation using the current parameters, the old value is not entered correctly.

yes i kinda noticed. because the value in the config changes the value from the slider. which should be implemented more cleanly perhaps. will do


Implementing watermodel.py

Hi, thanks for your great work!
But I get some problems when I am running watermodel.py. This confuses me for a long time. I don't know how to solve it.
Traceback (most recent call last):  File "UnderWaterZeroShot.py", line 168, in     test(args)
File "UnderWaterZeroShot.py", line 155, in test
loss.backward(retain_graph=True)  File "/mnt/petrelfs/zhangyiting/anaconda3/envs/nerf-pytorch/lib/python3.8/site-packages/torch/_tensor.py", line 363, in backward    torch.autograd.backward(self, gradient, retain_graph, create_graph, inputs=inputs)
File "/mnt/petrelfs/zhangyiting/anaconda3/envs/nerf-pytorch/lib/python3.8/site-packages/torch/autograd/init.py", line 173, in backward
Variable._execution_engine.run_backward(  # Calls into the C++ engine to run the backward passRuntimeError: one of the variables needed for gradient computation has been modified by an inplace operation: [torch.cuda.FloatTensor [1, 64, 64, 64]], which is output 0 of ReluBackward0, is at version 1; expected version 0 instead. Hint: the backtrace further above shows the operation that failed to compute its gradient. The variable in question was changed in there or anywhere later. Good luck!

I found in this env "torch==1.8.0+cu111", everything will be fine.  Additionally, I localized the error related to SKconv part.

nn.ReLU(inplace=True) -> nn.ReLU(inplace=False)


Services: first build: abs added

This is noarch, so it doesn't matter that the other platforms are failing.


A package reference version inconsistent issue - custom action

Describe the bug
Actually @luhan2017 found this issue when she helped me test the custom action feature, and it is a recent change.
@srinaath Thanks for your effort on this as well. : )
When testing custom action, after eject runtime, the package reference version of the Microsoft.BotFramework.Composer.CustomAction.csproj file in the custom action folder shows "4.9.0-rc4", which is inconsistent with the package reference versions of the Microsoft.BotFramework.Composer.WebApp.csproj file in the azurewebapp folder and core folder. This will generate conflict when executing the command to generate the schema file, and testing custom action fails.

Version
latest master branch.
Browser

[x] Chrome

OS

[x] Windows

Expected behavior
The package reference version of the Microsoft.BotFramework.Composer.CustomAction.csproj file in the custom action folder should be "4.9.0" for this release, consistent with the other package reference versions.
Additional text
Changing the version to 4.9.0 solves the conflict and testing custom action successfully.

thanks for spotting and creating this ticket @zxyanliu


Update students.txt

Added an X at the end of my name.

You have a small conflict, can you fix it ?

Fixed it


Installing conda as root during setup locks the user from properly installing environments

Error

WARNING conda.core.path_actions:verify(963): Unable to create environments file. Path not writable.

Solution
sudo chmod -R 775 /Users/$YOUR-USER/.conda

Conda no longer auto-installed since this should be user pref


JS - Collect and execute actions at doc and pages level

the goal is to execute actions like Open or OpenAction
can be tested with issue6106.pdf (auto-print)
once #12701 is merged, we can add page actions

/botio test

/botio test

/botio makeref


Fix a typo in settings.gradle

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

R: @udim

Run Python Postcommit

cc: @fredo838


Add picture of Dragonfly on Lavender from Wikimedia Commons

Description
A golden dragonfly on top of lavender flowers
Image Information

Author: HISANARI KUNIMOTO
License: CC0
Source: Webpage, Original image

Submitter Checklist

[x] Submitter has reviewed the Image Requirements
[x] Squashed commits with git rebase -i (if needed)
[x] Updated the respective meson.build and xml.in files

Alternately, perhaps this could go under a Flora  category or similar instead in the xml.in file?  This would cover plants, fungi, and lichen.


Only mouse over one feature at a time

This should fix #3568. It stores the currently hovered layer in _hoveredLayer and only checks that for mouse events until mouseout.

Nice! Looks good to me.


(Bug) unhandled exception and permissions api

https://sentry.io/organizations/gooddollar/issues/1779714426/events/?environment=production&project=1829798&referrer=alert_email

Firefox has permissions api but doesn't support all options to query (camera is one of them)
https://stackoverflow.com/questions/53147944/firefox-permission-name-member-of-permissiondescriptor-camera-is-not-a-vali
There wasn't mentioned in PermissionAPI docs that .query() could throw so that why we haven't wrapped it into try catch. That because we having unhandled rejection in FF
I propose to do the following:

wrap .query() call into try catch
on catch resolve state to Undetermined (like if there's no permissions api support)


Missing explanation of what the plugin does

There is no real explanation in the README of what features the plugin actually provides. Does it provide a Terraform scaffolder action? Ingest Terraform state files as catalog entries? Its not until the screenshot at the end that you can kind of deduce what the plugins capabilities are but its still not really spelt out.

thanks for flagging it @niallthomson ... we will add more details to the README


Add option for disabling gRPC support

Since not every application might need the gRPC features for communicating with an Executor, there should be an option to disable the feature and adjust the list of compiled sources based on that.
Adding the option would serve as a workaround for #85, although the underlying root cause should also be dealt with to support proper cross-compilation.

This issue has been resolved by #108 :)


Fix ClusterOperator event when version changes

Don't show ugly JSON diff when only the operator version changes.
Before this PR, when only Versions changed in a ClusterOperator:
Status for clusteroperator/csi-snapshot-controller changed: {"conditions":[{"type":"Degraded","status":"False","lastTransitionTime":"2020-04-29T11:32:49Z","reason":"AsExpected"},{"type":"Progressing","status":"False","lastTransitionTime":"2020-04-29T11:34:04Z","reason":"AsExpected"},{"type":"Available","status":"True","lastTransitionTime":"2020-04-29T11:34:04Z","reason":"AsExpected"},{"type":"Upgradeable","status":"True","lastTransitionTime":"2020-04-29T11:32:49Z","reason":"AsExpected"}],"

A: relatedObjects":[{"group":"","resource":"namespaces","name":"openshift-cluster-storage-operator"},{"group":"","resource":"namespaces","name":"openshift-cluster-storage-operator"},{"group":"operator.openshift.io","resource":"csisnapshotcontrollers","name":"cluster"}],"extension":null}

B: versions":[{"name":"csi-snapshot-controller","version":"v2.3.4"},{"name":"operator","version":"v1.2.3"}],"relatedObjects":[{"group":"","resource":"namespaces","name":"openshift-cluster-storage-operator"},{"group":"","resource":"namespaces","name":"openshift-cluster-storage-operator"},{"group":"operator.openshift.io","resource":"csisnapshotcontrollers","name":"cluster"}],"extension":null}

With this PR:
Status for clusteroperator/csi-snapshot-controller changed: status.versions changed from [] to [{"operator" "v1.2.3"} {"csi-snapshot-controller" "v2.3.4"}]
Related to https://bugzilla.redhat.com/show_bug.cgi?id=1829320

/lgtm

/approve


Zip Deploy fails for branches other than master

I think this is similar to issue #3111 but the fix there isn't working for me.  I have an Azure function app (built on PowerShell) that fails to deploy via DevOps Pipeline when deploying to a branch other than master.
ChangeSetId(Test) does not match 3305e1c221984b2692fb5e6fff91f60e, 'master' or 'HEAD'
I've found that if I use the 'Disconnect' option in the Azure portal -> Function app -> Deployment Center, then run the pipeline again it will succeed.  The Deployment Center will then update to show it's connected but references the branch of master even though the deployment is from my 'Test' branch.  See the picture below.

I checked c:\home\site\deployments\settings.xml and it does correctly reference the 'Test' branch.
Any help is appreciated!

One other thing I just noticed is when I click on the Deployment Center page, it shows the correct branch for 1-2 seconds like this:

then it switches back to this:

If I click the refresh button at the top or refresh the entire page, the same thing happens again where it shows the Test branch, then changes to master.

Hi
If the problem persists and is related to running it on Azure App Service, please open a support incident in Azure:
https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request
This way we can better track and assist you on this case
Thanks,
Joaquin Vano
Azure App Service


add value to eventProperties

adding value to  eventProperties is exest

Hey @mohamedaitbella, can you explain this more?

when tracking change on text field i could not have the value  of the text field so i  added this line  so i can have the value on /ahoy/events

Hey @mohamedaitbella, I think this will lead to Ahoy accidentally storing sensitive information. Due to that, I don’t think it makes sense to merge. Regardless, thanks for submitting it

oh, I totally  get your point   thanks for fast replay


Feat(ai huggingface)

Summary

Checklist

[x] The Pull Request has tests
[x] A changelog file has been created under changelog/unreleased/kong or skip-changelog label added on PR if changelog is unnecessary. README.md
[ ] There is a user-facing docs PR against https://github.com/Kong/docs.konghq.com - PUT DOCS PR HERE

Issue reference

AG-70

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

@srb3 seems some tests arefailing 🤔

@fffonion I have updated the expected responses in the spec file to match the changes made here


Home screen options for managing multiple books

Configuration: Windows 10, Lute v. 3.4.2 installed via pip
Hello. I was recently making changes to multiple books, and it took a while to do everything book-by-book. That led to the following idea, and your thoughts would be welcomed.
The user could save a nice amount of time and energy if the "Home" screen and the "Book Archive" screen included options for rapid management of multiple books. The below features may be useful:

(for the "Home" screen) "Archive Selected Books" and (for the "Book Archive" screen) "Unarchive Selected Books": this option could turn the book listing into a checklist, letting the user choose multiple books to archive or unarchive, respectively. A confirmation dialogue before the decision is finalised would be great, to ensure that the user did not make a mistake.
"Delete Selected Books": this option could turn the book listing into a checklist, letting the user choose multiple books to delete, with a confirmation dialogue given before the decision is finalised.
"Add Tags to Selected Books": this option could turn the book listing into a checklist, letting the user choose multiple books to add specific tags to.
"Remove Tags from Selected Books": this option could turn the book listing into a checklist, letting the user choose multiple books to remove specific tags from.
"Remove all Tags from Selected Books": this option could turn the book listing into a checklist, letting the user choose multiple books to remove all tags from (alternatively, an option to "Remove all Tags" could be given in the screen that would appear after the user would choose the aforementioned "Remove Tags from Selected Books" option).

Thank you very much for your work. I think that Lute is great and use it every day.

Hi @Inquisitor-Ignotorum - thanks for the notes, this makes sense. 👍
I may need to un-complicate some of the code first, so I've opened a new issue, https://github.com/LuteOrg/lute-v3/issues/442.  It's related to adding the checkmarks to the bookmarks ... this code is sometimes hard to understand!
Thank you very much for the detailed write up, appreciated.  Cheers!


Interactive filtering in thread does not show filter results in thread

Description
When using interactive kubectl with filtering in Slack. Botkube replies with the results and starts a thread to allow for running other filters.
When using this thread to run the filter, filtered results appear in the main section of the channel and NOT in the thread. This is confusing because in the first instance you think filtering is not working.
See this screenshot:

Expected behavior

Further filtered messages should appear in the thread.
Actual behavior

Further filtered messages are appearing the channel's main section.
Steps to reproduce

Set up Botkube in Slack.
Run @Butkube kc to start interactive kubectl.
Add a filter in the filter input box.
Enter the started thread.
Add another filter text and hit enter.
The filter result will show in the main channel section instead of the thread.

I reproduced this for interactive commands, but not with the normal ones. So, If I start with Botkube kc, this issue happens, but if I type Botkube describe nodes and continue, it works as expected. See below.
With @Botkube kc

With `@Botkube describe nodes