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> {
t
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 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 will
morestack, used
>> implicitly).
>>
>> I have the same problem with ISRs that re defined in libzinc. For now, I
>> make trampolines in the app code:
>>
>> #[no_mangle]
>> #[inline(never)]
>> #[no_split_stack]
>> pub unsafe fn task_schedule
While not currently possible, we plan on accommodating use cases such
as this through first-class allocators via type parameters. You'll be
able to specify your own allocator an standard library routines that
allocate memory.
Your other option currently is to link to libcore (which doesn't
provide
The ~int type has since moved to Box, 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 com
The equivalent of a function pointer in C is the bare fn type in rust. For
example, you could write your binding as:
// C code
int sqlite3_bind_text(sqlite3_stmt*, int, const char*, int n,
void(*)(void*));
// Rust definition
fn sqlite3_bind_text(stmt: *mut sqlite3_
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 wrote:
> I'd like to put t
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, 2014
> 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.)
>
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 print
> 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 i
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 wrote:
> Hi,
>
> I am trying different altern
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 wrote:
> Hi,
>
> So finally Rust can cross-compile for iOS
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
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) =
ntributors to Rust 0.11.0
---
Aaron Raimist
Aaron Turon
Adolfo Ochagavía
Adrien Tétar
Ahmed Charles
Alan Andrade
Alan Williams
Alex Crichton
Alexandre Gagnon
Alexei Sholik
Ali Smesseim
Andrew Gallant
Anton Löfgren
Arcterus
Ariel Ben-Yehuda
Axel Viala
Ben No
I've been tinkering with rusti recently, and I'm reaching the
conclusion that it should be removed entirely from the compiler. As
many people are probably aware, rusti hasn't been working
fantastically for awhile now, but that's only partially why I think
that it should be removed.
- What I think
Thanks for your input! It sounds like one thing we can definitely
agree that rustc isn't ready for a rusti-like tool to work 100% today.
> I knew that pretty printing history into a big list of strings was a bad way
> for it to work, but there was no other way to make it work at the time. Each
> c
> I was looking for something like: static h:HashMap =
> {(K,V),(K,V).}.
> Is this possible at all?
Unfortunately this is more difficult than it seems. One of the nice
things about the standard HashMap implementation is that it keys the
hashes with random values (stored in each hash map). If t
It's awesome to have a lot of syntactic sugar for the compiler for things like
overloading operators, automatic borrows (@mut in a lib), etc. What's
unfortunate is that each of these features requires a new `lang_item` to be
defined by the compiler *and* any crate which is compiled.
To alleviate t
I recently looked into redesigning fmt!, and I wanted to post my ideas before
going all the way to ensure that I'm not missing out on anything.
== Today's state ==
As of today, fmt! works pretty well. It's a very useful function and will likely
be a very common thing in all rust code using libstd
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 task
> 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 wo
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
wrote:
> Is the following error cause by this change?
>
> % rustc -v
> dyld: Library not loaded:
> x86
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 yo
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 wrote:
> I tried the rust-http's comparison wit
> 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?
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
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 of
Currently the threshold for being "officially supported" will be one
of being in the rust-lang organization or being on the travis
dashboard. At this time there are no plans to have an in-tree way to
distinguish, although I suspect that a README with a description would
likely suffice.
On Tue, Jul
>> 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
> 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
>> 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
> 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.
>> 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 i
>> 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 gen
101 - 138 of 138 matches
Mail list logo
