Re: [rust-dev] master's project work on rust - ideas
Bumping this, because my deadline for choosing a master's project is 25th. Would appreciate it if somebody could give me a brief answer about my concerns with regards to the runtimeless rust thing, at least. If I am unclear please ask for clarifications. It's mainly about getting help with formulating a set of targets (bundle of issues) given my resources so i can submit a proposal. If I can't do that in the time left, I will have to choose something else. Many thanks, Dan On Thu, Oct 17, 2013 at 11:04 AM, Dan Cristian Octavian danoctavia...@gmail.com wrote: Hello, I've spend some time looking at proposed master's projects by my uni to understand how this one compares and to understand the time resources that I have available (roughly 3 months of solid work and roughly 3 months of part-time during term-time work until project submission deadline, of course i could continue working afterwards to get things done ): Correct me if I'm wrong on the following: the main issues about runtimeless rust are: * supporting std functionality (to various degrees depending on the environment) * the stacks issue One of my concerns is that suppose I choose to do this, it's part of an active development effort and the aforementioned issues seem to be connected to many other problems (the stack problem) and it's kind of hard to just crop a big issue out and say yup this is a standalone project, you go do it. I am just worried I will have a hard time saying I've done this and I will only be able to say I've been a contributor to Rust for a while working mainly on this and that doesn't add up to be a master's project. I would really like to work on this, though. Do you think it can be formulated as a set of targets that are useful to the Rust project (they are actually used) and at the same time constitute a valid master's project? Would picking an issue that is milestoned for after 1.0 release be a good cure for this problem since their are not as interconnected with currently developed features? I've browsed through the interesting-project tagged issues. Aside from runtimeless I was interested in the following: compile time stack size https://github.com/mozilla/rust/issues/4389 proper REPL https://github.com/mozilla/rust/issues/9898 parallel multi-crate compiler driver https://github.com/mozilla/rust/issues/3431 sandboxing for tasks on linux https://github.com/mozilla/rust/issues/6811 But there's also the issue of having something sizeable enough. Again any suggestions welcome. Many thanks, Dan On Tue, Oct 1, 2013 at 12:07 PM, Alex Crichton a...@crichton.co wrote: One of my first thoughts when I saw the Rust project was to make it runtimeless. Shortly after that was achieved rather trivially with zero.rs. I don't know if any major improvement can be done there. As others have said, I don't believe that Rust is currently at the point of being runtimeless. In addition to what Brian mentioned about not being able to use core-language features easily (vectors, strings, convenient I/O), the story of stacks is also a little sad in runtimeless rust. Currently a runtimeless program is still forced to link to librustrt along with our own libmorestack to provide the __morestack function needed by LLVM's segmented stacks. It always seemed a little silly to me that runtimeless rust still links to the runtime... Various bits of discussion can be found on https://github.com/mozilla/rust/pull/8955 https://github.com/mozilla/rust/issues/8345 But in summary the story of how stacks are allocated is currently not sufficient for writing something like a kernel module or a kernel itself. I do believe that this is certainly within the realm of possibility, but it certainly needs to be done carefully. I'm not sure if it's too small of a master's project, but I personally consider this to be a fairly substantial undertaking to get right. The various modes discussed in those two issues would be useful to have. This also may not be limited to a runtimeless rust, because the current stack situation is a bit in flux with rust currently. Our segmented stacks are disabled in the new runtime (not implemented yet) and there's some unease about the fixed_stack_segment macro and how it can be more useful. For reference, here's some issues: Runtimeless rust: https://github.com/mozilla/rust/issues/3608 newsched segmented stacks: https://github.com/mozilla/rust/issues/6844 revised stack attributes: https://github.com/mozilla/rust/issues/8822 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] master's project work on rust - ideas
Hello, I've spend some time looking at proposed master's projects by my uni to understand how this one compares and to understand the time resources that I have available (roughly 3 months of solid work and roughly 3 months of part-time during term-time work until project submission deadline, of course i could continue working afterwards to get things done ): Correct me if I'm wrong on the following: the main issues about runtimeless rust are: * supporting std functionality (to various degrees depending on the environment) * the stacks issue One of my concerns is that suppose I choose to do this, it's part of an active development effort and the aforementioned issues seem to be connected to many other problems (the stack problem) and it's kind of hard to just crop a big issue out and say yup this is a standalone project, you go do it. I am just worried I will have a hard time saying I've done this and I will only be able to say I've been a contributor to Rust for a while working mainly on this and that doesn't add up to be a master's project. I would really like to work on this, though. Do you think it can be formulated as a set of targets that are useful to the Rust project (they are actually used) and at the same time constitute a valid master's project? Would picking an issue that is milestoned for after 1.0 release be a good cure for this problem since their are not as interconnected with currently developed features? I've browsed through the interesting-project tagged issues. Aside from runtimeless I was interested in the following: compile time stack size https://github.com/mozilla/rust/issues/4389 proper REPL https://github.com/mozilla/rust/issues/9898 parallel multi-crate compiler driver https://github.com/mozilla/rust/issues/3431 sandboxing for tasks on linux https://github.com/mozilla/rust/issues/6811 But there's also the issue of having something sizeable enough. Again any suggestions welcome. Many thanks, Dan On Tue, Oct 1, 2013 at 12:07 PM, Alex Crichton a...@crichton.co wrote: One of my first thoughts when I saw the Rust project was to make it runtimeless. Shortly after that was achieved rather trivially with zero.rs. I don't know if any major improvement can be done there. As others have said, I don't believe that Rust is currently at the point of being runtimeless. In addition to what Brian mentioned about not being able to use core-language features easily (vectors, strings, convenient I/O), the story of stacks is also a little sad in runtimeless rust. Currently a runtimeless program is still forced to link to librustrt along with our own libmorestack to provide the __morestack function needed by LLVM's segmented stacks. It always seemed a little silly to me that runtimeless rust still links to the runtime... Various bits of discussion can be found on https://github.com/mozilla/rust/pull/8955 https://github.com/mozilla/rust/issues/8345 But in summary the story of how stacks are allocated is currently not sufficient for writing something like a kernel module or a kernel itself. I do believe that this is certainly within the realm of possibility, but it certainly needs to be done carefully. I'm not sure if it's too small of a master's project, but I personally consider this to be a fairly substantial undertaking to get right. The various modes discussed in those two issues would be useful to have. This also may not be limited to a runtimeless rust, because the current stack situation is a bit in flux with rust currently. Our segmented stacks are disabled in the new runtime (not implemented yet) and there's some unease about the fixed_stack_segment macro and how it can be more useful. For reference, here's some issues: Runtimeless rust: https://github.com/mozilla/rust/issues/3608 newsched segmented stacks: https://github.com/mozilla/rust/issues/6844 revised stack attributes: https://github.com/mozilla/rust/issues/8822 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] master's project work on rust - ideas
Hello, I will be working on my master's degree individual project this year and I was very interested in picking up a Rust-related project. The purpose of this email is to ask for suggestions/proposals for Rust related work that could be done in the context of such a project. I've been following the rust project for quite a while, but didn't find the time to contribute. I noticed that the task to build the interpreter was picked up in a similar fashion. One of my first thoughts when I saw the Rust project was to make it runtimeless. Shortly after that was achieved rather trivially with zero.rs. I don't know if any major improvement can be done there. Other ideas I had are in the style of build X (library/kernel/etc.) with Rust. I don't know how relevant this is. Please let me know if you have suggestions. Many thanks, Dan ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] possible bug in net_tcp upon socket reading
Hi,
Is this a bug or am i doing something wrong?
i am calling net_tcp::listen with the following callback for
new_connect_cb, and when sending data from the client through the socket, i
get a ***stack smashing detected*** error.
|newConn, kill_chan| {
debug!(new conn);
task::spawn_sched (task::ManualThreads(1u), || {
debug!(this is the spawned task running);
let mut acceptRes = net_tcp::accept(newConn);
match acceptRes {
result::Ok(tcpSocket) = {
let socketBuf = net_tcp::socket_buf(tcpSocket);
debug!(accepted connection);
socketBuf.read_byte();
debug!(read byte);
socketBuf.write(str::to_bytes(yellow));
debug!(wrote to socket);
}
result::Err(_) = error!(failed to accept socket
connection)
};
};
What couid be the problem? Thank you.
D
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
