| 10:57 |
asciilifeform |
!q uptime |
| 10:57 |
snsabot |
asciilifeform: time since my last reconnect : 2d 13h 5m |
| |
~ 6 hours 58 minutes ~ |
| 17:55 |
phf |
asciilifeform: http://p.bvulpes.com/pastes/6wcKt/?raw=true that's the CTCP action bits |
| 17:56 |
asciilifeform |
ty phf , makes sense |
| 17:57 |
* |
phf ... rest might be utf until you encounter a closing 0x1 |
| 17:58 |
asciilifeform |
seems to me that 0x01 can't even occur in utf8 at all, so safe to lose'em entirely at the intake filter |
| 17:59 |
phf |
ah but then somebody typing |
| 17:59 |
* |
phf foo |
| 17:59 |
phf |
is equivalent to typing /me foo |
| 17:59 |
asciilifeform |
btw wb , phf |
| 17:59 |
phf |
eh |
| 17:59 |
* |
asciilifeform foo' == '/me foo' tho |
| 18:00 |
phf |
well, if you want to parse /me ctcp actions |
| 18:00 |
* |
phf 0x1 wrapped around it |
| 18:01 |
asciilifeform |
currently it's a barbaric regexp on 'ACTION' at start of payload |
| 18:01 |
asciilifeform |
seems like the 0x01 doesn't occur anywhere else, can match on it there and lose it |
| 18:01 |
phf |
right, exactly |
| 18:02 |
phf |
and it should only ever occur at the end of action string, unless the action was too long, so the 0x1 at the end will be cutoff. on irc protocol level. |
| 18:03 |
phf |
ok, hope that helps. |
| 18:03 |
asciilifeform |
it does, ty phf |
| 18:05 |
asciilifeform |
phf if yer back inbiz , plz can update http://btcbase.org/patches?patchset=m ? ty |
| 18:05 |
asciilifeform |
( and http://btcbase.org/patches?patchset=ffa also, diana_coman posted buncha sigs ) |