Open mkroman opened 4 years ago
Out of tree implementations do have the advantage that they don't need to be updated every time I make changes in rink-core. The one thing I'd suggest is that rink-core
is available on crates.io and could be used instead of developing in a fork of the main repo, as long as you don't need to make local changes that can't be upstreamed.
As for NOTICE
, I originally picked it because it's intended for bot messages - the IRC RFC it says this about it:
The NOTICE command is used similarly to PRIVMSG. The difference between NOTICE and PRIVMSG is that automatic replies MUST NEVER be sent in response to a NOTICE message. This rule applies to servers too - they MUST NOT send any error reply back to the client on receipt of a notice. The object of this rule is to avoid loops between clients automatically sending something in response to something it received.
This is typically used by services, and automatons (clients with either an AI or other interactive program controlling their actions).
I don't really use IRC anymore so I don't have a lot of interest in maintaining the IRC bot in-tree.
Alright, I'll go ahead and create a rink-irc repo, but it'll be slightly opinionated (i.e. .c <query>
to run
rink-core is available on crates.io and could be used instead of developing in a fork of the main repo, as long as you don't need to make local changes that can't be upstreamed.
Currently my breaking changes are mostly about color formatting - maybe this is something that could be upstreamed? Some kind of formatting trait for the varying returned expressions? Maybe even serde serializable?
You could generate custom strings based on the response objects (which are Serde-serializable), like rink-web does to generate HTML. That's a very overkill solution for just adding IRC color codes though, I agree that there should be an upstream way to do this. Maybe a "tokenized" representation that would make assigning colors much easier, or a formatting trait like you said.
Something like this:
struct Span {
content: String,
token: TokenType,
}
enum TokenType {
// Generic text like the `Definition:` part
Text,
Operator,
Number,
Unit,
// The `^2` in `m/s^2`
UnitPower,
// Other stuff could be added.
...
}
You could construct a color string like this, using this representation:
let mut output = String::new();
for span in spans {
match span.token {
TokenType::Number => output.push_str("make the text orange"),
TokenType::DocString => output.push_str("make it italic"),
_ => (),
}
output.push_str(&span.content);
output.push_str("magic code to reset formatting to defaults");
}
(in a real impl of course you'd probably generate fewer reset codes and such)
[
// Spaces could potentially be their own TokenType but I left that out for brevity.
{ content: "Definition: ", token: TokenType::Text },
{ content: "foot", token: TokenType::Unit },
{ content: " = ", token: TokenType::Text },
{ content: "12", token: TokenType::Number },
{ content: " inch", token: TokenType::Unit },
...
{ content: "International yard and pound, since July 1, 1959.", token: TokenType::DocString },
}
I want to get back to working on Rink so this might be a good thing to work on soon. The CLI app could potentially support colors as well.
I just updated the irc bot, it compiles in tree now. It doesn't support sandboxing yet but currency and color highlights are there.
Hi,
I noticed that the IRC implementation is no longer maintained.
I'm already maintaining a newer IRC implementation in my own fork, albeit with some pretty breaking changes to the output formatting, but I wouldn't mind maintaining a branch where I could submit the changes upstream without the personalized formatting (although I do disagree with the use of
NOTICE
overPRIVMSG
due to how many clients considerNOTICE
s to be "highlights/notifications")I do have a question, though — I've also recently done a matrix client implementation that I'm willing to maintain for the duration that I'm using Matrix (pardon me for the code quality, it's heavily copied and rushed :smile:) and I was wondering if at this point you might prefer out-of-tree implementations you could refer to?