Skip to content
Commits on Apr 15, 2012
  1. removed self-closing ifs

  2. Fixed formatting

Commits on Apr 14, 2012
  1. Added return type for nancy

Commits on Apr 13, 2012
  1. Merge pull request #11 from sethwebster/master

    All latest updates
  2. Removed extra line

Commits on Apr 12, 2012
Commits on Apr 11, 2012
  1. Removed Debug Code

  2. Fixed Duplicates

  3. Added SignalR.Client

  4. Updated with all current

  5. Merged

  6. Finally have working bot

Commits on Apr 8, 2012
Commits on Apr 7, 2012
Commits on Apr 6, 2012
  1. Working for latest Jabbr

  2. removed old signalR

Commits on Apr 2, 2012
  1. @davidfowl

    Merge pull request #9 from danzel/master

    davidfowl committed
    Fix Bot.Send to work with the live
  2. @danzel

    Tabs -> Spaces

    danzel committed
  3. @danzel

    Fix up readme

    danzel committed
  4. @danzel
Commits on Mar 15, 2012
  1. @davidfowl

    Merge pull request #8 from mikegeyser/master

    davidfowl committed
    JSON Serialization Error
  2. @mikegeyser

    JSON Serialization Error

    mikegeyser committed
    When attempting to naively connect to a Jabbr server (either fresh clone,
    or, an http 500 error is thrown. Investigating it on local, it
    appeared to be a problem in JSON deserialization. within Newtonsoft.Json
    library I would consistently get "Error parsing comment. Expected: *, got
    n. Line 1, position 1." or similar, depending on which command I was
    attempting to issue.
    Looking at the Signalr.Client sources, it appears that the command (like
    "/help") was the only parameter being passed through to the _hub.Invoke
    arg array which in turn means that it was the only thing being populated
    into the json "data" element. When I investigated what is returned via
    the Jabbr client, there are additional elements sent in this JSON object
    - specifically "id" and "room". Assuming that the id was a generated
    message GUID, I sent a freshly generate Guid through as well, and it
    was successful.
    Initially I wrapped the "command" argument in an anonymous type which
    includes a new Guid, and all worked, but I'm not sure if some commands
    would fail to function because of this.
    I picked up from the JabbR.Client repository that the IHubProxy.Invoke is
    being called with the addition of a null parameter. When I add this second
    parameter, it works just the same. I have gone for this second solution,
    as it appears to be closer to the intended API behaviour.
Commits on Feb 28, 2012
  1. Progress

Commits on Jan 24, 2012
  1. @davidfowl
Something went wrong with that request. Please try again.