djmcnab (u/djmcnab) - Readit News

djmcnab commented on WebKit switching to Skia for 2d graphics rendering blogs.igalia.com/carlosgc... · Posted by u/jessevdk

nox101 · 2 years ago

Vello is used in Skia

https://skia.googlesource.com/skia/+/2e551697dc56/third_part...

djmcnab · 2 years ago

Disclaimer: I work on Vello[0], but not on the Skia integration directly

My understanding, having not dug into it too much, is that the Skia integration does exist, but isn't enabled by default/any clients at the moment. That is, I don't know that this integration is shipping anywhere.

Vello still has some definite rough edges at the moment, so I'm not sure I'd recommend using it in a production application at the moment. We also don't have a C API, which might rule it out for some cases where you'd be considering Skia.

[0]: https://linebender.org/blog/xilem-2024/

djmcnab commented on Dennis Ritchie on the priorities of && || vs. == etc. (1982) lysator.liu.se/c/dmr-on-o... · Posted by u/spc476

tialaramex · 2 years ago

One of the most intriguing novel ideas in Carbon (One of the "C++ Replacement languages" announced in 2022) is the idea that operator precedence should not be a total order.

Lots of prior languages have tried either:

1. No operator precedence, expressions must use parentheses so that it's very clear

2. No operator precedence, everything just happens left to right regardless

But Carbon says what if we do have precedence, but only between operators which programmers expect to have precedence - whenever it's unclear what should happen the compiler instead rejects that, the same way many languages won't let you ask whether 5 == "Five" because you need to explain WTF you intended as most likely you've screwed up and didn't realise they're completely different types.

djmcnab · 2 years ago

WGSL (the shading language for WebGPU) has something similar[1].

For example, `a + b << c` will fail to parse in a conforming implementation, as will `a << b << c` and `a && b || c`. Note however that `a && b && c` does parse. I find these rules to be well-thought through.

[1]: https://www.w3.org/TR/WGSL/#operator-precedence-associativit...

djmcnab commented on Bevy 0.9: data oriented game engine built in Rust bevyengine.org/news/bevy-... · Posted by u/_cart

prideout · 3 years ago

How are entity id's managed? When an entity "dies", can its id be re-used?

From a Rust-on-WASM perspective, it might be useful to limit the entity id's to ~52 bits or less, since native JavaScript numbers are doubles.

djmcnab · 3 years ago

> From a Rust-on-WASM perspective, it might be useful to limit the entity id's to ~52 bits or less, since native JavaScript numbers are doubles.

Since compiling to web uses WebAssembly, we can just use native 64 bit integers for our entities. In general, we avoid introducing differences between web and native targets, and this is no exception.

If you do need to round-trip full entities using JavaScript, you should either store them in one of the native non-broken integer types (such as `BigInt` or `BigUint64Array`), or just store the `index` and `generation` as seperate `number`s. It's worth recognising that in most cases, you should only need to exchange the entity `id` with different systems, as the `generation` is mainly used to panic on use-after-free conditions.

djmcnab commented on iPhones and action discoverability alexanderell.is/posts/iph... · Posted by u/otras

jbverschoor · 3 years ago

While I also hate the "undescoverability". It's possible that all (maybe not all) usecases of an app are still available to anything visible. For older or less tech interested people, this is actually perfect.

The problem lies in the following cases:

1) Person accidentally does something

2) Edge case / state / scenario, which cannot be solved without knowing some shortcuts.

I think iOS became too complicated for some people. At the same time the UI is a pretty messy and inconsistent at times.

djmcnab · 3 years ago

In unfamiliar UIs, I often find myself accidentally triggering keyboard shortcuts and getting into weird states, so 1) leading to 2). A classic example is changing into override mode[0] in Microsoft Word or similar[1].

You end up in a mode where typing no longer adds characters, but replaces them. If you're at the end of the document, it would still add characers, but you stay in override mode. Meaning that once you're in this mode, it doesn't strike until you start editing or try to fix a typo, when the computer. WordPad doesn't even have any visual distinction.

Visual Studio Code's solution to this is nice. If you enter `Tab Moves Focus` mode, with <kbd>Ctrl</kbd>+<kbd>M</kbd>, the info bar shows the text `Tab Moves Focus` in a (tastefully) highlighted button, clicking which disables that mode. So you will have a moment of confusion upon pressing tab, inadvertently entering the mode, however the situation of 2) is avoided as a helping hand is visible.

Perhaps another UI is to have a log of activated keyboard shortcuts always visible, with 'new' shortcuts highlighted more obviously (perhaps with some estimation of decaying familiarity). I'm not familiar with this being implemented anywhere, but I think it at least merits consideration.

[0] This is activated with <kbd>Insert</kbd>; https://en.wikipedia.org/wiki/Insert_key [1] In the version of Word I currently have installed, this behaviour seems to be disabled/removed. However, Wordpad still changes into override mode upon pressing Insert.

djmcnab commented on A personal list of Rust grievances gist.github.com/brendanza... · Posted by u/todsacerdoti

heavyset_go · 3 years ago

Big one for me that stops me from using Rust like I would a scripting language for some tasks is the lack of an easy iterator/generator syntax.

Python and JavaScript make it dead simple to create iterators using generator functions, and in Python's case, generator expressions, as well.

For example, there are a lot of problems that are solved simply and efficiency by chaining generators together in pipelines. That's a task that's easy to tackle in Python and even JavaScript, but it can sometimes be awkward with Rust when defining iterators in the first place.

It's frustrating because Rust has a lot of features that make working with iterators nice. It's just a shame that they're awkward to create from scratch.

djmcnab · 3 years ago

Are you familiar with `core::other::from_fn`[1]. This allows converting from `impl FnMut() -> Option<T>` to `impl Iterator<Item = T>`.

I recognise that these aren't strictly generators - you need to do your own state tracking. However, this does make it easier to do that ad-hoc.

I believe there is some work in the ecosystem abusing `async` to make fake generators, although I haven't used any of them.

[1]: https://doc.rust-lang.org/stable/core/iter/fn.from_fn.html

djmcnab commented on Bevy 0.7: data oriented game engine built in Rust bevyengine.org/news/bevy-... · Posted by u/_cart

andrewmcwatters · 4 years ago

Any plans to provide out of the box multiplayer? Lots of engines today don't think about it at all, and instead seem to focus on the sort of feature set provided by Unreal and Unity.

I don't think there's a whole lot of value in that design, but that's my personal opinion having built an engine for the Lua community that did somethings no one else was doing.

Mainly, providing an out of the box experience for, typically, hobbyist developers who don't actually know anything about multiplayer serialization or prediction, etc.

The sort of younger developers and people who are playing around with code and posting on Reddit and such.

A lot of engines are just wrappers around popular libraries and I don't know if there's a tremendous value around that sort of thing.

Consider, for example, audio. It's really easy to provide audio bindings to, I don't know, let's say OpenAL, because I don't know what else is used these days. But game developers eventually mature enough where they don't just care about playing audio.

What they'll eventually want is to play a sound, with DSP, and have that audio automatically networked by the engine to play on different connected client's based on visibility rules or at least a simple emit sound networked event.

There's an entire class of hobby engines that don't consider these things, and leave it as an exercise for the user to implement. They are entirely non-trivial features that the users will never implement, though, and instead just never pursue that feature because the engine doesn't provide it.

djmcnab · 4 years ago

To copy from another comment[0] elsewhere in the thread from cart:

> The story is similar for networking. Ultimately we will have a built in api, but we're focused on more fundamental things at the moment. There are _tons_ of community-developed networking plugins though: https://bevyengine.org/assets/#networking

That is, we do definitely want to make multiplayer work properly, and our data design should give us inherent advantages here. But it hasn't been a priority so far, as we've had other more pressing requirements (e.g. animation this release).

But a lot of what you want should in the medium term be provided by external crates; our use of systems as the unit of logic should make this viable, as behaviour implemented by the engine is not special. These external crates could potentially be made official if that made sense, but that's for much longer time scales.

[0]: https://news.ycombinator.com/item?id=31044108

djmcnab commented on Bevy 0.7: data oriented game engine built in Rust bevyengine.org/news/bevy-... · Posted by u/_cart

MiniaczQ · 4 years ago

That's because with 0.6 Bevy moved onto a 3-month release schedule :)

djmcnab · 4 years ago

Yes, indeed. This was mentioned in 0.6's release notes[0]. However, this is the first actual stop of the train, so we probably could have mentioned it in these release notes as well.

[0]: https://bevyengine.org/news/bevy-0-6/#the-train-release-sche...

djmcnab commented on Bevy 0.7: data oriented game engine built in Rust bevyengine.org/news/bevy-... · Posted by u/_cart

djmcnab · 4 years ago

A change I find interesting in this release is the addition of `Deref`/`DerefMut` derives[0]. It addresses a very real pain point in bevy, due to `#[derive(Component)]`'s interaction with the orphan rules requiring newtypes[^1].

But it's potentially not idiomatic within the Rust language, at least at the moment (as mentioned in the OP). However, I think that the tide is likely to turn on that; for example, in the api-guidelines repo, there's a PR[2] to remove this advice. This appears to have stalled, although that appears to be not for reasons of it being controversial, just lack of reviews; the discussion had broad support.

We have discussed (in Discord[3]) a kind of 'internal' `Deref`, which would use lenses to do automatic unwrapping for queries. See #4413 [4] for an example of what this would look like. I'm not sure how necessary that is if we can just use `Deref[Mut]`, but it's definitely another angle we could go down long-term.

[0]: https://bevyengine.org/news/bevy-0-7/#deref-derefmut-derives

[^1]: This newtype requirement isn't a negative for bevy, since it makes it much easier to avoid interoperability headaches between different crates.

[2]: https://github.com/rust-lang/api-guidelines/pull/251

[3]: https://discord.gg/bevy

[4]: https://github.com/bevyengine/bevy/pull/4413

djmcnab commented on Making Rust a Better Fit for Cheri and Other Platforms tratt.net/laurie/blog/202... · Posted by u/ltratt

roblabla · 4 years ago

Problem is, there's lots of unsafe code that casts *mut T to &mut T (usually after checking T is valid and whatnot). If &mut T didn't use capabilities, this kind of unsafe code would end up not taking advantage of the CHERI capability checking, which would be unfortunate.

djmcnab · 4 years ago

I don't think this is actually a problem, since when casting from `&mut T` to `*mut T`, the returned pointer can only access the data (the T value) directly behind the reference.

The raw pointer would be synthesised with the capability for only the pointee of the original reference.

djmcnab commented on Making Rust a Better Fit for Cheri and Other Platforms tratt.net/laurie/blog/202... · Posted by u/ltratt

ltratt · 4 years ago

I agree that you don't want non-CHERI Rust code to have to know about capabilities in any way. However, if you are using Rust for CHERI, you need to have some access to capability functions otherwise, even in pure capability mode, you can't reduce a capability's permissions. For example, if you want to write `malloc` in purecap Rust, you'll probably want to hand out capabilities that point to blocks of memory with bounds that only cover that block: you need some way to say "create a new capability which has smaller bounds than its parent capability."

As to the utility of hybrid mode, I politely disagree. For example, is it useful for safe Rust code to always pay the size penalty of capabilities when you've proven at compile-time that they can't misuse the underlying pointers? A very different example is that hybrid mode allows you to meaningfully impose sub-process like compartments (in particular with the `DDC` register, which restricts non-capability code to a subset of the virtual address space; see also the `PCC` register and friends). Personally, I think that this latter technique holds a great deal of potential.

djmcnab · 4 years ago

One potential option I haven't seen mentioned is to make references (i.e. `&[mut] T`) not use capabilities, but raw pointers (`*(mut|const)`) to use capabilities. Since the compiler already guarantees that references are used correctly, at least theoretically this is best of all worlds.

Now it's possible that CHERI would make this impossible, but it's definitely an angle worth recognising.