gee-guys Mailing List for Group Experiments Environment
Status: Alpha
Brought to you by:
alllee
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
(5) |
Apr
(37) |
May
(43) |
Jun
(3) |
Jul
(6) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Allen L. <al...@cs...> - 2004-08-03 19:31:44
|
Hey Michael, I'm in the middle of porting the bots over, just wanted to respond to your readme packaged with the bots for Andy's benefit as well. > > Hey guys, > > 1. I've changed some variable names and such, so hopefully > everything is coherent, but there's definitely the possibility that I > mangled a variable or bit of logic in the transition, so contact me if > anything seems off or if you just want me to clarify something. > Whenever you've incorporated the agents, maybe we could run some > experiments with all agents and certain parameters, just to make sure > it's similar to what I was getting before. Will do, the bot integration should be done sometime this evening if all goes well. > > 2. An issue I hadn't thought about: I'm not sure how you guys are > handling movement, with continuous values or from discrete cell to > discrete cell. I think Ben did the former, but I did the latter. If > you're doing it continuously, it should still be really easy to > integrate my code, but the movement rate will be different than what I > used in my simulations, so we may have to calibrate it a bit to work > out well with humans. A related issue is that in the future, we may > want some people (both humans and agents, I guess) to move faster than > others to see how that changes individual strategies. From a > continuous standpoint, that means the faster people could just take > bigger steps, but from a discrete standpoint, it might mean that they > should have a faster tick update cycle. Maybe a similar issue would > arise in the social choice experiments if you wanted some people to > get multiple guesses in the same amount of time as another person. We're doing the discrete thing right now because it's much simpler to model and you're right, we can still simulate 'faster' people by modifying how often they send their updates. So.. we should be good. Basically I'm grokkin the code and figuring out how I can do the least amount of work to get the bots to talk to the server's world instead of maintaining their own forager grid world of tasty food. > > 3. I'm guessing that the agents' parameters will be part of the > input script, and if so, we'll know the params just by having recorded > what script was used in a particular experiment. But if that's not > the case, I want to make sure we store those params for each > experiment so we can compare behavior based on the params. Also, > we'll want to record the respective numbers of agents and humans in > each experiment, and I was thinking it would be best to make a clear > delineation between the humans and the agents in the output file. For > instance, maybe the top of the output file will say that there's 9 > humans and 11 agents, then at each time step, the file would first > have the locations and food acquired for each of the 9 humans, then > for each of the 11 agents, then the pellet locations (at least that > was the previous format). For a lot of analyses, we'd probably just > want to look at the human data, but for some things I think it would > be cool to compare the human performance vs. the agents, given that we > know what's driving the agents. Definitely. How should agent parameters be configured anyhow? Right now we are using a hierarchical type of configuration with a master configuration file specifying global parameters for the entire experiment server and tiny slave configuration files specifying details for individual rounds or sessions (multiple rounds) of experiments... it'd be cool to turn them into XML eventually because then we can avoid some ugliness in the files (specifying multiple or optional things is a little easier with XML, you don't have to do stuff like num-food-regions 2 food-region1 37 23 food-region2 23 47 Instead you can do stuff like: <food-regions> <location x-coord=37 y-coord=23 weight=14 /> <location x-coord=23 y-coord=47 weight=8 /> </food-regions> Arguably it is a bit easier to see what the config file means when its in XML... I'm tending towards having the bots be wired up via a separate set of configuration files still under the master configuration's control. > > 4. I've included two folders: forager_invis and forager_vis. > Forager_invis is responsible for the invisible food/invisible agents > condition, but it also handles the invisible food/visible agents > condition by doing everything the same (in terms of storing cell > values and increasing or decreasing the values based on their reward > history), but it sets the agent density parameter > 0, so that an > agent is weighing the desirability of a cell by also taking into > account how many agents are temporarily near the cell (on one hand, > you may not want to move there because it's too crowded, but on the > other hand, if you haven't figured out where any food is, it might be > in your best interest to go where a crowd is, and we can switch > between those behaviors by making the parameter negative or positive). > Likewise, forager_vis handles the visible food/visible agents case, > and it also handles the visible food/invisible agents case by setting > the agent density parameter to 0, so you're still choosing between > pieces of food based on how close you are, goal bias, and food density > (which I didn't mention yesterday, but it works like agent density, > except a piece of food is more desirable if other pieces of food are > nearby), but you don't have any information on other agents' > locations. With both models, I calculate a couple of things -- like > agent density -- outside of the agent class, because it's identical > for everyone, so it's quicker to do it once and then pass the result > to everyone. > > For forager_invis: > Main, Agent_List, and Agent_Invis_Cluster are the important files. > Main starts the program, sets the initial params (based on the the > blocks of sessions I want to try, but > for your purposes, you'll probably be able to discard all of Main), > and runs particular sessions via the timers for food dropping and > agent updating. What actually matters to you is in AgentList and > Agent_Invis_Cluster. I think all the functions in them can be > combined more meaningfully to just be an Agent class, but I separated > them at some point for dumb historic reasons of how I was running the > simulator and iterating through agents. > Whenever the timer in Main (experiment()) leads to an agent update > call, updateAgents is called in AgentList, and it has each agent > decide on their next movement (based on actionSelection in AgentList, > which should really be part of the Agent_Invis_Cluster class), then > they move (based on the move function that is in Agent_Invis_Cluster), > then "update" is called in Agent_Invis_Cluster, which essentially > takes care of the appropriate rewards, penalties and regeneration. > There's a bit of a distinction in that each grid cell's long-term > value is based on its starting value, then the history of rewards, > penalties, and possibly regeneration. But when an agent chhoses a > cell in actionSelection, a cell's value can also be affected by > whether or not it's currently the goal (which means it was chosen at > the previous time step, so you're already heading towards it and are > therefore likely -- but not definitely -- going to continue towards > it) and, if agents are visible, by the density of agents around the > cell. > I've left in the code for regeneration and inertia movement bias > (bias to keep going in the same direction), even though they don't > seem necessary for the data collected so far. You can either include > them and we'll just set their parameters to 0 for now, or don't worry > about them and we can add them in the future if necessary. > > For forager_vis: > I didn't include FoodRegion or FoodBin beause they're the same as in > forager_invis. The only thing that might be worth noticing is that I > have some code in FoodRegion to deposit food with uniform variance (in > a square, actually, not a circle) of different sizes, because I ran > some experiments where I wanted to compare how agents do based on food > density, which is harder to compare with gaussian distributions. > The set-up is similar. This time actionSelection is inside the > Agent_Visible class, but I calculate a couple of things -- agent > density and food density -- in AgentList and send the result to > everyone since they can all see the same thing. If the agents were > invisible, then the agent density parameter would be set to 0. One > minor detail is that the agents may not have anything to choose from > if no food is on the screen, so in that case they just keep moving > towards their previous goal, or stay at their goal if they've already > reached it. Regardless, it's extremely rare that all of the food has > been eaten, and new food appears very quickly. > Thanks for the docs, Michael, I'll let you know if I have any questions in the meantime! Allen |
|
From: Allen L. <al...@cs...> - 2004-07-09 15:41:41
|
Does the identity of the mini experiment matter so long as all of its
configuration parameters are written out? I was under the impression that
there wouldn't be as many canned mini experiments because of the always-on
nature of the new experiments..
On Thu, Jul 08, 2004 at 08:36:41PM -0700, Robert Goldstone wrote:
> It might not hurt to have the sampling rate be configurable. I could see
> different kinds of experiments wanting different resolutions. It's no big
> deal though. If you want a single rate, I'd recommend sampling once every 2
> seconds -- that's what we did before. More often than that and we tend to
> get files that are too big.
>
> Each line of data should have the {X,Y} location of each subject, their
> total amount of food, and also the number of food pieces on the screen and
> their {X,Y} locations. I don't think you need to write out client numbers
> if we assume that the data is printed out in order -- the first set of
> coordinates and #food eaten belongs to Agent #1 for example.
>
> Also, at the beginning of each experiment, you should write out in the same
> output file the number of pools, their coordinates, their replenishment
> rates if this isn't clear from the configuration file, the number of agents,
> and a number that reflects WHICH mini-experiment is being run (because each
> experiment consists of several mini-experiments with different parameters
> potentially).
>
>
> > Hey Rob, another quick question - how often do we need to sample the data
> > collection, and what data needs to be collected (currently client number,
> > location, total amount of food consumed). Does this need to be configurable
> > as well?
> >
> > Allen
> >
> > On Thu, Jul 01, 2004 at 11:07:56AM -0500, Rob Goldstone wrote:
> >> Hi Allen,
> >> An experiment can't really be a set of rounds, because people will be coming
> >> in and out. If we could imprison subjects for an hour or so, then we could
> >> be sure of having the same subjects, but we can't do this. So, the short
> >> answer to your question is that a "per round" makes sense. Each 5-10 minute
> >> experiment is logically independent of the others, even though there may be
> >> an orderly arrangement to which configurations of an experiment are
> >> presented when. In terms of statistical analyses, this means that we'll be
> >> using "between-subjects" rather than "within-subject" designs.
> >>
> >> The rest of what you describe makes good sense. For Forager and social
> >> choice I'm not envisioning any upper limit to the number of people involved.
> >> So, I don't expect we'll be spawning new experiments if one is filled up.
> >> This is fine functionality to include though, because I could imagine it
> >> coming up down the road.
> >> Ciao,
> >> Rob
> >>
> >>> Andy and I have come up with an issue that I thought would be good to have
> >>> some feedback on. We've been discussing how we want to implement the
> >>> 'waiting
> >>> room' functionality. Right now we're leaning towards the following
> >>> interaction model:
> >>>
> >>> 1. User hits the web page listing available games. Web page checks KNS to
> >>> see
> >>> which services are available and dynamically generates hyperlinks encoded
> >>> with
> >>> the specific host and port information for that particular server.
> >>>
> >>> 2. User clicks on a specific hyperlink, that takes them to the applet,
> >>> automatically connecting them to that experiment server.
> >>>
> >>> 3. Here's where we need some clarification or at least a "yes keep doing
> >>> that". We decided to 'throttle' connections at the experiment server end,
> >>> not
> >>> the KNS end. This means that people will be making connections to the
> >>> experiment server regardless of whether or not an experiment is already in
> >>> progress, etc. What we plan to do here is the following:
> >>> a. If there is no experiment session is in progress, or all current
> >>> experiment sessions are already full, a new experiment session is started.
> >>> We're going to have to worry about dealing with a maximum allowable limit
> >>> to this, of course, but we're leaving that for later since it's not
> >>> immediately needed.
> >>>
> >>> b. If there is an experiment session in progress and it is not full, the
> >>> user gets queued up for that particular experiment session and begins
> >>> playing in that experiment session in the next round. I was wary of this
> >>> idea when Andy first mentioned it because I had some artificial notion
> >>> that an experiment was a logical set of rounds, and the participants for a
> >>> given experiment should remain static throughout this set to keep it
> >>> cohesive. Since experiments will be randomized anyhow, we're leaning
> >>> towards the per-round implementation, so a user connects to the forager
> >>> server and gets slapped into the next round of forager.
> >>>
> >>> DING: Here's where we need confirmation/clarification. Do participants join
> >>> on a per-round basis or on a per experiment session basis? Will this change
> >>> for other experiments? Also, how long do we keep running these rounds? Do
> >>> we
> >>> let someone play forager for 37 hours? Do you need to interpret their data
> >>> differently?
> >>>
> >>> This is a pretty trivial question, but it's kind of a stumbling block right
> >>> now.
> >>>
> >>> Thoughts?
> >>>
> >>>
> >>>
> >>> -------------------------------------------------------
> >>> This SF.Net email sponsored by Black Hat Briefings & Training.
> >>> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> >>> digital self defense, top technical experts, no vendor pitches,
> >>> unmatched networking opportunities. Visit www.blackhat.com
> >>> _______________________________________________
> >>> gabel-guys mailing list
> >>> gab...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/gabel-guys
> >>>
> >>>
> >>>
> >
> >
> >
>
> ___________________________________________________
> Dr. Robert Goldstone
> Professor of Psychology, Program in Cognitive Science
> Psychology Building
> 1101 E 10th St.
> Indiana University
> Bloomington, IN. 47405-7007.
> 812-855-4853 (work). 812-333-0152 (home). 812-855-4691 (fax)
> Email: rgo...@in...
> Percepts and Concepts Laboratory: http://cognitrn.psych.indiana.edu/
|
|
From: Robert G. <rgo...@in...> - 2004-07-09 01:37:26
|
I'd say that agents should be given random starting locations, chosen from a uniform, not gaussian, distribution and covering the whole playing field. > And yet another one - I poked around the config files but didn't see anything > about initial starting locations for players. Should everyone start in the > very middle, or at 0,0, or be placed in a normal distribution or a gaussian > distribution, or off screen ;)? > > On Thu, Jul 08, 2004 at 02:01:39PM -0500, Allen Lee wrote: >> Hey Rob, another quick question - how often do we need to sample the data >> collection, and what data needs to be collected (currently client number, >> location, total amount of food consumed). Does this need to be configurable >> as well? >> >> Allen >> >> On Thu, Jul 01, 2004 at 11:07:56AM -0500, Rob Goldstone wrote: >>> Hi Allen, >>> An experiment can't really be a set of rounds, because people will be coming >>> in and out. If we could imprison subjects for an hour or so, then we could >>> be sure of having the same subjects, but we can't do this. So, the short >>> answer to your question is that a "per round" makes sense. Each 5-10 minute >>> experiment is logically independent of the others, even though there may be >>> an orderly arrangement to which configurations of an experiment are >>> presented when. In terms of statistical analyses, this means that we'll be >>> using "between-subjects" rather than "within-subject" designs. >>> >>> The rest of what you describe makes good sense. For Forager and social >>> choice I'm not envisioning any upper limit to the number of people involved. >>> So, I don't expect we'll be spawning new experiments if one is filled up. >>> This is fine functionality to include though, because I could imagine it >>> coming up down the road. >>> Ciao, >>> Rob >>> >>>> Andy and I have come up with an issue that I thought would be good to have >>>> some feedback on. We've been discussing how we want to implement the >>>> 'waiting >>>> room' functionality. Right now we're leaning towards the following >>>> interaction model: >>>> >>>> 1. User hits the web page listing available games. Web page checks KNS to >>>> see >>>> which services are available and dynamically generates hyperlinks encoded >>>> with >>>> the specific host and port information for that particular server. >>>> >>>> 2. User clicks on a specific hyperlink, that takes them to the applet, >>>> automatically connecting them to that experiment server. >>>> >>>> 3. Here's where we need some clarification or at least a "yes keep doing >>>> that". We decided to 'throttle' connections at the experiment server end, >>>> not >>>> the KNS end. This means that people will be making connections to the >>>> experiment server regardless of whether or not an experiment is already in >>>> progress, etc. What we plan to do here is the following: >>>> a. If there is no experiment session is in progress, or all current >>>> experiment sessions are already full, a new experiment session is >>>> started. >>>> We're going to have to worry about dealing with a maximum allowable limit >>>> to this, of course, but we're leaving that for later since it's not >>>> immediately needed. >>>> >>>> b. If there is an experiment session in progress and it is not full, the >>>> user gets queued up for that particular experiment session and begins >>>> playing in that experiment session in the next round. I was wary of this >>>> idea when Andy first mentioned it because I had some artificial notion >>>> that an experiment was a logical set of rounds, and the participants for >>>> a >>>> given experiment should remain static throughout this set to keep it >>>> cohesive. Since experiments will be randomized anyhow, we're leaning >>>> towards the per-round implementation, so a user connects to the forager >>>> server and gets slapped into the next round of forager. >>>> >>>> DING: Here's where we need confirmation/clarification. Do participants >>>> join >>>> on a per-round basis or on a per experiment session basis? Will this >>>> change >>>> for other experiments? Also, how long do we keep running these rounds? Do >>>> we >>>> let someone play forager for 37 hours? Do you need to interpret their data >>>> differently? >>>> >>>> This is a pretty trivial question, but it's kind of a stumbling block right >>>> now. >>>> >>>> Thoughts? >>>> >>>> >>>> >>>> ------------------------------------------------------- >>>> This SF.Net email sponsored by Black Hat Briefings & Training. >>>> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - >>>> digital self defense, top technical experts, no vendor pitches, >>>> unmatched networking opportunities. Visit www.blackhat.com >>>> _______________________________________________ >>>> gabel-guys mailing list >>>> gab...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gabel-guys >>>> >>>> >>>> >> >> >> ------------------------------------------------------- >> This SF.Net email sponsored by Black Hat Briefings & Training. >> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - >> digital self defense, top technical experts, no vendor pitches, >> unmatched networking opportunities. Visit www.blackhat.com >> _______________________________________________ >> gabel-guys mailing list >> gab...@li... >> https://lists.sourceforge.net/lists/listinfo/gabel-guys > > > ___________________________________________________ Dr. Robert Goldstone Professor of Psychology, Program in Cognitive Science Psychology Building 1101 E 10th St. Indiana University Bloomington, IN. 47405-7007. 812-855-4853 (work). 812-333-0152 (home). 812-855-4691 (fax) Email: rgo...@in... Percepts and Concepts Laboratory: http://cognitrn.psych.indiana.edu/ |
|
From: Robert G. <rgo...@in...> - 2004-07-09 01:36:01
|
It might not hurt to have the sampling rate be configurable. I could see
different kinds of experiments wanting different resolutions. It's no big
deal though. If you want a single rate, I'd recommend sampling once every 2
seconds -- that's what we did before. More often than that and we tend to
get files that are too big.
Each line of data should have the {X,Y} location of each subject, their
total amount of food, and also the number of food pieces on the screen and
their {X,Y} locations. I don't think you need to write out client numbers
if we assume that the data is printed out in order -- the first set of
coordinates and #food eaten belongs to Agent #1 for example.
Also, at the beginning of each experiment, you should write out in the same
output file the number of pools, their coordinates, their replenishment
rates if this isn't clear from the configuration file, the number of agents,
and a number that reflects WHICH mini-experiment is being run (because each
experiment consists of several mini-experiments with different parameters
potentially).
> Hey Rob, another quick question - how often do we need to sample the data
> collection, and what data needs to be collected (currently client number,
> location, total amount of food consumed). Does this need to be configurable
> as well?
>
> Allen
>
> On Thu, Jul 01, 2004 at 11:07:56AM -0500, Rob Goldstone wrote:
>> Hi Allen,
>> An experiment can't really be a set of rounds, because people will be coming
>> in and out. If we could imprison subjects for an hour or so, then we could
>> be sure of having the same subjects, but we can't do this. So, the short
>> answer to your question is that a "per round" makes sense. Each 5-10 minute
>> experiment is logically independent of the others, even though there may be
>> an orderly arrangement to which configurations of an experiment are
>> presented when. In terms of statistical analyses, this means that we'll be
>> using "between-subjects" rather than "within-subject" designs.
>>
>> The rest of what you describe makes good sense. For Forager and social
>> choice I'm not envisioning any upper limit to the number of people involved.
>> So, I don't expect we'll be spawning new experiments if one is filled up.
>> This is fine functionality to include though, because I could imagine it
>> coming up down the road.
>> Ciao,
>> Rob
>>
>>> Andy and I have come up with an issue that I thought would be good to have
>>> some feedback on. We've been discussing how we want to implement the
>>> 'waiting
>>> room' functionality. Right now we're leaning towards the following
>>> interaction model:
>>>
>>> 1. User hits the web page listing available games. Web page checks KNS to
>>> see
>>> which services are available and dynamically generates hyperlinks encoded
>>> with
>>> the specific host and port information for that particular server.
>>>
>>> 2. User clicks on a specific hyperlink, that takes them to the applet,
>>> automatically connecting them to that experiment server.
>>>
>>> 3. Here's where we need some clarification or at least a "yes keep doing
>>> that". We decided to 'throttle' connections at the experiment server end,
>>> not
>>> the KNS end. This means that people will be making connections to the
>>> experiment server regardless of whether or not an experiment is already in
>>> progress, etc. What we plan to do here is the following:
>>> a. If there is no experiment session is in progress, or all current
>>> experiment sessions are already full, a new experiment session is started.
>>> We're going to have to worry about dealing with a maximum allowable limit
>>> to this, of course, but we're leaving that for later since it's not
>>> immediately needed.
>>>
>>> b. If there is an experiment session in progress and it is not full, the
>>> user gets queued up for that particular experiment session and begins
>>> playing in that experiment session in the next round. I was wary of this
>>> idea when Andy first mentioned it because I had some artificial notion
>>> that an experiment was a logical set of rounds, and the participants for a
>>> given experiment should remain static throughout this set to keep it
>>> cohesive. Since experiments will be randomized anyhow, we're leaning
>>> towards the per-round implementation, so a user connects to the forager
>>> server and gets slapped into the next round of forager.
>>>
>>> DING: Here's where we need confirmation/clarification. Do participants join
>>> on a per-round basis or on a per experiment session basis? Will this change
>>> for other experiments? Also, how long do we keep running these rounds? Do
>>> we
>>> let someone play forager for 37 hours? Do you need to interpret their data
>>> differently?
>>>
>>> This is a pretty trivial question, but it's kind of a stumbling block right
>>> now.
>>>
>>> Thoughts?
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email sponsored by Black Hat Briefings & Training.
>>> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
>>> digital self defense, top technical experts, no vendor pitches,
>>> unmatched networking opportunities. Visit www.blackhat.com
>>> _______________________________________________
>>> gabel-guys mailing list
>>> gab...@li...
>>> https://lists.sourceforge.net/lists/listinfo/gabel-guys
>>>
>>>
>>>
>
>
>
___________________________________________________
Dr. Robert Goldstone
Professor of Psychology, Program in Cognitive Science
Psychology Building
1101 E 10th St.
Indiana University
Bloomington, IN. 47405-7007.
812-855-4853 (work). 812-333-0152 (home). 812-855-4691 (fax)
Email: rgo...@in...
Percepts and Concepts Laboratory: http://cognitrn.psych.indiana.edu/
|
|
From: Allen L. <al...@cs...> - 2004-07-08 19:39:31
|
And yet another one - I poked around the config files but didn't see anything about initial starting locations for players. Should everyone start in the very middle, or at 0,0, or be placed in a normal distribution or a gaussian distribution, or off screen ;)? On Thu, Jul 08, 2004 at 02:01:39PM -0500, Allen Lee wrote: > Hey Rob, another quick question - how often do we need to sample the data > collection, and what data needs to be collected (currently client number, > location, total amount of food consumed). Does this need to be configurable > as well? > > Allen > > On Thu, Jul 01, 2004 at 11:07:56AM -0500, Rob Goldstone wrote: > > Hi Allen, > > An experiment can't really be a set of rounds, because people will be coming > > in and out. If we could imprison subjects for an hour or so, then we could > > be sure of having the same subjects, but we can't do this. So, the short > > answer to your question is that a "per round" makes sense. Each 5-10 minute > > experiment is logically independent of the others, even though there may be > > an orderly arrangement to which configurations of an experiment are > > presented when. In terms of statistical analyses, this means that we'll be > > using "between-subjects" rather than "within-subject" designs. > > > > The rest of what you describe makes good sense. For Forager and social > > choice I'm not envisioning any upper limit to the number of people involved. > > So, I don't expect we'll be spawning new experiments if one is filled up. > > This is fine functionality to include though, because I could imagine it > > coming up down the road. > > Ciao, > > Rob > > > > > Andy and I have come up with an issue that I thought would be good to have > > > some feedback on. We've been discussing how we want to implement the 'waiting > > > room' functionality. Right now we're leaning towards the following > > > interaction model: > > > > > > 1. User hits the web page listing available games. Web page checks KNS to see > > > which services are available and dynamically generates hyperlinks encoded with > > > the specific host and port information for that particular server. > > > > > > 2. User clicks on a specific hyperlink, that takes them to the applet, > > > automatically connecting them to that experiment server. > > > > > > 3. Here's where we need some clarification or at least a "yes keep doing > > > that". We decided to 'throttle' connections at the experiment server end, not > > > the KNS end. This means that people will be making connections to the > > > experiment server regardless of whether or not an experiment is already in > > > progress, etc. What we plan to do here is the following: > > > a. If there is no experiment session is in progress, or all current > > > experiment sessions are already full, a new experiment session is started. > > > We're going to have to worry about dealing with a maximum allowable limit > > > to this, of course, but we're leaving that for later since it's not > > > immediately needed. > > > > > > b. If there is an experiment session in progress and it is not full, the > > > user gets queued up for that particular experiment session and begins > > > playing in that experiment session in the next round. I was wary of this > > > idea when Andy first mentioned it because I had some artificial notion > > > that an experiment was a logical set of rounds, and the participants for a > > > given experiment should remain static throughout this set to keep it > > > cohesive. Since experiments will be randomized anyhow, we're leaning > > > towards the per-round implementation, so a user connects to the forager > > > server and gets slapped into the next round of forager. > > > > > > DING: Here's where we need confirmation/clarification. Do participants join > > > on a per-round basis or on a per experiment session basis? Will this change > > > for other experiments? Also, how long do we keep running these rounds? Do we > > > let someone play forager for 37 hours? Do you need to interpret their data > > > differently? > > > > > > This is a pretty trivial question, but it's kind of a stumbling block right > > > now. > > > > > > Thoughts? > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.Net email sponsored by Black Hat Briefings & Training. > > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > > digital self defense, top technical experts, no vendor pitches, > > > unmatched networking opportunities. Visit www.blackhat.com > > > _______________________________________________ > > > gabel-guys mailing list > > > gab...@li... > > > https://lists.sourceforge.net/lists/listinfo/gabel-guys > > > > > > > > > > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > gabel-guys mailing list > gab...@li... > https://lists.sourceforge.net/lists/listinfo/gabel-guys |
|
From: Allen L. <al...@cs...> - 2004-07-08 19:01:50
|
Hey Rob, another quick question - how often do we need to sample the data collection, and what data needs to be collected (currently client number, location, total amount of food consumed). Does this need to be configurable as well? Allen On Thu, Jul 01, 2004 at 11:07:56AM -0500, Rob Goldstone wrote: > Hi Allen, > An experiment can't really be a set of rounds, because people will be coming > in and out. If we could imprison subjects for an hour or so, then we could > be sure of having the same subjects, but we can't do this. So, the short > answer to your question is that a "per round" makes sense. Each 5-10 minute > experiment is logically independent of the others, even though there may be > an orderly arrangement to which configurations of an experiment are > presented when. In terms of statistical analyses, this means that we'll be > using "between-subjects" rather than "within-subject" designs. > > The rest of what you describe makes good sense. For Forager and social > choice I'm not envisioning any upper limit to the number of people involved. > So, I don't expect we'll be spawning new experiments if one is filled up. > This is fine functionality to include though, because I could imagine it > coming up down the road. > Ciao, > Rob > > > Andy and I have come up with an issue that I thought would be good to have > > some feedback on. We've been discussing how we want to implement the 'waiting > > room' functionality. Right now we're leaning towards the following > > interaction model: > > > > 1. User hits the web page listing available games. Web page checks KNS to see > > which services are available and dynamically generates hyperlinks encoded with > > the specific host and port information for that particular server. > > > > 2. User clicks on a specific hyperlink, that takes them to the applet, > > automatically connecting them to that experiment server. > > > > 3. Here's where we need some clarification or at least a "yes keep doing > > that". We decided to 'throttle' connections at the experiment server end, not > > the KNS end. This means that people will be making connections to the > > experiment server regardless of whether or not an experiment is already in > > progress, etc. What we plan to do here is the following: > > a. If there is no experiment session is in progress, or all current > > experiment sessions are already full, a new experiment session is started. > > We're going to have to worry about dealing with a maximum allowable limit > > to this, of course, but we're leaving that for later since it's not > > immediately needed. > > > > b. If there is an experiment session in progress and it is not full, the > > user gets queued up for that particular experiment session and begins > > playing in that experiment session in the next round. I was wary of this > > idea when Andy first mentioned it because I had some artificial notion > > that an experiment was a logical set of rounds, and the participants for a > > given experiment should remain static throughout this set to keep it > > cohesive. Since experiments will be randomized anyhow, we're leaning > > towards the per-round implementation, so a user connects to the forager > > server and gets slapped into the next round of forager. > > > > DING: Here's where we need confirmation/clarification. Do participants join > > on a per-round basis or on a per experiment session basis? Will this change > > for other experiments? Also, how long do we keep running these rounds? Do we > > let someone play forager for 37 hours? Do you need to interpret their data > > differently? > > > > This is a pretty trivial question, but it's kind of a stumbling block right > > now. > > > > Thoughts? > > > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by Black Hat Briefings & Training. > > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > > digital self defense, top technical experts, no vendor pitches, > > unmatched networking opportunities. Visit www.blackhat.com > > _______________________________________________ > > gabel-guys mailing list > > gab...@li... > > https://lists.sourceforge.net/lists/listinfo/gabel-guys > > > > > > |
|
From: Rob G. <rgo...@in...> - 2004-07-01 16:07:24
|
Hi Allen, An experiment can't really be a set of rounds, because people will be coming in and out. If we could imprison subjects for an hour or so, then we could be sure of having the same subjects, but we can't do this. So, the short answer to your question is that a "per round" makes sense. Each 5-10 minute experiment is logically independent of the others, even though there may be an orderly arrangement to which configurations of an experiment are presented when. In terms of statistical analyses, this means that we'll be using "between-subjects" rather than "within-subject" designs. The rest of what you describe makes good sense. For Forager and social choice I'm not envisioning any upper limit to the number of people involved. So, I don't expect we'll be spawning new experiments if one is filled up. This is fine functionality to include though, because I could imagine it coming up down the road. Ciao, Rob > Andy and I have come up with an issue that I thought would be good to have > some feedback on. We've been discussing how we want to implement the 'waiting > room' functionality. Right now we're leaning towards the following > interaction model: > > 1. User hits the web page listing available games. Web page checks KNS to see > which services are available and dynamically generates hyperlinks encoded with > the specific host and port information for that particular server. > > 2. User clicks on a specific hyperlink, that takes them to the applet, > automatically connecting them to that experiment server. > > 3. Here's where we need some clarification or at least a "yes keep doing > that". We decided to 'throttle' connections at the experiment server end, not > the KNS end. This means that people will be making connections to the > experiment server regardless of whether or not an experiment is already in > progress, etc. What we plan to do here is the following: > a. If there is no experiment session is in progress, or all current > experiment sessions are already full, a new experiment session is started. > We're going to have to worry about dealing with a maximum allowable limit > to this, of course, but we're leaving that for later since it's not > immediately needed. > > b. If there is an experiment session in progress and it is not full, the > user gets queued up for that particular experiment session and begins > playing in that experiment session in the next round. I was wary of this > idea when Andy first mentioned it because I had some artificial notion > that an experiment was a logical set of rounds, and the participants for a > given experiment should remain static throughout this set to keep it > cohesive. Since experiments will be randomized anyhow, we're leaning > towards the per-round implementation, so a user connects to the forager > server and gets slapped into the next round of forager. > > DING: Here's where we need confirmation/clarification. Do participants join > on a per-round basis or on a per experiment session basis? Will this change > for other experiments? Also, how long do we keep running these rounds? Do we > let someone play forager for 37 hours? Do you need to interpret their data > differently? > > This is a pretty trivial question, but it's kind of a stumbling block right > now. > > Thoughts? > > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > gabel-guys mailing list > gab...@li... > https://lists.sourceforge.net/lists/listinfo/gabel-guys > > > |
|
From: Allen L. <al...@cs...> - 2004-06-30 22:50:48
|
Andy and I have come up with an issue that I thought would be good to have
some feedback on. We've been discussing how we want to implement the 'waiting
room' functionality. Right now we're leaning towards the following
interaction model:
1. User hits the web page listing available games. Web page checks KNS to see
which services are available and dynamically generates hyperlinks encoded with
the specific host and port information for that particular server.
2. User clicks on a specific hyperlink, that takes them to the applet,
automatically connecting them to that experiment server.
3. Here's where we need some clarification or at least a "yes keep doing
that". We decided to 'throttle' connections at the experiment server end, not
the KNS end. This means that people will be making connections to the
experiment server regardless of whether or not an experiment is already in
progress, etc. What we plan to do here is the following:
a. If there is no experiment session is in progress, or all current
experiment sessions are already full, a new experiment session is started.
We're going to have to worry about dealing with a maximum allowable limit
to this, of course, but we're leaving that for later since it's not
immediately needed.
b. If there is an experiment session in progress and it is not full, the
user gets queued up for that particular experiment session and begins
playing in that experiment session in the next round. I was wary of this
idea when Andy first mentioned it because I had some artificial notion
that an experiment was a logical set of rounds, and the participants for a
given experiment should remain static throughout this set to keep it
cohesive. Since experiments will be randomized anyhow, we're leaning
towards the per-round implementation, so a user connects to the forager
server and gets slapped into the next round of forager.
DING: Here's where we need confirmation/clarification. Do participants join
on a per-round basis or on a per experiment session basis? Will this change
for other experiments? Also, how long do we keep running these rounds? Do we
let someone play forager for 37 hours? Do you need to interpret their data
differently?
This is a pretty trivial question, but it's kind of a stumbling block right
now.
Thoughts?
|
|
From: Allen L. <al...@cs...> - 2004-06-04 00:03:53
|
Awesome, Andy, thanks!
Some thoughts, though:
- What do you think about folding Dispatcher and DispatcherSink
together - part of the responsibility of the Dispatcher may arguably be
converting low level input socket I/O into high level events. So the
Dispatcher avoids the additional level of indirection and just crams
out Events directly.
- I think we should get rid of using ints as identifiers. Especially
if you're considering using some of this code for P2P stuff, where
you'll have to deal with different JVMs generating non-unique
identifiers across the network and then it becomes unclear what thing
really generated what other thing. Before it was the easy-lazy way to
model identifiers, but now I think we're getting closer to the time
when this will really be a pain to fix if we don't fix it soon and
spray dependencies on ints as identifiers all over the codebase.
- why is stopping the server related to making it non-blocking?
There's no reason for the server to be registered with a Selector
unless you really want multiple ServerSocketChannels listening on the
same machine on different ports. Stopping the server entails just
falling out of the while loop and doing a serverSocketChannel.close()
- Disconnection is not too bad to deal with so long as we don't leak
the SocketChannel abstraction out of Dispatcher and friends, but the
Dispatcher is doing a lot of things at the same time right now.
Perhaps we would benefit from some sort of ConnectionManager class that
actually maintains the map of client identifiers to client connections
and provides convenience functionality for removing stale connections,
etc.
- I think that SelectorWrapper should go away and be replaced with the
ReadWorker implementation in ForagerNioServer, though I'm not sure what
the true intent of SelectorWrapper is. Right now it doesn't look like
it does anything other than wrap a Selector in a thread, which is what
the ReadWorker does already, with the added benefit that it can be used
in the WorkerPool that I've set up so that we can do poor-man's
load-balancing and enforced fairness using threads. Along the same
vein, what's the purpose of the SelectionKeyAcceptor? Do we really
need a whole nother class/object for processing the socket channels
that have information available? From the POV of the framework, all we
really need is a way to convert NIO server I/O (the ByteBuffer, etc.,
crap) into Events or Objects that the rest of a specific
experiment/application can understand...
Oh yeah, one last question: what did you mean by 'non-connections are
not detected'?
Your thoughts?
On Jun 3, 2004, at 5:34 PM, Andy Jones wrote:
> The dispatcher now lives!
> Here's the quick rundown...
>
> . Starting a server is as easy as pie
> disp = new Dispatcher();
> disp.startServer();
> . Making connection is as easy as pie
> disp = new Dispatcher();
> id = disp.connect(String host, int port);
> o Dispatcher makes the connection and return an identifier which
> should
> be used in future transactions
> o Dispatcher manages the Channel for you, will let you know when
> input
> comes { via accept(int, byte[]); }
> o Use write(int id, byte[]); to send data via the connection
> . Any object interested in received dispatcher happenings should
> implemens
> the DispatcherSink interface, three methods
> o accept(int id, byte[] buff); // accept data
> o acceptConnection(int id); // accept connection
> o dropConnection(int id); // drop a connection
> . Using this DispatcherSink it would be very easy to write a bridge
> class
> that implements the DispatcherSink and produces events which it then
> pushes into the event pool
> . The other two classes SelectorWrapper.java and
> SelectionKeyAcceptor.java
> are really just internal classes, but may be useful if you want to
> wrap
> a selector for convience sake in the future
> . Things to do...
> o Can't really stop the server, need to make the ServerSocketChannel
> a
> non-blocking Channel that is registered with the internal selector
> like anything else, able to stop
> o Non-connections are not detected
> o No clean way to disconnect channels yet
> o Add logger capabilities to error handling (currently println's)
>
>
> -Andy
>
> Repel them. Repel them. Induce them to relinquish the spheroid.
> -- Indiana University football cheer
>
> ----------------------------------------------------------------------
>
> THE SMURFS AND THE CUISINART (1986)
> The lovable little blue Smurfs encounter a lovable little
> kitchen
> appliance, which invites them to play. The Smurfs learn a
> valuable
> (if sometimes fatal) lesson.
>
> THE SMURFS AND THE CARBON-DIOXIDE INDUSTRIAL LASER (1987)
> The inevitable sequel. The lovable and somewhat mangled
> surviving
> Smurfs team up with the Care Bears to encounter a cute,
> lovable piece
> of high-tech welding equipment, which teaches them the magic of
> becoming rather greasy smoke. Heartwarming fun for the entire
> family.
>
> +++++++++++++++++++++++++
> '(Andy Jones)
> Home: (812) 337-1438
> Work: (812) 333-3134
> and...@in...
> IU Comp Sci Grad
> web...@co...
> +++++++++++++++++++++++++
>
|
|
From: Andy J. <and...@in...> - 2004-06-03 22:34:31
|
The dispatcher now lives!
Here's the quick rundown...
. Starting a server is as easy as pie
disp = new Dispatcher();
disp.startServer();
. Making connection is as easy as pie
disp = new Dispatcher();
id = disp.connect(String host, int port);
o Dispatcher makes the connection and return an identifier which should
be used in future transactions
o Dispatcher manages the Channel for you, will let you know when input
comes { via accept(int, byte[]); }
o Use write(int id, byte[]); to send data via the connection
. Any object interested in received dispatcher happenings should implemens
the DispatcherSink interface, three methods
o accept(int id, byte[] buff); // accept data
o acceptConnection(int id); // accept connection
o dropConnection(int id); // drop a connection
. Using this DispatcherSink it would be very easy to write a bridge class
that implements the DispatcherSink and produces events which it then
pushes into the event pool
. The other two classes SelectorWrapper.java and SelectionKeyAcceptor.java
are really just internal classes, but may be useful if you want to wrap
a selector for convience sake in the future
. Things to do...
o Can't really stop the server, need to make the ServerSocketChannel a
non-blocking Channel that is registered with the internal selector
like anything else, able to stop
o Non-connections are not detected
o No clean way to disconnect channels yet
o Add logger capabilities to error handling (currently println's)
-Andy
Repel them. Repel them. Induce them to relinquish the spheroid.
-- Indiana University football cheer
----------------------------------------------------------------------
THE SMURFS AND THE CUISINART (1986)
The lovable little blue Smurfs encounter a lovable little kitchen
appliance, which invites them to play. The Smurfs learn a valuable
(if sometimes fatal) lesson.
THE SMURFS AND THE CARBON-DIOXIDE INDUSTRIAL LASER (1987)
The inevitable sequel. The lovable and somewhat mangled surviving
Smurfs team up with the Care Bears to encounter a cute, lovable piece
of high-tech welding equipment, which teaches them the magic of
becoming rather greasy smoke. Heartwarming fun for the entire family.
+++++++++++++++++++++++++
'(Andy Jones)
Home: (812) 337-1438
Work: (812) 333-3134
and...@in...
IU Comp Sci Grad
web...@co...
+++++++++++++++++++++++++
|
|
From: Andy J. <and...@in...> - 2004-05-28 23:57:00
|
Anyone interested in learning java's NIO package... I finish my NIO stuff, it's in the net/sf/gabel/junk folder. If you compile it then run the server, then the client on the machine they will be able to talk to each other very well. Type 'help' at the command prompt for instructions. -Andy To keep your friends, treat them kindly; to kill them, treat them often +++++++++++++++++++++++++ '(Andy Jones) Home: (812) 337-1438 Work: (812) 333-3134 and...@in... IU Comp Sci Grad web...@co... +++++++++++++++++++++++++ |
|
From: Allen L. <al...@cs...> - 2004-05-26 23:01:19
|
Wrong URL, they've been changing their links lately:
http://www.opensymphony.com/quartz/
That _should_ be the latest one.
On Wed, May 26, 2004 at 05:52:08PM -0500, Allen Lee wrote:
> I used this at my other job and it's a nice piece of software that may be
> useful for scheduling the various experiments, or at least give us a more
> powerful/flexible way of running experiments on a timer. It supports cron
> type scheduling, so that should make Andy happy, crotchety cron rocketeer that
> he is. Not sure what that really means.
>
> http://www.quartzscheduler.org/
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> gabel-guys mailing list
> gab...@li...
> https://lists.sourceforge.net/lists/listinfo/gabel-guys
|
|
From: Allen L. <al...@cs...> - 2004-05-26 22:52:15
|
I used this at my other job and it's a nice piece of software that may be
useful for scheduling the various experiments, or at least give us a more
powerful/flexible way of running experiments on a timer. It supports cron
type scheduling, so that should make Andy happy, crotchety cron rocketeer that
he is. Not sure what that really means.
http://www.quartzscheduler.org/
|
|
From: Allen L. <al...@cs...> - 2004-05-26 03:21:23
|
Hey Rob, just a reminder to get us the latest incarnation of the forager code (from Dan?) when you get the chance. The stuff that Andy sent me doesn't seem to be complete... On Tue, May 25, 2004 at 08:50:49AM -0500, Allen Lee wrote: > If for no apparent reason yall are interested in CVS commit messages and > dev chatter, there is a new mailing list, gab...@li..., > where most of this blitherty bloo will be taking place. Let me know if you're > interested, or just sign up at the usual place :). > > Allen > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > gabel-guys mailing list > gab...@li... > https://lists.sourceforge.net/lists/listinfo/gabel-guys |
|
From: Allen L. <al...@cs...> - 2004-05-25 13:50:56
|
If for no apparent reason yall are interested in CVS commit messages and dev chatter, there is a new mailing list, gab...@li..., where most of this blitherty bloo will be taking place. Let me know if you're interested, or just sign up at the usual place :). Allen |
|
From: <ben...@id...> - 2004-05-25 08:05:46
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Allen L. <al...@cs...> - 2004-05-22 07:18:37
|
So, ah, where should we meet before lunch at Lennies? Lennies? Sorry for the lateness in replies, I just got back into town a few hours ago and have been unpacking wildly. On Mon, May 10, 2004 at 03:34:28PM -0500, Andy Jones wrote: > I posted the Gabel Retreat Schedule to the webpage > > http://gabel.sourceforge.net/ > > the exact URL is @ http://gabel.sourceforge.net/meetings/retreat.php > > I suggest we use/update this page to coordinate the retreat. Thoughts? > > -Andy > > On Tue, 4 May 2004, Robert Goldstone wrote: > > <>Dear Gabeller, > <>Here's an itinerary for the Gabel retreat. Let me know if there are items > <>to add in to the agenda. By the way, I certainly didn't intend for people > <>to hold off working on Gabel until the retreat! The more work that we do > <>before the retreat, the more substantive our discussion will be. In > <>particular, I'm hoping that Allen stops by to see me really soon, now that > <>classes have ended. He'll need to be in contact with Ben, but believe me, > <>there's more than enough work to go around! Ditto for Andy if he's gotten > <>his master's, or can fit in some Gabel work around the edges. > <>Rob > <>--------------------- > <> > <>Itinerary for Gabel Retreat: > <> > <> > <> > <>May 22 > <> > <>10:00-12:00 ? Informal discussion with Ben, Andy, Allen, and Michael > <> > <>I?ll arrive sometime around 12:30 > <> > <>12:00-1:30 ? lunch at Lennies (just so I?ll know where to find you) > <> > <>1:30-6:00 ? Gabel discussion > <> > <> > <> > <>May 23: > <> > <>9-1:00ish Gabel discussion continued > <> > <> > <> > <>Items: > <> > <>1. Discussion of Gabel infrastructure (led by Ben) ? about 1.5 hours > <> > <>2. Availability of code: How public should it be? About 0.5 hours > <> > <>3. Discussion of experiments (led by Rob) ? about 1.5 hours > <> > <> Forager > <> > <> Path formation > <> > <> Social choice > <> > <> For each paradigm, we will describe the background issues, some > <>results, and future desiderata for extensions > <> > <>4. Discussion of computational models/bots ? about 1.5 hours > <> > <> General issues for bot/participant interactions > <> > <> Forager: reinforcement learning (demo by Michael) > <> > <> Path formation: Active Walker model (maybe demo by Michael) > <> > <> Social choice: Particle swarm algorithm > <>5. New paradigms (I have attached a Word document that describes several > <>possible paradigms, a couple of which have now been implemented. This was > <>originally a note to Ben that was sent March 30, 1999, but we?ve been > <>continually tacking things on to it. You can ignore the first bit if you > <>want ? they?re just ideas on implementing forager). > <>___________________________________________________ > <>Dr. Robert Goldstone > <>Professor of Psychology, Program in Cognitive Science > <>Psychology Building > <>1101 E 10th St. > <>Indiana Un > > After a time, you may find that "having" is not so pleasing a thing, after > all, as "wanting." It is not logical, but it is often true. > -- Spock, Star Trek > > +++++++++++++++++++++++++ > '(Andy Jones) > Home: (812) 337-1438 > Work: (812) 333-3134 > and...@in... > IU Comp Sci Grad > web...@co... > +++++++++++++++++++++++++ > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Sleepycat Software > Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver > higher performing products faster, at low TCO. > http://www.sleepycat.com/telcomwpreg.php?From_______________________________________________ > gabel-guys mailing list > gab...@li... > https://lists.sourceforge.net/lists/listinfo/gabel-guys |
|
From: Allen L. <al...@cs...> - 2004-05-17 15:59:29
|
I was wondering what those were for :). On Fri, May 14, 2004 at 12:20:30AM +0000, Andy wrote: > Update of /cvsroot/gabel/gabel/src/com/andjones/test > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv19373/test > > Removed Files: > a_int.class a_int.java b.class b.java c.class c.java > networkHandler.class networkHandler.java networkServer.class > networkServer.java networkTester.class networkTester.java > noise.class noise.java > Log Message: > Remove my test directory from my com/andjones/ files - ADJ > > > --- c.java DELETED --- > > --- c.class DELETED --- > > --- networkHandler.class DELETED --- > > --- noise.java DELETED --- > > --- a_int.class DELETED --- > > --- b.class DELETED --- > > --- networkServer.class DELETED --- > > --- noise.class DELETED --- > > --- a_int.java DELETED --- > > --- networkTester.java DELETED --- > > --- networkTester.class DELETED --- > > --- networkHandler.java DELETED --- > > --- networkServer.java DELETED --- > > --- b.java DELETED --- > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: SourceForge.net Broadband > Sign-up now for SourceForge Broadband and get the fastest > 6.0/768 connection for only $19.95/mo for the first 3 months! > http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click > _______________________________________________ > gabel-guys mailing list > gab...@li... > https://lists.sourceforge.net/lists/listinfo/gabel-guys |
|
From: Andy <and...@us...> - 2004-05-14 00:20:38
|
Update of /cvsroot/gabel/gabel/src/com/andjones/test In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv19373/test Removed Files: a_int.class a_int.java b.class b.java c.class c.java networkHandler.class networkHandler.java networkServer.class networkServer.java networkTester.class networkTester.java noise.class noise.java Log Message: Remove my test directory from my com/andjones/ files - ADJ --- c.java DELETED --- --- c.class DELETED --- --- networkHandler.class DELETED --- --- noise.java DELETED --- --- a_int.class DELETED --- --- b.class DELETED --- --- networkServer.class DELETED --- --- noise.class DELETED --- --- a_int.java DELETED --- --- networkTester.java DELETED --- --- networkTester.class DELETED --- --- networkHandler.java DELETED --- --- networkServer.java DELETED --- --- b.java DELETED --- |
|
From: allen l. <al...@us...> - 2004-05-12 15:16:38
|
Update of /cvsroot/gabel/gabel/src/net/sf/gabel/server In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv23208/net/sf/gabel/server Modified Files: KnownNodeServer.java Log Message: - fixed 'quit' command - fixed a StringIndexOutOfBoundsException with the 'rem' command. - TODO: turn these into Command objects. Index: KnownNodeServer.java =================================================================== RCS file: /cvsroot/gabel/gabel/src/net/sf/gabel/server/KnownNodeServer.java,v retrieving revision 1.3 retrieving revision 1.4 diff -C2 -d -r1.3 -r1.4 *** KnownNodeServer.java 12 May 2004 10:08:16 -0000 1.3 --- KnownNodeServer.java 12 May 2004 15:16:29 -0000 1.4 *************** *** 309,313 **** System.out.println("System up and running..."); System.out.println("Type help for instructions"); ! while (true) { System.out.print("> "); line = inp.readLine(); --- 309,313 ---- System.out.println("System up and running..."); System.out.println("Type help for instructions"); ! while (running) { System.out.print("> "); line = inp.readLine(); *************** *** 349,354 **** if (line.startsWith("rem")) { ! rest = line.substring(4); ! removeService(rest); } --- 349,360 ---- if (line.startsWith("rem")) { ! if ( line.length() > 4 ) { ! rest = line.substring(4); ! boolean removed = removeService(rest); ! if ( ! removed ) { ! logger.warning("Tried to remove service: " + rest + ": failed."); ! } ! } ! } *************** *** 377,380 **** --- 383,387 ---- */ kns.repl(); + // FIXME: maybe this isnt' bad. throw new RuntimeException("repl returned, uhoh!!"); } catch (Exception e) { |
|
From: allen l. <al...@us...> - 2004-05-12 10:09:33
|
Update of /cvsroot/gabel/gabel/src/net/sf/gabel/server In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv19608/src/net/sf/gabel/server Added Files: AbstractRmiServer.java Log Message: AbstractRmiServer provides basic functionality for RmiServers. Convenience methods for notifying all subscribed clients, etc., will live here eventually, once remote messaging is all ironed out. --- NEW FILE: AbstractRmiServer.java --- package net.sf.gabel.server; // FIXME: log4j would be better, but this reduces jar dependencies. Maybe // Java's logging will improve. import java.util.logging.Logger; import java.rmi.*; import java.rmi.registry.*; import java.rmi.server.UnicastRemoteObject; /** * $Id: AbstractRmiServer.java,v 1.1 2004/05/12 10:09:23 alllee Exp $ * * Abstract class providing base functionality for binding to a Rmi registry. * Subclasses must implement methods for reporting the port number, the * registry name, and the 'what to do' method. * * @author <a href='mailto:al...@cs...'>Allen Lee</a> * @version $Revision: 1.1 $ */ public abstract class AbstractRmiServer implements RmiServer, Runnable { protected final Logger logger = Logger.getLogger(getClass().getName()); protected abstract int getPort(); protected abstract String getRegistryName(); protected abstract void execute(); public void run() { bind(); execute(); } private void bind() { try { Registry registry = LocateRegistry.createRegistry(getPort()); registry.bind(getRegistryName(), UnicastRemoteObject.exportObject(this, getPort())); } catch (Exception exception) { // FIXME: perhaps some better exception handling is in order? exception.printStackTrace(); logger.severe("Couldn't bind to the registry: " + exception.getMessage()); throw new RuntimeException(exception); } } } /* * $Log: AbstractRmiServer.java,v $ * Revision 1.1 2004/05/12 10:09:23 alllee * AbstractRmiServer provides basic functionality for RmiServers. Convenience * methods for notifying all subscribed clients, etc., will live here eventually, * once remote messaging is all ironed out. * * Revision 1.2 2004/05/04 02:09:08 alllee * new template crap * */ |
|
From: allen l. <al...@us...> - 2004-05-12 10:08:27
|
Update of /cvsroot/gabel/gabel/src/net/sf/gabel/server In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv19336/src/net/sf/gabel/server Modified Files: KNService.java KnownNodeServer.java RmiServer.java Service.java Log Message: More refactoring, turning KnownNodeServer into a specific instance of the more general RmiServer. Index: Service.java =================================================================== RCS file: /cvsroot/gabel/gabel/src/net/sf/gabel/server/Service.java,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 *** Service.java 12 May 2004 08:56:01 -0000 1.1 --- Service.java 12 May 2004 10:08:16 -0000 1.2 *************** *** 28,34 **** } ! public Service(KNService service) { ! delegate = service; ! properties = service.myParameters; } --- 28,34 ---- } ! public Service(String description, KNService delegate) { ! this(description, delegate.properties); ! this.delegate = delegate; } *************** *** 61,64 **** --- 61,68 ---- /* * $Log$ + * Revision 1.2 2004/05/12 10:08:16 alllee + * More refactoring, turning KnownNodeServer into a specific instance of the more + * general RmiServer. + * * Revision 1.1 2004/05/12 08:56:01 alllee * First cut at generalizing the KNS server. Index: RmiServer.java =================================================================== RCS file: /cvsroot/gabel/gabel/src/net/sf/gabel/server/RmiServer.java,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 *** RmiServer.java 12 May 2004 08:56:01 -0000 1.1 --- RmiServer.java 12 May 2004 10:08:16 -0000 1.2 *************** *** 1,5 **** package net.sf.gabel.server; - import java.rmi.Remote; import java.rmi.RemoteException; --- 1,4 ---- *************** *** 33,38 **** - public boolean remove(Service service) throws RemoteException; - /** * Stores a file on this remote machine. Very useful for --- 32,35 ---- *************** *** 54,57 **** --- 51,58 ---- /* * $Log$ + * Revision 1.2 2004/05/12 10:08:16 alllee + * More refactoring, turning KnownNodeServer into a specific instance of the more + * general RmiServer. + * * Revision 1.1 2004/05/12 08:56:01 alllee * First cut at generalizing the KNS server. Index: KNService.java =================================================================== RCS file: /cvsroot/gabel/gabel/src/net/sf/gabel/server/KNService.java,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 *** KNService.java 12 May 2004 08:56:01 -0000 1.1 --- KNService.java 12 May 2004 10:08:16 -0000 1.2 *************** *** 30,34 **** /** * The parameters of this service, can be anything */ ! public Properties myParameters = null; } --- 30,34 ---- /** * The parameters of this service, can be anything */ ! public Properties properties = null; } Index: KnownNodeServer.java =================================================================== RCS file: /cvsroot/gabel/gabel/src/net/sf/gabel/server/KnownNodeServer.java,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -d -r1.2 -r1.3 *** KnownNodeServer.java 12 May 2004 09:32:47 -0000 1.2 --- KnownNodeServer.java 12 May 2004 10:08:16 -0000 1.3 *************** *** 19,31 **** * @web http://groupsolve.dhs.org/ */ ! public class KnownNodeServer extends UnicastRemoteObject implements KNServable, Runnable { private final static int MAX_SERVICES = 100; private final Logger logger = Logger.getLogger(getClass().getName()); ! private Registry registry = null; ! // FIXME: this should be configurable. Either hand-roll configuration ! // management or use Jakarta Commons Configuration ! private static int myPort = 2099; /* defunct arrays. private int numServices = 0; --- 19,32 ---- * @web http://groupsolve.dhs.org/ */ ! public class KnownNodeServer extends AbstractRmiServer implements KNServable { + // FIXME: all this should be configurable at runtime. Either hand-roll + // configuration management or use Jakarta Commons Configuration private final static int MAX_SERVICES = 100; + private final static int PORT_NUMBER = 2099; + private final static String REGISTRY_NAME = "kns"; private final Logger logger = Logger.getLogger(getClass().getName()); ! // private Registry registry = null; /* defunct arrays. private int numServices = 0; *************** *** 36,42 **** // Map< String, Service > private final Map services = new LinkedHashMap(); - // FIXME: private boolean running = true; --- 37,43 ---- // Map< String, Service > + // using a LinkedHashMap to maintain insertion order private final Map services = new LinkedHashMap(); private boolean running = true; *************** *** 66,70 **** /** Sets up a new registry using the given port - */ public boolean createReg(int port) { try { --- 67,70 ---- *************** *** 77,84 **** return true; } /** Let us add ourselves to the registry * so that others can find us - */ public boolean addMyself() throws RemoteException { try { --- 77,84 ---- return true; } + */ /** Let us add ourselves to the registry * so that others can find us public boolean addMyself() throws RemoteException { try { *************** *** 92,95 **** --- 92,108 ---- return false; } + */ + + public String getRegistryName() { + return REGISTRY_NAME; + } + + public int getPort() { + return PORT_NUMBER; + } + + public String[] availableServices() throws RemoteException { + return listService(); + } /** Returns an array of available services. *************** *** 102,105 **** --- 115,126 ---- } + public boolean add(Service service) throws RemoteException { + if ( services.size() < MAX_SERVICES ) { + services.put(service.toString(), service); + return true; + } + return false; + } + /** Adds a service with the given name and properties to this kns. * <P> *************** *** 110,119 **** */ public boolean addService(String description, KNService obj) throws RemoteException { ! if ( services.size() < MAX_SERVICES ) { ! services.put(description, new Service(obj)); ! return true; ! } ! return false; ! /* int x = 0; --- 131,136 ---- */ public boolean addService(String description, KNService obj) throws RemoteException { ! return add(new Service(description, obj)); ! /* int x = 0; *************** *** 144,155 **** } ! /** Removes the service with the given name ! */ ! public boolean removeService(String description) throws RemoteException { ! if ( services.containsKey(description) ) { ! Service service = (Service) services.remove(description); return true; } return false; /* int x = 0; --- 161,178 ---- } ! public boolean remove(String key) throws RemoteException { ! if ( services.containsKey(key) ) { ! Service service = (Service) services.remove(key); ! logger.info("Removing service: " + key); return true; } return false; + } + + + /** Removes the service with the given name + */ + public boolean removeService(String description) throws RemoteException { + return remove(description); /* int x = 0; *************** *** 180,183 **** --- 203,214 ---- } + public Service get(String key) throws RemoteException { + return (Service) services.get(key); + } + + public void persist(String filename, byte[] data) throws RemoteException { + storeFile(filename, data); + } + /** * Returns the object encapsulating the setup information *************** *** 217,221 **** // do maintenance ! public void run() { while (running) { try { --- 248,252 ---- // do maintenance ! public void execute() { while (running) { try { *************** *** 322,327 **** --- 353,360 ---- } + /* if (line.equals("add")) addMyself(); + */ } *************** *** 337,346 **** KnownNodeServer kns = new KnownNodeServer(); new Thread(kns).start(); success = kns.createReg(myPort); if (!success) throw new Exception("Could not create the registry!!"); success = kns.addMyself(); if (!success) throw new Exception("Could not add myself to the registry!!"); kns.repl(); ! throw new Exception("repl returned, uhoh!!"); } catch (Exception e) { e.printStackTrace(); --- 370,381 ---- KnownNodeServer kns = new KnownNodeServer(); new Thread(kns).start(); + /* success = kns.createReg(myPort); if (!success) throw new Exception("Could not create the registry!!"); success = kns.addMyself(); if (!success) throw new Exception("Could not add myself to the registry!!"); + */ kns.repl(); ! throw new RuntimeException("repl returned, uhoh!!"); } catch (Exception e) { e.printStackTrace(); |
|
From: allen l. <al...@us...> - 2004-05-12 10:08:26
|
Update of /cvsroot/gabel/gabel In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv19336 Modified Files: build.xml Log Message: More refactoring, turning KnownNodeServer into a specific instance of the more general RmiServer. Index: build.xml =================================================================== RCS file: /cvsroot/gabel/gabel/build.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -C2 -d -r1.3 -r1.4 *** build.xml 12 May 2004 09:32:44 -0000 1.3 --- build.xml 12 May 2004 10:08:15 -0000 1.4 *************** *** 67,71 **** <!-- stubs for RMI compiler (FIXME: unused)--> <target name="rmi" depends="clean,prepare,compile"> ! <rmic base="${build.home}" includes="**/KnownNodeServer.class" verify="true" /> </target> --- 67,71 ---- <!-- stubs for RMI compiler (FIXME: unused)--> <target name="rmi" depends="clean,prepare,compile"> ! <rmic base="${build.home}" includes="**/KnownNodeServer.class,**/*Rmi*.class" verify="true" /> </target> *************** *** 226,229 **** --- 226,233 ---- <!-- $Log$ + Revision 1.4 2004/05/12 10:08:15 alllee + More refactoring, turning KnownNodeServer into a specific instance of the more + general RmiServer. + Revision 1.3 2004/05/12 09:32:44 alllee - Fixed a bug in KnownNodeServer (remove wouldn't work properly). |
|
From: allen l. <al...@us...> - 2004-05-12 09:33:28
|
Update of /cvsroot/gabel/gabel/src/com/andjones/kns In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv11753/src/com/andjones/kns Modified Files: KnownNodeServer.java Log Message: - Fixed a bug in KnownNodeServer (remove wouldn't work properly). - added a Tester for KnownNodeServer - fixed rmi targets in build.xml and made it a dependency in the test target (the KnownNodeServerTester requires the KnownNodeServer's stubs to be generated) Index: KnownNodeServer.java =================================================================== RCS file: /cvsroot/gabel/gabel/src/com/andjones/kns/KnownNodeServer.java,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 *** KnownNodeServer.java 10 Apr 2004 15:37:23 -0000 1.1 --- KnownNodeServer.java 12 May 2004 09:32:45 -0000 1.2 *************** *** 53,57 **** r = LocateRegistry.createRegistry(port); } catch (Exception e) { ! System.out.println ("Could not create registry: " + e.toString()); return false; } --- 53,57 ---- r = LocateRegistry.createRegistry(port); } catch (Exception e) { ! System.out.println ("Could not create registry: " + e.getMessage()); return false; } *************** *** 184,188 **** while (true) { try { ! Thread.currentThread().sleep(5000); now = new Date(); for(x=0; x<numServices; x++) { --- 184,188 ---- while (true) { try { ! Thread.sleep(5000); now = new Date(); for(x=0; x<numServices; x++) { |
|
From: allen l. <al...@us...> - 2004-05-12 09:33:28
|
Update of /cvsroot/gabel/gabel In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv11753 Modified Files: build.xml Log Message: - Fixed a bug in KnownNodeServer (remove wouldn't work properly). - added a Tester for KnownNodeServer - fixed rmi targets in build.xml and made it a dependency in the test target (the KnownNodeServerTester requires the KnownNodeServer's stubs to be generated) Index: build.xml =================================================================== RCS file: /cvsroot/gabel/gabel/build.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -d -r1.2 -r1.3 *** build.xml 11 May 2004 17:00:03 -0000 1.2 --- build.xml 12 May 2004 09:32:44 -0000 1.3 *************** *** 66,71 **** <!-- stubs for RMI compiler (FIXME: unused)--> ! <target name="rmi" depends="clean,compile"> ! <rmic base="${build.home}" includes="**/Rmi*.class, **/AbstractRmi*.class" verify="true" /> </target> --- 66,71 ---- <!-- stubs for RMI compiler (FIXME: unused)--> ! <target name="rmi" depends="clean,prepare,compile"> ! <rmic base="${build.home}" includes="**/KnownNodeServer.class" verify="true" /> </target> *************** *** 166,170 **** <!-- Compile Tests --> ! <target name="compile-tests" depends="prepare, compile"> <javac srcdir="${test.src.home}" destdir="${test.build.home}" --- 166,170 ---- <!-- Compile Tests --> ! <target name="compile-tests" depends="rmi"> <javac srcdir="${test.src.home}" destdir="${test.build.home}" *************** *** 226,229 **** --- 226,236 ---- <!-- $Log$ + Revision 1.3 2004/05/12 09:32:44 alllee + - Fixed a bug in KnownNodeServer (remove wouldn't work properly). + - added a Tester for KnownNodeServer + - fixed rmi targets in build.xml and made it a dependency in the test target + (the KnownNodeServerTester requires the KnownNodeServer's stubs to be + generated) + Revision 1.2 2004/05/11 17:00:03 alllee adding build-all convenience target for cruisecontrol, right now it just |