On 16/05/14 12:48 AM, Tommi wrote:
> On 2014-05-16, at 7:35, Steven Fackler wrote:
>
>> Type annotations are not there for the compiler; they're there for people
>> reading the code. If I want to use some function I don't want to be forced
>> to read the entire implementation to figure out what
On 2014-05-16, at 7:35, Steven Fackler wrote:
> Type annotations are not there for the compiler; they're there for people
> reading the code. If I want to use some function I don't want to be forced to
> read the entire implementation to figure out what the lifetime of the return
> value is.
Type annotations are not there for the compiler; they're there for people
reading the code. If I want to use some function I don't want to be forced
to read the entire implementation to figure out what the lifetime of the
return value is.
Steven Fackler
On Thu, May 15, 2014 at 9:30 PM, Tommi wr
On 2014-05-16, at 7:14, Daniel Micay wrote:
> On 16/05/14 12:10 AM, Tommi wrote:
>> I was just wondering, why do we have to explicitly specify the lifetimes of
>> references returned from functions? Couldn't the compiler figure those
>> lifetimes out by itself by analyzing the code in the funct
On 16/05/14 12:14 AM, Daniel Micay wrote:
> On 16/05/14 12:10 AM, Tommi wrote:
>> I was just wondering, why do we have to explicitly specify the lifetimes of
>> references returned from functions? Couldn't the compiler figure those
>> lifetimes out by itself by analyzing the code in the function?
On 16/05/14 12:10 AM, Tommi wrote:
> I was just wondering, why do we have to explicitly specify the lifetimes of
> references returned from functions? Couldn't the compiler figure those
> lifetimes out by itself by analyzing the code in the function?
Type inference is local to functions, so it c
I was just wondering, why do we have to explicitly specify the lifetimes of
references returned from functions? Couldn't the compiler figure those
lifetimes out by itself by analyzing the code in the function?
___
Rust-dev mailing list
Rust-dev@mozilla
I'm down for a meetup. I may be able to bring some others from UW CSE with
me.
On Thu, May 15, 2014 at 1:46 PM, Paul Nathan wrote:
> Hi,
>
> It looks like two people have expressed interest in this. I think that's
> enough to get together and talk.
>
> My suggestion for scheduling is next Thursd
> 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.)
>
Hi Alex,
Sorry for replying off-list, previously. I would try to argue on the
both points:
On Fri, May 16, 2014 at 2:09 AM, Alex Crichton 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.
>>
>> Is this intentio
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
Hi,
I have a few kinds of tasks like the ones reading from a TCP socket or
listening for TCP connections, that need to be shut down when
unneeded. How can I wake up/kill a task waiting for data in
Reader.read() method or similar?
In the master branch I can set_timeout and wake up once a while (wh
Hi,
It looks like two people have expressed interest in this. I think that's
enough to get together and talk.
My suggestion for scheduling is next Thursday (May 22nd) at 7-9pm at Remedy
Teas[1] on Capitol Hill.
Proposed topics:
- meet & greet
- talk about extant Rust projects (if any)
- planned
I’m pretty sure everybody agree with you. The guides, tutorial and manual are
always seen like a huge opportunity for improvement but few people have really
put effort on it.
I’m currently refactoring the guides with the following goals in mind:
1. Keep consistency when we talk about “pointers”
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
I'd like to put the following in a crate that intercepts start-up to
modify argc/argv, and then yield to whatever the normal start-up
procedure is (native, green, call main, etc...).
#[start]
fn start(...) {
/* pre-process argc/argv */
call default start-up stuff
}
Currently I'm having to exp
On 15/05/2014 08:59, Christophe Pedretti wrote:
I am trying to implement a Singleton (an object which instantiate only
once, successive instantiations returning the object itself).
Any tutorial for this ? any idea ? example ? best practice ?
Kimundi published this macro to define lazily initial
Hello,
My first instinct would be: don't... but in the name of science...
Have you tried looking at Stack Overflow ? Just googling around I found:
http://stackoverflow.com/questions/19605132/is-it-possible-to-use-global-variables-in-rustwhich
allows you to have a global variable and from there a
I am trying to implement a Singleton (an object which instantiate only
once, successive instantiations returning the object itself).
Any tutorial for this ? any idea ? example ? best practice ?
thanks
___
Rust-dev mailing list
Rust-dev@mozilla.org
https:
19 matches
Mail list logo