immersive-web/webxr 1901
Repository for the WebXR Device API Specification.
An extraction of the compiletest utility from the Rust compiler
"Freedom from syn": Proc macro tools for operating on token trees
immersive-web/webxr-hand-input 50
A feature repo for working on hand input support in WebXR. Feature lead: Manish Goregaokar
Safe wrapper for initializing arrays
Annotations for tabs in Chrome
immersive-web/webxr-test-api 6
WPT testing API for WebXR
Python2&3 API for talking to the StackExchange chat
Distributed file system using Raft Consensus protocol
Meta-tracker for my GSoC 2016 project
push eventrust-lang/rust-clippy
commit sha 1d3a09a9a0c29dd1e98d72b0dfeec51811eb8538
Automatic deploy to GitHub Pages: 85959be60667ec158da0a1824506ebba47791317
push time in 4 hours
push eventimmersive-web/webxr
commit sha 01361ec7e35541ed61db311de112da631cee10dc
Move layers and hands input to WG
commit sha e35bbf389f956aba037a37cc53d878d1f8451aa4
Changed the link format to numbers
commit sha 9cda4d399abdd5f8a7fef9bfdb69a582bccc75a7
Merge pull request #1139 from immersive-web/Yonet-patch-1 Move layers and hands input to WG
push time in 10 hours
push eventrust-lang/rust-clippy
commit sha 215062b5d64d368d8bd6c1e2855149dc6ddf0a18
Automatic deploy to GitHub Pages: eaffd0e41837dd952d0854a2f2aea35cccbb6319
push time in 18 hours
pull request commentimmersive-web/webxr-hand-input
Editorial: Align with Web IDL specification
Woohoo, finally Exposed is in core webidl
comment created time in 2 days
push eventimmersive-web/webxr-hand-input
commit sha 55b32ef62b88bcd9cd3d1a75705e6f51256fdc33
Editorial: Align with Web IDL specification
commit sha 212b2add392ab566cbbb19ed7907cebdd273706e
Merge pull request #54 from autokagami/webxr-hand-input Editorial: Align with Web IDL specification
push time in 2 days
PR merged immersive-web/webxr-hand-input
This is an automated pull request to align the spec with the latest Web IDL specification.
Currently the autofix might introduce some awkward code formatting, so please feel free to modify the formatting.
Please file an issue on https://github.com/saschanaz/webidl-updater/issues/new if you think this PR is invalid or should be enhanced.
The following is the validation messages from webidl2.js, which may help understanding this PR:
Validation error at line 1 in webxr-hand-input,1, inside `interface XRHand`:
interface XRHand {
^ Interfaces must have `[Exposed]` extended attribute. To fix, add, for example, `[Exposed=Window]`. Please also consider carefully if your interface should also be exposed in a Worker scope. Refer to the [WebIDL spec section on Exposed](https://heycam.github.io/webidl/#Exposed) for more information.
Validation error at line 1 in webxr-hand-input,2, inside `interface XRJointSpace`:
interface XRJointSpace: XRSpace {}
^ Interfaces must have `[Exposed]` extended attribute. To fix, add, for example, `[Exposed=Window]`. Please also consider carefully if your interface should also be exposed in a Worker scope. Refer to the [WebIDL spec section on Exposed](https://heycam.github.io/webidl/#Exposed) for more information.
Validation error at line 1 in webxr-hand-input,4, inside `interface XRJointPose`:
interface XRJointPose: XRPose {
^ Interfaces must have `[Exposed]` extended attribute. To fix, add, for example, `[Exposed=Window]`. Please also consider carefully if your interface should also be exposed in a Worker scope. Refer to the [WebIDL spec section on Exposed](https://heycam.github.io/webidl/#Exposed) for more information.
<!-- This comment and the below content is programatically generated. You may add a comma-separated list of anchors you'd like a direct link to below (e.g. #idl-serializers, #idl-sequence):
Don't remove this comment or modify anything below this line.
If you don't want a preview generated for this pull request,
just replace the whole of this comment's content by "no preview"
and remove what's below.
-->
<a href="https://pr-preview.s3.amazonaws.com/autokagami/webxr-hand-input/pull/54.html" title="Last updated on Oct 18, 2020, 3:00 AM UTC (55b32ef)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/immersive-web/webxr-hand-input/54/eb38266...autokagami:55b32ef.html" title="Last updated on Oct 18, 2020, 3:00 AM UTC (55b32ef)">Diff</a>
pr closed time in 2 days
issue commentManishearth/absolution
IntSuffix, FloatSuffix not pub
Yeah that would be great!
comment created time in 3 days
pull request commentrust-lang/rust
Remove intra-doc link disambiguation prefix aliases
We're allowed to break beta, but yes, if this wants to land it should be soon. I am against removing things other than prim though.
comment created time in 3 days
pull request commentw3c/csswg-drafts
[css-egg-1] Add the `adafish` unit and the `performance` media query
(yay, i've lost my Mozilla affiliation and can't make PRs to w3c repos that are not webxr anymore)
comment created time in 3 days
pull request commentw3c/csswg-drafts
[css-egg-1] Add the `adafish` unit and the `performance` media query
Marked as non substantive for IPR from ash-nazg.
comment created time in 3 days
PR opened w3c/csswg-drafts
[css-egg-1] Add the adafish unit and the performance media query
This was first proposed by @toji in https://twitter.com/Tojiro/status/1317298532630499329 , and has rapidly gained the support of the community (me).
cc @AdaRoseCannon
r? @tabatkins
pr created time in 3 days
issue commentManishearth/namespacing-rfc
My personal take on this is that typosquatting is not that big a deal and we mostly should decide on whether registering foo/bar blocks out the registration of foo-bar or not. But if we want to solve it, I'd prefer to not lose the UX of "it's just the name of the crate" in the process.
comment created time in 4 days
issue commentManishearth/namespacing-rfc
@carols10cents I don't see how this proposal fixes typosquatting, in essence the crate will still be serde_json in rust code. serde/json vs serde = { subcrate = json } both seem to have the same amount of typosquatting issues, except in the latter you have to type a lot more and people need to
[dependencies.serde] version = "1.0" # to depend on the parent crate, omit this if you aren't depending on the parent json = "1.0" # to depend on the serde/json crate
We can't do this because this locks us out of ever adding more keys to the dependency spec format
comment created time in 4 days
push eventrust-lang/rust-clippy
commit sha 3e679ca435db915c8ed1aee8e95d3bae0db0857f
Automatic deploy to GitHub Pages: 4e83a38618cb6160cf6a7297ed3413f434149242
push time in 4 days
issue commentManishearth/namespacing-rfc
Yeah to be clear discussion for that should probably belong on #3, but we might need to merge things.
comment created time in 4 days
issue commentManishearth/namespacing-rfc
@carols10cents an important point brought up by @withoutboats was that something that "converts to an underscore" would not require rustc changes, and they prefer a solution that is self contained in cargo/crates.
comment created time in 4 days
issue commentManishearth/namespacing-rfc
Have I understood correctly?
Correct! I've updated the RFC. The intent is to make sure that foo- does not become a de facto namespace.
use serde_gelf as serde_somethingelse_gelf; // need to choose a new name for one of them
This would have to be renamed in Cargo.toml, otherwise both would map as serde_gelf and Cargo would have to throw an error. Cargo lets you do this already.
(Worth noting, it's already possible to publish multiple crates that have the same lib name, so Cargo needs to deal with this already)
Seems... non-ambiguous to the compiler but potentially a little annoying for the programmer, but probably not common?
Correct, however someone could maliciously do this to confuse people, e.g. by publishing serde-gelf containing a bitcoin miner, whereas serde/gelf is the Actual Good crate.
comment created time in 4 days
push eventManishearth/namespacing-rfc
commit sha 136a5b8e10f8195dffd35e409fdc0a997025db61
Incorporate feedback from Carol From https://github.com/Manishearth/namespacing-rfc/issues/2#issuecomment-710101569
push time in 4 days
issue commentrust-lang/cargo
Accept hyphen in crate name in place of underscore
I've posted https://internals.rust-lang.org/t/pre-rfc-unify-dashes-and-underscores-on-crates-io/13216/13. It's becoming more clear to me that this doesn't need an RFC, but I've posted the pre RFC anyway.
I don't actually think the exponential growth for names with a large number of separators is a problem. In those cases we can traverse the index trie, looking for both separators whenever there is one, and splitting the search if both exist. Note that this will not cause exponential growth unless there actually are crates with that combination of separator: it's unlikely that foo-bar-baz-quux-1 and foo-bar-baz_quux-2 and foo-bar_baz-quux-3 and so on all exist (and if they do it's probably an automated publish in violation of crates.io policy). In other words, it's only possible to engineer an exponentially bad situation here on purpose, it's not really possible as an accident.
comment created time in 4 days
push eventrust-lang/team
commit sha f5a39bbd8fddd9f6ecbc0df0e2d08b928c4fd4e3
Fix Zulip stream name It should've been `t-lang/doc`.
commit sha 2fce82c8f7e4fc5950d734d765da6ba5ae56f104
Merge pull request #454 from JohnTitor/fix-zulip-stream Fix Zulip stream name
push time in 5 days
PR merged rust-lang/team
It should've been t-lang/doc, sorry for the trouble.
pr closed time in 5 days
issue openedManishearth/namespacing-rfc
Drawback: Namespace root token
The RFC as written prevents certain namespaces from existing
Not all existing projects can transition to using namespaces here. For example, the
unicodecrate is reserved, sounicode-rscannot use it as a namespace despite owning most of theunicode-foocrates. In other cases, the "namespace root"foomay be owned by a different set of people than thefoo-barcrates, and folks may need to negotiate (async-stdhas this problem, it managesasync-foocrates but the rootasynccrate is taken by someone else). Nobody is forced to switch to namespaces, of course, so the damage here is limited, but it would be nice for everyone to be able to transition.
created time in 5 days
issue openedManishearth/namespacing-rfc
The RFC as currently written provides a less-than-ideal migration path:
Existing projects wishing to use this may need to manually migrate. For example,
unic-langidmay becomeunic/langid, with theunicproject maintainingunic-langidas a reexport crate with the same version number. Getting people to migrate might be a bit of work, and furthermore maintaining a reexport crate during the (potentially long) transition period will also be some work. Of course, there is no obligation to maintain a transition crate, but users will stop getting updates if you don't.A possible path forward is to enable people to register aliases, i.e.
unic/langidis an alias forunic-langid.
created time in 5 days
issue commentManishearth/namespacing-rfc
My proposal is that foo/bar is always "feature bar of crate foo" (and it will provide a helpful error message when foo/bar exists but foo does not), and if you want to enable a namespaced crate, you use foo/bar/
comment created time in 5 days
issue openedManishearth/namespacing-rfc
Features can be specified as crate/feature, which makes foo/bar ambiguous with "feature bar of crate foo" and "optional crate `foo/bar".
We need a way to resolve ambiguity in the feature syntax
created time in 5 days
issue openedManishearth/namespacing-rfc
The current proposal allows for dash typosquatting
This proposal does not prevent anyone from taking
foo-barafter you publishfoo/bar. Given that the Rust crate import syntax forfoo/barisfoo_bar, same asfoo-bar, it's totally possible for a user to accidentally typefoo-barinCargo.tomlinstead offoo/bar, and pull in the wrong, squatted, crate.We currently prevent
foo-barandfoo_barfrom existing at the same time. We could do this here as well, but it would only go in one direction: iffoo/barexistsfoo-bar/foo_barcannot be published, but not vice versa. This limits the "damage" to cases where someone pre-squatsfoo-barbefore you publishfoo/bar, and the damage can be mitigated by checking to see if such a clashing crate exists when publishing, if you actually care about this attack vector. There are some tradeoffs there that we would have to explore.One thing that could mitigate
foo/barmapping to the potentially ambiguousfoo_baris using something likefoo::crate::baror~foo::barorfoo::/barin the import syntax.
created time in 5 days
issue commentManishearth/namespacing-rfc
I am personally a huge fan of mapping to _ because it does not require any additional changes to rustc and makes this a purely crates/cargo-side feature
comment created time in 5 days
issue openedManishearth/namespacing-rfc
The current RFC maps foo/bar to foo_bar in Rust code.
There are alternate mappings that can be selected
The proposal suggests mapping
foo/bartofoo_bar, but as mentioned in the typosquatting section, this has problems. There may be other mappings that work out better:
foo::bar(see section above)foo::crate::barfoo::/bar~foo::barand the like.
created time in 5 days
issue openedManishearth/namespacing-rfc
The current RFC lists slashes as the separator choice.
There are many other alternatives we could pick.
created time in 5 days
push eventManishearth/namespacing-rfc
commit sha b00c8cd2a816e3503e8f03db37d58ae0b29d25de
Fixes
push time in 5 days
created repositoryManishearth/namespacing-rfc
RFC for Packages as Optional Namespaces
created time in 5 days
created repositoryManishearth/-namespacing-rfc
RFC repo for Packages as Optional Namespaces
created time in 5 days
issue commentimmersive-web/webxr
OffscreenCanvas in a Worker support for webxr
There is no ETA, we're not prioritizing this
comment created time in 5 days
PR opened rust-lang/rust
It currently links to itself. Oops.
r? @jyn514
pr created time in 5 days
push eventManishearth/rust
commit sha 1c03f6dee571f63613432b00bbfe3d613929e672
Fix intra doc link for needs_drop
push time in 5 days
push eventrust-lang/rust-clippy
commit sha 4956157d126430b78a2f890134abc56e0dfb1f0d
Automatic deploy to GitHub Pages: de7e82ed11db1741e56580299e21b5e86b9e4d8c
push time in 6 days
pull request commentrust-lang/rust-clippy
Add a known problem for transmute_ptr_to_ref lint
@bors r+
comment created time in 6 days
push eventrust-fuzz/arbitrary
commit sha f275e1fac981d665acc9ef7a773c7237e7397386
Don't waste entropy when there is only one choice for `int_in_range_impl` Since all arbitrary choices / lengths / etc funnel into this method, fixing this here is enough to make all of them avoid unnecessarily wasting entropy when there is only one possible choice.
commit sha c583ffb307c8898aca7396d153e1dc605dfbc767
Merge pull request #59 from fitzgen/dont-waste-entropy Don't waste entropy when there is only one choice for `int_in_range_impl`
push time in 6 days
PR merged rust-fuzz/arbitrary
Since all arbitrary choices / lengths / etc funnel into this method, fixing this here is enough to make all of them avoid unnecessarily wasting entropy when there is only one possible choice.
pr closed time in 6 days
pull request commentManishearth/array-init
Thanks for all the help!
comment created time in 6 days
push eventManishearth/array-init
commit sha 973ae033cf1a66f36171a9144ea04bd291d2c2cc
Version 1.0.0
commit sha 9d05a598b8cddadf13151a884d479fde9928a1a9
Merge pull request #26 from krtab/1.0.0 Version 1.0.0
push time in 6 days
PR merged Manishearth/array-init
I think the current state is polished enough to release version 1.0.0!
If you merge this, could you release it on crates.io?
If you prefer, I can also do it (plus tagging github versions and whatnot) if you give me proper permissions.
Thanks for helping with my pull requests during these last days!
pr closed time in 6 days
pull request commentimmersive-web/webxr
Incorporating conclusions of recent privacy discussions
Rebased.
comment created time in 6 days
push eventimmersive-web/webxr
commit sha 527e1ef88ac43a776e8c659e423b06c9d49722d2
Switch over to use the newe (and more readable) bikeshed switch syntax
commit sha ef91f057c52d735aafdaee0f16d2f4446f653560
Merge pull request #1125 from immersive-web/new-switch Switch over to use the newer (and more readable) bikeshed switch syntax
commit sha 7c7fb82e18ccca0d50c524fb294ea1c9463a5120
Gate makeXRCompatible() on permissions policy
commit sha bc96697ebef48e931223e97ba5741cd35408cb47
Gate xrCompatible on permissions policy
commit sha 1383923807259763d4fbf42aafe0de8fa26d7726
Ensure that pending render state is always applied. (#1128) Ensure that pending render state is always applied, even if layer state is invalid.
commit sha effd87c555f8b73bcd930f5f73ac552dc3e89032
Make use of markdown syntax to clean up <code> tags
commit sha ea307ebecf94fd3735924c3b1571feefc052e1df
Merge pull request #1130 from immersive-web/markdownify Make use of markdown syntax to clean up <code> tags
commit sha 97e0becc2646d22a838da429775c9d2ded3053a0
Add requestViewportScale/recommendedViewportScale See https://github.com/immersive-web/webxr/issues/1091
commit sha bdd3223db8084bcd8507022a6927d377cf6b9a38
Clarify that framebuffer scale factors apply to width/height separately
commit sha cbaae48c1da5f1a836fdb0649ddaf3c82f666253
Address toji's review feedback Separately track "requested viewport scale" and "current viewport scale" so that changes after getViewport don't get ignored. Do an in-place viewport replacement instead of running the full "update the viewports" algorithm. Allow null arguments to requestViewportScale to avoid traps on systems that don't supply a recommended viewport scale. Rephrase notes to be (hopefully) clearer. Fix height/width cut&paste error.
commit sha 1c3a3de884df5cece52deb36465fcc20163bf442
Address manishearth's requests
commit sha 27ee847657a47c2bb5b3de9a7218e3041e4ad6a9
Fix view/XRView mixup
commit sha 634e8cfb8f3cfd30401f8351e2616849c84ab702
Change "void" back to "undefined"
commit sha 72c9858b782b2363fc49ed1a793a9005638d1d6a
Merge pull request #1131 from klausw/r-framebufferscale2 Clarify that framebuffer scale factors apply to width/height separately
commit sha 132fa32cdf5d54c9230b660d1f0bf6af6b0b2d6c
Merge pull request #1132 from klausw/r-viewportscale2 Add requestViewportScale/recommendedViewportScale
commit sha 8abdf7db615849333295ba4da1357d11203c0591
Clarify that minimum viewport scale may change The minimum viewport scale must ensure that the viewport has a nonzero size, and this may in theory require an adjustment if the session's baseLayer is changed during a session to use a very small framebufferScaleFactor. Change the wording to clarify that it's not necessarily constant for an entire session.
commit sha 919e516160285742b333fe9cfbd750d71d85c98c
Remove minimum viewport scale, update getViewport Add the nonzero viewport size and optional UA minimum viewport scale constraints to the getViewport algorithm instead.
commit sha bf79aa5c7a81bc5467b8497099a6c0255b856b85
add dynamic viewport scaling and baseLayer resize example
commit sha 24d2fa3587399274278c2aee1d1b3e5f1e35a8de
Merge pull request #1135 from klausw/r-viewportscale-explainer add dynamic viewport scaling and baseLayer resize example
commit sha ca0a933d0a9df657e67a135945a4123b850cb5fb
Merge pull request #1134 from klausw/r-viewportscale-3 Clarify that minimum viewport scale may change
push time in 6 days
pull request commentimmersive-web/webxr
Incorporating conclusions of recent privacy discussions
I understand the former concern about introducing the novel concept of user intent, but I think no spec so far has been required to exhaustively and normatively specify when the permissions it grants are allowed to be autogranted. If anything, we're going a step ahead and constraining the autogranting and providing examples.
comment created time in 6 days
pull request commentimmersive-web/webxr
Incorporating conclusions of recent privacy discussions
Like before, do you mean the bullets in #1124 (comment) to be the full set of options for an implementor? If yes, it would be good to have those be explicitly mentioned in the spec. If no, then we have the same issue as before, that there are not-specified paths through the spec. I think we've landed on "yes" but wanted to make sure
No.
We do not have the same problems as before: The consent situation is now modelled in terms of an existing web platform concept; permissions. Permissions already are allowed to be autogranted based on the user agent's discretion (the simplest example of this is caching permissions between pages when enabled, no spec explicitly talks about this). Our spec text is actually constraining autogranting to say that it must not be done in a way that hinders fingerprinting. We list some ways this can be achieved.
A standard, stock browser will mostly likely select one of the options I listed or ask for explicit consent. But we do not wish to hinder UX innovation here.
comment created time in 6 days
issue closedunicode-org/icu4x
Versioning of relative dependencies
Cargo.toml files have things like
icu-locale = { version = "0.0.1", path = "../" }
When developing, the path = "../" wins. However, when deploying, I guess the case is that version = "0.0.1" wins? If that's the case, we should add a lint that the versions are all in sync with each other so that we don't accidentally push crates to crates.io with out-of-date dependencies.
@zbraniecki @Manishearth @filmil @echeran
closed time in 7 days
sffc
issue commentunicode-org/icu4x
Versioning of relative dependencies
What zibi said, when it's lone version it fetches from crates.io. When you have multiple specs (git+version, path+version, it tries the other one if it can, and the version is treated as a constraint)
comment created time in 7 days
push eventManishearth/array-init
commit sha 7d66976aa5af634f6b66548913aba5d255f40eae
Added information entries to Cargo.toml
commit sha f2a873c1323254540775f350e5124a70c855686f
Merge pull request #24 from krtab/improve_cargo_toml Added information entries to Cargo.toml
push time in 7 days
issue commentrust-lang/rust
Move the doc directory to separate repo
Someone needs to build it and commit to running it.
comment created time in 7 days
pull request commentrust-lang/rust-clippy
Identical arguments on assert macro family
r? @ebroto since you've already started, feel free to bounce back the review if you're busy!
comment created time in 7 days
push eventManishearth/array-init
commit sha 8bd231ef2442601f24a445631a4d55ff013b9bc0
Remove disclaimer to move toward 1.0
commit sha 133aa0f288af064486081d3c68f44f59e8011478
Replace markdown links with badges
commit sha 810231c5cd8e778d70cebcbeded9c8898b3d9546
Precise that this crate doesn't leak memory on initializer failure.
commit sha 92d6e4bf6c9f7e718518a23fde134a1f355b63f1
Indent headers
commit sha 94d8393727ed02a548df7d628a139dfec76cfb8f
Merge pull request #23 from krtab/improve_readme Cosmetic fixes to the README aiming for 1.0
push time in 7 days
push eventManishearth/array-init
commit sha 247794e06b3462f569029cab5eb06e04b391a1b6
Fix copyright to "the array-init" developpers
commit sha 309b1f28c0e6a1c11c6e9c32fa83a05d86d0b264
Add date and authors to Apache copyright
commit sha 30fe757f1d569727e4399c7ada9fe65f667ffb3e
Extend date in MIT license
commit sha f62242479bccf28b8f7867f0e6cbeb822c4518e1
Copyright actually start 2017
commit sha 311f3b103cf1125827adbe0339b15760ff2ec0e7
Merge pull request #25 from krtab/fix_copyright Fix copyright notice in both licenses
push time in 7 days
issue commentw3c/font-text-cg
A highly configurable UCD processing utility for dumping the data into any subset and format
We typically have Python scripts like this one that ingest data files and spit out Rust code. Most of them are copied from each other and modified.
We also have ucd-generate, which is a generalized Rust crate for dealing with this. Some projects use that.
comment created time in 7 days
issue closedrust-lang/www.rust-lang.org
What needs to be fixed?
<!-- Tell us what content is causing the issue and how it is causing the issue. For example, "The code sample was confusing because it used advanced Rust features", or "The call to action on the community page was vague". --> in rust book, chapter11 we have, Filename: tests/common.rs:
#![allow(unused)]
fn main() {
pub fn setup() {
// setup code specific to your library's tests would go here
}
}
which when called inside Filename: tests/integration_test.rs throws error:
use adder;
mod common;
#[test]
fn it_adds_two() {
common::setup(); // error[E0425]: cannot find function setup in module common
assert_eq!(4, adder::add_two(2));
}
Page(s) Affected
rust book, chapter11 <!-- Please list the page or pages this bug is present on. Please file one issue for each bug you find. Only file an issue for a multi-page bug if the bug is indeed the same bug, across the pages. -->
Suggested Improvement
<!-- (optional) Do you have a suggestion for how to fix the problem? Include your ideas here. --> move outside of main?
closed time in 7 days
109149
issue commentrust-lang/www.rust-lang.org
The book repo is https://github.com/rust-lang/book
comment created time in 7 days
issue commentunicode-org/icu4x
* Cargo and Rust are going to introduce namespaces based on Manish proposal - https://internals.rust-lang.org/t/pre-rfc-packages-as-optional-namespaces/13059
This isn't for certain, fwiw, this is just my personal endeavor
comment created time in 7 days
pull request commentrust-dev-tools/rust-semverver
Pin nightly version to a latest one known to be working
Hmm, CI still fails, but r=me if you can get it to pass
comment created time in 8 days
push eventrust-lang/rust-clippy
commit sha a7c8c1ac365bd48f36e96e32079473cd15f2105f
Automatic deploy to GitHub Pages: 92783e39de26a114389c1e45a29ccbe75698dd2a
push time in 9 days
push eventrust-lang/www.rust-lang.org
commit sha 0b556f472fe7365e29e3f8c588358e542a685852
update firefox logo
commit sha 4ac80c23066bc1196a89de31105a3285af706adf
Merge pull request #1313 from Maxgy/master Update Firefox logo to fit new branding
push time in 9 days
PR merged rust-lang/www.rust-lang.org
The new image is 512x512 instead of 1024x1024, but this should be alright. I got the image straight from Mozilla Design.
EDIT: Fixes #1310
pr closed time in 9 days
issue closedrust-lang/www.rust-lang.org
What needs to be fixed?
Firefox logo on this page
Page(s) Affected
https://www.rust-lang.org/what/wasm
Suggested Improvement
Use newer Firefox logo
closed time in 9 days
Maxgy
pull request commentrust-lang/team
Please remove me, I must take a hiatus
You also need to be removed from the governance team file for this PR to be mergeable. If you'd like, you can move yourself to an "alumni" section (and keep valgrimm.toml around), this way you are still listed as an alumnus.
comment created time in 9 days
push eventManishearth/array-init
commit sha 74866d0eafcf62e083ff7827e07dbdfa886ad068
Cargo fmt
commit sha 887c72f1441e7b0106f3e0ec016cfaf45b53c4d4
Added documentation for try_array_init
commit sha a418b525f9774fbbad563d96da4bf00bfa1a701d
Fix typo 'unfallible' -> unfailible
commit sha 1735c0ad59ce9d248065e6190b6a95863f09b4ab
Reformulated array_init doc
commit sha cb422d219f7606845e9945aa98df99bc8ba7d81e
Remove extraneous whitespaces in try_array_init doc
commit sha 3568b1951f092d27a223f23f6b64ec7d2a124e7c
Use if then else as an expression. Makes the control-flow more explicit and should leverage more of the type-checker.
commit sha 6b56e473dc0801c0c9a256c252d557f59da28c9e
Remove comments linked to a previous implementation Fix: https://github.com/Manishearth/array-init/issues/19
commit sha 1fe42c7b3c7c09ecabcd58b45d813f4c9c60b566
Fix test assert message
commit sha fd49ed148d75015b3957a29cf85e68f3e2dcadc8
A bit more precisions in the doc
commit sha f58ead4ad3f1093658ad54ff8702f881b449ac79
Revert "Fix typo 'unfallible' -> unfailible" This reverts commit a418b525f9774fbbad563d96da4bf00bfa1a701d.
commit sha 26089f89635f04c5d32b2a0ba1267505ab21db94
Revert "Reformulated array_init doc" This reverts commit 1735c0ad59ce9d248065e6190b6a95863f09b4ab.
commit sha f0494abff8aa37b78b41d057a42f58189f01f2a5
Fix typo 'differentiate' -> 'differentiates'
commit sha 0815f4adfa8208d7232c8824273f4c7f781da1c5
Fix typo 'unfallible' -> 'infallible' Co-authored-by: Manish Goregaokar <[email protected]>
commit sha 584a14e0dafad2f6f78587e62e04b69349b71764
Merge pull request #20 from krtab/master Doc improvements, typo fixes
push time in 9 days
PR merged Manishearth/array-init
Hi !
This PR is a bit of a mess, if need be I can split it up in more atomic sub PR.
Anyway, it mainly consist of adding documentation, fixing some typos, and an unfortunate cargo fmt at the beginning which makes for a lot of the changes.
I think there are two commits that are a bit more important than others:
- https://github.com/Manishearth/array-init/commit/6b56e473dc0801c0c9a256c252d557f59da28c9e (fixes: #19)
- https://github.com/Manishearth/array-init/commit/1fe42c7b3c7c09ecabcd58b45d813f4c9c60b566
More broadly speaking, I'm interested in putting in some work to bring this crate to a more 1.0 state
pr closed time in 9 days
push eventManishearth/array-init
commit sha 4c5c0d5b1b832ff426065b3786d87714082c6847
Add dual licensing info
commit sha 36c10bb7bca9639ee81be0263010d2a1f5d6977e
Merge pull request #22 from Manishearth/Manishearth-patch-1 Add dual licensing info
push time in 9 days
PR merged Manishearth/array-init
Fixes https://github.com/Manishearth/array-init/issues/21
pr closed time in 9 days
issue closedManishearth/array-init
Hi !
This repo has both the Apache and MIT licenses, as most of the main rust repo, but is lacking a copyright notice indicating that any of the two can be chosen at the discretion of the user. Rust's main repo uses the following one: https://github.com/rust-lang/rust/blob/master/COPYRIGHT.
I am not a lawyer but I believe that without an explicit mention that the user is free to choose, the most restrictive license (which I guess is the Apache) applies.
I'm aware that Cargo.toml indicates an SPDX expression specifying the "OR" dual licensing, but I'm ensure this is "human language" enough to be considered enough.
Moreover, I believe that if we wanted to be extra cautious about the licensing of the code, we may need explicit approval from former contributors that their code is released under a dual license. Several projects include the following kind of mention in their readme which solves this issue and clarify dual-licensing:
Licensed under either of Apache License, Version 2.0 or MIT license at your option. Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in this crate by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.
This issue is similar to: https://github.com/rust-num/num-traits/issues/166
Best,
closed time in 9 days
krtab
PR opened Manishearth/array-init
Fixes https://github.com/Manishearth/array-init/issues/21
pr created time in 9 days
pull request commentimmersive-web/webxr
Incorporating conclusions of recent privacy discussions
Specifically, the capital "MAY" in the second path seems to suggest that this is a place where implementations may differ
This is. Implementations can choose to always resolve this promise to true, or they can choose to throw a permissions prompt. This is implementor choice, both options preserve privacy provided they always pick one or the other based on indistinguishable user agent.
I've changed it to explicitly call out that the user agent needs to have identical behavior here across all instances if it picks this option.
this isn't intended as an implementor decision point; a correct implementation will require one behavior or another in some situations.
It is, it is totally valid for an implementor to never autogrant the permission.
I've changed it to lowercase and mentioned "may be autogranted based on criteria below", since the intent of that text is mostly to just call out that there are criteria for autogranting.
I suggest keeping the MUST NOT section as is in the next, and moving the suggestions and guidance text into a note, to make it clear that its advice for ways of achieving the normative requirement, and not, in and of itself, a recommendation on behavior.
Done.
This is a style suggestion, and not part of my privacy review, so I'm not in anyway pushing on it, but I think it would be good to see if you can collapse "user intent", "implicit consent", "explicit consent" into fewer terms. Mostly, the spec defines a lot of local, unique terms that may collide with other specs, which may add additional confusion. Again, just a suggestion.
I'm afraid we can't, we use user intent more broadly for non fingerprinting user activation issues elsewhere. This was a bit of a struggle in this PR and is why moved away from better specifying user intent because it's used for other things in this spec and I didn't want to shut those cases out.
I think there is a lot of space for a privacy infra spec that defines reusable terms for things like this.
a correct implementation of the spec always requires achieving explicit consent whether or not the user has XR hardware installed?
No, this is incorrect. Alternate correct implementations can be:
- Unconditionally answering "yes" to the isSessionSupported() question regardless of hardware being installed, consolidating the permissions request into the one that occurs during
requestSession()(there is already a prompt there). This has some unfortunate UX implications: content will end up always showing an "enter XR" button even when it's not going to work, but there is no fingerprinting vector since clicking that button will always throw a permissions prompt (modulo cached permissions). - Rejecting the prompt with a randomized delay when the user does not have XR hardware installed, provided it's determined by the implementor that this actually privacy preserving
comment created time in 9 days
push eventimmersive-web/webxr
commit sha 1aa9af3c0c789871b193d8f2295ce630db47682f
Fix links and normative/non-normative split
commit sha b35d290ef106d2abcdafa00524934f53ff0a397e
MAY be autogranted -> may be autogranted
commit sha b0284f00eb4566acf13be9319402b5e5bbbe259a
clarify MAY in resolving to true
push time in 9 days
Pull request review commentManishearth/array-init
where enum Unreachable {} try_array_init(- // monomorphise into an unfailible version+ // monomorphise into an unfallible version
// monomorphise into an infallible version
No, you were correct in that "unfallible" is not a word, your fix was incorrect: it should be "infallible"
comment created time in 9 days
push eventrust-fuzz/arbitrary
commit sha e1918abdac0866467a7eb4d5b8487f0e4508a0d8
Update documentation suggesting version 0.2.0 The suggested line causes the error: the package `your_package` depends on `arbitrary`, with features: `derive` but `arbitrary` does not have these features.
commit sha f8a425aa2f3a5c157880231ff5f45b7dc733d87c
Merge pull request #58 from TheThirdOne/patch-1 Update documentation suggesting version 0.2.0 to 0.4
push time in 10 days
PR merged rust-fuzz/arbitrary
The suggested line causes the error:
the package your_package depends on arbitrary, with features: derive but arbitrary does not have these features.
Changing it to suggestion to 0.4 fixes the issue for my project and matches the README.
pr closed time in 10 days
Pull request review commentManishearth/array-init
pub unsafe trait IsArray { #[inline] /// Initialize an array given an initializer expression. ///-/// The initializer is given the index of the element. It is allowed-/// to mutate external state; we will always initialize the elements in order.+/// The initializer is given the index (between 0 and `Array:len() - 1` included) of the element. It is allowed
I don't think this commit is particularly helpful. "In order" should suffice, there is no need to explain the bounds
comment created time in 10 days
Pull request review commentManishearth/array-init
where Array: IsArray, F: FnMut(usize) -> Result<Array::Item, Err>, {+ // The implementation differentiate two cases:
// The implementation differentiates two cases:
comment created time in 10 days
Pull request review commentManishearth/array-init
where enum Unreachable {} try_array_init(- // monomorphise into an unfallible version+ // monomorphise into an unfailible version
the word should be infallible
comment created time in 10 days
PR closed immersive-web/webxr
change the length and change the border line
pr closed time in 10 days
pull request commentimmersive-web/webxr
This is the standard bikeshed CSS.
comment created time in 10 days
push eventrust-lang/rust-clippy
commit sha adf55af3f504a9e2850dfee46222362cc0bb0285
Automatic deploy to GitHub Pages: 8b70b84639a368eafbc278dbdd93a6286abf23b2
push time in 10 days
issue commentrust-lang/rust
Tracking issue for check_invalid_html_tags
Yes, it should be warn by default
comment created time in 11 days
issue commentunicode-org/icu4x
If Rust settled the dispute and decided to go for
-in crate names, I believe we would follow.
The community has largely decided on -, with _ being used more in older crates, but it's not 100% decided.
Here are the counts of - vs _:
[16:49:22] मanishearth@noether ~/sand/crates.io-index ^_^
$ find . -type f | sed "s/.*\///g" | tr -d -c "_" | wc -c
10901
[16:49:45] मanishearth@noether ~/sand/crates.io-index ^_^
$ find . -type f | sed "s/.*\///g" | tr -d -c "-" | wc -c
24828
Would you be able to provide any justification beyond
it looks betterthat counters theits consistent?
Yes, because - is more common than _ except for older crates and some holdouts, people typically try for - first, and when that doesn't work they try the other one.
Some namespacing proposals also involve specially blessing -, though they are unlikely to pass.
comment created time in 11 days
pull request commentimmersive-web/webxr
Incorporating conclusions of recent privacy discussions
@pes10k How do the latest changes look? User intent is no longer referenced, and we use a permission, specifying cases where it should be auto-granted.
comment created time in 11 days