Fork me on GitHub

Hi, can I ask what happened to Copilot development? From time to time i have checked but now it is dead.


Sure. The truth is I ran out of time in my daily life to work on it, and the person that was working on it with me also ran out of time to work on it. I really don't have any more time to dedicate to open source, nor another startup. I currently run two of those, and co-pilot was the most risky as far as return on investment of time.


Ah, I can imagine ;). Maybe somebody will take up the burden. Thanks for the info :-)


If I hit a point where I can take an actual vacation, and then have less than 40 hours of work to do a week, then I may do a sprint to get it up to the point of alpha quality, and see what happens. Don’t hold your breath, though. Best-case scenario for that kind of dreamy existence is 6+ months away

👍 2
Jakub Holý (HolyJak)11:03:18

I very much hope you will get a vacation in a not too distant future. We do not want you to burn out or collapse from overwork 🙂

💯 5

Book updated to include more strong language about the dangers of lazy seqs when combining code from the React js ecosystem:


Also updated the examples to use mapv as a subtle encouragement, even though Fulcro’s own library functions correct the lazy seq problems.

❤️ 1

Fulcro statechart support. See #announcements Basically an alternative to UISM that has some distinct advantages (follows an international standard, has hierarchical state, statecharts can “invoke” other statecharts (like function calling, but much more interesting), is more pluggable, etc.). UISM will continue to be supported as well if you find you prefer it.

😻 3

The statechart construction is also tolerant of nested children, allowing you to create much more expressive charts. For example, I recently wrote (private code in my project) a state wrapper that resolves actors to their classes, and routes to them, so that when entering a state, you see a particular screen:

(defn rstate
  "Just like `ele/state`, but auto-adds an on-entry node that ensures that the given actor is on-screen via
   the routing system."
  [{:keys [route-target route-params] :as props} & children]
  (apply state props
    (on-entry {}
      (script {:expr (fn [{:fulcro/keys [app] :as env} data]
                       (enc/when-let [Target (if (keyword? route-target)
                                               (scf/resolve-actor-class data route-target)
                                      path   (rroute/absolute-path app Target route-params)]
                         (dr/change-route! app path)))}))
so then I can just embed that in a chart:
(rstate {:id :state/gathering-credentials 
         :route-target :actor/login-form})


(rroute is RAD routing)


this could, of course, easily be extended to allow route-params to be a (fn [env data] …) that could be run in there as well to make it more dynamic…just haven’t needed that yet.


Anyway, I’m finding a lot of leverage in being able to even further decouple my logic from the (pure and declarative) UI, yet group it into an artifact that I can follow.

❤️ 1

We just started taking on statechart server-side, so this is a great and wonderful surprise, thank you @tony.kay!


Nice, yeah, I’ve been using it there since I released it. I made a durable store and event queue using PostgreSQL. It’s been working very well.

Thomas Moerman09:03:08

@U9E8C7QRJ out of curiosity, what is the use case are you applying statecharts for?