Re: Java Metadata Wrapper
I thought of protocols initially here too, but protocols just define functions, so where would the data live that you want as metadata? A closure over the data? This implies extending the protocol on a per-instance basis, which afaik doesn't exist (cljs design work aside http://dev.clojure.org/display/design/specify+i.e.+reify+for+instances). Some global map? We can't key on arbitrary java objects since the hashcode can change. Is there a key that will work? A var? We can already do that. Maybe there's someplace I'm missing where you could store this data and look it up later via a protocol implementation? -- -- 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: core.async/thread failing silently
I've run this a bunch of times (in BOTH `lein repl` and `java -cp [...] clojure.main`), and have observed both this code printing the OOM exception, and it being silent as you observed. The difference in trials *seems* to be that if I skip the intermediate steps, going straight for the big one - (https://github.com/clojure/core.async/blob/ae37883a10dc9249ac5f204f6900e7bb0dbe1e04/src/main/clojure/clojure/core/async.clj#L381-L382 Maybe whether the error prints or not depends on whether the exception gets raised on the receiving side (the main thread) or the sending side (presumably on an Executor)? On Sunday, December 8, 2013 9:27:44 AM UTC-6, Paul Butcher wrote: > > On 8 Dec 2013, at 14:21, Alex Miller > > wrote: > > If you're starting with lein repl then I would expect errors to be printed > at the console - that's the actual process running the code. It's also > possible that the thread's untaught exception handler doesn't print. I know > that the expectation for async go blocks is that you should catch and > handle any error. Have tried catching Throwable in your thread block and > printing? > > > Yup - that works fine (see below). > > The implication, I guess, is that nrepl doesn't set the default uncaught > exception handler? I find that surprising? > > user=> (require '[clojure.core.async :refer [thread nil > user=> (defn thread-add [x y] > #_=> (thread > #_=> (try > #_=> (if (zero? y) > #_=> x > #_=> (let [t (thread-add (inc x) (dec y))] > #_=> ( #_=> (catch Throwable e (println e) > #'user/thread-add > user=> ( 20 > user=> ( Exception in thread "async-thread-macro-1986" java.lang.OutOfMemoryError: > unable to create new native thread > at java.lang.Thread.start0(Native Method) > at java.lang.Thread.start(Thread.java:691) > at > java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:943) > at > java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java:992) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > > > -- > paul.butcher->msgCount++ > > Silverstone, Brands Hatch, Donington Park... > Who says I have a one track mind? > > http://www.paulbutcher.com/ > LinkedIn: http://www.linkedin.com/in/paulbutcher > Skype: paulrabutcher > > > > > On 8 Dec 2013, at 14:21, Alex Miller > > wrote: > > If you're starting with lein repl then I would expect errors to be printed > at the console - that's the actual process running the code. It's also > possible that the thread's untaught exception handler doesn't print. I know > that the expectation for async go blocks is that you should catch and > handle any error. Have tried catching Throwable in your thread block and > printing? > > -- > -- > 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 unsubscribe from this group and stop receiving emails from it, send an > email to clojure+u...@googlegroups.com . > For more options, visit https://groups.google.com/groups/opt_out. > > > -- -- 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: Removing the 5th, 10th, 15th ... element of a list
Sounds almost like a mirror image of `clojure.core/take-nth`, so something like this is kind of fun: (defn drop-nth [n coll] (lazy-seq (when-let [s (seq coll)] (concat (take (dec n) s) (drop-nth n (drop n s)) On Tuesday, February 17, 2015 at 1:21:20 PM UTC-6, Cecil Westerhof wrote: > > What is the best way to remove all elements which position (counting from > 1) is a multiply of five out of a list? > > So the list: > (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21) > becomes: > (1 2 3 4 6 7 8 9 11 12 13 14 16 17 18 19 21) > > -- > Cecil Westerhof > -- 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/d/optout.
Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?
I can heartily recommend Java Performance: The Definitive Guide to anyone interested in digging further into all the knobs you can set on the command line: http://www.amazon.com/Java-Performance-The-Definitive-Guide/dp/1449358454 -- 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/d/optout.
Re: Comprehensive lein template list?
Since these projects have to be named lein-template, you can actually get the full list via `lein search`, provided you don't need to search non-standard/private repositories. I bumped my :user profile's :search-page-size to 1000, and got this when I ran `lein search lein-template`: https://gist.github.com/trptcolin/11309006 These could be cleaned up a bit to make it easier to review them (e.g. unique by version; links to repos where applicable), but this should be a good starting point. On Friday, April 25, 2014 5:49:47 PM UTC-5, puzzler wrote: > > Is there a list somewhere of the various lein templates? > > I'm especially interested in comparing the templates for clojure web > development and/or clojurescript. > > The few I've sampled exhibit a wide variety of philosophies in terms of > whether to be minimalist or batteries-included (and which batteries are > included). So a summary would be extremely useful. > > Thanks, > > Mark > -- 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/d/optout.
Re: Leiningen Clojure REPL in Windows doesn't accept arrow keys.
It's due to jline not handling virtual key codes on Windows (which fails in some [all?] non-US locales). This has been fixed on jline master by https://github.com/jline/jline2/pull/134, but there's no jline release available yet. It'll be in the next REPLy release, even if I need to depend on a version I release to clojars (which I've done before since jline's release process moves slower than mine). And we'll try to get it into the next lein release. On Sunday, May 4, 2014 10:36:05 AM UTC-5, Taegyoon Kim wrote: > > I'm in Windows 7. > Not only me: REPL-y bug | https://github.com/trptcolin/reply/issues/121 > > Google search | > https://www.google.com/#q=windows+7+lein+repl+arrow&safe=off > > > 2014년 5월 5일 월요일 오전 12시 26분 49초 UTC+9, George Oliver 님의 말: > >> Arrow keys (left/right movement and up for history) on my lein repl in >> Windows XP works fine. Sounds like something on your system. >> > -- 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/d/optout.
Re: Defs with %
Yeah the latter version parses as 2 symbols in sjacket, whereas the defn
version parses as a single list.
user=> (p/parser "top%")
#net.cgrand.parsley.Node{:tag :net.cgrand.sjacket.parser/root, :content
[#net.cgrand.parsley.Node{:tag :symbol, :content
[#net.cgrand.parsley.Node{:tag :name, :content ["top"]}]}
#net.cgrand.parsley.Node{:tag :symbol, :content
[#net.cgrand.parsley.Node{:tag :name, :content ["%"]}]}]}
REPLy uses sjacket to split input expressions and send them each off to
nREPL in sequence, IIRC so that you get all results back from stuff like:
user=> 1 2 3
1
2
3
So it treats the "top%" input basically the same as if there were
intervening whitespace, like "top %".
>From http://clojure.org/reader:
-
Symbols begin with a non-numeric character and can contain alphanumeric
characters and *, +, !, -, _, and ? (other characters will be allowed
eventually, but not all macro characters have been determined). '/' has
special meaning, it can be used once in the middle of a symbol to separate
the namespace from the name, e.g. my-namespace/foo. '/' by itself names the
division function. '.' has special meaning - it can be used one or more
times in the middle of a symbol to designate a fully-qualified class name,
e.g. java.util.BitSet, or in namespace names. Symbols beginning or ending
with '.' are reserved by Clojure. Symbols containing / or . are said to be
'qualified'. Symbols beginning or ending with ':' are reserved by Clojure.
A symbol can contain one or more non-repeating ':'s.
-
So it looks to me like that function name is illegal, and it's an
implementation detail that it currently is allowed to work.
Usually parsing fixes for lein repl belong in sjacket
(https://github.com/cgrand/sjacket/issues), but I'm not 100% convinced the
parser should say top% is a legitimate symbol. But I'm also not convinced
it should ever be possible for 2 symbols to be right next to each other
with no intervening whitespace. Not sure what the right thing to do is
here. Let's discuss further in an issue on sjacket.
Short-term workaround: `(do top%)`.
On Tuesday, June 17, 2014 9:54:25 AM UTC-5, daveray wrote:
>
> I believe this is a problem with the Leiningen REPL. It works fine from
> the built-in REPL:
>
> $ java -jar ~/.m2/repository/org/clojure/clojure/1.5.1/clojure-1.5.1.jar
> Clojure 1.5.1
> user=> (def top% 4)
> #'user/top%
> user=> top%
> 4
>
> Dave
>
>
>
>
> On Tue, Jun 17, 2014 at 1:32 AM, Mike Thompson > wrote:
>
>> At the REPL ...
>>
>>
>> user=> (def top% 4) ;; an unusually named var
>> #'user/top%
>>
>> But later, it I try to use this var, trouble ...
>>
>> user=> top%
>>
>> CompilerException java.lang.RuntimeException: Unable to resolve symbol:
>> top in this context,
>> compiling:(Local\Temp\form-init6773082655831127234.clj:1:734)
>> CompilerException java.lang.RuntimeException: Unable to resolve symbol: %
>> in this context,
>> compiling:(Local\Temp\form-init6773082655831127234.clj:1:734)
>>
>>
>> Not sure what to make if this. Obviously % is a bit special. And it is
>> certainly not a significant problem for me, at all. Just seemed odd that
>> I'm allowed to successfully do the def, if it is just going to cause
>> problems later.
>>
>> --
>>
>> Mike
>>
>>
>>
>>
>>
>> --
>> 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 unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
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/d/optout.
Re: How can I remove the nils in the result?
Thanks, I had fun with this! This isn't more concise, but I went in a little a different direction, trying to pull the various concerns apart. In particular I had fun separating: - the idea of intervals for which any predicate passed from the specific case of 0/1 equality comparison - the string representation of intervals from their computation - the idea of one-indexing from the rest of the problem https://gist.github.com/trptcolin/a573561ac9262092f254 - Colin p.s. There was no need for me to use `juxt` in `format-interval` but honestly, if you're not going to use `juxt` at every conceivable opportunity, why bother? On Monday, December 22, 2014 10:09:06 PM UTC-6, Pauli wrote: > > Hi, all: > > I'm tring to solve such a problem: Given a string consisting of "1" and > "0", find all the locations of "1", and print them in the format of > intervals. > > For example: "00101110101110" => 3, 5-7, 9, 11-13 > > Here is my solution: > > (defn bar [x] > (letfn [(foo [mystr] > (->> > (map-indexed vector mystr) > (filter #(= (second %) \1)) > (map (comp inc first)) > (partition-all 2 1) > (filter #(= 2 (count %)] > (let [y (map #(if (> (- (second %) (first %)) 1) (print (first %) ", " > (second %) "-")) (foo x))] > (print (ffirst y) "-" y (last (last (foo x))) > > > With the code above, I got many nils in the result: > > (bar "00101110101110") => 3 , 5 -nil - (nil nil 7 , 9 -nil 9 , 11 -nil > nil nil nil) 13 > > How can I remove them? > > And, is there any way to make my code more concise? > > > > -- 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/d/optout.
Re: Including the same require/refers in every namespace
On Monday, March 25, 2013 2:26:11 PM UTC-5, Clinton Dreisbach wrote: > This may be a ridiculous idea/question, but: > > I have an application with many namespaces and every single one of > them has the same require/refer statement in the ns to add logging and > string manipulation. Is there a way to have this happen automatically > in the same way that clojure.core is used in every namespace created > with the ns macro? > > As far as I know, the closest thing is https://code.google.com/p/clj-nstools/ - though I haven't tried it with the latest clojure versions. > There's the obvious answer, which is, look at the ns macro and then > write your own macro using it to do this. I'm wondering if this is a > solved problem already, though, since it seems like it would come up a > lot. > > Since every post by law has to have an opinion on Alex Miller: he is a > fine gentleman who runs a tight conference. I didn't get to go this > year to Clojure/West, but I went last year, and it was the best > conference I've ever been to. Don't ever change. > > -- Clinton > -- -- 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: FileNotFoundException when running lein droid new
On Monday, March 25, 2013 4:02:40 PM UTC-5, Scott Thoman wrote:
>
> All,
>
> I figured I'd give the leiningen droid plugin a shot now that I've got a
> few spare moments to mess around with clojure for an android app. However,
> when I attempt to bootstrap a new project, I get the following:
> -
> $ lein --version
> Leiningen 2.1.1 on Java 1.7.0_15 OpenJDK 64-Bit Server VM
>
> $ cat .lein/profiles.clj
> {:user {:plugins [[lein-pprint "1.1.1"]
> [org.clojure/tools.logging "0.2.6"]
> [lein-droid "0.1.0-preview2"]]
> :android {:sdk-path "/opt/android-sdk"}}}
>
> $ jar tvf
> .m2/repository/lein-droid/lein-droid/0.1.0-preview2/lein-droid-0.1.0-preview2.jar
>
> | grep xml
> 2436 Sat Mar 09 21:55:52 EST 2013
> META-INF/maven/lein-droid/lein-droid/pom.xml
>673 Sat Aug 04 00:06:46 EDT 2012 templates/AndroidManifest.xml
>114 Sat Aug 04 00:06:46 EDT 2012 templates/strings.xml
>
> $ lein droid new blah org.something.blah
> java.io.FileNotFoundException: templates/AndroidManifest.xml (No such file
> or directory)
> at java.io.FileInputStream.open(Native Method)
> at java.io.FileInputStream.(FileInputStream.java:138)
> at clojure.java.io$fn__8638.invoke(io.clj:233)
> at clojure.java.io$fn__8577$G__8542__8584.invoke(io.clj:73)
> at clojure.java.io$fn__8650.invoke(io.clj:262)
> at clojure.java.io$fn__8577$G__8542__8584.invoke(io.clj:73)
> at clojure.java.io$fn__8612.invoke(io.clj:169)
> at clojure.java.io$fn__8551$G__8546__8558.invoke(io.clj:73)
> at clojure.java.io$reader.doInvoke(io.clj:106)
> at clojure.lang.RestFn.invoke(RestFn.java:410)
> at leiningen.new.templates$slurp_resource.invoke(templates.clj:29)
> at leiningen.droid.new$renderer$fn__921.doInvoke(new.clj:22)
> at clojure.lang.RestFn.invoke(RestFn.java:423)
> at leiningen.droid.new$new.doInvoke(new.clj:81)
> at clojure.lang.RestFn.invoke(RestFn.java:425)
> at clojure.lang.AFn.applyToHelper(AFn.java:163)
> at clojure.lang.RestFn.applyTo(RestFn.java:132)
> at clojure.core$apply.invoke(core.clj:617)
> at leiningen.droid$execute_subtask.invoke(droid.clj:85)
> at leiningen.droid$droid.doInvoke(droid.clj:74)
> ...
> -
>
> It looks like a simple classpath issue and I'm wondering if something has
> changed with newer versions of lein and its plugin interaction or
> something. I've also verified that the same behavior is present with the
> two prior droid plugin versions (preview1 and beta2).
>
> I'd like to know if anyone has seen this kind of thing and whether it's
> just something silly on my end? If it's not on my end, I'd be glad to poke
> around and fix something if something does, indeed, need a little fixing -
> just wanted to see what other knew before I'd dig into that.
>
> Thanks,
> /stt
>
Yeah, this is a Leiningen compatibility issue, broken in 2.1.0-2.1.1, but
now fixed on lein master. Thanks for bringing it to our attention! We can
do any further discussion at
https://github.com/technomancy/leiningen/issues/1102
- Colin
--
--
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 there a way to use clojure.main/repl from lein?
On Monday, May 27, 2013 12:48:24 PM UTC-5, stuart@gmail.com wrote:
>
> I thought I wanted some of the affordances, but not the nrepl connection
> (e.g. get to reply's standalone eval mode).
>
> But it turns out that for my use case, I don't need any of that, so
> calling clojure.main directly is the right thing.
>
>
Sounds like this is solved, but in case it comes up for anyone else, there
are a couple options to get a non-nREPL REPLy via leiningen. All will
currently require going through trampoline, but we think that's a
historical requirement and a non-trampolined version shouldn't be a big
deal to add if people want to avoid the trampoline.
- in project.clj: `:repl-options {:standalone true}`, and running `lein
trampoline repl`
- or override any existing setting from the command line: `lein update-in
:repl-options assoc :standalone true -- trampoline repl`
I am curious as to the use cases for avoiding nREPL. I know one is Heroku,
where network connections are more restricted. Are there others? Just want
to be sure there's nothing broken that we don't know about. If there are
bugs in REPLy that make people need to bypass it entirely, please let me
know with an issue: https://github.com/trptcolin/reply/issues (though you
may want to look at reply 0.2.0 first, which will be in lein 2.2.0).
- Colin
> Thanks,
> Stu
>
>
> On Mon, May 27, 2013 at 11:27 AM, Laurent PETIT
>
> > wrote:
>
>> Hello,
>>
>> What about
>>
>> lein run -m clojure.main
>>
>> ?
>>
>>
>> 2013/5/27 Stuart Halloway >:
>> > As opposed to tools.nrepl?
>> >
>> > Thanks,
>> > Stu
>> >
>> > --
>> > --
>> > 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 unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to clojure+u...@googlegroups.com .
>> > For more options, visit https://groups.google.com/groups/opt_out.
>> >
>> >
>>
>> --
>> --
>> 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 unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
--
--
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: [pre-ANN] test2, the last Clojure testing framework
On Monday, June 10, 2013 9:20:31 AM UTC-5, tbc++ wrote: > > >> 1) testing recursive functions. I want to test what a recursion STEP > does, not the >> whole function. Can I mock 'recur'? > > You shouldn't need to, pull the body of the loop out as as separate > function, then test that function. > > >> 2) testing sequence, esp. lazy > > For this, I often create a generator function, or do what I suggested for > 1). If your code is functional you should be able to test subsets of a lazy > seq by supplying the correct arguments to your generation function. > > >> 3) IoC typically makes code more testable. What are Clojure > alternatives for IoC? Pass all dependencies as parameters to your function? > > That's exactly what you should do. Functions should be small enough to > only need a few dependencies. If they need more, consider putting them into > a hash-map. > > Some systems like Midje or Speclj have systems for helping with this, but > I have only ever been frustrated with them. In the case of Speclj, > var-redefs are prefered, which assume that you'll have global vars to hold > your state, which is exactly the behavior I try to avoid. > > You can certainly use with-redefs with any testing library/framework, or you can pass dependencies into your production-code functions. I think perhaps I'm missing the detail you're seeing on how using a particular test framework encourages using global vars - can you elaborate? > Midje on the other hand, is a massive pile of macros and DSLs that > so complicate your code that advanced tests are insanely hard to debug. Pop > Quiz: Midje's "fact" and "provided", how are those parsed and executed? I > don't know! It's a black box, and I'd have to go and read the codebase to > understand why they don't work the way I think they should. Because Midje > exposes tests in a custom DSL, you can't approach it as if it was Clojure, > it's a different language with different semantics. > > I want my tests to be in the same language as my code, this is why I tend > to stick with clojure.test. What are tests? Functions. What are assertions? > a simple wrapper around "assert". Simplicity at its finest. Sure, the > library is a bit underpowered, but I've never been frustrated with > clojure.test. And I can't tell you how many dozens of hours I've lost > trying to figure out why Midje doesn't like my test results. > > Oh, and lein-difftestthat's one awesome bit of code. It provides extra > information, and yet doesn't add needless complexity. > > Timothy > > > On Sun, Jun 9, 2013 at 11:22 PM, julianrz > > wrote: > >> This may be a little off topic, but does this, or any other framework, >> solve some testing inconveniences that exist in Clojure and probably other >> functional languages: >> 1) testing recursive functions. I want to test what a recursion STEP >> does, not the whole function. Can I mock 'recur'? >> 2) testing sequence, esp. lazy >> 3) IoC typically makes code more testable. What are Clojure alternatives >> for IoC? Pass all dependencies as parameters to your function? >> >> I wonder if code=data philosophy of Lisp enables some testing techniques >> that are impossible in languages like Java. Typically you can only test a >> function programmatically, not arbitrary code block. But you can probably >> introspect code very easily in Clojure, and test parts, regardless if they >> are functions or not. A test framework could support that in principle... >> >> I found that functional code is harder to separate, which would make it >> harder to test... >> >> Any thoughts? >> Thanks, >> Julian >> >> -- >> -- >> 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 unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+u...@googlegroups.com . >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > > > -- > “One of the main causes of the fall of the Roman Empire was that–lacking > zero–they had no way to indicate successful termination of their C > programs.” > (Robert Firth) > -- -- 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/cl
Re: Multiple args: opts map vs inline arguments
+1 James.
I can't count the number of times I've found myself unrolling an options
map with a dance like this apply / apply concat.
And don't forget that the function itself then has to roll this options map
back up to operate on it, which syntactically isn't all that bad, but it
usually seems like a lot of unnecessary work, when the payoff is just to
omit a set of curly braces. Maybe it's not even that big of a performance
issue, but I find there's a mental overhead for me.
Other considerations:
- If you need two options maps for some reason (maybe one to delegate
elsewhere), one will have to be non-varargs.
- Should the consumer of the function be required to pass *some* options?
If so, using varargs options means even more work to verify that.
I won't go so far as to say that I never use the varargs/unrolled version.
I'm sure they're great if you always call a function with literal values,
like the `(release-sharks 2 :laser-beams true)` example. But I do find them
painful more often than not.
- Colin
On Tuesday, June 18, 2013 5:52:51 AM UTC-5, James Reeves wrote:
>
> I somewhat disagree with the coding standards in certain cases. If you
> have a large number of options, you may find yourself creating the option
> map programmatically. In which case:
>
> (release-sharks 2 options)
>
> Is preferable to:
>
> (apply release-sharks 2 (apply concat options))
>
> - James
>
> On 18 June 2013 06:32, dmirylenka >wrote:
>
>> According, to the library coding standards, the first is better:
>>
>> (release-sharks 2 :laser-beams true); good
>> (release-sharks 2 {:laser-beams true}) ; bad
>>
>> http://dev.clojure.org/display/design/Library+Coding+Standards
>>
>>
>> On Tuesday, June 18, 2013 5:26:15 PM UTC+12, Omer Iqbal wrote:
>>>
>>> Hey folks,
>>>
>>> What'c considered more idiomatic when having multiple, optional
>>> arguments?
>>>
>>> (defn foo1 [a b & args]
>>> (let [opts (apply hash-map args]
>>> ...))
>>>
>>> or
>>>
>>> (defn foo2 [a b opts]
>>> ...)
>>>
>>>
>>> Cheers,
>>> Omer
>>>
>>>
>>> --
>> --
>> 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 unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>
--
--
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: First day with Macros
As Carlo said, we need to keep track of when things are running. Within the context of any given unquote, for instance ~@(for [meth meths] ...), we're actually executing code. So if you don't quote the expression `(~method-name ~args ~@body), you (1) will try to execute the function "method-name" right there, giving the *result* to the reify macro instead of giving the *expression* to reify. The REPL is very helpful when digging into why quoting works the way it does (and `macroexpand-1` / `macroexpand` in particular for using syntax-quoting in macros). One other idea to look at, besides the great ones Gary mentioned, is a blog I did awhile back quoting: http://blog.8thlight.com/colin-jones/2012/05/22/quoting-without-confusion.html - Colin On Tuesday, June 18, 2013 2:47:58 AM UTC-5, Hussein B. wrote: > > I don't get why we have to use a second 'back tick'. I thought one > backtick at the beginning and then we use ~ and ~@ when needed. > > On Tuesday, June 18, 2013 2:09:44 AM UTC+2, Carlo wrote: >> >> I can't speak to the issues that Gary raised, but I can help you with >> your macro. >> >> (defmacro servlet [servlet-name & meths] >> `(reify Servlet >> ~@(for [meth meths] >> (let [[method-name args & body] meth >>method-name (hyphenated->camel-case method-name)] >>`(~method-name ~args ~@body) >> >> The key here is to keep track of when things are run. The `for` must be >> run at compile time in order to generate the code we want, so we have to >> escape it with ~@. The code that the `for` creates (in the form of a list) >> must then be (quasi-)quoted again by the backtick. >> >> Macros certainly take some getting used to. >> >> >> On Tue, Jun 18, 2013 at 8:12 AM, Hussein B. wrote: >> >>> Here is my fourth attempt: >>> >>> (defmacro servlet [servlet-name & meths] >>> `(reify Servlet >>> (for [meth ~meths] >>>(let [[method-name args & body] ~meth >>> camel-case-method-name (hyphenated->camel-case >>> ~method-name)] >>> (camel-case-method-name ~args ~@body) >>> >>> Still it is not working :( >>> >>> How to fix it? >>> >>> On Tuesday, June 18, 2013 12:04:50 AM UTC+2, Gary Trakhman wrote: >>> >>>> Unquoting 'camel-case-method-name' is going to try and replace the >>>> symbol with it's value during compile-time in the context of the macro >>>> itself. >>>> >>>> also, reify isn't going to work if you need a named class to actually >>>> wire up your servlet, for example with a web.xml. Also, consider that >>>> you'll need some AOT compilation for the container to actually see the >>>> servlet class. >>>> >>>> >>>> On Mon, Jun 17, 2013 at 4:38 PM, Hussein B. wrote: >>>> >>>>> Hi, >>>>> >>>>> My target is to have something like this: >>>>> >>>>> (servlet "ArticlesServlet" >>>>> (do-get [this request response] >>>>> (println "Get Request")) >>>>> (do-post [this request response] >>>>> (println "Post Request"))) >>>>> >>>>> >>>>> I started with this: >>>>> >>>>> (defmacro servlet [servlet-name meths] >>>>> `(reify Servlet >>>>> (for [meth ~@meths] >>>>>(let [[method-name params & body] meth >>>>> camel-case-method-name (hyphenated->camel-case >>>>> method-name)] >>>>> (~camel-case-method-name ~@body) >>>>> >>>>> But of course, it is not working :) >>>>> >>>>> I get: >>>>> >>>>> CompilerException java.lang.RuntimeException: Unable to resolve >>>>> symbol: camel-case-method-name in this context >>>>> >>>>> Why? >>>>> >>>>> And of course, feel super free to correct my Macro :) >>>>> >>>>> Thanks for help and time. >>>>> >>>>> -- >>>>> -- >>>>> 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 >>>
Re: Migrating nREPL out of Clojure Contrib
FWIW, as someone who's used and made small contributions to nREPL, I'm fine
with any of the options (leaving it in contrib, forking, rebooting). My
lack of contributions hasn't been due to process around nREPL (my lack of
activity on REPLy [1] can validate that) - more around a lack of direct
pain points to address.
One initial reaction to these options is that it will become harder to
manage versioning & compatibility for nREPL servers/clients if (a) this
leaves contrib [either by forking or rebooting], (b) development continues
on both, ultimately including separate feature sets, and (c) the community
doesn't 100% settle on one of them. We already have versioning to worry
about, it'll just be an additional axis (maven groupId), so not a blocker,
just what I'd call a mild concern.
For my downstream use in REPLy (which is `lein repl` and `boot repl` under
the hood), I've got some long-term ideas (influenced by a great talk Stu
Halloway did last month) about breaking things apart to make it possible to
opt in (and out) of jline, nrepl, socket-repl, etc. dependencies. That kind
of thing could allow integration of either fork, but I haven't thought
through all the pieces and implications. And at any rate, I don't see
myself tackling those anytime soon, but would be happy to have help :)
Just some random thoughts, but generally I don't have a strong inclination
towards / away from any of the options, and would be fine to do what the
project needs w/ regard to my contributions.
- Colin
[1] https://github.com/trptcolin/reply
On Tuesday, July 18, 2017 at 1:03:09 PM UTC-5, Chas Emerick wrote:
>
> To be clear ("well ACTUALLY" :-P), development hasn't ceased, just
> slowed to a trickle. (There are commits this year, so there?) Part of
> that is nREPL being intentionally a slow-moving bit of bedrock for other
> people to build on. That's not to discount my original stipulations (1)
> and (2) ofc.
>
> Forking is obviously easiest. Like I said, anyone can do that anytime.
>
> The benefit to rebooting is to shake off whatever responsibilities or
> constraints are associated with the (eventually prior) copyright
> assignment. What happens to a codebase that is subject to a CA that is
> forked elsewhere? Are future contributions subject to that CA? I assume
> not, but IANAL. Does the "Copyright (c) Rich Hickey" banner that's
> supposed to be on all files stay there permanently? Pretty sure, but
> IANAL. If all of the nontrivial contributors to the project decide they
> want to change the license later, do we also need to obtain Rich's
> assent? I have no idea. Do I want to maintain explanations of the right
> answers to these kinds of questions for a (fork of a) project that's no
> longer within contrib? Most definitely not.
>
> (Parenthetically, it strikes me as very strange for a project to have a
> copyright assignment to an individual that hasn't lodged any commits, at
> least insofar as the project gone "solo". It's interesting that I don't
> have that intuition if the assignee is an org like Apache or whatever, a
> discrepancy that I'll have to think on.)
>
> That was a good question! Answering helped clarify things for me:
> specifically, if I'm going to maintain the project outside of contrib, I
> will reboot it as previously described.
>
> Thanks,
>
> - Chas
>
> On 7/18/2017 13:19, Dan Larkin wrote:
> > Hi Chas!
> >
> > This is great news, I'm glad to hear development will resume. What's the
> downside to just forking? aka why bother rebooting from scratch?
> >
> >
> >> On Jul 18, 2017, at 05:48, Chas Emerick > wrote:
> >>
> >> Hi all,
> >>
> >> I've been approached many, many times over the years (and more
> frequently since the development and inclusion of socket-repl) about the
> potential of moving nREPL[1] out of clojure contrib…either back to its
> original location[2], or under one of the various Clojure community
> organizations. I've generally demurred or ghosted on these suggestions,
> sometimes out of a lack of time/attention, and often out of just not
> wanting to stir the pot. The pace of them has quickened somewhat lately
> though, and I'd like to put the whole topic to bed and hopefully get the
> project to a better footing in the process.
> >>
> >> First, to stipulate a few things:
> >> • nREPL is an essential bit of infrastructure in Clojure
> tooling
> >> • On balance, I have neglected the project in recent years, to
> the detriment of all of the users of the aforementioned tooling.
> >> • On balance, contributors and potential contributors have been
> less involved (or turned away entirely) because of the well-known friction
> that comes with the contrib process and requirements. (tbh, this is a
> factor in #2, though not the majority)
> >> • No one (least of all me) would object to nREPL having its
> contribution process managed through github or gitlab.
> >> So basically every
Re: If a Java function seems to never return, how do I test?
Any chance the thing being thrown was not an Exception, but still a Throwable? e.g. AssertionError would behave in the way you've described here, unless I'm missing some detail - https://docs.oracle.com/javase/7/docs/api/java/lang/AssertionError.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 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/d/optout.
Re: class loaders stack constant grow in REPL
Right, this is because nREPL uses clojure.main/repl each time it does an evaluation. See http://dev.clojure.org/jira/browse/NREPL-31 for a related issue that was addressed by modifying clojure.main/repl. I'm not sure where a fix for this would belong (nREPL or clojure.main), but I went ahead and opened an nREPL JIRA issue to track it: http://dev.clojure.org/jira/browse/NREPL-36 - Colin On Monday, December 10, 2012 2:46:10 AM UTC-6, Vladimir Tsichevski wrote: > > Hi, > > just found that every interaction with Clojure REPL causes one > more DynamicClassLoader put on the Thread context class loader chain. > > Here is how clojure.main/repl beginning looks like: > > (let [cl (.getContextClassLoader (Thread/currentThread))] > (.setContextClassLoader (Thread/currentThread) > (clojure.lang.DynamicClassLoader. cl))) > > And this is how to observe it: > > nREPL server started on port 19987 > REPL-y 0.1.0-beta10 > Clojure 1.4.0 > Exit: Control+D or (exit) or (quit) > Commands: (user/help) > Docs: (doc function-name-here) > (find-doc "part-of-name-here") > Source: (source function-name-here) > (user/sourcery function-name-here) > Javadoc: (javadoc java-object-or-class-here) > Examples from clojuredocs.org: [clojuredocs or cdoc] > (user/clojuredocs name-here) > (user/clojuredocs "ns-here" "name-here") > user=> (defn print-class-loader-stack > ([] > (print-class-loader-stack (.getContextClassLoader > (Thread/currentThread > ([cl] > (if cl >(do > (pprint cl) > (print-class-loader-stack (.getParent cl))) >(println "*Top*" > #_=> #_=> #_=> #_=> #_=> #_=> #_=> #_=> > #'user/print-class-loader-stack > user=> (print-class-loader-stack) > # > # > # > # > # > # > *Top* > nil > user=> 1 > 1 > user=> 1 > 1 > user=> 1 > 1 > user=> 1 > 1 > user=> (print-class-loader-stack) > # > # > # > # > # > # > # > # > # > # > # > *Top* > nil > user=> > -- 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: [ANN] nrepl-transcript
Great idea - and with so little code! On Monday, January 14, 2013 2:58:55 PM UTC-6, Jonas wrote: > > Hi > > I created a middleware for nrepl that saves a transcript of your repl > interactions so you can go back and see what you did. > > https://github.com/jonase/nrepl-transcript > > Feedback welcome! > > Jonas > > -- 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: What is the difference between *source-path* and *file*?
Yeah, there's been a patch in JIRA for that since 2010, and an updated one since October 2012: http://dev.clojure.org/jira/browse/CLJ-196 On Tuesday, February 19, 2013 1:08:22 PM UTC-6, Brian Marick wrote: > > By the way, the doc string for `*file*` is wrong: > > > clojure.core/*file* > > The path of the file being evaluated, as a String. > > > > Evaluates to nil when there is no file, eg. in the REPL. > > > > It actually evaluates to "NO_SOURCE_PATH" > > > Looking for employment as a Clojure programmer > Latest book: /Functional Programming for the Object-Oriented Programmer/ > https://leanpub.com/fp-oo > > -- -- 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: Boolean
On Saturday, April 7, 2012 10:59:00 AM UTC-5, Steven Obua wrote: > > load-node and store-node are custom functions that rely on two other > custom functions serialize and deserialize: > > (defn serialize > "Serializes value, returns a byte array." > [v] > (let [buff (java.io.ByteArrayOutputStream. 1024)] > (with-open [dos (java.io.ObjectOutputStream. buff)] > (.writeObject dos v)) > (.toByteArray buff))) > > (defn deserialize > "Accepts a byte array, returns deserialized value." > [bytes] > (with-open [dis (java.io.ObjectInputStream. >(java.io.ByteArrayInputStream. bytes))] > (.readObject dis))) > > On Saturday, April 7, 2012 4:50:00 PM UTC+1, Aaron Cohen wrote: >> >> On Sat, Apr 7, 2012 at 11:41 AM, Steven Obua wrote: >> >>> --(defrecord >>> >>> M-Node [leaf content]) >>> >>> (def n (M-Node. false "")) >>> >>> (if (:leaf n) "boom" "ok") ;; returns "ok" >>> >>> (def n (load-node (store-node n))) ;; load-node and store-node are just >>> java serialization/deserialization >>> >>> >> Where is load-node coming from? It should be canonicalizing booleans when >> it deserializes, or else it's buggy. >> >> This behavior would have surprised me too, but I suspect the performance tradeoffs of supporting arbitrary Boolean instances in this way have been carefully considered. from http://clojure.org/special_forms#Special Forms--(if test then else?) # (*if* test then else?)Evaluates test. If not the singular values *nil* or * false*, evaluates and yields then, otherwise, evaluates and yields else. If else is not supplied it defaults to*nil*. All of the other conditionals in Clojure are based upon the same logic, that is, *nil* and *false* constitute logical falsity, and everything else constitutes logical truth, and those meanings apply throughout. *if* performs conditional tests of boolean Java method return values without conversion to Boolean. Note that *if* does not test for arbitrary values of java.lang.Boolean, only the singular value * false* (Java's Boolean.FALSE), so if you are creating your own boxed Booleans make sure to use Boolean/valueOf and not the Boolean constructors. # Of course, if you use readBoolean/writeBoolean instead of readObject/writeObject in your serialization, you sidestep the issue. Granted, that'd require some additional code, but it could still be reasonably nice w/ polymorphism via protocols or multimethods. You could also avoid it by using Carbonite (which uses Kryo) instead of working with plain old ObjectInputStreams: https://github.com/revelytix/carbonite - Colin Colin Jones @trptcolin -- 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: Buggy FP behavior with Clojure 1.3
To address the Infinity exception that Sean & AJ are seeing, I think the issue there is that in REPLy / lein repl, we do a `read` of the input, and then `pr-str` the result and send it on to nREPL. So when nREPL goes to re-read the value back in, that's what triggers the compiler error. user=> (pr-str (read-string "1e308")) "1.0E308" user=> (pr-str (read-string "1e309")) "Infinity" ;;; and then across the wire... user=> (eval (read-string "1.0E308")) 1.0E308 user=> (eval (read-string "Infinity")) CompilerException java.lang.RuntimeException: Unable to resolve symbol: Infinity in this context, compiling:(NO_SOURCE_PATH:1) Incidentally, the reason for the full read rather than a dumb send-on-newline strategy is so that we can accumulate multiple lines of a form before sending to nREPL. Round-tripping read/pr-str like this has seemed to work out fine so far, but I'm imagining there may be other edge cases like this that could get tricky. So maybe there's an alternate strategy we can come up with. I'd appreciate suggestions on the Github issue I just opened for it: https://github.com/trptcolin/reply/issues/71 -Colin On Tuesday, June 26, 2012 4:37:56 PM UTC-5, mefesto wrote: > > When I run the repl from leiningen (v2.0.0-preview6) I get the > Infinity exception. But when I run the repl straight from the > clojure.jar it works without error. > > java -jar ~/.m2/repository/org/clojure/clojure/1.4.0/clojure-1.4.0.jar > > AJ > > On Tue, Jun 26, 2012 at 11:25 AM, Armando Blancas > wrote: > > I don't get the exception on 1.4.0: > > > > ~ $ clj > > Clojure 1.4.0 > > user=> 1e309 > > Infinity > > user=> > > > > > > On Monday, June 25, 2012 11:09:14 PM UTC-7, Sean Corfield wrote: > >> > >> On Mon, Jun 25, 2012 at 10:30 PM, dennis zhuang > >> wrote: > >> > Added a postfix "M" to make the number as BigDecimal or "N" as a > >> > BigInteger: > >> > >> Yes... > >> > >> user=> 1e309M > >> 1E+309M > >> > >> The "Infinity" exception seems wrong but clearly using BigDecimal makes > it > >> work. > >> -- > >> Sean A Corfield -- (904) 302-SEAN > >> An Architect's View -- http://corfield.org/ > >> World Singles, LLC. -- http://worldsingles.com/ > >> > >> "Perfection is the enemy of the good." > >> -- Gustave Flaubert, French realist novelist (1821-1880) > > > > -- > > 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 > On Tuesday, June 26, 2012 4:37:56 PM UTC-5, mefesto wrote: > > When I run the repl from leiningen (v2.0.0-preview6) I get the > Infinity exception. But when I run the repl straight from the > clojure.jar it works without error. > > java -jar ~/.m2/repository/org/clojure/clojure/1.4.0/clojure-1.4.0.jar > > AJ > > On Tue, Jun 26, 2012 at 11:25 AM, Armando Blancas > wrote: > > I don't get the exception on 1.4.0: > > > > ~ $ clj > > Clojure 1.4.0 > > user=> 1e309 > > Infinity > > user=> > > > > > > On Monday, June 25, 2012 11:09:14 PM UTC-7, Sean Corfield wrote: > >> > >> On Mon, Jun 25, 2012 at 10:30 PM, dennis zhuang > >> wrote: > >> > Added a postfix "M" to make the number as BigDecimal or "N" as a > >> > BigInteger: > >> > >> Yes... > >> > >> user=> 1e309M > >> 1E+309M > >> > >> The "Infinity" exception seems wrong but clearly using BigDecimal makes > it > >> work. > >> -- > >> Sean A Corfield -- (904) 302-SEAN > >> An Architect's View -- http://corfield.org/ > >> World Singles, LLC. -- http://worldsingles.com/ > >> > >> "Perfection is the enemy of the good." > >> -- Gustave Flaubert, French realist novelist (1821-1880) > > > > -- > > 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 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: slurp on over slow HTTP crashes clojure?
Is this using REPLy / a lein2-previewX repl, by chance? I fixed a memory leak in REPLy yesterday that happened in long-running command scenarios, and could have caused this behavior (see https://github.com/technomancy/leiningen/issues/691 for details). - Colin On Wednesday, July 18, 2012 10:14:24 AM UTC-5, the80srobot wrote: > > Hello, > > I apologize if this isn't the right place to post this. > > I've seen slurp exhibit some very strange behavior when querying a > particular URL at certain times of day - it seems that a call to slurp as > such: > > (slurp "http://support.clean-mx.de/clean-mx/viruses.php?limit=0,150";) > > > will crash clojure if that site is particularly slow to load. Downloading > the same URL using curl succeeds eventually and the download is just over 2 > MB, which shouldn't cause Java to run out of memory, but nevertheless that > is what seems to be happening, as the following is sometimes thrown before > the REPL dies: > > Exception in thread "Thread-12" java.lang.OutOfMemoryError: Java heap space >> Bye for now! > > > I haven't been able to recreate this issue with other URLs. I realize this > isn't much to go on, but has anyone else encountered this problem before? > > -Adam > -- 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: Reader errors with Datomic free
In Leiningen, the reader side is in a different process (owned by
Leiningen, without your project code on the classpath), than the execution
side. So I think you see this error due to classpath separation: the lein
side doesn't have data_readers.clj specification, or the reader functions
defined in the project.
Short-term, you can use `lein trampoline repl` instead of `lein repl` to
fix this, assuming it's the root problem.
I guess we'll need to do some thinking about what reader-side things would
need to change to accommodate custom reader literals in a cross-process
scenario. Simple things like a line consisting of only the reader literal
could be made to work by catching exceptions, but we use the Clojure reader
to decide when the user is done entering input, then pass the plaintext to
the server. So if we're not done with a form when we hit the exception, as
is the case in `(def x #db/id [:db/part.db] )`, we're stuck not knowing
whether the form is really complete or not, only that the reader failed to
read a reader literal.
It seems like ideally we'd have in-hand on the reader side what all the
data_readers.clj files have on the execution side *and* the functions
defining them, but it seems scary to have a server shipping code to execute
directly on the reader side.
Or maybe [hopefully] there's a more elegant solution that I'm missing?
On Wednesday, July 25, 2012 5:02:50 PM UTC-5, tbc++ wrote:
>
> I'm using the new Clojars version of datomic-free:
>
> (defproject clj-lobapp "0.1.0-SNAPSHOT"
> :description "FIXME: write description"
> :url "http://example.com/FIXME";
> :license {:name "Eclipse Public License"
> :url "http://www.eclipse.org/legal/epl-v10.html"}
> :plugins [[lein-localrepo "0.4.0"]]
> :dependencies [[org.clojure/clojure "1.4.0"]
> [com.datomic/datomic "0.8.3335"]])
>
>
> user=> ;; make in memory database
>(use '[datomic.api :only (q db) :as d])
> nil
> user=> (def uri "datomic:mem://matches")
> #'user/uri
> user=> (d/create-database uri)
> true
> user=> (def conn (d/connect uri))
> #'user/conn
> user=>
>
> user=> #db/id [:db.part/db]
> # db/id>
> nil
> user=> *data-readers*
> {base64 #'datomic.codec/base-64-literal, db/fn
> #'datomic.function/construct, db/id #'datomic.db/id-literal}
> user=> (get *data-readers* 'db/id)
> #'datomic.db/id-literal
> user=> ((get *data-readers* 'db/id) :db.part/db)
> UnsupportedOperationException nth not supported on this type: Keyword
> clojure.lang.RT.nthFrom (RT.java:787)
>
> user=> ((get *data-readers* 'db/id) [:db.part/db])
> #db/id[:db.part/db -100]
>
>
>
> What am I missing here?
>
>
> Thanks,
>
> Timothy Baldridge
>
--
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: Odd residual exception behaviour at the repl
It's a bug in reply. I've opened up an issue to get it fixed - thanks for
the report.
https://github.com/trptcolin/reply/issues/80
On Saturday, August 25, 2012 3:06:28 PM UTC-5, John Gabriele wrote:
>
> Ran into something odd. Not sure if it's a bug.
>
> In the repl, if I try `(def x ^{:a 1} 42)`, I get an exception (right,
> since I can't assign metadata to the value 42).
>
> But then after that, if I try something else (say, typing "hi" into
> the repl), I get a 2nd exception message. Here's an example:
>
> ~~~
> user=> (def x ^{:a 1} 42)
> # Metadata can only be applied to IMetas>
>
> #
>
> user=> "hi"
> IllegalArgumentException Metadata can only be applied to IMetas
> clojure.lang.LispReader$MetaReader.invoke (LispReader.java:740)
> RuntimeException Unmatched delimiter: )
> clojure.lang.Util.runtimeException (Util.java:170)
> "hi"
> user=> "hi"
> "hi"
> user=>
> ~~~
>
> This is using lein 2 preview 8, Clojure 1.4, with OpenJDK 1.7.
>
> ---John
>
--
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.contrib.profile crashes
This could be the same issue that Kevin Baribeau has found with clojure.contrib.profile here: https://github.com/richhickey/clojure-contrib/pull/2#issuecomment-1385392 (Yes, we know he needs a CA, etc. - he mentions requesting assembla access before closing that pull request.) TL;DR - might want a long instead of an int? https://github.com/kbaribeau/clojure-contrib/commit/5de52bd488265199fed8af09e7d5d31389492ed9 - Colin -- 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: Idiomatic record construction in 1.3
+1
A further argument in favor of your choices is that p3 and m2 both work
great with higher-order fns, which I didn't immediately find a way to do
with any of the others:
user=> (map (partial apply ->Person) [["bob" "loblaw"] ["stan" "sitwell"]])
(#user.Person{:first "bob", :last "loblaw"} #user.Person{:first "stan",
:last "sitwell"})
user=> (map map->Person [{:first "bob" :last "loblaw"} {:last "stan" :first
"sitwell"}])
(#user.Person{:first "bob", :last "loblaw"} #user.Person{:first "sitwell",
:last "stan"})
Thanks for posting this - I knew there were defrecord changes coming at
some point, but didn't realize they were already in in 1.3. Hooray!
-Colin
--
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 2.0.0-preview1
Yes, it's not supported yet in lein2 because REPL-y doesn't support it yet. But it's definitely on my plate to knock out soon, along with :prompt support, although :repl-* options will likely be collapsed into a :repl-options map. https://github.com/technomancy/leiningen/issues/432 https://github.com/trptcolin/reply/issues/31 -Colin On Friday, March 9, 2012 5:32:33 AM UTC-6, kjeldahl wrote: > > Another problem. I have a ":repl-init myproj.something" in > project.clj . Using "lein repl", that namespace gets pulled in just > fine, but not when I do a "lein2 repl". Any idea why? Looks like it > does not even try to load the namespace until I pull it in inside the > repl manually. > > Thanks, > > Marius K. > > On Mar 9, 5:41 am, Phil Hagelberg wrote: > > Phil Hagelberg writes: > > > Just found a bug that only manifests when you don't have any profiles > > > and are running outside a project. > > > > I released a 2.0.0-preview2 version with this fix. If you are running > > the old preview, running "lein2 upgrade" should take care of it. > > > > thanks, > > Phil -- 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: GSOC Idea: Interactive documentation with autodoc
One thing missing from reply's clojuredocs integration is the ability
to have a local cache of the examples. Currently, we're just making an
API call every time (using the clojuredocs-client library), which is
great for getting off the ground and for having the latest examples,
but not so great for offline work and speed.
I talked very briefly about this at Clojure/West with Lee Hinman
(author of clojuredocs-client) and Zack Kim (of clojuredocs fame), and
it sounded like they're open to this idea and even have ideas about
how it might work. I'm not sure whether it's big or interesting enough
for a GSOC project, or even which projects would be involved, but it's
certainly something I'd like to have.
On Mon, Mar 26, 2012 at 9:09 AM, David Nolen wrote:
> Zack,
>
> Having examples in the Clojure source has come up before and it's probably
> not going to happen. Also the repl-y project that is now integrated into
> lein 2 has this functionality. However I think you're on an interesting
> track as far as how Mathematica works. I don't think anyone has tackled a
> rich interactive REPL with good integrated graphics support (that is also
> interactive). I recall that Chas Emerick and others were interested in this.
>
> David
>
> On Sat, Mar 24, 2012 at 11:10 AM, Zack Maril wrote:
>>
>> Goal of project: Extend (or fork) autodoc such that it can create and run
>> interactive documentation for any project.
>>
>> Example for the take function:
>>
>>
>> take
>>
>> function
>>
>> Usage: (take n coll)
>>
>> Returns a lazy sequence of the first n items in coll, or all items if
>> there are fewer than n.
>>
>> Example:
>> (take 10 (range 20)) Eval!
>> Output:
>> [0 1 2 3 4 5 6 7 8 9]
>> Added in Clojure version 1.0
>> And then the user could change the code in the browser, it would be sent
>> off to the server, and the new user would get the answer back:
>> Example: (take 5 (range 20)) Eval!
>> Output: [0 1 2 3 4]
>>
>> To make this work, autodoc would need to be extended in two major ways:
>> 1. When generating the html, autodoc would look for metadata within
>> each definition. If it found :examples within the data, then it would add in
>> a number of elements and eval buttons prefilled with the given
>> examples.
>> Example definition:
>> (defn take
>>
>> "Returns a lazy sequence of the first n items in coll, or all items if
>> there are fewer than n."
>> {:added "1.0"
>> :static true
>>:examples ['(take 5 (range 10)),'(take 3 (drop 5 (range 1 11)))]}
>> [n coll]
>> (lazy-seq
>> (when (pos? n)
>> (when-let [s (seq coll)]
>> (cons (first s) (take (dec n) (rest s)))
>>
>> 2. Have it ship with a webserver that runs something similar to tryclojure
>> and has all of the routes set up for the documentation to work
>> automagically. A very basic use of clojail. An interesting challenge would
>> be finding a way to get outputs besides text to work (things like charts
>> for incanter).
>>
>> Conceptually, this isn't too hard to imagine as a project. The main brunt
>> of the work would be writing all of the examples for each project. Even
>> then, there are a ton of examples on clojuredocs.org that are under the EPL
>> license. Having interactive documentation would be pretty cool though. The
>> only place I have seen it so far has been in Mathematica, and that was only
>> after you bought the program. If people are interested in this being made,
>> I'll be the first to volunteer as a student.
>>
>> Would people be interested in this as a project for GSOC?
>> -Zack
>>
>> --
>> 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 Dev" group.
> To post to this group, send email to clojure-...@googlegroups.com.
> To unsubscribe from this group, send email to
> clojure-dev+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/clojure-dev?hl=en.
--
Colin Jones
@trptcolin
--
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
