profile
viewpoint
Lokathor Lokathor @rust-console, @rust-tutorials United States https://lokathor.github.io/ You should use the amazing new trio-license: Zlib OR Apache-2.0 OR MIT

Lokathor/bytemuck 61

A crate for mucking around with piles of bytes

Lokathor/easycurses-rs 28

A rust crate to smooth over the pain points of working with curses. (Windows+Unix)

Lokathor/fermium 27

An easy to build and use set of SDL2 bindings.

Lokathor/beryllium 25

An opinionated set of high level wrappers for the `fermium` SDL2 bindings.

Lokathor/dwarf-term-rs 15

A window that lets you do Dwarf Fortress style drawing

Lokathor/hektor 4

A library for hekkin vectors.

Lokathor/imagine 4

can you even imagine imagining.

Lokathor/dice-bot-rs 3

A Discord bot for rolling dice

Lokathor/fenestroj 3

Easier wrappers for Win32 API stuff, safe when possible

Lokathor/chlorine 2

Just the C types for `no_std`, but builds faster.

issue commentrust-gamedev/wg

raw-window-handle maintenance

Well of course @Osspial has to be on board for any changes.

Getting new platforms is mostly a matter of PRs from people who know how to work that platform. I'm sure once things are waiting on review Osspial will have a lot more incentive to actually review it. It's harder to get up the energy to do something new yourself, particularly during 2020.

msiglreith

comment created time in 8 hours

issue commentrust-gamedev/wg

raw-window-handle maintenance

Could you expand more on what new platforms you'd like to see?

And what API changes?

msiglreith

comment created time in 9 hours

issue commentrust-lang/rfcs

-0.0 should format with a minus sign by default

No, in fact while Debug is oriented at "a rust programmer", Display is oriented at "Someone who might not be a rust programmer", so it's rather a lot more likely that FromStr can't parse exactly what Display shows.

  • Debug is often something that can be a Rust literal.
  • Display is often something that can go into a log file somewhere.
rprichard

comment created time in 20 hours

fork Lokathor/rust

Empowering everyone to build reliable and efficient software.

https://www.rust-lang.org

fork in a day

issue commentrust-lang/packed_simd

"packed_simd v0.3.3" not compiling on Windows 10

This is a known break, and we cannot fix it.

https://github.com/rust-lang/packed_simd#the-cratesio-version-can-no-longer-be-updated

Please update to the 0.3.4 version of packed_simd_2 as described in the link.

Rabax55

comment created time in 2 days

pull request commentLokathor/wide

Lower i32x8/u32x8 SSE requirements from SSSE3 down to SSE2.

released wide-0.6.2

RazrFalcon

comment created time in 2 days

created tagLokathor/wide

tagv0.6.2

A crate to help you go wide.

created time in 2 days

push eventLokathor/wide

Lokathor

commit sha 19c286c0908814be0342f331a07dca7ee7e6c4ce

(cargo-release) version 0.6.2

view details

Lokathor

commit sha 6a70a6f307701e394a94ccb080c9c47f6e59d783

(cargo-release) start next development iteration 0.6.3-alpha.0

view details

push time in 2 days

pull request commentLokathor/wide

Lower i32x8/u32x8 SSE requirements from SSSE3 down to SSE2.

oh crap. hectic time lately. I'll try to do this soon

RazrFalcon

comment created time in 3 days

issue commentrust-lang/rust

Tracking issue for RFC 2700: numeric constants as associated consts

I was not being sarcastic at all.

If floating types don't get the same design fixes applied them, then that's dumb for all the reasons that std::u8::MAX is dumb.

LukasKalbertodt

comment created time in 4 days

issue commentrust-lang/rust

Tracking issue for RFC 2700: numeric constants as associated consts

if I can't just write f32::NAN then what the heck is the point of any of this.

LukasKalbertodt

comment created time in 4 days

issue commentrust-lang/mdBook

Please allow table of contents entries that don't have markdown pages.

Very neat, I didn't know a person could do that.

However, it seems that style makes the numbering not include the part entries.

Lokathor

comment created time in 6 days

push eventLokathor/bytemuck

Lokathor

commit sha 8b0710cd960318cb83fafd830a422e942f720cae

Update rust.yml

view details

push time in 7 days

push eventLokathor/bytemuck

Lokathor

commit sha 094f76ad735a7ff8fd338d7644a6e9919ba9b18e

Closes https://github.com/Lokathor/bytemuck/issues/39 On older compilers, you need to say `extern crate proc_macro;` even in 2018 edition. Since it doesn't hurt in newer compilers, we'll just do that.

view details

push time in 7 days

issue closedLokathor/bytemuck

Compile error in bytemuck_derive

graphics35334:wgpu-rs dmalyshau$ cargo test
    Updating crates.io index
    Updating git repository `https://github.com/gfx-rs/wgpu`
  Downloaded proc-macro2 v1.0.21
  Downloaded bytemuck v1.4.1
  Downloaded syn v1.0.40
  Downloaded bytemuck_derive v1.0.0
   Compiling proc-macro2 v1.0.21
   Compiling syn v1.0.40
   Compiling wgpu-core v0.6.0 (/Users/dmalyshau/Code/wgpu/wgpu-core)
   Compiling wgpu-types v0.6.0 (/Users/dmalyshau/Code/wgpu/wgpu-types)
   Compiling quote v1.0.3
   Compiling thiserror-impl v1.0.20
   Compiling bytemuck_derive v1.0.0
error[E0433]: failed to resolve: use of undeclared type or module `proc_macro`
  --> /Users/dmalyshau/.cargo/registry/src/github.com-1ecc6299db9ec823/bytemuck_derive-1.0.0/src/lib.rs:36:26
   |
36 | pub fn derive_pod(input: proc_macro::TokenStream) -> proc_macro::TokenStream {
   |                          ^^^^^^^^^^ use of undeclared type or module `proc_macro`

Looks like it can't find the proc_macro thing on my machine. I wonder why?

closed time in 7 days

kvark

issue closedLokathor/bytemuck

Stack overflow when using `zeroed_box()`

With a debug build, I'm consistently getting a stack overflow when using zeroed_box(). Minimal example:

const PAGE_SIZE: usize = 4096;
type BlockChunk = [u8; PAGE_SIZE];

const MIB_16: usize = 16 * 1024 * 1024;
const SUPER_SIZE: usize = MIB_16 / std::mem::size_of::<BlockChunk>();
type SuperPage = [BlockChunk; SUPER_SIZE];

#[test]
fn test_alloc() {
    // ABORT: thread '[...]::test_alloc' has overflowed its stack
    let _: Box<SuperPage> = bytemuck::zeroed_box();
}

EDIT: This happens on windows, have not checked anything else yet.

Reproducible on playpen: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=547372389428bf450c9bf885cf7ea6b8

closed time in 7 days

Kimundi

issue commentLokathor/bytemuck

Stack overflow when using `zeroed_box()`

Fixed by https://github.com/Lokathor/bytemuck/pull/43

Kimundi

comment created time in 7 days

push eventLokathor/bytemuck

Lokathor

commit sha 00cbef6b831b39dfe257bf39fe33294b3f4769f0

Create changelog.md

view details

push time in 7 days

push eventLokathor/bytemuck

Lokathor

commit sha 93d8e53509d4973de8a624e27ebb89cb60405d03

Update changelog.md

view details

push time in 7 days

push eventLokathor/bytemuck

Lokathor

commit sha 45bafba41c801dac190048ca423a2ec493835dc2

Update changelog.md

view details

push time in 7 days

push eventLokathor/bytemuck

Lokathor

commit sha 65b64fd8aab0f06cf0dd53ddda5c23bf4716a4c7

Update rust.yml

view details

push time in 7 days

push eventLokathor/bytemuck

Yanchi Toth

commit sha b264926ac0657b2aa04053c541a462aa5d4a1d03

Emit padding-asserting code that doesn't trigger clippy::identity_op (#45)

view details

push time in 7 days

PR merged Lokathor/bytemuck

Emit padding-asserting code that doesn't trigger clippy::identity_op

Not sure this was worth it, but here goes.. 😹

Fixes #44

+10 -3

1 comment

1 changed file

yanchith

pr closed time in 7 days

issue closedLokathor/bytemuck

derive(Pod) generates code that triggers warn-by-default clippy::identity_op

Hi! Thanks for bytemuck :heart: It is a pleasure to work with (compared to my previous unsafe versions of bytes_of and from_bytes ).

When switching to it, I managed to trigger https://rust-lang.github.io/rust-clippy/master/index.html#identity_op in the code generated by the derives.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&code=%23%5Brepr(C)%5D%0A%23%5Bderive(Debug%2C%20Clone%2C%20Copy%2C%20PartialEq%2C%20Default%2C%20bytemuck%3A%3AZeroable%2C%20bytemuck%3A%3APod)%5D%0Apub%20struct%20Vec2%20%7B%0A%20%20%20%20x%3A%20f32%2C%0A%20%20%20%20y%3A%20f32%2C%0A%7D%0A%0Afn%20main()%20%7B%7D

(run clippy on tthe play pen)

The culprit seems to be this generated code, emitted as a static check before the unsafe impl is emitted:

const _: fn() =
    ||
        {
            struct TypeWithoutPadding([u8; 0 + ::core::mem::size_of::<f32>() +
                                               ::core::mem::size_of::<f32>()]);
            let _ = ::core::mem::transmute::<Vec2, TypeWithoutPadding>;
        };

Seems to be trivially fixable by checking the number of fields beforehand in https://github.com/Lokathor/bytemuck/blob/main/derive/src/traits.rs#L209

I can submit a fix, if you desired.

closed time in 7 days

yanchith

push eventLokathor/bytemuck

Marvin Löbel

commit sha 92ce415317d9085611c4b2d12d46a322e25b05b3

Prevent `try_zeroed_box<T>()` from reserving `size_of<T>()` space on the stack. (#43) * Add test * Change try_zeroed_box implementation to not allocate space for T on the stack * Add second test

view details

push time in 7 days

issue commentrust-lang/rust

Consider limiting #[rustc_args_required_const(...)] to intrinsics.

Yeah, once const generics can handle this they're basically the more "rusty" way to do all this.

However, this is actually farther along than min_const_generics last I checked. You'd need to be able to say something like "fail the build if the generic value is more than 3 bits".

eddyb

comment created time in 7 days

issue commentrust-lang/rust

Consider limiting #[rustc_args_required_const(...)] to intrinsics.

Yes that's also my understanding. These intrinsics aren't truly accepting const args, they're actually a high level approximation of immediate values being encoded into an assembly instruction.

It's not breaking to Rust to suddenly allow a varying argument in a future release, but then it would absolutely fail to do the one job it's supposed to do.

Rust is unfortunately bad at expressing a few low level concepts, this is one of them.

eddyb

comment created time in 7 days

push eventrust-lang/packed_simd

Mingye Wang

commit sha d88f7af2c2c4f3e66a4765bcb8789406cb5718a7

README: Fix crate and docs links This follows the rename to `packed_simd_2`. The URL shown at the repo info should be changed to https://rust-lang.github.io/packed_simd/packed_simd_2/ too, but I don't have the permission to do it.

view details

Lokathor

commit sha c6ea275e0b9e7ac11ecfbed737833e8edcc6a3f4

Merge pull request #307 from Artoria2e5/patch-1 README: Fix crate and docs links

view details

push time in 7 days

PR merged rust-lang/packed_simd

README: Fix crate and docs links

This follows the rename to packed_simd_2. The URL shown at the repo info should be changed to https://rust-lang.github.io/packed_simd/packed_simd_2/ too, but I don't have the permission to do it.

+5 -5

1 comment

1 changed file

Artoria2e5

pr closed time in 7 days

PullRequestReviewEvent

pull request commentrust-lang/packed_simd

README: Fix crate and docs links

Ah, yes of course. @workingjubilee could you issue a patch with this new readme at some point?

Artoria2e5

comment created time in 7 days

issue commentLokathor/wide

feature request: u8x4

f32x16 is only available via avx-512 CPUs. Otherwise you'll just get emulated results.

Generally for color manipulations, you need to pick X many pixels you want to handle at once (usually 4 or 8), then "transpose" the channels so that instead of 4 colors or 8 colors, you have one simd value per channel (RGB or RGBA), and it holds that channel for all the pixels (eg: all the red chanenls). Then you can perform the color ops. At the end, you re-transpose the values back into their standard byte form.

There's actually a brief example of this in the tests/ folder, https://github.com/Lokathor/wide/blob/main/tests/t_usefulness.rs

LoganDark

comment created time in 7 days

issue commentLokathor/wide

feature request: u8x4

This doesn't match up with any hardware supported SIMD. It's too small, only 32 bits.

You could use something like u8x16 and process four pixels at a time though.

LoganDark

comment created time in 7 days

issue commentrust-lang/unsafe-code-guidelines

Meaning of Undefined and Justification for UB

if you are lucky and guess

A lot of things can happen if you're lucky and guess.

Specifically, the outcome of UB might be what you expect. It's always possible that the UB doesn't come back to bite you when using a particular compiler, on a particular set of flags, on a particular ... and so on. But what exactly happens is always up in the air, which is why as a user of the language/compiler you need to avoid UB if you want reliable compilations.

But in that particular example with a and b, I can't imagine much good happening. You can't really reason about b (eg: eliminating a duplicate load, or holding off on a store, etc) if you're also allowed to access it via a.

chorman0773

comment created time in 10 days

issue commentrust-lang/rust

Must a `const fn` behave exactly the same at runtime as at compile-time?

I think they mean "have a trait impl that's const (and used in const contexts) and also the same impl as non-const (and used in non-const contexts).

oli-obk

comment created time in 11 days

push eventLokathor/wide

Evgeniy Reizner

commit sha cee7b6f6cd7008a01a000f93f6710120c97162d5

Lower i32x8/u32x8 SSE requirements from SSSE3 down to SSE2. (#80)

view details

push time in 11 days

PR merged Lokathor/wide

Lower i32x8/u32x8 SSE requirements from SSSE3 down to SSE2.

Closes #76

+117 -139

1 comment

3 changed files

RazrFalcon

pr closed time in 11 days

issue closedLokathor/wide

SSE2 support in i32x8/u32x8

I'm trying to switch from f32x4 to f32x8 in my project, which is fairly straight-forward thanks to wide's fallback mechanism. But I also use a lot of i32x8/u32x8, which means that on SSE2 I'm stuck with scalar, which is very slow.

Is there a reason why i32x8/u32x8 doesn't support SSE2 fallback? f32x8 also uses two m128, but requires only SSE2 and not SSSE3. I can try implementing SSE2 fallback for i32x8/u32x8 if you're interested.

closed time in 11 days

RazrFalcon
PullRequestReviewEvent

pull request commentLokathor/wide

Add SSSE3 fallback to f32x8::trunc_int

Should I merge or do you want to add more elsewhere?

RazrFalcon

comment created time in 11 days

PullRequestReviewEvent

issue commentLokathor/wide

How to create i32x8 from two m128i?

uh, you could change them to pub(crate) fields, that's simplest.

RazrFalcon

comment created time in 11 days

issue commentLokathor/wide

SSE2 support in i32x8/u32x8

No reason it just wasn't implemented that way. I'm open to a PR which does additional fallback cases of there's sse2 but no avx2

RazrFalcon

comment created time in 11 days

PullRequestReviewEvent

push eventLokathor/utf16_lit

Plecra

commit sha 18d2be056f0694c228c6734579d4d65862aa5dda

Fix no_std support (#9) * feat: Return converted data by-value ...which allows the user to pass it as owned data. * fix: add back support for no_std

view details

push time in 12 days

PR merged Lokathor/utf16_lit

Fix no_std support
+6 -4

0 comment

1 changed file

Plecra

pr closed time in 12 days

push eventLokathor/utf16_lit

Plecra

commit sha 395946f66cc2387e4d7de0b2d593626b6b7c1bd8

feat: Return converted data by-value (#8) ...which allows the user to pass it as owned data.

view details

push time in 12 days

PR merged Lokathor/utf16_lit

Return converted data by-value

This came up when I was trying to put a string in a static - UnsafeCell needs to wrap the actual data to make sure it's properly marked as mutable for the compiler.

+5 -4

0 comment

1 changed file

Plecra

pr closed time in 12 days

issue openedmgba-emu/mgba

Request: an option to have the window title be fixed regardless of game

I'm requesting an option where the window title is fully fixed regardless of the currently open game.

eg: mGBA - {version}

The reasoning is that OBS detects what game frame to capture from based on the window titles of the active processes. This means that OBS loses track of mGBA when you change games, and you have to go and change the capture source.

created time in 12 days

issue commentrust-lang/rfcs

Syntax for one-line if-else operator

or if_ or similar

XX

comment created time in 13 days

issue commentLokathor/wide

Should Debug include the type name?

well a derived debug shows the type name of a structure sure, but debug on a f32 is still just the f32. that's also why it shows as 1 sometimes. Note that you can specify format arguments and each float within will respect that, so you can specify, i think it's :0.0? or something like that and it'll force the .0 part to print for whole numbers.

RazrFalcon

comment created time in 13 days

issue commentLokathor/wide

Should Debug include the type name?

possibly? f32 debug doesn't say it is an f32 though.

RazrFalcon

comment created time in 13 days

pull request commentLokathor/wide

Add f32xN::recip and f32xN::recip_sqrt

released wide-0.6.1

RazrFalcon

comment created time in 13 days

created tagLokathor/wide

tagv0.6.1

A crate to help you go wide.

created time in 13 days

push eventLokathor/wide

Lokathor

commit sha 6d7c364ade36b584bc7a74e0b28a415667403b82

(cargo-release) version 0.6.1

view details

Lokathor

commit sha fb7c9d4ce0254fc990818b00041057dbb7400620

(cargo-release) start next development iteration 0.6.2-alpha.0

view details

push time in 13 days

push eventLokathor/wide

Evgeniy Reizner

commit sha cf21c1510d7f298148d3f350668788f40744c265

Add f32xN::recip and f32xN::recip_sqrt (#71) Closes #69

view details

push time in 13 days

PR merged Lokathor/wide

Add f32xN::recip and f32xN::recip_sqrt

Closes #69

+228 -0

18 comments

4 changed files

RazrFalcon

pr closed time in 13 days

issue closedLokathor/wide

Add f32xN recip and recip_sqrt

_mm_rcp_ps and _mm_rsqrt_ps correspondingly.

closed time in 13 days

RazrFalcon

pull request commentLokathor/wide

Add f32xN::recip and f32xN::recip_sqrt

ah! sorry, missed the first message I guess.

RazrFalcon

comment created time in 13 days

pull request commentrust-console/gba

Remove cargo-xbuild dev dependency

I think that as I add to learn-gba, stuff that's sturdy and hasn't changed in a while will br pushed out into gba, and if there's enough value things in that might be split out to gba-types and gba-hal and stuff.

but otherwise i think i was over zealous in creating some of these crates and and they're probably not necessary. It's probably simpler and easier to maintain if we keep it to fewer crates until the need arises.

mogenson

comment created time in 13 days

pull request commentrust-console/gba

Remove cargo-xbuild dev dependency

Oh, right, I have been working on other GBA stuff lately that hasn't made it back into this crate.

  • https://github.com/rust-console/min-gba
  • https://github.com/rust-tutorials/learn-gba
mogenson

comment created time in 14 days

PullRequestReviewEvent

issue commentrust-lang/stdsimd

Get Cranelifted

That's why I was so resistant to the idea that we'd say what core::arch intrinsics a given core::simd lowers to, even in the obvious cases. Because we really should be guaranteeing nothing in that area.

workingjubilee

comment created time in 14 days

issue commentrust-lang/stdsimd

Get Cranelifted

I'd like to explicitly note that this doesn't (or shouldn't) have any impact on the public api of the crate. This consideration is purely for the internals.

workingjubilee

comment created time in 14 days

issue openedrust-lang/rust

feature(isa_attribute) / #[instruciton_set()] not present in the unstable book

this has been implemented in Nightly but not added to be unstable book.

created time in 14 days

issue commentKhronosGroup/OpenGL-Registry

[gl.xml] Question about type sizes and the usage of (unsigned) int

I thought so when writing my parser/generator for gl.xml, but I'm a Rust programmer not a C programmer, so I figured it was just some C obscurity I wasn't aware of and mapped it all to u32 / i32.

AndrewLKA

comment created time in 14 days

pull request commentrust-lang/stdarch

Add more ARM SIMD intrinsics

that figure is correct, here's a list of all neon intrinsics and which ones rust currently supports https://docs.google.com/spreadsheets/d/1MqW1g8c7tlhdRWQixgdWvR4uJHNZzCYAf4V0oHjZkwA/edit?usp=drivesdk

Licenser

comment created time in 14 days

push eventLokathor/tinyvec

Lokathor

commit sha 29a97b764a9bfdfbd0baf90fa6ecec8bb8559a8a

additional doc attributes.

view details

push time in 14 days

created tagLokathor/tinyvec

tagv1.1.0-alpha.1

Just, really the littlest Vec you could need. So smol.

created time in 14 days

push eventLokathor/tinyvec

Lokathor

commit sha 0ecfb47c06454bf1e4e774104fa1c8b6c4122e23

version bump

view details

Lokathor

commit sha 74b902cd9d90ad636858632769ae1971b5b7f560

(cargo-release) version 1.1.0-alpha.1

view details

push time in 14 days

push eventLokathor/utf16_lit

Lokathor

commit sha 1c6fc4270f631bf9412d026ec3b1a3cf3531b3c0

Update Cargo.toml

view details

push time in 15 days

push eventLokathor/utf16_lit

Plecra

commit sha 6cf082ca5504f252bf05dbd616775ef166c28e99

Use const fn instead of proc_macro (#6) * reactor: use const fn instead of proc_macro * docs: explain double binding

view details

push time in 15 days

PR merged Lokathor/utf16_lit

Use const fn instead of proc_macro

1.46 makes const fn powerful enough to implement the conversion, and allows us to forgo parsing the string. It also means the crate can be used with any expr that evaluates to a &str.

Some of the std APIs that were being used aren't available yet. When they're made const fns, the implementation can use them again.

+84 -205

2 comments

3 changed files

Plecra

pr closed time in 15 days

PullRequestReviewEvent

issue commentLokathor/utf16_lit

Guarantee Utf16 output

oh but this would probably work in v2!

Plecra

comment created time in 15 days

issue commentLokathor/utf16_lit

Guarantee Utf16 output

I'm not sure if a proc-macro crate can export non-proc-macro items.

If it can, i'd accept some sort of PR for this being an optional thing.

Plecra

comment created time in 15 days

pull request commentrust-lang/rust-clippy

Enable empty_loop for no_std crates.

I think "an allocation" is over-stating it. your function's stack will be a single value bigger than normal, pretty trivial. It also inserts a single instruction into the loop instead of 0 instructions in the loop, which is again a fairly trivial difference, since the speed of the empty loop sure doesn't matter.

josephlr

comment created time in 15 days

pull request commentrust-lang/rust-clippy

Enable empty_loop for no_std crates.

@therealprof

It's not supposed/documented to be.

But it is how things are. There's an open bug about it. No amount of "it shouldn't be that way" will change the facts.

Sometimes Rust just isn't good yet and you have to wait for it to improve. If you want this fixed, help patch LLVM to allow side-effect free loops, or help move insert-sideeffect to be on by default and stable.

Clippy should give accurate information about the current state of the compiler. If the compiler improves later then the lint can be updated later to match the improvement.

@josephlr

Once core is fixed to make spin_loop_hint have a side-effect on all platforms, we recommend that.

Is there even an issue about this ever happening? Because I don't think this will otherwise happen.

josephlr

comment created time in 15 days

pull request commentrust-lang/rust-clippy

Enable empty_loop for no_std crates.

Empty loops are an essential part of any embedded application (and quite a few other applications, too); telling a user to use a weird unrelated unsafe magic or go unstable is not a solution.

Anything else is UB.

Any volatile isn't "weird unrelated unsafe magic", every embedded developer needs to understand when to use volatile.

josephlr

comment created time in 15 days

pull request commentrust-lang/rust-clippy

Enable empty_loop for no_std crates.

The fact that the codegen will miscompile the program means that the program is not correct with or without the hint.

The intended semantics of loop{} is "that's fine" the actual semantics of loop{} is "LLVM will burn you". We have to live by the semantics we get.

The official, unstable, way to handle this problem is the -Zinsert-sideeffect flag that jonas-schievink mentioned.

The stable way to handle this is to volatile read a stack variable, like I said.

Fair enough, but what would be the issue using a nop instead? Well, because that's not a loop.

josephlr

comment created time in 15 days

pull request commentrust-lang/rust-clippy

Enable empty_loop for no_std crates.

It's a hint. A hint never changes the correctness (or not) of a program.

For example, I do my embedded work on the GBA, and spin_loop_hint does nothing because the ARM7TDMI CPU of a GBA has no built in assembly instruction for a power saving mode like that.

josephlr

comment created time in 15 days

pull request commentrust-lang/rust-clippy

Enable empty_loop for no_std crates.

no_std has no portable way to sleep. you can't suggest thread::sleep, because there's no such thing.

It's maybe a drag, but as jyn514 said, this is the world we live in.

josephlr

comment created time in 15 days

issue closedLokathor/tinyvec

Support `[value; N]` syntax with non-matching sizes

let vec: TinyVec<[f32; 4]> = tiny_vec![1.1; 3];

currently fails with:

8 |     let vec: TinyVec<[f32; 4]> = tiny_vec![1.1; 3];
  |              -----------------   ^^^^^^^^^^^^^^^^^ expected an array with a fixed size of 4 elements, found one with 3 elements
  |              |
  |              expected due to this

but using tiny_vec![1.1, 1.1, 1.1] in the same location works, also should be supported:

let vec: ArrayVec<[f32; 4]> = array_vec![1.1; 3];
let vec: TinyVec<[f32; 4]> = tiny_vec![1.1; 5];

And should check the error message for this to make sure it's still good:

let vec: ArrayVec<[f32; 4]> = array_vec![1.1; 5];

closed time in 15 days

Nemo157

push eventLokathor/tinyvec

Lokathor

commit sha 4ca258a5ca45e764b49d28f6ea96fd85b04ca2f7

rustfmt

view details

Lokathor

commit sha feecd9ae837d8b98227a7645b5be890c7266d23f

make docs even more plain and simple.

view details

Lokathor

commit sha 3946023ad4359b1aff2b4bf983c3024e87b8b62d

update changelog

view details

push time in 15 days

push eventLokathor/tinyvec

Johnny

commit sha c570a1148c09c4f45a2c1e53bfda417615d98c19

Add into_inner method (#124) * Add into_inner method * Whoops, forgot the function

view details

push time in 15 days

PR merged Lokathor/tinyvec

Add into_inner method

This method adds the into_inner method to both ArrayVec and TinyVec and resolves #122. It also adds documentation and doc-tests for both of these functions.

Implementation questions:

  • If the length of an ArrayVec is less than its capacity, should it return an error value or should it return the array with its default values? I have taken the latter option for the time being.
+8883 -1635

4 comments

6 changed files

not-a-seagull

pr closed time in 15 days

issue closedLokathor/tinyvec

Add some kind of "into_inner" function to ArrayVec and TinyVec

In my program, I use smallvec to collect iterators into arrays. My strategy is:

let my_iterator = { /* ... */ };
let res: [Foobar; 24] = my_iterator.collect::<SmallVec<[Foobar; 24]>>().into_inner().unwrap();

In this scenario, into_inner() returns Result<[Foobar; 24], SmallVec<[Foobar; 24]>>, where Ok(...) is returned if and only if the length is equal to the array capacity.

I would like to use the tinyvec package in this program instead. Is it possible that something close to into_inner() could be implemented on the ArrayVec and TinyVec structures? I would be willing to implement this PR.

closed time in 15 days

not-a-seagull

pull request commentLokathor/tinyvec

Add into_inner method

great! though also the example doesn't need to be a whole page :3 just a few lines showing that you can get the array out should be enough. I can fix that before publishing if you don't want to.

not sure why CI stopped, i'll restart it

not-a-seagull

comment created time in 15 days

pull request commentLokathor/tinyvec

Add into_inner method

yeouch, lots of diff noise, guess we haven't formatted the repo in a little while.

For TinyVec, the inner fields are already public since it's just an enum, I don't think we need to have an into_inner method at all. People can already do a match and then handle the error however they want.

not-a-seagull

comment created time in 15 days

issue commentsdroege/byte-slice-cast

What's keeping this from being 1.0 right now?

yeah just make the alignment check only allow equal alignment ;P

Lokathor

comment created time in 16 days

issue commentsdroege/byte-slice-cast

What's keeping this from being 1.0 right now?

Bytemuck has a vec cast that checks alignment, which is sound.

Lokathor

comment created time in 16 days

issue commentrust-lang/rust

Must a `const fn` behave exactly the same at runtime as at compile-time?

Note about option 2: changing the FP state causes LLVM UB with the standard IR operations. You have to use special IR ops that account for non-standard floating point state if that's what you want. And I'm pretty sure that no part of rust does that (yet?).

oli-obk

comment created time in 16 days

issue commentLokathor/tinyvec

Support `[value; N]` syntax with non-matching sizes

Yeah, checked just now,

  ($elem:expr; $n:expr) => {
    //$crate::ArrayVec::from([$elem; $n])
    ::core::iter::repeat($elem).count($n).collect()
  };

this makes the type inference fail all over.

Nemo157

comment created time in 16 days

pull request commentrust-lang/stdsimd

Feature/round

Looks good.

The docs should maybe say "whole number" rather than "integer" because these don't convert to an integer type, but that's a small nit that could be fixed later on.

calebzulawski

comment created time in 16 days

issue commentrust-lang/stdsimd

Comparison functions

any_nan / all_nan makes sense. i'm not sure what any_of / all_of would do though.

calebzulawski

comment created time in 16 days

Pull request review commentrust-lang/stdsimd

Feature/round

+macro_rules! implement {+    {+        impl $type:ident {+            int_type = $int_type:ident,+            floor = $floor_intrinsic:literal,+            ceil = $ceil_intrinsic:literal,+            round = $round_intrinsic:literal,+            trunc = $trunc_intrinsic:literal,+        }+    } => {+        mod $type {+            #[allow(improper_ctypes)]+            extern "C" {+                #[link_name = $floor_intrinsic]+                fn floor_intrinsic(x: crate::$type) -> crate::$type;+                #[link_name = $ceil_intrinsic]+                fn ceil_intrinsic(x: crate::$type) -> crate::$type;+                #[link_name = $round_intrinsic]+                fn round_intrinsic(x: crate::$type) -> crate::$type;+                #[link_name = $trunc_intrinsic]+                fn trunc_intrinsic(x: crate::$type) -> crate::$type;+            }++            impl crate::$type {+                /// Returns the largest integer less than or equal to each lane.+                #[must_use = "method returns a new vector and does not mutate the original value"]+                #[inline]+                pub fn floor(self) -> Self {+                    unsafe { floor_intrinsic(self) }+                }++                /// Returns the smallest integer greater than or equal to each lane.+                #[must_use = "method returns a new vector and does not mutate the original value"]+                #[inline]+                pub fn ceil(self) -> Self {+                    unsafe { ceil_intrinsic(self) }+                }++                /// Returns the nearest integer to each lane. Round half-way cases away from 0.0.

Just checking, we have tests about this right? I had thought that some places do "round to even", which means that 1.5 and 2.5 would both round to 2.0.

calebzulawski

comment created time in 16 days

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentrust-lang/rust-clippy

Enable empty_loop for no_std crates.

You can.

let x = 0;
unsafe { (&x as *const i32).read_volatile() };

All the "forward progress" you'd ever need.

josephlr

comment created time in 16 days

more