Update repositories.txt

@ArduinoBot

@ArduinoBot

Hello @crmoratelli. The automated system here only operates on library submissions. Since your submission was already accepted and the pull request merged, the bot won't pay any more attention to this pull request.
But this human is happy to help. What was it you wanted from the bot?

Hello.
I was trying to understand how a new tag version could be added. But perhaps new tags are automatically fetched from the repository. I think is everything right.
Thank you.

perhaps new tags are automatically fetched from the repository

You got it! After the initial addition of the library, the indexer job periodically checks each of the libraries in the index and picks up any new release/tag that meets the requirements listed here:
https://github.com/arduino/library-registry/blob/main/FAQ.md#what-are-the-requirements-for-publishing-new-releases-of-libraries-already-in-the-library-manager-list
This means there is no need to take any additional action to add new releases of your library to Library Manager. They will be added automagically! It does take a little time for the indexer job to run, and then some additional time after that for the update to propagate through the CDN and the local cache. But it will get there.
You can monitor the indexing of the library releases by checking the library's dedicated indexer logs web page:
http://downloads.arduino.cc/libraries/logs/github.com/crmoratelli/SupmeaDO7016/
This will tell you when the tag has been indexed and also provide some information in the event there was a problem that caused a release to be rejected. I took a quick look at the logs and it seems all is well with your library. Thanks!


Allow modification of dependencies in component metadata rules

For collecting feedback on #3157.

@oehme can you have another look at this PR? Main changes:

ComponentDependenciesMetadataDetails now has multiple differently typed add() methods. We need to do this, because there is already the add(T) method from the Collection interface which we can not override with add(Object). Advantage is also that the supported notations are easier to understand when looking at the interface.
There is a change for lazily providing a mutable dependency list in AbstractMutableModuleComponentResolveMetadata, which required a adjustments in two other places in the code where setDependencies() was used before. See my comment above.
Documentation and test coverage was added.

This PR has been updated to allow dependency modification per variant. I updated the description.
@oehme you may have another look.


I did something diff/wrong

The version 8.3.0 is on dockerhub and workin, but I'm not following whats happened to the branch
14:36 $ git push origin origin/8.x
Everything up-to-date

I'm trying to push the changes to the 8.x github branch

$ git push origin origin/8.x

Should that be upstream/8.x perhaps?

@danbev thanks, but unfortunately no. I'm using only the main repo : /
15:15 $ git branch -a
* (HEAD detached at origin/8.x)
  master
  remotes/origin/4.x
  remotes/origin/5.x
  remotes/origin/6.x
  remotes/origin/7.x
  remotes/origin/8.x
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
✔ ~/d/centos7-s2i-nodejs [node-8.2.1|✔]

I'm going to delete this local repo and start all again but without publish part.

from the docs:
https://github.com/bucharest-gold/centos7-s2i-nodejs/blob/master/PUBLISHING.md#updating-node-versions

Note that these files are kept up to date in the master branch, but any changes made here should be cherry-picked into the branch being updated.

master updated, now going to the 8x to cherry-pick and then push to the branch.

maybe I did another thing wrong because github is showing a 'change' with no 'changes'
✔ ~/d/centos7-s2i-nodejs [master|✔]
16:42 $ git checkout 8.x
Switched to branch '8.x'
Your branch is up-to-date with 'origin/8.x'.
✔ ~/d/centos7-s2i-nodejs [8.x|✔]
16:42 $ git pull origin 8.x
From github.com:bucharest-gold/centos7-s2i-nodejs
 * branch            8.x        -> FETCH_HEAD
Already up-to-date.
✔ ~/d/centos7-s2i-nodejs [8.x|✔]
16:43 $ git rebase origin/8.x
Current branch 8.x is up to date.
✔ ~/d/centos7-s2i-nodejs [8.x|✔]
16:43 $ git cherry-pick e19093502af5c94cc03fd833367c7c4baf1c77f0
[8.x d952a5f] (chore): update node versions
 Date: Thu Aug 10 16:35:09 2017 -0300
 3 files changed, 10 insertions(+), 9 deletions(-)
✔ ~/d/centos7-s2i-nodejs [8.x ↑·1|✔]
16:43 $ git commit -a -m "(chore) update to Node.js 8.3.0"
On branch 8.x
Your branch is ahead of 'origin/8.x' by 1 commit.
  (use "git push" to publish your local commits)
nothing to commit, working tree clean
✘-1 ~/d/centos7-s2i-nodejs [8.x ↑·1|✔]
16:45 $ git push origin 8.x
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 556 bytes | 0 bytes/s, done.
Total 5 (delta 4), reused 0 (delta 0)
remote: Resolving deltas: 100% (4/4), completed with 4 local objects.
To github.com:bucharest-gold/centos7-s2i-nodejs.git
   2e75a2b..d952a5f  8.x -> 8.x

when I click on compare and select the 8.x branch:

the problem with the first time was 'origin/8.x' instead only '8.x' : /


Add initial bundle testing docs

We should probably set up automation so that whenever a github release is created, we automatically build and push the image to the project-koku quay repo.

Codecov Report

Merging #50 (5246df8) into master (bfdc1e5) will increase coverage by 0.34%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master      #50      +/-   ##
==========================================
+ Coverage   85.76%   86.10%   +0.34%
==========================================
  Files           9        9
  Lines        1159     1159
==========================================
+ Hits          994      998       +4
+ Misses        108      105       -3
+ Partials       57       56       -1

Flag
Coverage Δ

unittests
86.10% <ø> (+0.34%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

controllers/kokumetricsconfig_controller.go
72.97% <0.00%> (+1.35%)
:arrow_up:

Continue to review full report at Codecov.

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


detect_marks() not working

Hi, I tried your code and I copied your save_model.pb file.  The detect_marks() is not working and it shows the error got shape [1, 128, 128, 3], but wanted [1]. Do you know what should I do to fix this ?
Thank you very much

@Jawkx please have a look at the the function defination of the function detect_marks in the face_landmarks.py. You need to pass the original image along with [x0, y0, X1, y0] which represents the face box coordinates you would have found from face detector. it should work then.

Issue solved, thanks


Release Google.Cloud.OsConfig.V1Alpha version 1.0.0-alpha03

Changes in this release:

Commit c38ba1f: feat: Update osconfig v1 and v1alpha with WindowsApplication
Commit ac367e2: feat: Regenerate all APIs to support self-signed JWTs

Created release for Google.Cloud.OsConfig.V1Alpha-1.0.0-alpha03


finally got hot reload of dependent files working

Continuation of #875
In order to hot-reload dependent files, we need to be able to control the module cache. We can do that with CommonJS and require(). With ESM, Node doesn't have an API to control the cache.
The solution was to always generate CommonJS files and generate .cjs extensions so everything will still work inside an ESM project.
As it stands, this will break if you require a file with a relative path that is outside the output directory. Not a hard fix, but I doubt anyone is affected and I don't want to deal with it right now.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

62 of 65 (95.38%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.2%) to 87.708%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/server/app.ts
0
1
0.0%

src/server/module-loader.ts
10
12
83.33%

Totals

Change from base Build<PHONE_NUMBER>:
0.2%

Covered Lines:
3062

Relevant Lines:
3531

💛  - Coveralls


Bugfix: don't run tests on precommit

Expected behaviour
Only linting should be run on precommit.
Actual behaviour
Both linting and tests run on precommit.
Steps to reproduce

Create PR.
Make changes.
Commit.

Your environment

Operating system(s): n/a
TwitchJS version: 2.0.0-alpha.1
NodeJS version: 8
Browser(s): n/a

Further discussion
Having tests run on precommit may make it difficult for new developers to contribute. Style and lint errors should be easy to correct, but new developers may require help to fix and add tests. To best help new developers, the code should be committed to a PR, where the it is easily accessible and the community can discuss and assist. At the end of the day, we still have CI to validate tests and coverage.

Thoughts @mBeierl ?

We only run
´´´
"prettier --write",
"eslint --fix",
"git add"
´´´
in precommit, as defined in .lintstagedrc.
The tests are only run when pushing. To create a PR we need to push of course. In my opinion tests that are broken by changes in a commit should be fixed before pushing/creating a PR.
But it would be easier for new developers to contribute when they can create PRs without having to worry about tests.
I'm good with both approaches. I personally like automated testing before pushing, as I often forget to run tests before pushing and the forced testing ensures that I fix tests before pushing.

Thanks for clarifying.
I like prepush tests too. Let's keep them for now and revisit the issue when the community starts development for Helix.


Add fill option to removeAlpha method

What are you trying to achieve?
I was trying to strip unnecessary alpha channel from an image to make it smaller. I expected sharp to fill transparent part with white, but instead it uncovered some previously hidden parts.
Stripping alpha channel without doing any additional work is certainly faster, so I don't think you should change removeAlpha default behavior.
But it would be great to have an option to fill transparent parts with a provided color.
Have you searched for similar feature requests?
Yes, #1648 looks a little bit similar
What would you expect the API to look like?
removeAlpha could accept a new fill option, similar to create.background option in sharp constructor:
.removeAlpha({ fill: { r: 255, g: 0, b: 0 } })

// or

.removeAlpha({ fill: '#ff0000' })

What alternatives have you considered?
I'll just keep alpha channel for now.
Is there a sample image that helps explain?
Here is my original image:

And here is how it looks after stripping alpha channel with sharp:

Currently removeAlpha works exactly the same as gm convert +matte. What I propose is something like
gm convert -background white -extent 0x0 +matte:

On the other hand, I should be already possible to create a single color image and then compose it with a transparent one to achieve the same result.

I was looking at the wrong method, I just need .flatten(). :)


Disable 15-test_ecparam.t when configured no-ec2m

This test doesn't actually fail completely, but there's no real pattern to distinguish which data files should be omitted when no-ec2m is configured and which should not.
Checklist

[x] tests are added or updated

Merged.  a4750ce55e7d6451c187b5ab9ccf5218e0851eeb


feat/get-fares-for-date-return-transfer

Please review before merging.

:tada: This PR is included in version 1.4.0 :tada:
The release is available on:

GitHub release
v1.4.0

Your semantic-release bot :package::rocket:


develop a similar plug-in for Siyuan Notes

obsidian-zotero is an amazing plugin. But Obsidian is too hard for some people.
Are you interested in developing a similar plugin for Siyuan Note?  The following URL maybe useful: plugin-sample for siyuan-note

I think it will be great!

WingDr/siyuan-plugin-citation: A citation plugin for the SiYuan Note.


Gauge chart not really round

Just look at the attached image (black slice, inner circle). This effect is on Chrome/MacOS only. No problems on FF/Windows.

I have the same problem on Chrome/Windows (

I'm closing this issue for now. We'll anyway provide a solid option for donut / pie charts which will solve this issue. By implementing #330 properly we can solve this.


page breaks if pass a number to the title

Environment
Last release Nuxt
Reproduction
Just add number characters in the title
Describe the bug
When I pass a number to the title, the page breaks !
This breaks the error page in production! You fixed this bug in vain with regexp without type checking.
This dangerous bug can lead to errors in the production of sites on Nuxt!
This will reduce the credibility of Nuxt! This is discrediting the reputation of Nuxt!

https://t.me/nuxtjs_ru/213128/227097
Additional context
relates
https://github.com/unjs/unhead/issues/106
Logs
No response

hot to make a Merge request to the repo?
https://github.com/unjs/unhead/pull/123/files

While this package should be able to handle it, the types clearly define that it should be a string value.

I've pushed up a fix  in v1.1.17
If you have lost credibility with Nuxt, that's okay, we don't need rude people using it.