ByteCode.News
RSS
SubmitLog in

Community

Chat Logs

Wednesday, March 11, 2026

  1. * Square joined #java
  2. * kusanagi joined #java
  3. * dob1 joined #java
  4. * dob1 joined #java
  5. * x1bncwn joined #java
  6. * droid3 joined #java
  7. droid3I got a huge issue with java programming language. Now i love the language along with many others and its a very powerful language.
  8. droid3However as memory keeps increasing for home computing and definition for HPC supercomputers...etc. aka 16GB , 32GB , 128 , 1TB much ,...100TB DDR...etc
  9. * ChaiTRex joined #java
  10. droid3The language is fundamentally stuck at creating only allowing the creation of arrays of 2GB entries
  11. droid3we are fundamentally stuck with java when creating an array[int] because we can only index an array by signed in we only can create 2GB entries at most.
  12. droid3This is not a limit on the size of the array but a limit on the amount of entries an array can have.
  13. droid3I find this very restrictive. For example BigInteger use arrays internally for the size of numbers so technically the size of an integer is restricted to 2GB digits if each entry stands for one digit.
  14. droid3No for most this aint to much of a problem but for say c/c++ you normally can create arrays index by longs so in this case you can create an array technically with 18,446,744,073,709,551,616 amount of entries
  15. droid318,446,744,073,709,551,616 far exceeds the amount of memory even a supercomputer will have available to it for quite sometime.
  16. droid3So can sun/oracle beef up the array[int] to array[long] or create some indexing datatype that isnt going to suffer from array barriors i call it.
  17. droid3even if long is signed we still would have 9,223,372,036,854,775,808 entries which still be more then enough for quite sometime
  18. droid3I mean alot of my math i do i have to switch back and forth from c/c++ to java when i am dealing with really huge stuff. If only java had bigger array entry creation
  19. droid3This is fundamentally the problem which also restricts all the java Collections to being 2GB entries as well.
  20. droid3However one can piece arrays together and classes can be in theory any size you could construct an array of objects or a class of many arrays.
  21. droid3To exceed the 2GB barrior that java has... however its still not clean one should just add the ability to create larger arrays
  22. * pengu1nx2 joined #java
  23. droid3This is not only for large million and billion digit number computing or math research or fun.
  24. * ForeverDreaming joined #java
  25. droid3There are benefits for nonmath based programs to beable to create large huge bigger then 2GB entry arrays.
  26. * stfstfm joined #java
  27. droid3Before this time not so much because memory was like 4GB or 8GB but now as memory exceeds and is getting ridiculously larger even for home computers. To me it just make sense to account for this in the java programming language. And not only restricted to java but all languages... native languages like c/c++ are easy to keep upgrading/uping the data type size. I imagine VM based languages are more of a challenge
  28. droid3And possiblely can break compatibility with with previous compiled to bytecode programs ...so i understand the reason it may be a hold off feature. But its definitely a feature that needs to be added if java is ever going to survive the future of HPC or bigger data/ more memory.
  29. droid3PM me if you want to talk on the subject its a bother to me. Sure i can use JNI to just call c/c++ do huge array computation in that world but its just better to not have to split shit up and have it all in terms of one java huge array.
  30. droid3At that point i usually would just switch to another language to achieve what i want but i feel it not complete until java has the same abilities
  31. droid3Another issue is if/when you do upgrade java to bigger arrays. I would imagine you also need a feature to shut off garbage collection for certain huge data structures or the garabage collector would chew up most of the computing /processing time searching for null references
  32. * ferdna joined #java
  33. droid3And also i do like garbage collection features in languages but it also would be nice to have the ability to shut them completely off for the whole program or parts of the program or for certain data type/structures you create.
  34. droid3So as to save performance when dealing with huge data structures or huge memory allocation ...etc. We never really cared or need this aspect with the language but now that huge memory and big data/object/data structures are becoming a thing...its going to get important for the performance of the language
  35. * ChaiTRex joined #java
  36. dreamrealdroid3: wait, what
  37. dreamrealdroid3: I don't know what you're doing, I just sat down, but WHAT
  38. dreamrealJava's going to be FINE
  39. dreamrealfor your specific application, who knows
  40. dreamrealValhalla may address some of it, but fixing it isn't trivial, and the number of applications it would address is relatively small, for what it's worth: that doesn't make it better for you, but there ARE efficiency reasons for array indexes being integral.
  41. dreamrealIt would be NICE to have some flexibility here but for 99.9999% of the applications out there - being conservative - not really. (And note that I work in a problem space where this IS a liability.)
  42. droid3So no matter how bigger are memory gets where always going to be stuck at 2GB entry arrays size. I just find that in future is going to be restrictive maybe not for most right now but eventually
  43. droid3So BigInteger will basically be stuck at 2billion digit size representation so wont be like computing the next biggest mersenne prime in this language :)
  44. droid3But joking aside i still think there we are going to want to create sometype of builtin datastructure for java if we cannt fundementally upgrade the int to a long
  45. droid3for arrays
  46. droid3I mean i imagine its far easier to add a bigarray data structure to java then to change the underlying fundamental language of java.
  47. droid3That way new versions of java will be compatible and there wont be any issues with old compiled bytecode...etc
  48. droid3I like java to have a datatype to have unlimited arrays entry sizes... as not only for math but for other huge stuff.
  49. droid3I get changing the builtin data types would break stuff but adding a new datatype wouldnt
  50. droid3Heck newer versions of java added lambda functions abilities and before that generics ,...etc it make sense to have unlimited sizes.
  51. droid3I mean you got BigInteger /BigDecimal in theory these are arbitrary precision crude libraries. I just think you have a way to scale arrays which is the fundemental datatype that allows for scaling everything else.
  52. droid3Really builtin nonarray based data types are when you dont need the precision that exceeds the hardware specific registers/sizes.
  53. droid3when you do you switch to BigNum based libraries. But c/c++ scales arrays entries to any size quite easy with the native language.
  54. droid3java if we just scaled unlimited array entry creations we be perfect.
  55. droid3Aka we have no restrictions on the BigInteger or arbitrary precision libraries as well as no restriction on array entry sizes.
  56. droid3Basically we be independent only restricted /confined to the RAM and storage sizes we have available to us when writting a program.
  57. droid3in java
  58. droid3Also it wouldnt really break bytecode or old JVM /java runtime versions. It just mean you have to run the code on a more modern JVM going forward.
  59. droid3Which usually is the standard typically as you use newer JDK you eventually upgrade the JRE in sync with them.
  60. droid3So it doesnt break portability with existing code running or have to be recompiled unless of course you running it on the new JVM...
  61. droid3So not sure why you say would be to difficult to do so over the benifit.
  62. droid3Bit is not a huge workaround for me it just an inconvenience when doing mathematic computations in this language that all. At the moment.
  63. droid3All languages have there strengths and weakness though it be good to strengthen this aspect for java
  64. * ChaiTRex joined #java
  65. * NeXeN joined #java
  66. jreicherdroid3: is there any particular reason you don't like Vector?
  67. jreicherOr ArrayList?
  68. jreicherI'm not entirely sure what you're after.
  69. * Aedil joined #java
  70. BombeI mean, nobody likes Vector…
  71. BombeBut yeah, sounds like a lot of non-pointiness.
  72. * smlckz joined #java
  73. jreicherI can't remember the last time I used Vector, but it's always the name I think of first. Maybe because of other languages.
  74. * smlckz left #java (WeeChat 4.6.3)
  75. * stfstfm_ joined #java
  76. * agnivn joined #java
  77. * stewi joined #java
  78. * jreicher joined #java
  79. * tabmow joined #java
  80. * lostlazy joined #java
  81. droid3no but vectors are restricted to the same size limit as arrays they just are dynamic in how you can size them where as arrays are fixed.
  82. droid3The issue jreicher is that any java Collection has this max 2GB restriction on the number of entries. I use all kinds of different Collections for different things when i am coding depending on what the problem is/ what i want to use for it.
  83. droid3That not the point its the fundemental restriction on max number of entries dictated by the index being a signed int.
  84. droid3It isnt even the size i came make with objects and arrays of object i can create well over any memory i have on any computer system in the java language like most others as well.
  85. droid3But the issue is for java there is a small limit 2GB on the amount of entries you can create.
  86. droid3Not how big a particular entry is
  87. * Afroboy joined #java
  88. * TomyWork joined #java
  89. * kathadris joined #java
  90. * TomyWork joined #java
  91. deebodefinite "limitation", but if you're hitting an array size limit, you might want to think about what you're doing, there's probably something much mroe suitable
  92. Maldiviaeh yeah, having any collection in memory with more than 2 billion entries sounds like "this needs to be done differently"
  93. * MikeBux joined #java
  94. BombeWhile it’s certain an issue that you can’t create arrays with more than two billion entries, I’m quite certain it’s not the issue for a very, very large amount of people.
  95. Maldiviaand there is a way to get around it also, if you really like
  96. MaldiviaMemorySegment.allocateNative(MemoryLayout.sequenceLayout(1_000_000_000_000, MemoryLayouts.JAVA_INT), globalScope()) -- there you go, an "int array" with 1 trillion entries
  97. Maldiviahope you have enough ram
  98. Maldiviaor simply slice your data int[1024*1024][1024*1024] -- an in array indexing 2^40 ints -- get(long index) { return array{index / (1024*1024)][index % (1024*1024)]; }
  99. Maldiviaso it's a non-issue
  100. * jbosmans joined #java
  101. kcomhnallMaldivia: sooo, you have MemoryLayouts.JAVA_INT for a 1 trillion value? does that work?
  102. Maldiviakcomhnall: no, I have a segment of a trillion entries, each of type JAVA_INT
  103. * kcomhnall would've thought long if anything
  104. Maldiviakcomhnall: on memory level, the above MemorySegment command is equivalent to new int[1_000_000_000_000]
  105. kcomhnallah,.. and the only restriction then is the hardware / hard drive capacity?
  106. Maldiviathe context was that native java arrays are limited to 2^31-1 entries
  107. kcomhnall2billion
  108. Maldivia(technicaly, 2^31-8)
  109. * kcomhnall thinks they were talkin about FFM in here before
  110. Parathat'd be in context of dmlloyd's smallrye-ffm probably
  111. Maldiviadroid3: as for your BigInteger issue - the spec says they support values up to 2^(2^31)
  112. Maldiviaso that's "only" ~ 650 million digits :D
  113. * TomyLobo2 joined #java
  114. * x1bncwn joined #java
  115. * agnivn joined #java
  116. dreamrealyo Maldivia
  117. Maldiviayo yo
  118. * Nemu64 joined #java
  119. dreamrealMaldivia: I spun up a second UI for bytecode.news yesterday: the model works! (Both UIs suuuuuck but that's not the point)
  120. Maldiviadreamreal: so I should be submiting a AI generated UI, you're saying? :D
  121. dreamrealMaldivia: hell, an AI generated both of those! But the key isn't "the UI" - the REST model behind it is working and it's pretty damn fast. I've got an older UI here written by someone else against an old version of the services - the reference ui looks like crap but actually validates the back end well (I found a lot of holes in the services while writing it)
  122. Maldivia:D
  123. dreamrealso now we have a stable API and a good UI can actually keep up. But that's the model I wanted for TSS back in 2007
  124. dreamrealmultiple ingress - one article draft was written with !suggest and another with !article here on IRC, and there're "anonymous posts" (submitted while not logged in) and I can spin up other ingress models for the system really quickly, I think
  125. dreamrealThe UIs really do suck: basic literally does nothing except read and echo, and the reference is an SPA that accounts for some popular bots but otherwise renders nothing up front, which is bad
  126. dreamrealbut the model's working, the reference UI *is* an actual MVP (emphasis on 'M'), and if I get a decent-looking UI up that doesn't rely so heavily on SPA, plus some actual content...
  127. dreamrealI'm gonna see if I can kill TSS
  128. dreamrealThe site isn't anything really "new" in terms of content, TSS was always better at commuting value through curation rather than possession; I don't know of anyone else intentionally designing the multiple egress part nor do I know any other site besides the LLMs who're so aggressive about ingress
  129. dreamrealThe idea is that ... like... okay, today, right? We have two discussions: one is droid3's thing about memory limitations, and then you have the REAL gold in my blathering, of course. But both of these can now easily be *captured* for bytecode.news - in the ideal, I can capture the interactions with droid3 and have them summarized automatically (and included for verification, because those summaries
  130. dreamrealare NOT intended for publication directly). But they're sort of pre-baked, so we don't see the discussion just fade into IRC logs if it's worth preserving.
  131. ParaMVP, as in Most Viable Product.
  132. dreamrealhah
  133. dreamrealin this case, "minimum"
  134. ParaI just ran cloc on my sideslop, I mean my website infra.
  135. Para21k rows and there's like three Spring handlers in this :D Of course I'm doing this The Hard Way on purpose and this runs tons of things one wouldn't need if all I wanted was a blog, but still...
  136. * dreamreal shrugs. I get it.
  137. dreamrealI mean, technically all *I* wanted was "a blog"...
  138. ParaAnd now we can play hangman over IRC.
  139. dreamrealand it's hooked up to github, discord, slack, irc, the web, polls RSS, has factoids, games, utilities, can recite poetry at you (and evaluate it)... not great poetry, but still!
  140. dreamrealand now we can play hangman over IRC. Wait until I get star traders hooked up. The economic model's actually pretty stable.
  141. dreamrealOne of the things I need to do for hangman is hook up an external word list; it only has 990 words and they're all pretty restricted in length. But hangman's a silly toy, so it's... pretty low priority.
  142. dreamrealI want it to use aspell or dict for words, but it needs to be able to run on multiple systems, so it'd have to scan
  143. * agnivn joined #java
  144. * zorone joined #java
  145. jbosmansupgrading to spring boot 4 && jackson 3 && hibernate 7 && fun
  146. dreamrealWhy jackson 3?
  147. dreamrealI've done that but haven't seen the benefits yet
  148. jbosmansafaik 2 is or will be deprecated
  149. jbosmansno more/less than that
  150. dreamrealsure. but it's going to be a while, and 3 has very "point release" energy to me
  151. dreamrealI look at 3 and I get it, but I'm also not going "oh thank god they fixed _that_", except in ONE area, and that area was so low-concern that I had to think about it to find it
  152. jbosmansyeah i see what you mean, but even so the immutable JsonMapper etc does bring some value and allows me to construct fewer instances
  153. jbosmansyeah, it's json mapping
  154. dreamreal(specifically: ObjectMapper -> JsonMapper as a specific migration; you probably want to use the "proper form" now. But if you use ObjectMapper you'll be fine.)
  155. jbosmansso it's not important
  156. jbosmansyet it's uber important
  157. jbosmans:-)
  158. jbosmansyeah i'm halfway there @ ObjectMapper -> JsonMapper
  159. dreamrealyeah. I just feel like it's ... a move that I haven't been able to say "OMG MUST DO" yet
  160. jbosmans[x] construction through JsonMapper.builder()
  161. dreamrealI mean, spring!
  162. dreamrealyou do that once and you're done
  163. ParaJust Slop It
  164. dreamrealbut then you want to change the reference types
  165. dreamrealI'm of the opinion that "AI slop" is the fault of the person driving the AI
  166. jbosmansalso added a bunch of JPA annotations, since apparently some naming changed again going hibernate 6 -> 7
  167. dreamrealjbosmans: yes, but that's pretty minor
  168. * tabmow joined #java
  169. jbosmansafter the joy of the changed id generation with hibernate 5 -> 6 :')
  170. dreamrealfun migration, though: I've done it myself recently and enjoyed it almost 1%
  171. jbosmanssounds about right
  172. dreamreal(including moving to jackson 3.)
  173. jbosmansclaude helped out with a few Q&A i have to say
  174. jbosmansand did a pretty good job
  175. dreamrealThat's another recent shift: I've been using codex over claude, and it's been pretty effective
  176. jbosmansyeah, openai is out here
  177. dreamrealclaude's context window has been ineffective: I have to explicitly remind it to do basic triage things, even though the directives SAY "never ignore these processes, I will bitch about them endlessly" and I still found myself bitching about them endlessly
  178. jbosmansright, good that there's plenty of competition
  179. dreamreallike, constant "Sure, claude, go ahead, fix main, why not OH YEAH I TOLD YOU NOT TO"
  180. jbosmanshopefully it stays that way
  181. jbosmansgemini 3 is apparently default in jetbrains junie
  182. dreamrealand "sure, go ahead and consider that feature done without mutating src/test in any way"
  183. ParaI've been running claude succesfully mostly by not allowing it direct access at all.
  184. jbosmansgot some pretty good results for (pretty simple) react stuff
  185. dreamrealfor UI the AIs are pretty good
  186. jbosmansyeah i'm pretty restrictive too
  187. jbosmansmostly hobby stuff for now
  188. dreamrealI don't mind AI code - but I use it pretty aggressively and I direct it a lot
  189. dreamrealvery few "oh I want this go code it" sessions without a *lot* of lead-up design discussions, which helps
  190. dreamrealand demanding test coverage helps a lot, too
  191. jbosmansyeah, "agentic development" && "i'm getting there"
  192. jbosmansmaybe "i'll be getting there"
  193. * kcomhnall joined #java
  194. * vobar joined #java
  195. * GreenResponse joined #java
  196. * jamezp joined #java
  197. jbosmansgrrr my jackson streaming reading code is breaking
  198. dreamrealI wonder if they changed it!
  199. * dreamreal giggles.
  200. * tabmow joined #java
  201. * sa02irc joined #java
  202. * x1bncwn joined #java
  203. jbosmansyeah, they did and i guess it's better
  204. dreamrealIt's slightly concerning that this is a guess. :D
  205. jbosmanshaha
  206. jbosmansfewer to no checked exceptions is a win
  207. dreamrealIs it?
  208. jbosmansthe immutable mappers same
  209. jbosmansimho yes
  210. dreamrealthe mappers, I'd agree with
  211. jbosmansi could still catch
  212. dreamrealthe checked exceptions, I'm neutral on
  213. jbosmansi either removed the try/catch, or changed to catch Exception
  214. jbosmansdepending on whether there was any handling
  215. jbosmans7/10 -> no handling
  216. * vitaliy joined #java
  217. * tronexte joined #java
  218. * Square joined #java
  219. * deepy joined #java
  220. * sbalmos joined #java
  221. * sbalmos joined #java
  222. * skinkitten joined #java
  223. * vitaliy joined #java
  224. * stfstfm joined #java
  225. * stfstfm__4788 joined #java
  226. * stfstfm_ joined #java
  227. * magla joined #java
  228. * dinomug joined #java
  229. * cation joined #java
  230. * MikeBux joined #java
  231. * stfstfm joined #java
  232. * gas51627 joined #java
  233. * kcomhnall joined #java
  234. * magla joined #java
  235. * tomaw joined #java
  236. * lex_v joined #java
  237. * nevet joined #java
  238. * CodeGeek!~codegeek@about/java/CodeGeek changed the topic to: Welcome! || Read Channel Rules at https://javachannel.org/ before participating. || Paste limit is two lines; ~pastebin lists options. || No applets, please. || Minecraft, Android, and Javascript all have their own channel. || You are being logged.
  239. * ferdna joined #java
  240. * ernimril joined #java
  241. * Shell joined #java
  242. * ernimril joined #java
  243. * ForeverDreaming joined #java
  244. * Everything joined #java
  245. dreamrealjbosmans: thanks, BTW. I felt bad about nevet still being on jackson 2, so I'm doing the migration myself. Great fun all around. Thaaaaaaaaanks.
  246. jbosmanshaha, with pleasure + don't give me that crap, you were somehow tempted ! :-D On a more serious note, suggest you make sure you tested it all :-)
  247. dreamrealoh, I have tons of tests. It's a 20 second build if I don't use tests... and a 3 minute build if I do.
  248. jbosmanssounds relatively efficient overall
  249. dreamrealWe'll see. When I'm done, I'll be able to describe how painful it was; overall the build's pretty modular, so it shouldn't be too bad.
  250. jbosmansregarding jackson, the immutability is pretty nice, i had a bunch of placed where defensive copies were made "just to be sure"
  251. jbosmansbecause if those placed failed, hellfire would've rained down (or something)
  252. jbosmansalso, project nearly never need explicit "do" or "don't" fail on unknown properties, or serialize/deserialize null properties whatnot
  253. jbosmanswith mutable ObjectMapper i basically never trusted myself
  254. jbosmans"just to be safe"
  255. * agnivn joined #java
  256. dreamrealheh. I'm pretty careful about those myself. But I just realized... I use json everywhere, partially because I use jsonb fields... and I just thought "hey, what about toon"
  257. jbosmanshah same @ jsonb
  258. dreamrealMost of my storage is pretty light, so I don't think it'd save much, but that's a nasty thought to land out of the blue
  259. dreamrealarticle Comparing JSON and toon
  260. nevetIdea session started: "Comparing JSON and toon". Use 'content <text>' to add body paragraphs, 'includeai' to enable AI summary/tags, 'done' to save, or 'cancel' to discard.
  261. dreamrealcontent look up definition and spec for toon
  262. nevetContent block #1 added to "Comparing JSON and toon". Use 'content <text>' to add more, or 'done' to save.
  263. dreamrealcontent size differentials, data scale
  264. nevetContent block #2 added to "Comparing JSON and toon". Use 'content <text>' to add more, or 'done' to save.
  265. dreamreallogs 20m
  266. nevetAdded 24 log messages (last 20m) as content block #3.
  267. dreamrealaisummary
  268. dreamrealdone
  269. nevetIdea saved as draft: "Comparing JSON and toon" (3 content blocks).
  270. jbosmansi'm guessing no jpa ?
  271. jbosmans@jpa i don't feel like i need to be an advocate for it, and it's bitten more than once
  272. ParaOn that tangent, Spring 6.1's JdbcClient is actually kinda nice for us raw-SQL-enjoyers.
  273. dreamreal*definitely* JPA
  274. dreamrealspring's on 7 now, lamer!
  275. jbosmans:D
  276. jbosmanshaha
  277. Paradreamreal: And Boot is in four yet I'm doing 3.5
  278. dreamrealjbosmans: one remaining section to fix, in openjpa
  279. dreamrealsorry, openapi
  280. jbosmansyeah well spring 7 + jpa + hibernate + jsonb field needs an extra annotation from where i'm sitting
  281. dreamrealyou guys got me thinking jpa :/
  282. dreamrealjbosmans: I was already there, jackson 2 was a decision I made out of familiarity
  283. dreamrealthis is me being dragged kicking and screaming into the new modern
  284. jbosmansdreamreal, it's hibernate 7 behavior related
  285. dreamrealjbosmans: yes, but like I said, I was already there :D
  286. jbosmansfwiw @ColumnTransformer
  287. jbosmansdreamreal, what, you've complited the migration spring boot 4 and/or spring framework 7 etc ?
  288. dreamrealspring boot 4 was already done, as was hibernate 7
  289. dreamrealit was spring boot 4 + hibernate 7 + jackson 2, this is changing that last
  290. jbosmansah
  291. jbosmansyeah makes sense
  292. jbosmansafaik most impactful one
  293. jbosmanswell, hibernate is always impactful
  294. dreamrealThe deprecation of @Temporal annoys me. I get it, but still...
  295. jbosmansi have to do these kinds of migrations "in one go" to preserve my sanity
  296. jbosmansoh yeah
  297. jbosmansi think i got bitten by that
  298. dreamrealwell, yeah, migrating to spring 4, it's probably BEST to do all three in one fell painful swoop
  299. jbosmansbasically workaround code to parse a (previously) java.sql.Timestamp to a LocalDateTime blew up
  300. jbosmansyeah
  301. jbosmansmajor spring boot version upgrades have been rough experiences for myself tho
  302. dreamrealI have all green tests but the code isn't idiomatic, working on that now
  303. jbosmanstho it makes sense, major dep upgrades are what they are
  304. jbosmansdreamreal, kudos for the tests
  305. dreamrealThey're working: migrating to idiomatic code is failing!
  306. dreamrealWhich is exactly what they're supposed to do
  307. jbosmans"tis good to fail"
  308. dreamrealmuch gooder to fail in tests than in production
  309. jbosmanscodex?/claude code?
  310. ParaI'm kinda amazed by how well the testing works in this ...thing of mine.
  311. dreamrealjbosmans: between the two: codex
  312. ParaI mean obviously it works because I spent two days prompting and rewriting it until I was happy, but still it's kinda pretty.
  313. jbosmansoh right, you said before, sorry
  314. dreamrealI like claude but I'm thinking lately it's not been as good as codex, a little surprising considering the lead it had
  315. ParaI haven't tested codex; Claude at least seems to be a good baseline for things. Anthropic's business strategy seems to be on promoting overspend and Ouroboros-like setups which I don't like.
  316. dreamrealclaude has been struggling with context windows. codex has done a better job lately of respecting my edicts, which is nice.
  317. cheeserthe new codex model is supposed to be pretty nice.
  318. ParaClaude is curious that it seems to work better when you give it the minimum possible context and lots of extra "focus on this", "ignore that" type of instructions.
  319. dreamreal(I have strict instructions to try to resist stroking my ego: my ego will be inflated best when MY CODE EFFING WORKS, LLMS.)
  320. ParaMy default prompt is basically five sentences of "treat me like an adult".
  321. * Everything left #java
  322. dreamrealcheeser: I haven't tried the new CODING model, because it emphasizes speed of response and I don't care about that: I want the code to be good, not to have it generated quickly
  323. dreamrealPara: Yeah, mine's more like 30 lines of treat me like an adult and these are the things I value, you stupid machine (like: "tests" and "make it work, make it pretty, make it fast in that order" and stuff like that.)
  324. Para+:tää:
  325. jbosmansso i've had an openai subscription for a pretty long time, but then the DoD thing happened, and i felt like i should re-investigate things?
  326. dreamrealDoW, you mean? The DoW thing is against anthropic, not openai
  327. * dreamreal despises "DoW" as a moniker
  328. jbosmansreally .. thanks for addendum :)à
  329. jbosmansthose things matter i think
  330. dreamrealI've had both openai and anthropic subscriptions; I work for a company for whom this is all important
  331. jbosmansLLM decided kills is just ......... wrong
  332. dreamrealoh, anyone handing such decisions to an LLM is off the rez
  333. dreamrealbut that's not what's happening
  334. dreamrealokay, idiomatic usage is ... "in" and all tests green
  335. jbosmanssounds good
  336. dreamrealbiggest problem was null handling
  337. dreamrealhmm, hmm, i wonder if I trust this enough to deploy
  338. jbosmansbiggest ethical problem is null handling? :-D
  339. dreamrealjbosmans: anyone handing ethics to an LLM is a problem, at any level
  340. jbosmansdreamreal, agree, i guess that's what anthropic was trying to prevent
  341. dreamrealIt's not difficult to get an LLM to decide that SURE, it's fine to shtup the babysitter
  342. * jbosmans && defending bn$ company :')
  343. dreamrealno, that wasn't the problem
  344. dreamrealanthropic and the DoD both had legit points
  345. jbosmansi read the anthropic points, somehow missed the DoD points?
  346. jbosmanssorry, as in "legit DoD points"?
  347. jbosmansimho they'll win their lawsuit
  348. jbosmansjust becuase somewhere someone, unexpectedly, still has common sense
  349. jbosmansdreamreal, i just noticed, from jackson 2->3 migration to this :-)
  350. ParaI'm old enough that "DoD" to me means Day of Defeat.
  351. jbosmans\o/
  352. jbosmansthose were the days
  353. jbosmansi always was the worst @ knowing the maps, including anzio
  354. jbosmansnothing a browning couldn't fix ;)
  355. cheeserdreamreal: then you are neither moving fast enough or breaking enough things
  356. dreamrealoh, anthropic definitely has legit points, so does the DoD
  357. jbosmanscheeser, hasn't move fast and break things been sorta deported since?
  358. dreamrealI'm not willing to take sides
  359. jbosmans:o
  360. cheeserjbosmans: promoted actually to focus on global efforts
  361. cheeser"And Zuckexander wept for there were no more worlds to break."
  362. jbosmanscheeser, haha perfect :-))))
  363. dreamrealI feel back for zuckerberg, actually
  364. dreamrealnobody else shares the burden of being him. The downside of that is that we still have to worry about how to pay bills, but still...
  365. jbosmansyeah :-(
  366. jbosmansluckily he jumped in with the other billionaires when the time was right
  367. jbosmansit must've been tough for him tho
  368. dreamrealHey, it's gotta be hard to be a lizard person in a world full of mammals
  369. ParaI wouldn't be surprised at this point if Zuckerberg turned out to be an android/lizard hybrid.
  370. dreamrealall right, haha, we've had our fun, let's be kind to even soulless cretins
  371. jbosmanshaha, those were some good meme/vids back in the day
  372. jbosmansactually, pretty recently
  373. dreamrealWilliam Gibson had a point that's kinda hard to disagree with: the very very rich are very difficult to consider as being actual humans any more, their perspectives are... warped
  374. dreamrealthis doesn't mean they're not actual humans, it's just difficult to actually understand them, and it's difficult for them to understand us muggles
  375. dreamreal"oh man, I need to figure out how to pay my rent" or "oh man, I broke my arm, the ER's gonna be $4k" gets met with "why don't you just... you know, not have that 17th mansion, 16 is enough" or "just have them replace the arm, my good man."
  376. jbosmansyeah
  377. dreamreal"Would you like a small country? I have a spare."
  378. jbosmansfwiw that stuff is spreading
  379. dreamrealwell, the internet was supposed to bring us together, and instead it's split us apart
  380. jbosmanssecond that
  381. ParaThe split point is somewhere around 2011, ironically.
  382. jbosmansit didn't at first tho !
  383. dreamrealOh, I thought it was GREAT - in 1994 I was talking to ACTUAL GENERALS on usenet
  384. dreamrealI still do, but back then it was very egalitarian
  385. ParaThat'd be Arab Spring events and how information flowed freely thanks to in no small part, Twitter. Not the event itself, but the showing that _this_ is what Internet can do. And that made the old money/power _very_ interested/worried.
  386. jbosmansi remember installing quicktime and then waiting like half an hour or more to watch a very brief star trek first contact trailer :-)
  387. ParaBut unfortunately this is so political stuff that even I have to now point out that this doesn't compile with javac so...
  388. dreamrealI think the inflection point you're seeing is incorrect, but I get it
  389. GreenResponsethere are forces that are vehemently against bringing humans together: like Asian autocracies Russia, China and Arabic countries
  390. jbosmansi think it's good to talk about "things", whenever possible
  391. GreenResponsethat’s why Russian trolls try to destroy decent communication
  392. dreamrealyep. But let's stay on topic before we drift back into politics.
  393. dreamrealtopic, please.
  394. dreamrealI am not saying I disagree with you, at all: but let's stay on topic.
  395. jbosmansGreenResponse, just for my info, where do you live?
  396. dreamrealtopic.
  397. dreamrealTake that to PM.
  398. ParaWhat's the state of non-LLM AI things?
  399. * waznot joined #java
  400. GreenResponsesorry, got carried away
  401. dreamrealPara: still great! I use AI for markov chain stuff in nevet :D
  402. ParaPeople focus on those but I'm actually more interested in image processing things.
  403. dreamrealGreenResponse: it's easy to do, no shade, I do it myself, but let's apply discipline
  404. * vitaliy joined #java
  405. dreamrealPara: that's not really AI, though, is it? It's ML, but not really AI
  406. dreamreali hate the conflation of terms
  407. ParaI've been thinking of a pipeline which takes crap quality video -> convert to frames -> mask away noise parts from the video -> run the remaining through gaussian splatting.
  408. ParaIt just seems a lot harder to find the bits for this kind of thing.
  409. dreamrealyeah, well, you're supposed to hand it to an LLM now!
  410. dreamrealthose data centers ain't gonna pay for themselves, you know!
  411. ParaMaybe I need to create a darn startup for this.
  412. * sa02irc joined #java
  413. dreamrealokay, I found a gap for jackson3: springdoc and openapi. It's easy to FIX - add the jackson kotlin module back for the openapi generation phase, with no other code changes, but without it the openapi spec loses the ability to specify required fields
  414. * monkeyPlus joined #java
  415. * nevet joined #java
  416. * CodeGeek!~codegeek@about/java/CodeGeek changed the topic to: Welcome! || Read Channel Rules at https://javachannel.org/ before participating. || Paste limit is two lines; ~pastebin lists options. || No applets, please. || Minecraft, Android, and Javascript all have their own channel. || You are being logged.
  417. * Ragnor joined #java
  418. * waz joined #java
  419. * jreicher joined #java
  420. * stfstfm_ joined #java
  421. * jamezp joined #java
  422. * zorone joined #java
  423. * dinomug joined #java
  424. * talbot joined #java
  425. * MikeBux joined #java
  426. * chris64 joined #java
  427. * x1bncwn joined #java
  428. * kcomhnall joined #java
  429. * metalmaniac joined #java
  430. * cation joined #java
  431. * Square joined #java