Get zerver/actions/*.py to 100% test coverage.

Lines missing coverage:
ERROR: zerver/actions/create_realm.py no longer has complete backend test coverage
  Lines missing coverage: [167, 194]

ERROR: zerver/actions/message_delete.py no longer has complete backend test coverage
  Lines missing coverage: [27]

ERROR: zerver/actions/message_edit.py no longer has complete backend test coverage
  Lines missing coverage: [925, 1098, 1166]

ERROR: zerver/actions/presence.py no longer has complete backend test coverage
  Lines missing coverage: [119]

ERROR: zerver/actions/scheduled_messages.py no longer has complete backend test coverage
  Lines missing coverage: [111]

The message_delete.py one is already fixed by https://github.com/zulip/zulip/pull/25494.

@zulipbot claim

Ready for Review

@zulipbot abandon

@zulipbot claim

@timabbott

How to produce this error locally? to confirm after code change?
How to understand the method to write test-covergage for any particular file?

Thanks @adityanarayanm095 for picking up this issue. This issue is related to the coverage provided by the tests for some; whose details are in the issue description.
You can check if your code works by checking out the test coverage by running ./tools/test-backend --coverage -- this will generate an HTML page from which you can find out the current coverage for each file related to the backend.
Also, I see there are five files mentioned in the issue description, but I just generated the coverage report. It looks like only zerver/actions/presence.py is missing 100% test coverage, and the rest of the files in zerver/actions have got full test coverage. So you need to just get one file to full test coverage to solve this issue.
The tests are located in zerver/tests -- try taking a look at zerver/tests/test_presence.py to see how they are laid out.

Thanks @adityanarayanm095 for picking up this issue. This issue is related to the coverage provided by the tests for some; whose details are in the issue description.
You can check if your code works by checking out the test coverage by running ./tools/test-backend --coverage -- this will generate an HTML page from which you can find out the current coverage for each file related to the backend.
Also, I see there are five files mentioned in the issue description, but I just generated the coverage report. It looks like only zerver/actions/presence.py is missing 100% test coverage, and the rest of the files in zerver/actions have got full test coverage. So you need to just get one file to full test coverage to solve this issue.
The tests are located in zerver/tests -- try taking a look at zerver/tests/test_presence.py to see how they are laid out.

@sbansal1999, Below and few other lines are not covered so how to get idea to write test coverage for them?, i have read zerver/tests/test_presence.py but not able to relate with the missing code coverage.

@adityanarayanm095  I ran the tests again just to double check and there is only one line (line no. 119) that is missing test coverage in zerver/actions/presence.py.
I would recommend updating your fork as it could be a possible reason for the discrepancy. Read - keeping your fork updated. Also for help on writing tests, you can have a look at this page.
Feel free to join The Zulip development community to discuss related things.

@zulipbot claim

@zulipbot claim

@zulipbot abandon

@zulipbot claim

@Haider8 Are you working on this issue?

Let me work on this @amanagr
assign

@zulipbot claim

@zulipbot claim

@sbansal1999 is this issue has been solved by #26511 or been solving by him?

@zulipbot abandon

@zulipbot claim

@zulipbot claim


Making docs gender agnostic

Pretty straight forward. We shouldn't be using genders in docs when referring to users or developers. Especially when they are so one-sidedly referring to men.
Especially as it's even stated in the docs on Docs

Some of the changelogs had references to "he" which should probably come out, but wasn't sure if I should be editing the changelogs that are driven from commit messages

This is great, but could you remove the whitespace-only changes (they make it hard to review the substantive changes). Thanks!

Hey Dan, thanks a lot - was on my bucket list for ages heh. How much work is it to remove the whitespace? I'd be inclined to merge, but as Fred says it makes it a lot harder to review. Please check that either your IDE doesn't remove trailing whitespace by default, or that you do a line-by-line review before committing (I find SourceTree handy for this)

https://github.com/silverstripe/silverstripe-framework/pull/3983/files?w=1

Until my last few PRs I used to do adding with hunks to keep whitespace changes out. However, cleaning trailing whitespace and adding newlines to EOF should be standard practice so I've decided that this falls into "boy scout rule" (leave something better than when you found it).
I can go through this and take out all the whitespace changes if it's really a big deal, but I don't think it should be :)

I know about the w=1 param, but not all community members participating in the discussion on a specific diff will. So while the "boy scout rule" is a good one, I think having a concise and readable code change is more important. If you think trailing whitespace is an issue worth fixing, please submit a separate PR for it, across all files. Its going to be a nuisance in further "git blame" use, but less so than having all this diff noise on further PRs.
Regardless, I'll merge this one - but won't next time ;)

Thanks Ingo, from now on I'll do cleaner commits.
Annoyingly my IDE is meant to only clean line endings on changed lines, but seems to fail to do that

I noticed that the "reformat changed lines only" feature in NetBeans doesn't seem to work, so I had to turn it off. Thanks for the w=1 tip. I wasn't aware of it :)


How to build a stream(simplex) from a graph or a network(Adjacency Matrix)

One option is to build an explicit metric space where the distance between any two vertices in the graph is the length of the shortest path between them. Then build the Vietoris-Rips complex on top of this explicit metric space.

If you come up with any other definitions, then you can build them as simplicial complexes using the Explicit Simplex Stream class.

Thank you for your answer,  still I have some questions and I hope you can help me.
Seek help for simplicial complex understanding.docx
@henryadams

Sincerely thank you！

In both of these examples, you have 4 (and 6) «minimal» cycles -- the triangles in the tetrahedron, the sides of the cube.
One of these cycles can be expressed in terms of the other 3 (or 5), and so does not contribute any essential cycles to the homology.
For the tetrahedron, your four minimal cycles are
[1,2] + [2,3] + [1,3]
[1,2] + [2,4] + [1,4]
[1,3] + [3,4] + [1,4]
[2,3] + [3,4] + [2,4]
(written in order as you go around the cycle)
Notice here (and remember that we are working mod 2) that
([1,2] + [2,3] + [1,3]) +
([1,2] + [2,4] + [1,4]) +
([1,3] + [3,4] + [1,4]) =
[1,2] + [1,2] + [1,3] + [1,3] + [1,4] + [1,4] + [2,3] + [3,4] + [2,4] =
[2,3] + [3,4] + [2,4]
So the last can be expressed in terms of the others, and is left out when reporting the results of the computation.
Mikael Vejdemo-Johansson
<EMAIL_ADDRESS>http://atmcs.appliedtopology.org http://atmcs.appliedtopology.org/

On 21Mar, 2018, at 12:57, Wangxingdong<EMAIL_ADDRESS>wrote:
Thank you for your answer, still I have some questions and I hope you can help me.
Seek help for simplicial complex understanding.docx https://github.com/appliedtopology/javaplex/files/1834260/Seek.help.for.simplicial.complex.understanding.docx
@henryadams https://github.com/henryadams
https://user-images.githubusercontent.com/37624901/37724384-9403b5bc-2d6b-11e8-938d-4ffa72694d41.GIF
Sincerely thank you！
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/appliedtopology/javaplex/issues/18#issuecomment-375017066, or mute the thread https://github.com/notifications/unsubscribe-auth/AHvcpyW9sX-Ja2hmqbm83liMi9PLPscCks5tgoaVgaJpZM4Sz9ID.


ChatViewModel : KeyNotFound

Steps to reproduce:

Run a server and 2 clients, say A and B.
Send a message from client B, e.g: "Hi".
Leave the meet from B.
Run a new client say C. client C will have this error.

@bruise-88 @ragedjavelin u guys should not remove the client from the session array, instead, just maintain a boolean like isLogged_out.
@RaswanthMurugan20
@hps1991 once the dashboard has made the above change u have to only show the client who is active in the session using that boolean.
@kmitul You need to update the telemetry for this, once the dashboard has made the changes.

@kmitul also the user count is not updating properly, though the graph is showing correctly.

As a quick fix to this issue, I have made the user who has chated but not in the meeting during a new client's arrival as "anonymous".
commit


Change to a 10.5 hour futures calendar

Change algorithms that use the futures calendar to run from 6:30am to 5:00pm instead of 24 hours. Minutely history calls will still return 24-hour data however.

Coverage decreased (-0.05%) to 87.33% when pulling 59c101481b32f45b780d8cd82862a9f0c7a86be6 on new-futures-hours into 3be451e2595da543e7687990785d6de198b801e8 on master.

@richafrank Ready for a look

Coverage decreased (-0.04%) to 87.334% when pulling ac5147b77963a92e37d91f923ed8ad4298e94fa3 on new-futures-hours into 3be451e2595da543e7687990785d6de198b801e8 on master.

Coverage decreased (-0.04%) to 87.334% when pulling ac5147b77963a92e37d91f923ed8ad4298e94fa3 on new-futures-hours into 3be451e2595da543e7687990785d6de198b801e8 on master.

Coverage decreased (-0.04%) to 87.334% when pulling ac5147b77963a92e37d91f923ed8ad4298e94fa3 on new-futures-hours into 3be451e2595da543e7687990785d6de198b801e8 on master.

Coverage decreased (-0.04%) to 87.334% when pulling 1602bbe8ba8c0ea0d371adcd75a68eeba36f8acc on new-futures-hours into 3be451e2595da543e7687990785d6de198b801e8 on master.

Coverage decreased (-0.04%) to 87.334% when pulling 4746f35cfd3435b7d485c3e5a92701abec4aeb6b on new-futures-hours into 3be451e2595da543e7687990785d6de198b801e8 on master.

Coverage increased (+0.01%) to 87.388% when pulling 3469e94dbc7a6541484e26bc8a649121aeff5d30 on new-futures-hours into 3be451e2595da543e7687990785d6de198b801e8 on master.

Coverage increased (+0.01%) to 87.388% when pulling 2c946e7a6f83849ae0a4478a0e73229e268d82d6 on new-futures-hours into 3be451e2595da543e7687990785d6de198b801e8 on master.

Coverage increased (+0.01%) to 87.388% when pulling ce13a17e20b1f9191ba186d76a661934095b028c on new-futures-hours into 595de9886afdd0c163beac87c131413bcba96c8d on master.

Coverage increased (+0.01%) to 87.389% when pulling ce13a17e20b1f9191ba186d76a661934095b028c on new-futures-hours into 595de9886afdd0c163beac87c131413bcba96c8d on master.

Coverage increased (+0.01%) to 87.389% when pulling ce13a17e20b1f9191ba186d76a661934095b028c on new-futures-hours into 595de9886afdd0c163beac87c131413bcba96c8d on master.

Coverage increased (+0.01%) to 87.389% when pulling ce13a17e20b1f9191ba186d76a661934095b028c on new-futures-hours into 595de9886afdd0c163beac87c131413bcba96c8d on master.

Coverage increased (+0.01%) to 87.389% when pulling 64e0cf292e0b60e18cb4cce31bed8aca2dc952f3 on new-futures-hours into 595de9886afdd0c163beac87c131413bcba96c8d on master.

Coverage increased (+0.01%) to 87.389% when pulling dd78bfa4e8f4dcfbd2066b060d778c4968803d25 on new-futures-hours into b45c52b453b96823c3cdbf702a91a320c72f54aa on master.


Another crafting performance issue

I just realized that no one has created an issue for the crafting lag that was introduced when the crafting speed was changed in 1.6.12.
Issue description:
Tps lag when crafting with lots of crafting CPU's
What happens:
TPS goes down to 2.
Steps to reproduce:

Make Reborn Storage Autocrafter. (Mine is Max size 16x16x16 with 1 crafting storage the rest are cpus).
Setup pattern for Sextuple compressed cobblestone.
Connect creative drawer with cobble.
Request 2 Sextuple compressed Cobblestone (Anything more gets caught by the complexity check for me)

Version (make sure you are on the latest version before reporting):

Minecraft:1.12.2
Forge:2815
Refined Storage:1.6.14

Does this issue occur on a server? [yes/no]yes
Profiling
https://www.dropbox.com/s/xkcbyg9bgcomy0l/RSCraftingWithoutOpeningCraftingMonitor.nps?dl=0
Looking at that this might be on reborn Storage? Not sure if he can fix this with the current API but I will post on his git too.
https://www.dropbox.com/s/5y8owgth6nqirij/RSCraftingWithMonitor.nps?dl=0
That looks like the monitor is updating on every change instead of periodically. Related to #2132

Thanks, I will look into this when I have time.

Got a similar issue.
If a crafter is pointed to a machine or chest with a processing recipe, and that machine or chest fills up while an extreme number of orders are in the backlog, the server pretty much kills itself.

This is a separate Issue @Theyoungster I had 0 machines involved in this. If you could do some profiling and post another issue that would be great.
https://refinedstorage.raoulvdberge.com/wiki/profiling

Alright. I suspect it's heavily related, but I'll post as a separate issue.

My issue is mostly fixed in this https://github.com/TechReborn/RebornStorage/pull/149
Not sure if there are other things that can be done without changing how the crafting code works.


Sync with nng, change error code, fix memory free in debug mode

Codecov Report
Base: 43.04% // Head: 43.04% // Increases project coverage by +0.00% :tada:

Coverage data is based on head (d266996) compared to base (9ddce31).
Patch coverage: 0.00% of modified lines in pull request are covered.

:exclamation: Current head d266996 differs from pull request most recent head 022df90. Consider uploading reports for the commit 022df90 to get more accurate results

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #404   +/-   ##
=======================================
  Coverage   43.04%   43.04%
=======================================
  Files         119      119
  Lines       35480    35480
=======================================
+ Hits        15271    15273    +2
+ Misses      20209    20207    -2

Impacted Files
Coverage Δ

src/mqtt/transport/tcp/mqtt_tcp.c
0.67% <0.00%> (ø)

src/core/timer.c
92.20% <0.00%> (-5.20%)
:arrow_down:

src/sp/protocol/pubsub0/pub.c
90.47% <0.00%> (-4.77%)
:arrow_down:

src/sp/transport/ws/websocket.c
75.76% <0.00%> (-3.42%)
:arrow_down:

src/core/list.c
84.61% <0.00%> (-1.29%)
:arrow_down:

src/sp/transport/inproc/inproc.c
79.54% <0.00%> (-1.14%)
:arrow_down:

src/core/aio.c
94.67% <0.00%> (-0.89%)
:arrow_down:

src/sp/protocol/reqrep0/req.c
95.49% <0.00%> (-0.57%)
:arrow_down:

src/sp/protocol/bus0/bus.c
94.31% <0.00%> (-0.48%)
:arrow_down:

src/sp/transport/tcp/tcp.c
72.39% <0.00%> (-0.34%)
:arrow_down:

... and 7 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


JFrog CLI 1.39 deletes sphinx CSS subdirectories etc. during uploads with rt upload

Describe the bug
We are observing an issue with uploading documentation created with sphinx.
To Reproduce
Invoke JFrog CLI from the jfrog/jfrog-cli-go Docker image:
jfrog rt config --interactive=false --url https://artifactory.local.example.net/artifactory --user $${ARTIFACTORY_USERNAME} --password $${ARTIFACTORY_PASSWORD}
jfrog rt upload ./ example-docs-local/package/latest/ --flat="false" --quiet="true" --sync-deletes="example-docs-local/package/latest/"

Expected behavior
We should see the following, as produced by v1.38.4:
Index of example-docs-local/pacakge/2020.224.0-2-ga9d350d

Name            Last modified      Size
../
.doctrees/       20-Aug-2020 19:49    -
_sources/        20-Aug-2020 19:49    -
_static/         20-Aug-2020 19:49    -
.buildinfo       20-Aug-2020 19:49  230 bytes
genindex.html    20-Aug-2020 19:49  4.25 KB
index.html       20-Aug-2020 19:49  9.87 KB
objects.inv      20-Aug-2020 19:49  327 bytes
search.html      20-Aug-2020 19:49  4.05 KB
searchindex.js   20-Aug-2020 19:49  1.56 KB

What actually see is the following, as produced by v1.39:
Index of example-docs-local/package/2020.224.0-1-g14a5e0b

Name            Last modified      Size
../
.buildinfo       20-Aug-2020 10:35  230 bytes
genindex.html    20-Aug-2020 10:35  4.25 KB
index.html       20-Aug-2020 10:35  9.87 KB
objects.inv      20-Aug-2020 10:35  327 bytes
search.html      20-Aug-2020 10:35  4.05 KB
searchindex.js   20-Aug-2020 10:35  1.56 KB

Screenshots
The log from v1.39 shows that the rt upload operations deletes all of the subdirectories, but gives no explanation as to why:
[... Lots of upload lines ...]
[Info] [Thread 2] Uploading artifact: .doctrees/environment.pickle
204	[Info] [Thread 0] Uploading artifact: .buildinfo
205	[Info] Searching artifacts...
206	[Info] Found 3 artifacts.
207	[Info] [Thread 1] Deleting example-docs-local/package/latest/_static/
208	[Info] [Thread 0] Deleting example-docs-local/package/latest/_sources/
209	[Info] [Thread 2] Deleting example-docs-local/package/latest/.doctrees/
210	{
211	  "status": "success",
212	  "totals": {
213	    "success": 92,
214	    "failure": 0
215	  }
216	}

Versions

JFrog CLI version: 1.39
JFrog CLI operating system: jfrog/jfrog-cli-go:1.39
Artifactory Version: 7.5.5 rev 70505900

@tmwong2003, I couldn’t reproduce this issue as I followed your steps. It will help if you run the following steps:

Run jfrog -v to make sure you’re using version 1.39.0.
Create a new empty directory and cd into it.
Run jfrog rt dl “tmwong2003/package/latest/(*)” {1} --url=https://ecosysjfrog.jfrog.io/artifactory --user=tmwong2003 --password=tmwong2003 --flat=true
Now you should see the following directory structure locally:

.
├── 1
├── 2
├── 3
└── _static
    ├── 1
    └── details1

rename the file details1 -> details2
Run jfrog rt upload ./ tmwong2003/package/latest/ --flat=“false” --quiet=“true” --sync-deletes=“tmwong2003/package/latest/” --url=https://ecosysjfrog.jfrog.io/artifactory --user=tmwong2003 --password=tmwong2003

If you manage to see the _static folder in Artifactory, with the updated file details2 then it’s probably a bug related to the --sync-deletes functionality, that is revealed for your unique files structures. It will be helpful if you can share one of your folders to allow me to reproduce this issue.
You can zip the directory structure, and attach it to this GitHub issue. Please also try to provide precise steps to reproduce the issue.
I’m looking forward to hearing from you.

I'm also seeing similar issues with JFrog CLI 1.39.1.
The issue appears to be with subfolders? My upload is something like:
docs/
  latest/
    root_file.txt
    subfolder_1/
      sub_1.txt
    subfolder_2/
      sub_2.txt
    subfolder_3/
      sub_3.txt

Only root_file.txt survives - previously, all the content in subfolders would also remain as expected.
My command is:
jfrog rt u --recursive --flat=false --sync-deletes="repo/docs/latest" "*" "repo/docs/latest"

When running with JFROG_CLI_LOG_LEVEL=DEBUG, here's what I see happening:

Lots of uploads (HTTP PUT) with ;sync.deletes.timestamp=1598458115311 -- all artifacts get uploaded successfully
Searches for files that are NOT for the timestamp:[Debug] Searching Artifactory using AQL query:
items.find({"@sync.deletes.timestamp":{"$ne":"1598458115311"},"type":"any","path":{"$ne":"."},"$or":[{"$and":[{"repo":"docs","path":"docs/latest","name":{"$match":"*"}}]},{"$and":[{"repo":"repo","path":{"$match":"docs/latest/*"},"name":{"$match":"*"}}]}]}).include("name","repo","path","actual_md5","actual_sha1","size","type","modified","created")

Searches for files that ARE for the tiemstamp:[Debug] Searching Artifactory using AQL query:
items.find({"@sync.deletes.timestamp":"1598458115311","type":"any","path":{"$ne":"."},"$or":[{"$and":[{"repo":"repo","path":"docs/latest","name":{"$match":"*"}}]},{"$and":[{"repo":"repo","path":{"$match":"docs/latest/*"},"name":{"$match":"*"}}]}]}).include("name","repo","path","actual_md5","actual_sha1","size","type","modified","created").sort({"$asc":["repo","path","name"]})

Finds 3 "artifacts" which appear to be the 3 subfolders which are then deleted!

@milas, It will be helpful if you can share one of your folders to allow me to reproduce this issue.
You can zip the directory structure, and attach it to this GitHub issue.

Run jfrog -v to make sure you’re using version 1.39.0.
bash-5.0# jfrog -v
jfrog version 1.39.0
Create a new empty directory and cd into it.
bash-5.0# mkdir test; cd test
Run jfrog rt dl “tmwong2003/package/latest/()” {1} --url=https://ecosysjfrog.jfrog.io/artifactory --user=tmwong2003 --password=tmwong2003 --flat=true
Now you should see the following directory structure locally:
.
├── 1
├── 2
├── 3
└── _static
├── 1
└── details1
bash-5.0# jfrog rt dl "tmwong2003/package/latest/()" {1} --url=https://ecosysjfrog.jfrog.io/artifactory --user=tmwong2003 --password=tmwong2003 --flat=true
[Info] Searching items to download...
[Info] [Thread 2] Downloading tmwong2003/package/latest/2
[Info] [Thread 1] Downloading tmwong2003/package/latest/3
[Info] [Thread 0] Downloading tmwong2003/package/latest/_static/1
[Info] [Thread 0] Downloading tmwong2003/package/latest/1
[Info] [Thread 1] Downloading tmwong2003/package/latest/_static/details1
{
"status": "success",
"totals": {
"success": 5,
"failure": 0
}
}
rename the file details1 -> details2
bash-5.0# mv _static/details1 _static/details2
Run jfrog rt upload ./ tmwong2003/package/latest/ --flat=“false” --quiet=“true” --sync-deletes=“tmwong2003/package/latest/” --url=https://ecosysjfrog.jfrog.io/artifactory --user=tmwong2003 --password=tmwong2003
bash-5.0# jfrog rt upload ./ tmwong2003/package/latest/ --flat="false" --quiet="true" --sync-deletes="tmwong2003/package/latest/" --url=https://ecosysjfrog.jfrog.io/artifactory --user=tmwong2003 --password=tmwong2003
[Info] [Thread 1] Uploading artifact: 3
[Info] [Thread 2] Uploading artifact: _static/details2
[Info] [Thread 0] Uploading artifact: _static/1
[Info] [Thread 1] Uploading artifact: 2
[Info] [Thread 2] Uploading artifact: 1
[Info] Searching artifacts...
[Info] Found 1 artifact.
[Info] [Thread 2] Deleting tmwong2003/package/latest/_static/details1
{
"status": "success",
"totals": {
"success": 5,
"failure": 0
}
}
I see that https://ecosysjfrog.jfrog.io/artifactory/tmwong2003/package/latest/_static https://ecosysjfrog.jfrog.io/artifactory/tmwong2003/package/latest/_static exists; I’m clearing the contents of the docs with management to make sure I can send the tarball.

Info] [Thread 0] Uploading artifact: _sources/index.rst.txt
[Info] [Thread 1] Uploading artifact: .doctrees/index.doctree
[Info] [Thread 0] Uploading artifact: .doctrees/environment.pickle
[Info] [Thread 2] Uploading artifact: .buildinfo
[Info] Searching artifacts...
[Info] Found 3 artifacts.
[Info] [Thread 2] Deleting tmwong2003/regression/latest/.doctrees/
[Info] [Thread 1] Deleting tmwong2003/regression/latest/_static/
[Info] [Thread 0] Deleting tmwong2003/regression/latest/_sources/
{
  "status": "success",
  "totals": {
    "success": 92,
    "failure": 0
  }
}
bash-5.0#

I pushed a tarball jfrog-test.tgz of the
and attached the full log file jfrog-upload.log of the upload session.

@Or-Gabay My structure/setup is very similar to that of @tmwong2003 -- if the example they shared is insufficient to repro, let me know and I can try to create a repro case as well, but it will be almost identical 🙂

First of all, thank you guys both for your collaboration, I have managed to fix the bug and we will release it soon.
Moreover, I have added a JFrog-CLI binary (Linux edition) which includes the fix, feel free to try it out and share your results.

@milas and @tmwong2003,
Version 1.39.2 is released and includes @Or-Gabay's fix for this issue.
Thanks again for helping us pinpoint and fix the issue. We're looking forward to your feedback for this patch release.
And of course, thanks @Or-Gabay for fixing the issue!

@eyalbe4 @Or-Gabay Thank you for releasing the fix! I can confirm that JFrog 1.39.2 fixes the issue we saw.


add test case

Fixes #ISSUSE_ID.
Changes proposed in this pull request:

Codecov Report

Merging #688 into dev will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##              dev     #688   +/-   ##
=======================================
  Coverage   67.45%   67.45%
=======================================
  Files         441      441
  Lines        8417     8417
  Branches     1348     1348
=======================================
  Hits         5678     5678
  Misses       2426     2426
  Partials      313      313

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 c66e08c...7c97362. Read the comment docs.


Add https inclusion to userscript

The game wouldn't load with the default http include when using https on the cookie clicker page.

Good idea.  Can you set the target to the dev branch?  Everything first goes to dev before master.  Also, what's with the change at the last line?

Not sure what the last line is, I didn't touch it.  I can't see the difference either.


WIP: Add internal reverse-mode rules for ranges

This is the second PR to fix https://github.com/EnzymeAD/Enzyme.jl/issues/274. It's separated as I think the forward mode one can just be merged no problem, and this one may take a little bit more time.
The crux of why this one is hard is because of how Julia deals with malformed ranges.
Basically dret.val = 182.0:156.0:26.0, the 26.0 is not the true value. Same as

julia> 10:1:1
10:1:9

Because of that behavior, the reverse dret does not actually have the information as to what its final point is, and its length is "incorrect" as it's changed by the constructor. In order to "fix" the reverse, we'd want to swap the step to negative and then use the same start/stop, but that information is already lost so it cannot be fixed within the rule. You can see the commented out code that would do the fixing if the information is there, and without that we cannot get a correctly sized reversed range for the rule.
But it's a bit puzzling to figure out how to remove that behavior. In Base Julia it seems to be done in the function (:)(start::T, step::T, stop::T) where T<:IEEEFloat, and as I showed in the issue, I can overload that function and the behavior goes away, but Enzyme's constructed range still has that truncation behavior, which means I missed spot or something.

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
Attention: Patch coverage is 0% with 29 lines in your changes missing coverage. Please review.

Project coverage is 63.33%. Comparing base (037dfed) to head (ec3d3fe).
Report is 27 commits behind head on main.

Files
Patch %
Lines

src/internal_rules.jl
0.00%
29 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1656      +/-   ##
==========================================
- Coverage   67.50%   63.33%   -4.17%
==========================================
  Files          31       32       +1
  Lines       12668    12654      -14
==========================================
- Hits         8552     8015     -537
- Misses       4116     4639     +523

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


Update typeDoc comments in dialog.ts

Description

Fixed links
Updated descriptions, hopefully for clarity and completeness.

Specific Changes

Major edits to all typeDoc comments in dialog.ts.
Minor copy edits in dialogContext.ts

Testing
Will do a visual review of the released docs and submit updates after the 4.6 release, as necessary.

Pull Request Test Coverage Report for Build 85738

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 85.158%

Totals

Change from base Build 85591:
0.0%

Covered Lines:
4920

Relevant Lines:
5535

💛  - Coveralls


Dynamic text size for char sheets

With localization on it's way (I finished the german file based on the actual pull request) I see some minor problems: the german terms are much longer than the english ones. Is there a way to make a dynamic text size? Or should I do abbreviations?
For example see the screenshot on the bottom row "Verpflichtung" is a really long word

That is actually a really interesting issue.
I've played around with a solution using SVG and text boxes but it would require a fairly timely sheet rework so probably won't be a priority just yet. For now rely on abbreviations where you have to, but I'll put it on the nice to have list.

Thanks for the reply. Thats all I want :)

Kinda fixed part of the issue.  Made sure the block titles now expand correctly and have adequate padding to display long words.

Closing this as we've made improvements.

Closing this as we've made improvements.


Have TensorBoard graph smoothing not overestimate last gotten scalar

When plotting scalars in TensorBoard, the smoothed curve overfits the latest value. It means the curve jumps around with subsequent updates, and for a line fit it just plainly looks bad and feels wrong.
For example, when progress reporting neural networks training and plotting the loss over the training data, surely the blue line will continue with a slight downwards slope given a stable learning rate but instead this happens at the end of the curve:

@danmane, could you please take a look?

Is this fixed by: https://github.com/tensorflow/tensorflow/pull/7891 ?

https://github.com/tensorflow/tensorflow/pull/7891 looks great.

Fixed?

Fixed in 1.1


Bump to version 6.4

I was bumping my build of dwm and thought to try the diff file on your build, and not many rejects occurred so i fixed all of them manually, i also saw that you have already applied some patches from after version 6.2, the only reject i couldn't solve was one related to the tile function which was not existing in your dwm.c i think it was replaced by the patch that added multiple layouts.

I notice that lockfullscreen is preventing full screen windows from being closed, which I don't this is the purpose. I had added a patch before that prevented moving from the focused window, and I think they might be interfering. Might check later.

Indeed the commit was added to main dwm by the guy that made the patch you're talking about, and later someone added the lockfullscreen variable to turn it on or off, if it's the thing causing problems i can remove it.

I'd rather remove the unique version my build has and replace it with the upstream one with the variable.

I'll work on removing the patch after a couple of hours when i have time.

I fixed the issue the patch seemed to have been applied to killclient instead of focusstack you probably shouldn't merge this since a mistake like that happened tomorrow i'll redo the patching and confirm every patch was applied where it should be.


Enable clippy on Travis

Let's wait what Travis say before merging.

So long as this doesn't lead to more pain than gain, I'd be okay with this.  I'd like to see us sort the spurious test failures FIRST though :D


Does anyone reproduce the result on CAMELYON-16?

Why I can only get Acc about 86%,   10% less than reported in the paper?

Why I can only get Acc about 82%, 10% less than reported in the paper?


Draggable /  DragTarget   freezes in dragging

master->android    OK
master->web         freezes
master->windows  freezes
beta->android      OK
beta->web           OK

Hi @amarildolacerda
Can you please provide your flutter doctor -v and a minimal complete reproducible code sample?
Thank you

Today I find some way workaround this:
I Change:
Draggable<...>(
child: InkWell(.....)
)

Hi @amarildolacerda
I need you to provide your flutter doctor -v and a minimal complete reproducible code sample?
Thank you

https://github.com/flutter/flutter/issues/65546


Cloud management gateway connection point Requirements

The "Cloud Management Gateway connection point" is a Role, but there are no hardware requirements listed. Really need to know the Recommended Processor, Disk Space, RAM needed.

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

ID: e67ddd45-90df-32cd-3cbe-9e1443b2540f
Version Independent ID: dee7fcb8-a7b7-e5a1-9c04-c113805be0da
Content: Recommended hardware - Configuration Manager
Content Source: sccm/core/plan-design/configs/recommended-hardware.md
Product: configuration-manager
Technology: configmgr-other
GitHub Login: @mestew
Microsoft Alias: mstewart

Hi @DavidHBaur, thanks for the feedback. In this instance, it falls under the row for "all other site system roles" in the Remote site system servers section.
I'll get a note added to the CMG scale/sizing content.

I just submitted a change. Once the pull request merges, this issue will automatically close. The change is in our 2002 release branch, so it won't be live until that publishes, which should be soon 😉

Thanks Aaron!
From: Aaron Czechowski<EMAIL_ADDRESS>Sent: Monday, March 30, 2020 4:28 PM
To: MicrosoftDocs/SCCMdocs
Cc: DavidHBaur; Mention
Subject: Re: [MicrosoftDocs/SCCMdocs] Cloud management gateway connection point Requirements (#2276)
I just submitted a change. Once the pull request merges, this issue will automatically close. The change is in our 2002 release branch, so it won't be live until that publishes, which should be soon 😉
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/MicrosoftDocs/SCCMdocs/issues/2276#issuecomment-606261114 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ALOZISJ3X2RASQOZEMJJYPTRKEFGDANCNFSM4LTA4Q7A .  https://github.com/notifications/beacon/ALOZISKP4SWGHFALV7HR3TLRKEFGDA5CNFSM4LTA4Q7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEQRM66Q.gif


Cannot re-add TV in homekit

I had setup homebridge-philips-android-tv succesfully. I was also able to add the Philips TV accessory in Homekit where I had some cotrols over the TV.
Once I removed the accessory from Homekit, I have not been able to add it again. I've reinstalled the plugin, rebooted Homebridge and Homekit without any success.
I can see that the plugin is connected to the TV but when I search for the accessory in Homekit, it does not show up anymore.

The workaround was to rename the TV in the plugin config.

Accessory to be presented as TV is registered as external accessory to Homebridge.
External Accessory can't be cleaned, neither have any persistent state.
So clean it - homebridge restart is needed.
Please attach logs if ever see notice this issue again.

I think this one can be closed.

So clean it - homebridge restart is needed.

This is the solution.

remove the TV from HomeKit
restart homebridge
(optional is this don't work for you) remove TV from HomeKit
3.1. remove the Plugin from homebridge (including config)
3.2. restart homebridge
3.3. install plugin again and configure config.json
3.4. restart homebridge again

External Accessory are a little bit special...

I tried both ways and more without success. I thought it could perhaps be something remaining in the Home hubs so I restarted the Apple TV. I even did the pending software update to 14.2.
HomeBridgeLog2.txt
As soon as I put in an unique name, homekit picks it up and I'm able to add the TV (again).
I've attached an extract of the homebridge log. I've filtered out the entries from other devices. Not sure if this is what you need as the info is limited. The log has 3 restarts. First with the original name from the plugin which fails. Second restart is with a name I have used previously which fails too. Third restart is a new name which works.
Let me know if you riquire other info.

All three times print
"Publishing accessory" indicates that external accessory have been registered,
also accessory uuid is based of name you provide, so always unique.
To be honest, I have no idea. We can escalate this to homebridge to get more support.


Timers

Timers are basically the same as erlang:start_timer. They are only active during activation they are created during.

I was considering if we could just leave it to start_timer and call it "done". But orleans timers are actually continual, http://dotnet.github.io/orleans/Documentation/Advanced-Concepts/Timers-and-Reminders.html
So I think it needs a erleans_grain:start_timer that takes a Period and DueTime.
I don't know why in the Orleans case they do:

Note however, asyncCallback invocations are not delivered as messages and are thus not subject to message interleaving semantics. This means that invocations of asyncCallback should be considered to behave as if running on a reentrant grain with respect to other messages to that grain

We may be fine just doing it as a message to the grain like erlang:start_timer/send_after but I'd like to be sure there isn't some advantage for the use cases of timers being done the Orleans way that we'd lose...
I guess I may need to find someone who actually develops with Orleans :)

Maybe the point is to not let another message being handled delay the firing of a timer. Of course then the timer handler can't update the state of the grain and not sure what to pass it as the state when it is called if that is the case.

Yeah, I am not sure we can support the semantics as they are in Orleans, since BEAM won't even let that happen.  It may be that we want to have two behaviors here: a new activation for a stateless grain, and a message sent to a stateful grain.

Also mentioned by @tsloughter in chat: "spawn separate processes and run a callback".  This could be an appealing model, as you could get timely action and if needed the callback could send a message to the grain for a state update.

@tsloughter The Orleans devs have been amazingly gracious to questions if you want to open an issue on the github repo

Ah cool, thanks @mrallen1 . I know some projects don't even like you asking questions about your problems running their project if it isn't a definite bug, let alone asking general questions to help with a clone :)
Might also be interesting to look at and ping those working on https://github.com/OrleansContrib/Orleankka

Orleans timers docs for reference: http://dotnet.github.io/orleans/Documentation/Advanced-Concepts/Timers-and-Reminders.html


EdgeDriver Version 116.0.1938.69 - Changed behaviour for WindowHandles Count with Open PrintDialog

We are testing a WebApp with Selenium 4 (Version 4.11) on Edge Browser.
about 3 weeks ago the Browser was updated to Microsoft Edge for Business Version 116.0.1938.54 in our company, and thus we also had to update the Webdriver to version 116.0.1938.54
We are facing the following issue now in our TestAutomation project: We use the count of WindowHandles to check if a PrintDialog was opened. So far the WindowHandles was increased by 1 when the Print Dialog was opened an we could switch to it an close it (via JavaScriptExcecutor).
Since the update we are facing the issue that the count of WindowHandles remains unchanged when the Print Dialog is opened.
The Version installed before was Version Microsoft Edge 115.0.1901.203 (no mention of For Business)
Attached file shows a screenshot of VisualStudio in Debug-Mode showing the value of WindowHandles and the state of the Browser at this time

@anitabogner did you ever make progress on this issue? I saw your posts in other forums and did not have any success with adding webview to the windowtypes. Wondering if you are still having this problem or if you found a workaround. Thanks!

@evanbaule Unfortunately no progress so far :(
I also tested the behaviour with Edge / EdgeDriver Versions 117 and 118 but the issue still occurs there => WindowHandles remains 1 after Print window is opened.
Adding Webview to the windowTypes also did not solve the issue for me, because as I mentioned it does not give access to the area with the Print and Cancel buttons just the area with the document preview :(
As a workaround I tried closing the print dialog with a small AutoIt script (by sending ESC to the browser window). This basically worked but only on my local machine. In our setup the tests are running on a remote machine without user logged in. This workaround requires an active UI session to be working, so still fails in our nightly testrun.
So I'm still waiting / hoping for a reply from Microsoft if there will be a fix or information how the issue could be resolved.

@anitabogner Thanks for the response, I'm in nearly the same position. We run a variety of scripts with headless browsers where blindly throwing keypress events towards the screen would not solve any issues.
I'm experimenting a bit with kiosk-mode https://stackoverflow.com/questions/65931706/start-microsoft-edge-in-silent-printing-kiosk-printing-mode-from-command-promp as a potential alternative, something you may find to be helpful?
We try to configure the behavior so that we can either close the dialog or confirm and print based on the need at the time, so I'm unsure if this is actually going to unblock us but it appears that this startup option is going to be our best bet if we don't get a response from MS. I don't know if there is actually a way to tell the driver to open the browser in kiosk mode, but I do know that you can open the browser with a specified remote debugging port and then attach the webdriver as a secondary operation.

Thank you for reporting this. We've recently a few reports of recently changed behavior around the print dialog. I've added this to our internal backlog for investigation.

I am facing similar issue. details here Notification popup is treated as window/tab in Edge - headless
Only in headless mode, windowhandles considers download notification as new tab. For me, only workaround is to disable notification
options.AddUserProfilePreference("browser.show_hub_popup_on_download_start", false);


Can no longer nest Application.MainLoop.Invoke (since 1.8.2)

Describe the bug
This is a behavior change in 1.8.2 and not present in 1.7.2
If a view is launched via Invoke e.g.
btnLaunch.Clicked += ()=>{
    Application.MainLoop.Invoke(()=>Application.Run(startWindow));
    };

Then any calls to Invoke that are triggered from the startWindow are blocking and never finish until the window is closed.
While the issue is easiest to demonstrate by launching a window via Invoke I think the issue manifests in other ways too.  For example I have a window where callbacks cannot be registered in 1.8.2 (blocks until window is closed) - see https://github.com/HicServices/RDMP/pull/1448 .

I have looked hard and can't see any problematic Invokes in my code but I think it is definitely related to the new locking behavior
UPDATE: Ok I know why my code is getting this deadlock, it is because of the use of ContextMenu.  If you update the demo code to launch the test window via a menu you get same problem:

var menu = new ContextMenu();
menu.MenuItems = new MenuBarItem(new []{new MenuItem("Launch",null,()=>Application.Run(startWindow))});

    btnLaunch.Clicked += ()=>{
        menu.Show();
    };

When running on 1.8.2 the 'Click Me' button gets stuck at 'Cancel' and its callback to increment the counter never happens. So total only increases by 1 when you press it instead of 4.  In 1.7.2 it works correctly
To Reproduce
I have created a minimum repro:
using Terminal.Gui;

class Program
{
    static int total = 0;
    static Button btn;
    public static void Main()
    {
        Application.Init();

        var startWindow = new Window{
            Modal = true
        };

        btn = new Button{
            Text = "Click Me"
        };

        btn.Clicked += RunAsyncTest;

        var totalbtn = new Button(){
            X = Pos.Right(btn),
            Text = "total"
        };

        totalbtn.Clicked += ()=>{
          MessageBox.Query("Count",$"Count is {total}","Ok");
        };

        startWindow.Add(btn);
        startWindow.Add(totalbtn);

        var splash = new View();
        var btnLaunch = new Button("Open Window");

        // Goes fine
        /*btnLaunch.Clicked += ()=>{
            Application.Run(startWindow);
            };*/
        // Goes badly
        btnLaunch.Clicked += ()=>{
            Application.MainLoop.Invoke(()=>Application.Run(startWindow));
            };

        splash.Add(btnLaunch);

        Application.Top.Add(btnLaunch);

        Application.Run();

        Application.Shutdown();

    }

    private static void RunAsyncTest()
    {
        btn.Text = "Cancel";
        Interlocked.Increment(ref total);
        btn.SetNeedsDisplay();

        var task = Task.Run(()=>
        {
            try
            {
                RunSql();
            }
            finally{
                SetReadyToRun();
            }
        }).ContinueWith((s,e)=> {

            Interlocked.Increment(ref total);

            },TaskScheduler.FromCurrentSynchronizationContext());
    }

    private static void RunSql()
    {
        Thread.Sleep(100);
        Application.MainLoop.Invoke(() => {
            Interlocked.Increment(ref total);
            btn.Text = "Pew Pew";
            btn.SetNeedsDisplay();
        });
    }

    private static void SetReadyToRun()
    {
        Application.MainLoop.Invoke(()=>{
            btn.Text = "Click Me";
            Interlocked.Increment(ref total);
            btn.SetNeedsDisplay();
        });
    }
}

For csproj use:
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net6.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Terminal.Gui" Version="1.8.2" />
  </ItemGroup>

</Project>

Run program then change back to 1.7.2 package reference
Expected behavior
Not sure, I'm open to discussion

This is due to the #1994. @tig had alerted about (BREAKING CHANGE). So the question is would if this is the write behavior, avoiding tasks popup on the main thread that uses a modal as true, or should to be reverted to the previous behavior?

I think in terms of user stories we want to start with the following:
I want to be able to launch modal dialogs from Button or ContextMenu click handlers.  And for those windows to behave normally (i.e. be able to use invokes).
Currently launching a modal Window from Button behaves differently from ContextMenu (The difference being that the resulting dialog cannot do its own invokes).  I think because Action gets run through invoke in Menu:
https://github.com/gui-cs/Terminal.Gui/blob/32e7b63b77655ff07dc3a9dce6074e77d0590fa3/Terminal.Gui/Views/Menu.cs#L571-L584
While in Button it is not:
https://github.com/gui-cs/Terminal.Gui/blob/7b93f443fe68aa2c713f27486e3cae3184bf3ac0/Terminal.Gui/Views/Button.cs#L229-L235
We should understand why they are behaving differently, which one is more correct and how we can adjust the current code to still have the good stable locking stuff added in #1994 but also allow for this user story.

Sorry, I made confusion because I thought you wanted that the follow should work, but was only to demonstrate the behavior you have mention.
Application.MainLoop.Invoke(()=>Application.Run(startWindow));
The menu run action is the same as the original but since the idle handlers lock was fixed, running a action through the Application.MainLoop.Invoke will block another following calls through the Application.MainLoop.Invoke because the running action block the idle handlers. If you wish I can submit a PR to change the Menu action calls or if you already have a fix for this I let you fix it.

Sorry, I made confusion because I thought you wanted that the follow should work, but was only to demonstrate the behavior you have mention. Application.MainLoop.Invoke(()=>Application.Run(startWindow));

Yeah my post was a bit muddled, sorry about that.  I created Issue when I had a repro but before I had traced it down to ContextMenu callback being the responsible.
Good fix though! Thanks


Heroku deployment is incompatible with VCS-based versioning using setuptools-scm and friends

It's become common practice to use something like setuptools-scm to manage package versioning automatically using Git or other version control history (sometimes via another tool like hatch-vcs).
What this often means in practice (and I admit it is not too clear from the setuptools-scm documentation) is that the project version is defined in a Python module, e.g. mypackage/__version__.py which is NOT checked in to Git but is generated dynamically when the project is installed (possibly in "editable" mode with pip install -e .).
You may see where I'm going with this - this is fundamentally incompatible with the way Heroku deploys things, because, from what I can tell:

Heroku's so-called "compile" process does not actually build (or compile) your app in any way except if there is no requirements.txt file.
Thus, anything generated as part of the build process is not actually generated (no Cython for you!).  Okay, well I guess you can use bin/post_compile to actually, um, compile your app.
But here's the really fun part: despite using Git for deployment, you don't actually have access to the Git history in the build process.  So, no versions for you, either!

So, you can hack around this by using the SETUPTOOLS_SCM_PRETEND_VERSION environment variable, which I guess is fine as long as you don't actually care about having the same version number as you otherwise would have.
In the case where your Heroku app is also a library distributed on PyPI, this is kind of annoying.

Hi!
You are correct that the .git/ directory is not present during the build itself (and thus not available to buildpacks). However, this design choice is not specific to the Python buildpack, but instead the whole Heroku build system. It has been implemented this way for some time - I would imagine due to some combination of:

Wanting to avoid the .git/ directory from ending up in the slug
Wanting to reduce the size of the payload sent from the git.heroku.com server to the build system
Wanting to avoid the need to clone the Git repo in the case of GitHub sync workflows and instead being able to use the direct source archive tarball instead
No one having asked for this before (deploying a library repo directly is very rare)

However, the originally commit information is available via the SOURCE_VERSION env var:
https://devcenter.heroku.com/articles/buildpack-api#bin-compile
Since this issue is not specific to the Python buildpack, it would be best to file this as a "make Git repo available during the build" feature request here:
https://github.com/heroku/roadmap
As a workaround for this specific scenario, it seems your options are either:

Set the SETUPTOOLS_SCM_PRETEND_VERSION env var on your app to a fixed fake value (which as you say, won't match the actual version)
See if there is a way to configure setuptools-scm to use SOURCE_VERSION if it's set.
Or, if setuptools-scm can't be made to use SOURCE_VERSION directly, then to create a buildpack that exports the SOURCE_VERSION env var to the env var SETUPTOOLS_SCM_PRETEND_VERSION using the export file: https://devcenter.heroku.com/articles/buildpack-api#composing-multiple-buildpacks

Thanks for the really detailed response - I definitely understand why copying the .git folder to the deployment isn't a great idea.  I'm a little bit surprised nobody ran into this problem before though...
It looks like there is a workaround possible, so I'll post it here when I figure it out and close the issue at that point (since as you say this is by design).

No problem!

Or, if setuptools-scm can't be made to use SOURCE_VERSION directly, then to create a buildpack that exports the SOURCE_VERSION env var to the env var SETUPTOOLS_SCM_PRETEND_VERSION using the export file: https://devcenter.heroku.com/articles/buildpack-api#composing-multiple-buildpacks

I haven't tested this (so there might be a typo in there), but a buildpack with a bin/compile script with something like the following contents should work:
#!/usr/bin/env bash

set -euo pipefail

BUILDPACK_DIR=$(cd $(dirname $0); cd ..; pwd)

echo "export SETUPTOOLS_SCM_PRETEND_VERSION='${SOURCE_VERSION}'" > "${BUILDPACK_DIR}/export"

Closing since this isn't an issue with the Python buildpack, and there are workarounds available.


manager-login-api

Coverage remained the same at 100.0% when pulling 14fff8a340a02d8da249504496e456e84ca8c09d on PandaMino:master into 37ddbe07b5d72487e73d28ef37ecc91e8c7ac46c on rugao-web-fullstack:master.

Coverage increased (+0.07%) to 98.63% when pulling a26a69895da0d5b68eee4bdbf23f03f4a201789b on PandaMino:master into d657c2fdd684408816afe06143e000150336f0b2 on rugao-web-fullstack:master.

冲突还没有解决。

Coverage increased (+0.09%) to 97.692% when pulling 5fbaa0233e172888e6e1b71e71646a7f470014a1 on PandaMino:master into 346cb3923121c2b40c7eb496808d178d191ef595 on rugao-web-fullstack:master.

Coverage increased (+0.07%) to 97.68% when pulling 9628fedc3073ff9cff9074d6636794608df30083 on PandaMino:master into 346cb3923121c2b40c7eb496808d178d191ef595 on rugao-web-fullstack:master.

Coverage increased (+0.07%) to 98.017% when pulling c30ca2245aee7de25091e6d9f3e4059d8cc95671 on PandaMino:master into 8c48ba0d64dd2e692c7c05e686239aa6610f9d39 on rugao-web-fullstack:master.

Coverage increased (+0.07%) to 98.01% when pulling 985e8ac5a70bfff5a8ddd951f6f4a7065a22221f on PandaMino:master into 400b2e4ebd3bebdde7aab698fb0277e7e88dcafd on rugao-web-fullstack:master.

Coverage increased (+0.07%) to 97.887% when pulling bcf2026caa634b1784be391def105b7a240cf01f on PandaMino:master into a3885007aa9ed08e036ac1cb919581633885f48a on rugao-web-fullstack:master.


Bug in tf.image.resize_images

System information
I am running Ubuntu 18.0.4 on my PC with CUDA-10 and Python 3.6 and Pillow 5.4.1
libcudnn7:
  Installed: <IP_ADDRESS>-1+cuda10.0
  Candidate: <IP_ADDRESS>-1+cuda10.0

with Tensorflow version b'v1.12.0-0-ga6d8ffae09' 1.12.0
Describe the problem
I am trying to resize an image with tf.image.resize_images using all available methods but I am getting completely crappy results for anything except NEAREST_NEIGHBOR
For example simply loading this image from the test set of Imagenet

I get colorful pixel salad if I put it through resize_bilinear
see code and output below.
Source code / logs
To reproduce place the code and the image file above in the same folder or adjust the file-path accordingly:
import tensorflow as tf
from PIL import Image
import time
import numpy as np

file_read = tf.read_file('ILSVRC2012_test_00000002.JPEG')
loaded_image = tf.image.decode_jpeg(file_read, channels=3)
reshape_image = tf.expand_dims(loaded_image, 0)
resized_image = tf.image.resize_bilinear(reshape_image, size=[510, 520], align_corners=False)
resized_image_v2 = tf.image.resize_images(reshape_image, size=[300, 320],
                                          method=tf.image.ResizeMethod.BILINEAR, align_corners=False)
# resized_image_v2 = tf.image.resize_images(reshape_image, size=[300, 320],
                                          method=tf.image.ResizeMethod.NEAREST_NEIGHBOR, align_corners=True)
with tf.Session() as sess:
    sess.run(tf.global_variables_initializer())
    orig_image = sess.run(loaded_image)
    resized_v1 = sess.run(resized_image)
    resized_v2 = sess.run(resized_image_v2)
    orig_img = Image.fromarray(orig_image, 'RGB')
    resized_v1_img = Image.fromarray(np.squeeze(resized_v1), 'RGB')
    resized_v2_img = Image.fromarray(np.squeeze(resized_v2), 'RGB')
    orig_img.show()
    resized_v1_img.show()
    resized_v2_img.show()
    time.sleep(10)
    orig_img.close()
    resized_v1_img.close()
    resized_v2_img.close()

This produces for the original image:

for the larger resize:

for the smaller resize:

I get similar crappy results if I set align_corners=True
However if I use method=tf.image.ResizeMethod.NEAREST_NEIGHBOR (i.e. the commented out line), I get a descent result

With BICUBIC and AREA the results are similar pixel garbage as with BILINEAR
Am I missing something here? This seems to be seriously broken.

Trying the same with OpenCV gives me perfectly reasonable results for both Bilinear and Nearest Neighbor
import cv2

file_read = cv2.imread('ILSVRC2012_test_00000002.JPEG')

resized_image_bl = cv2.resize(file_read, dsize=(300, 320), interpolation=cv2.INTER_LINEAR)
resized_image_nn = cv2.resize(file_read, dsize=(300, 320), interpolation=cv2.INTER_NEAREST)

cv2.imshow('original_image', file_read)
cv2.imshow('bilinear image', resized_image_bl)
cv2.imshow('NN image', resized_image_nn)

cv2.waitKey(0)  # waits until a key is pressed
cv2.destroyAllWindows()  # destroys the window showing image

Never mind. I simply did not catch that BILINEAR converts the Tensor automatically to tf.float32 ...
a simple numpy astype(np.uint8) solves the mytery ...
Grrrr

@maxfiedler Thanks for resolving and posting the solution here. Thanks again!

Are you satisfied with the resolution of your issue? Yes No


Release section for 1.10

Description

Urgency

[ ] Blocker
[x] High
[ ] Medium

Requirements

Test all commands and procedures.
Build content locally and test for formatting/links.
Add redirects to dcos-website/redirect-files.
Change all affected versions (e.g. 1.7, 1.8, and 1.9).
See the contribution guidelines.

Hey, team, I got approval for the text from prod and marketing but would love two really thorough reviews before merging. Submitting a separate PR to pin the 1.10.0-rc1 release notes download button to a specific version. Thank you!

Hi, I'd love a review of this before we ship any more 1.10 versions in order to avoid merge conflicts. @karlkfi and @joerg84 or @pleia2 do you have time tomorrow to review it? Thanks!


generated memcache c.Watch in controller does not match user guide

Bug Report

What did you do?
A clear and concise description of the steps you took (or insert a code snippet).
What did you expect to see?
A clear and concise description of what you expected to happen (or insert a code snippet).
I ran the operator-sdk and followed the user guide example for generating memcache CRDs and controller.  In the generated memcached_controller.go I expected to see the following as mentioned in the user guide:
err := c.Watch(&source.Kind{Type: &appsv1.Deployment{}}, &handler.EnqueueRequestForOwner{
IsController: true,
OwnerType:    &cachev1alpha1.Memcached{},
})
What did you see instead? Under which circumstances?
Instead what I saw in my generated memcached_controller.go I saw the following:
err = c.Watch(&source.Kind{Type: &corev1.Pod{}}, &handler.EnqueueRequestForOwner{
IsController: true,
OwnerType:    &cachev1alpha1.Memcached{},
})
Environment

operator-sdk version:
operator-sdk version: "v0.15.0-5-g6b4e137", commit: "6b4e1370f18e5d028b283375b740026d2efb0a44",

go version:
go version: "go1.13.3 darwin/amd64"

Kubernetes version information:

Kubernetes cluster kind:

Are you writing your operator in ansible, helm, or go?

Possible Solution

I would update doc/user-guide.md to instead show what the c.Watch really looks like. So I would update the user guide to instead show this:
err = c.Watch(&source.Kind{Type: &corev1.Pod{}}, &handler.EnqueueRequestForOwner{
IsController: true,
OwnerType:    &cachev1alpha1.Memcached{},
})
If you agree this issue is correct I am happy to submit a PR to fix it
Additional context
Add any other context about the problem here.

Hi @bradtopol .
Thank you for posting question. As per the user guide, Once scaffold is created, you are supposed to "replace"  memcached_controller.go implementation. Its possible you may have missed this step, and were looking at the original scaffolded file.
**_This will scaffold a new Controller implementation under pkg/controller/memcached/....
For this example replace the generated Controller file pkg/controller/memcached/memcached_controller.go with the example memcached_controller.go implementation._**
https://github.com/operator-framework/operator-sdk/blob/master/example/memcached-operator/memcached_controller.go.tmpl
Please take a look and let us know of any further concerns.

Hi @bharathi-tenneti!  Thank you for the helpful response.  Yes, you are correct.  Somehow I missed that step.   Things make a lot more sense now. :-)


StackoverflowException when running Windows Container image with mounted volume

Please provide a brief summary of the bug
I'm trying to run eclipse-temurin with JDK11 on a Windows machine with drive D: mounted into the container and the containers is existed with the following error:
Process is terminated due to StackOverflowException.

Same error happens with JDK8, JDK17 and JDK19
Please provide steps to reproduce where possible
StackoverflowException:
docker run -it --rm -v "d:\:d:" --entrypoint=powershell eclipse-temurin:11.0.17_8-jdk-windowsservercore-1809

Running the same image without the volume mount, the powershell is started:
docker run -it --rm --entrypoint=powershell eclipse-temurin:11.0.17_8-jdk-windowsservercore-1809

Running on older version is ok:
docker run -it --rm -v "d:\:d:" --entrypoint=powershell eclipse-temurin:<IP_ADDRESS>_1-jdk-windowsservercore-1809

StackoverflowException JDK19:
docker run -it --rm -v "d:\:d:" --entrypoint=powershell eclipse-temurin:19-jdk-windowsservercore-1809

Expected Results
Powershell should be opened inside the container.
Actual Results
Error Process is terminated due to StackOverflowException.
What Java Version are you using?
11.0.17_8
What is your operating system and platform?
Windows Server 2019 Datacenter Version 1809 (OS Build 17763.3650)
How did you install Java?
Docker Image
Did it work before?
No response
Did you test with other Java versions?
No response
Relevant log output
Docker info:

Client:
 Context:    default
 Debug Mode: false

Server:
 Containers: 1
  Running: 1
  Paused: 0
  Stopped: 0
 Images: 60
 Server Version: 20.10.17
 Storage Driver: windowsfilter
  Windows:
 Logging Driver: json-file
 Plugins:
  Volume: local
  Network: ics internal l2bridge l2tunnel nat null overlay private transparent
  Log: awslogs etwlogs fluentd gcplogs gelf json-file local logentries splunk syslog
 Swarm: inactive
 Default Isolation: process
 Kernel Version: 10.0 17763 (17763.1.amd64fre.rs5_release.180914-1434)
 Operating System: Windows Server 2019 Datacenter Version 1809 (OS Build 17763.3650)
 OSType: windows
 Architecture: x86_64
 CPUs: 4
 Total Memory: 4GiB
 Name: xxxxxx
 ID: xxxxxx
 Docker Root Dir: D:\docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  <IP_ADDRESS>/8
 Live Restore Enabled: false

It turned out to be an issue with Powershell and/or Windows, but only happens when Docker's data-root is on the same drive as the bind mount. Closing this and other issue is linked.


Create GH pages docs

The gradle-git-publish plugin conflicts with others. I'm not sure if there's an alternative solution.

Use https://github.com/spring-gradle-plugins/spring-release-plugin


Unable to load GOST3410-2012 key from a PKCS#12 store

Hi there,
I'm trying to use Bouncy Castle to sign data with given certificate and key from a PCKS#12 container. But I'm getting this error:
Caused by: java.io.IOException: exception unwrapping private key - java.security.InvalidKeyException: Invalid key encoding.
	at org.bouncycastle.jcajce.provider.keystore.pkcs12.PKCS12KeyStoreSpi.unwrapKey(Unknown Source)
	at org.bouncycastle.jcajce.provider.keystore.pkcs12.PKCS12KeyStoreSpi.engineLoad(Unknown Source)
	at java.security.KeyStore.load(KeyStore.java:1445)
	at BouncyCastleGostTest.main(BouncyCastleGostTest.java:32)

The container is created with the following command:
openssl req -newkey gost2012_256 -pkeyopt paramset:A  -passout pass:test -keyout test.key -out test.crt -x509 -days 3650
openssl pkcs12 -engine gost -export -in test.crt -inkey test.key -out container.p12 -password pass:test -passin pass:test

This is the code I used:
public class BouncyCastleGostTest {

    static {
        BouncyCastleProvider bcProvider = new BouncyCastleProvider();
        String name = bcProvider.getName();
        Security.removeProvider(name);
        Security.addProvider(bcProvider);
    }

    public static void main(String[] args) throws Exception {

        final File file = new File("/tmp/container.p12");

        final byte[] keyStoreData = Files.readAllBytes(file.toPath());

        final String password = "test";
        final String keyPassword = "test";

        final KeyStore keyStore = KeyStore.getInstance("PKCS12", "BC");

        try (ByteArrayInputStream is = new ByteArrayInputStream(keyStoreData)) {
            keyStore.load(is, password.toCharArray());
        }

        final String alias = keyStore.aliases().nextElement();
        keyStore.getKey(alias, keyPassword.toCharArray());
    }
}

Is this a bug or am I doing something wrong? I'm using BouncyCastle 1.64.
Thanks!

Can you provide a copy of the PKCS#12 key store? Not all versions of OpenSSL are equal...

Thanks for your prompt answer!
Here are the files:
Container: https://drop.helldev.net/2f5995ac-054e-4702-b709-81482194206c/container.p12
Certificate: https://drop.helldev.net/4cd20f1d-a685-4efc-8476-ddd8e5a0eeb9/test.crt
Private Key: https://drop.helldev.net/501ab601-7db7-4831-8eef-21e91f683f1f/test.key
All passwords are: test.
I'm using OpenSSL 1.1.1  11 Sep 2018 which is a part of Ubuntu 18.04.4 LTS.

I've uploaded a new beta which I think will fix this - it seems the private key is encoded without a wrapping OCTET STRING, seems to be easy enough to deal with. See https://www.bouncycastle.org/betas for details.

Thanks a ton for your fix, @bcgit!
It works well now.

And thanks for the report. Will be in 1.65.


ACR Build doesn't properly parse .dockerignore

Describe the bug
I had a problem where az acr build would always send an empty context (75 bytes, and the .tar.gz file in %TEMP% was empty).
Turns out my .dockerignore was the problem, I've attached it to this issue so you can take a look at it, but it basically ignores everything ** then un-ignores a few things.
dockerignore.zip
To Reproduce

Create a .dockerignore file that starts with ** then add a few ! lines to un-ignore the folders you want to add to the context.
Run az acr build
Notice that it sends a 75 byte context and it will fail to find your Dockerfile

Expected behavior
I expect it to parse the .dockerignore just like regular docker, and thus only send the folders I need while ignoring everything else.
Environment summary
azure-cli (2.0.42)
acr (2.1.0)
Docker Version: 18.06.0-ce
OS: Windows 10 Version 1803
Shell Type: Powershell and CMD

@northtyphoon

closing


Handle required properties

Codecov Report

Merging #280 (52ba3ac) into master (0427f62) will decrease coverage by 0.03%.
The diff coverage is 66.66%.

@@            Coverage Diff             @@
##           master     #280      +/-   ##
==========================================
- Coverage   67.93%   67.89%   -0.04%
==========================================
  Files          20       20
  Lines        6854     6890      +36
==========================================
+ Hits         4656     4678      +22
- Misses       2198     2212      +14

Impacted Files
Coverage Δ

stix2elevator/cli.py
0.00% <0.00%> (ø)

stix2elevator/test/test_main.py
100.00% <ø> (ø)

stix2elevator/convert_stix.py
80.87% <66.66%> (-0.41%)
:arrow_down:

stix2elevator/options.py
76.96% <100.00%> (-0.26%)
:arrow_down:

stix2elevator/convert_pattern.py
73.72% <0.00%> (-0.02%)
:arrow_down:

stix2elevator/test/test_utils.py
0.00% <0.00%> (ø)

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 0427f62...52ba3ac. Read the comment docs.


It doesn't seem work with emmVRC

I am unsure why this is the case, the hook looks completely valid but it doesn't work

I don't understand anything abt coding but maybe emmVRC uses it's own hook that bypass the game hook ?

Bump on this!

This should be fixed with 201050c >=0.4.0
I don't use emmVRC because it has nothing in it, so you'll have to test it.
It works with VRChatUtilityKit and that has the same code.
@UrLittleDashie @EntityReborn

i downloaded this and it wont fix my problem with the blood in the corners of my walls. how do i fix the blood? the blood will not go away, neither will the soft groaning from the rotting body in the basement.

This worked. Thanks!


Release v0.1.15

We've achieved quite a lot since last release:

Loading chains faster from disk
Load initial peers from multiple URL's
Cleaner multi-process mining

What do we need in order to push out the next release?
I would like to have these fixed:

#54 ValueError: Invalid descriptor: -1
#25  Too many open files

Opinions? @atramos @sashimi-houdini

My opinion is "Ship It!". Many users currently impacted by fixed issues, see recent comment traffic in #1.

I'm quite happy to just release "now"; and release again when the other issues are fixed. I'll get to it.

https://pypi.org/project/skepticoin/0.1.15/
As per usual, I just "shot from the hip" by running the tag and upload commands straight from master without any checks.


How to fix "Column could not be matched with a fieldtype" on generate-blueprints from migration?

Discussed in https://github.com/statamic-rad-pack/runway/discussions/521

Originally posted by IVoyt June 12, 2024
Description
When I try to generate a blueprint from a migration with php please runway:generate-blueprints <resource-handle> I permanently get error from the title.
I have a migration with fields integer (int11) and string (varchar255). Which field types I have to specify to successfully generate blueprint from the migration?
 What version of MySQL are you running?
Can you run Schema::getColumns('your_table_name'); and paste the results here?

\Illuminate\Support\Facades\Schema::getColumns('your_table_name');

here is the output
array:7 [
  0 => array:9 [
    "name" => "id"
    "type_name" => "bigint"
    "type" => "bigint(20) unsigned"
    "collation" => null
    "nullable" => false
    "default" => null
    "auto_increment" => true
    "comment" => null
    "generation" => null
  ]
  1 => array:9 [
    "name" => "name"
    "type_name" => "json"
    "type" => "json"
    "collation" => null
    "nullable" => false
    "default" => null
    "auto_increment" => false
    "comment" => null
    "generation" => null
  ]
  2 => array:9 [
    "name" => "logo"
    "type_name" => "json"
    "type" => "json"
    "collation" => null
    "nullable" => false
    "default" => null
    "auto_increment" => false
    "comment" => null
    "generation" => null
  ]
  3 => array:9 [
    "name" => "url"
    "type_name" => "varchar"
    "type" => "varchar(255)"
    "collation" => "utf8mb4_unicode_ci"
    "nullable" => false
    "default" => null
    "auto_increment" => false
    "comment" => null
    "generation" => null
  ]
  4 => array:9 [
    "name" => "status"
    "type_name" => "int"
    "type" => "int(11)"
    "collation" => null
    "nullable" => false
    "default" => null
    "auto_increment" => false
    "comment" => null
    "generation" => null
  ]
  5 => array:9 [
    "name" => "created_at"
    "type_name" => "timestamp"
    "type" => "timestamp"
    "collation" => null
    "nullable" => true
    "default" => null
    "auto_increment" => false
    "comment" => null
    "generation" => null
  ]
  6 => array:9 [
    "name" => "updated_at"
    "type_name" => "timestamp"
    "type" => "timestamp"
    "collation" => null
    "nullable" => true
    "default" => null
    "auto_increment" => false
    "comment" => null
    "generation" => null
  ]
]


login and synchronization on extentions (label:feature-request)

I would like to propose a new feature. A way to login with an account and automatically install the extentions added to the account itself in a new installation.
Thanks

Duplicate of #2743 ?

@chrmarti The bot is going crazy with those D issues.

/duplicate #2743


Add brew-burlap command

brew-burlap is a wrapper around bundler, which executes bundler within Homebrew's superenv build environment. Using superenv helps make gems' Homebrew dependencies discoverable when building C extensions thanks to Homebrew's compiler shims and other flags set by superenv. It also helps prevent gems from detecting certain dependencies which weren't specified in the Brewfile, which can help make Brewfile/Gemfile combos more reliable longterm. The Brewfile is used to supply the list of formulae to use as dependencies.
This was written because a common issue, when converting projects to use a Brewfile, was that gems specified in the Gemfile would opportunistically pick up unspecified libraries. This led to dependencies being forgotten.
For example, the charlock_holmes gem requires icu4c, and is able to pick it up opportunistically even though it's keg-only. However, if the bundle install is run within superenv with icu4c not specified as a dependency, the build is properly isolated, and brew burlap install will only succeed if icu4c is in the Brewfile. There are some superenv improvements to be made that can make this even more reliable.
(Why brew-burlap? You wrap up a bundle in burlap!)

If I understand correctly, you may want to make it more general as brew bundle exec command. So you could run brew bundle exec gem/bundle/pip/npm and so on.

This passes any arguments to the command to bundle, so bundle exec equivalents do work; e.g. brew burlap exec [...]. The intention is for it to act very transparently as a wrapper around bundler, with any bundler commands working.

Rereading, I get your suggestion now - making it more generic probably is a better idea, so, e.g., it can wrap other non-bundler external commands. That's a good idea, better than making this bundler specific! I'll look at

Added a commit which migrates this to a brew bundle wrap command. (Decided to name it wrap instead of exec because bundle exec already exists, and running brew bundle exec bundle exec would be confusing.) Any arguments after wrap are the full commandline which will be executed, e.g. brew bundle wrap bundle install --binstubs --path vendor/gems.

/Users/travis/build/Homebrew/homebrew-bundle/lib/bundle/commands/wrap.rb:1:in `require': cannot load such file -- extend/ENV (LoadError)

That's interesting, is the CI run without access to Homebrew's own code?

Yeh, tests should have Homebrew's code stubbed out. You can test locally with rake. I think wrap is a nicer name than burlap but brewenv setenv superenv homebrewexec or similar might be a nicer/more self-explanatory. We'll need enough tests here to maintain the 100% coverage we had before.
Otherwise: neat idea and 👍

I've been having a lot of trouble coming up with good names, which has me coming back around to exec despite the possibility of brew bundle exec bundle exec rake coming up. To fit with the other ones it feels like it should be a verb of some kind, and I felt that to many users something like superenv might not communicate very much. Currently using isolate, with the implication that the command is being isolated from the global environment.

@mistydemeo I think I like exec; with isolate it's not clear what and how it's being isolated. Presumably the reason for this not being a separate command is that's it's using superenv to restrict to only the stuff in the Brewfile?

@mistydemeo About the README: that was when I thought this was adding a DSL value; I see and understand now what this is doing so that nothing is needed in dsl_spec.rb 👍

Renamed to exec.

Looks good to me 👍. :shipit:


Ore generation seems to be broken regardless

no idea why.

It seems as though ore generation is only broken when far lands are disabled, and become fixed when enabled.

Vanilla apparently fixes this in 1.16.2 snapshots anyway: https://bugs.mojang.com/browse/MC-185925
Hopefully they've actually fixed it and not the repetition I use to reproduce it.


Cross compile failed due to sqlite in PD.

Bug Report
Please answer these questions before submitting your issue. Thanks!
PD crossing compile failed due to sqlite on macOS. Here 's the log:
$ SWAGGER=0 GOOS=linux make pd-server
make dashboard-ui
./scripts/embed-dashboard-ui.sh
+ Create cache directory
+ Fetch Dashboard Go module
+ Discover Dashboard UI version
  - Dashboard directory<EMAIL_ADDRESS>  - Dashboard ui version: 20200619_3
+ Check embedded assets exists in cache
  - Cached archive exists: /Users/yisa/Downloads/Github/GoProject/src/github.com/pingcap/pd/.dashboard_asset_cache/embedded-assets-golang-20200619_3.zip
+ Unpack embedded asset from archive
Archive:  /Users/yisa/Downloads/Github/GoProject/src/github.com/pingcap/pd/.dashboard_asset_cache/embedded-assets-golang-20200619_3.zip
  inflating: embedded_assets_handler.go
  - Unpacked pkg/dashboard/uiserver/embedded_assets_handler.go
CGO_ENABLED=1 go build  -gcflags '' -ldflags '-X "github.com/pingcap/pd/v4/server.PDReleaseVersion=v4.0.0-rc.2-77-g2a5e97ac" -X "github.com/pingcap/pd/v4/server.PDBuildTS=2020-08-07 05:42:42" -X "github.com/pingcap/pd/v4/server.PDGitHash=2a5e97ac3d7e9ea1e3c89d04a741e19ee9acb885" -X "github.com/pingcap/pd/v4/server.PDGitBranch=sh-poc" -X "github.com/pingcap/pd/v4/server.PDEdition=Community"' -tags "" -o bin/pd-server cmd/pd-server/main.go
# os/user
../../../../../../GOVERSION/go1.13.4/src/os/user/getgrouplist_unix.go:16:35: warning: passing 'gid_t *' (aka 'unsigned int *') to parameter of type 'int *' converts between pointers to integer types with different sign [-Wpointer-sign]
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/unistd.h:653:43: note: passing argument to parameter here
# github.com/mattn/go-sqlite3
sqlite3-binding.c:33123:42: error: use of undeclared identifier 'pread64'
sqlite3-binding.c:33141:42: error: use of undeclared identifier 'pwrite64'
sqlite3-binding.c:33274:22: error: invalid application of 'sizeof' to an incomplete type 'struct unix_syscall []'
sqlite3-binding.c:33283:22: error: invalid application of 'sizeof' to an incomplete type 'struct unix_syscall []'
sqlite3-binding.c:33310:20: error: invalid application of 'sizeof' to an incomplete type 'struct unix_syscall []'
sqlite3-binding.c:33327:16: error: invalid application of 'sizeof' to an incomplete type 'struct unix_syscall []'
sqlite3-binding.c:14220:38: note: expanded from macro 'ArraySize'
sqlite3-binding.c:33331:14: error: invalid application of 'sizeof' to an incomplete type 'struct unix_syscall []'
sqlite3-binding.c:14220:38: note: expanded from macro 'ArraySize'
sqlite3-binding.c:35984:11: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
sqlite3-binding.c:33127:49: note: expanded from macro 'osPread64'
sqlite3-binding.c:36096:17: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
sqlite3-binding.c:33145:57: note: expanded from macro 'osPwrite64'
make: *** [pd-server] Error 2

What did you do?
sqlite won't block PD cross compile process.

What did you expect to see?

What did you see instead?

What version of TiDB Dashboard are you using (./tidb-dashboard --version)?

The error is caused by the go-sqlite3 dependency. mattn/go-sqlite3#560 seems relevant.


Add a Gitter chat badge to README.md

ihucos/plash now has a Chat Room on Gitter
@ihucos has just created a chat room. You can visit it here: https://gitter.im/plash-containers/Lobby.
This pull-request adds this badge to your README.md:

If my aim is a little off, please let me know.
Happy chatting.
PS: Click here if you would prefer not to receive automatic pull-requests from Gitter in future.

Sir, it breaks the layout


Don't work with Figwheel

When I try to work with Figwheel, it gives me the warning:
Figwheel: Not loading code with warnings - target/js/cljs_deps.js
Figwheel: Compile Warning - expectations is a single segment namespace in file file:/home/mauricio/.m2/repository/expectations/expectations/2.2.0-rc3/expectations-2.2.0-rc3.jar!/expectations.cljc at line 1, column 1

I know I could just ignore warnings, but probably it's not a good idea when the fix would be relatively simple...

Changing the namespace would break backward compatibility so I can't do that.

So, any workaround?

Ignore the warnings?

Figwheel doesn't reload a file if it has warnings... also, sometimes, google closure compiler sometimes wouldn't load single segment ns, and there are a bunch of bugs in ClojureScript with this issue... doesn't seem right to add on every project that'll use expectation a line to ignore warning when it's discouraged by Clojure and ClojureScript. See discussion here: https://github.com/tonsky/datascript/issues/57
For now, I'm ignoring warnings from figwheel, so my code could reload again...

It's definitely unfortunate that expectations has always existed as a single-segment namespace.
When I added expectations.clojure.test, I did that as Clojure-only because a) I don't use ClojureScript and b) I don't know how to make a ClojureScript-compatible version of it (macros etc).
If you want to send a PR to copy expectations to expectations.core and have both expectations and expectations.clojure.test require that and import/intern all the symbols to maintain backward compatibility (and make sure all the clj and cljs tests still pass), I'd entertain that -- although I'm not sure cljs can do the intern thing?
But I'll be honest, cljs support has always been a bit of a pain in the @$$ as far as I'm concerned so it's low on my priority list 👎

Ok, I'll try something here and see if I can send you a PR.
Also, I agree with you: cljs support is indeed a pain...

If you have recommendations for unit-testing infrastructure for .cljc projects, I'm all ears!

Hi @mauricioszabo
I think You can fix the problem by adding :warnings {:single-segment-namespace false} to the  compiler option. See, https://clojurescript.org/reference/compiler-options#warnings
Here is my configuration:
:cljsbuild
{:builds {:dev {:source-paths ["src" "spec" "test" "tool"]
                :compiler {:main {{ns-name}}.core
                           :asset-path "js/out"
                           :output-to  "resources/public/js/app.js"
                           :output-dir "resources/public/js/out"
                           :optimizations :none
                           :source-map-timestamp true
                           :warnings {:single-segment-namespace false}
                           :parallel-build true}
                :figwheel {:on-jsload dev.tool/on-reload
                           :websocket-host :js-client-host}}

          :prod {:source-paths ["src" "spec"]
                 :compiler {:output-to "resources/public/js/app.js"
                            :optimizations :advanced
                            :fn-invoke-direct false ; Need more performance? If yes, turn it on.
                            ;; :source-map "resources/public/js/app.js.map" ; Uncomment this for debugging.
                            :pretty-print false
                            :parallel-build true}
                 :warning-handlers
                 [(fn [type env extra]
                    (let [root (str (System/getProperty "user.dir") "/")
                          path (clojure.string/replace-first cljs.analyzer/*cljs-file* root "")]
                      (when (re-find #"/{{sanitized}}/" path)
                        (-> (cljs.analyzer/error-message type extra)
                            (str " at line " (:line env) " " cljs.analyzer/*cljs-file*)
                            (ex-info {:tag :cljs/analysis-error})
                            (throw)))))]}}}

In advance, I am sorry if I misunderstand the problem.


[YUNIKORN-177] SchedulerName doesn't need to be configurable

hi @adamantal could you pls check why the e2e testing is failing?

It might because this line:
https://github.com/apache/incubator-yunikorn-k8shim/blob/590438fde5bd451744bc59b9074b91014d2938e3/.travis.yml#L58
it always installs the latest version of ginkgo . the CLI syntax might be changing. cc @ayubpathan for this issue.

Since I only substituted a string with a constant I don't think this is related to the patch itself. Should we file a jira for this e2e test failure?

Removed the changes from the e2e tests. I don't know what has caused this, seemed unrelated to me, but I'd rather not touch that part of the code.

Weird, it is still failing..

I think the test failure is not related. It failed with the following error: 'error: timed out waiting for the condition on deployments/yunikorn-scheduler'. However I tried to deploy it in the same way as the e2e test is doing, and it got deployed successfully. I would suggest to create a Jira to review the e2e test.

hi @kingamarton @adamantal
If you look at the docker file we used to build the scheduler, you'll see: https://github.com/apache/incubator-yunikorn-k8shim/blob/e11a7e068da3e8b024ceb86abe6c9a945308aca7/deployments/image/configmap/Dockerfile#L54. The schedulerName is part of the startup option. The PR here removes this option from the executable,  which causes the scheduler could not be started. I think the docker image also needs to be updated, to remove that option.

Yes, it is much clear now. Thanks for the comments!
I checked and actually the make run command was also affected (could not start the scheduler with the patch). Removed two occurences of he -name flag, and hopefully I caught each of them.

I just did a minor update that removes SCHEDULER_NAME env var in the docker file, rest looks good to me.  Merging now. Thanks @adamantal .

Thanks @yangwwei !


Institutes garbage collection to close files which have finished playing in Windows.

In Windows -

every time there is a call to play a sound, a garbage collection function looks through a list of previous sounds that have not been closed.

  Checks to see if previously played files are still playing, if not they are closed.  Runs every time a sound is played.

Hi Taylor,
1 - I was trying to fix closing the sounds after they are opened.  I
thought this was needed to deallocate memory.
2 - I didn't test this, but I think so.  I have played multiple sounds
immediately one after another without issues, so I assumed
that issuing commands to close a sound in succession would be safe.
3 - I just used a list because I see them used more commonly.  There is
certainly more than one approach.  I tend to think of it
in terms of a list because they do actually start in a sequential order.
Thank you for suggesting this.  I am going to study and learn
about this more.
4 - I see you are right, going backwards is not necessary, thank you for
pointing that out.
5 - I should not have done that.  That should be undone.
6 - I agree
I will delete the pull request.
I kind of assumed issuing close statements are supposed to happen since the
winmm.dll
documentation says to close them, the memory is allocated using c, so I
assumed that manual garbage collection is needed.
Overall, do you want me to work on making the sounds close?
If you think it is needed, I think the idea of keeping track of sounds,
checking to see if they are finished,
and closing them if they are finished should be straight-forward (maybe I
am naive about this).
If you think this is not needed or don't want me to work on it please let
me know and I will stop working on it.
Best regards and thank you for the time and effort you have put into this
module.
Gary
On Thu, Aug 5, 2021 at 10:48 PM TaylorSMarks @.***>
wrote:

@.**** requested changes on this pull request.
I have a lot of concerns with this PR.
1 - Is it actually fixing anything? There's no changes to the unit tests.
2 - Is it thread safe? It seems like multiple threads could be running the
collectGarbage function at the same time.
3 - The list traversal is non-pythonic... if you really need the index,
use the enumerate function, but I don't think it's really needed...
wouldn't using a set instead of a list work fine/better?
4 - The reverse list traversal is even weirder and less-pythonic - there
are proper ways to go over it backwards, but a set would remove concerns
about that... also, I don't think those concerns apply here since you're
not modifying removalList while traversing it (you're modifying
garbageCollection).
5 - Why are all exceptions being silently swallowed?
6 - try: pass except: makes absolutely no sense - the try does nothing and
can never throw an exception, so the except block will never fire. The
entire thing may as well not exist and should be removed.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/TaylorSMarks/playsound/pull/80#pullrequestreview-723938992,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ARTSKF34CBTDC6VK2FKQFPDT3NEQTANCNFSM5BKIWQTA
.
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&utm_campaign=notification-email
.

If you’re going to work on this then I’d like proof that something is wrong. Add a unit test that fails with the code currently on master which you can fix.
I’d think running some background thread that closes the sound after it’s done playing would be better than managing a collection of garbage that needs to be closed and checking it everytime playsound is used.
Thanks,
Taylor

On Aug 7, 2021, at 20:27, garydavenport73 @.***> wrote:

Closed #80.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.


[Improvement]: Unify service doc comments and crate docs with README files

Describe the improvement
Our service crates' documentations were recently updated so that the crate documentation
//! Shuttle service integration for the Axum web framework.
//!
//! ## Example
//!
//! ```rust,no_run
//! use axum::{routing::get, Router};
//!
//! async fn hello_world() -> &'static str {
//!     "Hello, world!"
//! }
//!
//! #[shuttle_runtime::main]
//! async fn axum() -> shuttle_axum::ShuttleAxum {
//!     let router = Router::new().route("/", get(hello_world));
//!
//!     Ok(router.into())
//! }
//! ```

is very similar to the return type's documentation
/// Return type from the `[shuttle_runtime::main]` macro for a Axum-based service.
///
/// ## Example
///
/// ```rust,no_run
/// use axum::{routing::get, Router};
///
/// async fn hello_world() -> &'static str {
///     "Hello, world!"
/// }
///
/// #[shuttle_runtime::main]
/// async fn axum() -> shuttle_axum::ShuttleAxum {
///     let router = Router::new().route("/", get(hello_world));
///
///     Ok(router.into())
/// }
/// ```

It would be better to only have one unified version of this doc in the crate's README.md file, and use #![doc = include_str!("../README.md")] and #[doc = include_str!("../README.md")] on the crate and the return type respectively.
This can be done for every service in the services/ dir.

Bonus task: Update the Cargo package descriptions if needed

Feel free to comment on this issue if you want to work on it!

Can i do this ?

Go for it! @AvaterClasher


Implement new docs header and footer

Replace header and footer templates in userGuideHtml.xsl with
a header that matches other gradle.org sites and a new footer
with navigation to docs and other Gradle sites.
Issue: gradle/dotorg-docs#89
Context
Alright so check this out. This implements a new header and footer in gradle/gradle to replace what we have on docs.gradle.org, but just for the user guide.
Header

Footer

The docs publication process will still inject a header for the release notes, DSL reference, and Javadocs, but this one will not be overridden and will provide a bunch of performance benefits for users visiting the docs on the web.
Hey, I even made it look not terrible on phones:
Header

Footer

In separate pull requests to come soon:

Maximize web performance
Implement primary and secondary docs navigation

Gradle Core Team Checklist

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation
[ ] Recognize contributor in release notes

@aweida @eriwen Great work on the redesign!
Something we should fix: the newsletter sign-up looks different on different browsers.
Chrome on Linux:

Firefox on Linux:


research: Analyse Priority of Widgets from existing Müsli

Count how often each Widget is used in the different pages of Müsli. Create a Matrix containing the information and group the Widgets according to their priority

Result (in order of importance)

Basic elements 66%

text, button, links, textinput, checkbox, switch
needed everywhere
straightforward: design and implementation should be easy

Database related elements 32%

dynamic vals, derived vals, list selection, tables
difficult design
difficult implementation (partly done by previous project)

Nice to have 2%

tooltips, rich text, file picker
nice to have = not important

More detailed result available in:

our presentations
goole table (ask me for access)


OTA update to <IP_ADDRESS> leads to reboot

When OTA update is finished (after version --dup), on pressing power button:

the screen will show login screen for few moments
screen will go blank, but will be lid
device will reboot, triggered by mce

Sometimes, device may have to be switched off by long press until red led will show up. Release power button and let device to power off.
As usual for OTA, first reboot will update boot image and trigger a new one. After that device should boot into GUI.
As I have not seen any side-effects on it, there is no plan to investigate and fix it.
The log below corresponds to the case where device rebooted:
Mar 11 19:34:16 Sailfish mce[3019]: powerkey.c: pwrkey_datapipe_keypress_event_cb(): powerkey pressed
Mar 11 19:34:16 Sailfish systemd-logind[3239]: Power key pressed.
Mar 11 19:34:16 Sailfish systemd-logind[3239]: Powering Off...
Mar 11 19:34:16 Sailfish systemd-logind[3239]: System is powering down.
Mar 11 19:34:16 Sailfish systemd[1]: Stopped target Bluetooth.
Mar 11 19:34:16 Sailfish systemd[1]: Stopping Pacrunner service...
Mar 11 19:34:16 Sailfish systemd[1]: Stopping Authorization Manager...
Mar 11 19:34:16 Sailfish pacrunner[9367]: Terminating
Mar 11 19:34:16 Sailfish systemd[1]: Stopping Autologin user 100000...
Mar 11 19:34:16 Sailfish pacrunner[9367]: Exit
Mar 11 19:34:16 Sailfish systemd[1]: Removed slice system-sdmount.slice.
Mar 11 19:34:16 Sailfish systemd[1]: Stopped target Timers.
Mar 11 19:34:16 Sailfish systemd[1]: Stopped Daily Cleanup of Temporary Directories.
Mar 11 19:34:16 Sailfish pacrunner[9367]: Source ID 5 was not found when attempting to remove it
Mar 11 19:34:16 Sailfish pacrunner[9367]: pacrunner[9367]: Terminating
Mar 11 19:34:16 Sailfish pacrunner[9367]: pacrunner[9367]: Exit
Mar 11 19:34:16 Sailfish systemd[4046]: pam_console(autologin:session): Could not open lock file /var/run/console/nemo, disallowing console access
Mar 11 19:34:16 Sailfish dbus-daemon[3169]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.481" (uid=100000 pid=4046 comm="(sd-pam)                                      " label="kernel") interface="org.freedesktop.login1.Manager" member="ReleaseSession" error name="(unset)" requested_reply="0" destination="org.freedesktop.login1" (uid=0 pid=3239 comm="/usr/lib/systemd/systemd-logind" label="kernel")
Mar 11 19:34:16 Sailfish dbus-daemon[3169]: dbus-daemon[3169]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.481" (uid=100000 pid=4046 comm="(sd-pam)                                      " label="kernel") interface="org.freedesktop.login1.Manager" member="ReleaseSession" error name="(unset)" requested_reply="0" destination="org.freedesktop.login1" (uid=0 pid=3239 comm="/usr/lib/systemd/systemd-logind" label="kernel")

Closing as there are no plans to investigate it.


Why does lastPushTimeStamp update on env checkout?

Which Category is your question related to?
env
Amplify CLI Version
4.13.4
What AWS Services are you utilizing?
AppSync, Console
Provide additional details e.g. code snippets
I've set up master and dev branches in Console, with environments master and dev respectively.
When I develop locally, I follow the pattern in the documentation. I will git checkout master then amplify init and point it to the master env. I'll then switch back to git checkout dev and then amplify init with dev as an env. Whenever I do that, the CLI modifies the amplify-meta.json file with an updated timestamp on the lastPushTimeStamp property.
This is annoying when switching between environments with no changes. It forces me to either commit the changes to amplify-meta.json or git reset --hard to ignore the automatic change.
Is this field update absolutely necessary? What are the implications of ignoring that change? Why doesn't it update only on amplify push?

@chrisco255 The amplify-meta.json file is part of the .gitignore file it should not be checked into source control, so the update of it would not be a problem. I tried the use case you were specifying and because it is ignored I had no problems switching between branches and such.
Is there a particular reason why you don't have it in your .gitignore file?

It's not in my .gitignore file. I can definitely add it, I'm not sure why the CLI setup didn't augment my file with that.

If you initialize the project with amplify init for the first time, the CLI creates a .gitignore file with these entries:
#amplify
amplify/\#current-cloud-backend
amplify/.config/local-*
amplify/mock-data
amplify/backend/amplify-meta.json
amplify/backend/awscloudformation
build/
dist/
node_modules/
aws-exports.js
awsconfiguration.json
amplifyconfiguration.json
amplify-gradle-config.json
amplifyxc.config

If you create your app through amplify-app then this step is not done, because it can be inside existing project and such.
Add these entries to your .gitignore and remove from the above files from source control and you will not see the issue.