we do
this for the HyPortLibrary (see
luni/src/main/native/include/shared/vmi.h)?
Thanks,
Andrey.
On 11/10/06, Andrey Chernyshev [EMAIL PROTECTED] wrote:
On 10/26/06, Angela Lin [EMAIL PROTECTED] wrote:
On 10/24/06, Weldon Washburn [EMAIL PROTECTED] wrote:
If an arbitrary
-dev/200606.mbox/[EMAIL
PROTECTED]
SY, Alexey
--
Andrey Chernyshev
Intel Enterprise Solutions Software Division
inspecting the thread state.
Using layer (1) directly would bypass the thread state tracking.
Angela
--
Weldon Washburn
Intel Middleware Products Division
--
Andrey Chernyshev
Intel Enterprise Solutions Software Division
On 11/9/06, Nathan Beyer [EMAIL PROTECTED] wrote:
On 11/8/06, Andrey Chernyshev [EMAIL PROTECTED] wrote:
On 11/8/06, Tim Ellison [EMAIL PROTECTED] wrote:
Nathan Beyer wrote:
Instead of continuing to add functionality to the DRLVM-specific
Atomics class, I'd like to get a consensus
support from both VMs.
+1
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
--
Andrey Chernyshev
Intel Enterprise Solutions Software Division
I
want to move forward I will do required changes to remove
vm_create_jthread from TM. I believe that will resolve all our
disagreements and the patch will be applied soon.
Thanks
Evgueni.
On 10/4/06, Andrey Chernyshev [EMAIL PROTECTED] wrote:
On 10/3/06, Evgueni Brevnov [EMAIL PROTECTED
Evgueni
On 10/2/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
On 9/29/06, Andrey Chernyshev [EMAIL PROTECTED] wrote:
On 9/29/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
Artem,
Thank you for your feedback find my inlined.
On 9/29/06, Artem Aliev [EMAIL PROTECTED] wrote
On 10/3/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
On 10/3/06, Andrey Chernyshev [EMAIL PROTECTED] wrote:
On 10/2/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
Andrey,
Just to be clear I agree with you it is more convenient if
jthread_create takes JNIEnv instead of JavaVM
Magnusson Jr. [EMAIL PROTECTED] wrote:
So where are we here?
On Sep 28, 2006, at 12:41 AM, Evgueni Brevnov wrote:
On 9/28/06, Weldon Washburn [EMAIL PROTECTED] wrote:
On 9/26/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
On 9/27/06, Andrey Chernyshev [EMAIL PROTECTED
On 9/27/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
On 9/27/06, Andrey Chernyshev [EMAIL PROTECTED] wrote:
On 9/26/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:
Alexey Varlamov [26/Sep/06 05:11 AM]
Evgueni, thank you, quite impressive work!
Unfortunately patch is so huge it is hard
/26/06, Tim Ellison [EMAIL PROTECTED] wrote:
Yes, exactly.
Regards,
Tim
Andrey Chernyshev wrote:
On 9/26/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
On Sep 26, 2006, at 7:09 AM, Tim Ellison wrote:
Weldon, I agree with your comments and observations below.
Let's
take
baby
-Original Message-
From: Andrey Chernyshev [mailto:[EMAIL PROTECTED]
Sent: Sunday, September 24, 2006 6:44 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][vmi] VMI classes for Thread/Object manipulation
for java.util.concurrent
On 9/22/06, Tim Ellison [EMAIL PROTECTED] wrote
PROTECTED]
--
Andrey Chernyshev
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]
://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrey Chernyshev
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org
On 9/20/06, Tim Ellison [EMAIL PROTECTED] wrote:
Andrey Chernyshev wrote:
Thanks Nathan! The Threads interface looks fine. Still, may be it
would be nice if two different methods are allocated for parkNanos and
parkUntil - passing the extra boolean parameter seems like an
overhead, though
for java.util.concurrent
Andrey Chernyshev wrote:
Thanks Nathan! The Threads interface looks fine. Still, may be it
would be nice if two different methods are allocated for parkNanos and
parkUntil - passing the extra boolean parameter seems like an
overhead, though very little.
I agree, just create
, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrey Chernyshev
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail
/vmcore/src/kernel_classes/javasrc/org/apache/harmony/util/concurrent/Atomics.java?view=markup
--
Andrey Chernyshev
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
for Windows?
--
Andrey Chernyshev
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]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrey Chernyshev
Intel Middleware Products Division
, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrey Chernyshev
Intel Middleware
Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrey Chernyshev
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]
--
Andrey Chernyshev
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]
--
Andrey Chernyshev
Intel Middleware Products Division
: http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrey Chernyshev
Intel Middleware Products Division
-
Terms of use : http
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrey Chernyshev
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]
--
Andrey Chernyshev
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]
--
Andrey Chernyshev
Intel Middleware Products Division
-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrey Chernyshev
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL
details about this in the issue description, I'd
be happy to provide more if needed.
Thanks,
Andrey.
--
Andrey Chernyshev
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
to fix this issue
if someone doesn't already know how. Volunteers?
Thanks,
Vladimir.
On 7/18/06, Andrey Chernyshev [EMAIL PROTECTED] wrote:
On 7/17/06, Vladimir Gorr [EMAIL PROTECTED] wrote:
On 7/17/06, Salikh Zakirov [EMAIL PROTECTED
On 7/17/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Andrey Chernyshev wrote:
On 7/13/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Andrey Chernyshev wrote:
SNIP!
or:
launcher calls CreateJavaVM()
CreateJavaVM() passes call to create_vm()
create_vm() makes its usual calls and returns. A flag
On 7/17/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Andrey Chernyshev wrote:
On 7/13/06, Tim Ellison [EMAIL PROTECTED] wrote:
Andrey Chernyshev wrote:
snip
(4)
Launcher wants the vm dll in the default directory unless the option
is specified. Should we realign the drlvm build output
PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrey Chernyshev
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED
On 7/13/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Andrey Chernyshev wrote:
With some changes I was able to run the DRLVM with classlib's
launcher. Here is what I did (you can see the experimental patch at
http://issues.apache.org/jira/browse/HARMONY-857):
- I have added JNI_CreateJavaVM
PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrey Chernyshev
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED
working, I'm wondering if there is a more graceful way to do this.
Thanks,
Andrey.
On 7/11/06, Andrey Chernyshev [EMAIL PROTECTED] wrote:
OK, so I'm going to add CreateJavaVM into vm\vmcore\src\jni\jni.cpp
and also add implementation into DestroyVM (stub is already seem to be
present there) based
. Maybe OK to hookup and fix bugs as we go.
Thanks,
Rana
On 7/10/06, Andrey Chernyshev [EMAIL PROTECTED] wrote:
Yes, it seems like the launcher will need at least JNI_CreateJavaVM
and DestroyJavaVM functions.
I couldn't find implementation for CreateJavaVM in drlvm codebase.
Perhaps
.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrey Chernyshev
Intel Middleware Products Division
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]
--
Andrey Chernyshev
Intel Middleware Products
On 7/10/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Andrey Chernyshev wrote:
On 7/7/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Andrey Chernyshev wrote:
I was trying to compile the kernel classes set from DRLVM
independently
from the classlib and found it difficult because kernel classes
/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrey Chernyshev
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
On 7/7/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Andrey Chernyshev wrote:
I was trying to compile the kernel classes set from DRLVM independently
from the classlib and found it difficult because kernel classes set
currently have a dependence on the internal classlib API, e.g
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrey Chernyshev
Intel Middleware Products Division
,
Andrey.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrey Chernyshev
Intel Middleware Products Division
#pkg_java_lang
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrey Chernyshev
Intel Middleware Products Division
Hi Tim,
On 7/4/06, Tim Ellison [EMAIL PROTECTED] 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
On 7/4/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Andrey Chernyshev wrote:
4) Change the drlvm build so that its deploy tree layout has no classlib
files in it. So we can do ...
As a first step, I suggest that we make drlvm build completely free
from the classlib-related tasks
VM-specific code?
I guess it will simplify a bit the org.apache.harmony.kernel.vm.VM
interface as well as would allow to avoid extra dependencies between
VM and classlib.
--
Andrey Chernyshev
Intel Middleware Products Division
]
--
Andrey Chernyshev
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]
?
Thanks,
Andrey.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200603.mbox/[EMAIL
PROTECTED]
--
Andrey Chernyshev
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony
On 7/3/06, Mark Hindess [EMAIL PROTECTED] wrote:
On 3 July 2006 at 15:14, Andrey Chernyshev [EMAIL PROTECTED]
wrote:
I didn't find the exact reason why this happens, looks like a drlvm
ant scripts work differently.
It could be a side effect of the recent adoption of DRLVM build
On 6/29/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Andrey Chernyshev wrote:
Hello,
In addition to the already proposed generic tasks like 5.0 support or
concurrent GC mentioned by Ivan, I'd like to add some more specific
things that might be interesting for people to look at as well
-mail: [EMAIL PROTECTED]
--
Andrey Chernyshev
Intel Middleware Products Division
On 6/24/06, Andrey Chernyshev [EMAIL PROTECTED] wrote:
I wanted to add that patching ant with cpptasks as it is done today should
not
be allowed since system wide installations are usually write protected.
:)
Note that when we're finished, DRLVM shouldn't do anything to the
filesystem
? :)
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrey Chernyshev
Intel Middleware Products Division
On 6/23/06, Tim Ellison [EMAIL PROTECTED] wrote:
Marina Goldburt wrote:
Hi,
I've noticed such a strange thing when examined drlvm building process.
The drlvm replaces hythreads shared library with its own simple
implementation based on APR. The drlvm hythreads library exports less
than 1/2
On 6/26/06, Anton Luht [EMAIL PROTECTED] wrote:
Good day,
Though DRLVM is in the repository already, the classlib building
instructions [1] still says nothing about it in the section Obtaining
a compatible VM . I coudn't find instructions on building DRLVM on
the site, either - I found them
On 6/23/06, Naveen Neelakantam [EMAIL PROTECTED] wrote:
This issue has been fixed in log4cxx: http://issues.apache.org/jira/
browser/LOGCXX-130. Specifically, the fix was applied in r384272 of
log4cxx.
I did some digging around, and patched versions of domconfigurator.h
and unicodehelper.h are
regular testing infrastructure which would
monitor the issues, but I'm assuming this won't come quickly.
Thoughts?
Thank you,
Andrey Chernyshev
Intel Middleware Products Division
On 6/23/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Odd. Nothing should have changed re log4cxx
Sure nothing else
How about the idea of independence between VM and classlib, isn't this
VM who decides where and how it loads the boot classes?
Given the comment in the head of the bootclasspath.properties file:
# The bootclasspath properties define elements of the virtual machine's
# boot class path.
I would
that given the eventual creations of the
massive file, build.tmp.xml
build.tmp.xml is produced just to put all modules together into a
single file in order to process the dependencies between the modules
correctly.
Thank you,
Andrey Chernyshev
Intel Middleware Products Division
On 6/7/06, Geir
On 6/21/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
You can always take a look at what command lines build calls C compiler if you
call build.bat with -d switch (it is just passed to ant). I am not sure if it
One more tip to see what Ant really executes for you is to run:
build.sh
I now have drlvm working w/ independent classlib and configure/make
building of APR on linux.
This is great, thanks! One more suggestion - what if we try using the
precompiled binaries for APR, Log4cxx? Their compilation takes the
significant time and may be extra cause of various building
orig = arr[i];
compareAndSet(i, 0, 0); // do CAS with whatever value, this
ensures cache is flushed;
return arr[i]; // return the master value
In terms of the speed, it must be almost same as doing mfense, at
least on IA32 (mfense is probably 20-30% faster).
Thank you,
Andrey Chernyshev
Intel
. until we get the whole picture. How
does that approach sound?
BTW, does SableVM assume some component/pluggability model around it?
It would be interesting to see how far is it from the proposed OPEN
concepts, what works in the OPEN specifically for SableVM and what
doesn't, e.t.c.
Thank you,
Andrey
be the right location for these modules, should they be a part
of VM or a part of classlib?
Thanks,
Andrey.
On 5/25/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Andrey Chernyshev wrote:
On 5/23/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Andrey Chernyshev wrote:
Returning back
On 5/23/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Andrey Chernyshev wrote:
Returning back to the subject of this discussion, I guess it should be
relatively easy to modify the DRLVM building system such that it would
get the binary HDK from web and use it for compilation of a single
On 5/19/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
IMHO, I would prefer new patch attached. Say, named like:
DRLVM-GCC-3.4_and_4.x-cumulative_v2.patch
DRLVM-GCC-3.4_and_4.x-cumulative_20060519.patch
It could help people if something is working with old patch and
suddenly stop working with new
internal
API's (like OPEN?) across multiple VM's, which certainly isn't the
case at the moment :)
Thanks,
Andrey.
On 5/19/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Andrey Chernyshev wrote:
On 5/18/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Andrey Chernyshev wrote:
We would not want to couple
On 5/18/06, Alexey Petrenko [EMAIL PROTECTED] wrote:
2006/5/18, Gregory Shimansky [EMAIL PROTECTED]:
If you talk about developers only there is no need for swing.jar or tweaks
like that. Developers already have some kind of java SDK installed and the
place to solve missing dependencies is
just thought it could be convenient for developers (as well as for
Harmony users) to take a complete workable JRE without an additional
need to combine something together.
Thank you,
Andrey Chernyshev
Intel Middleware Products Division
On 5/18/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Mark
deploy/
\jdk
|include
\jre
...
2) I was wondering how this change will affect the DRLVM? I notice from
building
the VM locally that it produces a deploy\jre\bin structure, so I imagine
that some
small path changes to build scripts would be necessary (similar to
Working with Geronimo, I've got acquainted with Maven
http://maven.apache.org/ build system, which solves this issue for
pure-java projects:
Do you have an idea how it would handle the mixed projects? I guess VM
modules you are suggesting to split will mostly consist of the native
code, at
=your_proxy_port#
at build\make\*.properties files.
Andrey Chernyshev
Intel Middleware Products Division
--
Weldon Washburn
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe
wrote:
Andrey Chernyshev wrote:
snip
(1) Do we need to keep the 'main' directory in every module? If we
need to have a distinction between tests and sources, may be just pull
tests one level up and have something like:
archive/
src/
native/
java
Hi All,
I'd like to mention one more issue concerned with the broken https
access: the building script supplied with the DRLVM is currently
checking out sources for class libraries from
https://svn.apache.org/... . Though it can be easily changed in a
build property file, this still may create
with DRLVM can easily be used to
support the source modularization approach, the proposed 'hdk' in that
case would provide the developers, besides the public includes, with
the shared part of the building scripts as well.
Thank you,
Andrey Chernyshev
Intel Middleware Products Division
Hi Gregory,
1. Many shared libraries in classlib are built without -fPIC option. As far as
Thanks for noting this! Looks like fPIC is just missed in several places.
I can create a JIRA issue with the patch because I think that all classlib
shared libraries should be built with -fPIC. Maybe
Using gcc 3.3.6, I'm stuck building native of vm.jitrino with link
errors:
I can suggest that link errors may be result of previous compilation
with GCC 4.0 and then subsequent attempt to link with GCC 3.3.6.
You may do the build clean first if you are changing the things like
compiler, or,
have worked as well.
I'm trying to build on my linux box now!
Thanks,
Chris Elford
Intel Middleware Products Division
-Original Message-
From: Andrey Chernyshev [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 03, 2006 7:16 AM
To: harmony-dev@incubator.apache.org
Subject: DRLVM
will still be
needed to integrate it with the most recent version of the class libraries.
You are welcome to try it and share your opinion!
Thank you,
Andrey Chernyshev
Intel Middleware Products Division
-
Terms of use : http
the Intel lingo ;-) )
I appreciate just how much work is involved in making such a large
contribution into the project -- you guys are stars!
Go Harmony!
Regards
Tim
Andrey Chernyshev wrote:
Dear All,
I'm happy to announce the contribution of the DRL Virtual Machine on
behalf of
Intel.
I have
Is there any particular reason for using C++?
Well, there was no any specific reason to develop in C++ except just
the developer's convenience. Some of the parts, for example - JIT
compiler, were believed to be pretty complex and people didn't see how
it can be easily done without exploiting
Chernyshev
Intel Middleware Products Division
-Matt
--- Andrey Chernyshev [EMAIL PROTECTED]
wrote:
(a bunch of stuff I snipped ;)
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
for Harmony.
I've tried to use standard filename and
containsregex selectors,
but they didn't appear suitable for that purpose.
Thank you,
Andrey Chernyshev
Intel Middleware Products Division
-Matt
--- Andrey Chernyshev [EMAIL PROTECTED]
wrote:
(a bunch of stuff I
that there is an
appeal process which can help to fix the spec/RI inconsistencies. In
particular, it would address the issue when RI doesn't conform to the
spec for some reason while the variety of apps are already dependent
on a wrongly thrown exception.
Thank you,
Andrey Chernyshev
Intel Middleware
.
Agreed. I think it would be great if we can keep our inter-component
interfaces (like vmi.h) platform independent.
Thank you,
Andrey Chernyshev
Intel Middleware Products Division
Hence, the most efficient (in terms of code
sharing and readability) code placement would
,
Andrey Chernyshev
Intel Middleware Products Division
Hence, the most efficient (in terms of code
sharing and readability) code placement would require a maximum
flexibility, though preserving some well-defined rules. The scheme
based on file dir/name matching seems to be flexible enough
at a candidate
for code separation.
I agree, this seems to be a good criteria for choosing between defines
and dir/file names.
Thank you,
Andrey Chernyshev
Intel Middleware Products Division
Finally, I'd suggest that the platform dependent code can be organized
in 3 different ways:
(1
.
How does the above proposal sound?
Thank you,
Andrey Chernyshev
Intel Middleware Products Division
Maybe in some components we would want to include a window manager
family too, though let's cross that bridge...
I had a quick hunt round for a recognized standard or convention for OS
and CPU
agree with the point that having a
shared layer for two different projects, like HTTPD and Harmony, could
be beneficial for both of them.
Thank you,
Andrey Chernyshev
Intel Middleware Products Division
The GNU/Classpath guys, for example, have defined a standard interface
to underlying OS
library,
hence the luck of creating equal zip files is likely to depend on it's
portability anyways :).
Thank you,
Andrey Chernyshev
Intel Middleware Products Division
On 2/6/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
We're trying...
Leo Simons wrote:
On Mon, Feb 06, 2006 at 04:39:27PM
[ http://issues.apache.org/jira/browse/HARMONY-39?page=all ]
Andrey Chernyshev updated HARMONY-39:
-
Attachment: regex_beans_math_src_20060120_1845-Harmony.tgz
Repacked using gtar
Contribution of beans, regex and math classlibrary code
/regex_beans_math_src_20060120_1845-Harmony.tgz),
hopefully either one or another bundle will work for the everyone.
Please let me know if there are still difficulties extracting the contents.
Thank you,
Andrey Chernyshev
Intel Middleware Products Division
Geir Magnusson Jr wrote:
Ooh. That's
it
be related to the new security code integration? Were you able to pass
security2 tests which utilize SHA?
Thank you,
Andrey Chernyshev
Intel Middleware Products Division
On 1/30/06, Stepan Mishura [EMAIL PROTECTED] wrote:
I tried this contribution in the following way: I've substituted the current
/HARMONY-39.
There were also some mails around it:
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200601.mbox/[EMAIL
PROTECTED]
Thank you,
Andrey Chernyshev
Intel Middleware Products Division
Contribution of beans, regex and math classlibrary code
---
Key: HARMONY-39
URL: http://issues.apache.org/jira/browse/HARMONY-39
Project: Harmony
Type: New Feature
Components: Contributions
Reporter: Andrey
[ http://issues.apache.org/jira/browse/HARMONY-39?page=all ]
Andrey Chernyshev updated HARMONY-39:
-
Attachment: regex_beans_math_src_20060120_1845-Harmony.zip
Beans / regex / math pacakges contribution from Intel
Contribution of beans, regex
with this
code. But, should any additional clarifications be required, I'll be happy to
provide them. You are welcome to try it out!
Thank you,
Andrey Chernyshev
Intel Middleware Products Division
1 - 100 of 105 matches
Mail list logo
