Fork me on GitHub
Jon Olick01:05:47

what is the difference between [1 2 3] and (int-array [1 2 3]) ?

Jon Olick01:05:10

I mean, other than needing to use aget, aset, etc for the latter.

Alex Miller (Clojure team)01:05:11

the first one is a persistent vector, the latter is a mutable Java array

Alex Miller (Clojure team)01:05:07

the first is thread-safe and immutable (but takes up more memory) whereas the Java array is not thread-safe

Jon Olick01:05:00

oh so its like a normal array, is that just for space savings?

Jon Olick01:05:16

like when dealing with lots of ints?


It's mostly for Java interop.


There are a whole bunch of them for Java primitive types:

user=> (apropos "-array")
(clojure.core/boolean-array clojure.core/byte-array clojure.core/char-array clojure.core/double-array clojure.core/float-array clojure.core/int-array clojure.core/into-array clojure.core/long-array clojure.core/make-array clojure.core/object-array clojure.core/short-array clojure.core/to-array clojure.core/to-array-2d)


into-array is a generic one -- you can give it a type to create the Java array, or it will deduce it from the first element (or use java.lang.Object if the sequence is empty).


In jo_lisp, you'd map those to the underlying C array types. For into-array, I guess you'd use a pointer type?

Jon Olick02:05:14

yeah or something like a std::vector


How are you representing host types in jo_lisp? In Clojure, for example, Long is java.lang.Long and is a boxed long value (c.f. long which is the primitive long type).

Jon Olick02:05:25

will think about that

Jon Olick02:05:42

there's fast-path types, and "generic" types

Jon Olick02:05:01

fast-path is commonly used types which don't go through function indirection

Jon Olick02:05:16

so the CPU can predict accurately what branches will be taken when

Jon Olick02:05:34

so the question is, is this common enough for me to make a fast path

Jon Olick02:05:07

(I doubt it)


In (JVM) Clojure, people use it where they have to for interop, and only occasionally for performance (like squeezing the best possible performance out of an algorithm by, essentially, dropping down closer to Java types).


In jo_lisp, I guess folks might need it for interop although I don't know how you plan to implement that? And for performance, I don't know whether tight, algorithmic code in jo_lisp is a goal or not? Seems like that would likely get written in native C/C++ and invoked directly in that hosted context?

Jon Olick02:05:28

yeah, my thoughts too

Jon Olick02:05:04

might be better served by providing a C api to convert persistent data structures to normal arrays

Jon Olick02:05:09

but maybe not

Jon Olick02:05:14

I dunno, it depends

Jon Olick02:05:59

I can see the value though in building it directly in native structures for passing to C functions as you go kind of

Jon Olick02:05:05

so maybe the clojure way is a pretty good way


I personally detest languages that don't have arrays. That's a fundamental CS data-structure, you have to have one. It's my personal preference, but imagine not being able to implement your own data-structures in the language itself? That almost feels like you could argue it's not a general programming language if it can't even be extended with custom data-structures. And arrays are fundamental primitives for that.


I have defined a atom in clojure file file1.clj and importing that atom in another file file2.clj (in namespace in require) and changing value using swap! , But when I try to read same atom in again in file1.clj , I am not getting updated value which I have done in file2.clj is it a actual behaviour?


(ns file1)

(def a (atom {:x 42}))

(defn give-me-a []

(ns file2
  (:require [file1 :as f]))

(swap! f/a update :x inc)
And then after file1 and file2 are loaded calls to (give-me-a) return 42 instead of 43? Does it describe your situation?


very strange, it should work just fine. Could you share those namespaces? you can leave there just definitions related to the atom


are you reloading file1 ns after calling swap!? Perhaps you need defonce instead of def to avoid re-initializing the atom.


@U04V4KLKC did you get the same issue in your workspace ?


I am not loading, I am just importing those namespace


no, it works as expected


you either have :reload-all option in your namespace declaration that forces dependencies to reinitialise or somehow hold dereferenced value of the atom instead of using the reference


I am experimenting this on reframe , when I dispatch an event , When i print value in file2 it is giving the expected result, but in file the values are not changing


ok, so it is clojurescript. then it has nothing to do with loading or file concept 🙂 I can't guess without seeing the code, sorry.


it also uses same clojure.core atom,


Will check , Thanks 🙂


clojure targets jvm and clojurescript targets js. you can't use atom defined for jvm in js.


that makes me think you have file1.clj and file2.cljs.


or maybe file1.cljc because you can require it in file2


both are cljs


I'm confused why Reframe has anything to do with your atom. If you do use Reframe for updating and subscribing to a Reagent atom, have you tried to use dispatch-sync? It forces the update immediately.


let me try


If you can't get it to work then at least show us some code. I don't really know what I am responding too 😬


Ahh I could ,it has too many changes and working on enhancement , hard to show that changes


Can I also make use of reagent atom here?


I have no idea what you are doing, but if you say you are using Reframe, then you need to write data to the db using dispatch, and then receive the updated data using subscribe. the db is a reagent atom. Reframe has a lot of code examples to show you how that works. I'd suggest to try and get that working.


yeah that approach is worked fine before, But I was trying to to introduce pagination, thought of refactoring using an atom


Given any number of maps, how do I join them on some key while also keeping all the maps that don't get joined?

(let [data [{:x 1 :foo 42}
            {:x 1 :bar 43}
            {:x 2 :foo 999}]]
  (??? data))
  ; => [{:x 1 :foo 42
  ;           :bar 43}
  ;     {:x 2 :foo 999}]


(let [data [{:x 1 :foo 42}
            {:x 1 :bar 43}
            {:x 2 :foo 999}]]
  (->> data
       (group-by :x)
       (map #(reduce into %))))

👍 1

@U04V4KLKC nice one. Thank you.