The explorer interpreter is still there, but it's non-default so it's a
little hard to link to (we could do a shortlink like
https://carbon.compiler-explorer.com/z/8P1WE97nn if you want to keep
that). As is, I assume it's okay to just state that this is now the
toolchain.
We propose updating our milestones to accelerate design and
implementation of
memory safety in Carbon, and a roadmap for 2025 reflecting this change.
We also
provide a retrospective for 2024's progress.
---------
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
* Change format:
* previously there was a single link per talk, the video if available
* now there are separate "video" and "slide" links
* Adds link to video for 2024 CppNorth talk
* Adds link to slides for 2024 LLVM Developers' Meeting
* Restores links to slides from past years
---------
Co-authored-by: Josh L <josh11b@users.noreply.github.com>
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
This provides an example of downloading and using the nightly buildings
of the toolchain. I've tried to provide appropriate caveats about the
fact that this is very early and not something that's really reliable.
But I wanted folks to know how they can play with the nightly releases
if they're interested.
I've also focused the source build instructions on the toolchain where
we'd be interested in contributions, and the first paragraph on trying
out Carbon in the browser with CE.
---------
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
I was considering making a "/bazel" alias for this, but I'm really on
the fence about whether that's a good choice. However, I do think this
is good to have to simplify installs.
Fixes#3071 and #3896
Also makes an alias so that this is easier to find. Verified that
running the alias still finds prelude files.
Note the actual target is printed when building (although a symlink is
also created, using that symlink confuses file-finding).
```
╚╡bazel build :carbon
...
Target //toolchain/install:prefix_root/bin/carbon up-to-date:
bazel-bin/toolchain/install/prefix_root/bin/carbon
```
Also reorder links so that the future/most recent items are first,
putting older videos lower down.
Noting the lightning talk because it's there, but also that it's a
lightning talk because most of the others are 40m/1h, so 5m is very
short by comparison (I was tempted to label the length of everything,
but not sure how valuable others view that).
Update broken links to aid in following links while perusing the
documentation. Closes#3778
I don't imagine I got every one of these right. Some 404s may be
reported due to permissions.
Using the lychee command in #3778, only the following link is reported
as not found, but it's just a permission issue:
```
[proposals/p1367.md]:
✗ [404] https://github.com/carbon-language/carbon-lang/settings/access | Failed: Network error: Not Found
```
I tried to get it down to as few as possible, partially so that future
link scans won't run into repeat errors.
---------
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Co-authored-by: Carbon Infra Bot <carbon-external-infra@google.com>
We had some amazing GSoC participants last year, but because Carbon is
still pretty small, we ended up stetched a bit too much to be
sustainable. And this year, we're trying to have an even narrower focus
on the toolchain.
Between these aspects, we sadly don't have the bandwidth to run an
effective GSoC project this year. We think it's really important that we
can give mentees an excellent experience on the project, and don't want
to overcommit ourselves, or worse, let them down.
We're really hopeful to be back when the project is a bit larger though,
and we have good bandwidth to host folks.
We propose a roadmap for 2024 focused on a working Carbon toolchain that
supports Carbon ↔ C++ interop.
---------
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Proposal to focus implementation effort for the next 1-2 years on the
Carbon
toolchain instead of the explorer. This will impact the explorer in a
few ways:
- We will keep the explorer's code in place, building, and passing its
basic
tests. It can remain a good baseline for exploring Carbon's language
features.
- We won't prioritize expanding the explorer's coverage of Carbon
features or
other improvements -- it is good enough for what we need until the
toolchain
catches up.
- We will stop actively fuzzing and expanding test coverage for the
explorer.
- Eventually, when we want to resume work on the explorer, we'll
evaluate the
best platform to build on -- the current explorer codebase or on top of
the
toolchain's semantic IR.
Also tries to update the core readme and contributing docs to reflect
this.
The successor strategy talk isn't up yet, but will be on Sep 8 -- just
trying to get them all in one pass.
Slides were previously linked, which I could keep, although it's weird
to have a long link with just `(Slides)` at the end because it implies
the whole linked text is slides (rather than a video). So if that's
desired, I might switch instead to something like:
```
- Talk name, con ([video](youtube link), [slides](slides link))
```
But, this current format (video-only full-name link) felt consistent
with the 2022 links.
This PR resolves the spelling error in the "Contributing" section of the
README. The sentence "Contribute the language design: feedback on
design, new design proposal" has been corrected to "Contribute to the
language design: feedback on design, new design proposal". This change
enhances the clarity and accuracy of the contribution guidelines.
Closes#3068
Co-authored-by: aroramrinaal <aroramrinaal@gmail.com>
These instructions have fallen out of sync with the note that we've stopped recommending brew for linux (due to build issues). Rather than having instructions that only work for MacOS, take the bare minimum and just point at contribution_tools.md.
chandlerc, I believe you'd specifically requested the instructions here as part of #1390. An alternative approach would be to remove this entirely, and just say "See our contribution tools page for instructions on how to build locally."
i-khadra's change #2636 is what made me notice this issue. They're trying to add Windows notes to the README, but this change reflects my leaning it's better to let contribution_tools.md explain setup.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Suggesting to add a section with past conference talks, to include content that has been created around carbon. This feel to me like an accessible type of content to have in the main README for those wanting to dig a bit deeper without going into /docs.
This does not show the speaker name to keep it "Carbon/community" oriented, vs naming, but there's an argument both ways I think.
Our "Getting Started" section doesn't mention the Compiler Explorer as a first step. Compiler Explorer already has the Carbon explorer installed, so it would save interested folks a lot of time if they just want to try code out before installing a lot of tools to build from scratch.
This is a repeat link of the status section, but given the title of this section ("Getting Started") it's quite possible visitors end up here before they read the status section.
Part of #1902Fixes#1904
Regarding #1904, using #access-requests because I've decided I feel weird using any other channel for this (including #proposal-prs-and-process)
Summary of resolved issues/ changes:
1. 'our' typed twice under **Join us** heading in README.md --> 'our ' is no longer repeated, typo fixed
2. verb form and comma related errors under **Memory Safety** heading in README.md --> grammar fixed
3. missing article and hyphen related errors under **Generics** heading in README.md --> grammar fixed
4. punctuation and preposition related errors under **Why build Carbon?** heading in README.md --> grammar fixed
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Tiny nit: Line 63 similarly links "modern generics system". Line 250 links 'generics', but doesn't include "modern ... system." So I think this approach is consistent (and subtly, implies the link is about the modern ... system, not just "generics").
Some review feedback from outside the team directly working on Carbon suggested
two pretty significant updates here. First, we didn't do a good job of
motivating Carbon. This takes two parts, first explaining what we'd like to
accomplish with this approach generally, and second explaining why alternative
approaches don't work. A particularly difficult case here is articulating
effectively the difficulties that motivate an approach other than improving C++
incrementally.
Co-authored-by: Jon Meow <jperkins@google.com>
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Jon Ross-Perkins
Chandler CarruthandRichard Smith
Dana Jansens
Mrinaal Aroraandaroramrinaal
Adrien Leravat
micttyl
Wolff Dobson
purpl3r0se
Roland Siegbert
Saurabh MudgalandJon Ross-Perkins
yogesh kartik
Josh Soref
Dan Sarginson
