This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-03-01
Channels
- # announcements (4)
- # aws (1)
- # beginners (172)
- # cider (16)
- # cljdoc (63)
- # cljsrn (7)
- # clojure (150)
- # clojure-dev (8)
- # clojure-europe (26)
- # clojure-gamedev (6)
- # clojure-greece (23)
- # clojure-nl (4)
- # clojure-spec (10)
- # clojure-uk (101)
- # clojurescript (40)
- # community-development (5)
- # cursive (19)
- # datomic (54)
- # emacs (39)
- # figwheel-main (5)
- # fulcro (4)
- # graphql (16)
- # immutant (5)
- # jobs (8)
- # jobs-rus (1)
- # leiningen (1)
- # off-topic (31)
- # planck (1)
- # re-frame (7)
- # reagent (8)
- # reitit (6)
- # remote-jobs (4)
- # shadow-cljs (11)
- # spacemacs (18)
- # specter (2)
- # sql (58)
- # vim (2)
- # yada (5)
from the docstring of http://clojuredocs.org/clojure.core/case > Unlike cond and condp, case does a constant-time dispatch, the clauses are not considered sequentially. can someone explain in plain English what that means?
it jumps to the condition, rather than linearly checking the conditions one at a time
it compiles to effectively (or maybe literally) a hash-map lookup on the dispatch value
the jvm has two bytecodes supporting "switch" - one is a linear series of checks, the other is effectively a constant time jump table keyed off of hashcode
Clojure's case does a ridiculous amount of work to use the latter
That got me scrolling through my phone to find the case source, which stirred up a couple of questions/comments:
1.) some?, if-some, when-someā do people use these often? I donāt, personally. Anyone have insight as to why they made it into core? I think I saw an added in 1.6, which makes me guess at it being related to transducers? Maybe Iām off 0.2 and that was the time of reducers? Either way, curious on the history.
2.) mod
ās docstring has a line āTruncates toward negative infinity.ā Could someone explain that to me, and perhaps provide an example of why itās important to know?
I typically avoid calling modulo/remainder or division operations on negative numbers, to avoid having to know, and because applications I have written didn't need such operations on negative numbers. But this page on the divide and modulo behavior in various flavors of C/C++ might answer some of your question: http://www.microhowto.info/howto/round_towards_minus_infinity_when_dividing_integers_in_c_or_c++.html
if I remember correctly the reason why they were added was because core.async
channels impose nil
as the end-of-stream sentinel
> I prefer if-some
and when-some
over if-let
and when-let
almost every time
yes I've met other clj programmers following that style
It might boil down to Java-like vs. Lisp-like boolean semantics (in Java there's no 'truthiness' - just true and false can be used in conditions). Some people prefer Java-like
@archibald.pontier_clo Iād take a look at https://stanfordnlp.github.io/CoreNLP/
Thank you! I actually know about corenlp but it doesn't have LDA nor RAKE. I know Spark has LDA but I'd like to avoid to massive overhead Spark creates... Worst case I'll go an implement it...
I saw something about LDA mentioned in the JavaDoc of CoreNLP, thatās why I thought it may be relevant, but maybe not.
I'm trying to find any previous implementations (or some library I could steal ideas from) for having a pipeline which basically all functions inside this pipeline depends on the previous step and also have side-effects. Goes something like fetch source -> build -> report status
but with a bit more steps in-between. Any previous art or thoughts on the subject are welcome! I've looked at some implementations using async/pipeline
but feels like over-engineering for my case, no need for it to be async
If I understand your requirement, Iāve done similar before simply using thread-first, passing a context as I go:
(-> initial-context fetch-data parse-data categorise send)
Ah, basically build up some context map that contains all the parts that are needed? Actually not a bad idea
Yep exactly. Youāre welcome š
I couldnāt find clojure.java.jdbc
channel, so asking here: At the time of table creation, if I provide [:age :int :default 18]
then jdbc throws error, but it accepts "18"
, which is logically incorrect. How to handle this?
the channel for jdbc is #sql
I'm making myself crazy with this... I'm using clojure.data.json to create a json string. The string I want to create looks like this: {"query": {"field": {"text": "123",
the json/write-str I use looks like this: (json/write-str {:query {:field {:text "123", :title "ABC}}})
is the " after C missing in your original?
user=> ((fn [& {:as m}]) 1)
Execution error (IllegalArgumentException) at user$eval1467$fn__1469/doInvoke (REPL:1).
No value supplied for key: 1
user=>
egret.run=> (j/write-str {:query {:text "123", :title "ABC"}})
"{\"query\":{\"text\":\"123\",\"title\":\"ABC\"}}"
egret.run=> (println *1)
{"query":{"text":"123","title":"ABC"}}
nil
egret.run=> (j/write-str {:query {:text "123", :title "ABC"}} :foo)
IllegalArgumentException No value supplied for key: :foo clojure.lang.PersistentHashMap.create (PersistentHashMap.java:77)
extra arg, yeah
It seems to me that query is matched by field, field is matched by the object containing text and title. Everything has a key value. The original JSON validates. It just doesn't work with json/write-str. Very odd.
you are providing the wrong number of args to write-str
it's how you make that error message happen
what does this mean?
you have supplied the error message, which says what the error is, but the stacktrace will tell you where the error is actually happening
IllegalArgumentException no value supplied for key: then: clojure.lang.PersistentArrayMap.createAsIfByAssoc (PersistentArrayMap.java:79)
*e
will contain the full trace
that's not a stack trace, it's a message
*e contains the trace
Here's the whole thing: at [clojure.lang.PersistentArrayMap createAsIfByAssoc "PersistentArrayMap.java" 79]}] :trace [[clojure.lang.PersistentArrayMap createAsIfByAssoc "PersistentArrayMap.java" 79] [clojure.core$array_map invokeStatic "core.clj" 4256] [clojure.core$array_map doInvoke "core.clj" 4249] [clojure.lang.RestFn applyTo "RestFn.java" 137] [clojure.core$apply invokeStatic "core.clj" 646] [clojure.core$apply invoke "core.clj" 641] [clojurewerkz.elastisch.arguments$GT_opts invokeStatic "arguments.clj" 9] [clojurewerkz.elastisch.arguments$GT_opts invoke "arguments.clj" 3] [clojurewerkz.elastisch.rest.percolation$register_query invokeStatic "percolation.clj" 30] [clojurewerkz.elastisch.rest.percolation$register_query doInvoke "percolation.clj" 25] [clojure.lang.RestFn invoke "RestFn.java" 467] [esearch.handler$get_register_search invokeStatic "handler.clj" 124] [esearch.handler$get_register_search invoke "handler.clj" 119] [mysql.core$eval11790 invokeStatic "form-init1224899402989498950.clj" 1] [mysql.core$eval11790 invoke "form-init1224899402989498950.clj" 1] [clojure.lang.Compiler eval "Compiler.java" 6927] [clojure.lang.Compiler eval "Compiler.java" 6890] [clojure.core$eval invokeStatic "core.clj" 3105] [clojure.core$eval invoke "core.clj" 3101] [clojure.main$repl$read_eval_print__7408$fn__7411 invoke "main.clj" 240] [clojure.main$repl$read_eval_print__7408 invoke "main.clj" 240] [clojure.main$repl$fn__7417 invoke "main.clj" 258] [clojure.main$repl invokeStatic "main.clj" 258] [clojure.main$repl doInvoke "main.clj" 174] [clojure.lang.RestFn invoke "RestFn.java" 1523] [nrepl.middleware.interruptible_eval$evaluate invokeStatic "interruptible_eval.clj" 79] [nrepl.middleware.interruptible_eval$evaluate invoke "interruptible_eval.clj" 55] [nrepl.middleware.interruptible_eval$interruptible_eval$fn__764$fn__768 invoke "interruptible_eval.clj" 142] [clojure.lang.AFn run "AFn.java" 22] [nrepl.middleware.session$session_exec$main_loop__865$fn__867 invoke "session.clj" 171] [nrepl.middleware.session$session_exec$main_loop__865 invoke "session.clj" 170] [clojure.lang.AFn run "AFn.java" 22] [java.lang.Thread run "Thread.java" 748]]}
so this problem has nothing to do with data.json
Probably not, but I presume that people have built JSON like this before with data.json..
write-str has nothing to do with that error
if that were true, write-str would be in the stack trace
I'd think so. It could be when it gets passed to ElasticSearch. Maybe something goes wrong there.
what does ->opts do and how is it being called?
You are most likely realizing a lazy sequence that was created somewhere else.
I think one problem might be that the values for title and text aren't simple like "123". They are 1024 character strings containing search terms that may or may not have foreign characters in them.
And the error is in what you passed to the code that created that lazy sequence.
Is -Dclojure.compile.warn-on-reflection
property supposed to work? If so, what effect should it have? I supposed it will set the reflection warning dynvar for all namespaces by default, but it doesn't seem to.
-Dclojure.compile.warn-on-reflection=true
should work.
$ clj -J-Dclojure.compile.warn-on-reflection=true
Clojure 1.10.0
(cmd)user=> *warn-on-reflection*
false
Ah, yes, that's it.
So its not controlling the value of *warn-on-reflection*
, it is just looked up as well by the compiler when compiling to decide if it should emit or not the warnings.
@U0K064KQV So it seems like I can't use it to check all namespaces for warnings. Sad.
clojure -J-Dclojure.compile.warn-on-reflection=true -e "(compile 'entry.point)"
should do it @U06PNK4HG?
(you'll need a classes
folder for it to compile into -- or else add a binding
call around the compile
for *compile-path*
)
@nkraft have you shown us exactly what code is on line 124 of esearch.handler
?
this is Elastisch, submitting a query to the ElasticSearch percolator: (pcl/register-query conn index rowid json) That's on line 124. 'json' is the output of data.json. index and rowid are strings.
Which version of Elastisch are you using? The stack trace does not match the latest version.
It looks to me like register-query
expects kw-args style arguments, i.e., named arguments, not a single JSON map.
Yes. Then you're calling it per the 3.x API, instead of the 2.x API.
& args
is expected to be unrolled keyword args, not a map.
In Elastisch 3.x, this call changed to accept a single hash map of opts
So you either need to change your call or update to 3.x.
Well, updating Elastisch to 3.0.0 didn't fix it. Same problem. I'll try keyword args rather than the JSON.
It should be a hash map not a JSON string.
Here's the commit that changed the kwargs to option hash maps across the whole of Elastisch in May 2016 https://github.com/clojurewerkz/elastisch/commit/f3ea4289b9a9cb37a491f0a3a2df4ec6388d27ae#diff-62e296465e10f4b062c0484560be3e12
So (pcl/register-query conn index rowid {:query {:text "123" :title "ABC"}})
for 3.x or (pcl/register-query conn index rowid :query {:text "123" :title "ABC"})
for 2.x.
Thanks that's very helpful. OF course our ElasticSearch servers just went down so I'll have to test later. My localhost ES doesn't have enough data for what I'm doing.
[ANN] Cognitect Labs' aws-api 0.8.273 is now available: https://groups.google.com/forum/#!topic/clojure/PgnJxiam_qk
this is pure gush but i just got my first full-time clojure gig and am incredibly excited. thanks for being such a thoughtful, curious community
@seancorfield I have to thank you. That one post about 3.x vs. 2.x was the key. It's fixed now.
@nkraft This is a good example of why Rich is such a strong advocate of accretion, relaxation, and fixation -- rather than breakage. Admittedly, Elastisch did a major version change to signal "potential breakage" per so-called Semantic Versioning, but it really does show that you never really know whether updating to a new major version is "safe" or not -- and changes like this make it hard to trust the docs, unless they are also fully versioned for every new release.
(That said, my "flagship" Clojure project, clojure.java.jdbc
also went through two rounds of API breakage -- to move to a more idiomatic API -- and, in fact, it was precisely the same changes that Elastisch made, switching from keyword arguments to an options hash map!)
That's true. I use your java.jdbc as well. Many times reading code is all that really works. Still, in my job I'm often trying to hack together something needed in a matter of hours, and I rely on docs to get things started probably more often than I should.
I don't think I've broken the java.jdbc
API in about two and a half years now, but 2016 and 2013 were bumpy years for the API š
(unfortunately there are still a lot of books and tutorials out there containing 0.2.x examples which haven't worked since 2013 š )
I saw the following spec in some code and I was wondering what the or
was supposed to do.
(s/def ::my-string string?)
(s/def ::my-int integer?)
(s/def ::my-spec (s/keys :req-un [(or ::my-string ::my-int)]))
I generated a few samples using clojure.spec.gen.alpha/generate
and saw that it does not yield the same results in Clojure 1.9 and 1.10.
In 1.9, it always returns maps with both keys (which looks like a bug :thinking_face:)
In 1.10, it returns maps with either ::my-string
key, ::my-int
or both (which looks like a normal or
)
What is the expected behavior?well first, the or here is not xor, so the generated examples in 1.9 are still "correct". in 1.10, it was updated to include either or potentially both.
so, expected behavior is its current behavior
So in 1.9, it generates only one case (both keys) of the 3 valid ones (first key, second key, both keys)
@seancorfield I recently learned about clojure.jdbc. Are you aware of it and its criticisms of java.jdbc? https://funcool.github.io/clojure.jdbc/latest/#why-another-jdbc-wrapper
Are you aware that it started life by copying code from clojure.java.jdbc
and ripping out the license and copyright? I had to call the guy out on the main Clojure Google Group for that.
I find it odd and annoying that the clojure.jdbc docs call clojure.java.jdbc java.jdbc, and that the project picked a name such that many discussions about using jdbc with clojure now look ambiguous
I haven't used it at all though
Are you aware that it started life by copying code from clojure.java.jdbc
and ripping out the license and copyright? I had to call the guy out on the main Clojure Google Group for that.
Also, it's criticisms are mostly out of date (and will be completely irrelevant when next.jdbc
comes out which I've been working on a for a while). And it hasn't had any code updates in three years now (and only minor doc updates that were two years ago) -- so I'd say it's abandoned at this point.
didnāt know there was this ādramaā associated with it. I just saw someone mentioning it on clojureverse
Somewhere he said: > Currently I have removed all taken code from the clojure.java.jdbc, license problem should be solved. I wonder with what he replaced that code then
I won't comment on that... for legal reasons...
Where it was mentioned on ClojureVerse, I also pointed out that the original code was ripped off, BTW. https://clojureverse.org/t/next-jdbc-early-notes/3480/5 Or is there another thread that mentions it?
(that's the only thread that search finds where it seems to be mentioned)
thats so uncool, not attributing code. Even disregarding the legal implications
derivation is at the heart of open source, but not by copying others work and posing it as your own
I think I saw a mention on Reddit (and also linked to the Google Group thread there about the code being ripped off in the early versions).
yeah, I think it was this one: https://www.reddit.com/r/Clojure/comments/ao8hlb/using_databases_in_clojure_a_lot_of_options/
This was the comment: https://www.reddit.com/r/Clojure/comments/ao8hlb/using_databases_in_clojure_a_lot_of_options/efzpxxj/ and I see 3 days later you reacted on it. I think I missed that.
I try to catch every mention of it I can. As someone who's been doing OSS development for over twenty five years, I'm very sensitive to the issues of licensing and plagiarization š
We're good. I'm just listening to Amanda Palmer's new album so not much is going to dampen my enthusiasm today š
legal issues aside, it's a disrespectful way to engage with a project whose work is leveraged that heavily
this went from technical to legal issues ( but the technical part was never talked about )
or ethical š
As technical people, we'd do well to remember there are ethical and legal aspects to our work a lot of the time... for example http://2018.clojure-conj.org/keynote-speaker-rebecca-parsons/
I often cite ācomputer ethicsā as the most influential course in my masters
University of Twente (Enschede, The Netherlands)
Also had lectures from Johnny SĆøraker? Its such a shame that heās no longer at the uniā¦
yeah probably not, I think he started teaching around 2006. Anyhow, cool to hear that this has been a trait of the UT for so long. I still believe that having a good ethics course is great for a computer scientist.
Small world š
Quite, moreso because the university we went to is one of the smaller of The Netherlands