In order to use httpurr.client.aleph in my project I must add [aleph "0.4.1-beta4"] to my deps. Is there a reason for this? It seems unnecessary.

@kenny: usually when integrating with third party libraries we mark the dependencies as "provided", the user is in control on what version of aleph wants

this way you choose the exact version of aleph you want to use: you can even depend on a modified version of aleph, a snapshot, whatever suits you best

Methinks this would be a nice addition to octet: (defn data-size [spec data] (if (satisfies? spec/ISpecDynamicSize spec) (spec/size* spec data) (spec/size spec))) I really like octet, though it is missing a lot of things from java.nio.ByteBuffer that I really need. (I'm porting java code these days to clojure/clojurescript.) but I really really love typespecs.. So I wrote a buffer namespace as part of my cljc library utilities (aautil): https://github.com/aatree/aautil#buffer

hi @laforge49 , thanks, I will consider adding that function to the octet, but pr is very welcome if you want get it quicker

about missing functions for java.nio.ByteBuffer, seems like they are very coupled with the nio implementation. I also found them useful but I don't see them for the core api of octet

but maybe have a little octet.util.nio ns with that functions

octet is designed for read/write typespects

not manipulate bytebuffers

but, you are right that manipulating is also very usefull and maybe we can think in a little subset of api that can work for all buffer implementations (clj and cljs)

and other, platform dependent subset put in a secondary, utils ns..

No rush here, I've got lots of non-idiomatic clojure code (converted from java) that I'm moving to cljc. But yeah, it is always better to fold things in when the fit is good enough. I love typespec, and by buffer ns integrates that in very nicely with all the rest of the nio byte buffer capabilities. Like octet, I don't wrap on the Clojure side, but on the clojurescript side I had to wrap to have a place to hold all that extra state.

Also note that in my code I bypassed your core read/write as you were using locked. That reminded me too much of the very slow HashTable from the old days. More an issue for me since I plan to have lots of reads/writes to a given buffer.

Overall, I found the octet code a pleasure to work with. And specs to be quite inspirational.

nice to hear that! thanks for your words!

It is only the truth. The good with the bad. But looking forward to whatever you work on next.

I'm finding that there is a general deficiency of libraries to mask over the differences in libraries available in clojure vs clojurescript. We've got a long way to go. cljc in and of itself is only a small start.

And it looks like we have similar interests in this area.

In general in funcool we are trying to solve that problems, doing libraries multiplatforms and solving the doc problem

promesa and urania is an other example of that

httpurr is also a great a example of simplification, great doc and multiplatform support

I'm working it from the other end. A database in Java, very similar to datomic, largely converted to non-idiomatic clojure and banging on a cljc version. But with a commitment to spinning off useful pieces, testing and documenting them.

But man it goes slowly. I'm not a js guy at all, which is why I love clojurescript. But there is so much to learn. So for example, code to handle running IndexedDb in a WebWorker (in cljs): https://github.com/aatree/aaworker AND https://github.com/aatree/durable-cells