Re: Bootstrapping community (Re: [arch] The Third Way : C/C++ and Java and lets go forward)
we are talking cross-purposes...i can't keep up with all the traffic. Are u sure, you haven't missed a nugget of information here and there? Am not saying that you should not pick Jam. Pick jam, but there are others who are willing to help and willing to write code and have contributions to bring in. *PLEASE* bring them in sooner than later. You know how bloody long it takes us to do the paperwork and get the infrastructure work done. Let's have the discussions on the mailing list. Document them say using java interfaces in SVN. Put up information on the wiki to back up the discussions. Let folks write some non-trivial code that is needed eventually but does not hinder your kernel work/discussions. For example, someone was going to write a javac wrapper for jdt. How do know which pieces of information on the mailing list you considered for taking a decision. and someone may use a totally different set of points made on the mailing list for taking the opposite decision. We need to document those in the design docs and/or wiki. Call me today and we can chat a bit more. thanks, dims On 5/23/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > On May 23, 2005, at 11:03 PM, Davanum Srinivas wrote: > > > Geir, > > > > Am not sure u understood where i am coming from. (I feel that u saying > > that we are not going to get commit privs for folks interested till > > the design discussions are over AND that design decisions are going to > > be made on the mailing list ONLY?) > > Huh? I don't understand that. > > What I want to do is start getting people working and committing, but > *also* getting some of the sophisticated design work done. I think > that we can drive one from another and vice-versa. By having a > little kernel-thingy (I won't call it "core" because after talking to > Steve, it's clearly a matter of semantics) that's for our > prototyping and learning, we can start working with the > modularization, which as I understand it, is a current topic in VM > research. > > Yes, I'm hoping the design decisions are made on the list, btw. :) > > > > > I have trouble keeping up with the mailing list and so do others...am > > not saying that we have to check-in code from all the seed VM's into > > our repo. I want to keep the momentum going by getting committers on > > board, letting them share thoughts, documents and code if any (SVN > > repo?), may be use JIRA to document requirements etc. Right now no one > > knows who is going to be working and on what and how to contribute > > etc. > > Yes - that's the entire point of what I'm trying to do :) > > > > > As stefano says - "good ideas and bad code build communities, the > > other three combinations do not"Let's build the community without > > waiting for the discussion to end on the mailing lists and let the > > committers/community decide on how best to move forward. We don't > > (mentors) have to pick the "winner"? do we? > > There's no "winner". LIke I said, this isn't about blessing one > thing as the solution. > > We aren't going to just take something from outside and say "done". > What I wanted is code to experiment with and adapt to what *we* > design. We can add things from elsewhere as the design require (like > modularize parts of JikesRVM, which I understand needs to be done...). > > Look at Jam. My understanding is that it sorta works, and it's very > simple. It sounds like it's easy to refactor to a small, kernel- > thingy that will be a basis of support for moving forward w/ the > modularity. And then we can throw it out :) or not. Whatever we > discover. I think we're going to learn a lot here. > > geir > > (And while I'm a mentor, I'm also a participant :) > > > > > > Thanks, > > dims > > > > On 5/23/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > >> > >> On May 23, 2005, at 9:54 PM, Davanum Srinivas wrote: > >> > >> > >>> Geir, > >>> Am convinced that we can write a JVM in pure java with minimal C/C > >>> ++. > >>> > >> > >> Why? If it has C/C++, it's not pure Java. Period. > >> > >> This isn't about whether or not that it can be done in Java, or a way > >> to get it into C/C++. Lets get over that misconception right now. > >> I'm sure that major parts can be done in Java - it's been > >> demonstrated by JikesRVM, and lots of experienced VM people point in > >> that direction, even with a C/C++ core. I have no problem with that. > >> > >> > >>> How about we poll the VM candidates on who wants to help seed the > >>> project, ask them to do the paperwork, then we can get folks on > >>> board > >>> as committers and let them play in sandboxes (see below). Folks > >>> who do > >>> the work will then get to decide the future direction. We don't have > >>> to make the technical decision now before the committers are on > >>> board. > >>> What do you think? > >>> > >> > >> I don't see what we gain. We want to create *our design*, not make > >> "frankenVM". The point of starting with a small seed C/C++
Re: Bootstrapping community (Re: [arch] The Third Way : C/C++ and Java and lets go forward)
On May 23, 2005, at 11:03 PM, Davanum Srinivas wrote: Geir, Am not sure u understood where i am coming from. (I feel that u saying that we are not going to get commit privs for folks interested till the design discussions are over AND that design decisions are going to be made on the mailing list ONLY?) Huh? I don't understand that. What I want to do is start getting people working and committing, but *also* getting some of the sophisticated design work done. I think that we can drive one from another and vice-versa. By having a little kernel-thingy (I won't call it "core" because after talking to Steve, it's clearly a matter of semantics) that's for our prototyping and learning, we can start working with the modularization, which as I understand it, is a current topic in VM research. Yes, I'm hoping the design decisions are made on the list, btw. :) I have trouble keeping up with the mailing list and so do others...am not saying that we have to check-in code from all the seed VM's into our repo. I want to keep the momentum going by getting committers on board, letting them share thoughts, documents and code if any (SVN repo?), may be use JIRA to document requirements etc. Right now no one knows who is going to be working and on what and how to contribute etc. Yes - that's the entire point of what I'm trying to do :) As stefano says - "good ideas and bad code build communities, the other three combinations do not"Let's build the community without waiting for the discussion to end on the mailing lists and let the committers/community decide on how best to move forward. We don't (mentors) have to pick the "winner"? do we? There's no "winner". LIke I said, this isn't about blessing one thing as the solution. We aren't going to just take something from outside and say "done". What I wanted is code to experiment with and adapt to what *we* design. We can add things from elsewhere as the design require (like modularize parts of JikesRVM, which I understand needs to be done...). Look at Jam. My understanding is that it sorta works, and it's very simple. It sounds like it's easy to refactor to a small, kernel- thingy that will be a basis of support for moving forward w/ the modularity. And then we can throw it out :) or not. Whatever we discover. I think we're going to learn a lot here. geir (And while I'm a mentor, I'm also a participant :) Thanks, dims On 5/23/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: On May 23, 2005, at 9:54 PM, Davanum Srinivas wrote: Geir, Am convinced that we can write a JVM in pure java with minimal C/C ++. Why? If it has C/C++, it's not pure Java. Period. This isn't about whether or not that it can be done in Java, or a way to get it into C/C++. Lets get over that misconception right now. I'm sure that major parts can be done in Java - it's been demonstrated by JikesRVM, and lots of experienced VM people point in that direction, even with a C/C++ core. I have no problem with that. How about we poll the VM candidates on who wants to help seed the project, ask them to do the paperwork, then we can get folks on board as committers and let them play in sandboxes (see below). Folks who do the work will then get to decide the future direction. We don't have to make the technical decision now before the committers are on board. What do you think? I don't see what we gain. We want to create *our design*, not make "frankenVM". The point of starting with a small seed C/C++ kernel is to get the bootstrap and intrinsics support that *any* VM will need, pure C, pure Java, or mixed. Our discussions will point to where we have to refactor. On top of that, we build what we decide to build, not what we find out there, unless what we find out there is what we designed for. geir Steve, As a mentor, i agree with you whole heartedly. How do we go about this process of designing the core for harmony? Could we say strip down say JamVM/JCVM to create a bootstrapper (OS dependent stuff ONLY) for a stripped down JikesRVM in our sandbox to illustrate the validity of writing the "almost" the whole JVM in java? [Nothing like working code to get juices flowing]. My problem is that i haven't done this (writing a JVM) before, so am itching to do something that will help me understand better the problems/challenges involved and help me on deciding what to look for in the other existing VM's that we can leverage/use. Thanks, dims On 5/23/05, Steve Blackburn <[EMAIL PROTECTED]> wrote: Lets get moving. Comments? Respectfully, I think this would be a mistake. I think it would be a major error to start coding a VM core until there was more clarity about what we are doing and what the core would require. but rather my understanding that we'll need a small C/C++ kernel to host the modules, no matter how they are written, and this is a way to get that going... This is no
