rails-devel — List for discussion of Rails development

Re: [Rails-devel] delurking with a quick ReportWindow fix

[brett l. <wak...@gm...>]

On Sat, Nov 22, 2008 at 1:49 AM, Jonathan Ferro
<jon...@ya...> wrote:
>> It took me some trouble to apply these patches (I must add immediately that
>
>> I have never worked with diff patches before).
>
> The most recent information that I had is that "unified diff" was still the preferred format for beginning contributions.  If that should be changed, just let me know.
>
> I don't see how to save the contents of an Eclipse "source compare" view in any meaningful way.  I must add that whenever a non-coding task can be performed in Cygwin/Emacs instead of Eclipse, I almost always do so. :-)
>
> -- Jonathan
>
>

I prefer unified diffs.  Not only are there a bunch of tools built
around using them, it is a very readable format for sending them in
e-mail and being able to comment on them.


---Brett.

Re: [Rails-devel] delurking with a quick ReportWindow fix

[Jonathan F. <jon...@ya...>]

> It took me some trouble to apply these patches (I must add immediately that

> I have never worked with diff patches before).

The most recent information that I had is that "unified diff" was still the preferred format for beginning contributions.  If that should be changed, just let me know.

I don't see how to save the contents of an Eclipse "source compare" view in any meaningful way.  I must add that whenever a non-coding task can be performed in Cygwin/Emacs instead of Eclipse, I almost always do so. :-)

-- Jonathan

Re: [Rails-devel] delurking with a quick ReportWindow fix

[John A. T. <ja...@ja...>]

On Fri, 21 Nov 2008, Erik Vos wrote:

> Hmm, unfortunately I'm one of those poor guys still stuck with Windows.

Patch is avaialble for windows, plus you can use Tortoise to apply 
patches.

--
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                 		 		Smyrna, GA  30082-3723

Re: [Rails-devel] delurking with a quick ReportWindow fix

[Erik V. <eri...@hc...>]

Hmm, unfortunately I'm one of those poor guys still stuck with Windows. 

> -----Original Message-----
> From: wak...@gm... [mailto:wak...@gm...] 
> Sent: Friday 21 November 2008 22:00
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] delurking with a quick ReportWindow fix
> 
> It's easier to work with diffs outside of Eclipse. I 
> generally apply patches with the linux patch command and then 
> have Eclipse reload its code view.
> 
> ---Brett
> 
> 
> Sent via BlackBerry from T-Mobile
> 
> -----Original Message-----
> From: "Erik Vos" <eri...@hc...>
> 
> Date: Fri, 21 Nov 2008 21:50:34 
> To: 'Development list for Rails: an 18xx 
> game'<rai...@li...>
> Subject: Re: [Rails-devel] delurking with a quick ReportWindow fix
> 
> 
> OK, I have picked up and committed these changes.
> 
> One comment:
> 
> It took me some trouble to apply these patches (I must add 
> immediately that
> I have never worked with diff patches before). On lines like
> --- 18xx.orig/rails/ui/swing/GameUIManager.java 2008-06-30
> 13:35:29.000000000 -0700
> it seems that Eclipse considers the date/time stuff as a part of the
> filename; I had to remove that.
> And the "orig" part I had to remove as well.
> 
> Otherwise, thanks.
> Erik.
> 
> > -----Original Message-----
> > From: Jonathan Ferro [mailto:jon...@ya...] 
> > Sent: Wednesday 19 November 2008 23:50
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] delurking with a quick ReportWindow fix
> > 
> > > If you know a better way than a JLabel to achieve the same 
> > effect, I'd like
> > 
> > > to know it. This was the only way I could manage it.
> > 
> > OK, done (appended) and it was much easier than I thought.  
> > In the process I destaticified some things, which felt like 
> > the right thing to do but please check it over.
> > 
> > > I think a separate and well-readable window report is 
> > needed for various
> > > reasons, not the least one being that, certainly in 
> > internet play, players
> > > would like to see a written account of the game actions, 
> > not cluttered by
> > > other log info. 
> > > The format is like game reports I have seen published on 
> > the Internet, and
> > > indeed intended to be suitable for saving, emailing (PBEM), 
> > publishing etc.
> > 
> > I think a next step might be to have the "game report" be 
> > separated from other debug logging by having it be completely 
> > regenerable from the same game history that undo uses.  I've 
> > lost track--does the undo trail now include the entire game, 
> > or are there still unundoable actions that cause it to be truncated?
> > 
> > -- Jonathan
> > 
> > diff -r -x CVS -u --strip-trailing-cr 
> > 18xx.orig/rails/ui/swing/GameUIManager.java 
> > 18xx/rails/ui/swing/GameUIManager.java
> > --- 18xx.orig/rails/ui/swing/GameUIManager.java 2008-06-30 
> > 13:35:29.000000000 -0700
> > +++ 18xx/rails/ui/swing/GameUIManager.java      2008-11-19 
> > 13:52:56.640625000 -0800
> > @@ -124,7 +124,7 @@
> >          log.debug("==Result from server: " + result);
> >          activeWindow.displayServerMessage();
> >  
> > -        ReportWindow.addLog();
> > +        reportWindow.addLog();
> >  
> >          // End of game checks
> >          if (gameManager.isGameOver()) {
> > diff -r -x CVS -u --strip-trailing-cr 
> > 18xx.orig/rails/ui/swing/ORUIManager.java 
> > 18xx/rails/ui/swing/ORUIManager.java
> > --- 18xx.orig/rails/ui/swing/ORUIManager.java   2008-10-12 
> > 07:36:44.000000000 -0700
> > +++ 18xx/rails/ui/swing/ORUIManager.java        2008-11-19 
> > 13:54:08.859375000 -0800
> > @@ -350,7 +350,7 @@
> >              displayRemainingTiles();
> >          }
> >  
> > -        ReportWindow.addLog();
> > +        gameUIManager.reportWindow.addLog();
> >      }
> >  
> >      /** Stub, can be overridden in subclasses */
> > diff -r -x CVS -u --strip-trailing-cr 
> > 18xx.orig/rails/ui/swing/ORWindow.java 
> > 18xx/rails/ui/swing/ORWindow.java
> > --- 18xx.orig/rails/ui/swing/ORWindow.java      2008-06-30 
> > 13:35:29.000000000 -0700
> > +++ 18xx/rails/ui/swing/ORWindow.java   2008-11-19 
> > 13:54:20.078125000 -0800
> > @@ -77,7 +77,7 @@
> >          setSize(800, 600);
> >          addWindowListener(this);
> >  
> > -        ReportWindow.addLog();
> > +        gameUIManager.reportWindow.addLog();
> >      }
> >  
> >      public ORUIManager getORUIManager() {
> > diff -r -x CVS -u --strip-trailing-cr 
> > 18xx.orig/rails/ui/swing/ReportWindow.java 
> > 18xx/rails/ui/swing/ReportWindow.java
> > --- 18xx.orig/rails/ui/swing/ReportWindow.java  2008-11-18 
> > 14:12:50.000000000 -0800
> > +++ 18xx/rails/ui/swing/ReportWindow.java       2008-11-19 
> > 13:57:43.781250000 -0800
> > @@ -15,29 +15,28 @@
> >  public class ReportWindow extends JFrame implements 
> > WindowListener, KeyListener {
> >  
> >      private static final long serialVersionUID = 1L;
> > -    private JLabel message;
> > +    private JTextArea message;
> >      private JScrollPane messageScroller;
> >      private JScrollBar vbar;
> >      private JPanel messagePanel;
> > -    private static ReportWindow messageWindow;
> > +    private ReportWindow messageWindow;
> >      private GameManager gameManager;
> >  
> > -    private static StringBuffer buffer = new 
> > StringBuffer("<html></html>");
> > -
> >      public ReportWindow(GameManager gameManager) {
> >          messageWindow = this;
> >          this.gameManager = gameManager;
> >  
> > -        message = new JLabel("");
> > +        message = new JTextArea();
> > +        message.setEditable(false);
> > +        message.setLineWrap(false);
> >          message.setBackground(Color.WHITE);
> >          message.setOpaque(true);
> > -        message.setVerticalAlignment(SwingConstants.TOP);
> >          message.setBorder(BorderFactory.createEmptyBorder(5, 
> > 5, 5, 5));
> >  
> >          messagePanel = new JPanel(new GridBagLayout());
> >          messageScroller =
> >                  new JScrollPane(message,
> > -                        
> > ScrollPaneConstants.VERTICAL_SCROLLBAR_AS_NEEDED,
> > +                        
> > ScrollPaneConstants.VERTICAL_SCROLLBAR_ALWAYS,
> >                          
> > ScrollPaneConstants.HORIZONTAL_SCROLLBAR_AS_NEEDED);
> >          vbar = messageScroller.getVerticalScrollBar();
> >          GridBagConstraints gbc = new GridBagConstraints();
> > @@ -55,12 +54,10 @@
> >  
> >      }
> >  
> > -    public static void addLog() {
> > +    public void addLog() {
> >          String newText = ReportBuffer.get();
> >          if (newText.length() > 0) {
> > -            buffer.insert(buffer.length() - 7, 
> > newText.replaceAll("\n", "<br>"));
> > -
> > -            messageWindow.message.setText(buffer.toString());
> > +            message.append(newText);
> >              SwingUtilities.invokeLater(new Runnable() {
> >                  public void run() {
> >                      
> > messageWindow.vbar.setValue(messageWindow.vbar.getMaximum());
> > 
> > 
> > --------------------------------------------------------------
> > -----------
> > This SF.Net email is sponsored by the Moblin Your Move 
> > Developer's challenge
> > Build the coolest Linux based applications with Moblin SDK & 
> > win great prizes
> > Grand prize is a trip for two to an Open Source event 
> > anywhere in the world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > 
> 
> 
> --------------------------------------------------------------
> -----------
> This SF.Net email is sponsored by the Moblin Your Move 
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & 
> win great prizes
> Grand prize is a trip for two to an Open Source event 
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> --------------------------------------------------------------
> -----------
> This SF.Net email is sponsored by the Moblin Your Move 
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & 
> win great prizes
> Grand prize is a trip for two to an Open Source event 
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 

Re: [Rails-devel] delurking with a quick ReportWindow fix

[<wak...@gm...>]

It's easier to work with diffs outside of Eclipse. I generally apply patches with the linux patch command and then have Eclipse reload its code view.

---Brett


Sent via BlackBerry from T-Mobile

-----Original Message-----
From: "Erik Vos" <eri...@hc...>

Date: Fri, 21 Nov 2008 21:50:34 
To: 'Development list for Rails: an 18xx game'<rai...@li...>
Subject: Re: [Rails-devel] delurking with a quick ReportWindow fix


OK, I have picked up and committed these changes.

One comment:

It took me some trouble to apply these patches (I must add immediately that
I have never worked with diff patches before). On lines like
--- 18xx.orig/rails/ui/swing/GameUIManager.java 2008-06-30
13:35:29.000000000 -0700
it seems that Eclipse considers the date/time stuff as a part of the
filename; I had to remove that.
And the "orig" part I had to remove as well.

Otherwise, thanks.
Erik.

> -----Original Message-----
> From: Jonathan Ferro [mailto:jon...@ya...] 
> Sent: Wednesday 19 November 2008 23:50
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] delurking with a quick ReportWindow fix
> 
> > If you know a better way than a JLabel to achieve the same 
> effect, I'd like
> 
> > to know it. This was the only way I could manage it.
> 
> OK, done (appended) and it was much easier than I thought.  
> In the process I destaticified some things, which felt like 
> the right thing to do but please check it over.
> 
> > I think a separate and well-readable window report is 
> needed for various
> > reasons, not the least one being that, certainly in 
> internet play, players
> > would like to see a written account of the game actions, 
> not cluttered by
> > other log info. 
> > The format is like game reports I have seen published on 
> the Internet, and
> > indeed intended to be suitable for saving, emailing (PBEM), 
> publishing etc.
> 
> I think a next step might be to have the "game report" be 
> separated from other debug logging by having it be completely 
> regenerable from the same game history that undo uses.  I've 
> lost track--does the undo trail now include the entire game, 
> or are there still unundoable actions that cause it to be truncated?
> 
> -- Jonathan
> 
> diff -r -x CVS -u --strip-trailing-cr 
> 18xx.orig/rails/ui/swing/GameUIManager.java 
> 18xx/rails/ui/swing/GameUIManager.java
> --- 18xx.orig/rails/ui/swing/GameUIManager.java 2008-06-30 
> 13:35:29.000000000 -0700
> +++ 18xx/rails/ui/swing/GameUIManager.java      2008-11-19 
> 13:52:56.640625000 -0800
> @@ -124,7 +124,7 @@
>          log.debug("==Result from server: " + result);
>          activeWindow.displayServerMessage();
>  
> -        ReportWindow.addLog();
> +        reportWindow.addLog();
>  
>          // End of game checks
>          if (gameManager.isGameOver()) {
> diff -r -x CVS -u --strip-trailing-cr 
> 18xx.orig/rails/ui/swing/ORUIManager.java 
> 18xx/rails/ui/swing/ORUIManager.java
> --- 18xx.orig/rails/ui/swing/ORUIManager.java   2008-10-12 
> 07:36:44.000000000 -0700
> +++ 18xx/rails/ui/swing/ORUIManager.java        2008-11-19 
> 13:54:08.859375000 -0800
> @@ -350,7 +350,7 @@
>              displayRemainingTiles();
>          }
>  
> -        ReportWindow.addLog();
> +        gameUIManager.reportWindow.addLog();
>      }
>  
>      /** Stub, can be overridden in subclasses */
> diff -r -x CVS -u --strip-trailing-cr 
> 18xx.orig/rails/ui/swing/ORWindow.java 
> 18xx/rails/ui/swing/ORWindow.java
> --- 18xx.orig/rails/ui/swing/ORWindow.java      2008-06-30 
> 13:35:29.000000000 -0700
> +++ 18xx/rails/ui/swing/ORWindow.java   2008-11-19 
> 13:54:20.078125000 -0800
> @@ -77,7 +77,7 @@
>          setSize(800, 600);
>          addWindowListener(this);
>  
> -        ReportWindow.addLog();
> +        gameUIManager.reportWindow.addLog();
>      }
>  
>      public ORUIManager getORUIManager() {
> diff -r -x CVS -u --strip-trailing-cr 
> 18xx.orig/rails/ui/swing/ReportWindow.java 
> 18xx/rails/ui/swing/ReportWindow.java
> --- 18xx.orig/rails/ui/swing/ReportWindow.java  2008-11-18 
> 14:12:50.000000000 -0800
> +++ 18xx/rails/ui/swing/ReportWindow.java       2008-11-19 
> 13:57:43.781250000 -0800
> @@ -15,29 +15,28 @@
>  public class ReportWindow extends JFrame implements 
> WindowListener, KeyListener {
>  
>      private static final long serialVersionUID = 1L;
> -    private JLabel message;
> +    private JTextArea message;
>      private JScrollPane messageScroller;
>      private JScrollBar vbar;
>      private JPanel messagePanel;
> -    private static ReportWindow messageWindow;
> +    private ReportWindow messageWindow;
>      private GameManager gameManager;
>  
> -    private static StringBuffer buffer = new 
> StringBuffer("<html></html>");
> -
>      public ReportWindow(GameManager gameManager) {
>          messageWindow = this;
>          this.gameManager = gameManager;
>  
> -        message = new JLabel("");
> +        message = new JTextArea();
> +        message.setEditable(false);
> +        message.setLineWrap(false);
>          message.setBackground(Color.WHITE);
>          message.setOpaque(true);
> -        message.setVerticalAlignment(SwingConstants.TOP);
>          message.setBorder(BorderFactory.createEmptyBorder(5, 
> 5, 5, 5));
>  
>          messagePanel = new JPanel(new GridBagLayout());
>          messageScroller =
>                  new JScrollPane(message,
> -                        
> ScrollPaneConstants.VERTICAL_SCROLLBAR_AS_NEEDED,
> +                        
> ScrollPaneConstants.VERTICAL_SCROLLBAR_ALWAYS,
>                          
> ScrollPaneConstants.HORIZONTAL_SCROLLBAR_AS_NEEDED);
>          vbar = messageScroller.getVerticalScrollBar();
>          GridBagConstraints gbc = new GridBagConstraints();
> @@ -55,12 +54,10 @@
>  
>      }
>  
> -    public static void addLog() {
> +    public void addLog() {
>          String newText = ReportBuffer.get();
>          if (newText.length() > 0) {
> -            buffer.insert(buffer.length() - 7, 
> newText.replaceAll("\n", "<br>"));
> -
> -            messageWindow.message.setText(buffer.toString());
> +            message.append(newText);
>              SwingUtilities.invokeLater(new Runnable() {
>                  public void run() {
>                      
> messageWindow.vbar.setValue(messageWindow.vbar.getMaximum());
> 
> 
> --------------------------------------------------------------
> -----------
> This SF.Net email is sponsored by the Moblin Your Move 
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & 
> win great prizes
> Grand prize is a trip for two to an Open Source event 
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] delurking with a quick ReportWindow fix

[John A. T. <jat...@ja...>]

On Fri, 21 Nov 2008, Erik Vos wrote:

> It took me some trouble to apply these patches (I must add immediately that
> I have never worked with diff patches before). On lines like
> --- 18xx.orig/rails/ui/swing/GameUIManager.java 2008-06-30
> 13:35:29.000000000 -0700
> it seems that Eclipse considers the date/time stuff as a part of the
> filename; I had to remove that.
> And the "orig" part I had to remove as well.

You should just be able to run patch -p1 <patchfile to apply the diffs -- 
-p1 tells it to strip off 1 path component, which in this case would be 
18xx, so you should be in the top of your working copy.

--
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                 		 		Smyrna, GA  30082-3723

Re: [Rails-devel] delurking with a quick ReportWindow fix

[Erik V. <eri...@hc...>]

OK, I have picked up and committed these changes.

One comment:

It took me some trouble to apply these patches (I must add immediately that
I have never worked with diff patches before). On lines like
--- 18xx.orig/rails/ui/swing/GameUIManager.java 2008-06-30
13:35:29.000000000 -0700
it seems that Eclipse considers the date/time stuff as a part of the
filename; I had to remove that.
And the "orig" part I had to remove as well.

Otherwise, thanks.
Erik.

> -----Original Message-----
> From: Jonathan Ferro [mailto:jon...@ya...] 
> Sent: Wednesday 19 November 2008 23:50
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] delurking with a quick ReportWindow fix
> 
> > If you know a better way than a JLabel to achieve the same 
> effect, I'd like
> 
> > to know it. This was the only way I could manage it.
> 
> OK, done (appended) and it was much easier than I thought.  
> In the process I destaticified some things, which felt like 
> the right thing to do but please check it over.
> 
> > I think a separate and well-readable window report is 
> needed for various
> > reasons, not the least one being that, certainly in 
> internet play, players
> > would like to see a written account of the game actions, 
> not cluttered by
> > other log info. 
> > The format is like game reports I have seen published on 
> the Internet, and
> > indeed intended to be suitable for saving, emailing (PBEM), 
> publishing etc.
> 
> I think a next step might be to have the "game report" be 
> separated from other debug logging by having it be completely 
> regenerable from the same game history that undo uses.  I've 
> lost track--does the undo trail now include the entire game, 
> or are there still unundoable actions that cause it to be truncated?
> 
> -- Jonathan
> 
> diff -r -x CVS -u --strip-trailing-cr 
> 18xx.orig/rails/ui/swing/GameUIManager.java 
> 18xx/rails/ui/swing/GameUIManager.java
> --- 18xx.orig/rails/ui/swing/GameUIManager.java 2008-06-30 
> 13:35:29.000000000 -0700
> +++ 18xx/rails/ui/swing/GameUIManager.java      2008-11-19 
> 13:52:56.640625000 -0800
> @@ -124,7 +124,7 @@
>          log.debug("==Result from server: " + result);
>          activeWindow.displayServerMessage();
>  
> -        ReportWindow.addLog();
> +        reportWindow.addLog();
>  
>          // End of game checks
>          if (gameManager.isGameOver()) {
> diff -r -x CVS -u --strip-trailing-cr 
> 18xx.orig/rails/ui/swing/ORUIManager.java 
> 18xx/rails/ui/swing/ORUIManager.java
> --- 18xx.orig/rails/ui/swing/ORUIManager.java   2008-10-12 
> 07:36:44.000000000 -0700
> +++ 18xx/rails/ui/swing/ORUIManager.java        2008-11-19 
> 13:54:08.859375000 -0800
> @@ -350,7 +350,7 @@
>              displayRemainingTiles();
>          }
>  
> -        ReportWindow.addLog();
> +        gameUIManager.reportWindow.addLog();
>      }
>  
>      /** Stub, can be overridden in subclasses */
> diff -r -x CVS -u --strip-trailing-cr 
> 18xx.orig/rails/ui/swing/ORWindow.java 
> 18xx/rails/ui/swing/ORWindow.java
> --- 18xx.orig/rails/ui/swing/ORWindow.java      2008-06-30 
> 13:35:29.000000000 -0700
> +++ 18xx/rails/ui/swing/ORWindow.java   2008-11-19 
> 13:54:20.078125000 -0800
> @@ -77,7 +77,7 @@
>          setSize(800, 600);
>          addWindowListener(this);
>  
> -        ReportWindow.addLog();
> +        gameUIManager.reportWindow.addLog();
>      }
>  
>      public ORUIManager getORUIManager() {
> diff -r -x CVS -u --strip-trailing-cr 
> 18xx.orig/rails/ui/swing/ReportWindow.java 
> 18xx/rails/ui/swing/ReportWindow.java
> --- 18xx.orig/rails/ui/swing/ReportWindow.java  2008-11-18 
> 14:12:50.000000000 -0800
> +++ 18xx/rails/ui/swing/ReportWindow.java       2008-11-19 
> 13:57:43.781250000 -0800
> @@ -15,29 +15,28 @@
>  public class ReportWindow extends JFrame implements 
> WindowListener, KeyListener {
>  
>      private static final long serialVersionUID = 1L;
> -    private JLabel message;
> +    private JTextArea message;
>      private JScrollPane messageScroller;
>      private JScrollBar vbar;
>      private JPanel messagePanel;
> -    private static ReportWindow messageWindow;
> +    private ReportWindow messageWindow;
>      private GameManager gameManager;
>  
> -    private static StringBuffer buffer = new 
> StringBuffer("<html></html>");
> -
>      public ReportWindow(GameManager gameManager) {
>          messageWindow = this;
>          this.gameManager = gameManager;
>  
> -        message = new JLabel("");
> +        message = new JTextArea();
> +        message.setEditable(false);
> +        message.setLineWrap(false);
>          message.setBackground(Color.WHITE);
>          message.setOpaque(true);
> -        message.setVerticalAlignment(SwingConstants.TOP);
>          message.setBorder(BorderFactory.createEmptyBorder(5, 
> 5, 5, 5));
>  
>          messagePanel = new JPanel(new GridBagLayout());
>          messageScroller =
>                  new JScrollPane(message,
> -                        
> ScrollPaneConstants.VERTICAL_SCROLLBAR_AS_NEEDED,
> +                        
> ScrollPaneConstants.VERTICAL_SCROLLBAR_ALWAYS,
>                          
> ScrollPaneConstants.HORIZONTAL_SCROLLBAR_AS_NEEDED);
>          vbar = messageScroller.getVerticalScrollBar();
>          GridBagConstraints gbc = new GridBagConstraints();
> @@ -55,12 +54,10 @@
>  
>      }
>  
> -    public static void addLog() {
> +    public void addLog() {
>          String newText = ReportBuffer.get();
>          if (newText.length() > 0) {
> -            buffer.insert(buffer.length() - 7, 
> newText.replaceAll("\n", "<br>"));
> -
> -            messageWindow.message.setText(buffer.toString());
> +            message.append(newText);
>              SwingUtilities.invokeLater(new Runnable() {
>                  public void run() {
>                      
> messageWindow.vbar.setValue(messageWindow.vbar.getMaximum());
> 
> 
> --------------------------------------------------------------
> -----------
> This SF.Net email is sponsored by the Moblin Your Move 
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & 
> win great prizes
> Grand prize is a trip for two to an Open Source event 
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 

[Rails-devel] 1856 Capitalisation

[Erik V. <eri...@hc...>]

I have committed changes for the 1856 Capitalisation rules and related
subjects such as destination reaching (which is temporarily a "Special" menu
action). The share buying execution code has been moved from Portfolio and
Player to Round and its subclasses (there was quite some duplicate and
partially unused code that I could clean up this way). This move was also
needed to allow coding the 1856 special rules in an efficient way.

The 1856 upgrade rules needed some fixes, and the phase-dependency of the
village up/downgrades has now also been implemented.

I think it all works, and I hope I haven't broken too much while doing all
this, but that always remains to be seen... 

Erik

Re: [Rails-devel] delurking with a quick ReportWindow fix

[Erik V. <eri...@hc...>]

Thanks. I'll try it out in the coming days, but on first sight the code
looks good.
I remember I had tried JTextArea before, but can't remember why I abandoned
it. We'll see.

Some answers below.

> > If you know a better way than a JLabel to achieve the same 
> effect, I'd like
> 
> > to know it. This was the only way I could manage it.
> 
> OK, done (appended) and it was much easier than I thought.  
> In the process I destaticified some things, which felt like 
> the right thing to do but please check it over.

Yes, I want to get rid of (most) statics.
 
> > I think a separate and well-readable window report is 
> needed for various
> > reasons, not the least one being that, certainly in 
> internet play, players
> > would like to see a written account of the game actions, 
> not cluttered by
> > other log info. 
> > The format is like game reports I have seen published on 
> the Internet, and
> > indeed intended to be suitable for saving, emailing (PBEM), 
> publishing etc.
> 
> I think a next step might be to have the "game report" be 
> separated from other debug logging by having it be completely 
> regenerable from the same game history that undo uses.  I've 
> lost track--does the undo trail now include the entire game, 
> or are there still unundoable actions that cause it to be truncated?

The fact that the report messages are also added to the log (as INFO)
looks logical to me. I don't see why that should be avoided.

The undo trail indeed covers the whole game, but the actions
contained in it are much more granular: just the movements of 
the game pieces (cards, tokens) and cash, and status variable changes.
I don't think the report messages can be reconstructed from such
low-level movements.

Saving the high-level game actions (PossibleAction instances) 
would have been another option, but that would have required lots
of code to figure out the detailed consequences of those actions
(and undoing these) from a different (post-action) game state 
than is now done from the pre-action state. I did not consider
that to be a viable option.

As undo/redo works now, it's pretty much invisible to the main code.
All that needs be done is to make sure that all changes are applied
by creating an instance of a Move subclass, or by calling a setter
in a State subclass, and to call MoveSet.start() and MoveSet.finish() 
at the right moments. 
The internals of the move package handle all the rest of it.

BTW Talking about reports and undo: currently Undo and Redo just 
write these words to the report. In stead, I would like Undo to 
remove the corresponding lines from the report. But *not* by 
keeping all versions of the whole report window in memory!
I'm looking for a somewhat more intelligent way of linking 
ReportBuffer with MoveSet, so that each MoveSet contains
just the latest addition(s) to the report window.
It should not be too difficult, but I haven't got to it yet.
 
Erik.

Re: [Rails-devel] delurking with a quick ReportWindow fix

[Jonathan F. <jon...@ya...>]

> If you know a better way than a JLabel to achieve the same effect, I'd like

> to know it. This was the only way I could manage it.

OK, done (appended) and it was much easier than I thought.  In the process I destaticified some things, which felt like the right thing to do but please check it over.

> I think a separate and well-readable window report is needed for various
> reasons, not the least one being that, certainly in internet play, players
> would like to see a written account of the game actions, not cluttered by
> other log info. 
> The format is like game reports I have seen published on the Internet, and
> indeed intended to be suitable for saving, emailing (PBEM), publishing etc.

I think a next step might be to have the "game report" be separated from other debug logging by having it be completely regenerable from the same game history that undo uses.  I've lost track--does the undo trail now include the entire game, or are there still unundoable actions that cause it to be truncated?

-- Jonathan

diff -r -x CVS -u --strip-trailing-cr 18xx.orig/rails/ui/swing/GameUIManager.java 18xx/rails/ui/swing/GameUIManager.java
--- 18xx.orig/rails/ui/swing/GameUIManager.java 2008-06-30 13:35:29.000000000 -0700
+++ 18xx/rails/ui/swing/GameUIManager.java      2008-11-19 13:52:56.640625000 -0800
@@ -124,7 +124,7 @@
         log.debug("==Result from server: " + result);
         activeWindow.displayServerMessage();
 
-        ReportWindow.addLog();
+        reportWindow.addLog();
 
         // End of game checks
         if (gameManager.isGameOver()) {
diff -r -x CVS -u --strip-trailing-cr 18xx.orig/rails/ui/swing/ORUIManager.java 18xx/rails/ui/swing/ORUIManager.java
--- 18xx.orig/rails/ui/swing/ORUIManager.java   2008-10-12 07:36:44.000000000 -0700
+++ 18xx/rails/ui/swing/ORUIManager.java        2008-11-19 13:54:08.859375000 -0800
@@ -350,7 +350,7 @@
             displayRemainingTiles();
         }
 
-        ReportWindow.addLog();
+        gameUIManager.reportWindow.addLog();
     }
 
     /** Stub, can be overridden in subclasses */
diff -r -x CVS -u --strip-trailing-cr 18xx.orig/rails/ui/swing/ORWindow.java 18xx/rails/ui/swing/ORWindow.java
--- 18xx.orig/rails/ui/swing/ORWindow.java      2008-06-30 13:35:29.000000000 -0700
+++ 18xx/rails/ui/swing/ORWindow.java   2008-11-19 13:54:20.078125000 -0800
@@ -77,7 +77,7 @@
         setSize(800, 600);
         addWindowListener(this);
 
-        ReportWindow.addLog();
+        gameUIManager.reportWindow.addLog();
     }
 
     public ORUIManager getORUIManager() {
diff -r -x CVS -u --strip-trailing-cr 18xx.orig/rails/ui/swing/ReportWindow.java 18xx/rails/ui/swing/ReportWindow.java
--- 18xx.orig/rails/ui/swing/ReportWindow.java  2008-11-18 14:12:50.000000000 -0800
+++ 18xx/rails/ui/swing/ReportWindow.java       2008-11-19 13:57:43.781250000 -0800
@@ -15,29 +15,28 @@
 public class ReportWindow extends JFrame implements WindowListener, KeyListener {
 
     private static final long serialVersionUID = 1L;
-    private JLabel message;
+    private JTextArea message;
     private JScrollPane messageScroller;
     private JScrollBar vbar;
     private JPanel messagePanel;
-    private static ReportWindow messageWindow;
+    private ReportWindow messageWindow;
     private GameManager gameManager;
 
-    private static StringBuffer buffer = new StringBuffer("<html></html>");
-
     public ReportWindow(GameManager gameManager) {
         messageWindow = this;
         this.gameManager = gameManager;
 
-        message = new JLabel("");
+        message = new JTextArea();
+        message.setEditable(false);
+        message.setLineWrap(false);
         message.setBackground(Color.WHITE);
         message.setOpaque(true);
-        message.setVerticalAlignment(SwingConstants.TOP);
         message.setBorder(BorderFactory.createEmptyBorder(5, 5, 5, 5));
 
         messagePanel = new JPanel(new GridBagLayout());
         messageScroller =
                 new JScrollPane(message,
-                        ScrollPaneConstants.VERTICAL_SCROLLBAR_AS_NEEDED,
+                        ScrollPaneConstants.VERTICAL_SCROLLBAR_ALWAYS,
                         ScrollPaneConstants.HORIZONTAL_SCROLLBAR_AS_NEEDED);
         vbar = messageScroller.getVerticalScrollBar();
         GridBagConstraints gbc = new GridBagConstraints();
@@ -55,12 +54,10 @@
 
     }
 
-    public static void addLog() {
+    public void addLog() {
         String newText = ReportBuffer.get();
         if (newText.length() > 0) {
-            buffer.insert(buffer.length() - 7, newText.replaceAll("\n", "<br>"));
-
-            messageWindow.message.setText(buffer.toString());
+            message.append(newText);
             SwingUtilities.invokeLater(new Runnable() {
                 public void run() {
                     messageWindow.vbar.setValue(messageWindow.vbar.getMaximum());

Re: [Rails-devel] delurking with a quick ReportWindow fix

[Erik V. <eri...@hc...>]

Jonathan,

Thanks for this fix, which repairs a long-standing annoyance (at least to
me).
I have committed it into CVS.

If you know a better way than a JLabel to achieve the same effect, I'd like
to know it. This was the only way I could manage it.

I think a separate and well-readable window report is needed for various
reasons, not the least one being that, certainly in internet play, players
would like to see a written account of the game actions, not cluttered by
other log info. 
The format is like game reports I have seen published on the Internet, and
indeed intended to be suitable for saving, emailing (PBEM), publishing etc.

Erik.

> -----Original Message-----
> From: Jonathan Ferro [mailto:jon...@ya...] 
> Sent: Monday 17 November 2008 07:18
> To: rai...@li...
> Subject: [Rails-devel] delurking with a quick ReportWindow fix
> 
> Hello all,
> 
> I haven't looked at the code in over a year (and really only 
> lurked before that), so I thought I'd find something to fix 
> to justify my continued presence.  Here's a quick fix to 
> ReportWindow that (a) installs a clearer border around the 
> text, and (b) causes the scrollbar to wait until the text has 
> been repainted before recomputing where the "bottom" of the 
> window is.  The (ab)use of a JLabel for the purpose of 
> displaying the game log, which makes it impossible to 
> select/copy the text, can be a lower-priority problem since 
> all the info in this window is also available in the debug log file.
> 
> -- Jonathan
> 
> swing $ diff -u ReportWindow.java.orig ReportWindow.java
> --- ReportWindow.java.orig      2008-11-16 22:03:40.984375000 -0800
> +++ ReportWindow.java   2008-11-16 16:30:58.203125000 -0800
> @@ -32,6 +32,8 @@
>          message.setBackground(Color.WHITE);
>          message.setOpaque(true);
>          message.setVerticalAlignment(SwingConstants.TOP);
> +        message.setBorder(BorderFactory.createEmptyBorder(5, 
> 5, 5, 5));
> +
>          messagePanel = new JPanel(new GridBagLayout());
>          messageScroller =
>                  new JScrollPane(message,
> @@ -47,9 +49,6 @@
>  
>          setSize(400, 400);
>          setLocation(600, 400);
> -
> -        messagePanel.setBorder(BorderFactory.createEtchedBorder());
> -
>          setTitle("Rails: Game log");
>          addWindowListener(this);
>          addKeyListener(this);
> @@ -62,7 +61,11 @@
>              buffer.insert(buffer.length() - 7, 
> newText.replaceAll("\n", "<br>"));
>  
>              messageWindow.message.setText(buffer.toString());
> -            
> messageWindow.vbar.setValue(messageWindow.vbar.getMaximum());
> +            SwingUtilities.invokeLater(new Runnable() {
> +                public void run() {
> +                    
> messageWindow.vbar.setValue(messageWindow.vbar.getMaximum());
> +                }
> +            });
>          }
>      }
> 
> 
> --------------------------------------------------------------
> -----------
> This SF.Net email is sponsored by the Moblin Your Move 
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & 
> win great prizes
> Grand prize is a trip for two to an Open Source event 
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 

[Rails-devel] delurking with a quick ReportWindow fix

[Jonathan F. <jon...@ya...>]

Hello all,

I haven't looked at the code in over a year (and really only lurked before that), so I thought I'd find something to fix to justify my continued presence.  Here's a quick fix to ReportWindow that (a) installs a clearer border around the text, and (b) causes the scrollbar to wait until the text has been repainted before recomputing where the "bottom" of the window is.  The (ab)use of a JLabel for the purpose of displaying the game log, which makes it impossible to select/copy the text, can be a lower-priority problem since all the info in this window is also available in the debug log file.

-- Jonathan

swing $ diff -u ReportWindow.java.orig ReportWindow.java
--- ReportWindow.java.orig      2008-11-16 22:03:40.984375000 -0800
+++ ReportWindow.java   2008-11-16 16:30:58.203125000 -0800
@@ -32,6 +32,8 @@
         message.setBackground(Color.WHITE);
         message.setOpaque(true);
         message.setVerticalAlignment(SwingConstants.TOP);
+        message.setBorder(BorderFactory.createEmptyBorder(5, 5, 5, 5));
+
         messagePanel = new JPanel(new GridBagLayout());
         messageScroller =
                 new JScrollPane(message,
@@ -47,9 +49,6 @@
 
         setSize(400, 400);
         setLocation(600, 400);
-
-        messagePanel.setBorder(BorderFactory.createEtchedBorder());
-
         setTitle("Rails: Game log");
         addWindowListener(this);
         addKeyListener(this);
@@ -62,7 +61,11 @@
             buffer.insert(buffer.length() - 7, newText.replaceAll("\n", "<br>"));
 
             messageWindow.message.setText(buffer.toString());
-            messageWindow.vbar.setValue(messageWindow.vbar.getMaximum());
+            SwingUtilities.invokeLater(new Runnable() {
+                public void run() {
+                    messageWindow.vbar.setValue(messageWindow.vbar.getMaximum());
+                }
+            });
         }
     }

Re: [Rails-devel] [Rails-commits] 18xx/rails/game TileI.java, 1.11, 1.12 Tile.java, 1.20, 1.21

[Erik V. <eri...@hc...>]

Yes, I know I'm the culprit.
The point is, though, that many of my changes start somewhat experimentally,
and I need to be able to *see* what I have removed until it's final. And,
yes, I then often overlook to remove much of that.
My current work on 1856 capitalization again causes pretty much refactoring
and removal of redundant code, so I hope I will do better this time.
Feel free to remove dead code when you see it. And whether you see it or
not, trust me, it's harmless.
Erik.

> -----Original Message-----
> From: Mark Smith [mailto:mar...@gm...] 
> Sent: Saturday 15 November 2008 19:43
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] [Rails-commits] 18xx/rails/game 
> TileI.java, 1.11,1.12 Tile.java, 1.20, 1.21
> 
> In this I agree with Brett completely. Given the CVS System, if
> something fails and you need to revert, you can go back to an older
> revision easy enough. It makes the code a lot cleaner to remove "dead
> code" before it is checked in.
> 
> Mark
> 
> --------------------------------------------------------------
> -----------
> This SF.Net email is sponsored by the Moblin Your Move 
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & 
> win great prizes
> Grand prize is a trip for two to an Open Source event 
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 

Re: [Rails-devel] [Rails-commits] 18xx/rails/game TileI.java, 1.11, 1.12 Tile.java, 1.20, 1.21

[Mark S. <mar...@gm...>]

In this I agree with Brett completely. Given the CVS System, if
something fails and you need to revert, you can go back to an older
revision easy enough. It makes the code a lot cleaner to remove "dead
code" before it is checked in.

Mark

Re: [Rails-devel] [Rails-commits] 18xx/rails/game TileI.java, 1.11, 1.12 Tile.java, 1.20, 1.21

[brett l. <wak...@gm...>]

I know that, historically, we've commented out many changes. Let's
dispose of that practice.

If it's your intention to change behavior and not just temporarily
disable something then just go ahead and remove the methods.

---Brett.

On Sat, Nov 15, 2008 at 5:41 AM, Erik Vos <ev...@us...> wrote:
> Update of /cvsroot/rails/18xx/rails/game
> In directory 23jxhf1.ch3.sourceforge.com:/tmp/cvs-serv7515/rails/game
>
> Modified Files:
>        TileI.java Tile.java
> Log Message:
> Removed isLayableNow()
>
> Index: TileI.java
> ===================================================================
> RCS file: /cvsroot/rails/18xx/rails/game/TileI.java,v
> retrieving revision 1.11
> retrieving revision 1.12
> diff -C2 -d -r1.11 -r1.12
> *** TileI.java  4 Jun 2008 19:00:32 -0000       1.11
> --- TileI.java  15 Nov 2008 13:41:11 -0000      1.12
> ***************
> *** 39,43 ****
>      public boolean isUpgradeable();
>
> !     public boolean isLayableNow();
>
>      public List<TileI> getUpgrades(MapHex hex);
> --- 39,43 ----
>      public boolean isUpgradeable();
>
> !     //public boolean isLayableNow();
>
>      public List<TileI> getUpgrades(MapHex hex);
>
> Index: Tile.java
> ===================================================================
> RCS file: /cvsroot/rails/18xx/rails/game/Tile.java,v
> retrieving revision 1.20
> retrieving revision 1.21
> diff -C2 -d -r1.20 -r1.21
> *** Tile.java   30 Jun 2008 20:35:29 -0000      1.20
> --- Tile.java   15 Nov 2008 13:41:11 -0000      1.21
> ***************
> *** 328,334 ****
>       * @return
>       */
> !     public boolean isLayableNow() {
> !         return GameManager.getInstance().getCurrentPhase().isTileColourAllowed(colourName);
> !     }
>
>      /**
> --- 328,334 ----
>       * @return
>       */
> !     // public boolean isLayableNow() {
> !     //    return GameManager.getInstance().getCurrentPhase().isTileColourAllowed(colourName);
> !     //}
>
>      /**
>
>

Re: [Rails-devel] PublicCompany_1856

[Erik V. <eri...@hc...>]

> So I think I'll leave StockRound_1856 as it is now,
> and add an extra condition for getting a turn (for the first time) 
> to OperatingRound_1856.

Done, by overriding a new OperatingRound method setNextOperatingCompany(),
factored out of the existing start() and finishTurn() methods. A message is
displayed if a company that seems eligible for operating at the OR start
appears to be not so when it's turn would start.
Also:
- Removed the isLayableNow() method from Tile (as discussed a while ago).
- Added destinationReached attribute and related methods to PublicCompany.

Erik.

Re: [Rails-devel] PublicCompany_1856

[John D. G. <jd...@di...>]

John A. Tamplin wrote:
> Erik Vos wrote:
>> - the next available train from the bank when the presidency was bought
>> (which determines the company capitalization rules at floating time and
>> later), and
>>   
> No, 1856 cares about the available train type at the point it first 
> tries to operate.  It is a common error to only buy 2 shares at the 
> beginning and find that by the time your company comes up in the 
> operating order, a 3 is available so you do not operate.

You're both right.  The available train type at the point your company
first "tries to operate" determines whether the company has floated,
but the available train type when the president's share is purchased
determines which of the three capitalization schemes applies to the
company (and, therefore, whether it ever needs to destinate).

Re: [Rails-devel] PublicCompany_1856

[Erik V. <eri...@hc...>]

> Erik Vos wrote:
> > - the next available train from the bank when the 
> presidency was bought
> > (which determines the company capitalization rules at 
> floating time and
> > later), and
> >   
> No, 1856 cares about the available train type at the point it first 
> tries to operate.  It is a common error to only buy 2 shares at the 
> beginning and find that by the time your company comes up in the 
> operating order, a 3 is available so you do not operate.

In fact, both is true, as Mark has correctly pointed out.
The train type available at company starting time (= buying the presidency)
determines the capitalization rules, so it must be remembered,
and I think this is unique to 1856, unless someone has counterexamples.

Mark is also correct that "floating" in its usual meaning does not exist in
1856.
Nevertheless it is a central concept in Rails, that in this case needs 
to be implemented differently: a company "floats" when it has the turn 
to operate for the first time, and the train available at that time 
is not larger than the number of shares sold. 
So it really "floats" during the Operating Round.

However, in Rails "floating" also means that companies are 
included in the list of companies appearing in the OR (map) window.

So I think I'll leave StockRound_1856 as it is now,
and add an extra condition for getting a turn (for the first time) 
to OperatingRound_1856.

> 18GL also cares about this, but slightly different -- if a company is 
> started after a 10H has been bought, capitalization rules are totally 
> different.  Many other games have similar dependencies on the 
> phase or 
> available train for starting companies, such as what initial stock 
> prices are available, possible starting locations, train purchase 
> restrictions, etc.

Phase dependencies are common, and have so far (I think) all been defined in

XML, although perhaps not yet in a very consistent way. I'm not aware of
other
games of which the rules depend on available trains at different times 
in the game, but I may think again when confronted with counterexamples.
I own a lot more 18xx games than I have played, which makes remembering
the details of all of them not so easy.

> There are enough 18xx games out there and enough interest in making 
> something new and different, that you can find all sorts of 
> rules which 
> have been combined in novel ways in each new game you 
> encounter.  If you 
> create new infrastructure code for each one, you will never 
> be able to 
> extend the set of games supported by Rails separately from modifying 
> Rails itself.  If instead all the base functionality is in Rails, and 
> then the games simply specify how to combine them, then it 
> becomes much 
> more extensible.  I think that feeds directly into the 
> decision to make 
> general-purpose vs. custom infrastructure.

This seems to call for making everything configurable in XML, 
but I don't think that is an achievable goal. Well, perhaps in theory.

On the other hand, should it turn out that some feature once thought
game-specific is common enough for inclusion in the generic code:
refactoring is pretty simple in Eclipse.

BTW the use of game-specific classes is also configured in XML, 
not hardcoded in any way. Should PublicCompany_1856 turn out 
to be useful in some other game 18ABC, well, use (and possibly 
extend and/or rename) it. 

Erik.

Re: [Rails-devel] PublicCompany_1856

[John A. T. <ja...@ja...>]

Erik Vos wrote:
> - the next available train from the bank when the presidency was bought
> (which determines the company capitalization rules at floating time and
> later), and
>   
No, 1856 cares about the available train type at the point it first 
tries to operate.  It is a common error to only buy 2 shares at the 
beginning and find that by the time your company comes up in the 
operating order, a 3 is available so you do not operate.

18GL also cares about this, but slightly different -- if a company is 
started after a 10H has been bought, capitalization rules are totally 
different.  Many other games have similar dependencies on the phase or 
available train for starting companies, such as what initial stock 
prices are available, possible starting locations, train purchase 
restrictions, etc.
> - the amount of treasury money held in escrow by the bank in some cases.
>   
Many games have a similar aspect, typically tied to achieving 
connectivity to or actually running to a destination, or upon hitting a 
particular area of the stock market, or upon conversion.

There are enough 18xx games out there and enough interest in making 
something new and different, that you can find all sorts of rules which 
have been combined in novel ways in each new game you encounter.  If you 
create new infrastructure code for each one, you will never be able to 
extend the set of games supported by Rails separately from modifying 
Rails itself.  If instead all the base functionality is in Rails, and 
then the games simply specify how to combine them, then it becomes much 
more extensible.  I think that feeds directly into the decision to make 
general-purpose vs. custom infrastructure.

--
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                		 		Smyrna, GA  30082-3723

Re: [Rails-devel] PublicCompany_1856

[Mark S. <mar...@gm...>]

I happen to have 1856 Rulebook at hand and I see a few items just to
clarify the points brought up:

STARTING CAPITALIZATION (Page 13)
1. If the President Certificate bought BEFORE a 5 Train is available,
company receives  cash for each of the first five (5) shares sold. If
shares after the fifth is sold, the extra cash goes into escrow.
2. If the President Certificate bought when a 5 Train is available,
cash for each share sold goes to company (no escrow)
3. If the President Certificate bought when a 6 or Diesel is
available, cash for all 10 shares goes to company

INITIAL SHARES NEEDED TO OPERATE (Page 14)
# of Shares sold equal to or greater than the number of current train
type available. This is determined at the time when the company "may
be able to operate", not based upon when the President's certificate
is bought.
EXAMPLE: If a 2 train available, only the President share needed, if a
3 train available, 3 shares must be sold.

The rules have a very clear example of when this odd situation occurs.

There is no concept of "floating" a company like in the other games.

What may also be necessary for this 1856 subclass is a count of the
number of loans the company has out.

Mark

On Thu, Nov 13, 2008 at 4:13 PM, Erik Vos <eri...@hc...> wrote:
> It is interesting that, just having had a discussion about Company types,
> I'm for the first time hitting the need for a game-specific company
> subclass. 1856 public companies need (at least) two per-company attributes
> that, I believe, are unique to this game and should not be included in the
> generic PublicCompany class:
>
> - the next available train from the bank when the presidency was bought
> (which determines the company capitalization rules at floating time and
> later), and
>
> - the amount of treasury money held in escrow by the bank in some cases.
>
> So I think I'm going to create a subclass PublicCompany_1856 to hold these
> values.
>
> The destination hex and the destination-reached condition are common enough
> to be put into PublicCompany itself (the hex has in fact always been there).
> Setting destination-reached will be a menu action, for the time being.
>
> Comments?
>
> Erik
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] PublicCompany_1856

[Erik V. <eri...@hc...>]

It is interesting that, just having had a discussion about Company types,
I'm for the first time hitting the need for a game-specific company
subclass. 1856 public companies need (at least) two per-company attributes
that, I believe, are unique to this game and should not be included in the
generic PublicCompany class:

- the next available train from the bank when the presidency was bought
(which determines the company capitalization rules at floating time and
later), and

- the amount of treasury money held in escrow by the bank in some cases.

So I think I'm going to create a subclass PublicCompany_1856 to hold these
values.

The destination hex and the destination-reached condition are common enough
to be put into PublicCompany itself (the hex has in fact always been there).
Setting destination-reached will be a menu action, for the time being.

Comments?

Erik

Re: [Rails-devel] Status of Tile & Map Code Integration

[Mark S. <mar...@gm...>]

OK Given that Brett and Erik are both in agreement on this, I will
concede the point. I am not here to make waves. I hope to be here to
help contribute to the development of the project.

Re: [Rails-devel] Status of Tile & Map Code Integration

[Erik V. <eri...@hc...>]

> However, I disagree with the implication that we have 
> "enough" classes.
> There is no empiric measurement we can take, no way of calculating an
> exact number of classes that are "enough".
> 
> If there's a better way to implement something, it shouldn't 
> matter how
> many additional classes it requires. What's important is the benefits
> brought to the code in terms of maintenance, scaling, and allowing us
> humans to clearly understand what the code is doing.
> 
> If that means we reorganize things into a larger number of 
> class files,
> so be it.

Of course. I only meant to avoid multiplying entities without necessity (if
I may misuse Occam this way).
Erik.

Re: [Rails-devel] Status of Tile & Map Code Integration

[Brett L. <wak...@gm...>]

On Mon, 2008-11-10 at 23:09 +0100, Erik Vos wrote:
> I completely agree with John. Enforcing a particular hierarchical order in
> which features appear would be too rigid. 
> 
> This could be loosened by creating interfaces like HasShares, HasTokens etc,
> which dedicated (perhaps game-dependent) company classes could implement,
> but that would lead to even more class (+interface) files.
> 
> Other considerations:
> 1. Coding is easier the way it is: you only need tests like hasSharePrice()
> etc. Your way you will get a lot of instanceof's + casts + separate
> variables for the casted subtypes, to handle all the differences in (for
> instance) OperatingRound.
> 
> 2. We have enough classes as it is. I'm only in favour of creating new ones
> if there is a real need for it, which I don't see in this case. I don't want
> to spend too much time and energy in remembering small differences between
> similar classes.
> Systems are the only special types for which I see a need for a new class.
> And maybe the 1841 concessions (but these are more like privates). 
> 

I agree with your basic idea. I don't want our code to mimic the Java
API, with it's numerous varieties of similar containers (List, Array,
ArrayList, Vector, Map, HashMap, etc). 

However, I disagree with the implication that we have "enough" classes.
There is no empiric measurement we can take, no way of calculating an
exact number of classes that are "enough".

If there's a better way to implement something, it shouldn't matter how
many additional classes it requires. What's important is the benefits
brought to the code in terms of maintenance, scaling, and allowing us
humans to clearly understand what the code is doing.

If that means we reorganize things into a larger number of class files,
so be it.

> 3. Yes, PublicCompany is a large class. I'm sure there are some redundancies
> and methods that belong somewhere else (similar to the redundant method in
> Tile that we have spotted recently). But in handling company objects in
> OperatingRound etc., the similarities between the various types look more
> important to me than the differences.

> On transformations: critical to me is whether or not the company name
> changes. If so, it is a new company and shares are exchanged. If not (for
> instance, when a minor or 5-share company transforms to a major or 10-share
> company, as in 1826 and several other games), it remains the same company,
> and shares are moved from "unavailable" to whereever the new shares are to
> be put, and the percentage per share is changed (e.g. from 20 to 10).
> 
> Erik.


---Brett.

> 
> 
> > -----Original Message-----
> > From: John A. Tamplin [mailto:ja...@ja...] 
> > Sent: Monday 10 November 2008 07:45
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] Status of Tile & Map Code Integration
> > 
> > Mark Smith wrote:
> > > When I came up with my hierarchy I was primarily focused on 
> > the games
> > > I currently own (1829, 1830, 1835, 1837, 1853, 1856, 1870). 
> > And since
> > > then many more sprang up. I do still feel building a basic hierarchy
> > > for companies makes sense. It allows separation of 
> > functionality. and
> > > allows the class hierarchy enforce some of the game mechanics (a
> > > company that is just a Train Company, cannot manipulate 
> > tokens, and if
> > > a Company is a Token Company, but not a Share Company cannot have
> > > certificates that have variable price). But I would be interested in
> > > what Brett & Erik have to say on the subject. I am sure they have
> > > discussed this in the past.
> > >   
> > The problem is there are a large number of variations and 
> > more will be 
> > added over time.  Assume you have n different criteria you want to 
> > encode in the class hierarchy (exists on the map, has tokens, has a 
> > share price, may merge, etc).  If you encode all 
> > possibilities into the 
> > hierarchy, you wind up with n^m classes, most of which are very 
> > similar.  If instead you expose these different functions 
> > into separate 
> > classes and have the company delegate to them depending on 
> > what form it 
> > currently has, you have only n*m classes with no code duplication.
> > 
> > Again think of the idea of Rails being to core code to implement any 
> > game and the per-game files would contain only unique code needed for 
> > that game.  If a new game requires a new combination of these 
> > features 
> > in a company, the only option would be to duplicate lots of in-Rails 
> > code in the game-specific classes, which worsens the 
> > maintenance burden 
> > especially when they may have separate maintainers.
> > 
> > --
> > John A. Tamplin					ja...@ja...
> > 770/436-5387 HOME				4116 Manson Ave
> >                 		 		Smyrna, GA  30082-3723
> > 
> > 
> > --------------------------------------------------------------
> > -----------
> > This SF.Net email is sponsored by the Moblin Your Move 
> > Developer's challenge
> > Build the coolest Linux based applications with Moblin SDK & 
> > win great prizes
> > Grand prize is a trip for two to an Open Source event 
> > anywhere in the world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > 
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
---Brett.

The graveyards are full of indispensable men.
		-- Charles de Gaulle

Re: [Rails-devel] Status of Tile & Map Code Integration

[Erik V. <eri...@hc...>]

I completely agree with John. Enforcing a particular hierarchical order in
which features appear would be too rigid. 

This could be loosened by creating interfaces like HasShares, HasTokens etc,
which dedicated (perhaps game-dependent) company classes could implement,
but that would lead to even more class (+interface) files.

Other considerations:
1. Coding is easier the way it is: you only need tests like hasSharePrice()
etc. Your way you will get a lot of instanceof's + casts + separate
variables for the casted subtypes, to handle all the differences in (for
instance) OperatingRound.

2. We have enough classes as it is. I'm only in favour of creating new ones
if there is a real need for it, which I don't see in this case. I don't want
to spend too much time and energy in remembering small differences between
similar classes.
Systems are the only special types for which I see a need for a new class.
And maybe the 1841 concessions (but these are more like privates). 

3. Yes, PublicCompany is a large class. I'm sure there are some redundancies
and methods that belong somewhere else (similar to the redundant method in
Tile that we have spotted recently). But in handling company objects in
OperatingRound etc., the similarities between the various types look more
important to me than the differences.

On transformations: critical to me is whether or not the company name
changes. If so, it is a new company and shares are exchanged. If not (for
instance, when a minor or 5-share company transforms to a major or 10-share
company, as in 1826 and several other games), it remains the same company,
and shares are moved from "unavailable" to whereever the new shares are to
be put, and the percentage per share is changed (e.g. from 20 to 10).

Erik.


> -----Original Message-----
> From: John A. Tamplin [mailto:ja...@ja...] 
> Sent: Monday 10 November 2008 07:45
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Status of Tile & Map Code Integration
> 
> Mark Smith wrote:
> > When I came up with my hierarchy I was primarily focused on 
> the games
> > I currently own (1829, 1830, 1835, 1837, 1853, 1856, 1870). 
> And since
> > then many more sprang up. I do still feel building a basic hierarchy
> > for companies makes sense. It allows separation of 
> functionality. and
> > allows the class hierarchy enforce some of the game mechanics (a
> > company that is just a Train Company, cannot manipulate 
> tokens, and if
> > a Company is a Token Company, but not a Share Company cannot have
> > certificates that have variable price). But I would be interested in
> > what Brett & Erik have to say on the subject. I am sure they have
> > discussed this in the past.
> >   
> The problem is there are a large number of variations and 
> more will be 
> added over time.  Assume you have n different criteria you want to 
> encode in the class hierarchy (exists on the map, has tokens, has a 
> share price, may merge, etc).  If you encode all 
> possibilities into the 
> hierarchy, you wind up with n^m classes, most of which are very 
> similar.  If instead you expose these different functions 
> into separate 
> classes and have the company delegate to them depending on 
> what form it 
> currently has, you have only n*m classes with no code duplication.
> 
> Again think of the idea of Rails being to core code to implement any 
> game and the per-game files would contain only unique code needed for 
> that game.  If a new game requires a new combination of these 
> features 
> in a company, the only option would be to duplicate lots of in-Rails 
> code in the game-specific classes, which worsens the 
> maintenance burden 
> especially when they may have separate maintainers.
> 
> --
> John A. Tamplin					ja...@ja...
> 770/436-5387 HOME				4116 Manson Ave
>                 		 		Smyrna, GA  30082-3723
> 
> 
> --------------------------------------------------------------
> -----------
> This SF.Net email is sponsored by the Moblin Your Move 
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & 
> win great prizes
> Grand prize is a trip for two to an Open Source event 
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>