Fails with future returned by Datomic. #17
Comments
|
I believe this is essentially the same issue as #8 - I'm hoping to make some headway on both of these in the near future. |
|
Hi @benkamphaus - what version of datomic free are you using? I can't seem to replicate your initial output. |
|
|
I see this behavior on the latest version (0.9.5130) on both free and pro, Lein dependencies as: or |
|
@benkamphaus Would you mind seeing if this behavior is still present with the latest version of Ultra (0.3.0)? I believe this should be resolved. |
|
Better make that 0.3.2, since I'm an idiot. |
|
I'm still seeing it with 0.3.2. I've observed the same behavior (as listed above) with: as the exception (stacktrace is identical). Tested on: Ubuntu 14.04 Environment isolated to this as only lein plugin. JVMs: Oracle JDK 1.7.0_67 Various Datomic versions tested, including: 0.9.5130 At least as far back as: 0.9.4572 Not sure if this info helps or is just superfluous. |
|
What version of Clojure are you using? |
|
1.6.0 |
|
Great, and which version of Leiningen? |
|
2.4.2 on the Ubuntu VM. |
|
Ah, great - I've been able to successfully reproduce this. Not quite sure how this sidestepped the fix introduced in |
|
@greglook I'm afraid this is boils down to another Puget issue; It makes me wonder if, rather than testing for interface satisfaction, Puget should check for class membership, at least when it comes to printing documents that Puget expects to be core Clojure types. I don't know if you have thoughts on this. I'm fine with building an escape hatch in Ultra for Datomic in the short term as well. |
This commit adds a new namespace, `ultra.printer.escape-hatch` to allow me to define custom methods for Puget's `format-doc` multimethod. In this case I'm using it to add an escape hatch for `datomic.db.Db` objects; it's a temporary workaround until I can figure out a better long term solution with @greglook, though it'll work fine for now. This commit also adds a bugfix for colorscheme selection that was introduced in `0.3.0`. This commit is therefore intended to resolve both #23 and #17
|
@benkamphaus - I've added a temporary escape hatch for In the longer run I think @greglook and I will want to figure out something in Puget to address this, but I think this sort of escape hatch may be a necessary device in the near-to-mid term for Ultra to provide support for popular libraries like Datomic where I don't want to leave users out in the cold. |
|
Hm. This escape hatch issue creates problems for projects that don't use Datomic. There's probably an easy way around this, too, but it warrants additional thinking. |
Hmm, that might work, though it would be a bit more brittle that way. I think we're starting to bump into Puget's origins as a canonical serialization library rather than a colorizing pretty-printer. I wonder if there's a way to check if a class is loaded without blowing up if it's not present? If so you could curate some |
|
That's sort of what I had in mind for my next task at this - grab the class, cast to string, check if that string matches a list of known class strings and if so, use the object's built-in print-method. Feels very monkey-patch-y, but it's also relatively painless to backdoor into Puget from Ultra. |
|
The latest commit (2fded31) on the |
|
Closing as this will be resolved once 0.3.3 ships. |
|
@benkamphaus 0.3.3 is up on Clojars now; datomic should be happy working with it. Let me know if you find this not to be the case. |
|
Works beautifully! Thanks! |
Hi I've been playing around with ultra and enjoying it a lot. Unfortunately, most of the work I do at the repl is with Datomic and there's presently an issue with handling the deref of the future returned by a datomic transaction. If you include Datomic free in a library, this is a simple reproduce case:
Stacktrace:
With ultra disabled, the output of the deref is:
{:db-before datomic.db.Db@133188bf, :db-after datomic.db.Db@28cd0b35, :tx-data [#datom[13194139534312 50 #inst "2015-02-20T14:48:52.680-00:00" 13194139534312 true] #datom[17592186045417 62 "hello world" 13194139534312 true]], :tempids {-9223350046623220288 17592186045417}}The text was updated successfully, but these errors were encountered: