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
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,
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
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 compiles
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.
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.
You may do
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
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 link with
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 :
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
*)
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'm
Paulex, Mikhail, all,
Do I understand the proposed directory structure for stress tests
correctly?
src/test/
|
+- impl/
|
+- compliant/
|
+- stress/
| |
| +- org
| |
| +- apache
| |
| +- harmony
|
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
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,
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
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
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
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
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
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:
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: [prayer]
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
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
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
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 Debian
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
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
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
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
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
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
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]
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
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
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.
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
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 community to
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
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
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
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
the classes
41 matches
Mail list logo
