Menu
▾
▴
rails-devel
|
From: Chris S. <chr...@gm...> - 2010-01-19 21:36:46
|
One of our players says: It looks like the 18xx.log file mod. date is updated when you close a .rails > file even if you don't make any changes. Is there a way to review the game > without forcing an update to the log - other than copying the directory and > opening that? > Also, can anyone comment on the "conflicted copy" log file question I asked a while back? Is it the same issue, or something different? -- Chris Please consider the environment before printing this e-mail. |
|
From: Aliza P. <ali...@gm...> - 2010-01-19 21:53:51
|
On Tue, Jan 19, 2010 at 1:36 PM, Chris Shaffer <chr...@gm...> wrote: > One of our players says: > >> It looks like the 18xx.log file mod. date is updated when you >> close a .rails file even if you don't make any changes. Is there >> a way to review the game without forcing an update to the >> log - other than copying the directory and opening that? If you use a copy of Rails in one directory to open a savefile in another directory, then the logfile is in the same directory as the software, not the data. For example, in my PBEM games the Dropbox shared file area has data files only, and we each run our own copies of the Rails software (a slightly more secure model, though a bit more error prone if players need to keep track of which software version to use with which game.) - Aliza |
|
From: Chris S. <chr...@gm...> - 2010-01-19 21:59:54
|
Right, I understand that, but we are using Rails in the Dropbox directory and sharing it. We know it is a slight security risk but keeping the software version synchronized trumped that. So, the questions remain: 1) Is there any way to prevent Rails from saving the log file on exit if no actions are taken; 2) What are the conflicted log files, and what purpose do they serve; 3) Are 1 and 2 the same question? -- Chris Please consider the environment before printing this e-mail. On Tue, Jan 19, 2010 at 1:53 PM, Aliza Panitz <ali...@gm...>wrote: > On Tue, Jan 19, 2010 at 1:36 PM, Chris Shaffer <chr...@gm...> > wrote: > > One of our players says: > > > >> It looks like the 18xx.log file mod. date is updated when you > >> close a .rails file even if you don't make any changes. Is there > >> a way to review the game without forcing an update to the > >> log - other than copying the directory and opening that? > > If you use a copy of Rails in one directory to open a savefile in > another directory, then the logfile is in the same directory as the > software, not the data. > > For example, in my PBEM games the Dropbox shared file area has data > files only, and we each run our own copies of the Rails software (a > slightly more secure model, though a bit more error prone if players > need to keep track of which software version to use with which game.) > > - Aliza > > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for > Conference > attendees to learn about information security's most important issues > through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Phil D. <de...@gm...> - 2010-01-19 22:45:46
|
Rails opens the log file when you start it up and holds it open. It saves on exit. Therefore, if two people open rails from the same folder at the same time, the log file will end up conflicted since two people have accessed it. The program log isn't a killer I don't believe. The game log is a seperate file. Conflicted versions can probably be deleted without impacting the game. I'll create a conflict in my DB game and test this... Phil On 19 Jan 2010, at 21:59, Chris Shaffer <chr...@gm...> wrote: > Right, I understand that, but we are using Rails in the Dropbox > directory and sharing it. We know it is a slight security risk but > keeping the software version synchronized trumped that. > > So, the questions remain: > > 1) Is there any way to prevent Rails from saving the log file on > exit if no actions are taken; > 2) What are the conflicted log files, and what purpose do they serve; > 3) Are 1 and 2 the same question? > > -- > Chris > > Please consider the environment before printing this e-mail. > > > On Tue, Jan 19, 2010 at 1:53 PM, Aliza Panitz > <ali...@gm...> wrote: > On Tue, Jan 19, 2010 at 1:36 PM, Chris Shaffer <chr...@gm... > > wrote: > > One of our players says: > > > >> It looks like the 18xx.log file mod. date is updated when you > >> close a .rails file even if you don't make any changes. Is there > >> a way to review the game without forcing an update to the > >> log - other than copying the directory and opening that? > > If you use a copy of Rails in one directory to open a savefile in > another directory, then the logfile is in the same directory as the > software, not the data. > > For example, in my PBEM games the Dropbox shared file area has data > files only, and we each run our own copies of the Rails software (a > slightly more secure model, though a bit more error prone if players > need to keep track of which software version to use with which game.) > > - Aliza > > --- > --- > --- > --------------------------------------------------------------------- > Throughout its 18-year history, RSA Conference consistently attracts > the > world's best and brightest in the field, creating opportunities for > Conference > attendees to learn about information security's most important > issues through > interactions with peers, luminaries and emerging and established > companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > --- > --- > --- > --------------------------------------------------------------------- > Throughout its 18-year history, RSA Conference consistently attracts > the > world's best and brightest in the field, creating opportunities for > Conference > attendees to learn about information security's most important > issues through > interactions with peers, luminaries and emerging and established > companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Erik V. <eri...@xs...> - 2010-01-19 23:04:48
|
Not sure what the problem is. Are we talking about log files or save files? You can set the log file location and name in your copy of my.properties: log4j.appender.F.File=<path> Erik. _____ From: Chris Shaffer [mailto:chr...@gm...] Sent: Tuesday 19 January 2010 23:00 To: Development list for Rails: an 18xx game Subject: Re: [Rails-devel] Log file query Right, I understand that, but we are using Rails in the Dropbox directory and sharing it. We know it is a slight security risk but keeping the software version synchronized trumped that. So, the questions remain: 1) Is there any way to prevent Rails from saving the log file on exit if no actions are taken; 2) What are the conflicted log files, and what purpose do they serve; 3) Are 1 and 2 the same question? -- Chris Please consider the environment before printing this e-mail. On Tue, Jan 19, 2010 at 1:53 PM, Aliza Panitz <ali...@gm...> wrote: On Tue, Jan 19, 2010 at 1:36 PM, Chris Shaffer <chr...@gm...> wrote: > One of our players says: > >> It looks like the 18xx.log file mod. date is updated when you >> close a .rails file even if you don't make any changes. Is there >> a way to review the game without forcing an update to the >> log - other than copying the directory and opening that? If you use a copy of Rails in one directory to open a savefile in another directory, then the logfile is in the same directory as the software, not the data. For example, in my PBEM games the Dropbox shared file area has data files only, and we each run our own copies of the Rails software (a slightly more secure model, though a bit more error prone if players need to keep track of which software version to use with which game.) - Aliza ---------------------------------------------------------------------------- -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Erik V. <eri...@xs...> - 2010-01-19 23:14:07
|
Oh, I see. Phil's last mail clarifies it for me. One idea is to have different people run with different .properties files, each specifying a different log file name. You can set a personal .properties file on the command line by adding the option -Dconfigfile=Chris.properties or Phil.properties or whatever. So give each player a separate .bat or .sh file to start Rails. Erik. _____ From: Erik Vos [mailto:eri...@xs...] Sent: Wednesday 20 January 2010 00:05 To: 'Development list for Rails: an 18xx game' Subject: Re: [Rails-devel] Log file query Not sure what the problem is. Are we talking about log files or save files? You can set the log file location and name in your copy of my.properties: log4j.appender.F.File=<path> Erik. _____ From: Chris Shaffer [mailto:chr...@gm...] Sent: Tuesday 19 January 2010 23:00 To: Development list for Rails: an 18xx game Subject: Re: [Rails-devel] Log file query Right, I understand that, but we are using Rails in the Dropbox directory and sharing it. We know it is a slight security risk but keeping the software version synchronized trumped that. So, the questions remain: 1) Is there any way to prevent Rails from saving the log file on exit if no actions are taken; 2) What are the conflicted log files, and what purpose do they serve; 3) Are 1 and 2 the same question? -- Chris Please consider the environment before printing this e-mail. On Tue, Jan 19, 2010 at 1:53 PM, Aliza Panitz <ali...@gm...> wrote: On Tue, Jan 19, 2010 at 1:36 PM, Chris Shaffer <chr...@gm...> wrote: > One of our players says: > >> It looks like the 18xx.log file mod. date is updated when you >> close a .rails file even if you don't make any changes. Is there >> a way to review the game without forcing an update to the >> log - other than copying the directory and opening that? If you use a copy of Rails in one directory to open a savefile in another directory, then the logfile is in the same directory as the software, not the data. For example, in my PBEM games the Dropbox shared file area has data files only, and we each run our own copies of the Rails software (a slightly more secure model, though a bit more error prone if players need to keep track of which software version to use with which game.) - Aliza ---------------------------------------------------------------------------- -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Chris S. <chr...@gm...> - 2010-01-19 23:16:25
|
OK, that would work. I guess the question is whether we even care if there are conflicts? Since the 18xx.log file has no real effect on game play... -- Chris Please consider the environment before printing this e-mail. On Tue, Jan 19, 2010 at 3:14 PM, Erik Vos <eri...@xs...> wrote: > Oh, I see. Phil's last mail clarifies it for me. > One idea is to have different people run with different .properties files, > each specifying a different log file name. > You can set a personal .properties file on the command line by adding the > option > > -Dconfigfile=Chris.properties or Phil.properties or whatever. > > So give each player a separate .bat or .sh file to start Rails. > > Erik. > > ------------------------------ > *From:* Erik Vos [mailto:eri...@xs...] > *Sent:* Wednesday 20 January 2010 00:05 > > *To:* 'Development list for Rails: an 18xx game' > *Subject:* Re: [Rails-devel] Log file query > > Not sure what the problem is. > Are we talking about log files or save files? > You can set the log file location and name in your copy of my.properties: > log4j.appender.F.File=<path> > > Erik. > > ------------------------------ > *From:* Chris Shaffer [mailto:chr...@gm...] > *Sent:* Tuesday 19 January 2010 23:00 > *To:* Development list for Rails: an 18xx game > *Subject:* Re: [Rails-devel] Log file query > > Right, I understand that, but we are using Rails in the Dropbox directory > and sharing it. We know it is a slight security risk but keeping the > software version synchronized trumped that. > > So, the questions remain: > > 1) Is there any way to prevent Rails from saving the log file on exit if no > actions are taken; > 2) What are the conflicted log files, and what purpose do they serve; > 3) Are 1 and 2 the same question? > > -- > Chris > > Please consider the environment before printing this e-mail. > > > On Tue, Jan 19, 2010 at 1:53 PM, Aliza Panitz <ali...@gm...>wrote: > >> On Tue, Jan 19, 2010 at 1:36 PM, Chris Shaffer <chr...@gm...> >> wrote: >> > One of our players says: >> > >> >> It looks like the 18xx.log file mod. date is updated when you >> >> close a .rails file even if you don't make any changes. Is there >> >> a way to review the game without forcing an update to the >> >> log - other than copying the directory and opening that? >> >> If you use a copy of Rails in one directory to open a savefile in >> another directory, then the logfile is in the same directory as the >> software, not the data. >> >> For example, in my PBEM games the Dropbox shared file area has data >> files only, and we each run our own copies of the Rails software (a >> slightly more secure model, though a bit more error prone if players >> need to keep track of which software version to use with which game.) >> >> - Aliza >> >> >> ------------------------------------------------------------------------------ >> Throughout its 18-year history, RSA Conference consistently attracts the >> world's best and brightest in the field, creating opportunities for >> Conference >> attendees to learn about information security's most important issues >> through >> interactions with peers, luminaries and emerging and established >> companies. >> http://p.sf.net/sfu/rsaconf-dev2dev >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> > > > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for > Conference > attendees to learn about information security's most important issues > through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
|
From: Chris B. <bro...@co...> - 2010-01-20 00:45:02
|
On Tue, Jan 19, 2010 at 3:14 PM, Erik Vos <eri...@xs...> wrote: > So give each player a separate .bat or .sh file to start Rails. > > Or possibly have the log file go to a consistent non-shared path that (hopefully) would work across all of the machines (/tmp for example)? -Chris |
|
From: Phil D. <de...@gm...> - 2010-01-20 09:55:03
|
2010/1/20 Chris Brooks <bro...@co...>: > On Tue, Jan 19, 2010 at 3:14 PM, Erik Vos <eri...@xs...> wrote: >> >> So give each player a separate .bat or .sh file to start Rails. > > Or possibly have the log file go to a consistent non-shared path that > (hopefully) would work across all of the machines (/tmp for example)? This is probably the best option I think, it saves the messiness of a conflicted file and also stops that little swirly synch thing on dropbox from spinning constantly whilst you have rails open :) > -Chris > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for > Conference > attendees to learn about information security's most important issues > through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
|
From: Chris S. <chr...@gm...> - 2010-01-19 23:14:19
|
I'm guessing there really isn't a problem. As best I can tell from this discussion, the file 18xx.log is only used for program debugging and can be ignored by players. If that is correct, then I think we are done. The issue is that we are running Rails within the shared Dropbox folder, so multiple people can open the same jar at the same time. This causes conflicts when generating the 18xx.log file. Everyone is using a shared my.properties file, so we can't change it on a player-by-player basis. The advantage of running Rails this way is versioning. I'm currently playing one game on 1.1.0 and another on 1.1.2. Keeping a separate copy of Rails for each game makes it easier for me to avoid accidentally opening a game in the wrong version. -- Chris Please consider the environment before printing this e-mail. On Tue, Jan 19, 2010 at 3:04 PM, Erik Vos <eri...@xs...> wrote: > Not sure what the problem is. > Are we talking about log files or save files? > You can set the log file location and name in your copy of my.properties: > log4j.appender.F.File=<path> > > Erik. > > ------------------------------ > *From:* Chris Shaffer [mailto:chr...@gm...] > *Sent:* Tuesday 19 January 2010 23:00 > *To:* Development list for Rails: an 18xx game > *Subject:* Re: [Rails-devel] Log file query > > Right, I understand that, but we are using Rails in the Dropbox directory > and sharing it. We know it is a slight security risk but keeping the > software version synchronized trumped that. > > So, the questions remain: > > 1) Is there any way to prevent Rails from saving the log file on exit if no > actions are taken; > 2) What are the conflicted log files, and what purpose do they serve; > 3) Are 1 and 2 the same question? > > -- > Chris > > Please consider the environment before printing this e-mail. > > > On Tue, Jan 19, 2010 at 1:53 PM, Aliza Panitz <ali...@gm...>wrote: > >> On Tue, Jan 19, 2010 at 1:36 PM, Chris Shaffer <chr...@gm...> >> wrote: >> > One of our players says: >> > >> >> It looks like the 18xx.log file mod. date is updated when you >> >> close a .rails file even if you don't make any changes. Is there >> >> a way to review the game without forcing an update to the >> >> log - other than copying the directory and opening that? >> >> If you use a copy of Rails in one directory to open a savefile in >> another directory, then the logfile is in the same directory as the >> software, not the data. >> >> For example, in my PBEM games the Dropbox shared file area has data >> files only, and we each run our own copies of the Rails software (a >> slightly more secure model, though a bit more error prone if players >> need to keep track of which software version to use with which game.) >> >> - Aliza >> >> >> ------------------------------------------------------------------------------ >> Throughout its 18-year history, RSA Conference consistently attracts the >> world's best and brightest in the field, creating opportunities for >> Conference >> attendees to learn about information security's most important issues >> through >> interactions with peers, luminaries and emerging and established >> companies. >> http://p.sf.net/sfu/rsaconf-dev2dev >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> > > > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for > Conference > attendees to learn about information security's most important issues > through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
|
From: Erik V. <eri...@xs...> - 2010-01-20 20:21:32
|
The size of the log file can considerably be reduced by replacing DEBUG by INFO or WARN in my.properties. Which makes me think: wouldn't it be better if INFO would be the default setting in the release packages? Is anyone looking into the logs to spot errors? Erik. -----Original Message----- From: Phil Davies [mailto:de...@gm...] Sent: Wednesday 20 January 2010 10:55 To: bro...@co...; Development list for Rails: an 18xx game Subject: Re: [Rails-devel] Log file query 2010/1/20 Chris Brooks <bro...@co...>: > On Tue, Jan 19, 2010 at 3:14 PM, Erik Vos <eri...@xs...> wrote: >> >> So give each player a separate .bat or .sh file to start Rails. > > Or possibly have the log file go to a consistent non-shared path that > (hopefully) would work across all of the machines (/tmp for example)? This is probably the best option I think, it saves the messiness of a conflicted file and also stops that little swirly synch thing on dropbox from spinning constantly whilst you have rails open :) > -Chris > ---------------------------------------------------------------------------- -- > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for > Conference > attendees to learn about information security's most important issues > through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > ---------------------------------------------------------------------------- -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Phil D. <de...@gm...> - 2010-01-20 20:29:30
|
Generally speaking, best practice seems to suggest releasing public versions as INFO. That said, DEBUG info is quite handy for those of us who want to know what's going on and to try and locate issues. Plus, the log files aren't really that big. If it makes a significant difference on performance or size (like >1MB) then it's worth switching to INFO, otherwise DEBUG information is probably more useful. Phil 2010/1/20 Erik Vos <eri...@xs...>: > The size of the log file can considerably be reduced by > replacing DEBUG by INFO or WARN in my.properties. > > Which makes me think: wouldn't it be better if INFO would > be the default setting in the release packages? > > Is anyone looking into the logs to spot errors? > > Erik. > > -----Original Message----- > From: Phil Davies [mailto:de...@gm...] > Sent: Wednesday 20 January 2010 10:55 > To: bro...@co...; Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] Log file query > > 2010/1/20 Chris Brooks <bro...@co...>: >> On Tue, Jan 19, 2010 at 3:14 PM, Erik Vos <eri...@xs...> wrote: >>> >>> So give each player a separate .bat or .sh file to start Rails. >> >> Or possibly have the log file go to a consistent non-shared path that >> (hopefully) would work across all of the machines (/tmp for example)? > > This is probably the best option I think, it saves the messiness of a > conflicted file and also stops that little swirly synch thing on > dropbox from spinning constantly whilst you have rails open :) > >> -Chris >> > ---------------------------------------------------------------------------- > -- >> Throughout its 18-year history, RSA Conference consistently attracts the >> world's best and brightest in the field, creating opportunities for >> Conference >> attendees to learn about information security's most important issues >> through >> interactions with peers, luminaries and emerging and established > companies. >> http://p.sf.net/sfu/rsaconf-dev2dev >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel >> >> > > ---------------------------------------------------------------------------- > -- > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for > Conference > attendees to learn about information security's most important issues > through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ------------------------------------------------------------------------------ > Throughout its 18-year history, RSA Conference consistently attracts the > world's best and brightest in the field, creating opportunities for Conference > attendees to learn about information security's most important issues through > interactions with peers, luminaries and emerging and established companies. > http://p.sf.net/sfu/rsaconf-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X