Dotpay a github paid task platform using DOT payment

Project Abstract
DotPay is a platform that supports paid tasks to complete open-source projects on Github.
For which grant level are you applying?

[x] Level 2:  Up to $50,000, 3 approvals

Application Checklist

[x] The application template has been copied, renamed ( project_name.md) and updated.
[x] A BTC or Ethereum (DAI/USDT) address for the payment of the milestones is provided inside the application.
[x] I have read and acknowledged the terms and conditions.
[x] The software delivered for this grant will be released under an open-source license specified in the application.
[x] The initial PR contains only one commit (squash and force-push if needed).
[x] The grant will only be announced once the first milestone has been accepted.

 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.

@AdaLam7 Thanks for the application. At a first glance, this sounds similar to dot marketplace application. I would recommend you take a look at their proposal and outline in your application how/if it compares and whether there is room for collaboration/reuse. By simply checking their github activity, the @WowLabz team seem to be making some progress.

I think we are very suitable for cooperation with dot marketplace, but these two projects are still very different. First, dotpay will focus on open-source payment collaboration, deep integration with GitHub, closer to end-users, but dot marketplace more general.

Hi @AdaLam7, could you

remove the BTC amounts (USD amounts will be converted to BTC at time of payment),
add a Development Status section (your roadmap mentions that some functionality is already available),
have a look at the Development Roadmap in our application template (it contains info on what each milestone should include (e.g. tests)),
have a look at the What activities/positions do you fund? section of our FAQs (for example, we don't fund server costs and marketing), and
send links to relevant code repositories or related activities by you or your team to grants at web3.foundation?

Please note that all questions are ideally addressed by modifying the application document, as it becomes the basis for the contract when a grant is signed.

@Noc2 thanks a lot for your suggestion, The project is under development so that there is no website that can be displayed. You can see our homepage in about two weeks. You can try most of the functions after a month and a half.  I will add milestones details, and remove the design phase first~

@AdaLam7, why did you change the cost of M1? The total and the sum of the milestones now don't add up anymore.

@AdaLam7, why did you change the cost of M1? The total and the sum of the milestones now don't add up anymore.

@AdaLam7, why did you change the cost of M1? The total and the sum of the milestones now don't add up anymore.

@semuelle sorry about that, @AdaLam7 hadn't slept all night and changed the number by mistake 😄

@semuelle Thank you for your suggestion, I added the milestone details~

@vimerr plz rebase all the commits.

Thanks for the application. In general, I would love to see a proper incentivization of contribution via git (not only github, but also things like https://radicle.xyz/). However, you milestones currently still are missing a lot of details, see https://github.com/w3f/Grants-Program/blob/master/applications/application-template.md#development-roadmap-nut_and_bolt and we usually don’t fund things like the initial design phase. Let us know once we should take another look at the application.

Hi @Noc2  We have added relevant information about Development Roadmap , Ecosystem Fit and Development Status ,and have also submitted the Google Form. could you please have a look and give me some suggestions ? I'd really appreciate it if you could let me know your opinion about it in time.  Looking forward to hearing from you soon.

@Noc2 Submit a google form because we want to provide some member information privately. I add the deliverables 0a-0d, please check it out, thank you ：）

Hi@Noc2，thanks for your suggestions, we've added relevant information about milestones.
About the question of " Do you want to apply in private instead and close the current application? "
Please contiue  the current application
To be honestly, it is the first time for our team to apply  grant, and we want to  supply team specific infoemation privately,
so in our grant application we  indicated the team specific infoemation will be sent in private and then we offered it by Google Form.Please contiue the current application and I would appreciated and please accept our apologies for any inconvenience caused.
And we have added the deliverables 0a-0d about mlestones，it would be very helpful if you could give us some review suggestions.Thanks again and have a nice day，looking forward to hearing from you soon.

Thank you very much for your detailed suggestions, we will provide more detailed information as required

Everything funded by a W3F grant should be useful to the ecosystem as a whole
For example, an email notification module is a very important contact channel for a developer who has never used Polkadot to withdraw DOT. Will the foundation fund the development of such a module? If w3f doesn’t fund a similar feature, I will delete it from the milestone. I personally think this is a very important way to expand ecological end users.

Hi @Noc2 @semuelle I update the milestone:

Delete the milestone 4, split the test work to each milestone.
Explained the value of each work to the ecology.
Merged shorter milestones into one

Now we have three very clear milestones.
After all the milestones are completed, the website will launch a complete open-source task payment function. Thank you again for your patience and guidance. If there are any other issues, we will do our best to adjust in time.

Thanks for the update, @AdaLam7. We will review very soon. Could you remove the .gitignore file from the PR, though?

Could you clarify what step 5 in the process (trigger on chain transfer) looks like? I understand that in step 4, Alice triggers a notification to Bob, and in step 6, Bob withdraws them. What is required in between? Wouldn't it be possible to trigger the notification and the payment in one step?

Could you also clarify what you mean by "Module"? In the context of Substrate/Polkadot, this usually refers to a pallet.

If I understand correctly, only the admin of the repository can recharge the wallet and create paid tasks, correct? I could see a situation where others might be interested in funding specific issues. For example, on StackOverflow anyone might offer a bounty for an open question, not just the original poster.

Could you increase the minimum test coverage on each milestone? 50% is rather low.

trigger on chain transfer means dotpay platform call polkadot API to transfer DOT. I think notification and payment can be one step, it better notified after the payment is successful.
Module means dotpay server function, for example a HTTP handle, or something like pallet, but now we only needs polkadot SDK, don't need create a pallet.
Not only the repository owner can create paid tasks, I think anyone can trigger a payment when his account has enough DOT, and the repository is already active a webhook to dotpay. We will support StackOverflow reddit ... in the feature.
I will increase test coverage to 70%

Thanks for the update, @AdaLam7. We will review very soon. Could you remove the .gitignore file from the PR, though?

I delete the .gitignore, and rebase all commit~ : )

Thanks for the update. I will share your application with the rest of the team. Just one more note from me: the total FTEs and the sum of the milestone FTEs don't match.

Hi @Noc2 @semuelle Thanks a lot  for your helpful suggestions, we've  added relevant information about Milestones, could you please have a look and give me some suggestions ? I'd really appreciate it if you could let me know your opinion about it in time.
We sincerely hope that our project can expand ecological end users and continue to work with other teams to contribute to Polkadot ecology.
Thanks again and looking forward to hearing from you soon.

For example, do you store the mnemonics on your server? (milestone 1)

@Noc2 Thanks a lot for your suggestions.
As far as I know, substrate-tip-bot is a very good tool for users who are familiar with Polkadot. In contrast, dotpay has a completely different positioning.
First of all, different user groups. The user groups of the substrate-tip-bot are the users in the Polkadot ecosystem
The user group of Dotpay are the open source developers who obtain DOT tokens by completing paid tasks in GitHub. According to our survey, many open source developers do not know more about digital currency, especially DOT tokens. When they complete paid tasks, obtain DOT tokens and start using DOT, it will bring a large number of new users to Polkadot ecosystem
For the owners of open source projects, if everyone needs to start a substrate-tip-bot, the cost is very high. With the help of Dotpay platform, they only need to recharge - > activate the repositry  - > publish tasks
Secondly, our vision is to make open source better with the help of Polkadot ecosystem，
Let open source projects continue to attract open source developers, so that developers can not only contribute to open source but also obtain DOT tokens, which will make open source projects flourish,Polkadot will attract large number user-base，open source developers will have a new way to earn remuneration ，it will produce higher social value, and will hire more developers. This is a very good virtuous circle.
To achieve these above goals, it is obviously difficult to rely on a tool such as substrate-tip-bot, so Dotpay will be developed as a platform,not a development tool.
About Decentralization:
From a long-term perspective, We will continue to develop towards the goal of decentralization, and we also have corresponding schemes. For example, in future planning, we will develop our projects on the parallel chain.
The centralized approach is adopted at this stage because of the following considerations:

Security. Dotpay does not pay tips, but the remuneration of open source developers. The cumulative amount will be large. It is difficult to avoid some problems in the process of remuneration payment, such as wrong payment object or amount. If direct on-chain transfer is made, it can no longer be recovered (I personally have such a painful lesson) In the early stage of development, the platform will temporarily ensure that the wrong payment can be recovered within a certain period of time in a centralized way.

Arbitration. Once a dispute arises, such as dissatisfaction with the output quality of the developer, or the employer defaults and does not pay remuneration, the DotPay platform will intervene

Of course, we will have corresponding decentralized solutions for the above two points in the future. For example, 1. Solve through contract 2. Solve through Dao.

We need to launch the product quickly, because solving the actual problems of users and expanding the number of end users of Polkadot ecosystem are always the first priority. We evaluated that it takes more than three times more time to implement it in a decentralized way, which is disastrous for the team. We hope to launch products first, then improve, upgrade and optimize them to meet the market demand

About why mnemonics are stored on the platform
Mnemonics are stored on the platform to create a default address
Because one of our missions is to attract open source developers in Github especiallywho don't know digital currency to join Polkadot ecosystem
We prefer to simplify the process first. If a bunch of unfamiliar operations are required before new users get the actual benefits,  it will increase the possibility of losing users
As a new user, I hope their user's experience is simple, fast and easy to get
When withdrawing DOT tokens after completing the task and obtaining tokens, in order to obtain substantial benefits, such as withdrawing DOT tokens into their wallet, new users are more willing to carry out cumbersome operations that have not been done.
We sincerely hope that our project can expand ecological end users and continue to work with other teams to contribute to Polkadot ecosystem.
I'd really appreciate it if you could give me some more suggestions.Thanks again and have a nice day.Looking forward to hearing from you soon.

@Noc2 Thanks a lot for your suggestions.
As far as I know, substrate-tip-bot is a very good tool for users who are familiar with Polkadot. In contrast, dotpay has a completely different positioning.
First of all, different user groups. The user groups of the substrate-tip-bot are the users in the Polkadot ecosystem
The user group of Dotpay are the open source developers who obtain DOT tokens by completing paid tasks in GitHub. According to our survey, many open source developers do not know more about digital currency, especially DOT tokens. When they complete paid tasks, obtain DOT tokens and start using DOT, it will bring a large number of new users to Polkadot ecosystem
For the owners of open source projects, if everyone needs to start a substrate-tip-bot, the cost is very high. With the help of Dotpay platform, they only need to recharge - > activate the repositry  - > publish tasks
Secondly, our vision is to make open source better with the help of Polkadot ecosystem，
Let open source projects continue to attract open source developers, so that developers can not only contribute to open source but also obtain DOT tokens, which will make open source projects flourish,Polkadot will attract large number user-base，open source developers will have a new way to earn remuneration ，it will produce higher social value, and will hire more developers. This is a very good virtuous circle.
To achieve these above goals, it is obviously difficult to rely on a tool such as substrate-tip-bot, so Dotpay will be developed as a platform,not a development tool.
About Decentralization:
From a long-term perspective, We will continue to develop towards the goal of decentralization, and we also have corresponding schemes. For example, in future planning, we will develop our projects on the parallel chain.
The centralized approach is adopted at this stage because of the following considerations:

Security. Dotpay does not pay tips, but the remuneration of open source developers. The cumulative amount will be large. It is difficult to avoid some problems in the process of remuneration payment, such as wrong payment object or amount. If direct on-chain transfer is made, it can no longer be recovered (I personally have such a painful lesson) In the early stage of development, the platform will temporarily ensure that the wrong payment can be recovered within a certain period of time in a centralized way.

Arbitration. Once a dispute arises, such as dissatisfaction with the output quality of the developer, or the employer defaults and does not pay remuneration, the DotPay platform will intervene

Of course, we will have corresponding decentralized solutions for the above two points in the future. For example, 1. Solve through contract 2. Solve through Dao.

We need to launch the product quickly, because solving the actual problems of users and expanding the number of end users of Polkadot ecosystem are always the first priority. We evaluated that it takes more than three times more time to implement it in a decentralized way, which is disastrous for the team. We hope to launch products first, then improve, upgrade and optimize them to meet the market demand

About why mnemonics are stored on the platform
Mnemonics are stored on the platform to create a default address
Because one of our missions is to attract open source developers in Github especiallywho don't know digital currency to join Polkadot ecosystem
We prefer to simplify the process first. If a bunch of unfamiliar operations are required before new users get the actual benefits,  it will increase the possibility of losing users
As a new user, I hope their user's experience is simple, fast and easy to get
When withdrawing DOT tokens after completing the task and obtaining tokens, in order to obtain substantial benefits, such as withdrawing DOT tokens into their wallet, new users are more willing to carry out cumbersome operations that have not been done.
We sincerely hope that our project can expand ecological end users and continue to work with other teams to contribute to Polkadot ecosystem.
I'd really appreciate it if you could give me some more suggestions.Thanks again and have a nice day.Looking forward to hearing from you soon.

@Noc2 Thanks for your suggestions, our team is seriously discussing how to achieve as decentralized as possible.
The result of the discussion is that instead of storing the developer’s mnemonic, we can use the method of letting the developer bind the address. Developers only need to use the bind command to bind their first address, such as replying in a github issue  /dotpay bind [address].
Regarding the security issue of the owner triggering the transfer, we will add stricter reminders to allow the owner to confirm his actions repeatedly.
I will add the design details to our document later~

Solve the problem that the owner does not need to recharge, to let the entire dotpay asset be completely decentralized.
Address binding can solve part of the decentralization problem of the platform, and the platform no longer needs to record the developer's mnemonic.
However, the owner of the project still needs to recharge the platform account. This also has the problem of centralization. We can use the contract
To solve this problem, the platform assets can be completely decentralized.
This contract has three interfaces:

Set the maximum amount and maximum total amount for each transaction
set_limit(per_transfer_amount, total_transfer_amount)
Only the owner of the project has the calling permission

Set up the transfer whitelist
set_witelist(username, address)
Only the owner of the project has the calling permission

Transfer interface
transfer(address,amount)
The platform has the calling permission

Benefits of this design:

The platform no longer needs the owner to recharge, just need to sign a contract with the owner
The platform does not have the authority to set a whitelist, ensuring that the platform cannot transfer funds to addresses other than the whitelist set by the owner
The single maximum amount and the total amount set to a certain extent ensure the safety of the owner's funds

The above scheme will be executed when the Polkadot mainnet contract para chain is available, such as moonbeam or other support
Start on the premise that the ink! Parachain is available.
After processing in this way, the entire dotpay asset is completely decentralized.

Do I understand correctly that I would have to add every developer address to my whitelist to make sure that they can get paid when the task is completed?

@semuelle Yes, but don’t worry about the added complexity. When the developer performs the binding address operation, the robot will reply to the contract address and let the owner bind the whitelist. The owner only takes one more step. Or disable the whitelist, but some security will be lost, for example, the platform transfers assets to its own account through a contract (of course we will never do that)

@Noc2 We have added the contract to the first milestone. At this stage, we provide ink! contract that can be run in a local Substrate Smart Contracts Node.  In the feature, the platform will be integrating the contract when Polkadot mainnet parachain supports ink! contract~
Thank you again for your suggestions so that we can successfully find some more reasonable solutions : )

Hi~ @Noc2 Thanks a lot for your helpful suggestions, we've added relevant information about Milestones, could you please have a look and give me some suggestions ? I'd really appreciate it if you could let me know your opinion about it.
We sincerely hope that our project can expand ecological end users and continue to work with other teams to contribute to Polkadot ecology.
Thanks again and looking forward to hearing from you soon.

@Noc2 Thanks a lot for your helpful suggestions, we've updated relevant information about Milestones,
I'd really appreciate  thhat you have the foresight to give our team the  opportunity to work on and we  believe that we will make prograss on Polkadot ecology.Thanks again and looking forward to hearing from you soon.

@AdaLam7, thanks for the update, but I think what David was saying was that this grant would be about milestone 1 and 2, with the third milestone removed.

Hi~ @semuelle Thanks for reaching out , Yep, and  I wanna know what do you think of it , I'd really appreciate it if you could let me know what your opinion of  view is ,thanks again and looking forward to hearing from you soon.

Hi~ @Noc2 @semuelle Thanks for your helpful suggestions and we have already started the development project. Could you please let me know if there is anything we need to do about the process of applying for grant ?
Wish you a Merry Christmas.Thanks again and looking forward to hearing from you soon.

Hi @AdaLam7. Your proposal currently has two approvals out of three required. If a third committee member approves it, it is accepted and merged.
If there is no third committee member giving their approval within two weeks, the PR will be closed. I'm afraid you will have to wait until one of the two things happens.

Hi~@Aleixo Sánchez We've updated relevant information about Milestones, could you please take a look and we have already started the development project. I'd really appreciate it if you could  let me know if there is anything we need to do about the process of applying for grant.
We sincerely hope that our project can expand ecological end users and continue to work with other teams to contribute to Polkadot ecology.
Wish you a Merry Christmas and looking forward to hearing from you soon.

Hi~ @alxs  We've updated relevant information about Milestones, could you please take a look and we have already started the development project. I'd really appreciate it if you could let me know if there is anything we need to do about the process of applying for grant.
We sincerely hope that our project can expand ecological end users and continue to work with other teams to contribute to Polkadot ecology.
Wish you a Merry Christmas and looking forward to hearing from you soon.

Hi~ @alxs We've updated relevant information about Milestones, could you please take a look as the proposal has two approvals out of three required so far and at the same time, we have already started the development project.  I'd really appreciate it if you could let me know if there is anything we need to do about the process of applying for grant.
We sincerely hope that our project can expand ecological end users and continue to work with other teams to contribute to Polkadot ecology.
Wish you a Merry Christmas and looking forward to hearing from you soon.


Consolidate the sync controllers

This PR is to get review while we wait on getting a new upstream repository (https://github.com/open-cluster-management-io/community/issues/164). Note this points to a "feature" branch and not "main". The Go module will be renamed once we have confirmed the new repo name.
The spec sync and template sync controllers were merged into the status sync repo by using the --allow-unrelated-histories Git flag. This allows us to keep the Git history for these controllers, but it does mean that this PR has all of those commits.
You can focus on the following commits in particular, which are the latest commits. Note that I did not and will not squash those fix up commits because squashing has proven to be difficult when merging all these unrelated Git histories.

Rename to governance-policy-syncer
Consolidate the Spec Sync controller (merge commit)
Consolidate the Template Sync controller (merge commit)
Fix dependency conflicts after merging the template sync
Fix the tests after merging the template sync controller
Fix the leader election on the hub manager

Relates:
https://github.com/stolostron/backlog/issues/17974

What is the vision for pushing these changes once the syncer repository is ready? Would whatever we "approve" here just be force-pushed to that repo?
GitHub doesn't seem happy/able to show me a smaller diff for the merge commits - so unless I'm missing a trick I'll probably just trust that nothing unnecessary changed when that code was brought over from the other repositories. I don't think it will be necessary to comb through those thousands of lines.

What is the vision for pushing these changes once the syncer repository is ready? Would whatever we "approve" here just be force-pushed to that repo?
GitHub doesn't seem happy/able to show me a smaller diff for the merge commits - so unless I'm missing a trick I'll probably just trust that nothing unnecessary changed when that code was brought over from the other repositories. I don't think it will be necessary to comb through those thousands of lines.

Yes, that's the idea. If this gets merged, I would force push this on the new repo.
I have not seen an easy way to show just the diff of what was changed during merge conflict resolution from the other parent, however, you can run something like this to see the merge conflicts and what was done to fix them:
# Spec sync
git log --remerge-diff c2857ce6d67ce2837d1cd9bb874e0e40e22e36b4
# Template sync
git log --remerge-diff e404fdc8007ec9bc670dfad55142e147a8275b94

That being said, I did not change the controllers other than rename them. The main changes are in main.go and making the tests pass by removing mocks and accounting for the other controller behaviors.

This was pushed here:
https://github.com/open-cluster-management-io/governance-policy-framework-addon


feat: Add a header logo in README.md

There will be garbled fonts in Chinese introductions, so English is used.
中文介绍会有乱码字体，所以用英文。

thanks


Remove 'generator' field from components

Remove the generator field from the component.yaml files in favor of the type field.

Fixed in #28


Fix ubuntu integration tests

most likely culprit: GH runner version or image version.
rerunning old successful runs will lead to failed runs
Old successful runs, example:
Current runner version: '2.308.0'
Operating System
Runner Image
  Image: ubuntu-22.04
  Version: 20230821.1.0
  Included Software: https://github.com/actions/runner-images/blob/ubuntu22/20230821.1/images/linux/Ubuntu2204-Readme.md
  Image Release: https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20230821.1
Runner Image Provisioner
  2.0.266.1

New failed runs, example:
Current runner version: '2.309.0'
Operating System
Runner Image
  Image: ubuntu-22.04
  Version: 20230911.1.0
  Included Software: https://github.com/actions/runner-images/blob/ubuntu22/20230[9](https://github.com/getsentry/sentry-dart-plugin/actions/runs/6235755273/job/16925619627#step:1:10)11.1/images/linux/Ubuntu2204-Readme.md
  Image Release: https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20230911.1
Runner Image Provisioner
  2.0.310.1

Observations
Endpoint: http://<IP_ADDRESS>:8000/api/0/projects/sentry-sdks/sentry-dart-plugin/files/difs/assemble/

Both runs find the same number of files
Both runs have the same dependencies (os, flutter, sentry-cli).
In the success run there are three app.so files and three libapp.so files
In the failure run there are six libapp.so files
The debug id's are duplicated in both, maybe leading to some file name mixup in 'sentry-cli'?
In both runs the app.so files should be present present, as they are in later failing runs.

Success
https://github.com/getsentry/sentry-dart-plugin/actions/runs/6140635136/job/16659855989
"99b099dff41a4414b5470f785fa17a03a7405fdb":
{
    "name": "app.so",
    "debug_id": "6ff64056-0e28-15fa-c26e-f1715b2a12e9",
    "chunks":
    [
        "99b099dff41a4414b5470f785fa17a03a7405fdb"
    ]
},

"0c2b6f3c6cab12796e3d6f9aecc3441b463f783f":
{
    "name": "libapp.so",
    "debug_id": "6ff64056-0e28-15fa-c26e-f1715b2a12e9",
    "chunks":
    [
        "0c2b6f3c6cab12796e3d6f9aecc3441b463f783f"
    ]
}

Failure
https://github.com/getsentry/sentry-dart-plugin/actions/runs/6221053336/job/16882288167
"24c3b00e5b6811db190936099c7fc95da596ec30":
{
    "name": "libapp.so",
    "debug_id": "4bb27947-4dbf-7b34-f9d1-a6dc80569693",
    "chunks":
    [
        "24c3b00e5b6811db190936099c7fc95da596ec30"
    ]
},
"06e33d5d773778ab9f55f44b9aaf37ed32f7c41b":
{
    "name": "libapp.so",
    "debug_id": "4bb27947-4dbf-7b34-f9d1-a6dc80569693",
    "chunks":
    [
        "06e33d5d773778ab9f55f44b9aaf37ed32f7c41b"
    ]
},

So the file names that sentry-cli is posting to our local server are missing the three app.so files, but have three libapp.so files too many, possibly because they have the same debug_id assigned? This is only failing on ubuntu and has started recently. Do you have some feedback/ideas on this @krystofwoldrich @kamilogorek @loewenheim @kamilogorek?

Here's the closed PR, showing that it was not the flutter version: #162


LF-20069: Adding url to feed titles

https://livefyre.atlassian.net/browse/LF-20069

Replaced by: https://github.com/Livefyre/streamhub-sdk/pull/335


Color classes Not Working when in the Context of Portal

Bug Report
Description
Color scss classes are not being applied correctly to different components in our wellness applications, we first noticed this issue when we were updating our application(health trackers) to use the newer version of terra-text(version 4 and onwards).  The colors were being applied correctly locally but inside a portal the colors were not being applied correctly. We developed a workaround solution by applying the !important tag on all our color classes.
Additional Context / Screenshots
We believe its related to terra causing a dependency on the ordering of stylesheets In the first image is the css on a terra-text component

The component is getting it's color from the inherit while in the second one I manually disable the Text.Module and the correct color gets applied

Environment
This can been seen in our wellness environments here http://cckc-mo.wellness.us.healtheintent.com/pages/home on most apps such as health trackers, To-do List, and screening results.  Please PM me on teams, Joseph Fortebuono, for login info..

Note: this is impacting more than just terra-text if it wasn't, this is impacting any terra component that has a color set to inherit for example its not working when I try to set the color of a terra-card as well.

I'm wondering if color inherit should be used as a color class thats applied if no color class is passed in. Passing in a color class would then replace that the terra provided class applying color:inherit. This approach should be passive to current consumers while resolving this bug.
The problem the current implementation creates is that it creates a dependency on the ordering of stylesheets to determine if the color class, or the terra provided class setting color:inherit is used.

@jf046606 @mhemesath I've sent out a PR to address this, take a look and let me know if you have any thoughts on it. https://github.com/cerner/terra-core/pull/2607


Reduce request in copilot chat sample app

Everytime I ask a question, it takes long to reply a message. What was happening behind a chat?
Is there a way to reduce the request? For example, no memory mode.
Content:
{
"error": {
"message": "Rate limit reached for default-gpt-3.5-turbo in organization org-xx1YQ6kT97CUfp444pfkgoM6 on requests per min. Limit: 3 / min. Please try again in 20s. Contact us through our help center at help.openai.com if you continue to have issues. Please add a payment method to your account to increase your rate limit. Visit https://platform.openai.com/account/billing to add a payment method.",
"type": "requests",
"param": null,
"code": null
}

The error message itself is clear that "Please add a payment method to your account to increase your rate limit. Visit https://platform.openai.com/account/billing to add a payment method."

There are a few requests that go on behind the scenes with each chat message that is sent, and as @lextm mentions you can add a CC to increase the rate limit.
Recycling my reply to one of your other posts re ways to reduce this: https://github.com/microsoft/semantic-kernel/issues/999#issuecomment-1550350983
I'll close this for now, feel free to reopen if there is more to discuss here.


How to use this model for point cloud?

Hi, I'm trying to use this model for point cloud task. However, the shape of my input data is (B, N, C), where B is the batch size, N is the number of points, C is the dim of feature. Which params I need to modify to apply this model to my task?

You can try :
model = Perceiver(
input_channels = C,          # number of channels for each token of the input
input_axis = 1,    etc)
It will suppose you have only one axis (here all of your points) and you have C channels like the dimension of the features.

I think the point's location also needs to be converted to Fourier Features?


Can not route several GRPC Services through Ingress Gateway

Bug description
I have several services in my cluster that exposes a GRPC API, so, I would like to be able to route to them from the Ingress Gateway, but I can't make it work.
Here is my setup
The services exposes por 8080 for rest and 9090 for GRPC

NAME                            TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)             AGE
serviceA             ClusterIP   <IP_ADDRESS>   <none>        8080/TCP,9090/TCP   54d
serviceB             ClusterIP   <IP_ADDRESS>   <none>        8080/TCP,9090/TCP   54d

...
  ports:
  - name: http2
    port: 8080
    protocol: TCP
    targetPort: http2
  - name: grpc
    port: 9090
    protocol: TCP
    targetPort: 9090
...

Deployment
...
ports:
        - containerPort: 8080
          name: http2
          protocol: TCP
        - containerPort: 9090
          name: grpc
          protocol: TCP
...

Ingress Gateway
- apiVersion: networking.istio.io/v1alpha3
  kind: Gateway
  metadata:
    annotations:
    name: gateway
    namespace: services
  spec:
    selector:
      istio: ingressgateway
    servers:
    - hosts:
      - '*'
      port:
        name: grpc
        number: 9090
        protocol: grpc

Virtual Services
apiVersion: v1
items:
- apiVersion: networking.istio.io/v1alpha3
  kind: VirtualService
  metadata:
    annotations:
    name: serviceA
    namespace: services
  spec:
    gateways:
    - gateway
    hosts:
    - '*'
    http:
    - match:
      - port: 9090
      - uri:
          prefix: /serviceA
      route:
      - destination:
          host: serviceA.services.svc.cluster.local
          port:
            number: 9090
- apiVersion: networking.istio.io/v1alpha3
  kind: VirtualService
  metadata:
    annotations:
    name: serviceB
    namespace: services
  spec:
    gateways:
    - gateway
    hosts:
    - '*'
    http:
    - match:
      - port: 9090
      - uri:
          prefix: /serviceB
      route:
      - destination:
          host: serviceB.services.svc.cluster.local
          port:
            number: 9090
kind: List

When I check the ingress config I see this
➜  ~ istioctl proxy-config routes istio-ingressgateway-5c6df4f597-8hw5z.istio-system -ojson
[
    {
        "name": "http.9090",
        "virtualHosts": [
            {
                "name": "*:9090",
                "domains": [
                    "*",
                    "*:9090"
                ],
                "routes": [
                    {
                        "match": {
                            "prefix": "/"
                        },
                        "route": {
                            "cluster": "outbound|9090||serviceA.services.svc.cluster.local",

...
{
                        "match": {
                            "prefix": "/"
                        },
                        "route": {
                            "cluster": "outbound|9090||serviceB.services.svc.cluster.local",

With this config I only can call the serviceA trough the ingress gateway, and that is because I create de virtual service serviceA first and the match prefix / is first, or so I guess.
I also tried to route rest services and that I make it work, but for some reason grpc doesnt work
Expected behavior
Ingress Gateway to be able to route between several grpc services
Steps to reproduce the bug
Deploy 2 or more GRPC services and try to route trough them via Ingress Gateway
Version (include the output of istioctl version --remote and kubectl version and helm version if you used Helm)
➜  ~ istioctl version --remote
client version: 1.2.2
citadel version: 1.2.2
galley version: 1.2.2
ingressgateway version: 1.2.2
pilot version: 1.2.2
sidecar-injector version: 1.2.2
telemetry version: 1.2.2
➜  ~ kubectl version
Client Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.4", GitCommit:"f49fa022dbe63faafd0da106ef7e05a29721d3f1", GitTreeState:"clean", BuildDate:"2018-12-14T07:10:00Z", GoVersion:"go1.10.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.4+icp-ee", GitCommit:"d03f6421b5463042d87aa0211f116ba4848a0d0f", GitTreeState:"clean", BuildDate:"2019-01-17T13:14:09Z", GoVersion:"go1.10.4", Compiler:"gc", Platform:"linux/amd64"}
➜  ~ helm version
Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

How was Istio installed?
IBM Istio Helm Chart
Environment where bug was observed (cloud vendor, OS, etc)
ICP version 3.1.2

I applied your config and I see
    {
     "version_info": "2020-03-26T15:16:00Z/11",
     "route_config": {
      "@type": "type.googleapis.com/envoy.api.v2.RouteConfiguration",
      "name": "http.9090",
      "virtual_hosts": [
       {
        "name": "*:9090",
        "domains": [
         "*"
        ],
        "routes": [
         {
          "match": {
           "prefix": "/serviceA",
           "case_sensitive": true
          },
          "route": {
           "cluster": "outbound|9090||servicea.services.svc.cluster.local",
           "timeout": "0s",
           "retry_policy": {
            "retry_on": "connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes",
            "num_retries": 2,
            "retry_host_predicate": [
             {
              "name": "envoy.retry_host_predicates.previous_hosts"
             }
            ],
            "host_selection_retry_max_attempts": "5",
            "retriable_status_codes": [
             503
            ]
           },
           "max_grpc_timeout": "0s"
          },
          "metadata": {
           "filter_metadata": {
            "istio": {
             "config": "/apis/networking.istio.io/v1alpha3/namespaces/services/virtual-service/servicea"
            }
           }
          },
          "decorator": {
           "operation": "servicea.services.svc.cluster.local:9090/serviceA*"
          }
         },
         {
          "match": {
           "prefix": "/serviceB",
           "case_sensitive": true
          },
          "route": {
           "cluster": "outbound|9090||servicea.services.svc.cluster.local",
           "timeout": "0s",
           "retry_policy": {
            "retry_on": "connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes",
            "num_retries": 2,
            "retry_host_predicate": [
             {
              "name": "envoy.retry_host_predicates.previous_hosts"
             }
            ],
            "host_selection_retry_max_attempts": "5",
            "retriable_status_codes": [
             503
            ]
           },
           "max_grpc_timeout": "0s"
          },
          "metadata": {
           "filter_metadata": {
            "istio": {
             "config": "/apis/networking.istio.io/v1alpha3/namespaces/services/virtual-service/serviceb"
            }
           }
          },
          "decorator": {
           "operation": "servicea.services.svc.cluster.local:9090/serviceB*"
          }
         },
         {
          "match": {
           "prefix": "/",
           "case_sensitive": true
          },
          "route": {
           "cluster": "outbound|9090||servicea.services.svc.cluster.local",
           "timeout": "0s",
           "retry_policy": {
            "retry_on": "connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes",
            "num_retries": 2,
            "retry_host_predicate": [
             {
              "name": "envoy.retry_host_predicates.previous_hosts"
             }
            ],
            "host_selection_retry_max_attempts": "5",
            "retriable_status_codes": [
             503
            ]
           },
           "max_grpc_timeout": "0s"
          },
          "metadata": {
           "filter_metadata": {
            "istio": {
             "config": "/apis/networking.istio.io/v1alpha3/namespaces/services/virtual-service/servicea"
            }
           }
          },
          "decorator": {
           "operation": "servicea.services.svc.cluster.local:9090/*"
          }
         },
         {
          "match": {
           "prefix": "/",
           "case_sensitive": true
          },
          "route": {
           "cluster": "outbound|9090||servicea.services.svc.cluster.local",
           "timeout": "0s",
           "retry_policy": {
            "retry_on": "connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes",
            "num_retries": 2,
            "retry_host_predicate": [
             {
              "name": "envoy.retry_host_predicates.previous_hosts"
             }
            ],
            "host_selection_retry_max_attempts": "5",
            "retriable_status_codes": [
             503
            ]
           },
           "max_grpc_timeout": "0s"
          },
          "metadata": {
           "filter_metadata": {
            "istio": {
             "config": "/apis/networking.istio.io/v1alpha3/namespaces/services/virtual-service/serviceb"
            }
           }
          },
          "decorator": {
           "operation": "servicea.services.svc.cluster.local:9090/*"
          }
         }
        ]
       }
      ],
      "validate_clusters": false
     },
     "last_updated": "2020-03-26T15:16:00.191Z"
    }
   ]
  },

This is on the latest supported version of istio. 1.2 is EOL: https://istio.io/news/support/announcing-1.2-eol/
@linsun @esnible is it possible to stop recommending Istio 1.2?

Wow, that's too bad
IBM only offers version 1.2.2 on its official helm repo: https://github.com/IBM/charts/blob/884389cd82ea713958a5857451b690a919cda316/stable/ibm-istio/Chart.yaml#L3
One may think that as they are a big part of the istio community, they could keep the istio chart updated, but no.
@herickbeth

@nelsonyaccuzzi I agree! I reached out to some folks at IBM to see if we can get this resolved. In the meantime I think this is an IBM issue, everything is working in supported Istio versions, so I will close this. If I misunderstood lmk and we can reinvestigate


Fix mysensors validation for composite entities

Breaking Change:

Description:

Composite entities require multiple value types to be present in child values to function. Any of those value types should trigger an entity update if updated.
Always write platform v names as sets.
Run black.

Related issue (if applicable):
fixes #24085, fixes #24686
Pull request with documentation for home-assistant.io (if applicable):
N/A
Example entry for configuration.yaml (if applicable):

Checklist:

[x] The code change is tested and works locally.
[x] Local tests pass with tox. Your PR cannot be merged unless tests pass
[x] There is no commented out code in this PR.
[x] I have followed the development checklist

Looks good 🐬


No Support for Alpha/Opacity in Webgl?

I may be missing something, but I've spent a day looking for this with no success:
Is there a way to control edge opacity when using webgl?  I have some networks that are way too big for canvas, and I can't get anything to work for opacity.  I've tried:

Using rgba() in the data
Using rgba() to set the default edge color in the renderer settings

Is this just one of those things that will not be supported?
Thanks!
-Ian

Hello @iankloo. For a reason I don't clearly remember I think we do not support alpha with the WebGL renderer. What are you trying to achieve UX-wise? Maybe we can find some workaround.

Got it - thanks for the response.  I'm working with large (~90,000 edges and ~6,000 nodes) graphs and would benefit from being able to show fairly transparent links.  There's no doubt that graphs of this size typically just look like a hairball, but being able to see central nodes can give a good general idea of the network.  Without an alpha channel, it is hard to make sense of the nodes given all of the edges.
I've had some success setting very small edges size attributes, so I'll probably just move ahead with that.
Thanks!

Is this related?
https://github.com/jacomyal/sigma.js/pull/573/files


Artisan route list extends

This pull request extends artisan route:list command with two options:
--filter[=FILTER] Filter the routes by word in any column.
--action[=ACTION] Filter the routes by action.
I would like to comment my proposals:
--filter[=FILTER] will find anything in any column, is useful for Windows machines, there is no normal grep command
--action[=ACTION] sometimes it is useful to filter routes for controller methods and I don’t found how to make it

I would like to coI would like to comment my proposals:
--filter[=FILTER] will find anything in any column, is useful for Windows machines, there is no normal grep command
--action[=ACTION] sometimes it is useful to filter routes for controller methods and I don’t found how to make it

Windows has the find tool.
php artisan route:list | find "example"

I knew it, but not all people know it. And for me, for example, built-in tool is more convenient.

Holding off on this for now.

As you wish @taylorotwell :)


not able to run example program main.go

Trying to run https://github.com/docker/libcompose/blob/master/example/main.go and getting error as:
$ go run main.go
# command-line-arguments
./main.go:22: not enough arguments in call to project.Up

on compose file
$ cat docker-compose.yml
postgresql:
  image: swordphilic/postgresql
  ports:
    - "5432"
  environment:
    DB_NAME: gitlab
    DB_PASS: gitlab
    DB_USER: gitlab

gitlab:
  image: swordphilic/gitlab
  ports:
    - "30000:80"
    - "30001:443"
    - "30002:22"
  links:
    - redis
    - postgresql
  environment:
    DB_TYPE: postgres
    DB_NAME: gitlab
    DB_PASS: gitlab
    DB_USER: gitlab

redis:
  image: swordphilic/redis
  ports:
    - "6379"

hey @surajssd,
Thank u for the report. There has been some changes API wise and I did not yet the documentation and examples. Sorry about that, I'll work on it soon.
You can take a look at project/interface.go to see what is needed :wink:


Jesse: Blacklist omega[\W_]+crypto(?:[\W_]+recovery)?

Jesse requests the blacklist of the keyword omega[\W_]*+crypto(?:[\W_]*+recovery)?. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

omega[\W_]*+crypto(?:[\W_]*+recovery)? has been seen in 17 true positives, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


Does this support Lua and Luajit?

I looked at the bpf code in the repository, and it seems that there is no lua/luajit part. Will lua/luajit be supported in the future? Thanks!

The future OTEL repository is open to contributions from the community.
Driving lua/luajit support is highly appreciated, and my personal guess is that it will come.

FYI we're 95% there in Parca Agent (some customers already testing it), and plan to port it to this.

Happy to see that happen. Programs like cloudwu/skynet have multiple lua vms in one process, is that supported?

I don’t know for sure, our primary focus is for openresty workloads.


Give pointer to esp-open-sdk

If I understand this correctly, the SDK is strictly necessary to build the examples.
It would thus make sense to add a link to the repo, which also contains installation instructions.

Thank you for this! Your understanding is correct, I just  have one quick question.
I had previously obtained the binaries directly from Espressif's documentation, and was actually unfamiliar with the esp-open-sdk repository. I have built it now, and am not seeing at tools directory; I am however seeing xtensa-lx106-elf, whose bin directory seems to contain what we want. I'm just curious if I am missing something or if you have made a typo. I just want to make sure everything is as clear and accurate as possible.

Actually you're right. Late night PRs. Never a good idea. :facepalm:
Actually I hadn't even realized I could just get that binary from espressif directly. I just googled it and the open sdk came up first. :P

feel free to discard this and write it the way you'd want it of course. I just wanted to confirm I'm understanding the moving parts here correctly. :)

These things happen 😄
Thanks for updating this, I think it's fine as it is for now; the README will obviously receive more updates with time anyways.


[7.x] Make all remaining stubs customizable

This PR makes all remaining make: commands stubs publishable and customizable.
For every stub three replacement formats are available: DummyName, {{ name }}, {{name}}.
Existing duplicated resolveStubPath function has been reworked and moved to GeneratorCommand.

Please send this to 8.x (master branch).


yolov5 qat problem

Hi, I am wondering if the qat method can work on the yolov5 model. When trying to convert yolov5 to a quantized model, I met some errors when executing the following code. Thanks for helping !!
Code:
from tinynn.graph.quantization.quantizer import QATQuantizer
quantizer = QATQuantizer(model, dummy_input=torch.rand(1,3,640,640).to(device), work_dir='./quantization', config={'asymmetric': True, 'per_tensor': True})
model = quantizer.quantize()

Error
torch/nn/modules/module.py", line 1208, in __getattr_type(self).__name__, name))
AttributeError: 'Upsample' object has no attribute 'recompute_scale_factor'

Environment:
pytorch: 1.12.1
python: 3.7.13
cuda:11.6

This issue is related to your training framework. Obviously, you have your own implementation of the class Upsample. I'd be glad to look into it if you can tell me which repo are you using.

Would you please share the generated script under the ./quantization folder?

As can be seen in the code, recompute_scale_factor is actually an attribute of the class Upsample. So, it is possibly caused by a corrupted PyTorch installation?

Thanks for helping, I would try to downgrade my PyTorch version and try again. This is the generated file model_qat.zip

Thanks for helping, I would try to downgrade my PyTorch version and try again. This is the generated file model_qat.zip

Well, I mean the python script, not the weights file.

Sorry about that. In fact, the code did not generate any script file under ./quantization folder.  It stucks at the generate code step
Traceback (most recent call last):
  File "yolo_quantize.py", line 674, in <module>
    main(opt)
  File "yolo_quantize.py", line 569, in main
    train(opt.hyp, opt, device, callbacks)
  File "yolo_quantize.py", line 187, in train
    model = quantizer.quantize()
  File "/home/urchinwang/anaconda3/envs/py3.7/lib/python3.7/site-packages/tinynn/graph/quantization/quantizer.py", line 221, in quantize
    graph.generate_code(model_code_path, model_weights_path, model_name_qat)
  File "/home/urchinwang/anaconda3/envs/py3.7/lib/python3.7/site-packages/tinynn/graph/tracer.py", line 1951, in generate_code
    init_block = self.__gen_init_code()
  File "/home/urchinwang/anaconda3/envs/py3.7/lib/python3.7/site-packages/tinynn/graph/tracer.py", line 1824, in __gen_init_code
    orig_constructor_line, mod_cache = gen_module_constrctor_line(node.module, mod_cache_dict)
  File "/home/urchinwang/anaconda3/envs/py3.7/lib/python3.7/site-packages/tinynn/graph/tracer.py", line 1246, in gen_module_constrctor_line
    prop_value = getattr(module, prop_name)
  File "/home/urchinwang/anaconda3/envs/py3.7/lib/python3.7/site-packages/torch/nn/modules/module.py", line 1208, in __getattr__
    type(self).__name__, name))
AttributeError: 'Upsample' object has no attribute 'recompute_scale_factor'

In addition, I met a problem before this one and modified PyTorch source code as the link specified  https://github.com/openai/DALL-E/issues/54#issuecomment-1092826376, I am not sure whether this modification causes this error

@Raychen0617 Okay, I think I know the reason. It is because you are loading from a serialized model in a newer version of PyTorch, which is generated using an old version of PyTorch, but the current version of PyTorch contains the property recompute_scale_factor. I guess we can skip this kind of property or loading the default value from the constructor.

@Raychen0617 Should be resolved via https://github.com/alibaba/TinyNeuralNetwork/commit/c3fa67cda8685202f76f2dcf960d84b077cc0d40

In addition, I met a problem before this one and modified PyTorch source code as the link specified  https://github.com/openai/DALL-E/issues/54#issuecomment-1092826376, I am not sure whether this modification causes this error

Also, the workaround in that post is not that graceful. The following seems a better solution.
for m in model.modules():
    if isinstance(m, nn.Upsample):
        setattr(m, 'recompute_scale_factor', None)

This solves the problem, thanks a lot !!!


version: set the version back to 6.1.0

Update the branch to accurately reflect the version.
Motivation:
Need to accurately display the version
Modifications:
Reverted https://github.com/swiftlang/swift-package-manager/pull/8135
Result:
N/A

I would recommend doing git revert fe8501667c18ddc077aebbb9e9da8ddf0556be89 so it's easier to track the reverts.

Good call. done

@swift-ci please test

@swift-ci please test Windows

@swift-ci Please test nightly self hosted

@swift-ci test

@swift-ci test


Custom deserialization for my type

Hello. I'm doing a custom data format for a format that is out of my control.
What I'm trying to solve now is that sequences can be prefixed with the length as u8/u16/u32, but you can't figure it out what it is except if you know it.
So what I'm trying to do is:
#[derive(Serialize, Deserialize)]
#[serde(transparent)]
pub struct WeirdVec<T, S> {
  pub inner: Vec<T>,
  pub phantom: marker::PhantomData<S>
}

I would've liked to have a default implementation that would work for the other formats, and then specialize the ser/de process for my format and take into consideration the size in bytes of the length prefix.
I would like some advice on how can I do that/what would be the best way to handle this. Thanks.

Hi, wasn't this page useful?
It should cover the basics of the flow.

Hi @xTachyon, sorry that no one was able to provide more help here. If this is still an issue, you could try taking this question to any of the resources shown in https://github.com/serde-rs/serde#getting-help.


Error while refactoring

Describe the bug
Refactoring breaks with an error message
{"err":{"status":"unknown","msg":"","payload":"{\"msg\":\"no childNote found: f7be3edd-0a74-45d2-8c00-16eafd3f3392, current note: fcb8b329-1e15-4373-9bbb-65814357f0d2\"}"}}

For both ids a note exists and the issue persists after running Dendron:Doctor
To Reproduce
Refactor in a multi-vault environment
Expected behavior
Notes are moved within the vault to a new hierarchy
Desktop (please complete the following information):

OS: Windows
VSCodium
Version 0.18.1

Additional context
Add any other context about the problem here.
Dendron Log file
Please attach the output of >Dev:Dendron: Open Logs here

In Code (version 1.15.1) with the same workspace the error is slightly different
{"ctx":"y:run","err":{"status":"unknown","msg":"","payload":"{"msg":"Cannot read property 'forEach' of undefined","stack":"TypeError: Cannot read property 'forEach' of undefined\n\tat l.refreshNotesV2 (c:\\Users\\Bassmann\\.vscode\\extensions\\dendron.dendron-0.18.1\\dist\\extension.js:102:53335)\n\tat l.renameNote (c:\\Users\\Bassmann\\.vscode\\extensions\\dendron.dendron-0.18.1\\dist\\extension.js:102:53900)\n\tat async m.execute (c:\\Users\\Bassmann\\.vscode\\extensions\\dendron.dendron-0.18.1\\dist\\extension.js:537:48567)\n\tat async a.default.reduce.Promise.resolve.changed (c:\\Users\\Bassmann\\.vscode\\extensions\\dendron.dendron-0.18.1\\dist\\extension.js:537:41855)\n\tat async a.default.reduce.Promise.resolve.changed (c:\\Users\\Bassmann\\.vscode\\extensions\\dendron.dendron-0.18.1\\dist\\extension.js:537:41779)\n\tat async a.default.reduce.Promise.resolve.changed (c:\\Users\\Bassmann\\.vscode\\extensions\\dendron.dendron-0.18.1\\dist\\extension.js:537:41779)\n\tat async a.default.reduce.Promise.resolve.changed (c:\\Users\\Bassmann\\.vscode\\extensions\\dendron.dendron-0.18.1\\dist\\extension.js:537:41779)\n\tat async a.default.reduce.Promise.resolve.changed (c:\\Users\\Bassmann\\.vscode\\extensions\\dendron.dendron-0.18.1\\dist\\extension.js:537:41779)\n\tat async a.default.reduce.Promise.resolve.changed (c:\\Users\\Bassmann\\.vscode\\extensions\\dendron.dendron-0.18.1\\dist\\extension.js:537:41779)\n\tat async a.default.reduce.Promise.resolve.changed (c:\\Users\\Bassmann\\.vscode\\extensions\\dendron.dendron-0.18.1\\dist\\extension.js:537:41779)\n\tat async a.default.reduce.Promise.resolve.changed (c:\\Users\\Bassmann\\.vscode\\extensions\\dendron.dendron-0.18.1\\dist\\extension.js:537:41779)\n\tat async a.default.reduce.Promise.resolve.changed (c:\\Users\\Bassmann\\.vscode\\extensions\\dendron.dendron-0.18.1\\dist\\extension.js:537:41779)\n\tat async a.default.reduce.Promise.resolve.changed (c:\\Users\\Bassmann\\.vscode\\extensions\\dendron.dendron-0.18.1\\dist\\extension.js:537:41779)\n\tat async y.execute (c:\\Users\\Bassmann\\.vscode\\extensions\\dendron.dendron-0.18.1\\dist\\extension.js:537:41735)\n\tat async y.run (c:\\Users\\Bassmann\\.vscode\\extensions\\dendron.dendron-0.18.1\\dist\\extension.js:11:101200)\n\tat async c:\\Users\\Bassmann\\.vscode\\extensions\\dendron.dendron-0.18.1\\dist\\extension.js:11:77744"}"}}

Dendron: OpenLogsays this
{"level":30,"time":1607170726712,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"Logger:configure","msg":"exit","log_level":"info"}
{"level":30,"time":1607170726749,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"_activate","stage":"dev","isDebug":false,"logPath":"c:\\Users\\Bassmann\\AppData\\Roaming\\Code\\logs\\20201205T131059\\exthost1\\dendron.dendron","logLevel":"info","extensionPath":"c:\\Users\\Bassmann\\.vscode\\extensions\\dendron.dendron-0.18.1","extensionUri":{"$mid":1,"fsPath":"c:\\Users\\Bassmann\\.vscode\\extensions\\dendron.dendron-0.18.1","_sep":1,"path":"/c:/Users/Bassmann/.vscode/extensions/dendron.dendron-0.18.1","scheme":"file"},"storagePath":"c:\\Users\\Bassmann\\AppData\\Roaming\\Code\\User\\workspaceStorage\\4adf13994b126496bda953daada217ba\\dendron.dendron","workspaceFile":{"$mid":1,"fsPath":"c:\\Users\\Bassmann\\Software\\Dendron-new\\dendron.code-workspace","_sep":1,"external":"file:///c%3A/Users/Bassmann/Software/Dendron-new/dendron.code-workspace","path":"/c:/Users/Bassmann/Software/Dendron-new/dendron.code-workspace","scheme":"file"},"workspaceFolders":[{"uri":{"$mid":1,"fsPath":"c:\\Users\\Bassmann\\Software\\Dendron-new\\gitjournal","_sep":1,"external":"file:///c%3A/Users/Bassmann/Software/Dendron-new/gitjournal","path":"/c:/Users/Bassmann/Software/Dendron-new/gitjournal","scheme":"file"},"name":"Gitjournal","index":0},{"uri":{"$mid":1,"fsPath":"c:\\Users\\Bassmann\\Software\\Dendron-new\\nextcloud","_sep":1,"external":"file:///c%3A/Users/Bassmann/Software/Dendron-new/nextcloud","path":"/c:/Users/Bassmann/Software/Dendron-new/nextcloud","scheme":"file"},"name":"Nextcloud","index":1}]}
{"level":30,"time":1607170726753,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"DendronWorkspace","msg":"initialized"}
{"level":30,"time":1607170726757,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"_activate","config":{"version":1,"vaults":[{"fsPath":"gitjournal","name":"Gitjournal"},{"fsPath":"..\\..\\Nextcloud\\Dendron\\vault","name":"Nextcloud"}],"site":{"copyAssets":true,"siteHierarchies":["root"],"siteRootDir":"docs","usePrettyRefs":true}},"configMigrated":false,"msg":"read dendron config"}
{"level":30,"time":1607170726980,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"_activate","wsConfig":{"folders":[{"path":"gitjournal","name":"Gitjournal"},{"path":"nextcloud","name":"Nextcloud"}],"settings":{"dendron.rootDir":".","files.autoSave":"onFocusChange","pasteImage.path":"${currentFileDir}/assets/images","pasteImage.prefix":"/","markdown-preview-enhanced.enableWikiLinkSyntax":true,"markdown-preview-enhanced.wikiLinkFileExtension":".md","editor.snippetSuggestions":"inline","editor.suggest.snippetsPreventQuickSuggestions":false,"editor.suggest.showSnippets":true,"editor.tabCompletion":"on"},"extensions":{"recommendations":["dendron.dendron-paste-image","equinusocio.vsc-material-theme","dendron.dendron-markdown-shortcuts","dendron.dendron-markdown-preview-enhanced","dendron.dendron-markdown-links","github.github-vscode-theme"],"unwantedRecommendations":["dendron.dendron-markdown-notes","shd101wyy.markdown-preview-enhanced","kortina.vscode-markdown-notes","mushan.vscode-paste-image"]}},"wsConfigMigrated":{},"msg":"read wsConfig"}
{"level":30,"time":1607170726989,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"_activate","installedGlobalVersion":"0.18.1","migratedGlobalVersion":"0.18.1","previousGlobalVersion":"0.17.1","previousWsVersion":"0.18.1","platform":"win32","extensions":[{"id":"dendron.dendron-paste-image","version":"1.0.4","active":false},{"id":"equinusocio.vsc-material-theme","version":"33.0.0","active":false},{"id":"dendron.dendron-markdown-shortcuts","version":"0.12.1","active":true},{"id":"dendron.dendron-markdown-preview-enhanced","version":"0.10.11","active":false},{"id":"dendron.dendron-markdown-links","version":"0.6.17","active":false},{"id":"github.github-vscode-theme","version":"1.1.5","active":false}],"vaults":[{"fsPath":"c:\\Users\\Bassmann\\Software\\Dendron-new\\gitjournal","name":"Gitjournal"},{"fsPath":"c:\\Users\\Bassmann\\Nextcloud\\Dendron\\vault","name":"Nextcloud"}]}
{"level":30,"time":1607170726990,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"startServeer","logLevel":"info"}
{"level":30,"time":1607170727028,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"_activate","msg":"post-start-server","port":57559}
{"level":30,"time":1607170727032,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"ReloadIndex.execute","msg":"enter"}
{"level":30,"time":1607170730732,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"ReloadIndex.execute","msg":"exit"}
{"level":30,"time":1607170730732,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"reloadWorkspace","msg":"post-ws.reloadWorkspace"}
{"level":30,"time":1607170730733,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"reloadWorkspace","msg":"exit"}
{"level":30,"time":1607170730733,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"postReloadWorkspace","msg":"same wsVersion"}
{"level":30,"time":1607170730733,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"postReloadWorkspace","msg":"exit"}
{"level":30,"time":1607170730734,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"TreeView:getChildren","msg":"reconstructing tree"}
{"level":30,"time":1607170730765,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"setupViews","msg":"init:backlinks"}
{"level":30,"time":1607170730780,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"activateWorkspace","stage":"dev","msg":"enter"}
{"level":30,"time":1607170730785,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"toggleViews","msg":"views enabled: true"}
{"level":30,"time":1607170730785,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"_activate","msg":"fin startClient"}
{"level":30,"time":1607170730785,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"showWelcomeOrWhatsNew","version":"0.18.1","previousVersion":"0.18.1"}
{"level":30,"time":1607170730785,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"showWelcomeOrWhatsNew","msg":"not first time install"}
{"level":30,"time":1607170730946,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"TreeView:getChildren","msg":"reconstructing tree"}
{"level":30,"time":1607170740624,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"WindowWatcher:onDidChangeActiveTextEditor","msg":"enter","uri":{"$mid":1,"fsPath":"c:\\Users\\Bassmann\\Software\\Dendron-new\\gitjournal\\gtd.computer.md","_sep":1,"external":"file:///c%3A/Users/Bassmann/Software/Dendron-new/gitjournal/gtd.computer.md","path":"/c:/Users/Bassmann/Software/Dendron-new/gitjournal/gtd.computer.md","scheme":"file"}}
{"level":30,"time":1607170763059,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"y:run","msg":"pre-execute"}
{"level":30,"time":1607170763060,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"RefactorHierarchy:execute","opts":{"match":"^software.","replace":"ref."},"msg":"enter"}
{"level":30,"time":1607170771182,"pid":9364,"hostname":"Bassmann","name":"dendron","orig":"c:\\Users\\Bassmann\\Software\\Dendron-new\\gitjournal\\software.android.md","replace":"c:\\Users\\Bassmann\\Software\\Dendron-new\\gitjournal\\ref.android.md"}
{"level":30,"time":1607170771182,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"RenameNoteV2a","msg":"enter","opts":{"files":[{"oldUri":{"$mid":1,"fsPath":"c:\\Users\\Bassmann\\Software\\Dendron-new\\gitjournal\\software.android.md","_sep":1,"path":"/c:/Users/Bassmann/Software/Dendron-new/gitjournal/software.android.md","scheme":"file"},"newUri":{"$mid":1,"fsPath":"c:\\Users\\Bassmann\\Software\\Dendron-new\\gitjournal\\ref.android.md","_sep":1,"path":"/c:/Users/Bassmann/Software/Dendron-new/gitjournal/ref.android.md","scheme":"file"}}],"silent":true,"closeCurrentFile":false,"openNewFile":false,"noModifyWatcher":true}}
{"level":50,"time":1607170771209,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"y:run","err":{"type":"r","message":"","stack":"Error: \n\tat y.run (c:\\Users\\Bassmann\\.vscode\\extensions\\dendron.dendron-0.18.1\\dist\\extension.js:11:101356)\n\tat async c:\\Users\\Bassmann\\.vscode\\extensions\\dendron.dendron-0.18.1\\dist\\extension.js:11:77744","status":"unknown","msg":"","payload":"{\"msg\":\"Cannot read property 'forEach' of undefined\",\"stack\":\"TypeError: Cannot read property 'forEach' of undefined\\n\\tat l.refreshNotesV2 (c:\\\\Users\\\\Bassmann\\\\.vscode\\\\extensions\\\\dendron.dendron-0.18.1\\\\dist\\\\extension.js:102:53335)\\n\\tat l.renameNote (c:\\\\Users\\\\Bassmann\\\\.vscode\\\\extensions\\\\dendron.dendron-0.18.1\\\\dist\\\\extension.js:102:53900)\\n\\tat async m.execute (c:\\\\Users\\\\Bassmann\\\\.vscode\\\\extensions\\\\dendron.dendron-0.18.1\\\\dist\\\\extension.js:537:48567)\\n\\tat async a.default.reduce.Promise.resolve.changed (c:\\\\Users\\\\Bassmann\\\\.vscode\\\\extensions\\\\dendron.dendron-0.18.1\\\\dist\\\\extension.js:537:41855)\\n\\tat async a.default.reduce.Promise.resolve.changed (c:\\\\Users\\\\Bassmann\\\\.vscode\\\\extensions\\\\dendron.dendron-0.18.1\\\\dist\\\\extension.js:537:41779)\\n\\tat async a.default.reduce.Promise.resolve.changed (c:\\\\Users\\\\Bassmann\\\\.vscode\\\\extensions\\\\dendron.dendron-0.18.1\\\\dist\\\\extension.js:537:41779)\\n\\tat async a.default.reduce.Promise.resolve.changed (c:\\\\Users\\\\Bassmann\\\\.vscode\\\\extensions\\\\dendron.dendron-0.18.1\\\\dist\\\\extension.js:537:41779)\\n\\tat async a.default.reduce.Promise.resolve.changed (c:\\\\Users\\\\Bassmann\\\\.vscode\\\\extensions\\\\dendron.dendron-0.18.1\\\\dist\\\\extension.js:537:41779)\\n\\tat async a.default.reduce.Promise.resolve.changed (c:\\\\Users\\\\Bassmann\\\\.vscode\\\\extensions\\\\dendron.dendron-0.18.1\\\\dist\\\\extension.js:537:41779)\\n\\tat async a.default.reduce.Promise.resolve.changed (c:\\\\Users\\\\Bassmann\\\\.vscode\\\\extensions\\\\dendron.dendron-0.18.1\\\\dist\\\\extension.js:537:41779)\\n\\tat async a.default.reduce.Promise.resolve.changed (c:\\\\Users\\\\Bassmann\\\\.vscode\\\\extensions\\\\dendron.dendron-0.18.1\\\\dist\\\\extension.js:537:41779)\\n\\tat async a.default.reduce.Promise.resolve.changed (c:\\\\Users\\\\Bassmann\\\\.vscode\\\\extensions\\\\dendron.dendron-0.18.1\\\\dist\\\\extension.js:537:41779)\\n\\tat async a.default.reduce.Promise.resolve.changed (c:\\\\Users\\\\Bassmann\\\\.vscode\\\\extensions\\\\dendron.dendron-0.18.1\\\\dist\\\\extension.js:537:41779)\\n\\tat async y.execute (c:\\\\Users\\\\Bassmann\\\\.vscode\\\\extensions\\\\dendron.dendron-0.18.1\\\\dist\\\\extension.js:537:41735)\\n\\tat async y.run (c:\\\\Users\\\\Bassmann\\\\.vscode\\\\extensions\\\\dendron.dendron-0.18.1\\\\dist\\\\extension.js:11:101200)\\n\\tat async c:\\\\Users\\\\Bassmann\\\\.vscode\\\\extensions\\\\dendron.dendron-0.18.1\\\\dist\\\\extension.js:11:77744\"}"}}
{"level":30,"time":1607170774224,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"RefactorHierarchy:execute","msg":"exit"}
{"level":30,"time":1607170774337,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"refreshTree"}
{"level":30,"time":1607170774342,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"TreeView:getChildren","msg":"reconstructing tree"}
{"level":30,"time":1607170790887,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"c:run","msg":"pre-execute"}
{"level":30,"time":1607170790887,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"LookupCommand:execute","opts":{"noteType":"scratch","selectionType":"selection2link","flavor":"note"},"msg":"enter"}
{"level":30,"time":1607170790890,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"LookupCommand:execute","profile":2,"msg":"postCreateController"}
{"level":30,"time":1607170790890,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"LookupCommand:execute","profile":2,"msg":"post:extractRange"}
{"level":30,"time":1607170790891,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"LookupControllerV2:show","msg":"enter","cleanOpts":{"ignoreFocusOut":true}}
{"level":30,"time":1607170790893,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"LookupControllerV2:show","profile":2,"msg":"post:createQuickPick"}
{"level":30,"time":1607170790894,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"LookupControllerV2:show","profile":2,"msg":"post:createProvider"}
{"level":30,"time":1607170790895,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"updatePickerBehavior","activeButtons":[{"iconPathNormal":{"id":"link"},"iconPathPressed":{"id":"menu-selection"},"type":"selection2link","pressed":true,"title":"Selection to Link","canToggle":true,"opts":{"title":"Selection to Link","iconOff":"link","iconOn":"menu-selection","type":"selection2link"}},{"iconPathNormal":{"id":"new-file"},"iconPathPressed":{"id":"menu-selection"},"type":"scratch","pressed":true,"title":"Create Scratch Note","canToggle":true,"opts":{"title":"Create Scratch Note","iconOff":"new-file","iconOn":"menu-selection","type":"scratch"}}]}
{"level":30,"time":1607170790896,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"LookupCommand:execute","profile":8,"msg":"post:show"}
{"level":30,"time":1607170790898,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"LookupControllerV2:show","profile":2,"msg":"post:updatePickerBehavior"}
{"level":30,"time":1607170790900,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"LookupControllerV2:show","profile":2,"msg":"post:provide"}
{"level":30,"time":1607170790900,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"LookupControllerV2:show","profile":2,"msg":"exit"}
{"level":30,"time":1607170790901,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"c:run","msg":"post-execute"}
{"level":30,"time":1607170795385,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"updatePickerBehavior","activeButtons":[{"iconPathNormal":{"id":"link"},"iconPathPressed":{"id":"menu-selection"},"type":"selection2link","pressed":true,"title":"Selection to Link","canToggle":true,"opts":{"title":"Selection to Link","iconOff":"link","iconOn":"menu-selection","type":"selection2link"}}]}
{"level":30,"time":1607170795386,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"updatePickerItems","msg":"enter","queryOrig":"","source":"updatePickerBehavior:normal"}
{"level":30,"time":1607170795426,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"updatePickerItems","msg":"exit","queryOrig":"","source":"updatePickerBehavior:normal","profile":40,"cancelled":false}
{"level":30,"time":1607170798188,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"updatePickerBehavior","activeButtons":[{"iconPathNormal":{"id":"link"},"iconPathPressed":{"id":"menu-selection"},"type":"selection2link","pressed":true,"title":"Selection to Link","canToggle":true,"opts":{"title":"Selection to Link","iconOff":"link","iconOn":"menu-selection","type":"selection2link"}},{"iconPathNormal":{"id":"new-file"},"iconPathPressed":{"id":"menu-selection"},"type":"scratch","pressed":true,"title":"Create Scratch Note","canToggle":true,"opts":{"title":"Create Scratch Note","iconOff":"new-file","iconOn":"menu-selection","type":"scratch"}}]}
{"level":30,"time":1607170817022,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"c:run","msg":"pre-execute"}
{"level":30,"time":1607170817023,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"LookupCommand:execute","opts":{"noteType":"scratch","selectionType":"selection2link","flavor":"note"},"msg":"enter"}
{"level":30,"time":1607170817023,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"LookupCommand:execute","profile":0,"msg":"postCreateController"}
{"level":30,"time":1607170817024,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"LookupCommand:execute","profile":1,"msg":"post:extractRange"}
{"level":30,"time":1607170817024,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"LookupControllerV2:show","msg":"enter","cleanOpts":{"ignoreFocusOut":true}}
{"level":30,"time":1607170817025,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"LookupControllerV2:show","profile":0,"msg":"post:createQuickPick"}
{"level":30,"time":1607170817025,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"LookupControllerV2:show","profile":0,"msg":"post:createProvider"}
{"level":30,"time":1607170817025,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"updatePickerBehavior","activeButtons":[{"iconPathNormal":{"id":"link"},"iconPathPressed":{"id":"menu-selection"},"type":"selection2link","pressed":true,"title":"Selection to Link","canToggle":true,"opts":{"title":"Selection to Link","iconOff":"link","iconOn":"menu-selection","type":"selection2link"}},{"iconPathNormal":{"id":"new-file"},"iconPathPressed":{"id":"menu-selection"},"type":"scratch","pressed":true,"title":"Create Scratch Note","canToggle":true,"opts":{"title":"Create Scratch Note","iconOff":"new-file","iconOn":"menu-selection","type":"scratch"}}]}
{"level":30,"time":1607170817026,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"LookupCommand:execute","profile":3,"msg":"post:show"}
{"level":30,"time":1607170817027,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"LookupControllerV2:show","profile":0,"msg":"post:updatePickerBehavior"}
{"level":30,"time":1607170817027,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"LookupControllerV2:show","profile":0,"msg":"post:provide"}
{"level":30,"time":1607170817028,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"LookupControllerV2:show","profile":0,"msg":"exit"}
{"level":30,"time":1607170817028,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"c:run","msg":"post-execute"}
{"level":30,"time":1607170819892,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"updatePickerItems","msg":"enter","queryOrig":"e","source":"onValueChange"}
{"level":30,"time":1607170819940,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"updatePickerItems","msg":"exit","queryOrig":"e","source":"onValueChange","profile":48,"cancelled":false}
{"level":30,"time":1607170820207,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"updatePickerItems","msg":"enter","queryOrig":"er","source":"onValueChange"}
{"level":30,"time":1607170820209,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"createPickerItemsFromEngine","msg":"first query"}
{"level":30,"time":1607170820228,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"createPickerItemsFromEngine","msg":"post:queryNotes"}
{"level":30,"time":1607170820258,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"createPickerItemsFromEngine","msg":"engine.query","profile":49}
{"level":30,"time":1607170820258,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"updatePickerItems","msg":"exit","queryOrig":"er","source":"onValueChange","profile":51,"cancelled":false}
{"level":30,"time":1607170820379,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"updatePickerItems","msg":"enter","queryOrig":"err","source":"onValueChange"}
{"level":30,"time":1607170820379,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"createPickerItemsFromEngine","msg":"first query"}
{"level":30,"time":1607170820391,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"createPickerItemsFromEngine","msg":"post:queryNotes"}
{"level":30,"time":1607170820402,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"createPickerItemsFromEngine","msg":"engine.query","profile":23}
{"level":30,"time":1607170820403,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"updatePickerItems","msg":"exit","queryOrig":"err","source":"onValueChange","profile":24,"cancelled":false}
{"level":30,"time":1607170820498,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"updatePickerItems","msg":"enter","queryOrig":"erro","source":"onValueChange"}
{"level":30,"time":1607170820498,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"createPickerItemsFromEngine","msg":"first query"}
{"level":30,"time":1607170820502,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"createPickerItemsFromEngine","msg":"post:queryNotes"}
{"level":30,"time":1607170820543,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"createPickerItemsFromEngine","msg":"engine.query","profile":44}
{"level":30,"time":1607170820543,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"updatePickerItems","msg":"exit","queryOrig":"erro","source":"onValueChange","profile":45,"cancelled":false}
{"level":30,"time":1607170820625,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"updatePickerItems","msg":"enter","queryOrig":"error","source":"onValueChange"}
{"level":30,"time":1607170820625,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"createPickerItemsFromEngine","msg":"first query"}
{"level":30,"time":1607170820629,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"createPickerItemsFromEngine","msg":"post:queryNotes"}
{"level":30,"time":1607170820634,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"createPickerItemsFromEngine","msg":"engine.query","profile":8}
{"level":30,"time":1607170820634,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"updatePickerItems","msg":"exit","queryOrig":"error","source":"onValueChange","profile":9,"cancelled":false}
{"level":30,"time":1607170821605,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"onDidAcceptSingle","msg":"enter","value":"error","opts":{"flavor":"note"},"selectedItems":[{"fname":"Create New","id":"79346629-768f-46b3-84b7-bd3b4c918355"}],"activeItems":[{"fname":"Create New","id":"79346629-768f-46b3-84b7-bd3b4c918355"}]}
{"level":30,"time":1607170821605,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"onAcceptNewNode"}
{"level":30,"time":1607170821606,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"onAcceptNewNode","msg":"createNewPick","value":"error"}
{"level":30,"time":1607170821607,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"onAcceptNewNode","msg":"create normal node"}
{"level":30,"time":1607170821607,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"onAcceptNewNode","msg":"post:maybeAddSchema"}
{"level":30,"time":1607170821608,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"onAcceptNewNode","msg":"pre:checkNoteExist","uri":{"$mid":1,"path":"/c:/Users/Bassmann/Software/Dendron-new/gitjournal/error.md","scheme":"file"}}
{"level":30,"time":1607170821609,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"onAcceptNewNode","msg":"pre:pickerOnCreate","uri":{"$mid":1,"path":"/c:/Users/Bassmann/Software/Dendron-new/gitjournal/error.md","scheme":"file"}}
{"level":30,"time":1607170821609,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"onAcceptNewNode","msg":"pre:engine.write","uri":{"$mid":1,"path":"/c:/Users/Bassmann/Software/Dendron-new/gitjournal/error.md","scheme":"file"}}
{"level":30,"time":1607170821624,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"onAcceptNewNode","msg":"engine.write"}
{"level":30,"time":1607170821772,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"WindowWatcher:onDidChangeActiveTextEditor","msg":"enter","uri":{"$mid":1,"fsPath":"c:\\Users\\Bassmann\\Software\\Dendron-new\\gitjournal\\error.md","_sep":1,"external":"file:///c%3A/Users/Bassmann/Software/Dendron-new/gitjournal/error.md","path":"/c:/Users/Bassmann/Software/Dendron-new/gitjournal/error.md","scheme":"file"}}
{"level":30,"time":1607170821786,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"showDocAndHidePicker","msg":"showTextDocument"}
{"level":30,"time":1607170821789,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"VaultWatcher:onDidCreate","uri":{"$mid":1,"fsPath":"c:\\Users\\Bassmann\\Software\\Dendron-new\\gitjournal\\error.md","_sep":1,"path":"/c:/Users/Bassmann/Software/Dendron-new/gitjournal/error.md","scheme":"file"}}
{"level":30,"time":1607170821897,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"refreshTree"}
{"level":30,"time":1607170821900,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"TreeView:getChildren","msg":"reconstructing tree"}
{"level":30,"time":1607170856549,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"d:run","msg":"pre-execute"}
{"level":30,"time":1607170856564,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"d:run","msg":"post-execute"}
{"level":30,"time":1607170856664,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"VaultWatcher:onDidDelete","uri":{"$mid":1,"fsPath":"c:\\Users\\Bassmann\\Software\\Dendron-new\\gitjournal\\error.md","_sep":1,"external":"file:///c%3A/Users/Bassmann/Software/Dendron-new/gitjournal/error.md","path":"/c:/Users/Bassmann/Software/Dendron-new/gitjournal/error.md","scheme":"file"}}
{"level":30,"time":1607170856774,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"refreshTree"}
{"level":30,"time":1607170856777,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"TreeView:getChildren","msg":"reconstructing tree"}
{"level":30,"time":1607170859070,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"WorkspaceWatcher:onWillSaveTextDocument","url":"c:\\Users\\Bassmann\\Software\\Dendron-new\\gitjournal\\error.md","reason":3,"msg":"enter"}
{"level":30,"time":1607170859200,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"VaultWatcher:onDidCreate","uri":{"$mid":1,"fsPath":"c:\\Users\\Bassmann\\Software\\Dendron-new\\gitjournal\\error.md","_sep":1,"path":"/c:/Users/Bassmann/Software/Dendron-new/gitjournal/error.md","scheme":"file"}}
{"level":30,"time":1607170859310,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"refreshTree"}
{"level":30,"time":1607170859312,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"TreeView:getChildren","msg":"reconstructing tree"}
{"level":30,"time":1607170916163,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"WindowWatcher:onDidChangeActiveTextEditor","msg":"enter","uri":{"$mid":1,"fsPath":"Untitled-1","_sep":1,"external":"untitled:Untitled-1","path":"Untitled-1","scheme":"untitled"}}
{"level":30,"time":1607170959077,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"c:run","msg":"pre-execute"}
{"level":30,"time":1607170959078,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"execute","opts":{}}
{"level":30,"time":1607170959107,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"c:run","msg":"post-execute"}
{"level":30,"time":1607170959321,"pid":9364,"hostname":"Bassmann","name":"dendron","ctx":"WindowWatcher:onDidChangeActiveTextEditor","msg":"enter","uri":{"$mid":1,"fsPath":"c:\\Users\\Bassmann\\AppData\\Roaming\\Code\\logs\\20201205T131059\\exthost1\\dendron.dendron\\dendron.log","_sep":1,"external":"file:///c%3A/Users/Bassmann/AppData/Roaming/Code/logs/20201205T131059/exthost1/dendron.dendron/dendron.log","path":"/c:/Users/Bassmann/AppData/Roaming/Code/logs/20201205T131059/exthost1/dendron.dendron/dendron.log","scheme":"file"}}

This is expected. Rename is supported but refactor is not. This will most likely land next week.

So refactoring is one of the capabilities missing in multi vault atm?

yeah, you can refactor notes in your primary vault but if you involve notes
in an added vault, you will get an error
On Sun, Dec 6, 2020 at 10:46 AM Bassmann<EMAIL_ADDRESS>wrote:

So refactoring is one of the capabilities missing in multi vault atm?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dendronhq/dendron/issues/392#issuecomment-739545363,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADD52NI26CKC3DUCJFVBKDSTPGRVANCNFSM4UOQFNGQ
.

shipped in 0.20


Build a squid proxy quoin

@dragan commented on Thu Sep 14 2017
To CI the proxy configuration within the Kubernetes quoin, we need a squid proxy quoin to launch as part of an environment.

Some helpful documentation on understanding configuring Squid.


Add a malloc() library

Like https://github.com/mattconte/tlsf
Also could then use this to create a dynamic stack

Implemented with DLMALLOC


.net 8.0

EOL for .net 6.0 updates is November 2024. Update to next LTS release (.net 8.0) should be completed for EndlessClient and all dependencies. This includes:

EndlessClient project
EOLib.* projects
PELoaderLib
XNAControls
eolib-dotnet

the project itself is netstandard so should be fine, but the test code is net6.0, so it'd be a good idea to make sure this is up to date as well.

This is highly dependent on MonoGame support for .net 8.0.

https://www.reddit.com/r/monogame/comments/18lhtb4/net_8_meet_monogame/


Release request: 0.14.1

G'day,
Sorry to be a pain, but was wondering if the latest version could be released to crates.io as perhaps 0.74.1. Hoping to take advantage of #74, and as I release to crates.io, I'm unable to depend on the git version.
Cheers,
nick42d

No worries. Thanks for your PR. I have published the version as 0.14.1.
I still have missed to update the Changelog…

No worries. Thanks for your PR. I have published the version as 0.14.1. I still have missed to update the Changelog…

Thanks so much, it happens! If you consider automation at all in the future, I'd be happy to help you set up release-plz - as long as you following the commit naming conventions, it semi-automates the changelog and crates.io release for you. (https://release-plz.ieni.dev/)

Thanks for hinting to release-plz. Haven’t known this before. I have installed it and will see with next releases, if I want to make use of it or not.
BTW: the tags should be v0.14.1 or 0.14.1 ?

Thanks for hinting to release-plz. Haven’t known this before. I have installed it and will see with next releases, if I want to make use of it or not.
BTW: the tags should be v0.14.1 or 0.14.1 ?

Not sure on the tags. Release-plz uses vX.Y.Z by default so I just use that for my projects, but you can customise it if you prefer something else.


Source for openai/universe.flashgames

This is more of a request than an issue. Where can the source for openai/universe.flashgames image be found? Any plans for making the Dockerfile public?

Yep, we'll be releasing it in upcoming weeks, along with tools to integrate
new environments. Sign up for early access here:
https://docs.google.com/a/openai.com/forms/d/e/1FAIpQLScAiW-kIS0mz6hdzzFZJJFlXlicDvQs1TX9XMEkipNwjV5VlA/viewform
.

gdb

On Mon, Dec 5, 2016 at 11:31 AM, Shreyas Karnik<EMAIL_ADDRESS>wrote:

This is more of a request than an issue. Where can the source for
openai/universe.flashgames image be found? Any plans for making the
Dockerfile public?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/openai/universe/issues/14, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAM7kTTuwEQ1NvUKnQzhEihvRT1IKZBLks5rFGakgaJpZM4LEnnE
.

@gdb Thanks a lot for the swift reply!


Clean-up old files used when the package was in the monorepo

Refs. #6

Is the use of a symlink to ciDict.json an issue with the java implementation?


Read dataset with the end transaction RID

Replace branch name with transaction RID when reading a dataset

Released 0.5.0


nginx' buffering on kubeapi-loadbalancer is breaking kubectl

Hi,
I'm adding a Juju action to create and delete a docker registry, much like the currently existing "microbot" action. The creation works fine, but the deletion always fails, specifically the deletion of the replicationcontroller.
I found the root cause to be the bufferring of nginx in the kubeapi-loadbalancer unit. More specifically, when the "kubectl delete" action is run against a replicationcontroller, kubectl tries to monitor the "downscaling" of said replicationcontroller using a URL in the form of :
/api/v1/watch/namespaces/default/replicationcontrollers?fieldSelector=metadata.name%3Dkube-registry-v0

This "/watch/" URLs streams data, but because nginx buffers said data (presumably until the connection is closed from the client, which it never is because the client doesn't receive  data !), it never reaches the kubectl client. The connection is then closed by nginx, because of the "proxy_read_timeout  90;" config option.
This is fixed by adding the following to the nginx configuration :
proxy_buffering off;

However, I am no nginx expert, so I'm not sure if there are other consequences to turning off this buffering.
Thanks

@axinojolais I think we're good to enable this at least in the short term. I have a lofty goal of replacing this nginx load balancer with an haproxy based LB for better connectivity support.


FloatingGroup support in DragPane

Now you can use DragPane along with a FloatingGroup to create a true drop-and-drag-anywhere powerhouse.
This might slightly affect other widgets using DragPane (like TabbedPane) - I tested it locally with gdx-lml-vis-tests and it seems fine, but some additional checks are welcome.
Not sure is the behavior is correct, though. I could easily add a check that disallows dragging is the actor is outside of the original FloatingGroup bounds; right now you can drag an actor near group's border, where it basically "breaks" the bounds.
Note that Draggable$DragListener API changed. Draggable was added to each method, so you can check the source of the event. Some utility methods were added to DragPane to support other groups.

This is quite nice, originally I intended to only use FloatingGroup for keeping windows in bounds, turned out really nice if combined with DragPane.

I could easily add a check that disallows dragging is the actor is outside of the original FloatingGroup bounds;

I think you should include those checks, that way it would be consistent with VisWindoe#setKeepWithinParent which does not allow to break bounds if moved closely to edge.

Should it completely reject dragging if outside of bounds or just normalize the values and add the widget near an edge? I think first approach would be nicer.

Now actors are rejected when outside of drag pane bounds. I think it looks pretty nice, and you can always use draggable that keeps actors withing parent bounds (kind of like TabbedPane does) if you want window-like behavior.

Normalizing values would be better IMO, at least in case when you are using it to achieve window-like behavior, check this example, let's say user want to drag label to an edge, with this approach it requires placing it very precisely near an edge or it would be moved to starting position.

That's what Draggable#setKeepWithinParent(boolean) is for, isn't it? Normalizing values would cause "hick-ups" when dragging near edges.
Are there any real life examples why you'd want to normalize values, but still reject to use setKeepWithingParent(true)?

It's not about dragging, Draggable#setKeepWithinParent(boolean) is working correctly. It's about the moment when you release mouse button: if actor is outside bounds it will return to starting position where I think it should stay near that edge.
addToFloatingGroup would need to be changed like this:
		protected boolean addToFloatingGroup (final Draggable draggable, final Actor actor, final DragPane dragPane) {
			final FloatingGroup group = dragPane.getFloatingGroup();
			dragPane.stageToLocalCoordinates(DRAG_POSITION);
			float x = DRAG_POSITION.x + draggable.getOffsetX();
			if (x < 0f) {
				x = 0;
			} else if (x + actor.getWidth() > dragPane.getWidth()) {
				x = dragPane.getWidth() - actor.getWidth();
			}
			float y = DRAG_POSITION.y + draggable.getOffsetY();
			if (y < 0f) {
				y = 0;
			} else if (y + actor.getHeight() > dragPane.getHeight()) {
				y = dragPane.getHeight() - actor.getHeight();
			}
			actor.remove();
			actor.setPosition(x, y);
			group.addActor(actor);
			return APPROVE;

Yeah, I misunderstood. Now position is normalized when the draggable is set to be kept within parent. Otherwise it works as before to prevent from weird bugs with stageToLocalCoords. Trust me, it's better this way (TM).
Anyway, your example should now correctly handle edge cases, literally.

Yep it works now. Thanks.


Update hw-aeson and cardano-addresses

[x] Bump dependencies on hw-aeson to match cardano-addresses to match latest version.

Issue Number
ADP-1999

For the release, we do all the bumps in a single pull request. Closing.


HTML Entities

I was working with this for a project, and one of the things I wanted to do was use HTML entities in some of my Labels. When rendering from a list with other elements I see the rendered HTML entity as I would expect in my Label. When rendering a solo label with a HTML Entity I see the raw text.
More details. When I have no text typed, and I activate the Awesomplete it shows an unrendered Awesomplete label (raw HTML entities like you'd see in a text-editor).
Received

Desired (not including france, just the HTML entity)

Here's a CodePen
https://codepen.io/Lewiscowles1986/pen/PooMgXE?editors=1010
Known workaround
The workaround so-far has just been to paste the character literal in.
Background
This is also an example of Live AJAX listing which I know some people have asked for.
I'm unsure if it's the best pattern, and sure writing my own debounce and using native DOM would be more accessible to a wider group of people. It also really spams data.

I noticed your Codepen was using Awesomplete 1.0.0. This was fixed with 2015's 1.1 release https://github.com/LeaVerou/awesomplete/commit/6a6c8c1ccc2a50bdfa78cd9d5526dbd8afc723fa#diff-0861bfe5a8e20a86e84f647fe9e26358
Update to the current version, 1.1.15, and you won't have this issue. I was able to do this in the Codepen you provided.
I believe this can be closed!

Thanks @bbenjamin :heart: I'm very sorry for that

Hey @bbenjamin, thank you for helping people in issues! Would you like to be added as a contributor?

Happy to help, you can definitely add me as a contributor @LeaVerou!
Some context: Awesomplete is currently my (and several others) preferred replacement for jQuery UI autocomplete in Drupal core. jQuery UI has reached end-of-life so it must be phased out and replaced. In particular, Awesomplete has the best accessibility of all the options evaluated. I figured I'd extend my appreciation for Awesomplete existing by helping out.

Thank you for the context, and the willingness to help! I'm spread way too thin, so any help is very appreciated. Just sent the invitation!


Add Link header for client tests

Currently the endpoints for clients are only advertised in HTML, so it's not possible to test clients that only support the Link header.

Fixed in 58ddd7bb0d05f861b0938aa96747b1bf72f4606f


Use Stable Rust

Since we are now in serious business and publishing crates, let's move back to stable Rust.
https://twitter.com/en_JS/status/1676484656575946753

It would be really nice if it didn’t rely on nightly Rust. Nightly is cool for apps, but not for infra that others will build on.

To get started, change rust-toolchain.toml's channel to the latest <major.minor.patch>
(1.71.0) version, and run cargo check and fix all the code ;-)

Oh no we need to remove portable_simd 😢 Unless we can find a stable simd.

Released all crates as v0.1.0 🥳
https://crates.io/crates/oxc


Testing relnotes application... to be closed soon

I've labeled this with documentation, so I'm really hoping that no other labels are applied

Woohoo! Confirmed!


wallet_account_update_active_key fails with "unable to parse new active key" if key is given as argument

default (unlocked) >>> wallet_account_update_active_key xxxxxxxxxxxx xxxxxxxxxxxx BTS5DCxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
10 assert_exception: Assert Exception
new_private_key.valid(): Unable to parse new active key.

Looks like the parameter should be a private key, but BTS5DCxxxxxxxxxx is a public key?

dang ..
you are write .. though it could be an address but the help indeed states it requires a wif..
sorry for the interrupt
closing


Syntax error for JSON input

ERROR:  syntax error at or near "[" of jsonpath input
STATEMENT:  SELECT jsonb_agg(v)#>>'{}' FROM (SELECT jsonb_path_query(jsonb_path_query(data, '$[*] ? (@."$schema" == $schema)', ('{"schema":"' || $1 || '"}')::jsonb), $2::jsonpath) AS v FROM dataset WHERE id = $3) AS values

Do you have any steps of reproducing this? From grepping it's a query in DatasetServiceImpl.queryData.

This could be user input that is causing this query not to be syntactically correct. The parameter $2 supplies a jsonpath.
Can this issue still be reproduced ?

Closing for now, no steps to reproduce


Releaser

We can not merge it yet. Each package has a different version, let's use @jupyter-notebook/ydoc v0.2.0-alpha.1 a bit and make a 0.2.3 release of both packages to sync the version.
The version of both packages is aligned now.

I opened https://github.com/agoose77/hatch-nodejs-version/pull/15 to improve the hatch plugin

Using hatch-nodejs-version, hatchling takes the python version from the package.json. That means we need to include the package.json in the python build.

@meeseeksdev please backport to main