These are chat archives for rust-lang/rust

2nd
Jan 2019
Ayush Prashar
@ayushprashar
Jan 02 06:38 UTC
Hi guys
Do we have any official tool to cross compile our program for a raspberry Pi 3
Michal 'vorner' Vaner
@vorner
Jan 02 08:13 UTC
I don't think there's anything fully official, but cross was a nice tool for cross-compiling stuff. I don't know if it knows raspi-3 specifically (you might need to know the correct target tripple anyway)
aohan237
@aohan237
Jan 02 09:59 UTC
hello, i found futures 0.3 has a threadpool to run futures? does it means from version 0.3 ,i wont need tokio to run futures?
Michal 'vorner' Vaner
@vorner
Jan 02 10:08 UTC
Threadpool is just an executor. But something needs to „wake up“ the futures. Tokio is (aside from everything else) a reactor ‒ it knows how to handle network sockets, etc.
(I've also heard that the threadpool in tokio is much better in terms of performance, configurability, etc...)
aohan237
@aohan237
Jan 02 10:21 UTC
thank you,so tokio is still a must
Michal 'vorner' Vaner
@vorner
Jan 02 10:45 UTC
Some subset of it at least. But I expect some churn about responsibilities for bits of functionality after all the async-await thing lands and such.
Andrea Moretti
@axyz
Jan 02 10:49 UTC
impl<'a> Encode<VipsJpegImage<'a>> for VipsJpegImage<'a> {
    fn encode(&self, quality: u8) -> Result<VipsJpegImage<'a>, Box<Error>> {
        println!("before unsafe encode");
        let mut buf: *mut c_void = null_mut();
        let mut result_size: usize = 0;
        let img = unsafe {
            println!("before jpegsave_buffer");
            vips::vips_jpegsave_buffer(
                self.img,
                &mut buf,
                &mut result_size,
                "Q\0".as_ptr(),
                quality as i32,
                NULL_LIST,
            );
            println!("after jpegsave_buffer");
            println!(">>>>> {:#?}", result_size);
            println!(">>>>> {:#?}", CStr::from_ptr(buf as *const c_char));
            vips::vips_image_new_from_buffer(buf as *const c_void, result_size, NULL_LIST)
        };
        println!("after unsafe encode");
        result(img)
    }
}
Hi, I'm facing a segfault issue with libvips bindings. Regardless of the specific use case, I wonder if someone could point out possible issues in the code. most likely it should be something related to the mutable buf used to write the jpeg output in. If I do run the code multiple times, sometimes a jpeg actually get correctly written there, but quite often it just segfaults. So I guess there may be some source of randomness on where the memory address ends up. I saw this pattern around to pass a void pointer to C functions, but I'm not sure if it is the proper way.
(it segfaults during vips_jpegsave_buffer even before getting to the next function)
wegry
@wegry
Jan 02 14:18 UTC
image.png
I'm getting bowled over by the module system at the moment. If I have three files like this
and main depends on graph and types and graph also depends on types, is there a way to refer within graph to types without super::types::...?
Tim Robinson
@1tgr
Jan 02 14:35 UTC
That's how I would write it, or you could also do crate::types
Assuming you are doing this at the top of graph.rs:
use super::types::{MyType, MyOtherType};
wegry
@wegry
Jan 02 14:36 UTC
can you do that if it's a local module?
I kept getting a warning, one sec
Tim Robinson
@1tgr
Jan 02 14:36 UTC
On Rust 2018, yes
On Rust 2015 it would be (from graph.rs): use types::{MyType, MyOtherType};
wegry
@wegry
Jan 02 14:39 UTC
Alright, so if I'm trying to refer to stuff in renderer from main, can I not use use the same way in Rust 2018?
imports can only refer to extern crate names passed with --extern on stable channel (see issue #53130)rustc(E0658)
for
mod renderer;
use renderer::{LinkedNode, Node};
@1tgr
Tim Robinson
@1tgr
Jan 02 14:40 UTC
mod renderer;
use self::renderer::{LinkedNode, Node};
wegry
@wegry
Jan 02 14:40 UTC
thank you so much
Been beating my head against this for a while ;)
Julian Didier
@theredfish
Jan 02 15:13 UTC

Hello :)
My question is also related to Rust 2018. I'm just trying to understand why it doesn't work :

| - main.rs
| - foo
     | - foo.rs
     | - bar.rs

From main.rs :

mod foo;

The compiler give me this message name the file either foo.rs or foo/mod.rs inside the directory "src" but giving the documentation i can rename mod.rs by foo.rs.

Michal 'vorner' Vaner
@vorner
Jan 02 15:14 UTC
Yes, but it is meant as src/foo.rs, not src/foo/foo.rs
Julian Didier
@theredfish
Jan 02 15:15 UTC
oh well, I need to organize my project like that?
| - main.rs
| - foo.rs
| - foo
     | - bar.rs
No, it doesn't make sense ^^
Michal 'vorner' Vaner
@vorner
Jan 02 15:16 UTC
Yes. Or the original src/foo/mod.rs also works.
Julian Didier
@theredfish
Jan 02 15:16 UTC
Srly ! haha ok...
I wonder if this new mods organization is really clear? I mean... folders are here to organize things, but here we are moving these things out of them. mod.rs seems to be better in this case for me :)
Maybe i'm missing the point ^^
Thanks for the help
Michal 'vorner' Vaner
@vorner
Jan 02 15:26 UTC
Some people are used for the other way. Like, if you come from perl, it uses supermodule.pm, supermodule/submodule.pm. But keep using mod.rs if you like.
Julian Didier
@theredfish
Jan 02 15:28 UTC
Ok I see :) thx
Sergey Nikolaev
@qvantor
Jan 02 17:55 UTC
struct Foo {
    collection: Bar,
}

let obj = Foo {
            bar: Bar::new()
}

For example, I have Foo, which contains Bar
Bar has a method add
And i want to Foo.add, was equivalent to call Foo.bar.add
Like Foo extends Bar in OOP languages.
How to achieve that?

Trait is fit to my functionality, but inside trait i can't use types, only functions :(

pub trait Addible {
// can i add something like this trait SHOULD contain {collection: Bar}
// and use construction like below
    fn add(&self, object: Object) -> &Self {
        &self::collection::add(object)
    }
}
David O'Connor
@David-OConnor
Jan 02 23:12 UTC
Does anyone know why we can't use type aliases for generic types? It seems like most of the longer 'types' I make (eg would benefit from a type alias) include them
Isobel Redelmeier
@iredelmeier
Jan 02 23:13 UTC
@David-OConnor do you mean like type X<T> = Y<T>? that should work
David O'Connor
@David-OConnor
Jan 02 23:17 UTC
Thanks Iso - you're spot on!
Isobel Redelmeier
@iredelmeier
Jan 02 23:31 UTC
no problem!