java.lang.NumberFormatException from java.io.Writer.write()

[alansam]

Hi,

I'm not sure if this is a bug or if I'm just doing something wrong.

The following program fails with a java.lang.NumberFormatException when attempting to write strings to a file (compiled with NetRexx 3.00 and NetRexx 3.01RC2, build 1-20110925-2337):

/* NetRexx */

options replace format comments java crossref savelog symbols binary

players = [String -

    'Stephen Harper:Goal' -

  , 'Fabricio Coloccini:Def' -

]

filename = 'TxFileIO001N.txt'

fileobj  = File(filename)

filebuff = BufferedWriter(FileWriter(fileobj))

loop r_ = 0 to players.length - 1

  rec = String(players[r_])

  say rec

  filebuff.write(rec)

  filebuff.newLine

  end r_

filebuff.close

return

The generated Java program is:

/* Generated from 'TxFileIO001N.nrx' 30 Sep 2011 16:27:34 [v3.01] */

/* Options: Binary Comments Crossref Decimal Format Java Logo Replace Symbols Trace2 Verbose3 */

/* NetRexx */

public class TxFileIO001N{

 private static final java.lang.String $0="TxFileIO001N.nrx";

 

 public static void main(java.lang.String $0s[]) throws java.io.IOException{

  java.lang.String players[];

  java.lang.String filename;

  java.io.File fileobj;

  java.io.BufferedWriter filebuff;

  int r_=0;

  java.lang.String rec=null;

  players=new java.lang.String[]{"Stephen Harper:Goal","Fabricio Coloccini:Def"};

  

  

  

  

  

  filename="TxFileIO001N.txt";

  fileobj=new java.io.File(filename);

  filebuff=new java.io.BufferedWriter((java.io.Writer)(new java.io.FileWriter(fileobj)));

  

  {int $1=players.length-1;r_=0;r_:for(;r_<=$1;r_++){

   rec=new java.lang.String(players[r_]);

   netrexx.lang.RexxIO.Say(rec);

   filebuff.write(netrexx.lang.Rexx.toRexx(rec).toint());

   filebuff.newLine();

   }

  }/*r_*/

  filebuff.close();

  

  return;

  }

 

 private TxFileIO001N(){return;}

 }

Observe that the call to filebuff.write(rec)is being generated as filebuff.write(netrexx.lang.Rexx.toRexx(rec).toint());and is thus attempting to use the Writer.write(int) method instead of the Writer.write(String) method.

As a test I rewrote the program in straight Java:

import java.io.File;

import java.io.FileWriter;

import java.io.BufferedWriter;

import java.io.IOException;

public class TxFileIO001J {

  public static void main(String[] args) throws IOException {

    String[] players = new String[] { "Stephen Harper:Goal", "Fabricio Coloccini:Def", };

  

    String         filename = "TxFileIO001J.txt";

    File            fileobj = new File(filename);

    BufferedWriter filebuff = new BufferedWriter((java.io.Writer)(new FileWriter(fileobj)));

    for (String rec : players) {

      System.out.println(rec);

      filebuff.write(rec);

      filebuff.newLine();

    }

    filebuff.close();

  

    return;

  }

}

This program works as expected and the output file is complete.

Any suggestions?

Alan.

--
Can't tweet, won't tweet!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ThSITC]

Hello Alan,

   I think coding:

       int irc
      
       ...
       irc=filebuff.write(rec)

   should avoid the pitfall.

   I also think that NetRexx generated the .toint, as write is a function returning an integer return code....

   Whether this is a bug: I have to leave this for the expert(s) :-)

Thomas Schneider
===================================================
Am 01.10.2011 02:15, schrieb Alan Sampson:

Hi,

I'm not sure if this is a bug or if I'm just doing something wrong.

The following program fails with a java.lang.NumberFormatException when attempting to write strings to a file (compiled with NetRexx 3.00 and NetRexx 3.01RC2, build 1-20110925-2337):

/* NetRexx */

options replace format comments java crossref savelog symbols binary

players = [String -

    'Stephen Harper:Goal' -

  , 'Fabricio Coloccini:Def' -

]

filename = 'TxFileIO001N.txt'

fileobj  = File(filename)

filebuff = BufferedWriter(FileWriter(fileobj))

loop r_ = 0 to players.length - 1

  rec = String(players[r_])

  say rec

  filebuff.write(rec)

  filebuff.newLine

  end r_

filebuff.close

return

The generated Java program is:

/* Generated from 'TxFileIO001N.nrx' 30 Sep 2011 16:27:34 [v3.01] */

/* Options: Binary Comments Crossref Decimal Format Java Logo Replace Symbols Trace2 Verbose3 */

/* NetRexx */

public class TxFileIO001N{

 private static final java.lang.String $0="TxFileIO001N.nrx";

 

 public static void main(java.lang.String $0s[]) throws java.io.IOException{

  java.lang.String players[];

  java.lang.String filename;

  java.io.File fileobj;

  java.io.BufferedWriter filebuff;

  int r_=0;

  java.lang.String rec=null;

  players=new java.lang.String[]{"Stephen Harper:Goal","Fabricio Coloccini:Def"};

  

  

  

  

  

  filename="TxFileIO001N.txt";

  fileobj=new java.io.File(filename);

  filebuff=new java.io.BufferedWriter((java.io.Writer)(new java.io.FileWriter(fileobj)));

  

  {int $1=players.length-1;r_=0;r_:for(;r_<=$1;r_++){

   rec=new java.lang.String(players[r_]);

   netrexx.lang.RexxIO.Say(rec);

   filebuff.write(netrexx.lang.Rexx.toRexx(rec).toint());

   filebuff.newLine();

   }

  }/*r_*/

  filebuff.close();

  

  return;

  }

 

 private TxFileIO001N(){return;}

 }

Observe that the call to filebuff.write(rec)is being generated as filebuff.write(netrexx.lang.Rexx.toRexx(rec).toint());and is thus attempting to use the Writer.write(int) method instead of the Writer.write(String) method.

As a test I rewrote the program in straight Java:

import java.io.File;

import java.io.FileWriter;

import java.io.BufferedWriter;

import java.io.IOException;

public class TxFileIO001J {

  public static void main(String[] args) throws IOException {

    String[] players = new String[] { "Stephen Harper:Goal", "Fabricio Coloccini:Def", };

  

    String         filename = "TxFileIO001J.txt";

    File            fileobj = new File(filename);

    BufferedWriter filebuff = new BufferedWriter((java.io.Writer)(new FileWriter(fileobj)));

    for (String rec : players) {

      System.out.println(rec);

      filebuff.write(rec);

      filebuff.newLine();

    }

    filebuff.close();

  

    return;

  }

}

This program works as expected and the output file is complete.

Any suggestions?

Alan.

--
Can't tweet, won't tweet!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[measel]

The variable rec is assigned a string rather than defined as a string so it is by default Netrexx.
The bracket on the player array is in the wrong place.
Use say to see what it is.
 

From: Alan Sampson [mailto:[hidden email]]
Sent: Friday, September 30, 2011 08:15 PM
To: [hidden email] <[hidden email]>
Subject: [Ibm-netrexx] java.lang.NumberFormatException fromjava.io.Writer.write()
 

Hi,

I'm not sure if this is a bug or if I'm just doing something wrong.

The following program fails with a java.lang.NumberFormatException when attempting to write strings to a file (compiled with NetRexx 3.00 and NetRexx 3.01RC2, build 1-20110925-2337):

/* NetRexx */

options replace format comments java crossref savelog symbols binary

players = [String -

    'Stephen Harper:Goal' -

  , 'Fabricio Coloccini:Def' -

]

filename = 'TxFileIO001N.txt'

fileobj  = File(filename)

filebuff = BufferedWriter(FileWriter(fileobj))

loop r_ = 0 to players.length - 1

  rec = String(players[r_])

  say rec

  filebuff.write(rec)

  filebuff.newLine

  end r_

filebuff.close

return

The generated Java program is:

/* Generated from 'TxFileIO001N.nrx' 30 Sep 2011 16:27:34 [v3.01] */

/* Options: Binary Comments Crossref Decimal Format Java Logo Replace Symbols Trace2 Verbose3 */

/* NetRexx */

public class TxFileIO001N{

 private static final java.lang.String $0="TxFileIO001N.nrx";

 

 public static void main(java.lang.String $0s[]) throws java.io.IOException{

  java.lang.String players[];

  java.lang.String filename;

  java.io.File fileobj;

  java.io.BufferedWriter filebuff;

  int r_=0;

  java.lang.String rec=null;

  players=new java.lang.String[]{"Stephen Harper:Goal","Fabricio Coloccini:Def"};

  

  

  

  

  

  filename="TxFileIO001N.txt";

  fileobj=new java.io.File(filename);

  filebuff=new java.io.BufferedWriter((java.io.Writer)(new java.io.FileWriter(fileobj)));

  

  {int $1=players.length-1;r_=0;r_:for(;r_<=$1;r_++){

   rec=new java.lang.String(players[r_]);

   netrexx.lang.RexxIO.Say(rec);

   filebuff.write(netrexx.lang.Rexx.toRexx(rec).toint());

   filebuff.newLine();

   }

  }/*r_*/

  filebuff.close();

  

  return;

  }

 

 private TxFileIO001N(){return;}

 }

Observe that the call to filebuff.write(rec)is being generated as filebuff.write(netrexx.lang.Rexx.toRexx(rec).toint());and is thus attempting to use the Writer.write(int) method instead of the Writer.write(String) method.

As a test I rewrote the program in straight Java:

import java.io.File;

import java.io.FileWriter;

import java.io.BufferedWriter;

import java.io.IOException;

public class TxFileIO001J {

  public static void main(String[] args) throws IOException {

    String[] players = new String[] { "Stephen Harper:Goal", "Fabricio Coloccini:Def", };

  

    String         filename = "TxFileIO001J.txt";

    File            fileobj = new File(filename);

    BufferedWriter filebuff = new BufferedWriter((java.io.Writer)(new FileWriter(fileobj)));

    for (String rec : players) {

      System.out.println(rec);

      filebuff.write(rec);

      filebuff.newLine();

    }

    filebuff.close();

  

    return;

  }

}

This program works as expected and the output file is complete.

Any suggestions?

Alan.

--
Can't tweet, won't tweet!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[George Hovey-2]

Alan,
The only single argument form of write defined in BufferedWriter is write(int), although it inherits write(String) and write(int) from Writer.  Could this be a clue?
George

On Fri, Sep 30, 2011 at 8:15 PM, Alan Sampson <[hidden email]> wrote:

Hi,

I'm not sure if this is a bug or if I'm just doing something wrong.

The following program fails with a java.lang.NumberFormatException when attempting to write strings to a file (compiled with NetRexx 3.00 and NetRexx 3.01RC2, build 1-20110925-2337):

/* NetRexx */

options replace format comments java crossref savelog symbols binary

players = [String -

    'Stephen Harper:Goal' -

  , 'Fabricio Coloccini:Def' -

]

filename = 'TxFileIO001N.txt'

fileobj  = File(filename)

filebuff = BufferedWriter(FileWriter(fileobj))

loop r_ = 0 to players.length - 1

  rec = String(players[r_])

  say rec

  filebuff.write(rec)

  filebuff.newLine

  end r_

filebuff.close

return

The generated Java program is:

/* Generated from 'TxFileIO001N.nrx' 30 Sep 2011 16:27:34 [v3.01] */

/* Options: Binary Comments Crossref Decimal Format Java Logo Replace Symbols Trace2 Verbose3 */

/* NetRexx */

public class TxFileIO001N{

 private static final java.lang.String $0="TxFileIO001N.nrx";

 

 public static void main(java.lang.String $0s[]) throws java.io.IOException{

  java.lang.String players[];

  java.lang.String filename;

  java.io.File fileobj;

  java.io.BufferedWriter filebuff;

  int r_=0;

  java.lang.String rec=null;

  players=new java.lang.String[]{"Stephen Harper:Goal","Fabricio Coloccini:Def"};

  

  

  

  

  

  filename="TxFileIO001N.txt";

  fileobj=new java.io.File(filename);

  filebuff=new java.io.BufferedWriter((java.io.Writer)(new java.io.FileWriter(fileobj)));

  

  {int $1=players.length-1;r_=0;r_:for(;r_<=$1;r_++){

   rec=new java.lang.String(players[r_]);

   netrexx.lang.RexxIO.Say(rec);

   filebuff.write(netrexx.lang.Rexx.toRexx(rec).toint());

   filebuff.newLine();

   }

  }/*r_*/

  filebuff.close();

  

  return;

  }

 

 private TxFileIO001N(){return;}

 }

Observe that the call to filebuff.write(rec)is being generated as filebuff.write(netrexx.lang.Rexx.toRexx(rec).toint());and is thus attempting to use the Writer.write(int) method instead of the Writer.write(String) method.

As a test I rewrote the program in straight Java:

import java.io.File;

import java.io.FileWriter;

import java.io.BufferedWriter;

import java.io.IOException;

public class TxFileIO001J {

  public static void main(String[] args) throws IOException {

    String[] players = new String[] { "Stephen Harper:Goal", "Fabricio Coloccini:Def", };

  

    String         filename = "TxFileIO001J.txt";

    File            fileobj = new File(filename);

    BufferedWriter filebuff = new BufferedWriter((java.io.Writer)(new FileWriter(fileobj)));

    for (String rec : players) {

      System.out.println(rec);

      filebuff.write(rec);

      filebuff.newLine();

    }

    filebuff.close();

  

    return;

  }

}

This program works as expected and the output file is complete.

Any suggestions?

Alan.

--
Can't tweet, won't tweet!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[alansam]

Mike,

On 1 October 2011 04:24, Measel, Mike <[hidden email]> wrote:

The variable rec is assigned a string rather than defined as a string so it is by default Netrexx.

 

Not according to the generated Java:

    rec=new java.lang.String(players[r_]);

The bracket on the player array is in the wrong place.

 

If that were true it wouldn't compile.  It does compile; I'm getting a run-time error. 

Use say to see what it is.

I have.  I get the first element in the players array printed, then I get the exception.  Here's a sample run:

$ nrc -keepasjava TxFileIO001N

NetRexx portable processor, version NetRexx 3.01RC2, build 1-20110925-2337

Copyright (c) RexxLA, 2011.  All rights reserved.

Parts Copyright (c) IBM Corporation, 1995,2008.

Program TxFileIO001N.nrx

Compilation of 'TxFileIO001N.nrx' successful

$ java TxFileIO001N

Stephen Harper:Goal

Exception in thread "main" java.lang.NumberFormatException: Stephen Harper:Goal

at netrexx.lang.Rexx.toint(Rexx.nrx:627)

at TxFileIO001N.main(TxFileIO001N.nrx:31)

and if I modify the program to use the BufferedWriter.write(String,int,int) method it works.

My point is that NetRexx is choosing the wrong method prototype and coercing my String input into an int so it can use the Writer.write(int) method.  It should be choosing the Writer.write(String) method; the input is a Java String.)

FYI  Here's my modified working version:

/* NetRexx */

options replace format comments java crossref savelog symbols binary

players = [String -

    'Stephen Harper:Goal' -

  , 'Fabricio Coloccini:Def' -

]

filename = 'TxFileIO001N.txt'

fileobj  = File(filename)

filebuff = BufferedWriter(FileWriter(fileobj))

loop r_ = 0 to players.length - 1

  rec = String(players[r_])

  say rec

  filebuff.write(rec, 0, rec.length)

  filebuff.newLine

  end r_

filebuff.close

return

and the relevant part of the resulting Java:

{int $1=players.length-1;r_=0;r_:for(;r_<=$1;r_++){

   rec=new java.lang.String(players[r_]);

   netrexx.lang.RexxIO.Say(rec);

   filebuff.write(rec,0,rec.length());

   filebuff.newLine();

   }

  }/*r_*/

--
Can't tweet, won't tweet!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[alansam]

Thomas,

On 30 September 2011 22:18, Thomas Schneider <[hidden email]> wrote:

Hello Alan,

   I think coding:

       int irc
      
       ...
       irc=filebuff.write(rec)

   should avoid the pitfall.

The Writer.write() family of methods are void functions; they don't provide any return values.  Your suggestion would never compile.

Alan.

--
Can't tweet, won't tweet!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[alansam]

George,

On 1 October 2011 05:50, George Hovey <[hidden email]> wrote:

Alan,
The only single argument form of write defined in BufferedWriter is write(int), although it inherits write(String) and write(int) from Writer.  Could this be a clue?
George

Yes!  That's a huge clue.  Downcasting filebuff to a Writer generates a working program:

/* NetRexx */

options replace format comments java crossref savelog symbols binary

players = [String -

    'Stephen Harper:Goal' -

  , 'Fabricio Coloccini:Def' -

]

filename = 'TxFileIO001N.txt'

fileobj  = File(filename)

filebuff = BufferedWriter(FileWriter(fileobj))

loop r_ = 0 to players.length - 1

  rec = String(players[r_])

  say rec

  (Writer filebuff).write(rec)

  filebuff.newLine

  end r_

filebuff.close

return

but I don't think I should need to.  As you observe BufferedWriter is a Writer so NetRexx should be choosing the correct method without the downcast.  That's why I asked if this is a bug.

Alan.

--
Can't tweet, won't tweet!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Mike Cowlishaw]

 

My point is that NetRexx is choosing the wrong method prototype and coercing my String input into an int so it can use the Writer.write(int) method.  It should be choosing the Writer.write(String) method; the input is a Java String.) 

 

Given you specified BufferedWriter, and NetRexx can do a conversion to the (int) method there ... why is it choosing the 'wrong' method prototype? 

 

A String (or Rexx) object is a vague type that can be converted to a number (and other things) if required to do so, and I think you requested that it do that ... a match against the specific class that you specified has to be better than a match against the superclass?

 

[But others have had this confusion .. so perhaps a Warning would be useful.]

 

 

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Mike Cowlishaw]

 

but I don't think I should need to.  As you observe BufferedWriter is a Writer so NetRexx should be choosing the correct method without the downcast.  That's why I asked if this is a bug. 

 

But you specifically told NetRexx to use BufferedWriter .. and it could, so it did ... it would only go up the inheritance chain if it faieled at the level you specified.   [If I remember correctly ....]

 

Mike 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[George Hovey-2]

Alan,
IMO its either a bug or a feature that's going to be difficult to explain to users.
George

On Sat, Oct 1, 2011 at 11:54 AM, Alan Sampson <[hidden email]> wrote:

George,

On 1 October 2011 05:50, George Hovey <[hidden email]> wrote:

Alan,
The only single argument form of write defined in BufferedWriter is write(int), although it inherits write(String) and write(int) from Writer.  Could this be a clue?
George

Yes!  That's a huge clue.  Downcasting filebuff to a Writer generates a working program:

/* NetRexx */

options replace format comments java crossref savelog symbols binary

players = [String -

    'Stephen Harper:Goal' -

  , 'Fabricio Coloccini:Def' -

]

filename = 'TxFileIO001N.txt'

fileobj  = File(filename)

filebuff = BufferedWriter(FileWriter(fileobj))

loop r_ = 0 to players.length - 1

  rec = String(players[r_])

  say rec

  (Writer filebuff).write(rec)

  filebuff.newLine

  end r_

filebuff.close

return

but I don't think I should need to.  As you observe BufferedWriter is a Writer so NetRexx should be choosing the correct method without the downcast.  That's why I asked if this is a bug.

Alan.

--
Can't tweet, won't tweet!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Kermit Kiser]

Although I sort of understand Mike's reasoning, I agree with you guys. This one bites me often and always offends my principle of least astonishment. I think more people would expect the translator to prefer a matching method, regardless of inheritance, over performing a type conversion. At least enter a problem issue so we can look into it more.

http://kenai.com/jira/browse/NETREXX

-- Kermit


On 10/1/2011 10:21 AM, George Hovey wrote:

Alan,
IMO its either a bug or a feature that's going to be difficult to explain to users.
George

On Sat, Oct 1, 2011 at 11:54 AM, Alan Sampson <[hidden email]> wrote:

George,

On 1 October 2011 05:50, George Hovey <[hidden email]> wrote:

Alan,
The only single argument form of write defined in BufferedWriter is write(int), although it inherits write(String) and write(int) from Writer.  Could this be a clue?
George

Yes!  That's a huge clue.  Downcasting filebuff to a Writer generates a working program:

/* NetRexx */

options replace format comments java crossref savelog symbols binary

players = [String -

    'Stephen Harper:Goal' -

  , 'Fabricio Coloccini:Def' -

]

filename = 'TxFileIO001N.txt'

fileobj  = File(filename)

filebuff = BufferedWriter(FileWriter(fileobj))

loop r_ = 0 to players.length - 1

  rec = String(players[r_])

  say rec

  (Writer filebuff).write(rec)

  filebuff.newLine

  end r_

filebuff.close

return

but I don't think I should need to.  As you observe BufferedWriter is a Writer so NetRexx should be choosing the correct method without the downcast.  That's why I asked if this is a bug.

Alan.

--
Can't tweet, won't tweet!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ThSITC]

Then I have been totally wrong (replied by brain)

But, when you have on the line, suggest that you simply start to use
the documented linein/lineout etc methods of my RexxFile implementation, which do exactly work as in classic Rexx?

... And I'm sorry hwen I did raise any confusion.

Obviously, I'm using some other (classic Rexx compliant) methods of programming than many of you :-(

Thomas.
======================================================
Am 01.10.2011 17:45, schrieb Alan Sampson:

Thomas,

On 30 September 2011 22:18, Thomas Schneider <[hidden email]> wrote:

Hello Alan,

   I think coding:

       int irc
      
       ...
       irc=filebuff.write(rec)

   should avoid the pitfall.

The Writer.write() family of methods are void functions; they don't provide any return values.  Your suggestion would never compile.

Alan.

--
Can't tweet, won't tweet!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Mike Cowlishaw]

 

 

Although I sort of understand Mike's reasoning, I agree with you guys. This one bites me often and always offends my principle of least astonishment. I think more people would expect the translator to prefer a matching method, regardless of inheritance, over performing a type conversion. At least enter a problem issue so we can look into it more.

http://kenai.com/jira/browse/NETREXX

Definitely not claiming I got that one right :-).   And definitely worth another look at the costing algorithm(s) for many reasons.  They were/are fairly arbitrary and hindsight is a powerful thing.  Be careful not to break existing programs, though ...

 

MIke   

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Kermit Kiser]

Alan -

I am not sure if you are on the project (Kenai) mailing lists, so ignore this if you have already seen it.

There is now a potential fix for this problem on the after3.01 branch of the repository. If you have time to test it with your code, the binary for the updated translator can be downloaded from here:

http://kenai.com/projects/netrexx-plus/downloads

-- Kermit


On 10/1/2011 8:54 AM, Alan Sampson wrote:

George,

On 1 October 2011 05:50, George Hovey <[hidden email]> wrote:

Alan,
The only single argument form of write defined in BufferedWriter is write(int), although it inherits write(String) and write(int) from Writer.  Could this be a clue?
George

Yes!  That's a huge clue.  Downcasting filebuff to a Writer generates a working program:

/* NetRexx */

options replace format comments java crossref savelog symbols binary

players = [String -

    'Stephen Harper:Goal' -

  , 'Fabricio Coloccini:Def' -

]

filename = 'TxFileIO001N.txt'

fileobj  = File(filename)

filebuff = BufferedWriter(FileWriter(fileobj))

loop r_ = 0 to players.length - 1

  rec = String(players[r_])

  say rec

  (Writer filebuff).write(rec)

  filebuff.newLine

  end r_

filebuff.close

return

but I don't think I should need to.  As you observe BufferedWriter is a Writer so NetRexx should be choosing the correct method without the downcast.  That's why I asked if this is a bug.

Alan.

--
Can't tweet, won't tweet!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ThSITC]

Hello all,
   1.) Alan, Kermit, & all involved: Thank you for tracking down this issue! :-)
   2.) NetRexx does have a quite innovative way to DEFINE a TERM; as well
as the CASTING syntax. When all of you would read the RED LINE below, saying

 (Writer filebuff).write(rec)
  
you will see what I do mean. Don't know, whether a *new* NetRexx user
will come up with this *human undertandable* syntax.

I would *not* like to argue about this. The way NetRexx does it, has also many many advantages.

But the below notation is *surely* neither intuitive nor human, nor easy to understand. ... :-(

But, as I said so many times: I'm *with you*, *NOT* against you !

Thomas Schneider.

PS: My current only fault seems to be that I'm reading too many Reference
Manuals from too many Computer Programming Languages, and disseminating too many CODE Snippets (Chip, thats for you, old friend)

=========================================================
Am 04.10.2011 21:43, schrieb Kermit Kiser:

Alan -

I am not sure if you are on the project (Kenai) mailing lists, so ignore this if you have already seen it.

There is now a potential fix for this problem on the after3.01 branch of the repository. If you have time to test it with your code, the binary for the updated translator can be downloaded from here:

http://kenai.com/projects/netrexx-plus/downloads

-- Kermit


On 10/1/2011 8:54 AM, Alan Sampson wrote:

George,

On 1 October 2011 05:50, George Hovey <[hidden email]> wrote:

Alan,
The only single argument form of write defined in BufferedWriter is write(int), although it inherits write(String) and write(int) from Writer.  Could this be a clue?
George

Yes!  That's a huge clue.  Downcasting filebuff to a Writer generates a working program:

/* NetRexx */

options replace format comments java crossref savelog symbols binary

players = [String -

    'Stephen Harper:Goal' -

  , 'Fabricio Coloccini:Def' -

]

filename = 'TxFileIO001N.txt'

fileobj  = File(filename)

filebuff = BufferedWriter(FileWriter(fileobj))

loop r_ = 0 to players.length - 1

  rec = String(players[r_])

  say rec

  (Writer filebuff).write(rec)

  filebuff.newLine

  end r_

filebuff.close

return

but I don't think I should need to.  As you observe BufferedWriter is a Writer so NetRexx should be choosing the correct method without the downcast.  That's why I asked if this is a bug.

Alan.

--
Can't tweet, won't tweet!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Rony G. Flatscher (wu-wien)]

Kermit,

On 04.10.2011 21:43, Kermit Kiser wrote:

I am not sure if you are on the project (Kenai) mailing lists, so ignore this if you have already seen it.

There is now a potential fix for this problem on the after3.01 branch of the repository. If you have time to test it with your code, the binary for the updated translator can be downloaded from here:

could you hint at how you solved this problem (conceptually)?

---rony

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ThSITC]

Rony, are you a member of the KENAI NetRexx developers list ?
Thomas.
=============================================================
Am 05.10.2011 11:43, schrieb Rony G. Flatscher:

Kermit,

On 04.10.2011 21:43, Kermit Kiser wrote:

I am not sure if you are on the project (Kenai) mailing lists, so ignore this if you have already seen it.

There is now a potential fix for this problem on the after3.01 branch of the repository. If you have time to test it with your code, the binary for the updated translator can be downloaded from here:

could you hint at how you solved this problem (conceptually)?

---rony

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Kermit Kiser]

The current method selection logic is a recursive algorithm:

1) If any methods in the current class can be used, select the best fit (least cost) and use it.
2) If any methods in the superclass can be used, select the best fit using this algorithm and use it.
3) If any methods in interfaces can be used, select the best fit and use it.

The proposed logic is:

1) If any methods in the current class can be used, save the best fit and it's cost.
2) If any superclass methods can be used, save the best fit using this algorithm and it's cost.
3) If any interface methods can be used, save the best fit and it's cost.
4) Select the best fit (least cost) of the above three and use it.

Thus the new algorithm examines all possible method calls and then selects the best fit (least cost in conversions) whereas the old algorithm preferred local methods over any others, regardless of fit. Note that local methods are still preferred, but ONLY if they fit as well as inherited methods.

-- KK

On 10/5/2011 2:43 AM, Rony G. Flatscher wrote:

Kermit,

On 04.10.2011 21:43, Kermit Kiser wrote:

I am not sure if you are on the project (Kenai) mailing lists, so ignore this if you have already seen it.

There is now a potential fix for this problem on the after3.01 branch of the repository. If you have time to test it with your code, the binary for the updated translator can be downloaded from here:

could you hint at how you solved this problem (conceptually)?

---rony

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Rony G. Flatscher (wu-wien)]

On 05.10.2011 17:51, Kermit Kiser wrote:

The current method selection logic is a recursive algorithm:

1) If any methods in the current class can be used, select the best fit (least cost) and use it.
2) If any methods in the superclass can be used, select the best fit using this algorithm and use it.
3) If any methods in interfaces can be used, select the best fit and use it.

The proposed logic is:

1) If any methods in the current class can be used, save the best fit and it's cost.
2) If any superclass methods can be used, save the best fit using this algorithm and it's cost.
3) If any interface methods can be used, save the best fit and it's cost.
4) Select the best fit (least cost) of the above three and use it.

Thus the new algorithm examines all possible method calls and then selects the best fit (least cost in conversions) whereas the old algorithm preferred local methods over any others, regardless of fit. Note that local methods are still preferred, but ONLY if they fit as well as inherited methods.

Thank you for this description!

This change would replace the defined method resolution order (in NetRexx 2, p. 54) in the post NetRexx 3.01 implementation.

As the new algorithms change the current method resolution order one question would be, how it will affect existing (old) NetRexx projects that get changed and recompiled with the new algorithms. It is likely, that some of these recompilations might pick a different method than is currently the case, if a method in a superclass is "cheaper" in terms of coercion. The behaviour of such projects may as a result change (maybe slightly, which would be even more "dangerous" as one might overlook this).

The original problem Alan found with the current method resolution should be fixable by informing NetRexx to use a method in the super class of BufferedWriter instead, e.g. like

(Writer filebuff).write(rec)

which will create the following (expected) Java code:

(java.io.Writer)filebuff).write(rec);
  

Having read the current method resolution rules makes it clear that the above is indeed the solution. Alan's surprise about the method resolution has probably to do with him not being acquainted in the method resolution rules at that particular point in time and his observation, that a hand-written Java program would indeed pick the "write(java.lang.String)" method in the java.io.Writer class: this is to be expected, as Java is not behaving the same as NetRexx as it follows different lookup-rules. Or with other words: because the NetRexx translation does ad-hoc-conversions using the Rexx datatype to use a Java method in the current class first, one cannot compare (or expect) the same behaviour between the Java compiler and the NetRexx translator!

The NetRexx translator works in Alan's case according to the NetRexx specifications and Alan's surprise (and probably of many savvy Java programmers) has nothing to do with a shortcoming (or error for that matter) of NetRexx. It is just a different behaviour that was intentionally laid out the way it is.

---

So one question would be, whether the new method resolution algorithm should replace the 15 year old method resolution algorithm that has been explicitly documented and applied to numerous NetRexx applications?

One aspect would be whether existing NetRexx programs would break? In the case they need re-translation this seems to be possible!

Another aspect would be whether the new algorithms would always pick the method the programmer expects to be picked? This can probably be doubted. E.g. consider some method xyz(int) in the superclass SC and a method xyz(long) in the current class CC, which extends SC. With the new algorithm, probably the superclass' method SC.xyz(int) would be picked (if the costs of creating an int are cheaper than the costs of creating a long) if the Rexx value was something like "23", whereas the current algorithm would pick CC.xyz(long) in the current class.

Mostlikely NetRexx coders might be surprised by this new behaviour (where not the method in the current class is used/preferred but some method in some superclass instead), if they are not clearly aware of the cost-based algorithm in addition to the method resolution algorithm. (It has to be expected that NetRexx programmers over time forget about the details of the method resolution and cost calculation algorithms. This is probably the reason why Alan and others were surprised about his example as hardly anyone would be always aware of the method resolution algorithms in place.)

---

Having read the current NetRexx specifications about method resolution I would see nothing wrong in NetRexx' behaviour (even though I was surprised myself when I saw Alan's example and scratched my head and had to turn to the NetRexx specifications)!

So another question that arises for me: is this manifested surprise something that is common among the NetRexx programmers or a very rare observation because of runtime errors thrown that do not match the expectations of the coder? If it is a rare phenomenon, then I would rather point to the method resolution algorithm in place and documented in the NetRexx Language book, as a wrong expectation is a probably a user error!

---rony

P.S.: Part of the (expectation) problem may be that knowing there is a cost-based algorithm that helps resolve a method might wrongly lead to the conclusion that NetRexx will always be able to pick the "correct" (i.e. expected) method. That would be an impossible expectation: at translation time the NetRexx translator can only work with assumptions, i.e. trying to guess the best method. If the assumptions do not match the programmer's the "Alan-phenomenon" ;) occurs.

P.P.S.: One could think to solve the problem in a backwardly compatible manner by doing something like BSF4ooRexx: if it is possible that multiple methods could be picked, then let the NetRexx translator do the following:

• use the current method resolution algorithm to pick the method to use, but enclose it into a try block,
• create a catch block in which an algorithm anaylses the Rexx value at hand on the one side and all methods having the same number of argumetns; then try to convert the Rexx value to the argument types until one method is found where no illegal conversion exception is throwin and use that; if no such method can be found even after searching all superclasses then rethrow the original exception.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[alansam]

Rony,

While I agree with many of your thoughts I do take issue with the idea that NetRexx should coerce (as happened in my case) a java.lang.String object into a lang.netrexx.Rexx object and then apply that object's toInt() method to the contents just so it could force a call to java.io.BufferedWriter.write(int), particularly as this was inside a "binary" method in a "binary" class.  Perhaps that's where the distinction should be drawn; if the translator is working with a Rexx object and/or "nobinary" is in effect then the old algorithm could be employed, if casting and/or "binary" is specified then it should employ the new scheme.  Having gone to the trouble of casting the datatype and specifying that I wanted more control over the code, I expected the compiler to respect my request.  At some point the compiler should respect the programmer's wishes.

Alan.

On 6 October 2011 12:05, Rony G. Flatscher <[hidden email]> wrote:

On 05.10.2011 17:51, Kermit Kiser wrote:

The current method selection logic is a recursive algorithm:

1) If any methods in the current class can be used, select the best fit (least cost) and use it.
2) If any methods in the superclass can be used, select the best fit using this algorithm and use it.
3) If any methods in interfaces can be used, select the best fit and use it.

The proposed logic is:

1) If any methods in the current class can be used, save the best fit and it's cost.
2) If any superclass methods can be used, save the best fit using this algorithm and it's cost.
3) If any interface methods can be used, save the best fit and it's cost.
4) Select the best fit (least cost) of the above three and use it.

Thus the new algorithm examines all possible method calls and then selects the best fit (least cost in conversions) whereas the old algorithm preferred local methods over any others, regardless of fit. Note that local methods are still preferred, but ONLY if they fit as well as inherited methods.

Thank you for this description!

This change would replace the defined method resolution order (in NetRexx 2, p. 54) in the post NetRexx 3.01 implementation.

As the new algorithms change the current method resolution order one question would be, how it will affect existing (old) NetRexx projects that get changed and recompiled with the new algorithms. It is likely, that some of these recompilations might pick a different method than is currently the case, if a method in a superclass is "cheaper" in terms of coercion. The behaviour of such projects may as a result change (maybe slightly, which would be even more "dangerous" as one might overlook this).

The original problem Alan found with the current method resolution should be fixable by informing NetRexx to use a method in the super class of BufferedWriter instead, e.g. like

(Writer filebuff).write(rec)

which will create the following (expected) Java code:

(java.io.Writer)filebuff).write(rec);
  

Having read the current method resolution rules makes it clear that the above is indeed the solution. Alan's surprise about the method resolution has probably to do with him not being acquainted in the method resolution rules at that particular point in time and his observation, that a hand-written Java program would indeed pick the "write(java.lang.String)" method in the java.io.Writer class: this is to be expected, as Java is not behaving the same as NetRexx as it follows different lookup-rules. Or with other words: because the NetRexx translation does ad-hoc-conversions using the Rexx datatype to use a Java method in the current class first, one cannot compare (or expect) the same behaviour between the Java compiler and the NetRexx translator!

The NetRexx translator works in Alan's case according to the NetRexx specifications and Alan's surprise (and probably of many savvy Java programmers) has nothing to do with a shortcoming (or error for that matter) of NetRexx. It is just a different behaviour that was intentionally laid out the way it is.

---

So one question would be, whether the new method resolution algorithm should replace the 15 year old method resolution algorithm that has been explicitly documented and applied to numerous NetRexx applications?

One aspect would be whether existing NetRexx programs would break? In the case they need re-translation this seems to be possible!

Another aspect would be whether the new algorithms would always pick the method the programmer expects to be picked? This can probably be doubted. E.g. consider some method xyz(int) in the superclass SC and a method xyz(long) in the current class CC, which extends SC. With the new algorithm, probably the superclass' method SC.xyz(int) would be picked (if the costs of creating an int are cheaper than the costs of creating a long) if the Rexx value was something like "23", whereas the current algorithm would pick CC.xyz(long) in the current class.

Mostlikely NetRexx coders might be surprised by this new behaviour (where not the method in the current class is used/preferred but some method in some superclass instead), if they are not clearly aware of the cost-based algorithm in addition to the method resolution algorithm. (It has to be expected that NetRexx programmers over time forget about the details of the method resolution and cost calculation algorithms. This is probably the reason why Alan and others were surprised about his example as hardly anyone would be always aware of the method resolution algorithms in place.)

---

Having read the current NetRexx specifications about method resolution I would see nothing wrong in NetRexx' behaviour (even though I was surprised myself when I saw Alan's example and scratched my head and had to turn to the NetRexx specifications)!

So another question that arises for me: is this manifested surprise something that is common among the NetRexx programmers or a very rare observation because of runtime errors thrown that do not match the expectations of the coder? If it is a rare phenomenon, then I would rather point to the method resolution algorithm in place and documented in the NetRexx Language book, as a wrong expectation is a probably a user error!

---rony

P.S.: Part of the (expectation) problem may be that knowing there is a cost-based algorithm that helps resolve a method might wrongly lead to the conclusion that NetRexx will always be able to pick the "correct" (i.e. expected) method. That would be an impossible expectation: at translation time the NetRexx translator can only work with assumptions, i.e. trying to guess the best method. If the assumptions do not match the programmer's the "Alan-phenomenon" ;) occurs.

P.P.S.: One could think to solve the problem in a backwardly compatible manner by doing something like BSF4ooRexx: if it is possible that multiple methods could be picked, then let the NetRexx translator do the following:

• use the current method resolution algorithm to pick the method to use, but enclose it into a try block,
• create a catch block in which an algorithm anaylses the Rexx value at hand on the one side and all methods having the same number of argumetns; then try to convert the Rexx value to the argument types until one method is found where no illegal conversion exception is throwin and use that; if no such method can be found even after searching all superclasses then rethrow the original exception.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

--
Can't tweet, won't tweet!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/