Sorry for these multiple postbacks
On 6/16/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
>The assert makes sense as a safety, IMO.
>Notice how it caught this which hinted at work that had to be done
>elsewhere.
Yes, but the assert should not be giving us misleading information. If
On 6/16/06, Gregory Shimansky <[EMAIL PROTECTED] > wrote:
>This won't make anything good. The class_handle which is a pointer to
java
>heap object of type java.lang.Class is used very often, I am even
surprised
>that hello world even worked without java.lang.Class superinterfaces
>instances, but
I haven't read the whole thread yet, and I apologize
for the top post, but I couldn't see that the
discussion was heading for where I want to take it, so
I couldn't stop myself any longer.
Parts of Ant were conceptually inherited from make,
e.g. the common tendency for a buildfile to have an
incre
Rana Dasgupta wrote:
> Hi Gregory/Geir,
> Sorry for jumping in, but I have a question...
>
>
> On 6/16/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>>
>> >This method as the name says allocates a java.lang.Class instance for
>> the
>> >requested class and assigns class handle to the C nat
On Friday 16 June 2006 22:31 Rana Dasgupta wrote:
>I am also trying to understand the flow here. But since this is a dummy
> bootstrap case, would it make sense to just disable this assert instead of
> instantiating all the new interfaces and resolving everything, or is this
> instantiation nec
Paulex Yang wrote:
In Classpath, if select(2) returns EINTR, the select just returns
normally
(with nothing selected) and then the code checks Thread.interrupted().
If set, it closes and throws the exception as necessary.
Yes I noticed that select(2) on Linux has this good feature, but I
cannot
Hi Gregory/Geir,
Sorry for jumping in, but I have a question...
On 6/16/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>This method as the name says allocates a java.lang.Class instance for the
>requested class and assigns class handle to the C native Class struct.
But
>java.lang.Class can
Mark Hindess wrote:
On 16 June 2006 at 12:11, Tim Ellison <[EMAIL PROTECTED]> wrote:
Geir Magnusson Jr wrote:
I'd like to suggest that we get at least one of the project VMs to
support this before we switch.
Yep, Alexey said that there were "some (minor) changes" required to
DRLVM, and Archie
On 6/16/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
> >Talking of this maybe enable debug by default for DRL VM? It is used by
> >developers for development for the most part at the moment so
assertions and
>> symbol info may be quite useful. Also debug is built faster because it
is not
>
Gregory Shimansky wrote:
> On Friday 16 June 2006 16:29 Gregory Shimansky wrote:
>> 2006/6/16, Geir Magnusson Jr <[EMAIL PROTECTED]>:
>>> Gregory Shimansky wrote:
Sorry for delay, JIRA is painfully slow for me today. I submitted
HARMONY-612.
The reason I didn't do it immidiate
On Friday 16 June 2006 16:29 Gregory Shimansky wrote:
> 2006/6/16, Geir Magnusson Jr <[EMAIL PROTECTED]>:
> > Gregory Shimansky wrote:
> > > Sorry for delay, JIRA is painfully slow for me today. I submitted
> > > HARMONY-612.
> > >
> > > The reason I didn't do it immidiatelly is that I thought I am
I was thinking we may as well leave the version number the same, since
we don't want to keep the previous v3 hanging around anyway. Ive
overwritten the old package on the download site so noone should
ever get it again. I'm guessing that, since you are the first person
to complain of this, there a
Excellent - do you think it's worthwhile goosing the version to v4?
geir
(testing an IMAP account - dont' respond to this email address directly...)
Oliver Deakin wrote:
Geir Magnusson Jr wrote:
Oliver Deakin wrote:
[EMAIL PROTECTED] wrote:
I just got my ubuntu box setup, and when
No worries. You made it.
- Start Original Message -
Sent: Fri, 16 Jun 2006 08:13:19 -0500
From: "bootjvm" <[EMAIL PROTECTED]>
To: harmony-dev@incubator.apache.org
Subject: RE: [VOTE] Acceptance of Harmony-528 : AWT, Java2D and Swing
>
> +1
>
> (Better late than never)
>
> Dan Lydick
>
Geir Magnusson Jr wrote:
Oliver Deakin wrote:
[EMAIL PROTECTED] wrote:
I just got my ubuntu box setup, and when running the test suite, I see
this :
[junit] Exception in thread "main" java.lang.NoClassDefFoundError:
org.apache.harmony.luni.www.protocol.jar.JarURLConnection
+1
(Better late than never)
Dan Lydick
> [Original Message]
> From: Geir Magnusson Jr <[EMAIL PROTECTED]>
> To:
> Date: 6/5/06 5:38:08 PM
> Subject: [VOTE] Acceptance of Harmony-528 : AWT, Java2D and Swing
>
>
> I have received the ACQs and the BCC for Harmony-528, so I can assert
> that the
test - please ignore
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
2006/6/16, Geir Magnusson Jr <[EMAIL PROTECTED]>:
Gregory Shimansky wrote:
> Sorry for delay, JIRA is painfully slow for me today. I submitted
> HARMONY-612.
>
> The reason I didn't do it immidiatelly is that I thought I am missing
> something and you have the fix already somewhere as you wrot
I realize my response wasn't clear, but I was advocating that we switch
to APR-defined make strategy...
I re-read my response, and it was clear to me I was thinking it, but
didn't state explicitly.
geir
Garrett Rooney wrote:
> On 6/16/06, Nataly Naumova <[EMAIL PROTECTED]> wrote:
>
>> here's th
Gregory Shimansky wrote:
> Sorry for delay, JIRA is painfully slow for me today. I submitted
> HARMONY-612.
>
> The reason I didn't do it immidiatelly is that I thought I am missing
> something and you have the fix already somewhere as you wrote that VM
> worked
> on WinXP for you.
'worked' is
On 6/16/06, Nataly Naumova <[EMAIL PROTECTED]> wrote:
here's the reason of not building *extra* things by their own build.
Initially there was a concept not to use own build for every *extra*
things, such as APR or CLASSLIB in order to support different
compilers and configurations. For APR it
Nathan,
VMI Atomicity/Lock API - All of the AtomicXXX classes are delegated to a
VM-specific API for atomic gets and sets. This API will need to be defined
and then implemented by the various VMs. Many of the lock APIs also make use
of this API.
I have done some experiments with concurrent in
On 16 June 2006 at 11:48, Oliver Deakin <[EMAIL PROTECTED]> wrote:
> Mark Hindess wrote:
> > There are a couple of things I'd like to "fix" about the build.xml
> > structure. I'd be very interested in what other people think about
> > these issues. In no particular order:
> >
> > 1) Currently wh
Sorry for delay, JIRA is painfully slow for me today. I submitted
HARMONY-612.
The reason I didn't do it immidiatelly is that I thought I am missing
something and you have the fix already somewhere as you wrote that VM worked
on WinXP for you.
2006/6/16, Geir Magnusson Jr <[EMAIL PROTECTED]>:
Mark Hindess wrote:
> On 16 June 2006 at 6:37, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
>> Mark Hindess wrote:
>>> 3) Currently the 'build' target automatically does a 'clean'. I think
>>> this dependency should be removed and a new target - 'dist' perhaps? -
>>> should be created for doing
can you shove that into a JIRA please? I'll apply immediately. Thanks
I'm sure there are more problems to be discovered. :)
geir
Gregory Shimansky wrote:
> Hello Geir
>
> I've tried to build drlvm with your most recent upadtes to build (revision
> 414775) and everything compiled fine but run
MIkhail,
I fully agree that we need to test protected methods of public classes
- java.beans.PersistenceDelegate for example. But I was talking about
a bit different thing - testing children of PersistenceDelegate that
are NOT public API classes. But we still need to implement it somehow.
User is
On 16 June 2006 at 12:11, Tim Ellison <[EMAIL PROTECTED]> wrote:
> Geir Magnusson Jr wrote:
> > I'd like to suggest that we get at least one of the project VMs to
> > support this before we switch.
>
> Yep, Alexey said that there were "some (minor) changes" required to
> DRLVM, and Archie said th
On 16 June 2006 at 6:37, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
>
> Mark Hindess wrote:
> >
> > 3) Currently the 'build' target automatically does a 'clean'. I think
> > this dependency should be removed and a new target - 'dist' perhaps? -
> > should be created for doing non-incremental
On 16 June 2006 at 11:07, Tim Ellison <[EMAIL PROTECTED]> wrote:
> I just sent a note with a subset of these same concerns!
>
> That's quite the laundry list ...
>
> Mark Hindess wrote:
> >
> > 6) Mikhail (IIRC?) modified a few of the module build files to use
> > macros. I like this idea (in f
Geir Magnusson Jr wrote:
> I'd like to suggest that we get at least one of the project VMs to
> support this before we switch.
Yep, Alexey said that there were "some (minor) changes" required to
DRLVM, and Archie said that JCHEVM should already handle the new
classfile format. Hopefully we will a
Hello Geir
I've tried to build drlvm with your most recent upadtes to build (revision
414775) and everything compiled fine but running hello world application
failed on assertion in class loader. I had to patch assertion to include
superinterfaces for java.lang.Class from 1.5 like this:
Index: d
Mark Hindess wrote:
There are a couple of things I'd like to "fix" about the build.xml
structure. I'd be very interested in what other people think about
these issues. In no particular order:
1) Currently when you look at the classlib checkout for the first time
the first think most people are
On 6/16/06, Geir Magnusson Jr wrote:
Stepan Mishura wrote:
> On 6/16/06, Geir Magnusson Jr wrote:
>>
>> but that means that you touch one file, the whole thing gets rebuilt.
>> Doesn't make much sense...
>>
>> Let me ask - how do you use this?
>
>
> Right, if one file is updated it doesn't ma
Tim Ellison wrote:
> While we are on the subject, how about we move the build.xml up a level
> into classlib/trunk (and each modules' build.xml up a level too) [1]. I
> would like to leave the helper scripts down in the make subdirs, such
> that the build.xml would only have targets that we expe
I'd like to suggest that we get at least one of the project VMs to
support this before we switch.
geir
Tim Ellison wrote:
> Jimmy, Jing Lv wrote:
>> Seems everyone is glad to move to 1.5, so I'd like to know when will
>> Harmony reach this milestone? I can hardly wait :)
>
> Good to see your ent
Mark Hindess wrote:
> There are a couple of things I'd like to "fix" about the build.xml
> structure. I'd be very interested in what other people think about
> these issues. In no particular order:
>
> 1) Currently when you look at the classlib checkout for the first time
> the first think mos
Nataly Naumova wrote:
> On 6/16/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
>> Why exactly is APR slightly massaged and then specially built?
>>
>> Why can't we just do the regular ./configure -> make sequence to build
>> it?
>
> Hi Geir,
>
> here's the reason of not building *extra* thing
Alexander,
I modified the subject to make it more obvious:). Sorry at first for
responsing so late, I was a little distracted by the NIO work. I agree
with you that option 1 and 2 below is feasible, and I have some rough
thoughts on the cache mechanism, I'm interested in how others think
ab
That's wonderful -- thanks Alexey and the team at Intel.
Regards,
Tim
Alexey Petrenko wrote:
> Dear all,
>
> I am glad to announce next contribution to Harmony class library on
> behalf of Intel. The archive with the contribution is uploaded to the
> following location:
>
> http://issues.apac
On 16 June 2006 at 10:52, Tim Ellison <[EMAIL PROTECTED]> wrote:
>
> While we are on the subject, how about we move the build.xml up a
> level into classlib/trunk (and each modules' build.xml up a level
> too) [1]. I would like to leave the helper scripts down in the make
> subdirs, such that the
Alexey Petrenko wrote:
> Ok, I'll try this tomorrow.
> But in this case all headers should be copied before any building. It
> is the only possible problem.
Yes. Today, the classlib has to continue to be buildable independently
and first (against stubs where necessary), then the DRLVM and others
Stepan Mishura wrote:
> On 6/16/06, Geir Magnusson Jr wrote:
>>
>> but that means that you touch one file, the whole thing gets rebuilt.
>> Doesn't make much sense...
>>
>> Let me ask - how do you use this?
>
>
> Right, if one file is updated it doesn't make sense to rebuild
> everything so
> I
Jimmy, Jing Lv wrote:
> Seems everyone is glad to move to 1.5, so I'd like to know when will
> Harmony reach this milestone? I can hardly wait :)
Good to see your enthusiasm! I was going to get an IBM VME download in
place first so that those who choose can continue to use that VM without
interru
I just sent a note with a subset of these same concerns!
That's quite the laundry list ...
Mark Hindess wrote:
> There are a couple of things I'd like to "fix" about the build.xml
> structure. I'd be very interested in what other people think about
> these issues. In no particular order:
>
> 1
Oliver Deakin wrote:
>
>
> [EMAIL PROTECTED] wrote:
>> I just got my ubuntu box setup, and when running the test suite, I see
>> this :
>>
>> [junit] Exception in thread "main" java.lang.NoClassDefFoundError:
>> org.apache.harmony.luni.www.protocol.jar.JarURLConnection
>>
>
> This packa
Tim Ellison wrote:
Alexey Varlamov wrote:
So we need answers from DRLVM and jchevm guys...
Archie has expressed the jchevm opinion in favour of the change --
anyone familiar with DRLVM care to comment?
(Of course this would be after Geir's VM build work, just asking)
Regards,
Tim
DRLVM needs
While we are on the subject, how about we move the build.xml up a level
into classlib/trunk (and each modules' build.xml up a level too) [1]. I
would like to leave the helper scripts down in the make subdirs, such
that the build.xml would only have targets that we expect anyone to
call, and the su
Alexey Petrenko wrote:
> Try to unset JAVA_HOME variable. It helps sometimes...
I'm one of those old-timers that still believes that computers are
deterministic mechanical devices... "sometimes"?? :)
geir
>
> 2006/6/16, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
>> I just got my ubuntu box set
There are a couple of things I'd like to "fix" about the build.xml
structure. I'd be very interested in what other people think about
these issues. In no particular order:
1) Currently when you look at the classlib checkout for the first time
the first think most people are going to do is look
(switching mail encoding - hopefully nothing lost)
Paulex Yang wrote:
> Archie,
>
> Thank you for the explanation, I'm appreciated most of your suggestion,
> because mostly I planned to do the same thing as part of interruption
> and asynchronized close implementation. But actually the problem is
Tim Ellison wrote:
Oliver Deakin wrote:
Tim Ellison wrote:
Oliver Deakin wrote:
move them out to the tools/launcher directory where they better belong.
So, with the removal of these Harmony internal files from depends, that
directory becomes external
dependencies only
On 6/16/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
Why exactly is APR slightly massaged and then specially built?
Why can't we just do the regular ./configure -> make sequence to build it?
Hi Geir,
here's the reason of not building *extra* things by their own build.
Initially there was
Richard Liang wrote:
Hello Alexander,
I agree that my implementation about "Connection: Keep-Alive" is
incorrect. Thank you.
And as mentioned in the spec of "Persistent Connections"[1]:
.
/The support for HTTP keep-Alive is done transparently. However, it
can be controlled by system p
Vladimir
Vladimir Ivanov wrote:
The current reports don't provide code source linking. Are you going to
add it?
There were no information for 'security' and 'auth' modules, but, I have
updated the pages and now there is source code linking for all modules.
One more issue to discuss: exclude
[EMAIL PROTECTED] wrote:
I just got my ubuntu box setup, and when running the test suite, I see this :
[junit] Exception in thread "main" java.lang.NoClassDefFoundError:
org.apache.harmony.luni.www.protocol.jar.JarURLConnection
This package was renamed a while back. It's now
org.apach
Hello Richard,
If we are going to implement persistent connections and make them
configurable we should fix this piece of code anyway. So it is not
necessary to roll back your fix.
I will file a JIRA about this issue.
Thank You,
Alexander
57 matches
Mail list logo
