Re: Apparent bug with more than 5000 command line arguments

[Jim]

Although I am still curious as to why it works in the uberjar but not with 
lein run.

On Thursday, October 15, 2015 at 10:52:52 PM UTC-7, Jim wrote:
>
> Yep you are right. I figured it out right after I posted this :)
>
> On Thursday, October 15, 2015 at 10:46:01 PM UTC-7, Andy Fingerhut wrote:
>>
>> James:
>>
>> This sounds to me likely to be known and expected behavior of xargs.  Any 
>> OS has maximum limitations on either number and/or total size of command 
>> line arguments, and xargs is probably invoking multiple JVMs.
>>
>> Here is a portion of the man page for xargs on my Mac:
>>
>> Any arguments specified on the command line are given to utility upon
>>
>>  each invocation, followed by some number of the arguments read from 
>> the
>>
>>  standard input of xargs.  The utility is repeatedly executed until 
>> stan-
>>
>>  dard input is exhausted.
>>
>> Andy
>>
>>
>> On Thu, Oct 15, 2015 at 10:10 PM, James Paton  wrote:
>>
>>> I ran into an apparent bug today when trying to stress test a program I 
>>> wrote. The program was just supposed to tell you both the minimum and 
>>> maximum integers supplied in the command line arguments. I tried using 
>>> xargs to provide thousands of numbers when I encountered this issue. 
>>> However, I can repro it as follows, using Leiningen 2.5.1 and Clojure 
>>> 1.6.0. As you can see, when I do lein run, it prints an exception about 
>>> "Method code too large", but then prints out Hello World. And when I use 
>>> the uberjar, it just prints the output twice.
>>>
>>> jpaton2@jpaton2-mba ~/Projects> lein -v
>>> Leiningen 2.5.1 on Java 1.8.0_60 Java HotSpot(TM) 64-Bit Server VM
>>> jpaton2@jpaton2-mba ~/Projects> lein new app test-args
>>> Generating a project called test-args based on the 'app' template.
>>> jpaton2@jpaton2-mba ~/Projects> cd test-args/
>>> jpaton2@jpaton2-mba ~/P/test-args> lein run
>>> Hello, World!
>>> jpaton2@jpaton2-mba ~/P/test-args> wc -l ../numbers
>>> 7514 ../numbers
>>> jpaton2@jpaton2-mba ~/P/test-args> xargs lein run -- < ../numbers
>>> Exception in thread "main" java.lang.RuntimeException: Method code too 
>>> large!, 
>>> compiling:(/private/var/folders/wd/shmj7jgd7sqbk9wyh8dp0lz1jq62k4/T/form-init6518370413228051607.clj:1:165)
>>> at clojure.lang.Compiler.analyzeSeq(Compiler.java:6651)
>>> at clojure.lang.Compiler.analyze(Compiler.java:6445)
>>> at clojure.lang.Compiler.eval(Compiler.java:6700)
>>> at clojure.lang.Compiler.eval(Compiler.java:6693)
>>> at clojure.lang.Compiler.load(Compiler.java:7130)
>>> at clojure.lang.Compiler.loadFile(Compiler.java:7086)
>>> at clojure.main$load_script.invoke(main.clj:274)
>>> at clojure.main$init_opt.invoke(main.clj:279)
>>> at clojure.main$initialize.invoke(main.clj:307)
>>> at clojure.main$null_opt.invoke(main.clj:342)
>>> at clojure.main$main.doInvoke(main.clj:420)
>>> at clojure.lang.RestFn.invoke(RestFn.java:421)
>>> at clojure.lang.Var.invoke(Var.java:383)
>>> at clojure.lang.AFn.applyToHelper(AFn.java:156)
>>> at clojure.lang.Var.applyTo(Var.java:700)
>>> at clojure.main.main(main.java:37)
>>> Caused by: java.lang.RuntimeException: Method code too large!
>>> at clojure.asm.MethodWriter.getSize(MethodWriter.java:1872)
>>> at clojure.asm.ClassWriter.toByteArray(ClassWriter.java:775)
>>> at clojure.lang.Compiler$ObjExpr.compile(Compiler.java:4450)
>>> at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3904)
>>> at clojure.lang.Compiler.analyzeSeq(Compiler.java:6642)
>>> ... 15 more
>>> Hello, World!
>>> jpaton2@jpaton2-mba ~/P/test-args> lein uberjar
>>> Compiling test-args.core
>>> Created 
>>> /Users/jpaton2/Projects/test-args/target/uberjar+uberjar/test-args-0.1.0-SNAPSHOT.jar
>>> Created 
>>> /Users/jpaton2/Projects/test-args/target/uberjar/test-args-0.1.0-SNAPSHOT-standalone.jar
>>> jpaton2@jpaton2-mba ~/P/test-args> xargs java -jar 
>>> target/uberjar/test-args-0.1.0-SNAPSHOT-standalone.jar < ../numbers
>>> Hello, World!
>>> Hello, World!
>>>
>>> I found, through trial and error, that it appears to be sharding the 
>>> arguments in chunks of 5000, then calling -main once for each chunk. I can 
>>> verify this by using a file with the first 7000 numbers and the following 
>>> program:
>>>
>>> (ns test-args.core
>>>   (:gen-class))
>>>
>>> (defn -main
>>>   [& args]
>>>   (println (apply max (map #(Integer/parseInt %) args
>>>
>>> Using that for my core.clj file, I get the following:
>>>
>>> jpaton2@jpaton2-mba ~/P/test-args> lein uberjar
>>> Compiling test-args.core
>>> Created 
>>> /Users/jpaton2/Projects/test-args/target/uberjar+uberjar/test-args-0.1.0-SNAPSHOT.jar
>>> Created 
>>> /Users/jpaton2/Projects/test-args/target/uberjar/test-args-0.1.0-SNAPSHOT-standalone.jar
>>> jpaton2@jpaton2-mba ~/P/test-args> xargs java -jar 
>>> target/uberjar/test-args-0.1.0-SNAPSHOT-standalone.jar < ../numbers
>>> 4999
>>> 6999
>>>
>>> Curious if this is a known problem and whether anyone can offer insight.
>>>
>>> -- 
>>> You received this message because you are subscribed to t

Re: Apparent bug with more than 5000 command line arguments

[Jim]

Yep you are right. I figured it out right after I posted this :)

On Thursday, October 15, 2015 at 10:46:01 PM UTC-7, Andy Fingerhut wrote:
>
> James:
>
> This sounds to me likely to be known and expected behavior of xargs.  Any 
> OS has maximum limitations on either number and/or total size of command 
> line arguments, and xargs is probably invoking multiple JVMs.
>
> Here is a portion of the man page for xargs on my Mac:
>
> Any arguments specified on the command line are given to utility upon
>
>  each invocation, followed by some number of the arguments read from 
> the
>
>  standard input of xargs.  The utility is repeatedly executed until 
> stan-
>
>  dard input is exhausted.
>
> Andy
>
>
> On Thu, Oct 15, 2015 at 10:10 PM, James Paton  > wrote:
>
>> I ran into an apparent bug today when trying to stress test a program I 
>> wrote. The program was just supposed to tell you both the minimum and 
>> maximum integers supplied in the command line arguments. I tried using 
>> xargs to provide thousands of numbers when I encountered this issue. 
>> However, I can repro it as follows, using Leiningen 2.5.1 and Clojure 
>> 1.6.0. As you can see, when I do lein run, it prints an exception about 
>> "Method code too large", but then prints out Hello World. And when I use 
>> the uberjar, it just prints the output twice.
>>
>> jpaton2@jpaton2-mba ~/Projects> lein -v
>> Leiningen 2.5.1 on Java 1.8.0_60 Java HotSpot(TM) 64-Bit Server VM
>> jpaton2@jpaton2-mba ~/Projects> lein new app test-args
>> Generating a project called test-args based on the 'app' template.
>> jpaton2@jpaton2-mba ~/Projects> cd test-args/
>> jpaton2@jpaton2-mba ~/P/test-args> lein run
>> Hello, World!
>> jpaton2@jpaton2-mba ~/P/test-args> wc -l ../numbers
>> 7514 ../numbers
>> jpaton2@jpaton2-mba ~/P/test-args> xargs lein run -- < ../numbers
>> Exception in thread "main" java.lang.RuntimeException: Method code too 
>> large!, 
>> compiling:(/private/var/folders/wd/shmj7jgd7sqbk9wyh8dp0lz1jq62k4/T/form-init6518370413228051607.clj:1:165)
>> at clojure.lang.Compiler.analyzeSeq(Compiler.java:6651)
>> at clojure.lang.Compiler.analyze(Compiler.java:6445)
>> at clojure.lang.Compiler.eval(Compiler.java:6700)
>> at clojure.lang.Compiler.eval(Compiler.java:6693)
>> at clojure.lang.Compiler.load(Compiler.java:7130)
>> at clojure.lang.Compiler.loadFile(Compiler.java:7086)
>> at clojure.main$load_script.invoke(main.clj:274)
>> at clojure.main$init_opt.invoke(main.clj:279)
>> at clojure.main$initialize.invoke(main.clj:307)
>> at clojure.main$null_opt.invoke(main.clj:342)
>> at clojure.main$main.doInvoke(main.clj:420)
>> at clojure.lang.RestFn.invoke(RestFn.java:421)
>> at clojure.lang.Var.invoke(Var.java:383)
>> at clojure.lang.AFn.applyToHelper(AFn.java:156)
>> at clojure.lang.Var.applyTo(Var.java:700)
>> at clojure.main.main(main.java:37)
>> Caused by: java.lang.RuntimeException: Method code too large!
>> at clojure.asm.MethodWriter.getSize(MethodWriter.java:1872)
>> at clojure.asm.ClassWriter.toByteArray(ClassWriter.java:775)
>> at clojure.lang.Compiler$ObjExpr.compile(Compiler.java:4450)
>> at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3904)
>> at clojure.lang.Compiler.analyzeSeq(Compiler.java:6642)
>> ... 15 more
>> Hello, World!
>> jpaton2@jpaton2-mba ~/P/test-args> lein uberjar
>> Compiling test-args.core
>> Created 
>> /Users/jpaton2/Projects/test-args/target/uberjar+uberjar/test-args-0.1.0-SNAPSHOT.jar
>> Created 
>> /Users/jpaton2/Projects/test-args/target/uberjar/test-args-0.1.0-SNAPSHOT-standalone.jar
>> jpaton2@jpaton2-mba ~/P/test-args> xargs java -jar 
>> target/uberjar/test-args-0.1.0-SNAPSHOT-standalone.jar < ../numbers
>> Hello, World!
>> Hello, World!
>>
>> I found, through trial and error, that it appears to be sharding the 
>> arguments in chunks of 5000, then calling -main once for each chunk. I can 
>> verify this by using a file with the first 7000 numbers and the following 
>> program:
>>
>> (ns test-args.core
>>   (:gen-class))
>>
>> (defn -main
>>   [& args]
>>   (println (apply max (map #(Integer/parseInt %) args
>>
>> Using that for my core.clj file, I get the following:
>>
>> jpaton2@jpaton2-mba ~/P/test-args> lein uberjar
>> Compiling test-args.core
>> Created 
>> /Users/jpaton2/Projects/test-args/target/uberjar+uberjar/test-args-0.1.0-SNAPSHOT.jar
>> Created 
>> /Users/jpaton2/Projects/test-args/target/uberjar/test-args-0.1.0-SNAPSHOT-standalone.jar
>> jpaton2@jpaton2-mba ~/P/test-args> xargs java -jar 
>> target/uberjar/test-args-0.1.0-SNAPSHOT-standalone.jar < ../numbers
>> 4999
>> 6999
>>
>> Curious if this is a known problem and whether anyone can offer insight.
>>
>> -- 
>> 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..

Re: Where I can learn this?

[Bozhidar Batsov]

Just a small clarification - clj-refactor.el is currently an extension for
CIDER, although there are plans to merge at least some of its functionality
in CIDER (or provide similar functionality there out-of-the-box).

On 15 October 2015 at 09:19, Mikhail Malchevskiy  wrote:

> Sure you can =) Here is the public repo of Magnar Sveen (author of the
> "Parens of the Dead"): https://github.com/magnars/.emacs.d.
> Some of the functions are part of the clj-refactor (
> https://github.com/clojure-emacs/clj-refactor.el) which is part of the
> CIDER (https://github.com/clojure-emacs/cider)
> My personal recommendation would be to try Spacemacs (
> https://github.com/syl20bnr/spacemacs) which is great by itself and also
> has very pretty default setup for clojure (you just need to add clojure
> layer)
>
> четверг, 15 октября 2015 г., 4:48:37 UTC+3 пользователь Erlis Vidal
> написал:
>
>> Guys,
>>
>> I've just finished the first episode of "parens of the dead" and was mind
>> blown for what I saw there.
>>
>> http://www.parens-of-the-dead.com/e1.html
>>
>> Have you been near someone that do something cool and you have to ask,
>> "how you did that?" Well, every second on the video I was having that
>> feeling. I don't work much in clojure, just in my spare time, is my dream
>> language, I use it in emacs, but I'm really not using any of the things I
>> saw in the video.
>>
>> - html completion
>> - refactoring (rename, move to function)
>> - adding dependencies and automatic project.clj modificaiton
>>
>> Is there a way I can learn what emacs packages was used for all that?
>>
>> I know this is not a clojure question but I'll die to have a screencast
>> that teach all those keystrokes and reveal the real power of emacs +
>> clojure.
>>
>> It was really nice to see the mouse in the middle of the screen and not
>> moving at all. :D
>>
>> Thanks for sharing! In just 11 minutes you empowered my Clojure passion
>> even more!
>>
>> Erlis
>>
> --
> 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.
>

-- 
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: Apparent bug with more than 5000 command line arguments

[Andy Fingerhut]

James:

This sounds to me likely to be known and expected behavior of xargs.  Any
OS has maximum limitations on either number and/or total size of command
line arguments, and xargs is probably invoking multiple JVMs.

Here is a portion of the man page for xargs on my Mac:

Any arguments specified on the command line are given to utility upon

 each invocation, followed by some number of the arguments read from the

 standard input of xargs.  The utility is repeatedly executed until
stan-

 dard input is exhausted.

Andy


On Thu, Oct 15, 2015 at 10:10 PM, James Paton  wrote:

> I ran into an apparent bug today when trying to stress test a program I
> wrote. The program was just supposed to tell you both the minimum and
> maximum integers supplied in the command line arguments. I tried using
> xargs to provide thousands of numbers when I encountered this issue.
> However, I can repro it as follows, using Leiningen 2.5.1 and Clojure
> 1.6.0. As you can see, when I do lein run, it prints an exception about
> "Method code too large", but then prints out Hello World. And when I use
> the uberjar, it just prints the output twice.
>
> jpaton2@jpaton2-mba ~/Projects> lein -v
> Leiningen 2.5.1 on Java 1.8.0_60 Java HotSpot(TM) 64-Bit Server VM
> jpaton2@jpaton2-mba ~/Projects> lein new app test-args
> Generating a project called test-args based on the 'app' template.
> jpaton2@jpaton2-mba ~/Projects> cd test-args/
> jpaton2@jpaton2-mba ~/P/test-args> lein run
> Hello, World!
> jpaton2@jpaton2-mba ~/P/test-args> wc -l ../numbers
> 7514 ../numbers
> jpaton2@jpaton2-mba ~/P/test-args> xargs lein run -- < ../numbers
> Exception in thread "main" java.lang.RuntimeException: Method code too
> large!,
> compiling:(/private/var/folders/wd/shmj7jgd7sqbk9wyh8dp0lz1jq62k4/T/form-init6518370413228051607.clj:1:165)
> at clojure.lang.Compiler.analyzeSeq(Compiler.java:6651)
> at clojure.lang.Compiler.analyze(Compiler.java:6445)
> at clojure.lang.Compiler.eval(Compiler.java:6700)
> at clojure.lang.Compiler.eval(Compiler.java:6693)
> at clojure.lang.Compiler.load(Compiler.java:7130)
> at clojure.lang.Compiler.loadFile(Compiler.java:7086)
> at clojure.main$load_script.invoke(main.clj:274)
> at clojure.main$init_opt.invoke(main.clj:279)
> at clojure.main$initialize.invoke(main.clj:307)
> at clojure.main$null_opt.invoke(main.clj:342)
> at clojure.main$main.doInvoke(main.clj:420)
> at clojure.lang.RestFn.invoke(RestFn.java:421)
> at clojure.lang.Var.invoke(Var.java:383)
> at clojure.lang.AFn.applyToHelper(AFn.java:156)
> at clojure.lang.Var.applyTo(Var.java:700)
> at clojure.main.main(main.java:37)
> Caused by: java.lang.RuntimeException: Method code too large!
> at clojure.asm.MethodWriter.getSize(MethodWriter.java:1872)
> at clojure.asm.ClassWriter.toByteArray(ClassWriter.java:775)
> at clojure.lang.Compiler$ObjExpr.compile(Compiler.java:4450)
> at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3904)
> at clojure.lang.Compiler.analyzeSeq(Compiler.java:6642)
> ... 15 more
> Hello, World!
> jpaton2@jpaton2-mba ~/P/test-args> lein uberjar
> Compiling test-args.core
> Created
> /Users/jpaton2/Projects/test-args/target/uberjar+uberjar/test-args-0.1.0-SNAPSHOT.jar
> Created
> /Users/jpaton2/Projects/test-args/target/uberjar/test-args-0.1.0-SNAPSHOT-standalone.jar
> jpaton2@jpaton2-mba ~/P/test-args> xargs java -jar
> target/uberjar/test-args-0.1.0-SNAPSHOT-standalone.jar < ../numbers
> Hello, World!
> Hello, World!
>
> I found, through trial and error, that it appears to be sharding the
> arguments in chunks of 5000, then calling -main once for each chunk. I can
> verify this by using a file with the first 7000 numbers and the following
> program:
>
> (ns test-args.core
>   (:gen-class))
>
> (defn -main
>   [& args]
>   (println (apply max (map #(Integer/parseInt %) args
>
> Using that for my core.clj file, I get the following:
>
> jpaton2@jpaton2-mba ~/P/test-args> lein uberjar
> Compiling test-args.core
> Created
> /Users/jpaton2/Projects/test-args/target/uberjar+uberjar/test-args-0.1.0-SNAPSHOT.jar
> Created
> /Users/jpaton2/Projects/test-args/target/uberjar/test-args-0.1.0-SNAPSHOT-standalone.jar
> jpaton2@jpaton2-mba ~/P/test-args> xargs java -jar
> target/uberjar/test-args-0.1.0-SNAPSHOT-standalone.jar < ../numbers
> 4999
> 6999
>
> Curious if this is a known problem and whether anyone can offer insight.
>
> --
> 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

Apparent bug with more than 5000 command line arguments

[James Paton]

I ran into an apparent bug today when trying to stress test a program I 
wrote. The program was just supposed to tell you both the minimum and 
maximum integers supplied in the command line arguments. I tried using 
xargs to provide thousands of numbers when I encountered this issue. 
However, I can repro it as follows, using Leiningen 2.5.1 and Clojure 
1.6.0. As you can see, when I do lein run, it prints an exception about 
"Method code too large", but then prints out Hello World. And when I use 
the uberjar, it just prints the output twice.

jpaton2@jpaton2-mba ~/Projects> lein -v
Leiningen 2.5.1 on Java 1.8.0_60 Java HotSpot(TM) 64-Bit Server VM
jpaton2@jpaton2-mba ~/Projects> lein new app test-args
Generating a project called test-args based on the 'app' template.
jpaton2@jpaton2-mba ~/Projects> cd test-args/
jpaton2@jpaton2-mba ~/P/test-args> lein run
Hello, World!
jpaton2@jpaton2-mba ~/P/test-args> wc -l ../numbers
7514 ../numbers
jpaton2@jpaton2-mba ~/P/test-args> xargs lein run -- < ../numbers
Exception in thread "main" java.lang.RuntimeException: Method code too 
large!, 
compiling:(/private/var/folders/wd/shmj7jgd7sqbk9wyh8dp0lz1jq62k4/T/form-init6518370413228051607.clj:1:165)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6651)
at clojure.lang.Compiler.analyze(Compiler.java:6445)
at clojure.lang.Compiler.eval(Compiler.java:6700)
at clojure.lang.Compiler.eval(Compiler.java:6693)
at clojure.lang.Compiler.load(Compiler.java:7130)
at clojure.lang.Compiler.loadFile(Compiler.java:7086)
at clojure.main$load_script.invoke(main.clj:274)
at clojure.main$init_opt.invoke(main.clj:279)
at clojure.main$initialize.invoke(main.clj:307)
at clojure.main$null_opt.invoke(main.clj:342)
at clojure.main$main.doInvoke(main.clj:420)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at clojure.lang.Var.invoke(Var.java:383)
at clojure.lang.AFn.applyToHelper(AFn.java:156)
at clojure.lang.Var.applyTo(Var.java:700)
at clojure.main.main(main.java:37)
Caused by: java.lang.RuntimeException: Method code too large!
at clojure.asm.MethodWriter.getSize(MethodWriter.java:1872)
at clojure.asm.ClassWriter.toByteArray(ClassWriter.java:775)
at clojure.lang.Compiler$ObjExpr.compile(Compiler.java:4450)
at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3904)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6642)
... 15 more
Hello, World!
jpaton2@jpaton2-mba ~/P/test-args> lein uberjar
Compiling test-args.core
Created 
/Users/jpaton2/Projects/test-args/target/uberjar+uberjar/test-args-0.1.0-SNAPSHOT.jar
Created 
/Users/jpaton2/Projects/test-args/target/uberjar/test-args-0.1.0-SNAPSHOT-standalone.jar
jpaton2@jpaton2-mba ~/P/test-args> xargs java -jar 
target/uberjar/test-args-0.1.0-SNAPSHOT-standalone.jar < ../numbers
Hello, World!
Hello, World!

I found, through trial and error, that it appears to be sharding the 
arguments in chunks of 5000, then calling -main once for each chunk. I can 
verify this by using a file with the first 7000 numbers and the following 
program:

(ns test-args.core
  (:gen-class))

(defn -main
  [& args]
  (println (apply max (map #(Integer/parseInt %) args

Using that for my core.clj file, I get the following:

jpaton2@jpaton2-mba ~/P/test-args> lein uberjar
Compiling test-args.core
Created 
/Users/jpaton2/Projects/test-args/target/uberjar+uberjar/test-args-0.1.0-SNAPSHOT.jar
Created 
/Users/jpaton2/Projects/test-args/target/uberjar/test-args-0.1.0-SNAPSHOT-standalone.jar
jpaton2@jpaton2-mba ~/P/test-args> xargs java -jar 
target/uberjar/test-args-0.1.0-SNAPSHOT-standalone.jar < ../numbers
4999
6999

Curious if this is a known problem and whether anyone can offer insight.

-- 
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: [ANN] Clojure 1.8.0-beta1

[Alex Miller]

It would be great to have a ticket and some examples beyond the riddley one 
where this was an issue.

Thanks for trying the beta and giving feedback!

-- 
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: [ANN] Clojure 1.8.0-beta1

[Alex Miller]

It would be great to have a ticket and some examples beyond the riddley one 
where this was an issue.

Thanks for trying the beta and giving feedback!

-- 
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: recombining results from clojure.data/diff

[Sean Johnson]

On Thursday, October 15, 2015 at 5:26:01 PM UTC-4, JvJ wrote:
>
> I just discovered clojure.data/diff, and it's great.  However, I'm not 
> sure how to recombine the results to get back the original.
>
> For instance, if (diff a b) = c, then how can I combine b and c to get 
> back to a?
>
>
Merge them:

(def a {:a 1 :b 2})
(def b {:b 2 :c 3})

(let [[only-a only-b both] (clojure.data/diff a b)]
   (println "original a:" a " is the same as " (merge only-a both))
   (println "original b:" b " is the same as " (merge only-b both)))

Cheers,
Sean
 

-- 
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: [ANN] Clojure 1.8.0-beta1

[Martin Raison]

I migrated a significant Clojure codebase to 1.8.0-beta1, and I had to 
solve issues caused by this IMapEntry/APersistentVector change in several 
places (including the pull request mentioned above). Also wondering about 
the rationale behind this. It's not a huge deal, but it does make some code 
ambiguous (if you have a function that potentially accepts any object, 
including vectors of 2 elements, and you want to do something specific for 
instances of IMapEntry).

I didn't have any other problems apart from this - and I was actually 
migrating from clojure 1.6.0. Great job!



Le jeudi 15 octobre 2015 16:28:16 UTC-7, Mike Rodriguez a écrit :
>
> Someone else looked at the issue on 
> https://github.com/ztellman/riddley/issues/18
>
> This issue makes the current version of riddley, and therefore potemkin, 
> not work on Clojure 1.8 beta1
>
> There is a pull request to fix it at 
> https://github.com/ztellman/riddley/pull/19
>
> However I am wondering if it is going to affect more places. The problem 
> is that in Clojuee 1.8 APersistentVector now implements IMapEntry 
> (therefore j.u.Map$Entry as well), but it doesn't implement the key or val 
> methods. 
> What is the reason for that change and/or is this a desired side effect of 
> the change?
>
>

-- 
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: [ANN] Clojure 1.8.0-beta1

[Mike Rodriguez]

Someone else looked at the issue on 
https://github.com/ztellman/riddley/issues/18

This issue makes the current version of riddley, and therefore potemkin, not 
work on Clojure 1.8 beta1

There is a pull request to fix it at https://github.com/ztellman/riddley/pull/19

However I am wondering if it is going to affect more places. The problem is 
that in Clojuee 1.8 APersistentVector now implements IMapEntry (therefore 
j.u.Map$Entry as well), but it doesn't implement the key or val methods. 
What is the reason for that change and/or is this a desired side effect of the 
change?

-- 
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.

recombining results from clojure.data/diff

[JvJ]

I just discovered clojure.data/diff, and it's great.  However, I'm not sure 
how to recombine the results to get back the original.

For instance, if (diff a b) = c, then how can I combine b and c to get back 
to 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
--- 
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: Newbie trying HTML parsing

[James Reeves]

On 15 October 2015 at 18:00, Mike  wrote:

(dzx/xml1-> my-zipper dz/descendants)
>
> gives me what appears to be the original zipper structure, which I wasn't
> expecting.  I was expecting a flattened-out seq of the nodes.
>

The dz/descendants function doesn't return a seq of nodes, but a seq of
zippers. Remember, the moment you convert back into an individual node you
lose the capability to go back up the tree. So the descendants are actually
zippers, with the root of each zipper set to a descendant node.

Because you're using xml1-> and not xml->, you only get the first result of
the seq. This is why it looks like it just returns the original zipper, but
it actually returns the first descendent zipper.

If you want to get a list of all the descendants as nodes, you need to use
xml->, and put clojure.zip/node on the end:

  (dzx/xml-> my-zipper dz/descendants z/node)



> (dzx/xml1-> my-zipper :html)
>
> returns *nil*, which I *really *wasn't expecting.  Examples on the web
> led me to believe that this last call should match on the html tag.  Can
> anyone provide any explanation on these call and why I got these return
> values?
>

This is because you're searching the children of the current node. So
you're looking for a html tag inside a html tag.

These should return non-nil values:

  (dzx/xml1-> my-zipper :head)
  (dzx/xml1-> my-zipper :body)

If you want to find your input:

  (dzx/xml1-> my-zipper :body :input z/node)

Or to do a descendant search:

  (dzx/xml1-> my-zipper dz/descendants :input z/node)

- James

-- 
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: Newbie trying HTML parsing

[Mike]

>
> I've read the clojure.data.xml.zip docs carefully and looked at many 
> examples, but I don't understand this behavior:
>
 
(require '[clj-http.client :as client]
 '[clojure.zip :as z]
 '[clojure.data.zip :as dz]
 '[clojure.data.zip.xml :as dzx]
 '[crouton.html :as html])
(def my-html "\n\n\n\n")
(def my-zipper (z/xml-zip (html/parse-string my-html)))
(dzx/xml1-> my-zipper)
(dzx/xml1-> my-zipper dz/descendants)
(dzx/xml1-> my-zipper :html)

 I am starting with this so that I can understand step-by-step what is 
happening here.  I built a simple HTML string, converted it into an XML 
zipper and then tried a few *xml1 *calls on it:

(dzx/xml1-> my-zipper)

gives me the original zipper, which is what I expected.

(dzx/xml1-> my-zipper dz/descendants)

gives me what appears to be the original zipper structure, which I wasn't 
expecting.  I was expecting a flattened-out seq of the nodes.

(dzx/xml1-> my-zipper :html)

returns *nil*, which I *really *wasn't expecting.  Examples on the web led 
me to believe that this last call should match on the html tag.  Can anyone 
provide any explanation on these call and why I got these return values?



-- 
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: Tessel and ClojureScript

[Mimmo Cosenza]

I never used tessel, but we run class/nodejs on a bunch of similar products. 
Probably you have to verify the compatibility of the nodejs version. Eventually 
you could recompile the one the fit cljs. 

and yes, you’ll have a lot, really a lot of fun too.

mimmo

> On 15 Oct 2015, at 03:11, Erlis Vidal  wrote:
> 
> This question is for the clojurescript guys. 
> 
> Do you think it's possible to code the Tessel (https://tessel.io/ 
> ) using ClojureScript? 
> 
> I really want to have fun :) 
> 
> -- 
> 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 
> .

-- 
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.