Chat Logs

  1. NeXeNyes, i just had a eureka moment!
  2. NeXeNstupid and as silly as it sounds, it actually works. a very complex thing i've been building from a vision for months (man maybe year and a half now) and it can make a boolean value upper or lower case, as designed!
  3. NeXeNman that's why i love coding, fsck them llms they make you lazy
  4. NeXeNsmall accomplishments give me energy
  5. jreicherUmm, huh?
  6. NeXeNworking on a gui app and just testing. doing simple stuff
  7. NeXeNbut you know, it's nice after putting a lot of effort into a thing, even a simple accomplishment makes things fun
  8. jreicherOh I absolutely know the feeling. It's one of the reasons I like using Emacs. Tiny tweaks have a big impact, and always feel simple in a way. But I'm curious what the thing is you're working on.
  9. NeXeNoh, it's a library
  10. NeXeNlets you provision a pipeline. has a schema code generator (not an llm, think boilerplate reduction) and a gui that lets you essentially do some of the design work visually instead of with json or xml, though you could i guess
  11. NeXeNthe code schema is used to enforce type safety across the pipeline no matter the language. there will be a TS library so can pass via protobuf or classic serialization
  12. NeXeNbut to get to the point where i can simply drag and drop a thing and see that it's type safe and doing it's thing is kinda cool. i had doubts if i had the stamina to stay with a personal project
  13. deeboisn't protobuf typed already?
  14. NeXeNyeah that's why i wanna use it
  15. NeXeNi have become a fan, but it's not always straightforward you know....most people just serialize
  16. deeboprotobuf could be interesting to use instead of json over rest for internal data
  17. deebothink netflix does it like that
  18. NeXeNit's definitely more efficient. but i'm supporting jackson and gson as well just because
  19. deeboapis would have to be more explicit about errors etc as well which would be beneficial
  20. NeXeNyeah
  21. NeXeNi mean you know, i can build tools to inspect protobuf as easy as json. but i'm hoping to keep it at a lower layer where i don't ever have to think about it
  22. deeboour end user apps log all http traffic currently (even most bodies) for debugging etc, would be easier to filter protobuf too, http json has too many gotchas and "non-trivial" parsing to do that
  23. NeXeNoh yeah no joke!
  24. NeXeNhrmm you gave me an idea
  25. deebomaybe time to let claude prototype something :)
  26. NeXeNi have built a filter to filter out pii in logs, i bet it could be adapted to do a similar thing
  27. deebowe use zalandos logbook, it can easily do header and property filtering, like "password": "hunter2" -> "password": "xxx"
  28. NeXeNyeah. i dunno why you gotta log everything, but it sure is handy in a pinch
  29. deebobut what it couldn't do (well), was when given a massive blob of data, like {"id": 5, ... hundreds of nested props ... }, we couldn't just log: {"id":5}, since that's the only important bit
  30. deebowe use MDC with user session ids etc, so it's really easy to see what an user did that lead to an error, or check their claims of some problem that supposedly happened to them
  31. deeboRUM could achieve the same, IF everyone agreed to third party scripts etc, but they don't :)
  32. NeXeNcouldn't you change from a full dump of the req/resp body just filter with something simple to parse the stream and just extract top level keys and full parse just for things i dunno diagnostic, like /id or /status and such and drop the rest, just keep what you need?
  33. NeXeNmaybe you could even populate the mdc at the gateway/filter layer with userId, sessionId, etc and the extracted entity's id?
  34. NeXeNthen you don't really need the raw request, i mean ...you know to figure out what they did
  35. NeXeNmaybe you got plenty of space. you know that's always a thing
  36. deebothat would mean reading the streams going in and out into a buffer, trying (and sometimes failing) to parse into json, filter via code and then output to logs
  37. NeXeNyeah, probably better to just rely on the route bindings instead
  38. deebowe tried it but it didn't really work, would probably be easier with protobuf
  39. NeXeNselective field extraction is cheap
  40. NeXeNi like protobuf. i'm trying to push it into my personal projects. you know it sucks doing that at work....using a new shiny toy just because
  41. hassoon'morning
  42. jreicherjavabot is napping on the job again.
  43. dreamrealI dunno why it's so inconsistent lately, I don't think anything's changed in the code
  44. jreicherI thought it was "consistent" in its behaviour of not reconnecting? Maybe the change is in external factors causing more frequent disconnections?
  45. dreamrealNo clue, not watching the logs
  46. dreamrealnot my server, not my bot :/
  47. Paralibera servers don't allow immediate authentication either, so if the bot's too quick to authenticate, it can fail
  48. hassoon'afternoon
  49. sbalmoswhat isn't "immediate authentication" about authenticating on connect with SASL?
  50. * NeXeN shrugs
  51. jreicherPara: what do you mean? I'm still learning about how IRC works but I thought only nickserv auth mattered, and if the nick is still in use you can use REGAIN. (That's how I have my IRC client setup for when I have a network glitch; it reconnects ASAP)
  52. nimajeyou should use SASL auth with a client certificat if the irc network supports it, like libera does https://libera.chat/guides/certfp
  53. nevetLogin With a Certificate (CertFP)
  54. NeXeNsome people don't use sasl, and you auth a moment later. i dunno i think the bot might have other troubles
  55. NeXeNbut also the network kicked my znc off, which hasn't happened before. like two days ago