date:20060406


Hi

As far as I can say, the main problem of porting a JVM, designed for 
UNIX, to the Windows environment are the ANSI signals:
Windows, in fact, doesn't honor not even a fourth of all ANSI signals, 
therefore, the JVM signals handler WILL NOT be called by Windows.


   


I am not an MSVS expert, but my previous MS C/C++ work has had
no problem using the signal library, which was in any case borrowed
from Unix, so I don't think this will be a problem.  The only signal I
really need is SIGALRM for the time slicer.

 

If nothing changed since MSVC 6.0 (1999), the signals available in 
Windows are:


SIGABRT,SIGFPE,SIGILL,SIGINT,SIGSEGV,SIGTERM

Yet:

"The SIGILL, SIGSEGV, and SIGTERM signals are not generated under 
Windows NT. They are included for ANSI compatibility"



I don't know yet if and how Cygwin deals with this kind of problem...
  
   


Those who have compiled it had misc. header files to adjust, but
nobody has so far complained about signals.

Thanks,

Dan Lydick

 snip ...


 


Enrico

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Starting my next round on BootJVM

2006-04-06 Thread bootjvm




> [Original Message]
> From: Enrico Migliore <[EMAIL PROTECTED]>
> To: 
> Cc: bootjvm <[EMAIL PROTECTED]>
> Date: 4/5/06 7:58:57 AM
> Subject: Re: Starting my next round on BootJVM
>
...snip...
> >
> As far as I can say, the main problem of porting a JVM, designed for 
> UNIX, to the Windows environment are the ANSI signals:
> Windows, in fact, doesn't honor not even a fourth of all ANSI signals, 
> therefore, the JVM signals handler WILL NOT be called by Windows.
>
I am not an MSVS expert, but my previous MS C/C++ work has had
no problem using the signal library, which was in any case borrowed
from Unix, so I don't think this will be a problem.  The only signal I
really need is SIGALRM for the time slicer.

> I don't know yet if and how Cygwin deals with this kind of problem...
>
Those who have compiled it had misc. header files to adjust, but
nobody has so far complained about signals.

Thanks,

Dan Lydick

 snip ...




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New Harmony Launcher Plug-in Available For Eclipse

2006-04-06 Thread LvJimmy，Jing

Hi George:

Thanks very much for your work, I've struggled for eclipse
Harmony-JRE-configuration for hours this morning until find a solution from
your mail :)
For alternative, a direct copy of this file  "
org.apache.harmony.eclipse.jdt.launching_1.0.1.jar" to eclipse plug-in
directory works properly as well :)

Best regards,
Jimmy,Jing lv

2006/4/7, George Harley <[EMAIL PROTECTED]>:
>
> [EMAIL PROTECTED] wrote:
> >> Hi Etienne,
> >>
> >> That is as expected, I think, as the URL is intended for the Eclipse
> >> update manager not web browsers.
> >>
> >
> > So, I do not need it if I do not work with Eclipse, do I ?
> >
>
> Hi Hadrien,
>
> That's right ; the plug-in is an extension to Eclipse that enables
> developers to conveniently define a Harmony JRE to the IDE and run
> applications on it from within their IDE workspace.
>
> Best regards,
> George
>
>
> >
> >> Best regards,
> >> George
> >>
> >>
> >> Etienne Gagnon wrote:
> >>
> >>> The link gives me:
> >>>
> >>> An Exception Has Occurred
> >>> Python Traceback
> >>>
> >>> Traceback (most recent call last):
> >>>   File "/usr/local/viewcvs-1.0-dev/lib/viewcvs.py", line 3351, in main
> >>> request.run_viewcvs()
> >>> ...
> >>>
> >>> George Harley wrote:
> >>>
> >>>
>  split. Please point your Eclipse update manager at the following site
>  and install version 1.0.1 ...
> 
> 
> http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/tools/trunk/eclipse/org.apache.harmony.eclipse.site
> 
> 
> >>>
> >>>
> >> -
> >> 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]
> >
> >
> >
>
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: [classlib] Switching to a 5.0 compiler

2006-04-06 Thread bootjvm


+1 from me, especially with the 1.4 target as an intermediate
provision.  This should facilitate work while contributions
dependent on version 5 begin to happen.  At some point,
there will be enough version 5 tools around to move away
from 1.4 provisions.  We will just have to bide our time
and it will happen pretty much of its own accord.

Dan Lydick

> [Original Message]
> From: George Harley <[EMAIL PROTECTED]>
> To: 
> Date: 4/5/06 7:29:11 AM
> Subject: Re: [classlib] Switching to a 5.0 compiler
>
> Hi,
>
> Using the Sun 5.0 javac with the "jsr14" target it is possible to do a 
> complete compile of the Harmony Java source and successfully run the 
> tests on the existing VME. That means we could add in more contributions 
> that depended on 5.0 language features being understood instead of 
> letting them queue up.
>
> So +1 from me for using the straightforward but undocumented "jsr14" 
> target as a purely temporary measure to keep things moving onwards.
>
> Best regards,
> George




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib] update on running Harmony Classlib on GNU Classpath VMs

2006-04-06 Thread Weldon Washburn

Hi Tim,

On 4/6/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
> Weldon Washburn wrote:
> > I was able to eliminate almost all mods necessary to run Harmony
> > Classlib on a GNU Classpath VM.  The VM used is still JCHEVM.
>
> Cool -- I'd be very interested to hear about what you are doing.

I tried to give a complete explaination in the readme in JIRA
Harmony-318.  It would be great if you could tell me what this
document is missing or where it is unclear.

>
> > The VM
> > expects a specific hardcoded java lib directory structure.  Therefore,
> > directories such as kernel/src/main/java/gnu/classpath have been added
> > to Harmony Classlib.
>
> Do you mean directory paths to the class library JARs or specific class
> package names?

Actually I could not get JCHEVM/cygwin to read the JAR files.  I
simply use unzipped Harmony class files.  The directory paths in
question were added because generic GNU Classpath VMs are hardcoded to
expect to find specific class files in specific packages.  Which, in
turn, means creating the corresponding *.java files in new
directories.  The alternative would be to get GNU Classpath to modify
their directory structure plus get all the JVMs using GNU Classpath to
change their hardcoding.
>
> > The one remaining mod to JCHEVM is because dlopen() fails to load
> > hynio.dll.
>
> That DLL shouldn't be loaded?  We moved the natives out into hyluni.dll
> and (I just checked) there are no references to it from the Java code.

I am working with a 2 month old copy of Harmony Classlib.  I would
like to hold off the move to current Harmony Classlib until after I
get the cygwin dlopen() problems solved.

> Who is trying to load it?

I modified System.java to do a "VMRuntime.nativeLoad("hynio.dll");" 
This is a call into GNU Classpath JVM that will cause a DLL to be
loaded.

>
> The hynio.dll is scheduled for deletion once we figure out there is no
> longer a need for it (based on Paulex's ongoing work on IO refactoring).

Its good to see progress on IO refactoring!

>
> Regards,
> Tim
>
>
> --
>
> Tim Ellison ([EMAIL PROTECTED])
> IBM Java technology centre, UK.
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Weldon Washburn
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ITC: Contribution of java.math and javax.crypto

2006-04-06 Thread Miguel Montes

Thanks for the tip, Tim. I think the set of access rules for 1.5 should be
pretty much the same

Miguel

On 4/6/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>
> Miguel,
>
> You can set up Eclipse to avoid this problem by defining access rules
> that ensure you can only 'see' API packages.
>
> Take a look at:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=116656
> (contains an example for JDK 1.4.2 rules)
>
> Regards,
> Tim
>
>
> Miguel Montes wrote:
> > Hi Mikhail:
> > I'm glad that you are looking at our code.
> >
> > I'm afraid that the problem was caused by Eclipse's black magic.
> Searching
> > for a Base 64 decoder, the developer typed B ctrl+space, and the first
> > option was BASE64Decoder. We have even src.zip removed from the
> > workstations, so the absence of doc comments  was not a hint.
> > It was clearly a mistake, and we are working on fixing it. Thanks for
> > pointing at it.
> >
> > Miguel
> >
> >
> > On 4/6/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
> >> Hello Miguel
> >>
> >> Thank you for your recent contribution to Harmony project!
> >>
> >> I've noticed that class javax.crypto.Util invokes a method
> >> from undocumented package sun.misc.*
> >>
> >> I assume that you did not have access to Sun sources, so it probably
> >> would be good if you provide a link to how did you learn about that
> Sun's
> >> internal functionality and its usage.
> >>
> >> Thanks,
> >> Mikhail
> >>
> >> 2006/3/14, Tim Ellison <[EMAIL PROTECTED]>:
> >>> Excellent!  -- thanks Miguel and team.
> >>>
> >>> Regards,
> >>> Tim
> >>>
> >>> Miguel Montes wrote:
>   As it was announced by Iris Gastañaga we are contributing the
> >> packages
>  javax.crypto and java.math on behalf of ITC (Córdoba Technolgy
> >> Institute).
>  We have been developing this code for several months and we believe
> it
> >> is a
>  valid contribution. Our code not only implements the full 5.0 API but
> >> also
>  uses 5.0 features and syntax.  As 5.0 is a stated goal of Harmony we
> >> hope
>  that a 5.0 VM will be available soon.
>  We are also contributing a set of test cases for both packages.
> 
>  Below there is a short description of the contribution.  We will soon
>  contribute also  an implementation of java.rmi.
> 
> 
> 
>   *Package name*
>  **javax.crypto
>  *
>  Package Description*
>  This is a clean room implementation of the package javax.crypto as
> >> specified
>  in the JDK 5.0. It requires the existence of other java packages, in
>  particular java.security and java.util. It can be used to replace
> >> jce.jar in
>  the jdk.
> 
>  *Current Status*
>  The package is almost fully implemented. It does not implement the
>  ExemptionMechanism logic.
> 
>  *Testing
>  * Unit and integration tests (and their documentation) are provided
> >> with the
>  code.*
>  *
> 
>  *Implementation Notes
>  The code uses heavily J2SE 5.0 features, such as generics, so it
> >> requires
>  5.0 VM and libraries (for instance java.security).
>  It has been tested against Sun SDK, removing the original jce.jar and
>  replacing it by ours.
> 
>  *
> 
> 
> 
> 
>   *Package name*
>  **java.math
> 
>   *Package Description*
>  This is a clean room implementation of the package java.math as
> >> specified in
>  JDK 5.0.
> 
>  *Current Status*
>  The package is fully implemented.  Some methods are fairly optimized
> >> (for
>  example multiplication combines paper-and-pencil and Karatsuba
> >> algorithms).
>  *Testing
>  * Unit and integration tests (and their documentation) are provided
> >> with the
>  code.*
>  *
> 
>  *Implementation Notes
>  The internal representation for BigInteger is two-complement (this is
>  different from the sign-magnitude implementation already donated to
>  Harmony). BigDecimal uses only BigInteger's public interface and
> >> implements
>  the full 5.0 specification (which has about twice as many methods as
> >> in 1.4).
>  The code uses J2SE 5.0 features, so it requires 5.0 VM. It has been
> >> tested
>  against Sun SDK.
> 
>  *
>  **
> 
> 
> 
> 
>  --
>  Miguel Montes
> 
> >>> --
> >>>
> >>> Tim Ellison ([EMAIL PROTECTED])
> >>> IBM Java technology centre, UK.
> >>>
> >> -
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >
> > --
> > Miguel Montes
> >
>
> --
>
> Tim Ellison ([EMAIL PROTECTED])
> IBM Java technology centre, UK.
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
>

Re: [classlib] update on running Harmony Classlib on GNU Classpath VMs

Weldon Washburn wrote:
> I was able to eliminate almost all mods necessary to run Harmony
> Classlib on a GNU Classpath VM.  The VM used is still JCHEVM.

Cool -- I'd be very interested to hear about what you are doing.

> The VM
> expects a specific hardcoded java lib directory structure.  Therefore,
> directories such as kernel/src/main/java/gnu/classpath have been added
> to Harmony Classlib.

Do you mean directory paths to the class library JARs or specific class
package names?

> The one remaining mod to JCHEVM is because dlopen() fails to load
> hynio.dll.

That DLL shouldn't be loaded?  We moved the natives out into hyluni.dll
and (I just checked) there are no references to it from the Java code.
Who is trying to load it?

The hynio.dll is scheduled for deletion once we figure out there is no
longer a need for it (based on Paulex's ongoing work on IO refactoring).

Regards,
Tim

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ITC: Contribution of java.math and javax.crypto

You can run the Eclipse IDE on Classpath or Harmony(*) class libraries,
both are sufficiently well advanced to run it.

(*) you need to use the regex code from regex-beans-math which hasn't
been merged into the build process yet

Regards,
Tim

Chris Gray wrote:
> On Thursday 06 April 2006 23:02, Miguel Montes wrote:
>> Hi Mikhail:
>> I'm glad that you are looking at our code.
>>
>> I'm afraid that the problem was caused by Eclipse's black magic. Searching
>> for a Base 64 decoder, the developer typed B ctrl+space, and the first
>> option was BASE64Decoder. We have even src.zip removed from the
>> workstations, so the absence of doc comments  was not a hint.
>> It was clearly a mistake, and we are working on fixing it. Thanks for
>> pointing at it.
>>
>> Miguel
> 
> Guess this is a good illustration of why being able to run eclipse on 
> Classpath or Harmony, and not install even a jre from Sun on the dev machine, 
> is / will be a Good Thing ...
> 
> Chris
> 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ITC: Contribution of java.math and javax.crypto

Miguel,

You can set up Eclipse to avoid this problem by defining access rules
that ensure you can only 'see' API packages.

Take a look at:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=116656
(contains an example for JDK 1.4.2 rules)

Regards,
Tim


Miguel Montes wrote:
> Hi Mikhail:
> I'm glad that you are looking at our code.
> 
> I'm afraid that the problem was caused by Eclipse's black magic. Searching
> for a Base 64 decoder, the developer typed B ctrl+space, and the first
> option was BASE64Decoder. We have even src.zip removed from the
> workstations, so the absence of doc comments  was not a hint.
> It was clearly a mistake, and we are working on fixing it. Thanks for
> pointing at it.
> 
> Miguel
> 
> 
> On 4/6/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
>> Hello Miguel
>>
>> Thank you for your recent contribution to Harmony project!
>>
>> I've noticed that class javax.crypto.Util invokes a method
>> from undocumented package sun.misc.*
>>
>> I assume that you did not have access to Sun sources, so it probably
>> would be good if you provide a link to how did you learn about that Sun's
>> internal functionality and its usage.
>>
>> Thanks,
>> Mikhail
>>
>> 2006/3/14, Tim Ellison <[EMAIL PROTECTED]>:
>>> Excellent!  -- thanks Miguel and team.
>>>
>>> Regards,
>>> Tim
>>>
>>> Miguel Montes wrote:
  As it was announced by Iris Gastañaga we are contributing the
>> packages
 javax.crypto and java.math on behalf of ITC (Córdoba Technolgy
>> Institute).
 We have been developing this code for several months and we believe it
>> is a
 valid contribution. Our code not only implements the full 5.0 API but
>> also
 uses 5.0 features and syntax.  As 5.0 is a stated goal of Harmony we
>> hope
 that a 5.0 VM will be available soon.
 We are also contributing a set of test cases for both packages.

 Below there is a short description of the contribution.  We will soon
 contribute also  an implementation of java.rmi.



  *Package name*
 **javax.crypto
 *
 Package Description*
 This is a clean room implementation of the package javax.crypto as
>> specified
 in the JDK 5.0. It requires the existence of other java packages, in
 particular java.security and java.util. It can be used to replace
>> jce.jar in
 the jdk.

 *Current Status*
 The package is almost fully implemented. It does not implement the
 ExemptionMechanism logic.

 *Testing
 * Unit and integration tests (and their documentation) are provided
>> with the
 code.*
 *

 *Implementation Notes
 The code uses heavily J2SE 5.0 features, such as generics, so it
>> requires
 5.0 VM and libraries (for instance java.security).
 It has been tested against Sun SDK, removing the original jce.jar and
 replacing it by ours.

 *




  *Package name*
 **java.math

  *Package Description*
 This is a clean room implementation of the package java.math as
>> specified in
 JDK 5.0.

 *Current Status*
 The package is fully implemented.  Some methods are fairly optimized
>> (for
 example multiplication combines paper-and-pencil and Karatsuba
>> algorithms).
 *Testing
 * Unit and integration tests (and their documentation) are provided
>> with the
 code.*
 *

 *Implementation Notes
 The internal representation for BigInteger is two-complement (this is
 different from the sign-magnitude implementation already donated to
 Harmony). BigDecimal uses only BigInteger's public interface and
>> implements
 the full 5.0 specification (which has about twice as many methods as
>> in 1.4).
 The code uses J2SE 5.0 features, so it requires 5.0 VM. It has been
>> tested
 against Sun SDK.

 *
 **




 --
 Miguel Montes

>>> --
>>>
>>> Tim Ellison ([EMAIL PROTECTED])
>>> IBM Java technology centre, UK.
>>>
>> -
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> 
> --
> Miguel Montes
> 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ITC: Contribution of java.math and javax.crypto

2006-04-06 Thread Chris Gray

On Thursday 06 April 2006 23:02, Miguel Montes wrote:
> Hi Mikhail:
> I'm glad that you are looking at our code.
>
> I'm afraid that the problem was caused by Eclipse's black magic. Searching
> for a Base 64 decoder, the developer typed B ctrl+space, and the first
> option was BASE64Decoder. We have even src.zip removed from the
> workstations, so the absence of doc comments  was not a hint.
> It was clearly a mistake, and we are working on fixing it. Thanks for
> pointing at it.
>
> Miguel

Guess this is a good illustration of why being able to run eclipse on 
Classpath or Harmony, and not install even a jre from Sun on the dev machine, 
is / will be a Good Thing ...

Chris

-- 
Chris Gray/k/ Embedded Java Solutions  BE0503765045
Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/
[EMAIL PROTECTED] +32 3 216 0369


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ITC: Contribution of java.math and javax.crypto

2006-04-06 Thread Miguel Montes

Hi Mikhail:
I'm glad that you are looking at our code.

I'm afraid that the problem was caused by Eclipse's black magic. Searching
for a Base 64 decoder, the developer typed B ctrl+space, and the first
option was BASE64Decoder. We have even src.zip removed from the
workstations, so the absence of doc comments  was not a hint.
It was clearly a mistake, and we are working on fixing it. Thanks for
pointing at it.

Miguel


On 4/6/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
>
> Hello Miguel
>
> Thank you for your recent contribution to Harmony project!
>
> I've noticed that class javax.crypto.Util invokes a method
> from undocumented package sun.misc.*
>
> I assume that you did not have access to Sun sources, so it probably
> would be good if you provide a link to how did you learn about that Sun's
> internal functionality and its usage.
>
> Thanks,
> Mikhail
>
> 2006/3/14, Tim Ellison <[EMAIL PROTECTED]>:
> > Excellent!  -- thanks Miguel and team.
> >
> > Regards,
> > Tim
> >
> > Miguel Montes wrote:
> > >  As it was announced by Iris Gastañaga we are contributing the
> packages
> > > javax.crypto and java.math on behalf of ITC (Córdoba Technolgy
> Institute).
> > > We have been developing this code for several months and we believe it
> is a
> > > valid contribution. Our code not only implements the full 5.0 API but
> also
> > > uses 5.0 features and syntax.  As 5.0 is a stated goal of Harmony we
> hope
> > > that a 5.0 VM will be available soon.
> > > We are also contributing a set of test cases for both packages.
> > >
> > > Below there is a short description of the contribution.  We will soon
> > > contribute also  an implementation of java.rmi.
> > >
> > >
> > >
> > >  *Package name*
> > > **javax.crypto
> > > *
> > > Package Description*
> > > This is a clean room implementation of the package javax.crypto as
> specified
> > > in the JDK 5.0. It requires the existence of other java packages, in
> > > particular java.security and java.util. It can be used to replace
> jce.jar in
> > > the jdk.
> > >
> > > *Current Status*
> > > The package is almost fully implemented. It does not implement the
> > > ExemptionMechanism logic.
> > >
> > > *Testing
> > > * Unit and integration tests (and their documentation) are provided
> with the
> > > code.*
> > > *
> > >
> > > *Implementation Notes
> > > The code uses heavily J2SE 5.0 features, such as generics, so it
> requires
> > > 5.0 VM and libraries (for instance java.security).
> > > It has been tested against Sun SDK, removing the original jce.jar and
> > > replacing it by ours.
> > >
> > > *
> > >
> > >
> > >
> > >
> > >  *Package name*
> > > **java.math
> > >
> > >  *Package Description*
> > > This is a clean room implementation of the package java.math as
> specified in
> > > JDK 5.0.
> > >
> > > *Current Status*
> > > The package is fully implemented.  Some methods are fairly optimized
> (for
> > > example multiplication combines paper-and-pencil and Karatsuba
> algorithms).
> > >
> > > *Testing
> > > * Unit and integration tests (and their documentation) are provided
> with the
> > > code.*
> > > *
> > >
> > > *Implementation Notes
> > > The internal representation for BigInteger is two-complement (this is
> > > different from the sign-magnitude implementation already donated to
> > > Harmony). BigDecimal uses only BigInteger's public interface and
> implements
> > > the full 5.0 specification (which has about twice as many methods as
> in 1.4).
> > > The code uses J2SE 5.0 features, so it requires 5.0 VM. It has been
> tested
> > > against Sun SDK.
> > >
> > > *
> > > **
> > >
> > >
> > >
> > >
> > > --
> > > Miguel Montes
> > >
> >
> > --
> >
> > Tim Ellison ([EMAIL PROTECTED])
> > IBM Java technology centre, UK.
> >
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Miguel Montes

Re: [jira] Created: (HARMONY-318) mods to Harmony Classlib that eliminate most of the changes to JCHEVM

2006-04-06 Thread Archie Cobbs


Geir,

[resend]

Is it OK to commit this stuff to the repo??

Thanks,
-Archie

weldon washburn (JIRA) wrote:

mods to Harmony Classlib that eliminate most of the changes to JCHEVM
-

 Key: HARMONY-318
 URL: http://issues.apache.org/jira/browse/HARMONY-318
 Project: Harmony
Type: Bug

  Components: Classlib  
 Environment: cygwin

Reporter: weldon washburn


Most of the modifications to JCHEVM to support Harmony Classlib have been 
removed.  The one remaining mod is because JCHEVM uses cygwin dlopen() to load 
a DLL.  And dlopen(), for an unknown reason, refuses to load hynio.dll.



__
Archie Cobbs  *CTO, Awarix*  http://www.awarix.com

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[classlib] update on running Harmony Classlib on GNU Classpath VMs

2006-04-06 Thread Weldon Washburn

All,

I was able to eliminate almost all mods necessary to run Harmony
Classlib on a GNU Classpath VM.  The VM used is still JCHEVM.  The VM
expects a specific hardcoded java lib directory structure.  Therefore,
directories such as kernel/src/main/java/gnu/classpath have been added
to Harmony Classlib.

The one remaining mod to JCHEVM is because dlopen() fails to load
hynio.dll.  I will investigate the cause soon.  What is known at this
time is that dlopen() will successfully load a DLL that contains the
following sections:
.bss
.data
.edata
.idata
.rdata
.reloc
.text

On the other hand, hynio.dll has the following sections:
.data
.rdata
.reloc
.rsrc
.text

The problem might be caused because hynio.dll is not built with tools
that are compatible with cygwin's dlopen().  Does anyone have any
suggestions?

A zip file with all the mods to get Harmony Classlib to do "hello
world" on JCHEVM have been uploaded to JIRA Harmony-318.

--
Weldon Washburn
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Porting Harmony classlib to Sablevm

2006-04-06 Thread Mark Hindess

On 4/6/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Hi,

Hi Hadrien,

> in the Harmony Class Library Porting Documentation, it said that VM
> vendor must implement the kernel classes (like java.lang.Object).
>
> In the kernel classes harmony code, most classes are "skeletons"
> (for exemple Object.hashCode returns zero).

The versions you find in the classlib svn are just stubs for the
classlib to build.

> Does it mean IBM VM intercepts directly all calls to these
> "skeleton" methods to execute them in native code or load kernel
> classes from their own package (in a .zip or .jar) linked with VM
> via native declared methods ?

Yes. The VM vendor is expected to provide the implementations of these
classes.  As you suspected, the IBM VME contains it's implementations in:

  deploy/jre/bin/default/luni-kernel.jar and
  deploy/jre/bin/default/security-kernel.jar.

which are the "real" versions used at runtime.

Regards,
 Mark.

--
Mark Hindess <[EMAIL PROTECTED]>
IBM Java Technology Centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Porting Harmony classlib to Sablevm

2006-04-06 Thread hadrien

Hi,
in the Harmony Class Library Porting Documentation, it said that VM vendor must 
implement the kernel classes (like java.lang.Object).

In the kernel classes harmony code, most classes are "skeletons" (for exemple 
Object.hashCode returns zero).

Does it mean IBM VM intercepts directly all calls to these "skeleton" methods 
to execute them in native code or load kernel classes from their own package 
(in a .zip or .jar) linked with VM via native declared methods ? 

Regards,
Hadrien

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New Harmony Launcher Plug-in Available For Eclipse

2006-04-06 Thread George Harley


[EMAIL PROTECTED] wrote:

Hi Etienne,

That is as expected, I think, as the URL is intended for the Eclipse 
update manager not web browsers.



So, I do not need it if I do not work with Eclipse, do I ?
  


Hi Hadrien,

That's right ; the plug-in is an extension to Eclipse that enables 
developers to conveniently define a Harmony JRE to the IDE and run 
applications on it from within their IDE workspace.  


Best regards,
George


  

Best regards,
George


Etienne Gagnon wrote:


The link gives me:

An Exception Has Occurred
Python Traceback

Traceback (most recent call last):
  File "/usr/local/viewcvs-1.0-dev/lib/viewcvs.py", line 3351, in main
request.run_viewcvs()
...

George Harley wrote:
  
  

split. Please point your Eclipse update manager at the following site
and install version 1.0.1 ...

http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/tools/trunk/eclipse/org.apache.harmony.eclipse.site


  
  

-
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]


  



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New Harmony Launcher Plug-in Available For Eclipse

2006-04-06 Thread hadrien

> Hi Etienne,
> 
> That is as expected, I think, as the URL is intended for the Eclipse 
> update manager not web browsers.

So, I do not need it if I do not work with Eclipse, do I ?

> 
> Best regards,
> George
> 
> 
> Etienne Gagnon wrote:
> > The link gives me:
> >
> > An Exception Has Occurred
> > Python Traceback
> >
> > Traceback (most recent call last):
> >   File "/usr/local/viewcvs-1.0-dev/lib/viewcvs.py", line 3351, in main
> > request.run_viewcvs()
> > ...
> >
> > George Harley wrote:
> >   
> >> split. Please point your Eclipse update manager at the following site
> >> and install version 1.0.1 ...
> >>
> >> http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/tools/trunk/eclipse/org.apache.harmony.eclipse.site
> >> 
> >
> >   
> 
> 
> -
> 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]

Re: New Harmony Launcher Plug-in Available For Eclipse

2006-04-06 Thread George Harley


Hi Etienne,

That is as expected, I think, as the URL is intended for the Eclipse 
update manager not web browsers.


Best regards,
George


Etienne Gagnon wrote:

The link gives me:

An Exception Has Occurred
Python Traceback

Traceback (most recent call last):
  File "/usr/local/viewcvs-1.0-dev/lib/viewcvs.py", line 3351, in main
request.run_viewcvs()
...

George Harley wrote:
  

split. Please point your Eclipse update manager at the following site
and install version 1.0.1 ...

http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/tools/trunk/eclipse/org.apache.harmony.eclipse.site



  



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New Harmony Launcher Plug-in Available For Eclipse

2006-04-06 Thread Etienne Gagnon

The link gives me:

An Exception Has Occurred
Python Traceback

Traceback (most recent call last):
  File "/usr/local/viewcvs-1.0-dev/lib/viewcvs.py", line 3351, in main
request.run_viewcvs()
...

George Harley wrote:
> split. Please point your Eclipse update manager at the following site
> and install version 1.0.1 ...
> 
> http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/tools/trunk/eclipse/org.apache.harmony.eclipse.site

-- 
Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/
SableVM:   http://www.sablevm.org/
SableCC:   http://www.sablecc.org/


signature.asc
Description: OpenPGP digital signature

New Harmony Launcher Plug-in Available For Eclipse

2006-04-06 Thread George Harley


Hi,

The Apache Harmony launcher plug-in has been updated to work with the 
new IBM VME announced earlier today in which the kernel jars have been 
split. Please point your Eclipse update manager at the following site 
and install version 1.0.1 ...


http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/tools/trunk/eclipse/org.apache.harmony.eclipse.site


Best regards,
George



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Updated: (HARMONY-308) java.nio.charset.Charset.encode(CharBuffer) returns bytes in a different order in Harmony and RI for the UTF-16 charset

2006-04-06 Thread Dmitry M. Kononov

Hi Richard,

On 4/6/06, Richard Liang <[EMAIL PROTECTED]> wrote:

> Dmitry M. Kononov wrote:
> > As you exactly noticed the cause of this issue that Harmony uses the
> > little-endian byte order, if an encoded UTF-16 sequence has no
> byte-order
> > mark. However, the spec reads such a case explicitly as follows:
> >
> > "When decoding, the UTF-16 charset interprets a byte-order mark to
> indicate
> > the byte order of the stream but defaults to big-endian if there is no
> > byte-order mark; when encoding, it uses big-endian byte order and writes
> a
> > big-endian byte-order mark."
> >
> >
> Hello Dmitry,
>
> Yes, although Harmony and RI use different byte order, as both Harmony
> and RI use byte-order mark (U+FEFF), I think both Harmony and RI are
> compliant with the specification. So could we regard Harmony-308 as "not
> a bug"?

I think Harmony's behavior in this case is inconsistent with the java spec,
since the spec defines the expected behavior explicitly:
"when encoding, it uses big-endian byte order and writes a big-endian
byte-order mark." But Harmony's encode() returns bytes in the little-endian
order.

It seems I do not understand why do you think Harmony follows the spec
correctly in this case? :)
I am really sorry for my misunderstanding.

>From a test case attached to the HARMONY-308:

1) We have a char array that has no byte-order mark:
private static final char chars[] = {

0x041b,0x0435,0x0442,0x043e,0x0020,0x0432,0x0020,0x0420,0x043e,0x0441,
0x0441,0x0438,0x0438};

2) We have a byte array that encode() should return as we expect.
private static final byte bytes[] = {
(byte)254,(byte)255,(byte)  4,(byte) 27,(byte)  4,(byte) 53,(byte)
4,
(byte) 66,(byte)  4,(byte) 62,(byte)  0,(byte) 32,(byte)  4,(byte)
50,
(byte)  0,(byte) 32,(byte)  4,(byte) 32,(byte)  4,(byte) 62,(byte)
4,
(byte) 65,(byte)  4,(byte) 65,(byte)  4,(byte) 56,(byte)  4,(byte)
56};

Please note, according to the spec we expect bytes returned by encode() in
big-endian byte order. So, we expect the FEFF byte-order mark.
Do you agree this expectation is correct and consistent with the spec?

Thanks.
--
Dmitry M. Kononov
Intel Managed Runtime Division

Re: [sablevm] SIGSEGV signal received from Cygwin

2006-04-06 Thread Etienne Gagnon

Enrico Migliore wrote:
> I debugged the classical HelloWorld class with DDD and found the problem
> in the following function:
> 
> _svmf_init(void)
> {
> pthread_once(...);< SEGSEGV  signal

That's definitely a cygwin bug.  I see.

>>> problem 1:  POSIX dependancy
>>> -
>>>...
>> I think that moving to Harmony's port library should solve this.  I
>> agree that it shouldn't be hard to fix.
>>
> Are you referring to the work-in-progress that is adapting SableVM to
> the VMI?

Yep.

>>> problem 2:  GCC extensions
>>> -
>>...
>> this: use Hans Boehm's atomic_ops library to get this code out of
>> SableVM.  See:
>>
>> http://sablevm.org/bugs/179

Just FYI, fixing this is a short term objective.  (i.e. work in progress).

> In any case, before starting the port, I think that I and the people who
> would like to help, will have analyze the code file by file.

Actually, you should really start looking at:

 src/libsablevm/include/jni_system_specific.h
 src/libsablevm/system.c
 src/libsablevm/system.h

These are the files which contain system-specific code.  Outside of
these files, the only real dependencies are POSIX calls.  [I think
there's some exception in System.getCurrentMillis() implementation that
shouldn't even be in the VM to start with, as there's no VM-specific
functionality in it...  I had to live with Classpath's decisions on
their VM interface.]

If you really want to read every single source file (!), then you should
definitely:
0.1) [prerequisite] read the JVMS fully, a few times over
0.2) [prerequisite] read the JNI spec fully, a few times over
1) read my Ph.D. thesis
2) read the documents in doc/
3) ask questions on sablevm-devel@ for clarifications

Going that deep shouldn't be necessary, though.  Identifying POSIX
dependencies and replacing them with VMI-port calls should be sufficient
to start with.

Etienne

-- 
Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/
SableVM:   http://www.sablevm.org/
SableCC:   http://www.sablecc.org/

signature.asc
Description: OpenPGP digital signature

Re: [sablevm] SIGSEGV signal received from Cygwin

Hi Etienne,

Enrico Migliore wrote:

I'm doing some testing on SableVM, and noticed that is receives the very
same segmentation fault signal that JCHEVM does, from
pthread_key_create() which is embedded in:

/usr/bin/cygwin1.dll

I read around that this problem could be fixed, but the error means that
the Cygwin platform can only be used for developing, studying and
testing and not for real world use.

Can you expand a little on this. I am not sure what you mean.

I debugged the classical HelloWorld class with DDD and found the problem
in the following function:

_svmf_init(void)
{
pthread_once(...);< SEGSEGV signal

}

problem 1: POSIX dependancy
-
The code contains a certain number of POSIX calls (dependancies). Much
of them can be easily replaced, but some might be hard to replace.

I think that moving to Harmony's port library should solve this. I
agree that it shouldn't be hard to fix.

Are you referring to the work-in-progress that is adapting SableVM to
the VMI?

problem 2: GCC extensions
-
The code contains some GCC extensions which are not ANSI.

When compiling a switch interpreter (--with-treading=switch), there
shouldn't be GCC extensions. The only exception is atomic operations
which cannot be expressed in C. Yet, I've found an elegant solution to
this: use Hans Boehm's atomic_ops library to get this code out of
SableVM. See:

http://sablevm.org/bugs/179

problem 3: Which compiler?
-
GCC seems to be the best candidate but MSVC is more popular.

Ideally, I'd like both to work. Getting the faster direct/inlined
interpreters to work with MSVC might be tricky (require inline assembly
or linking to an asm library), but the switch interpreter shouldn't be a
problem.

I see what you're saying

problem 4: Native code dependancies
---
The Harmony class library depends on the port layer:

http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/index.html

Yep, using this layer and atomic_ops should hopefully be sufficient to
remove all system-specific dependencies. If anything is missing, we
should probably abstract it into the port layer.

In any case, before starting the port, I think that I and the people who
would like to help, will have analyze the code file by file.

Now, the interesting thing would be for Harmony native code to compile
and work on something other than ia32. SableVM already works on pretty
much anything (using gcc, so far), as long as libffi and GNU classpath
compiles on the target. The only other limitation is 2 operations that
cannot be expressed in C: compare_and_swap and clear_cache.

Etienne

That's another reasonable goal :-)

Enrico

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Refactoring package names


Thanks Richard - this is fixed now

Richard Liang wrote:

Oliver Deakin wrote:
Tim and I have now completed the package renames at repository 
revision 391957. It is now safe to update and start building the 
Harmony classlib again.


If you use the IBM VME in combination with Harmony classlib, you will 
need to download the new version (v2) to continue working with 
classlib after revision 391957. They can be found at:

http://www-128.ibm.com/developerworks/java/jdk/harmony/index.html
and are called Harmony-vme-win.IA32-v2.zip for Windows and 
Harmony-vme-linux.IA32-v2.tar.gz for Linux.
The VME v1 is not compatible with Harmony classlib after revision 
391957.



Awesome! I'm downloading the new VME

BTW, there is only "IBM Development Package for Apache Harmony v1.0 
" 
link in the index page. But after you login (if you already have a IBM 
ID), following the link you will see the new VME v2.

Regards,
Oliver

Tim Ellison wrote:

Ok, the renames are done -- I'll leave this around for a few hours in
case somebody screams.  Otherwise it is a case of checking out the
earlier revision.

Regards,
Tim

Tim Ellison wrote:
 

FYI: Before we do the refactoring I'm making a copy of trunk onto the
branch directory ... I'll remove it once things are settled.

Regards,
Tim

Oliver Deakin wrote:
  

Hi all,

Tim and I plan to complete the refactoring of package names from 
com.ibm

to org.apache.harmony over the next few hours. We are going to make a
backup of the current classlib trunk in a branch before we make our
changes, so we can revert should anything unexpected occur.

Please be aware that while we are making these changes the build will
probably be broken, so it may be worth not updating until we 
complete.

Ill send a mail to confirm when we are finished.

Regards,
Oliver

  


  







--
Oliver Deakin
IBM United Kingdom Limited


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Refactoring package names

2006-04-06 Thread Richard Liang


Oliver Deakin wrote:
Tim and I have now completed the package renames at repository 
revision 391957. It is now safe to update and start building the 
Harmony classlib again.


If you use the IBM VME in combination with Harmony classlib, you will 
need to download the new version (v2) to continue working with 
classlib after revision 391957. They can be found at:

http://www-128.ibm.com/developerworks/java/jdk/harmony/index.html
and are called Harmony-vme-win.IA32-v2.zip for Windows and 
Harmony-vme-linux.IA32-v2.tar.gz for Linux.

The VME v1 is not compatible with Harmony classlib after revision 391957.


Awesome! I'm downloading the new VME

BTW, there is only "IBM Development Package for Apache Harmony v1.0 
" 
link in the index page. But after you login (if you already have a IBM 
ID), following the link you will see the new VME v2.

Regards,
Oliver

Tim Ellison wrote:

Ok, the renames are done -- I'll leave this around for a few hours in
case somebody screams.  Otherwise it is a case of checking out the
earlier revision.

Regards,
Tim

Tim Ellison wrote:
 

FYI: Before we do the refactoring I'm making a copy of trunk onto the
branch directory ... I'll remove it once things are settled.

Regards,
Tim

Oliver Deakin wrote:
   

Hi all,

Tim and I plan to complete the refactoring of package names from 
com.ibm

to org.apache.harmony over the next few hours. We are going to make a
backup of the current classlib trunk in a branch before we make our
changes, so we can revert should anything unexpected occur.

Please be aware that while we are making these changes the build will
probably be broken, so it may be worth not updating until we complete.
Ill send a mail to confirm when we are finished.

Regards,
Oliver

  


  





--
Richard Liang
China Software Development Lab, IBM

Re: [sablevm] SIGSEGV signal received from Cygwin

Enrico Migliore wrote:

> problem 4:  Native code dependancies
> ---
> The Harmony class library depends on the port layer:
> 
> http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/index.html
> 
> 
> Is this layer available for MSVC?

Yes it is written using MSVC (and in fact would require some
modification to make it work with gcc on Windows).

Regards,
Tim

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Starting my next round on BootJVM


Hi Dan,


Enrico,

Are you able to compile this latest source level?
 


I'm busy at the moment and didn't download your latest snapshot. Sorry :-(


Whether you can or not, would you mind to send
me your MS project and MS workspace files
(I forget if this is the right name on VS.  Maybe
this is just Eclipse nomenclature.)  I would like
to look at using your settings as the starting
point for MSVS compilations.

Dan Lydick

 


Yes, I can send you the source and the workspace files.
E-mail is fine?

The tag used for commenting out the code are:

 (four slashes)
enrico:   (my name)

I just checked and notice that the number of modifications I did is 
really little.
The major work was moving the declarations of a certain number of stack 
variables up to the top of the body of the function, as shown in the 
follwing example:


old_function:

int my_func (void)
{
   printf("Ciao");
   int i;
   i=0;
   return i;
}


new_function:

int my_func (void)
{
   int i;
   printf("Ciao");
   i=0;
   return i;
}


Enrico


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [sablevm] SIGSEGV signal received from Cygwin

2006-04-06 Thread Etienne Gagnon

Enrico Migliore wrote:
> I'm doing some testing on SableVM, and noticed that is receives the very
> same segmentation fault signal that JCHEVM does, from
> pthread_key_create() which is embedded in:
> 
> /usr/bin/cygwin1.dll
> 
> I read around that this problem could be fixed, but the error means that
> the Cygwin platform can only be used for developing, studying and
> testing and not for real world use.

Can you expand a little on this.  I am not sure what you mean.

> problem 1:  POSIX dependancy
> -
> The code contains a certain number of POSIX calls (dependancies). Much
> of them can be easily replaced, but some might be hard to replace.

I think that moving to Harmony's port library should solve this.  I
agree that it shouldn't be hard to fix.

> problem 2:  GCC extensions
> -
> The code contains some GCC extensions which are not ANSI.

When compiling a switch interpreter (--with-treading=switch), there
shouldn't be GCC extensions.  The only exception is atomic operations
which cannot be expressed in C.  Yet, I've found an elegant solution to
this: use Hans Boehm's atomic_ops library to get this code out of
SableVM.  See:

 http://sablevm.org/bugs/179

> problem 3:  Which compiler?
> -
> GCC seems to be the best candidate but MSVC is more popular.

Ideally, I'd like both to work.  Getting the faster direct/inlined
interpreters to work with MSVC might be tricky (require inline assembly
or linking to an asm library), but the switch interpreter shouldn't be a
problem.

> problem 4:  Native code dependancies
> ---
> The Harmony class library depends on the port layer:
> 
> http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/index.html

Yep, using this layer and atomic_ops should hopefully be sufficient to
remove all system-specific dependencies.  If anything is missing, we
should probably abstract it into the port layer.

Now, the interesting thing would be for Harmony native code to compile
and work on something other than ia32.  SableVM already works on pretty
much anything (using gcc, so far), as long as libffi and GNU classpath
compiles on the target.  The only other limitation is 2 operations that
cannot be expressed in C: compare_and_swap and clear_cache.

Etienne

-- 
Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/
SableVM:   http://www.sablevm.org/
SableCC:   http://www.sablecc.org/

signature.asc
Description: OpenPGP digital signature

Re: [jira] Updated: (HARMONY-308) java.nio.charset.Charset.encode(CharBuffer) returns bytes in a different order in Harmony and RI for the UTF-16 charset

2006-04-06 Thread Richard Liang


Dmitry M. Kononov wrote:

Hi Richard,

On 4/6/06, Richard Liang <[EMAIL PROTECTED]> wrote:
  

And as described in Unioccde, UTF-16 can be encoded as either big endian
or little endian, but a leading byte sequence corresponding to U+FEFF
will be used to distinguish the two byte orders.

If the leading byte sequence is FE FF, the whole byte sequence will be
regarded as big-endian
If the leading byte sequence is FF FE, the whole byte sequence will be
regarded as little-endian.

From your test, we can see Harmony use little-endian, while RI use
big-endian.

I'm sorry if my explanation make you confused :-)




I absolutely agreed with you. Thanks a lot for your explanation and sorry
for my brief description of the issue.

As you exactly noticed the cause of this issue that Harmony uses the
little-endian byte order, if an encoded UTF-16 sequence has no byte-order
mark. However, the spec reads such a case explicitly as follows:

"When decoding, the UTF-16 charset interprets a byte-order mark to indicate
the byte order of the stream but defaults to big-endian if there is no
byte-order mark; when encoding, it uses big-endian byte order and writes a
big-endian byte-order mark."

  

Hello Dmitry,

Yes, although Harmony and RI use different byte order, as both Harmony 
and RI use byte-order mark (U+FEFF), I think both Harmony and RI are 
compliant with the specification. So could we regard Harmony-308 as "not 
a bug"?

Thanks.

  

--
Dmitry M. Kononov
Intel Managed Runtime Division



  



--
Richard Liang
China Software Development Lab, IBM

[sablevm] SIGSEGV signal received from Cygwin


Hi,

I'm doing some testing on SableVM, and noticed that is receives the very 
same segmentation fault signal that JCHEVM does, from 
pthread_key_create() which is embedded in:


/usr/bin/cygwin1.dll

I read around that this problem could be fixed, but the error means that 
the Cygwin platform can only be used for developing, studying and 
testing and not for real world use.


Let me recap the problems we face when trying to port JCHEVM and SableVM 
on Windows:



problem 1:  POSIX dependancy
-
The code contains a certain number of POSIX calls (dependancies). Much 
of them can be easily replaced, but some might be hard to replace.



problem 2:  GCC extensions
-
The code contains some GCC extensions which are not ANSI.


problem 3:  Which compiler?
-
GCC seems to be the best candidate but MSVC is more popular.


problem 4:  Native code dependancies
---
The Harmony class library depends on the port layer:

http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/index.html

Is this layer available for MSVC?


Enrico



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[classlib][announce] New VM required to run classlib code!

Just so people can't claim they missed it ;-)

If you check out the Harmony classlib code *at or before* repository
revision 391919 you will need to use the IBM VME version 1 to run the code.

If you check out the classlib code now (revision 391957 onwards) you
will need to use the IBM VME version 2 to run the code.

You cannot mix and match between these versions.

Both versions of the IBM VME are available from:
http://www.ibm.com/developerworks/java/jdk/harmony


Thanks to Oliver for making the new VME available.

Regards,
Tim

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Refactoring package names

Tim and I have now completed the package renames at repository revision 
391957. It is now safe to update and start building the Harmony classlib 
again.


If you use the IBM VME in combination with Harmony classlib, you will 
need to download the new version (v2) to continue working with classlib 
after revision 391957. They can be found at:

http://www-128.ibm.com/developerworks/java/jdk/harmony/index.html
and are called Harmony-vme-win.IA32-v2.zip for Windows and 
Harmony-vme-linux.IA32-v2.tar.gz for Linux.

The VME v1 is not compatible with Harmony classlib after revision 391957.

Regards,
Oliver

Tim Ellison wrote:

Ok, the renames are done -- I'll leave this around for a few hours in
case somebody screams.  Otherwise it is a case of checking out the
earlier revision.

Regards,
Tim

Tim Ellison wrote:
  

FYI: Before we do the refactoring I'm making a copy of trunk onto the
branch directory ... I'll remove it once things are settled.

Regards,
Tim

Oliver Deakin wrote:


Hi all,

Tim and I plan to complete the refactoring of package names from com.ibm
to org.apache.harmony over the next few hours. We are going to make a
backup of the current classlib trunk in a branch before we make our
changes, so we can revert should anything unexpected occur.

Please be aware that while we are making these changes the build will
probably be broken, so it may be worth not updating until we complete.
Ill send a mail to confirm when we are finished.

Regards,
Oliver

  


  


--
Oliver Deakin
IBM United Kingdom Limited


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jira] Updated: (HARMONY-308) java.nio.charset.Charset.encode(CharBuffer) returns bytes in a different order in Harmony and RI for the UTF-16 charset

2006-04-06 Thread Dmitry M. Kononov

Hi Richard,

On 4/6/06, Richard Liang <[EMAIL PROTECTED]> wrote:
>
> And as described in Unioccde, UTF-16 can be encoded as either big endian
> or little endian, but a leading byte sequence corresponding to U+FEFF
> will be used to distinguish the two byte orders.
>
> If the leading byte sequence is FE FF, the whole byte sequence will be
> regarded as big-endian
> If the leading byte sequence is FF FE, the whole byte sequence will be
> regarded as little-endian.
>
> From your test, we can see Harmony use little-endian, while RI use
> big-endian.
>
> I'm sorry if my explanation make you confused :-)


I absolutely agreed with you. Thanks a lot for your explanation and sorry
for my brief description of the issue.

As you exactly noticed the cause of this issue that Harmony uses the
little-endian byte order, if an encoded UTF-16 sequence has no byte-order
mark. However, the spec reads such a case explicitly as follows:

"When decoding, the UTF-16 charset interprets a byte-order mark to indicate
the byte order of the stream but defaults to big-endian if there is no
byte-order mark; when encoding, it uses big-endian byte order and writes a
big-endian byte-order mark."

Thanks.

> --
> Dmitry M. Kononov
> Intel Managed Runtime Division

select one (was: RE: svn commit: r391955 [5/5] - in /incubator/harmony/enhanced/...)

2006-04-06 Thread Mikhail Loenko

We have pairs of implementations for the following functionality
(modules luni and security):

ASN1 De/Encoding
Base64 De/Encoding
DefaultPolicy

I'm going to compare and choose one them but I'd appreciate if someone
else would compare them too.

Thanks,
Mikhail

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Refactoring package names

Ok, the renames are done -- I'll leave this around for a few hours in
case somebody screams.  Otherwise it is a case of checking out the
earlier revision.

Regards,
Tim

Tim Ellison wrote:
> FYI: Before we do the refactoring I'm making a copy of trunk onto the
> branch directory ... I'll remove it once things are settled.
> 
> Regards,
> Tim
> 
> Oliver Deakin wrote:
>> Hi all,
>>
>> Tim and I plan to complete the refactoring of package names from com.ibm
>> to org.apache.harmony over the next few hours. We are going to make a
>> backup of the current classlib trunk in a branch before we make our
>> changes, so we can revert should anything unexpected occur.
>>
>> Please be aware that while we are making these changes the build will
>> probably be broken, so it may be worth not updating until we complete.
>> Ill send a mail to confirm when we are finished.
>>
>> Regards,
>> Oliver
>>
> 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Problems with accessing JIRA

2006-04-06 Thread Paulex Yang


Same problem to me:(.

Anton Avtamonov wrote:

Hi,

I cannot access JIRA with "Service Temporarily Unavailable" message.
Could someone please investigate?

Thank you in advance,
--
Anton Avtamonov,
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]


  



--
Paulex Yang
China Software Development Lab
IBM



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Problems with accessing JIRA

2006-04-06 Thread Anton Avtamonov

Hi,

I cannot access JIRA with "Service Temporarily Unavailable" message.
Could someone please investigate?

Thank you in advance,
--
Anton Avtamonov,
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Refactoring package names

FYI: Before we do the refactoring I'm making a copy of trunk onto the
branch directory ... I'll remove it once things are settled.

Regards,
Tim

Oliver Deakin wrote:
> Hi all,
> 
> Tim and I plan to complete the refactoring of package names from com.ibm
> to org.apache.harmony over the next few hours. We are going to make a
> backup of the current classlib trunk in a branch before we make our
> changes, so we can revert should anything unexpected occur.
> 
> Please be aware that while we are making these changes the build will
> probably be broken, so it may be worth not updating until we complete.
> Ill send a mail to confirm when we are finished.
> 
> Regards,
> Oliver
> 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[classlib] New snapshot build available

New class library snapshot builds are available on the Harmony binary
downloads page:

http://cvs.apache.org/dist/incubator/harmony/snapshots/

This is the state of the classlib code at repository revision 391918
(linux) and 391919 (windows) [1], and is made available as a convenience
for those who do not have the required tool chain to build the code
themselves.  The latest downloads for windows and linux are:

   harmony-classlib-r391918-Linux-x86-snapshot.tar.gz
   harmony-classlib-r391919-win-x86-snapshot.zip

Details of how to rebuild these binaries from source and how to obtain a
compatible VM [2] to run the code are given here:

http://incubator.apache.org/harmony/subcomponents/classlibrary/build_classlib.html

There are a number of bug fixes, enhancements, and new contributions in
this new snapshot.

Please download it and try it, and if there are any problems send a note
to the dev list.

Thanks to everyone who has contributed to this build!


Regards,
Tim

[1] they are different repository revision numbers because we share our
SVN with other projects, the code in each build is at an identical
Harmony level.

[2] This is the last snapshot that is designed to run on the
IBM VME version 1, subsequent builds will require the VME version 2.
Details of this change are being posted to the dev list separately.

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Refactoring package names


Hi all,

Tim and I plan to complete the refactoring of package names from com.ibm 
to org.apache.harmony over the next few hours. We are going to make a 
backup of the current classlib trunk in a branch before we make our 
changes, so we can revert should anything unexpected occur.


Please be aware that while we are making these changes the build will 
probably be broken, so it may be worth not updating until we complete. 
Ill send a mail to confirm when we are finished.


Regards,
Oliver

--
Oliver Deakin
IBM United Kingdom Limited


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Refactoring package names


Hi all,

Tim and I plan to complete the refactoring of package names from com.ibm 
to org.apache.harmony over the next few hours. We are going to make a 
backup of the current classlib trunk in a branch before we make our 
changes, so we can revert should anything unexpected occur.


Please be aware that while we are making these changes the build will 
probably be broken, so it may be worth not updating until we complete. 
Ill send a mail to confirm when we are finished.


Regards,
Oliver

--
Oliver Deakin
IBM United Kingdom Limited


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New IBM VME