Seems no one objects this proposal:), so I'm going to implement the
JNI1.4 enhancement in nio module, i.e, provide patch to Harmony-578,
Because this implementation requires some native codes, so I probably
need to reintroduce hynio.dll(.so), but I have some questions.(Excuse me
about my
On 19 June 2006 at 8:55, Tim Ellison [EMAIL PROTECTED] wrote:
Mark Hindess wrote:
On 19 June 2006 at 14:03, Mikhail Loenko [EMAIL PROTECTED] wrote:
Good stuff. I was also thinking about separating exclude list from
modules' build.xml.
Yes that definitely makes sense. (I did that in
On 20 June 2006 at 14:18, Paulex Yang [EMAIL PROTECTED] wrote:
Seems no one objects this proposal:), so I'm going to implement the
JNI1.4 enhancement in nio module, i.e, provide patch to Harmony-578,
Because this implementation requires some native codes, so I probably
need to reintroduce
2006/6/20, Geir Magnusson Jr [EMAIL PROTECTED]:
We don't want to do that, distribute third party code that we build.
But as far as I understand we will do that... HDK will include this
libraries. Isn't it?
--
Alexey A. Petrenko
Intel Middleware Products Division
Vladimir Ivanov wrote:
Classes from exclude list are now specified as green.
I've update wiki (http://wiki.apache.org/harmony/Coverage_information)
and
coverage pages.
Great, thank you, Vladimir!
Thanks,
Vladimir
On 6/16/06, Paulex Yang [EMAIL PROTECTED] wrote:
Vladimir
Vladimir
Anton and Tim,
FYI, the Selector implementation has been merged into SVN as patch of
Harmony-41 at revision 415279. So it should be ready to use now. Thank you.
Tim Ellison wrote:
Anton Luht wrote:
Good day,
I've tried to run Azureus, too, and saw all those problems (no SSL
provider,
Hi,
I'm going to start merging existing frameworks for testing serialization.
As first step I've updated 'security' framework. The updated framework
searches and loads resource files according [1] and eliminates requirement
to extend SerializationTest. Also to provide smooth frameworks merging
Hi Daniel,
Thank you for your response and sorry for delay with my answer. Please
find my comments inside.
On 6/15/06, Daniel Fridlender [EMAIL PROTECTED] wrote:
Hi Vladimir,
thank you very much for this new optimization of math from, as you
said, enterprise-level applications point of view.
Hi Mikhail,
AFAIK, we haven't such kind of tests in svn yet. It's hard to define
best place for it, but since this suite is intended for java.math
testing only and it's implementation-independent tests, I believe
modules/math/src/test/java/tests/api is appropriate place. If you
agree with this I
Archie Cobbs wrote:
Ivan Volosyuk wrote:
IMHO, Archie's suggestion is simplier and less intrusive, as the
function Thread.attachInternal() can be native function implemented in
classlibadapter itself.
But Graeme is correct in that there could be initialization delay.
I.e., if we're
Alexey Petrenko wrote:
2006/6/18, Mark Hindess [EMAIL PROTECTED]:
On 18 June 2006 at 22:16, Alexey Petrenko
[EMAIL PROTECTED] wrote:
2006/6/18, Mark Hindess [EMAIL PROTECTED]:
c) I'm also wondering about the motivation for using C++ when I can't
see any pressing reason to require this.
Hi,
The problem is in the order of the linked libs. the order is important for
gcc.
Change components/vm/vmi, the order must be:
libset libs=hyzip dir=${external.dep.CLASSLIB.libdir} /
libset libs=hypool dir=${external.dep.CLASSLIB.libdir} /
libset libs=hyprt
Vladimir Ivanov wrote:
On 6/20/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
On Monday 19 June 2006 20:33 Anton Luht wrote:
It is not a good idea to put creation of such resources in something
like setUp() method in JUnit test because who knows if a read-only
file created by VM under
2006/6/20, Tim Ellison [EMAIL PROTECTED]:
Alexey Petrenko wrote:
2006/6/18, Mark Hindess [EMAIL PROTECTED]:
On 18 June 2006 at 22:16, Alexey Petrenko
[EMAIL PROTECTED] wrote:
2006/6/18, Mark Hindess [EMAIL PROTECTED]:
c) I'm also wondering about the motivation for using C++ when I can't
On 6/20/06, Vladimir Ivanov wrote:
Thanks Stepan,
1. The decision about other resource files is: they should be stored into
src/test/resources/ without further naming convention. Right? – then,
a) Ideally, can we specify further (after src/test/resources/)
naming
convention for resource
Paulex Yang wrote:
Mark Hindess wrote:
snip
Yes. Since this header forms part of the API it probably should be
moved to deploy/include at build time - like the other headers for the
classlib natives API.
I see, but seems not all header files in LUNI are copied into
deploy/include now,
Paulex Yang wrote:
Anton and Tim,
FYI, the Selector implementation has been merged into SVN as patch of
Harmony-41 at revision 415279. So it should be ready to use now. Thank you.
Cool -- thanks Paulex.
Can you easily repeat the experiment Anton? It would be good if you put
your method on
Paulex Yang wrote:
Seems no one objects this proposal:), so I'm going to implement the
JNI1.4 enhancement in nio module, i.e, provide patch to Harmony-578,
Because this implementation requires some native codes, so I probably
need to reintroduce hynio.dll(.so), but I have some
Stepan,
Cool! Basically I'm fine with the merging plan, and I'm very interested
in more details, please see my comments below:
Stepan Mishura wrote:
Hi,
I'm going to start merging existing frameworks for testing serialization.
As first step I've updated 'security' framework. The updated
Oliver Deakin wrote:
Paulex Yang wrote:
Seems no one objects this proposal:), so I'm going to implement the
JNI1.4 enhancement in nio module, i.e, provide patch to Harmony-578,
Because this implementation requires some native codes, so I probably
need to reintroduce hynio.dll(.so), but I have
Hi Paulex,
see answers below
On 6/20/06, Paulex Yang wrote:
Stepan,
Cool! Basically I'm fine with the merging plan, and I'm very interested
in more details, please see my comments below:
Stepan Mishura wrote:
Hi,
I'm going to start merging existing frameworks for testing
serialization.
Hello Paulex,
I will start to implement the constructor and some simple methods such
as ioException(), locale(), etc. Then I'm going to implement the methods
from j.u.Iterator. At last, I will touch the pattern matching methods.
Really, as you said, the complexity is far beyond my
Hi Nathan,
Yes, seeing this too. Suspect that the Swing and AWT manifests are
currently broken and that this is upsetting PDE. Perhaps things can be
temporarily solved for you by reverting your Eclipse PDE target to a
build prior to the Swing/AWT ? Assuming you have one lying around.
Best
Dear All,
I find this bug when preparing for implementing j.u.Scanner. Could
anyone have a look at this issue? Thanks a lot.
Richard Liang (JIRA) wrote:
java.util.regex.Pattern fails to compile some patterns
--
Key: HARMONY-606
Hi Paulex,
Sorry about that. Requested change made in revision 415600.
Best regards,
George
Paulex Yang wrote:
George,
nio project cannot compile in my Eclipse after this revision, seems
the MANIFEST.MF needs to add tests.util to Import-Package section as
below, would you please have a
George,
It works now, thank you!
George Harley wrote:
Hi Paulex,
Sorry about that. Requested change made in revision 415600.
Best regards,
George
Paulex Yang wrote:
George,
nio project cannot compile in my Eclipse after this revision, seems
the MANIFEST.MF needs to add tests.util to
splendid. Thanks
Mark Hindess wrote:
On 20 June 2006 at 1:05, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I've been puttering about and am having a problem under linux.
Everything builds now, and APR is built using the standard ./configure
make combination. No big deal.
But I seem to
Thanks!
Yes, that solved is.
Marina Goldburt wrote:
Hi,
The problem is in the order of the linked libs. the order is important for
gcc.
Change components/vm/vmi, the order must be:
libset libs=hyzip dir=${external.dep.CLASSLIB.libdir} /
libset libs=hypool
Geir,
There's some rather straight-forward stuff to do in Eclipse plus some
less trivial config options description and some debug scenarios. I
hope the info can be of help to you.
I know it's hard to believe, but what about if someone isn't using
eclipse? ;)
The doc has some scenarios
described on testing and serialization convention pages.
Yes, it'll be useful. But currently few resource files follow conventions
Not only resource files.
The Testing convention document (testing.html) says:
1) Tests, their resources, and support classes are located under
Hello Richard,
Thank you for this find. For some reason I've missed these character classes.
Will update JIRA issue in a moment.
--
Regards,
Nikolay Kuznetsov,
Intel Middleware Products Division
-
Terms of use :
I think they are not unit tests and should go to a different
(performance?) test
suite. Right now we don't have one but it seems to be time to create it
Thanks,
Mikhail
2006/6/20, Vladimir Strigun [EMAIL PROTECTED]:
Hi Mikhail,
AFAIK, we haven't such kind of tests in svn yet. It's hard to
Alexey Petrenko wrote:
2006/6/20, Geir Magnusson Jr [EMAIL PROTECTED]:
We don't want to do that, distribute third party code that we build.
But as far as I understand we will do that... HDK will include this
libraries. Isn't it?
We will include third party libraries that are build and
2006/6/20, Vladimir Ivanov [EMAIL PROTECTED]:
Thanks Stepan,
1. The decision about other resource files is: they should be stored into
src/test/resources/ without further naming convention. Right? – then,
a) Ideally, can we specify further (after src/test/resources/) naming
convention for
I now have drlvm working w/ independent classlib and configure/make
building of APR on linux.
I had a lot of fun working through a lot of the gcc issues that others
have. It was a good refresher course for me. It's working on Ubuntu
6.whatever using gcc/g++ version 3.4 and Sun's java 5.
I can
Build and dependency issues aside, what are the next functional
enhancements / features for DRLVM?
I think #1 is to get it to function with Java 5 classfiles, so we can
make the switch throughout the project.
Thoughts? What else?
geir
2006/6/20, Vladimir Ivanov [EMAIL PROTECTED]:
described on testing and serialization convention pages.
Yes, it'll be useful. But currently few resource files follow conventions
Not only resource files.
The Testing convention document (testing.html) says:
1) Tests, their resources, and
Indeed, unless you are extremely paranoid that all the other API
implementations wrong, but are conspiring to make your test pass then
you should assume that everything else is working ok and you are testing
some specific piece of functionality.
Why should we have gold files then? Let's imagine
I'd like to start assembling a high-level roadmap of the milestones we'd
like to achieve in the next 12 months.
I volunteer to track and organize, but this clearly is a community
activity so lets start by just tossing out ideas.
1) By ApcheCon EU - a combined snapshot that is a pure open source
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 achieve in the next 12 months.
I volunteer to track and organize, but this clearly is a community
activity so lets start by just tossing out ideas.
1) By ApcheCon EU
11) em64t/ipf platform support
On 6/20/06, 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 achieve in the next 12 months.
I volunteer to track and organize, but this
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 achieve in the next 12 months.
I volunteer to track and organize, but this clearly is a
On 6/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
I think they are not unit tests and should go to a different
(performance?) test
suite. Right now we don't have one but it seems to be time to create it
Of course, it's not unit tests, but my suggestion was based on our
testing convention.
Great progress - it started and looks similar to Azureus launched on RI.
Unfortunately I'm behind a firewall so I can't test it fully (and,
frankly speaking, I've never used it before I tried to run it on
Harmony so I don't know for sure how to use it properly :) )
--
Regards,
Anton Luht,
Intel
Paulex Yang wrote:
OK, this is nice and simple.. installing an interrupt action is a clean
and Java-centric way to make the handling of interrupts explicit. It may
be technically unnecessary (if POSIX signals were available) but has
the advantage of being less tied to the O/S and VM internals.
Anton Luht wrote:
Great progress - it started and looks similar to Azureus launched on RI.
Unfortunately I'm behind a firewall so I can't test it fully (and,
frankly speaking, I've never used it before I tried to run it on
Harmony so I don't know for sure how to use it properly :) )
Cool --
I've been through and fixed the manifest and classpath files for the
incoming Swing/AWT/Accessibility/Misc code (in repo r415629).
Regards,
Tim
George Harley wrote:
Hi Nathan,
Yes, seeing this too. Suspect that the Swing and AWT manifests are
currently broken and that this is upsetting
Cool -- can't wait to try it.
Did you have to hack any of the Azureus code assumptions to get it
working? (i.e. BKS or HARMONY-536 JSSE provider)
No, I just ran it 'as is' - old errors are in place:
DEBUG::Tue Jun 20 18:25:02 MSD
Hi Tim,
Thank you very much, it all works fine for me now. Hopefully things are
now fixed for Nathan (and everyone else) too.
Best regards,
George
Tim Ellison wrote:
I've been through and fixed the manifest and classpath files for the
incoming Swing/AWT/Accessibility/Misc code (in repo
Oops. Thanks Tim. And thanks for fixing up my Eclipse/MANIFEST
mess. I'll try a little harder with my cut'n'paste creation of these
next time. I wonder if we can add tests to the builds to catch these
problems?
Regards,
Mark.
On 20 June 2006 at 13:19, [EMAIL PROTECTED] wrote:
Author:
Geir Magnusson Jr wrote:
Build and dependency issues aside, what are the next functional
enhancements / features for DRLVM?
I think #1 is to get it to function with Java 5 classfiles, so we can
make the switch throughout the project.
Thoughts? What else?
As far as I can tell, general
2006/6/20, Mark Hindess [EMAIL PROTECTED]:
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 achieve in the next 12 months.
I volunteer to
On 6/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Build and dependency issues aside, what are the next functional
enhancements / features for DRLVM?
I think #1 is to get it to function with Java 5 classfiles, so we can
make the switch throughout the project.
Thoughts? What else?
I agree
On 20 June 2006 at 20:19, Alexey Petrenko [EMAIL PROTECTED] wrote:
2006/6/20, Mark Hindess [EMAIL PROTECTED]:
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
Geir Magnusson Jr wrote:
I'd like to start assembling a high-level roadmap of the milestones we'd
like to achieve in the next 12 months.
I volunteer to track and organize, but this clearly is a community
activity so lets start by just tossing out ideas.
1) By ApcheCon EU - a combined
Anton Luht wrote:
Great progress - it started and looks similar to Azureus launched on RI.
Unfortunately I'm behind a firewall so I can't test it fully (and,
frankly speaking, I've never used it before I tried to run it on
Harmony so I don't know for sure how to use it properly :) )
Azureus
-Original Message-
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 20, 2006 1:16 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [general] milestones and roadmap
Geir Magnusson Jr wrote:
I'd like to start assembling a high-level roadmap of the
Magnusson, Geir wrote:
-Original Message-
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 20, 2006 1:16 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [general] milestones and roadmap
Geir Magnusson Jr wrote:
I'd like to start assembling a high-level
2006/6/20, Mark Hindess [EMAIL PROTECTED]:
16) Port to MacOS X
This could be the same as 13 but I was thinking of linux/ppc64. MacOSX
would be more interesting but I think it makes sense to change one
aspect of the platform at a time. So you are right to make this a
separate item.
And I was
On Tuesday 20 June 2006 19:44 Salikh Zakirov wrote:
Geir Magnusson Jr wrote:
Build and dependency issues aside, what are the next functional
enhancements / features for DRLVM?
I think #1 is to get it to function with Java 5 classfiles, so we can
make the switch throughout the project.
On 6/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I'd like to start assembling a high-level roadmap of the milestones we'd
like to achieve in the next 12 months.
I volunteer to track and organize, but this clearly is a community
activity so lets start by just tossing out ideas.
1) By
Stefano Mazzocchi skrev den 20-06-2006 19:21:
If you guys write a little how to on the wiki on how to build the
thing from scratch on linux from sources, I'll be happy to try azureus
on harmony with some 10Gb torrent files and report back on the wiki.
I did that recently with the IBM JVM,
I've jumped ahead a bit on the pack200 archive, and written the
unpacking for file data stored in a pack200 archive. The current
implementation will barf if the file size is 2Gb, because I'm
pulling all the data into a byte array at present (it's pretty memory
hungry anyway).
I've not got any
On 6/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Build and dependency issues aside, what are the next functional
enhancements / features for DRLVM?
I think #1 is to get it to function with Java 5 classfiles, so we can
make the switch throughout the project.
Geir,
Good question. By
Ming,
I looked at JIRA 622. It looks like there are 22 pages of new
assembly code and about 26 pages of new java code. Perhaps you could
give us a summary of what the assembly code does and why it can't be
done in Java.
Also, I would like to see the code you developed that JITs the GC. It
On 6/20/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
On Tuesday 20 June 2006 19:44 Salikh Zakirov wrote:
Geir Magnusson Jr wrote:
Build and dependency issues aside, what are the next functional
enhancements / features for DRLVM?
I think #1 is to get it to function with Java 5
On 6/20/06, Rana Dasgupta [EMAIL PROTECTED] wrote:
On 6/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Build and dependency issues aside, what are the next functional
enhancements / features for DRLVM?
I think #1 is to get it to function with Java 5 classfiles, so we can
make the switch
Was it just that the value of the Import-Package had a newline before the
actual package names? I was just frustrated with myself that I couldn't
figure it out.
I like how OSGi uses the manifest, but manifest file format is the most
fragile thing I've ever dealt with; one wrong whitespace or
As mentioned in the [general] milestones and roadmap thread, work on
integrating the concurrency APIs will require VM support and it seems like
DRLVM is close to having some of it complete, so I would lobby for that.
The VM APIs need are atomic CAS, parking and possibly methods for set/get of
Hi Mark,
I believe that 'move' means copying file with its revisions history. This
can be done by 'svn move'. You did this for 'hyproperties.xml' file but not
for 'build.xml' file. Why? Yes, it is possible to figure out from its
initial revision (415681) what was the origin. But I prefer to have
On 6/21/06, Alex Blewitt wrote:
SNIP
I'd also like to suggest that we try to move the pack200 code out of
the archive module into its own dedicated archive-pack200 module. If
this code is to be reused in other environments (whether part of a
classlib/J2SE implementation, or as a library/driver
Hi Tim,
AlgorithmParameterGenerator.init(int) doesn't declare exceptions to be
thrown[1].
Thanks,
Stepan.
[1]
http://java.sun.com/j2se/1.5.0/docs/api/java/security/AlgorithmParameterGenerator.html#init(int
)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent:
Archie Cobbs wrote:
Paulex Yang wrote:
OK, this is nice and simple.. installing an interrupt action is a clean
and Java-centric way to make the handling of interrupts explicit. It
may
be technically unnecessary (if POSIX signals were available) but has
the advantage of being less tied to the
Weldon,
2006/6/21, Weldon Washburn [EMAIL PROTECTED]:
I looked at JIRA 622. It looks like there are 22 pages of new
assembly code and about 26 pages of new java code. Perhaps you could
give us a summary of what the assembly code does and why it can't be
done in Java.
Don't worry about
74 matches
Mail list logo
