Delegate data directory location in the sandbox to the controller

Because this library should not assume that /var/lib/docker is
always the root path.
Signed-off-by: David Calavera<EMAIL_ADDRESS>

@mrjana I totally agree with you. I redid the patch to use the controller's data directory and remove that default prefix.

Looks like this may resolve https://github.com/docker/libnetwork/issues/747 ?

@calavera thanks for the fix. Could you also please take care of the hard-coding in sandbox_externalkey_unix.go ?

will do

ping @calavera looks like you didn't fix sandbox_externalkey_unix.go yet :smile:

@thaJeztah I did, but changing that requires more work than I expected, and I'm slightly busy with the api right now :smiley_cat:

@calavera yup, I can imagine. I just landed here through https://github.com/docker/docker/issues/18508, and noticed it wasn't merged/updated yet :+1:

@mavenugo @thaJeztah I'm not sure we can remove that hardcoded path. It's used to store the sockets for reexecution. If we remove it, we'd need to send the full path to the socket as the third argument to set the network key. I really have no idea where we run that reexecution.

@calavera I will take a look at this as well. Since you have already completed the work on other hard-coded paths, I think we can get this one in. I will handle the sandbox_externalkey_unix.go.

@thaJeztah @calavera I dont think this is critical for 1.10 release. Given the intrusive changes and potentially causing migration issues (if we start using another location to look for local states), I would keep this PR out of 1.10 release.

@mavenugo wondering if this can cause corruption of the local-kv.db if somebody either switches graph-directory, or has two daemons on the same host, but different graph-dir?

@thaJeztah How do you mean when you say "if somebody either switches graph-directory"? If somebody switches graph-directory across docker restarts we are talking about different local-kv.db instances. If two docker hosts run in different graph-dir again this is a supported configuration and we full support it. In fact we create local-kv.db in exactly the graph dir option used in daemon option.
Actually there is no hard coding at all. The only thing that is hard coded is the location of the unix domain socket that libnetwork listens to for pre/post start hooks. But that unix domain socket is named using random controller id which cannot collide.
So while this is a good PR to merge in the master, the only thing that is hard coded is the unix domain socket path. Hence I don't think this is a candidate for 1.10 since the change is more pervasive and reward is less than the risk.

@mrjana its my mistake that I incorrectly pointed about migration, while that is not an issue in this case.
@thaJeztah I agree with @mrjana we took care of the local-kv.db stored in the correct root folder (pointed by -g) in 1.9 release.

@mrjana apologies, I think I misinterpreted this part https://github.com/docker/libnetwork/blob/317d527fd6628f51662e1c1c1c0ac9f1b911d6c5/datastore/datastore.go#L118-L137 also initializing the database in that location

@thaJeztah Yeah that's the default default. But a non-empty data directory argument from engine will always override it as can be seen here:
https://github.com/docker/libnetwork/blob/317d527fd6628f51662e1c1c1c0ac9f1b911d6c5/datastore/datastore.go#L159

@mavenugo how hard would it be to change the third parameter in the reexec function to take the whole path to the socket? that seems like the easiest solution, but I still don't know the implications of changing one of those arguments?

@calavera I think that is a reasonable and safe change. To give you a history of this change, it is supposed to be called from the hook callback from runc (when it runs as an external process). It is currently embedded as the libcontainer library in docker and hence the reexec path is not exercised by Docker. But when it does, it can just call the re-exec with the said parameters so that libnetwork can continue doing its sandbox configuration phase. Since runc library is in the same process context as the docker engine, we call the SetKey directly from docker and hence bypassing the entire reexec path.
Libnetwork is designed to independent of how docker engine makes use of runc.
With that history, I think it is safe to do that change and I would have done the same if I handled it.
@calavera @thaJeztah do you think this is a mandatory PR for 1.10 ?
We can absolutely review and merge it (after fixing the sandbox_externalkey) in master. We have to determine the importance of it for the 1.10 branch.

okay, that makes more sense. I'm going to make the smallest changes I can to support the path as the third argument.
I think we should try to have this in 1.10. Give me a few minutes to put the patch together.

@mavenugo I'm just here to give my vote for fixing this for 1.10, especially if it's doable without much risk.

I don't agree that this should be part of 1.10. If it was merged before code freeze may be but not now.

@mrjana this is a bug, not a docker api change.

@tiborvass This is code cleanup with no user visible bug.

@mrjana it is an user visible bug : https://github.com/docker/libnetwork/issues/747

I don't attribute #747 as a user visible bug as we don't even document anywhere where we are going to place that UDS sock. But all of this is just one man's opinion.

@mrjana docker/docker#18508

@mrjana it is not just the UDS sock. IT is also resolvConfPath and hostsPath

@mavenugo It's not. It's just UDS sock. We always get resolvConfPath and hostsPath from engine

why do we even start the reexec process if we're not currently using it? can we disable that?

@calavera we did that because libnetwork was originally designed to be used independent of the decision to integrate with runc as an external process. If there are no such plans, I think it is safe to even turn off the functionality for now.

ping @calavera. Can we get this blessed by CI?

What happened to this PR @calavera and @mavenugo?
It would be good to have merged as it's causing issues for Kubernetes deployments with two daemons.

@luxas this issue shouldnt cause any issue with 2 daemons with 2 different -g locations. The only issue here is the fact that, the sock is stored in the static location. but that shouldn't cause any specific daemon issue.

it's causing issues for Kubernetes deployments with two daemons.

Can you please explain the issue ?

@mavenugo Please see: https://github.com/docker/docker/issues/21156


DeprecationWarning: Listening to events on the Db class has been deprecated and will be removed in the next major version

I got some deprecation warning
OS : macOS 11.2 Big Sur
Monk : Latest 7.3.3
Mongodb : Latest 3.6.4
(node:58674) DeprecationWarning: Listening to events on the Db class has been deprecated and will be removed in the next major version.
    at /Users/forte/Workspace/freejs/node_modules/monk/lib/manager.js:150:18
    at Array.forEach (<anonymous>)
    at Manager.<anonymous> (/Users/forte/Workspace/freejs/node_modules/monk/lib/manager.js:149:95)
    at /Users/forte/Workspace/freejs/node_modules/mongodb/lib/utils.js:693:5
    at /Users/forte/Workspace/freejs/node_modules/mongodb/lib/mongo_client.js:227:7
    at connectCallback (/Users/forte/Workspace/freejs/node_modules/mongodb/lib/operations/connect.js:366:5)
    at /Users/forte/Workspace/freejs/node_modules/mongodb/lib/operations/connect.js:602:5
    at Object.connectHandler [as callback] (/Users/forte/Workspace/freejs/node_modules/mongodb/lib/core/sdam/topology.js:297:43)
    at processWaitQueue (/Users/forte/Workspace/freejs/node_modules/mongodb/lib/core/sdam/topology.js:1048:21)
    at NativeTopology.serverUpdateHandler (/Users/forte/Workspace/freejs/node_modules/mongodb/lib/core/sdam/topology.js:567:7)
    at Server.emit (events.js:315:20)
    at Server.EventEmitter.emit (domain.js:467:12)
    at Monitor.<anonymous> (/Users/forte/Workspace/freejs/node_modules/mongodb/lib/core/sdam/server.js:151:12)
    at Monitor.emit (events.js:327:22)
    at Monitor.EventEmitter.emit (domain.js:467:12)
    at /Users/forte/Workspace/freejs/node_modules/mongodb/lib/core/sdam/monitor.js:272:13

Prompted to come here for this same issue.

https://stackoverflow.com/questions/66190532/deprecationwarning-listening-to-events-on-the-db-class-has-been-deprecated-and
TEMP Fix.
you must remove current mongoose version (I was on 5.11.13), and downgrade to<EMAIL_ADDRESS>to resolve it.

This is fixed with mongodb version 3.6.5.
npm i<EMAIL_ADDRESS>
This can also be fixed with ```npm i<EMAIL_ADDRESS>as that version is before the bug occured.

Given that this isn't an issue with monk and is resolved downstream, this is probably safe to close?

I have tried to install<EMAIL_ADDRESS>and 3.6.6 but the deprecation warning still be exist..
And originally why I open the issue, I think this deprecation may cause problem in the next release if monk library is not patched / fixed

And I have found monk library also have own mongodb version. So which mongodb version that we install to our project, monk will use its own mongodb version

This is not how NPM works.
Monk specifies "mongodb": "^3.2.3",, which means any version of mongodb greater than or equal to 3.2.3, but NOT 4.x.x.
This means that if you explicitly install a version of mongodb in your project, monk will use that version of mongodb, provided that the version you install is after 3.2.3.

@zkldi
Please check it out this simple repo https://github.com/fortezhuo/monk_dummy
The repo only contains mongodb 3.6.3 and monk 7.3.3
{
  "name": "monk_dummy",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "dependencies": {
    "mongodb": "3.6.3",
    "monk": "^7.3.3"
  }
}

I used to use yarn and found monk still use<EMAIL_ADDRESS>I think the problem may be caused by yarn.

Strange, this has started breaking for me again. Nothing has changed with the versions installed, either.

Well, hm. Here's an uninteresting fix. If you:

install monk npm install monk
install<EMAIL_ADDRESS>@3.6.5, or later deliberately npm install mongodb
uninstall monk npm uninstall monk
install monk npm install monk

The errors do not appear. I have absolutely no idea how this fixes the problem, but uh, it does. Maybe NPM is doing some wacky cacheing.

I solved this problem with silly solution, I had cloned monk library, downgrade mongodb  to 3.6.3, and allow lib to be hosted on github. So I use the cloned monk on my project
"monk": "fortezhuo/monk",

I have exactly the same problem. Is there already a solution?

Why isn't Monk just using the new paradigm?
https://www.mongodb.com/community/forums/t/node-44612-deprecationwarning-listening-to-events-on-the-db-class-has-been-deprecated-and-will-be-removed-in-the-next-major-version/15849/4

It's a shame that we have not received any reply from the developers of this framework, stating how to resolve this issue or at least letting us know they are working on it.

Someone, please tell me how to disable these errors, I don't care if they're just ignored or if the code is fixed, I JUST DONT WANT TO SEE THEM. Thanks.

npm install monk

This worked for me. i almost collapsed fixing this bug


Update package manager index before installing ccache

This is to avoid the index being outdated and failing ccache installation.
Relevant issues:
https://github.com/actions/virtual-environments/issues/1757#issuecomment-765238242
https://github.com/actions/virtual-environments/issues/2924
From https://docs.github.com/en/actions/using-github-hosted-runners/customizing-github-hosted-runners:

Note: Always run sudo apt-get update before installing a package. In case the apt index is stale, this
command fetches and re-indexes any available packages, which helps prevent package installation failures.

OK, I just found https://github.com/hendrikmuhs/ccache-action/pull/1
IMO the point is someone has to update the package manager index anyway, either the user's workflow or this action.
Another way to handle this is to add a specific note about requiring the package manager is updated before using this action, however I think it is quite unnatural that an action which will install a package won't ensure the package manager index is up to date before installation...

Not running apt-get update or any counterpart (e.g. brew update) is by design. It is highly likely that it has been run before, because C++ projects highly likely have other dependencies that need to be installed. Apart from that it is highly unlikely that an error happens due to a file removal in the upstream repository, ccache is rarely updated.
I agree that documenting this behavior would be nice. You could as well catch the potential error and print a meaningful message like: "did you run apt-get update / brew update before?"
If you desperately need this behavior I am ok with adding a parameter update-package-index to the action that if true runs the update. However the default false must be kept as this is the current behavior and many users rely on this and I don't want to change their workflow.

It is highly likely that it has been run before, because C++ projects highly likely have other dependencies that need to be installed.

Right, but a part of the README is misleading about it:

NB! This should always come after the actions/checkout step.

This implies the user should run this action right after checkout and before installing the dependencies.
I'll leave the revising work for someone else...

However the default false must be kept as this is the current behavior and many users rely on this and I don't want to change their workflow.

I'm not particularly interested of adding an new option. You can also consider releasing version 2 of this action which will be a breaking change from v1.

Apart from that it is highly unlikely that an error happens due to a file removal in the upstream repository, ccache is rarely updated.

Maybe on ubuntu. On homebrew it is updated yesterday: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/ccache.rb

It is highly likely that it has been run before, because C++ projects highly likely have other dependencies that need to be installed.

Right, but a part of the README is misleading about it:

NB! This should always come after the actions/checkout step.

This implies the user should run this action right after checkout and before installing the dependencies.

I don't read this, it only says it should it should be added after:
      - name: checkout from git
        uses: actions/checkout@v2

That's all, however I am currently not remembering the reason. I happily improve the docs, however I don't get the problem. It doesn't say anything else. The user feedback has been that most users run apt or brew update anyway, before this action. That's why an additional update unnecessarily increases build time. I haven't got any complains about it, I think it is the opposite: the existing user base will not appreciate this change.
That's why I am not accepting this change if it changes the current default behavior.

I'm not particularly interested of adding an new option. You can also consider releasing version 2 of this action which will be a breaking change from v1 (accumulate with other breaking changes).

For this change, I see no reason to change the default. I see quite some user base in public repositories and I imagine more in private repositories. I don't want to break existing workflows without a strong reason. The idea of a feature branch is a good one, however I wouldn't call it version 2 as long as it's experimental.

That's why an additional update unnecessarily increases build time.

Like how much? < 30 secs at most is considered too much?
Anyway, thank you for your time.


Improve documentation

Coverage remained the same at 100.0% when pulling af0df3bcaa45e6d0d3ede2901429050c61fdbdff on 8-ImproveDoc into e301b4ddd28aaa7ad7cf09fb65d8b7686bc562a5 on ReleaseCandidate.


Fixes issue #7 Setting value just after building a gauge with Dashboa…

…rdSkin locks the application

Fixed adjustTextSize method condition and avoid infinite loop

Problem is that the condition in the loop does not do what is expected. Also the loop enters in an infinite loop when MAX_WIDTH and fontSize are zero, something that happens in the OverviewDemo because the gauge has not been rendered for the first time and all initial sizes are zero.

Commit message is wrong. It fixes issue #8 not issue #7 :-(

Fixed with other things


Fix incorrect rotation of internal magnetometers

Fixes https://github.com/PX4/Firmware/issues/7325

This not the correct fix. It breaks my race-condition fix. I will have look soon and properly fix it, now that we know where it goes wrong.

@mhkabir Did you have a chance to look at this yet?

Yes I did and I know how to fix it, but i won't get a chance to send the correct PR till tomorrow morning.

Can you provide a few pointers? Given the large number of potentially affected users and the already existing v1.6 tag this is super high priority to fix, so I'd like to take a stab at this today. I think I know what to look for, but I don't want to ignore the work you have already done.

@LorenzMeier @priseborough OK, fixed properly here. Please test since I don't have hardware : https://github.com/PX4/Firmware/pull/7337


fix: change engine to<EMAIL_ADDRESS>

Removes experimentalDecorators and tslib dependency.

Codecov Report

Merging #24 (6fe0a34) into main (fb297cf) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main       #24   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            6         6
  Lines           59        59
  Branches        12        12
=========================================
  Hits            59        59

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 fb297cf...6fe0a34. Read the comment docs.


change types String to FilePath

Changed defineByDocumentFile, defineByIntrospectionFile,
importGQLDocument, importGQLDocumentWithNamespace, to take the type
synonym FilePath instead of String.
r/t https://github.com/morpheusgraphql/morpheus-graphql/issues/518

approved


🐛 [firebase_analytics] The firebase_analytics is not working on android, works fine on ios

Bug report
I used the dart-only initialization, with flutterfire cli, and everything works fine, firebase_messaging works on ios and android, and the firebase_analytics works on ios, but not on android

Hi @LuisOtavioOliveira, when you say it doesn't work on android, can you please provide full details as to how it does not work?
Please also provide the version of the flutterfire plugins you're using along with the output of flutter doctor -v and a complete minimal reproducible code sample in a repo that we can clone so that we can investigate this.
Thank you

I'm using these versions of firebase plugins:
firebase_analytics: ^10.4.3
firebase_core: ^2.15.1
flutter doctor shows no issues, and firebase_messaging and cloud_firestore are both working, firebase_analytics works on ios, but when i open the app on android, nothing happens in the real time analytics, i've already re-installed the firebase_core and changed version, but just doesn't work, i´ve already tried the manual installation too but no sucess.

Hi @LuisOtavioOliveira, do you have this same issue when you use the code sample from the firebase_anayltics example?
It would help if you could provide a minimal sample in a repo that we can clone so that we can investigate this.
Thank you

I solved the problem using the manual installation, and adding the permissions to AndroidManifest.xml.
in AndroidManifest.xml:

in android/build.gradle:
classpath 'com.google.gms:google-services:4.3.15'
in android/app/build.gradle:
apply plugin: 'com.google.gms.google-services'
in main.dart:
Platform.isAndroid
? await Firebase.initializeApp()
: await Firebase.initializeApp(
options: DefaultFirebaseOptions.currentPlatform);


After login, app shows 404 brefily and then redirects

This should not happen. Please let's fix this ASAP.

This is not happening any more.


VM: Implement XSWAP, XTUCK, DEPTH, DROP opcode

Closes #274.

Codecov Report

Merging #275 into vm will decrease coverage by 0.71%.
The diff coverage is 41.3%.

@@            Coverage Diff             @@
##               vm     #275      +/-   ##
==========================================
- Coverage   52.69%   51.97%   -0.72%
==========================================
  Files          76       76
  Lines        2769     2815      +46
==========================================
+ Hits         1459     1463       +4
- Misses       1160     1194      +34
- Partials      150      158       +8

Impacted Files
Coverage Δ

pkg/vm/vm_ops.go
100% <ø> (ø)
:arrow_up:

pkg/vm/stack/stack.go
44.59% <0%> (-4.66%)
:arrow_down:

pkg/vm/vm_ops_stackmani.go
52.17% <48.71%> (-19.26%)
:arrow_down:

pkg/peer/peer.go
26.76% <0%> (-7.58%)
:arrow_down:

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 045db09...aa67e98. Read the comment docs.


Changelog documentation indentation issue

Rasa Open Source version
NA
Rasa SDK version
NA
Rasa X version
NA
Python version
Other
What operating system are you using?
Windows
What happened?
The below image shows us, that inside changelog docs for 3.0 there is issue with indentation and needs a line break to see the changes written there.

Command / Request
I would like to fix this issue by opening a PR if nobody is working on this.

Relevant log output
No response

Thanks for raising this issue, @joejuzl will get back to you about it soon✨
Please also check out the docs and the forum in case your issue was raised there too 🤗


Make big plus symbol on empty WI list clickable

I would love to see that this big plus symbol that is JUMPING IN MY FACE is clickable. But currently it isn't.

@Mgranfie this would increase the usability, no?

@kwk can you see if it is just as bad when Epics are empty? We are using the same empty state message for that as well. I don't notice those things, since I did them :)

@kwk can you see if it is just as bad when Epics are empty?

I don't get what you're saying.

This is good feedback Konrad... will look into this!
On Wed, Mar 22, 2017 at 10:18 AM, Konrad Kleine<EMAIL_ADDRESS>wrote:

I would love to see that this big plus symbol that is JUMPING IN MY FACE
is clickable. But currently it isn't.
[image: screenshot from 2017-03-22 14-17-04]
https://cloud.githubusercontent.com/assets/193408/24202158/9392050c-0f12-11e7-8ff8-6d37422343c2.png
@Mgranfie https://github.com/Mgranfie this would increase the
usability, no?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/fabric8io/fabric8-planner/issues/1246, or mute the
thread
https://github.com/notifications/unsubscribe-auth/ARTwq4_QIZo1EThEVDUHRYI-irtfaD-Zks5roS2egaJpZM4MlRHA
.

@kwk ignore my comment - doesn't apply 😄

+1 on this one - its the biggest target on the screen but it doesn't do anything. +1 on making it actually "Add" or remove it.

Fixed with #1685


fv_atm(1)%ks is never initialized

This is a question for @wmputman on what to do.
Namely, I recently tried running GEOS with GNU as the compiler and Intel MPI as the MPI stack. When I did so, the runs threw this:
pe=00072 FAIL at line=00636    FV_StateMod.F90                          <ks must be smaller than NPZ+1>

on many processes. Looking at the code, this is here:
https://github.com/GEOS-ESM/FVdycoreCubed_GridComp/blob/de5698065e397239908393ed2f3bea2f54aaa9e4/FV_StateMod.F90#L632-L636
So, I put in some prints to get out ks and npz+1 and:
 ks:            0
 FV_Atm(1)%flagstruct%NPZ+1:           73
 ks:            1
 FV_Atm(1)%flagstruct%NPZ+1:           73
 ks:   -495940352
 FV_Atm(1)%flagstruct%NPZ+1:           73
 ks:     57212160
 FV_Atm(1)%flagstruct%NPZ+1:           73
 ks:    189469340
 FV_Atm(1)%flagstruct%NPZ+1:           73

This is an obvious uninitialized variable signature.
From what myself and @bena-nasa see, ks could be provided by m_set_eta in Hermes, but it looks like it isn't. If it was, ks would be 40 (for a 72-level run).
The main question for @wmputman is: Is this something that should be fixed? I tried looking at FV and it looks like ks is only really used by "Rayleigh friction" sort of codes? I don't know.
If ks is a dead variable, we should just initialize it to 0 and be done with it. But if there are cases we might use it, we should initialize it to the right value our ak/bk would supply. As @atrayano says in the comment:
FV_Atm(1)%ks = count(BK == 0.0) - 1

should would seem to work. (From my reading of m_set_eta, ks is actually 1 less than the number of zeros in bk.
Finally, the reason I missed this for a bit was because we do not trap the RC code from fv_setup:
https://github.com/GEOS-ESM/FVdycoreCubed_GridComp/blob/de5698065e397239908393ed2f3bea2f54aaa9e4/DynCore_GridCompMod.F90#L2299
That line should be:
    call DynSetup(GC, LAYOUT_FILE, _RC)

or similar to verify the RC code.

The fix from Atanas is safe to take

@wmputman Okay. I'll work on getting a PR together and testing, etc. Should be pretty simple. I'll ping you when I have it for your approval.


Fast travel location fixes + Removing POIS detected in housing

Rebuild of thesead moved the fast travel locations + Rodoroc Trading Tunnel location got moved slightly. Adjusted the POIS to match.
Also reordered fast travel location list from lowest x value to highest x value like all other location lists
I know that this is probably not the place to edit this it cause apparently this doesnt affect legacy, but if i get pointed to the right spot, i will edit that to match as well.
EDIT: I edited this file because this is also the one i used to remove duplicate waypoints in thesead, nessak, and kandon-beda when they were rebuilt during 2.0
Fast Travel Changes:
Thesead to Eltom
Old:
{
"x": 833,
"y": 113,
"z": -4990
},
New:
{
"x": 859,
"y": 112,
"z": -5038
},
Rodoroc
Old:
{
"x": 991,
"y": 8,
"z": -5070
},
New:
{
"x": 1015,
"y": 12,
"z": -5096
},
POIS were rendered on housing islands, removing:
Potion Merchant:
{
"x": 65543,
"y": 102,
"z": 65927
},
{
"x": 65547,
"y": 102,
"z": 65519
}
Item Identifier:
{
"x": 65543,
"y": 102,
"z": 65924
}
Powder Master:
{
"x": 65543,
"y": 102,
"z": 65930
}
Emerald Merchant:
{
"x": 65543,
"y": 102,
"z": 65924
}
Trade Market:
{
"x": 65535,
"y": 104,
"z": 65927
},
{
"x": 65544,
"y": 105,
"z": 65519
}
Blacksmith:
{
"x": 65544,
"y": 105,
"z":
}

The purpose of this repo is to provide a stable data with clear sources and a recipe for reproducing the data.
How did you gather this data?

I gathered the fast travel changes by hand cause i dont remember telemetry picking them up.

It is not so much a requirement of proof that I want, as a way to automate (if possible). Hand-made changes is hard to update, hard to detect the need for update, can have errors (as seen by one of the fixes pushed here just the other day), and can include subjective interpretation.

I am not sure how to automate fast travel locations and at a quick search i cant find them in the wynn api either. do you know how they were initially collected? i can try to collect them that way

yeah ok I ran a script that produces a list from the api. and I ended up finding the thesead and rodoroc fast travels in there, both of the wrong coordinates

Ok, I got confused by the changes to housing island services; I did not read your PR description properly. My bad, apologies. :-(
I agree that Fast Travel is not possible to get coordinates for other than manually producing them like this. But it also means that there is a bit of subjectivity involved. Whenever you get teleported by Wynncraft, it is a potential "fast travel". Determining which points to include and what coordinate to give them, needs a judgement call.
I think we need a structure for our data sources that allows us to include such manually gathered and curated data, but still clearly separates it from what can be achieved automatically. My intention was that this separation should be between the Data-Storage and the Reference repo, but it has not worked out. :-( So I'll accept this for now since it is useful to current users of Wynntils. But the entire data processing chain needs a better design.


Fix GFM table issue

The pipe in the sample Regex was breaking the Makrdown table on the Webpack docs page.
Solution is based on this -- https://github.com/gitlabhq/gitlabhq/issues/1238

Nice one. Thanks! 👍


testing

Signed-off-by: Doug Davis<EMAIL_ADDRESS>

LGTM

LGTM

LGTM

NOT LGTM

LGTM

NOT LGTM

LGTM

LGTM

merging just to remove testing stuff from README


SamlSecurityTokenHandler has hardcoded strings in exception messages.

See: CreateAttribute, CreateAuthenticationStatement, CreateSubject, SetDelegateFromAttribute, ReadToken
Add meaningful log messages to LogMessages.cs

#760


WsiDicomizer stores DICOM with NumberOfSamples = 3, but should be 4 when converting from OpenSlide

Took me a while to figure this out, but when converting from OpenSlide and encoding to JPEG2000, the DICOM Tag SamplesPerPixel is set to 3, however, OpenSlide is returning ARGB and this is also stored in the JPEG2000-encoded. This makes it challenging to allocate the correct buffers in third-party applications. There are two solutions, which is why I didn't fix it myself:

Strip the alpha part from the returned openslide tile
Store the SamplesPerPixel as 4

As I don't know very well if DICOM handles an alpha channel very well, I thought stripping it might be better?

Thanks for the bug report. Yes the openslide data comes as ARGB. The jpeg-encoder can handle (ignore) the extra channel by setting the input color space. I have to test if the jpeg2000 does the same (there is a colorspace flag). Otherwise we must strip it before sending it to the encoder. It is not allowed to have anything else than 1 or 3 SamplesPerPixel.


openssl s_client shows "Server did acknowledge servername extension" even if server didn't

When I send a server name which server does not recognize (in OpenSSL programming, SSL_TLSEXT_ERR_NOACK is returned from callback set by SSL_CTX_set_tlsext_servername_callback in server side) using openssl s_client, it still shows "Server did acknowledge servername extension."

It seems that ssl_servername_cb gets called even if server_name extension is not present in SH.
SSL_get_servername() just echos back the hostname s_client set, so unless it is resumed session, it always thinks that server recognized sni.
I think that the possible fix is that checking |sent| parameter in final_server_name, and if it is zero, don't call callback.

The code that displays that message shouldn't be there at all. This is what it looks like in 1.0.2:
#if 0                           /* This test doesn't really work as intended
                                 * (needs to be fixed) */
# ifndef OPENSSL_NO_TLSEXT
                if (servername != NULL && !SSL_session_reused(con)) {
                    BIO_printf(bio_c_out,
                               "Server did %sacknowledge servername extension.\n",
                               tlsextcbp.ack ? "" : "not ");
                }
# endif
#endif

Note that comment at the start and the fact that it is "'if 0'd" out.
In the 1.1.0 branch that code got completely deleted in 75d0ebe. It then made a comeback in "the mega commit" 7e1b7485. I think it was a merge error.

So @mattcaswell you want a PR that fixes that merge error?

Yes, I'd like to see a PR that does that (for master and 1.1.0)

This is fixed via f2150cd.


[Feature] Ability to add documentation inside of sol! macro to satisfy missing_docs lint rule

Component
sol! macro
Describe the feature you would like
When using the following common lint rule:
[lints]
rust.missing_docs = "warn"

It will warn users that this sol! block is missing documentation with the error: missing documentation for a struct field requested on the command line with "-W missing-docs"
sol! {
    #[sol(rpc, bytecode="6080...0033")]
    contract Counter {
        uint256 public number;

        function setNumber(uint256 newNumber) public {
            number = newNumber;
        }

        function increment() public {
            number++;
        }
    }
}

It is however currently not possible to add documentation inside of the sol! macro and therefore it requires adding a #[allow(missing_docs)] for now.
Additional context
Added a minimal repro here: https://github.com/zerosnacks/alloy-core-repro-588
Unclear if this should be marked as a feature request or a bug

Came here to open this exact issue!
Fwiw, this invocation gives the same warning:
sol! {
    /// Emitted when `value` tokens are moved from one account (`from`) to
    /// another (`to`).
    ///
    /// Note that `value` may be zero.
    event Transfer(address indexed from, address indexed to, uint256 value);
    /// Emitted when the allowance of a `spender` for an `owner` is set by a
    /// call to `approve`. `value` is the new allowance.
    event Approval(address indexed owner, address indexed spender, uint256 value);
}

Is it my understanding that you would prefer something like the following, instead of allowing the lint with #[allow(missing_docs)]?
sol! {
    /// ...
    event Approval(
        /// ...
        address indexed owner,
        /// ...
        address indexed spender,
        /// ...
        uint256 value
    );
}

Is it my understanding that you would prefer something like the following

For me this gives a warning as well.

Yes, it's not implemented, I am asking if that's what you would like

Yeah, I think that works 👍

Is it my understanding that you would prefer something like the following, instead of allowing the lint with #[allow(missing_docs)]

Ah @DaniPopes, so I was revisiting this and reading the code, and I realized that I probably misunderstood your question twice.
I think I'd prefer if we annotated the fields of the generated event struct with #[allow(missing_docs)], which is what you suggested?
I initially thought you meant:
sol! {
    /// ...
    event Approval(
        #[allow(missing_docs)]
        address indexed owner,
        #[allow(missing_docs)]
        address indexed spender,
        #[allow(missing_docs)]
        uint256 value
    );
}

It's a one-line change, so I'll just open a PR.


On the current Live version of RLCraft I can't see my backpack from the WearableBackpacks mod, and I can't see my Toolbelt from the toolbelt mod.

I can't fix it by changing video settings as far as I know. I reset all of my video settings back to default and still can't manage to get the backpack or toolbelt to show up. Also, on some servers I notice some people not being able to see toolbelt items on other players' waists.

I'm sorry I forgot to mention that I can see the items in the world, I just cant see them when I equip them. Also sorry I mentioned the toolbelt mod. I just now realized that this isnt the place to talk about it.
To be clear, when I drop or place the backpack I can see the model, but when I equip it, regardless of whether or not I equip it in my chest armor slot, I dont see it rendered on my character's back.

It doesn't show up on my player model when I'm naked ina new world either. Tested on a single player world with cheats enabled.

No worries, I understood what you meant. I can't really say what mod causes it. Has this started to be an issue with a recent version of the modpack? Perhaps it's a mod that updated or has been added recently. I would additionally report this to the modpack author, as they'll be more familiar with the changes made.

Sorry I can't say whether this is a new issue or not as I've just recently started playing RLCraft. I'll take your advice and contact the modpack creator about the issue to see if it can get fixed. Thanks for you consideration friend.

This is currently not an issue in the latest version of RLCraft 2.7 and 2.7.1.  I see the toolbelt and backpack render on my player character just fine.  I'm not sure what Murculater's issue is.  If he enabled the player animations in Mo'Bends, then the models won't show up, but that is why those animations are disabled by default.  Did you perhaps enable those Mo'Bends animations Murculater or didn't install my configs correctly?  If you didn't install my configs right, it will load default configs which will enable new player animations meant to be disabled.

I downloaded the modpack from the Twitch client and ran it from there. I haven't gotten into any config files and changed anything. I also don't know where the settings for the Mo'Bends mod would be.

Here's some proof of the toolbelt mod not showing up to other players like it's supposed to. Gonna post it here now that Shivaxi is here. If this isn't the place then lmk copygirl. https://clips.twitch.tv/LittleFaithfulNoodlePlanking

Definitely not the right place for the Tool Belt mod issue, but I don't mind that much :p
You should however separately report it to its own issue tracker.
Looking at your clip, it doesn't seem Mo'Bends is enabled for the player so that won't be the issue. However, it is still strange since it did work with it at some point in the past (#82, #98). We didn't change anything about how backpacks render on players since then, I'm pretty sure.

I'm having the same issue with Wearable Backpacks (along with Tool Belt and Open Gliders).... so I would imagine there is some other mod interfering. Other players have no trouble clicking my backpack to open it, and it renders properly when set down. However, none of us can see it on a person (whether used as Chest Armor or not).
Client attempting to join with 299 mods : alcatrazcore@1.0.4,simpleportals@1.12.2-<IP_ADDRESS>,jaff@1.7_for_1.12,metaltransport@v2.6.9+mc1.12.2,consecration@1.0.6,totemessentials@1.1.0,mtrm@<IP_ADDRESS>,jeroreintegration@1.1.0,betternether@<IP_ADDRESS>,contenttweaker@1.12.2-4.9.1,lost_aether@0.1.1,craftstudioapi@1.0.0,modnametooltip@1.10.1,bettercaves@1.12.2,forgeendertech@1.12.2-<IP_ADDRESS>,minerva@1.0.13,hammercore@<IP_ADDRESS>,jeibees@<IP_ADDRESS>,ctm@MC1.12.2-<IP_ADDRESS>,reauth@3.6.0,bewitchment@0.21.5,hungertweaker@1.3.0,forgelin@1.8.4,atum@2.0.16,xreliquary@1.12.2-<IP_ADDRESS>6,stg@1.12.2-1.2.3,randompatches@1.12.2-<IP_ADDRESS>,llibrary@1.7.19,apotheosis@1.12.4,snowrealmagic@0.3.3,guideapi@1.12-2.1.8-63,jeresources@<IP_ADDRESS>,soulshardsrespawn@1.12.2-1.1.1-13,shetiphiancore@3.5.9,mysticallib@1.12.2-1.4.0,betterwithlib@${version},dshuds@<IP_ADDRESS>,unidict@1.12.2-2.9.3,openglider@@VERSION@,climaticbiomesjbg@2.14.10,biomesoplenty@<IP_ADDRESS>1,redstoneflux@2.1.0,controlledburn@<IP_ADDRESS>,defiledlands@1.4.3,battletowers@1.6.5,reccomplex@<IP_ADDRESS>,botania@r1.10-362,dynamiclights_mobequipment@1.1.0,containerfix@1.0,resourceloader@1.5.3,watercontrolextreme@1.0.0,littletilescore@1.0.0,potioncore@1.8_for_1.12.2,impstorage@1.5.0,lunatriuscore@<IP_ADDRESS>,eerieentities@1.0.7,topaddons@1.12.2-1.12.0,aetherworks@1.12.2-<IP_ADDRESS>,ceramics@1.12-1.3.7,FML@<IP_ADDRESS>,storagedrawersunlimited@1.12.2-1.3.0,tombstone@3.6.2,hardcoredarkness@2.0,itemphysic@1.4.0,adchimneys@1.12.2-<IP_ADDRESS>,dynamiclights_creepers@1.0.6,charm@1.12.2-1.3.6,customstartinggear@1.2.0,cleanview@1.12.2-v1c,codechickenlib@<IP_ADDRESS>8,dynamictrees@1.12.2-0.9.6,dym@1.2.0,prettybeaches@1.0.4,netherex@2.0.15,climaticbiomesdt@1.4.0,baubleshud@5.0.2,clienttweaks@3.1.11,savemystronghold@1.12.2-1.0.0,ctgui@1.0.0,mowziesmobs@1.5.4,dynamictreesbop@1.12.2-1.4.1e,tinkersextras@1.12.2-1.1.0,coralreef@2.0,hungeroverhaul@1.12.2-1.3.3.jenkins148,smoothfont@mc1.12.2-2.1.1,jei@<IP_ADDRESS>1,attributefix@1.0.4,ropeladders@2.0.0,custommainmenu@2.0.9,orechidendium@1.0.1,bibliocraft@2.4.5,cosmeticbeds@1.12.2-<IP_ADDRESS>,colytra@<IP_ADDRESS>,naturalnetherportals@1.2.0,smoothfontcore@mc1.12.2-2.1.1,naturescompass@1.6.2,sereneseasons@1.2.18,chameleon@1.12-4.1.3,conarm@<IP_ADDRESS>,inventorytweaks@1.63+release.109.220f184,stepup@1.0.2-mc1.10-1.12.2,xpholder@2.0.4,ep@1.0,iceandfire@1.8.3,crafttweaker@4.1.20,mysticalworld@1.12.2-1.6.1,ido@1.0.6,forge@<IP_ADDRESS>47,ruins@17.2,phosphor-lighting@1.12.2-0.2.6,dsurround@<IP_ADDRESS>,antiqueatlas@4.6.3,infernalmobs@1.7.6,ferdinandsflowers@<IP_ADDRESS>,minecraft@1.12.2,horsetweaks@1.0.5,tcomplement@1.12.2-0.4.3,capsule@1.12.2-3.3.7,theoneprobe@1.4.28,mousetweaks@2.10,carbonado@1.5.1,pickblockplus@1.1.1,undergroundbiomes@1.3.7,hooked@%VERSION%,applecore@3.2.0,dynamiclights_dropitems@1.1.0,rustic@1.1.2,kjlib@1.0.4,dynamiclights_flamearrows@1.0.1,torchlever@1.0,totemic@1.12.2-0.11.6,jeiintegration@<IP_ADDRESS>,mantle@1.12-<IP_ADDRESS>,loottweaker@0.1.3,thebetweenlands@3.5.4,jeivillagers@1.0,autoreglib@1.3-32,libraryex@1.0.12,visuals@7r,wopper@1.12-r5,structurize@1.12.2-0.10.124-ALPHA,biometweakercore@1.0.39,stellarapi@1.12.2-<IP_ADDRESS>,embers@1.13-hotfix2,appleskin@1.0.9,spawnercontrol@1.6.3b,antiqueatlasoverlay@1.2,recipehandler@0.13,durabilityviewer@1.4,netherendingores@1.12.2-1.3,easyelytrato@1.1,parry@1.0,aquaculture@1.6.8,metalchests@v6.1.0+mc1.12.2,dynamiclights_onfire@1.0.7,friendlyfire@1.5.10,spiceoflife@1.3.12,baubleofundying@1.0.1,holoinventory@<IP_ADDRESS>,forestry@<IP_ADDRESS>9,mobends@0.24,base@3.13.0,astralsorcery@1.10.20,netherportalfix@5.3.17,113_water_mechanics@1.0.2,creativecoredummy@1.0.0,animania@1.7.3,multistorage@1.4.14,universalbestiary@1.1.0,dynamiclights_floodlights@1.0.3,incontrol@3.9.16,cofhcore@4.6.3,dynamiclights@1.4.9,netherchest@1.1.1,multimine@1.6.2,findme@1.1.0,rsgauges@1.1.10,controlling@3.0.7,cookingforblockheads@6.4.71,jrftl@1.1,placebo@1.6.0,millenaireextended@1.2.0,valkyrienwarfare@0.9_prerelease_5,fencejumper@1.0.5,bookshelf@2.3.590,streams@0.4.7,cofhworld@1.3.1,progressivebosses@1.5.4,dynamiclights_otherplayers@1.0.9,additionalstructures@2.3.1,mpr@2.3.3,librarianliblate@4.20,carryon@1.12.3,biometweaker@3.2.354,twilightforest@3.10.1013,dynamictreesphc@1.12.2-1.4.2,betterwithmods@1.12-2.3.20-1037,crafttweakerjei@2.0.3,endertanks@1.6.8,jehc@1.6.6,roguelike@1.8.0,patchouli@1.0-20,pewter@1.4.3,randomthings@<IP_ADDRESS>,cathedral@1.12.2-1.9.7k,better_diving@1.4.14,endreborn@0.3.1,combustfish@<IP_ADDRESS>,jetif@1.5.1,soot@1.6,instantunify@1.1.2,soundreloader@1.1,vtt@0.6.4,extraalchemy@0.5.2,movillages@1.5.4,beebetteratbees@2.0.3,aether_legacy_addon@1.12.2-v1.2.3,dldungeonsjbg@1.12.10,librarianlib@4.20,xpfromharvest@1.1.0,globalsettings@3.0.2,ebwizardry@4.2.5,platforms@1.4.6,witherskelefix@2.6.3,thirstybottles@1.1.9,dynamiclights_theplayer@1.1.3,chunkpregenerator@2.1,randomconfigs@1.12.2-<IP_ADDRESS>,ivtoolkit@1.3.3-1.12,vulcanite@1.5.2,waystones@4.0.72,yoyos@1.12.2-<IP_ADDRESS>,mcp@9.42,clumps@3.1.2,diethopper@1.1,caveroot@1.1.1,comforts@<IP_ADDRESS>,cavegenerator@0.16,harvestcraft@1.12.2zb,jeid@1.0.3-48,foamfixcore@7.7.4,tbone@v1.6.8+mc1.12.2,roughmobs@2.0.0,realistictorches@2.1.1,villagermarket@1.0.1,millenaire@Millénaire 8.0.1,randomportals@1.12.2-<IP_ADDRESS>,bonsaitrees@1.1.3,iguanatweaks@1.4.20,toastcontrol@1.8.1,enderstorage@<IP_ADDRESS>,farseek@2.3.2,akashictome@1.2-12,moveminecarts@1.2,wearablebackpacks@3.1.4,orelib@<IP_ADDRESS>,craftingtweaks@8.1.9,unmending@GRADLE:VERSION-GRADLE:BUILD,tconstruct@1.12.2-<IP_ADDRESS>,extraanvils@@VERSION@,chromaticfoliage@1.1.0,endportrec@1.0,fxcontrol@0.1.14,dynamiclights_entityclasses@1.0.1,rusticwitchcraft@1.0.2,toolbelt@1.9.12,baubles@1.5.2,arcanearchives@<IP_ADDRESS>,creativecore@1.9.9,villagesp@1.0,moveboats@1.1,bloodmoon@1.5.3,vanillafix@1.0.10-SNAPSHOT,quark@r1.6-177,fastbench@1.7.3,fenceoverhaul@1.3.4,galaxite@1.1.2,iberia@2.0-25,storagedrawers@1.12.2-5.4.0,stellarsky@1.12.2-<IP_ADDRESS>,dde@1.0,schematica@<IP_ADDRESS>,minecolonies@1.12.2-0.10.630-BETA,laggoggles@FAT-1.12.2-4.9,wanionlib@1.12.2-2.4,chisel@MC1.12.2-<IP_ADDRESS>,toroquest@1.12.2-5.3,solcarrot@1.8.3,foamfix@0.10.9-1.12.2,randomtweaks@1.12.2-<IP_ADDRESS>,aether_legacy@1.4.4,customizeddungeonloot@1.0.3,illagers_plus@1.1,gbook_snapshot@2.9.1.s5,hardcorebuoy@${version},soundfilters@0.11_for_1.12,betterfoliage@2.3.1,littletiles<EMAIL_ADDRESS>


The dialog in the lab does not proceed as expected

Get to the lab
Talk to NPC until the point when he says to weigh the fish
Put the fish on the weight
See that the dialog does not continue

Unable to reproduce


fixed Typo

I think this is what you mean

@tommy-mor : Thanks for your contribution! The author, @shizn, has been notified to review your proposed change.

fixes #11580

#sign-off

@femsulu: I'm sorry - only the author of this article, @shizn, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.


MSFT_xWebVirtualDirectory: Moving strings to localization file

Pull Request (PR) description
MSFT_xWebVirtualDirectory: Moving strings to localization file
This Pull Request (PR) fixes the following issues

Fixes #477

Task list

[ ] Added an entry under the Unreleased section of the change log in the CHANGELOG.md.
Entry should say what was changed, and how that affects users (if applicable).
[ ] Resource documentation added/updated in README.md.
[ ] Resource parameter descriptions added/updated in README.md, schema.mof
and comment-based help.
[ ] Comment-based help added/updated.
[x] Localization strings added/updated in all localization files as appropriate.
[ ] Examples appropriately added/updated.
[ ] Unit tests added/updated. See DSC Resource Testing Guidelines.
[ ] Integration tests added/updated (where possible). See DSC Resource Testing Guidelines.
[ ] New/changed code adheres to DSC Resource Style Guidelines and Best Practices.

This change is

Please update this PR similar to https://github.com/PowerShell/xWebAdministration/pull/510.

Please update this PR similar to https://github.com/PowerShell/xWebAdministration/pull/510.

Codecov Report

Merging #512 into dev will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##              dev     #512   +/-   ##
=======================================
  Coverage   91.39%   91.39%
=======================================
  Files          17       17
  Lines        2661     2661
=======================================
  Hits         2432     2432
  Misses        229      229

Impacted Files
Coverage Δ

...WebVirtualDirectory/MSFT_xWebVirtualDirectory.psm1
89.36% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


[4.1] Upgraded line awesome to 1.3.0 and replaced all fa icons with la icons

Upgraded Line-Awesome to 1.3.0, which provides syntax compatibility with Font Awesome 5.x
Breaking change. Some icon names have changed.
Took the liberty of replacing all icon syntax throughout Backpack from fa fa-home to la la-home, to prevent clashes when using the bootstrap-iconpicker field type.
One problem remains - inside datatables, the ellipsis and ordering carets still don't work:

Needs mentioning in the upgrade guide:

change path to CSS file in config/base.php file;
check that all icons you were using before in your sidebar_content.blade.php still work, or replace them with icons from their website;


PR 0

Fixed typo:
accomodating -> accommodating
Found with: https://github.com/ss18/grep-typos

Thanks for the correction.


Customize expense payee

Ability to use organization profiles as payees for expenses if they're not hosts.
Also added a filter on isMemberOf to filter out hosts on frontend payee select.

Everything looks clean, just make sure tests are passing.


Fixing hitting get_next_requests on each attempt to get buffered request

When it's not possible to fully fill the downloader queue, get_next_requests is called on each scheduler's attempt to get new request in Scrapy Engine. Resulting to blocking the event loop and timing out of requests that are already in the queue.
The solution in this PR introduces 30 seconds delay when backend is returning zero results, allowing rest of the schedulers buffer to exhaust, event loop to unblock and continue processing the queue.

@kalessin please have a look!

Related to https://github.com/scrapinghub/crawl-frontier/pull/19

Ok, looks good to me

just is a bit weird to me that first time self._delay_next_call is initialized to clock() and then to 0.0. Logic is not broken but it is a bit confusing.

It looks good for me too, except a tiny moment: probably we don't want hard-coded 30 seconds delay for any backend, it's too restrictive in common sense, so I'd move it to the frontier settings to make it more flexible (with default value).

+1

@kalessin, @vshlapakov please check!

Thanks, I'm fine with the patch.

@vshlapakov Could you merge it?


Build and publish huginn/huginn-test

If we publish this docker image, then it will be possible to execute commands from within a huginn development/test environment. For example, it should be possible to test and build an external huginn_agent using this docker image:
# docker-compose.yml
version: '2'

services:
  ...
  huginn_gem_build:
    image: huginn/huginn_test
    environment:
      DATABASE_ADAPTER: postgresql
      TEST_DATABASE_NAME: huginn
       ...
    links:
      - postgres
    command: rake prepare spec build
    working_dir: /build
    volumes:
      - .:/build

I don't think the Travis job will work until docker.io/huginn/huginn-test is created:
DOCKER_IMAGE=huginn/huginn-test DOCKERFILE=docker/test/Dockerfile ./build_docker_image.sh

docker pull $DOCKER_IMAGE
Using default tag: latest
Pulling repository docker.io/huginn/huginn-test
Error: image huginn/huginn-test:latest not found

@dsander good idea - updated the PR with your suggestion

@mandrews I think I was wrong yesterday. Since the test image is based on huginn/huginn-single-process we should build it after that one, right?

@dsander good catch - sorry I missed that 👍

Thanks!


[multistage] initial draft with a metadata block API

MultiStageOperator

[x] added getMetadataBlock() API which sets termination flag to true and propagate upstream.
[ ] any operator should only call getMetadataBlock() to return a successful EOS, it should not generate directly EOS via TransferrableBlockUtil anymore

Mailboxes

[x] SendingMailbox and ReceivingMailbox now bear a contract to indicate whether early termination has occur from upstream (receiving --> sending)
[x] ReceivingMailbox uses early terminate flag to indicate backward signaling from ReceiveOperator
[ ] SendingMailbox propagate the backward signaling to SendingOperator

Codecov Report

Merging #11746 (3c21c0f) into master (87996d2) will decrease coverage by 0.01%.
Report is 1 commits behind head on master.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master   #11746      +/-   ##
============================================
- Coverage     14.41%   14.40%   -0.01%
  Complexity      201      201
============================================
  Files          2342     2342
  Lines        125896   125938      +42
  Branches      19362    19365       +3
============================================
+ Hits          18146    18147       +1
- Misses       106213   106254      +41
  Partials       1537     1537

Flag
Coverage Δ

integration
?

integration2
?

java-17
14.40% <0.00%> (-0.01%)
:arrow_down:

java-20
?

temurin
14.40% <0.00%> (-0.01%)
:arrow_down:

unittests
14.40% <0.00%> (-0.01%)
:arrow_down:

unittests2
14.40% <0.00%> (-0.01%)
:arrow_down:

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

Files
Coverage Δ

...e/pinot/query/runtime/operator/FilterOperator.java
0.00% <0.00%> (ø)

...ot/query/runtime/operator/MailboxSendOperator.java
0.00% <0.00%> (ø)

...inot/query/runtime/operator/TransformOperator.java
0.00% <0.00%> (ø)

.../query/mailbox/channel/MailboxContentObserver.java
0.00% <0.00%> (ø)

...t/query/runtime/operator/LiteralValueOperator.java
0.00% <0.00%> (ø)

...query/runtime/operator/exchange/BlockExchange.java
0.00% <0.00%> (ø)

...apache/pinot/query/mailbox/GrpcSendingMailbox.java
0.00% <0.00%> (ø)

...t/query/mailbox/channel/MailboxStatusObserver.java
0.00% <0.00%> (ø)

...pinot/query/runtime/operator/HashJoinOperator.java
0.00% <0.00%> (ø)

...che/pinot/query/runtime/operator/SortOperator.java
0.00% <0.00%> (ø)

... and 9 more

... and 14 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


KAFKA-6299. Fix AdminClient error handling when metadata changes

AdminClient should only call Metadata#requestUpdate when needed.
AdminClient should retry requests for which the controller has changed.
Fix an issue where AdminClient requests might not get a security
exception, even when a metadata fetch fails with an authorization
exception.
Fix a possible issue where AdminClient might leak a socket after the
timeout expires on a hard close, if a very narrow race condition is
hit.

Test failure was org.apache.kafka.common.security.authenticator.ClientAuthenticationFailureTest.testAdminClientWithInvalidCredentials, which is not related.

@cmccabe The test failure does seem caused by this patch. I reproduced locally on this branch. Can you check again?

Jenkins is flaking again due to out of memory errors launching git.
18:28:10 Caused by: java.lang.OutOfMemoryError: unable to create new native thread
18:28:10 	at java.lang.Thread.start0(Native Method)
18:28:10 	at java.lang.Thread.start(Thread.java:717)
18:28:10 	at hudson.Proc$LocalProc.<init>(Proc.java:269)
18:28:10 	at hudson.Proc$LocalProc.<init>(Proc.java:218)
18:28:10 	at hudson.Launcher$LocalLauncher.launch(Launcher.java:930)
18:28:10 	at hudson.Launcher$ProcStarter.start(Launcher.java:450)
18:28:10 	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1992)
18:28:10 	... 15 more
18:28:10 ERROR: Error cloning remote repo 'origin'
18:28:10 Retrying after 10 seconds

retest this please

retest this please

retest this please


NUCLEO-F446RE - timed out or error in transfer to remote

Hi,
I'm trying to copy the uasyncio library to my NUCLEO-F446RE board (MB1136 C-03). I tried to copy the whole folder, I tried to copy single files -everytime I get the error message:
timed out or error in transfer to remote
Any idea what I can do?

Please try rshell 0.0.26
I just uplaoded a fix. Please let me know if it wrks for you.

Thanks a lot - it is fixed with rshell 0.0.26


Generate pseudo events

Add the pseudo events generator that should still live in dials_research.
At this moment there is only an option to write event datasets full of zeros, implemented in order to generate example files for GDA. It would be good to have an actual fake event generator, which already exists and only needs some tidying up.

While still pretty slow, the pseudo event generator is now working slightly better than before.
Aside from speed, the biggest issue right now is that the timestamps are exactly the same each chunk that gets written (so if eg. 3 chunks there will be the same (position, timestamp) repeated 3 times in the dataset)

Log of event generation for one chunk of events for a Tristan2M detector:
2022-02-25 15:06:57,656 NeXusGenerator.writer.data INFO Start generating one chunk of pseudo events for (1, 2) modules of Tristan 2M
2022-02-25 15:08:14,632 NeXusGenerator.writer.data INFO Time taken to generate pseudo-event list: 76.91 s.

Log of event generation for one chunk of events for a Tristan10M detector:
2022-02-25 16:39:13,304 NeXusGenerator.writer.data INFO Start generating one chunk of pseudo events for (2, 5) modules of Tristan 10M
2022-02-25 16:45:16,805 NeXusGenerator.writer.data INFO Time taken to generate pseudo-event list: 362.60 s.

Average time to then write events to each file: 0.40s.

This will still need some improvement work ...


include advisories from Snyk

E.g. https://security.snyk.io/vuln/SNYK-JS-AXIOS-6144788 which is not currently being flagged by dependabot

Hi Alex!
Thanks for reaching out and sending us this feedback. We always appreciate a chance to make our database better.
Unfortunately Snyk's advisories are proprietary and not an option for us to republish. If the advisory has a CVE, it is then public domain and comes to us through our CVE importers, but this specific one does not.
This highlights the importance of all package maintainers making sure they get an official CVE when publishing an advisory so this information can be propagated through all information pathways!
Let me know if this answers your question, if so I'll go ahead and close this issue.
Thanks again!

We're very sure! We've worked with our legal team before on this subject.
If there's no other questions here, I'll go ahead and close this issue out. But thanks for writing in here, we appreciate our community working to make us better ❤


Python tests do not work without AudioTK Python libraries installed

The Python tests do not work without the Python libraries installed, so the test can not be run from the source or build tree without installing first, which is a problem e.g. for distribution packagers.
The reason is that they import the ATK modules in the form from ATK.Xyz import xyz, but the directory for the ATK python package is only created on installation of the modules. In the build tree there is no ATK directory and hence no ATK package. So even adding the build/Python directory to PYTHONPATH for the tests wouldn't work.
I don't see a quick solution for this. IMHO either the build process should be altered in such a way that the modules are created in a proper package directory structure under build/Python/ATK or a testing environment should be used, that creates a temporary installation of the Python package (like e.g. tox.)

This ticket arose out of of issue #15.

Thanks a lot!
A preliminary hack that I added on the current SIMD branch is DISABLE_PYTHON_TESTS as I had lots of issues, even after make install, on appveyor and travis-ci.
But it's a workaround only, I need to figure out a proper way to fix this. The refactoring to streamline the Python generation should help, as I can also generate the init.py file from them and then just rename the parent folder accordingly.

Seems like everything should work. That's odd. I'll have to check a few things.

I tried it on an embedded Linux and the latest develop version, it worked as expected, the tests did have all the Python scripts :/
So I have no clue why it doesn't work on your platform. You may want to add a few message(STATUS "${entry}") inside the python/ATK/CMakeLists.txt file to display which files are really parsed.


Permit more than just HTTP?

An option to allow a direct socket connection would be nice, for example, if I wish to permit someone to access my box via SSH/FTP/whatever, being able to forward those protocols would be nice.
Have the default listener set to 80 on the localtunnel.me 'forwarded host' or whatever port works for you.
Just an idea, but it would be a very nice function :)

ngrok does permit tcp connections

I am not against it but don't have the time to look into what it would take
to accomplish it. I also don't view it as a priority since it is not the
main focus of this tool.
On Thursday, August 6, 2015, Adrian Rangel<EMAIL_ADDRESS>wrote:

ngrok does permit tcp connections
—
Reply to this email directly or view it on GitHub
https://github.com/localtunnel/localtunnel/issues/23#issuecomment-128481082
.

Just to be clear, Websockets are still not supported on the hosted server, right? Sorry if they aren't... I've been looking for a service that does this for quite some time now, since I don't have the time to code it (or better yet, to learn how to code it and then do it) myself either...
I do believe this kind of service would open a door to bidirectional communications between local devices. I know there are some services that offer this, Ngrok is one of them, but their payment plans don't seem right for what I need...

@jamesokbo websockets should be supported just fine on the hosted server. If they are not, it is likely a bug.

Was this recently implemented? :)

No, iirc websocket support has existed for a while

lol ok! thank you very much, I'll try it as soon as I can


Add Acorn 5

After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} reports no offenses.
[x] The commit message includes the cask’s name and version.

Additionally, if adding a new cask:

[x] Named the cask according to the token reference.
[x] brew cask install {{cask_file}} worked successfully.
[x] brew cask uninstall {{cask_file}} worked successfully.
[x] Checked there are no open pull requests for the same cask.
[x] Checked the cask was not already refused in closed issues.
[x] Checked the cask is submitted to the correct repo.

@commitay Done. FWIW, I had removed them because brew cask audit and style complained.

Interpolation in single quoted string detected. Use double quoted strings if you need interpolation.

Oh, I see, thanks. Not a Ruby developer, and all style told me was that it wasn't a valid URL.

brew cask style acorn5.rb
== acorn5.rb ==
W:  5:  7: Interpolation in single quoted string detected. Use double quoted strings if you need interpolation.
W:  6: 11: Interpolation in single quoted string detected. Use double quoted strings if you need interpolation.

1 file inspected, 2 offenses detected
Error: style check failed

$ brew cask style acorn5
Error: Cask 'acorn5' definition is invalid: 'url' stanza failed with: bad URI(is not URI?): https://secure.flyingmeat.com/download/Acorn-#{version}.zip

Strange, that's the error you should get for audit not style.
brew cask audit acorn5.rb
Error: Cask 'acorn5' definition is invalid: 'url' stanza failed with: bad URI(is not URI?): https://secure.flyingmeat.com/download/Acorn-#{version}.zip
``

Moreover,
$ brew cask style acorn5.rb
Error: Cask 'acorn5' is unavailable: No Cask with this name exists. Did you mean “acorn5”?
$ brew cask --version
Homebrew-Cask 1.3.6-148-g2d5bb02
caskroom/homebrew-cask (git revision 6ca7f; last commit 2017-10-31)

Ah, it works if passing a Ruby file, not a cask name. This might be a bug depending how you look at it.
$ cd Casks
$ brew cask style acorn5.rb
== acorn5.rb ==
W:  5:  7: Interpolation in single quoted string detected. Use double quoted strings if you need interpolation.
W:  6: 11: Interpolation in single quoted string detected. Use double quoted strings if you need interpolation.

1 file inspected, 2 offenses detected
Error: style check failed


How to stop making new rustfmt windows?

I have rust-mode configured to run rustfmt on save, which generally I like. However, every time there's an error, it splits an existing window so that it can show the *rustfmt* buffer, and then after fixing the errors, it closes the *rustfmt* buffer, but leaves the new window configuration. So as I work it just slowly changes around my window setup. Can I avoid this behavior somehow while still automatically running rustfmt on save?

Try (setq rust-format-show-buffer nil).

Perfect, thanks.


Address already used

I print the tcp. From the results, setting the port does not seem to have any effect

The number after : indicates the number of processes that should be launched on that node. I don't think it's possible to manually set the port, except by changing the value at https://github.com/zhijian-liu/torchpack/blob/master/torchpack/launch/launchers/drunner.py#L73.

any updates on this issue?

@jiachens, I haven't got a chance to fix this yet. This should be a minor fix. Feel free to submit a PR if you have time.

Hello! I have encountered the same problem. How can I solve it?

Have you fixed the bug?

It's been a long time, and I've lost track of the specific code. My previous solution was to plagiarize the train.py file of mmdetection3d. Hope this helps.

It's been a long time, and I've lost track of the specific code. My previous solution was to plagiarize the train.py file of mmdetection3d. Hope this helps.

Thanks for your kind suggestion!


GEODE-6875: Remove unused & deprecated API usage

The pull request contains 3 different commits, one for each of the tasks requested through the GEODE ticket.
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[X] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?

[X] Has your PR been rebased against the latest commit within the target branch (typically develop)?

[X] Is your initial contribution a single, squashed commit?

[X] Does gradlew build run cleanly?

[X] Have you written or updated unit tests to verify your changes?

[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?

Note:
Please ensure that once the PR is submitted, check Concourse for build issues and
submit an update to your PR as soon as possible. If you need help, please send an
email to<EMAIL_ADDRESS>

Regarding the usage of Internal API, below is the list of classes for which the task couldn't be achieved and the actual reasons:

AbstractCache: no replacements for used API in public classes.
AbstractSessionAttributes: belongs to an internal package, it can use internal classes.
Banner: no replacement for GemFireVersion in public packages.
CreateRegionFunction: internal function that creates an internal region dealing with internal mechanisms, no replacements in public packages.
DeltaEvent: belongs to an internal package, it can use internal classes.
DeltaSession: no replacements for used API in public classes.
DeltaSessionManager: no replacements for used API in public classes.
DeltaSessionStatistics: belongs to an internal package, it can use internal classes.
GatewayDeltaCreateEvent: no replacements for used API in public classes.
GatewayDeltaEventApplicationCacheListener: no replacements for used API in public classes.
GatewayDeltaForwarderCacheListener: no replacements for used API in public classes.
GemfireSessionManager: belongs to an internal package, it can use internal classes.
Installer: no replacements for used API in public classes.
RegionHelper: no replacements for used API in public classes.
BootstrappingFunctionTest: no replacements for used API in public classes.
ClientServerSessionCacheDUnitTest: no replacements for used API in public classes.

Hey @mcmellawatt ,
Thanks for reviewing this, guess it wasn't an easy task due to the amount of files changed... :sweat_smile:. Regarding the Tomcat tests in the org.apache.geode.session.tests package, they should be included as part of CI execution under the :geode-assembly:distributedTest task:
./gradlewStrict -PcompileJVM=/usr/lib/jvm/java-8-openjdk-amd64 -PcompileJVMVer=8 -PtestJVM=/usr/lib/jvm/java-11-openjdk-amd64 -PtestJVMVer=11 -PparallelDunit -PdunitDockerUser=geode -PdunitDockerImage=$(docker images --format '{{.Repository}}:{{.Tag}}') -PdunitParallelForks=24 --parallel --console=plain --no-daemon -x javadoc -x spotlessCheck -x rat distributedTest

We should be fine to merge this PR once the last CI finishes (assuming everything's green):
Cheers.


feat: use final redirect URL for chunk download

Only call the final redirect URL to avoid overloading the Hub with requests and also altering the download count
cc @osanseviero & @Pierrci regarding download count.
@Wauplin we should check that we do the same in huggingface_hub for download but also when using the multipart upload, we want to make sure parts_urls: Vec<String> only contains s3 urls and not hugginface.co (though this won't affect download count, more a thing about reducing load on hf.co).

pretty sure it's always already been the case in huggingface_hub

@McPatate for reference, can you link to internal discussion of this subject? (e.g. a Slack link)

This conversation for example: https://huggingface.slack.com/archives/C02EMARJ65P/p1717775944145709


Add inline help for forms

Form fields could benefit from a help text for each field (when hovering on a small question mark icon next to the field's name for example).

Add or re-add placeholders in fields where relevant


Four Capabilities in Modern Editor

After a previous issue, and a long reconsidering on "category of extendsion" or "interconnect inside editor components", I cannot find any durable help more. And now I quit that. I think we may restart to a initial part: production base line, what define a editor itself but not another, and I call this as a course named "Capabilities in Editor", and as a periodically conclusion, more specifically, I call this as a course named "Four Capabilities in Modern Editor":

Capabilities I -- Content Create and Modify Invoking (CCAMI). It is important that a modern editor is not just focus in content create and modify , but deeply focus and care in the invoking of content create and modify. Philosophically, this means that a modern editor take edit as a act, but also a procedure. The duality in edit-as-act and edit-as-procedure cause a unimaginable complexity but also a unprecedented performance in a Modern Editor. And as a question, development shall support thus capabilities,  The CCAMI Capabilities, for a substantial editing experience and for a better tomorrow.  There be a shift from CCAM paradigm to CCAMI paradigm in A modern editor . And both text editing and object editing might enter on the stage.
Capabilities II -- Responsive Editing(RE). What you type is what to insert is a most simply policy and a nocturnes in early editor. But nowadays, the ubiquitous connections raise the new structure of Responsive Editing, and more factors may extend, enrich the scope or task of Responsive Editing. We can divide the Responsive Editing in three journey: Before-Editing journey, In-Editing journey and After-Editing journey. But with more generality, there still another some hyper journey: Before-Program journey, In-Program journey and After-Program journey since data or preparation are from hardwards and not just configure files. As a result, development shall support a journey-interesting Responsive Editing.
Capabilities III -- Working Flow Integration And Progress Governing (WFIAPG). The modern life brights tons of inputs, events and interactions into production and individuals, which oppress every worker subjected to his boss, his working flow, but edge out his character. A balance and controllable editor shall both care the flexibility, reliability and responsibility of individuals, but also get rid of the inhuman or irrational schooled-flow or schooled-progress. Intersecting to working flow integration, Progress Governing means one shall has the free and be protected to use his rights in editing, especially his editing of decision, epistemic and voting, not locked from software, hardward or anything else.
Capabilities IV -- Trust Information Transmit(TIT). A modern editor construct from his calculation, his visual structure and composition, his story from user and to user. Information both characterized or not-characterized, is the soul of editor-user-story cycle. A modern editor has the capabilities to single out, management and delivery information to and from his user, by graphical interface, the network, or a piece of paper.

And so, "category of extendsion" or "interconnect inside editor components" shall build on the stone of thus four capabilities. And as next step, it is possible that be a document on how this four implemented in Biscuit.

Hey @ltaoist, thanks for the good notes!
From my understanding, you are suggesting a more intentional and structured development process that aligns with these capabilities. By focusing on these capabilities, I believe that the resulting editor will be more robust, flexible, and user-friendly, encompassing a range of functionalities that address content manipulation, responsiveness, workflow integration, and information management.
In essence, we will be able to establish a conceptual framework that informs the design and development decisions for the Biscuit project, ensuring that future extensions and internal components align with these identified capabilities for a more coherent and powerful editor.
I have taken good notes from your suggestions, I will be updating the code as well to be more readable, more well documented! also take a look at the work-in-process documentation of biscuit: https://billyeatcookies.github.io/biscuit/

I think your highlights is outstanding. Yes, I am try to suggest a more intentional and structured development process. And more, robust, flexible, and user-friendly, functionalities ... will be attractive.
In the other hand, I am afraid should a more structured design of the editor, but what you comment that "a more intentional and structured development process", I think may not cost too much, and, will be good enough. And so on, a framework might be infeasible, but a "conceptual" framework will work.
I am amazing of your wisdom. You point things in a right way much more that me at least in my view!
======================
Sorry for my verbose. I don't know how to proposal this in short.
As practice, recent day I try to reconstruction libreoffice for several steps. In first step, we want build it by another build system, yes "monkey2". Now we have discover some issue. Firstly is that the well famous “conditional compile” or “conditional build” might divide into "feature optional building", "platform specific building", and "language level conditional building". Now I have to prepare for a serious modification in the tons line of the libreoffice source. If I choice to advance this works in biscuit, how should I construct a user interface? (as I am the only user may be now.) Typically it might be a pop window for building message. There are two options: ① try to allocate a new window as text base interface, ② a more interesting or innovative way. Can I get any help from you? I can try to implement an idea, but I can find a an attractive mechanism.
An attractive mechanism not a framework.
An attractive mechanism not a framework.
An attractive mechanism not a framework.
While I say mechanism, or a conceptual framework, I actually refer to a question -- "How should computation fly?" Actually I think apple work well. Some example:
https://developer.apple.com/design/human-interface-guidelines/designing-for-visionos
https://developer.apple.com/design/human-interface-guidelines/immersive-experiences
On the opposite side, google do bad. Some example:
https://developer.android.com/topic/architecture
As a member in programmer's programming helper stack, I think editor will help programmer to construct the program, the software, the computation, so give power to computation flying is important and apple works well. But google just trap developer into their "framework", "architecture".
======================
All and all, my conclusion is that it well better be for some graph about how things work together. And, I might try to integrate with the build system more deeply.
Good Luck!

@ltaoist the idea is quite amazing, sorry for the delay (due to my uni). I will document the whole thing gradually, see the progress so far at https://billyeatcookies.github.io/biscuit

Dear Lord Billy, Sorry for I lost a long time. However after such a long time separation, I finally found what here has done is just really good. And I have something new.
I think document now is accommodated. Good jobs!
I think the class name is hard, this is some root of the difficult for further stepping. I started to do some analyse and prepare for a new commit.

@ltaoist haha thanks for the review! ❤ I will try to work on the docs further

After a new structure for core packages, I think some analyse would be more; for how to establish functions and creativity part more simply.

For more, go https://github.com/billyeatcookies/biscuit/discussions/218


Feature/sepolia network

This PR adds the Arbitrum Sepolia chain subgraph.
The package.json commands are set up for deploying the subgraph to Alchemy.
I have removed the accessKey entity from the subgraph definitions

Great Eugene. Please can you add a changeset. You can do this by running yarn changeset in the root. Then create a minor release. See here for some examples. Thanks


[No QA] Temporarily remove getPullRequestsMergedBetween unit test

Details
Contributor PRs are failing unit tests because they do not have access to the repo secrets necessary for OSBotify to configure commit signing on the GitHub Actions runner. This PR should fix that temporarily removing the new failing test, pending a solution that doesn't require commit signing (or doesn't use actual GPG keys).
Fixed Issues
$ https://github.com/Expensify/Expensify/issues/191675
Tests
None - only PR checks.
QA Steps
No QA.
Tested On

GitHub only

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by @Julesssss in version: 1.1.27-2 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to staging by @Julesssss in version: 1.1.27-3 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to staging by @Julesssss in version: 1.1.27-3 🚀

platform
result

🤖 android 🤖
skipped 🚫

🖥 desktop 🖥
skipped 🚫

🍎 iOS 🍎
skipped 🚫

🕸 web 🕸
skipped 🚫

🚀 Deployed to production by @Jag96 in version: 1.1.29-5 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


How can I get the entire file with changes?

Hello, I would like to know how I can get the whole file with a diff part of it and not, as shown in the screenshot.

This is my code for getting diffs
`async getDiff(hash, repoPath) {
const diffs = [];
const repo = await gitConnect.gitOpenConnect(repoPath);
const commit = await repo.getCommit(hash);
const diffList = await commit.getDiff();
    for (const diff of diffList) {
        const patches = await diff.patches();
        for (const patch of patches) {
            const hunks = await patch.hunks();
            for (const hunk of hunks) {
                const lines = await hunk.lines();
                const diff = {
                    oldFile: patch.oldFile().path(),
                    newFile: patch.newFile().path(),
                    hunk: hunk.header().trim(),
                };
                for (const line of lines) {
                    diff.file += String.fromCharCode(line.origin()) +
                        line.content().trim() + '\n';
                }
                diffs.push(diff);
            }
        }
    }
    return diffs;
}`


P/Invoke and COM definitions not generated by builds for ARM64

Actual behavior
Some APIs do not seem to generate definitions even if you build with ARM64 platform instead of Any CPU. I can confirm this with IShellBrowser, IShellView and SHGetFileInfo.
Expected behavior
I expect the API definition to be generated when ARM64 is specified as well as when x64 is specified.
Repro steps

NativeMethods.txt content:

IShellBrowser
IShellView
SHGetFileInfo

NativeMethods.json content (if present):

Any of your own code that should be shared?

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net6.0</TargetFramework>
    <Platforms>x64;arm64</Platforms>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.Windows.CsWin32" Version="0.1.635-beta">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>
  </ItemGroup>

</Project>

Build comand
# Succeeded
dotnet build -p:Platform=x64
# Warning
dotnet build -p:Platform=arm64

Build log

C:\Users\shibayan\Documents\cswin32test\NativeMethods.txt(1,1): warning PInvoke005: This API is only available when targeting a specific CPU architecture. AnyCPU cannot generate this API. [C:\Users\shibayan\Documents\cswin32test\cswin32test.csproj]
C:\Users\shibayan\Documents\cswin32test\NativeMethods.txt(2,1): warning PInvoke005: This API is only available when targeting a specific CPU architecture. AnyCPU cannot generate this API. [C:\Users\shibayan\Documents\cswin32test\cswin32test.csproj]
C:\Users\shibayan\Documents\cswin32test\NativeMethods.txt(3,1): warning PInvoke005: This API is only available when targeting a specific CPU architecture. AnyCPU cannot generate this API. [C:\Users\shibayan\Documents\cswin32test\cswin32test.csproj]

Context

CsWin32 version: 0.1.635-beta
Win32Metadata version (if explicitly set by project):
Target Framework: net6.0
LangVersion (if explicitly set by project):

Ok, so the problem is apparent when you add -bl to your build and inspect the msbuild.binlog file. The Csc task is invoked with Platform set to AnyCPU.
It turns out that merely setting the msbuild Platform property isn't enough. The property that is passed to the compiler is PlatformTarget. If you set that at the command line, it works:
dotnet build -p:Platform=arm64 -bl -t:rebuild -p:PlatformTarget=arm64

A quick glance at the msbuild .targets files in the .NET SDK suggests that this disconnect is intended for projects to pivot based on runtime identifiers instead of platforms. If you modify your project file like this:
-    <Platforms>x64;arm64</Platforms>
+    <RuntimeIdentifiers>win-x86;win-x64;win-arm64</RuntimeIdentifiers>

Then building succeeds when you target a specific runtime identifier:
dotnet build -bl -t:rebuild -r win-arm64
dotnet build -bl -t:rebuild -r win-x64

I don't know why this is only required when setting platform to arm64. Your project builds fine as you expected with -p:x64. Maybe the .targets files in the SDK know how to map Platform to PlatformTarget for x86 and x64 but not arm64. @rainersigwald, do you have any idea?

@AArnott I think you're exactly right, and dotnet/sdk#15434 should be the right place to track it.
@baronfel, I think there might be room for some docs guidance about Platform/RID for .NET projects; I believe we generally prefer specifying RID and inferring Platform/PlatformTarget but I couldn't see that anywhere in the docs.

Thanks for the investigation.
I was able to avoid this problem for the time being by adding the following definition to csproj file.
  <PropertyGroup Condition=" '$(_PlatformWithoutConfigurationInference)' == 'ARM64' ">
    <PlatformTarget Condition=" '$(PlatformTarget)' == '' ">ARM64</PlatformTarget>
  </PropertyGroup>


Tetris game

Is your feature request related to a problem? Please describe.
I want to make a Tetris game.
Describe the solution you'd like
I want to make a Tetris game using HTML, CSS and Js
Additional context
NA

@urvashi-code1255 can you please assign this issue to me as a part of Cross WOC?

@Harshal0902 go for it.


[BUG] Bot auto assigned gym team. Bot auto-renamed player. Bot changed looks of player

Expected Behavior
Continue botting
Actual Behavior
Player name changed to AYOUBTBBLEBG
Player assigned to Team Mystic
Player appearance changed from default male to dark skinned male
Possibly got soft banned also. Did no teleportation activities.
Your FULL config.json (remove your username, password, gmapkey and any other private info)
{
"auth_service": "ptc",
"username": "",
"password": "",
"location": "",
"gmapkey": "",
"encrypt_location": "",
"websocket_server": false,
"heartbeat_threshold": 10,
"tasks": [
{
"type": "HandleSoftBan"
},
{
"type": "SleepSchedule",
"config": {
"enabled": true,
"time": "23:54",
"duration":"6:46",
"time_random_offset": "00:24",
"duration_random_offset": "00:43"
}
},
{
"type": "RandomPause",
"config": {
"enabled": true,
"min_duration": "00:00:50",
"max_duration": "00:25:00",
"min_interval": "00:25:00",
"max_interval": "02:00:00"
}
},
{
"type": "CompleteTutorial",
"config": {
"enabled": false,
"// set a name": "",
"nickname": ""
}
},
{
"type": "CollectLevelUpReward"
},
{
"type": "IncubateEggs",
"config": {
"longer_eggs_first": true
}
},
{
"type": "UpdateLiveStats",
"config": {
"enabled": true,
"min_interval": 10,
"stats": ["username", "uptime", "stardust_earned", "xp_earned", "xp_per_hour", "stops_visited"],
"terminal_log": true,
"terminal_title": true
}
},
{
"type": "UpdateLiveInventory",
"config": {
"enabled": true,
"min_interval": 120,
"show_all_multiple_lines": false,
"items": ["pokemon_bag", "space_info", "pokeballs", "greatballs", "ultraballs", "razzberries", "luckyegg"]
}
},
{
"type": "TransferPokemon",
"config": {
"min_free_slot": 5,
"transfer_wait_min": 1,
"transfer_wait_max": 4
}
},
{
"type": "NicknamePokemon",
"config": {
"enabled": false,
"nickname_template": "{iv_pct}_{iv_ads}"
}
},
{
"type": "EvolvePokemon",
"config": {
"evolve_all": "Pidgey,Pidgeotto,Rattata,Weedle,Caterpie,Zubat,Psyduck,Krabby,Doduo,Spearow,Ponyta,Staryu,Slowpoke,Horsea,Goldeen,Ekans,Tentacool,Paras,Meowth,Mankey,Cubone,Sandshrew,Machop,Machoke,Growlithe,Venonat,Diglett,Geodude,Graveler,Rhyhorn,Eevee,Nidorino,Nidorina",
"first_evolve_by": "cp",
"evolve_above_cp": 10,
"evolve_above_iv": 0.9,
"logic": "or",
"evolve_speed": 20,
"use_lucky_egg": false
}
},
{
"type": "RecycleItems",
"config": {
"min_empty_space": 15,
"max_balls_keep": 200,
"max_potions_keep": 50,
"max_berries_keep": 70,
"max_revives_keep": 70,
"item_filter": {
"Pokeball":       { "keep" : 10 },
"Greatball":       { "keep" : 50 },
"Ultraball":       { "keep" : 150 },
"Potion":         { "keep" : 0 },
"Super Potion":   { "keep" : 0 },
"Hyper Potion":   { "keep" : 0 },
"Max Potion":   { "keep" : 30 },
"Revive":         { "keep" : 15 },
"Razz Berry":     { "keep" : 25 }
},
"recycle_wait_min": 1,
"recycle_wait_max": 4
}
},
{
"type": "CatchPokemon",
"config": {
"catch_visible_pokemon": true,
"catch_lured_pokemon": true,
"min_ultraball_to_keep": 5,
"berry_threshold": 0.35,
"vip_berry_threshold": 0.9,
"catch_throw_parameters": {
"excellent_rate": 0.1,
"great_rate": 0.5,
"nice_rate": 0.3,
"normal_rate": 0.1,
"spin_success_rate" : 0.6,
"hit_rate": 0.75
},
"catch_simulation": {
"flee_count": 3,
"flee_duration": 2,
"catch_wait_min": 2,
"catch_wait_max": 6,
"berry_wait_min": 2,
"berry_wait_max": 3,
"changeball_wait_min": 2,
"changeball_wait_max": 3
}
}
},
{
"type": "SpinFort",
"config": {
"spin_wait_min": 2,
"spin_wait_max": 3
}
},
{
"type": "MoveToFort",
"config": {
"lure_attraction": true,
"lure_max_distance": 2000,
"walker": "StepWalker"
}
},
{
"type": "FollowSpiral",
"config": {
"diameter": 2,
"step_size": 20
}
}
],
"map_object_cache_time": 5,
"forts": {
"avoid_circles": true,
"max_circle_size": 50,
"cache_recent_forts": true
},
"pokemon_bag": {
"// if 'show_at_start' is true, it will log all the pokemons in the bag (not eggs) at bot start": {},
"show_at_start": false,
"// if 'show_count' is true, it will show the amount of each pokemon (minimum 1)": {},
"show_count": true,
"// 'pokemon_info' parameter define which info to show for each pokemon": {},
"// the available options are": {},
"// ['cp', 'iv_ads', 'iv_pct', 'ivcp', 'ncp', 'level', 'hp', 'moveset', 'dps']": {},
"pokemon_info": ["cp", "iv_pct"]
},
"walk_max": 9.16,
"walk_min": 5.16,
"alt_min": 500,
"alt_max": 1000,
"gps_default_altitude": 8.0,
"replicate_gps_xy_noise": false,
"replicate_gps_z_noise": false,
"gps_xy_noise_range": 0.000125,
"gps_z_noise_range": 12.5,
"debug": false,
"test": false,
"health_record": true,
"location_cache": true,
"distance_unit": "km",
"reconnecting_timeout": 15,
"logging_color": true,
"daily_catch_limit": 800,
"catch": {
"any": {"catch_above_cp": 0, "catch_above_iv": 0, "logic": "or"},
"// Example of always catching Rattata:": {},
"// Rattata": { "always_catch" : true }
},
"release": {
"any": {"keep_best_cp": 2},
"// Example of always releasing Rattata:": {},
"// Rattata": {"always_release": true},
"// Example of keeping 3 stronger (based on CP) Pidgey:": {},
"// Pidgey": {"keep_best_cp": 3},
"// Example of keeping 2 best (based on IV) Zubat:": {},
"// Zubat": {"keep_best_iv": 2},
"// Also, it is working with any": {},
"// any": {"keep_best_iv": 3},
"// Example of keeping the 2 strongest (based on CP) and 3 best (based on IV) Zubat:": {},
"// Zubat": {"keep_best_cp": 2, "keep_best_iv": 3},
"// Example of custom order of static criterion": {},
"// Zubat": {"keep_best_custom": "iv, cp, hp_max", "amount":2}
},
"vips" : {
"Any pokemon put here directly force to use Berry & Best Ball to capture, to secure the capture rate!": {},
"any": {"catch_above_cp": 1500, "catch_above_iv": 0.98, "logic": "or" },
"Lapras": {},
"Moltres": {},
"Zapdos": {},
"Articuno": {},
    "// S-Tier pokemons (if pokemon can be evolved into tier, list the representative)": {},
    "Mewtwo": {},
    "Dragonite": {},
    "Snorlax": {},
    "// Mew evolves to Mewtwo": {},
    "Mew": {},
    "Arcanine": {},
    "Vaporeon": {},
    "Gyarados": {},
    "Exeggutor": {},
    "Muk": {},
    "Weezing": {},
    "Flareon": {}
}

}
Output when issue occurred
Don't exactly know when issue occurred. Stopped bot. Updated bot to latest version. Ran bot again.
Steps to Reproduce
Not available.
Other Information
OS:
Win 10
Branch:
Master
Git Commit:
ed095936e8fb2bdb7442c9966630664f0cb739ea
Python Version:
2.3.6

looks like this bot has been hacked.

Disappointed. @solderzzc , @nivong , @mjmadsen
Please update if this is the case.

Somebody else must have your account data, because the bot does not handle gyms, which would be needed to assign a team.

Yeah, there isn't anything in our bot that would do that.
Don't go wagging your finger at some devs who are working for free. :)


[AzureMonitorExporter] update OpenTelemetry dependencies to v1.5.0

Changes

update OpenTelemetry dependencies to v1.5.0
Breaking changes:

LogRecord.StateValues replaced with LogRecord.Attributes
ParseStateValues will be ignored unless logging an unknown object.
see also: https://github.com/open-telemetry/opentelemetry-dotnet/pull/4334

API change check
API changes are not detected in this pull request.

@TimothyMothra It would be good to validate the changes against otlp exporter changes that was done in the pr you referenced.

@TimothyMothra It would be good to validate the changes against otlp exporter changes that was done in the pr you referenced.

I don't see any of the Exporters in the otel repo checking the ParseStateValues

TODO: Need to lock to SDK v1.5.x or lower because of coming breaking changes.

@TimothyMothra It would be good to validate the changes against otlp exporter changes that was done in the pr you referenced.

I don't see any of the Exporters in the otel repo checking the ParseStateValues

There are no breaking changes. So even if this exporter do nothing, everything would work as before. (Ofcourse there will be warning about using obsolete things, but if you suppress it, then there is no need of any change here.)

TODO: Need to lock to SDK v1.5.x or lower because of coming breaking changes.

Where is breaking change in Otel sdk?

TODO: Need to lock to SDK v1.5.x or lower because of coming breaking changes.

Where is breaking change in Otel sdk?

Breaking changes are coming in the Instrumentation Libraries. We want to snap the Exporter to a known version of the base SDK.


Auto Create database if not exist.

What version of Flyway are you using?
4.2.0
Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin, SBT plugin, ANT tasks)
Gradle plugin
What database are you using (type & version)?
PostGreSQL
What operating system are you using?
mac
What did you do?
I deleted my database now I want to run gradle flywayMigrate -i and it gives error
What did you expect to see?
I want that if database does not exist it should create a new one else it should continue migration
What did you see instead?
Error occurred while executing flywayMigrate
 Unable to obtain Jdbc connection from DataSource (jdbc:mysql://localhost:3306/testDb) for user 'root': Unknown database 'testDb'
 Unknown database 'testDb'

Flyway can creates schemas, not databases. This works as designed.


dial unix /var/run/fleet.sock: connect: no such file or directory

running
core@ip-10-0-0-11 ~ $ fleetctl status
Error retrieving unit: Get http://domain-sock/fleet/v1/units?alt=json: dial unix /var/run/fleet.sock: connect: no such file or directory
core@ip-10-0-0-11 ~ $

This would most likely be because fleet is not turned on. I don't turn it
on because it is not needed for k8s. You could add a fleet section to the
cloud configs if you need / want it:
https://coreos.com/os/docs/latest/cloud-config.html
On Thu, Aug 25, 2016 at 4:52 PM Norman Khine<EMAIL_ADDRESS>wrote:

running
core@ip-10-0-0-11 ~ $ fleetctl status
Error retrieving unit: Get http://domain-sock/fleet/v1/units?alt=json: dial unix /var/run/fleet.sock: connect: no such file or directory
core@ip-10-0-0-11 ~ $
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/kz8s/tack/issues/54, or mute the thread
https://github.com/notifications/unsubscribe-auth/AE6-kXDvQoVM3RQ5aUCFufdFTa7OtHU6ks5qjiqzgaJpZM4JtnbK
.


Update README.md

Add a note about running it in the background to prevent docker auto shutdown.

I had added some explanation of the new args.
Thanks!


feat: Support for public m3u8 url in fetch video api

Description
Think about this scenario:-
I have a public m3u8 video url and i want to upload it to bunny stream. The thing I've to do now:-

Manually download all the ts files and pack it into mp4 format
Use upload video api to upload mp4 video to bunny stream

If it is possible to upload m3u8 directly to bunny stream with fetch video api, then it will be super cool!

Hey @mubin986! I agree that for your purposes the fetchVideo api would be great and should definitely support that functionality. However this project simply hits the "fetchVideo" api of BunnyCDN, therefore I would recommend you contact them instead.
https://bunny.net/contact/
Best,
Dan


fix minor typo

autcorrelation -> autocorrelation
Hello! Please make sure to check all these boxes before submitting a Pull Request
(PR). Once you have checked the boxes, feel free to remove all text except the
justification in point 5.

[ ] You have run tests on this submission, either by using Travis Continuous Integration testing testing or running nosetests on your changes?
[ ] This pull request is directed to the pysal/dev branch.
[ ] This pull introduces new functionality covered by
docstrings and
unittests?
[ ] You have assigned a
reviewer and added relevant labels
[ ] The justification for this PR is:

Coverage remained the same at 83.074% when pulling ca15316afae4f3212a947ea7abb66e6ce878fb6e on fnorf:patch-1 into 2b8174a549d6d7e724dbac17edea317c3af8ab59 on pysal:dev.

Coverage remained the same at 83.074% when pulling ca15316afae4f3212a947ea7abb66e6ce878fb6e on fnorf:patch-1 into 2b8174a549d6d7e724dbac17edea317c3af8ab59 on pysal:dev.

Coverage remained the same at 83.074% when pulling ca15316afae4f3212a947ea7abb66e6ce878fb6e on fnorf:patch-1 into 2b8174a549d6d7e724dbac17edea317c3af8ab59 on pysal:dev.

Coverage remained the same at 83.074% when pulling ca15316afae4f3212a947ea7abb66e6ce878fb6e on fnorf:patch-1 into 2b8174a549d6d7e724dbac17edea317c3af8ab59 on pysal:dev.

Coverage remained the same at 83.074% when pulling ca15316afae4f3212a947ea7abb66e6ce878fb6e on fnorf:patch-1 into 2b8174a549d6d7e724dbac17edea317c3af8ab59 on pysal:dev.


feat: upgrades react native template to 0.63.2

This PR performs the necessary changes to upgrade the template from 0.62.2 to 0.63.2.
I have tested initializing new builds with this template locally and both iOS and Android are running.

✅  Init with template (locally) was successful
✅  yarn test
✅  yarn ios
✅  yarn android
✅  yarn e2e:ios-debug
❌  yarn e2e:ios  (a flipper error) need to validate that a release build works
❌  yarn e2e:android-debug
❌  yarn e2e:android

Updated configurations of Detox, getting closer!
✅  Init with template (locally) was successful
✅  yarn test
✅  yarn ios
✅  yarn android
✅  yarn e2e:ios-debug
❌  yarn e2e:ios (a flipper error) need to validate that a release build works
✅  yarn e2e:android-debug
✅  yarn e2e:android