Re: [ANN] faster-multimethods

I think it would be a good idea to some feedback and more widespread use first. I've started the process with https://dev.clojure.org/jira/browse/CLJ-2234. The other semantic changes need more review. The main performance change to clojure.lang.MultiFn is to replace persistent data structures by

Re: possibly a Clojure question or possibly an AWS question: slow writes to durable-queue

Following Daniel Compton's suggestion, I turned on logging for GC. I don't see it happening more often, but the slow down does seem related to the moment when the app hits the maximum memory allowed. It had been running with 4G, so I increased that to 7G, so it goes longer now before it hits

Re: [ANN] faster-multimethods

why not merge it to clojure.core multimethods? I think it's a valuable work, you can create a patch to make clojure better. See https://clojure.org/community/contributing 2017-10-13 8:13 GMT+08:00 John Alan McDonald : > Beta release (0.1.0) of faster-multimethods,

Re: (resolve (symbol f)) works at the REPL but not in an uberjar

you can use (symbol "denormalize.pull-from-mysql" "f") instead On Thu, Oct 12, 2017 at 6:34 PM wrote: > Nevermind. I found that this works, though I think it is ugly and > inelegant: > > resolved-f (resolve (symbol (str "denormalize.pull-from-mysql/" > f)))

Re: (resolve (symbol f)) works at the REPL but not in an uberjar

Nevermind. I found that this works, though I think it is ugly and inelegant: resolved-f (resolve (symbol (str "denormalize.pull-from-mysql/" f))) On Thursday, October 12, 2017 at 9:27:06 PM UTC-4, lawrence...@gmail.com wrote: > > At the REPL, this works perfectly: > > > (defn

(resolve (symbol f)) works at the REPL but not in an uberjar

At the REPL, this works perfectly: > (defn get-users [] [:susan :kwan]) > > (defn what-is-this-function [f] ((resolve (symbol f > (what-is-this-function "get-users") >[:susan :kwan] In an uberjar this does not work. I read somewhere that the runtime name-space is different than the

Re: possibly a Clojure question or possibly an AWS question: slow writes to durable-queue

Hi! Can you change one of the variables? Specifically can you replicate this on your local machine? If it happens locally then I would focus on something in the JVM eco-system. If you can't replicate it locally then it's possibly AWS specific. It sounds like you're using a t2.large or m4.xlarge.

[ANN] faster-multimethods

Beta release (0.1.0) of faster-multimethods, which brings multimethod lookup overhead to roughly the same cost as protocols, with only modest changes to the Clojure 1.8.0 implementation. It is mostly backwards compatible with Clojure 1.8.0. I would very much appreciate feedback on the semantic

Re: possibly a Clojure question or possibly an AWS question: slow writes to durable-queue

Daniel Compton, good suggestion. I've increased the memory to see if I can postpone the GCs, and I'll log that more carefully. On Wednesday, October 11, 2017 at 8:35:44 PM UTC-4, Daniel Compton wrote: > > Without more information it's hard to tell, but this looks a like it could > be a

Re: possibly a Clojure question or possibly an AWS question: slow writes to durable-queue

Justin Smith, thanks, I've created an Uberjar that I now run under Supervisord on an EC2 instance, and I set the JVM options via the command that Supervisord calls. On Wednesday, October 11, 2017 at 6:58:52 PM UTC-4, Justin Smith wrote: > > a small thing here, if memory usage is important you

Re: SourceDebugExtension Class Attribute in clojure-1.8.0.jar

The other thing that would be affected is debugging using a bytecode debugger like Cursive's - that won't work without the debug info in the bytecode. pack200 is usually something that you'd use for deployment though, so perhaps this isn't a problem. On 12 October 2017 at 23:39, Alex Miller

Wrong Video title

while the title says "Homoiconicity : It Is What It Is - Stuart Sierra" , It's a different talk "Learning Clojure and CLJS by playing a card game" Video link :- https://www.youtube.com/watch?v=B_ubbbm9cRg -- You received this message because you are subscribed to the Google Groups "Clojure"

Re: SourceDebugExtension Class Attribute in clojure-1.8.0.jar

The SourceDebugExtension stuff is used (see JSR-45) to provide source code maps from the compiled classes back to the original source files, namely the source file name and the source file line numbers. This information appears in stack traces. Removing these debug extensions means you won't

Re: About determinism of async

That's clever! Just a bummer I have to feed everything to the chan in a collection for cat to work. Guess I could add a map transducer which converts non-collections into collections. keskiviikko 11. lokakuuta 2017 15.25.24 UTC+3 tbc++ kirjoitti: > > If you want to simply keep some messages in

Eastwood, the Clojure lint tool, version 0.2.5 released

Eastwood, the Clojure lint tool, version 0.2.5 has been released. See install instructions and complete documentation at [1]. Below are some of the changes since version 0.2.4. A complete list is at [2]. Thanks to contributions from Daniel Compton, Derek Passen, Emlyn Corrin, and Reid

SourceDebugExtension Class Attribute in clojure-1.8.0.jar

Recently I needed to run pack200 on the clojure-1.8.0.jar When I did this I got an error that SourceDebugExtension is an unknown class attribute. I got around this problem by removing all the SourceDebugExtension class attributes from clojure-1.8.0.jar. Here are my questions: What is clojure