On Tue, Feb 18, 2014 at 11:52 PM, Phil Dawes rustp...@phildawes.net wrote:
Is that not a big problem for production code? I think I'd prefer the
default case to be to crash the task than deal with a logic bug.
The existence of library functions that swallow errors makes reviewing
code and
I understand, but it seems like a bad tradeoff to me in a language with
safety as a primary feature.
'.lines()' looks like the way to do line iteration in rust, so people will
use it without thinking especially as it is part of the std.io introduction.
On Wed, Feb 19, 2014 at 8:36 AM, Tim Kuehn
On 19/02/14 09:14, Phil Dawes wrote:
I understand, but it seems like a bad tradeoff to me in a language
with safety as a primary feature.
'.lines()' looks like the way to do line iteration in rust, so people
will use it without thinking especially as it is part of the std.io
http://std.io
It would need a red mark because *one* convenience method doesn't
provide the full error handling suite?? Surely Rust at least gets Some.
That said, the failing-reader and/or `operate` techniques sound like
they might be nice, on first blush. (I'll note that `operate` is very
similar to the
On Wed, Feb 19, 2014 at 1:40 AM, Brian Anderson bander...@mozilla.com wrote:
Backwards-compatibility is guaranteed.
Does that include ABI compatibility?
Second, the AST is traversed and stability index is propagated downward to
any indexable node that isn't explicitly tagged.
Should it be
Am 19.02.2014 08:52, schrieb Phil Dawes:
Is that not a big problem for production code? I think I'd prefer the
default case to be to crash the task than deal with a logic bug.
The existence of library functions that swallow errors makes reviewing
code and reasoning about failure cases a lot
Hi everyone,
So I would like to know if anyone else working on this and to read your
comments on the JSR 310 choice.
I was interested but day job, master thesis and my own XML parser got in
the way :(
If you are starting I'd love to join and help you, but I have a LOT of
reading on my
I also love to be part of it if you set up a github project I'll be glad to
send some PL on this subject
-
Gaetan
2014-02-19 14:43 GMT+01:00 Daniel Fath daniel.fa...@gmail.com:
Hi everyone,
So I would like to know if anyone else working on this and to read your
comments on the JSR
On 2014-02-18, at 15:52, Alfredos (fredy) Damkalis fr...@fredy.gr wrote:
Hi everyone,
I am new to rust and interested in writing datetime library.
I have already read most of the linked documents and code gathered by
Luis de Bethencourt and others in wiki page [1].
I have also read the
I would also agree that yes, this is the wrong default. Things should
default to Stability 1 unless otherwise marked. If you don't care
about stability tracking, this seems completely reasonable to properly
communicate your intentions.
___
Rust-dev
Why not just modify the Lines iterator to return values of IoResult~str?
All the caller has to do to unwrap that is to use if_ok!() or try!() on the
returned value, so, its basically just as easy to use and it means that
errors are handled consistently. I don't see why this particular use case
Hi all,
I'd like to share some thoughts with regard to our current test and
approval process. Let me break this thoughts into 2 separate sections:
1. Testing:
Currently, all patches are being tested after they are approved. However, I
think it would be of great benefit for contributors - and
On 19/02/2014 21:12, Flaper87 wrote:
2. Approval Process
[...] For example, requiring 2 r+ from 2 different reviewers instead
of 1. This might seem a bit drastic now, however as the number of
contributors grows, this will help with making sure that patches are
reviewed at least by 2 core
As an alternative to arbitrary code running on the buildbot, there could
be a b+ which means please try building this which core contributors can
comment with after a quick skim through the patch.
On Wed, Feb 19, 2014 at 3:38 PM, Felix S. Klock II pnkfe...@mozilla.comwrote:
On 19/02/2014
On Wed, Feb 19, 2014 at 12:38 PM, Felix S. Klock II pnkfe...@mozilla.comwrote:
On 19/02/2014 21:12, Flaper87 wrote:
2. Approval Process
[...] For example, requiring 2 r+ from 2 different reviewers instead of
1. This might seem a bit drastic now, however as the number of contributors
My understanding is that .lines() exists primarily to make quick-and-dirty I/O
as easy as it is in, say, a scripting language. How do scripting languages
handle I/O errors when iterating lines? Do they raise an exception? Perhaps
.lines() should fail!() if it gets a non-EOF error. Then we could
On Feb 19, 2014, at 12:28 PM, Corey Richardson co...@octayn.net wrote:
This is a pretty bad idea, allowing *arbitrary unreviewed anything* to
run on the buildbots. All it needs to do is remove the contents of its
home directory to put the builder out of commission, afaik. It'd
definitely be
Another alternative is to have a few fast builders (e.g. whatever
configuration the try bots run) just run through the queue as they're
r+'d to get fast feedback.
(A (significant) problem with all these proposals is the increase in
infrastructure complexity: there's already semi-regular
2014-02-19 22:48 GMT+01:00 Kevin Ballard ke...@sb.org:
On Feb 19, 2014, at 12:28 PM, Corey Richardson co...@octayn.net wrote:
This is a pretty bad idea, allowing *arbitrary unreviewed anything* to
run on the buildbots. All it needs to do is remove the contents of its
home directory to put
On 19/02/14 21:44, Kevin Ballard wrote:
My understanding is that .lines() exists primarily to make
quick-and-dirty I/O as easy as it is in, say, a scripting language.
How do scripting languages handle I/O errors when iterating lines? Do
they raise an exception? Perhaps .lines() should fail!()
On Feb 19, 2014, at 2:34 PM, Lee Braiden leebr...@gmail.com wrote:
Then we could introduce a new struct to wrap any Reader that translates
non-EOF errors into EOF specifically to let you say “I really don’t care
about failure”.
It sounds like a very specific way to handle a very general
Currently, all patches are being tested after they are approved. However, I
think it would be of great benefit for contributors - and reviewers - to
test patches before and after they're approved.
I would personally love to explore using Travis-CI for this. I think
this is almost exactly what
#12368 has 3 concrete suggestions for possible solutions (which are
included in your list of 6):
- A FailingReader wrapper that wraps another reader and fails on errors
- A ChompingReader wrapper that chomps errors, but stores them so that
they are externally accessible
- Have the lines()
Can you point to any scripting langs whose lines equivalent just silently
ignores errors? I'm not aware of any; even perl will at least populate $!.
I opened https://github.com/mozilla/rust/issues/12130 a little while ago
about if_ok!/try! not being usable from main and the limitations for
On Wed, Feb 19, 2014 at 11:53 PM, Alex Crichton a...@crichton.co wrote:
Currently, all patches are being tested after they are approved. However, I
think it would be of great benefit for contributors - and reviewers - to
test patches before and after they're approved.
I would personally love
Travis is well for unit testing with already existing compiler, however
here I dont see how you will deploy the stage0 easily for automating.
I think you should stick with your buildbot and improve it in order to
enhance pre merge tests on PL (why not trigger the test when the creator of
the PL
On Feb 19, 2014, at 3:40 PM, Jason Fager jfa...@gmail.com wrote:
Can you point to any scripting langs whose lines equivalent just silently
ignores errors? I'm not aware of any; even perl will at least populate $!.
No, because I typically don’t think about errors when writing quick
Thinking about this a bit more, I think that another solution would be:
7 - Update lines() to return an IteratorIoResult and then create an
iterator wrapper that fails on any error except for EOF. I think by using
an extension method, the syntax could be:
fn main() {
for line in
You're assuming `use` loads code, but it only brings names into scope.
`mod submodule;` is what loads `submodule` into the crate. See
http://static.rust-lang.org/doc/master/tutorial.html#crates-and-the-module-system
On Wed, Feb 19, 2014 at 11:37 PM, benjamin adamson
adamson.benja...@gmail.com
29 matches
Mail list logo
