Clojure now supports a socket REPL https://clojure.org/reference/repl_and_main (scroll down to section on socket server) Not quite the same as drawbridge, but maybe of use

The result of your next.jdbc query is a namespaced map. To access the data, you can: (:tenants/name result)or (get result :tenants/name) More informations on https://clojure.org/reference/reader#_maps

Thank you. That works fine but is there a way to simply get all the content at once without the namespace?

Like i can write a function that manipulates the data but sounds like a pretty basic thing to do

Yes. next.jdbc has specific config for this https://cljdoc.org/d/com.github.seancorfield/next.jdbc/1.2.780/doc/getting-started#options--result-set-builders

You're the best! Thank you!

@UHZPYLPU1 there is a very strong argument for keeping the namespace, which manifests when doing joins. If you join a table to another table (and those tables have similar column names), then unless you take preventative measures yourself, then there is no guarantee that the value of the column will contain the value you want.

Using namespaced keys prevents that, in addition, it's quite easy to destructure the data, i.e.,

(let [{:tenants/keys [created_at name id deleted_at]} tenants] (println created_at name id deleted_at))....

It's strongly encouraged in the documentation to try to keep the namespaces 🙂

@U11EL3P9U I agree with you 🙂

@U033V0AJFU4 namespaces are good 🙂

Namespaces are good, but Clojure’s printing of “namespaced maps” are not, in my opinion. If you turn it off it is much easier to understand how to work with the data, and in my eyes easier to read:

(set! *print-namespace-maps* false)

This just changes the visualization, so instead you’d see

{:tenants/created-at ,,,
 :tenants/name ,,,
 :tenants/id ,,,}

Will keep all that in mind! Thanks a lot guys!

I have this beauty in several codebases :thinking_face:

(defmacro forcat
  "`forcat` is to `for` like `mapcat` is to `map`."
  [& body]
  `(mapcat identity (for ~@body)))

At that point, I'd probably use reduce.

why not just use mapcat ?

Because for has capabilities that mapcat does not.

that's true

reduce is closer to mapcat than to for, but you'll be building a single collection, without anything intermediate. With either for or mapcat you will have either one intermediate lazy collection that will be thrown away or a whole bunch of them. But maybe I'm overthinking things, that happens too. :)

how about common lisp loop macro if you really want to overkill

Use the return expression as another binding (for [x xs y (body ,,,)] y)

Thanks all 🙂

@Ben That is my favourite suggestion 🙂

> how about common lisp loop macro if you really want to overkill did someone actually port loop to clojure, or do you mean clojure.core/loop?

loop in common lisp is a DSL implementing a language that definitely isn't lisp

(loop with list-a = '(1 2 3)
      with infinite-list = (setf (cdr (last list-a)) list-a)
      for item in infinite-list
      repeat 8
      collect item)
;; (1 2 3 1 2 3 1 2)

you can close over for a one-time thing, or you can give the go block a channel and send values to the channel

Thanks, I've used both of those before and they work fine. I guess if one allowed values to be pushed into go blocks, there has to be some thought put into buffering and orders, like I send a shitload of values, does it just block/explode? I send a value before it's expecting one, does it just hold it until it needs it? I send a value when it's never expecting one, does it throw?

that's why we channels with a variety of buffer choices

go blocks are kind of implicitly buffer 1 right, they'll wait until each value is pulled out to continue

go blocks don't have buffers at all

are you referring to the output channel returned by a go block?

if so, that's a channel with buffer of fixed size 1

that's what I meant, the output channel

but you can also give a go block an explicit output channel that does whatever you need

Exactly, so to make input and output symmetric since they're implicitly buffersize 1 for output, being buffersize 1 for input would be logical

they are symmetric - you can supply both to do whatever you want :)

yeah it's definitely not a concrete limitation I was just wondering whether there was another design choice that would allowed for slightly more succinct code

as you say it can be achieved by passing in the channel

Putting into a go block doesn't really make logical sense.

You should think of go as starting a sequential process. It is more akin to (Thread.)

It's like that in a primitive way. And then you can if you want build higher level abstractions on top.

(defn adder-3
  [value]
  (go (+ 3 value)))

(go (println (<! (adder-3 10)))

go is a machine, channels are conveyor belts

machines can take inputs or provide outputs on 0...N belts

So to be clear, in your case, you can easily achieve what you want by just wrapping a go block in a function, like in my example code above.

And to Alex Miller's point, that's often how you do it, just using a function around the go machine.

(defn some-go-process
  [input-chan-0 input-chan-1 ... input-chan-N
   output-chan-0 output-chan-1 ... output-chan-N]
  (go
     ;; Take from the input chans as needed
     ;; Put on the output chans as needed))

#{} creates a set, which is not ordered. I'm guessing you wanted {}

Oh, derp, that was it. I’m getting schema data from datomic, and pulling out bits of it to generate mock data for tests, and somehow the extra # slipped in while I was editing.

just want to point out you can leave the prefix style and use other namespaces or even no namespaces

#:foo{:abraham 1
      :martin 2
      :john 3
      :bar/puff 4
      :_/no-namespace 5}

so how do you refer to the namespace called _?

do you just not?

i was thinking about that. its a legal keyword :_/foo. Not sure if it is expressable in this instance

Yeah, seems to be the case

ya, it’s one of the only objectively bad things in the language, imo

Yeah, I think it was a mistake.

It's actually the default

The clojure.main repl overrides it

SCI?

ah nice, i haven’t checked it out. use case: I am reviving an old project where I scraped a ton of s-expressions from the #clojure IRC channel’s logs, and then ran everything that looks like a valid sexp in a sandbox. i then captured the values and outputs of each of them, and made the result searchable

as of 1.5.1 I got to about ~32,000 working expressions, looking to make another pass on this with latest clojure

one thing i don’t immediately see in SCI is a notion of a timeout. plenty of expressions in the input set run for an infinite amount of time

I know that someone has tried using clojurescript + https://www.stopify.org/ for this purpose. Not sure how well it worked.

I know sci is sometimes mentioned as a sandbox tool, but I haven't seen anything that demonstrates what usage might be safe or demonstrate that "safe" usage exists. Since sci relies on an uninterpreted clojure.core library, I don't think it's realistically possible to prevent non-terminating programs or programs that consume arbitrary amounts of memory. Another approach is to set restrictions at the OS process level.

ill probably do both

A couple of weeks ago I had the same question. After reading the source code of clojure.test, the relevant documentation, examples, and other materials, it seems that dynamic variables are the way to go.

darn

I can always do something with macros (first rule of macro club)

Correct

strings are not Counted

at least for the purpose of bounded-count, it falls back to the seq path

(I think alex was saying "correct" to your last clause @U06DQC6MA -- there's no need to call bounded-count on strings)

right, makes sense

thanks

Yeah

clojure.core/count should be O(1) runtime on strings, but because clojure.lang.RT/count Java method has an O(1) implementation for it.

Yeah, but strings do not implement the Counted interface, so looks like bounded-count would be linear time on strings.