| Age | Commit message (Collapse) | Author |
|---|
|
This is the final project. Now that we got rid of the web extension and
native host code, we can move the Lisp code to the root.
|
|
The default executable compiled by SBCL is huge. Copied code from:
https://lispcookbook.github.io/cl-cookbook/scripting.html#building-a-smaller-binary-with-sbcls-core-compression
to produce a smaller executable.
Here's the size comparison:
$ du -hs extreload*
11M extreload-ecl
58M extreload-sbcl
15M extreload-sbcl-compressed
|
|
Set a five second timeout to ensure we don't block endlessly if we send
a WebSocket message and don't receive a response in a reasonable amount
of time.
Chose five seconds arbitrarily, but that seems like more than enough
time to do our work. If it takes longer, something else is probably
wrong.
|
|
|
|
Remove the hard-coded call IDs and replace them with a class that keeps
track of the current call ID and allows for easy incrementing to get the
next ID.
This should allow us to give multiple extension IDs on the command line
and send messages with properly incrementing call IDs.
Didn't touch the `runtime-evaluate-msg` message call ID because that one
is local to the target it's attached to, so we can keep it at ID "1".
|
|
The `main.lisp` file was getting crowded. Move DevTools Protocol-related
functions into a new file.
|
|
Make a new function `parse-options` that parses the command line options
and returns a `config` object. We'll use that object instead of
`options` in `main`. Cleans up the `main` function a bit.
Currently, we just print the `config` object to ensure we're storing the
proper values.
Followed Practical Common Lisp's example to implement `print-object` so
we can see the contents of its slots:
http://www.gigamonkeys.com/book/practical-a-spam-filter.html#the-heart-of-a-spam-filter
Still need to implement error checking for a missing `--socket-url`
option.
|
|
We'll use this as a storage container for the command line options.
|
|
Include the 'unix-opts' library described in
http://lispcookbook.github.io/cl-cookbook/scripting.html#parsing-command-line-arguments
for command line option parsing.
Define the options I need. We want a `--socket-url` option, and a list
of extension IDs as free arguments.
Implement the `-V` version command line argument. Thanks to JJJ
(https://stackoverflow.com/users/1337941/jjj) on Stack Overflow for
describing how to get the version number of an ASDF system:
https://stackoverflow.com/questions/11084339/getting-the-version-of-an-asdf-system/11088022#11088022
Add a new `options.lisp` file where we'll add the option parsing restart
error handling functions required by 'unix-opts'.
|
|
The `sleep` call allowed me to test the behaviour of the program, since
without it, it would exit before the WebSocket messages had a chance to
be sent and received.
But we shouldn't be waiting a fixed number of seconds for the program to
execute. Instead, we should only keep the program alive as long as there
are messages to be sent and received.
This adds a Go-style wait group using my wait-group library that
increments the wait group when we send a WebSocket message, and
decrements it when we receive a WebSocket response. That allows us to
keep the program alive only for the amount of time necessary for the
messages to be exchanged.
|
|
Doesn't make a big difference, just for fun. I like the idea of a
compile-time version of this since it's essentially just renaming
`remove-if-not`.
Move it to a new file so we can include it before it's used in
`main.lisp`.
|
|
Build an executable binary by dumping an SBCL image, using the method
described in:
https://lispcookbook.github.io/cl-cookbook/scripting.html#with-asdf
|
|
Add a `sleep` just in case we need that to have time to print the
message.
Use the `jsown` project for JSON encoding and decoding.
|
|
Define the package so we can define things inside it.
|
|
Trying to see if I can write the program in Common Lisp. Learned how to
set up an .asd project file and started with some websocket client code
based on the example in:
https://github.com/fukamachi/websocket-driver#client-side
Need to work out how to set up JSON interaction.
|
