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 (Read error: Connection reset by peer)
  3. * skillbot joined #primate
  4. * skillnews joined #primate
  5. * phaleth joined #primate
  6. bluehi phaleth
  7. phalethhi blue
  8. bluephaleth, dog can now run jsc in addition to v8 and qjs
  9. phalethcan it already run primate?
  10. blueI doubt that
  11. phalethor at least some of the flog workloads
  12. bluefirst the dog std needs to reach parity with rcompat
  13. blueand the dog std is implemented natively, in cit
  14. blueso some of that requires cit std capabilities
  15. blueI assume dog will be able to run primate by the end of the year, phaleth
  16. bluedog 0.1 will only release once it can run repopack, anyway
  17. blueand then we can try running repopack with `dog --engine v8` or `dog --engine jsc` or even `dog --engine qjs`
  18. phalethah, yeah, but rcompat will not cease to exist, right? it's just with dog one won't have to install rcompat
  19. phalethor any of it's packages
  20. blueyes. with dog you won't need to install rcompat at all
  21. blueand primate/repopack/etc. will just use std:
  22. bluewith flog/dog, primate's dependencies will shrink to basically only the frontends. @primate/core will likely stop having any dependencies at all
  23. bluewhich is the goal
  24. phalethwell, I guess for example primate website uses only a small portion of the rcompat APIs
  25. blueyes
  26. phalethand so I'd suggest focusing only on that first, then deploy primate website on dog
  27. phaleththen observe
  28. phalethalso I thought @primate/core only depends on pema, for some odd reason
  29. bluepema + esbuild + @rcompat/*
  30. bluepema is workspace
  31. phalethbut primate 0.43 took care of server side JS being sent to client, so that does not matter
  32. blue@rcompat/* will drop in dog
  33. bluethe only thing we'd need to replace is esbuild. flog will likely replace esbuild at some point, but not right now
  34. bluethe dream stack in 2027 will be just flog/dog
  35. phalethoh really
  36. blueyes
  37. bluewe'll be running purely on our own gears
  38. phalethyeah, but esbuild is just a bundler and it has good enough APIs
  39. blueyes but flog will already contains everything it needs to create bundles
  40. bluecontain*
  41. bluebecause it has stick for `flog format` and `flog lint` etc.
  42. blueI don't dislike esbuild, but also I don't need a thousand tools all doing the same thing
  43. bluethe lesson that esbuild taught us is that Go is a bad language to write engines, but a great language to write tooling, even if they include interpreters
  44. phaleththere is not much to gain there, also mostly if it's only going to be primate specific
  45. phalethall these esbuild alternatives exist for pretty much no reason and one way or another they were either bundling or copying esbuild anyway
  46. phalethalso the goal should really be to run TS as is and be able to optimize based on types
  47. phalethbut that isn't of course going to happen cause of moving web standards
  48. phalethand you know vite is somehow holding on cause of venture capital, but once these investors bail the org behind vite all the projects depending on it will have to look for something else
  49. phalethblue: btw, take a look into aspen https://github.com/reason-machines/aspen
  50. nevetGitHub - reason-machines/aspen: A self-hostable Git server for agent-scale traffic: packs in object storage, per-branch history in Postgres. Pre-alpha.
  51. phalethI mean at lest the readme
  52. blueyeah I heard about aspen
  53. bluewe're building a git alternative as well
  54. bluehttps://repopack.com/project/repopack/tasks/850
  55. phalethheh, yeah, single file change with so many rebases
  56. liolocyou're making a git alternative??
  57. liolochi btw :D
  58. phalethhi
  59. phalethgit as a client will remain
  60. liolocbtw created https://repopack.com/project/primate/tasks/357, with it you can use primate to build to an ios simulator or ios device. Haven't actually tried notarising the app or anything like that, so this is mostly for building. I tested with a simple primate app with a react shadcn button
  61. liolocphaleth: hey! so what did blue mean by "we're building a git alternative as well"?
  62. lioloci'm confused lol
  63. phalethclassic git is just openssh on the server side, but the problem with that approach is that it abuses filesystem a lot, and also keeping files and database records in sync is difficult, so we've already thought about moving everything into postgres to keep the data in one place in the past
  64. liolocso git would just be used to push to the repo?
  65. liolocbut not for tracking actual changes?
  66. liolocno uhh that doesn't make sense
  67. liolocvery cool idea I'm just not smart enough to follow what you mean
  68. phalethnope, the functionality should remain, just the disk load and maintainability of the system server side will differ
  69. liolocah ok
  70. phalethwell I also don't understand exactly how repopack works right now
  71. phalethbut I find it kinda dumb to just slam the harddrive, so I don't care
  72. liolochaha
  73. phaleththere is openssh server and some sh scripts in the system using curl and what not, it's kinda overcomplicated
  74. liolocwow i didn't know it was so confusing
  75. liolocare you guys using any agentic framework when building? I'm trying to build workflows that I can use to create code in a controlled way, curious if you guys have any tips / ideas on that
  76. lioloci'm going to test flowise right now
  77. * phaleth quit (Quit: phaleth)
  78. liolocnvm flowise sucks