Geir Magnusson Jr wrote:
>
>
> Nathan Beyer wrote:
>> I may be a bit naïve in regards to such things, but would it be
>> possible to
>> create our own stripped down compiler package? My thought is that we
>> could
>> just checkout the appropriate JDT code from Eclipse's CVS server,
>> build only
Vladimir, Andrew
2006/4/26, Andrew Zhang <[EMAIL PROTECTED]>:
Here I propose two solutions:
1. Set the ByteBuffer to the limit, and store the remaining ByteBuffer in
decoder. Invokers doesn't care the position of in. If the result is
UNDERFLOW and there're furthur input, just pass the new input
In my opinion the presence a lot of patches for same contribution (until it
will be put to SVN) is not good idea.
It's very conveniently to have one patch if its size is not too big.
Otherwise we will have the issues with the maintenance.
Now we try to fix the build problems (using different ver
According to guidlines draft both are possible if you run tests
from bootclasspath:
"If the test is designed to be run from bootclasspath then its package
is the same
as the package of the class under test"
Thanks,
Mikhail
2006/5/4, Geir Magnusson Jr <[EMAIL PROTECTED]>:
For example, you have
I linked 443 to the original DRL contrib JIRA.
geir
Ivan Volosyuk wrote:
Leo, thank you, for the clarification.
I have created JIRA issue 'Harmony-443' with the patch.
It fixes compilation with GCC-3.4.6
I have checked, that fix doesn't break GCC-3.3.x build or windows build.
Now I am workin
Mike Milinkovich wrote:
>
>>have you guys given any thoughts of producing
>>Maven-compatible packages for those things? (just curious)]
>
>
> Short answer: no.
>
> Maven currently isn't used within Eclipse. As a result, there just isn't a
> lot of internal demand from within our committer comm
Leo Simons wrote:
On Thu, May 04, 2006 at 04:50:28PM -0700, Rana Dasgupta wrote:
We should probably hold off on patching right now?
I don't see why you can't attach patches to the relevant jira issue, if the
code is accepted then its likely the patch will be, too :-)
Personally, I'd pref
Nathan Beyer wrote:
I may be a bit naïve in regards to such things, but would it be possible to
create our own stripped down compiler package? My thought is that we could
just checkout the appropriate JDT code from Eclipse's CVS server, build only
the classes necessary and create a wee JAR.
Chris, try patch from Harmony-443 for gcc-3.4.6 it should also work for
gcc-3.4.5. With the patch I was able to build VM and started eclipse.
As for gcc-4.1.0, I have prepared patch which fixes all the compilation
problem, code still builds and works if compiled by gcc-3.4.6 and now
compiles on g
Hi Vladimir,
In the process of getting compiler 3.3.4 to work, I uninstalled the
gcc that came with Fedora. It is possible that g++ wasn't installed
completely by the Fedora installer and I hadn't installed updates on
that system that might have fixed it. Since I've gotten it working
with 3.3
This is great news everybody!
Another linux success story here. I managed to compile and then run
eclipse on Fedora Core 4 using gcc 3.3.4 as was suggested by Vladimir.
I compiled gcc 3.3.4 [libs, gcc, g++, ...] from the gcc 3.3.4 sources
[which involved playing some games with packages on the
Leo, thank you, for the clarification.
I have created JIRA issue 'Harmony-443' with the patch.
It fixes compilation with GCC-3.4.6
I have checked, that fix doesn't break GCC-3.3.x build or windows build.
Now I am working on compilation issues with GCC-4.1.0.
I've found a few in log4cxx and some
Hi, Vladimir
The bug has been raised in ICU bug tracking system serveral months ago[1].
ICU has noticed this bug and will fix the bug in next release version.
Thanks.
[1] (http://bugs.icu-project.org/cgi-bin/icu-bugs/conversion?id=5074)
On 5/4/06, Vladimir Strigun (JIRA) <[EMAIL PROTECTED]> w
On Thu, May 04, 2006 at 04:50:28PM -0700, Rana Dasgupta wrote:
> We should probably hold off on patching right now?
I don't see why you can't attach patches to the relevant jira issue, if the
code is accepted then its likely the patch will be, too :-)
Patch management is going to be hard if the
We should probably hold off on patching right now?
The submission compiles and runs fine with XP V2, msvc VC7 and with SUSE
9.2 and GCC 3.3.4.
We should pick the Linux/GCC version that we run Harmony builds
regularly on and make all the changes in one shot to fix the compile on
that. Has th
I may be a bit naïve in regards to such things, but would it be possible to
create our own stripped down compiler package? My thought is that we could
just checkout the appropriate JDT code from Eclipse's CVS server, build only
the classes necessary and create a wee JAR.
I'm guessing that the big
Great! Good progress.
Here is mine:
gcc (GCC) 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)
Gcc-4.x is masked in gentoo, so I have started with gcc-3.4.6.
It was harder then before. I have made number of changes in jitrino/**/Set.h
to get it compile.
A few more changes in other places in ji
Stefano meant something slightly different... Maven defines a standard jar
repository layout that it uses to find and download dependency jars for
building.
The main one is at ibiblio and hosts stuff from many organizations and projects.
I believe stefano was suggesting that your artfacts (suc
> have you guys given any thoughts of producing
> Maven-compatible packages for those things? (just curious)]
Short answer: no.
Maven currently isn't used within Eclipse. As a result, there just isn't a
lot of internal demand from within our committer community to do something
like this.
But
On 4 May 2006 at 21:43, "Ivan Volosyuk" <[EMAIL PROTECTED]> wrote:
>
> DRLVM compiled fine on my home computer. Eclipse works.
> Configuration:
> Gentoo stable, not much up to date.
> gcc (GCC) 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)
> Binutils: 2.16.1
> Kernel: 2.6.15.6
I'm using
DRLVM compiled fine on my home computer. Eclipse works.
Configuration:
Gentoo stable, not much up to date.
gcc (GCC) 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)
Binutils: 2.16.1
Kernel: 2.6.15.6
One build issue:
When using /usr/bin/ant compilation failed even for ant-1.6.5, I have
compiled
Mike Milinkovich wrote:
> Oops
>
> Don't worry! I did not take offence, and didn't mean to imply that I had. I
> laughed my ass off when I read the prayer.
>
> Sarcasm is considered good fun in Canada. That's why we're generally funnier
> than Americans :-)
Used to believe that too, then I s
Hi Chris,
Thanks for the useful notes:
1) On setting the COMPILER_CFG_SCRIPT as outlined in the README. I
could not figure out how to get it to work with the Windows Platform
SDK. There is no vcvars.bat in the platform sdk just SetEnv.Cmd which
doesn't work quite the same way. I switched it
Tim Ellison wrote:
Geir Magnusson Jr wrote:
There was actually zero sarcasm intended there. I was just hoping to
get your attention. I've used this format effectively w/ the JCP as
well. :)
The only comment that I thought might get taken the wrong way was the
"bloat" comment, but from the p
Geir Magnusson Jr wrote:
> There was actually zero sarcasm intended there. I was just hoping to
> get your attention. I've used this format effectively w/ the JCP as
> well. :)
>
> The only comment that I thought might get taken the wrong way was the
> "bloat" comment, but from the perspective o
Crapneed more coffee this morning.
That should read "...I need to set *your* expectations really low..."
> -Original Message-
> From: Mike Milinkovich [mailto:[EMAIL PROTECTED]
> Sent: May 4, 2006 9:37 AM
> To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED]
> Subject: RE: [p
Oops
Don't worry! I did not take offence, and didn't mean to imply that I had. I
laughed my ass off when I read the prayer.
Sarcasm is considered good fun in Canada. That's why we're generally funnier
than Americans :-)
I will ask the compiler guys if it's already available somewhere. But g
There was actually zero sarcasm intended there. I was just hoping to
get your attention. I've used this format effectively w/ the JCP as
well. :)
The only comment that I thought might get taken the wrong way was the
"bloat" comment, but from the perspective of being interested in getting
th
I've tried parsing the prayer a few times to delete the sarcasm and
understand exactly what you're asking for, but as with most prayers, the
language appears to be imprecise.
What *exactly* is it that you're looking for?
Mike Milinkovich
Executive Director,
Eclipse Foundation, Inc.
Office: 613-
thx! I just wanted to make sure we knew of any places where we could
help or vector people that were interested...
geir
Tim Ellison wrote:
It is fully complete and compatible for Java 5 (modulo the usual spec
ambiguities and absences that we are familiar with).
Regards,
Tim
Geir Magnusson
Tim Ellison wrote:
I was suggesting that you try to capture the reasons for the layout and
the package naming of tests etc. in a descriptive doc.
At this point it would be a 'proposed' doc -- the mail thread is getting
too long to follow all the arguments so having a document we can work on
to
For example, you have
org.apache.harmony.luni.internal.net.www.protocol - package under test
org.apache.harmony.luni.tests.internal.net.www.protocol - package for
the test
where if it's an implementation test since it's an 'internal' package,
wouldn't the the test most likely be
o.a.h.l.
It is fully complete and compatible for Java 5 (modulo the usual spec
ambiguities and absences that we are familiar with).
Regards,
Tim
Geir Magnusson Jr wrote:
> Does anyone have an idea how 'complete' or 'compatible' the eclipse
> compiler is for Java 5? Given the state of the ecosystem, I'm g
I was suggesting that you try to capture the reasons for the layout and
the package naming of tests etc. in a descriptive doc.
At this point it would be a 'proposed' doc -- the mail thread is getting
too long to follow all the arguments so having a document we can work on
together is likely more p
Geir
What kind of conventions do you mean?
If it is package naming then I thought we have the same conventions
for all types of the tests: bootclasspath tests go to the same package as
class, classpath tests go to o.a.h.module.tests.package
Am I missing something?
Thanks,
Mikhail
2006/5/4, G
Alexei
package naming for stress tests does not exactly match what was described,
(there is no 'stress' in the package name) but directory layout is correct.
2006/5/4, Fedotov, Alexei A <[EMAIL PROTECTED]>:
Paulex, Mikhail, all,
Do I understand the proposed directory structure for stress tests
Paulex, Mikhail, all,
Do I understand the proposed directory structure for stress tests
correctly?
src/test/
|
+- impl/
|
+- compliant/
|
+- stress/
| |
| +- org
| |
| +- apache
| |
| +- harmony
|
Mikhail Loenko wrote:
2006/5/3, Mikhail Loenko <[EMAIL PROTECTED]>:
Ok, I'll put this on the website
I've put it on the web-site (it has not appeared yet)
Comments are welcome
I think you only captures half of it. You also need to describe
conventions for harmony-specific tests...
I'
If I'm not wrong the Eclipse 3.2 has the unit tests allowing to make this
thing.
I mean the following:
jdtcorebuilder (*1.5 JRE required*)
org.eclipse.jdt.core.tests.builder jdtcorecompiler
(*1.5 JRE required*) org.eclipse.jdt.core.tests.compiler jdtcoremodel
(*1.5JRE required
*) org.eclipse.jdt
2006/5/3, Mikhail Loenko <[EMAIL PROTECTED]>:
Ok, I'll put this on the website
I've put it on the web-site (it has not appeared yet)
Comments are welcome
Thanks,
Mikhail
-
Terms of use : http://incubator.apache.org/harmony/
On 4 May 2006 at 13:58, "Andrey Chernyshev" <[EMAIL PROTECTED]> wrote:
>
> Mark Hindess wrote:
> > 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
Seriously, anyone have any contacts there? (Church of Eclipse, not
billygraham...)
Mike, are you around? :)
geir
Tim Ellison wrote:
Dear Harmony Project,
I think you are on the wrong mailing list, please try
www.billygraham.org (or whatever your personal preference).
Regards,
Tim
Geir
Does anyone have an idea how 'complete' or 'compatible' the eclipse
compiler is for Java 5? Given the state of the ecosystem, I'm guessing
there is no general test suite for java compilers...
geir
-
Terms of use : http://incu
On 4 May 2006 at 13:58, "Andrey Chernyshev" <[EMAIL PROTECTED]> wrote:
> > 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.
> Y
I can do Haiku as well. :)
Neil Bartlett wrote:
Or get Eclipse to just make the jar's we need (and others need)
available somewhere...
Probably the best way to ask for that is to raise a bug in
https://bugs.eclipse.org/bugs/ against the JDT component. If the bug
report is in the form of a haik
Or get Eclipse to just make the jar's we need (and others need)
available somewhere...
Probably the best way to ask for that is to raise a bug in
https://bugs.eclipse.org/bugs/ against the JDT component. If the bug
report is in the form of a haiku then all the better.
Dear Harmony Project,
I think you are on the wrong mailing list, please try
www.billygraham.org (or whatever your personal preference).
Regards,
Tim
Geir Magnusson Jr wrote:
> Oh Mighty Eclipse Foundation,
>
> Thou art soest bountiful, we praise your munificence, especially that
> which compi
Hello, Alexei,
Thank you for reply.
> Do you have in mind some standard glue for these simple building
blocks
> as well?
Here is a model which describes how to compose simple building blocks.
Let's define the following terms:
* Brick - any junit Test
* Generator - junit Test which compos
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, ma
Hi Mark,
thank you very much for this valuable information. Indeed we used the gcc of
3.X version to build DRLVM.
It's not clear a cause why this header file (stl_hash_fun.h) has been
renamed for the recent gcc versions.
It seems the DRLVM sources should be correspondingly tuned to avoid the
p
Chris,
most likely I've understood a root cause of your issue. I paid attention
the /usr/include/ext directory is absent on your machine. It means (or can
mean)
the g++ compiler has been partially installed for your case. Please, try to
eliminate it and to re-build again.
Thanks,
Vladimir.
The classes loaded by the J9 system class loader have incorrect CodeSource
objects. Particularly the location URL of CodeSource object specifying the
place from where the class has been loaded has null value. To reproduce the
bug run the following test:
test.java
52 matches
Mail list logo
