Darmac | 1 Aug 01:12 2009
Picon

New version of AnotherClojureBox (ACB)


Hi
I just release a new version of AnotherClojureBox!!

What's new:

- First, ACB Launcher!! Many people ask me for what file should be
executed in order to edit or run REPL, so I did a launcher that wiil
be always there.

- Improved inline form documentation (now include clojure.contrib
namespaces)

- You can rebuild clojure API or clojure keywords in order to update
Scite to a new (may be alpha) version.
  You can also include others libraries documentation to the API or
the keywords list.

- Regex syntax #"" breaks the lexer (Fixed).

- ACB Launcher & Config.

- Select forms in the editor and send to execute in the REPL (Ctrl-E
from scite).

Again, give it a try and let me know what do you think about it!
You can download in my homepage http://sites.google.com/site/dariomac/Home/projects

Enjoy!
(Continue reading)

Stuart Sierra | 1 Aug 02:44 2009
Picon

Re: JSR 223


Someone's working on it: http://github.com/pmf/clojure-jsr223/tree/master

-SS

On Jul 31, 12:04 pm, Mike <cki... <at> gmail.com> wrote:
> Sorry if this is a FAQ; couldn't find it on the main site nor in the
> group.
>
> Are there plans for Clojure to work in JSR-223 (Java Scripting
> Framework)?  I see a lot of languages up there already.  In fact, the
> only major JVM languages missing are Scala and Clojure.
>
> Thanks for any info...
> Mike
Niels Mayer | 1 Aug 02:36 2009
Picon

Re: JSR 223

http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise20M2On Fri, Jul 31, 2009 at 9:04 AM, Mike <ckimyt <at> gmail.com> wrote:
Are there plans for Clojure to work in JSR-223 (Java Scripting
Framework)?  I see a lot of languages up there already.  In fact, the
only major JVM languages missing are Scala and Clojure.


Clojure has a JSR-223 implementation according to:
http://github.com/pmf/clojure-jsr223/tree/master
http://groovy.codehaus.org/JSR-223+access+to+other+JVM+languages
http://sayspy.blogspot.com/2009/03/interacting-between-jvm-lang-here-and.html

I've been told I'd need to "Build the Clojure JSR223 engine from http://github.com/pmf/clojure-jsr223/tree/master and place it inside WEB-INF/lib" in order to add Clojure as a scripting language to Xwiki (alongside existing velocity/groovy and jRuby scripting implementations). Any special instructions or suggestions or "gotchas" in creating the clojure jsr223 engine? (I'm still upgrading to Xwiki 2.0M2 prior to starting my clojure experiment, so any prior advice before doing anything stupid --  e.g. running the jsr223 engine on an incompatible version of clojure -- would be helpful.)


PS: I've always seen xwiki as the "emacs of webapps" (and wikis)...
So I'm looking forward to having a real emacsish type language -- clojure -- 
to extend it via a more appropriate language for scripting.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure <at> 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+unsubscribe <at> googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---

pmf | 1 Aug 08:00 2009
Picon
Picon

Re: JSR 223


On Aug 1, 2:36 am, Niels Mayer <nielsma... <at> gmail.com> wrote:
> PS: I've always seen xwiki as the "emacs of webapps" (and wikis)...
> So I'm looking forward to having a real emacsish type language -- clojure
> --
> to extend it via a more appropriate language for scripting.

I'm the author of the JSR 223 bridge for Clojure. At the moment, I
have several uncommitted changes (mainly related to wrapping it up in
a nice OSGi service component (to be used optionally). The Invocable-
stuff is not implemented at the moment, but will be painless to
implement. The Compilable-interface is a bit harder to do, and given
Clojure's AOT compilation, I'm not sure if there's really a use case
(because if you use require within a small script, Clojure will
already out of the box transparently choose a compiled implementation,
given a proper classpath setup). It's not quite the same, but comes
pretty close.

Aside from that, I have some unresolved design issues regarding
isolation of engines; this works differently for Clojure than for
other dynamic languages for the reasons explained below.

Due to the static initialization of the Clojure runtime, it is much
harder to create different independent Clojure-engine instances, since
this would require loading each Clojure-runtime under a separate
classloader, which I am not opposed to, but was unable to implement.

At the moment, I'm using a weird kind of isolation in which each
Clojure-engine runs in its own thread, using a shared runtime, and
bindings are isolated by pushing and popping them.

I'm going to abandon this rather stupid approach and use a simpler
"one namespace per engine"-scheme. This change should (hopefully) be
transparent for little scripts that don't have their own explicit
namespaces. If your scripts use user-defined namespaces, I'll just
assume you break this isolation intentionally (which is true to the
meaning of namespaces, after all).

If anybody would like to look into the classloader-based isolation,
I'd happily to integrate this change (even if this means a severe
startup-overhead for the creation of each engine-instance; it's simply
the proper way to do it).

For production (at least if you plan to have more than one active
engine instance), I'd recommend to wait for either the namespace-based
isolation or (should anybody get involved) the classloader-based
approach. I'll reply to this thread again if one of these approaches
is implemented.
Rich Hickey | 1 Aug 15:02 2009
Picon

Re: REQUEST: Add apply-map to contrib.def (or core)


On Fri, Jul 31, 2009 at 2:34 PM, Sean Devlin<francoisdevlin <at> gmail.com> wrote:
>
> I've been using Meikel's defnk macro a fair bit in some of my code.  I
> have several functions that have sensible defaults that only need to
> be overridden occasionally, so keyword arguments fit the bill nicely.
>
> Let's consider two (contrived) keyword fns.
>
> (use 'clojure.contrib.def)
>
> (defnk add
>  [x :y 10 :z 20]
>  (+ x y z))
>
> (defnk nil-free?
>  [a :b 1 :c 2]
>  (every? (comp not nil?) [a b c]))
>
> There are several occasions I would like to use apply, and supply a
> map for the keyword arguments.  For those of you with a Python
> background, it would work just like the ** operator.  Let's call this
> function apply-map (a definition can be found here: http://gist.github.com/159324
> ).  You can use apply-map just like you would apply.
>
> (def useful-vec [:y 0])
> (def useful-map {:y 0})
>
> user=> (apply add 1 usefull-vec)
> 21
>
> ;This could be used to apply setting from a user...
> user=>(apply-map add 1 useful-map)
> 21
>
> Some more use cases:
>
> user=> (def test-map {:a "A" :b "B" :c "C"})
> #'user/test-map
> user=> (vector test-map)
> [{:a "A", :b "B", :c "C"}]
> user=> (apply vector test-map)
> [[:a "A"] [:b "B"] [:c "C"]]
> user=> (apply-map vector test-map)
> [:a "A" :b "B" :c "C"]
>
> This helps with higher order functions
>
> ;This worked before, because Meikel is just awesome.
> user=>(map add [1 2 3])
> (31 32 33)
>
> ;Slightly ugly, but it works...
> user=>(map
>               #(apply-map add (first %) (second %))
>               [[1 {:z 0}] [2 {:y 0}] [3]])
> (11 22 33)
>
> Similarly, this works for filter/remove
>
> ;Again, somewhat ugly...
> user=>(filter
>             #(apply-map nil-free? (first %) (second %))
>             [[nil {}] [1 {:b nil}] [2]])
> ([2])
>
> This does NOT attempt to solve the problem of mixing keyword and
> variable length arguments.  However, I think it is a step forward in
> making keyword arguments more useful in Clojure.
>
> Feedback?

I think your 'uglies' are a hint - perhaps better to make a function
that takes a keyword fn and returns a fn that works the way you want:

(fixfnk keywordfn) -> mapargfn

((fixfnk add) 4 {:y 101}) -> 125

Then you can map, filter etc.

But the whole thing is somewhat an exercise in the non-composability
of keyword fns.

Rich

Rich Hickey | 1 Aug 15:15 2009
Picon

Re: Bug in parallel.clj (and fix)


On Fri, Jul 31, 2009 at 10:40 AM, Eric<ericwnormand <at> gmail.com> wrote:
>
> I tried to import clojure.parallel today and it didn't work.  It
> couldn't find forkjoin.ParallelArray
>
> So I went hunting for it and it doesn't exist.  There is a
> extra166y.ParallelArray.  In fact, all of the names imported were in
> extra166y.  So I changed the line in parallel to reflect that.
>
> (import '(jsr166y.forkjoin ParallelArray ParallelArrayWithBounds
> ParallelArrayWithFilter
>                           ParallelArrayWithMapping
>                           Ops$Op Ops$BinaryOp Ops$Reducer Ops
> $Predicate Ops$BinaryPredicate
>                           Ops$IntAndObjectPredicate Ops
> $IntAndObjectToObject))
>
> changed to
>
> (import '(extra166y ParallelArray ParallelArrayWithBounds
> ParallelArrayWithFilter
>                           ParallelArrayWithMapping
>                           Ops$Op Ops$BinaryOp Ops$Reducer Ops
> $Predicate Ops$BinaryPredicate
>                           Ops$IntAndObjectPredicate Ops
> $IntAndObjectToObject))
>
>
> This seems to fix it.

You are right, ParallelArray has moved, but more important, isn't
going to make it into Java 7. Due to that, and some prodding to look
at the latest ForkJoin, I've started work on implementing parallel
algorithms right on the Clojure persistent data structures using the
lower-lever ForkJoin primitives.

The work is in the 'par' branch on GitHub:

http://github.com/richhickey/clojure/tree/par

You'll need the jsr166y.jar I have built, placed in the same directory
as build.xml:

http://cloud.github.com/downloads/richhickey/clojure/jsr166y.jar

And be building and running with Java 6.

Right now there is just pvmap and pvreduce, both in the clojure.par
namespace. Both take (Clojure) vectors, and, unlike pmap, are quite
fast even for relatively small operations, i.e. (pvmap inc v) should
be faster than (map inc v) for large vectors on multicore machines.
The nice thing is pvmap returns a Clojure vector, so no need for the
special data structures as with the older parallel library.

The results are quite promising, and I look forward to implementing
many parallel operations on Clojure's vectors and maps, and providing
the tools for you to write your own.

Feedback welcome,

Rich

Daniel | 1 Aug 14:38 2009
Picon

Re: Is it possible to swap in a new classloader?


2009/7/31 Garth Sheldon-Coulson <gasc <at> mit.edu>:
> Dear Clojurians,
>
> Is it possible to dynamically swap in a new classloader or give Clojure's classloader a new parent classloader?
>
> I'm embedding Clojure in a parent app, and the parent app has its own classloader that keeps track of its own
classpath. It gives my embedded Clojure a pretty meager classpath such that I can't import anything
without add-classpath'ing first.
>
> One option is to shuttle the parent classpath over to Clojure iteratively using add-classpath. It would
be better and more elegant, though, if I could just link into the parent classloader directly.

Not exactly sure what you're referring to, or what exactly the layout
of your classloaders are, but classloaders are _in general_
hierarchical, with the parent having precedence. Meaning that if it's
on the parents classpath, then the parent classloader will load an
provide the class (that scheme is part of the security architecture
around the JVM to prevent unwanted code injection/manipulation).

If you're running in a container (appserver/servlet container/osgi
container/etc.), which is doing classloading tricks, then the answer
is going to be dependent on which container it is and how your app
fits in.

Cheers,
Daniel

Garth Sheldon-Coulson | 1 Aug 16:09 2009
Picon

Re: Bug in parallel.clj (and fix)


Brilliant. Can't wait to see this in action.

On 8/1/09, Rich Hickey <richhickey <at> gmail.com> wrote:
>
> On Fri, Jul 31, 2009 at 10:40 AM, Eric<ericwnormand <at> gmail.com> wrote:
>>
>> I tried to import clojure.parallel today and it didn't work.  It
>> couldn't find forkjoin.ParallelArray
>>
>> So I went hunting for it and it doesn't exist.  There is a
>> extra166y.ParallelArray.  In fact, all of the names imported were in
>> extra166y.  So I changed the line in parallel to reflect that.
>>
>> (import '(jsr166y.forkjoin ParallelArray ParallelArrayWithBounds
>> ParallelArrayWithFilter
>>                           ParallelArrayWithMapping
>>                           Ops$Op Ops$BinaryOp Ops$Reducer Ops
>> $Predicate Ops$BinaryPredicate
>>                           Ops$IntAndObjectPredicate Ops
>> $IntAndObjectToObject))
>>
>> changed to
>>
>> (import '(extra166y ParallelArray ParallelArrayWithBounds
>> ParallelArrayWithFilter
>>                           ParallelArrayWithMapping
>>                           Ops$Op Ops$BinaryOp Ops$Reducer Ops
>> $Predicate Ops$BinaryPredicate
>>                           Ops$IntAndObjectPredicate Ops
>> $IntAndObjectToObject))
>>
>>
>> This seems to fix it.
>
> You are right, ParallelArray has moved, but more important, isn't
> going to make it into Java 7. Due to that, and some prodding to look
> at the latest ForkJoin, I've started work on implementing parallel
> algorithms right on the Clojure persistent data structures using the
> lower-lever ForkJoin primitives.
>
> The work is in the 'par' branch on GitHub:
>
> http://github.com/richhickey/clojure/tree/par
>
> You'll need the jsr166y.jar I have built, placed in the same directory
> as build.xml:
>
> http://cloud.github.com/downloads/richhickey/clojure/jsr166y.jar
>
> And be building and running with Java 6.
>
> Right now there is just pvmap and pvreduce, both in the clojure.par
> namespace. Both take (Clojure) vectors, and, unlike pmap, are quite
> fast even for relatively small operations, i.e. (pvmap inc v) should
> be faster than (map inc v) for large vectors on multicore machines.
> The nice thing is pvmap returns a Clojure vector, so no need for the
> special data structures as with the older parallel library.
>
> The results are quite promising, and I look forward to implementing
> many parallel operations on Clojure's vectors and maps, and providing
> the tools for you to write your own.
>
> Feedback welcome,
>
> Rich
>
> >
>

--

-- 
Sent from my mobile device

Garth Sheldon-Coulson | 1 Aug 18:37 2009
Picon

Converting seqs to vectors & caching lazyseqs

Hi there,

I have a program that produces multidimensional LazySeqs, i.e. seqs of seqs of seqs of...

I would like to write a function to convert these multidimensional LazySeqs to vectors. This is in case a user needs constant lookup time.

The following function will do it:

(defn vectorize [obj]
  (if-not (seq? obj)
    obj
    (vec (map vectorize obj))))

(def foo (list 1 2 3 (list 1 2 4 (list 1 4)) 2))

(vectorize foo)
>> [1 2 3 [1 2 4 [1 4]] 2]

However, since there is no recur there, the function is liable to blow the stack on a very deep data structure (or so I gather from reading about Clojure's lack of TCO).

I cannot figure out how to write the function using recur. Any ideas?

More broadly, this would not be necessary if I could tell my LazySeqs to cache accesses and they cached them using a constant-lookup-time data structure. I've seen mention that LazySeqs cache access, but they don't seem to for me:

user=> (def foo (lazy-seq (range 10000000)))
user=> (time (nth foo 9999999))
"Elapsed time: 655.924286 msecs"
9999999
user=> (time (nth foo 9999999))
"Elapsed time: 675.42013 msecs"
9999999

Maybe I'm misunderstanding what is meant by caching.

Any thoughts on the vectorize function or caching?
Thanks.

Garth

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure <at> 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+unsubscribe <at> googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---

ataggart | 1 Aug 23:05 2009
Picon

Re: Converting seqs to vectors & caching lazyseqs


On Aug 1, 9:37 am, Garth Sheldon-Coulson <g... <at> mit.edu> wrote:
> Hi there,
>
> I have a program that produces multidimensional LazySeqs, i.e. seqs of seqs
> of seqs of...
>
> I would like to write a function to convert these multidimensional LazySeqs
> to vectors. This is in case a user needs constant lookup time.
>
> The following function will do it:
>
> (defn vectorize [obj]
>   (if-not (seq? obj)
>     obj
>     (vec (map vectorize obj))))
>
> (def foo (list 1 2 3 (list 1 2 4 (list 1 4)) 2))
>
> (vectorize foo)
>
> >> [1 2 3 [1 2 4 [1 4]] 2]
>
> However, since there is no recur there, the function is liable to blow the
> stack on a very deep data structure (or so I gather from reading about
> Clojure's lack of TCO).
>
> I cannot figure out how to write the function using recur. Any ideas?
>
> More broadly, this would not be necessary if I could tell my LazySeqs to
> cache accesses and they cached them using a constant-lookup-time data
> structure. I've seen mention that LazySeqs cache access, but they don't seem
> to for me:
>
> user=> (def foo (lazy-seq (range 10000000)))
> user=> (time (nth foo 9999999))
> "Elapsed time: 655.924286 msecs"
> 9999999
> user=> (time (nth foo 9999999))
> "Elapsed time: 675.42013 msecs"
> 9999999
>
> Maybe I'm misunderstanding what is meant by caching.

The results of realizing the seq are cached, but its still a list, so
the lookup is done in linear time.  I would guess that the times are
similar because the dominant factor is nth's traversal of the seq, not
range's generation of incremental ints; that or the hotspot hasn't
kicked in.

>
> Any thoughts on the vectorize function or caching?
> Thanks.
>
> Garth

Gmane