[Cs5500] Cs5500 Digest, Vol 3, Issue 35

Fri Apr 22 12:08:07 EDT 2011

Hi Reto,
    The history file parsing is fails because i had appended the player
final scores at the end of the file, which is not a part of RawHistory
object. If we remove the last two line from the history file the parsing
wont fail.

regards,
Gautam

On Fri, Apr 22, 2011 at 12:00 PM, <cs5500-request at lists.ccs.neu.edu> wrote:

> Send Cs5500 mailing list submissions to
>        cs5500 at lists.ccs.neu.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.ccs.neu.edu/bin/listinfo/cs5500
> or, via email, send a message with subject or body 'help' to
>        cs5500-request at lists.ccs.neu.edu
>
> You can reach the person managing the list at
>        cs5500-owner at lists.ccs.neu.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Cs5500 digest..."
>
>
> Today's Topics:
>
>   1. Possible whitespace issues using the DemF print() function
>      (Reto Kleeb)
>   2. Re: Possible whitespace issues using the DemF print()
>      function (Patrick Lannigan)
>   3. Collecting Ideas to systematically verify the contents of the
>      raw history (Reto Kleeb)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 21 Apr 2011 13:29:56 -0400
> From: Reto Kleeb <kleeb.r at husky.neu.edu>
> Subject: [Cs5500] Possible whitespace issues using the DemF print()
>        function
> To: Managing Software Development <cs5500 at lists.ccs.neu.edu>
> Message-ID: <4DB06994.3020105 at husky.neu.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hey,
>
> about a week ago we discussed that a system that serializes objects to
> strings (and back), (eg. XML or like in our case in DemF defined syntax)
> should have the following property:
>
> String serialized = "MY-OBJECT AS A STRING"
> Object myObj = Object.parse(serialized)
>
> assertEquals(serialized, myObj.serializeToString())
>
> and
>
> assertEquals(myObj, Object.parse(myObj.serializeToString()))
>
> It could be argued that these two tests do the same, but I argue that
> only if we include the first test, we verify our system against a
> "hand-written, visible" string.
>
> In our project such a test looks like this:
>
> String inpt = "hsr.HSRInstanceSet {{ HSR (9,2) }}
> scg.protocol.ForAllExists {{    }} 0.44444 0.44444";
>
> Claim claim = Claim.parse(inpt);
>
> Assert.assertEquals(inpt, claim.print());
>
> The problem now is, that this test fails, DemeterF adds an extra white
> space character in the printed string
> (http://img685.imageshack.us/i/demfwhitespace.png/). This is obviously
> related to the *s in the grammar.
>
> Now our question basically is, is this something that we need to accept
> in this situation? Or can we get DemeterF to omit these extra characters
> without changing the grammar?
>
> Best
>
> Reto (PRX)
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 21 Apr 2011 14:19:37 -0400
> From: Patrick Lannigan <lannigan at ccs.neu.edu>
> Subject: Re: [Cs5500] Possible whitespace issues using the DemF
>        print() function
> To: Reto Kleeb <kleeb.r at husky.neu.edu>
> Cc: Managing Software Development <cs5500 at lists.ccs.neu.edu>
> Message-ID: <BANLkTi=TUVCMnUM-p3XEzVc44nikEdcN6w at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I agree that both tests are important.
>
> The first tests that the system serializes to the format it was
> de-serialized from. The serialization code should always produce the same
> output for the same object. So this could reveal that the the input
> definition is not restrictive enough and allows A and B to both
> de-serialize
> to O. I would expect that if A != B, then parse(A) != parse(B).
>
> The second test ensures that the system preoduces an equivalent object when
> parsing the serialized version it created.
>
> As for what to do about the current situation, I think that this is
> something that will likely not be solved by Monday. This is much more about
> dealing with the idiosyncrasies of demeterf than it is getting the system
> running. It is more important that we can correctly run tournaments and
> games, write history and log files, and represent the state of the system
> in
> the UI. If the only case where parse(A) == parse(B) are when A and B are
> logically equivalent, but have different white spacing, I think it makes
> sense to let this be one of the things that would be solved in the next
> round of development.
>
> Patrick
>
> On Thu, Apr 21, 2011 at 1:29 PM, Reto Kleeb <kleeb.r at husky.neu.edu> wrote:
>
> > Hey,
> >
> > about a week ago we discussed that a system that serializes objects to
> > strings (and back), (eg. XML or like in our case in DemF defined syntax)
> > should have the following property:
> >
> > String serialized = "MY-OBJECT AS A STRING"
> > Object myObj = Object.parse(serialized)
> >
> > assertEquals(serialized, myObj.serializeToString())
> >
> > and
> >
> > assertEquals(myObj, Object.parse(myObj.serializeToString()))
> >
> > It could be argued that these two tests do the same, but I argue that
> > only if we include the first test, we verify our system against a
> > "hand-written, visible" string.
> >
> > In our project such a test looks like this:
> >
> > String inpt = "hsr.HSRInstanceSet {{ HSR (9,2) }}
> > scg.protocol.ForAllExists {{    }} 0.44444 0.44444";
> >
> > Claim claim = Claim.parse(inpt);
> >
> > Assert.assertEquals(inpt, claim.print());
> >
> > The problem now is, that this test fails, DemeterF adds an extra white
> > space character in the printed string
> > (http://img685.imageshack.us/i/demfwhitespace.png/). This is obviously
> > related to the *s in the grammar.
> >
> > Now our question basically is, is this something that we need to accept
> > in this situation? Or can we get DemeterF to omit these extra characters
> > without changing the grammar?
> >
> > Best
> >
> > Reto (PRX)
> >
> >
> >
> > _______________________________________________
> > Cs5500 mailing list
> > Cs5500 at lists.ccs.neu.edu
> > https://lists.ccs.neu.edu/bin/listinfo/cs5500
> >
> -------------- next part --------------
> HTML attachment scrubbed and removed
>
> ------------------------------
>
> Message: 3
> Date: Thu, 21 Apr 2011 17:26:55 -0400
> From: Reto Kleeb <kleeb.r at husky.neu.edu>
> Subject: [Cs5500] Collecting Ideas to systematically verify the
>        contents of the raw history
> To: Managing Software Development <cs5500 at lists.ccs.neu.edu>
> Message-ID: <4DB0A11F.6070702 at husky.neu.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hey class,
>
> last night we discovered that the raw history contained items that did
> not make sense. The way I remember it, somebody claimed that in such a
> case (erroneous history)
>
> RawHistory.parse(historyContents);
>
> would not be successful. We could not reproduce this, the way the
> RawHistory is written, it should always produce valid entries (at least
> according to the grammar).
>
> So our question is, do we have a history file that actually does fail to
> parse?
>
>
> SVN Issues:
> ---------------------
> Some of you might have noticed that our SVN provider assembla does
> currently have some issues, they are affected by the amazon outage:
> http://blog.assembla.com/
>
>
>
> Reto (PRX)
>
>
>
> ------------------------------
>
> _______________________________________________
> Cs5500 mailing list
> Cs5500 at lists.ccs.neu.edu
> https://lists.ccs.neu.edu/bin/listinfo/cs5500
>
>
> End of Cs5500 Digest, Vol 3, Issue 35
> *************************************
>
-------------- next part --------------
HTML attachment scrubbed and removed