[ANN] logger4clj 0.2

[jkauzlar]

I've been throwing in more little features to the logger4clj API. This 
release focuses on the appenders/formatters library, with support for a 
configurable fields in single-line log statements, the ability to log the 
function and line number of the caller, a file appender with time or 
size-based rollover as well as self-cleanup of old log files, and 
formatters for XML, YAML, clojure data structures and JSON. Hope someone 
will find this useful!

Logger4clj is a heirarchical logging tool written in clojure w/ some minor 
dependencies on JDK6. It is NOT a wrapper for another logging API! 

https://github.com/jkauzlar/logger4clj

In Leiningen via Clojars:  [logger4clj "0.2"]



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

Re: Searching for a picture

[Sébastien Wagener]

Hi, you probably mean this:
http://machinegestalt.posterous.com/if-programming-languages-were-cars


2012/12/28 Qiu Xiafei 

> I'am preparing an introduce of clojure to my colleague.
> I remember that there's a picture showing that clojure = java + lisp, the
> picture must be a good example in my keynote, I think I should refer to it.
> In that picture, java is like a powful SUV with very big wheels, lisp is
> like a cool sedan with two "wings", and clojur is like a monster car with
> big wheels and wings.
> So forget where i saw the picture last time, it seems in some one's
> lecture.
> I will be very priciate if u knonw it, Thanks!
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: Searching for a picture

[Mayank Jain]

Nice :)

On Fri, Dec 28, 2012 at 3:26 PM, Sébastien Wagener
 wrote:
> Hi, you probably mean this:
> http://machinegestalt.posterous.com/if-programming-languages-were-cars
>
>
> 2012/12/28 Qiu Xiafei 
>>
>> I'am preparing an introduce of clojure to my colleague.
>> I remember that there's a picture showing that clojure = java + lisp, the
>> picture must be a good example in my keynote, I think I should refer to it.
>> In that picture, java is like a powful SUV with very big wheels, lisp is
>> like a cool sedan with two "wings", and clojur is like a monster car with
>> big wheels and wings.
>> So forget where i saw the picture last time, it seems in some one's
>> lecture.
>> I will be very priciate if u knonw it, Thanks!
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To 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



-- 
Regards,
Mayank.

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

Re: reduce-kv incompatible with subvec

[Andy Fingerhut]

I am not saying that one would *have* to give up O(1) subvec in order to 
support other operations.

I am guessing, without having done a thorough analysis, that an O(log n) subvec 
based on RRB Trees would make most/all operations on subvec's just fall out 
fairly naturally, rather than having to be written as special cases.

Andy

On Dec 27, 2012, at 8:54 PM, Alan Busby wrote:

> I'm confused why we'd need to give up O(1) just to support something like 
> reduce-kv on subvectors.
> Isn't the implementation of subvector just a wrapper around the original 
> vector along with a start and end value?
> 
> Current source here;
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/APersistentVector.java
> 
> I apologize if I'm missing something key here.
> 
> 
> On Fri, Dec 28, 2012 at 3:18 AM, Andy Fingerhut  
> wrote:
> http://dev.clojure.org/jira/browse/CLJ-1082

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

Re: Searching for a picture

[Qiu Xiafei]

good job!! thanks a lot!


On Fri, Dec 28, 2012 at 9:39 PM, Mayank Jain  wrote:

> Nice :)
>
> On Fri, Dec 28, 2012 at 3:26 PM, Sébastien Wagener
>  wrote:
> > Hi, you probably mean this:
> > http://machinegestalt.posterous.com/if-programming-languages-were-cars
> >
> >
> > 2012/12/28 Qiu Xiafei 
> >>
> >> I'am preparing an introduce of clojure to my colleague.
> >> I remember that there's a picture showing that clojure = java + lisp,
> the
> >> picture must be a good example in my keynote, I think I should refer to
> it.
> >> In that picture, java is like a powful SUV with very big wheels, lisp is
> >> like a cool sedan with two "wings", and clojur is like a monster car
> with
> >> big wheels and wings.
> >> So forget where i saw the picture last time, it seems in some one's
> >> lecture.
> >> I will be very priciate if u knonw it, Thanks!
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Clojure" group.
> >> To post to this group, send email to clojure@googlegroups.com
> >> Note that posts from new members are moderated - please be patient with
> >> your first post.
> >> To unsubscribe from this group, send email to
> >> clojure+unsubscr...@googlegroups.com
> >> For more options, visit this group at
> >> http://groups.google.com/group/clojure?hl=en
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To 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
>
>
>
> --
> Regards,
> Mayank.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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

Re: Will the JVM will always likely, remain the primary Clojure implementation ?

[Stephen Compall]

On Dec 27, 2012 11:55 PM, "Sukh Singh"  wrote:
> Is there any chance of clojure community abandoning the JVM as the
> primary plaform in the future?

Yes.

Who knows what machines lurk in the hearts of programmers?

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

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

Re: Will the JVM will always likely, remain the primary Clojure implementation ?

[Jay Fields]

It might help if you told us why you're asking this question. My guess
would be that you want to introduce Clojure, but you're afraid of
backing yourself into a corner if it begins to die off. If that is the
case, I think choosing to adopt is a safe choice (I've made the same
choice, and many others have as well). If you have another motivation
for your question, you should probably share it.

As far as Rich commiting to a platform, why would he? Who knows that
Oracle will do with the JVM? Who knows what Rich will do with his life
(what if he wanted to dedicate all his time to Datomic?) Why would he
want to commit to anything? Clojure is viable now and available now,
but no one knows what the future holds.

You aren't likely to get commitments, so you have to make the safest
bet given the current information. Currently, Clojure is JVM first.
Smart money says it will be for the foreseeable future, but nothing is
or will ever be guaranteed. If you *need* a guarantee, you probably
shouldn't adopt Clojure. If there's a better option than the JVM,
Clojure may move, and so will most of us. We want to deliver software
- not dedicate ourselves to a specific VM. However, if you're
comfortable making a safe bet, then Clojure+JVM are likely to be
around for a very long time.

On Thu, Dec 27, 2012 at 11:55 PM, Sukh Singh  wrote:
> Is there any chance of clojure community abandoning the JVM as the
> primary plaform in the future?
>
> On Dec 27, 4:41 pm, Michael Klishin 
> wrote:
>> 2012/12/27 Sukh Singh 
>>
>> > From the above statements, can I say that
>>
>> > *the JVM will always likely, remain the primary Clojure implementation* ?
>>
>> The answer is: nobody will give you a definitive answer. This is open
>> source software, "primary" implementations
>> are not "assigned", they are what people actually adopt.
>>
>> Seehttps://groups.google.com/d/topic/clojure/pEWgq1MGbYY/discussion
>> --
>> MK
>>
>> http://github.com/michaelklishinhttp://twitter.com/michaelklishin
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: Will the JVM will always likely, remain the primary Clojure implementation ?

[Softaddicts]

Given the number of JVM implementations available, I think you can qualify this
as a low risk for the near future.

If I would have to move our 15,000 lines code base away from the JVM, I would
be able to do it in about four months. Most of that time would be spent finding
replaçements for some Java libs with a little interop remodeling.

What would be my target ?  Probably CLR since it is close to the JVM 
implementation. JavaScript will be an option in a more distant future.

Like others said, nothings is as still as stone in the software world, otherwise
things like Clojure would not even exists, we would still be rolling on square
weels...

Luc

> On Dec 27, 2012 11:55 PM, "Sukh Singh"  wrote:
> > Is there any chance of clojure community abandoning the JVM as the
> > primary plaform in the future?
> > Yes.
> > Who knows what machines lurk in the hearts of programmers?
> > --
> Stephen Compall
> If anyone in the MSA is online, you should watch this flythrough.
> > -- > You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
Softaddicts sent by ibisMail from my ipad!

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

Re: Will the JVM will always likely, remain the primary Clojure implementation ?

[Eric MacAdie]

Also: Isn't the JVM open source?

- Eric MacAdie

On Fri, Dec 28, 2012 at 11:25 AM, Softaddicts
wrote:

> Given the number of JVM implementations available, I think you can qualify
> this
> as a low risk for the near future.
>
> If I would have to move our 15,000 lines code base away from the JVM, I
> would
> be able to do it in about four months. Most of that time would be spent
> finding
> replaçements for some Java libs with a little interop remodeling.
>
> What would be my target ?  Probably CLR since it is close to the JVM
> implementation. JavaScript will be an option in a more distant future.
>
> Like others said, nothings is as still as stone in the software world,
> otherwise
> things like Clojure would not even exists, we would still be rolling on
> square
> weels...
>
> Luc
>
> > On Dec 27, 2012 11:55 PM, "Sukh Singh"  wrote:
> > > Is there any chance of clojure community abandoning the JVM as the
> > > primary plaform in the future?
> > > Yes.
> > > Who knows what machines lurk in the hearts of programmers?
> > > --
> > Stephen Compall
> > If anyone in the MSA is online, you should watch this flythrough.
> > > -- > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> --
> Softaddicts sent by ibisMail from my ipad!
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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

Re: Will the JVM will always likely, remain the primary Clojure implementation ?

[Softaddicts]

OpenJDK is.



> Also: Isn't the JVM open source?
> > - Eric MacAdie
> > On Fri, Dec 28, 2012 at 11:25 AM, Softaddicts
> wrote:
> > > Given the number of JVM implementations available, I think you can qualify
> > this
> > as a low risk for the near future.
> >
> > If I would have to move our 15,000 lines code base away from the JVM, I
> > would
> > be able to do it in about four months. Most of that time would be spent
> > finding
> > replaçements for some Java libs with a little interop remodeling

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

[ANN] Dire, Erlang-style error handling

[Michael Drogalis]

Hey folks,

After watching The Language of the System and being directed to Joe 
Armstrong's paper on error handling, I concurred that his approach is 
fantastic. I really wanted the same thing for more rudimentary operations, 
like file handling. So I wrote Dire https://github.com/MichaelDrogalis/dire

The pros are of this are that error handling code is removed from 
application logic and it is not order complected.
The cons are that tasks are not as strongly isolated as they are in Erlang. 
Also, because it is so simple (16 lines),
there's no way for a supervisor to "restart" a child task. (Yet, I guess. 
Ideas?)

Can such a thing be useful in a non-distributed environment? Or does this 
look like a hassle to use?


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

Re: [ANN] Dire, Erlang-style error handling

[Marc Boschma]

Would it make sense for the handler to have access to the exception 'e' ?

On 29/12/2012, at 6:14 AM, Michael Drogalis  wrote:

> Hey folks,
> 
> After watching The Language of the System and being directed to Joe 
> Armstrong's paper on error handling, I concurred that his approach is 
> fantastic. I really wanted the same thing for more rudimentary operations, 
> like file handling. So I wrote Dire https://github.com/MichaelDrogalis/dire
> 
> The pros are of this are that error handling code is removed from application 
> logic and it is not order complected.
> The cons are that tasks are not as strongly isolated as they are in Erlang. 
> Also, because it is so simple (16 lines),
> there's no way for a supervisor to "restart" a child task. (Yet, I guess. 
> Ideas?)
> 
> Can such a thing be useful in a non-distributed environment? Or does this 
> look like a hassle to use?
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: [ANN] Dire, Erlang-style error handling

[Michael Drogalis]

Perhaps. Is there anything in the exception object that is useful? I passed 
on it because the implementer of a handler already knows what 
exception occurred. I'm happy to pass it as an argument if we have good 
reasons for it.

On Friday, December 28, 2012 2:54:45 PM UTC-5, marc wrote:
>
> Would it make sense for the handler to have access to the exception 'e' ?
>
> On 29/12/2012, at 6:14 AM, Michael Drogalis > 
> wrote:
>
> Hey folks,
>
> After watching The Language of the System and being directed to Joe 
> Armstrong's paper on error handling, I concurred that his approach is 
> fantastic. I really wanted the same thing for more rudimentary operations, 
> like file handling. So I wrote Dire 
> https://github.com/MichaelDrogalis/dire
>
> The pros are of this are that error handling code is removed from 
> application logic and it is not order complected.
> The cons are that tasks are not as strongly isolated as they are in 
> Erlang. Also, because it is so simple (16 lines),
> there's no way for a supervisor to "restart" a child task. (Yet, I guess. 
> Ideas?)
>
> Can such a thing be useful in a non-distributed environment? Or does this 
> look like a hassle to use?
>
>
>  -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com 
> Note that posts from new members are moderated - please be patient with 
> your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>
>

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

Re: [ANN] Dire, Erlang-style error handling

[Craig Brozefsky]

Michael Drogalis  writes:

>Perhaps. Is there anything in the exception object that is useful? I
>passed on it because the implementer of a handler already knows what
>exception occurred. I'm happy to pass it as an argument if we have good
>reasons for it.

If my handler is going to log error details for later debuggery?

If my restart or other aspect of handling it depends on a detail of the
failure, like the schema of the URL that I couldn't request...

Basically, nearly all of my current error handling logic assumes I have
access to the exception.  Without this, I have almost no hope of
translating them to dire.

-- 
Craig Brozefsky 
Premature reification is the root of all evil

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

Re: [ANN] Dire, Erlang-style error handling

[Michael Drogalis]

I kind of forgot about user defined exceptions containing useful things. 
Good point. Deployed this adjustment to dire-0.1.0 with commit 
https://github.com/MichaelDrogalis/dire/commit/4a493e85ca88dd59806651264103de53a2879b66

On Friday, December 28, 2012 3:32:41 PM UTC-5, Craig Brozefsky wrote:
>
> Michael Drogalis > writes: 
>
> >Perhaps. Is there anything in the exception object that is useful? I 
> >passed on it because the implementer of a handler already knows what 
> >exception occurred. I'm happy to pass it as an argument if we have 
> good 
> >reasons for it. 
>
> If my handler is going to log error details for later debuggery? 
>
> If my restart or other aspect of handling it depends on a detail of the 
> failure, like the schema of the URL that I couldn't request... 
>
> Basically, nearly all of my current error handling logic assumes I have 
> access to the exception.  Without this, I have almost no hope of 
> translating them to dire. 
>
> -- 
> Craig Brozefsky > 
> Premature reification is the root of all evil 
>

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

Re: Will the JVM will always likely, remain the primary Clojure implementation ?

[Marko Topolnik]

>
> If I would have to move our 15,000 lines code base away from the JVM, I 
> would 

be able to do it in about four months. Most of that time would be spent 
> finding 
> replacements for some Java libs with a little interop remodeling. 
>

You would also have to wait for each and every Clojure library you depend 
on to do the same.

If you had any optimized code relying on primitives/arrays, you'd probably 
be looking at a full rewrite to whatever gives performance on the new 
platform (this takes a lot of time and experience with the platform). The 
same applies to all other libraries. With CLR you may get by easily just 
because it is such a close match to the JVM. With JavaScript, no way.
 

> Like others said, nothings is as still as stone in the software world, 
> otherwise 
> things like Clojure would not even exists, we would still be rolling on 
> square 
> wheels... 
>

 My prediction is, Clojure dies with the JVM. This will not happen any time 
soon and when it does, there will be other exciting languages around, 
sharing much of the spirit with Clojure. If Clojure migrates to another 
platform, it will be an effort strictly by -- and for -- the hard-core (and 
old-school, by then) Clojure afficionados.

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

Re: Will the JVM will always likely, remain the primary Clojure implementation ?

[David Nolen]

On Fri, Dec 28, 2012 at 4:08 PM, Marko Topolnik wrote:

> If you had any optimized code relying on primitives/arrays, you'd probably
> be looking at a full rewrite to whatever gives performance on the new
> platform (this takes a lot of time and experience with the platform). The
> same applies to all other libraries. With CLR you may get by easily just
> because it is such a close match to the JVM. With JavaScript, no way.
>

In my experience the code style that is fast on Clojure JVM is fast for
ClojureScript.

Also I suspect by Clojure/conj 2013 if not sooner you'll see a
bootstrappable ClojureScript for those people who don't need the
concurrency features yet could benefit from a JVM-less Clojure.

David

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

What would you use a #[] data literal for?

[vemv]

I was just wondering - given that we have the #() and #{} literals, why not 
a #[] as well? Queues look like a good fit.

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

Re: seq? empty? and every?

[Peter West]

Thanks for that BG. Makes sense.

-- 
> Baishampayan Ghose 
> b.ghose at gmail.com 
>

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

Re: abysmal multicore performance, especially on AMD processors

[cameron]

Hi Lee,
  I've done some more digging and seem to have found the root of the 
problem, 
it seems that java native methods are much slower when called in parallel.
The following code illustrates the problem: 

(letfn [(time-native [f]  
 (let [c (class [])] 
   (time (dorun (f
 (fn [_] (.isArray c))
 (range 1000))]
  (println "Sequential Test:")
  (time-native map)
  (println "Parallel Test:")
  (time-native pmap))

On a dual quad-core xeon box I get the following results:
  Sequential Test:
   "Elapsed time: 1054.807725 msecs"
  Parallel Test:
   "Elapsed time: 15302.605697 msecs"

ie. the code executed in parallel was 15 times slower than the sequential 
version.
The same can be seen with isInstance and isArray members of java.lang.Class.

I'm not sure where to go from here, these functions are frequently used by 
clojure.core
Perhaps someone with more JVM implementation knowledge can help?

Cameron.

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

Re: abysmal multicore performance, especially on AMD processors

[Leonardo Borges]

In that case isn't context switching dominating your test?

.isArray isn't expensive enough to warrant the use of pmap

Leonardo Borges
www.leonardoborges.com
On Dec 29, 2012 10:29 AM, "cameron"  wrote:

> Hi Lee,
>   I've done some more digging and seem to have found the root of the
> problem,
> it seems that java native methods are much slower when called in parallel.
> The following code illustrates the problem:
>
> (letfn [(time-native [f]
>  (let [c (class [])]
>(time (dorun (f
>  (fn [_] (.isArray c))
>  (range 1000))]
>   (println "Sequential Test:")
>   (time-native map)
>   (println "Parallel Test:")
>   (time-native pmap))
>
> On a dual quad-core xeon box I get the following results:
>   Sequential Test:
>"Elapsed time: 1054.807725 msecs"
>   Parallel Test:
>"Elapsed time: 15302.605697 msecs"
>
> ie. the code executed in parallel was 15 times slower than the sequential
> version.
> The same can be seen with isInstance and isArray members of
> java.lang.Class.
>
> I'm not sure where to go from here, these functions are frequently used by
> clojure.core
> Perhaps someone with more JVM implementation knowledge can help?
>
> Cameron.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

Re: abysmal multicore performance, especially on AMD processors

[cameron]

No, it's not the context switching, changing isArray (a native method) to 
getAnnotations (a normal jvm method) gives the same time for both the 
parallel and serial version.

Cameron.

On Saturday, December 29, 2012 10:34:42 AM UTC+11, Leonardo Borges wrote:
>
> In that case isn't context switching dominating your test? 
>
> .isArray isn't expensive enough to warrant the use of pmap
>
> Leonardo Borges
> www.leonardoborges.com
> On Dec 29, 2012 10:29 AM, "cameron" > 
> wrote:
>
>> Hi Lee,
>>   I've done some more digging and seem to have found the root of the 
>> problem, 
>> it seems that java native methods are much slower when called in parallel.
>> The following code illustrates the problem: 
>>
>> (letfn [(time-native [f]  
>>  (let [c (class [])] 
>>(time (dorun (f
>>  (fn [_] (.isArray c))
>>  (range 1000))]
>>   (println "Sequential Test:")
>>   (time-native map)
>>   (println "Parallel Test:")
>>   (time-native pmap))
>>
>> On a dual quad-core xeon box I get the following results:
>>   Sequential Test:
>>"Elapsed time: 1054.807725 msecs"
>>   Parallel Test:
>>"Elapsed time: 15302.605697 msecs"
>>
>> ie. the code executed in parallel was 15 times slower than the sequential 
>> version.
>> The same can be seen with isInstance and isArray members of 
>> java.lang.Class.
>>
>> I'm not sure where to go from here, these functions are frequently used 
>> by clojure.core
>> Perhaps someone with more JVM implementation knowledge can help?
>>
>> Cameron.
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>
>

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

Clojure Console in a Qt Widget

[Fred Eisele]

Systems have customization languages.
Python seems to be the current darling.
I would like to know how to implement a Qt widget containing the Clojure 
console.
If you could point to an open source project which does this that would be 
sufficient.
The following link shows the type of thing I am looking for as a Python 
console.

http://sourceforge.net/apps/mediawiki/free-cad/index.php?title=Python_scripting_tutorial#Writing_python_code

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

Re: I'm curious if the development of native Clojurescript macros is in progress

[Brandon Bloom]

> So I'm curious if the adoption of native macros into Clojurescript is in 
progress by contributors.

The only visibile progress I know of here is Kanaka's self hosting fork: 
https://github.com/kanaka/clojurescript

If not, is it on the plan at least? Or is it rejected after some discussion?
>

The goal is to get the official ClojureScript compiler self-hosting is 
2013, but there are a lot of stickly little issues and the few active 
contributors are busy people. Help is welcome!

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

Re: Will the JVM will always likely, remain the primary Clojure implementation ?

[Softaddicts]

You are quite wrong in asserting how our software is written.

Most of the clojure libs we refer to are layers around a Java lib.
When I state that we would have to move away from these in four months,
it includes these layers and a replacement for the Java libs.

On top of that we have isolation layers between our core and a few Java
libs. As far as performance critical code, we stay away from this type of 
tuning.
Our business domain allows us to do that plus an early decision to stay
away from Java in our core as much as possible.

As for waiting for these libs to show up by themselves, no way, we would take
things in our hands as soon as such a move would be required.

For any project your mileage may vary but I stated in my post that this depends
on your reliance on interop. If it's everywhere in your code then such a move
requires more work obviously.

Luc P.
> 
> >
> > If I would have to move our 15,000 lines code base away from the JVM, I 
> > would 
> 
> be able to do it in about four months. Most of that time would be spent 
> > finding 
> > replacements for some Java libs with a little interop remodeling. 
> >
> 
> You would also have to wait for each and every Clojure library you depen on 
> to do the same.
> 
> If you had any optimized code relying on primitives/arrays, you'd probably 
> be looking at a full rewrite to whatever gives performance on the new 
> platform (this takes a lot of time and experience with the platform). Th
> same applies to all other libraries. With CLR you may get by easily just 
> because it is such a close match to the JVM. With JavaScript, no way.
>  
> 
> > Like others said, nothings is as still as stone in the software world, 
> > otherwise 
> > things like Clojure would not even exists, we would still be rolling on 
> > square 
> > wheels... 
> >
> 
>  My prediction is, Clojure dies with the JVM. This will not happen any time 
> soon and when it does, there will be other exciting languages around, 
> sharing much of the spirit with Clojure. If Clojure migrates to another 
> platform, it will be an effort strictly by -- and for -- the hard-core (and 
> old-school, by then) Clojure afficionados.
> 
> -- 
> 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
--
Softaddicts sent by ibisMail from my ipad!

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

Re: reduce-kv incompatible with subvec

[Alan Busby]

Just curious why something like the following wouldn't be part of subvector?

public Object kvreduce(IFn f, Object init){
for(int i=0;i<(end - start);i++){
init = f.invoke(init,i,v.nth(start+i));

return init;

}



On Fri, Dec 28, 2012 at 11:23 PM, Andy Fingerhut
wrote:

> I am not saying that one would *have* to give up O(1) subvec in order to
> support other operations.
>
> I am guessing, without having done a thorough analysis, that an O(log n)
> subvec based on RRB Trees would make most/all operations on subvec's just
> fall out fairly naturally, rather than having to be written as special
> cases.
>
> Andy
>
> On Dec 27, 2012, at 8:54 PM, Alan Busby wrote:
>
> I'm confused why we'd need to give up O(1) just to support something like
> reduce-kv on subvectors.
> Isn't the implementation of subvector just a wrapper around the original
> vector along with a start and end value?
>
> Current source here;
>
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/APersistentVector.java
>
> I apologize if I'm missing something key here.
>
>
> On Fri, Dec 28, 2012 at 3:18 AM, Andy Fingerhut 
> wrote:
>
>> http://dev.clojure.org/jira/browse/CLJ-1082
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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

Re: [ANN] Dire, Erlang-style error handling

[Dave Sann]

I see joe's thesis is linked on your github page. is this thesis the paper 
you are referring to?
Do you have a link to the video you refer to?

thanks

Dave


On Saturday, 29 December 2012 06:14:34 UTC+11, Michael Drogalis wrote:
>
> Hey folks,
>
> After watching The Language of the System and being directed to Joe 
> Armstrong's paper on error handling, I concurred that his approach is 
> fantastic. I really wanted the same thing for more rudimentary operations, 
> like file handling. So I wrote Dire 
> https://github.com/MichaelDrogalis/dire
>
> The pros are of this are that error handling code is removed from 
> application logic and it is not order complected.
> The cons are that tasks are not as strongly isolated as they are in 
> Erlang. Also, because it is so simple (16 lines),
> there's no way for a supervisor to "restart" a child task. (Yet, I guess. 
> Ideas?)
>
> Can such a thing be useful in a non-distributed environment? Or does this 
> look like a hassle to use?
>
>
>

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

Re: [ANN] Dire, Erlang-style error handling

[Michael Drogalis]

Indeed, that is the paper - Joe Armstrong's 2003 dissertation "Making 
Reliable Distributed Systems in the Presence of Software Errors".
The video for Rich's The Language of the System: 
http://skillsmatter.com/podcast/scala/the-language-of-the-system

On Friday, December 28, 2012 8:40:28 PM UTC-5, Dave Sann wrote:
>
> I see joe's thesis is linked on your github page. is this thesis the paper 
> you are referring to?
> Do you have a link to the video you refer to?
>
> thanks
>
> Dave
>
>
> On Saturday, 29 December 2012 06:14:34 UTC+11, Michael Drogalis wrote:
>>
>> Hey folks,
>>
>> After watching The Language of the System and being directed to Joe 
>> Armstrong's paper on error handling, I concurred that his approach is 
>> fantastic. I really wanted the same thing for more rudimentary operations, 
>> like file handling. So I wrote Dire 
>> https://github.com/MichaelDrogalis/dire
>>
>> The pros are of this are that error handling code is removed from 
>> application logic and it is not order complected.
>> The cons are that tasks are not as strongly isolated as they are in 
>> Erlang. Also, because it is so simple (16 lines),
>> there's no way for a supervisor to "restart" a child task. (Yet, I guess. 
>> Ideas?)
>>
>> Can such a thing be useful in a non-distributed environment? Or does this 
>> look like a hassle to use?
>>
>>
>>

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

Re: Core.logic performance of looping over a list with tabling

[David Nolen]

http://github.com/clojure/core.logic/commit/ef437d676e72dd9a30e60b31d8ee4a1dccbfdcef

Finally tabled goals are reset upon every run!

The old behavior is no longer supported - I'm not even sure that behavior
was ever the true intent of the original miniKanren tabling design.

Should the old behavior return it will need to come after an overhaul of
the `defrel` related features.


On Fri, Oct 19, 2012 at 11:47 AM, Coen De Roover  wrote:

>
> On 17 Oct 2012, at 19:31, David Nolen  wrote:
>
> On Mon, Oct 8, 2012 at 10:00 AM, Reinout Stevens wrote:
>
>> Another question: is it possible to manually reset the contents of the
>> tables?
>>
>>
>> Thanks a lot
>>
>>
>> Reinout
>>
>
> After some more thinking, I agree that the current behavior is not only
> counter intuitive, but simply awful :)
>
> http://dev.clojure.org/jira/browse/LOGIC-59
>
> I'd like to address this issue before taking 0.8.0 out of beta.
>
> David
>
>
>
> Hi David,
>
> What are your plans about the tables?
> I would side with the title of the issue rather than its description :)
>
> At least for Ekeko, it does not make sense to keep the tables in between
> runs as the Eclipse workspace that is being queried changes continuously.
> The same is probably true for all applications that query an external data
> structure. The downside of volatile tables is that applications with a more
> static "fact base" incur an overhead.
> A compromise might be to provide hooks through which the tables can be
> reset. In general, the ideal solution is probably application-specfic but
> it never hurts to err on the safe side :)
>
> Coen
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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

Re: Clojure Console in a Qt Widget

[Herwig Hochleitner]

I'd try to run a lein repl in a terminal widget.
Maybe http://code.google.com/p/qterminal/ does the trick?


2012/12/28 Fred Eisele 

> Systems have customization languages.
> Python seems to be the current darling.
> I would like to know how to implement a Qt widget containing the Clojure
> console.
> If you could point to an open source project which does this that would be
> sufficient.
> The following link shows the type of thing I am looking for as a Python
> console.
>
>
> http://sourceforge.net/apps/mediawiki/free-cad/index.php?title=Python_scripting_tutorial#Writing_python_code
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

[ANN] lein-resource 0.2.0 hits clojars

[Matthew O. Smith]

https://github.com/m0smith/lein-resource

lein-resource 

A plugin that can be used to copy files from mulitiple source directories 
to a target directory while maintaining the sub-directories. Also, each 
file will be transformed using 
stencil. 
The map that is passed to stencil contains a combination of:

   - The project map
   - The system properties (with .prop added to the name )
   - Additional values (currently only :timestamp)
   - Values set in the project.clj using :resource :extra-values


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