Back to the channels

#java

05:13 jreicher ,ping
05:14 KnownSyntax ,pong
05:14 jreicher I 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. :)
07:21 [twisti] ping
07:21 [twisti] ~ping
07:21 javabot http://www.nataliedee.com/071405/ping.jpg
07:27 jreicher I can access that jpg. :(
07:27 jreicher ^can^can't
07:30 [twisti] yeah, me neither
09:12 Para ~syn
09:12 javabot Para, what does that even *mean*?
09:12 Para aww
09:13 Para dreamreal: 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.
10:11 deebo xa transaction over ircd, RFC 420
10:12 deebo -69
10:45 dreamreal Para: yes
10:46 dreamreal ~ping
10:46 javabot Uh.. wha?
10:46 dreamreal ^^^ for javabot, KnownSyntax and jreicher
10:46 Square Say 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?
10:47 dreamreal exclusions.
10:47 Square s/Spring want/Spring and want/
10:47 dreamreal Square: exclusions.
10:48 Square dreamreal, yeah I'm thinking
10:48 dreamreal cool. your conclusion will be "exclusions."
10:49 Square People developing B can be pretty cheaty and if pressure is high enough they'll probably remove the exclude.
10:51 Square I'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.
10:51 deebo have project-A and project-A-spring, and possible project-A-spring-boot-starter
10:52 Square (the goal is for them not to tamper with stuff they shouldn't cause it leads to complicated code/projects)
10:52 dreamreal The 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
10:52 dreamreal deebo: it depends on how A is written and why, but yes
10:53 deebo indeed, 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
10:54 dreamreal Para: 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.
10:54 deebo the whole thing will probably actually break when jersey and a few others have jackson3 support and spring-boot can drop jackson2 compat libs
10:54 dreamreal deebo: yeah. jackson3 is actually kinda annoying me.
10:56 dreamreal Para: 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
10:56 Square dreamreal, why?
10:56 dreamreal Square: why what?
10:56 Square why jackson3 annoys you?
10:56 Square Just curios, never tried it
10:56 deebo if you import a @Configuration class with a bean, it always disables boot autoconfig and spring only has a mechanism to ignore autoconfigs, not configs
10:56 deebo ^ disables autoconfig for that bean (e.g. datasource)
10:57 dreamreal because 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.
10:57 Square ah ok
10:57 Square I kinda of like programmatic jackson2, I loathe the annotation stuff.
10:58 dreamreal I 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
10:58 dreamreal lots of muscle memory is being disrupted
10:58 dreamreal jreicher: grr, you weren't here: ~ping is for the bot
10:58 dreamreal and I have a toy for you to try out!
10:59 Square Maybe witnesses will allow better json handling.
10:59 dreamreal Depends on what "better" means - I found jackson's json to be pretty peak. Maybe not THE FASTEST but the happiest medium.
11:01 Square I'm thinking of the fact that OpenAPI3 + jackson is miles behind other languages.
11:01 Square (some at least)
11:01 dreamreal openapi isn't relevant for jackson.
11:01 dreamreal What does jackson do that's "miles behind other languages?"
11:01 Square jackson can be relevant to openapi
11:01 dreamreal so you're complaining about openapi, as do we all, it's a piece of crap. What does that have to do with jackson?
11:01 jreicher dreamreal: I'll read the javabot log in a bit. Just have to take care of a few things.
11:03 dreamreal jreicher: I was just mentioning the javabot ping from earlier - nevet and javabot are unrelated :D
11:03 dreamreal but *nevet* has a new toy
11:04 Square dreamreal, The annotations (around inheritance) seems too powerful / relaxed to match an openapi specification.
11:04 dreamreal Square: with all due respect, I get it, but you're complaining about an impedance mismatch *in openapi*
11:05 Square I think openapi is pretty well made.
11:05 dreamreal the 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
11:05 dreamreal it's very well intentioned, yes
11:05 dreamreal ~barbie api
11:05 javabot <barbie>api is hard!</barbie>
11:06 Square All I can say, from experience with other libs and languages is that jackson + schema based json rpc is a failure atm.
11:07 Square ...and you can argue all day about wo me changing my mind. =D
11:07 dreamreal and I can tell you from working with programmers the world over that the failure is unrelated to jackson and schema
11:07 Square about it*
11:07 dreamreal I have no interest in changing your mind
11:07 dreamreal but you're blaming the wrong thing
11:07 dreamreal which is inefficient
11:07 Square who should I blame then?
11:08 dreamreal the 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
11:08 dreamreal you could yeet schema, you could yeet jackson, and you'd have the same problem, thus jackson is not the problem
11:09 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"
11:09 dreamreal ^^^ this is the error I'm looking at here
11:15 dreamreal although 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.
11:16 dreamreal You 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.
11:17 dreamreal I'd say most openapi specs are designed like, to use the technical term, "ass."
11:19 dreamreal or maybe "poo." or perhaps the rather formal "boogers." or maybe the slightly less formal but still pretty posh "boogers made of poo."
11:22 dreamreal Para: 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)
11:31 dreamreal Para: daaaaaaaaaaaaang. You just gave me a KILLER idea, thank you.
11:40 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
11:40 dreamreal with it. But that's not STATEFUL...)
11:40 dreamreal but I just had an idea for a USEFUL stateful interaction with the bot that aligns very well with the original intent :D
11:42 deepy Last time I worked with an openapi spec it turned out the vendor that produced it didn't even follow their own spec
11:43 deepy And that's when I learned there's specific functionality for fixing other people's spec and I just gave up
11:44 Square Well, that's good then. I mean that you could resolve they didn't follow the spec.
11:46 Square Then you can either tell them and or avoid working with them in the future.
11:46 dreamreal I mean, "this api follows the spec poorly" is a pretty safe assumption to make :D
11:47 deepy What's the point of providing a spec if I have to write my own anyways?
11:47 dreamreal in 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.
11:48 dreamreal deepy: it's actually a reminder that you surely needed that people are terrible at doing things
11:48 dreamreal a 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
11:49 Square Science 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.
11:50 deepy dreamreal: I don't need reminding, I'm people, I'm terrible at doing things
11:50 deepy I 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
11:51 dreamreal deepy: well, screw you, you're a terrible person (I work for the redundancy department of redundancy) and you're terrible at doing things!
11:51 Square =D
11:52 Square I mean one big reason we fail is that the libraries we use are crap.
11:53 Square ...and languages
11:53 dreamreal I 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
11:54 dreamreal I know I come off as a judgemental assnozzle, but I don't mean to PLUS I'm probably a judgemental assnozzle
11:55 Maldivia ahh... it's good to see even if I've neglected IRC for a while, that some things never change... *wave* hi dreamreal :D
11:55 dreamreal WHOA MALDIVIA SIGHTING
11:56 dreamreal how's it going, mate?
11:57 Maldivia it's going... been waaay too busy, not enough hours in the day :/
11:58 dreamreal yeah, I know how that feels all too well. Thankfully AI is here to remove some of the weight, right?
11:58 Square dreamreal, I agree with your correction
11:58 Maldivia "hey claude, can you log in to IRC and impersonate me, so people don't think I'm gone"
11:59 dreamreal Maldivia: /m nevet !be dreamreal
11:59 Square ...to a point. Some languages are just dated and inconsistent
11:59 dreamreal actually, if you're privmsging it it probably doesn't need the !
12:00 deepy dreamreal: 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
12:00 Maldivia :D
12:01 deepy I only redesigned the entire thing from not-quite-scratch 4 times, and gave up when the vendors API didn't even work
12:01 dreamreal Maldivia: markov chain. Remember surial?
12:01 Maldivia yeah
12:01 dreamreal Maldivia: 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
12:02 Maldivia dreamreal: and rightfully so... :D
12:02 dreamreal so 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
12:03 dreamreal that was RIGHT AROUND the time he got mad at us for not enjoying how caustic he was and left the channel
12:03 dreamreal but 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
12:06 dreamreal the 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)
12:07 dreamreal nevet is NOT a good idea to run on security-conscious mediums :D
12:07 Maldivia dreamreal: well, that does free true to the training subject :D
12:07 dreamreal right? I mean if you don't want it to capture you being a fool, don't be a fool!
12:10 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.)
12:10 Maldivia nice
12:11 dreamreal but 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
12:11 dreamreal and the same for slack or irc (this channel is, for example, irc://libera/#java)
12:11 dreamreal it's muted HERE though, because I don't want it to compete with javabot
12:12 dreamreal (if anyone wants to play with it, there's a channel where it's unmuted on libera)
12:14 deepy is it more coherent than megahal was?
12:15 dreamreal I don't know what megahal was so I have no comparison point
12:16 dreamreal I 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.
12:17 dreamreal It 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
12:18 dreamreal I really do need to buckle down and get the certs and deployment online, then the github webhooks can be used
12:18 dreamreal I just enjoy that side of things very little
16:05 dreamreal Para: all those nevet restarts are your fault :D It's almost done though
16:07 Para dreamreal: there's better be a killer demo
16:07 dreamreal nevet's VERY first iteration from 2006 was done with OSGi so you could update functionality without restarting anything, but, well, OSGi