rails-devel — List for discussion of Rails development

Re: [Rails-devel] Rails 1.7.7 bug - 18AL

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

I'm sorry, you're right, I'm wrong.  I had it confused with another game.

On 2012-07-15 08:29, John David Galt wrote:
> The rules say the tile can be placed as soon as the 6-train is bought.
> 
> On 2012-07-15 03:36, Erik Vos wrote:
>> That is because the first 4D-train has not yet been bought.
>>
>>> -----Original Message-----
>>> From: John David Galt [mailto:jd...@di...]
>>> Sent: Sunday, July 15, 2012 4:13 AM
>>> To: rai...@li...
>>> Subject: [Rails-devel] Rails 1.7.7 bug - 18AL
>>>
>>> This game ran just fine until the point of the save file -- but it won't
>> allow me
>>> to place the grey tile in Birmingham.
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and 
>> threat landscape has changed and how IT managers can respond. Discussions 
>> will include endpoint security, mobile security and the latest in malware 
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 

Re: [Rails-devel] Rails 1.7.7 bug - 18AL

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

The rules say the tile can be placed as soon as the 6-train is bought.

On 2012-07-15 03:36, Erik Vos wrote:
> That is because the first 4D-train has not yet been bought.
> 
>> -----Original Message-----
>> From: John David Galt [mailto:jd...@di...]
>> Sent: Sunday, July 15, 2012 4:13 AM
>> To: rai...@li...
>> Subject: [Rails-devel] Rails 1.7.7 bug - 18AL
>>
>> This game ran just fine until the point of the save file -- but it won't
> allow me
>> to place the grey tile in Birmingham.
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 

Re: [Rails-devel] Rails 1.7.7 bug - 18AL

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

That is because the first 4D-train has not yet been bought.

> -----Original Message-----
> From: John David Galt [mailto:jd...@di...]
> Sent: Sunday, July 15, 2012 4:13 AM
> To: rai...@li...
> Subject: [Rails-devel] Rails 1.7.7 bug - 18AL
> 
> This game ran just fine until the point of the save file -- but it won't
allow me
> to place the grey tile in Birmingham.

[Rails-devel] Rails 1.7.7 bug - 18AL

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

This game ran just fine until the point of the save file -- but it won't
allow me to place the grey tile in Birmingham.

Re: [Rails-devel] Bug in Statuswindow

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

On 2012-07-13 06:18, Erik Vos wrote:
> Both the upper and lower captions are initialized according to the priority situation at game starting/loading time, but only the upper caption is ever updated to show a changed PD.
> 
> I believe my original intention was to show the PD marker only in the upper caption row.  So the lower captions should have been initialized with just the player name.
> 
> But if a majority votes for showing the PD marker both up and down, I’ll be happy to change accordingly.  Both ways to fix this bug are easy to do.

This is something I was considering changing myself.  If I had my way, the letters
"PD" would show in the player-name lines of the Game Status window and nowhere
else, ever (especially not in the map/operating-round window).

Better still would be to replace it with highlighting in some unique color (green?)
so that the Game Status window would never need to change its size, except possibly
when one or more companies are permanently removed from play.

Re: [Rails-devel] Bug in Statuswindow

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

Martin & all,

 

Both the upper and lower captions are initialized according to the priority situation at game starting/loading time, but only the upper caption is ever updated to show a changed PD.

 

I believe my original intention was to show the PD marker only in the upper caption row.  So the lower captions should have been initialized with just the player name.

But if a majority votes for showing the PD marker both up and down, I’ll be happy to change accordingly.  Both ways to fix this bug are easy to do.

 

Erik.

 

 

From: Dr....@t-... [mailto:Dr....@t-...] 
Sent: Wednesday, July 11, 2012 6:11 PM
To: Erik Vos; Rails Devel
Subject: Bug in Statuswindow

 

Hi Erik, 

 

please have a look at the attached Graphic. It shows that the Top Row has changed the PD correctly after a share purchase while the bottom row apparently isnt updated.

 

I 'll attach the save game also but upon load this behaviour will not be visible perhaps after the next action.

 

KInd regards,

Martin

 

Re: [Rails-devel] Rails2.0: Observer and Formatter

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

Stefan,

OK, I understand your reasoning.
>From your proposals, Presenter sounds best to me, but I leave it entirely to
you.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Thursday, July 12, 2012 10:09 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Rails2.0: Observer and Formatter
> 
> Erik:
> as in the previous cases I prefer generic (short) names for the basic
> Interfaces and Abstract Classes.
> 
> Main reason is that usually the specialization implies adding another word
to
> that, e.g. State and BooleanState.
> 
> However there is no major reason to use ObservableFormatter and then
> replace Observable by the specializaton e.g. BooleanFormatter.
> Only disadvantage is more typing:
> 
> Example:
> BooleanFormatter extends ObservableFormatter<BooleanState>
> 
> instead of
> 
> BooleanFormatter extends Formatter<BooleanState>
> 
> As there are no other Formatters exist in Rails and I have no intention to
add
> one, I would prefer to stick with the shorter name.
> 
> I used the label "View" for implementations of an Observer.
> 
> Using View (as view in a MVC context) would be misleading for the
> Formatter as  the Formatter acts more like the upper level of the Model.
> 
> One could consider them as Adapter or Presenter in a MVA/MVP framework
> (check Wikipedia for short explanations). All three names Formatter,
Adapter
> and Presenter are ok with me, so I would follow your recommendation.
> 
> Stefan
> 
> 
> On 07/12/2012 09:45 AM, Erik Vos wrote:
> > Stefan,
> >
> > This looks absolutely fine to me.
> >
> > Just one remark: 'Formatter' is a rather generic name, but it seems to
> > me that its usage is restricted to wrapping Observables.
> > If that is true, shouldn't we try to find a more descriptive name?
> > ObservableFormatter is a bit longish, perhaps just Viewer (or
> > ObservableViewer) would do? (as you use xxxViewer in some examples).
> >
> > Erik.
> >
> >> -----Original Message-----
> >> From: Stefan Frey [mailto:ste...@we...]
> >> Sent: Thursday, July 12, 2012 12:06 AM
> >> To: Development list for Rails: an 18xx game
> >> Subject: [Rails-devel] Rails2.0: Observer and Formatter
> >>
> >> After the recent discussion I have finalized the Observer Interface.
> >> Related to this I present the Formatter (Abstract) Class that allows
> >> for different type of output from the identical Observable object.
> >>
> >> As usual comments are very welcome, as things can still be changed
> easily.
> >>
> >> Stefan
> >>
> >>
> >> *** Observer
> >> I took two major decisions that (on a first glance) limits the
> > flexibility,
> >> however simplifies the structure.
> >>
> >> 1. Each observer is only allowed to observe one Observable (reminder:
> >> this is either a State or a Model). However an observable can have
> >> many observers (so it is a n:1 relation).
> >>
> >> 2. The data transferred is always a String.
> >>
> >> However this makes the Observer interface straightforward. There is
only
> >>    ...
> >>
> >>       (public) void update(String text);
> >>
> >> ... one method with one argument containing the updated data from the
> >> observed Observable.
> >>
> >> This is called only once per ChangeSet activity (committing a new,
> >> undo, redo), and only if the Observable is changed by the ChangeSet(s)
> executed.
> >>
> >> * Usage:
> >>
> >> Adding an observer to an observable uses the following method:
> >> observable.addObserver(observer);
> >>
> >> It is possible to remove it:
> >> observable.removeObserver(observer);
> >>
> >> or to get a set with all attached observers
> >> observable.getObservers()
> >>
> >> * Remark:
> >>
> >> The two assumptions above are not as restrictive as it might appear:
> >>
> >> 1. It is easy to build a Class that contains several Observers as
> >> inner
> > classes
> >> that observe multiple Observable. (Similar to Listeners in Swing).
> >>
> >> 2. It is possible that the String could contain XML, Json or another
> > serialized
> >> representation of a more complex data structure.
> >> As long as no true client/server separation is done, direct callbacks
> >> are possible (and later one could still add some RMI technology).
> >>
> >> *** Formatter
> >>
> >> A class that extends the abstract Formatter class can act as a
> >> wrapper
> > around
> >> an Observable to change the output text specific for different
observers.
> >> Usually the text delivered to the update method of the observers is
> >> the
> > one
> >> defined by the observerText() method of the Observable.
> >> A Formatter now allows to
> >>
> >> * Example: Share Portfolio
> >>
> >> Assume that you have a Model that represents the SharePortfolio of a
> > Player
> >> (labelled CertificateModel).
> >> Now there could be two Observers in the GUI for that SharePortfolio:
> >> One could display the total percentage of the shares for one company
> (e.g.
> >> 40%, labelled percentViewer), whereas the other (called
> >> toolTipViewer) displays the exact compositon (20%P+1*10%+2*5%).
> >>
> >> To achieve this one creates a Formatter<CertificateModel> that take
> >> the CertificateModel as one argument to its constructor and the
> >> required type
> > of
> >> output as the other argument (e.g. verbose=true/false).
> >>
> >> Then the Observer would not be added to the Observable directly, but
> >> to
> > the
> >> Formatter objects, that wrap the Observable inside:
> >>
> >> detailedCertificates.addObserver(toolTipViewer)
> >> percentageCertificates.addObserver(percentViewer)
> >>
> >> * Another Example: BooleanState
> >>
> >> As Unit Test I have defined a simple Formatter for a BooleanState
> >> that instead the default text ("true" versus "false") simply delivers
> >> an
> > alternative
> >> text representation ("yes" versus "no")
> >>
> >> * Implementation / Usage
> >>
> >> Again it is pretty simple:
> >> There is the abstract method observerText which has to be
> >> overwritten,
> > e.g.
> >> in the case of BooleanState above:
> >>
> >> @Override
> >> public String observerText() {
> >>     if (state.value()) {
> >>       return "yes";
> >>     } else {
> >>       return "no";
> >>     }
> >> }
> >>
> >> *** Current state of implementation
> >> Both Observer and Formatter are fully implemented and have unit tests
> >> attached.
> >>
> >>
> >>
> > ----------------------------------------------------------------------
> > ------
> > --
> >> Live Security Virtual Conference
> >> Exclusive live event will cover all the ways today's security and
> >> threat landscape has changed and how IT managers can respond.
> >> Discussions will include endpoint security, mobile security and the
> >> latest in malware threats.
> >> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> > ----------------------------------------------------------------------
> > --------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond.
> > Discussions will include endpoint security, mobile security and the
> > latest in malware threats.
> > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> 
> 
> 
>
----------------------------------------------------------------------------
--
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware
threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Rails2.0: Observer and Formatter

[Stefan F. <ste...@we...>]

Erik:
as in the previous cases I prefer generic (short) names for the basic 
Interfaces and Abstract Classes.

Main reason is that usually the specialization implies adding another 
word to that, e.g. State and BooleanState.

However there is no major reason to use ObservableFormatter and then 
replace Observable by the specializaton e.g. BooleanFormatter.
Only disadvantage is more typing:

Example:
BooleanFormatter extends ObservableFormatter<BooleanState>

instead of

BooleanFormatter extends Formatter<BooleanState>

As there are no other Formatters exist in Rails and I have no intention 
to add one, I would prefer to stick with the shorter name.

I used the label "View" for implementations of an Observer.

Using View (as view in a MVC context) would be misleading for the 
Formatter as  the Formatter acts more like the upper level of the Model.

One could consider them as Adapter or Presenter in a MVA/MVP framework 
(check Wikipedia for short explanations). All three names Formatter, 
Adapter and Presenter are ok with me, so I would follow your recommendation.

Stefan


On 07/12/2012 09:45 AM, Erik Vos wrote:
> Stefan,
>
> This looks absolutely fine to me.
>
> Just one remark: 'Formatter' is a rather generic name, but it seems to me
> that its usage is restricted to wrapping Observables.
> If that is true, shouldn't we try to find a more descriptive name?
> ObservableFormatter is a bit longish, perhaps just Viewer (or
> ObservableViewer) would do? (as you use xxxViewer in some examples).
>
> Erik.
>
>> -----Original Message-----
>> From: Stefan Frey [mailto:ste...@we...]
>> Sent: Thursday, July 12, 2012 12:06 AM
>> To: Development list for Rails: an 18xx game
>> Subject: [Rails-devel] Rails2.0: Observer and Formatter
>>
>> After the recent discussion I have finalized the Observer Interface.
>> Related to this I present the Formatter (Abstract) Class that allows for
>> different type of output from the identical Observable object.
>>
>> As usual comments are very welcome, as things can still be changed easily.
>>
>> Stefan
>>
>>
>> *** Observer
>> I took two major decisions that (on a first glance) limits the
> flexibility,
>> however simplifies the structure.
>>
>> 1. Each observer is only allowed to observe one Observable (reminder:
>> this is either a State or a Model). However an observable can have many
>> observers (so it is a n:1 relation).
>>
>> 2. The data transferred is always a String.
>>
>> However this makes the Observer interface straightforward. There is only
>>    ...
>>
>>       (public) void update(String text);
>>
>> ... one method with one argument containing the updated data from the
>> observed Observable.
>>
>> This is called only once per ChangeSet activity (committing a new, undo,
>> redo), and only if the Observable is changed by the ChangeSet(s) executed.
>>
>> * Usage:
>>
>> Adding an observer to an observable uses the following method:
>> observable.addObserver(observer);
>>
>> It is possible to remove it:
>> observable.removeObserver(observer);
>>
>> or to get a set with all attached observers
>> observable.getObservers()
>>
>> * Remark:
>>
>> The two assumptions above are not as restrictive as it might appear:
>>
>> 1. It is easy to build a Class that contains several Observers as inner
> classes
>> that observe multiple Observable. (Similar to Listeners in Swing).
>>
>> 2. It is possible that the String could contain XML, Json or another
> serialized
>> representation of a more complex data structure.
>> As long as no true client/server separation is done, direct callbacks are
>> possible (and later one could still add some RMI technology).
>>
>> *** Formatter
>>
>> A class that extends the abstract Formatter class can act as a wrapper
> around
>> an Observable to change the output text specific for different observers.
>> Usually the text delivered to the update method of the observers is the
> one
>> defined by the observerText() method of the Observable.
>> A Formatter now allows to
>>
>> * Example: Share Portfolio
>>
>> Assume that you have a Model that represents the SharePortfolio of a
> Player
>> (labelled CertificateModel).
>> Now there could be two Observers in the GUI for that SharePortfolio:
>> One could display the total percentage of the shares for one company (e.g.
>> 40%, labelled percentViewer), whereas the other (called
>> toolTipViewer) displays the exact compositon (20%P+1*10%+2*5%).
>>
>> To achieve this one creates a Formatter<CertificateModel> that take the
>> CertificateModel as one argument to its constructor and the required type
> of
>> output as the other argument (e.g. verbose=true/false).
>>
>> Then the Observer would not be added to the Observable directly, but to
> the
>> Formatter objects, that wrap the Observable inside:
>>
>> detailedCertificates.addObserver(toolTipViewer)
>> percentageCertificates.addObserver(percentViewer)
>>
>> * Another Example: BooleanState
>>
>> As Unit Test I have defined a simple Formatter for a BooleanState that
>> instead the default text ("true" versus "false") simply delivers an
> alternative
>> text representation ("yes" versus "no")
>>
>> * Implementation / Usage
>>
>> Again it is pretty simple:
>> There is the abstract method observerText which has to be overwritten,
> e.g.
>> in the case of BooleanState above:
>>
>> @Override
>> public String observerText() {
>>     if (state.value()) {
>>       return "yes";
>>     } else {
>>       return "no";
>>     }
>> }
>>
>> *** Current state of implementation
>> Both Observer and Formatter are fully implemented and have unit tests
>> attached.
>>
>>
>>
> ----------------------------------------------------------------------------
> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Rails2.0: Observer and Formatter

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

Stefan,

This looks absolutely fine to me.

Just one remark: 'Formatter' is a rather generic name, but it seems to me
that its usage is restricted to wrapping Observables.
If that is true, shouldn't we try to find a more descriptive name?  
ObservableFormatter is a bit longish, perhaps just Viewer (or
ObservableViewer) would do? (as you use xxxViewer in some examples).

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Thursday, July 12, 2012 12:06 AM
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Rails2.0: Observer and Formatter
> 
> After the recent discussion I have finalized the Observer Interface.
> Related to this I present the Formatter (Abstract) Class that allows for
> different type of output from the identical Observable object.
> 
> As usual comments are very welcome, as things can still be changed easily.
> 
> Stefan
> 
> 
> *** Observer
> I took two major decisions that (on a first glance) limits the
flexibility,
> however simplifies the structure.
> 
> 1. Each observer is only allowed to observe one Observable (reminder:
> this is either a State or a Model). However an observable can have many
> observers (so it is a n:1 relation).
> 
> 2. The data transferred is always a String.
> 
> However this makes the Observer interface straightforward. There is only
>   ...
> 
>      (public) void update(String text);
> 
> ... one method with one argument containing the updated data from the
> observed Observable.
> 
> This is called only once per ChangeSet activity (committing a new, undo,
> redo), and only if the Observable is changed by the ChangeSet(s) executed.
> 
> * Usage:
> 
> Adding an observer to an observable uses the following method:
> observable.addObserver(observer);
> 
> It is possible to remove it:
> observable.removeObserver(observer);
> 
> or to get a set with all attached observers
> observable.getObservers()
> 
> * Remark:
> 
> The two assumptions above are not as restrictive as it might appear:
> 
> 1. It is easy to build a Class that contains several Observers as inner
classes
> that observe multiple Observable. (Similar to Listeners in Swing).
> 
> 2. It is possible that the String could contain XML, Json or another
serialized
> representation of a more complex data structure.
> As long as no true client/server separation is done, direct callbacks are
> possible (and later one could still add some RMI technology).
> 
> *** Formatter
> 
> A class that extends the abstract Formatter class can act as a wrapper
around
> an Observable to change the output text specific for different observers.
> Usually the text delivered to the update method of the observers is the
one
> defined by the observerText() method of the Observable.
> A Formatter now allows to
> 
> * Example: Share Portfolio
> 
> Assume that you have a Model that represents the SharePortfolio of a
Player
> (labelled CertificateModel).
> Now there could be two Observers in the GUI for that SharePortfolio:
> One could display the total percentage of the shares for one company (e.g.
> 40%, labelled percentViewer), whereas the other (called
> toolTipViewer) displays the exact compositon (20%P+1*10%+2*5%).
> 
> To achieve this one creates a Formatter<CertificateModel> that take the
> CertificateModel as one argument to its constructor and the required type
of
> output as the other argument (e.g. verbose=true/false).
> 
> Then the Observer would not be added to the Observable directly, but to
the
> Formatter objects, that wrap the Observable inside:
> 
> detailedCertificates.addObserver(toolTipViewer)
> percentageCertificates.addObserver(percentViewer)
> 
> * Another Example: BooleanState
> 
> As Unit Test I have defined a simple Formatter for a BooleanState that
> instead the default text ("true" versus "false") simply delivers an
alternative
> text representation ("yes" versus "no")
> 
> * Implementation / Usage
> 
> Again it is pretty simple:
> There is the abstract method observerText which has to be overwritten,
e.g.
> in the case of BooleanState above:
> 
> @Override
> public String observerText() {
>    if (state.value()) {
>      return "yes";
>    } else {
>      return "no";
>    }
> }
> 
> *** Current state of implementation
> Both Observer and Formatter are fully implemented and have unit tests
> attached.
> 
> 
>
----------------------------------------------------------------------------
--
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Rails2.0: Observer and Formatter

[Stefan F. <ste...@we...>]

After the recent discussion I have finalized the Observer Interface.
Related to this I present the Formatter (Abstract) Class that allows for 
different type of output from the identical Observable object.

As usual comments are very welcome, as things can still be changed
easily.

Stefan


*** Observer
I took two major decisions that (on a first glance) limits the 
flexibility, however simplifies the structure.

1. Each observer is only allowed to observe one Observable (reminder: 
this is either a State or a Model). However an observable can have many 
observers (so it is a n:1 relation).

2. The data transferred is always a String.

However this makes the Observer interface straightforward. There is only 
  ...

     (public) void update(String text);

... one method with one argument containing the updated data from the 
observed Observable.

This is called only once per ChangeSet activity (committing a new, undo, 
redo), and only if the Observable is changed by the ChangeSet(s) executed.

* Usage:

Adding an observer to an observable uses the following method:
observable.addObserver(observer);

It is possible to remove it:
observable.removeObserver(observer);

or to get a set with all attached observers
observable.getObservers()

* Remark:

The two assumptions above are not as restrictive as it might appear:

1. It is easy to build a Class that contains several Observers as inner 
classes that observe multiple Observable. (Similar to Listeners in Swing).

2. It is possible that the String could contain XML, Json or another 
serialized representation of a more complex data structure.
As long as no true client/server separation is done, direct callbacks 
are possible (and later one could still add some RMI technology).

*** Formatter

A class that extends the abstract Formatter class can act as a wrapper 
around an Observable to change the output text specific for different 
observers.
Usually the text delivered to the update method of the observers is the 
one defined by the observerText() method of the Observable.
A Formatter now allows to

* Example: Share Portfolio

Assume that you have a Model that represents the SharePortfolio of a 
Player (labelled CertificateModel).
Now there could be two Observers in the GUI for that SharePortfolio:
One could display the total percentage of the shares for one company 
(e.g. 40%, labelled percentViewer), whereas the other (called 
toolTipViewer) displays the exact compositon (20%P+1*10%+2*5%).

To achieve this one creates a Formatter<CertificateModel> that take the 
CertificateModel as one argument to its constructor and the required 
type of output as the other argument (e.g. verbose=true/false).

Then the Observer would not be added to the Observable directly, but to 
the Formatter objects, that wrap the Observable inside:

detailedCertificates.addObserver(toolTipViewer)
percentageCertificates.addObserver(percentViewer)

* Another Example: BooleanState

As Unit Test I have defined a simple Formatter for a BooleanState that 
instead the default text ("true" versus "false") simply delivers an 
alternative text representation ("yes" versus "no")

* Implementation / Usage

Again it is pretty simple:
There is the abstract method observerText which has to be overwritten, 
e.g. in the case of BooleanState above:

@Override
public String observerText() {
   if (state.value()) {
     return "yes";
   } else {
     return "no";
   }
}

*** Current state of implementation
Both Observer and Formatter are fully implemented and have unit tests 
attached.

Re: [Rails-devel] Rails2.0: States and Models as Observables

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

On Mon, Jul 9, 2012 at 11:43 AM, Stefan Frey <ste...@we...> wrote:
> As I prefer Python over Perl I usually prefer the easier design over the
> flexible design ;-)

You and me both. ;-)

Your additional explanation helps a lot. I have no objections to the design.

Thanks!

---Brett.

Re: [Rails-devel] Rails2.0: States and Models as Observables

[Stefan F. <ste...@we...>]

Erik,
thanks for your comments. Answers see below.
Stefan

On 07/09/2012 12:11 AM, Erik Vos wrote:
>
> Wouldn't it be better to use different class/interface names, to avoid
> confusion with the standard Java names Observable and Observer?
> Not that I have any good proposals.
> Publisher/Subscriber aren't wrong but sound a bit pompously here.
> Perhaps ObservableItem and ObservingItem or ObservingElement?

No I do not think that there is any confusion: That is exactly what java 
namespaces are for.

Did you know that there are 4 other classes named State in packages 
delivered with the java jdk? What you suggest to not use "State" for 
that reason?

>
>> Currently an Observer only provides an update(Observable obs, String
>> text) method. The latter argument provides a text update for the standard
>> cases.
>
> Did you consider the cases where currently a ViewObject is passed?  This can
> (in theory) contain anything that can be serialized (currently to a String
> only).
>

I am aware of those cases, but as I stated, I have not fully decided how 
to replace them. My preference would be to still have only Strings 
passed, as this would keep the interface between Observer and 
Observables easy.

In the longer run, the Strings can be complex XML or JSON expression, so 
it is not a real restriction. As a dirty workaround until a true 
client/server separation one could even use direct callbacks from the 
observer to the observable to transmit complex data.

>> I am wondering if I should add a proxy approach, such that the Observer
> can
>> specify a function which has to be called that can be specific for each
>> Observable observed. Or if I should be more restrictive and allow each
>> Observer to observe ONLY one observable, thus dropping the need to
>> specify the Observable in the interface method.
>
> Not sure what you mean here.
>

For the latter part of my paragraph above see my answer to Brett.
A proxy or delegate approach would add a Delegate object that would 
subscribe itself to the observable (and would be called on update()). 
However at the creation of the delegate the true observer could specify 
that it would prefer to have a different method called.

The use case is the following:
Assume you have an Observer that observes two Observables called A and 
B: Then instead of having one method update(Observable obs) and using if 
statements inside, it is possible to have two methods update_from_A() 
and update_from_B() inside the observer.

But as I prefer to rule that out, there is no need for such an approach.

Re: [Rails-devel] Rails2.0: States and Models as Observables

[Stefan F. <ste...@we...>]

Brett,
thanks for your comments. See answers below.
Stefan

>>
>> I consider the java.util.Observable/Observer implementation is not a
>> perfect fit for Rails, I preferred to write my own instead.
>
> Can you expand on this a bit more? What are the limitations that your
> version overcomes?
>

In my view (at several more competent others) it is not as easy to use 
as it can be with your own implementation.

The general issues I have, are that is a) non-generic (if one has to
use a data object at all), b) confusing to use (you have to do both 
setChanged and notifyObservers, there is no forcedNotification) and c) 
the update method of the Observer always always requires one Observable 
and a data object (which however can be null).

More details see e.g.
http://www2.sys-con.com/itsg/virtualcd/java/archives/0210/schwell/index.html

The rails specific issue is that the list of observers in 
java.util.Observable is not implemented as state variable, so it is not 
undo/redo-proof.

In general I believe that design patterns should not have a language 
implementation, as they are suggestions for good coding, not recipes for 
good coding. Thus you should incorporate the idea into your own code.

An excellent implementation (in terms of generality) is the one from 
PerfectJPattern: http://perfectjpattern.sourceforge.net/dp-observer.html
however it is easy to agree that in almost all cases it is a complete 
overkill.

>> However the Observer interface could potentially change, as I am stil
>> working on the needs and constraints of the existing GUI.
>>
>> Currently an Observer only provides an update(Observable obs, String
>> text) method. The latter argument provides a text update for the
>> standard cases.
>>
>> I am wondering if I should add a proxy approach, such that the Observer
>> can specify a function which has to be called that can be specific for
>> each Observable observed. Or if I should be more restrictive and allow
>> each Observer to observe ONLY one observable, thus dropping the need to
>> specify the Observable in the interface method.
>>
>
> In general, I would support the more flexible design. However, I'm not
> certain of the use cases here. Can you give some examples on why we'd
> prefer one design over the other?

I cannot give concrete examples yet, as I have not started to change the 
code seriously. However I am getting closer to the opinion that 
restricting that one observer can only observe one observable (so N:1 
from observers to observables) is a good idea: The consequence is that 
if an Observer wants to observe several Observables at the same time, 
this could be realized by creating a specific Model for that Observer.
And that is exactly the function of a Model that it combines the effect 
of several other observables (states/models).

As I prefer Python over Perl I usually prefer the easier design over the 
flexible design ;-)

Re: [Rails-devel] Rails2.0: States and Models as Observables

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

Stefan,

This all looks pretty good to me.

> I consider the java.util.Observable/Observer implementation is not a
perfect
> fit for Rails, I preferred to write my own instead.
> However the Observer interface could potentially change, as I am stil
working
> on the needs and constraints of the existing GUI.

Wouldn't it be better to use different class/interface names, to avoid
confusion with the standard Java names Observable and Observer?  
Not that I have any good proposals. 
Publisher/Subscriber aren't wrong but sound a bit pompously here.
Perhaps ObservableItem and ObservingItem or ObservingElement?
 
> Currently an Observer only provides an update(Observable obs, String
> text) method. The latter argument provides a text update for the standard
> cases.

Did you consider the cases where currently a ViewObject is passed?  This can
(in theory) contain anything that can be serialized (currently to a String
only).

> I am wondering if I should add a proxy approach, such that the Observer
can
> specify a function which has to be called that can be specific for each
> Observable observed. Or if I should be more restrictive and allow each
> Observer to observe ONLY one observable, thus dropping the need to
> specify the Observable in the interface method.

Not sure what you mean here.

Erik.

Re: [Rails-devel] Rails2.0: States and Models as Observables

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

On Sun, Jul 8, 2012 at 4:53 PM, Stefan Frey <ste...@we...> wrote:
> *** Current State of Implementation
>
> Observable/State/Model classes are fully specified, implemented and have
> unit tests added.
>
> I consider the java.util.Observable/Observer implementation is not a
> perfect fit for Rails, I preferred to write my own instead.

Can you expand on this a bit more? What are the limitations that your
version overcomes?

> However the Observer interface could potentially change, as I am stil
> working on the needs and constraints of the existing GUI.
>
> Currently an Observer only provides an update(Observable obs, String
> text) method. The latter argument provides a text update for the
> standard cases.
>
> I am wondering if I should add a proxy approach, such that the Observer
> can specify a function which has to be called that can be specific for
> each Observable observed. Or if I should be more restrictive and allow
> each Observer to observe ONLY one observable, thus dropping the need to
> specify the Observable in the interface method.
>

In general, I would support the more flexible design. However, I'm not
certain of the use cases here. Can you give some examples on why we'd
prefer one design over the other?

---Brett.

[Rails-devel] Rails2.0: States and Models as Observables

[Stefan F. <ste...@we...>]

This installment of the series on refactored classes in Rails 2.0 
discusses States and Models. Those are the core of both the undo/redo 
mechanism and the data/view separation of Rails.

I will cover the big picture of States and Models here, more details on 
the specific States and Models classes to follow in later mails and how 
to use them will follow in later mails.

As it is still on the abstract level, most likely only Erik will comment ;-)

Stefan

*** Object Hierarchy

Item (Interface)
|
Observable (Abstract Class)
|			|
State (Abstract Class) 	Model (Abstract Class)
|			|		
BooleanState		MoneyModel
...			...
and many more		and many more
(in State package)	(in Model package)

(Remark: Observable above is not java.util.Observable)

States being Items implies that they are elements inside the Rails Item 
tree. Example: hasFloated is a BooleanState of a PublicCompany.

So it is possible to locate the hasFloated state of PRR from the root 
node by calling the locate method: 
root.locate("/companies/PRR/hasFloated"). And this bypasses the fact 
that hasFloated and/or its getter/setter methods are declared private.
This makes implementing the "exception-to-the-general-rule" rules of 
some 18xx much easier.

*** Core ideas of States and Models

State classes usually take existing (or simple) constructs and wraps 
them with the mechanism required for undo/redo mechanisms.
Examples are BooleanState (wraps Boolean), HashMapState (wraps HashMap).

Model classes have no redo/undo mechanism of their own, they rely on 
embedded state objects for that.
For this Models can add themselves to States using state.addModel(Model 
m). If the Model is the parent of the State this is done automatically 
during construction of the State.

An example is a CashMoneyModel which embeds an IntegerState.

It is also possible that Model itself is based on another Model, an 
example for this is PresidentModel which relies on the CertificateModel.

By allowing those connections States and Models create a directed graph 
(in this case a forest == many disjoint trees) with states being the 
root nodes of each tree in the forest.

*** Creation of States and Models

The creation of States and Models usually uses the following patterns:

State.create(Item parent, String id)
to initialize with a (sensible) default value.

State.create(Item parent, String id, [Object] init)
to initialize with a specified initial value.

In some cases (especially models) an id is a predefined and the parent 
class is specialized.

Example:
PresidentModel.create(PublicCompany parent)
Here the id is automatically set to "PresidentModel" and the parent has 
to be a PublicCompany.

*** Observable/Observer mechanism
By deriving from Observable State and Model both share the property that 
they can be observed by other Rails (usually) GUI elements. Those have 
to implement the Observer Interface and add themselves to States/Models 
using state/model.addObserver(Observer o)

Observers get only updated once per (Action)ChangeSet. Thus we avoid 
multiple updates of the GUI during the processing of an action.
This update only occurs AFTER closing the open (Action)ChangeSet.

This is different to when the State itself changes it value: This occurs 
immediately after the change of the State. The same is true for Models 
that are connected with those State, they are informed about the new 
values, thus could and should update their value as well.

Examples:
1. hasFloated BooleanState

If hasFloated.set(true) is executed the following happens:
* hasFloated changes its value to true (thus hasFloated.value() returns 
true).
* A BooleanChange is added to the current ChangeSet to store that change.
* However no update is send to a potential Observer. This is delayed 
until the ChangeSet closes.

2. CashMoneyModel treasury
This stores the amount of cash in companies treasury: It embeds
an IntegerState called value to store the amount of money.

If treasury.change(-100) is executed the following happens:
* The IntegerState value is changed to -100.
* An IntegerState change is added to the current ChangeSet.
* The CashMoneyModel treasury is informed that the value has changed.
* However no update is send to a potential Observers. Again this is 
delayed until the ChangeSet closes.

The reason behind this is to avoid multiple updates of GUI elements 
during the processing of the GameAction. Only after all processing is 
finished, the Observers of all effected States and Models get informed 
only once. It is also possible to roll-back the ChangeSet without having 
intermediate updates of the GUI.
This makes a potential client/server communication much more efficient.

*** Comparison to Rails 1.x

In Rails 1.x the general hierarchy was:
java.util.observable
|
ModelObject
|
State

So State was a specialized ModelObject. This has been changed, so that 
State and Model have clearly separated roles, but both are still 
Observables.

Another issue was that several State subclasses did not inherit from 
State, but from ModelObject or from neither.

*** Current State of Implementation

Observable/State/Model classes are fully specified, implemented and have 
unit tests added.

I consider the java.util.Observable/Observer implementation is not a 
perfect fit for Rails, I preferred to write my own instead.
However the Observer interface could potentially change, as I am stil
working on the needs and constraints of the existing GUI.

Currently an Observer only provides an update(Observable obs, String 
text) method. The latter argument provides a text update for the 
standard cases.

I am wondering if I should add a proxy approach, such that the Observer 
can specify a function which has to be called that can be specific for 
each Observable observed. Or if I should be more restrictive and allow 
each Observer to observe ONLY one observable, thus dropping the need to 
specify the Observable in the interface method.

Re: [Rails-devel] Rails2.0: ChangeStack and ChangeSet

[Stefan F. <ste...@we...>]

Erik:
thanks for your comments: Some quick replies, see below.
Stefan

 >
>> Remark: This is different to Rails1.x, for which some State changes could
> get
>> lost, as there was no open ChangeSet available at the time of processing.
>
> The explicit opening and closing of MoveSets was intentional, to make sure
> that no changes would exist outside of the "change window" after receiving
> and validating a player action.
> Just a matter of trying to ensure some programming discipline: any change
> outside that window was considered illegal.
> Unfortunately, I never got to catch such illegal changes, so the only way to
> find these errors was inspecting the logs.
> (This omission has been the cause of several undo bugs, so this incomplete
> cure may have been worse than the disease.)
>
> In fact you are dropping this change window concept, allowing changes at any
> time.  Two further comments on that:
>
> 1. You no longer can enforce that no changes are done before validation is
> complete.  Any such premature changes will now end up in an open
> AutoChangeSet.
> I would prefer an approach where whatever changeset is open would be closed
> before the engine passes control back to the UI, and any premature changes
> when no changeset is open should be catched somehow, perhaps by throwing an
> exception. I'm not sure if that is practical, however; if not, I may have to
> settle with your approach, although somewhat reluctantly.
>

It is possible to add that behavior, by adding an explicit lock to the 
ChangeStack. Maybe we could even make the behavior then different in 
development (fail) and production (only error in log). For me that is 
not a property of the ChangeSet, but more of the ChangeStack itself.
Then you could lock e.g. during validations.

I did not spec it until now, as it was not correctly implemented in 
Rails1.x and was more a source of errors than a feature.

For me this is different to open and close of ChangeSets (open means 
that ChangeSet accepts additional changes, closed means that it will 
NEVER accept any additional changes).

> 2. I'm not sure if 'action' and 'auto' changes can be separated so easily,
> in the sense that the latter always follow the former. Did you check that?
> I'm particularly thinking of special cases like the CGR formation, where
> player and auto actions seem rather intertwined to me.

It is not easy in ALL cases, but it is easy in MOST cases. And as it 
only informational value, it is not an issue if it is done wrong.

It will be
* Start ActionChangeSet (closes AutoChangeSet)
* Process Action
* Close ActionChangeSet (opens AutoChangeSet)
* Game Processing
* Start ActionChangeSet (closes AutoChangeSet)
* Process Action
and so on...

Game Processing could be split in separate parts
* Last Action in SR processed
* AutoChangeSet open
* End of StockRound in-game processing (e.g. share price changes due to 
shares sold out)
* Open next AutoChangeSet
* In-Game OR processing (e.g. income of privates)
* Start ActionChangeSet
* Process Tile Lay Action
and so on...

The "base" functionality of ActionChangeSet and AutoChangeSet is 
identical, it merely defines the "owner" of changes and this could be 
used in displaying user comments and the game reports.

What I have not mentioned so far is I intend to make user Comments and 
Report Text (sub-)components of the ChangeSets in future Rails2.0 
development.

>
> 3. Do you still link change sets so that these can only be undone as a
> whole?
>

There is an implicit link of ActionChangeSets to AutoChangeSets as 
undo/redo will always jump to the next action. So all AutoChangeSets 
will be undone automatically.
I consider linking ActionChangeSets that belong to separate actions as 
harmful, as in my opinion it always indicate an inherent undo problem, 
which should be fixed instead of artificially linking the actions.

Re: [Rails-devel] Rails2.0: ChangeStack and ChangeSet

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

Hi Stefan,

Just a few comments.

> Remark: I changed the term "Move" in Rails1.x to the term "Change" in
> Rails2.0 to avoid the confusion with an in-game tile move or token move.
> ChangeStack and ChangeSet are MoveStack and MoveSet in Rails1.x.

I agree that Change is better than Move.

> Remark: This is different to Rails1.x, for which some State changes could
get
> lost, as there was no open ChangeSet available at the time of processing.

The explicit opening and closing of MoveSets was intentional, to make sure
that no changes would exist outside of the "change window" after receiving
and validating a player action.
Just a matter of trying to ensure some programming discipline: any change
outside that window was considered illegal.
Unfortunately, I never got to catch such illegal changes, so the only way to
find these errors was inspecting the logs. 
(This omission has been the cause of several undo bugs, so this incomplete
cure may have been worse than the disease.)

In fact you are dropping this change window concept, allowing changes at any
time.  Two further comments on that:

1. You no longer can enforce that no changes are done before validation is
complete.  Any such premature changes will now end up in an open
AutoChangeSet.
I would prefer an approach where whatever changeset is open would be closed
before the engine passes control back to the UI, and any premature changes
when no changeset is open should be catched somehow, perhaps by throwing an
exception. I'm not sure if that is practical, however; if not, I may have to
settle with your approach, although somewhat reluctantly.

2. I'm not sure if 'action' and 'auto' changes can be separated so easily,
in the sense that the latter always follow the former. Did you check that?
I'm particularly thinking of special cases like the CGR formation, where
player and auto actions seem rather intertwined to me.

3. Do you still link change sets so that these can only be undone as a
whole?

Apart from these comments, I generally like your changes.
 
Erik. 

[Rails-devel] Rails2.0: ChangeStack and ChangeSet

[Stefan F. <ste...@we...>]

Below I discuss the per-requisites of the State mechanism. The latter 
will be covered in a soon-to-follow email.
So most likely the only one interested in the bits below will be Erik.

Stefan

Remark: I changed the term "Move" in Rails1.x to the term "Change" in 
Rails2.0 to avoid the confusion with an in-game tile move or token move.
ChangeStack and ChangeSet are MoveStack and MoveSet in Rails1.x.

*** So how do State objects work in Rails internally?
Assume a BooleanState variable was created: If the boolean value is 
changed by e.g. stateVariable.set(true), an object of a Change subclass 
is created (here a BooleanChange). The change object contains both links 
to the state and the old and the new variable.
The change object then is added to the ChangeStack, which is located 
inside the StateManager.

*** The redesigned ChangeStack:
* Changes get collected in ChangeSets, where are two types of ChangeSets:
- ActionChangeSet (all Changes associated with an action)
- AutoChangeSet (all Changes during  automated processing)

* ChangeSets can be open=accepting new Changes or closed=raise errors
if one tries to add Changes.

* The current ChangeSet of the ChangeStack is always open. If the 
current ChangeSet is closed, a new (Auto)ChangeSet is automatically 
opened and is the new current ChangeSet of the ChangeStack.

Remark: This is different to Rails1.x, for which some State changes 
could get lost, as there was no open ChangeSet available at the time of 
processing.

* At the start of the game an AutoChangeSet created which is defined the 
terminal, thus it is not undoable.
This collects all changes that precede any player action.

* The typical sequence is the following:
Player action is processed:
ChangeStack.startActionChangeSet(player, action)
opens a new ActionChangeSet (and closes the current AutoChangeSet 
automatically)

After processing the action:
ChangeStack.closeCurrentChangeSet()
closes the current ActionChangeSet (and opens a new AutoChangeSet)

Then the games process non-action related changes (e.g. ending the SR, 
starting a new OR, paying revenue to privates, etc.) all of this gets 
collected into AutoChangeSet(s).

* The major advantage of the separation of changes is that it will allow 
to link output in the report window and player comments to either a 
player action or the automated game processing.

Currently all output of the game engine is linked to the previous player 
action, however this is only based on game sequence and not on game logic.

* Still undo/redo will always un-execute/re-execute the next player 
action (including all automated changes).

* An internal change is that there are are now two stacks (one for undo, 
one for redo), this avoids the usage of an index that separates the 
undo-part from the redo-part if using one stack only.

Thus an undo command the top ChangeSet of the undo-stack onto the redo 
stack and the reverse for redos.

The current (open) ChangeSet is stored in a separately as long as it is 
open, it only gets moved onto the undo stack after its close.
Thus all ChangeSets on the undo (and redo) stack are always closed.

* Setting up of the ChangeStack:
The ChangeStack is automatically setup to full functionality after 
creating the Root:

So Root root = Root.create()
will have working ChangeStack inside.

If one adds a state now, e.g.
BooleanState state = BooleanState.create(root, "example")
every change of that state is put on the according ChangeStack.

The ChangeStack is unique to the Root item hierarchy, however it is 
possible to create several roots with each having its own independent 
ChangeStack.

Access to the ChangeStack:
 From root: root.getStateManager().getChangeStack()

 From any item:
item.getRoot().getStateManager().getChangeStack()

* Current state of implementation:
The core functionality is working and covered by tests (see 
ChangeStackTest and ChangeSetTest).

Re: [Rails-devel] Fwd: Hosted Apps Retirement

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

In the blog they mention some options (e.g. Wordpress), and I understand
that more detailed migration suggestions/instructions are coming.  Perhaps
we'll await that?
I have no experience with wiki s/w packages, so I can't be of much help.

Erik.


> -----Original Message-----
> From: brett lentz [mailto:wak...@gm...]
> Sent: Tuesday, July 03, 2012 5:16 PM
> To: rai...@li...
> Subject: [Rails-devel] Fwd: Hosted Apps Retirement
> 
> Stefan, Erik -
> 
> Thoughts/Ideas on where to migrate our wiki, which appears to be the main
> affected app?
> 
> ---Brett.
> 
> 
> 
> ---------- Forwarded message ----------
> From: SourceForge.net Team <no...@so...>
> Date: Tue, Jul 3, 2012 at 10:22 AM
> Subject: Hosted Apps Retirement
> 
> In case you missed it ...
> 
> We wanted to be sure you were aware of some upcoming changes to the
> SourceForge project hosting service.
> 
> One or more of your projects use the Hosted Apps service. On September 1,
> 2012, the Hosted Apps service will reach the end of its life and be shut
down.
> The reasons for this are discussed in the blog post, at
> http://sourceforge.net/blog/hosted-apps-retirement/  and in the wiki, at
> https://sourceforge.net/p/forge/community-
> docs/Hosted%20Apps%20Retirement/
> 
> 
> Over the coming days, we'll be publishing more documents about how to
> migrate your apps to your own project web space, so that none of your data
> is lost in this transition. We want to be sure that your project can
continue to
> operate without interruption, so if you have any concerns, difficulty with
> migration, or just want to chat, please send us a note
> (com...@so...).
> 
> Please watch the wiki page
> (https://sourceforge.net/p/forge/community-
> docs/Hosted%20Apps%20Retirement/)
> for further updates about this process. We'll be back in touch as it gets
closer
> to the deadline, or if anything about the plan changes.
> 
> Thanks again for being part of the SourceForge community.
> 
> ----------------------------------------------------------------------
> SourceForge.net has made this mailing to you as a registered user of the
> SourceForge.net site to convey important information regarding your
> SourceForge.net account or your use of SourceForge.net services.
> 
> We make a small number of directed mailings to registered users each year
> regarding their account or data, to help preserve the security of their
account
> or prevent loss of data or service access.
> 
> If you have concerns about this mailing please contact our Support team
per:
> http://sourceforge.net/support
> 
>
----------------------------------------------------------------------------
--
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and threat
> landscape has changed and how IT managers can respond. Discussions will
> include endpoint security, mobile security and the latest in malware
threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Fwd: Hosted Apps Retirement

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

Stefan, Erik -

Thoughts/Ideas on where to migrate our wiki, which appears to be the
main affected app?

---Brett.



---------- Forwarded message ----------
From: SourceForge.net Team <no...@so...>
Date: Tue, Jul 3, 2012 at 10:22 AM
Subject: Hosted Apps Retirement

In case you missed it ...

We wanted to be sure you were aware of some upcoming changes to the
SourceForge project hosting service.

One or more of your projects use the Hosted Apps service. On September 1,
2012, the Hosted Apps service will reach the end of its life and be shut
down. The reasons for this are discussed in the blog post, at
http://sourceforge.net/blog/hosted-apps-retirement/  and in the wiki, at
https://sourceforge.net/p/forge/community-docs/Hosted%20Apps%20Retirement/


Over the coming days, we'll be publishing more documents about how to
migrate your apps to your own project web space, so that none of your data
is lost in this transition. We want to be sure that your project can
continue to operate without interruption, so if you have any concerns,
difficulty with migration, or just want to chat, please send us a note
(com...@so...).

Please watch the wiki page
(https://sourceforge.net/p/forge/community-docs/Hosted%20Apps%20Retirement/)
for further updates about this process. We'll be back in touch as it gets
closer to the deadline, or if anything about the plan changes.

Thanks again for being part of the SourceForge community.

----------------------------------------------------------------------
SourceForge.net has made this mailing to you as a registered user of
the SourceForge.net site to convey important information regarding
your SourceForge.net account or your use of SourceForge.net services.

We make a small number of directed mailings to registered users each
year regarding their account or data, to help preserve the security of
their account or prevent loss of data or service access.

If you have concerns about this mailing please contact our Support
team per: http://sourceforge.net/support

Re: [Rails-devel] Rules Clarifications, variant links in Rails

[Mike B. <com...@ip...>]

Would happily do it but I don't have the time. I'm only sleeping 3-5 hrs a
night as it is.

 

Mike Bourke

Campaign Mastery http://www.campaignmastery.com
<http://www.campaignmastery.com/> 

Co-author, Assassin's Amulet  <http://www.legaciescampaignsetting.com/>
http://www.legaciescampaignsetting.com

  _____  

From: Dr....@t-... [mailto:Dr....@t-...] 
Sent: Tuesday, 3 July 2012 9:25 PM
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Rules Clarifications, variant links in Rails

 

Hm,

 

we got a volunteer maybe ? :) points @ Mike

 

Regards,

Martin

 

Von: "Mike Bourke" <com...@ip...>
An: "'Development list for Rails: an 18xx game'"
<rai...@li...>
Betreff: Re: [Rails-devel] Rails 1.7.7 1856 bug - CGR president's
certificate
Datum: Tue, 03 Jul 2012 10:00:22 +0200

I would like to see such links and statements of variant provided within the
game itself, even if only in a separate document included within the zip. It
would not only be a useful resource to players but also would assist in
reducing false bug reports (of which I have made my share, lest anyone think
I am referring exclusively to the current discussion thread.

Mike Bourke
Campaign Mastery http://www.campaignmastery.com
Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Tuesday, 3 July 2012 2:58 PM
To: rai...@li... <javascript:void(0)> 
Subject: Re: [Rails-devel] Rails 1.7.7 1856 bug - CGR president's
certificate

Agree that this is not a bug, if I am not mistaken this is covered
by bullet point three in Steve Thomas list of clarifications
compare http://www.18xx.net/1856/1856f.htm

Maybe we could link that from the Rails wiki (if it is not already there).

Potentially we could add the FAQ pages and clarifications for 1830 and 
1835 as well, but this would require to state which variant we follow 
for those issues which are still ambiguous.

Stefan



---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 120702-1, 02/07/2012
Tested on: 3/07/2012 6:00:23 PM
avast! - copyright (c) 1988-2012 AVAST Software.
http://www.avast.com




----------------------------------------------------------------------------
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Rails-devel mailing list
Rai...@li... <javascript:void(0)> 
https://lists.sourceforge.net/lists/listinfo/rails-devel

 




---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 120702-1, 02/07/2012
Tested on: 3/07/2012 9:39:22 PM
avast! - copyright (c) 1988-2012 AVAST Software.
http://www.avast.com

Re: [Rails-devel] Rules Clarifications, variant links in Rails

[<Dr....@t-...>]

Hm, 

	we got a volunteer maybe ? :) points @ Mike 

	Regards, 

	Martin  

	  Von: "Mike Bourke" <com...@ip...>
 An: "'Development list for Rails: an 18xx game'"
<rai...@li...>
 Betreff: Re: [Rails-devel] Rails 1.7.7 1856 bug - CGR president's
certificate
 Datum: Tue, 03 Jul 2012 10:00:22 +0200

 I would like to see such links and statements of variant provided
within the
 game itself, even if only in a separate document included within the
zip. It
 would not only be a useful resource to players but also would assist
in
 reducing false bug reports (of which I have made my share, lest
anyone think
 I am referring exclusively to the current discussion thread.

 Mike Bourke
 Campaign Mastery http://www.campaignmastery.com [1]
 Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com
[2]

 -----Original Message-----
 From: Stefan Frey [mailto:ste...@we...] 
 Sent: Tuesday, 3 July 2012 2:58 PM
 To: rai...@li... [3]
 Subject: Re: [Rails-devel] Rails 1.7.7 1856 bug - CGR president's
 certificate

 Agree that this is not a bug, if I am not mistaken this is covered
 by bullet point three in Steve Thomas list of clarifications
 compare http://www.18xx.net/1856/1856f.htm [4]

 Maybe we could link that from the Rails wiki (if it is not already
there).

 Potentially we could add the FAQ pages and clarifications for 1830
and 
 1835 as well, but this would require to state which variant we follow

 for those issues which are still ambiguous.

 Stefan

 ---
 avast! Antivirus: Outbound message clean.
 Virus Database (VPS): 120702-1, 02/07/2012
 Tested on: 3/07/2012 6:00:23 PM
 avast! - copyright (c) 1988-2012 AVAST Software.
 http://www.avast.com [5]

 ------------------------------------------------------------------------------
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and 
 threat landscape has changed and how IT managers can respond.
Discussions 
 will include endpoint security, mobile security and the latest in
malware 
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
[6]
 _______________________________________________
 Rails-devel mailing list
 Rai...@li... [7]
 https://lists.sourceforge.net/lists/listinfo/rails-devel [8]

Links:
------
[1] ?ctl=dereferer&amp;to=aHR0cDovL3d3dy5jYW1wYWlnbm1hc3RlcnkuY29t
[2]
?ctl=dereferer&amp;to=aHR0cDovL3d3dy5sZWdhY2llc2NhbXBhaWduc2V0dGluZy5jb20%3D
[3] javascript:void(0)
[4]
?ctl=dereferer&amp;to=aHR0cDovL3d3dy4xOHh4Lm5ldC8xODU2LzE4NTZmLmh0bQ%3D%3D
[5] ?ctl=dereferer&amp;to=aHR0cDovL3d3dy5hdmFzdC5jb20%3D
[6]
?ctl=dereferer&amp;to=aHR0cDovL3d3dy5hY2NlbGFjb21tLmNvbS9qYXcvc2ZybmwwNDI0MjAxMi8xMTQvNTAxMjIyNjMv
[7] javascript:void(0)
[8]
?ctl=dereferer&amp;to=aHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vcmFpbHMtZGV2ZWw%3D

Re: [Rails-devel] Rails 1.7.7 1856 bug - CGR president's certificate

[Mike B. <com...@ip...>]

I would like to see such links and statements of variant provided within the
game itself, even if only in a separate document included within the zip. It
would not only be a useful resource to players but also would assist in
reducing false bug reports (of which I have made my share, lest anyone think
I am referring exclusively to the current discussion thread.

Mike Bourke
Campaign Mastery http://www.campaignmastery.com
Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Tuesday, 3 July 2012 2:58 PM
To: rai...@li...
Subject: Re: [Rails-devel] Rails 1.7.7 1856 bug - CGR president's
certificate

Agree that this is not a bug, if I am not mistaken this is covered
by bullet point three in Steve Thomas list of clarifications
compare http://www.18xx.net/1856/1856f.htm

Maybe we could link that from the Rails wiki (if it is not already there).

Potentially we could add the FAQ pages and clarifications for 1830 and 
1835 as well, but this would require to state which variant we follow 
for those issues which are still ambiguous.

Stefan



---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 120702-1, 02/07/2012
Tested on: 3/07/2012 6:00:23 PM
avast! - copyright (c) 1988-2012 AVAST Software.
http://www.avast.com

Re: [Rails-devel] Rails 1.7.7 1856 bug - CGR president's certificate

[Stefan F. <ste...@we...>]

Agree that this is not a bug, if I am not mistaken this is covered
by bullet point three in Steve Thomas list of clarifications
compare http://www.18xx.net/1856/1856f.htm

Maybe we could link that from the Rails wiki (if it is not already there).

Potentially we could add the FAQ pages and clarifications for 1830 and 
1835 as well, but this would require to state which variant we follow 
for those issues which are still ambiguous.

Stefan

On 07/03/2012 04:46 AM, John David Galt wrote:
> Kevin J. Price wrote:
>>> It looks like the game is configured so that the President's certificate counts
>>> as a single certificate, even if the CGR issues its second set of shares.
>>>
>>> The rules are admittedly slightly ambiguous on this, but I'm fairly certain the
>>> intent is that each certificate, including the president's certificate, counts
>>> as half a cert.
>>>
>>> Do you agree that this is a bug, or are you interpreting the rules otherwise?
>
> On 2012-07-02 11:37, Mike Bourke wrote:
>> Presidency, including that of the CGR, is always a double share. If the second
>> set of shares is issued, each regular cert is 5% and the president’s cert is
>> 10%, for a total of 18+1=19 certs. If not, each is 10% and the President’s
>> share is 20%, for a total of 8+1=9 certs.
>
> Correction: I hit Send too soon.
>
> True but not on point.  Kevin is talking about how each CGR certificate is
> supposed to be "counted" against each player's certificate limit.
>
> I do not agree with Kevin that this is a bug.  The single shares of CGR are
> supposed to count as half certificates if they are 5% each, but since the
> president's certificate is two shares (as Mike said) it counts as one whole
> certificate whether it is 10% or 20%.  I see no bug.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>