Re: [rust-dev] Rustaceans - Rust User Groups
I'd be wary of some of the lists, such as rust-core, rust-bugs, rust-announce, etc, that some may think are official. On Tue, Aug 11, 2015 at 1:38 PM Simon Flynn simon.fl...@financejobs.co wrote: On Tue, Aug 11, 2015 at 10:11:10PM +0200, Simon Sapin wrote: On 11/08/15 16:12, Simon Flynn wrote: Are you aware of https://users.rust-lang.org/ ? Yes, I'm aware. However, the focus of rustaceans.com will be fostering small, tight knit communities akin to what Perl Mongers is to Perl, whereas users.rust-lang.org is more for discussions of Rust itself. we have decided Who is we? The small team at Finance Jobs. I regularly attend the meetups in Paris. They are organized on meetup.com/Rust-Paris and on #rust-fr IRC. I don’t remember hearing of a desire for yet another communication channel. Did someone ask for paris-rustace...@rustaceans.com? The initial list of existing mailing lists where taken from the list of Rust 1.0 Launch Party events. Paris was one of them :) Simon -- Simon Flynn https://www.financejobs.co ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rustaceans - Rust User Groups
Yes I know. Even just adding `Unofficial' in the description of those lists would help prevent confusion, I think. The 'official' rust-core is https://internals.rust-lang.org On Tue, Aug 11, 2015 at 4:42 PM Simon Flynn simon.fl...@financejobs.co wrote: Mozilla having semi-closed their rust-dev mailing list was the motivation for hosting the rust-* lists. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust Research Project Query
A project I'd love to see (either separate, or eventually baked into the test harness), is test coverage data. Something like how Go's cover[1] works, by adding counters to the source code, seems simplest. I've thought about this, and it could either be a CLI tool, like `rustc --cover --test`, or a plugin. Perhaps including a `#![cover]` attribute in the crate or something. With a plugin, the Plugin Registrar would need to add the ability to register a Visitor that can modify the AST. [1] http://blog.golang.org/cover ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Many-to-many channels
On Sat, Oct 4, 2014 at 1:27 PM, Evan G eg1...@gmail.com wrote: Couldn't you just implement that with a loop and a match statement? Wouldn't that just make the process burn cpu, instead of being able to allow other threads to work? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] std::rand::Rng
On Wed, Sep 17, 2014 at 2:26 PM, Evan Davis cptr...@gmail.com wrote: The problem is that you're trying to use a trait as a type. That shouldn't be a problem. You can use a `mut Trait`, and you'll get dynamic dispatch. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] FFI: how to deal with different platforms
You can use define the CSIZE a couple times in your file, with conditional compilation: http://doc.rust-lang.org/rust.html#conditional-compilation On Sun, Sep 7, 2014 at 6:03 PM, Fox, Michael michael@caviumnetworks.com wrote: How can FFI work across platforms unless you compile against the specific platform’s headers? Sometimes a common header defines the same-named structure, type or macro differently depending on your platform. For example, here’s a definition from termios.h on OSX: #define CSIZE 0x0300 /* character size mask */ And here’s the same one on some old Linux: #define CSIZE 060 So, you can’t just take one of them and define it like: pub static CSIZE: ulong_t = 0x300; I don’t see how it can work unless you embed a C compiler which reads and uses the actual platform’s headers. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Place for discussions
I went into my account settings for the Rust Discourse, and fiddled with the email notifications such that I get emails for all topics, and replying to the emails works just as with a mailing list. I quite like the HTML emails that are sent also, as it makes code and links and such much easier to grok. On Fri, Aug 1, 2014 at 1:32 PM, Evan G eg1...@gmail.com wrote: Has anyone here tried using the Discourse instance in a mailing-list like setup? I know this is one of the target audiences for Discourse installs, there has been some work put in to make this happen, and some communities have started migrating mailman lists to discourse. On Fri, Aug 1, 2014 at 3:27 PM, Blaine Pace blainep...@gmail.com wrote: Not to get the +1! ball rolling too far, but I find the mailing list the most convenient for keeping up with Rust development as well. On Fri, Aug 1, 2014 at 10:50 AM, Kevin Cantu m...@kevincantu.org wrote: Ditto. /me scratches neck beard Kevin On Fri, Aug 1, 2014 at 9:51 AM, Steve Klabnik st...@steveklabnik.com wrote: I actually find mailing lists to have a perfectly serviceable UI, but I recognize that others don't. I'm just really an old man at heart... ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Blaine Pace ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] std::num::pow() is inadequate / language concepts
On Fri, Jul 25, 2014 at 1:45 PM, Gregor Cramer rema...@gmx.net wrote: How you are doing this? I'm in fact a newbie in Rust, and it's interesting that this can be done. std::num::pow() is a good example, I think. Suppose I already have a program which is using std::num::pow() with a self defined integer type. Now you are changing std::num::pow(), moving the functionality into a trait. And my program will still compile and work as before? I'd expect that std::num::pow() would gain a #[deprecated = Use Pow trait] attribute, and be removed after Rust's deprecation period (which pre-1.0 is pretty much a few commits later). ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] A few random questions
On Wed, May 28, 2014 at 5:38 PM, Oleg Eterevsky o...@eterevsky.com wrote:
3. It seems like almost any string operation requires as_slice().
Can't various string methods be also implemented for String?
When writing functions for others to use, you don't want to require them to
have a String, since that requires a heap allocation. It's free to go from
String to a slice, but not vice-versa. That said, there's been whispers of
making String implement Deref, as well passing as arguments to autoderef,
so you could pass a String and rustc would convert to a slice for you.
5. Simple indexing doesn't work for vectors:
let a = vec![1, 2, 3];
println!({}, a[0]);
It's a bit surprising...
Known issue: https://github.com/mozilla/rust/issues/11875
6. impl ToStr for custom struct fails:
error: conflicting implementations for trait `std::to_str::ToStr`
note: conflicting implementation in crate `std`
Is it a bug? Is Show implicitly assumed for all struct's?
This is because ToStr is implemented for all Show implementations. You
can't implement ToStr, because if you then implemented Show, you'd have
conflicting implementations. #[deriving(Show)] on your structs is probably
all you want.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Array of heap allocated strings for opts_present?
Considering many options would be single characters, it'd seem nice to also
be able to pass a slice of chars. It doesn't look like char implements Str.
getopts could define a new trait, Text or something, for all 3...
On Mon, May 26, 2014 at 2:56 PM, Kevin Ballard ke...@sb.org wrote:
I think getopts has an old API. All the methods that take [String] should
probably be rewritten to be generic with S: Str and take [S] instead,
which will allow taking either a slice of Strings or a slice of str's.
-Kevin
On May 26, 2014, at 12:16 PM, Benjamin Striegel ben.strie...@gmail.com
wrote:
I'm not familiar with the getopts module, but on the surface that behavior
sounds wrong to me.
As for the verbosity of the repeated `to_owned` calls, this sounds like
the perfect application for macros:
#![feature(macro_rules)]
macro_rules! owned(
($($e:expr),*) = ([$($e.to_owned()),*])
)
fn main() {
let x = owned![b, c, d];
}
On Mon, May 26, 2014 at 2:11 PM, Gulshan Singh gsingh_2...@yahoo.comwrote:
Why does getopts::Matches::opts_present() take an array of heap
allocated strings? Unless I'm missing something, it doesn't seem like it
needs to:
https://github.com/mozilla/rust/blob/7d76d0ad44e1ec203d235f22eb3514247b8cbfe5/src/libgetopts/lib.rs#L302
Currently, my code to use it looks like this:
if matches.opts_present([b.to_owned(), x.to_owned(), s.to_owned(),
w.to_owned()]) { /* */ }
1. Should the function be converted to take a list of borrowed strings?
2. Regardless of what this function should take as an argument, is the
way I'm constructing a list of StrBufs the correct way to do it? It seems a
bit verbose.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Cryptography Library
There's rust-crypto[1], which has quite a few implementations already. The issue isn't so much that Rust needs crypto code, is that it needs auditing of the code that exists. [1] https://github.com/DaGenix/rust-crypto___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Is it possible to implement extension methods on existing traits?
I can't say why the immutable argument error is happening, but there's
another error in that function. You're using a `Writer`, but Writer doesn't
have `write_my_string`, only `MySerialization` does. I'd write that like
this:
fn save_toT: MySerialization(self, writer: mut T) - io::IoResult() {
writer.write_my_string(self.string_field_1) // don't need try!, since
you're returning an IoResult
}
On Sat, Apr 5, 2014 at 1:55 PM, Frank Huang m...@nongraphical.com wrote:
Thanks for the quick response, Steven! Having done what you suggested, I'm
now getting the following error (for serializing a larger struct in which
some fields are strings):
implT: Writer MySerialization for T {
fn write_my_string(mut self, s: str) - IoResult() {
...
}
}
impl StructToBeSerialized {
fn save_to(self, writer: mut io::Writer) - io::IoResult() {
try!(writer.write_my_string(self.string_field_1)); // error at this
line
}
}
The error is at the indicated line and it says: cannot borrow immutable
argument `writer` as mutable. However, the function argument writer to
save_to is a mut io::Writer, which would seem to be mutable to me. Would
you happen to know what's going wrong with this code?
Thanks again!
Frank
On Sat, Apr 5, 2014 at 1:17 PM, Steven Fackler sfack...@gmail.com wrote:
You can do it like this:
implT: Writer MySerialization for T {
...
}
Steven Fackler
On Sat, Apr 5, 2014 at 12:57 PM, Frank Huang m...@nongraphical.com wrote:
Hello everyone,
I have a question about making extension methods on something like
io::Writer. Basically, I have a data format that requires strings to be
serialized as an 8-byte length header and then the string bytes themselves.
Instead of having to type writer.write_u64(...); writer.write_str(...);
over and over again, I would like to implement some extension methods or
something like that on io::Writer, like the following pseudocode:
trait MySerialization {
fn write_my_string(mut self, s: str) - io::IoResult();
}
impl MySerialization for io::Writer {
fn write_my_string(mut self, s: str) - io::IoResult() {
try!(self.write_u64(s.len());
self.write_str(s);
}
}
However, this of course doesn't work, because I can't implement a trait
for a trait. Rustc says: reference to trait `io::Writer` where a type is
expected; try `@io::Writer`, `~io::Writer`, or `io::Writer`, however when
I try io::Writer as suggested, rustc complains about lifetimes. Is this
sort of thing possible in Rust?
Thanks for your help!
- Frank
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Refactor json.rs
How is it different from having the generic on the trait itself?
On Mar 22, 2014 10:44 AM, comex com...@gmail.com wrote:
On Sat, Mar 22, 2014 at 10:24 AM, Edward Wang edward.yu.w...@gmail.com
wrote:
But of course, it is very uncivilized :) Any suggestion on how to
refactor
this piece of code so it won't violate the lifetime requirement?
To be drastic, if Encodable were
pub trait Encodable {
fn encodeS: Encoder(self, s: mut S);
}
wouldn't it avoid this problem?
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] RFC: Importing/exporting macros
Rust now has the ability to import macros from other crates, hurray!
However, I'd like to propose adjusting the current way of using them to be
more like importing/exporting other symbols of a crate.
1) It's more consistent, makes it easier to find where macros came from.
2) Current usage brings name collisions.
Current example:
pub mod foo {
// assume other macros as well
#[macro_export]
macro_rules! bar ( ... )
}
pub mod baz {
// assume other macros as well
#[macro_export]
macro_rules! bar ( ... )
}
mod herp {
// i want bar! from foo, and some other macros from baz
[phase(syntax)]
use super::foo;
[phase(syntax)]
use super::baz;
pub Derp = bar!(); // which bar? is this an ICE? or logic error?
}
Proposed example:
pub mod foo {
pub marco_rules! bar ( ... );
}
pub mod baz {
pub marco_rules! bar ( ... );
pub marco_rules! quux ( ... );
}
mod herp {
use super::foo::bar!;
use super::baz::quux!;
// using same name macros, no problem
use baz! = super::baz::bar!;
pub Derp = bar!(baz!());
}
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Chaining Results and Options
This could be handled by a macro. opt_method!(tmp, method) On Mon, Feb 10, 2014 at 12:04 PM, Ziad Hatahet hata...@gmail.com wrote: Isn't this proposal a subset of having `do` syntax like Haskell does? I thought that was being blocked on HKTs. -- Ziad On Mon, Feb 10, 2014 at 4:40 AM, Armin Ronacher armin.ronac...@active-4.com wrote: Hi, On 10/02/2014 11:50, Huon Wilson wrote: It's actually Haskell's fmap, which we have in the form of .map for both Option[1] and Result[2], e.g. the proposed expr-method() is the same as expr.map(|x| x.method()) (which is still quite verbose). The return value of .method() is actually a Result/Option so it would be more similar to .and_then: foo-bar() // would be the same as foo.and_then(|x| x.bar()); Regards, Armin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] user input
let in = readln!() ?
macro_rules! readln(
() = ({
let mut stdin = ::std::io::BufferedReader::new(::std::io::stdin());
stdin.read_line().unwrap()
})
)
On Sat, Feb 8, 2014 at 4:48 PM, Huon Wilson dbau...@gmail.com wrote:
There is read_line:
http://static.rust-lang.org/doc/master/std/io/trait.Buffer.html#method.read_line
use std::io::{stdin, BufferedReader};
fn main() {
let mut stdin = BufferedReader::new(stdin());
let line = stdin.read_line().unwrap();
println!({}, line);
}
Huon
On 09/02/14 11:44, Liigo Zhuang wrote:
2014年2月9日 上午7:35于 Alex Crichton a...@crichton.co写道：
We do indeed want to make common tasks like this fairly lightweight,
but we also strive to require that the program handle possible error
cases. Currently, the code you have shows well what one would expect
when reading a line of input. On today's master, you might be able to
shorten it slightly to:
use std::io::{stdin, BufferedReader};
fn main() {
let mut stdin = BufferedReader::new(stdin());
for line in stdin.lines() {
println!({}, line);
}
}
I'm curious thought what you think is the heavy/verbose aspects of
this? I like common patterns having shortcuts here and there!
This is not a common pattern for stdin. Programs often need process
something when user press return key, immediately. So read one line is more
useful than read multiple lines, at least for stdin. I agree to need
stdin.readln or read_line.
On Sat, Feb 8, 2014 at 3:06 PM, Renato Lenzi rex...@gmail.com wrote:
I would like to manage user input for example by storing it in a
string. I
found this solution:
use std::io::buffered::BufferedReader;
use std::io::stdin;
fn main()
{
let mut stdin = BufferedReader::new(stdin());
let mut s1 = stdin.read_line().unwrap_or(~nothing);
print(s1);
}
It works but it seems (to me) a bit verbose, heavy... is there a
cheaper way
to do this simple task?
Thx.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing
listRust-dev@mozilla.orghttps://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Deprecating rustpkg
On Fri, Jan 31, 2014 at 1:05 PM, Tony Arcieri basc...@gmail.com wrote: IMO, a system that respects semantic versioning, allows you to constrain the dependency to a particular *major* version without requiring pinning to a *specific* version. I would call anything that requires pinning to a specific version an antipattern. Among other things, pinning to specific versions precludes software updates which may be security-critical. It's perfectly reasonable to require a certain *minor* version, since minor versions (in semver) can include API additions that you may depend on. Also, nodejs and npm supposedly support semver, but it's impossible to enforce library authors actually do this, so you'll get libraries with breaking changes going from 1.1.2 to 1.1.3 because reasons. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Moving libcrypto back into rust repo?
Considering the effort to break up libextra into multiple crates in #8784[1], could rust-crypto[2] be moved back into rust as libcrypto? Some comments on the issue deviated about whether crypto should written *in* Rust, or just be bindings. As a user, I don't care how they are implemented, as long as the exposed API is Rust-like. However, I can't imagine scouring the internet for a crypto library maintained by someone, instead of using what comes with Rust (which gives me a sense of assurance that it does the crypto correctly). [1]: https://github.com/mozilla/rust/issues/8784 [2]: https://github.com/DaGenix/rust-crypto ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] let mut - var
Part of the nice thing about `let mut` is that it requires you to opt-in to mutability, making it a conscious choice. Having `let` and `var` would make Rust be like ES6: we all look at `let` and say why bother. For Rust, I imagine many would get into the habit of using `var` over `let` because it's easier, and as code samples show up using it, newcomers would default to using `var`. On Wed, Jan 29, 2014 at 6:50 PM, Kevin Ballard ke...@sb.org wrote: On Jan 29, 2014, at 6:43 PM, Brian Anderson bander...@mozilla.com wrote: On 01/29/2014 06:35 PM, Patrick Walton wrote: On 1/29/14 6:34 PM, Samuel Williams wrote: Perhaps this has been considered already, but when I'm reading rust code let mut just seems to stick out all over the place. Why not add a var keyword that does the same thing? I think there are lots of good and bad reasons to do this or not do it, but I just wanted to propose the idea and see what other people are thinking. `let` takes a pattern. `mut` is a modifier on variables in a pattern. It is reasonable to write `let (x, mut y) = ...`, `let (mut x, y) = ...`, `let (mut x, mut y) = ...`, and so forth. Having a special var syntax would defeat this orthogonality. `var` could potentially just be special-case sugar for `let mut`. To what end? Users still need to know about `mut` for all the other uses of patterns. This would reserve a new keyword and appear to duplicate functionality for no gain. -Kevin ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
