ByteCode.News
RSS
SubmitLog in

Community

Chat Logs

Thursday, March 5, 2026

  1. jreicher,ping
  2. KnownSyntax,pong
  3. jreicherI thought javabot had a test like this. Might be mixing it up with another bot. No matter can see it logged us. So test passed. :)
  4. [twisti]ping
  5. [twisti]~ping
  6. javabothttp://www.nataliedee.com/071405/ping.jpg
  7. jreicherI can access that jpg. :(
  8. jreicher^can^can't
  9. [twisti]yeah, me neither
  10. Para~syn
  11. javabotPara, what does that even *mean*?
  12. Paraaww
  13. Paradreamreal: can nevet do stateful commands? e.g. I say "syn", it replies "syn/ack", after that I sy "ack", then an action occurs. I literally have no use for this beyond that.
  14. deeboxa transaction over ircd, RFC 420
  15. deebo-69
  16. dreamrealPara: yes
  17. dreamreal~ping
  18. javabotUh.. wha?
  19. dreamreal^^^ for javabot, KnownSyntax and jreicher
  20. SquareSay you're having a maven project B that depends on A. You're fine with A using Spring. You're not fine with B using Spring want to make it close to impossible to do it. What would be a good approach to achieve this? Some maven plugin like enforcer plugin? Write your own scanning plugin that finds banned package imports?
  21. dreamrealexclusions.
  22. Squares/Spring want/Spring and want/
  23. dreamrealSquare: exclusions.
  24. Squaredreamreal, yeah I'm thinking
  25. dreamrealcool. your conclusion will be "exclusions."
  26. SquarePeople developing B can be pretty cheaty and if pressure is high enough they'll probably remove the exclude.
  27. SquareI'd happy if I could execute mvn from the command line on the project with some switches and then just know they're not using Spring.
  28. deebohave project-A and project-A-spring, and possible project-A-spring-boot-starter
  29. Square(the goal is for them not to tamper with stuff they shouldn't cause it leads to complicated code/projects)
  30. dreamrealThe good news is that "depending on spring" is one of those "oh no you mean I have to have a dependency that everyone uses?" things, but I get it
  31. dreamrealdeebo: it depends on how A is written and why, but yes
  32. deeboindeed, we depend on one project that has e.g. a @Configuration class with @Bean @Qualifier("our-fancy-project") public DataSource datasource(), that's not fun on spring boot
  33. dreamrealPara: for ack/syn it'd be really easy: in nevet, there's a provenance for operations that says "this is who and where this is from," which can be "a channel" or "a person on a channel" or even "a network" (irc, libera) or "a service" (just IRC, period, regardless of network), and there's a storage mechanism that uses provenance. That's how hangman, 21, safecracker all work.
  34. deebothe whole thing will probably actually break when jersey and a few others have jackson3 support and spring-boot can drop jackson2 compat libs
  35. dreamrealdeebo: yeah. jackson3 is actually kinda annoying me.
  36. dreamrealPara: I'm working on a MUCH more complex game that will have much larger storage requirements than those toys: it will ALSO be a toy, but one that pushes things a little harder than those games do
  37. Squaredreamreal, why?
  38. dreamrealSquare: why what?
  39. Squarewhy jackson3 annoys you?
  40. SquareJust curios, never tried it
  41. deeboif you import a @Configuration class with a bean, it always disables boot autoconfig and spring only has a mechanism to ignore autoconfigs, not configs
  42. deebo^ disables autoconfig for that bean (e.g. datasource)
  43. dreamrealbecause they changed the mechanisms through which you use it. If you know how to do X with jackson2 for configuration, jackson 3 does not necessarily have the same surface.
  44. Squareah ok
  45. SquareI kinda of like programmatic jackson2, I loathe the annotation stuff.
  46. dreamrealI think there's a potential for things to have been improved, in that the type structure makes sense, but dang it I've been using jackson for years
  47. dreamreallots of muscle memory is being disrupted
  48. dreamrealjreicher: grr, you weren't here: ~ping is for the bot
  49. dreamrealand I have a toy for you to try out!
  50. SquareMaybe witnesses will allow better json handling.
  51. dreamrealDepends on what "better" means - I found jackson's json to be pretty peak. Maybe not THE FASTEST but the happiest medium.
  52. SquareI'm thinking of the fact that OpenAPI3 + jackson is miles behind other languages.
  53. Square(some at least)
  54. dreamrealopenapi isn't relevant for jackson.
  55. dreamrealWhat does jackson do that's "miles behind other languages?"
  56. Squarejackson can be relevant to openapi
  57. dreamrealso you're complaining about openapi, as do we all, it's a piece of crap. What does that have to do with jackson?
  58. jreicherdreamreal: I'll read the javabot log in a bit. Just have to take care of a few things.
  59. dreamrealjreicher: I was just mentioning the javabot ping from earlier - nevet and javabot are unrelated :D
  60. dreamrealbut *nevet* has a new toy
  61. Squaredreamreal, The annotations (around inheritance) seems too powerful / relaxed to match an openapi specification.
  62. dreamrealSquare: with all due respect, I get it, but you're complaining about an impedance mismatch *in openapi*
  63. SquareI think openapi is pretty well made.
  64. dreamrealthe loose typing supported by other languages is part of the problem, and jackson has no bearing here; you'd see the same problem with ANY json library
  65. dreamrealit's very well intentioned, yes
  66. dreamreal~barbie api
  67. javabot<barbie>api is hard!</barbie>
  68. SquareAll I can say, from experience with other libs and languages is that jackson + schema based json rpc is a failure atm.
  69. Square...and you can argue all day about wo me changing my mind. =D
  70. dreamrealand I can tell you from working with programmers the world over that the failure is unrelated to jackson and schema
  71. Squareabout it*
  72. dreamrealI have no interest in changing your mind
  73. dreamrealbut you're blaming the wrong thing
  74. dreamrealwhich is inefficient
  75. Squarewho should I blame then?
  76. dreamrealthe way openapi works with types (it really doesn't, it's very loose) working with a language (java) that does not really respect typing that has no meaning
  77. dreamrealyou could yeet schema, you could yeet jackson, and you'd have the same problem, thus jackson is not the problem
  78. dreamreal"it's definitely the red thing over there, but when we took out the red thing, the problem remained, so it's DEFINITELY the red thing"
  79. dreamreal^^^ this is the error I'm looking at here
  80. dreamrealalthough I'd also have a minor issue with the word "blame" here. It's not a guilt thing, nobody's doing anything especially WRONG, openapi works the way it does because it works for the general case with systems that use types as suggestions, so it uses types as suggestions, and java rather famously does NOT. Hello, impedance mismatch. Note how I didn't mention schema or jackson here.
  81. dreamrealYou can get around it by being very careful in how YOU design openapi specs, and how you consume them. But the whole point of openapi is to be *open* and that's a difficult thing to require in the el real world-o.
  82. dreamrealI'd say most openapi specs are designed like, to use the technical term, "ass."
  83. dreamrealor maybe "poo." or perhaps the rather formal "boogers." or maybe the slightly less formal but still pretty posh "boogers made of poo."
  84. dreamrealPara: incidentally, building that kind of operation would be pointless in nevet but it could be done pretty easily, maybe 10 minutes of work? Tops? (mostly because of infrastructure requirements, because an operation is a structural thing in nevet)
  85. dreamrealPara: daaaaaaaaaaaaang. You just gave me a KILLER idea, thank you.
  86. dreamreal(the problem with !syn/!ack is that it's a human protocol: if you were modeling human interactions off of UDP, you'd go to your friend and say "ack?" and he'd respond with "syn" or "nack" to say "yes" or "no" as a very light interaction that would hopefully interrupt flow as little as possible. But the bot doesn't have that problem: it's ALWAYS available, thus "ping" is an appropriate interaction
  87. dreamrealwith it. But that's not STATEFUL...)
  88. dreamrealbut I just had an idea for a USEFUL stateful interaction with the bot that aligns very well with the original intent :D
  89. deepyLast time I worked with an openapi spec it turned out the vendor that produced it didn't even follow their own spec
  90. deepyAnd that's when I learned there's specific functionality for fixing other people's spec and I just gave up
  91. SquareWell, that's good then. I mean that you could resolve they didn't follow the spec.
  92. SquareThen you can either tell them and or avoid working with them in the future.
  93. dreamrealI mean, "this api follows the spec poorly" is a pretty safe assumption to make :D
  94. deepyWhat's the point of providing a spec if I have to write my own anyways?
  95. dreamrealin nevet, the openapi spec is updated *every build* - it runs right alongside spotless, so if you change any endpoints, the git repo gets an updated openapi spec. That also meant I needed to sort the openapi doc so it was consistent, but eh.
  96. dreamrealdeepy: it's actually a reminder that you surely needed that people are terrible at doing things
  97. dreamreala poorly done openapi spec means someone probably had their fingers in the spec when it should have been purely generated... or the generation was so poorly done that the spec is meaningless
  98. SquareScience has gotten far enough to know what type systems it's easy enough to reason about on a *exact* level. No api should go beyond that limit.
  99. deepydreamreal: I don't need reminding, I'm people, I'm terrible at doing things
  100. deepyI even forgot to run obfuscation on a project I sent to someone else, so they got to see stacktraces with classes named SqlThing and FailureProneGoogleSheet
  101. dreamrealdeepy: well, screw you, you're a terrible person (I work for the redundancy department of redundancy) and you're terrible at doing things!
  102. Square=D
  103. SquareI mean one big reason we fail is that the libraries we use are crap.
  104. Square...and languages
  105. dreamrealI was going to point at the languages and their type systems, rather than libraries, and I'd say they're less "crap" and more "too flexible for specific applications to derive usefully" but felt like I was correcting you too often already today :D
  106. dreamrealI know I come off as a judgemental assnozzle, but I don't mean to PLUS I'm probably a judgemental assnozzle
  107. Maldiviaahh... it's good to see even if I've neglected IRC for a while, that some things never change... *wave* hi dreamreal :D
  108. dreamrealWHOA MALDIVIA SIGHTING
  109. dreamrealhow's it going, mate?
  110. Maldiviait's going... been waaay too busy, not enough hours in the day :/
  111. dreamrealyeah, I know how that feels all too well. Thankfully AI is here to remove some of the weight, right?
  112. Squaredreamreal, I agree with your correction
  113. Maldivia"hey claude, can you log in to IRC and impersonate me, so people don't think I'm gone"
  114. dreamrealMaldivia: /m nevet !be dreamreal
  115. Square...to a point. Some languages are just dated and inconsistent
  116. dreamrealactually, if you're privmsging it it probably doesn't need the !
  117. deepydreamreal: don't worry, I have a lot of redundancy, I have at least 3 classes to spare that I shipped despite no longer needing them
  118. Maldivia:D
  119. deepyI only redesigned the entire thing from not-quite-scratch 4 times, and gave up when the vendors API didn't even work
  120. dreamrealMaldivia: markov chain. Remember surial?
  121. Maldiviayeah
  122. dreamrealMaldivia: one of the things that got me to build nevet's very first gen was surial bitching that he wasn't actually negative, how dare idiots think such awful trash, they were clearly deficient human beings
  123. Maldiviadreamreal: and rightfully so... :D
  124. dreamrealso I captured the logs from him, fed it into a markov chain, and did sentiment analysis on the *chain* generating content, and figured if the markov chain generated negative sentiment, we had a conclusion
  125. dreamrealthat was RIGHT AROUND the time he got mad at us for not enjoying how caustic he was and left the channel
  126. dreamrealbut the idea's been around since then, I just slapped it into nevet's current codebase a few days ago so I could have a clojure operation :D
  127. dreamrealthe markov chain DOES generate nonsense, especially given that it has no initial seed to START the chain (it's not responding to anything, plus it uses ALL content from a user regardless of channel or medium, so if you're discussing furry NFSW content on discord, well, that's... something you're saying, so it's part of the chain)
  128. dreamrealnevet is NOT a good idea to run on security-conscious mediums :D
  129. Maldiviadreamreal: well, that does free true to the training subject :D
  130. dreamrealright? I mean if you don't want it to capture you being a fool, don't be a fool!
  131. dreamreal(and yes, nevet can track identity across discord and slack and irc, so it knows who I am regardless of what I use to interact with it: it has a service binding to user for services that support user validation. I can tell it to say something on discord or slack *from irc* and it can bridge mediums; there's one channel here on IRC that's echoed on discord and vice versa, too.)
  132. Maldivianice
  133. dreamrealbut I can tell it to tell discord://foo/user1234 something and, well, it'll post content there if it has permissions to do so from discord
  134. dreamrealand the same for slack or irc (this channel is, for example, irc://libera/#java)
  135. dreamrealit's muted HERE though, because I don't want it to compete with javabot
  136. dreamreal(if anyone wants to play with it, there's a channel where it's unmuted on libera)
  137. deepyis it more coherent than megahal was?
  138. dreamrealI don't know what megahal was so I have no comparison point
  139. dreamrealI mean, nevet's still a bot, it responds to interactions deterministically, so it can certainly do things to be very noisy: teh safecracker game is pretty noisy, for example. But it's not designed to be generally mutable (i.e., users can put in factoids but not generative processes, without running nevet themselves) so it's not going to spam channels without being told to do so.
  140. dreamrealIt has an RSS feed mechanism and a github poller (no webhooks yet, but that's because SOMEONE sucks at setting up deployed web endpoints) and THOSE might push to a channel, too, but it separates polls and channel notifications, so it can poll an RSS feed and only have certain channels subscribed to it
  141. dreamrealI really do need to buckle down and get the certs and deployment online, then the github webhooks can be used
  142. dreamrealI just enjoy that side of things very little
  143. dreamrealPara: all those nevet restarts are your fault :D It's almost done though
  144. Paradreamreal: there's better be a killer demo
  145. dreamrealnevet's VERY first iteration from 2006 was done with OSGi so you could update functionality without restarting anything, but, well, OSGi