Re: proxy doesn't care about type hints?

[Jim - FooBar();]

aaa ok sorry... proxy-super is a no-no in this case...I think at this 
point my best bet is to write a macro that will expand into a gen-class 
skeleton form...there is no other way I'm afraid...the proxy approach 
would be so elegant if it worked!


Jim


On 15/04/13 22:17, Meikel Brandmeyer (kotarak) wrote:



Am Montag, 15. April 2013 23:03:56 UTC+2 schrieb Jim foo.bar:

On 15/04/13 21:37, Meikel Brandmeyer (kotarak) wrote:
>
> (proxy [YourClass BarInterface] []
>   (bar [x-or-y]
> (if (instance? InterfaceY x-or-y)
>   (override x-or-y)
>   (proxy-super x-or-y

I'm sorry I forgot...what is 'override' above? what fn is this? I
cannot
find docs...


It is just a placeholder for the override logic since you wrote that 
in case of an InterfaceY you want to override the method. You would 
provide override.


Meikel

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient 
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google 
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to clojure+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.




--
--
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: proxy doesn't care about type hints?

[Meikel Brandmeyer (kotarak)]

Am Montag, 15. April 2013 23:03:56 UTC+2 schrieb Jim foo.bar:
>
> On 15/04/13 21:37, Meikel Brandmeyer (kotarak) wrote: 
> > 
> > (proxy [YourClass BarInterface] [] 
> >   (bar [x-or-y] 
> > (if (instance? InterfaceY x-or-y) 
> >   (override x-or-y) 
> >   (proxy-super x-or-y 
>
> I'm sorry I forgot...what is 'override' above? what fn is this? I cannot 
> find docs... 
>

It is just a placeholder for the override logic since you wrote that in 
case of an InterfaceY you want to override the method. You would provide 
override.

Meikel

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

Re: proxy doesn't care about type hints?

[Jim - FooBar();]

On 15/04/13 21:37, Meikel Brandmeyer (kotarak) wrote:


(proxy [YourClass BarInterface] []
  (bar [x-or-y]
(if (instance? InterfaceY x-or-y)
  (override x-or-y)
  (proxy-super x-or-y


I'm sorry I forgot...what is 'override' above? what fn is this? I cannot 
find docs...



Jim

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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: proxy doesn't care about type hints?

[Jim - FooBar();]

On 15/04/13 21:37, Meikel Brandmeyer (kotarak) wrote:


Their might be cases where this works. And where it doesn't. Eg. when 
the X-bar calls the Y-bar.


Unfortunately that is exactly what is happening... :(

http://grepcode.com/file/repo1.maven.org/maven2/org.apache.uima/uimaj-core/2.4.0/org/apache/uima/analysis_component/JCasAnnotator_ImplBase.java/

line 46 and 67 to save you potential time...
the non-abstract method which accepts the more general Interface, casts 
its argument and delegates to the more specific signature (which is 
supposed to be overriden) with that cast...


The problem is that this is not an uncommon pattern in Java...It may be 
the first time I'm working with it but I've seen it elsewhere...that is 
whay it sort of surprises we don't have a good story for that...even 
gen-class is getting slightly ugly and complicated...but nothing beats 
'proxy' (If i could use it!)...



Jim

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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: proxy doesn't care about type hints?

[Meikel Brandmeyer (kotarak)]

Hi,

Am Montag, 15. April 2013 20:57:30 UTC+2 schrieb Jim foo.bar:
>
>  Hi everyone,
>
> I was very surprised to find out that it is practically impossible to 
> subclass some Class Foo and override only 1 overload of some method bar() 
> via proxy...especially, if there are more than 1 methods 'bar' taking args 
> like below, where InterfaceY extends InterfaceX. Providing the types does 
> nothing - it seems proxy only cares about arity
>
> void bar(InterfaceX ix); //*not *supposed to be overriden
>
> abstract void bar(InterfaceY iy); //but this is indeed supposed to be 
> overriden
>
>
Does this work?

(proxy [YourClass BarInterface] []
  (bar [x-or-y]
(if (instance? InterfaceY x-or-y)
  (override x-or-y)
  (proxy-super x-or-y

Their might be cases where this works. And where it doesn't. Eg. when the 
X-bar calls the Y-bar.

Meikel

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

Re: docs for clojure.java.jdbc 0.3.x

[Josh Kamau]

Thanks. I will wait for the 0.3 docs. I didnt want to "memorize" the old
API.

Josh


On Mon, Apr 15, 2013 at 9:16 PM, Sean Corfield wrote:

> Yup, autodoc is not run automatically on every commit/build so the
> generated docs tend to lag a little behind the source code (for all
> contrib libraries). What's currently on
> http://clojure.github.com/java.jdbc/ is pretty close to the current
> state of 0.3.0-alpha1. The biggest difference is that the associated
> documentation (linked from that page) shows the old API in examples
> and that has all been rewritten recently to use the new API. You can
> see the updated docs here:
> https://github.com/clojure/java.jdbc/tree/master/doc/clojure/java/jdbc
>
> Perhaps Tom F can oblige by running the autodoc task for us to update
> everything?
>
> Sean
>
> On Mon, Apr 15, 2013 at 8:03 AM,   wrote:
> > Hello, Josh
> >
> > http://clojure.github.io/java.jdbc/
> > Actually described about 0.3.x APIs.
> >
> > 2013年4月15日月曜日 20時53分24秒 UTC+9 Josh Kamau:
> >>
> >> Hello ;
> >>
> >> Where can i find the 'generated docs' for clojure.java.jdbc 0.3.x ? i
> can
> >> only see the docs for 0.2.4
> >>
> >>
> >> Josh
> >
> > --
> > --
> > 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.
>
>
>

-- 
-- 
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] Schejulure 0.1.3

[Anthony Grimes]

You had me at the changelog entry regarding Sundays.

I was actually tasked with writing pretty much this at work last Friday. My 
thanks for doing my work for me. Unfortunately I don't think you will be 
paid for your troubles.

On Monday, April 15, 2013 6:02:02 AM UTC-7, Adam Clements wrote:
>
> I forgot to mention, schejulure can be obtained from the normal places:
>
> Github:
> https://github.com/AdamClements/schejulure 
>
> Clojars: 
> [schejulure "0.1.3"]
>
>
> Adam Clements
>
> +44 7947 724 795
> --
> This email and any files transmitted with it are confidential. If you are 
> not the intended recipient, you are hereby notified that any disclosure, 
> distribution or copying of this communication is strictly prohibited. 
>  
>
> On Mon, Apr 15, 2013 at 11:27 AM, Adam Clements 
> 
> > wrote:
>
>> 0.1.3 - Bugfix release fixing a discrepancy between clj-time and cron's 
>> representation of Sunday (thanks dwwoelfel)
>>
>> *What is Schejulure?*
>> Schejulure is a lightweight, cron-inspired, minute resolution scheduling 
>> library. It has a neat, concise api and no stateful central scheduler. 
>>  It's tiny (~60 lines) and aims to do one task well. It's modelled after 
>> futures, and in fact returns a future, so use it in the same places/way you 
>> might use a future, but for recurring events.
>>
>> To schedule things, it's like a cron setup (so by default fires every 
>> minute of every hour of every day...) but you can merge a map with lists of 
>> times when it should fire, so for example {:minute [0 15 30 45] :day :tue} 
>> will fire every 15 minutes on a tuesday where {:hour 9} will fire every 
>> minute from 9-10am every day. Beyond that you simply call schedule with 
>> pairs of schedule maps to functions which should fire.
>>
>> *Example:*
>> => (def my-running-scheduler
>>  (schedule {:hour 12 :minute [0 15 30 45]} my-function
>>{:hour (range 0 24 6) :minute 0 :day [:sat :sun]} 
>> batch-job))
>>
>> ...
>> => (future-cancel my-running-scheduler)
>>
>> Simple as that.
>>
>> -- 
>> -- 
>> 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: Type hinting generated functions

[Alan Malloy]

If all the functions you want to generate accept doubles, you can just 
modify str-sym to include a (with-meta (symbol ...) {:tag 'double}) and it 
should generate exactly the code in your hand-written version. As an aside, 
there's no reason for str-sym to be a macro: it should just be a function 
like (symbol (apply str args)).

On Monday, April 15, 2013 2:59:27 AM UTC-7, dannyg wrote:
>
> Hi all, 
>
> I was writing some code and became idly curious about making it more 
> 'general' but still performant.  Specifically I thought it'd be neat 
> to auto-generate a series of vector-based operations from a single 
> specification.  So instead of many functions like this by hand: 
>
> (defn vadd3 [[^double a1 ^double a2 ^double a3] [^double b1 ^double b2 
> ^double b3]] 
>   [(+ a1 b1) (+ a2 b2) (+ a3 b3)]) 
>
> I'd instead have a macro generate them. Pretty low level ops (yes not 
> really suited for clojure but I like exploring the limits) and I was 
> pretty happy with the performance: 
>
> (bench 1e7 (vadd3 [1.1 2.2 3.3] [2.2 3.3 4.4])) 
> "Elapsed time: 1799.587 msecs" 
>
> Here we have my attempt to generalise it: 
>
> (defmacro -make-vec-ops 
>  [{:keys [name op start end] :or {start 2}}] 
>  (cons `do (for [n (range start end)] 
>  `(defn ~(str-sym- \v n name) 
> ~name 
>  [[~@(for [x (range n)] (str-sym- "a" x)) :as ~'a] 
>   [~@(for [x (range n)] (str-sym- "b" x)) :as ~'b]] 
> [~@(for [x (range n)] 
>  `(~op ~(str-sym- "a" x) ~(str-sym- "b" x)))] 
>
> (bench 1e7 (v3add [1.1 2.2 3.3] [2.2 3.3 4.4])) 
> "Elapsed time: 2238.391 msecs" 
>
> The performacne isn't 'too bad' at 25% lower.  But it's frustratingly 
> close to matching the original too!  I tried toying with some other 
> answers I found about generating type-metadat.  Alas, my resulting 
> macros were either malformed (unsupported binding forms) or didn't 
> appear to generate anything in the final functions/performance was the 
> same. 
>
> I'd love to be wowed by a simple solution!  Heck 'any' solution that 
> works ;) 
>
> As an aside, the macro is pretty ugly... I tried extracting the vector 
> deconstruction to a second macro, like this 
>
>   (defmacro -varg [a n] 
> `(~@(for [x (range n)] (str-sym- a x)) :as ~a)) 
>
> where str-sym- 
>
>   (defmacro str-sym-  [& args] `(symbol (str ~@args))) 
>
> But couldn't quite to get it to work :/ 
>
> Cheers, 
> Daniel Grigg 
>

-- 
-- 
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: proxy doesn't care about type hints?

[Herwig Hochleitner]

2013/4/15 Jim - FooBar(); 

>  I was very surprised to find out that it is practically impossible to
> subclass some Class Foo and override only 1 overload of some method bar()
> via proxy...especially, if there are more than 1 methods 'bar' taking args
> like below, where InterfaceY extends InterfaceX. Providing the types does
> nothing - it seems proxy only cares about arity
>

I don't think proxy can do that, save for dispatching to proxy-super
yourself.
gen-class seems to support for overriding based on type signature,
demonstrated here
http://dishevelled.net/Tricky-uses-of-Clojure-gen-class-and-AOT-compilation.html
Since this is not documented, I wonder if it's officially supported, though.

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

proxy doesn't care about type hints?

[Jim - FooBar();]

Hi everyone,

I was very surprised to find out that it is practically impossible to 
subclass some Class Foo and override only 1 overload of some method 
bar() via proxy...especially, if there are more than 1 methods 'bar' 
taking args like below, where InterfaceY extends InterfaceX. Providing 
the types does nothing - it seems proxy only cares about arity


void bar(InterfaceX ix); //*not *supposed to be overriden

abstract void bar(InterfaceY iy); //but this is indeed supposed to be 
overriden


Should I just give up?

Jim

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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ANN: Kern 0.7.0 text parsing lib has fixes, better performance

[Armando Blancas]

You're very welcome. Glad to know the lib is useful.

On Monday, April 15, 2013 10:15:30 AM UTC-7, Omer Iqbal wrote:
>
> Thanks Armando! I've been using kern for a number of projects and I'm 
> really grateful for the awesome documentation :)
>
>
>
> On Tue, Apr 16, 2013 at 12:38 AM, Armando Blancas 
> 
> > wrote:
>
>> This is a much needed clean up and perf boost release. 
>>
>> https://github.com/blancas/kern
>>
>> Function (parse-file) won't choke with big files, while new parsers 
>> (parse-data) and (parse-data-file) work much faster by relaxing their 
>> house-keeping for input that's expected to be alright (e.g., serialized 
>> data).
>>
>> Parser (search) will match a pattern anywhere in the input, not just at 
>> the start. The new lexer configuration for a leading sign in numbers helps 
>> in cases where the lexical sign interferes with the grammar for 
>> expressions. The Wiki now includes a chapter in lexer config:
>>
>> https://github.com/blancas/kern/wiki/How-to-Customize-the-Lexer
>>
>> Documentation and samples:
>> https://github.com/blancas/kern/wiki
>> http://blancas.github.io/kern/
>>
>> For bug reports, feedback, and feature requests:
>> https://github.com/blancas/kern/issues?state=open
>>
>>  -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to 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: Namespaces, APIs, protocols and records

[Stuart Sierra]

>
> "...talk by Stuart Sierra (http://vimeo.com/46163090) in which he suggests 
> putting protocols and their implementations in separate namespaces, 
> because, during development reloading a protocol breaks existing instances"
>

I don't universally recommend this any more. You still have to be careful 
with reloading. The documentation for 
tools.namespacedescribes some the 
issues with reloading and protocols, and ways to work 
around them.

-S

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

Re: docs for clojure.java.jdbc 0.3.x

[Sean Corfield]

Yup, autodoc is not run automatically on every commit/build so the
generated docs tend to lag a little behind the source code (for all
contrib libraries). What's currently on
http://clojure.github.com/java.jdbc/ is pretty close to the current
state of 0.3.0-alpha1. The biggest difference is that the associated
documentation (linked from that page) shows the old API in examples
and that has all been rewritten recently to use the new API. You can
see the updated docs here:
https://github.com/clojure/java.jdbc/tree/master/doc/clojure/java/jdbc

Perhaps Tom F can oblige by running the autodoc task for us to update
everything?

Sean

On Mon, Apr 15, 2013 at 8:03 AM,   wrote:
> Hello, Josh
>
> http://clojure.github.io/java.jdbc/
> Actually described about 0.3.x APIs.
>
> 2013年4月15日月曜日 20時53分24秒 UTC+9 Josh Kamau:
>>
>> Hello ;
>>
>> Where can i find the 'generated docs' for clojure.java.jdbc 0.3.x ? i can
>> only see the docs for 0.2.4
>>
>>
>> Josh
>
> --
> --
> 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.

Clojurescript Error: Undefined nameToPath for goog.ui

[Răzvan Rotaru]

Hi,

I am currently unable to get to the bottom of a "undefined nameToPath" 
error in clojurescript. Here's the script:

*test.cljs:*
(ns test
  (:require [goog.dom :as gdom] [goog.ui :as gui]))

(.render (new gui/Button "Hello!") (gdom/getElement "b1"))

And the compiled output:

*test.js (compiled) :*
goog.provide('test');
goog.require('cljs.core');
goog.require('goog.ui');
goog.require('goog.dom');
(new goog.ui.Button("Hello!")).render(goog.dom.getElement("b1"));


*bootstrap.js (compiled) :*
goog.addDependency("base.js", ['goog'], []);
goog.addDependency("../cljs/core.js", ['cljs.core'], ['goog.string', 
'goog.array', 'goog.object', 'goog.string.format', 
'goog.string.StringBuffer']);
goog.addDependency("../test.js", ['test'], ['cljs.core', 'goog.dom', 
'goog.ui']);

*index.html:*


  

Habarnam
  
  




  goog.require('test');

  


Any ideas what i'm doing wrong here? Thanks.

Răzvan

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

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

[Meikel Brandmeyer (kotarak)]

Hi Pierre,

does this patch work?

8<--8<--8<
diff --git a/test/eu/markosproject/test/LicenseCheckerTest.java 
b/test/eu/markosproject/test/LicenseCheckerTest.java
index 2e017cc..1a1cc82 100644
--- a/test/eu/markosproject/test/LicenseCheckerTest.java
+++ b/test/eu/markosproject/test/LicenseCheckerTest.java
@@ -11,8 +11,12 @@ import 
eu.markosproject.commons.interfaces.licensing.ICheckerResultStorer;
 import eu.markosproject.commons.interfaces.licensing.IRNotification;
 import eu.markosproject.licensing.LicenseChecker;
 
+import clojure.lang.RT;
 
 public class LicenseCheckerTest {
+ static {
+ RT.var("clojure.core", "require").invoke(RT.var("clojure.core", 
"symbol").invoke("eu.markosproject.licensing"));
+ }
  
  private final static Logger log = 
Logger.getLogger(LicenseCheckerTest.class .getName()); 
  
8<--8<--8<

I'm not convinced that records are supposed to be created directly. (Ok. 
Testing. Maybe.) They should be an implementation detail returned by an 
API. If you need Java access there you might want to still go the Clojure 
route and provide Java access through a façade. cf. Rich Hickey's example 
of 
Datomic: 
http://skillsmatter.com/podcast/scala/impromptu-rich-hickey-lightning-talk

Meikel

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

Re: ANN: Kern 0.7.0 text parsing lib has fixes, better performance

[Omer Iqbal]

Thanks Armando! I've been using kern for a number of projects and I'm
really grateful for the awesome documentation :)



On Tue, Apr 16, 2013 at 12:38 AM, Armando Blancas wrote:

> This is a much needed clean up and perf boost release.
>
> https://github.com/blancas/kern
>
> Function (parse-file) won't choke with big files, while new parsers
> (parse-data) and (parse-data-file) work much faster by relaxing their
> house-keeping for input that's expected to be alright (e.g., serialized
> data).
>
> Parser (search) will match a pattern anywhere in the input, not just at
> the start. The new lexer configuration for a leading sign in numbers helps
> in cases where the lexical sign interferes with the grammar for
> expressions. The Wiki now includes a chapter in lexer config:
>
> https://github.com/blancas/kern/wiki/How-to-Customize-the-Lexer
>
> Documentation and samples:
> https://github.com/blancas/kern/wiki
> http://blancas.github.io/kern/
>
> For bug reports, feedback, and feature requests:
> https://github.com/blancas/kern/issues?state=open
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

[Armando Blancas]

This is a much needed clean up and perf boost release. 

https://github.com/blancas/kern

Function (parse-file) won't choke with big files, while new parsers 
(parse-data) and (parse-data-file) work much faster by relaxing their 
house-keeping for input that's expected to be alright (e.g., serialized 
data).

Parser (search) will match a pattern anywhere in the input, not just at the 
start. The new lexer configuration for a leading sign in numbers helps in 
cases where the lexical sign interferes with the grammar for expressions. 
The Wiki now includes a chapter in lexer config:

https://github.com/blancas/kern/wiki/How-to-Customize-the-Lexer

Documentation and samples:
https://github.com/blancas/kern/wiki
http://blancas.github.io/kern/

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

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

Re: Namespaces, APIs, protocols and records

[Travis Vachon]

>  I definitely like that it keeps things simpler for me (the implementer), but 
> clients have to know about multiple namespaces rather than a single namespace 
> and I don't like that.

Ah, right - I've mostly been working in application code, not
libraries. That said, I think the heuristic still works - I'd
definitely try writing some code that consumes your library, either in
tests or in a dummy project, and apply the same rule: can you give the
namespace a name that makes function calls clearer? Given a single
name, are there pieces that feel out of place?

This is a topic that comes up a lot, and I think that's at least
partially because different domains and library styles call for
different strategies. An ideal library that does one thing really well
might indeed be a good candidate for one big public namespace, but of
course internally it might make a lot of sense to break the
implementation up into focused modules.

You might check out the clojurewerks libraries for some insight from a
group that has written quite a few libraries:

http://clojurewerkz.org/

Travis

On Mon, Apr 15, 2013 at 11:23 AM, Simon Katz  wrote:
> I'm considering going this way.  I definitely like that it keeps things
> simpler for me (the implementer), but clients have to know about multiple
> namespaces rather than a single namespace and I don't like that.
>
> I must say I'm finding it hard to decide which way to go.
>
>
> On Monday, 15 April 2013 15:31:49 UTC+1, travis vachon wrote:
>>
>> For what it's worth, I've been refactoring big namespaces out into
>> small, focused namespaces lately. A rough heuristic I've found useful
>> is that when I require a namespace I should be able to assign it a
>> name that aids with readability.
>>
>> So for example:
>>
>> (ns foo.book)
>>
>> (defn search [book term]
>>   ;;search the book
>>   )
>> --
>> (ns foo.stacks)
>>
>> (defn search [stacks title]
>> ;; search stacks
>> )
>> --
>> (ns foo.library
>>   (require [foo.book :as book]
>>   [foo.stacks :as stacks]))
>>
>> (defn find-passage [stacks passage title]
>>   (-> stacks
>>(stacks/search title)
>>(books/search passage)))
>> -
>>
>> This is all pretty contrived, but it seems to work out in the wild
>> pretty well. YMMV, and I'm still not settled on this myself, but
>> hopefully that helps.
>>
>> Travis
>>
>>
>>
>>
>>
>> On Sun, Apr 14, 2013 at 2:16 PM, Simon Katz  wrote:
>> > Whoops — when I said "with an extra [namespace] for each protocol", I
>> > meant
>> > "with an extra [namespace] for each protocol implementation".
>> >
>> >
>> > On Sunday, 14 April 2013 18:21:19 UTC+1, Simon Katz wrote:
>> >>
>> >> I'm in the process of trying to work out how I want to use namespaces
>> >> when
>> >> implementing libraries or subsystems.
>> >>
>> >> I'm aware of several approaches:
>> >>
>> >> Use a single namespace, making only the API public (either with
>> >> everything
>> >> in a single file or breaking things into multiple files and using
>> >> `load`).
>> >> Use implementation namespaces and create an API in a separate namespace
>> >> (perhaps using Potemkin to simplify the creation of the API).
>> >> Have lots of smaller namespaces and have the client need to know which
>> >> of
>> >> the smaller namespaces to use for what.
>> >> (And some variations.)
>> >>
>> >>
>> >> I'm fairly happy with large namespaces, so I'm leaning towards using a
>> >> single namespace.
>> >>
>> >> There's one thing I've come across that doesn't fit nicely with putting
>> >> everything into a single namespace, though.  A Google search for
>> >> "Clojure in
>> >> the Large" led me to a nice talk by Stuart Sierra
>> >> (http://vimeo.com/46163090) in which he suggests putting protocols and
>> >> their
>> >> implementations in separate namespaces, because, during development
>> >> reloading a protocol breaks existing instances.  (I know Stuart gave a
>> >> similarly presentation at Clojure West recently, but I don't think the
>> >> video
>> >> of that is available yet.)
>> >>
>> >> Having the separate namespaces would be fine if I was heading down the
>> >> route of having the client know about multiple namespaces, but I don't
>> >> really want to do that.  With the single namespace approach (with an
>> >> extra
>> >> one for each protocol I define), I end up wanting circular dependencies
>> >> — a
>> >> namespace containing a protocol implementation needs to refer to the
>> >> main
>> >> namespace in order to mention the protocol, and the main namespace
>> >> needs to
>> >> refer to the namespaces containing protocol implementations in order to
>> >> invoke constructors.
>> >>
>> >> Maybe I'll just put everything in a single namespace and be careful
>> >> about
>> >> reloading the whole thing when I care about existing instances of
>> >> protocols.
>> >>
>> >> Any other suggestions?
>> >>
>> >> Simon
>> >
>> > --
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.

Re: docs for clojure.java.jdbc 0.3.x

[shinmuro]

Hello, Josh

http://clojure.github.io/java.jdbc/
Actually described about 0.3.x APIs.

2013年4月15日月曜日 20時53分24秒 UTC+9 Josh Kamau:
>
> Hello ;
>
> Where can i find the 'generated docs' for clojure.java.jdbc 0.3.x ? i can 
> only see the docs for 0.2.4
>
>
> Josh
>  

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

Re: Namespaces, APIs, protocols and records

[Simon Katz]

I'm considering going this way.  I definitely like that it keeps things 
simpler for me (the implementer), but clients have to know about multiple 
namespaces rather than a single namespace and I don't like that.

I must say I'm finding it hard to decide which way to go.

On Monday, 15 April 2013 15:31:49 UTC+1, travis vachon wrote:
>
> For what it's worth, I've been refactoring big namespaces out into 
> small, focused namespaces lately. A rough heuristic I've found useful 
> is that when I require a namespace I should be able to assign it a 
> name that aids with readability. 
>
> So for example: 
>
> (ns foo.book) 
>
> (defn search [book term] 
>   ;;search the book 
>   ) 
> -- 
> (ns foo.stacks) 
>
> (defn search [stacks title] 
> ;; search stacks 
> ) 
> -- 
> (ns foo.library 
>   (require [foo.book :as book] 
>   [foo.stacks :as stacks])) 
>
> (defn find-passage [stacks passage title] 
>   (-> stacks 
>(stacks/search title) 
>(books/search passage))) 
> - 
>
> This is all pretty contrived, but it seems to work out in the wild 
> pretty well. YMMV, and I'm still not settled on this myself, but 
> hopefully that helps. 
>
> Travis 
>
>
>
>
>
> On Sun, Apr 14, 2013 at 2:16 PM, Simon Katz > 
> wrote: 
> > Whoops — when I said "with an extra [namespace] for each protocol", I 
> meant 
> > "with an extra [namespace] for each protocol implementation". 
> > 
> > 
> > On Sunday, 14 April 2013 18:21:19 UTC+1, Simon Katz wrote: 
> >> 
> >> I'm in the process of trying to work out how I want to use namespaces 
> when 
> >> implementing libraries or subsystems. 
> >> 
> >> I'm aware of several approaches: 
> >> 
> >> Use a single namespace, making only the API public (either with 
> everything 
> >> in a single file or breaking things into multiple files and using 
> `load`). 
> >> Use implementation namespaces and create an API in a separate namespace 
> >> (perhaps using Potemkin to simplify the creation of the API). 
> >> Have lots of smaller namespaces and have the client need to know which 
> of 
> >> the smaller namespaces to use for what. 
> >> (And some variations.) 
> >> 
> >> 
> >> I'm fairly happy with large namespaces, so I'm leaning towards using a 
> >> single namespace. 
> >> 
> >> There's one thing I've come across that doesn't fit nicely with putting 
> >> everything into a single namespace, though.  A Google search for 
> "Clojure in 
> >> the Large" led me to a nice talk by Stuart Sierra 
> >> (http://vimeo.com/46163090) in which he suggests putting protocols and 
> their 
> >> implementations in separate namespaces, because, during development 
> >> reloading a protocol breaks existing instances.  (I know Stuart gave a 
> >> similarly presentation at Clojure West recently, but I don't think the 
> video 
> >> of that is available yet.) 
> >> 
> >> Having the separate namespaces would be fine if I was heading down the 
> >> route of having the client know about multiple namespaces, but I don't 
> >> really want to do that.  With the single namespace approach (with an 
> extra 
> >> one for each protocol I define), I end up wanting circular dependencies 
> — a 
> >> namespace containing a protocol implementation needs to refer to the 
> main 
> >> namespace in order to mention the protocol, and the main namespace 
> needs to 
> >> refer to the namespaces containing protocol implementations in order to 
> >> invoke constructors. 
> >> 
> >> Maybe I'll just put everything in a single namespace and be careful 
> about 
> >> reloading the whole thing when I care about existing instances of 
> protocols. 
> >> 
> >> Any other suggestions? 
> >> 
> >> Simon 
> > 
> > -- 
> > -- 
> > 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

Re: Namespaces, APIs, protocols and records

[Travis Vachon]

For what it's worth, I've been refactoring big namespaces out into
small, focused namespaces lately. A rough heuristic I've found useful
is that when I require a namespace I should be able to assign it a
name that aids with readability.

So for example:

(ns foo.book)

(defn search [book term]
  ;;search the book
  )
--
(ns foo.stacks)

(defn search [stacks title]
;; search stacks
)
--
(ns foo.library
  (require [foo.book :as book]
  [foo.stacks :as stacks]))

(defn find-passage [stacks passage title]
  (-> stacks
   (stacks/search title)
   (books/search passage)))
-

This is all pretty contrived, but it seems to work out in the wild
pretty well. YMMV, and I'm still not settled on this myself, but
hopefully that helps.

Travis





On Sun, Apr 14, 2013 at 2:16 PM, Simon Katz  wrote:
> Whoops — when I said "with an extra [namespace] for each protocol", I meant
> "with an extra [namespace] for each protocol implementation".
>
>
> On Sunday, 14 April 2013 18:21:19 UTC+1, Simon Katz wrote:
>>
>> I'm in the process of trying to work out how I want to use namespaces when
>> implementing libraries or subsystems.
>>
>> I'm aware of several approaches:
>>
>> Use a single namespace, making only the API public (either with everything
>> in a single file or breaking things into multiple files and using `load`).
>> Use implementation namespaces and create an API in a separate namespace
>> (perhaps using Potemkin to simplify the creation of the API).
>> Have lots of smaller namespaces and have the client need to know which of
>> the smaller namespaces to use for what.
>> (And some variations.)
>>
>>
>> I'm fairly happy with large namespaces, so I'm leaning towards using a
>> single namespace.
>>
>> There's one thing I've come across that doesn't fit nicely with putting
>> everything into a single namespace, though.  A Google search for "Clojure in
>> the Large" led me to a nice talk by Stuart Sierra
>> (http://vimeo.com/46163090) in which he suggests putting protocols and their
>> implementations in separate namespaces, because, during development
>> reloading a protocol breaks existing instances.  (I know Stuart gave a
>> similarly presentation at Clojure West recently, but I don't think the video
>> of that is available yet.)
>>
>> Having the separate namespaces would be fine if I was heading down the
>> route of having the client know about multiple namespaces, but I don't
>> really want to do that.  With the single namespace approach (with an extra
>> one for each protocol I define), I end up wanting circular dependencies — a
>> namespace containing a protocol implementation needs to refer to the main
>> namespace in order to mention the protocol, and the main namespace needs to
>> refer to the namespaces containing protocol implementations in order to
>> invoke constructors.
>>
>> Maybe I'll just put everything in a single namespace and be careful about
>> reloading the whole thing when I care about existing instances of protocols.
>>
>> Any other suggestions?
>>
>> Simon
>
> --
> --
> 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: [ANN] Schejulure 0.1.3

[Adam Clements]

I forgot to mention, schejulure can be obtained from the normal places:

Github:
https://github.com/AdamClements/schejulure

Clojars:
[schejulure "0.1.3"]


Adam Clements

+44 7947 724 795
--
This email and any files transmitted with it are confidential. If you are
not the intended recipient, you are hereby notified that any disclosure,
distribution or copying of this communication is strictly prohibited.


On Mon, Apr 15, 2013 at 11:27 AM, Adam Clements wrote:

> 0.1.3 - Bugfix release fixing a discrepancy between clj-time and cron's
> representation of Sunday (thanks dwwoelfel)
>
> *What is Schejulure?*
> Schejulure is a lightweight, cron-inspired, minute resolution scheduling
> library. It has a neat, concise api and no stateful central scheduler.
>  It's tiny (~60 lines) and aims to do one task well. It's modelled after
> futures, and in fact returns a future, so use it in the same places/way you
> might use a future, but for recurring events.
>
> To schedule things, it's like a cron setup (so by default fires every
> minute of every hour of every day...) but you can merge a map with lists of
> times when it should fire, so for example {:minute [0 15 30 45] :day :tue}
> will fire every 15 minutes on a tuesday where {:hour 9} will fire every
> minute from 9-10am every day. Beyond that you simply call schedule with
> pairs of schedule maps to functions which should fire.
>
> *Example:*
> => (def my-running-scheduler
>  (schedule {:hour 12 :minute [0 15 30 45]} my-function
>{:hour (range 0 24 6) :minute 0 :day [:sat :sun]}
> batch-job))
>
> ...
> => (future-cancel my-running-scheduler)
>
> Simple as that.
>
> --
> --
> 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: Namespace loading with defrecord and attempting to call unbound fn

[Pierre Allix]

Hi Meikel,

If you look at the source of this project:

git clone git://git.berlios.de/markos-license-analyser

in the test directory there is a JUnit test where the Clojure record
is instantiated through a normal Java 'new' call.
The record is imported with a normal Java import.

If you want I could create a project reproducing the bug.


On Apr 15, 1:33 pm, "Meikel Brandmeyer (kotarak)" 
wrote:
> Hi,
>
> reading the resources you linked, I got the impression that just the
> initial require is missing. Instead of adding the require to the method, it
> should be added to the application init (or some appropriate static
> initializer? The class giving out instances of the record might be a
> candidate.). That should be sufficient. However there was no complete code
> demonstrating the issue. Only the clojure side. So I may be missing
> something.
>
> Behaviour like for gen-class is not implemented, yet, AFAIK.
>
> Meikel

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

Re: GSOC2013 NDArray implementation

[Mikera]

Hi Vytautas,

I'm the maintainer of core.matrix and originally proposed this as a project 
idea. I'd be happy to give you some tips and proposal ideas.

I suggest we discuss this on the numerical Clojure group: there are plenty 
of insightful conversations on this topic and most of the deep numerics 
discussions happen there:
https://groups.google.com/forum/#!forum/numerical-clojure

  Mike.

On Monday, 15 April 2013 17:56:54 UTC+8, Vytautas Jančauskas wrote:
>
> I'm interested in doing this project. I have Common Lisp and Scheme 
> experience (I completed a scheme gsoc project before) and I work with numpy 
> all the time. Who can I contact about this? Any tips for the proposal? Some 
> organizations seem to have their own set of requirements for the applicants 
> so I'm posting to make sure I don't miss anything.
>

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

docs for clojure.java.jdbc 0.3.x

[Josh Kamau]

Hello ;

Where can i find the 'generated docs' for clojure.java.jdbc 0.3.x ? i can
only see the docs for 0.2.4


Josh

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

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

[Meikel Brandmeyer (kotarak)]

Hi,

reading the resources you linked, I got the impression that just the 
initial require is missing. Instead of adding the require to the method, it 
should be added to the application init (or some appropriate static 
initializer? The class giving out instances of the record might be a 
candidate.). That should be sufficient. However there was no complete code 
demonstrating the issue. Only the clojure side. So I may be missing 
something.

Behaviour like for gen-class is not implemented, yet, AFAIK.

Meikel

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

Re: keyword bug

[Colin Fleming]

This is something I noticed the other day - the reader doc states of
keywords "They cannot contain '.' or name classes". Clearly most qualified
keywords will contain '.'.

On 15 April 2013 18:07, Andy Fingerhut  wrote:

> The description of legal symbols at http://clojure.org/reader could be
> somewhat more explicit on this.  One could read it to mean that since :m/7
> starts with an non-numeric "m" after the :, it is legal.  One could also
> infer from it that since within namespace m you could not use :7 (since
> that starts with a numeric symbol), :m/7 should not be legal, either.  I
> personally believe the second statement is correct, but that is only my
> non-authoritative opinion.
>
> Clojure has a history of functions that do not throw exceptions and return
> what look like perfectly valid return values for symbols, namespaces, and
> keywords, even though the documentation says they are not supported.  For
> example, see http://dev.clojure.org/jira/browse/CLJ-1033
>
> I have no idea whether this is likely to change.  I would guess it isn't
> high priority for Clojure/core members.
>
> Andy
>
>
> On Sun, Apr 14, 2013 at 8:37 AM, ubun2  wrote:
>
>> (keyword "m" "7") ;;=> :m/7
>>
>> :m/7 ;;=> #> :m/7>
>>
>> a bug right?
>>
>> --
>> --
>> 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: Good Clojure style?

[u1204]

> Now it's been a long while since I wrote code to put food on the table - 
> but back then if I saw C or C++ code written like this I would describe it 
> as obfuscated - the sort of thing I would expect to see in the (now 
> defunct?) annual obfuscated C competition. It's concise and rather clever, 
> certainly, but hardly self-documenting: it's not very clear what it's doing 
> at all- with a couple of magic numbers thrown in for good measure. Rather 
> arcane in fact.

Actually there is no such thing as "self documenting code". In order
to understand code one must "be the machine", a skill that is long 
in the making. There is nothing wrong with concise, clever code.
It is, after all, written for the machine.

However, if code needs to be maintained it is probably best to write
English text. In order to understand text one must "be human", a skill
I can't rightly claim on my resume yet. But writing "for the human" is
important if code to live beyond the original author.

Notice that thousands of Sourceforge/github/Savannah projects are
considered "dead" because the author stopped changing it and nobody else
understands it.  The code still works and is probably very concise,
clever, and efficient. Death awaits undocumented code.

There was a conference in Portland called WriteTheDocs 
(http://conf.writethedocs.org). They should be posting videos shortly.
I gave the talk on "Literate Programming in the Large".

There are a lot of people begging programmers to write text. 
Not everyone has internalized the "fetch-execute cycle".
Those that have are not going to waste cycles decoding 
"self documenting code".

Tim Daly
Curmudgeon at large.

-- 
-- 
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] Schejulure 0.1.3

[Adam Clements]

0.1.3 - Bugfix release fixing a discrepancy between clj-time and cron's 
representation of Sunday (thanks dwwoelfel)

*What is Schejulure?*
Schejulure is a lightweight, cron-inspired, minute resolution scheduling 
library. It has a neat, concise api and no stateful central scheduler. 
 It's tiny (~60 lines) and aims to do one task well. It's modelled after 
futures, and in fact returns a future, so use it in the same places/way you 
might use a future, but for recurring events.

To schedule things, it's like a cron setup (so by default fires every 
minute of every hour of every day...) but you can merge a map with lists of 
times when it should fire, so for example {:minute [0 15 30 45] :day :tue} 
will fire every 15 minutes on a tuesday where {:hour 9} will fire every 
minute from 9-10am every day. Beyond that you simply call schedule with 
pairs of schedule maps to functions which should fire.

*Example:*
=> (def my-running-scheduler
 (schedule {:hour 12 :minute [0 15 30 45]} my-function
   {:hour (range 0 24 6) :minute 0 :day [:sat :sun]} batch-job))

...
=> (future-cancel my-running-scheduler)

Simple as that.

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

LambdaNext Clojure Workshop - London May 20-22 2013

[Sam Aaron]

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.

GSOC2013 NDArray implementation

[Vytautas Jančauskas]

I'm interested in doing this project. I have Common Lisp and Scheme 
experience (I completed a scheme gsoc project before) and I work with numpy 
all the time. Who can I contact about this? Any tips for the proposal? Some 
organizations seem to have their own set of requirements for the applicants 
so I'm posting to make sure I don't miss anything.

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

Type hinting generated functions

[dannyg]

Hi all,

I was writing some code and became idly curious about making it more
'general' but still performant.  Specifically I thought it'd be neat
to auto-generate a series of vector-based operations from a single
specification.  So instead of many functions like this by hand:

(defn vadd3 [[^double a1 ^double a2 ^double a3] [^double b1 ^double b2
^double b3]]
  [(+ a1 b1) (+ a2 b2) (+ a3 b3)])

I'd instead have a macro generate them. Pretty low level ops (yes not
really suited for clojure but I like exploring the limits) and I was
pretty happy with the performance:

(bench 1e7 (vadd3 [1.1 2.2 3.3] [2.2 3.3 4.4]))
"Elapsed time: 1799.587 msecs"

Here we have my attempt to generalise it:

(defmacro -make-vec-ops
 [{:keys [name op start end] :or {start 2}}]
 (cons `do (for [n (range start end)]
 `(defn ~(str-sym- \v n name)
~name
 [[~@(for [x (range n)] (str-sym- "a" x)) :as ~'a]
  [~@(for [x (range n)] (str-sym- "b" x)) :as ~'b]]
[~@(for [x (range n)]
 `(~op ~(str-sym- "a" x) ~(str-sym- "b" x)))]

(bench 1e7 (v3add [1.1 2.2 3.3] [2.2 3.3 4.4]))
"Elapsed time: 2238.391 msecs"

The performacne isn't 'too bad' at 25% lower.  But it's frustratingly
close to matching the original too!  I tried toying with some other
answers I found about generating type-metadat.  Alas, my resulting
macros were either malformed (unsupported binding forms) or didn't
appear to generate anything in the final functions/performance was the
same.

I'd love to be wowed by a simple solution!  Heck 'any' solution that
works ;)

As an aside, the macro is pretty ugly... I tried extracting the vector
deconstruction to a second macro, like this

  (defmacro -varg [a n]
`(~@(for [x (range n)] (str-sym- a x)) :as ~a))

where str-sym-

  (defmacro str-sym-  [& args] `(symbol (str ~@args)))

But couldn't quite to get it to work :/

Cheers,
Daniel Grigg

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

Re: Namespaces, APIs, protocols and records

[Simon Katz]

Thanks — this works nicely.  I think it's a shame that if I want to make 
protocol methods public I have to use the "Use implementation namespaces 
and create an API in a separate namespace" approach, but I guess this is 
the only way.

On Monday, 15 April 2013 01:52:37 UTC+1, Mikera wrote:
>
> You may want to look at what core.matrix does in this regard:
>
> clojure.core.matrix: single namespace containing the public API
> clojure.core.matrix.protocols: namespace containing all the protocols
> clojure.core.matrix.impl.* : namespaces for specific implementations / 
> subsystems
> + a few utility namespaces
>
> The rationale for this is:
>
> it's better for users if the public API is in a single namespace
> the public API needs to require some of the implementations, so these need 
> their own namespaces
> the implementations need the protocols, so these have to be in a separate 
> namespace
>
> Note how this structure has been driven to some extent by the problem of 
> circular dependencies.
>
> On Monday, 15 April 2013 01:21:19 UTC+8, Simon Katz wrote:
>>
>> I'm in the process of trying to work out how I want to use namespaces 
>> when implementing libraries or subsystems.
>>
>> I'm aware of several approaches:
>>
>>- Use a single namespace, making only the API public (either with 
>>everything in a single file or breaking things into multiple files and 
>>using `load`).
>>- Use implementation namespaces and create an API in a separate 
>>namespace (perhaps using Potemkin to simplify the creation of the API).
>>- Have lots of smaller namespaces and have the client need to know 
>>which of the smaller namespaces to use for what.
>>- (And some variations.)
>>
>>
>> I'm fairly happy with large namespaces, so I'm leaning towards using a 
>> single namespace.
>>
>> There's one thing I've come across that doesn't fit nicely with putting 
>> everything into a single namespace, though.  A Google search for "Clojure 
>> in the Large" led me to a nice talk by Stuart Sierra (
>> http://vimeo.com/46163090) in which he suggests putting protocols and 
>> their implementations in separate namespaces, because, during development 
>> reloading a protocol breaks existing instances.  (I know Stuart gave a 
>> similarly presentation at Clojure West recently, but I don't think the 
>> video of that is available yet.)
>>
>> Having the separate namespaces would be fine if I was heading down the 
>> route of having the client know about multiple namespaces, but I don't 
>> really want to do that.  With the single namespace approach (with an extra 
>> one for each protocol I define), I end up wanting circular dependencies — a 
>> namespace containing a protocol implementation needs to refer to the main 
>> namespace in order to mention the protocol, and the main namespace needs to 
>> refer to the namespaces containing protocol implementations in order to 
>> invoke constructors.
>>
>> Maybe I'll just put everything in a single namespace and be careful about 
>> reloading the whole thing when I care about existing instances of protocols.
>>
>> Any other suggestions?
>>
>> Simon
>>
>

-- 
-- 
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: Good Clojure style?

[Tj Gabbour]

BTW, in the case of frequencies, I did find it weird at first. But also 
suspiciously useful. I think the reason is... in Clojure, I really feel how 
I'm constantly moving things from datastructure to datastructure. ("Duh, 
that's what I constantly do in any language...") So we can imagine that a 
useful operation is to map data to simple numbers somehow. What would that 
operation be? Perhaps it's frequencies, which simply associates each datum 
with its count.

It's like learning a vocabulary of words like "partition", "frequencies"... 
These things have technical meanings which may not correspond with everyday 
meanings. ("frequencies" typically evokes something wave- or hardware-like. 
Or one of those boring math class things people suffered through? But when 
you look at the word, it's at least about how frequently something occurs.)

Of course, I use emacs, so after a few times pressing M-., which jumps to 
the docstring, it gets burned into my mind... Like suspicious jargon which 
becomes natural because you're constantly saying it.


All the best,
  Tj

BTW: I recall sitting in a mall waiting for someone, depressed/angry upon 
realizing that to get anything done (without "ugly" code), I'd probably 
have to understand partitioning of potentially infinite sequences, enough 
to use it naturally without mental effort... and for some reason my mind 
wasn't obliging. So I closed my eyes on the mall couch and half-dreamt of 
infinite sequences... imagining the infinite sequences implicit in most 
languages' for-loops, generally constrained before they have a chance to 
become their own logical consequences... and then imagined some visual 
metaphors for chunking down these fellows into partitions...

Yeah, it's a different point of view, and may require some dark mental 
process before it's like, "Duh, just take some elements off that partition 
of infinite sequences..." But I recall when I learned a for-loop to this 
extent; it was a far less pleasant experience. People forget their learning 
process, which seems to be a natural part of mastery. That's why few 
masters can articulate a path to mastery well enough to be good teachers... 
and why we expect things closely related to our masteries to be obvious 
faster.


On Monday, April 15, 2013 10:12:22 AM UTC+2, Tj Gabbour wrote:
>
> Really? You may of course be right; but double-checking [1], I see:
>

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

Namespace loading with defrecord and attempting to call unbound fn

[Pierre Allix]

Hello,

When defining a record with defrecord and calling from Java a method
of the record which is implemented by calling the function of another
namespace, the exception IllegalStateException is thrown with error "
attempting to call unbound fn".

An example of this could be something like that:

(ns mynamespace
  (:require [some-stuff :as s])

(defrecord MyRecord
 []
 MyInterface
 (doSomething [this]
(s/do-something)))

Similar errors are referenced here:

https://groups.google.com/forum/#!msg/clojure-dev/4CtSVWcD15A/shpMuyjMpxsJ

http://stackoverflow.com/questions/10953621/clojure-deftype-calling-function-in-the-same-namespace-throws-java-lang-illegal


A workaround is to use a (require) on the first instruction of the
doSomething method.

For me it looks like a bug and it makes it more difficult than
necessary to interface Clojure from Java for my coworkers.

I'm surprised that this behaviour is still in Clojure 1.5.

Is there some plan to fix that or is "by design" so?

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

[GSoC] Leiningen & Clojure packaging in Debian

[Wolodja Wentland]

Dear Clojurists, 

= Debian selected as a mentoring organization = 

We are happy to announce that Google has selected Debian as a mentoring
organisation for Google Summer of Code 2013!

To see the current list of projects, please head to the dedicated wiki page
[1] which includes, among other projects, one that is of particular interest
to the Clojure community.

= Clojure in Debian =

We are aiming to provide a well integrated and tested platform for Clojure on
Debian and derivatives such as Ubuntu. One of the major obstacles in packaging
Clojure today is, however, that we lack tools that integrate our package build
system with Leiningen. Such tools exist for Java [8] or other major languages,
but packaging Clojure projects still requires a significant amount of manual
work.

The goal of the proposed GSoC project [5] is the creation of tools that ease
the packaging of typical Clojure libraries or applications that utilise
Leiningen as build tool.

As a prerequisite to this we need to package Leiningen 2 and, in particular,
all its dependencies. In helping with this the student will gather hands-on
experience with Debian packaging, our culture and policy in a way that enables
her to continue with the creation of policy compliant packaging tools.

In particular, we expect the student to develop two tools, namely one that
helps with the initial creation of the package from a Leiningen project and
another one that integrates Leiningen into our package build system.

The first tool could, for example, be implemented as a leiningen plugin or as
a standalone tool such as other established helpers like dh_make [6],
jh_makepkg [7] or mh_make (from maven-debian-helper). The second tool should
integrate Leiningen with the debhelper build system in very much the same way
as javahelper [7] allows us to build a variety of Java projects.

= Application procedure =

The formal student application period [0] opens on April 22 at 19:00 UTC and
runs until May 3, 19:00 UTC, but students are encouraged to engage with
prospective mentors and start drafting their proposals now.

If you want to apply as a student, please create a new page following the
application template [2] and link it from our student applications page [3].
You should be aware of the GSoC FAQ [4] and timeline [0].

= Pre-Application Contribution =

This year we require students to make a small contribution to the project they
are interested in. Doing this not only allows us to get an impression of the
way in which the student works and interacts with the mentors, but also allows
the student to get an impression of the work that lies ahead.

Details about this can be found on the wiki [5], but prospective students are
strongly encouraged to join us on IRC or contact us by mail if any question
arises.

[0] http://wiki.debian.org/SummerOfCode2013#Google_timeline
[1] http://wiki.debian.org/SummerOfCode2013/Projects
[2] http://wiki.debian.org/SummerOfCode2013/StudentApplicationTemplate
[3] http://wiki.debian.org/SummerOfCode2013/StudentApplications
[4] 
http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2013/help_page
[5] 
http://wiki.debian.org/SummerOfCode2013/Projects#Leiningen_.26_Clojure_packaging
[6] http://www.debian.org/doc/manuals/maint-guide/first.en.html
[7] http://pkg-java.alioth.debian.org/docs/tutorial.html
[8] http://wiki.debian.org/Java
-- 
Wolodja 

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital signature

Re: Good Clojure style?

[Chris Webster]

Well, Luc, I'm still not convinced there is such a significant decline in 
performance with age - maybe I never reached as high a peak in the first place! 
But I certainly agree that it's important to "work smarter, not harder" as we 
gain the experience to do so, especially in Javaland where so many factors 
combine to reduce productivity (and fun) in our work. I'm encouraged to see so 
many responses from fellow "greybeards" (but where are the women?). Maybe 
Clojure is like jazz - something that many folk don't really get until they've 
been around a while.

As for the OP's question re. Style - many thanks to Erlis for posting the link 
to the Clojure style tips: really helpful to us newbies. Now it's back to Miles 
and macros for this greybeard!

-- 
-- 
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: Good Clojure style?

[Tj Gabbour]

Really? You may of course be right; but double-checking [1], I see:
* it removed the "couple of magic numbers", the original post's most
  substantive technical criticism

* it has a much larger and better docstring

I don't want to come across as zealot-y (who likes that?); it's just my 
opinion and could be wrong! Just seemed that the first example wouldn't 
pass tech review unscathed; but when I dug deeper into the context, I found 
the second and it seemed that would reasonably pass.


To Devil's Advocate myself, there are critiques I personally see:
* Maybe "cells" is better named "living-cells", or documented as such?

* "cells" starts off being the subject... but each neighbor becomes
  the subject. There is a cleverness in this. Maybe a brief comment
  would be apropos.

* mapcat and frequencies are fairly uncommon to use


But to Devil's Advocate my Devil's Advocate, it's in a book which explains 
these things. So the impact of the cleverness or suboptimal naming is a bit 
diminished. Maybe the authors didn't want to belabor the point, due to the 
sharp edge between being explanatory and plodding. And I actually have used 
mapcat and even frequencies, in my tiny helper scripts before I started 
using Clojure for production.

YMMV!


All the best,
  Tj

[1] 
https://github.com/clojurebook/ClojureProgramming/blob/7521bcfb52cdf7e598bca3c4e7860d795a67992c/ch03-game-of-life/src/com/clojurebook/collections/life.clj#L122


On Monday, April 15, 2013 8:40:58 AM UTC+2, edw...@kenworthy.info wrote:
>
> I'm sorry but that's not true. The version over the page hasn't been 
> re-factored 'into a nicer version' it's been re-factored into a more 
> generic version to support, for example, hexagonal grids.
>
> On Saturday, 13 April 2013 23:12:59 UTC+1, Tj Gabbour wrote:
>>
>> Hi,
>>
>> The text explains the "elegant" aspects of it; and then in the next page, 
>> they refactor it into a nicer version which was 40% docstring. [1]
>>
>> So this is like critiquing the readability of someone's first draft. :)
>>
>>
>> All the best,
>>   Tj
>>
>> [1] 
>> https://github.com/clojurebook/ClojureProgramming/blob/7521bcfb52cdf7e598bca3c4e7860d795a67992c/ch03-game-of-life/src/com/clojurebook/collections/life.clj#L122
>>
>>
>> On Wednesday, April 10, 2013 7:27:58 PM UTC+2, edw...@kenworthy.infowrote:
>>>
>>> So, page 143 of Clojure Programming has an implementation of Conway's 
>>> Life:
>>>
>>>   (defn step
>>>   "Yields the next state of the world"
>>>   [cells]
>>>   (set (for [[loc n] (frequencies (mapcat neighbours cells))
>>>
>>> :when (or (= n 3) (and (= n 2) (cells loc)))]
>>>
>>> loc))) 
>>>
>>> The book claims this to be "an elegant implementation'.
>>>
>>> Now it's been a long while since I wrote code to put food on the table - 
>>> but back then if I saw C or C++ code written like this I would describe it 
>>> as obfuscated - the sort of thing I would expect to see in the (now 
>>> defunct?) annual obfuscated C competition. It's concise and rather clever, 
>>> certainly, but hardly self-documenting: it's not very clear what it's doing 
>>> at all- with a couple of magic numbers thrown in for good measure. Rather 
>>> arcane in fact.
>>>
>>> Is it just me? Is this considered to be good Clojure code and I'm just 
>>> hopelessly out of touch and need to get with the programme?
>>>
>>>
>>>
>>>
>>>  

-- 
-- 
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: Good Clojure style?

[Marko Topolnik]

On Monday, April 15, 2013 8:42:56 AM UTC+2, edw...@kenworthy.info wrote:

> Haha! I had similar advice from my Grandfather in the late 70s who 
> predicted that computers will be writing all their own programs in the near 
> future and so the job prospects for working in the field would be quite 
> poor.
>

Once THAT happens, there will be no more jobs of any kind :) 

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