Prerender stricter with JS than chrome or FF can cause failure to load JS

In this particular case, we had some functions defined in the middle of a function inside an if statement - which works fine in FF/Chrome - but the JS file did not load atall in prerender (and did not provide an error message)
Happily, the IDE mentioned function statement not at top level of function or statement is prohibited - this seems like it is forcing strict mode, which should probably be disabled by default (just because it seems to be disabled by default in browsers, and would thus render in a more similar manner to them)

Yeah we've seen some stuff like this. Not sure of a way to do that since that's part of PhantomJS that I don't think we can easily change. Chrome and FF don't use webkit anymore so PhantomJS should be closer to Safari.

I don't think we can do anything about this since we are relying on PhantomJS but feel free to reopen if you have any more info that would help us solve this!

I guess without changing the rendering engine in phantomjs, there is not alot that can be done.
Perhaps a prominent note in the docs?
Or backporting the less strict JS code to webkit, but that's another kettle of fish :grinning:

I haven't found any docs or anything showing that PhantomJS forces strict mode. Do you have strict mode somewhere in your project?


첫 로그인 시 계정 비밀번호 변경을 위한 새로운 GraphQL mutation 구현

이슈 설명:
계정 보안을 강화하는 일환으로, 모든 계정이 처음으로 로그인 시 비밀번호를 변경하도록 할 필요가 있습니다. 이렇게 하면 디폴트 비밀번호가 첫 로그인 즉시 교체되므로 남용될 위험이 최소화됩니다.
이 요구사항을 구현하기 위해, 새로운 GraphQL mutation인 sign_in_with_new_password(username: !String, oldPassword: !String, newPassword: !String)를 추가합니다. 이 mutation은 사용자의 username과 oldPassword를 사용하여 사용자를 인증하고, 데이터베이스에 저장된 Account의 password 필드 값을 newPassword로 바꾸고 last_signin_time 필드를 갱신해야 합니다. oldPassword와 newPassword는 서로 달라야 합니다.
또한, 계정이 한 번도 로그인한 적이 없는 경우 로그인 시도를 받아들이지 않도록 기존의 signIn mutation을 수정해야 합니다.
구현 전:
signIn mutation은 사용자가 이전에 로그인한 적이 없더라도 로그인 시도를 받아들입니다.
구현 후:

첫 사용자가 로그인을 시도합니다.
signIn mutation은 last_signin_time이 None인 경우 로그인 시도를 거부합니다.
사용자는 sign_in_with_new_password를 사용하여 로그인하고 동시에 비밀번호를 변경합니다.
sign_in_with_new_password mutation은 사용자를 인증하고, password와 last_signin_time을 업데이트하고, AuthPayload를 리턴합니다.

요청인: @sehkone

@sehkone in https://github.com/aicers/review-web/pull/291#issuecomment-2385672834:

since requiring users to change their password at the first sign-in is still inconvenient, I think it would be better to make this optional based on a command line option or another approach. Could you suggest your idea on this?

I'd like to clarify that requiring users to change their password at the first sign-in was actually one of the original requirements you proposed. The wording was: "[...] forces the new user to change its password when signing in for the first time." Has this requirement changed?
Regarding your suggestion to make this optional, I have some concerns. While I understand that it may be inconvenient for users to change their password at the first sign-in, I don't think that's a strong enough argument to compromise on security. Security measures often come with a trade-off in convenience, but that doesn't mean we should make them optional.
Providing an option to choose between a secure and insecure practice can lead to users choosing the insecure option, which can have serious consequences. If a customer's system is compromised due to an unchanged initial password, it could damage ClumL's reputation and publicity.
I think it's better to stick with the original requirement and ensure that users change their password at the first sign-in.

@sehkone in #291 (comment):

since requiring users to change their password at the first sign-in is still inconvenient, I think it would be better to make this optional based on a command line option or another approach. Could you suggest your idea on this?

I'd like to clarify that requiring users to change their password at the first sign-in was actually one of the original requirements you proposed. The wording was: "[...] forces the new user to change its password when signing in for the first time." Has this requirement changed?
Regarding your suggestion to make this optional, I have some concerns. While I understand that it may be inconvenient for users to change their password at the first sign-in, I don't think that's a strong enough argument to compromise on security. Security measures often come with a trade-off in convenience, but that doesn't mean we should make them optional.
Providing an option to choose between a secure and insecure practice can lead to users choosing the insecure option, which can have serious consequences. If a customer's system is compromised due to an unchanged initial password, it could damage ClumL's reputation and publicity.
I think it's better to stick with the original requirement and ensure that users change their password at the first sign-in.

I apologize for the confusion in my argument. What I meant by "inconvenient" refers not to the general users but to our developers and testers. As for the users, as you mentioned, we need to stick to the requirements. I just hope that our internal team can save time on testing.

Thank you for the clarification, and I understand the need to streamline the process for developers and testers.
Rather than introducing a command-line option that might compromise security in the shipped binary, I propose creating a separate binary target within the review-web crate specifically for internal use. This binary would modify the database to set up test accounts and other necessary configurations. This internal tool will not be part of the shipped product, keeping security intact for our end-users. Does this approach sound reasonable to you?

Thank you for the clarification, and I understand the need to streamline the process for developers and testers.
Rather than introducing a command-line option that might compromise security in the shipped binary, I propose creating a separate binary target within the review-web crate specifically for internal use. This binary would modify the database to set up test accounts and other necessary configurations. This internal tool will not be part of the shipped product, keeping security intact for our end-users. Does this approach sound reasonable to you?

I agree with you on the separate binary target. If we proceed with that, I hope it will be incorporated into the central manager rather than the review-web.
On the other hand, while I am reconsidering, it occurs to me that this feature—enforcing a password change—likely won't be troublesome enough to bother our team significantly. The change only needs to happen once when the manager server is fully initiated, which doesn’t seem to take place very often. Therefore, I think it would be better to go ahead with this feature and see how it works out.
Thank you for your advice.


feat: add joerdav/xc

joerdav/xc: Markdown defined task runner
$ aqua g -i joerdav/xc

How to confirm if this package works well
Reviewers aren't necessarily familiar with this package, so please describe how to confirm if this package works well.
Please confirm if this package works well yourself as much as possible.
Command and output
$ xc --help
xc <task> [inputs...]
  Run a task from an xc compatible markdown file.
  If -file is not specified and no README.md is found in the current directory,
    xc will search in parent files for convenience.
  -f -file <string>
        Specify a markdown file that contains tasks (default "README.md").
  -md
        Print the markdown for a task rather than running it.
  -H -heading <string>
        Specify the heading for xc tasks. (default "Tasks")

xc
  List tasks from an xc compatible markdown file.
  If -file is not specified and no README.md is found in the current directory,
    xc will search in parent files for convenience.
  -s -short
        List task names in a short format.
  -h -help
        Print this help text.
  -f -file <string>
        Specify a markdown file that contains tasks (default "README.md").
  -H -heading <string>
        Specify the heading for xc tasks. (default "Tasks")
  -version
        Show xc version.
  -complete
        Install completion for xc.
  -uncomplete
        Uninstall completion for xc.
  -y    Don't prompt user for typing 'yes' when installing completion.

Thank you always!


OperationID considered breaking changes?

Describe the bug
Changes in operation ids are considered breaking API changes
To Reproduce
Steps to reproduce the behavior:

Generate 2 specs with the same API but differing operation ids

Expected behavior
No breaking changes should be found

Fixed by https://github.com/Tufin/oasdiff/pull/98
Note that changes to "OperationID" will be considered non-breaking both under Methods and under Links.
Please confirm whether this makes sense to you.

Well, that was quick! Yes that makes sense to me.


"Bradu" is listed in the drop-down menu

Description:
"Bradu" is listed in the drop-down menu alongside its corresponding county and commune, according to the law
Precondition:
The website is up an running.

Fixed! Poti sa retestezi


Swipe to remove tokens can be accidentally and easily triggered

Hi. First thanks for this awesome piece of software it is a delight to use :-).
The latest update sure did brought welcomed new features but one major thing that's bothering me though is how easy it is to remove a token. As careless as I am I've unintentionally triggered it few times already, and every time it's an "oh sh*t" moment.

@baldover Thanks for the feedback, the Action Sheet confirmation was intended to prevent accidental removal but maybe there are still improvements that can be made here.

@baldover are you referring to iOS or iPad? I see we only have the action sheet confirmation for iOS.

The message that pops up to say ‘remove token’ could include name of token requesting delete, just for extra confirmation as tiles slide over extremely fast

I think here are a few issues here.

The main one is that the "swipe right" action that triggers the delete is FAR too sensitive. You only need to slightly move your finger and it goes into delete mode.
When going into delete mode, the card flies off the screen far too quickly, and it appears the item is already deleted before the confirmation popup.  The delete action should work like other stock IOS apps, where the "delete" button is slowly revealed during the swipe, and the card stays on the screen until deleting is completed. The card should not fly off the screen like this, and the delete action should not be triggered until the swipe goes at least 33% across the screen. Just look at how other standard IOS apps work, like Notes or Stocks.
In other IOS apps, the delete action is triggered by swiping left, not right, so this conflicts with how people are used to deleting things.

Thank you for your comments @orev, I agree with most of them. I would like to switch the tokens listing(TokensViewController) layout to use a table view controller, instead of a collection view controller. The table view controller provides functionality to enable the swipe gesture behavior you see in standard iOS apps like Mail, Messages, and Notes.

I second this request that the swipe-to-remove interaction be reconsidered. Removing tokens is a very rare interaction, and should be extremely difficult to do accidentally.
It could be something like long-press, then multiple confirmations. At the very least, the swipe sensitivity should be double-checked. It is much more sensitive than similar swipe-to-archive interactions in other programs. An option to undo the deletion should be available as well, rather than just having the entry disappear.
The penalty for accidentally removing one of these is possibly-permanent loss of access to the account you're accessing.
Thanks.


Bug: Votes in modal are out of order after 1 min

The votes should be ordered from newest to oldest. Currently as seen above they go from oldest to newest. This does not occur when they are seconds old, only when they turn to minutes in age.
Check the res from getVotes which is seeding the table. See if they are in order or not. If they are, then it is a front end issue.
If they are not, then check turbosrc-engine/lib/getVotes to see if they are being selected from the Postgres table in the correct order.

Closed with PR #96 merge.


Too many MQTT messages.

The idea of the project is great.
However, it's very message intensive and that demands a lot of the broker. It's causing my broker to slow down for the rest of my devices.
I propose having a batch topic, that we could send one message containing several topics and values, much like the Tasmota Backlog command.
A simple JSON would suffice, like so:
{
	"command": "dim=50",
	"command/page": 1,
	"command/p[1].b[4].txt": "Lamp On"
}

This is an interesting idea and I'll look into it further.  The latest release of the Arduino code + Home Assistant automations may resolve a lot of the MQTT traffic you're seeing, so I'd make sure you're running the latest automations and that will likely address your current problems.
Still, I think sending a JSON over with a set of commands it interesting and warrants further investigation.  Thanks for the suggestion!

This has been added in version 0.33 using a JSON array instead of objects, as key:value doesn't really make sense here.  Documentation here.


Refactor KDTree to avoid captured block

This will allow to break inside #each_neighbor and easily implement #any_neighbor?, etc.

Check https://observablehq.com/@deamonpog/k-d-trees-non-recursive-array-based and https://github.com/raptorswing/QKDTree for iterative impl.


upgraded jquery to version 1.11.0

Aaron Grant will be sending you my ICLA. thanks.

@Josh31415 @asgrant Any update on the ICLA?

@ChristianMurphy @Josh31415 we sent this probably 5-6 times via FAX. I haven't had this issue ever before for our devs. Not sure what is going on.


w2v.similarity() returns wrong result

This function seems returns the dot product of two vectors instead of cosine similarity of the vectors.

A cosine similarity is a dot product divided by the product of norms.

w2v.similarity([0.1],[0.1])
0.010000000000000002
w2v.similarity([0.01],[0.01])
0.0001
w2v.similarity([0.02],[0.01])
0.0002

Issue seems to be at calc.js line 43, it just calculate the dot product and didn't divided by the product of norms.
......
  var sum = 0;
  for (i = 0; i < v1.length; i++) {
    sum += v1[i] * v2[i];
  }
  return sum;
......

Hello @hzhengran,
This function is mean to calculate the vectors returned by getVector function, which has already been normalized :) You can check more at the source code from google it self and I have some comment at L108, L111, L130, L189. Thanks.

Thanks for the quick response!
However, when i tried to calculate two vectors' similarity, i got a number as below:
w2v.similarity(v,v)
180.05311423395676

To my understading the similarity value should be between 0 and 1. So could you suggest how can I get the right result with this function?

And if i try to get the similarity of two vectors with same value, the result is not 1.
var v1 = v2 = [A 300 dimension vector]
w2v.similarity(v1,v2)
0.10785282179660252


more setting request

Could you please add some settings as below config?
Because I have no idea to forward my site to my back-end  https server? --> proxy_pass https://x.x.x.x/;.
I just modify the config file as below for make my site work now.
   location / {
	proxy_pass https://x.x.x.x/;
	proxy_http_version      1.1;
        proxy_set_header Connection "";
	proxy_read_timeout      360;
	proxy_pass_header       Date;
	proxy_pass_header       Server;
	proxy_pass_header       Authorization;
	proxy_set_header        Host $host;
	proxy_set_header        X-Real-IP $remote_addr;
	proxy_set_header        X-Forwarded-For  $proxy_add_x_forwarded_for;
	proxy_pass_request_headers on;
	proxy_set_header Accept-Encoding "";
	proxy_request_buffering off;
	proxy_buffering off;
	#proxy_set_header Connection "Keep-Alive";
	}

Many thanks.

Perhaps the advanced configuration should by default show the entire server { } configuration contents, just automatically generated, and the variables from the first tab provided as $variables?
(so basically move the location / { } to the advanced configuration by default?)
As long as nobody goes to the advanced tab, it's still simple to use, but also more powerfull for more experienced users?
So far i've been able to do the websockets for most scenarios, except now for mosquitto. Where the root seems to be the websocket path.

Yep I considered that as an option. In your case, it might be worth adding a option to enable websocket upgrades for the entire site, as the quickest solution. I've been considering that anyway and no reason why both ideas can't co-exist. I'll look in to it in a week

This doesn't solve the original issue, but I've added another setting for Proxy Hosts in version 2.0.3 for any hosts that need websocket upgrades. Just turn on "Allow Websocket HTTP Upgrades" and hopefully everything works without the need for advanced config.

Thanx for cool software!
It would be nice to haveproxy_set_header option X-Forwarded-For with value $proxy_add_x_forwarded_for;. Now it's hardcoded to $remote_addr, so I need to override with Advanced configuration. This option is pretty common when you want to serve different domains/subdomains on same ip with same server behind proxy. Thanx!

Thanx for cool software!
It would be nice to haveproxy_set_header option X-Forwarded-For with value $proxy_add_x_forwarded_for;. Now it's hardcoded to $remote_addr, so I need to override with Advanced configuration. This option is pretty common when you want to serve different domains/subdomains on same ip with same server behind proxy. Thanx!


Cannot read property 'split' of undefined

My code: following the documentation to the dot. Can't figure out what the error is.
 function ImageSubmit(event){ 		console.log(event.target.files[0]) 		let file = event.target.files[0].name 		S3Client.uploadFile(file)	     		.then(data => console.log("X", data))     		.catch(err => console.error(err)) }
My error:

index.js:1 TypeError: Cannot read property 'split' of undefined
at s.uploadFile (aws-s3.js:1)
at ImageSubmit (AddCarPage.js:72)
at HTMLUnknownElement.callCallback (react-dom.development.js:336)
at Object.invokeGuardedCallbackDev (react-dom.development.js:385)
at invokeGuardedCallback (react-dom.development.js:440)
at invokeGuardedCallbackAndCatchFirstError (react-dom.development.js:454)
at executeDispatch (react-dom.development.js:584)
at executeDispatchesInOrder (react-dom.development.js:609)
at executeDispatchesAndRelease (react-dom.development.js:713)
at executeDispatchesAndReleaseTopLevel (react-dom.development.js:722)
at forEachAccumulated (react-dom.development.js:694)
at runEventsInBatch (react-dom.development.js:739)
at runExtractedPluginEventsInBatch (react-dom.development.js:880)
at handleTopLevel (react-dom.development.js:5803)
at batchedEventUpdates$1 (react-dom.development.js:24401)
at batchedEventUpdates (react-dom.development.js:1415)
at dispatchEventForPluginEventSystem (react-dom.development.js:5894)
at attemptToDispatchEvent (react-dom.development.js:6010)
at dispatchEvent (react-dom.development.js:5914)

Same here. Did you find any workaround ?

@codeghees I have this issue too.
Did you solve it?

Yeah - I was sending just the name - send the entire object.
@sarykemmoun2

can you please help me solving this as well ? i am getting the same error cannot read property split of undefined


add_variable vs add_weight

add_variable is termed as an alias to add_weight. Is there any particular reason behind this API?
https://github.com/keras-team/keras/blob/327360e617771d4f34e2b4bf4810ed8b413709bb/keras/layers/layer.py#L423

It is a bit confusing, but essentially variables are a super set of weights, that contain other variables that will be compiled (at least on some backends) but are not trainable floats.
In particular, jax random seeds are state, that must be passed explicitly to any jax compiled function. These are not trainable floats, so you would not want them in model.weights, but we do need an way to gather all state to pass to a jax compiled function, and model.variables is that.

That is super helpful!
Do you think we should document this inside of the docstrings from the method?

Improving docs sounds good. We don't want to get overwhelmingly detailed, but do want to give users the right mental model. Currently we have
https://github.com/keras-team/keras/blob/aa055387f27d974a9a7a3eed8fdd9a2f2e589b6b/keras/layers/layer.py#L538-L545
https://github.com/keras-team/keras/blob/aa055387f27d974a9a7a3eed8fdd9a2f2e589b6b/keras/layers/layer.py#L586-L589
Though it looks like this is not yet all on keras.io

I believe the issue has been concluded. Feel free to reopen if you have more questions.
Thanks!


TPM persistent key support

Add support for persistent TPM keys

Can you please update PR summary with a little more detail for those of us who aren't terribly familiar with TPM?


/gpushare-scheduler/bind returns 500 when enableServiceLinks is set to false

version: Kubernetes 1.13
/gpushare-scheduler/bind returns 500 when enableServiceLinks: false is set in deployment yaml.
Log:
"Error":"Pod "test-gpushare-7f5965c889-wkgkp" is invalid: spec: Forbidden: pod updates may not change fields other than spec.containers[*].image, spec.initContainers[*].image, spec.activeDeadlineSeconds or spec.tolerations (only additions to existing tolerations)

The problem is caused by inconsistent API versions for client (v1.11) & apiserver (v1.13). Upgrading https://github.com/AliyunContainerService/gpushare-scheduler-extender/blob/master/vendor/k8s.io/api/core/v1/types.go can solve it.


runInLinuxVM combined with runCommand fails

Issue description
The pattern of combining pkgs.vmTools.runInLinuxVM and pkgs.runCommand fails with the error "variable $src or $srcs should point to the source".
Bisected to pull request #15803
Looks like passAsFile is not supported when using runInLinuxVM.
A quick work around is to add "passAsFile = []" to overrides applied by runInLinuxVM.
Steps to reproduce
with (import <nixpkgs> {});
with lib;

pkgs.vmTools.runInLinuxVM (pkgs.runCommand "boo" {} ''
  ${concatMapStringsSep "\n" (i: "echo baaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa") (range 1 30000)}
'')

fails with
these derivations will be built:
  /nix/store/j49h6c22v7np02jszgs9gd332nk61382-boo.drv
building path(s) ‘/nix/store/r9pp9yw5x2vr8l5l8q9kgpnb5wqb38k7-boo’
WARNING: Image format was not specified for '/dev/null' and probing guessed raw.
         Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
         Specify the 'raw' format explicitly to remove the restrictions.
loading kernel modules...
mounting Nix store...
mounting host's temporary directory...
starting stage 2 (/nix/store/a2v2srhngnjlhy79smi7x383pay272ry-vm-run-stage2)
unpacking sources
variable $src or $srcs should point to the source
[    1.437850] reboot: Power down
builder for ‘/nix/store/j49h6c22v7np02jszgs9gd332nk61382-boo.drv’ failed with exit code 1
error: build of ‘/nix/store/j49h6c22v7np02jszgs9gd332nk61382-boo.drv’ failed

Technical details

System: 16.09.git.12516d7
Nix version: nix-env (Nix) 1.11.2
Nixpkgs version: "16.09.git.a69199d"

Huh, need to fix this properly.

I agree the proposed work around "passAsFile = []" is not a proper fix.
How about placing the files generated by passAsFile under /nix/store? AFAICT the generated files are currently temps under TMPDIR.  Placing the files under /nix/store would work with usages of runInLinuxVM; Those VMs mount the nix store in the same place on the VM as host.

It was worked around for now, but it should still get fixed properly.

Are there any updates to this issue, please?

Is my issue trying to build a config with colmena & woodpecker inside of a podman (nixos/nix) container related?
[ERROR]   stderr) sourcing setup hook '/nix/store/aazf105snicrlvyzzbdj85sx4179rpfp-set-source-date-epoch-to-latest.sh'
[ERROR]   stderr) sourcing setup hook '/nix/store/gps9qrh99j7g02840wv5x78ykmz30byp-strip.sh'
[ERROR]   stderr) Running phase: unpackPhase
[ERROR]   stderr) variable $src or $srcs should point to the source
[ERROR]   stderr) error: builder for '/nix/store/3yq8mb64gh3442ynb9w5h42f1xwiwcl6-NetworkManager.conf.drv' failed with exit code 1
[ERROR]   stderr) copying path '/nix/store/mraajssb5jr055cxhfb2r3nb7qhv5ai7-tremor-unstable-2018-03-16' from 'https://cache.nixos.org'.../
[ERROR]   stderr) copying path '/nix/store/c4pbw3viwryy1kr2cswb1v02bs66bhim-udev-rules' from 'https://cache.nixos.org'.../
[ERROR]   stderr) error: 1 dependencies of derivation '/nix/store/cwhbwid01xy1mysdch6mgyz8r69g5rfb-etc.drv' failed to build
[ERROR]   stderr) error: 1 dependencies of derivation '/nix/store/cczdwbcpi5bbb8zcqv52adaw60p9mlb9-nixos-system-nhqih-misc-24.11pre-git.drv' failed to build
[ERROR]  failure) Child process exited with error code: 100
[ERROR] -----
[ERROR] Operation failed with error: Child process exited with error code: 100
Hint: Backtrace available - Use `RUST_BACKTRACE=1` environment variable to display a backtrace


Many Emoji Slows/Crashes App

Summary
If you insert many emoji in messages (thing enough to fill the screen) it will cause the app to freeze up and sometimes even crash. In my testing, each emoji was different and not the same.
Environment Information

Device Name: LG G6
OS Version: Android 8.0
Mattermost App Version: 1.13.0 (Build 151)
Mattermost Server Version: 5.4.0

Steps to reproduce
Insert ALOT of emoji into the chat, preferably all different emoji and enough to entirely fill the screen. Once this is done close the app and then re-open it to the channel where the emoji are located, the app will freeze or completely crash
Expected behavior
App should continue working correctly.
Observed behavior
Freezes/Crashes the app
Possible fixes
Unknown

Thank you @tankerkiller125,
This is a React Native issue, and we are planning to submit an Issue in their repo in the upcoming days.

Filed an issue in the react-native repo: https://github.com/facebook/react-native/issues/22038

Closing this Issue as this can be followed via react native,


Field dot notation does not seem to work.

I have the following fields specified:
"fields": ["_id", "info"]
and receive the following as a result against a local PouchDB:
{
   "_id":"85-somedude-1456174210512",
   "info":{
      "zeeId":"85",
      "lastUser":"somedude",
      "lastSaved":"2016-02-23T18:12:06.389Z",
      "version":"0.1.0",
      "id":0
   }
}

"info" is an object with multiple properties on it and the entire object is returned. That's what I would expect.
When I try to do this, against the same PouchDB:
"fields": ["_id", "info.lastSaved"]
I don't get anything except "_id":
{
    "_id":"85-somedude-1456174210512"
}

Yes, it doesn't work, eventually you can query only by "_id" and then use javascript filter function to select "info.id"

Is there a test for this in the test suite?

This is the offending function: https://github.com/nolanlawson/pouchdb-find/blob/master/lib/utils.js#L142
It has no support for dot notation. I'll take care of it over the next few days and do a PR with test added.

OK, I've got this fixed. But the tests from master are a mess and are failing all over the place. We need to get these working so I can verify that my PR doesn't break anything.

I have a branch and PR for the test fixes. But I'm waiting for some bug fixes in mango first.
All misspelling thanks to my iPhone

On 20 May 2016, at 12:35 PM, Colin Skow<EMAIL_ADDRESS>wrote:
OK, I've got this fixed. But the tests from master are a mess and are failing all over the place. We need to get these working so I can verify that my PR doesn't break anything.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

Shall I submit the PR anyway? I've unit tested it manually and it seems to work fine.

Yes please that would be awesome. But we will probably only be able to merge once we fixed master.
All misspelling thanks to my iPhone.
On Fri, May 20, 2016 at 3:57 AM -0700, "Colin Skow"<EMAIL_ADDRESS>wrote:
Shall I submit the PR anyway? I've unit tested it manually and it seems to work fine.
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

fixed in https://github.com/nolanlawson/pouchdb-find/pull/189


Streaming example is not streaming

This example specifically talks about how streaming reduces the demands for memory or disk space when uploading large files.
The section Upload large files with streaming shows code calling FileHelpers.ProcessStreamedFile. That code creates a MemoryStream and copies the entire source stream into it. At the end it creates another copy of the stream by calling ToArray().
Maybe I did not understand the purpose of this example but it seems to do the exact opposite of what the article tries to communicate and I therefore highly recommend that this (part of the) article is corrected or removed.

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

ID: 9a5cfa38-0e6c-4346-dafc-84ea5c513fcf
Version Independent ID: c6787f0f-3e9a-6efb-0e6e-5ccb957d3f4a
Content: Upload files in ASP.NET Core
Content Source: aspnetcore/mvc/models/file-uploads.md
Product: aspnet-core
Technology: aspnetcore-mvc
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

Hello @double-bee ... That's because the word "stream"/"streaming" is overloaded. Streaming in this context refers to how the file is broken up into sections and processed by the server ...
https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/mvc/models/file-uploads/samples/3.x/SampleApp/Controllers/StreamingController.cs#L84
The "stream" (MemoryStream in this case) in the server's helper class is for processing each section and isn't a factor in the overall concept of "streaming" the file to the server.


How to open .txt files in python using spyder ide

Issue Report Checklist

[ ] Searched the issues page for similar reports
[ ] Read the relevant sections of the Spyder Troubleshooting Guide and followed its advice
[ ] Reproduced the issue after updating with conda update spyder (or pip, if not using Anaconda)
[ ] Could not reproduce inside jupyter qtconsole (if console-related)
[ ] Tried basic troubleshooting (if a bug/error)

[ ] Restarted Spyder
[ ] Reset preferences with spyder --reset
[ ] Reinstalled the latest version of Anaconda
[ ] Tried the other applicable steps from the Troubleshooting Guide

[ ] Completed the Problem Description, Steps to Reproduce and Version sections below

Problem Description
What steps reproduce the problem?

What is the expected output? What do you see instead?
Paste Traceback/Error Below (if applicable)

PASTE TRACEBACK HERE

Versions

Spyder version:
Python version:
Qt version:
PyQt version:
Operating System name/version:

Dependencies

PASTE DEPENDENCIES HERE

Just write in a terminal
spyder a.txt

That's all that's needed.

Thank you  for your help
On Tue, Apr 7, 2020, 9:18 PM Carlos Cordoba<EMAIL_ADDRESS>wrote:

Closed #12204 https://github.com/spyder-ide/spyder/issues/12204.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/spyder-ide/spyder/issues/12204#event-3210497120, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AM24FO4PFU42GWAWKQXOJHDRLNDMRANCNFSM4MDFPW6A
.


Added a settings variable to enable/disable the user delete method

Today I have realized that you can change the permission settings in the djoser settings to achieve the same results, but somehow my permission does not work.
Here I want only allow staff users to use the delete method for users. For testing, I have created a normal user and try to delete with the same account. With changed permissions this shouln't work. But the non-staff user was able to delete himself.
# main.permissions.py
class OnlyAdminPermission(permissions.BasePermission):
    def has_object_permission(self, request, view, obj):
        user = request.user
        return user.is_staff

# settings.py
DJOSER = {
    # "USER_DELETE_DISABLE": True,
    'PASSWORD_RESET_CONFIRM_URL': '#/password/reset/confirm/{uid}/{token}',
    'PERMISSIONS': {
        'user_delete': ['main.permissions.OnlyAdminPermission'],
    }
}
```
First I thought that my permission is not loaded correctly, but I used breakpoints in the djoser source code and saw that my permission is used during the delete method.

Hope someone can help me.


Integration fails when IP address changes

For some reason, my Daikin system seems to get allocated a new IP address on my network every now and then (typically lasts a few weeks). When this happens, the sensors become unavailable, and after a restarting HA the integration then shows “Failed to set up”. The error log shows that it is trying to communicate to an IP address which I can tell is not responding to a ping. This has happened many times for me, and the solution is always to remove the integration, restart, and let it find the integration again. When this happens, it finds the new IP address no problem and it’s all back to normal and works perfectly fine again. However, I’d like to not have to do this every few weeks, and it would be better if it were able to recover itself in such a scenario.
Debug log below…
Logger: homeassistant.config_entries
Source: config_entries.py:406
First occurred: 12:28:15 (1 occurrences)
Last logged: 12:28:15
Error setting up entry Daikin HVAC controller (222xxxxxx) for daikin_altherma
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/aiohttp/connector.py", line 992, in _wrap_create_connection
return await self._loop.create_connection(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/asyncio/base_events.py", line 1085, in create_connection
raise exceptions[0]
File "/usr/local/lib/python3.11/asyncio/base_events.py", line 1069, in create_connection
sock = await self._connect_sock(
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/asyncio/base_events.py", line 973, in _connect_sock
await self.sock_connect(sock, address)
File "/usr/local/lib/python3.11/asyncio/selector_events.py", line 628, in sock_connect
return await fut
^^^^^^^^^
File "/usr/local/lib/python3.11/asyncio/selector_events.py", line 668, in _sock_connect_cb
raise OSError(err, f'Connect call failed {address}')
OSError: [Errno 113] Connect call failed ('<IP_ADDRESS>', 80)

I would suggest to set static IP in the router but if it is not possible, then at this time, you can use "dirty hack" as described here
tip: if you are using nano then you can use ctrl + w to search for the word daikin.


Emoji's are not visible in many websites.

Issue(s):

[x] Whitelist
[x] Blacklist
[x] Website Broken

Pack(s):
Write the name of the pack(s) you are using.

Pack(s) Name: Ultimate

Extension(s):
Also name the extension(s) if you are using any. If you don't then leave it blank.

Extension(s) Name:

Domain(s):
If you are submitting this issue for whitelist/blacklist issue, send us the domain(s) for whitelisting/blacklisting here. Kindly use the Code Tag to prevent tracking.

Domain(s): https://forum.xda-developers.com/android/software-hacking/keweon-privacy-online-security-t3681139

Your Config:
Just to ensure there is no issues or conflicts with other app/software/magisk module/extension/source list.
Make sure you are running Energized Protection Service only.

Client: Hosts/ Hblock with only one source ie energized ultimate

Version: latest

Details:
Write us a lil bit more about your issue or query. You can attach any screen shot or log of the issue or advert, this will help to highlight it.

Your Issue Detail:
Emoji's are not visible. They appear as square boxes. And it's not the fault of my unicode or any font since it starts appearing only after I enabled it in my hosts.

https://forum.xda-developers.com/android/software-hacking/keweon-privacy-online-security-t3681139
visit this and scroll down. Things like bullets have turned into square boxes.
Even the emoji's Grammarly extension uses are not working.

Thank you for making Energized Protection great with your kind help!

I couldn't reproduce this issue either. Emojis dont seem to work for me either way. It doesn't show up even if I turn off the uBlock. (Only on KeWeOn thread, I have checked) But emojis are working for me on other site. Can you send another website where you are facing the same issue?

it was my fault. since other than this keewon website, every other thing was fixed by the additional install of emoji-ttf font from AUR.


add php8 support

Add support for PHP 8.0
#422

@stof, any update?

Any update on this?

Friendly ping @stof
Do you have some time to look at this PR ?
Are you looking for maintainer to help you ?
Take care

Friendly ping @stof
Do you have some time to look at this PR ?
Are you looking for maintainer to help you ?
Take care

@stof could you please accept this PR? This is the only library keeping most of us from upgrading our projects to PHP 8.0.

@stof could you please accept this PR? This is the only library keeping most of us from upgrading our projects to PHP 8.0.

It's strange - there is ready PR, without any reaction.
I've just removed StofDoctrineExtensionsBundle from my projects and managed all functionality by myself. Now my projects are PHP8.0 compatibile... But it is not right way...

It's strange - there is ready PR, without any reaction.
I've just removed StofDoctrineExtensionsBundle from my projects and managed all functionality by myself. Now my projects are PHP8.0 compatibile... But it is not right way...

@derrabus Can you accept this PR or contact @stof?

@derrabus Can you accept this PR or contact @stof?

@derrabus Can you accept this PR

I don't have permissions on this repo.

@derrabus Can you accept this PR

I don't have permissions on this repo.

Is it possible to tag a new release @stof ? :)

@VincentLanglet Stof hasn't replied for more than a month here. I've tried multiple ways to contact him. See #422 for more information. I even contacted someone from the Symfony Core Team (since symfony.com recommends this bundle), but they're not responsible for third-party bundles. That's why I propose to remove this bundle from the Symfony documentation: https://github.com/symfony/symfony-docs/pull/14909

@stephanvierkant hi, you're able to use my fork

Thanks! I see it's a popular fork, well done! I think it's in our shared interest to have a well-maintained and community-driven bundle, so feel free to create a PR in symfony/symfony-docs to replace Stof's bundle by your fork. And let's be clear about the maintainers, to prevent having the same issue (a bundle that depends on a single person) ever again.

I would recommend just to use that gedmo library directly - it's super easy to use with Symfony 4.x+ - https://github.com/doctrine-extensions/DoctrineExtensions/blob/main/doc/symfony4.md


ERROR FF10284 when invoking create asset

API Endpoint:
{{baseUrl}}/invoke/CreateAsset
Error response:
{
    "error": "FF10284: Error from fabconnect: %!!(MISSING)s(<nil>)"
}

same here, did you find what leads to it?


RE3 - Room 402 cutscene freezes the game

Version
3.1.1 (1e8850a)
Seed
R730-B3KX-ZXHM0HXZ9Y000ZJZZZZZZZZZZZZZZZZZZZZZZZZZZZ
Scenario
RE 1 (Chris)
Player Character
Annette RE2 Remake
What happened?
Reached room 402 (Hospital Entrance). Zombie cutscene played out, he was killed by an invisible enemy, and then freeze. Music still plays, but the cutscene wont finish.

Duplicate of #550


Validators for Query Parameters

Information
I would like to have validators for query parameters like there are for body parameters
Describe the solution you'd like
import { Controller, Get, QueryParams, Maximum, Minimum } from "@tsed/common";

@Controller('/test')
export class TestCtrl {
  @Get('/')
  test(@Maximum(10) @Minimum(1) @QueryParams() test: number) {}
}

Current Error: [ERROR] [TSED] - TypeError: Cannot read property 'mapper' of undefined

@tomer-amir Validation on params isn't available (excepted for required). I work on this evolution.

It will also be nice if the swagger will reflect that

It will be supported also. The work is around the jsonschema package itself.
My work about this feature is in progress ^^.

v6 support this feature :) #619


Bug:Mac版创建数据库连接时选择Redis白屏

Chat2DB Version
v2.0.13
Describe the bug
Mac版创建数据库连接时选择Redis白屏

Redis is not supported right now, will support in future. move to #402


xargs: memory exhausted

Thanks for an awesome thing. :smile:
I got some errors while apt-get upgrade:ing to a more recent Ubuntu version (wily):
Preparing to unpack .../libpython3.4-stdlib_3.4.3-9ubuntu1_amd64.deb ...
xargs: memory exhausted
awk: cmd. line:1: (FILENAME=- FNR=211) fatal: print to "standard output" failed (Broken pipe)
Unpacking libpython3.4-stdlib:amd64 (3.4.3-9ubuntu1) over (3.4.3-1ubuntu1~14.04.3) ...

(The same error appeared multiple times, for different packages.)

Probably the same as #92

It's known issue, related to: #14
Ms is working on fix.

I submitted a fix for this issue into our dev branch today and it should be in a Windows Insider Fast Ring build in a few weeks.  Keep an eye out on the release notes, I'll make sure we call out the fix for xargs.

Fixed in build 14361.


[Adaptive] ForEach should be able to traverse object keys

Version
4.12.x
Describe the bug
At one point, Microsoft.Foreach used to accept iterable objects. This was removed, but provide quite a bit of utility and should come back.
Expected behavior
I want to be able to provide Microsoft.ForEach an object as an import and traverse its keys and have access to the key and the value for additional computation.

@boydc2014 to investigate.

Microsoft.Foreach doesn't support iterating on object, it was the built-in foreach function that support object. So re-label this as a feature request.

This has more details on how to do this. https://github.com/microsoft/botbuilder-dotnet/issues/5619


Add support for custom import handlers

Abstract
Provide a mechanism to let developers define custom import handlers to allow typesafe imports of different file types.
Problem
import at this time exclusively handles ts/js module imports. Importing non-modules, e.g. css (for css-modules usage) or json files, currently requires workarounds with potentially huge drawbacks: Statically creating a .d.ts for each file, or using a require declaration returning any.
    // examples using webpack css-loader in module mode
    import * as styles from "./style.css" // requires static style.css.d.ts
    const styles = require<any>("./style.css") // not type-checked

Proposition
Provide a mechanism to define import handlers for specified file extensions. This handler will be supplied with the path of the file to be imported, and shall return a valid declaration - from the scripts perspective, a custom import should behave like a regular typescript module import.
The handler could exist as a single script or a node module.
Advantages
The proposed addition opens up the possibility for developers to implement typesafe usage of loaders when using module bundlers like webpack. Additionally, it could enable the development of more flexible build pipelines that don't rely on preceding transpilation.

This has already been resolved with ambient wildcard module declarations. Unfortunately this does not validate the existence of the target but it allows you to specify the types of the values produced by the loaders and bundlers that operate over them.
Workarounds like creating individual .d.ts files were annoying and cumbersome to maintain, what are no longer necessary thanks to this new feature in 2.0.
declare module '*.html' {
  export default '';
}

What does does not do is intertwine TypeScript with a specific tool, environment, or protocol. It is an abstract declaration and can even contain exotic AMD style plug-in syntax or synthetic directory structures.
I think this turned out really well.

For reference the issue is #6615

Indeed wildcard module declarations are a good solution for many cases, but they do not provide a typesafe mechanism on a individual file basis. This would be an option separate to wildcard module declarations. Staying with the css-modules example, a pluggable import handler could enable the type checker to catch the following error:
    .elem {/* css declaration */}

    import * as styles from "styles.css"
    let e = styles.elm // typo, styles.elm is not defined

What you are asking for is non trivial.  These import handlers would have to parse non-TypeScript files into some sort of AST that is understood by TypeScript.  That would require a whole syntactic language to describe how to parse files in other languages.
What we have been doing in @dojo, wanting to use CSS Modules, is creating a build step in our process to output a TypeScript module that contains the mapping of modular CSS classes into what is being generated when the CSS Module is transpiled.  We are also doing something similar with our internationalisation strings.
We are finding that dynamically generating TypeScript files is one of the easiest ways to have TypeScript understand "foreign" file formats.

These import handlers would have to parse non-TypeScript files into some sort of AST that is understood by TypeScript. That would require a whole syntactic language to describe how to parse files in other languages.

They would return a simple module declaration in string form, the same format that a matching .d.ts file would contain. Typescript would then consume this string like any other module.

We are finding that dynamically generating TypeScript files is one of the easiest ways to have TypeScript understand "foreign" file formats.

This is what the handler is supposed to do, merely avoiding the detour of writing the generated typescript to a file and instead passing the contents directly to the typescript service. It would have the advantage of providing the definition immediately to enable on-the-fly type checking and autocompletion.

I would recommend creating a tool that would generate a .d.ts file from the original file.
Building a whole set of custom module loading plugins, watching the source files, doing this on every edit would not be a salable solution.

I should also note this is already covered by https://github.com/Microsoft/TypeScript/issues/3136


Feature/improvements

Hello, Goswami! I'm working a lot on adapting your great library to fit the needs of my project (actually, I ended up importing this library as a module of my app, to make it easy for testing and etc). It would be great if you take a look on what I did. Maybe there's any idea that you can save. Thanks in advance.

I added an option to clean the data of the WebView before launching it, so that you "sign out" the user if you want, to allow them to log with different accounts;
I changed the "nextActivity" strategy by "startActivityForResult", because, in my app, the user will be prompted to login within the app, not in an inicial login screen;
I made some code refactoring;
And fix an issue that was occurring because the app was trying to handle the first link that the webView opens, but actually, that was a redirect link. So, I make the app check if the link contains "?code=" in it before try to handle.

Well, I made a lot of changes lol

great work, thank you


Update Worker to support concurrent predictions

PLAT-502.
This adds a max_concurrency parameter to Worker that allows it to accept
predictions while others are already in-flight.
I have removed the PROCESSING WorkerState; in concurrent mode, there is no
distinction between READY and PROCESSING because we might be able to accept a
prediction in either case.
Worker now keeps track of multiple in-flight predictions in a dictionary, keyed
on tag.  Tags are required if max_concurrency > 1.  Otherwise tags are
optional (and, if omitted, we store the prediction with tag=None).
There is one awkward place which is _prepare_payload().  As I understand it,
this synchronously downloads URLFiles, which will block us from processing any
other updates from the child while we download the URL.
Opening as draft as I have local test failures I don't fully understand - TestWorkerState is flaky, and the test_build integration tests are failing?!

Ok this is ready for review now I think I've got a handle on the tests

I pushed 27e35b4 to update the hypothesis tests to support concurrent prediction subscribers, and 3f25357 with PR feedback


Migrate to Rust edition 2021

Description
Migrates the libc crate to Rust edition 2021 with an automated script (after some initial manual adjustments).
Since ctest2 does not support crate:: in paths, a hack has been implemented in libc-test/build.rs, which makes a copy of src replacing every crate:: with ::.
cc https://github.com/rust-lang/libc/issues/3898

Sources

Checklist

[x] Relevant tests in libc-test/semver have been updated
[x] No placeholder or unstable values like *LAST or *MAX are
included (see #3131)
[ ] Tested locally (cd libc-test && cargo test --target mytarget);
especially relevant for platforms that may not be checked in CI

:umbrella: The latest upstream changes (presumably #4128) made this pull request unmergeable. Please resolve the merge conflicts.

Thanks! It is pretty unfortunate that the hotfix is needed (ctest is quite limiting...) but I think that is okay for now.
Would it be possible to add popular imports to the top of these files and then drop the crate:: prefix? Not for everything of course, but it would be nice for the types that are used everywhere (all c_* types, Ioctl, size_t, ssize_t, anything else that is used somewhat commonly).

Alsocargo fix works with --target if you're up for just doing rustc --print target-list | xargs -ITARGET cargo fix --edition --target TARGET --allow-dirty (that's a bit too crude since some need build-std or downloaded targets and I don't expect every single target to actually work, but it should be possible to get everything that's in CI).
I'll also add a .git-blame-ignore-revs entry after this merges.

Would it be possible to add popular imports to the top of these files and then drop the crate:: prefix? Not for everything of course, but it would be nice for the types that are used everywhere (all c_* types, Ioctl, size_t, ssize_t, anything else that is used somewhat commonly).

Even with the help of automatic find-and-replace, that's going to be a pretty huge work considering the amount of modules where imports need to be added.

Cargo is aware of this right? Meaning if you put the import in the file, it will use that rather than adding the crate:: prefix. If so, it should be pretty easy:
# `rg -l` lists files containing the pattern, the `sed` command
# will add the import to the top of the file
# The imports will be ugly but I'll just make rustfmt fix that
rg -l "::c_int" src | xargs -IFILE sed -i '1s;^;use crate::c_int\n\n;' FILE
rg -l "::c_long" src | xargs -IFILE sed -i '1s;^;use crate::c_long\n\n;' FILE
# ... repeat for all relevant types

# fix commands
cargo fix ...

# run formatting
./ci/style.sh

Even if Cargo isn't aware it should be easy to sub out using the same rg command and replacing the sed pattern with s/::c_int/c_int/g.
Could you post the exact script you use to perform the automated step? Then have the commits in this PR be the following:

Add the testing hack
Any other setup, if applicable
Apply the automated commands from the script
Any hand cleanup, if applicable. (don't worry about updating the comments, so this can be smaller. Or I think you could do it in the script, duplicate the above rg | xarg sed commands and replace sed with with perl -pi -e 's/(?!\w)::(\w+)/$1/g')

This will make it easy to verify the changes (I can rerun step 3 and hash the files to make sure nothing machine-specific and wonky happened - we caught a rustfmt bug this way when we reformatted part of rust-lang/rust), to rebase when the time comes (just drop commit 3 and rerun the script) and to apply to libc-0.2 after this merges.
I am going to wait a couple days to merge this until it is possible to land a few changes that are nearly ready but would conflict with this, and also going to add rustfmt config so imports get grouped and sorted (meaning the output of the above script won't be horrible). So feel free to hold off on rebasing unless you're experimenting with the above, I'll let you know when I'm ready for this 👍

I'm seeing some weirdness:
If I add use crate::c_long; to src/unix/linux_like/linux/mod.rs, it fails to compile with
error[E0432]: unresolved import `crate::c_long`
 --> src/unix/linux_like/linux/mod.rs:3:5
  |
3 | use crate::c_long;
  |     ^^^^^^^^^^^^^ no `c_long` in the root

However, if I just change a use of ::c_long with crate::c_long anywhere in the same file, it compiles fine.
What's going on there? Is that a rustc bug?

Oh - I guess that's actually a new feature in 2018 https://doc.rust-lang.org/edition-guide/rust-2018/path-changes.html#the-crate-keyword-refers-to-the-current-crate. After the changes here, are you able to actually set the edition to 2018? Or are there other failures.

But use crate:: usually works on edition 2015 too, since it does not conflict with any previous syntax. If fact, use crate::c_int; works fine. It is with c_long where I'm getting errors.

Here's a repro - I guess you can't reexport something through a module and then also use it from the crate https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=e124499dd4f73870bdddd5e64eadfaf2, c_int is different because it's at a higher level.
I'm okay with just leaving the crate:: prefix on c_long and any others that give you problems, I'll figure out how to clean them up later (unless you feel like hacking at it). As long as we get most of the crate:: prefixes in the automated step so the diff isn't bigger than it needs to be.

Is there a reason not to use types from core::ffi?

The core::ffi types became stable in 1.64, which is beyond our current MSRV, and we can't use std for os::raw. This would be a good thing to change at the next MSRV bump though.

cargo fix does not seem to be that smart. It will change ::<type> to crate::<type> even if there is a use crate::<type>.
I'll try to hack some find-and-replace solution.

Well that's interesting, I thought it would know better. Here's one solution ((?<!\w) ensures the :: is not preceded by another word character, i.e. should match  ::foo but not crate::foo)
find src -name '*.rs' | xargs -IFILE perl -pi -077 -e \
    's/(?<!\w)::(c_[us]?char|c_double|c_float|c_u?int|c_u?longlong|c_u?short|ptrdiff_t|s?size_t|c_void|Ioctl|off_t|time_t)/$1/g' FILE

:umbrella: The latest upstream changes (presumably #4136) made this pull request unmergeable. Please resolve the merge conflicts.

:umbrella: The latest upstream changes (presumably #3978) made this pull request unmergeable. Please resolve the merge conflicts.

Now there are 3 commits instead of 4. The changes of the old third commit are now also handled by the script.

New script
#!/usr/bin/env bash

git restore Cargo.toml src

# Handle leading `::` in common types

implicit_c_long_ulong_char=(
  src/fuchsia/mod.rs
  src/solid/mod.rs
  src/unix/aix/mod.rs
  src/unix/bsd/apple/mod.rs
  src/unix/bsd/freebsdlike/freebsd/mod.rs
  src/unix/bsd/freebsdlike/mod.rs
  src/unix/bsd/netbsdlike/netbsd/mod.rs
  src/unix/bsd/netbsdlike/openbsd/mod.rs
  src/unix/bsd/netbsdlike/mod.rs
  src/unix/bsd/mod.rs
  src/unix/haiku/mod.rs
  src/unix/hurd/mod.rs
  src/unix/linux_like/android/b32/mod.rs
  src/unix/linux_like/android/b64/mod.rs
  src/unix/linux_like/android/mod.rs
  src/unix/linux_like/linux/gnu/b32/mod.rs
  src/unix/linux_like/linux/gnu/b64/aarch64/mod.rs
  src/unix/linux_like/linux/gnu/b64/x86_64/mod.rs
  src/unix/linux_like/linux/gnu/b64/mod.rs
  src/unix/linux_like/linux/gnu/mod.rs
  src/unix/linux_like/linux/musl/mod.rs
  src/unix/linux_like/linux/uclibc/mips/mod.rs
  src/unix/linux_like/linux/uclibc/mod.rs
  src/unix/linux_like/linux/mod.rs
  src/unix/linux_like/mod.rs
  src/unix/newlib/mod.rs
  src/unix/nto/mod.rs
  src/unix/mod.rs
  src/vxworks/mod.rs
)

for file in "${implicit_c_long_ulong_char[@]}"; do
  perl -pi -077 -e 's/(?<!\w)::(c_long|c_ulong|c_char)\b/$1/g' "$file"
done

implicit_off_t=(
  src/unix/linux_like/linux/gnu/mod.rs
  src/unix/linux_like/linux/mod.rs
  src/unix/linux_like/mod.rs
  src/unix/mod.rs
)

for file in "${implicit_off_t[@]}"; do
  perl -pi -077 -e 's/(?<!\w)::(off_t)\b/$1/g' "$file"
done

implicit_off64_t=(
  src/unix/linux_like/android/mod.rs
  src/unix/linux_like/mod.rs
)

for file in "${implicit_off64_t[@]}"; do
  perl -pi -077 -e 's/(?<!\w)::(off64_t)\b/$1/g' "$file"
done

implicit_Ioctl=(
  src/unix/linux_like/linux/mod.rs
)

for file in "${implicit_Ioctl[@]}"; do
  perl -pi -077 -e 's/(?<!\w)::(Ioctl)\b/$1/g' "$file"
done

perl -pi -077 -e 's/(?<!\w)::(__u8|__u16|__u32|__s16|__s32)\b/$1/g' src/unix/linux_like/linux/mod.rs

perl -pi -077 -e 's/(?<!\w)::(SIG[A-Z]+)\b/$1/g' src/unix/solarish/mod.rs

# These are used only in `cfg`ed items or comments, `use ::<type>;` would cause warnings on some targets
perl -pi -077 -e 's/(?<!\w)::c_ulong\b/crate::c_ulong/g' src/unix/newlib/generic.rs
perl -pi -077 -e 's/(?<!\w)::c_ulong\b/crate::c_ulong/g' src/unix/linux_like/linux/arch/generic/mod.rs
perl -pi -077 -e 's/(?<!\w)::c_ulonglong\b/crate::c_ulonglong/g' src/unix/linux_like/linux/gnu/b64/mod.rs
perl -pi -077 -e 's/(?<!\w)::c_ulonglong\b/crate::c_ulonglong/g' src/unix/linux_like/linux/mod.rs
perl -pi -077 -e 's/(?<!\w)::c_ulonglong\b/crate::c_ulonglong/g' src/unix/linux_like/mod.rs
perl -pi -077 -e 's/(?<!\w)::c_short\b/crate::c_short/g' src/unix/linux_like/linux/gnu/b32/mod.rs
perl -pi -077 -e 's/(?<!\w)::c_short\b/crate::c_short/g' src/unix/newlib/mod.rs
perl -pi -077 -e 's/(?<!\w)::c_float\b/c_float/g' src/unix/linux_like/linux/gnu/b64/s390x.rs
perl -pi -077 -e 's/(?<!\w)::c_float\b/c_float/g' src/unix/linux_like/linux/musl/b64/s390x.rs

function handle_type() {
  type="$1"
  uses_type="$(rg -l "[^\w]::$type\b" src)"
  has_type_def="$(rg -l "(type|struct) $type " src)"
  has_type_import="$(rg -l "use ([0-9a-zA-Z_]+::)*$type;" src)"

  add_import=($(comm -3 <(echo "$uses_type" | sort) <(printf "%s\n%s" "$has_type_def" "$has_type_import" | sort) | cut -f1))
  for file in "${add_import[@]}"; do
    # Split the file into two parts: module-level attributes and rest
    # Imports will be added after module-level attributes

    awk '/^#!|^\/\/!/ {found=NR} {lines[NR]=$0} END {for (i=1; i<=found; i++) print lines[i]}' \
      "$file" > "$file.attrs"
    awk '/^#!|^\/\/!/ {found=NR} END {if (found) {for (i=found+1; i<=NR; i++) print lines[i]} else {for (i=1; i<=NR; i++) print lines[i]}} {lines[NR]=$0}' \
      "$file" > "$file.rest"

    cat "$file.attrs" > "$file"
    echo >> "$file"
    echo 'use crate::'"$type"';' >> "$file"
    echo >> "$file"
    cat "$file.rest" >> "$file"

    rm "$file.attrs" "$file.rest"
  done

  for file in $uses_type; do
    perl -pi -077 -e 's/(?<!\w)::('"$type"')\b/$1/g' "$file"
  done
}

handle_type c_void
handle_type c_int
handle_type c_uint
handle_type c_char
handle_type c_schar
handle_type c_uchar
handle_type c_short
handle_type c_ushort
handle_type c_long
handle_type c_ulong
handle_type c_longlong
handle_type c_ulonglong
handle_type c_float
handle_type c_double
handle_type size_t
handle_type ssize_t
handle_type intptr_t
handle_type ptrdiff_t
handle_type off_t
handle_type off64_t
#handle_type time_t # Produces deprecation warnings
handle_type Ioctl
handle_type cmsghdr # To avoid "line formatted, but exceeded maximum width"

# Commented targets failed to `cargo check -Zbuild-std=core`
targets=(
  aarch64-apple-darwin
  aarch64-apple-ios
  aarch64-apple-ios-macabi
  aarch64-apple-ios-sim
  aarch64-apple-tvos
  aarch64-apple-tvos-sim
  aarch64-apple-visionos
  aarch64-apple-visionos-sim
  aarch64-apple-watchos
  aarch64-apple-watchos-sim
  aarch64-kmc-solid_asp3
  aarch64-linux-android
  aarch64-nintendo-switch-freestanding
  aarch64-pc-windows-gnullvm
  aarch64-pc-windows-msvc
  aarch64-unknown-freebsd
  aarch64-unknown-fuchsia
  aarch64-unknown-hermit
  aarch64-unknown-illumos
  aarch64-unknown-linux-gnu
  aarch64-unknown-linux-gnu_ilp32
  aarch64-unknown-linux-musl
  aarch64-unknown-linux-ohos
  aarch64-unknown-netbsd
  aarch64-unknown-none
  aarch64-unknown-none-softfloat
  aarch64-unknown-nto-qnx700
  aarch64-unknown-nto-qnx710
  aarch64-unknown-openbsd
  aarch64-unknown-redox
  #aarch64-unknown-teeos
  aarch64-unknown-trusty
  aarch64-unknown-uefi
  aarch64-uwp-windows-msvc
  aarch64-wrs-vxworks
  aarch64_be-unknown-linux-gnu
  aarch64_be-unknown-linux-gnu_ilp32
  aarch64_be-unknown-netbsd
  arm-linux-androideabi
  arm-unknown-linux-gnueabi
  arm-unknown-linux-gnueabihf
  arm-unknown-linux-musleabi
  arm-unknown-linux-musleabihf
  arm64_32-apple-watchos
  arm64e-apple-darwin
  arm64e-apple-ios
  arm64e-apple-tvos
  arm64ec-pc-windows-msvc
  armeb-unknown-linux-gnueabi
  armebv7r-none-eabi
  armebv7r-none-eabihf
  armv4t-none-eabi
  armv4t-unknown-linux-gnueabi
  armv5te-none-eabi
  armv5te-unknown-linux-gnueabi
  armv5te-unknown-linux-musleabi
  armv5te-unknown-linux-uclibceabi
  armv6-unknown-freebsd
  armv6-unknown-netbsd-eabihf
  armv6k-nintendo-3ds
  armv7-linux-androideabi
  armv7-rtems-eabihf
  armv7-sony-vita-newlibeabihf
  armv7-unknown-freebsd
  armv7-unknown-linux-gnueabi
  armv7-unknown-linux-gnueabihf
  armv7-unknown-linux-musleabi
  armv7-unknown-linux-musleabihf
  armv7-unknown-linux-ohos
  armv7-unknown-linux-uclibceabi
  armv7-unknown-linux-uclibceabihf
  armv7-unknown-netbsd-eabihf
  armv7-unknown-trusty
  armv7-wrs-vxworks-eabihf
  armv7a-kmc-solid_asp3-eabi
  armv7a-kmc-solid_asp3-eabihf
  armv7a-none-eabi
  armv7a-none-eabihf
  armv7k-apple-watchos
  armv7r-none-eabi
  armv7r-none-eabihf
  armv7s-apple-ios
  armv8r-none-eabihf
  #avr-unknown-gnu-atmega328
  bpfeb-unknown-none
  bpfel-unknown-none
  csky-unknown-linux-gnuabiv2
  csky-unknown-linux-gnuabiv2hf
  hexagon-unknown-linux-musl
  #hexagon-unknown-none-elf
  i386-apple-ios
  #i586-pc-nto-qnx700
  i586-pc-windows-msvc
  i586-unknown-linux-gnu
  i586-unknown-linux-musl
  i586-unknown-netbsd
  i686-apple-darwin
  i686-linux-android
  i686-pc-windows-gnu
  i686-pc-windows-gnullvm
  i686-pc-windows-msvc
  i686-unknown-freebsd
  i686-unknown-haiku
  i686-unknown-hurd-gnu
  i686-unknown-linux-gnu
  i686-unknown-linux-musl
  i686-unknown-netbsd
  i686-unknown-openbsd
  i686-unknown-redox
  i686-unknown-uefi
  i686-uwp-windows-gnu
  i686-uwp-windows-msvc
  i686-win7-windows-msvc
  i686-wrs-vxworks
  loongarch64-unknown-linux-gnu
  loongarch64-unknown-linux-musl
  loongarch64-unknown-linux-ohos
  loongarch64-unknown-none
  loongarch64-unknown-none-softfloat
  #m68k-unknown-linux-gnu
  mips-unknown-linux-gnu
  mips-unknown-linux-musl
  mips-unknown-linux-uclibc
  mips64-openwrt-linux-musl
  mips64-unknown-linux-gnuabi64
  mips64-unknown-linux-muslabi64
  mips64el-unknown-linux-gnuabi64
  mips64el-unknown-linux-muslabi64
  mipsel-sony-psp
  mipsel-sony-psx
  mipsel-unknown-linux-gnu
  mipsel-unknown-linux-musl
  mipsel-unknown-linux-uclibc
  mipsel-unknown-netbsd
  mipsel-unknown-none
  mipsisa32r6-unknown-linux-gnu
  mipsisa32r6el-unknown-linux-gnu
  mipsisa64r6-unknown-linux-gnuabi64
  mipsisa64r6el-unknown-linux-gnuabi64
  msp430-none-elf
  nvptx64-nvidia-cuda
  powerpc-unknown-freebsd
  powerpc-unknown-linux-gnu
  powerpc-unknown-linux-gnuspe
  powerpc-unknown-linux-musl
  powerpc-unknown-linux-muslspe
  powerpc-unknown-netbsd
  powerpc-unknown-openbsd
  powerpc-wrs-vxworks
  powerpc-wrs-vxworks-spe
  powerpc64-ibm-aix
  powerpc64-unknown-freebsd
  powerpc64-unknown-linux-gnu
  powerpc64-unknown-linux-musl
  powerpc64-unknown-openbsd
  powerpc64-wrs-vxworks
  powerpc64le-unknown-freebsd
  powerpc64le-unknown-linux-gnu
  powerpc64le-unknown-linux-musl
  riscv32-wrs-vxworks
  riscv32e-unknown-none-elf
  riscv32em-unknown-none-elf
  riscv32emc-unknown-none-elf
  riscv32gc-unknown-linux-gnu
  riscv32gc-unknown-linux-musl
  riscv32i-unknown-none-elf
  riscv32im-risc0-zkvm-elf
  riscv32im-unknown-none-elf
  riscv32ima-unknown-none-elf
  riscv32imac-esp-espidf
  riscv32imac-unknown-none-elf
  riscv32imac-unknown-nuttx-elf
  riscv32imac-unknown-xous-elf
  riscv32imafc-esp-espidf
  riscv32imafc-unknown-none-elf
  riscv32imafc-unknown-nuttx-elf
  riscv32imc-esp-espidf
  riscv32imc-unknown-none-elf
  riscv32imc-unknown-nuttx-elf
  riscv64-linux-android
  riscv64-wrs-vxworks
  riscv64gc-unknown-freebsd
  riscv64gc-unknown-fuchsia
  riscv64gc-unknown-hermit
  riscv64gc-unknown-linux-gnu
  riscv64gc-unknown-linux-musl
  #riscv64gc-unknown-netbsd
  riscv64gc-unknown-none-elf
  riscv64gc-unknown-nuttx-elf
  riscv64gc-unknown-openbsd
  riscv64imac-unknown-none-elf
  riscv64imac-unknown-nuttx-elf
  s390x-unknown-linux-gnu
  s390x-unknown-linux-musl
  sparc-unknown-linux-gnu
  sparc-unknown-none-elf
  sparc64-unknown-linux-gnu
  sparc64-unknown-netbsd
  sparc64-unknown-openbsd
  sparcv9-sun-solaris
  thumbv4t-none-eabi
  thumbv5te-none-eabi
  thumbv6m-none-eabi
  thumbv6m-nuttx-eabi
  thumbv7a-pc-windows-msvc
  thumbv7a-uwp-windows-msvc
  thumbv7em-none-eabi
  thumbv7em-none-eabihf
  thumbv7em-nuttx-eabi
  thumbv7em-nuttx-eabihf
  thumbv7m-none-eabi
  thumbv7m-nuttx-eabi
  thumbv7neon-linux-androideabi
  thumbv7neon-unknown-linux-gnueabihf
  thumbv7neon-unknown-linux-musleabihf
  thumbv8m.base-none-eabi
  thumbv8m.base-nuttx-eabi
  thumbv8m.main-none-eabi
  thumbv8m.main-none-eabihf
  thumbv8m.main-nuttx-eabi
  thumbv8m.main-nuttx-eabihf
  wasm32-unknown-emscripten
  wasm32-unknown-unknown
  wasm32-wasip1
  wasm32-wasip1-threads
  wasm32-wasip2
  wasm32v1-none
  wasm64-unknown-unknown
  x86_64-apple-darwin
  x86_64-apple-ios
  x86_64-apple-ios-macabi
  x86_64-apple-tvos
  x86_64-apple-watchos-sim
  x86_64-fortanix-unknown-sgx
  x86_64-linux-android
  x86_64-pc-nto-qnx710
  x86_64-pc-solaris
  x86_64-pc-windows-gnu
  x86_64-pc-windows-gnullvm
  x86_64-pc-windows-msvc
  x86_64-unikraft-linux-musl
  x86_64-unknown-dragonfly
  x86_64-unknown-freebsd
  x86_64-unknown-fuchsia
  x86_64-unknown-haiku
  x86_64-unknown-hermit
  x86_64-unknown-hurd-gnu
  x86_64-unknown-illumos
  x86_64-unknown-l4re-uclibc
  x86_64-unknown-linux-gnu
  x86_64-unknown-linux-gnux32
  x86_64-unknown-linux-musl
  #x86_64-unknown-linux-none
  x86_64-unknown-linux-ohos
  x86_64-unknown-netbsd
  x86_64-unknown-none
  x86_64-unknown-openbsd
  x86_64-unknown-redox
  x86_64-unknown-trusty
  x86_64-unknown-uefi
  x86_64-uwp-windows-gnu
  x86_64-uwp-windows-msvc
  x86_64-win7-windows-msvc
  x86_64-wrs-vxworks
  x86_64h-apple-darwin
  #xtensa-esp32-espidf
  #xtensa-esp32-none-elf
  #xtensa-esp32s2-espidf
  #xtensa-esp32s2-none-elf
  #xtensa-esp32s3-espidf
  #xtensa-esp32s3-none-elf
)

# Migrate to 2018

for target in "${targets[@]}"; do
  echo "Migrating 2015 -> 2018 target $target"
  cargo fix --target "$target" -Zbuild-std=core --features extra_traits --allow-dirty --edition --broken-code 2> /dev/null
done

# Handle freebsd versions
freebsd_versions=(freebsd13 freebsd14 freebsd15)
for ver in "${freebsd_versions[@]}"; do
  echo "Migrating 2015 -> 2018 $ver"
  RUSTFLAGS="--cfg $ver" cargo fix --target i686-unknown-freebsd -Zbuild-std=core --features extra_traits --allow-dirty --edition --broken-code 2> /dev/null
  RUSTFLAGS="--cfg $ver" cargo fix --target x86_64-unknown-freebsd -Zbuild-std=core --features extra_traits --allow-dirty --edition --broken-code 2> /dev/null
done

sed -i 's/edition = "2015"/edition = "2018"/' Cargo.toml

# Migrate to 2021

for target in "${targets[@]}"; do
  echo "Migrating 2018 -> 2021 target $target"
  cargo fix --target "$target" -Zbuild-std=core --features extra_traits --allow-dirty --edition --broken-code 2> /dev/null
done

sed -i 's/edition = "2018"/edition = "2021"/' Cargo.toml

# Check
for target in "${targets[@]}"; do
  echo "Checking target $target"
  cargo check --target "$target" -Zbuild-std=core --features extra_traits || {
    echo "Failed for target $target"
    exit 1
  }
done

for ver in "${freebsd_versions[@]}"; do
  echo "Checking $ver"
  RUSTFLAGS="--cfg $ver" cargo check --target i686-unknown-freebsd -Zbuild-std=core --features extra_traits || {
    echo "Failed for i686 $freebsd_versions"
    exit 1
  }
  RUSTFLAGS="--cfg $ver" cargo check --target x86_64-unknown-freebsd -Zbuild-std=core --features extra_traits || {
    echo "Failed for x86_64 $freebsd_versions"
    exit 1
  }
done

# Fix formatting
ci/style.sh

Results of me running locally:
$ git checkout 498165de32e5c5661b58f108ff32a7ef75454534 # last commit in this PR before automated upgrades
$ git ls-tree --full-tree -r HEAD . | git hash-object  --stdin # hash of initial state
e210fdd4cb497b8cb13c2b962ea0de4b6f5ba2a5
$ ../a.sh  # your script
$ git commit -am "apply automated changes" # dummy commit for ls-tree
$ git ls-tree --full-tree -r HEAD . | git hash-object --stdin # hash the result of these changes
72db53fcc2e536e8725f4178d035bace1f853a3d
$  git diff dfb720856c05943c34085d541a235a466dc9d751 # compare to the result of this PR
diff --git a/Cargo.toml b/Cargo.toml
index a631b4a5d..9deb2ac56 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -4,7 +4,7 @@ version = "1.0.0-alpha.1"
 authors = ["The Rust Project Developers"]
 license = "MIT OR Apache-2.0"
 readme = "README.md"
-edition = "2021"
+edition = "2015"
 repository = "https://github.com/rust-lang/libc"
 homepage = "https://github.com/rust-lang/libc"
 documentation = "https://docs.rs/libc/"
diff --git a/src/unix/linux_like/mod.rs b/src/unix/linux_like/mod.rs
index 823a4ec02..ac17f88f2 100644
--- a/src/unix/linux_like/mod.rs
+++ b/src/unix/linux_like/mod.rs
@@ -1658,7 +1658,7 @@ safe_f! {
     pub {const} fn KERNEL_VERSION(a: u32, b: u32, c: u32) -> u32 {
         ((a << 16) + (b << 8))
             + match c {
-                0..=255 => c,
+                0...255 => c,
                 _ => 255,
             }
     }
$ git checkout dfb720856c05943c34085d541a235a466dc9d751 # commit in this PR after automated changes
$ git ls-tree --full-tree -r HEAD . | git hash-object --stdin
e0aaa981dce61d44bcf37469c58e9aae5ba0011c

I'm not sure why the above would be different?
Note to self so I don't accidentally invalidate 30GB of cache: I'm on rustc 1.84.0-nightly (b19329a37 2024-11-21)

Anyway I'm not going to worry about the above, it looks like your script is doing the right thing and my machine isn't for some reason. Everything else lines up so that is the important thing.
I left two comments suggesting some trivial updates. Rebase and rerun whenever you're ready, then let's get this huge thing merged!

I'm not sure why the above would be different?

Oh, the edition string update was done with sed which isn't portable. If those sed lines were replaced with awk or perl it would probably be fine.

I didn't know that sed -i was not portable. I replaced it with perl. Rebased and removed :: prefixes for Option, Copy and Clone.

Script
#!/usr/bin/env bash

git restore Cargo.toml src

# Handle leading `::` in common types

for file in $(find src -name "*.rs"); do
  perl -pi -077 -e 's/(?<!\w)::(Option|Copy|Clone)\b/$1/g' "$file"
done

implicit_c_long_ulong_char=(
  src/fuchsia/mod.rs
  src/solid/mod.rs
  src/unix/aix/mod.rs
  src/unix/bsd/apple/mod.rs
  src/unix/bsd/freebsdlike/freebsd/mod.rs
  src/unix/bsd/freebsdlike/mod.rs
  src/unix/bsd/netbsdlike/netbsd/mod.rs
  src/unix/bsd/netbsdlike/openbsd/mod.rs
  src/unix/bsd/netbsdlike/mod.rs
  src/unix/bsd/mod.rs
  src/unix/haiku/mod.rs
  src/unix/hurd/mod.rs
  src/unix/linux_like/android/b32/mod.rs
  src/unix/linux_like/android/b64/mod.rs
  src/unix/linux_like/android/mod.rs
  src/unix/linux_like/linux/gnu/b32/mod.rs
  src/unix/linux_like/linux/gnu/b64/aarch64/mod.rs
  src/unix/linux_like/linux/gnu/b64/x86_64/mod.rs
  src/unix/linux_like/linux/gnu/b64/mod.rs
  src/unix/linux_like/linux/gnu/mod.rs
  src/unix/linux_like/linux/musl/mod.rs
  src/unix/linux_like/linux/uclibc/mips/mod.rs
  src/unix/linux_like/linux/uclibc/mod.rs
  src/unix/linux_like/linux/mod.rs
  src/unix/linux_like/mod.rs
  src/unix/newlib/mod.rs
  src/unix/nto/mod.rs
  src/unix/mod.rs
  src/vxworks/mod.rs
)

for file in "${implicit_c_long_ulong_char[@]}"; do
  perl -pi -077 -e 's/(?<!\w)::(c_long|c_ulong|c_char)\b/$1/g' "$file"
done

implicit_off_t=(
  src/unix/linux_like/linux/gnu/mod.rs
  src/unix/linux_like/linux/mod.rs
  src/unix/linux_like/mod.rs
  src/unix/mod.rs
)

for file in "${implicit_off_t[@]}"; do
  perl -pi -077 -e 's/(?<!\w)::(off_t)\b/$1/g' "$file"
done

implicit_off64_t=(
  src/unix/linux_like/android/mod.rs
  src/unix/linux_like/mod.rs
)

for file in "${implicit_off64_t[@]}"; do
  perl -pi -077 -e 's/(?<!\w)::(off64_t)\b/$1/g' "$file"
done

implicit_Ioctl=(
  src/unix/linux_like/linux/mod.rs
)

for file in "${implicit_Ioctl[@]}"; do
  perl -pi -077 -e 's/(?<!\w)::(Ioctl)\b/$1/g' "$file"
done

perl -pi -077 -e 's/(?<!\w)::(__u8|__u16|__u32|__s16|__s32)\b/$1/g' src/unix/linux_like/linux/mod.rs

perl -pi -077 -e 's/(?<!\w)::(SIG[A-Z]+)\b/$1/g' src/unix/solarish/mod.rs

# These are used only in `cfg`ed items or comments, `use ::<type>;` would cause warnings on some targets
perl -pi -077 -e 's/(?<!\w)::c_ulong\b/crate::c_ulong/g' src/unix/newlib/generic.rs
perl -pi -077 -e 's/(?<!\w)::c_ulong\b/crate::c_ulong/g' src/unix/linux_like/linux/arch/generic/mod.rs
perl -pi -077 -e 's/(?<!\w)::c_ulonglong\b/crate::c_ulonglong/g' src/unix/linux_like/linux/gnu/b64/mod.rs
perl -pi -077 -e 's/(?<!\w)::c_ulonglong\b/crate::c_ulonglong/g' src/unix/linux_like/linux/mod.rs
perl -pi -077 -e 's/(?<!\w)::c_ulonglong\b/crate::c_ulonglong/g' src/unix/linux_like/mod.rs
perl -pi -077 -e 's/(?<!\w)::c_short\b/crate::c_short/g' src/unix/linux_like/linux/gnu/b32/mod.rs
perl -pi -077 -e 's/(?<!\w)::c_short\b/crate::c_short/g' src/unix/newlib/mod.rs
perl -pi -077 -e 's/(?<!\w)::c_float\b/c_float/g' src/unix/linux_like/linux/gnu/b64/s390x.rs
perl -pi -077 -e 's/(?<!\w)::c_float\b/c_float/g' src/unix/linux_like/linux/musl/b64/s390x.rs

function handle_type() {
  type="$1"
  uses_type="$(rg -l "[^\w]::$type\b" src)"
  has_type_def="$(rg -l "(type|struct) $type " src)"
  has_type_import="$(rg -l "use ([0-9a-zA-Z_]+::)*$type;" src)"

  add_import=($(comm -3 <(echo "$uses_type" | sort) <(printf "%s\n%s" "$has_type_def" "$has_type_import" | sort) | cut -f1))
  for file in "${add_import[@]}"; do
    # Split the file into two parts: module-level attributes and rest
    # Imports will be added after module-level attributes

    awk '/^#!|^\/\/!/ {found=NR} {lines[NR]=$0} END {for (i=1; i<=found; i++) print lines[i]}' \
      "$file" > "$file.attrs"
    awk '/^#!|^\/\/!/ {found=NR} END {if (found) {for (i=found+1; i<=NR; i++) print lines[i]} else {for (i=1; i<=NR; i++) print lines[i]}} {lines[NR]=$0}' \
      "$file" > "$file.rest"

    cat "$file.attrs" > "$file"
    echo >> "$file"
    echo 'use crate::'"$type"';' >> "$file"
    echo >> "$file"
    cat "$file.rest" >> "$file"

    rm "$file.attrs" "$file.rest"
  done

  for file in $uses_type; do
    perl -pi -077 -e 's/(?<!\w)::('"$type"')\b/$1/g' "$file"
  done
}

handle_type c_void
handle_type c_int
handle_type c_uint
handle_type c_char
handle_type c_schar
handle_type c_uchar
handle_type c_short
handle_type c_ushort
handle_type c_long
handle_type c_ulong
handle_type c_longlong
handle_type c_ulonglong
handle_type c_float
handle_type c_double
handle_type size_t
handle_type ssize_t
handle_type intptr_t
handle_type ptrdiff_t
handle_type off_t
handle_type off64_t
#handle_type time_t # Produces deprecation warnings
handle_type Ioctl
handle_type cmsghdr # To avoid "line formatted, but exceeded maximum width"

# Commented targets failed to `cargo check -Zbuild-std=core`
targets=(
  aarch64-apple-darwin
  aarch64-apple-ios
  aarch64-apple-ios-macabi
  aarch64-apple-ios-sim
  aarch64-apple-tvos
  aarch64-apple-tvos-sim
  aarch64-apple-visionos
  aarch64-apple-visionos-sim
  aarch64-apple-watchos
  aarch64-apple-watchos-sim
  aarch64-kmc-solid_asp3
  aarch64-linux-android
  aarch64-nintendo-switch-freestanding
  aarch64-pc-windows-gnullvm
  aarch64-pc-windows-msvc
  aarch64-unknown-freebsd
  aarch64-unknown-fuchsia
  aarch64-unknown-hermit
  aarch64-unknown-illumos
  aarch64-unknown-linux-gnu
  aarch64-unknown-linux-gnu_ilp32
  aarch64-unknown-linux-musl
  aarch64-unknown-linux-ohos
  aarch64-unknown-netbsd
  aarch64-unknown-none
  aarch64-unknown-none-softfloat
  aarch64-unknown-nto-qnx700
  aarch64-unknown-nto-qnx710
  aarch64-unknown-openbsd
  aarch64-unknown-redox
  #aarch64-unknown-teeos
  aarch64-unknown-trusty
  aarch64-unknown-uefi
  aarch64-uwp-windows-msvc
  aarch64-wrs-vxworks
  aarch64_be-unknown-linux-gnu
  aarch64_be-unknown-linux-gnu_ilp32
  aarch64_be-unknown-netbsd
  arm-linux-androideabi
  arm-unknown-linux-gnueabi
  arm-unknown-linux-gnueabihf
  arm-unknown-linux-musleabi
  arm-unknown-linux-musleabihf
  arm64_32-apple-watchos
  arm64e-apple-darwin
  arm64e-apple-ios
  arm64e-apple-tvos
  arm64ec-pc-windows-msvc
  armeb-unknown-linux-gnueabi
  armebv7r-none-eabi
  armebv7r-none-eabihf
  armv4t-none-eabi
  armv4t-unknown-linux-gnueabi
  armv5te-none-eabi
  armv5te-unknown-linux-gnueabi
  armv5te-unknown-linux-musleabi
  armv5te-unknown-linux-uclibceabi
  armv6-unknown-freebsd
  armv6-unknown-netbsd-eabihf
  armv6k-nintendo-3ds
  armv7-linux-androideabi
  armv7-rtems-eabihf
  armv7-sony-vita-newlibeabihf
  armv7-unknown-freebsd
  armv7-unknown-linux-gnueabi
  armv7-unknown-linux-gnueabihf
  armv7-unknown-linux-musleabi
  armv7-unknown-linux-musleabihf
  armv7-unknown-linux-ohos
  armv7-unknown-linux-uclibceabi
  armv7-unknown-linux-uclibceabihf
  armv7-unknown-netbsd-eabihf
  armv7-unknown-trusty
  armv7-wrs-vxworks-eabihf
  armv7a-kmc-solid_asp3-eabi
  armv7a-kmc-solid_asp3-eabihf
  armv7a-none-eabi
  armv7a-none-eabihf
  armv7k-apple-watchos
  armv7r-none-eabi
  armv7r-none-eabihf
  armv7s-apple-ios
  armv8r-none-eabihf
  #avr-unknown-gnu-atmega328
  bpfeb-unknown-none
  bpfel-unknown-none
  csky-unknown-linux-gnuabiv2
  csky-unknown-linux-gnuabiv2hf
  hexagon-unknown-linux-musl
  #hexagon-unknown-none-elf
  i386-apple-ios
  #i586-pc-nto-qnx700
  i586-pc-windows-msvc
  i586-unknown-linux-gnu
  i586-unknown-linux-musl
  i586-unknown-netbsd
  i686-apple-darwin
  i686-linux-android
  i686-pc-windows-gnu
  i686-pc-windows-gnullvm
  i686-pc-windows-msvc
  i686-unknown-freebsd
  i686-unknown-haiku
  i686-unknown-hurd-gnu
  i686-unknown-linux-gnu
  i686-unknown-linux-musl
  i686-unknown-netbsd
  i686-unknown-openbsd
  i686-unknown-redox
  i686-unknown-uefi
  i686-uwp-windows-gnu
  i686-uwp-windows-msvc
  i686-win7-windows-msvc
  i686-wrs-vxworks
  loongarch64-unknown-linux-gnu
  loongarch64-unknown-linux-musl
  loongarch64-unknown-linux-ohos
  loongarch64-unknown-none
  loongarch64-unknown-none-softfloat
  #m68k-unknown-linux-gnu
  mips-unknown-linux-gnu
  mips-unknown-linux-musl
  mips-unknown-linux-uclibc
  mips64-openwrt-linux-musl
  mips64-unknown-linux-gnuabi64
  mips64-unknown-linux-muslabi64
  mips64el-unknown-linux-gnuabi64
  mips64el-unknown-linux-muslabi64
  mipsel-sony-psp
  mipsel-sony-psx
  mipsel-unknown-linux-gnu
  mipsel-unknown-linux-musl
  mipsel-unknown-linux-uclibc
  mipsel-unknown-netbsd
  mipsel-unknown-none
  mipsisa32r6-unknown-linux-gnu
  mipsisa32r6el-unknown-linux-gnu
  mipsisa64r6-unknown-linux-gnuabi64
  mipsisa64r6el-unknown-linux-gnuabi64
  msp430-none-elf
  nvptx64-nvidia-cuda
  powerpc-unknown-freebsd
  powerpc-unknown-linux-gnu
  powerpc-unknown-linux-gnuspe
  powerpc-unknown-linux-musl
  powerpc-unknown-linux-muslspe
  powerpc-unknown-netbsd
  powerpc-unknown-openbsd
  powerpc-wrs-vxworks
  powerpc-wrs-vxworks-spe
  powerpc64-ibm-aix
  powerpc64-unknown-freebsd
  powerpc64-unknown-linux-gnu
  powerpc64-unknown-linux-musl
  powerpc64-unknown-openbsd
  powerpc64-wrs-vxworks
  powerpc64le-unknown-freebsd
  powerpc64le-unknown-linux-gnu
  powerpc64le-unknown-linux-musl
  riscv32-wrs-vxworks
  riscv32e-unknown-none-elf
  riscv32em-unknown-none-elf
  riscv32emc-unknown-none-elf
  riscv32gc-unknown-linux-gnu
  riscv32gc-unknown-linux-musl
  riscv32i-unknown-none-elf
  riscv32im-risc0-zkvm-elf
  riscv32im-unknown-none-elf
  riscv32ima-unknown-none-elf
  riscv32imac-esp-espidf
  riscv32imac-unknown-none-elf
  riscv32imac-unknown-nuttx-elf
  riscv32imac-unknown-xous-elf
  riscv32imafc-esp-espidf
  riscv32imafc-unknown-none-elf
  riscv32imafc-unknown-nuttx-elf
  riscv32imc-esp-espidf
  riscv32imc-unknown-none-elf
  riscv32imc-unknown-nuttx-elf
  riscv64-linux-android
  riscv64-wrs-vxworks
  riscv64gc-unknown-freebsd
  riscv64gc-unknown-fuchsia
  riscv64gc-unknown-hermit
  riscv64gc-unknown-linux-gnu
  riscv64gc-unknown-linux-musl
  #riscv64gc-unknown-netbsd
  riscv64gc-unknown-none-elf
  riscv64gc-unknown-nuttx-elf
  riscv64gc-unknown-openbsd
  riscv64imac-unknown-none-elf
  riscv64imac-unknown-nuttx-elf
  s390x-unknown-linux-gnu
  s390x-unknown-linux-musl
  sparc-unknown-linux-gnu
  sparc-unknown-none-elf
  sparc64-unknown-linux-gnu
  sparc64-unknown-netbsd
  sparc64-unknown-openbsd
  sparcv9-sun-solaris
  thumbv4t-none-eabi
  thumbv5te-none-eabi
  thumbv6m-none-eabi
  thumbv6m-nuttx-eabi
  thumbv7a-pc-windows-msvc
  thumbv7a-uwp-windows-msvc
  thumbv7em-none-eabi
  thumbv7em-none-eabihf
  thumbv7em-nuttx-eabi
  thumbv7em-nuttx-eabihf
  thumbv7m-none-eabi
  thumbv7m-nuttx-eabi
  thumbv7neon-linux-androideabi
  thumbv7neon-unknown-linux-gnueabihf
  thumbv7neon-unknown-linux-musleabihf
  thumbv8m.base-none-eabi
  thumbv8m.base-nuttx-eabi
  thumbv8m.main-none-eabi
  thumbv8m.main-none-eabihf
  thumbv8m.main-nuttx-eabi
  thumbv8m.main-nuttx-eabihf
  wasm32-unknown-emscripten
  wasm32-unknown-unknown
  wasm32-wasip1
  wasm32-wasip1-threads
  wasm32-wasip2
  wasm32v1-none
  wasm64-unknown-unknown
  x86_64-apple-darwin
  x86_64-apple-ios
  x86_64-apple-ios-macabi
  x86_64-apple-tvos
  x86_64-apple-watchos-sim
  x86_64-fortanix-unknown-sgx
  x86_64-linux-android
  x86_64-pc-nto-qnx710
  x86_64-pc-solaris
  x86_64-pc-windows-gnu
  x86_64-pc-windows-gnullvm
  x86_64-pc-windows-msvc
  x86_64-unikraft-linux-musl
  x86_64-unknown-dragonfly
  x86_64-unknown-freebsd
  x86_64-unknown-fuchsia
  x86_64-unknown-haiku
  x86_64-unknown-hermit
  x86_64-unknown-hurd-gnu
  x86_64-unknown-illumos
  x86_64-unknown-l4re-uclibc
  x86_64-unknown-linux-gnu
  x86_64-unknown-linux-gnux32
  x86_64-unknown-linux-musl
  #x86_64-unknown-linux-none
  x86_64-unknown-linux-ohos
  x86_64-unknown-netbsd
  x86_64-unknown-none
  x86_64-unknown-openbsd
  x86_64-unknown-redox
  x86_64-unknown-trusty
  x86_64-unknown-uefi
  x86_64-uwp-windows-gnu
  x86_64-uwp-windows-msvc
  x86_64-win7-windows-msvc
  x86_64-wrs-vxworks
  x86_64h-apple-darwin
  #xtensa-esp32-espidf
  #xtensa-esp32-none-elf
  #xtensa-esp32s2-espidf
  #xtensa-esp32s2-none-elf
  #xtensa-esp32s3-espidf
  #xtensa-esp32s3-none-elf
)

# Migrate to 2018

for target in "${targets[@]}"; do
  echo "Migrating 2015 -> 2018 target $target"
  cargo fix --target "$target" -Zbuild-std=core --features extra_traits --allow-dirty --edition --broken-code 2> /dev/null
done

# Handle freebsd versions
freebsd_versions=(freebsd13 freebsd14 freebsd15)
for ver in "${freebsd_versions[@]}"; do
  echo "Migrating 2015 -> 2018 $ver"
  RUSTFLAGS="--cfg $ver" cargo fix --target i686-unknown-freebsd -Zbuild-std=core --features extra_traits --allow-dirty --edition --broken-code 2> /dev/null
  RUSTFLAGS="--cfg $ver" cargo fix --target x86_64-unknown-freebsd -Zbuild-std=core --features extra_traits --allow-dirty --edition --broken-code 2> /dev/null
done

perl -pi -077 -e 's/edition = "2015"/edition = "2018"/' Cargo.toml

# Migrate to 2021

for target in "${targets[@]}"; do
  echo "Migrating 2018 -> 2021 target $target"
  cargo fix --target "$target" -Zbuild-std=core --features extra_traits --allow-dirty --edition --broken-code 2> /dev/null
done

perl -pi -077 -e 's/edition = "2018"/edition = "2021"/' Cargo.toml

# Check
for target in "${targets[@]}"; do
  echo "Checking target $target"
  cargo check --target "$target" -Zbuild-std=core --features extra_traits || {
    echo "Failed for target $target"
    exit 1
  }
done

for ver in "${freebsd_versions[@]}"; do
  echo "Checking $ver"
  RUSTFLAGS="--cfg $ver" cargo check --target i686-unknown-freebsd -Zbuild-std=core --features extra_traits || {
    echo "Failed for i686 $freebsd_versions"
    exit 1
  }
  RUSTFLAGS="--cfg $ver" cargo check --target x86_64-unknown-freebsd -Zbuild-std=core --features extra_traits || {
    echo "Failed for x86_64 $freebsd_versions"
    exit 1
  }
done

# Fix formatting
ci/style.sh

Thanks for all the work here! I'll backport this and add a .git-blame-ignore-revs entry for the third commit.

I think the older freebsd versions that we don't test in CI might have gotten skipped. I'll make sure everything gets synced up before this makes it to a release (fyi @asomers).

Backported in https://github.com/rust-lang/libc/pull/4155#event-15445820840


Automated Package Upgrade

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


🐛 Bug Report: RTL support: Switch

👟 Reproduction steps
Something like this fixes this behaviour
[dir=rtl] .switch:where(:checked)::before {
    transform: translateX(-1rem);
}

👍 Expected behavior
To be this

👎 Actual Behavior

Magic URL dir = 'rtl'
Passowrd dir = 'ltr'
🎲 Appwrite version
Version 1.2.x
💻 Operating system
Linux
🧱 Your Environment
No response
👀 Have you spent some time to check if this issue has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

@omar2205 thank you for submitting this issue :)
@elad2412 can you take a look at this?

@omar2205 Please take a look :-); the issue is fixed.
If there is ant comment, please let me know.
Issue closed


[Doc]: What big projects use narwhals now?

What type of report is this?
Improvement
Please describe the issue.
It might be nice to have a spot on the docs that highlight which projects use Narwahls as a dep. I am partially asking this as a curiosity, but having such a page might also help motivate others to join the fun.
If you have a suggestion on how it should be, add it below.
Maybe a dedicated page?

thanks for the request - we have https://github.com/narwhals-dev/narwhals?tab=readme-ov-file#used-by, but maybe this should be mirrored in the docs too

Yes, I was also looking for that in the docs, and then realized we only have that in the README

here now, thanks Francesco https://narwhals-dev.github.io/narwhals/ecosystem/#used-by


Fix some minor errors in Simplified Chinese translations

I'm sorry I have to submit another PR. It seems that approval is required before it can be converted into official translations in Crowdin (Maybe you can modify the configuration of Crowdin?). So this time I still use PR for existing translations. Next time I may use Crowdin to submit translation. Thanks for your support!

Thanks again. Any translations submitted through Crowdin just need to be approved by me.


Creating two simulator instances  generates the error: "Simulator::gpuDevice: no OpenGL context"

Habitat-Sim version
v0.1.7
❓ Questions and Help
Hi,
I cannot create two habitat simulator instances inside the same python script, attempting to do so generates the error message: "Simulator::gpuDevice: no OpenGL context", and the program then crashes. The issue persists if the two simulator instances are assigned different GPU ID's.
There is no issue if I run two identical scripts in parallel as two separate programs (or if I run the commands interactively across two parallel python interpreters on different terminal instances), and nvidia-smi shows that the allocated GPU memory indeed corresponds to two simulator instances for this case.
Thanks a lot in advance for the help!
Additional Context
I implemented a gym environment that maintains a habitat-sim object as one of its fields, together with some additional functionality implemented around it for reward assignment, episode initialization, curriculum management, etc. I need to parallelize multiple such environments, and that is when I first encountered the issue. The issue can be reproduced without any of these additions, by simply creating two habitat-sim instances.
Code to Reproduce the Issue
The code below creates a simple sim configuration, and instantiates two simulators.
import os
import math
import habitat_sim

if __name__ == "__main__":

    # Set scene path
    SCENE_PATH = "./habitat-lab/data/scene_datasets/habitat-test-scenes/apartment_1.glb"

    # Setup general parameters (scene path, gpu, physics)
    sim_cfg = habitat_sim.SimulatorConfiguration()
    sim_cfg.gpu_device_id = 0
    sim_cfg.scene_id = SCENE_PATH
    sim_cfg.enable_physics = False

    # Sensor configuration
    sensor_specs = []
    color_sensor_1st_person_spec = habitat_sim.CameraSensorSpec()
    color_sensor_1st_person_spec.uuid = "color_sensor_1st_person"
    color_sensor_1st_person_spec.sensor_type = habitat_sim.SensorType.COLOR
    color_sensor_1st_person_spec.resolution = [544, 720]
    color_sensor_1st_person_spec.position = [0.0, 1, 0.5]
    color_sensor_1st_person_spec.orientation = [(-math.pi / 8.0),0.0,0.0,]
    color_sensor_1st_person_spec.sensor_subtype = habitat_sim.SensorSubType.PINHOLE
    sensor_specs.append(color_sensor_1st_person_spec)

    # Agent configuration
    agent_cfg = habitat_sim.agent.AgentConfiguration()
    agent_cfg.sensor_specifications = sensor_specs
    agent_cfg.action_space = {
        "move_forward": habitat_sim.agent.ActionSpec(
            "move_forward", habitat_sim.agent.ActuationSpec(amount=0.25) # default = 0.25
        ),
        "turn_left": habitat_sim.agent.ActionSpec(
            "turn_left", habitat_sim.agent.ActuationSpec(amount=30.0) # default = 0.25
        ),
        "turn_right": habitat_sim.agent.ActionSpec(
            "turn_right", habitat_sim.agent.ActuationSpec(amount=30.0) # default = 0.25
        ),

    }

    cfg = habitat_sim.Configuration(sim_cfg, [agent_cfg])

    # Create 2 simulator instances
    print('Creating sim1...')
    sim1 = habitat_sim.Simulator(cfg)
    print('Creating sim2...')
    sim2 = habitat_sim.Simulator(cfg)

Outputs
Creating sim1...
WARNING: Logging before InitGoogleLogging() is written to STDERR
E0604 14:19:06.148123 16987 SemanticScene.h:155] SemanticScene::loadSemanticSceneDescriptor : File ./habitat-lab/data/scene_datasets/habitat-test-scenes/apartment_1.scn does not exist.  Aborting load.
Creating sim2...
E0604 14:19:07.502121 16987 SemanticScene.h:155] SemanticScene::loadSemanticSceneDescriptor : File ./habitat-lab/data/scene_datasets/habitat-test-scenes/apartment_1.scn does not exist.  Aborting load.
Simulator::gpuDevice: no OpenGL context.
Aborted (core dumped)

Opening two instances of the simulator is not supported

I see, thanks.


Citeseer dataset is missing

The attribute of Citeseer is misssing (cite.txt) in the data directory. Could you kindly upload it?

Due to the limitation of file size, the complete data can be found in Baidu Netdisk:
graph: 链接:https://pan.baidu.com/s/1MEWr1KyrtBQndVNy8_y2Lw 密码:opc1
data: 链接:https://pan.baidu.com/s/1kqoWlElbWazJyrTdv1sHNg 密码:1gd4

Thanks. My fault, I didn't read the readme carefully.


hostname

https://info.cern.ch/hypertext/WWW/Addressing/BNF.html#5

https://info.cern.ch/hypertext/WWW/Addressing/BNF.html#5

Ok


Why does it convert "\t" to "\t"?

https://github.com/nikitaKunevich/vscode-snippet-creator/blob/852f6afbf14439e9ad9f6244e6273d77a3d56ecf/extension.js#L201
e.g.
Selected text:
	fmt.Println("hello world")

Snippet to be created:
	"test": {
		"prefix": "test",
		"body": [
			"func main() {",
			"\\tfmt.Println(\"hello world\")",
			"}",
			""
		],
		"description": "test"
	}

Output:
\tfmt.Println("hello world")

Expected:
	fmt.Println("hello world")

related to https://github.com/nikitaKunevich/vscode-snippet-creator/issues/6


Add missing license headers

Two new files in Services API branch are missing their license headers.

Merging immediately. No actual code changes here.


WIP [Dubbo-7181]Fix MonitorFilter not collect statistics when first invoke.

What is the purpose of the change
1，修复MonitorFilter首次运行不会采集统计数据的bug。
2，修复dubbo:monitor扩展不友好的问题。
Brief changelog
1，monitor在service、reference注册订阅时初始化；
2，monitorURL不在带入service、reference的URL，只保留monitorURL的协议头，减少service、reference的URL长度；
3，MonitorFIlter执行collect时使用AbstractMonitorFactory.getMonitors()->findAny()获得monitor；
4，支持扩展monitor时<dubbo:monitor protocol="yours"/>、<dubbo:monitor protocol="yours" address="<IP_ADDRESS>"/>配置语法；
5，MonitorFIlter只对继承AbstractMonitorFactory的Monitor生效，如果采用implements MonitorFactory方式扩展，则需要再额外实现Filter用于针对性数据采集（比如每次服务调用结果实时发送kafka）；
Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Make sure there is a GITHUB_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GITHUB issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[x] Format the pull request title like [Dubbo-XXX] Fix UnknownException when host config not exist #XXX. Each commit in the pull request should have a meaningful subject line and body.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[x] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
[ ] Run mvn clean install -DskipTests=false & mvn clean test-compile failsafe:integration-test to make sure unit-test and integration-test pass.
[ ] If this contribution is large, please follow the Software Donation Guide.

I think it would be better if we can move the initialization of Monitor to DubboStrap init process.
We are planning to do it this way on 3.0.


Remove file name parameter from builder inside SsePullRequestPayload

It is never changed and the default value is always used

The file name parameter is changed when used with SsePullRequestReviewPayload, therefore the parameter can't be removed. As a result, I am closing this issue.


How do I find the address of stuff?

[Enter feedback here]
The DumpObj command "displays information about an object at a specified address".   Similar notes are found for each command.  However, I cannot find anything not this page about how I am supposed to find the address of a given object.
Similarly, how can I display the line of code that a particular stack frame is on?  Eg. If my function contains n calls to another function, I cannot determine which of the n calls is the one that lead to the next stack frame.

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

ID: 8e01c075-7a07-5850-d462-706675b545f1
Version Independent ID: 0dd6c661-01a1-592c-ea53-8427412ff8d0
Content: SOS.dll (SOS Debugging Extension)
Content Source: docs/framework/tools/sos-dll-sos-debugging-extension.md
Product: dotnet-framework
GitHub Login: @tdykstra
Microsoft Alias: tdykstra

Hello!
Sorry to say, but this article is not the right place to ask that question. I think you will have a better chance of getting your question answered if you post it on a forum such as StackOverflow. This article is just the help information displayed by the tool, not a tutorial on how to use it. Doing a quick search I found http://www.dotnetspeak.com/debugging/inspecting-objects-using-windbg/ which mentions

you can use !dumpheap command to look at each object and !dumpheap -MT to look at the instances of each type.  Once you get an object address from the output of !dumpheap -MT command, you can then type
!dumpobj XXXX
where XXXX is the object address.

I'm going to close the issue.
Thanks.


Clear cache on stack upgrade

Summary

https://github.com/paketo-buildpacks/ruby/issues/819
Clear the cache on stack upgrades.
While the majority of simple applications could successfully use cached gems on a stack upgrade, there were a few instances where this caused issues. Because of this, we must clear the cache to be safe. Specifically, we have seen examples in which some gems cached gems have issues with OS-level packages like libssl:
/layers/paketo-buildpacks_bundle-install/launch-gems/ruby/3.1.0/gems/puma-5.6.5/lib/puma.rb:13:in `require': libssl.so.3: cannot open shared object file: No such file or directory - /layers/paketo-buildpacks_bundle-install/launch-gems/ruby/3.1.0/gems/puma-5.6.5/lib/puma/puma_http11.so

This PR also updates the simple app test fixture to use Ruby 3.1 so that we can test against Jammy in the stack upgrade scenario. Gem updates were necessary to get the app working properly with the newer Ruby version. Other tests that use that app were updated accordingly.

Use Cases

Checklist

[X] I have viewed, signed, and submitted the Contributor License Agreement.
[X] I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
[X] I have added an integration test, if necessary.
[X] I have reviewed the styleguide for guidance on my code quality.
[X] I'm happy with the commit history on this PR (I have rebased/squashed as needed).

@ryanmoran I have confirmed that the stack upgrade test does in fact fail with libssl-related errors when the cache clearing code is not present ✅


Cursor returns to the beginning when taping on the text field in the edit task screen.

Try to figure out a way of stopping the controller from returning the cursor to the origin when rebuilding if text is already present in the input.

Solved by keeping the TextEditingController in the State instead of the widget so that way it only has to be created once.


The status code for CPX_STAT_ABORT_OBJ_LIM is wrong

The status code for CPX_STAT_ABORT_OBJ_LIM(Aborted due to an objective limit) is mapped to 11 instead of 12.
closes #72

Clearly a typo, thanks for the fix!

Thanks!

No problem, quick fix.