Second Life Wiki - User contributions [en]

How to add unit tests to C++ code

2010-08-25T05:26:52Z

Enus Linden:

The indra C++ codebase is fraught with much peril. To reduce the amount of risk associated with refactoring legacy code, use unit tests. Here's how to use the new LL_ADD_PROJECT_UNIT_TESTS cmake macro and the existing tut test infrastructure to add a test to the build.

== Overview ==
Tests for a file in a project go into the tests/ subdirectory of that project with the specific naming convention <code>''code_filename''_test.cpp</code>. The test code itself should use our basic tut template (which as of 2009-04 is somewhat in flux). Add a testing target to the bottom of the project using the cmake command LL_ADD_PROJECT_UNIT_TESTS(project sourcelist).

DO NOT add test code that:
* talks to a database.
* communicates across a network.
* touches the file system.
* requires doing special things to the environment (such as editing configuration files) to run it.
* takes longer than about ~.1s to run on a modern computer.

== The unit test template ==
Copy this to a file <code>indra/''project_name''/tests/''code_filename''_test.cpp</code> and follow the next section to make sure the build runs with it before you begin writing your test. (You should expect link errors to appear once you've successfully started building the test.)

<pre>
#include "linden_common.h"
#include "lltut.h"

#include "llclassname.h"

namespace tut
{
// Main Setup
struct LLClassNameFixture
{
LLClassNameFixture()
{
}
};
typedef test_group<LLClassNameFixture> factory;
typedef factory::object object;
factory tf("LLClassName");

// Tests
template<> template<>
void object::test<1>()
{

}
}
</pre>

== Code to make the unit test build ==
There is a macro that takes care of adding the proper testing targets to the build, you merely need to supply source files and a project name.

=== Basic example ===
This would go at the bottom of CMakeLists.txt for a project called "chewbacca". The exact quoting is important! CMake is very particular about list variables.

<pre>
INCLUDE(LLAddBuildTest)
# NOTE: this is different from project_SOURCE_FILES because not all source has tests.
set(chewbacca_TESTED_SOURCE_FILES
chewbacca.cpp
person.cpp
)
LL_ADD_PROJECT_UNIT_TESTS(chewbacca "${chewbacca_TESTED_SOURCE_FILES}")
</pre>

=== Extended example ===
The "Chewbacca! What a Wookie!" project code is available on bitbucket ( http://bitbucket.org/poppy_linden/unit-testing-infrastructure-test/ ) and instructions for using it are available on the [[How to test unit test infrastructure changes]] page. Download and run that example, the code will demonstrate the bare basics if the newview code proves too dense to understand. Notably, there are no actual tests, just the scaffolding to get the unit test into the build.

== How to unit test your indra code ==
We've covered the basics of setup, but not the process of writing the tests themselves.
* [[C++ Unit Testing - How It Works]] - how the test framework generates and builds test projects.
* [[C++ Unit Testing - Case Study]] - a walkthrough of the whole process (from setup to fixing link errors to writing tests), by example. Note that this predates Google Mock ([http://code.google.com/p/googlemock/wiki/ForDummies tutorial here]), which provides another way of fixing up link errors.
* [[C++ Unit Testing - FAQ]]

The following is still relevant, but more focused on overall structure of code than what to write.

== To add a new test ==
The framework uses template meta-programming to do automatic registration of test functions. Add a new function as a method of the local tut::test_group<local_data> class with a incremented number as the template parameter. In general, you should always append tests, and try to have a limited number of calls to any of the ensure* functions inside the test function.
<code>
<pre>
namespace tut
{
... Test group stuff

... Other tests

template<> template<>
void math_object::test<7>()
{
...
ensure("new test", (...));
}
}
</pre>
</code>

== To add a new test group ==
Inside the namespace declaration, instantiate a test_group<test_data> object where test_data is a class which will have necessary information for most of the test calls, eg, an open file handle. The constructor for the test_data object will initialize (ala setUp()) and the destructor will free that data as necessary (ala tearDown()). You can provide an empty struct if you have no data. All instance members of the test_data will be available on the stack as newly generated objects in every call to test(). Each test group is limited to 50 actual test methods unless you make a special declaration. For example:
<code>
<pre>
namespace tut
{
struct uuid_data
{
LLUUID id;
};
typedef test_group<uuid_data> uuid_test;
typedef uuid_test::object uuid_object;
tut::uuid_test tu("uuid");

template<> template<>
void uuid_object::test<1>()
{
ensure("uuid null", id.isNull());
id.generate();
ensure("generate not null", id.notNull());
id.setNull();
ensure("set null", id.isNull());
}
}
</pre>
</code>

== To add new test suites ==
You need to simply create a new file for the test suites and add a group and then tests. For example, math.cpp tests the llmath library and currently has 2 test groups, each with a few test() functions.
== Needed Improvements ==
* I added an ensure_not_equals() function in lltut.h since I felt that was necessary. More ensure functions should be written:
** ensure_approximately_equals()
** ensure_memory_matches()
** ensure_equals<A,B,Compare_fn> () { if(compare(a,b))...}
* More tests! I only wrote a few to make sure it worked and was fairly easy to use.
* The test runner needs to have a few more commands and options since it is possible to only run certain test groups. Eg, `./test --group=uuid` could be wired to run the uuid tests.
* The test runner needs more optional controls on the output. The output is generated through callbacks, so an enterprising programmer that loves GUIs could even write a progress bar output.

[[Category:Automated Testing]]

PyOGP Client Library Development Sandbox

2010-06-25T18:17:07Z

Enus Linden: /* buildout */

{{PyOGP/navigation}}
We will first run down the general explanation and add platform specific notes later.

== Repositories ==

Stable trunk repositories:
* http://bitbucket.org/enus_linden/pyogp.apps/
* http://bitbucket.org/enus_linden/pyogp.lib.base/
* http://bitbucket.org/enus_linden/pyogp.lib.client/
* http://bitbucket.org/enus_linden/pyogp.buildout/

Maintenance repositories:
* http://bitbucket.org/enus_linden/pyogp.apps-maint/
* http://bitbucket.org/enus_linden/pyogp.lib.base-maint/
* http://bitbucket.org/enus_linden/pyogp.lib.client-maint/
* http://bitbucket.org/enus_linden/pyogp.buildout-maint/

Defunct until someone picks them up and fixes them:
* http://bitbucket.org/enus_linden/pyogp.interop/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/

== Browse the Code ==

If all you want to do is glance at the source code, use the bitbucket source browser:
* http://bitbucket.org/enus_linden/pyogp.apps/src/
* http://bitbucket.org/enus_linden/pyogp.buildout/src/
* http://bitbucket.org/enus_linden/pyogp.interop/src/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/src/
* http://bitbucket.org/enus_linden/pyogp.lib.base/src/
* http://bitbucket.org/enus_linden/pyogp.lib.client/src/

== Environment Preparation ==

=== Prerequisites ===

You must have the following installed:
* Mercurial - 1.3 or greater
* Python 2.4.4, 2.5.x, 2.6.x (untested on 3.0)

'''Setuptools''' and '''easy_install''' are Python standard means for installing modules. For more info, start here: http://pypi.python.org/pypi/setuptools.

'''Virtualenv''' is a method which allows you to create isolated Python environments, separate from your base install if you so prefer. For more, see here: http://pypi.python.org/pypi/virtualenv.

Your distribution may have Python's '''setuptools''' and '''virtualenv''' packages in its package repository. If so, it is probably best to use your normal package installation procedures (see below for information on specific Linux distributions). If the packages are not available then follow these generic instructions.

=== Mac Specifics ===

'''Note:''' Snow Leopard upgrades require a updated install of XCode, in this case to accommodate gcc (and greenlet).

=== Generic *nix Specifics ===

In order to install Python Packages and creating a development sandbox you have to do the following:

=== easy_install ===

"Easy Install is a python module (easy_install) bundled with setuptools that lets you automatically download, build, install, and manage Python packages." I stole that from here: http://peak.telecommunity.com/DevCenter/EasyInstall.

Download ez_setup.py and run it with your Python interpreter. You can find it here: http://peak.telecommunity.com/dist/ez_setup.py

Eventually you have to be root to do this depending on your system (mostly non-windows). It should look like this on a unix based machine:

wget http://peak.telecommunity.com/dist/ez_setup.py
-or-
curl -O http://peak.telecommunity.com/dist/ez_setup.py
sudo python ez_setup.py

=== virtualenv ===

Virtualenv builds isolated python environments. To learn more, read this: http://pypi.python.org/pypi/virtualenv.

To use a dedicated python installation in your host, isolated from your system python install, install virtualenv like this:

easy_install virtualenv

Or, if you need to be root something like this:

sudo easy_install virtualenv

On windows, you may need a different path to easy_install

c:\Python25\Scripts\easy_install.exe virtualenv

== Install methods ==

Python modules can be installed in a variety of ways... we're encouraging the virtualenv and setup.py method.

=== buildout ===

Buildout has a variety of uses, in PyOGP's case it is used as a development sandbox. Buildout will checkout all the necessary PyOGP repositories and their dependencies, and configure everything automatically (set up the right path members and install scripts). Once the sandbox is set up, you can make changes to the libs in the parts/ directory (they are actually local mercurial repositories), update the code referenced in buildout (re-run bin/buildout), and test your changes.

It's really easy to work with...

1. First check out the buildout into a directory of your choice:

hg clone http://bitbucket.org/enus_linden/pyogp.buildout (or grab pyogp.buildout-maint to work with maintenance repos)

2. Now turn this checkout into a virtual python environment, independent of your normal Python installation:

cd pyogp.buildout
virtualenv . --no-site-packages

on windows, you may need to specify the path

c:\Python25\Scripts\virtualenv.exe . --no-site-packages

3. Now run the bootstrap.py file with the newly created local Python interpreter:

bin/python bootstrap.py

or on Windows:

Scripts\python bootstrap.py

4. This creates a bunch of directories and the bin/buildout script (bin\buildout.exe on windows). We now run this:

bin/buildout -v

or on Windows:

bin\buildout.exe -v

5. The development sandbox is ready. There now is a bin/pyogp_interpreter, a python interpreter which contains all the installed packages and the pyogp libraries and dependencies referenced in the path.

6. Test the buildout installation. To test this installation you can (at least at this stage of the project) try the following sample script or run the unittests:

bin/region_connect <firstname> <lastname>

-or-

bin/unittests --where=parts/pyogp.lib.base (or pyogp.lib.client)

Enter the avatar's password when prompted, and you're on your way to aditi, the Beta Grid.

=== setup.py ===

If you prefer to not use buildout, and to do things a bit more manually, well, you probably don't need much help here then do you? ;)

Grab the source for each of the pyogp repos, and install them to a virtualenv instance (see above for installing virtualenv if you don't have it)..

Here's a simple setup that Enus likes:
cd ~
mkdir sandbox
cd sandbox
virtualenv . --no-site-packages
cd ~
mkdir hg
cd hg
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.apps/
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.base/
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.client/
cd ~/hg/pyogp.lib.base
~/sandbox/bin/python setup.py install
cd ~/hg/pyogp.lib.client
~/sandbox/bin/python setup.py install
cd ~/hg/pyogp.apps
~/sandbox/bin/python setup.py install
......
now, in ~/sandbox/bin/ you'll have all kinds of pyogp executables for testing stuff out (like region_connect, etc)

You now have all the source, plus a sandbox, for tinkering with pyogp!

To try an executable out, just run it in ~/sandbox/bin/. for example:
~/sandbox/bin/region_connect firstname lastname
This command will login in your agent to aditi, and will prompt you for a password.

Pass any script the "-h" param to get it's usage.

== Run the tests ==

See [[PyOGP_Package_Unittests]] for details...

[[Category: Pyogp_Client_Lib]]

PyOGP Client Library Development Sandbox

2010-06-25T18:16:52Z

Enus Linden: /* buildout */

Pyogp/Roadmap

2010-06-25T18:14:34Z

Enus Linden:

{{PyOGP/navigation}}

== Meta Issues ==

# Update and maintain the published docs at:
## [http://wiki.secondlife.com/wiki/PyOGP_Client_Library pWiki Pyogp Tech Overview]
# we need to spend time improving unit test coverage very soon
# we need to use pylint to help clean up pyogp
# <s>we need to come up with pyogp specific coding guidelines</s> (Done - PyOGP_Coding_Guidelines)
## <s>wiki page indicating style, naming conventions, docstring standards, and examples of adding code (in the lib context)</s>

== Functional Changes ==

# PyOGP Application support
## adding application level events throughout
## Raise an application event when disconnected
# Messaging changes
## add a MessagingManager, refactor UDPDispatcher and EventQueueClient to purely parse/pack data, and handle messaging concerns in this new class
### incorporate message.xml handling
## <s>remove packets.py and refactor accordingly</s> (Done)
## <s>Merge UPDPacket and Message</s> (Done)
## <s>merge packet_handler and event_queue_handler</s> (Done)
## <s>fix http://jira.secondlife.com/browse/PYO-62 (kotler)</s> (Done)
# <s>update the event handler</s> (Done)
## <s>create a generic event message class with name and payload</s> (Done)
## add convenience methods (e.g. to_llsd(), to_dict())
# Functional Additions
## teleport
##* <s>teleport to region/x/y/z</s> (Done 2009-06-15)
##* <s>teleport to landmark</s> (Done 2009-09-01)
##* receive teleport request
##* accept teleport request
##* accept god teleport request
##* <s>teleport status</s> (Done 2009-06-15)
## L$
##* <s>Send money</s> (Done 2009-06-17)
##* <s>money balance updates</s> (Done 2009-06-17)
## Actions
##* <s>Sit on ground</s> (Done 2009-07-07)
##* Sit on target
##* <s>Stand</s> (Done 2009-07-07)
##* Gestures
## Friends
##* <s>List of friends</s> (Done 2009-06-15)
##* <s>offline/online notifications</s> (Done 2009-06-15)
##* send/accept friend invite
##* de-friending
## Parcels
##* parcel update events (media)
## Voice
##* <s>Voice URI (Can be done using caps; should we bother with it outside a sample?)</s> (Sample added 2009-10-13)
##* <s>Voice credentials</s> (Sample added 2009-10-13)
## Object Tracking
##* Avatars (name cache)
## Appearance management (e.g. avoid having to bake locally)
##* <s>Initialization of appearance manager and required messages</s> (Done)
##* <s>Requesting cached Texture ids</s>(Done)
##* <s>VisualParams classes</s> (Done)
##* <s>AgentSetAppearance</s> (Done)
##* <s>Fetch own avatar visualParams from wearables</s> (Done)
##* Cases where sim does not have cached TextureEntry(ObjectUpdate) or TextureIDs (AgentCachedTextureResponse)
##* Attachments
##* Animations
## a thousand other things

=== Apps to develop using pyogp ===

# build a regression test suite using pyogp
# create a viewer proxy using pyogp
# create something akin to libomv's TestClient

PyOGP/Roadmap

2010-06-25T18:13:06Z

Enus Linden: Redirected page to Pyogp/Roadmap

#REDIRECT [[Pyogp/Roadmap]]

Template:PyOGP/navigation

2010-06-25T18:12:02Z

Enus Linden:

<div id="box" style="float:right; width:17em; padding-bottom:1em; padding-left:1em; margin-left: 0.5em">
'''[[PyOGP]]'''
* [[PyOGP/Roadmap|Roadmap]]
* [[PyOGP Client Library]]:
** [[PyOGP Coding Guidelines|Coding Guidelines]]
** [[PyOGP Client Library Development|Package Development]]
** [[PyOGP Client Library Development Sandbox|Client Development Sandbox]]
** [[PyOGP Package Unittests|Package Unittests]]
</div>

Pyogp/Roadmap

2010-06-25T18:11:10Z

Enus Linden: /* Meta Issues */

== Meta Issues ==

# Update and maintain the published docs at:
## [http://wiki.secondlife.com/wiki/PyOGP_Client_Library pWiki Pyogp Tech Overview]
# we need to spend time improving unit test coverage very soon
# we need to use pylint to help clean up pyogp
# <s>we need to come up with pyogp specific coding guidelines</s> (Done - PyOGP_Coding_Guidelines)
## <s>wiki page indicating style, naming conventions, docstring standards, and examples of adding code (in the lib context)</s>

== Functional Changes ==

# PyOGP Application support
## adding application level events throughout
## Raise an application event when disconnected
# Messaging changes
## add a MessagingManager, refactor UDPDispatcher and EventQueueClient to purely parse/pack data, and handle messaging concerns in this new class
### incorporate message.xml handling
## <s>remove packets.py and refactor accordingly</s> (Done)
## <s>Merge UPDPacket and Message</s> (Done)
## <s>merge packet_handler and event_queue_handler</s> (Done)
## <s>fix http://jira.secondlife.com/browse/PYO-62 (kotler)</s> (Done)
# <s>update the event handler</s> (Done)
## <s>create a generic event message class with name and payload</s> (Done)
## add convenience methods (e.g. to_llsd(), to_dict())
# Functional Additions
## teleport
##* <s>teleport to region/x/y/z</s> (Done 2009-06-15)
##* <s>teleport to landmark</s> (Done 2009-09-01)
##* receive teleport request
##* accept teleport request
##* accept god teleport request
##* <s>teleport status</s> (Done 2009-06-15)
## L$
##* <s>Send money</s> (Done 2009-06-17)
##* <s>money balance updates</s> (Done 2009-06-17)
## Actions
##* <s>Sit on ground</s> (Done 2009-07-07)
##* Sit on target
##* <s>Stand</s> (Done 2009-07-07)
##* Gestures
## Friends
##* <s>List of friends</s> (Done 2009-06-15)
##* <s>offline/online notifications</s> (Done 2009-06-15)
##* send/accept friend invite
##* de-friending
## Parcels
##* parcel update events (media)
## Voice
##* <s>Voice URI (Can be done using caps; should we bother with it outside a sample?)</s> (Sample added 2009-10-13)
##* <s>Voice credentials</s> (Sample added 2009-10-13)
## Object Tracking
##* Avatars (name cache)
## Appearance management (e.g. avoid having to bake locally)
##* <s>Initialization of appearance manager and required messages</s> (Done)
##* <s>Requesting cached Texture ids</s>(Done)
##* <s>VisualParams classes</s> (Done)
##* <s>AgentSetAppearance</s> (Done)
##* <s>Fetch own avatar visualParams from wearables</s> (Done)
##* Cases where sim does not have cached TextureEntry(ObjectUpdate) or TextureIDs (AgentCachedTextureResponse)
##* Attachments
##* Animations
## a thousand other things

=== Apps to develop using pyogp ===

# build a regression test suite using pyogp
# create a viewer proxy using pyogp
# create something akin to libomv's TestClient

Pyogp/Roadmap

2010-06-25T18:10:44Z

Enus Linden:

== Meta Issues ==

# Update and maintain the published docs at:
## [http://wiki.secondlife.com/wiki/PyOGP_Client_Library pWiki Pyogp Tech Overview]
# we need to spend time improving unit test coverage very soon
# we need to use pylint to help clean up pyogp
<s># we need to come up with pyogp specific coding guidelines</s> (Done - PyOGP_Coding_Guidelines)
<s>## wiki page indicating style, naming conventions, docstring standards, and examples of adding code (in the lib context)</s>

== Functional Changes ==

# PyOGP Application support
## adding application level events throughout
## Raise an application event when disconnected
# Messaging changes
## add a MessagingManager, refactor UDPDispatcher and EventQueueClient to purely parse/pack data, and handle messaging concerns in this new class
### incorporate message.xml handling
## <s>remove packets.py and refactor accordingly</s> (Done)
## <s>Merge UPDPacket and Message</s> (Done)
## <s>merge packet_handler and event_queue_handler</s> (Done)
## <s>fix http://jira.secondlife.com/browse/PYO-62 (kotler)</s> (Done)
# <s>update the event handler</s> (Done)
## <s>create a generic event message class with name and payload</s> (Done)
## add convenience methods (e.g. to_llsd(), to_dict())
# Functional Additions
## teleport
##* <s>teleport to region/x/y/z</s> (Done 2009-06-15)
##* <s>teleport to landmark</s> (Done 2009-09-01)
##* receive teleport request
##* accept teleport request
##* accept god teleport request
##* <s>teleport status</s> (Done 2009-06-15)
## L$
##* <s>Send money</s> (Done 2009-06-17)
##* <s>money balance updates</s> (Done 2009-06-17)
## Actions
##* <s>Sit on ground</s> (Done 2009-07-07)
##* Sit on target
##* <s>Stand</s> (Done 2009-07-07)
##* Gestures
## Friends
##* <s>List of friends</s> (Done 2009-06-15)
##* <s>offline/online notifications</s> (Done 2009-06-15)
##* send/accept friend invite
##* de-friending
## Parcels
##* parcel update events (media)
## Voice
##* <s>Voice URI (Can be done using caps; should we bother with it outside a sample?)</s> (Sample added 2009-10-13)
##* <s>Voice credentials</s> (Sample added 2009-10-13)
## Object Tracking
##* Avatars (name cache)
## Appearance management (e.g. avoid having to bake locally)
##* <s>Initialization of appearance manager and required messages</s> (Done)
##* <s>Requesting cached Texture ids</s>(Done)
##* <s>VisualParams classes</s> (Done)
##* <s>AgentSetAppearance</s> (Done)
##* <s>Fetch own avatar visualParams from wearables</s> (Done)
##* Cases where sim does not have cached TextureEntry(ObjectUpdate) or TextureIDs (AgentCachedTextureResponse)
##* Attachments
##* Animations
## a thousand other things

=== Apps to develop using pyogp ===

# build a regression test suite using pyogp
# create a viewer proxy using pyogp
# create something akin to libomv's TestClient

PyOGP

2010-06-25T18:07:20Z

Enus Linden: /* Project Status */

{{PyOGP/navigation}}
== Overview ==

=== What Is It? ===

Pyogp is an open source project to explore a suite of python based Second Life client libraries and to produce an automated testing framework.

PyOGP is useful for:
* learning more about Second Life's client-server relationship
* prototyping client side features
* quickly writing tests for software which communicates using LLMessageSystem-like messages
* demonstrating protocol proposals
* building test suites which validate Second Life simulator and grid functionality

=== Getting Started ===

See [[PyOGP Client Library Development Sandbox]] for instructions on the mechanics of working with the PyOGP package suite.

For a more comprehensive overview of working within the structure of classes and event systems in PyOGP packages, take a look at [[PyOGP Client Library]].

=== How To Contribute ===
* Source: [[Pyogp/Client_Lib/The_Development_Sandbox | Checkout Instructions]]. See the [[Open_Source_Portal|Open Source Portal]] for details on being a contributor
* in-world group: pyogp (open enrollement)
* IRC: irc://irc.freenode.com/#pyogp
* Mailing list: https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp, pyogp@lists.secondlife.com
* Jira: http://jira.secondlife.com/browse/PYO
* Related Meetings
** Enus Linden's office hours: Friday @ 1:00 http://slurl.com/secondlife/Longfellow/99/97/28

== Project Status ==

PyOGP has moved to bitbucket! http://bitbucket.org/enus_linden/

client_proxy is now stable[https://lists.secondlife.com/pipermail/pyogp/2010-June/000255.html], though it's only logging things currently.

Keep track of progress on the list: https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp.

== Pic of the Moment ==
[[Image:355571.jpg|900x835px|the EnusBots are coming!]]

Image used with permission. Taken by [[User:Opensource_Obscure|Opensource Obscure]]. (thanks oo! <3)

== Licensing ==
Contributions to Pyogp are subject to Linden Lab's [http://secondlifegrid.net/programs/open_source/submission contributor agreement]. The Pyogp open source code is made available subject to the Apache v2 license. Read more at [http://opensource.org/licenses/apache2.0.php opensource.org] and [http://www.apache.org/licenses/LICENSE-2.0 apache.org].

<excerpt>
Copyright 2008, Linden Research, Inc.
 
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
 
http://www.apache.org/licenses/LICENSE-2.0
 
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
</excerpt>

== History ==

Linden Lab and the [[AWG]] ([[AW_Groupies|in-world discussion group page]]) are working together to develop a set of open protocols called the [[Open Grid Protocol]] that can be used to create a virtual world where regions are independently operated (not only by Linden Lab). The project is aiming to allow people (organizations, individuals, and the like) to host their own regions in the virtual world and be able to interact and communicate with people in regions hosted elsewhere. In essence, the project's goal is to allow open-source region hosting.

AWG and Linden Lab plan to share the effort in writing a test harness that executes tests against implementations of the Open Grid Protocol.

The intent is not to test SL or OpenSim (or gridX) themselves. Rather, the desire is to create a framework where the implementations of the protocols can be tested in any virtual environment implemented per the Open Grid Protocols as documented. The goal is to use the test harness to test the implementations to make sure that the virtual environment is interoperable with the other virtual environments that have implemented the OGP. However, we also plan to test the current SL protocols (the Legacy protocols). We plan to be able to test at the smallest functional level possible, akin to unit testing, and to have the ability to use the framework to sequence steps to enable state specific tests to be run.

The longer-term vision is essentially a [[Pyogp_Client_Lib|client library]], capable of navigating the grid and interacting with the various hosts, sitting next to a testing framework, happily running along telling us what works where, and where something needs a little attention to work according to specification...

For more detail on OGP, see a visual representation of the upcoming [[Open Grid Platform Projects Q2-Q3|projects]] and a general [[Structural Design Overview|introduction]].

=== Notes from the kickoff meeting ===

At the AWG meeting held April 29, 2008, we discussed what a test harness could look like that would be used to test the agent-domain, rez-avatar, and overall work being done implementing the open grid protocols. I'd like to summarize, and continue the discussion on the mailing list, in-world, and on the wiki. See [[AWGroupies-2008-04-29|meeting chat log]].

How do we start?

Let's work on defining the test harness components (from the meeting):
# Login
# Caps (and while it's around the UDP pipe)
# Message Handlers (see chttp)
# Basic web server parts for the Agent, Region and grid bits (ideally a snap in framework)
# Test framework
# Test data (I put this here, not really as a component of the harness, more as a "i'm not telling you my test account's password and what are we gonna do about it" thing)

Python seems to be the flavor of choice here, with a requirement that it accommodate non-python components as needed. The repository for the code is proposed to be maintained by Linden Lab, distributed as an open source export, under the Apache v2 License (see http://opensource.org/licenses/apache2.0.php). The process and details here are tentative, and need more attention...

There is plenty to be figured out. How to start, who wants to play, details are all TBD. My role is primarily intended as one who will facilitate dialogue and contribute as much as possible, but this is intended as a joint effort.

-- Enus Linden

[[Category:Architecture Working Group]]
[[Category:Grid_Interoperability]]
[[Category: Pyogp|*]]
[[Category:Pyogp_Kitchen_Sink]]
[[Category: AW Groupies]]
[[Category:Automated Testing]]

PyOGP

2010-06-25T18:05:41Z

Enus Linden: /* Getting Started */

{{PyOGP/navigation}}
== Overview ==

=== What Is It? ===

Pyogp is an open source project to explore a suite of python based Second Life client libraries and to produce an automated testing framework.

PyOGP is useful for:
* learning more about Second Life's client-server relationship
* prototyping client side features
* quickly writing tests for software which communicates using LLMessageSystem-like messages
* demonstrating protocol proposals
* building test suites which validate Second Life simulator and grid functionality

=== Getting Started ===

See [[PyOGP Client Library Development Sandbox]] for instructions on the mechanics of working with the PyOGP package suite.

For a more comprehensive overview of working within the structure of classes and event systems in PyOGP packages, take a look at [[PyOGP Client Library]].

=== How To Contribute ===
* Source: [[Pyogp/Client_Lib/The_Development_Sandbox | Checkout Instructions]]. See the [[Open_Source_Portal|Open Source Portal]] for details on being a contributor
* in-world group: pyogp (open enrollement)
* IRC: irc://irc.freenode.com/#pyogp
* Mailing list: https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp, pyogp@lists.secondlife.com
* Jira: http://jira.secondlife.com/browse/PYO
* Related Meetings
** Enus Linden's office hours: Friday @ 1:00 http://slurl.com/secondlife/Longfellow/99/97/28

== Project Status ==

PyOGP is moving to bitbucket! http://bitbucket.org/enus_linden/

Thanks for the patience as we make this transition.

Keep track of progress on the list: https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp.

== Pic of the Moment ==
[[Image:355571.jpg|900x835px|the EnusBots are coming!]]

Image used with permission. Taken by [[User:Opensource_Obscure|Opensource Obscure]]. (thanks oo! <3)

== Licensing ==
Contributions to Pyogp are subject to Linden Lab's [http://secondlifegrid.net/programs/open_source/submission contributor agreement]. The Pyogp open source code is made available subject to the Apache v2 license. Read more at [http://opensource.org/licenses/apache2.0.php opensource.org] and [http://www.apache.org/licenses/LICENSE-2.0 apache.org].

<excerpt>
Copyright 2008, Linden Research, Inc.
 
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
 
http://www.apache.org/licenses/LICENSE-2.0
 
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
</excerpt>

== History ==

Linden Lab and the [[AWG]] ([[AW_Groupies|in-world discussion group page]]) are working together to develop a set of open protocols called the [[Open Grid Protocol]] that can be used to create a virtual world where regions are independently operated (not only by Linden Lab). The project is aiming to allow people (organizations, individuals, and the like) to host their own regions in the virtual world and be able to interact and communicate with people in regions hosted elsewhere. In essence, the project's goal is to allow open-source region hosting.

AWG and Linden Lab plan to share the effort in writing a test harness that executes tests against implementations of the Open Grid Protocol.

The intent is not to test SL or OpenSim (or gridX) themselves. Rather, the desire is to create a framework where the implementations of the protocols can be tested in any virtual environment implemented per the Open Grid Protocols as documented. The goal is to use the test harness to test the implementations to make sure that the virtual environment is interoperable with the other virtual environments that have implemented the OGP. However, we also plan to test the current SL protocols (the Legacy protocols). We plan to be able to test at the smallest functional level possible, akin to unit testing, and to have the ability to use the framework to sequence steps to enable state specific tests to be run.

The longer-term vision is essentially a [[Pyogp_Client_Lib|client library]], capable of navigating the grid and interacting with the various hosts, sitting next to a testing framework, happily running along telling us what works where, and where something needs a little attention to work according to specification...

For more detail on OGP, see a visual representation of the upcoming [[Open Grid Platform Projects Q2-Q3|projects]] and a general [[Structural Design Overview|introduction]].

=== Notes from the kickoff meeting ===

At the AWG meeting held April 29, 2008, we discussed what a test harness could look like that would be used to test the agent-domain, rez-avatar, and overall work being done implementing the open grid protocols. I'd like to summarize, and continue the discussion on the mailing list, in-world, and on the wiki. See [[AWGroupies-2008-04-29|meeting chat log]].

How do we start?

Let's work on defining the test harness components (from the meeting):
# Login
# Caps (and while it's around the UDP pipe)
# Message Handlers (see chttp)
# Basic web server parts for the Agent, Region and grid bits (ideally a snap in framework)
# Test framework
# Test data (I put this here, not really as a component of the harness, more as a "i'm not telling you my test account's password and what are we gonna do about it" thing)

Python seems to be the flavor of choice here, with a requirement that it accommodate non-python components as needed. The repository for the code is proposed to be maintained by Linden Lab, distributed as an open source export, under the Apache v2 License (see http://opensource.org/licenses/apache2.0.php). The process and details here are tentative, and need more attention...

There is plenty to be figured out. How to start, who wants to play, details are all TBD. My role is primarily intended as one who will facilitate dialogue and contribute as much as possible, but this is intended as a joint effort.

-- Enus Linden

[[Category:Architecture Working Group]]
[[Category:Grid_Interoperability]]
[[Category: Pyogp|*]]
[[Category:Pyogp_Kitchen_Sink]]
[[Category: AW Groupies]]
[[Category:Automated Testing]]

PyOGP

2010-06-25T18:03:34Z

Enus Linden: /* What Is It? */

{{PyOGP/navigation}}
== Overview ==

=== What Is It? ===

Pyogp is an open source project to explore a suite of python based Second Life client libraries and to produce an automated testing framework.

PyOGP is useful for:
* learning more about Second Life's client-server relationship
* prototyping client side features
* quickly writing tests for software which communicates using LLMessageSystem-like messages
* demonstrating protocol proposals
* building test suites which validate Second Life simulator and grid functionality

=== Getting Started ===

See [[PyOGP Client Library Development Sandbox]] for instructions on how to starting using Pyogp.
See also [[PyOGP Client Library]] for a more up-to-date page.

=== How To Contribute ===
* Source: [[Pyogp/Client_Lib/The_Development_Sandbox | Checkout Instructions]]. See the [[Open_Source_Portal|Open Source Portal]] for details on being a contributor
* in-world group: pyogp (open enrollement)
* IRC: irc://irc.freenode.com/#pyogp
* Mailing list: https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp, pyogp@lists.secondlife.com
* Jira: http://jira.secondlife.com/browse/PYO
* Related Meetings
** Enus Linden's office hours: Friday @ 1:00 http://slurl.com/secondlife/Longfellow/99/97/28

== Project Status ==

PyOGP is moving to bitbucket! http://bitbucket.org/enus_linden/

Thanks for the patience as we make this transition.

Keep track of progress on the list: https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp.

== Pic of the Moment ==
[[Image:355571.jpg|900x835px|the EnusBots are coming!]]

Image used with permission. Taken by [[User:Opensource_Obscure|Opensource Obscure]]. (thanks oo! <3)

== Licensing ==
Contributions to Pyogp are subject to Linden Lab's [http://secondlifegrid.net/programs/open_source/submission contributor agreement]. The Pyogp open source code is made available subject to the Apache v2 license. Read more at [http://opensource.org/licenses/apache2.0.php opensource.org] and [http://www.apache.org/licenses/LICENSE-2.0 apache.org].

<excerpt>
Copyright 2008, Linden Research, Inc.
 
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
 
http://www.apache.org/licenses/LICENSE-2.0
 
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
</excerpt>

== History ==

Linden Lab and the [[AWG]] ([[AW_Groupies|in-world discussion group page]]) are working together to develop a set of open protocols called the [[Open Grid Protocol]] that can be used to create a virtual world where regions are independently operated (not only by Linden Lab). The project is aiming to allow people (organizations, individuals, and the like) to host their own regions in the virtual world and be able to interact and communicate with people in regions hosted elsewhere. In essence, the project's goal is to allow open-source region hosting.

AWG and Linden Lab plan to share the effort in writing a test harness that executes tests against implementations of the Open Grid Protocol.

The intent is not to test SL or OpenSim (or gridX) themselves. Rather, the desire is to create a framework where the implementations of the protocols can be tested in any virtual environment implemented per the Open Grid Protocols as documented. The goal is to use the test harness to test the implementations to make sure that the virtual environment is interoperable with the other virtual environments that have implemented the OGP. However, we also plan to test the current SL protocols (the Legacy protocols). We plan to be able to test at the smallest functional level possible, akin to unit testing, and to have the ability to use the framework to sequence steps to enable state specific tests to be run.

The longer-term vision is essentially a [[Pyogp_Client_Lib|client library]], capable of navigating the grid and interacting with the various hosts, sitting next to a testing framework, happily running along telling us what works where, and where something needs a little attention to work according to specification...

For more detail on OGP, see a visual representation of the upcoming [[Open Grid Platform Projects Q2-Q3|projects]] and a general [[Structural Design Overview|introduction]].

=== Notes from the kickoff meeting ===

At the AWG meeting held April 29, 2008, we discussed what a test harness could look like that would be used to test the agent-domain, rez-avatar, and overall work being done implementing the open grid protocols. I'd like to summarize, and continue the discussion on the mailing list, in-world, and on the wiki. See [[AWGroupies-2008-04-29|meeting chat log]].

How do we start?

Let's work on defining the test harness components (from the meeting):
# Login
# Caps (and while it's around the UDP pipe)
# Message Handlers (see chttp)
# Basic web server parts for the Agent, Region and grid bits (ideally a snap in framework)
# Test framework
# Test data (I put this here, not really as a component of the harness, more as a "i'm not telling you my test account's password and what are we gonna do about it" thing)

Python seems to be the flavor of choice here, with a requirement that it accommodate non-python components as needed. The repository for the code is proposed to be maintained by Linden Lab, distributed as an open source export, under the Apache v2 License (see http://opensource.org/licenses/apache2.0.php). The process and details here are tentative, and need more attention...

There is plenty to be figured out. How to start, who wants to play, details are all TBD. My role is primarily intended as one who will facilitate dialogue and contribute as much as possible, but this is intended as a joint effort.

-- Enus Linden

[[Category:Architecture Working Group]]
[[Category:Grid_Interoperability]]
[[Category: Pyogp|*]]
[[Category:Pyogp_Kitchen_Sink]]
[[Category: AW Groupies]]
[[Category:Automated Testing]]

PyOGP Package Unittests

2010-06-25T17:52:19Z

Enus Linden:

{{PyOGP/navigation}}

== Overview ==

Each package in the lib should have unit tests, which cover as much code as possible. The unit tests evaluate the integrity of the library code itself, in terms of apis, code paths, and dependencies.

Packages under unit test right now:
pyogp.lib.base
pyogp.lib.client

Unit tests live in directories named test/ within any directory in any package.

== Python test types ==

=== unittest ===

Unit tests are written as standard python unittest implementations. For more on this, see http://docs.python.org/library/unittest.html.

=== doctest ===

doctests are narrative sample uses of code, that may be run via various test wrappers. For more, see http://docs.python.org/library/doctest.html.

== Running tests ==

=== nose ===

We use Nose! http://somethingaboutorange.com/mrl/projects/nose/0.11.1/

Buildout grabs the necessary module. If you are an enterprising soul, please download the nose source and install to your native python or virtualenv instance.

'''Nose Install Steps:'''
# http://somethingaboutorange.com/mrl/projects/nose/nose-0.11.1.tar.gz
# gzip -dc nose-0.11.1.tar.gz | tar xf -
# cd nose-0.11.1
# python setup.py install

=== in buildout ===

After running buildout, there will be a bin/unittests script available. Simply run it, passing which package's unit tests to run...

bin/unittests --where=src/pyogp.lib.client/
bin/unittests --where=src/pyogp.lib.base/

=== per packages test runs ===

There is a test.py in each of pyogp.lib.*.tests. It works in a buildout context by adding to path all the necessary packages and dependencies, or works outside of buildout assuming your python path has all the necessary modules sourced.

To run it, simply:
cd pyogp/lib/base/tests
python test.py

Pass test.py a file name, or to run all tests in the package, pass '..'.

'''Ensure the necessary modules are in your python instance's path:'''

Here's what the buildout generated nose test wrapper looks like on Enus' machine:

<pre>
#!/Users/enus/svn/buildout/bin/python

import sys
sys.path[0:0] = [
'/Users/enus/svn/buildout/eggs/uuid-1.30-py2.5.egg',
'/Users/enus/svn/buildout/eggs/indra.base-1.0-py2.5.egg',
'/Users/enus/svn/buildout/eggs/eventlet-0.8.14-py2.5.egg',
'/Users/enus/svn/buildout/eggs/wsgiref-0.1.2-py2.5.egg',
'/Users/enus/svn/buildout/src/pyogp.lib.base',
'/Users/enus/svn/buildout/eggs/nose-0.11.1-py2.5.egg',
'/Users/enus/svn/buildout/eggs/WebOb-0.9.6.1-py2.5.egg',
'/Users/enus/svn/buildout/eggs/elementtree-1.2.7_20070827_preview-py2.5.egg',
'/Users/enus/svn/buildout/eggs/setuptools-0.6c9-py2.5.egg',
'/Users/enus/svn/buildout/eggs/pyOpenSSL-0.9-py2.5-macosx-10.5-i386.egg',
'/Users/enus/svn/buildout/eggs/greenlet-0.2-py2.5-macosx-10.5-i386.egg',
'/Users/enus/svn/buildout/eggs/indra.util-1.0-py2.5.egg',
]

import nose

if __name__ == '__main__':
nose.main(argv=['nose']+sys.argv[1:])
</pre>

=== Evaluating test coverage ===

Nose has a great tie into the coverage module (http://nedbatchelder.com/code/modules/rees-coverage.html), which evaluates code coverage by our tests. Buildout automatically installs the necessary module, or, you can install it to your python instance via "easy_install coverage".

To run the unittests via a buildout instance, add the following flags (making sure package names match up):

--with-coverage --cover-package=pyogp.lib.client

For more on the nose test wrapper, see bin/unittests -h.

== Code Coverage ==

Currently, coverage of code by unittest is OK, but, we need to improve it!

=== pyogp.lib.client ===

Current coverage:

<pre>
[11:32:17] [enus@sune] buildout$ bin/unittests --where=src/pyogp.lib.client/ --with-coverage --cover-package=pyogp.lib.client

Name Stmts Exec Cover Missing
-------------------------------------------------------------
pyogp.lib.client 1 1 100%
pyogp.lib.client.agent 513 164 31% 35-49, 71, 82, 179-180, 213, 216, 222-239, 272, 281-303, 311-331, 336-345, 350-359, 365-431, 437-446, 452-457, 477-486, 496-533, 552-570, 575-580, 586-587, 593, 600-615, 620-632, 637-644, 649, 658-674, 679-700, 705-746, 751-757, 762-787, 792-804, 818-872, 881-925, 930-953, 967-980, 986-1017, 1024-1044, 1052-1068, 1073, 1080-1086, 1090-1093, 1098-1101, 1105, 1109-1112, 1117-1119
pyogp.lib.client.appearance 151 76 50% 76-83, 89-97, 122-135, 151-162, 165, 171, 179-183, 194-199, 216-226, 234-249, 257-280, 294-310, 335, 341-347, 354-355
pyogp.lib.client.assets 125 30 24% 58, 68-123, 145-168, 174, 177, 185-192, 202-211, 215-217, 222-231, 234-261
pyogp.lib.client.event_queue 153 90 58% 31, 39, 64, 73, 104, 107-109, 118-125, 136-149, 173, 179, 184-215, 220-235, 248-273
pyogp.lib.client.event_system 89 71 79% 43, 60-67, 82-84, 173-174, 184-185, 193-200, 205, 210
pyogp.lib.client.exc 136 78 57% 36, 42, 45, 57-60, 64, 73, 76, 86-90, 94, 116, 119, 128, 131, 141-142, 145, 160-161, 164, 173-174, 177, 186-187, 190, 199-200, 203, 212-213, 216, 225-226, 229, 238-239, 242, 261, 273, 285, 302, 305, 317, 330, 333, 345, 348, 356, 359, 367, 370
pyogp.lib.client.groups 243 54 22% 65-79, 85-90, 97-111, 116-130, 135-144, 149-156, 174-205, 210-215, 221-224, 229-236, 241, 246-252, 262-273, 278-287, 292-310, 315, 320, 325-329, 333-339, 347-359, 364, 369-375, 380-382, 387-404, 424-451, 469-477, 484-488, 492, 496-520, 524-527
pyogp.lib.client.inventory 495 181 36% 73-80, 84, 88, 93-152, 157-164, 173-180, 191-193, 199-202, 227, 243, 275-277, 295-302, 312, 320-322, 332-338, 350, 362, 373, 378-384, 389-391, 399-408, 417-431, 436-468, 473-480, 522, 559-560, 567-572, 577, 582, 587, 592, 599-601, 606-630, 635-659, 664-697, 702-705, 710-742, 749, 754, 759, 764-775, 780, 784-812, 816-867, 897, 902-909, 914, 924-933, 938, 948-956, 1021-1027, 1036-1040, 1046-1063, 1075-1104, 1109-1150
pyogp.lib.client.login 205 176 85% 111, 129, 150, 171, 201, 210, 225-226, 234, 281-283, 293, 300-301, 308-313, 341, 343, 347, 361, 370, 374-377, 389, 406, 433
pyogp.lib.client.objects 612 276 45% 114, 120-132, 143, 159-190, 200, 207, 212-220, 225-227, 235-239, 244-257, 262-284, 289-294, 298-303, 329-332, 340, 354, 357, 367-376, 382-391, 425-461, 466-633, 639-663, 691-693, 729-859, 907-908, 919-967, 971-973, 977-1014, 1037-1067, 1173, 1183-1195, 1203-1205, 1213-1215, 1223-1225, 1233-1235, 1242-1244, 1251-1253, 1260, 1268-1276, 1283, 1291-1299, 1304, 1309-1323, 1328-1344, 1351, 1358-1365, 1372, 1379-1386
pyogp.lib.client.parcel 372 69 18% 99-112, 122-127, 132-185, 190-212, 219-234, 239-279, 284-299, 304-307, 311, 315, 319, 325-328, 333-338, 343-359, 364-376, 381-389, 394-412, 417-424, 429-447, 452-456, 462, 467-482, 489, 521, 554, 587, 615, 642, 670, 696-699, 704-713, 721-723, 747-750, 755-763, 768-787, 797-873, 878-882, 889, 921, 945, 978, 1006, 1030, 1051, 1083, 1107, 1139
pyogp.lib.client.permissions 23 18 78% 57-61
pyogp.lib.client.region 259 91 35% 34, 40-41, 43, 78, 85, 96, 189-195, 199, 223-229, 237-240, 245-250, 255-272, 277-285, 289-315, 321-331, 336-351, 356-361, 366-367, 373-385, 390-396, 401-407, 412-416, 433-448, 453-460, 465-472, 477-514, 519-523, 528-529, 535-565, 570, 575, 580-586, 597-620, 623
pyogp.lib.client.settings 67 55 82% 146-155, 178-179
pyogp.lib.client.visualparams 502 495 98% 42-44, 50-53
-------------------------------------------------------------
TOTAL 3946 1925 48%
----------------------------------------------------------------------
Ran 94 tests in 14.455s

FAILED (errors=1)
</pre>

=== pyogp.lib.base ===

Nice coverage!

<pre>
[11:32:40] [enus@sune] buildout$ bin/unittests --where=src/pyogp.lib.base/ --with-coverage --cover-package=pyogp.lib.base

Name Stmts Exec Cover Missing
----------------------------------------------------------------------
pyogp.lib.base 1 1 100%
pyogp.lib.base.datatypes 106 73 68% 45, 49, 53, 72, 75, 80, 88-91, 107, 111, 115, 119, 136-141, 150, 153, 158, 184-189, 208, 213, 222-225, 230-232
pyogp.lib.base.exc 136 77 56% 33, 36, 42, 45, 57-60, 64, 73, 76, 86-90, 94, 116, 119, 128, 131, 141-142, 145, 160-161, 164, 173-174, 177, 186-187, 190, 199-200, 203, 212-213, 216, 225-226, 229, 238-239, 242, 261, 273, 285, 302, 305, 317, 330, 333, 345, 348, 356, 359, 367, 370
pyogp.lib.base.message 1 1 100%
pyogp.lib.base.message.circuit 84 69 82% 39, 78-83, 91, 98-104, 134, 149-150, 154
pyogp.lib.base.message.data 4 4 100%
pyogp.lib.base.message.data_packer 63 48 76% 66, 69-70, 73-75, 78, 81, 84-87, 92, 99, 101
pyogp.lib.base.message.data_unpacker 65 57 87% 76-80, 83-84, 91, 94, 100
pyogp.lib.base.message.llsd_builder 39 38 97% 34
pyogp.lib.base.message.message 63 42 66% 35-36, 43-44, 109-110, 114, 119-136, 141
pyogp.lib.base.message.message_handler 44 29 65% 38, 47-49, 60, 75-78, 88-90, 93, 97, 100-102, 106
pyogp.lib.base.message.msgtypes 83 76 91% 45-47, 118, 125, 127, 143
pyogp.lib.base.message.template 133 105 78% 46, 63, 71, 84, 87-92, 98, 101, 105, 116, 119, 121, 145, 148, 151, 154, 187, 190, 196, 199, 202, 205, 208, 211, 214
pyogp.lib.base.message.template_dict 58 52 89% 49-52, 100, 106
pyogp.lib.base.message.template_parser 228 187 82% 172-173, 177, 223, 252, 266-278, 281-294, 297-305, 309-317, 320
pyogp.lib.base.message.udpdeserializer 180 139 77% 52, 76-78, 116-125, 132, 138, 145-147, 170, 175, 184, 193, 197, 220-230, 240, 262, 274-275, 296-297, 308-315, 321-323, 335
pyogp.lib.base.message.udpdispatcher 149 108 72% 80, 111, 124-130, 135, 141, 147, 164, 173, 178, 190, 192, 203-211, 220-224, 242-255, 281, 287-288, 297-301, 305
pyogp.lib.base.message.udpserializer 66 57 86% 72, 89, 110-111, 131, 138, 143-147
pyogp.lib.base.network 1 1 100%
pyogp.lib.base.network.net 27 14 51% 31, 35-38, 41-50, 66
pyogp.lib.base.settings 67 45 67% 146-155, 167-198
pyogp.lib.base.utilities 1 1 100%
pyogp.lib.base.utilities.events 35 17 48% 36-38, 43-51, 55-65, 69, 73-74, 78
pyogp.lib.base.utilities.helpers 107 45 42% 48, 54-58, 64-71, 77-81, 87-100, 106-119, 125-128, 136, 150, 156, 162, 187, 204, 208, 213, 267-268, 270, 275-276, 287-292, 296-305, 309
----------------------------------------------------------------------
TOTAL 1741 1286 73%
----------------------------------------------------------------------
Ran 71 tests in 17.255s

OK
</pre>

== Writing Test Cases ==

Tests can be written using standard unittest. The tests in pyogp.interop cover some ogp and a couple of legacy cases, these need to be updated to work.

Testing only the call to login.cgi is unique, we don't need to spawn the client in a coroutine, nor do we need to keep the client alive, we just need to post to the login endpoint and evaluate the response.

=== pyogp.lib.client.test.test_agent ===

This test is a standard unittest instance, which tests agent.py at some level of coverage, and also shows how to use some of the mock objects available for use in testing the libs without connecting to a real grid. The mocks should likely be reworked to be simplified and standardized, but are functional for now.

<python># standard python libs
import unittest

# pyogp
from pyogp.lib.client.agent import Agent, Home
from pyogp.lib.client.login import LegacyLoginParams, OGPLoginParams
from pyogp.lib.client.exc import LoginError

# pyogp tests
from pyogp.lib.base.tests.mock_xmlrpc import MockXMLRPC
from pyogp.lib.base.tests.base import MockXMLRPCLogin, MockAgentDomainLogin
from pyogp.lib.base.network.tests.mockup_client import MockupClient
import pyogp.lib.base.tests.config

class TestAgent(unittest.TestCase):

def setUp(self):

self.legacy_loginuri = 'http://localhost:12345/cgi-bin/login.cgi'
self.ogp_loginuri = 'http://localhost:12345/auth.cgi'
self.firstname = 'firstname'
self.lastname = 'lastname'
self.password = 'secret'

self.client = Agent()

def tearDown(self):

pass

def test_agent_legacy_login_via_variables(self):

# override the network client with the mock client pointed at the mock login handler
self.loginhandler = MockXMLRPC(MockXMLRPCLogin(), self.legacy_loginuri)

self.client.login(self.legacy_loginuri, self.firstname, self.lastname, self.password, start_location = 'start', handler = self.loginhandler, connect_region = False)

self.assertEquals(self.client.login_response, {'region_y': '256', 'region_x': '256', 'first_name': '"first"', 'secure_session_id': '00000000-0000-0000-0000-000000000000', 'sim_ip': '127.0.0.1', 'agent_access': 'M', 'circuit_code': '600000000', 'look_at': '[r0.9963859999999999939,r-0.084939700000000006863,r0]', 'session_id': '00000000-0000-0000-0000-000000000000', 'udp_blacklist': 'EnableSimulator,TeleportFinish,CrossedRegion', 'seed_capability': 'https://somesim:12043/cap/00000000-0000-0000-0000-000000000000', 'agent_id': '00000000-0000-0000-0000-000000000000', 'last_name': 'last', 'inventory_host': 'someinvhost', 'start_location': 'last', 'sim_port': '13001', 'message': 'message', 'login': 'true', 'seconds_since_epoch': '1234567890'})

def test_agent_legacy_login_via_params(self):

# override the network client with the mock client pointed at the mock login handler
self.loginhandler = MockXMLRPC(MockXMLRPCLogin(), self.legacy_loginuri)

login_params = LegacyLoginParams(self.firstname, self.lastname, self.password)

self.client.login(self.legacy_loginuri, login_params = login_params, start_location = 'start', handler = self.loginhandler, connect_region = False)

self.assertEquals(self.client.login_response, {'region_y': '256', 'region_x': '256', 'first_name': '"first"', 'secure_session_id': '00000000-0000-0000-0000-000000000000', 'sim_ip': '127.0.0.1', 'agent_access': 'M', 'circuit_code': '600000000', 'look_at': '[r0.9963859999999999939,r-0.084939700000000006863,r0]', 'session_id': '00000000-0000-0000-0000-000000000000', 'udp_blacklist': 'EnableSimulator,TeleportFinish,CrossedRegion', 'seed_capability': 'https://somesim:12043/cap/00000000-0000-0000-0000-000000000000', 'agent_id': '00000000-0000-0000-0000-000000000000', 'last_name': 'last', 'inventory_host': 'someinvhost', 'start_location': 'last', 'sim_port': '13001', 'message': 'message', 'login': 'true', 'seconds_since_epoch': '1234567890'})

def test_agent_ogp_login_via_variables(self):

# override the network client with the mock client pointed at the mock login handler
self.loginhandler = MockupClient(MockAgentDomainLogin())

self.client.login(self.ogp_loginuri, self.firstname, self.lastname, self.password, start_location = 'start', handler = self.loginhandler, connect_region = False)

self.assertEquals(self.client.login_response, {'agent_seed_capability': 'http://127.0.0.1:12345/seed_cap', 'authenticated': True})

def test_agent_ogp_login_via_params(self):

# override the network client with the mock client pointed at the mock login handler
self.loginhandler = MockupClient(MockAgentDomainLogin())

login_params = OGPLoginParams(self.firstname, self.lastname, self.password)

self.client.login(self.ogp_loginuri, self.firstname, self.lastname, self.password, start_location = 'start', handler = self.loginhandler, connect_region = False)

self.assertEquals(self.client.login_response, {'agent_seed_capability': 'http://127.0.0.1:12345/seed_cap', 'authenticated': True})

def test_agent_login_no_account_info(self):

self.assertRaises(LoginError, self.client.login, self.ogp_loginuri)

def test_legacy_get_login_params(self):

self.client.grid_type = 'Legacy'
params = self.client._get_login_params(self.firstname, self.lastname, self.password)

self.assertEquals(type(params), type(LegacyLoginParams(self.firstname, self.lastname, self.password)))

def test_ogp_get_login_params(self):

self.client.grid_type = 'OGP'
params = self.client._get_login_params(self.firstname, self.lastname, self.password)

self.assertEquals(type(params), type(OGPLoginParams(self.firstname, self.lastname, self.password)))

'''
def test_failed_legacy_login(self):

# ToDo: enable mne when you can get me working, it's 'correct',
# but not raising the error properly?

self.password = 'badpassword'

# override the network client with the mock client pointed at the mock login handler
self.loginhandler = MockXMLRPC(MockXMLRPCLogin(), self.legacy_loginuri)

self.assertRaises(LoginError, self.client.login, self.legacy_loginuri, self.firstname, self.lastname, self.password, start_location = 'start', handler = self.loginhandler)
'''

def test_agent_home_class(self):

home_string = "{'region_handle':[r261120, r247040], 'position':[r171.622, r148.26, r79.3938], 'look_at':[r0, r1, r0]}"

home = Home(home_string)

# Note: have not yet worked out precision on floats. Kinda need to
self.assertEquals(home.region_handle, [261120, 247040])
self.assertEquals(home.position.X, 171.62200000000001)
self.assertEquals(home.position.Y, 148.25999999999999)
self.assertEquals(home.position.Z, 79.393799999999999)
self.assertEquals(home.look_at.X, 0)
self.assertEquals(home.look_at.Y, 1)
self.assertEquals(home.look_at.Z, 0)
self.assertEquals(home.global_x, 261120)
self.assertEquals(home.global_y, 247040)

def test_suite():
from unittest import TestSuite, makeSuite
suite = TestSuite()
suite.addTest(makeSuite(TestAgent))
return suite</python>

[[Category: Pyogp_Client_Lib]]
[[Category: Pyogp]]

Template:PyOGP/navigation

2010-06-25T17:51:54Z

Enus Linden:

<div id="box" style="float:right; width:17em; padding-bottom:1em; padding-left:1em; margin-left: 0.5em">
'''[[PyOGP]]'''
* [[PyOGP Client Library]]:
** [[PyOGP Coding Guidelines|Coding Guidelines]]
** [[PyOGP Client Library Development|Package Development]]
** [[PyOGP Client Library Development Sandbox|Client Development Sandbox]]
** [[PyOGP Package Unittests|Package Unittests]]
</div>

PyOGP Client Library Development

2010-06-25T17:45:25Z

Enus Linden: /* How-Tos */

{{PyOGP/navigation}}

'''Note:''' Major revisions are needed to pull this document up to speed.

This is the development page for the [[Pyogp]] [[Pyogp/Client_Lib | Client Library]].
If you want to work with us on PyOGP here is all you need to know.

== Setup and Preliminary Info==

* [[Pyogp/Client_Lib/The_Development_Sandbox| How to setup a development sandbox for developing the library]]
* [[Pyogp/Client_Lib/Filesystem_Structure| The filesystem structure of pyogp]]

== Development Principles ==

* Tools we use (buildout, eggs, unit tests)
* How do I add new functionality the best way? See [[PyOGP_Client_Library]] for implementation details.

== How-Tos ==

* [[PyOGP_Client_Library#Extending_Functionality | How do I add a new component/subproject to the project?]]
* [[PyOGP_Package_Unittests | How do I write and run library unit tests? ]]

== Code Status ==
*[https://svn.secondlife.com/svn/linden/projects/2008/pyogp/ Current Pyogp Repo] - svn repo of the most up-to-date code we are using for the project

== Coding Guidelines ==

We've recently published goals to keep in mind while writing new code for PyOGP. Please follow [[PyOGP_Coding_Guidelines]] when possible.

== Documentation ==
* Pyogp created documentation
** [[Pyogp/Client_Lib/Packet]] - notes that may help understand the rest
** [[Pyogp/Documentation/Specification/pyogp.lib.base]] - documentation on the code
 
* Current Protocols
** [[Current_login_protocols]] - what login is like now
** [[Current_Sim_Capabilities]] - capabilities that are currently used
* OGP Protocols
** [[Structural_Design]] - the design of the new architecture
** [[Open Grid Protocol]] - the outline of the OGP protocols
** [[OGP_Draft_Login|OGP Draft Login flowchart]] - flowchart for current OGP login protocols
** [[SLGOGP_Teleport_Strawman]] - what login may be like
** [[Second_Life_Login_API_Strawman]] - what login may be like
** [[OGP_Draft_Login]] - diagrams of the OGP login
* General Notes
** [[Second_Life_Grid_Protocols/Foundation]] - general protocol information
** [[Protocol]] - this is general information about messaging and the various protocol systems
** [http://en.wikipedia.org/wiki/Comet_(programming) COMET programming]
** [[Eventlet]] - a networking library written in Python, probably going to be used for this project
***NOTE: We have been testing eventlet and it seems there's a problem posting to the seed capability.
****[[Pyogp_Client_Lib/Login_Test_Script]] - a very simple test script using eventlet that fails at the post to the seed cap
***Windows Instructions - Eventlet for Windows is a bit tricky to install
****[[User:Baba_Yamamoto/Eventlet]] - there are some problems with eventlet that Baba has looked into
****greenlet - you MUST have Visual Studio 2003 installed to install greenlet on windows (are there binary versions?). Use easy_install greenlet to install it.
****pyOpenSSl - windows versions
*****[http://webcleaner.sourceforge.net/pyOpenSSL-0.6.win32-py2.4.exe pyOpenSSL py2.4] - windows pyOpenSSL for Python 2.4
*****[http://webcleaner.sourceforge.net/pyOpenSSL-0.6.win32-py2.5.exe pyOpenSSL py2.5] - windows pyOpenSSL for Python 2.5
****util.py - has a dependency on fcntl. Go into eventlet's util.py, and either comment out all the fcntl calls, or for a slightly (not a good fix) better solution, [https://lists.secondlife.com/pipermail/sldev/2007-September/004790.html Donovan's Fix]
** [[Circuit]] - the way to pass two-way information along a UDP connection
** [[Message]] - more detail of messages
** [[Reverse_HTTP]] - I believe this is used (or will be) in the OGP protocols
** [http://www.libsecondlife.org/wiki/Protocol_%28network%29 General Packet Format] - libsecondlife - describes what the general format is for a packet
** [http://www.libsecondlife.org/wiki/ACK ACKs] - libsecondlife - describes what an ACK is
* Coding notes
** [http://www.muthukadan.net/docs/zca.html ZCA Guide] - ZCA that the lib project will be using
* Python Docs
** [http://www.python.org/doc/current/lib/module-distutils.html DistUtils] -
*** [http://www.python.org/community/sigs/current/distutils-sig/ Sig for utils]
** [http://peak.telecommunity.com/DevCenter/PythonEggs Python Eggs] -
*** [http://peak.telecommunity.com/DevCenter/setuptools setuptools] - lib to handle eggs

* Old Code
**[http://pysecondlife.googlecode.com/svn/pyogp/pyogp.lib.base/trunk: Tao Takashi's Pyogp] - svn repo - Tao Takashi has hit the ground running with an experimental framework which has been made available [http://code.google.com/p/pysecondlife/ here].
***Read more at his blogpost describing the start of his work at his very long [http://mrtopf.de/blog/secondlife/worldofsl/setting-up-a-framework-for-a-python-implementation-of-the-open-grid-protocol-technical url].
**[[Presence_Code_Python| Sai's Presence]] and [[Presence_Code_Python_cmd_line| Sai's Presence_cmd_line]] - Saijanai Kuhn's first attempts at some Python presence
**[https://svn.secondlife.com/svn/linden/projects/2008/pyogp_old/ Linden Pyogp] - svn repo of Linden's first stab at framework, using Sai's code as a base
***[https://svn.secondlife.com/svn/linden/projects/2008/pyogp_old/examples/pyogp.lib-login.py pyogp.lib-login.py] - sample script which logs into aditi's agent domain and establishes a presence on a simulator on vaak:
***Disclaimer*: Everything in the repo now will change dramatically in the next few weeks as things firm up structure wise. My desires for the work include: a simple, well defined library, a separate test framework (unittest, the initial high level code to be added this week), an samples/examples sandbox, and clean well commented code. That said, none of the above are in place now. They will be. More sophisticated implementations can evolve over time, or can be included on the side of the library...
**[[Example_protocol_code]] - code written about login and presence
** [http://zhaewry.wordpress.com/2008/06/05/happy-jumpy-ruths-interop-takes-a-step/ Interop Ruths] - some news that may be of interest to us

== Licensing ==
# The code written as part of this effort is subject to the Apache v2 license. Read more at http://opensource.org/licenses/apache2.0.php.

<excerpt>
Copyright 2008, Linden Research, Inc.
 
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
 
http://www.apache.org/licenses/LICENSE-2.0
 
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
</excerpt>

[[Category: Pyogp_Client_Lib]]

PyOGP Client Library Development

2010-06-25T17:44:24Z

Enus Linden: /* How-Tos */

{{PyOGP/navigation}}

'''Note:''' Major revisions are needed to pull this document up to speed.

This is the development page for the [[Pyogp]] [[Pyogp/Client_Lib | Client Library]].
If you want to work with us on PyOGP here is all you need to know.

== Setup and Preliminary Info==

* [[Pyogp/Client_Lib/The_Development_Sandbox| How to setup a development sandbox for developing the library]]
* [[Pyogp/Client_Lib/Filesystem_Structure| The filesystem structure of pyogp]]

== Development Principles ==

* Tools we use (buildout, eggs, unit tests)
* How do I add new functionality the best way? See [[PyOGP_Client_Library]] for implementation details.

== How-Tos ==

* [[Pyogp/Client_Lib/newcomponent | How do I add a new component/subproject to the project?]]
* [[PyOGP_Package_Unittests | How do I write and run library unit tests? ]]

== Code Status ==
*[https://svn.secondlife.com/svn/linden/projects/2008/pyogp/ Current Pyogp Repo] - svn repo of the most up-to-date code we are using for the project

== Coding Guidelines ==

We've recently published goals to keep in mind while writing new code for PyOGP. Please follow [[PyOGP_Coding_Guidelines]] when possible.

== Documentation ==
* Pyogp created documentation
** [[Pyogp/Client_Lib/Packet]] - notes that may help understand the rest
** [[Pyogp/Documentation/Specification/pyogp.lib.base]] - documentation on the code
 
* Current Protocols
** [[Current_login_protocols]] - what login is like now
** [[Current_Sim_Capabilities]] - capabilities that are currently used
* OGP Protocols
** [[Structural_Design]] - the design of the new architecture
** [[Open Grid Protocol]] - the outline of the OGP protocols
** [[OGP_Draft_Login|OGP Draft Login flowchart]] - flowchart for current OGP login protocols
** [[SLGOGP_Teleport_Strawman]] - what login may be like
** [[Second_Life_Login_API_Strawman]] - what login may be like
** [[OGP_Draft_Login]] - diagrams of the OGP login
* General Notes
** [[Second_Life_Grid_Protocols/Foundation]] - general protocol information
** [[Protocol]] - this is general information about messaging and the various protocol systems
** [http://en.wikipedia.org/wiki/Comet_(programming) COMET programming]
** [[Eventlet]] - a networking library written in Python, probably going to be used for this project
***NOTE: We have been testing eventlet and it seems there's a problem posting to the seed capability.
****[[Pyogp_Client_Lib/Login_Test_Script]] - a very simple test script using eventlet that fails at the post to the seed cap
***Windows Instructions - Eventlet for Windows is a bit tricky to install
****[[User:Baba_Yamamoto/Eventlet]] - there are some problems with eventlet that Baba has looked into
****greenlet - you MUST have Visual Studio 2003 installed to install greenlet on windows (are there binary versions?). Use easy_install greenlet to install it.
****pyOpenSSl - windows versions
*****[http://webcleaner.sourceforge.net/pyOpenSSL-0.6.win32-py2.4.exe pyOpenSSL py2.4] - windows pyOpenSSL for Python 2.4
*****[http://webcleaner.sourceforge.net/pyOpenSSL-0.6.win32-py2.5.exe pyOpenSSL py2.5] - windows pyOpenSSL for Python 2.5
****util.py - has a dependency on fcntl. Go into eventlet's util.py, and either comment out all the fcntl calls, or for a slightly (not a good fix) better solution, [https://lists.secondlife.com/pipermail/sldev/2007-September/004790.html Donovan's Fix]
** [[Circuit]] - the way to pass two-way information along a UDP connection
** [[Message]] - more detail of messages
** [[Reverse_HTTP]] - I believe this is used (or will be) in the OGP protocols
** [http://www.libsecondlife.org/wiki/Protocol_%28network%29 General Packet Format] - libsecondlife - describes what the general format is for a packet
** [http://www.libsecondlife.org/wiki/ACK ACKs] - libsecondlife - describes what an ACK is
* Coding notes
** [http://www.muthukadan.net/docs/zca.html ZCA Guide] - ZCA that the lib project will be using
* Python Docs
** [http://www.python.org/doc/current/lib/module-distutils.html DistUtils] -
*** [http://www.python.org/community/sigs/current/distutils-sig/ Sig for utils]
** [http://peak.telecommunity.com/DevCenter/PythonEggs Python Eggs] -
*** [http://peak.telecommunity.com/DevCenter/setuptools setuptools] - lib to handle eggs

* Old Code
**[http://pysecondlife.googlecode.com/svn/pyogp/pyogp.lib.base/trunk: Tao Takashi's Pyogp] - svn repo - Tao Takashi has hit the ground running with an experimental framework which has been made available [http://code.google.com/p/pysecondlife/ here].
***Read more at his blogpost describing the start of his work at his very long [http://mrtopf.de/blog/secondlife/worldofsl/setting-up-a-framework-for-a-python-implementation-of-the-open-grid-protocol-technical url].
**[[Presence_Code_Python| Sai's Presence]] and [[Presence_Code_Python_cmd_line| Sai's Presence_cmd_line]] - Saijanai Kuhn's first attempts at some Python presence
**[https://svn.secondlife.com/svn/linden/projects/2008/pyogp_old/ Linden Pyogp] - svn repo of Linden's first stab at framework, using Sai's code as a base
***[https://svn.secondlife.com/svn/linden/projects/2008/pyogp_old/examples/pyogp.lib-login.py pyogp.lib-login.py] - sample script which logs into aditi's agent domain and establishes a presence on a simulator on vaak:
***Disclaimer*: Everything in the repo now will change dramatically in the next few weeks as things firm up structure wise. My desires for the work include: a simple, well defined library, a separate test framework (unittest, the initial high level code to be added this week), an samples/examples sandbox, and clean well commented code. That said, none of the above are in place now. They will be. More sophisticated implementations can evolve over time, or can be included on the side of the library...
**[[Example_protocol_code]] - code written about login and presence
** [http://zhaewry.wordpress.com/2008/06/05/happy-jumpy-ruths-interop-takes-a-step/ Interop Ruths] - some news that may be of interest to us

== Licensing ==
# The code written as part of this effort is subject to the Apache v2 license. Read more at http://opensource.org/licenses/apache2.0.php.

<excerpt>
Copyright 2008, Linden Research, Inc.
 
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
 
http://www.apache.org/licenses/LICENSE-2.0
 
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
</excerpt>

[[Category: Pyogp_Client_Lib]]

PyOGP Client Library Development

2010-06-25T17:44:11Z

Enus Linden: /* How-Tos */

{{PyOGP/navigation}}

'''Note:''' Major revisions are needed to pull this document up to speed.

This is the development page for the [[Pyogp]] [[Pyogp/Client_Lib | Client Library]].
If you want to work with us on PyOGP here is all you need to know.

== Setup and Preliminary Info==

* [[Pyogp/Client_Lib/The_Development_Sandbox| How to setup a development sandbox for developing the library]]
* [[Pyogp/Client_Lib/Filesystem_Structure| The filesystem structure of pyogp]]

== Development Principles ==

* Tools we use (buildout, eggs, unit tests)
* How do I add new functionality the best way? See [[PyOGP_Client_Library]] for implementation details.

== How-Tos ==

* [[Pyogp/Client_Lib/newcomponent | How do I add a new component/subproject to the project?]]
* [[PyOGP_Package_Unittests | How do I write and run tests? ]]

== Code Status ==
*[https://svn.secondlife.com/svn/linden/projects/2008/pyogp/ Current Pyogp Repo] - svn repo of the most up-to-date code we are using for the project

== Coding Guidelines ==

We've recently published goals to keep in mind while writing new code for PyOGP. Please follow [[PyOGP_Coding_Guidelines]] when possible.

== Documentation ==
* Pyogp created documentation
** [[Pyogp/Client_Lib/Packet]] - notes that may help understand the rest
** [[Pyogp/Documentation/Specification/pyogp.lib.base]] - documentation on the code
 
* Current Protocols
** [[Current_login_protocols]] - what login is like now
** [[Current_Sim_Capabilities]] - capabilities that are currently used
* OGP Protocols
** [[Structural_Design]] - the design of the new architecture
** [[Open Grid Protocol]] - the outline of the OGP protocols
** [[OGP_Draft_Login|OGP Draft Login flowchart]] - flowchart for current OGP login protocols
** [[SLGOGP_Teleport_Strawman]] - what login may be like
** [[Second_Life_Login_API_Strawman]] - what login may be like
** [[OGP_Draft_Login]] - diagrams of the OGP login
* General Notes
** [[Second_Life_Grid_Protocols/Foundation]] - general protocol information
** [[Protocol]] - this is general information about messaging and the various protocol systems
** [http://en.wikipedia.org/wiki/Comet_(programming) COMET programming]
** [[Eventlet]] - a networking library written in Python, probably going to be used for this project
***NOTE: We have been testing eventlet and it seems there's a problem posting to the seed capability.
****[[Pyogp_Client_Lib/Login_Test_Script]] - a very simple test script using eventlet that fails at the post to the seed cap
***Windows Instructions - Eventlet for Windows is a bit tricky to install
****[[User:Baba_Yamamoto/Eventlet]] - there are some problems with eventlet that Baba has looked into
****greenlet - you MUST have Visual Studio 2003 installed to install greenlet on windows (are there binary versions?). Use easy_install greenlet to install it.
****pyOpenSSl - windows versions
*****[http://webcleaner.sourceforge.net/pyOpenSSL-0.6.win32-py2.4.exe pyOpenSSL py2.4] - windows pyOpenSSL for Python 2.4
*****[http://webcleaner.sourceforge.net/pyOpenSSL-0.6.win32-py2.5.exe pyOpenSSL py2.5] - windows pyOpenSSL for Python 2.5
****util.py - has a dependency on fcntl. Go into eventlet's util.py, and either comment out all the fcntl calls, or for a slightly (not a good fix) better solution, [https://lists.secondlife.com/pipermail/sldev/2007-September/004790.html Donovan's Fix]
** [[Circuit]] - the way to pass two-way information along a UDP connection
** [[Message]] - more detail of messages
** [[Reverse_HTTP]] - I believe this is used (or will be) in the OGP protocols
** [http://www.libsecondlife.org/wiki/Protocol_%28network%29 General Packet Format] - libsecondlife - describes what the general format is for a packet
** [http://www.libsecondlife.org/wiki/ACK ACKs] - libsecondlife - describes what an ACK is
* Coding notes
** [http://www.muthukadan.net/docs/zca.html ZCA Guide] - ZCA that the lib project will be using
* Python Docs
** [http://www.python.org/doc/current/lib/module-distutils.html DistUtils] -
*** [http://www.python.org/community/sigs/current/distutils-sig/ Sig for utils]
** [http://peak.telecommunity.com/DevCenter/PythonEggs Python Eggs] -
*** [http://peak.telecommunity.com/DevCenter/setuptools setuptools] - lib to handle eggs

* Old Code
**[http://pysecondlife.googlecode.com/svn/pyogp/pyogp.lib.base/trunk: Tao Takashi's Pyogp] - svn repo - Tao Takashi has hit the ground running with an experimental framework which has been made available [http://code.google.com/p/pysecondlife/ here].
***Read more at his blogpost describing the start of his work at his very long [http://mrtopf.de/blog/secondlife/worldofsl/setting-up-a-framework-for-a-python-implementation-of-the-open-grid-protocol-technical url].
**[[Presence_Code_Python| Sai's Presence]] and [[Presence_Code_Python_cmd_line| Sai's Presence_cmd_line]] - Saijanai Kuhn's first attempts at some Python presence
**[https://svn.secondlife.com/svn/linden/projects/2008/pyogp_old/ Linden Pyogp] - svn repo of Linden's first stab at framework, using Sai's code as a base
***[https://svn.secondlife.com/svn/linden/projects/2008/pyogp_old/examples/pyogp.lib-login.py pyogp.lib-login.py] - sample script which logs into aditi's agent domain and establishes a presence on a simulator on vaak:
***Disclaimer*: Everything in the repo now will change dramatically in the next few weeks as things firm up structure wise. My desires for the work include: a simple, well defined library, a separate test framework (unittest, the initial high level code to be added this week), an samples/examples sandbox, and clean well commented code. That said, none of the above are in place now. They will be. More sophisticated implementations can evolve over time, or can be included on the side of the library...
**[[Example_protocol_code]] - code written about login and presence
** [http://zhaewry.wordpress.com/2008/06/05/happy-jumpy-ruths-interop-takes-a-step/ Interop Ruths] - some news that may be of interest to us

== Licensing ==
# The code written as part of this effort is subject to the Apache v2 license. Read more at http://opensource.org/licenses/apache2.0.php.

<excerpt>
Copyright 2008, Linden Research, Inc.
 
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
 
http://www.apache.org/licenses/LICENSE-2.0
 
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
</excerpt>

[[Category: Pyogp_Client_Lib]]

PyOGP Client Library Development Sandbox

2010-06-25T17:41:24Z

Enus Linden: /* Environment Preparation */

PyOGP Client Library Development Sandbox

2010-06-25T17:39:57Z

Enus Linden:

{{PyOGP/navigation}}
We will first run down the general explanation and add platform specific notes later.

== Repositories ==

Stable trunk repositories:
* http://bitbucket.org/enus_linden/pyogp.apps/
* http://bitbucket.org/enus_linden/pyogp.lib.base/
* http://bitbucket.org/enus_linden/pyogp.lib.client/
* http://bitbucket.org/enus_linden/pyogp.buildout/

Maintenance repositories:
* http://bitbucket.org/enus_linden/pyogp.apps-maint/
* http://bitbucket.org/enus_linden/pyogp.lib.base-maint/
* http://bitbucket.org/enus_linden/pyogp.lib.client-maint/
* http://bitbucket.org/enus_linden/pyogp.buildout-maint/

Defunct until someone picks them up and fixes them:
* http://bitbucket.org/enus_linden/pyogp.interop/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/

== Browse the Code ==

If all you want to do is glance at the source code, use the bitbucket source browser:
* http://bitbucket.org/enus_linden/pyogp.apps/src/
* http://bitbucket.org/enus_linden/pyogp.buildout/src/
* http://bitbucket.org/enus_linden/pyogp.interop/src/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/src/
* http://bitbucket.org/enus_linden/pyogp.lib.base/src/
* http://bitbucket.org/enus_linden/pyogp.lib.client/src/

== Environment Preparation ==

=== Prerequisites ===

You must have the following installed:
* Mercurial - 1.3 or greater
* Python 2.4.4, 2.5.x, 2.6.x (untested on 3.0)

=== Mac Specifics ===

'''Note:''' Snow Leopard upgrades require a reinstall of XCode, in this case to accommodate gcc (and greenlet).

'''Setuptools''' and '''easy_install''' are Python standard means for installing modules. For more info, start here: http://pypi.python.org/pypi/setuptools.

'''Virtualenv''' is a method which allows you to create isolated Python environments, separate from your base install if you so prefer. For more, see here: http://pypi.python.org/pypi/virtualenv.

Your distribution may have Python's '''setuptools''' and '''virtualenv''' packages in its package repository. If so, it is probably best to use your normal package installation procedures (see below for information on specific Linux distributions). If the packages are not available then follow these generic instructions.

=== Generic *nix Specifics ===

In order to install Python Packages and creating a development sandbox you have to do the following:

=== easy_install ===

"Easy Install is a python module (easy_install) bundled with setuptools that lets you automatically download, build, install, and manage Python packages." I stole that from here: http://peak.telecommunity.com/DevCenter/EasyInstall.

Download ez_setup.py and run it with your Python interpreter. You can find it here: http://peak.telecommunity.com/dist/ez_setup.py

Eventually you have to be root to do this depending on your system (mostly non-windows). It should look like this on a unix based machine:

wget http://peak.telecommunity.com/dist/ez_setup.py
-or-
curl -O http://peak.telecommunity.com/dist/ez_setup.py
sudo python ez_setup.py

=== virtualenv ===

Virtualenv builds isolated python environments. To learn more, read this: http://pypi.python.org/pypi/virtualenv.

To use a dedicated python installation in your host, isolated from your system python install, install virtualenv like this:

easy_install virtualenv

Or, if you need to be root something like this:

sudo easy_install virtualenv

On windows, you may need a different path to easy_install

c:\Python25\Scripts\easy_install.exe virtualenv

== Install methods ==

Python modules can be installed in a variety of ways... we're encouraging the virtualenv and setup.py method.

=== buildout ===

Buildout has a variety of uses, in PyOGP's case it is used as a development sandbox. Buildout will checkout all the necessary PyOGP repositories and their dependencies, and configure everything automatically (set up the right path members and install scripts). Once the sandbox is set up, you can make changes to the libs in the parts/ directory (they are actually local mercurial repositories), update the code referenced in buildout (re-run bin/buildout), and test your changes.

It's really easy to work with...

1. First check out the buildout into a directory of your choice:

hg clone http://bitbucket.org/enus_linden/pyogp.buildout (or grab pyogp.buildout-maint to work with maintenance repos)

2. Now turn this checkout into a virtual python environment, independent of your normal Python installation:

cd pyogp.buildout
virtualenv . --no-site-packages

on windows, you may need to specify the path

c:\Python25\Scripts\virtualenv.exe . --no-site-packages

3. Now run the bootstrap.py file with the newly created local Python interpreter:

bin/python bootstrap.py

or on Windows:

Scripts\python bootstrap.py

4. This creates a bunch of directories and the bin/buildout script (bin\buildout.exe on windows). We now run this:

bin/buildout -v

or on Windows:

bin\buildout.exe -v

5. The development sandbox is ready. There now is a bin/pyogp_interpreter, a python interpreter which contains all the installed packages and the pyogp libraries and dependencies referenced in the path.

6. Test the buildout installation. To test this installation you can (at least at this stage of the project) try the following sample script or run the unittests:

bin/region_connect <firstname> <lastname>

-or-

bin/unittests --where=parts/pyogp.lib.base (or pyogp.lib.client)

Enter the avatar's password when prompted, and you're on your way to aditi, the Beta Grid.

=== setup.py ===

If you prefer to not use buildout, and to do things a bit more manually, well, you probably don't need much help here then do you? ;)

Grab the source for each of the pyogp repos, and install them to a virtualenv instance (see above for installing virtualenv if you don't have it)..

Here's a simple setup that Enus likes:
cd ~
mkdir sandbox
cd sandbox
virtualenv . --no-site-packages
cd ~
mkdir hg
cd hg
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.apps/
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.base/
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.client/
cd ~/hg/pyogp.lib.base
~/sandbox/bin/python setup.py install
cd ~/hg/pyogp.lib.client
~/sandbox/bin/python setup.py install
cd ~/hg/pyogp.apps
~/sandbox/bin/python setup.py install
......
now, in ~/sandbox/bin/ you'll have all kinds of pyogp executables for testing stuff out (like region_connect, etc)

You now have all the source, plus a sandbox, for tinkering with pyogp!

To try an executable out, just run it in ~/sandbox/bin/. for example:
~/sandbox/bin/region_connect firstname lastname
This command will login in your agent to aditi, and will prompt you for a password.

Pass any script the "-h" param to get it's usage.

== Run the tests ==

See [[PyOGP_Package_Unittests]] for details...

[[Category: Pyogp_Client_Lib]]

PyOGP Client Library Development Sandbox

2010-06-25T17:39:37Z

Enus Linden:

{{PyOGP/navigation}}
We will first run down the general explanation and add platform specific notes later.

== Repositories ==

Stable trunk repositories:
* http://bitbucket.org/enus_linden/pyogp.apps/
* http://bitbucket.org/enus_linden/pyogp.lib.base/
* http://bitbucket.org/enus_linden/pyogp.lib.client/
* http://bitbucket.org/enus_linden/pyogp.buildout/

Maintenance repositories:
* http://bitbucket.org/enus_linden/pyogp.apps-maint/
* http://bitbucket.org/enus_linden/pyogp.lib.base-maint/
* http://bitbucket.org/enus_linden/pyogp.lib.client-maint/
* http://bitbucket.org/enus_linden/pyogp.buildout-maint/

Defunct until someone picks them up and fixes them:
* http://bitbucket.org/enus_linden/pyogp.interop/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/

== Browse the Code ==

If all you want to do is glance at the source code, use the bitbucket source browser:
* http://bitbucket.org/enus_linden/pyogp.apps/src/
* http://bitbucket.org/enus_linden/pyogp.buildout/src/
* http://bitbucket.org/enus_linden/pyogp.interop/src/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/src/
* http://bitbucket.org/enus_linden/pyogp.lib.base/src/
* http://bitbucket.org/enus_linden/pyogp.lib.client/src/

== Environment Preparation ==

=== Prerequisites ===

You must have the following installed:
* Mercurial - 1.3 or greater
* Python 2.4.4, 2.5.x, 2.6.x (untested on 3.0)

=== Mac Specifics ===

'''Note:''' Snow Leopard upgrades require a reinstall of XCode, in this case to accommodate gcc (and greenlet).

'''Setuptools''' and '''easy_install''' are Python standard means for installing modules. For more info, start here: http://pypi.python.org/pypi/setuptools.

'''Virtualenv''' is a method which allows you to create isolated Python environments, separate from your base install if you so prefer. For more, see here: http://pypi.python.org/pypi/virtualenv.

Your distribution may have Python's '''setuptools''' and '''virtualenv''' packages in its package repository. If so, it is probably best to use your normal package installation procedures (see below for information on specific Linux distributions). If the packages are not available then follow these generic instructions.

=== Generic *nix Specifics ===

In order to install Python Packages and creating a development sandbox you have to do the following:

=== easy_install ===

"Easy Install is a python module (easy_install) bundled with setuptools that lets you automatically download, build, install, and manage Python packages." I stole that from here: http://peak.telecommunity.com/DevCenter/EasyInstall.

Download ez_setup.py and run it with your Python interpreter. You can find it here: http://peak.telecommunity.com/dist/ez_setup.py

Eventually you have to be root to do this depending on your system (mostly non-windows). It should look like this on a unix based machine:

wget http://peak.telecommunity.com/dist/ez_setup.py
-or-
curl -O http://peak.telecommunity.com/dist/ez_setup.py
sudo python ez_setup.py

==== virtualenv ====

Virtualenv builds isolated python environments. To learn more, read this: http://pypi.python.org/pypi/virtualenv.

To use a dedicated python installation in your host, isolated from your system python install, install virtualenv like this:

easy_install virtualenv

Or, if you need to be root something like this:

sudo easy_install virtualenv

On windows, you may need a different path to easy_install

c:\Python25\Scripts\easy_install.exe virtualenv

== Install methods ==

Python modules can be installed in a variety of ways... we're encouraging the virtualenv and setup.py method.

=== buildout ===

Buildout has a variety of uses, in PyOGP's case it is used as a development sandbox. Buildout will checkout all the necessary PyOGP repositories and their dependencies, and configure everything automatically (set up the right path members and install scripts). Once the sandbox is set up, you can make changes to the libs in the parts/ directory (they are actually local mercurial repositories), update the code referenced in buildout (re-run bin/buildout), and test your changes.

It's really easy to work with...

1. First check out the buildout into a directory of your choice:

hg clone http://bitbucket.org/enus_linden/pyogp.buildout (or grab pyogp.buildout-maint to work with maintenance repos)

2. Now turn this checkout into a virtual python environment, independent of your normal Python installation:

cd pyogp.buildout
virtualenv . --no-site-packages

on windows, you may need to specify the path

c:\Python25\Scripts\virtualenv.exe . --no-site-packages

3. Now run the bootstrap.py file with the newly created local Python interpreter:

bin/python bootstrap.py

or on Windows:

Scripts\python bootstrap.py

4. This creates a bunch of directories and the bin/buildout script (bin\buildout.exe on windows). We now run this:

bin/buildout -v

or on Windows:

bin\buildout.exe -v

5. The development sandbox is ready. There now is a bin/pyogp_interpreter, a python interpreter which contains all the installed packages and the pyogp libraries and dependencies referenced in the path.

6. Test the buildout installation. To test this installation you can (at least at this stage of the project) try the following sample script or run the unittests:

bin/region_connect <firstname> <lastname>

-or-

bin/unittests --where=parts/pyogp.lib.base (or pyogp.lib.client)

Enter the avatar's password when prompted, and you're on your way to aditi, the Beta Grid.

=== setup.py ===

If you prefer to not use buildout, and to do things a bit more manually, well, you probably don't need much help here then do you? ;)

Grab the source for each of the pyogp repos, and install them to a virtualenv instance (see above for installing virtualenv if you don't have it)..

Here's a simple setup that Enus likes:
cd ~
mkdir sandbox
cd sandbox
virtualenv . --no-site-packages
cd ~
mkdir hg
cd hg
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.apps/
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.base/
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.client/
cd ~/hg/pyogp.lib.base
~/sandbox/bin/python setup.py install
cd ~/hg/pyogp.lib.client
~/sandbox/bin/python setup.py install
cd ~/hg/pyogp.apps
~/sandbox/bin/python setup.py install
......
now, in ~/sandbox/bin/ you'll have all kinds of pyogp executables for testing stuff out (like region_connect, etc)

You now have all the source, plus a sandbox, for tinkering with pyogp!

To try an executable out, just run it in ~/sandbox/bin/. for example:
~/sandbox/bin/region_connect firstname lastname
This command will login in your agent to aditi, and will prompt you for a password.

Pass any script the "-h" param to get it's usage.

== Run the tests ==

See [[PyOGP_Package_Unittests]] for details...

[[Category: Pyogp_Client_Lib]]

PyOGP Client Library Development Sandbox

2010-06-25T17:22:18Z

Enus Linden: /* Note */

{{PyOGP/navigation}}
We will first run down the general explanation and add platform specific notes later.

== Repositories ==

Stable trunk repositories:
* http://bitbucket.org/enus_linden/pyogp.apps/
* http://bitbucket.org/enus_linden/pyogp.lib.base/
* http://bitbucket.org/enus_linden/pyogp.lib.client/
* http://bitbucket.org/enus_linden/pyogp.buildout/

Maintenance repositories:
* http://bitbucket.org/enus_linden/pyogp.apps-maint/
* http://bitbucket.org/enus_linden/pyogp.lib.base-maint/
* http://bitbucket.org/enus_linden/pyogp.lib.client-maint/
* http://bitbucket.org/enus_linden/pyogp.buildout-maint/

Defunct until someone picks them up and fixes them:
* http://bitbucket.org/enus_linden/pyogp.interop/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/

== Browse the Code ==

If all you want to do is glance at the source code, use the bitbucket source browser:
* http://bitbucket.org/enus_linden/pyogp.apps/src/
* http://bitbucket.org/enus_linden/pyogp.buildout/src/
* http://bitbucket.org/enus_linden/pyogp.interop/src/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/src/
* http://bitbucket.org/enus_linden/pyogp.lib.base/src/
* http://bitbucket.org/enus_linden/pyogp.lib.client/src/

== Prerequisites ==

You must have the following installed:
* Mercurial - 1.3 or greater
* Python 2.4.4, 2.5.x, 2.6.x (untested on 3.0)

'''Note:''' Snow Leopard upgrades require a reinstall of XCode, in this case to accommodate gcc (and greenlet).

== Environment Preparation ==

'''Setuptools''' and '''easy_install''' are Python standard means for installing modules. For more info, start here: http://pypi.python.org/pypi/setuptools.

'''Virtualenv''' is a method which allows you to create isolated Python environments, separate from your base install if you so prefer. For more, see here: http://pypi.python.org/pypi/virtualenv.

Your distribution may have Python's '''setuptools''' and '''virtualenv''' packages in its package repository. If so, it is probably best to use your normal package installation procedures (see below for information on specific Linux distributions). If the packages are not available then follow these generic instructions.

=== Generic *nix distribution ===
In order to install Python Packages and creating a development sandbox you have to do the following:

==== easy_install ====

Download ez_setup.py and run it with your Python interpreter. You can find it here: http://peak.telecommunity.com/dist/ez_setup.py

Eventually you have to be root to do this depending on your system (mostly non-windows). It should look like this on a unix based machine:

wget http://peak.telecommunity.com/dist/ez_setup.py
-or-
curl -O http://peak.telecommunity.com/dist/ez_setup.py
sudo python ez_setup.py

==== virtualenv ====

One may choose to create an isolated python instance on your host, to be able to work with PyOGP without installing packages to your base Python install on your host.

To use a dedicated python installation in your host, install virtualenv like this:

easy_install virtualenv

Or, if you need to be root something like this:

sudo easy_install virtualenv

On windows, you may need a different path to easy_install

c:\Python25\Scripts\easy_install.exe virtualenv


=== setup.py ===

Grab the source files for each of the pyogp repos, and install them to a virtualenv instance (see above for installing virtualenv if you don't have it)..

Here's a simple setup that Enus likes:
cd ~
mkdir sandbox
cd sandbox
virtualenv . --no-site-packages
cd ~
mkdir hg
cd hg
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.apps/
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.base/
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.client/
cd ~/hg/pyogp.lib.base
~/sandbox/bin/python setup.py install
cd ~/hg/pyogp.lib.client
~/sandbox/bin/python setup.py install
cd ~/hg/pyogp.apps
~/sandbox/bin/python setup.py install
......
now, in ~/sandbox/bin/ you'll have all kinds of pyogp executables for testing stuff out (like region_connect, etc)

You now have all the source, plus a sandbox, for tinkering with pyogp!

To try an executable out, just run it in ~/sandbox/bin/. for example:
~/sandbox/bin/region_connect firstname lastname
This command will login in your agent to aditi, and will prompt you for a password.

Pass any script the "-h" param to get it's usage.

== Run the tests ==

See [[PyOGP_Package_Unittests]] for details...

== The structure of the sandbox ==

You now might wonder what all those directories are good for. To learn more about this check out the [[Pyogp/Filesystem_Structure|Filesystem Structure]]

[[Category: Pyogp_Client_Lib]]

PyOGP Client Library Development Sandbox

2010-06-25T16:52:08Z

Enus Linden:

{{PyOGP/navigation}}
We will first run down the general explanation and add platform specific notes later.

== Note ==

We're migrating to [[Mercurial_repositories|Mercurial]]... Please check back soon for updated docs.

PyOGP package install instructions need some work... stay tuned. Feel free to follow the buildout directions to use the Subversion repositories for now.

=== Repositories ===

Stable trunk repositories:
* http://bitbucket.org/enus_linden/pyogp.apps/
* http://bitbucket.org/enus_linden/pyogp.lib.base/
* http://bitbucket.org/enus_linden/pyogp.lib.client/
* http://bitbucket.org/enus_linden/pyogp.buildout/

Maintenance repositories:
* http://bitbucket.org/enus_linden/pyogp.apps-maint/
* http://bitbucket.org/enus_linden/pyogp.lib.base-maint/
* http://bitbucket.org/enus_linden/pyogp.lib.client-maint/
* http://bitbucket.org/enus_linden/pyogp.buildout-maint/

Defunct until someone picks them up and fixes them:
* http://bitbucket.org/enus_linden/pyogp.interop/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/

== Browse the Code ==

If all you want to do is glance at the source code, use the bitbucket source browser:
* http://bitbucket.org/enus_linden/pyogp.apps/src/
* http://bitbucket.org/enus_linden/pyogp.buildout/src/
* http://bitbucket.org/enus_linden/pyogp.interop/src/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/src/
* http://bitbucket.org/enus_linden/pyogp.lib.base/src/
* http://bitbucket.org/enus_linden/pyogp.lib.client/src/

== Prerequisites ==

You must have the following installed:
* Mercurial - 1.3 or greater
* Python 2.4.4, 2.5.x, 2.6.x (untested on 3.0)

'''Note:''' Snow Leopard upgrades require a reinstall of XCode, in this case to accommodate gcc (and greenlet).

== Environment Preparation ==

'''Setuptools''' and '''easy_install''' are Python standard means for installing modules. For more info, start here: http://pypi.python.org/pypi/setuptools.

'''Virtualenv''' is a method which allows you to create isolated Python environments, separate from your base install if you so prefer. For more, see here: http://pypi.python.org/pypi/virtualenv.

Your distribution may have Python's '''setuptools''' and '''virtualenv''' packages in its package repository. If so, it is probably best to use your normal package installation procedures (see below for information on specific Linux distributions). If the packages are not available then follow these generic instructions.

=== Generic *nix distribution ===
In order to install Python Packages and creating a development sandbox you have to do the following:

==== easy_install ====

Download ez_setup.py and run it with your Python interpreter. You can find it here: http://peak.telecommunity.com/dist/ez_setup.py

Eventually you have to be root to do this depending on your system (mostly non-windows). It should look like this on a unix based machine:

wget http://peak.telecommunity.com/dist/ez_setup.py
-or-
curl -O http://peak.telecommunity.com/dist/ez_setup.py
sudo python ez_setup.py

==== virtualenv ====

One may choose to create an isolated python instance on your host, to be able to work with PyOGP without installing packages to your base Python install on your host.

To use a dedicated python installation in your host, install virtualenv like this:

easy_install virtualenv

Or, if you need to be root something like this:

sudo easy_install virtualenv

On windows, you may need a different path to easy_install

c:\Python25\Scripts\easy_install.exe virtualenv


=== setup.py ===

Grab the source files for each of the pyogp repos, and install them to a virtualenv instance (see above for installing virtualenv if you don't have it)..

Here's a simple setup that Enus likes:
cd ~
mkdir sandbox
cd sandbox
virtualenv . --no-site-packages
cd ~
mkdir hg
cd hg
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.apps/
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.base/
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.client/
cd ~/hg/pyogp.lib.base
~/sandbox/bin/python setup.py install
cd ~/hg/pyogp.lib.client
~/sandbox/bin/python setup.py install
cd ~/hg/pyogp.apps
~/sandbox/bin/python setup.py install
......
now, in ~/sandbox/bin/ you'll have all kinds of pyogp executables for testing stuff out (like region_connect, etc)

You now have all the source, plus a sandbox, for tinkering with pyogp!

To try an executable out, just run it in ~/sandbox/bin/. for example:
~/sandbox/bin/region_connect firstname lastname
This command will login in your agent to aditi, and will prompt you for a password.

Pass any script the "-h" param to get it's usage.

== Run the tests ==

See [[PyOGP_Package_Unittests]] for details...

== The structure of the sandbox ==

You now might wonder what all those directories are good for. To learn more about this check out the [[Pyogp/Filesystem_Structure|Filesystem Structure]]

[[Category: Pyogp_Client_Lib]]

PyOGP Client Library Development Sandbox

2010-06-24T21:46:08Z

Enus Linden: /* Run the tests */

{{PyOGP/navigation}}
We will first run down the general explanation and add platform specific notes later.

== Note ==

We're migrating to [[Mercurial_repositories|Mercurial]]... Please check back soon for updated docs.

PyOGP package install instructions need some work... stay tuned. Feel free to follow the buildout directions to use the Subversion repositories for now.

=== Repositories ===

Need some work before they are ready as installed packages. In the meantime, just add the path to "pyogp.{package}" to your PYTHONPATH to use the libs, assuming you have the other dependencies.
* http://bitbucket.org/enus_linden/pyogp.apps/
* http://bitbucket.org/enus_linden/pyogp.lib.base/
* http://bitbucket.org/enus_linden/pyogp.lib.client/

Needs updates to work:
* http://bitbucket.org/enus_linden/pyogp.buildout/

Defunct until someone picks them up and fixes them:
* http://bitbucket.org/enus_linden/pyogp.interop/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/

== Browse the Code ==

If all you want to do is glance at the source code, use the bitbucket source browser:
* http://bitbucket.org/enus_linden/pyogp.apps/src/
* http://bitbucket.org/enus_linden/pyogp.buildout/src/
* http://bitbucket.org/enus_linden/pyogp.interop/src/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/src/
* http://bitbucket.org/enus_linden/pyogp.lib.base/src/
* http://bitbucket.org/enus_linden/pyogp.lib.client/src/

== Prerequisites ==

You must have the following installed:
* Mercurial - 1.3 or greater
* Python 2.4.4, 2.5.x, 2.6.x (untested on 3.0)

'''Note:''' Snow Leopard upgrades require a reinstall of XCode, in this case to accommodate gcc (and greenlet).

== Environment Preparation ==

'''Setuptools''' and '''easy_install''' are Python standard means for installing modules. For more info, start here: http://pypi.python.org/pypi/setuptools.

'''Virtualenv''' is a method which allows you to create isolated Python environments, separate from your base install if you so prefer. For more, see here: http://pypi.python.org/pypi/virtualenv.

Your distribution may have Python's '''setuptools''' and '''virtualenv''' packages in its package repository. If so, it is probably best to use your normal package installation procedures (see below for information on specific Linux distributions). If the packages are not available then follow these generic instructions.

=== Generic *nix distribution ===
In order to install Python Packages and creating a development sandbox you have to do the following:

==== easy_install ====

Download ez_setup.py and run it with your Python interpreter. You can find it here: http://peak.telecommunity.com/dist/ez_setup.py

Eventually you have to be root to do this depending on your system (mostly non-windows). It should look like this on a unix based machine:

wget http://peak.telecommunity.com/dist/ez_setup.py
-or-
curl -O http://peak.telecommunity.com/dist/ez_setup.py
sudo python ez_setup.py

==== virtualenv ====

One may choose to create an isolated python instance on your host, to be able to work with PyOGP without installing packages to your base Python install on your host.

To use a dedicated python installation in your host, install virtualenv like this:

easy_install virtualenv

Or, if you need to be root something like this:

sudo easy_install virtualenv

On windows, you may need a different path to easy_install

c:\Python25\Scripts\easy_install.exe virtualenv


=== setup.py ===

Grab the source files for each of the pyogp repos, and install them to a virtualenv instance (see above for installing virtualenv if you don't have it)..

Here's a simple setup that Enus likes:
cd ~
mkdir sandbox
cd sandbox
virtualenv . --no-site-packages
cd ~
mkdir hg
cd hg
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.apps/
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.base/
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.client/
cd ~/hg/pyogp.lib.base
~/sandbox/bin/python setup.py install
cd ~/hg/pyogp.lib.client
~/sandbox/bin/python setup.py install
cd ~/hg/pyogp.apps
~/sandbox/bin/python setup.py install
......
now, in ~/sandbox/bin/ you'll have all kinds of pyogp executables for testing stuff out (like region_connect, etc)

You now have all the source, plus a sandbox, for tinkering with pyogp!

To try an executable out, just run it in ~/sandbox/bin/. for example:
~/sandbox/bin/region_connect firstname lastname
This command will login in your agent to aditi, and will prompt you for a password.

Pass any script the "-h" param to get it's usage.

== Run the tests ==

See [[PyOGP_Package_Unittests]] for details...

== The structure of the sandbox ==

You now might wonder what all those directories are good for. To learn more about this check out the [[Pyogp/Filesystem_Structure|Filesystem Structure]]

[[Category: Pyogp_Client_Lib]]

PyOGP Client Library Development Sandbox

2010-06-24T21:41:11Z

Enus Linden: /* Prerequisites */

{{PyOGP/navigation}}
We will first run down the general explanation and add platform specific notes later.

== Note ==

We're migrating to [[Mercurial_repositories|Mercurial]]... Please check back soon for updated docs.

PyOGP package install instructions need some work... stay tuned. Feel free to follow the buildout directions to use the Subversion repositories for now.

=== Repositories ===

Need some work before they are ready as installed packages. In the meantime, just add the path to "pyogp.{package}" to your PYTHONPATH to use the libs, assuming you have the other dependencies.
* http://bitbucket.org/enus_linden/pyogp.apps/
* http://bitbucket.org/enus_linden/pyogp.lib.base/
* http://bitbucket.org/enus_linden/pyogp.lib.client/

Needs updates to work:
* http://bitbucket.org/enus_linden/pyogp.buildout/

Defunct until someone picks them up and fixes them:
* http://bitbucket.org/enus_linden/pyogp.interop/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/

== Browse the Code ==

If all you want to do is glance at the source code, use the bitbucket source browser:
* http://bitbucket.org/enus_linden/pyogp.apps/src/
* http://bitbucket.org/enus_linden/pyogp.buildout/src/
* http://bitbucket.org/enus_linden/pyogp.interop/src/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/src/
* http://bitbucket.org/enus_linden/pyogp.lib.base/src/
* http://bitbucket.org/enus_linden/pyogp.lib.client/src/

== Prerequisites ==

You must have the following installed:
* Mercurial - 1.3 or greater
* Python 2.4.4, 2.5.x, 2.6.x (untested on 3.0)

'''Note:''' Snow Leopard upgrades require a reinstall of XCode, in this case to accommodate gcc (and greenlet).

== Environment Preparation ==

'''Setuptools''' and '''easy_install''' are Python standard means for installing modules. For more info, start here: http://pypi.python.org/pypi/setuptools.

'''Virtualenv''' is a method which allows you to create isolated Python environments, separate from your base install if you so prefer. For more, see here: http://pypi.python.org/pypi/virtualenv.

Your distribution may have Python's '''setuptools''' and '''virtualenv''' packages in its package repository. If so, it is probably best to use your normal package installation procedures (see below for information on specific Linux distributions). If the packages are not available then follow these generic instructions.

=== Generic *nix distribution ===
In order to install Python Packages and creating a development sandbox you have to do the following:

==== easy_install ====

Download ez_setup.py and run it with your Python interpreter. You can find it here: http://peak.telecommunity.com/dist/ez_setup.py

Eventually you have to be root to do this depending on your system (mostly non-windows). It should look like this on a unix based machine:

wget http://peak.telecommunity.com/dist/ez_setup.py
-or-
curl -O http://peak.telecommunity.com/dist/ez_setup.py
sudo python ez_setup.py

==== virtualenv ====

One may choose to create an isolated python instance on your host, to be able to work with PyOGP without installing packages to your base Python install on your host.

To use a dedicated python installation in your host, install virtualenv like this:

easy_install virtualenv

Or, if you need to be root something like this:

sudo easy_install virtualenv

On windows, you may need a different path to easy_install

c:\Python25\Scripts\easy_install.exe virtualenv


=== setup.py ===

Grab the source files for each of the pyogp repos, and install them to a virtualenv instance (see above for installing virtualenv if you don't have it)..

Here's a simple setup that Enus likes:
cd ~
mkdir sandbox
cd sandbox
virtualenv . --no-site-packages
cd ~
mkdir hg
cd hg
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.apps/
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.base/
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.client/
cd ~/hg/pyogp.lib.base
~/sandbox/bin/python setup.py install
cd ~/hg/pyogp.lib.client
~/sandbox/bin/python setup.py install
cd ~/hg/pyogp.apps
~/sandbox/bin/python setup.py install
......
now, in ~/sandbox/bin/ you'll have all kinds of pyogp executables for testing stuff out (like region_connect, etc)

You now have all the source, plus a sandbox, for tinkering with pyogp!

To try an executable out, just run it in ~/sandbox/bin/. for example:
~/sandbox/bin/region_connect firstname lastname
This command will login in your agent to aditi, and will prompt you for a password.

Pass any script the "-h" param to get it's usage.

== Run the tests ==

See [[PyOGP_Client_Library#Pyogp_Unit_Tests]] for details...

== The structure of the sandbox ==

You now might wonder what all those directories are good for. To learn more about this check out the [[Pyogp/Filesystem_Structure|Filesystem Structure]]

[[Category: Pyogp_Client_Lib]]

PyOGP Client Library Development Sandbox

2010-05-03T21:29:17Z

Enus Linden: /* setup.py */

{{PyOGP/navigation}}
We will first run down the general explanation and add platform specific notes later.

== Note ==

We're migrating to [[Mercurial_repositories|Mercurial]]... Please check back soon for updated docs.

PyOGP package install instructions need some work... stay tuned. Feel free to follow the buildout directions to use the Subversion repositories for now.

=== Repositories ===

Need some work before they are ready as installed packages. In the meantime, just add the path to "pyogp.{package}" to your PYTHONPATH to use the libs, assuming you have the other dependencies.
* http://bitbucket.org/enus_linden/pyogp.apps/
* http://bitbucket.org/enus_linden/pyogp.lib.base/
* http://bitbucket.org/enus_linden/pyogp.lib.client/

Needs updates to work:
* http://bitbucket.org/enus_linden/pyogp.buildout/

Defunct until someone picks them up and fixes them:
* http://bitbucket.org/enus_linden/pyogp.interop/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/

== Browse the Code ==

If all you want to do is glance at the source code, use the bitbucket source browser:
* http://bitbucket.org/enus_linden/pyogp.apps/src/
* http://bitbucket.org/enus_linden/pyogp.buildout/src/
* http://bitbucket.org/enus_linden/pyogp.interop/src/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/src/
* http://bitbucket.org/enus_linden/pyogp.lib.base/src/
* http://bitbucket.org/enus_linden/pyogp.lib.client/src/

== Prerequisites ==

You must have the following installed:
* Mercurial - 1.3 or greater
* Python 2.4.4, 2.5.x (fails on 2.6 currently and untested on 3.0)

'''Note:''' Snow Leopard upgrades require a reinstall of XCode, in this case to accommodate gcc (and greenlet).

'''Note:''' Buildout does not yet support subversion 1.6, only 1.4.4-1.5.x.

== Environment Preparation ==

'''Setuptools''' and '''easy_install''' are Python standard means for installing modules. For more info, start here: http://pypi.python.org/pypi/setuptools.

'''Virtualenv''' is a method which allows you to create isolated Python environments, separate from your base install if you so prefer. For more, see here: http://pypi.python.org/pypi/virtualenv.

Your distribution may have Python's '''setuptools''' and '''virtualenv''' packages in its package repository. If so, it is probably best to use your normal package installation procedures (see below for information on specific Linux distributions). If the packages are not available then follow these generic instructions.

=== Generic *nix distribution ===
In order to install Python Packages and creating a development sandbox you have to do the following:

==== easy_install ====

Download ez_setup.py and run it with your Python interpreter. You can find it here: http://peak.telecommunity.com/dist/ez_setup.py

Eventually you have to be root to do this depending on your system (mostly non-windows). It should look like this on a unix based machine:

wget http://peak.telecommunity.com/dist/ez_setup.py
-or-
curl -O http://peak.telecommunity.com/dist/ez_setup.py
sudo python ez_setup.py

==== virtualenv ====

One may choose to create an isolated python instance on your host, to be able to work with PyOGP without installing packages to your base Python install on your host.

To use a dedicated python installation in your host, install virtualenv like this:

easy_install virtualenv

Or, if you need to be root something like this:

sudo easy_install virtualenv

On windows, you may need a different path to easy_install

c:\Python25\Scripts\easy_install.exe virtualenv


=== setup.py ===

Grab the source files for each of the pyogp repos, and install them to a virtualenv instance (see above for installing virtualenv if you don't have it)..

Here's a simple setup that Enus likes:
cd ~
mkdir sandbox
cd sandbox
virtualenv . --no-site-packages
cd ~
mkdir hg
cd hg
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.apps/
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.base/
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.client/
cd ~/hg/pyogp.lib.base
~/sandbox/bin/python setup.py install
cd ~/hg/pyogp.lib.client
~/sandbox/bin/python setup.py install
cd ~/hg/pyogp.apps
~/sandbox/bin/python setup.py install
......
now, in ~/sandbox/bin/ you'll have all kinds of pyogp executables for testing stuff out (like region_connect, etc)

You now have all the source, plus a sandbox, for tinkering with pyogp!

To try an executable out, just run it in ~/sandbox/bin/. for example:
~/sandbox/bin/region_connect firstname lastname
This command will login in your agent to aditi, and will prompt you for a password.

Pass any script the "-h" param to get it's usage.

== Run the tests ==

See [[PyOGP_Client_Library#Pyogp_Unit_Tests]] for details...

== The structure of the sandbox ==

You now might wonder what all those directories are good for. To learn more about this check out the [[Pyogp/Filesystem_Structure|Filesystem Structure]]

[[Category: Pyogp_Client_Lib]]

PyOGP Client Library Development Sandbox

2010-05-03T21:27:14Z

Enus Linden: /* setup.py */

{{PyOGP/navigation}}
We will first run down the general explanation and add platform specific notes later.

== Note ==

We're migrating to [[Mercurial_repositories|Mercurial]]... Please check back soon for updated docs.

PyOGP package install instructions need some work... stay tuned. Feel free to follow the buildout directions to use the Subversion repositories for now.

=== Repositories ===

Need some work before they are ready as installed packages. In the meantime, just add the path to "pyogp.{package}" to your PYTHONPATH to use the libs, assuming you have the other dependencies.
* http://bitbucket.org/enus_linden/pyogp.apps/
* http://bitbucket.org/enus_linden/pyogp.lib.base/
* http://bitbucket.org/enus_linden/pyogp.lib.client/

Needs updates to work:
* http://bitbucket.org/enus_linden/pyogp.buildout/

Defunct until someone picks them up and fixes them:
* http://bitbucket.org/enus_linden/pyogp.interop/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/

== Browse the Code ==

If all you want to do is glance at the source code, use the bitbucket source browser:
* http://bitbucket.org/enus_linden/pyogp.apps/src/
* http://bitbucket.org/enus_linden/pyogp.buildout/src/
* http://bitbucket.org/enus_linden/pyogp.interop/src/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/src/
* http://bitbucket.org/enus_linden/pyogp.lib.base/src/
* http://bitbucket.org/enus_linden/pyogp.lib.client/src/

== Prerequisites ==

You must have the following installed:
* Mercurial - 1.3 or greater
* Python 2.4.4, 2.5.x (fails on 2.6 currently and untested on 3.0)

'''Note:''' Snow Leopard upgrades require a reinstall of XCode, in this case to accommodate gcc (and greenlet).

'''Note:''' Buildout does not yet support subversion 1.6, only 1.4.4-1.5.x.

== Environment Preparation ==

'''Setuptools''' and '''easy_install''' are Python standard means for installing modules. For more info, start here: http://pypi.python.org/pypi/setuptools.

'''Virtualenv''' is a method which allows you to create isolated Python environments, separate from your base install if you so prefer. For more, see here: http://pypi.python.org/pypi/virtualenv.

Your distribution may have Python's '''setuptools''' and '''virtualenv''' packages in its package repository. If so, it is probably best to use your normal package installation procedures (see below for information on specific Linux distributions). If the packages are not available then follow these generic instructions.

=== Generic *nix distribution ===
In order to install Python Packages and creating a development sandbox you have to do the following:

==== easy_install ====

Download ez_setup.py and run it with your Python interpreter. You can find it here: http://peak.telecommunity.com/dist/ez_setup.py

Eventually you have to be root to do this depending on your system (mostly non-windows). It should look like this on a unix based machine:

wget http://peak.telecommunity.com/dist/ez_setup.py
-or-
curl -O http://peak.telecommunity.com/dist/ez_setup.py
sudo python ez_setup.py

==== virtualenv ====

One may choose to create an isolated python instance on your host, to be able to work with PyOGP without installing packages to your base Python install on your host.

To use a dedicated python installation in your host, install virtualenv like this:

easy_install virtualenv

Or, if you need to be root something like this:

sudo easy_install virtualenv

On windows, you may need a different path to easy_install

c:\Python25\Scripts\easy_install.exe virtualenv


=== setup.py ===

Grab the source files for each of the pyogp repos, and install them to a virtualenv instance (see above for installing virtualenv if you don't have it)..

Here's a simple setup that Enus likes:
cd ~
mkdir sandbox
cd sandbox
virtualenv . --no-site-packages
cd ~
mkdir hg
cd hg
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.apps/
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.base/
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.client/
cd ~/hg/pyogp.lib.base
~/sandbox/bin/python setup.py install
cd ~/hg/pyogp.lib.client
~/sandbox/bin/python setup.py install
cd ~/hg/pyogp.apps
~/sandbox/bin/python setup.py install
......
now, in ~/sandbox/bin/you'll have all kinds of pyogp executables for testing stuff out.

You now have all the source, plus a sandbox, for tinkering with pyogp!

== Run the tests ==

See [[PyOGP_Client_Library#Pyogp_Unit_Tests]] for details...

== The structure of the sandbox ==

You now might wonder what all those directories are good for. To learn more about this check out the [[Pyogp/Filesystem_Structure|Filesystem Structure]]

[[Category: Pyogp_Client_Lib]]

PyOGP Client Library Development Sandbox

2010-05-03T21:26:27Z

Enus Linden: /* setup.py */

{{PyOGP/navigation}}
We will first run down the general explanation and add platform specific notes later.

== Note ==

We're migrating to [[Mercurial_repositories|Mercurial]]... Please check back soon for updated docs.

PyOGP package install instructions need some work... stay tuned. Feel free to follow the buildout directions to use the Subversion repositories for now.

=== Repositories ===

Need some work before they are ready as installed packages. In the meantime, just add the path to "pyogp.{package}" to your PYTHONPATH to use the libs, assuming you have the other dependencies.
* http://bitbucket.org/enus_linden/pyogp.apps/
* http://bitbucket.org/enus_linden/pyogp.lib.base/
* http://bitbucket.org/enus_linden/pyogp.lib.client/

Needs updates to work:
* http://bitbucket.org/enus_linden/pyogp.buildout/

Defunct until someone picks them up and fixes them:
* http://bitbucket.org/enus_linden/pyogp.interop/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/

== Browse the Code ==

If all you want to do is glance at the source code, use the bitbucket source browser:
* http://bitbucket.org/enus_linden/pyogp.apps/src/
* http://bitbucket.org/enus_linden/pyogp.buildout/src/
* http://bitbucket.org/enus_linden/pyogp.interop/src/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/src/
* http://bitbucket.org/enus_linden/pyogp.lib.base/src/
* http://bitbucket.org/enus_linden/pyogp.lib.client/src/

== Prerequisites ==

You must have the following installed:
* Mercurial - 1.3 or greater
* Python 2.4.4, 2.5.x (fails on 2.6 currently and untested on 3.0)

'''Note:''' Snow Leopard upgrades require a reinstall of XCode, in this case to accommodate gcc (and greenlet).

'''Note:''' Buildout does not yet support subversion 1.6, only 1.4.4-1.5.x.

== Environment Preparation ==

'''Setuptools''' and '''easy_install''' are Python standard means for installing modules. For more info, start here: http://pypi.python.org/pypi/setuptools.

'''Virtualenv''' is a method which allows you to create isolated Python environments, separate from your base install if you so prefer. For more, see here: http://pypi.python.org/pypi/virtualenv.

Your distribution may have Python's '''setuptools''' and '''virtualenv''' packages in its package repository. If so, it is probably best to use your normal package installation procedures (see below for information on specific Linux distributions). If the packages are not available then follow these generic instructions.

=== Generic *nix distribution ===
In order to install Python Packages and creating a development sandbox you have to do the following:

==== easy_install ====

Download ez_setup.py and run it with your Python interpreter. You can find it here: http://peak.telecommunity.com/dist/ez_setup.py

Eventually you have to be root to do this depending on your system (mostly non-windows). It should look like this on a unix based machine:

wget http://peak.telecommunity.com/dist/ez_setup.py
-or-
curl -O http://peak.telecommunity.com/dist/ez_setup.py
sudo python ez_setup.py

==== virtualenv ====

One may choose to create an isolated python instance on your host, to be able to work with PyOGP without installing packages to your base Python install on your host.

To use a dedicated python installation in your host, install virtualenv like this:

easy_install virtualenv

Or, if you need to be root something like this:

sudo easy_install virtualenv

On windows, you may need a different path to easy_install

c:\Python25\Scripts\easy_install.exe virtualenv


=== setup.py ===

Grab the source files for each of the pyogp repos, and install them to a virtualenv instance (see above for installing virtualenv if you don't have it)..

Here's a simple setup that Enus likes:
cd ~
mkdir sandbox
cd sandbox
virtualenv . --no-site-packages
cd ~
mkdir hg
cd hg
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.apps/
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.base/
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.client/
cd ~/hg/pyogp.lib.base
~/sandbox/bin/python setup.py install
cd ~/hg/pyogp.lib.client
~/sandbox/bin/python setup.py install
cd ~/hg/pyogp.apps
~/sandbox/bin/python setup.py install

You now have all the source, plus a sandbox, for tinkering with pyogp!

== Run the tests ==

See [[PyOGP_Client_Library#Pyogp_Unit_Tests]] for details...

== The structure of the sandbox ==

You now might wonder what all those directories are good for. To learn more about this check out the [[Pyogp/Filesystem_Structure|Filesystem Structure]]

[[Category: Pyogp_Client_Lib]]

PyOGP Client Library Development Sandbox

2010-05-03T21:20:52Z

Enus Linden: /* easy_install */

{{PyOGP/navigation}}
We will first run down the general explanation and add platform specific notes later.

== Note ==

We're migrating to [[Mercurial_repositories|Mercurial]]... Please check back soon for updated docs.

PyOGP package install instructions need some work... stay tuned. Feel free to follow the buildout directions to use the Subversion repositories for now.

=== Repositories ===

Need some work before they are ready as installed packages. In the meantime, just add the path to "pyogp.{package}" to your PYTHONPATH to use the libs, assuming you have the other dependencies.
* http://bitbucket.org/enus_linden/pyogp.apps/
* http://bitbucket.org/enus_linden/pyogp.lib.base/
* http://bitbucket.org/enus_linden/pyogp.lib.client/

Needs updates to work:
* http://bitbucket.org/enus_linden/pyogp.buildout/

Defunct until someone picks them up and fixes them:
* http://bitbucket.org/enus_linden/pyogp.interop/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/

== Browse the Code ==

If all you want to do is glance at the source code, use the bitbucket source browser:
* http://bitbucket.org/enus_linden/pyogp.apps/src/
* http://bitbucket.org/enus_linden/pyogp.buildout/src/
* http://bitbucket.org/enus_linden/pyogp.interop/src/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/src/
* http://bitbucket.org/enus_linden/pyogp.lib.base/src/
* http://bitbucket.org/enus_linden/pyogp.lib.client/src/

== Prerequisites ==

You must have the following installed:
* Mercurial - 1.3 or greater
* Python 2.4.4, 2.5.x (fails on 2.6 currently and untested on 3.0)

'''Note:''' Snow Leopard upgrades require a reinstall of XCode, in this case to accommodate gcc (and greenlet).

'''Note:''' Buildout does not yet support subversion 1.6, only 1.4.4-1.5.x.

== Environment Preparation ==

'''Setuptools''' and '''easy_install''' are Python standard means for installing modules. For more info, start here: http://pypi.python.org/pypi/setuptools.

'''Virtualenv''' is a method which allows you to create isolated Python environments, separate from your base install if you so prefer. For more, see here: http://pypi.python.org/pypi/virtualenv.

Your distribution may have Python's '''setuptools''' and '''virtualenv''' packages in its package repository. If so, it is probably best to use your normal package installation procedures (see below for information on specific Linux distributions). If the packages are not available then follow these generic instructions.

=== Generic *nix distribution ===
In order to install Python Packages and creating a development sandbox you have to do the following:

==== easy_install ====

Download ez_setup.py and run it with your Python interpreter. You can find it here: http://peak.telecommunity.com/dist/ez_setup.py

Eventually you have to be root to do this depending on your system (mostly non-windows). It should look like this on a unix based machine:

wget http://peak.telecommunity.com/dist/ez_setup.py
-or-
curl -O http://peak.telecommunity.com/dist/ez_setup.py
sudo python ez_setup.py

==== virtualenv ====

One may choose to create an isolated python instance on your host, to be able to work with PyOGP without installing packages to your base Python install on your host.

To use a dedicated python installation in your host, install virtualenv like this:

easy_install virtualenv

Or, if you need to be root something like this:

sudo easy_install virtualenv

On windows, you may need a different path to easy_install

c:\Python25\Scripts\easy_install.exe virtualenv


=== setup.py ===

Grab the source files for each of the pyogp repos, and install them to a virtualenv instance (see above for installing virtualenv if you don't have it)..

Here's a simple setup that Enus likes:
cd ~
mkdir sandbox
cd sandbox
virtualenv . --no-site-packages
cd ~
mkdir hg
cd hg
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.apps/
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.base/
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.client/
cd pyogp.lib.base
~/sandbox/bin/python setup.py install
cd pyogp.lib.client
~/sandbox/bin/python setup.py install
cd pyogp.apps
~/sandbox/bin/python setup.py install

You now have all the source, plus a sandbox, for tinkering with pyogp!

== Run the tests ==

See [[PyOGP_Client_Library#Pyogp_Unit_Tests]] for details...

== The structure of the sandbox ==

You now might wonder what all those directories are good for. To learn more about this check out the [[Pyogp/Filesystem_Structure|Filesystem Structure]]

[[Category: Pyogp_Client_Lib]]

PyOGP Client Library Development Sandbox

2010-05-03T21:16:45Z

Enus Linden: /* Environment Preparation */

{{PyOGP/navigation}}
We will first run down the general explanation and add platform specific notes later.

== Note ==

We're migrating to [[Mercurial_repositories|Mercurial]]... Please check back soon for updated docs.

PyOGP package install instructions need some work... stay tuned. Feel free to follow the buildout directions to use the Subversion repositories for now.

=== Repositories ===

Need some work before they are ready as installed packages. In the meantime, just add the path to "pyogp.{package}" to your PYTHONPATH to use the libs, assuming you have the other dependencies.
* http://bitbucket.org/enus_linden/pyogp.apps/
* http://bitbucket.org/enus_linden/pyogp.lib.base/
* http://bitbucket.org/enus_linden/pyogp.lib.client/

Needs updates to work:
* http://bitbucket.org/enus_linden/pyogp.buildout/

Defunct until someone picks them up and fixes them:
* http://bitbucket.org/enus_linden/pyogp.interop/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/

== Browse the Code ==

If all you want to do is glance at the source code, use the bitbucket source browser:
* http://bitbucket.org/enus_linden/pyogp.apps/src/
* http://bitbucket.org/enus_linden/pyogp.buildout/src/
* http://bitbucket.org/enus_linden/pyogp.interop/src/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/src/
* http://bitbucket.org/enus_linden/pyogp.lib.base/src/
* http://bitbucket.org/enus_linden/pyogp.lib.client/src/

== Prerequisites ==

You must have the following installed:
* Mercurial - 1.3 or greater
* Python 2.4.4, 2.5.x (fails on 2.6 currently and untested on 3.0)

'''Note:''' Snow Leopard upgrades require a reinstall of XCode, in this case to accommodate gcc (and greenlet).

'''Note:''' Buildout does not yet support subversion 1.6, only 1.4.4-1.5.x.

== Environment Preparation ==

'''Setuptools''' and '''easy_install''' are Python standard means for installing modules. For more info, start here: http://pypi.python.org/pypi/setuptools.

'''Virtualenv''' is a method which allows you to create isolated Python environments, separate from your base install if you so prefer. For more, see here: http://pypi.python.org/pypi/virtualenv.

Your distribution may have Python's '''setuptools''' and '''virtualenv''' packages in its package repository. If so, it is probably best to use your normal package installation procedures (see below for information on specific Linux distributions). If the packages are not available then follow these generic instructions.

=== Generic *nix distribution ===
In order to install Python Packages and creating a development sandbox you have to do the following:

==== easy_install ====

Download ez_setup.py and run it with your Python interpreter. You can find it here: http://peak.telecommunity.com/dist/ez_setup.py

Eventually you have to be root to do this depending on your system (mostly non-windows). It should look like this on a unix based machine:

wget http://peak.telecommunity.com/dist/ez_setup.py
-or-
curl -O tp://peak.telecommunity.com/dist/ez_setup.py
sudo python ez_setup.py

==== virtualenv ====

One may choose to create an isolated python instance on your host, to be able to work with PyOGP without installing packages to your base Python install on your host.

To use a dedicated python installation in your host, install virtualenv like this:

easy_install virtualenv

Or, if you need to be root something like this:

sudo easy_install virtualenv

On windows, you may need a different path to easy_install

c:\Python25\Scripts\easy_install.exe virtualenv


=== setup.py ===

Grab the source files for each of the pyogp repos, and install them to a virtualenv instance (see above for installing virtualenv if you don't have it)..

Here's a simple setup that Enus likes:
cd ~
mkdir sandbox
cd sandbox
virtualenv . --no-site-packages
cd ~
mkdir hg
cd hg
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.apps/
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.base/
hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.client/
cd pyogp.lib.base
~/sandbox/bin/python setup.py install
cd pyogp.lib.client
~/sandbox/bin/python setup.py install
cd pyogp.apps
~/sandbox/bin/python setup.py install

You now have all the source, plus a sandbox, for tinkering with pyogp!

== Run the tests ==

See [[PyOGP_Client_Library#Pyogp_Unit_Tests]] for details...

== The structure of the sandbox ==

You now might wonder what all those directories are good for. To learn more about this check out the [[Pyogp/Filesystem_Structure|Filesystem Structure]]

[[Category: Pyogp_Client_Lib]]

PyOGP Client Library Development Sandbox

2010-05-03T21:15:43Z

Enus Linden:

{{PyOGP/navigation}}
We will first run down the general explanation and add platform specific notes later.

== Note ==

We're migrating to [[Mercurial_repositories|Mercurial]]... Please check back soon for updated docs.

PyOGP package install instructions need some work... stay tuned. Feel free to follow the buildout directions to use the Subversion repositories for now.

=== Repositories ===

Need some work before they are ready as installed packages. In the meantime, just add the path to "pyogp.{package}" to your PYTHONPATH to use the libs, assuming you have the other dependencies.
* http://bitbucket.org/enus_linden/pyogp.apps/
* http://bitbucket.org/enus_linden/pyogp.lib.base/
* http://bitbucket.org/enus_linden/pyogp.lib.client/

Needs updates to work:
* http://bitbucket.org/enus_linden/pyogp.buildout/

Defunct until someone picks them up and fixes them:
* http://bitbucket.org/enus_linden/pyogp.interop/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/

== Browse the Code ==

If all you want to do is glance at the source code, use the bitbucket source browser:
* http://bitbucket.org/enus_linden/pyogp.apps/src/
* http://bitbucket.org/enus_linden/pyogp.buildout/src/
* http://bitbucket.org/enus_linden/pyogp.interop/src/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/src/
* http://bitbucket.org/enus_linden/pyogp.lib.base/src/
* http://bitbucket.org/enus_linden/pyogp.lib.client/src/

== Prerequisites ==

You must have the following installed:
* Mercurial - 1.3 or greater
* Python 2.4.4, 2.5.x (fails on 2.6 currently and untested on 3.0)

'''Note:''' Snow Leopard upgrades require a reinstall of XCode, in this case to accommodate gcc (and greenlet).

'''Note:''' Buildout does not yet support subversion 1.6, only 1.4.4-1.5.x.

== Environment Preparation ==

'''Setuptools''' and '''easy_install''' are Python standard means for installing modules. For more info, start here: http://pypi.python.org/pypi/setuptools.

'''Virtualenv''' is a method which allows you to create isolated Python environments, separate from your base install if you so prefer. For more, see here: http://pypi.python.org/pypi/virtualenv.

Your distribution may have Python's '''setuptools''' and '''virtualenv''' packages in its package repository. If so, it is probably best to use your normal package installation procedures (see below for information on specific Linux distributions). If the packages are not available then follow these generic instructions.

=== Generic *nix distribution ===
In order to install Python Packages and creating a development sandbox you have to do the following:

==== easy_install ====

Download ez_setup.py and run it with your Python interpreter. You can find it here: http://peak.telecommunity.com/dist/ez_setup.py

Eventually you have to be root to do this depending on your system (mostly non-windows). It should look like this on a unix based machine:

wget http://peak.telecommunity.com/dist/ez_setup.py
-or-
curl -O tp://peak.telecommunity.com/dist/ez_setup.py
sudo python ez_setup.py

==== virtualenv ====

One may choose to create an isolated python instance on your host, to be able to work with PyOGP without installing packages to your base Python install on your host.

To use a dedicated python installation in your host, install virtualenv like this:

easy_install virtualenv

Or, if you need to be root something like this:

sudo easy_install virtualenv

On windows, you may need a different path to easy_install

c:\Python25\Scripts\easy_install.exe virtualenv


=== setup.py ===

Grab the source files for each of the pyogp repos, and install them to a virtualenv instance (see above for installing virtualenv if you don't have it)..

Here's a simple setup that Enus likes:
: cd ~
: mkdir sandbox
: cd sandbox
: virtualenv . --no-site-packages
: cd ~
: mkdir hg
: cd hg
: hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.apps/
: hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.base/
: hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.client/
: cd pyogp.lib.base
: ~/sandbox/bin/python setup.py install
: cd pyogp.lib.client
: ~/sandbox/bin/python setup.py install
: cd pyogp.apps
: ~/sandbox/bin/python setup.py install

You now have all the source, plus a sandbox, for tinkering with pyogp!

== Run the tests ==

See [[PyOGP_Client_Library#Pyogp_Unit_Tests]] for details...

== The structure of the sandbox ==

You now might wonder what all those directories are good for. To learn more about this check out the [[Pyogp/Filesystem_Structure|Filesystem Structure]]

[[Category: Pyogp_Client_Lib]]

User:Enus Linden/Office Hours/Friday

2010-03-05T20:23:44Z

Enus Linden:

{{hCalendar event/Office Hours
|mode={{{mode|}}}
|Resident=Enus Linden
|weekday=Friday
|start=1pm {{SLT}}
|end=2pm {{SLT}}
|location=[http://slurl.com/secondlife/Longfellow/99/97/28 Enus' Clubhouse]
|description='''My Office hours are on sabbatical until further notice, feel free to find me in world otherwise...''' 
Topics:
* Primarily Pyogp
* QA
* Bots
}}

User:Enus Linden/Office Hours/Friday

2010-03-05T20:23:19Z

Enus Linden:

{{hCalendar event/Office Hours
|mode={{{mode|}}}
|Resident=Enus Linden
|weekday=Friday
|start=1pm {{SLT}}
|end=2pm {{SLT}}
|location=[http://slurl.com/secondlife/Longfellow/99/97/28 Enus' Clubhouse]
|description='''On Office hours sabbatical until further notice, feel free to find me in world otherwise...''' 
Topics:
* Primarily Pyogp
* QA
* Bots
}}

User:Enus Linden/Office Hours/Friday

2010-02-26T20:28:23Z

Enus Linden:

{{hCalendar event/Office Hours
|mode={{{mode|}}}
|Resident=Enus Linden
|weekday=Friday
|start=1pm {{SLT}}
|end=2pm {{SLT}}
|location=[http://slurl.com/secondlife/Longfellow/99/97/28 Enus' Clubhouse]
|description='''No meeting February 26...''' 
Topics:
* Primarily Pyogp
* QA
* Bots
}}

PyOGP Client Library

2010-02-09T18:14:57Z

Enus Linden: /* Python module dependencies */

{{PyOGP/navigation}}
== Intro ==

PyOGP is a young, open source, python client library which provides an interface to an agent (client) of a Second Life grid. The code aims to enable automated testing of Second Life grids, to encourage and enable exploration into the client/server relationship and related protocols of Second Life, and to make possible simple prototyping of various client applications.

Hosted on svn.secondlife.com, it does require a contributor's agreement for commit access, and currently has a few contributors from the Second Life open source community.

P.S. We'll likely be moving to hg relatively soon...

* mailing list: pyogp@lists.secondlife.com
* irc: irc://irc.freenode.com/#pyogp
* wiki: http://wiki.secondlife.com/wiki/Pyogp
* licensing: Apache 2.0 license, copyright Linden Lab

=== Goals ===

In the very near future, we can have tests available to be run as soon as a deploy is completed that exercise a simulator/grid in the same way we do a smoke test. We will use these as automated tests run at build time, post deploy validation, and regression testing of simulators and backend systems.

This provides early feedback on code quality. QA is then able to dive deeper in testing the changes specific to a branch.

Having this library available also allows us to test potential changes before we have finalized design and are ready to submit to QA. Not sure how something will play out? Try it, and test it with PyOGP....

=== A Brief History ===

PyOGP was originally created as a tool for testing [[OGP]] related changes to the Second Life grid. By the end of the summer in 2008, the '''pyogp.lib.base''' package provided a skeleton messaging system and was able to test Linden Lab's first implementation of an agent domain and the related changes in an agent's region handoff and teleport. As the development effort around OGP waned, we started to extend pyogp by adding higher level client related functionality. Recently, this functionality was split out into a separate python package ('''pyogp.lib.client'''), and sample scripts (and future apps) were moved into '''pyogp.apps'''.

== Architecture Overview==

=== Structure ===

PyOGP is comprised of three python packages. The library consists of pyogp.lib.base and pyogp.lib.client, while sample scripts, and in time applications, live in pyogp.apps.
:'''pyogp.lib.base''' - consists of basic networking, messaging systems (UDP and event queue) and capabilities, custom datatypes, and a low level message related event system
:'''pyogp.lib.client''' - consists of 'convenience' classes mapping methods and handlers to specific messages (e.g. Agent().say(msg) tells the client to send the ChatFromViewer message to the host region). Raises application oriented events based on processing of messages (these are currently sparsely implemented)
:'''pyogp.apps''' - sample scripts and works in progress, the scripts here generally illustrate simple usage of classes as related to in world interactions by an agent of a Second Life grid

=== Dependencies ===

==== Platform / Python version compatibility ====

PyOGP aims to be compatible across platforms, though there are known problems with various environments. We'll be focusing on ensuring better compatibility soon.

'''Known good configurations'''

:Windows XP + Python 2.5
:Mac + Python 2.5, 2.6
:Linux + Python 2.4, 2.5, 2.6 (Linden hosts fall into this group)

'''Known bad configurations'''
:Windows Vista + Python 2.6
:Windows 7 + Python 2.6

There have been challenges in ensuring compatibility between the various dependencies, largely due to greenlet, eventlet, and pyopenssl. Please report bugs on [http://jira.secondlife.com/browse/PYO pJira]

==== Python module dependencies ====

The packages that make up PyOGP have some dependencies on python modules not included in a standard install, or sometimes not available on an older Python distribution.

'''pyogp.lib.base dependencies:'''

<python> #from setup.py

install_requires=[
'setuptools',
# -*- Extra requirements: -*-
'uuid',
'elementtree',
'llbase',
'WebOb',
'wsgiref',
'eventlet==0.8.14'
]</python>

'''pyogp.lib.client dependencies:'''

<python> install_requires=[
'setuptools',
# -*- Extra requirements: -*-
'pyogp.lib.base'
] </python>

'''pyogp.apps dependencies:'''

<python> install_requires=[
'setuptools',
'pyogp.lib.client'
]</python>

=== How to install ===

''Lindens can see internal documentation for more specific guidance. https://wiki.lindenlab.com/wiki/Pyogp#How_to_Install''

==== Standalone dev environment using buildout ====

Buildout is a type of Python development environment, organizing and configuring various components and their dependencies. On a desktop, one may checkout such an environment for working with PyOGP. One may optionally use a virtualenv Python environment to isolate the development code and it's runtime environment on one's host.

Dependencies: buildout takes care of everything, grabbing needed modules etc.

Wiki instructions: https://wiki.secondlife.com/wiki/Pyogp/Client_Lib/The_Development_Sandbox

==== Installing the PyOGP packages ====

Each of the PyOGP package may be installed to one's Python install or to a [http://pypi.python.org/pypi/virtualenv virtualenv]. '''Buyer beware''' if installing into your system's install: you'll want to be able to uninstall manually, as we haven't hooked up the uninstall. PyOGP is still coming up to speed with respect to distutils and pypi and the like, but it's relatively close now.

To install a package, simply run 'python setup.py install' in a package's root.

==== Referencing PyOGP packages via the PATH ====

Source code can be referenced directly if one simply ensures that a package, and it's dependencies, are available in the PYTHONPATH environmental variable.

== Current functional coverage ==

Anything not listed as covered is probably not yet covered.

pyogp.lib.base:
:* base udp messaging system (message.*)
:** UDP serialization/deserialization
:** message_template.msg parsing
:* base event queue messaging system (event_queue.EventQueueClient())
:* capabilities and their methods. Seed capabilities are a special case. (caps.Capability())
:* Message-based events (message.message_handler)

pyogp.lib.client:
:* agents (agent.Agent())
:** L$ balance request, friending, and walk/fly/sit/stand actions...
:* OGP agentdomain (agentdomain.AgentDomain())
:* application level events (event_system.AppEventsHandler())
:* some object handling (objects.*)
:** edit name, description, next-owner permissions and more
:** object creation is possible
:* some inventory handling (inventory.*)
:** login inv skeletons
:** fetching inventory, including AIS (caps based Agent Inventory Services))
:** some creating of new inventory items (LSL scripts, notecards)
:* regions (region.Region())
:** host and neighboring regions are handled slightly differently
:** udp and event queue connections are optionally enabled for each case
:** currently only pulling caps available to the agent via the seed cap (plus using the inventory related caps in the AIS context)
:* some appearance handling (appearance.AppearanceManager),
:* parcels
:* chat
:* some ImprovedInstantMessage handling
:** raises events on received instant messages
:** can deal with inventory offers/accepts/declines
:** other cases in this message are currently only logged
:* groups
:* group chat
:* LSL script uploading

=== Sample Scripts ===

There are a variety of scripted examples that have been used to exercise and test functionality as it is added to the library. These persist as coded documentation.

The source code is available in https://svn.secondlife.com/svn/linden/projects/2008/pyogp/pyogp.apps/trunk/pyogp/apps/examples/.

The following refers to a buildout context. If one installs pyogp.apps vi setup.py, these scripts will exist in the python environment's bin/ directory. In the buildout context, these scripts are available in {buildout root}/bin.

The scripts are derived from a package's 'setup.py' via the entry_points parameter, and essentially build executable Python scripts configured to run in the correct environment with the proper dependencies added the the path used by the script. These scripts are currently just simple illustrations of some uses of the PyOGP codebase.

<python> #the current entry_points in setup.py og pyogp.apps:

entry_points={
'console_scripts': [
'AIS_inventory_handling = pyogp.apps.examples.AIS_inventory_handling:main',
'agent_login = pyogp.apps.examples.agent_login:main',
'agent_manager = pyogp.apps.examples.agent_manager:main',
'appearance_management = pyogp.apps.examples.appearance_management:main',
'chat_and_instant_messaging = pyogp.apps.examples.chat_and_instant_messaging:main',
'group_chat = pyogp.apps.examples.group_chat:main',
'group_creation = pyogp.apps.examples.group_creation:main',
'inventory_handling = pyogp.apps.examples.inventory_handling:main',
'inventory_transfer = pyogp.apps.examples.inventory_transfer:main',
'inventory_transfer_specify_agent = pyogp.apps.examples.inventory_transfer_specify_agent:main',
'login = pyogp.apps.examples.login:main',
'multi_region_connect = pyogp.apps.examples.multi_region_connect:main',
'object_create_edit = pyogp.apps.examples.object_create_edit:main',
'object_create_permissions = pyogp.apps.examples.object_create_permissions:main',
'object_create_rez_script = pyogp.apps.examples.object_create_rez_script:main',
'object_creation = pyogp.apps.examples.object_creation:main',
'object_properties = pyogp.apps.examples.object_properties:main',
'object_tracking = pyogp.apps.examples.object_tracking:main',
'parcel_management = pyogp.apps.examples.parcel_management:main',
'parse_packets = pyogp.apps.examples.parse_packets:main',
'region_connect = pyogp.apps.examples.region_connect:main',
'smoke_test = pyogp.apps.examples.smoke_test:main',
'chat = pyogp.apps.examples.chat_interface:main',
]
}</python>

== How it Works (High Level) ==

=== Eventlet ===

PyOGP use [[Eventlet]] to run coroutines to handle multiple 'concurrent' processes, rather than threads or multiple processes. Each client agent instance will spawn a handful of coroutines to handles e.g. the UDP pipe, the Event Queue, various monitors, while yielding time to the parent process which should ensure it yields to the other routines as well.

PyOGP uses eventlet in very elementary ways at this point, but will perhaps start to use blocking queues in some cases, so that the coroutine only is allocated processing time if there is work for it to do.

=== pyogp.lib.base ===

This package handles the protocols used when communicating with a Second Life grid. A high level perspective on the package reveals a MessageManager() (still in development) which provides an interface to the UDP and Event Queue connections, as well as basic networking with enables login and capabilities interactions. The base package also has a low level even system through which all messages are passed and sent to subscribers.

Any subcomponent is available for direct interaction at any time, the MessageManager() and the MessageHandler() are the simple access points.

==== Events & Callbacks ====

The event implementation in pyogp follows the observer pattern, where observers subscribe to and are notified when an event occurs. Data is passed throughout the client instance via events.

* MessageManager - is an attribute of a Region and every packet received/sent is filtered through here. subscriptions are by message name
** MessageHandler - is an attribute of MessageManager, and every categorized message received from the event queue or udp dispatcher is filtered through here. (message as defined in message_template.msg, or one of ['ChatterBoxInvitation', 'ChatterBoxSessionEventReply', 'ChatterBoxSessionAgentListUpdates', 'ChatterBoxSessionStartReply', 'EstablishAgentCommunication']. There may be unhandled messages, I just haven't seen em yet :))

===== Message Events =====

In the most fundamental implementation of event usage, all packets are passed through a MessageManager() instance for evaluation. Observers may register to receive udp packets serialized into the form of Message() instances. The MessageHandler() is a consolidation point for subscribing to messages keyed by message name, and created on demand via subscription.

See pyogp.lib.base.message.message_handler.MessageHandler() for more details.

The pyogp agent's Region() instances each monitor their stream of packets (e.g. the host region: agent.region.message_manager.message_handler). (Perhaps this should be changed to a generalized Network() class where all packets (coupled to their originating regions) are evaluated.

Event firing passes data on to a callback handler defined in the subscription, in the form of (handler, *args, **kwargs).

The Agent class monitors the ImprovedInstantMessage packet:
<python> onImprovedInstantMessage_received = self.region.message_handler.register('ImprovedInstantMessage')
onImprovedInstantMessage_received.subscribe(self.onImprovedInstantMessage)

def onImprovedInstantMessage(self, packet):
""" handles the many cases of data being passed in this message """

{code} # parse and handle the data...</python>

The messaging system then fires the event when an ImprovedInstantMessage message is received, which calls onImprovedInstantMessage method above to handle the message contents. Multiple subscribers may be listening for any message related event, and each would be notified of the same Message() instance.

Unsubscribing from an event:
<python> onImprovedInstantMessage_received.unsubscribe(self.onImprovedInstantMessage)</python>

There are various event and callback implementations viewable in pyogp, poke around and help consolidate things if you like.

=== pyogp.lib.client ===

The client package generally provides a convenient interface to initiate or interpret interactions with host region (or neighboring regions). By listening to the messaging related event system in pyogp.lib.base, the client package interprets the messages that come in off the wire, and executes business logic in building responses. pyogp.lib.client also provides simple methods to enable the ending of messages to a grid.

==== Events ====

* EventsHandler - an attribute of an Agent, also able to be passed in, that is intended as the primary interface of a pyogp application into the internal state and data events within the lib. This system uses the same base classes as used by the MessageHandler() in the base package, and the descriptions about events and callbacks above apply here as well. The api for subscribing to these events is similar to the MessageHandler(), with an additional timeout parameter passed in the _register() method. When the specified timeout expires, the subscription returns None and expires the subscription.

==== Agent Login (examples) ====

===== Single Agent Login & Chat=====

Spawn a client in a co-routine, allowing persistent presence until forcefully terminated.

<python>from eventlet import api

from pyogp.lib.client.agent import Agent
from pyogp.lib.client.settings import Settings

settings = Settings()

settings.ENABLE_INVENTORY_MANAGEMENT = True
settings.MULTIPLE_SIM_CONNECTIONS = False

client = Agent(settings = settings)

api.spawn(client.login, options.loginuri, 'first', 'last', 'password', start_location = options.region)

# wait for the agent to connect to it's region
while client.connected == False:
api.sleep(0)

while client.region.connected == False:
api.sleep(0)

client.say("Hello World!")

# once connected, live until someone kills me
while client.running:
api.sleep(0)</python>

===== Multiple Agent Login =====

Each agent instance in logged in in a separate coroutine.

<python>from pyogp.lib.client.agent import Agent
from pyogp.lib.client.agentmanager import AgentManager

credentials= [('agent1', 'lastname', 'password'), ('agent2', 'lastname', 'password')]
agents = []

# prime the Agent instances
for firstname, lastname, password in credentials:
agents.append(Agent(settings, firstname, lastname, password))

agentmanager = AgentManager()
agentmanager.initialize(agents)

# log them in
for key in agentmanager.agents:
agentmanager.login(key, options.loginuri, options.region)

# while they are connected, stay alive
while agentmanager.has_agents_running():
api.sleep(0)</python>

== Extending Functionality ==

While the implementations and structures in pyogp.lib.base can (and are in the process of) being refactored to improve performance or usability, it is a fairly complete package.

The functional coverage PyOGP provides on the other hand is not complete, and there are a variety of needs to complete the implementation in pyogp.lib.base. We need to improve coverage of message handling (dealing with messages sent to the client), add more wrappers for sending various messages and performing multistep tasks (to simplify the initiation of interactions with the region), and we need to raise more application level events in the client package so that applications have easy access to incoming data.

=== Sending Messages ===

PyOGP, like the Viewer, communicates with the Second Life simulator by sending messages over UDP.

In order to extend PyOGP, you'll build a representation of a new UDP message, and send it through the pyogp.lib.base modules for serialization and wire handling.

=== Example: Sending an IM ===

To send an IM to the simulator, send an ImprovedInstantMessage packet. The base class for message packets is defined in <code>base/message/message.py</code>

Packets are assembled using a Message() instance which has the message name and Block() instances passed in through its constructor. Similarly, Blocks are assembled by passing in the Block name and the value name and values for each of the Block values. (The ability to build Message() instances via an llsd payload is expected to be introduced soon.)

Note: It is important that the message name, block name, and value names and types should match what is specified in the message template. (It is also possible to manipulate the representation of the stored template, or to use a custom message template.)

Example:
<python> def send_ImprovedInstantMessage(self, AgentID = None, SessionID = None,
FromGroup = None, ToAgentID = None,
ParentEstateID = None, RegionID = None,
Position = None, Offline = None,
Dialog = None, _ID = None, Timestamp = None,
FromAgentName = None, _Message = None,
BinaryBucket = None):
"""
sends an instant message packet to ToAgentID. this is a
multi-purpose message for inventory offer handling, im, group chat,
and more
"""

packet = Message('ImprovedInstantMessage',
Block('AgentData',
AgentID = AgentID,
SessionID = SessionID),
Block('MessageBlock',
FromGroup = FromGroup,
ToAgentID = ToAgentID,
ParentEstateID = ParentEstateID,
RegionID = RegionID,
Position = Position,
Offline = Offline,
Dialog = Dialog,
ID = UUID(str(_ID)),
Timestamp = Timestamp,
FromAgentName = FromAgentName,
Message = _Message,
BinaryBucket = BinaryBucket))

# Send the message:
self.region.enqueue_message(packet, True)</python>

=== Handling Incoming Messages and Raising an Event ===

To listen for when messages of a particular type are sent to the client instance, subscribe to the MessageHandler() on the host region's MessageManager(), like the example that follows:

<python> onImprovedInstantMessage_received = self.region.message_handler.register('ImprovedInstantMessage')
onImprovedInstantMessage_received.subscribe(self.onImprovedInstantMessage)</python>

When the event is fired upon receipt of the message matching the name, the specified callback handles the data passed along, and in this case raises an event notifying observers of the 'InstantMessageReceived' event in pyogp.lib.client of the important data.

<python> def onImprovedInstantMessage(self, packet):
""" callback handler for received ImprovedInstantMessage messages. much is passed in this message, and handling the data is only partially implemented """

Dialog = packet.blocks['MessageBlock'][0].get_variable('Dialog').data
FromAgentID = packet.blocks['AgentData'][0].get_variable('AgentID').data

if Dialog == ImprovedIMDialogue.InventoryOffered:

self.inventory.handle_inventory_offer(packet)

# ...
# some of the Dialogue types this message can contain are handled, we are showing 2
# ...

elif Dialog == ImprovedIMDialogue.FromAgent:

# ... code parses the data from the Message() instance ...

message = AppEvent('InstantMessageReceived', FromAgentID = FromAgentID, RegionID = RegionID, Position = Position, ID = ID, FromAgentName = FromAgentName, Message = _Message)

logger.info("Received instant message from %s: %s" % (FromAgentName, _Message))

self.events_handler.handle(message)</python>

== Logging ==

Uses python's standard logging module (http://docs.python.org/library/logging.html). The library defines logging events throughout, it is up to the application/script to determine the output.

Hooking logging into a new module:

<python>from logging import getLogger

# initialize logging
logger = getLogger('pyogp.lib.client.agent')

class Agent(object):
""" our agent class """

def __init__(self, params):

self.params = params

logger.debug("Initializing agent with params: %s" % (params))</python>

An application can then set up the logging output as follows (or any other way it pleases):

<python>console = logging.StreamHandler()
formatter = logging.Formatter('%(asctime)-30s%(name)-30s: %(levelname)-8s %(message)s')
console.setFormatter(formatter)
logging.getLogger('').addHandler(console)
logging.getLogger('').setLevel(logging.DEBUG)</python>

The output to console is then:

<bash>2009-04-21 22:08:58,681 pyogp.lib.base.agent : DEBUG agent with params: params</bash>

== Pyogp Unit Tests ==

See [[PyOGP_Package_Unittests]].

== Sphinx (api docs) ==

'''Api documentation is now available for PyOGP packages''' (well, not for apps yet, but someday....)!

In pyogp/docs in each of the pyogp.lib.base and pyogp.lib.client packages, one will find source, last revision, and build files for sphinx based documents. Output is available at {package root}/docs/html/index.html.

We plan on sharing the api documentation on the web soon, and will work to make simple build wrappers work on various platforms, though this is a low priority.

Ask Enus for updated documentation to be checked in, or, build a better refresh.py.

== Roadmap ==

See [[Pyogp/Roadmap]] for details, or ask in irc or on the mailing list. Here's what's up in the near term for pyogp:

* better '''packaging''' and '''platform compatibility'''
* more '''functional coverage''' of message. We are covering 32% of the messages the viewers sends or handles when received (though it's estimated at more like 50% of normal use cases.
* '''permissions system testing''' to save QA from 3-5 day regression passes on perms
* '''appearance''' - this will require enabling upload and download, plus baking. Anyone have some spare time? :)

[[Category: Pyogp_Client_Lib]]
[[Category: Pyogp]]
[[Category:Architecture Working Group]]
[[Category:Grid_Interoperability]]
[[Category:AW Groupies]]
[[Category:MMOX]]

User:Enus Linden/Office Hours/2010 Fenruary 05

2010-02-05T23:47:35Z

Enus Linden: moved User:Enus Linden/Office Hours/2010 Fenruary 05 to User:Enus Linden/Office Hours/2010 February 05

#REDIRECT [[User:Enus Linden/Office Hours/2010 February 05]]

User:Enus Linden/Office Hours/2010 February 05

2010-02-05T23:47:35Z

Enus Linden: moved User:Enus Linden/Office Hours/2010 Fenruary 05 to User:Enus Linden/Office Hours/2010 February 05

[13:02] Latif Khalifa: perhaps enus will grace us with his presence this year 
[13:02] Latif Khalifa: :P 
[13:02] Dedric Mauriac: if anyone would like a free bear, let me know and i'll send you mine. 
[13:02] Ardy Lay: Nice lag-walk there Enus. 
[13:02] Enus Linden: it's punishment latif 
[13:03] Latif Khalifa: speaking of the... 
[13:03] Latif Khalifa: lol 
[13:03] Enus Linden: tz ardy, i've been working on perfecting it! 
[13:03] Enus Linden: tx* 
[13:03] Latif Khalifa: judging by how often you come, you sure must feel like it's punishment :P 
[13:04] Enus Linden: tbh, i've been wrestling with the idea of 1. stopping my OH or 2. sharing the mc responsibilities 
[13:04] Enus Linden: its not getting any easier to make time, and that sucks 
[13:04] Enus Linden: i dont want to stop em 
[13:04] Enus Linden: but do want them to be mutually useful 
[13:05] Enus Linden: nice to see that folks havent given up yet! 
[13:05] Latif Khalifa: i was advertising the OH xD 
[13:05] Arcane Laval: :) 
[13:05] Dedric Mauriac: we are all just bots 
[13:05] Latif Khalifa: long time no see :) 
[13:06] Enus Linden: have you an agenda in advertising today latif? 
[13:06] Latif Khalifa: erm, no 
[13:06] Enus Linden: crap, so i need to have one 
[13:06] Enus Linden: ;) 
[13:06] Latif Khalifa: i could've made one had i known it was required 
[13:06] Enus Linden: i've a couple of things on the mind... 
[13:06] Ardy Lay: Ah.. well, if you are not getting anything out of them then I don't see there is much point. I know I don't have much to offer you. I was just hoping to learn a little more about what's going on in SL. 
[13:07] Enus Linden: one is pyogp, which should start moving again soon 
[13:07] Enus Linden: another is in regards to the automation team 
[13:07] Enus Linden: and we'll see where things go from there 
[13:07] Latif Khalifa: perhaps some would be interested to hear about automated load testing using Amazon EC2 cloud 
[13:07] Enus Linden: aye latif 
[13:08] Latif Khalifa: i know i would xD 
[13:08] Enus Linden: i'll cover that 
[13:08] Morgaine Dinova: Me too 
[13:08] Dedric Mauriac: interesting 
[13:08] Enus Linden: awesome 
[13:08] Enus Linden: well, thanks all for coming 
[13:08] Enus Linden: hi rakesh! 
[13:08] Dedric Mauriac: will there be a white paper about it? 
[13:08] Rakesh Linden: hi Enus 
[13:08] Enus Linden: dedric, maybe? 
[13:08] Rakesh Linden: there is no voice 
[13:08] Latif Khalifa: hello Rakesh 
[13:08] Enus Linden: OH is in text 
[13:08] Enus Linden: to many languages 
[13:08] Enus Linden: to listen clearly 
[13:08] Rakesh Linden: i c. 
[13:08] Youri Ashton: friendly hello's! 
[13:09] Rakesh Linden: hi everyone 
[13:09] Enus Linden: plus text requires minimal moderation 
[13:09] Enus Linden: hey youri 
[13:09] Morgaine Dinova: Enus, what would you like to see on your part, that would make these meetings more useful to you, beyond just "community contact"? 
[13:09] Enus Linden: so pyogp lib work update really quicly 
[13:09] Enus Linden: good ? morgaine 
[13:09] Enus Linden: i'll take a note to discuss it 
[13:09] Arcane Laval: I'll be right back! 
[13:10] Enus Linden: alright: pyogp 
[13:10] Enus Linden: i have done nil with this for a couple of months 
[13:10] Enus Linden: i ported to hg 
[13:10] Enus Linden: did some dev, moved indra.base to llbase after pushing that to pypi 
[13:10] Enus Linden: and it stalled 
[13:11] Enus Linden: I'm too busy to continue regularly, but... 
[13:11] Enus Linden: i'll be handing off maintenance and further extension of the libs to some folks in QA here 
[13:11] Enus Linden: OS folks are of course encouraged to collab as well 
[13:12] Enus Linden: but that's been quiet for some time and i assume not much there 
[13:12] Morgaine Dinova: Since it's the basis of your test platform (isn't it?), do you mean it's stalled because your current test stuff works and you have no incentive to touch it? 
[13:12] Enus Linden: i'd love to see an ecosystem pop up around it again 
[13:12] Eddi Decosta: hey Enus ㋡ 
[13:12] Enus Linden: should prolly start engageing in irc and the mailing list more agin 
[13:12] Enus Linden: again 
[13:12] Enus Linden: morgaine: it's still ramping up as the basis 
[13:13] Enus Linden: Rakesh (and Ali, Vektor, Fisher, and others as time allows) will be driving it's evolution primarily now 
[13:13] Youri Ashton: hey fisher! 
[13:13] Eddi Decosta: heya Fisher! ㋡ 
[13:13] Enus Linden: there is MUCh incentive to touch it: it's incomplete, amd not much testing is in place using it now 
[13:14] Fisher Linden: Hey 
[13:14] Enus Linden: that's going to cahnge this quarter 
[13:14] Morgaine Dinova: Well I still hope to poke VWRAP bits into PyOGP, once we know what the hell to poke in. ;-) I'm not in the slightest bit happy with Pixel's addition of OGP code into Snowglobe --- that's no way to test out protocol ideas, by hardwiring them into C++ code within a nightmare codebase. 
[13:14] Eddi Decosta: welcome to sl Rakesh lol ㋡ 
[13:14] Enus Linden: VWRAP is highly encouraged to leverage PyOGP 
[13:14] Morgaine Dinova: :-) 
[13:14] Enus Linden: maybe a pyogp-vwrap fork is in order 
[13:15] Enus Linden: in fact, we should make it so 
[13:15] Rakesh Linden: thx Eddi 
[13:15] Morgaine Dinova: Could happen. Although with Hg, a "fork" isn't necessary, just another repository, or several. 
[13:15] Ardy Lay: Ugh. Some uninitiated noob is closing my JIRA issues as "expected bahaviour". I gotta go beat on them. Bye. 
[13:15] Enus Linden: i'd suggest a fork of the lib packages 
[13:15] Rakesh Linden: is VWRAP a standard yet? 
[13:15] Enus Linden: slightly more formal 
[13:15] Morgaine Dinova: Lord no 
[13:16] Latif Khalifa: there is nothing to fork over for yet 
[13:16] Enus Linden: it's a theory 
[13:16] Rakesh Linden: I thought it is still a proposal 
[13:16] Latif Khalifa: no implementation exists yet 
[13:16] Latif Khalifa: so talking about vwrap fork is premature imhp 
[13:16] Latif Khalifa: o even 
[13:16] Enus Linden: yep 
[13:16] Morgaine Dinova: VWRAP is currently at the 5% reached initial draft stage, if that. And not even that 5% is well examined yet, let alone agreed. Early days. 
[13:17] Enus Linden: i'll support pyogp as a test bed when timing dictates it 
[13:17] Rakesh Linden: i agree with Latif 
[13:17] Enus Linden: so sometime next week i'll set up a roadmap and walkthrough for qa to grab pyogp and make it go as a server side test source 
[13:18] Enus Linden: they've been tinkering, but we're all busy 
[13:18] Morgaine Dinova: That's cool 
[13:18] Sea Urchin beanbag: Going to next texture. 
[13:18] Sea Urchin beanbag: Going to next texture. 
[13:18] Sea Urchin beanbag: Going to next texture. 
[13:18] Enus Linden: their work will complement the work of the automation team as it spins up 
[13:19] Enus Linden: the automation team is Spider, Ray, Xandix, and the not yet started but hired Scobu 
[13:19] Enus Linden: Cassandra = PM 
[13:19] Enus Linden: i'm in the mix in some ways, mostly high level 
[13:19] Morgaine Dinova: Project Manager> 
[13:19] Morgaine Dinova: ? 
[13:19] Enus Linden: yep Morgaine 
[13:19] Morgaine Dinova: kk 
[13:19] Enus Linden: Spider = Lead 
[13:19] Latif Khalifa: is automatio team all about services, sims, and the backend? 
[13:20] Enus Linden: not onlt latif 
[13:20] Enus Linden: will cover Viewer and Web as well 
[13:20] Latif Khalifa: interesting 
[13:20] Morgaine Dinova: Viewer? In what respect? 
[13:20] Dedric Mauriac: click button, verify something happens 
[13:20] Enus Linden: cannot share details w/o consent at this time 
[13:21] Enus Linden: GUI automation would be great, but isnt part of the picture right now 
[13:21] Enus Linden: pixel based testing isn't our idea of fun yet 
[13:21] Morgaine Dinova: But that's GUI QA. 
[13:21] Dedric Mauriac: unit testing 
[13:21] Morgaine Dinova: Hmm. Can you explain the diff btn automation and QA teams? 
[13:21] Enus Linden: functional automation against the viewer is being worked on now though 
[13:21] Enus Linden: yeah morgaine 
[13:22] Enus Linden: Automation team's charter is to build frameworks and environments to support testing 
[13:22] Dedric Mauriac: qa is people with eyes verifying manually 
[13:22] Morgaine Dinova: Jeez no Dedric, or I hope not 
[13:22] Enus Linden: their work will initially be setting up a harness that handles code and enironments to test in, running existing unit tests and functional tests, and enabling more to be run via enrionemnts and such 
[13:22] Dedric Mauriac: automation supports qa 
[13:23] Enus Linden: QA = test engineers 
[13:23] Enus Linden: test planning, risk assessmnet, test execution, 
[13:23] Enus Linden: QA and Dev write autoamted test cases 
[13:23] Enus Linden: automation team makes sure they are run and reported on 
[13:24] Enus Linden: once there is sufficient framework coverage, the automation team can certainly help with test writing 
[13:24] Enus Linden: but that is not their responsibility atm 
[13:24] Morgaine Dinova: You mean QA team "makes sure they are run and reported on", right? 
[13:25] Widget Whiteberry slips away 
[13:25] Enus Linden: in a way morgaine, it's the auto team facilitating the running and reporting. QA uses the data as part of test plan validation 
[13:25] Morgaine Dinova chuckles 
[13:26] Enus Linden: so the 30000 foot view of the automatin team roadmap as we know it: 
[13:26] Enus Linden: provide a test harness 
[13:26] Morgaine Dinova: I'm confused, but don't worry about it. The way I make sense of it is Autom == make test infrastructure, QA == use it. But I guess that's wrong. 
[13:26] Dedric Mauriac: that's a lot of feet 
[13:26] Enus Linden: hook existing automated tests in (ours, third party libs, w/e) 
[13:26] Enus Linden: morgaine, that's right 
[13:27] Morgaine Dinova: Uh, OK ^_^ 
[13:27] Enus Linden: 3000 ft cont: extend the harness with test beds in the form of dedicated hardware and EC2 virtual environments 
[13:27] Enus Linden: missed a 0 there ;) 
[13:27] Morgaine Dinova: UDP loss 
[13:28] Enus Linden: work on facilitating load tests in real and virtual envs 
[13:28] Enus Linden: report on all of it 
[13:28] Enus Linden: build libs to support test case state setting and execution 
[13:28] Enus Linden: etc etc etc 
[13:28] Enus Linden: we've sketched out plans for the year, given info we know, as of this week 
[13:28] Enus Linden: we start real work monday 
[13:29] Enus Linden: wheeeee 
[13:29] Sea Urchin beanbag: Going to next texture. 
[13:29] Morgaine Dinova: Wheee indeed :-) 
[13:29] Latif Khalifa: sounds some awesome QA juice on the way :D 
[13:29] Fisher Linden: Wheeee indeed 
[13:29] Sea Urchin beanbag: Going to next texture. 
[13:29] Morgaine Dinova: About time. You can't afford to do the grunt work manually, really can't. 
[13:29] Sea Urchin beanbag: Going to next texture. 
[13:29] Sea Urchin beanbag: Going to next texture. 
[13:29] Sea Urchin beanbag: Going to next texture. 
[13:29] Enus Linden: agreed morgaine 
[13:30] Dedric Mauriac: oh, i think they can afford it, but wouldn't make sense though 
[13:30] Enus Linden: QA folks are going to start getting more direction toward automation in many ways 
[13:30] Enus Linden: for some, it's a natrual inclination 
[13:30] Enus Linden: but as a team, we've got to start heading that way more and more 
[13:31] Morgaine Dinova: Will be brill to be able to say "1.23.9 is ready for RC1 release, passes all regression tests for 1.23.8". 
[13:31] Dedric Mauriac: with the use of automation, problems can be found quicker, as they happen in development, or newly discovered 
[13:31] Enus Linden: test plans need to assert things like "100% unit tests coverage and 80% functinal test coverage" 
[13:31] Enus Linden: we need to start budgeting time, and building up skill sets to enable it 
[13:31] Latif Khalifa: hopefully with amazon and there diverse locations you could add some higher latency tests like connecting from europe etc. some network timing issues are known to slip by if you test from the same country :) 
[13:31] Enus Linden: so will improve over the upcoming months 
[13:31] Fisher Linden: Entrance and exit criteria, Enus 
[13:32] Dedric Mauriac: are you using things like nunit/nmock/nhibernate/log4net and such? 
[13:32] Morgaine Dinova: Oooh, coverage analysis, need. Even if the coverage assignment is largely handwaved, it's still helpful. 
[13:32] Morgaine Dinova: neat* 
[13:32] Enus Linden: Fisher will do a lot of the grunt work :P 
[13:32] Fisher Linden: lol...yummy! 
[13:32] Fisher Linden: We love coverage analysis too 
[13:32] Enus Linden: latif: latency tests YES 
[13:32] Morgaine Dinova gives Fisher a cookie 
[13:32] Fisher Linden: nomnomnom 
[13:33] Morgaine Dinova: lol 
[13:33] Enus Linden: so perf/load/benchmark testing.... 
[13:33] Enus Linden: all part of the same equation 
[13:33] Enus Linden: we've talked about my intent to use pyogp on ec2 against a test env before 
[13:33] Dedric Mauriac: don't the methods in theLSL language already have automated testing in them wiht each build? 
[13:33] Enus Linden: that's on the automation team's roadmap to facilitate 
[13:34] Enus Linden: and i need to plug it into QA's 
[13:34] Enus Linden: tbh, I need to hire someone to drive it. I can only drive it so much 
[13:34] Enus Linden: i've started. I have test pyogp debs for our system image 
[13:34] Latif Khalifa: you can do some serious ddos with ec2. i mean load testing :P 
[13:34] Morgaine Dinova: haha 
[13:34] Enus Linden: latif: yeah 
[13:34] Enus Linden: 1st goal: simulate peak concurrency on a grid 
[13:34] Fisher Linden: Really looking forward to ec2 testing 
[13:35] Rakesh Linden: ec2 will definitely play a big part in future at Linden 
[13:35] Dedric Mauriac: I would attempt to simulate more than the peak. mabe 150% peak 
[13:35] Enus Linden: 2nd goal: 2x peak 
[13:35] Enus Linden: then 4x 
[13:35] Dedric Mauriac: ah, good goals 
[13:35] Enus Linden: and then til stuff falls apart and i break the whole grid 
[13:35] Latif Khalifa: with libomv you could do prolly 200-300 clients per instance 
[13:35] Enus Linden: latif: on windows yeas 
[13:35] Latif Khalifa: don't know how much pyogp can scale 
[13:35] Fisher Linden: We will see! 
[13:36] Enus Linden: pyogp can handle 80 
[13:36] Enus Linden: becaus eof eventlet 
[13:36] Dedric Mauriac: try simulating 1500 people in one sim. lol 
[13:36] Enus Linden: eventlet grabs 75% of a cpu 
[13:36] Enus Linden: and that's it 
[13:36] Latif Khalifa: ah 
[13:36] Enus Linden: could easily run on multiple cpus 
[13:36] Rakesh Linden: so libomv doesn't work w Mono? 
[13:36] Latif Khalifa: Rakesh it sure does 
[13:36] Enus Linden: libomv does work well under mono 
[13:36] Enus Linden: but mono adds resource overhead 
[13:36] Enus Linden: at least on our eniacs i can only run 100 clients 
[13:37] Enus Linden: on my windows desktop i easily run 400 
[13:37] Rakesh Linden: i c 
[13:37] Enus Linden: 9eanic = dev box w/ system image like that of a prod host) 
[13:37] Latif Khalifa: Enus mono 2.6 got a lot better. some memleaks and cpu usage problems we had disappeared 
[13:37] Enus Linden: ooohhh 
[13:37] Enus Linden: we still only have 1.9 
[13:37] Enus Linden: will re-investigate 
[13:37] Latif Khalifa: if you ever want to test it, go with 2.6 
[13:38] Latif Khalifa: i've seen significant improvements 
[13:38] Enus Linden: easy to add a new version to a host, but wont update the sys image package anytime soon 
[13:38] Enus Linden: thanks for the tip 
[13:38] Rakesh Linden: esp since we use Mono for LSL interpreter 
[13:38] Dedric Mauriac: so besides havok, we now need to upgrade mono. heh. 
[13:38] Morgaine Dinova: That's extremely bad news if eventlet only scales that far. Stackless scales massively according to EVE, but I don't know what "massively" translates to for SL work. Hmmmm ... :-( 
[13:38] Latif Khalifa: my test with 20 clients went from 60% cpu to 7% 
[13:38] Enus Linden: woah 
[13:38] Enus Linden: eventlet is odd in that way morgaine 
[13:38] Dedric Mauriac looks for a JITA region 
[13:38] Latif Khalifa: and memory usage was flat 
[13:39] Enus Linden: so, back to distributed load testing 
[13:39] Morgaine Dinova: Latif, can't the Mono thread pool be extended to hundreds and thousands? 
[13:39] Enus Linden: vision: test automation harness (we're going to use TeamCity, will get url in a sec) to spawn a bajillion test agent hosts on ECS, distributed in various hosting facilities in Europe, Aisie, NA, etc 
[13:40] Morgaine Dinova: s/can't/can/ 
[13:40] Enus Linden: those agents can be driven via a web hook to run specific tests using specific accounts against a staging env that very closely matches agni 
[13:40] Dedric Mauriac: http://www.jetbrains.com/teamcity/ 
[13:40] Enus Linden: this staging env is also in the works, but is a separate team's deliverable 
[13:41] Enus Linden: the agents shoudl act very very similar to real agents in world 
[13:41] Dedric Mauriac: real scripted agents 
[13:41] Enus Linden: and we should see cimilar metrics of various kinds to what we see in production 
[13:41] Enus Linden: similar* 
[13:41] Enus Linden: ty for the link dedric 
[13:42] Enus Linden: once we are happy that we ahve a useful test config, we ramp it up 
[13:42] Dedric Mauriac: i've used ccnet in the past, but have had someone else recommend team city to me as well. 
[13:42] Latif Khalifa: we also use teamcity for automated testing in libomv (on a much lower scale of course) :) 
[13:42] Enus Linden: and watch things fall over 
[13:42] Enus Linden: fix 
[13:42] Enus Linden: repeat 
[13:43] Enus Linden: it's not just this sort of testing we're targetting tho 
[13:43] Enus Linden: it's far simpler to enable testing susystems 
[13:43] Enus Linden: sub* 
[13:43] Enus Linden: web services, util.agni services, web apps, etc 
[13:44] Enus Linden: they will come first. it's kind of nice, seeing the roadmap and it's building blocks 
[13:44] Dedric Mauriac: most awesome app - http://www.avatarsunited.com/apps/helloworld 
[13:44] Latif Khalifa: i could imagine. it woudl still be helpful to have a way to test things on production level loads. things have a nasty habit of breaeking at high load that work well under subsystem test 
[13:45] Enus Linden: latif: absolutely 
[13:45] Enus Linden: case in point: I laod testing avatars unites 
[13:45] Enus Linden: we all know how well that worked out 
[13:45] Latif Khalifa: hehehe 
[13:45] Enus Linden: due to timing, could only test from a handful of angles 
[13:45] Enus Linden: we *did* see the breaking point 
[13:45] Enus Linden: called it out 
[13:45] Latif Khalifa: is it RoR? 
[13:46] Enus Linden: and simply didnt expect the uptake to be what it was 
[13:46] Dedric Mauriac: I log in and see about 100 bithdays every day on the home page now 
[13:47] Enus Linden: being able to test comprehensively is what this year will be all about 
[13:47] Dedric Mauriac: Enus, i'm proud that you are moving in that direction. 
[13:47] Morgaine Dinova: Dedric: AU's webite work pretty poorly. Your URL is another that fails -- I just get the general app/ directory 
[13:47] Sea Urchin beanbag: Going to next texture. 
[13:47] Enus Linden: unit, functional, subsystem, end to end, at scale, for every product and app we handle 
[13:47] Dedric Mauriac: ah, i didn't publish the app yet. maybe that is why 
[13:47] Enus Linden: such a cynic morgaine ;) 
[13:47] Dedric Mauriac: it's just me testing a very simple "hello world" app 
[13:47] Morgaine Dinova: Me? Never! 
[13:47] Enus Linden: well, 70 should have been 60 
[13:48] Enus Linden: oops, ww 
[13:48] Al Sonic: Hello, United Avatars! 
[13:48] Dedric Mauriac: ah yea, i should upgrade it to say that instead. heh. 
[13:48] Enus Linden: i wonder if this OH should shift to a more general QA and Automation orientation 
[13:49] Dedric Mauriac: :) 
[13:49] Enus Linden: getting back to morgaine's question about it's usefulness 
[13:49] Enus Linden: it was a vehicle for pyogp convos and ogp convos for a wihle 
[13:49] Enus Linden: while 
[13:49] Enus Linden: perhaps it's time to re-orient things 
[13:49] Dedric Mauriac: Has anything became apparent using automated testing that you would have never found on your own? 
[13:50] Enus Linden: some bottlenecks in load testing i've done is surprising 
[13:50] Enus Linden: the way sims work (or dont) is often surprising 
[13:50] Enus Linden: libomv knows all about that 
[13:50] Enus Linden: ;) 
[13:50] Dedric Mauriac: the nameless delagger is Enus 
[13:50] Latif Khalifa: ;) 
[13:51] Morgaine Dinova: Resi's are beyond surprise. ;-) [Working on that cynicism here :P] 
[13:51] Dedric Mauriac: or is it, delagulator 
[13:51] Latif Khalifa: i actually often wonder what makes sim choke with over 50-60 agents. is it cpu, io saturation, etc 
[13:51] Enus Linden: right now, the focus w/in automation will be building regression test suites, and automation coverage on new projects 
[13:52] Enus Linden: latif: io and then cpu (script time often) 
[13:52] Dedric Mauriac: with automated testing, i'm sure you can make charts to help identify what happens 
[13:52] Fisher Linden: hmm....charts .... 
[13:52] Enus Linden: dedric: we'll have thousands of pretty charts 
[13:52] Enus Linden: literally 
[13:52] Latif Khalifa: Enus, script time should be throttled 
[13:52] Enus Linden: maybe tens of them 
[13:52] Enus Linden: latif, should be, is, still sucks 
[13:52] Enus Linden: WIP 
[13:52] Dedric Mauriac: you sould let us see some - even if they are really old. us geeks need eye candy. 
[13:52] Latif Khalifa: i mean mono gets it's time slice and that's it 
[13:53] Enus Linden: dedric, in progress. 
[13:53] Enus Linden: I plan to publish publicly 
[13:53] Enus Linden: at least some things 
[13:53] Latif Khalifa: but i could imagine doing high bandwidth network with 60+ clients can be resource intensive on the sim 
[13:53] Dedric Mauriac: The article about the MySQL upgrade was the most intriging thing I saw this year on the blogs. 
[13:53] Enus Linden: in fact, will start to talk to the auto team abuot building OS style collab on test case authoring and input 
[13:54] Enus Linden: derric: that was rad. loved it 
[13:54] Enus Linden: it was clearly well received 
[13:54] Morgaine Dinova: Did you see this Enus? Was very interesting reading -- http://arstechnica.com/business/data-centers/2010/02/what-second-life-can-teach-all-companies-about-scaling-web-apps.ars 
[13:54] Enus Linden: i glanced at page 2 morgaine XD 
[13:54] Enus Linden: it's open and pending a read 
[13:54] Morgaine Dinova: Hehe 
[13:55] Enus Linden: (first link i got to it was to page 2) 
[13:55] Youri Ashton: thanks for the meeting enus! 
[13:55] Youri Ashton: bye bye all 
[13:55] Enus Linden: my pleasure! 
[13:55] Enus Linden: ciao youri 
[13:55] Enus Linden: see ya laters 
[13:55] Morgaine Dinova: Cyu Youri :-) 
[13:55] Latif Khalifa: it was interesting to read how people scale up things 
[13:56] Latif Khalifa: like handling enourmous read loads 
[13:56] Enus Linden: scaling is a focal point here atm. last year we spent a lot of time re-architecting things, with good impact 
[13:56] Latif Khalifa: a lot of it seems to be, use db's as key value store 
[13:56] Latif Khalifa: and memcache the hell out of it 
[13:56] Latif Khalifa: joins will kill you 
[13:56] Enus Linden: amen latif, is a good model in many cases 
[13:57] Enus Linden: (AU would benefit there) 
[13:57] Morgaine Dinova: Hmmmm ... not "with good impact" from the resi's PoV, Enus. And that's not cynicism I'm afraid. 
[13:57] Latif Khalifa: read a but about facebook infrastructure 
[13:57] Enus Linden: Morgaine: think back to last january 
[13:57] Enus Linden: and the months leading up 
[13:57] Latif Khalifa: they handle 150k pageviews a sec 
[13:57] Latif Khalifa: and they have 35TB memcached cluster 
[13:57] Morgaine Dinova: Yeah, Facebook is great with articles and presentations on their internals. 
[13:57] Latif Khalifa: which they have hacked to use UDP 
[13:57] Enus Linden: we fell over at 3pm PSt 3 out of every 7 days 
[13:58] Latif Khalifa: since it's all iternal net, and ultra low latency 
[13:58] Latif Khalifa: they claim to get <1ms latency from memcached over udp on local net 
[13:58] Latif Khalifa: which is pretty awesome 
[13:58] Morgaine Dinova: Latif: notice that though they went back to UDP, they had to create their own reliability layer on top of it, and they said that was utter murder. 
[13:59] Enus Linden: eep, almost 2. i gotta run. 
[13:59] Enus Linden: THANKS everyone 
[13:59] Morgaine Dinova: KK, Cyu Enus, take care :-) 
[13:59] Rakesh Linden: ty Enus 
[13:59] Fisher Linden: Thanks, Enus. :-) 
[13:59] Dedric Mauriac: Thanks enus. 
[13:59] Enus Linden: note: next week I will miss this time slot 
[13:59] Latif Khalifa: take care enus 
[13:59] Enus Linden: i hope to have a stand in 
[13:59] Enus Linden: this was a nice caht 
[13:59] Fisher Linden: Spider! 
[13:59] Enus Linden: maybe i'll get the auto team to front someone to talk more 
[14:00] Morgaine Dinova: woot! 
[14:00] Enus Linden: exactly fisher 
[14:00] Dedric Mauriac: have an ajenda next time 
[14:00] Enus Linden: this went well w/o 
[14:00] Enus Linden: ;) 
[14:00] Enus Linden: will try 
[14:00] Enus Linden: ciao!

User:Enus Linden/Office Hours/2010 February 05

2010-02-05T23:47:18Z

Enus Linden: Created page with '[13:02] Latif Khalifa: perhaps enus will grace us with his presence this year [13:02] Latif Khalifa: :P [13:02] Dedric Mauriac: if anyone would like a free bear, let m...'

PyOGP Client Library Development Sandbox

2010-01-06T17:32:01Z

Enus Linden: /* Install Method 2: setup.py */

{{PyOGP/navigation}}
We will first run down the general explanation and add platform specific notes later.

== Note ==

We're migrating to [[Mercurial_repositories|Mercurial]]... Please check back soon for updated docs.

PyOGP package install instructions need some work... stay tuned. Feel free to follow the buildout directions to use the Subversion repositories for now.

=== Repositories ===

Need some work before they are ready as installed packages. In the meantime, just add the path to "pyogp.{package}" to your PYTHONPATH to use the libs, assuming you have the other dependencies.
* http://bitbucket.org/enus_linden/pyogp.apps/
* http://bitbucket.org/enus_linden/pyogp.lib.base/
* http://bitbucket.org/enus_linden/pyogp.lib.client/

Needs updates to work:
* http://bitbucket.org/enus_linden/pyogp.buildout/

Defunct until someone picks them up and fixes them:
* http://bitbucket.org/enus_linden/pyogp.interop/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/

== Browse the Code ==

If all you want to do is glance at the source code, use the bitbucket source browser:
* http://bitbucket.org/enus_linden/pyogp.apps/src/
* http://bitbucket.org/enus_linden/pyogp.buildout/src/
* http://bitbucket.org/enus_linden/pyogp.interop/src/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/src/
* http://bitbucket.org/enus_linden/pyogp.lib.base/src/
* http://bitbucket.org/enus_linden/pyogp.lib.client/src/

== Prerequisites ==

You must have the following installed:
* Mercurial - 1.3 or greater
* Python 2.4.4, 2.5.x (fails on 2.6 currently and untested on 3.0)
* pyopenssl http://sourceforge.net/projects/pyopenssl/files/pyopenssl-win/0.8a1/pyOpenSSL-0.8a1.winxp32-py2.5.msi/download (Windows 32-bit)

'''Note:''' Snow Leopard upgrades require a reinstall of XCode, in this case to accommodate gcc (and greenlet).

'''Note:''' Buildout does not yet support subversion 1.6, only 1.4.4-1.5.x.

== Environment Preparation ==

'''Setuptools''' and '''easy_install''' are Python standard means for installing modules. For more info, start here: http://pypi.python.org/pypi/setuptools.

'''Virtualenv''' is a method which allows you to create isolated Python environments, separate from your base install if you so prefer. For more, see here: http://pypi.python.org/pypi/virtualenv.

Your distribution may have Python's '''setuptools''' and '''virtualenv''' packages in its package repository. If so, it is probably best to use your normal package installation procedures (see below for information on specific Linux distributions). If the packages are not available then follow these generic instructions.

=== Generic *nix distribution ===
In order to install Python Packages and creating a development sandbox you have to do the following:

==== easy_install ====

Download ez_setup.py and run it with your Python interpreter. You can find it here: http://peak.telecommunity.com/dist/ez_setup.py

Eventually you have to be root to do this depending on your system (mostly non-windows). It should look like this on a unix based machine:

wget http://peak.telecommunity.com/dist/ez_setup.py
sudo python ez_setup.py

==== virtualenv ====

One may choose to create an isolated python instance on your host, to be able to work with PyOGP without installing packages to your base Python install on your host.

To use a dedicated python installation in your host, install virtualenv like this:

easy_install virtualenv

Or, if you need to be root something like this:

sudo easy_install virtualenv

On windows, you may need a different path to easy_install

c:\Python25\Scripts\easy_install.exe virtualenv

== Install methods ==

Python modules can be installed in a variety of ways...

=== Install Method 1: buildout [Defunct] ===

We use zc.buildout to automatically setup a development environment. buildout gives you the ability to install packages only locally instead of your global python installation. It's sort of a local python installation which helps you avoiding version conflicts of packages.

1. First check out the buildout into a directory of your choice:

svn co http://svn.secondlife.com/svn/linden/projects/2008/pyogp/buildouts/libdev/trunk/ libdev

2. '''(Optional)''' Now turn this directory into a virtual python environment which is independent of your normal Python installation:

cd libdev
virtualenv . --no-site-packages

on windows, you may need to specify the path

c:\Python25\Scripts\virtualenv.exe . --no-site-packages

3. Now run the bootstrap.py file with the newly created local Python interpreter (if installed. If not, use your system's python.):

bin/python bootstrap.py

or on Windows:

Scripts\python bootstrap.py

4. This creates a bunch of directories and the bin/buildout script (bin\buildout.exe on windows). We now run this:

bin/buildout -v

or on Windows:

bin\buildout.exe -v

5. The development sandbox is ready. There now is a bin/pyogp which is a python interpreter which contains all the installed packaged and the pyogp library and related projects.

6. Test the buildout installation. To test this installation you can (at least at this stage of the project) try the following:

bin/region_connect <firstname> <lastname>

Give your Avatar name and it will ask for a password. Then it tries to login to the Preview Grid.

=== Install Method 2: setup.py ===

How to check out packages and using them independently of buildout.

If you are comfortable, feel free to use setup.py (with or without a dedicated virtualenv) in any of the following repos:

: hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.apps/
: hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.base/
: hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.client/

Each of the repos already has eggs embedded, and pyogp.apps has the appropriate dependency on pyogp.lib.base configured, which can be checked out and installed in isolation.

1. Check out the repository of your choice
hg clone https://enus_linden@bitbucket.org/enus_linden/{pyogp package}/

2. Run setup.py
cd <your pyogp dir>
python setup.py install

== Run the tests ==

See [[PyOGP_Client_Library#Pyogp_Unit_Tests]] for details...

== The structure of the sandbox ==

You now might wonder what all those directories are good for. To learn more about this check out the [[Pyogp/Filesystem_Structure|Filesystem Structure]]

[[Category: Pyogp_Client_Lib]]

PyOGP Client Library Development Sandbox

2009-12-03T23:49:05Z

Enus Linden: /* Install Method 1: buildout [Defunct] */

{{PyOGP/navigation}}
We will first run down the general explanation and add platform specific notes later.

== Note ==

We're migrating to [[Mercurial_repositories|Mercurial]]... Please check back soon for updated docs.

PyOGP package install instructions need some work... stay tuned. Feel free to follow the buildout directions to use the Subversion repositories for now.

=== Repositories ===

Need some work before they are ready as installed packages. In the meantime, just add the path to "pyogp.{package}" to your PYTHONPATH to use the libs, assuming you have the other dependencies.
* http://bitbucket.org/enus_linden/pyogp.apps/
* http://bitbucket.org/enus_linden/pyogp.lib.base/
* http://bitbucket.org/enus_linden/pyogp.lib.client/

Needs updates to work:
* http://bitbucket.org/enus_linden/pyogp.buildout/

Defunct until someone picks them up and fixes them:
* http://bitbucket.org/enus_linden/pyogp.interop/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/

== Browse the Code ==

If all you want to do is glance at the source code, use the bitbucket source browser:
* http://bitbucket.org/enus_linden/pyogp.apps/src/
* http://bitbucket.org/enus_linden/pyogp.buildout/src/
* http://bitbucket.org/enus_linden/pyogp.interop/src/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/src/
* http://bitbucket.org/enus_linden/pyogp.lib.base/src/
* http://bitbucket.org/enus_linden/pyogp.lib.client/src/

== Prerequisites ==

You must have the following installed:
* Mercurial - 1.3 or greater
* Python 2.4.4, 2.5.x (fails on 2.6 currently and untested on 3.0)
* pyopenssl http://sourceforge.net/projects/pyopenssl/files/pyopenssl-win/0.8a1/pyOpenSSL-0.8a1.winxp32-py2.5.msi/download (Windows 32-bit)

'''Note:''' Snow Leopard upgrades require a reinstall of XCode, in this case to accommodate gcc (and greenlet).

'''Note:''' Buildout does not yet support subversion 1.6, only 1.4.4-1.5.x.

== Environment Preparation ==

'''Setuptools''' and '''easy_install''' are Python standard means for installing modules. For more info, start here: http://pypi.python.org/pypi/setuptools.

'''Virtualenv''' is a method which allows you to create isolated Python environments, separate from your base install if you so prefer. For more, see here: http://pypi.python.org/pypi/virtualenv.

Your distribution may have Python's '''setuptools''' and '''virtualenv''' packages in its package repository. If so, it is probably best to use your normal package installation procedures (see below for information on specific Linux distributions). If the packages are not available then follow these generic instructions.

=== Generic *nix distribution ===
In order to install Python Packages and creating a development sandbox you have to do the following:

==== easy_install ====

Download ez_setup.py and run it with your Python interpreter. You can find it here: http://peak.telecommunity.com/dist/ez_setup.py

Eventually you have to be root to do this depending on your system (mostly non-windows). It should look like this on a unix based machine:

wget http://peak.telecommunity.com/dist/ez_setup.py
sudo python ez_setup.py

==== virtualenv ====

One may choose to create an isolated python instance on your host, to be able to work with PyOGP without installing packages to your base Python install on your host.

To use a dedicated python installation in your host, install virtualenv like this:

easy_install virtualenv

Or, if you need to be root something like this:

sudo easy_install virtualenv

On windows, you may need a different path to easy_install

c:\Python25\Scripts\easy_install.exe virtualenv

== Install methods ==

Python modules can be installed in a variety of ways...

=== Install Method 1: buildout [Defunct] ===

We use zc.buildout to automatically setup a development environment. buildout gives you the ability to install packages only locally instead of your global python installation. It's sort of a local python installation which helps you avoiding version conflicts of packages.

1. First check out the buildout into a directory of your choice:

svn co http://svn.secondlife.com/svn/linden/projects/2008/pyogp/buildouts/libdev/trunk/ libdev

2. '''(Optional)''' Now turn this directory into a virtual python environment which is independent of your normal Python installation:

cd libdev
virtualenv . --no-site-packages

on windows, you may need to specify the path

c:\Python25\Scripts\virtualenv.exe . --no-site-packages

3. Now run the bootstrap.py file with the newly created local Python interpreter (if installed. If not, use your system's python.):

bin/python bootstrap.py

or on Windows:

Scripts\python bootstrap.py

4. This creates a bunch of directories and the bin/buildout script (bin\buildout.exe on windows). We now run this:

bin/buildout -v

or on Windows:

bin\buildout.exe -v

5. The development sandbox is ready. There now is a bin/pyogp which is a python interpreter which contains all the installed packaged and the pyogp library and related projects.

6. Test the buildout installation. To test this installation you can (at least at this stage of the project) try the following:

bin/region_connect <firstname> <lastname>

Give your Avatar name and it will ask for a password. Then it tries to login to the Preview Grid.

=== Install Method 2: setup.py ===

How to check out packages and using them independently of buildout.

If you are comfortable, feel free to use setup.py (with or without a dedicated virtualenv) in any of the following repos:

: hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.apps/
: hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.base/
: hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.client/

Each of the repos already has eggs embedded, and pyogp.apps has the appropriate dependency on pyogp.lib.base configured, which can be checked out and installed in isolation.

1. Check out the repository of your choice
hg clone https://enus_linden@bitbucket.org/enus_linden/{pyogp package}/

2. Run setup.py
cd <your pyogp dir>
python setup.py

== Run the tests ==

See [[PyOGP_Client_Library#Pyogp_Unit_Tests]] for details...

== The structure of the sandbox ==

You now might wonder what all those directories are good for. To learn more about this check out the [[Pyogp/Filesystem_Structure|Filesystem Structure]]

[[Category: Pyogp_Client_Lib]]

PyOGP Client Library Development Sandbox

2009-12-03T23:48:23Z

Enus Linden: /* Install Method 2: setup.py */

{{PyOGP/navigation}}
We will first run down the general explanation and add platform specific notes later.

== Note ==

We're migrating to [[Mercurial_repositories|Mercurial]]... Please check back soon for updated docs.

PyOGP package install instructions need some work... stay tuned. Feel free to follow the buildout directions to use the Subversion repositories for now.

=== Repositories ===

Need some work before they are ready as installed packages. In the meantime, just add the path to "pyogp.{package}" to your PYTHONPATH to use the libs, assuming you have the other dependencies.
* http://bitbucket.org/enus_linden/pyogp.apps/
* http://bitbucket.org/enus_linden/pyogp.lib.base/
* http://bitbucket.org/enus_linden/pyogp.lib.client/

Needs updates to work:
* http://bitbucket.org/enus_linden/pyogp.buildout/

Defunct until someone picks them up and fixes them:
* http://bitbucket.org/enus_linden/pyogp.interop/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/

== Browse the Code ==

If all you want to do is glance at the source code, use the bitbucket source browser:
* http://bitbucket.org/enus_linden/pyogp.apps/src/
* http://bitbucket.org/enus_linden/pyogp.buildout/src/
* http://bitbucket.org/enus_linden/pyogp.interop/src/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/src/
* http://bitbucket.org/enus_linden/pyogp.lib.base/src/
* http://bitbucket.org/enus_linden/pyogp.lib.client/src/

== Prerequisites ==

You must have the following installed:
* Mercurial - 1.3 or greater
* Python 2.4.4, 2.5.x (fails on 2.6 currently and untested on 3.0)
* pyopenssl http://sourceforge.net/projects/pyopenssl/files/pyopenssl-win/0.8a1/pyOpenSSL-0.8a1.winxp32-py2.5.msi/download (Windows 32-bit)

'''Note:''' Snow Leopard upgrades require a reinstall of XCode, in this case to accommodate gcc (and greenlet).

'''Note:''' Buildout does not yet support subversion 1.6, only 1.4.4-1.5.x.

== Environment Preparation ==

'''Setuptools''' and '''easy_install''' are Python standard means for installing modules. For more info, start here: http://pypi.python.org/pypi/setuptools.

'''Virtualenv''' is a method which allows you to create isolated Python environments, separate from your base install if you so prefer. For more, see here: http://pypi.python.org/pypi/virtualenv.

Your distribution may have Python's '''setuptools''' and '''virtualenv''' packages in its package repository. If so, it is probably best to use your normal package installation procedures (see below for information on specific Linux distributions). If the packages are not available then follow these generic instructions.

=== Generic *nix distribution ===
In order to install Python Packages and creating a development sandbox you have to do the following:

==== easy_install ====

Download ez_setup.py and run it with your Python interpreter. You can find it here: http://peak.telecommunity.com/dist/ez_setup.py

Eventually you have to be root to do this depending on your system (mostly non-windows). It should look like this on a unix based machine:

wget http://peak.telecommunity.com/dist/ez_setup.py
sudo python ez_setup.py

==== virtualenv ====

One may choose to create an isolated python instance on your host, to be able to work with PyOGP without installing packages to your base Python install on your host.

To use a dedicated python installation in your host, install virtualenv like this:

easy_install virtualenv

Or, if you need to be root something like this:

sudo easy_install virtualenv

On windows, you may need a different path to easy_install

c:\Python25\Scripts\easy_install.exe virtualenv

== Install methods ==

Python modules can be installed in a variety of ways...

=== Install Method 1: buildout [Defunct] ===

We use zc.buildout to automatically setup a development environment. buildout gives you the ability to install packages only locally instead of your global python installation. It's sort of a local python installation which helps you avoiding version conflicts of packages.

1. First check out the buildout into a directory of your choice:

svn co http://svn.secondlife.com/svn/linden/projects/2008/pyogp/buildouts/libdev/trunk/ libdev

For those who are interested, tagged and stable version of buildout (with pinned versions on externals) is available at https://svn.secondlife.com/svn/linden/projects/2008/pyogp/buildouts/libdev/tags/0.1/.

2. '''(Optional)''' Now turn this directory into a virtual python environment which is independent of your normal Python installation:

cd libdev
virtualenv . --no-site-packages

on windows, you may need to specify the path

c:\Python25\Scripts\virtualenv.exe . --no-site-packages

3. Now run the bootstrap.py file with the newly created local Python interpreter (if installed. If not, use your system's python.):

bin/python bootstrap.py

or on Windows:

Scripts\python bootstrap.py

4. This creates a bunch of directories and the bin/buildout script (bin\buildout.exe on windows). We now run this:

bin/buildout -v

or on Windows:

bin\buildout.exe -v

5. The development sandbox is ready. There now is a bin/pyogp which is a python interpreter which contains all the installed packaged and the pyogp library and related projects.

6. Test the buildout installation. To test this installation you can (at least at this stage of the project) try the following:

bin/region_connect <firstname> <lastname>

Give your Avatar name and it will ask for a password. Then it tries to login to the Preview Grid.

=== Install Method 2: setup.py ===

How to check out packages and using them independently of buildout.

If you are comfortable, feel free to use setup.py (with or without a dedicated virtualenv) in any of the following repos:

: hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.apps/
: hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.base/
: hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.client/

Each of the repos already has eggs embedded, and pyogp.apps has the appropriate dependency on pyogp.lib.base configured, which can be checked out and installed in isolation.

1. Check out the repository of your choice
hg clone https://enus_linden@bitbucket.org/enus_linden/{pyogp package}/

2. Run setup.py
cd <your pyogp dir>
python setup.py

== Run the tests ==

See [[PyOGP_Client_Library#Pyogp_Unit_Tests]] for details...

== The structure of the sandbox ==

You now might wonder what all those directories are good for. To learn more about this check out the [[Pyogp/Filesystem_Structure|Filesystem Structure]]

[[Category: Pyogp_Client_Lib]]

PyOGP Client Library Development Sandbox

2009-12-03T23:47:39Z

Enus Linden: /* Repositories */

{{PyOGP/navigation}}
We will first run down the general explanation and add platform specific notes later.

== Note ==

We're migrating to [[Mercurial_repositories|Mercurial]]... Please check back soon for updated docs.

PyOGP package install instructions need some work... stay tuned. Feel free to follow the buildout directions to use the Subversion repositories for now.

=== Repositories ===

Need some work before they are ready as installed packages. In the meantime, just add the path to "pyogp.{package}" to your PYTHONPATH to use the libs, assuming you have the other dependencies.
* http://bitbucket.org/enus_linden/pyogp.apps/
* http://bitbucket.org/enus_linden/pyogp.lib.base/
* http://bitbucket.org/enus_linden/pyogp.lib.client/

Needs updates to work:
* http://bitbucket.org/enus_linden/pyogp.buildout/

Defunct until someone picks them up and fixes them:
* http://bitbucket.org/enus_linden/pyogp.interop/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/

== Browse the Code ==

If all you want to do is glance at the source code, use the bitbucket source browser:
* http://bitbucket.org/enus_linden/pyogp.apps/src/
* http://bitbucket.org/enus_linden/pyogp.buildout/src/
* http://bitbucket.org/enus_linden/pyogp.interop/src/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/src/
* http://bitbucket.org/enus_linden/pyogp.lib.base/src/
* http://bitbucket.org/enus_linden/pyogp.lib.client/src/

== Prerequisites ==

You must have the following installed:
* Mercurial - 1.3 or greater
* Python 2.4.4, 2.5.x (fails on 2.6 currently and untested on 3.0)
* pyopenssl http://sourceforge.net/projects/pyopenssl/files/pyopenssl-win/0.8a1/pyOpenSSL-0.8a1.winxp32-py2.5.msi/download (Windows 32-bit)

'''Note:''' Snow Leopard upgrades require a reinstall of XCode, in this case to accommodate gcc (and greenlet).

'''Note:''' Buildout does not yet support subversion 1.6, only 1.4.4-1.5.x.

== Environment Preparation ==

'''Setuptools''' and '''easy_install''' are Python standard means for installing modules. For more info, start here: http://pypi.python.org/pypi/setuptools.

'''Virtualenv''' is a method which allows you to create isolated Python environments, separate from your base install if you so prefer. For more, see here: http://pypi.python.org/pypi/virtualenv.

Your distribution may have Python's '''setuptools''' and '''virtualenv''' packages in its package repository. If so, it is probably best to use your normal package installation procedures (see below for information on specific Linux distributions). If the packages are not available then follow these generic instructions.

=== Generic *nix distribution ===
In order to install Python Packages and creating a development sandbox you have to do the following:

==== easy_install ====

Download ez_setup.py and run it with your Python interpreter. You can find it here: http://peak.telecommunity.com/dist/ez_setup.py

Eventually you have to be root to do this depending on your system (mostly non-windows). It should look like this on a unix based machine:

wget http://peak.telecommunity.com/dist/ez_setup.py
sudo python ez_setup.py

==== virtualenv ====

One may choose to create an isolated python instance on your host, to be able to work with PyOGP without installing packages to your base Python install on your host.

To use a dedicated python installation in your host, install virtualenv like this:

easy_install virtualenv

Or, if you need to be root something like this:

sudo easy_install virtualenv

On windows, you may need a different path to easy_install

c:\Python25\Scripts\easy_install.exe virtualenv

== Install methods ==

Python modules can be installed in a variety of ways...

=== Install Method 1: buildout [Defunct] ===

We use zc.buildout to automatically setup a development environment. buildout gives you the ability to install packages only locally instead of your global python installation. It's sort of a local python installation which helps you avoiding version conflicts of packages.

1. First check out the buildout into a directory of your choice:

svn co http://svn.secondlife.com/svn/linden/projects/2008/pyogp/buildouts/libdev/trunk/ libdev

For those who are interested, tagged and stable version of buildout (with pinned versions on externals) is available at https://svn.secondlife.com/svn/linden/projects/2008/pyogp/buildouts/libdev/tags/0.1/.

2. '''(Optional)''' Now turn this directory into a virtual python environment which is independent of your normal Python installation:

cd libdev
virtualenv . --no-site-packages

on windows, you may need to specify the path

c:\Python25\Scripts\virtualenv.exe . --no-site-packages

3. Now run the bootstrap.py file with the newly created local Python interpreter (if installed. If not, use your system's python.):

bin/python bootstrap.py

or on Windows:

Scripts\python bootstrap.py

4. This creates a bunch of directories and the bin/buildout script (bin\buildout.exe on windows). We now run this:

bin/buildout -v

or on Windows:

bin\buildout.exe -v

5. The development sandbox is ready. There now is a bin/pyogp which is a python interpreter which contains all the installed packaged and the pyogp library and related projects.

6. Test the buildout installation. To test this installation you can (at least at this stage of the project) try the following:

bin/region_connect <firstname> <lastname>

Give your Avatar name and it will ask for a password. Then it tries to login to the Preview Grid.

=== Install Method 2: setup.py ===

How to check out packages and using them independently of buildout.

If you are comfortable, feel free to use setup.py (with or without a dedicated virtualenv) in any of the following repos:

: hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.apps/
: hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.base/
: hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.client/

Each of the repos already has eggs embedded, and pyogp.apps has the appropriate dependency on pyogp.lib.base configured, which can be checked out and installed in isolation.

1. Check out the repository of your choice
svn co https://svn.secondlife.com/svn/linden/projects/2008/pyogp/<the repo you wanted>/trunk <your pyogp dir>

2. Run setup.py
cd <your pyogp dir>
python setup.py

== Run the tests ==

See [[PyOGP_Client_Library#Pyogp_Unit_Tests]] for details...

== The structure of the sandbox ==

You now might wonder what all those directories are good for. To learn more about this check out the [[Pyogp/Filesystem_Structure|Filesystem Structure]]

[[Category: Pyogp_Client_Lib]]

PyOGP Client Library Development Sandbox

2009-12-03T23:47:15Z

Enus Linden: /* Repositories */

{{PyOGP/navigation}}
We will first run down the general explanation and add platform specific notes later.

== Note ==

We're migrating to [[Mercurial_repositories|Mercurial]]... Please check back soon for updated docs.

PyOGP package install instructions need some work... stay tuned. Feel free to follow the buildout directions to use the Subversion repositories for now.

=== Repositories ===

Need some work before they are ready as installed packages. In the meantime, just add the path to "pyogp.{package} to your PYTHONPATH to use the libs.
* http://bitbucket.org/enus_linden/pyogp.apps/
* http://bitbucket.org/enus_linden/pyogp.lib.base/
* http://bitbucket.org/enus_linden/pyogp.lib.client/

Needs updates to work:
* http://bitbucket.org/enus_linden/pyogp.buildout/

Defunct until someone picks them up and fixes them:
* http://bitbucket.org/enus_linden/pyogp.interop/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/

== Browse the Code ==

If all you want to do is glance at the source code, use the bitbucket source browser:
* http://bitbucket.org/enus_linden/pyogp.apps/src/
* http://bitbucket.org/enus_linden/pyogp.buildout/src/
* http://bitbucket.org/enus_linden/pyogp.interop/src/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/src/
* http://bitbucket.org/enus_linden/pyogp.lib.base/src/
* http://bitbucket.org/enus_linden/pyogp.lib.client/src/

== Prerequisites ==

You must have the following installed:
* Mercurial - 1.3 or greater
* Python 2.4.4, 2.5.x (fails on 2.6 currently and untested on 3.0)
* pyopenssl http://sourceforge.net/projects/pyopenssl/files/pyopenssl-win/0.8a1/pyOpenSSL-0.8a1.winxp32-py2.5.msi/download (Windows 32-bit)

'''Note:''' Snow Leopard upgrades require a reinstall of XCode, in this case to accommodate gcc (and greenlet).

'''Note:''' Buildout does not yet support subversion 1.6, only 1.4.4-1.5.x.

== Environment Preparation ==

'''Setuptools''' and '''easy_install''' are Python standard means for installing modules. For more info, start here: http://pypi.python.org/pypi/setuptools.

'''Virtualenv''' is a method which allows you to create isolated Python environments, separate from your base install if you so prefer. For more, see here: http://pypi.python.org/pypi/virtualenv.

Your distribution may have Python's '''setuptools''' and '''virtualenv''' packages in its package repository. If so, it is probably best to use your normal package installation procedures (see below for information on specific Linux distributions). If the packages are not available then follow these generic instructions.

=== Generic *nix distribution ===
In order to install Python Packages and creating a development sandbox you have to do the following:

==== easy_install ====

Download ez_setup.py and run it with your Python interpreter. You can find it here: http://peak.telecommunity.com/dist/ez_setup.py

Eventually you have to be root to do this depending on your system (mostly non-windows). It should look like this on a unix based machine:

wget http://peak.telecommunity.com/dist/ez_setup.py
sudo python ez_setup.py

==== virtualenv ====

One may choose to create an isolated python instance on your host, to be able to work with PyOGP without installing packages to your base Python install on your host.

To use a dedicated python installation in your host, install virtualenv like this:

easy_install virtualenv

Or, if you need to be root something like this:

sudo easy_install virtualenv

On windows, you may need a different path to easy_install

c:\Python25\Scripts\easy_install.exe virtualenv

== Install methods ==

Python modules can be installed in a variety of ways...

=== Install Method 1: buildout [Defunct] ===

We use zc.buildout to automatically setup a development environment. buildout gives you the ability to install packages only locally instead of your global python installation. It's sort of a local python installation which helps you avoiding version conflicts of packages.

1. First check out the buildout into a directory of your choice:

svn co http://svn.secondlife.com/svn/linden/projects/2008/pyogp/buildouts/libdev/trunk/ libdev

For those who are interested, tagged and stable version of buildout (with pinned versions on externals) is available at https://svn.secondlife.com/svn/linden/projects/2008/pyogp/buildouts/libdev/tags/0.1/.

2. '''(Optional)''' Now turn this directory into a virtual python environment which is independent of your normal Python installation:

cd libdev
virtualenv . --no-site-packages

on windows, you may need to specify the path

c:\Python25\Scripts\virtualenv.exe . --no-site-packages

3. Now run the bootstrap.py file with the newly created local Python interpreter (if installed. If not, use your system's python.):

bin/python bootstrap.py

or on Windows:

Scripts\python bootstrap.py

4. This creates a bunch of directories and the bin/buildout script (bin\buildout.exe on windows). We now run this:

bin/buildout -v

or on Windows:

bin\buildout.exe -v

5. The development sandbox is ready. There now is a bin/pyogp which is a python interpreter which contains all the installed packaged and the pyogp library and related projects.

6. Test the buildout installation. To test this installation you can (at least at this stage of the project) try the following:

bin/region_connect <firstname> <lastname>

Give your Avatar name and it will ask for a password. Then it tries to login to the Preview Grid.

=== Install Method 2: setup.py ===

How to check out packages and using them independently of buildout.

If you are comfortable, feel free to use setup.py (with or without a dedicated virtualenv) in any of the following repos:

: hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.apps/
: hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.base/
: hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.client/

Each of the repos already has eggs embedded, and pyogp.apps has the appropriate dependency on pyogp.lib.base configured, which can be checked out and installed in isolation.

1. Check out the repository of your choice
svn co https://svn.secondlife.com/svn/linden/projects/2008/pyogp/<the repo you wanted>/trunk <your pyogp dir>

2. Run setup.py
cd <your pyogp dir>
python setup.py

== Run the tests ==

See [[PyOGP_Client_Library#Pyogp_Unit_Tests]] for details...

== The structure of the sandbox ==

You now might wonder what all those directories are good for. To learn more about this check out the [[Pyogp/Filesystem_Structure|Filesystem Structure]]

[[Category: Pyogp_Client_Lib]]

PyOGP Client Library Development Sandbox

2009-12-03T23:46:25Z

Enus Linden: /* Note */

{{PyOGP/navigation}}
We will first run down the general explanation and add platform specific notes later.

== Note ==

We're migrating to [[Mercurial_repositories|Mercurial]]... Please check back soon for updated docs.

PyOGP package install instructions need some work... stay tuned. Feel free to follow the buildout directions to use the Subversion repositories for now.

=== Repositories ===

Should work just fine as installed packages:
* http://bitbucket.org/enus_linden/pyogp.apps/
* http://bitbucket.org/enus_linden/pyogp.lib.base/
* http://bitbucket.org/enus_linden/pyogp.lib.client/

Needs updates to work:
* http://bitbucket.org/enus_linden/pyogp.buildout/

Defunct until someone picks them up and fixes them:
* http://bitbucket.org/enus_linden/pyogp.interop/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/

== Browse the Code ==

If all you want to do is glance at the source code, use the bitbucket source browser:
* http://bitbucket.org/enus_linden/pyogp.apps/src/
* http://bitbucket.org/enus_linden/pyogp.buildout/src/
* http://bitbucket.org/enus_linden/pyogp.interop/src/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/src/
* http://bitbucket.org/enus_linden/pyogp.lib.base/src/
* http://bitbucket.org/enus_linden/pyogp.lib.client/src/

== Prerequisites ==

You must have the following installed:
* Mercurial - 1.3 or greater
* Python 2.4.4, 2.5.x (fails on 2.6 currently and untested on 3.0)
* pyopenssl http://sourceforge.net/projects/pyopenssl/files/pyopenssl-win/0.8a1/pyOpenSSL-0.8a1.winxp32-py2.5.msi/download (Windows 32-bit)

'''Note:''' Snow Leopard upgrades require a reinstall of XCode, in this case to accommodate gcc (and greenlet).

'''Note:''' Buildout does not yet support subversion 1.6, only 1.4.4-1.5.x.

== Environment Preparation ==

'''Setuptools''' and '''easy_install''' are Python standard means for installing modules. For more info, start here: http://pypi.python.org/pypi/setuptools.

'''Virtualenv''' is a method which allows you to create isolated Python environments, separate from your base install if you so prefer. For more, see here: http://pypi.python.org/pypi/virtualenv.

Your distribution may have Python's '''setuptools''' and '''virtualenv''' packages in its package repository. If so, it is probably best to use your normal package installation procedures (see below for information on specific Linux distributions). If the packages are not available then follow these generic instructions.

=== Generic *nix distribution ===
In order to install Python Packages and creating a development sandbox you have to do the following:

==== easy_install ====

Download ez_setup.py and run it with your Python interpreter. You can find it here: http://peak.telecommunity.com/dist/ez_setup.py

Eventually you have to be root to do this depending on your system (mostly non-windows). It should look like this on a unix based machine:

wget http://peak.telecommunity.com/dist/ez_setup.py
sudo python ez_setup.py

==== virtualenv ====

One may choose to create an isolated python instance on your host, to be able to work with PyOGP without installing packages to your base Python install on your host.

To use a dedicated python installation in your host, install virtualenv like this:

easy_install virtualenv

Or, if you need to be root something like this:

sudo easy_install virtualenv

On windows, you may need a different path to easy_install

c:\Python25\Scripts\easy_install.exe virtualenv

== Install methods ==

Python modules can be installed in a variety of ways...

=== Install Method 1: buildout [Defunct] ===

We use zc.buildout to automatically setup a development environment. buildout gives you the ability to install packages only locally instead of your global python installation. It's sort of a local python installation which helps you avoiding version conflicts of packages.

1. First check out the buildout into a directory of your choice:

svn co http://svn.secondlife.com/svn/linden/projects/2008/pyogp/buildouts/libdev/trunk/ libdev

For those who are interested, tagged and stable version of buildout (with pinned versions on externals) is available at https://svn.secondlife.com/svn/linden/projects/2008/pyogp/buildouts/libdev/tags/0.1/.

2. '''(Optional)''' Now turn this directory into a virtual python environment which is independent of your normal Python installation:

cd libdev
virtualenv . --no-site-packages

on windows, you may need to specify the path

c:\Python25\Scripts\virtualenv.exe . --no-site-packages

3. Now run the bootstrap.py file with the newly created local Python interpreter (if installed. If not, use your system's python.):

bin/python bootstrap.py

or on Windows:

Scripts\python bootstrap.py

4. This creates a bunch of directories and the bin/buildout script (bin\buildout.exe on windows). We now run this:

bin/buildout -v

or on Windows:

bin\buildout.exe -v

5. The development sandbox is ready. There now is a bin/pyogp which is a python interpreter which contains all the installed packaged and the pyogp library and related projects.

6. Test the buildout installation. To test this installation you can (at least at this stage of the project) try the following:

bin/region_connect <firstname> <lastname>

Give your Avatar name and it will ask for a password. Then it tries to login to the Preview Grid.

=== Install Method 2: setup.py ===

How to check out packages and using them independently of buildout.

If you are comfortable, feel free to use setup.py (with or without a dedicated virtualenv) in any of the following repos:

: hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.apps/
: hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.base/
: hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.client/

Each of the repos already has eggs embedded, and pyogp.apps has the appropriate dependency on pyogp.lib.base configured, which can be checked out and installed in isolation.

1. Check out the repository of your choice
svn co https://svn.secondlife.com/svn/linden/projects/2008/pyogp/<the repo you wanted>/trunk <your pyogp dir>

2. Run setup.py
cd <your pyogp dir>
python setup.py

== Run the tests ==

See [[PyOGP_Client_Library#Pyogp_Unit_Tests]] for details...

== The structure of the sandbox ==

You now might wonder what all those directories are good for. To learn more about this check out the [[Pyogp/Filesystem_Structure|Filesystem Structure]]

[[Category: Pyogp_Client_Lib]]

PyOGP Client Library Development Sandbox

2009-12-03T21:56:03Z

Enus Linden: /* Note */

{{PyOGP/navigation}}
We will first run down the general explanation and add platform specific notes later.

== Note ==

We're migrating to Mercurial... Please check back soon for updated docs.

Feel free t follow the buildout and Subversion related directions below for now...

=== Repositories ===

Should work just fine as installed packages:
* http://bitbucket.org/enus_linden/pyogp.apps/
* http://bitbucket.org/enus_linden/pyogp.lib.base/
* http://bitbucket.org/enus_linden/pyogp.lib.client/

Needs updates to work:
* http://bitbucket.org/enus_linden/pyogp.buildout/

Defunct until someone picks them up and fixes them:
* http://bitbucket.org/enus_linden/pyogp.interop/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/

== Browse the Code ==

If all you want to do is glance at the source code, use the bitbucket source browser:
* http://bitbucket.org/enus_linden/pyogp.apps/src/
* http://bitbucket.org/enus_linden/pyogp.buildout/src/
* http://bitbucket.org/enus_linden/pyogp.interop/src/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/src/
* http://bitbucket.org/enus_linden/pyogp.lib.base/src/
* http://bitbucket.org/enus_linden/pyogp.lib.client/src/

== Prerequisites ==

You must have the following installed:
* Mercurial - 1.3 or greater
* Python 2.4.4, 2.5.x (fails on 2.6 currently and untested on 3.0)
* pyopenssl http://sourceforge.net/projects/pyopenssl/files/pyopenssl-win/0.8a1/pyOpenSSL-0.8a1.winxp32-py2.5.msi/download (Windows 32-bit)

'''Note:''' Snow Leopard upgrades require a reinstall of XCode, in this case to accommodate gcc (and greenlet).

'''Note:''' Buildout does not yet support subversion 1.6, only 1.4.4-1.5.x.

== Environment Preparation ==

'''Setuptools''' and '''easy_install''' are Python standard means for installing modules. For more info, start here: http://pypi.python.org/pypi/setuptools.

'''Virtualenv''' is a method which allows you to create isolated Python environments, separate from your base install if you so prefer. For more, see here: http://pypi.python.org/pypi/virtualenv.

Your distribution may have Python's '''setuptools''' and '''virtualenv''' packages in its package repository. If so, it is probably best to use your normal package installation procedures (see below for information on specific Linux distributions). If the packages are not available then follow these generic instructions.

=== Generic *nix distribution ===
In order to install Python Packages and creating a development sandbox you have to do the following:

==== easy_install ====

Download ez_setup.py and run it with your Python interpreter. You can find it here: http://peak.telecommunity.com/dist/ez_setup.py

Eventually you have to be root to do this depending on your system (mostly non-windows). It should look like this on a unix based machine:

wget http://peak.telecommunity.com/dist/ez_setup.py
sudo python ez_setup.py

==== virtualenv ====

One may choose to create an isolated python instance on your host, to be able to work with PyOGP without installing packages to your base Python install on your host.

To use a dedicated python installation in your host, install virtualenv like this:

easy_install virtualenv

Or, if you need to be root something like this:

sudo easy_install virtualenv

On windows, you may need a different path to easy_install

c:\Python25\Scripts\easy_install.exe virtualenv

== Install methods ==

Python modules can be installed in a variety of ways...

=== Install Method 1: buildout [Defunct] ===

We use zc.buildout to automatically setup a development environment. buildout gives you the ability to install packages only locally instead of your global python installation. It's sort of a local python installation which helps you avoiding version conflicts of packages.

1. First check out the buildout into a directory of your choice:

svn co http://svn.secondlife.com/svn/linden/projects/2008/pyogp/buildouts/libdev/trunk/ libdev

For those who are interested, tagged and stable version of buildout (with pinned versions on externals) is available at https://svn.secondlife.com/svn/linden/projects/2008/pyogp/buildouts/libdev/tags/0.1/.

2. '''(Optional)''' Now turn this directory into a virtual python environment which is independent of your normal Python installation:

cd libdev
virtualenv . --no-site-packages

on windows, you may need to specify the path

c:\Python25\Scripts\virtualenv.exe . --no-site-packages

3. Now run the bootstrap.py file with the newly created local Python interpreter (if installed. If not, use your system's python.):

bin/python bootstrap.py

or on Windows:

Scripts\python bootstrap.py

4. This creates a bunch of directories and the bin/buildout script (bin\buildout.exe on windows). We now run this:

bin/buildout -v

or on Windows:

bin\buildout.exe -v

5. The development sandbox is ready. There now is a bin/pyogp which is a python interpreter which contains all the installed packaged and the pyogp library and related projects.

6. Test the buildout installation. To test this installation you can (at least at this stage of the project) try the following:

bin/region_connect <firstname> <lastname>

Give your Avatar name and it will ask for a password. Then it tries to login to the Preview Grid.

=== Install Method 2: setup.py ===

How to check out packages and using them independently of buildout.

If you are comfortable, feel free to use setup.py (with or without a dedicated virtualenv) in any of the following repos:

: hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.apps/
: hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.base/
: hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.client/

Each of the repos already has eggs embedded, and pyogp.apps has the appropriate dependency on pyogp.lib.base configured, which can be checked out and installed in isolation.

1. Check out the repository of your choice
svn co https://svn.secondlife.com/svn/linden/projects/2008/pyogp/<the repo you wanted>/trunk <your pyogp dir>

2. Run setup.py
cd <your pyogp dir>
python setup.py

== Run the tests ==

See [[PyOGP_Client_Library#Pyogp_Unit_Tests]] for details...

== The structure of the sandbox ==

You now might wonder what all those directories are good for. To learn more about this check out the [[Pyogp/Filesystem_Structure|Filesystem Structure]]

[[Category: Pyogp_Client_Lib]]

PyOGP Client Library Development Sandbox

2009-12-03T21:30:14Z

Enus Linden:

{{PyOGP/navigation}}
We will first run down the general explanation and add platform specific notes later.

== Note ==

We're migrating to Mercurial... Please check back soon for updated docs.

=== Repositories ===

Should work just fine as installed packages:
* http://bitbucket.org/enus_linden/pyogp.apps/
* http://bitbucket.org/enus_linden/pyogp.lib.base/
* http://bitbucket.org/enus_linden/pyogp.lib.client/

Needs updates to work:
* http://bitbucket.org/enus_linden/pyogp.buildout/

Defunct until someone picks them up and fixes them:
* http://bitbucket.org/enus_linden/pyogp.interop/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/

== Browse the Code ==

If all you want to do is glance at the source code, use the bitbucket source browser:
* http://bitbucket.org/enus_linden/pyogp.apps/src/
* http://bitbucket.org/enus_linden/pyogp.buildout/src/
* http://bitbucket.org/enus_linden/pyogp.interop/src/
* http://bitbucket.org/enus_linden/pyogp.lib.agentdomain/src/
* http://bitbucket.org/enus_linden/pyogp.lib.base/src/
* http://bitbucket.org/enus_linden/pyogp.lib.client/src/

== Prerequisites ==

You must have the following installed:
* Mercurial - 1.3 or greater
* Python 2.4.4, 2.5.x (fails on 2.6 currently and untested on 3.0)
* pyopenssl http://sourceforge.net/projects/pyopenssl/files/pyopenssl-win/0.8a1/pyOpenSSL-0.8a1.winxp32-py2.5.msi/download (Windows 32-bit)

'''Note:''' Snow Leopard upgrades require a reinstall of XCode, in this case to accommodate gcc (and greenlet).

'''Note:''' Buildout does not yet support subversion 1.6, only 1.4.4-1.5.x.

== Environment Preparation ==

'''Setuptools''' and '''easy_install''' are Python standard means for installing modules. For more info, start here: http://pypi.python.org/pypi/setuptools.

'''Virtualenv''' is a method which allows you to create isolated Python environments, separate from your base install if you so prefer. For more, see here: http://pypi.python.org/pypi/virtualenv.

Your distribution may have Python's '''setuptools''' and '''virtualenv''' packages in its package repository. If so, it is probably best to use your normal package installation procedures (see below for information on specific Linux distributions). If the packages are not available then follow these generic instructions.

=== Generic *nix distribution ===
In order to install Python Packages and creating a development sandbox you have to do the following:

==== easy_install ====

Download ez_setup.py and run it with your Python interpreter. You can find it here: http://peak.telecommunity.com/dist/ez_setup.py

Eventually you have to be root to do this depending on your system (mostly non-windows). It should look like this on a unix based machine:

wget http://peak.telecommunity.com/dist/ez_setup.py
sudo python ez_setup.py

==== virtualenv ====

One may choose to create an isolated python instance on your host, to be able to work with PyOGP without installing packages to your base Python install on your host.

To use a dedicated python installation in your host, install virtualenv like this:

easy_install virtualenv

Or, if you need to be root something like this:

sudo easy_install virtualenv

On windows, you may need a different path to easy_install

c:\Python25\Scripts\easy_install.exe virtualenv

== Install methods ==

Python modules can be installed in a variety of ways...

=== Install Method 1: buildout [Defunct] ===

We use zc.buildout to automatically setup a development environment. buildout gives you the ability to install packages only locally instead of your global python installation. It's sort of a local python installation which helps you avoiding version conflicts of packages.

1. First check out the buildout into a directory of your choice:

svn co http://svn.secondlife.com/svn/linden/projects/2008/pyogp/buildouts/libdev/trunk/ libdev

For those who are interested, tagged and stable version of buildout (with pinned versions on externals) is available at https://svn.secondlife.com/svn/linden/projects/2008/pyogp/buildouts/libdev/tags/0.1/.

2. '''(Optional)''' Now turn this directory into a virtual python environment which is independent of your normal Python installation:

cd libdev
virtualenv . --no-site-packages

on windows, you may need to specify the path

c:\Python25\Scripts\virtualenv.exe . --no-site-packages

3. Now run the bootstrap.py file with the newly created local Python interpreter (if installed. If not, use your system's python.):

bin/python bootstrap.py

or on Windows:

Scripts\python bootstrap.py

4. This creates a bunch of directories and the bin/buildout script (bin\buildout.exe on windows). We now run this:

bin/buildout -v

or on Windows:

bin\buildout.exe -v

5. The development sandbox is ready. There now is a bin/pyogp which is a python interpreter which contains all the installed packaged and the pyogp library and related projects.

6. Test the buildout installation. To test this installation you can (at least at this stage of the project) try the following:

bin/region_connect <firstname> <lastname>

Give your Avatar name and it will ask for a password. Then it tries to login to the Preview Grid.

=== Install Method 2: setup.py ===

How to check out packages and using them independently of buildout.

If you are comfortable, feel free to use setup.py (with or without a dedicated virtualenv) in any of the following repos:

: hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.apps/
: hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.base/
: hg clone https://enus_linden@bitbucket.org/enus_linden/pyogp.lib.client/

Each of the repos already has eggs embedded, and pyogp.apps has the appropriate dependency on pyogp.lib.base configured, which can be checked out and installed in isolation.

1. Check out the repository of your choice
svn co https://svn.secondlife.com/svn/linden/projects/2008/pyogp/<the repo you wanted>/trunk <your pyogp dir>

2. Run setup.py
cd <your pyogp dir>
python setup.py

== Run the tests ==

See [[PyOGP_Client_Library#Pyogp_Unit_Tests]] for details...

== The structure of the sandbox ==

You now might wonder what all those directories are good for. To learn more about this check out the [[Pyogp/Filesystem_Structure|Filesystem Structure]]

[[Category: Pyogp_Client_Lib]]

PyOGP Client Library Development Sandbox

2009-12-03T21:18:11Z

Enus Linden: /* Prerequisites */

{{PyOGP/navigation}}
We will first run down the general explanation and add platform specific notes later.

==Browse the Code==
If all you want to do is glance at the source code, use the [http://svn.secondlife.com/trac/linden/browser/projects/2008/pyogp browser link to the repository]
== Prerequisites ==

You must have the following installed:
* Mercurial - 1.3 or greater
* Python 2.4.4, 2.5.x (fails on 2.6 currently and untested on 3.0)
* pyopenssl http://sourceforge.net/projects/pyopenssl/files/pyopenssl-win/0.8a1/pyOpenSSL-0.8a1.winxp32-py2.5.msi/download (Windows 32-bit)

'''Note:''' Snow Leopard upgrades require a reinstall of XCode, in this case to accommodate gcc (and greenlet).

'''Note:''' Buildout does not yet support subversion 1.6, only 1.4.4-1.5.x.

== Environment Preparation ==

'''Setuptools''' and '''easy_install''' are Python standard means for installing modules. For more info, start here: http://pypi.python.org/pypi/setuptools.

'''Virtualenv''' is a method which allows you to create isolated Python environments, separate from your base install if you so prefer. For more, see here: http://pypi.python.org/pypi/virtualenv.

Your distribution may have Python's '''setuptools''' and '''virtualenv''' packages in its package repository. If so, it is probably best to use your normal package installation procedures (see below for information on specific Linux distributions). If the packages are not available then follow these generic instructions.

=== Generic *nix distribution ===
In order to install Python Packages and creating a development sandbox you have to do the following:

==== easy_install ====

Download ez_setup.py and run it with your Python interpreter. You can find it here: http://peak.telecommunity.com/dist/ez_setup.py

Eventually you have to be root to do this depending on your system (mostly non-windows). It should look like this on a unix based machine:

wget http://peak.telecommunity.com/dist/ez_setup.py
sudo python ez_setup.py

==== virtualenv ====

One may choose to create an isolated python instance on your host, to be able to work with PyOGP without installing packages to your base Python install on your host.

To use a dedicated python installation in your host, install virtualenv like this:

easy_install virtualenv

Or, if you need to be root something like this:

sudo easy_install virtualenv

On windows, you may need a different path to easy_install

c:\Python25\Scripts\easy_install.exe virtualenv

== Install methods ==

Python modules can be installed in a variety of ways...

=== Install Method 1: buildout ===

We use zc.buildout to automatically setup a development environment. buildout gives you the ability to install packages only locally instead of your global python installation. It's sort of a local python installation which helps you avoiding version conflicts of packages.

1. First check out the buildout into a directory of your choice:

svn co http://svn.secondlife.com/svn/linden/projects/2008/pyogp/buildouts/libdev/trunk/ libdev

For those who are interested, tagged and stable version of buildout (with pinned versions on externals) is available at https://svn.secondlife.com/svn/linden/projects/2008/pyogp/buildouts/libdev/tags/0.1/.

2. '''(Optional)''' Now turn this directory into a virtual python environment which is independent of your normal Python installation:

cd libdev
virtualenv . --no-site-packages

on windows, you may need to specify the path

c:\Python25\Scripts\virtualenv.exe . --no-site-packages

3. Now run the bootstrap.py file with the newly created local Python interpreter (if installed. If not, use your system's python.):

bin/python bootstrap.py

or on Windows:

Scripts\python bootstrap.py

4. This creates a bunch of directories and the bin/buildout script (bin\buildout.exe on windows). We now run this:

bin/buildout -v

or on Windows:

bin\buildout.exe -v

5. The development sandbox is ready. There now is a bin/pyogp which is a python interpreter which contains all the installed packaged and the pyogp library and related projects.

6. Test the buildout installation. To test this installation you can (at least at this stage of the project) try the following:

bin/region_connect <firstname> <lastname>

Give your Avatar name and it will ask for a password. Then it tries to login to the Preview Grid.

=== Install Method 2: setup.py ===

How to check out packages and using them independently of buildout.

If you are comfortable, feel free to use setup.py (with or without a dedicated virtualenv) in any of the following repos:

: '''Dev''': https://svn.secondlife.com/svn/linden/projects/2008/pyogp/pyogp.apps/trunk
: '''Dev''': https://svn.secondlife.com/svn/linden/projects/2008/pyogp/pyogp.lib.base/trunk/
: '''Dev''': https://svn.secondlife.com/svn/linden/projects/2008/pyogp/pyogp.lib.client/trunk/

Each of the repos already has eggs embedded, and pyogp.apps has the appropriate dependency on pyogp.lib.base configured, which can be checked out and installed in isolation.

1. Check out the repository of your choice
svn co https://svn.secondlife.com/svn/linden/projects/2008/pyogp/<the repo you wanted>/trunk <your pyogp dir>

2. Run setup.py
cd <your pyogp dir>
python setup.py

== Run the tests ==

See [[PyOGP_Client_Library#Pyogp_Unit_Tests]] for details...

== The structure of the sandbox ==

You now might wonder what all those directories are good for. To learn more about this check out the [[Pyogp/Filesystem_Structure|Filesystem Structure]]

[[Category: Pyogp_Client_Lib]]

PyOGP

2009-12-03T21:15:28Z

Enus Linden: /* How To Contribute */

{{PyOGP/navigation}}
== Overview ==

=== What Is It? ===

Pyogp is an open source project between Linden Lab and the [[AWG|Architecture Working Group (AWG)]] to support testing the [[Open Grid Protocol|Open Grid Protocol (OGP)]]. Written in Python, Pyogp will consist initially of a [[Pyogp/Documentation/Specification/pyogp.lib.base|client library]] and [[Pyogp/Documentation/Specification/pyogp.interop|test functionality]] to enable testing OGP-enabled virtual worlds such as Second Life and compatible OpenSim implementations. These components will expand as the effort matures.

PyOGP could be useful for:
* checking your software's compliance with the OGP
* quickly writing tests for software which communicates using LLMessageSystem-like messages
* demonstrating protocol proposals

=== Getting Started ===

See [[PyOGP Client Library Development Sandbox]] for instructions on how to starting using Pyogp.
See also [[PyOGP Client Library]] for a more up-to-date page.

=== How To Contribute ===
* Source: [[Pyogp/Client_Lib/The_Development_Sandbox | Checkout Instructions]]. See the [[Open_Source_Portal|Open Source Portal]] for details on being a contributor
* in-world group: pyogp (open enrollement)
* IRC: irc://irc.freenode.com/#pyogp
* Mailing list: https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp, pyogp@lists.secondlife.com
* Jira: http://jira.secondlife.com/browse/PYO
* Related Meetings
** Enus Linden's office hours: Friday @ 1:00 http://slurl.com/secondlife/Longfellow/99/97/28

== Project Status ==

PyOGP is moving to bitbucket! http://bitbucket.org/enus_linden/

Thanks for the patience as we make this transition.

Keep track of progress on the list: https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp.

== Pic of the Moment ==
[[Image:355571.jpg|900x835px|the EnusBots are coming!]]

Image used with permission. Taken by [[User:Opensource_Obscure|Opensource Obscure]]. (thanks oo! <3)

== Licensing ==
Contributions to Pyogp are subject to Linden Lab's [http://secondlifegrid.net/programs/open_source/submission contributor agreement]. The Pyogp open source code is made available subject to the Apache v2 license. Read more at [http://opensource.org/licenses/apache2.0.php opensource.org] and [http://www.apache.org/licenses/LICENSE-2.0 apache.org].

<excerpt>
Copyright 2008, Linden Research, Inc.
 
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
 
http://www.apache.org/licenses/LICENSE-2.0
 
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
</excerpt>

== History ==

Linden Lab and the [[AWG]] ([[AW_Groupies|in-world discussion group page]]) are working together to develop a set of open protocols called the [[Open Grid Protocol]] that can be used to create a virtual world where regions are independently operated (not only by Linden Lab). The project is aiming to allow people (organizations, individuals, and the like) to host their own regions in the virtual world and be able to interact and communicate with people in regions hosted elsewhere. In essence, the project's goal is to allow open-source region hosting.

AWG and Linden Lab plan to share the effort in writing a test harness that executes tests against implementations of the Open Grid Protocol.

The intent is not to test SL or OpenSim (or gridX) themselves. Rather, the desire is to create a framework where the implementations of the protocols can be tested in any virtual environment implemented per the Open Grid Protocols as documented. The goal is to use the test harness to test the implementations to make sure that the virtual environment is interoperable with the other virtual environments that have implemented the OGP. However, we also plan to test the current SL protocols (the Legacy protocols). We plan to be able to test at the smallest functional level possible, akin to unit testing, and to have the ability to use the framework to sequence steps to enable state specific tests to be run.

The longer-term vision is essentially a [[Pyogp_Client_Lib|client library]], capable of navigating the grid and interacting with the various hosts, sitting next to a testing framework, happily running along telling us what works where, and where something needs a little attention to work according to specification...

For more detail on OGP, see a visual representation of the upcoming [[Open Grid Platform Projects Q2-Q3|projects]] and a general [[Structural Design Overview|introduction]].

=== Notes from the kickoff meeting ===

At the AWG meeting held April 29, 2008, we discussed what a test harness could look like that would be used to test the agent-domain, rez-avatar, and overall work being done implementing the open grid protocols. I'd like to summarize, and continue the discussion on the mailing list, in-world, and on the wiki. See [[AWGroupies-2008-04-29|meeting chat log]].

How do we start?

Let's work on defining the test harness components (from the meeting):
# Login
# Caps (and while it's around the UDP pipe)
# Message Handlers (see chttp)
# Basic web server parts for the Agent, Region and grid bits (ideally a snap in framework)
# Test framework
# Test data (I put this here, not really as a component of the harness, more as a "i'm not telling you my test account's password and what are we gonna do about it" thing)

Python seems to be the flavor of choice here, with a requirement that it accommodate non-python components as needed. The repository for the code is proposed to be maintained by Linden Lab, distributed as an open source export, under the Apache v2 License (see http://opensource.org/licenses/apache2.0.php). The process and details here are tentative, and need more attention...

There is plenty to be figured out. How to start, who wants to play, details are all TBD. My role is primarily intended as one who will facilitate dialogue and contribute as much as possible, but this is intended as a joint effort.

-- Enus Linden

[[Category:Architecture Working Group]]
[[Category:Grid_Interoperability]]
[[Category: Pyogp|*]]
[[Category:Pyogp_Kitchen_Sink]]
[[Category: AW Groupies]]
[[Category:Automated Testing]]

PyOGP

2009-12-03T21:13:50Z

Enus Linden: /* Project Status */

{{PyOGP/navigation}}
== Overview ==

=== What Is It? ===

Pyogp is an open source project between Linden Lab and the [[AWG|Architecture Working Group (AWG)]] to support testing the [[Open Grid Protocol|Open Grid Protocol (OGP)]]. Written in Python, Pyogp will consist initially of a [[Pyogp/Documentation/Specification/pyogp.lib.base|client library]] and [[Pyogp/Documentation/Specification/pyogp.interop|test functionality]] to enable testing OGP-enabled virtual worlds such as Second Life and compatible OpenSim implementations. These components will expand as the effort matures.

PyOGP could be useful for:
* checking your software's compliance with the OGP
* quickly writing tests for software which communicates using LLMessageSystem-like messages
* demonstrating protocol proposals

=== Getting Started ===

See [[PyOGP Client Library Development Sandbox]] for instructions on how to starting using Pyogp.
See also [[PyOGP Client Library]] for a more up-to-date page.

=== How To Contribute ===
* Source: [[Pyogp/Client_Lib/The_Development_Sandbox | Checkout Instructions]]. See the [[Open_Source_Portal|Open Source Portal]] for details on being a contributor
** If all you want to do is glance at the source code, use the [https://svn.secondlife.com/svn/linden/projects/2008/pyogp/ browser link to the repository]
* in-world group: pyogp (open enrollement)
* IRC: irc://irc.freenode.com/#pyogp
* Mailing list: https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp, pyogp@lists.secondlife.com
* Jira: http://jira.secondlife.com/browse/PYO
* Related Meetings
** Enus Linden's office hours: Friday @ 1:00 http://slurl.com/secondlife/Longfellow/99/97/28

== Project Status ==

PyOGP is moving to bitbucket! http://bitbucket.org/enus_linden/

Thanks for the patience as we make this transition.

Keep track of progress on the list: https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp.

== Pic of the Moment ==
[[Image:355571.jpg|900x835px|the EnusBots are coming!]]

Image used with permission. Taken by [[User:Opensource_Obscure|Opensource Obscure]]. (thanks oo! <3)

== Licensing ==
Contributions to Pyogp are subject to Linden Lab's [http://secondlifegrid.net/programs/open_source/submission contributor agreement]. The Pyogp open source code is made available subject to the Apache v2 license. Read more at [http://opensource.org/licenses/apache2.0.php opensource.org] and [http://www.apache.org/licenses/LICENSE-2.0 apache.org].

<excerpt>
Copyright 2008, Linden Research, Inc.
 
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
 
http://www.apache.org/licenses/LICENSE-2.0
 
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
</excerpt>

== History ==

Linden Lab and the [[AWG]] ([[AW_Groupies|in-world discussion group page]]) are working together to develop a set of open protocols called the [[Open Grid Protocol]] that can be used to create a virtual world where regions are independently operated (not only by Linden Lab). The project is aiming to allow people (organizations, individuals, and the like) to host their own regions in the virtual world and be able to interact and communicate with people in regions hosted elsewhere. In essence, the project's goal is to allow open-source region hosting.

AWG and Linden Lab plan to share the effort in writing a test harness that executes tests against implementations of the Open Grid Protocol.

The intent is not to test SL or OpenSim (or gridX) themselves. Rather, the desire is to create a framework where the implementations of the protocols can be tested in any virtual environment implemented per the Open Grid Protocols as documented. The goal is to use the test harness to test the implementations to make sure that the virtual environment is interoperable with the other virtual environments that have implemented the OGP. However, we also plan to test the current SL protocols (the Legacy protocols). We plan to be able to test at the smallest functional level possible, akin to unit testing, and to have the ability to use the framework to sequence steps to enable state specific tests to be run.

The longer-term vision is essentially a [[Pyogp_Client_Lib|client library]], capable of navigating the grid and interacting with the various hosts, sitting next to a testing framework, happily running along telling us what works where, and where something needs a little attention to work according to specification...

For more detail on OGP, see a visual representation of the upcoming [[Open Grid Platform Projects Q2-Q3|projects]] and a general [[Structural Design Overview|introduction]].

=== Notes from the kickoff meeting ===

At the AWG meeting held April 29, 2008, we discussed what a test harness could look like that would be used to test the agent-domain, rez-avatar, and overall work being done implementing the open grid protocols. I'd like to summarize, and continue the discussion on the mailing list, in-world, and on the wiki. See [[AWGroupies-2008-04-29|meeting chat log]].

How do we start?

Let's work on defining the test harness components (from the meeting):
# Login
# Caps (and while it's around the UDP pipe)
# Message Handlers (see chttp)
# Basic web server parts for the Agent, Region and grid bits (ideally a snap in framework)
# Test framework
# Test data (I put this here, not really as a component of the harness, more as a "i'm not telling you my test account's password and what are we gonna do about it" thing)

Python seems to be the flavor of choice here, with a requirement that it accommodate non-python components as needed. The repository for the code is proposed to be maintained by Linden Lab, distributed as an open source export, under the Apache v2 License (see http://opensource.org/licenses/apache2.0.php). The process and details here are tentative, and need more attention...

There is plenty to be figured out. How to start, who wants to play, details are all TBD. My role is primarily intended as one who will facilitate dialogue and contribute as much as possible, but this is intended as a joint effort.

-- Enus Linden

[[Category:Architecture Working Group]]
[[Category:Grid_Interoperability]]
[[Category: Pyogp|*]]
[[Category:Pyogp_Kitchen_Sink]]
[[Category: AW Groupies]]
[[Category:Automated Testing]]

PyOGP

2009-12-03T21:13:35Z

Enus Linden: /* Project Status */

{{PyOGP/navigation}}
== Overview ==

=== What Is It? ===

Pyogp is an open source project between Linden Lab and the [[AWG|Architecture Working Group (AWG)]] to support testing the [[Open Grid Protocol|Open Grid Protocol (OGP)]]. Written in Python, Pyogp will consist initially of a [[Pyogp/Documentation/Specification/pyogp.lib.base|client library]] and [[Pyogp/Documentation/Specification/pyogp.interop|test functionality]] to enable testing OGP-enabled virtual worlds such as Second Life and compatible OpenSim implementations. These components will expand as the effort matures.

PyOGP could be useful for:
* checking your software's compliance with the OGP
* quickly writing tests for software which communicates using LLMessageSystem-like messages
* demonstrating protocol proposals

=== Getting Started ===

See [[PyOGP Client Library Development Sandbox]] for instructions on how to starting using Pyogp.
See also [[PyOGP Client Library]] for a more up-to-date page.

=== How To Contribute ===
* Source: [[Pyogp/Client_Lib/The_Development_Sandbox | Checkout Instructions]]. See the [[Open_Source_Portal|Open Source Portal]] for details on being a contributor
** If all you want to do is glance at the source code, use the [https://svn.secondlife.com/svn/linden/projects/2008/pyogp/ browser link to the repository]
* in-world group: pyogp (open enrollement)
* IRC: irc://irc.freenode.com/#pyogp
* Mailing list: https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp, pyogp@lists.secondlife.com
* Jira: http://jira.secondlife.com/browse/PYO
* Related Meetings
** Enus Linden's office hours: Friday @ 1:00 http://slurl.com/secondlife/Longfellow/99/97/28

== Project Status ==

PyOGP is moving to bitbucket! http://bitbucket.org/enus_linden/ Thanks for the patience as we make this transition.

Keep track of progress on the list: https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp.

== Pic of the Moment ==
[[Image:355571.jpg|900x835px|the EnusBots are coming!]]

Image used with permission. Taken by [[User:Opensource_Obscure|Opensource Obscure]]. (thanks oo! <3)

== Licensing ==
Contributions to Pyogp are subject to Linden Lab's [http://secondlifegrid.net/programs/open_source/submission contributor agreement]. The Pyogp open source code is made available subject to the Apache v2 license. Read more at [http://opensource.org/licenses/apache2.0.php opensource.org] and [http://www.apache.org/licenses/LICENSE-2.0 apache.org].

<excerpt>
Copyright 2008, Linden Research, Inc.
 
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
 
http://www.apache.org/licenses/LICENSE-2.0
 
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
</excerpt>

== History ==

Linden Lab and the [[AWG]] ([[AW_Groupies|in-world discussion group page]]) are working together to develop a set of open protocols called the [[Open Grid Protocol]] that can be used to create a virtual world where regions are independently operated (not only by Linden Lab). The project is aiming to allow people (organizations, individuals, and the like) to host their own regions in the virtual world and be able to interact and communicate with people in regions hosted elsewhere. In essence, the project's goal is to allow open-source region hosting.

AWG and Linden Lab plan to share the effort in writing a test harness that executes tests against implementations of the Open Grid Protocol.

The intent is not to test SL or OpenSim (or gridX) themselves. Rather, the desire is to create a framework where the implementations of the protocols can be tested in any virtual environment implemented per the Open Grid Protocols as documented. The goal is to use the test harness to test the implementations to make sure that the virtual environment is interoperable with the other virtual environments that have implemented the OGP. However, we also plan to test the current SL protocols (the Legacy protocols). We plan to be able to test at the smallest functional level possible, akin to unit testing, and to have the ability to use the framework to sequence steps to enable state specific tests to be run.

The longer-term vision is essentially a [[Pyogp_Client_Lib|client library]], capable of navigating the grid and interacting with the various hosts, sitting next to a testing framework, happily running along telling us what works where, and where something needs a little attention to work according to specification...

For more detail on OGP, see a visual representation of the upcoming [[Open Grid Platform Projects Q2-Q3|projects]] and a general [[Structural Design Overview|introduction]].

=== Notes from the kickoff meeting ===

At the AWG meeting held April 29, 2008, we discussed what a test harness could look like that would be used to test the agent-domain, rez-avatar, and overall work being done implementing the open grid protocols. I'd like to summarize, and continue the discussion on the mailing list, in-world, and on the wiki. See [[AWGroupies-2008-04-29|meeting chat log]].

How do we start?

Let's work on defining the test harness components (from the meeting):
# Login
# Caps (and while it's around the UDP pipe)
# Message Handlers (see chttp)
# Basic web server parts for the Agent, Region and grid bits (ideally a snap in framework)
# Test framework
# Test data (I put this here, not really as a component of the harness, more as a "i'm not telling you my test account's password and what are we gonna do about it" thing)

Python seems to be the flavor of choice here, with a requirement that it accommodate non-python components as needed. The repository for the code is proposed to be maintained by Linden Lab, distributed as an open source export, under the Apache v2 License (see http://opensource.org/licenses/apache2.0.php). The process and details here are tentative, and need more attention...

There is plenty to be figured out. How to start, who wants to play, details are all TBD. My role is primarily intended as one who will facilitate dialogue and contribute as much as possible, but this is intended as a joint effort.

-- Enus Linden

[[Category:Architecture Working Group]]
[[Category:Grid_Interoperability]]
[[Category: Pyogp|*]]
[[Category:Pyogp_Kitchen_Sink]]
[[Category: AW Groupies]]
[[Category:Automated Testing]]

PyOGP Client Library

2009-10-20T07:17:57Z

Enus Linden: /* Goals */

{{PyOGP/navigation}}
== Intro ==

PyOGP is a young, open source, python client library which provides an interface to an agent (client) of a Second Life grid. The code aims to enable automated testing of Second Life grids, to encourage and enable exploration into the client/server relationship and related protocols of Second Life, and to make possible simple prototyping of various client applications.

Hosted on svn.secondlife.com, it does require a contributor's agreement for commit access, and currently has a few contributors from the Second Life open source community.

P.S. We'll likely be moving to hg relatively soon...

* mailing list: pyogp@lists.secondlife.com
* irc: irc://irc.freenode.com/#pyogp
* wiki: http://wiki.secondlife.com/wiki/Pyogp
* licensing: Apache 2.0 license, copyright Linden Lab

=== Goals ===

In the very near future, we can have tests available to be run as soon as a deploy is completed that exercise a simulator/grid in the same way we do a smoke test. We will use these as automated tests run at build time, post deploy validation, and regression testing of simulators and backend systems.

This provides early feedback on code quality. QA is then able to dive deeper in testing the changes specific to a branch.

Having this library available also allows us to test potential changes before we have finalized design and are ready to submit to QA. Not sure how something will play out? Try it, and test it with PyOGP....

=== A Brief History ===

PyOGP was originally created as a tool for testing [[OGP]] related changes to the Second Life grid. By the end of the summer in 2008, the '''pyogp.lib.base''' package provided a skeleton messaging system and was able to test Linden Lab's first implementation of an agent domain and the related changes in an agent's region handoff and teleport. As the development effort around OGP waned, we started to extend pyogp by adding higher level client related functionality. Recently, this functionality was split out into a separate python package ('''pyogp.lib.client'''), and sample scripts (and future apps) were moved into '''pyogp.apps'''.

== Architecture Overview==

=== Structure ===

PyOGP is comprised of three python packages. The library consists of pyogp.lib.base and pyogp.lib.client, while sample scripts, and in time applications, live in pyogp.apps.
:'''pyogp.lib.base''' - consists of basic networking, messaging systems (UDP and event queue) and capabilities, custom datatypes, and a low level message related event system
:'''pyogp.lib.client''' - consists of 'convenience' classes mapping methods and handlers to specific messages (e.g. Agent().say(msg) tells the client to send the ChatFromViewer message to the host region). Raises application oriented events based on processing of messages (these are currently sparsely implemented)
:'''pyogp.apps''' - sample scripts and works in progress, the scripts here generally illustrate simple usage of classes as related to in world interactions by an agent of a Second Life grid

=== Dependencies ===

==== Platform / Python version compatibility ====

PyOGP aims to be compatible across platforms, though there are known problems with various environments. We'll be focusing on ensuring better compatibility soon.

'''Known good configurations'''

:Windows XP + Python 2.5
:Mac + Python 2.5, 2.6
:Linux + Python 2.4, 2.5, 2.6 (Linden hosts fall into this group)

'''Known bad configurations'''
:Windows Vista + Python 2.6
:Windows 7 + Python 2.6

There have been challenges in ensuring compatibility between the various dependencies, largely due to greenlet, eventlet, and pyopenssl. Please report bugs on [http://jira.secondlife.com/browse/PYO pJira]

==== Python module dependencies ====

The packages that make up PyOGP have some dependencies on python modules not included in a standard install, or sometimes not available on an older Python distribution.

'''pyogp.lib.base dependencies:'''

<python> #from setup.py

install_requires=[
'setuptools',
# -*- Extra requirements: -*-
'uuid',
'elementtree',
'indra.base',
'WebOb',
'wsgiref',
'eventlet==0.8.14'
]</python>

'''pyogp.lib.client dependencies:'''

<python> install_requires=[
'setuptools',
# -*- Extra requirements: -*-
'pyogp.lib.base'
] </python>

'''pyogp.apps dependencies:'''

<python> install_requires=[
'setuptools',
'pyogp.lib.client'
]</python>

=== How to install ===

''Lindens can see internal documentation for more specific guidance. https://wiki.lindenlab.com/wiki/Pyogp#How_to_Install''

==== Standalone dev environment using buildout ====

Buildout is a type of Python development environment, organizing and configuring various components and their dependencies. On a desktop, one may checkout such an environment for working with PyOGP. One may optionally use a virtualenv Python environment to isolate the development code and it's runtime environment on one's host.

Dependencies: buildout takes care of everything, grabbing needed modules etc.

Wiki instructions: https://wiki.secondlife.com/wiki/Pyogp/Client_Lib/The_Development_Sandbox

==== Installing the PyOGP packages ====

Each of the PyOGP package may be installed to one's Python install or to a [http://pypi.python.org/pypi/virtualenv virtualenv]. '''Buyer beware''' if installing into your system's install: you'll want to be able to uninstall manually, as we haven't hooked up the uninstall. PyOGP is still coming up to speed with respect to distutils and pypi and the like, but it's relatively close now.

To install a package, simply run 'python setup.py install' in a package's root.

==== Referencing PyOGP packages via the PATH ====

Source code can be referenced directly if one simply ensures that a package, and it's dependencies, are available in the PYTHONPATH environmental variable.

== Current functional coverage ==

Anything not listed as covered is probably not yet covered.

pyogp.lib.base:
:* base udp messaging system (message.*)
:** UDP serialization/deserialization
:** message_template.msg parsing
:* base event queue messaging system (event_queue.EventQueueClient())
:* capabilities and their methods. Seed capabilities are a special case. (caps.Capability())
:* Message-based events (message.message_handler)

pyogp.lib.client:
:* agents (agent.Agent())
:** L$ balance request, friending, and walk/fly/sit/stand actions...
:* OGP agentdomain (agentdomain.AgentDomain())
:* application level events (event_system.AppEventsHandler())
:* some object handling (objects.*)
:** edit name, description, next-owner permissions and more
:** object creation is possible
:* some inventory handling (inventory.*)
:** login inv skeletons
:** fetching inventory, including AIS (caps based Agent Inventory Services))
:** some creating of new inventory items (LSL scripts, notecards)
:* regions (region.Region())
:** host and neighboring regions are handled slightly differently
:** udp and event queue connections are optionally enabled for each case
:** currently only pulling caps available to the agent via the seed cap (plus using the inventory related caps in the AIS context)
:* some appearance handling (appearance.AppearanceManager),
:* parcels
:* chat
:* some ImprovedInstantMessage handling
:** raises events on received instant messages
:** can deal with inventory offers/accepts/declines
:** other cases in this message are currently only logged
:* groups
:* group chat
:* LSL script uploading

=== Sample Scripts ===

There are a variety of scripted examples that have been used to exercise and test functionality as it is added to the library. These persist as coded documentation.

The source code is available in https://svn.secondlife.com/svn/linden/projects/2008/pyogp/pyogp.apps/trunk/pyogp/apps/examples/.

The following refers to a buildout context. If one installs pyogp.apps vi setup.py, these scripts will exist in the python environment's bin/ directory. In the buildout context, these scripts are available in {buildout root}/bin.

The scripts are derived from a package's 'setup.py' via the entry_points parameter, and essentially build executable Python scripts configured to run in the correct environment with the proper dependencies added the the path used by the script. These scripts are currently just simple illustrations of some uses of the PyOGP codebase.

<python> #the current entry_points in setup.py og pyogp.apps:

entry_points={
'console_scripts': [
'AIS_inventory_handling = pyogp.apps.examples.AIS_inventory_handling:main',
'agent_login = pyogp.apps.examples.agent_login:main',
'agent_manager = pyogp.apps.examples.agent_manager:main',
'appearance_management = pyogp.apps.examples.appearance_management:main',
'chat_and_instant_messaging = pyogp.apps.examples.chat_and_instant_messaging:main',
'group_chat = pyogp.apps.examples.group_chat:main',
'group_creation = pyogp.apps.examples.group_creation:main',
'inventory_handling = pyogp.apps.examples.inventory_handling:main',
'inventory_transfer = pyogp.apps.examples.inventory_transfer:main',
'inventory_transfer_specify_agent = pyogp.apps.examples.inventory_transfer_specify_agent:main',
'login = pyogp.apps.examples.login:main',
'multi_region_connect = pyogp.apps.examples.multi_region_connect:main',
'object_create_edit = pyogp.apps.examples.object_create_edit:main',
'object_create_permissions = pyogp.apps.examples.object_create_permissions:main',
'object_create_rez_script = pyogp.apps.examples.object_create_rez_script:main',
'object_creation = pyogp.apps.examples.object_creation:main',
'object_properties = pyogp.apps.examples.object_properties:main',
'object_tracking = pyogp.apps.examples.object_tracking:main',
'parcel_management = pyogp.apps.examples.parcel_management:main',
'parse_packets = pyogp.apps.examples.parse_packets:main',
'region_connect = pyogp.apps.examples.region_connect:main',
'smoke_test = pyogp.apps.examples.smoke_test:main',
'chat = pyogp.apps.examples.chat_interface:main',
]
}</python>

== How it Works (High Level) ==

=== Eventlet ===

PyOGP use [[Eventlet]] to run coroutines to handle multiple 'concurrent' processes, rather than threads or multiple processes. Each client agent instance will spawn a handful of coroutines to handles e.g. the UDP pipe, the Event Queue, various monitors, while yielding time to the parent process which should ensure it yields to the other routines as well.

PyOGP uses eventlet in very elementary ways at this point, but will perhaps start to use blocking queues in some cases, so that the coroutine only is allocated processing time if there is work for it to do.

=== pyogp.lib.base ===

This package handles the protocols used when communicating with a Second Life grid. A high level perspective on the package reveals a MessageManager() (still in development) which provides an interface to the UDP and Event Queue connections, as well as basic networking with enables login and capabilities interactions. The base package also has a low level even system through which all messages are passed and sent to subscribers.

Any subcomponent is available for direct interaction at any time, the MessageManager() and the MessageHandler() are the simple access points.

==== Events & Callbacks ====

The event implementation in pyogp follows the observer pattern, where observers subscribe to and are notified when an event occurs. Data is passed throughout the client instance via events.

* MessageManager - is an attribute of a Region and every packet received/sent is filtered through here. subscriptions are by message name
** MessageHandler - is an attribute of MessageManager, and every categorized message received from the event queue or udp dispatcher is filtered through here. (message as defined in message_template.msg, or one of ['ChatterBoxInvitation', 'ChatterBoxSessionEventReply', 'ChatterBoxSessionAgentListUpdates', 'ChatterBoxSessionStartReply', 'EstablishAgentCommunication']. There may be unhandled messages, I just haven't seen em yet :))

===== Message Events =====

In the most fundamental implementation of event usage, all packets are passed through a MessageManager() instance for evaluation. Observers may register to receive udp packets serialized into the form of Message() instances. The MessageHandler() is a consolidation point for subscribing to messages keyed by message name, and created on demand via subscription.

See pyogp.lib.base.message.message_handler.MessageHandler() for more details.

The pyogp agent's Region() instances each monitor their stream of packets (e.g. the host region: agent.region.message_manager.message_handler). (Perhaps this should be changed to a generalized Network() class where all packets (coupled to their originating regions) are evaluated.

Event firing passes data on to a callback handler defined in the subscription, in the form of (handler, *args, **kwargs).

The Agent class monitors the ImprovedInstantMessage packet:
<python> onImprovedInstantMessage_received = self.region.message_handler.register('ImprovedInstantMessage')
onImprovedInstantMessage_received.subscribe(self.onImprovedInstantMessage)

def onImprovedInstantMessage(self, packet):
""" handles the many cases of data being passed in this message """

{code} # parse and handle the data...</python>

The messaging system then fires the event when an ImprovedInstantMessage message is received, which calls onImprovedInstantMessage method above to handle the message contents. Multiple subscribers may be listening for any message related event, and each would be notified of the same Message() instance.

Unsubscribing from an event:
<python> onImprovedInstantMessage_received.unsubscribe(self.onImprovedInstantMessage)</python>

There are various event and callback implementations viewable in pyogp, poke around and help consolidate things if you like.

=== pyogp.lib.client ===

The client package generally provides a convenient interface to initiate or interpret interactions with host region (or neighboring regions). By listening to the messaging related event system in pyogp.lib.base, the client package interprets the messages that come in off the wire, and executes business logic in building responses. pyogp.lib.client also provides simple methods to enable the ending of messages to a grid.

==== Events ====

* EventsHandler - an attribute of an Agent, also able to be passed in, that is intended as the primary interface of a pyogp application into the internal state and data events within the lib. This system uses the same base classes as used by the MessageHandler() in the base package, and the descriptions about events and callbacks above apply here as well. The api for subscribing to these events is similar to the MessageHandler(), with an additional timeout parameter passed in the _register() method. When the specified timeout expires, the subscription returns None and expires the subscription.

==== Agent Login (examples) ====

===== Single Agent Login & Chat=====

Spawn a client in a co-routine, allowing persistent presence until forcefully terminated.

<python>from eventlet import api

from pyogp.lib.client.agent import Agent
from pyogp.lib.client.settings import Settings

settings = Settings()

settings.ENABLE_INVENTORY_MANAGEMENT = True
settings.MULTIPLE_SIM_CONNECTIONS = False

client = Agent(settings = settings)

api.spawn(client.login, options.loginuri, 'first', 'last', 'password', start_location = options.region)

# wait for the agent to connect to it's region
while client.connected == False:
api.sleep(0)

while client.region.connected == False:
api.sleep(0)

client.say("Hello World!")

# once connected, live until someone kills me
while client.running:
api.sleep(0)</python>

===== Multiple Agent Login =====

Each agent instance in logged in in a separate coroutine.

<python>from pyogp.lib.client.agent import Agent
from pyogp.lib.client.agentmanager import AgentManager

clients = [['agent1', 'lastname', 'password'], ['agent2', 'lastname', 'password']]
agents = []

# prime the Agent instances
for params in clients:
agents.append(Agent(settings, params[0], params[1], params[2]))

agentmanager = AgentManager()
agentmanager.initialize(agents)

# log them in
for key in agentmanager.agents:
agentmanager.login(key, options.loginuri, options.region)

# while they are connected, stay alive
while agentmanager.has_agents_running():
api.sleep(0)</python>

== Extending Functionality ==

While the implementations and structures in pyogp.lib.base can (and are in the process of) being refactored to improve performance or usability, it is a fairly complete package.

The functional coverage PyOGP provides on the other hand is not complete, and there are a variety of needs to complete the implementation in pyogp.lib.base. We need to improve coverage of message handling (dealing with messages sent to the client), add more wrappers for sending various messages and performing multistep tasks (to simplify the initiation of interactions with the region), and we need to raise more application level events in the client package so that applications have easy access to incoming data.

=== Sending Messages ===

PyOGP, like the Viewer, communicates with the Second Life simulator by sending messages over UDP.

In order to extend PyOGP, you'll build a representation of a new UDP message, and send it through the pyogp.lib.base modules for serialization and wire handling.

=== Example: Sending an IM ===

To send an IM to the simulator, send an ImprovedInstantMessage packet. The base class for message packets is defined in <code>base/message/message.py</code>

Packets are assembled using a Message() instance which has the message name and Block() instances passed in through its constructor. Similarly, Blocks are assembled by passing in the Block name and the value name and values for each of the Block values. (The ability to build Message() instances via an llsd payload is expected to be introduced soon.)

Note: It is important that the message name, block name, and value names and types should match what is specified in the message template. (It is also possible to manipulate the representation of the stored template, or to use a custom message template.)

Example:
<python> def send_ImprovedInstantMessage(self, AgentID = None, SessionID = None,
FromGroup = None, ToAgentID = None,
ParentEstateID = None, RegionID = None,
Position = None, Offline = None,
Dialog = None, _ID = None, Timestamp = None,
FromAgentName = None, _Message = None,
BinaryBucket = None):
"""
sends an instant message packet to ToAgentID. this is a
multi-purpose message for inventory offer handling, im, group chat,
and more
"""

packet = Message('ImprovedInstantMessage',
Block('AgentData',
AgentID = AgentID,
SessionID = SessionID),
Block('MessageBlock',
FromGroup = FromGroup,
ToAgentID = ToAgentID,
ParentEstateID = ParentEstateID,
RegionID = RegionID,
Position = Position,
Offline = Offline,
Dialog = Dialog,
ID = UUID(str(_ID)),
Timestamp = Timestamp,
FromAgentName = FromAgentName,
Message = _Message,
BinaryBucket = BinaryBucket))

# Send the message:
self.region.enqueue_message(packet, True)</python>

=== Handling Incoming Messages and Raising an Event ===

To listen for when messages of a particular type are sent to the client instance, subscribe to the MessageHandler() on the host region's MessageManager(), like the example that follows:

<python> onImprovedInstantMessage_received = self.region.message_handler.register('ImprovedInstantMessage')
onImprovedInstantMessage_received.subscribe(self.onImprovedInstantMessage)</python>

When the event is fired upon receipt of the message matching the name, the specified callback handles the data passed along, and in this case raises an event notifying observers of the 'InstantMessageReceived' event in pyogp.lib.client of the important data.

<python> def onImprovedInstantMessage(self, packet):
""" callback handler for received ImprovedInstantMessage messages. much is passed in this message, and handling the data is only partially implemented """

Dialog = packet.blocks['MessageBlock'][0].get_variable('Dialog').data
FromAgentID = packet.blocks['AgentData'][0].get_variable('AgentID').data

if Dialog == ImprovedIMDialogue.InventoryOffered:

self.inventory.handle_inventory_offer(packet)

# ...
# some of the Dialogue types this message can contain are handled, we are showing 2
# ...

elif Dialog == ImprovedIMDialogue.FromAgent:

# ... code parses the data from the Message() instance ...

message = AppEvent('InstantMessageReceived', FromAgentID = FromAgentID, RegionID = RegionID, Position = Position, ID = ID, FromAgentName = FromAgentName, Message = _Message)

logger.info("Received instant message from %s: %s" % (FromAgentName, _Message))

self.events_handler.handle(message)</python>

== Logging ==

Uses python's standard logging module (http://docs.python.org/library/logging.html). The library defines logging events throughout, it is up to the application/script to determine the output.

Hooking logging into a new module:

<python>from logging import getLogger

# initialize logging
logger = getLogger('pyogp.lib.client.agent')

class Agent(object):
""" our agent class """

def __init__(self, params):

self.params = params

logger.debug("Initializing agent with params: %s" % (params))</python>

An application can then set up the logging output as follows (or any other way it pleases):

<python>console = logging.StreamHandler()
formatter = logging.Formatter('%(asctime)-30s%(name)-30s: %(levelname)-8s %(message)s')
console.setFormatter(formatter)
logging.getLogger('').addHandler(console)
logging.getLogger('').setLevel(logging.DEBUG)</python>

The output to console is then:

<bash>2009-04-21 22:08:58,681 pyogp.lib.base.agent : DEBUG agent with params: params</bash>

== Pyogp Unit Tests ==

See [[PyOGP_Package_Unittests]].

== Sphinx (api docs) ==

'''Api documentation is now available for PyOGP packages''' (well, not for apps yet, but someday....)!

In pyogp/docs in each of the pyogp.lib.base and pyogp.lib.client packages, one will find source, last revision, and build files for sphinx based documents. Output is available at {package root}/docs/html/index.html.

We plan on sharing the api documentation on the web soon, and will work to make simple build wrappers work on various platforms, though this is a low priority.

Ask Enus for updated documentation to be checked in, or, build a better refresh.py.

== Roadmap ==

See [[Pyogp/Roadmap]] for details, or ask in irc or on the mailing list. Here's what's up in the near term for pyogp:

* better '''packaging''' and '''platform compatibility'''
* more '''functional coverage''' of message. We are covering 32% of the messages the viewers sends or handles when received (though it's estimated at more like 50% of normal use cases.
* '''permissions system testing''' to save QA from 3-5 day regression passes on perms
* '''appearance''' - this will require enabling upload and download, plus baking. Anyone have some spare time? :)

[[Category: Pyogp_Client_Lib]]
[[Category: Pyogp]]
[[Category:Architecture Working Group]]
[[Category:Grid_Interoperability]]
[[Category:AW Groupies]]
[[Category:MMOX]]

PyOGP Client Library

2009-10-20T07:16:18Z

Enus Linden: /* Logging */

{{PyOGP/navigation}}
== Intro ==

PyOGP is a young, open source, python client library which provides an interface to an agent (client) of a Second Life grid. The code aims to enable automated testing of Second Life grids, to encourage and enable exploration into the client/server relationship and related protocols of Second Life, and to make possible simple prototyping of various client applications.

Hosted on svn.secondlife.com, it does require a contributor's agreement for commit access, and currently has a few contributors from the Second Life open source community.

P.S. We'll likely be moving to hg relatively soon...

* mailing list: pyogp@lists.secondlife.com
* irc: irc://irc.freenode.com/#pyogp
* wiki: http://wiki.secondlife.com/wiki/Pyogp
* licensing: Apache 2.0 license, copyright Linden Lab

=== Goals ===

In the very near future, we can have tests available to be run as soon as a deploy is completed that exercise a simulator/grid in the same way we do a smoke test. We will use these as automated tests run at build time, post deploy validation, and regression testing of simulators and backend systems.

This provides early feedback on code quality. QA is then able to dive deeper in testing the changes specific to a branch.

Having this library available also allows us to test potential changes before we have finalized design and are ready to submit to QA. Not sure how something will play out? Try it, and test it with PyOGP....

=== A Brief History ===

PyOGP was originally created as a tool for testing [[OGP]] related changes to the Second Life grid. By the end of the summer in 2008, the '''pyogp.lib.base''' package provided a skeleton messaging system and was able to test Linden Lab's first implementation of an agent domain and the related changes in an agent's region handoff and teleport. As the development effort around OGP waned, we started to extend pyogp by adding higher level client related functionality. Recently, this functionality was split out into a separate python package ('''pyogp.lib.client'''), and sample scripts (and future apps) were moved into '''pyogp.apps'''.

== Architecture Overview==

=== Structure ===

PyOGP is comprised of three python packages. The library consists of pyogp.lib.base and pyogp.lib.client, while sample scripts, and in time applications, live in pyogp.apps.
:'''pyogp.lib.base''' - consists of basic networking, messaging systems (UDP and event queue) and capabilities, custom datatypes, and a low level message related event system
:'''pyogp.lib.client''' - consists of 'convenience' classes mapping methods and handlers to specific messages (e.g. Agent().say(msg) tells the client to send the ChatFromViewer message to the host region). Raises application oriented events based on processing of messages (these are currently sparsely implemented)
:'''pyogp.apps''' - sample scripts and works in progress, the scripts here generally illustrate simple usage of classes as related to in world interactions by an agent of a Second Life grid

=== Dependencies ===

==== Platform / Python version compatibility ====

PyOGP aims to be compatible across platforms, though there are known problems with various environments. We'll be focusing on ensuring better compatibility soon.

'''Known good configurations'''

:Windows XP + Python 2.5
:Mac + Python 2.5, 2.6
:Linux + Python 2.4, 2.5, 2.6 (Linden hosts fall into this group)

'''Known bad configurations'''
:Windows Vista + Python 2.6
:Windows 7 + Python 2.6

There have been challenges in ensuring compatibility between the various dependencies, largely due to greenlet, eventlet, and pyopenssl. Please report bugs on [http://jira.secondlife.com/browse/PYO pJira]

==== Python module dependencies ====

The packages that make up PyOGP have some dependencies on python modules not included in a standard install, or sometimes not available on an older Python distribution.

'''pyogp.lib.base dependencies:'''

<python> #from setup.py

install_requires=[
'setuptools',
# -*- Extra requirements: -*-
'uuid',
'elementtree',
'indra.base',
'WebOb',
'wsgiref',
'eventlet==0.8.14'
]</python>

'''pyogp.lib.client dependencies:'''

<python> install_requires=[
'setuptools',
# -*- Extra requirements: -*-
'pyogp.lib.base'
] </python>

'''pyogp.apps dependencies:'''

<python> install_requires=[
'setuptools',
'pyogp.lib.client'
]</python>

=== How to install ===

''Lindens can see internal documentation for more specific guidance. https://wiki.lindenlab.com/wiki/Pyogp#How_to_Install''

==== Standalone dev environment using buildout ====

Buildout is a type of Python development environment, organizing and configuring various components and their dependencies. On a desktop, one may checkout such an environment for working with PyOGP. One may optionally use a virtualenv Python environment to isolate the development code and it's runtime environment on one's host.

Dependencies: buildout takes care of everything, grabbing needed modules etc.

Wiki instructions: https://wiki.secondlife.com/wiki/Pyogp/Client_Lib/The_Development_Sandbox

==== Installing the PyOGP packages ====

Each of the PyOGP package may be installed to one's Python install or to a [http://pypi.python.org/pypi/virtualenv virtualenv]. '''Buyer beware''' if installing into your system's install: you'll want to be able to uninstall manually, as we haven't hooked up the uninstall. PyOGP is still coming up to speed with respect to distutils and pypi and the like, but it's relatively close now.

To install a package, simply run 'python setup.py install' in a package's root.

==== Referencing PyOGP packages via the PATH ====

Source code can be referenced directly if one simply ensures that a package, and it's dependencies, are available in the PYTHONPATH environmental variable.

== Current functional coverage ==

Anything not listed as covered is probably not yet covered.

pyogp.lib.base:
:* base udp messaging system (message.*)
:** UDP serialization/deserialization
:** message_template.msg parsing
:* base event queue messaging system (event_queue.EventQueueClient())
:* capabilities and their methods. Seed capabilities are a special case. (caps.Capability())
:* Message-based events (message.message_handler)

pyogp.lib.client:
:* agents (agent.Agent())
:** L$ balance request, friending, and walk/fly/sit/stand actions...
:* OGP agentdomain (agentdomain.AgentDomain())
:* application level events (event_system.AppEventsHandler())
:* some object handling (objects.*)
:** edit name, description, next-owner permissions and more
:** object creation is possible
:* some inventory handling (inventory.*)
:** login inv skeletons
:** fetching inventory, including AIS (caps based Agent Inventory Services))
:** some creating of new inventory items (LSL scripts, notecards)
:* regions (region.Region())
:** host and neighboring regions are handled slightly differently
:** udp and event queue connections are optionally enabled for each case
:** currently only pulling caps available to the agent via the seed cap (plus using the inventory related caps in the AIS context)
:* some appearance handling (appearance.AppearanceManager),
:* parcels
:* chat
:* some ImprovedInstantMessage handling
:** raises events on received instant messages
:** can deal with inventory offers/accepts/declines
:** other cases in this message are currently only logged
:* groups
:* group chat
:* LSL script uploading

=== Sample Scripts ===

There are a variety of scripted examples that have been used to exercise and test functionality as it is added to the library. These persist as coded documentation.

The source code is available in https://svn.secondlife.com/svn/linden/projects/2008/pyogp/pyogp.apps/trunk/pyogp/apps/examples/.

The following refers to a buildout context. If one installs pyogp.apps vi setup.py, these scripts will exist in the python environment's bin/ directory. In the buildout context, these scripts are available in {buildout root}/bin.

The scripts are derived from a package's 'setup.py' via the entry_points parameter, and essentially build executable Python scripts configured to run in the correct environment with the proper dependencies added the the path used by the script. These scripts are currently just simple illustrations of some uses of the PyOGP codebase.

<python> #the current entry_points in setup.py og pyogp.apps:

entry_points={
'console_scripts': [
'AIS_inventory_handling = pyogp.apps.examples.AIS_inventory_handling:main',
'agent_login = pyogp.apps.examples.agent_login:main',
'agent_manager = pyogp.apps.examples.agent_manager:main',
'appearance_management = pyogp.apps.examples.appearance_management:main',
'chat_and_instant_messaging = pyogp.apps.examples.chat_and_instant_messaging:main',
'group_chat = pyogp.apps.examples.group_chat:main',
'group_creation = pyogp.apps.examples.group_creation:main',
'inventory_handling = pyogp.apps.examples.inventory_handling:main',
'inventory_transfer = pyogp.apps.examples.inventory_transfer:main',
'inventory_transfer_specify_agent = pyogp.apps.examples.inventory_transfer_specify_agent:main',
'login = pyogp.apps.examples.login:main',
'multi_region_connect = pyogp.apps.examples.multi_region_connect:main',
'object_create_edit = pyogp.apps.examples.object_create_edit:main',
'object_create_permissions = pyogp.apps.examples.object_create_permissions:main',
'object_create_rez_script = pyogp.apps.examples.object_create_rez_script:main',
'object_creation = pyogp.apps.examples.object_creation:main',
'object_properties = pyogp.apps.examples.object_properties:main',
'object_tracking = pyogp.apps.examples.object_tracking:main',
'parcel_management = pyogp.apps.examples.parcel_management:main',
'parse_packets = pyogp.apps.examples.parse_packets:main',
'region_connect = pyogp.apps.examples.region_connect:main',
'smoke_test = pyogp.apps.examples.smoke_test:main',
'chat = pyogp.apps.examples.chat_interface:main',
]
}</python>

== How it Works (High Level) ==

=== Eventlet ===

PyOGP use [[Eventlet]] to run coroutines to handle multiple 'concurrent' processes, rather than threads or multiple processes. Each client agent instance will spawn a handful of coroutines to handles e.g. the UDP pipe, the Event Queue, various monitors, while yielding time to the parent process which should ensure it yields to the other routines as well.

PyOGP uses eventlet in very elementary ways at this point, but will perhaps start to use blocking queues in some cases, so that the coroutine only is allocated processing time if there is work for it to do.

=== pyogp.lib.base ===

This package handles the protocols used when communicating with a Second Life grid. A high level perspective on the package reveals a MessageManager() (still in development) which provides an interface to the UDP and Event Queue connections, as well as basic networking with enables login and capabilities interactions. The base package also has a low level even system through which all messages are passed and sent to subscribers.

Any subcomponent is available for direct interaction at any time, the MessageManager() and the MessageHandler() are the simple access points.

==== Events & Callbacks ====

The event implementation in pyogp follows the observer pattern, where observers subscribe to and are notified when an event occurs. Data is passed throughout the client instance via events.

* MessageManager - is an attribute of a Region and every packet received/sent is filtered through here. subscriptions are by message name
** MessageHandler - is an attribute of MessageManager, and every categorized message received from the event queue or udp dispatcher is filtered through here. (message as defined in message_template.msg, or one of ['ChatterBoxInvitation', 'ChatterBoxSessionEventReply', 'ChatterBoxSessionAgentListUpdates', 'ChatterBoxSessionStartReply', 'EstablishAgentCommunication']. There may be unhandled messages, I just haven't seen em yet :))

===== Message Events =====

In the most fundamental implementation of event usage, all packets are passed through a MessageManager() instance for evaluation. Observers may register to receive udp packets serialized into the form of Message() instances. The MessageHandler() is a consolidation point for subscribing to messages keyed by message name, and created on demand via subscription.

See pyogp.lib.base.message.message_handler.MessageHandler() for more details.

The pyogp agent's Region() instances each monitor their stream of packets (e.g. the host region: agent.region.message_manager.message_handler). (Perhaps this should be changed to a generalized Network() class where all packets (coupled to their originating regions) are evaluated.

Event firing passes data on to a callback handler defined in the subscription, in the form of (handler, *args, **kwargs).

The Agent class monitors the ImprovedInstantMessage packet:
<python> onImprovedInstantMessage_received = self.region.message_handler.register('ImprovedInstantMessage')
onImprovedInstantMessage_received.subscribe(self.onImprovedInstantMessage)

def onImprovedInstantMessage(self, packet):
""" handles the many cases of data being passed in this message """

{code} # parse and handle the data...</python>

The messaging system then fires the event when an ImprovedInstantMessage message is received, which calls onImprovedInstantMessage method above to handle the message contents. Multiple subscribers may be listening for any message related event, and each would be notified of the same Message() instance.

Unsubscribing from an event:
<python> onImprovedInstantMessage_received.unsubscribe(self.onImprovedInstantMessage)</python>

There are various event and callback implementations viewable in pyogp, poke around and help consolidate things if you like.

=== pyogp.lib.client ===

The client package generally provides a convenient interface to initiate or interpret interactions with host region (or neighboring regions). By listening to the messaging related event system in pyogp.lib.base, the client package interprets the messages that come in off the wire, and executes business logic in building responses. pyogp.lib.client also provides simple methods to enable the ending of messages to a grid.

==== Events ====

* EventsHandler - an attribute of an Agent, also able to be passed in, that is intended as the primary interface of a pyogp application into the internal state and data events within the lib. This system uses the same base classes as used by the MessageHandler() in the base package, and the descriptions about events and callbacks above apply here as well. The api for subscribing to these events is similar to the MessageHandler(), with an additional timeout parameter passed in the _register() method. When the specified timeout expires, the subscription returns None and expires the subscription.

==== Agent Login (examples) ====

===== Single Agent Login & Chat=====

Spawn a client in a co-routine, allowing persistent presence until forcefully terminated.

<python>from eventlet import api

from pyogp.lib.client.agent import Agent
from pyogp.lib.client.settings import Settings

settings = Settings()

settings.ENABLE_INVENTORY_MANAGEMENT = True
settings.MULTIPLE_SIM_CONNECTIONS = False

client = Agent(settings = settings)

api.spawn(client.login, options.loginuri, 'first', 'last', 'password', start_location = options.region)

# wait for the agent to connect to it's region
while client.connected == False:
api.sleep(0)

while client.region.connected == False:
api.sleep(0)

client.say("Hello World!")

# once connected, live until someone kills me
while client.running:
api.sleep(0)</python>

===== Multiple Agent Login =====

Each agent instance in logged in in a separate coroutine.

<python>from pyogp.lib.client.agent import Agent
from pyogp.lib.client.agentmanager import AgentManager

clients = [['agent1', 'lastname', 'password'], ['agent2', 'lastname', 'password']]
agents = []

# prime the Agent instances
for params in clients:
agents.append(Agent(settings, params[0], params[1], params[2]))

agentmanager = AgentManager()
agentmanager.initialize(agents)

# log them in
for key in agentmanager.agents:
agentmanager.login(key, options.loginuri, options.region)

# while they are connected, stay alive
while agentmanager.has_agents_running():
api.sleep(0)</python>

== Extending Functionality ==

While the implementations and structures in pyogp.lib.base can (and are in the process of) being refactored to improve performance or usability, it is a fairly complete package.

The functional coverage PyOGP provides on the other hand is not complete, and there are a variety of needs to complete the implementation in pyogp.lib.base. We need to improve coverage of message handling (dealing with messages sent to the client), add more wrappers for sending various messages and performing multistep tasks (to simplify the initiation of interactions with the region), and we need to raise more application level events in the client package so that applications have easy access to incoming data.

=== Sending Messages ===

PyOGP, like the Viewer, communicates with the Second Life simulator by sending messages over UDP.

In order to extend PyOGP, you'll build a representation of a new UDP message, and send it through the pyogp.lib.base modules for serialization and wire handling.

=== Example: Sending an IM ===

To send an IM to the simulator, send an ImprovedInstantMessage packet. The base class for message packets is defined in <code>base/message/message.py</code>

Packets are assembled using a Message() instance which has the message name and Block() instances passed in through its constructor. Similarly, Blocks are assembled by passing in the Block name and the value name and values for each of the Block values. (The ability to build Message() instances via an llsd payload is expected to be introduced soon.)

Note: It is important that the message name, block name, and value names and types should match what is specified in the message template. (It is also possible to manipulate the representation of the stored template, or to use a custom message template.)

Example:
<python> def send_ImprovedInstantMessage(self, AgentID = None, SessionID = None,
FromGroup = None, ToAgentID = None,
ParentEstateID = None, RegionID = None,
Position = None, Offline = None,
Dialog = None, _ID = None, Timestamp = None,
FromAgentName = None, _Message = None,
BinaryBucket = None):
"""
sends an instant message packet to ToAgentID. this is a
multi-purpose message for inventory offer handling, im, group chat,
and more
"""

packet = Message('ImprovedInstantMessage',
Block('AgentData',
AgentID = AgentID,
SessionID = SessionID),
Block('MessageBlock',
FromGroup = FromGroup,
ToAgentID = ToAgentID,
ParentEstateID = ParentEstateID,
RegionID = RegionID,
Position = Position,
Offline = Offline,
Dialog = Dialog,
ID = UUID(str(_ID)),
Timestamp = Timestamp,
FromAgentName = FromAgentName,
Message = _Message,
BinaryBucket = BinaryBucket))

# Send the message:
self.region.enqueue_message(packet, True)</python>

=== Handling Incoming Messages and Raising an Event ===

To listen for when messages of a particular type are sent to the client instance, subscribe to the MessageHandler() on the host region's MessageManager(), like the example that follows:

<python> onImprovedInstantMessage_received = self.region.message_handler.register('ImprovedInstantMessage')
onImprovedInstantMessage_received.subscribe(self.onImprovedInstantMessage)</python>

When the event is fired upon receipt of the message matching the name, the specified callback handles the data passed along, and in this case raises an event notifying observers of the 'InstantMessageReceived' event in pyogp.lib.client of the important data.

<python> def onImprovedInstantMessage(self, packet):
""" callback handler for received ImprovedInstantMessage messages. much is passed in this message, and handling the data is only partially implemented """

Dialog = packet.blocks['MessageBlock'][0].get_variable('Dialog').data
FromAgentID = packet.blocks['AgentData'][0].get_variable('AgentID').data

if Dialog == ImprovedIMDialogue.InventoryOffered:

self.inventory.handle_inventory_offer(packet)

# ...
# some of the Dialogue types this message can contain are handled, we are showing 2
# ...

elif Dialog == ImprovedIMDialogue.FromAgent:

# ... code parses the data from the Message() instance ...

message = AppEvent('InstantMessageReceived', FromAgentID = FromAgentID, RegionID = RegionID, Position = Position, ID = ID, FromAgentName = FromAgentName, Message = _Message)

logger.info("Received instant message from %s: %s" % (FromAgentName, _Message))

self.events_handler.handle(message)</python>

== Logging ==

Uses python's standard logging module (http://docs.python.org/library/logging.html). The library defines logging events throughout, it is up to the application/script to determine the output.

Hooking logging into a new module:

<python>from logging import getLogger

# initialize logging
logger = getLogger('pyogp.lib.client.agent')

class Agent(object):
""" our agent class """

def __init__(self, params):

self.params = params

logger.debug("Initializing agent with params: %s" % (params))</python>

An application can then set up the logging output as follows (or any other way it pleases):

<python>console = logging.StreamHandler()
formatter = logging.Formatter('%(asctime)-30s%(name)-30s: %(levelname)-8s %(message)s')
console.setFormatter(formatter)
logging.getLogger('').addHandler(console)
logging.getLogger('').setLevel(logging.DEBUG)</python>

The output to console is then:

<bash>2009-04-21 22:08:58,681 pyogp.lib.base.agent : DEBUG agent with params: params</bash>

== Pyogp Unit Tests ==

See [[PyOGP_Package_Unittests]].

== Sphinx (api docs) ==

'''Api documentation is now available for PyOGP packages''' (well, not for apps yet, but someday....)!

In pyogp/docs in each of the pyogp.lib.base and pyogp.lib.client packages, one will find source, last revision, and build files for sphinx based documents. Output is available at {package root}/docs/html/index.html.

We plan on sharing the api documentation on the web soon, and will work to make simple build wrappers work on various platforms, though this is a low priority.

Ask Enus for updated documentation to be checked in, or, build a better refresh.py.

== Roadmap ==

See [[Pyogp/Roadmap]] for details, or ask in irc or on the mailing list. Here's what's up in the near term for pyogp:

* better '''packaging''' and '''platform compatibility'''
* more '''functional coverage''' of message. We are covering 32% of the messages the viewers sends or handles when received (though it's estimated at more like 50% of normal use cases.
* '''permissions system testing''' to save QA from 3-5 day regression passes on perms
* '''appearance''' - this will require enabling upload and download, plus baking. Anyone have some spare time? :)

[[Category: Pyogp_Client_Lib]]
[[Category: Pyogp]]
[[Category:Architecture Working Group]]
[[Category:Grid_Interoperability]]
[[Category:AW Groupies]]
[[Category:MMOX]]