Re: [ANN] Morph v0.1.0 Monads & friends: pure functions, less boilerplate
btw, have you seen https://github.com/jduey/protocol-monads ? Marek On Thursday, February 7, 2013 1:06:39 AM UTC+1, Armando Blancas wrote: > > Morph is a new implementation of monads based on protocols. It's intended > to provide the common patterns of error-handling, short-circuit sequencing, > and modeling of stateful computations in pure functions. I've tried to make > this library idiomatic while keeping it close to its Haskell roots. > > This is a utility library that, I hope, can make your coding easier. No > particular knowledge is assumed or required. The docs name things but rely > on getting an intuitive feeling of what's going on. Protocols are relevant > only if you want to write your own plumbing, which shouldn't be difficult; > otherwise it's all ready to use. > > Project: https://github.com/blancas/morph > User Guide: https://github.com/blancas/morph/wiki > Codox API: http://blancas.github.com/morph > > Please use the project wiki for feedback, bug reports, or feature requests. > > -- -- 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, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: *read-eval* vulnerability
The most simple thing would be to change the default value of *read-eval* to false... Marek On Wednesday, January 30, 2013 8:02:54 AM UTC+1, Takahiro Hozumi wrote: > > As more and more projects are using edn format for config, > communication and etc, I think that default value of *read-eval*, > which is true, is source of vulnerability such as recently reported > ring issue [1]. > And I don't understand why read-string depends on *read-eval* instead > of argument. > I believe optional argument is more preferable. > What do you think? > > [1] Ring 1.0.3 / 1.1.7 released to fix security flaw > > https://groups.google.com/group/clojure/browse_thread/thread/7b0fe662867b9124 > -- -- 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, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Is contributing to clojurescript is intentionally made hard ?
On Saturday, January 19, 2013 8:56:28 PM UTC+1, Andy Fingerhut wrote: > > Irakli: > > I am curious about the possibility of auto-creating patches from git pull > requests, in case that would bridge the divide between people that would > prefer submitting pull requests, and Clojure screeners that would prefer > evaluating patches and JIRA tickets. > > Causing a new git pull request to to auto-create a JIRA ticket with a > patch sounds easy, but that isn't the whole process. > > What about comments that are later added to the pull request? Are they > auto-added as comments to the JIRA ticket? > > Are comments added to the JIRA ticket auto-added as comments to the pull > request? > > If the JIRA ticket is closed, does that automatically close the github > pull request? > > If the answer to all of the above is "yes, already works that way", then > I'd be willing to spend a little more time looking into it. Do you have > links to any info on the tools that enable such behavior? > > Thanks, > Andy > > There's another, easier possibility - When the pull request is created, create also the JIRA issue with the patch added, then add a github comment pointing to the JIRA issue and close the pull request. This is not perfect, but IMO better than the current state... Another, even easier would be just to autopost a github comment, stating that pull requests aren't accepted and pointing to the Clojure contributing page... Marek > On Jan 18, 2013, at 5:13 PM, Irakli Gozalishvili wrote: > > At mozilla we also require signing CA but do accept pull requests and > there are whole team of legal people that > makes sure things like that don't raise any legal concerns. After all it's > just .patch to the pull request url gives you > an actual change patch so if reviewing patches is desired it's easy to > build a tool that attaches it to JIRA. We in fact > do that for bugzilla. The good news is that such tools are already written > for JIRA so it's just matter of enabling it! > > -- 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, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Numerical Clojure - discussion open!
The url is https://groups.google.com/forum/#!forum/numerical-clojure Marek On Friday, January 11, 2013 10:41:58 AM UTC+1, Shantanu Kumar wrote: > > Hi Mike, > > Could you please share the discussion group URL? > > Shantanu > > On Jan 11, 9:12 am, Mikera wrote: > > Hello everybody, > > > > I've created a new discussion group "Numerical Clojure" for anyone > > interested in doing serious numerical computing in Clojure. > > > > The vision is to build a numerics capability / set of libraries in > Clojure > > somewhat inspired by what the Python community has done with NumPy, but > > also building on the many natural strengths that Clojure should have in > > this space (e.g. the wealth of JVM libraries, symbolic metaprogramming, > > high level abstraction capabilities etc.) > > > > An initial focus is on creating a "core.matrix" API for vector / matrix > > maths. There's a working prototype of this on GitHub: > > -https://github.com/mikera/matrix-api > > > > Anyone interested in this topic, please join the group and contribute > your > > ideas! > > > > Best regards, > > > >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, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: list* not returning a list
I found CLJ-1060 [1] and added there a patch with Cons implementing IPersistentList and (apply list args) in one-argument case of list*. Marek [1] http://dev.clojure.org/jira/browse/CLJ-1060 On Wednesday, December 26, 2012 9:35:25 PM UTC+1, Marek Šrank wrote: > > function list* doesn't return a list, because it uses 'cons' under the > hood: > > (list? (list* 1 2 3 '())) > ;=> false > > (class (list* 1 2 3 '())) > ;=> clojure.lang.Cons > > ...however, its docstring says: "Creates a new list containing the items > prepended to the rest, the last of which will be treated as a sequence." > > I think that this can be pretty confusing... Shouldn't it be fixed (at > least the docstring)? > > > Cheers, > Marek. > > -- 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, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: list* not returning a list
Making Cons implement IPersistentList will solve all cases except when
list* gets only one argument. This is problematic. The source looks like
this:
(defn list*
"Creates a new list containing the items prepended to the rest, the
last of which will be treated as a sequence."
{:added "1.0"
:static true}
([args] (seq args))
([a args] (cons a args))
([a b args] (cons a (cons b args)))
([a b c args] (cons a (cons b (cons c args
([a b c d & more]
(cons a (cons b (cons c (cons d (spread more)))
Calling 'seq' in the first case means that with calls like: (list* {:a 1})
we get clojure.lang.PersistentArrayMap$Seq and not a List. In theory, we
could do just (apply list args) here, but apply itself also uses list* in
its implementation. Luckily, it doesn't use the one-argument version of
list*, so we could probably declare 'apply' above the 'list*' in the
'core.clj' source and then use it there... Does it seem reasonably?
Marek
On Thursday, December 27, 2012 3:28:04 AM UTC+1, Tom Jack wrote:
>
> A small bug in ClojureScript was related to this:
> https://github.com/clojure/clojurescript/commit/88b36c177ebd1bb49dbd874a9d13652fd1de4027
>
> It looks like the only thing missing to make Cons implement
> IPersistentList is IPersistentStack. Why not implement it?
>
> On Wednesday, December 26, 2012 4:13:38 PM UTC-6, Ben wrote:
>>
>> On Wed, Dec 26, 2012 at 2:07 PM, Stephen Compall
>> wrote:
>> > On Wed, 2012-12-26 at 12:35 -0800, Marek Šrank wrote:
>> >> ...however, its docstring says: "Creates a new list containing the
>> items
>> >> prepended to the rest, the last of which will be treated as a
>> sequence."
>> >
>> > List is almost always colloquial, not literally IPersistentList.
>> >
>> > I would be in favor of eliminating list?, really, in favor of
>> > seq?/sequential?/seqable?.
>>
>> Given that lists and (e.g.) vectors behave differently in some
>> circumstances (as the first argument to conj, for instance), it seems
>> desirable to be able to tell what one's got on one's hands.
>>
>> --
>> Ben Wolfson
>> "Human kind has used its intelligence to vary the flavour of drinks,
>> which may be sweet, aromatic, fermented or spirit-based. ... Family
>> and social life also offer numerous other occasions to consume drinks
>> for pleasure." [Larousse, "Drink" entry]
>>
>
--
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, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
list* not returning a list
function list* doesn't return a list, because it uses 'cons' under the hood: (list? (list* 1 2 3 '())) ;=> false (class (list* 1 2 3 '())) ;=> clojure.lang.Cons ...however, its docstring says: "Creates a new list containing the items prepended to the rest, the last of which will be treated as a sequence." I think that this can be pretty confusing... Shouldn't it be fixed (at least the docstring)? Cheers, Marek. -- 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, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Confused about comp
...which should be also a lot faster :)
On Saturday, December 15, 2012 5:44:01 PM UTC+1, Armando Blancas wrote:
>
> (comp (partial apply str) (partial filter #{\a}))
>>
>
> Or, (comp join (partial filter #{\a}))
>
>
--
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, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Clojure videos deleted from blip.tv?
Btw, seems that Rich won't allow sharing his videos by ourselves: https://twitter.com/richhickey/status/279414741582114817 , but he's going to find an alternate location where to put them, so it should be all okay then :) Marek. On Friday, December 14, 2012 2:20:09 PM UTC+1, Marek Šrank wrote: > > So I downloaded them to make a backup, but I found that I have only > 10GB/30days upload limit on my current academic internet network, so It'll > take time till I upload them all :-/ > Then I'll post the download links, just in a case the Blip TV will delete > them in a future... > > Marek > > On Friday, December 14, 2012 12:32:17 PM UTC+1, Marek Šrank wrote: >> >> While they are not on http://blip.tv/clojure , I was able to google >> them: https://google.com/search?q=site:blip.tv/clojure - all the links >> are here: http://is.gd/clojure_blip_videos >> >> In the process I also found the rss channel http://blip.tv/clojure/rsswhich >> has direct links to the files (especially Firefox displays them in a >> nice way). Direct urls to the videos (best quality) are here: >> https://gist.github.com/4284773 I'm going to download all of them now >> and will put them somewhere... >> >> Marek. >> >> On Thursday, December 13, 2012 5:40:21 AM UTC+1, Alex Grigorovich wrote: >>> >>> Hi, >>> >>> I was trying to watch Rich's videos on http://clojure.blip.tv and got a >>> 404 Not Found. Searching blip.tv for "clojure" brings up on entry that >>> is "pending deletion". Are these videos available elsewhere? What's going >>> on? >>> >>> -- >>> Thanks, >>> 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 this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure videos deleted from blip.tv?
So I downloaded them to make a backup, but I found that I have only 10GB/30days upload limit on my current academic internet network, so It'll take time till I upload them all :-/ Then I'll post the download links, just in a case the Blip TV will delete them in a future... Marek On Friday, December 14, 2012 12:32:17 PM UTC+1, Marek Šrank wrote: > > While they are not on http://blip.tv/clojure , I was able to google them: > https://google.com/search?q=site:blip.tv/clojure - all the links are > here: http://is.gd/clojure_blip_videos > > In the process I also found the rss channel http://blip.tv/clojure/rsswhich > has direct links to the files (especially Firefox displays them in a > nice way). Direct urls to the videos (best quality) are here: > https://gist.github.com/4284773 I'm going to download all of them now and > will put them somewhere... > > Marek. > > On Thursday, December 13, 2012 5:40:21 AM UTC+1, Alex Grigorovich wrote: >> >> Hi, >> >> I was trying to watch Rich's videos on http://clojure.blip.tv and got a >> 404 Not Found. Searching blip.tv for "clojure" brings up on entry that >> is "pending deletion". Are these videos available elsewhere? What's going >> on? >> >> -- >> Thanks, >> 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 this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure videos deleted from blip.tv?
While they are not on http://blip.tv/clojure , I was able to google them: https://google.com/search?q=site:blip.tv/clojure - all the links are here: http://is.gd/clojure_blip_videos In the process I also found the rss channel http://blip.tv/clojure/rss which has direct links to the files (especially Firefox displays them in a nice way). Direct urls to the videos (best quality) are here: https://gist.github.com/4284773 I'm going to download all of them now and will put them somewhere... Marek. On Thursday, December 13, 2012 5:40:21 AM UTC+1, Alex Grigorovich wrote: > > Hi, > > I was trying to watch Rich's videos on http://clojure.blip.tv and got a > 404 Not Found. Searching blip.tv for "clojure" brings up on entry that is > "pending deletion". Are these videos available elsewhere? What's going on? > > -- > Thanks, > 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 this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: abysmal multicore performance, especially on AMD processors
> Just tried, my first foray into reducers, but I must not be understanding > something correctly: > > (time (r/map burn (doall (range 4 > > returns in less than a second on my macbook pro, whereas > > (time (doall (map burn (range 4 > > takes nearly a minute. > > This feels like unforced laziness (although it's not quite that fast), but > clojure.core.reducers/map involves no laziness, right? > > Yep, reducers, don't use lazy seqs. But they return just sth. like transformed functions, that will be applied when building the collection. So you can use them like this: (into [] (r/map burn (doall (range 4) See http://clojure.com/blog/2012/05/08/reducers-a-library-and-model-for-collection-processing.html and http://clojure.com/blog/2012/05/15/anatomy-of-reducer.html for more info... Marek. -- 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, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Proposed change to let-> syntax
+1 On Saturday, December 1, 2012 6:38:54 PM UTC+1, Andy Fingerhut wrote: > > I don't have suggestions for the best names for these new things, but one > good example in the doc string would go a long way to making it clearer > what they *do* and how they are intended to be used. The doc strings are > written once, but read thousands of times, and are your most reliable line > of communication to Clojure developers. Everyone can find them quickly. > > Andy > > On Dec 1, 2012, at 6:48 AM, Rich Hickey wrote: > > > I'll argue that if 'e' in conde is enough to imply 'each' then '->' in > cond-> is enough to imply it keeps threading. > > > > I think many people have ideas about -> operators born of some of these > libraries that supply a wealth of 'things you can use in ->'. Most of > their operators have '->' in their names, but don't fundamentally thread - > e.g. they are terminators or one shots like if-> (or ->if). > > > > A op-> operator, IMO, should take an open set of expressions and thread > the return values through them in some way. Otherwise it shouldn't be an > op->. > > > > When one reads -> as 'thread' vs 'for use in threading', things might > become clearer. > > > > > > On Dec 1, 2012, at 9:31 AM, Steve Miner wrote: > > > >> gate-> would work. Like guard-> it doesn't have any connotations in > the Clojure world, but it's learnable. I'll add one more: qual-> ... short > for "qualified threading macro". Each clause is qualified by a test > condition. > >> > >> Of course, there's always conde-> to borrow from miniKanren and > core.logic. The "e" stands for "every" because multiple clauses can > succeed as opposed to the short-circuiting cond. > >> > >> > >> On Nov 30, 2012, at 2:49 PM, Rich Hickey > > wrote: > >> > >>> > >>> On Nov 30, 2012, at 1:49 PM, Steve Miner wrote: > >>> > I propose guard-> to avoid the cond-> confusion. > > >>> > >>> Yeah, that came up. Guards in other langs are short circuiting, just > like cond. > >>> > >>> Another in that camp was gate-> > >> > >> -- > >> You received this message because you are subscribed to the Google > >> Groups "Clojure" group. > >> To post to this group, send email to clo...@googlegroups.com > >> Note that posts from new members are moderated - please be patient with > your first post. > >> To unsubscribe from this group, send email to > >> clojure+u...@googlegroups.com > >> For more options, visit this group at > >> http://groups.google.com/group/clojure?hl=en > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clo...@googlegroups.com > > Note that posts from new members are moderated - please be patient with > your first post. > > To unsubscribe from this group, send email to > > clojure+u...@googlegroups.com > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > > -- 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, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: lein 2.x not working on Mac OS X 10.7.5 -- Exception in thread "main" java.lang.ClassNotFoundException:
Yep, leiningen now doesn't create -main function in the default template
Marek.
On Wednesday, November 14, 2012 8:40:20 PM UTC+1, Alec Ramsay wrote:
>
> My bad: I did not have (defn -main[] (...)) defined.
>
>
> On Wednesday, November 14, 2012 7:42:20 AM UTC-8, Alec Ramsay wrote:
>>
>> Thanks everyone for the feedback. To rule out any hyphen / underscore
>> issues, I created a new project "hello". Got the same exception:
>>
>> Exception in thread "main" java.lang.ClassNotFoundException: hello.core
>> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>> at clojure.lang.DynamicClassLoader.findClass(DynamicClassLoader.java:61)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
>> at java.lang.Class.forName0(Native Method)
>> at java.lang.Class.forName(Class.java:247)
>> at clojure.lang.RT.classForName(RT.java:2039)
>> at clojure.lang.Reflector.invokeStaticMethod(Reflector.java:199)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:93)
>> at clojure.lang.Reflector.invokeStaticMethod(Reflector.java:207)
>> at user$eval12.invoke(NO_SOURCE_FILE:1)
>> at clojure.lang.Compiler.eval(Compiler.java:6511)
>> at clojure.lang.Compiler.eval(Compiler.java:6501)
>> at clojure.lang.Compiler.eval(Compiler.java:6477)
>> at clojure.core$eval.invoke(core.clj:2797)
>> at clojure.main$eval_opt.invoke(main.clj:297)
>> at clojure.main$initialize.invoke(main.clj:316)
>> at clojure.main$null_opt.invoke(main.clj:349)
>> at clojure.main$main.doInvoke(main.clj:427)
>> at clojure.lang.RestFn.invoke(RestFn.java:421)
>> at clojure.lang.Var.invoke(Var.java:419)
>> at clojure.lang.AFn.applyToHelper(AFn.java:163)
>> at clojure.lang.Var.applyTo(Var.java:532)
>> at clojure.main.main(main.java:37)
>>
>>
>> I'm not using gen-class.
>>
>> Any other thoughts?
>>
>> I could be way off base, but it feels like something's not right in the
>> repo, dependencies, or search path. Is there a way to reset all of these /
>> make sure they're all right?
>>
>> Thanks ...
>>
>>
>> On Tuesday, November 13, 2012 4:11:58 PM UTC-8, Alec Ramsay wrote:
>>>
>>> When I do "lein run" now, I get "Exception in thread "main"
>>> java.lang.ClassNotFoundException:".
>>>
>>> I'm early in the process of getting a Clojure development environment
>>> set up--I coded a lot of LISP years ago and want to dust off my skills with
>>> Clojure--and I have previously successfully done the following on Mac OS X
>>> 10.7.5:
>>>
>>>- Installed Leiningen using Brew--this installed a V1 version
>>>- Created and run projects ("lein new"; "lein run"; etc.)
>>>- Everything worked great
>>>
>>> However, I wanted to use nREPL in Aquamacs, so I needed lein 2.x. The
>>> only way I could get lein2 installed was using these
>>> steps.
>>>
>>> After completing them, I successfully tested nREPL inside Aquamacs. Again
>>> things seemed to work great.
>>>
>>> But while "lein new" still works, "lein run" does not. I get the
>>> following exception:
>>>
>>> Exception in thread "main" java.lang.ClassNotFoundException:
>>> http_hello3.core
>>> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
>>> at java.security.AccessController.doPrivileged(Native Method)
>>> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>>> at clojure.lang.DynamicClassLoader.findClass(DynamicClassLoader.java:61)
>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
>>> at java.lang.Class.forName0(Native Method)
>>> at java.lang.Class.forName(Class.java:247)
>>> at clojure.lang.RT.classForName(RT.java:2039)
>>> at clojure.lang.Reflector.invokeStaticMethod(Reflector.java:199)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>> at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:93)
>>> at clojure.lang.Reflector.invokeStaticMethod(Reflector.java:207)
>>> at user$eval12.invoke(NO_SOURCE_FILE:1)
>>> at clojure.lang.Compiler.eval(Compiler.java:6511)
>>> at clojure.lang.Compiler.eval(Compiler.java:6501)
>>> at clojure.lang.Compiler.eval(Compiler.java:6477)
>>> at clojure.core$eval.invoke(core.clj:2797)
>>> at clojure.main$eval_opt.invoke(main.clj:297)
>>> at clojure.m
Re: lein 2.x not working on Mac OS X 10.7.5 -- Exception in thread "main" java.lang.ClassNotFoundException:
I also had the same issue some time ago and it was caused by incorrect
using of dash ('-') vs. underscore ('_') in project/namespace name... I
don't remember what concretely was wrong, but you at least can try all
possibilities
Also, are you using gen-class ?
Marek.
On Wednesday, November 14, 2012 1:11:58 AM UTC+1, Alec Ramsay wrote:
>
> When I do "lein run" now, I get "Exception in thread "main"
> java.lang.ClassNotFoundException:".
>
> I'm early in the process of getting a Clojure development environment set
> up--I coded a lot of LISP years ago and want to dust off my skills with
> Clojure--and I have previously successfully done the following on Mac OS X
> 10.7.5:
>
>- Installed Leiningen using Brew--this installed a V1 version
>- Created and run projects ("lein new"; "lein run"; etc.)
>- Everything worked great
>
> However, I wanted to use nREPL in Aquamacs, so I needed lein 2.x. The only
> way I could get lein2 installed was using these
> steps.
> After completing them, I successfully tested nREPL inside Aquamacs. Again
> things seemed to work great.
>
> But while "lein new" still works, "lein run" does not. I get the following
> exception:
>
> Exception in thread "main" java.lang.ClassNotFoundException:
> http_hello3.core
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at clojure.lang.DynamicClassLoader.findClass(DynamicClassLoader.java:61)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:247)
> at clojure.lang.RT.classForName(RT.java:2039)
> at clojure.lang.Reflector.invokeStaticMethod(Reflector.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:93)
> at clojure.lang.Reflector.invokeStaticMethod(Reflector.java:207)
> at user$eval12.invoke(NO_SOURCE_FILE:1)
> at clojure.lang.Compiler.eval(Compiler.java:6511)
> at clojure.lang.Compiler.eval(Compiler.java:6501)
> at clojure.lang.Compiler.eval(Compiler.java:6477)
> at clojure.core$eval.invoke(core.clj:2797)
> at clojure.main$eval_opt.invoke(main.clj:297)
> at clojure.main$initialize.invoke(main.clj:316)
> at clojure.main$null_opt.invoke(main.clj:349)
> at clojure.main$main.doInvoke(main.clj:427)
> at clojure.lang.RestFn.invoke(RestFn.java:421)
> at clojure.lang.Var.invoke(Var.java:419)
> at clojure.lang.AFn.applyToHelper(AFn.java:163)
> at clojure.lang.Var.applyTo(Var.java:532)
> at clojure.main.main(main.java:37)
>
> My project.clj looks like this:
>
> (defproject http_hello3 "0.1.0-SNAPSHOT"
> :description "http hello"
> ; :url "http://example.com/FIXME";
> ; :license {:name "Eclipse Public License"
> ;:url "http://www.eclipse.org/legal/epl-v10.html"}
> :dependencies [[org.clojure/clojure "1.4.0"]])
>
> I've done a lot of searching and tried several different things, to no
> avail. I'd appreciate any pointers you can give me. Thanks ...
>
>
--
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, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: pattern-matching in Closure?
At the wiki: https://github.com/clojure/core.match/wiki :-) Marek. On Sunday, November 4, 2012 11:03:40 PM UTC+1, Vladimir Tsichevski wrote: > > Hi Moritz, > > this looks promising. Do you know where can I get any > documentation/examples for this module? > > Regards, > Vladimir > > On Monday, November 5, 2012 1:10:59 AM UTC+4, Moritz Ulrich wrote: >> >> Use core.match: https://github.com/clojure/core.match >> >> On Sun, Nov 4, 2012 at 10:09 PM, Vladimir Tsichevski >> wrote: >> > Hi gurus. >> > >> > Is it possible in Clojure to use pattern matching, like I can with >> Bigloo >> > scheme, for example: >> > >> > (match-case '(a b a) >> > ((?x ?x) 'foo) >> > ((?x ?- ?x) 'bar)) >> > >> > Regards, >> > Vladimir >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups "Clojure" group. >> > To post to this group, send email to clo...@googlegroups.com >> > Note that posts from new members are moderated - please be patient with >> your >> > first post. >> > To unsubscribe from this group, send email to >> > clojure+u...@googlegroups.com >> > For more options, visit this group at >> > http://groups.google.com/group/clojure?hl=en >> > -- 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, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Why is a non-transient `into` faster than the built-in one?
These are my results using (dotimes (time (dotimes ...))) combo to get
consistent results:
- on sets:
(dotimes [i 10] (time (dotimes [j 100] (into #{} (range 1e4)
"Elapsed time: 388.595226 msecs"
"Elapsed time: 406.666801 msecs"
"Elapsed time: 421.559753 msecs"
"Elapsed time: 444.719263 msecs"
"Elapsed time: 431.319374 msecs"
"Elapsed time: 392.3779 msecs"
"Elapsed time: 392.382365 msecs"
"Elapsed time: 408.71734 msecs"
"Elapsed time: 444.203973 msecs"
"Elapsed time: 442.351363 msecs"
(dotimes [i 10] (time (dotimes [j 100] (naive-into #{} (range 1e4)
"Elapsed time: 1287.412806 msecs"
"Elapsed time: 1318.931199 msecs"
"Elapsed time: 1314.773064 msecs"
"Elapsed time: 1292.664029 msecs"
"Elapsed time: 1277.616099 msecs"
"Elapsed time: 1289.514678 msecs"
"Elapsed time: 1700.74875 msecs"
"Elapsed time: 1352.734662 msecs"
"Elapsed time: 1464.09882 msecs"
"Elapsed time: 1449.704738 msecs"
- on vectors:
(dotimes [i 10] (time (dotimes [j 100] (into [] (range 1e4)
"Elapsed time: 307.838501 msecs"
"Elapsed time: 243.426624 msecs"
"Elapsed time: 234.013566 msecs"
"Elapsed time: 247.711805 msecs"
"Elapsed time: 253.154264 msecs"
"Elapsed time: 284.375476 msecs"
"Elapsed time: 227.773865 msecs"
"Elapsed time: 247.807286 msecs"
"Elapsed time: 240.959477 msecs"
"Elapsed time: 230.627513 msecs"
(dotimes [i 10] (time (dotimes [j 100] (naive-into [] (range 1e4)
"Elapsed time: 406.55752 msecs"
"Elapsed time: 419.365134 msecs"
"Elapsed time: 413.544069 msecs"
"Elapsed time: 410.892756 msecs"
"Elapsed time: 394.827165 msecs"
"Elapsed time: 407.338251 msecs"
"Elapsed time: 441.60916 msecs"
"Elapsed time: 401.721826 msecs"
"Elapsed time: 412.7506 msecs"
"Elapsed time: 399.972445 msecs"
Clojure 1.4.0
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) Server VM (build 20.1-b02, mixed mode)
Cheers.
Marek.
On Sunday, November 4, 2012 3:41:14 AM UTC+1, Satoru Logic wrote:
>
> Hi, all.
>
> I am following an example demonstrating that `transient` can help optimize
> mass updates to data structures:
>
> First, a function is defined, which doesn't use transient collection:
>
> (defn naive-into
>> [coll source]
>> (reduce conj coll source))
>
>
> This is supposed to run slower than the built-in `into`, because, as the
> book said, `into` uses transient collections whenever possible.
>
> But the result shows up in my `repl` is just the reverse.
>
>
>> user=> (time (do (into #{} (range 1e6)) nil))
>> "Elapsed time: 4882.176 msecs"
>> nil
>> user=> (time (do (naive-into #{} (range 1e6)) nil))
>> "Elapsed time: 3745.707 msecs"
>> nil
>
>
> What could be the reason of this?
>
--
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, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: leiningen: RuntimeException: Unable to resolve symbol: doc in this context
Oh yes, I've found the commit https://github.com/clojure/clojure/commit/728972b026a323fc941a5d560b81d37453dc6cad . I should look at the commits first Marek. On Saturday, October 27, 2012 10:26:22 PM UTC+2, Marek Šrank wrote: > > Please ignore that github link. I somehow got the feeling that it's about > a bug in leiningen (really don't know why :), but now I see that it's > (probably) totally unrelated :D > Marek > > On Saturday, October 27, 2012 10:20:34 PM UTC+2, Marek Šrank wrote: >> >> When using [org.clojure/clojure "1.5.0-beta1"] in my project.clj, >> calling: (doc function) gives me this exception: >> >> CompilerException java.lang.RuntimeException: Unable to resolve symbol: >> doc in this context, compiling:(NO_SOURCE_PATH:1:1) >> >> And similarly with find-doc, source, javadoc and clojuredocs. >> >> With clojure 1.5.0-alpha7 or below, it works normally like it always >> worked... >> >> Can this be a bug in a Clojure (or Leiningen)? >> >> I've found this https://github.com/trptcolin/reply/issues/17 but for me >> it works in 1.5.0-alpha7 or below and not in 1.5.0-beta1 so I conclude that >> it must be somehow connected with recent changes in Clojure itself... >> >> Marek >> > -- 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, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: leiningen: RuntimeException: Unable to resolve symbol: doc in this context
Please ignore that github link. I somehow got the feeling that it's about a bug in leiningen (really don't know why :), but now I see that it's (probably) totally unrelated :D Marek On Saturday, October 27, 2012 10:20:34 PM UTC+2, Marek Šrank wrote: > > When using [org.clojure/clojure "1.5.0-beta1"] in my project.clj, calling: > (doc function) gives me this exception: > > CompilerException java.lang.RuntimeException: Unable to resolve symbol: > doc in this context, compiling:(NO_SOURCE_PATH:1:1) > > And similarly with find-doc, source, javadoc and clojuredocs. > > With clojure 1.5.0-alpha7 or below, it works normally like it always > worked... > > Can this be a bug in a Clojure (or Leiningen)? > > I've found this https://github.com/trptcolin/reply/issues/17 but for me > it works in 1.5.0-alpha7 or below and not in 1.5.0-beta1 so I conclude that > it must be somehow connected with recent changes in Clojure itself... > > Marek > -- 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, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
leiningen: RuntimeException: Unable to resolve symbol: doc in this context
When using [org.clojure/clojure "1.5.0-beta1"] in my project.clj, calling: (doc function) gives me this exception: CompilerException java.lang.RuntimeException: Unable to resolve symbol: doc in this context, compiling:(NO_SOURCE_PATH:1:1) And similarly with find-doc, source, javadoc and clojuredocs. With clojure 1.5.0-alpha7 or below, it works normally like it always worked... Can this be a bug in a Clojure (or Leiningen)? I've found this https://github.com/trptcolin/reply/issues/17 but for me it works in 1.5.0-alpha7 or below and not in 1.5.0-beta1 so I conclude that it must be somehow connected with recent changes in Clojure itself... Marek -- 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, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
