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
+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
REPLs built into the hardware in the 80s,
the ability to easily futz with graphics added an extra dimension to the
learning experience. Bocko imitates the gr mode from the Apple ][.
- Mike
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post
Yeah I agree. I misremembered them from 33 years ago as being HLINE and VLINE
and corrected them when I looked them up. :)
By the way, it is available for ClojureScript / iOS now:
https://github.com/mfikes/bocko-ios
(I have to say, CLJC rocks!)
- Mike
On May 8, 2015, at 10:16 PM, David
I've been waiting for this since the Conj, and so far it has been worth the
wait.
One thing that impressed me right off the bat was the amount of content - 300
pages in this beta version. A pleasant surprise considering the recent trend
of early access books that only have 2-3 chapters
Yeah, I noticed my mistake after I posted. I regularly use the kindle app and
iBooks and I forgot how they represent page numbers differently.
So I'll use a different, more appropriate metric - AIDKT's (Ah, I didn't know
that). About 30% of the way through the book, and I'm registering 3-4
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 agree that complex would be a better name.
It would be also be nice if it the 1-arg version could be idempotent (i.e.
returns an existing complex number unchanged). The downside is that this
would mean a slight performance hit because it would prevent the use of
primitive arguments. Maybe we
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
Living Clojure Do ~20 project euler problems (there are few open source
repos in Clojure you can compare your algorithms with).
On Thursday, 25 June 2015 10:59:12 UTC+2, Baskar Kalyanasamy wrote:
hi everyone,
can somebody send me materials for clojure. i am a
beginner and
June 2015 16:45:45 UTC+2, Dylan Butman wrote:
Have you looked at yada http://yada.juxt.pro/user-guide.html ?
It's an aleph compatible alternative to liberator that is swagger
compatible with swagger out of the box.
On Tuesday, June 23, 2015 at 5:33:50 AM UTC-4, Mike Grabowski wrote:
Hey
Hey guys,
I am so excited to join Clojure bandwagon, last weeks have been super
exciting, pretty much in love with Clojure syntax. As we are currently
building an application broken into smaller micro services, I thought I am
gonna make one or two Clojure based modules. Although the initial
:
On Tuesday, June 23, 2015, Mike Grabowski wrote:
... I just can't stop thinking about non-blocking evented
IO interactions. It just does not feel right to me to
block the thread when e.g. logging in an user.
Unfortunately, there are no NIO drivers for the database
engines I am
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'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
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 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
I think the right strategy is to make a separate complex array
implementation library (core.matrix.complex?). In terms of dependencies,
it would only need to depend depend upon core.matrix and complex.
The array representation could simply be a deftype which uses two
underlying arrays for the
OK, here's a basic version that I think has most of the key elements in
place.
A lot more protocols still need implementing, but it should be a reasonable
basis to build upon:
https://github.com/mikera/core.matrix.complex
On Tuesday, 2 June 2015 16:35:25 UTC+1, Christopher Small wrote:
/posts/2015-06-19-portable-macro-musing.html
(Hoping things don’t become excessively combinatorial.)
- Mike
On Jul 2, 2015, at 8:09 AM, Michael Sperber sper...@deinprogramm.de wrote:
I'd like to define a macro differently for Clojure and for ClojureScript.
Is there a way to do this via reader
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
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
Wondering what all this “bootstrapped ClojureScript” hubbub is all about, and
have an iOS device? There's a REPL app for that!
Try the beta; experience it firsthand:
https://github.com/mfikes/replete/wiki/Beta
Special thanks to David Nolen and Joel Martin for making this possible!
- Mike
I recently posted in mistake and deleted the post. Perhaps that is causing what
you are seeing.
- Mike
On Aug 4, 2015, at 10:09 AM, Fluid Dynamics a2093...@trbvm.com wrote:
The front page of this group shows no unread threads to me, but shows a (1)
next to Google Groups in the page title
-of-planck.html
- Mike
--
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
Planck 1.3 is now available via Homebrew:
http://blog.fikesfarm.com/posts/2015-08-04-pour-a-pint-of-planck.html
--
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
Happy to announce that Planck 1.0 is available:
http://planck.fikesfarm.com http://planck.fikesfarm.com/
--
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
Hi Zach,
Yeah, it definitely sounds like your Homebrew install has an issue.
You can also just download the binary from http://planck.fikesfarm.com
http://planck.fikesfarm.com/ (it is a self-contained single-file executable).
It works on Mavericks or later.
- Mike
On Aug 5, 2015, at 1:24 PM
This would be mighty useful:
http://dev.clojure.org/jira/browse/ASYNC-137
I was planning on moving away from using core.async because I had assumed
this issue would not be fixed and released in the forseeable future.
Should I have hope? :-)
On Thursday, August 6, 2015 at 9:22:56 AM
It was approved as is.
Out of curiosity, how painful/painless was the process of getting it accepted
into the app store? I've heard that Apple is pretty sensitive about letting
anything in that does any kind of evaluation of arbitrary code.
--
You received this message because you are
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
Replete 1.0 is now in the App Store
http://blog.fikesfarm.com/posts/2015-07-20-ios-clojurescript-repl-available-in-app-store.html
--
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
Nice. Thanks for pushing that through a Jira and into 1.8 so quickly!
On Tuesday, October 27, 2015 at 1:32:46 PM UTC-5, Alex Miller wrote:
>
> The map-entry? predicate was just committed to master and will be in the
> next build.
>
> On Friday, October 16, 2015 at 1:29:21
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
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
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
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
)) for the vector
case...
On Friday, October 16, 2015 at 6:39:50 AM UTC-5, Alex Miller wrote:
>
>
> On Friday, October 16, 2015 at 3:32:43 AM UTC-5, Pierre-Yves Ritschard
> wrote:
>>
>> Hi Mike,
>>
>> The code at here seems to contradict you:
>>
>> ht
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 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
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
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
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
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)
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.
>
>
>> 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
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
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
concurrency on the JVM is built on top of j.u.concurrent).
Mike
On Fri, Feb 12, 2016, 4:59 PM Fernando Abrao <fdab...@gmail.com> wrote:
> Hello All,
>
> I 'm doing a program that have to:
> - Read a file with list of hosts ip
> - Start pinging from n threads pool or whatever
Is the future returning a lazy seq? You might need to walk the seq with
doseq / dorun etc.
On Mon, Feb 15, 2016, 6:02 AM Gary Verhaegen
wrote:
> `future` starts a function in a separate thread, which comes out of a
> thread pool. It may not be that easy to check if a
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
Thanks! More to come real soon!
On Mon, Mar 21, 2016 at 5:34 PM, Rangel Spasov wrote:
> I'm continuously impressed by the work you guys are doing! Keep it up!
>
>
> On Monday, March 21, 2016 at 7:27:49 AM UTC-7, Michael Drogalis wrote:
>>
>> Hi everyone,
>>
>> I'm happy to
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
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
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
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
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
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
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. 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
> 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
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
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".
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,
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
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
.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
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
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'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
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 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
Is there still any activity in the clojure-android space? The
clojure-android mail list is largely inactive, seems like the developers of
lein-droid haven't done anything in months (1.7.0-r4 is still used in the
templates), and the numerous references If ind for an android-clojure web
site are
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
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>
>
>
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
> 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
So, Amit, any updates? Bear in mind that ICFP is Sept. 27-29 this
year.
-mike
On Jan 28, 4:40 pm, Amit Rathore amitrath...@gmail.com wrote:
The JavaOne alignment will probably work. The last time, we had a
special Bay Area Clojure meetup following it, and it was our biggest
ever (around 80
Adam Smyczek's Introduction to Monads video is now available.
http://www.youtube.com/user/LinkedInTechTalks?feature=mhw5#p/u/0/ObR3qi4Guys
I'll work on getting an HD version up Friday.
-mike
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post
701 - 794 of 794 matches
Mail list logo