Re: [ANN] Clojure infrastructure SSL
Hello, Op vrijdag 21 april 2017 23:08:22 UTC+2 schreef Alex Miller: > > The following bits of Clojure infrastructure are now https-only and > redirect all traffic from http to https: > > https://build.clojure.org - Jenkins > https://dev.clojure.org/jira - JIRA > https://dev.clojure.org - Confluence > > Let me know if you see anything amiss. > > Since you're going https-only you should also make your cookies secure as well as set HTTP Strict Transport Security headers. Kr, Jo -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: How do I access components of a system map
Hey Collin, Op zondag 15 maart 2015 17:26:10 UTC+1 schreef Colin Yates: > > > How do the worker fns actually get called - the dispatching is up to > you - I tend to have a bus (or channel) which is the glue underneath > the gateway. > > For example, I might have: > - a command bus which needs a command registry > - a number of handlers which each handle a command > > I might have: > - a CommandRegistry component which exposes the actual registry > - a CommandOneHandler component which depends on the registry and > registers command-one-handler as the handler of CommandOne. It might > actually register a (partial command-one-handler collab-1 collab-2 > etc.) > - a CommandDispatcher component which takes the command registry, > listens to commands and then dispatches to the correct handler > I have like exactly this. But one problem i have that you create a circular dependency between your Registry & Handlers which causes a StackOverflow when trying to print the Registry from the repl. Any solutions to that. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Using a dynamic var for my database connection for implicit connections+transactions
Hello, I think you are coming to a point where you might want to consider Stuart Sierra's component library. https://github.com/stuartsierra/component A dynamic var is kind of thread-bounded global state, which is to be avoided. There is a nice talk to go with it https://www.youtube.com/watch?v=13cmHf_kt-Q Kr, Jo Op vrijdag 31 juli 2015 02:44:31 UTC+2 schreef J. Pablo Fernández: Hello Clojurians, I found passing around the database connection to each function that uses it very error prone when you are using transactions as passing the wrong one could mean a query runs outside the transaction when in the source code it is inside the with-db-transaction function. So I ended up defining the db namespace like this: (ns db) (defonce ^:dynamic conn (atom nil)) (defn connect! (reset conn (generate-new-connection))) (defn run-query [query] (run-query query @conn) [query conn] (run-the-query-in-connection query conn)) This is pseudo-code of course, simplified to highlight the part that I'm most unfamiliar with: (defonce ^:dynamic conn (atom nil)) The reason why it's an atom is so that connect! can *set* it and the reason why it's a dynamic var is so I can do this: (jdbc/with-db-transaction [db-connection-with-transaction @db/conn] (binding [db/conn (atom db-connection-with-transaction)] (db/run-query SELECT *)) and the query will be implicitly run inside the transaction. Does it make sense? Is this wrong? will it fail in unexpected ways? Is there a better way? Thanks. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: java method overloading and clojure interop
Op woensdag 8 juli 2015 05:20:51 UTC+2 schreef Herwig Hochleitner: The way I would do it: Define multiply as a function calling (.multiply amount ^Number x), for higher order usage, and then add an :inline function to its metadata, which returns `(.multiply ~amount ~x). That acts as a compiler macro, which inlines the call to .multiply, that way, its parameter type can be assigned via local type inferrence (which clojure does). See http://www.bytopia.org/2014/07/07/inline-functions-in-clojure/#sec-3 Beware, that inline functions aren't public API and subject to change. One more question. What does :inline-arities exactly do? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: java method overloading and clojure interop
Herwig Hochleitner schreef op 2015-07-08 05:20: 2015-07-07 15:04 GMT+02:00 Jo Geraerts j...@umask.net [1]: * multiply(long x) * multiply(double x) * multiply(Number x) In clojure i want to do something like (defn multiply[^MonetaryAmount amount multiplicant] (.multiply amount multiplicant)) Function parameters in Clojure, are generally passed as a java.lang.Object, so numbers are boxed by default. Clojure does have infrastructure to pass primitive numbers, see invokePrim here: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/IFn.java#L97 [2] see also http://clojure.org/java_interop#Java [3] Interop-Support for Java Primitives however, this requires a specific type hint on the multiply fn, so normally that means separate multiply-double and multiply-long fns. The way I would do it: Define multiply as a function calling (.multiply amount ^Number x), for higher order usage, and then add an :inline function to its metadata, which returns `(.multiply ~amount ~x). That acts as a compiler macro, which inlines the call to .multiply, that way, its parameter type can be assigned via local type inferrence (which clojure does). See http://www.bytopia.org/2014/07/07/inline-functions-in-clojure/#sec-3 [4] Beware, that inline functions aren't public API and subject to change. This is enlightening. I found such constructs in clojure's core.clj cause there similar things should happen for certain functions, but i couldn't fully grasp what was going on. In core.clj also quite some dispatching happens to clojure.lang.RT which i figured was part of the :inline setup. Thank you for the explanation. Kr, Jo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: http-kit and context root?
I think you don't.
But you can make a small piece of middleware that dispatches to a different
handler based on the 'context root'. You can also strip off the context
root as u dispatch the request to the correct handler.
I'm doing something similar with virtual hosts.
(ns net.umask.imageresizer.vhost)
(defn vhost-handler [vhosts]
(fn [request]
(let [hostname (:server-name request)
handler (get-in vhosts [hostname :handler])]
(if-not (nil? handler)
(handler request)
{:status 404
:body vhost config not found}
Hope you can work with this.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
java method overloading and clojure interop
Hello, I'm trying to create a small wrapper for the java money api. The api uses method overloading. For example: https://github.com/JavaMoney/jsr354-api/blob/master/src/main/java/javax/money/MonetaryAmount.java has methods * multiply(long x) * multiply(double x) * multiply(Number x) In clojure i want to do something like (defn multiply[^MonetaryAmount amount multiplicant] (.multiply amount multiplicant)) Ofcourse i get reflection warnings. I can add typehints to the multiplicant to 1 of the 3 versions above, but obviously that doesnt allow me to expose the other versions. What would be the most idiomatic choice to handle this? Things i considered myself are: * multimethods: they can only work on the boxed versions of long/double * have different function names like multiplyLong multiplyDouble but that doesnt sound right either. Kr, Jo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: zipmap different ordering in 1.7
Op maandag 6 juli 2015 10:42:43 UTC+2 schreef dmic...@gmail.com: The semantics of a set doesn't guarantee an order either (even though it's implementation might), I'd sort over the keys and use the resulting collection as hash-map key so you are independent of any clojure-intrinsic behavior I only cared if those keys were present and i used the keys function as a dispatch function and used the ordering it returned. Now suddenly the ordering changed in 1.7 and my program broke, but the exact ordering didn't really matter. Anyhow it is fixed now and my unit tests run happily again. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: zipmap different ordering in 1.7
That was exactly what i'm doing to fix it. I didnt care about the actual
order but assumed the order was going to stay the same. Bad assumption.
Thank you all for the feedback.
Op donderdag 2 juli 2015 03:06:00 UTC+2 schreef Fluid Dynamics:
On Wednesday, July 1, 2015 at 3:54:03 PM UTC-4, Jo Geraerts wrote:
Hey,
I when i tried to run my program with the shiny new 1.7, it broke. I have
traced it down to the fact that zipmap (
https://github.com/clojure/clojure/blame/master/src/clj/clojure/core.clj#L2940)
does returns the keys in a different order than i'm used to.
e.g clojure 1.6:
nREPL server started on port 52315 on host 127.0.0.1 - nrepl://
127.0.0.1:52315
REPL-y 0.3.5, nREPL 0.2.7
Clojure 1.6.0
Java HotSpot(TM) 64-Bit Server VM 1.8.0_40-b26
Docs: (doc function-name-here)
(find-doc part-of-name-here)
Source: (source function-name-here)
Javadoc: (javadoc java-object-or-class-here)
Exit: Control+D or (exit) or (quit)
Results: Stored in vars *1, *2, *3, an exception in *e
user= (zipmap [:a :b] [:c :d])
{:b :d, :a :c}
Whereas clojure 1.7 does:
nREPL server started on port 52193 on host 127.0.0.1 - nrepl://
127.0.0.1:52193
REPL-y 0.3.5, nREPL 0.2.7
Clojure 1.7.0
Java HotSpot(TM) 64-Bit Server VM 1.8.0_40-b26
Docs: (doc function-name-here)
(find-doc part-of-name-here)
Source: (source function-name-here)
Javadoc: (javadoc java-object-or-class-here)
Exit: Control+D or (exit) or (quit)
Results: Stored in vars *1, *2, *3, an exception in *e
user= (zipmap [:a :b] [:c :d])
{:a :c, :b :d}
As i'm using the keys function later on these values as a multimethod
dispatch function, things break.
It's rather trivial to change my program with the new ordering, but i was
wondering if the ordering of the keys of the returned map is part of the
contract.
When one would need more context about the actual code, the usage of the
zipmap can be found here at
https://github.com/jgeraerts/imageresizer/blob/master/src/net/umask/imageresizer/urlparser.clj#L19
.
The multimethod dispatch
https://github.com/jgeraerts/imageresizer/blob/master/src/net/umask/imageresizer/resizer.clj#L15
The tests break with these kinds of exceptions:
ERROR in (test-resizer) (MultiFn.java:156)
expected: (= [200 [200 200]] (run-resizer size/200x200/rose-cmyk.tiff))
20:31:05.179 [main] WARN net.umask.imageresizer.resizer - image not
found for uri size/200x200/nonexisting
actual: java.lang.IllegalArgumentException: No method in multimethod
'scale' for dispatch value: (:width :height)
at clojure.lang.MultiFn.getFn (MultiFn.java:156)
clojure.lang.MultiFn.invoke (MultiFn.java:233)
I'm glad to hear your feedback.
Key order for (non-sorted) maps is not guaranteed, but there is an easy
fix: pour the result of keys into a set, e.g. (into #{} (keys my-map)), and
use #{:width :height} e.g. as your dispatch values. Then it will work
independently of the vagaries of key ordering.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
zipmap different ordering in 1.7
Hey,
I when i tried to run my program with the shiny new 1.7, it broke. I have
traced it down to the fact that zipmap (
https://github.com/clojure/clojure/blame/master/src/clj/clojure/core.clj#L2940)
does returns the keys in a different order than i'm used to.
e.g clojure 1.6:
nREPL server started on port 52315 on host 127.0.0.1 -
nrepl://127.0.0.1:52315
REPL-y 0.3.5, nREPL 0.2.7
Clojure 1.6.0
Java HotSpot(TM) 64-Bit Server VM 1.8.0_40-b26
Docs: (doc function-name-here)
(find-doc part-of-name-here)
Source: (source function-name-here)
Javadoc: (javadoc java-object-or-class-here)
Exit: Control+D or (exit) or (quit)
Results: Stored in vars *1, *2, *3, an exception in *e
user= (zipmap [:a :b] [:c :d])
{:b :d, :a :c}
Whereas clojure 1.7 does:
nREPL server started on port 52193 on host 127.0.0.1 -
nrepl://127.0.0.1:52193
REPL-y 0.3.5, nREPL 0.2.7
Clojure 1.7.0
Java HotSpot(TM) 64-Bit Server VM 1.8.0_40-b26
Docs: (doc function-name-here)
(find-doc part-of-name-here)
Source: (source function-name-here)
Javadoc: (javadoc java-object-or-class-here)
Exit: Control+D or (exit) or (quit)
Results: Stored in vars *1, *2, *3, an exception in *e
user= (zipmap [:a :b] [:c :d])
{:a :c, :b :d}
As i'm using the keys function later on these values as a multimethod
dispatch function, things break.
It's rather trivial to change my program with the new ordering, but i was
wondering if the ordering of the keys of the returned map is part of the
contract.
When one would need more context about the actual code, the usage of the
zipmap can be found here at
https://github.com/jgeraerts/imageresizer/blob/master/src/net/umask/imageresizer/urlparser.clj#L19
.
The multimethod dispatch
https://github.com/jgeraerts/imageresizer/blob/master/src/net/umask/imageresizer/resizer.clj#L15
The tests break with these kinds of exceptions:
ERROR in (test-resizer) (MultiFn.java:156)
expected: (= [200 [200 200]] (run-resizer size/200x200/rose-cmyk.tiff))
20:31:05.179 [main] WARN net.umask.imageresizer.resizer - image not found
for uri size/200x200/nonexisting
actual: java.lang.IllegalArgumentException: No method in multimethod
'scale' for dispatch value: (:width :height)
at clojure.lang.MultiFn.getFn (MultiFn.java:156)
clojure.lang.MultiFn.invoke (MultiFn.java:233)
I'm glad to hear your feedback.
Kr,
Jo
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
