Re: "core.matrix" proposal

[Konrad Hinsen]

Mikera writes:

 > Initial tests seem to suggest that supporting N-dimensional arrays
 > should be pretty easy in terms of the API itself. We could also
 > provide fast-paths for 1D and 2D arrays.
 > 
 > Of course, actual support for N-dimensional arrays would depend on
 > the underlying implementation.

There are a few array implementations that support N-d arrays, for example
the ones in JHDF5 (https://wiki-bsse.ethz.ch/display/JHDF5) and in netCDF
(http://www.unidata.ucar.edu/software/netcdf-java/).

 > Yep, the idea is to be flexible enough to support many different 
 > implementations.

The real problem I see in making all this practically usable is
efficient conversion between implementations. The fragmentation of the
scientific computing ecosystem in Java makes it nearly impossible to
get any real work done without some conversion between array
libraries. If I want to read a matrix from an HDF5 file and then
calculate its eigenvalues, I need to convert from HDF5 arrays to Colt
(or whatever) arrays. Some libraries provide a way to construct an N-d
array from a 1-d data storage area plus a shape vector, without
copying the data. I think it's important to leverage such
functionality in a Clojure API in order to let conversion happen as
much as possible behind the scenes.

BTW, I started my own attempt at something similar a while ago, but
never found the time to get it to a usable state:

   https://code.google.com/p/clj-multiarray/

Konrad.

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

Re: Copying (immigrating) macros from namespace to namespace

[Vedang]

I remembered bookmarking a library that did something similar, so I
looked at my bookmarks. Here is Zach Tellman's "potemkin" library, you
might be interested in checking it out:
https://github.com/ztellman/potemkin

>From the README :

"Clojure’s namespaces conflate how you implement your code and how
it’s consumed by other code. This isn’t always a bad thing, but in
practice this means that large projects either have surprisingly large
source files (e.g. clojure.core) or a surprising number of namespaces
that have to all be used in concert to accomplish complex tasks (e.g.
Ring).

The former approach places an onus on the creator of the library; the
various orthogonal pieces of his library all coexist, which can make
it difficult to keep everything straight. The latter approach places
an onus on the consumers of the library, forcing them to remember
exactly what functionality resides where before they can actually use
it.

import-fn and import-macro decouple the structure of the code from the
structure of the API, allowing the library creator to structure the
code however he likes, without necessarily requiring that the
consumers have the same intimate understanding of that structure.

As someone who spends a fair amount of time worrying both about the
structure of the code and the presentation of the API, it’s helpful
not to have to think about how one affects the other. You might find
it helpful, too."

/vedang

On Mon, Jan 7, 2013 at 8:12 AM, Sean Corfield  wrote:
> On Sun, Jan 6, 2013 at 6:17 PM, Stuart Sierra
>  wrote:
>> 1. `refer`. Define a public function that `refer`s all the symbols you want.
>> It's an extra step for the user, but that's good because it makes it evident
>> that extra symbols are being added.
>
> Forcing all users of a library to refer a whole slew of symbols from
> another library that they don't even know they're using is horrible
> usability and really not a useful suggestion. The user should be able
> to (:require [main-library :refer [what i want]) without being forced
> to know about a transitive dependency and know which symbols come from
> which library, if the main-library developer wishes to provide a
> single, simple API.
>
> Could you explain exactly how this "breaks dynamic binding,
> with-redefs, and the ability to redefine functions at the REPL" given
> the scenario we're discussing? Remember that the whole purpose of this
> discussion is to essentially hide the underlying namespace from which
> symbols originate, and to present a single namespace with the desired
> API.
>
>> 2. `load`. If you have N namespaces with no clashing symbols, then you only
>> need one namespace. If you want to split it across multiple files, use
>> `load`. `clojure.core` does this.
>
> Fine if you control all of the source yourself.
>
> In the case of FW/1, I want a portion of Enlive available directly and
> easily to users of FW/1. Enlive is a transitive dependency - users of
> FW/1 don't need to know about it, and shouldn't really care.
>
> Since this appears to be a relatively common use case for library
> developers, perhaps a native Clojure solution that doesn't have the
> downsides you list would be worth adding? Perhaps some sort of (export
> some-ns/some-symbol) that makes *ns*/some-symbol appear like an exact
> public alias of some-ns/some-symbol? So users of the library see those
> exported symbols exactly as if they were declared in the library
> itself, rather than the third-party dependency, and could interact
> with them as such.
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles, LLC. -- http://worldsingles.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en



-- 
Unix is simple. It takes a genius to understand it's simplicity.-Anon
People think it must be fun to be a super genius, but they don't
realize how hard it is to put up with all the idiots in the world.
-Calvin.

Cheers,
Vedang.

Programmer,
Infinitely Beta.
http://twitter.com/vedang
http://vedang.me

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

Re: "core.matrix" proposal

[Mikera]

Yep, the idea is to be flexible enough to support many different 
implementations.

The pure Clojure version should be very easy to use and flexible since it 
uses regular Clojure persistent vectors. The trade-off is of less 
performance compared to the Java/native implementations.

As an added bonus, writing a pure Clojure version is useful for testing / 
validating the design of the API before we extend it to more complex 
implementations.

On Sunday, 6 January 2013 12:54:08 UTC+8, Rob Lachlan wrote:
>
> I really like this idea -- I think there's a need for a dedicated matrix 
> computation library in clojure.  I really like the idea of having matrix 
> operations implemented in clojure (I think that you have this in 
> persistent_vector.clj) but also being able to call on java libraries.
>
>
> On Saturday, January 5, 2013 2:00:23 AM UTC-8, Mikera wrote:
>>
>> Hello all,
>>
>> I've been experimenting with a common API / abstraction for matrix and 
>> vector maths in Clojure:
>>
>>   https://github.com/mikera/matrix-api
>>
>> The idea is:
>>  - Provide a clear, consistent API for matrix and vector operations
>>  - Support multiple different underlying implementations (e.g. native 
>> code via JBLAS vs pure Java like vectorz-clj)
>>  - Provide a base which other libraries that need to consume matrices can 
>> build upon (e.g. Incanter)
>>  - Offer good performance while still presenting a reasonably flexible 
>> high level API
>>
>> I think this could be very useful for the Clojure community, especially 
>> given the interest in big data, simulations, machine learning, 3D graphics 
>> etc. If it goes well and there is enough interest, I guess that this could 
>> form the basis for a future "core.matrix" library.
>>
>> Comments / ideas / patches welcome.
>>
>>   Mike.
>>
>

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

Re: "core.matrix" proposal

[Mikera]

Initial tests seem to suggest that supporting N-dimensional arrays should 
be pretty easy in terms of the API itself. We could also provide fast-paths 
for 1D and 2D arrays.

Of course, actual support for N-dimensional arrays would depend on the 
underlying implementation. 

On Monday, 7 January 2013 13:22:38 UTC+8, James Sofra wrote:
>
> +1 on Konrad's comment about N-dimensional arrays for me.
>
> I think the issue of using immutable arrays (which can be important for 
> performance) in Clojure is interesting to think about.
> I have had some ideas about how to use arrays with restricted or limited 
> mutability but haven't solidified anything yet.
>
> On Saturday, January 5, 2013 10:11:59 PM UTC+11, Konrad Hinsen wrote:
>>
>> Mikera writes: 
>>
>>  > I think this could be very useful for the Clojure community, 
>> especially given the 
>>  > interest in big data, simulations, machine learning, 3D graphics etc. 
>> If it goes well 
>>  > and there is enough interest, I guess that this could form the basis 
>> for a future 
>>  > "core.matrix" library. 
>>  > 
>>  > Comments / ideas / patches welcome. 
>>
>> I haven't looked at your library yet, but my immediate comment is that 
>> I'd much prefer to have an API for N-dimensional arrays rather than 
>> just for matrices (2d) and vectors (1d). 
>>
>> Konrad. 
>>
>

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

Re: "core.matrix" proposal

[James Sofra]

+1 on Konrad's comment about N-dimensional arrays for me.

I think the issue of using immutable arrays (which can be important for 
performance) in Clojure is interesting to think about.
I have had some ideas about how to use arrays with restricted or limited 
mutability but haven't solidified anything yet.

On Saturday, January 5, 2013 10:11:59 PM UTC+11, Konrad Hinsen wrote:
>
> Mikera writes: 
>
>  > I think this could be very useful for the Clojure community, especially 
> given the 
>  > interest in big data, simulations, machine learning, 3D graphics etc. 
> If it goes well 
>  > and there is enough interest, I guess that this could form the basis 
> for a future 
>  > "core.matrix" library. 
>  > 
>  > Comments / ideas / patches welcome. 
>
> I haven't looked at your library yet, but my immediate comment is that 
> I'd much prefer to have an API for N-dimensional arrays rather than 
> just for matrices (2d) and vectors (1d). 
>
> Konrad. 
>

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

Re: Unable to save the source file which loads repl

[Stephen Compall]

On Jan 6, 2013 10:22 PM, "Alice"  wrote:
> C:\>java -jar clojure-1.4.0.jar hello.clj
> user=>
>
> And then the file becomes read-only.
> I'm launching repl myself to avoid threading issue in my wpf project.
> (https://gist.github.com/3062194)

It's how Windows works.  You'll have to do something else, maybe wrap the
repl call in (future ...), maybe put your actual app in a separate file.

--
Stephen Compall
If anyone in the MSA is online, you should watch this flythrough.

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

Unable to save the source file which loads repl

[Alice]

c:\hello.clj:

  (clojure.main/repl)

C:\>java -jar clojure-1.4.0.jar hello.clj
user=>


And then the file becomes read-only.
I'm launching repl myself to avoid threading issue in my wpf project.
(https://gist.github.com/3062194)

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

Re: Copying (immigrating) macros from namespace to namespace

[Sean Corfield]

On Sun, Jan 6, 2013 at 6:17 PM, Stuart Sierra
 wrote:
> 1. `refer`. Define a public function that `refer`s all the symbols you want.
> It's an extra step for the user, but that's good because it makes it evident
> that extra symbols are being added.

Forcing all users of a library to refer a whole slew of symbols from
another library that they don't even know they're using is horrible
usability and really not a useful suggestion. The user should be able
to (:require [main-library :refer [what i want]) without being forced
to know about a transitive dependency and know which symbols come from
which library, if the main-library developer wishes to provide a
single, simple API.

Could you explain exactly how this "breaks dynamic binding,
with-redefs, and the ability to redefine functions at the REPL" given
the scenario we're discussing? Remember that the whole purpose of this
discussion is to essentially hide the underlying namespace from which
symbols originate, and to present a single namespace with the desired
API.

> 2. `load`. If you have N namespaces with no clashing symbols, then you only
> need one namespace. If you want to split it across multiple files, use
> `load`. `clojure.core` does this.

Fine if you control all of the source yourself.

In the case of FW/1, I want a portion of Enlive available directly and
easily to users of FW/1. Enlive is a transitive dependency - users of
FW/1 don't need to know about it, and shouldn't really care.

Since this appears to be a relatively common use case for library
developers, perhaps a native Clojure solution that doesn't have the
downsides you list would be worth adding? Perhaps some sort of (export
some-ns/some-symbol) that makes *ns*/some-symbol appear like an exact
public alias of some-ns/some-symbol? So users of the library see those
exported symbols exactly as if they were declared in the library
itself, rather than the third-party dependency, and could interact
with them as such.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: Copying (immigrating) macros from namespace to namespace

[Leonardo Borges]

On Mon, Jan 7, 2013 at 1:17 PM, Stuart Sierra
 wrote:
> I've said it before and I will keep saying it: copying symbols by interning
> vars breaks the identity of the original vars. It breaks dynamic binding,
> with-redefs, and the ability to redefine functions at the REPL.
>
> Clojure has a two perfectly good mechanisms for making vars available in
> other namespaces:
>
> 1. `refer`. Define a public function that `refer`s all the symbols you want.
> It's an extra step for the user, but that's good because it makes it evident
> that extra symbols are being added.
>

So this would be no different than having the user put an extra 'use'
call to use any additional namespaces right? In this case I'd rather
have the user explicitly perform the  "use" call instead of "refer",
like this:

(require '[bouncer.core :as b])
(use '[bouncer.validators :only [defvalidator])

Which is what I recommend at the moment.

> 2. `load`. If you have N namespaces with no clashing symbols, then you only
> need one namespace. If you want to split it across multiple files, use
> `load`. `clojure.core` does this.
>

This sounds like what I want. I'll look into it, thanks.

Leo.

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

Re: Copying (immigrating) macros from namespace to namespace

[Stuart Sierra]

I've said it before and I will keep saying it: copying symbols by interning 
vars breaks the identity of the original vars. It breaks dynamic binding, 
with-redefs, and the ability to redefine functions at the REPL.

Clojure has a two perfectly good mechanisms for making vars available in 
other namespaces: 

1. `refer`. Define a public function that `refer`s all the symbols you 
want. It's an extra step for the user, but that's good because it makes it 
evident that extra symbols are being added.

2. `load`. If you have N namespaces with no clashing symbols, then you only 
need one namespace. If you want to split it across multiple files, use 
`load`. `clojure.core` does this.

-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

Re: Copying (immigrating) macros from namespace to namespace

[Leonardo Borges]

+1

I was thinking of doing the same in the validation lib I published
recently [1] and this thread came in handy. I haven't implemented it
yet but having a common way in which people do this seems reasonable -
if it's in core then all the better.

Cheers,
Leo


[1] - https://github.com/leonardoborges/bouncer
Leonardo Borges
www.leonardoborges.com


On Mon, Jan 7, 2013 at 12:04 PM, Brian Marick  wrote:
>
> On Jan 6, 2013, at 3:34 PM, Sean Corfield  wrote:
>
>> Here's what I use to pull symbols from Enlive into FW/1:
>
>
> Midje plays similar tricks to make namespace abilities available via one 
> `use`.
>
> Which makes me think:
>
> 1: In the old patterns world, there was a "rule of three" which claimed that 
> something shouldn't be published as a pattern until it could be demonstrated 
> in three real systems.
>
> 2: Lispers like Gabriel and others noted that what were patterns in languages 
> like Smalltalk and C++ were built into Lisp or were easily regularized 
> in-language with macros.
>
> Therefore: to me, this email thread suggests that the ability to do such 
> consolidation should be immortalized not in email examples of patterns 
> ("here's how I accomplished X") but - in a more Lispy fashion - by writing a 
> common library and making it available to the user base. That is: functions 
> like Adam's and Sean's and mine should be in some official library close to 
> clojure.core.
>
> 
> Occasional consulting on programming technique
> Contract programming in Ruby and Clojure
> Latest book: /Functional Programming for the Object-Oriented Programmer/
> https://leanpub.com/fp-oo
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: Copying (immigrating) macros from namespace to namespace

[Brian Marick]

On Jan 6, 2013, at 3:34 PM, Sean Corfield  wrote:

> Here's what I use to pull symbols from Enlive into FW/1:


Midje plays similar tricks to make namespace abilities available via one `use`. 

Which makes me think:

1: In the old patterns world, there was a "rule of three" which claimed that 
something shouldn't be published as a pattern until it could be demonstrated in 
three real systems. 

2: Lispers like Gabriel and others noted that what were patterns in languages 
like Smalltalk and C++ were built into Lisp or were easily regularized 
in-language with macros.

Therefore: to me, this email thread suggests that the ability to do such 
consolidation should be immortalized not in email examples of patterns ("here's 
how I accomplished X") but - in a more Lispy fashion - by writing a common 
library and making it available to the user base. That is: functions like 
Adam's and Sean's and mine should be in some official library close to 
clojure.core. 


Occasional consulting on programming technique
Contract programming in Ruby and Clojure
Latest book: /Functional Programming for the Object-Oriented Programmer/
https://leanpub.com/fp-oo

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

Clojure/Script pr-str/read-string roundtrip differences

[Thomas Heller]

Hey,

I'm writing a Clojure Webapp with a CLJS Frontend and expected to be able 
to cljs.reader/read-string everything I pr-str'd on the CLJ side. That 
however does not work for defrecords and BigDecimals (1.1M) .

1. defrecord

In CLJ I can:

(ns dummy)
(defrecord Foo [bar])
(pr-str (Foo. 1)) ; => "#dummy.Foo{:bar 1}"

in CLJS however this will print as

"#Foo{:bar 1}"

missing the Namespace. I found an old 
postabout 
this but no other information.

Also when I pr-str this record in CLJ and cljs.reader/read-string it in 
CLJS it fails with "Could not find tag parser for dummy.Foo in ("inst" 
"uuid" "queue") ", although the defrecord exists and is in the same ns 
(actually a cljsbuild crossover). I figured out that I can 
(cljs.reader/register-tag-parser! 'dummy.Foo make-foo) but thats seems 
faulty. I read about EDN and understand why the reader would think its 
reading a Tag but I can do read-string in CLJ just fine. Shouldnt both 
sides be equal here?

2. BigDecimals:

I understand that JavaScript has no BigDecimals and I can live with 
js/parseFloat on the Client for now, however is there any way I can hint 
the CLJS printer to print "1.1" as "1.1M"?

On the Topic of EDN: How would I "tag" a value in CLJ(S) to print {:foo 
"bar"} as #my/tag {:foo "bar"}? The docs only talk about data_readers.clj.

The answers probably lie in the sources, but I hope somebody here has a 
quick answer. ;)

Cheers,
/thomas

PS: I'd actually prefer using "tagged" literals instead of the defrecord 
constructor form since I dont trust anything coming from the client even it 
looks like clojure data. Is there some protocol I can implement for the 
record and have it print as tagged instead? For CLJ and CLJS? :)


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

Re: Suggestion: add `into` on clojure.org/data_structures page

[Sean Corfield]

And there's also the excellent http://clojureatlas.com for exploring
concepts and their implementations within the Clojure ecosystem.

On Sun, Jan 6, 2013 at 3:08 PM, Andy Fingerhut  wrote:
> For most of the documentation on clojure.org, only a few people have
> authorization to modify it.  You could create a JIRA ticket suggesting a
> change here:
>
> http://dev.clojure.org/jira/browse/CLJ
>
> Such tickets can take anywhere from a few days to many months before someone
> acts upon them, depending upon the severity of the issue.
>
>
> I'm not sure if you were looking for the info below, but here are some other
> sources of Clojure documentation:
>
> http://clojure-doc.org takes pull requests on github from anyone wanting to
> make changes to it.
>
> http://clojuredocs.org lets anyone with a free-and-quick-to-create account
> add examples or edit existing ones, add "see also" links, etc.
>
> There are auto-generated docs from source by going to clojure.org, clicking
> Documentation, then "API Documentation".  That is hosted on github, too.
>
> http://clojure.org/cheatsheet has one way of organizing Clojure symbols.  By
> clicking the link "Download other versions with tooltips" near the top of
> that page, you can find versions of the cheatsheet that show the
> documentation of the symbols when you hover your mouse over them.
>
> Andy
>
> On Jan 6, 2013, at 2:10 PM, David James wrote:
>
> I noticed that `into` is not currently mentioned on
> http://clojure.org/data_structures
>
> How do community-suggested documentation changes work? Is there a wiki?
> Auto-generated docs from source?
>
> Thanks,
> David
>
> --
> 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



-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: Suggestion: add `into` on clojure.org/data_structures page

[Andy Fingerhut]

For most of the documentation on clojure.org, only a few people have 
authorization to modify it.  You could create a JIRA ticket suggesting a change 
here: 

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

Such tickets can take anywhere from a few days to many months before someone 
acts upon them, depending upon the severity of the issue.


I'm not sure if you were looking for the info below, but here are some other 
sources of Clojure documentation:

http://clojure-doc.org takes pull requests on github from anyone wanting to 
make changes to it.

http://clojuredocs.org lets anyone with a free-and-quick-to-create account add 
examples or edit existing ones, add "see also" links, etc.

There are auto-generated docs from source by going to clojure.org, clicking 
Documentation, then "API Documentation".  That is hosted on github, too.

http://clojure.org/cheatsheet has one way of organizing Clojure symbols.  By 
clicking the link "Download other versions with tooltips" near the top of that 
page, you can find versions of the cheatsheet that show the documentation of 
the symbols when you hover your mouse over them.

Andy

On Jan 6, 2013, at 2:10 PM, David James wrote:

> I noticed that `into` is not currently mentioned on 
> http://clojure.org/data_structures
> 
> How do community-suggested documentation changes work? Is there a wiki? 
> Auto-generated docs from source?
> 
> Thanks,
> David

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

Suggestion: add `into` on clojure.org/data_structures page

[David James]

I noticed that `into` is not currently mentioned on
http://clojure.org/data_structures

How do community-suggested documentation changes work? Is there a wiki?
Auto-generated docs from source?

Thanks,
David

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

Re: Copying (immigrating) macros from namespace to namespace

[Sean Corfield]

Here's what I use to pull symbols from Enlive into FW/1:

(def ^:private enlive-symbols
  ['append 'at 'clone-for 'content 'do-> 'html-content 'prepend
'remove-class 'set-attr 'substitute])

(defmacro enlive-alias ^:private [sym]
  `(let [enlive-sym# (resolve (symbol (str "html/" ~sym)))]
 (intern *ns* (with-meta ~sym (meta enlive-sym#)) (deref enlive-sym#

This pulls in both functions and macros. It hard-codes the alias for
Enlive (html, for net.cgrand.enlive-html) but otherwise should serve
your needs. FW/1 uses it like this:

(doseq [sym enlive-symbols]
  (enlive-alias sym))

Sean

On Sun, Jan 6, 2013 at 12:19 PM, the80srobot  wrote:
> I have come up with a solution to a problem I don't think exists outside of
> my mind, but since I can't for the life of me figure out how Clojure 'wants'
> me to do this, I thought I would bounce this off the Google Group.
>
> The scenario: I am trying to collect a bunch of functions and macros from
> all the different namespaces in my library into a single namespace; let's
> call the namespace adams-lib.api. The idea is that the consumer of the
> library will only have to include that one API namespace, and not all of the
> little namespaces with parts of the functionality.
>
> The problem: Obviously, calling (use) doesn't cut it, because the aliased
> vars are not immigrated by subsequent calls to the (use) of the namespace
> that (used) them. You know what I mean.
>
> The "solution": For functions this is simpler, but macros pose some
> additional challenges, which is why I'm including my "solution" for
> immigrating macros. Hold on to your hats, this one is ugly:
>
> (defmacro immigrate-macro
>   [ns-sym macro-sym]
>   `(let [ nspublics# (ns-publics '~ns-sym)
>   macro-var# (nspublics# '~macro-sym)
>   macro-fn# @macro-var#
>   macro-meta# (meta macro-var#)]
> (def ~macro-sym macro-fn#)
> (. (var ~macro-sym) (setMacro))
> (reset-meta! (var ~macro-sym) macro-meta#))
> nil)
>
>
> And using it:
>
> (immigrate-macro adams-lib.some-other-ns some-macro)
>
>
> There has got to be a simpler/better/less insane way of doing this. Would
> anyone care to weigh in? For the record, I fully realize that my solution is
> not OK.
>
> -Adam
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en



-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

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

Re: core.match gotcha

[Chas Emerick]

On Jan 6, 10:48 am, Ambrose Bonnaire-Sergeant
 wrote:
> On a related note, combining a quoted symbol and a named wildcard pattern
> seems to be buggy.
>
> clojure.core.match=> (match 'my-sym a a)
> # ocr-3612 in this context, compiling:(REPL:79)>
> clojure.core.match=> (macroexpand-1 '(match 'my-sym a a))
> (clojure.core/let [a ocr-3620] a)

Ticket opened here FWIW:

   http://dev.clojure.org/jira/browse/MATCH-66

- Chas

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

Copying (immigrating) macros from namespace to namespace

[the80srobot]

I have come up with a solution to a problem I don't think exists outside of 
my mind, but since I can't for the life of me figure out how Clojure 
'wants' me to do this, I thought I would bounce this off the Google Group.

*The scenario:* I am trying to collect a bunch of functions and macros from 
all the different namespaces in my library into a single namespace; let's 
call the namespace adams-lib.api. The idea is that the consumer of the 
library will only have to include that one API namespace, and not all of 
the little namespaces with parts of the functionality.

*The problem:* Obviously, calling (use) doesn't cut it, because the aliased 
vars are not immigrated by subsequent calls to the (use) of the namespace 
that (used) them. You know what I mean.

*The "solution": *For functions this is simpler, but macros pose some 
additional challenges, which is why I'm including my "solution" for 
immigrating macros. Hold on to your hats, this one is ugly:

(defmacro immigrate-macro
  [ns-sym macro-sym]
  `(let [ nspublics# (ns-publics '~ns-sym)
  macro-var# (nspublics# '~macro-sym)
  macro-fn# @macro-var#
  macro-meta# (meta macro-var#)]
(def ~macro-sym macro-fn#)
(. (var ~macro-sym) (setMacro))
(reset-meta! (var ~macro-sym) macro-meta#))
nil)


And using it:

(immigrate-macro adams-lib.some-other-ns some-macro)


There has got to be a simpler/better/less insane way of doing this. Would 
anyone care to weigh in? For the record, I fully realize that my solution 
is not OK.

-Adam

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

Re: Extracting map values matching a pattern

[Stephen Compall]

On Jan 6, 2013 1:55 PM, "Jonathon McKitrick"  wrote:
> My first thought is to simply iterate the web parameter map, and convert
each key to a string using NAME and then a regex on the name.  Is there a
better way?

If the numeric range may not be contiguous or start at 0 or 1, and you do
not need to process them in numeric order, your suggested approach is fine.

--
Stephen Compall
If anyone in the MSA is online, you should watch this flythrough.

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

Extracting map values matching a pattern

[Jonathon McKitrick]

I have a web handler which will take any number of parameters beginning 
with 'q' and a number, like 'q1', 'q2', etc.  I want to iterate and operate 
on just those parameters.

My first thought is to simply iterate the web parameter map, and convert 
each key to a string using NAME and then a regex on the name.  Is there a 
better way?

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

Re: core.match gotcha

[Chas Emerick]

On Jan 6, 2013, at 10:48 AM, Ambrose Bonnaire-Sergeant wrote:

> On a related note, combining a quoted symbol and a named wildcard pattern 
> seems to be buggy.
> 
> clojure.core.match=> (match 'my-sym a a)
> # ocr-3612 in this context, compiling:(REPL:79)>
> clojure.core.match=> (macroexpand-1 '(match 'my-sym a a))
> (clojure.core/let [a ocr-3620] a)

Yeah, I've hit that, but presumed I was just doing something wrong. :-)

> I included a section on how symbols work as patterns.

Perfect, reads very well.  I'm glad I didn't just add something, it would not 
have been as clear or succinct.

> Interestingly, the old design page still has some good stuff, including an 
> explanation of this particular issue.
> I'm not sure how much is still relevant.
> 
> https://github.com/clojure/core.match/wiki/Design-Wiki

Ach, I hadn't thought to look at what else might be lurking in the wiki!  The 
'Local Bindings' section on the design page would have made it all obvious.

Thanks!

- Chas

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

core.match gotcha

[Chas Emerick]

I've recently started using core.match, which has been quite pleasant and 
successful; thank you to David Nolen, and all others that have contributed.

The only hiccup I've had has been around how core.match incorporates bindings 
from local scope into pattern rows.  A stupid example demonstrating the 
(potential) confusion:

=> (match [[:k]]
 [[x]] x)
:k

vs.

=> (let [x 12]
 (match [[:k]]
   [[x]] x))
nil

I was assuming that bindings established by the wildcards in pattern rows 
shadowed any other local bindings.  It took me a while to realize that, e.g. in 
the example above, `x` was being interpolated into `[[x]]` to yield a pattern 
row of `[[12]]`.  Now that I know that, all's well; but, it took me perhaps 
longer than it should have to figure it out.

All this is to say, perhaps a relevant note in the (really excellent) overview 
wiki page[1] might be helpful.

Thanks,

- Chas

[1] https://github.com/clojure/core.match/wiki/Overview

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

ANN clj-javafx 0.2

[Christian Sperandio]

Hi,

I released the version 0.2 of clj-javafx.
You can find it here: 
https://github.com/chrix75/clj-javafx/tree/clj-javafx/0.2

As a reminder, this project helps you out to use JavaFX with Clojure.
You have information about this project in the Wiki pages.

Chris

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

Upcoming London Clojurian Events

[Bruce Durling]

Roll up! Roll up!

We have 2 Clojure events coming up in the next 7 days here are the details!

- Bodil Stokke and ClojureScript all the way down
Thursday 10 January at Skills Matter 18:30
http://skillsmatter.com/event/scala/clojurescript-all-the-way-down

Node.js is really hip these days. Of course, a barrier to adoption for
any sensible programmer is the fact that while the opportunities it
provides for network programming are shiny and brilliant, it expects
you to write your code in Javascript, a language born with so many
design flaws it makes you pine for the halcyon days of COBOL.

-  Clojure Hammock Weekend
Sunday 13 January at Forward Technology 10:00 - 22:00
http://clojure-hammock-weekend.eventbrite.com/

Tommy Hall says:

I just competed in the Node Knockout and while I quite like Node I
prefer clojure and was thinking of doing something similar.

The format of a sleep deprived weekend cranking out a webapp does not
feel a good fit for the clojure culture, which seems to me a bit more
mature and reflective so I thought the following might be fun.

Fri: Meet for dinner with you team to discuss ideas. Go to sleep early
(and not too drunk)
Sat: Go for a walk somewhere nice as a team to discuss. Eat nice food,
sleep early (in a hammock maybe, again not too drunk)
Sun: For some of the hours between 10am and 10pm, build something. A
library, a webapp, whatever you like.

The contest will be judged by the contestants, I'll build some sort of
voting app beforehand.


I hope to see you all there or at the other 5 clojure events coming up
in the next 32 days!

cheers,
Bruce

--
@otfrom | CTO & co-founder @MastodonC | mastodonc.com
See recent coverage of us in the Economist http://econ.st/WeTd2i and
the Financial Times http://on.ft.com/T154BA

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

Re: Clojure Conj Videos

[kinleyd]

You are right Alex. I got it mixed up since I've been waiting for both the 
Strange Loop and the Clojure Conj talks on InfoQ.

On Sunday, January 6, 2013 7:29:15 AM UTC+6, Alex Miller wrote:
>
> Barski hasn't spoken at Strange Loop, perhaps you mean his talk at the 
> conj?
>
> On Friday, January 4, 2013 3:30:55 AM UTC-6, kinleyd wrote:
>>
>> Thanks for taking the trouble Alex - that was pretty comprehensive. I've 
>> seen Rathore's and Nolen's (both excellent), skipped Stokke's (but only 
>> because Catnip didn't interest me) and was looking forward to Barski (but 
>> don't see him on the horizon though his talk was delivered a while back). I 
>> will now go through the others that you have listed. 
>>
>> On Friday, January 4, 2013 9:45:06 AM UTC+6, Alex Miller wrote:
>>>
>>> The full Strange Loop video schedule is here: 
>>> https://thestrangeloop.com/news/strange-loop-2012-video-schedule
>>>
>>> Re Clojure talks, 
>>>
>>> Already released related in some way to Clojure and ClojureScript:
>>> - Nathan Marz on big data - 
>>> http://www.infoq.com/presentations/Complexity-Big-Data
>>> - Jim Weirich on Y Combinator - 
>>> http://www.infoq.com/presentations/Y-Combinator
>>> - Chris Granger on Light Table - 
>>> http://www.infoq.com/presentations/Learn-Tools
>>> - David Nolen on ClojureScript - 
>>> http://www.infoq.com/presentations/ClojureScript-Optimizations
>>> - Amit Rathore on Clojure+Datomic+Storm - 
>>> http://www.infoq.com/presentations/Zolodeck
>>> - Bodil Stokke on Catnip IDE and ClojureScript - 
>>> http://www.infoq.com/presentations/Catnip
>>>
>>> Still to be released:
>>> - Jason Wolfe's talk on the Prismatic Graph library is coming out week 
>>> of Jan 28th
>>> - Kevin Lynagh's talk on his ClojureScript visualization lib is week of 
>>> Feb 11th
>>> - Rich Hickey's talk is scheduled for week of Mar 18th but same one has 
>>> already been released on InfoQ so not sure if they'll re-release it
>>> - Stuart Sierra's talk on functional design patterns is week of Apr 1st
>>>
>>> Sorry if I missed any.
>>>
>>> Alex
>>>
>>> On Thursday, January 3, 2013 2:43:39 AM UTC-6, kinleyd wrote:

 I've been waiting forever for the recent Strange Loop Clojure talks to 
 be made available as well. So far I've only seen two, Amit Rathore's 
 "Clojure + Datomic + Stomr = Zolodeck" and David Nolen's "ClojureScript - 
 Better semantics at low, low prices" on InfoQ. Any one have any idea when 
 the others will be made available? 

 On Thursday, January 3, 2013 2:26:18 PM UTC+6, CA wrote:
>
> Let the party begin :-)
>
> On Thursday, January 3, 2013 2:02:41 AM UTC+1, Lynn Grogan wrote:
>>
>> Confreaks is just completing the final edits on the videos and we 
>> should be releasing them soon (in a week or so?). 
>> Of course, it will probably be a staggered release just to drive 
>> everyone crazy ;) 
>>
>> Lynn Grogan
>> Relevance
>>
>> On Wednesday, January 2, 2013 7:12:03 PM UTC-5, Sean Corfield wrote:
>>>
>>> On Wed, Jan 2, 2013 at 3:42 PM, Mark Derricutt  
>>> wrote: 
>>> > 
>>> > +1 - I'm sure I've even seen any BLOGS on this years Conj let 
>>> alone videos. 
>>>
>>> http://corfield.org/blog/post.cfm/clojure-conj-2012 
>>> -- 
>>> Sean A Corfield -- (904) 302-SEAN 
>>> An Architect's View -- http://corfield.org/ 
>>> World Singles, LLC. -- http://worldsingles.com/ 
>>>
>>> "Perfection is the enemy of the good." 
>>> -- Gustave Flaubert, French realist novelist (1821-1880) 
>>>
>>

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

Re: Google+ community

[kinleyd]

Well, thanks @dspiteself for bringing up the topic. I like the interaction 
at G+ and joined the larger G+ Clojure community as a result of this thread.


On Sunday, January 6, 2013 3:51:26 AM UTC+6, dspiteself wrote:
>
> Thanks I am surprised I did not see it when I created it a week or 2 ago.
> I deleted it so we can congregate at one.
>
> On Saturday, January 5, 2013 2:17:43 PM UTC-6, JM Ibanez wrote:
>>
>>  FWIW, there's already this existing Clojure community: 
>>
>> https://plus.google.com/u/0/communities/103410768849046117338
>>
>> -- 
>> JM Ibanez
>> jmib...@gmail.com
>> http://jmibanez.com/
>>
>> Sent with Sparrow 
>>
>> On Sunday, January 6, 2013 at 4:15 AM, dspiteself wrote:
>>
>> I started a google plus 
>> community. 
>>  
>> I know most of the Clojure community is generally more into twitter, but 
>> I have been enjoying Google+ communities very much. It could be a great 
>> more externally visible venue for some of the conversation that happen on 
>> google groups. 
>> It also has the effect off make your search results of people and people 
>> in your circles and communities show up higher. 
>>
>>  -- 
>> 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 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