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
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
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
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
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:
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
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
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,
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 a...@crichton.co 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
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
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 pnathan.softw...@gmail.comwrote:
Hi,
It looks like two people have expressed interest in this. I think that's
enough to get together and talk.
My suggestion for
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
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
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 2014-05-16, at 7:14, Daniel Micay danielmi...@gmail.com 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
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
16 matches
Mail list logo
