On 4/12/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > Weldon, > > Sorry, it was a mistake on my part, it should be: > > svn diff --diff-cmd diff -x -ubBw > > Anyway, I'm making some progress with the diff that you already > provided. (Part of the problem was that in order to use the diff on > Linux I had to remove the '\r' characters from the meta-data lines in > the diff.) > > Don't expect me to check anything in. I'm not a committer. > > What I really wanted to do was to: > > 1) bringing your changes up to date with respect to changes/movement > of files in svn,
Great! I really appreciate it. > > 2) looking at what you were doing and how, Ah! Sorry for the uncommented code. I wanted to get things working first then go back, clean up and document how they work. I will start working on this part soon. > > 3) test your changes on Linux Good idea. Other than perhaps the arg passing to native methods, there should be zero Linux specific mods. Let me know how things go. > > One thing that makes understanding what you are doing a little > difficult is that you label all your changes with only "// wrw" > comments. Generally I'm more interested in why a change was made than > "who" made it and ultimately svn will keep track of the who (or at > least which committer is to blame! ;-) Good point. I will rip out the //wjw and replace with comments. > > My initial thoughts are that it would be good to eliminate the changes > to you've had to make to the classlib tree and make things easier for > people to try out. Specifically: > > 1) Copy the luni-kernel and security-kernel stubs and add > implementation rather than doing it in place. The stubs are just for > compilation we shouldn't add anything VM (or VM adapter) specific to > them. hmm.... not sure what you are suggesting. The stubs allow the build to finish properly but the resultant binary won't run on any JVM because the stubs are hollow. > > 2) Figure out how to avoid faking the natives - > e.g. isLittleEndianImpl I assume for lack of 'why' comments that these > relate to the JNI/dll discussions you've been having. Nope. I will have to go back and reconcile why I hacked on isLittleEndianImpl. I can't recall off-hand. > > 3) Rename the java.lang.VM* internals to something more in keeping > with the naming convention [1] something like: > > org.apache.harmony.classpathadapter.internal.VM* No problem with the above renaming. > > 4) Create ant files to build adapter jars: luni-kernel.jar and > security-kernel.jar > > 1), 3), & 4) should be pretty easy to make progress on. I need to > look at 2 in a bit more depth. > > I think we should be looking to create something, that when combined > with JCHEVM, can be dropped in to the deploy tree in the same way that > the current IBM VME is dropped in. > > Anyway, all this is just my (humble) opinion as someone interested in > seeing this progress. All very good ideas. Thanks. > > Regards, > Mark. > > [1] > http://incubator.apache.org/harmony/subcomponents/classlibrary/pkgnaming.html > > On 4/12/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > > Mark, > > > > Thanks for working on the diffs. I have tried to get svn to behave. > > Version 1.3.0 dated Jan 15 does not recognize the "--diff-cmd" you > > suggest below. It might be a cygwin issue. > > > > Can you check-in just the kernel adapter stubs for now? This should > > involve zero diffs since this is a generic implementation of the > > stubs. There was a discussion previously to put all the kernel_path > > related files below .../enhanced/gnuclasspathadapter/ Thus no worry > > about overwriting the existing empty stubs in Classlib. > > > > On 4/12/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > > Weldon, any chance you could make a diff_harmony.txt without all the > > > whitespace changes and attach it to the JIRA? I'm trying to update it > > > to work with current svn and I want to avoid going through lots of > > > rejects that are only whitespace changes. I think you should be able > > > to do this with a command like: > > > > > > svn diff --diff-cmd 'diff -ubBw' > > > > > > assuming you have gnu diff installed or you could undo your formatting > > > changes but that might be a little more difficult. ;-) > > > > > > Of course, you realise that the classes you are modifying in kernel > > > (now luni-kernel and security-kernel) are only intended to be stubs to > > > compile against and not implemntation. These are intended to be > > > implemented by the VM. In this case I guess they'd need to be > > > implemented by the adapter. Thus I'm going to copy the stubs and > > > apply your patches to the copy outside of the classlib tree since we > > > shouldn't be changing the stubs. > > > > > > Regards, > > > Mark. > > > > > > On 4/12/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > > > Weldon, > > > > > > > > It's good to have this discussion on the list, but would you mind > > > > including at least some of the details about what the attached file is > > > > in the JIRA comment when you attach a file? At the moment when you > > > > look at the JIRA it's hard to tell what the attachments are for? > > > > > > > > Regards, > > > > Mark. > > > > > > > > On 4/12/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > > > > > I just uploaded a new zip file to JIRA Harmony-318 that contains the > > > > > mods to Harmony Classlib that will allow it to run on an unmodified > > > > > generic GNU Classpath JVM. > > > > > > > > > > Some of the issues encountered: > > > > > > > > > > 1) > > > > > libtool was not behaving. So, I gave up and used raw ld. > > > > > 2) > > > > > dlopen() refused to load the output of ld. Google turned up help pages > > > > > that showed dlopen() only likes files ending in *.a > > > > > 3) > > > > > Once dlopen() was able to open the shared lib containing the native > > > > > method, gdb was getting lost. Googling the web again turned up a > > > > > magic input arg to ld called "--enable-auto-image-base". Apparently > > > > > gdb internals are stepping on the same virtual addr as the newly > > > > > loaded lib?? In any case, the --enable.... worked around it. > > > > > 4) > > > > > There was real difficulty lining up the native method's incoming > > > > > arguments. Finally I declared the native method with input arguments > > > > > (int a1, int a2, int a3, int a4). Then passed the character to be > > > > > printed in all four arg slots. Surprise! The second arg of the C > > > > > routine actually held the correct argument. So the native method was > > > > > modified to print just a2. It works fine. > > > > > > > > > > Question for SableVM/JCHEVM guys: Did I miss the documentation on > > > > > lining up native method args? Can you point me to the correct place > > > > > to figure out how to do this? > > > > > > > > > > Also, I modified files in Harmony Classlib's native-src directory. > > > > > This might mean we need to add an additional level below > > > > > enhanced/gnuclasspathadapter/. Something like > > > > > enhanced/gnuclasspathadapter/native-src... Another issue is that > > > > > different GNU Classpath JVMs may require different name decoration and > > > > > different build options. Two ways of handling this are 1) add a > > > > > subdirectory for each JVM that contains the code that is unique to the > > > > > jvm and 2) use #ifdefs and make file options to handle the > > > > > differences. > > > > > > > > > > > > > > > > > > > > -- > > > > > Weldon Washburn > > > > > Intel Middleware Products Division > > > > > > > > > > --------------------------------------------------------------------- > > > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > -- > > > > Mark Hindess <[EMAIL PROTECTED]> > > > > IBM Java Technology Centre, UK. > > > > > > > > > > > > > -- > > > Mark Hindess <[EMAIL PROTECTED]> > > > IBM Java Technology Centre, UK. > > > > > > --------------------------------------------------------------------- > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Weldon Washburn > > Intel Middleware Products Division > > > > --------------------------------------------------------------------- > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Mark Hindess <[EMAIL PROTECTED]> > IBM Java Technology Centre, UK. > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Weldon Washburn Intel Middleware Products Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
