rails-devel — List for discussion of Rails development

Re: [Rails-devel] Undo / Redo design

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

I think that looks like it would hit most of the important points I
was thinking of.

I think that might work.

---Brett.


On 7/17/06, Erik Vos <eri...@hc...> wrote:
> Please also keep in mind, that some actions sometimes have side effects
> of a different nature. For instance, buying the first 4-train
> rusts all 2-trains. Undoing this buy also must move all these 2-trains
> back from the bit bucket (actually a Bank portfolio named scrapHeap)
> to the companies that last owned these.
> All these side effects must be done and undone as one action!
>
> It is not practical to define separate action classes for each possible
> combination of direct and indirect effects. It is much easier
> to work with very simple "movements" or whatever you would
> like to call these subactions.
>
> So I would propose:
> - An Action class, with do() and undo() methods, containing an
> ArrayList of Move objects.
> - An abtract Move class, which is the parent of all concrete Moves.
> - A bunch of XxxMove class, e.g. CashMove, TileMove, CertificateMove
> etc., each of which represents a specific type of minimal change.
> Each of the Move objects would also have do() and undo() methods,
> undo() being identical to do() with to and from swapped.
>
> Action.do() would call the do() method of each of the
> contained Move objects. Similar with undo.
>
> Erik.
>
> > -----Original Message-----
> > From: rai...@li...
> > [mailto:rai...@li...] On Behalf
> > Of brett lentz
> > Sent: 17 July 2006 20:44
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] Undo / Redo design
> >
> > I was just thinking, that there's another option that exists.
> >
> > I'm thinking that it probably will require more work than the other
> > options, but it may be beneficial for us to do it because of the
> > advantages in simplifying some of the complexity of the application.
> >
> > We can define a parent object (Action) and/or interface (Actionable)
> > for our model objects to inherit from.
> >
> > Each object then, inherits a basic Do and Undo methods that can be
> > overridden when needed.  For classes that do more than one thing, the
> > Do method can take the name of the action to take, and call the
> > associated methods that will take the desired action.
> >
> > Then, the UI code can be reworked to call these Do and Undo methods
> > and we can make all other methods private to prevent them from being
> > called directly.
> >
> > >From there, we can create a stack and assure that each Do method adds
> > its parent object to the stack. This makes Undoing a matter of popping
> > the object off the stack and calling the Undo method. Any calling
> > parameters can be accessed via an array held by the object.
> >
> >
> > ---Brett
> >
> > On 7/17/06, Erik Vos <eri...@hc...> wrote:
> > > I have also thought about this subject in the past weeks.
> > >
> > > Usually an action falls apart in several sub-action
> > > (which I tend to call moves). An Action can contain any
> > > number of moves; the determining factor is which combination
> > > of moves constitute an "atomic" action, i.e. a series of
> > > moves (changes) that must be executed and possibly undone
> > as a whole.
> > >
> > > For instance, selling a share involves at least:
> > > 1. The movement of a certificate from a player's portfolio
> > > to the Bank Pool (another rportfolio),
> > > 2. The movement of some cash from the Bank to the selling
> > > player (both are CashHolders).
> > > 3. A price drop, accompanied by the movement of the
> > > company's token on the Stock Chart.
> > >
> > > One could express this in XML as follows (this does not mean
> > > that I want to store the Undo stack in that way, although
> > > it is an option):
> > > <Action>
> > >   <MoveCertificate company=PRR seqno=2 from=Player-1 to=Pool/>
> > >   <MoveCash amount=67 from=bank to=Player-1/>
> > >   <MovePrice company=PRR from=G6 to=G7/>
> > > </Action>
> > >
> > > For many type of actions this is easy to implement, as many
> > > movements already exist in much this way in the existing code
> > > (see for instance Bank.transferCash() and
> > Portfolio.transferCertificate()).
> > > Of course, it becomes tricky when state changes enter the picture.
> > > For instance, a just floated company must be unfloated in an Undo,
> > > and such an activity does not yet exist.
> > >
> > > I am thinking to build up an Action gradually.
> > > As soon as the user's request has been validated in StockRound or
> > > OperationRound, Action.start() is called, which creates a
> > new (empty)
> > > Action object.
> > > Then the changes are executed, each being registered in the
> > > Action object as additional moves,
> > > e.g. with Action.add(new MoveCash (...)).
> > > Finally Action.end() is called, closing the action (and perhaps
> > > executing it, see below).
> > >
> > > Action.undo() should then undo the last action.
> > >
> > > Stacking can be easily added this way.
> > >
> > > One main decision to take is whether the changes should be executed
> > > parallel to creating the Action object (so that the existing code
> > > remains much the same), or that it is the Action object that,
> > > when finished, actually performs the changes.
> > >
> > > Perhaps the latter option is better, as it enforces developers
> > > to implement all changes, including state changes, in a
> > symmetric way.
> > >
> > > I think this is a similar (or perhaps the same) choice as you
> > > have presented below.
> > >
> > > Erik.
> > >
> > >
> > > > -----Original Message-----
> > > > From: rai...@li...
> > > > [mailto:rai...@li...] On Behalf
> > > > Of brett lentz
> > > > Sent: 17 July 2006 07:31
> > > > To: Development list for Rails: an 18xx game
> > > > Subject: [Rails-devel] Undo / Redo design
> > > >
> > > > I've been thinking about how to approach implementing Undo/Redo.
> > > >
> > > > It seems to me that there are two basic strategies that we
> > > > can attempt.
> > > >
> > > > In each of them, we need to create a stack to store
> > actions. Then, we
> > > > can place the stack in front of or after the code to execute the
> > > > action.
> > > >
> > > > The basic flow would look something like this:
> > > >
> > > > Stack before Action (Stack as EventHandler):
> > > > 1. Stack object receives call from UI to take an action.
> > > > 2. Stack stores action taken
> > > > 3. Stack object calls model object to resolve action.
> > > >
> > > > Stack after Action (Stack as a Listener):
> > > > 1. Model code receives call to act.
> > > > 2. Model resolves action
> > > > 3. Model notifies Stack object of action just taken.
> > > >
> > > >
> > > > I haven't really done much of an analysis of which
> > approach would be
> > > > more work or have additional implications.  There also
> > could be other
> > > > approaches I haven't thought of, as well.
> > > >
> > > > What are your thoughts on this?  Is there a solution with an
> > > > obvious advantage?
> > > >
> > > >
> > > > ----Brett.
> > > >
> >
> > --------------------------------------------------------------
> > -----------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the
> > chance to share your
> > opinions on IT & business topics through brief surveys -- and
> > earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge
> > &CID=DEVDEV
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Undo / Redo design

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

Please also keep in mind, that some actions sometimes have side effects
of a different nature. For instance, buying the first 4-train
rusts all 2-trains. Undoing this buy also must move all these 2-trains
back from the bit bucket (actually a Bank portfolio named scrapHeap) 
to the companies that last owned these.
All these side effects must be done and undone as one action!

It is not practical to define separate action classes for each possible
combination of direct and indirect effects. It is much easier
to work with very simple "movements" or whatever you would
like to call these subactions.

So I would propose:
- An Action class, with do() and undo() methods, containing an
ArrayList of Move objects.
- An abtract Move class, which is the parent of all concrete Moves.
- A bunch of XxxMove class, e.g. CashMove, TileMove, CertificateMove
etc., each of which represents a specific type of minimal change.
Each of the Move objects would also have do() and undo() methods,
undo() being identical to do() with to and from swapped.

Action.do() would call the do() method of each of the 
contained Move objects. Similar with undo.

Erik.

> -----Original Message-----
> From: rai...@li... 
> [mailto:rai...@li...] On Behalf 
> Of brett lentz
> Sent: 17 July 2006 20:44
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Undo / Redo design
> 
> I was just thinking, that there's another option that exists.
> 
> I'm thinking that it probably will require more work than the other
> options, but it may be beneficial for us to do it because of the
> advantages in simplifying some of the complexity of the application.
> 
> We can define a parent object (Action) and/or interface (Actionable)
> for our model objects to inherit from.
> 
> Each object then, inherits a basic Do and Undo methods that can be
> overridden when needed.  For classes that do more than one thing, the
> Do method can take the name of the action to take, and call the
> associated methods that will take the desired action.
> 
> Then, the UI code can be reworked to call these Do and Undo methods
> and we can make all other methods private to prevent them from being
> called directly.
> 
> >From there, we can create a stack and assure that each Do method adds
> its parent object to the stack. This makes Undoing a matter of popping
> the object off the stack and calling the Undo method. Any calling
> parameters can be accessed via an array held by the object.
> 
> 
> ---Brett
> 
> On 7/17/06, Erik Vos <eri...@hc...> wrote:
> > I have also thought about this subject in the past weeks.
> >
> > Usually an action falls apart in several sub-action
> > (which I tend to call moves). An Action can contain any
> > number of moves; the determining factor is which combination
> > of moves constitute an "atomic" action, i.e. a series of
> > moves (changes) that must be executed and possibly undone 
> as a whole.
> >
> > For instance, selling a share involves at least:
> > 1. The movement of a certificate from a player's portfolio
> > to the Bank Pool (another rportfolio),
> > 2. The movement of some cash from the Bank to the selling
> > player (both are CashHolders).
> > 3. A price drop, accompanied by the movement of the
> > company's token on the Stock Chart.
> >
> > One could express this in XML as follows (this does not mean
> > that I want to store the Undo stack in that way, although
> > it is an option):
> > <Action>
> >   <MoveCertificate company=PRR seqno=2 from=Player-1 to=Pool/>
> >   <MoveCash amount=67 from=bank to=Player-1/>
> >   <MovePrice company=PRR from=G6 to=G7/>
> > </Action>
> >
> > For many type of actions this is easy to implement, as many
> > movements already exist in much this way in the existing code
> > (see for instance Bank.transferCash() and 
> Portfolio.transferCertificate()).
> > Of course, it becomes tricky when state changes enter the picture.
> > For instance, a just floated company must be unfloated in an Undo,
> > and such an activity does not yet exist.
> >
> > I am thinking to build up an Action gradually.
> > As soon as the user's request has been validated in StockRound or
> > OperationRound, Action.start() is called, which creates a 
> new (empty)
> > Action object.
> > Then the changes are executed, each being registered in the
> > Action object as additional moves,
> > e.g. with Action.add(new MoveCash (...)).
> > Finally Action.end() is called, closing the action (and perhaps
> > executing it, see below).
> >
> > Action.undo() should then undo the last action.
> >
> > Stacking can be easily added this way.
> >
> > One main decision to take is whether the changes should be executed
> > parallel to creating the Action object (so that the existing code
> > remains much the same), or that it is the Action object that,
> > when finished, actually performs the changes.
> >
> > Perhaps the latter option is better, as it enforces developers
> > to implement all changes, including state changes, in a 
> symmetric way.
> >
> > I think this is a similar (or perhaps the same) choice as you
> > have presented below.
> >
> > Erik.
> >
> >
> > > -----Original Message-----
> > > From: rai...@li...
> > > [mailto:rai...@li...] On Behalf
> > > Of brett lentz
> > > Sent: 17 July 2006 07:31
> > > To: Development list for Rails: an 18xx game
> > > Subject: [Rails-devel] Undo / Redo design
> > >
> > > I've been thinking about how to approach implementing Undo/Redo.
> > >
> > > It seems to me that there are two basic strategies that we
> > > can attempt.
> > >
> > > In each of them, we need to create a stack to store 
> actions. Then, we
> > > can place the stack in front of or after the code to execute the
> > > action.
> > >
> > > The basic flow would look something like this:
> > >
> > > Stack before Action (Stack as EventHandler):
> > > 1. Stack object receives call from UI to take an action.
> > > 2. Stack stores action taken
> > > 3. Stack object calls model object to resolve action.
> > >
> > > Stack after Action (Stack as a Listener):
> > > 1. Model code receives call to act.
> > > 2. Model resolves action
> > > 3. Model notifies Stack object of action just taken.
> > >
> > >
> > > I haven't really done much of an analysis of which 
> approach would be
> > > more work or have additional implications.  There also 
> could be other
> > > approaches I haven't thought of, as well.
> > >
> > > What are your thoughts on this?  Is there a solution with an
> > > obvious advantage?
> > >
> > >
> > > ----Brett.
> > >
> 
> --------------------------------------------------------------
> -----------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the 
> chance to share your
> opinions on IT & business topics through brief surveys -- and 
> earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge
> &CID=DEVDEV
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 

Re: [Rails-devel] Undo / Redo design

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

I was just thinking, that there's another option that exists.

I'm thinking that it probably will require more work than the other
options, but it may be beneficial for us to do it because of the
advantages in simplifying some of the complexity of the application.

We can define a parent object (Action) and/or interface (Actionable)
for our model objects to inherit from.

Each object then, inherits a basic Do and Undo methods that can be
overridden when needed.  For classes that do more than one thing, the
Do method can take the name of the action to take, and call the
associated methods that will take the desired action.

Then, the UI code can be reworked to call these Do and Undo methods
and we can make all other methods private to prevent them from being
called directly.

>From there, we can create a stack and assure that each Do method adds
its parent object to the stack. This makes Undoing a matter of popping
the object off the stack and calling the Undo method. Any calling
parameters can be accessed via an array held by the object.


---Brett

On 7/17/06, Erik Vos <eri...@hc...> wrote:
> I have also thought about this subject in the past weeks.
>
> Usually an action falls apart in several sub-action
> (which I tend to call moves). An Action can contain any
> number of moves; the determining factor is which combination
> of moves constitute an "atomic" action, i.e. a series of
> moves (changes) that must be executed and possibly undone as a whole.
>
> For instance, selling a share involves at least:
> 1. The movement of a certificate from a player's portfolio
> to the Bank Pool (another rportfolio),
> 2. The movement of some cash from the Bank to the selling
> player (both are CashHolders).
> 3. A price drop, accompanied by the movement of the
> company's token on the Stock Chart.
>
> One could express this in XML as follows (this does not mean
> that I want to store the Undo stack in that way, although
> it is an option):
> <Action>
>   <MoveCertificate company=PRR seqno=2 from=Player-1 to=Pool/>
>   <MoveCash amount=67 from=bank to=Player-1/>
>   <MovePrice company=PRR from=G6 to=G7/>
> </Action>
>
> For many type of actions this is easy to implement, as many
> movements already exist in much this way in the existing code
> (see for instance Bank.transferCash() and Portfolio.transferCertificate()).
> Of course, it becomes tricky when state changes enter the picture.
> For instance, a just floated company must be unfloated in an Undo,
> and such an activity does not yet exist.
>
> I am thinking to build up an Action gradually.
> As soon as the user's request has been validated in StockRound or
> OperationRound, Action.start() is called, which creates a new (empty)
> Action object.
> Then the changes are executed, each being registered in the
> Action object as additional moves,
> e.g. with Action.add(new MoveCash (...)).
> Finally Action.end() is called, closing the action (and perhaps
> executing it, see below).
>
> Action.undo() should then undo the last action.
>
> Stacking can be easily added this way.
>
> One main decision to take is whether the changes should be executed
> parallel to creating the Action object (so that the existing code
> remains much the same), or that it is the Action object that,
> when finished, actually performs the changes.
>
> Perhaps the latter option is better, as it enforces developers
> to implement all changes, including state changes, in a symmetric way.
>
> I think this is a similar (or perhaps the same) choice as you
> have presented below.
>
> Erik.
>
>
> > -----Original Message-----
> > From: rai...@li...
> > [mailto:rai...@li...] On Behalf
> > Of brett lentz
> > Sent: 17 July 2006 07:31
> > To: Development list for Rails: an 18xx game
> > Subject: [Rails-devel] Undo / Redo design
> >
> > I've been thinking about how to approach implementing Undo/Redo.
> >
> > It seems to me that there are two basic strategies that we
> > can attempt.
> >
> > In each of them, we need to create a stack to store actions. Then, we
> > can place the stack in front of or after the code to execute the
> > action.
> >
> > The basic flow would look something like this:
> >
> > Stack before Action (Stack as EventHandler):
> > 1. Stack object receives call from UI to take an action.
> > 2. Stack stores action taken
> > 3. Stack object calls model object to resolve action.
> >
> > Stack after Action (Stack as a Listener):
> > 1. Model code receives call to act.
> > 2. Model resolves action
> > 3. Model notifies Stack object of action just taken.
> >
> >
> > I haven't really done much of an analysis of which approach would be
> > more work or have additional implications.  There also could be other
> > approaches I haven't thought of, as well.
> >
> > What are your thoughts on this?  Is there a solution with an
> > obvious advantage?
> >
> >
> > ----Brett.
> >

Re: [Rails-devel] Undo / Redo design

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

I have also thought about this subject in the past weeks.

Usually an action falls apart in several sub-action
(which I tend to call moves). An Action can contain any
number of moves; the determining factor is which combination
of moves constitute an "atomic" action, i.e. a series of 
moves (changes) that must be executed and possibly undone as a whole.

For instance, selling a share involves at least:
1. The movement of a certificate from a player's portfolio
to the Bank Pool (another rportfolio),
2. The movement of some cash from the Bank to the selling
player (both are CashHolders).
3. A price drop, accompanied by the movement of the
company's token on the Stock Chart.

One could express this in XML as follows (this does not mean
that I want to store the Undo stack in that way, although
it is an option):
<Action>
  <MoveCertificate company=PRR seqno=2 from=Player-1 to=Pool/>
  <MoveCash amount=67 from=bank to=Player-1/>
  <MovePrice company=PRR from=G6 to=G7/>
</Action>

For many type of actions this is easy to implement, as many
movements already exist in much this way in the existing code 
(see for instance Bank.transferCash() and Portfolio.transferCertificate()).
Of course, it becomes tricky when state changes enter the picture.
For instance, a just floated company must be unfloated in an Undo,
and such an activity does not yet exist.

I am thinking to build up an Action gradually.
As soon as the user's request has been validated in StockRound or
OperationRound, Action.start() is called, which creates a new (empty)
Action object.
Then the changes are executed, each being registered in the 
Action object as additional moves, 
e.g. with Action.add(new MoveCash (...)).
Finally Action.end() is called, closing the action (and perhaps
executing it, see below).

Action.undo() should then undo the last action.

Stacking can be easily added this way.

One main decision to take is whether the changes should be executed
parallel to creating the Action object (so that the existing code
remains much the same), or that it is the Action object that,
when finished, actually performs the changes. 

Perhaps the latter option is better, as it enforces developers
to implement all changes, including state changes, in a symmetric way.

I think this is a similar (or perhaps the same) choice as you 
have presented below.

Erik.
 

> -----Original Message-----
> From: rai...@li... 
> [mailto:rai...@li...] On Behalf 
> Of brett lentz
> Sent: 17 July 2006 07:31
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Undo / Redo design
> 
> I've been thinking about how to approach implementing Undo/Redo.
> 
> It seems to me that there are two basic strategies that we 
> can attempt.
> 
> In each of them, we need to create a stack to store actions. Then, we
> can place the stack in front of or after the code to execute the
> action.
> 
> The basic flow would look something like this:
> 
> Stack before Action (Stack as EventHandler):
> 1. Stack object receives call from UI to take an action.
> 2. Stack stores action taken
> 3. Stack object calls model object to resolve action.
> 
> Stack after Action (Stack as a Listener):
> 1. Model code receives call to act.
> 2. Model resolves action
> 3. Model notifies Stack object of action just taken.
> 
> 
> I haven't really done much of an analysis of which approach would be
> more work or have additional implications.  There also could be other
> approaches I haven't thought of, as well.
> 
> What are your thoughts on this?  Is there a solution with an 
> obvious advantage?
> 
> 
> ----Brett.
> 
> 
> --------------------------------------------------------------
> -----------
> Using Tomcat but need to do more? Need to support web 
> services, security?
> Get stuff done quickly with pre-integrated technology to make 
> your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on 
> Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&
dat=121642
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 

[Rails-devel] Undo / Redo design

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

I've been thinking about how to approach implementing Undo/Redo.

It seems to me that there are two basic strategies that we can attempt.

In each of them, we need to create a stack to store actions. Then, we
can place the stack in front of or after the code to execute the
action.

The basic flow would look something like this:

Stack before Action (Stack as EventHandler):
1. Stack object receives call from UI to take an action.
2. Stack stores action taken
3. Stack object calls model object to resolve action.

Stack after Action (Stack as a Listener):
1. Model code receives call to act.
2. Model resolves action
3. Model notifies Stack object of action just taken.


I haven't really done much of an analysis of which approach would be
more work or have additional implications.  There also could be other
approaches I haven't thought of, as well.

What are your thoughts on this?  Is there a solution with an obvious advantage?


----Brett.

Re: [Rails-devel] Localization (was: Constants)

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

On 7/16/06, Erik Vos <eri...@hc...> wrote:
> > Ok... I think I'm more or less done with moving all of the localizable
> > strings out to LocalisedText.properties.
>
> Any particular strategy behind using the different
> key format styles (e.g. LayTile and LAY_TRACK)?
>

No, not really.  Just something that was a byproduct of my doing much
of this without looking at the conventions until I was well into
making the changes.

> > I've also included some helpful text about the conventions used in the
> > file to further help anybody interested in translating.
>
> There is an easier and IMO far better way to format strings
> that contain variable values: MessageFormat.
>
> I have implemented this in LocalText.getText as a new signature
> getText (key, Object[]), where the 2nd arg is an array of objects
> (typically Strings). I have included one example on line 121 of
> LocalisedText.properties, which is used in ORPanel line 802.
>

OK, good.  If I have some time in the next few days, I'll see about
reworking some of the worst offenders of using multiple strings.

> In addition:
>
> - fixed bug 1519026 (Canceling train purchase does not abort
> purchase). This was true for buying from another company, in
> the price request popup.
>
> - implemented request 1517709 (Deactivate train button),
> this applies to train buying if the company has no room
> for more trains.
>
> - fixed a few more bugs around train buying.
>

Excellent.

---Brett.

Re: [Rails-devel] Localization (was: Constants)

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

> Ok... I think I'm more or less done with moving all of the localizable
> strings out to LocalisedText.properties.

Any particular strategy behind using the different
key format styles (e.g. LayTile and LAY_TRACK)?

> I've also included some helpful text about the conventions used in the
> file to further help anybody interested in translating.

There is an easier and IMO far better way to format strings
that contain variable values: MessageFormat. 

I have implemented this in LocalText.getText as a new signature
getText (key, Object[]), where the 2nd arg is an array of objects
(typically Strings). I have included one example on line 121 of
LocalisedText.properties, which is used in ORPanel line 802.

In addition:

- fixed bug 1519026 (Canceling train purchase does not abort
purchase). This was true for buying from another company, in
the price request popup.

- implemented request 1517709 (Deactivate train button),
this applies to train buying if the company has no room 
for more trains.

- fixed a few more bugs around train buying.

Erik.

Re: [Rails-devel] Can't synchronize

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

http://sourceforge.net/forum/forum.php?forum_id=591372

Posted By: burley
Date: 2006-07-14 04:41
Summary: Password expiry due to shell server exploit

A recent kernel exploit was released that allowed a non admin user to
escalate privileges on the host pr-shell1. We urge all users who
frequent this host to change their password immediately and check
their project group space for any tampering. As a precaution, we have
blocked access to all project resources by password until the user
resets their password. After the password has been reset, project
resources should be accessible within 5 minutes.


On 7/16/06, Erik Vos <eri...@hc...> wrote:
> I have fixed a few things around train buying,
> but for some reason I cannot synchronize with Sourceforge
> at the moment. I keep being asked for my password.
> Not sure what is wrong...
>
> Erik Vos
>
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] Can't synchronize

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

I have fixed a few things around train buying, 
but for some reason I cannot synchronize with Sourceforge
at the moment. I keep being asked for my password.
Not sure what is wrong...

Erik Vos

Re: [Rails-devel] Localization (was: Constants)

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

Ok... I think I'm more or less done with moving all of the localizable
strings out to LocalisedText.properties.

I've also included some helpful text about the conventions used in the
file to further help anybody interested in translating.

---Brett.

Re: [Rails-devel] Constants

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

On 7/11/06, Erik Vos <eri...@hc...> wrote:
> > > Localisation is (or should be) already handled in Game.getText().
> > > Currently there is only a default (English) text file,
> > > but IIRC adding French texts in a file LocalisedText_fr.properties
> > > should handle that language (after calling Game.setLocale("fr")).
> > >
> >
> > We should make this a configurable option on startup.  We should also
> > look at saving a file of "default" settings so that when the user sets
> > a preference, we save it and re-use it the next time we start up.
>
> Yes, and yes.
>

Ok... let's address this after we handle Undo/Redo and Load/Save of games.

I'll stick it in the feature request tracker.

Later today, I should have most of the strings pulled out into
LocalisedText.properties.

---Brett.

Re: [Rails-devel] Constants

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

> > Localisation is (or should be) already handled in Game.getText().
> > Currently there is only a default (English) text file,
> > but IIRC adding French texts in a file LocalisedText_fr.properties
> > should handle that language (after calling Game.setLocale("fr")).
> >
> 
> We should make this a configurable option on startup.  We should also
> look at saving a file of "default" settings so that when the user sets
> a preference, we save it and re-use it the next time we start up.

Yes, and yes.

Erik.

Re: [Rails-devel] Constants

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

On 7/11/06, Erik Vos <eri...@hc...> wrote:
> > Java has it's own localisation methods and classes under
> > java.util.Locale and java.util.ResourceBundle.
> >
> > The current plan for localization in Rails is fairly loose. Erik has
> > started a basic amount of using the Locale class and
> > LocalisedText.properties.
>
> Localisation is (or should be) already handled in Game.getText().
> Currently there is only a default (English) text file,
> but IIRC adding French texts in a file LocalisedText_fr.properties
> should handle that language (after calling Game.setLocale("fr")).
>

We should make this a configurable option on startup.  We should also
look at saving a file of "default" settings so that when the user sets
a preference, we save it and re-use it the next time we start up.

---Brett.

Re: [Rails-devel] Constants

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

> Java has it's own localisation methods and classes under
> java.util.Locale and java.util.ResourceBundle.
> 
> The current plan for localization in Rails is fairly loose. Erik has
> started a basic amount of using the Locale class and
> LocalisedText.properties.

Localisation is (or should be) already handled in Game.getText().
Currently there is only a default (English) text file,
but IIRC adding French texts in a file LocalisedText_fr.properties 
should handle that language (after calling Game.setLocale("fr")).

Erik.

Re: [Rails-devel] Constants

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

On 7/11/06, John A. Tamplin <ja...@ja...> wrote:
> brett lentz wrote:
>
> >Of course.  I was more meaning things like the many static strings
> >that we use on buttons and labels (e.g. "ok" and "done") or static
> >numbers like SQRT3 that are duplicated across the GUI files, etc.
> >
> >
> Speaking of strings, what is the plan for localization?  I have always
> used GNU gettext myself, but I am not sure how that works with the Java
> approach (even though I see there is a port of gettext to Java).
>
> If we aren't using something like that, then perhaps isolating all the
> UI strings into a single class would make it easier to localize, perhaps
> even using ClassLoader to load the appropriate one from a preference
> setting.
>
> It's too bad Sun didn't include java.lang.Math.SQRT3 etc, and that you
> can't easily add constant definitions to a class.
>


Java has it's own localisation methods and classes under
java.util.Locale and java.util.ResourceBundle.

The current plan for localization in Rails is fairly loose. Erik has
started a basic amount of using the Locale class and
LocalisedText.properties.

I was thinking that I might at least round up all the strings and make
them available for translating.

---Brett.

Re: [Rails-devel] Constants

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

On 7/11/06, Erik Vos <eri...@hc...> wrote:
> > I've noticed that we've got a ton of constants that are duplicated
> > across our source tree.
> >
> > Does anyone object to me creating a single Constants class-file that
> > holds all of these items and relocating all of our constants into this
> > central file?
>
> I presume you are only talking about public constants.
> Protected and private ones have only local significance
> and should stay where these are anyway.
>

Correct.

> Displayed texts should not be constants but be made localisable
> by defining these in LocalisedText.properties, and retrieved via
> Game.getText().
>
> For the rest I concur with John: it is generally better
> to keep constants related to classes where they logically
> belong to.
>
> Perhaps the keys of the localisable texts are an exception,
> I can imagine putting all these in one class LocalText or such
> (this is also the kind of constant that will suffer most from duplication).
> Game.getText() could then be moved to that class.
>

Yeah, this was more along the lines I was thinking.

I'll focus just on the localisable texts for now.

---Brett.

Re: [Rails-devel] Constants

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

brett lentz wrote:

>Of course.  I was more meaning things like the many static strings
>that we use on buttons and labels (e.g. "ok" and "done") or static
>numbers like SQRT3 that are duplicated across the GUI files, etc.
>  
>
Speaking of strings, what is the plan for localization?  I have always 
used GNU gettext myself, but I am not sure how that works with the Java 
approach (even though I see there is a port of gettext to Java).

If we aren't using something like that, then perhaps isolating all the 
UI strings into a single class would make it easier to localize, perhaps 
even using ClassLoader to load the appropriate one from a preference 
setting.

It's too bad Sun didn't include java.lang.Math.SQRT3 etc, and that you 
can't easily add constant definitions to a class.

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

Re: [Rails-devel] Constants

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

> I've noticed that we've got a ton of constants that are duplicated
> across our source tree.
> 
> Does anyone object to me creating a single Constants class-file that
> holds all of these items and relocating all of our constants into this
> central file?

I presume you are only talking about public constants.
Protected and private ones have only local significance
and should stay where these are anyway.

Displayed texts should not be constants but be made localisable
by defining these in LocalisedText.properties, and retrieved via
Game.getText().

For the rest I concur with John: it is generally better 
to keep constants related to classes where they logically
belong to.

Perhaps the keys of the localisable texts are an exception,
I can imagine putting all these in one class LocalText or such
(this is also the kind of constant that will suffer most from duplication).
Game.getText() could then be moved to that class.

Erik.

Re: [Rails-devel] Constants

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

On 7/11/06, John A. Tamplin <ja...@ja...> wrote:
> brett lentz wrote:
>
> >I've noticed that we've got a ton of constants that are duplicated
> >across our source tree.
> >
> >Does anyone object to me creating a single Constants class-file that
> >holds all of these items and relocating all of our constants into this
> >central file?
> >
> >
> It would seem better to have them related to how they are used, rather
> than just grouping them because they are constants.  For example, a
> constant describing the type of a junction on a tile has no business
> being lumped together with a constant definition of the number of pixels
> offset for some graphic object.
>
> This will add unnecesary coupling between classes.
>
> If the values are really duplicated, then a better solution would be to
> remove the duplication and use one canonical source.
>

Of course.  I was more meaning things like the many static strings
that we use on buttons and labels (e.g. "ok" and "done") or static
numbers like SQRT3 that are duplicated across the GUI files, etc.

All of the more specific variables, I'm not interested in touching. ;-)

---Brett.

Re: [Rails-devel] Constants

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

brett lentz wrote:

>I've noticed that we've got a ton of constants that are duplicated
>across our source tree.
>
>Does anyone object to me creating a single Constants class-file that
>holds all of these items and relocating all of our constants into this
>central file?
>  
>
It would seem better to have them related to how they are used, rather 
than just grouping them because they are constants.  For example, a 
constant describing the type of a junction on a tile has no business 
being lumped together with a constant definition of the number of pixels 
offset for some graphic object.

This will add unnecesary coupling between classes.

If the values are really duplicated, then a better solution would be to 
remove the duplication and use one canonical source.

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

[Rails-devel] Constants

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

I've noticed that we've got a ton of constants that are duplicated
across our source tree.

Does anyone object to me creating a single Constants class-file that
holds all of these items and relocating all of our constants into this
central file?

---Brett.

Re: [Rails-devel] Bug report: Tiles are now shown

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

On 7/11/06, brett lentz <wak...@gm...> wrote:
> On 7/11/06, Akiyoshi NOMURA <aki...@ni...> wrote:
> >
> > > Try renaming the JAR file to "Rails.jar" and see if that helps.
> >
> > Thanks.  Rails.jar works well.
>
> Great.  I know where the issue is then.
>

I've fixed this problem, and uploaded a new version of the JAR that
doesn't need to be renamed.

---Brett.

Re: [Rails-devel] Bug report: Tiles are now shown

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

On 7/11/06, Akiyoshi NOMURA <aki...@ni...> wrote:
>
> > Try renaming the JAR file to "Rails.jar" and see if that helps.
>
> Thanks.  Rails.jar works well.

Great.  I know where the issue is then.

---Brett.

Re: [Rails-devel] Bug report: Tiles are now shown

[Akiyoshi N. <aki...@ni...>]

Hi Brett, 

----- Original Message ----- 
From: "brett lentz" <wak...@gm...>
To: "Development list for Rails: an 18xx game" <rai...@li...>
Sent: Wednesday, July 12, 2006 1:17 AM
Subject: Re: [Rails-devel] Bug report: Tiles are now shown (was: Railsversion 1.0.1 released)


> Try renaming the JAR file to "Rails.jar" and see if that helps.

Thanks.  Rails.jar works well.  

> Also, what Operating System and what Java Runtime Engine are you using?

Windows XP SP2, J2SE 1.5.0_07.  

Akiyoshi NOMURA
  mailto:aki...@ni...

Re: [Rails-devel] Bug report: Tiles are now shown (was: Rails version 1.0.1 released)

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

Try renaming the JAR file to "Rails.jar" and see if that helps.

Also, what Operating System and what Java Runtime Engine are you using?

---Brett.

On 7/11/06, Akiyoshi NOMURA <aki...@ni...> wrote:
> Hello,
>
> This is a bug report for Rails 1.01.  Rails 1.00 does not have
> this bug.
>
> In Map winodw, tiles are not shown when I click a hex.
>
> Akiyoshi NOMURA
>   mailto:aki...@ni...
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>