add a comment for the variable channel

Add an other example for the Chanel ID variable.
in case of error :"Chat not found", when use in ID as integer format

Hi,
Happy new year.
I don't know, this is juat a readme file.
The vps example is just an example. I'm running this project flon my own
linux server.
Have you an example with pinescript alert to send more easily tradingview
data, in json format ?
Regards
Le sam. 1 janv. 2022 à 17:29, Fabston @.***> a écrit :

@.**** requested changes on this pull request.
Wont approve PR with given changes.
In README.md
https://github.com/fabston/TradingView-Webhook-Bot/pull/83#discussion_r777120759
:

@@ -39,13 +39,13 @@ All alerts can be instantly sent to Telegram, Discord, Twitter and/or Email.

💡 Got a feature idea? Open an issue and I might implement it.

Installation
-> ⚠ Best to run the bot on a VPS. I can recommend Hetzner's CX11 VPS for 2.89€/month. Sign up now and receive €20 free credits.
I do not fully understand why that line was uncommented. As mentioned "its
best to run it on a VPS".
—
Reply to this email directly, view it on GitHub
https://github.com/fabston/TradingView-Webhook-Bot/pull/83#pullrequestreview-842346174,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIMIWKSDTCAI7VBP6O2RB6DUT4TXVANCNFSM5KHRTUXA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>

Hi,
Happy new year.
I don't know, this is juat a readme file.
The vps example is just an example. I'm running this project flon my own
linux server.
Have you an example with pinescript alert to send more easily tradingview
data, in json format ?
Regards
Le sam. 1 janv. 2022 à 17:29, Fabston @.***> a écrit :

@.**** requested changes on this pull request.
Wont approve PR with given changes.
In README.md
https://github.com/fabston/TradingView-Webhook-Bot/pull/83#discussion_r777120759
:

@@ -39,13 +39,13 @@ All alerts can be instantly sent to Telegram, Discord, Twitter and/or Email.

💡 Got a feature idea? Open an issue and I might implement it.

Installation
-> ⚠ Best to run the bot on a VPS. I can recommend Hetzner's CX11 VPS for 2.89€/month. Sign up now and receive €20 free credits.
I do not fully understand why that line was uncommented. As mentioned "its
best to run it on a VPS".
—
Reply to this email directly, view it on GitHub
https://github.com/fabston/TradingView-Webhook-Bot/pull/83#pullrequestreview-842346174,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIMIWKSDTCAI7VBP6O2RB6DUT4TXVANCNFSM5KHRTUXA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>


[AutoRelease] t2-apimanagement-2021-03-17-10034(Do not merge)

https://github.com/Azure/sdk-release-request/issues/1361

need to confirm tag


Fixes tiny error in docucomments regarding the horizon() fns

Hi there! I came across this project and was browsing the source when I noticed that the documentation strings for the non-test connection fns were erroneous. This tiny PR fixes that.

Thank you!

My pleasure; thanks for writing the client!


Add size = None option to v2 Resize

Addresses new feature request opened in #8358
Looking for feedback regarding v1 compatibility issues / potential workarounds for that.

Just pushed some changes @NicolasHug! Lmk if you have any thoughts

Just pushed some changes @NicolasHug! Lmk if you have any thoughts


Added :<>=, :<=, :>=, :#=

Background
In general, Chisel's connection operators are very broken; their semantics change depending on import Chisel._ vs import chisel3._. Even chisel3._'s semantics are not clean; you cannot reason about what will be connected to what unless you know whether the things you are connecting are Wires or IOs. Part of this stems from the fact that we got rid of relative-flippedness for declaring things, instead relying on using Input/Output.
This PR defines four new operators which have very clean semantics which depend solely on the hardware type of the things you are connecting. Using them, we plan to migrate all existing operators semantics to compositions of them, but for now we define them independently of Chisel/chisel3, and thus they have more verbose syntax to make them compatible with both imports.
As we continue, we may rename them etc., but their semantics are composable which is an important property. In fact, there are only actually two operators which, when composed in different ways, can implement the semantics of other kinds of operators: :<= and :>=. While these operators may not be the most common ones to use, understanding them will help users reason about how all the connection operators work.
I've written a lot of ScalaDoc to describe their semantics. Future work can write more explanative material (mdoc etc.) to flesh out them in more detail.
Update: I've adding the Defaulting type, and it the operators will assign default values to unassigned fields, rather than erroring.
TODO:

Update docs to clarify strictness guarantees
Write mdoc
Brainstorm names for Defaulting
Improve the tests, I'm not happy with their structure, and they aren't testing :<= and :>=

Current requested reviewer feedback

ScalaDoc explanations are clear (and mdoc once written)

Contributor Checklist

[x] Did you add Scaladoc to every public function/method?
[x] Did you add at least one test demonstrating the PR?
[x] Did you delete any extraneous printlns/debugging code?
[x] Did you specify the type of improvement?
[ ] Did you add appropriate documentation in docs/src?
[x] Did you state the API impact?
[x] Did you specify the code generation impact?
[x] Did you request a desired merge strategy?
[x] Did you add text to be included in the Release Notes for this change?

Type of Improvement

new feature/API

API Impact

No impact on current code. Adds new operators and documentation.
Desired Merge Strategy

Squash: The PR will be squashed and merged (choose this if you have no preference.

Release Notes

Added new operators :<>=, :<=, :>=, :#=
Added new Scaladoc to :=, <>

Reviewer Checklist (only modified by reviewer)

[ ] Did you add the appropriate labels?
[ ] Did you mark the proper milestone (Bug fix: 3.4.x, [small] API extension: 3.5.x, API modification or big change: 3.6.0)?
[ ] Did you review?
[ ] Did you check whether all relevant Contributor checkboxes have been checked?
[ ] Did you do one of the following when ready to merge:

[ ] Squash: You/ the contributor Enable auto-merge (squash), clean up the commit message, and label with Please Merge.
[ ] Merge: Ensure that contributor has cleaned up their commit history, then merge with Create a merge commit.

implements part of https://github.com/chipsalliance/chisel3/issues/2643

Closed in favor of #2806


vid2vid Only 1 frame generated? - on mac

Using macOS, I seem able to generate only 1 frame? then it does not seem to process anymore.
Frames prepared: 1 / 488; Frames processed: 1 / 488

Same here on windows, no visible errors. I have the latest auto1111 webui

Same for me on Windows with the latest A1111 webui

Same

#33 same error, I think is because the resolution?

This seems like a temporary solution, this worked for me. https://github.com/volotat/SD-CN-Animation/issues/33#issuecomment-1537991750

Vid2Vid works fine for me, but only one frame when trying to generate txt2vid...

I had the same issue, but I stumbled upon the fix. Just hoover over the height/width integer input boxes and select one of the suggested values.  The width/height for my video was not valid.

mine stops at 11 frames, it will infer twice and then just looks like its done

i also noticed that , when i had kitchen theme extension installed, this happened, i disabled that and restart and worked fine. (could be wrong as well)  because i did changed resolution as well

mine stops at 11 frames, it will infer twice and then just looks like its done

I eventually had this issue too. Turned out to be this setting turned on "Apply color correction to img2img results to match original colors"

This worked for me! Thanks.

Is this issue still relevant in the last version?

Is this issue still relevant in the last version?

It does not like "Apply color correction"-setting. I'm not sure about the resolution though. Thanks for this tool!

Is this issue still relevant in the last version?

Yes, very :)


include procps in RUN_DEPS

It's tiny, and pretty handy for debugging.

Added half a meg to the image size, for the record:


Upgrade CUDA to 11.6 Update 2?

Checklist

[X] I've read the contribution guidelines.
[X] I've searched other issues and no duplicate issues were found.
[X] I've agreed with the maintainers that I can plan this task.

Description
"All versions prior to CUDA Toolkit 11.6 Update 2" have a security risk.
https://nvidia.custhelp.com/app/answers/detail/a_id/5334
Purpose
To resolve the risk.
Possible approaches
Update the versions in ansible/playbooks/universe.yaml.
https://github.com/autowarefoundation/autoware/blob/b260f67085dda5c0161ade051b236a3fbdee4147/ansible/playbooks/universe.yaml#L6-L8
Definition of done
The versions are updated and the build CI passes.

@mitsudome-r @xmfcx @yukkysaito @esteve What do you think about this?

It seems there is no 11.6 for libnvinfer yet.
https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/

is it possible to mix the rest of CUDA 11.6 with libnvinfer-plugin 11.4? If not, I'd wait until the new version is released.

Actually, I believe it's impossible. We have to wait for the release in any case.
Also, I'm concerned about the dependencies in https://github.com/autowarefoundation/autoware.universe.
@yukkysaito knows well about this.

To be sure, I am currently checking tit works properly with cuda 11.4.
After that, I will check it works with cuda11.6.

The new version should be available in both x86_64(amd64) and sbsa(arm64).
https://github.com/autowarefoundation/autoware/pull/154#issuecomment-1099745019
https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/
https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/sbsa/

I've created a helper tool to find CUDA versions.
https://github.com/kenji-miyake/find-cuda-versions
Now we can find if there are any corresponding versions to a certain CUDA version.
$ find-cuda-versions --cuda 11.6
[cudnn x86_64]
<IP_ADDRESS>-1+cuda11.6

[cudnn sbsa]
<IP_ADDRESS>-1+cuda11.6

[tensorrt x86_64]

[tensorrt sbsa]


Code Hierarchy Node Parser

Description
Moved from https://github.com/run-llama/llama_index/pull/7450
Type of Change
Please delete options that are not relevant.

[X] New Loader/Tool

How Has This Been Tested?
Every language is extensively tested in pytest
Checklist:
The following items need to be completed before moving out of draft:

[ ] Fix the unit tests and make compatible with newest LLama Index version
[ ] I have added a library.json file if a new loader/tool was added
[ ] I have removed all TODO's from the Readme
[ ] I have updated the Jupyter notebook
[ ] The keyword indexer is tested and does not require an LLM
[ ] I ran make format; make lint to appease the lint gods

[ ] Fix from the jupyter notebook:

---------------------------------------------------------------------------
ModuleNotFoundError                       Traceback (most recent call last)
Cell In[19], [line 1](vscode-notebook-cell:?execution_count=19&line=1)
----> [1](vscode-notebook-cell:?execution_count=19&line=1) from llama_hub.file.code.code_hierarchy import CodeHierarchyNodeParser
      [2](vscode-notebook-cell:?execution_count=19&line=2) from llama_index.text_splitter import CodeSplitter
      [3](vscode-notebook-cell:?execution_count=19&line=3) from llama_index.readers import SimpleDirectoryReader

ModuleNotFoundError: No module named 'llama_hub'


bitfinex is doesn't support anymore

i was wondering whether this support kraken since  bitfinex no longer support or margin trading

What are you talking about? Bitfinex is still supporting Margin trading.


Support parquet file format

Describe the new feature being added
It would be good if this can support parquet files since they can be loaded and saved much faster than CSV files. This is more apparent as the size of the file begins to grow. source
How will this feature improve this extension
I think this is an even better use case for what has been built. Although it is useful to edit CSV's, the native jupyterlab editor can do that. Since the parquet format is not human readable, it is not possible currently for a user to modify that without loading it into pandas and then resaving it.
Additional context
Utilize existing library: https://github.com/ironSource/parquetjs

Would you like it to be read-only, or editable?


Update the cookiecutter

Fixes #11
Grab the latest changes from upstream: https://github.com/jupyterlab/extension-cookiecutter-ts

Looking good when trying the cookiecutter in a fresh environment:


requierements.txt should have also the hash of the files

I just like in mozapkpublisher
https://github.com/mozilla-releng/mozapkpublisher/pull/210/files

@sylvestre can I work on this issue?

Sure, please see https://github.com/mozilla/relman-auto-nag/pull/768 before


Design the new About us page

The new page will have the following blocks :

Hero
Team members
Values
History
Investors
Benefits
Opened positions / CTA to join us

Debrief with @lpinot (29/06/2022)
Hero block:

Should we keep this sentence as the Hero block, or should we change it to something else? @mdubus

Team members:

Tests should be made on the cards, to find the right balance between info and design @lpinot
The link could point to the public Notion page of every team member as it is more "human" than a Linkedin page (+ it has the location of everyone) @lpinot
The pain point would be the photos of everybody. Ideally, we would need everybody's picture with a white or green background @mdubus
We should avoid having a carousel as some profiles would be highlighted when others would be hidden. Everybody should be on an equal footing @lpinot

Values

Do we want paragraphs? Small sentences? How do we want our values to be represented? @mdubus

History

We talked about having:

A timeline with the important dates (fundraisings, Cloud release, ...)
A speech from the co-founders

Should we keep both? @lpinot
Benefits

How many Perks & Benefits do we want to have max.? We would need at least the titles @mdubus

Opened positions

Check if they are easy to retrieve from Lever, and which info we can get @mdubus
Make the design @lpinot

💡 The list of the missing information has been sent to the people involved on the 5th of July 2022

Hero block
For lack of a better idea, I think key numbers and a small presentation text is ok for now. For key numbers:

the date of creation of the company: end of 2018 instead of 4 years old
the number of team members: 30
the amount of funds we have raised up to here (2 rounds of funding, 7M USD total)

The presentation text we have for Meilisearch (present in job ads) is enough for now. I'll work on an update in the months to come.
Team

Our team vs. Our Marvelous Team
Adding links to each team member's public Notion page is 👍
Photos: ideally we would like to have an “official” individual photo for everyone. This will happen by batch, on the occasion of an offsite or other reunion. We will hire a photographer. In the meantime a personal picture will be asked for each person.

Remote working
I'd like to add a specific section about this, as it's embedded in our culture and way of working. I'd like to add this text, please let me know what you think:
When you join Meilisearch you are free to come to our Paris office, or work remotely. 80% of us are working remotely today. Here's what you need to know:
- Most of us in France, some of us are in Europe and other parts of the world (Middle East, Africa, South America).
- We’re 100% ok with international hires. Our only condition is for you to share at least 4 hours of work with the France time zone (CET).
- If you are an international hire, you will either have a contractor agreement with us, or a local employment contract through a PEO (Oyster HR).
- We are learning to work asynchronously. It’s not perfect yet, but we’re getting there. The tools we use are:
    - GitHub for code & project management
    - Notion for collaborative working and team work spaces
    - Slack for instant messaging
    - Zoom, Google Meet or Around for calls
    - Figma for design
- As a remote hire, you will have access to the [[Fleex](https://en.fleex.com/)](https://en.fleex.com/) platform (Europe) or a stipend for your home office equipment.
- We reimburse up to 500$/month for co working spaces.

Values
I like having a small phrase + a short paragraph for each value:
Commitment
We are passionate about what we do
At Meilisearch we all do what we do because it's what we love doing. We try to keep a healthy balance between work and passion.
We care about the project
we are all very committed to making Meilisearch a successful project, which goes beyond our individual job scopes
We disagree and commit
For us being committed also means being opinionated and therefore disagreeing. Often. About a lot of things. We try to do this in a constructive way that helps us move forward.
Quality & simplicity
We prefer quality over rapidity
Building an open-source project means respecting certain standards and paying close attention to the work we produce and show. We would rather be rigorous than rapid.
We are pragmatic
We believe that aiming for perfection is counterproductive. We stand by the adage "done well today is better than perfect next week".
Openness
We give back to open-source what it gave to us
We are providing a high-quality search solution, accessible to all, no matter their financial means. We take pride in building a great solution thanks to the feedback of our community.
We want to put sharing and collaboration at the basis of what we do.
We find solutions together
One thing we know for sure is that no one knows everything. We are constantly learning from others and are not afraid to say, "I don't know"
We value diverse views and backgrounds
Meilisearch was built thanks to each team member's personality, skills, and experience. We are interested in welcoming people from diverse backgrounds, cultures, and opinions as we believe it is the only way to build a long-lasting company.
Benefits

4 day work week
Stock options
Well being program:

Mental well being: 6 coaching and mental health care sessions per year
Physical well being: access to [Gymlib](https://gymlib.com/en/employee-offer) or reimbursement of 60€/month (equipment, classes, gym membership…).

3 months fully paid parental leave for birth givers and second parents, no matter where you are in the world,
6 weeks paid time off.

Open positions
A link towards our Lever page seems sufficient.

Photographer
The person we have hired is a freelancer, who works for Welcome to the Jungle and who did our pictures for the last version of our company page. We will ask him to bring the equipment necessary to the headshots.
Benefits text display
😎 [4 day work week](https://blog.meilisearch.com/how-we-implemented-the-4-day-work-week/)
No meetings or Slack messages on Fridays; you’re free to work, or not.
📈 Stock options
We offer stock options to all team members with long term contracts.
🧘 Well-being program
We offer solutions to support team members with their physical and [mental](https://blog.meilisearch.com/our-first-steps-to-support-the-mental-health-of-our-team-members/) well-being.
🏝 Time off
We offer 6 weeks of paid time off per year.
👶 Parental leave
Birth givers and second parents can take a fully paid leave of 3 months to take care of their new born child.
🩺 Health insurance
We offer health insurance options for all team members.

Meeting with @lpinot and @morganeff (19th of September)
Morgane N. validated the designs. A photograph also came on the 20th of September to take shots of (almost) everybody.
If someone doesn't want to have his face on the page, we could replace it with an emoji of his choice.
What remains to do
We considered adding a carousel with pictures of the whole team.
The Investors block should also evolve to welcome more and more investors for the future :)
Next steps
Léna will now decline the designs for other devices (mobile + tablet), and the development phase should start soon after.

25th October
Beginning of the development phase.


chore(nextjs): improve "subscription.stop" using variables instead of hooks

Maybe we can improve this custom hook a little bit by reducing the dependency of the React lifecycle using only JavaScript variables.
[ useSubscriptionContextWrapper ]

Checklist

[ ] run make test
[ ] PR title must follow conventional-commit-standard
[ ] tests and/or benchmarks are included
[ ] documentation is changed or added
[ ] commit message and code follows the Code of conduct

I think it makes sense to me, let me verify.


[Wallet] Pagination of ETH txs is broken

https://user-images.githubusercontent.com/61792675/120476556-ffe53480-c3aa-11eb-9e10-4b8b99d83e03.mp4

depends on https://github.com/xchainjs/xchainjs-lib/issues/343


Cannot  push saved tarball as rootFs is missing in json. Invalid image config (rootFS is not set)

Hi,
Nice project , i am using it for rootless world .
I am trying to push toregistry a saved tarball to dockerhub with skopeo but it seems that the tarball is missing some data like rootfs.
FATA[0000] determining manifest MIME type for docker-archive:///workspaces/umoci/popo.tar: Invalid image config (rootFS is not set): 93dc8da4000dde62aefe8ed8c2647b711e6ffe9c6940d6e0e61c18c2d001ca5c.json
here is the full use case : (pulling alpine , make some changes , export container , import container , save image )

May be ma i missing something in the workflow ?
Thx,

Here is the tarball:
savedImage_.zip

This is now implemented in the Devel3 branch. The limitation was in the import when udocker creates the metadata.
Please check.

I have tested it on devel3 Branch. It works !
Thanx a lot!

closing it

release 1.3.11 published


hardcode --filter-uneven-sized-batch

See https://github.com/k2-fsa/icefall/pull/843#issuecomment-1386454863

Thanks!


Make use of iptablesPath variable which has the path of iptables, instea...

...d of using string iptables directly

Can you please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "master" git@github.com:gaurav-gosec/docker.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -f

This will update the existing PR, so DO NOT open a new one.

LGTM

LGTM


Enhance the submit and movies button

As the website is so interactive to make it more responsible Enhance the contact us and watch videos and movies to list the movies
can you please assign this issue under GSSOC extd'24.

hii @aslams2020    i believe i can do this task efficiently as i have a strong hold over css styling. could you please assign me this task under GSSoC24 extd and hactoberfest24.

please assign me with the task @aslams2020

Make sure to Follow the website theme

@Saketh1714 Are u working on it?

Yaa I will be completing by Wednesday.

is it completed @Saketh1714

Noo


fix issue #10

fix issue #10 , error when predicting

Maybe include also a fix to the typo label_feild -> label_field? it seems appropriate for this pr


Player does not forward texture uniforms properly in some cases

Tried to build Eidolon with the Python3 version and got very broken outputs in the landscape.
I don't think the Python3 part is related, just that the C++ code at that time was different from what it is now.
The codegen is a nightmare so I am tempted to redo the player code in a more debuggable fashion and see how large it becomes.

This work is ongoing in the th/py3_new_player branch


Update prepare-commit-msg +semver: minor

Closes #
📑 Description

✅ Checks

[X] My pull request adheres to the code style of this project
[X] My code requires changes to the documentation
[X] I have updated the documentation as required
[X] All the tests have passed

☢ Does this introduce a breaking change?

[ ] Yes
[X] No

ℹ Additional Information

@gstraccini csharpier


wolfictl: use the sdk rather than the old wolfictl image

@rawlingsj can you rebase?

thanks all done

once this merges we can re-run the update digest action so all the sdk images are using the same digest.  We just did a new tools release.


Use VSS for backing up LDK Gateway's channel state

Similar to https://github.com/fedimint/fedimint/issues/5853, but we should use VSS so that LDK Gateway can backup its channel state.
https://github.com/lightningdevkit/vss-server
https://github.com/lightningdevkit/vss-rust-client

@dpc @maan2003 This looks very interesting for client backups too!


Hover-over link icons

This PR addresses #21 using the Anchor.js library.
cc @ilovett

@rathpc Thanks for the review! I'll merge the PR now.

@lucperkins Thanks for the PR! This makes linking certain sections of the doc pages much more convenient, e.g.:


Remove Travis CI badging and update README and CONTRIBUTING.

We haven't had a green travis build in a very long time.
Also, with the addition of Spanner, the master jobs reach the max time limit on Travis and just timeout anyway.

Also, with the addition of Spanner, the master jobs reach the max time limit on Travis and just timeout anyway.

This was true before Spanner.
I am :+1: on this but would rather we finish the migration from Travis to CircleCI first.

@dhermes what's missing in CiricleCI besides the PR builds only building/testing the changed services?

the PR builds only building/testing the changed services
doing the same on merge builds (ci-diff-helper supports this)
making docs script less Travis specific
other parts of the iceberg?

This is superceded by #3146.


refactor(http): Uniform debug message from the http hanlder

Reason for This PR
Better debug log messages for the http handler
issue #480
Description of Changes
Update log.Debug message structure to include all needed information. Debug messages from the log will be in the form of:
{"remote": "<IP_ADDRESS>", "ts": "3.273883ms", "resp.status": 201, "method": "GET", "uri": "http://localhost:10084/?hello=world"}
License Acceptance
By submitting this pull request, I confirm that my contribution is made under
the terms of the MIT license.
PR Checklist

[x] All commits in this PR are signed (git commit -s).
[x] The reason for this PR is clearly provided (issue no. or explanation).
[x] The description of changes is clear and encompassing.
[x] Any required documentation changes (code and docs) are included in this PR.
[x] Any user-facing changes are mentioned in CHANGELOG.md.
[x] All added/changed functionality is tested.

linked #368


data-vv-scope is not working

Versions:

VueJs: 2.1.3
Vee-Validate: 2.0.0-beta.15

Description:
data-vv-scope is not working. It's not working in your demo either. Getting lots of console warns for the following.
"Trying to validate a non-existant field: "0". Use "attach()" first."
Steps To Reproduce:
See your demo http://vee-validate.logaretm.com/examples#scope-example

Thank you for the report! This was fixed already: https://github.com/logaretm/vee-validate/issues/148 Upgrade to beta.17 if you are able :)

Thanks. I apologize. I downloaded the plugin just a day or two ago and thought I was on the latest already. It does indeed work.

Using scopes was working fine in 2.0.0 rc18 for me.
I updated to 2.0.5 and it broke.
A coworkers was broken as well, and he was on 2.0.0 rc25
We had to revert to rc18 to get our vue files to work again.
We had errors with cannot find password of undefined... and the entire component was not displaying.
I'm not sure if this is related, but maybe its a regression?

@gpickin Could be an issue or a implementation choice that was introduced later, do you mind creating an example demonstrating the issue, will be happy to take a look and fix it if its an issue.

I will try to.
It was just a simple input validation.
<input  							data-vv-scope="about" 							type="tel"  							name="phone"  							id="phone"  							v-validate="'phoneValidator'" 							v-model="editablePhone" 							:class="{'incorrect': errors.has('about.phone') }" 							required />


Update test.md

update to match existing concourse fly changes.

Kinda scary to have a default or recommended value of production :)


:SemanticArtefact class not defined

in mod-v2.0_ontology.owl, there are the following statements, but no declaration of :SemanticArtefact. I assume its' supposed to be mod:SemanticArtefact.  This is breaking.   ?maybe mod-v2.0_ontology.owl is deprecated???
line 3045:
https://w3id.org/mod#Taxonomy
mod:Taxonomy rdf:type owl:Class ;
rdfs:subClassOf :SemanticArtefact .
https://w3id.org/mod#Terminology
mod:Terminology rdf:type owl:Class ;
rdfs:subClassOf :SemanticArtefact .

Thanks @smrgeoinfo for spotting that. You are right - we're revising MOD as part of the FAIR-IMPACT project and we will make sure to fix this (we are working for version MOD 2.1)
This is the link to the line you refer to:
https://github.com/FAIR-IMPACT/MOD/blob/8a27405be5dbf19e4ea1a2b1a3c25c4d6615c55e/mod-v2.0_ontology.owl#L3045
Can I also point you to the design decisions discussions? https://github.com/FAIR-IMPACT/MOD/discussions
It would be great to get your views.

Assigning @biswanathdutta as he is the person that have produced the mod-v2.0_ontology.owl
I do confirm @agbeltran 's point on the fact that we are re-taking all of this in v2.1

in mod-v2.0_ontology.owl, there are the following statements, but no declaration of :SemanticArtefact. I assume its' supposed to be mod:SemanticArtefact. This is breaking. ?maybe mod-v2.0_ontology.owl is deprecated???

@smrgeoinfo Yes, it is mod:SemanticArtefact.
See here https://w3id.org/mod#SemanticArtefact

thanks @biswanathdutta @jonquet
but the problem that was raised was that the SemanticArtefact class was not defined in version 2.0
I've now created a pull request to resolve this issue, and of course, we will keep it and add more details in 3.0

This issue has been fixed in https://github.com/FAIR-IMPACT/MOD/pull/55 - and the SemanticArtefact class and definition will also be available for version 3.0


Support building Verus-verified components with ordinary stable Rust

So far, we've been using the verus executable to build and compile Verus projects in their entirety.  However, there are also scenarios where Verus-verified code is used as a component in a larger unverified Rust-based project.  In this case, the Verus-verified component still depends on builtin, builtin_macros, and vstd, which currently depend on special Verus build procedures that include non-stable Rust features.
This pull request observes that once ghost code is erased, builtin, builtin_macros, and vstd don't actually depend on any special Verus build procedures or non-stable Rust features, and can in fact be built with ordinary stable rustc and cargo, making them easier to incorporate as dependencies in larger Rust projects.  To take advantage of this, this pull request replaces the verus_macro_erase_ghost cfg flag with two cfg flags, verus_ghost_keep and verus_ghost_keep_body.  This supports the two existing scenarios where verus runs rustc with unstable features, plus the new stable-Rust scenario:

verus_ghost_keep and verus_ghost_keep_body ==> keep all ghost code, as in previous not(verus_macro_erase_ghost)
verus_ghost_keep and not(verus_ghost_keep_body) ==> keep only ghost stub function declarations, but erase ghost function bodies, as in previous verus_macro_erase_ghost
not(verus_ghost_keep) and not(verus_ghost_keep_body) ==> erase ghost function bodies and declarations, including declarations in builtin, to enable compiling code with ordinary stable rustc and cargo as part of a larger project

Since not(verus_ghost_keep) and not(verus_ghost_keep_body) are the default configuration, no special cfg flags are required for compiling Verus-verified code with ordinary rustc and cargo.  In addition, this pull request adds an ordinary Cargo.toml file for vstd that builds the not(verus_ghost_keep) and not(verus_ghost_keep_body) version of vstd and vstd's dependencies (including builtin, builtin_macros, syn_verus, etc.).  Larger Rust projects can easily use this Cargo.toml file to build the dependencies of any Verus-verified code.  Finally, this pull request makes building this no-ghost version of vstd part of CI.
Note: this pull request avoids triggering the issue that motivated https://github.com/verus-lang/verus/pull/709 and is therefore orthogonal to https://github.com/verus-lang/verus/pull/709 .

I was planning to use the unstable allocator_api for https://github.com/verus-lang/verus/pull/460
Is there a way to keep that?

I was planning to use the unstable allocator_api for #460
Is there a way to keep that?

Good question.  I guess some projects like Syn are highly configurable based on cfg feature flags.  Should we make vstd configurable by a cfg flag so that it can include or exclude code that relies on unstable features?  (Or we could overload the verus_keep_ghost cfg flag for this purpose.)

Well the allocator_api is supposed to be used by executable code. So restricting it to verus_keep_ghost wouldn't help.

Well the allocator_api is supposed to be used by executable code. So restricting it to verus_keep_ghost wouldn't help.

Ok, so maybe the proper thing to do is to add a separate cfg flag for executable vstd code that relies on unstable Rust features.

Ok, so maybe the proper thing to do is to add a separate cfg flag for executable vstd code that relies on unstable Rust features.

That makes sense to me if @tjhance believes it would work.


Unrestricted directory traversal with @fs

Describe the bug
The entire filesystem is indiscriminately exposed while the Vite dev server is running. Combined with the fact that the server is exposed to <IP_ADDRESS> by default, you're effectively opening your machine to the world during development.
This is technically a Vite feature as currently documented, but probably not actually intended.
Reproduction
Any Vite project will do.
npm init @vitejs/app app
cd app
npm install
npm run dev

If running on Windows, visit<EMAIL_ADDRESS>If running on Linux, visit http://localhost:3000/@fs/etc/passwd
No idea of an equivalent on macOS but I'm sure you can think of something

Combined with the fact that any "out of root" directories already reveal the username of the current user, you can also easily do<EMAIL_ADDRESS>System Info
  System:
    OS: Windows 10 10.0.19042
    CPU: (16) x64 AMD Ryzen 7 3700X 8-Core Processor
    Memory: 19.47 GB / 31.95 GB
  Binaries:
    Node: 14.16.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.10 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 7.7.5 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 89.0.4389.114
    Edge: Spartan (44.19041.423.0), Chromium (89.0.774.63)
    Internet Explorer: 11.0.19041.1
  npmPackages:
    vite: ^2.1.5 => 2.1.5

Used package manager: npm

This feature is used to solve problems in monorepos.
So I think we can expose an option to specify a workspace root (defaults to the project root) and restrict fs access beyond that directory.

If we did want to support monorepos by default then various tools have their own way to find the root of the workspace:

yarn and npm - workspaces field in the root package.json - this may not play nicely with nested workspaces, I've never used those so I'm not sure how they really work. (yarn workspaces, npm workspaces)
pnpm - pnpm-workspace.yaml file in the project root (pnpm workspaces)
rush - rush.json in the project root (rush config files)
nx - workspaces.json / nx.json files in prject root (nx structure)

As we can see this is a bit of a moving target (and there are more tools than these).yarn and pnpm are the most common as far as I am aware, those cases could be handled by default if this were deemed a 'good idea'.
I have no opinion on this as long as it is secure by default but leaving this info here in case it is useful.

@marvinhagemeister I think this discussion may also be of interest for WMR. Maybe you already had similar talks about how to tackle the security implications of opening the dev server.

@patak-js Yes, indeed this is something I've been pondering a lot about and it was one of the reason we didn't add an @fs loader to WMR. Any request made to the dev server is user input and therefore is deemed unsafe and needs to be sanitized/normalized accordingly.
In our case we limit file serving to the web root for now. We're planning to expand that to include aliased directories in the future. So we'd essentially have an array of allowed folders to load files from.
Just before loading we normalize the path and check if the resolved path leads to a file inside one of those include directories (which is currently just the web root). If it it does indeed lies somewhere in those folders we serve it, otherwise we error.

Thanks for the explanation. I like the idea of having web root + support for monorepos by default as @pngwn suggested (at least for common tools), and an array of allowed folders to manually cover the rest of the cases like it is done in WMR

Draft a PR, https://github.com/vitejs/vite/issues/2820
Not sure if we should do the auto-detection, which could be a bit untransparent for users as the behavior would change based on users' environments. For example, having on package.json with workspace accidentally on your ~/ will still unsafely expose<EMAIL_ADDRESS>and others. So, I'd think maybe it's better to strict by default and let users configure for monorepo setup explicitly.

Some thoughts:

Are there additional files inside root that need to be protected? eg. .env files that could contain serverside secrets?
Could the module graph / entries list be used to limit responses to files that are actually somehow attached to the vite server?
Do we need to protect against malicious modules trying to import known files and sending them off to god knows where?

I think that https://github.com/vitejs/vite/pull/2850 is a good first step, and should be considered a fix for this issue. But I agree with @dominikg that further changes are needed

Are there additional files inside root that need to be protected? eg. .env files that could contain serverside secrets?
Could the module graph / entries list be used to limit responses to files that are actually somehow attached to the vite server?

This is a good idea. There is also a related issue https://github.com/vitejs/vite/issues/2587 so publicDir overrides the default public root in dev mode. I think we should only serve from the public directory for absolute paths and allow /@fs/ access only for imported files (also taking into account glob imports)

Do we need to protect against malicious modules trying to import known files and sending them off to a remote server?

How would you achieve something like this?

How would you achieve something like this?

Good question. A set of allow and deny list checks in the import analysis plugin and prohibiting imports that are not passing?
Or maybe an extra security/validation plugin that tests all ids for bad ones?

Do we need to protect against malicious modules trying to import known files and sending them off to a remote server?

I kinda think this is out-of-scope of Vite, developers should take the responsibility to use malicious modules. And we don't actually have the ability to completely prevent it as every node modules are capable of doing such things if they want.

In a Vite Ruby project structure, vite.config.ts is at the project root while Vite's root targets an inner directory such as app/frontend/entrypoints.
The library leverages the fact that Vite can serve files in app/frontend directly, that is, outside of the root.
If the fix uses the location of package.json or the location of vite.config.ts to determine the root of the workspace (if failing to detect a mono repo), it wouldn't break Vite Ruby projects.

Drafted a PR, #2820
Not sure if we should do the auto-detection, which could be a bit untransparent for users as the behavior would change based on users' environments. For example, having on package.json with workspace accidentally on your ~/ will still unsafely expose<EMAIL_ADDRESS>and others. So, I'd think maybe it's better to strict by default and let users configure for monorepo setup explicitly.

why don't let set directory, where monorepo is, then find all package.jsons in it, and set access to all directories containing package.json (or their workspace) but omit folders without it?

or why don't we omit all /@fs/*, and let it expose just files, that are exposed on port dirrectlly?

@ElMassimo is there no way to do that, you detect all package.json and vite.config.ts (also in parents directories), and allow serve only directories that contain these files or are subfolder of folder that contain this files, and just omit all folders and files that doesn't contain this file and are not subfolder of folder containing these files?

Bring back for the record

Or when I think about it, monorepo is just repo, so why not find .git folder?

Sorry to resurrect this, but I want to echo this question.
Why is .git not considered a heuristic for the workspace root?


How to get the similarity between two faces?

Hello, is there a demo that use caffemodel to get the distance and similarity between two faces just like the deploy/test.py of original insightface?Thanks,waiting for reply.

Computing the Cosine Similarity


test/cases/simpl installer: bump to use fdo 0.4.0

Signed-off-by: Antonio Murdaca<EMAIL_ADDRESS>This pull request includes:

[ ] adequate testing for the new functionality or fixed issue
[ ] adequate documentation informing people about the change such as

[ ] submit a PR for the guides repository if this PR changed any behavior described there: https://www.osbuild.org/guides/

this passed again @gicmo @achilleas-k can we get it in? and then follow up with https://github.com/osbuild/osbuild-composer/pull/2376

Looks good!

the failing tests are the usual suspects

The tests that are failing are expected to fail (koji CS9, installer on CS9/RHEL9: https://bugzilla.redhat.com/show_bug.cgi?id=2059565)


Use request.session storage instead of (most of) the current views.py global variables

I think the global variables are causing the issues of dataset pollution between sessions (e.g. even an additional private browsing tab, on the same computer).
https://github.com/NSSAC/PEpiTA/blob/36a2966b8a0d947c4bea6235a14ef5dcca12bd79/webdesign/polls/views.py#L22-L33
https://github.com/NSSAC/PEpiTA/blob/36a2966b8a0d947c4bea6235a14ef5dcca12bd79/webdesign/polls/views.py#L53
Global variables are generally a bad idea in any software engineering. It is almost always better/safer to explicitly pass things in, via function parameters.
I believe the current situation makes it possible for an uploadbutton branch . . .
https://github.com/NSSAC/PEpiTA/blob/36a2966b8a0d947c4bea6235a14ef5dcca12bd79/webdesign/polls/views.py#L90
. . . in one session, to clobber the input_ts (and csvname, etc.) variable data of a subsequent evocation of a runbutton branch . . .
https://github.com/NSSAC/PEpiTA/blob/36a2966b8a0d947c4bea6235a14ef5dcca12bd79/webdesign/polls/views.py#L136
. . . in another session.
Session data is already set up to utilize server tmp storage. Django is also already configured to have session variables available to html templates. e.g.
In views.py index(request) function, we could do things like . . .
sess = request.session
sess.setdefault('csvname', '')

(etc.)
In index.html template:
{ request.session.csvname }
So, we might not even need to construct a "context" dictionary, and pass it to the render function. Maybe just add anything useful to the session dictionary.
Apparently, though, a session storage update is only automatically triggered by key value changes at the top level. If the content of a nested container (e.g. request.session['some_dict']['val1'] = 'new_val') is changed, that will require a manual triggering of an update, by . . .
request.session.modified = True
So it might be easiest/safest to just try to put things as basic data types, at the top level (e.g. not make a nested context dictionary one of the session key values).
Any utility functions called from index() could be passed the session dictionary, and get and set things from that.
e.g. here:
https://github.com/NSSAC/PEpiTA/blob/36a2966b8a0d947c4bea6235a14ef5dcca12bd79/webdesign/polls/views.py#L321-L322
Does that make sense, @ajs997 (@srinivvenkat, @bryanleroylewis ) ?
It is probably even problematic to use a globally-accessable "figures" directory, under the "media" dir.
Note: Check the end of https://github.com/NSSAC/PEpiTA/issues/9#issue-1961993720 for maybe a better way of storing the input_ts data.

It occurs to me . . . It's probably best to have the code utilize any global state, as little as possible. -even if it is per session.
It would be best to have things put in functions, with clear return values, rather than updating session variables as side-effects.
We could still assign the result from calling function, using returned tuples if necessary for multiple changes. But, probably, the only place even a session variable should be used is as a session dictionary being passed in to a function.


iOS can not set, get or delete tags

Is there an opportunity to manage tags on iOS? If no, how can we manage devices to target them further?
In my case I check in app subscription that should allow user no receive notifications. I've stuck on how to target iOS users in this case? On Android i set subscribed tag.

I am sorry, I have incorrectly imported library in OneSignal. If tag API works on iOS probably readme should be updated.