Re: [rust-dev] Daemonizing a process

Alex Crichton helped me figure out a solution: use std::io::Command; use std::os; use std::io::timer::sleep; fn main() { let args = os::args(); if args.len() == 1 { let child = Command::new(args.get(0).as_slice()) .arg("child") .detached().spawn().unwrap();

Re: [rust-dev] C++ to Rust - Is that about right?

> pick up the general style just by reading "generic" material. Whether > they'll be sold on it is another question... Well that's the point ;). They will often not be sold because the initial time you need to invest to understand and appreciate rusts "novel" choices will be too high. Just think a

Re: [rust-dev] C++ to Rust - Is that about right?

Re-CCing list because you don't seem to have dropped it intentionally and I'd prefer more experienced people to shout at me if I say something wrong. On Tue, Jul 15, 2014 at 5:25 AM, Christoph Husse wrote: > > > you're thinking in one paradigm exclusively while using in a multi-paradigm > > Well

Re: [rust-dev] robots.txt prevents Archive.org from storing old documentation

Its not about "special casing a user agent" its about archiving duplicate copies of old documents. Right now, everything is crawled off of the current docs, and none of the archived docs are allowed. with this change, the IA would store multiple copies of old documentation—once as the "old" entry f

Re: [rust-dev] robots.txt prevents Archive.org from storing old documentation

On 07/14/2014 09:56 PM, Chris Morgan wrote: > On Tue, Jul 15, 2014 at 4:16 AM, Brian Anderson wrote: >> Can somebody file an issue described exactly what we should do and cc me? > > Nothing. Absolutely nothing. > > robots.txt rules do not apply to historical data; if archive.org has > archived s

Re: [rust-dev] robots.txt prevents Archive.org from storing old documentation

On Tue, Jul 15, 2014 at 4:16 AM, Brian Anderson wrote: > Can somebody file an issue described exactly what we should do and cc me? Nothing. Absolutely nothing. robots.txt rules do not apply to historical data; if archive.org has archived something, the introduction of a new Disallow rule will no

Re: [rust-dev] How to get the file descriptors of standard I/O types?

I'm writing for the Raspberry Pi, so cross-compiling to ARM Linux. --Nat www.natpryce.com On 15 Jul 2014, at 00:18, Ilya Dmitrichenko wrote: Are you working on a project targeting MCUs or Linux? If MCUs, I'd strongly encourage you to join the efforts on Zinc (http://Zinc.rs)! On 14 Jul 2014 23

Re: [rust-dev] How to get the file descriptors of standard I/O types?

Are you working on a project targeting MCUs or Linux? If MCUs, I'd strongly encourage you to join the efforts on Zinc (http://Zinc.rs)! On 14 Jul 2014 23:15, "Nat Pryce" wrote: > I'm currently using the native API to implement new I/O abstractions for > GPIO, I2C, etc. But really want to combine

Re: [rust-dev] How to get the file descriptors of standard I/O types?

I'm currently using the native API to implement new I/O abstractions for GPIO, I2C, etc. But really want to combine them with the existing File and socket APIs. I've had to copy code from the native runtime library to convert native errors to IoError, which makes me uncomfortable. What's the URL

Re: [rust-dev] How to get the file descriptors of standard I/O types?

Nat, I would very much appreciate if you join the discussion on my pull request. There is also a link to the Stack Overflow answer I got earlier, it describes how you can get the file descriptor form a lower layer `libnative` API... On 14 July 2014 22:26, Nat Pryce wrote: > Are there plans to be

Re: [rust-dev] How to get the file descriptors of standard I/O types?

Are there plans to better link the standard I/O APIs and the platform's native I/O? For example, to control devices (on Linux often done by ioctl, which needs a file descriptor), use non-IP protocols (on Linux, different socket families, return a file descriptor), multiplex I/O events, etc. --Nat

Re: [rust-dev] Next week's older RFCs

On 07/10/2014 05:48 PM, Nick Cameron wrote: Hi, here are the recommendations for discussion at next weeks meetings. There is a new section of RFCs which are ready for discussion but discussion has been postponed because we're waiting on a key person for that RFC to be present. This is mostly f

Re: [rust-dev] C++ to Rust - Is that about right?

On 14/07/14 03:33 PM, Robin Kruppe wrote: > > Second, the signature of MyClass::new() in your example is... unusual. > The return type unnecessarily narrow (returns a trait object instead of > the concrete type, even though callers have to know the concrete type > anyway to call new()) and does a

Re: [rust-dev] How to get the file descriptors of standard I/O types?

There is not currently a method of doing so through the `std::io` apis. While possible through the rustuv and native apis, I would discourage manual use of those crates as they have experimental and volatile APIs. You may be interested in https://github.com/rust-lang/rust/pull/15643 which may add

Re: [rust-dev] C++ to Rust - Is that about right?

Two things I noticed: This organization, or at least the way you present it, makes the most sense when treating classes as your primary and (almost) only design element ("Kingdom of nouns"). While this is certainly a valid design paradigm, and Rust should support it rather well, focusing on it is

Re: [rust-dev] C++ to Rust - Is that about right?

On 14/07/14 02:45 PM, Christoph Husse wrote: > > Now I can hear the screams already :D. So I want to explain a bit > about this choice. > > First, I find the rust source code I looked at so far pretty > unstructured and confusing. Everything seems to be defined somewhere > at will, without having

[rust-dev] C++ to Rust - Is that about right?

Hi, I am just starting to think I have wrapped my mind around this type system shift introduced by rust. Now I just want to confirm that view to make sure I haven't missed something important. Declaring a C++ class in rust: # // MyMod/mod.rs - One monolythic file of all

[rust-dev] How to get the file descriptors of standard I/O types?

Hi. I want to use the existing I/O types (files, sockets, etc.) with epoll. Is there an API call to get hold of their file descriptors? --Nat -- http://www.natpryce.com ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/

Re: [rust-dev] robots.txt prevents Archive.org from storing old documentation

Can somebody file an issue described exactly what we should do and cc me? On 07/14/2014 01:13 AM, richo wrote: On 10/07/14 17:15 +, Ivan Kozik wrote: On Thu, Jul 10, 2014 at 3:49 PM, Jonas Wielicki wrote: While this is a good thing /all/ software projects should be doing imo, one could st

Re: [rust-dev] Invoking rustc as crate?

On 07/13/2014 12:10 AM, Christoph Husse wrote: Hi, I successfully managed to hook into the compiler so far. Or well it's not that successful, because it doesn't work, but at least the code is there ;). Now I am trying to compile an empty file, and it gives me the weird error: "error: can't fi

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

On 07/11/2014 12:09 PM, Zoltán Tóth wrote: On Wed, Jul 9, 2014 at 12:57 AM, Brian Anderson > wrote: # Impact Installing rustc to non-default locations will result in an installation that puts some important libraries in a location the dynamic li

Re: [rust-dev] Rust Guidelines

Indeed I did, but that was back before I understood pretty much anything about Rust :). It seems to use the compiler too so that might be a great starting point for me and a chance to merge efforts. I will look into it! Thanks. On Mon, Jul 14, 2014 at 5:43 PM, Nat Pryce wrote: > Have you looked

Re: [rust-dev] Rust Guidelines

I meant code formatting, not code completion xD On Mon, Jul 14, 2014 at 3:12 PM, Christoph Husse wrote: > I looked at this tool already, but it has a complementary approach > (which definitely is needed in addition anyway). I want to base code > completion entirely on the compiler, which means it

Re: [rust-dev] Rust Guidelines

I looked at this tool already, but it has a complementary approach (which definitely is needed in addition anyway). I want to base code completion entirely on the compiler, which means it will only work for something the compiler can get analaysis to pass on. But on the other hand it will be absolu

Re: [rust-dev] Rust Guidelines

On Mon, Jul 14, 2014 at 1:24 AM, Christoph Husse < thesaint1...@googlemail.com> wrote: > Hmm I am actually trying to make one as first step towards accurate > code completion and refactoring. But I have never done that before so > I can't promise anything :D. > > On Mon, Jul 14, 2014 at 1:12 AM, S

Re: [rust-dev] robots.txt prevents Archive.org from storing old documentation

On 10/07/14 17:15 +, Ivan Kozik wrote: On Thu, Jul 10, 2014 at 3:49 PM, Jonas Wielicki wrote: While this is a good thing /all/ software projects should be doing imo, one could still explicitly allow Archive.org by prepending: User-agent: ia_archiver Disallow: ? It looks like doc