This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-01-01
Channels
- # beginners (2)
- # cider (20)
- # cljsjs (3)
- # clojure (86)
- # clojure-italy (2)
- # clojure-spec (7)
- # clojure-uk (3)
- # clojurescript (8)
- # defnpodcast (3)
- # emacs (10)
- # figwheel (1)
- # hoplon (9)
- # immutant (4)
- # keechma (2)
- # luminus (11)
- # off-topic (13)
- # re-frame (6)
- # reagent (3)
- # ring (1)
- # specter (5)
- # sql (2)
- # unrepl (127)
any immutant users here? does immutant have a proxyname configuration similar to tomcat, for when it's run behind a proxy?
are you aware that compojure is a router?
@noisesmith i want to get a json document if the user goes to http://www.mysite.com/mystuff
right, my point is that compojure is a library for routing requests to request handling functions
there's ring middleware for returning json, compojure is used with ring
@noisesmith thank you
that library I just linked to has a function called wrap-json-response
, if you call that and pass your handler as an argument, it returns a new handler that returns json (edit, fixed function name)
your handler is the function that processes a request
(wrap-json-respone my-handler) returns a new function, it will have json as its body
it is not possible to return a json without diving into the abstract mechanisms of handlers?
you can create a json string, if you return a string that's what ring returns
i am sorry that i am too dumb to understand this concept of handlers in these circumstancesw
you have a handler, you can't serve requests without a handler
if you call wrap-json-response with your current handler as an argument, it returns a new handler
use that one
that's it
that's the whole thing
or, you can use cheshire/generate-string, if you handler function returns a string, ring will give that string to the client as the request body, tha's another option but it's more complicated
somewhere in your code you start a server, you pass an argument to the server, that argument is a handler
this has nothing to do with reagent
I've told you two different ways to do this already
you either call cheshire/generate-string on your data, or you wrap the function returning the data in wrap-json-request
right, good luck
(defn json-response [data & [status]] {:status (or status 200) :headers {"Content-Type" "application/json"} :body (json/generate-string data)})
that used anothwer library, i'll try the cheshire one, that seems like something that i could understand
you don't need that
all you need is the json/generate-string
right
@mjo324_56 It sounds like you're fairly new to Clojure so you might find #beginners to be a better venue for asking these sorts of questions? There are over 11,000 people in this channel but in #beginners folks have opted in to helping folks who are new to Clojure and/or struggling with basic concepts.
Hi there, I have a custom Cheshire encoder being added like so:
(add-encoder ValidationError
(fn [v jsonGenerator] ...))
ValidationError
is a Schema class defined with deftype
and I have it imported like so:
(ns foo.setup
(:import [schema.utils ValidationError]))
The code works well when it's being executed with leiningen in my :dev profile, but it fails to compile to a jar file. Here's my uberjar configuration:
:uberjar {:aot :all
:main foo.main}}
The deftype
doc has a few considerations about AOT compiling and how it dynamically generates bytecode for the class, could it be related somehow? I seriously have no idea. By the way, the foo.main namespace is tagged with the :gen-class directive.
you are importing the generated class, but not loading the clojure code that generates the class
the best thing to do is to not treat deftypes like java classes that you use via import
deftype (if I recall, I generally use defrecord) generates a factory function something like ->TypeName that takes the same arguments as the constructor
use that instead, and you won't end up using the class without first loading the clojure code to generate the class
in general though, you most likely shouldn't be using deftype at all, and you shouldn't be aot compiling
that's a great tip! thanks @hiredman I required the namespace and it worked. but I will try this another approach you mentioned, seems less error prone
most of the time i use defrecord just like you mentioned, i think there's something advertising against deftype in the book i read
most projects don't need to be aot compiled. aot compilation is a process with edge cases and unintended consequences, you can end up with weird issues related to types and type visibility and types with the same name that are not the same type. better to leave it out
@hiredman thanks, i understand it now! and by removing :aot :all from by :uberjar configuration leiningen used aot compilation only on my main namespace.
any namespaces loaded while aot compiling your main namespace will also be aot compiled (and so on)
i thought it had compiled only the main one because the logs showed that only the main one was being compiled, when i use :aot :all i get compiling logs for every namespace in the project
if I recall the message being printed out is coming from lein when it calls the clojure compiler to compile a given namespace
but the compiling of transitive dependencies is something the clojure compiler does and lein doesn't have visibility into it
oh i get it now, but is it possible to build an uberjar through leiningen without aot compilation at all? this might be a silly question, but i also couldn't find any docs on how to build the uberjar and turning off this setting. and when I remove the :aot directive it still takes the main namespace for aot compilation according to its logs, in your post you described the steps by loading the project directly from the clojure.jar.
I'm hoping to clarify my understanding of the JVM wrt to why we chunk seqs at 32 elements. Native x86-64 has 64 byte data buses, so with 64 bit types that means 8 are read from cache at once (assuming no misses). Clojure's built-in data structures box elements, and I have no idea how much additional memory that takes, so we're chunking at >4x a native cache line. However, I assume the JVM works differently than native. Can anyone explain?
I'd say the chunk seq size is orthogonal to CPU architectural concerns...
A seq can contain e.g. 32 very-large arbitary objects. Maybe just a handful of those elements would surpass already what a CPU cache can retain.
So the 32
is more like a sensible general-purpose default - a "not too big not too small" number.