[ANN] May London Clojure Dojo at Forward

[Bruce Durling]

Roll up! Roll up!

The Next London Clojure Dojo is at Forward in beautiful and
conveniently located Camden Town:

Sign up here: http://ldnclj-may-fwd.eventbrite.com/

Time and Dates:

May 2013 London Clojure Dojo at Forward
London Clojurians
Monday, 13 May 2013 at 18:30 (BST)

Location:

Forward Internet Group
19 Mandela St
NW1 0DU London
United Kingdom

I hope to see you all there!

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

Two new Clojure projects

[Kelker Ryan]

I just wanted to share two new Clojure projects. Porta is a Clojure utility that generates a Clojure abstraction for an existing Java Class.https://github.com/runexec/porta CHP (ClojureHomePage) is a project that aims at making Clojure web development as easy as PHP.https://github.com/runexec/chp   



-- 
-- 
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 clojure.lang.Compiler.LOADER is null in clojure 1.5.1

[stream]

Hi all

i wanna change the classloader of Clojure RT. in 1.5.1
so , i try to 
clojure.lang.Var.pushThreadBindings(clojure.lang.RT.map( 
clojure.lang.Compiler.LOADER, cl) );

but throws exception that cojure.lang.Compiler.LOADER is null

Caused by: java.lang.NullPointerException
at clojure.lang.RT.baseLoader(RT.java:2043)
at clojure.lang.RT.load(RT.java:417)
at clojure.lang.RT.load(RT.java:411)
at clojure.lang.RT.doInit(RT.java:447)
at clojure.lang.RT.(RT.java:329)
... 9 more


However this is work in the 1.4.0

someone could tell me what had happened in 1.5.1
thanks

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

Lisp In Summer Projects

[Tim Daly]

If you have a Clojure project you could earn money and fame.
Check out "Lisp In Summer Projects"
http://lispinsummerprojects.org/?2013

Heow-Eide Goodman, the man behind LispNYC, is getting a group of
experts together to judge the projects. You'll get your name in
front of some well-connected people, a nice check, and a chance
to speak at a LISP conference.

Best of all, they don't even have to be literate programs! :-)

Tim Daly
Elder of the Internet

-- 
-- 
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 clojure.lang.Compiler.LOADER is null in clojure 1.5.1

[semperos]

Is there a reason you don't use one of the methods exposed in 
clojure.lang.RT, e.g., makeClassLoader() or baseLoader() ?

On Thursday, May 9, 2013 2:00:54 AM UTC-4, Stream wrote:
>
> Hi all 
>
> i wanna change the classloader of Clojure RT. in 1.5.1 
> so , i try to 
> clojure.lang.Var.pushThreadBindings(clojure.lang.RT.map( 
> clojure.lang.Compiler.LOADER, cl) ); 
>
> but throws exception that cojure.lang.Compiler.LOADER is null 
>
> Caused by: java.lang.NullPointerException 
> at clojure.lang.RT.baseLoader(RT.java:2043) 
> at clojure.lang.RT.load(RT.java:417) 
> at clojure.lang.RT.load(RT.java:411) 
> at clojure.lang.RT.doInit(RT.java:447) 
> at clojure.lang.RT.(RT.java:329) 
> ... 9 more 
>
>
> However this is work in the 1.4.0 
>
> someone could tell me what had happened in 1.5.1 
> thanks

-- 
-- 
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: Lisp In Summer Projects

[Nico Balestra]

Contest is also not open to residents of Brazil, Italy, Quebec, and Saudi
Arabia

I'm UK resident but born Italian and I find the above a bit distressing.


*"It is better to have 100 functions operate on one data structure than to
have 10 functions operate on 10 data structures" - A.J. Perlis*


On 9 May 2013 14:05, Tim Daly  wrote:

> If you have a Clojure project you could earn money and fame.
> Check out "Lisp In Summer Projects"
> http://lispinsummerprojects.org/?2013
>
> Heow-Eide Goodman, the man behind LispNYC, is getting a group of
> experts together to judge the projects. You'll get your name in
> front of some well-connected people, a nice check, and a chance
> to speak at a LISP conference.
>
> Best of all, they don't even have to be literate programs! :-)
>
> Tim Daly
> Elder of the Internet
>
> --
> --
> 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: Lisp In Summer Projects

[Plínio Balduino]

'(sad)

On Thu, May 9, 2013 at 11:58 AM, Nico Balestra  wrote:
> Contest is also not open to residents of Brazil, Italy, Quebec, and Saudi
> Arabia
>
> I'm UK resident but born Italian and I find the above a bit distressing.
>
>
> "It is better to have 100 functions operate on one data structure than to
> have 10 functions operate on 10 data structures" - A.J. Perlis
>
>
> On 9 May 2013 14:05, Tim Daly  wrote:
>>
>> If you have a Clojure project you could earn money and fame.
>> Check out "Lisp In Summer Projects"
>> http://lispinsummerprojects.org/?2013
>>
>> Heow-Eide Goodman, the man behind LispNYC, is getting a group of
>> experts together to judge the projects. You'll get your name in
>> front of some well-connected people, a nice check, and a chance
>> to speak at a LISP conference.
>>
>> Best of all, they don't even have to be literate programs! :-)
>>
>> Tim Daly
>> Elder of the Internet
>>
>> --
>> --
>> 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: why clojure.lang.Compiler.LOADER is null in clojure 1.5.1

[AtKaaZ]

Caused by: java.lang.NullPointerException
at clojure.lang.RT.*baseLoader*(RT.java:2043)

hmm, it's almost as if:
static final public Var LOADER = Var.create().setDynamic();
had no effect as in: LOADER=null;



On Thu, May 9, 2013 at 4:51 PM, semperos wrote:

> Is there a reason you don't use one of the methods exposed in
> clojure.lang.RT, e.g., makeClassLoader() or baseLoader() ?
>
>
> On Thursday, May 9, 2013 2:00:54 AM UTC-4, Stream wrote:
>>
>> Hi all
>>
>> i wanna change the classloader of Clojure RT. in 1.5.1
>> so , i try to
>> clojure.lang.Var.**pushThreadBindings(clojure.**lang.RT.map(
>> clojure.lang.Compiler.LOADER, cl) );
>>
>> but throws exception that cojure.lang.Compiler.LOADER is null
>>
>> Caused by: java.lang.NullPointerException
>> at clojure.lang.RT.baseLoader(RT.**java:2043)
>> at clojure.lang.RT.load(RT.java:**417)
>> at clojure.lang.RT.load(RT.java:**411)
>> at clojure.lang.RT.doInit(RT.**java:447)
>> at clojure.lang.RT.(RT.**java:329)
>> ... 9 more
>>
>>
>> However this is work in the 1.4.0
>>
>> someone could tell me what had happened in 1.5.1
>> thanks
>
>  --
> --
> 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.

Struggling with encapsulation

[Colin Yates]

(newbie, but trying hard!)

I am designing a Woobly.  A Woobly is non-trivial and has a number of 
internal data structures (queues, worker threads etc.).  You can 'add' and 
'remove' jobs from a Woobly.

In OO land I might have a Woobly interface with the various methods which 
provides a public API.  I might also have a factory or more likely builder 
somewhere which creates Wooblies.  

The part I am struggling with is how to create a Woobly without exposing 
its internals.  Let's imagine that Woobly uses an internal 
LinkedBlockingQueue of a certain size.

Option 1 - a big bag of data.
I could create a map of config/state/data that comprises the implementation 
and have the creator function return that.  Consumers can then call other 
methods passing back that bag of config/state, but what stops them simply 
diving into that bag themselves?  For example:

[code]
(defn create-woobly
 ([] (create-woobly 100)
 ([queue-size] {:queue (java.util.concurrent.LinkedBlockingQueue 
queue-size)}))

(defn add-job [woobly job] )

;; nothing stopping me diving into that state...
(.clear (:queue (create-wobbly)))
[/code]

Option 2 - protocol and deftype
Alternatively I could implement an IWoobly protocol and create a single 
deftype which is instantiated and returned from the 'create-woobly' 
function?  I am not sure I like this as it is really back to OO isn't it?  

I want to retain the notion of create returning a handle which is the first 
argument in the other public functions, but the first way just feels far 
too dangerous. 

Am I overthinking this - what do you all do to address this?

Thanks a bunch.

Col

-- 
-- 
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 clojure.lang.Compiler.LOADER is null in clojure 1.5.1

[AtKaaZ]

is there any chance that we can see the full code (maybe's on github
already?)


On Thu, May 9, 2013 at 9:00 AM, stream  wrote:

> Hi all
>
> i wanna change the classloader of Clojure RT. in 1.5.1
> so , i try to
> clojure.lang.Var.pushThreadBindings(clojure.lang.RT.map(
> clojure.lang.Compiler.LOADER, cl) );
>
> but throws exception that cojure.lang.Compiler.LOADER is null
>
> Caused by: java.lang.NullPointerException
> at clojure.lang.RT.baseLoader(RT.java:2043)
> at clojure.lang.RT.load(RT.java:417)
> at clojure.lang.RT.load(RT.java:411)
> at clojure.lang.RT.doInit(RT.java:447)
> at clojure.lang.RT.(RT.java:329)
> ... 9 more
>
>
> However this is work in the 1.4.0
>
> someone could tell me what had happened in 1.5.1
> thanks
>
> --
> --
> 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: Lisp In Summer Projects

[Nico Balestra]

..after reading the FAQ I know have the answer why Italians are not
eligible:

*Q: Why do you hate Italians?*
A: We're not sure why Italy is ineligible, contact
us if
you're an Italian lawyer willing to help us out.

It might be because Italians have too many parenthesis in their laws :)

*"It is better to have 100 functions operate on one data structure than to
have 10 functions operate on 10 data structures" - A.J. Perlis*


On 9 May 2013 16:49, Plínio Balduino  wrote:

> '(sad)
>
> On Thu, May 9, 2013 at 11:58 AM, Nico Balestra 
> wrote:
> > Contest is also not open to residents of Brazil, Italy, Quebec, and Saudi
> > Arabia
> >
> > I'm UK resident but born Italian and I find the above a bit distressing.
> >
> >
> > "It is better to have 100 functions operate on one data structure than to
> > have 10 functions operate on 10 data structures" - A.J. Perlis
> >
> >
> > On 9 May 2013 14:05, Tim Daly  wrote:
> >>
> >> If you have a Clojure project you could earn money and fame.
> >> Check out "Lisp In Summer Projects"
> >> http://lispinsummerprojects.org/?2013
> >>
> >> Heow-Eide Goodman, the man behind LispNYC, is getting a group of
> >> experts together to judge the projects. You'll get your name in
> >> front of some well-connected people, a nice check, and a chance
> >> to speak at a LISP conference.
> >>
> >> Best of all, they don't even have to be literate programs! :-)
> >>
> >> Tim Daly
> >> Elder of the Internet
> >>
> >> --
> >> --
> >> 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.
>
>
>

-- 
-- 
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: Lisp In Summer Projects

[Nico Balestra]

(replace "I know have" "I now have")

*"It is better to have 100 functions operate on one data structure than to
have 10 functions operate on 10 data structures" - A.J. Perlis*


On 9 May 2013 17:13, Nico Balestra  wrote:

> ..after reading the FAQ I know have the answer why Italians are not
> eligible:
>
> *Q: Why do you hate Italians?*
> A: We're not sure why Italy is ineligible, contact 
> us if
> you're an Italian lawyer willing to help us out.
>
> It might be because Italians have too many parenthesis in their laws :)
>
> *"It is better to have 100 functions operate on one data structure than
> to have 10 functions operate on 10 data structures" - A.J. Perlis*
>
>
> On 9 May 2013 16:49, Plínio Balduino  wrote:
>
>> '(sad)
>>
>> On Thu, May 9, 2013 at 11:58 AM, Nico Balestra 
>> wrote:
>> > Contest is also not open to residents of Brazil, Italy, Quebec, and
>> Saudi
>> > Arabia
>> >
>> > I'm UK resident but born Italian and I find the above a bit distressing.
>> >
>> >
>> > "It is better to have 100 functions operate on one data structure than
>> to
>> > have 10 functions operate on 10 data structures" - A.J. Perlis
>> >
>> >
>> > On 9 May 2013 14:05, Tim Daly  wrote:
>> >>
>> >> If you have a Clojure project you could earn money and fame.
>> >> Check out "Lisp In Summer Projects"
>> >> http://lispinsummerprojects.org/?2013
>> >>
>> >> Heow-Eide Goodman, the man behind LispNYC, is getting a group of
>> >> experts together to judge the projects. You'll get your name in
>> >> front of some well-connected people, a nice check, and a chance
>> >> to speak at a LISP conference.
>> >>
>> >> Best of all, they don't even have to be literate programs! :-)
>> >>
>> >> Tim Daly
>> >> Elder of the Internet
>> >>
>> >> --
>> >> --
>> >> 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.
>>
>>
>>
>

-- 
-- 
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: Struggling with encapsulation

[Gary Trakhman]

If the interface provides everything that's needed, then there will be no
need to dive in?

I find attempts to hide that stuff frustrating when I'm a consumer of the
code, if I need it, and I acknowledge that implementation details are
subject-to-change when I take that risk, so only having something clearly
marked off by documentation of intent would be what I would do as a
producer of the code.


On Thu, May 9, 2013 at 12:07 PM, Colin Yates  wrote:

> (newbie, but trying hard!)
>
> I am designing a Woobly.  A Woobly is non-trivial and has a number of
> internal data structures (queues, worker threads etc.).  You can 'add' and
> 'remove' jobs from a Woobly.
>
> In OO land I might have a Woobly interface with the various methods which
> provides a public API.  I might also have a factory or more likely builder
> somewhere which creates Wooblies.
>
> The part I am struggling with is how to create a Woobly without exposing
> its internals.  Let's imagine that Woobly uses an internal
> LinkedBlockingQueue of a certain size.
>
> Option 1 - a big bag of data.
> I could create a map of config/state/data that comprises the
> implementation and have the creator function return that.  Consumers can
> then call other methods passing back that bag of config/state, but what
> stops them simply diving into that bag themselves?  For example:
>
> [code]
> (defn create-woobly
>  ([] (create-woobly 100)
>  ([queue-size] {:queue (java.util.concurrent.LinkedBlockingQueue
> queue-size)}))
>
> (defn add-job [woobly job] )
>
> ;; nothing stopping me diving into that state...
> (.clear (:queue (create-wobbly)))
> [/code]
>
> Option 2 - protocol and deftype
> Alternatively I could implement an IWoobly protocol and create a single
> deftype which is instantiated and returned from the 'create-woobly'
> function?  I am not sure I like this as it is really back to OO isn't it?
>
> I want to retain the notion of create returning a handle which is the
> first argument in the other public functions, but the first way just feels
> far too dangerous.
>
> Am I overthinking this - what do you all do to address this?
>
> Thanks a bunch.
>
> Col
>
> --
> --
> 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: why clojure.lang.Compiler.LOADER is null in clojure 1.5.1

[AtKaaZ]

is not this one is it ?
https://github.com/CmdrDats/clj-minecraft/blob/master/javasrc/cljminecraft/BasePlugin.java#L82


On Thu, May 9, 2013 at 7:12 PM, AtKaaZ  wrote:

> is there any chance that we can see the full code (maybe's on github
> already?)
>
>
> On Thu, May 9, 2013 at 9:00 AM, stream  wrote:
>
>> Hi all
>>
>> i wanna change the classloader of Clojure RT. in 1.5.1
>> so , i try to
>> clojure.lang.Var.pushThreadBindings(clojure.lang.RT.map(
>> clojure.lang.Compiler.LOADER, cl) );
>>
>> but throws exception that cojure.lang.Compiler.LOADER is null
>>
>> Caused by: java.lang.NullPointerException
>> at clojure.lang.RT.baseLoader(RT.java:2043)
>> at clojure.lang.RT.load(RT.java:417)
>> at clojure.lang.RT.load(RT.java:411)
>> at clojure.lang.RT.doInit(RT.java:447)
>> at clojure.lang.RT.(RT.java:329)
>> ... 9 more
>>
>>
>> However this is work in the 1.4.0
>>
>> someone could tell me what had happened in 1.5.1
>> thanks
>>
>> --
>> --
>> 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: Struggling with encapsulation

[Jonathan Fischer Friberg]

I agree with Gary, there's normally not really any need to obfuscate the
implementation,
and using the underlying structure can sometimes be useful.

That said, if you really want to, you can create a "woobly" protocol and
implement it using reify, this will make the underlying implementation
completely hidden.

(defprotocol Woobly
  (add-job [woobly job]))

(defn create-woobly
 ([] (create-woobly 100)
 ([queue-size]
  (let [queue (java.util.concurrent.LinkedBlockingQueue. queue-size)]
(reify Woobly
  (add-job [woobly job]
...use queue...)

Jonathan



On Thu, May 9, 2013 at 6:15 PM, Gary Trakhman wrote:

> If the interface provides everything that's needed, then there will be no
> need to dive in?
>
> I find attempts to hide that stuff frustrating when I'm a consumer of the
> code, if I need it, and I acknowledge that implementation details are
> subject-to-change when I take that risk, so only having something clearly
> marked off by documentation of intent would be what I would do as a
> producer of the code.
>
>
> On Thu, May 9, 2013 at 12:07 PM, Colin Yates wrote:
>
>> (newbie, but trying hard!)
>>
>> I am designing a Woobly.  A Woobly is non-trivial and has a number of
>> internal data structures (queues, worker threads etc.).  You can 'add' and
>> 'remove' jobs from a Woobly.
>>
>> In OO land I might have a Woobly interface with the various methods which
>> provides a public API.  I might also have a factory or more likely builder
>> somewhere which creates Wooblies.
>>
>> The part I am struggling with is how to create a Woobly without exposing
>> its internals.  Let's imagine that Woobly uses an internal
>> LinkedBlockingQueue of a certain size.
>>
>> Option 1 - a big bag of data.
>> I could create a map of config/state/data that comprises the
>> implementation and have the creator function return that.  Consumers can
>> then call other methods passing back that bag of config/state, but what
>> stops them simply diving into that bag themselves?  For example:
>>
>> [code]
>> (defn create-woobly
>>  ([] (create-woobly 100)
>>  ([queue-size] {:queue (java.util.concurrent.LinkedBlockingQueue
>> queue-size)}))
>>
>> (defn add-job [woobly job] )
>>
>> ;; nothing stopping me diving into that state...
>> (.clear (:queue (create-wobbly)))
>> [/code]
>>
>> Option 2 - protocol and deftype
>> Alternatively I could implement an IWoobly protocol and create a single
>> deftype which is instantiated and returned from the 'create-woobly'
>> function?  I am not sure I like this as it is really back to OO isn't it?
>>
>> I want to retain the notion of create returning a handle which is the
>> first argument in the other public functions, but the first way just feels
>> far too dangerous.
>>
>> Am I overthinking this - what do you all do to address this?
>>
>> Thanks a bunch.
>>
>> Col
>>
>> --
>> --
>> 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 option

Re: Struggling with encapsulation

[Dave Ray]

I agree that you probably don't need to go overboard with hiding
stuff. For option 2 though there's no need for deftype. Just implement
the protocol with reifiy within the create function and use the
closure for state.

(defn create-woobly
   [...]
   (let [... put your queues and stuff here ...]
  (reify Woobly
  ... implement protocol here ...)))

Dave


On Thu, May 9, 2013 at 9:15 AM, Gary Trakhman  wrote:
> If the interface provides everything that's needed, then there will be no
> need to dive in?
>
> I find attempts to hide that stuff frustrating when I'm a consumer of the
> code, if I need it, and I acknowledge that implementation details are
> subject-to-change when I take that risk, so only having something clearly
> marked off by documentation of intent would be what I would do as a producer
> of the code.
>
>
> On Thu, May 9, 2013 at 12:07 PM, Colin Yates  wrote:
>>
>> (newbie, but trying hard!)
>>
>> I am designing a Woobly.  A Woobly is non-trivial and has a number of
>> internal data structures (queues, worker threads etc.).  You can 'add' and
>> 'remove' jobs from a Woobly.
>>
>> In OO land I might have a Woobly interface with the various methods which
>> provides a public API.  I might also have a factory or more likely builder
>> somewhere which creates Wooblies.
>>
>> The part I am struggling with is how to create a Woobly without exposing
>> its internals.  Let's imagine that Woobly uses an internal
>> LinkedBlockingQueue of a certain size.
>>
>> Option 1 - a big bag of data.
>> I could create a map of config/state/data that comprises the
>> implementation and have the creator function return that.  Consumers can
>> then call other methods passing back that bag of config/state, but what
>> stops them simply diving into that bag themselves?  For example:
>>
>> [code]
>> (defn create-woobly
>>  ([] (create-woobly 100)
>>  ([queue-size] {:queue (java.util.concurrent.LinkedBlockingQueue
>> queue-size)}))
>>
>> (defn add-job [woobly job] )
>>
>> ;; nothing stopping me diving into that state...
>> (.clear (:queue (create-wobbly)))
>> [/code]
>>
>> Option 2 - protocol and deftype
>> Alternatively I could implement an IWoobly protocol and create a single
>> deftype which is instantiated and returned from the 'create-woobly'
>> function?  I am not sure I like this as it is really back to OO isn't it?
>>
>> I want to retain the notion of create returning a handle which is the
>> first argument in the other public functions, but the first way just feels
>> far too dangerous.
>>
>> Am I overthinking this - what do you all do to address this?
>>
>> Thanks a bunch.
>>
>> Col
>>
>> --
>> --
>> 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: Struggling with encapsulation

[James Reeves]

On 9 May 2013 17:07, Colin Yates  wrote:

> The part I am struggling with is how to create a Woobly without exposing
> its internals.
>

To what end? What's the benefit?

If you take a look at some internal data structures Clojure uses, like
zippers or protocols, you'll notice that they're just maps. In general
there's no need to try and obfuscate data to stop people from diving into
the internals; just don't provide a public API for the internal parts and
people will get the hint.

- James

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

Re: why clojure.lang.Compiler.LOADER is null in clojure 1.5.1

[Sean Corfield]

Daniel hinted at it in his response and it's been discussed several
times in the past but most of clojure.lang.RT and pretty much all of
clojure.lang.{anything-else} is considered a private implementation
detail and subject to change, so relying on it in code is very
brittle. I think Rich has indicated that pretty much only
clojure.lang.RT.var() is really "supported" and everything else should
be considered off-limits.

That doesn't help you with changing the classloader so maybe someone
from Clojure/core can weigh in on whether that's even considered
safe...?

Sean

On Wed, May 8, 2013 at 11:00 PM, stream  wrote:
> Hi all
>
> i wanna change the classloader of Clojure RT. in 1.5.1
> so , i try to
> clojure.lang.Var.pushThreadBindings(clojure.lang.RT.map( 
> clojure.lang.Compiler.LOADER, cl) );
>
> but throws exception that cojure.lang.Compiler.LOADER is null
>
> Caused by: java.lang.NullPointerException
> at clojure.lang.RT.baseLoader(RT.java:2043)
> at clojure.lang.RT.load(RT.java:417)
> at clojure.lang.RT.load(RT.java:411)
> at clojure.lang.RT.doInit(RT.java:447)
> at clojure.lang.RT.(RT.java:329)
> ... 9 more
>
>
> However this is work in the 1.4.0
>
> someone could tell me what had happened in 1.5.1
> thanks
>
> --
> --
> 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.
>
>



-- 
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
--- 
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: Struggling with encapsulation

[Colin Yates]

Thanks for all the helpful responses.

One reason I want to hide the internals is that I don't want people to add
jobs directly to the queue.  (add-job) will put a map containing the
provided function onto the queue.  Not really relevant, but this is so that
I can track queue timings that I can later on use to determine how much
capacity the system can handle.

I am nervous as well about "expose internals but trust people to do the
right thing" because in this case, if I was a consumer and saw that queue,
particularly given the emphasis about data being the contract etc. then why
would I think *not* to use it.

I do appreciate the point about not needlessly obfuscating information -
this is a slightly different case.

Sounds like in this case, either reify is the way to go or maybe return a
bad of data but have this stuff in an 'internal' map (i.e. {:internal
{:queue...}})

Thanks a bunch - really helpful.


On 9 May 2013 17:30, James Reeves  wrote:

> On 9 May 2013 17:07, Colin Yates  wrote:
>
>> The part I am struggling with is how to create a Woobly without exposing
>> its internals.
>>
>
> To what end? What's the benefit?
>
> If you take a look at some internal data structures Clojure uses, like
> zippers or protocols, you'll notice that they're just maps. In general
> there's no need to try and obfuscate data to stop people from diving into
> the internals; just don't provide a public API for the internal parts and
> people will get the hint.
>
> - James
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/D2OBBPTxGfY/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, 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.

Eatomic: a Datomic-themed dinner and chat (tonight; SF Bay Area, CA, USA)

[Rich Morin]

[ Eatomic is tonight; drop by if you can...  -r ]

The 2nd Thursday of the odd-numbered months seems to be free, so
let's get together anyway.  Eatomic is a Datomic-themed dinner
and chat.  Be prepared to spend about $20 on interesting food
(and conversation).

  Thursday, May 9, 2013
  6:00 PM to 8:00 PM
  Coconut Bay Street Cafe
  Burlingame, CA

  http://www.meetup.com/The-Bay-Area-Datomic-User-Group/events/114537012/

-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: Lisp In Summer Projects

[Konrad Scorciapino]

Disappointing, isn't it? They've explained to me further:

Basicly our small project is similar to Google's Code-In, which is where
> the requirement originated. We don't have Google's cadre of lawyers and
> cannot risk inviting trouble to our friends and colleagues at the ALU. They
> coordinate the International Lisp Conference and distribute our money
> awards.



2013/5/9 Nico Balestra 

> (replace "I know have" "I now have")
>
> *"It is better to have 100 functions operate on one data structure than
> to have 10 functions operate on 10 data structures" - A.J. Perlis*
>
>
> On 9 May 2013 17:13, Nico Balestra  wrote:
>
>> ..after reading the FAQ I know have the answer why Italians are not
>> eligible:
>>
>> *Q: Why do you hate Italians?*
>> A: We're not sure why Italy is ineligible, contact 
>> us if
>> you're an Italian lawyer willing to help us out.
>>
>> It might be because Italians have too many parenthesis in their laws :)
>>
>> *"It is better to have 100 functions operate on one data structure than
>> to have 10 functions operate on 10 data structures" - A.J. Perlis*
>>
>>
>> On 9 May 2013 16:49, Plínio Balduino  wrote:
>>
>>> '(sad)
>>>
>>> On Thu, May 9, 2013 at 11:58 AM, Nico Balestra 
>>> wrote:
>>> > Contest is also not open to residents of Brazil, Italy, Quebec, and
>>> Saudi
>>> > Arabia
>>> >
>>> > I'm UK resident but born Italian and I find the above a bit
>>> distressing.
>>> >
>>> >
>>> > "It is better to have 100 functions operate on one data structure than
>>> to
>>> > have 10 functions operate on 10 data structures" - A.J. Perlis
>>> >
>>> >
>>> > On 9 May 2013 14:05, Tim Daly  wrote:
>>> >>
>>> >> If you have a Clojure project you could earn money and fame.
>>> >> Check out "Lisp In Summer Projects"
>>> >> http://lispinsummerprojects.org/?2013
>>> >>
>>> >> Heow-Eide Goodman, the man behind LispNYC, is getting a group of
>>> >> experts together to judge the projects. You'll get your name in
>>> >> front of some well-connected people, a nice check, and a chance
>>> >> to speak at a LISP conference.
>>> >>
>>> >> Best of all, they don't even have to be literate programs! :-)
>>> >>
>>> >> Tim Daly
>>> >> Elder of the Internet
>>> >>
>>> >> --
>>> >> --
>>> >> 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.
>>>
>>>
>>>
>>
>  --
> --
> 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
> c

Quick question on protocols

[Dave Kincaid]

I've not worked with protocols much, but saw a good fit recently. However, 
I'm a little bit unsure about this situation. I have some Thrift objects 
that I'd like to be able to easily unpack into maps, so I created a protocol

(defprotocol Unpackable
  (unpack [x]))

Thrift has two main data types - structs and unions that need to be handled 
differently. Structs always implement the interface TBase. Unions extend 
the abstract class TUnion which in turn implements the interface TBase. So 
I'm extending my protocol to these types like this:

(extend-protocol IUnpackable
  TUnion
  (unpack [x] (unpack-union x))

  TBase
  (unpack [x] (unpack-struct x (get-meta-data (class x)

It all seems to work correctly, but I'm a little unsure that it is 
guaranteed to work especially in the case of a union. Since a union extends 
TUnion, but also implements TBase will a call to (unpack the-union) do the 
right thing (go to unpack-union instead of unpack-struct) every time?

Thanks.

-- 
-- 
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: Quick question on protocols

[Jeroen van Dijk]

Hi David,

I've used protocols for the exact same purpose (Thrift unpacking, and like
you (?), for convenience in Cascalog). I think it works very well and is
speedier than other methods. It is also convenient when you have nested
data structures and you don't want to care how to go through this nesting
to get nested values. Protocols can make this work like magic. Your
question makes sense though and I wasn't sure if it will always works
(never had a counter example in practise though). I did the following
experiment and I think it shows that it works without exception:

user=> (isa? String Object)
true

(defprotocol ITest
  (show-me [v]))

(extend-protocol ITest
  Object
  (show-me [v] (println "got an object"))
  String
  (show-me [v] (println "got a string")))

user=> (show-me (Object.))
got an object
nil
user=> (show-me (String.))
got a string
nil
user=> (show-me ^Object (String.))
got a string
nil
user=> (show-me (Integer. 1))
got an object
nil
user=> (show-me (cast Object "1"))
got a string
nil

Not sure if there are other tests available, but this gives me some
confidence.

HTH,

Jeroen


On Thu, May 9, 2013 at 8:45 PM, Dave Kincaid  wrote:

> I've not worked with protocols much, but saw a good fit recently. However,
> I'm a little bit unsure about this situation. I have some Thrift objects
> that I'd like to be able to easily unpack into maps, so I created a protocol
>
> (defprotocol Unpackable
>   (unpack [x]))
>
> Thrift has two main data types - structs and unions that need to be
> handled differently. Structs always implement the interface TBase. Unions
> extend the abstract class TUnion which in turn implements the interface
> TBase. So I'm extending my protocol to these types like this:
>
> (extend-protocol IUnpackable
>   TUnion
>   (unpack [x] (unpack-union x))
>
>   TBase
>   (unpack [x] (unpack-struct x (get-meta-data (class x)
>
> It all seems to work correctly, but I'm a little unsure that it is
> guaranteed to work especially in the case of a union. Since a union extends
> TUnion, but also implements TBase will a call to (unpack the-union) do the
> right thing (go to unpack-union instead of unpack-struct) every time?
>
> Thanks.
>
> --
> --
> 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: Lisp In Summer Projects

[u1204]

I believe that cash payments are forbidden by law in the listed
countries. The contest will make cash payments. I know that
Lisp In Summer Projects has no problem with people from Italy,
Brazil, or other listed countries.

Tim Daly

-- 
-- 
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: Struggling with encapsulation

[James Reeves]

On 9 May 2013 18:03, Colin Yates  wrote:

> I am nervous as well about "expose internals but trust people to do the
> right thing" because in this case, if I was a consumer and saw that queue,
> particularly given the emphasis about data being the contract etc. then why
> would I think *not* to use it.
>

If this were a problem in general I think we'd find more people poking at
the internals of protocols, but I've never seen that happen.

You could use namespaced keywords, like :woobly.internal/queue, to give
people more of a hint that the data shouldn't be used without the API, but
I really think you're borrowing trouble with this.

Encapsulation is like inheritance, in that it's one of those ideas that's
nice on paper, but ultimately not very useful in practise.

- James

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

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

[Brian Jenkins]

Hi, Thomas.

I also found this frustrating. Here's a work-around I came up with:


;; assuming (defrecord Design [id name]) in namespace tektite.model.design
 
(cljs.reader/register-tag-parser!  "tektite.model.design.Design" 
tektite.model.design/map->Design)
 
(extend-protocol IPrintWithWriter
  tektite.model.design/Design
  (-pr-writer [coll writer opts]
(let [pr-pair (fn [keyval] (pr-sequential-writer writer pr-writer "" " 
" "" opts keyval))]
  (pr-sequential-writer writer pr-pair "#tektite.model.design.Design{" 
", " "}" opts coll


On the server side, I read EDN out of the request body with 
clojure.edn/read (because clojure.core/read is 
unsafe for reading evil strings from the internet).  clojure.edn/read 
doesn't pick up new readers
from data_readers.clj or *data-readers* (fortunately), but can be taught 
new tags like this:


(def model-readers {'tektite.model.design.Design 
#'tektite.model.design/map->Design})
 
(defn read-edn-body [context]
  (clojure.edn/read {:readers model-readers, :eof nil}
(java.io.PushbackReader.
 (java.io.InputStreamReader.
  (get-in context [:request :body])
  "UTF-8"


(I use liberator, so the request arrives in a context hash)

Best,
Brian

On Monday, January 7, 2013 1:13:30 AM UTC+1, Thomas Heller wrote:
>
> 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?
>

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

Re: Accessing JSON Array data in Clojure

[Hawkeye02]

Thanks Greg for the suggestion.  I have added the book to my Safari account.

Michael, I tried your suggestion with 'get-in' and it came back with 
[object Object] from JSON.  I switched the clojure.contrib stuff with 
data.json.

Below is the updated code and a screenshot of the result.  Thanks in 
advance for any guidance.

*(ns brainiac.plugins.dark-sky*
*  (:require [brainiac.plugin :as brainiac]*
*[clojure.data.json :as json]*
*[clojure.java.io :as io :only (reader)]*
*[clojure.core :as core]))*
*
*
*
*
*(defn format-forecast [forecast]*
*  {*
*:temp (:currentTemp forecast)*
*:current-summary (:currentSummary forecast)*
*:hour-summary (core/get-in :dayPrecipitation [:temp] forecast)*
*:minutes-until-change (:minutesUntilChange forecast)*
*  })*
*
*
*(defn transform [stream]*
*  (let [json (json/read-json (io/reader stream))]*
*(assoc {}*
*  :name "dark-sky"*
*  :title "Right now, outside..."*
*  :data (format-forecast json*
*
*
*(defn url [api-key lat lon]*
*  (format "https://api.darkskyapp.com/v1/forecast/%s/%s,%s"; api-key lat 
lon))*
*
*
*(defn configure [{:keys [api-key lat lon program-name]}]*
*  (brainiac/simple-http-plugin*
*{:url (url api-key lat lon)}*
*transform program-name))*
*
*


*
*

On Tuesday, May 7, 2013 8:10:02 PM UTC-5, greg r wrote:
>
> You might want to check out "Clojure Data Analysis Handbook" by Eric 
> Rochester.  There is an example using org.clojure/data.json and Incanter to 
> read JSON format into an Incanter dataset.  You might find other recipes in 
> the book useful as well:
>
> http://www.packtpub.com/clojure-data-analysis-cookbook/book
>
> I'm going through it (slowly) and learning a lot.  It's not a beginner's 
> book.  Full blast functional programming for sure.
>
> Regards,
> Greg
>
>

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

Re: Accessing JSON Array data in Clojure

[Hawkeye02]

Forgot to put the JSON data:

"radarStation":"lot","dayPrecipitation":[{"time":1368129600,"probability":0.23,"type":"rain","temp":74,"cloudCover":1,"relHumidity":0.45},..


On Thursday, May 9, 2013 4:10:44 PM UTC-5, Hawkeye02 wrote:
>
> Thanks Greg for the suggestion.  I have added the book to my Safari 
> account.
>
> Michael, I tried your suggestion with 'get-in' and it came back with 
> [object Object] from JSON.  I switched the clojure.contrib stuff with 
> data.json.
>
> Below is the updated code and a screenshot of the result.  Thanks in 
> advance for any guidance.
>
> *(ns brainiac.plugins.dark-sky*
> *  (:require [brainiac.plugin :as brainiac]*
> *[clojure.data.json :as json]*
> *[clojure.java.io :as io :only (reader)]*
> *[clojure.core :as core]))*
> *
> *
> *
> *
> *(defn format-forecast [forecast]*
> *  {*
> *:temp (:currentTemp forecast)*
> *:current-summary (:currentSummary forecast)*
> *:hour-summary (core/get-in :dayPrecipitation [:temp] forecast)*
> *:minutes-until-change (:minutesUntilChange forecast)*
> *  })*
> *
> *
> *(defn transform [stream]*
> *  (let [json (json/read-json (io/reader stream))]*
> *(assoc {}*
> *  :name "dark-sky"*
> *  :title "Right now, outside..."*
> *  :data (format-forecast json*
> *
> *
> *(defn url [api-key lat lon]*
> *  (format "https://api.darkskyapp.com/v1/forecast/%s/%s,%s"; api-key lat 
> lon))*
> *
> *
> *(defn configure [{:keys [api-key lat lon program-name]}]*
> *  (brainiac/simple-http-plugin*
> *{:url (url api-key lat lon)}*
> *transform program-name))*
> *
> *
>
>
> 
> *
> *
>
> On Tuesday, May 7, 2013 8:10:02 PM UTC-5, greg r wrote:
>>
>> You might want to check out "Clojure Data Analysis Handbook" by Eric 
>> Rochester.  There is an example using org.clojure/data.json and Incanter to 
>> read JSON format into an Incanter dataset.  You might find other recipes in 
>> the book useful as well:
>>
>> http://www.packtpub.com/clojure-data-analysis-cookbook/book
>>
>> I'm going through it (slowly) and learning a lot.  It's not a beginner's 
>> book.  Full blast functional programming for sure.
>>
>> Regards,
>> Greg
>>
>>

-- 
-- 
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: kits 1.5.1 - some of Runa's core utilities

[Alex Baranosky]

Runa has decided to open source a project of our utility namespaces that we
call Runa Kits . At this point in time
this includes:

   - benchmark.clj ;; simple timing functions
   - csv.clj ;; wrapper around clojure-csv library that turn csv in to
   column-name, column-value key value pair that can be configured via
   :key-fn, :val-fn and :reader for each field
   - db_migrator.clj ;; simple SQL schema migration library
   - foundation.clj ;; catchall ns of utils
   - homeless.clj ;; another catchall ns of utils
   - logging.clj ;; Simple wrapper library for java.util.logging
   - map.clj ;; Functions that operate on Clojure maps
   - match.clj ;; Supports the speed optimized 'matches?' macro and
   'fmatches?' fn for checking if a string matches a sequence of strings or
   wildcard strings
   - queues.clj ;; Wrappers for constructing various java.util.concurrent
   queues
   - runtime.clj ;; Library to access run-time info from the JVM
   - seq.clj ;; Functions that operate on Clojure sequences
   - string.clj ;; Functions that operate on Strings or Keywords
   - structured_logging.clj ;; Logging Clojure data as JSON: supports :tags
   and log contexts
   - test_utils.clj ;; Functions and macros for making writing tests more
   effectively
   - timestamp.clj ;; Functions for creating and formatting timestamps
   (Longs)
   - xml.clj ;; To simplify working with clojure.xml

These are tools we use everyday, and have not been spiffed up with many doc
strings.  In general these kits are offered up for use by the community
as-is, and we hope you find something of use in there.

Best,
Alex

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

defmethod/require race condition

[Steven Degutis]

In my app, sometimes a file containing a defmethod hasn't been
required yet by the time some other function calls the multi-method.
So naturally it throws an exception.

But later, as the app continues to run, the file containing the proper
defmethod eventually gets required by another file. Then everything
works fine.

The ugly solution is to require all possible implementations of a
multi-method in the file that calls it. But that feels like it defeats
the goal of polymorphism, to not have to know about concrete
implementors of an interface.

Is there a better solution to this kind of race condition?

-Steven

-- 
-- 
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: kits 1.5.1 - some of Runa's core utilities

[Timothy Gardner]

That's awesome! Thanks!


On Thu, May 9, 2013 at 5:57 PM, Alex Baranosky <
alexander.barano...@gmail.com> wrote:

> Runa has decided to open source a project of our utility namespaces that
> we call Runa Kits . At this point in
> time this includes:
>
>- benchmark.clj ;; simple timing functions
>- csv.clj ;; wrapper around clojure-csv library that turn csv in to
>column-name, column-value key value pair that can be configured via
>:key-fn, :val-fn and :reader for each field
>- db_migrator.clj ;; simple SQL schema migration library
>- foundation.clj ;; catchall ns of utils
>- homeless.clj ;; another catchall ns of utils
>- logging.clj ;; Simple wrapper library for java.util.logging
>- map.clj ;; Functions that operate on Clojure maps
>- match.clj ;; Supports the speed optimized 'matches?' macro and
>'fmatches?' fn for checking if a string matches a sequence of strings or
>wildcard strings
>- queues.clj ;; Wrappers for constructing various java.util.concurrent
>queues
>- runtime.clj ;; Library to access run-time info from the JVM
>- seq.clj ;; Functions that operate on Clojure sequences
>- string.clj ;; Functions that operate on Strings or Keywords
>- structured_logging.clj ;; Logging Clojure data as JSON: supports
>:tags and log contexts
>- test_utils.clj ;; Functions and macros for making writing tests more
>effectively
>- timestamp.clj ;; Functions for creating and formatting timestamps
>(Longs)
>- xml.clj ;; To simplify working with clojure.xml
>
> These are tools we use everyday, and have not been spiffed up with many
> doc strings.  In general these kits are offered up for use by the community
> as-is, and we hope you find something of use in there.
>
> Best,
> Alex
>
> --
> --
> 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: Lisp In Summer Projects

[Softaddicts]

Quebec is a province within Canada and has little jurisdiction outside of its 
geographic 
borders. It's not a country...

A good example are internet poker game sites and similar activities on the net.
The Quebec agency which regulates all lotteries and similar activities cannot 
do anything
about people playing on the internet  or forbid the organizations
outside of Quebec to propose these activities.

They cannot sue outsiders on the net except if they are located in the province.
They can in theory sue players residing in Quebec
but they never did so. Playing a poker game here is illegal if it involves money
if you do not ask for a permit, even in a charity event.

They are not even able to forbid these type of activities in native reserves
within the province :) It would trigger a war 
There's a bunch of servers running poker web sites near Montreal in a Mohawk
reserve and you will never see cops going there to seize the equipment.

Looks to me more like an attorney bad trip than a serious facts analysis.

Luc


> I believe that cash payments are forbidden by law in the listed
> countries. The contest will make cash payments. I know that
> Lisp In Summer Projects has no problem with people from Italy,
> Brazil, or other listed countries.
> 
> Tim Daly
> 
> -- 
> -- 
> 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.
> 
> 
> 
--
Softaddicts sent by ibisMail from my ipad!

-- 
-- 
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: defmethod/require race condition

[Gary Trakhman]

Do you have dynamic 'require' statements? Why? Should prefer (ns (:require
[])) in non-scripts.

As an alternative, if you want to ensure a sane state, I would suggest
starting your app from an initialization namespace that requires all the
namespaces you might want.


On Thu, May 9, 2013 at 5:19 PM, Steven Degutis  wrote:

> In my app, sometimes a file containing a defmethod hasn't been
> required yet by the time some other function calls the multi-method.
> So naturally it throws an exception.
>
> But later, as the app continues to run, the file containing the proper
> defmethod eventually gets required by another file. Then everything
> works fine.
>
> The ugly solution is to require all possible implementations of a
> multi-method in the file that calls it. But that feels like it defeats
> the goal of polymorphism, to not have to know about concrete
> implementors of an interface.
>
> Is there a better solution to this kind of race condition?
>
> -Steven
>
> --
> --
> 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: LambdaNext Clojure Workshop - London May 20-22 2013

[Sam Aaron]

Hey there,

just a quick reminder of the upcoming LambdaNext Clojure training workshop in 
London in a couple of weeks.

There are only a few spots left, so if you were thinking about joining, act 
quick to grab your place!

The LambdaNext Team - http://lambdanext.eu/

On 15 Apr 2013, at 11:24, Sam Aaron  wrote:

> Are you interested in becoming a professional Clojure programmer? Want
> to jumpstart your knowledge or simply take things to the next level? The
> LambdaNext team is holding a Clojure workshop in London, May 20-22 2013.
> 
> Come join us! 
> http://lambdanext.eu
> 
> 
> * An intensive learning experience
> 
> The workshop is 3 days in total, the first two introduce the basics of
> the language and gear up to the last day which covers advanced concepts
> and techniques.  You can opt for any combination of the the 2 and 1 day
> workshops.  We'll be training from The Hub, Westminster
> (http://westminster.the-hub.net/) in Central London.  The workshop will
> have at most 20 attendees, to 4 trainers.
> 
> 
> * Our world-class Clojure team
> 
> We are a team of 4 long time professional and deeply enthusiastic
> Clojurists.  We've deployed Clojure in a wide variety of interesting
> domains from atom splitting to live music making.  Check out
> www.lambdanext.com for links to our blogs, projects and other details.
> 
> Between us, we've have more experience teaching Clojure in Europe than
> anybody. You'll know you're in expert hands.
> 
> 
> * Our proven teaching method
> 
> Our teaching method involves carefully sowing and then nurturing the
> seeds of Clojure's core concepts in an iterative manner.
> 
> Our sowing phase of each concept takes place through an "unplugged"
> session which will scaffold and demonstrate the concept through the use
> of a variety of illustrative props and audience participation. This
> allows us to collectively get direct into the core of each individual
> idea.
> 
> We will then fertilise and nurture these new concepts through an
> increasingly sophisticated set of mini-projects where you write code in
> groups with our guidance. This allows the ideas to be tested in a real
> context with chance for rapid and continuous feedback to accelerate the
> learning process.
> 
> This is a truly intensive format and so we have all four of our trainers in
> the room to help, unblock and encourage.  With a ratio of 20 attendees
> to 4 trainers you can guarantee you'll make rapid progress.
> 
> 
> * Caring for you
> 
> We'll lay on a nutritious breakfast and lunch, and all the tea, coffee,
> juice and biscuits you can consume during the day.
> 
> 
> * Questions ?
> 
> If you'd like to know more, or have any questions please drop us an
> email (i...@lambdanext.eu) or tweet (@LambdaNext).
> 
> Sam, Edmund, Christophe and Meikel,
> The LambdaNext Team
> http://lambdanext.eu
> 

-- 
-- 
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: kits 1.5.1 - some of Runa's core utilities

[Michael Klishin]

2013/5/10 Alex Baranosky 

> These are tools we use everyday, and have not been spiffed up with many
> doc strings.  In general these kits are offered up for use by the community
> as-is, and we hope you find something of use in there.


Alex,

I can't find what license Kits uses. Would it be possible to clarify this
in README
and add a LICENSE file to the repo?

Thanks.
-- 
MK

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

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

Re: Accessing JSON Array data in Clojure

[Michael Klishin]

2013/5/10 Hawkeye02 

> :hour-summary (core/get-in :dayPrecipitation [:temp] forecast)


I don't think you use get-in the way it is demonstrated in the examples. It
takes a map
as the first argument and a collection of keys to traverse.

http://clojuredocs.org/clojure_core/clojure.core/get-in

Also, you don't need to require clojure.core. It is automatically loaded
and referred to.
-- 
MK

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

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

Re: defmethod/require race condition

[sdegutis]

They're all in the (ns (:require [...])), so that's fine. The problem is, a 
file which requires the concrete implementation won't get required by 
another file for a while.

On Thursday, May 9, 2013 6:00:39 PM UTC-5, Gary Trakhman wrote:
>
> Do you have dynamic 'require' statements? Why? Should prefer (ns (:require 
> [])) in non-scripts.
>
> As an alternative, if you want to ensure a sane state, I would suggest 
> starting your app from an initialization namespace that requires all the 
> namespaces you might want.
>
>
> On Thu, May 9, 2013 at 5:19 PM, Steven Degutis 
> > wrote:
>
>> In my app, sometimes a file containing a defmethod hasn't been
>> required yet by the time some other function calls the multi-method.
>> So naturally it throws an exception.
>>
>> But later, as the app continues to run, the file containing the proper
>> defmethod eventually gets required by another file. Then everything
>> works fine.
>>
>> The ugly solution is to require all possible implementations of a
>> multi-method in the file that calls it. But that feels like it defeats
>> the goal of polymorphism, to not have to know about concrete
>> implementors of an interface.
>>
>> Is there a better solution to this kind of race condition?
>>
>> -Steven
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>

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

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

[David Nolen]

Patch welcome for 1.

As far as 2 I myself see no way to make that work without considering a
numerics overhaul.


On Sun, Jan 6, 2013 at 7:13 PM, Thomas Heller  wrote:

> 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

-- 
-- 
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: kits 1.5.1 - some of Runa's core utilities

[Dave Sann]

A question for the community.

There are several "projects" that provide a bunch of base level/common 
functions and extensions (similar to those here) beyond core Clojure. And I 
am sure that many people have their own collection of useful utilities like 
this. I know that I do.

clojure/core.incubator doesn't move very quickly for obvious reasons

Maybe the community could establish a common project or set of projects to 
pool these utilities as a common base. This could also potentially feed 
into core Clojure as relevant.

I know this can have complications, it's just a thought to avoid 
duplication of effort.

Dave


On Friday, 10 May 2013 07:57:10 UTC+10, Alex Baranosky wrote:
>
> Runa has decided to open source a project of our utility namespaces that 
> we call Runa Kits . At this point in 
> time this includes:
>
>- benchmark.clj ;; simple timing functions 
>- csv.clj ;; wrapper around clojure-csv library that turn csv in to 
>column-name, column-value key value pair that can be configured via 
>:key-fn, :val-fn and :reader for each field
>- db_migrator.clj ;; simple SQL schema migration library 
>- foundation.clj ;; catchall ns of utils
>- homeless.clj ;; another catchall ns of utils
>- logging.clj ;; Simple wrapper library for java.util.logging
>- map.clj ;; Functions that operate on Clojure maps 
>- match.clj ;; Supports the speed optimized 'matches?' macro and 
>'fmatches?' fn for checking if a string matches a sequence of strings or 
>wildcard strings
>- queues.clj ;; Wrappers for constructing various java.util.concurrent 
>queues 
>- runtime.clj ;; Library to access run-time info from the JVM
>- seq.clj ;; Functions that operate on Clojure sequences
>- string.clj ;; Functions that operate on Strings or Keywords
>- structured_logging.clj ;; Logging Clojure data as JSON: supports 
>:tags and log contexts 
>- test_utils.clj ;; Functions and macros for making writing tests more 
>effectively
>- timestamp.clj ;; Functions for creating and formatting timestamps 
>(Longs)
>- xml.clj ;; To simplify working with clojure.xml 
>
> These are tools we use everyday, and have not been spiffed up with many 
> doc strings.  In general these kits are offered up for use by the community 
> as-is, and we hope you find something of use in there.
>
> Best,
> Alex
>

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

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

[Thomas Heller]

Hey Brian,

been a while since that Post, Issue #1 has been resolved for a while (see
http://dev.clojure.org/jira/browse/CLJS-466) but I actually switched to
using proper EDN tags via IPrintWithWriter, clj/print-method and
clojure.edn/read-string like you suggested.

#2 I solved indirectly via #1, I didnt find an acceptable BigDecimal
JavaScript implementation and since all the math happens on the server
anyways I just transmit them as Strings inside records. The Reader function
in CLJS just keeps it as a String, the CLJ Reader function just does
(BigDecimal. s) so all is good. (eg. #ns/money [:EUR "1234567.89"])




On Thu, May 9, 2013 at 9:03 PM, Brian Jenkins  wrote:

> Hi, Thomas.
>
> I also found this frustrating. Here's a work-around I came up with:
>
>
> ;; assuming (defrecord Design [id name]) in namespace tektite.model.design
>
> (cljs.reader/register-tag-parser!  "tektite.model.design.Design"
> tektite.model.design/map->Design)
>
> (extend-protocol IPrintWithWriter
>   tektite.model.design/Design
>   (-pr-writer [coll writer opts]
> (let [pr-pair (fn [keyval] (pr-sequential-writer writer pr-writer "" "
> " "" opts keyval))]
>   (pr-sequential-writer writer pr-pair "#tektite.model.design.Design{"
> ", " "}" opts coll
>
>
> On the server side, I read EDN out of the request body with
> clojure.edn/read (because clojure.core/read is
> unsafe for reading evil strings from the internet).  clojure.edn/read
> doesn't pick up new readers
> from data_readers.clj or *data-readers* (fortunately), but can be taught
> new tags like this:
>
>
> (def model-readers {'tektite.model.design.Design
> #'tektite.model.design/map->Design})
>
> (defn read-edn-body [context]
>   (clojure.edn/read {:readers model-readers, :eof nil}
> (java.io.PushbackReader.
>  (java.io.InputStreamReader.
>   (get-in context [:request :body])
>   "UTF-8"
>
>
> (I use liberator, so the request arrives in a context hash)
>
> Best,
> Brian
>
> On Monday, January 7, 2013 1:13:30 AM UTC+1, Thomas Heller wrote:
>>
>> 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?
>>
>  --
> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/4aeIxs_yNG4/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, 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: Clojure/Script pr-str/read-string roundtrip differences

[David Nolen]

Heh didn't notice the date on the first post :)


On Thu, May 9, 2013 at 8:29 PM, Thomas Heller  wrote:

> Hey Brian,
>
> been a while since that Post, Issue #1 has been resolved for a while (see
> http://dev.clojure.org/jira/browse/CLJS-466) but I actually switched to
> using proper EDN tags via IPrintWithWriter, clj/print-method and
> clojure.edn/read-string like you suggested.
>
> #2 I solved indirectly via #1, I didnt find an acceptable BigDecimal
> JavaScript implementation and since all the math happens on the server
> anyways I just transmit them as Strings inside records. The Reader function
> in CLJS just keeps it as a String, the CLJ Reader function just does
> (BigDecimal. s) so all is good. (eg. #ns/money [:EUR "1234567.89"])
>
>
>
>
> On Thu, May 9, 2013 at 9:03 PM, Brian Jenkins  wrote:
>
>> Hi, Thomas.
>>
>> I also found this frustrating. Here's a work-around I came up with:
>>
>>
>> ;; assuming (defrecord Design [id name]) in namespace tektite.model.design
>>
>> (cljs.reader/register-tag-parser!  "tektite.model.design.Design"
>> tektite.model.design/map->Design)
>>
>> (extend-protocol IPrintWithWriter
>>   tektite.model.design/Design
>>   (-pr-writer [coll writer opts]
>> (let [pr-pair (fn [keyval] (pr-sequential-writer writer pr-writer ""
>> " " "" opts keyval))]
>>   (pr-sequential-writer writer pr-pair
>> "#tektite.model.design.Design{" ", " "}" opts coll
>>
>>
>> On the server side, I read EDN out of the request body with
>> clojure.edn/read (because clojure.core/read is
>> unsafe for reading evil strings from the internet).  clojure.edn/read
>> doesn't pick up new readers
>> from data_readers.clj or *data-readers* (fortunately), but can be taught
>> new tags like this:
>>
>>
>> (def model-readers {'tektite.model.design.Design
>> #'tektite.model.design/map->Design})
>>
>> (defn read-edn-body [context]
>>   (clojure.edn/read {:readers model-readers, :eof nil}
>> (java.io.PushbackReader.
>>  (java.io.InputStreamReader.
>>   (get-in context [:request :body])
>>   "UTF-8"
>>
>>
>> (I use liberator, so the request arrives in a context hash)
>>
>> Best,
>> Brian
>>
>> On Monday, January 7, 2013 1:13:30 AM UTC+1, Thomas Heller wrote:
>>>
>>> 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?
>>>
>>  --
>> --
>> 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 a topic in the
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/clojure/4aeIxs_yNG4/unsubscribe?hl=en.
>> To unsubscribe from this group and all its topics, 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 opt

Re: defmethod/require race condition

[Brandon Bloom]

This is an unfortunate ugly side effect of def and def-like forms being, 
um, side effectual.

In the particular case of defmethod, I think that the general 
recommendation would be to structure your namespaces such that methods are 
defined along side the code that could produce dispatch values which would 
trigger those methods. For example, if you were to dispatch by :some-key, 
then the functions that produce maps with {:some-key :foo} should be in the 
same namespace as (defmethod f :foo ...)

On Thursday, May 9, 2013 5:19:40 PM UTC-4, sdegutis wrote:
>
> In my app, sometimes a file containing a defmethod hasn't been 
> required yet by the time some other function calls the multi-method. 
> So naturally it throws an exception. 
>
> But later, as the app continues to run, the file containing the proper 
> defmethod eventually gets required by another file. Then everything 
> works fine. 
>
> The ugly solution is to require all possible implementations of a 
> multi-method in the file that calls it. But that feels like it defeats 
> the goal of polymorphism, to not have to know about concrete 
> implementors of an interface. 
>
> Is there a better solution to this kind of race condition? 
>
> -Steven 
>

-- 
-- 
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: Two new Clojure projects

[Kelker Ryan]

There's now a tutorial for CHP https://github.com/runexec/chp/tree/master/tutorial/01  09.05.2013, 20:03, "Kelker Ryan" :I just wanted to share two new Clojure projects. Porta is a Clojure utility that generates a Clojure abstraction for an existing Java Class.https://github.com/runexec/porta CHP (ClojureHomePage) is a project that aims at making Clojure web development as easy as PHP.https://github.com/runexec/chp--  --  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: Accessing JSON Array data in Clojure

[Bryan Henderson]

What map would be defined for the first argument with the given code?  It
seems like how it is set up, it is grabbing information straight from the
JSON data without a map defined.  The 'format-forecast' definition takes
forecast as an arg so I tried it like this with no luck:

*:hour-summary (core/get-in forecast [**:dayPrecipitation :temp])*
*
*
I wasn't sure what else to put for the first argument.

Thanks for the heads up on the clojure.core requirement.  I saw it in some
other code online; figured I needed it.

Also, thanks again for the help.




On Thu, May 9, 2013 at 6:17 PM, Michael Klishin  wrote:

>
> 2013/5/10 Hawkeye02 
>
>> :hour-summary (core/get-in :dayPrecipitation [:temp] forecast)
>
>
> I don't think you use get-in the way it is demonstrated in the examples.
> It takes a map
> as the first argument and a collection of keys to traverse.
>
> http://clojuredocs.org/clojure_core/clojure.core/get-in
>
> Also, you don't need to require clojure.core. It is automatically loaded
> and referred to.
> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/ZreY5nWg0e4/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, 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: Lisp In Summer Projects

[Terje Norderhaug]

I suggest allowing participants from the listed countries, but give
an eventual prize to a charity of choice to avoid a cash payment.


On Thu, May 9, 2013 at 12:59 PM, u1204  wrote:

> I believe that cash payments are forbidden by law in the listed
> countries. The contest will make cash payments. I know that
> Lisp In Summer Projects has no problem with people from Italy,
> Brazil, or other listed countries.
>
> Tim Daly
>
> --
> --
> 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.