rails-devel

[Rails-devel] Tokens misplaced on tile #59?

[Bill R. <ro...@gm...>]

Hello,

Am I the only one who is seeing tokens misplaced on tile #59.  (Actually, it seems to be any station with position x5y for arbitrary x and y.)  Specifically, they appear one 60 degree rotation from the correct place.  I've attached a savegame that shows this for the Erie's home hex.  This also appears in the 1830 Reading variant, with the preprinted PRR and the RDG home tiles.

I have spent some time this evening trying to find the problem, but I am largely at a loss.  Using git bisect I am able to track the offending commit (at least as far as 1830 goes) to commit 0c69cf, which introduced the Coalfields variant.  Digging further, the cities on tile #59 were at positions  052 and 352 before this commit, but at positions 152 and 452 following the commit.

This, one would think, could be easily found in the data files, or in the code that generates data/Tiles.xml from data/TileDictionary.xml.  I have looked at the previous commit that modified Tiles.xml: I can see the change in tile #59 (and presumably other tiles also), but I cannot find any changes to the tile database or the program that generates Tiles.xml that look like they would cause this change.

I can (and will) continue to try to find the source of the problem, as clearly hand-editing the generated Tiles.xml files is not a solution, but I thought I would ask to see if anyone knows how/why such a change might have been introduced.

The two attached savegames show the problem (at least on my end).  The 1830 savegame has the Erie's home token out of place, and the 1830R savegame has the RDG's token (among others) in the wrong place.  If you are checking out old code, note that only the 1830 savegame is likely to work, as the 1830 Reading savegame requires fixes that were only released in Rails 1.5.

Bill

Re: [Rails-devel] Tokens misplaced on tile #59?

[Phil D. <de...@gm...>]

I've not noticed this problem but does it occur if you replay a game
from the start?  I wonder if this is an issue of using an old save
with newer codebase?

I'll try these out later and see

Phil

On 5 October 2011 14:56, Bill Rosgen <ro...@gm...> wrote:
> Hello,
>
> Am I the only one who is seeing tokens misplaced on tile #59.  (Actually, it seems to be any station with position x5y for arbitrary x and y.)  Specifically, they appear one 60 degree rotation from the correct place.  I've attached a savegame that shows this for the Erie's home hex.  This also appears in the 1830 Reading variant, with the preprinted PRR and the RDG home tiles.
>
> I have spent some time this evening trying to find the problem, but I am largely at a loss.  Using git bisect I am able to track the offending commit (at least as far as 1830 goes) to commit 0c69cf, which introduced the Coalfields variant.  Digging further, the cities on tile #59 were at positions  052 and 352 before this commit, but at positions 152 and 452 following the commit.
>
> This, one would think, could be easily found in the data files, or in the code that generates data/Tiles.xml from data/TileDictionary.xml.  I have looked at the previous commit that modified Tiles.xml: I can see the change in tile #59 (and presumably other tiles also), but I cannot find any changes to the tile database or the program that generates Tiles.xml that look like they would cause this change.
>
> I can (and will) continue to try to find the source of the problem, as clearly hand-editing the generated Tiles.xml files is not a solution, but I thought I would ask to see if anyone knows how/why such a change might have been introduced.
>
> The two attached savegames show the problem (at least on my end).  The 1830 savegame has the Erie's home token out of place, and the 1830R savegame has the RDG's token (among others) in the wrong place.  If you are checking out old code, note that only the 1830 savegame is likely to work, as the 1830 Reading savegame requires fixes that were only released in Rails 1.5.
>
> Bill
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] Tokens misplaced on tile #59?

[Bill R. <ro...@gm...>]

This happens in new games created and played with 1.5, and it also happens in games created and played in older versions.

If the bug isn't universal, I can post screenshots that demonstrate the problem.  It would be odd, however, if the change in the data files was not the source of the problem.  I cannot, however, find an explanation for the changes to the (automatically generated) data files.

Bill

On 2011-10-05, at 22:08 , Phil Davies wrote:

> I've not noticed this problem but does it occur if you replay a game
> from the start?  I wonder if this is an issue of using an old save
> with newer codebase?
> 
> I'll try these out later and see
> 
> Phil
> 
> On 5 October 2011 14:56, Bill Rosgen <ro...@gm...> wrote:
>> Hello,
>> 
>> Am I the only one who is seeing tokens misplaced on tile #59.  (Actually, it seems to be any station with position x5y for arbitrary x and y.)  Specifically, they appear one 60 degree rotation from the correct place.  I've attached a savegame that shows this for the Erie's home hex.  This also appears in the 1830 Reading variant, with the preprinted PRR and the RDG home tiles.
>> 
>> I have spent some time this evening trying to find the problem, but I am largely at a loss.  Using git bisect I am able to track the offending commit (at least as far as 1830 goes) to commit 0c69cf, which introduced the Coalfields variant.  Digging further, the cities on tile #59 were at positions  052 and 352 before this commit, but at positions 152 and 452 following the commit.
>> 
>> This, one would think, could be easily found in the data files, or in the code that generates data/Tiles.xml from data/TileDictionary.xml.  I have looked at the previous commit that modified Tiles.xml: I can see the change in tile #59 (and presumably other tiles also), but I cannot find any changes to the tile database or the program that generates Tiles.xml that look like they would cause this change.
>> 
>> I can (and will) continue to try to find the source of the problem, as clearly hand-editing the generated Tiles.xml files is not a solution, but I thought I would ask to see if anyone knows how/why such a change might have been introduced.
>> 
>> The two attached savegames show the problem (at least on my end).  The 1830 savegame has the Erie's home token out of place, and the 1830R savegame has the RDG's token (among others) in the wrong place.  If you are checking out old code, note that only the 1830 savegame is likely to work, as the 1830 Reading savegame requires fixes that were only released in Rails 1.5.
>> 
>> Bill
>> 
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure contains a
>> definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy1
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> 
>> 
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Tokens misplaced on tile #59?

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

It's actually a 30 degrees clockwise rotation. 

I'll have a look tomorrow. One possibility is that some code has got
confused with respect to the hex orientation (NS or EW).  I know there have
been changes around the hex orientation logic, and maybe some consequence of
that has been missed. 

Erik.

> -----Original Message-----
> From: Bill Rosgen [mailto:ro...@gm...]
> Sent: Wednesday, October 05, 2011 6:52 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Tokens misplaced on tile #59?
> 
> This happens in new games created and played with 1.5, and it also happens
> in games created and played in older versions.
> 
> If the bug isn't universal, I can post screenshots that demonstrate the
> problem.  It would be odd, however, if the change in the data files was
not
> the source of the problem.  I cannot, however, find an explanation for the
> changes to the (automatically generated) data files.
> 
> Bill
> 
> On 2011-10-05, at 22:08 , Phil Davies wrote:
> 
> > I've not noticed this problem but does it occur if you replay a game
> > from the start?  I wonder if this is an issue of using an old save
> > with newer codebase?
> >
> > I'll try these out later and see
> >
> > Phil
> >
> > On 5 October 2011 14:56, Bill Rosgen <ro...@gm...> wrote:
> >> Hello,
> >>
> >> Am I the only one who is seeing tokens misplaced on tile #59.
(Actually, it
> seems to be any station with position x5y for arbitrary x and y.)
Specifically,
> they appear one 60 degree rotation from the correct place.  I've attached
a
> savegame that shows this for the Erie's home hex.  This also appears in
the
> 1830 Reading variant, with the preprinted PRR and the RDG home tiles.
> >>
> >> I have spent some time this evening trying to find the problem, but I
am
> largely at a loss.  Using git bisect I am able to track the offending
commit (at
> least as far as 1830 goes) to commit 0c69cf, which introduced the
Coalfields
> variant.  Digging further, the cities on tile #59 were at positions  052
and 352
> before this commit, but at positions 152 and 452 following the commit.
> >>
> >> This, one would think, could be easily found in the data files, or in
the
> code that generates data/Tiles.xml from data/TileDictionary.xml.  I have
> looked at the previous commit that modified Tiles.xml: I can see the
change
> in tile #59 (and presumably other tiles also), but I cannot find any
changes to
> the tile database or the program that generates Tiles.xml that look like
they
> would cause this change.
> >>
> >> I can (and will) continue to try to find the source of the problem, as
clearly
> hand-editing the generated Tiles.xml files is not a solution, but I
thought I
> would ask to see if anyone knows how/why such a change might have been
> introduced.
> >>
> >> The two attached savegames show the problem (at least on my end).  The
> 1830 savegame has the Erie's home token out of place, and the 1830R
> savegame has the RDG's token (among others) in the wrong place.  If you
are
> checking out old code, note that only the 1830 savegame is likely to work,
as
> the 1830 Reading savegame requires fixes that were only released in Rails
> 1.5.
> >>
> >> Bill
> >>
> >> ---------------------------------------------------------------------
> >> --------- All the data continuously generated in your IT
> >> infrastructure contains a definitive record of customers, application
> >> performance, security threats, fraudulent activity and more. Splunk
> >> takes this data and makes sense of it. Business sense. IT sense.
> >> Common sense.
> >> http://p.sf.net/sfu/splunk-d2dcopy1
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >>
> >>
> >
> > ----------------------------------------------------------------------
> > -------- All the data continuously generated in your IT infrastructure
> > contains a definitive record of customers, application performance,
> > security threats, fraudulent activity and more. Splunk takes this data
> > and makes sense of it. Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy1
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
>
----------------------------------------------------------------------------
--
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security threats,
> fraudulent activity and more. Splunk takes this data and makes sense of
it.
> Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Tokens misplaced on tile #59?

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

>>  Using git bisect I am able to track the offending commit (at least as
far as 1830 goes) to commit 0c69cf, which introduced the Coalfields variant.
Digging further, the cities on tile #59 were at positions  052 and 352
before this commit, but at positions 152 and 452 following the commit.
>>

This puzzles me. As far as I can see, the position values 152 and 452 for
tile #59 exist since the introduction of these codes 6 years ago.

It turns out, that this kind of token misplacement only occurs 
- in games with EW-oriented tiles
- for tokenable cities that are located off-center
- but only for cities located near a tile corner, not if located near a tile
edge.

Token locations are calculated in GUIHex.getTokenCenter(), and so far I
can't find anything that can explain why only corner-facing cities would
suffer from this problem.
I can't find anything irregular, neither in this code, nor in the
translations from the TileDesigner city location names  to my position codes
in ConvertTilesXML cityMap.

Erik.

> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> Sent: Wednesday, October 05, 2011 11:39 PM
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] Tokens misplaced on tile #59?
> 
> It's actually a 30 degrees clockwise rotation.
> 
> I'll have a look tomorrow. One possibility is that some code has got
confused
> with respect to the hex orientation (NS or EW).  I know there have been
> changes around the hex orientation logic, and maybe some consequence of
> that has been missed.
> 
> Erik.
> 
> > -----Original Message-----
> > From: Bill Rosgen [mailto:ro...@gm...]
> > Sent: Wednesday, October 05, 2011 6:52 PM
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] Tokens misplaced on tile #59?
> >
> > This happens in new games created and played with 1.5, and it also
> > happens in games created and played in older versions.
> >
> > If the bug isn't universal, I can post screenshots that demonstrate
> > the problem.  It would be odd, however, if the change in the data
> > files was
> not
> > the source of the problem.  I cannot, however, find an explanation for
> > the changes to the (automatically generated) data files.
> >
> > Bill
> >
> > On 2011-10-05, at 22:08 , Phil Davies wrote:
> >
> > > I've not noticed this problem but does it occur if you replay a game
> > > from the start?  I wonder if this is an issue of using an old save
> > > with newer codebase?
> > >
> > > I'll try these out later and see
> > >
> > > Phil
> > >
> > > On 5 October 2011 14:56, Bill Rosgen <ro...@gm...> wrote:
> > >> Hello,
> > >>
> > >> Am I the only one who is seeing tokens misplaced on tile #59.
> (Actually, it
> > seems to be any station with position x5y for arbitrary x and y.)
> Specifically,
> > they appear one 60 degree rotation from the correct place.  I've
> > attached
> a
> > savegame that shows this for the Erie's home hex.  This also appears
> > in
> the
> > 1830 Reading variant, with the preprinted PRR and the RDG home tiles.
> > >>
> > >> I have spent some time this evening trying to find the problem, but
> > >> I
> am
> > largely at a loss.  Using git bisect I am able to track the offending
> commit (at
> > least as far as 1830 goes) to commit 0c69cf, which introduced the
> Coalfields
> > variant.  Digging further, the cities on tile #59 were at positions
> > 052
> and 352
> > before this commit, but at positions 152 and 452 following the commit.
> > >>
> > >> This, one would think, could be easily found in the data files, or
> > >> in
> the
> > code that generates data/Tiles.xml from data/TileDictionary.xml.  I
> > have looked at the previous commit that modified Tiles.xml: I can see
> > the
> change
> > in tile #59 (and presumably other tiles also), but I cannot find any
> changes to
> > the tile database or the program that generates Tiles.xml that look
> > like
> they
> > would cause this change.
> > >>
> > >> I can (and will) continue to try to find the source of the problem,
> > >> as
> clearly
> > hand-editing the generated Tiles.xml files is not a solution, but I
> thought I
> > would ask to see if anyone knows how/why such a change might have
> been
> > introduced.
> > >>
> > >> The two attached savegames show the problem (at least on my end).
> > >> The
> > 1830 savegame has the Erie's home token out of place, and the 1830R
> > savegame has the RDG's token (among others) in the wrong place.  If
> > you
> are
> > checking out old code, note that only the 1830 savegame is likely to
> > work,
> as
> > the 1830 Reading savegame requires fixes that were only released in
> > Rails 1.5.
> > >>
> > >> Bill
> > >>
> > >> -------------------------------------------------------------------
> > >> --
> > >> --------- All the data continuously generated in your IT
> > >> infrastructure contains a definitive record of customers,
> > >> application performance, security threats, fraudulent activity and
> > >> more. Splunk takes this data and makes sense of it. Business sense.
IT
> sense.
> > >> Common sense.
> > >> http://p.sf.net/sfu/splunk-d2dcopy1
> > >> _______________________________________________
> > >> Rails-devel mailing list
> > >> Rai...@li...
> > >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> > >>
> > >>
> > >
> > > --------------------------------------------------------------------
> > > --
> > > -------- All the data continuously generated in your IT
> > > infrastructure contains a definitive record of customers,
> > > application performance, security threats, fraudulent activity and
> > > more. Splunk takes this data and makes sense of it. Business sense. IT
> sense. Common sense.
> > > http://p.sf.net/sfu/splunk-d2dcopy1
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> >
>
----------------------------------------------------------------------------
> --
> > All the data continuously generated in your IT infrastructure contains
> > a definitive record of customers, application performance, security
> > threats, fraudulent activity and more. Splunk takes this data and
> > makes sense of
> it.
> > Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy1
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
>
----------------------------------------------------------------------------
--
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security threats,
> fraudulent activity and more. Splunk takes this data and makes sense of
it.
> Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Tokens misplaced on tile #59?

[Bill R. <ro...@gm...>]

On 2011-10-07, at 4:08 , Erik Vos wrote:

>>> Using git bisect I am able to track the offending commit (at least as
> far as 1830 goes) to commit 0c69cf, which introduced the Coalfields variant.
> Digging further, the cities on tile #59 were at positions  052 and 352
> before this commit, but at positions 152 and 452 following the commit.
>>> 
> 
> This puzzles me. As far as I can see, the position values 152 and 452 for
> tile #59 exist since the introduction of these codes 6 years ago.

This may all be a waste of time, if the problem is simply in the display code, or can be easily fixed in the display code, but git claims that tile #59 changed at commit 0c69cf on 13 Feb 2011.  Specifically, the following three consecutive commits (of those commits that affect the file tiles/Tiles.xml ) are relevant for what I describe below:

30628c - 14 Mar 2011 - Extra off-map tiles for 18VA (and others)
0c69cf - 13 Feb 2011 - Initial commit for 1830 Coalfields
98c5dd - 18 Dec 2010 -  1889 fixes:

When comparing it is easier for me to take diffs between 30628c and 98c5dd, as the file in 0c69cf doesn't seem to have any linebreaks in it that diff will understand.  By visual inspection the code for tile #59 is identical in both 0c69cf and 30628c (up to linebreaks).

When I do the following in the tiles/ subfolder of rails, I get the following output:

rosgen@thales tiles $ git checkout 30628c5
HEAD is now at 30628c5... Extra off-map tiles for 18VA (and others)

rosgen@thales tiles $ git diff 98c5dd -- Tiles.xml | grep -A 7 id\=\"59\"
    <Tile colour="green" id="59" name="59">
-       <Station id="city1" position="052" slots="1" type="City" value="40"/>
-       <Station id="city2" position="352" slots="1" type="City" value="40"/>
+       <Station id="city1" position="152" slots="1" type="City" value="40"/>
+       <Station id="city2" position="452" slots="1" type="City" value="40"/>
        <Track from="city1" gauge="normal" to="side1"/>
        <Track from="city2" gauge="normal" to="side3"/>
    </Tile>

I can find no reason for this change.  The tile dictionary and the code used to generate Tiles.xml (in utils/ ) shows no changes that look like they could cause this to happen.

When I hand-edit the Tiles.xml file for 1830 to revert to 052/352 in place of 152/452, the tokens once more line up with the stops on the tile, but this is not a good solution.

Bill

Re: [Rails-devel] Tokens misplaced on tile #59?

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

It turns out that I had overlooked an earlier commit (417750, dated
28-2-2008) in which the reverse change (152/452 -> 052/352) had occurred.
That commit included changes to fix exactly this problem.  
The later commit you have found has reverted that. I'm pretty sure that the
Tiles.xml versions in this commit had been recreated from scratch (i.e.,
from TileDesigner output).  
So the Tiles.xml generation process must have been broken. It might not have
helped that for a long time we have had two versions of ConvertTilesXML.java
around.

I have finally found the root cause: the position codes of the corner-facing
cities in the currently remaining version of ConvertTilesXML.java were all
wrong.  Subtracting 100  (mod 600) from each one has now fixed that.
I have recreated the Tiles.xml files for 1825, 1830 and 1835, and the
generic version.  I'm not aware of other games where this problem might show
up and has not been fixed before. 

I have also added an XML-formatting Perl script, named formatxml.pl, that I
will use from now on in my Tiles.xml-creating scripts (actually .bat files).
I have put this Perl script into the repository (under tools) so others can
use it if wanted.  It should be platform- and machine-independent (and
therefore does not have a #! first line, and writes files in binmode).
Please keep it that way.
See also my next mail on formatting issues.

Erik.


> -----Original Message-----
> From: Bill Rosgen [mailto:ro...@gm...]
> Sent: Friday, October 07, 2011 7:44 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Tokens misplaced on tile #59?
> 
> 
> On 2011-10-07, at 4:08 , Erik Vos wrote:
> 
> >>> Using git bisect I am able to track the offending commit (at least
> >>> as
> > far as 1830 goes) to commit 0c69cf, which introduced the Coalfields
variant.
> > Digging further, the cities on tile #59 were at positions  052 and 352
> > before this commit, but at positions 152 and 452 following the commit.
> >>>
> >
> > This puzzles me. As far as I can see, the position values 152 and 452
> > for tile #59 exist since the introduction of these codes 6 years ago.
> 
> This may all be a waste of time, if the problem is simply in the display
code, or
> can be easily fixed in the display code, but git claims that tile #59
changed at
> commit 0c69cf on 13 Feb 2011.  Specifically, the following three
consecutive
> commits (of those commits that affect the file tiles/Tiles.xml ) are
relevant
> for what I describe below:
> 
> 30628c - 14 Mar 2011 - Extra off-map tiles for 18VA (and others) 0c69cf -
13
> Feb 2011 - Initial commit for 1830 Coalfields 98c5dd - 18 Dec 2010 -  1889
fixes:
> 
> When comparing it is easier for me to take diffs between 30628c and
98c5dd,
> as the file in 0c69cf doesn't seem to have any linebreaks in it that diff
will
> understand.  By visual inspection the code for tile #59 is identical in
both
> 0c69cf and 30628c (up to linebreaks).
> 
> When I do the following in the tiles/ subfolder of rails, I get the
following
> output:
> 
> rosgen@thales tiles $ git checkout 30628c5 HEAD is now at 30628c5... Extra
> off-map tiles for 18VA (and others)
> 
> rosgen@thales tiles $ git diff 98c5dd -- Tiles.xml | grep -A 7 id\=\"59\"
>     <Tile colour="green" id="59" name="59">
> -       <Station id="city1" position="052" slots="1" type="City"
value="40"/>
> -       <Station id="city2" position="352" slots="1" type="City"
value="40"/>
> +       <Station id="city1" position="152" slots="1" type="City"
value="40"/>
> +       <Station id="city2" position="452" slots="1" type="City"
> + value="40"/>
>         <Track from="city1" gauge="normal" to="side1"/>
>         <Track from="city2" gauge="normal" to="side3"/>
>     </Tile>
> 
> I can find no reason for this change.  The tile dictionary and the code
used to
> generate Tiles.xml (in utils/ ) shows no changes that look like they could
> cause this to happen.
> 
> When I hand-edit the Tiles.xml file for 1830 to revert to 052/352 in place
of
> 152/452, the tokens once more line up with the stops on the tile, but this
is
> not a good solution.
> 
> Bill
>
----------------------------------------------------------------------------
--
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel