Re: [classlib] debug compilation as default
On 8 July 2006 at 19:13, =?ISO-8859-1?Q?Thorbj=F8rn_Ravn_Andersen?= <[EMAIL PROTECTED]> wrote: > Ivan Volosyuk skrev den 08-07-2006 00:35: > > Working on different projects, I've found out that Java programmers > > and C programmers have different habits. Java programmers likes ant, > > Linux/C programmers - make. I am C programmer :) > > If we going to do all the build ant-way, let's use cpptask as DRLVM > > does. But I will not sign up under that task - I can deal with > > makefile based build system, but I have quite little knowledge of ant > > to do that task. > Personally I think that it will be easier to use other C IDE's if the > project uses Makefiles since that is what historically has been used for > that purpose. > > Make and ant are to me very different in how you think when using it > - make is in terms of creating rules for deriving file(s) from other > file(s), where ant describes tasks. > > I think it is fine to use ant to invoke the global build, but > that make should be used for the C build. Perhaps ant can build > the configuration files used by make? Something similar to what > "configure" does? No. I think we should just invoke configure not re-invent it in ant. The point is that if/when we change from using raw make to using configure the developer running ant at the top-level (or module level) shouldn't care how, for example: ant -Dbuild.cfg=release and: ant -Dbuild.cfg=debug is implemented underneath. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] debug compilation as default
On 8 July 2006 at 1:35, "Ivan Volosyuk" <[EMAIL PROTECTED]> wrote: > On 7/7/06, Mark Hindess <[EMAIL PROTECTED]> wrote: > > > > On 7 July 2006 at 21:29, "Ivan Volosyuk" <[EMAIL PROTECTED]> wrote: > > > On 7/7/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > > > > > > > Ivan Volosyuk wrote: > > > > > > > > > > The drlvm build already has ant property called "build.cfg" > > > > > and "build.cxx" for the debug or release build and the > > > > > compiler name. The properties is initialized from BUILD_CFG > > > > > and CXX environment variables. IMHO, it will be convenient to > > > > > have the same property for drlvm and classlib build. Is it ok > > > > > to have _this_ property names? I don't think the word 'native' > > > > > in property make sense as this switch can be used somehow even > > > > > in java build (?) eventually. > > > > > > > > > > > > I do think we should agree on something, to make federation > > > > easier. > > > > > > > > geir > > > > > > Linux version of the makefiles update is already in > > > http://issues.apache.org/jira/browse/HARMONY-803 > > > > The DEFINES and INCLUDES is exactly the kind of thing I was thinking > > about. However: > > > > 1) I think we've somehow lost the default '-O1' option > > Yes. I'll fix it. > > > 2) I think the $(shell uname -m) is overkill, we'll handle this a > > better way when the time comes in the meantime forking/execing sh > > and uname for each call to make is just overhead. > > I know that fork/exec operation is quite efficient on linux, more over > the compilation of sources uses much more time. But it always returns the same result, for any valid architecture that we can build on, so why not just leave it out for now? As a general rule, we add complexity when we need it not before we need it without any discussion/justification. > > > I didn't touch ant build system. It allows to pass environment to > > > makefiles. That's enough. Makefiles will do the rest. > > > > Sorry, but I don't like this for reasons I discussed yesterday. It > > was late and I guess I wasn't clear enough. > > > > It should be done via ant because ant is the interface that > > developers should be using to execute the build - either using the > > top-level ant file or the module ant file (or via some federation > > calling ant). Even if they are only building native code in a > > module developers should still use the ant file. > > Working on different projects, I've found out that Java programmers > and C programmers have different habits. Java programmers likes ant, > Linux/C programmers - make. I am C programmer :) (I don't think it helps clarify the issue, but for the record, I'm a C programmer and Perl hacker. I don't particularly like make or ant. I like using the right tool for the job.) Harmony Classlib is primarily a Java project that includes a little C code[1]. The build is kicked off with ant so ant is the primary *interface* for developers, are you suggesting we change the top-level interface to make? It still uses make for the C underneath so as not to scare off C developers when they work at that level but they are always encouraged to kick off the build via ant for consistency. > If we going to do all the build ant-way, let's use cpptask as DRLVM > does. But I will not sign up under that task - I can deal with > makefile based build system, but I have quite little knowledge of ant > to do that task. No. As you say C programmers prefer tools like make (and configure) so we decided a while ago to stick to tools that matched expectations (for the implementation but not the interface). I'm not arguing that we should use *ant* for the *implementation* of the C code building just that ant is the *interface*. > > We may change[0] the way native code is built if handle things like > > this configuration issue via ant then the interface for developers > > can remain the same even when we change what happens under the > > covers. > > > > Regards, Mark. > > > > [0] Probably sooner rather than later if we start ports to other > > platforms. Regards, Mark [1] Arguably as little as we can get away with because we believe that in the long term the JIT will do better than a compiler when it comes to optimisation. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vm-kernel][testing] Where to put VM-agnostic tests for kernel classes?
> -Original Message- > From: Tim Ellison [mailto:[EMAIL PROTECTED] > > That is the default name, but you can change it with a command line > option -vm: and put it in a directory specified by -vmdir:, > > e.g. java -vmdir:drlvm -vm:foo Does this work for DRLVM now? I tried this method two weeks ago and couldn't get it to work. Is there anyway to configure the VM by an INI file or something? I'd prefer to use the DRLVM, but until I can just drop the binaries in place like the IBM VME it just seems like a pain. -Nathan > > look in jre/bin/drlvm for a library called foo.[so|dll] that exports the > JNI_CreateJavaVM etc. > > The idea is that you can have multiple VMs in deploy and choose which > you use at runtime. > > Regards, > Tim > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] debug compilation as default
Geir Magnusson Jr wrote: > > Ivan Volosyuk wrote: >> Working on different projects, I've found out that Java programmers >> and C programmers have different habits. Java programmers likes ant, >> Linux/C programmers - make. I am C programmer :) > > I am both, and I like using both for different things. > >> If we going to do all the build ant-way, let's use cpptask as DRLVM >> does. But I will not sign up under that task - I can deal with >> makefile based build system, but I have quite little knowledge of ant >> to do that task. > > I personally am against using cpptask, and hope we soon get around to > fixing drlvm's build system to use make. Actually, I'd prefer that we > use a conventional configure script to get some help w/ platform > specifics for the build. Me too. Having the top-level ant script invoke configure and make with default options is fine too, to tie it all together; but as we have written before there are a number of benefits to using the tools most commonly associated with each language. Regards, Tim -- Tim Ellison ([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]
Re: [classlib] debug compilation as default
Thorbjørn Ravn Andersen wrote: > Ivan Volosyuk skrev den 08-07-2006 00:35: >> Working on different projects, I've found out that Java programmers >> and C programmers have different habits. Java programmers likes ant, >> Linux/C programmers - make. I am C programmer :) >> If we going to do all the build ant-way, let's use cpptask as DRLVM >> does. But I will not sign up under that task - I can deal with >> makefile based build system, but I have quite little knowledge of ant >> to do that task. > Personally I think that it will be easier to use other C IDE's if the > project uses Makefiles since that is what historically has been used for > that purpose. > > Make and ant are to me very different in how you think when using it - > make is in terms of creating rules for deriving file(s) from other > file(s), where ant describes tasks. > > I think it is fine to use ant to invoke the global build, but that make > should be used for the C build. Perhaps ant can build the configuration > files used by make? Something similar to what "configure" does? > Or just use configure :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] debug compilation as default
Ivan Volosyuk wrote: > > Working on different projects, I've found out that Java programmers > and C programmers have different habits. Java programmers likes ant, > Linux/C programmers - make. I am C programmer :) I am both, and I like using both for different things. > If we going to do all the build ant-way, let's use cpptask as DRLVM > does. But I will not sign up under that task - I can deal with > makefile based build system, but I have quite little knowledge of ant > to do that task. I personally am against using cpptask, and hope we soon get around to fixing drlvm's build system to use make. Actually, I'd prefer that we use a conventional configure script to get some help w/ platform specifics for the build. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [testing] Peace
Tim Ellison skrev den 07-07-2006 00:10: May I tactfully suggest that we get this back to a discussion of the pros and cons of JUnit test suites and/or TestNG metadata vs. directory layout. Sounds good. Then I have a question: I have used JUnit 3 somewhat for test-driven development, and found it well integrated in eclipse. Is the features of TestNG so overwhelmingly better than JUnit (both 3 and 4) that they merit using it, despite that more developers know JUnit? Lets hear it from the elders themselves :) -- Thorbjørn - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] debug compilation as default
Ivan Volosyuk skrev den 08-07-2006 00:35: Working on different projects, I've found out that Java programmers and C programmers have different habits. Java programmers likes ant, Linux/C programmers - make. I am C programmer :) If we going to do all the build ant-way, let's use cpptask as DRLVM does. But I will not sign up under that task - I can deal with makefile based build system, but I have quite little knowledge of ant to do that task. Personally I think that it will be easier to use other C IDE's if the project uses Makefiles since that is what historically has been used for that purpose. Make and ant are to me very different in how you think when using it - make is in terms of creating rules for deriving file(s) from other file(s), where ant describes tasks. I think it is fine to use ant to invoke the global build, but that make should be used for the C build. Perhaps ant can build the configuration files used by make? Something similar to what "configure" does? -- Thorbjørn - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DRLVM] GC/VM interface discussion
All,
As a first step to improving DRLVM's GC/VM interface, it would be
great to cleanup drlvm/trunk/vm/include/open/vm_gc.h and gc.h.
Basically the concept is to start by removing unused APIs and fixing
the comments.
A second step would be to modify these files to accommodate different
GCs such as MMTk.
To start the discussion, below are some initial comments on gc.h
GCExport void gc_test_safepoint();
The comments associated with this API are vague and confusing. "The
GC may ignore this, or it may force a root set enumeration, or it may
execute a full GC. Questions for the debugger folks: Is this
interface really needed? When does it actually have to do something?
If a full GC arbitrarily happens when this API is called, will the
debugger work as expected? One interpretation of the comments is that
"void gc_test_safepoint() {}" satisfies the requirements and everyone
is happy.
GCExport void gc_add_root_set_entry_managed_pointer();
I looked at the code. Its in gc_for_vm.cpp. I remember writing code
very similar to this function to support ECMA CLI. ECMA CLI needs to
handle the situation where an optimizing compiler leaves an interior
pointer to an array pointing just one past the last element.
Understand that the optimizing compiler is smart enough not to use
this bad pointer but in ECMA CLI it could get reported to the GC.
Since none of this happens in Java, how about dumping this API? We
should replace it with gc_add_root_set_entry(). Thoughts?
GCExport Managed_Object_Handle gc_alloc_pinned();
This API is currently unused. How about we dump it for now? (NOTE:
MMTk has the concept of "immortal space". Immortal space is never
collected, never moved, only traced. Maybe we need an immortal space
kind of API instead??)
GCExport void gc_write_barrier(Managed_Object_Handle p_base_of_obj_with_slot);
This is a difficult API. For starts, it only applies to write
barriers written in C/asm. Its not usable by MMTk. "C" Write
barriers that also need the ref ptr that gets written to heap will
need to call a different API. That is, unless the JIT can *inline*
random chunks of C/asm and optimize across the call boundary. A hard
and ugly thing to have to do! Since old ORP generational GC and also
SableVM GC only use the above API, my vote is to leave this API "as
is" for now.
--
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]
Re: [general] milestones and roadmap (round 1 summary)
Weldon Washburn wrote: > On 7/6/06, Tim Ellison <[EMAIL PROTECTED]> wrote: >> Geir Magnusson Jr wrote: >> > I think this captures the input so far w/ a minimum of >> editorializing on >> > my part for now :) let me know if anything was left off, or if there >> > are new things to be added > > I agree. It looks like a good start. >> >> It would be good to expand on some of these topics with specific tasks, >> then put them on the website so people can see what needs doing (and >> volunteer!) >> > > Good idea! Once the top level structure is in place, perhaps we can > create multiple mailing lists that reflect the structure. With the > volume of mail on harmony-dev, its very easy to overlook messages you > are interested in. > I'm against this for now because I still think it's too early, although we'll certainly do this in the future. For now, I think that we can do well if we're careful about prepending subject lines. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Testing conventions - a proposal
Alex Blewitt wrote: > On 08/07/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: >> >> So while I like the annotations, and expect we can use them effectively, >> I have an instinctive skepticism of annotations right now because in >> general (in general in Java), I'm not convinced we've used them enough >> to grok good design patterns. > > There's really no reason to get hung up on the annotations. TestNG > works just as well with JavaDoc source comments; annotations are only > another means to that end. (They're probably a better one for the > future, but it's just an implementation detail.) You don't understand what I meant - one of the elements of this subject is that we can punt on how we're organizing tests in a directory layout, and use annotations for that purpose, and I'm worried about going fully to that extreme. > >> Now since I still haven't read the thread fully, I'm jumping to >> conclusions, taking it to the extreme, etc etc, but my thinking in >> writing the above is that if we bury everything about our test >> 'parameter space' in annotations, some of the visible organization we >> have now w/ on-disk layout becomes invisible, and the readable >> "summaries" of aspects of testing that we'd have in an XML metadata >> document (or whatever) also are hard because you need to scan the >> sources to find all instances of annotation "X". > > I'm hoping that this would be just as applicable to using JavaDoc > variants, and that the problem's not with annotations per se. Right. > > In either case, both are grokkable with tools -- either > annotation-savy readers or a JavaDoc tag processor, and it wouldn't be > hard to configure one of those to periodically scan the codebase to > generate reports. Furthermore, as long as the annotation X is well > defined, *you* don't have to scan it -- you leave it up to TestNG to > figure it out. Maybe. Tools help, but they have to be universal, lightweight and pretty transparent, IMO. Don't force people to boot Eclipse (or Netbeans or IDEA) to just figure out the general details of a test class... > > Actually, there's a very valid benefit for using TestNG markers (= > annotations/JavaDoc) for grouping tests; the directory structure is a > tree, whereas the markers can form any slice of tests, and the sets > don't need to be strict subsets (with a tree, everything has to be a > strict subset of its parents). That means that it's possible to define > a marker IO to run all the IO tests, or a marker Win32 to run all the > Win32 tests, and both of those will contain IO-specific Win32 tests. > You can't do that in a tree structure without duplicating content > somewhere along the line (e.g. /win/io or /io/win). Neither of these > scale well, and every time you add a new dimension, you're doubling > the structure of the directory, but merely adding a new marker with > TestNG. So if you wanted to have (say) boot classpath tests vs api > tests, then you'd ahve to have /api/win/io and /boot/win/io (or > various permutations as applicable). I understand this, which is why I think a general human-readable metadata system will help, preferably one that has the data in one place, rather than scattered throughout... of course, centralization has it's downsides too... it's not an easy problem :) > > Most of the directory-based arguments seem to be along the lines of > "/api/win/io is better! No, /win/io/api is better!". Just have an > 'api', 'win', 'io' TestNG marker, and then let TestNG figure out which > ones to run. You can then even get specific, and only run the Windows > IO API tests, if you really want -- but if you don't, you get the > benefit of being able to run all IO tests (both API and boot). Or a document that has groups/suites that ant then uses... > > There doesn't seem to be any benefit to having a strict tree-like > structure to the tests when it's possible to have a multi-dimensional > matrix of all possible combinations that's managed by the tool. Right. Clearly a "directory-only" solution won't ever work well, in the same way an annotation/marker based solution won't either (I'm guessing). I think we first have to figure out what we want to achieve *irrespective* of how it will be done, and then find the right tools/process/strategy to achieve that, or create them. This is important. Lets not let the directory-tail or the annotation-tail wag the testing dog. :D geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] milestones and roadmap (round 1 summary)
On 7/6/06, Tim Ellison <[EMAIL PROTECTED]> wrote: Geir Magnusson Jr wrote: > I think this captures the input so far w/ a minimum of editorializing on > my part for now :) let me know if anything was left off, or if there > are new things to be added I agree. It looks like a good start. It would be good to expand on some of these topics with specific tasks, then put them on the website so people can see what needs doing (and volunteer!) Good idea! Once the top level structure is in place, perhaps we can create multiple mailing lists that reflect the structure. With the volume of mail on harmony-dev, its very easy to overlook messages you are interested in. -- 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]
Re: [announce] New Apache Harmony Committer : Weldon Washburn
Thanks everyone. I look forword to working with you. Let's make Harmony exceed expectations! - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [classlib] Testing conventions - a proposal
On 08/07/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: So while I like the annotations, and expect we can use them effectively, I have an instinctive skepticism of annotations right now because in general (in general in Java), I'm not convinced we've used them enough to grok good design patterns. There's really no reason to get hung up on the annotations. TestNG works just as well with JavaDoc source comments; annotations are only another means to that end. (They're probably a better one for the future, but it's just an implementation detail.) Now since I still haven't read the thread fully, I'm jumping to conclusions, taking it to the extreme, etc etc, but my thinking in writing the above is that if we bury everything about our test 'parameter space' in annotations, some of the visible organization we have now w/ on-disk layout becomes invisible, and the readable "summaries" of aspects of testing that we'd have in an XML metadata document (or whatever) also are hard because you need to scan the sources to find all instances of annotation "X". I'm hoping that this would be just as applicable to using JavaDoc variants, and that the problem's not with annotations per se. In either case, both are grokkable with tools -- either annotation-savy readers or a JavaDoc tag processor, and it wouldn't be hard to configure one of those to periodically scan the codebase to generate reports. Furthermore, as long as the annotation X is well defined, *you* don't have to scan it -- you leave it up to TestNG to figure it out. Actually, there's a very valid benefit for using TestNG markers (= annotations/JavaDoc) for grouping tests; the directory structure is a tree, whereas the markers can form any slice of tests, and the sets don't need to be strict subsets (with a tree, everything has to be a strict subset of its parents). That means that it's possible to define a marker IO to run all the IO tests, or a marker Win32 to run all the Win32 tests, and both of those will contain IO-specific Win32 tests. You can't do that in a tree structure without duplicating content somewhere along the line (e.g. /win/io or /io/win). Neither of these scale well, and every time you add a new dimension, you're doubling the structure of the directory, but merely adding a new marker with TestNG. So if you wanted to have (say) boot classpath tests vs api tests, then you'd ahve to have /api/win/io and /boot/win/io (or various permutations as applicable). Most of the directory-based arguments seem to be along the lines of "/api/win/io is better! No, /win/io/api is better!". Just have an 'api', 'win', 'io' TestNG marker, and then let TestNG figure out which ones to run. You can then even get specific, and only run the Windows IO API tests, if you really want -- but if you don't, you get the benefit of being able to run all IO tests (both API and boot). There doesn't seem to be any benefit to having a strict tree-like structure to the tests when it's possible to have a multi-dimensional matrix of all possible combinations that's managed by the tool. Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Testing conventions - a proposal
Nathan Beyer wrote: > >> -Original Message- >> From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] >> > >> This is a fun thread. I plan to read it from end to end later today and >> comment. >> >> Initial thoughts are that I've been wanting to use TestNG for months >> (hence my resistance to any JUnit deps more than we needed to) and >> second, annotations won't solve our problems. More later :) >> > > I find this to be an extremely interesting comment. What value do you see > TestNG offering? Most of the conversations pushing for TestNG as a solution > have been all about the annotations. I meant "all our problems" :) I've been suggesting being open to TestNG for a while now, for the reason that it's "second generation", written by people I know and trust who have had to use it in anger - they were scratching their own itch. I like a bunch of small things, like not having to extend a base class, dependent test methods, pluggability, parameterized tests, and the annotations, but I haven't used it -it's all academic for me so far. So while I like the annotations, and expect we can use them effectively, I have an instinctive skepticism of annotations right now because in general (in general in Java), I'm not convinced we've used them enough to grok good design patterns. Now since I still haven't read the thread fully, I'm jumping to conclusions, taking it to the extreme, etc etc, but my thinking in writing the above is that if we bury everything about our test 'parameter space' in annotations, some of the visible organization we have now w/ on-disk layout becomes invisible, and the readable "summaries" of aspects of testing that we'd have in an XML metadata document (or whatever) also are hard because you need to scan the sources to find all instances of annotation "X". Anyway, I wanted this to be a short note to address your concern, but I don't seem to be able to do that :) More later. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
