Thanks for your input! It sounds like one thing we can definitely agree that rustc isn't ready for a rusti-like tool to work 100% today.
> I knew that pretty printing history into a big list of strings was a bad way > for it to work, but there was no other way to make it work at the time. Each > compiler instance (i.e. every time a line was inputted) had to be run on a > separate task every time, so the history had to be sendable. A better > alternative would have been to store the history as AST (so it didn't need > to be parsed each time, only compiled), but that wasn't sendable. As far as > I know, each compiler instance no longer needs to be on a separate task so > this could probably be used instead now. I'll respond to Lindsey here as well. I think that this is one main reason that rusti can't work in today's model. There's no way getting around running rustc in a separate task from rusti, which implies that everything has to be sendable. This means that you can't have any "local variables" in rusti which are @ (assuming that there's some saved local state between lines of input). > In my opinion, rusti gets the job done. Yes, having in-memory compiled state > would work a lot better. But I don't know how viable that is. I know for a > fact that a big feature plan is to have the compiler only partially compile > when applicable, i.e. only compile things are actually important. That would > help drastically here. For me, if I use rusti I expect to get all of rust and everything that entails. Sadly, rusti only gives you certain portions right now, and to me that doesn't cut it for being a core tool that rust provides. That being said, if the compiler did partially compile and have a lot of extra options, I can see how a true rusti would be much more plausible. For now though, I think that a reasonable course of action would be to remove rusti, leverage rustpkg to install rusti once rustpkg is working, and then continue to update it with the compiler. In theory it could be re-integrated back into the tree once the compiler supports it, but I think the idea of it being a separate installable package would also be a good idea long term. To me this is a much more preferable solution than "half a rusti waiting for the compiler to change." > And no-no-no, I think removing the JIT backend is a really bad idea. That > sort of thing is really useful and removing it now is not going to be > productive. There has been much work from the community recently to improve > rusti and the JIT compiler. I think once Mozilla setup automated testing of > the JIT compiler it could easily be polished and have all tests green under > it, which would be great. I definitely don't mind leaving it in, it's not too much extra code to maintain. It's just something that I'd want to be sure was kept around for a good reason. Currently the way that it's used, it's not clear to my why it doesn't just write the binary somewhere and run it externally instead of running it in-process (although that only applies to current use-cases). That being said though, there is automated testing for the JIT right now (I added it), and I've also been fixing it for various platforms (x86 mainly). I think the JIT is much more robust than rusti because right now the only bug is that task failures in JIT code are completely broken, but probably has to do with LLVM anyway. Regardless, I still think that rusti should be removed: * It's a fair amount of code to maintain and keep up with all the giant language changes * It's not the tool that you would expect it to be. Under a minute of interaction with it will convince you of that. Not only that, but even if you include all my un-landed patches to help rusti, I can still think of many examples which run different in rusti than rustc. If a tool is distributed by the main rust distribution, I would expect it to be of the same quality as the rest of the tools distributed (in terms of what it does when I throw input at it). This is my major reason for thinking that rusti should be dropped for now, and I think that if it were dropped rusti shouldn't be a part of the tree until these issues are mitigated. Again though, these issues may be able to be mitigated right now and I'm just unaware! * If it's just "waiting for rustc to evolve", it can do that outside the main rust tree (this shouldn't affect how rustc evolves, it should have the same goals). It doesn't sound like this is really happening in the near future at all. The changes necessary to make rusti only perhaps plausible sound like major architectural changes to the compiler (I could be wrong), so waiting in tree seems a bit infeasible. All that being said, I'll definitely take a look at cling (thanks Lindsey!). I would imagine that there are many similar problems in a JIT for C++ as there is for Rust. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
