Re: (pprint template) gives me an exception

2013-04-16 Thread Tassilo Horn 
larry google groups  writes:

>   (println (pp/pprint template))

Aside from the original problem: pprint already prints to *out* and only
returns nil, so the code above first prints template, and then the
println will also print the nil returned from pprint.

Bye,
Tassilo

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

[ANN] phaser-1.1.2 - A Clojure DSL for the LMAX Disruptor 3.0.1

2013-04-16 Thread Trevor Bernard 
I'd like to officially announce the immediate availability of Phaser, a 
Clojure DSL for the LMAX Disruptor 3.0.1.

https://github.com/userevents/phaser

Pull requests welcome!

-Trev

-- 
-- 
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: invokedynamic instructions in Clojure

2013-04-16 Thread Brandon Bloom 
Do you have any measurements, results, or conclusions to report?

On Tuesday, April 16, 2013 12:12:15 PM UTC-4, Ghadi Shayban wrote:
>
> I've added a very minimal usage of invokedynamic to the compiler.  
> Basically the smallest delta without having to change internals of ObjExpr 
> or break ABI compatibility.  This is minimal and raw.  There are many many 
> usages of indy that will really help the Clojure runtime, this ain't one of 
> them.  No benchmarks here, it's probably slower.
>
> In current Clojure mainline, a Fn has reference slots to any vars it needs 
> in its constant pool, like a cache. Anytime a non-dynamic Var's value needs 
> to be accessed, the Var goes from the constant pool to the stack, and 
> getRawRoot() is invoked on it.
>
> With this change, an invokedynamic instruction instead creates a 
> ConstantCallSite, which closes over a looked-up Var, and then binds the 
> call site to invoke getRawRoot() on it directly.  This is only for 
> non-dynamic Vars.
>
> Simple todos:
> cache the CallSite as a member on the Var itself so that all identical 
> indy lookup instructions have fast bootstrapping.
> emit a similar call for dynamic vars
> remove the emission of Vars into the constant pool of a class
>
> Lots of really interesting use cases for invokedynamic and all the 
> associated combinators in java.lang.invoke:
>
> Better protocol callsite caching
> CallSite "middleware" for things like CLJ specific instrumentation
> equality could be a special instruction
> KeywordCallSite could be its own instruction as well
> (apply) argument "spreading"/varargs array collection (through the 
> combinators)
> potentially removing IFn.invoke(*) and using MethodHandle invocation 
> instead (fat chance)
>
> You can pull down the changes at github.com/ghadishayban/clojure.
> mvn clean package, tested on OpenJDK 1.7
>

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

Warning: *retry-limit* not declared dynamic and thus is not dynamically rebindable

2013-04-16 Thread ljcppunix 
Dear all,

When I installed leiningen and clojure, I run command "lein repl",
then prompt some message like such ---

C:\lein>lein repl
Warning: *default-javac-options* not declared dynamic and thus is not
dynamicall
y rebindable, but its name suggests otherwise. Please either indicate
^:dynamic
*default-javac-options* or change the name.
Warning: *silently* not declared dynamic and thus is not dynamically
rebindable,
 but its name suggests otherwise. Please either indicate ^:dynamic
*silently* or
 change the name.
Warning: *skip-auto-compile* not declared dynamic and thus is not
dynamically re
bindable, but its name suggests otherwise. Please either indicate
^:dynamic *ski
p-auto-compile* or change the name.
Warning: *retry-limit* not declared dynamic and thus is not
dynamically rebindab
le, but its name suggests otherwise. Please either indicate ^:dynamic
*retry-lim
it* or change the name.
REPL started; server listening on localhost:53849.

I think some thing is wrong, and I spent a lot of time and can't solve
these problem,
so ask help for me, thanks very much!

-- 
-- 
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] Linode compromise possibly affecting Clojars

2013-04-16 Thread Phil Hagelberg 

Phil Hagelberg writes:

> If you run a private proxying internal repository for your company, you
> can help us verify checksums. I'll be posting a follow-up soon with some
> code you can use to calculate and publish checksums so we can
> investigate discrepancies.

Update: Hugo Duncan pointed out that the Clojars search indices contain
checksums in them, so I've written a script to verify a repository
against a copy of the index I have from the 22nd of April.

  
https://github.com/technomancy/clojars-verify/blob/daa26b39341b6d9dae54269ca0ac127eb0bb90c8/src/clojars/verify.clj

However, this gets me a huge number of false negatives (~39%) for
unknown reasons, so we'll be falling back to the original plan of
verification from old copies.

We have a few sources of backups from before the compromise, but if
anyone else has a copy of the repository from before the first of April
it wouldn't hurt to have additional sources of verification. Please
contact me by email or on IRC in the #leiningen freenode channel if so.

thanks,
Phil

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
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] Linode compromise possibly affecting Clojars

2013-04-16 Thread Rostislav Svoboda 
Whata an [ANN] !!!
Please change the subject to [linode-compromise "1.0.0"]
:)

-- 
-- 
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: [GSOC 2013] Program analysis suite, based on Rich Hickey's Codeq

2013-04-16 Thread Rich Morin 
On Apr 16, 2013, at 04:54, Navgeet Agrawal wrote:
> Hi all, thanks for these suggestions and sorry for the late reply.

No problem; I'm happy that we didn't scare you away (:-).

> I have been looking into jvm.tools.analyze for the past few days and it
> looks as a better choice to build a comprehensive analyzer. Of course
> the biggest problem in using it is it likes to expand all macros fully,
> which is bad for codeq. I think that can be handled by patching some
> parts of Compiler.java and using the patched methods. I am currently
> trying to write a demonstration fork of jvm.tools.analyze.

>From a documentation point of view, macros have two operational contexts.
In one, they generate code; in the other, the generated code is run.  I'm
not precisely sure how this should be handled, but it _is_ interesting.


> I have been thinking for some time that tracking the inputs and outputs
> through every function in a program over time can be useful. We could
> allow the user to call some function with test input, then for all
> functions down the call chain, store their input and output in the
> datomic database. Do this for every commit (every time the function
> changes). The results can provide feedback about data flow in the
> program across commits. Any comments?

One use case for this sort of tracking would be to collect "signatures"
for the inputs and outputs seen in the test suite.  If a production run
generates diverging signatures, either the test suite is incomplete or
the production code is using the function in an unexpected fashion.


> That's all for now till my exams end.

Good luck in the exams!

-r

 -- 
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: Free book on Clojure (in German)

2013-04-16 Thread Michael Klishin 
2013/4/16 Dominikus 

> If you speak German, I have a free book on Clojure ("Funktionale
> Programmierung in Clojure") for you:
>
> http://denkspuren.blogspot.de/2013/04/freies-clojure-buch-funktionale.html
>

Feel free to submit a pull request that adds it to
http://clojure-doc.org/articles/ecosystem/books.html ;)
-- 
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.

[ANN] Linode compromise possibly affecting Clojars

2013-04-16 Thread Phil Hagelberg 

Today Linode announced that their database was attacked[1]. Clojars is
hosted on Linode, and while we have no evidence that the attackers used
their access to break into the VPS instance which hosts Clojars, we
can't rule out the possibility. Other VPS instances[2] have been broken
into.

Apparently the attack happened two weeks ago. In order to confirm that
there was no attack, we want to verify checksums of all the artifacts we
can based on copies that were fetched before the attack.

If you run a private proxying internal repository for your company, you
can help us verify checksums. I'll be posting a follow-up soon with some
code you can use to calculate and publish checksums so we can
investigate discrepancies.

At this point you should be aware that there is some risk in continuing
to pull artifacts from Clojars while the verification is in process. If
you have a private proxying repository, you may want to disable the
Clojars source to avoid pulling in any new possibly-compromised
artifacts and possibly clear out any artifacts that were fetched within
the past two weeks.

If you can help out with the verification process, please join the
#leiningen channel on freenode or reply to me personally.

thanks,
Phil

[1] - http://blog.linode.com/2013/04/16/security-incident-update/

[2] - http://seclists.org/nmap-dev/2013/q2/3
http://p.hagelb.org/clojars-compromise-ann.html



pgpt2OK8ngk1f.pgp
Description: PGP signature

Free book on Clojure (in German)

2013-04-16 Thread Dominikus 
If you speak German, I have a free book on Clojure ("Funktionale 
Programmierung in Clojure") for you:

http://denkspuren.blogspot.de/2013/04/freies-clojure-buch-funktionale.html

Dominikus

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

ANN: Morph 0.3.0, monads+functors lib gets perf boost

2013-04-16 Thread Armando Blancas 
In this release the lib gets rid of reflective calls by adding type hints.

https://github.com/blancas/morph

I don't have any benchmarks, but in Ben's tree-numbering Morph's timing 
goes from ~13,700 msecs down to ~350.
https://github.com/bwo/monads/wiki/Tree-numbering-benchmark

Morph tries hard to demystify the use of monads (though writing new ones 
may be a bit tricker). The same with functors: types that map regular 
functions over their fields. Morph extends Clojure types as functors; want 
to map over a collection and keep the type? Use Morp's fmap instead of map. 
Extending your own types as functors is pretty easy.

Documentation:
https://github.com/blancas/morph/wiki
http://blancas.github.io/morph/

For bug reports, feedback, or feature requests:
https://github.com/blancas/morph/issues?state=open

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

invokedynamic instructions in Clojure

2013-04-16 Thread Ghadi Shayban 
I've added a very minimal usage of invokedynamic to the compiler.  
Basically the smallest delta without having to change internals of ObjExpr 
or break ABI compatibility.  This is minimal and raw.  There are many many 
usages of indy that will really help the Clojure runtime, this ain't one of 
them.  No benchmarks here, it's probably slower.

In current Clojure mainline, a Fn has reference slots to any vars it needs 
in its constant pool, like a cache. Anytime a non-dynamic Var's value needs 
to be accessed, the Var goes from the constant pool to the stack, and 
getRawRoot() is invoked on it.

With this change, an invokedynamic instruction instead creates a 
ConstantCallSite, which closes over a looked-up Var, and then binds the 
call site to invoke getRawRoot() on it directly.  This is only for 
non-dynamic Vars.

Simple todos:
cache the CallSite as a member on the Var itself so that all identical indy 
lookup instructions have fast bootstrapping.
emit a similar call for dynamic vars
remove the emission of Vars into the constant pool of a class

Lots of really interesting use cases for invokedynamic and all the 
associated combinators in java.lang.invoke:

Better protocol callsite caching
CallSite "middleware" for things like CLJ specific instrumentation
equality could be a special instruction
KeywordCallSite could be its own instruction as well
(apply) argument "spreading"/varargs array collection (through the 
combinators)
potentially removing IFn.invoke(*) and using MethodHandle invocation 
instead (fat chance)

You can pull down the changes at github.com/ghadishayban/clojure.
mvn clean package, tested on OpenJDK 1.7

-- 
-- 
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: Kern 0.7.0 text parsing lib has fixes, better performance

2013-04-16 Thread Armando Blancas 
On Tuesday, April 16, 2013 4:06:51 AM UTC-7, Luca Antiga wrote:
>
> Great, I just updated clj-toml to 0.7.0 and all tests pass.
> Thanks Armando
>

Very cool, Luca. I'll be looking for other ways to boost performance while 
keeping the purely functional design.

-- 
-- 
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: [GSoC 2013] CinC

2013-04-16 Thread Aaron Cohen 
As a mentor, what should I be doing at this point?

I've been contacted by a couple of interested students so far, checking to
see if I'm still interested in mentoring this (I am!)

I'm just not sure what my current next step should be.

--Aaron


On Tue, Apr 9, 2013 at 8:54 PM, Daniel Solano Gómez wrote:

> Hello,
>
> On Wed Apr 10 00:04 2013, Bronsa wrote:
> > Actually, I would be interested in doing this if still available :)
>
> Well, now that we have been accepted as a mentoring organization, now is
> the time to start getting in touch with potential mentors and develop a
> proposal.  The student application period won't open until April 22, but
> there is no reason to wait until then.
>
> Sincerely,
>
> Daniel
>
>
>
> > On Mon, Mar 4, 2013 at 6:53 PM, Aaron Cohen  wrote:
> >
> > > On Mon, Mar 4, 2013 at 11:26 AM, abp  wrote:
> > >
> > >> Is this work related?
> > >>
> > >> http://clojurewest.org/sessions#martin
> > >> https://github.com/kanaka/clojurescript
> > >>
> > >
> > > Nope, completely unrelated, though similar work.
> > >
> > > --Aaron
> > >
> > > --
> > > --
> > > 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.
> >
> >
>

-- 
-- 
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: (pprint template) gives me an exception

2013-04-16 Thread larry google groups 

Oh, I see. I had just changed :admin-text to hold a keyword instead of
text. I should have seen that sooner.

But I am still confused why a keyword would cause pprint to throw an
exception. And why at that point in the code, and not sooner?



On Apr 16, 10:05 am, larry google groups 
wrote:
> The function before the previously mentioned function is this:
>
> (defn add-public-text-to-top-banner-and-return-as-new-template
> [template item]
>   (println "entering add-public-text-to-top-banner-and-return-as-new-
> template")
>   (println (pp/pprint template))
>   (enlive/transform template [:#content :> :h1 :span] (enlive/content
> (:admin-text item
>
> I am not clear why this kills the template, but it seems to. Here,
> pprint works and shows the Enlive nodes. But in the next function I
> get an exception.
>
> On Apr 16, 9:59 am, larry google groups 
> wrote:
>
>
>
>
>
>
>
> > On the first pprint expression in this function, I get an exception:
>
> > (defn add-main-image-for-this-item-and-return-as-new-template
> > [template item]
>
> > (println " start of add-main-image-for-this-item-and-return-as-new-
> > template")
>
> > (println (pp/pprint template))
> >   (println "add-main-image-for-this-item-and-return-as-new-template")
> >   (let [final-template (if-not (nil? (:filename item))
> >                          (enlive/transform template [:#main-image-for-
> > this-item] (enlive/html-content (str "")))
> >                          template)]
> > (println (pp/pprint final-template))
> >       (println "  leaving add-main-image-for-this-item-and-return-as-
> > new-template")
> >     final-template))
>
> > The exception is:
>
> >  start of add-main-image-for-this-item-and-return-as-new-template
> > 2013-04-16 09:54:23.536:WARN:oejs.AbstractHttpConnection:/admin/edit/
> > planners/summer-camp3804946
> > java.lang.IllegalArgumentException: Don't know how to create ISeq
> > from: clojure.lang.Keyword
> >         at clojure.lang.RT.seqFrom(RT.java:494)
> >         at clojure.lang.RT.seq(RT.java:475)
>
> > Why would anything blow up on pprint? I thought pprint could handle
> > anything?

-- 
-- 
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: (pprint template) gives me an exception

2013-04-16 Thread larry google groups 
The function before the previously mentioned function is this:

(defn add-public-text-to-top-banner-and-return-as-new-template
[template item]
  (println "entering add-public-text-to-top-banner-and-return-as-new-
template")
  (println (pp/pprint template))
  (enlive/transform template [:#content :> :h1 :span] (enlive/content
(:admin-text item


I am not clear why this kills the template, but it seems to. Here,
pprint works and shows the Enlive nodes. But in the next function I
get an exception.



On Apr 16, 9:59 am, larry google groups 
wrote:
> On the first pprint expression in this function, I get an exception:
>
> (defn add-main-image-for-this-item-and-return-as-new-template
> [template item]
>
> (println " start of add-main-image-for-this-item-and-return-as-new-
> template")
>
> (println (pp/pprint template))
>   (println "add-main-image-for-this-item-and-return-as-new-template")
>   (let [final-template (if-not (nil? (:filename item))
>                          (enlive/transform template [:#main-image-for-
> this-item] (enlive/html-content (str "")))
>                          template)]
> (println (pp/pprint final-template))
>       (println "  leaving add-main-image-for-this-item-and-return-as-
> new-template")
>     final-template))
>
> The exception is:
>
>  start of add-main-image-for-this-item-and-return-as-new-template
> 2013-04-16 09:54:23.536:WARN:oejs.AbstractHttpConnection:/admin/edit/
> planners/summer-camp3804946
> java.lang.IllegalArgumentException: Don't know how to create ISeq
> from: clojure.lang.Keyword
>         at clojure.lang.RT.seqFrom(RT.java:494)
>         at clojure.lang.RT.seq(RT.java:475)
>
> Why would anything blow up on pprint? I thought pprint could handle
> anything?

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

(pprint template) gives me an exception

2013-04-16 Thread larry google groups 
On the first pprint expression in this function, I get an exception:


(defn add-main-image-for-this-item-and-return-as-new-template
[template item]

(println " start of add-main-image-for-this-item-and-return-as-new-
template")

(println (pp/pprint template))
  (println "add-main-image-for-this-item-and-return-as-new-template")
  (let [final-template (if-not (nil? (:filename item))
 (enlive/transform template [:#main-image-for-
this-item] (enlive/html-content (str "")))
 template)]
(println (pp/pprint final-template))
  (println "  leaving add-main-image-for-this-item-and-return-as-
new-template")
final-template))


The exception is:

 start of add-main-image-for-this-item-and-return-as-new-template
2013-04-16 09:54:23.536:WARN:oejs.AbstractHttpConnection:/admin/edit/
planners/summer-camp3804946
java.lang.IllegalArgumentException: Don't know how to create ISeq
from: clojure.lang.Keyword
at clojure.lang.RT.seqFrom(RT.java:494)
at clojure.lang.RT.seq(RT.java:475)


Why would anything blow up on pprint? I thought pprint could handle
anything?

-- 
-- 
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 is the compiler more strict on one of my machines?

2013-04-16 Thread larry google groups 
Thank you! I think you are right.

On Apr 16, 9:05 am, "Jim foo.bar"  wrote:
> It sounds to me that you forgot to run 'lein clean' at work, leaving
> certain classfiles present in 'target'. This would explain why you got
> your uberjar at work but not at home (presumably .class files are being
> ignored by git)
>
> Jim
>
> On 16/04/13 13:59, larry google groups wrote:
>
>
>
>
>
>
>
> > I have a Mac at work and I have a Mac at home. At work, while working
> > on my project, I decided to delete my file "validation.clj". There was
> > still a reference to it in the ns declaration in import_data.clj, but
> > I did not know that. I ran "lein uberjar" and everything compiled. I
> > did not use any functions in import_data.clj, but the app seemed to
> > run. Then I did:
>
> > git add .
> > git comment -m "some comment"
> > git push origin master
>
> > Then I got home and did "git pull origin master".
>
> > Then I ran "lein uberjar" and got a compile error because of the ns
> > declaration in import_data.clj.
>
> > Why would one compiler be more strict than the other? Could I have set
> > some config variable that I've now forgotten about?

-- 
-- 
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 is the compiler more strict on one of my machines?

2013-04-16 Thread Jim foo.bar 
It sounds to me that you forgot to run 'lein clean' at work, leaving 
certain classfiles present in 'target'. This would explain why you got 
your uberjar at work but not at home (presumably .class files are being 
ignored by git)


Jim


On 16/04/13 13:59, larry google groups wrote:

I have a Mac at work and I have a Mac at home. At work, while working
on my project, I decided to delete my file "validation.clj". There was
still a reference to it in the ns declaration in import_data.clj, but
I did not know that. I ran "lein uberjar" and everything compiled. I
did not use any functions in import_data.clj, but the app seemed to
run. Then I did:

git add .
git comment -m "some comment"
git push origin master

Then I got home and did "git pull origin master".

Then I ran "lein uberjar" and got a compile error because of the ns
declaration in import_data.clj.

Why would one compiler be more strict than the other? Could I have set
some config variable that I've now forgotten about?



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

Why is the compiler more strict on one of my machines?

2013-04-16 Thread larry google groups 
I have a Mac at work and I have a Mac at home. At work, while working
on my project, I decided to delete my file "validation.clj". There was
still a reference to it in the ns declaration in import_data.clj, but
I did not know that. I ran "lein uberjar" and everything compiled. I
did not use any functions in import_data.clj, but the app seemed to
run. Then I did:

git add .
git comment -m "some comment"
git push origin master

Then I got home and did "git pull origin master".

Then I ran "lein uberjar" and got a compile error because of the ns
declaration in import_data.clj.

Why would one compiler be more strict than the other? Could I have set
some config variable that I've now forgotten about?

-- 
-- 
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: [GSOC 2013] Program analysis suite, based on Rich Hickey's Codeq

2013-04-16 Thread Navgeet Agrawal 
Hi all, thanks for these suggestions and sorry for the late reply.
I have been looking into jvm.tools.analyze for the past few days and it
looks as a better choice to build a comprehensive analyzer. Of course the
biggest problem in using it is it likes to expand all macros fully, which
is bad for codeq. I think that can be handled by patching some parts of
Compiler.java and using the patched methods. I am currently trying to write
a demonstration fork of jvm.tools.analyze.


I have been thinking for some time that tracking the inputs and outputs
through every function in a program over time can be useful. We could allow
the user to call some function with test input, then for all functions down
the call chain, store their input and output in the datomic database. Do
this for every commit (every time the function changes). The results can
provide feedback about data flow in the program across commits. Any
comments?

That's all for now till my exams end.

-- Navgeet

-- 
-- 
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: Kern 0.7.0 text parsing lib has fixes, better performance

2013-04-16 Thread Luca Antiga 
Great, I just updated clj-toml to 0.7.0 and all tests pass.
Thanks Armando

Luca

On Monday, April 15, 2013 6:38:40 PM UTC+2, Armando Blancas wrote:
>
> This is a much needed clean up and perf boost release. 
>
> https://github.com/blancas/kern
>
> Function (parse-file) won't choke with big files, while new parsers 
> (parse-data) and (parse-data-file) work much faster by relaxing their 
> house-keeping for input that's expected to be alright (e.g., serialized 
> data).
>
> Parser (search) will match a pattern anywhere in the input, not just at 
> the start. The new lexer configuration for a leading sign in numbers helps 
> in cases where the lexical sign interferes with the grammar for 
> expressions. The Wiki now includes a chapter in lexer config:
>
> https://github.com/blancas/kern/wiki/How-to-Customize-the-Lexer
>
> Documentation and samples:
> https://github.com/blancas/kern/wiki
> http://blancas.github.io/kern/
>
> For bug reports, feedback, and feature requests:
> https://github.com/blancas/kern/issues?state=open
>
>

-- 
-- 
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: Full stack Clojure web/REST framework - is there any mileage in it?

2013-04-16 Thread edward 
I'm a bit curious. My immediate reaction was to ask what you use instead of 
Spring (none?), Hibernate (datomic?) and what did you use to provide the 
plumbing for web apps (assuming you needed it and didn't just write it all 
from scratch).

My second thought was then what is the difference between a framework like 
Spring and a stack like the one I am assuming you used if it were 
documented and became a de facto framework?

On Sunday, 13 January 2013 15:28:38 UTC, Luc wrote:
>
> +1, excellent summary of the key points. 
>
> We got rid of Spring, Hibernate et cie for the same reasons. They were 
> somewhat 
> needed in Java but in Clojure we found that they were cumbersome to use 
> and 
> brought little value. 
>
> We realized along the way that some generated Java code (Hibernate is a 
> good 
> example) was buggy and needed to be maintained by hand. 
>
> If even the generated code to glue things together is buggy, were is the 
> gain ? 
> You end up having to maintain it... 
>
> We cut our backend code by a magnitude of more than 15 times by switching 
> to 100% 
> Clojure and getting rid of the frameworks. Now down to 15000 sloc and less 
> dependencies to track... 
>
> Luc P. 
>
>
> > The Clojure tradition of mixing-and-matching small libraries rather than 
> > relying on large frameworks like Spring did not emerge by accident. The 
> > Java language itself causes library authors to create their own types 
> > thereby creating an impedance mismatch with other libraries. Spring (and 
> > similar frameworks) have evolved to address these issues, using clever 
> > design patterns such as interface adaptation. In contrast, Clojure 
> > libraries simply use common data structures (maps, sequences, sets) and 
> > Clojure itself has all the functions to convert between them where 
> > necessary. The result is that *Clojure libraries integrate with each 
> other 
> > relatively seamlessly without the need for frameworks like Spring*. In 
> > other words, the very existence of Spring and other 'compendium' 
> frameworks 
> > in the Java world is evidence that a lot of work is required to get Java 
> > libraries to work together. The absence of equivalents in the Clojure 
> world 
> > is something that we should be very happy about. When you choose a 
> > compendium framework, you have to work with whatever libraries have been 
> > chosen for you by the framework provider, and hope that the doors you 
> want 
> > to walk through are unlocked prior to your arrival. All too often they 
> are 
> > not. 
> > 
> > I've long felt that large platforms like Spring, Eclipse and even the 
> JDK 
> > itself are a trade-off between the benefits of ease-of-use with the 
> *sacrifice 
> > of future innovation* - platforms give incumbent libraries a *premature 
> > monopoly* on a functional area, thereby stifling competition from a 
> > potential worthy successor library. What I like about the Clojure 
> > eco-system is that, to a large extent, no such monopolies have emerged, 
> > there is a truer meritocracy because it is possible for libraries to 
> emerge 
> > that provide a better or alternative approach to existing ones - so 
> Ring, 
> > Aleph, Hiccup, Enlive, Compojure, Moustache and Liberator (to name but a 
> > few) can all peacefully co-exist. Innovative new libraries crop up all 
> the 
> > time - so quickly it's almost hard to keep up! In which case, we 
> shouldn't 
> > confuse frameworks with simple collections of libraries that some 
> curator 
> > has verified work together. This is akin to the function that GNU/Linux 
> > distributions perform and there is definite value, especially for 
> > beginners, in the community shaping these collections. 
> > 
> > 
> > On Friday, 11 January 2013 16:52:05 UTC, Paul Umbers wrote: 
> > > 
> > > I've been experimenting with Clojure web services recently, and 
> posting 
> > > the work on GitHub  and my blog<
> http://internistic.blogspot.ca/search/label/clojure> 
> > > . 
> > > 
> > > When putting this test app together, it occurred to me that most other 
> > > languages have a full-stack API available which makes life easier when 
> it 
> > > comes to making decisions about which libraries/APIs/frameworks to 
> use. It 
> > > also reduces the possibility of "impedance mismatch" between the 
> libraries. 
> > > For Java, you can use Spring (or any one of a dozen or more other 
> popular 
> > > frameworks), for Scala there's Typesafe, and so on. Clojure has 
> Compojure, 
> > > Ring, several logging, validation and database libraries, and they can 
> be 
> > > used together but they don't constitute a coordinated full stack - and 
> that 
> > > creates issues. 
> > > 
> > > For example, the latest vesion of Compojure (1.1.3) uses Ring 1.1.5 
> and 
> > > not the latest version of Ring (1.1.6) which has significantly better 
> util 
> > > functions available - but I can't use them until Compojure catches up. 
> By 
> > > the time you ad

Re: Namespace loading with defrecord and attempting to call unbound fn

2013-04-16 Thread Meikel Brandmeyer (kotarak) 
Hi,

Am Dienstag, 16. April 2013 11:32:38 UTC+2 schrieb Pierre Allix:
>
> Thank you the patch works.
>
> I though it would have made sense to just create a record directly from 
> Java since they can implement Java interfaces.
>
>
As a rule of thumb, I go with the non-AOT behaviour of Clojure. In that 
case the record does not exist until the namespace is required. So if I 
want to use it (in particular directly from Java), I have to require the 
namespace upfront to actually create the record class. And even if AOT 
would behave differently (think gen-class: require implementing namespace 
on class init), doing it explicitly is more robust because it allows both - 
AOT and non-AOT - usage.

But as I said before: I would not create the record directly but go through 
the support functions ("->Bar", "map->Bar"). Or even higher level 
constructing functions. In Java this is probably the factory pattern.

Meikel

-- 
-- 
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: Namespaces, APIs, protocols and records

2013-04-16 Thread Simon Katz 
Thanks for the pointer to 
tools.namespace — 
it looks really useful.  And if I follow the advice there to "always create 
new instances of records after a refresh", it will simplify my decision on 
how to organise namespaces — there's no longer a need to separate protocols 
and their implementations. Now I only need to think about how to make it 
easy to create new instances of records after a refresh :-)

On Monday, 15 April 2013 19:45:45 UTC+1, Stuart Sierra wrote:
>
> "...talk by Stuart Sierra (http://vimeo.com/46163090) in which he 
>> suggests putting protocols and their implementations in separate 
>> namespaces, because, during development reloading a protocol breaks 
>> existing instances"
>>
>
> I don't universally recommend this any more. You still have to be careful 
> with reloading. The documentation for 
> tools.namespacedescribes some the 
> issues with reloading and protocols, and ways to work 
> around them.
>
> -S
>
>

-- 
-- 
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: Namespace loading with defrecord and attempting to call unbound fn

2013-04-16 Thread Pierre Allix 
Thank you the patch works.

I though it would have made sense to just create a record directly from 
Java since they can implement Java interfaces.

On Monday, April 15, 2013 7:57:28 PM UTC+2, Meikel Brandmeyer (kotarak) 
wrote:
>
> Hi Pierre,
>
> does this patch work?
>
> 8<--8<--8<
> diff --git a/test/eu/markosproject/test/LicenseCheckerTest.java 
> b/test/eu/markosproject/test/LicenseCheckerTest.java
> index 2e017cc..1a1cc82 100644
> --- a/test/eu/markosproject/test/LicenseCheckerTest.java
> +++ b/test/eu/markosproject/test/LicenseCheckerTest.java
> @@ -11,8 +11,12 @@ import 
> eu.markosproject.commons.interfaces.licensing.ICheckerResultStorer;
>  import eu.markosproject.commons.interfaces.licensing.IRNotification;
>  import eu.markosproject.licensing.LicenseChecker;
>  
> +import clojure.lang.RT;
>  
>  public class LicenseCheckerTest {
> + static {
> + RT.var("clojure.core", "require").invoke(RT.var("clojure.core", 
> "symbol").invoke("eu.markosproject.licensing"));
> + }
>   
>   private final static Logger log = 
> Logger.getLogger(LicenseCheckerTest.class .getName()); 
>   
> 8<--8<--8<
>
> I'm not convinced that records are supposed to be created directly. (Ok. 
> Testing. Maybe.) They should be an implementation detail returned by an 
> API. If you need Java access there you might want to still go the Clojure 
> route and provide Java access through a façade. cf. Rich Hickey's example 
> of Datomic: 
> http://skillsmatter.com/podcast/scala/impromptu-rich-hickey-lightning-talk
>
> Meikel
>
>

-- 
-- 
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: Namespaces, APIs, protocols and records

2013-04-16 Thread Simon Katz 
Thanks for the suggestion to look at the ClojureWerkz libraries.  I took a 
quick look at the user documentation for three of them (Monger, Welle and 
Quartzite), and in all cases they showed examples of client code requiring 
multiple namespaces.

On Monday, 15 April 2013 16:45:47 UTC+1, travis vachon wrote:
>
> >  I definitely like that it keeps things simpler for me (the 
> implementer), but clients have to know about multiple namespaces rather 
> than a single namespace and I don't like that. 
>
> Ah, right - I've mostly been working in application code, not 
> libraries. That said, I think the heuristic still works - I'd 
> definitely try writing some code that consumes your library, either in 
> tests or in a dummy project, and apply the same rule: can you give the 
> namespace a name that makes function calls clearer? Given a single 
> name, are there pieces that feel out of place? 
>
> This is a topic that comes up a lot, and I think that's at least 
> partially because different domains and library styles call for 
> different strategies. An ideal library that does one thing really well 
> might indeed be a good candidate for one big public namespace, but of 
> course internally it might make a lot of sense to break the 
> implementation up into focused modules. 
>
> You might check out the clojurewerks libraries for some insight from a 
> group that has written quite a few libraries: 
>
> http://clojurewerkz.org/ 
>
> Travis 
>
> On Mon, Apr 15, 2013 at 11:23 AM, Simon Katz > 
> wrote: 
> > I'm considering going this way.  I definitely like that it keeps things 
> > simpler for me (the implementer), but clients have to know about 
> multiple 
> > namespaces rather than a single namespace and I don't like that. 
> > 
> > I must say I'm finding it hard to decide which way to go. 
> > 
> > 
> > On Monday, 15 April 2013 15:31:49 UTC+1, travis vachon wrote: 
> >> 
> >> For what it's worth, I've been refactoring big namespaces out into 
> >> small, focused namespaces lately. A rough heuristic I've found useful 
> >> is that when I require a namespace I should be able to assign it a 
> >> name that aids with readability. 
> >> 
> >> So for example: 
> >> 
> >> (ns foo.book) 
> >> 
> >> (defn search [book term] 
> >>   ;;search the book 
> >>   ) 
> >> -- 
> >> (ns foo.stacks) 
> >> 
> >> (defn search [stacks title] 
> >> ;; search stacks 
> >> ) 
> >> -- 
> >> (ns foo.library 
> >>   (require [foo.book :as book] 
> >>   [foo.stacks :as stacks])) 
> >> 
> >> (defn find-passage [stacks passage title] 
> >>   (-> stacks 
> >>(stacks/search title) 
> >>(books/search passage))) 
> >> - 
> >> 
> >> This is all pretty contrived, but it seems to work out in the wild 
> >> pretty well. YMMV, and I'm still not settled on this myself, but 
> >> hopefully that helps. 
> >> 
> >> Travis 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> On Sun, Apr 14, 2013 at 2:16 PM, Simon Katz  wrote: 
> >> > Whoops — when I said "with an extra [namespace] for each protocol", I 
> >> > meant 
> >> > "with an extra [namespace] for each protocol implementation". 
> >> > 
> >> > 
> >> > On Sunday, 14 April 2013 18:21:19 UTC+1, Simon Katz wrote: 
> >> >> 
> >> >> I'm in the process of trying to work out how I want to use 
> namespaces 
> >> >> when 
> >> >> implementing libraries or subsystems. 
> >> >> 
> >> >> I'm aware of several approaches: 
> >> >> 
> >> >> Use a single namespace, making only the API public (either with 
> >> >> everything 
> >> >> in a single file or breaking things into multiple files and using 
> >> >> `load`). 
> >> >> Use implementation namespaces and create an API in a separate 
> namespace 
> >> >> (perhaps using Potemkin to simplify the creation of the API). 
> >> >> Have lots of smaller namespaces and have the client need to know 
> which 
> >> >> of 
> >> >> the smaller namespaces to use for what. 
> >> >> (And some variations.) 
> >> >> 
> >> >> 
> >> >> I'm fairly happy with large namespaces, so I'm leaning towards using 
> a 
> >> >> single namespace. 
> >> >> 
> >> >> There's one thing I've come across that doesn't fit nicely with 
> putting 
> >> >> everything into a single namespace, though.  A Google search for 
> >> >> "Clojure in 
> >> >> the Large" led me to a nice talk by Stuart Sierra 
> >> >> (http://vimeo.com/46163090) in which he suggests putting protocols 
> and 
> >> >> their 
> >> >> implementations in separate namespaces, because, during development 
> >> >> reloading a protocol breaks existing instances.  (I know Stuart gave 
> a 
> >> >> similarly presentation at Clojure West recently, but I don't think 
> the 
> >> >> video 
> >> >> of that is available yet.) 
> >> >> 
> >> >> Having the separate namespaces would be fine if I was heading down 
> the 
> >> >> route of having the client know about multiple namespaces, but I 
> don't 
> >> >> really want to do that.  With the single namespace approach (with an 
> >> >> extra 
> >> >> one for each protocol I d

Surprising behaviour related to records, protocols and AOT

2013-04-16 Thread Ragnar Dahlén 
Hi,

Today I encountered a, to me, slightly surprising behaviour seemingly
related clojure records. 

The setup is as follows:

1. One namespace defines a record type:

(ns defrecordissue.arecord)

(defrecord ARecord [])


2. Another namespace defines a protocol, and extends it to the record
   type defined in 1:

(ns defrecordissue.aprotocol
  (:require [defrecordissue.arecord])
  (:import [defrecordissue.arecord ARecord]))
 
(defprotocol AProtocol
  (afn [this]))
 
(extend-protocol AProtocol
  ARecord
  (afn [this] 42))

3. A third namespace constructs an instance of the record and invokes
   the protocol function on the record:

(ns defrecordissue.aot1
  (:require [defrecordissue.aprotocol]
[defrecordissue.arecord]))
 
(defrecordissue.aprotocol/afn (defrecordissue.arecord/->ARecord))


When the defrecordissue.aot1 namespace is compiled, in my case using
`lein compile defrecordissue.aot1`, compilation fails with the
following exception:

Exception in thread "main" java.lang.IllegalArgumentException: No 
implementation of method: :afn of protocol: 
#'defrecordissue.aprotocol/AProtocol found for class: 
defrecordissue.arecord.ARecord, compiling:(aot1.clj:5:1)
at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:3463)
at clojure.lang.Compiler.compile1(Compiler.java:7153)
at clojure.lang.Compiler.compile(Compiler.java:7219)
at clojure.lang.RT.compile(RT.java:398)
at clojure.lang.RT.load(RT.java:438)
at clojure.lang.RT.load(RT.java:411)
at clojure.core$load$fn__5018.invoke(core.clj:5530)
at clojure.core$load.doInvoke(core.clj:5529)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5336)
at clojure.core$compile$fn__5023.invoke(core.clj:5541)
at clojure.core$compile.invoke(core.clj:5540)
at user$eval7.invoke(NO_SOURCE_FILE:1)
at clojure.lang.Compiler.eval(Compiler.java:6619)
at clojure.lang.Compiler.eval(Compiler.java:6609)
at clojure.lang.Compiler.eval(Compiler.java:6582)
at clojure.core$eval.invoke(core.clj:2852)
at clojure.main$eval_opt.invoke(main.clj:308)
at clojure.main$initialize.invoke(main.clj:327)
at clojure.main$null_opt.invoke(main.clj:362)
at clojure.main$main.doInvoke(main.clj:440)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at clojure.lang.Var.invoke(Var.java:419)
at clojure.lang.AFn.applyToHelper(AFn.java:163)
at clojure.lang.Var.applyTo(Var.java:532)
at clojure.main.main(main.java:37)
Caused by: java.lang.IllegalArgumentException: No implementation of method: 
:afn of protocol: #'defrecordissue.aprotocol/AProtocol found for class: 
defrecordissue.arecord.ARecord
at clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:541)
at defrecordissue.aprotocol$fn__40$G__35__45.invoke(aprotocol.clj:5)
at clojure.lang.AFn.applyToHelper(AFn.java:161)
at clojure.lang.AFn.applyTo(AFn.java:151)
at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:3458)
... 25 more 

If I change 3) to construct the record class directly, like so:

   (ns defrecordissue.aot2
 (:require [defrecordissue.aprotocol]
   [defrecordissue.arecord]))

   (defrecordissue.aprotocol/afn (defrecordissue.arecord.ARecord.))

Compilation succeeds.

My suspicion is that this is somehow related to
http://dev.clojure.org/jira/browse/CLJ-371, but I don't understant
exactly what is happening. 

I should also add that without the `lein clean`, compilation succeeds
the second time, since a class for the record is now available on the
classpath. Therefore, I can get around this problem by AOT-compiling
the namespace defining the record type.

I created a simple leiningen project on GitHub that illustrates the
issue, see README for usage:
https://github.com/ragnard/defrecordissue

Any enlightenment is much appreciated.

Cheers,

Ragnar

-- 
-- 
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: Type hinting generated functions

2013-04-16 Thread dannyg 
Thanks Allan ill try it tonight

-- 
-- 
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: Clojurescript Error: Undefined nameToPath for goog.ui

2013-04-16 Thread Răzvan Rotaru 
I found the cause after looking at google closure more closely. The 
following is wrong:

goog.require('goog.ui');

It must be:

goog.require('goog.ui.Button');

So the correct clojurescript code is:

(ns test
  (:import goog.ui.Button))

(.render (new Button "Hello!") (goog.dom/getElement "b1"))


Razvan

luni, 15 aprilie 2013, 21:13:19 UTC+3, Răzvan Rotaru a scris:
>
> Hi,
>
> I am currently unable to get to the bottom of a "undefined nameToPath" 
> error in clojurescript. Here's the script:
>
> *test.cljs:*
> (ns test
>   (:require [goog.dom :as gdom] [goog.ui :as gui]))
>
> (.render (new gui/Button "Hello!") (gdom/getElement "b1"))
>
> And the compiled output:
>
> *test.js (compiled) :*
> goog.provide('test');
> goog.require('cljs.core');
> goog.require('goog.ui');
> goog.require('goog.dom');
> (new goog.ui.Button("Hello!")).render(goog.dom.getElement("b1"));
>
>
> *bootstrap.js (compiled) :*
> goog.addDependency("base.js", ['goog'], []);
> goog.addDependency("../cljs/core.js", ['cljs.core'], ['goog.string', 
> 'goog.array', 'goog.object', 'goog.string.format', 
> 'goog.string.StringBuffer']);
> goog.addDependency("../test.js", ['test'], ['cljs.core', 'goog.dom', 
> 'goog.ui']);
>
> *index.html:*
> 
> 
>   
> 
> Habarnam
>   
>   
> 
> 
> 
> 
>   goog.require('test');
> 
>   
> 
>
> Any ideas what i'm doing wrong here? Thanks.
>
> Răzvan
>

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