@veix.q5 try ((wrap dedupe) [1 1 2 3 3 4])

In your code you end up calling 'wrap' with the result of a no-arg call to dedupe.

@the2bears wrap expects a transducer and returns a transducer

@veix.q5 the reducing function returned by the dedupe transducer is stateful. The reducing function returned by wrap rebuilds a new transducing chain for each reducing step, so the previous state of dedupe is lost

How would i test code like this with something like clojure.test?

I want to spin up a socket server and actually try sending messages to it then shut it down

but i cant kill a thread on command so im a bit at a loss on how to go about that

@emccue can you store the server-socket or (.accept server-socket) in an atom? Then you can start it, do tests and call (.close @socket) on it when done

alternatively, this is where things like Component make things easier, as you'd create a component for the socket server and your -main is only responsible for starting the system and holding on to it (or storing it in an atom in the core namespace)

@emccue also, this might be helpful - our Statsd client ships with a UDP server based on Aleph, and we're using it to verify that the client is sending the right metric data: https://github.com/nomnom-insights/nomnom.stature/blob/master/test/stature/statsd_test.clj#L13

@lukaszkorecki at least in the way the code is, it's a blocking thing

So if I run my socket accept then I can't do more

And if I offload it to a thread then I don't know how to impl the stop

Does that make sense?

I could put the sockets into some global registry

That does make sense

Yep, then your option would be to wrap the accept call in a future and use callbacks when receiving / writing to a socket

and then (.close @socket-future)) to close it

or use Aleph 🙂 it implements the socket server too and is slightly easier to manage than Java classes

https://aleph.io/aleph/tcp.html

i think there's something off with the clojure package that is out there for ubuntu people .. running it just on it's sure does start the repl ... but it totally seems to ignore the deps.edn file and doesn't do any of the -A handling

installing the clojure with the installation script from https://clojure.org/guides/getting_started however seems to behave in expected ways

discovered the difference in behavior by accident, was checking out clojurl as a graalvm native-image example (as i had trouble getting native-image running with just snap of my fingers) and bashed my head for 5-10 minutes before i figured out that the "clojure" i had ... wasn't really the clojure that the readme examples expected it to be

@kulminaator That predates the CLI/`deps.edn` stuff by quite a while and it's just a small wrapper to running scripts or starting a REPL.

There's a few "rogue" packages out there on various platforms that are like that and predate the CLI/`deps.edn` from Cognitect. Windows has clojure on Chocolatey I think that is about the same as what you mention on Ubuntu...

well ... can we help the package managers out with more up to date samples ?

the weird part is that the clojure version in the package is new, it's just the shell wrapper build up that seems to be wrong

it has clojure 1.10 under the hood but all the wrapper seems to do right now is end up with invoking this exec $rlwrap java -cp /usr/share/java/clojure-1.10.jar"$extra_classpath" clojure.main "$@"

@ehashman Probably has some insight into how/when that package came into existence (the bionic/clojure page lists her as maintainer and I remember her talking about that work ages ago).

I don’t think they’ve had time to integrate the new Clojure stuff yet in the Debian packages

They build everything from source and there a ton of downstream deps (Maven) that all need to be bundled too

Yeah, I recall Elana saying it was a very involved, elaborate, and slow process.