Hi,
I have a 3GB Linux x64 machine that I've done occasional rust builds
on and I found it failing tonight:
task unnamed failed at 'failure in fork: Cannot allocate memory',
/home/rustbuild/src/rust-buildbot/slave/snap3-linux/build/src/libstd/run.rs:672
Is this to be expected?
To be fair, I
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
Does Rust ever sleep?
This is a rhetorical question, conceivably related to the Neil Young
album, or to the possibility of a project motto, or maybe about
whether the Rust runtime really runs programs in parallel, with
as many true OS-level threads as cores.
Nathan Myers
n...@cantrip.org
Kind of sad nobody else seemed interested in this. I unfortunately
don't know enough about rust internals to make any sensible
contribution to a LLVM track, but I plan on going to FOSDEM this year
so if anyone else is going I'd be happy to say hi!
Cheers
On Wed, Oct 9, 2013 at 2:20 PM, Sylvestre
The new Path API still has a return a new path set of APIs. They're just
named differently. For example, the old path.push(foo) is now
path.join(foo). And all the path.set_*() mutating methods have variants
path.with_*() that return a new path.
-Kevin
On Oct 18, 2013, at 9:09 AM, Jack Moffitt
What about using Result types as mentioned here, but introducing some
syntactic sugar to make chaining them easier? Something like Haskell's or
Scala's do syntax:
do (
a - x // x and y are Results
b - y
) { /* do stuff with 'a' and 'b' */ }
else {
/* First Err is returned. Handle here. */
}
I came across this blog post which may be relevant:
https://coderwall.com/p/kokm7w
--
Ziad
On Fri, Oct 18, 2013 at 10:23 AM, Ziad Hatahet hata...@gmail.com wrote:
What about using Result types as mentioned here, but introducing some
syntactic sugar to make chaining them easier? Something
On Fri, Oct 18, 2013 at 12:09 PM, Jack Moffitt j...@metajack.im wrote:
In the latest Rust upgrade for Servo, I noticed that the path API is
now mutate-in-place instead of return a new path. It used to be that
path.push(foo) gave you a new path with an extra component, but now
path.push(foo)
On Oct 18, 2013, at 11:14 AM, Daniel Micay danielmi...@gmail.com wrote:
On Fri, Oct 18, 2013 at 12:09 PM, Jack Moffitt j...@metajack.im wrote:
In the latest Rust upgrade for Servo, I noticed that the path API is
now mutate-in-place instead of return a new path. It used to be that
* Patrick Walton:
In other words: Why bet, as Go did, that the failure case won't
happen much in practice when we can adopt an error-handling strategy
that rules it out entirely?
Uh-oh, I thought that Rust has ruled out error handling constructs
based on implicit control flow? :-)
But
* Igor Bukanov:
So the Go style is to call a function, check if the was an error,
update the error object (or create a new wrapping the old one) with
extra information relevant to the current call stack frame and
propagate the updated error object to the caller.
It's more common to simply
On 10/18/2013 11:14 AM, Daniel Micay wrote:
On Fri, Oct 18, 2013 at 12:09 PM, Jack Moffitt j...@metajack.im
mailto:j...@metajack.im wrote:
In the latest Rust upgrade for Servo, I noticed that the path API is
now mutate-in-place instead of return a new path. It used to be that
On Fri, Oct 18, 2013 at 6:09 PM, Jack Moffitt j...@metajack.im wrote:
If we decide that both API styles are good to have, what should the
naming convention be for the functional vs. mutable ones? Ruby,
Scheme, and Clojure use `!` to denote the in-place mutation ones, but
that syntax is for
To be clear, '!' doesn't mean mutation, it means 'dangerous.' For example,
some methods return nil on error, and the bang version throws an excption
on error.
Sometimes, mutation is dangerous, though... ;)
___
Rust-dev mailing list
Rust-dev@mozilla.org
Hello!
While reading the Rust tutorial I'm really excited to see a new programming
language that can replace C/C++ for performance-critical programming. C/C++
is very entrenched but extremely tricky and getting more complicated with
each revision. The world needs a replacement that's not so
On 19/10/13 10:37, Jerry Morrison wrote:
* Use postfix syntax for pointer dereference, like in Pascal:
(~rect).area() becomes rect~.area() . That reads left-to-right
with nary a precedence mistake.
While Rust’s auto-dereference feature and type checker will
sometimes catch
* Use postfix syntax for pointer dereference, like in Pascal:
(~rect).area() becomes rect~.area() . That reads left-to-right
with nary a precedence mistake.
While Rust?s auto-dereference feature and type checker will
sometimes catch that mistake, it's better to just
Hi,
I recently added rust-http, rust-mustache and rust-sqlite to AUR for
Arch Linux users. These should make some web development related stuff
easier. I'll add more packages soon.
Links to github pages of the packages:
rust-http : https://github.com/chris-morgan/rust-http
rust-mustache :
On Fri, Oct 18, 2013 at 6:13 PM, Daniel Micay danielmi...@gmail.com wrote:
On Fri, Oct 18, 2013 at 7:37 PM, Jerry Morrison jhm...@gmail.com wrote:
(1) Rust has great potential for *real-time programming* as well as
secure programming. Perhaps this just needs a library call to fork
real-time
19 matches
Mail list logo
