Re: [RFC/PATCH] Invokedynamic API stubs

2011-02-08 Thread Mark Wielaard
On Mon, 2011-02-07 at 22:01 +0200, Pekka Enberg wrote:
 On Mon, 2011-02-07 at 15:24 +0100, Dr Andrew John Hughes wrote:
   I guess I could keep it on my Github mirror until I have something
   concrete enough to be merged to trunk.
  
  I'd prefer to have it in HEAD as long as it's clearly marked as stubs
  (the NotImplementedException I mentioned) and there is work actively
  taking place.
  Then there's always the (slim) possibility someone else can work on it :-)
 
 That was my original thinking as well. Does the included patch look
 better to you? Mark, what do you think about this?

I admit to still just not like stubs, however they are setup.
If creating branches wasn't such a pain with CVS I would really
recommend doing all this on a branch and only merge when ready and it
can actually be used with some VM. I guess it is just time to bite the
bullet and create some time to move to mercurial and setup some rules
about how to create working branches. I won't veto getting this in right
now if that is really what you and Andrew want, but I am not
particularly excited either.

 This patch implements the work-in-progress invokedynamic API stubs described
 here:
 
   http://download.oracle.com/javase/7/docs/api/java/dyn/package-summary.html
 
 The classes don't do anything useful yet and don't even contain all the
 specified methods.

Might be better to find some other reference to point people at. This
screams it isn't finished yet, might move. I don't have a good
suggestion though. The java doc in OpenJDK is distributed under the GPL
though, but doesn't seem to be online yet.

Cheers,

Mark





Re: [RFC/PATCH] Invokedynamic API stubs

2011-02-08 Thread Pekka Enberg
Hi Mark,

On Mon, 2011-02-07 at 15:24 +0100, Dr Andrew John Hughes wrote:
   I guess I could keep it on my Github mirror until I have something
   concrete enough to be merged to trunk.
  
  I'd prefer to have it in HEAD as long as it's clearly marked as stubs
  (the NotImplementedException I mentioned) and there is work actively
  taking place.
  Then there's always the (slim) possibility someone else can work on it :-)

On Mon, 2011-02-07 at 22:01 +0200, Pekka Enberg wrote:
 That was my original thinking as well. Does the included patch look
 better to you? Mark, what do you think about this?

On Tue, Feb 8, 2011 at 2:28 PM, Mark Wielaard m...@klomp.org wrote:
 I admit to still just not like stubs, however they are setup.
 If creating branches wasn't such a pain with CVS I would really
 recommend doing all this on a branch and only merge when ready and it
 can actually be used with some VM. I guess it is just time to bite the
 bullet and create some time to move to mercurial and setup some rules
 about how to create working branches. I won't veto getting this in right
 now if that is really what you and Andrew want, but I am not
 particularly excited either.

Well, I'd like to keep everyone involved excited so maybe Mercural
branch is the way to go here?

Pekka



Re: [RFC/PATCH] Invokedynamic API stubs

2011-02-08 Thread Dr Andrew John Hughes
On 13:28 Tue 08 Feb , Mark Wielaard wrote:
 On Mon, 2011-02-07 at 22:01 +0200, Pekka Enberg wrote:
  On Mon, 2011-02-07 at 15:24 +0100, Dr Andrew John Hughes wrote:
I guess I could keep it on my Github mirror until I have something
concrete enough to be merged to trunk.
   
   I'd prefer to have it in HEAD as long as it's clearly marked as stubs
   (the NotImplementedException I mentioned) and there is work actively
   taking place.
   Then there's always the (slim) possibility someone else can work on it :-)
  
  That was my original thinking as well. Does the included patch look
  better to you? Mark, what do you think about this?
 
 I admit to still just not like stubs, however they are setup.
 If creating branches wasn't such a pain with CVS I would really
 recommend doing all this on a branch and only merge when ready and it
 can actually be used with some VM. I guess it is just time to bite the
 bullet and create some time to move to mercurial and setup some rules
 about how to create working branches. I won't veto getting this in right
 now if that is really what you and Andrew want, but I am not
 particularly excited either.
 

I assume by Mercurial 'branching', you mean what we do with IcedTea6 HEAD
and the releases at present, not the in-tree support?  Because that's worse
than CVS IME.

  This patch implements the work-in-progress invokedynamic API stubs described
  here:
  
http://download.oracle.com/javase/7/docs/api/java/dyn/package-summary.html
  
  The classes don't do anything useful yet and don't even contain all the
  specified methods.
 
 Might be better to find some other reference to point people at. This
 screams it isn't finished yet, might move. I don't have a good
 suggestion though. The java doc in OpenJDK is distributed under the GPL
 though, but doesn't seem to be online yet.
 

Is there anything stopping us having the docs generated by IcedTea online?
Maybe the builder could produce them?

 Cheers,
 
 Mark
 
 
 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37