Clojurians Log v2

What I think has more potential isn't a visual editor, but a more semantic aware editor where the editor guarantees that all edits always compiles and are valid syntax. I've thought about this before, but every-time you'd def, instead of using some text id which is the def name, the editor would provide an auto-generated GUID for it instead, and there's be meta similar to docstring that would be docname which is the name you'd normally be entering. That type of thing. I mean we get close-ish to this in Clojure already if you use strict strutural editing, but this goes beyond and assume your editor has lots of semantic knowledge, and the UI is not strictly letting you modify text free-form. Unison: https://www.unisonweb.org/ comes closest as I know to what I'm talking about.

Recommend this talk about it if you're interested: https://www.youtube.com/watch?v=gCWtkvDQ2ZI

Object reference writes are always atomic

I'm certainly not writing (nor seeking to recommend writing) such code! I was just curious, I hadn't before considered the possible differences of tearing between 32/64bit jvms. On my specific question about long tearing on a 64bit jvm, the JLS appears to say tearing is technically still possible, as the copying of longs is JVM implementation dependent, so you may not officially depend on atomic longs.

When implementing an interface / protocol with multiple overloads in defrecord / reify this readme https://clojure.org/reference/protocols seems to suggest writing (foo [ ] ...) multiple times. But later on in the readme I see:

(extend-type MyType
  Countable
    (cnt [c] ...)
  Foo
    (bar [x y] ...)
    (baz ([x] ...) ([x y zs] ...)))

It isn't the same for extend type vs reify or defrecord

For defrecord / deftype you do a method per arity (like java without types, because it ends up generating methods for each), for extend type it is like fns with a different body per arity because it actually macro expands to a fn

thanks

A little while ago I recall seeing a clojure editor like this

Can anyone recommend a Clojure product/library/tool similar to Python's celery (aka task execution from a queue -- https://docs.celeryproject.org/en/stable/getting-started/introduction.html). Or does everyone just kind of roll their own for that sort of work in Clojure?

https://github.com/crabhi/celery-java

I think you can just use celery

I haven't gone far enough to know what to recommend, but my money is on there being pretty robust Java solutions you can use

quartz or whatever the heck

@goomba are you planning to use RabbitMQ? Is celery compatibility required (e.g. you have python publishers/consumers)?

no, just looking for similar conceptual functionality

After a few years with Celery, I would not recommend it to anyone. :) But I got pretty bitter with the whole Python ecosytem. With that being said, I couldn't find any complete replacement. Here are some links with similar/related stuff that I've gathered, maybe they will be helpful: - http://immutant.org/documentation/current/apidoc/immutant.messaging.pipeline.html - http://www.quartz-scheduler.org/ - https://github.com/prepor/twarc - https://redisson.org/ - https://github.com/gresrun/jesque - https://github.com/apache/storm - http://www.onyxplatform.org/

@p-himik agreed re:Celery 😉 Dang awesome list or resources!!

Ah, yet another few: - https://github.com/framed-data/overseer - https://github.com/mikub/titanoboa - https://github.com/schmee/daguerreo

We have built our own RabbitMQ library/component https://github.com/nomnom-insights/nomnom.bunnicula - currently processing millions of jobs every day

Does it handle computation DAGs?

(was that to me or @lukaszkorecki. @p-himik?)

lukasz

@p-himik no, it's a "simple" job publisher/consumer thing. DAGs etc are out of scope (not sure how it would all work to be honest, it's not something we need, at least as a "hard" concept)

Hey, I'm trying to upgdate my dependencies with lein ancient and I keep getting this: "Syntax error compiling var at (midje/util/exceptions.clj:75:3).\nUnable to resolve var: aviso.exception/traditional in this context\n"

Does anyone know how this could be fixed?

@franklineapiyo Sounds like a version conflict between one or more libraries. Do you have stuff in your ~/.lein/profiles.clj file? That's often the most common cause of problems with Leiningen.

Yes I do. bu the only thing in there is {:user {:plugins [[lein-ancient "0.6.15"]]}}

And you're getting the exception from lein ancient itself? Or when you try to run the project after it has updated it?

(or are you just trying to get a report of outdated dependencies to update them yourself?)

I'm getting this from just running lein ancient

I've tried to run lein ancient interactive mode and this only happens when I try to upgrade midje, clojure or dk.ative/docjure

trying to upgrade any one of them or all of them at the same time causes this error

not sure if this will help, but try lein with-profile -dev [whatever goes here]

You could just update these things manually -- but the problem looks like recent versions of Midje depend on that var, which was introduced in Aviso Pretty 0.1.15, which all happened a few years ago.

Running that... I get Reflection warning, dk/ative/docjure/spreadsheet.clj:642:17 - call to org.apache.poi.ss.util.CellReference ctor can't be resolved.

I don't really trust any tools that try to update my project configuration "automatically"...

But @seancorfield, I don't see Aviso Pretty anywhere in my project.clj... I'm a bit of a newb.. how should I update something that isn't in my project.clj... I think it's a dependency of something that's in my dependencies correct?

Part of me feels like saying "Stop using Midje -- that's part of your problem"... 🙂

Since this is probably going to be a fair bit of hand-holding to get to the bottom of this and you're fairly new to Clojure, perhaps share your project.clj file in #beginners where folks have opted in to spending more time digging into basic problems like this (I'm happy to continue digging into it in #beginners )

sweet!

(there's an expectation in this channel that you can mostly debug dependency conflicts on your own)