ByteCode.NewsSubmit
Use quotes for an exact word.

Subscribe

RSSPodcast
Log in

Chat Logs

  1. bluecool, jreicher
  2. bluedreamreal: the two primate bugs posted, would you be comfortable waiting for 0.43, or do they necessitate a 0.42 backport?
  3. blueI'm agnostic, so up to you
  4. blueactually I'm slightly gnostic there: I do prefer not having to deal with pnpm by means of a backport, but it's not a blocker for me
  5. dreamrealI've got workarounds, feel free to wait
  6. dreamrealnot a rush, just filed the issues so you'd know
  7. dreamrealblue: I've got a spin-up process for nevet, going to try it on our private network later today
  8. dreamrealmoving to the full dockerized install kinda made that a little difficult thanks to using the console for initial configuration, but the pudl UI provides a console *endpoint* so I can use that
  9. bluenice, dreamreal
  10. dreamrealblue: I'm going to try to spin it up under the name "gholem" :D
  11. dreamrealit's basically going to be the gitlab watcher for mattermost
  12. bluedreamreal: you know, I'm gonna need someone to battletest repopack, just saying :P
  13. dreamrealThis is part of getting close to that, this is all initialization stuff, like "how the heck DO you run this now?"
  14. bluetrue. also consider that repopack both manages the repo (via tasks etc.) *and* deploys it. the change can be gradual
  15. bluebut I'm gonna hold off recommending a move until it gets release primitives
  16. blueI must be content with it myself
  17. bluethere is no way around that
  18. dreamrealWell, streampack requires intervention on configuration, unfortunately, so the spin-up isn't trivial
  19. blueintervention on configuration?
  20. dreamrealIt's getting there: right now it's a bunch of y/n questions with only a few details like email addresses and server names/ports
  21. blueright
  22. bluebtw, dreamreal, what honestly scares me, is that repopack has been moved to the new ai-based idea for a month, and I'm already at task 670. that's an incredible turnaround
  23. blueI'm a bit reserved of optimising it too much, myself, because my pro 100 would run out like nothing :/
  24. bluebut it will be necessary, again, no way around it
  25. blueI can't be going around with like 5 tmux sessions and countless opencode windows, it gets more and more confusing
  26. dreamrealyeah, it's fast, it's potentially expensive, but it highlights the value of ideation
  27. blueit's *too* fast
  28. dreamrealIs it?
  29. dreamrealI mean, it might be outracing your funding, but...
  30. dreamrealI'm fixing search now - i was searching for "emergent" but got "emerges" instead because of the stemming, and I didn't have a good way to clarify the matching :D
  31. blueI told you, my current pace drains pro 100 in roughly 1.2d, accounting for a normal sleep/work cycle. pro 100 runs for 7d. the resets, on which it is dangerous to rely, cut it to roughly 3.5d on average. pro 200 is doubled; at my *current* pace, I would be nearly exhausting pro 200 every single time. any boost on that pace is potentially fatal
  32. bluesorry, pro 200 is quadrupled*
  33. blueand I'm already economical. most work is done by sol 5.6; sol 6 only does reviews; sol 6.1 is rarely used at all
  34. dreamrealI hear you. But note that sol is not always necessary.
  35. bluetell that to me who tried to reason with terra and got "continuing with this" every single time, necessitating me babysitting it every 5 minutes with "continue"
  36. dreamrealheh
  37. bluethe problem as I see it, is that repopack is going to minimise overhead and maximise agent runtime, which is going to be highly effective and potentially burn through limits to no end
  38. bluewhich yes, leaves more for ideation, which is good, but also means you need more power
  39. blueand yes, I remember your search tokenises, which kinda amazed me, I thought you did ai
  40. bluebut it predates I believe
  41. blueor was consciously chosen conservatively
  42. bluepredates ai*
  43. dreamrealthe libraries I was using use stemming, it's heuristic, no AI
  44. dreamrealin fact, search doesn't use AI *at all* although !define now has a fallback to AI if the dictionary services fail
  45. blue*nod*
  46. blueI'm currently toying with the idea of repopacking reducing test time for offering optimise containers
  47. bluea lot of the test time primate has is spent of spinning postgres and oracle containers and what not
  48. bluespent on*
  49. dreamreal*nod*
  50. dreamrealsqlite, buddy! *grin*
  51. dreamrealI despise sqlite
  52. dreamrealthat was a funny
  53. blueyes, well, *all* adapters need testing
  54. dreamrealincidentally, the streampack bot on our private network is going to be called 'gholem' :D
  55. blueprivate network?
  56. dreamrealYeah, I have an internal network for work, not visible externally
  57. bluefair enough
  58. blueI have decided flog won't also have runtime capabilities, I won't make everything out of it, like bun. it'll remain mostly a package *manager*
  59. bluethe runtime will be another tool
  60. bluedreamreal: btw, nevet is so nice. it's offering everything I need from a bot currently
  61. dreamrealheh, I'm glad to hear that :D
  62. dreamrealI'm adding external entrypoints now, so you can overrride the banner and add external jars without having to build them into the system
  63. dreamrealso THEORETICALLY you could have your OWN module, on ts own repo, drop it into a directory, and have streampack pick it up
  64. blueawesome
  65. bluedreamreal: every task I solve, I can three new ones. this is BRUTAL
  66. blueI create*
  67. dreamrealYes, it's almost like development. And this is how development ALWAYS went, but the machines can wear blinders a lot less well than humans can. As humans we say "I'll fix that when I need to!" and we shim in functionality, but the machine's going "you said to do it, not fake it..."
  68. blueyup
  69. dreamrealokay, search is fixed!
  70. bluenice
  71. dreamrealAND - this will be good for repopack - I have extensions exposed outside the docker image, so a repopack service/operation doesn't have to be part of the main build any more
  72. dreamrealThere's no reason they couldn't be part of the main build but the main build's pretty giant already, and it's grown way past what it should be
  73. dreamrealnew modules should be really rare now
  74. dreamrealand I may move some of the modules *out* - like hangman, 21, etc., a lot of those really aren't core, they just were part of the core to prove out features and stuck around
  75. bluehi phaleth
  76. bluedreamreal: WOW!
  77. blueamazing
  78. phalethhi blue
  79. bluephaleth: btw https://repopack.com/project/repopack/jobs/1
  80. blue272 jobs x 7mb x 4 -> 7.6 gb
  81. bluehence -> https://repopack.com/project/repopack/tasks/674?tasks=status%3Dopen
  82. phalethyeah, I was wondering if those artifacts get cleaned up
  83. phaleththe goal is to be able to rebuild them, not to store them indefinitely
  84. blue674 will clean up old jobs
  85. bluewith a retention policy
  86. blueprobably "keep last x jobs", or, "remove jobs older than 30 days", or both
  87. phalethok
  88. blueI think last 10 or 20 jobs, and remove anything older than 30 days, is ok
  89. bluewe will also introduce a storage limit for free accounts
  90. bluemaybe 1gb or less
  91. bluepaying accounts can be get more
  92. bluecan get*
  93. phaleth256 MB
  94. bluestorage, not RAM
  95. blueor did oyu mean storage?
  96. phalethyeah, storage
  97. bluebut we currently have 130gb available on this vps. if it's 1gb, it would be up to 130 accounts
  98. phalethand also single container app with max 256 MB RAM
  99. blueif 256, up to 520
  100. bluewell we gotta also limit the number of apps per account
  101. blueand also the number of concurrently running jobs
  102. phalethjust give them a way to clear artifacts
  103. phalethvia cli
  104. phaleth256 MB is alot
  105. bluenah, should be automatic. the only thing that we need is a whitelist, to freeze builds that you need to keep
  106. blueI mean we can let people delete jobs. I'm not sure runs, but jobs you can delete and it deletes all runs + their artifacts
  107. bluebut letting people deleting runs sounds like wasting time on bookkeeping
  108. phalethyeah, but it's better to have both, maybe somebody will build a lot of crap and then realize they have to wait a month for it to be cleaned
  109. bluedelete*
  110. bluefair enough. but remember, that also means they could instead of clogging the cpu
  111. blues/of/be/
  112. bluelike then you can script it 24/7, build -> delete -> build -> delete
  113. bluethat's a form of abuse as well
  114. phalethwait, the builds should happen in podman containers with resource limits
  115. blueyes
  116. phalethincluding CPU limits
  117. bluethat's already the case now
  118. bluebut CPU limits should be measure across an entire account, monthly
  119. blueand you don't want someone to waste all his CPU time on the first day
  120. blueanyway, I think that's a product decision that we can discuss later
  121. bluebut free accounts will need to be limited
  122. phalethand for build the container should take max 2 GB RAM, cause if anybody tries to build some rust crap they should not be able to
  123. blueyes
  124. bluewell if you're a paying customer, you can build rust, why not
  125. blueyou can also build v8, which is a waste of time and takes forever, but who cares if you're paying for it
  126. phalethyeah
  127. blueI think that also, if we have people like dreamreal, who to my knowledge doesn't pay for gh actions atm, we should try to keep under the free tier, otherwise people won't switch
  128. bluethe idea of the free tier is a bit that you lose money on those users, but also you draw them in
  129. blueso once they see how great the service is, they can pay for cases where they generate money, so it's a trickle down effect
  130. bluethe worst cases are that the customer doesn't generate income, but needs to pay, in those cases they might switch back to gh
  131. blueor aws or google
  132. phalethyou need different kind of accounts, but those 256 MB RAM I meant for randoms
  133. blueyes
  134. phalethyou can offer people perks
  135. bluethat's something we need to get into place before launch, definitely
  136. bluebut also need more servers, anyway. preferably dedi
  137. phalethmaking it a game is a good idea
  138. blueI'd like to start with around 100 euro worth of dedi/vps servers a month, I think that's a good start in terms of offered powered
  139. phalethdedis are too expensive, we should be fine with VPSes
  140. blueyeah, whatever's the best
  141. blue10-20 vps should be also fine by me
  142. phalethall what I'm trying to do is to avoid dedis
  143. bluefair
  144. blueI don't mind just doing a lot of vps
  145. phalethyeah, the question is when can repopack orchestrate
  146. phalethand when the current tasks are done
  147. bluein the future
  148. bluerepopack can already do a lot. in fact more than I ever wanted fly to be able to do for primate
  149. phalethI hope flog is complete and repopack can use flog
  150. blueshould be, yes. there's a benchmark task open, I can show you in a bit
  151. phaleththat just means more optimizations and they are a waste of time at certain point
  152. phalethI've filed a bug against flog today
  153. blueI can see it, will do
  154. phalethand also the trust me bro script still does not work
  155. bluethat's by design
  156. phalethand then you should consider having releases also for windows and that's it
  157. blueI told you, flog needs release primitives
  158. bluerepopack doesn't have them yet
  159. phalethI think that will require a powershell trust me bro script
  160. bluepossibly, yes
  161. phalethyeah, I know, so those release primitives, whatever task on repopack that is are the blocker for flog
  162. blueyes
  163. phalethcause flog is a way to get people engaged
  164. blueI know
  165. phalethkinda like primate
  166. blueand that is also a blocker for primate 0.43
  167. bluea chain of blockers, so to speak
  168. blueto my knowledge dreamreal also needs release primitives
  169. blueI think we should have them this week, god willing
  170. phalethok, how much clanker time is left?
  171. blueit refreshed earlier today.. let me see
  172. blue54%
  173. bluephaleth: https://repopack.com/project/flog/jobs/2?run=3
  174. blueclick View on summary.md :P
  175. phalethyeah, looks great, but I've tried this one earlier and it's not working correctly https://repopack.com/project/flog/jobs/1?run=47 I was getting missing tsc error
  176. phalethnot sure if that's related
  177. bluemaybe you can report
  178. bluethe roblem
  179. phalethbut that job looks weird, is that one already on master?
  180. blueno, that job is being run manually by clanker
  181. blueI will switch to `trigger:master` when the task is merged
  182. phalethwhich task?
  183. blue68/69
  184. bluetechnically this job should serve as a review gate. but we don't have the ability to make jobs a review gate, yet
  185. phalethnot sure how clanker was able to trigger job 47 from a task
  186. phalethI'll add note to flog#69
  187. phalethnow it will not know how I got the primate.tar.gz :)
  188. bluedreamreal: https://repopack.com/project/primate/tasks/216
  189. bluefeedback please