text:
Add OCI Data Science Model Deployment LLM Integration

Description
Oracle Cloud Infrastructure (OCI) Data Science is a fully managed, serverless platform for data science teams to build, train, and manage machine learning models in Oracle Cloud Infrastructure. This PR introduces a new LLM integration with (OCI) Data Science Model Deployment endpoints. It includes synchronous and asynchronous clients, built-in retry logic using tenacity, and direct authentication via the OCI Signer.
llama_index_test_base.pdf
New Package?
Did I fill in the tool.llamahub section in the pyproject.toml and provide a detailed README.md for my new integration or package?

[X] Yes
[ ] No

Version Bump?
Did I bump the version in the pyproject.toml file of the package I am updating? (Except for the llama-index-core package)

[X] Yes
[ ] No

Type of Change
Please delete options that are not relevant.

[X] New feature (non-breaking change which adds functionality)
[X] This change requires a documentation update

How Has This Been Tested?

[X] I performed thorough manual testing
[X] I added new unit tests to cover this change
[ ] I believe this change is already covered by existing unit tests

Suggested Checklist:

[X] I have performed a self-review of my own code
[X] I have commented my code, particularly in hard-to-understand areas
[X] I have made corresponding changes to the documentation
[X] I have added Google Colab support for the newly added notebooks.
[X] My changes generate no new warnings
[X] I have added tests that prove my fix is effective or that my feature works
[X] New and existing unit tests pass locally with my changes
[X] I ran make format; make lint to appease the lint gods

Hi @logan-markewich,
I wanted to kindly ask for your help with the review of this PR. The changes introduce integration for invoking LLMs on OCI Data Science, and I’d greatly appreciate your feedback and insights.
Additionally, I’ve encountered an issue with failing tests during the CI pipeline due to the absence of the oracle-ads library, despite it being listed in the pyproject.toml file. All the tests pass locally without any problems. It seems the oracle-ads library is not being installed in the CI environment before running the tests. It looks like that poetry doesn't take into account the pyproject.toml dependencies.
When you have time, could you please take a look at this and share your thoughts on what might be causing this discrepancy? Your guidance would be incredibly helpful.
Thank you in advance for your time and support!

hmm, closer, but its not restricting to 3.9 the way i'd like

Thanks @logan-markewich for looking into this.
It looks like to use the interpreter_constraints=["==3.9.*"] option, pants needs to be run with this option: --skip-if-no-valid-interpreter.

I've temporarily removed the oracle-ads dependency. If the user doesn't have this library installed, they will receive a comprehensive error message with guidance on the necessary steps to resolve the issue. Hopefully this will help to pass the tests. Meanwhile i will try to reproduce the problem on my local environment to see which libraries cause the conflict.


text:
NPC Animator Plugin

Lets users set and run animations on NPCs and their own character.
This plugin is intended to be used to make the NPCs feel more alive and to give them a little extra personality. It might also be useful for players who want to make role-playing videos.
Features:

Save any animation in the game with your own customizable name for it.
Run any animation on your own player.
Run any animation on any NPC.
Save animations for individual NPCs as 'Greetings'

Example: Save the bow animation for King Roald so when you interact with him, he bows to you.

Run all saved NPC animations at the same time.

Use this to run all the saved greeting animations or just 1 specific animation on all saved NPCs.

Run an animation on all spawned NPCs at the same time.

You're adding a nav button here which is never removed, even on plugin shutdown, so disabling your plugin would not remove this button and toggling it would add multiple buttons. Please ensure it is removed on shutDown().

You're adding a nav button here which is never removed, even on plugin shutdown, so disabling your plugin would not remove this button and toggling it would add multiple buttons. Please ensure it is removed on shutDown().

I fixed this as requested and also fixed a UI bug. However, I cannot verify the workflow checks pass as it's awaiting approval from a maintainer.

source: gharchive/pull-request

authors: Nightfirecat SomewhatUsefulSoftware

repo: runelite/plugin-hub

license_type: permissive

license_source: github-api


text:
Create xt-security-plugin

This plugin talks to an https server to retrieve runescape login details and randomly takes screenshots every couple of minutes
I tried to add a pull request before but i got this error "This plugin requires a review from a Plugin Hub maintainer. The reviewer will request any additional changes if needed."

"Requires maintainer review." How can i get it checked by a maintainer ?

We aren't interested in adding this plugin because it is clearly just for running a gold farm.

"Requires maintainer review." How can i get it checked by a maintainer ?

Maintainers have already closed your pull requests twice. I would take that as a sign that this isn't something that would be considered for inclusion on the hub.

We aren't interested in adding this plugin because it is clearly just for running a gold farm.

what the plugin does is just to retrieve runescape login details for more secure login without giving the email and pass and take a screenshot of the client every 10min, it's meant to not expose the login details and keep track of the account progress

authors: Adam- YehiaHelal cdfisher


text:
Varlamore House Thieving Bonus Chest Indicator Broken After Using Mark Object Function

Type
Incorrect behavior
Operating System
Windows
OS Version
Win 10
Bug description
Arrows indicating bonus chest in the Varlamore thieving minigame were only displaying for a couple of frames before disappearing. Often arrow does not appear at all, but object is is highlighted for a frame and then appears normal.
Issue first appeared after marking chests using Object Markers, but persisted after objects were unmarked, after resetting Object markers plugin and  even after  disabling object markers plugin enabled.
Tried without 117 HD, tried without House Thieving plugin, issue still persisted.
Solved temporarily by logging into the official client, playing the minigame, then logging back into Runelite. After 1 round of thieving round of rounds, issue reappeared.
Screenshots or videos
Broken Thieving Minigame.webm
Temporarily Fixed After Using Official Client.webm
Using Official Client.webm
RuneLite version
Runelite Version: 1.10.26.4
Launcher Version: 2.6.8
Logs
client.log
launcher.log

Can you try to replicate this problem in safe mode? Its my belief this is because of the hub plugin.
I've been using it while stealing the keys, and have noticed the single available arrow immediately jumps to the door, as soon as the child is done baiting the wealthy citizen. So a similar issue where the arrow is getting pulled somewhere else, feels like it's happening for you.
https://github.com/runelite/runelite/wiki/FAQ#how-do-i-run-runelite-in-safe-mode

I was able to replicate this issue while running in safe mode

This issue occurs for me while holding a clue scroll that has been read (and therefore has the clue step infobox on-screen). In my case this is an easy clue scroll with the "Dwarven Mine Crate" step, although I very highly doubt that the issue is that specific.
I am able to reliably reproduce the issue by reading this clue scroll, and reliably resolve the issue by banking or dropping the clue scroll.

This looks like it may be the same bug as #6938.

I've found I am unable to see the arrows with clue scrolls (only checked easy) open. My arrows will show up with the House Thieving Varlamore plugin.

source: gharchive/issue

authors: DrZaiusOB Felanbird KyleSocks Sellyme emuise

repo: runelite/runelite


text:
Request focus "force" does not work when RuneLite is minimized

Type
Incorrect behavior
Operating System
MacOS
OS Version
MacOS Monterey (12.7.5)
Bug description
The request focus notification setting "force" only works when the RuneLite window is either not focused or hidden (command+H). If RuneLite is minimized, it doesn't work. Adding the below code snippet in requestForeground() of runelite-client/src/main/java/net/runelite/client/util/OSXUtil.java resolves the issue (i.e. the forced notification retrieves the minimized window), however I'm not sure of the broader implications of this change on other parts of the code.
if (frame.getState() == Frame.ICONIFIED)
{
    frame.setState(Frame.NORMAL);
    log.debug("Restored minimized window to normal state");
}

Screenshots or videos
No response
RuneLite version
RuneLite version: 1.10.38.1
Launcher version: 2.7.2
Logs
No response

It would be best to put a setState() inside of forceFocus() I think. The tray icon focus code has this which is similar:
				if (OSType.getOSType() == OSType.MacOS && !frame.isFocused())
				{
					// On macOS, frame.setVisible(true) only restores focus when the visibility was previously false.
					// The frame's visibility is not set to false when the window loses focus, so we set it manually.
					// Additionally, in order to bring the window to the foreground,
					// frame.setVisible(true) calls CPlatformWindow::nativePushNSWindowToFront.
					// However, this native method is not called with activateIgnoringOtherApps:YES,
					// so any other active window will prevent our window from being brought to the front.
					// To work around this, we use our macOS-specific requestForeground().
					frame.setVisible(false);
					OSXUtil.requestForeground();
				}
				frame.setVisible(true);
				frame.setState(Frame.NORMAL); // Restore

but I am not sure how much of this is necessary. In particular it seems to think that flipping isVisible is also required

authors: Adam- oschei


text:
All items from one tag get displayed in another if it starts with the others tag name

Describe the bug
If you have two tags and the second tag starts with the name of the first, the items shown in the first tags tab will display the items from the second too.
For example:
Take two tabs vorkath and vorkath-loot. Adding items to vorkath-loot tag will mean that it displays in vorkath tag tab too.
This is due to the tags being searched using startsWith (line:133 TagManager.java).
This behavior is good when using the search bar as you might only type in the first few letters but when selecting tabs it should behave differently but it uses the same methods to search for the items.
Obviously, a workaround can be to have tags never starting with an existing tag.
So instead of it being vorkath-loot you could have loot-vorkath instead. It works but may not be ideal for every use case.
To Reproduce
Steps to reproduce the behavior:

Create a tag tab called 'tagliatelle'
Create a tag tab called 'tag'
Add an item to the 'tagliatelle' tag
It will appear in the tag tab too

That's by design

I see how it's by design when searching for tags but makes less sense when using tab tags as you have selected to only see what's under that exact tag and not everything that follows, otherwise you'd just search

Don't name your tag tagliatelle then. It's so you can do Slayer - Melee and Slayer - Magic then search Slayer and it returns all of them

Okay, it seemed to me like the tab tags had a different use case to searching for tags. I was just mistaken about that and I will close this issue.


text:
Additional Text methods, FriendNote wrapping

Added some new methods to the Text class
FriendNotes will now wrap according to pixel width ignoring tags
Would like to add another method to strip specific tags and preserve others.
Later of course 😂

Feels to me like we should just enforce some maximum tooltip width at the TooltipManager level, not for individual plugins.

Enforcing this at the TooltipManager level makes a lot of good sense. @Rheon-D if you don't have the time to do that, I can give it a shot.

authors: Hoten Nightfirecat Rheon-D


text:
Agility plugin: highlight multiple marks

fixes #5893

Is this actually possible in practice?

Yes. Most courses have multiple mark spawn locations, and marks do not despawn for ~10 minutes.

authors: Adam- Nightfirecat SebastiaanVanspauwen


text:
Project active?

I was wondering if the project is still active?
Thanks,
Darren

It is, I've just not had a lot of time recently to get some needed changes sorted. I hope to do some housekeeping this weekend :)

@rupa thanks for clarifying :+1: :)

authors: darrenhaken rupa

repo: rupa/z

license: WTFPL


text:
[Add]  DSA playlist in Python

Site URL
https://www.youtube.com/playlist?list=PLrk5tgtnMN6TYBW0-U4YhIRyYEVpqVEnJ
Description of the above provided site
Data Structures and Algorithms form the backbone of computer science and software development. These topics are vital for any programmer aiming to excel in the industry. As Python is a widely used language in the tech industry a dedicated playlist on these topics in Python would be a valuable addition.
Category
Youtube
Sub Category
Data Structures
Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I am willing to work on this issue (optional)
[X] I am a GSSoC'23 contributor

You may start working on it

repo: rupali-codes/LinksHub

license: MIT


text:
Fix CI

What
Fix CI's start timing.
Why
If don't fix it, CI publish to npm repo every time master is updated

Sorry I wrong to rebase ...

repo: ruritoBlogger/gsap-animation-library


text:
add latest version of armadillo library

Does not use the build-in cmake files because they are ment to build a
convenience library that automatically determines installed dependencies
and links those.
This would prevent the possibility to install those dependencies via
hunter, because the cmake script would not find them. (Right??)
I will add older versions later.
Should the Armadillo repository be transferred to https://github.com/hunter-packages ?

Should the Armadillo repository be transferred to https://github.com/hunter-packages ?

@ThomasFeher Ok, see https://github.com/hunter-packages/armadillo

This would prevent the possibility to install those dependencies via
hunter, because the cmake script would not find them

To be precise if they are not installed system-wide script will fail. If they are installed system-wide this may or may not conflict. See https://github.com/ruslo/hunter/wiki/usr.adding.new.package.with.dependencies. Of course it's better to add all dependencies to Hunter first but non-hunterized version can be used for now as a workaround.

Does not use the build-in cmake files because they are ment to build a
convenience library...

It's better to patch CMake code than adding new scheme. I hope that sometime other schemes will be removed and only url_sha1_cmake.cmake will left. From what I see only headers of library is used. You can add an option to the CMake code (like ARMADILLO_INSTALL_ONLY_HEADERS) and install INTERFACE library. There are a lot of boilerplate code but It's quite trivial, see example: https://github.com/ruslo/leathers/blob/master/CMakeLists.txt#L91

Ok, I will have a look into the install interface library approach. This will mainly mean bypassing all cmake code and just adding the install target. I will also try to get this upstream, but it will take a while, because I'm quite busy at the moment.
Just to clarify: Armadillo is a header only library. All dependencies are optional. The cmake script is, in my opinion, just for quickly testing it. For  serious use one will just use the headers and configure the used dependencies as needed. On Windows the cmake script won't even do anything, see https://github.com/hunter-packages/armadillo/blob/master/CMakeLists.txt#L59 .

Ok, I will have a look into the install interface library approach

@ThomasFeher Cool, thanks

Seems abandoned. Feel free to reopen on updates.

authors: ThomasFeher ruslo

repo: ruslo/hunter

license_source: bigquery


text:
Region and Client updates

A few changes here to make the client interfaces more ergonomic:

Region is now Copy and Display
Stuff that used to take a &Region now takes a Region
Clients now use a type parameter instead of a box to be generic over credentials providers

The diff on src/s3.rs is a bit of a mess because there were a huge number of whitespace errors in that file. All the real changes to it are for the above points. I also killed some code that was commented out or simply never called. We can look at it in the Git history if it's needed for reference later, but I think having dead code checked into the repository makes it harder to understand the crate for new contributors, and harder for us to maintain.

LGTM.
We should do something better about the S3 bits - the integration tests matter and I'd like to keep them around.  Having them commented out was for ease of testing S3 codegen.  I'm not sure what the best solution is aside from finishing said codegen.  Feels a bit like eating an elephant at times!

authors: jimmycuadra matthewkmayer

repo: rusoto/rusoto

license: mit


text:
Cancelled is not Copy

I'd love to have a backtrace in Cancelled to be able to debug "completion is always cancelled" problem. So it probably is a good idea to make Cancelled non Copy type, even if it is a ZST in prod.

bors r+

repo: rust-analyzer/rust-analyzer


text:
fix: use vscode.FileSystem API for globalStorage

I encountered an error where bootstrap() attempts to create a directory with the path C:\C:\.... I couldn't find this reported anywhere else. Using the vscode.FileSystem API instead of the fs one works here. I assume the latter automatically prepends C:\ to paths whereas the former does not. I don't know if this suggests vscode.FileSystem should be used in more places for consistency.

yeah, ideally we should never use bare fs are there other places we might want to adjust this?

Well, it looks like fs is used in main.ts, net.ts, and toolchain.ts, at least. I don't immediately see any situations where vscode.FileSystem would be insufficient. I'm AFK at the moment but can look into replacing those calls later.
I guess the question at this point is which API is more stable and if the VS Code one has drawbacks I'm not aware of. I admit I'm not very familiar with Node/TypeScript, so please correct me if I'm mistaken on anything :)

I replaced some cases of low-hanging fruit using fs with vscode.FileSystem equivalents. As the VS Code API uses vscode.Uri for file paths (and not plain old strings), I also introduced some Uri.file() and Uri.joinPath() code to avoid Node's path module. I would have liked to completely eliminate the need for path and fs, but unfortunately:

vscode.Uri is kind of limited, and vscode.FileSystem lacks some functionality (e.g., createWriteStream()) of fs
vscode.Uri.file() prepends / to the given path, which is undesirable when referencing executables in the PATH

The root cause is that in 95c51d8f1df1efdb2e98b7717544a6db8cad14e7
- this.globalStoragePath = ctx.globalStoragePath;
+ this.globalStoragePath = ctx.globalStorageUri.path;

Uri#path returns /C:/Users/XXX on Windows. The correct property should be Url#fsPath (https://code.visualstudio.com/api/references/vscode-api#details-418), it returns c:\Users\XXX
I'm too familiar with new APIs like vscode.FileSystem thus don't know which one is better.

Thanks for clarifying, @yume-chan. As I was exploring the VS Code API I noticed that deprecation, but I didn't realize what exactly the cause for the path error was.
At the end of the day, the simplest solution would be to rollback my commits and replace path with fsPath; that would at least accomplish the original goal of this PR. However, looking through the VS Code extension code, I think the way we're using raw strings to represent paths and importing the Node fs module for FS operations is a bit messy. At the same time, I don't know if replacing fs with vscode.FileSystem will be a regression in this case. Perhaps a wrapper that uses the VS Code API as a base and draws from Node when necessary is warranted?

I thought vscode.FileSystem was added for Language Server type extensions to support virtual file systems, but the extension global store in this case should always be on the local disk, so Node.js fs module will work.
However when reading the documentation more carefully, I found this:

> globalStorageUri: Uri
[...]

see - workspace.fs for how to read and write files and folders from an uri.

-- https://code.visualstudio.com/api/references/vscode-api#ExtensionContext.globalStorageUri

So maybe Code expects extensions to use vscode.FileSystem to operate on globalStorageUri.

Personally, I think Uri.fsPath is still a 'correct' way to do this, documentation wise. I found this in Uri.fsPath:

The resulting string shall not be used for display purposes but for disk operations, like readFile et al.

I didn't previously consider your comment about virtual file systems, but seeing as globalState is always local, I think this solution is fine for now.

I've pushed a fix to just use fsPath, which fixed the immediate issue. However, switching from fs to vscode.fs is something we need to do as well, so it's best to rebase this PR on master!
Thanks a bunch for figuring this all out @wxb1ank and @yume-chan, it was instrumental in preparing the quick fix for todays release!

I found a vscode-python extension that documents their transition from Node's fs to vscode.FileSystem: https://github.com/microsoft/vscode-python/issues/8533. I think this proves that the latter can (mostly) replace the former. I will rebase and look into this later this week.

Sorry it took me a bit. Coming back to this, it looks like only net.ts uses the fs module now. Unfortunately, I still don't see a good solution to this: AFAIK, vscode.FileSystem can't modify file permissions (.e.g., make the downloaded executable rx), nor does it provide a suitable alternative to fs.createWriteStream() (necessary for storing gunzip streams*).
I've linted and rebased, and I think this is ready for review again.
*We also need a way to store non-gunzipped (gzipped?) streams. node-fetch conveniently provides Response.buffer() for this.

bors r+
Let's see if this breaks anything :D

authors: matklad wxb1ank yume-chan


text:
Update CI

Closes #15.
Prerequisite:

[ ] Create rust-av/av1-grain project on codecov.io
[ ] Add a secret called CODECOV_TOKEN to this repository

Changes:

Run all CI on ubuntu (no platform-specific code)
Switch to codecov
Update MIRIFLAGS

Removed:

valgrind, fuzzing (stubs)
rust-code-analysis
weighted-code-coverage

rust-code-analysis and weighted-code-coverage could arguably be added back, but I'm not sure it's necessary to run these in CI.

Should probably fix clippy errors first, to see the actual CI runs.

@lu-zero I am not sure who has the permissions for this, but can you add a codecov token for this repository (instructions)? Or maybe ping someone who can? Thanks in advance


text:
deserialize for Transaction Err if there are no transaction inputs

Hi!
Took me some time to understand why I had the issue. I have not yet investigated in rust-bitcoin code to understand the issue/propose a fix yet.
Raw transactions which do not include inputs are not properly handled.
This test fails on latest rust-bitcoin/master
#[test]
fn test_transaction_no_vin() {
    let hex_tx = hex_bytes("02000000000100ca9a3b00000000160014716f8e8fa281cb42bb6900ce35b73a13fa3e66e000000000").unwrap();
    let tx: Result<Transaction, _> = deserialize(&hex_tx);
    assert!(tx.is_ok());
}

If you replace the assert with tx.unwrap() you would get the following stack:
thread 'blockdata::transaction::tests::test_transaction_no_vin' panicked at 'called `Result::unwrap()` on an `Err` value: ByteOrder(Custom { kind: UnexpectedEof, error: StringError("failed to fill whole buffer") })', libcore/result.rs:945:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: <std::panicking::begin_panic::PanicPayload<A> as core::panic::BoxMeUp>::get
             at libstd/panicking.rs:463
   5: std::panicking::try::do_call
             at libstd/panicking.rs:350
   6: std::panicking::try::do_call
             at libstd/panicking.rs:328
   7: <&'a T as core::fmt::Display>::fmt
             at libcore/panicking.rs:71
   8: core::result::unwrap_failed
             at /Users/travis/build/rust-lang/rust/src/libcore/macros.rs:26
   9: <core::result::Result<T, E>>::unwrap
             at /Users/travis/build/rust-lang/rust/src/libcore/result.rs:782
  10: bitcoin::blockdata::transaction::tests::test_transaction_no_vin
             at src/blockdata/transaction.rs:934
  11: bitcoin::__test::TESTS::{{closure}}
             at src/blockdata/transaction.rs:931
  12: core::ops::function::FnOnce::call_once
             at /Users/travis/build/rust-lang/rust/src/libcore/ops/function.rs:223
  13: <F as alloc::boxed::FnBox<A>>::call_box
             at libtest/lib.rs:1451
             at /Users/travis/build/rust-lang/rust/src/libcore/ops/function.rs:223
             at /Users/travis/build/rust-lang/rust/src/liballoc/boxed.rs:638
  14: panic_unwind::dwarf::eh::read_encoded_pointer
             at libpanic_unwind/lib.rs:105
test blockdata::transaction::tests::test_transaction_no_vin ... FAILED

Please note that bitcoind is able to decode the said transaction:
Request
{
    "jsonrpc": "1.0",
    "id":"curltest",
    "method": "decoderawtransaction",
    "params":
["02000000000100ca9a3b00000000160014716f8e8fa281cb42bb6900ce35b73a13fa3e66e000000000"
    ]

}

Response
{
    "result": {
        "txid": "e8069d1704d4d194f3fd6c85081851a8bc093a9f03da1be75065b961ddee1572",
        "hash": "e8069d1704d4d194f3fd6c85081851a8bc093a9f03da1be75065b961ddee1572",
        "version": 2,
        "size": 41,
        "vsize": 41,
        "locktime": 0,
        "vin": [],
        "vout": [
            {
                "value": 10,
                "n": 0,
                "scriptPubKey": {
                    "asm": "0 716f8e8fa281cb42bb6900ce35b73a13fa3e66e0",
                    "hex": "0014716f8e8fa281cb42bb6900ce35b73a13fa3e66e0",
                    "reqSigs": 1,
                    "type": "witness_v0_keyhash",
                    "addresses": [
                        "tb1qw9hcarazs8959wmfqr8rtde6z0aruehqt6m3m7"
                    ]
                }
            }
        ]
    },
    "error": null,
    "id": "curltest"
}

Looking at struct Transaction it does not look like input must be present so at this stage I am thinking about a bug in the deserialize function.
2 proposed way forward:

Support transaction without inputs
Improve the failure message to make it easier to debug

Let me know how you would prefer to move forward and I may be able to look into a patch.

The transaction there includes the SegWit flag byte, which is nonsense for a 0-input transaction. Ultimately that is a rather strange encoding that Bitcoin Core probably shouldn't be able to deserialize either. Out of curiosity, what encoded that transaction?
Obviously we should have a better error message here, but failing to decode that is correct, I think.

There isn't much we can do here - SegWit introduced ambiguity in encodings for 0-input transactions. Ultimately the best solutions is proabbly PSBT (see #103). Better errors would be nice, but ultimately decoded non-SegWit-flag-included 0-input transactions isn't ever reliably possible. Bitcoin core has some heuristics for attempting to do so, but can also guess wrong, which could be very dangerous in some cases.

repo: rust-bitcoin/rust-bitcoin


text:
Improve error handling in errors emmited by keys

For now I have tried to group those functions which can produce more than one error and changed the functions which were  generating single error from Key::Error to the respective error. Let me know if this needs to be changed.
Also in psbt/error.rs I have changed the InvalidPublicKey(crate::crypto::key::Error) to InvalidPublicKey(crate::crypto::key::FromSliceError). What should be done here?
Changes -

in from_slice changed the error to FromSliceError.
in verify changed to secp256k1::Error as it can return only one error.
in from_str changed to FromSliceError.
in CompressedPublicKey changed verify from Error to secp236k1::Error as it only returns one error.
introduces CompressedPublicKeyError
Removes impl from bip32.rs

Potential fix #2291

It looks like there are a few CI failures -- I'd like those to be fixed before reviewing.
Also, as a matter of policy, all commits should pass all tests. The easiest way to check this is to run git rebase -x "cargo test --all-targets --all-features" master, which won't check everything but is likely to catch typos or simple mistakes. (If there are more subtle issues, like certain feature combinations not working, then I will show up and complain :)).

I ran the test cases and build the package locally, I did not find any errors though. I also ran the command that you mentioned and push the changes. But the CI is still failing I don't know why.

Feature gating appears incorrect. Look at another example of error code in the codebase to see how to do it.

You may need to add --no-default-features to your cargo invocations to disable the std feature, and then I think the errors will become apparent.

Pull Request Test Coverage Report for Build 7606875932

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.06%) to 84.205%

Totals

Change from base Build 7601948115:
-0.06%

Covered Lines:
19229

Relevant Lines:
22836

💛  - Coveralls

@tcharding Should I put all the error types at the end of the file in the sequence that you mentioned?

Should I put all the error types at the end of the file in the sequence that you mentioned?

TL;DR - In this case they seem to be all at the bottom of the file above unit tests, I would leave them there.
More generally, you can put the error types where ever you like, there is no hard and fast rule (AFAIK). I sometimes put them below where they are used but most often I personally put them at the bottom (right above the unit tests). Please definitely don't put them at the top of the file (but that is just my personal pet peev).
Thanks

It could probably be merged but I think it'd be nicer to just solve the variants right away.

I could be wrong but I think fixing the length stuff could require some curly generics changes, I'm inclined to let this one in as is. Of course if I'm wrong and you can get this working @Harshit933 all well and good, I would punish yourself with it though.

I really like this PR.

I also really like the Doom avatar :)

Holy-moly @Kixunil's review makes me feel like a very bad reviewer by acking :(

@tcharding don't worry, happens in reverse too.

@Kixunil @tcharding Thanks for reviewing this much bad code. I am learning quite a lot here.

Lets just get this in, there is some open work that is going to touch theses lines of code straight away, I'll clean them up when I do it.

Sorry guys, this conflicts with #2445 which adds a new method returning UncompressedPubkeyError. This needs to be rebased and that return changed to UncompressedPublicKeyError.
I should've merged this one first, but I got lazy and did the small PRs first this morning.

Rebased :)

I don't know why the CI is failing

It was a fluke, I re-ran the CI and it's OK now.

@apoelstra can I be a bore and get you to merge this please?

authors: Harshit933 Kixunil apoelstra coveralls tcharding yancyribbens


text:
Run the formatter

I don't want to wait for the bot, just run the formatter now.
No manual changes.

My displeasure is mainly about having to review things that don't seem priority to me and have very little value.

You could trust the PR title to mean "no changes here, nothing to review".

authors: Kixunil apoelstra tcharding


text:
Remove feature gated enum variants

This is the updated version of #874 (which I closed, force pushed, and then was unable to re-open - my bad).
Feature gating enum variants makes code that uses the library brittle while we do not have non_exhaustive, we should avoid doing so. Instead we can add a dummy type that is available when the feature is not turned on. Doing so enables the compiler to enforce that we do not create the error type that is feature gated when the feature is not enabled.
Remove the feature gating around bitcoinconsensus error enum variants.
Closes: #645

Needs rebase because of #806, sorry

No changes in force push, rebase only.

Because of this comment: https://github.com/rust-bitcoin/rust-bitcoin/pull/874#discussion_r823613829

Because of this comment: https://github.com/rust-bitcoin/rust-bitcoin/pull/874#discussion_r823613829

I do not agree with that. Commented there

Oh, I thought your comment was just in the general case. I'll put some more thought into digesting the whole thread of discussion again. Thanks for re-stating you position.

Rebased on master and added all derives as suggested by @dr-orlovsky (+ Clone).

Though I am also a little confused why we're dropping derives in this PR.

PR no longer does this.

authors: apoelstra dr-orlovsky tcharding


text:
Add NOR flash trait

This is my first try of a NOR flash trait.
try_read, try_write and try_erase are similar to ReadWrite, but with different semantics.
Additionally it can return up to 4 regions with differing erase sizes to account for flashes that support some erase sizes only for specific address ranges.
Ate the moment regions and erase_sizes return heapless::Vec. I don't know if this is the optimal way to go.
This was discussed in #1 and #3.

I thought adding a simplified version for everyone who doesn't want to deal with the complexity of different regions is a good idea.

@Sympatron Could you rebase this?

@Sympatron Could you rebase this?

authors: MathiasKoch Sympatron


text:
objcopy produces an empty file

I have executed the following commands, both on Windows 10 and on Rasbian 10. All of them produce an empty file. Is this a bug or am I doing something wrong?
cargo objcopy --release --target thumbv7em-none-eabihf --bin main -- -O binary asdf.bin
cargo objcopy --target thumbv7em-none-eabihf --bin main -- -O binary asdf.bin
cargo objcopy --release --target thumbv7em-none-eabihf -- -O binary asdf.bin
cargo objcopy --release --target thumbv7em-none-eabihf -- -O binary asdf.bin

My main.rs looks like this:
#![no_std]
#![no_main]

use panic_semihosting as _;

use cortex_m_rt::entry;
use nrf52840_hal::clocks::Clocks;
use nrf52840_hal::usbd::{UsbPeripheral, Usbd};
use nrf52840_pac::Peripherals;
use usb_device::device::{UsbDeviceBuilder, UsbVidPid};
use usbd_serial::{SerialPort, USB_CLASS_CDC};

#[entry]
fn main() -> ! {
    let periph = Peripherals::take().unwrap();
    let clocks = Clocks::new(periph.CLOCK);
    let clocks = clocks.enable_ext_hfosc();

    let usb_bus = Usbd::new(UsbPeripheral::new(periph.USBD, &clocks));
    let mut serial = SerialPort::new(&usb_bus);

    let mut usb_dev = UsbDeviceBuilder::new(&usb_bus, UsbVidPid(0x16c0, 0x27dd))
        .manufacturer("Fake company")
        .product("Serial port")
        .serial_number("TEST")
        .device_class(USB_CLASS_CDC)
        .max_packet_size_0(64) // (makes control transfers 8x faster)
        .build();

    loop {
        if !usb_dev.poll(&mut [&mut serial]) {
            continue;
        }

        let mut buf = [0u8; 64];

        match serial.read(&mut buf) {
            Ok(count) if count > 0 => {
                // Echo back in upper case
                for c in buf[0..count].iter_mut() {
                    if 0x61 <= *c && *c <= 0x7a {
                        *c &= !0x20;
                    }
                }

                let mut write_offset = 0;
                while write_offset < count {
                    match serial.write(&buf[write_offset..count]) {
                        Ok(len) if len > 0 => {
                            write_offset += len;
                        }
                        _ => {}
                    }
                }
            }
            _ => {}
        }
    }
}

I have confirmed that the compiled ELF binary does in fact exist and is not an empty file. cargo size also shows a size of 0.
Toolchain info:
cargo 1.57.0
stable compiler
llvm-tools-preview has been added as a rustup component

Have you set a linker script? Something like this line in a .cargo/config.toml file: https://github.com/rust-embedded/cortex-m-quickstart/blob/master/.cargo/config.toml#L18
Without telling cargo to tell Rust to pass -Tlink.x to the linker, your output elf is generated but doesn't have any sections and so the raw binary is empty.

I didn't do that! Is there documentation on this mysterious linker argument so that I can learn more? In the embedded book perhaps?
Does this have anything to do with memory.x? I saw something about that too but don't know what it is or how to configure it

Theres a very small section on it in the embedded book
https://docs.rust-embedded.org/book/start/hardware.html#configuring
And that cortex-m-quickstart is kind of a canonical form of an embedded project and always a good place to check if you're missing something

The memory.x and -Tlink.x stuff fixed it, thank you!

Any chance this could have some diagnostics for it to make this error more debuggable for people like me?

Hm, it's a good idea but it might be tricky to implement here, since this crate is really just providing a convenient wrapper around the Rust distribution objcopy and friends. It might be possible to check for an empty output and print a warning but doing so might mess up workflows that expect the behaviour to match the underlying objcopy. Still maybe that's worth it...
I think that ideally, the error would instead be caught earlier, since the real problem is that your elf is bad before objcopy even sees it and for people using the elf directly (with e.g. cargo-flash/cargo-embed/probe-run) a change here won't help them. If cortex-m-rt could detect the missing linker script somehow instead that would be ideal.

ok, I guess I should close this then

authors: TheButlah adamgreig jacobrosenthal

repo: rust-embedded/cargo-binutils


text:
Fix link text in README.md

On #472 PR I used [Docker] and [Podman] however I didn't notice that they were not defined.

bors r+

authors: Dylan-DPC oblique

repo: rust-embedded/cross


text:
How to read incoming data from SPI MOSI Lane? (not MISO)

I am working on a specific epd which requires to read data from the MOSI line after sending a command but switching the CS pin between each byte. It's unclear to me if this is even achievable with the SPI Bus implementation. If so some guidance would be appreciated.
Some relevant parts from the documentation:

Here it also states that a CS pulse is necessary between each read.

I thought something like this would be working:
    pub fn read_otp(&mut self, buffer: &mut [u8]) -> Result<(), E> {
        self.bus.lock(|bus| {
            let mut bus = bus.borrow_mut();

            self.cs.set_low().ok();
            // Command mode
            self.dc.set_low().ok();

            // Send read command
            bus.write(&[0xA2])?;

            self.dc.set_high().ok(); // Data mode

            // Read data
            for byte in buffer.iter_mut() {
                self.cs.set_high().ok();
                self.cs.set_low().ok();

                // Send dummy byte and read the result
                let mut read_buf = [0u8];
                bus.transfer(&mut read_buf, &[0x00])?;
                *byte = read_buf[0];
            }

            self.cs.set_high().ok();
            Ok(())
        })
    }

but then i found out that the transfer also wants to read on the MISO line.

This looks like a non-standard variation of SPI.
While it may (or may not) be supported by the SPI hardware of your microcontroller, it's not something supported by the abstraction layer provided by embedded-hal.

authors: Syphixs jannic

repo: rust-embedded/embedded-hal


text:
Accessor newtypes

Part 2 of #463, builds on #464.

Wraps register reader/writer and field readers in newtype wrappers, which significantly improves the documentation output.

Again there's some minor potential for breaking changes:

If users named the complete type of the previous type alias, it would break.  It seems more likely that they would use the alias, which will silently upgrade to a reference to the newtype.

r? @burrbull

bytes
master
#464
#465

debug
1090816
1094812
1471756

release
7016
7016
105180

Oh my this really blows up the size of the release build!  I thought that the newtype pattern was basically optimized away by the compiler, but it seems that either something is preventing that from happening or the compiler's handling of it is not as good as I thought it was.

Upon closer inspection, most of that extra junk is in .symtab.  After strip --strip-unneeded, the numbers are:

bytes
master
#464
#465

debug
11148
11148
11772

release
2444
2444
2732

My intuition is that .symtab won't get shipped to flash anyway, so these numbers would be more representative of the real impact.  Is that right?
As a general matter, what's the best way to do this sort of profiling?

Ok I've stumbled onto size, which seems appropriate for the job.  Running that against the binaries here gives me:

debug
master
#464
#465

text
9386
9386
10010

data
1250
1250
1250

bss
1
1
1

release
master
#464
#465

text
1862
1862
2150

data
74
74
74

bss
1
1
1

Rebased on top of master, please take another look.

Re: https://github.com/rust-embedded/svd2rust/pull/466#issuecomment-670553172
For Rahix/avr-device:
$ du --summarize src-*
8884	src-465
7920	src-master

For lpc-rs/lpc-pac:
$ du --summarize lpc*-*
4540	lpc11uxx-465
4168	lpc11uxx-master
7072	lpc176x5x-465
6296	lpc176x5x-master
278760	lpc54606-465
277548	lpc54606-master
4720	lpc82x-465
4212	lpc82x-master
118212	lpc845-465
117632	lpc845-master

There's some increase in the generated code size, but not a lot.

Size increase looks reasonable. There's still a lot of (medium high hanging) fruit to pick.
I'll soft approve and let give @burrbull have a second look.

authors: couchand therealprof


text:
Bring back futures::stream::futures_ordered?

This function used to exist, but no longer does. It's relative futures_unordered still exists though: https://github.com/rust-lang-nursery/futures-rs/blob/master/futures-util/src/stream/mod.rs#L135-L144

Errr, not sure what I was saying, it looks like from_iter is the way to do this.

repo: rust-lang-nursery/futures-rs


text:
Release 0.3.0-alpha.18

The last release was about a month ago and we've gotten a bunch of improvements to this crate like join! and try_join! being implemented as proc macros etc. I think its about time we think about releasing alpha 18.
cc @cramertj @Nemo157 @taiki-e

Sure, I can do a release tomorrow.

This is done.

authors: LucioFranco cramertj


text:
add associated constants to items reference

related to https://github.com/rust-lang/rust/pull/42809

🎊

authors: seanmonstar steveklabnik

repo: rust-lang-nursery/reference


text:
PartialOrd for opaque?

In #882 (PR #1002) we used PartialEq analysis to analyse whether we can derive PartialOrd. Generally this makes sense because if PartialEq can be derived then PartialOrd can be derived too.
But there is a problem. I can imagine what means for opaque types to be PartialEq: we just have to compare byte-by-byte both blobs. But I have a problem imaging what we should do in case of PartialOrd: compare each byte in both blobs?
Maybe we should split result of the analysis and explicitly state whether we can derive PartialOrd or not?

Writing this down I realized that it makes no sense to derive PartialEq for blobs either!
I'm not a compiler wizard, but isn't it is at least incorrect (if not UB) to compare byte-by-byte two structs because of stuff like padding bytes which, if I understand correctly, have undefined values.

Good point about padding. I guess we should only be "manually" implementing these things so that we don't look into padding.
Or I guess we could define a special type for padding that implements various traits with some kind of default/no-op that doesn't actually read the padding bits, and then we could still derive and the padding would effectively be skipped over.
This doesn't apply for opaque blobs of course.

@emilio if we stopped deriving traits for opaque things (except maybe Debug?), would that have bad implications for Stylo?

authors: fitzgen pepyakin

repo: rust-lang-nursery/rust-bindgen


text:
Prepended underscores in macro identifiers are incorrectly removed

Running cargo +nightly fmt on the following code breaks it:
Original
macro_rules! assert_success_data {
    ($__r:expr, $__p:pat, $__x:expr) => {
        match $__r {
            Response::Success($__p) => $__x,
            __u => assert!(false, format!("unexpected response {:?}", __u)),
        }
    };
}
fn main() {
    println!("Hello, world!");
}

Formatted
macro_rules! assert_success_data {
    ($__r:expr, $__p:pat, $__x:expr) => {
        match $r { // <---- PREPENDED UDERSCORES REMOVED
            Response::Success($p) => $x, // <---- PREPENDED UNDERSCORES REMOVED
            __u => assert!(false, format!("unexpected response {:?}", __u)),
        }
    };
}
fn main() {
    println!("Hello, world!");
}

Specifically, it seems like $__r, $__p and $__x had their initial underscores removed. What's interesting is that __u in the next match arm is untouched.
rustfmt version: 0.3.8-nightly (346238f 2018-02-04)

Thanks for filing an issue. I am going to close this as this is a duplicate of #2560.

My bad :/ I should have done a better job of searching open issues. I searched for “underscore”, but should also have searched for “_” and “macro”.
I will take a look at the referenced bug and see how hard it is to actually fix, since it’s marked as a “good first issue”.
Thank you!

From: Seiichi Uchida notifications@github.com
Sent: Sunday, April 1, 2018 9:54:26 AM
To: rust-lang-nursery/rustfmt
Cc: Allen George; Author
Subject: Re: [rust-lang-nursery/rustfmt] Prepended underscores in macro identifiers are incorrectly removed (#2585)
Closed #2585https://github.com/rust-lang-nursery/rustfmt/issues/2585.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/rust-lang-nursery/rustfmt/issues/2585#event-1551114165, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAEO9GL4nYvdb7h_1cOgo7cqldMyGDYXks5tkNwSgaJpZM4TCyjn.

@allengeorge No worry! Also the issue is already fixed on the current master :)

Ah :) TY!

From: Seiichi Uchida notifications@github.com
Sent: Sunday, April 1, 2018 10:41:13 AM
To: rust-lang-nursery/rustfmt
Cc: Allen George; Mention
Subject: Re: [rust-lang-nursery/rustfmt] Prepended underscores in macro identifiers are incorrectly removed (#2585)
@allengeorgehttps://github.com/allengeorge No worry! Also the issue is already fixed on the current master :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/rust-lang-nursery/rustfmt/issues/2585#issuecomment-377791399, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAEO9HCb_O-QUUSqgW9dq6jjvBR-p6KOks5tkOcJgaJpZM4TCyjn.

authors: allengeorge topecongiro

repo: rust-lang-nursery/rustfmt


text:
config: fix suffices -> suffixes typo

Fixes #1477.

Is backwards compat for the old name wanted to bridge over updates?

Thanks for this!

Is backwards compat for the old name wanted to bridge over updates?

Nah, pre-1.0, etc.

authors: mathstuf nrc


text:
Put match arm's guard on new line if it exceeds max width

Closes #1656.

Thanks!

authors: nrc topecongiro


text:
Cargo no longer seems to build anything using tagged git versions

Tok:rust-array doug$ rustc --version
rustc 0.13.0-nightly (39d740266 2015-01-01 15:51:08 +0000)

Tok:rust-array doug$ cargo --version
cargo 0.0.1-pre-nightly (1a1868b 2014-12-31 21:39:41 +0000)

Tok:rust-array doug$ cargo test --verbose
    Updating git repository `https://github.com/shadowmint/rust-traits`
Unable to update https://github.com/shadowmint/rust-traits?tag=0.1.6

Caused by:
   failed to find tag `0.1.6`

Caused by:
   The requested type does not match the type in the ODB

In Cargo.toml:
[dependencies.traits]
git = "https://github.com/shadowmint/rust-traits"
tag = "0.1.6"

The requested tag exists here:
https://github.com/shadowmint/rust-traits/releases/tag/0.1.6

Seems to compile things fine without the 'tag' or by replacing 'tag' with 'version', although it doesn't download the correct tagged version.
Is this option depreciated? I couldn't see anything in the commit logs for it?

NB. This is the osx nightly from a few days ago, because cargo doesn't currently compile against the rust master, so... can't really test cargo head to check if this is already resolved.

Thanks for the report! It looks like that git repo has tags of a form that we weren't quite expecting, and I think I've fixed this in https://github.com/rust-lang/cargo/pull/1122

authors: alexcrichton shadowmint

repo: rust-lang/cargo


text:
Job server strongly conflicts with multithreaded linkers

Problem
Normally, cargo is only ever indirectly running one linker at a time, at the very end of compilation, and so, multithreaded linkers don't really matter. However, for cargo test, these linkers might be run in parallel, and cargo makes the assumption that all of these linkers are single-threaded, which is not the case for mold.
This can result in a potentially quadratic number of threads being run at the same time, which can crash systems.
Proposed Solution
One simple solution for the specific case of mold as a linker is to pass the MOLD_JOBS=1 environment variable to rustc, which will then be passed to the linker, which will then tell mold to ensure that the number of instances of the linker running at the same time is only ever one. This still means that the number of concurrent threads can be double what the CPU supports, since there can still be concurrent rustc jobs at the same time as the linker, but it won't end up being quadratic. However, this makes more sense as a mitigation done by users instead of something done by Cargo, since it affects the environment for more users than it needs to affect.
A potentially better solution is to delay all linking tasks until the very end of compilation, and have the option to run them serially instead of in parallel. This could be detected automatically via -Clink-args=-fuse-ld=mold, but more it would probably be fine just as a configurable flag initially. It's not really possible to separate the linking from rustc at the moment, but at least limiting the rustc calls that are expected to call a linker until the end seems reasonable.
Notes
At some point, it might be desirable to have the linker fully controlled by cargo, so that there isn't a problem not running them in parallel at the end of compilation. However, this is substantially larger of a change than the one proposed, so, it's left out for now.

Thanks for the idea and the workaround for mold. I didn't know the trick until today!
It seems like a duplicate of https://github.com/rust-lang/cargo/issues/9157. We have a general issue for parallelism controls in https://github.com/rust-lang/cargo/issues/12912. I am going to close this in favor of those. Let us know if you think the issue should be kept open separately :)

Ah, I had tried to search for previous issues but missed that one. Thank you!

authors: clarfonthey weihanglo


text:
Log details of failure if no errors were seen

What does this PR try to resolve?
Crater has started (some time ago, though exact point is not known) to see failures in crates without logging an error. We're suspecting that there's something wrong in Cargo or rustc, but it's also possible that Crater itself is at fault. In any case, this should provide more details.
cc https://github.com/rust-lang/crater/issues/733
How should we test and review this PR?
My hope is that this is reasonable to land without additional tests -- as-is, we expect it to never happen (there's even a debug assert later in the same code path) but it seems it is happening sometimes in the wild.

@bors r+

:pushpin: Commit ecfc89963605634c297510de366fdf50ef08f678 has been approved by weihanglo
It is now in the queue for this repository.

:hourglass: Testing commit ecfc89963605634c297510de366fdf50ef08f678 with merge f2d1e37b56529f5200c3861be8b3d1c24f62c135...

:sunny: Test successful - checks-actions
Approved by: weihanglo
Pushing f2d1e37b56529f5200c3861be8b3d1c24f62c135 to master...

authors: Mark-Simulacrum bors weihanglo


text:
Fix typo in badges section of example manifest

Extremely small typo I saw when I was looking at the new badges feature.

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

@bors: r+
Thanks!

:pushpin: Commit fcc1344 has been approved by alexcrichton

:hourglass: Testing commit fcc1344 with merge 15d697d...

:sunny: Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 15d697d9feaa5333f6cd1e91c62d5fbb5411e6cc to master...

authors: alexcrichton bors malept rust-highfive


text:
Cap lints for upstream deps with -vv

Previously with -vv Cargo didn't pass --cap-lints at all, but with upstream
dependencies we still want to pass at least --cap-lints warn to make sure that
they're all still compiling.
Closes #3823

r? @matklad

r? @brson
(rust_highfive has picked a reviewer for you, use r? to override)

We've basically all but jettisoned support for older compilers, but yeah we definitely don't attempt to test older compilers as well. Note that --cap-lints was added in like 1.4, ages ago!

@bors: r+
Issue to jettison --cap-lints feature detection: https://github.com/rust-lang/cargo/issues/3828

:pushpin: Commit 1982d38 has been approved by matklad

:hourglass: Testing commit 1982d38 with merge 7d2ef41...

:broken_heart: Test failed - status-appveyor

rustc?
or rustc?()
or rustc()?
or ?rustc()
or ¿rustc()
or rustc¿()

:pushpin: Commit 684790f has been approved by matklad

@bors: r=matklad

:hourglass: Testing commit 684790f with merge 19fdb30...

:sunny: Test successful - status-appveyor, status-travis
Approved by: matklad
Pushing 19fdb308cdbb25faf4f1e25a71351d8d603fa447 to master...

authors: alexcrichton bors matklad rust-highfive


text:
Add package spec support to profile overrides.

Note: It errors out if multiple overrides match the same package.  This could potentially merge the overrides together with a hierarchy similar to CSS specificity.  However, that seems overkill for now.

r? @matklad
(rust_highfive has picked a reviewer for you, use r? to override)

@bors: r+
Nice!

:pushpin: Commit 5415a34 has been approved by alexcrichton

:hourglass: Testing commit 5415a341a50aabafaf227c96e65f10b83aff641a with merge b429a3649cf8ee3eb574076cbb6c39ad3a9467f0...

authors: alexcrichton bors ehuss rust-highfive


text:
Use SPDX syntax for license expression

The license is supposed to be an SPDX 2.3 license expression. See https://doc.rust-lang.org/1.75.0/cargo/reference/manifest.html#the-license-and-license-file-fields.
SPDX license expressions support AND and OR operators to combine multiple licenses.
Previously multiple licenses could be separated with a /, but that usage is deprecated.

Thank you for the PR! ❤

authors: dtolnay lcnr

repo: rust-lang/ferris-says


text:
using russh

I would be interested if its technically possible to change the underlying ssh used by libgit2 to be able to for example use russh ?

I expect you'd be able to use git2's transport module to write a custom ssh transport no?

authors: extrawurst vcfxb


text:
make with generics

Suppose you wanted to write a tower-esque trait using RPITIT:
pub trait LocalService<Request> {
    type Response;
    type Error;

    async fn execute(self, request: Request) -> Result<Self::Response, Self::Error>;
}

This now works, but if I want to use make to add a Send variant, the macro fails:
error: expected `:`
 --> src/example.rs:1:30
  |
1 | #[trait_variant::make(Service<Request>: Send)]
  |                              ^

Omitting the generic parameters yields a different error:
error[E0412]: cannot find type `Request` in this scope
 --> src/example.rs:6:37
  |
6 |     async fn execute(self, request: Request) -> Result<Self::Response, Self::Error>;
  |                                     ^^^^^^^ not found in this scope
  |
help: consider importing one of these items
  |
1 + use core::error::Request;
  |
1 + use std::error::Request;
  |

error[E0107]: missing generics for trait `LocalService`
 --> src/example.rs:2:11
  |
2 | pub trait LocalService<Request> {
  |           ^^^^^^^^^^^^ expected 1 generic argument
  |
note: trait defined here, with 1 generic parameter: `Request`
 --> src/example.rs:2:11
  |
2 | pub trait LocalService<Request> {
  |           ^^^^^^^^^^^^ -------
help: add missing generic argument
  |
2 | pub trait LocalService<Request><Request> {
  |                       +++++++++

error[E0107]: missing generics for trait `Service`
 --> src/example.rs:1:23
  |
1 | #[trait_variant::make(Service: Send)]
  |                       ^^^^^^^ expected 1 generic argument
  |
note: trait defined here, with 1 generic parameter: `Request`
 --> src/example.rs:1:23
  |
1 | #[trait_variant::make(Service: Send)]
  |                       ^^^^^^^
2 | pub trait LocalService<Request> {
  |                        -------
help: add missing generic argument
  |
1 | #[trait_variant::make(Service<Request>: Send)]
  |                              +++++++++

Should this be closed?

repo: rust-lang/impl-trait-utils


text:
Add getrandom to FreeBSD

Introduced in FreeBSD 12.0.
Manual page: https://www.freebsd.org/cgi/man.cgi?query=getrandom.
Not sure if the constants should be c_int, just matching the flags argument in the function, in c they're macros.

r? @JohnTitor
(rust_highfive has picked a reviewer for you, use r? to override)

@bors r+

:pushpin: Commit 99b36350794dc5afaaadd1a536c4cc713c3819ae has been approved by JohnTitor

:hourglass: Testing commit 99b36350794dc5afaaadd1a536c4cc713c3819ae with merge 8e62c982741710861007ca711e3f2a0e0ea43908...

:sunny: Test successful - checks-actions, checks-cirrus-freebsd-11, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13
Approved by: JohnTitor
Pushing 8e62c982741710861007ca711e3f2a0e0ea43908 to master...

authors: JohnTitor Thomasdezeeuw bors rust-highfive

repo: rust-lang/libc


text:
Correct Windows argument handling

Previously there were rare edge cases where the command line string would have been incorrectly constructed.
Fixes #1881

Sorry about the noise. Had a bit of trouble with formatting properly.

Thanks a lot for the PR!

Previously there were rare edge cases where the command line string would have been incorrectly constructed.

Can you extend this line and the reference file to check at least one of those edge cases?
https://github.com/rust-lang/miri/blob/6cf851f6d43bff1e8ac1421cbf3c6a8d20f89560/test-cargo-miri/run-test.py#L97

I'll update the comment but does the test allow testing the zeroth argument? That's the only one that I think has issues.

Oh... hm yeah not sure how to test that one.

I'll update the comment but does the test allow testing the zeroth argument? That's the only one that I think has issues.

I guess the 2nd best thing we could do is have a #[test] inside eval.rs that checks args_to_utf16_command_string for some interesting cases.

Ok, I've hopefully addressed all the above issues.
The new code at the bottom is tests for the argv[0] edge cases.

Thanks a lot. :)
@bors r+

:pushpin: Commit cfd1316e60c901bd61f5ccc1006e32d75f3f7ab2 has been approved by RalfJung

:hourglass: Testing commit cfd1316e60c901bd61f5ccc1006e32d75f3f7ab2 with merge 76057dc518a17cc9418401d8c6dc2440bdaad947...

:sunny: Test successful - checks-actions
Approved by: RalfJung
Pushing 76057dc518a17cc9418401d8c6dc2440bdaad947 to master...

authors: ChrisDenton RalfJung bors

repo: rust-lang/miri


text:
deprecate -Zmiri-allow-uninit-numbers and -Zmiri-allow-ptr-int-transmute

Cc https://github.com/rust-lang/miri/issues/2187 https://github.com/rust-lang/miri/issues/2188

@bors r+

:pushpin: Commit 14913e993b9415c3f12159aaa387ed3931a30e73 has been approved by oli-obk

:hourglass: Testing commit 14913e993b9415c3f12159aaa387ed3931a30e73 with merge 2bbb70f5846c409b22137719debbf532d3e9b63d...

:sunny: Test successful - checks-actions
Approved by: oli-obk
Pushing 2bbb70f5846c409b22137719debbf532d3e9b63d to master...

authors: RalfJung bors oli-obk


text:
Cargo fallback for toolchain linked toolchains seems to not work on Windows

Reproduction should look something like
# Build my own rustc
../x.py build --stage 1

# Link rustup to it
rustup toolchain link dev build/x86_64-pc-windows-gnu/stage1
rustup default dev

# Check rustc and cargo, rustc works, but cargo doesn't
rustc --version
rustc 1.20.0-dev (f75d16a48 2017-07-07)
cargo --version
error: toolchain 'dev' does not have the binary `cargo.exe`

# Switch back to nightly toolchain, cargo is available again
rustup default nightly-x86_64-pc-windows-gnu
cargo 0.21.0-nightly (eb6cf012a 2017-07-02)

I believe I've seen this working previously, but maybe it was on Linux, so I'm not sure.

Triage: this is still an issue.

The problem disappeared after uninstalling rustup and then installing the fresh version again from scratch.
So apparently installation of older rustup versions could become broken in some way leading to cargo fallback being unavailable.

Hmm, the difference with reinstalled rustup is that the .rustup\fallback\cargo.exe appeared, it wasn't there before.


text:
Rustup breaks this package

Switching from brew to rustup causes this package to break
by default this package checks the typical paths /bin:/usr/bin etc but rustup puts rust in ~/.cargo/bin
I've tryed adding that folder for the path: but it doesn't seem to be working for me.
Would love to see if anyone can get this working
Rust build paths:
    "osx":
    {
        "path": "/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin"
    },

When i try changing the path in https://github.com/rust-lang/sublime-rust/blob/master/Rust.sublime-build and reload the plugin, the path is still the same.
As you can see in the images, even though i add a new path to the end, it does not reflect when running the plugin. I've tried adding a lot of different paths.

Is this a bug within Sublime 3 itself? @FichteFoll @wbond
Build: 3125
Note:
This issue has also been mentioned in https://github.com/rust-lang/sublime-rust/issues/22

I don't believe path is a known variable for build systems.
With any luck, the next dev build of ST3 will actually have code to pull in your shell environment on OS X, which should resolve this issue.

Thanks for the quick response @wbond !
So I'm assuming path will just be the user's system path when running build? which means we can get rid of the path field here?

@Jayflux see the env key described here: http://docs.sublimetext.info/en/latest/reference/build_systems/exec.html
Basically,
{
    ....
    "env": {
        "path": "$path:~/.cargo/bin"
    }
}

Apparently the path in the debug information is incorrect:
https://github.com/SublimeTextIssues/Core/issues/1039

Sorry, I was looking at the C++ part of the build system implementation… it does appear that through the kwargs in the exec build system that path should work. It does appear, however that it is not reflected in the build system output.
I'll try to get these edge cases cleaned up in one of the next builds.

authors: FichteFoll Jayflux wbond

repo: rust-lang/sublime-rust


text:
Couldn't generate qt_3d_extras on windows

rust 1.21.0 x64 msvc
MS VS 2017
Qt 5.9.2
clang 5.0.0
On step with generation qt_3d_extras moc failed:
log.zip
Generating crate: qt_3d_extras
Debug log will be saved to D:\devel\qt-cache\qt_3d_extras\log
Loading dependencies
Running C++ parser
clang version 5.0.0 (tags/RELEASE_500/final)
Initializing clang...
Warning: CLANG_SYSTEM_INCLUDE_PATH environment variable is not set.
This may result in parse errors related to system header includes.
clang arguments: ["-Xclang", "-detailed-preprocessing-record", "-fcxx-exceptions
", "-std=c++14", "-I", "D:/Qt/5.9.2/msvc2017_64/include", "-I", "D:/Qt/5.9.2/msv
c2017_64/include\\Qt3DExtras", "-I", "D:/Qt/5.9.2/msvc2017_64/include\\QtCore",
"-I", "D:/Qt/5.9.2/msvc2017_64/include\\QtGui", "-I", "D:/Qt/5.9.2/msvc2017_64/i
nclude\\Qt3DCore", "-I", "D:/Qt/5.9.2/msvc2017_64/include\\Qt3DRender", "-I", "D
:/Qt/5.9.2/msvc2017_64/include\\Qt3DInput", "-I", "D:/Qt/5.9.2/msvc2017_64/inclu
de\\Qt3DLogic"]
Parsing types
Parsing methods
Checking data integrity
Searching for template instantiations
Detecting signals and slots
Running custom filters for C++ parser data
Detecting fancy Qt header names
Adding Qt documentation from D:/Qt/Docs/Qt-5.9.2\qt3d.qch
Saving C++ parser data
C++ parser data is saved to file: D:\devel\qt-cache\qt_3d_extras\parser_cpp_data
.bin
Post-processing parse result
Detecting type allocation places
Saving processed C++ data
Processed C++ data is saved to file: D:\devel\qt-cache\qt_3d_extras\processed_cp
p_data.bin
Generating C++ wrapper library (qt_3d_extras_c)
Instantiating templates
Adding field accessors
Adding cast functions
Generating C++ FFI methods for header: QConeGeometry
Generating C++ FFI methods for header: QConeMesh
Generating C++ FFI methods for header: QCuboidGeometry
Generating C++ FFI methods for header: QCuboidMesh
Generating C++ FFI methods for header: QCylinderGeometry
Generating C++ FFI methods for header: QCylinderMesh
Generating C++ FFI methods for header: QDiffuseMapMaterial
Generating C++ FFI methods for header: QDiffuseSpecularMapMaterial
Generating C++ FFI methods for header: QExtrudedTextGeometry
Generating C++ FFI methods for header: QExtrudedTextMesh
Generating C++ FFI methods for header: QFirstPersonCameraController
Generating C++ FFI methods for header: QForwardRenderer
Generating C++ FFI methods for header: QGoochMaterial
Generating C++ FFI methods for header: QMetalRoughMaterial
Generating C++ FFI methods for header: QMorphPhongMaterial
Generating C++ FFI methods for header: QNormalDiffuseMapAlphaMaterial
Generating C++ FFI methods for header: QNormalDiffuseMapMaterial
Generating C++ FFI methods for header: QNormalDiffuseSpecularMapMaterial
Generating C++ FFI methods for header: QOrbitCameraController
Generating C++ FFI methods for header: QPerVertexColorMaterial
Generating C++ FFI methods for header: QPhongAlphaMaterial
Generating C++ FFI methods for header: QPhongMaterial
Generating C++ FFI methods for header: QPlaneGeometry
Generating C++ FFI methods for header: QPlaneMesh
Generating C++ FFI methods for header: QSkyboxEntity
Generating C++ FFI methods for header: QSphereGeometry
Generating C++ FFI methods for header: QSphereMesh
Generating C++ FFI methods for header: QText2DEntity
Generating C++ FFI methods for header: QTextureMaterial
Generating C++ FFI methods for header: QTexturedMetalRoughMaterial
Generating C++ FFI methods for header: QTorusGeometry
Generating C++ FFI methods for header: QTorusMesh
Generating C++ FFI methods for header: Qt3DWindow
Generating C++ FFI methods for header: slots
Generating C++ wrapper code
Executing command: "moc" "-i" "D:\\devel\\qt-rust-test01\\qt_3d_extras\\c_lib\\i
nclude\\qt_3d_extras_c_slots.h"
Stdout:
Stderr:
Error:
   0: command failed with exit code: 3221225794: "moc" "-i" "D:\\devel\\qt-rust-
test01\\qt_3d_extras\\c_lib\\include\\qt_3d_extras_c_slots.h"
   1: C++ code generator failed
error: process didn't exit successfully: `target\release\qt_generator.exe -c D:\
devel\qt-cache -C 3 -l all --debug-logging save -o D:\devel\qt-rust-test01` (exi
t code: 1)

Does moc run when you execute it manually from the same console you run the generator from? From looking at the log, it seems that moc is not able to properly start at all.

I'm closing this because there is not enough information to find the cause of the issue.


text:
Testing of asynchronous code

Right now, rust's standard way of writing tests and the standard way of executing futures (tokio) are at odds with eachother. The test framework expects a panic on test failure - tokio catches panics and treats them as normal errors. The test framework tries to run multiple tests in parallel where it can - tokio immediately spawns one thread per CPU core when you run it. This makes testing asynchronous code pretty hard, and that's something we should fix.
I think to fix this, we need a simpler futures executor that doesn't include quite so many batteries. Instead, a run function that just runs like a regular function - without trying to do anything with threads or panic catching. Ideally, in the name of keeping test and prod environments similar, I would suggest we at least consider making tokio that simpler executor*. Also possible would be taking something like toykio further, or potentially even going the full way to supporting #[test] async fn ... in future.
*and separating all of the threading magic done by tokio out into a wrapper around a simpler core executor. This would be a big move, and I may be missing a whole bunch of reasons why its a bad idea, but on the bright side the extra flexibility could help people who

want really high performance, and need custom control over how things work across threads in their program
want a really light footprint for their code (nobody likes the app that spawns 8 threads just to transfer a file to another computer)
don't expect high enough load for their program that the effort to make their code threadsafe is justified for the performance gains it would bring

The Tokio current_thread::Runtime spawns no threads.

futures itself already provides a light weight executor that can be used for tests, you wouldn’t be able to use tokio types with it as they additionally require a reactor for wake notifications, but you can use in-memory pseudo-IO types with it. They’re a bit limited at the moment for test purposes as they always return Ready, I would expect at some point there will be a library for test purposes that provide in-memory types that act more like real IO types by actually returning NotReady occasionally.

The test framework expects a panic on test failure - tokio catches panics and treats them as normal errors.

This is not an issue anymore, as long as the top-level executor call returns these panics-as-errors to you, your test function can now return the error to signal a failure.

Not related to Tokio, but creating a Future's Context is a bit hard in the context of testing. For both the LocalWaker and Executor you need something of a runtime. Maybe a future-test crate would be useful, it would provide a Context that easy is to use in (unit) tests. For example calls to wake would just add a notification of some kind to a collection. The Executor would do something along the same lines.

In case there are subscribers to this that haven't seen it, quite a while back a futures-test-preview crate was added that contains common utilities for testing futures, e.g. constructing different kinds of Context or wrapping synchronous/in-memory async IO implementations in ones that attempt to emulate being async, see the blog post and the documentation.

authors: Nemo157 Thomasdezeeuw ashfordneil carllerche

repo: rustasync/team


text:
Js number tests

Switch over to testing JsNumber because of #78

This should cover the JsNumber section of #76.  Let me know if there is any other JsNumber specific tests we should have for 76.

Awesome -- just one minor issue, the expected/actual ordering is backwards in the chai tests.

authors: dherman mfpiccolo

repo: rustbridge/neon


text:
Fix K8s API server connectivity for IPv6

The upstream library kube-rs uses an old way of connection to the K8s API, which in their implementation breaks on IPv6 clusters due to wrong URL formatting. This forces the lib to use the proper service, which works on IPv6 clusters as well. The hint towards this solution is from kube-rs/kube-rs#587 - the fix they implemented there is specific to using the rustls feature, which is not in use in this project. But the workaround works regardless.
I also made the env variables configure as a Helm value, in case somebody else needs to change something there in the future. Currently we've applied this fix with kustomize, but having it directly in the chart would let us get rid of that complexity. Plus, others can benefit as well. :)

@mKeRix Isn't this fixed in https://github.com/kube-rs/kube-rs/pull/597, if so the proper fix would be to upgrade the latest kube-rs version.

Isn't this fixed in kube-rs/kube-rs#597, if so the proper fix would be to upgrade the latest kube-rs version.

No, it is not fixed in upstream kube-rs , as kube-rs does not properly format IPv6 addresses in URL, it will create something like https://::1:443 (which is invalid) instead of https://[::1]:443.
@mKeRix If you can address my comment above, I will happily merge this PR.

Indeed. Sorry, I should've made that clearer in my initial post. I have updated the pull request accordingly now. :)

@mKeRix this PR is now part of today's v0.1.6 release. Thanks for the PR.

authors: alex-berger mKeRix

repo: rustrial/aws-eks-iam-auth-controller

license: Unlicense


text:
Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: rustsec/audit-check

If you use the action rustsec/audit-check in the workflow github will show you the warning
Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20
It will be great if you can updated to node 20

Is this repository still maintained? Last commit was about a year ago. I hope it is, I really like it.

authors: Finomnis istellino-chub

repo: rustsec/audit-check


text:
mut required for uploading to uniforms

Functions like uniform4fv_with_f32_array() expect a mutable reference to a slice as input
This is really odd imho because you would never expect that function to change the data you pass in.
Also makes it a bit tougher to work with due to borrowing rules...
From looking at the WebIDL it seems this is a Float32List - but I see no indication of why that would be mutable.
Help understanding is greatly appreciated!

See https://github.com/rustwasm/wasm-bindgen/issues/1005

Ohhh... thanks, I'll go ahead and close this since it's already addressed there and the linked issues.

authors: dakom jsheard

repo: rustwasm/wasm-bindgen


text:
ShapeNet dataset classes

dataset.num_classes is 50 when we only use 2 categories for ShapeNet
Hi, I am new to Pytorch geometric and was trying to recreate the point cloud classification example but with ShapeNet instead of GeometricShapes. Anyways, when downloading the ShapeNet dataset I have some issues understanding the dataset parameters.
Example code:
from torch_geometric.datasets import ShapeNet

dataset = ShapeNet(root='data/ShapeNet',categories = ['Airplane','Car'])
print(dataset)
print(dataset[0])
print('first 10 class labels for first graph: ' + str(dataset[0].y[0:10]))
print('num classes: ' + str(dataset.num_classes))

ShapeNet uses one label per node, intuitively I thought these labels would all be the same for each graph, either Airplane (0) or Car (1). Furthermore, I was expecting dataset.num_classes would be '2' as we only have Airplanes and Cars.
The outputs are however
ShapeNet(3089, categories=['Airplane', 'Car'])
Data(category=[1], pos=[2518, 3], x=[2518, 3], y=[2518])
first 10 class labels for first graph: tensor([0, 0, 3, 3, 0, 0, 1, 1, 3, 3])
num classes: 50

I have probably misunderstood something, but how come n_Classes is 50 and dataset[0].y corresponds to numerous classes?
Thankful for any insight :)

The ShapeNet dataset is a segmentation dataset, so each point has a label instead of each graph. For example, Airplane has labels such as "wing".

Oh, I see, that makes sense,
Thank you for the quick answer!


text:
Creating my own dataset

❓ Questions & Help

First of all, thanks for your excellent works. I just started my deep learning study with torch_geometric and it's really helpful!
Heres my questions when I am trying to creating my own dataset. First, how can I add train_maks, val_mask and test_mask attribute to Data?  Is Data.__setitem__() suitbal for this? Second, in Cora dataset, I get Data(x=[2708, 1433], edge_index=[2, 10556], y=[2708], train_mask=[2708], val_mask=[2708], test_mask=[2708]) and data.train_mask.sum()=140, dose it mean *_mask is multi-hot key used to select data for various use(e.g. train)?
Any help will be appreciated!

Hi,
you can add masks (or any other attributes) by simply assigning it to your data object, e.g., data.train_mask = torch.tensor([...], dtype=torch.uint8). The *_masks we use in the Cora datasets are masks in the size of the number of nodes and contain a 1 if the node belongs to the given set (and 0 otherwise).

It works as expectedly, still got something to figure out.
Sorry to bother you with my rookie questions.
Anyway thank you xD


text:
Cannot install with PyTorch Nightly

📚 Installation
Environment

OS: Ubuntu 16.04
Python version: 3.7.9
PyTorch version: 1.9.0.dev20210220
CUDA/cuDNN version: 10.2.89
GCC version: 5.4.0
How did you try to install PyTorch Geometric and its extensions (wheel, source):conda install pytorch torchvision torchaudio -c pytorch-nightly
pip install torch-scatter
pip install torch-sparse
pip install torch-cluster
pip install torch-spline-conv
pip install torch-geometric

Any other relevant information:
The pip installation is successful, but when I try import torch_sparse, I got the following error:Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/anaconda2/envs/svg/lib/python3.7/site-packages/torch_sparse/__init__.py", line 34, in <module>
  from .storage import SparseStorage  # noqa
File "/home/anaconda2/envs/svg/lib/python3.7/site-packages/torch_sparse/storage.py", line 21, in <module>
  class SparseStorage(object):
File "/home/xtli/anaconda2/envs/svg/lib/python3.7/site-packages/torch/jit/_script.py", line 979, in script
  _compile_and_register_class(obj, _rcb, qualified_name)
File "/home/anaconda2/envs/svg/lib/python3.7/site-packages/torch/jit/_script.py", line 72, in _compile_and_register_class
  torch._C._jit_script_class_compile(qualified_name, ast, defaults, rcb)
RuntimeError:
attribute assignment is not defined on __torch__.torch_sparse.storage.SparseStorage:
  File "/home/anaconda2/envs/svg/lib/python3.7/site-packages/torch_sparse/storage.py", line 145
  def empty(self):
      self = SparseStorage.__new__(SparseStorage)
      self._row = None
      ~~~~~~~~~~~~~~~~ <--- HERE
      self._rowptr = None
      self._value = None

Checklist

[x] I followed the installation guide.
[x] I cannot find my error message in the FAQ.
[x] I set up CUDA correctly and can compile CUDA code via nvcc.
[ ] I do have multiple CUDA versions on my machine.

This looks like some TorchScript internals changed in PyTorch master. We will fix that once a new official PyTorch release lands. We cannot fix that for now to guarantee correct behavior with the current PyTorch release.

Got it. Thanks for the quick response and looking forward to the new release.


text:
Using NeighborSampler (with InMemoryDatasets)

❓ Questions & Help

Hi @rusty1s , I am trying to use the Neighbor Sampler to collect information about the patches around nodes on molecular surfaces. I have tried to implement a minimal example based on the reddit example, but I am running into some curious errors. After consulting the original feature request re neighborhood sampling and the documentation on the Reddit example  I have not been able to figure out why.
I load my training set as an InMemoryDataset, as in the reddit example. They have x, y, and edge_index, as well as other attributes. I load a single structure, and then initialize a NeighborSampler with it. I need to use a larger patch than in the examples, so my n_hops is 9.
When I try to create a dataflow using the Neighbor sampler, I get AttributeError: 'Data' object has no attribute 'dtype'. This seems strange to me, but if I manually give the structure a dtype attribute I get AttributeError: 'Data' object has no attribute 'split'.
A similar error occurs if I use a DataLoader to load my structures.
Here is the (very) minimal example:
data = trainset[0]
ns = NeighborSampler(data, 0.1, 9, batch_size=100, add_self_loops=True)
for dataflow in ns(data):
    print('loop')

And the traceback:

AttributeError                            Traceback (most recent call last)
 in
----> 1 for dataflow in ns(data):
      2     print('loop')
~/opt/anaconda3/envs/geo/lib/python3.7/site-packages/torch_geometric-1.3.2-py3.7.egg/torch_geometric/data/sampler.py in call(self, subset)
261             produce = self.produce_subgraph
262
--> 263         for n_id in self.get_batches(subset):
264             yield produce(n_id)
~/opt/anaconda3/envs/geo/lib/python3.7/site-packages/torch_geometric-1.3.2-py3.7.egg/torch_geometric/data/sampler.py in get_batches(self, subset)
146             subset = torch.randperm(self.data.num_nodes)
147         else:
--> 148             if subset.dtype == torch.bool or subset.dtype == torch.uint8:
149                 subset = subset.nonzero().view(-1)
150             if self.shuffle:
AttributeError: 'Data' object has no attribute 'dtype'

What am I doing wrong here? Thank you!

This line is wrong:
for dataflow in ns(data):

You either pass in nothing, our the indices of the nodes you want to iterate over.

Thank you!


text:
Password is bold for a moment and after bolding is removed, it still looks semi bold

https://user-images.githubusercontent.com/1311912/191571380-ede66076-0db6-440b-85c2-16c9a5f040a9.mov

It seems that this problem only affects Mac/iPhone users.
It looks like Safari renders the 'font-weight: 600' style (semi-bold) with some delay.
At the first stage, it applies the default bold style (font-weight=700), then after a delay, it applies the actual font-weight=600.
In both cases, if standard or bold 'font-weight' is used, the problem does not appear.
@laurijamsa should we replace 'semi-bold' style to 'bold' for the 'Password' title?

Actually, we can just remove the whole "Password" title I think as we already have a similar Password placeholder on the input field.

That's not true, the 'Password' placeholder was removed and the placeholder now is used to show '********' when a saved password is used:

Also, the same 'Password' field is used for manual connection:

QA passed

authors: TheSomeMan laurijamsa markoaamunkajo


text:
propose, nodejs compatibility

Hi @rvagg
Not sure you really want this, please let me know, i ll make a fork then.
It replaces your tsml module by underscore.template module.
By running it againt its repository, i found sometimes commit.summary was not set.
I fixed that dirtily, i believe this way in a way it won t break any es6 things i m not aware.
jshint did not complain anything here.

const should be available everywhere fwiw
a couple of style things I'd like fixed up before I properly review, will comment inline on those

hope that works, i also fine tuned a little bit

Hi,
i made more significant changes in a separate branch, here
https://github.com/maboiteaspam/changelog-maker/tree/better-project-id-detection
See a relevant commit message here for an overview of the changes
https://github.com/maboiteaspam/changelog-maker/commit/196426be10541b829112fcb388fd624edff53491
Do i merge that into this ?

I actually quite like the changes you made to detect the default package, I've been wondering how best to achieve that, I can live with debug too. Happy to merge but I'd appreciate some more work to match style, I know it's quirky but it's my quirky.

i.e. happy to have those additional changes you've made, once we get the style nits right then I'll add you as a collaborator here

Hi,
it s fine to be demanding about the code style.
It s just i see now the jshint config does not seem to be inline with the comments you made.
Are you standard (feross/standard) user ? Or semi-standard ?
Please let me know i'll put that into the npm run lint script command.

I checked this source code against standard / semi-standard. None of them really fit the style in this repository. It s fine to me, i like their initiative, not their code style.
Then i checked my words and the jshint i have here would not catch semi colons. Did not try to tune its config, instead i gave a try to eslint, because i prefer its output output, with the help of https://github.com/valorkin/eslint-rules-mapper it was real quick.
I then adjusted the existing rules to pass the source code. It s bit unusual to proceed that way.
you can check the whole config,
here https://github.com/maboiteaspam/changelog-maker/blob/eslint/.eslintrc
I have put my specific adjustments to pass the lint into a specific commit here
https://github.com/maboiteaspam/changelog-maker/commit/83ae289ce090ae4e0a8d1e09df8f51ae6f627000
Let me know, at the end, my belief is that manual code style checking does not worth a cent. I d really prefer have one linter config to comply to.

so many errors running eslint with that .eslintrc, do I need to be using a pre-release version or something to make it happy?

only a few minor style nits and we can land this

Hope it s fine.

sorry to be a pain, but could you squash this all into a single commit please? there's a heap of noise here. If it's too difficult to squash with the rebased activity in the middle then perhaps submit a new PR with a single commit?

Agreed, i found also all those commits was not satisfying. Need to check how to do that.

opened #16, closing #12.

authors: maboiteaspam rvagg

repo: rvagg/changelog-maker


text:
[BUG] Possible bug with create_model(..., features_only=True, ...)

Describe the bug
Possible bug with create_model(..., features_only=True, ...). The output when passing an tensor (B,3,512,512) and the output passing the images as (1,3,512,512) and then merging do not coincide.
To Reproduce
import timm
import torch

t = torch.randn(2,3,512,512)
feature_extractor = timm.create_model('efficientnet_b0', pretrained=True, features_only=True, out_indices=[2])
feature_extractor.eval()
out = feature_extractor(t)[0]

t0 = t[0, ...].unsqueeze(0)
out0 = feature_extractor(t0)[0]

t1 = t[1, ...].unsqueeze(0)
out1 = feature_extractor(t1)[0]

print('out0 equals out1 (expected False):', (out0 == out1).all().item())
print('out0 equals out[0] (expected True):', (out0 == out[0:1]).all().item())
print('out1 equals out[1] (expected True):', (out1 == out[1:2]).all().item())
print('out[0] equals out[1] (expected False):', (out[0:1] == out[1:2]).all().item())

Result
out0 equals out1 (expected False): False
out0 equals out[0] (expected True): False
out1 equals out[1] (expected True): False
out[0] equals out[1] (expected False): False

Expected behavior
I would expect that the output of passing a batch is the same that passing the images 1 per time and then merge the results.
Desktop:

OS: Ubuntu 20.04
timm  0.6.7
torch  1.12.1+cu116

@Keredu why would you expect that in a model with batch norm, when you have the model in train() mode?

@Keredu why would you expect that in a model with batch norm, when you have the model in train() mode?

That's true, I forgot to add feature_extractor.eval() to the example so I just edited it. The behaviour is still the same. I'm just trying to obtain the features of multiples (B) images at the same time instead of pass only 1 image in each forward pass.
The use case is: I extract the features of the images and then, they are consumed by other NN (a LSTM indeed) so I'd like to speed up the feature extraction process by doing it on multiples images at the same time.

Also,
t0 = t[0, ...].unsqueeze(0)
out0 = feature_extractor(t0)[0]

t1 = t[1, ...].unsqueeze(0)
out1 = feature_extractor(t1)[0]

> > @Keredu why would you expect that in a model with batch norm, when you have the model in train() mode?
>
> That's true, I forgot to add `feature_extractor.eval()` to the example so I just edited it. The behaviour is still the same. I'm just trying to obtain the features of multiples (B) images at the same time instead of pass only 1 image in each forward pass.
>
> The use case is: I extract the features of the images and then, they are consumed by other NN (a LSTM indeed) so I'd like to speed up the feature extraction process by doing it on multiples images at the same time.

they look fine to me, it won't be exact because the float ops will vary between batch size 1 and 2, so it'll be close within some float eps

(out[0] - out0).max()
tensor(6.8665e-05, grad_fn=<MaxBackward1>)
(out[1] - out1).max()
tensor(7.2479e-05, grad_fn=<MaxBackward1>)

You are right. I'm closing this issue and check my code again. Thanks.

authors: Keredu rwightman

repo: rwightman/pytorch-image-models


text:
Remove checking smoothing parameter

Currently, smoothing parameter for label smoothing is not used, so there's no need if-condition for now.
OR
From pytorch 1.10.x, starts to support label_smoothing parameter. So we can change to
As-is
self.loss = nn.CrossEntropyLoss().to(self.device)

To-be
self.loss = nn.CrossEntropyLoss(label_smoothing=kwargs.pop('smoothing', 0)).to(self.device)

API : nn.CrossEntropyLoss

Indeed, that is a silly bit of code, I guess I was going to add the other custom loss w/ smoothing but likely won't impact benchmark so just remove for now...

authors: kozistr rwightman