profile
viewpoint

harfbuzz/harfbuzz 1785

HarfBuzz text shaping engine

Frozen-Flask/Frozen-Flask 667

Freezes a Flask application into a set of static files.

binast/binjs-ref 396

Reference implementation for the JavaScript Binary AST format

rust-threadpool/rust-threadpool 361

A very simple thread pool for parallel task execution

kuchiki-rs/kuchiki 327

(朽木) HTML/XML tree manipulation library for Rust

linebender/skribo 278

A Rust library for low-level text layout.

Flask-FlatPages/Flask-FlatPages 243

Provides flat static pages to a Flask application

lifthrasiir/rust-encoding 220

Character encoding support for Rust

Kozea/cairocffi 184

CFFI-based cairo bindings for Python.

rust-lang/wg-allocators 107

Home of the Allocators working group: Paving a path for a standard set of allocator traits to be used in collections!

push eventservo/doc.servo.org

Taskcluster

commit sha e64a865aaf1943987d668cd94beaa8970c89b1f0

Rebuild Servo documentation

view details

push time in 3 hours

startedSimonSapin/rust-typed-arena

started time in 4 hours

push eventservo/doc.servo.org

Taskcluster

commit sha e9dc4a779ce9f4e1cc031ad0d3243833151298d7

Rebuild Servo documentation

view details

push time in 5 hours

issue closedadngdb/arewereorganizedyet.com

Enable HTTPS?

It's time.

closed time in 8 hours

annevk

issue commentadngdb/arewereorganizedyet.com

Enable HTTPS?

Seems this is fixed.

annevk

comment created time in 9 hours

push eventservo/doc.servo.org

Taskcluster

commit sha ccab7bdfd0fb4741d5772f6b31702c32efa65528

Rebuild Servo documentation

view details

push time in 15 hours

push eventservo/doc.servo.org

Taskcluster

commit sha 682362f84f8695d15f50c1cfe4d293b336868d58

Rebuild Servo documentation

view details

push time in a day

push eventservo/doc.servo.org

Taskcluster

commit sha 228141e6e8038f4bc457fa4296ead1516980656c

Rebuild Servo documentation

view details

push time in a day

Pull request review commentrust-lang/libs-team

MCP: API Guidelines

+# API Guidelines++## Writing a 2021 Edition of the API Guidelines++Some patterns have changed and new idioms have emerged since we last spent time on the API Guidelines.+There are some new language features like `impl Trait` and `async` / `await` that haven't been fully considered in the existing guidelines yet.++As of this writing, it's been about two years since any substantial new content was added to the API Guidelines.+That's not necessarily an issue, we could consider the API Guidelines "done" for the 2018 language edition.+Coming up to 2021 we should revist existing recommendations and see if any new ones have come up that make sense for the new edition.

Typo:

Coming up to 2021 we should revisit existing recommendations and see if any new ones have come up that make sense for the new edition.
KodrAus

comment created time in 2 days

push eventrust-lang/libs-team

Ashley Mannix

commit sha 1e2eec65ccb94c074d6f6ecfef7a482e21278a2a

link to (currently empty) std dev guide

view details

push time in 2 days

issue commentrust-lang/wg-cargo-std-aware

Support `cargo vendor`

Ah OK so this is what is tripping us up. I saw https://doc.rust-lang.org/cargo/reference/source-replacement.html#local-registry-sources which says it's OK to have this subset mirror.

By "subset" it is saying that you don't have to mirror all of crates.io locally. It doesn't mean that it will allow something to be missing from the subset. Source replacement works as a "full replacement", not as an overlay.

Also, a local-registry is not what we are talking about here. The vendoring mechanism we are talking about is a directory-source (ala cargo vendor).

ehuss

comment created time in 3 days

issue commentrust-lang/wg-cargo-std-aware

Support `cargo vendor`

It is not transparent in the sense that all dependencies must be vendored, otherwise it is an error (it does not fall back to anything).

Ah OK so this is what is tripping us up. I saw https://doc.rust-lang.org/cargo/reference/source-replacement.html#local-registry-sources which says it's OK to have this subset mirror.

Now, supposing that either the book is correct, or the book can be made correct:

It is transparent in the sense that vendoring shouldn't behave any differently from using the registry sources.

Whew :)

Crates don't provide source replacement. Source replacement is driven by the configuration files, which can be local or global relative to the workspace.

I think thats fine. By conditionally, I mean -Z build-std and information from the current compiler / rust-src component would be mixed in at configuration loading time, just like information from multiple config files is already. Everything together would create the single global Config, as today.

Independently from that, -Z build-std would also influence the std workspace as today. So the std workspace would go looking some compiler-specific crate source code, and independently by the config-time mechnaism, the otherwise-unonbtainable source containing those crate source code would be replaced in.

ehuss

comment created time in 3 days

issue commentrust-lang/wg-cargo-std-aware

Support `cargo vendor`

Sorry, I'm having a hard time understanding what you are saying.

isn't the decision here about when/where to use the vendor, not when to create it?

The intent here is that the std dependencies are always vendored (located in $SYROOT/.../lib/rustlib/src/rust/vendor/...). The issue is that it is not easy to have Cargo conditionally use vendoring for one workspace versus not in another (as described above in https://github.com/rust-lang/wg-cargo-std-aware/issues/23#issuecomment-765474842), because it is a global setting (global in the sense of within the Cargo process, since Config is essentially a global).

When doing -Z build-std it uses whatever replacement source the crate provides, globally but conditionally.

Crates don't provide source replacement. Source replacement is driven by the configuration files, which can be local or global relative to the workspace. If you mean conditionally within Cargo, that's what I explained above that the global Config is not designed to be conditional or easily cloned.

The fact that this vendor isn't always the same I thought was OK, because source replacement is transparent

I don't know what is meant by "transparent" here. It is transparent in the sense that vendoring shouldn't behave any differently from using the registry sources. It is not transparent in the sense that all dependencies must be vendored, otherwise it is an error (it does not fall back to anything).

ehuss

comment created time in 3 days

issue commentrust-lang/wg-cargo-std-aware

Support `cargo vendor`

@ehuss isn't the decision here about when/where to use the vendor, not when to create it? When doing -Z build-std it uses whatever replacement source the crate provides, globally but conditionally. The fact that this vendor isn't always the same I thought was OK, because source replacement is transparent, so the project workspace won't need to care. The std workspace of course will care what is and isn't there since it has no crates.io to fall back on, but it varies with the vendor so I think it would be OK

ehuss

comment created time in 3 days

issue commentrust-lang/wg-cargo-std-aware

Support `cargo vendor`

If both workspaces are vendored into the same directory, that would tie it to a specific version of rustc. Switching versions of rustc would need different dependencies that don't appear in the vendor directory, which would lead to an error.

ehuss

comment created time in 3 days

issue commentrust-lang/wg-cargo-std-aware

Support `cargo vendor`

@ehuss Sorry, let me try to be clearer: what's the problem for turning on the vendoring or both workspaces? If cfg_if or hash_brown is needed twice, it just works right? And if something isn't in the vendor it falls back on crates.io, right?

ehuss

comment created time in 3 days

issue commentrust-lang/wg-cargo-std-aware

Support `cargo vendor`

Sorry, I'm not sure I understand the question. The issue with using source replacement is that it is a global config setting in Cargo which would affect both workspaces. One possible route is to change this line to create some kind of clone of the config, and modify the config to enable vendoring for just the std workspace. However, Config isn't really designed to be cloned, and that might be tricky to do efficiently. I'm also uncertain if that might trigger problems elsewhere (for example this line where the PackagetSets from the two workspaces are merged).

ehuss

comment created time in 4 days

issue openedservo/rust-cssparser

Build error running on Github Actions

When trying to run on Github Actions (ubuntu-latest), build.rs fails to run giving an obtuse exit code. I can't reproduce this locally on my machine so I'm a bit stumped as to what might be causing it.

You can see the output of one such run at: https://github.com/lovelace-ed/lovelace/runs/1747751311

created time in 4 days

MemberEvent

pull request commentadngdb/arewereorganizedyet.com

they say start the year the way you want to spend it so let's REORG!

Thanks Rehan! I've invited you, let me know if there's a problem.

rehandalal

comment created time in 5 days

push eventservo/doc.servo.org

Taskcluster

commit sha 2953cfdaa3eeaa94fb1bc007aecf6fd1d7938f85

Rebuild Servo documentation

view details

push time in 5 days

pull request commentadngdb/arewereorganizedyet.com

they say start the year the way you want to spend it so let's REORG!

I'm happy to hop on as a maintainer.

rehandalal

comment created time in 5 days

push eventadngdb/arewereorganizedyet.com

R&D

commit sha 18ac3626e6118e289e3d5c038e1710fa22f2c5a2

they say start the year the way you want to spend it so let's REORG! (#60)

view details

push time in 5 days

push eventservo/doc.servo.org

Taskcluster

commit sha 7d911776adfc79edc265d1d1d5a0e7aa999167c5

Rebuild Servo documentation

view details

push time in 5 days

issue commentrust-lang/wg-cargo-std-aware

Support `cargo vendor`

@ehuss is the a problem for turning it on for both workspaces? Isn't vendoring transparent so it need not affect the lockfile?

ehuss

comment created time in 5 days

Pull request review commentadngdb/arewereorganizedyet.com

they say start the year the way you want to spend it so let's REORG!

 <h1 id="answer" class="flex">WAIT</h1>         <h2>Days since last reorg: <strong id="last-reorg-days"></strong></h2>         <h2>Expected reorg <strong id="next-reorg-days"></strong></h2>         <ul>+            <li>(since January 19, 2020)</li>

DOH!

rehandalal

comment created time in 6 days

push eventservo/doc.servo.org

Taskcluster

commit sha 60336d3058c7f0ae5c82f261cca919df868b1ef9

Rebuild Servo documentation

view details

push time in 6 days

push eventservo/doc.servo.org

Taskcluster

commit sha 42d7034d1afd4c0e013972d2067c830e308c1c73

Rebuild Servo documentation

view details

push time in 6 days

Pull request review commentadngdb/arewereorganizedyet.com

they say start the year the way you want to spend it so let's REORG!

 <h1 id="answer" class="flex">WAIT</h1>         <h2>Days since last reorg: <strong id="last-reorg-days"></strong></h2>         <h2>Expected reorg <strong id="next-reorg-days"></strong></h2>         <ul>+            <li>(since January 19, 2020)</li>

2021?

rehandalal

comment created time in 6 days

more