We discussed in the November 2007 meeting Todd doing a presentation of Net::Jabber::Bot. We also considered the possibility of maintaining the module as a group. The following is a summary of the project from Todd.

Existing perl Jabber bots in the field

Jpb seemed like a good candidate to me originally so I wouldn't have to write my own. The problem as I got into it was that the code badly mixed with the config so that I would have to alter the modules any time I wanted to change something. I decided to write my own.

Net::Jabber::Bot Synopsis

The module heavily leverages Net::Jabber, which is really just a thin shell on top of Net::XMPP. I have developed this module over the last few months to allow me to separate out the things one wants to do with a bot from the things that can get you in a lot of trouble with a bot. The assumption I started with is that most people simply want to create a bot that can do something every once and while and that is able to react when new messages it cares about are sent. This is what the module aims to do.

Needed code enhancements to the module.

1. Needs to be able to react to version requests. This requires being able to generate customized messages. This trick is documented between Net::XMPP and Net::Jabber, but I lack the object-oriented experience to implement it.
2. Needs to be able to tell what messages are just history messages. Currently the bot does this by ignoring everyone for a period on startup. I consider this to be a hack at the moment that sometimes fails if the server is slow.
3. Make test is a mess. Almost all of the tests require a jabber server to be present. This is making the modules tests to look very red on the automated CPAN testers site. Robert and Wade told me I should be programming to the interface. This sounds like a grand plan but I have no idea what it means :)
4. Some of my design decisions could use a closer look as to some of the values being hard coded, etc. Originally I envisioned a Net::Jabber::Bot being inherited from Net::Jabber::Bot::Safety, but I decided to just merge the 2 ideas. I'd love to explore if the choice I made was a good one.
5. Currently the module is initialized and connections are made via a new being fed a hash from hell. It feels like a kludgy approach to me at the moment.
6. The re-connect algorithm seems to have issues
7. While it's perfectly safe to connect to a jabber server with the same username, it's very dangerous to the server to connect with the same user/resource. Unfortunately I haven't figured out a way to detect that I'm doing this. As a result I've been "chastised" by server admins for not noticing that I hadn't killed the old bot when I started the new one up.
8. Ability to add/leave forums at times other than startup. Probably a good candidate for removal from new. I don't know what to look for to detect if the join succeeded. Right now I'm just assuming the room joins succeed.

Documentation need

1. POD documentation is a little loose on the existing subs. I'm not documenting the private ones at all except for a few comments in the file. Not sure what the etiquette is on this. I really don't think they should be showing up on CPAN and if I pod them, they will.
2. Need code examples on how to leverage the bot. This is pretty easy to provide, but I haven't reverse engineered someone else's CPAN to figure out how they do this to make it look right in CPAN.

Hosted Project

The perl-net-jabber-bot project is currently hosted on the Google Code site.

We discussed in the November 2007 meeting Todd doing a presentation of Net::Jabber::Bot. We also considered the possibility of maintaining the module as a group. The following is a summary of the project from Todd.

Existing perl Jabber bots in the field

Jpb seemed like a good candidate to me originally so I wouldn't have to write my own. The problem as I got into it was that the code badly mixed with the config so that I would have to alter the modules any time I wanted to change something. I decided to write my own.

Net::Jabber::Bot Synopsis

The module heavily leverages Net::Jabber, which is really just a thin shell on top of Net::XMPP. I have developed this module over the last few months to allow me to separate out the things one wants to do with a bot from the things that can get you in a lot of trouble with a bot. The assumption I started with is that most people simply want to create a bot that can do something every once and while and that is able to react when new messages it cares about are sent. This is what the module aims to do.

Needed code enhancements to the module.

1. Needs to be able to react to version requests. This requires being able to generate customized messages. This trick is documented between Net::XMPP and Net::Jabber, but I lack the object-oriented experience to implement it.
2. Needs to be able to tell what messages are just history messages. Currently the bot does this by ignoring everyone for a period on startup. I consider this to be a hack at the moment that sometimes fails if the server is slow.
3. Make test is a mess. Almost all of the tests require a jabber server to be present. This is making the modules tests to look very red on the automated CPAN testers site. Robert and Wade told me I should be programming to the interface. This sounds like a grand plan but I have no idea what it means :)
4. Some of my design decisions could use a closer look as to some of the values being hard coded, etc. Originally I envisioned a Net::Jabber::Bot being inherited from Net::Jabber::Bot::Safety, but I decided to just merge the 2 ideas. I'd love to explore if the choice I made was a good one.
5. Currently the module is initialized and connections are made via a new being fed a hash from hell. It feels like a kludgy approach to me at the moment.
6. The re-connect algorithm seems to have issues
7. While it's perfectly safe to connect to a jabber server with the same username, it's very dangerous to the server to connect with the same user/resource. Unfortunately I haven't figured out a way to detect that I'm doing this. As a result I've been "chastised" by server admins for not noticing that I hadn't killed the old bot when I started the new one up.
8. Ability to add/leave forums at times other than startup. Probably a good candidate for removal from new. I don't know what to look for to detect if the join succeeded. Right now I'm just assuming the room joins succeed.

Documentation need

1. POD documentation is a little loose on the existing subs. I'm not documenting the private ones at all except for a few comments in the file. Not sure what the etiquette is on this. I really don't think they should be showing up on CPAN and if I pod them, they will.
2. Need code examples on how to leverage the bot. This is pretty easy to provide, but I haven't reverse engineered someone else's CPAN to figure out how they do this to make it look right in CPAN.

Hosted Project

The perl-net-jabber-bot project is currently hosted on the Google Code site.

We discussed in the November 2007 meeting Todd doing a presentation of Net::Jabber::Bot. We also considered the possibility of maintaining the module as a group. The following is a summary of the project from Todd.

Existing perl Jabber bots in the field

Jpb seemed like a good candidate to me originally so I wouldn't have to write my own. The problem as I got into it was that the code badly mixed with the config so that I would have to alter the modules any time I wanted to change something. I decided to write my own.

Net::Jabber::Bot Synopsis

The module heavily leverages Net::Jabber, which is really just a thin shell on top of Net::XMPP. I have developed this module over the last few months to allow me to separate out the things one wants to do with a bot from the things that can get you in a lot of trouble with a bot. The assumption I started with is that most people simply want to create a bot that can do something every once and while and that is able to react when new messages it cares about are sent. This is what the module aims to do.

Needed code enhancements to the module.

1. Needs to be able to react to version requests. This requires being able to generate customized messages. This trick is documented between Net::XMPP and Net::Jabber, but I lack the object-oriented experience to implement it.
2. Needs to be able to tell what messages are just history messages. Currently the bot does this by ignoring everyone for a period on startup. I consider this to be a hack at the moment that sometimes fails if the server is slow.
3. Make test is a mess. Almost all of the tests require a jabber server to be present. This is making the modules tests to look very red on the automated CPAN testers site. Robert and Wade told me I should be programming to the interface. This sounds like a grand plan but I have no idea what it means :)
4. Some of my design decisions could use a closer look as to some of the values being hard coded, etc. Originally I envisioned a Net::Jabber::Bot being inherited from Net::Jabber::Bot::Safety, but I decided to just merge the 2 ideas. I'd love to explore if the choice I made was a good one.
5. Currently the module is initialized and connections are made via a new being fed a hash from hell. It feels like a kludgy approach to me at the moment.
6. The re-connect algorithm seems to have issues
7. While it's perfectly safe to connect to a jabber server with the same username, it's very dangerous to the server to connect with the same user/resource. Unfortunately I haven't figured out a way to detect that I'm doing this. As a result I've been "chastised" by server admins for not noticing that I hadn't killed the old bot when I started the new one up.
8. Ability to add/leave forums at times other than startup. Probably a good candidate for removal from new. I don't know what to look for to detect if the join succeeded. Right now I'm just assuming the room joins succeed.

Documentation need

1. POD documentation is a little loose on the existing subs. I'm not documenting the private ones at all except for a few comments in the file. Not sure what the etiquette is on this. I really don't think they should be showing up on CPAN and if I pod them, they will.
2. Need code examples on how to leverage the bot. This is pretty easy to provide, but I haven't reverse engineered someone else's CPAN to figure out how they do this to make it look right in CPAN.

Hosted Project

The perl-net-jabber-bot project is currently hosted on the Google Code site.

For the January 2006 meeting, Paul Archer presented a new project he was working on. The idea was to provide Perl access to the USB Visual Signal Indicator from Delcom Engineering. This project was based on a set of articles in the Linux Journal. For more information on the origin of the project, see the notes on the first presentation.

Since the Delcom VSI is a USB device, controlling it from Perl requires a Perl interface to USB. At the time Paul began working on this there was a minimal module on CPAN for access to USB, but nothing complete. There is a C library for accessing USB devices libusb. In order to use this library, we need to be able to call C code from Perl. Paul decided to use the Inline::C module to provide this access.

The February meeting continued the group development of some prototype code that was able to exercise the device. Some work was accomplished to clean up the code for accessing the libusb library, but the main focus was on the VSI itself. Since that time, Wade has been adding some time and potential help to the project, focusing mostly on the LibUSB interface and a possible language-based interface to the VSI library. We have also elicited interface design help from the group at large.

The March meeting concluded the sessions on this project. There is still development to do, but as the project moves from a prototyping phase into more traditional development, it appears to be less interesting in a meeting setting. We did a few new experiments and had a bit more discussion about issues relating to getting the LibUSB module ready to be released.

Project Code

This is the latest version of the code developed for this project. Since it is a work in progress, don't be surprised if it is not complete.

• Device::USB::LibUSB module, version 0.02

Lessons Learned

The Delcom documentation is mostly useful. But it did contain a few discrepancies that made life more difficult. In many cases, the text would contain a description of parameters to be passed and then an example to clarify. These two often did not match. In general, the text seems to be right and the example is wrong.

The Delcom documentation is also quite specific about the request type in being 0x08 when making a usb_control_msg call. Unfortunately, not only does that value not work, but example code that does work uses a value of 0xc8. It turns out that the request type actually encodes three pieces of information, not just an address. In our case, the value should be 0x48 for sending data to the device and 0xc8 when requesting data from the device. When just using the function to set control parameters (which is most of what we do) either parameter appears to work.

Although the Inline::C module has been extremely helpful in accessing libusb from Perl, it has also been the source of some difficulty. Since the Inline::C parser is not a full parser, we have seen some cases where function prototypes did not act as expected. In particular, a function with no parameters cannot be declared with void as the parameter list.

Also the "DATA" approach to declaring the C code inline works great in a script, but it does not work so well in a module. The names of functions declared in the inline portion will not be available in the module. This problem can be solved either by moving the code to a here document or directly calling the Inline->init() method after your use Inline call.

References

• Delcom Engineering
• USB Visual Signal Indicator
• Linux Journal articles by Greg Kroah-Hartman:
  • Writing a Simple USB Driver
  • Writing a Real Driver -- In User Space
• libusb
• USB.org: source for specifications and such on the USB.
• Device::USB module providing partial libusb implementation
• Inline::C module for accessing C code from Perl
• Parse::RecDescent module parsing an input language for controlling the VSI
• inline@perl.org mailing list archive

For the January 2006 meeting, Paul Archer presented a new project he was working on. The idea was to provide Perl access to the USB Visual Signal Indicator from Delcom Engineering. This project was based on a set of articles in the Linux Journal. For more information on the origin of the project, see the notes on the first presentation.

Since the Delcom VSI is a USB device, controlling it from Perl requires a Perl interface to USB. At the time Paul began working on this there was a minimal module on CPAN for access to USB, but nothing complete. There is a C library for accessing USB devices libusb. In order to use this library, we need to be able to call C code from Perl. Paul decided to use the Inline::C module to provide this access.

The February meeting continued the group development of some prototype code that was able to exercise the device. Some work was accomplished to clean up the code for accessing the libusb library, but the main focus was on the VSI itself. Since that time, Wade has been adding some time and potential help to the project, focusing mostly on the LibUSB interface and a possible language-based interface to the VSI library. We have also elicited interface design help from the group at large.

The March meeting concluded the sessions on this project. There is still development to do, but as the project moves from a prototyping phase into more traditional development, it appears to be less interesting in a meeting setting. We did a few new experiments and had a bit more discussion about issues relating to getting the LibUSB module ready to be released.

Project Code

This is the latest version of the code developed for this project. Since it is a work in progress, don't be surprised if it is not complete.

• Device::USB::LibUSB module, version 0.02

Lessons Learned

The Delcom documentation is mostly useful. But it did contain a few discrepancies that made life more difficult. In many cases, the text would contain a description of parameters to be passed and then an example to clarify. These two often did not match. In general, the text seems to be right and the example is wrong.

The Delcom documentation is also quite specific about the request type in being 0x08 when making a usb_control_msg call. Unfortunately, not only does that value not work, but example code that does work uses a value of 0xc8. It turns out that the request type actually encodes three pieces of information, not just an address. In our case, the value should be 0x48 for sending data to the device and 0xc8 when requesting data from the device. When just using the function to set control parameters (which is most of what we do) either parameter appears to work.

Although the Inline::C module has been extremely helpful in accessing libusb from Perl, it has also been the source of some difficulty. Since the Inline::C parser is not a full parser, we have seen some cases where function prototypes did not act as expected. In particular, a function with no parameters cannot be declared with void as the parameter list.

Also the "DATA" approach to declaring the C code inline works great in a script, but it does not work so well in a module. The names of functions declared in the inline portion will not be available in the module. This problem can be solved either by moving the code to a here document or directly calling the Inline->init() method after your use Inline call.

References

• Delcom Engineering
• USB Visual Signal Indicator
• Linux Journal articles by Greg Kroah-Hartman:
  • Writing a Simple USB Driver
  • Writing a Real Driver -- In User Space
• libusb
• USB.org: source for specifications and such on the USB.
• Device::USB module providing partial libusb implementation
• Inline::C module for accessing C code from Perl
• Parse::RecDescent module parsing an input language for controlling the VSI
• inline@perl.org mailing list archive

For the January 2006 meeting, Paul Archer presented a new project he was working on. The idea was to provide Perl access to the USB Visual Signal Indicator from Delcom Engineering. This project was based on a set of articles in the Linux Journal. For more information on the origin of the project, see the notes on the first presentation.

Since the Delcom VSI is a USB device, controlling it from Perl requires a Perl interface to USB. At the time Paul began working on this there was a minimal module on CPAN for access to USB, but nothing complete. There is a C library for accessing USB devices libusb. In order to use this library, we need to be able to call C code from Perl. Paul decided to use the Inline::C module to provide this access.

The February meeting continued the group development of some prototype code that was able to exercise the device. Some work was accomplished to clean up the code for accessing the libusb library, but the main focus was on the VSI itself. Since that time, Wade has been adding some time and potential help to the project, focusing mostly on the LibUSB interface and a possible language-based interface to the VSI library. We have also elicited interface design help from the group at large.

The March meeting concluded the sessions on this project. There is still development to do, but as the project moves from a prototyping phase into more traditional development, it appears to be less interesting in a meeting setting. We did a few new experiments and had a bit more discussion about issues relating to getting the LibUSB module ready to be released.

Project Code

This is the latest version of the code developed for this project. Since it is a work in progress, don't be surprised if it is not complete.

• Device::USB::LibUSB module, version 0.02

Lessons Learned

The Delcom documentation is mostly useful. But it did contain a few discrepancies that made life more difficult. In many cases, the text would contain a description of parameters to be passed and then an example to clarify. These two often did not match. In general, the text seems to be right and the example is wrong.

The Delcom documentation is also quite specific about the request type in being 0x08 when making a usb_control_msg call. Unfortunately, not only does that value not work, but example code that does work uses a value of 0xc8. It turns out that the request type actually encodes three pieces of information, not just an address. In our case, the value should be 0x48 for sending data to the device and 0xc8 when requesting data from the device. When just using the function to set control parameters (which is most of what we do) either parameter appears to work.

Although the Inline::C module has been extremely helpful in accessing libusb from Perl, it has also been the source of some difficulty. Since the Inline::C parser is not a full parser, we have seen some cases where function prototypes did not act as expected. In particular, a function with no parameters cannot be declared with void as the parameter list.

Also the "DATA" approach to declaring the C code inline works great in a script, but it does not work so well in a module. The names of functions declared in the inline portion will not be available in the module. This problem can be solved either by moving the code to a here document or directly calling the Inline->init() method after your use Inline call.

References

• Delcom Engineering
• USB Visual Signal Indicator
• Linux Journal articles by Greg Kroah-Hartman:
  • Writing a Simple USB Driver
  • Writing a Real Driver -- In User Space
• libusb
• USB.org: source for specifications and such on the USB.
• Device::USB module providing partial libusb implementation
• Inline::C module for accessing C code from Perl
• Parse::RecDescent module parsing an input language for controlling the VSI
• inline@perl.org mailing list archive