channel. Did someone ask for
paris-rustace...@rustaceans.com?
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
on.
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On 21/09/14 07:34, Daniel Micay wrote:
It's not intended to be used for anything other than memory safety.
It’s also used to maintain invariants, such as the bytes inside a String
being valid UTF-8: String::push_bytes() is unsafe, but
String::push_str() is not.
--
Simon Sapin
, password, host, port number, and path.
(Some of which are optional or can be empty.)
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
some features that were missing:
http://servo.github.io/rust-url/
rust-url is not distributed with rustc, but builds easily with Cargo.
Please use the GitHub issue tracker for any feedback on the
documentation, bugs, feature requests, etc.
Cheers,
--
Simon Sapin
://github.com/rustdoc for this purpose.)
http://docs.travis-ci.com/user/encryption-keys/
https://help.github.com/articles/creating-an-access-token-for-command-line-use
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org
, with instructions
on how to get API keys or whatever Travis wants? I tried
https://github.com/patrickkettner/travis-ping , but only got a
mysterious error messages and didn’t feel like debugging that code.
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev
!
Cheers,
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
we’re doing in this
in London so we’re still figuring it all out. Just remember that the
event is in the evening and that there may be another talk in the same
event. To give a number that I totally just made up, anything up to 30
minutes sounds good.
--
Simon Sapin
on libstd PRs.
How about a gofmt-like source code reformatting utility?
As far as I can tell, everyone agrees it would be great to have. We just
need someone to make it.
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https
the tarball was extracted, without installing it?
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
out that many Travis
auth tokens has expired in the mean time.
Are there advantages or disadvantages with using nightlies from the PPA
rather than those from rust-lang.org?
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https
On 06/06/2014 16:34, Diggory Hardy wrote:
Related: how to do this in a match?
let s = abc.to_owned();
match s {
abc = ...
match s.as_slice() { // ...
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org
On 29/05/2014 08:25, Kevin Ballard wrote:
This is a temporary issue. Once DST lands we will likely implement
Derefstr for String, which will make all str methods work
transparently on String.
Until then, is there a reason not to have String implement the StrSlice
trait?
--
Simon Sapin
).
If that’s the case, it sounds like a bug with an easy fix.
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
/rust/issues/14131 )
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
of a 'match'
statement start with patterns, not expressions. In a pattern, the 'box'
keyword means deconstruct a BoxT type to access the T inside. The
'ref' keyword (which can be used without 'box') means to take a T
reference rather than move the value.
--
Simon Sapin
.
http://static.rust-lang.org/doc/master/core/kinds/trait.Share.html
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
access with .offset()
and ptr::read(), but you can not index it like an array.
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
like
[extern unsafe fn(), ..4] whose size is proportional to the number of
elements.
DST: https://github.com/mozilla/rust/issues/6308
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
!() (in
the prelude) with non-obvious differences.
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
:
For example:
#[deriving(Show)]
enum Function {
GPIO = 0,
F1 = 1,
F2 = 2,
F3 = 3,
}
fn main() {
let f = GPIO;
println!({:?}, f)
let s: ~str = format!({:?}, f);
println!({}, s)
}
Output:
GPIO
GPIO
--
Simon
trying to do.
Could you explain in more details, with more context? For example, what
is it you call a function? It seems not to be Rust function declared
with the `fn` keyword.
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https
.)
On the other hand, we probably don’t want to fragment the discussion
between GitHub issues and email.
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
.
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
*are* issues. Requiring *another* issue when someone has code
to submit already is not useful IMO.
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
can stay as
straightforward as it is, and does not need to be coded defensively.)
---
Does the general idea sound like something y’all want? I’m not overly
attached to the details.
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https
/trait.Iterator.html#method.fuse
http://static.rust-lang.org/doc/master/guide-container.html#iterator-adaptors
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
to a single
location, and user-defined adaptors don't need to get this right.
My entire email was about specifically *not* enforcing anything, only
convention.
Filter is in the exact same category as Map: it’s only expected to be
well-behaved when its input is.
--
Simon Sapin
/4259#issuecomment-34094922
https://github.com/mozilla/rust/wiki/Meeting-weekly-2014-02-04#wiki-llvm
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
member without ref moves.
It would be a different story (I think) if your pattern was Some(ref mut f).
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
) is better.
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
FYI, made a pull request according to this proposal:
https://github.com/mozilla/rust/pull/11129
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On 23/12/2013 22:19, Liigo Zhuang wrote:
Code full of .unwrap() is not good smell I think.
I agree, and I wrote in the first email that it is one of the downsides.
But doubling the API (from_utf8 and from_utf8_opt) is also not a good
smell, so it’s a compromise to find.
--
Simon Sapin
methods.
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
with two variants
for each option function, I would prefer the default one return an
Option and have the variant fail on invalid input. Task failure at
runtime is a nastier surprise than an invalid type error at compile
time, especially for new users who aren't entirely sure of the difference.
--
Simon
= s.utf8_decode()? // logical failure expected, return None or
whatnot
This is interesting, but I’d like to discuss what to do in this
particular language, Rust that is trying to go to 1.0 and will probably
not accept such syntax change :)
--
Simon Sapin
the power to express
the monad typeclass/trait in Rust so the fully general form probably
isn't possible as a syntax extension yet, although a limited version is).
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org
to discuss
this before sending pull requests with invasive API changes.)
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
design, and should be avoided if possible.
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
, but that
leaves the responsibility to the user of the API.
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
this should be a case-by-case decision, but send/try_send and
recv/try_recv have the same issue as from_utf8/from_utf8_opt of two
slightly different names for almost the same thing.
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https
On 06/12/2013 21:50, Eric Reed wrote:
Personally, I prefer making functions that don't fail and use Option or
Result and then composing them with functions that fail for certain
outputs, but I think I'm in the minority there.
Yes, this is what I’m suggesting.
--
Simon Sapin
against this. I think we
should try to avoid doubling the amount of API.
Or perhaps allow the propagation of Option/Result.
This is why we have methods like .map() and .and_then()
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https
to this app; this is critical information to the reader.
How to do that right?
If my proposal is accepted (returning Option is favored), then calling
.unwrap() is the way to express that success is expected. unwrap()
causes task failure when called with None.
--
Simon Sapin
have uses I’m not thinking of right now.
Side note:
Regarding failing vs. returning an Option or Result: I’d be in favor of
only having the latter. Having two versions of the same API (foo() and
foo_opt()) is ugly, and it’s easy to get value or fail from an Option
with .unwrap()
--
Simon
On 02/12/2013 16:21, David Piepgrass wrote:
That would be so. much. better. than a mailing list.
Hi. Could you expand on this? I don’t necessarily disagree, but as the
one proposing change it’s up to you to convince everyone else :)
--
Simon Sapin
| { ... }
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
::slice and count UTF-8
bytes. (Which I suppose is what you call code units?)
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
of the invalid byte sequence, *which can be
negative*, in case the invalid sequence started in an earlier .feed() call.
What do you think it should be?
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust
and should not be encouraged.
(Depending on what you’re doing with it, it could lead to security
issues.) If you do want ignore or ASCII substitute, writing a custom
condition handler is easy enough.
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev
the method
that does end-of-stream processing flush would be confusing.
flush is the name that rust-encoding uses, but I argee that finish
is better for what it does.
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org
Le 10/09/2013 16:47, Simon Sapin a écrit :
TR;DR: the actual proposal is at the end of this email.
I moved this to the wiki, to better deal with updates:
https://github.com/mozilla/rust/wiki/Proposal-for-character-encoding-API
--
Simon Sapin
the API and the behavior
right. I trust the smart people working on Rust to refactor and optimize
the implementation over time.
Cheers,
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Le 11/09/2013 17:19, Marvin Löbel a écrit :
On 09/10/2013 05:47 PM, Simon Sapin wrote:
Hi,
TR;DR: the actual proposal is at the end of this email.
Rust today has good support for UTF-8 which new content definitely
should use, but many systems still have to deal with legacy content
that uses
,
/// even if the input iterator is not exhausted yet.
fn next(mut self) - OptionResult~str, DecodeError {
// Implementation left out.
}
}
Cheers,
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org
bindings to
Rust libraris) and JS or Dart for the UI.
I don’t know about adding Go or Dart to the mix, but it is definitely
one of Servo’s goals to be embeddable as a library in a larger application.
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev
?
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
-sources Gumbo, a C Library for Parsing HTML5.
So it could be used until that somebody builds a parser in pure Rust.
https://github.com/google/gumbo-parser
That’s cool, but what would it buy us to switch from one C library to
another? Is Gumbo better than Hubbub?
--
Simon Sapin
often.
I’m not too attached to the name. Do you have suggestions on how it
could work?
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
) is with a Peekable iterator
as in this pull request:
https://github.com/mozilla/rust/pull/8428
Then .finished() is .peek().is_none().
But this is unnecessary overhead if you don’t otherwise use .peek(). The
for-loop already knows how it exited.
--
Simon Sapin
into an explicit call to the else block.
No, it’s the opposite. The for-else loop jumps to the else block when
the iterator’s next() returns None.
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Le 12/08/2013 20:16, Corey Richardson a écrit :
On Mon, Aug 12, 2013 at 2:54 PM, Simon Sapin simon.sa...@exyr.org wrote:
fn main() {
let v = ~[1u, 7, 42, 0];
let mut it = v.move_iter().enumerate();
for_!((i, v) in it {
if v == 42 {
printfln!(Found it at %u
Le 11/08/2013 06:53, Tom Lee a écrit :
I think your code will be more explicit if you declare a mut bool
check its state post-`break`. :)
Resorting to boolean flags to cope with insufficient control flow feels
like Basic, which makes me sad :(
--
Simon Sapin
.
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Le 10/08/2013 15:56, Jordi Boggiano a écrit :
On 10.08.2013 16:10, Simon Sapin wrote:
Proposal:
for i in iter {
// ...
} else {
// ...
}
The optional else block is executed when the for loop stops without
exhausting the iterator, ie. when break is used.
Maybe
Le 10/08/2013 15:10, Simon Sapin a écrit :
Proposal:
for i in iter {
// ...
} else {
// ...
}
The optional else block is executed when the for loop stops without
exhausting the iterator, ie. when break is used.
Typical usage is finding an element
,
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
{
// ...
}
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
in libstd that uses libc::memcpm instead of an explicit loop:
https://github.com/mozilla/rust/blob/06fec5243b/src/libstd/vec.rs#L2091
Cheers,
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
parameters sep=' ' and end='\n'.
In my experience 'end' is not used often. When it is, it is most often
set to the emtpty string. 'sep' is even less used. So maybe it’s okay to
not have so much flexibility, and require complex cases to fall back on
fmt!()
--
Simon Sapin
.
This is great to have, thanks.
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
(and their types,
presumably.)
Cheers,
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
-webencodings
I've started prototyping a solution patterned on Python (i.e. a tool to
generate specific codec modules from the specs).
What does patterned on Python mean?
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https
-lang.org/doc/core/float.html#function-pow_with_uint
For a float power, I find traces of a f64::pow function but it’s
undocumented…
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
,
it: fn(int) - bool) {
let mut i = lo;
while i hi {
if !it(i) { break }
i += step;
}
}
Maybe range_step() could be added to libcore?
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https
| {
if !it(i, el) { break }
i += 1;
}
}
for enumarate(|it| { some_str.each_char(it) }) |i, ch| { … }
… but it’s not pretty, and doesn’t work with eg. vec::each2 which gives
two arguments to its own `it`.
--
Simon Sapin
___
Rust-dev mailing list
Rust
Le 01/02/2013 14:50, Benjamin Striegel a écrit :
Though note that this function is relatively new, you'll need to be on a
recent unstable version rather than 0.5.
Is it a bug that it’s not documented?
http://static.rust-lang.org/doc/core/int.html
--
Simon Sapin
/map.html
http://static.rust-lang.org/doc/core/hash.html
Cheers,
--
Simon Sapin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
79 matches
Mail list logo
