Re: [rust-dev] Overflow when benchmarking
The `nums` array is allocated on the stack and is 8 MB (assuming you're on
a 64 bit platform).
On Wed Nov 26 2014 at 8:23:08 PM Ben Wilson wrote:
> Hey folks, I've started writing some rust code lately and run into weird
> behavior when benchmarking. When running
>
> https://gist.github.com/benwilson512/56f84d4625f11feb
>
> #[bench]
> fn test_overflow(b: &mut Bencher) {
> let nums = [0i, ..100];
> b.iter(|| {
> let mut x = 0i;
> for i in range(0, nums.len()) {
> x = nums[i];
> }
> });
> }
>
> I get "task '' has overflowed its stack" pretty much immediately when
> running cargo bench. Ordinarily I'd expect to see that error when doing
> recursion, but I can't quite figure out why it's showing up here. What am I
> missing?
>
> Thanks!
>
> - Ben
>
> ___
> 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] Why there's this asymmetry in defining a generic type/function/method and calling it?
The syntax is ambiguous: let foo = (HashMapnew()); is foo a HashMap, or is it a tuple containing the results of these two comparisons: HashMap < Foo and Bar > new()? On Tue Nov 18 2014 at 1:38:26 PM Daniel Trstenjak < daniel.trsten...@gmail.com> wrote: > > Dear rust devs, > > is there a reason why it's e.g.: > >let vec = Vecnew(); >let vec = vec.iter().map(|i| *i + 1).collect::>(); > > instead of: > >let vec = Vec::new(); >let vec = vec.iter().map(|i| *i + 1).collect>(); > > > Thanks for any hints! > > > Greetings, > Daniel > ___ > 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] surprising test failure with "panicked at 'Box'"
assert! Takes a boolean expression and an optional error message. The `false` is being interpreted as an error message which results in the Box output. You probably want to use assert_eq! On Mon Nov 17 2014 at 8:31:46 AM Max R.D. Parmer wrote: > The code and error generated from the test suite are here: > https://gist.github.com/maxrp/e8b17669d18006471434 > > Where things get strange to me (is this a bug?) is how main() works as > expected and the first test passes but the second test fails with this > odd "panicked at 'Box'" -- I'm not sure where the Box occurs -- > possibly libtest? > > I'm using the latest nightlies: > rustc --version && cargo --version > rustc 0.13.0-nightly (d91a015ab 2014-11-14 23:37:27 +) > cargo 0.0.1-pre-nightly (56852db 2014-11-14 23:33:33 +) > > Secondary to the specific issue, any remarks on style and idiom are also > welcome. > > Thanks, > Max > ___ > 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] Rationale on if let
A special grammar is not necessary:
```
if let Foo(bar) = baz() {
bar.process();
}
``
is equivalent to
```
match baz() {
Foo(bar) => bar.process(),
_ => {}
}
```
Similarly, `for` and `while` loops do not require a special grammar, since
they can be emulated with `loop`:
```
while thing {
do_bar();
}
```
is equivalent to
```
loop {
if !thing {
break;
}
do_bar();
}
```
We judged that the convenience of the `if let` syntax justified its
inclusion in the language, just like `for` and `while`.
Steven Fackler
On Tue, Oct 14, 2014 at 8:40 AM, Michael Giagnocavo
wrote:
> The RFC only shows examples with optionals, and Swift, which is the
> inspiration(?) for this only allows it with optionals. I suppose it might
> also be useful in matching e.g. lists.
>
> I didn’t see where the RFC states why special grammar is needed, over a
> closure-like syntax. Just curious.
>
> -Michael
>
> From: Steven Fackler [mailto:sfack...@gmail.com]
> Sent: Sunday, October 12, 2014 11:53 PM
> To: Michael Giagnocavo
> Cc: Rust-dev@mozilla.org
> Subject: Re: [rust-dev] Rationale on if let
>
> `if let` acts on *any* refutable pattern, not just `Option`s. The RFC that
> proposed the syntax is a good place to look for the rationale of why it was
> added: https://github.com/rust-lang/rfcs/pull/160
>
>
> Steven Fackler
>
> On Sun, Oct 12, 2014 at 10:41 PM, Michael Giagnocavo
> wrote:
> I came across the "if let" syntax, and it's been bothering me a bit.
>
> It seems like a strange thing to elevate to a grammar-level construct.
>
> The example given is:
> if let Some(x) = foo() {
> doSomethingWith(x)
> }
>
> What's wrong with e.g.:
>
> foo().if_some!(|x| { doSomethingWith(x) })?
>
> Can macros not step in here and allow us to write code that looks like a
> closure but doesn't actually create a closure or cost any overhead?
> (In fact, is a macro even needed? Couldn't a function and it's function
> parameters be marked for inlining - wouldn't that take care of it?) This
> seems like a handy thing to have in general. I've written code in other
> languages where I want the emitted code to be as if I wrote it as a
> single function with branches, but want to express it with lambdas
> and function calls.
>
> If neither inlining nor macros can handle this, would it not be better
> to improve those features, instead of tacking on odd bits of grammar?
>
> I love more features and expressiveness but "if let" seems like
> something that shouldn't be baked into the compiler (even if Swift does
> it).
>
> I'm honestly asking this question, because the Rust team seems to have
> pretty good sense and reasoning, so I'm probably misunderstanding something
> and would like to know what I'm missing.
>
> Sincerely,
> Michael
> ___
> 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] Rationale on if let
`if let` acts on *any* refutable pattern, not just `Option`s. The RFC that
proposed the syntax is a good place to look for the rationale of why it was
added: https://github.com/rust-lang/rfcs/pull/160
Steven Fackler
On Sun, Oct 12, 2014 at 10:41 PM, Michael Giagnocavo
wrote:
> I came across the "if let" syntax, and it's been bothering me a bit.
>
> It seems like a strange thing to elevate to a grammar-level construct.
>
> The example given is:
> if let Some(x) = foo() {
> doSomethingWith(x)
> }
>
> What's wrong with e.g.:
>
> foo().if_some!(|x| { doSomethingWith(x) })?
>
> Can macros not step in here and allow us to write code that looks like a
> closure but doesn't actually create a closure or cost any overhead?
> (In fact, is a macro even needed? Couldn't a function and it's function
> parameters be marked for inlining - wouldn't that take care of it?) This
> seems like a handy thing to have in general. I've written code in other
> languages where I want the emitted code to be as if I wrote it as a
> single function with branches, but want to express it with lambdas
> and function calls.
>
> If neither inlining nor macros can handle this, would it not be better
> to improve those features, instead of tacking on odd bits of grammar?
>
> I love more features and expressiveness but "if let" seems like
> something that shouldn't be baked into the compiler (even if Swift does
> it).
>
> I'm honestly asking this question, because the Rust team seems to have
> pretty good sense and reasoning, so I'm probably misunderstanding something
> and would like to know what I'm missing.
>
> Sincerely,
> Michael
> ___
> 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] file logger missing?
Is a logger that synchronously writes to the filesystem and doesn't offer any type of rotation more useful than redirecting stderr? Steven Fackler On Tue, Jul 22, 2014 at 8:11 AM, Diggory Hardy wrote: > Are you saying that liblog should be moved too? Because I don't see why a > complex logging framework should be separated from a simple log-to-file > implementation (36 lines in my case, including doc, use statements, etc). > > On Tuesday 22 Jul 2014 10:49:59 Steve Klabnik wrote: > > I think in general, especially now that Cargo exists, we don't really > > need to add a lot more to the tree. Publish a package for it instead! > ___ > 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] Mutable files
Some types are implicitly copyable. They implement the built-in trait Copy.
A type is Copy if it is
a) numeric primitive (e.g. f32 or uint), or
b) an immutable reference (e.g. &Foo or &str), or
c) a raw pointer (e.g. *const Foo or *mut Foo), or
d) a collection of Copy types (e.g. struct Foo { a: int, b: &'static str }).
In addition, if a type implements Drop, it is no longer Copy.
Steven Fackler
On Sun, Jul 20, 2014 at 7:39 PM, David Henningsson wrote:
>
>
> On 2014-07-21 03:33, Patrick Walton wrote:
>
>> On 7/20/14 6:29 PM, David Henningsson wrote:
>>
>>> Hi,
>>>
>>> Consider these two examples:
>>>
>>> 1)
>>>
>>> let mut file = File::open(filename);
>>> file.read(buf);
>>>
>>> 2)
>>>
>>> let file = File::open(filename);
>>> let mut reader = BufferedReader::new(file);
>>> reader.read(buf);
>>>
>>> My question is: in example 2, why doesn't BufferedReader need "file" to
>>> be mutable? After all, BufferedReader ends up calling file.read(), which
>>> needs a mutable reference to the file.
>>>
>>> It looks like I'm able to "bypass" the mutability requirement, just
>>> because I wrap the file inside a BufferedReader?
>>>
>>
>> Because `BufferedReader::new` moves `file` and takes ownership of it.
>> (You can see this if you try to use `file` again: the compiler will
>> prevent you.) Mutability is inherited through ownership in Rust: that
>> is, the current owner determines the mutability of a piece of data. So,
>> the mutability of `reader` determines the mutability of the `File`
>> object at the time you try to read, and the mutability restriction is
>> satisfied.
>>
>
> Thanks for the quick answer!
>
> I did two more examples to try to understand when things are moved:
>
> 3)
> struct Dummy {
> foo: int,
> bar: int
> }
>
> let f = Dummy {foo: 10, bar: 5};
> let mut g = f; // Here the assignment copies..?
> println!("{}", f.foo + g.foo); // Ok
>
> 4)
>
> let f = File::open(filename);
> let mut g = f; // Here the assignment moves..?
> f.tell(); // Fails - use of moved value
>
> How come that the assignment moves in example 4), and copies in example 3)?
>
> // David
>
> ___
> 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] no error or warning when an unknown attribute is used
The unused attribute lint is actually running earlier than it should right now, which forces it to globally whitelist every attribute that's only used in trans: https://github.com/rust-lang/rust/blob/master/src/librustc/lint/builtin.rs#L563. It can't know if an attribute is unused until we've given the compiler an opportunity to use it! Steven Fackler On Wed, Jul 16, 2014 at 5:16 PM, Ben Harris wrote: > Have a quick skim over this ( > http://tomlee.co/2014/04/03/a-more-detailed-tour-of-the-rust-compiler/). > Lint is the last thing to run before conversion to LLVM. > > I'f you like to suggest it changed or augmented, the rust-lang/rust issues > board would be best. > > > On 16 July 2014 23:15, Ilya Dmitrichenko wrote: > >> On 16 July 2014 15:23, Chris Morgan wrote: >> >>> Did it come up as an unused-attribute warning? >> >> No, it didn't. >> > The simple reason it doesn't come up as an unknown attribute is >> > because it did not successfully compile, and so it did not get to the >> > step where it warns about unused attributes. >> >> Sure, it's pretty clear what's going on, but I do think it's a bit of >> a problem. It's rather hard to spot a misspelled attribute. Should >> there be a pre-lint stage for this purpose? >> ___ >> 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] Why no "@Override" analogy?
I don't see what this has to do with @Override. @Override causes the
compiler to check to make sure that the method signature matches a
supertype method. Rust always enforces that check inside of a trait
implementation block. This kind of thing is always illegal:
impl SomeTrait for Foo {
fn some_random_method_that_isnt_part_of_some_trait(&self) { ... }
}
The visitor trait is huge, and 99% of use cases don't need to visit every
possible part of the AST, so there are default implementations of all of
the methods that simply fall through to visit all of the subparts. That
comment is just saying that if you *do* want to visit everything, you have
to manually check to make sure you're overriding everything.
Steven Fackler
On Wed, Jul 16, 2014 at 11:59 AM, Christoph Husse <
thesaint1...@googlemail.com> wrote:
> This comment from "syntax::visit::Visitor" really gives me a headache:
>
> /// If you want to ensure that your code handles every variant
> /// explicitly, you need to override each method. (And you also need
> /// to monitor future changes to `Visitor` in case a new method with a
> /// new default implementation gets introduced.)
>
> I kindof thought we would have passed this :(.
> "I" need to check for future changes :O? How? Closed source 3rd party,
> just to name one example, or simply oversight. Okay, an IDE could warn
> too. But we dont' have one right now and in the past it didn't seem
> like this would have helped much.
>
> What's the rationale behind this decision?
>
> Why no: #[Impl] attribute or something?
>
> Sry, if I bring up old discussions but it was kinda hard to come up
> with a search term for this.
> ___
> 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] Impending change in RPATH behavior when linking to Rust dynamic libraries
There's a fix for make install waiting on bors right now: https://github.com/rust-lang/rust/pull/15550 Steven Fackler On Wed, Jul 9, 2014 at 1:11 PM, Ben Gamari wrote: > Brian Anderson writes: > > > Hi. > > > > Very soon now the way rustc links crates dynamically is going to > > change[1], and it will impact the way you work with Rust in some > > important cases. The TL;DR is that rustc will no longer encode RPATH > > information in the binaries it produces, so the dynamic linker will be > > less likely to find the dynamic library (.so, .dylib) dependencies; in > > some scenarios people will need to use LD_LIBRARY_PATH or rely on > > higher-level tooling to arrange for libraries to be discovered by the > > dynamic linker at runtime. > > > Perhaps I'm missing something obvious here, but this broke `make > install` in the rustc tree for me. The cause appears to be that `make > install` tries to verify that it can run the new `rustc` binary in > place, which expectedly fails due to missing libraries, > > /opt/exp/rust $ make install > ... > install: verifying platform can run binaries > /opt/exp/rust/tmp/dist/rust-0.11.0-x86_64-unknown-linux-gnu/bin/rustc: > error while loading shared libraries: libnative-4e7c5e5c.so: cannot open > shared object file: No such file or directory > install: error: can't execute rustc binary on this platform > make: *** [install] Error 1 > > Surely I don't need to mangle LD_LIBRARY_PATH just to run `make > install`? > > Cheers, > > - Ben > > ___ > 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] Drop and lifetimes
Drop implementations for types with lifetime parameters need to be tagged
with #[unsafe_destructor] because they're currently unsound in certain
situations: https://github.com/rust-lang/rust/issues/8861. The intended
semantics are what you would expect: Cursor would drop before Database.
It's something that will be fixed before 1.0. Rust-Postgres uses this kind
of lifetime setup and it works pretty well (ignoring the memory corruption
which is hackily checked for right now with a canary):
https://github.com/sfackler/rust-postgres.
You can't safely create a Thing. Cursor contains a pointer to the Database,
but the Database will move to a new location in memory when you place it
into the Thing, and every time Thing moves afterwards. All of those moves
will cause the Cursor's reference to the Database to point to stale memory.
You may be able to adjust Thing so it contains a reference to the Database
instead.
Steven Fackler
On Tue, Jul 1, 2014 at 7:35 AM, David Brown wrote:
> Imagine a hypothetical database interface:
>
>struct Database { ... }
>struct Cursor<'a> {
>db: &'a Database,
>...
>}
>impl Database {
>fn query<'a>(&'a self, ...) -> Cursor<'a> { ... }
>}
>
> Ideally, I would like both the Database, and the Cursor to implement
> Drop. The underlying database API requires the cursors to all be
> closed before the database itself is closed.
>
> My first concern is that the trend seems to be to disallow Drop on the
> Cursor (it requires #[unsafe_destructor] to compile right now).
>
> My second concern is around what seems to be to be a reasonable use of
> this:
>
>struct Thing<'a> {
>db: Database,
> q1: Cursor<'a>,
> ...
>}
>
> This would be common with the use of an SQL database, where there are
> a handful of prepared statements that get reused with different data.
> (minor other question, I can't figure out how to make a 'Thing',
> everything I've tried results in some kind of lifetime error).
>
> But, the question then becomes, what order would Drop be called when
> Thing goes out of scope?
>
> Am I missing a better way of doing all of this? I don't see 'Rc' or
> 'Gc' helping, least because they only handle an immutable value, but
> also, they are non-Send, so can't have Drop either.
>
> Thanks,
> David Brown
> ___
> 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] Error while trying to split source code into multiple files
Yep!
main.rs:
mod foo;
mod bar;
fn main() {
foo::foo();
}
foo.rs:
use bar; // this use lets you refer to the bar fn as bar::bar() instead of
::bar::bar()
pub fn foo() {
bar::bar();
}
bar.rs:
pub fn bar() {}
Steven Fackler
On Sun, Jun 1, 2014 at 5:25 PM, Nicholas Bishop
wrote:
> My intent wasn't to make bar a submodule of foo, but rather that foo &
> bar would be sibling modules (and foo just happens to use bar). Is
> there a way to do that?
>
> On Sun, Jun 1, 2014 at 6:56 PM, Steven Fackler wrote:
> > The directory layout of the project should match the module hierarchy.
> bar
> > is a submodule of foo so it shouldn't live next to foo in the filesystem.
> > There are a couple of filesystem setups that will work:
> >
> > src/
> > main.rs
> > foo/
> > mod.rs
> > bar.rs
> >
> > src/
> > main.rs
> > foo/
> > mod.rs
> > bar/
> >mod.rs
> >
> > The first configuration seems to be what most code uses. If bar ends up
> > having submodules of its own, it would need to move to the second setup.
> >
> > Steven Fackler
> >
> >
> > On Sun, Jun 1, 2014 at 3:02 PM, Nicholas Bishop <
> nicholasbis...@gmail.com>
> > wrote:
> >>
> >> Here's example code:
> >>
> >> /src/main.rs:
> >> mod foo;
> >> fn main() {
> >> foo::foo();
> >> }
> >>
> >> /src/bar.rs:
> >> pub fn bar() {
> >> }
> >>
> >> /src/foo.rs:
> >> mod bar;
> >> pub fn foo() {
> >> bar::bar();
> >> }
> >>
> >> This fails:
> >> $ rust-nightly-x86_64-unknown-linux-gnu/bin/rustc -v
> >> rustc 0.11.0-pre-nightly (064dbb9 2014-06-01 00:56:42 -0700)
> >> host: x86_64-unknown-linux-gnu
> >>
> >> $ rust-nightly-x86_64-unknown-linux-gnu/bin/rustc main.rs
> >> foo.rs:1:5: 1:8 error: cannot declare a new module at this location
> >> foo.rs:1 mod bar;
> >> ^~~
> >> foo.rs:1:5: 1:8 note: maybe move this module `foo` to its own
> >> directory via `foo/mod.rs`
> >> foo.rs:1 mod bar;
> >> ^~~
> >> foo.rs:1:5: 1:8 note: ... or maybe `use` the module `bar` instead of
> >> possibly redeclaring it
> >> foo.rs:1 mod bar;
> >> ^~~
> >> error: aborting due to previous error
> >>
> >> I tried the first suggestion (moving foo.rs to foo/mod.rs), this fails
> >> too:
> >> foo/mod.rs:1:5: 1:8 error: file not found for module `bar`
> >> foo/mod.rs:1 mod bar;
> >> ^~~
> >>
> >> The second suggestion, which I took to mean replacing "mod bar" with
> >> "use bar", also failed:
> >> brokencrate/foo.rs:1:5: 1:8 error: unresolved import: there is no
> `bar` in
> >> `???`
> >> brokencrate/foo.rs:1 use bar;
> >> ^~~
> >> brokencrate/foo.rs:1:5: 1:8 error: failed to resolve import `bar`
> >> brokencrate/foo.rs:1 use bar;
> >> ^~~
> >> error: aborting due to 2 previous errors
> >>
> >> I'm guessing that this failure is related to this RFC:
> >>
> >>
> https://github.com/rust-lang/rfcs/blob/master/complete/0016-module-file-system-hierarchy.md
> >>
> >> Unfortunately the RFC describes "a common newbie mistake" but not what
> >> a newbie might do to correct this mistake. I also looked through
> >> http://doc.rust-lang.org/tutorial.html#crates-and-the-module-system,
> >> but didn't see this question directly addressed.
> >>
> >> Thanks,
> >> -Nicholas
> >> ___
> >> 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] Error while trying to split source code into multiple files
The directory layout of the project should match the module hierarchy. bar
is a submodule of foo so it shouldn't live next to foo in the filesystem.
There are a couple of filesystem setups that will work:
src/
main.rs
foo/
mod.rs
bar.rs
src/
main.rs
foo/
mod.rs
bar/
mod.rs
The first configuration seems to be what most code uses. If bar ends up
having submodules of its own, it would need to move to the second setup.
Steven Fackler
On Sun, Jun 1, 2014 at 3:02 PM, Nicholas Bishop
wrote:
> Here's example code:
>
> /src/main.rs:
> mod foo;
> fn main() {
> foo::foo();
> }
>
> /src/bar.rs:
> pub fn bar() {
> }
>
> /src/foo.rs:
> mod bar;
> pub fn foo() {
> bar::bar();
> }
>
> This fails:
> $ rust-nightly-x86_64-unknown-linux-gnu/bin/rustc -v
> rustc 0.11.0-pre-nightly (064dbb9 2014-06-01 00:56:42 -0700)
> host: x86_64-unknown-linux-gnu
>
> $ rust-nightly-x86_64-unknown-linux-gnu/bin/rustc main.rs
> foo.rs:1:5: 1:8 error: cannot declare a new module at this location
> foo.rs:1 mod bar;
> ^~~
> foo.rs:1:5: 1:8 note: maybe move this module `foo` to its own
> directory via `foo/mod.rs`
> foo.rs:1 mod bar;
> ^~~
> foo.rs:1:5: 1:8 note: ... or maybe `use` the module `bar` instead of
> possibly redeclaring it
> foo.rs:1 mod bar;
> ^~~
> error: aborting due to previous error
>
> I tried the first suggestion (moving foo.rs to foo/mod.rs), this fails
> too:
> foo/mod.rs:1:5: 1:8 error: file not found for module `bar`
> foo/mod.rs:1 mod bar;
> ^~~
>
> The second suggestion, which I took to mean replacing "mod bar" with
> "use bar", also failed:
> brokencrate/foo.rs:1:5: 1:8 error: unresolved import: there is no `bar`
> in `???`
> brokencrate/foo.rs:1 use bar;
> ^~~
> brokencrate/foo.rs:1:5: 1:8 error: failed to resolve import `bar`
> brokencrate/foo.rs:1 use bar;
> ^~~
> error: aborting due to 2 previous errors
>
> I'm guessing that this failure is related to this RFC:
>
> https://github.com/rust-lang/rfcs/blob/master/complete/0016-module-file-system-hierarchy.md
>
> Unfortunately the RFC describes "a common newbie mistake" but not what
> a newbie might do to correct this mistake. I also looked through
> http://doc.rust-lang.org/tutorial.html#crates-and-the-module-system,
> but didn't see this question directly addressed.
>
> Thanks,
> -Nicholas
> ___
> 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] Detection of early end for Take
It may not fulfill your exact use case, but you can get this in a way:
let mut foo = bar.iter().peekable();
{
let mut limit_foo = foo.by_ref().limit(50);
for baz in limit_foo {
...
}
}
if foo.is_empty() {
...
}
Steven Fackler
On Fri, May 30, 2014 at 9:51 AM, Evan G wrote:
> Instead of using a for statement, try looping over a custom iterator that
> returns an Enum.
>
>
> On Fri, May 30, 2014 at 11:31 AM, Andrew Poelstra <
> apoels...@wpsoftware.net> wrote:
>
>> Hi guys,
>>
>>
>> Take is an iterator adaptor which cuts off the contained iterator after
>> some number of elements, always returning None.
>>
>> I find that I need to detect whether I'm getting None from a Take
>> iterator because I've read all of the elements I expected or because the
>> underlying iterator ran dry unexpectedly. (Specifically, I'm parsing
>> some data from the network and want to detect an early EOM.)
>>
>>
>> This seems like it might be only me, so I'm posing this to the list: if
>> there was a function Take::is_done(&self) -> bool, which returned whether
>> or not the Take had returned as many elements as it could, would that be
>> generally useful?
>>
>> I'm happy to submit a PR but want to check that this is appropriate for
>> the standard library.
>>
>>
>>
>> Thanks
>>
>> Andrew
>>
>>
>>
>> --
>> Andrew Poelstra
>> Mathematics Department, University of Texas at Austin
>> Email: apoelstra at wpsoftware.net
>> Web: http://www.wpsoftware.net/andrew
>>
>> "If they had taught a class on how to be the kind of citizen Dick Cheney
>> worries about, I would have finished high school." --Edward Snowden
>>
>>
>> ___
>> 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] Glob crate?
A glob crate like this one?
https://github.com/mozilla/rust/blob/master/src/libglob/lib.rs
Steven Fackler
On Mon, May 26, 2014 at 6:57 PM, Daniel Fagnan wrote:
> Writing it here to gauge an interest of the community for a glob crate. If
> it seems people are liking the idea, I'll write an RFC for it and send a PR.
>
> I'm guessing the majority of the folks here already know what it is, as
> it's pretty universal and used heavily in unix-based environments.
>
> (One *could* use a simple regex, but the interface wouldn't be the most
> ideal)
>
> Something like:
>
> ```rust
> use glob::Glob;
>
> fn main() {
> let fn globber = Glob::new(r"foo/**/*.rs");
>
> let list = vec!["foo/hello.rs", "foo/foo2/woot.rs"];
>
> match globber.match(list.get(0)) {
> // ...
> }
>
> // Or you could match all and you would get a Result> where
> // the contents of the vector are only the matched occurrences.
> globber.match_all(list);
> }
> ```
>
> Thoughts?
>
> --
> Daniel Fagnan
> Titan Analytics Inc.
> www.titananalytics.com
> M: (780) 983-4997
>
> ___
> 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] Why explicit named lifetimes?
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 wrote: > On 2014-05-16, at 7:14, 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? > > > > Type inference is local to functions, so it couldn't do that. It would > > be impossible to have libraries if inference needed to be global across > > the entire program, and the errors would be *signicantly* harder to > > understand as they would span across countless functions. > > I'm sorry, but for some reason I completely fail to understand your > explanation. > > My thinking of how the compiler would work is that whenever it compiles a > function, it would analyze it and in some sense "write in" the named > lifetimes for that function. The named lifetimes would still be explicitly > part of the signature of the function in the compiler's internal > representation of the function, but not be visible in the source code. > > ___ > 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] Removal of sigils : ~T,~[T], Box, Vec
That will be possible, but the Index trait needs to be overhauled first.
Steven Fackler
On Sun, May 4, 2014 at 3:01 PM, Brian Rogoff wrote:
> On Sat, May 3, 2014 at 2:27 AM, Artella Coding <
> artella.cod...@googlemail.com> wrote:
>
>> Hi looking at https://github.com/rust-lang/rfcs/pull/59 , is it the case
>> that the following replacement rules apply :
>>
>> 1) ~T is replaced by Box
>> 2) ~[T] is replaced by Vec
>>
>> and what does little "box" (as opposed to Box) do?
>>
>
> I have some code that makes a matrix of nested slices that looks like this
> (make_owned_slice is a helper fn)
>
> fn make_owned_slice(n: uint, default: T) -> ~[T] {
> Vec::from_elem(n, default).as_slice().to_owned()
> }
>
> fn make_matrix(nrows: uint, ncols: uint, default: T) -> ~[~[T]] {
> make_owned_slice(nrows, make_owned_slice(ncols, default))
> }
>
> Is that code going to become the following
>
> fn make_matrix(nrows: uint, ncols: uint, default: T) ->
> Vec> {
> Vec::from_elem(nrows, Vec::from_elem(ncols, default))
> }
>
> and will I be able to index matrices of Vec> like matrix[i][j]?
> Last time I checked vectors weren't indexable that way.
>
>
>
>
>>
>> When will these changes appear in the nightlies? I am using "rustc
>> 0.11-pre-nightly (e97d4e6 2014-05-01 23:41:46 -0700)" and the changes don't
>> seem to have appeared yet. Thanks
>>
>> ___
>> 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] possible code dump bug (state machine iterator)
There's an extra layer of indirection in that struct definition. A &'a fn()
is a pointer to a pointer to a function. A statement like "self_.statefn =
&finished;" expands to "let foo = finished; self_.statefn = &foo". That's
obviously creating a dangling pointer onto the stack which is why it ends
up crashing. Adjusting the struct definition to
struct StateMachineIter {
statefn: fn(&mut StateMachineIter) -> Option<&'static str>
}
should make things work as you want. There's also a bug in rustc for even
letting that program compile. I'm not sure if it's already been run into
and filed.
Steven Fackler
On Fri, Apr 18, 2014 at 8:30 AM, Ziad Hatahet wrote:
> Confirm repro on an older rustc version. Ubuntu 13.10 running rustc
> 0.11-pre (ecc774f 2014-04-11 13:46:45 -0700).
>
>
> --
> Ziad
>
>
> On Fri, Apr 18, 2014 at 4:38 AM, Phil Dawes wrote:
>
>> Hello everyone,
>>
>> I was trying to create an iterator that used a function pointer to
>> alternate between different states, and ended up core dumping. I've pasted
>> a version that generates the issue on my box (Ubuntu 12.04 LTS,
>> rust-nightly pulled just now). Can anybody reproduce this on their
>> machines? If so I'll file a bug.
>>
>> Cheers,
>>
>> Phil
>>
>> struct StateMachineIter<'a> {
>> statefn: &'a fn(&mut StateMachineIter<'a>) -> Option<&'static str>
>> }
>>
>> impl<'a> Iterator<&'static str> for StateMachineIter<'a> {
>> fn next(&mut self) -> Option<&'static str> {
>> return (*self.statefn)(self);
>> }
>> }
>>
>> fn state1(self_: &mut StateMachineIter) -> Option<&'static str> {
>> self_.statefn = &state2;
>> return Some("state1");
>> }
>>
>> fn state2(self_: &mut StateMachineIter) -> Option<(&'static str)> {
>> self_.statefn = &state3;
>> return Some("state2");
>> }
>>
>> fn state3(self_: &mut StateMachineIter) -> Option<(&'static str)> {
>> self_.statefn = &finished;
>> return Some("state3");
>> }
>>
>> fn finished(_: &mut StateMachineIter) -> Option<(&'static str)> {
>> return None;
>> }
>>
>> fn state_iter() -> StateMachineIter {
>> StateMachineIter { statefn: &state1 }
>> }
>>
>>
>> fn main() {
>> let mut it = state_iter();
>> println!("{}",it.next());
>> println!("{}",it.next());
>> println!("{}",it.next());
>> println!("{}",it.next());
>> println!("{}",it.next());
>> }
>>
>>
>> ___
>> 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] Shouldn't task::try(...).unwrap() fail to compile?
You can use task::try(...).ok().unwrap() for Results with non-Show error
types.
Steven Fackler
On Thu, Apr 17, 2014 at 8:55 AM, Edward Wang wrote:
> It current can compile, but judging from signatures:
>
> std::task::try is pub fn try(f: proc(): Send -> T) -> Result ~Any:Send>
> std::result::unwrap on the other hand is impl Result {
> fn unwrap(self) -> T {...} }
>
> There's no way the error part of result from task::try(...) can fulfil
> Show so it shouldn't compile.
>
> Though to ask the list first before filing a bug report.
>
> Regards,
> Edward
>
> ___
> 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] Is it possible to implement "extension methods" on existing traits?
You can do it like this:
impl MySerialization for T {
...
}
Steven Fackler
On Sat, Apr 5, 2014 at 12:57 PM, Frank Huang 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
Re: [rust-dev] to ! or not to !
println is a function in std::io that prints strings to standard out.
println! is a macro that allows for formatted output (e.g. println!("hello,
{}!", "world")). More details here:
http://static.rust-lang.org/doc/master/std/fmt/index.html
Steven Fackler
On Fri, Mar 14, 2014 at 2:52 PM, Renato Lenzi wrote:
> Simple question:
>
> println("hello");
>
> or
>
> println!("hello!");
>
> Why (or when) should we use one or the other form?? Differences?
>
> Regards.
>
> ___
> 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] Handling I/O errors
You can also use a nested pattern:
match reader.read(buf) {
Ok(cnt) => { /* stuff */ }
Err(IoError { kind: EndOfFile, .. } => { /* eof stuff */ }
Err(e) => return Err(e)
}
Steven Fackler
On Mon, Feb 3, 2014 at 10:32 PM, Alex Crichton wrote:
> I'd recommend one of two solutions, one is a match guard:
>
> match reader.read(buf) {
> Ok(cnt) => { /* ... */ }
> Err(ref e) if e.kind == io::EndOfFile => { /* ... */ }
> Err(e) => return Err(e)
> }
>
> and the other would be to home-grow your own macro if you find
> yourself writing the same pattern frequently.
>
> On Mon, Feb 3, 2014 at 7:25 PM, Palmer Cox wrote:
> > I like this change quite a bit. However, is there a more succinct way
> than
> > the following to take an action on EOF:
> >
> > match reader.read(buff) {
> > Ok(cnt) => {
> > // Do something
> > }
> > Err(io_error) => match io_error.kind {
> > EndOfFile => {
> > // Do something for EOF
> > }
> > _ => return Err(io_error)
> > }
> > }
> >
> > -Palmer Cox
> >
> >
> >
> > On Mon, Feb 3, 2014 at 9:19 PM, Alex Crichton wrote:
> >>
> >> > By returning a Result from all function calls, it's not much cleaner
> >> > to handle errors
> >>
> >> Oops, wrong word there, I meant to indicate that it *is* much cleaner
> >> to handle errors with Result rather than conditions.
> >> ___
> >> 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] "let mut" <-> "var"
The Zen of Python also says "There should be one-- and preferably only one --obvious way to do it." Steven Fackler On Thu, Jan 30, 2014 at 11:35 AM, Donaldo Fastoso < donquest...@rocketmail.com> wrote: > I like python's rational of "consenting adults": Give people the tools > to do the right thing, if they still want to hurt themselves, they may > have a good reason, or they are better of dead! ;-) > > I would argue, that people choosing Rust over C/C++ are choosing it > BECAUSE of safety measures like immutability and wouldn't need > overbearing lectures. > > In all honesty it's not the TYPING of three additional chars "let mut", > but the READING. It interrupts the flow of reading, or better: it's > a bump in the flow of scanning. Source-Code is not prosa, you have to > actively follow the train of thought and guess the intentions of the > author. So improving READABILITY would really be nice, especially > for people coming from other languages. They would probably try to > learn by reading the source from experienced programmers. > > In this case i would also advice against the use of "var", instead > of "let mut", but omitting "let" and leave it to "mut" would be much > easier to read and understand. > > so > "let mut x, y;" > > would become: > > "mut x;" > "let y;" > > which would take a possible interpretation-ambiguity away from the > single "let mut x, y", which can be read either as "let mut" for x > and y, or "let mut x" and "let y"! > > So imho "let mut" has at least two pitfalls: > 1) read-bump > 2) ambiguity. > > AFAIK you did a remarkable good job so far, and i have all the faith > you are considering all arguments before coming to a decision. > > Even if some thoughts of the thoughts come form the bad smelling > "lurker"-fraction, which do nothing but making comments about things they > possible can't understand! ;-) > > Regards, > Don > > ___ > 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] Compile-time function evaluation in Rust
The rough idea that pcwalton, acrichto and I were talking about when I was
working on the procedural macro stuff was to split compilation into two
phases. The first phase would produce a library that the compiler would
load for the second phase. The procedural macro PR added the `phase`
attribute which is currently only used with `extern mod` statements but
could be extended to functions and whatever else:
#[phase(syntax)]
fn ctfe_function() -> int {
10
}
static FOO: int = ctfe_function();
Steven Fackler
On Wed, Jan 29, 2014 at 11:44 AM, Niko Matsakis wrote:
> On Tue, Jan 28, 2014 at 07:01:44PM -0500, comex wrote:
> > Actually, Rust already has procedural macros as of recently. I was
> > wondering whether that could be combined with the proposed new system.
>
> I haven't looked in detail at the procedural macro support that was
> recently added, but off hand I think I favor that approach. That is,
> I'd rather compile a Rust module, link it dynamically, and run it as
> normal, versus defining some subset of Rust that the compiler can
> execute. The latter seems like it'll be difficult to define,
> implement, and understand. Our experience with effect systems and
> purity has not been particularly good, and I think staged compilation
> is easier to explain and free from the twin hazards of "this library
> function is pure but not marked pure" (when using explicit
> declaration) or "this library function is accidentally pure" (when
> using inference).
>
>
> Niko
> ___
> 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] Deriving keyword
The deriving infrastructure is implemented as a procedural macro (or syntax extension) that's built into the compiler. Historically, _all_ syntax extensions had to be built in but that is no longer the case: https://github.com/mozilla/rust/pull/11151. It's now possible to write something like #[deriving_Drawable] that will implement Drawable for types but you can't currently add new traits to #[deriving(..)] to make something like #[deriving(Clone, Drawable)] work. It would be possible to support that, but it would make #[deriving(..)] "special" in ways that other syntax extensions aren't and it's unclear whether or not that's a good idea. Steven Fackler On Thu, Jan 23, 2014 at 8:32 PM, benjamin adamson < adamson.benja...@gmail.com> wrote: > Question, what constitutes whether a 'trait' is applicable for > implementation by the #deriving() attribute? > > According to the language specification on master: > http://static.rust-lang.org/doc/master/rust.html#deriving > > There exists a static list. I found myself interested in the idea of using > the deriving attribute to derive a simple drawable implementation: > > > https://github.com/JeremyLetang/rust-sfml/blob/master/src/rsfml/traits/drawable.rs > > but then looked up the attribute in the rust manual, and noticed that > there is a static list of what I will call 'traits that support the > deriving attribute'. Why the restriction? Is there some prior reading on > this? Is there any plan on letting libraries define more types that can be > 'derivable'? > > ___ > 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] Exporting macros: #[macro_escape] usage
#[macro_export] exports macros from one crate to another (across an "extern mod" boundary). It doesn't have any effect inside of the crate in which it is defined. Steven Fackler On Sun, Jan 19, 2014 at 11:50 PM, Vladimir Matveev wrote: > I thought so :) > By the way, isn't one of the latest pull requests (the one about > loadable syntax extensions) provide a solution to this problem? It has > this particular snippet in its explanation: > > #[macro_export] > macro_rules! exported_macro (() => (2)) > > Which suggests that macros can now be exported. > > > 2014/1/20 John Clements : > > > > On Jan 11, 2014, at 12:15 AM, Vladimir Matveev wrote: > > > >> Oh, thanks. It does work now. Are macro scoping rules documented > >> somewhere except the compiler source code? > > > > As the author of the macro_escape hack: no, I don't believe it's > documented. > > > > John Clements > > > ___ > 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] NewType change in 0.9
Something like this should work:
pub fn cell_alive(&self, Row(row): Row, Column(column): Column) -> uint {
return match self.inner[row][column].value {
dead => 0,
alive => 1
};
}
Steven Fackler
On Sat, Jan 11, 2014 at 2:03 PM, benjamin adamson <
adamson.benja...@gmail.com> wrote:
> Hello Rust community!
>
> I've been busying myself over the past few weeks learning the different
> features of rust, and I have been working on an implementation of Conway's
> game of life (while trying to explore different features of rust.
>
> In 0.9, it was changed so that you cannot dereference haskell-like
> "NewTypes" with the * operator. In the 0.9 documentation, it says we can
> use pattern matching to extract the underlying type.
>
> Right here in my 0.8 code I dererenced the row parameter here:
> https://github.com/ShortStomp/ConwayGameOfLife-RUST/blob/master/grid.rs#L42
>
> which is a simple 'NewType', with underlying type uint.
>
> My question is, instead of dereferencing the 'Row' and 'Column' types, how
> can I use pattern matching here, to get the underlying uint to index the
> array with the code I just linked?
>
> Thanks in advance! :)
>
> ___
> 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] Announcing rust-openssl
There's an old open PR to optionally integrate with rust-ssl or rust-nss ( https://github.com/chris-morgan/rust-http/pull/31) but it'd need to be updated. Steven Fackler On Sun, Dec 29, 2013 at 10:12 AM, Patrick Walton wrote: > On 12/29/13 7:48 AM, Erick Tryzelaar wrote: > >> Hello everyone! >> >> I wanted to let you all know that Steven Fackler and I have merged my >> rustcrypto and his rust-ssl projects into rust-openssl, found here: >> >> https://github.com/sfackler/rust-openssl >> >> This project exposes many of the OpenSSL symmetric and PKI cryptographic >> services, and also supports wrapping a rust `std::io::Stream` with SSL. >> We still have some work to do to finish merging the projects together, >> but all the tests pass and we are registered with rust-ci. Please try it >> out and let us know if you run into any problems. >> > > Sounds like an ideal candidate for integration with `rust-http`. (Not > proposing merging the two projects, just wondering about integration.) Can > `rust-http` be made to work with a user-supplied stream? > > Patrick > > ___ > 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] Interface around SQL databases
The interface can be made generic, but it'd require HKT and potentially some more work on removing spurious conflicting trait implementation warnings. It only uses trait objects for query parameters where you actually need an array of distinct types implementing an interface. I've also found that generic SQL interfaces are less than useful in the "I can instantly swap from Postgres to SQLite with a config file toggle" sense simply because their implementations of SQL (SERIAL vs AUTOINCREMENT, etc) differ too much for it to work without a ton of pain. If anything, a generic API would be nice just to push the APIs of different SQL client libraries closer together. Someone could absolutely take the interface used by rust-postgres and make a MySQL/MariaDB driver with it, but that person wouldn't be me :) Steven Fackler On Wed, Dec 11, 2013 at 7:15 AM, Gaetan wrote: > I agree python dbapi is pretty simple to use due to the dynamic nature of > types in python. > > I like this rust postgre binding, I can't see why it cannot be extended to > support mysql? > > Actually, my main reference is sqlalchemy but it's a step much higher in > term of abstraction of the DB. > > - > Gaetan > > > > 2013/12/11 Corey Richardson > >> Python has the advantage of dynamic typing, and Go runtime type >> assertions and variadics. Their interfaces probably aren't /too/ good >> for inspiration, especially Python's. >> >> See rust-postgres (https://github.com/sfackler/rust-postgres) for an >> existing DB binding. I think it's fairly idiomatic and any DB API >> should draw inspiration from it. It leverages trait objects, though >> it's unclear that that can be generic. Personally I've never really >> been a fan of generic SQL APIs. Unless they leverage intense amounts >> of magic (Entity Framework, SQLAlchemy), I find they end up being >> crippled (luasql) or fairly uses (python's dbapi). >> >> Maybe that's just me. >> >> On Wed, Dec 11, 2013 at 9:24 AM, Gaetan wrote: >> > I'll be glad volunteering for this task, however I'm new in rust so I >> may >> > need to have some mentoring for this... >> > >> > I would be inspired by the python interface: >> > https://pypi.python.org/pypi/MySQL-python/1.2.4 >> > >> > - >> > Gaetan >> > >> > >> > >> > 2013/12/11 John Mija >> >> >> >> Before of release 1.0, it would be very good if it's added to the >> package >> >> standard a generic interface to be implemented by the packages of SQL >> >> drivers. >> >> >> >> As example, see packages "database/sql" and "database/sql/driver" in >> the >> >> Go's library: >> >> >> >> http://golang.org/pkg/database/ >> >> ___ >> >> 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] Please simplify the syntax for Great Justice
> base64.rs: >let s = [52, 53, 54].to_base64(STANDARD); > > => why adding the "standard" argument? One will ALWAYS want the "STANDARD" method of creating the base64 representation of some bytes, why not adding this argument as default. That is not true. If you are going to be putting the Base64 encoded data into a URL you're going to have to use URL_SAFE instead of STANDARD. If you're trying to send an email, you'll need to use MIME instead of STANDARD. If you're talking to a service that requires one of the ~10 other variants of Base64, you'll need to use a custom config struct. Steven Fackler On Mon, Nov 11, 2013 at 5:23 PM, Brendan Zabarauskas wrote: > On 12 Nov 2013, at 10:12 am, John Clements > wrote: > > > If you had the energy to build an alternate front-end using a > parenthesized syntax, I'm sure there are others that would give it a try. > Me, for instance! > > It would be nice if we could: > > - A: desugar Rust into a small kernel language > - B: allow rustc to take in some sort of raw AST data (not sure if that’s > already possible) > - C: have a way of outputting the AST data in a certain syntax. > > That would allow folks like me to have a nice Haskelly syntax as well as > an s-expr style! > > Heh. > > ~Brendan > > ___ > 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] Strange behavior about Writer trait
If T is a trait, its trait objects ~T, @T and &T do not implement T. There
is an implementation of Writer for @Writer, but not for ~Writer or &Writer
which is why you're seeing that error.
Steven Fackler
On Fri, Oct 18, 2013 at 11:27 PM, Oren Ben-Kiki wrote:
> Ugh, I was too optimistic. Yes, I can write my code using `MyWriter`, but
> I can't cast any @Writer (such as `io::stdout()`) to it. I guess I should
> just use `@Writer` everywhere for now :-(
>
> This raises the question of how come the compiler is smart enough to
> figure out a `@Writer` has the trait `WriterUtil`, but isn't smart enough
> to figure out a `&Writer` has the trait...
>
>
> On Sat, Oct 19, 2013 at 9:08 AM, Oren Ben-Kiki wrote:
>
>> I run into the following problem (the code below is a toy example).
>>
>> ```
>> use std::io::Writer; // Makes no difference if added/removed.
>>
>> trait PrintWithSpice {
>> fn print(&self, writer: &Writer, spice: bool);
>> }
>>
>> struct Bar {
>> bar: ~PrintWithSpice,
>> }
>>
>> impl Bar {
>> pub fn print(&self, writer: &Writer) {
>> self.bar.print(writer, false);
>> Bar::print_via_borrowed(writer, &self.bar);
>> }
>>
>> fn print_via_borrowed(writer: &Writer, data: &PrintWithSpice) {
>> // Invoking the `print` function via the borrowed pointer to the
>> `PrintWithSpice` trait:
>> // Works fine, as expected..
>> data.print(writer, true);
>> }
>> }
>>
>> struct Foo {
>> foo: bool
>> }
>>
>> impl PrintWithSpice for Foo {
>> fn print(&self, writer: &Writer, spice: bool) {
>> // Invoking the `write_str` function via the borrowed pointer to
>> the `Writer` trait:
>> // error: failed to find an implementation of trait
>> std::io::Writer for &std::io::Writer
>> // What is going on?
>> writer.write_str(format!("foo: {:b} spice: {:b}", self.foo,
>> spice));
>> }
>> }
>> ```
>>
>> I didn't understand what the compiler is complaining about. "failed to
>> find an implementation of Foo for &Foo"? A Foo is a Foo, no?
>> Calling a function via a borrowed pointer to a trait should just work (it
>> does a few lines above).
>>
>> After digging I discovered what the compiler really meant (I think). The
>> `write_str` method is defined for `WriterUtils` rather than for `Writer`.
>> So, if I replace `Writer` by `WriterUtil` in the above code, it compiles
>> fine.
>>
>> So, I ended up defining `trait MyWriter: Writer + WriterUtil` and I am
>> using that instead of `Writer` all over my code. I can see doing that as a
>> workaround, but it doesn't smell right to me.
>>
>> So:
>>
>> * Why is the compiler complaining about not finding an implementation for
>> `Writer` when the method I invoke is from `WriterUtil`?
>>
>> * Since there is an `impl for WriterUtil`, shouldn't the
>> compiler be "sufficiently smart" to deduce that the code is valid in the
>> 1st place?
>>
>> * Until the compiler is "sufficiently smart" (or, if there is a good
>> reason why it would never be), shouldn't we rename `Writer` to
>> `BasicWriter` and define `trait Writer: BasicWriter, WriterUtil {}` so
>> `&Writer` would become more usable?
>>
>
>
> ___
> 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] Should I/O use conditions?
+1 on getting rid of IO conditions. I'd be okay with a Result based API. If we change it over, we should have a tutorial that goes over how to deal with Results to make it less painful for people (e.g. using or_return! macros). I'm not a huge fan of implementing Reader for Result, etc. One thing that I've tried that I kind of like is having separate `foo` and `try_foo` methods, where `try_foo` returns a Result and `foo` is a wrapper around `try_foo` that fails with a good error message if `foo` returned Err. It makes it more explicit to users of the API what's going to happen, and when failure will occur if there's an error. A failed Result can hang around for a long time before any methods are called on it. It can also allow for slightly better failure messages. For example, if `prepare` fails, its error message can print the query string without having to copy it into a new ~str. In the IO case, you could keep this cost free to implement by having `Reader` contain a default implementation for `read` and only require users to implement `try_read`. See http://docs.octayn.net/postgres/struct.PostgresConnection.html for some examples. Steven Fackler On Wed, Oct 16, 2013 at 11:20 AM, Kevin Ballard wrote: > +1 here too. I agree with what Alex said about conditions. They're useful > for when you can actually recover from the error gracefully, but for > generic error reporting they're kind of a PITA. > > -Kevin > > On Oct 16, 2013, at 11:16 AM, Patrick Walton wrote: > > > On 10/16/13 11:02 AM, Alex Crichton wrote: > >> All that being said, we're not making much progress without an idea of > where to > >> possibly go next. Right now, the current idea is to create an Error > trait and > >> have I/O operations return Result instead of Option. This > would > >> mean that Reader/Writer and other associated traits would be defined for > >> Result where T: Trait (so you could still chain operations > easily), > >> and you could very easily check for an I/O error. > > > > +1 for the use of Result. Yay monads! > > > > Patrick > > > > ___ > > 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] Trait method self parameter type clashes with lifetime annotation required by the implementation
Foo can't really be used safely. Say that we have
struct Bar {
baz: BazPartOfBar
}
struct Foo {
bar: Bar,
baz: &'magic BazPartOfBar
}
And let's say we add a `self` syntax to allow field initializers to refer
to other fields:
let foo = Foo {
bar: Bar {
baz: BazPartOfBar
},
baz: &self.bar.baz
};
We can't really do much with Foo. If we move it, foo.baz is no longer a
valid reference, so that can't happen. We could modify foo.bar in this
case, but not if Bar were defined as
struct Bar {
baz: ~BazPartOfBar
}
since foo.baz would point to deallocated memory if we replace self.bar or
self.bar.baz.
Steven Fackler
On Sun, Sep 29, 2013 at 3:15 PM, Tim Kuehn wrote:
> Could you use struct methods for "quick access"? Or is there a reason this
> wouldn't fit your use case? Sorry, I haven't followed the whole thread
> closely.
>
> struct Owner {
> owned: ~[int],
> }
>
> impl Owner {
> fn quick_access<'a>(&'a mut self) -> &'a mut int {
> &mut self.owned[0]
> }
> }
>
>
> On Sun, Sep 29, 2013 at 5:32 PM, Oren Ben-Kiki wrote:
>
>> That's... surprising. Even ignoring the fact the name "self" means
>> exactly the opposite (déjà vu from "const" here)...
>>
>> I don't suppose there's a chance that something like what I expected
>> 'self to be like would be supported at some point? Its lack rules out a lot
>> of reasonable, safe, useful code.
>>
>>
>>
>> On Mon, Sep 30, 2013 at 12:13 AM, Gábor Lehel wrote:
>>
>>>
>>> `On Sun, Sep 29, 2013 at 9:21 PM, Oren Ben-Kiki wrote:
>>>
>>>> Thanks for the explanation. You said two key points:
>>>> - Basically, every object has a lifetime - from its creation to its
>>>> destruction - but a lifetime parameter or argument typically refers to the
>>>> lifetime of something else, which the object itself must not or does not
>>>> outlive.
>>>> And:
>>>> - 'self is not special in any way, except that the compiler has
>>>> historical baggage such that 'self is the only name it lets you use for a
>>>> lifetime parameter on a struct.
>>>>
>>>> So, 'self is indeed very far from what I thought (hoped) it would be.
>>>>
>>>> Taking these together, do I read this right as saying there is no way
>>>> whatsoever to say:
>>>>
>>>> struct Foo {
>>>> bar: Bar,
>>>> baz: &'i-live-as-long-as-the-foo-struct-and-no-more BazPartOfBar,
>>>> }
>>>>
>>>
>>> Per my understanding, this is correct. Because there is a constraint on
>>> the lifetime of a part of `Foo`, there must a constraint on the lifetime of
>>> `Foo`. It has to propagate outwards to make sure the lifetime of the whole
>>> structure is properly constrained. You basically want to "propagate
>>> inwards". I don't think that's possible, but maybe someone will correct me.
>>>
>>>
>>>>
>>>> When writing a non-trivial container, I found several user cases to be
>>>> extremely problematic. One was the above; a container held a "spine" or
>>>> "master" or "owned" or whatever-you-want-to-call-it data structure(s), plus
>>>> borrowed pointers that only live as long as the container and allow quick
>>>> access to specific parts of it.
>>>>
>>>> Is this impossible in Rust (barring use of @ or unsafe pointers)?
>>>>
>>>
>>> This sounds similar to the case of a doubly linked list (with forward
>>> pointers being the "spine" and backwards the "quick access"), which is not
>>> possible as an 'owned' structure as far as I know without unsafe pointers.
>>>
>>>
>>>>
>>>>
>>>> On Sun, Sep 29, 2013 at 8:24 PM, Gábor Lehel wrote:
>>>>
>>>>> 'self is not special in any way, except that the compiler has
>>>>> historical baggage such that 'self is the only name it lets you use for a
>>>>> lifetime parameter on a struct. But that's a bug. In the ideal platonic
>>>>> Rust in the sky, you can have any number of lifetime parameters on a
>>>>> struct
>>>>> with whatever names you prefer.
>>>>>
>>>>> The way I've found to think about lifetimes is that if you have:
>>>>
