This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-06-13
Channels
- # babashka (1)
- # beginners (11)
- # cider (8)
- # clj-kondo (7)
- # clojure (35)
- # clojure-italy (2)
- # clojurescript (6)
- # conjure (5)
- # datomic (10)
- # duct (7)
- # fulcro (9)
- # helix (2)
- # introduce-yourself (5)
- # lsp (3)
- # malli (7)
- # meander (3)
- # off-topic (8)
- # pathom (3)
- # podcasts-discuss (2)
- # portal (9)
- # reitit (7)
- # releases (3)
- # shadow-cljs (43)
- # sql (25)
- # tools-deps (3)
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] ...))
does not work which makes enough sense given that Sequable
is a java interface and HashBasedTable
is a java class.
I was wondering if there was some other mechanism I was missing? Not really seeing an avenue when I look at the clojure source code for seq(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
HashBasedTable seems to be defined basically just by the interface, so this should be a drop in replacement wherever you are using it now
@U3JH98J4R Nice! Cheers. Yeah using a wrapper like that should be an upgrade on my current code.
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.
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"}
I’ve already required [next.jdbc.date-time]
but there’s this error:
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.
If you’ve required next.jdbc.date-time
then this protocol will be in effect: https://github.com/seancorfield/next-jdbc/blob/develop/src/next/jdbc/date_time.clj#L40-L50 and Instant
will be stored via .setTimestamp
. If you’re seeing that exception, That protocol is not in effect. Without seeing more of your code, it’s hard to tell what you’re doing tho’
(also, I’d have probably seen this sooner if it was posted in #sql)
Thanks @U04V70XH6 I’ll be posting in #sql
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).
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