On Saturday 21 October 2006 05:05 Rana Dasgupta wrote:
> On 10/20/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> > >But you are right, the dependencies graph of all VM internal >headers is
> >
> > a huge
> >
> > >tangle which should be untangled somehow. Hopefully the > Class.h
> > > cleanup
>
> I think a generic encoding interface exposed by a component could
return for
> a given helper a mask of affected registers, description of input and
return
> parameters, and should not produce any other side effects including
VM calls
As an alternative, we can simply disassemble the return
I looked at adding the nowarn arg for the tests, but 'build-test.xml'
doesn't have a single large compile statement like 'buid-java.xml'
does. The arg would need to be added to the compile-test of every
module's build, which can be done, I was just feeling lazy at the
moment, sorry. :( Also, I had
They are in 'standard' and do use 'links' (svn:externals). Check out
the full path of the original commit message. Using svn:externals just
makes it seem like it's in 'extended', but that's just in your working
copy.
-Nathan
On 10/20/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Thanks for
+1
On Oct 20, 2006, at 11:06 PM, Nathan Beyer wrote:
+1
On 10/20/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
We're trying something a little different. I think Roy Fielding one
said something along the lines of "when a community gets organized
enough to vote itself out of the Incubator
+1
On 10/20/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
We're trying something a little different. I think Roy Fielding one
said something along the lines of "when a community gets organized
enough to vote itself out of the Incubator, it's appropriate."
So to bring the Harmony community
+1
Let's go further!
On 10/21/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
We're trying something a little different. I think Roy Fielding one
said something along the lines of "when a community gets organized
enough to vote itself out of the Incubator, it's appropriate."
So to bring th
+1 !
On 10/21/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
We're trying something a little different. I think Roy Fielding one
said something along the lines of "when a community gets organized
enough to vote itself out of the Incubator, it's appropriate."
So to bring the Harmony communi
On 10/20/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>But you are right, the dependencies graph of all VM internal >headers is
a huge
>tangle which should be untangled somehow. Hopefully the > Class.h cleanup
which
>Pavel is doing now will make a first step in the right direction.
Is thi
All votes are welcome, and encouraged.
geir
Jordan Justen wrote:
I agree with Alexei's comment, and add a +1 non-binding vote. :)
On 10/20/06, Fedotov, Alexei A <[EMAIL PROTECTED]> wrote:
+1
As far as I understand the main goal of incubation is creation of
healthy community. It means that
I agree with Alexei's comment, and add a +1 non-binding vote. :)
On 10/20/06, Fedotov, Alexei A <[EMAIL PROTECTED]> wrote:
+1
As far as I understand the main goal of incubation is creation of
healthy community. It means that all these non-binding +1 votes do bind
us to this project. :-)
With
On 21/10/06, Fedotov, Alexei A <[EMAIL PROTECTED]> wrote:
Alex,
I see and accept your point. I believe that partial commits are a must -
we should be a community.
My point is simple - the code under active development shouldn't be a
subject of beautification - it just should be safe for other Ha
Alex,
I see and accept your point. I believe that partial commits are a must -
we should be a community.
My point is simple - the code under active development shouldn't be a
subject of beautification - it just should be safe for other Harmony
modules. The first goal is to make it work.
With bes
+1
As far as I understand the main goal of incubation is creation of
healthy community. It means that all these non-binding +1 votes do bind
us to this project. :-)
With best regards,
Alexei Fedotov,
Intel Java & XML Engineering
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL
On 20/10/06, Fedotov, Alexei A <[EMAIL PROTECTED]> wrote:
I agree that if a part of the code is kept for purpose, automatic tools
can destroy it. From the other side, if we check your example, the
following commenting solves the problem.
>// int i;
>// i=someMethod() TODO Fix the bug in someMet
sorry...
please ignore
Alex,
This is a great letter! I cannot compete. I agree with the main point
that no change should be done until the proper understanding of
consequences is achieved.
Nevertheless, from my perspective automatic tools are pretty good for
locating problematic places, and each place usually worth del
Moving from a different thread ...
I'd like to move the pack200 to a separate buildable module, primarily
so that it can be built as its own OSGi bundle and/or Jar, but also to
separate it out from the archive so that e.g. internationalisation
messages etc. don't need to get mixed in.
There's a
There have been a few messages recently regarding build warnings that
complain about e.g. local variables not being used or missing
annotations, and work going on to 'fix' them.
However, in most cases, the only thing that is being 'fixed' is that
the compiler warnings no longer appear. Realistica
Since I am not a committer or ppmc of this podling, my vote is non-binding.
+1
hope to get the Trinidad Podling build done by Harmony soon!
;)
-Matthias
On 10/20/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
+1 from me!
On 10/21/06, Alex Blewitt <[EMAIL PROTECTED]> wrote:
>
> On 20/10/06, Ge
On Saturday 21 October 2006 01:26 Mikhail Fursov wrote:
> On 10/21/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> > I think there is a mistake in the code which Alex wrote (or it would
> > simply throw NPE). It should be
> >
> > class GCv5Magics {
> > static {
> > String gcPat
I can't see any good point in keeping old class files in the build
path for the next run. It's like not running a clean after each build.
I say keep it out :-)
Alex.
On 20/10/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
In the last day or so it seems we have had to do a 'clean' to get a
successf
On Saturday 21 October 2006 01:09 Maksim Ananjev wrote:
> Hi!
>
> I want to use some types defined in Class.h in translator (nothing
> weird here, really?) so I have to include "Сlass.h" into
> "DrlVMCompilationInterface.cpp"
>
> But after having it included I get strange compiler errors.
>
> /work
+1 from me!
On 10/21/06, Alex Blewitt <[EMAIL PROTECTED]> wrote:
On 20/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> [ ] +1 Graduate Apache Harmony from incubation, and let it petition the
> board for Top Level Project status
+1 from me too.
Alex.
---
On 10/21/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
I think there is a mistake in the code which Alex wrote (or it would
simply throw NPE). It should be
class GCv5Magics {
static {
String gcPath = System.getProperty("vm.gc_dll");
-if (gcPath == null) {
+i
Maksim
AFAIK the vm/vmcore/include/Class.h is vmcore internal header and was never
included in JIT.
To use its functionality you should declare the method you need in
vm/include/open/vm.h or in vm/include/open/*class*.h file (sorry I do not
have not svn copy to check the exact name right now) and
On 20/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
[ ] +1 Graduate Apache Harmony from incubation, and let it petition the
board for Top Level Project status
+1 from me too.
Alex.
-
Terms of use : http://incubator.apa
Hi!
I want to use some types defined in Class.h in translator (nothing
weird here, really?) so I have to include "Сlass.h" into
"DrlVMCompilationInterface.cpp"
But after having it included I get strange compiler errors.
/working_vm/vm/include/open/hythread.h:114: error: `I_64' was not
declared
+1
-Mark.
On 20 October 2006 at 15:30, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
>
> We're trying something a little different. I think Roy Fielding one
> said something along the lines of "when a community gets organized
> enough to vote itself out of the Incubator, it's appropriate."
>
+1
Non-binding +1 from me too
Danese Cooper
On Oct 20, 2006, at 12:54 PM, Sam Ruby wrote:
[x] +1 Graduate Apache Harmony from incubation, and let it
petition the board for Top Level Project status
- Sam Ruby
-
Terms of use :
[x] +1 Graduate Apache Harmony from incubation, and let it petition the
board for Top Level Project status
- Sam Ruby
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
+1 from me for sure.
Geir Magnusson Jr. wrote:
We're trying something a little different. I think Roy Fielding one
said something along the lines of "when a community gets organized
enough to vote itself out of the Incubator, it's appropriate."
So to bring the Harmony community and the Incub
All - just so you know, the ASF is moving it's infrastructure this
weekend, so there will be outages of services.
geir
Original Message
Subject: [NOTICE] Scheduled downtime for critical infrastructure
Date: Wed, 18 Oct 2006 16:53:50 -0700
From: Sander Striker <[EMAIL PROTECTED
+1
Good luck!
Etienne
Geir Magnusson Jr. wrote:
> [...]
> So, without any further ado :
>
> [ ] +1 Graduate Apache Harmony from incubation, and let it petition the
> board for Top Level Project status
>
> [ ] 0 No opinion
>
> [ ] -1 No, don't graduate Harmony. Here's why :
>
>
> This vote
Mikhail Fursov wrote:
Alex,
we still have a problem with your solution :(
System.loadLibrary does not accept full paths, but -Dvm.em_dll could be a
full path to a library. IMO the workaround with parsing the path and
adjusting "java.library.path" before loading a library is bad solution.
Any tho
+1 from me
Geir Magnusson Jr. wrote:
We're trying something a little different. I think Roy Fielding one
said something along the lines of "when a community gets organized
enough to vote itself out of the Incubator, it's appropriate."
So to bring the Harmony community and the Incubator commu
We're trying something a little different. I think Roy Fielding one
said something along the lines of "when a community gets organized
enough to vote itself out of the Incubator, it's appropriate."
So to bring the Harmony community and the Incubator community together
for this important event
Just so there is some context for what will follow
Original Message
Subject: Harmony graduation vote on harmony-dev
Date: Fri, 20 Oct 2006 15:20:31 -0400
From: Geir Magnusson Jr. <[EMAIL PROTECTED]>
Reply-To: general@incubator.apache.org, [EMAIL PROTECTED]
To: general@incuba
Thanks for bringing this up. I did a classlib update this morning, and
saw these files change, and I was confused.
Why do we have the files here anyway? I thought we were going to keep
in /standard and use links?
geir
Tim Ellison wrote:
Mark,
I suggest that this is rolled back since it is
That's because you tried to use property expansion
notation--"${hy.required.metainf-files}"--for a
reference. Try
;)
-Matt
--- Tim Ellison <[EMAIL PROTECTED]> wrote:
> Matt Benson wrote:
> > Tim: This should not be the case. What version of
> Ant
> > is this?
>
> I'm using Ant 1.6.5
>
> W
Rana,
of course, you are right and the patches must/will be verified
against x86-32 and x86-64.
Best regards,
Igor.
2006/10/20, Rana Dasgupta <[EMAIL PROTECTED]>:
Sure, I have no problem, just the question :-) But without clear IPF commit
criteria, there is a reasonable limit. On the other IPF
On 20 October 2006 at 12:52, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
>
> Mark Hindess wrote:
> > On 20 October 2006 at 10:11, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
> >>
> >> Mark Hindess wrote:
> >>> On 20 October 2006 at 9:31, Tim Ellison <[EMAIL PROTECTED]> wrote:
> FWIW:
Alex,
we still have a problem with your solution :(
System.loadLibrary does not accept full paths, but -Dvm.em_dll could be a
full path to a library. IMO the workaround with parsing the path and
adjusting "java.library.path" before loading a library is bad solution.
Any thoughts?
All,
Are there
On 20 October 2006 at 17:21, Tim Ellison <[EMAIL PROTECTED]> wrote:
>
> Mark,
>
> I suggest that this is rolled back since it is modifying the
> concurrency code in our 'standard' SVN area that we aim to keep in
> close sync with Doug's repository.
Agreed. I thought about this after doing it th
Excellent! That should deal with those odd compile errors that people
were seeing that went away if they did a rebuild.
-Mark.
On 20 October 2006 at 16:53, [EMAIL PROTECTED] wrote:
> Author: tellison
> Date: Fri Oct 20 09:53:49 2006
> New Revision: 466199
>
> URL: http://svn.apache.org/viewvc
>A *real* unix hacker
Two years of release engineering is more than enough:
find . -name .svn -exec grep -H name {}/entries \; | sed -e
's/\.svn\/entries: name="//; s/"$//' | egrep -i
'\.(gif|jar|png|dat|class|tif|jpg|jpeg|ico|dll|so|exe|doc|wav|pdf|zip)$'
:-)
With best regards,
Alexei Fedot
Matt Benson wrote:
> Tim: This should not be the case. What version of Ant
> is this?
I'm using Ant 1.6.5
When I try that style I get:
BUILD FAILED
C:\Harmony\modules\logging\build.xml:76: Reference
${hy.required.metainf-files} not found.
Regards,
Tim
> --- Tim Ellison <[EMAIL PROTECTED]> wr
In the last day or so it seems we have had to do a 'clean' to get a
successful build. Looking into it I see that we were picking up the
build.output dir in our 'global' build javac (see below), which likely
means that the new source files are compiled against the old .class
files in some order.
I
Mark Hindess wrote:
On 20 October 2006 at 10:11, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
Mark Hindess wrote:
On 20 October 2006 at 9:31, Tim Ellison <[EMAIL PROTECTED]> wrote:
FWIW: Below are the results of running RAT on a windows snapshot.
For some reason it complained about lack
Volynets, Vera wrote:
Hi,
svn has two commands where you can get svn revision.
It's nice bug the problem is that results are different.
example:
1) svn log --limit 1
r466095 | smishura | 2006-10-20 16:47:14 +0400 (Fri, 20 Oc
Tim: This should not be the case. What version of Ant
is this?
-Matt
--- Tim Ellison <[EMAIL PROTECTED]> wrote:
> So I'd like to avoid each module having to
> explicitly list the files
> required to go into the meta-inf directory of their
> JAR, like this
> example taken from LOGGING:
>
>
>
So I'd like to avoid each module having to explicitly list the files
required to go into the meta-inf directory of their JAR, like this
example taken from LOGGING:
and would prefer to set up a fileset in properties.xml that can be
referenced by all modul
Mark,
I suggest that this is rolled back since it is modifying the concurrency
code in our 'standard' SVN area that we aim to keep in close sync with
Doug's repository.
Perhaps we can offer the patch to that community, and/or set up local
compiler options to hide the warnings in this module.
Reg
Denis Kishenko wrote:
I have researched issue H-1664 and found one more difference with RI.
I run simple test on Windows Server 2003 SP1
=== Test =
import java.net.InetAddress;
import java.net.UnknownHostException;
public class Test {
public static void main(Strin
Hi Weldon,
I am sorry to to see that you may be still having problems with the
VS.Net debugger. I use it all the time, and everything( BP's, watch, memory
and thread windows ) works as expected. If you haven't done so alread, could
you please give this a shot?
devenv /debugexe whatever-comman
On 10/20/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 10/20/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
>
> This sounds very much like what I experienced before I did the
> below. When
> the above dialog box opens, are you running from msvc debugger or from a
> msdos console window? It
On 10/20/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
This sounds very much like what I experienced before I did the
below. When
the above dialog box opens, are you running from msvc debugger or from a
msdos console window? It seems msvc 2003/2005 can't find the debug
symbols
if drlvm is run
On 10/20/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
The way you debugging should work.
I use MSVC + Visual Assist as code browser + I do not use __asm(int
3)-like
breakpoints, therefore working with complete projects is more convenient
for
me.
Actually all that is required is a single int
Nathan Beyer wrote:
I added a compiler arg to the main 'build-java.xml' compile to disable
all of the warnings.
Thanks a lot, Nathan, but how about also add that arg to build-test.xml?
I think the ECJ probably feels more unhappy with the test cases:).
This should take care of the warnings.
-N
Vera,
I think that the second revison (Revision: 466101) is the revison of the
last update.
On 10/20/06, Volynets, Vera <[EMAIL PROTECTED]> wrote:
Hi,
svn has two commands where you can get svn revision.
It's nice bug the problem is that results are different.
example:
1) svn log --limit 1
Hi,
svn has two commands where you can get svn revision.
It's nice bug the problem is that results are different.
example:
1) svn log --limit 1
r466095 | smishura | 2006-10-20 16:47:14 +0400 (Fri, 20 Oct 2006) | 1 line
Apply
On 20 October 2006 at 10:11, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
>
>
> Mark Hindess wrote:
> > On 20 October 2006 at 9:31, Tim Ellison <[EMAIL PROTECTED]> wrote:
> >> FWIW: Below are the results of running RAT on a windows snapshot.
> >> For some reason it complained about lack of A
Sure, I have no problem, just the question :-) But without clear IPF commit
criteria, there is a reasonable limit. On the other IPF proposal thread,
we decided to just commit IPF patches by verifying that things don't break
on x86-32 and x86-64 for now.
Rana
On 10/20/06, Mikhail Fursov <[EMAI
Why not to do in parallel? No doubt, interpreter will run "Hello World"
first :)
On 10/20/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
I thought that we are doing IPF first with the interpreter?
Rana
--
Mikhail Fursov
I thought that we are doing IPF first with the interpreter?
Rana
On 20 Oct 2006 19:15:46 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote:
>To sum up my thoughts:
>* debugging_VM_and_JIT
>+ is outdated
>+ covers both linux and windows debugging tips intermixed
>+ has instructions for JET tracing (quite valid)
>* Let's make make it 2 separate docs: "Linux debugg
Morozova, Nadezhda wrote:
Egor,
You're a treasure keeper, so many useful tips :)
As you mentioned yourself, this info should be on the website, and I
side with you on this.
We actually have some debugging tips already:
http://incubator.apache.org/harmony/subcomponents/drlvm/debugging_VM_and
_
Egor Pasko wrote:
On the 0x208 day of Apache Harmony Tonny Lau wrote:
Hi,
I checked out the latest drlvm, and failed to set breakpoint when I used
gdb. It seems the
"harmony/enhanced/drlvm/trunk/build/lnx_ia32_gcc_debug/deploy/jre/bin/java"
is copied from "harmony/enhanced/classlib/trunk/depl
Egor Pasko wrote:
On the 0x208 day of Apache Harmony Tim Ellison wrote:
FWIW: Below are the results of running RAT on a windows snapshot. For
some reason it complained about lack of ASF block comments in DLLs, and
proceeded to dump them to the console, so I chopped them out of the
report. L
Mikhail Loenko wrote:
2006/10/20, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
For those that haven't been following along
Graduating from the Incubator is a "dynamic" process, as there's no
really hard and fast rules to satisfy. On one hand, this is a good
thing, because determining the heal
Mark Hindess wrote:
On 20 October 2006 at 9:31, Tim Ellison <[EMAIL PROTECTED]> wrote:
FWIW: Below are the results of running RAT on a windows snapshot.
For some reason it complained about lack of ASF block comments in
DLLs, and proceeded to dump them to the console, so I chopped them out
of
"Mikhail Fursov" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 10/20/06, Slava Shakin <[EMAIL PROTECTED]> wrote:
>>
>> I think a generic encoding interface exposed by a component could return
>> for
>> a given helper a mask of affected registers, description of input and
>> ret
Alex Blewitt wrote:
However, if not, and some IPMC memebers still really want to see a
demonstration of a release process, we can certainly do that. I've
thought about what we might release. One thing that came to mind is a
Pack200 jar :)
:-) So, you're saying I've got less than a month to
Hi Mikhail,
I don't see any problems with the RI behavior here. The spec says
about the ObjectInputStream#resolveClass() method:
"This method will be invoked only once for each unique class in the stream."
So your TestObjectInputStream#resolveClass() will be called only once.
And all serialized
Artem, I was wrong. No need to answer the question about
hythread_get_tls_suspend_request_offset.
The 'suspend_request' is TM term. So your proposal to call TM from JIT was
right.
On 10/20/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
Just a small update.
On 10/20/06, Mikhail Fursov <[EMAIL PRO
I just removed a bit of javadoc from lang-kernel's java.lang.System
class for clearProperty().
It was identical to that of the Java SE 5 spec. Now, I know it makes
perfect sense to to do this, but please remember that we aren't allowed
to do this.
Please provide original javadoc, and if you
On 10/20/06, Slava Shakin <[EMAIL PROTECTED]> wrote:
I think a generic encoding interface exposed by a component could return
for
a given helper a mask of affected registers, description of input and
return
parameters, and should not produce any other side effects including VM
calls
or exception
The way you debugging should work.
I use MSVC + Visual Assist as code browser + I do not use __asm(int 3)-like
breakpoints, therefore working with complete projects is more convenient for
me.
BTW I noticed that when VM is crashed the "Debug" button in the dialog opens
VS debugger with all stack
I like the proposal about delegation of encoding to another responsible
component (TM in this case). Or shall we call it binary inlining of VM
helpers?
It seems to fix the remaining minor modularity issues we failed to solve
with magics.
We could introduce something like TLSLoadMacroInst in CG
[test] please ignore
--
Best regards,
Igor.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 10/20/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
Weldon,
I use MSVC 2003 for debugging every day and everything works fine.
Did you try drlvm/trunk/buld/msvc_2003 build? It's not complete (no
vmcore,
no gc), but it runs debug session OK to me.
Actually, I am in the process of moving to
On 10/20/06, Morozova, Nadezhda <[EMAIL PROTECTED]> wrote:
Yeo-hoo! Great news, Mikhail.
Do you think you can also take a look at our Debugging guide on the
website? I think it also gives some debugging tips on MSVS. Are any of
them still valid? :)
Part of the info about MSVC2003 debugging is
Weldon,
I use MSVC 2003 for debugging every day and everything works fine.
Did you try drlvm/trunk/buld/msvc_2003 build? It's not complete (no vmcore,
no gc), but it runs debug session OK to me.
On 10/20/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
Suddenly I am unable to debug msvc 2003. I
Folks,
I seem to be done with the merging procedure and fixing the duplication
issue. Patches are in HARMONY-1730
[http://issues.apache.org/jira/browse/HARMONY-1881].
I've done the following:
1) I've remove [1], because it's out-of-date and have migrated unique
bits (not repeated elsewhere) to [2]
Suddenly I am unable to debug msvc 2003. It won't load the debug symbols I
tried installing msvc 2005 but it still won't load the debug symbols.
The following seems to work. Does anyone else see this? Is there an easier
way to do this?
1)
Create a new and empty project
2)
On the Project pul
Prerequisite: each component carries its own helpers (which means no
"allocation helper" in VM Core, for example).
Yes, simple JIT will call helper as regular JNI method.
I missed several issues in my original message.
First: "how to get address of helper?"
Answer:
Two choices:
1) each componen
On 10/20/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
Evgueni,
Please also test on Linux. This looks like a reasonable patch to me.
Unfortunately, I don't have access to Linux today (work from home).
Regarding the 16-bit CAS. A long time ago, there was a 16-bit, byte-aligned
field for thre
Yeo-hoo! Great news, Mikhail.
Do you think you can also take a look at our Debugging guide on the
website? I think it also gives some debugging tips on MSVS. Are any of
them still valid? :)
Thank you,
Nadya Morozova
-Original Message-
From: Mikhail Fursov [mailto:[EMAIL PROTECTED]
Sen
Added patch for SUID wanings to the same issue.H-1926
2006/10/20, Tim Ellison <[EMAIL PROTECTED]>:
Denis Kishenko wrote:
> Almost all unused variables are local. Only two of them are class
> fields and they are not using in native code. Build and all tests are
> successful.
Thanks Denis!
Regar
Hi Dmitry,
Could I ask you what is the "table_number" in your interface?
On 10/20/06, Dmitry Yershov <[EMAIL PROTECTED]> wrote:
Hi All,
I finished implementation of new properties module for DRL VM.
Also, HARMONY-1925 was created to track the progress. You can
find some details and patch
Hi All,
I finished implementation of new properties module for DRL VM.
Also, HARMONY-1925 was created to track the progress. You can
find some details and patch file here. Any comments are welcome
Thanks
Dmitry
-
Terms of us
On 10/20/06, Morozova, Nadezhda <[EMAIL PROTECTED]> wrote:
Summing up: the decision for now = Add new pages for Wiki =
- Debugging on Linux - Egor has volunteered; anybody else?
- Debugging on Windows - Mikhail has been recommended; how's that?
Nadya,
yes I have a text that describes how to l
Egor,
Thanks for a detailed an proactive response.
Surely, I think we can start accumulating new content on Wiki - this is
more visible and editable than patches to website. When we're done with
the bulk of content, I'll migrate the stable stuff to the site.
> * Thaking the one above into account
On the 0x208 day of Apache Harmony Igor Chebykin wrote:
> Hello all,
>
> I suggest a short series of patches for drlvm ipf code generator.
> We have some improvements for jitrino/ipf
> and would like to commit its to harmony.
>
> All patches will change only vm/jitrino/src/codegenerator/ipf/* file
Hi all,
That's just to let you know that there is a new page on wiki:
http://wiki.apache.org/harmony/Eclipse_Unit_Tests_Pass_on_DRLVM
You can find Eclipse Unit Tests runs results there.
A link from the FrontPage is also added.
Thanks,
Nina Rinskaya
--
Hi Igor,
Good start!
what IPF commit criteria looks reasonable for you? Is "IPF build is
compilable" criteria enough?
On 10/20/06, Igor Chebykin <[EMAIL PROTECTED]> wrote:
Hello all,
I suggest a short series of patches for drlvm ipf code generator.
We have some improvements for jitrino/ipf
and
Folks,
Thanks again for your feedback and appreciating the doc.
I've updated the patch correcting minor issues
[http://issues.apache.org/jira/browse/HARMONY-1881].
IMHO the patch is ready for the commitment. What do you think?
Would be great if someone can decide its fate. :)
Thanks in advance!
Evgueni,
Please also test on Linux. This looks like a reasonable patch to me.
Regarding the 16-bit CAS. A long time ago, there was a 16-bit, byte-aligned
field for thread ID. monenter() would do a 16-bit CAS. Maybe this is left
over from old monenter()??
On 10/19/06, Artem Aliev <[EMAIL PROT
1 - 100 of 167 matches
Mail list logo
