Re: GCJ ------ file type not supported by system

2014-09-04 Thread Andrew Haley
On 03/09/14 18:59, Per Bothner wrote:
 On 09/03/2014 09:35 AM, Guillermo Rodriguez Garcia wrote:
 What would you like me to do? How can I help ?
 
 More useful than updating Classoath per se would be creating
 a version of GCJ that uses OpenJDK's javac for compiling to bytecodes,

Why?  Eclipse's javac seems fine.

 (I don't believe Eclipse's compiler is as solid or complete, though that may 
 be
 my bias from having worked with javac engineers.  It's probably good enough 
 for
 at least the initial stages of merging in OpenJDK classes.)

Oh, OK.  Most of the world I know about uses Eclipse for everything.

Andrew.





Re: GCJ ------ file type not supported by system

2014-09-04 Thread Christopher Friedt
On Sep 3, 2014 12:13 PM, Guillermo Rodriguez Garcia 
guille.rodrig...@gmail.com wrote:
  If someone wants to take the project, the best thing to do is to start
  contributing patches. After all, how can the maintainer know if someone
  is seriously willing to take his role if there lack of a serious and
  recent contribution flow?

I've been eavesdropping on this bread a bit. Personally, I don't really
care who is maintaining classpath, but I still use it regularly for
embedded Java on several architectures.

There are even a few patches I've been using for years that I would like to
get upstream as configurable features. I did submit these to the list, if
I'm not mistaken,but never received any feedback. In particular,

1) a patch to allow mmaping special files (e.g. /dev/video0) via
MappedByteBuffer FileChannel.map()
2) a patch that implements direct ByteBuffers (i.e. reducing the JNI
overhead per-transaction) that extends the ability to CharBuffers,
ShortBuffers, LongBuffers, etc.

If I am not able to get these patches upstream (even with some reworking),
I'm effectively maintaining a fork, which I would rather not do.

A gift repository would, of course, be a welcome improvement :-)

C


Re: GCJ ------ file type not supported by system

2014-09-04 Thread Andïï
On 4 September 2014 12:31, Christopher Friedt chrisfri...@gmail.com wrote:


 On Sep 3, 2014 12:13 PM, Guillermo Rodriguez Garcia 
 guille.rodrig...@gmail.com wrote:
   If someone wants to take the project, the best thing to do is to start
   contributing patches. After all, how can the maintainer know if someone
   is seriously willing to take his role if there lack of a serious and
   recent contribution flow?

  I've been eavesdropping on this bread a bit. Personally, I don't really
 care who is maintaining classpath, but I still use it regularly for
 embedded Java on several architectures.


I'll assume that's meant to be 'thread' ;) Eavesdropping on baked goods
doesn't sound as promising.


 There are even a few patches I've been using for years that I would like
 to get upstream as configurable features. I did submit these to the list,
 if I'm not mistaken,but never received any feedback. In particular,

 1) a patch to allow mmaping special files (e.g. /dev/video0) via
 MappedByteBuffer FileChannel.map()
 2) a patch that implements direct ByteBuffers (i.e. reducing the JNI
 overhead per-transaction) that extends the ability to CharBuffers,
 ShortBuffers, LongBuffers, etc.

 If I am not able to get these patches upstream (even with some reworking),
 I'm effectively maintaining a fork, which I would rather not do.


I've not seen either of these. Please resubmit them and we can look at
getting them in.


 A gift repository would, of course, be a welcome improvement :-)

 C


We have one: http://git.savannah.gnu.org/cgit/classpath.git/log/
-- 
Andii :-)


Re: GCJ ------ file type not supported by system

2014-09-04 Thread Andïï
On 3 September 2014 17:12, Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com wrote:

 Hi Mario,

 2014-09-01 12:47 GMT+02:00 Mario Torre neug...@redhat.com:
 [...]
  Yes I am sure about this, but that is not my point. What I am saying
  is that it would be very good for the project to be maintained by a
  team who really wants to move things forward.
 
 
  I understand what you mean, but the current maintainer has always
  integrated patches and done releases, I think the problem is not the
  lack of one maintainer willing to move forward, is lack of manpower to
  do it.

 Well,part of the job of the maintainer for an OSS project, perhaps the
 most important one, is to attract and motivate other developers. This
 is how the 'lack of manpower' problem is solved.

 Just as an example: 0.99 is now over 2 years old, yet the official
 Classpath site still lists 0.98 (2009) as current. 0.99 is not even
 listed in the downloads page. If the first thing a developer sees is
 that the latest release is more than 5 years old, that does not
 exactly help. I already mentioned this in this list, by the way
 (https://www.mail-archive.com/classpath@gnu.org/msg15456.html).


I'm aware of this and I see your point. The issue is that the web pages
rely on a tool called wml that seems to be no longer maintained and
I've simply not had chance to look at fixing it up myself or doing away
with it.

If you want to do so, feel free. I can point you in the right direction.



 Also I am not the first one to raise these concerns. Pekka Enberg
 wrote an excellent post about the future of GNU Classpath in Dec
 2010, and the situation has not changed a lot since then. I cannot
 find the original post anymore (the blog was hosted at posterous
 spaces, which is no longer available), but the thread in the ML
 remains (http://www.spinics.net/lists/gnu-classpath/msg03027.html).
 But you already know this of course, since you took part in that
 conversation.

 
  As I said, anyone can step in, if patches start to flow (including bug
  fixes) I'm sure they'll be integrated correctly and quickly.
 
  If someone wants to take the project, the best thing to do is to start
  contributing patches. After all, how can the maintainer know if someone
  is seriously willing to take his role if there lack of a serious and
  recent contribution flow?
 

 Of course if someone wanted to take on the project, then that would be
 the process. I completely agree with you.


There have been three changes made this year already:

http://git.savannah.gnu.org/cgit/classpath.git/log/

They were included pretty much as soon as they were posted.

I also have some stuff I'm working on, but it has to take second place
to maintaining three (soon four) major versions of OpenJDK/IcedTea.

 At the end what I am saying is that:

 1. Development of GNU Classpath seems to be stalled now (quoting from
 an earlier post from Andrew Haley: I have to tell you that Classpath
 is not being actively developed, so your problem is unlikely to be
 fixed.)

Sorry, but that's simply nonsense, as can be seen by what I've said above.
It's slow, because there aren't many people with the time and interest, but
it's certainly not 'stalled'.


 2. This is due to the lack of manpower, which in turn is probably due
 to the lack of interested developers, but also to the fact that most
 of the development effort of the current team is going to OpenJDK
 instead.

 3. Given the above, perhaps the current maintainers should consider
 switching priorities and start actively looking for a competent
 successor (as in lesson #5 of ESR's The Cathedral and the Bazaar).

Maybe rather than complaining and telling us what we already know, you
could help by providing patches?

I'm sorry if that sounds harsh, but this is really quite unhelpful to someone
who's trying to do what they can for the project with the limited resources
available.

Pekka did so and, as far as I'm aware, they've all been integrated into the
codebase.


 Best,
 --
 Guillermo Rodriguez Garcia
 guille.rodrig...@gmail.com




-- 
Andii :-)



Re: GCJ ------ file type not supported by system

2014-09-04 Thread Guillermo Rodriguez

El 04/09/2014 14:14, Andïï escribió:
 On 3 September 2014 17:12, Guillermo Rodriguez Garcia
 guille.rodrig...@gmail.com wrote:

 Hi Mario,

 2014-09-01 12:47 GMT+02:00 Mario Torre neug...@redhat.com:
 [...]
 Yes I am sure about this, but that is not my point. What I am saying
 is that it would be very good for the project to be maintained by a
 team who really wants to move things forward.


 I understand what you mean, but the current maintainer has always
 integrated patches and done releases, I think the problem is not the
 lack of one maintainer willing to move forward, is lack of manpower to
 do it.

 Well,part of the job of the maintainer for an OSS project, perhaps the
 most important one, is to attract and motivate other developers. This
 is how the 'lack of manpower' problem is solved.

 Just as an example: 0.99 is now over 2 years old, yet the official
 Classpath site still lists 0.98 (2009) as current. 0.99 is not even
 listed in the downloads page. If the first thing a developer sees is
 that the latest release is more than 5 years old, that does not
 exactly help. I already mentioned this in this list, by the way
 (https://www.mail-archive.com/classpath@gnu.org/msg15456.html).
 
 
 I'm aware of this and I see your point. The issue is that the web pages
 rely on a tool called wml that seems to be no longer maintained and
 I've simply not had chance to look at fixing it up myself or doing away
 with it.
 
 If you want to do so, feel free. I can point you in the right direction.

I was going to send a set of patches against the CVS repository that
Mark Wielaard posted 
(http://web.cvs.savannah.gnu.org/viewvc/classpath/?root=classpath)

I don't really see the point of fixing an obsolete tool that is no
longer maintained. Can't we update the HTML pages directly (short term
solution) and then later decide on what to do with WML ?

If patching the HTML files is OK (that's what I understood from Mark's
e-mail) I will do that.


 Also I am not the first one to raise these concerns. Pekka Enberg
 wrote an excellent post about the future of GNU Classpath in Dec
 2010, and the situation has not changed a lot since then. I cannot
 find the original post anymore (the blog was hosted at posterous
 spaces, which is no longer available), but the thread in the ML
 remains (http://www.spinics.net/lists/gnu-classpath/msg03027.html).
 But you already know this of course, since you took part in that
 conversation.


 As I said, anyone can step in, if patches start to flow (including bug
 fixes) I'm sure they'll be integrated correctly and quickly.

 If someone wants to take the project, the best thing to do is to start
 contributing patches. After all, how can the maintainer know if someone
 is seriously willing to take his role if there lack of a serious and
 recent contribution flow?


 Of course if someone wanted to take on the project, then that would be
 the process. I completely agree with you.

 
 There have been three changes made this year already:
 
 http://git.savannah.gnu.org/cgit/classpath.git/log/
 
 They were included pretty much as soon as they were posted.
 
 I also have some stuff I'm working on, but it has to take second place
 to maintaining three (soon four) major versions of OpenJDK/IcedTea.
 
 At the end what I am saying is that:

 1. Development of GNU Classpath seems to be stalled now (quoting from
 an earlier post from Andrew Haley: I have to tell you that Classpath
 is not being actively developed, so your problem is unlikely to be
 fixed.)
 
 Sorry, but that's simply nonsense,

Sorry, but it wasn't me who said Classpath is not being actively developed.

 as can be seen by what I've said above.
 It's slow, because there aren't many people with the time and interest, but
 it's certainly not 'stalled'.

That's a very subtle difference, if any.

 

 2. This is due to the lack of manpower, which in turn is probably due
 to the lack of interested developers, but also to the fact that most
 of the development effort of the current team is going to OpenJDK
 instead.

 3. Given the above, perhaps the current maintainers should consider
 switching priorities and start actively looking for a competent
 successor (as in lesson #5 of ESR's The Cathedral and the Bazaar).
 
 Maybe rather than complaining and telling us what we already know, you
 could help by providing patches?

I think that asking to help rather than complain is a bit unfair.

First of all I am not complaining, I am trying to suggest that perhaps,
if time and resources are limited, the best way to spend them would be to
look for a successor.

Second, I am willing to help in any way I can, and already stated that. 
Yes I can submit patches (and will do) although in my opinion this does
not address the underlying problem. I think that updating the website
(to help raise awareness and attract developers) would be much more
useful than sending patches to fix bugs or issues.

 
 I'm sorry if that sounds harsh, but this is really quite 

Re: Re: GCJ ------ file type not supported by system

2014-09-04 Thread Guillermo Rodriguez Garcia
Hello Pekka,

El jueves, 4 de septiembre de 2014, Pekka Enberg penb...@kernel.org
escribió:

 On Thu, Sep 4, 2014 at 7:17 PM, Guillermo Rodriguez
 guille.rodrig...@gmail.com javascript:; wrote:
  I think that asking to help rather than complain is a bit unfair.

 No, it's really not unfair at all. You are basically saying Andrew is
 doing a crappy job as a maintainer


No, I am definitely NOT saying that, nothing even close. Please don't put
your words in my mouth, thank you.


  in reality he's pretty much
 the only one developing GNU Classpath these days...


 On Thu, Sep 4, 2014 at 7:17 PM, Guillermo Rodriguez
 guille.rodrig...@gmail.com javascript:; wrote:
  First of all I am not complaining, I am trying to suggest that perhaps,
  if time and resources are limited, the best way to spend them would be to
  look for a successor.

 Thanks for the suggestion. We're going to just ignore it because it
 makes no sense.


Ok :)

Once you answer the hypothetical question *who* should
 be the successor, you will understand why.


I see, so if I don't have the answer, the question makes no sense. Ok.



 On Thu, Sep 4, 2014 at 7:17 PM, Guillermo Rodriguez
 guille.rodrig...@gmail.com javascript:; wrote:
  Second, I am willing to help in any way I can, and already stated that.
  Yes I can submit patches (and will do) although in my opinion this does
  not address the underlying problem. I think that updating the website
  (to help raise awareness and attract developers) would be much more
  useful than sending patches to fix bugs or issues.

 I also think the website needs fixing. Are sources to it available
 somewhere and who is able to update it if someone actually sends a
 patch against it?


That's what I asked as well.

Guillermo


-- 
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com


Re: Re: GCJ ------ file type not supported by system

2014-09-04 Thread Pekka Enberg
El jueves, 4 de septiembre de 2014, Pekka Enberg penb...@kernel.org escribió:
 No, it's really not unfair at all. You are basically saying Andrew is
 doing a crappy job as a maintainer

On Thu, Sep 4, 2014 at 10:29 PM, Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com wrote:
 No, I am definitely NOT saying that, nothing even close. Please don't put
 your words in my mouth, thank you.

Of course you are saying that. Why else would you even bring up the
issue of finding a competent successor which implies that Andrew is
no longer interested in GNU Classpath and neglecting its maintenance?

El jueves, 4 de septiembre de 2014, Pekka Enberg penb...@kernel.org escribió:
 Once you answer the hypothetical question *who* should
 be the successor, you will understand why.

On Thu, Sep 4, 2014 at 10:29 PM, Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com wrote:
 I see, so if I don't have the answer, the question makes no sense. Ok.

You didn't even try to answer the question, did you?

If Andrew actually needed a competent successor (he doesn't), what
is required of that person? The person needs to be an active
developer, needs to understand GNU Classpath well, and has to have
support from people who actually developed the project, right?

Are you able to make an educated guess who actually meets that criteria?

- Pekka



Re: GCJ ------ file type not supported by system

2014-09-04 Thread Andrew Haley
On 09/04/2014 09:07 PM, Pekka Enberg wrote:
 El jueves, 4 de septiembre de 2014, Pekka Enberg penb...@kernel.org 
 escribió:
 No, it's really not unfair at all. You are basically saying Andrew is
 doing a crappy job as a maintainer
 
 On Thu, Sep 4, 2014 at 10:29 PM, Guillermo Rodriguez Garcia
 guille.rodrig...@gmail.com wrote:
 No, I am definitely NOT saying that, nothing even close. Please don't put
 your words in my mouth, thank you.
 
 Of course you are saying that. Why else would you even bring up the
 issue of finding a competent successor which implies that Andrew is
 no longer interested in GNU Classpath and neglecting its maintenance?

Whoa Pekka, be nice.  Let's just assume that Guillermo is sincere, and
he wants to help.

The problem isn't competence.  All of us are competent.  It's a lack of
time.  All of us, I believe, have day jobs, and none of them are in GNU
Classpath development.

 El jueves, 4 de septiembre de 2014, Pekka Enberg penb...@kernel.org 
 escribió:
 Once you answer the hypothetical question *who* should
 be the successor, you will understand why.
 
 On Thu, Sep 4, 2014 at 10:29 PM, Guillermo Rodriguez Garcia
 guille.rodrig...@gmail.com wrote:
 I see, so if I don't have the answer, the question makes no sense. Ok.
 
 You didn't even try to answer the question, did you?
 
 If Andrew actually needed a competent successor (he doesn't), what
 is required of that person? The person needs to be an active
 developer, needs to understand GNU Classpath well, and has to have
 support from people who actually developed the project, right?
 
 Are you able to make an educated guess who actually meets that criteria?

Guillermo, please.  You phrased your point badly, in a way that was likely
to annoy people.  I believe that you didn't want to do that.

Everyone: let's have a proper discussion.  Is there something we can
do with GNU Classpath that takes it further forward.  And, if so,
what?  What would our goals be?

Andrew.



Re: GCJ ------ file type not supported by system

2014-09-04 Thread Pekka Enberg
On Thu, Sep 4, 2014 at 11:15 PM, Andrew Haley a...@redhat.com wrote:
 Everyone: let's have a proper discussion.  Is there something we can
 do with GNU Classpath that takes it further forward.  And, if so,
 what?  What would our goals be?

I think Guillermo is right that we need to update the GNU Classpath
web site. Right now, it gives the impression that the project is
abandoned...

- Pekka



Re: Re: GCJ ------ file type not supported by system

2014-09-04 Thread Guillermo Rodriguez Garcia
El jueves, 4 de septiembre de 2014, Pekka Enberg penb...@kernel.org
escribió:

 El jueves, 4 de septiembre de 2014, Pekka Enberg penb...@kernel.org
 javascript:; escribió:
  No, it's really not unfair at all. You are basically saying Andrew is
  doing a crappy job as a maintainer

 On Thu, Sep 4, 2014 at 10:29 PM, Guillermo Rodriguez Garcia
 guille.rodrig...@gmail.com javascript:; wrote:
  No, I am definitely NOT saying that, nothing even close. Please don't put
  your words in my mouth, thank you.

 Of course you are saying that.


No, I am not.


 Why else would you even bring up the
 issue of finding a competent successor which implies that Andrew is
 no longer interested in GNU Classpath and neglecting its maintenance?


Wrong. I said that if the current maintainers don't have time or resources,
perhaps they could look for a competent successor. One that they trust.
That does not imply that the current maintainers are not competent. That
might have been your interpretation, but it is not what I think and it is
not what I said.

(By the way, when I said competent successor I was just quoting Eric S
Raymond, literally. I even linked to the source.)


 El jueves, 4 de septiembre de 2014, Pekka Enberg penb...@kernel.org
 javascript:; escribió:
  Once you answer the hypothetical question *who* should
  be the successor, you will understand why.

 On Thu, Sep 4, 2014 at 10:29 PM, Guillermo Rodriguez Garcia
 guille.rodrig...@gmail.com javascript:; wrote:
  I see, so if I don't have the answer, the question makes no sense. Ok.

 You didn't even try to answer the question, did you?


No. I don't have the answer, and I don't think that having an answer is a
prerequisite for a question to be valid.



 If Andrew actually needed a competent successor (he doesn't),


If he doesn't, then all the better. I am not trying to annoy anyone, just
trying to help.

At least this ignited a discussion. That's already something.

Guillermo


-- 
Guillermo Rodriguez Garcia
guille.rodrig...@gmail.com


Re: GCJ ------ file type not supported by system

2014-09-04 Thread Mark Wielaard
On Thu, 2014-09-04 at 18:17 +0200, Guillermo Rodriguez wrote:
 El 04/09/2014 14:14, Andïï escribió:
  I'm aware of this and I see your point. The issue is that the web pages
  rely on a tool called wml that seems to be no longer maintained and
  I've simply not had chance to look at fixing it up myself or doing away
  with it.
  
  If you want to do so, feel free. I can point you in the right direction.
 
 I was going to send a set of patches against the CVS repository that
 Mark Wielaard posted 
 (http://web.cvs.savannah.gnu.org/viewvc/classpath/?root=classpath)
 
 I don't really see the point of fixing an obsolete tool that is no
 longer maintained. Can't we update the HTML pages directly (short term
 solution) and then later decide on what to do with WML ?
 
 If patching the HTML files is OK (that's what I understood from Mark's
 e-mail) I will do that.

I admit that I don't really like doing that. But when I looked for my
working copy of WML I noticed it doesn't actually work anymore on my
latest distro :{ And when looking for the latest version at
http://thewml.org/ the Distrib location is broken, so I don't actually
know where to get a source copy right now.

So we should probably move away from WML and find some other framework
to do the website it.

Given that we don't yet have that other framework it might be good to
just make the changes to the HTML files in the web repo directly. If you
do sent a patch for that please also sent a patch explaining the current
situation for the main git repo doc/www.gnu.org/README. So others know
to not try to update the website using the old WML framework. And please
note that the publishing rule in doc/www.gnu.org/Makefile relies on the
other docs one level up to publish the guides under
https://www.gnu.org/software/classpath/docs/docs.html

Also, as a side note, I just noticed the webpages look bad under https,
they look fine under http though.

Thanks,

Mark