| Age | Commit message (Collapse) | Author |
|---|
|
Follow the same format used in 08077a854a63884de619034d6762aa5b18ed2f91
with the argument description in lowercase surrounded by angle brackets.
|
|
To aid the readability of the help output, align the dashes vertically
so the descriptions are in a uniform place.
The resulting output now looks like this:
<git_sha> – Generate a commit URL based on the given SHA.
git remote set origin URL – Set the git remote URL for this channel.
help – Show a list of available bot commands.
|
|
Use lowercase and brackets instead of a shell-style capitalised
identifier. In the help output, this looks better to me. Inspired by
Hubot.
|
|
Instead of printing all help text on a single line as a result of
joining the list of help text, print each plugin's help on a separate
line.
Also separate commands from descriptions with a dash instead of a tab as
the tab character was getting rendered as an `I` in irssi instead of the
actual whitespace I had been hoping for. The dash in inspired by Hubot.
In order to print multiple lines of output, we needed to change the IRC
PRIVMSG handler. This now splits the plugin result at newlines into a
list and sends separate PRIVMSGs for each line of output. Before, text
with newlines would only show the first line in the resulting IRC
message.
Assume plugin error messages will always be a single line.
|
|
Since the style we're following favours vertical alignment, align these
record definitions aroung the `=` signs.
|
|
A new plugin that displays a help listing for every plugin in the bot.
Currently the formatting is off in the chat output, but it does work.
This introduces two new record fields on `Plugin`: `command` and
`description`. The command is the text used to invoke the plugin and the
description is a long form explanation of what the plugin does.
Needed to update the `Show` for `Plugin` to match these extra fields.
Didn't change any of the output for now because I'm not really using the
`show` function, so I don't need to see the new fields for now. Also
change the `p` argument to an `_` because we're not using it.
All existing plugins now have the new fields filled. The Help plugin
will go through the list of all plugins and get their help fields for
output.
In order to be able to use the plugin list in both `Plugin.hs` and in
the Help plugin module, I needed to move the list into a new module to
avoid a circular dependency. Previously the `Plugin` module defined the
list, but we can't import `Plugin` from `Help` because `Plugin` needs to
import `Help` in order to build the full list of plugins. The
semi-hackish solution I came up with was to create a new module for the
plugin list that both these modules can use, but leave out the `Help`
plugin from the plugin list there. Then, `Plugin` and `Help` override
the list, appending the `Help` plugin to the list. I want the Help
plugin to appear last, which is why I'm appending. Wasn't comfortable
concatenating the list because of the performance smell, but it's going
to be a small enough list anyway that it shouldn't be a problem.
One thing I don't really like is the fact that we have to return an
`IO a` from `helpAction` even though it doesn't interact with `IO` at
all. Not sure if there's a way to use `IO` when we need it and not when
we don't. Not a huge deal though.
|
|
Use 'optparse-applicative' to parse command line options.
Provide a `--slack-token` option that sets a Slack API token to enable
access to the chat platform.
More options will come as needed (including things like database name,
language, possibly IRC configuration).
Code is based on the example in
https://hackage.haskell.org/package/optparse-applicative
Pretty cool option parser.
|
|
Previously I had moved the `{` to the previous line because I was
getting compilation errors with it on a new line. Turns out whitespace
is important here. We just need to indent it an extra time and the
compiler understands us. Now this section matches the style of the rest
of the project.
|
|
Get rid of this package because we're no longer using it. Instead we're
going it alone for i18n (dde184a6e24b88f8d6628f4652d5c42ed0f016b2).
Also delete the translation .msg file.
|
|
Follow the example
https://wiki.haskell.org/Internationalization_of_Haskell_programs_using_Haskell_data_types
to get i18n.
Get rid of the Shakespeare-I18N code. The idea of using text files to
define translation strings was nice, but since I couldn't get it working
with ease and couldn't find examples outside of a Yesod context, I
decided to chuck it and go with the alternative, simpler approach.
Really liking this system. Simplified things a bit from the example
since we only need to show one language at a time. Will need to figure
out how to use the same language throughout the program.
|
|
An unsuccessful attempt at getting i18n working through Shakespeare. Had
a little help from:
https://gist.github.com/nicolashery/f87467fb37da2b00cec1eed028f51e60
Unfortunately, I can't figure out how to get this working. Even before,
without the locale stuff and defining a custom `translate` function,
when I tried using Shakespeare's `_{}` function, I was, and still am,
getting this error:
src/Plugin/GitHubCommit.hs:38:29: error:
Data constructor not in scope: MsgGitHubCommitRepoURLNotFound
Yes, obviously, that makes sense. But how do I get it to be in scope if
it isn't even in my code? What?
I'm giving up on Shakespeare for i18n. It was a nice idea, I liked the
fact that strings were stored in external files, but I don't know how to
do this, I can't find the right resources online to use this in a
non-web non-template context, and it's becoming a pain. Going to get rid
of all this code and just use regular Haskell data types to do it as
described in
https://wiki.haskell.org/Internationalization_of_Haskell_programs
|
|
en.msg:
* Remove comment lines because apparently comments aren't allowed by the
parser
* Change data type to `T.Text` to match the import from the `I18n`
module
GitHubCommit.hs:
Import the `I18n` module because we'll be testing it in context in a
bit, but for now just want to get the module code to compile.
I18n.hs:
Follow the example on http://www.yesodweb.com/book/internationalization
to make a function for proper internationalisation.
|
|
To allow us to take advantage of its `Text.Shakespeare.I18N` feature.
|
|
This will enable us to translate our messages into multiple languages
using Yesod's Shakespeare package.
|
|
|
|
|
|
Instead of just responding with the given URL, include a message in
English to let users know that the value was saved.
|
|
|
|
|
|
I had used `INSERT` as a placeholder while trying to get the plugin
working properly. This would create a row every time the "git remote set
origin" command was invoked. What I really wanted was an upsert.
Looked through a number of different ways of accomplishing that in
SQLite:
- https://stackoverflow.com/questions/418898/sqlite-upsert-not-insert-or-replace/7511635#7511635
- https://stackoverflow.com/questions/15277373/sqlite-upsert-update-or-insert
Ended up settling on this solution from CL.:
https://stackoverflow.com/questions/20323174/upsert-in-sqlite/20326705#20326705
It seemed to be pretty clean and understandable, so I leveraged that
approach.
|
|
Finally figured out how to get a capture group out of the regex match.
Needed to coerce as a two-dimensional `String` list.
Thanks to:
- https://stackoverflow.com/questions/24699279/cant-capture-a-group-in-a-string
- https://stackoverflow.com/questions/6729158/find-all-capturing-groups-of-a-regular-expression
Get the captured group and set it to the URL to insert into the
database. It lives in the second element of the first list:
Prelude Text.Regex.TDFA> "git remote set origin https://example.new" =~ "^git remote set origin ([^ ]+)$" :: [[String]]
[["git remote set origin https://example.new","https://example.new"]]
Prelude Text.Regex.TDFA> "" =~ "^git remote set origin ([^ ]+)$" :: [[String]]
[]
|
|
|
|
This plugin provides a command to set a git commit repo URL for use with
the `GitHubCommit` plugin. Typing
git remote set origin URL
in chat will set that URL to the current channel.
Problems:
* Can't figure out how to use capture groups, so the entire matched
message string comes back, not just the URL
* Need to upsert instead of insert into the database
|
|
Mark off recently completed tasks.
|
|
Clean up some of the calls to get the `text` field by adding a function
that abstracts the call to `Data.Text(unpack)`.
|
|
Use the `Data.Text` type instead of `String` in most of the places we
use it in `Plugin` and `Message`.
This allows us to more easily pass data between the IRC package. No more
kludgy `pack`s and `unpack`s in our IRC message handler.
The one thing we couldn't convert was our regex. From what I understand
(https://stackoverflow.com/questions/14922579/haskell-regular-expressions-and-data-text#14922626),
the regex library I'm using doesn't support `Data.Text`, so use
`String`s for that instead.
|
|
When a PRIVMSG comes in from an individual user instead of a channel,
invoke our plugins so we're doing the same thing in both cases.
|
|
This was there as a test but didn't work. It's no longer needed, so we
can remove it.
|
|
Handle our un-handled `Nothing` branches. Make `privmsgFromPlugin`
return a `Maybe` so we can decide whether or not to send a message
upstream.
If we do get a `Nothing` from `privmsgFromPlugin`, just return unit and
don't send any chat message, since no plugin matched and thus none could
respond.
|
|
We have some code that's duplicated in both branches of the `Either`
case statement that sends a response over IRC. Extract that to a new
function that can be shared between the two case statements to try to
reduce repetition.
Took me a while to wrangle the monads to get this, but it's in working
condition now. Need to add the commented `Nothing` branch in so I'm
handling all the cases.
|
|
I had a bunch of code commented from earlier and from false starts when
working on integrating my plugins and the IRC message handler. Remove
these commented lines now as they are no longer relevant. The actual
code is functioning.
|
|
|
|
Instead of sending a hard-coded string message over IRC, now invoke our
plugin list.
Now, IRC messages get matched against our plugin list, and if any plugin
matches, its return string gets posted to the appropriate channel.
Move the database connection inside the plugin so that we can continue
to access it without having to pass in the DB connection. I didn't want
to connect to the database in the IRC code because it doesn't relate,
and I don't have a good enough grasp of monads to know if I can create
the connection in "Lib.hs" and "pass" it to the IRC message handler to
then pass it into the plugins.
Moving the database connection inside the plugins means that it no
longer takes a database connection as an argument.
The IRC message handler now has a lot of duplication, but it basically
works, which is super exciting! Took a _long_ time to figure out the
proper way to get the types to line up and get this compiling, but
really glad it's working now! The magic function turned out to be
`liftIO` to extract the `Either String String` out of its `IO` monad
wrapper to be fed to the `IRC.send` function.
Not a fan of the type conversion between `String` and `Data.Text`, so
we'll eventually have to convert our plugins to use `Data.Text`.
|
|
Now that we have something sort of working on the IRC side of things, we
can move it out into its own module to keep `Lib` clear and tidy.
|
|
We don't need this information. I was just saving it to find out what
that argument actually was.
|
|
Instead of always responding on a hard-coded channel, the bot now
responds on the channel the PRIVMSG was received on. This can be either
a regular channel or a query message.
The `serv` argument is apparently the message sender's hostname. Wanted
to print it out to see what that argument was.
I had been following this example from "barrucadu"'s 'yukibot':
https://github.com/barrucadu/yukibot/blob/31930b234eb423ed74546b56ada100105c1680ce/yukibot-backend-irc/Yukibot/Backend/IRC.hs#L152-L156
but the code ignored the first `Event` argument. In order to send it as
a chat message, needed to convert it to a `Data.Text`, using the method
courtesy of this tutorial:
https://haskell-lang.org/tutorial/string-types
|
|
Add an event handler that gets called when a message is posted to a
channel the bot is on. When a message is posted, the bot will send a
chat message containing the text "test".
This tests out the message handling and posting mechanism, and gives us
a place to build off of to allow the bot to communicate.
|
|
Make it a bit more obvious where these functions are coming from by
prefixing them with `IRC.`.
|
|
The 'irc-client' package depends on 'cryptonite'. I was getting this
compilation error from 'cryptonite' on my machine:
[111 of 111] Compiling Crypto.Cipher.AES ( Crypto/Cipher/AES.hs, .stack-work/dist/x86_64-osx/Cabal-1.24.2.0/build/Crypto/Cipher/AES.o )
cc1: error: unrecognized command line option "-maes"
`gcc' failed in phase `C Compiler'. (Exit code: 1)
The package recommends disabling AESNI via a compile flag to get around
this error
(https://github.com/haskell-crypto/cryptonite#known-building-issues):
cabal configure --flag='-support_aesni'
Add 'cryptonite' to our `extra-deps` in order to be able to set a flag
on it. Turn off the `-support_aesni` flag in order to facilitate
compilation.
|
|
Add the 'irc-client' package to facilitate communication over IRC.
Copy the example from:
http://hackage.haskell.org/package/irc-client-0.4.4.4/docs/Network-IRC-Client.html
which connects to a network. We specify a channel to join, and what do
you know, it works! Pretty cool.
Commented out the code that runs the GitHub Commit plugin for now while
testing this.
Add the `OverloadedStrings` extension so we can write string literals
but have them converted into the appropriate `Data.Text` and
`Data.ByteString` types required by the IRC library.
|
|
|
|
The `=` was previously aligned with the function definition below, but
since the pattern match of the lower function definition changed, the
`=`s were no longer aligned.
Seems like it would be weird to move the `=` out and create a bunch of
blank space to align the two `=`s, so moving the function body to the
next line.
|
|
|
|
It's duplicated so I figured I'd take it out.
|
|
Get rid of the `fail` and use an `Either` for error handling instead.
This allows us to send back the response string like before, but provide
an additional error message when no data comes back from the database
query.
Remove the old error handling code I had tried to set up previously.
|
|
This doesn't really work, but I wanted to hold onto this step. I've been
reading about error handling, notably this article:
http://www.randomhacks.net/2007/03/10/haskell-8-ways-to-report-errors/
I kind of like the idea of just using `fail`, and being able to have
that set up some polymorphism to handle `Maybe`, `Either`, and `IO`
situations, but today read some literature that discouraged using fail,
since not all monads implement it.
Anyway, this code doesn't print out the error string like I intended it
to, so I guess I'll have to use `Either` instead.
|
|
A few tasks to set up some clear next steps.
|
|
We don't need to select the channel because we don't do anything with
it. All we need is the repo URL.
Create a new data type for use with the database query that allows us to
select only the URL. Remove the `ChannelRepoUrl` type as it's no longer
needed.
|
|
Ask for the row corresponding to the channel received from the chat
message. This gets rid of the previously hard-coded SQL and allows us to
dynamically get the right URL value.
|
|
Added these while developing ff00355ade021d3e06d55017c5337f488474e5cb to
test out different theories while trying to get the project to compile.
These are no longer relevant any more, so delete them.
|
