> On Wednesday, January 15, 2020 at 10:46:36 AM UTC-6, Mike Rodriguez wrote:
>>
>> Do you have any idea about the reason that the Clojure implementation was
>> done this way - when it obviously seems a bit limited and also slower than
>> necessary? Just curious if there's
Do you have any idea about the reason that the Clojure implementation was
done this way - when it obviously seems a bit limited and also slower than
necessary? Just curious if there's some historical context.
On Tuesday, January 14, 2020 at 11:58:17 AM UTC-5, Nathan Marz wrote:
>
> The speedup
It's good to see this lib getting attention. It can be very useful.
On Monday, March 25, 2019 at 12:04:55 PM UTC-4, benedek fazekas wrote:
>
> hi everyone,
>
> happy to announce a new version of MrAnderson <
> https://github.com/benedekfazekas/mranderson>, a dependency inlining and
> shadowing
[cider/cider-nrepl "0.8.2"]
is quite old. It looks like lein 2.9.1 (as of 2.8.2) uses a newer version
of nrepl that requires cider-nrepl 0.18+ or something along those lines.
In newer versions of cider, you may not need to include this plugin at all.
I know that the "jack-in" commands of
Waeselynck wrote:
>
> @Mike Rodriguez the 0.1.3 release improves ClojureScript support and
> should solve the mentioned issue, along with much better documentation
> <https://github.com/alvalval/scope-capture/wiki/Pitfalls-with-(browser-connected)-ClojureScript-REPLs>
>
>
I really like this library already. I only had to give it about 5 minutes
of time to immediately see how it simplified quick REPL-driven debugging
workflows for me.
The only outstanding issue that is an annoyance for me is the CLJS support,
which is discussed
at
I've have used this as a lein plugin and I think it is a really great tool
to have available. It makes working on Java or a hybrid Java/Clojure
project more tolerable.
On Thursday, March 16, 2017 at 2:13:35 PM UTC-4, Zach Tellman wrote:
>
> I figured it was worth reminding everyone that this
I haven't been able to get to the bottom of this as of yet. Primarily the
problem is I need to investigate how `lein trampoline` works compared to
without it, from an implementation perspective.
I'll note that `lein test` does do a :reload option to `require` when
running tests. Typically
Guava is often a dependency conflict when trying to put libs together that use
it. I'm surprised cljs has dependencies like this. I'd think a language would
try to avoid having any deps at all or repackage them or something. For
example, Clojure only has ASM.
--
You received this message
I believe it is generally true that the Clojure-maven-plugin has
non-deterministic ordering of namespaces it auto "discovers" for its various
goals that involve namespace discovery.
This has been a source of frustration for me in the past as far as trying to
get determinism with test
plugin not
> preserving information that it should, so it seems like it should be fixed
> there.
>
> On Wednesday, December 28, 2016 at 7:06:11 AM UTC-6, Mike Rodriguez wrote:
>>
>> Background:
>>
>> This problem is specific to building jars that contain AOT (Ahea
(which fall back to .equals behavior).
>
> If you wanted to file a jira on anything here, a jira to add a line to the
> doc string stating that the first duplicate is kept would be the only thing
> possibly worth doing.
>
> Alex
>
>
> On Wednesday, December 28, 2016 at 10:
Yeah, I was thinking about logging the ticket for it. I just figured I'd
discuss it on the google groups first to see if anyone else thought it was
a useful concern.
It seems that some people have opinions on in it in both directions
perhaps, i.e. docs are sufficient vs docs are not
On Thursday, December 29, 2016 at 5:47:14 PM UTC-6, Erik Assum wrote:
>
> Wouldn't the order be different depending on wether you keep the first or
> the last?
>
> (distinct [1 2 1])
> => [1 2]
> vs
> (distinct [1 2 1])
> => [2 1]
>
> Erik.
> --
> i farta
>
>
I should have thought about this
> f it helps anyone sleep better at night, were the behavior of distinct ever
> to change in a way that breaks one's application, the original one is right
> there in the git history, available for everyone's copying and use, with
> whatever promises in the doc string you choose to add.
I
Yeah. It is so hard to come up with a real use case here after I think about it
that it is best to just let it be.
It would only matter if identity mattered for something, but still hard to even
contrive a scenario. So part (2) solved.
--
You received this message because you are subscribed
om
> > wrote:
>
>> Also, I'm assuming distinct uses .equals semantics which might be worth
>> calling out in the doc
>>
>> On Wed, Dec 28, 2016, 11:22 AM Mike Rodriguez <mjr...@gmail.com
>> > wrote:
>>
>>> The doc for `distinct` is:
>&g
The doc for `distinct` is:
"Returns a lazy sequence of the elements of coll with duplicates removed.
Returns a stateful transducer when no collection is provided."
(1) In the lazy sequence case, I've thought that maybe it is assuemd there
is a guarantee that the order of the input seq is
.invoke(Var.java:375)
at shade.ShadeJava.main(ShadeJava.java:14)
On Wednesday, December 28, 2016 at 7:06:11 AM UTC-6, Mike Rodriguez wrote:
>
> Background:
>
> This problem is specific to building jars that contain AOT (Ahead Of Time)
> compiled Clojure code using Maven and
lve further classloader issues.
>
> On Wed, Dec 28, 2016 at 8:06 AM Mike Rodriguez <mjr...@gmail.com
> > wrote:
>
>> Background:
>>
>> This problem is specific to building jars that contain AOT (Ahead Of
>> Time) compiled Clojure code using Maven and th
Background:
This problem is specific to building jars that contain AOT (Ahead Of Time)
compiled Clojure code using Maven and the maven-shade-plugin.
Clojure AOT compilation depends on timestamps of .class files vs .clj files
being accurate. When both .class files and their associated .clj
Thanks, both of you, for the extra background there.
On Wednesday, December 21, 2016 at 9:44:34 AM UTC-6, Alex Miller wrote:
>
> From prior conversations, Rich is not in favor of the preference approach
> for protocols. I'm not sure what he has in mind as an alternative though.
>
> On Wednesday,
On Wednesday, December 21, 2016 at 9:02:36 AM UTC-6, Alex Miller wrote:
>
>
>
> On Wednesday, December 21, 2016 at 7:24:17 AM UTC-6, Mike Rodriguez wrote:
>>
>> That sounds like a good idea to me. I think the major potential issue is
>> that it creates ambiguity
I found an issue with Clojure's behavior on iterators that somewhat relates
to what was discussed the comment thread of
http://dev.clojure.org/jira/browse/CLJ-1738. I'm posting it here to raise
awareness and to see if anyone thinks it is a legitimate concern or
"behaving as expected".
Uh oh. I should have asked. I ranked my priorities in the exact opposite order
since I thought 1 was lowest.
--
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
Just FYI. The code part under "Tabs are printed as \t:" has a typo and shows a
new line instead of tab.
Otherwise nice work.
--
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
I'm excited about this :managed-dependencies feature along with it's
combined usage with lein-parent. I think this is a feature I really needed
from Leiningen for quite some time now.
On Wednesday, August 24, 2016 at 7:03:52 PM UTC-5, Jean Niklas L'orange
wrote:
>
> Greetings, fellow
ecord via the record class
> itself. So, this is an area still potentially open for more work.
>
> I think deftype is not an issue as you don't generally have keyword field
> access in deftype like you do with defrecord.
>
>
> On Saturday, June 11, 2016 at 11:02:57 AM UTC-5, Mike R
I know that Spec and the changes coming to Clojure 1.9 I see that namespace
qualified keys have gained some focus. I understand the motivations for this
and support it.
The one barrier that is coming up for me is in the use of Clojure records (and
perhaps deftype types too). We use records
Thanks for this explanation. I think that cleared up some of this for me
more. I'm certainly excited about this new addition. I should have
started off with that.
On Wednesday, May 25, 2016 at 8:01:49 PM UTC-5, Rich Hickey wrote:
>
> I’d advise everyone concerned/confused about the
>
>
>> Is there a recommended way to introspect specs for our own purposes
>>> (coercion, code generation)? An interpreter on the output of 'describe'
>>> might work (although it's a little complicated for fn specs), but I wanted
>>> to know if you all had any thoughts or plans for the future
Vectors are eager. So they'd need to be finite. Varargs/rest args can be
infinite lazy sequences. So it is appropriate that they are just generic "seq"
abstractions instead of something specific (and eager) like a vector.
--
You received this message because you are subscribed to the Google
I won't speak directly to your use-case other than saying that `extend` is
already a function, so there is no reason to call it with a macro or via
strange evaluation orders via quotes and eval.
You can define the record first, as normal, then call `extend` after
dynamically and without messing
Read it and like it so far!
--
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 issue is a subtle one. I do find it interesting that all vars are
created and mapped to their namespace in the initN() (where N is 0 though
whatever) methods.
However, other top-level function calls happen in the load() method. All
of this runs in the clinit of the class though.
I'd
Nothing specific but for the same reason you'd want to use 'and' in other
scenarios. You want the short-circuit behavior if certain criteria are met.
Only in this case you just want a function that does it instead.
One contrived example coming to mind:
(every-fn iterative-has-next? get-next)
The distinction between names is important when one is a predicate and the
other is not. However I think it would be more useful if it were every-fn since
it is often more useful to have the final return value vs just true false. This
is consistent with the behavior or and and or. So some-fn
Nice! I'm excited to try this one out. Good idea.
--
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.
I second Ghadi's question (2). Is there any further information to read that
discusses the benefits found from direct linking? I understand the motivation.
I was just hoping to here some performance boost success stories.
--
You received this message because you are subscribed to the Google
I did a trial run of some of my production applications (big data space) and I
did see an overall improvement in execution time that seemed consistent. It was
not too significant of a difference though, but it was still good to see. I am
not positive my use case would have necessarily been in
Perhaps having a "map-entry?" predicate that was smarter would be
>>> helpful.
>>>
>>> On Friday, October 16, 2015 at 9:39:09 AM UTC-5, Mike Rodriguez wrote:
>>>>
>>>> Yes, I am in support of the fact that size=2 vectors now can now ha
l.
>
> On Friday, October 16, 2015 at 9:39:09 AM UTC-5, Mike Rodriguez wrote:
>>
>> Yes, I am in support of the fact that size=2 vectors now can now have
>> `key` and `val` called on them. This not working prior to Clojure 1.8 was
>> occasionally the reason why I just
ap entry (instead of a collection).
>>
>
> It does not make sense to me for empty on a MapEntry to do what you ask
> (for similar reasons why empty on a record is not allowed).
>
>
>> I'm happy to create a ticket for this use-case if deemed valid.
>>
>&
Someone else looked at the issue on
https://github.com/ztellman/riddley/issues/18
This issue makes the current version of riddley, and therefore potemkin, not
work on Clojure 1.8 beta1
There is a pull request to fix it at https://github.com/ztellman/riddley/pull/19
However I am wondering if
Just a heads up, I tried upliftign to Clojure 1.8.0-beta1 today and had a
failure that is originating from potemkin "0.4.1". I think the issue may
be in its dependent project riddley "0.1.10".
I logged an issue there at https://github.com/ztellman/riddley/issues/18.
I haven't tracked down the
Thanks for the info! I should have searched for that on Jira first. I actually
wasn't sure if doc changes typically warrant a Jira , but it looks like it
ended up being more than a doc fix!
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post
The doc string for clojure.core/run! is:
"Runs the supplied procedure (via reduce), for purposes of side
effects, on successive items in the collection. Returns nil"
However, it does not necessarily return nil.
e.g.
(run! #(do (println %) %) [1 2])
1
2
;= 2
It just returns whatever the
I think Artur described it well. I don't think the docs are wrong. The thing is
just understanding that the reader macro syntax is interpreted by the reader.
The reader comes before the evaluation of the compiler (there is grey area here
with read-eval but that's another topic).
Since a
This has came up numerous times in other posts here. I can't hunt them down
currently but the quoted symbol issue you showed is just a misunderstanding of
how the reader macro for metadata works.
Try (meta '^{:foo :bar} a)
When you put the reader macro in front of the quote it is applied to
Off subject. Just going to throw it out there that HttpInputOverHTTP looks like
a CamelCase naming convention gone wrong. Id like to hear why it was named that
way. :)
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email
I agree. I think it is an excellent talk. I've see pretty much all of his talks
and I think this is among the best.
--
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
Good call on the auto-boxing. I wasn't considering that before, but
obviously it is important.
Nice insight into :inline. I never really did understand the usefulness of
it before.
On Tuesday, July 7, 2015 at 10:20:51 PM UTC-5, Herwig Hochleitner wrote:
2015-07-07 15:04 GMT+02:00 Jo
consional = conditional
Typo sorry.
--
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
You can do some consional instance? checks at runtime and type hint each method
call appropriately.
Java would determine the correct method based on the type information known to
the compiler at compile time.
You don't have that given in Clojure so you have to runtime check the type and
I don't think this is a let me google that for you question. Let vs let* in
Clojure is not at all the same as the popular usages of these forms in popular
lisp dialects like Common Lisp.
I've thought it was confusing why let* existed in Clojure since let binding is
only done in a sequential
Thanks for the insight Alex!
--
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
I agree the hashCode performance for records is a concern due to that lack of
caching.
I noticed the priority of that Jira 1224 changed to critical about a week ago
(June 3). I was curious why that was done and what that means in terms of
prioritization.
Last minute squeeze into CLJ version
I'll chime in with my opinion on this topic.
I think the existing if-let and similar forms that have a limitation of only
allowing a single binding is a confusing restriction to place on the familiar
binding vector construct. I've always been a little uneasy about repurposing
binding vectors
Thanks Andy for the extra info and for logging the follow-up Jira!
It looks like the exception changes are expected and are a potential
improvement with line numbers etc.
My the main goal was just to provide constructive feedback on here of the
issues I faced investigating the upgrade of a
Sorry for the delay in getting back with a response to this. I think it is
fairly clear in the Clojure Compiler that there is an exception that will
wrap errors that occur during macroexpansion now.
Around
here
I can see in Git several areas where the compiler now catches exceptions thrown
and re throws them wrapped in this exception type. I've been out of town and
unable to make a small example yet. I will soon.
--
You received this message because you are subscribed to the Google
Groups Clojure
Seems like this could certainly be an issue with any interaction with Hadoop's
infamous reduce-side iterable object reuse. I will have to test further where I
may be affected similarly.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this
This isn't necessarily a problem, but I figured I'd put it up in case anyone
encounters similar or so that people can be aware of it coming.
We had some tests fail when I switched to the recent 1.7 versions of Clojure
(beta3 was last I checked, but it shouldn't have changed here).
The
+1 to Eastwood. It is great.
--
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
What you wanted here was
(meta '^:abc some-symbol)
It's a little weird but the reader attaches the metadata to the symbol. Then
the quote just evaluates directly to the same symbol, so the metadata is
preserved.
I agree that metadata can be confusing though. Especially around where AND
In reference to [1]:
I do feel like the metadata loss on many macros is undesirable though and I
wish it were addressed. It certainly feels unhygienic, just in a new sense
of the term.
[1] https://github.com/jonase/eastwood#unused-meta-on-macro
--
You received this message because you are
Not really related. But I just want to chime in to say I love this quote from
Fluid in regards to the DSL bit:
Under the hood is a delicate way of saying not homoiconic, whereby 90% of
the benefit goes away.
+1 to that!
--
You received this message because you are subscribed to the Google
I have found long docs like that to be useful in some major top-level function
if it has a large sort of input and configuration parameters to pass in.
Markdown I believe means with back ticks around the symbol to make it stand out
as an actual art name vs some other word in the sentence. I
I agree about wanting to use the explicit argument name surrounded by markdown
quotes in docs. I've definitely started adopting this practice and wish there
were conventions around this sort of thing. Without it, doc strings can easily
get ambiguous and confusing in how they relate the the
This is exactly one of the reasons a bunch of folk ( aka, purests maybe )
don't like that map/filter etc. in Clojure convert the input collection
into seqs, unlike Haskell or others where the those monad laws keep you in
check that map/filter return the *same* container - so mapping a set
Thanks for sharing this. I found the write-up to be very informative and
to have good background sources.
I certainly never thought about this sneaky behavior concerning `seq` and
hash sets before now. I'll have to look out for that one!
On Tuesday, April 21, 2015 at 8:13:48 PM UTC-5, Andy
We've been using Clojure at Cerner in the healthcare IT space.
--
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
Another thing to note is if you were using these maps as keys to a hash-based
associative structure, like a hash map, then you be aware that Clojure record
do not cache their hash code like other Clojure persistent map impls do.
I've had this eat up performance time in some scenarios before.
Sorry. That was a typo. I meant 1.8.
I'm just referring to the version tagged on the Jira.
--
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 -
I'm not 100% sure and haven't really looked deeply at this comment or link
you mention, but perhaps this is related to
http://dev.clojure.org/jira/browse/CLJ-979.
This would only be the case for Clojure-dynamically generated Java classes
though, which is those from deftype or the macros built
To the point (b) it seems that this posts is saying the clj's = will not be
faster for keyword than string since the runtime type checking overhead is
where most time is spent. So the identity part of keyword equals doesn't show
its benefit here (unless these were long strings vs long keywords
To the point (b) it seems that this posts is saying the clj's = will not be
faster for keyword than string since the runtime type checking overhead is
where most time is spent. So the identity part of keyword equals doesn't show
its benefit here (unless these were long strings vs long keywords
To the point (b) it seems that this posts is saying the clj's = will not be
faster for keyword than string since the runtime type checking overhead is
where most time is spent. So the identity part of keyword equals doesn't show
its benefit here (unless these were long strings vs long keywords
Thanks for taking the time for the (detailed) clarification. I understand what
you were saying now.
:)
--
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
Thanks for putting it up so fast!
--
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
80 matches
Mail list logo
