Is there currently any way to daemonize a process in Linux? I was using the
`daemon` function in C: http://man7.org/linux/man-pages/man3/daemon.3.html.
I asked in the IRC but I didn't get a response.
___
Rust-dev mailing list
Rust-dev@mozilla.org
On 08/07/14 23:47 -0700, Gulshan Singh wrote:
Is there currently any way to daemonize a process in Linux? I was using the
`daemon` function in C: http://man7.org/linux/man-pages/man3/daemon.3.html.
I asked in the IRC but I didn't get a response.
There's going to be excitement with this, mostly
Additionally, I'd like to note that modern best practice is to relay this
on the init process itself. With modern init systems, such as systemd or
launchctl, this works very nicely and application developer doesn't have to
care about daemonisation and logging is also done simply via stdout.
On 9
Is the following error cause by this change?
% rustc -v
dyld: Library not loaded:
x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib/librustc-4e7c5e5c.dylib
Referenced from: /Users/ilya/Library/Local/Rust/current/bin/rustc
Reason: image not found
Trace/BPT trap
On 9 July 2014
Consider the following docs:
/// Foo
///
/// ```rust
/// under_test();
/// ```
pub fn under_test() {
}
doing `rustdoc main.rs --test` produces:
jeff@jeff-mbp:~/src/rust-intro-presentation/Jun2014$ rustdoc main.rs --test
running 1 test
test foo::under_test_0 ... FAILED
failures:
It is indeed! You'll need to ensure that
`/Users/ilya/Library/Local/Rust/current/lib` is in your
DYLD_LIBRARY_PATH environment variable for OSX.
On Wed, Jul 9, 2014 at 6:25 AM, Ilya Dmitrichenko
errordevelo...@gmail.com wrote:
Is the following error cause by this change?
% rustc -v
dyld:
Doc tests are compiled as if they were clients of a library, so you'll
have to write the test assuming the rest of the source was built with
`--crate-type lib` and then import it directly.
For example, you may have to do this:
```rust
main::under_test();
```
Doc test aren't really designed with
Hi,
This piece of code,
#![feature(phase)]
#[phase(plugin)]
extern crate green;
use std::io::timer;
use std::task::TaskBuilder;
green_start!(main)
fn main() {
for _ in range(0, 1i) {
TaskBuilder::new().stack_size(20*1024).spawn(proc() {
timer::sleep(2)
});
}
}
fails with,
task
By default, each stack is allocated with a red zone at the end for
running code on stack overflow, calling C functions, etc. The current
size of the red zone is 20K.
Requested stack sizes are always at least 20K, but the 20K is not
currently added to the stack size. So for your test case when you
Thanks a lot.
After about an hour of searching around, I found the RED_ZONE in stack.rs
--
Chandra Sekar.S
On Wed, Jul 9, 2014 at 8:36 PM, Alex Crichton a...@crichton.co wrote:
By default, each stack is allocated with a red zone at the end for
running code on stack overflow, calling C
On 7/9/14 7:42 AM, Bob Ippolito wrote:
This seems like madness. No other programming language out there that
I've seen requires developers to mangle these environment variables.
Note that rpath never worked on Windows [1], so it could never be a
long-term solution.
Patrick
[1]:
On Wed, Jul 9, 2014 at 9:29 AM, Patrick Walton pcwal...@mozilla.com wrote:
On 7/9/14 7:42 AM, Bob Ippolito wrote:
This seems like madness. No other programming language out there that
I've seen requires developers to mangle these environment variables.
Note that rpath never worked on
On 7/9/14 7:42 AM, Bob Ippolito wrote:
This seems like madness. No other programming language out there that
I've seen requires developers to mangle these environment variables.
Also, when installing Rust you don't have to mangle these environment
variables, since the libraries will be placed
On Wed, Jul 9, 2014 at 9:48 AM, Patrick Walton pcwal...@mozilla.com wrote:
On 7/9/14 7:42 AM, Bob Ippolito wrote:
This seems like madness. No other programming language out there that
I've seen requires developers to mangle these environment variables.
Also, when installing Rust you don't
Other programming languages do this. C and C++ do not mandate the use of
RPATH, and Rust not applying RPATH by default doesn't exclude people
opting into it if they want. In this context I am also considering
@executable_path and @loader_path to be 'RPATH', and in fact
@loader_path is the
Brian Anderson bander...@mozilla.com 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,
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 bgamari.f...@gmail.com wrote:
Brian Anderson bander...@mozilla.com writes:
Hi.
Very soon now the way rustc links crates
I ran stats on the type parameters on Rust's master branch.
(I was dumb and only sent this to Ben Striegel last time. My fault for
not knowing how to use an email client.)
On 06/30, Benjamin Striegel wrote:
Whether or not we want something like this, I'd be fascinated if someone
managed to
18 matches
Mail list logo
