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 < [email protected]> 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 <[email protected]> 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 [email protected] https://mail.mozilla.org/listinfo/rust-dev
