+1
2006/7/6, Nathan Beyer [EMAIL PROTECTED]:
+1
-Original Message-
From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 05, 2006 6:29 PM
To: harmony-dev@incubator.apache.org
Subject: [vote] acceptance of HARMONY-536 : JSEE provider contribution
All is in order
2006/7/5, George Harley [EMAIL PROTECTED]:
Hi,
Just seen Tim's note on test support classes and it really caught my
attention as I have been mulling over this issue for a little while now.
I think that it is a good time for us to return to the topic of class
library test layouts.
The current
+1
2006/7/6, Geir Magnusson Jr [EMAIL PROTECTED]:
All is in order and in SVN for Harmony-609 wrt BCC and ACQ.
Please vote to accept or reject this codebase into the Apache Harmony
class library :
[ ] + 1 Accept
[ ] -1 Reject (provide reason below)
Lets let this run a minimum of 3 days
+1
-Mark
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 5 July 2006 at 19:46, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
In HARMONY-681, I applied the patch to build DRLVM as debug by
default, but 'rejected' the classlib patch, as it's not overridable as
the DRLVM one is.
I think that we'd like to be able to set a flag for release build,
On 6 July 2006 at 0:46, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Mark Hindess wrote:
On 20 June 2006 at 19:24, Mikhail Loenko [EMAIL PROTECTED] wrote:
2006/6/20, Geir Magnusson Jr [EMAIL PROTECTED]:
I'd like to start assembling a high-level roadmap of the
milestones we'd like to
On 5 July 2006 at 13:39, =?ISO-8859-1?Q?Thorbj=F8rn_Ravn_Andersen?= [EMAIL
PROTECTED] wrote:
Oliver Deakin skrev den 27-06-2006 12:25:
Do you mean the header files in deploy/include? If so, the reason
they are copied there is so that they are in a shared location for
all modules. (In
On 5 July 2006 at 10:06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Mark Hindess wrote:
Sorry to interrupt your game,
Umpire, can you get this streaker off the court, please?
:)
:-)
but is there any reason why the jar must have the version number in
the name - it's in the
On 06/07/06, Richard Liang [EMAIL PROTECTED] wrote:
George Harley wrote:
A couple of weeks ago I mentioned that the TestNG framework [2] seemed
like a reasonably good way of allowing us to both group together
different kinds of tests and permit the exclusion of individual
tests/groups of
Alex Blewitt wrote:
On 06/07/06, Richard Liang [EMAIL PROTECTED] wrote:
George Harley wrote:
A couple of weeks ago I mentioned that the TestNG framework [2] seemed
like a reasonably good way of allowing us to both group together
different kinds of tests and permit the exclusion of
On 06/07/06, Richard Liang [EMAIL PROTECTED] wrote:
It seems that you're very familiar with TestNG. ;-) So would you please
identify what we shall do to transfer from junit to TestNG? Thanks a lot.
Me? I'm just highly opinionated :-)
There's guidelines for migrating from JUnit to TestNG at
IMNSHO I don't think we should by default copy the toString()
behaviour from the RI, unless mandated by the spec in JavaDoc.
Frankly, the toString() has always been undefined, and I'm sick off
Java developers saying Well, yes, but I always expect it to be
[name='value',name='other value'] and
Ok. I just have to ask. Why did you delete the body of the original
message?
Mark Hindess wrote:
+1
-Mark
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL
More details: it is
org/apache/harmony/security/tests/java/security/SecureRandom2Test.java test.
At present time it has 2 failing tests with messages about SHA1PRNG
algorithm (no support for SHA1PRNG provider).
Looks like it is valid tests for non implemented functionality, but, I'm not
sure what
On 6 July 2006 at 5:38, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Ok. I just have to ask. Why did you delete the body of the original
message?
I didn't really give it much thought, but ...
Why not? Wasn't the meaning of the +1 comment was perfectly clear
from the subject.
I had nothing
Odd. :)
Leaving the body does make it clear, given that with long threads, there
can be a gap between Subject and body...
geir
Mark Hindess wrote:
On 6 July 2006 at 5:38, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Ok. I just have to ask. Why did you delete the body of the original
Alex Blewitt wrote:
IMNSHO I don't think we should by default copy the toString()
behaviour from the RI, unless mandated by the spec in JavaDoc.
Frankly, the toString() has always been undefined, and I'm sick off
Java developers saying Well, yes, but I always expect it to be
Xiao-Feng Li wrote:
Visual Studio 2005 (Whidbey VC8) C runtime library (CRT) has changed
some compilation rules and APIs for better security or ISO/ANSI
conformance. Many changes are breaking, i.e., incompatible. For
example, it adds safer counterparts for many functions like `strcpy_s'
for
Alex Blewitt wrote:
On 06/07/06, Richard Liang [EMAIL PROTECTED] wrote:
It seems that you're very familiar with TestNG. ;-) So would you please
identify what we shall do to transfer from junit to TestNG? Thanks a
lot.
Me? I'm just highly opinionated :-)
There's guidelines for migrating
Ok, then I will get back to VC7 at the moment. :-) Let's wait till
its acceptance by the community.
Actually I don't see them as new APIs; instead, I view them as
enforced good coding conventions that help to achieve better security,
e.g., always check the buffer size in debug mode. (Personally
Alex Blewitt wrote:
On 06/07/06, Richard Liang [EMAIL PROTECTED] wrote:
It seems that you're very familiar with TestNG. ;-) So would you please
identify what we shall do to transfer from junit to TestNG? Thanks a
lot.
Me? I'm just highly opinionated :-)
Hi Alex,
I think we are all
Hi Mark,
From what I can tell this JIRA hasn't really achieved much apart from
pushing code around the repository and breaking at least one patch
(HARMONY-755). It would be great if you or Paulex (and everyone in fact)
could comment in the [classlib] Testing conventions - a proposal
thread
Geir - looks accurate to me. A couple of comments in line:
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
General
===
- switch to java 5
-
On 7/6/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
On Wednesday 05 July 2006 14:33 Alexey Varlamov wrote:
Please find the solution in HARMONY-764 and HARMONY-765 JIRAs.
Thanks a lot Alexey, I've checked the build with your fixes on linux and now
signed jars work.
The only addition to these
During the first pass through bytecode verifier builds an instruction array
of the method. While building the instruction array verifier checks
constraints for each processed instruction. For instance, for instruction
working with local variables verifier checks a range of local variable
index,
Hello All,
When I'm trying to implement Scanner.nextInt(int radix), I met a problem.
As we all know, Character.MIN_RADIX equals 2 and Character.MAX_RADIX
equals 36, so the parameter radix can not less than 2 or greater than
36, Otherwise that parameter is illegal.
But on RI, when the
Hi, George
I've read that thread, and I agree with you that the test layout is an
issue worthing consideration, but before heading into the discussion on
test convention(again), I want to have a look at TestNG at first so that
I can have more value-add to that thread.
But on the other side,
Andrew,
I've raised HARMONY-782, and thanks Mark, the patch has been applied,
but I must say sorry that it breaks your patch for HARMONY-767(many
thanks to Mark again, he provided a updated patch for this). Please
check it can meet your requirement so far.
And FYI, you may interest another
On 6 July 2006 at 12:55, George Harley [EMAIL PROTECTED]
wrote:
Hi Mark,
From what I can tell this JIRA hasn't really achieved much apart
from pushing code around the repository and breaking at least one
patch (HARMONY-755).
Well, obviously that wasn't my motivation! ;-)
From the
Hi Richard,
Very good example.
You are right, spec says nothing about invalid radix processing for
nextInt(). RI behavior just proves they have no guard check. However
useRadix() produces IAE for the invalid radix and the sound of logic
says that IAE is a proper reaction for wrong radix in any
Mark Hindess wrote:
On 6 July 2006 at 12:55, George Harley [EMAIL PROTECTED]
wrote:
Hi Mark,
From what I can tell this JIRA hasn't really achieved much apart
from pushing code around the repository and breaking at least one
patch (HARMONY-755).
Well, obviously that wasn't my
Hello,
For those who're going to rewrite the build: please add copying
logging.properties:
http://issues.apache.org/jira/browse/HARMONY-789
On 7/5/06, Vladimir Gorr [EMAIL PROTECTED] wrote:
On 7/5/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Mark Hindess wrote:
Salikh Zakirov wrote:
Paulex Yang wrote:
Richard Liang wrote:
Hello All,
When I'm trying to implement Scanner.nextInt(int radix), I met a
problem.
As we all know, Character.MIN_RADIX equals 2 and Character.MAX_RADIX
equals 36, so the parameter radix can not less than 2 or greater than
36, Otherwise that
Anton Avtamonov wrote:
Hi Richard,
Very good example.
You are right, spec says nothing about invalid radix processing for
nextInt(). RI behavior just proves they have no guard check. However
useRadix() produces IAE for the invalid radix and the sound of logic
says that IAE is a proper
Andrey Chernyshev wrote:
On 7/5/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Mark Hindess wrote:
Salikh Zakirov wrote:
Using the fixed classlib snapshot will remove one factor
of uncertainty, and will make the DRLVM behaviour more reproducible.
-1
Doing this will hide issues that
Don't take my word here - we need opines from others, especially the
people that work a lot on windows...
geir
Xiao-Feng Li wrote:
Ok, then I will get back to VC7 at the moment. :-) Let's wait till
its acceptance by the community.
Actually I don't see them as new APIs; instead, I view
This is a great example. The last two aren't even legal exceptions for
that method.
It seems like the RI is doing random crap, and it wouldn't be something
that someone would depend on... can you imagine?
try {
Scanner.nextInt(foo);
}
catch {StringInxOutOfBndsEx bar) {
... real
Geir,
I quite often want to search JIRA for outstanding DRLVM issues. At the
moment, these are mixed in with jchevm, classlibadapter and bootjvm
issues. Perhaps we could split the VM component now?
Regards,
Mark.
-
Terms
On 6 July 2006 at 10:36, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
It is good to see that we finally have java1.5 support in
DRLVM. One small question, why my authorship was discarded from
interpreter.cpp? :)
Nothing personal - just a habit... I'm just nipping
On 7/6/06, Mark Hindess [EMAIL PROTECTED] wrote:
On 6 July 2006 at 10:36, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Ivan Volosyuk wrote:
It is good to see that we finally have java1.5 support in
DRLVM. One small question, why my authorship was discarded from
interpreter.cpp? :)
Mikhail Loenko wrote:
2006/7/5, George Harley [EMAIL PROTECTED]:
Hi,
Just seen Tim's note on test support classes and it really caught my
attention as I have been mulling over this issue for a little while now.
I think that it is a good time for us to return to the topic of class
library
Gregory Shimansky wrote:
On Thursday 06 July 2006 03:46 Geir Magnusson Jr wrote:
In HARMONY-681, I applied the patch to build DRLVM as debug by default,
but 'rejected' the classlib patch, as it's not overridable as the DRLVM
one is.
I think that we'd like to be able to set a flag for release
Sure! have at it!
Mark Hindess wrote:
Geir,
I quite often want to search JIRA for outstanding DRLVM issues. At the
moment, these are mixed in with jchevm, classlibadapter and bootjvm
issues. Perhaps we could split the VM component now?
Regards,
Mark.
Alex Blewitt wrote:
IMNSHO I don't think we should by default copy the toString()
behaviour from the RI, unless mandated by the spec in JavaDoc.
Frankly, the toString() has always been undefined, and I'm sick off
Java developers saying Well, yes, but I always expect it to be
(Apologies for the very late response, I'm way behind on my 'must
respond' list)...
Marina Goldburt wrote:
Hi,
As I see the main idea of the port library is isolates all platform
specific knowledge to one area, as written at
http://svn.apache.org/viewvc
(sorry for the very late response)
Geir Magnusson Jr wrote:
I don't mind the macros, I just think the actual function should be
named something different than the macro and have some docs to stem
confusion from other readers in the future.
Yea/nea?
Yea to doc (thanks!) and nea to renaming.
Nathan Beyer wrote:
Shouldn't we be using Unicode 4.0.1, since Java 5 RI is 4.0-based and 4.1 is
large upgrade? I've used 4.0.1 to implement some of the Character and
UnicodeBlock code since it's a 4.0 patch version.
Should be attempt to support a single Unicode version for all modules,
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 06, 2006 12:34 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] mem
(sorry for the very late response)
Geir Magnusson Jr wrote:
I don't mind the macros, I just think the actual
Vladimir Gorr wrote:
On 7/5/06, Salikh Zakirov [EMAIL PROTECTED] wrote:
Mark Hindess wrote:
Salikh Zakirov wrote:
Using the fixed classlib snapshot will remove one factor
of uncertainty, and will make the DRLVM behaviour more reproducible.
-1
Doing this will hide issues that
Geir Magnusson Jr wrote:
I'm -1 for adding any more auto-fetches to DRLVM.
me too, for the record.
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use :
Marina Goldburt wrote:
The patch is only an experiment to change the internal portlib
implementation, that, as I think, reveals some design/implementation
problems of the luni module.
Please elaborate.
I'm pleased that you are looking at this code, but may I suggest that
you make a point of
Mark Hindess wrote:
On 6 July 2006 at 12:55, George Harley [EMAIL PROTECTED]
wrote:
Hi Mark,
From what I can tell this JIRA hasn't really achieved much apart
from pushing code around the repository and breaking at least one
patch (HARMONY-755).
Well, obviously that wasn't my
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
It would be good to expand on some of these topics with specific tasks,
then put them on the
This particular mail (by Gregory) contains
(a) a link to another mail (of his) describing how to
get the MSFT tools to work, and
(b) a link to a JIRA issue containing the necessary
patches to use NASM for assembly:
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/[EMAIL
Geir Magnusson Jr wrote:
Tim Ellison wrote:
Andrey Chernyshev wrote:
I'm not sure it is just a name clash problem - drlvm won't give the
hythread library if the class lib hadn't requested it.
The classlib builds it's own copy of the hythread library, so there is
no need for a compatible VM
Paulex Yang wrote:
Hi, George
I've read that thread, and I agree with you that the test layout is an
issue worthing consideration, but before heading into the discussion
on test convention(again), I want to have a look at TestNG at first so
that I can have more value-add to that thread.
Hi
On Thursday 06 July 2006 20:20 Tim Ellison wrote:
Gregory Shimansky wrote:
On Thursday 06 July 2006 03:46 Geir Magnusson Jr wrote:
In HARMONY-681, I applied the patch to build DRLVM as debug by default,
but 'rejected' the classlib patch, as it's not overridable as the DRLVM
one is.
I
On Thursday 06 July 2006 14:35 Xiao-Feng Li wrote:
Ok, then I will get back to VC7 at the moment. :-) Let's wait till
its acceptance by the community.
Actually I don't see them as new APIs; instead, I view them as
enforced good coding conventions that help to achieve better security,
e.g.,
Tim Ellison wrote:
Geir Magnusson Jr wrote:
Tim Ellison wrote:
Andrey Chernyshev wrote:
I'm not sure it is just a name clash problem - drlvm won't give the
hythread library if the class lib hadn't requested it.
The classlib builds it's own copy of the hythread library, so there is
no need
please categorize subject lines...
Tim Ellison wrote:
Ivan Volosyuk wrote:
A little bit upset, that I'm no longer mentioned as author of the
interpreter.cpp, it was quite a bit of work; not perfect I know.
Sorry that you feel that way. Your feelings illustrates to me why it is
easier and
Gregory Shimansky wrote:
(I'll try to answer both your and Geir's question here)
The build system for native code is really simple and has most things like
even debug on/off mode hardcoded in the flags. It has just one fixed set of
flags which don't include debug by default. If any change
Gregory Shimansky wrote:
On Thursday 06 July 2006 20:20 Tim Ellison wrote:
Gregory Shimansky wrote:
On Thursday 06 July 2006 03:46 Geir Magnusson Jr wrote:
In HARMONY-681, I applied the patch to build DRLVM as debug by default,
but 'rejected' the classlib patch, as it's not overridable as
On 7/6/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I think the key reason is that this is non-standard stuff from
microsoft's for-fee toolchain, and people in OSS try to avoid having a
dependency on that.
I wouldn't mind supporting this at some point a) once it becomes a
standard and b) has
Actually, let me flip this the other way...
What are the differences between the impl of the threading lib in DRLVM
vs that in classlib?
Geir Magnusson Jr wrote:
Tim Ellison wrote:
Geir Magnusson Jr wrote:
Tim Ellison wrote:
Andrey Chernyshev wrote:
I'm not sure it is just a name clash
Vladimir Ivanov wrote:
More details: it is
org/apache/harmony/security/tests/java/security/SecureRandom2Test.java
test.
At present time it has 2 failing tests with messages about SHA1PRNG
algorithm (no support for SHA1PRNG provider).
Looks like it is valid tests for non implemented
On 6 July 2006 at 18:05, George Harley [EMAIL PROTECTED] wrote:
Mark Hindess wrote:
On 6 July 2006 at 12:55, George Harley [EMAIL PROTECTED]
wrote:
Hi Mark,
From what I can tell this JIRA hasn't really achieved much apart
from pushing code around the repository and breaking
Magnusson, Geir wrote:
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 06, 2006 12:34 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] mem
(sorry for the very late response)
Geir Magnusson Jr wrote:
I don't mind the macros, I
On Thursday 06 July 2006 16:49, Geir Magnusson Jr wrote:
This is a great example. The last two aren't even legal exceptions for
that method.
It seems like the RI is doing random crap, and it wouldn't be something
that someone would depend on... can you imagine?
I think we have to
Gregory Shimansky wrote:
On Thursday 06 July 2006 20:26 Geir Magnusson Jr wrote:
As part of the work surrounding the HARMONY-677 (r419557), getting DRLVM
to deal with Java5 classfile format, I noticed that DRLVM doesn't
appear to give a hoot what version of the classfile it's chewing on.
On 6 July 2006 at 21:37, Gregory Shimansky [EMAIL PROTECTED] wrote:
On Thursday 06 July 2006 20:20 Tim Ellison wrote:
Gregory Shimansky wrote:
On Thursday 06 July 2006 03:46 Geir Magnusson Jr wrote:
In HARMONY-681, I applied the patch to build DRLVM as debug by default,
but 'rejected'
+1 in favor of dumping author tags.
On 7/6/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
please categorize subject lines...
Tim Ellison wrote:
Ivan Volosyuk wrote:
A little bit upset, that I'm no longer mentioned as author of the
interpreter.cpp, it was quite a bit of work; not perfect I
On Thursday 06 July 2006 23:06 Mark Hindess wrote:
The build system for native code is really simple and has most things
like even debug on/off mode hardcoded in the flags. It has just one
fixed set of flags which don't include debug by default. If any change
is required, makefiles have to
Anyway, I want to make a few changes in interpreter code. There is a
fix for a few floating-point to integer conversions' bytecodes which
make incorrect clumping. An improvement for diagnostic messages in
AbstractMethodError and IllegalAccessError. Is it the right time to do
this kind of changes?
On 7/7/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
On Thursday 06 July 2006 23:06 Mark Hindess wrote:
The build system for native code is really simple and has most things
like even debug on/off mode hardcoded in the flags. It has just one
fixed set of flags which don't include debug by
On 7/6/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
Visual Studio 2005 (Whidbey VC8) C runtime library (CRT) has changed
some compilation rules and APIs for better security or ISO/ANSI
conformance. Many changes are breaking, i.e., incompatible. For
example, it adds safer counterparts for many
On 7 July 2006 at 0:43, Ivan Volosyuk [EMAIL PROTECTED] wrote:
On 7/7/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
On Thursday 06 July 2006 23:06 Mark Hindess wrote:
The build system for native code is really simple and has most
things like even debug on/off mode hardcoded in the
Mark Hindess wrote:
On 6 July 2006 at 18:05, George Harley [EMAIL PROTECTED] wrote:
Mark Hindess wrote:
On 6 July 2006 at 12:55, George Harley [EMAIL PROTECTED]
wrote:
Hi Mark,
From what I can tell this JIRA hasn't really achieved much apart
from pushing code around the
On 7/7/06, Mark Hindess [EMAIL PROTECTED] wrote:
On 7 July 2006 at 0:43, Ivan Volosyuk [EMAIL PROTECTED] wrote:
On 7/7/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
On Thursday 06 July 2006 23:06 Mark Hindess wrote:
The build system for native code is really simple and has most
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.
It sounds like we all want to resolve that problem asap.
Regards,
Tim
George Harley wrote:
Mark Hindess wrote:
On 6 July 2006 at 18:05, George
On Friday 07 July 2006 01:28 Ivan Volosyuk wrote:
I'm happy with release and debug but the top-level interface (and
the module-level interface too for that matter) is ant - make should
not be called directly - so it will probably need to be an ant property.
I was thinking:
1) adding
On 7/7/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
On Friday 07 July 2006 01:28 Ivan Volosyuk wrote:
I'm happy with release and debug but the top-level interface (and
the module-level interface too for that matter) is ant - make should
not be called directly - so it will probably need
The pieces of Unicode 4.1 that would be of any concern would be the notable
changes [1]. If we were to fully support Unicode 4.1 in some classes, like
Character.UnicodeBlock, there may be some cases of supporting more than the
Java 5 spec (RI). This is probably fine in most cases, but I'd be
I think Tim has a valid point, or at least the point I'm inferring seems
valid: the testing technology is not the real issue. This problem can be
solved by either JUnit or TestNG. More specifically, this problem can be
solved utilizing the grouping of arbitrary tests.
I'm been playing with
Chris Gray wrote:
On Thursday 06 July 2006 16:49, Geir Magnusson Jr wrote:
This is a great example. The last two aren't even legal exceptions for
that method.
It seems like the RI is doing random crap, and it wouldn't be something
that someone would depend on... can you imagine?
I
Richard Liang wrote:
Paulex Yang wrote:
Richard Liang wrote:
Hello All,
When I'm trying to implement Scanner.nextInt(int radix), I met a
problem.
As we all know, Character.MIN_RADIX equals 2 and Character.MAX_RADIX
equals 36, so the parameter radix can not less than 2 or greater
than
Geir Magnusson Jr wrote:
This is a great example. The last two aren't even legal exceptions for
that method.
It seems like the RI is doing random crap, and it wouldn't be something
that someone would depend on... can you imagine?
Thanks a lot, Geir. There may be a great deal of these
I would suggest another approach.
Since the safe CRT APIs are mostly similar to the original counterpart
but enforcing safety checks and validations, we can take them as
coding conventions, so as to achieve both the safety and portability.
For example, with strcpy, we do this way:
step 1.
The checks in my code example below can be asserts or defined for
debug mode only, if people worry about the performance AND are almost
sure about the safety. But I don't think they are only for debugging
purpose. Optimizations can be done to reduce the overhead.
Thanks,
xiaofeng
On 7/7/06,
Nathan Beyer wrote:
The pieces of Unicode 4.1 that would be of any concern would be the notable
changes [1]. If we were to fully support Unicode 4.1 in some classes, like
Character.UnicodeBlock, there may be some cases of supporting more than the
Java 5 spec (RI). This is probably fine in most
Tim Ellison wrote:
(Apologies for the very late response, I'm way behind on my 'must
respond' list)...
Marina Goldburt wrote:
Hi,
As I see the main idea of the port library is isolates all platform
specific knowledge to one area, as written at
http://svn.apache.org/viewvc
On 7/5/06, George Harley [EMAIL PROTECTED] wrote:
Hi,
Just seen Tim's note on test support classes and it really caught my
attention as I have been mulling over this issue for a little while now.
I think that it is a good time for us to return to the topic of class
library test layouts.
The
Andrew Zhang wrote:
Hello everybody,
I changed the subject to make things clear.
Jimmy, as you mentioned, What's more, I find some operations related to
network are also written
in this way, first select and then read/write/accept/connect, so I guess
all implementation in java.nio.channels
Hello All,
After read through the document recommended by Alex, I think TestNG can
really meet our requirement. It provides much flexibility for test
configuration. ;-)
If we decide to transfer to TestNG, we shall:
1. Identify Harmony testing strategy. (It's not easy)
2. Define TestNG
+1
Dan Lydick
[Original Message]
From: Geir Magnusson Jr [EMAIL PROTECTED]
To: harmony-dev@incubator.apache.org
Date: 7/5/06 6:29:17 PM
Subject: [vote] acceptance of HARMONY-536 : JSEE provider contribution
All is in order and in SVN for Harmony-536 wrt BCC and ACQ.
Please vote to
Mark Hindess wrote:
On 7 July 2006 at 0:43, Ivan Volosyuk [EMAIL PROTECTED] wrote:
On 7/7/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
I can make this patch. One question, is it ok to have same property as
DRLVM for release mode? Like this:
BUILD_CFG=release
I'm happy with release
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
Richard Liang wrote:
Hello All,
After read through the document recommended by Alex, I think TestNG
can really meet our requirement. It provides much flexibility for test
configuration. ;-)
If we decide to transfer to TestNG, we shall:
1. Identify Harmony testing strategy. (It's not easy)
Hi Jimmy
In fact, after I raising Harmony-778, 779, I felt a little guilty, and
didn't have a good sleep. :)
I agree that original implConfigureBlocking is necessary but not sufficient.
Original implConfigureBlocking uses ioctl family function to set underlying
file descriptor, it's correct.
2006/7/7, Gregory Shimansky [EMAIL PROTECTED]:
On Thursday 06 July 2006 20:26 Geir Magnusson Jr wrote:
As part of the work surrounding the HARMONY-677 (r419557), getting DRLVM
to deal with Java5 classfile format, I noticed that DRLVM doesn't
appear to give a hoot what version of the
On 7/7/06, Richard Liang [EMAIL PROTECTED] wrote:
SNIP
We may frequently encounter this confused situation, and I suggest we
discuss the problems case by case if someone is not sure how to do. ;-)
For this case, I decide to follow useRadix(int radix). Please correct
me if I'm wrong. Thanks a
1 - 100 of 102 matches
Mail list logo
