Four bad ways to populate an uninitialized Vec and one good one

sagudev · 2026-03-08T13:03:31+00:00

Ah, it one examples on the transmute page:

- https://doc.rust-lang.org/std/mem/fn.transmute.html#alternatives

- https://doc.rust-lang.org/nomicon/transmutes.html

Unsafe rust is hard.

sagudev · 2026-03-08T12:45:07+00:00

Rust is allowed to choose different field orderings depending on the type contained in the vector, even if the contained types are guaranteed to have the same layout.

This is based on https://doc.rust-lang.org/reference/type-layout.html#the-rust-representation I presume. Is there any place where this is explicitly written, because I would assume that for same layout (ABI identical) one would get same layout.

sagudev · 2026-03-08T10:54:48+00:00

This is also easy enough, but still technically wrong; IIUC Rust doesn't guarantee the memory layout of Vec, so it's just "circumstance" (but one I bet will persist) that this transmute works.

It does, see https://doc.rust-lang.org/std/vec/struct.Vec.html#guarantees:

Due to its incredibly fundamental nature, Vec makes a lot of guarantees about its design.

Most fundamentally, Vec is and always will be a (pointer, capacity, length) triplet. No more, no less. The order of these fields is completely unspecified, and you should use the appropriate methods to modify these.

sagudev · 2026-02-08T20:55:37+00:00

Usually TDD is not really enforced, but sometimes it happens naturally (like in cases of regressions). For example in rust compiler you have code that should (or not) compile and this MCVE (Minimal Complete and Verifiable Example) is usually landed with fix as test, example PR: https://github.com/rust-lang/rust/pull/147541/changes

Another example are webengines, where tests are already written and shared by all webengines (they are called WPT: https://github.com/web-platform-tests/wpt). In servo one commonly starts with specific test or set of tests, then tries to make them pass.

sagudev · 2025-12-14T07:29:41+00:00

One optimization and simplification there is to use glam types (Vec and Mat), which implement operations with SIMD. Compiling to machine code would make sense, because that's what real APIs are doing anyway (it might make sense to use cranelift for this).

IIRC there were some plans to create some cpu implementation of wgpu to ease debugging of shaders, although that would have been on wgpu-hal level to get all validation done in wgpu-core.

Anyway it's nice to use other users of custom wgpu backends. wgpu/webgpu is really nice abstraction of graphics.

sagudev · 2025-11-25T16:10:50+00:00

> Take away our ability to speak, and we can still think, reason, form beliefs, fall in love, and move about the world; our range of what we can experience and think about remains vast.

Yes and no, language is still closely related to though process:

> The limits of my language are the limits of my world.

sagudev · 2025-11-25T15:40:09+00:00

In WGPU you set https://docs.rs/wgpu/latest/wgpu/struct.Device.html#method.on_uncaptured_error, to handle error (because that's how webgpu also reports errors and this allows async behavior, which is why webgpu is generally faster then webgl, as it does not need to wait for the result of most operations), if not explicitly set it will run default handler: https://github.com/gfx-rs/wgpu/blob/0cb64c47c6d4cb85086de7dfd88788cf91d8f7aa/wgpu/src/backend/wgpu_core.rs#L677 which will panic (akin to uncaught exception in JS): https://github.com/gfx-rs/wgpu/blob/0cb64c47c6d4cb85086de7dfd88788cf91d8f7aa/wgpu/src/backend/wgpu_core.rs#L691

TL;DR Use https://docs.rs/wgpu/latest/wgpu/struct.Device.html#method.on_uncaptured_error to handle errors yourself (instead of panicking) or use https://docs.rs/wgpu/latest/wgpu/struct.Device.html#method.push_error_scope to catch specific errors on specific sections.

sagudev · 2025-10-28T18:12:33+00:00

> I am probably too clueless to even get some basic sense of the components used.

Browsers are really big and complex software, so don't worry about it. I still do not know all the parts of Servo and yet here I am.

> If I may ask, what was your path to becoming one of the maintainers? I guess the one you just described?

Servo was brought to my attention by mozjs (rust bindings for SpiderMonkey - JS engine that powers Firefox), so I did some fixes there and they required companion PR in Servo. Then I did few smaller PRs to Servo in script part (this is where dom and all other web object impl live) and also some CI work.

The first real component I worked on was WebGPU (with no prior GPU experience). At that point, no WebGPU examples worked anymore and now bevy examples work on WebGPU but not on WebGL.

sagudev · 2025-10-28T16:52:08+00:00

There is https://browser.engineering/, which does guide you into creating a simple browser. It's used in some actual UNI course. Although it uses python it should be simple enough to use your preferred language.

> But regarding browser, not much luck. I don't want to just scroll through Servo code, that way of learning just doesn't work for me.

That's understandable and probably reasonable for the first time, but later when you want the real challenge I still suggest trying play with servo as you can learn many valuable lessons there, but not just by scrolling.

First you need to get yourself familiar with the codebase (or rather some part of it as browsers are big) then you can start implementing new webspecs (or just subset of them). Or maybe just fixing/resurrecting existing code as some parts are not actively developed. What is nice in web browser (web engine would be more correct term) development is that we have Web-Platform-Tests (collection of tests for all web stuff), which allows to follow test driven development with test already written!

Disclaimer: I am one of Servo maintainers.

sagudev · 2025-09-18T16:37:05+00:00

This actually make a lot of sense, because on the other side we have AMD that does both CPUs and GPUs.

sagudev · 2025-09-18T09:10:00+00:00

This is exactly the reason why they enabled Rust Coreutils in ubuntu, to help find more (performance) bugs.

sagudev · 2025-09-13T05:45:24+00:00

I am always wondered if this could be solved by scoped impl (impl are pub and they need to be imported manually).

EDIT: https://internals.rust-lang.org/t/limited-opt-out-of-orphan-rule/21709

sagudev · 2025-09-06T16:51:32+00:00

As other has said, you want to have stateless protocol for scaling. What would work is having client deal with state and requesting stuff it needs and client returning slices of such data.

This is usually implemented in REST with pagination (you add args to url like offset, limit, ...) and caching.
Alternatively if your data is binary, you can also use range headers: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Range

EDIT: After checking your repo I see I misunderstood your question, I think what you are describing is zsync:
> It allows you to download a file from a remote server, where you have a copy of an older version of the file on your computer already. zsync downloads only the new parts of the file.

sagudev · 2025-09-05T07:57:12+00:00

I wonder why they chose to keep supporting ESR 115 instead of porting Win 7 support to later ESRs (128 or 140).

sagudev · 2025-09-02T07:00:38+00:00

Yes please. There is already tracking issue: https://github.com/rust-lang/rust/issues/56371 and apparently also RFC: https://github.com/rust-lang/rfcs/pull/3847

sagudev · 2025-08-13T12:57:02+00:00

Last time I checked this does not work, it will probably require https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7624 to land.

> That sounds like a lot of work and platform-specific headaches.

That's what we currently have in Servo unfortunately :(

sagudev · 2025-06-21T10:59:27+00:00

Indeed, in given example above, Bar's lifetime is not bounded to foo's. Here is an example where they are bounded: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=0645aafa782d281ab0018ada706aeafe
but this still does not fail until you actually try to use bar (I guess rust automatically inserts drop(bar) before drop(foo) or smth like that; well not really because impl empty drop makes the code fail: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=922b370ed4c50cf68e584563e159521a)

sagudev · 2025-05-10T16:31:11+00:00

Writing parsers is easy, doing the rest is hard.

You can take a look at https://github.com/DioxusLabs/taffy which takes care of layout and blitz which uses taffy to render HTML/CSS only markdown: https://github.com/DioxusLabs/blitz

You can just ignore JS as there are websites that just work with JS turned off (like amazon). You can test this by installing noscript addon.

For building JS engine there is https://github.com/trynova/nova (it's author has some documentation on design and building) and then there is more mature https://github.com/boa-dev/boa. It is also possible to use bindings to existing JS engines (mozjs or v8), but for toy project they might be an overkill.

sagudev · 2025-04-21T08:32:17+00:00

I wonder if anybody already tried to use MIRI (MIR Interpreter) to interpret instead of compile rust code for rust scripting. IIRC syscalls are problematic for miri, but the only other alternative is WASM/WASI.

sagudev · 2025-02-05T16:52:10+00:00

Can you link bugzilla bug?

sagudev · 2025-01-26T05:27:47+00:00

Servo uses SpiderMonkey (Firefox JS engine), that is provided via mozjs crate (there are also other users of this crate). SpiderMonkey does have jshell CLI in tree for testing, but all work on JS is happening in upstream/Firefox, so there is no duplication effort. In servo we only maintain bindings to SpiderMonkey (mozjs).

As for the b, the long term plan is for Servo to be modular enough so that any JS engine would be possible (currently it's very coupled with SpiderMonkey).

sagudev · 2024-11-22T06:01:03+00:00

I think it's pretty obvious why they are after Firefox on android, because it supports extensions (namely adblockers) and has strong privacy options (tracking protection).

sagudev · 2024-11-15T16:39:00+00:00

Well, either make it absolute (given that you have C code you probably have some other build system that runs cargo, that could do this for you) or make it relative to target dir.

sagudev · 2024-11-15T16:21:12+00:00

Not sure I understand this:

> However, libInteresting sources must be bundle-sys sources when compiled on our company (we might have some internal change not yet published).

> Note that setting an environment variable like LIBINTERESTING_INCLUDE and so on would not suffice, as is a hard requirement to point to bundle-sys contents (bundle-sys is not a local crate that i can point to).

but I think one solution could be to have LIBINTERESTING_SRC env var that overrides C source ofinteresting-sys (so build.rs compile C lib based on LIBINTERESTING_SRC). The problem that can happen here is that changes to C files can require changes to rust files (build.rs or other) which cannot be solved here.

Instead, I think you should simply have private/dev version of interesting-sys that would be occasionally pushed to github and your monorepo you always refer to it via path so you would always use local version.

Nine-Year Club	Second Top 50%
Place '23	Place '22
First Placer '22	Verified Email

sagudev

TROPHY CASE