ByteCode.NewsSubmit
Use quotes for an exact word.

Subscribe

RSSPodcast
Log in

Chat Logs

  1. * skillbot quit (Remote host closed the connection)
  2. * skillnews quit (Remote host closed the connection)
  3. * skillbot joined #primate
  4. * skillnews joined #primate
  5. * jreicher quit (Quit: In transit)
  6. * jreicher joined #primate
  7. liolocmorning !
  8. liolocIs there any way to undo migrations?
  9. bluelioloc: morning, hello
  10. bluelioloc: no, migrations are forwarding breaking by design
  11. blueforward breaking*
  12. bluethe way to deal with it is create another migration that fixes the problem
  13. bluesome orms/db systems do implement reversible migrations, but it's a can of worms: destructible migrations cannot be reserved, and non-destructible are easy to forward-fix. so reverting migrations doesn't gain you much
  14. bluereversed*
  15. liolocah i see
  16. blueso the question is, what is your use case here?
  17. blueit's better to accept migrations as historic evidence and forward-fix than messing with them
  18. liolocif we had a database that operated kind of like git does, with "commits" then it would probably be an easy fix, but there's probably good reasons why that doesn't exist
  19. liolocMy use case was a personal project where I added a migration but decided to revert those changes, nothing crazy
  20. liolocI don't mind adding another migration to revert
  21. blueyes, if you had a database that operated like git, it would be easy to 'revert' migrations. however, you have to remember that databases do not operate in a way; their write operations aren't all gated by acceptance, like commits here, and any user performing an action post-migration already has the expectation that that action is persisted, rather than lost when you 'revert' to the old stage
  22. bluedatabases do not operate in the same way*
  23. liolocah ok
  24. bluegit's graph is visible all the way, databases are generally not ledgers... and even so, the complexity of reconciliating a back-migration with already-persisted changes is too high, I'd say even impossible
  25. bluelioloc: primate 0.44 released, btw
  26. blueit's not a particularly big release like 0.45, but I wanted to `primate update` out already
  27. bluelike 0.43*
  28. blueI'm also adding more features to flog. `flog format` and `flog lint` will hopefully soon arrive, as a fast replacement to eslint. then we'll have `flog test` and `flog test --cover`
  29. bluefinally, `flog typecheck` is planned. it will ts-check your project, but only against modern ts syntax. so erasable syntax only, no namespaces, etc.
  30. bluegenerally speaking this will be replacing eslint + tsc + test runners (like proby)
  31. blueso flog will do everything except run your code
  32. bluehttps://primate-master.repopack.app/docs/testing
  33. blueexciting
  34. blue(upcoming in 0.45)
  35. bluedreamreal: ^^^ that might be interesting for your tests, as it doesn't require starting a primate app
  36. blueprimate is getting a visual website refresh in 0.45, https://pewtxngij-task-295.repopack.app/
  37. nevetPrimate — The Universal Web Framework
  38. nevet[ByteCode.News] CheerpJ 5 launches: Java 21 and Java 25 in the browser - https://bytecode.news/posts/2026/10/cheerpj-5-launches-java-21-and-java-25-in-the-browser
  39. liolochey blue, 0.44 is broken with a simple react app, created task https://repopack.com/project/primate/tasks/302 for it
  40. lioloci couldn't access the visual website refresh, sasy 404 page not found
  41. bluehi lioloc, looking at it
  42. bluelioloc: @primate/core@0.13.1 is published
  43. liolocnice thanks
  44. liolocconfirmed it works
  45. liolocthanks
  46. blueno worries, fixing on master + adding tests now
  47. bluefeed list
  48. nevetjustine.lol - https://justine.lol/rss.xml Node.js Blog - https://nodejs.org/en/feed/blog.xml Obsidian Blog - https://obsidian.md/feed.xml W3C - Blog - https://www.w3.org/blog/feed Jan van den Berg - https://j11g.com/feed WebAssembly News - https://webassembly.org/feed.xml James Shore - https://www.jamesshore.com/v2/feed Distant Province - https://distantprovince.substack.com/feed Ember.js Blog - https://blog.emberjs.com/rss.xml The Astro Blog - https://astro.build/rss.xml Entropic Thoughts - https://entropicthoughts.com/feed Loris Cro's Personal Website - https://kristoff.it/index.xml Flog releases - https://flog.run/changelog.rss zer0ver - https://0ver.org/atom.xml Simon Willison's Weblog - https://simonwillison.net/atom/everything/ Andrew Kelley - https://andrewkelley.me/rss.xml danluu.com - https://danluu.com/atom.xml Primate Blog - https://primate.run/blog.rss Diátaxis - https://diataxis.fr/atom.xml The JetBrains Blog - https://blog.jetbrains.com/feed/ purplesyringa's blog - https://purplesyringa.moe/blog/feed.rss Rust Blog - https://blog.rust-lang.org/feed.xml Read the Tea Leaves - https://nolanlawson.com/feed/ Adoptium Blog - https://adoptium.net/rss.xml FREEZE64.COM - https://freeze64.com/feed/ Terence Eden’s Blog - https://shkspr.mobi/blog/feed/atom Docker - https://www.docker.com/feed/ Feed - https://hollycummins.com/rss.xml bun.com - https://bun.com/rss.xml Alan Williamson - https://alan.is/feed/ Ziglang.org News - https://ziglang.org/news/index.xml Svelte blog - https://svelte.dev/blog/rss.xml CheerpJ - https://cheerpj.com/feed.xml Chicory Blog - https://chicory.dev/blog/rss.xml yosh's blog - https://www.unix.dog/~yosh/blog/feed.atom tRPC Blog - https://trpc.io/blog/rss.xml Eignex - https://eignex.com/feed.xml Typotheque - https://www.typotheque.com/rss Improbable Research - https://improbable.com/feed/ Alberto Denia's Writing - https://www.albertodenia.com/writing/feed Deciphering Glyph - https://blog.glyph.im/feeds/all.atom.xml cekrem.github.io - https://cekrem.github.io/index.xml Apache NetBeans - https://netbeans.apache.org/blogs/atom The PHP Foundation - https://thephp.foundation/atom.xml That Privacy Guy! Blog - https://www.thatprivacyguy.com/blog/feed.xml Help Net Security - https://www.helpnetsecurity.com/feed/ maevyn.codes - https://maevyn.codes/rss.xml David M. Lloyd - https://word-bits.flurg.com/rss.xml TypeScript - https://devblogs.microsoft.com/typescript/feed/ thoughts from the red planet - http://feeds.feedburner.com/ThoughtsFromTheRedPlanet Piotr's TechBlog - https://piotrminkowski.com/feed/ Vlad Mihalcea - https://vladmihalcea.com/feed/ Deno - https://deno.com/feed WebKit - https://webkit.org/feed Eclipse IDE and platform on eclipseide.org - https://eclipseide.org/index.xml Fernando Borretti - https://borretti.me/feed.xml Enigmastation.com - https://enigmastation.com/feed.xml JoshLong.com - https://api.joshlong.com/feed.xml OpenTelemetry - https://opentelemetry.io/index.xml MDN Blog - https://developer.mozilla.org/en-US/blog/rss.xml Random Notes and Cheat Sheets - https://www.kodewerk.com/feed.xml The Nuxt Blog - https://nuxt.com/blog/rss.xml Spring - https://spring.io/blog.atom Vercel News - https://vercel.com/atom Christian Rackerseder | Blog - https://www.echooff.dev/rss.xml Nushell - https://www.nushell.sh/atom.xml Angular Blog - Medium - https://blog.angular.dev/feed Paged Out! Magazine - https://pagedout.institute/rss.xml Vanish is... - https://vanish.is/feed.xml Open Liberty - https://openliberty.io/feed.xml Apache Fory™ Blog - https://fory.apache.org/blog/rss.xml Poimandres - https://pmnd.rs/feed.xml The Vue Point - https://blog.vuejs.org/feed.rss Next.js Blog - https://nextjs.org/feed.xml Biome | Blog - https://biomejs.dev/blog/rss.xml Mystic’s Substack - https://www.wecodefire.com/feed Nate Meyvis - https://www.natemeyvis.com/feed/ マリウス - https://xn--gckvb8fzb.com/index.xml Nature Reviews Computing - https://www.nature.com/nrcomput.rss Blog posts | RSS Feed - https://www.cockroachlabs.com/rss.xml OpenAPI Initiative - https://www.openapis.org/feed The Go Blog - https://go.dev/blog/feed.atom React Blog - https://react.dev/feed.xml ByteCode.News - https://bytecode.news/feed.xml Codeberg News - https://blog.codeberg.org/feeds/all.atom.xml DuckDB - https://duckdb.org/feed.xml Martin Fowler - https://martinfowler.com/feed.atom Terminal Trove - https://terminaltrove.com/blog.xml GitHub hosting -> Codeberg - https://discuss.cachyos.org/t/github-hosting-codeberg/33963.rss
  49. bluedreamreal: ^ this really should show the feeds for this channel, showing all feeds is... not useful
  50. bluearticles
  51. bluearticles blue
  52. bluenothing is working :(
  53. blue`!articles` without [user], should show my articles, I think
  54. bluewith user, show should user's articles
  55. blueshould show*
  56. bluedreamreal: and coolest feature of all: link my irc user to repopack user, link channel to project, then be able to do `+task [title] [text]`
  57. bluethis would allow quick prototyping of ideas
  58. * phaleth joined #primate
  59. bluehi phaleth
  60. bluehttps://primate-master.repopack.app/
  61. nevetPrimate — The Universal Web Framework
  62. bluenew website coming in 0.45
  63. phalethhi blue
  64. phalethnew primate website?
  65. blueyes
  66. bluealso testing, ORM translactions, changelog for primate, and API docs
  67. bluetesting is already done: https://primate-master.repopack.app/docs/testing
  68. blueprimate already uses it internally for its frontend tests, this bypasses starting a real server and occupying a port, pretty cool stuff
  69. phalethcolors are a bit different, margins are a bit off in some places but many that's fine
  70. blueya
  71. phalethmaybe that's fine*
  72. bluealso flog is gaining many new commands, `flog check types`, `flog check imports`, `flog checks deps`
  73. blueso it'll replace many tools, eslint/prettier/biome, tsc, npm, knip, and many more. anything aside from the runtime itself, essentially
  74. bluethis is the bun thing I think systemfault was complaining about. flog is basically bun but without the runtime, so it's only a package manager
  75. bluethis is the one thing flog will never be, a runtime. because it's in go. but that's fine, I don't want it to be a runtime
  76. bluedog will carry that torch
  77. phalethshould be separate yeah, make the container too big
  78. bluewell flog right now, on master, is 4.5mb
  79. bluethat's not very big at all. bun is like 90mb
  80. * skillbot quit (Remote host closed the connection)
  81. * skillnews quit (Read error: Connection reset by peer)
  82. * skillbot joined #primate
  83. * skillnews joined #primate
  84. phaleth9.8M on my disk
  85. blueflog-0.0.0-dev.1540bd0af077-linux-amd64.tar.gz 4.5MB
  86. blueI guess there's a lot of text inside? binaries are supposed to be compressed already I thought...
  87. blueanyway I'll see if I can make it smaller
  88. phalethunarchived
  89. blueya
  90. bluewell 9.8M is still ok. but I'll optimise once we get all the features
  91. blueI'm just trying to get rid of all this unreliable dumpster fire tooling that never works for me properly
  92. bluelike I install knip, then it shows a thousand errors where about 99.99% of them are false positive because it doesn't understand node private imports (#)
  93. bluedoes anyone actually test/use those tools?
  94. phalethno, people still use webpack
  95. blueomg webpack
  96. phalethit's always like yeah, dog shit slow, but it's battle tested and it works
  97. bluebattle tested my butt
  98. bluebut tbh, I delimit flog to *my* use cases. like for TS type checks, it's only modern syntax because I don't care about enums or interfaces or all that old garbage
  99. blueso it's just erasable syntax and no interface. it's anyway what the TS more or less recommends today
  100. bluesorry, no namespaces*
  101. blueinterfaces will be fully supported
  102. bluenamespaces was a module-like attempt of TS that predated proper ESM modules, I believe. so anyway you shouldn't be doing it anymore
  103. bluealso no type decorators and so on
  104. phalethI like TS enums
  105. bluethey don't degrade well at all
  106. phaleththey allow string values
  107. phalethlike Java enums, but Java enums look weird
  108. blueyou should just do `const ENUM = { 1: "HI", 2: "BYE"};`
  109. bluethat's as good an enum as you'll get
  110. phalethnamespaces in TS are a failure
  111. blueyes
  112. bluethat's why `flog check types` won't support htem
  113. blueso obviously if you need to check the world, you'd be still using tsc. but for modern projects, flog will be just as good
  114. bluethese are primate's devdeps right?
  115. blueright now:
  116. blue "@rcompat/test": "^0.22.0",
  117. blue "@types/node": "^26.6.4",
  118. blue "@typescript/native": "npm:typescript@^7.0.2",
  119. blue "apekit": "0.0.58",
  120. blue "eslint": "^10.12.0",
  121. blue "proby": "^0.27.0",
  122. blue "typescript": "npm:@typescript/typescript6@^6.0.2"
  123. blueafter flog is done, they'll all be removed
  124. blueit's all tooling upon tooling
  125. blueand I'm sick and tired of it
  126. bluejust need one good tool, (tm)
  127. phalethflog will replace tsc?
  128. blueyes
  129. phalethok
  130. phalethalso isn't proby your thing?
  131. blueyes
  132. blueproby is a test runner. flog will replace it
  133. blue@rcompat/test, that might stay there until primate can switch to std:test and dog
  134. phalethok, well concurrent test runner is better
  135. bluebut all those devdeps are heading to the dumpster yard
  136. bluethey're not really devdeps, they're tooling
  137. bluethe future is flog
  138. blueand not all those dumpster fires
  139. phalethso I've tried to use encore as just a JS runtime and it just wanted me to generate their project from their template and shit I was like hell no
  140. bluelol
  141. bluewhat is encore?
  142. phalethit's like you buy one product from apple and you have to dump everything else into trash to replace it with other apple crap
  143. phalethnot too sure, it's somebody having similar ideas to yours and just kinda replacing everything
  144. phalethbut they wanna lock you in you know, and maybe you will be accused of the same
  145. phalethyou will get comments like you do support TS, but it's not a TS, what it is
  146. blueI don't give a rat's butt
  147. phalethanyway, impossible to keep up with the standards
  148. blueI develop all my tools for myself, others are welcome to partake, if they don't want to, it's their prerogative to use their broken old tools
  149. blueI don't have to carry every backcompat nonsense the TS team feels obliged to. they have semver, they could decide to not do it
  150. bluepeople have apparently forgotten semver was designed so you can freely break stuff, like a bird
  151. blueinstead, people put themselves into self-inflicted prisons, not my problem
  152. phalethnah TS doesn't follow semver
  153. blueif TS doesn't follow semever, then why does it publish new majors? it should just switch to the firefox/chrome model
  154. blueso they kinda follow semver but also they don't
  155. bluealso your argument might hold for TS, but it certainly doesn't hold for node
  156. blueit does follow semver, but also it almost never breaks anything
  157. blueit could break stuff, it just doesn't want to
  158. blueif it broke stuff, people would be forced to update their old rotten software still using fs.write(callback) or whatever it is
  159. blueor stay on older, unsupported versions
  160. bluewhy do open source projects shift the burden of keeping your software uptodate, to themselves? and then complain they have no resource to maintain stuff?
  161. bluedreamreal: ^ honest question
  162. bluejust break forward, like linux does, and you don't need to maintain compat forever
  163. phalethpeople still use express and cjs, and still actually write more cjs than esm server side
  164. phalethand clanker keep supporting that crap too
  165. blueyeah but they do it because they can
  166. phalethso that means node cannot break, period
  167. bluewhen what's his name.. the esm guy, started publishing esm-only packages, people complained, but then they stopped complaining and continued to use his useful tools
  168. bluesindre*
  169. phalethso the thing is node is everywhere where non-browser JS is, I think even electron might use node, but dunno
  170. phalethand so if you wanna invade that space you just have to have everything well integrated, including editor support if you think people should write code
  171. phalethand in that integration sense also well automated, cause when people have to make effort they will not change their tools
  172. phalethit's always the same answer: PHP has already solved those problems
  173. phalethor whatever you put instead of PHP there
  174. phalethalso the biggest problem is mobile
  175. phalethmobile will be the biggest problem also for repopack, cause people like to sit on toilet when writing down ideas for whoever to work on, be it clankers
  176. phalethor lay down in bed or on a couch
  177. phalethlike who's having a desktop PC at home, only total nerds
  178. bluecan use repopack on normiephone too
  179. dreamrealblue: laziness
  180. bluedreamreal: ya but they complain about that one guy in nebraska maintaining it?
  181. blueidk, it just doesn't fit together
  182. dreamrealeveryone wants everything for free
  183. blueopen source should be something you do as a passion, you don't ned to maintain compat beyond what you have time to
  184. bluethat's what I do with primate. it's take it or leave it
  185. dreamreal"you gave it away, why are you not STILL giving it away"
  186. bluebecause I'm not obliged to :P
  187. bluebut no law of man or god
  188. blues/but/by/
  189. bluethe answer is simple to me. the question is why do so many open source maintainers put themselves in this bind
  190. dreamrealsure but people still want everyone ELSE to hold the burden
  191. blueI would never put myself in this bind
  192. dreamrealand since a lot of open source maintainers feel the same they bind themselves
  193. blueunless someone pays me to do primate, I'm not gonna support something I don't have the time, or more importantly, the passion, to support
  194. bluethis is something I will never compromise on
  195. dreamreal+1
  196. blueif I stop enjoying it, I'll stop doing it, I don't care
  197. dreamrealbut definitely fix all of MY issues
  198. blueyour issues are ALL fixed and more!
  199. phalethheh
  200. dreamrealI wasn't being serious anyway :D
  201. blueya, I know
  202. bluephaleth: did I tell you cit is compiling directly to assembly at&t, no libc?
  203. blueI think I also figured out ownership
  204. phalethyeah, so simple
  205. blueso clanker asked, how to deal with a scenario where you have a helper which needs to modify a resource, but also you want to give it back
  206. blueapparently rust has something like &mut or whatever craziness, like temporarily ownership or wahtever
  207. bluecit isn't having any of it, you transfer the ownership with !, and you give it back with ! again if you need to
  208. blueif you need to give it back AND provide more data, you give back a 2-tuple
  209. blue[!resource, bytes_read]
  210. blueit's all very simple, I don't know why rust complicates it so much
  211. blueit's a bit of go, a bit of rust, only the good parts
  212. blueit's very impotant to be able to read code in a linear way
  213. bluea bit like repopack tasks
  214. blueall those pointers are doing nothing good
  215. blueit's like all hidden sideeffects and whatnot. I think this is what zig is trying to avoid, but of course as we all know zig has become a dumpster fire
  216. blueso now we get zig simplicity, with rust-style ownership, and go returns
  217. blueall good and proper
  218. bluedreamreal: see how I actively engage in tikkun olam here?
  219. dreamrealI do, yes
  220. bluegood
  221. phalethblue: you should watch `Async Rust` from tsoding then you will remove rust completely :D
  222. phalethi can actually upload it for you if you want, it's a fun stream
  223. * phaleth quit (Quit: phaleth)