The syntax was pioneered before the RFC process was in effect, so it
may not have an official grammar, but it looks something like:
expr := 'box' expr | 'box' '(' expr ')' expr
The first form is rewritten as `box(::std::owned::HEAP) expr` and
the second form (the more general) specifies
Feel free to open a bug on the
issue tracker (https://github.com/rust-lang/rfcs/issues) or even open
an RFC on it! Due to it being a language change, you should register
the issue in the RFC repo instead of the rust repo.
Oh my, I'm allowed to start an RFC? I don't feel confident in
Disclaimer: please take all of this with a huge grain of salt. This
feedback is meant with the humility of someone who surely doesn't
fully understand the language yet and hasn't invested enough time into
yet to be taken seriously. Much of what I say may have little bearing
on anything.
There's a cron job running which will trigger each build each night
after the nightlies have finished building, and the .travis.yml script
for these repos are all wired to nightlies rather than the PPA.
Could the source code for this cron job be published, with instructions on
how to get
We plan to implement any necessary infrastructure to ensure that the
crates
move out of the rust repository maintain the same level of quality they
currently have.
Will these crates’ documentation be available online?
At this time there are no plans for this, but we're certainly open to
Ok, I got the basic going with a temporary for of `libsemver` here:
- https://travis-ci.org/errordeveloper/rust-libsemver/builds/31217706
- https://github.com/errordeveloper/rust-libsemver
Awesome! I've created a new repo for you to make a PR against:
https://github.com/rust-lang/semver
Now that cargo is starting to become a larger part of the Rust ecosystem
it's time for some of the crates as part of the standard distribution to
move out of the main rust repository. This movement has been planned for
quite some time now, and it has only recently become possible with the
advent
There is not currently a method of doing so through the `std::io`
apis. While possible through the rustuv and native apis, I would
discourage manual use of those crates as they have experimental and
volatile APIs.
You may be interested in https://github.com/rust-lang/rust/pull/15643
which may add
This is a known performance bug in the green schedulers being tracked
at https://github.com/rust-lang/rust/issues/11730.
To see the difference, you can run with RUST_THREADS=1 when using the
green scheduler.
On Fri, Jul 11, 2014 at 1:39 PM, Chandru chandru...@gmail.com wrote:
I tried the
LD_LIBRARY_PATH is not known about by many
The install.sh script now recommends adding an entry to this variable
if it detects that this is necessary, so it's not *entirely* unknown.
This doesn't help, however, if it's considered a bad practice.
1) Link dependencies of rustc statically to it?
It is indeed! You'll need to ensure that
`/Users/ilya/Library/Local/Rust/current/lib` is in your
DYLD_LIBRARY_PATH environment variable for OSX.
On Wed, Jul 9, 2014 at 6:25 AM, Ilya Dmitrichenko
errordevelo...@gmail.com wrote:
Is the following error cause by this change?
% rustc -v
dyld:
Doc tests are compiled as if they were clients of a library, so you'll
have to write the test assuming the rest of the source was built with
`--crate-type lib` and then import it directly.
For example, you may have to do this:
```rust
main::under_test();
```
Doc test aren't really designed with
By default, each stack is allocated with a red zone at the end for
running code on stack overflow, calling C functions, etc. The current
size of the red zone is 20K.
Requested stack sizes are always at least 20K, but the 20K is not
currently added to the stack size. So for your test case when you
I am thinking that maybe one solution could be that the C code calls
an init function that calls native::start and provides a function pointer
that start calls back into C. That way the C main thread will have a rust
runtime in the background, I *think*?.
That is correct!
I hope this would
Binding by ref is subtly different that the function still owns the
argument. For example, this may go awry with ref:T
struct Foo;
impl Drop for Foo {
fn drop(mut self) { println!(dropping); }
}
fn foo(ref _param: Foo) {}
fn main() {
let f1: fn(ref:Foo) = foo;
let f2: fn(Foo) = foo;
Aaron Turon atu...@mozilla.com
Adolfo Ochagavía aochagavi...@gmail.com
Adrien Tétar adri-from...@hotmail.fr
Ahmed Charles ahmedchar...@gmail.com
Alan Andrade alan.andra...@gmail.com
Alan Williams mral...@gmail.com
Alex Crichton a...@alexcrichton.com
Alexandre Gagnon alxg...@gmail.com
Alexei Sholik
If you touch runtime services (such as those mentioned by Benjamin),
it is assume that a Rust Task [1] is available. In your case, you're
touching the unwinding service, but you have no set a catch-point for
the call to unwinding anywhere. This sounds like you're triggering a
failure without a
Hello Rustilians!
Bors has outdone himself once again in preparing an 0.11.0 release candidate
for us. I've done the usual smoke test, but if you'd also like to try them
out the links are all pasted below. Remember that this is not a signed
release yet, we've only got checksums for these files at
Nice job Valerii! This is all thanks to the awesome work you've been
doing wrangling compiler-rt and the standard libraries. I'm excited to
see what new applications Rust can serve on iOS!
On Mon, Jun 16, 2014 at 9:19 AM, Valerii Hiora valerii.hi...@gmail.com wrote:
Hi,
So finally Rust can
Rust tasks do not support being killed at arbitrary points. You'll
have to arrange ahead of time for a please die message to be sent a
long a channel, or a similar scheme for transmitting this information.
On Wed, Jun 4, 2014 at 9:33 AM, Aravinda VK hallimanearav...@gmail.com wrote:
Hi,
I am
Sorry for the brevity, I'm writing this from a phone and I haven't thought of
this issue very thoroughly.
You appear to dislike one of the most fundamental features of Rust, so
I would encourage you to think through ideas such as this before
hastily posting to the mailing list.
The current
The test runner captures stdout by default and prints it at the end of
the test run, but only if the test failed. This is intended to turn
down the noise of successful tests, especially the failing ones.
If you pass the --nocapture option to the test binary, it will disable
this behavior and
Rust doesn't support life-before-main, which is basically what this
ends up entailing. What you've done already is likely what you'll want
to keep doing, which is explicitly chaining control flow through the
startup process.
On Thu, May 15, 2014 at 1:11 PM, Noah Watkins jayh...@cs.ucsc.edu wrote:
There is no way to generically wake up or kill a task, it must be
arranged via some other means for the task to wake up. For TCP
connections, you can use the close_read() method or the
set_read_timeout() methods. In 0.10, this was not implemented (we
recommend you use master).
On Thu, May 15,
Waking up on timeout is hardly a good decision. Let's think about
thousands of connections, each waking up at a reasonable timeouts
(sometimes between 100 ms to 1 sec for my taste). The close_read is a
hack that doesn't work for many cases (listening sockets, pipes, SCTP
sockets, etc.)
I'm
The ~int type has since moved to Boxint, which will one day be a
library type with Deref implemented on it (currently it is implemented
by the compiler). Regardless, there's no need to implement the Deref
trait for the type today, the compiler already takes care of it.
For example, your code will
Oddly enough, that was the first thing I jumped to as well! I think
that type inference like that doesn't drive method selection, which is
why it ended up not working out.
On Wed, Apr 30, 2014 at 3:54 AM, Michael Neumann mneum...@ntecs.de wrote:
Am 29.04.2014 22:51, schrieb Alex Crichton
In an rlib, all publicly reachable symbols will be exported from the
object, for example:
mod foo { pub static BAR: int = 3; }
That symbol is not exported because BAR is not reachable from the outside world.
pub use foo::BAR;
mod foo { pub static BAR: int = 3; }
This time, BAR
in a dedicated object file and
pass it to linker, as those depend on libzinc which isn't reaching the
linker explicitly.
On Wed, Apr 30, 2014 at 5:17 PM, Alex Crichton a...@crichton.co wrote:
In an rlib, all publicly reachable symbols will be exported from the
object, for example:
mod
The by_ref() method exists on both the Reader and the Writer trait,
and you're working with a stream which implements both Reader and
Writer (hence the confusion by the compiler).
You could work around it with something like:
fn rdr'a, T: Reader(t: 'a mut T) - RefReader'a, T {
This used to be present for the JIT support that the old rusti
provided, but the internal support for this has been removed. You may
be able to resurrect it outside the compiler with these LLVM apis, but
it may also require exposing more LLVM details from the compiler
itself.
There is currently
I can do with that.
On Mon, Apr 21, 2014 at 5:23 PM, Alex Crichton a...@crichton.co wrote:
The split stack patches for ARM were recently upstreamed, and they
were modified when being upstreamed as well. Primarily the location of
the split stack is no longer at a magic address for thumb
How do I manually implement clone() for Structs/Enums with lifetime
parameters (e.g. for struct below)?
---
struct Cls'a,T {
x:'a T
}
impl'a, T: Clone Clone for Cls'a, T {
fn clone(self) - Cls'a, T {
Cls { x: self.x }
}
The split stack patches for ARM were recently upstreamed, and they
were modified when being upstreamed as well. Primarily the location of
the split stack is no longer at a magic address for thumb, but rather
it uses the same instruction as ARM (some thumb processors do indeed
have the
Refcounting is, of course, unsuitable for objects with circular links and I’m
going to have plenty of them.
You may be interested in the downgrade() method on Rc/Arc along with
the Weak pointers (they allow cycles, but also allow for destruction).
So I’m thinking about adding per-task arenas
Welcome Aaron! I'm so excited to have you with us!
On Mon, Apr 21, 2014 at 2:06 PM, Brian Anderson bander...@mozilla.com wrote:
Hey there, Rusticators,
Grand news! Starting today Aaron Turon is joining the Rust team. Aaron did
his PhD thesis on concurrency at Northeastern University, where he
The ~Any type has a special implementation of Show:
https://github.com/mozilla/rust/blob/master/src/libstd/any.rs#L151-L155
I believe it was primarily used in failure messages originally (you
can fail a task with ~Any)
On Thu, Apr 17, 2014 at 8:55 AM, Edward Wang edward.yu.w...@gmail.com wrote:
Greetings Rustlers!
Projects such as cargo and Servo have recently expressed interest in having a
breaking changes changelog as part of the rust repository. It's often
difficult for those not closely tied to the compiler itself to keep up with all
the changes that are getting made. Additionally,
Your BaseImpl enum isn't necessarily Send because it contains a trait
object (~Base). The typechecker doesn't know what type is behind this
trait object, so it doesn't know whether it's send or not. To make the
BaseImpl type Send again, you can change the definition to:
enum BaseImpl {
As you've discovered in bug #13325, dealing with external constants in
static expressions is sometimes a little tricky. I would avoid casting
for now (as happens in the bug) in favor of stronger types. For
example, this compiles and runs for me:
extern {
fn foo();
fn bar();
.
* search works across crates that have been rendered to the same output
directory.
Contributors to Rust 0.10
Adrien Tétar adri-from...@hotmail.fr
Alan Andrade alan.andra...@gmail.com
Alex Crichton a...@alexcrichton.com
Alex Whitney aw1...@ic.ac.uk
a_m0d damien.sch
I've noticed recently that there seems to be a bit of confusion about the fate
of ~[T] with an impending implementation of DST on the horizon. This has been
accompanied with a number of pull requests to completely remove many uses of
~[T] throughout the standard distribution. I'd like to take some
Greeting Rustlers!
Our lovely automation has recently prepared an 0.10 release candidate recently.
I've tested them slightly, and if you'd like to also give them a shot all the
links are included at the end of this message. Remember that this is not a
signed release yet, we've only got checksums
23, 2014 at 5:17 PM, Alex Crichton a...@crichton.co
wrote:
You should be able to assemble standalone objects for any triple
through rustc itself, you'll likely have to specify a different
linker
or assembler though:
rustc foo.rs --target arm-non-linux-gnueabi \
-C linker
I would recommend using io::process with the detach option set to true
rather than invoking fork(). The green runtime is not fork-safe, and
at this time we're not guaranteeing that the native runtime is
fork-safe.
On Mon, Mar 17, 2014 at 4:59 AM, John Mija jon...@proinbox.com wrote:
Is possible
Can someone explain why this is necessary?
static FOO: OptionCellint = None;
let foo = FOO;
Implementation-wise, FOO is placed into read-only memory in the
executable. This is done mainly for optimization purposes for LLVM.
Something like
static NUM_BITS: uint = 32;
should act
I was working from the assumption that the initializers of non-mut statics
are checked to ensure they do not contain values of non-Freeze types, nor
destructors. Does the new plan also involve lifting this restriction? (From
the below it seems like it does.)
Yes, by disallowing taking the
Right now #[link] only takes library names (it gets passed through as
a -l flag).
It doesn't seem much more brittle to use -C link-args than to have
absolute paths, so you may wish to explore that route.
On Wed, Mar 5, 2014 at 1:12 AM, Doug douglas.lin...@gmail.com wrote:
Hey~
I've been
You can use the prototype through `std::comm::Select` for now, but the
macro is not currently exported. See
https://github.com/mozilla/rust/issues/12044 for more information.
On Mon, Feb 24, 2014 at 10:59 PM, Frank Huang fyhu...@gmail.com wrote:
Hi everyone,
Here with a novice question. I'm
This feature was removed from the language in
https://github.com/mozilla/rust/pull/12244. The as_slice() method will
continue to work for now.
On Thu, Feb 20, 2014 at 4:53 PM, Michael Dagitses mich...@dagits.es wrote:
The following no longer works:
let file = match std::os::args() {
[_prog,
Currently, all patches are being tested after they are approved. However, I
think it would be of great benefit for contributors - and reviewers - to
test patches before and after they're approved.
I would personally love to explore using Travis-CI for this. I think
this is almost exactly what
-11 branch as the base for my PR?
Svetoslav.
-Original Message-
From: alexc...@gmail.com [mailto:alexc...@gmail.com] On Behalf Of Alex
Crichton
Sent: Sunday, February 16, 2014 1:16 AM
To: Svetoslav Neykov
Cc: rust-dev@mozilla.org
Subject: Re: [rust-dev] [PATCH] Add stack overflow
For LLVM patches, we prefer if you have first attempted to upstream
the patch with LLVM before we push it to our local fork. This normally
entails emailing the llvm-commits mailing list. Once this upstream
attempt has been made, you can open a PR against the rust-lang/llvm
repo on github.
This
Are you targeting a platform other than x86? I recently added support
for 64-bit atomics on all platforms, and without the right cpu or
target feature set LLVM will lower them to intrinsic calls, and it's
possible that you're missing an intrinsic somewhere.
On Fri, Feb 14, 2014 at 9:48 AM, Ian
...@gmail.com wrote:
Targetting ARM hard float, v7 CPU.
Any ideas how to go about addressing this?
--
From My Tiny Glowing Screen
On Fri, Feb 14, 2014 at 10:20 AM, Alex Crichton a...@crichton.co wrote:
Are you targeting a platform other than x86? I recently added support
for 64-bit atomics
What version of the compiler are you using? The clone-able Chan only
very recently landed, so you'll need a very up-to-date compiler to get
the change.
On Thu, Feb 13, 2014 at 6:12 AM, Liigo Zhuang com.li...@gmail.com wrote:
Hi Rusties,
When try to compile tmp.rs, I got the error:
```
For reference, this topic was discussed last August as well:
https://mail.mozilla.org/pipermail/rust-dev/2013-August/005113.html
On Thu, Feb 13, 2014 at 10:05 AM, Simon Sapin simon.sa...@exyr.org wrote:
Hi,
The Rust documentation currently makes iterators behavior undefined after
.next() has
Can you supply the output of `rustc -v`? The snippet complies ok for
me off master.
On Thu, Feb 13, 2014 at 8:17 AM, Liigo Zhuang com.li...@gmail.com wrote:
I compiled the lasted rustc from source yesterday.
2014年2月13日 下午8:17于 Alex Crichton a...@crichton.co写道：
What version of the compiler
) it automatically triggers a flush on stdout and stderr to
avoid this uncomfortable situation.
I suppose it would not be took difficult to incorporate this in Rust.
-- Matthieu.
On Sun, Feb 9, 2014 at 2:40 AM, Patrick Walton pcwal...@mozilla.com
wrote:
On 2/8/14 3:35 PM, Alex Crichton
We do indeed want to make common tasks like this fairly lightweight,
but we also strive to require that the program handle possible error
cases. Currently, the code you have shows well what one would expect
when reading a line of input. On today's master, you might be able to
shorten it slightly
Some of you may have already seen GitHub's new State of the Octoverse
2013 at http://octoverse.github.com/
I'd just like to point out that the rust repository closed the second
most number of issues (6408) on all of GitHub. Just to reiterate, out
of the millions of repositories on GitHub, we
Greetings Rustaceans!
Upon updating your nightly builds tonight some of you may realize that
all I/O code will fail to compile. Fear not, this simply means that
#11946 has landed! The summary of this change is the same as its
title, remove io::io_error. This is quite a far-reaching change,
By returning a Result from all function calls, it's not much cleaner
to handle errors
Oops, wrong word there, I meant to indicate that it *is* much cleaner
to handle errors with Result rather than conditions.
___
Rust-dev mailing list
Welcome Nick!
I can't wait to see that 1.0 issue count go down!
On Mon, Feb 3, 2014 at 6:20 PM, Brian Anderson bander...@mozilla.com wrote:
Hi Rusties,
I'm just thrilled to announce today that Nick Cameron (nrc) has joined
Mozilla's Rust team full-time. Nick has a PhD in programming language
Our discussion in a recent meeting concluded that statics will not be
allowed to contain types with destructors, and you also won't be able
to move out of static items:
https://github.com/mozilla/rust/issues/10577#issuecomment-32294407
On Tue, Jan 28, 2014 at 3:34 PM, Kevin Ballard ke...@sb.org
Rust has the idea of implicit copyability, a property of a type
formalized by the Pod trait. An implicitly copyable type is either a
primitive, or a structure/enum which is built from implicitly copyable
types (plus some extra rules in play here).
When you add a destructor (implementation of the
What's the reason ~T not coerced to T the same way as in the main()
function and borrow3 -- ie. why isn't it automatically converted to **v as
it is in these cases? The conversion is identical, no? The inability in
this particular context seems rather arbitrary.
Sadly this is correct. Right
Any way to prevent this, so that only I am allowed to create FieldDef
structs but can still return references to them in my public API?
You'll want something like:
pub struct FieldDef {
priv field: int,
}
That way everyone can name your struct, but no one other than you can
construct it
fn borrow1'a('a self) - 'a int {
match (self) {
// error: mismatched types: expected `'a int` but found `~int`
// (expected -ptr but found ~-ptr)
Foo(ref v) = *v
}
}
This doesn't work because the local variable v has type ~int,
This is the part that I don't follow; why can't I just mark
my mutable-only methods as taking a mutable self?
The problem with this is that it requires that the *owner* of a type
have a *mutable slot*, and you cannot prevent owners from declaring
their slots as mutable. In the example you gave,
The problem with this is that it requires that the *owner* of a type
have a *mutable slot*, and you cannot prevent owners from declaring
their slots as mutable. In the example you gave, you could write let
mut var2 = Box { x: 2 } and it would compile, there's nothing
preventing usage of the
1. I miss a search functionality on the mailing list. Am i just blind, or do
i have to
use google with the site: option?
The mailing list we use is pretty standard, and it's
archived/searchable on other mirrors (gmane I think mirrors our
mailing list)
2. I'm used to curly braces, but every
. After years of iteration I'm
hopeful that we're finally converging on a good design for the runtime.
On 12/28/2013 10:37 AM, Alex Crichton wrote:
Greetings rusticians!
Recently pull request #10965 landed, so the rust standard library no
longer has
any scheduling baked
Greetings rusticians!
Recently pull request #10965 landed, so the rust standard library no longer has
any scheduling baked into it, but rather it's refactored out into two libraries.
This means that if you want a 1:1 program, you can jettison all M:N support with
just a few `extern mod`
1. Is doing part (b) necessary? That is, does LLVM's optimization
already eliminate unused code?
I don't believe that it is from a final binary point of view.
Unreachable functions will be flagged as internal, and LLVM can do
whatever it wants with internal symbols. I would imagine that it
Hello rust-dev!
Everyone's had their fair share of issues with autoref and autoderef,
and it's worth considering removing certain portions of it from the
compiler. The discussion around this has been rooted in the past, but
has recently been brought up as part of
Additionally, we discussed this today at our weekly meeting, and the
minutes can be found here:
https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-11-19#autoderef
___
Rust-dev mailing list
Rust-dev@mozilla.org
Rust’s old fmt! syntax also used % instead of {}. The reason for the switch was
to primarily support compatibility with an internationalization-style scheme of
string formatting. The main benefit of {} of % is that you can nest {} inside
of another format, whereas with % you’re limited to just
* #[link(...)] becomes the new method of specifying linkage semantics on
extern
blocks, and it may be used similarly to link_args today
I'd kind of like for this to be available at the crate level too since most
libraries don't use OS X two-level namespaces and it's more convient to me
I've been thinking about static linking recently, along with a little bit of
linking in general, and I wanted to see what others thought.
# The Goal
Primarily, I believe that if desired, rustc should be able to generate an
executable or dynamic library with no dependence on any rust libraries.
Primarily, I believe that if desired, rustc should be able to generate an
executable or dynamic library with no dependence on any rust libraries. This
includes things like librustrt and libextra. Rust shouldn't be striving to
lift
dependence on system libraries, that'll come at later times
Hm, I suppose I should re-phrase. Rust's linkage model should not
attempt to lift dependence on global native libraries. These global
libraries (like libm and librt on linux) should be assumed to be
everywhere. Our result artifacts must always be linked against them
(if their functionality is
To this end, I mainly
point out that rust should roll in local native static libraries, and
just live with global native dynamic libraries.
How does rustc know the difference? Because the local native libraries
are tagged as #[link(once)]? (nit: maybe link(static) would be clearer?)
You're
, 2013 at 12:09 AM, Alex Crichton a...@crichton.co wrote:
I've been thinking about static linking recently, along with a little bit
of
linking in general, and I wanted to see what others thought.
# The Goal
Primarily, I believe that if desired, rustc should be able to generate an
executable
It looks like you're compiling a fairly old version of the compiler, I
would recommend that you update to the master branch instead of using
older copies (we're a fast-moving target right now!)
On Thu, Nov 14, 2013 at 9:57 AM, tessy joseph tessyjoseph1...@gmail.com wrote:
Hi
I was trying to
The situation may not be as dire as you think. The runtime is still in a state
of flux, and don't forget that in one summer the entire runtime was rewritten in
rust and was entirely redesigned. I personally still think that M:N is a viable
model for various applications, and it seems especially
You're correct about the safeness of catching failure at a task
boundary. Rust's invariants about spawning a task involve knowing a
fair bit about what's allowable to share between a task boundary, and
that allows us to reason about the failure unwinding to the task
boundary being a safe operation
You should be careful to declare modules only once. It looks like you
have two instances of mod actions in the module hierarchy, and both
modules will be compiled as separate entities (although everything
will have the same name).
If you remove the `mod actions` inside of testaction.rs you should
in C.
Philippe Delrieu
Le 08/11/2013 09:53, Alex Crichton a écrit :
You should be careful to declare modules only once. It looks like you
have two instances of mod actions in the module hierarchy, and both
modules will be compiled as separate entities (although everything
will have
I just want to know what the state of affairs is.
The current state of affairs in terms of visibility and privacy in the
languages is defined and implemented with possible bugs. What's
documented in the manual/tutorial is what is intended and currently
implemented in the compiler, and if there
Out of curiosity, why not make File::open() return a Result instead of
Option like it does now?
This is a relic of I/O using conditions. The idea here is that if you
wanted to catch the condition, you can indeed catch it (and do
something appropriate). If you don't catch it then the task fails
This api is a little in flux (hopefully #10179 will land soon), but
I'm not quite sure what you mean about keeping the file descriptor
open. If there was an error opening the file, then a file descriptor
was never allocated and there's nothing to keep open. Regardless, once
my pull request lands,
# Renaming `unwrap` to `get`
I would personally find this change a little odd because we still have
a large number of `unwrap` methods thorughout the codebase. Most of
these do indeed imply destruction of the enclosing type. A change like
this would mean that when you decide to write your
Right now the file I/O isn't quite what I think we want it to be in
the end, but otherwise that is roughly the code which you'll want to
write. It could be slightly shortened like this:
use std::rt::io::Writer;
use std::rt::io::file::FileInfo;
use std::rt::io;
let mut stream =
Are macros possible in traits?
Right now the grammar does not allow for this, and it may be difficult
to do so (I don't think that we're going to change that in the near
future)
Object coercion would be great, is that a planned feature?
I believe so. I thought there was a bug open already,
It's great to see progress in this area! I know that this has been a
tricky topic in the past, and it would be awesome to get things sorted
out.
One thing I would keep in mind is that pretty much any strategy
(except the no safety one) involves changes in LLVM. I think we all
hope to one day use
I forget what the memory usage was when 0.8 was cut, but around that
time the compiler peaked at about 2.2 GB of memory. At this time, it
would then fork to invoke the linker, which is the most common cause
of the out of memory issues we've been seeing. For things like VMs,
I've seen 4GB work
There have been some recent grumblings [1] about the use of conditions in the
new runtime's I/O system. It was decided awhile back [2] that we'd try out the
use of conditions for error handling in the new runtime. This has manifested
itself in the `io_error` and `read_error` conditions inside of
As I think was mentioned on IRC, sadly there wasn't a set of well
defined privacy rules in place beforehand. What I've been able to
gather is that they were a rough approximation of what was desired at
one point in time, but more pressing matters led to them never really
getting refined to where
I think this is a fantastic idea. We may even want to entertain the
idea of moving the mentioned URL on an ICE to this page instead. It
looks like github also throws up a banner about guidelines for
contributing which point to CONTRIBUTING.md, so perhaps it should
also be included in that file so
1 - 100 of 117 matches
Mail list logo
