Luckily enough, I had the concept for zinc even before I started coding in
rust :-) And yes, there are lots of different oxides in rust world.
On Wed, Apr 23, 2014 at 3:58 AM, Thad Guidry thadgui...@gmail.com wrote:
Actually...I do not. :)
On Tue, Apr 22, 2014 at 9:05 PM, Chris Morgan
Vladimir Pouzanov farcal...@gmail.com writes:
This is the project I've been tinkering with for a good number of
weekends zinc, the bare metal stack for rust is available at
https://github.com/hackndev/zinc.
I've just finished a major refactoring work for LPC1768 code, so
STM32F4 is kind of
There is a number of options on the memory side of things. I feel that
stack usage could be estimated a bit more simply with rust and it's
__morestack support, so that it would be possible to run a few threads with
preemptive scheduling (__morestack also guarantees that no memory
corruption would
Ruby is aluminum oxide. C is elemental carbon; C++, doubly ionized. Perl is
mostly calcium carbonate. But there are better wordplay opportunities here
than obscure chemistry references.
On April 23, 2014 12:28:48 AM Vladimir Pouzanov farcal...@gmail.com wrote:
Luckily enough, I had the
Hi everyone,
I believe that by-move pattern bindings don't actually have to perform
any copying of bits for non-word-sized values. This applies to both
`let` and `match`. It surprised me too, which is why I thought I'd send
it to the mailing list first.
A by-move pattern binding is any
Ah, neat. I have been wanting to do this optimization for function
parameters for a long time, but I hadn't thought about it for other
kinds of bindings. Better yet, I think by-copy vs by-move is a red
herring. The optimization applies equally well in both scenarios.
That said, we do have to be a
On Wed, Apr 16, 2014 at 12:21:20AM -0400, comex wrote:
If I have x: [char, ..5], I can use ~*x to get an owned version
without a lot of typing. Would it be too insane to have that work for
[char] or str with DST?
Something like this will work, yes. It'll probably look more like:
We're just being overly restrictive for legacy reasons.
This same sentiment appears in https://github.com/rust-lang/rfcs/pull/48 .
How many more rules are we imposing that exist only for legacy reasons?
Is addressing them all a priority for 1.0?
On Wed, Apr 23, 2014 at 10:09 PM, Niko Matsakis
