When you map a function over something what is returned? is it a collection of return data?

A lazy sequence

But yes a collection of that function applied over the data, just not realized until you ask for it.

I see. It worked the way I thought it should. I was trying to then map println which resulted in nil. Instead I had to apply println.

Did you do that in the repl?

I'm using Calva and it's truncating the results in the REPL for some reason.

repl will realize your map function for you

It would have worked if I had just typed it into the REPL

Would have been more obvious.

Gotcha

Trying a simple project in Clojure. I've literally been reading about it for years, but never done anything with it.

Are you enjoying it so far?

So far so good. There are definitely some nice libraries to make what I'm trying to do easy.

That’s good! Calva looks like a neat tool I will have to check it out sometime.

I had to rework my approach so it would be REPL friendly. I was nesting my functions in a way that made it difficult to work with at first.

Ah yeah, thread macros ->> -> make nesting readable

Yep I was trying to do too much in a given function too.

I haven't used the thread macros yet.

working with thread macros lets you think about composability of your code

I'm looking to store a map in an atom, then use clojure.data.diff to see when it changes. If it changes, I want to update the value in the atom, then trigger an action.

Does this sound reasonable? Is there a "best practice" for this type of thing?

@scott.archer You can add a watcher to an atom so that function is called when it changes.

I don't really mean "monitor" the atom, but call a function to get the differences.

It sounds like a watcher could work to trigger the event based only on the change. Would that be a good way to go about this?

https://clojuredocs.org/clojure.core/add-watch

Then you could check the old and new state and see if it changed in a way that you need to trigger your event.

But if your "check" also updates the value in the atom, you might get into a loop 🙂

I'm not really sure what you mean by "If it changes, I want to update the value in the atom"

I'm scraping a website looking for product changes, then I want to generate a text message if something has changed.

It's not a complex use case, just using it to learn.

Yeah, I think this would work for you then. The watcher function would check whether old state = new state and, if not, generate the message.

Yep it's worth trying. Thanks for the help. The last time I tried to get started on a clojure project, I got some stuff working, but it wasn't done the clojure way and it didn't feel any different than java.

I'm trying to do a better job working through this.

Getting into the functional mindset is (at least) half of the battle if you're coming from Java, I think.

It is and I think writing code that decomposes well so that the REPL is useful seems really important too.

Aye, the REPL is a game-changer, once you get into the flow with it (see Stu Halloway's talks "REPL-Driven Development" and "Running With Scissors").

Key advice: never type directly into a REPL. Type into a (source) file instead, and evaluate each form as you type it. You can put REPL experiments inside a (comment ..) form to stop them affecting the source file when it is loaded. And keep them there as notes on what worked (and perhaps what didn't).

I actually saw the (comment trick today and I'm using it. It works great!

@seancorfield do you use Calva by any chance?

I have used it occasionally. Mostly I use Atom and Chlorine.

It keeps truncating my results for some reason I thought you might be using it.

in the REPL.

Ah ok.

It's fairly standard in editor integrations to prevent crashing/locking up when you accidentally print very large data structures.

If it shows ... in the output, it may be clickable to expand the data some more.

I'll check it out. Thanks!

There's a #calva-dev channel in case you need to ask detailed Qs about it.

This might be relevant (from that channel): https://clojurians.slack.com/archives/CBE668G4R/p1549729716098300

Hi there, I'm trying to update the specific entry in a map upon predicate and at the end I get a map with only the updated entry (the rest of entries eventually turn into nil):

(update data :sms (fn [coll]
                    (map #(when (= id (:id %))
                            (conj % {:sent? true}))
                         coll)))

use if, not when

is sms a map?

yup, it is

oops, yeah, got it! thank you!

You can use (map #(merge % (when (= 1 (:id %)) {:sent? true})) [{:sent? false :id 2} {:sent? false :id 1}])

If you don’t want to use if

you can in this case also use assoc instead of conj, personally conj is confusing for me in this instance

but im also a beginner 😄

dunno, conj works fine in my mental model right now xD

Thank you Alex!

np 👍

argh, time---

Observe:

(let [given-t "1549913529.537"
          t 1549913529537]
      (java.util.Date. t))

I derived t by multiplying by 1000, or more to the point, by editing out the "s and the . :face_with_rolling_eyes:

of course I would rather not do that

But this is no good:

(let [given-t "1549913529.537"
          t (Double. given-t)]
      (java.util.Date. t))

nor is this:

(let [given-t "1549913529.537"
          t (Integer. (* 1000 (Double. given-t)))]
      (java.util.Date. t))

I think that integer might be too big for Integer?

(-> "1549913529.537" (str/replace "." "") (Long/parseLong) (java.util.Date.))

I've just constructed my first ever BigInteger.... which java.util.Date has also never heard of

oh a Long is not a Double

I sort of thought Long, Double, and Float were all the same name for the same idea

not sure what the constraints of the initial string are, but if its precision is always 3 you can just delete the decimal to multiply by 1000 and then parse it?

I think that is the case --- this is super-prototypey so it's okay if it explodes later

thanks @dpsutton !

@mathpunk I'm sure BigInteger is fine here, but I can think of very few cases I'd use Integer over Long

similar with Float vs. Double

prefer the 64 bit types

Long is a big 64-bit integer, and Double is a 64-bit float?

yes!

mmmmk

(in Clojure, longs can store values between -(2^63 + 1) — 2^63, so they are signed)

[-2^63, 2^63-1] inclusive (sorry can't resist pointing out off by one bugs)

i remember hearing a neat thing. The minimum value in ranges like this is not representable as a literal

ie if the range is [-16, 15] you can't represent -16 as a literal of that type. you get type promoted

You mean, in Java programs?

yes. but i think its common across most languages due to the way things are parsed

presumably the same thing in clojure

I know of rust that did strange things with non-inclusive ranges for all byte values

like if you said 0…256 non-inclusive

its because -X is parsed as unary operator negation on X. and the minimum is usually larger in absolute value terms than the maximum. so in the range [-16, 15] -16 is (negate 16) and the 16 there is too large for your type so you get type promotion

user=> Long/MIN_VALUE
-9223372036854775808
user=> (type -9223372036854775808)
java.lang.Long

and (type -9223372036854775809)?

First time I have seen Slack's animation for deleting a message. Cool!

java does not have this problem apparently. (type (- 9223372036854775808)) is BigInt

perhaps this was only in C# or C++?

user=> (type (unchecked-subtract 0 9223372036854775808))
clojure.lang.BigInt

of course this is because 9223372036854775808 is already bigint

yes that number is too large for Long. There are some languages that don't read -9223372036854775808 (a valid Long) as this number but as negating 9223372036854775808 (a positive number) which is too large for longs

and java does have this defect (it seems)

HelloWorld.java:5: error: integer number too large: -9223372036854775808
        long x = -9223372036854775808;
                  ^
1 error

public class HelloWorld{

     public static void main(String []args){
        System.out.println("Hello World");
        long x = -9223372036854775808;
     }
}

clojure has a better long parser than java

another way clojure is better than java :D

- is a unary operator in Java right

I assumed this would make its way into clojure

so, it first parses 9223372036854775808 as long, but that isn’t a long

yeah - and since clojure doesn't need to use java for parsing, I'm not surprised that bug is fixed

i just thought that was really cool when i learned it. a value is not expressable as a literal

yeah, but it makes sense if you think about how that would be structured in a grammar

class Main {
  public static void main(String[] args) {
    System.out.println(- - 6);
  }
}

it looks like the compiler uses a regex to match integers. but it looks like it always returns a bigInteger. so i'm a little confused

ah no, it reads everything into biginteger and then tries to go down to longs if possible

I have never seen this time format before --- 0211/133208.940471. That's MMDD/??????.???

star date?

hahah

gotta be it

133208 is more than the number of seconds in one day, so not sure what that is intended to be.

Where did you find that?

this is coming out of a ChromeDriver log.... that precision is quite a claim

maybe it's not a timestamp, but heck if I know what it is

thanks, @andy.fingerhut, i was hoping someone would have recognition on whether this was quite likely ridiculous

Seconds since the process started, maybe?

maybe.... I think I'm going to put this down and back away

I have many other events of interest with sane timestamps

Logging tends to proliferate time representations.

s/time representations.//

maybe js/window.performance.now()?

I guess you can get higher resolution timestamps out of there