[Cs5500] Fwd: Fwd: [Req #95165] Fwd: Idle Crash?

Sun Oct 30 14:39:45 EDT 2011

Enclosed is the feedback from Ravi.

I am busy with grading the algorithm midterm.

-- Karl

---------- Forwarded message ----------
From: Ravishankar Rajagopal <rajagopal.r at husky.neu.edu>
Date: Sat, Oct 29, 2011 at 10:45 PM
Subject: Re: [Cs5500] Fwd: [Req #95165] Fwd: Idle Crash?
To: Karl Lieberherr <lieber at ccs.neu.edu>

Hello Professor,

Please find below the feedback on the document. Let me know if you have any
questions. Thanks.

I generally found the document to be much more informative and i have a
listed a few minor mistakes which could be corrected to improve
readability.

The only major question that i have is with regard to the location
mentioned in section 2. Have or will the students be provided with the
source code or do they have to pick it from some location on the ccis
network?

1. In the last paragraph of the introduction section, the first line states
that k is a value and then the last line in the same paragraph states that
k is a property.  Also just to be formally correct, the last line could say
"... that for all instances in K satisfying ...."
2. Section 1.1.4 - Replace the dotted notation with a closed interval
notation.
3. Section 2 lists propose as a method to be modified and then suggests
that no changes are required for this function? The homework however asks
for an implementation of this function?
4. Section 2.1 - Point 5 - The line should be "If an avatar ...
MinProposals OR greater ...". It should not have and.

Regards,
Ravi Rajagopal

On Fri, Oct 28, 2011 at 11:56 AM, Karl Lieberherr <lieber at ccs.neu.edu>wrote:

> Hi Ravi:
>
> here is the next version of the Avatar Designer Guide.
> Please can you give detailed feedback about how to improve it.  I think
> you like this second version better; it is still being worked on.
>
> -- Karl
>
> ---------- Forwarded message ----------
> From: Madhuvanthi Balasubramanian <balasubramanian.m at husky.neu.edu>
> Date: Thu, Oct 27, 2011 at 1:55 PM
> Subject: Re: [Cs5500] Fwd: [Req #95165] Fwd: Idle Crash?
> To: Karl Lieberherr <lieber at ccs.neu.edu>
>
>
> Professor,
>
>         I have updated the design document with the following:
>          1. Split tournament management into 2 sections, the first section
> describing the admin's responsibilities, and the second, the avatar's
> responsibilities.
>          2. Added an "Understanding the Tournaments Page" section, under
> avatar's responsibilities
>          3. Added the GNU screen section.
>
>          Please let me know if there are any issues.
>
> On Wed, Oct 26, 2011 at 3:38 PM, Karl Lieberherr <lieber at ccs.neu.edu>wrote:
>
>> The Avatar Designer Guide does not mention this issue of disconnected
>> avatars that we had last semester. According to Ahmed this is still
>> relevant.
>>
>> Our users might really be unhappy if they follow your instructions
>> but then their avatar is disconnected.
>>
>> Please check this out and add the use of GNU Screen to the instructions.
>>
>> Currently team Navi (and Jessica) are working on the Guide because
>> team Spartan has a final tomorrow.
>>
>> -- Karl
>>
>> ---------- Forwarded message ----------
>> From: Ahmed Abdelmeged <mohsen at ccs.neu.edu>
>> Date: Wed, Oct 26, 2011 at 2:45 PM
>> Subject: Re: [Req #95165] Fwd: Idle Crash?
>> To: Karl Lieberherr <lieber at ccs.neu.edu>
>> Cc: Sandeep Upendra Kamath <kamath.s at husky.neu.edu>, karan at ccs.neu.edu
>>
>>
>> To the best of my knowledge, it is still relevant.
>> This will only go away when the players are not required to maintain the
>> same IP address during a single game.
>>
>> One way is to have a different communication architecture. A central
>> server that players keep poling for protocol requests they should handle.
>>
>>
>> On Wed, Oct 26, 2011 at 2:38 PM, Karl Lieberherr <lieber at ccs.neu.edu>wrote:
>>
>>> Hi Ahmed:
>>>
>>> is this issue about terminated connections no longer relevant with the
>>> new system SCG Court?
>>>
>>> No need to use GNU Screen?
>>>
>>> -- Karl
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Christopher Allison via RT <systems at ccs.neu.edu>
>>> Date: Wed, Feb 9, 2011 at 4:16 PM
>>> Subject: [Req #95165] Fwd: Idle Crash?
>>> To: lieber at ccs.neu.edu
>>> Cc: chadwick at ccs.neu.edu, danhang at ccs.neu.edu, marcucci.dan at gmail.com,
>>> mgomrokchi at gmail.com, mohsen at ccs.neu.edu, skotthe at ccs.neu.edu
>>>
>>>
>>> Hello Karl,
>>>
>>> I have passed on your inquiry about dedicated machine(s) for your class
>>> to David. He has asked if you would be free to meet with us to discuss
>>> this. Unfortunately David is busy all day tomorrow, but he and I are
>>> both free from 12:30 to 3:00, Friday afternoon. Are you free at all
>>> during that time?
>>>
>>> Meanwhile, here are the resources I told you about.
>>>
>>> Public machines:
>>>
>>> Our public machines are login.ccs.neu.edu and the hosts in 102. You can
>>> access a list of those hosts from the link on
>>> http://howto.ccs.neu.edu/howto/unixlinux/linux-at-ccis/
>>>
>>> You can also access the same list from any managed linux machine with
>>> the command /ccis/bin/linuxmachines
>>>
>>> GNU Screen:
>>>
>>> One very good tool for anyone concerned about being disconnected from a
>>> long running process on a remote terminal is GNU screen. This program
>>> allows you to start one or more processes running in a unix shell
>>> session, "detach" from that shell session, and then "reattach" to it
>>> later from the same connection you first used, or from another
>>> connection. Having a connection terminated (eg: as happens to your
>>> student) is the same as a "detach" - nothing prevents you from easily
>>> reattaching upon reconnecting.
>>>
>>> screen is very powerful, but easy to start using. Example:
>>>
>>> 1) Connect to a remote host (ie: ssh to login.ccs.neu.edu): This will
>>> vary based on your ssh client.
>>>
>>> 2) Run screen (only do this one time):
>>>
>>> > cba at login:~ $ screen <enter>
>>>
>>> 3) Upon starting up, screen will display a welcome message. You can
>>> either read this or not, as your preference dictates. When done reading,
>>> press <enter>
>>>
>>> 4) You are now back at a shell prompt, but are running within screen.
>>> Start some program (eg: the game client) as if this were a normal shell
>>> session, eg:
>>>
>>> > cba at login:~$ vim somefile.txt <enter>
>>>
>>> 5) Detach or lose your connection: To detach from your running screen
>>> session but leave the program you just started running, type ctrl-a, d
>>> (Control key + "A" key (lowercase), then just "D" key (lowercase)). This
>>> will look like this:
>>>
>>> > cba at login:~ $ screen
>>> > [detached]
>>> > cba at login:~ $
>>>
>>> (note the "[detached]", and the absence from your shell of the program
>>> you were just running). If you don't manually detach your screen
>>> session, but instead just lose an ssh connection (eg: your lose network,
>>> sleep/hibernate your local machine, close your ssh client, etc), the
>>> effect is the same as if you had manually detached.
>>>
>>> 6) Reattach: To attach back to the screen session from which you
>>> previously detached (or from which you were separated due to
>>> network/ssh/etc problems), just run "screen -x", eg:
>>>
>>> > cba at login:~ $ screen -x <enter>
>>>
>>> Your display should now be restored to the state it was in when you
>>> previously detached from or lost connectivity to your screen session.
>>>
>>> ---
>>>
>>> Two caveats:
>>>
>>> - If you run more than one screen session (eg: run "screen" rather than
>>> "screen -x" on the same host more than once without first exiting your
>>> previous screen session(s)), you will be greeted with an error message
>>> asking you to select the screen session to which you want to reattach.
>>>
>>> Simply run "screen -x $SESSION" (where $SESSION is generally of the form
>>> process_id.tty.host, eg: 1234.pts-99.login) to attach to a given screen
>>> session. I suggest that if you do accidentally start more than one
>>> screen session, you exit all but one, so as to keep things simple. See
>>> below for how to exit a screen session.
>>>
>>> - Because screen takes over your entire (virtual) terminal, it is
>>> (generally) not possible to scroll back output in screen. As such, if
>>> you want to run something from within screen which will produce a lot of
>>> output, and you want to review that output, it is generally wise to pipe
>>> that output to pager (eg: "| less" or "| more") or redirect it to some
>>> file to review later (eg: "> mylogfile.txt").
>>>
>>>
>>> Notes:
>>>
>>> - To fully exit a screen session (bringing your entire screen process to
>>> a close), simply attach as per the directions above, end any programs
>>> running within the screen session, and exit the shell as you would
>>> normally (eg: "logout", "exit", ctrl-d, etc). You will know that you
>>> have exited screen because after clearing its output, instead of
>>> displaying "[detached]", screen will instead display "[screen is
>>> terminating]", eg:
>>>
>>> > cba at login:~ $ screen -x
>>> > [screen is terminating]
>>> > cba at login:~ $
>>>
>>> - screen has abilities far beyond those I've outlined above, including
>>> process control (eg: menu-based kill) of processes running within it,
>>> the ability to have up to 40 virtual "windows" (terminals) instead of
>>> just one, and various other useful features. For more information on
>>> these, I suggest consulting screen's man page, or performing a web
>>> search.
>>>
>>> I have long said that screen is one of those programs without which I
>>> would find systems administration to be much more complex and
>>> frustrating. I hope that you find it as useful as I have.
>>>
>>> Best,
>>>
>>> -Chris Allison
>>> --
>>> UNIX Systems Administrator
>>> College of Computer and Information Science
>>> Northeastern University, Boston, MA
>>>
>>>
>>
>>
>> --
>> Ahmed
>>
>>
>> _______________________________________________
>> Cs5500 mailing list
>> Cs5500 at lists.ccs.neu.edu
>> https://lists.ccs.neu.edu/bin/listinfo/cs5500
>>
>>
>
>
> --
>  Thanks
> - Madhu
>
>
>
-------------- next part --------------
HTML attachment scrubbed and removed