This api is a little in flux (hopefully #10179 will land soon), but
I'm not quite sure what you mean about keeping the file descriptor
open. If there was an error opening the file, then a file descriptor
was never allocated and there's nothing to keep open. Regardless, once
my pull request lands, y
I prepared a patch that renames everything as proposed with the
exception of Option's unwrap -> get change here:
https://github.com/Kimundi/rust/commit/752912f75f6334da87a476fffc2475a3dfa5639d
I touches ~ 300 lines, most of them being the unwrap -> get and
unwrap_err -> err_get fallout.
In f
On 11/02/2013 04:34 PM, Niko Matsakis wrote:
I am generally in favor of this proposal. It seems to be a reasonable
way forward. It is unclear to me how many types would benefit from
this approach of having methods for each variant, but `Result`
certainly does.
With respect to possible confusion
How to check an error at opening a file but without closing its file
descriptor?
use std::path;
use std::rt::io;
use std::rt::io::file;
let filename = "/some/path";
let f = file::open(&path::Path::new(filename), io::Open, io::Read);
___
Rust-dev maili
Thanks! :D
It compiles now! (and works)
The working code is here:
https://github.com/astrieanna/rust-fun/blob/one_worker_per_element/pmap.rs
Best,
Leah
On Sat, Nov 2, 2013 at 5:21 PM, Simon Sapin wrote:
> Le 02/11/2013 21:05, Leah Hanson a écrit :
>
> Thanks, Brendan. :)
>>
>> You’re
Le 02/11/2013 21:05, Leah Hanson a écrit :
Thanks, Brendan. :)
You’re trying to move the ~strs out of the vector. You’ll need to
use `move_iter`:
Is this "moving" about moving memory around or about promising the
compiler that I won't use those elements of the vector again?
~str is an
Instead of `do spawn` try `do spawn_with(s) |s| { ... }`. Then the closure
won't close over s, but rather take it as an argument, allowing it to move
it out.
Cheers
On Sat, Nov 2, 2013 at 5:05 PM, Leah Hanson wrote:
> Thanks, Brendan. :)
>
> You’re trying to move the ~strs out of the vector. Y
Thanks, Brendan. :)
You’re trying to move the ~strs out of the vector. You’ll need to use
> `move_iter`:
>
Is this "moving" about moving memory around or about promising the compiler
that I won't use those elements of the vector again?
> ~~~
> let ports = do myvect.move_iter().map |s| {
> le
You’re trying to move the ~strs out of the vector. You’ll need to use
`move_iter`:
~~~
let ports = do myvect.move_iter().map |s| {
let (pport, cchan) = stream();
do spawn {
cchan.send(fun(s))
}
pport
}.to_owned_vec();
~~~
Also note the use of `to_owned_vec`. `map` lazily
Thanks, Scott, I think that's closer.
However, now I'm having trouble with my pointer types. Using the element
inside a spawn means that I need to capture the owned string in the right
way so that the compiler allows me to give it to the other task.
This version:
~~~
let ports = do myvect.iter().
I would think:
let ports = do myvect.iter().map { |e| something(e) }
On Sat, 2 Nov 2013, Leah Hanson wrote:
Hi,
I have a ~[~str]. I have code that will turn a ~str into a Port.
I want to end up with a [Port]. (or ~ or @ or whatever. I just want
to be able to iterate over the Ports later.)
S
Hi,
I have a ~[~str]. I have code that will turn a ~str into a Port.
I want to end up with a [Port]. (or ~ or @ or whatever. I just want
to be able to iterate over the Ports later.)
Since I'm not sure what looping construct to use, I tried with a for-each
loop.
~~~
let ports = for s in myvect.i
I am generally in favor of this proposal. It seems to be a reasonable
way forward. It is unclear to me how many types would benefit from
this approach of having methods for each variant, but `Result`
certainly does.
With respect to possible confusion between `is_ok()` and `ok()` -- I
think that th
A '?' suffix for boolean methods would be fantastic.
On Sat, Nov 2, 2013 at 4:40 AM, Oren Ben-Kiki wrote:
> I would love it if '?' was allowed at the end of any identifier, to make it
> natural to name boolean variables, methods, constants, etc. Having to say
> is_xxx is ugly IMO. A lint option e
I would love it if '?' was allowed at the end of any identifier, to make it
natural to name boolean variables, methods, constants, etc. Having to say
is_xxx is ugly IMO. A lint option ensuring this is only applied to boolean
typed constructs could help reduce abuse, if this is seen as an issue.
On
15 matches
Mail list logo
