Re: Raw strings

[Mark Engelberg]

On Sun, Mar 17, 2013 at 11:23 PM, Softaddicts
wrote:

>
> I find raw string handling in XML simply ugly :)


Agreed.


>
> Do you have a suggestion on how to represent raw strings ? Something
> concrete
> we could discuss about ?
>
>
In several languages, they use a sequence of three double-quotes to mark
the beginning and the end of the raw string.

In Clojure, I think raw strings would actually enhance the power of the edn
format rather than detract, specifically the tagged elements.

Right now, edn supports things like:
#uuid "f81d4fae-7dec-11d0-a765-00a0c91e6bf6"and
#inst "1985-04-12T23:20:50.52Z"and you can create your own.  The built-ins
happen to not utilize double-quotes or backslashes, so escaping is not a
big deal, but if you want your tagged element to use a syntax where quotes
and backslashes are natural, you're out of luck and you get a big ugly
mess.  Think how much uglier the above inst element would look if - and :
happened to be characters that required escaping.  All I want is the
ability to do something like

*#my/tag """45 \ "a" \ 50"""*

if that's the most natural way to express the element rather than having to
type

*#my/tag "45 \\ \"a\" \\ 50"*

which is already starting to look ugly, and looks far uglier the more
characters are in there that require escaping.

-- 
-- 
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: Raw strings

[Marko Topolnik]

Chas Emerick is also one of those who voiced their 
desireto see 
such a feature in Clojure.

On Monday, March 18, 2013 8:13:58 AM UTC+1, puzzler wrote:
>
> On Sun, Mar 17, 2013 at 11:23 PM, Softaddicts 
> 
> > wrote:
>
>>
>> Do you have a suggestion on how to represent raw strings ? Something 
>> concrete
>> we could discuss about ?
>>
>>
> In several languages, they use a sequence of three double-quotes to mark 
> the beginning and the end of the raw string.  
>
> In Clojure, I think raw strings would actually enhance the power of the 
> edn format rather than detract, specifically the tagged elements.
>
> Right now, edn supports things like:
> #uuid "f81d4fae-7dec-11d0-a765-00a0c91e6bf6"and
> #inst "1985-04-12T23:20:50.52Z"and you can create your own.  The 
> built-ins happen to not utilize double-quotes or backslashes, so escaping 
> is not a big deal, but if you want your tagged element to use a syntax 
> where quotes and backslashes are natural, you're out of luck and you get a 
> big ugly mess.  Think how much uglier the above inst element would look if 
> - and : happened to be characters that required escaping.  All I want is 
> the ability to do something like
>
> *#my/tag """45 \ "a" \ 50"""*
>
> if that's the most natural way to express the element rather than having 
> to type
>
> *#my/tag "45 \\ \"a\" \\ 50"*
>
> which is already starting to look ugly, and looks far uglier the more 
> characters are in there that require escaping.
>
>

-- 
-- 
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: Raw strings

[Softaddicts]

Looks fine to me. If it's an extension to the literal syntax it's also a narrow 
scope change.

The standard escape sequences make things harder even for display purposes.
We would also benefit from this, we are handling huge amounts of raw text
and just for debugging purposes we have to mentally handle the \ escape
character... berk.

Our unit tests also suffer from this escaping mode.

Using a literal syntax like this one would make life easier.

Luc P.

> On Sun, Mar 17, 2013 at 11:23 PM, Softaddicts
> wrote:
> 
> >
> > I find raw string handling in XML simply ugly :)
> 
> 
> Agreed.
> 
> 
> >
> > Do you have a suggestion on how to represent raw strings ? Something
> > concrete
> > we could discuss about ?
> >
> >
> In several languages, they use a sequence of three double-quotes to mark
> the beginning and the end of the raw string.
> 
> In Clojure, I think raw strings would actually enhance the power of the edn
> format rather than detract, specifically the tagged elements.
> 
> Right now, edn supports things like:
> #uuid "f81d4fae-7dec-11d0-a765-00a0c91e6bf6"and
> #inst "1985-04-12T23:20:50.52Z"and you can create your own.  The built-ins
> happen to not utilize double-quotes or backslashes, so escaping is not a
> big deal, but if you want your tagged element to use a syntax where quotes
> and backslashes are natural, you're out of luck and you get a big ugly
> mess.  Think how much uglier the above inst element would look if - and :
> happened to be characters that required escaping.  All I want is the
> ability to do something like
> 
> *#my/tag """45 \ "a" \ 50"""*
> 
> if that's the most natural way to express the element rather than having to
> type
> 
> *#my/tag "45 \\ \"a\" \\ 50"*
> 
> which is already starting to look ugly, and looks far uglier the more
> characters are in there that require escaping.
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 
> 
--
Softaddicts sent by ibisMail from my ipad!

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

Re: Raw strings

[Dave Sann]

I'd welcome the ability to change delimiter. I've found it very useful in 
the past to avoid illegible or hard to read strings.


On Monday, 18 March 2013 19:57:06 UTC+11, Luc wrote:
>
> Looks fine to me. If it's an extension to the literal syntax it's also a 
> narrow scope change. 
>
> The standard escape sequences make things harder even for display 
> purposes. 
> We would also benefit from this, we are handling huge amounts of raw text 
> and just for debugging purposes we have to mentally handle the \ escape 
> character... berk. 
>
> Our unit tests also suffer from this escaping mode. 
>
> Using a literal syntax like this one would make life easier. 
>
> Luc P. 
>
> > On Sun, Mar 17, 2013 at 11:23 PM, Softaddicts 
> > >wrote: 
> > 
> > > 
> > > I find raw string handling in XML simply ugly :) 
> > 
> > 
> > Agreed. 
> > 
> > 
> > > 
> > > Do you have a suggestion on how to represent raw strings ? Something 
> > > concrete 
> > > we could discuss about ? 
> > > 
> > > 
> > In several languages, they use a sequence of three double-quotes to mark 
> > the beginning and the end of the raw string. 
> > 
> > In Clojure, I think raw strings would actually enhance the power of the 
> edn 
> > format rather than detract, specifically the tagged elements. 
> > 
> > Right now, edn supports things like: 
> > #uuid "f81d4fae-7dec-11d0-a765-00a0c91e6bf6"and 
> > #inst "1985-04-12T23:20:50.52Z"and you can create your own.  The 
> built-ins 
> > happen to not utilize double-quotes or backslashes, so escaping is not a 
> > big deal, but if you want your tagged element to use a syntax where 
> quotes 
> > and backslashes are natural, you're out of luck and you get a big ugly 
> > mess.  Think how much uglier the above inst element would look if - and 
> : 
> > happened to be characters that required escaping.  All I want is the 
> > ability to do something like 
> > 
> > *#my/tag """45 \ "a" \ 50"""* 
> > 
> > if that's the most natural way to express the element rather than having 
> to 
> > type 
> > 
> > *#my/tag "45 \\ \"a\" \\ 50"* 
> > 
> > which is already starting to look ugly, and looks far uglier the more 
> > characters are in there that require escaping. 
> > 
> > -- 
> > -- 
> > 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. 
> > 
> > 
> > 
> -- 
> Softaddicts> sent by ibisMail from 
> my ipad! 
>

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

Re: Raw strings

[Maik Schünemann]

http://dev.clojure.org/display/design/Alternate+string+quote+syntaxes


On Mon, Mar 18, 2013 at 11:50 AM, Dave Sann  wrote:

> I'd welcome the ability to change delimiter. I've found it very useful in
> the past to avoid illegible or hard to read strings.
>
>
> On Monday, 18 March 2013 19:57:06 UTC+11, Luc wrote:
>
>> Looks fine to me. If it's an extension to the literal syntax it's also a
>> narrow scope change.
>>
>> The standard escape sequences make things harder even for display
>> purposes.
>> We would also benefit from this, we are handling huge amounts of raw text
>> and just for debugging purposes we have to mentally handle the \ escape
>> character... berk.
>>
>> Our unit tests also suffer from this escaping mode.
>>
>> Using a literal syntax like this one would make life easier.
>>
>> Luc P.
>>
>> > On Sun, Mar 17, 2013 at 11:23 PM, Softaddicts
>> > **wrote:
>> >
>> > >
>> > > I find raw string handling in XML simply ugly :)
>> >
>> >
>> > Agreed.
>> >
>> >
>> > >
>> > > Do you have a suggestion on how to represent raw strings ? Something
>> > > concrete
>> > > we could discuss about ?
>> > >
>> > >
>> > In several languages, they use a sequence of three double-quotes to
>> mark
>> > the beginning and the end of the raw string.
>> >
>> > In Clojure, I think raw strings would actually enhance the power of the
>> edn
>> > format rather than detract, specifically the tagged elements.
>> >
>> > Right now, edn supports things like:
>> > #uuid "f81d4fae-7dec-11d0-a765-**00a0c91e6bf6"and
>> > #inst "1985-04-12T23:20:50.52Z"and you can create your own.  The
>> built-ins
>> > happen to not utilize double-quotes or backslashes, so escaping is not
>> a
>> > big deal, but if you want your tagged element to use a syntax where
>> quotes
>> > and backslashes are natural, you're out of luck and you get a big ugly
>> > mess.  Think how much uglier the above inst element would look if - and
>> :
>> > happened to be characters that required escaping.  All I want is the
>> > ability to do something like
>> >
>> > *#my/tag """45 \ "a" \ 50"""*
>> >
>> > if that's the most natural way to express the element rather than
>> having to
>> > type
>> >
>> > *#my/tag "45 \\ \"a\" \\ 50"*
>> >
>> > which is already starting to look ugly, and looks far uglier the more
>> > characters are in there that require escaping.
>> >
>> > --
>> > --
>> > 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.
>>
>> >
>> >
>> >
>> --
>> Softaddicts sent by ibisMail from my ipad!
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
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: Raw strings

[vemv]

>
> Nobody wants to store every regexp in a separate file.
>

That's because regexes are 'atomic' - you don't place Clojure expressions 
in the middle of them. SQL or math are vastly different from that. As for 
SQL, it *is* common practice to store them as isolatedly as possible.

I have not questioned the validity of notations other than Clojure's. What 
I do consider mistaken though, is the concrete strategy of extending 
Clojure's reader.

Some DSLs are based on a really handy notation that has been in use by 
> computer scientists and/or mathematicians for decades or longer. Trying to 
> shoe-horn these convenient notations into something that looks like Clojure 
> is not always the right way to go.
>

In fact your proposal is closer to "shoehorning" than mine :) by separating 
languages you can use arbitrary syntaxes for each, without risk of 
interfering. For example, one can list named physics/math functions using 
their "DSLs" (including funny Unicodes etc), and generate first-class 
callable code from that (no strings!). Like:

*File - example.math:
*
add (x, y):
x + y

*Compile util.math to Clojure and that to bytecode, ahead-of-time or 
on-the-fly.
*
*File - consumer.clj:
*
(require 'example)
(example/add 3 2)

Assuming the math/physics functions were substantial enough, I think 
developing a tiny compiler like that would be worth the effort.

-- 
-- 
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: Raw strings

[Marko Topolnik]

On Monday, March 18, 2013 12:35:31 PM UTC+1, vemv wrote:

> Nobody wants to store every regexp in a separate file.
>>
> 
> That's because regexes are 'atomic' - you don't place Clojure expressions 
> in the middle of them. SQL or math are vastly different from that. As for 
> SQL, it *is* common practice to store them as isolatedly as possible.
>

Dynamic regex building is a standard technique. Unfortunately, once you 
leave the regex literal world, you are back to escaping everything.

I also have tons of SQL (HQL, actually but same thing) inline with my 
Clojure. It is an approach that never backfired on me. I also have much 
need for dynamic SQL generation. I don't consider myself special because of 
that.

-marko

-- 
-- 
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: Raw strings

[vemv]

   
   - doc strings with examples could be more human readable

(defn ^{:examples '[(with-out-str (clipboard (doc distinct)))]
clipboard [x] ...)

Just if a mechanism like this were used more widely... we'd get syntax 
coloring for free, and a facility for programatically querying examples.

   - 
   
   XML, JSON or SQL generation tests become filled with escaped quotes
   
Again, one can either keep reference to files in the tests, or develop e.g. 
a XML-testing DSL.

Even if they were cases were there wasn't a clear alternative to the idea 
of raw strings, if such a feature were added, it could be used gratuitously.
For the same reason Clojure offers e.g. limited inheritance possibilities. 
I prefer having to eventually resort to Java to write "advanced" classes, 
than to use a language which users have it easy to build implementation 
hierarchies.

On Monday, March 18, 2013 12:25:07 PM UTC+1, Maik Schünemann wrote:
>
> http://dev.clojure.org/display/design/Alternate+string+quote+syntaxes
>
>
> On Mon, Mar 18, 2013 at 11:50 AM, Dave Sann 
> > wrote:
>
>> I'd welcome the ability to change delimiter. I've found it very useful in 
>> the past to avoid illegible or hard to read strings.
>>
>>
>> On Monday, 18 March 2013 19:57:06 UTC+11, Luc wrote:
>>
>>> Looks fine to me. If it's an extension to the literal syntax it's also a 
>>> narrow scope change. 
>>>
>>> The standard escape sequences make things harder even for display 
>>> purposes. 
>>> We would also benefit from this, we are handling huge amounts of raw 
>>> text 
>>> and just for debugging purposes we have to mentally handle the \ escape 
>>> character... berk. 
>>>
>>> Our unit tests also suffer from this escaping mode. 
>>>
>>> Using a literal syntax like this one would make life easier. 
>>>
>>> Luc P. 
>>>
>>> > On Sun, Mar 17, 2013 at 11:23 PM, Softaddicts 
>>> > **wrote: 
>>> > 
>>> > > 
>>> > > I find raw string handling in XML simply ugly :) 
>>> > 
>>> > 
>>> > Agreed. 
>>> > 
>>> > 
>>> > > 
>>> > > Do you have a suggestion on how to represent raw strings ? Something 
>>> > > concrete 
>>> > > we could discuss about ? 
>>> > > 
>>> > > 
>>> > In several languages, they use a sequence of three double-quotes to 
>>> mark 
>>> > the beginning and the end of the raw string. 
>>> > 
>>> > In Clojure, I think raw strings would actually enhance the power of 
>>> the edn 
>>> > format rather than detract, specifically the tagged elements. 
>>> > 
>>> > Right now, edn supports things like: 
>>> > #uuid "f81d4fae-7dec-11d0-a765-**00a0c91e6bf6"and 
>>> > #inst "1985-04-12T23:20:50.52Z"and you can create your own.  The 
>>> built-ins 
>>> > happen to not utilize double-quotes or backslashes, so escaping is not 
>>> a 
>>> > big deal, but if you want your tagged element to use a syntax where 
>>> quotes 
>>> > and backslashes are natural, you're out of luck and you get a big ugly 
>>> > mess.  Think how much uglier the above inst element would look if - 
>>> and : 
>>> > happened to be characters that required escaping.  All I want is the 
>>> > ability to do something like 
>>> > 
>>> > *#my/tag """45 \ "a" \ 50"""* 
>>> > 
>>> > if that's the most natural way to express the element rather than 
>>> having to 
>>> > type 
>>> > 
>>> > *#my/tag "45 \\ \"a\" \\ 50"* 
>>> > 
>>> > which is already starting to look ugly, and looks far uglier the more 
>>> > characters are in there that require escaping. 
>>> > 
>>> > -- 
>>> > -- 
>>> > 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.
>>> >  
>>>
>>> > 
>>> > 
>>> > 
>>> -- 
>>> 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 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 fr

Re: Raw strings

[vemv]

I wasn't familiar with dynamic regex building. Sounds like a task that 
would be best performed separately from normal Clojure reading/evaluation 
(i.e. using a different file).

I don't think dynamic SQL construction would benefit from raw strings. 
String interpolation is a different story.

On Monday, March 18, 2013 12:50:13 PM UTC+1, Marko Topolnik wrote:
>
> On Monday, March 18, 2013 12:35:31 PM UTC+1, vemv wrote:
>
>> Nobody wants to store every regexp in a separate file.
>>>
>> 
>> That's because regexes are 'atomic' - you don't place Clojure expressions 
>> in the middle of them. SQL or math are vastly different from that. As for 
>> SQL, it *is* common practice to store them as isolatedly as possible.
>>
>
> Dynamic regex building is a standard technique. Unfortunately, once you 
> leave the regex literal world, you are back to escaping everything.
>
> I also have tons of SQL (HQL, actually but same thing) inline with my 
> Clojure. It is an approach that never backfired on me. I also have much 
> need for dynamic SQL generation. I don't consider myself special because of 
> that.
>
> -marko
>

-- 
-- 
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: Google Summer of Code 2013

[Laurent PETIT]

I just added a proposal for a "Refactoring feature for CCW & other IDEs" :

http://dev.clojure.org/display/community/Project+Ideas#ProjectIdeas-RefactoringfeatureforCCWotherIDEs

Victor showed interest into this.

Hope it's not too late.

I must admit that this would be a prime time for me, and I'm a little bit
scared by the amount of time that is required from mentors in average.

If people having already played the "mentoring" role can shed some light on
this, please, "from the trenches", so that I can double-check that I'm not
doing all this too lightly ?


Cheers,

-- 
Laurent Petit

2013/3/16 Daniel Solano Gómez 

> On Sat Mar 16 19:57 2013, Víctor M. Valenzuela wrote:
> > Hello Daniel,
> >
> > my bad, the application period indeed starts on Monday. Sorry for the
> noise.
> >
> > Can I propose (complete) ideas if I've not found a mentor for them yet?
>
> Certainly.  Your best bet is to bring up your project ideas on the
> relevant mailing lists.  This will be a great way to get feedback from
> the community and find potential mentors.
>
> Sincerely,
>
> Daniel
>
> >
> > Thank you - Vicotor
> >
> > On Sat, Mar 16, 2013 at 7:46 PM, Daniel Solano Gómez <
> cloj...@sattvik.com>wrote:
> >
> > > Hello, Victor,
> > >
> > > I think the application period started on Monday.  Nonetheless, I am
> > > planning on starting the application as soon as it opens.  I'll do what
> > > David did last year and post the application questions on the Clojure
> > > community wiki.
> > >
> > > I am planning on officially kicking off Clojure's GSoC effort at
> > > Clojure/West on Monday with a lightning talk and an unsession.
> > >
> > > Sincerely,
> > >
> > > Daniel
> > >
> > > On Sat Mar 16 09:14 2013, vemv wrote:
> > > > Daniel,
> > > >
> > > > Starting from today and until March 29 organisations can send their
> > > > applications. Which date will you pick?
> > > >
> > > > Thanks,
> > > >
> > > > Victor
> > > >
> > > > On Thursday, February 14, 2013 7:03:58 PM UTC+1, Daniel Solano Gómez
> > > wrote:
> > > > >
> > > > > Hello, all,
> > > > >
> > > > > It's official:  Google Summer of Code 2013 is on.
> > > > >
> > > > > Last year, Clojure was able to get four students who worked on
> projects
> > > > > like Typed Clojure, Clojure on Android, Clojure and Lua, and
> Overtone,
> > > and
> > > > > I'd love to see Clojure be a mentoring organisation again this
> year.
> > > > >
> > > > > I have created a GSoC 2013 page on the Clojure community wiki <
> > > > >
> http://dev.clojure.org/display/community/Google+Summer+of+Code+2013>.
> > > > >  Here you will be able to find the latest information about what's
> > > going on
> > > > > with Clojure's GSoC 2013 effort and how to get involved.
> > > > >
> > > > > Here's some ways you can help:
> > > > >
> > > > > * Let people in your local user groups or university know about
> Clojure
> > > > > and GSoC.
> > > > > * If you're going to Clojure/West, attend the GSoC unsession.
> > > > >
> > > > > For students
> > > > >
> > > > > * Start researching project ideas and get involved with the
> relevant
> > > > > communities to find mentors.
> > > > >
> > > > > For developers:
> > > > >
> > > > > Does your open source project have a backlog of features to
> implement?
> > > > >  GSoC is a great way to draw new contributors to your project.
> > > > >
> > > > > * Post it to the project idea page and become a mentor.
> > > > > * Let people know about GSoC on your project mailing list.
> > > > >
> > > > > I'd like to thank everyone in advance for helping with our GSoC
> 2013
> > > > > project.
> > > > >
> > > > > Sincerely,
> > > > >
> > > > > Daniel
> > > > >
> > > >
> > > > --
> > > > --
> > > > 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 beca

what are some stack sizes that people use?

[larry google groups]

I am a noob when it comes to the JVM, and actually I find the JVM to be the 
hardest thing to learn about Clojure. 

Problem: I was trying to serialize some data to YAML. I had this working 
for awhile, but then I added more data and I started getting StackOverflow 
as an error. I then decided to just take a subset of my data, but even the 
subset will some day grow too large. I did some searches on Google and 
apparently I need to increase the stack size of my JVM. However, I have no 
idea what values are considered large or too-large. 

I have a project built with Leiningen. I have been reading up on jvm 
options, and so far, in my project.clj file, I have: 

  :jvm-opts ["-Xms256m" "-Xmx1000m" "-XX:-UseCompressedOops"])

The stack size option is "-ss"? A large value would be... uh, what? 2000? 
5000? 1? Should I do: 

  :jvm-opts ["-Xms256m" "-Xmx1000m" "-XX:-UseCompressedOops" "-ss: 5000"])

?




-- 
-- 
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: Google Summer of Code 2013

[Daniel Solano Gómez]

Hello, Laurent,

On Mon Mar 18 13:38 2013, Laurent PETIT wrote:
> I just added a proposal for a "Refactoring feature for CCW & other IDEs" :
> 
> http://dev.clojure.org/display/community/Project+Ideas#ProjectIdeas-RefactoringfeatureforCCWotherIDEs

Thank you!


> Victor showed interest into this.
> 
> Hope it's not too late.

No, not at all.  The organization application period just opened, so
this is the time to fill up the project ideas page.


> I must admit that this would be a prime time for me, and I'm a little bit
> scared by the amount of time that is required from mentors in average.
> 
> If people having already played the "mentoring" role can shed some light on
> this, please, "from the trenches", so that I can double-check that I'm not
> doing all this too lightly ?

I have placed a few pointers to resources for mentors on the wiki
.
Google says that mentoring should take on average about five hours per
week.

In the end, as a mentor, your job is to help guide the student and
review the student's work.  You should not be micromanaging the student
or doing a lot of hand-holding.  This is why it is important to interact
with student applicants before they are selected.  You want to be sure
that the student is sufficiently prepared and self-driven to be able to
complete the project successfully.

I hope this helps.

Sincerely,

Daniel

> 
> 
> Cheers,
> 
> -- 
> Laurent Petit
> 
> 2013/3/16 Daniel Solano Gómez 
> 
> > On Sat Mar 16 19:57 2013, Víctor M. Valenzuela wrote:
> > > Hello Daniel,
> > >
> > > my bad, the application period indeed starts on Monday. Sorry for the
> > noise.
> > >
> > > Can I propose (complete) ideas if I've not found a mentor for them yet?
> >
> > Certainly.  Your best bet is to bring up your project ideas on the
> > relevant mailing lists.  This will be a great way to get feedback from
> > the community and find potential mentors.
> >
> > Sincerely,
> >
> > Daniel
> >
> > >
> > > Thank you - Vicotor
> > >
> > > On Sat, Mar 16, 2013 at 7:46 PM, Daniel Solano Gómez <
> > cloj...@sattvik.com>wrote:
> > >
> > > > Hello, Victor,
> > > >
> > > > I think the application period started on Monday.  Nonetheless, I am
> > > > planning on starting the application as soon as it opens.  I'll do what
> > > > David did last year and post the application questions on the Clojure
> > > > community wiki.
> > > >
> > > > I am planning on officially kicking off Clojure's GSoC effort at
> > > > Clojure/West on Monday with a lightning talk and an unsession.
> > > >
> > > > Sincerely,
> > > >
> > > > Daniel
> > > >
> > > > On Sat Mar 16 09:14 2013, vemv wrote:
> > > > > Daniel,
> > > > >
> > > > > Starting from today and until March 29 organisations can send their
> > > > > applications. Which date will you pick?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Victor
> > > > >
> > > > > On Thursday, February 14, 2013 7:03:58 PM UTC+1, Daniel Solano Gómez
> > > > wrote:
> > > > > >
> > > > > > Hello, all,
> > > > > >
> > > > > > It's official:  Google Summer of Code 2013 is on.
> > > > > >
> > > > > > Last year, Clojure was able to get four students who worked on
> > projects
> > > > > > like Typed Clojure, Clojure on Android, Clojure and Lua, and
> > Overtone,
> > > > and
> > > > > > I'd love to see Clojure be a mentoring organisation again this
> > year.
> > > > > >
> > > > > > I have created a GSoC 2013 page on the Clojure community wiki <
> > > > > >
> > http://dev.clojure.org/display/community/Google+Summer+of+Code+2013>.
> > > > > >  Here you will be able to find the latest information about what's
> > > > going on
> > > > > > with Clojure's GSoC 2013 effort and how to get involved.
> > > > > >
> > > > > > Here's some ways you can help:
> > > > > >
> > > > > > * Let people in your local user groups or university know about
> > Clojure
> > > > > > and GSoC.
> > > > > > * If you're going to Clojure/West, attend the GSoC unsession.
> > > > > >
> > > > > > For students
> > > > > >
> > > > > > * Start researching project ideas and get involved with the
> > relevant
> > > > > > communities to find mentors.
> > > > > >
> > > > > > For developers:
> > > > > >
> > > > > > Does your open source project have a backlog of features to
> > implement?
> > > > > >  GSoC is a great way to draw new contributors to your project.
> > > > > >
> > > > > > * Post it to the project idea page and become a mentor.
> > > > > > * Let people know about GSoC on your project mailing list.
> > > > > >
> > > > > > I'd like to thank everyone in advance for helping with our GSoC
> > 2013
> > > > > > project.
> > > > > >
> > > > > > Sincerely,
> > > > > >
> > > > > > Daniel
> > > > > >
> > > > >
> > > > > --
> > > > > --
> > > > > 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 f

Re: what are some stack sizes that people use?

[Niels van Klaveren]

Default stack size is 512kB for 32bit JVMs on Solaris, 320kB for 32bit JVMs 
on Linux (and Windows), and 1024kB for 64bit JVMs.

However, stack overflows are usually a good indication of problematic / 
faulty recursive algorithms. Increasing the stacksize usually only 
alleviates some symptoms for a bit. Increasing the stacksize is something 
that only rarely needs to be done, usually when relying on an external 
library that has problems with stacksize. Always try to troubleshoot code 
you can alter first.

On Monday, March 18, 2013 4:15:00 PM UTC+1, larry google groups wrote:
>
>
> I am a noob when it comes to the JVM, and actually I find the JVM to be 
> the hardest thing to learn about Clojure. 
>
> Problem: I was trying to serialize some data to YAML. I had this working 
> for awhile, but then I added more data and I started getting StackOverflow 
> as an error. I then decided to just take a subset of my data, but even the 
> subset will some day grow too large. I did some searches on Google and 
> apparently I need to increase the stack size of my JVM. However, I have no 
> idea what values are considered large or too-large. 
>
> I have a project built with Leiningen. I have been reading up on jvm 
> options, and so far, in my project.clj file, I have: 
>
>   :jvm-opts ["-Xms256m" "-Xmx1000m" "-XX:-UseCompressedOops"])
>
> The stack size option is "-ss"? A large value would be... uh, what? 2000? 
> 5000? 1? Should I do: 
>
>   :jvm-opts ["-Xms256m" "-Xmx1000m" "-XX:-UseCompressedOops" "-ss: 5000"])
>
> ?
>
>
>
>
>

-- 
-- 
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: what are some stack sizes that people use?

[Niels van Klaveren]

Another Caveat is that stack size is allocated per thread. If you use a 
highly threaded application (f.i. webservers) a small stacksize increase 
can add up quite a bit.

On Monday, March 18, 2013 4:15:00 PM UTC+1, larry google groups wrote:
>
>
> I am a noob when it comes to the JVM, and actually I find the JVM to be 
> the hardest thing to learn about Clojure. 
>
> Problem: I was trying to serialize some data to YAML. I had this working 
> for awhile, but then I added more data and I started getting StackOverflow 
> as an error. I then decided to just take a subset of my data, but even the 
> subset will some day grow too large. I did some searches on Google and 
> apparently I need to increase the stack size of my JVM. However, I have no 
> idea what values are considered large or too-large. 
>
> I have a project built with Leiningen. I have been reading up on jvm 
> options, and so far, in my project.clj file, I have: 
>
>   :jvm-opts ["-Xms256m" "-Xmx1000m" "-XX:-UseCompressedOops"])
>
> The stack size option is "-ss"? A large value would be... uh, what? 2000? 
> 5000? 1? Should I do: 
>
>   :jvm-opts ["-Xms256m" "-Xmx1000m" "-XX:-UseCompressedOops" "-ss: 5000"])
>
> ?
>
>
>
>
>

-- 
-- 
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: Google Summer of Code 2013

[Laurent PETIT]

2013/3/18 Daniel Solano Gómez 

> Hello, Laurent,
>
> On Mon Mar 18 13:38 2013, Laurent PETIT wrote:
> > I just added a proposal for a "Refactoring feature for CCW & other IDEs"
> :
> >
> >
> http://dev.clojure.org/display/community/Project+Ideas#ProjectIdeas-RefactoringfeatureforCCWotherIDEs
>
> Thank you!
>
>
> > Victor showed interest into this.
> >
> > Hope it's not too late.
>
> No, not at all.  The organization application period just opened, so
> this is the time to fill up the project ideas page.
>
>
> > I must admit that this would be a prime time for me, and I'm a little bit
> > scared by the amount of time that is required from mentors in average.
> >
> > If people having already played the "mentoring" role can shed some light
> on
> > this, please, "from the trenches", so that I can double-check that I'm
> not
> > doing all this too lightly ?
>
> I have placed a few pointers to resources for mentors on the wiki
> <
> http://dev.clojure.org/display/community/Google+Summer+of+Code+2013#GoogleSummerofCode2013-Mentors
> >.
> Google says that mentoring should take on average about five hours per
> week.
>

Yeah, this means a lot to me. 5 hours is more than half the time I'm
currently dedicating to CCW in average, so it may be a big deal, I'll have
to think about it.

But as you said, it depends on the student also, and the preparation can be
done before things start, maybe at a slower pace.

Hummm ... hammock time  :-)


>
> In the end, as a mentor, your job is to help guide the student and
> review the student's work.  You should not be micromanaging the student
> or doing a lot of hand-holding.  This is why it is important to interact
> with student applicants before they are selected.  You want to be sure
> that the student is sufficiently prepared and self-driven to be able to
> complete the project successfully.
>
> I hope this helps.
>
> Sincerely,
>
> Daniel
>
> >
> >
> > Cheers,
> >
> > --
> > Laurent Petit
> >
> > 2013/3/16 Daniel Solano Gómez 
> >
> > > On Sat Mar 16 19:57 2013, Víctor M. Valenzuela wrote:
> > > > Hello Daniel,
> > > >
> > > > my bad, the application period indeed starts on Monday. Sorry for the
> > > noise.
> > > >
> > > > Can I propose (complete) ideas if I've not found a mentor for them
> yet?
> > >
> > > Certainly.  Your best bet is to bring up your project ideas on the
> > > relevant mailing lists.  This will be a great way to get feedback from
> > > the community and find potential mentors.
> > >
> > > Sincerely,
> > >
> > > Daniel
> > >
> > > >
> > > > Thank you - Vicotor
> > > >
> > > > On Sat, Mar 16, 2013 at 7:46 PM, Daniel Solano Gómez <
> > > cloj...@sattvik.com>wrote:
> > > >
> > > > > Hello, Victor,
> > > > >
> > > > > I think the application period started on Monday.  Nonetheless, I
> am
> > > > > planning on starting the application as soon as it opens.  I'll do
> what
> > > > > David did last year and post the application questions on the
> Clojure
> > > > > community wiki.
> > > > >
> > > > > I am planning on officially kicking off Clojure's GSoC effort at
> > > > > Clojure/West on Monday with a lightning talk and an unsession.
> > > > >
> > > > > Sincerely,
> > > > >
> > > > > Daniel
> > > > >
> > > > > On Sat Mar 16 09:14 2013, vemv wrote:
> > > > > > Daniel,
> > > > > >
> > > > > > Starting from today and until March 29 organisations can send
> their
> > > > > > applications. Which date will you pick?
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Victor
> > > > > >
> > > > > > On Thursday, February 14, 2013 7:03:58 PM UTC+1, Daniel Solano
> Gómez
> > > > > wrote:
> > > > > > >
> > > > > > > Hello, all,
> > > > > > >
> > > > > > > It's official:  Google Summer of Code 2013 is on.
> > > > > > >
> > > > > > > Last year, Clojure was able to get four students who worked on
> > > projects
> > > > > > > like Typed Clojure, Clojure on Android, Clojure and Lua, and
> > > Overtone,
> > > > > and
> > > > > > > I'd love to see Clojure be a mentoring organisation again this
> > > year.
> > > > > > >
> > > > > > > I have created a GSoC 2013 page on the Clojure community wiki <
> > > > > > >
> > > http://dev.clojure.org/display/community/Google+Summer+of+Code+2013>.
> > > > > > >  Here you will be able to find the latest information about
> what's
> > > > > going on
> > > > > > > with Clojure's GSoC 2013 effort and how to get involved.
> > > > > > >
> > > > > > > Here's some ways you can help:
> > > > > > >
> > > > > > > * Let people in your local user groups or university know about
> > > Clojure
> > > > > > > and GSoC.
> > > > > > > * If you're going to Clojure/West, attend the GSoC unsession.
> > > > > > >
> > > > > > > For students
> > > > > > >
> > > > > > > * Start researching project ideas and get involved with the
> > > relevant
> > > > > > > communities to find mentors.
> > > > > > >
> > > > > > > For developers:
> > > > > > >
> > > > > > > Does your open source project have a backlog of features to
> > > implement?
> > > > > > >  GSoC is a gre

Midje 1.5 released

[Brian Marick]

Midje is a test framework for Clojure that aims to be more readable than 
clojure.test and to allow styles of testing that clojure.test does not.

1.5 is the Enterprise Edition and Respect the Repl Release.

Enterprise (integration with build servers)
* Configuration files 
* Tests can be selected using their metadata
* Plugin interface for customizing reporting

Respect the Repl: 
* Although `lein midje` still works, the emphasis for non-batch 
  use is on a set of repl tools. For example, you can autotest
  inside the repl, which is surprisingly better than running it at
  the command line. (You get both automatic rechecking of tests 
  whose dependencies change and all the convenience of the repl 
  prompt.)
* There's a lot of in-repl documentation. For example, 
  `(doc midje-repl)` brings up a list of the names, brief 
  summaries, and common uses of all the repl tools.
* Reporting of user errors is improved. (Some errors that 
  previously produced confusing "I blew up" messages from Clojure 
  now have their own checks that yield less confusing messages.)

The user guide has been largely rewritten. 

https://github.com/marick/Midje

User guide, including two tutorials (one specifically for clojure.test users): 
https://github.com/marick/Midje/wiki

Change list: https://github.com/marick/Midje/wiki/What%27s-new-in-midje-1.5


Looking for employment as a Clojure programmer
Latest book: /Functional Programming for the Object-Oriented Programmer/
https://leanpub.com/fp-oo

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

[larry google groups]

> However, stack overflows are usually a good indication of problematic / 
faulty 
> recursive algorithms. Increasing the stacksize usually only alleviates 
some symptoms for 
> a bit. Increasing the stacksize is something that only rarely needs to be 
done, usually 
> when relying on an external library that has problems with stacksize. 
Always try 
> to troubleshoot code you can alter first.


I appreciate that. Nothing change in my code except the amount of data in 
the var that was being given to clj-yaml. Possibly clj-yaml recurses too 
much. 





On Monday, March 18, 2013 1:05:00 PM UTC-4, Niels van Klaveren wrote:
>
> Default stack size is 512kB for 32bit JVMs on Solaris, 320kB for 32bit 
> JVMs on Linux (and Windows), and 1024kB for 64bit JVMs.
>
> However, stack overflows are usually a good indication of problematic / 
> faulty recursive algorithms. Increasing the stacksize usually only 
> alleviates some symptoms for a bit. Increasing the stacksize is something 
> that only rarely needs to be done, usually when relying on an external 
> library that has problems with stacksize. Always try to troubleshoot code 
> you can alter first.
>
> On Monday, March 18, 2013 4:15:00 PM UTC+1, larry google groups wrote:
>>
>>
>> I am a noob when it comes to the JVM, and actually I find the JVM to be 
>> the hardest thing to learn about Clojure. 
>>
>> Problem: I was trying to serialize some data to YAML. I had this working 
>> for awhile, but then I added more data and I started getting StackOverflow 
>> as an error. I then decided to just take a subset of my data, but even the 
>> subset will some day grow too large. I did some searches on Google and 
>> apparently I need to increase the stack size of my JVM. However, I have no 
>> idea what values are considered large or too-large. 
>>
>> I have a project built with Leiningen. I have been reading up on jvm 
>> options, and so far, in my project.clj file, I have: 
>>
>>   :jvm-opts ["-Xms256m" "-Xmx1000m" "-XX:-UseCompressedOops"])
>>
>> The stack size option is "-ss"? A large value would be... uh, what? 2000? 
>> 5000? 1? Should I do: 
>>
>>   :jvm-opts ["-Xms256m" "-Xmx1000m" "-XX:-UseCompressedOops" "-ss: 5000"])
>>
>> ?
>>
>>
>>
>>
>>

-- 
-- 
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: what are some stack sizes that people use?

[larry google groups]

> Default stack size is 512kB for 32bit JVMs on Solaris, 320kB for 32bit 
JVMs on 
> Linux (and Windows), and 1024kB for 64bit JVMs.

Thank you for that. So I guess I could double those numbers and see if that 
helps? -ss: 2048kb ?






On Monday, March 18, 2013 3:02:22 PM UTC-4, larry google groups wrote:
>
> > However, stack overflows are usually a good indication of problematic / 
> faulty 
> > recursive algorithms. Increasing the stacksize usually only alleviates 
> some symptoms for 
> > a bit. Increasing the stacksize is something that only rarely needs to 
> be done, usually 
> > when relying on an external library that has problems with stacksize. 
> Always try 
> > to troubleshoot code you can alter first.
>
>
> I appreciate that. Nothing change in my code except the amount of data in 
> the var that was being given to clj-yaml. Possibly clj-yaml recurses too 
> much. 
>
>
>
>
>
> On Monday, March 18, 2013 1:05:00 PM UTC-4, Niels van Klaveren wrote:
>>
>> Default stack size is 512kB for 32bit JVMs on Solaris, 320kB for 32bit 
>> JVMs on Linux (and Windows), and 1024kB for 64bit JVMs.
>>
>> However, stack overflows are usually a good indication of problematic / 
>> faulty recursive algorithms. Increasing the stacksize usually only 
>> alleviates some symptoms for a bit. Increasing the stacksize is something 
>> that only rarely needs to be done, usually when relying on an external 
>> library that has problems with stacksize. Always try to troubleshoot code 
>> you can alter first.
>>
>> On Monday, March 18, 2013 4:15:00 PM UTC+1, larry google groups wrote:
>>>
>>>
>>> I am a noob when it comes to the JVM, and actually I find the JVM to be 
>>> the hardest thing to learn about Clojure. 
>>>
>>> Problem: I was trying to serialize some data to YAML. I had this working 
>>> for awhile, but then I added more data and I started getting StackOverflow 
>>> as an error. I then decided to just take a subset of my data, but even the 
>>> subset will some day grow too large. I did some searches on Google and 
>>> apparently I need to increase the stack size of my JVM. However, I have no 
>>> idea what values are considered large or too-large. 
>>>
>>> I have a project built with Leiningen. I have been reading up on jvm 
>>> options, and so far, in my project.clj file, I have: 
>>>
>>>   :jvm-opts ["-Xms256m" "-Xmx1000m" "-XX:-UseCompressedOops"])
>>>
>>> The stack size option is "-ss"? A large value would be... uh, what? 
>>> 2000? 5000? 1? Should I do: 
>>>
>>>   :jvm-opts ["-Xms256m" "-Xmx1000m" "-XX:-UseCompressedOops" "-ss: 
>>> 5000"])
>>>
>>> ?
>>>
>>>
>>>
>>>
>>>

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

contrib.monads doesn't compile?

[Jim - FooBar();]

HI everyone,

I just hit this and I thought I'd share... 2 min ago I specified 
clojure-contrib 1.2.0 as a dependency only to use 2 functions from the 
probabilities namespace. However that namepsace depends on the 
contrib.monads namespace which immediately throw this compiler error :


CompilerException java.lang.IllegalStateException: Can't dynamically 
bind non-dynamic var: clojure.contrib.macro-utils/protected-symbols, 
compiling:(clojure/contrib/monads.clj:195:1)


it's no biggie for me as I can copy paste the 2 3-line functions I want 
but still it strikes me as weird and I thought you should know...


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: Raw strings

[Stefan Kamphausen]

Hi,

On Monday, March 18, 2013 12:50:13 PM UTC+1, Marko Topolnik wrote:
>
> Dynamic regex building is a standard technique. Unfortunately, once you 
> leave the regex literal world, you are back to escaping everything.


this works pretty well, at least better than I expected, e.g.:

 user=> (def r1 #"(\s.)")
#'user/r1
user=> (def r2 #"([abc])")
#'user/r2
user=> (def r3 (re-pattern (str r1 "|" r2)))
#'user/r3
user=> r3
#"(\s.)|([abc])"
user=> (re-find r3 " x")
[" x" " x" nil]
user=> (re-find r3 "b")
["b" nil "b"]


Regards,
Stefan

-- 
-- 
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: Understanding vars

[Marko Topolnik]

On Monday, March 18, 2013 7:16:17 PM UTC+1, puzzler wrote:

>
> It used to be that a common way to refactor this for best performance 
> would be:
>
> (let [pi (compute-estimate-of-pi)]
>   (defn f [x]
>   ; Do stuff with pi here
> ))
>
 
This is just about the same as

(def ^:const pi (compute-estimate-of-pi))

(defn f [x] ...)

Otherwise, for a regular static var you pay AtomicBoolean.get + volatile 
read of the actual value. For a dynamic var you pay much more 
(ThreadLocal.get() + hashmap lookup).

-marko

-- 
-- 
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: Raw strings

[Stefan Kamphausen]

On Monday, March 18, 2013 12:25:07 PM UTC+1, Maik Schünemann wrote:
>
> http://dev.clojure.org/display/design/Alternate+string+quote+syntaxes
>
>
It would have been nice to still have #" available for this and #// for 
regexes.  That's probably my Perl heritage leaking through, 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.

Re: contrib.monads doesn't compile?

[Andy Fingerhut]

clojure-contrib 1.2.0 probably still compiles reasonably well with Clojure
1.2.0, but since Clojure 1.3.0 support for the older contrib libraries has
been gradually waning.

http://dev.clojure.org/display/design/Where+Did+Clojure.Contrib+Go

Andy

On Mon, Mar 18, 2013 at 12:32 PM, Jim - FooBar(); wrote:

> HI everyone,
>
> I just hit this and I thought I'd share... 2 min ago I specified
> clojure-contrib 1.2.0 as a dependency only to use 2 functions from the
> probabilities namespace. However that namepsace depends on the
> contrib.monads namespace which immediately throw this compiler error :
>
> CompilerException java.lang.**IllegalStateException: Can't dynamically
> bind non-dynamic var: clojure.contrib.macro-utils/**protected-symbols,
> compiling:(clojure/contrib/**monads.clj:195:1)
>
> it's no biggie for me as I can copy paste the 2 3-line functions I want
> but still it strikes me as weird and I thought you should know...
>
> 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+unsubscribe@**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+unsubscribe@**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: Raw strings

[Marko Topolnik]

On Monday, March 18, 2013 8:37:19 PM UTC+1, Stefan Kamphausen wrote:
>
>
> this works pretty well, at least better than I expected, e.g.:
>
>  user=> (def r1 #"(\s.)")
> #'user/r1
> user=> (def r2 #"([abc])")
> #'user/r2
> user=> (def r3 (re-pattern (str r1 "|" r2)))
> #'user/r3
> user=> r3
> #"(\s.)|([abc])"
> user=> (re-find r3 " x")
> [" x" " x" nil]
> user=> (re-find r3 "b")
> ["b" nil "b"]
>

This is a nice trick, but obviously isn't universal: it works only if you 
build up from parts that are literal regexes. More often that not this will 
not be the case.

-marko
 

-- 
-- 
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: contrib.monads doesn't compile?

[Sean Corfield]

Old contrib is no longer supported or maintained and parts of it do
not work with newer versions of Clojure so this failure is expected
and nothing will get done about it (unless someone volunteers to port
the old probabilities contrib to the new contrib ecosystem).

On Mon, Mar 18, 2013 at 12:32 PM, Jim - FooBar();  wrote:
> HI everyone,
>
> I just hit this and I thought I'd share... 2 min ago I specified
> clojure-contrib 1.2.0 as a dependency only to use 2 functions from the
> probabilities namespace. However that namepsace depends on the
> contrib.monads namespace which immediately throw this compiler error :
>
> CompilerException java.lang.IllegalStateException: Can't dynamically bind
> non-dynamic var: clojure.contrib.macro-utils/protected-symbols,
> compiling:(clojure/contrib/monads.clj:195:1)
>
> it's no biggie for me as I can copy paste the 2 3-line functions I want but
> still it strikes me as weird and I thought you should know...
>
> 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.
>
>



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

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

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

Re: contrib.monads doesn't compile?

[Marko Topolnik]

This is expected, the old contrib isn't compatible with 1.3+. You may have 
a look at the unofficial port to the newer versions:

https://github.com/arohner/clojure-contrib/tree/1.3-compat

On Monday, March 18, 2013 8:32:57 PM UTC+1, Jim foo.bar wrote:
>
> HI everyone, 
>
> I just hit this and I thought I'd share... 2 min ago I specified 
> clojure-contrib 1.2.0 as a dependency only to use 2 functions from the 
> probabilities namespace. However that namepsace depends on the 
> contrib.monads namespace which immediately throw this compiler error : 
>
> CompilerException java.lang.IllegalStateException: Can't dynamically 
> bind non-dynamic var: clojure.contrib.macro-utils/protected-symbols, 
> compiling:(clojure/contrib/monads.clj:195:1) 
>
> it's no biggie for me as I can copy paste the 2 3-line functions I want 
> but still it strikes me as weird and I thought you should know... 
>
> 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: Raw strings

[Andy Fingerhut]

On Mon, Mar 18, 2013 at 12:48 PM, Marko Topolnik
wrote:


>
> On Monday, March 18, 2013 8:37:19 PM UTC+1, Stefan Kamphausen wrote:
>>
>>
>> this works pretty well, at least better than I expected, e.g.:
>>
>>  user=> (def r1 #"(\s.)")
>> #'user/r1
>> user=> (def r2 #"([abc])")
>> #'user/r2
>> user=> (def r3 (re-pattern (str r1 "|" r2)))
>> #'user/r3
>> user=> r3
>> #"(\s.)|([abc])"
>> user=> (re-find r3 " x")
>> [" x" " x" nil]
>> user=> (re-find r3 "b")
>> ["b" nil "b"]
>>
>
> This is a nice trick, but obviously isn't universal: it works only if you
> build up from parts that are literal regexes. More often that not this will
> not be the case.
>

 str is based on the toString() method of java.util.regex.Pattern, so I do
not understand why you say it only works if you build up from parts that
are literal regexes.  For example:

user=> (def r1 (re-pattern "\\sfoo|bar\\d+"))
#'user/r1
user=> (def r2 (re-pattern "taking over the world( world)*\\b"))
#'user/r2
user=> (def r3 (re-pattern (str "(" r1 ")|(" r2 ")")))
#'user/r3
user=> r3
#"(\sfoo|bar\d+)|(taking over the world( world)*\b)"
user=> (re-find r3 "I don't like this fooing weather")
[" foo" " foo" nil nil]
user=> (re-find r3 "We should be taking over the world soon")
["taking over the world" nil "taking over the world" nil]

Andy

-- 
-- 
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: Raw strings

[Marko Topolnik]

On Monday, March 18, 2013 8:59:27 PM UTC+1, Andy Fingerhut wrote:
>
>  str is based on the toString() method of java.util.regex.Pattern, so I do 
> not understand why you say it only works if you build up from parts that 
> are literal regexes.  For example:
>
> user=> (def r1 (re-pattern "\\sfoo|bar\\d+"))
> #'user/r1
> user=> (def r2 (re-pattern "taking over the world( world)*\\b"))
> #'user/r2
> user=> (def r3 (re-pattern (str "(" r1 ")|(" r2 ")")))
> #'user/r3
> user=> r3
>

Well obviously, you aren't benefiting from the literal regex syntax here :) 
Stefan's point was using the literal syntax to avoid double-backslashes and 
such, while still programmatically building up the full regex.

-marko
 

-- 
-- 
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: core.logic 0.8.0

[Denis Labaye]

On Sun, Mar 17, 2013 at 8:50 PM, David Nolen  wrote:

> I'm happy to announce the release of core.logic 0.8.0. There are far too
> changes, bug fixes, and enhancements to cover here. For the most part the
> miniKanren portion of core.logic has been left unchanged from the
> standpoint of the user. The biggest change is the inclusion of extensible
> constraint logic programming (CLP) - specifically we now support constraint
> logic programming over finite domains as well as nominal logic programming.
>
> It's been a long time since the last release, getting all the CLP bits
> working has been a quite a job, but moving forward releases should be
> considerably more incremental.
>
> https://github.com/clojure/core.logic
>
> Happy relational hacking!
>

hurray!


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

Immutant and ClojureScript

[David Frese]

Hi,

I tried to use the Immutant app server, some ClojureScript, and this little 
ring middleware https://github.com/jblomo/ring.middleware.clojurescript to 
"automatically" compile the ClojureScript and the resulting js.
Upon a web-request, ClojureScript's build function is called from within 
the ring-handler function as expected, but it crashes with an exception - 
see below.

Looking at some source code of Immutant and ClojureScript, I saw that 
ClojureScript calls getContextClassLoader on the currentThread, and expects 
it to have a 'findResources' function, which the effective classloader at 
that time, the ImmutantClassLoader does not define itself - though it's a 
protected method from the standard base class java.lang.ClassLoader.

So, is that a bug in ClojureScript?
Does anybody have an idea for a workaround (I have little experience with 
all of this, including classloaders)?


Stacktrace:
23:06:01,247 ERROR [stderr] (http-/127.0.0.1:8080-1) Exception: 
java.lang.IllegalArgumentException: No matching method found: findResources 
for class org.immutant.core.ImmutantClassLoader
23:06:01,247 ERROR [stderr] (http-/127.0.0.1:8080-1)   
   Reflector.java:53 clojure.lang.Reflector.invokeMatchingMethod
23:06:01,247 ERROR [stderr] (http-/127.0.0.1:8080-1)   
   Reflector.java:28 clojure.lang.Reflector.invokeInstanceMethod
23:06:01,247 ERROR [stderr] (http-/127.0.0.1:8080-1)   
 closure.clj:849 cljs.closure/get-upstream-deps*
23:06:01,247 ERROR [stderr] (http-/127.0.0.1:8080-1)   
AFn.java:159 clojure.lang.AFn.applyToHelper
23:06:01,247 ERROR [stderr] (http-/127.0.0.1:8080-1)   
AFn.java:151 clojure.lang.AFn.applyTo
23:06:01,247 ERROR [stderr] (http-/127.0.0.1:8080-1)   
core.clj:601 clojure.core/apply
23:06:01,247 ERROR [stderr] (http-/127.0.0.1:8080-1)   
   core.clj:5620 clojure.core/memoize[fn]
23:06:01,247 ERROR [stderr] (http-/127.0.0.1:8080-1)   
 RestFn.java:397 clojure.lang.RestFn.invoke
23:06:01,248 ERROR [stderr] (http-/127.0.0.1:8080-1)   
 closure.clj:868 cljs.closure/build
23:06:01,248 ERROR [stderr] (http-/127.0.0.1:8080-1)   
clojurescript.clj:44 
ring.middleware.clojurescript/wrap-clojurescript[fn]
23:06:01,248 ERROR [stderr] (http-/127.0.0.1:8080-1)   
clojurescript.clj:38 
ring.middleware.clojurescript/wrap-clojurescript[fn]
23:06:01,248 ERROR [stderr] (http-/127.0.0.1:8080-1)   
core.clj:106 compojure.core/routing[fn]
23:06:01,248 ERROR [stderr] (http-/127.0.0.1:8080-1)   
   core.clj:2390 clojure.core/some
23:06:01,248 ERROR [stderr] (http-/127.0.0.1:8080-1)   
core.clj:106 compojure.core/routing
23:06:01,248 ERROR [stderr] (http-/127.0.0.1:8080-1)   
 RestFn.java:139 clojure.lang.RestFn.applyTo
23:06:01,248 ERROR [stderr] (http-/127.0.0.1:8080-1)   
core.clj:603 clojure.core/apply
23:06:01,248 ERROR [stderr] (http-/127.0.0.1:8080-1)   
core.clj:111 compojure.core/routes[fn]
23:06:01,248 ERROR [stderr] (http-/127.0.0.1:8080-1)   
Var.java:415 clojure.lang.Var.invoke
23:06:01,248 ERROR [stderr] (http-/127.0.0.1:8080-1)   
   reload.clj:18 ring.middleware.reload/wrap-reload[fn]
23:06:01,248 ERROR [stderr] (http-/127.0.0.1:8080-1)   
   stacktrace.clj:15 ring.middleware.stacktrace/wrap-stacktrace-log[fn]
23:06:01,248 ERROR [stderr] (http-/127.0.0.1:8080-1)   
   stacktrace.clj:79 ring.middleware.stacktrace/wrap-stacktrace-web[fn]
23:06:01,248 ERROR [stderr] (http-/127.0.0.1:8080-1)   
 ring.clj:46 immutant.web.ring/handle-request[fn]
23:06:01,248 ERROR [stderr] (http-/127.0.0.1:8080-1)   
 ring.clj:42 immutant.web.ring/handle-request
23:06:01,248 ERROR [stderr] (http-/127.0.0.1:8080-1)   
Var.java:423 clojure.lang.Var.invoke
23:06:01,248 ERROR [stderr] (http-/127.0.0.1:8080-1)   
 ClojureRuntimeImpl.java:162 
org.immutant.runtime.impl.ClojureRuntimeImpl.invoke
23:06:01,249 ERROR [stderr] (http-/127.0.0.1:8080-1)   
 ClojureRuntimeImpl.java:154 
org.immutant.runtime.impl.ClojureRuntimeImpl.invoke
23:06:01,249 ERROR [stderr] (http-/127.0.0.1:8080-1)   
 RingServlet.java:70 org.immutant.web.servlet.RingServlet.doRing
23:06:01,249 ERROR [stderr] (http-/127.0.0.1:8080-1)   
 RingServlet.java:47 org.immutant.web.servlet.RingServlet.doGet
23:06:01,249 ERROR [stderr] (http-/127.0.0.1:8080-1)   
HttpServlet.java:734

RE: ANN: core.logic 0.8.0

[Coen De Roover]

Couldn't agree more. Thanks for all the effort you put in! I'm very excited
about cl and it's future.
--
From: Denis Labaye
Sent: 18/03/2013 23:06
To: clojure@googlegroups.com
Cc: minikan...@googlegroups.com
Subject: Re: ANN: core.logic 0.8.0



On Sun, Mar 17, 2013 at 8:50 PM, David Nolen  wrote:

> I'm happy to announce the release of core.logic 0.8.0. There are far too
> changes, bug fixes, and enhancements to cover here. For the most part the
> miniKanren portion of core.logic has been left unchanged from the
> standpoint of the user. The biggest change is the inclusion of extensible
> constraint logic programming (CLP) - specifically we now support constraint
> logic programming over finite domains as well as nominal logic programming.
>
> It's been a long time since the last release, getting all the CLP bits
> working has been a quite a job, but moving forward releases should be
> considerably more incremental.
>
> https://github.com/clojure/core.logic
>
> Happy relational hacking!
>

hurray!


> 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
> ---
> 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: Understanding vars

[Mark Engelberg]

On Mon, Mar 18, 2013 at 12:38 PM, Marko Topolnik
wrote:

> This is just about the same as
>
> (def ^:const pi (compute-estimate-of-pi))
>
>
>
OK, just tried out ^:const in my code and it seems to strip off any meta
data associated with the object stored in the var.  That ruins its utility
for my purposes.

(def ecr (with-meta [] {:amazing true}))
(def ^:const c ecr)

(meta ecr) -> {:amazing true}
(meta c) -> nil

Bug?

-- 
-- 
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: Midje 1.5 released

[Evan Mezeske]

Thanks for your continued work on this, Brian.  I can't wait to upgrade!

On Monday, March 18, 2013 10:36:57 AM UTC-7, Brian Marick wrote:
>
> Midje is a test framework for Clojure that aims to be more readable than 
> clojure.test and to allow styles of testing that clojure.test does not. 
>
> 1.5 is the Enterprise Edition and Respect the Repl Release. 
>
> Enterprise (integration with build servers) 
> * Configuration files 
> * Tests can be selected using their metadata 
> * Plugin interface for customizing reporting 
>
> Respect the Repl: 
> * Although `lein midje` still works, the emphasis for non-batch 
>   use is on a set of repl tools. For example, you can autotest 
>   inside the repl, which is surprisingly better than running it at 
>   the command line. (You get both automatic rechecking of tests 
>   whose dependencies change and all the convenience of the repl 
>   prompt.) 
> * There's a lot of in-repl documentation. For example, 
>   `(doc midje-repl)` brings up a list of the names, brief 
>   summaries, and common uses of all the repl tools. 
> * Reporting of user errors is improved. (Some errors that 
>   previously produced confusing "I blew up" messages from Clojure 
>   now have their own checks that yield less confusing messages.) 
>
> The user guide has been largely rewritten. 
>
> https://github.com/marick/Midje 
>
> User guide, including two tutorials (one specifically for clojure.test 
> users): https://github.com/marick/Midje/wiki 
>
> Change list: 
> https://github.com/marick/Midje/wiki/What%27s-new-in-midje-1.5 
>
>  
> Looking for employment as a Clojure programmer 
> Latest book: /Functional Programming for the Object-Oriented Programmer/ 
> https://leanpub.com/fp-oo 
>
>

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

[Kemar]

Explicitly derefing the var and calling meta on it works:

(meta @#'c) -> {:amazing true}

No idea as to why though...


Am Dienstag, 19. März 2013 03:45:57 UTC+1 schrieb puzzler:
>
> On Mon, Mar 18, 2013 at 12:38 PM, Marko Topolnik 
> 
> > wrote:
>
>> This is just about the same as
>>
>> (def ^:const pi (compute-estimate-of-pi))
>>
>>
>>
> OK, just tried out ^:const in my code and it seems to strip off any meta 
> data associated with the object stored in the var.  That ruins its utility 
> for my purposes.
>
> (def ecr (with-meta [] {:amazing true}))
> (def ^:const c ecr)
>
> (meta ecr) -> {:amazing true}
> (meta c) -> nil
>
> Bug?
>

-- 
-- 
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: Understanding vars

[Mark Engelberg]

On Mon, Mar 18, 2013 at 8:31 PM, Kemar  wrote:

> Explicitly derefing the var and calling meta on it works:
>
> (meta @#'c) -> {:amazing true}
>
> No idea as to why though...
>

Quirky.  I assume that explicitly derefing the var defeats the speed
benefits of  ^:const, yes?

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

Re: Clojure - CLR - JS - Visual Studio Extension

[Devin Garner]

I'm not sure how CLR & Javascript are related. However, if you want Clojure 
to translate into javascript, ClojureScript does that. If you're interested 
in helping make a visual studio extension to clojure, vsClojure is open 
source & could use your help. It shouldn't be too hard to modify the 
msbuild script in vsClojure to point to the ClojureScript compiler, instead 
of the ClojureCLR compiler.

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