Kumar,
Just so you know, on this page:
https://github.com/cambium-clojure/cambium.logback.core
you link to here:
https://cambium-clojure.github.io/
but I get a 404 when I go there.
On Monday, October 9, 2017 at 2:56:24 AM UTC-4, Shantanu Kumar wrote:
>
>
>>
>> I'm curious what others do fo
Shantanu Kumar, thanks for that, I might try it. I assume you've never had
the problem I'm talking about, of messages on background threads that
disappear?
On Monday, October 9, 2017 at 2:56:24 AM UTC-4, Shantanu Kumar wrote:
>
>
>>
>> I'm curious what others do for logging?
>>
>
> At Concur w
On Monday, 9 October 2017 12:31:57 UTC+5:30, lawrence...@gmail.com wrote:
>
> Kumar,
>
> Just so you know, on this page:
>
> https://github.com/cambium-clojure/cambium.logback.core
>
> you link to here:
>
> https://cambium-clojure.github.io/
>
> but I get a 404 when I go there.
>
I'm sorry the
On Monday, 9 October 2017 12:34:41 UTC+5:30, lawrence...@gmail.com wrote:
>
> Shantanu Kumar, thanks for that, I might try it. I assume you've never had
> the problem I'm talking about, of messages on background threads that
> disappear?
>
Logback (the SLF4j impl we use) is capable of logging
Slightly off-topic, but why doesn't using the 'incorrect' alphabet-macro
give an error? If I try and define a Record with keyword keys it tells me
very clearly not to:
user=> (defrecord Wrong [:a])
CompilerException java.lang.AssertionError: defrecord and deftype fields
must be symbols, user.W
In fact they are symbols, but print as keywords:
user=> (symbol ":a")
:a
user=> (symbol? (symbol (str :a)))
true
2017-10-09 16:26 GMT+08:00 Peter Hull :
> Slightly off-topic, but why doesn't using the 'incorrect' alphabet-macro
> give an error? If I try and define a Record with keyword keys it
Not easy to be positive without more information about your code base, but
the only times I had symptoms that resemble what you describe, the problem
was that the JVM died before printing. That is, you have multiple threads,
and printing is asynchronous at many levels (even the terminal itself
buff
Very cool, Val!
It should be possible to recreate the original scope as a let (instead of
defs) so you don't have to worry about the names cluttering up your
namespace.
Cheers,
Stu
On Sun, Oct 8, 2017 at 10:17 PM, Jiacai Liu wrote:
> Wow, what a good idea. Thanks for sharing.
>
> On Mon, Oct 9
The linked
page https://stuartsierra.com/2015/05/27/clojure-uncaught-exceptions also
says "Another wrinkle: exceptions inside a future are always caught by the
Future. The exception will not be thrown until something calls Future.get
(deref in Clojure)." So you would need to review the pattern
Hey Guys,
I wanted to know if there is a better way to get to the same result as
`GitlabProject[].class`
after some digging around, I got to this array of class definition by doing
something like `(class (make-array GitlabProject 1))`. But I don't know if
there is a better way to get to this sam
Thanks Stu! Yes that is one of the options the library provides, though not
the one I use most.
Le 9 oct. 2017 13:44, "Stuart Halloway" a
écrit :
> Very cool, Val!
>
> It should be possible to recreate the original scope as a let (instead of
> defs) so you don't have to worry about the names clu
What happens with loops? Say if you spy inside a for?
--
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 pos
You can generally use ^"[fully.qualified.ClassName" as the type hint, if that's
what you're trying to do. I'm not quite sure of the benefits of typing an array
when it's not a primitive one, though.
What are you trying to accomplish, if we zoom back a little bit? Maybe there's
a better way to d
(Class/forName "[Lorg.gitlab.api.models.GitlabProject;")
On Monday, October 9, 2017 at 10:38:37 AM UTC-5, pericles macedo wrote:
>
> Hey Guys,
> I wanted to know if there is a better way to get to the same result as
> `GitlabProject[].class`
> after some digging around, I got to this array of cl
> The argument that existence of specs provided to s/keys can only be
checked at runtime is false.
> The argument that that recursive specs are impossible if existence of
specs provided to s/keys was checked at compile time is also false.
Could you explain to us why this is false? Clojure is a
Thanks Alex :)
Yes, that works better
On Monday, October 9, 2017 at 9:21:24 AM UTC-7, Alex Miller wrote:
>
> (Class/forName "[Lorg.gitlab.api.models.GitlabProject;")
>
>
> On Monday, October 9, 2017 at 10:38:37 AM UTC-5, pericles macedo wrote:
>>
>> Hey Guys,
>> I wanted to know if there is a bett
Hey Gary, thanks for the help
I'm not sure if a type hint would work in this case, as the attribute
expect a class literal, and not a variable of that specific class. Thanks
for the example though, I didn't know that was a valid type hint.
About what I'm trying to do, I'm using a gitlab api gem
MatchingSocks, thanks for that. I think the pattern I followed everywhere
was:
(future
(slingshot/try+
;;; some code
(catch Object o
(println o
So I think I do catch everything inside of each future that I launch. But I
will check again. Perhaps I missed one somewhere.
O
Gary Verhaegen, thanks for that. The idea of buffers and threads dying is a
good one and gives me something to look for.
On Monday, October 9, 2017 at 2:23:05 PM UTC-4, lawrence...@gmail.com wrote:
>
> MatchingSocks, thanks for that. I think the pattern I followed everywhere
> was:
>
> (future
Timbre has a logged-future macro that you can use instead of future so that
exceptions are automatically logged.
Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
_
I have opened two issues on the original nREPL repo:
1. Describing the background and rationale for the work to be done:
https://github.com/cemerick/nREPL/issues/1
2. Enumerating the nREPL contributors to obtain explicit permission for
their commits to be distributed under the terms of EPL only (
Hello,
I'm generating deftest's using a helper macro that takes a variety of test
parameters and though the tests function correctly, the output of a failed
test is not exactly right. The expect value is shown as the un-evaluated
test form, and the actual value is shown as the result of evaluat
Sean Corfield, thank you, that is a great tip.
On Monday, October 9, 2017 at 2:59:35 PM UTC-4, Sean Corfield wrote:
>
> Timbre has a logged-future macro that you can use instead of future so
> that exceptions are automatically logged.
>
>
>
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
>
I figured a common reason for error messages to disappear is when there is
another Exception inside of the catch block, so the catch block itself dies
without doing anything.
I had copy-and-pasted this from somewhere, without looking at it much:
(catch Exception e
(println e)
(sta
The problem isn't the macro, it's your use of syntax quoting. `(= x y) gets
expanded at read-time into `(clojure.core/= x y)`. Not much you can do
about that. Although I'd suggest perhaps changing your code a bit to not
require macros.
deftest mostly just creates a defn with some extra metadata an
Hey Everyone,
I've released a new course called *Code Katas* on Clojurecademy, which is a
curated list of Clojure Code
Katas: https://clojurecademy.com/courses/17592186068882/learn/overview
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to
Le 9 oct. 2017 18:17, "Didier" a écrit :
What happens with loops? Say if you spy inside a for?
It records and logs new information on each iteration :) see `disable!`
and/or `brk` if that's inconvenient.
--
You received this message because you are subscribed to the Google
Groups "Clojure" gro
27 matches
Mail list logo
