Something like the following:

(ns-requires *ns*) ;; => [clojure.set clojure.string]

@U0220KPQ5CH a namespace is either already loaded or it is not, but it doesn't matter which namespace did this, so this information isn't saved anywhere I believe. you can inspect the aliases that are valid within a namespace

This can give you some info:

user=> (binding [clojure.core/*loading-verbosely* true] (require '[clojure.set] :reload))
(clojure.core/load "/clojure/set")
nil

Thanks for the help. I'm trying to solve a problem where I want to test if the given namespace loads the proper list, so I can have lein test signal if something weird is going on. We're using a bit of dynamic namespace parsing, so it really matters for us which namespace loads what

for testing you could use with-redefs on require

user=> (with-redefs [require (fn [& args] (prn :req args))] (require 'clojure.set))
:req (clojure.set)
nil

(ns-aliases (find-ns 'foo.bar))

@U05224H0W that's not sufficient here:

user=> (require '[clojure.set])
nil
user=> (ns-aliases *ns*)
{}

true, it is not 100%. most of the time things will have :as aliases though so should be good enough

Not for my case, unfortunately

What you can also do as a test is, require a namespace and test if after doing that, the other namespaces have been loaded?

hmm yeah then it gets tricky, especially if there are some namespaces that are AOT compiled since those won't show up in regular require logs

unless you temporarily re-define require using with-redefs

once it enters AOT loading it won't use require anymore so redef does nothing

I think I can parse out the require list or go with the with-redefs solution

true

Try to benchmark java version when you create seed each time. Notice that clojure version probably allocates it since it is not an input argument

Seed is expected to be done once ! If I re-init seed each time, I'll have always the same result

I don’t know why. Why does it matter?

Sorry @U064X3EF3 I don't understand. Why the performance is important? the seed?

What's the reason behind the whole thread?

1. I feel like a newbie so I may have done something fundamentally wrong 2. If that implementation is quicker and equivalent (what I think), it may be an improvement, something like :

(def ^java.util.Random seed (java.util.Random.))

(defn rand-int-alternative
  "Returns a random integer between 0 (inclusive) and n (exclusive)."
  {:added "1.0"
   :static true}
  [n] (.nextInt seed n))

If you need more context I am trying to port an operations research tool I built years ago in C++. That kind of algorithms are combinatorial optimization, with a huge number of iterations on int-array. I start with some benchmarking between java and clojure and find out the global execution time gap was due to that rand-intfunction. That kind of use case are demanding from a time execution prospective (billion of iterations are expected).

thanks, that was the context I was looking for. I don't think anything is preventing you from using your alternative method. I don't know why it's implemented the way it is. I'll make a ticket out of it when I get a chance.

yes, I agree this is not a critical issue. Thanks for your confirmation to use the 'alternative method'. It's all what I need.

ok, I'm just trying to learn what a gist is first, (;p

or pastebin :)

I did it !

yay :)

And I followed the question to http://ask.clojure.org following your recommandation. Thx.

last one is good except it could be in transducer form:

(into {} (map (juxt :key :value)) coll)

what do you think is wrong with it?

not sure. i think it has something todo with the fact this the expression is saying ‘add this value under this key’, but in my head i’m thinking ‘add as this key’. i suppose (juxt :key identity) would express that. thanks!

(juxt :key idenity) creates a different output though

whenever I find myself writing (juxt ... identity) I reach for Medley's index-by

What does #object read into ?

(defn joda-time-data-reader [[class-symbol _objid date-time-string :as value]]
  (if (= "org.joda.time.DateTime" (name class-symbol))
    (tf/parse date-time-string)
    (throw (ex-info "Unsupported #object instance" {:value value}))))

org.joda.time.Datetime

in what way does it "not work" ?

When I put

(def x #object[org.joda.time.DateTime 0x3ff80a66 "2021-07-04T09:54:54.937Z"])

(defn y [] #object[org.joda.time.DateTime 0x3ff80a66 "2021-07-04T09:54:54.937Z"])

Syntax error compiling fn* at (src/.../plans/presentation.clj:324:1).
Can't embed object in code, maybe print-dup not defined: 2021-07-04T09:54:54.937Z

Similarly if I just put like (identity #object….) in namespace top-level and try to load it, same error

seems odd that def parses differently than other expressions

right, so the data reader is reading into an object. that object can't be represented in bytecode as a value, so you can't compile the function like that. def is different case

you can probably add a printer for this type of object though and get it to work

you do that by extending the print-method and print-dup multimethods

you then have roundtripping of read/print which are complementary operations

I see, thank you

Also if you define a print operation for these values, then it would be preferable for the reader to not read #object, but rather read something like #joda/datetime

for sure

This will prevent issues with other objects being read as date times.

as the author, I think "advocates" is a strong description - this is an idea, it may be useful, or it may not :)

To your question about how to explain the value proposition of passing arguments vs. depending on globals: It sounds like you're trying to convince colleagues about the benefits of pure functions. Unfortunately, you'll probably have to tailor your arguments to your audience so your pitch will resonate with their specific experiences. Some arguments you could you could be: parallelization of tests - without global state you can safely parallelize your tests. transparency - global state is an additional, silent, side-channel input. It doesn't come through the front door like other function arguments. So the developer who picks up the test/code needs to know all of the relevant context to figure out how the function will behave. If you use pure functions and you know that the behavior only depends on the arguments supplied to the function, I've found it's much easier to understand and easier for other developers to understand.

the idea is that instead of my-insertion-db receiving system it receives the datasource itself?

yes

only what the function needs I guess

but this is just an opinion, do what you want

Just the public APIs generally needs the system-map, other private functions downstream generaly will get only what it needs

yeah, I generally agree on pass only what the function needs, but destructuring helps a lot with this on most part of the time 😄

Ahhh, I guess that it happens because destructuring a map is so easy 😄

I think is more simple / clean to have just a map 😄

I'm struggling to find this on clojure 😞, it has for Elixir though https://dashbit.co/blog/mocks-and-explicit-contracts

when macro-a expands it will make the symbol B/macro-b fully qualified

and if the namespace with that symbol is loaded by any other namespace it will be resolved correctly

Right, I might have been confused on that last point in my CLJC project. Indeed, ns B was being loaded in Clojure but not in CLJS, so it was misbehaving in CLJS. Make sense!

this relation seems really handy: log(AB) = log(A) + log(B). This might get into things like numerical stability and errors related to that

That relation is how slide rules work

I believe Java ProcessBuilder class can enable you to do that. I don't think that the built-in-to-Clojure shell/sh can do that.

https://docs.oracle.com/javase/7/docs/api/java/lang/ProcessBuilder.html

yeah I have a snippet doing that with ProcessBuilder:

(let [pb (ProcessBuilder. ["lua"])
      p (.start pb)
      out (.getOutputStream p)
      in (.getInputStream p)]
  (spit out "print \"hello from lua\"\n")
  (slurp in))

of course for real interactivity you have to use something other than slurp / spit (and that means more complexity) - I'm sure there's some good libs that simplify that streaming IO stuff out there

sounds like you want the stdout / stderr for monitoring? you should be able to .read from the output stream and error stream in a loop and trigger a callback for each line / chunk / whatever

you can also use processbuilder to stream to a file or pipe instead of a stream, and to join the streams if that simplifies your use case as well

Thanks to both of you 🙂

I am using my software to run multiple (shell) jobs concurrently and want output from them ASAP and continually so I can see if anything goes wrong. So yes, I guess monitoring is the word.

@endrebak Example with babashka.process (which you can use as a regular Clojure library):

(require '[babashka.process :refer [process]])
(process ["foo"] {:inherit true})
(process ["bar"] {:inherit true})
.. wait .. e.g. @(promise)

they mentioned they don't want the output to go to stdio of the repl

> and want output from them ASAP and continually so I can see if anything goes wrong oh, I thought he/she/they did say that here

But if multiple jobs send to stdout concurrently they might overlap. Also, I want to send some to the front-end and so on so it would be best to send it to a tap or something 🙂

just make a loop that reads the output line by line, prints it and does whatever else with it

This is all new to me. Sounds like it is not that hard then. Thanks!

I have a similar example to that here: https://book.babashka.org/#child_processes

Here is a simple example that reads the output from yes:

(require '[babashka.process :as p :refer [process]]
         '[ :as io])

(def yes (process ["yes"] {:err :inherit
                           :shutdown p/destroy}))

(with-open [rdr (io/reader (:out yes))]
  (binding [*in* rdr]
    (loop []
      (let [line (read-line)]
        (println :line line))
      (recur))))

@borkdude I guess there should be a (when (not (nil? line)) (recur)) above?

I tried it and it just keeps on printing :line nil forever 🙂

@UT770EY2K you are correct, but the output from yes never ends :)

♾️