Clojurians Log v2

I want to use tools.deps add-lib. When I started using the addlib3 branch, shadow-cljs would no longer work. Any ideas how to use add-lib in a way that most dependencies of tools.deps are the same as on master?

Are you using this SHA 241cd24c35ba770aea4773ea161d45276e5d3a73? That's up-to-date per March 30th which ought to be recent enough for Shadow-cljs.

Can you be a bit more specific about "no longer work[s]"?

I'm using that version of t.d.a all-day, every-day -- although not with cljs.

I am going to add spec on the values passed to chan? Where to put the validation part? Also, is spec on chan a proper place?

Is there any way to extend stuff so that seq and friends work directly on a https://guava.dev/releases/19.0/api/docs/com/google/common/collect/HashBasedTable.html ? Not super important but would be nice. Work arounds are fine enough.

(extend-type HashBasedTable
  Seqable
  (seq [coll] ...))

Unfortunately there is no mechanism

obv. you can just write a function to do it

(defn hash-based-table-seq [hbt]
  ...)

and in whatever contexts you need it to happen automatically wrap it

(defn hash-based-table-as-seqable [hbt]
  (reify Seqable
    (seq [_]
      (hash-based-table-seq hbt))

ah well. I never considered the reify trick. I’ll see if that is a good fit in certain places. Thanks!

you can also do the newtype/composition trick - make a deftype that implements all the same interfaces as HashBasedTable and just wraps it, then mimic instance and static methods with functions in a namespace

Its more verbose, but its the OO way to go when you don't have inheritance

@slack1003 https://gist.github.com/bowbahdoe/407feefcaa759a9941d4583d2fa02730

HashBasedTable seems to be defined basically just by the interface, so this should be a drop in replacement wherever you are using it now

minus maybe the equals definition

@emccue Nice! Cheers. Yeah using a wrapper like that should be an upgrade on my current code.

curious - what is your use case for a data structure like this?

Optimizing some stuff thus making the code less idiomatically clojure. It is part of the frame graph for rather flexible rendering in a game loop. My take on https://www.slideshare.net/DICEStudio/framegraph-extensible-rendering-architecture-in-frostbite or https://github.com/acdemiralp/fg Everything started of represented with immutable neat clojure data structures. I am happy enough with the interface but I need quite a bit more perf and a little more control over garbage. And in this particular case I don’t really need the immutability. I have denormalized a few things and this HashBasedTable seems like a good storage type for a few things. I’ll see what the profiler has to say after I finish up a few things.

Some graph algorithms aren’t great to write against immutable data structures anyway. I always need a topological sorting of my graph but my graph does not change wildly frame to frame. So I implemented https://dl.acm.org/doi/10.5555/1862199.1862208 My version going against the mutable data structures is cleaner and faster than my old version and looks more like the algorithm in the paper.

lmk how that goes - I am curious how it turns out

will do!

I’m trying to save the following to postgres using next-jdbc:

{:updated-at #object[java.time.Instant 0x2c51100f "2021-06-13T18:25:59.271Z"]
 :user-id "xxxx"}

Execution error (PSQLException) at org.postgresql.jdbc.PgPreparedStatement/setObject (PgPreparedStatement.java:1011).
Can't infer the SQL type to use for an instance of java.time.Instant. Use setObject() with an explicit Types value to specify the type to use.

According to https://cljdoc.org/d/com.github.seancorfield/next.jdbc/1.2.659/doc/getting-started/tips-tricks#working-with-date-and-time

By default, PostgreSQL's JDBC driver does not always perform conversions from java.util.Date to a SQL data type. You can enable this by extending SettableParameter to the appropriate (Java) types, or by simply requiring next.jdbc.date-time.

In addition, if you want java.time.Instant, java.time.LocalDate, and java.time.LocalDateTime to be automatically converted to SQL data types, requiring next.jdbc.date-time will enable those as well (by extending SettableParameter for you).

Any ideas why I’m receiving this exception? Thank you

(whoops. misread java.util.Date in there)

It works if I convert the java.time.Instant field to #inst but I’m hoping not to have to do this, as specified in the doc above

what server-side frameworks are people using and enjoying for writing web apps in clojure these days?