Re: Which is the most idiomatic way to go

[Ryan]

Ah! Got what you mean, thanks a lot :)

On Tuesday, March 26, 2013 3:52:39 AM UTC+2, Herwig Hochleitner wrote:
>
> 2013/3/25 Ryan >
>
>> Thanks for your input Herwig.
>>
>> When talking to a database, there might already be record and 
>>> list-of-records interface, for step 2.
>>
>>
>> I didn't fully understand what you meant with that. Can you please 
>> explain? 
>>
>
> For example clojure.java.jdbc/insert! [1] can take a number of record 
> maps, to be inserted into a table.
> Datomic's transact [2] can also take a list of maps, that are interpreted 
> as additions of facts to an entity.
> I imagine similar interfaces exist for various no-sql systems.
>
> The hint was, that given those interfaces, your step 2 might just be 
> another functional transformation, continuing into a single call to an 
> update! function of your db system.
>
> [1] http://clojure.github.com/java.jdbc/#clojure.java.jdbc/insert!
> [2] http://docs.datomic.com/clojure/index.html#datomic.api/transact
>
>

-- 
-- 
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: why am I hitting the 64k method limit on a var?

[Marko Topolnik]

What exactly is getting compiled into a class here? Not the map itself, I 
believe; that wouldn't even cause this error.

>From general clues, the code that builds your config map is being compiled 
into a method. Without AOT compilation this shouldn't be happening, but I'm 
surprised it's happening even with AOT.

-marko

On Monday, March 25, 2013 10:35:33 PM UTC+1, David Powell wrote:
>
> You might be better off putting the config into a file, and then 
> "read"-ing it.  That way it never gets compiled into a class, and just 
> stays as a data structure.
>
> On Mon, Mar 25, 2013 at 9:23 PM, larry google groups 
> 
> > wrote:
>
>> Are vars subject to Java's 64k limit on methods? I started an app a few 
>> months ago and I was putting all the config into into a var:
>>
>> (def app-config 
>> {
>>  :cites {
>>;; more here
>>}
>>
>>  :slides {
>>;; more here
>>}
>>  :questions {
>>;; more here
>>}
>> }
>>
>>
>> Then I guess I added too much and I started getting the error regarding 
>> the 64k limit. Is this expected? 
>>
>> Why can I add more than 64k to a var, but I can not define it that way at 
>> compile 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
>> 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: why am I hitting the 64k method limit on a var?

[David Powell]

On Tue, Mar 26, 2013 at 10:40 AM, Marko Topolnik
wrote:

> What exactly is getting compiled into a class here? Not the map itself, I
> believe; that wouldn't even cause this error.
>
> From general clues, the code that builds your config map is being compiled
> into a method. Without AOT compilation this shouldn't be happening, but I'm
> surprised it's happening even with AOT.
>

Java classes can contain code, and primitive constants, everything else,
even array initialisers in Java, have to be compiled into initialiser code
that builds the data-structure.

I'd guess that this would be a pretty big map to run to over 64k though -
though I think Clojure has a single initialiser method that initialises all
vars in the namespace, so it is tha total that is important.

I think AOT is irrelevant - the same classes get compiled whether they are
AOT'd or not.

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

JIT Compiler crash on IBM JDK 6

[Paudi Moriarty]

Hi,

I'm hitting a JIT compiler bug in IBM JDK 6 with the following code 
(forcing JIT compilation using -Xjit:count=0):

(defprotocol FooProtocol
  (do-something [x]))

(def foo
  (reify FooProtocol
(do-something [this]
  (locking this
(println "XXX")

(do-something foo)

IBM JDK 6 is part of the clojure build matrix (though the last stable build 
is from over a year ago: 
http://build.clojure.org/job/clojure-test-matrix/jdk=IBM%20JDK%201.6/lastStableBuild/
)

I'm committed to supporting the IBM JVM as we are supporting AIX on PowerPC 
where there are no alternatives. For now I have to avoid the locking macro.

The JVM crashes with the following output:

Unhandled exception
Type=Segmentation error vmState=0x0005ff05
J9Generic_Signal_Number=0004 Signal_Number=000b 
Error_Value= Signal_Code=0001
Handler1=7FBD43A7C900 Handler2=7FBD43735FB0 
InaccessibleAddress=0008015F5718
RDI=019C2418 RSI=015F5700 RAX=015F5720 
RBX=015C5378
RCX=0001 RDX= R8= 
R9=0001
R10= R11=015F54D8 R12=015C5AD0 
R13=7FBD1F2E7240
R14=015F5700 R15=019C86F8
RIP=7FBD416E944A GS= FS= RSP=7FBD1F2E7040
EFlags=00210296 CS=0033 RBP=015C5A98 ERR=0004
TRAPNO=000E OLDMASK= CR2=0008015F5718
xmm0 ff00 (f: 0.00, d: 1.385239e-309)
xmm1  (f: 0.00, d: 0.00e+00)
xmm2  (f: 0.00, d: 0.00e+00)
xmm3  (f: 0.00, d: 0.00e+00)
xmm4  (f: 0.00, d: 0.00e+00)
xmm5  (f: 0.00, d: 0.00e+00)
xmm6  (f: 0.00, d: 0.00e+00)
xmm7  (f: 0.00, d: 0.00e+00)
xmm8  (f: 0.00, d: 0.00e+00)
xmm9  (f: 0.00, d: 0.00e+00)
xmm10 00ff (f: 16777215.00, d: 8.289046e-317)
xmm11  (f: 0.00, d: 0.00e+00)
xmm12  (f: 0.00, d: 0.00e+00)
xmm13  (f: 0.00, d: 0.00e+00)
xmm14  (f: 0.00, d: 0.00e+00)
xmm15  (f: 0.00, d: 0.00e+00)
Module=/usr/lib/jvm/ibm-java-x86_64-60/jre/lib/amd64/default/libj9jit24.so
Module_base_address=7FBD4162D000

Method_being_compiled=user$reify__27.do_something()Ljava/lang/Object;
Target=2_40_20121024_126067 (Linux 3.0.0-32-generic)
CPU=amd64 (8 logical CPUs) (0x3eba54000 RAM)
--- Stack Backtrace ---
(0x7FBD416E944A [libj9jit24.so+0xbc44a])
(0x7FBD416EB6F3 [libj9jit24.so+0xbe6f3])
(0x7FBD416E7DA0 [libj9jit24.so+0xbada0])
(0x7FBD416E8060 [libj9jit24.so+0xbb060])
(0x7FBD416F4909 [libj9jit24.so+0xc7909])
(0x7FBD416F43C4 [libj9jit24.so+0xc73c4])
(0x7FBD4169F077 [libj9jit24.so+0x72077])
(0x7FBD4169E3EC [libj9jit24.so+0x713ec])
(0x7FBD437356B1 [libj9prt24.so+0x196b1])
(0x7FBD4169DE4D [libj9jit24.so+0x70e4d])
(0x7FBD4169AFF9 [libj9jit24.so+0x6dff9])
(0x7FBD437356B1 [libj9prt24.so+0x196b1])
(0x7FBD4169AD42 [libj9jit24.so+0x6dd42])
(0x7FBD4395F0F6 [libj9thr24.so+0x40f6])
(0x7FBD44F50EFC [libpthread.so.0+0x7efc])
clone+0x6d (0x7FBD44A86F8D [libc.so.6+0xe4f8d])
---

Paudi

-- 
-- 
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: Accessing a resource inside a jar

[Clinton N. Dreisbach]

John,

That appears to be working. Thanks!

-- Clinton

On Tuesday, March 26, 2013 12:04:38 AM UTC-4, John Hume wrote:
>
> It looks like MimetypesFileTypeMap wants a path to a plain file. I can't 
> try this right now, but I think you want the constructor that takes an 
> InputStream. Something like 
> (MimetypesFileTypeMap. (io/input-stream (io/resource "thefile"))) 
> though if you just passed "/thefile" to io/input-stream, that might do it. 
> On Mar 25, 2013 9:08 PM, "Clinton Dreisbach" 
> > 
> wrote:
>
>> My apologies for a simple question, but:
>>
>> I have a very small library I wrote that needs to read a file in its
>> resources/ directory. In the project, this works fine. However, when I
>> package the library as a JAR, it can't find the file. I thought I was
>> following the best practice of getting the file like so:
>>
>> (.getFile (io/resource "mime.types"))
>>
>> "mime.types" is definitely in the JAR; it's at the root.
>>
>> You can see the project at
>> https://github.com/cndreisbach/ring.middleware.mime-extensions and the
>> problem in particular at
>>
>> https://github.com/cndreisbach/ring.middleware.mime-extensions/blob/master/src/ring/middleware/mime_extensions.clj#L12
>> .
>>
>> Am I missing some piece of knowledge about my project.clj? Any help
>> you could give would be very appreciated.
>>
>> Thanks,
>> Clinton Dreisbach
>>
>> --
>> --
>> 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: Clojure/West 2013 videos?

[Rick Beerendonk]

Alex, you are doing a wonderful job with the videos. InfoQ is helping us all by 
making a business out of quality videos. From experience, I know there are 
always people wanting things quicker and cheaper. I bet the same complains will 
be here if the videos are releases in half the time.

Of course I would love to have all videos available now. But it is not normal 
to have (all) videos available at all... So... I am very happy with the current 
situation.

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

GSoC 2013: Only three days left to submit project ideas

[Daniel Solano Gómez]

Hello, all,

There are just three days left to prepare our application for GSoC 2013.
Although we have a number of really good ideas up on our Project Ideas
page , we really
need to do a lot more in order to strengthen our application.

By submitting ideas to the project page, you needn't commit to being a
mentor.  The most important thing is to put together a great list so
that Clojure can participate in this year's GSoC.

Thank you for your help.

Sincerely,

Daniel


signature.asc
Description: Digital signature

Re: JIT Compiler crash on IBM JDK 6

[Thomas]

Hi Paudi,

Which particular version of the IBM JDK are you running (java -version) and 
have you checked if you are running the very latest version?

Thomas


-- 
-- 
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: JIT Compiler crash on IBM JDK 6

[Paudi Moriarty]

Hi Thomas,

This is occuring on every Linux and AIX version I've tried, SR9, SR11 and 
SR12. I tried Java 7 but it seems Clojure is very broken on IBM Java 7. 
Getting ClassFormatErrors when building Clojure itself there!

Paudi

On Tuesday, 26 March 2013 14:38:44 UTC, Thomas wrote:
>
> Hi Paudi,
>
> Which particular version of the IBM JDK are you running (java -version) 
> and have you checked if you are running the very latest version?
>
> Thomas
>
>
>

-- 
-- 
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: why am I hitting the 64k method limit on a var?

[Marko Topolnik]

On Tuesday, March 26, 2013 12:13:54 PM UTC+1, David Powell wrote:

>
> On Tue, Mar 26, 2013 at 10:40 AM, Marko Topolnik 
> 
> > wrote:
>
>> What exactly is getting compiled into a class here? Not the map itself, I 
>> believe; that wouldn't even cause this error.
>>
>> From general clues, the code that builds your config map is being 
>> compiled into a method. Without AOT compilation this shouldn't be 
>> happening, but I'm surprised it's happening even with AOT.
>>
>
> I'd guess that this would be a pretty big map to run to over 64k though - 
> though I think Clojure has a single initialiser method that initialises all 
> vars in the namespace, so it is tha total that is important.
>
> I think AOT is irrelevant - the same classes get compiled whether they are 
> AOT'd or not.
>

Each form is compiled individually and nothing is compiled for the 
namespace as a whole. Whether or not this is true for AOT I'm not sure; for 
:gen-class it is definitely not true.

-marko 

-- 
-- 
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: JIT Compiler crash on IBM JDK 6

[Thomas]

On Tuesday, March 26, 2013 3:19:08 PM UTC, Paudi Moriarty wrote:
>
> Hi Thomas,
>
> This is occuring on every Linux and AIX version I've tried, SR9, SR11 and 
> SR12. I tried Java 7 but it seems Clojure is very broken on IBM Java 7. 
> Getting ClassFormatErrors when building Clojure itself there!
>
> Paudi
>

Interesting, I am now running Java 7 SR4 on Linux X86 (32bit) and haven't 
seen any problems (yet). Older versions of 7 did have problems, but they 
seem to have been fixed.

Thomas 

-- 
-- 
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: JIT Compiler crash on IBM JDK 6

[Paudi Moriarty]

Thanks for that, I'll have a look. Think it was SR3 on x86_64 I tried.

On Tuesday, 26 March 2013 16:09:43 UTC, Thomas wrote:
>
>
>
> On Tuesday, March 26, 2013 3:19:08 PM UTC, Paudi Moriarty wrote:
>>
>> Hi Thomas,
>>
>> This is occuring on every Linux and AIX version I've tried, SR9, SR11 and 
>> SR12. I tried Java 7 but it seems Clojure is very broken on IBM Java 7. 
>> Getting ClassFormatErrors when building Clojure itself there!
>>
>> Paudi
>>
>
> Interesting, I am now running Java 7 SR4 on Linux X86 (32bit) and haven't 
> seen any problems (yet). Older versions of 7 did have problems, but they 
> seem to have been fixed.
>
> Thomas 
>

-- 
-- 
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: Sweet-expressions

[david sheldrick]

I don't like the idea of infix math as a reader macro. Yeah prefix is weird 
to read for complex expressions, but in such rare cases there are ordinary 
macros that let you do infix math. Use them.

An interesting thought I had the other day regarding infix math:
It would be possible for Clojure to provide it's own implementations of the 
basic number classes (Integer, Long, Double, etc) that implement IFn such 
that they take a function and another number and apply themselves and the 
other number to the function.

Then we could just write (2 + 5).

I imagine this has all kinds of downsides regarding optimisation and what 
to do with numbers that get emitted from java code and so forth.

On Monday, 25 March 2013 10:52:23 UTC, poetix wrote:
>
> I really like the look of this:
>
> http://readable.sourceforge.net/
>
> which defines a completely reversible transformation between e.g.
>
> define fibfast(n)
>   if {n < 2}
> n
> fibup(n 2 1 0)
>
> and
>
> (define (fibfast n)
>   (if (< n 2)
> n
> (fibup n 2 1 0)))
>
>
> and wonder how difficult it would be to support it (or something like it) 
> in/for Clojure. A coffeescript-like approach might be a good first step.
>
> Any thoughts?
>
> Dominic
>

-- 
-- 
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: JIT Compiler crash on IBM JDK 6

[Andy Fingerhut]

On Tue, Mar 26, 2013 at 5:21 AM, Paudi Moriarty
wrote:

>
> IBM JDK 6 is part of the clojure build matrix (though the last stable
> build is from over a year ago:
> http://build.clojure.org/job/clojure-test-matrix/jdk=IBM%20JDK%201.6/lastStableBuild/
> )
>

I don't have any suggestions about the crash you are experiencing, but I do
know that the only reason that Clojure fails to build with IBM JDK 6 is due
to a couple of tests failing due to differences in how IBM JDK 6 handles
encoding/decoding of UTF-16.  CLJ-967 has a patch that disables the two
failing tests when building Clojure with IBM JDK 6, but it looks like it
will not be committed.

http://dev.clojure.org/jira/browse/CLJ-967

With those two failing tests disabled, Clojure 1.5.1 builds and the rest
the tests pass just fine with IBM JDK 6.

I haven't found any IBM JDK 7 version that can build Clojure 1.5.1
successfully on Linux (tried SR3 and SR4 this morning with different kinds
of failures with each).

Andy

-- 
-- 
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: why am I hitting the 64k method limit on a var?

[larry google groups]

> I'd guess that this would be a pretty big map to run to over 64k though - 
though 
> I think Clojure has a single initialiser method that initialises all vars 
in the 
> namespace, so it is tha total that is important.


It certainly seems as if it is the whole namespace that is being compiled. 
The startup file was fine for a while, when I had maybe 3k or 4k of data 
that I was holding in a map, which told the software about the different 
types of data it needed to work on. But then my company gave me a list of 
all search node numbers that we have used to structure the way we make 
calls to Solr. The most obvious place for me to put this was in that same 
map, so I could use it to build search queries on the fly, but, as I said, 
I then ran into the 64k limit. 

I guess, moving forward, I will store the data in MongoDb and I will read 
into that var once the app is running. 







On Tuesday, March 26, 2013 7:13:54 AM UTC-4, David Powell wrote:
>
>
>
> On Tue, Mar 26, 2013 at 10:40 AM, Marko Topolnik 
> 
> > wrote:
>
>> What exactly is getting compiled into a class here? Not the map itself, I 
>> believe; that wouldn't even cause this error.
>>
>> From general clues, the code that builds your config map is being 
>> compiled into a method. Without AOT compilation this shouldn't be 
>> happening, but I'm surprised it's happening even with AOT.
>>
>
> Java classes can contain code, and primitive constants, everything else, 
> even array initialisers in Java, have to be compiled into initialiser code 
> that builds the data-structure.
>
> I'd guess that this would be a pretty big map to run to over 64k though - 
> though I think Clojure has a single initialiser method that initialises all 
> vars in the namespace, so it is tha total that is important.
>
> I think AOT is irrelevant - the same classes get compiled whether they are 
> AOT'd or not.
>

-- 
-- 
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: why am I hitting the 64k method limit on a var?

[David Powell]

On Tue, Mar 26, 2013 at 5:48 PM, larry google groups <
lawrencecloj...@gmail.com> wrote:

>
> > I'd guess that this would be a pretty big map to run to over 64k though
> - though
> > I think Clojure has a single initialiser method that initialises all
> vars in the
> > namespace, so it is tha total that is important.
>
>
> It certainly seems as if it is the whole namespace that is being compiled.
> The startup file was fine for a while, when I had maybe 3k or 4k of data
> that I was holding in a map, which told the software about the different
> types of data it needed to work on. But then my company gave me a list of
> all search node numbers that we have used to structure the way we make
> calls to Solr. The most obvious place for me to put this was in that same
> map, so I could use it to build search queries on the fly, but, as I said,
> I then ran into the 64k limit.
>
> I guess, moving forward, I will store the data in MongoDb and I will read
> into that var once the app is running.
>

Yeah, top-level defs get compiled into a *__init.class* class -
you can verify this by AOT compiling then using *javap -c* on the class
file.

Something like:

(def config (read (clojure.java.io/resource "my_file.clj")))


will overcome the limitation

-- 
Dave

-- 
-- 
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: [ANN] Amazonica: Clojure client for the entire AWS api

[Michael Cohen]

Thanks for the comments. I've made the suggested changes such that the AWS 
functions take an optional first parameter map of credentials. But I'm left 
wondering if it should not be required, and just do away with the stateful 
"defcredential" convenience. Thots?



On Monday, March 25, 2013 6:29:49 PM UTC-7, Herwig Hochleitner wrote:
>
> 2013/3/26 James Reeves >
>
>> It looks very interesting, but I'm afraid I really don't like 
>> "defcredential" macro. The Clojure API should really have *less*mutability 
>> than the Java API, not more :)
>>
>
> Agreed! It would be nicer to pass a context to the api functions.
>
> The api functions could be generated such to expect an optional first 
> context argument and otherwise expect a dynamic binding.
> IMO it would also be acceptable to unconditionally take a context 
> argument, because we have doto.
>

-- 
-- 
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: [ANN] Amazonica: Clojure client for the entire AWS api

[Timothy Baldridge]

I'm a bit concerned about all the reflection going on. Am I correct that
the lib does dynamic dispatch at runtime based on both the arity and the
number of arguments? The code looks like it would be painfully slow.
Perhaps the hit is okay if I only want to make a dozen calls a second or
so, but if I wanted more performance it seems like this library would cause
me some problems.

Besides that, I love the idea of an auto generated lib.

Timothy Baldridge


On Tue, Mar 26, 2013 at 12:18 PM, Michael Cohen  wrote:

> Thanks for the comments. I've made the suggested changes such that the AWS
> functions take an optional first parameter map of credentials. But I'm left
> wondering if it should not be required, and just do away with the stateful
> "defcredential" convenience. Thots?
>
>
>
> On Monday, March 25, 2013 6:29:49 PM UTC-7, Herwig Hochleitner wrote:
>>
>> 2013/3/26 James Reeves 
>>
>> It looks very interesting, but I'm afraid I really don't like
>>> "defcredential" macro. The Clojure API should really have *less*mutability 
>>> than the Java API, not more :)
>>>
>>
>> Agreed! It would be nicer to pass a context to the api functions.
>>
>> The api functions could be generated such to expect an optional first
>> context argument and otherwise expect a dynamic binding.
>> IMO it would also be acceptable to unconditionally take a context
>> argument, because we have doto.
>>
>  --
> --
> 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.
>
>
>



-- 
“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/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: [ANN] Amazonica: Clojure client for the entire AWS api

[Michael Cohen]

Well, of course everything is handled via reflection, which has a cost. The 
question is, can you afford the cost. In general, I think most of the AWS 
apis really aren't concerned with performance, e.g. EC2, and you're not 
making (many) repeated calls. If you look at something like DynamoDB 
though, that might be a case where you're quite concerned with performance, 
and potentially making numerous calls. Of course these calls are remote 
calls, so I'd guess that the reflection penalty is much smaller than the 
price you pay going out of process. As with anything though, measurement is 
key. I actually planned on doing some kind of benchmark comparison against 
Jame's excellent rotary . In general 
though I think for AWS reflection would not be an issue.


On Tuesday, March 26, 2013 11:23:29 AM UTC-7, tbc++ wrote:
>
> I'm a bit concerned about all the reflection going on. Am I correct that 
> the lib does dynamic dispatch at runtime based on both the arity and the 
> number of arguments? The code looks like it would be painfully slow. 
> Perhaps the hit is okay if I only want to make a dozen calls a second or 
> so, but if I wanted more performance it seems like this library would cause 
> me some problems. 
>
> Besides that, I love the idea of an auto generated lib.
>
> Timothy Baldridge
>
>
> On Tue, Mar 26, 2013 at 12:18 PM, Michael Cohen 
> 
> > wrote:
>
>> Thanks for the comments. I've made the suggested changes such that the 
>> AWS functions take an optional first parameter map of credentials. But I'm 
>> left wondering if it should not be required, and just do away with the 
>> stateful "defcredential" convenience. Thots?
>>
>>
>>
>> On Monday, March 25, 2013 6:29:49 PM UTC-7, Herwig Hochleitner wrote:
>>>
>>> 2013/3/26 James Reeves 
>>>
>>> It looks very interesting, but I'm afraid I really don't like 
 "defcredential" macro. The Clojure API should really have *less*mutability 
 than the Java API, not more :)

>>>
>>> Agreed! It would be nicer to pass a context to the api functions.
>>>
>>> The api functions could be generated such to expect an optional first 
>>> context argument and otherwise expect a dynamic binding.
>>> IMO it would also be acceptable to unconditionally take a context 
>>> argument, because we have doto.
>>>
>>  -- 
>> -- 
>> 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/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: [ANN] Amazonica: Clojure client for the entire AWS api

[Hugo Duncan]

Michael Cohen  writes:

> Well, of course everything is handled via reflection, which has a cost. The 
> question is, can you afford the cost. 

Or can the cost be confined to compile time...

> In general, I think most of the AWS 
> apis really aren't concerned with performance, e.g. EC2, and you're not 
> making (many) repeated calls. 

> In general though I think for AWS reflection would not be an issue.

I think the dynamic use of reflection would be enough to put me off
using this in something like pallet, for example.

Hugo

-- 
-- 
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: why am I hitting the 64k method limit on a var?

[Marko Topolnik]

On Tuesday, March 26, 2013 6:54:12 PM UTC+1, David Powell wrote:

>
>
> On Tue, Mar 26, 2013 at 5:48 PM, larry google groups 
> 
> > wrote:
>
>>
>> > I'd guess that this would be a pretty big map to run to over 64k though 
>> - though 
>> > I think Clojure has a single initialiser method that initialises all 
>> vars in the 
>> > namespace, so it is tha total that is important.
>>
>>
>> It certainly seems as if it is the whole namespace that is being 
>> compiled. The startup file was fine for a while, when I had maybe 3k or 4k 
>> of data that I was holding in a map, which told the software about the 
>> different types of data it needed to work on. But then my company gave me a 
>> list of all search node numbers that we have used to structure the way we 
>> make calls to Solr. The most obvious place for me to put this was in that 
>> same map, so I could use it to build search queries on the fly, but, as I 
>> said, I then ran into the 64k limit. 
>>
>> I guess, moving forward, I will store the data in MongoDb and I will read 
>> into that var once the app is running. 
>>
>
> Yeah, top-level defs get compiled into a *__init.class* class 
> - you can verify this by AOT compiling then using *javap -c* on the class 
> file.
>

There is no equivalent to this in the case without AOT compilation. In that 
case the evaluation of each def form individually compiles and executes its 
initialization code.

-marko

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

Seeking help with the Leiningen Chocolatey package (Windows)

[Michael Klishin]

Folks who use Leiningen on Windows, Leiningen maintainers need a little bit
of your help.

The Chocolatey Leiningen package maintainer can no longer support it and is
looking
to pass things on:
http://chocolatey.org/packages/leiningen

If you are familiar with Chocolatey, consider helping him out.

Unfortunately, none of the active Leiningen contributors use Windows but
they
definitely don't want Leiningen to suck on it. They also don't want
Chocolatey users
to be stuck on an old preview version. We need a hand or two from Windows
users
with this.

If you want to help, please leave a comment on the Chocolatey package page:
http://chocolatey.org/packages/leiningen

Thank you!
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

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

Apply elements in a vector as arguments to function

[Ryan]

Hello all,

I have been searching and searching on how to do this but I am failing 
miserably. I am trying to do a pretty simply thing actually.

I have the following vector:

[:foo :bar]


and a function that takes keywords as arguments, like so:

(my-function :foo :bar & more)


What i am trying to do is to apply the elements of my vector as arguments 
to the function. How can I achieve this?

Thank you for any replies

-- 
-- 
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: Apply elements in a vector as arguments to function

[Michael Klishin]

2013/3/26 Ryan 

> What i am trying to do is to apply the elements of my vector as arguments
> to the function. How can I achieve this?


user=> (apply (fn [a b] (println a b)) [:a :b])
:a :b
nil

-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

-- 
-- 
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: Apply elements in a vector as arguments to function

[Ryan]

Thanks Michael, but If i am not mistaken, your example only works with a 
vector with two elements. What if we have an unknown number of vector 
elements?
My apologies if that wasn't clear on my first post.

On Tuesday, March 26, 2013 9:38:55 PM UTC+2, Michael Klishin wrote:
>
>
> 2013/3/26 Ryan >
>
>> What i am trying to do is to apply the elements of my vector as arguments 
>> to the function. How can I achieve this?
>
>
> user=> (apply (fn [a b] (println a b)) [:a :b])
> :a :b
> nil
>
> -- 
> MK
>
> http://github.com/michaelklishin
> http://twitter.com/michaelklishin
>  

-- 
-- 
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: Apply elements in a vector as arguments to function

[Marko Topolnik]

Have you tried (apply my-function [:foo :bar]) yet? Because *apply* is 
exactly what you are looking for; to make sure, read its docstring.

On Tuesday, March 26, 2013 8:44:49 PM UTC+1, Ryan wrote:
>
> Thanks Michael, but If i am not mistaken, your example only works with a 
> vector with two elements. What if we have an unknown number of vector 
> elements?
> My apologies if that wasn't clear on my first post.
>
> On Tuesday, March 26, 2013 9:38:55 PM UTC+2, Michael Klishin wrote:
>>
>>
>> 2013/3/26 Ryan 
>>
>>> What i am trying to do is to apply the elements of my vector as 
>>> arguments to the function. How can I achieve this?
>>
>>
>> user=> (apply (fn [a b] (println a b)) [:a :b])
>> :a :b
>> nil
>>
>> -- 
>> MK
>>
>> http://github.com/michaelklishin
>> http://twitter.com/michaelklishin
>>  
>

-- 
-- 
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: Apply elements in a vector as arguments to function

[Alan Thompson]

Apply works for any number of args:

 (apply + [1 2 3 4 5])

He just gave you an example inline function of 2 args since that was the
original example.
Alan Thompson


On Tue, Mar 26, 2013 at 12:44 PM, Ryan  wrote:

> Thanks Michael, but If i am not mistaken, your example only works with a
> vector with two elements. What if we have an unknown number of vector
> elements?
> My apologies if that wasn't clear on my first post.
>
> On Tuesday, March 26, 2013 9:38:55 PM UTC+2, Michael Klishin wrote:
>>
>>
>> 2013/3/26 Ryan 
>>
>>> What i am trying to do is to apply the elements of my vector as
>>> arguments to the function. How can I achieve this?
>>
>>
>> user=> (apply (fn [a b] (println a b)) [:a :b])
>> :a :b
>> nil
>>
>> --
>> MK
>>
>> http://github.com/**michaelklishin 
>> http://twitter.com/**michaelklishin 
>>
>  --
> --
> 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.
>
>
>

-- 
-- 
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: Apply elements in a vector as arguments to function

[Michael Klishin]

2013/3/26 Ryan 

> Thanks Michael, but If i am not mistaken, your example only works with a
> vector with two elements. What if we have an unknown number of vector
> elements?
> My apologies if that wasn't clear on my first post.
>

If your function's signature allows for & rest arguments, it will work. If
not, you will get a wrong arity exception:

user=> (apply (fn [a b] (println a b)) [:a :b :c :d :e])
ArityException Wrong number of args (5) passed to: user$eval353$fn
 clojure.lang.AFn.throwArity (AFn.java:437)

user=> (apply (fn [a b & xs] (println a b)) [:a :b :c :d :e])
:a :b
nil

-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

-- 
-- 
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: Apply elements in a vector as arguments to function

[Max Penet]

You are mistaken :) 

try:

(apply str [:a :b :c])
(apply str [:a :b :c :d :e])

> (doc apply)
-
clojure.core/apply
([f args] [f x args] [f x y args] [f x y z args] [f a b c d & args])
Applies fn f to the argument list formed by prepending intervening 
arguments to args.
nil

On Tuesday, March 26, 2013 8:44:49 PM UTC+1, Ryan wrote:
>
> Thanks Michael, but If i am not mistaken, your example only works with a 
> vector with two elements. What if we have an unknown number of vector 
> elements?
> My apologies if that wasn't clear on my first post.
>
> On Tuesday, March 26, 2013 9:38:55 PM UTC+2, Michael Klishin wrote:
>>
>>
>> 2013/3/26 Ryan 
>>
>>> What i am trying to do is to apply the elements of my vector as 
>>> arguments to the function. How can I achieve this?
>>
>>
>> user=> (apply (fn [a b] (println a b)) [:a :b])
>> :a :b
>> nil
>>
>> -- 
>> MK
>>
>> http://github.com/michaelklishin
>> http://twitter.com/michaelklishin
>>  
>

-- 
-- 
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: Apply elements in a vector as arguments to function

[Alan Thompson]

Essentially, apply just removes the parens (or brackets) from your list of
args and creates the original function call:

(apply  +  [1 2 3])  ->  (+ 1 2 3)

Alan Thompson

On Tue, Mar 26, 2013 at 12:49 PM, Alan Thompson wrote:

> Apply works for any number of args:
>
>  (apply + [1 2 3 4 5])
>
> He just gave you an example inline function of 2 args since that was the
> original example.
> Alan Thompson
>
>
> On Tue, Mar 26, 2013 at 12:44 PM, Ryan  wrote:
>
>> Thanks Michael, but If i am not mistaken, your example only works with a
>> vector with two elements. What if we have an unknown number of vector
>> elements?
>> My apologies if that wasn't clear on my first post.
>>
>> On Tuesday, March 26, 2013 9:38:55 PM UTC+2, Michael Klishin wrote:
>>>
>>>
>>> 2013/3/26 Ryan 
>>>
 What i am trying to do is to apply the elements of my vector as
 arguments to the function. How can I achieve this?
>>>
>>>
>>> user=> (apply (fn [a b] (println a b)) [:a :b])
>>> :a :b
>>> nil
>>>
>>> --
>>> MK
>>>
>>> http://github.com/**michaelklishin 
>>> http://twitter.com/**michaelklishin 
>>>
>>  --
>> --
>> 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.
>>
>>
>>
>
>

-- 
-- 
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: Apply elements in a vector as arguments to function

[Jim - FooBar();]

On 26/03/13 19:28, Ryan wrote:

apply the elements of my vector as arguments to the function


you said it yourself in your first post... :) 'apply' is what you're 
looking for!


Jim

--
--
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: Apply elements in a vector as arguments to function

[Ryan]

Thank you guys for your answer. apply was the first thing I used but I got 
the following error:

java.lang.ClassCastException: clojure.lang.Keyword cannot be cast to 
> clojure.lang.Associative


and i thought i am not going the right way. What i am more specifically 
trying to do is this:

http://sqlkorma.com/docs#select

In the link above, the select example takes a (fields ) function so, I 
made the following wrapper because it was convenient to use in my project:

(defn find-one-row [entity fields-vector where-hash-map]
>   (first (select entity (apply fields fields-vector) (where 
> where-hash-map) (limit 1 


...but it  throws the error i mentioned

If i hardcode the fields like this, it works fine:

(defn find-one-row [entity where-hash-map]
>   (first (select entity (fields :id) (where where-hash-map) (limit 1 


Any ideas?


On Tuesday, March 26, 2013 9:51:34 PM UTC+2, Jim foo.bar wrote:
>
> On 26/03/13 19:28, Ryan wrote: 
> > apply the elements of my vector as arguments to the function 
>
> you said it yourself in your first post... :) 'apply' is what you're 
> looking for! 
>
> Jim 
>

-- 
-- 
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: Apply elements in a vector as arguments to function

[Cedric Greevey]

The docs there seem to imply that fields takes a keyword or a vector,
rather than a keyword or keywords. Try just (fields fields-vector), without
the "apply".


On Tue, Mar 26, 2013 at 4:12 PM, Ryan  wrote:

> Thank you guys for your answer. apply was the first thing I used but I got
> the following error:
>
> java.lang.ClassCastException: clojure.lang.Keyword cannot be cast to
>> clojure.lang.Associative
>
>
> and i thought i am not going the right way. What i am more specifically
> trying to do is this:
>
> http://sqlkorma.com/docs#select
>
> In the link above, the select example takes a (fields ) function so, I
> made the following wrapper because it was convenient to use in my project:
>
> (defn find-one-row [entity fields-vector where-hash-map]
>>   (first (select entity (apply fields fields-vector) (where
>> where-hash-map) (limit 1
>
>
> ...but it  throws the error i mentioned
>
> If i hardcode the fields like this, it works fine:
>
> (defn find-one-row [entity where-hash-map]
>>   (first (select entity (fields :id) (where where-hash-map) (limit 1
>
>
> Any ideas?
>
>
> On Tuesday, March 26, 2013 9:51:34 PM UTC+2, Jim foo.bar wrote:
>>
>> On 26/03/13 19:28, Ryan wrote:
>> > apply the elements of my vector as arguments to the function
>>
>> you said it yourself in your first post... :) 'apply' is what you're
>> looking for!
>>
>> Jim
>>
>  --
> --
> 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.
>
>
>

-- 
-- 
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: Apply elements in a vector as arguments to function

[Jim - FooBar();]

;;from the website you linked
(/fields/  [:firstname  :first]:last  :address.state)
  ;; you can alias a field using a vector of [field alias]

Your vector argument should look like this:
[[:firstname  :first]:last  :address.state]

or like this (if you're not aliasing):

[:firstname  :last  :address.state]

or in your case exactly:
[:id]
[[:id :identity]] ;;with aliasing

is this how your 'fields-vector' looks like?

Jim

ps: I've not looked at the source of 'fields', I may be wrong...




On 26/03/13 20:12, Ryan wrote:
Thank you guys for your answer. apply was the first thing I used but I 
got the following error:


java.lang.ClassCastException: clojure.lang.Keyword cannot be cast
to clojure.lang.Associative


and i thought i am not going the right way. What i am more 
specifically trying to do is this:


http://sqlkorma.com/docs#select

In the link above, the select example takes a (fields ) function 
so, I made the following wrapper because it was convenient to use in 
my project:


(defn find-one-row [entity fields-vector where-hash-map]
  (first (select entity (apply fields fields-vector) (where
where-hash-map) (limit 1 



...but it  throws the error i mentioned

If i hardcode the fields like this, it works fine:

(defn find-one-row [entity where-hash-map]
  (first (select entity (fields :id) (where where-hash-map) (limit
1 



Any ideas?


On Tuesday, March 26, 2013 9:51:34 PM UTC+2, Jim foo.bar wrote:

On 26/03/13 19:28, Ryan wrote:
> apply the elements of my vector as arguments to the function

you said it yourself in your first post... :) 'apply' is what you're
looking for!

Jim

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




--
--
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: Apply elements in a vector as arguments to function

[Ryan]

Ah damn, you are right! Sorry if I wasted anyone's time :)

At least I learned that apply was the way to go in my original post

On Tuesday, March 26, 2013 10:23:10 PM UTC+2, Cedric Greevey wrote:
>
> The docs there seem to imply that fields takes a keyword or a vector, 
> rather than a keyword or keywords. Try just (fields fields-vector), without 
> the "apply".
>
>
> On Tue, Mar 26, 2013 at 4:12 PM, Ryan >wrote:
>
>> Thank you guys for your answer. apply was the first thing I used but I 
>> got the following error:
>>
>> java.lang.ClassCastException: clojure.lang.Keyword cannot be cast to 
>>> clojure.lang.Associative
>>
>>
>> and i thought i am not going the right way. What i am more specifically 
>> trying to do is this:
>>
>> http://sqlkorma.com/docs#select
>>
>> In the link above, the select example takes a (fields ) function so, 
>> I made the following wrapper because it was convenient to use in my project:
>>
>> (defn find-one-row [entity fields-vector where-hash-map]
>>>   (first (select entity (apply fields fields-vector) (where 
>>> where-hash-map) (limit 1 
>>
>>
>> ...but it  throws the error i mentioned
>>
>> If i hardcode the fields like this, it works fine:
>>
>> (defn find-one-row [entity where-hash-map]
>>>   (first (select entity (fields :id) (where where-hash-map) (limit 1 
>>
>>
>> Any ideas?
>>
>>
>> On Tuesday, March 26, 2013 9:51:34 PM UTC+2, Jim foo.bar wrote:
>>>
>>> On 26/03/13 19:28, Ryan wrote: 
>>> > apply the elements of my vector as arguments to the function 
>>>
>>> you said it yourself in your first post... :) 'apply' is what you're 
>>> looking for! 
>>>
>>> Jim 
>>>
>>  -- 
>> -- 
>> 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: Apply elements in a vector as arguments to function

[Jim - FooBar();]

aaa see? always check the docs first and the sources second (if 
available)...I should have done that as well :)


Jim


On 26/03/13 20:28, Ryan wrote:

Ah damn, you are right! Sorry if I wasted anyone's time :)

At least I learned that apply was the way to go in my original post

On Tuesday, March 26, 2013 10:23:10 PM UTC+2, Cedric Greevey wrote:

The docs there seem to imply that fields takes a keyword or a
vector, rather than a keyword or keywords. Try just (fields
fields-vector), without the "apply".


On Tue, Mar 26, 2013 at 4:12 PM, Ryan > wrote:

Thank you guys for your answer. apply was the first thing I
used but I got the following error:

java.lang.ClassCastException: clojure.lang.Keyword cannot
be cast to clojure.lang.Associative


and i thought i am not going the right way. What i am more
specifically trying to do is this:

http://sqlkorma.com/docs#select 

In the link above, the select example takes a (fields )
function so, I made the following wrapper because it
was convenient to use in my project:

(defn find-one-row [entity fields-vector where-hash-map]
  (first (select entity (apply fields fields-vector)
(where where-hash-map) (limit 1 



...but it  throws the error i mentioned

If i hardcode the fields like this, it works fine:

(defn find-one-row [entity where-hash-map]
  (first (select entity (fields :id) (where
where-hash-map) (limit 1 



Any ideas?


On Tuesday, March 26, 2013 9:51:34 PM UTC+2, Jim foo.bar wrote:

On 26/03/13 19:28, Ryan wrote:
> apply the elements of my vector as arguments to the
function

you said it yourself in your first post... :) 'apply' is
what you're
looking for!

Jim

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




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

[GSoC Idea] Program analysis suite, based on Rich Hickey's Codeq

[Rich Morin]

  Category:  Tooling

  Name:  Program analysis suite, based on Rich Hickey's Codeq

  Brief explanation:
  
Rich Hickey, inventor of Clojure and Datomic, created Codeq as a
prototype framework for program analysis.  It harvests multiple
information sources (eg, Git metadata, source code), and stores
the results in a graph database (eg, Datomic).  The results are
thus available for querying, processing, visualization, etc.

Although Codeq is very promising, it is only a proof of concept,
lacking analyzers, a control framework, and presentation tools.
Turning Codeq into a production suite would be a substantial
software engineering effort, with corresponding visibility.  The
student would extend the base that Codeq provides, producing a
compelling and robust example of the power of this approach.

  Expected results:

The suite should be ready for "drop-in" installation in typical
Clojure shops.  It should do continuous harvesting of code bases.
It should extend the current Clojure analyzer to harvest names of
called functions and methods, use of global state, etc.

Stretch goals might include other analyzers (eg, Java), queries
for common use cases, analysis and visualization software, etc.

  Knowledge prerequisites:

Interest in mechanized program analysis.  Experience with Clojure.

  Difficulty:  Medium

  Mentor:  Rich Morin (mechanized documentation enthusiast),
   Tom Faulhaber (author of Autodoc, cl-format, etc.)

 -- 
http://www.cfcl.com/rdmRich Morin
http://www.cfcl.com/rdm/resume r...@cfcl.com
http://www.cfcl.com/rdm/weblog +1 650-873-7841

Software system design, development, and documentation


-- 
-- 
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: Apply elements in a vector as arguments to function

[Ryan]

Well, I did check em but It wasn't clear to me that I could pass a vector; 
I thought that was only for aliasing. Oh well, it happens I guess :)

Thanks again everybody!

On Tuesday, March 26, 2013 10:30:48 PM UTC+2, Jim foo.bar wrote:
>
>  aaa see? always check the docs first and the sources second (if 
> available)...I should have done that as well :)
>
> Jim
>
>
> On 26/03/13 20:28, Ryan wrote:
>  
> Ah damn, you are right! Sorry if I wasted anyone's time :) 
>
>  At least I learned that apply was the way to go in my original post
>
> On Tuesday, March 26, 2013 10:23:10 PM UTC+2, Cedric Greevey wrote: 
>>
>> The docs there seem to imply that fields takes a keyword or a vector, 
>> rather than a keyword or keywords. Try just (fields fields-vector), without 
>> the "apply".
>>  
>>
>> On Tue, Mar 26, 2013 at 4:12 PM, Ryan  wrote:
>>
>>> Thank you guys for your answer. apply was the first thing I used but I 
>>> got the following error: 
>>>
>>>  java.lang.ClassCastException: clojure.lang.Keyword cannot be cast to 
 clojure.lang.Associative
>>>
>>>
>>>  and i thought i am not going the right way. What i am more 
>>> specifically trying to do is this:
>>>
>>>  http://sqlkorma.com/docs#select
>>>
>>>  In the link above, the select example takes a (fields ) function 
>>> so, I made the following wrapper because it was convenient to use in my 
>>> project:
>>>
>>>  (defn find-one-row [entity fields-vector where-hash-map]
   (first (select entity (apply fields fields-vector) (where 
 where-hash-map) (limit 1 
>>>
>>>
>>>  ...but it  throws the error i mentioned
>>>  
>>>  If i hardcode the fields like this, it works fine:
>>>
>>>  (defn find-one-row [entity where-hash-map]
   (first (select entity (fields :id) (where where-hash-map) (limit 
 1 
>>>
>>>
>>>  Any ideas?
>>>  
>>>  
>>> On Tuesday, March 26, 2013 9:51:34 PM UTC+2, Jim foo.bar wrote: 

 On 26/03/13 19:28, Ryan wrote: 
 > apply the elements of my vector as arguments to the function 

 you said it yourself in your first post... :) 'apply' is what you're 
 looking for! 

 Jim 

>>>-- 
>>> -- 
>>> 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: Sweet-expressions

[Gary Verhaegen]

Right now, Clojure is fighting its way to get to Java-like performance
for numerics, and that involves emitting primitive numbers and
operations whenever possible. I'm afraid that would be utterly
incompatible with turning numbers into functions - that would be at
least two levels of indirection (numbers would have to be objects, and
these objects would have to implement IFn).

Nice idea on a conceptual level, though.

On 26 March 2013 18:18, david sheldrick  wrote:
> I don't like the idea of infix math as a reader macro. Yeah prefix is weird
> to read for complex expressions, but in such rare cases there are ordinary
> macros that let you do infix math. Use them.
>
> An interesting thought I had the other day regarding infix math:
> It would be possible for Clojure to provide it's own implementations of the
> basic number classes (Integer, Long, Double, etc) that implement IFn such
> that they take a function and another number and apply themselves and the
> other number to the function.
>
> Then we could just write (2 + 5).
>
> I imagine this has all kinds of downsides regarding optimisation and what to
> do with numbers that get emitted from java code and so forth.
>
> On Monday, 25 March 2013 10:52:23 UTC, poetix wrote:
>>
>> I really like the look of this:
>>
>> http://readable.sourceforge.net/
>>
>> which defines a completely reversible transformation between e.g.
>>
>> define fibfast(n)
>>   if {n < 2}
>> n
>> fibup(n 2 1 0)
>>
>> and
>>
>> (define (fibfast n)
>>   (if (< n 2)
>> n
>> (fibup n 2 1 0)))
>>
>>
>> and wonder how difficult it would be to support it (or something like it)
>> in/for Clojure. A coffeescript-like approach might be a good first step.
>>
>> Any thoughts?
>>
>> Dominic
>
> --
> --
> 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.
>
>

-- 
-- 
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: (load "hello") can't see hello.clj in the current directory.

[stephen jones]

try (load-file "hello.clj")

On Tuesday, March 26, 2013 9:25:43 AM UTC-7, MC Andre wrote:
>
> I tried setting *compile-path* to ".", but Clojure still can't find 
> hello.clj.
>
> Trace:
>
> $ cat hello.clj
> (ns hello
>   (:gen-class))
>
> (defn -main [& args]
>   (println "Hello World!\n"))
>
> $ lein repl
> nREPL server started on port 4902
> 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=> (load "hello")
> FileNotFoundException Could not locate hello__init.class or hello.clj on 
> classpath:   clojure.lang.RT.load (RT.java:432)
>
> System:
>
> * Leiningen 2.0.0-preview10
> * Clojure 1.4.0
> * Java Java 1.7.0_17 Java HotSpot(TM) Client VM
> * Windows XP
>

-- 
-- 
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: (load "hello") can't see hello.clj in the current directory.

[Leif]

I works for me if I run 'lein repl' *outside* of a project.  In that case, 
"" is on the classpath, so "." looks in the current directory.

When you run 'lein repl' *inside* of a project, however, the top-level 
project directory is not on the classpath.  "." in this case probably means 
"look in the root of all directories on the classpath."  (I'm guessing; 
Java experts speak up.)

--Leif

On Tuesday, March 26, 2013 12:25:43 PM UTC-4, MC Andre wrote:
>
> I tried setting *compile-path* to ".", but Clojure still can't find 
> hello.clj.
>
> Trace:
>
> $ cat hello.clj
> (ns hello
>   (:gen-class))
>
> (defn -main [& args]
>   (println "Hello World!\n"))
>
> $ lein repl
> nREPL server started on port 4902
> 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=> (load "hello")
> FileNotFoundException Could not locate hello__init.class or hello.clj on 
> classpath:   clojure.lang.RT.load (RT.java:432)
>
> System:
>
> * Leiningen 2.0.0-preview10
> * Clojure 1.4.0
> * Java Java 1.7.0_17 Java HotSpot(TM) Client VM
> * Windows XP
>

-- 
-- 
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: Seeking advice on a safe way to mock/stub fns

[Leif]

Hi, Allen.

My own version of with-redefs?  That *sounds* kind of hard.  Could you keep 
an atom with the "original" bound value (the first one my-with-redefs sees, 
anyway) and then always roll back to that value?  Something like that?

Thanks,
Leif

On Monday, March 25, 2013 1:58:53 AM UTC-4, Allen Rohner wrote:
>
>
> I've also run into the problem. You could write your own version of 
> with-redefs (it's not that hard). In your case, it sounds like you're not 
> running tests in parallel in the same process, so could you work around it 
> by waiting for your app to finish initializing before running tests? 
>
> Allen
>

-- 
-- 
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: Seeking advice on a safe way to mock/stub fns

[Leif]

Hi, Shantanu.

Thanks for the suggestions.  A couple thoughts:

1. Many times, I seem to stub or mock things that are scattered here and 
there in the code, like things that send email or log metrics, etc.  so 
they are not really isolated (or isolatable??), but I still want to test 
that they get called.
2. So I'm usually mocking utility functions that have side effects.  Am I 
mocking at the right level?
3. For these types of things, even if I make protocols for them, passing 
them all in as arguments seems like it could get messy fast.  E.g. my 
function used to be (f x), but now it's (f x logger emailer metric-logger 
...)
4. I'm not really familiar with the methods you describe, so any 
elaboration on your comments would be welcome.  Or even better, a link to a 
project that uses the designs you mentioned.

Thanks,
Leif

On Monday, March 25, 2013 5:57:34 AM UTC-4, Shantanu Kumar wrote:
>
>
>
> On Monday, 25 March 2013 06:45:32 UTC+5:30, Leif wrote:
>>
>> Hello, fellow Clojurians.
>>
>> One problem I've run into when stubbing fns is that with-redefs doesn't 
>> play well with concurrency.  E.g. 
>> http://clojuredocs.org/clojure_core/clojure.core/with-redefs#example_994  
>> The problem arises because, quoting with-redef's docstring, "These 
>> temporary changes will be visible in all threads."
>>
>> Let's say you're stubbing the fn 'f' with the fn 'stub'.  Here is an 
>> irritating sequence of events:
>> 1:  test1 redefs f to stub, saving the initial fn
>> 2:  test2 redefs f to stub, saving **the current value of f, which is 
>> stub**
>> 3:  test1 completes, resetting f to its initial fn
>> 4:  test2 completes, **resetting f to the stub fn**
>> 5:  test3 starts, expecting the fn f to work normally, and fails
>>
>> We actually ran into the problem because there was a delay in our app's 
>> init fn, and so the first one of our integration tests that ran permanently 
>> rewrote some fns.  I would imagine that this could even happen in unit 
>> tests, though, if your test runner executed tests in parallel.
>>
>> Has anyone run into a similar problem, and come up with a safer way of 
>> stubbing / mocking non-dynamic vars?
>>
>
> If you could design the code around Primatic's Graph: 
> https://github.com/Prismatic/plumbing it may be cleaner and easier to 
> isolate the dependencies, hence making them easy to mock.
>
> Another (lengthier) approach would be to model anything mockable as a 
> protocol, and pass the implementation as function argument. As a bonus, 
> this lets one keep the code mostly unaware of impurity. For production and 
> integration-tests initialize the application at its entry point and 
> instantiate the chain of dependencies, then pass the top level dependencies 
> as function arguments. For unit tests where you need a mock dependency, 
> simply pass a mock implementation of the protocol as a function argument. 
> In cases where the application has several reference types for complex 
> state management, an inside-out design will probably help a lot together 
> with this approach for testing.
>
> Shantanu
>

-- 
-- 
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: Apply elements in a vector as arguments to function

[Michael Klishin]

2013/3/27 Jim - FooBar(); 

> aaa see? always check the docs first and the sources second (if
> available)...I should have done that as well :)


Definitely don't just check the sources and think it's something normal.

Complain loudly to maintainers on this list that their documentation has
gaps and they should
clarify this and that. The idea that people should read the source to get
reasonably straightforward
stuff done is wrong and does a lot of long term damage to the community.
-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

-- 
-- 
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: Seeking advice on a safe way to mock/stub fns

[Shantanu Kumar]

On Wednesday, 27 March 2013 08:06:30 UTC+5:30, Leif wrote:
>
> Hi, Shantanu.
>
> Thanks for the suggestions.  A couple thoughts:
>
> 1. Many times, I seem to stub or mock things that are scattered here and 
> there in the code, like things that send email or log metrics, etc.  so 
> they are not really isolated (or isolatable??), but I still want to test 
> that they get called.
> 2. So I'm usually mocking utility functions that have side effects.  Am I 
> mocking at the right level?
> 3. For these types of things, even if I make protocols for them, passing 
> them all in as arguments seems like it could get messy fast.  E.g. my 
> function used to be (f x), but now it's (f x logger emailer metric-logger 
> ...)
> 4. I'm not really familiar with the methods you describe, so any 
> elaboration on your comments would be welcome.  Or even better, a link to a 
> project that uses the designs you mentioned.
>

I do not have any Open Source application using this technique to share 
now, but I will try to illustrate here. If you have a Ring-based web app, 
you can initialize the app in a middleware, or if you have a command-line 
app then you can initialize in the -main function. The initialization 
function can return a map of mockable implementations, which could be 
either protocol implementations or functions:

(def ^:dynamic *deps* nil)

;; in the Ring middleware or -main fn (using prod config)
(let [deps {:logger (make-logger app-config) ; returns fn
 :emailer (make-emailer app-config)  ; returns fn
 :db-worker (make-db-worker)   ; IDatabase protocol 
impl
 :metric-logger (make-metric-logger app-config)}]
  (binding [*deps* deps] ; compojure route handlers can use *deps*
...))

So, how should the regular functions be defined now? We need to propagate 
the dependencies to all the places that need it.

Earlier version:

;; notice the dependencies: logger, db, email
(defn foo [x]
  (util/logger :debug "Enter")
  (let [p (make-db-payload x)]
(db/write p))
  (let [m (compose-mail "xyz")]
(util/email m))
  (util/logger :debug "Exit"))

New version:

;; deps can be actual services or mocked
(defn foo [x deps]
  ((:logger deps) :debug "Enter")
  (let [p (make-db-payload x)]
(.write (:db-worker deps) p))
  (let [m (compose-mail "xyz")]
((:emailer deps) m))
  ((:logger deps) :debug "Exit"))

This can be streamlined by extracting snippets like (:logger deps) into 
dedicated functions to avoid typos. But yeah, the idea is that deps needs 
to be carried around. In the places where you need to mock something, just 
call as follows:

(let [deps (make-mock-deps)]
  (foo x deps))

So, to answer your question #2, in this approach the code has an inside-out 
design and works at a higher order.

Shantanu

-- 
-- 
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: Seeking advice on a safe way to mock/stub fns

[Shantanu Kumar]

Sorry, in the last illustration, the (binding [*deps* deps] ...) cannot be 
useful for Compojure route handlers because dynamic vars are bound at a 
thread-local level; you will probably have to `alter-var-root` it to some 
var and have the handlers use that static var instead. In the code I write 
personally, I use a static var that I `alter-var-root` so I couldn't see 
the error in dynamic var immediately.

Shantanu

On Wednesday, 27 March 2013 12:16:58 UTC+5:30, Shantanu Kumar wrote:
>
>
>
> On Wednesday, 27 March 2013 08:06:30 UTC+5:30, Leif wrote:
>>
>> Hi, Shantanu.
>>
>> Thanks for the suggestions.  A couple thoughts:
>>
>> 1. Many times, I seem to stub or mock things that are scattered here and 
>> there in the code, like things that send email or log metrics, etc.  so 
>> they are not really isolated (or isolatable??), but I still want to test 
>> that they get called.
>> 2. So I'm usually mocking utility functions that have side effects.  Am I 
>> mocking at the right level?
>> 3. For these types of things, even if I make protocols for them, passing 
>> them all in as arguments seems like it could get messy fast.  E.g. my 
>> function used to be (f x), but now it's (f x logger emailer metric-logger 
>> ...)
>> 4. I'm not really familiar with the methods you describe, so any 
>> elaboration on your comments would be welcome.  Or even better, a link to a 
>> project that uses the designs you mentioned.
>>
>
> I do not have any Open Source application using this technique to share 
> now, but I will try to illustrate here. If you have a Ring-based web app, 
> you can initialize the app in a middleware, or if you have a command-line 
> app then you can initialize in the -main function. The initialization 
> function can return a map of mockable implementations, which could be 
> either protocol implementations or functions:
>
> (def ^:dynamic *deps* nil)
>
> ;; in the Ring middleware or -main fn (using prod config)
> (let [deps {:logger (make-logger app-config) ; returns fn
>  :emailer (make-emailer app-config)  ; returns fn
>  :db-worker (make-db-worker)   ; IDatabase 
> protocol impl
>  :metric-logger (make-metric-logger app-config)}]
>   (binding [*deps* deps] ; compojure route handlers can use *deps*
> ...))
>
> So, how should the regular functions be defined now? We need to propagate 
> the dependencies to all the places that need it.
>
> Earlier version:
>
> ;; notice the dependencies: logger, db, email
> (defn foo [x]
>   (util/logger :debug "Enter")
>   (let [p (make-db-payload x)]
> (db/write p))
>   (let [m (compose-mail "xyz")]
> (util/email m))
>   (util/logger :debug "Exit"))
>
> New version:
>
> ;; deps can be actual services or mocked
> (defn foo [x deps]
>   ((:logger deps) :debug "Enter")
>   (let [p (make-db-payload x)]
> (.write (:db-worker deps) p))
>   (let [m (compose-mail "xyz")]
> ((:emailer deps) m))
>   ((:logger deps) :debug "Exit"))
>
> This can be streamlined by extracting snippets like (:logger deps) into 
> dedicated functions to avoid typos. But yeah, the idea is that deps needs 
> to be carried around. In the places where you need to mock something, 
> just call as follows:
>
> (let [deps (make-mock-deps)]
>   (foo x deps))
>
> So, to answer your question #2, in this approach the code has an 
> inside-out design and works at a higher order.
>
> Shantanu
>

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